I recently encountered an issue where users attempting to connect to a server via the “Remote Desktop” tab in the RD Web Access site were presented with a “Remote Desktop can’t find the computer” error when attempting to connect to a resource, as shown in the below screenshot.
After performing some research it appeared that the DefaultTSGateway property in the RD Web Access IIS site needed to be populated with the external fully qualified domain name of the RD Gateway server. By performing this, the request made for a server via the Remote Desktop tab in the RD Web Access site was then directed through the RD Gateway server. To achieve this, and resolve the issue the following actions were performed.
1. Connect to your RD Web Access server and open the IIS 7 management console.
2. Expand Server Name -> Sites -> Default Web Site -> RDWeb -> Pages -> en-US
3. In the Application Settings pane, click the DefaultTSGateway entry and select edit from the action pane on the right hand side, as shown in the below screenshot.
4. In the edit DefaultTSGateway box that is now presented, in the value section, enter the external fully qualified domain name of your RD Gateway server. For example, rdsgateway.domain.co.uk and click ok.
5. Test resource access from the RD Web Access site to a server via the Remote Desktop tab. You should now be able to connect and authenticate correctly. One thing to note is that you will only be allowed to connect to internal resources that have been specified in your Resource Authorisation Policy (RAP) in the RD Gateway manager.
That’s it, your all done.
I was recently involved in a Remote Desktop Services deployment for three hundred users. After configured Remote Desktop Services and publishing a RemoteApp, which had been digitally signed with a Go Daddy certificate and deployed via an MSI, I was prompted with a “Do you trust the publisher of this RemoteApp program” warning as shown in the below screenshot.
Obviously this was going to be an inconvenience for users, so to resolve this issue I performed the following actions.
1. Create a new Group Policy object via the Group Policy Management Console.
2. Edit the GPO and navigate to the following location, User Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client.
3. Within the Remote Desktop Connection Client folder double click the “Specify SHA1 thumbprints of certificates representing trusted .rdp publishers” group policy object and check the enabled radio button.
4. Now open the SSL certificate you are using for RemoteApp signing, click the Details tab and then scroll down the details pane until you see the “Thumbprint” item. Click the thumbprint entry and you should now see a large alphanumeric string, copy this string and paste the contents into the “Comma separated list of SHA1 trusted certificate thumbprints” box in the GPO we were editing in step 3.
5. Now that you have pasted the thumprint string into the GPO, remove all space and capitalise all lower case letters of the string. For example, if your thumprint looks like this, “95 1f 22 02 c3 6e a6 b0 64 0c db 8e b5 4a bb 98 0c bd ed af” once you have pasted it into the GPO, you need to modify it to read like this, “951F2202C36EA6B0640CBD8EB54ABB980CBDEDAF”.
6. Close down the GPO editor and then link the created GPO to a users organisational unit where the RemoteApp users reside. Log a RemoteApp user off and back on again and test the RemoteApp program, you should now hopefully see that the certificate warning is suppressed and the application loads straight away.
That’s it, your all done.
I recently experienced an issue with getting RemoteApp single sign on working from Windows XP workstations. When launching a published RemoteApp through either an .RDP or MSI file, users were prompted for authentication even though they had already authenticated on login. In order to stop this from occurring, the following actions were performed.
1. Ensure that the Windows XP workstation is running service pack 3 and ensure that the Remote Desktop Connection 7.0 Client is also installed. The Remote Desktop Connection 7.0 client can be obtained from here.
2. Install the Credential Security Support Provider (CredSSP) package. This enables credentials to be passed to target servers. The CredSSP package can be obtained from here.
3. Ensure that at least .NET Framework 3.5 SP1 is also installed on the workstation.
4. Configure a computer level Group Policy on a domain controller to enable delegating default credentials. A detailed explanation of how to configure the group policy object is detailed here.
5. The final step is to apply hotfix KB953760 which address a particular single sign on issue with Windows XP SP3 based workstations. The hotfix can be directly downloaded from here. When the hotfix has been applied reboot the workstation.
That’s it, you should hopefully now no longer be prompted for authentication when opening published RemoteApp’s on Windows XP SP3 workstations.
I recently deployed a small Windows Server 2008 R2 Remote Desktop Services environment and experience an issue where I could not hide the administrative tools folder that is inherited as a part of the default user profile. This meant that when a user connected to the session host (Terminal Server) they could see the administrative tools icon and associated MMC snap-in’s on the Start Menu. After trawling through all user based group policy objects, I realised hiding the administrative tools folder was not possible. To achieve this, I created a custom ADM template that could be imported into a Group Policy Object in order to hide the administrative tools entry. The steps I performed are featured below:
1. On a Windows Server 2008 R2 machine, with the Group Policy Management console installed, download and place the custom ADM file in the C:\Windows\inf. The ADM template (rdsadmintools.adm) can be download here, please right click the link and select Save Target As.
2. Edit your existing user lockdown Group Policy Object. Expand the user configuration, polices, then right click Administrative Templates and select Add/Remove Templates.
3. In the Add/Remove dialog box, select Add and then browse to the rdsadmintools.adm file and click ok followed by clicking close.
4. You should now see a “Classic Administrative Templates (ADM)” folder under the main Administrative Templates container. Double click this container and then double click the Remote Desktop Services container to reveal the GPO.
5. Double click the “Remove Administrative Tools From the Start Menu” GPO, click Enable and then using the drop down select box select “Off” and click ok.
Your all done, when logging in as a remote desktop services user you should now no longer be able to see the administrative tools start menu item.