Change Computer name for downloaded RD Web file and SSL certs

    General discussion

  • Discussion, not a question. I'm just documenting here to save others the hassles. In case there's an easier way, please correct me.

    We have a simple two-host farm for Remote Desktop. We're distributing the RDP file by having people log into RD Web and downloading it from there. We have two RD servers called TS02 & TS03 and another server called FS09 performing other roles of gateway, licensing, broker. All are running Win 2012 R2. After deployment but during QA check we discovered we had two issues:

    1. For the computer name showing in the RD file, it was using the wrong name. It had the name of the broker instead of the farm name. We wanted to update the RD file but couldn't find this exposed in the GUI as with previous versions of Windows Server or even PS (RemoteDesktop module). To fix this we had to use the script at Change published FQDN for Server 2012 or 2012 R2 RDS Deployment (thanks TP[]!)

    2. The session host servers were using the self-signed rather than wildcard cert that we had purchased and already added to the local certificate stores. We couldn't find a GUI way to select this as with previous versions of Windows Server. We had to edit the registry to get to this! We followed the instructions in the article Remote Desktop listener certificate configurations in Windows Server 2012 R2 and Windows Server 2012.

    Friday, May 18, 2018 3:28 PM

All replies

  • Hi,

    1. The FQDN in the .rdp file is supposed to point to the broker.  You probably already know this, but I wanted to clarify since some people think it should point to the RD Session Host servers, which is incorrect.

    2. The RDSH servers should be using self-signed certificates.  That is how it is designed.  A client first connects to the broker and authenticates the broker via Kerberos and/or Certificate and then broker authenticates the target host on behalf of the client.  Unless you have a special requirement such as old client devices that don't understand how to work properly with Server 2012 or later RDS self-signed certificates should be used on the RDSH servers.

    Separate from an RDS deployment, you may need to use a custom certificate on the RDP-Tcp listener for individual servers.  For example, if you have a server where you can't use Kerberos to authenticate it you can assign your own trusted certificate to the listener so that certificate authentication can be used instead.


    Friday, May 18, 2018 3:49 PM
  • Hmmm. Maybe we have some other problem(s) then. We did have the broker name as the Computer name in the RD file but Domain Users (who could connect to the RD Farm) were getting error messages. I found that it was because the broker was trying to log them into itself rather than directing them to the farm. The session collection contains only the RD Session Hosts so I'm not sure why this was the result.

    The SSL certs were giving us errors since people were connecting from non-domain-joined (personal) computers. During the connection process, we'd see an error message related to the cert. Is there some other way to avoid that?

    Friday, May 18, 2018 3:55 PM
  • Hi,

    When a user launches a connection using a .rdp file with proper contents they will first connect to the broker and be redirected to the appropriate RDSH server, not try to log on to the broker as you describe.  If they try to manually connect by using mstsc and entering a name/ip in the box, then they will see the behavior you describe.

    If the .rdp file is manually obtained from RDWeb it will have the proper contents, assuming you have first configured the RDS environment properly.  It is okay to manually distribute .rdp files if that is what you want.

    The preferred way for users to launch desktops/RemoteApps is via RD Web Access, and/or RemoteApp and Desktop Connections, and/or Remote Resources (Mac, iOS, Android, UWP).  Using one of the preferred techniques allows for dynamic changes/additions to the environment besides the stated benefit of having correct .rdp files.

    When using a certificate from trusted public authority both domain-joined and non domain-joined PCs will trust it.  So the remaining issue is to make sure you have the correct FQDNs (for broker and gateway) configured, and your DNS entries are correct both internal and external.


    Friday, May 18, 2018 4:06 PM