User profiles are an automatic feature of Windows NT 4.0 that make it possible for individual users to maintain their own shortcuts and configuration settings on a single computer. Each user's profile consists of a registry hive called Ntuser.dat (except for mandatory profiles, which use an Ntuser.man file), which the system loads into the HKEY_CURRENT_USER key during the logon process, and a collection of subdirectories containing the shortcuts and other elements that comprise the user's desktop, Start menu, Send To menu, and other customized elements of the user interface.

By default, user profiles are stored in subdirectories of the %SystemRoot%\Profiles directory on the local machine, named for the users who have logged on to the system. However, it is also possible to store the profiles on server drives, by specifying the name of a shared directory in the user's account in User Manager for Domains. This makes it possible for the user to access the profile information from any computer on the network. If, for example, you are operating a university computer center with a fleet of communal PCs, you can create a server-based profile for each user and, no matter which machine users use to log on, they receive their familiar desktop arrangement and registry settings. These are known as a roaming profiles.

Storing profiles on servers also makes it possible to enforce the use of mandatory profiles. Normally, a Windows NT system updates the profile whenever a user logs off the system, saving any changes that they have made to the interface or the registry during the session. In a mandatory profile, however, this update does not take place. No matter what changes users make during the session, they receive their original configuration the next time they log on.

The default environments provided with the Zero Administration Kit employ neither roaming nor mandatory user profiles. This is because the ZAK configurations are designed to prevent users from making any changes to the registry or the desktop interface that would be reflected in the profile. If, however, you create your own customized ZAK environments that relax the strict lockdown policies enforced on AppStation and TaskStation systems, you may want to employ roaming profiles to enable your users to log on from different workstations, or mandatory profiles to keep users from changing the system configuration.

Another reason why the ZAK does not employ user profiles is that they are inherently less secure than other methods of securing the computer, such as system policies. You can, for example, use mandatory profiles to prevent users from making any permanent changes to the entries in the HKEY_CURRENT_USER registry key, but this does not prevent them from modifying registry values; it only prevents the system from writing those values to the hive stored in the profile during the logoff procedure. Given access to the appropriate tools, users can still do substantial damage to the system by making improper registry modifications.

For this reason, you should employ user profiles in combination with other Windows NT security mechanisms, such as system policies and NTFS permissions. In most cases, it is the roaming profile capability that is most useful to the ZAK system administrator. Roaming profiles make it possible to support multiple ZAK system configurations on the same computer. In any environment where users with different levels of expertise are likely to work on different systems at various times, creating a series of roaming profiles can be more efficient than keeping track of which computers are configured for which type of user.

It is important to understand that you do not necessarily have to create a separate user profile for each user on your network. In some cases, it is simpler to create a profile for each ZAK environment or type of user instead. It is possible for multiple users to share the same profile, as long as that profile is mandatory. It is necessary for shared profiles to be mandatory, because the changes made to the profile by various users at logoff time would otherwise overwrite each other.

This chapter describes how user profiles function on Windows NT systems, and examines the tools and techniques used to deploy them as part of your own ZAK workstation environments.

Using Local Profiles

During the installation of the Windows NT operating system on a workstation, two user profile directories are created in %SystemRoot%\Profiles, called \Default User and \All Users. The Default User profile is a template for all of the subsequent profiles that will be created on the system. Whenever a new user logs on to the computer, the system copies the contents of the \Default User directory to a new profile directory created and named for that user.

The \All Users directory is not, strictly speaking, a profile directory, because it does not contain a registry hive. However, it does contain a collection of desktop and Start menu shortcuts that the system adds to every user profile during the logon process. These shortcuts appear in the Start menu below a solid line, and are the equivalent of the common groups used in Windows NT 3.5x.

Thus, when you log on to the computer for the first time using the Administrator account, the system creates a third profile directory called \Administrator that is a copy of the \Default User directory. The shortcuts in the \All Users directory appear on the desktop and in the Start menu, but they are not directly assimilated into the Administrator profile.

Profiles and Security IDs

Each user account on a Windows NT system has a unique identifier called a security ID that the system uses to distinguish users with the same name. This is an important factor when using profiles, because the registry contains a key for each user who has logged on to the system in HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList , containing the security ID for the account and the location of its user profile. This means that the associations between user accounts and user profiles depend not on the username alone, but also on the security IDs that they have in common.

For example, if you delete a user account on an NT system, the link to the user profile associated with that account is broken. Creating a new user account with the same name will not re-establish this link, because the new account will have a different security ID from the old one. The next time the user logs on to the computer, the system will create a new profile directory by adding the extension .000 to the username. The new profile will contain the contents of the profile in the \Default User directory, just like that of any other new user. The original profile for the deleted user is effectively orphaned by the removal of that account, and will never be used by the system again.

NOTE:

When the deletion of an account causes a user profile to be orphaned, you can resolve the problem by copying the contents of the orphaned profile to the new profile directory using the System Control Panel. See "Copying profiles," later in this chapter, for more information on this process.

Creating Multiple User Systems

Windows NT creates user profiles automatically whenever a new user logs onto the system. This is unlike Windows 9x, in which the use of profiles is optional. This is one reason why administrators should carefully plan and execute the installation and configuration of the system's applications before the first working user logs on. In order for the users to receive the profile elements they need to access their applications, these elements must be added to the Default User profile so that every new user logging on will receive a copy.

During a typical ZAK workstation deployment, applications are installed by a script that executes after the operating system installation is completed and the computer reboots and logs on using an administrative account. An AppStation system, for example, executes the Zakb1wrk.cmd script after logging on using an account name and password that you supplied during the Zaksetup process. To run the other elements of the script, such as Acls.cmd and Hide.cmd, the account you use for this logon requires administrative privileges, so it is therefore not likely to be the same as that which a user will employ later to log onto the system.

Most applications do not write their registry settings to the HKEY_CURRENT_USER key in the registry. They use the HKEY_LOCAL_MACHINE key instead, meaning that the settings are not a part of the user profile. However, because the Start menu shortcuts and other elements created by the application installation processes are part of the profile, they are usually created in the profile directory for the user logged onto the system at the time.

If, for example, you install the workstation applications using the Administrator account, any changes to the Start menu or the HKEY_CURRENT_USER registry key are written to the %SystemRoot%\Profiles\Administrator directory, by default. New users logging on with other accounts will have profiles created from the \Default User directory, meaning that they will have access to the application files, but they will not see the shortcuts or receive the HKEY_CURRENT_USER registry changes, if any.

To make the shortcuts and registry entries available to all users, you can copy the contents of the profile with which you installed the applications to the \Default User directory using the System Properties Control Panel or by creating a batch file that copies the profile directory to \Default User. Each new user will then receive a copy of the Default User profile during his or her first system logon.

NOTE:

When copying profile directories using batch files, be sure that neither of the profiles involved is in use during the copy procedure.

By modifying the Default User profile in this way, you create a workstation that can support multiple users with no special adjustments after the initial deployment. However, for each user to be assigned a complete profile, it is important that all of the application installation and configuration procedures, as well as the user profile manipulations, be completed before the first nonadministrative user logs on.

NOTE:

In some cases, applications write their Start menu shortcuts to the \All Users directory instead of to the profile directory for the user who is currently logged on. If no HKEY_CURRENT_USER registry entries are associated with the application, then no profile adjustments are needed, as the All Users shortcuts are added to every profile during the logon sequence.

Using System Properties to Manage Profiles

To manage the user profiles on a Windows NT machine, you use the controls on the User Profiles page of the System Control Panel (see Figure 8-1). This screen lists the profiles for all of the users who have logged on to the system, and enables you to modify their properties. The capabilities provided by this dialog box include the following:

• Copy a profile to another location on a local or server drive
• Modify the user permissions in a copied profile
• Specify the profile type (local or roaming)
• Delete a profile

NOTE:

Only users with administrative privileges can view and manage all of the system's profiles using the System Control Panel. Nonadministrative users see only the profile that is currently in use.

Each listed profile includes the size of the entire profile directory, the date that the profile was last modified, and a type designator that specifies whether the profile is local or roaming. You can use this information to determine which profile is associated with a specific directory, when duplicate names cause the system to create profile directories with numeric extensions, like .000. An "Account Deleted" entry in the list indicates that a profile still exists on the system for a user who has been deleted from the user account database.

NOTE:

Another method to determine which profile directory a particular account is using is to log on to the system with the account, right-click the Start button, and select Explore from the context menu. This opens an Explorer window that displays the root directory of the profile currently in use.

Copying profiles

To copy a user profile, you select one of the entries in the User Profiles dialog box, click the Copy To button, and specify the name of the directory to which the profile is to be copied. You can specify the destination directory using a drive letter or a UNC name, and the directory can be located on the local system or on a server drive.

The copy procedure duplicates the entire directory structure for the profile in the new location, except for the root directory in which the profile is located. Because the Copy To dialog box and its accompanying Browse window do not provide the ability to create new directories, you must use Windows NT Explorer to create the destination directory named for the user before you perform the copy operation.

NOTE:  

There is a problem with all versions of Windows NT 4.0 (through Service Pack 3) on systems with Internet Explorer 4.0x installed that causes an error to be generated during some profile copy procedures that states: "Copy profile error. The operation completed successfully." When the message appears, the copy has, in fact, not completed successfully, because of the system's inability to modify the HKCU\Software\Microsoft\Protected Storage System Provider registry key. Microsoft has released a fix for this problem, which is incorporated into Service Pack 4. As a workaround, you can disable the NT Protected Storage service in the Services Control Panel, then log on as a new user and modify the system configuration as needed. The profile that the system creates for the new user will not contain the offending registry key, since the Protected Storage service is not active, and can therefore be copied without generating an error.

Profile permissions

Whenever an NT system creates a profile for a new user, that user is granted permission to use the profile. This permission is coded into the Ntuser.dat or Ntuser.man hive in the profile and must be modified if you copy the profile for use by another logon account. The Copy To dialog box in the System Control Panel contains a Permitted To Use box that enables you to specify the user for whom the profile is intended.

Clicking the Change button displays the familiar NT account selector dialog box, from which you can select the user or group to receive permission to use the profile. Unlike the process of setting NTFS or registry permissions, however, you can select only a single user or group account for a profile. If you plan to have multiple users sharing the same profile, or if you want to create a template profile that you will copy for many users, use a group name or the Everyone entity.

NOTE:

It is also possible to modify the permissions for a profile manually, by using the Regedt32.exe application to open the hive and edit its contents. See "Manually Editing Profiles," later in this chapter, for more information.

Aside from the registry permission that users require to load a profile, they must also have the proper filesystem permissions to access the profile directory structure. If the profile is stored on an NTFS drive, whether local or server-based, you must assign the appropriate permissions to each user for his or her profile.

The Acls.cmd script included with the ZAK grants the Change permission to the Everyone group for the %SystemRoot%\Profiles directory on the local system. This enables users to read their profiles as they log on and write any changes back to the profile when they log off. Because the ZAK AppStation and TaskStation environments deny users access to the registry and file management tools they would need to modify the profiles manually, there is little danger of accidental damage. If you elect to store your users' profiles on server drives, you must assign permissions to those directories in the same way that you would on the local drive.

NOTE:

If you plan to use mandatory profiles, you can grant users only the Read permission to their profile directories, because the directories are not modified during the user logoff process.

Depending on how you configure your own ZAK environments, you may want to modify the permissions you assign to the profile directories. In order for a nonmandatory profile to function properly, the user must have the Change permission that enables him to both read and write to the profile directory. However, the Acls.cmd script grants all users the Change permission to the entire %SystemRoot%\Profiles directory on the local drive. This means that if you design a ZAK environment in which users have access to the tools needed to modify profiles directly, they can modify other users' profiles as well as their own. If this is the case, you may want to modify the permissions so as to grant users the Change permission only to their own profile directory, and not to those of other users.

To do this, you can use a Cacls.exe command in a logon script or a batch file executed using the RunOnce registry entry. To create a generic script that you can use on all of your workstations, include the %UserName% environment variable in the command, as in the following example:

cacls.exe profiles\%UserName% /g administrators:f system:f %UserName%:c

This command employs the %UserName% variable twice, first to identify the profile directory and then to specify the name of the user who should receive the Change permission.

Another security measure that you can implement is to revoke the Delete individual permission from the profile directories for your users, leaving only the Read, Write, and Execute individual permissions. This enables the systems to update the profiles as needed but prevents users from accidentally deleting the directory or its contents. To do this with a script, you use the Xcacls.exe program with a command line like the following:

xcacls profiles\%UserName% /g administrators:f system:f %UserName%:ewx NOTE:

In the syntax for the Xcacls.exe utility, the initial E is used to specify the Read individual permission, and R represents the Read standard permission. In this example, the command grants the user the Read, Write, and Execute individual permissions. Because the Read standard permission includes Delete capabilities, you do not want to apply it in this case.

Deleting profiles

When you select a profile from the list on the User Profiles page and click the Delete button, the entire contents of the profile directory for that user is deleted. However, this procedure does not delete the user account associated with the profile. To delete the account, you must use the User Manager or User Manager for Domains application.

It is also possible to delete profiles from the command line using the Delprof.exe utility included in the Windows NT Server Resource Kit. Delprof is also useful to the network administrator because it can delete profiles from remote systems anywhere on the network. The syntax for Delprof is as follows:

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

/c:\\computername

Specifies the name of a computer on the network from which a profile is to be deleted, where computername is a valid NetBIOS name.

/d:days

Specifies a period of user profile inactivity, where days is an integer representing a number of days. All profiles that have not been used for the specified number of days are deleted.

/i

Causes the program to ignore any errors that occur during processing and continue the deletion process.

/p

Causes the program to prompt the user for confirmation before deleting each profile.

/q

Causes the program to delete the profiles with no pauses for confirmation.

NOTE:

It is not possible to delete a profile that is currently in use. You must log on to the system as a different user in order to delete a profile. It is also possible for a service to run using a particular account, which makes it impossible to delete the profile associated with that account unless you stop the service first.

Manually Editing Profiles

In most cases, you should modify existing profiles by logging on to the computer with the associated account and using the standard Windows NT tools to reconfigure the system. Then, when you log off, the system saves the new settings to the profile. However, because the profile is composed of standard elements like directories, shortcuts, and registry hives, you can also manipulate it directly.

With the exception of the registry hive, you can manipulate the components of a profile using standard file management tools like Windows NT Explorer. You can add and remove shortcuts from the various profile directories, or modify their properties, and supply users with documents by adding them to the \Personal directory.

Because the Ntuser.dat or Ntuser.man file in each user profile is a standard registry hive, you can use the Regedt32.exe utility to import the hive from any profile into the registry, make any changes that are necessary, and save those changes back to the profile. To load a hive into the registry editor, launch Regedt32.exe (Regedit.exe is not capable of importing hives), select Load Hive from the Registry menu, and browse to the Ntuser.dat or Ntuser.man file in the desired profile. The program then prompts you for the name of a key into which it should import the hive. You can use any name for this key, as long as you remember it when it comes time to unload the hive in order to save your changes.

Once the hive is imported into the registry, you can browse through its contents and make any modifications that are necessary, taking into account the usual cautions whenever you modify registry contents directly. The imported hive is not actually in use, so the effects of any typographical or misconfiguration errors you make while modifying its contents will not appear until the next time the associated user logs on to the system. As always, the effects of these errors can range from the trivial to the catastrophic.

Apart from creating, removing, and modifying registry keys and entries in the normal manner, you can also use Regedt32.exe to alter the permissions that control which accounts are able to use the profile. By selecting Permissions from the Security menu, you can specify the users or groups that can access the profile. Unlike the Permitted To Use box in the System Control Panel, which only enables you to select a single user or group to access the profile, Regedt32.exe can add multiple users and groups to the permissions list.

Once you have completed making your changes to the hive, highlight the key name that you specified during the importation process and select Unload Hive from the Registry menu. This removes the key from the registry display and saves its contents back to the Ntuser.dat or Ntuser.man file you originally imported. You can use this procedure to modify the registry hive in any profile on the local system or a server drive.

Persistent Connections

Persistent connections (that is, network connections that you configure to be restored every time the user logs on) are stored in user profiles, in the HKCU\Network key, in subkeys that are named for the individual drive letters. Each drive letter subkey includes a RemotePath entry that specifies the UNC name of the network share to which the drive letter is connected, and a UserName entry that specifies the credentials that the system is to use to connect to that share. You can modify these entries like any other part of the profile's registry hive, in order to specify alternate credentials or change the share name. If, for example, you intend to copy a profile and you don't want the recipient to use the alternate credentials for a particular persistent connection, you would modify the UserName entry and replace the existing value with blank spaces (leaving the entry itself intact, however).

NOTE:

The persistent connections in a user profile do not include the password for any alternative credentials they might contain. Users must supply the password interactively during the logon process.

Using Server-Based Profiles

Storing user profiles on network servers instead of local drives provides both advantages and drawbacks to system administrators. On the plus side, a user can access a profile on a network drive from any computer on the network, and multiple users can share a single profile. Server drives also provide a measure of fault tolerance that local drives do not. If the hard disk drive on a workstation should fail, it is easier to restore the environment to its original condition when all documents and user-configurable parameters are stored on a server that can be replicated and/or backed up regularly.

The major drawback to server-based profiles is that the workstation has to download them to the local drive during the logon process. Depending on what you elect to store in the user profiles, this process can cause an irritating delay to the user. For example, the \Personal directory in each profile is intended for the storage of the documents created by the user in their various applications. During the logon process, the entire profile directory structure can be downloaded to the workstation drive, and if users have a large number of data files (or a number of large data files), this download process can be very lengthy. In general, you should create the users' home directories outside of the profile directory structure for this reason.

Creating a Server-Based Profile

To specify a location for a user profile other than in the %SystemRoot%\Profiles directory on the local drive, you must use the User Manager or User Manager for Domains application. When you click on the Profile button in the User Properties screen for any account in the NT user database, you see a User Environment Profile dialog box in which you can specify the UNC path name to the desired profile directory and the user's home directory. The profile directory can be located on any shared network drive. You can use environment variables like %UserName% in the UNC path to provide unique values for each user.

NOTE:

When you include the %UserName% variable in a UNC path for a profile directory, the system replaces the variable with the user's account name during processing. However, the variable must appear only once in the path name, and also must appear as the last subdirectory in the path. For example, a value of \\Ntserver\Profiles\%UserName% is acceptable, but \\Ntserver\Users\%UserName%\Profile is not. You can, however, append an extension to the variable in the profile path, making \\Ntserver\Profiles\%UserName%.man an acceptable value.

Creating domain users and specifying profile paths for the user accounts are processes that can be automated, using a scripting language like Perl. Ashley J. Meggitt and Timothy D. Ritchey's Windows NT User Administration (O'Reilly & Associates) documents the process of creating a user creation script that includes the specification of a customized profile path for each user.

Server-Based Profiles and the Logon Process

When a user logs on to a Windows NT system using an account that specifies a profile location on a shared network drive, the system performs the following profile access procedure:

1. The system examines the profile on the specified server drive and compares it with the user's local profile in the %SystemRoot%\Profiles directory.
2. If the server profile is newer than the profile on the local drive, the system copies the contents of the server directory to the local directory and loads the profile.
3. If the server profile is identical to the profile on the local drive, the system loads the local profile without performing a download from the server.
4. When the user logs off, the system writes any modified contents of the profile in use on the local drive back to the profile directories, both on the server and the local drive, except in the case of mandatory profiles, which are never updated.

Because NT workstations always copy server-based profiles from the server to the local drive before using them, it does not matter what operating system is running on the server. You can store profiles on Windows NT Server or Workstation systems running Version 4.0 or 3.5x, or even on NetWare servers, as long as the computers are properly configured to access the network drive.

It is important to understand that the copy operations, both to and from the server profile directory, include the entire contents of the directory and all of its subdirectories. If an administrator deletes shortcuts or other files from a directory that is part of the server-based profile, those files still exist in the workstation profile. The next time the user logs off of the system, the workstation copies the files in question back to the server. Thus, to remove a file completely, you must delete it from both the server and workstation directories.

The Network Default User Profile

All Windows NT systems have a Default User profile on the local drive that they use as a template to create profiles for new users. However, you can also create a Default User profile for an entire domain that takes precedence over the local Default User profile. To do this you must create a directory called \Default User in the root of the Netlogon share on your primary domain controller. By default, this is the %SystemRoot%\Repl\Import\Scripts directory on your NT server.

When you place a profile in this directory and a user logs on to the domain, the workstation compares the date and size stamps of the Default User profile on the server with those on the local machine. If the profiles are identical, the system uses the Default User profile on the local drive to create the new profile for the user. If they are not, the workstation copies the contents of the \Default User directory on the Netlogon share to the %SystemRoot%\Profiles\Default User directory on the local drive and creates a new profile for the user from there.

Using the NT Directory Replicator service, you can copy the server-based Default User profile to the other domain controllers on the network, so that the profile is always available to new users.

This technique is only feasible when you intend to use the same Default User profile for all of the users on your network. If you have a number of different profiles for various types of users, you are better off copying them directly into the users' designated profile directories, as long as you set the appropriate registry and filesystem permissions.

Using the %LogonServer% Variable

Normally, a user profile that is stored on a server drive is available only from that server. If the server is down or otherwise unavailable, the user cannot access the profile there. However, you can use NT's Directory Replicator service or the Robocopy.exe utility in the Windows NT Server Resource Kit to maintain copies of your profiles on all of the domain controllers on your network, so that your server-based profiles are always available to your users.

In order to make the profiles automatically available to client systems, no matter what domain controller authenticates the user account, you use the %LogonServer% environment variable as part of the profile directory path in User Manager for Domains. The system sets this variable to the name of the validating server when the user logs on to the domain. Thus, specifying a profile path like %LogonServer%\profiles\%UserName% would locate the correct profile directory on whatever domain controller authenticates the user during the logon sequence.

Creating Roaming Profiles

When you configure a user account to store its profile on a server drive by supplying a network share for the profile path in the User Manager for Domains, you are creating a roaming profile that the user can access from any system on the network. Once the user has logged on and off of a workstation once using the profile, it appears on the User Profiles page of the System Control Panel with the designation Roaming in the Type column.

On a workstation where the user has access to the System Control Panel, he can modify the Type designation for a profile in order to specify whether the system should load the local or the server-based profile during the next logon. When the Type designation is Roaming, as it is by default whenever you specify a profile path for the account in User Manager for Domains, the system compares the date and size of the local profile with those on the server at each logon. If the local profile is newer, the system prompts the user to select the profile that it should load. If the server profile is newer, the system loads it without user intervention.

If you change the profile's Type to Local by clicking the Change To button, the system will use the profile in the %SystemRoot%\Profiles directory on the local machine, despite the continued availability of the server profile. When the user logs off, the system writes the profile changes only to the local directory, not to the server directory specified as the profile path in User Manager for Domains. The system also uses the local profile automatically when the server-based profile specified in User Manager for Domains is not available, unless you have made the use of the profile mandatory.

The other parameter that you can set on the Change Type page is Use Cached Profiles on Slow Connection. When you enable this option, the system measures the time required to access the profile on the server, and if the interval is greater than a certain value (2000 milliseconds or 2 seconds, by default), the system automatically uses the local profile instead. You can specify the time interval that the system uses to determine whether a slow connection exists by setting the Slow Network Connection Timeout system policy supplied by the Winnt.adm policy template file.

NOTE:

If your users have access to the Control Panel and you want to prevent them from changing their profile type from local to roaming or vice versa, you can revoke the Read individual permission from the %SystemRoot%\System32\Sysdm.cpl file for those users. This prevents the System icon from appearing in the Control Panel. You can use this same technique with any of the other .cpl files in the directory to suppress other Control Panel icons.

Creating Mandatory Profiles

The term "mandatory" is used in two different senses when referring to user profiles. In most cases, a mandatory profile is one that a user cannot change. Even though the user might be able to modify the properties of the workstation interface that are reflected in the profile, the changes are not saved when the user logs off, thus ensuring that they always begin the next session with the same profile. To make an existing profile mandatory, you change the extension of the Ntuser.dat file to .man.

NOTE:

In order to successfully change a roaming profile to a mandatory one, you must rename the Ntuser.dat file while the user is not logged on to the network. Otherwise, the system writes the profile back to the server as Ntuser.dat when the user logs off, causing the most recent registry changes to be lost.

The existence of an Ntuser.man file in a profile directory prevents the system from writing modifications to the profile at logoff time, but it does not in itself prevent the user from manually altering the contents of the profile. A user with access to the appropriate tools and who possesses the proper permissions can modify the contents of the registry hive and the directories that make up the profile. This is why you should carefully protect the profile with filesystem and registry permissions, in addition to making it mandatory. Because the workstation never writes changes back to the profile, the user needs only the Read standard permission to the profile directory.

The second type of mandatory profile is one in which the user is not only prevented from modifying the contents of the profile, but is also required to log on using that profile. If the drive on which the profile is stored is inaccessible, the user is not permitted to log on to the system. To create this type of mandatory profile, you modify the name of the profile directory on the server by adding a .man extension. You must also include the .man extension in the profile path that you specify in the User Manager for Domains application.

NOTE:

You can add an extension to the profile path even when you are using an environment variable to specify the name of a directory. For example, the path \\Ntserver\Users\%UserName%.man is a valid entry for this field.

Windows NT 3.5x Mandatory Profiles

User profiles for Windows NT 3.5x systems are not compatible with those for Windows NT 4.0, but both use the .man extension for mandatory profile directories. In a situation where an NT 3.5x profile already exists, you can add a 4.0 profile for the same account by adding a .pdm extension to the profile directory name instead of .man. Then, when a user logs on to the network with an NT 4.0 system, the workstation will recognize that the .man directory contains an improper profile and will search for a .pdm directory instead. There is no need to modify the profile path in User Manager for Domains to reflect the .pdm directory name. Users can also log on from a 3.5x workstation and access the older profile in the .man directory as they always have.