Microsoft Windows NT 4.0 User Manual

Server Operating System

White Paper

Guide to Microsoft® Windows NT® 4.0 Profiles and Policies

discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, the BackOffice logo, MS-DOS, Windows, and Windows NT are registered trademarks of Microsoft Corporation.

Other product or company names mentioned herein may be the trademarks of their respective owners. Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA 0997

Abstract

This guide provides information and procedures for implementing Microsoft®

Windows NT® 4.0 Profiles and Policies on client workstations and servers. A Microsoft Windows NT 4.0 User Profile describes the Windows NT configuration for a specific user, including the user’s environment and

preference settings. A System Policy is a set of registry settings that together define the computer resources available to a group of users or an individual. With the addition of System Policies and the new User Profile structure to

Windows NT 4.0, network administrators have a greater ability to control the user environment than they have ever had before.

This document provides the details that administrators need to know to

implement a rollout of User Profiles and System Policies under Windows NT

4.0. Although the primary emphasis is Windows NT, this paper also discusses

how User Profiles are handled with Windows 95 clients and how the two

platforms differ. You should use this guide in conjunction with your

Windows NT 4.0 documentation and Resource Kits.

Introduction ................................................................

.........................

..........

CONTENTS

TCO and the User Profiles, Policies, and the Zero Administration Kit What are User Profiles and System Policies? Before You Begin

Key Terminology

Technical Notes

Establishing User Profiles – An Overview ................................

Creating and Administering User Profiles User Profile Structure

Configuration Preferences Stored in the Registry Hive Configuration Preferences Stored in Profile Directories

Windows NT 4.0 and Windows 95 User Profile Differences

How User Profiles Are Handled in Windows 95

User Profile Planning and Implementation

Setting Permissions for User Profiles Encoding Permissions in the User Profile Selecting a Location to Save User Profiles Setting Persistent Connections Working Around Slow Network Links

Creating and Maintaining User Profiles............................................

Creating a New Roaming User Profile for Windows NT 4.0 Creating a New Mandatory User Profile for Windows NT 4.0 Making a Roaming Profile Mandatory in Windows NT 4.0

Changing the User’s Ability to Modify a Profile

Enforcing the Use of the Server-based Profile Creating a New Roaming User Profile for a Windows 95 User Creating a New Mandatory User Profile for Windows 95 Maintaining User Profiles with Control Panel System Properties

Deleting Profiles

Changing the Profile Type from Roaming to Local

Determining Which Profile Is Displayed

Copying Profiles Viewing the Contents of the Profiles Directory on a Local Computer

Log Files Used by Profiles

The All Users Shared Profile

Default User Template Profiles

Profile Names and Storage in the Registry Manually Administering a User Profile through the Registry

Modifying the Default User Profile Upgrading Windows NT 3.5x Server-based Profiles to Windows NT 4.0 Roaming Profiles

Upgrading Windows NT 3.5x Mandatory Profiles to Windows NT 4.0 Mandatory Profiles 30 Extracting a User Profile for Use on Another Domain or Machine 31 Creating Profiles Without User-Specific Connections 32 Troubleshooting User Profiles with the UserEnv.log File 33

System Policy – An Introduction....................................................... 35

System Policy Files 35 Policy Replication 36 How Policies Are Applied 36 Additional Implementation Considerations 37

The System Policy Editor .................................................................. 39

Installing the System Policy Editor on a Windows NT Workstation 39 Installing the System Policy Editor on a Windows 95 Computer 39 Updating the Registry with the System Policy Editor 40

System Policy Editor Template (.Adm) Files 40 Configuring Policy Settings 41

Setting Folder Paths Back to Defaults 42 Creating a System Policy 42 Creating Alternate Folder Paths 44

Setting Up Shortcuts for Server-based Profiles 44 Deploying Policies for Windows NT 4.0 Machines 45 Deploying Policies for Windows 95 Machines 46 Modifying Policy Settings on Stand-Alone Workstations 47 Creating a Custom .Adm File 48 Configuring System Policies Based on Geographic Location 52 Clearing the Documents Available List 52 Building Fault Tolerance for Custom Shared Folders 52

Registry Keys Modified by the System Policy Editor Default

Templates .......................................................................................... 54

Default User Settings 54

Control Panel Display Application 54

Wallpaper 54

Color Scheme 55

Start Menu Run Command 55

Settings Folders 55

Settings Taskbar 56

Start Menu Find Command 56

My Computer Drive Icons 57

Network Neighborhood Icon 57

Network Neighborhood Display 57

Network Neighborhood Workgroup Contents 58

Desktop Display 58

Start Menu Shut Down Command Saved Settings Registry Editing Tools Windows Applications Restrictions Custom Programs Custom Desktop Icons Start Menu Subfolders Custom Startup Folder Custom Network Neighborhood Custom Start Menu Shell Extensions Explorer File Menu Start Menu Common Program Groups Taskbar Context Menus Explorer Context Menu Network Connections Explorer Context Menu Autoexec.bat Logon Scripts Task Manager Welcome Tips

Default Computer Settings

Remote Update Communities Permitted Managers Public Community Traps Run Command Drive Shares – Workstation Drive Shares – Server Printer Browse Thread Server Scheduler Error Beep Authentication Retries Authentication Time Limit RAS Call-back Interval RAS Auto-disconnect Shared Programs Folder Path Shared Desktop Icons Path Shared Start Menu Path Shared Startup Folder Path Logon Banner Logon Dialog Shut Down Button Logon Name Display Logon Scripts Long File Names

Extended Characters in 8.3 File Names 77

Read Only Files – Last Access Time 78

Cached Roaming Profiles 78

Slow Network Detection 79

Slow Network Timeout 79

Dialog Box Timeout 79

Registry Entries Not Included in the System Policy Editor............ 81

Autorun 81

Start Banner 81

For More Information......................................................................... 83

Appendix A –Flowcharts.................................................................... 84

User Profile Flowcharts 84 System Policy Flowchart 89

Appendix B - Implementing User Profiles ........................................ 90

Existing Windows NT 3.5x Roaming Profile 90 Existing Windows NT 3.5x Roaming Profile 90 Migrating Windows NT 3.5x Roaming Profile to Windows NT 4.0 Roaming Profile 90 Migrating Windows NT 3.5x Mandatory Profile to Windows NT 4.0 Mandatory Profile 90 Migrating Windows NT 3.5x Mandatory Profile to Windows NT 4.0 Roaming Profile 91 Creating a New Windows NT 4.0 Roaming Profile 91 Creating a New Windows NT 4.0 Mandatory Profile 91 Updating and Changing a Roaming Profile to a Mandatory Profile 92 Changing a Roaming Profile to a Mandatory Profile 92

Appendix C – Usage Notes............................................................... 93

Important Information for Administrators Regarding User Logons and User Logoffs 93 Recent Updates to Profiles Since Retail Release 93 Recent Updates to Policies Since Retail Release 94

APPENDIX D – Related Knowledge Base Articles............................ 95

Profiles 95 Policies 95

Not too many years ago, information technology professionals faced a serious

INTRODUCTION

challenge in controlling the mounting costs of mainframe use. It seemed that everyone—clerks, writers, developers, and systems administrators—all had terminals and were using the system for everything from numbers crunching to typing letters. Networks became bogged down, and IT professionals were given the task of getting “nonessential operations” off the mainframe. Their decision was to deploy personal computers in the enterprise—with emulation software for mainframe access and local software for tasks where central processing or data sharing were not required. Gradually, as PCs became more powerful, more and more operations moved to the desktop. And as PC networking matured, many businesses found that a PC-based network built on commodity hardware and off-the-shelf software was their best business solution.

Lately, however, we’ve come full circle on this. It seems that the total cost of ownership (or TCO)—the real cost of maintaining a distributed personal computer network—is far from trivial. TCO includes the initial capital cost of hardware and software, deployment and configuration expense, costs associated with deploying hardware and software updates, training and retraining, day-to-day maintenance and administration, and telephone and on-site technical support. With these escalating costs in mind, Microsoft and others are working together on several initiatives to lower the total cost of ownership of personal computers.

TCO and the User

One of the major costs highlighted in recent reports on Total Cost of Ownership (TCO), is lost productivity at the desktop caused by user error, such as changing the system configuration and rendering the computer unworkable, or system distractions and complexities, for example too many features or nonessential applications installed on the desktop. To solve these problems, system administrators need a means to control a user’s access to key configuration files and to features and applications that are not required to do that user’s particular job. To be successful, this means of control must be flexible and customizable—the system administrator must be able to control the computer configurations of individuals and groups of users based on user job responsibilities and computer literacy.

Profiles, Policies, and the Zero Administration Kit

The Zero Administration Kit (ZAK) for the Microsoft Windows NT® version 4.0 operating system is designed to help the corporate administrator address some of the issues arising from user operations. ZAK is a set of methodologies for deploying Microsoft Windows NT 4.0 that greatly reduces the burden of individual desktop management for task-based workers. With ZAK, system administrators can establish user profiles, system policies, and security to reduce some of the administrative costs associated with managing end-users in an enterprise network.

ZAK’s methodologies are based on the underlying technologies and capa-

Microsoft Windows NT Server White Paper 1

bilities of Windows NT 4.0, and as such these techniques can readily be adapted to accommodate a corporation’s specific computing requirements. In the near future, you will see additional TCO-reducing features appear in Microsoft Windows® 98, Windows NT 5.0, and Microsoft Systems Management Server. Central to these features is the idea of centralized desktop control. This is accomplished through User Profiles and System Policies—the subject of this paper.

What are User Profiles and System Policies?

A Microsoft Windows NT 4.0 User Profile describes the Windows NT configuration for a specific user, including the user’s environment and preference settings. For example, those settings and configuration options specific to the user—such as installed applications, desktop icons, color options, and so forth—are contained in a User Profile. This profile is built in part from System Policy information (for example, those things that a user has access to and those things that the user can and cannot change) and in part from permitted, saved changes that a user makes to customize his or her desktop.

A System Policy is a set of registry settings that together define the computer resources available to a group of users or an individual. Policies define the various facets of the desktop environment that a system administrator needs to control, such as which applications are available, which applications appear on the user’s desktop, which applications and options appear in the Start menu, who can change attributes of their desktops and who cannot, and so forth.

With the addition of System Policies and the new User Profile structure to Windows NT 4.0, network administrators have a greater ability to control the user environment than they ever have had before. Many of the requests that customers submitted, including providing more options in controlling the user’s desktop, accessibility to applications and system tools, minimizing administrative overhead, and scalability enhancements, have been added. And, as with every release, Microsoft encourages customer feedback on enhancements to the Windows NT operating system.

This document provides the details that administrators need to implement a rollout of User Profiles and System Policies under Windows NT 4.0. Although the primary emphasis is Windows NT, this paper also discusses how User Profiles are handled with Windows 95 clients and how the two platforms differ.

2 Microsoft Windows NT Server White Paper

Before You Begin

Before proceeding with this document, we recommend that you read Chapters 3 and 4 of the Windows NT 4.0 Concepts and Planning Guide. In addition, you should be familiar with the following terms and concepts.

Key Terminology

Directory Replication

The copying of a master set of directories from a server (called the export server) to specified servers or workstations (called import computers) in the same or other domains. Replication simplifies the task of maintaining identical sets of directories and files on multiple computers, because only a single master copy of the data is maintained. Files are replicated when they are added to an export directory and each time a change is saved to one of the exported files.

Domain Structure

In Windows NT, a domain is a collection of computers defined by the administrator of a Windows NT Server network that share a common directory database. A domain provides access to the centralized user accounts and group accounts maintained by the domain administrator. Each domain has a unique name.

Home Directory

A home directory is a directory that is accessible to the user and contains files and programs for that user. A home directory can be assigned to a single user or to a group of users.

Local Profile

A local profile is specific to a computer. A user who has a local profile on a particular computer can gain access to that profile only while logged on to that computer.

Mandatory Profile

A mandatory profile is a preconfigured roaming profile that the user cannot change. In most cases, these are assigned to a person or a group of people for whom a common interface and standard configuration is required.

NetLogon Service

For Windows NT Server, the NetLogon service authenticates domain logons and keeps the domain’s directory database synchronized between the primary domain controller (PDC) and the backup domain controllers (BDCs).

Regedt32.exe

The 32-bit version of the Registry Editor.

Registry

The registry is a database where Windows NT internal configuration information and machine- and user-specific settings are stored.

Registry Hive

A hive is a section of the registry that is saved as a file. The registry subtree is divided into hives (named for their resemblance to the cellular structure of a beehive). A hive is a discrete body of keys, subkeys, and values.

Roaming Profile

A roaming profile is stored on a network share and can be accessed

Microsoft Windows NT Server White Paper 3

from any computer. A user who has a roaming profile can log on to any computer for which that profile is valid and access the profile. (Note that a profile is only valid on the platform for which it was created—for example, a Windows NT 4.0 profile cannot be used on a

Windows 95 computer.)

Roaming User

A roaming user is a user who logs on to the network from different computers at different times. This type of user may use a kiosk or may share a bank of computers with other users. A roaming user stores his or her user profile on a network share, and can log on to any networked computer and access that profile.

System Policy

A System Policy is a set of registry settings that together define the computer resources available to a group of users or an individual. You create system policies with the System Policy Editor. System policies allow an administrator to control user work environments and actions, and to enforce system configurations.

%systemroot%

An environment variable that expands to become the root directory containing Windows NT files. The directory name is specified when Windows NT is installed (normally, this directory name is c:\winnt).

%systemroot%\profiles

A folder in the root directory that contains the user profiles for each user of the computer.

%username%

An environment variable that expands to become the user account ID for the current logged on user. This identifies the user account to Windows NT.

4 Microsoft Windows NT Server White Paper

Technical Notes

Several portions of this guide refer to registry locations that allow you to change certain behaviors of Windows NT and modify settings. For this reason, we include the following warning.

Caution:

Using Registry Editor incorrectly can cause system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be resolved.

In addition, portions of this guide refer to a registry hive called NTuser.xxx. In instances where this is used, .xxx can be replaced with either .dat or .man.

ESTABLISHING USER

OVERVIEW

PROFILES – AN

A Microsoft Windows NT 4.0 User Profile describes the Windows NT configuration for a specific user, including the user’s environment and preference settings. A User Profile can be local, roaming, or mandatory. A local profile is specific to a given computer. A user who creates a local profile on a particular computer can gain access to that profile only while logged on to that computer. Conversely, a roaming profile is stored on a network share and can be accessed from any networked computer. A user who has a roaming profile can log on to any networked computer for which that profile is valid and access the profile. A mandatory profile is a preconfigured roaming profile that the user cannot change. As a system administrator, you may want to use mandatory profiles for a group of people who require a common interface and standard configuration.

One of the primary goals of User Profiles is to allow a user’s system and desktop customizations to travel with the user from computer to computer, without requiring the user to reconfigure any settings. When a user logs on to any computer that supports his or her roaming profile, the desktop appears— just as the user left it the last time he or she logged off. With roaming user support, users can share computers, but each user has his or her personal desktop on any computer in the network (both roaming and mandatory profiles support this functionality).

Creating and Administering User Profiles

User Profiles can be created and administered in several different ways as will be described next. Note that as a system administrator, you determine whether users can modify their profiles.

• You create a User Profile that is not modifiable for a particular user or

group (this is a mandatory profile).

• You establish a network Default User Profile that applies to all new users

on Windows NT 4.0 computers. After downloading this default profile and logging on, the user can customize the profile (provided that it is not mandatory).

• You allow a new user to use the local Default User Profile on the

Windows NT 4.0 computer where the user logs on. After logging on, the user can customize the profile (provided that it is not mandatory).

• You copy a template User Profile, and assign the copy to a user. The user

can then customize the profile (provided that it is not a mandatory profile).

Profiles can be stored on a network server or cached on the local machine. (Cached profiles are located in the \%systemroot%\Profiles directory.) Caching a profile reduces the total time to log on and load the profile; however, in a roaming user or kiosk environment, this approach may not be optimal. This option is controlled by the administrator.

User Profile Structure

A User Profile is comprised of a Windows NT registry hive and a set of profile directories. The registry is a database used to store machine- and user-specific

Microsoft Windows NT Server White Paper 5

settings, and portions of the registry can be saved as files, called hives. These hives can then be reloaded for use as necessary. User Profiles take advantage of the hive feature to provide roaming profile functionality.

The User Profile registry hive is the NTuser.dat in file form, and is mapped to the HKEY_CURRENT_USER portion of the registry when the user logs on.The NTuser.dat hive maintains the user’s environment preferences when the user is logged on. It stores those settings that maintain network connections, Control Panel configurations unique to the user (such as the desktop color and mouse), and application-specific settings. The series of profile directories store shortcut links, desktop icons, startup applications, and so forth. Together, these two components record all user-configurable settings that can migrate from computer to computer. Details are provided below.

Configuration Preferences Stored in the Registry Hive

The NTuser.dat file contains the following configuration settings.

• Windows NT Explorer settings. All user-definable settings for Windows NT

Explorer, as well as persistent network connections.

• Taskbar. All personal program groups and their properties, all program

items and their properties, and all taskbar settings.

• Printer settings. All network printer connections.

• Control Panel. All user-defined settings made in the Control Panel.

• Accessories. All user-specific application settings affecting the

Windows NT environment, including: Calculator, Clock, Notepad, Paint, and HyperTerminal, among others.

• Help bookmarks. Any bookmarks placed in the Windows NT Help system.

Configuration Preferences Stored in Profile Directories

The profile directories are designed to contain the following configuration settings.

• Application data. Application-specific data, such as a custom dictionary for

a word processing program. Application vendors decide what data to store in this directory.

• 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. Also a central store for any docu-

ments that the user creates. Applications should be written to save files here by default.

• PrintHood.* Shortcuts to printer folder items.

• Recent. Shortcuts to the most recently used items.

• SendTo. Shortcuts to document storage locations and applications.

• Start Menu. Shortcuts to program items.

• Templates.* Shortcuts to template items.

* These directories are hidden by default. To see these directories, change the View Options.

6 Microsoft Windows NT Server White Paper

Windows NT 4.0 and Windows 95 User Profile Differences

Windows 95 Profiles are very similar in behavior to Windows NT 4.0 Profiles, but

there are some differences.

Unlike Windows NT 4.0, Windows 95 downloads and writes User Profiles to the user’s home directory. When the Windows 95 user first logs on, the UNC path specified in the user account’s home directory path is checked for the

Windows 95 User Profile. You can modify this behavior, however. See the Win-

dows 95 Resource Kit for more information.

Windows 95 and Windows NT 4.0 User Profiles have the following additional functional differences:

• Windows 95 does not support common groups.

• Windows 95 can be configured to copy only the shortcut (.lnk) and Pro-

gram Information Files (.pif) when the User Profile is downloaded, whereas Windows NT downloads all file, shortcut, and directory objects.

• Windows 95 User Profiles do not support a centrally stored Default User

Profile.

• Windows 95 uses different files for the registry portion of User Profiles.

(Refer to the following table.) Windows 95 and Windows NT 4.0 profiles are not interchangeable, primarily because the registry hive, which is a key component of the User Profile, is incompatible between operating system versions.

Windows NT 4.0 file Equivalent Windows 95 file

NTuser.dat User.dat NTuser.dat.log User.da0 NTuser.man User.man

NOTE: The Windows 95 User.da0 and Windows NT 4.0 Ntuser.dat.log, while equivalent, provide slightly different functionality. Windows 95 writes a copy of User.dat to User.da0 each time the user logs off. Windows NT uses the Ntuser.dat.log file as a transaction log file. This allows for fault tolerance in the event that a User Profile must be recovered.

• Windows 95 and Windows NT 4.0 file structures are identical with the ex-

ception of the Application Data directory. Windows 95 does not support this directory.

Windows 95 User Profiles can be stored on NetWare servers. For more information on configuring a client with a Primary Network Logon of Client for NetWare Networks, see the chapter “Windows 95 on NetWare Networks” in the Windows 95 Resource Kit. For more information on configuring a client that uses Microsoft Service for NetWare Directory Services, see the online Help that accompanies the service.

How User Profiles Are Handled in Windows 95

When a user logs on to a Windows 95 machine, the local profile path,

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Profile List, is checked for an existing entry for that user:

If the user has an entry in this registry location, Windows 95 checks for a locally cached version of the user’s profile. Windows 95 also checks the user’s

Microsoft Windows NT Server White Paper 7

home directory (or other specified directory if the location has been modified) on the server for the User Profile. If a profile exists in both locations, the newer of the two is used. If the User Profile exists on the server, but does not exist on the local machine, the profile on the server is downloaded and used. If the User Profile only exists on the local machine, that copy is used.

If a User Profile is not found in either location, the Default User Profile from the Windows 95 machine is used and is copied to a newly created folder for the logged on user. At log off, any changes that the user made are written to the user’s local profile. If the user has a roaming profile, the changes are written to the user’s profile on the server.

User Profile Planning and Implementation

A successful implementation of User Profiles requires planning and preparation. Before creating User Profiles, consider the following:

• How much of the user environment do you wish to control? Would System

Policies—either in conjunction with User Profiles, or by themselves—be a better solution?

• Will users be required to use a specific set of desktop folders and envi-

ronment settings?

• Will users be able to make modifications to their profiles?

• What features will you be implementing in User Profiles? Optional features

include persistent network connections, custom icons, backgrounds, and so on.

• For roaming profiles, will users be allowed to use the default profile from

the client workstation or will a standardized server-based default profile be used instead?

• Where will the profiles be stored, and is there enough drive space to store

them?

• Where do existing user home directories reside?

• How will shortcuts and links be displayed for the user?

• What are the speeds of the links between the clients and the server stor-

ing the profiles?

These issues are examined more fully in the following paragraphs. For more information, refer to the Windows NT Server Concepts and Planning Guide.

8 Microsoft Windows NT Server White Paper

Setting Permissions for User Profiles

When troubleshooting or preparing for a rollout of User Profiles, you should pay careful attention to permissions at the Windows NT File System (NTFS) and share levels. If the profile is mandatory, the user account should have at least Read permissions on the network share where that user’s User Profile is stored. If the user’s profile is roaming, the user must have Change permissions (or better) because the client will need to write the changes back to the central profile on the shared network drive when the user logs off. If roaming profiles are stored on an NTFS partition, you can choose to remove the Delete permission from the default Change permissions at the NTFS level.

NOTE: Directories containing roaming User Profiles need at least Add and Read permissions for profiles to be read correctly. If you use Add permissions only, when Windows NT checks for the existence of the profile it will fail because it looks for the path first, and if Read rights are not given, the check will fail.

Permissions are also important on a client machine where the user is logging on interactively. If Windows NT is installed in an NTFS partition on the client computer, and the user does not have at least the default permissions as outlined in the Windows NT Server Concepts and Planning Guide (page 132), errors can occur. For example, if permissions are incorrect on the root of the system directory, the following message appears: “Can’t access this folder— the path is too long.” A blank desktop is displayed, and the user’s only option is to log off.

If permissions are set incorrectly in the %systemroot%, %systemroot%\System, %systemroot%\System32, or %systemroot%\System32\Config directories, the following message appears: “Unable to log you on because your profile could not be loaded.”

Encoding Permissions in the User Profile

The registry portion of the User Profile, NTuser.xxx, is encoded with the user or group that has permission to use that profile. Once this is saved, you can use the Registry Editor to modify this information if you want to change the permissions on a profile without replacing it. To change encoded User Profile information:

1. Follow the instructions to manually edit a profile: (Refer to the section

“Administering a User Profile Manually through the Registry” later in this document).

2. Change the permissions on the root of the key to include users and groups

who will have permission to use the profile.

3. Unload the hive.

Selecting a Location to Save User Profiles

As with Windows NT 3.5x, you can place a roaming profile in any shared directory, and then configure the user account profile path to point to the profile. The Profiles directory in the system root stores local User Profiles, “All Users” profile settings (which apply to any user who uses the computer), the “Default User” profile, and cached User Profiles of domain users. You should avoid using the %systemroot%\Profiles directory in the domain users’ profile path as a location to store server-based profiles, whether they are roaming or mandatory. (The path should allow the user’s profile to roam with the user and be available on any networked computer that the user logs on to. If you specify a path to the %systemroot%\Profiles directory, the client computer always uses the local profile instead.)

Windows NT 4.0 profiles can be saved on any Windows NT 3.5x or 4.0 server because the client computer uses the path where the profile is stored only as a location to download the profile and to write the modified user profile at log off. This allows profiles to be stored on any shared network drive. The process of downloading the profile is controlled by the client computer—all the

Microsoft Windows NT Server White Paper 9

client needs is the correct path. Note that storing profiles on a Windows NT 4.0 Server makes it easier for the administrator to open a user’s NTuser.dat file to make any necessary modifications. You can also store User Profiles on Novell Servers provided that the client is configured correctly and can access the profile path.

If a client is not receiving a User Profile at logon, use the Start menu Run command to check the profile path. For example, to see if you can locate the profile, type \\server\share\mydomainuser. If the path to the user’s profile contains spaces, put quotation marks around the path when you type it in the Run command box.

Except in the case of mandatory profiles or when a slow network is detected, any changes to the user’s profile are saved to the central profile when the user logs off. (Because users cannot modify mandatory profiles, changes do not need to be written to the server.)

NOTE: In situations where the same user account logs on to multiple machines, the last user to log off dictates the profile settings because that user was the last one to write data to the profile. Similarly, if a group of users all point to the same profile, the final logoff settings are saved and will overwrite previous settings.

If the User Profile is flagged as a local profile and is not mandatory, any changes the user makes while logged on are written to the locally cached version of the profile, but not to the server-based copy.

NOTE: You should not make the home directory and User Profile path the same. If the profile path encompasses the home directory path and the server-based profile is more recent than the local profile on the workstation, all directories and files that exist in the user’s home directory will be copied to the user’s workstation at logon. These files are then written back to the server (if modified) when the user logs off. This process occurs at each logon. In addition, even if the user logs off and the administrator deletes all of the unnecessary files from the home directory, the versions of these files that reside on the workstation will not be deleted at logon and will be written back to the server again at log off. This file copy process is avoided if you place the profile in a subdirectory of the home directory, as follows:

\\server\share\domainuser\profile.

Setting Persistent Connections

Persistent connections are stored in the User Profiles registry hive under the Network subkey. If you create a template User Profile that includes persistent connections and you have to supply credentials when making those connections, the credentials—with the exception of the password you used—are stored in the User Profile. When the new user receives the template User Profile, these saved credentials are passed (as opposed to the logged on user’s credentials), and the connection may fail.

There are three methods to correct this:

1. You can recreate the profile without supplying alternate credentials when

connecting to network resources, or

2. Using Registry Editor (Regedt32.exe), use blank spaces to erase the

contents of the USERNAME value under HKEY_CURRENT_USER\Network\drive letter. (Do not delete the value— just fill it with blank spaces.) Save the profile. For additional help, refer to the section “Administering a User Profile Manually Through the Registry” later in this document, or

10 Microsoft Windows NT Server White Paper

3. Delete the network connection and reconnect.

Working Around Slow Network Links

Slow Net (which is configured in System Policy) was designed to offer a user faster access to his or her User Profile if the system detects a slower network speed, such as a modem line connection. Instead of automatically downloading a profile that may be several hundred kilobytes to several megabytes large, Slow Net gives the user the option of either downloading the profile or using the locally cached version. If the cached file is used, it can significantly reduce the time it takes to log on to the computer. To detect a slow network, the operating system computes the amount of time it takes to receive a response from the server (which the profile path defines as part of the user account). As system administrator, you can determine the allowable slow network speed. Use the System Policy Editor to set this value.

If the user uses the Control Panel System application to change the profile type to Local, then the cached copy of the User Profile is opened every time the user logs on. Any changes that occur to the profile are written locally and not to the server location.

Microsoft Windows NT Server White Paper 11

CREATING AND

PROFILES

MAINTAINING USER

Creating a New Roaming User Profile for Windows NT 4.0

To create a new roaming User Profile, you must first determine where the user’s profile will be stored. You then must create a user account (if one doesn’t already exist), and specify a User Profile path. Finally, you must specify whether a given user will use a specific profile or can use a default profile. These procedures are described below.

To create a new roaming user profile:

1. If a location has not already been prepared, create a directory on the server and establish a network share. Give the user a minimum of Change permissions to the shared directory. (For more information on planning for this type of user, read the sections “Selecting a Location to Save User Profiles” and “Setting Permissions for User Profiles” earlier in this document.) If your implementation stores user profiles within users’ home directories, make the profile directory a subdirectory of the user’s home directory. (Note that this approach precludes the use of the %USERNAME% variable.) To prevent the share from being browsable, append “$” to the share name.

2. If this will be a domain user or if this will be a local account for a Windows NT Server-based machine, use User Manager for Domains to create the account. If this will be a Windows NT 4.0 Workstation account, use the version of User Manager included in the Administrative Tools program group. Refer to your operating system documentation and online Help for procedures when using these tools. (Note that for this example, the user account is mydomainuser.)

3. Enter the User Profile path. This is the location where the User Profile will be stored, for example: \\myserver\myshare\mydomainuser.

Or, if the profile is being stored within the user’s home directory, use:

\\myserver\myshare\MyUsersHomeDir\profile.

4. If the user is to receive the Default User profile from the workstation where he or she will interactively log on, no further administration is required.

If the user’s profile will be a copy of an existing user profile, refer to Step 9. Otherwise, use User Manager to create an account for establishing a template profile. So that you can easily identify this account, we recommend that it be called TemplateUser.

5. Using the template account (TemplateUser), log on to the local machine or domain. A new directory with the same name as the user name created in Step 4 will be created in the %systemroot%\Profiles directory when you first log on. For example, if the user name is TemplateUser, the resulting directory name will be %systemroot%\Profiles\TemplateUser.

6. Modify any items that need to differ from the current default (for example, you may choose to modify the background color or bitmap, shortcuts on the desktop, and View options in My Computer).

7. Log off, and then log back on to the same computer using an account with administrative privileges.

12 Microsoft Windows NT Server White Paper

8. Place the template profile in the appropriate location for the type of profile distribution that will be used. (The template profile, including customizations, is stored initially in %systemroot%\Profiles\TemplateUser.)

• If the template profile will be distributed manually to multiple users:

a) Create a directory where the template profile will be stored for

distribution to each user account created.

b) From the Windows NT-based machine hosting the template pro-

file to be used, log on as an administrator.

c) From the Control Panel, click System. From the User Profiles

page, use the Copy To option to enter the path of the directory you just created.

d) Modify the permissions to allow the Everyone group to use the

profile. To do this, click the Change button, select the group, and click OK.

e) Continue to Step 9.

• If the template profile will be distributed via the Default User folder

on validating servers:

a) Create a Default User directory in the NETLOGON share (which

is %systemroot%\Repl\Import\Scripts by default) of validating domain controllers. This folder name must be named Default User or the profile will not be downloaded from the server. To keep the Default User profile consistent across domain controllers and to ease administrative overhead, you can create this folder on one computer and then use the directory replication service to export it to all validating domain controllers.

b) If a user logs on and does not have an existing local or server-

based profile and your implementation uses the Default User folder on validating domain controllers, Windows NT will check the NETLOGON share for the Default User profile before it uses the local default profile. (Workstations save the server Default User profile on a local cache.) Windows NT will check the time/date/size of the server copy against the locally cached copy before downloading the server copy. And, if the files are identical, Windows NT will use the local copy of the server Default User profile.

c) Continue to Step 10.

9. In the \\server\share from Step 1, create the directory structure you specified as the path in Step 3. For example, create the directory mydomainuser under \\myserver\myshare. If the profile is to be stored within the user's home directory, use the directory structure \mydomainuser\profile under \\myserver\myshare.

Microsoft Windows NT Server White Paper 13

10. Copy the profile appropriate to your implementation.

• To copy an existing user’s profile to another user:

a) From the Windows NT-based machine hosting the profile to be

used, log on as an administrator.

b) From the Control Panel, click System. On the User Profiles page,

select the profile to be copied and use the Copy To option to enter the path of the directory you created in Step 9.

c) Modify the permissions to reflect the proper account. To do this,

click the Change button, select the account, and click OK. Click OK again to copy the profile.

• To copy the template profile to the Default User folder on validating

domain controllers:

a) From the Windows NT-based machine hosting the profile to be

used, log on as an administrator.

b) From the Control Panel, click System. On the User Profiles page,

select the profile to be copied and use the Copy To option to enter the path of the Default User directory on the validating domain controller.

c) Modify the permissions to reflect the Everyone group. To do this,

click the Change button, select the account, and click OK. Click OK again to copy the profile.

• To copy a template profile manually to a number of users:

a) Copy the entire contents (files and subdirectories) from the direc-

tory containing the template user profile created in Step 8 to the directory created in Step 9.

b) Repeat this for each of the user profile directories that will receive

the template user profile.

14 Microsoft Windows NT Server White Paper

NOTES:

• When entering the path to the target directory, you can use Uniform Naming Convention (UNC)

names. However, if you are going to use the Browse function to locate the target directory for the profile, it is important that you first map a drive to the \\server\share where the profile will be stored.

• The mydomainuser name shown in Step 2 does not have to be the user’s name. Many user accounts

or groups can be configured to point to the same profile. Of course, if the profile is shared by a group of users and is not mandatory, as each user logs off, the user’s changes are written back to the shared profile.

• The profile does not need to be stored one directory below the server\share. The profile can be

nested several directories below, or the profile path can be local.

• If the profile path points to a directory on the local machine, a share is not needed.

• The variable %USERNAME% is replaced by the user name only once in the User Profile path in User

Manager, and it must be the last subdirectory in the path. However, extensions can still be added, such as .usr or .man.

• You can select any group or a specific user when setting the permissions. However, only the user or

group specified will be able to use the profile. For this reason, it is recommended that the Everyone group be given permission to use template profiles.

Once the above steps are completed, the user receives the appropriate

profile as follows:

• If the user is to receive the Default User profile from a Windows NT 4.0- based workstation, the workstation’s default profile is used when the user first logs on. When the user logs off, the profile is automatically written to the local cache and to the server-based profile.

• If the user is to receive the Default User profile from the validating domain controller, the default profile from the server is used when the user first logs on. When the user logs off, this profile is automatically written to the local cache and to the server-based profile.

• In all other cases, the profile—including the folder trees and the NTuser.xxx file originally included with the profile—is written to the user’s profile directory. The permissions are also encoded into the binary NTuser.xxx file.

Creating a New Mandatory User Profile for Windows NT 4.0

To create a new mandatory User Profile:

1. If a location has not already been prepared, create a directory on the server and establish a network share. Users who will have mandatory profiles need only Read permissions to the shared directory. (For more information on planning for this type of user, read the sections “Selecting a Location to Save User Profiles” and “Setting Permissions for User Profiles” earlier in this document.) If your implementation stores user profiles within users’ home directories, make the profile directory a subdirectory of the user’s home directory. (Note that this approach precludes the use of the %USERNAME% variable.) To prevent the share from being browsable, append “$” to the share name.

2. If this will be a domain user or if this will be a local account for a Windows NT Server, use User Manager for Domains to create the account. If this will be a Windows NT 4.0 Workstation account, use the version of User Manager included in the Administrative Tools program group. Refer to your operating system documentation and online Help for procedures when using these tools. (Note that for this example, the user account is mydomainuser.)

3. Enter the User Profile path. This is the location where the User Profile will be stored, for example: \\myserver\myshare\mydomainuser.

Or, if the profile is being stored within the user’s home directory, use:

\\myserver\myshare\MyUsersHomeDir\profile.

4. Determine if an extension needs to be appended to the User Profile path. If it will be mandatory that the user reads the profile from the server, and if logon will be denied unless this is the case, add the extension .man to the User Profile path; for example: \\myserver\myshare\mydomainuser.man.

5. Use User Manager to create an account for establishing the template profile. So that you can easily identify this account, we recommend that it be

Microsoft Windows NT Server White Paper 15

called TemplateUser.

6. Using the template account (TemplateUser), log on to the local machine or domain. A new directory with the same name as the user name created in Step 2 will be created in the %systemroot%\Profiles directory when you first log on. For example, if the user name is TemplateUser, the resulting directory name will be %systemroot%\Profiles\TemplateUser.

7. Modify any items that need to differ from the current default (for example, you may choose to modify the background color or bitmap, shortcuts on the desktop, and View options in My Computer).

8. Log off, and then log back on to the same computer using an account with administrative privileges.

9. In the \\server\share from Step 1, create the directory structure you specified as the path in Step 3. For example, you would need to create the directory mydomainuser under \\myserver\myshare. Or, if the profile is stored in the user’s home directory, you would need to create the directory structure \mydomainuser\profile under \\myserver\myshare.

If you appended the .man extension to the User Profile path in Step 4, append the .man suffix to the directory name for the folder where the profile will be stored. The .man extension identifies a Windows NT 4.0 mandatory profile that must be accessible for the user to logon. For example, if the user name is mydomainuser, the path to the mandatory profile would be \\myserver\myshare\mydomainuser.man.

If you also have a mandatory Windows NT 3.5x profile for the user, use the .pdm extension in place of the .man extension (for example, \\myserver\myshare\mydomainuser.pdm). The .pdm extension is required because the profile folder cannot have the same name as the Windows NT 3.5x User Profile located in the same parent folder.

10. From the Windows NT-based machine hosting the template profile to be used, log on as an administrator.

11. From the Control Panel, click System. From the User Profiles page, select the profile to be copied and use the Copy To option to enter the path of the directory you created in Step 9.

12. Modify the permissions to allow the user or group to use the profile. To do this, click the Change button, select the account, and click OK. You can select any group or specific user when setting the permissions; however only the user or group specified will be able to use the profile.

The profile—including the folder trees and the NTuser.xxx file originally included with the profile—is written to the location you designated. The permissions are also encoded into the binary NTuser.xxx file.

13. In the directory that the profile was copied to in Step 3, check the NTUSER.xxx file for the .man extension. If the extension is .dat, the profile will still be modifiable. Change the extension to .man if necessary.

16 Microsoft Windows NT Server White Paper

NOTES:

• When entering the path to the target directory, you can use universal naming convention (UNC)

• The mydomainuser name shown in Step 2 does not have to be the user’s name. Many user accounts

or groups can be configured to point to the same profile. Because this is a mandatory profile, this may be the desired use of the profile since the administrator wants all the users in the group to receive the same settings.

• The profile does not need to be stored one directory below the \\server\share. The profile can be

nested several directories below, or the profile path can be local.

• If the profile path points to a directory on the local machine, a share is not needed.

• The variable %USERNAME% is replaced by the user name only once in the User Profile path, in User

Manager, and it must be the last subdirectory in the path. However, extensions can still be added, such as .usr or .man.

• The %LOGONSERVER% variable can be used for mandatory profiles to provide fault tolerance. Do

not place double slashes ( \\) in front of %LOGONSERVER%; doing so will prevent the variable from being read properly. See Microsoft Knowledge Base article Q141714 for more information.

• You can use the TemplateUser account to test changes before making them available to users by

copying the adjusted profile directory to test accounts prior to rollout.

• You can select any group or a specific user when setting the permissions. However, only the user or

group specified will be able to use the profile. For this reason, it is recommended that the Everyone group be given permission to use template profiles.

Making a Roaming Profile Mandatory in Windows NT 4.0

You have two options when configuring a mandatory roaming profile: you can change the user’s ability to modify the User Profile, or you can change the user’s ability to modify the User Profile and enforce the use of the serverbased profile at logon. With the second option, the user is not able to log on to the system if the network profile is unavailable. Each of these procedures will be explained more fully below.

Changing the User’s Ability to Modify a Profile

When creating a User Profile or at any time thereafter, you have the option of enforcing whether or not the user can modify the profile by changing the extension on the NTuser.dat file. The NTuser.dat file is located in the root of the user’s profile directory. If you change the name of this file to NTuser.man, when Windows NT reads the profile, it marks the profile as read-only, and any changes that the user makes while logged on are not written back to the server-based profile when he or she logs off.

To change the user’s ability to make modifications to the User Profile

1. Locate the user’s profile in the account’s User Profile path.

2. While the user is logged off, rename the NTuser.dat file to NTuser.man. (Note that if you make this change while the user is logged on, the user’s copy of the profile will overwrite your changes, because at the time the user logged on, he or she had permission to overwrite the profile.)

Microsoft Windows NT Server White Paper 17

Be cautious if you use the Explorer interface to make these changes. If you have the “Hide file extensions for known file types” option enabled (this is the default), be sure to check the properties to be sure that there are not two extensions. For example, say you want to make a profile mandatory and you use Explorer to rename the NTuser.dat file name to NTuser.man. Because of the Hide extensions default, Explorer saves the file as type .man, but does not display the .man extension. Later, you decide to allow the user to make changes again, and through Explorer, you rename the file back to NTuser.dat. However, because Explorer was hiding that part of the file name that determines its type, the only thing you rename is the prefix. The file name is now NTuser.dat.man. To avoid this situation, you can either rename files from the command line or change the behavior of Explorer.

Enforcing the Use of the Server-based Profile

In addition to enforcing the read-only property of a profile, the administrator can duplicate the functionality that was available in Windows NT 3.5x of not allowing the user to log on unless the server profile is available.

To enforce the use of the server-based profile for a given user:

1. Append the .man extension to the User Profile path in User Manager as explained in the previous section. (Skip this step for users who have existing Windows NT 3.5x profiles and who already have the .man extension appended to their profile paths.)

2. If the user already has a Windows NT 3.5x mandatory profile on the server, change the name of the folder where the Windows NT 4.0 roaming profile currently exists to foldername.pdm. If the user logs on to a Windows NT 4.0-based workstation and the User Profile path contains the .man extension, Windows NT will determine that a mandatory Windows NT 3.5x profile exists and will automatically replace the .man extension with .pdm and will look for the directory path configured in the User Profile path. For example, at logon if the User Profile path is configured to use \\server\share\username.man, Windows NT will look for \\server\share\username.pdm for the correct profile to load.

If only the Windows NT 4.0 user profile exists, change the name of the

folder where the Windows NT 4.0 roaming profile exists to folder- name.man. If the user logs on to a Windows NT 4.0-based workstation and the User Profile path contains the extension .man, Windows NT will look for the directory path configured in the User Profile path. If Windows NT does not find the directory, it will replace the .man extension with .pdm, and will check again.

3. If you haven't already done so, change the name of the NTuser.xxx file to NTuser.dat. (Refer to the section, “Changing the User’s Ability to Modify a Profile, ” in this document.)

18 Microsoft Windows NT Server White Paper

Creating a New Roaming User Profile for a Windows 95 User

If you have Windows 95 users in your domain, you can create roaming user profiles for them as well.

To create a roaming user profile for a Windows 95 user

1. On the client Windows 95-based computer, start Control Panel, and select Passwords.

2. From the User Profiles property page, enable the option that allows users to have individual profiles, and set the Primary Network Logon to Client for Microsoft Networks.

3. Reboot the client machine.

4. Use User Manager for Domains to create the user account (if it does not already exist). For the user’s home directory, specify the location where the User Profile will be stored. An example would be:

This automatically creates a folder with the user name. If a dialog box is displayed stating that the operation failed, create the folder manually before continuing.

5. Decide whether the user will receive a specific profile or if a default will be used instead:

• If the user will receive a specific profile, from the Windows 95-based

computer hosting the profile to be used, copy the complete contents of the local Profile folder to the folder created in Step 4. This writes the profile to the destination, including the folder trees and the User.xxx file originally included with the profile.

• If a default profile will be used, no administrative action is required.

When the user logs on, the Default User Profile from the local Windows 95-based machine will be used. At log off, this profile will be written to the user’s home directory with any customizations the user has made.

NOTES:

• If you need to troubleshoot problems with users not receiving their User Profiles, have the users execute the command: NET USE * /HOME from the command prompt on the client machine. This verifies that the user can access the home directory, and allows the user to verify that the User Profile exists in that folder.

• The profile does not need to be stored one directory below the \\server\share. The profile can be nested several directories below, if desired.

Microsoft Windows NT Server White Paper 19

Creating a New Mandatory User Profile for Windows 95

If you have Windows 95 users in your domain, you can create new mandatory user profiles.

To create a mandatory user profile for a Windows 95 user:

1. On the client Windows 95-based computer, start Control Panel, and select Passwords.

2. From the User Profiles property page, enable the option that allows users to have individual profiles, and set the Primary Network Logon to Client for Microsoft Networks.

3. Reboot the client machine.

This automatically creates a folder with the user name. If a dialog is displayed stating that the operation failed, create the folder manually before continuing.

5. Copy the Template Profile that you are using for mandatory profiles to the user’s home directory:

• From the Windows 95-based machine hosting the mandatory, copy

the complete contents of the local Profile folder to the folder created previously. This writes the profile to the destination, including the folder trees and the User.xxx file originally included with the profile.

• If you have not already done so, rename the User.dat file to

User.man.

At logon, the user will download the mandatory profile, cache it, and no

changes will be written back to the server at log off.

20 Microsoft Windows NT Server White Paper

NOTES:

• The profile does not need to be stored one directory below the \\server\share. The profile can be nested several directories below, if desired.

• Alternatively, a new profile can be made mandatory by the user logging on, logging off, and the administrator changing the User.dat file to User.man.

Maintaining User Profiles with Control Panel System Properties

In Windows NT 4.0, much of the functionality provided by individual tools in Windows NT 3.5x has been consolidated in the Control Panel System Properties application. And System Properties, when used in conjunction with the

System Policy Editor, provides even greater functionality than Windows NT

3.5x delivered. Some of the features of System Properties are described next.

NOTE: In Windows NT 3.5x, you used the User Profile Editor to modify User Profile properties. In Windows NT 4.0, this tool has been replaced by a combination of the User Profile structure and System Policies. User Profile Editor is not included in the Windows NT 4.0 package.

The User Profiles property sheet (shown in the figure below) allows you to view the list of User Profiles. From there you can delete, copy, or modify the profile type for each of the profiles listed. Note that the profiles listed are only for those users who have interactively logged onto the local machine. User profiles that have been created and not used or profiles that are stored for use on remote machines are not included in this list. Furthermore, if a user does not have administrative rights, only that user’s profile is listed. Administrators have permissions to see all available profiles.

Deleting Profiles

The User Profiles property sheet allows users with administrator privileges to delete unused profiles that still exist on a local computer. (In Windows NT 3.5x, this function was available in the Main group of the Windows NT Setup program.) To delete a User Profile, select the profile name and click the Delete

Microsoft Windows NT Server White Paper 21

button. This deletes the User Profile on the local machine, but it does not delete the associated User Account. Note that sometimes the phrase “Account Deleted” is present in the list of profiles. These are accounts that were deleted from the User Account Database, but whose profiles still exist on the local computer.

If you need to delete profiles on remote computers, the Delprof.exe utility available in the Windows NT Server Resource Kit, version 4.0, provides this functionality. Windows NT 4.0 User Profiles can grow quite large and can take up considerable disk space, particularly if several people are using one computer. With Delprof.exe, you can reclaim disk space by removing profiles that are no longer needed. This utility deletes User Profiles on computers running Windows NT, and it can be used on a local or remote computer running Windows NT 4.0 or earlier. However, because Delprof.exe is Unicode-based, it cannot run on Windows 95.

NOTE: Delprof.exe will delete everything contained in a user's profile, including settings, colors, and user documents. Please be aware of any user documents that may be deleted before using this tool.

The syntax of Delprof.exe is as follows:

delprof [/q] [/i] [/p] [/c:\\computername] [/d:days] [/?]

Where:

/q Runs Delprof.exe in quiet mode, with no confirma-

tion for each profile to be deleted.

/I Indicates that Delprof.exe should ignore errors and

continue deleting.

/p Prompts for confirmation before deleting each pro-

file.

/c:\\computername Specifies a remote computer name on which to run

Delprof.exe.

/d:days Specifies the number of days of inactivity (days is

an integer). Profiles with longer inactivity will be deleted.

/? Displays command-line syntax.

See the Windows NT Server Resource Kit for more information.

It is important to note that if a user is logged on locally to a machine and then attempts to delete his or her own profile, a message will appear stating that the profile is currently in use and cannot be deleted. The user must log off, log back on using a different account with administrator privileges, and delete the profile. In addition, if a service is running for a particular user account, the same message may appear. If this happens, stop the service and then delete the profile.

22 Microsoft Windows NT Server White Paper

Changing the Profile Type from Roaming to Local

With the User Profiles Change Type feature, a user can control which copy of

+ 74 hidden pages