Rd Client Not Connecting

Posted on by admin



RDS Client not connecting. On Apr 3, 2020 at 10:39 UTC. Solved Microsoft Remote Desktop Services. Next: Remote Desktop not launching ready for. Try connecting with another client, like Remote Desktop client for Windows 7 or Windows 10, and check to see if you can open the web client. Can't open other websites while connected to the web client If you can't open other websites while you're connected to the web client, there might be network connection problems or a network outage. Double click on the “Remote Desktop Connection Client” and then double click on the “Turn off UDP on Client” option. Check the “Enabled” button and save changes. Exit out of the Group Policy manager and then check to see if the issue persists.

-->

Use these steps when a Remote Desktop client can't connect to a remote desktop but doesn't provide messages or other symptoms that would help identify the cause.

Check the status of the RDP protocol

Check the status of the RDP protocol on a local computer

To check and change the status of the RDP protocol on a local computer, see How to enable Remote Desktop.

Note

If the remote desktop options are not available, see Check whether a Group Policy Object is blocking RDP.

Check the status of the RDP protocol on a remote computer

Important

Follow this section's instructions carefully. Serious problems can occur if the registry is modified incorrectly. Before you start modifying the registry, back up the registry so you can restore it in case something goes wrong.

To check and change the status of the RDP protocol on a remote computer, use a network registry connection:

  1. First, go to the Start menu, then select Run. In the text box that appears, enter regedt32.
  2. In the Registry Editor, select File, then select Connect Network Registry.
  3. In the Select Computer dialog box, enter the name of the remote computer, select Check Names, and then select OK.
  4. Navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal Server.
    • If the value of the fDenyTSConnections key is 0, then RDP is enabled.
    • If the value of the fDenyTSConnections key is 1, then RDP is disabled.
  5. To enable RDP, change the value of fDenyTSConnections from 1 to 0.

Check whether a Group Policy Object (GPO) is blocking RDP on a local computer

If you can't turn on RDP in the user interface or the value of fDenyTSConnections reverts to 1 after you've changed it, a GPO may be overriding the computer-level settings.

To check the group policy configuration on a local computer, open a Command Prompt window as an administrator, and enter the following command:

After this command finishes, open gpresult.html. In Computer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostConnections, find the Allow users to connect remotely by using Remote Desktop Services policy.

  • If the setting for this policy is Enabled, Group Policy is not blocking RDP connections.

  • If the setting for this policy is Disabled, check Winning GPO. This is the GPO that is blocking RDP connections.

Check whether a GPO is blocking RDP on a remote computer

To check the Group Policy configuration on a remote computer, the command is almost the same as for a local computer:

The file that this command produces (gpresult-<computer name>.html) uses the same information format as the local computer version (gpresult.html) uses.

Modifying a blocking GPO

Not

You can modify these settings in the Group Policy Object Editor (GPE) and Group Policy Management Console (GPM). For more information about how to use Group Policy, see Advanced Group Policy Management.

To modify the blocking policy, use one of the following methods:

  • In GPE, access the appropriate level of GPO (such as local or domain), and navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections > Allow users to connect remotely by using Remote Desktop Services.
    1. Set the policy to either Enabled or Not configured.
    2. On the affected computers, open a command prompt window as an administrator, and run the gpupdate /force command.
  • In GPM, navigate to the organizational unit (OU) in which the blocking policy is applied to the affected computers and delete the policy from the OU.

Check the status of the RDP services

On both the local (client) computer and the remote (target) computer, the following services should be running:

  • Remote Desktop Services (TermService)
  • Remote Desktop Services UserMode Port Redirector (UmRdpService)

You can use the Services MMC snap-in to manage the services locally or remotely. You can also use PowerShell to manage the services locally or remotely (if the remote computer is configured to accept remote PowerShell cmdlets).

On either computer, if one or both services are not running, start them.

Note

If you start the Remote Desktop Services service, click Yes to automatically restart the Remote Desktop Services UserMode Port Redirector service.

Check that the RDP listener is functioning

Important

Follow this section's instructions carefully. Serious problems can occur if the registry is modified incorrectly. Before you starty modifying the registry, back up the registry so you can restore it in case something goes wrong.

Check the status of the RDP listener

For this procedure, use a PowerShell instance that has administrative permissions. For a local computer, you can also use a command prompt that has administrative permissions. However, this procedure uses PowerShell because the same cmdlets work both locally and remotely.

  1. To connect to a remote computer, run the following cmdlet:

  2. Enter qwinsta.

  3. If the list includes rdp-tcp with a status of Listen, the RDP listener is working. Proceed to Check the RDP listener port. Otherwise, continue at step 4.

  4. Export the RDP listener configuration from a working computer.

    1. Sign in to a computer that has the same operating system version as the affected computer has, and access that computer's registry (for example, by using Registry Editor).
    2. Navigate to the following registry entry:
      HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp
    3. Export the entry to a .reg file. For example, in Registry Editor, right-click the entry, select Export, and then enter a filename for the exported settings.
    4. Copy the exported .reg file to the affected computer.

  5. To import the RDP listener configuration, open a PowerShell window that has administrative permissions on the affected computer (or open the PowerShell window and connect to the affected computer remotely).

    1. To back up the existing registry entry, enter the following cmdlet:

    2. To remove the existing registry entry, enter the following cmdlets:

    3. To import the new registry entry and then restart the service, enter the following cmdlets:

      Replace <filename> with the name of the exported .reg file.

  6. Test the configuration by trying the remote desktop connection again. If you still can't connect, restart the affected computer.

  7. If you still can't connect, check the status of the RDP self-signed certificate.

Check the status of the RDP self-signed certificate

  1. If you still can't connect, open the Certificates MMC snap-in. When you are prompted to select the certificate store to manage, select Computer account, and then select the affected computer.
  2. In the Certificates folder under Remote Desktop, delete the RDP self-signed certificate.
  3. On the affected computer, restart the Remote Desktop Services service.
  4. Refresh the Certificates snap-in.
  5. If the RDP self-signed certificate has not been recreated, check the permissions of the MachineKeys folder.

Check the permissions of the MachineKeys folder

  1. On the affected computer, open Explorer, and then navigate to C:ProgramDataMicrosoftCryptoRSA.
  2. Right-click MachineKeys, select Properties, select Security, and then select Advanced.
  3. Make sure that the following permissions are configured:
    • BuiltinAdministrators: Full control
    • Everyone: Read, Write

Check the RDP listener port

On both the local (client) computer and the remote (target) computer, the RDP listener should be listening on port 3389. No other applications should be using this port.

Important

Follow this section's instructions carefully. Serious problems can occur if the registry is modified incorrectly. Before you starty modifying the registry, back up the registry so you can restore it in case something goes wrong.

To check or change the RDP port, use the Registry Editor:

  1. Go to the Start menu, select Run, then enter regedt32 into the text box that appears.
    • To connect to a remote computer, select File, and then select Connect Network Registry.
    • In the Select Computer dialog box, enter the name of the remote computer, select Check Names, and then select OK.
  2. Open the registry and navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStations<listener>.
  3. If PortNumber has a value other than 3389, change it to 3389.

    Important

    You can operate Remote Desktop services using another port. However, we don't recommend you do this. This article doesn't cover how to troubleshoot that type of configuration.

  4. After you change the port number, restart the Remote Desktop Services service.

Check that another application isn't trying to use the same port

For this procedure, use a PowerShell instance that has administrative permissions. For a local computer, you can also use a command prompt that has administrative permissions. However, this procedure uses PowerShell because the same cmdlets work locally and remotely.

Setup Rd Client

  1. Open a PowerShell window. To connect to a remote computer, enter Enter-PSSession -ComputerName <computer name>.

  2. Enter the following command:

  3. Look for an entry for TCP port 3389 (or the assigned RDP port) with a status of Listening.

    Note

    The process identifier (PID) for the process or service using that port appears under the PID column.

  4. To determine which application is using port 3389 (or the assigned RDP port), enter the following command:

  5. Look for an entry for the PID number that is associated with the port (from the netstat output). The services or processes that are associated with that PID appear on the right column.

  6. If an application or service other than Remote Desktop Services (TermServ.exe) is using the port, you can resolve the conflict by using one of the following methods:

    • Configure the other application or service to use a different port (recommended).
    • Uninstall the other application or service.
    • Configure RDP to use a different port, and then restart the Remote Desktop Services service (not recommended).

Check whether a firewall is blocking the RDP port

Use the psping tool to test whether you can reach the affected computer by using port 3389.

  1. Go to a different computer that isn't affected and download psping from https://live.sysinternals.com/psping.exe.

  2. Open a command prompt window as an administrator, change to the directory in which you installed psping, and then enter the following command:

  3. Check the output of the psping command for results such as the following:

    • Connecting to <computer IP>: The remote computer is reachable.
    • (0% loss): All attempts to connect succeeded.
    • The remote computer refused the network connection: The remote computer is not reachable.
    • (100% loss): All attempts to connect failed.

  4. Run psping on multiple computers to test their ability to connect to the affected computer.

  5. Note whether the affected computer blocks connections from all other computers, some other computers, or only one other computer.

  6. Recommended next steps:

    • Engage your network administrators to verify that the network allows RDP traffic to the affected computer.
    • Investigate the configurations of any firewalls between the source computers and the affected computer (including Windows Firewall on the affected computer) to determine whether a firewall is blocking the RDP port.

This week I’ve been working with a customer that is experiencing intermittent issues connecting into Windows Virtual Desktop from the RD Client installed on their corporate Windows 10 devices and was asked to formulate a list of troubleshooting steps that their IT team could follow to help find and resolve the root cause.

I reached out to Jim Moyle, our aligned WVD Global Black Belt for his thoughts, and in this post, I want to share those initial troubleshooting steps, along with the rationale for each, put them out to the wider WVD community for feedback and over the coming weeks update this article with the identified root cause and the steps taken to resolve the issue.

For info and early clarification, this customer is using the Fall 2019 release of Windows Virtual Desktop.

So, what is the problem?

As introduced, the customer is reporting that certain users, not all, are intermittently unable to connect to their WVD resource using the RD Client installed on their corporate Windows 10 device, furthermore, they never receive any errors (such as resources not available) nor have they indicated that the connection attempt times out (I’ll double-check this and update if required), it simply doesn’t connect.

The below screenshot was provided by an affected user, this shows the RD Client attempting to connect to a selected remote desktop.

Before delving any deeper and starting to define the tests to be undertaken lets quickly recap on how a user connects to WVD, that way once we do start defining a particular test we better understand the rationale behind it, that is, what are we trying to prove or disprove.

Rd Client Connecting To Windows

The diagram below shows the WVD connection flow.

Step 1 > The user launches the RD Client which connects to Azure AD, user signs in, and Azure AD returns token.
Step 2 > The RD Client uses the previously generated token and authenticates to Web Access, the Broker then queries the database to determine the resources (Remote Apps and Desktops) that the user is assigned to.
Step 3 > The user selects a resource (Remote App or Desktop) and the RD Client connects to the Gateway.
Step 4 > Finally, the Broker orchestrates the connection from the WVD instance (the Azure VM) to the Gateway (aka Reverse Connect).

Note, on start-up the RD Client will always refresh your feed, as below, this is the RD Client running through steps 1 and 2 in the above connection flow.

Now, let’s quickly cover some basic assumptions before we get into the testing, again I’ll update these as I speak with the customer IT team and understand more of the nuances of the issue.

Assumption 1 > WVD is a global service, as such, for resilience, it operates many instances of the WVD control plane (the backend services, such as Web Access, Broker and Gateway shown in the connection flow diagram) in each region, however, based on availability at the time the control plane managing your user’s connections into WVD may not be running in the same region as the WVD VM’s themselves. Azure use their Front Door (and Traffic Manager) service to provide a resilient and optimised connection to the control plane – let’s assume a control plane is always up and available.

However, if we wanted to clarify the control plane you’re using is healthy we could use the below Powershell commands.

The below shows the results of the script, note the service is reporting as healthy and more importantly the Region URL shows that actual control plane you’re using.

Remmina Remote Desktop Client Not Connecting

Assumption 2 > This is only affecting certain users, other users can successfully connect to the same WVD resource at the same time others cannot indicating that the WVD VM’s themselves are healthy.

Again, if we want to verify the health of the WVD session hosts within a given host pool we could use the below Powershell commands.

The results will be shown as below.

Assumption 3 > This is only affecting users on their corporate devices, I’ll double-check this with the customer IT team and update if needed.

Assumption 4 > The customer has all the WVD backend services opened and available through the corporate firewall and web proxies. I know they use Cisco Umbrella for web proxy services, so something to be mindful of.

Assumption 5 > The user sees the same issue if they are on their corporate LAN, VPN or connected to the open internet from their home broadband as the majority of their staff are working from home.

So, what tests are we going to run when a user reports they cannot connect and why?

Test 1 > Can the user access the same WVD resource from the HTML5 interface at https://aka.ms/wvdweb?

Bluestacks 1 installer download. Why? We need to narrow down whether the issues is only with the connection initiated from the RD Client, testing from the WVD Web Interface should help prove this. If the user is able to authenticate to the web interface, see all of their assigned WVD resources and then successfully logon to a desktop it proves the issue is not with the control plane, their assignment or WVD session host.

Test 2 > Can the user resolve the WVD Global URL in DNS?

Why? I’m almost certain that whatever the route cause is it will be environmental, that is, something occurring at that exact time on that device that is hindering the connection attempt. This is a very simple test to ensure that the device is able to resolve the WVD Global URL that is used to forward to the regional control plane instance and initiate the connections.

We could build on that test slightly using the Test-NetConnection cmdlet to test connectivity to the Regional URL (from test 2) over HTTP.

Test 3 > Clear RD Client Subscriptions and Re-Subscribe Mass effect 2 gibbed save editor xbox 360 download.

Why? As mentioned earlier, on start-up the RD Client performed a refresh of the feed, this then caches the subscription details in the registry. This test is looking at whether there could potentially be an issue either with the cached settings or the authentication token. You can unsubscribe from the RD Client itself by clicking the 3 dot menu next to the tenant name and selecting Unsubscribe or running the below from a command prompt.

Well, that’s it for now (16/05/20), if you have any suggestions please send them my way on Twitter, I’ll update this post as soon as I’ve had a chance to work with the customers IT team and investigate these issues closer.

Thanks.

Part 2 in this blog series is up now, click here.