can't log on HTML5 web site

Question

can't log on HTML5 web site

Misko Stanivukovich 25

Hello I have deployed RDS, and I also have installed HTML5

packageId : rd-html5 version : 2.1.65.0 author : Microsoft summary : The Remote Desktop Web Client minRDWebClientManagementVersion : 1.0.4 path : C:\Program Files\RemoteDesktopWeb\Internal\Clients\x4isi5i1.oca _baseVersion : 2.1.65.0 publishedAs : {}

I can log on to RDWeb/Pages but when I try to log to RDWeb/webclient it is rejecting my log in credentials which are the same

4 answers

Your answer

Answer 1

Hi Misko Stanivukovich,

Thanks for the update, and great job getting the HTML5 Web Client installed!

From what you’ve described, you’re able to log in successfully at /RDWeb/Pages, but login fails at /RDWeb/webclient using the same credentials. This usually points to a configuration issue specific to the HTML5 client.

In my understanding, The HTML5 Web Client has stricter requirements for authentication and deployment linkage. Even if RDWeb/Pages works, the HTML5 client may reject logins due to:

Missing or unpublished web client package
RD Gateway misconfiguration
User permissions not correctly set
SSO or credential caching conflicts
Certificate trust issues

Here are a few things to check to help resolve this:

1. Verify Web Client Is Published

Run:

Get-RDWebClientPackage

If not published:

Publish-RDWebClientPackage -Type Production -Latest

Reference: Set up the Remote Desktop Web Client

2. Use the Correct Login URL

Make sure you're accessing:

https://<YourServerFQDN>/RDWeb/webclient/index.html

Some browsers don’t redirect properly if /index.html is missing.

3. Check RD Gateway Configuration

The HTML5 client uses RD Gateway for external access. Ensure:

RD Gateway is enabled and reachable
Certificate is valid and trusted
Gateway settings are configured in the deployment

I managed to find this thread with a similar issue, please take a look at the solutions when you have the time: RemoteApp WebClient Launch Failure

4. Review User Permissions

Make sure the user:

Is part of the Remote Desktop Users group
Is assigned to the RemoteApp collection

Reference: RDWeb login OK, but RemoteApp says credentials are wrong

5. Check for SSO Conflicts

If SSO is enabled and the user recently changed their password, registry settings like ForceSilentTSAutoLogon can block login.

Reference: SSO Login Failure Troubleshooting

6. Try a Different Browser or InPrivate Mode

Sometimes cached credentials or certificate trust issues can interfere. Testing in a clean browser session can help isolate the issue.

Let me know what you find after trying these steps. If login still fails, feel free to share any error messages or screenshots, and I’ll help you dig deeper.

Answer 2

Misko Stanivukovich 25

It is having same issue

An account failed to log on.

Subject:

Security ID:		NULL SID

Account Name:		-

Account Domain:		-

Logon ID:		0x0

Logon Type: 3

Account For Which Logon Failed:

Security ID:		NULL SID

Account Name:		test

Account Domain:		dc01

Failure Information:

Failure Reason:		An Error occured during Logon.

Status:			0xC000006D

Sub Status:		0x0

Process Information:

Caller Process ID:	0x0

Caller Process Name:	-

Network Information:

Workstation Name:	TC-XXXXX

Source Network Address:	131.176.170.130

Source Port:		51038

Detailed Authentication Information:

Logon Process:		

Authentication Package:	NTLM

Transited Services:	-

Package Name (NTLM only):	-

Key Length:		0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.

- Transited services indicate which intermediate services have participated in this logon request.

- Package name indicates which sub-protocol was used among the NTLM protocols.

- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-07T03:10:47.69+00:00
Hi Misko Stanivukovich,

Thanks for sharing the error log, it helps a lot!

This is a common issue when setting up the HTML5 Web Client for Remote Desktop, and it’s usually caused by a small configuration step being missed. The logs:

An account failed to log on. Status: 0xC000006D Logon Type: 3 Authentication Package: NTLM

This means the system received your login request but couldn’t verify the credentials. It’s not that the username or password is wrong, it’s more likely that the HTML5 Web Client isn’t fully connected to the rest of your RDS setup. Here are some common fixes:

1. Make Sure the Web Client Is Published

I know I already provided it in my last response, but I need confirmation you have done this step. Even if the client is installed, it won’t work until it’s published.

To check and publish it:

Open PowerShell as Administrator

Run:

Get-RDWebClientPackage Publish-RDWebClientPackage -Type Production -Latest

Publish the Web Client – Microsoft Docs

2. Confirm the User Is Assigned to a Collection

The HTML5 client only allows logins for users who are:

In the Remote Desktop Users group

Assigned to a RemoteApp or Session Collection

To check this:

On your RD Connection Broker, open Server Manager > Remote Desktop Services > Collections

Make sure the user account is listed under the correct collection

Manage user accounts in Active Directory Users and Computers – Microsoft Docs

3. Verify RD Gateway Configuration

The HTML5 client requires RD Gateway, even for internal access. If the Gateway isn’t set up or the certificate isn’t trusted, login will silently fail.

To check this:

Open Server Manager > Remote Desktop Services > Overview

Click Edit Deployment Properties

Go to the RD Gateway tab and confirm:

RD Gateway is enabled

The certificate is valid and trusted

The FQDN is reachable from the client

Configure RD Gateway for Web Client – Microsoft Docs

4. Try a Clean Browser Session

Sometimes cached credentials or certificate issues can interfere. So try:

Open the web client in InPrivate/Incognito mode

Or use a different browser to test

I know I am repeating some of the steps, but I need you to confirm:

If the web client was successfully published

Whether the user is part of a RemoteApp or Session Collection

If the RD Gateway is enabled and reachable

And whether you’ve tried logging in from a private browser session

This way we can narrow down the issue you are having.

Let me know how it goes after trying these steps! If it still doesn’t work, I’ll be happy to dig deeper with you.
Misko Stanivukovich 25 Reputation points

2025-08-07T09:13:54.8433333+00:00

Hello I have try the above 4 steps all is ok but still same
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-07T10:47:50.36+00:00
Hi Misko Stanivukovich,

Thanks for the confirmation - I really appreciate your effort!

Since the issue is still happening, we’ll need to dig a little deeper to pinpoint what’s blocking the login.

Confirm the User Is in the Right AD Group

Can you verify that the user account (test from domain dc01) is a member of the Remote Desktop Users group in Active Directory?

Manage user accounts in Active Directory Users and Computers

Check RD Gateway Authentication Settings

Open Server Manager > Remote Desktop Services > Overview > Edit Deployment Properties, then go to the RD Gateway tab and confirm:

RD Gateway is enabled

The authentication method is set to Password (not Smart Card or custom)

The certificate is valid and trusted by the client machine

Configure RD Gateway for Web Client – Microsoft Docs

Test Classic RDWeb Login with RemoteApp

Try logging in to /RDWeb/Pages and launching a RemoteApp or desktop. If this fails too, it confirms the issue is not specific to the HTML5 client but likely related to user access or gateway configuration.

Review Event Viewer Logs on RD Gateway and Broker

On the RD Gateway and RD Connection Broker servers, open:

Event Viewer > Windows Logs > Application

Event Viewer > Windows Logs > Security

Look for:

Audit failures

Credential delegation errors

Kerberos or NTLM authentication issues

These logs can help us trace where the login is being rejected.

Let me know what you find from these steps especially the Event Viewer logs. We can walk through the logs together.
Misko Stanivukovich 25 Reputation points

2025-08-07T11:35:08.36+00:00
I can confirm I have cheeked the 3 steps above all is good I can access the rd page with credentials, from the event viiewer the logs:

Process ID: 1664 Process name: w3wp.exe Account name: IIS APPPOOL\RDWebAccess

Exception information:

Exception type: NullReferenceException Exception message: Object reference not set to an instance of an object.

at Microsoft.TerminalServices.Publishing.Portal.FormAuthentication.TSFormAuthTicketInfo..ctor(HttpContext objHttpContext)

at ASP.en_us_default_aspx.<GetAppsAsync>d__0.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

at System.Web.UI.PageAsyncTaskManager.<ExecuteTasksAsync>d__3.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at System.Web.UI.Page.<ProcessRequestAsync>d__554.MoveNext()

Request information:

Request URL: https://xxxxxxxxxx:443/RDWeb/Pages/en-US/default.aspx Request path: /RDWeb/Pages/en-US/default.aspx User host address: 10.181.216.97 User: Is authenticated: False Authentication Type: Thread account name: IIS APPPOOL\RDWebAccess

An account failed to log on. Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: NULL SID Account Name: test Account Domain: dc01 Failure Information: Failure Reason: An Error occured during Logon. Status: 0xC000006D Sub Status: 0x0 Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: TC-XXXXXX Source Network Address: 131.176.170.130 Source Port: 53358 Detailed Authentication Information: Logon Process: Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0

This is all I have found
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-08T03:36:52.7166667+00:00
Hi Misko Stanivukovich,

Thank you for sharing the detailed Event Viewer logs, very helpful in narrowing this down. Based on the error:

Exception type: NullReferenceException at Microsoft.TerminalServices.Publishing.Portal.FormAuthentication.TSFormAuthTicketInfo..ctor(HttpContext objHttpContext)

and the Security log (Status: 0xC000006D, Authentication Package: NTLM), this indicates the HTML5 Web Client is failing during the authentication ticket creation process in RDWeb. This usually happens when:

IIS authentication settings or RDWeb configuration are misaligned

There’s a corruption in the RDWeb/HTML5 deployment.

Please go through these steps accordingly:

1. Check IIS Authentication Settings

Open IIS Manager→Sites→Default Web Site→RDWeb→Pages.

Under Authentication:

Windows Authentication = Enabled

Anonymous Authentication = Disabled

Forms Authentication should NOT be enabled.

If you make changes, restart IIS:

iisreset

RDWeb relies on Windows Authentication to create a secure session ticket. If Anonymous or Forms Authentication is enabled, RDWeb cannot generate the ticket, causing the NullReferenceException.

Reference: Configure Authentication in IIS

2. Reset RDWeb Configuration

If any custom web.config exists in:

C:\Windows\Web\RDWeb\Pages

C:\Program Files\RemoteDesktopWeb\Internal\Clients

rename it (e.g., web.config.old) and restart IIS.

If corruption is suspected, reinstall RD Web Access:

Uninstall-WindowsFeature RDS-Web-Access Install-WindowsFeature RDS-Web-Access

Corrupted or custom web.config files can break the authentication pipeline. Resetting ensures RDWeb uses the default configuration.

3. Verify RDWebAccess App Pool Settings

In IIS → Application Pools → RDWebAccess:

.NET CLR Version = v4.0

Managed Pipeline Mode = Integrated

Identity = Network Service (or default)

RDWeb requires .NET CLR v4.0 and Integrated pipeline mode. If these are wrong, the ASP.NET components fail to process authentication.

Reference: Application Pools settings

4. Repair HTML5 Web Client

Unpublish and republish the HTML5 Web Client:

Unpublish-RDWebClientPackage Publish-RDWebClientPackage -Type Production -Latest

Republishing refreshes internal files and fixes broken references that can occur after updates or partial installs.

5. Advanced Checks (Optional)

If the issue persists after the steps above or if you’re in a domain environment using RD Gateway, please check:

Kerberos/SPN Validation

Kerberos is the default authentication protocol in AD. If SPNs are missing or misconfigured, Kerberos fails and falls back to NTLM (as seen in your logs).

setspn -L <RD Gateway Server>

You should see:

HTTP/<FQDN> HTTP/<ShortName> TERMSRV/<FQDN> TERMSRV/<ShortName>

If missing, add them:

setspn -S HTTP/<FQDN> <ServerName> setspn -S HTTP/<ShortName> <ServerName> setspn -S TERMSRV/<FQDN> <ServerName> setspn -S TERMSRV/<ShortName> <ServerName>

Reference:

Kerberos Authentication Overview

Setspn Tool

RD Gateway CAP/RAP Policies

In RD Gateway Manager, confirm:

The user/group is allowed in Connection Authorization Policies (CAP).

The target resources are allowed in Resource Authorization Policies (RAP).

Reference: Configure RD Gateway CAP and RAP

I managed to find these fixes. Please after you have tried it, tell me how it goes.

If the issue still persists, let me know right away!
Misko Stanivukovich 25 Reputation points

2025-08-08T08:22:22.3233333+00:00
This part is not configurated and it is returning error:

FindDomainForAccount: Call to DsGetDcNameWithAccountW failed with return value 0x00000525 Could not find account xxxxx

Regarding the power shell commands are from Domain controller power shell to the host or opposite

Could not find account tc-testlab.tecm.esa.int

5. Advanced Checks (Optional)

If the issue persists after the steps above or if you’re in a domain environment using RD Gateway, please check:

Kerberos/SPN Validation

Kerberos is the default authentication protocol in AD. If SPNs are missing or misconfigured, Kerberos fails and falls back to NTLM (as seen in your logs).

SQLCopy

setspn -L <RD Gateway Server>

You should see:

JSONCopy

HTTP/<FQDN> HTTP/<ShortName> TERMSRV/<FQDN> TERMSRV/<ShortName>

If missing, add them:

PowerShellCopy

setspn -S HTTP/<FQDN> <ServerName> setspn -S HTTP/<ShortName> <ServerName> setspn -S TERMSRV/<FQDN> <ServerName> setspn -S TERMSRV/<ShortName> <ServerName>
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-08T09:35:42.72+00:00
Hi Misko Stanivukovich,

The message:

FindDomainForAccount: DsGetDcNameWithAccountW failed (0x00000525) Could not find account tc-testlab.tecm.esa.int

means the RD Web Client or RD Gateway cannot locate this account in Active Directory. This is an Active Directory lookup issue, not an HTML5 Web Client configuration problem. The Web Client depends on AD and RD Gateway for authentication, so if the account cannot be resolved, the Web Client will fail regardless of IIS or HTML5 settings. Missing or misconfigured SPNs when Kerberos is in use.

Please try out these steps:

Confirm the account exists and is enabled

Run this on a domain controller or any domain-joined machine with the Active Directory module (RSAT):

Get-ADUser -Identity "tc-testlab.tecm.esa.int" -Properties Enabled

Expected:

DistinguishedName : CN=tc-testlab,OU=Users,DC=tecm,DC=esa,DC=int Enabled : True Name : tc-testlab SamAccountName : tc-testlab UserPrincipalName : ******@tecm.esa.int

If you see an error like:

Get-ADUser : Cannot find an object with identity: 'tc-testlab.tecm.esa.int'

It means the account does not exist or the UPN is incorrect.

Check domain controller connectivity

Run this on the RD Gateway or RD Web Access server (because we need to confirm these servers can reach a domain controller):

nltest /dsgetdc:tecm.esa.int

Expected:

DC: \DC01.tecm.esa.int Address: \10.x.x.x Domain Name: tecm.esa.int The command completed successfully

If you see:

DsGetDcName failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

There is a DNS or trust issue between the server and the domain.

Test login on RDWeb/Pages

Try logging into RDWeb/Pages with the same account.

If this fails, the issue is with AD authentication, not the HTML5 Web Client.

SPN Check (Kerberos)

If the account exists and domain connectivity works, check SPNs for the RD Gateway server. Run this on a domain controller or any machine with RSAT tools:

setspn -L <RD Gateway ServerName>

You should see entries like:

HTTP/<FQDN> HTTP/<ShortName> TERMSRV/<FQDN> TERMSRV/<ShortName>

If any are missing, add them:

setspn -S HTTP/<FQDN> <ServerName> setspn -S HTTP/<ShortName> <ServerName> setspn -S TERMSRV/<FQDN> <ServerName> setspn -S TERMSRV/<ShortName> <ServerName>

Please share when you have tried out these steps:

Output of Get-ADUser (or the error if it fails)

Output of nltest /dsgetdc:tecm.esa.int

Output of setspn -L <RD Gateway ServerName>

This will confirm whether the issue is account-related, DNS/trust-related, or SPN-related.
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-12T03:40:01.16+00:00

Hi Misko Stanivukovich,

Just checking if you have your issue resolved! If you have any more issue please let me know!
Misko Stanivukovich 25 Reputation points

2025-08-18T07:15:39.2333333+00:00

Hello still not solved sorry I was on vacation
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-18T07:23:55.9533333+00:00
Hi Misko Stanivukovich,

Thank you for the update and welcome back!

Just to be sure. Were you able to try the latest steps I shared? The outputs from these checks will help us pinpoint the root cause:

Get-ADUser result (or the error if it fails)

nltest /dsgetdc:tecm.esa.int result

setspn -L <RD Gateway ServerName> result

If you run into any issues executing these commands, let me know—we can guide you through them.

Once we have these details, we can confirm whether the issue is account-related, DNS/trust-related, or SPN-related and move forward with the fix.
Misko Stanivukovich 25 Reputation points

2025-08-18T09:49:24.2433333+00:00
PS C:\Windows\system32> Get-ADUser

Get-ADUser : The term 'Get-ADUser' is not recognized as the name of a cmdlet, function, script file, or operable

program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

At line:1 char:1

Get-ADUser

+ CategoryInfo : ObjectNotFound: (Get-ADUser:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException

PS C:\Windows\system32> nltest /dsgetdc:dc01.tecm

DC: \\tec-dc01-ext.dc01.tecm Address: \\131.176.170.134 Dom Guid: cfb0af78-187b-4276-8bc3-bffde0b3acec Dom Name: dc01.tecm

Forest Name: dc01.tecm

Dc Site Name: Default-First-Site-Name

Our Site Name: Default-First-Site-Name

Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9 DS_10 0x20000

The command completed successfully
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-18T10:56:21.03+00:00
Hi Misko Stanivukovich,

Thank you for sharing the logs. I’ve reviewed them carefully, and here’s what they confirm:

Get-ADUser Not Recognized

The error:

Get-ADUser : The term 'Get-ADUser' is not recognized...

means the Active Directory PowerShell module is not installed on the machine where you ran the command.

This is expected if the command was executed on an RD Gateway or RD Web Access server, as these roles do not include AD tools by default.

nltest /dsgetdc:dc01.tecm Succeeded

The output shows:

DC: \tec-dc01-ext.dc01.tecm Flags: PDC GC DS LDAP KDC TIMESERV ... The command completed successfully

This confirms:

The server can locate and communicate with a Domain Controller.

DNS and LDAP services are working.

So, domain connectivity is healthy.

This means:

The AD lookup error (FindDomainForAccount: DsGetDcNameWithAccountW failed (0x00000525)) is not caused by network issues.

The likely causes are:

The user account does not exist or is disabled.

The UPN (User Principal Name) does not match what is being used for login.

Missing or incorrect SPNs (Service Principal Names) for RD Gateway.

Please perform these checks on a Domain Controller or a machine with RSAT installed:

Step 1: Install RSAT (if not on a Domain Controller)

On Windows 10/11:

Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

On Windows Server:

Install-WindowsFeature RSAT-AD-PowerShell

Reference: Learn more about RSAT installation

Step 2: Verify the User Account

Run:

Get-ADUser <username> -Properties Enabled,UserPrincipalName

Confirm:

Enabled = True.

UserPrincipalName matches the format you use to log in (e.g., ******@company.com).

Reference: Get-ADUser documentation

Step 3: Check for UPN Mismatch

If the UPN is different from what users enter, update it:

Set-ADUser <username> -UserPrincipalName ******@company.com

Reference: More on UPN and RDS

Step 4: Validate SPNs for RD Gateway

Run:

setspn -L <RDGatewayServerName>

Ensure entries like:

TERMSRV/<FQDN> TERMSRV/<NetBIOSName>

If missing, add them:

setspn -S TERMSRV/<FQDN> <RDGatewayServerName> setspn -S TERMSRV/<NetBIOSName> <RDGatewayServerName>

Reference: SetSPN documentation

These steps help because:

The HTML5 Web Client relies on Active Directory lookups and Kerberos authentication.

If the account is disabled, UPN is incorrect, or SPNs are missing, authentication will fail even though RDWeb/Pages works.

Please let me know the results of these steps when you have the time to try them.
Misko Stanivukovich 25 Reputation points

2025-08-18T11:13:16.01+00:00

This is the problem it is windows 2019 server

PS C:\Users\Administrator> Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

Path :

Online : True

RestartNeeded : False

PS C:\Users\Administrator> Get-ADUser tecmit -Properties Enabled,UserPrincipalName

DistinguishedName : CN=tecmit,CN=Users,DC=dc01,DC=tecm

Enabled : True

GivenName : tecmit

Name : tecmit

ObjectClass : user

ObjectGUID : 86399ec6-c332-4ceb-923b-afadea50b57c

SamAccountName : tecmit

SID : S-xxxxxxx -xxxxx

Surname :

UserPrincipalName : ******@dc01.tecm

PS C:\Users\Administrator> setspn -S TERMSRV/tec-dc01-ext.dc01.tecm tc-testlab.dc01.tecm

Checking domain DC=dc01,DC=tecm

FindDomainForAccount: Call to DsGetDcNameWithAccountW failed with return value 0x00000525

Unable to locate account tc-testlab.dc01.tecm
Misko Stanivukovich 25 Reputation points

2025-08-18T11:20:43.9533333+00:00

PS C:\Users\Administrator> setspn -L tc-testlab.dc01.tecm

FindDomainForAccount: Call to DsGetDcNameWithAccountW failed with return value 0x00000525

Could not find account tc-testlab.dc01.tecm
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-19T03:30:06.3466667+00:00
Hi Misko Stanivukovich,

Thank you for taking the time to share the latest outputs and for your patience throughout this process. The new information you provided is very helpful and gives us a clear direction toward resolving the issue.

The error you encountered:

FindDomainForAccount: Call to DsGetDcNameWithAccountW failed with return value 0x00000525 Could not find account tc-testlab.dc01.tecm

occurs when Active Directory cannot find the account you specified in the setspn command. In other words, the computer account you’re trying to update SPNs for does not exist in AD under that name.

This is why both:

setspn -S TERMSRV/<FQDN> <RDGatewayServerName> setspn -S TERMSRV/<NetBIOSName> <RDGatewayServerName>

are failing.

Why This Matters

The HTML5 Web Client uses Kerberos authentication for secure connections.

Kerberos requires Service Principal Names (SPNs) to be correctly registered on the RD Gateway server’s computer account in Active Directory.

If the computer account is missing or the wrong name is used, SPN registration fails → Kerberos fails → HTML5 login fails.

Step 1: Find the Correct RD Gateway Server Name

The name you use in the setspn command must match the actual computer account name in Active Directory (usually the NetBIOS name of the RD Gateway server).

How to check the correct name:

On the RD Gateway server, run:

hostname

This shows the server’s short name (NetBIOS name).

Then, on a Domain Controller or RSAT machine, confirm the computer account exists:

Get-ADComputer <hostname>

Example:

Get-ADComputer tc-testlab

If this returns the computer object → Great, proceed to Step 2.

If it returns nothing → The RD Gateway server is not joined to the domain or the name is incorrect.

Fix: Join or rejoin the RD Gateway server to the domain.

Reference: Get-ADComputer documentation

Step 2: Register the Correct SPNs

Once the computer account exists in AD, run:

setspn -S TERMSRV/<FQDN> <ComputerAccountName> setspn -S TERMSRV/<NetBIOSName> <ComputerAccountName>

Example (replace with your actual names):

setspn -S TERMSRV/tc-testlab.dc01.tecm tc-testlab setspn -S TERMSRV/tc-testlab tc-testlab

The first part (TERMSRV/...) is the SPN value (FQDN and short name).

The second part is the actual AD computer account name of the RD Gateway server.

Step 3: Restart RD Gateway Services

After SPNs are registered, restart the RD Gateway services or reboot the server to apply the changes.

Why this might work:

SPNs allow Kerberos to authenticate the RD Gateway service.

Without correct SPNs on the RD Gateway’s computer account, authentication falls back to NTLM or fails entirely, which breaks HTML5 Web Client login.

Once the RD Gateway computer account is confirmed and SPNs are properly registered, the HTML5 Web Client should authenticate successfully.

References:

Service Principal Names (SPNs) Overview

Kerberos Authentication and SPNs

Please let me know once you’ve verified the computer account and applied the SPN commands when you have the time.
Misko Stanivukovich 25 Reputation points

2025-08-19T07:58:37.5333333+00:00
PS C:\Users\Administrator> Get-ADComputer tc-testlab

DistinguishedName : CN=TC-TESTLAB,CN=Computers,DC=dc01,DC=tecm

DNSHostName : tc-testlab.dc01.tecm

Enabled : True

Name : TC-TESTLAB

ObjectClass : computer

ObjectGUID : a5327233-1b7c-47aa-8bc7-bca4e790XXXX

SamAccountName : TC-TESTLAB$

SID : S-1-5-21-1431472414-3151924545-12366651XX-XXXX

UserPrincipalName :

PS C:\Users\Administrator> setspn -S TERMSRV/tc-testlab.dc01.tecm tc-testlab

Checking domain DC=dc01,DC=tecm

CN=TC-TESTLAB,CN=Computers,DC=dc01,DC=tecm

MSSQLSvc/tc-testlab.dc01.tecm:1433 MSSQLSvc/tc-testlab.dc01.tecm TERMSRV/TC-TESTLAB TERMSRV/tc-testlab.dc01.tecm WSMAN/tc-testlab WSMAN/tc-testlab.dc01.tecm RestrictedKrbHost/TC-TESTLAB HOST/TC-TESTLAB RestrictedKrbHost/tc-testlab.dc01.tecm HOST/tc-testlab.dc01.tecm

Duplicate SPN found, aborting operation!

PS C:\Users\Administrator> setspn -S TERMSRV/tc-testlab tc-testlab

Checking domain DC=dc01,DC=tecm

CN=TC-TESTLAB,CN=Computers,DC=dc01,DC=tecm

MSSQLSvc/tc-testlab.dc01.tecm:1433 MSSQLSvc/tc-testlab.dc01.tecm TERMSRV/TC-TESTLAB TERMSRV/tc-testlab.dc01.tecm WSMAN/tc-testlab WSMAN/tc-testlab.dc01.tecm RestrictedKrbHost/TC-TESTLAB HOST/TC-TESTLAB RestrictedKrbHost/tc-testlab.dc01.tecm HOST/tc-testlab.dc01.tecm

Duplicate SPN found, aborting operation!
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-19T08:12:32.21+00:00
Hi Misko Stanivukovich,

Thank you again for sharing the latest outputs and for your continued patience. Based on your confirmation that the RD Gateway computer account (tc-testlab) exists and is enabled in Active Directory, and that both required SPNs (TERMSRV/tc-testlab.dc01.tecm and TERMSRV/tc-testlab) are already registered, we’re in a great position to move forward.

The original error:

FindDomainForAccount: DsGetDcNameWithAccountW failed (0x00000525)

was caused by an AD lookup failure, likely due to a missing or misnamed computer account. That issue is now resolved.

To apply the changes and ensure Kerberos authentication works as expected:

Restart the RD Gateway services or reboot the RD Gateway server:

Restart-Service TSGateway

Test the HTML5 Web Client login again using a clean browser session (incognito/private mode).

With the correct SPNs in place and the computer account verified, the HTML5 Web Client should now authenticate successfully via Kerberos.

Please let me know how the login test goes when you have a moment. I’m here to help with the next steps if needed.
Misko Stanivukovich 25 Reputation points

2025-08-19T08:34:00.1533333+00:00

Same login issue I have done all the steps above
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-19T08:50:23.5366667+00:00
Hi Misko Stanivukovich,

Thanks for confirming that you've completed all the steps. I understand how frustrating this issue must be, especially after so many attempts and I truly appreciate your persistence.

Since the RD Gateway computer account and SPNs are correctly configured, and the original Active Directory lookup error is resolved, we’re now moving into the next layer of diagnostics. At this stage, we need to collect logs to pinpoint what’s blocking the HTML5 Web Client login.

Please collect the following:

HTML5 Web Client logs Location:
%ProgramData%\RDWebClientManagement\Logs

IIS logs Location:
C:\inetpub\logs\LogFiles\W3SVC*
Reference: IIS logging

Event Viewer logs Open Event Viewer > Applications and Services Logs > Microsoft > Windows:

TerminalServices-Gateway

TerminalServices-WebAccess

Fiddler trace (Optional)

Capture a trace during the login attempt to RDWeb/webclient.

Once we have these, we’ll be able to analyze the login flow in detail and identify any remaining misconfigurations or service-level issues.

Please let me know once you’ve gathered the logs.
Misko Stanivukovich 25 Reputation points

2025-08-19T10:47:46.2933333+00:00
#Software: Microsoft Internet Information Services 10.0

#Version: 1.0

#Date: 2025-08-19 08:27:55

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken

2025-08-19 08:27:55 131.176.170.XXX GET /RDWeb/webclient - 443 - 131.176.170.XXX Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36 - 401 2 5 2

An account failed to log on.

Subject:

Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:

Security ID: NULL SID Account Name: test Account Domain: DC01

Failure Information:

Failure Reason: An Error occured during Logon. Status: 0xC000006D Sub Status: 0x0

Process Information:

Caller Process ID: 0x0 Caller Process Name: -

Network Information:

Workstation Name: TC-TESTLAB Source Network Address: 131.176.170.XXX Source Port: 50022

Detailed Authentication Information:

Logon Process: Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-20T03:47:54.1933333+00:00
Hi Misko Stanivukovich,

Thank you for sharing the IIS log and Security event details. Based on the evidence:

The request to /RDWeb/webclient is returning 401.2 (Logon failed due to server configuration).

Security logs show NTLM failures, which means the HTML5 Web Client path is being protected by Windows Authentication instead of allowing Anonymous access.

This is an IIS configuration drift.

Enable Anonymous Authentication for /RDWeb/webclient

Open IIS Manager → Default Web Site → RDWeb → webclient → Authentication.

Enable: Anonymous Authentication

Disable: Windows Authentication (Reference: Configure Authentication in IIS)

Check Authorization Rules

In the same path, open Authorization Rules.

Ensure there is an Allow All Users rule and no inherited Deny rules. (Reference: Authorization Rules in IIS)

Verify File Permissions

Confirm that IUSR and IIS_IUSRS have Read & Execute permissions on the webclient folder. (Reference: Set File Permissions in IIS)

Optional – Reset Web Client Deployment If you suspect more configuration drift, you can reset and re-publish the HTML5 Web Client: Reset-RDWebClientDeployment Install-RDWebClientPackage Publish-RDWebClientPackage -Type Production iisreset /noforce

How to check the fix

Browse to: https://<your-RDS-FQDN>/RDWeb/webclient/ It should load without prompting for credentials.

If you still see 401 errors, please enable Failed Request Tracing for 401 status codes and share the FREB XML. (Reference: Troubleshoot IIS 401 Errors with FREB)

Once you make these changes, the HTML5 Web Client should load correctly. If the issue persists, please send:

Updated IIS logs after the change

FREB trace for /RDWeb/webclient

HTML5 Web Client logs from: C:\ProgramData\RDWebClientManagement\Logs

Let me know how it goes!
Misko Stanivukovich 25 Reputation points

2025-08-20T07:55:29.52+00:00
Same problem

ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken

2025-08-20 06:56:57 131.176.170.130 GET /RDWeb/webclient - 443 - 131.176.170.XXX Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36 - 401 2 5 0

An account failed to log on.

Subject:

Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:

Security ID: NULL SID Account Name: tecmit Account Domain:

Failure Information:

Failure Reason: An Error occured during Logon. Status: 0xC000006D Sub Status: 0x0

Process Information:

Caller Process ID: 0x0 Caller Process Name: -

Network Information:

Workstation Name: TC-TESTLAB Source Network Address: 131.176.170.XXX Source Port: 52101

Detailed Authentication Information:

Logon Process: Authentication Package: NTLM Transited Services: -

Tom Tran (WICLOUD CORPORATION) 525 Microsoft External Staff

Hi Misko Stanivukovich,

Thank you for sharing the latest IIS and Security logs. Based on the evidence:

The request to /RDWeb/webclient is still returning 401.2 (Logon failed due to server configuration).
Security logs show NTLM authentication attempts, which means the HTML5 Web Client path is still protected by Windows Authentication instead of allowing Anonymous access.

This confirms the issue is an IIS configuration override at the /RDWeb/webclient level.

Please open Command Prompt as Administrator and run the following commands exactly as shown:

REM Enable Anonymous Authentication and disable Windows Authentication
%windir%\system32\inetsrv\appcmd set config "Default Web Site/RDWeb/webclient" -section:system.webServer/security/authentication/anonymousAuthentication /enabled:true /commit:apphost
%windir%\system32\inetsrv\appcmd set config "Default Web Site/RDWeb/webclient" -section:system.webServer/security/authentication/windowsAuthentication /enabled:false /commit:apphost
REM Clear inherited authorization rules and allow all users
%windir%\system32\inetsrv\appcmd set config -location:"Default Web Site/RDWeb/webclient" -section:system.web/authorization /clear /commit:apphost
%windir%\system32\inetsrv\appcmd set config -location:"Default Web Site/RDWeb/webclient" -section:system.web/authorization /+"[accessType='Allow', users='*']" /commit:apphost
REM Show the effective configuration (please copy these outputs back to us)
%windir%\system32\inetsrv\appcmd list config "Default Web Site/RDWeb/webclient" -section:system.webServer/security/authentication/anonymousAuthentication
%windir%\system32\inetsrv\appcmd list config "Default Web Site/RDWeb/webclient" -section:system.webServer/security/authentication/windowsAuthentication
%windir%\system32\inetsrv\appcmd list config "Default Web Site/RDWeb/webclient" -section:system.web/authorization
REM Restart IIS
iisreset /noforce

After running these:

Browse to https://<your-RDWeb-FQDN>/RDWeb/webclient
It should load without prompting for credentials.

If you still see 401:

Please provide:

The outputs of the three AppCmd “list config” commands above.
A Failed Request Tracing (FREB) XML for status code 401 on /RDWeb/webclient (Reference: Troubleshoot IIS 401 Errors with FREB).
Updated IIS logs after the change.

Misko Stanivukovich 25

HTTP Error 500.19 - Internal Server Error

The requested page cannot be accessed because the related configuration data for the page is invalid.

Detailed Error Information:

ProtocolSupportModule
Module	ProtocolSupportModule
Notification	SendResponse
Handler	StaticFile
Error Code	0x800700b7
Config Error	Cannot add duplicate collection entry of type 'add' with unique key attribute 'name' set to 'X-Frame-Options'

Config Source:

   20:         <customHeaders>

Misko Stanivukovich 25 Reputation points

2025-08-20T09:45:29.05+00:00

Config Source:

20: <customHeaders>

21: <add name="X-Frame-Options" value="SAMEORIGIN"/>

22: </customHeaders>
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-20T10:02:42.4233333+00:00
Hi Misko Stanivukovich,

The new error you’re seeing:

HTTP Error 500.19 - Internal Server Error Cannot add duplicate collection entry of type 'add' with unique key attribute 'name' set to 'X-Frame-Options'

occurs when IIS finds the same custom header defined in more than one place (for example, at the server or site level and again under RDWeb/webclient). This is a common IIS configuration merge behavior.

Option 1 – Remove the parent header (quickest)

If security policy allows, remove the X-Frame-Options header from the Default Web Site level:

IIS Manager

Go to Default Web Site → HTTP Response Headers.

Select X-Frame-Options → Remove.

Run:
iisreset /noforce

Or via AppCmd:

%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpProtocol /-"customHeaders.[name='X-Frame-Options']" /commit:apphost -location:"Default Web Site" iisreset /noforce

Option 2 – Keep the parent header but override it at the app

If you must keep the header at the site/server level, edit the RDWeb/webclient web.config and add:

<system.webServer> <httpProtocol> <customHeaders> <remove name="X-Frame-Options" /> <add name="X-Frame-Options" value="SAMEORIGIN" /> </customHeaders> </httpProtocol> </system.webServer>

This removes the inherited header before adding the desired value, preventing duplication.

After applying one of the above fixes, please browse to:

https://<your-server>/RDWeb/webclient

If you still see 401:

Please send me:

The outputs of these three commands:

%windir%\system32\inetsrv\appcmd list config "Default Web Site/RDWeb/webclient" -section:system.webServer/security/authentication/anonymousAuthentication %windir%\system32\inetsrv\appcmd list config "Default Web Site/RDWeb/webclient" -section:system.webServer/security/authentication/windowsAuthentication %windir%\system32\inetsrv\appcmd list config "Default Web Site/RDWeb/webclient" -section:system.web/authorization

A Failed Request Tracing (FREB) log for 401 on /RDWeb/webclient and updated IIS logs.
Misko Stanivukovich 25 Reputation points

2025-08-20T10:13:54.6233333+00:00

Thanks very much now it is finally working

There are currently no resources assigned to you in . Contact technical support for help.

This is the last error
Misko Stanivukovich 25 Reputation points

2025-08-20T10:14:39.8366667+00:00

But I can log in with credentials
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-20T10:49:21.9733333+00:00
Hi Misko Stanivukovich,

Thanks for confirming that the HTML5 Web Client is now working and you're able to log in successfully - that’s great news!

The message you are seeing:

There are currently no resources assigned to you in . Contact technical support for help.

This message indicates that the user has successfully authenticated, but no RemoteApps or desktops are currently assigned to their account. This is a common and low-severity issue at this stage.

Next Steps

Please check the following:

User Assignment to Collection

Open Server Manager → Remote Desktop Services → Collections

Select the relevant collection and ensure the user is listed under User Groups

Published Resources

Confirm that the collection has at least one RemoteApp or desktop published.

Correct Deployment Target

Make sure the RDWeb/webclient is pointing to the correct deployment and collection.

Test with Another User

Try logging in with a known working user to confirm the Web Client is functioning correctly.

Let me know how it goes. Otherwise, it looks like you're very close to full functionality!
Misko Stanivukovich 25 Reputation points

2025-08-20T12:03:42.25+00:00
The first 2 steps are ok

Correct Deployment Target

Make sure the RDWeb/webclient is pointing to the correct deployment and collection. Can you assist me with this step how to configurated
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-21T04:06:23.0833333+00:00
Hi Misko Stanivukovich,

Thanks for confirming that the user assignment and published resources are already in place!

Regarding your question on:
“Correct Deployment Target – Make sure the RDWeb/webclient is pointing to the correct deployment and collection.”

This step ensures that the HTML5 Web Client is correctly configured to communicate with your Remote Desktop deployment. If this isn’t set up properly, users may authenticate successfully but still see the message:

“There are currently no resources assigned to you in . Contact technical support for help.”

This is a common and low-severity issue at this stage, and here’s how to verify and correct it:

1. Confirm the Web Client is Published

On the RD Web Access server, open PowerShell and run:

Get-RDWebClientPackage

If no package is listed or it’s outdated, publish the latest version:

Publish-RDWebClientPackage -Type Production -Latest

This ensures the Web Client is active and using the latest configuration.

2. Check Deployment Settings

Still on the RD Web Access server, run:

Get-RDWebClientDeploymentSetting

This will return key configuration values such as:

RDWebAccessServer

RDConnectionBroker

DeploymentType

Make sure these values match your intended RDS deployment. If anything looks incorrect or outdated, re-publishing the Web Client (as shown above) will refresh the configuration.

3. Confirm RD Web Access is Part of the Deployment

In Server Manager → Remote Desktop Services → Overview, verify that:

RD Web Access

RD Connection Broker

RD Session Host

...are all listed and healthy. If RD Web Access is not part of the deployment, it won’t be able to enumerate resources for the Web Client.

4. Verify the Web Client URL

Ensure users are accessing the correct URL format:

https://<YourServerFQDN>/RDWeb/webclient/index.html

Some browsers may not redirect properly if /index.html is omitted, which can cause unexpected behavior.

I'd really recommend you read this to have a better understanding of the deployment: How to publish the Remote Desktop Web Client

Let me know how it goes after these checks.
Misko Stanivukovich 25 Reputation points

2025-08-21T06:44:45.4+00:00

PS C:\Windows\system32> Get-RDWebClientDeploymentSetting

Name Value

SuppressTelemetry False
Misko Stanivukovich 25 Reputation points

2025-08-21T06:45:13.4466667+00:00
Also I have removed

Go to Default Web Site → HTTP Response Headers.

Select X-Frame-Options → Remove.
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-21T07:26:54.36+00:00
Hi Misko Stanivukovich,

Thank you for sharing the output and the update on the header change. About:

Get-RDWebClientDeploymentSetting

The result:

Name Value SuppressTelemetry False

is expected and does not indicate a problem. This cmdlet only reports a few UI-related settings (like telemetry), not whether the Web Client is correctly linked to your RDS deployment. So this output is normal and not related to the “no resources assigned” message.

Why the issue persists

The HTML5 Web Client relies on RD Web Access being properly connected to the Connection Broker and having the correct Broker certificate imported. If that linkage is missing or broken, the client can authenticate but still show:

There are currently no resources assigned to you in <deployment>.

Next steps to confirm configuration

Please run these two commands on the RD Web Access server and share the outputs:

Get-RDWebClientPackage Get-RDWebClientBrokerCert

Get-RDWebClientPackage → Confirms the Web Client is published and current.

Get-RDWebClientBrokerCert → Confirms the Broker certificate is imported correctly.

If the Broker certificate is missing or incorrect, the fix is:

# Export the Broker's SSO certificate (.cer) from the Connection Broker # Then on RD Web Access: Import-RDWebClientBrokerCert "C:\path\broker.cer" Publish-RDWebClientPackage -Type Production -Latest

Also, please verify in Server Manager → Remote Desktop Services → Overview that:

RD Web Access

RD Connection Broker

RD Session Host are all listed and healthy.

Finally, confirm you’re using the full URL:

https://<FQDN>/RDWeb/webclient/index.html

About the X-Frame-Options header

I see you removed the header at the site level. If your security policy requires this header, please apply by adding it back at the app level in RDWeb/webclient\web.config or via AppCmd:

%windir%\system32\inetsrv\appcmd set config "Default Web Site/RDWeb/webclient" -section:system.webServer/httpProtocol /-"customHeaders.[name='X-Frame-Options']" /commit:apphost %windir%\system32\inetsrv\appcmd set config "Default Web Site/RDWeb/webclient" -section:system.webServer/httpProtocol /+customHeaders.[name='X-Frame-Options',value='SAMEORIGIN'] /commit:apphost iisreset /noforce

This ensures the header is present for security but does not block the Web Client.

If after these checks the message still appears, please collect:

%ProgramData%\RDWebClientManagement\Logs

IIS logs for /RDWeb/webclient

Event Viewer logs under Applications and Services Logs → Microsoft → Windows → TerminalServices-WebAccess

We’ll review those to identify the root cause.
Misko Stanivukovich 25 Reputation points

2025-08-21T07:41:55.12+00:00
%windir%\system32\inetsrv\appcmd set config "Default Web Site/RDWeb/webclient" -section:system.webServer/httpProtocol /-"customHeaders.[name='X-Frame-Options']" /commit:apphost

%windir%\system32\inetsrv\appcmd set config "Default Web Site/RDWeb/webclient" -section:system.webServer/httpProtocol /+customHeaders.[name='X-Frame-Options',value='SAMEORIGIN'] /commit:apphost

iisreset /noforce

PS C:\Windows\system32> Get-RDWebClientBrokerCert

Thumbprint Subject

2XXX9F7F9850222BD771EDB4C54CF211340D6E05 CN=tc-testlab.tecm.xxx.xxx, O=ESA-ESTEC (European Space Research and Techn...

After putting this command again I cannot see the web site

Config Source:

20: <customHeaders>
Misko Stanivukovich 25 Reputation points

2025-08-21T07:42:37.8866667+00:00
%windir%\system32\inetsrv\appcmd set config "Default Web Site/RDWeb/webclient" -section:system.webServer/httpProtocol /-"customHeaders.[name='X-Frame-Options']" /commit:apphost %windir%\system32\inetsrv\appcmd set config "Default Web Site/RDWeb/webclient" -section:system.webServer/httpProtocol /+customHeaders.[name='X-Frame-Options',value='SAMEORIGIN'] /commit:apphost iisreset /noforce

20: <customHeaders> 21: <add name="X-Frame-Options" value="SAMEORIGIN"/> 22: </customHeaders>
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-21T08:01:31.58+00:00
Hi Misko Stanivukovich,

Based on the information you shared, it looks like the RDWeb/webclient site is currently unavailable due to an invalid configuration in the web.config file.

The <customHeaders> section in your web.config appears to contain raw command-line text (e.g., appcmd set config ... iisreset /noforce) instead of valid XML. This breaks the IIS configuration and prevents the site from loading.

This likely occurred due to a misunderstanding — the commands I provided were meant to be run in PowerShell or Command Prompt, not pasted into the config file.

How to Fix It

Please follow these steps to restore the site:

Open the web.config file:

Path: C:\Windows\Web\RDWeb\webclient\web.config

Use Notepad or another text editor.

Find and correct the <customHeaders> section.

Remove any lines that contain command text like appcmd set config ....

Replace with the correct XML:

<customHeaders> <add name="X-Frame-Options" value="SAMEORIGIN" /> </customHeaders>

Save the file and run:

iisreset /noforce

Test the site by visiting the RDWeb/webclient URL in a browser.

After Recovery

Once the site is accessible again, we’ll continue investigating the original issue: “There are currently no resources assigned to you in <deployment>.”

Please re-run these commands on the RD Web Access server and share the outputs:

Get-RDWebClientPackage Get-RDWebClientBrokerCert

Also confirm in Server Manager → Remote Desktop Services → Overview that:

RD Web Access

RD Connection Broker

RD Session Host

are all listed and healthy.

Please collect the following logs for deeper analysis:

%ProgramData%\RDWebClientManagement\Logs

IIS logs for /RDWeb/webclient

Event Viewer → Applications and Services Logs → Microsoft → Windows → TerminalServices-WebAccess

We’ll review these to identify the root cause.
Misko Stanivukovich 25 Reputation points

2025-08-21T08:10:21.79+00:00

Just to give to additional Info:

C:\Windows\Web\RDWeb there was no webclient folder so web.config file is created for RDweb but since there is no folder webclinet what will the page see...

I have created webclient folder but it is empty
Misko Stanivukovich 25 Reputation points

2025-08-21T09:45:05.69+00:00

As I see

PS C:\Windows\system32> Get-RDWebClientPackage

packageId : rd-html5

version : 2.1.65.0

author : Microsoft

summary : The Remote Desktop Web Client

minRDWebClientManagementVersion : 1.0.4

path : C:\Program Files\RemoteDesktopWeb\Internal\Clients\lkqnbcmz.vwy

_baseVersion : 2.1.65.0

publishedAs : {Production}
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-21T09:59:04.19+00:00
Hi Misko Stanivukovich,
Based on your findings, the RDWeb/webclient folder was manually created and is currently empty, which explains why the site isn’t working and why no logs are being generated.

Let’s fix this by resetting the Web Client deployment. Please make sure to run these steps on the RD Web Access server (the one hosting https://<FQDN>/RDWeb):

Recovery Steps

Delete the empty folder:

Windows Command PromptCopy

Remove-Item "C:\Windows\Web\RDWeb\webclient" -Recurse -Force

Re-import the Broker certificate (if not already done):

Windows Command PromptCopy

Import-RDWebClientBrokerCert "C:\Path\To\Broker.cer"

Re-publish the Web Client:

Windows Command PromptCopy

Publish-RDWebClientPackage -Type Production -Latest

Restart IIS:

Windows Command PromptCopy

iisreset /noforce

After completing the steps:

Confirm that C:\Windows\Web\RDWeb\webclient now contains files like index.html and web.config.

Check that %ProgramData%\RDWebClientManagement\Logs exists (this indicates the publish ran successfully).

You should also see Event Viewer entries under Applications and Services Logs → Microsoft → Windows → TerminalServices-WebAccess.

Once this is done, try loading https://<FQDN>/RDWeb/webclient/ again. If the page loads but shows “no resources assigned,” we’ll continue investigating the feed and permissions.
Misko Stanivukovich 25 Reputation points

2025-08-21T11:12:56.0866667+00:00
I have done the procedure, the steps bellow are no created

Confirm that C:\Windows\Web\RDWeb\webclient now contains files like index.html and web.config.

Check that %ProgramData%\RDWebClientManagement\Logs exists (this indicates the publish ran successfully).

You should also see Event Viewer entries under Applications and Services Logs → Microsoft → Windows → TerminalServices-WebAccess.
Misko Stanivukovich 25 Reputation points

2025-08-21T12:28:19.1+00:00
PS C:\Windows\system32> Install-Module -Name RDWebClientManagement -Force

PackageManagement\Install-Package : License Acceptance is required for module 'RDWebClientManagement'. Please specify '-AcceptLicense' to perform this operation.

At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.2.5\PSModule.psm1:9711 char:34

... talledPackages = PackageManagement\Install-Package @PSBoundParameters

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo : InvalidArgument: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Exception

FullyQualifiedErrorId : ForceAcceptLicense,Install-PackageUtility,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-22T03:52:07.2+00:00
Hi Misko Stanivukovich,

Thanks for the update. Based on your output, it looks like the Web Client module wasn’t installed correctly, which is why the publish step didn’t actually run and the folder is still empty.

Let’s go through the corrected steps to fix this. Please follow them exactly as written, and make sure you’re running PowerShell as Administrator on the RD Web Access server.

Install the RDWebClientManagement module with license acceptance:

Install-Module -Name RDWebClientManagement -Force -AcceptLicense

Verify the module is installed:

Get-Command -Module RDWebClientManagement

You should see commands like Publish-RDWebClientPackage listed.

Delete the empty folder (if it still exists):

Remove-Item "C:\Windows\Web\RDWeb\webclient" -Recurse -Force

Re-import the Broker certificate (if not already done):

Replace the path with the actual location of your .cer file:

Import-RDWebClientBrokerCert "C:\Path\To\Broker.cer"

Re-publish the Web Client:

Publish-RDWebClientPackage -Type Production -Latest

Restart IIS:

iisreset /noforce

After Completing the Steps

Please confirm the following:

The folder C:\Windows\Web\RDWeb\webclient now contains files like:

index.html

web.config

The folder %ProgramData%\RDWebClientManagement\Logs exists.

Event Viewer has new entries under: Applications and Services Logs →Microsoft →Windows →TerminalServices-WebAccess

Once these are in place, try accessing the Web Client again. If the page loads but shows “no resources assigned,” we’ll continue with feed and permission checks.

Let me know how it goes!
Misko Stanivukovich 25 Reputation points

2025-08-22T07:19:45.6233333+00:00

The command works but still no web client created

Function Find-RDWebClientPackage 1.0.4 RDWebClientManagement

Function Get-RDWebClientBrokerCert 1.0.4 RDWebClientManagement

Function Get-RDWebClientDeploymentSetting 1.0.4 RDWebClientManagement

Function Get-RDWebClientPackage 1.0.4 RDWebClientManagement

Function Import-RDWebClientBrokerCert 1.0.4 RDWebClientManagement

Function Install-RDWebClientPackage 1.0.4 RDWebClientManagement

Function Publish-RDWebClientPackage 1.0.4 RDWebClientManagement

Function Remove-RDWebClientBrokerCert 1.0.4 RDWebClientManagement

Function Reset-RDWebClientDeploymentSetting 1.0.4 RDWebClientManagement

Function Save-RDWebClientPackage 1.0.4 RDWebClientManagement

Function Set-RDWebClientDeploymentSetting 1.0.4 RDWebClientManagement

Function Uninstall-RDWebClient 1.0.4 RDWebClientManagement

Function Uninstall-RDWebClientPackage 1.0.4 RDWebClientManagement

Function Unpublish-RDWebClientPackage 1.0.4 RDWebClientManagement
Misko Stanivukovich 25 Reputation points

2025-08-22T09:11:25.49+00:00
Nothing is created yet

The folder C:\Windows\Web\RDWeb\webclient now contains files like:

index.html

web.config

The folder %ProgramData%\RDWebClientManagement\Logs exists.

Event Viewer has new entries under: Applications and Services Logs →Microsoft →Windows →TerminalServices-WebAccess
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-22T09:13:43.5533333+00:00
Hi Misko Stanivukovich,

Thanks for confirming the command output.

Good news: the RDWebClientManagement module is fully installed and functional.

Since the Web Client folder still isn’t being created, let’s double-check a few key areas to make sure the publish step completes successfully. Please go through these steps and let me know what you find:

Confirm the Broker Certificate is Valid

Run this command:

Get-RDWebClientBrokerCert

Make sure it returns a valid certificate, and that it’s not expired. If you’re unsure, you can re-import it using:

Import-RDWebClientBrokerCert "C:\Path\To\Broker.cer"

Run Publish with Verbose Output

This helps us catch any silent errors:

Publish-RDWebClientPackage -Type Production -Latest -Verbose

Please copy and share any warnings or errors you see.

Check if the Web Client Folder Was Created

After publishing, check if this folder exists and contains files like index.html:

C:\Windows\Web\RDWeb\webclient

Check for Logs

Look for this folder:

%ProgramData%\RDWebClientManagement\Logs

If it exists, open the latest log file and check for any errors during publish.

Check Event Viewer

Go to:

Applications and Services Logs → Microsoft → Windows → TerminalServices-WebAccess

Look for any errors or warnings around the time you ran the publish command.

Once we have this info, we’ll know whether the publish step is failing silently or being blocked by something environmental.
Misko Stanivukovich 25 Reputation points

2025-08-22T09:20:45.69+00:00

PS C:\Windows\system32> Get-RDWebClientBrokerCert

Thumbprint Subject

2B0D9F7F9850222BD771EDB4C54CF211340D6XXX CN=tc-testlab.tecm.xxx.xxx, O=XXX-XXX (European Space Research and Techn...

PS C:\Windows\system32> Publish-RDWebClientPackage -Type Production -Latest -Verbose

VERBOSE: Performing the operation "Publish alongside Remote Desktop Web Access" on target "The Remote Desktop web

client package".

WARNING: The requested package has already been published for this client type.

All is ok with the certificate but the folder is still not created
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-22T09:32:14.7766667+00:00
Hi Misko Stanivukovich,

Since the system reports that the package is already published but the folder still doesn’t exist, we may be dealing with a corrupted or incomplete deployment.

Let’s do a clean reset to clear any stale settings and re-deploy the Web Client properly. Please follow these steps on the RD Web Access server, with PowerShell run as Administrator:

Clean Reset Steps (Run on RD Web Access Server)

Unpublish the Web Client:

Unpublish-RDWebClientPackage -Type Production

Uninstall the Web Client package:

Uninstall-RDWebClientPackage -Type Production

Reset deployment settings:

Reset-RDWebClientDeploymentSetting

Delete any leftover folder manually:

Remove-Item "C:\Windows\Web\RDWeb\webclient" -Recurse -Force

Re-import the Broker certificate (if needed):

Import-RDWebClientBrokerCert "C:\Path\To\Broker.cer"

Reinstall and publish the Web Client:

Install-RDWebClientPackage -Type Production Publish-RDWebClientPackage -Type Production -Latest -Verbose

Restart IIS:

iisreset /noforce

After completing these steps, please confirm:

The folder C:\Windows\Web\RDWeb\webclient now exists and contains files like index.html.

Logs are present at %ProgramData%\RDWebClientManagement\Logs.

Event Viewer has new entries under Applications and Services Logs → Microsoft → Windows → TerminalServices-WebAccess.

Let’s see if this clears things up!
Misko Stanivukovich 25 Reputation points

2025-08-22T09:42:24.45+00:00
PS C:\Windows\system32> Unpublish-RDWebClientPackage -Type Production

Cannot convert the "Default Web Site/RDWeb/webclient" value of type "Microsoft.Web.Administration.VirtualDirectory" to type "Microsoft.Web.Administration.VirtualDirectory".

At C:\Program Files\WindowsPowerShell\Modules\RDWebClientManagement\1.0.4\RDWebClientManagement.psm1:1032 char:9

$targetVdir = $iisContext.ProdClientVdir

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo : MetadataError: (:) [], ArgumentTransformationMetadataException

FullyQualifiedErrorId : RuntimeException

Cannot convert the "Default Web Site/RDWeb/webclient/config" value of type "Microsoft.Web.Administration.VirtualDirectory" to type "Microsoft.Web.Administration.VirtualDirectory".

At C:\Program Files\WindowsPowerShell\Modules\RDWebClientManagement\1.0.4\RDWebClientManagement.psm1:1033 char:9

$targetConfigVdir =$iisContext.ProdClientConfigVdir

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo : MetadataError: (:) [], ArgumentTransformationMetadataException

FullyQualifiedErrorId : RuntimeException

Unpublish-RDWebClientPackage : The requested client type is not published.

At line:1 char:1

Unpublish-RDWebClientPackage -Type Production

+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Unpublish-RDWebClientPackage

PS C:\Windows\system32> Uninstall-RDWebClientPackage -Type Production

Uninstall-RDWebClientPackage : A parameter cannot be found that matches parameter name 'Type'.

At line:1 char:30

Uninstall-RDWebClientPackage -Type Production

~~~~~

CategoryInfo : InvalidArgument: (:) [Uninstall-RDWebClientPackage], ParameterBindingException

FullyQualifiedErrorId : NamedParameterNotFound,Uninstall-RDWebClientPackage
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-22T09:56:54.4366667+00:00
Hi Misko Stanivukovich,

Thanks for sharing the error output - this gives us a much clearer picture of what’s happening.

You received the following errors when trying to unpublish and uninstall the Web Client:

Unpublish-RDWebClientPackage Error

Cannot convert the "Default Web Site/RDWeb/webclient" value of type "Microsoft.Web.Administration.VirtualDirectory" to type "Microsoft.Web.Administration.VirtualDirectory". Unpublish-RDWebClientPackage : The requested client type is not published.

This means the Web Client was never successfully published, and the IIS configuration is likely incomplete or corrupted. The module is trying to access virtual directories that don’t exist.

Uninstall-RDWebClientPackage Error

Uninstall-RDWebClientPackage : A parameter cannot be found that matches parameter name 'Type'.

This is a syntax issue — the Uninstall-RDWebClientPackage cmdlet does not accept a -Type parameter.

What To Do Next

Let’s clean up and re-deploy the Web Client properly. Please run the following commands on the RD Web Access server, with PowerShell opened as Administrator:

Clean Reset Steps

Uninstall the Web Client package (correct syntax):

Uninstall-RDWebClientPackage

Reset deployment settings:

Reset-RDWebClientDeploymentSetting

Delete any leftover folder manually:

Remove-Item "C:\Windows\Web\RDWeb\webclient" -Recurse -Force

Re-import the Broker certificate (if needed):

Import-RDWebClientBrokerCert "C:\Path\To\Broker.cer"

Reinstall and publish the Web Client:

Install-RDWebClientPackage -Type Production Publish-RDWebClientPackage -Type Production -Latest -Verbose

Restart IIS:

iisreset /noforce

After completing these steps, please confirm:

The folder C:\Windows\Web\RDWeb\webclient now exists and contains files like index.html.

Logs are present at %ProgramData%\RDWebClientManagement\Logs.

Event Viewer has new entries under Applications and Services Logs → Microsoft → Windows → TerminalServices-WebAccess.

Let’s see if this clears up the issue!
Misko Stanivukovich 25 Reputation points

2025-08-22T10:04:29.7066667+00:00
Again I have error ussing

cmdlet Uninstall-RDWebClientPackage at command pipeline position 1

Supply values for the following parameters:

RequiredVersion: 1.0.4 - I have enter this version from the logs

Uninstall-RDWebClientPackage : The requested client package is not installed.

At line:1 char:1

Uninstall-RDWebClientPackage

+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Uninstall-RDWebClientPackage
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-22T10:25:18.1233333+00:00
Hi Misko Stanivukovich,

Thanks for confirming - this tells us the Web Client package was never actually installed, which explains why the publish step isn’t creating any files.

Let’s go ahead and install it cleanly. Please run the following commands on the RD Web Access server, with PowerShell opened as Administrator:

Install and Publish the Web Client

Install the Web Client package:

Install-RDWebClientPackage -Type Production

Publish the Web Client:

Publish-RDWebClientPackage -Type Production -Latest -Verbose

Restart IIS:

iisreset /noforce

After this, please check:

Does the folder C:\Windows\Web\RDWeb\webclient now exist?

Are there files like index.html and web.config inside?

Are there logs at %ProgramData%\RDWebClientManagement\Logs?

Are there new entries in Event Viewer under TerminalServices-WebAccess?

Let’s see if this finally gets the Web Client deployed!
Misko Stanivukovich 25 Reputation points

2025-08-22T11:33:59.01+00:00
Sorry again error

PS C:\Windows\system32> Install-RDWebClientPackage -Type Production

Install-RDWebClientPackage : A parameter cannot be found that matches parameter name 'Type'.

At line:1 char:28

Install-RDWebClientPackage -Type Production

~~~~~

CategoryInfo : InvalidArgument: (:) [Install-RDWebClientPackage], ParameterBindingException

FullyQualifiedErrorId : NamedParameterNotFound,Install-RDWebClientPackage
Misko Stanivukovich 25 Reputation points

2025-08-25T07:03:50.4966667+00:00

Can you give me suggestion on this also
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-26T03:42:46.58+00:00
Hi Misko Stanivukovich,

Sorry for the late response.
Thank you for sharing the error details. The message:

A parameter cannot be found that matches parameter name 'Type'

indicates that the Remote Desktop Services PowerShell module on your server does not recognize the -Type parameter. This usually happens when the server is running an older RDS build or missing recent cumulative updates.

Why this happens

On Windows Server 2019, the -Type parameter was introduced in later updates.

If the server is not fully updated, the cmdlet will only support the basic syntax without -Type

What to do next

Check and install the latest updates

Make sure your server has the latest cumulative updates installed. You can check recent updates with:

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

If updates are missing, please install them and restart the server.

Run the commands without -Type Even without the parameter, the installation will work:

Install-RDWebClientPackage Publish-RDWebClientPackage -Latest -Verbose iisreset /noforce

Verify the installation

Folder exists: C:\Windows\Web\RDWeb\webclient

Files like index.html and web.config are present

Logs at %ProgramData%\RDWebClientManagement\Logs

Event Viewer → Applications and Services Logs > Microsoft > Windows > TerminalServices-WebAccess

If you still run into issues after these steps, please let me know, and we can move to advanced checks.
Misko Stanivukovich 25 Reputation points

2025-08-26T07:13:48.36+00:00
PS C:\Windows\system32> Install-RDWebClientPackage

WARNING: The requested Remote Desktop web client is already installed.

PS C:\Windows\system32> Publish-RDWebClientPackage -Latest -Verbose

cmdlet Publish-RDWebClientPackage at command pipeline position 1

Supply values for the following parameters:

Type: 1 - I have put it one and I have error messages as last time

Publish-RDWebClientPackage : Cannot validate argument on parameter 'Type'. The argument "1" does not belong to the set

"Test,Production" specified by the ValidateSet attribute. Supply an argument that is in the set and then try the

command again.

At line:1 char:1

Publish-RDWebClientPackage -Latest -Verbose

+ CategoryInfo : InvalidData: (:) [Publish-RDWebClientPackage], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationError,Publish-RDWebClientPackage

PS C:\Windows\system32>
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-26T08:45:10.36+00:00
Hi Misko Stanivukovich,

Thanks for the details. The message you’re seeing is just a parameter validation prompt—nothing is wrong with the install.

Publish-RDWebClientPackage requires a -Type value. Because it wasn’t provided, PowerShell asked for it and a value of 1 was entered. The cmdlet only accepts Production or Test, so it rejected 1.

Please run one of the following (no prompts, no errors):

Publish to production (recommended):

Publish-RDWebClientPackage -Type Production -Latest -Verbose

Or publish a test build first:

Publish-RDWebClientPackage -Type Test -Latest -Verbose

Production URL: https://<FQDN>/RDWeb/webclient/index.html Test URL: https://<FQDN>/RDWeb/webclient-test/index.html

If you haven’t imported the broker certificate yet, please do that once before publishing:

Import-RDWebClientBrokerCert "C:\Path\to\broker.cer"

Then rerun the publish command above.

Quick validation

Get-Module RDWebClientManagement -ListAvailable | Select Name,Version Get-Command Publish-RDWebClientPackage -Syntax

This will confirm the module and show the valid -Type values (Production/Test).

Read this for better visual for the installation steps:
https://woshub.com/rds-html5-web-client/

Once -Type Production succeeds, browse to /RDWeb/webclient and sign in. If anything still looks off, send me a screenshot and I’ll take the next steps.
Misko Stanivukovich 25 Reputation points

2025-08-26T09:21:16+00:00

Hello,

I have already give answer on this commands they dont work

Publish-RDWebClientPackage -Type Production -Latest -Verbose

VERBOSE: Performing the operation "Publish alongside Remote Desktop Web Access" on target "The Remote Desktop web

client package".

WARNING: The requested package has already been published for this client type.

All the time it is reporting that the package is installed and I cannot uninstalled because on the end it is not installed
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-26T09:28:36.8833333+00:00
Hi Misko Stanivukovich,

Check the WebClient folder

Confirm if C:\Windows\Web\RDWeb\WebClient exists and has content.

Remove the stale publish state

Try:

Uninstall-RDWebClientPackage -Type Production -Verbose

If that fails, use:

Remove-RDWebClientPackage -Type Production -Force

(If this cmdlet isn’t available, we’ll do a manual cleanup.)

Manual cleanup if needed

Delete the WebClient folder manually if it’s empty or broken.

Reinstall the module (optional but recommended)

Uninstall-Module RDWebClientManagement -Force Install-Module RDWebClientManagement -Force

Publish again

Publish-RDWebClientPackage -Type Production -Latest -Verbose
Misko Stanivukovich 25 Reputation points

2025-08-26T09:58:34.4633333+00:00

Hello I have updated the windows server 2019 but still type command is not working, the web client folder was never created
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-26T10:07:14.0133333+00:00
Hi Misko Stanivukovich,

If the folder does not exist, then just continue with these steps:
Remove the stale publish state

Try:

PowerShellCopy

Uninstall-RDWebClientPackage -Type

If that fails, use:

PowerShellCopy

Remove-RDWebClientPackage -Type

(If this cmdlet isn’t available, we’ll do a manual cleanup.)

Manual cleanup if needed

Delete the WebClient folder manually if it’s empty or broken.

Reinstall the module (optional but recommended)

Uninstall-Module

Publish again

Publish-RDWebClientPackage -Type

Validate

Browse to /RDWeb/webclient and confirm it loads.
Misko Stanivukovich 25 Reputation points

2025-08-26T11:22:50.47+00:00

Thanks for the help I have stated above -Type is not recognized command from power shell
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-27T02:11:32.9233333+00:00
Hi Misko Stanivukovich,

I'm sorry for my response.

Thanks for confirming. The reason -Type isn’t recognized is that your RDWebClientManagement module is outdated or missing. This parameter was introduced in later versions, so the publish/uninstall commands won’t work until the module is updated.

Check current version

Get-Module RDWebClientManagement -ListAvailable | Select Name,Version

Update the module

Install-Module PowerShellGet -Force Install-Module RDWebClientManagement -Force

Verify syntax

Get-Command Publish-RDWebClientPackage -Syntax

You should now see -Type <Production | Test>.

Publish again

Publish-RDWebClientPackage -Type Production -Latest -Verbose

If the update fails, ensure TLS 1.2 is enabled:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Once the module is updated, the commands will work and the WebClient folder will be created.
Misko Stanivukovich 25 Reputation points

2025-08-27T08:52:54.5033333+00:00

Hello,

PS C:\Windows\system32> Get-Module RDWebClientManagement -ListAvailable | Select Name,Version

Name Version

RDWebClientManagement 1.0.4

PS C:\Windows\system32> Install-Module PowerShellGet -Force

WARNING: The version '1.4.8.1' of module 'PackageManagement' is currently in use. Retry the operation after closing the applications.

PS C:\Windows\system32>
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-27T09:25:58.3566667+00:00
Hi Misko Stanivukovich,

This warning is actually quite common when updating PowerShell modules:

WARNING: The version '1.4.8.1' of module 'PackageManagement' is currently in use. Retry the operation after closing the applications.

PowerShell is telling us that the PackageManagement module is already loaded into memory, likely by the current PowerShell session or another tool like PowerShell ISE (Integrated Scripting Environment). Because of that, it can’t overwrite or update the module until it’s fully released.

This prevents the update of PowerShellGet, which in turn blocks the update of RDWebClientManagement. That’s why you’re still seeing version 1.0.4, which doesn’t support the -Type parameter.

Close all PowerShell windows, including PowerShell ISE or any script editors.

Reopen PowerShell as Administrator.

Run the following commands:

Install-Package PackageManagement -Force Install-Module PowerShellGet -Force Install-Module RDWebClientManagement -Force

If the issue persists, reboot the machine and retry the steps above.

You can verify the update worked by running:

Get-Module RDWebClientManagement -ListAvailable | Select Name,Version

You should now see a version like 1.0.6 or higher, and the -Type parameter will be available.
Misko Stanivukovich 25 Reputation points

2025-08-27T10:04:17.64+00:00

Hello, Sorry I did everything close all app from power shell reboot the pc same message again

WARNING: The version '1.4.8.1' of module 'PackageManagement' is currently in use. Retry the operation after closing the

applications.

PS C:\Windows\system32> Get-Module RDWebClientManagement -ListAvailable | Select Name,Version

Name Version

RDWebClientManagement 1.0.4
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-27T10:38:16.7933333+00:00
Hi Misko Stanivukovich,

Let’s try a few deeper cleanup steps to fully release the module:

Step 1: Check if the module is loaded

Open PowerShell as Administrator and run:

Get-Module PackageManagement

If it returns anything, run:

Remove-Module PackageManagement

Step 2: Use a clean PowerShell session

Launch PowerShell with no profile scripts:

powershell.exe -NoProfile -ExecutionPolicy Bypass

Then run:

Install-Package PackageManagement -Force Install-Module PowerShellGet -Force Install-Module RDWebClientManagement -Force

Step 3: Manual cleanup (if needed)

If the issue still persists:

C:\Program Files\WindowsPowerShell\Modules\PackageManagement

Rename or delete the folder 1.4.8.1 (you may need to stop services or take ownership).

Reboot the machine.

Retry the install commands from step 2.

After installation, confirm the RDWebClientManagement version:

Get-Module RDWebClientManagement -ListAvailable | Select Name,Version
Misko Stanivukovich 25 Reputation points

2025-08-27T11:53:09.68+00:00

Ok now it is like this

PS C:\Windows\system32> Install-Package PackageManagement -Force

Name Version Source Summary

PackageManagement 1.4.8.1 PSGallery PackageManagement (a.k.a. OneGet) is a new way to discover and install software packages from around the web....

He is installing same version after deleting

and also

Install-Module -Name RDWebClientManagement -Force

PS C:\Windows\system32> Get-Module RDWebClientManagement -ListAvailable | Select Name,Version

Name Version

RDWebClientManagement 1.0.4

Same version installing not 1.0.6
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-28T04:37:43.6066667+00:00
Hi Misko Stanivukovich,

Thanks for the update — it looks like we’re making solid progress!

Since RDWebClientManagement 1.0.6 is still not installing, it likely means PowerShell is either:

Pulling from a cached or outdated PSGallery index,

Or unable to reach the latest version due to proxy, TLS, or NuGet provider issues.

Please try the following in an elevated PowerShell session:

Ensure PSGallery is trusted and reachable

Get-PSRepository Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted

Update NuGet and PowerShellGet

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 Install-PackageProvider -Name NuGet -Force Update-Module PowerShellGet -Force

Try installing the latest version explicitly

Install-Module RDWebClientManagement -RequiredVersion 1.0.6 -Force

Verify the installed version

Get-Module RDWebClientManagement -ListAvailable | Select Name, Version

If version 1.0.6 still doesn’t appear, please run:

Find-Module RDWebClientManagement

This will show what versions are available from PSGallery and help us confirm if the issue is environmental.
Misko Stanivukovich 25 Reputation points

2025-08-28T06:18:43.2633333+00:00
PS C:\Windows\system32> Get-PSRepository

Name InstallationPolicy SourceLocation

PSGallery Untrusted https://www.powershellgallery.com/api/v2

PS C:\Windows\system32> Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted

PS C:\Windows\system32> Get-PSRepository

Name InstallationPolicy SourceLocation

PSGallery Trusted https://www.powershellgallery.com/api/v2

PS C:\Windows\system32> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

PS C:\Windows\system32> Install-PackageProvider -Name NuGet -Force

Name Version Source Summary

nuget 2.8.5.208 https://cdn.o... NuGet provider for the OneGet meta-package manager

PS C:\Windows\system32> Update-Module PowerShellGet -Force

WARNING: The version '1.4.8.1' of module 'PackageManagement' is currently in use. Retry the operation after closing the

applications.

PS C:\Windows\system32> Install-Module RDWebClientManagement -RequiredVersion 1.0.6 -Force

PackageManagement\Install-Package : No match was found for the specified search criteria and module name

'RDWebClientManagement'. Try Get-PSRepository to see all available registered module repositories.

At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.2.5\PSModule.psm1:9711 char:34

... talledPackages = PackageManagement\Install-Package @PSBoundParameters

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Ex

ception

FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

PS C:\Windows\system32> Get-Module RDWebClientManagement -ListAvailable | Select Name, Version

Name Version

RDWebClientManagement 1.0.4

PS C:\Windows\system32> Find-Module RDWebClientManagement

Version Name Repository Description

1.0.4 RDWebClientManagement PSGallery Manage the download and deployment of ...

PS C:\Windows\system32>
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-28T07:26:09.47+00:00
Hi Misko Stanivukovich,

Step 1: Confirm PowerShellGet version

Run:

Get-Module PowerShellGet -ListAvailable | Select Name, Version

You need at least version 2.2.5. If it's older, update manually:

Install-Module PowerShellGet -RequiredVersion 2.2.5 -Force

If this fails again due to PackageManagement lock, try:

Remove-Module PackageManagement

Then retry the install.

Step 2: Bypass TLS/Proxy Issues

Try downloading the module manually:

Go to RDWebClientManagement on PowerShell Gallery

Download the .nupkg file for version 1.0.6

Extract it and place it in:

C:\Program Files\WindowsPowerShell\Modules\RDWebClientManagement\1.0.6

Then verify:

Get-Module RDWebClientManagement -ListAvailable | Select Name, Version

Step 3: Reset PowerShell Gallery Source (Optional)

Sometimes the PSGallery source gets corrupted. You can reset it:

Unregister-PSRepository -Name PSGallery Register-PSRepository -Default

Then retry:

Find-Module RDWebClientManagement

This is a common but annoying issue, especially in enterprise environments with proxies or security filtering. Manual install is often the fastest workaround.
Misko Stanivukovich 25 Reputation points

2025-08-28T08:08:58.2966667+00:00

Sorry when I extract the file I see files that are different then on existing webclientmanagement
Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-28T08:43:10.3133333+00:00
Hi Misko Stanivukovich,

Based on your message, it looks like the files you're seeing after extracting the .nupkg are different from the existing RDWebClientManagement module folder. That’s expected — the .nupkg is a NuGet package container, not the final module layout.

To resolve this:

Manual Install Steps Recap

Rename the .nupkg to .zip Example:

Rename-Item -Path "RDWebClientManagement.1.0.6.nupkg" -NewName "RDWebClientManagement.1.0.6.zip"

Extract the ZIP, then go into the package folder inside it.

Copy the contents of the package folder (not the whole ZIP) to:

C:\Program Files\WindowsPowerShell\Modules\RDWebClientManagement\1.0.6

Then verify:

Get-Module RDWebClientManagement -ListAvailable | Select Name, Version

This should match the structure of your existing module folder and allow the Web Client management cmdlets to load properly.

If the manual steps still don’t resolve the issue, I truly apologize for the inconvenience. I understand how frustrating it can be to troubleshoot this kind of issue — especially through Microsoft Q&A, which isn’t ideal for complex cases involving module installation, environment-specific errors, or log analysis.

To get faster and more effective help, I strongly recommend opening a Microsoft support ticket. This will connect you directly with our support engineers who can securely collect logs, analyze your setup, and provide tailored guidance.

https://support.microsoft.com/en-in/contactus/

(You’ll need to sign in with your Microsoft account. Once logged in, scroll to the bottom-right corner and click Help & Support, then choose Contact Us.)

Note for free users: If you're using a free Microsoft account (e.g., personal, education, or developer), support options may be limited. You can still try contacting support via the portal above, or use Microsoft’s general support page to explore available channels like live chat or callback.

I’m really sorry this has been such a frustrating and disappointing experience but right now your case requires more professional and deep-dive help. A support case is the best way to move forward quickly and get the help you deserve. I hope you the best in the future.

Answer 3

The Yaml it doesn't exist

#Software: Microsoft Internet Information Services 10.0

#Version: 1.0

#Date: 2025-08-19 08:27:55

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken

2025-08-19 08:27:55 131.176.170.130 GET /RDWeb/webclient - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36 - 401 2 5 2

2025-08-19 08:28:06 131.176.170.130 GET /RDWeb/webclient - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36 - 401 2 5 0

2025-08-19 08:28:06 131.176.170.130 GET /RDWeb/webclient - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36 - 401 1 3221225581 0

2025-08-19 08:28:29 131.176.170.130 GET /RDWeb/webclient - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36 - 401 2 5 0

2025-08-19 08:28:29 131.176.170.130 GET /RDWeb/webclient - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36 - 401 1 3221225581 1

2025-08-19 08:28:37 131.176.170.130 GET /RDWeb/webclient - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36 - 401 2 5 0

2025-08-19 08:28:37 131.176.170.130 GET /RDWeb/webclient - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36 - 401 1 3221225581 0

#Software: Microsoft Internet Information Services 10.0

#Version: 1.0

#Date: 2025-08-19 08:31:59

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/en-US/login.aspx ReturnUrl=/RDWeb/Pages/en-US/default.aspx 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 200 0 0 1642

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/Site.xsl - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 4

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/en-US/RDWAStrings.xml - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 2

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/en-US/tswa.css - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 2

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/renderscripts.js - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 2

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/webscripts-domain.js - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 2

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/logo_01.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 5

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/logo_02.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 5

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/bar_03.jpg - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 4

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/WS_h_c.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 2

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/mslogo_black.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 2

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/top_mid.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 2

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/bg_globe_01.jpg - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/tswa.css 200 0 0 3

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/top_right.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 2

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/top_left.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 3

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/left_mid.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 1

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/banner_01.jpg - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 1

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/banner_02.jpg - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 1

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/bottom_mid.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 2

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/right_mid.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 1

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/bottom_left.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 1

2025-08-19 08:31:59 131.176.170.130 GET /RDWeb/Pages/images/bottom_right.png - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 200 0 0 1

2025-08-19 08:32:00 131.176.170.130 GET /favicon.ico - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/default.aspx 401 2 5 1132

2025-08-19 08:32:14 131.176.170.130 GET /RDWeb/webclient/ - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 2 5 101

2025-08-19 08:32:28 131.176.170.130 GET /RDWeb/webclient/ - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 2 5 0

2025-08-19 08:32:28 131.176.170.130 GET /RDWeb/webclient/ - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 1 3221225581 1

2025-08-19 08:32:46 131.176.170.130 GET /RDWeb/webclient/ - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 2 5 0

2025-08-19 08:32:46 131.176.170.130 GET /RDWeb/webclient/ - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 1 3221225581 1

2025-08-19 08:32:52 131.176.170.130 GET /RDWeb/webclient/ - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 2 5 0

2025-08-19 08:32:52 131.176.170.130 GET /favicon.ico - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/RDWeb/webclient/ 401 2 5 0

2025-08-19 08:33:10 131.176.170.130 GET / - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 2 5 131

2025-08-19 08:33:23 131.176.170.130 GET / - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 2 5 1

2025-08-19 08:33:23 131.176.170.130 GET / - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 1 3221225581 1

2025-08-19 08:33:33 131.176.170.130 GET / - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 2 5 0

2025-08-19 08:33:33 131.176.170.130 GET / - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 1 3221225581 1

2025-08-19 08:33:39 131.176.170.130 GET / - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 2 5 0

2025-08-19 08:33:39 131.176.170.130 GET / - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 1 3221225581 1

2025-08-19 08:34:06 131.176.170.130 GET / - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 - 401 2 5 1

2025-08-19 08:34:06 131.176.170.130 GET /favicon.ico - 443 - 131.176.170.130 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36+Edg/139.0.0.0 https://tc-testlab.tecm.esa.int/ 401 2 5 0

Subject:

Security ID:		NULL SID

Account Name:		-

Account Domain:		-

Logon ID:		0x0

Logon Type: 3

Account For Which Logon Failed:

Security ID:		NULL SID

Account Name:		test

Account Domain:		DC01

Failure Information:

Failure Reason:		An Error occured during Logon.

Status:			0xC000006D

Sub Status:		0x0

Process Information:

Caller Process ID:	0x0

Caller Process Name:	-

Network Information:

Workstation Name:	TC-TESTLAB

Source Network Address:	131.176.170.130

Source Port:		50022

Detailed Authentication Information:

Logon Process:		

Authentication Package:	NTLM

Transited Services:	-

Package Name (NTLM only):	-

Key Length:		0

Answer 4

Misko Stanivukovich 25

Logs:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken

2025-08-21 07:57:19 131.176.170.XXX POST /RDWeb/Pages/en-US/login.aspx - 443 dc01\tecmit 131.176.170.XXX Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36 https://tc-testlab.tecm.esa.int/RDWeb/webclient/ 302 0 0 17

For Event Viewer logs under Applications and Services Logs → Microsoft → Windows → TerminalServices-WebAccess I dont see folder with that name

Also for %ProgramData%\RDWebClientManagement\Logs no folder for Rd

Tom Tran (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff

2025-08-21T08:48:16.6533333+00:00
Hi Misko Stanivukovich,

Based on your findings, the RDWeb/webclient folder was manually created and is currently empty, which explains why the site isn’t working and why no logs are being generated.

Let’s fix this by resetting the Web Client deployment. Please make sure to run these steps on the RD Web Access server (the one hosting https://<FQDN>/RDWeb):

Recovery Steps

Delete the empty folder:

Remove-Item "C:\Windows\Web\RDWeb\webclient" -Recurse -Force

Re-import the Broker certificate (if not already done):

Import-RDWebClientBrokerCert "C:\Path\To\Broker.cer"

Re-publish the Web Client:

Publish-RDWebClientPackage -Type Production -Latest

Restart IIS:

iisreset /noforce

After this, the Web Client folder will be recreated with the correct files, and the site should load properly. You should also see:

Confirm that C:\Windows\Web\RDWeb\webclient now contains files like index.html and web.config.

Check that %ProgramData%\RDWebClientManagement\Logs exists (this indicates the publish ran successfully).

You should also see Event Viewer entries under Applications and Services Logs → Microsoft → Windows → TerminalServices-WebAccess.

Let me know once this is done and we’ll continue investigating the “no resources assigned” message.

Share via

can't log on HTML5 web site

4 answers

Your answer