Profiles, Policies, and Logon Scripts

Use these tools to define the user environment

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 anetwork server. (Drew Heywood's September article describes user profilecontents and implementation.) User profiles come in four flavors: local,roaming, mandatory, and network default. The difference among the four typesarises from their storage location and the amount of control they let yourelinquish to the user. By default, the local machine stores local profiles inthe %Systemroot%Profiles folder. You locate both roaming and mandatoryprofiles on a network server available to client workstations in the domain. Youstore the network default profile in the NetLogon share(%systemroot%system32replimportscripts) on each domain controller.

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

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

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

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

One advantage of having all the user profiles on a central server is theease with which an administrator can change a user's environment. Suppose youwant to add a new Start menu item to Mary's roaming profile. You connect to theProfiles$ share and place a new shortcut in the Start Menu folder within Mary'sprofile. However, you must use the touch utility in the MicrosoftWindows NT Resource Kit to update the time on the ntuser.dat portion of theuser's profile. This step is necessary because two copies of the user profileare 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 itlocally under the %Systemroot%Profiles folder. On logoff, the cached copyis uploaded to Server1. The locally cached copy provides the user profile ifServer1 is unavailable. On logon, N checks the timestamp of ntuser.dat on thelocal and remote profile. It will use the copy on Server1 only if the timestampof the ntuser.dat stored there is more recent than the timestamp on the localcopy. If you change the server copy without updating the timestamp onntuser.dat, the system will use the local copy and will overwrite the servercopy when the user logs off, voiding your changes to the copy on the server. Tocomplete the modification of Mary's profile, execute the following command:

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 uploadedto the server and overwrite your changes.

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

To create the standard profile to give David, you must first create a newuser. Refer to it as TempAcct. Then, log on as TempAcct. The system willdistribute the profile for this account as a mandatory profile to everyone inthe accounting department, so configure the desktop and user environmentas you want it to appear to your accounting users. Set up this configurationfrom a workstation in the accounting department because many of the menu itemsand desktop icons will point to locally installed accounting applications. Whenyou've configured the environment, log off and log on to an account withadministrative privileges.

Before David can use this profile, he needs a new account with a profileassigned to it. Open User Manager for Domains and create a new user. On the newuser property sheet, click the Profile button. Now set the user profile path to\Server1Profiles$DavidJ. Please note that a DavidJ folder does not exist atthis 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 theCopy profile to dialog box, enter the universal naming convention (UNC)path \ServerProfiles$DavidJ. Click the Change button under Permitted touse and select David's new account. This complete operation creates theDavidJ folder and assigns permissions such that Administrators, System, andDavidJ have Full Control. The operation also sets the security of the Registrykeys the profile uses. If you fail to change the Permitted to useportion, a DavidJ folder will be created, but the permissions will retain theirfile and Registry security settings for TempAcct.

Last, you must make the profile mandatory. Open Explorer, and drill down to\Server1Profiles$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 Readonly access. This action prevents David from changing ntuser.man tontuser.dat.

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

To implement a network default profile, you need a profile named DefaultUser in the NetLogon share (%systemroot%system32replimportscripts) onall domain controllers. To facilitate distribution of the network default userprofile, establish directory replication among your domain controllers. Allclients use this profile for their first logon, which is useful for an enhancedinitial desktop configuration. Such enhancements can include shortcuts to commonapplications and custom wallpaper (with company logo, of course). You can placeuniversal resource locators (URLs) for the corporate intranet and Help desk sitein the Favorites folder of the network default user profile. This step seedsusers' Internet Explorer (IE) Favorites list with chosen URLs.

As you might expect, you must follow several steps to create a networkdefault 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 tothis account, and configure the environment that you want to distribute tofirst-time logons. Now log off.

Next, you must instruct NT to use the Net-Default profile for the networkdefault profile. Log on as a user with administrative access. Open Control Paneland double-click System. Choose the User Profiles tab to invoke the UserProfiles 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 exportdirectory on the export server. Click the Change button under Permitted touse and select Everyone. Now select OK to commit the copy. You have nowsuccessfully created a network default profile. Log on to a new account to testthe profile.

Windows 95 Profiles
Similar to NT clients, Win95 machinescan use server-based profiles. But rather than storing a Win95 user's profile ina specific location, you store Win95 profiles in each user's home directory.This setup garbles the home directory with a bunch of folders that areunrecognizable to the user. To avoid confusion, map a separate drive for use asa 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 andNT 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 thePasswords icon. Select the User Profiles tab, and choose Users Can CustomizeTheir Preferences And Desktop Settings. For this step to take effect, youmust restart the machine. If you've created and shared a folder to store Win95home directories, invoke User Manager for Domains and identify the homedirectory path for the Win95 user account. You can use something like \Server1<%username%>, where Home is a shared folder on Server1. NTwill create a subfolder with the same name as the user account (it reads the%username% variable and names the directory according to the accountname). 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 tomodify the user's profile, you must change the permissions on the folder to alsogrant administrators full control. Such permissions prevent users from tamperingwith other users' profiles but let administrators access user profiles and makechanges if needed.

System Policies
What if you want to control certain aspects of a user environment withoutimposing a mandatory profile? What if you want to prevent changes to items suchas screen resolution but allow changes to backgrounds and wallpaper? And whatabout keeping users out of areas like Control Panel? The answer is systempolicies, which give you a varied degree of control over the user environment.And policies let you control machine-specific settings. Profiles consist ofseveral folders and an ntuser.dat file. The ntuser.dat file is the user'sportion of the Registry and is loaded at logon. Policies modify the Registry andare applied after a user's profile is loaded. Consequently, policies overlay theuser'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'swallpaper settings in a roaming or mandatory profile.

You create policies with NT's System Policy Editor. (For details aboutSystem Policy Editor, see "Related Articles in Windows NT Magazine.")You can apply different policies based on the individual user, the user's groupmembership, or the computer from which the user logs on. You save all the policysettings in one file named ntconfig.pol and place the file in the NetLogon shareof all domain controllers (or in the export directory on an export server whenyou're using directory replication).

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

You can take two approaches to implementing policies. You can implementrestrictive policies for the defaults and reverse the restrictions by virtue ofgroup membership, or you can be less restrictive with the defaults and morerestrictive with groups. From a security perspective, you need to be mostrestrictive with the defaults such that if no group policy exists for users, thefunctionality they can access is severely limited. This approach reinforces theidea that with group membership comes additional privileges. In all cases, youmust track the policies you implement and add a Domain Admins group policy thatreverses all the restrictions you implement. The Domain Admins group policy letsyou avoid any restrictions you have established when you log on as a domainadmin.

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

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

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

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

NT Server lets you use logon scripts without third-party tools. You definea 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 logonscripts at account creation. In Screen 2, the Logon Script Name: field appearswhen you select the profile button under a user's property sheet. Now thatyou'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, youwill have no problem writing a logon script for NT. However, batch file logonscripts are fairly limited. The most common use for a logon script is mappingdrive letters. Mapping drive letters to remote resources is often done with NETcommands in batch files. (For more on NET commands, see Michael D. Reilly, "NETCommands," November 1997.) The following batch file maps drive letters tonetwork resources:

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

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

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

Putting the Pieces Together
Now that we have discussed profiles, policies, and logon scripts, let'sdiscuss how to use all these tools together. You might have several reasons forcontrolling a user's environment. The two primary reasons are to lower supportcosts and to implement security. You can lower support costs through theintroduction of a standard desktop configuration. You can establish such aconfiguration with mandatory profiles or system policies. If you use systempolicies, you can introduce restrictions to the Shell and Control Panel. You canalso use system policies to make up for the lack of security in Win95. Forexample, NT security disallows modification to important parts of the Registryby Domain Users, but Win95 clients can easily modify their Registry settings. Toavoid such problems with Win95 clients, you can introduce a policy to disableRegistry editing tools for Domain Users. Other Win95 security related policiesinclude Minimum Password Length, Alphanumeric Passwords, Disable PasswordCaching, and Disable File and Print Sharing.

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

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

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

Applying the Knowledge
To better understand how profiles, policies, and logon scripts worktogether, let's look at a company that must implement all of them. For thisexample, we use one KiXtart logon script for all users. The script synchronizesthe workstation's time with a server and maps network drives. All users willhave drive H: mapped to their home directory on Server1 and will receive othermappings depending on their group membership. We've created two policies: onefor Win95 machines and one for NT machines. Both restrict user access toRegistry editing tools. We use simple policies for illustrative purposes. Yourpolicies are likely to be more complex. Also, we establish a Network DefaultUser 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 wehave just created an account for Nancy, an NT user. We've assigned her a roamingprofile 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 \Server1NTProfiles$Nancy. Nancy now has aroaming profile and will receive the same desktop settings regardless of whichNT machine she uses. Because our policy restricts user access to Registryediting tools, Nancy can never edit the Registry.

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

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

If you have many Win95 machines on your network, you will probablyimplement 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 cannotchange the network configuration. However, without policies, a Win95 user caneasily make such changes. Take Flynn, another Win95 user. One afternoon, Flynnloses connectivity with an important network server. Lacking an understanding ofTCP/IP, Flynn decides to copy his neighbor's IP address in an attempt to remedythe problem. But duplicate IP addresses cause problems. If you use the policysetting to restrict access to the Control Panel Network applet, this situationwill never occur.

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