RDWeb error; Remote Desktop can't connect to the remote computer (name) for one of these reasons

Question

New install

Server 2022

Webpage displays correctly from internal and external, no certificate errors

shows a list of published apps

When starting an app the error dialog appears "Remote Desktop can't connect to the remote computer (name) for one of these reasons"

The computer name in the error is the INTERNAL/PRIVATE name.

Troubleshooting steps taken:

Created a Let's Encrypt certificate and replaced certificate in IIS and RdGateway

In Rd Gateway Manager, Server farm member, tried entering public DNS name, then private DNS name

In IIS Manager, Sites, RDWeb, Pages, DefaultTSGateway, tried entering public DNS name, then private DNS name, and empty

verified sufficient licences

verified windows firewall is off

verified remote desktop is enabled

verified AV is not quaranteening any file

verified user has sufficient privilege

Collection properties, Security; tried turning NLA on and off

RdGateway configure deployment, Rd Gateway; tried turning Bypass RD Gateway server for local addresses on and off

Application logs:

1309 ASP .NET 4 Event Code 3005 An unhandled exception has occured

System Logs:

4402 NPS There is no domain controller for the domain (TT.)

Answer 1

The error message you're encountering, "Remote Desktop can't connect to the remote computer (name) for one of these reasons," suggests that there might be issues related to the RDWeb configuration or its interaction with the RD Gateway.

Given the troubleshooting steps you've already taken, here's a more focused approach:

1. RD Gateway Configuration

Since the error references the internal/private name in the error, it suggests there might be a misconfiguration in how the RD Gateway is handling the connection.

Double-check the RD Gateway settings in RD Gateway Manager. Ensure that the "Bypass RD Gateway server for local addresses" option is configured correctly. It might be useful to test with Bypass enabled or disabled depending on your network topology.

Ensure that RD Gateway is correctly configured to point to the public DNS name for external access, and the private DNS name for internal access.

2. SSL/TLS and Certificates

It looks like you've replaced the certificate in IIS and the RD Gateway, but ensure that the same certificate is used across all components (RD Gateway, IIS, RD Web).

Ensure the certificate chain is complete and correctly trusted by the server. Sometimes, intermediate certificates may cause issues.

Verify that SNI (Server Name Indication) is correctly set up on your IIS server, as it can impact access to the RDWeb page if there are multiple certificates.

3. NPS Logs (4402 Event)

The "There is no domain controller for the domain" error suggests there could be an issue with NPS (Network Policy Server) not reaching the domain controller. This could indicate a DNS issue or a network connectivity issue between the RD Gateway and the domain controller.

Make sure that the DNS is properly configured on the server and that it's able to resolve the domain name and the DC's IP.

Test connectivity to the domain controller from the RD Gateway server to ensure there are no network issues.

4. User and Group Permissions

While you've verified that the user has sufficient privileges, ensure that the user group memberships and RDS permissions are correctly configured for the remote desktop session.

Check the "Remote Desktop Users" group and ensure that the user is a member of the appropriate group for remote access.

5. Testing with Different Clients

Try connecting from different clients (both internal and external) to see if the issue persists. Sometimes client configurations or local network issues might be contributing to the error.

6. Check the Application and System Logs

You mentioned an ASP .NET 4 Event Code 3005 error. This could indicate an issue with the web page or application pool in IIS that serves RDWeb. Consider restarting IIS and reviewing the application pool settings for any misconfigurations.

7. Firewall and AV

Even though the Windows Firewall is off and AV isn't quarantining any files, it’s worth temporarily disabling any security software to test if it is causing the issue.

Windows Client for IT Pros and Windows Server forums are moving to Microsoft Q&A

We’re transitioning to Microsoft Q&A for a more streamlined experience. Starting February 26th*, new questions can only be posted on* Microsoft Q&A. Existing discussions will remain accessible here.

Beginning March 3rdcustomers looking for support on Answers will be automatically redirected to Microsoft Q&A.

Answer 2

Telling me to make sure RD Gateway is configured correctly is 100% not helpful. I posted here to figure out HOW to configure it correctly, even tho i've configured a half dozen of these before. I would just build another but we have spent time getting a vendor to install and configure software on this server.

I have done all my homework and i think i deserve more than just a cut and paste from a script.

More testing:

Opened a M$ support case. Paid $, no response :(

I opened the .RDP files from the broken server and a working server. they have the same Private and Public names in the same fields. not likely the problem.

ran SFC /scannow + reboot

left and re-joined the domain

put the server on the same subnet as the firewall, verified the return traffic goes to the firewall with the VIP (route print) as we have multiple independent firewalls

Started building a new RdWeb server. *sigh*

Answer 3

I understand your frustration—you're already deep into troubleshooting and have put in a lot of work on this. I'll avoid the generic suggestions, as it sounds like you've already done a lot of the typical steps. Let's get more granular and dive into some potential specifics based on the setup you’ve mentioned.

Next Steps and Advanced Troubleshooting

1. RD Gateway DNS / Name Resolution Discrepancy

You mentioned that the error message is showing the internal/private name instead of the public name, which means there could be something still off in how the RD Gateway is resolving or routing connections internally.

Verify the RD Gateway’s DNS resolution: Use nslookup or ping directly on the server to see if the public name of the RD Gateway resolves as expected from the internal network. Sometimes a misconfiguration in internal DNS (split-DNS) can lead to this kind of issue.

Additionally, ensure the RD Gateway server name is the correct one in the RD Web/Deployment Configuration—sometimes it’s easy to miss the right match between the internal name and the published external name.

2. Double-Check SSL and RDP Certificate Binding

While you replaced the certificate, it’s easy to overlook if IIS and the RD Gateway both correctly reference the same certificate.

Use Netsh to verify the SSL bindings in RD Gateway and IIS. In particular, check for any incorrect bindings that may be causing the issue.

netsh http show sslcert

Verify that the RDP certificate being used is actually the correct one (the one associated with the RD Gateway).

3. RD Gateway and Application Publishing

Test the published apps directly using an RDP client rather than through the RD Web interface. If you can connect using RDP directly but not through the web, the issue may lie in the RDWeb configuration, not the gateway itself.

Double-check the RDS deployment configuration to ensure that your published applications are not accidentally misconfigured. This could result in an internal name being embedded into the RDP file, which is what's likely happening if it is showing the private name in the error dialog.

4. Certificate/SSL Profile Issue with RD Gateway

If the certificate and SSL bindings seem fine, there’s still the possibility that the RD Gateway is failing to route the traffic properly. One potential problem could be SSL offloading at the firewall or a misconfiguration in the RD Gateway's TLS settings.

Check that TLS 1.2 is enabled on the RD Gateway.

Make sure there is no issue with SSL offloading if you have a reverse proxy or firewall in the path. This could cause an internal SSL/TLS error while presenting the wrong certificate to the client.

5. Testing Client and Server Communication

If possible, try connecting to the RD Gateway with the "remote desktop connection" tool directly, bypassing RDWeb completely.

Set the RD Gateway manually in the RDP file and see if that works.

On a client machine, use netstat or Wireshark to monitor traffic on port 443 to see if the gateway is receiving any traffic, and trace the return path.

6. Event Logs and Additional Monitoring

I see you’ve looked at the logs, but make sure to check these as well:

RemoteDesktopManager logs (located in C:\Windows\Logs\RD Gateway)

System Event Viewer Logs for any network connectivity issues, especially regarding RDS components like NLA (Network Level Authentication) and RDP licensing.

7. Firewall, Routing, and Subnet Adjustments

Since you've done some subnet changes and routing adjustments, double-check the NAT/Firewall configurations between the RD Gateway and the clients. If you have multiple firewalls, ensure that all required ports for both internal and external communication are open (i.e., 3389 for RDP, 443 for RDWeb, 443 for RD Gateway).

Verify that there are no routing issues between the RD Gateway and the RDS farm members.

Unlikely but Worth Checking:

Group Policy Misconfiguration: Sometimes a GPO setting can interfere with RDS connections, especially around authentication (such as encryption levels, NLA settings). Check the applied GPOs to ensure nothing has changed.

Corrupted RDS Licenses: Make sure your RDS licensing is correctly activated and there is no issue with the license server. Sometimes an expired or improperly configured license can cause issues.

Windows Client for IT Pros and Windows Server forums are moving to Microsoft Q&A

We’re transitioning to Microsoft Q&A for a more streamlined experience. From 26 February*, new questions can only be posted on*Microsoft Q&A. Existing discussions will remain accessible here until 3 March.

From the 3 Marchcustomers looking for support on Answers will be automatically redirected toMicrosoft Q&A.