Chapter 3 - Managing User Work Environments

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

User work environments include the desktop items and settings, such as screen colors, mouse settings, window size and position, and network and printer connections.

You can use the following tools to manage user work environments on a Windows NT Server network:

  • User profiles

    The user profile contains all user-definable settings for the work environment of a computer running Windows NT, including display settings and network connections. All user-specific settings are automatically saved into the Profiles folder within the system root folder (typically C:\winnt\profiles).

  • System Policy Editor

    System policy enables you to control the user-definable settings in Windows NT and Windows 95 user profiles, as well as system configuration settings. You can use the System Policy Editor to change desktop settings and restrict what users can do from their desktops.

  • Logon scripts

    A logon script is a batch file (.bat) or executable (.exe) file that runs whenever a user logs on at any type of workstation on the network. The script can contain operating system commands, such as commands to make network connections or start applications.

  • Environment variables

    Environment variables specify the computer's search path, directory for temporary files, and other similar information.

User Profiles

On computers running Windows NT Workstation or Windows NT Server, user profiles automatically create and maintain the desktop settings for each user's work environment on the local computer. A user profile is created for each user when the user logs on to a computer for the first time.

User profiles provide several advantages to users:

  • When users log on to their workstations, they receive the desktop settings as they existed when they logged off.

  • Several users can use the same computer, and each receives a customized desktop when they log on.

  • User profiles can be stored on a server so that user profiles can follow users to any computer running the Windows NT version 4.0 platform on the network. These are called roaming user profiles.

As an administrative tool, user profiles provide these options:

  • You can create customized user profiles and assign them to users to provide consistent work environments that are appropriate to their tasks.

  • You can specify common group settings for all users.

  • You can assign mandatory user profiles to prevent users from changing any desktop settings.

User profiles can be used on computers running Windows 95, but they must be enabled before they are available. User profiles have no effect on computers running MS-DOS, UNIX, or OS/2.

For more information on using user profiles with computers running Windows 95, see "Using Windows 95 User Profiles on Windows NT Server Networks" later in this chapter.

Settings Saved in a User Profile

A user profile contains configuration preferences and options for each user: a snapshot of a user's desktop environment.

The following table describes the settings in a user profile.

Source

Parameters saved

Windows NT Explorer

All user-definable settings for Windows NT Explorer.

Taskbar

All personal program groups and their properties, all program items and their properties, and all Taskbar settings.

Printers Settings

Network printer connections.

Control Panel

All user-defined settings made in Control Panel.

Accessories

All user-specific application settings affecting the user's Windows NT environment, including Calculator, Clock, Notepad, Paint, and HyperTerminal, among others.

Windows NT-based applications

Any application written specifically for Windows can be designed so that it tracks application settings on a per-user basis. If this information exists, it is saved in the user profile.

Online Help bookmarks

Any bookmarks placed in the Windows NT Help system.

Structure of a User Profile

Every user profile begins as a copy of Default User, a default user profile stored on each computer running Windows NT Workstation or Windows NT Server. The NTuser.dat file within Default User displays configuration settings from the Windows NT Registry. Every user profile also uses the common program groups, contained in the All Users folder.

User Profile Folders

Every user profile begins as a copy of Default User, a default user profile stored on each computer running Windows NT Workstation or Windows NT Server. The Default User profile folder, user profile folders for each user, and All User profile folders are located in the Profiles folder in the system root (usually C:\Winnt). The Default User folder and individual user profile folders contain an NTuser.dat file plus a directory of links to desktop items.

Cc751447.xcp_d01(en-us,TechNet.10).gif 

The user profiles folders contain links to various desktop items.

User profile folder

Contents

Application Data

Application-specific data. For example, a customer dictionary. Application vendors decide what data to store in the User Profile folder.

Desktop

Desktop items, including files and shortcuts.

Favorites

Shortcuts to program items and favorite locations.

NetHood

Shortcuts to Network Neighborhood items.

Personal

Shortcuts to program items.

PrintHood

Shortcuts to printer folder items

Recent

Shortcuts to the most recently used items.

SendTo

Shortcuts to document items.

Start Menu

Shortcuts to program items.

Templates

Shortcuts to template items.

Note The NetHood, PrintHood, Recent, and Templates folders are hidden and, by default, do not appear in Windows NT Explorer. To view these folders and their contents in Windows Explorer, click Options on the View menu, and then click Show all files.

NTuser.dat File

The NTuser.dat file is the registry portion of the user profile. NTuser.dat is a cached copy of the Windows NT Registry HKEY_CURRENT_USER subtree on the local computer. The registry is a database repository for information about the computer's configuration, including the hardware, installed software, environment settings, and other information. In the registry, the settings that determine the work environment for the user who is currently logged on to the computer are stored in HKEY_CURRENT_USER.

Cc751447.xcp_d02(en-us,TechNet.10).gif 

All Users Folder

Although they are not copied to user profile folders, the settings in the All Users folder are used with user profile folders to create the user profile.

The Windows NT platform supports two program group types:

  • Common program groups are always available on a computer, no matter who is logged on. Only administrators can add, delete, and modify them.

  • Personal program groups are private to the user who creates them.

Common program groups are stored in the All Users folder under the Profiles folder. The All Users folder also contains settings for the Desktop and Start menu.

On computers running Windows NT Workstation or Windows NT Server, only members of the Administrators group can create common program groups.

For information on adding new program groups, see "To add a new submenu to the Programs menu" in Windows NT Help.

How Local User Profiles Are Created

The local user profile is the user profile stored on the computer under the user name in the Profiles folder. When no preconfigured server-based (roaming) user profile exists for a user, the first time a user logs on to a computer, a user profile folder is created for the user name. The contents of Default User are then copied to the new user profile folder. The user profile, along with the common program group settings in the All Users folder, create the user's desktop. When the user logs off, any changes made to the default settings during the session are saved to the new user profile folder. The user profile in Default User remains unchanged.

If the user has a user account on the local workstation in addition to a domain user account or more than one domain user account, the local user profile is different for each account because different user profiles are generated for each user that logs on. When the user logs off, changed settings are saved to only one user profile, depending on which account the user logged on to.

When a user has a local user profile on a computer, the user profile folder contains the NTuser.dat file and a transaction log file named NTuser.dat.LOG. The log file is used to provide fault tolerance, allowing Windows NT to recover if a problem occurs while the NTuser.dat file is being updated.

Cc751447.xcp_d03(en-us,TechNet.10).gif 

Using Roaming User Profiles

Roaming user profiles can be implemented in three ways:

  • Add a user profile path to each user account to automatically create an empty user profile folder named for the user in the server location and to allow users to create their own user profiles.

  • Add a user profile path to each user account and copy a preconfigured user profile to the user profile path specified in each user account.

  • Add a user profile path to each user account, copy a preconfigured user profile to the user profile path specified in each user account, and then rename the NTuser.dat file to NTuser.man in the user profile path specified in each user account. This creates a mandatory user profile.

In User Manager For Domains, you can assign a server location for user profiles. If you enter a user profile path into a user's domain account, a copy of the user's local user profile is saved both locally and in the user profile path location when the user logs off. The next time that user logs on, the user profile in the user profile path location is compared to the copy in the local user profile folder and the most recent copy of the user profile is opened. The local user profile becomes a roaming user profile by virtue of the centralized domain location. It is available wherever the user logs on, providing the server is available.

If the server is not available, the local cached copy of the roaming user profile is used. If the user has not logged on to the computer before, a new local user profile is created. In either case, if the centrally stored user profile is not available at logon, it is not updated when the user logs off. If the user profile is not downloaded due to server problems, it is not uploaded when the user logs off. The next time the user logs on, they must specify which user profile to use — the newer locally cached copy of the user profile or the older centrally stored copy.

To create a preconfigured roaming user profile, use User Manager for Domains to assign a server location for a user profile and then use the User Profile tab of the System option in Control Panel to copy a preconfigured user profile to the server. The first time the user logs on, instead of getting a copy of the Default Profile, the user gets a copy of the preconfigured user profile from the server. Thereafter, the user profile functions just like a standard roaming user profile. Each time the user logs off, the user profile is saved locally and is also copied to the server.

Note To copy a user profile, you must use the User Profile tab of the System option in Control Panel. You cannot use Windows NT Explorer or any other file management tool.

A mandatory user profile is just a preconfigured roaming user profile that the user cannot update. The user can still modify the desktop, but the changes are not saved when the user logs off. The next time the user logs on, the mandatory user profile is downloaded again. User profiles become mandatory when you rename the NTuser.dat file on the server to NTuser.man. This extension makes the user profile read-only.

The same mandatory user profile can be used by as many users as needed.

Tip When control over user choices and work styles is desirable for either security or to compensate for user computer skills, system policy offers more choices for control. You can select a subset of settings to control, and you can control both user and computer settings. For more information, see "System Policy" later in this chapter.

For information on modifying user accounts, see User Manager for Domains Help.

Adding the User Profile Path to User Accounts

In User Manager for Domains, you can use the User Environment Profile dialog box to add the user profile path location. Open the User Properties dialog box for a user account, and click the Profiles button to add the user profile path.

Cc751447.xcp_d04(en-us,TechNet.10).gif 

Use a full path in each user account:

\\server\share\profilename 

For share, create a Profiles folder if it does not already exist and share the folder with Everyone.

For profilename, use the user name for the user account.

The user profile path location can be on any server; it does not have to be a domain controller. When the user logs on, Windows NT Server checks the user's account to see if there is a user profile path. If the path exists, the user profile is located by the system.

For information on modifying user accounts, see User Manager for Domains Help.

Copying the User Profile to the Server Location

To provide a specific user profile for some users, copy the user profile to the proper location by running Control Panel, choosing System, and then selecting the User Profiles tab. This location must match the User Profile Path entry for the user's account in User Manager For Domains.

In the User Profiles tab in the System Properties dialog box, all user profiles that have been created on the computer are listed in the Profiles Stored On This Computer box.

To copy a specific user profile, click Copy To, and then either type the name of the destination folder or browse the network for it.

Cc751447.xcp_d05(en-us,TechNet.10).gif

For more information on creating preconfigured user profiles, see "Preparing Preconfigured Roaming and Mandatory User Profiles" later in this chapter.

For information on copying user profiles, see Control Panel Help.

Adding Users and Groups to the Permissions List for a Roaming User Profile

The System option in Control Panel also copies appropriate permissions along with the user profile so that users have access to the user profile. However, when you copy a user profile to a location for use by another user or group, you must add the user or group to the permissions list. The Permitted to use box shows the user who has permissions to use the user profile. Click Change to add the user or group to the permissions list for the user profile.

Cc751447.xcp_d06(en-us,TechNet.10).gif 

Note If you assign a roaming user profile path to a group, each time a group member logs off, his or her user profile is written over the centrally stored user profile. For this reason, it is best to make group user profiles mandatory, or use system policy to specify different settings for different groups.

For information about system policy, see "System Policy" later in this chapter.

For information about setting security permissions on folders and files, see Chapter 4, "Managing Shared Resources and Resource Security."

For information on adding users and groups to a permissions or auditing lists, see User Manager for Domains Help.

For information on modifying user accounts, see "To configure the user environment profile" in User Manager for Domains Help.

Changing the User Profile Type for Slow Connections

Users who log on to the network over slow links, such as when using a Remote Access Service (RAS) connection, can use their local user profile instead of slowing their logon for the process of downloading the roaming user profile from the server. When a user logs on under these conditions, a dialog box appears allowing the user to specify which user profile to load.

When already logged on, you can use the System option in Control Panel to change your user profile type from roaming to local and vice versa. The setting remains in effect until you change it. When you change the type from roaming to local, the cached copy of your roaming user profile is opened every time you log on, and changes are saved to that local user profile only.

For information on changing your profile type, see "To switch between a roaming and local user profile" in System Policy Editor Help.

Preparing Preconfigured Roaming and Mandatory User Profiles

Although you can use any account to create a preconfigured roaming or mandatory user profile, it is often more convenient and efficient to use a test account. For example, if you plan to create and maintain three different preconfigured roaming or mandatory user profiles for your sales, payroll, and production departments, create three different test accounts called Sales Profile, Payroll Profile, and Prod Profile. Then, log on with each account to create the appropriate user profile for the user group. After you log back on as Administrator, use User Manager for Domains to modify the user's individual accounts or the appropriate group account, and then use the User Profile tab of the System option in Control Panel to copy the user profiles to the appropriate server.

Allowing for Different Hardware Configurations

Because user profiles can be used on various types of workstations, you should keep in mind that these workstations can have different hardware configurations, particularly different video cards and display monitors.

Because a user profile determines screen placement and size of windows, the type of display hardware a workstation has affects how well the user profile works. For example, the window setup in a user profile created for a computer with a super-VGA screen may not look correct when loaded on a computer with a regular VGA monitor.

To prevent problems:

  • When creating or editing a user profile for a single user, use a computer with the same type of video hardware as the computer the user typically uses.

  • When creating a mandatory user profile for several users, create a single user profile for the whole group of users only if they all use computers with the same type of video hardware.

Deleting a User Profile

If you no longer want to use a roaming or mandatory user profile that is assigned to users delete the user profile path from the user accounts in User Manager for Domains.

To delete a user profile from the centrally stored location, use the User Profile tab of the System option in Control Panel.

For information on modifying user accounts, see User Manager for Domains Help.

Customizing the Default User Profile for All Computers on a Domain

If you want to create a customized domain-wide default user profile for all computers running Windows NT Workstation or Windows NT Server, you can create a customized user profile and copy it to the domain PDC using the User Profile tab of the System option in Control Panel.

Log on to any computer running Windows NT Workstation or Windows NT Server, create a custom user profile, and then log off. Log back on to the computer using the Administrator account, and use the User Profile tab of the System option in Control Panel to copy your customized version to the Netlogon folder in the system root folder on the PDC.

For example, if the domain controller is named Central, copy the user profile to \\Central\Netlogon\Default User. The Default User directory is created, and the links and NTuser.dat file are copied.

When you copy the user profile, in the Copy To dialog box you permit Everyone to use the user profile. This user profile is downloaded to the Default User (Network) folder on every computer at startup.

For information on customizing the Default User profile for all computers in a domain, see "To change the local default user profile" in System Policy Editor Help.

For information about synchronization, see Chapter 1, "Managing Windows NT Server Domains."

Customizing the Local Default User Profile for One Computer

You can customize a particular computer's default user profile when special circumstances require that a computer perform in a consistent way that is different from other computers. For example, if you want to have one computer with certain applications and settings preset for a specialized or dedicated task, you can create a custom user profile and copy it to the Default User folder.

System Default Profile

When Windows NT is running on a computer that no user is logged on to, a dialog box appears, prompting you to press CTRL+ALT+DEL to log on. This dialog box and other aspects of the Windows NT environment at this point, such as the screen's background color and its use of wallpaper and screen savers, are controlled by the system default profile. The settings for this profile are stored in System32\config\default. The system default profile can be changed by using Windows NT Registry Editor to edit the .Default key in HKEY_USERS.

For information about using Windows NT Registry Editor, see Appendix A, "Windows NT Registry."

Using Windows 95 User Profiles on Windows NT Server Networks

Unlike user profiles in Windows NT Workstation and Windows NT Server, which are automatic and always available, user profiles in Windows 95 must be enabled on the local computer using the Passwords option in Control Panel. Once enabled, user profiles are used as follows:

  • Windows 95 local user profiles operate the same way as user profiles operate in Windows NT Workstation and Windows NT Server.

  • Roaming user profiles can be used on a Windows NT Server network if Client for Microsoft Networks is selected as the primary network logon client, or on a NetWare network if Client for NetWare Networks is selected as the primary network logon client.

  • Mandatory user profiles can be used but must be created for each user.

Windows 95 and Windows NT User Profile Differences

Because of the differences between Windows 95 user profiles and Windows NT user profiles, you cannot create user profiles for Windows 95 clients on a computer running Windows NT Workstation or Windows NT Server.

Registry File Differences

Different files are used for the registry portion of user profiles in Windows 95 than are used in user profiles in Windows NT.

Windows NT Server

Windows 95

NTuser.dat

User.dat

NTuser.dat.LOG

User.da0

NTuser.man

User.man

Note The Windows 95 User.da0 and Windows NT Server files provides slightly different functionality. While Windows 95 writes a copy of User.dat to User.da0 each time the user logs off, Windows NT uses NTuser.dat.LOG as a transaction log file to provide fault tolerance. This allows Windows NT to recover the user profile if a problem occurs while Windows NT is updating NTuser.dat.

File Structure Differences

The same folder structure is used for both Windows NT and Windows 95 with one exception: Windows 95 does not support the Application Data folder.

Functional Differences

Windows NT and Windows 95 profiles have the following functional differences:

  • Windows 95 does not support common groups

  • Windows 95 user profiles do not copy all desktop items–only shortcut (.lnk) and program information (.pif) files.

  • Windows 95 user profiles don't support a centrally stored Default User profile.

  • Windows 95 clients don't use the Windows NT Server profile path to obtain roaming user profiles. They can be retrieved only from the user's home directory.

  • To use mandatory user profiles on computers running Windows 95 on a Windows NT Server network, an administrator must create a custom user profile for each user and copy the user profile files to each user's home directory.

For more information on common groups, see "All Users Folder" earlier in this chapter.

For more information on using a centrally stored Default User profile, see "Customizing the Default User Profile for All Computers on a Domain" earlier in this chapter.

For more information on Windows 95 user profiles, see the Windows 95 Resource Kit.

How User Profiles are Updated for Windows NT 4.0

When upgrading from Windows NT Server 3.5x to Windows NT Server 4.0, user profiles undergo format changes that consist of changing the user profile from a single file (version 3.5x) to a folder (version 4.0) containing the user profile plus a directory of links to various desktop items.

When roaming user profiles exist in Windows NT 3.5x, upgrading to version 4.0 has the following effects:

  • The original roaming user profile is retained in the same server location.

  • A new user profile is created in Windows NT 4.0 that consists of the original user profile updated to the Windows NT 4.0 format.

  • Both versions remain available to users, so they can continue to use computers running Windows NT 3.5x and receive their roaming user profiles. However, if a user uses both operating systems, the two user profile versions are stored and updated separately.

Note Although roaming user profiles from both Windows NT version 3.5x and 4.0 are available to users, local user profiles are converted to Windows NT version 4.0 user profile format.

File name extensions of user profiles in Windows NT 3.5x change to the 4.0 version of the user profile type, and the NTuser file is added to each user profile folder with the appropriate extension for a roaming or mandatory user profile.

Windows NT 3.5x type and file name

Windows NT 4.0 type, folder name, and NTuser file name and extension

Roaming/personal = username.usr

Roaming = username.pds
file name = NTuser.dat

Mandatory = username.man

Mandatory = username.pdm
file name = NTuser.man

Note The .pds and .pdm extensions for username files stand for profile directory structure and profile directory mandatory, respectively.

Logging on For the First Time After an Upgrade

The first time a user that has been using a Windows NT 3.5x roaming user profile logs on to a computer running Windows NT 4.0, a Windows NT version 4.0 user profile folder is created on the server. The user profile folder is named for the user name from the Windows NT 3.5x user profile, with the addition of a .pds extension. For example, if your Windows NT 3.5x user profiles is Joe.usr, a Joe.pds folder is created the first time Joe logs on to a computer running Windows NT 4.0. The Joe.pds folder is then propagated with the appropriate folders and files to create Joe's Windows NT 4.0 user profile.

You do not have to change the user profile path in User Manager for Domains. Each time Windows NT version 4.0 sees that your user account specifies a Windows NT 3.5x user profile (identifiable by a .usr extension), Windows NT automatically looks for the same user profile, but with a .pds extension. For example, if you log on to a computer running Windows NT Workstation version 4.0, and your user account specifies \\server\share\username.usr, Window NT looks for \\server\share\username.pds.

Mandatory User Profile Upgrade

Upgrading of mandatory user profiles from Windows NT Server version 3.5x to 4.0 is not automatic. The following steps explain how to set up a mandatory user profile in Windows NT Server 4.0 and have it coexist with a mandatory user profile created in Windows NT Server 3.x.

  • Log on to a computer and create a user profile with the settings you want for the mandatory user profile.

  • Log off the computer and log back on as Administrator.

  • Use the User Profile tab in the System option in Control Panel to copy the new user profile to the user profile path location. Give the new user profile folder the same name as the 3.5x user profile name, but add the .pdm extension (to keep the new user profile from overwriting the 3.5x user profile).

    \\server\share\profilename.pdm

  • In the new user profile folder, rename NTuser.dat to NTuser.man.

The first time a user logs on to a computer running Windows NT Workstation or Windows NT Server 4.0, the mandatory user profile is downloaded to the local computer.

The 3.5x user profile still exists as profilename.man in the same user profile path location. When the user logs on to a computer running Windows NT Workstation or Windows NT Server version 3.5x, the 3.5x version of the mandatory user profile is downloaded from the server.

Note An alternative to creating a new registry file (NTuser.man) for the mandatory user is to follow the preceding steps, and then copy the 3.5x mandatory user profile into the user profile path folder as NTuser.man (replacing the existing file). However, because 3.5x mandatory user profiles undergo an upgrade the first time they are downloaded to a computer running Windows NT Workstation or Windows NT Server 4.0 and because the server copy of the user profile is never overwritten by the local user profile, the upgrade process must take place each time the user logs on. To avoid this inconvenience, it is best to create a new mandatory user profile when upgrading.

For information on modifying multiple user accounts, see User Manager for Domains Help.

System Policy as an Alternative to Mandatory User Profiles

When upgrading to Windows NT Server 4.0, you might consider the added control of system policy as a replacement for old mandatory user profiles. With system policy, you can mandate all the user profile settings of a mandatory user profile, plus control computer-specific settings as well.

How User Profiles are Opened and Saved

The sequence for opening user profiles at logon is shown in the following chart.

Cc751447.xcp_d07(en-us,TechNet.10).gif

The following chart shows the sequence for saving user profiles at logoff.

Cc751447.xcp_d08(en-us,TechNet.10).gif 

System Policy

On computers running Windows NT Workstation or Windows NT Server, the contents of the user profile are taken from the user portion of the Windows NT Registry. Another portion of the registry, the local computer portion, contains configuration settings that can be managed, along with user profiles, using System Policy Editor. With this tool, you create a system policy to control user work environments and actions, and to enforce system configuration for all computers running Windows NT Workstation and Windows NT Server.

With system policy, you can control some aspects of user work environments without enforcing the restrictions of a mandatory user profile. You can restrict what users can do from the desktop; such as restrict certain options in Control Panel, customize parts of the desktop, or configure network settings.

How System Policy Works

The desktop settings in user profiles, as well as logon and network access settings, are stored in the computer's registry database. System policy for users overwrites settings in the current user area of the registry, and system policy for computers overwrites the current local machine area of the registry. This allows you to control user actions (user profiles) as well as computer actions for users and groups. In System Policy Editor, you manage the user desktop by changing the Default User settings, and you manage the logon and network settings by changing the Default Computer settings.

Using System Policy Editor, you create a file called NTConfig.pol that contains settings for users (user profiles) and computers (logons and network access settings). To enable a uniform policy for all network computers running Windows NT Server, Windows NT Workstation, you save this file to the Netlogon folder in the system root folder of the primary domain controller: \\PDCservername\Netlogon.

Cc751447.xcp_d09(en-us,TechNet.10).gif 

When a user logs on to any network computer running Windows NT, the operating system looks in the Netlogon folder in the logon server's system root folder to see if there is an NTConfig.pol file present. If the file is found, the contents of the file are copied to the local computer's registry, and is used to overwrite the current user and local machine portions of the registry.

System Policy Editor entries change local computer registry settings in the following ways:

  • Desktop settings for Default User in System Policy Editor modify the HKEY_CURRENT_USER key in the registry, which defines the contents of the user profile that is in effect for the computer.

  • Logon and network access settings for Default Computer in System Policy Editor modify the HKEY_LOCAL_MACHINE key in the registry.

When a user logs on to the domain, the contents of the NTConfig.pol file on the server are merged with the NTuser.dat file found in the user profile location for the user logging on. Settings in NTuser.dat that do not match NTConfig.pol settings are overwritten, and thus system policy controls the user profile settings for the entire domain. Settings for Default Computer that are not contained in the user profile are added to the local machine portion of the registry.

Customizing System Policy for Users, Groups, and Computers

If you have special users, groups, or computers that need settings that are different from the default settings, you can change the default settings to accommodate special needs and add users, groups, and computers as appropriate. Users, groups, or computers you add receive separate entries in the NTConfig.pol file that contain the settings that are different from the default system policy settings. When a user or group member who has special policy settings in NTConfig.pol logs on, the system finds NTConfig.pol and also the special settings that apply specifically to the user or group member. Similarly, if a computer is added and special settings entered in System Policy Editor, anyone logging on to that computer receives those computer settings.

Note Computer policy is applied when the user logs on. Policy is taken from the user's logon domain, not the computer's domain. This can cause problems when users log on in different domain, and not all domains use system policy. For example, Sue has a user account in the South domain, and travels to the North site. When she logs on to a computer in the North domain, she is validated by a logon server in the South domain. If Joe, who has a user account in the North domain, logs on after Sue logs off, and the North domain doesn't use system policy, the South domain computer profile is not overwritten and remains in effect. You can correct this problem by implementing system policy on all domains, or using the Manual update mode to load a specify policy on affected computers.

Profile Evaluation for Users and Computers

When multiple profiles apply to one user, a user profile for a specific user takes precedence over a user profile for a group that the user is a member of. Similarly, if no specific user profile has been defined for the user, a group profile for a group that includes the user is used, if available, before the Default User profile is used.

If no computer profile is defined for a specific computer, the Default Computer profile is used. If multiple group profiles apply to a user, they are applied in the order specified in the Group Priority dialog box.

For information on specifying system policy for groups, see "To specify system policy priority for groups" in System Policy Editor Help.

Using Manual Update Mode

Manual update mode ensures that system policy is always copied from a specific server, regardless of who logs on. When you can change the remote system policy file update mode from automatic to manual, you specify a path other than the Netlogon folder on the PDC. To use this feature, you must use System Policy Editor on individual computers to change the update path.

For more information on changing the update mode, see "To change the system policy file path for manual update" in System Policy Editor Help.

System Policy Templates

System policy templates allow you to set system policy for networks using computers running Windows NT Workstation and Windows NT Server, Windows 95, or a combination (user profiles must be enabled on each computer running Windows 95). The templates provide the necessary framework for overwriting the Registry keys on the different systems.

When you install System Policy Editor, the following template files are installed automatically:

  • WINNT.adm. Provides System Policy Editor settings specific to the Windows NT operating system and registry structure

  • WINDOWS.adm. Provides System Policy Editor settings specific to the Windows 95 operating system and registry structure

  • COMMON.adm. Provides the System Policy Editor settings that are common to both the Windows NT and Windows 95 registry structures, and that are not contained in either WINNT.adm or WINDOWS.adm.

System policy files created on computers running Windows NT Server cannot be used on computers running Windows 95, and vice versa.

For information about enabling and using user profiles and system policy on Windows 95 computers, see the Windows 95 Resource Kit.

For information on loading additional policy templates, see "To add a policy template" in System Policy Editor Help.

Using System Policy Editor to Create System Policy

System Policy Editor can be used to create system policy as follows:

  • Create default settings for the computer and user policy for the domain.

  • Create custom settings that apply to individual users, groups of users, or individual computers.

  • Specify the manner and location from which to download policy for all or some users.

Note The user options described in this section are for computers running Windows NT. For information about Windows 95 system policy settings, see the Windows 95 Resource Kit.

Default System Policy Settings: Default Computer and Default User

When you create a new system policy file, System Policy Editor displays two icons representing the computer and user portions of the registry. When you click either Default Computer or Default User, a graphic representation of categories in the associated portion of the registry appears. Within each major category, subcategories and settings provide options for changing the way computers and users operate. For some settings, selecting a check box opens a set of choices or text boxes; for others, specific information must be provided.

Some settings available in System Profile Editor use the terms disabled, removed, or hidden. These terms explain how the item appears to the user.

  • A disabled command appears dimmed on the menu.

  • A removed command or item does not appear on the menu.

  • A hidden item cannot be seen by the user.

For example, if you select Hide Screen Saver Tab, the Screen Saver tab in the Control Panel Display option does not appear.

Check-Box Selection Levels

In addition to the usual on/off nature of check boxes, System Policy Editor check boxes have a third setting, which is dimmed. The purpose of the this setting is to indicate that there is no change to the previous setting in the registry.

User Policy: Setting Restrictions on User Profiles

The Default User option allows you to control the user profile settings. Each selection in the Default User Properties dialog box contains settings that control what the user can do from the desktop to shape the user work environment.

Cc751447.xcp_d10(en-us,TechNet.10).gif

Control Panel

Use this category to restrict the user activity in the Display option in Control Panel or to deny any access to the Display option.

Desktop

You can specify the background wallpaper and color scheme for the desktop.

Shell

In the Shell category, you can customize desktop folders and restrict what appears on the desktop and restrict the use of the Run, Find, and Shut Down commands. You can create custom folders by entering paths to program items, desktop icons, startup items, Network Neighborhood items, and Start menu items that you want to come from a location other than user profile folders. You can provide locations for custom desktop icons, applications you want in the Startup folder, or even replace the entire Start menu.

System

You can disable Windows NT Registry Editor (Regedt32.exe) and Windows 95 Registry Editor (Regedit.exe) so that users cannot edit the registry files. You can also provide a list of Windows-based applications users can use. Any application not in the list is unavailable.

Windows NT System

When you select Parse Autoexec.bat, Windows NT reads the environment variables from this file and merges them with the user's environment variables.

For information on managing system policy, see "To manage system policy" in System Policy Editor Help.

Computer Policy: Determining Logon and Network Access

The Default Computer option allows you to control logon and network access settings for computers. Each selection in the Default Computer Properties dialog box contains settings that prevent users from modifying the hardware and environment settings for the operating system.

Cc751447.xcp_d11(en-us,TechNet.10).gif

Network

You can provide remote update of system policies instead of updating from Ntconfig.pol on domain controllers. By typing a path to a different policy file, you can enable manual update of the policy file in a location other than the server location.

Load Balancing enables computers running Windows 95 to take policies from multiple logon servers. Enabling Load Balancing prevents bottlenecks on large networks when many users try to access the same policy file.

In addition, you can specify to have error messages displayed when a policy cannot be applied.

For information on managing system policy, see "To manage system policy" in System Policy Editor Help.

System

You can specify the contents of the Run and Run once entries that are used to specify which applications should run at startup.

You can also change default SNMP (Simple Network Management Protocol) configuration by adding or removing communities, managers, and public community traps. The default for these settings are established when the SNMP service is configured on the host. System provides three options for changing default SNMP configuration

Windows NT System

System security. For Windows NT System, you can set logon policy for user accounts, including creating a logon banner and enabling or disabling automatic logon. Automatic logon allows the user to bypass the ctRl+alt+delete key combination when the system is started.

Logon security. Enable or disable the Shut Down button in the Welcome dialog box. Disabling the button on servers ensures that an unauthorized user cannot shut down the system.

FTP logon policies. For computers running the File Transfer Protocol (FTP) Server Service, you can set policy for allowing and logging anonymous logons, setting a timeout limit for unsuccessful (idle) connections, and specifying the home directory for new users.

Windows NT Printers

For print servers, you can disable the print spooler browse process that periodically sends information to other print servers about which printers the server shares. This browsing consumes some CPU and network capacity, which might not be necessary for some print operations.

You can change the priority of print job assignments to ports and also set the print spooler to beep every 10 seconds if an error condition occurs for a remote print job.

Windows NT Remote Access

When using a remote access server, you can set a maximum number for unsuccessful authentication retries and a maximum time limit for authentication. You can also set the time interval between call-back attempts and a time limit for automatic disconnection from the server.

For information on managing system policy, see "To manage system policy" in System Policy Editor Help.

Using System Policy Editor to Edit the Registry

You can use the Open Registry command on the System Policy Editor File menu to make changes to the Windows NT Registry settings on the local computer. Using Open Registry, the changes you set in System Policy Editor are made immediately in the registry when you use Save on the File menu.

You can use the Connect command on the System Policy Editor File menu to make changes to the Windows NT Registry settings on a remote computer. This feature allows remote adjustment to computer registries. For example, a help desk technician can connect to a computer and correct settings that a user mistakenly changed.

Note System policy is designed to manage registry settings for the entire domain; direct changes to registry settings are not recommended unless a specific instance of user or computer incompatibility occurs.

Using Logon Scripts to Configure User Work Environments

A logon script runs automatically whenever a user logs on to a computer running either Windows NT Server or Windows NT Workstation. Although a logon script is typically a batch file (.bat extension), any executable program (.exe extension) can also be used.

Logon scripts are optional. They can be used to configure user working environments by creating network connections and starting applications. Logon scripts are useful when you want to affect the user work environment without managing all aspects of it.

Note User profiles can restore network connections at logon that were established prior to logging off, but they cannot be used to create new network connections at logon.

Creating Logon Scripts

You can create logon scripts using a text editor and then use User Manager for Domains to assign different logon scripts to different users or assign the same logon script to multiple users.

There are several special parameters you can use when creating logon scripts:

Parameter

Description

%HOMEDRIVE%

The user's local workstation drive letter connected to the user's home directory

%HOMEPATH%

The full path of the user's home directory

%HOMESHARE%

The share name containing the user's home directory

%OS%

The operating system of the user's workstation

%PROCESSOR_ARCHITECTURE%

The processor type (such as 80386) of the user's workstation

%PROCESSOR_LEVEL%

The processor level of the user's workstation

%USERDOMAIN%

The domain containing the user's account

%USERNAME%

The user name

Assigning Logon Scripts to User or Group Accounts

You assign a logon script in a user account or group account by entering a path to the logon script file in User Manager For Domains. When a user logs on and a path to a logon script is present in the user account, the file is located and run at logon.

In the User Environment Profile dialog box, you can assign logon scripts to user accounts by typing the filename (for example, Clerks.bat) in the Logon Script Name box. At logon, the server authenticating the logon locates the logon script (if one is assigned) by looking for the specified file following that server's local logon script path (usually C:\WINNT\System32\Repl\Import\Scripts). If a relative path is provided before the filename (for example, Admins\CristalW.bat), the server looks for the logon script in that subdirectory of the logon script path.

The entry in the Logon Script Name box specifies only the filename (and optionally the relative path) and does not create the actual logon script. You create a logon script of the specified name and place it in the appropriate directory on the appropriate replication export server.

You can place a logon script in a local directory of a user's computer, but you usually use this location when you are administering user accounts that exist on a single computer rather than in a domain. In this case, you must place the logon script following the computer's logon script path or in a subdirectory of that logon script path. The logon script path for a Windows NT computer is systemroot\System32\Repl\Import\Scripts.

For information on configuring a user environment profile, see User Manager for Domains Help.

Setting Up Replication of Logon Scripts

A logon script is always downloaded from the server that validates a user's logon request. For users with accounts on Windows NT Server domains that have one or more backup domain controllers, any one of the domain controllers can authorize a user's logon attempt. To ensure that logon scripts always work for users, you should be sure that logon scripts for all user accounts in a domain exist on every primary and backup domain controller in the domain.

The best way to ensure that logon scripts are always available is to use the Replicator service. This service maintains identical copies of a directory tree on multiple computers. When you make a change to a file in the master copy of the tree (located on the export server), the Replicator service automatically copies the change to the other computers (the import computers).

When you use the Replicator service with logon scripts, you set up one domain controller as the export server and all the other domain controllers in the domain as import servers.

The logon script path can be configured for each server of a domain using either Server Manager (administering servers either locally or remotely) or the Server option in each server's Control Panel. Use the Directory Replication dialog box to set up replication export and replication import and to specify a local path to user logon scripts.

Usually, a master collection of logon scripts is maintained by an administrator in an export directory (usually C:\WINNT\System32\Repl\Export\Scripts and its subdirectories) of one replication export server in the domain, and this master collection is replicated to all the servers in the domain so that each server has its own local copy of all logon scripts.

For information on Directory Replication, see "Managing Export Replication" and "Managing Import Replication" in Server Manager Help.

For information about directory replication, see Chapter 4, "Managing Shared Resources and Resource Security."

Using Environment Variables to Manage Workstations

When managing multiple user and group accounts, you often need to make the same change to many accounts. You can use environment variables to replace specific names or labels with a general one that is replaced by the appropriate specific data when copied.

Changing the System Environment Variables

Windows NT requires certain information to find programs, to allocate memory space for some programs to run, and to control various programs. This information — called the system and user environment variables — can be viewed using the System option in Control Panel in the Environment Variables tab. These environment variables are similar to those that can be set in the MS-DOS operating system, such as PATH and TEMP.

The system environment variables are defined by Windows NT Workstation and Windows NT Server and are the same no matter who is logged on at the computer. If you are logged on as a member of the Administrators group, you can add new variables or change the values.

The user environment variables can be different for each user of a particular computer. They include any environment variables you want to define or variables defined by your applications, such as the path where application files are located.

After you change any environment variables in Environment Variables tab in the System Properties dialog box and click OK, Windows NT saves the new values in the registry so they are available automatically the next time you start your computer.

If any conflict exists between environment variables, Windows NT Workstation and Windows NT Server resolve the conflict in this way:

  • System environment variables are set first.

  • Variables defined in Autoexec.bat (except for Path variables) are set next and override system variables.

  • User environment variables defined in the System dialog box are set next and override both the system and Autoexec.bat variables. 

  • Path variables defined in Autoexec.bat are set last.

Note Path settings, unlike other environmental variables, are cumulative. The full path (what you see when you type path at the command prompt) is created by appending the path contained in Autoexec.bat to the paths defined in the System option in Control Panel.

Using System Environment Variables in User Profile Paths, Home Directory Paths, and Logon Scripts

Any system environment variable on a client computer running Windows NT Workstation can be used in a user account's user profile path, logon script path, home directory path, and within a logon script itself. To use the system environment variable in this way, enclose it in percent signs (%); for example, to use a client's servername environment variable in a user profile path, type \\%servername%\scripts in the User Profile Path box.

One use of this feature is to ensure that logon scripts and user profiles are run most efficiently on domains that span WAN (wide area network) links, especially if you have users that sometimes work at both sites. Suppose you have two physical sites, Paris and London. On every computer running Windows NT Workstation and Windows NT Server at the London site, set the servername system environment variable to the computer name of a backup domain controller in London. On Paris computers set servername in a similar way, but use the computer name of a Paris backup domain controller. Then, in every user account in the domain, use %servername% in the logon script paths. When a user logs on, the logon script is always loaded from a server at the local site.

Cc751447.spacer(en-us,TechNet.10).gif