Guide To Windows NT 4.0 Profiles and Policies (Part 3 of 6)

Article translations Article translations
Article ID: 185588 - View products that this article applies to.
This article was previously published under Q185588
This article has been archived. It is offered "as is" and will no longer be updated.
Expand all | Collapse all


This article is the third in a series of articles that provides information and procedures for implementing Microsoft Windows NT 4.0 Profiles and Policies on client workstations and servers.

A whitepaper is available that contains all of this information and additional flowcharts, diagrams and examples and can be downloaded from the following web page:
NOTE: The above link is one path; it has been wrapped for readability.

For the other sections of this guide, please see the following article(s) in the Microsoft Knowledge Base:
161334 Guide to Windows NT 4.0 Profiles & Policies Part 1 of 6
185587 Guide to Windows NT 4.0 Profiles & Policies Part 2 of 6
185589 Guide to Windows NT 4.0 Profiles & Policies Part 4 of 6
185591 Guide to Windows NT 4.0 Profiles & Policies Part 6 of 6

More information

                   Windows NT Server Operating System
                             White Paper
         Guide to Microsoft Windows NT 4.0 Profiles and Policies

Copyright 1997 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of
Microsoft Corporation on the issues 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

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


During Windows NT 4.0 Workstation installation, the setup program creates a
generic User Profile, the Default User, and saves it in a folder in the
profiles directory. These default settings define an environment for new
users who log on to the computer locally or who log on to a domain that
does not contain a network Default User profile. When a new user logs on, a
profile directory is created for that user, and the default settings are
written to the new user's directory. (The profile may or may not then be
customizable, depending upon how the administrator has configured

In Windows NT 4.0, administrators have the option of generating a network
Default User profile that, if present, will be used before the local
Default User profile is used. With the original retail release of Windows
NT 4.0, workstations downloaded this network Default User profile and the
most recent NTconfig.pol file, and cached them in the local Default User
(Network) and Policy folders, respectively. Then, instead of automatically
downloading these from the server whenever they were needed, the logon
process compared the time/date/size stamps of the two versions, and if they
were the same, used the cached versions without performing another
download. With Windows NT 4.0 Service Pack 2, however, the System Policy
file, NTconfig.pol, is downloaded during each logon. (The profile
functionality remains unchanged-the profile is downloaded only if the local
copy is out of date.)


Windows NT 4.0 records which profile should be used by which user by
placing registry keys for the user's security ID (SID) in the registry in:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

Each user who has logged on to the local machine will have a SID recorded
here in a subkey, with a value that contains the path to that user's local
profile, ProfileImagePath. Should multiple users with the same account name
log on to the network, separate distinct profiles are created for each. For
example, if multiple users with the account name John Smith log on to the
computer, the first John Smith is assigned a folder named JohnSmith.
Subsequent users with the same name are assigned folders named JohnSmith
with a numerical suffix appended, for example JohnSmith.000, JohnSmith.001,
and so forth.


As system administrator, you may need to change a given setting to avoid
unnecessary user interaction, to make modifications before setting the
profile to mandatory, or to add custom registry entries. In addition, you
may need to modify the Default User Profile on a computer before new users
log on and use it as the template. You can open a specific user's profile
or the Default User Profile and customize it manually as explained in the
procedure below.

NOTE: Make sure that the user is not logged on before using this procedure.
If the user is logged on while changes are made, the changes will be
overwritten by the user's preferences because profile settings are saved at
log off.

As discussed earlier, the NTuser.dat file contains all of the registry
settings located in HKEY_CURRENT_USER. As system administrator, you can
modify the data contained in the NTuser.dat portion of the profile by
loading the hive into the registry.

To manually customize a User Profile:

1. Locate the profile to be modified.

    - If the profile is a server-based profile, locate the
      \\server\share\username and determine the extension on the

    - If the profile is a local profile, locate the
      %systemroot%\Profiles\username directory, and determine the extension
      on the file.

    - If you need to edit the Default User Profile, locate the
      %systemroot%\Profiles\Default User directory, and determine the
      extension on the file.

    - If you need to edit the Network Default User Profile, locate the
      Default User folder in the NETLOGON share of the domain controllers
      that are doing user authentication, and determine the extension on
      the file. If there is more than one domain controller and
      directory replication is ensuring that the "Default User" profile is
      the same on all domain controllers, open only the profile on the
      domain controller which is the export server.

2. Start Regedt32.exe, and select the HKEY_USERS on Local Machine window.
   Highlight the root key of HKEY_USERS.

3. From the Registry menu, select Load Hive.

4. Browse for the directory identified in Step 1, and select the
   file located in that directory.

5. A dialog will prompt you to enter a Key Name. You can use any value, but
   you must remember this value so that you can select it during the unload
   process. For this reason, we recommend that you use the user name.

6. Click Enter. This adds the profile registry hive as a subkey to
   HKEY_USERS, as shown in the illustration below.

7. Edit the existing values as necessary.

8. After completing the changes, highlight the root of the user's profile
   registry key, and from the Registry menu, select Unload Hive. This saves
   the changes to the user's profile. (When you first selected Load Hive,
   the key was mapped to the file selected in the Open dialog. A Save As
   option is therefore unnecessary.)


To modify a Windows NT-based workstation's Default User Profile settings or
to modify the Network Default User Profile, load the hive into
the registry as outlined above, make the necessary changes, and unload the
hive (this automatically saves the changes).

 - The workstation Default User Profile is located in the
   \%systemroot%\Profiles\Default User directory.

 - To make changes to the Network Default User Profile, use the
   file from the scripts export directory
   (%systemroot%\system32\repl\export\scripts) of the domain controller
   that is the export server for the domain. Any changes that you make to
   this file will be replicated to the other domain controllers (which are
   import servers).

To provide users with a Default User Profile that contains custom
shortcuts, folders, and files that are not centrally managed, place the
icons in the appropriate folder within the Default User Profile. New users
will receive the shortcuts, folders, and files as part of their new
profiles. For example, if you want each new user that logs on to a given
computer to receive a folder called "My Storage" on the desktop, just
create this folder in the path:

   \%systemroot%\Profiles\Default User\Desktop


When you upgrade Windows NT 3.5x roaming profiles (.usr profiles), you do
not need to change anything in the profile path configured in the user
account. When the user logs on to a Windows NT 4.0-based machine and the
profile is found to be a Windows NT 3.5x profile, a process automatically
looks for the equivalent Windows NT 4.0 profile. If the profile isn't
found, a conversion process creates a new Windows NT 4.0 profile using the
settings established in the Windows NT 3.5x profile.

During the conversion process, Windows NT 4.0 creates a directory for the
new profile in the same location as the existing Windows NT 3.5x profile.
The resulting directory has a .pds extension, which stands for Profile
Directory Structure, rather than the previous Windows NT 3.5x .usr
extension. For example, if the User Profile path for the Windows NT 3.5x
user mydomainuser is \\myserver\myshare\mydomainuser.usr, and the user logs
on to a Windows NT 4.0-based machine, the profile directory
mydomainuser.pds would be created within \\myserver\myshare.

This approach allows the user to log on to the network from either a
Windows NT 3.5x or 4.0-based workstation. If the user were to log on from a
Windows NT 3.5x-based computer, the profile path would direct the Windows
NT 3.5x-based machine to the User Profile used prior to the Windows NT 4.0
upgrade. If the user then moved to a Windows NT 4.0-based computer, the
user's Windows NT-based workstation would recognize that the profile
contained Windows NT 3.5x syntax, would replace the .usr with .pds, and
would then use that string to locate the Windows NT 4.0 profile. The
resulting Windows NT 4.0 structure will be the Windows NT 3.51 profile (now and the Default User Profile folders.

It is important to emphasize that the Windows NT 3.5x profile is not
deleted-it is still available to the user should they ever log on from a
Windows NT 3.5x-based computer. It is also important to note that the
settings for these two profiles are completely independent; changes made to
the Windows NT 3.5x profile will not be reflected in the Windows NT 4.0
profile, and vice versa.

NOTE: As an administrator, if you review the directory structures in the
share where users' roaming profiles are stored, and no .pds or .pdm
extensions are appended, this is normal. No extension is appended to
roaming profile directories that are new to Windows NT 4.0. These
extensions are only added when profiles are migrated from Windows NT 3.5x
to 4.0, or when the administrator creates a new Windows NT 4.0 mandatory
profile that requires a successful logon.


Upgrades of Windows NT 3.5x mandatory profiles to Windows NT 4.0 cannot be
done automatically. This is because the same restrictions that prevent a
user from saving any changes to his or her profile also restricts the
system's ability to generate a new Windows NT 4.0 mandatory profile from an
existing profile.

When you upgrade a Windows NT 3.5x mandatory profile, the profile path does
not need to be modified. However, you will need to create a new mandatory
profile with the same desired settings. To create the mandatory profile,
you can remove the mandatory extension from the old profile and force a
conversion, or you can create the new profile from a template. Both
procedures are explained below.

To create a mandatory profile from the old profile:

1. Replace the .man extension on the existing mandatory profile with the
   extension .usr.

2. Change the extension on the user's profile path from .man to .usr.

3. Allow the user to log on. This permits the conversion to take place.

4. Have the user log off. This creates a directory with the name of the
   profile and a .pds extension.

5. Change the .pds folder extension to .pdm and change the user's profile
   path back to .man.

6. Rename the NTuser.dat file to

To create the profile from an existing template profile:

1. In the \\server\share specified in the User Profile path, create a
   folder with the directory name of the location where the profile is
   stored. Use the .pdm extension for this directory name. For example, if
   the user name is domainuser, the directory name would be

2. On the Windows NT-based computer hosting the profile, log on as an
   administrator and map a drive to the \\server\share where the profile
   will be stored.

3. From the Control Panel, click System.

4. On the User Profiles page, select the profile to be copied. Use the Copy
   To option to select the user's folder created in Step 1, modify the
   permissions to reflect the proper account, and click OK.

   The profile is now written to the designated location, including the
   folder trees and the file originally included with the
   profile. The permissions are also encoded into the binary

5. In the directory that the profile was copied to, check the
   file for the .man extension. If the extension is .dat, the profile will
   still be modifiable. Change the extension to .man, if necessary.

Note that because the User Profile was saved into a directory with a .pdm
extension, both the Windows NT 3.5x and Windows NT 4.0 profiles exist on
the server. A user can log on from either a Windows NT 3.5x or Windows NT
4.0-based computer, and the appropriate profile will be used.


As explained previously in this document, a user is given explicit
permissions to use a profile, and these permissions can be created and
controlled by an administrator or generated automatically by the system
when the user first logs on.

If a profile has permissions that differ from those needed by the user (for
example, if the profile was created for a user on a different domain), the
profile permissions must be changed to function correctly. As an example,
suppose you have a Windows NT-based workstation that you would like to have
join the domain, but you want the user to be able to retain his or her
profile settings. The Windows NT-based workstation is currently a part of
the WORKER workgroup and will be joining the domain BIGDOMAIN.

To change the profile:

1. Log on to the computer as an administrator, and create a local account
   that will be used only temporarily to house the profile during the
   conversion process.

2. Log on as a temporary user and immediately log off. This will create a
   subdirectory underneath the %systemroot%\Profiles directory with the
   name of the account that logged on.

3. Log back on as an administrator, and configure the workstation to join
   the domain.

4. After the workstation has joined the domain, reboot the computer.

5. After the machine restarts, log on as the user from the domain that will
   need the converted profile, and then log off. This sets up the directory
   structure needed to complete the conversion process.

6. Log back on as an administrator, and copy the profile structure,
   including the file and all subdirectories, from the directory
   that stored the workgroup user's profile to the subdirectory created for
   the temporary user in Step 2.

7. From the Control Panel, click System.

8. On the User Profiles property page, select the temporary user profile,
   and click Copy To. Browse under %systemroot%\Profiles to locate the
   subdirectory that contains the profile for the domain user that logged
   on in Step 5. Click OK and then click the Change button for the

9. Select the domain user who will use the profile. Click OK to copy the

10. Log off and log on as the domain user. The profile settings should now
    be available to that user.

NOTE: Alternatively, you can copy the profile and use the instructions from
the section "Encoding Permissions in the User Profile" to change the
permissions. However, this requires that you manually edit the registry.


In some cases, you may want to create profiles that include preconfigured
persistent connections. However, if you need to supply alternate
credentials when you create the template profile, this can cause problems
for users later when the profile is used.

Information about persistent connections is stored in the registry location
HKEY_CURRENT_USER\Network. This key has subkeys that list the persistent
drive connections by drive letter. For each of these subkeys, there is a
value of UserName. If alternate credentials must be supplied to make the
connection, those credentials are also stored here. Note that this includes
only the domain and user account name; the password is not included. When
the user receives this profile and logs on, Windows NT attempts to
reconnect the drive, but the alternate credentials are sent rather than
those of the logged on user.. Note that if the UserName value contains a
blank string, the credentials of the logged on user are sent (which is the
desired behavior in this case).

To avoid inadequate credentials or wrong credentials being sent, use one of
the following approaches:

 - Avoid having to supply alternate credentials when you create the
   connections to network resources in the shared profile by granting the
   user creating the template profile sufficient permissions in advance.

 - Before modifying the profile to be a mandatory profile, run a REGINI
   script that removes the credentials from the UserName value. Do not
   delete the value, only the string data.


The Userenv.log is an invaluable tool for troubleshooting the process of
loading and unloading User Profiles. Each step in the User Profile process
is recorded in the log, including informational and error-related messages.

The checked version of the UserEnv.dll is the same dynamic link library
(.dll) as the retail version, except that it contains debug flags that you
can set and use with the kernel debugger.
This file, which is included in both the Windows NT Device Driver Kit (DDK)
and the Windows NT Software Development Kit (SDK), when used in conjunction
with a registry entry, generates a log file that can be used in
troubleshooting and debugging problems with roaming profiles and system
policies on Windows NT 4.0 clients.

To enable logging:

1. Rename the file UserEnv.dll in the %systemroot%\SYSTEM32 directory to
   Userenv.old or to a unique name of your choice.

2. Copy the checked version of UserEnv.dll to the %systemroot%\SYSTEM32
   directory of the client machine that you want to debug. The checked
   version of the UserEnv file must match the version of the operating
   system and Service Pack installed on the client computer.

3. Start REGEDT32 and locate the following path:


4. Create a new value called UserEnvDebugLevel as a REG_DWORD type. Assign
   the hex value 10002.

5. Reboot the computer.

Logging information will be recorded in the root directory of the C drive
as UserEnv.log. You can use Notepad to view the log file. A sample log is
provided next.

Sample Log

LoadUserProfile. : Entering, hToken = <0xac>, lpProfileInfo = 0x12f4f4
LoadUserProfile: lpProfileInfo->dwFlags = <0x2>
LoadUserProfile: lpProfileInfo->lpUserName = <administrator>
LoadUserProfile: NULL central profile path
LoadUserProfile: lpProfileInfo->lpDefaultPath = <\\DfsES\netlogon\Default
LoadUserProfile: lpProfileInfo->lpServerName = <\\DfsES>
LoadUserProfile: lpProfileInfo->lpPolicyPath =
RestoreUserProfile: Entering
RestoreUserProfile: Profile path = <>
RestoreUserProfile: User is a Admin
IsCentralProfileReachable: Entering
IsCentralProfileReachable: Null path. Leaving
GetLocalProfileImage: Found entry in profile list for existing local
GetLocalProfileImage: Local profile image filename =
GetLocalProfileImage: Expanded local profile image filename =
GetLocalProfileImage: Found local profile image file ok
Local profile is reachable
Local profile name is <D:\WINNTDfs\Profiles\Administrator>
RestoreUserProfile: No central profile. Attempting to load local profile.
RestoreUserProfile: About to Leave. Final Information follows:
Profile was successfully loaded.
lpProfile->szCentralProfile = <>
lpProfile->szLocalProfile = <D:\WINNTDfs\Profiles\Administrator>
lpProfile->dwInternalFlags = 0x102
RestoreUserProfile: Leaving.
UpgradeProfile: Entering
UpgradeProfile: Build numbers match
UpgradeProfile: Leaving Successfully
ApplyPolicy: Entering
ApplyPolicy: Policy is turned off on this machine.
LoadUserProfile: Leaving with a value of 1. hProfile = <0x60>


Article ID: 185588 - Last Review: October 26, 2013 - Revision: 4.0
Applies to
  • Microsoft Windows NT Server 4.0 Standard Edition
  • Microsoft Windows NT Workstation 4.0 Developer Edition
  • Microsoft Windows 95
kbnosurvey kbarchive kbinfo KB185588

Give Feedback


Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from