User Policies Group Policies | Terminal Services for Microsoft Windows Server 2003: Advanced Technical Design Guide (Advanced Technical Design Guide series)

User Policies / Group Policies

While user profiles allow users to customize the settings of their own environments, policies allow you (the administrator) to force settings in your users' environments. Policies (and their mandatory configuration settings) can be applied to servers globally, affecting all users that logon, or conditionally, affecting only specific users that logon. This conditional application can be based on user accounts, group memberships, or OU membership.

While most of the policy settings that are used to restrict or control a user's environment are available in policies from NT 4.0 through Windows 2003, some Group Policy settings discussed in this chapter are only available when to Windows Server 2003-based Terminal Servers that are members of a Windows 2003-based Active Directory domain.

Windows User Policies

Before we look at the details of how Microsoft Windows policies work, it's important to understand the differences between policies and user profiles.

Differences between Windows User Policies and Profiles

Both policies and user profiles affect registry settings. A user profile contains registry settings (in the ntuser.dat file) that are used to create the user's unique HKEY_CURRENT_USER registry hive when they log on. Policies also contain registry settings. They dictate which values are or are not allowed in the HKEY_CURRENT_USER registry hive as its being created from the user profile. Policies can also affect computer-wide HKEY_LOCAL_MACHINE settings, which are applied as the computer is booted before any users log on.

Application settings and configurations that are maintained in the registry can be set with either a user profile or a policy. If there is a conflict, the policy setting will take precedence over the user profile setting. (Registry settings for user can also be manipulated via logon scripts, which will be covered later in this chapter).

A user might configure his desktop background to be bright red, thus setting the bright red color value in a desktop settings registry key in the user's HKEY_CURRENT_USER registry hive. This updated value would become part of the user's profile, taking effect at every logon. At any time, the user could decide to change the desktop background color.

However, if you wanted to force the user's desktop to be a specific color, you would apply a policy. The policy would affect the exact same value in the same registry location as when the user set it (in their profile), except that the policy could not be changed by the user. That's in essence what a policy is—an administrator's way to force settings onto users.

Of course, you don't generally use policies to set the desktop color in Windows. You would use policies to set elements that affect how the users use the system such as Start menu items, file save locations, search options, and local drive access.

User Profile	Policy

Applied to a user	Applied to a computer, group, or user
Only one per user	Many can be layered per user
Settings are the user's choice	Settings are the administrator's choice
Affects the user's registry hive	Affects the user's or server's registry hive
Registry settings, folders, files	Registry settings only

Figure 6.9: Differences between profiles and policies

People often wonder whether they should use profiles or policies to manage the user environment. In the real world, the two are meant to complement each other and are used together. Situations are rare in which one is used to the exclusion of the other.

Creating and Editing Windows Policies

In Windows 2000/2003 environments, policies are created and managed via an MMC snap-in called gpedit.msc. Since policies are essentially no more than a collection of registry keys and values, policy editing snap-ins are merely graphical interfaces that allow you to set registry values. These registry values can then be directly applied to the local server or saved as policy files.

When editing and creating policies, you'll need at least one "ADM" policy template file. ADM files contain all of the policy settings and options, as well as the corresponding registry keys and values needed to create a policy. ADM template files are added as plug-ins to the policy editing utilities. Without any ADM template files plugged-in, the policy editing tools are useless, like the MMC without any snap-ins. Once the ADM files are plugged-in to the policy editing utility, you can point-and-click your way through the configuration of policies.

ADM policy templates are simply text files with the ".adm" extension, such as winnt.adm or common.adm. The MMC-based policy editors for Windows 2000 and 2003 come with several ADM files plugged-in out of the box. These default ADM files allow you to configure policies for several Windows options. However, if you have other applications installed, such as Microsoft Word, you'll probably want to extend your policy editor to include Microsoft Word options. Since the default ADM templates only cover Windows options, you can't use them to configure any Microsoft Word options.

In order to create policies that include Microsoft Word options, you must obtain a Microsoft Word ADM policy template file. There are hundreds of Microsoft Word templates available. You can download the "official" ones from Microsoft's web site. (They are included as part of the Office Resource Kit.) As soon as you add the Microsoft Word ADM template to your policy editing utility, you will instantly see options for configuring Microsoft Word settings. For example with Microsoft Word, these policy settings include paths to office assistants, the ability to disable certain features, and menu options.

You will need to find (or create) ADM policy templates for all the applications that you want to regulate with policies. Check out the THIN list at http://thethin.net for a great collection of ADM policy templates.

ADM policy template files essentially are nothing more than interfaces that provide you a graphical means of setting and forcing desktop and application settings onto users.

Why should you care about user policy design?

Now that you understand the basics of what policies are, you can appreciate the two reasons that you need to think about user policy design on your system:

Policies affect users' ability to customize their own environments.
Policies affect the security of your system.

Users' Ability to Customize Their Environment

If policies are too restrictive, users will not be able to do their jobs or fully use the system. Many over-zealous administrators go extremes when implementing policies, not realizing, for example, that users need the ability to access local drives, the control panel, or printer settings.

Security

User profiles and policies will directly affect the options and settings users see in their Terminal Server sessions. Properly designed policies will allow users to use the servers without risk of them changing inappropriate settings or accessing unwanted areas.

Shane Broomhall, a Citrix and Terminal Server instructor, says it best:

Most likely, you have a certain user in your environment with a copy of "MCSE for Complete Brain-Dead Idiots in 24 Hours" on his desk. This person is the really dangerous one. The one with a little knowledge and even less common sense. The one who, just by reading one thing, can completely break his desktop computer. From your perspective, if this person has broken his desktop by playing around with it (because it was not locked down) it's no big deal, because he has only really affected himself. However, now that you're using Terminal Servers, when this user does the same thing with a session desktop that has not been locked down properly, he's affecting potentially hundreds of other users. It is this user that forces us to spend time designing policies and profiles.

What are the user policy design options?

When it comes down to actually designing your policies, you have a few options. To decide on the type that best fits your environment, you first need to understand the options and how they are applied to users.

Note

(This book is not meant to be an exhaustive study of Windows 2003 policies. Rather, we review the basics and focus on the specifics and best practices that you should know in order to implement policies in a Terminal Server environment.)

What type of Windows 2003 Policies will you use?

There are two types of policies that you can apply in Windows 2000/2003 environments: local policies and group policies. Both affect the registry settings of your Terminal Servers. Let's highlight the differences between the two.

Windows 2003 Local Computer (System) Policies

Local computer policies are a fancy way of saying "the local registry settings" of a Windows 2003 computer. They are applied with the Group Policy MMC snap-in (gpedit.msc). By default, there is no shortcut for this snap-in. You have to launch it manually (Start | Run | gpedit.msc).

Changing settings of the local computer policy sets registry values on the local server. After you are done changing policy settings, you can simply close the Group Policy editor. Nothing needs to be saved since the Group Policy editor (in this case) is basically a direct connection with the local computer's registry.

The downside to editing the registry directly with Group Policy editor is that any policy settings you change will only apply to the local computer.

Advantages of Local Computer Policies

Simple to apply.
Easy to change.
Work well for single-server environments.
Allow each server to have unique policy settings.

Disadvantages of Local Computer Policies

Must be manually configured at every server.
Since these settings affect every user that logs on to the server, all users get the same settings.
Do not scale very well.

Windows 2003 Group Policies

If your Terminal Servers are part of an Active Directory domain (whether Windows 2000 or Windows 2003-based), policy application becomes flexible. In Active Directory environments, policies can be stored in the directory as "Group Policy Objects." A Group Policy Object (GPO) is a single policy file containing policy settings for users and computers. GPOs are stored in the directory itself, and there is no limit to the number that can be stored. Once they are created and stored in the directory, GPOs are applied to Active Directory Sites, Domains, or Organizational Units. The policies defined within the GPO apply to those objects (such as users and computers) that are in the container where they are applied.

In small environments (1, 2 or even 3 servers), it might not be necessary to implement GPOs. As your environment grows, you'll find it is much easier to put your server into a specific OU and find it "auto-magically" configured like the other servers. This approach is the surest way to ensure that your server settings are identical between servers without having to manually configure or verify them all.

Note

(Terminal Servers running on Windows Server 2003 can receive policies from Domain Controllers and Active Directories running on Windows 2000, and vice-versa.)

Don't let the name fool you. Group Policy Objects have nothing to do with Windows user groups. The word "Group" in Group Policy Objects derives from the fact that a GPO is a policy applied to a "group" of objects.

Advantages of Group Policy

Ensures uniform settings across Terminal Servers
Changes to Server settings are done in one place instead of server-by-server
Ensures that only administrators with rights to modify the GPO can modify the server settings
Extremely flexible
Granular application

Disadvantages of Group Policy

Requires Active Directory.
Requires the ability to edit a GPO (rights and skill)
If different settings are required on different servers the GPOs will have to be filtered or multiple GPOs will be required

How will you apply policies?

Before applying any policies in your environment, you need to understand how they will affect servers and users. Since you can apply policies to servers, sites, domains or OUs, you must know the precedence that each takes when multiple policies are applied to the same server.

Policies are applied in the following order:

Local policies (stored in the local server's registry and configured via the gpedit.msc MMC snap-in).
Site (GPOs applied to the AD site to which the server belongs).
Domain (GPOs applied to the AD domain to which the server belongs).
Organizational Unit (GPOs applied to OUs that contain the server).

Such architecture allows you to create extremely flexible policies. For example, you can put all of your Terminal Servers into one OU. Then, you can create a locked-down Group Policy Object and apply it to the OU, effectively securing your Terminal Servers while not restricting user access to other systems not part of that OU.

Because policies can be applied at multiple levels, designs can become complex very quickly when you apply different policies at different levels to the same objects.

The details of Active Directory GPO design will not be covered in this book. If you plan to make heavy use of them, there are several excellent white papers on Microsoft's website that explain how they are applied and how settings are inherited between levels. GPOs are often used with great success in Terminal Server environments.

When applying policies to Terminal Servers, the biggest design decision that you will have to make is whether: (1) you will require different policy settings for different groups of users; or (2) whether all users using the server will receive the same policy.

Typically, you would only use a local policy if you do not have Active Directory or have a small single-server or (at most) a couple of servers in your environment. Once an environment begins to grow the granularity level of the policies generally does also.

Let's assume that you have a small two server environment that will host 50 users running a single application. In this environment, a local system policy may be adequate since few (if any) different policy settings will be required for different groups of users.

On the other hand, what if you have an environment with 50 servers spread across three clusters and numerous types of users using various applications and configurations? In this scenario it is more likely that you'll need the ability to filter policies based on group membership within the domain. Local policies cannot accommodate here since they affect every user that logs on and they can't differentiate between users or groups. You will have to use domain-based GPOs to achieve the results you are looking for.

Applying Policies to Users on a Terminal Server

Remember that each group policy object has two sections—a section that contains computer settings and a section that contains user settings.

What happens when a user from one OU (with a GPO applied) logs on to a Terminal Server that's in another OU (with another GPO applied)? Logically, you would think that the settings from the user section of the GPO applied to the user's OU would apply to the user, and the settings from the computer section of the GPO applied to the computer's OU would apply to the computer. Unfortunately, that's not how it works at all.

When a user logs on to a computer that's part of an Active Directory, the GPO that's applied is determined by the location of the user's account object in Active Directory. If a user object is located in one OU and the Terminal Server (or any machine they log on to for that matter) is in another OU, the Group Policy applied to the user is applied as a result of the OU that the user object resides in and not the OU that the Terminal Server resides in.

This could be a problem for an administrator attempting to lock down a Terminal Server desktop without affecting users when they log on to their normal workstations.

To remedy this, you can configure a GPO to merge the settings from the Group Policy of the user's OU and the Group Policy of the computer's OU. Alternately, you can configure the GPO applied to the computer's OU so that it completely replaces the user's policy. You thus completely control users' Terminal Server policy without the interference of their original policies.

To do this, enable "loopback processing" in the GPO that's applied to the Terminal Server's OU. Loopback processing works in one of two modes:

Replace (default) specifies that user settings normally applied from the user's GPO are ignored and replaced with the user settings as configured in this GPO instead.
Merge specifies that user settings from the user's "normal" GPO will be applied along with the user settings from the GPO applied to the Terminal Server. If any two settings conflict with each other, the Terminal Server's GPO takes precedence.

Loopback processing is almost always a necessity in Terminal Server environments of any size. Without loopback settings enabled, you would have the same policy settings (and restrictions) applied to users at their workstations' desktops and on their Terminal Server sessions.

In most environments, you will need to implement much more restrictive settings on the Terminal Servers as compared to users' desktop workstations.

Loopback Processing Group Policy Location

Advantages of Using the Loopback Processing Mode

Allows you to specify GPO settings that are specific to the Terminal Server session.
Allows for the merging or complete replacement of user GPO settings.

Disadvantages of Using the Loopback Processing Mode

User environments will have different configurations between the Terminal Server sessions and the normal desktops.
Additional complexity can be harder to administer.

What settings will you configure in the policy?

If your Windows 2003 Terminal Servers are members of a Windows 2003-based Active Directory, then you'll find that there are dozens of Terminal Server-specific policy settings available to you. These policies work just as any other policies in Windows. When enabled or disabled they basically edit the registry, which in turn changes the way the system works or is configured.

One interesting fact about these "Terminal Server" policy objects is that they're only meant to control Windows 2003 servers with Terminal Server installed. They're not meant to control the administrative Remote Desktop connection.

These settings can be found by using the group policy editor and navigating to the following location:

Computer Configuration | Administrative Templates | Windows Components | Terminal Services

In the root of this folder, you'll see a number of policy options and several subfolders. Let's take a look at the various Terminal Server options that are available.

Keep Alive-Connections: These settings enable the server to determine the proper session state when the client disconnects its session. It is possible for a session that is disconnected to remain active and not go into a disconnected state, causing the client attempting to reconnect to wind up with a new session instead of reconnecting to the disconnected session.

By default, keep-alive connections are disabled and can only be enabled by editing the registry or enabling this policy.

Automatic Reconnection: When enabled, this policy configures RDC clients that get disconnected to automatically attempt to reconnect to the server, such as when there is a temporary loss of network connectivity. If a network disconnect occurs when this policy is enabled, the client will attempt to reconnect to the server 20 times at 5 second intervals.

Enabling this policy is basically equivalent to enabling the "Reconnect if connection is dropped" feature on the Experience tab in Remote Desktop Connection client.

If the policy is disabled, automatic reconnection of clients is not allowed, even if the client is configured for it.

This feature is especially useful to remote and Internet users that may experience frequent drops or short disconnects from the server.

Restrict Terminal Services users to a single remote session: As the name implies, this policy will limit each user account to a single session on your Terminal Server. When enabled, it will verify that a user does not have an existing session open before allowing him to load his session. If the user has an existing session, the new session connection is connected to the existing session and the first connection to that session is dropped.

This policy is ideal for environments in which users share passwords or are known to leave sessions open, only to open new ones from other workstations.

If you leave this policy set as "Not Configured," you can control this functionality with the Terminal Services Configuration MMC snap-in.

Enforce Removal of Remote Desktop Wallpaper: This option allows you disable all those pretty background pictures that users tend to put on their desktops. On a normal workstation wallpaper might not be a big deal, but in a Terminal Server environment these images eat up bandwidth and can degrade session performance. When enabled, a user does not have the ability to set or use wallpaper for their desktop session.

When disabled or not configured, the Wallpaper for the session will be displayed.

Deny log off of an Administrator logged on to the console session: One of the new features of Windows Server 2003 is the ability for administrators to connect to the server console (or session 0) via an RDP session. When this happens, the server's real console screen displays the "locked" message just like a normally locked computer. Enabling this policy prevents someone from being able to kick off the remote session 0 session by unlocking the server console.

When not configured or disabled, the default action is to allow one administrator to unlock or logoff another administrator, potentially causing her to loose work since she might be logged in and active when she's kicked off.

Limit number of connections: This policy allows you to specify the maximum number of Terminal Server sessions that can run on a server. This is not a "per-user" setting, rather, it limits the total sessions on the server.

If you read the product documentation from Microsoft, they make a point to tell you that valid values for this policy range from 1 to 999,999 (just in case you have a really, really big server).

If this policy is left unconfigured or disabled, no limit is specified and users can keep connecting until the server runs out of system resources.

Limit maximum color depth: As its name implies, this policy allows you to place a server-wide limit on the maximum color depth for Terminal Server sessions. Enforcing this limit can save bandwidth and generally works well in low-bandwidth environments.

By default, Windows 2003 Terminal Servers will limit client connections to 16-bit color, although Terminal Server will support up to 24-bit color.

Keep in mind that this is a maximum setting. If you configure it for 24-bit color, clients that can't aren't configured for that much will still be able to connect at lower color depths.

Allow users to connect remotely using Terminal Services: Quite simply, disabling this policy lets you "turn off" access to a server via Terminal Services. If you set this policy to "disabled," existing sessions will continue to function on the Terminal Server even though it will deny new connection attempts.

This policy shouldn't be used to manage Terminal Server access. Most people use it when applying policies to non-Terminal Servers as a way to ensure that no users accidentally connect to them.

Do not allow local administrators to customize permissions: This policy is useful if you have people on your IT staff who like to play with permissions. It sets the security on individual connections (as configured via the Terminal Services Configuration tool) to "read only." When enabled, local administrators of a server will not be able to modify any of the security settings found in the tool.

The default action for Terminal Server is to allow local administrators to modify these settings as needed.

If you do choose to enable this policy, keep in mind that you'll have to wait for a Terminal Server to get the new policy update if you disable this policy in order to make "a quick change" to the security settings of a server.

Remove Windows security item from Start menu: This policy (one of the few that also works on Windows 2000 Terminal Servers), removes the Windows security shortcut from the Start menu. (Remember that in Terminal Server sessions the "Windows security" item is the equivalent of pressing CTRL+ALT+DEL on a regular computer.) Enabling this policy can help you prevent users from getting confused and accidentally logging off the server.

If you enable this policy, users will have to log off a computer by typing the Windows security hotkey sequence, which is usually CTRL+ALT+END. Alternately, you might decide to tell users to disconnect from their sessions and let the server automatically log off disconnected users after a few minutes.

Remove Disconnect option from Shut Down dialogue: Whenever a user selects "log off" from a Terminal Server session, he is presented with a log off dialogue that allows him to either log off or disconnect his session. If you want to force users to logoff (by not allowing them to leave a disconnected session), you can enable this policy.

This policy only removes the disconnect option from that one dialog box. It does prevent a user from disconnecting his session via other means (by simply closing the client window, for example). In practice, this policy is really only a good choice in thin client-type environments.

Set path for TS Roaming Profiles: This setting overrides the Profile Path or TS Profile Path that's set as part of a user attribute whenever a user logs onto this server via Terminal Services. It's a lifesaver in several different scenarios, including:

Users who access two different versions of Terminal Severs and you don't want to mix the Profiles between the two systems.
Users who access two different sets of Terminal Servers across WAN links and you want to use Roaming Profiles without having to copy the profile across the WAN link.
You have two sets of servers that require different User Profile settings that conflict with each other. This is common when running multiple versions of the same application.

When enabled, you'll be asked to provide a UNC path to where you want to store the master copy of the roaming profile. This should be formatted as \\ServerName\ShareName. Do not append the %username% variable or anything else to the end. The Terminal Server will use this share location as the root directory then add the user profiles in directories matching their usernames under the root folder.

If this policy is set to Not Configured or Disabled, then the Terminal Server will store profiles as it normally would.

TS User Home Directory: Much like the previous policy, this policy overrides the home folder attribute normally associated with the user's domain or AD account object. This policy allows you to specify a "custom" home folder for users that log on to the specific Terminal Servers where this policy is applied.

Like the profile override policy, you'll need to specify a UNC path to the share that will hold users' home folders (such as \\ServerName\ShareName) and pick a drive letter that you want to use for the mapping. If you choose a local path, (such as c:\homedirs), the drive letter field is ignored and local path is used instead. This approach is basically the same as when you configure a home folder as part of a user's attribute in Active Directory, except that in this policy you don't specify any user-specific variables at the end of the path (such as %USERNAME%). Terminal Services automatically appends that at logon and connects the user to the proper folder within the share.

If this policy is Enabled, Terminal Services creates the home folder in the specified location as the user connects to the server. The home folder path for each user is the specified "Home Dir Root Path" field of this policy with the user's alias appended to the end.

Using this policy to override the default home folders is useful in several situations. We'll review those situations in the "Home Folders" section of this chapter.

Set rules for remote control of Terminal Server user sessions: This policy allows you to configure what type of access (if any) IT staff or users will have to a user's session when they remote control (or "shadow") it. It's important to note that this setting does not give you the ability to determine who can remote control which users' sessions. Instead, it sets the rules for the remote control session after the permissions for remote control have already been established in the Terminal Services Configuration tool.

Just like the normal configurations allowed with remote control settings, when this policy is enabled, you have five options to choose from:

No remote control allowed disables remote control of sessions on the server.
Full Control with user's permission causes a little box to pop up on the user's screen when a remote control attempt is made. If the user accepts the remote control, then the remote controller can view the user's session and control his mouse and keyboard remotely.
Full Control without user's permission is identical to the previous option, except that the user is not given the option to accept or decline the remote control.
View Session with user's permission is also similar to the previous options, although this policy setting prevents remote controllers from actually being able to take control of a remote user's keyboard and mouse. This is like a "remote viewing" option.
View Session without user's permission is the same as the previous option, except that the user is not given the choice as to whether they want to be remotely viewed.

Remote control rules policy setting is also available in the "User Configuration" section of a group policy object (User Configuration | Administrative Templates | Windows Components | Terminal Services). If there is ever a situation in which this policy setting is configured differently in the Computer Configuration and User Configuration settings of the same policy, then the configuration in the Computer Configuration section will override the setting in the User Configuration. (This is one of the rare instances in which the "most restrictive" rule does not apply.)

In cases where this policy setting conflicts with the remote control properties of the user object and/or the connection properties, the most restrictive settings are enforced. This allows you to apply the settings at the appropriate layer to fit your exact requirements.

Start Program on Connection: This policy setting allows you to specify the "initial program" (as discussed throughout this book) that's run when a user connects to a Terminal Server. Enabling this policy and specifying a program to run causes the server automatically to run the program and obscure the desktop and Start menu from the user. If the application is closed, then the whole session is ended.

If this policy is enabled and the program specified in the path and working directory is not valid, then the user will be presented with an error message and the session will abort.

If the policy object is set to Disabled or Not Configured, the Terminal Services sessions will start with an entire desktop or with a program specified by the end user in the RDC client.

As for the previous policy, this policy setting can also be specified in the "User Configuration" section of a policy (User Configuration | Administrative Templates | Windows Components | Terminal Services). In cases where an initial program is specified in both locations, the server will override the User Configuration setting and run the program that's specified in the Computer Configuration setting.

Client/Server Data Redirection Policy Subfolder

The policy objects contained in this subfolder all deal with the virtual channels of the RDP protocol. All of these policy settings can also be configured as a property of the RDP listener port in the Terminal Services Configuration MMC snap-in. In case of a conflict, the most restrictive setting will take precedence. (After all, if you configure a port so that audio is disabled, then all audio will be disabled through that port regardless of what the policy says.

Allow Time Zone Redirection: One of the most useful enhancements that Microsoft added to Terminal Server in Windows 2003 is the ability for the server session's time zone to be dynamically set based on the client device's time zone. The clocks in users' local and remote applications can be the same, and that one Terminal Server can host users from multiple time zones.

By default, this automatic session time zone adjustment is disabled, and the session time zone is the same as the server time zone. However, enabling this policy setting will cause the server to calculate the proper time zone from the RDC client.

It's important to realize that this functionality is "time zone offset synchronization," not "clock synchronization." The server will look at the time zone of the client, and adjust the time zone of the session to match. If the server's clock is set correctly and if the server is configured for the proper time zone then everything will work out.

server base time + client time zone offset = actual session time

Time zone redirection tends to cause problems for some users. Generally when it is enabled you will receive several calls from users in the same time zone as the server complaining that their clocks are way off. This discrepancy can usually be traced back to the client computer's time zone being set incorrectly, fouling up the server's calculation. Remember that RDC client does not send its clock time to the server. It only sends its time zone, causing the server to adjust the session time regardless of what the client clock says.

Since this time zone synchronizing functionality is rather new, you need to have client software that supports it. Microsoft introduces this support in the "5.1" versions of the RDC client software.

Do not allow clipboard redirection: As the name implies, this policy setting allows you to disable the RDP virtual channel that is used for sharing clipboard contents (cut & paste) between the server and a client computer using a Terminal Services session. This functionality is enabled by default.

In the event of a policy setting conflicting with an RDP listener port setting, the most restrictive setting takes precedence.

Do Not Allow Smart Card Device Redirection: As discussed in Chapter 12, Windows 2000 and newer clients can use smart cards to authenticate to their Terminal Server sessions instead of standard (manual) credentials. Ordinarily, whether a user can use a smart card (or whether a user is forced to use a smart card) is configured as part of a user's Active Directory account object.

In some cases, you might want to prevent users from being able to use a smart card on some Terminal Servers, and enabling this policy setting allows you to do so.

Allow Audio Redirection: Audio redirection is a new feature of Windows Server 2003 that enables your users hear their session sounds on their local client devices (such as the Windows "ding!"). Enabling this policy setting turns on this functionality.

Audio redirection does consume bandwidth, so it should only be used when it's actually needed.

Enabling this policy does not automatically "force" users to hear audio. Instead, it gives them the option (via their client settings) of having audio redirected.

Similar to the other policy settings, you can also enable or disable audio redirection as part of the RDP listener port properties in the Terminal Services Configuration MMC snap-in. By default, audio redirection is enabled here. Conflicting settings revert to the most restrictive setting taking precedence.

Do Not Allow COM port, client printer, LPT port, or drive redirection: These four policy settings are grouped together here because they all are simple "on and off" switches for basic RDP functionality. As with the previous policy settings, if one of these settings is enabled then that particular virtual channel is disabled.

Also like the other settings, each of these four items can be configured as part of the RDP listener port's properties, and the most restrictive setting takes precedence when conflicts occur.

Do Not set Default Client Printer to be the Default in the session: By default, a Terminal Server will automatically set the client's default printer as their default printer within the Terminal Server session. This policy allows you to override that and not allow it to happen.

This setting is useful if the application you are running on the Terminal Server uses a local IP port or UNC on the server to send print jobs that you want to keep as the default.

Some people get confused by this setting since they enable it and the user's default printer still becomes the default in their session. This is often the case when the user has only one printer and no local printers are installed on the Terminal Server. The only printer available is the client's default printer and of course that has to become the default.

As with previous Policy settings, if this option is configured as "disabled" the exact opposite occurs and the user's client printer becomes their default. This setting can also be configured as part of the RDP listener port properties.

Encryption and Security Policy Subfolder

Based on the name, you would think that this section of the policy would involve some complexity, but it actually doesn't. It only has three available options, two of which have very little to do with server security and more to do with the traffic between the client and the server.

Always prompt client for password upon connection: If enabled, this policy setting tells the Terminal Server to ignore any credentials the client has passed to it, instead forcing them to log on to the Windows logon screen from the server when they make their connection. This option is generally used when you suspect that your users are using other peoples' machines with stored passwords on them.

If this setting is disabled, any credentials passed from the client will be used for authentication. Of course if there aren't any credentials passed to the server or the passed credentials are incorrect, the user will still be prompted for a username and password.

As with most of these policies this option can also be set in the Terminal Services Configuration tool.

Set client encryption level: This policy setting is very straightforward, allowing you to specify a minimum RDP protocol encryption level. The different levels (FIPS, Client, High, and Low) are detailed in Chapter 12.

If you enable this policy and the client device can't meet the minimum standard you've set, then the client connection will be refused. You can also enforce encryption levels on a per-connection basis as a property of the RDP listener port in the Terminal Services Configuration MMC snap-in. Conflicting settings between the two will cause whichever encryption scheme is more secure to be applied.

RPC Security Policy | Secure Server: This policy setting allows you to specify whether RPC calls to the Terminal Server must be secured. In Windows Server 2003 environments, this RPC interface is used for administration and configuration of Terminal Server settings and properties. While the details of a secure RPC environment are outside the scope of this book, enabling this setting will deny RPC requests unless they are secure. If this policy is set to "disabled" or not configured, the server will still request secure RPC connections at first, but will accept unsecured communications if secure ones are not available.

Licensing Policy Subfolder

The licensing subfolder of a Group Policy object contains two policy settings. (Unfortunately, the ability to specify a preferred licensing server is not one of them.)

License Server Security Group: As discussed in Chapter 4, one of the great new features of Terminal Server on Windows 2003 is your ability to control which servers are authorized to receive licenses from a TS License Server.

You can enable this functionality by enabling this policy setting on a TS Licensing Server. When you do this, a new local security group is created called "Terminal Services Computers." The license server will then only distribute licenses to Terminal Servers that are members of this local group. In order for your servers to be granted licenses, you'll have to add their domain computer accounts into this group. (Most people actually create a domain global group that contains Terminal Server computer accounts. They then place that global group into the Terminal Services Computers local group on each license server. That way, they can manage group memberships via the one global group instead manually at each license server.)

This license server security group feature is great for companies that buy li.censes by department. Since it's possible for one department's Terminal Servers to discover another department's TS license servers, licenses could be accidentally transferred across departments. This policy setting prevents that from happening.

If this setting is disabled or not configured, the license server will default to issuing a license to any server that requests one.

Prevent License Upgrade: This policy setting lets you prevent your license servers from "wasting" a Windows 2003 license on a Windows 2000 Terminal Server. If this option is disabled or not configured, the TS License Server will first try to issue a Windows 2000 CAL to Windows 2000 Terminal Servers but will "upgrade" to a Windows 2003 CAL if no Windows 2000 TS CALs are available. Chapter 4 explains this functionality.

Temporary Folders Policy Subfolder

This subfolder of a policy object delineates how temporary folders are handled in Terminal Server sessions. You won't usually need to change these settings unless you're dealing with a particularly crabby application.

Do not use temp folders per session: By default, a Windows 2003 Terminal Server assigns the user's TEMP and TMP variables to a location in the user's profile (%USERPROFILE%\Local Settings\Temp\<SessionID>). Enabling this policy setting lets you override the SessionID part of the TEMP path, turning it into %USERPROFILE%\Local Settings\Temp\, causing every user on the server to share the same temp folder.

If this policy is disabled or not configured, specific per-session temp folders are created for the user at each login.

Do not delete temporary folder on exit: By default, a user's temporary files and folders are deleted from a Terminal Server when the user logs off (helping to reduce the profile size). When enabled, this setting allows you to override that default behavior and causes the server to retain those files. The setting only works if you do not enable the "Do not use temp folders per session" policy. If that policy is enabled, this policy will not function.

Session Directory Subfolder

These policy settings allow you to configure your servers to participate in a Session Directory. As discussed in Chapters 3 and 7, the Session Directory directs users to the server hosting their previously-disconnected sessions in clustered environments.

These Session Directory policies only apply to Terminal Servers running the Enterprise or Data Center editions of Windows 2003, since the Standard edition does not have the ability to participate in a Session Directory.

The easiest way to apply these Session Directory policy settings is to create an OU for your Terminal Server cluster. Then, you can configure the settings for the entire cluster simply by changing the settings of a GPO applied to the OU. This OU-based cluster method is much easier then trying to configure GPO security based on computer names.

Terminal Server IP address redirection: This policy option lets you configure how the routing works in a Session Directory environment—either based on an IP address or routing token. If you're not yet familiar with the details of Session Directory, then this setting will be meaningless to you. Windows 2003's Session Directory is covered in Chapter 7.

If this is set to "Not Configured," the IP address redirection setting in the Terminal Services Configuration tool is used.

Join a Session Directory: As its name implies, enabling this policy setting will cause the target Terminal Server to participate in a Session Directory. This setting doesn't do any good on its own. You must configure the next two settings as well.

Session Directory Server: This setting is where you enter the name of the Windows 2003 server that's running the Session Directory service.

Session Directory Cluster Name: Since each Session Directory server can host multiple Session Directories, you also must specify the name of the specific cluster that you want the target Terminal Server to be part of.

Sessions Policy Subfolder

The final subfolder containing Terminal Services policy settings contains settings that apply to user sessions. There are five session settings available:

Set a time limit for disconnect sessions.
Set a time limit for active Terminal Services sessions.
Set a time limit for active but idle Terminal Services sessions.
Allow reconnection from the original client only.
Terminate the session when time limits are reached.

Within a policy file, sessions settings can be configured as a property of both the Computer Configuration (Computer Configuration | Administrative Templates | Windows Components | Terminal Services | Sessions) and User Configuration (User Configuration | Administrative Templates | Windows Components | Terminal Services | Sessions). If there are ever conflicting values within the same policy file, the computer policy will take precedence over the user setting.

In addition to being configured as part of a policy, these settings can be configured as part of the RDP listener port properties (Start | All Programs | Administrative Tools | Terminal Services Configuration | Connections | Right-click on the connection name | Properties | Sessions tab). They can also be configured as part of a user's AD account object (Active Directory Users and Computers MMC snap-in | Double-click on a user account | Sessions tab). In case of a conflict, the most-restrictive setting will take precedence.

Things to Consider when Designing User Policies

Now that you know what your user policy options are, you can begin the actual policy design process. As you design your policies, consider the following:

Will users run full desktops or just an individual application?
How important is security?

User Applications

If users are running full desktops on your Terminal Servers, it's important that you lock down those desktops with policies. On the other hand, if users only run an individual application then you don't need to worry as much about policies as you would with a full desktop.

Security

The tighter you lock down your policies, the more secure your environment will be. Of course this will also lead to a more restrictive, less flexible environment. See Chapter 12 for the full details about securing your Terminal Server environment.