Blog: Terminal Server

I recently worked on a problem where a user had a PC with a network printer added utilizing HP’s Univeral Print Driver. The user RDP’s to a Terminal Server and this “local” network printer is redirected through to their Terminal Server Session. When the user attempted to print to the redirected network printer, they received the following error message:

"The selected printer 'HP Universal Printing PCL6' is not a supported HP device"

Printing from the PC to the network printer as well as printing from the TS directly to the network printer worked. [more]

Knowing that the UPD utilizes bidirectional communication when printing, it is my best guess that this was not working via the TS port that was created when the redirected network printer was auto-generated at login. This behavior does not occur with all model printers.

I enabled and configured SNMP with an established SNMP community name on both the network printer port on the print server as well as through the Web Interface on the network printer. Once that was done, printing via the redirected network printer worked.

Upon rebooting a Terminal Server that had resource issues, we could not log back into the server through RDP.  We could log in through iLO, and it was apparent that the logins were working but they were very slow.  Upon examining the services, we could see that the IPSEC service was not started. 

Trying to manually start the service gave the following popup: "Could not start the IPSEC Services service on Local Computer.  Error 2: The system cannot find the file specified."  The event logs also showed that TCP/IP was in blocking mode. 

Disabling the service and rebooting restored all network communication, but trying to start the service would drop all connectivity again and slow down the server.  I found another article that said that IPSEC may need to be rebuilt.  When I looked for the registry keys for IPSEC, they were not there.  After I ran the following commands, the registry keys were populated, and IPSEC was able to run properly.

To rebuild IPSEC, follow these steps: [more]

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\IPsec\Policy\Local.  (In my case, the server’s registry ended before IPsec.  If this is the case, skip to step 6.)
3. On the Edit menu, click Delete.
4. Click Yes to confirm that you want to delete the subkey
5. Quit Registry Editor
6. Click Start, click Run, type regsvr32 polstore.dll, and then click OK.

We recently encountered a problem where users were unable to type in the password or username box after locking Terminal Server sessions from their Thin Clients. Their keyboards were responsive (pressing CAPS Lock key initiated the notification on the Terminal Server) but the cursor or any keys entered would not show up.

It is suspected that one of the multiple windows updates that were released for the month of June may have caused this. Users started complaining the day after the updates were applied. However, testing was not completed to determine which one of the updates caused this or if removal of the update fixed the issue.

Here is the workaround we found:  The problem does not occur if the user locks their screen using the left CTRL+ALT combination. This issue only presents itself if the user locked their session using the right CTRL+ALT key combination. If the user does lock their session using the right CTRL+ALT key combination and is presented with the problem, pressing the left CTRL+ALT keys simultaneously will allow the user to enter their information into the password\username boxes to unlock their session.

We began to see the autocreation of printers (or redirected printers) starting to fail for users when logging in to a customer's Terminal Servers lately.  On the same server we also start seeing the printers that were autocreated not being deleted (orphaned session printers) when users logged off a Terminal Server.  The cause turned out to be two outdated DLLs installed on the Terminal Servers:

Hpmini.dll - This issue occurs with HP model driver versions 60.x.x.x and 4.x.x.x. containing hpbmini.dll version 1.0.0.18 or older. Version 1.0.0.19 and newer has the fix. The memory leaks and memory corruption possible with the 1.0.0.18 (or older) dll will not cause a spooler crash, but can degrade performance of the server.  Version 4.x.x.x print drivers have an issue unloading hpbmini.dll which will likely cause a spooler crash when the server has a heavy load of connected users.

hpcdmc32.dll - This issue occurs with 60.x.x.x and 4.x.x.x HP print drivers containing hpcdmc32.dll version 1.0.2.30 or older. Version 1.0.2.31 and newer has the fix. The most recent version of hpcdmc32.dll is 1.0.2.35. The memory leaks possible with the 1.0.2.30 (or older) dll will not cause a spooler crash but may cause performance degradation.

Here is what turned out to be the solution for us: [more]

1. Upgrade to latest driver available for printer model(s) causing issue – verify that the two DLLs above are updated during this process. If the files are in use while the driver is updated, they will not be replaced.
2. Manually replace the two DLLs above with updated versions.
3. Install and use HP Universal print driver

I’ve been researching some slow installs on one of our terminal servers for a while now. An install, which normally takes a couple of minutes, had been taking close to an hour; giving me time to complete other installs and come back to it. It seemed like a registry issue for the longest time, but I wasn’t completely sure where to begin. I found a posting on an HP forum about an older version of the Universal Print Driver leaving a ton of garbage in the registry when it was installed. Checking the tree (HKEY_CURRENT_USER\Software\Hewlett-Packard, HKEY_USERS\.DEFAULT\Software\Hewlett-Packard) and there were quite a few keys with GUIDs (100a6cf5-1f38-4593-558c-306404c054e2) running down the list. [more]

Following recommendations from http://www.rb303.net/2010/01/terminal-server-2003-msiexec-high-cpu.html, I deleted all the HP printers, deleted all the HP drivers from the local print server properties, and then backed up and deleted the trees listed above as well as the HP Universal Print Monitor key (HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Print\Monitors\HP Universal Print Monitor). I then reinstalled the necessary HP printers, one of which installed the Universal Print driver again, and checked the registry. Much cleaner.

After running a test install, it appears that removing those entries really cleaned up the registry quite a bit and is speeding up the installs. To give you an idea of the sheer size of the exported entries, in the default .reg format, the export took nearly 40MB. In plain-text (.txt) export, the size doubled. That's a lot of HP garbage.

A client's users were getting an error that prevented them from logging into their terminal server. The error points to a long file path for a certain file that is too long to be copied during their roaming profile transfer.  After some research we found that Internet Explorer creates drive cached XML files that are stored within the user’s profile. The file path is so extensive that it prevents windows from copying the file during the roaming profile transfer.

In this particular case, the files are stored in two different places. [more]

1. The USERDATA  folder in the root of the profile path.
2. Application Data\Microsoft\Internet Explorer\UserData

We are able to fix the issue with Location #1 by using a Group Policy to restrict what folders are copied back and forth during the roaming profile. By adding the USERDATA folder to this policy, these files are no longer copied with the roaming profile.

Location #2 is still being researched. However, it appears this caching location can be disabled as well within the internet option settings. It hasn’t been tested at this point, but could be a possible solution.

The setting is located in the following location:

1.  Within Internet Options, select the Security Tab, then the Internet Zone, then Custom Level.

2.  Within the Security Settings, Disable Userdata persisitence

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.

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 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.