|
|
For a terminal server, an optimized operating system means improved performance and no crashes. This is why the methods described in the following section are recommended for optimizing performance or troubleshooting.
If applications with well-known memory leaks are used on a terminal server, it might become necessary to reboot the system frequently. This would clean the memory and lead to improved stability.
The Tsshutdn command is suitable for rebooting and includes a number of parameters. The most important ones are /reboot for rebooting the server (that is, not only shutting it down) and the waiting time in seconds. When that time has passed, all user sessions will be disconnected. Out of basic courtesy, users should be informed of the imminent reboot. The Tsshutdn command does this automatically, using the following syntax:
TsShutdn 120 /reboot
With the help of the At command, it is possible to configure the system for frequent reboots. The Task Scheduler service must be started because it handles the time-controlled execution of commands. In the following example, the server is restarted every Sunday at 11:00 P.M.
At 23:00 /every:Su “TsShutdn 120 /reboot”
If users fail to log on to a terminal server, this can be for many reasons. It is important to know that under Windows Server 2003 there is a clear distinction between local logon and logon via Terminal Services, and that Windows Server 2003 does not behave like Windows 2000 in this respect.
If a user fails to log on to a terminal server, it makes sense to check the following settings:
User group Verify whether the user or user group is part of the local Remote Desktop Users group, which is a standard requirement for using Terminal Services. It is possible to add the user to another group that is defined in the Policy for the local computer or in Group Policy under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Allow log on through Terminal Services. Alternatively, it is possible to add groups including the user concerned.
User properties in Computer Management or in Active Directory Activate the Allow logon to terminal server setting on the Terminal Services Profile tab.
Guest or user access Using Terminal Services Configuration, a user or group can be granted guest or user access if the corresponding settings have been changed in the Permissions tab of the Connection properties.
The Windows Server 2003 registry allows a system-wide configuration for overwriting unwanted user settings. In particular, these settings involve certain graphical output generated in user sessions. The relevant keys are located in the registry under HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\<Connectionname>\UserOverride\Control Panel\Desktop, where <Connectionname> is the name of the connection (that is, RDP-Tcp or ICA-Tcp).
|
Value Name |
Data Type, Default Value |
Description |
|---|---|---|
|
CursorBlinkRate |
SZ: -1 |
The cursor does not blink permanently and thus does not create data traffic between terminal server and client. |
|
DragFullWindows |
SZ: 1 |
Only the window’s outline is visible when dragging it. |
|
MenuShowDelay |
SZ: 10 |
Time before a menu opens after moving the mouse over it. |
|
WaitToKillAppTimeout |
SZ: 20000 |
Time in milliseconds that the system waits for a response after an application was ended by the Task Manager using the End Task button. |
|
SmoothScroll |
DWORD: 0x0 |
Moving window elements without delay using the scroll bars. |
|
Wallpaper |
SZ: (none) |
Users cannot use background images on their desktops. |
|
WindowMetrics\MinAnimate |
SZ: 1 |
Minimizing windows without animation. |
As with Windows 2000 Server Terminal Services, it is possible to prevent clients from establishing user sessions to Windows Server 2003 when specific conditions are met. These conditions are not based on available licenses, but on preset maximum connection configuration values. These values were originally set to prevent a denial-of- service attack on the server. During such an attack, an enormous amount of data packages provokes overload. However, on a terminal server, these limits are often reached, under normal conditions, and can thus lead to unwanted results. This is usually caused by programs that send a large amount of connection requests per user session to a server (for example, Lotus Notes).
The behavior described in the preceding paragraph can be changed through two values in the registry, MaxWorkItems and MaxMpxCt. In an unmodified installation of Windows Server 2003, these values do not yet exist in the registry and therefore need to be created. Nevertheless, their standard behavior has already been predefined in the system. The keys to both values are located in the registry under HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters. For a terminal server environment, the value for MaxWorkItems should be set to DWORD: 8192, and the value for MaxMpxCt to DWORD: 500. MaxWorkItems determines the number of input buffers that a server can provide simultaneously. MaxMpxCt sets the maximum number of client requests that a server can process. You can find more detailed information on this topic in article 232476 in the Microsoft Knowledge Database at http://support.microsoft.com.
Printing documents from Terminal Services sessions is a frequent source of problems and errors because of the different print options and rather complex paths for creating print data streams, as described in Chapter 4 and Chapter 10. For this reason, the following section deals with solutions that will enable the user to avoid some of these system-based problems before they have a chance to occur.
A frequent scenario in large terminal server environments is that of users wanting to connect a new printer to their Terminal Services client and, of course, wanting to use it to print from their user sessions. To automate this process, the terminal server needs a driver that corresponds to the printer driver on the client. So how can the administrator ensure that only the wanted printer drivers are on the terminal server, and no other drivers that might have been imported without the administrator’s knowledge? The solution is installing all permitted printer drivers manually via Start\Printers and Faxes. If the relevant files are in line with the Windows 2000 or Windows Server 2003 specifications, they are saved in the %Systemroot%\system32\spool\drivers\w32x86\3 folder. Furthermore, all relevant configuration data is generated in the registry under HKLM\System\CurrentControlSet\Control\Print and HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\<Printer Name>. (See Chapter 6.) If the reference to the printers under Printers and Faxes is deleted later, the driver files and the relevant data remain intact on the system. This becomes obvious when you attempt to install the same printer driver during a new installation because the system asks if you want to keep the existing driver.
If the client is part of a corporate network and has access to a print server, users may configure their client environment in a way that they can work with network printers via the print server. The necessary drivers are installed either manually or automatically. It is basically impossible for user sessions running on a terminal server or Citrix MetaFrame XP Presentation Server to differentiate between these network printer drivers and a local client printer driver.
If a client with locally configured drivers connects to a terminal server and if the system was configured accordingly, both print subsystems will try to link up automatically. If this works out because the printer drivers already exist in the system, only the administrator group and this particular user will have access to the resulting printer resource. If, however, the character strings between client printer and all printer drivers installed in %Systemroot%\system32\spool\drivers\w32x86 \3 on the terminal server or Wtsprnt.inf for MetaFrame servers do not match, the Ntprint.inf file for terminal servers will help to perform a corresponding allocation through an installation at a later time. Ntprint.inf contains a list of all printer drivers that are part of the standard Windows Server 2003 scope of delivery. The printer drivers, including all relevant driver files, can be installed at a later time using the Driver.cab file located in the %Systemroot%\Driver Cache folder. This later installation will be in system context with maximum access permissions, even if the process was initiated by a user with standard access permissions. In contrast to Ntprint.inf, Wtsprnt.inf contains a list only of printers actually installed that are managed by Citrix MetaFrame XP Presentation Server.
If an original equipment manufacturer (OEM) driver is installed for a new printer model that is not covered by the Driver.cab file, Ntprint.inf also changes. Thus, an OEM printer driver behaves just like an installed default printer driver when it comes to linking Terminal Services sessions. Of course, it is also possible to manually remove the references to printers that are not to be used in a corporate environment from Ntprint.inf. If the list in Ntprint.inf comprises only the preinstalled printer drivers, no new driver will be installed automatically on the terminal server. The driver already exists on the system—even if it was invisible under Printers and Faxes.
| Note |
You might find an instance when the files are on the system and the driver is registered on the system, but the reference is not visible in the standard printer admin tool “Printers and Faxes”. This happens if you uninstall a printer driver: the files and some registry keys remain on the system. This is why the system “remembers” that this driver has already been here when you try to reinstall this driver. |
If a driver is not properly assigned to a client printer in Ntprint.inf, the client printer will not be available for the user session, and a corresponding message will be generated. For this reason, it is an advantage to have many tested and preinstalled printer drivers on a terminal server with a modified Ntprint.inf file because they will ensure the desired functionality and increase stability.
| Tip |
The OEM driver is a driver that is not included in the standard distribution CD of the operating system. The OEM driver comes with the device on a companion CD. |
A MetaFrame server expands the printer management logic slightly. (See Chapter 10.) On the one hand, Citrix MetaFrame XP Presentation Server allows automatic distribution of printer drivers over an entire server farm so that the same printer drivers are installed anywhere on the farm at any time. On the other hand, it is possible to assign all unknown printers to a common, universal printer driver. This method is definitely more favorable than allowing untested OEM drivers on a production terminal server! If the driver installation behavior is controlled by universal printer drivers, the system will be more stable—in the end, it is undetermined as to the damage an untested printer driver that was installed in system context could cause on a terminal server. Only the Group Policy that prevents Microsoft Windows NT 4–compatible drivers from being installed can provide a little additional security in this context.
| Note |
In addition to Citrix, the most popular manufacturers of universal printer drivers are ThinPrint (http://www.thinprint.com), Charon Systems with UniPrint (http://www.uniprint.net), Tricerat with Screwdrivers (http://www.tricerat.com), and Emergent Online with EOL Universal Printer (http://www.go-eol.com). These solutions are suitable both for unmodified terminal servers and with Citrix MetaFrame XP Presentation Server. |
If several client printers are linked to one user session, error messages might be written to the Event Viewer. This is often caused by removing the relevant printer queues in the wrong sequence. Error messages numbered 1109 are caused by this issue and may be ignored.
Another option for printing from user sessions is a set of network printers that can be accessed directly from terminal servers. However, the printer drivers still have to be assigned both on terminal servers and print servers. Each user can individually configure the print server printers available on the network. The corresponding settings are saved in each user’s terminal server profile.
This concept will work fine as long as the printer drivers on terminal servers and print servers are identical. If there are differences between the versions, users will receive a message saying that they will not be able to print on the printer they selected. This is because an automatic update of driver versions for network printers requires write access. However, a normal user has only read and execute permissions in the relevant %Systemroot%\system32\spool\drivers\w32x86\3 folder.
If the user notifies an administrator of the situation, and the administrator subsequently tries to reproduce the error with his or her account, the administrator will not receive the error. This is because the administrator has full access to %Systemroot%\system32\spool\drivers\w32x86\3 and thus may synchronize the drivers automatically—possibly without even knowing it. This will correct the incompatibility and the user will be able to print on the terminal server in question because the needed printer driver is now there. The problem will disappear and the Administrator might not understand how this issue was corrected.
However, if the terminal server in this scenario is part of a farm, this process will result in the individual servers of the farm having different printer configurations. The problems with individual printer configurations will be difficult to predict because user connections will depend on a load-balancing mechanism; and users will be randomly redirected to different servers upon logon. The more administrators help to resolve the problem described earlier, the greater the chaos relating to the installed printer driver versions.
One solution is denying administrators write permission for %Systemroot%\system32\spool\drivers\w32x86\3. This limitation needs to be lifted for a short time only, when new and tested printer drivers are installed on all servers of a farm. Alternatively, it is recommended that new printer drivers for larger environments be installed through special, automated installation environments and a suitable services account. Instead of the drastic limitation of administrator permissions, it is possible to use the Citrix MetaFrame XP Presentation Server print functions. They easily synchronize printer drivers with those of the print server and automatically distribute them over the entire MetaFrame server farm.
Even if the Restrict each user to one session option was selected in the Terminal Services Configuration server settings, it is still possible that a user could log on to the server more than once. This happens if the user starts a Remote Desktop connection with an initial program and launches another connection without an initial program. The terminal server interprets these two sessions as individual sessions and thus allows this unexpected behavior.
Specific logon scripts may be used to prevent a user from logging on to the terminal server or terminal server farm with several sessions. With these scripts and their relevant commands, a list is created enumerating the users who are logged on, current user names are compared, and the second session is terminated immediately. (See Chapter 7.)
With Citrix MetaFrame XP Presentation Server and its Program Neighborhood settings, it is significantly easier to prevent a user from logging on more than once.
Although the Active Desktop allows interesting graphical effects, it usually consumes too many system resources on terminal servers and should therefore be disabled in the Terminal Services Configuration server settings.
To improve the security of conventional logon scripts through batch processing programs, it is recommended that these scripts be executed invisibly on terminal servers—for example, by setting a corresponding system policy under Computer Configuration\Administrative Templates\System\Scripts. Third-party tools are also available for this purpose; for example, Runh.exe. This program can be found on the Web site http://www.scripthorizon.com.
If user profiles are centrally saved, roaming users can be supported. (See Chapter 4.) A terminal server saves local copies of each profile on the local file system while the user is logged on. Normally, changes to settings (such as application or printer configuration settings) are saved in the local copy of the profile first. When the user logs off, all changes to the local profile are synchronized with the profile saved on the server. This makes a lot of sense if there are only a few terminal servers because the possibility that a user will log on to the same terminal server is relatively high. If the locally cached profile is still current, it does not need to be downloaded from the central location, which, of course, saves network bandwidth and ensures quick processing.
However, in large, load-balanced terminal server environments, this behavior is quite counterproductive. In time, profiles will collect on each server because almost all users will have worked on each server. The possibility that one user will log on to the same server twice is fairly low. This means that local hard drive space will be consumed by the user profiles saved on the servers, even though the profiles will still be loaded from the central location. Because terminal servers—just like other computers—do not respond too positively to full hard drives, it is recommended that local profiles be deleted when users log off. The way to do this is by using the DWORD: 0x1 value in the DeleteRoamingCache key located in the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon registry path. If needed, this key must be generated manually. However, this setting can also be established through the system policies under Computer Configuration\Administrative Templates\System\User Profiles.
As with all operating systems, a terminal server responds extremely sensitively when it is attacked by viruses, especially script and macro viruses. To protect the terminal server from viruses, it is necessary to take action. An antivirus program suitable for Windows Server 2003 and multiple-user environments will definitely help. This type of program is usually designed as a service and therefore works in the background. If several terminal servers within a Windows environment need to be checked for viruses, it is possible to deploy specific antivirus programs that consist of a server and a client component. The server program initiates the examination by the client program and notifies the administrator if a virus has indeed been found.
Nevertheless, it is often even better to protect the peripherals from viruses instead of the terminal server itself. If e-mail and file servers are properly protected from viruses and if suitable protection mechanisms are deployed on firewalls, routers, and gateways, it is not necessary to use antivirus programs on terminal servers. Tools such as the AppSense Application Manager offer additional protection. (See Chapter 8.)
|
|