Blog: RDP

In a prior post I outlined a method to set the time zone from the command line using a control panel applet.  I needed to do this to fix a problem with the Mac RDP client which doesn't work correctly with time zone redirection.  Using the control panel applet works great on XP and 2003 Server, but only launches the Date and Time applet on 2008 and Windows 7.  After a little bit of research, I found a utility called tzutil that's included with Windows Server 2008 and Windows 7.  This is the same utility Microsoft used to change time zones during the last daylight savings time calendar change. [more]

Syntax:   tzutil /s "Central Standard Time"

A coworker and I ran up against a very interesting situation at a virtualization consulting customer's site the other day. We got an after-hours call from the customer that said he was working on the console of a new Windows 2008 virtual machine. He was trying to set the IP address on the NIC and accidentally choose the “bridge network adapters” setting. Afterwards, he was unable to get to anything in the internal network from this server and several other VMs could not communicate with the internal network either. My coworker connected via VPN just fine, but was unable to ping the vmhost2. He could ping the SBS server, one terminal server, and the ISA server. We discussed over the phone that the particular ESX server that those servers were on must have somehow gotten isolated from the network. Sure enough, when my coworker checked the NIC status on vmhost1, it showed that all NICs connected to the LAN network were disconnected. We decided to go onsite and check out what was going on. On the way out, I realized what had happened. When the two NICs got bridged on that VM, it created a loop and must have looped a BPDU and err-disabled the port. Once onsite we confirmed that the port was down and portfast was NOT enabled on that port.

So, the warning here is two fold…yes, a VM can take down the whole ESX server. And second, its best to turn on portfast for ports connected to ESX servers. They don’t understand STP anyway.

I had recently changed the administrator account at one of our IT consulting customer's sites, and I kept having the account lock out.  Usually this can happen if there are disconnected RDP sessions or services that explicitly run with the administrator’s old credentials.  It is not easy to tell where the lockouts are happening from, but I found some software that I was able to demo that displayed in real time when the account locked out and which computer caused it.  There were about three disconnected sessions that kept causing the lockouts to happen due to disconnected RDP sessions.  I would log off the disconnected session, and I  would see another lockout from a different PC soon after. [more]

This software helped me know where to look, and might be useful for some of our customers that deal with user accounts on a regular basis.  You can also unlock accounts through the console of this software.

http://www.netwrix.com/account_lockout_examiner.html

I have been troubleshooting an issue with terminal services sound redirection for one of our customers for a while. Audio mapping was enabled and all of the GPOs had been checked and re-checked. Resultant set of policy showed everything should be working. The volume showed to be muted when looking at the sound settings through the control panel. You could unmute the sound and click apply and the "muted" check box would automatically re-check itself. All types of troubleshooting were done from DirectX diagnostics to a Microsoft PSS case. Skipping three days forward, the root cause was due to rdpclip.exe not running at user login. This process is started at each login subject to the existence of a registry key which was missing. [more]

The reason it was missing was due to a previous fix for performance issues. The registry key that was missing was  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd:StartupPrograms --> rdpclip  . I added it back and tested and sound redirection worked. However, now the performance issue is back. At login, there are several users who experience very high CPU usage for the rdpclip.exe process. Since rdpclip.exe is responsible for several types of RDP redirection, it was undesirable to remove the registry key again to fix the issue. I was able to determine through additional troubleshooting that audio mapping was the root cause. I can enable any type of redirection via terminal services redirection except audio mapping and the performance problem does not occur.  At this time we still have not found a fix for the performance issue.

Working on an ISA server the other day I had to change the LAN IP addresses.  I was RDP’d into the server from the internal network when I made the change and applied it.  I waited a few seconds and tried to reconnect to the server (by name).  DNS has updated properly with the correct IP address, and I could ping the address, but I couldn’t RDP back to the server.  The server was virtual, so I used VI to connect to the server console.  I didn’t see any issues, but rebooted the server to be sure.  When the server came up, I still couldn’t RDP.  I checked the Terminal Services service and it was not running.  I tried to start it, but it failed.  I checked the event log and it mentioned something about the service binding.  I ran the Terminal Services Configuration console, checked the Properties of the RDP-Tcp object.  On the Network Adapter tab, the “All network adapters configured with this protocol” was selected (which is the default, but wasn’t working).  I manually selected the LAN NIC and hit Apply, and RDP started working again. [more]

I’ve been using the Microsoft RDP client for the Mac to login to one of our terminal servers.  Unfortunately this client has an annoying bug where the time zone is not set correctly if time zone redirection is set through group policy.  After manually changing the time zone a few days in a row I decided to look for more automated solution.  I found that you can invoke the Date and Time control panel applet from a command line and pass the desired time zone.  The command is: [more]

control.exe timedate.cpl,,/Z Central Standard Time

The time zone has to match the one key values saved in the registry at HKLM\Software\Microsoft\Windows NT\CurrentVersion\Time Zones.  I put this in a command file and added it to my startup group on the server.

I cloned a Windows Desktop XP machine and could not access the machine via RDP.  I found that if I edited the registry with a key AllowDirectRDP=True, then I could RDP to the desktop. After researching the problem, I found that this behavior is “by design” for Virtual Desktop Manager “managed” machines. However, I do not believe the original machine was managed by the VDM, but it could have had roots in such a machine. 

Here is the relevant KB article from VMWare.  http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006042

Out of the box, Windows XP doesn’t have Remote Desktop enabled for connecting in to the PC.  You can access the registry of the remote machine and change the setting that will allow access (at least to administrators).

The target PC must have remote registry service enabled.  If it isn’t, you can open services.msc and connect to the remote PC and start it.

The next step is to open regedit and connect to remote PC.  Look for the following Registry key:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnection

Set the value to 0 to enable Remote Desktop, or 1 to disable.

I recently experience a problem with the RDP client not passing the %clientname% variable when setting up a Thin Client running Win CE 6.0. 

Further investigation shows that the issue of the environment variable %clientname% not being passed through to the Terminal Server does not have anything to do with Win CE 6.0. The issue was caused by the specific build of RDP 6.0 that was included on the image of the new shipment of Thin Clients running Win CE 6.0. The specific build included on this image was RDP 6.0 build 9.  [more]

When I checked, there was a new image available for the HP thin clients from HP’s website. The new image included an updated build (14) of  RDP 6.0. This build does pass through the %clientname% environment variable and allows the scripts to function normally. Build 14 of RDP 6 was not available individually as a download from HP’s site. That means the only option at this time is to reload the entire image on the thin client.

When you download and runn the exe you will be given the option of creating an ISO, copying to a USB drive, or deploying the files to a network. I copied the files to a USB drive and then booted the TC to the USB drive. Note: that the USB copy completely formats your USB flash drive erasing any pre-existing data.