I recently installed the Routing & Remote Access service on a Windows Server 2008 R2 domain controller. While this is not a recommended approach, it was unfortunately the only server available to host the role. Shortly after installing the role and binding it to the DHCP service, I noticed that when pinging the domain controller it was returning an IP address in the DHCP range. On further inspection it appeared the IP address assigned to the virtual RRAS adapter was registering against DNS and therefore creating two entries for the domain controller. To resolve this issue, the following steps were performed.
1. Navigate to Start -> Administrative Tools and click the DNS option.
2. When the DNS console opens, expand the “Forward Lookup Zones” container and then expand your local domain name.
3. Locate the incorrect host A record for your domain controller and delete it by right clicking the record and selecting delete.
4. In the DNS console, right click the servers name and select properties.
5. In the properties window click the listeners tab and select the “Only the following IP addresses” radio button.
6. In IP addresses list remove the incorrect IP address and then click ok and exit the DNS console.
That’s it, you should no longer experience duplicate DNS entries for your domain controller.
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.
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.
Time synchronisation on Windows servers is an issue that comes around every so often, which can cause some serious problems in an infrastructure. I recently had a customer with a time problem which was affecting several services from starting correctly, which were mainly Microsoft Exchange related. There is a ton of information on the internet about ways to fix time issues in Windows based domains, most of which reference third party time applications or registry fixes. Whenever I experience a time issue across an infrastructure I always utilise the following procedure:
1. Open up a command prompt window, if you have User Account Control enabled on your server ensure you open the command prompt window as an administrator
2. Firstly I like to find out the time difference between my domain controllers and an external trusted time source, to obtain this information run the following command. You can change the “computer” attribute to a time server in your geographical area, I have set this to uk.pool.ntp.org to reflect greenwich meantime:
3. You should now be able to see how far out of sync your domain controller is compared to an accurate external time source. To sync your domain controller with this external time source and rectify the issue, enter the following command into the same command prompt window. As with the previous command you can change the “manualpeerlist” entry to reflect an external time server in your geographical location:
4. That’s it, your domain controllers time you should have correctly synchronised against the external time source specified and other machines in your domain should also now inherit this time if they are configured to obtain time information from a domain controller.
I recently experienced an issue with Dynamic DNS updates on Windows Server 2008. Since upgrading VMware tools on a Windows Server 2008 virtual machine, all six network adapters that were assigned to the VM were now registering themselves on my internal DNS servers, despite me having unchecked the “Register the connections address in DNS” checkbox on each adapters properties. This resulted in me having six host A records in my internal DNS for the same server, however I only wanted one of the servers IP addresses to be registered against it’s hostname.
Unfortunately enabling and then disabling the “Register the connections address in DNS” option again did not resolve the issue. I figured this occurred as when upgrading VMware tools the servers network adapters are removed and re-added. To resolve this issue I opted to disable Dynamic DNS updates on the server all together using a registry entry. To disable Dymanic DNS on a Windows Server 2008 or Server 2008 R2 machine, perform the following actions.
1. Login to the server with the issue.
2. Click the Start menu and select Run.
3. In the Run dialog box type the following entry without the quotation marks and then click ok:
I would recommend keeping a watch on your internal DNS servers for 24 hours after applying this registry key, to completely ensure the issue is resolved. You can find additional information on methods of disabling Dynamic DNS on Windows Server platforms at the following Microsoft KB article: http://support.microsoft.com/kb/816592
I recently assisted with a deployment of Office Communications Server 2007 R2. During the deployment I experienced an issue with Communicator Web Access. When signing in via CWA, either internally or external, my SIP enabled accounts presence always showed as offline, even if I explicitly told the web access client to sign me in as available. The strange thing was, when I viewed the account signed in through CWA on a Communicator Client, the presence was correctly shown as available. After a lot of testing and investigation it turned out this was an issue related to deploying the Communicator Web Access role on Windows Server 2008 R2. To resolve the issue I performed the following actions:
1. On your CWA server download and install the latest July 2010 Communicator Web Access patch which is included in Microsoft KB 968802. This can be downloaded from the following location, however please note you will need to scroll down the article and download the cwamain.msp file.