Posts tagged Terminal Services

Opening Terminal Server registry propogation window. (aka: Installing software in windows takes forever)

463 days
by in I.T.

That’s not a typo. For the past few months, I’ve noticed that installing software or running updates on one particular terminal server that I manage (Windows Server 2003, std.), the updates/installation take hours — in some cases, days. So I enabled windows installer logging and here’s what I found:

MSI (s) (2C:30) [01:58:16:558]: Opening Terminal Server registry propogation window.
MSI (s) (2C:E8) [02:35:44:188]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [03:13:14:358]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [03:50:44:453]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [04:28:14:529]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [05:05:44:619]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [05:43:14:897]: RunEngine wait timed out
Installer is no longer responding.
Action ended 5:52:07: InstallInitialize. Return value 1.
MSI (s) (2C:30) [05:52:07:859]: Doing action: SxsInstallCA
Action start 5:52:07: SxsInstallCA.

So as you can see by the snippet above, this routine installation took an enormous amount of time. This exact scenario played out anytime I tried running updates or installing software. As it turns out, this was the problem. Simply removing the driver and deleting the following registry keys, and then installing the latest version of the driver (… I was on ~3 something; at the time of this writing, the latest version is 6.1) fixed the problem. Here are the registry keys that should be removed after the driver has been uninstalled (and before the latest version has been installed):

HKEY_LOCAL_MACHINE\SOFTWARE\Hewlett-Packard
HKEY_CURRENT_USER\SOFTWARE\Hewlett-Packard
HKEY_USERS\.DEFAULT\Software\Hewlett-Packard

This was an extremely frustrating issue — other symptoms included server crashes with an error message about the registry being too large; logging in a brand new user for the first time takes ~15 minutes or so, and a whole host of other performance related weirdness. At first I thought that installing UPHClean would help solve this (the symptoms being registry-related and all) but it may have actually made the problem worse. If you scroll all the way down to the bottom of the page of the previous link to HP’s website, you’ll see the following post:

JulianBlue Oct 6, 2010 07:37:53 GMT
It is very likely that HP UPD problem replicating tons of registry keys to global default registry hive (.DEFAULT) being related to Terminal Server on which the Microsoft UPHClean Tool is installed. I would recommend to look at the readme.txt with UPHClean and setup an exclusion for svchost.exe/rpcss.dll.

“UPHClean assists the operating system to unload user profile hive by remapping the handles to the user profile hive to the default user hive. For example if a process has a handle to HKEY_USERS\S-1-5-21-X-Y-Z\Software\Microsoft after remapping it would have a handle to HKEY_USERS\.DEFAULT\Software\Microsoft.”

I haven’t had the chance to test this yet, but it does sound plausible enough. There’s also some other posts related to this on HP’s website that are worth having a look at. Here’s the readme.txt that comes with UPHClean. Setting up an exclusion list is fairly straightforward; for convenience, I’ve pasted the pertinent section of the UPHClean readme here:

PROBLEMS USING UPHCLEAN
=======================

Because UPHClean assists in unloading the users registry
hive some services may behave incorrectly. Administrators
are encouraged to test and watch for unexpected behavior.
If unwanted behavior is identified contact the developers of
software that UPHClean identified as preventing profile from
unloading.

UPHClean assists the operating system to unload user profile
hive by remapping the handles to the user profile hive to the
default user hive. For example if a process has a handle to
HKEY_USERS\S-1-5-21-X-Y-Z\Software\Microsoft after remapping
it would have a handle to HKEY_USERS\.DEFAULT\Software\Microsoft.
This allows the profile hive to unload. This may not work if the
application expects data that would only be available under the
specific user profile hive it was accessing since the data will not be copied.

If you find that removing UPHClean stops a particular problem from
occurring then you may be interested in restricting UPHClean from
processing certain handles. UPHClean ignores handles that are
held opened to profile hives for the users specified on the user
exclusion list or by processes specified on the process exclusion list.
These lists are specified using the following registry values:

HKLM\System\CurrentControlSet\Services\UPHClean\Parameters\PROCESS_EXCLUSION_LIST

HKLM\System\CurrentControlSet\Services\UPHClean\Parameters\USER_EXCLUSION_LIST

Note that since these values are specified as REG_MULTI_SZ strings
you should use regedt32 on Windows NT and Windows 2000 to edit them.

The process exclusion list is a list of process names that UPHClean
should ignore when determining which handles to user profile hives
to act on. Each process name is specified on its own line when
input in registry editor. The process name should be specified the
same way as it shows in Task Manager. Usually this is the file
name of the program (e.g. notepad.exe).

A few process show multiple times in Task Manager. It is possible to
specify that a certain DLL be loaded in the process to allow a selection
of a specific process. This is useful with the svchost process to identify
a specific instance. For example to specify the svchost process that
the Remote Procedure Call (RPC) service is running in on Windows 2000,
Windows XP and Windows Server 2003 you would specify
svchost.exe/rpcss.dll in the process exclusion list

The user exclusion list is a list of user security identifier (SID) or user that
UPHClean should ignore when determining which handle to user profile
hives to act on. Each user SID or name is specified on its own line when
input in registry editor. If specifying a user name you must enter the user
domain name followed by a backslash followed by the user name. For
example RCARONDOM\RCARON to specify the user RCARON from
domain RCARONDOM. SIDs should be specified in the usual string
format (e.g. S-1-5-21-2127521184-1604012920-1887927527-68486).
This is the same string you see under HKEY_USERS in registry editor.

Note that the user exclusion list always includes the following
SIDs: S-1-5-18, S-1-5-19, S-1-5-20. Unloading these profiles can cause
problems so UPHClean will not attempt to process handles to these profiles.

Which processes UPHClean performs handle remapping can specified
using the following registry value:

HKLM\System\CurrentControlSet\Services\UPHClean\Parameters\REMAP_HANDLE_PROCESS_LIST

The list by default contains ‘*’ which specifies that handle remapping should
be performed for all non-excluded processes. This list can be changed to
only include specified processes in the same manner as the process
exclusion list. Processes specified on this list can be preceeded by a ‘-’
character to specify that they should be excluded from handle remapping.
Any handle for a process that is not excluded but has handle remapping
turned off will be closed.

I hope this helps!

Configuring “Per User” licensing in Terminal Services, remotely *without* Remote Desktop access

866 days
by in I.T.

So the other day I was trying to connect to one of the terminal servers that I manage (for the purpose of this post, we’ll call the server ‘TERMSVR01′) and I got the following error message and was promptly disconnected:

The remote session was disconnected because there are no Terminal Server client access licenses available for this computer

At first glance, this seems as though the server ran out of TS CALS (Terminal Server Client Access Licenses). I was pretty sure that the server was configured to use the “Per User” licensing mode. However, a Windows Server 2003 Terminal Server operating in the “Per User” licensing mode can’t run out of licenses to the extent that it prevents the user from connecting (and instead, giving them the aforementioned error message). To the best of my knowledge, it can only do this when it is operating in “Per Device” mode. So this was the assumption that I ran with — that somehow, this server was never configured for “Per User” -or- it was, but the setting was either changed, reset, or corrupted somehow.

So, even though I wasn’t able to connect to TERMSVR01 via Remote Desktop, I was able to “Manage” it remotely by doing the following:

  1. Open “Active Directory Users and Computers” on any Domain Controller
  2. Expand the “Computers” node
  3. Right-click TERMSVR01 and select ‘Manage’

Now we can do a few things (not many) on the server. One thing I wanted was to have a look at the Event Viewer. There were a few error messages like the following:

Event Type: Information
Event Source: TermService
Event Category: None
Event ID: 1004
Date: 1/5/2010
Time: 6:18:23 PM
User: N/A
Computer: TERMSVR01
Description:
The terminal server cannot issue a client license. It was unable to issue the license due to a changed (mismatched) client license, insufficient memory, or an internal error. Further details for this problem may have been reported at the client’s computer.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

The more of these I saw, the more confident I was that my assumption was correct — the server was operating in “Per Device” mode and it had finally run out of licenses. I had the following options:

  1. Wait for someone to go onsite and reconfigure the licensing mode (easy, but it would have to wait until tomorrow) or…
  2. Attempt to reconfigure this setting and restart the service remotely (so that the setting takes takes effect) … all without having “Remote Desktop” access to the server.

Care to guess which option I chose? :-)

Step #1: Override the licensing mode setting using group policy

  1. Click ‘Start’
  2. Click ‘Run’
  3. Type the following command:
    gpedit.msc /gpcomputer:TERMSVR01
  4. Click ‘OK’

Those four steps open the group policy (remotely) for TERMSVR01. Next we need to actually change the setting:

  1. In the left-hand panel, expand “Administrative Templates”
  2. Expand “Windows Components”
  3. Click on “Terminal Services”
  4. Locate the following setting in the right-hand panel:
    Set the Terminal Server licensing mode
  5. Double-click the aforementioned setting
  6. Change the option (directly below the heading) to “Enabled”
  7. Select “Per User” from the drop-down box (below the heading: “Specify the licensing mode for the terminal server”.)
  8. Click ‘OK’
  9. Close the “Group Policy Object Editor” window

Great. The licensing mode has been changed but the setting won’t take effect until the service is restarted. We could open ‘services.msc’ and connect to ‘TERMSVR01′ by using the ‘Connect to another computer …’ option in the ‘Action’ menu. This will allow us to administer almost all running services on TERMSVR01 … almost all. You’ll notice immediately that you cannot start/stop the ‘Terminal Services’ service from this management console, so we need to find another way to do it.

The easiest way I know to accomplish this task is to use the WMIC command from the command prompt.

Step #2: Restart a remote service using WMIC

  1. Open a command prompt
  2. Type the following command (then hit enter) to stop the service:
    wmic /node:TERMSVR01 service where “caption=’Terminal Services’” call StopService
  3. Then, type the following command to start the service:
    wmic /node:TERMSVR01 service where “caption=’Terminal Services’” call StartService
  4. Close the command prompt

If everything was successful (and my assumption about the nature of the problem was correct), then I should be able to connect to the server using the Remote Desktop client. I fired up the client and voilà! It worked perfectly.

Go to Top