Profiles, Policies, and Logon Scripts

Some of the most puzzling aspects of Windows NT are user profiles, policies, and logon scripts. Each tool helps you control a user's desktop environment. Profiles provide an easy mechanism for changing NT 4.0's user interface, including attributes such as wallpaper and shortcuts to common applications. System policies are new to NT 4.0. They provide for detailed user-environment controls, such as locking users out of the Control Panel, and let you download Registry changes on client logon. A logon script is a file that you assign to a user account and that runs automatically when a user logs on. With a logon script, you can map drive letters to network resources, for example.

Given the flexibility of each tool, the true challenge is developing a strategy for effectively using these tools on your network. You need to know what to do after you learn how to create policies, profiles, or logon scripts. Let's examine the functionality each tool offers and see how to deploy them effectively. We will explore each tool's advantages and present some guidelines for their use. We also cover the interoperability issues for those with NT Workstation and Windows 95 clients. (For specifics on creating policies and implementing roaming profiles, see "Related Articles in Windows NT Magazine," page 158.)

Profiles
Profiles contain all user-defined settings for the user environment, including start menu entries, desktop icons, display settings, and background colors. NT places these settings on the local machine, or you can put them on a network server. (Drew Heywood's September article describes user profile contents and implementation.) User profiles come in four flavors: local, roaming, mandatory, and network default. The difference among the four types arises from their storage location and the amount of control they let you relinquish to the user. By default, the local machine stores local profiles in the %Systemroot%\Profiles folder. You locate both roaming and mandatory profiles on a network server available to client workstations in the domain. You store the network default profile in the NetLogon share (%systemroot%\system32\repl\import\scripts) on each domain controller.

Local Profiles
Alone, local profiles have limited functionality. Because they are local, they lack the flexibility to let users maintain the same profile when logging on to different workstations in the domain. In addition, a hard disk crash or machine failure will destroy a local profile, and you'll have to reconfigure the desktop settings. And what happens if you upgrade user machines? Ideally, the users will have stored all their work on a server. However, their local profile disappears with the old machine. The user must re-create the old environment from scratch if your network does not use server-based profiles. For these reasons, you might want to use profiles stored on a network server.

Roaming and Mandatory Profiles
You can store two types of profiles on a network server: roaming profiles and mandatory profiles. Roaming profiles give users complete control over their desktop environment. In contrast, mandatory profiles impose the same user environment each time a user logs on. Although users with mandatory profiles can make changes during their session, they cannot save those changes to the profile on the network server. Mandatory profiles can easily prevent nuisance calls to the Help desk from users who have deleted a desktop or menu item. To recover from such problems, users with mandatory profiles can simply log off and on again. The logon imposes the mandatory environment and restores any desktop icons or menu items the user inadvertently deleted. Because mandatory profiles are never updated at logoff, a group of users can share them. Although mandatory profiles sound great for controlling desktop environments, you may want to consider policies (as discussed later) instead because Microsoft does not plan to support mandatory profiles in NT 5.0.

Let's consider some issues involved in placing profiles on a network server. Because the profiles are on a server, they must be downloaded when a user logs on. You cannot locate a profile server across a slow WAN link and expect a quick logon. The storage space required for user profiles is another consideration. A typical profile consumes about 250KB of space and can grow to 600KB or more. We recommend basing your storage requirements on about 500KB per user. But what happens when users download a 4MB file and save it to their desktop? Because the desktop items are part of a profile's composition, this 4MB file becomes part of the user's profile. Thus, you need to discourage users from saving files, especially large ones, to their desktop.

When you configure the profile server, you can create a Profiles folder to hold a subfolder for each user's profile, as Figure 1 shows. Rather than sharing each subfolder, you can create one share for the Profiles folder and use a sharename of Profiles$. The $ hides the share from the browse list. You don't need to advertise the share because only the system and, occasionally, administrators use it. With regard to security, when NT creates new profiles beneath the Profiles folder, it grants Full Control to the individual user, Administrators group, and System. This configuration prevents one user from modifying the profile of another but lets administrators make changes.

One advantage of having all the user profiles on a central server is the ease with which an administrator can change a user's environment. Suppose you want to add a new Start menu item to Mary's roaming profile. You connect to the Profiles$ share and place a new shortcut in the Start Menu folder within Mary's profile. However, you must use the touch utility in the Microsoft Windows NT Resource Kit to update the time on the ntuser.dat portion of the user's profile. This step is necessary because two copies of the user profile are maintained: one at Mary's workstation and one on Server1. When Mary logs on, her workstation downloads her profile from the network server and caches it locally under the %Systemroot%\Profiles folder. On logoff, the cached copy is uploaded to Server1. The locally cached copy provides the user profile if Server1 is unavailable. On logon, N checks the timestamp of ntuser.dat on the local and remote profile. It will use the copy on Server1 only if the timestamp of the ntuser.dat stored there is more recent than the timestamp on the local copy. If you change the server copy without updating the timestamp on ntuser.dat, the system will use the local copy and will overwrite the server copy when the user logs off, voiding your changes to the copy on the server. To complete the modification of Mary's profile, execute the following command:

touch ntuser.dat

Also note that you must make changes when the user is not logged on. Otherwise, when the user logs off, the profile for the session will be uploaded to the server and overwrite your changes.

Suppose a new person joins your accounting department. Wouldn't you like to have a standard accounting department user profile that you can give to the new user? Suppose you have a server containing user profiles as in Figure 1 and want to create a mandatory profile to give to a new user, David Jones, in the accounting department.

To create the standard profile to give David, you must first create a new user. Refer to it as TempAcct. Then, log on as TempAcct. The system will distribute the profile for this account as a mandatory profile to everyone in the accounting department, so configure the desktop and user environment as you want it to appear to your accounting users. Set up this configuration from a workstation in the accounting department because many of the menu items and desktop icons will point to locally installed accounting applications. When you've configured the environment, log off and log on to an account with administrative privileges.

Before David can use this profile, he needs a new account with a profile assigned to it. Open User Manager for Domains and create a new user. On the new user property sheet, click the Profile button. Now set the user profile path to \\Server1\Profiles$\DavidJ. Please note that a DavidJ folder does not exist at this point.

Now, you must copy the profile for TempAcct to David's user profile path. Open the Control Panel, and double-click System. Choose the User Profiles tab. Select the profile for TempAcct, and click Copy To, as Screen 1 shows. In the Copy profile to dialog box, enter the universal naming convention (UNC) path \\Server\Profiles$\DavidJ. Click the Change button under Permitted to use and select David's new account. This complete operation creates the DavidJ folder and assigns permissions such that Administrators, System, and DavidJ have Full Control. The operation also sets the security of the Registry keys the profile uses. If you fail to change the Permitted to use portion, a DavidJ folder will be created, but the permissions will retain their file and Registry security settings for TempAcct.

Last, you must make the profile mandatory. Open Explorer, and drill down to \\Server1\Profiles$\DavidJ. Rename the ntuser.dat file for David to ntuser.man. You must also set NTFS permissions on the DavidJ folder such that David has Read only access. This action prevents David from changing ntuser.man to ntuser.dat.

The Network Default Profile
NT uses the network default profile for first-time logons to the domain and creates the user environment for a new account based on the Default User and All Users folders on the client machine. However, if a network default profile exists, NT will use it (rather than the local Default User) to construct the profile for the new account.

To implement a network default profile, you need a profile named Default User in the NetLogon share (%systemroot%\system32\repl\import\scripts) on all domain controllers. To facilitate distribution of the network default user profile, establish directory replication among your domain controllers. All clients use this profile for their first logon, which is useful for an enhanced initial desktop configuration. Such enhancements can include shortcuts to common applications and custom wallpaper (with company logo, of course). You can place universal resource locators (URLs) for the corporate intranet and Help desk site in the Favorites folder of the network default user profile. This step seeds users' Internet Explorer (IE) Favorites list with chosen URLs.

As you might expect, you must follow several steps to create a network default profile. Be careful and do the steps in the proper order.

First, create a new account, which we'll refer to as Net-Default. Log on to this account, and configure the environment that you want to distribute to first-time logons. Now log off.

Next, you must instruct NT to use the Net-Default profile for the network default profile. Log on as a user with administrative access. Open Control Panel and double-click System. Choose the User Profiles tab to invoke the User Profiles property sheet. Select the profile for Net-Default, and click Copy To. In the Copy profile to dialog box, fill in the path for the export directory on the export server. Click the Change button under Permitted to use and select Everyone. Now select OK to commit the copy. You have now successfully created a network default profile. Log on to a new account to test the profile.

Windows 95 Profiles
Similar to NT clients, Win95 machines can use server-based profiles. But rather than storing a Win95 user's profile in a specific location, you store Win95 profiles in each user's home directory. This setup garbles the home directory with a bunch of folders that are unrecognizable to the user. To avoid confusion, map a separate drive for use as a home directory and leave the actual home directory for profile storage only. Note that Win95 and NT profiles are separate, and people who use both Win95 and NT will have two different profiles to configure.

You must follow several steps to establish profiles for Win95 users. First, enable User Profiles on the Win95 computer. Open Control Panel and click the Passwords icon. Select the User Profiles tab, and choose Users Can Customize Their Preferences And Desktop Settings. For this step to take effect, you must restart the machine. If you've created and shared a folder to store Win95 home directories, invoke User Manager for Domains and identify the home directory path for the Win95 user account. You can use something like \\Server1<Home>\<%username%>, where Home is a shared folder on Server1. NT will create a subfolder with the same name as the user account (it reads the %username% variable and names the directory according to the account name). NT not only creates the subfolder but also sets the security permissions, yielding Full Control to the user account. If you want to access the folder to modify the user's profile, you must change the permissions on the folder to also grant administrators full control. Such permissions prevent users from tampering with other users' profiles but let administrators access user profiles and make changes if needed.