Blog: Terminal Server

We received Event ID:333 "An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in, or write out, or flush, one of the files that contain the system's image of the Registry." On Windows 2003 R2 terminal server running SEP 12.1.

We could reproduced the issue by simply running a SEP scan. We notice all user registry hives from everyone that has logged in are loaded into the registry's HKEY User directory for scanning. Depending on how many users have logged into the server, this can quickly add up. When this happens, it causes the registry memory to become so low that it fails to write any new data to the registry until the server is restarted. [more]

The first event logged would generally state that the system's available memory for the registry was low. After that, Event ID: 333 would be logged about every 30 seconds.

We found this article that helped resolve this issue http://www.symantec.com/connect/forums/event-id-333. In the article are some memory pool settings in the registry with a link to: http://support.microsoft.com/default.aspx?scid=kb;EN-US;312362.

In the article, it states for PagedPoolMax, "Setting the value at 60 informs the Memory Manager to start the trimming process at 60 percent of PagedPoolMax rather than the default setting of 80 percent. If a threshold of 60 percent is not enough to handle spikes in activity, reduce this setting to 50 percent or 40 percent."

During our testing, the value of 60 still exhibited the low resource issue. Setting the PagedPoolMax value to 40 (decimal) along with the other TCP chimney settings stopped the registry errors from Symantec scans.

A user was converted from a workgroup to a hosted domain containing a domain controller and a terminal server. They use the terminal server primarily for an application. After setting up the user on the domain, the user complained that the font on her screen was very small when using the application through RemoteApp on the terminal server. I found a registry key that you can change to change the DPI of the font, but this only changed some menus. The main window was still very small, and her application ran very slow. I could log in as myself and the application seemed to run fine. What I finally found was that her screen resolution was set to a non-standard size of about 1500x1600, and the terminal server gets it’s resolution from the client PC. I set the screen size to 1024x768 and the application started running much faster, so I suppose it just had trouble resizing the pages to fit the odd screen size. She had also set the font on her computer to 150%, so the font size on her computer was much bigger than the terminal server. After setting her screen resolution to a normal size and setting the font back to 100%, the application is running quickly and the font is large enough for her to view.

I was working on a few terminal servers that were extremely low on free disk space on a drive which also contained user profiles.  I came across a helpful tool called ICSweep from Ctrl-Alt-Del IT Consultancy and is freeware.  You can download it and other tools from http://www.ctrl-alt-del.com.au/CAD_TSUtils.htm.

“ICSweep is a command-line utility to clear the Temporary Internet Files Cache and/or the TEMP files folder of ALL user profiles that are NOT in use when this command is executed.  This utility was written for the purpose of allowing a SINGLE command to identify and clear Temporary Internet Files Cache and/ or TEMP files of ALL user profiles currently NOT in use.” [more]

Windows Compatible - 2000\XP\2003\Vista\2008\7
Citrix Compatible - Metaframe\Presentation Server\XenApp

Simply extract the zip file then run ICSweep from a command prompt with one of the following command line switches:

  /ALL   -   Delete both Temporary Internet Files and Temp files
  /TIF   -   Delete Temporary Internet Files only (Default)
  /TMP   -   Delete Temp files only
  /SIZE  -   Report the size of both Temporary Internet Files
                and Temp files in each profile NOT in use. This
                switch will also report the total size of
                both Temporary Internet Files and Temp files NOT
                in use. It DOES NOT DELETE any files.

Again, note that this is best done when all users are off of the server.  On one of the servers I ran this utility on, it cleaned up 6 GB of space alone.

This is pretty straight forward, but comes up from time to time.  A customer called to say their screen is smaller (lower resolution) than it used to be after Windows Updates.
 
Notes about Terminal Server resolution:

• You cannot change the resolution while in a terminal server session.
• The Display tab in the RDP options before you connect is usually set to “Full Screen”.  It can be set to lower resolution sizes than your current PC or Thin Client settings, but not higher.

In order to fix the problem, close the terminal server connection.  Change the resolution size as needed on the local PC or Thin Client, and then reconnect to the terminal server.  The new resolution settings will be passed through automatically if the display settings are still set to “Full Screen”.

We ran into a problem recently where users on a Windows 2008 R2 terminal server would lose their connection to SMB shares.  Fully-qualified domain names do not get disconnected.

There is a Hotfix from available from Microsoft that fixes this problem:  http://support.microsoft.com/kb/2194664.  The Hotfix is integrated into into Windows 2008 R2 SP1 and the next Windows 7 service pack.

One of our network consulting clients complained of being unable to use remote logon for shadowing sessions on a terminal server.  Upon testing I was able to use remote logon fine.  I did eventually find a user that I could not shadow.  I received an error, “Access is Denied” when attempting to use remote logon with their session.   Further investigation found that users that had two monitors setup and were using both with remote desktop 7 were the ones I could not remote to.  This had been confusing because sometimes it appeared to work and others it did not.  The customer was in the process of moving all users to a two monitor setup so the problem had been progressively getting worse.  Various forums and Microsoft articles referenced this problem.  Shadowing of dual monitor sessions is not currently supported by Remote Desktop Services Manager.

We had an issue come up with a group of Citrix Presentation Servers that were recently introduced as a pilot for one of our customers. All the Citrix servers are newly built using mostly application defaults. Our first application silo contained routine applications like Office, IE, and file share resources. Setup and testing went very smooth. However, the second silo we built published a core application that was launched using a batch file. Testing of the application by our network engineers and by the customer’s head of IT raised no concerns. Everything worked as expected. The application was published to a small set of regular users chosen as a pilot group and we were quickly alerted that none of the users could launch the application. Here is the error that was displayed: [more]

“The desktop you are trying to open is currently available only to administrators”

We were aware of some ongoing Terminal Server licensing issues that this customer was experiencing so we automatically assumed that was the problem. We scrambled to put another Windows 2003 server on the network to run TS licensing thinking it was only a matter of time before the other Citrix servers started having issues. By the end of the day, we had the new TS licensing server online and all the settings deployed via group policy to the problematic servers. A reboot of the servers would fix it…not so much. After the reboot, the issue persisted. Back to square one. After digging through all the settings a few times, I finally found the following setting:

On the surface this setting doesn’t look like it would cause any issues. After all, we were using a published application and it looks like this setting would only prevent users from opening a published desktop on the server. However, after doing some testing, we found that the ICA protocol doesn’t consider launching a batch file to be a published application. Only files with .exe extensions count. Our testing failed to uncover this issue because we had unintentionally done all of our testing with administrator accounts and all the applications published on the first silo were standard .exe apps. Unchecking this box fixed the problem.

I was recently assisting a client who was receiving TSCAL (licensing) errors when logging into 2008 terminal server via a Wyse thin client.  After researching found that it was caused by the default User not having write access to the registry that is needed to be able to re-write the hardware ID under MS licensing.  Here is how I was able to fix the problem: [more]

1. Login as Administrator locally in to the device and disable the write filter
2. Launch the registry editor and navigate in to Hkey_local_machine\Software\Microsoft\
3. Select MSLicensing > right click select Permission  > Click on Advance tab
4. Set the User  and the Power User  to have full control