Profiles, Policies, and Logon Scripts

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.