Server Operating System

White Paper

Abstract

Policies can be implemented in a Terminal Server environment to control and limit the access that each user has while connected to a Terminal Server session. When implementing policies in a Terminal Server environment, additional planning and consideration is necessary to accommodate the multiuser environment presented by Terminal Server.

Introduction

Policies in a Terminal Server Environment

When users access a session through a Terminal Server, by default, they have access to all files on the Terminal Server. The actions of one user can have a detrimental effect on other users of the Terminal Server.

One of the methods that can be used to control the access of users to a Terminal Server is to implement policies for the Terminal Server sessions.

Unlike Windows NT® Server, Terminal Server does not download the policy to your local computer. This allows a great amount of flexibility: Users can have a flexible policy for their local workstations while at the same time have a locked-down policy when using a Terminal Server session.

Initial Planning and Consideration

When implementing policies in a Terminal Server environment, additional planning and consideration is necessary to accommodate various scenarios and networking environments.

Policies are implemented on a Terminal Server and the Terminal Server sessions in the same manner as they are implemented on a Windows NT Workstation or Windows NT Server. Furthermore, the same file (Ntconfig.pol) is used to determine policies in both Windows NT (Workstation and Server) and Terminal Server.

The implementation of a common policy in both Terminal Server and Windows NT (Workstations and Servers) prevents the flexibility necessary for many environments.

This document examines common issues encountered when implementing policies in a Terminal Server environment and discusses procedures that can increase the flexibility of policies.

Default Implementation of Policies

When a policy is implemented in a domain environment that contains Windows NT workstations, the Windows NT Workstation references the Ntconfig.pol file in the Netlogon share to receive its policies. A computer running Windows® Windows 95 or Windows 98 compute rin a domain environment receives its policy from the Config.pol file in the Netlogon share.

In addition, Windows NT Workstation stores profiles under Ntuser.dat, but Windows 9x computers store their profiles under User.dat. Both types of computers store their profiles in the user's profile path.

When policies are implemented, the respective user profile (Ntuser.dat or User.dat) is modified with the user-specific settings created by the policy.

Because Windows NT Workstation and Windows 9x computers reference different policy files and store settings in different .dat files, separate and unique policies are maintained for Windows NT workstations and Windows 9x computers.

Policies in a Terminal Server-only Environment

When a policy is implemented or a session created on a Terminal Server, the Terminal Server references the Ntconfig.pol file in the Netlogon share.

Profile settings for Terminal Server are stored under Ntuser.dat in the User's Terminal Server Profile path, which is defined in the User Manager extension for Terminal Server.

By default, Windows NT Workstation and Terminal Server share the same policy file, Ntconfig.pol.

Policies in a Windows NT \ Windows 9x \ Terminal Server Environment

When implementing policies in a mixed environment that contains Windows NT Workstations, Windows 9x, and Terminal Server(s), the following issues occur:

Windows NT Workstations and Terminal Server(s) reference the same Ntconfig.pol file. In essence, a user receives the same user-specific policy settings when logging on to a Terminal Server as when logging on to a Windows NT Workstation.

The same user Profile could be used for a Windows NT Workstation session that is used for a Terminal Server session. User-specific settings saved while logged on to a Terminal Server session could be applied to a Windows NT Workstation setting and vice versa.

When implementing policies on a Terminal Server, there are no files shared with the files that are used when policies are implemented on a Windows 9x computer. As a result, there are no conflicts when policies are implemented for both Windows 9x computers and Terminal Servers.

Referencing a Terminal Server-Specific Policy

By default, Terminal Server references Ntconfig.pol located in the Netlogon share. This reference can be found in the registry, located at:

HKEY_LOCAL_MACHINE \System \CurrentControlSet Control\Update

Modifying the Policy Location and Name

To create separate policies for a Windows NT Workstation session and a Windows Terminal Server session for a user ID that may log on to both, modify the above registry key value to point to a different policy file for each Terminal Server.

The value for this registry key is modified on a computer-by-computer basis. To modify this value, use the System Policy Editor, and modify the update section found in the network section of the default machine properties. The Common.adm administrative template defines this registry key.

If you are modifying multiple Terminal Servers, a utility such as Regini.exe can be used to modify the Terminal Server registries.

Consequences of Policy Location Modification

When the policy location is modified, the location of the new policy file needs to be considered. In the example provided in the appendix, a new policy file, Wtsconfig.pol, is created and stored in the Netlogon share of all domain controllers.

By storing the Terminal Server specific policy in the same location as other policy files (Ntconfig.pol and Config.pol), the advantages of Windows NT 4.0 domain replication are utilized.

If the policy file location references a location that does not include the policy file, no policy is applied for the logon.

Location of Profiles

Profiles store policy-specific information, which is updated each time a user logs off properly. In addition, previous settings in a profile are applied to the current logon session, provided a policy does not override the profile settings.

Local and Roaming Windows NT User Profiles

The type of Windows NT User Profile is determined in User Manager for Domains. If a user ID does not have a profile path specified, the profile is a local profile.

A local profile is stored in the %systemroot%\Profiles\ %username% directory as Ntuser.dat. Each local profile is specific to each computer.

A roaming profile is stored in a network share and is accessible regardless of which computer the logon process occurs on.

Local and Roaming Terminal Server Profiles

The location of Terminal Server profiles is determined in User Manager for Domains. The location of Terminal Server profiles can be determined only when accessing the User Manager from the User Manager that is provided with Terminal Server. The User Manager provided with Terminal Server includes the Terminal Server–specific User Manager extensions.

A local Terminal Server profile is stored in the %systemroot%\Profiles\%username% directory as Ntuser.dat. Each local profile is specific to each Terminal Server.

A roaming profile is stored in a network share and is accessible regardless of which Terminal Server the logon process occurs on.

Determining Which Profile Is Used

If the roaming Terminal Server profile cannot be found, the Windows NT Profile path is used. This may create a shared profile if both the Terminal Server profile and the Windows NT profile are roaming. If either the Terminal Server profile or the Windows NT profile are local profiles, it is not likely that the profiles are shared.

Sharing NT and Terminal Server Profiles

If a Windows NT profile and a Terminal Server profile share the same path, the profiles overlap. When this occurs, additional consideration must be taken when maintaining the Windows NT policy and the Terminal Server policy.

Policy Compatibility

When the Ntuser.dat file is shared between Terminal Server and Windows NT logon sessions and each type of session is managed by separate policies, care must be taken to ensure that the two separate policies are compatible.

Creating Compatible Policies

To create compatible policies, verify that all items that are modified in one policy are modified in the other policy. For example, if the Terminal Server policy has the "Hide all desktop icons" option selected, the Windows NT policy should either also have this item checked.

When the registry is modified through a policy, the registry stays modified, until it is unmodified through policies by clearing the check-box. There are three settings in a policy: A gray-box, a clear box, and a checked box. A gray box is not considered when a policy is applied (this increases the application of policies at logon time). A checked box implements the policy. A un-checked box reverses the implemented policy.

If you restrict a feature in one policy file but fail to modify the same feature in the other policy file, a restriction placed in one policy could affect the other policy file if the storage location of Ntuser.dat is the same for Windows NT and Terminal Server policies.

Appendix I: Sample Policies

Application Availability through Policies

When implementing Terminal Server, it is possible to assign applications based on group membership. A custom desktop or custom Start menu path can be used for each group that requires a separate group of applications.

The following example shows how to set up custom Start menu icons. In this example, it would be necessary to create a local folder on each Terminal Server for each group of unique applications.

Example: A folder named Acct could be created to contain the shortcuts needed by the accounting department; the Acct folder would contain shortcuts to all applications to which the accounting department would need access. A folder named Sales could contain shortcuts needed by the sales department. The policy for each Global Group would point to the folder containing shortcuts for that group.

Common Restrictions

When implementing Terminal Server, additional steps must be taken to restrict user access to the Terminal Server. To accomplish this, the .adm templates included with Terminal Server include additional settings to help restrict user access.

The ability to remove context menus (right-click) from the taskbar and desktop has been added to the default .adm files:

If your browser does not support inline frames, click here to view on a separate page.

Appendix II: Sample Administrative Template

When publishing applications such as Microsoft® Word and Microsoft Excel, it may be necessary to designate a default save and open location. Although the default save and open locations are in the registry, this information may not be included in the default .adm templates provided with Terminal Server.

To modify user-specific settings that are not included in the default .adm templates, a custom .adm template can be applied.

The .adm template provided below allows you to specify the default save and open location for both Word 97and Excel 97: