Microsoft Windows Server 2003 Deployment Kit [Electronic resources] : Planning Server Deployments نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Microsoft Windows Server 2003 Deployment Kit [Electronic resources] : Planning Server Deployments - نسخه متنی

Microsoft Corporation

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
توضیحات
افزودن یادداشت جدید





Designing Terminal Server Installation and Configuration


By carefully planning how you install and configure the various components of your Terminal Server solution, you can save considerable time in the installation and make management of your servers easier. Figure 4.5 describes the steps in this process. The components needed for a complete Terminal Server solution include the terminal servers themselves, the license server, and the applications that you plan to host, as well as a load-balancing solution and a Session Directory server if you plan to use them.


Figure 4.5: Designing Terminal Server Installation and Configuration



Designing the Installation Process


Selecting the best way to deploy your terminal servers depends on the scope of your use of Terminal Server. You can enable Terminal Server on a server that has Windows Server 2003 already installed by using Add or Remove Programs in Control Panel or the Configure Your Server Wizard. You can also deploy Windows Server 2003 with Terminal Server enabled by using an automated installation method. These options are discussed in further detail in the following sections.

Enabling Terminal Server Manually


If you are deploying just one terminal server, or if you are upgrading to Windows Server 2003, it might be easiest to enable Terminal Server on a server that already has the operating system installed and configure the server individually. You can accomplish this through the Configure Your Server Wizard or through Add or Remove Programs in Control Panel. For information about how to use the Configure Your Server Wizard, see "Install Terminal Server" in Help and Support Center for Windows Server 2003. To enable Terminal Server through Add or Remove Programs, open Add or Remove Programs from Control Panel, or in the Run dialog box, type control appwiz.cpl, and click Add/Remove Windows Components.





Note

You can also install Terminal Server Licensing through Add or Remove Programs.


Internet Explorer Enhanced Security Configuration Considerations


If you choose to install Terminal Server by using Add or Remove Windows Components in Add or Remove Programs, a warning appears if the installation will proceed with Internet Explorer Enhanced Security Configuration enabled, and allows you to choose whether you want to proceed with this configuration. It is recommended that you choose No and return to Add or Remove Windows Components and disable this configuration to allow users to browse the Internet.

If you install Terminal Server through the Configure Your Server Wizard, no warning appears. When the Manage Your Server window appears after you have added the Terminal Server role, a message appears that indicates the status of the Internet Explorer Enhanced Security Configuration, and gives instructions about how to change it.

For more information about Internet Explorer Enhanced Security Configuration settings, see "Internet Explorer Enhanced Security Configuration" in Help and Support Center for Windows Server 2003.



Enabling Terminal Server Using an Automated Installation Method


One way to ensure that your servers have a consistent configuration is by using an automated installation method to install Windows Server 2003 with Terminal Server enabled. The following automated installation methods are available in Windows Server 2003:



Unattended Setup



Sysprep



Remote Installation Services (RIS)



If you are deploying Terminal Server with several configurations, you can enable Terminal Server on all of the servers by using an automated installation method, and then configure the servers individually after the installation.

You cannot configure settings such as Group Policy settings within the automated installation itself. However you can set up the installation to run scripts that can configure these settings and perform a wide variety of other configurations after the setup is complete. For more information about the options for automated installations, see the design chapters for the various automated installation methods in Automating and Customizing Installations of this kit and the "Microsoft Windows Corporate Deployment Tools User's Guide" in the \Support\Tools folder of the Windows Server 2003 operating system CD.





Tip

If you deploy Terminal Server for use in a load-balanced farm, an automated installation method is an easy way to ensure an identical configuration on all the servers in the farm.


Unattended Setup


Unattended Setup uses an answer file to automate the setup of Windows Server 2003. It is the only way to automate an upgrade to Windows Server 2003. Unattended Setup is a good choice for installing Terminal Server if, for example, you are planning to deploy terminal servers with a few applications for different purposes. For more information about designing an Unattended Setup, see "Designing Unattended Installations" in Automating and Customizing Installations of this kit.

For Terminal Server, you need to make entries in a few of sections of the answer file (Unattend.txt) in order to complete the automated installation:


[Components]

The [Components] section contains entries for installing the components of Windows XP or Windows Server 2003 operating systems. These components use the values On or Off to install or not install the component.





Note

The entries in this section can also be set in the Sysprep Factory mode, sysprep -factory, which is used for the preinstallation of Windows in an OEM manufacturing environment.


For Terminal Server, you can install the following components:



LicenseServer. Set this to On if you are setting up the server as a license server for Terminal Server.



TerminalServer. Set this to On if you are setting up the server as a terminal server.





Important

When you install Terminal Server through Unattended Setup, it is installed by default with Internet Explorer Enhanced Security Configuration enabled for administrators, and disabled for users. To change Internet Explorer Enhanced Security Configuration during Unattended Setup, you can configure IEHArdenUser and IEHArdenAdmin, also found in the [Components] section of the answer file. For more information about Internet Explorer Enhanced Security Configuration settings, see "Internet Explorer Enhanced Security Configuration" in Help and Support Center for Windows Server 2003.




TSWebClient. Set this to On to install the ActiveX control and sample pages for hosting Remote Desktop client connections over the Web.



IEHardenUser. This is set to Off by default, which removes the Internet Explorer Enhanced Security Configuration from members of the Restricted Users and Guests groups. For more information about Internet Explorer Enhanced Security Configuration settings, see "Internet Explorer Enhanced Security Configuration" in Help and Support Center for Windows Server 2003.



IEHardenAdmin. This is set to On by default, which applies the Internet Explorer Enhanced Security Configuration to members of the Administrators and Power Users groups. For more information about Internet Explorer Enhanced Security Configuration settings, see "Internet Explorer Enhanced Security Configuration" in Help and Support Center for Windows Server 2003.




[TerminalServices]

If you set the TerminalServer entry to On in the answer file, you also need to set the following entries in the [TerminalServices] section:





Note

You can also set these settings through the TSCC. If these settings are changed in TSCC after the installation, the new settings take precedence.




AllowConnections. When set to 1 this entry enables Terminal Server by allowing connections. The default for this setting is 0. You can also set this through Group Policy.



LicensingMode. This setting configures how Terminal Services manages CALs — PerDevice or PerUser. The default for this setting is PerDevice. For more information about choosing a licensing mode, see "Choosing the Licensing Model" earlier in this chapter.



PermissionsSetting. This setting allows you to choose the security mode for Terminal Server users during terminal server sessions. This entry maps to the Permission Compatibility setting in TSCC. The default setting for this entry is 0, which maps to Full Security in TSCC.





Important

Only set PermissionSetting to 1, which maps to Relaxed Security in TSCC, if you are running older applications and your testing has determined that your applications will not run properly with the setting at 0. For more information, see "Designing the Terminal Server Configuration" later in this chapter.




Sysprep


Sysprep is an image-based method that you can use for clean installations of Windows Server 2003 with Terminal Server enabled. Using Sysprep is the quickest way to install Terminal Server along with many applications. Sysprep is a good choice for installing Terminal Server if, for example, you are deploying a terminal server farm.

If you plan to use a single image for many server configurations, you can use Sysprep in factory mode. For Terminal Server, you can configure the entries in the [Components] section of the Winbom.ini file for use with Sysprep in factory mode. These settings are the same as for the [Components] section of the Unattend.txt file for Unattended Setup discussed earlier in this section. For more information about using Sysprep for automated installations, see "Designing Image-based Installations with Sysprep" in Automating and Customizing Installations of this kit.


RIS


RIS requires the deployment of a network infrastructure specifically for its use and requires that you install Active Directory in your organization. Plan to use RIS for the automated installation of Terminal Server only if you are planning to use it throughout your organization for installing Windows Server 2003. If you do plan to use RIS for installing Terminal Server, you need to be sure to image a terminal server that does not already have licenses. You need to install licenses on the servers after the installation. For more information about using RIS for automated installations, see "Designing RIS Installations" in Automating and Customizing Installations of this kit.


Upgrading to Windows Server 2003 Terminal Server


The best way to install Terminal Server is by performing a clean installation. However, if you already have a Windows 2000 Terminal Services in Application Mode or Windows NT 4.0 Terminal Server Edition infrastructure in place, you might want to perform an upgrade. There are a number of other reasons why you might perform an upgrade, for example, if you are transitioning gradually to Windows Server 2003 or if you want to retain the ability to use your older software and device drivers. If you are upgrading your terminal servers from Windows 2000 to Windows Server 2003, you must take into consideration a number of changes and new requirements with Windows Server 2003.





Note

When performing an operating system upgrade on a terminal server, the security template that is applied does not reset the access control lists (ACLs). This is in contrast to a non-Terminal Server upgrade, which resets the ACLs. If you are moving from Windows NT 4.0 Terminal Server Edition or Windows 2000 in Relaxed Security mode to Windows Server 2003 Terminal Server, consider performing a clean installation.


Upgrading Terminal Server Licensing


With Windows Server 2003, you must use a license server that is running Windows Server 2003. You can still issue licenses to Windows 2000 Terminal Server with a license server that is running Windows Server 2003, if you plan to gradually upgrade your terminal servers. Also, with Windows Server 2003 you no longer need to host your license server on a domain controller. For more information about choosing a host server for Terminal Server Licensing, see "Planning the License Server" earlier in this chapter.

Table 4.1 summarizes the licensing issues to be aware of when upgrading from Windows 2000 Terminal Services to Windows Server 2003 Terminal Server.
























Table 4.1: Licensing Issues for Upgrading Terminal Server

If you are...


You need to...


Gradually upgrading your terminal servers to Windows Server 2003 from Windows 2000.


Upgrade your license server to Windows Server 2003 at the same time that you upgrade the first terminal server. You can also ensure that the license server issues the appropriate CAL for Windows 2000 or Windows Server 2003 through Group Policy. For more information, see "Designing the Terminal Server Configuration" later in this chapter.


Performing an in-place upgrade of the domain controller that hosts Terminal Server Licensing.


Consider keeping your licenses on the same server whether or not you plan to host your license server on a domain controller. You can demote the domain controller either before or after you upgrade the server to Windows Server 2003 by using the Active Directory Installation Wizard (dcpromo.exe).

If you upgrade your license server, you must reactivate the license server.

For information about upgrading a domain controller, see "Upgrading Windows 2000 Domains to Windows Server 2003 Domains" in Designing and Deploying Directory and Security Services of this kit.


Performing a clean installation of the domain controller that hosts Terminal Server Licensing.


Determine where you want to host Terminal Server Licensing and whether you want an Enterprise License server or a Domain License server. You also need to migrate your licenses to the new server. For information about transferring licenses, see "Repeat the installation of a client license key pack" in Help and Support Center for Windows Server 2003.


Redeploying Terminal Server Licensing to a new server.


Determine where you want to host Terminal Server Licensing and whether you want an Enterprise License server or a Domain License server. You also need to migrate your licenses to the new server. For information about transferring licenses, see "Repeat the installation of a client license key pack" in Help and Support Center for Windows Server 2003.



Group Policy Upgrade Issues


Windows Server 2003 offers more Terminal Server-specific Group Policy settings than did earlier versions of the Windows operating system. Your initial Group Policy settings vary depending on whether you perform an upgrade or clean installation. When you upgrade your terminal servers to Windows Server 2003, the new Group Policy settings are left Not Configured rather than set to their default. When you perform a clean installation, the default settings are used. Carefully review the Group Policy settings for Terminal Server to choose the best settings for your environment. For more information, see "Planning Terminal Server User Rights and Logon" earlier in this chapter.

Permission Compatibility


If you are upgrading from Windows 2000 Terminal Services or Windows NT 4.0 Terminal Server Edition, and are planning to host the same applications with Windows Server 2003, be aware that, in order for them to work, some older applications require access to system resources, such as the registry, for members of the Users group on a terminal server. If your older applications require this type of access, you can control the Permission Compatibility setting in TSCC on the Server Configuration tab for application compatibility. This setting is set to Full Security by default, which restricts access to system resources.





Important

Do not set this setting to Relaxed Security unless you have performed thorough testing and have determined that your applications will not work properly otherwise. Relaxed Security mode gives users access to system components on the server, such as the ability to modify the system32 directory where operating system files are stored, access to the Program Files directories, and read/write access to registry settings in HKEY_LOCAL_MACHINE.


For more information about configuring this setting, see "Designing the Terminal Server Configuration" later in this chapter.

Automated Installation


If you are planning to use an automated installation method to upgrade your terminal servers, you can do this only by using Unattended Setup. For more information about using Unattended Setup with Terminal Server, see "Designing Application Installation" later in this chapter. For more information about installing Windows Server 2003 by using an automated installation method, see Automating and Customizing Installations of this kit.


Internet Explorer Enhanced Security Configuration


When you upgrade from Windows 2000 Terminal Services, Internet Explorer Enhanced Security Configuration is enabled for administrators and disabled for users by default. With this configuration, users are able to browse and download files from the Internet without restriction, but administrators cannot do so. For more information about Internet Explorer Enhanced Security Configuration settings, see "Internet Explorer Enhanced Security Configuration" in Help and Support Center for Windows Server 2003.


Designing Application Installation


There are several ways in which to install the applications you plan to host on the terminal server. The size of your deployment and whether you have Active Directory installed are factors in deciding which method to use.

Installing Applications Manually


With manual installations, in order for Terminal Services to replicate the necessary registry entries or .ini files for each user, the user must install the application by using Add or Remove Programs in Control Panel. You can also install applications from the command line by using the change user /install command, but using Add or Remove Programs is preferable.

Installing Applications Using Group Policy and Windows Installer


A recommended way to distribute applications to a server in a Terminal Services farm is to use Group Policy. Active Directory is required for this. By separating the terminal servers into their own OU, you can create a Group Policy object that is linked to only that OU, and you can then assign Windows Installer (.msi) packages to it. Assigned applications are installed on the server when the server is turned on. For more information, see "Assigned and published programs" in Help and Support Center for Windows Server 2003. For more information about deploying software using Group Policy, see "Deploying and upgrading software" in Help and Support Center for Windows Server 2003 and "Deploying a Managed Software Environment" in Designing a Managed Environment of this kit.





Note

Terminal Server cannot accept published programs because publishing occurs on a per-user basis. Additionally, you must assign programs on a per-computer basis, rather than on a per-user basis.


Some applications require a transform file (.mst) when when you install them by using Windows Installer. Transform files are modifications to .msi packages that you create to instruct Windows Installer to install the application and all the needed components locally on the terminal server. Test your application installation to determine if a transform file is needed. For more information about .mst files, see "Deploying a Managed Software Environment" in Designing a Managed Environment of this kit.


To create and install applications using an .mst file, see the Office 2000 Resource Kit at the MSDN Library link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. Search for the topics under "Installing Office in a Windows Terminal Server Environment" in the Office 2000 Resource Kit on this Web site.





Note

Microsoft Office XP installs and runs on a terminal server correctly without requiring a transform file.


Running Compatibility Scripts


If it is necessary to run application compatibility scripts for any of the applications that you are hosting with Terminal Server, you must run them after you install the application, but before you restart the server. For more information about compatibility scripts, see "Identifying Ideal Candidates for Hosting" earlier in this chapter and the Optimizing Applications for Windows 2000 Terminal Services link on the Web Resources page at Using Home Directories with Terminal Server" earlier in this chapter.

Supporting Multilingual and International Users


Windows Server 2003 with Terminal Server enabled offers multilingual support. Using this capability, Terminal Services can simultaneously serve users in any language that is installed on the server. Terminal servers that are running Windows Server 2003 can take advantage of the multilingual user interface (MUI). This interface allows you to install multiple languages on the system and configure them on a per user basis. You must load MUI to take advantage of this functionality, which simplifies the deployment of Terminal Services within a multinational organization. It is also recommended that you install the keyboard drivers for any language-specific keyboards that you use in your organization as part of the Terminal Services installation. You can support your users around the world who can understand and work in English by hosting all users on the International English version of Windows Server 2003. This ensures that the organization is not in violation of United States export laws regulating strong encryption. However, using the International English Version might be inadequate if the organization must provide support for different languages. By default, Terminal Server installs all the available keyboard layouts, including support for Asian non-Input Method Editor keyboards.


While loading the MUI, install all of the languages that you expect users to need. The installation copies the appropriate language DLLs and Help files. By using Regional and Language Options in Control Panel, users can select their default language and keyboard settings. Regional and Language Options also includes such settings as date and currency formatting. Because this setting is stored in the user profile, individual users can adjust the settings to match their locality. If a user has a roaming profile that specifies a different language than the language that is loaded in the user profile, then the system uses the default user language from the profile.





Important

Roaming users should not use Folder Redirection with MUI. If they do, they might create multiple language versions of My Documents and other peruser folders on the computer. If the user interface (UI) language files that are needed to support the roaming user's default UI language have not been installed on the computer, the localized names of the new folders might not display correctly.


For more information about MUI, see the MultiLanguage Version link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. For information about deploying MUI, see "Planning Multilingual Deployments" on the Web at http://www.microsoft.com/reskits.


Designing the Terminal Server Configuration


You can configure Terminal Services by using TSCC Microsoft Management Console (MMC) snap-in, Group Policy, or WMI. Some server configurations settings for Terminal Services, for example the Sessions settings, are also configurable for the user. Because the server settings can override the user settings, it is recommended that you set these settings on the server whenever possible.

Choosing a Terminal Server Configuration Tool


Choose a configuration tool based on your level of permission, the tasks you want to accomplish, and the level at which you want to apply settings. If you are a domain administrator configuring global settings on a number of terminal servers, it is recommended that you use Group Policy. WMI is a good choice for automating the configuring of global settings on a number of terminal servers if you are not a domain administrator and if you are familiar with scripting. However, you must be a local administrator on every computer you want to configure using WMI. You can also invoke WMI to configure settings automatically after you install Windows Server 2003 with an automated installation method. For more information about configuring automated installation to invoke scripts, see the design chapter in Automating and Customizing Installations that corresponds to the automated installation method you have chosen to use. The TSCC snap-in is an easy-to-use tool for configuring a single terminal server, and is useful for configuring unique settings for a particular server. Table 4.2 summarizes these tools, and the following sections describe each tool in further detail.





















Table 4.2: Benefit and Restriction Comparison for Terminal Server Configuration Tools

Tool


Benefits


Restrictions


Group Policy


Can centrally configure terminal servers and Terminal Server users by applying policies to OUs.

Always overrides configurations set by using other tools.


Administrator must be a domain administrator to apply Group Policy settings to OUs.

Must have Active Directory in place.


WMI Terminal Server provider


Can configure many terminal servers or Terminal Server users using scripts.


Administrator must know how to write scripts.


Terminal Server Connection Configuration snap-in


Can configure unique per-server settings.

Some configurations only available in TSCC snap-in.


Can be overwritten by Group Policy settings.

Can be applied only to a single terminal server and its users.

Cannot be used to configure a remote server.



Your choice of tools might also depend on your server environment or number of connections. Take the following information into consideration when making your choice:



In an operating system environment where only Windows Server 2003 is run, you can use Terminal Server Group Policy settings to configure all settings that apply across an OU. You can also configure individual Windows Server 2003 operating systems using Group Policy on the local Group Policy object.



In server environments where several different versions of the Windows operating system are run, you might need to use a combination of tools. For example, you might configure the Windows Server 2003 operating systems with Group Policy, while using TSCC to configure servers that are running earlier versions of Windows.



If you have two or more connections on the same computer, and you want to configure each connection differently, you cannot use Group Policy. Instead, use the TSCC tool, which allows you to configure Terminal Services settings on a per-connection basis.




Using Group Policy


You can use Group Policy to configure Terminal Server connection settings, set user policies, configure terminal server clusters, and manage Terminal Server sessions. You can apply Group Policy settings for users of a computer through the Remote Desktop Users group, for individual computers through local Group Policy, or for groups of computers through a Terminal Server OU. To set local policies for users of a particular computer, you must be an administrator for that computer. To set policies for an OU in a domain, you must be an administrator for that domain. Settings that are specific to Terminal Server are located under Computer Configuration/Administrative Templates/Windows Components/Terminal Services. For more information, see "Configuring Terminal Services with Group Policy" in Help and Support Center for Windows Server 2003.





Note

There are many new Group Policy settings with Windows Server 2003. If you are upgrading your terminal servers from Windows 2000, the new Group Policy settings will be set to Disabled by default. For new Windows Server 2003 deployments, the defaults are stated in the "Designing Terminal Server Connection Configurations" section later in this chapter.


Using the Terminal Services WMI provider

The Terminal Services WMI provider allows administrators to create custom scripts for configuring, managing, and querying terminal servers. It contains properties and methods that can perform the same tasks as Terminal Services configuration tools and command-line tools, but remotely and through scripted applications. A provider is an architectural element of WMI that extends the WMI schema of classes to allow WMI to work with new types of objects. The Terminal Services provider defines classes for querying and configuring Terminal Services. The Terminal Services WMI provider is defined in systemroot\System32\Wbem\tscfgwmi.mof. For more information about WMI, see "Configuring Terminal Services with WMI" in Help and Support Center for Windows Server 2003.





Note

Configuration settings applied with the Terminal Services WMI provider operate in the same order of precedence as they do if applied with the corresponding configuration tool. In general, Group Policy settings always override settings applied with WMI. For more information about using WMI, see the TechNet Script Center link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.



Using the TSCC snap-in

With the TSCC snap-in you can configure the RDP connection parameters and connection permissions for the terminal server. You can apply settings only to a single terminal server and its users, however, and you cannot use TSCC to configure a remote server. In addition, there are several settings that you can set only by using TSCC. For more information, see "Configuring Terminal Services with TSCC" in Help and Support Center for Windows Server 2003.


Designing Terminal Server Connection Configurations


Use the following guidelines to design the configuration of the connections to your terminal servers. If you are using TSCC to configure a single server, you can use the Terminal Services Connection Wizard to configure these settings when you create a new connection. For more information about configuring Terminal Server with TSCC when you create a new connection, see "Make a new connection" in Help and Support Center for Windows Server 2003. You can also use Group Policy or WMI to configure the connections to many terminal servers. For a job aid to assist you in recording your Terminal Server Group Policy configuration decisions, see "Group Policy Configuration Worksheet" (SDCTS_2.xls) on the Windows Server 2003 Deployment Kit companion CD (or see "Group Policy Configuration Worksheet" on the Web at http://www.microsoft.com/reskit).

Data Encryption


You can assign data transfer encryption levels between the Remote Desktop client and Terminal Server by using either Group Policy or TSCC. The default RDP encryption level is Client Compatible. You can choose one of the following possible choices for encryption:



FIPS Compliant. Encrypts traffic between client and server to meet the Federal Information Processing Standard 140-1 (FIPS 140-1). Use this level when Terminal Services connections require the highest degree of encryption, such as those required by the U.S. federal government.



Client Compatible. With Client Compatible encryption, traffic between the client and the server is encrypted using the RC4 algorithm and the strongest key the client supports (40-bit, 56-bit, or 128 bit). The server negotiates with the client to determine the key strength on connection, however the server does not accept non-encrypted client connections.



High. Traffic in both directions is encrypted using the RC4 algorithm and a 128-bit key only. If a client does not support 128-bit encryption, it is not permitted to connect.



Low. Traffic from the client to the server only is encrypted, at the strongest key that the client supports. This can improve performance on the client because the client does not have to decrypt the screen update data coming from the server. The client still encrypts the keystroke and mouse data that it sends to the server. This also allows you to use products to improve performance over a WAN, for example to use between a branch and a home office. Use this setting only if you are planning to use these products. A malicious user can monitor documents and data coming from the server over the link if this setting is used.




On the General tab of TSCC or on the Data Encryption property page of the Terminal Services Connection Wizard, the Use standard Windows authentication check box is cleared by default. If you select this check box, lower security authentication mechanisms are permitted.

Logon Settings


By default, users are allowed access to the terminal server using the information that they provided to log on to their remote desktop client. For a more secure system, you can require users to provide logon credentials to access the terminal server.

You can allow access to the server based on the credentials provided here by clicking the Always use the following logon information radio button on the Logon Settings tab of TSCC or by enabling the Always prompt client for password upon connection Group Policy setting located in the Encryption and Security folder under Terminal Services in Computer Configuration. Use one of these options only if you are hosting an application that requires a password for access. For more information, see "Planning Terminal Server User Rights and Logon" earlier in this chapter.

Remote Procedure Call (RPC) Security Policy


You can enable this Group Policy setting to allow Terminal Server to accept only authenticated and encrypted requests. It is recommended that you enable this setting for increased security.

Sessions


You can set Terminal Server time-out and reconnection settings on the server to help manage the number of sessions held by a terminal server at any one time, to help manage unreliable connections for remote users, or to reduce the impact on the CPU of many users logging on to the server at the same time. You can set most of these settings by using TSCC or Group Policy. Exceptions are noted.





Note

You can also set these settings per user through Group Policy User Configuration and through Active Directory Users and Computers user properties. However, the Group Policy computer settings listed here take precedence over user settings.


End a disconnected session

You can set a limit on the time that a disconnected session continues to exist on the server. There can be many reasons why a session becomes disconnected, for example if a user's computer fails or if the user places the session into a disconnected state in order to access the same session from another location. The programs and processes that the user had running before the disconnection continue to run during a disconnected session. Because a user can have a disconnected session running on the server without realizing it, it is best to set a limit on how long disconnected sessions continue to run on the server. However, by setting this as high as possible you can achieve better server performance by reducing the additional CPU usage needed when a user reconnects to the server.


Active session limit

You can set a limit on how long a user can maintain an active session with the server. If you choose Never, the server allows an active session to continue forever.

Idle session limit

You can set a limit on how long an idle session remains open. An idle session occurs if there has been no mouse or keyboard activity for a certain period of time. This can indicate that the user has stepped away from the computer, presenting someone else with the opportunity to use his or her session. When a session has been idle for more time than you have specified, the user is notified and given two minutes to place the session back into an active state. If the two minutes elapse, the server disconnects or ends the session, depending on the settings you choose. Just as with choosing a timeframe for ending a disconnected session, it is important to understand users' work patterns and needs when choosing a limit for idle sessions.





Note

In a load-balanced farm, an idle session cannot be moved to a different server within the farm.


Session reconnection

By default, users can reconnect to a disconnected session from a computer other that the one from which they originally connected to the session. However, if a user connects from a Citrix ICA client, you can restrict the user to reconnecting only from the computer that originally connected to the session. This setting does not apply to Windows clients.

Session limit behavior

If you choose to enforce session limits for your users, you can ensure that users do not choose to have their sessions end when the connection to the server is broken for whatever reason. This way, you can be sure that all users can pick up where they left off in the event of a server failure, thereby reducing the loss of work and helpdesk incidents. If you choose to have sessions disconnect, you can use TSCC or Group Policy to specify the amount of time the session remains in a disconnected state.

Shut down options

You can use the following two Group Policy settings, found in the Terminal Services folder under Computer Configuration/Administrative Templates/Windows Components, to remove items from the Start menu and Shut Down dialog box so that users cannot use certain methods to disconnect or log off from their session:



Enable the Remove Windows Security item from the Start menu policy to prevent users from unintentionally logging off of Terminal Server.



Enable the Remove Disconnect option from Shut Down dialog policy to prevent users from using this method to disconnect from Terminal Server.



Automatic reconnection

You can allow a session to automatically reconnect to Terminal Server if the network connection is lost.


User Environment


Use the following settings to control the users' desktop environment.

Launch application on connection

If you are hosting a single application with Terminal Server, for example a line-of-business application or an application for task workers who use the server for only one thing, you can have that application start automatically when the user logs on. This eliminates the possibility of the user running unauthorized applications on the server or accessing other parts of the server or the network through the server. For information about how to start an application on connection, see "Specify a program to start when the user logs on" in Help and Support Center for Windows Server 2003. For more information about automatic logon, see "Planning Terminal Server User Rights and Logon" earlier in this chapter. You can configure this setting by using Group Policy (which you can apply to both computers and users), TSCC, and for users through the Remote Desktop Connection tool.

Desktop wallpaper

By default, sessions connecting to Windows Server 2003 Terminal Server do not display desktop wallpaper. For sessions connecting to servers running previous versions of Windows server operating systems and clients running Windows XP Professional or earlier, you can accomplish this by using Group Policy. For more information, see "Enforce removal of Remote Desktop wallpaper" in Help and Support Center for Windows Server 2003.





Note

In Windows 2000 you can disable desktop wallpaper on the client from the Environment tab of the Terminal Services Connection Configuration tool.


Remote Control


You can use Remote Control to control or troubleshoot a user's session from a remote location. You can configure this setting by using Group Policy settings (which you can apply to both computers and users) or TSCC. If you choose to enable this in your organization, you can configure this setting in the following ways:



Full Control with user's permission



Full Control without user's permission



View Session with user's permission



View Session without user's permission



It is recommended that you configure this setting so that the user's permission is required to allow another person to access their computer through Remote Control. Keep in mind that even if you require a user to give permission, the user can choose to allow anyone who has acquired the correct permissions to access his or her computer. Also, some countries and regions have laws that do not allow the View Session with user's permission setting. If your organization has offices in several countries and regions, check the local laws before configuring Remote Control in this way. For more information about configuring sessions for Remote Control, see "Configure remote control settings" in Help and Support Center for Windows Server 2003.


Client Settings


You can use the settings discussed in this section to control certain aspects of the user experience and allow users to perform certain operations through their desktop computer rather than through the server.

Client/Server data redirection

You can use data redirection with Terminal Server to enable users to access and use resources from their desktop computers rather than from the terminal server. The most notable of these resources is printing, but you can also enable drive, audio, smart card, and clipboard redirection to the client computer. In general, restricting user's options to only those required to do their jobs can minimize the likelihood of introducing a vulnerability to the system. You can configure most of these settings through Group Policy (which you can apply to computers only) or TSCC. Exceptions are noted.





Note

You can also configure redirection for disk drives, printer, and serial ports by using the Remote Desktop Connection tool on the client. For more information, see "Configuring Remote Desktop Connection" later in this chapter.


Table 4.3 summarizes the data redirection settings.







































Table 4.3: Data Redirection Settings

Data redirection type


Characteristics


Time zone


Only configurable by using Group Policy.

By default the session time zone is the same as the time zone of the terminal server. This can be an issue if you are using Terminal Server for remote or mobile users, especially when your line-of-business applications (for example, financial applications) have time dependencies.


Clipboard


By default, you can copy and paste between the terminal server and the Remote Desktop client Disable this ability if you have sensitive data on the terminal server that should not be shared outside of the application in which it is used.


Smart card


Only configurable by using Group Policy.

By default the ability to log on to the Remote Desktop client is allowed. For more information about using smart card with Terminal Server, see the "Planning Network Security Components" earlier in this chapter.


Audio


By default, users cannot play audio on the Remote Desktop client. The sound plays on the server rather than the client computer. If you enable this setting, users can specify on the Remote Desktop Connection tool whether to play audio at their computer or the server, or to not have the sound play at all.


Serial port


By default, Terminal Server allows users to redirect data to peripherals attached to the serial (COM) port. Disable this capability unless there is a requirement for it. This prevents users from printing or copying sensitive data stored on the terminal server, and reduces vulnerabilities to security threats that could access your computer through these ports.


Client printer


By default, users can redirect print jobs to a printer attached to their client computer. Unless users need to print to a local printer, disable this capability so that users cannot print or copy sensitive data stored on the terminal server.


Parallel port


By default, Terminal Server allows users to redirect data to peripherals attached to the parallel (LPT) port. Disable this capability unless there is a requirement for it. This prevents users from printing or copying sensitive data stored on the terminal server, and reduces vulnerabilities to security threats that could access your computer through these ports.


Drive


By default, Terminal Server allows users to redirect data to the drives on the client computer. Unless there is a requirement for this, you should disable this capability so that users cannot copy sensitive data stored on the terminal server onto their local computer.


Default printer


By default, Terminal Server designates the client default printer as the default printer in a session. Unless users need to be able to print to a local printer, disable this capability so that users cannot print or copy sensitive data stored on the terminal server.


Color depth

You can reduce or increase the maximum color depth depending on your bandwidth and fidelity requirements (greater color depth requires more bandwidth and resources on the terminal server).


Number of connections


By default, an unlimited number of sessions are permitted on the terminal server. Restricting the number of sessions improves the performance of Terminal Server because fewer sessions are demanding system resources.

You can configure this setting in the Terminal Services folder of the Group Policy Object Editor. In TSCC, you can configure the number of settings on the Network Adapter tab. You can also select the network adapter you want to use for the RDP connection traffic.

Permissions


You can use TSCC to change your permissions lists by adding and removing users and groups. You can also customize the permissions for users or groups on a per-connection basis. It is recommended that you give permissions to as few users and groups as is necessary, and to give those users and groups the lowest level permissions necessary for them to do their jobs. For more information about how to set permissions, see the topics under "Managing permissions on connections" in Help and Support Center for Windows Server 2003.


Designing Server Setting Configurations


Use the following guidelines to design the configuration of your terminal servers.

Keep-Alive Connections


Configure this Group Policy setting to Enabled to ensure that the session state remains consistent with the client state. Use this setting only if you are having problems with users who cannot reconnect.

Temporary Folders


These settings can be set in the Server Settings folder of TSCC or in the Temporary Folders node of the Terminal Services administrative template in the Group Policy Object Editor. In TSCC, both of these settings are configured Yes by default, which means that temporary folders are used per session and deleted upon logging off. It is recommended that you keep the default settings unless there is a compelling business reason to change them.

Delete or retain temporary folders when exiting It is recommended that you configure your servers so that the data stored in the temporary folder for user sessions is deleted when users log off. This provides added security by eliminating a point of access for user data. It also provides a way to manage the load on the server, because temporary folders tend to grow quickly in size in a multiuser environment. If you are using Group Policy to set this setting (set to Disable to delete temporary folders), you must also configure the server to use per-session temporary folders.

Use separate temporary folders for each session This setting keeps each session's temporary folders in a separate folder, which enables you to configure the server to delete temporary folders when a single user logs off without affecting other users' sessions.


Active Desktop


You can restrict users from using Active Desktop by using TSCC or Group Policy under User Configuration/Administrative Templates/Desktop/Active Desktop. Active Desktop allows users to choose JPEG and HTML wallpaper, both of which can affect performance for the user because of the amount of data that needs to transfer from the server to the desktop. The default setting is Enable. It is recommended that you disable Active Desktop.

Session Directory Settings


If you are load balancing several terminal servers and using Session Directory, you can use TSCC or Group Policy to configure the servers to use Session Directory. Session Directory is a database that tracks user sessions that are running on load-balanced terminal servers. For more information about using Session Directory (including configuring Session Directory), see "Load Balancing Terminal Servers" earlier in this chapter. For more information about Session Directory, see the "Session Directory and Load Balancing Using Windows Server 2003 Terminal Server" white paper at the Terminal Services link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Licensing


Use the following settings to configure the license server for Terminal Server. Most of these settings can be configured only through Group Policy. Exceptions are noted.

Licensing Mode You can set the licensing mode to Per Device or Per User through the TSCC Server Settings folder. For more information about licensing modes for Terminal Server, see "Choosing the Licensing Model" earlier in this chapter.

License Server Security Group Enabling this Group Policy setting and applying it to your license server creates a local group called Terminal Services Computers. The license server issues licenses only to the terminal servers in this group. You must add both the terminal servers for which you need to provide licenses and any license servers that might need to acquire licenses to this group for each license server. For ease of management in a large Terminal Server deployment, create an Active Directory global group named Terminal Server Licensing and add all of your terminal servers and all of your license servers to this group. Then add this group to the Terminal Services Computers group of each license server. Whenever you deploy a new terminal server or license server, if you add it to the Terminal Server Licensing group, it automatically appears in the Terminal Services Computers group for each license server.

Prevent License Upgrade In an environment with both Windows Server 2003 and Windows 2000 Terminal Server, enable this Group Policy setting to prevent the license server from handing out Windows Server 2003 CALs to terminal servers that are running Windows 2000.


Limit users to one remote session


By default, the TSCC setting that restricts users to one session is set to Yes. This ensures that a user who disconnects can reconnect to the same session. This also conserves server resources by keeping the number of sessions on your server to a known number. You can enforce this setting domain-wide by using Group Policy. Limit users to one session unless you have a valid business reason for allowing more than one.

Permission Compatibility


This TSCC setting is set to Full Security by default. It restricts access to system resources, such as the registry, to members of the Users group on a terminal server.





Important

Although some older applications require such access, do not set this setting to Relaxed Security unless you have determined through testing that your applications do not work properly in Full Security mode.


Home Directory


Use this Group Policy setting to set the path for storing your user home directories. For more information about planning for storage of home directories, see "Using Home Directories with Terminal Server" earlier in this chapter.

Roaming Profiles


Use this Group Policy setting to set the path for storing your roaming user profiles. For more information about planning for storage of roaming user profiles, see "Using User Profiles" earlier in this chapter.

Using Software Restriction Policies


Software restriction policies, which are new with Windows XP and Windows Server 2003, enable you to identify software running on computers in your domain and to control whether a user can run them. Restricting certain types of applications can, for example, protect your organization against viruses. As a way to lock down the user environment on a terminal server, you can set up software restriction policies that allow users to run only specific applications on the server.

Software restriction policies are located in the Group Policy Object Editor under Windows Settings/Security Settings. Windows Installer operates with applications permitted by these Software Restriction Policies. For more information, see "Software restriction policies" in Help and Support Center for Windows Server 2003.


You can use software restriction policies with Terminal Server by using path rules, as shown in Table 4.4. These rules allow groups of users, when separated into different OUs, to access only the applications or application components that you want the groups of users to access on the server. For example, a company has a terminal server with a line-of-business application and a few productivity applications for the use of the accounts payable department. The company has decided that account managers need access to all of the available applications for that department, but the data-entry workers in that department need access only to the line-of-business application. The company sets the default rule to Disallowed and configures the software restriction policies as outlined in the following table.






















































Table 4.4: Example Software Restriction Policy Configuration

Path Rule


Security Level


Terminal Server OU


%windir%


Unrestricted


%windir%\regedit.exe


Disallowed


%windir%\system32\cmd.exe


Disallowed


%windir%\system32\command.com


Disallowed


%windir%\system32\dllcache


Disallowed


%windir%\system32\gpresult.exe


Disallowed


%windir%\system32\gpupdate.exe


Disallowed


%ProgramFiles%\Windows NT\Accessories


Unrestricted


Data Entry OU


%ProgramFiles%\Accounts Payable Software


Unrestricted


Account Managers OU


%ProgramFiles%\Microsoft Office\Office


Unrestricted


%ProgramFiles%\Internet Explorer


Unrestricted


Configuring Terminal Server for Differing Time Zones


By default Terminal Server keeps track of time according to the time zone in which it has been configured, rather than on a per-user basis. This can be a problem when a user connects to a terminal server outside of the time zone in which the user is located because the local computer uses the time configured on the terminal server rather than the local time. If you are hosting time-sensitive applications on your terminal server or if you have processes in place that depend on the user's current local time, such as financial systems and calendaring, you might want to enable the Allow Time Zone Redirection Group Policy setting. This policy is located in Windows Components/Terminal Services. With this setting enabled, Terminal Services uses the server base time on the terminal server and the client time zone information to calculate the time on the session.

/ 122