Using GPOs to Configure Terminal Services

Since Microsoft first released Windows NT Server 4.0, Terminal Server Edition (WTS) in 1998, the company has greatly improved the client experience for people who use RDP to connect to terminal servers. In Windows Server 2003, the RDP client is almost as capable as the ICA client used to connect to Citrix MetaFrame servers, lacking support only for application publishing and Seamless Windows. If you're unfamiliar with MetaFrame, application publishing enables a connection to one application on a terminal server, and Seamless Windows lets end users maintain multiple connections to a terminal server that all connect to the same session and thus don't multiply resource usage.

However, Microsoft historically hasn't paid as much attention to improving server management in WTS and Windows 2000 Server Terminal Services. NT 4.0 predated WTS, so the core NT OS has no terminal server management capabilities—even user account management must be done on a WTS machine or by using the WTS-capable User Account Manager. Win2K includes support for Terminal Services in the core OS, but the server-management tools are suitable for managing only a small number of users or servers because you must configure Terminal Services settings separately for each account or machine. Because Terminal Services settings such as the profile path aren't exposed through Active Directory Service Interfaces (ADSI), you can't script server management beyond what's possible with the command-line tools. This restriction is tolerable if you plan to stay with the default settings or if you have only two or three user accounts or servers to configure. But configuring and managing more user settings and terminal servers consistently can get a bit complicated.

Windows 2003 has done a lot to make terminal servers—and user account settings that apply to Terminal Services—more manageable by exposing many settings through ADSI and Windows Management Instrumentation (WMI). You can use administrative scripts to manage these settings, or you can use Group Policy Objects (GPOs) that you can apply to organizational units (OUs). I introduce you to some GPOs for managing settings for users and computers and show you how to apply them to perform common tasks.

Locating Terminal Services Policies
When you open Group Policy Editor (GPE) on a Windows 2003 computer, you'll see a new folder—Administrative TemplatesWindows ComponentsTerminal Services—under both the Computer Configuration and User Configuration folders. Figure 1, page 92, shows the settings available in the Computer ConfigurationAdministrative TemplatesWindows ComponentsTerminal Services folder. A few of these settings are duplicated in the User ConfigurationAdministrative TemplatesWindows ComponentsTerminal Services folder. The Computer Configuration settings are organized into several Terminal Services subfolders. Web Table 1 (http://www.winnetmag.com, InstantDoc ID 38284) lists the location of both the Computer Configuration and User Configuration Terminal Services settings.

To configure a setting, double-click it to open its Properties dialog box, then select Enable or Disable as appropriate. You might need to provide additional information for some settings; for example, to set user home directories for terminal sessions, you must provide the local or network path and—assuming that you're using a network location for home directories—the network drive letter to which you want to map the path. Although most settings apply to only Windows 2003 terminal servers or Windows XP Remote Desktop Connection, a few settings (e.g., the option to remove the Disconnect button from the Start menu) can apply to Win2K terminal servers. The version requirements are on each policy's Properties dialog box.

If you've ever edited the Terminal Services default user and terminal server settings, you know that a precedence of control exists for settings that you can configure for both servers and users. Typically, if a setting exists for both servers and users (as the default printer mapping settings do), the user setting takes precedence. You can use Terminal Services Configuration to override the user setting and give the server setting precedence. If you don't configure a GPO, whichever settings you've chosen to have precedence will control. However, when you configure a GPO, the GPO setting takes precedence over any settings you've edited through Terminal Services Configuration or through the user account properties, whether you enable or disable the GPO. If you've configured the same setting for both users and computers (possible with a few settings, such as those that manage remote control functionality), the computer settings take precedence over the user settings. (If you're linking GPOs to different containers in the domain, the policy-inheritance rules in place apply. If you're not accustomed to working with GPOs, see Getting Started With Win2K, "Group Policy," March 2000, http://www.winnetmag.com, InstantDoc ID 8144.)

Always be careful when you enable or disable policies because the wording of the GPOs can be confusing. For example, if you configure the setting for using smart cards with a terminal server and want to make sure smart cards are supported, you must disable the Do Not Allow Smart Card Redirection Policy.

Applying GPOs to Terminal Servers
To apply GPOs to your terminal servers, you first must create a terminal servers OU and, if needed, a terminal server clients OU. Open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, and right-click the domain's icon in the left-hand pane. From the context menu, choose New, Organizational Unit. Name the new OU TerminalServers or something equally descriptive, and put all the application servers into it.

Terminal Services has no user-specific settings, so you might be able to get by with simply configuring policies for the terminal servers. However, you might choose not to configure all settings (such as those related to remote control of user sessions) at the computer level. You can apply per-user settings in several ways. One option is to create an OU for people allowed to log on to terminal servers. However, AD objects can be in only one OU, and putting people into a Terminal Services—specific OU might not be practical. Another option is to apply settings to the user OUs that you set up and use the loopback policy to make sure that the appropriate settings are applied when the users log on to terminal servers. To use loopback processing, you need to enable the Group Policy Loopback Policy Processing Mode on the Terminal Servers OU. This policy, found in Computer ConfigurationAdministrative TemplatesSystemGroup Policy, controls how user policies are applied to special-purpose computers such as terminal servers. To make sure that the terminal server policies take precedence, go to the policy's Settings tab and choose Replace from the drop-down menu.

After you create the user and terminal server OUs, you're ready to apply new policies to those OUs. I show you how to configure the servers because that's what most policies apply to. Right-click the TerminalServers OU and choose Properties. Select the Group Policy tab to open the dialog box that Figure 2, page 92, shows. Click New to create a new GPO (the figure shows a new GPO called TS Policies), then click Edit to return to the Group Policy Object Editor screen that Figure 1 shows.

Now you're ready to configure your new policy settings. The following configuration examples will get you started:

Tuning remote control settings. Remote control lets an administrator connect to a user's session to see what the user is doing or interact with the session directly. If you use the default settings, a user must explicitly permit the administrator to take remote control of his or her session, and the administrator can interact with that session. To change these default settings for the OU, go to Computer ConfigurationAdministrative TemplatesWindowsComponentsTerminal Services and enable Sets rules for remote control of Terminal Services user sessions, as Figure 3 shows. From the Options drop-down list, you can choose to completely disable remote control or you can choose settings from one of two main groups: Full Control, which lets the administrator interact with the user's session, and View Session, which lets the administrator watch what the user is doing but not take action. Within those two groups, you can specify whether the user must explicitly permit the administrator to take remote control of his or her session or whether the administrator can connect to the session without getting permission. (These settings are also available under User ConfigurationAdministrative TemplatesWindowsComponentsTerminal Services. If you set policies in both places, the computer policies apply.)

Setting a profile path and home directory for terminal sessions. Migrating profile paths from WTS to Terminal Services used to be painful because the Terminal Services profile path—distinct from the user profile path—wasn't exposed as a property of the user account object in ADSI; therefore, you could configure the profile path only by editing the user account properties either through the GUI or from the Tsprof command-line tool. This information is now available to group policies. The policies controlling user profiles and home directories are in the root Terminal Services folder in Computer ConfigurationAdministrative TemplatesWindows Components. Enable Set Path for TS Roaming Profiles and TS User Home Directory. To configure the profile path, include the computer name and path to the profile directory; the server will fill in the username automatically. If the path you provide doesn't exist (or the server can't reach it), the account will use local profiles.

The same process applies to setting up the home directory—enable the policy, type the Universal Naming Convention (UNC) name for the network share, and assign a local drive letter, if necessary (for applications that demand a drive letter). I don't generally recommend putting the user home directory on the local terminal server unless you have no other options; doing so gives users separate home directories depending on which server they're connected to, complicating backups and making locating user files difficult.

An Evolving Solution
Each generation of Terminal Services gets closer to being a complete solution, even for large organizations with many users. Although Windows 2003 Terminal Services still has some loopholes that third-party products can fill, adding some serious server and group management tools has done a lot to make configuring a lot of servers or user accounts much easier.