August 1999

Making Profiles and Policies Work for You

Total Cost of Ownership (TCO), that dratted reality that computers cost a whole lot more than just their initial purchase price, is a major concern for most companies. Optimizing and controlling system configurations can reduce costs and improve efficiencies. Your best weapons for this task are System Policies and User Profiles. According to Microsoft, a major part of TCO is, "lost productivity at the desktop caused by user error, such as changing the system configuration and rendering the computer unworkable, or system distractions and complexities, for example, too many features or nonessential applications installed on the desktop."

Microsoft's solution is the Zero Administration Kit (ZAK). ZAK may sound like something you'd buy, yet it's "a set of methodologies for deploying Windows [computers]." The two primary components of ZAK are system policies and user profiles.

System policies

System policies are sets of Registry settings that together control which resources are available to a user or group of users. You create policies with the System Policy Editor (Poledit), as shown in Figure A.

Figure A: You use the System Policy Editor to create policies.

By checking, clearing, or leaving the options presented by Poledit grayed out, you configure a Registry template that can be applied to users, groups, and computers.

You can think of a policy as a filter, through which you pour the Registry. Entries in the policy selectively modify the Registry. The end result is that the user's Registry takes on the new settings that you've specified. Unless you undo those settings with a change to the policy or by manually editing the Registry, the settings remain in effect.

User profiles

A User profile is the automatically saved system configuration for a user, which includes environment and preference settings, installed applications, desktop icons and their arrangement, color options, and policy settings. For example, the user's selection of a wallpaper or color scheme is stored in his profile. By default, profiles are automatically created and saved locally. However, you can configure profiles to follow the user as they log on at different computers on the network. Such profiles are called roaming user profiles. Roaming user profiles are stored on a network computer in a location that's always available to the user. When the user logs on, his profile is retrieved from the network and cached locally. Changes to the environment update both the local cached copy and the network copy.

You can configure mandatory settings, configurations that users can't change, through mandatory user profiles. This type of profile is simply a modified roaming user profile.

Which should you use?

Profiles and policies sound like they let you accomplish similar goals--they do. So, when should you use policies and when should you use profiles? In general, you should think of a policy as an administrative and security tool whereas profiles are user environment management tools. Sure, you can set the wallpaper a user will see with a policy. But, policies shine for tasks like customizing the Start menu, preventing users from running certain programs, or preventing access to certain types of system configuration tasks. Policies are great for reining in configuraholics, thereby reducing system administration costs.

configuraholic (kn fig' yr hl' c) n. 1. A person who can't stop twiddling with system settings until his computer no longer works and who then must be rescued by the system administration staff.

Profiles, on the other hand, are great for customizing users' environments. Want to make a particular program always available as an icon on the user's desktop no matter which computer he logs on to? Use a roaming user profile. Want to set a corporate color scheme, complete with custom company-logo wallpaper? Use a mandatory user profile. To determine which will best suit your needs, consult the Windows NT 4.0 Concepts and Planning Guide and Microsoft's Policies and Profiles white paper mentioned at the end of this article.

Implementing policies

Policies are stored in a file called ntconfig.pol (for Windows NT systems) or config.pol (for Windows 9x systems). You create just one policy file per platform (NT or 9x), not one per user. Inside this single policy file, you can configure settings for multiple users, groups, or computers. You must run Poledit on the platform for which you want to build a system policy. Policies created on Windows NT systems can be used only on Windows NT systems; those created on Windows 9x systems are suitable only for other 9x systems.

Looking back at Figure A, three options are being configured with Poledit. Do Not Display Last Logged On User Name is selected, meaning that this setting will be implemented. Enable Shutdown From Authentication Dialog Box is cleared, or not selected, meaning that this setting will be turned off. Logon Banner is grayed out, leaving the user's Registry configured as it was before the policy gets applied.

It's a bit complicated, but important to understand if you're going to implement policies correctly. As the diagram shows, if a user-specific policy exists, group policies are skipped. What might not be clear from the diagram is that the Administrator and administrative level users aren't exempt from policies. You might want to create a user-specific or Administrators group policy object to override restrictive settings that are configured elsewhere.

You can prioritize group policies, using Poledit, so that the highest priority policies get applied last (and override lower-priority policy settings). Make sure to give highest priority to administrative-level groups or you might find your environment unintentionally restricted.

Once you've configured the policy, you need to distribute it across the network. Put the resulting configuration file in the %systemroot%\system32\repl\export\scripts directory on your PDC and configure the NT file replication service to replicate the file to all of the BDCs in your domain. Only those policies from a user's home domain (where their account exists) get applied. If you need to use different policies for a user for different domains, they'll need multiple user accounts--configuring trusts won't take care of the situation.

Configuring a client computer to get policies from a domain controller

When users log on, their computers download the policy from the BDC that validates them and cache the policy in the \%systemroot\Profiles\Policy folder. You can configure a client computer to get its policies from a particular domain controller. This manual setting is designed to let you load balance and deal with WAN congestion caused by downloading policies. Computers running Windows NT with Service Pack 3 or newer and those running Windows 95 OSR2 and newer support this manual policy configuration.

You can configure this manual setting either through a policy or by editing the Registry. If your users are already getting policies set and you just want to change where they're getting them from, configure the manual settings with Poledit. Configure either a specific machine policy or the Default Computer policy. In the Network, System Policies Update category, check the Remote Update box. Select Manual and enter a UNC path and filename that point to the policy file.

If you're applying a policy for the first time and want to make sure users get their policies from a particular domain controller, you'll have to edit the Registry. On Windows 9x computers, use the Registry Editor to access the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update key. Change the value there to 2 (for manual mode; 0 is disabled and 1 is for automatic mode where the computer gets the policy from the validating BDC).

In the same key, modify the NetworkPath value (REG_SZ) with the local or UNC path to where the policy file is stored. For Windows NT computers, the Registry path is almost the same. Access the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update key and change the UpdateMode value to 2. Again, in the same key, modify the NetworkPath value (REG_SZ) with the local or UNC path. You could use this same technique to force a non-domain member computer to download and apply a policy.

Implementing profiles

Profiles are made up of a series of folders, in which shortcuts and icons are stored, and a file, in which selected Registry settings are stored. On Windows NT systems, this file is ntuser.dat and on Windows 9x systems the file is user.dat. The user profile folders and configuration file are stored inside the profile folder in C:\WINNT or C:\WINDOWS. To create a roaming user profile, you must put the profile folders and the configuration file in a network share that's always accessible to users. You could put copies of the Default User and All Users profiles in that location as well. Users will need at least Change permissions unless you're using mandatory profiles. In that case, the Read permission will be sufficient. Using the User Environment Profile dialog box, configure the user account to point to the profile path, as shown in
Figure B.

Figure B: Configure user accounts to use profiles with User Manager For Domains.

You might find it convenient to store the profile in the user's home directory. But, make sure to put profiles in a sub-folder. When users log on, their profile will be cached (copied) locally. If other files and folders are stored in the same location as the profile, they too will be copied to the user's workstation. Then, when the user logs off, all of those files and the profile will be copied back to the network. From a performance standpoint, this would certainly not be desirable. To avoid this problem, simply put profiles into a folder of their own within the user's home directory.

Administrators often use the %USERNAME% replaceable variable when specifying the home directory path. However, that parameter must represent the last folder in the path. You couldn't use it with a path like \\corpserver\users\%USERNAME%\profile. Remember, if you put all of the user profiles on one server, it will be burdened with serving up all of the profiles when users log on. Make sure the profiles server has sufficient resources to handle the morning log on rush hour.

Another strategy you could use is to store profiles on your domain controllers and configure users to get their profiles from the server that validates their logon. To do this, put the profiles in a subfolder of the %systemroot%\system32\repl\export\scripts directory on your PDC. NT's file replication service will replicate the folder to all of the BDCs in your domain. For example, you could create a folder called profiles inside of which you create one folder per user. Then, in User Manager For Domains, configure users to get their profiles from %LOGONSERVER%\NETLOGON\profiles\%USERNAME%. Don't include a preceding double backslash (\\) before the %LOGONSERVER% parameter and it will get replaced by the name of the server that validates the user's logon. Since %USERNAME% is the last parameter, it will be replaced with the user's name. With this configuration, the workload of distributing profiles is distributed across all your BDCs.

Finally, while you can make manual configuration changes to roaming profiles, be mindful of how Windows checks for the most up-to-date profile. Windows checks the file modification time stamp on the Ntconfig (or config) file only. It doesn't check the time stamps on the other folders and files of a profile. So, if you manually add a shortcut or link to one of the subfolders, you will need to modify the time stamp on the configuration file using a file maintenance utility (for example, the touch.exe POSIX command included with the Windows NT Resource Kit).

Conclusion

Standardizing and controlling user environments with policies and profiles can help you reduce TCO. These technologies are more complex than can be covered fully in the space available here. To get maximum benefit of these tools, you should read the Windows NT 4.0 Concepts and Planning Guide that comes with Windows NT and check out Microsoft's white paper on Policies and Profiles at www.microsoft.com/ntworkstation/technical/DeploymentDocs/ProfPol.asp.

Copyright © 1999, ZD Inc. All rights reserved. ZD Journals and the ZD Journals logo are trademarks of ZD Inc. Reproduction in whole or in part in any form or medium without express written permission of ZD Inc. is prohibited. All other product names and logos are trademarks or registered trademarks of their respective owners.