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.

System Policies
What if you want to control certain aspects of a user environment without imposing a mandatory profile? What if you want to prevent changes to items such as screen resolution but allow changes to backgrounds and wallpaper? And what about keeping users out of areas like Control Panel? The answer is system policies, which give you a varied degree of control over the user environment. And policies let you control machine-specific settings. Profiles consist of several folders and an ntuser.dat file. The ntuser.dat file is the user's portion of the Registry and is loaded at logon. Policies modify the Registry and are applied after a user's profile is loaded. Consequently, policies overlay the user's portion of the Registry when you use them with a profile. In other words, a policy that changes a user's wallpaper takes precedence over the user's wallpaper settings in a roaming or mandatory profile.

You create policies with NT's System Policy Editor. (For details about System Policy Editor, see "Related Articles in Windows NT Magazine.") You can apply different policies based on the individual user, the user's group membership, or the computer from which the user logs on. You save all the policy settings in one file named ntconfig.pol and place the file in the NetLogon share of all domain controllers (or in the export directory on an export server when you're using directory replication).

Policies are great for limiting changes users can make and for implementing rudimentary security. To create a policy, first invoke the System Policy Editor and select New Policy from the File menu. The policy starts with two icons: Default Computer and Default User. You can add groups, individual users, and machines as needed. When you double-click Default User or Default Computer, NT presents you with a hierarchy of policies related to the user or machine.

You can take two approaches to implementing policies. You can implement restrictive policies for the defaults and reverse the restrictions by virtue of group membership, or you can be less restrictive with the defaults and more restrictive with groups. From a security perspective, you need to be most restrictive with the defaults such that if no group policy exists for users, the functionality they can access is severely limited. This approach reinforces the idea that with group membership comes additional privileges. In all cases, you must track the policies you implement and add a Domain Admins group policy that reverses all the restrictions you implement. The Domain Admins group policy lets you avoid any restrictions you have established when you log on as a domain admin.

In addition to the flexibility of adding individual users, groups, and machines, you can also load policy templates. Policy templates contain additional policies, and you can customize them. In fact, you can write policy templates to accomplish almost any Registry changes you want to make.

Because most systems administrators want to prevent users from changing a system's configuration, we recommend investigating the Control Panel and Shell policies. Disabling Registry editing tools is a must for anyone using policies. To disable Registry editing tools for the default user, double-click Default User, expand System, expand Restrictions, and check the box for Disable Registry editing tools. Of course, you want to make these tools available to your domain administrators. Thus, you need to add the Domain Admins group and reverse the policy by clearing the same check box for the Domain Admins group.

Windows 95 Policies
In addition to policies for NT clients, you can establish policies for Win95 clients. To create a policy for Win95 clients, use the Win95 System Policy Editor. Or you can use the NT System Policy Editor and load the windows.adm template. You'll find the Win95 System Policy Editor on the Win95 CD-ROM in Admin\Apptools\Poledit. To install the System Policy Editor, go to Control Panel, Add/Remove Programs, Windows Setup, Have Disk. Enter Admin\Apptools\Poledit for the path, and choose OK. When prompted, install both the System Policy Editor and Group Policies. After configuring your Win95 policy, save the completed policy file as config.pol and place it in the NetLogon share on all domain controllers (either manually or via directory replication). By default, Win95 will process the config.pol file; however, for Win95 to apply group policies, you must install Group Policies (as above) on each Win95 machine. With regard to group policies, a Win95 machine attempts to query only the Primary Domain Controller (PDC) for group information even though a Backup Domain Controller (BDC) might have validated the logon. This problem can lead to users getting the default user policy if your PDC is down. Microsoft has acknowledged this problem; for information, see Microsoft Knowledge Base article Q150687 on the Web at http://www.microsoft.com/kb/articles/q150/6/87.htm.

Logon Scripts
A logon script is a small program that executes automatically when a user logs on. Logon scripts let an administrator set the client machine's time, map drive letters to network resources, redirect printing to shared network printers, and clean up temp space. With profiles and tools such as the System Policy Editor, some features of logon scripts are a moot point. Let's discuss logon scripts and show additional, often overlooked features.

NT Server lets you use logon scripts without third-party tools. You define a logon script for a user through a GUI-based tool, User Manager for Domains. With User Manager for Domains, you can create user accounts and assign logon scripts at account creation. In Screen 2, the Logon Script Name: field appears when you select the profile button under a user's property sheet. Now that you've assigned a script to the user, you need to write the script.

If you are a bit of a programmer at heart or are good with batch files, you will have no problem writing a logon script for NT. However, batch file logon scripts are fairly limited. The most common use for a logon script is mapping drive letters. Mapping drive letters to remote resources is often done with NET commands in batch files. (For more on NET commands, see Michael D. Reilly, "NET Commands," November 1997.) The following batch file maps drive letters to network resources:

net use h: \\Server\%username%

net use p: \\Server\Public

This sample batch file is useful, but it is slow to execute and limited in functionality. Instead of batch files, you can write your own executable. A custom executable used as a logon script is limited only by the author's imagination. Anything is possible with the right API call. But few network administrators have the time to write custom programs for use as their company's logon script.

Fortunately, a better method exists: KiXtart. KiXtart is a freeware scripting language designed and developed by Ruud van Velsen of Microsoft Benelux. Much like batch files, KiXtart scripts are easy to write. Unlike batch files, KiXtart scripts provide much of the power possible with custom executables. Have you ever wanted to install a printer on a client workstation when a user logged on? Have you ever wanted to make Registry changes at user logon? Try doing so with batch files. With KiXtart, you merely use a command in the script. Another advantage KiXtart offers is the capability of using one logon script for the entire organization. KiXtart has built-in macros that let the script interpret user information and group membership. The following code shows how KiXtart can map a drive based on group membership:

if ingroup("accounting")

use q: \\<accounting file server>\payroll

endif

KiXtart has too many commands to describe in this article. See the sidebar, "KiXtart Logon Scripts," for a sample KiXtart script and information on where to obtain the software.

Putting the Pieces Together
Now that we have discussed profiles, policies, and logon scripts, let's discuss how to use all these tools together. You might have several reasons for controlling a user's environment. The two primary reasons are to lower support costs and to implement security. You can lower support costs through the introduction of a standard desktop configuration. You can establish such a configuration with mandatory profiles or system policies. If you use system policies, you can introduce restrictions to the Shell and Control Panel. You can also use system policies to make up for the lack of security in Win95. For example, NT security disallows modification to important parts of the Registry by Domain Users, but Win95 clients can easily modify their Registry settings. To avoid such problems with Win95 clients, you can introduce a policy to disable Registry editing tools for Domain Users. Other Win95 security related policies include Minimum Password Length, Alphanumeric Passwords, Disable Password Caching, and Disable File and Print Sharing.

If you don't mind users customizing their desktops and menus, use roaming profiles. Compared with mandatory profiles, roaming profiles are easier to implement. To establish a roaming profile, you simply share a directory to hold profiles and set the User Profile Path for a user's account. When the user logs off the system, the profile is uploaded to the share on the server. In contrast, mandatory profiles require several steps, including creating and configuring a temporary account.

So where does the network default profile fit into all this? If all your profiles are mandatory, it does not. However, if you use roaming (or local) profiles, you can implement the network default profile to create an initial desktop.

In all cases, you will most likely need to use logon scripts to map network drives. You need drive mappings to establish connections to home directories and departmental file servers. In an enterprise organization, you typically need to map drives for each user, based on department. In other words, users in the accounting department need drives mapped to the accounting file server, and users in the engineering department need drives mapped to the engineering file server. The limited power of NET commands forces most organizations to maintain numerous batch files in their NetLogon shares. However, a KiXtart script that properly interprets group information and maps drives to the appropriate departmental file server can eliminate this clutter of batch files.

Applying the Knowledge
To better understand how profiles, policies, and logon scripts work together, let's look at a company that must implement all of them. For this example, we use one KiXtart logon script for all users. The script synchronizes the workstation's time with a server and maps network drives. All users will have drive H: mapped to their home directory on Server1 and will receive other mappings depending on their group membership. We've created two policies: one for Win95 machines and one for NT machines. Both restrict user access to Registry editing tools. We use simple policies for illustrative purposes. Your policies are likely to be more complex. Also, we establish a Network Default User profile that has a shortcut to our company intranet on the desktop.

Now, let's examine the impact on a few users in our network. Suppose we have just created an account for Nancy, an NT user. We've assigned her a roaming profile so she can customize her desktop. When Nancy logs on the first time, she'll get an initial profile based on the Default User profile. At logoff, Nancy's profile is saved to \\Server1\NTProfiles$\Nancy. Nancy now has a roaming profile and will receive the same desktop settings regardless of which NT machine she uses. Because our policy restricts user access to Registry editing tools, Nancy can never edit the Registry.

Rick, another NT user on our network, is a long-term contractor in our engineering department. The administrator has assigned a shared mandatory profile to all users in the engineering department. When Rick logs on, he can make changes to his desktop. However, he cannot use the Registry editor. At logoff, Rick's changes are not uploaded to the server. Consequently, Rick can log on to any machine and will always receive the standardized desktop the administrator has defined.

In our fictitious company, we have not upgraded all our machines to NT. We took the remaining Win95 machines and designated them for temporary employees. The administrator has decided that a standardized desktop is best for the temporary employees. Sue, a Win95 programmer, is one of 50 temporary employees for whom the administrator has defined a mandatory profile. Because a Win95 mandatory profile must be in each user's home directory, a group cannot share it.

If you have many Win95 machines on your network, you will probably implement policies to compensate for the lack of security in Win95. For example, suppose users decide to change their IP address. On an NT machine, a user cannot change the network configuration. However, without policies, a Win95 user can easily make such changes. Take Flynn, another Win95 user. One afternoon, Flynn loses connectivity with an important network server. Lacking an understanding of TCP/IP, Flynn decides to copy his neighbor's IP address in an attempt to remedy the problem. But duplicate IP addresses cause problems. If you use the policy setting to restrict access to the Control Panel Network applet, this situation will never occur.

We've shown you the basics of setting up profiles, policies, and logon scripts. You can eliminate many systems administration problems with these tools and achieve nearly any degree of control over the client environment.