Search the Catalog
Windows 2000 Active Directory

Windows 2000 Active Directory

By Alistair G. Lowe-Norris
1st Edition January 2000
1-56592-638-2, Order Number: 6382
624 pages, $39.95

Chapter 8
Profiles and Group Policy Primer

Before getting to the meat of how to effectively structure your Active Directory to take Group Policy Objects into account, I need to give you a solid introduction to the subject of profiles and policies. It's a very large subject, and it's worth treating properly so that you get the most out of your system. This chapter is the introduction to the subject, and the next chapter builds on it to show how policies work in Active Directory and how to design a tree to incorporate them effectively.

The goal of policy-based administration is for the administrator to state a wish about the state of users/computer environment once, then rely on the system to enforce that wish. With Windows 2000 group policies, that state is nearly realized.

In Windows NT, system policies had a number of limitations. System policies:

That has really changed with Windows 2000 group policies. Group policies are the primary Windows 2000 mechanism for applying changes to computers and users throughout an organization. In contrast to system policies, group policies:

With group policies, an administrator can define a very large number of detailed settings that are to be enforced on users throughout the organization and be confident that the system will take care of things. Let's take a simple example from Leicester University. We administrators wanted workstation access to the Systems Administrator toolset, which normally is installed only on a server. While we could install these tools on our own PCs, we actually wanted the tools to follow us around the network and be available from any PC that we chose to log on from. However, we didn't want to leave these tools installed on that PC when we logged off and went away. Prior to Windows 2000, I would have had to arrive at that client, log on, install the toolset, do whatever was required at that client, uninstall the toolset, and finally log off again. This is a considerable chore for large numbers of machines. With Windows 2000, we were able to use group policies to specify that the toolset was to be automatically installed on any client that I logged on to before the desktop appeared. That way, I could go straight to the Start menu and use the tools I wanted. Then, when I went to log off, the same group policies would uninstall the toolset from the machine.

Let's take another example. At the university we use a central logon script for every user. This is no different than Windows NT. However, we also apply extra logon scripts for some sets of users based on which Organizational Unit they are in. So some of our users get more than one logon script depending on where in Active Directory their accounts reside. That's a significant step forward from Windows NT, but it doesn't end there. We also can specify logoff scripts that run when a user logs off the system. Similarly, we can have a central logoff script that applies to all users and a series of other logoff scripts tailored to users in certain parts of the tree. Workstations also can have scripts, but instead of executing at logon and logoff, these scripts run at startup and shutdown. Want to install a new Dynamic Link Library (DLL) on all clients? How about using a startup script to do it? Have a desire to start the (normally disabled) web service on a series of workstations for a conference that runs for a week? Why not create a startup script in Active Directory that starts those services? When the week is over, remove the script, and the workstations return to normal mode. Of course, as you've probably guessed, this startup script runs in addition to any other startup scripts such as a central one for all workstations. So, rather than a single user logon script available for Windows NT, we now have multiple user logon/logoff scripts and multiple workstation startup/shutdown scripts.

Let's take a final example. You are required to change a set of registry key values for every client in your organization so that the clients can all receive an organization-wide company video broadcast from the chairman and CEO. You set up a simple Group Policy with the customized registry changes configured and apply it to every computer in your organization. At present, this functionality may seem no different from what you could have achieved with Windows NT system policies. You apply these changes one evening, and the next morning, 20 thousand workstations across your network are rebooted so that they receive this policy on startup. The Group Policy applies and the settings are changed. However, about an hour later you realize that one of the values in the registry needs changing again. You don't want to force 20 thousand clients to reboot, and with Windows 2000 you don't have to. You can specify that this policy be reapplied every 15 minutes to all workstations after they have booted. So, you make the change to the group policies and sit back, knowing that within 15-45 minutes[1] every workstation will receive the policy again with the updated change.

With examples like these, it becomes quite easy to see the power of group policies. While some of the examples can be accomplished under Windows NT, they require a lot more time and effort to achieve than with Windows 2000's simple Configuration tool.

The rest of the chapter goes into detail about group policies.

TIP: Group policies are normally referred to simply as GPOs (pronounced Gee-Pee-Ohs), corresponding to the term Group Policy Objects, during normal discussions. This is the style I use for the remainder of the book.

A Profile Primer

The terms policies and profiles often are included together in documentation, yet they perform very different functions. Because they interrelate, it is easy to get confused about them. To make things clear, I'll cover the essentials of profiles so that you can understand how you can manipulate them using group policies.

Let's consider a Windows 2000 workstation with a newly created account for a user named Richard Lang with the username RLang. When Richard logs on to the client, the system creates a profile directory for him corresponding to his username Rlang in the Documents and Settings directory. If Richard were to log on to a Windows NT workstation or a Windows 2000 workstation that was upgraded from a previous version of Windows NT, the profile would be created under the %systemroot%\Profiles[2] directory.

Inside this directory, the Windows NT/2000 system places a file called NTUSER.DAT, along with various other data files. Let's concentrate on the NTUSER.DAT file for a moment. This file contains what is known generally as the user portion of the registry. You see, Windows 95, Windows 98, Windows NT, and Windows 2000 all have a registry that consists of two parts: the so-called user portion represented by the file NTUSER.DAT (or USER.DAT on Windows 9x systems) and the system or computer portion of the registry, known as SYSTEM.DAT.[3] The user part of the registry holds information indicating what screensaver should be used for that user; what colors, background, and event sounds are set; where the user's My Documents folder points to; and so on. The system portion of the registry holds hardware device settings, installed software information, and so on. When a user logs on to a client, the combined effects of the settings for the machine held in the system portion of the registry and the settings for the user held in the user portion of the registry take effect.

When you use a tool such as REGEDIT.EXE or REGEDT32.EXE to examine the registry on a machine, both portions of the registry are opened and displayed together for you to look at within one tool.

TIP: The two registry tools have been developed with different requirements in mind and consequently have different functionality. The REGEDIT tool was developed for Windows 9x clients, and as such allows for management of the datatypes of that registry format as well as for rapid searching for any key or value that contains a given word or phrase. REGEDT32, on the other hand, is designed to support the extra Windows NT/2000 datatypes that are required within those registries. REGEDIT cannot write out those types. However, REGEDT32 has an awful search mechanism that allows searches only through keys. So, while REGEDT32 is used on Windows NT/2000 for day-to-day management of the registry, a systems administrator also knows how to use REGEDIT on those operating systems due to its superior search capabilities. REGEDIT also has a few other benefits including the ability to export registry hives in a readable format.

Figure 8-1 shows a view of the registry on a Windows 2000 client when viewed from REGEDIT. The screen shot also shows the five registry hives (as they are known) available to Windows 2000. The two important hives are HKEY_LOCAL_MACHINE, also known as HKLM, which corresponds to the system part of the registry, and HKEY_CURRENT_USER, also known as HKCU, which corresponds to the user portion of the registry.

Figure 8-1. A REGEDIT view of the registry on a Windows 2000 Professional client

 

When Richard logs on, he gets the NTUSER.DAT file. In this scenario, when Richard logs on to the local client, the file is copied from the Default User profile directory that already exists on that machine under Documents and Settings. During Richard's first logon, the system also creates a series of directories underneath Richard's profile directory with names like My Documents, Start Menu, Desktop, and so on. If Richard ever places an icon on the desktop or saves a file from WordPad to the My Documents folder, the data is placed inside the relevant folders in Richard's profile. The Start Menu folder holds the Start menu structure that Richard sees when he clicks the Start button.

The Default User and All User Folders

The default contents placed inside all these folders in Richard's profile come directly from the same folders in the Default User profile. However, when Richard logs on, he may see icons or folders inside My Documents, Start Menu, and Desktop that do not appear in his own profile directories. These extra items are displayed as if they were part of Richard's profile, but in fact they are part of the All Users profile that also resides on the computer. In fact, the settings from the All Users\NTUSER.DAT file also are available to Richard. The All Users profile is a great way of adding new items to every user's profile on the client without having to add every item manually. During installation, NT-aware software tends to ask whether the installation is just for the user installing the software or whether it is for all users of the client. If the software is told that it is for all users, then it modifies the All Users profile by default.

To recap, when Richard logs on for the first time, a profile directory Documents and Settings\Rlang is created for him, and everything from the Documents and Settings\Default User profile is copied into it. Richard's profile now contains an NTUSER.DAT file that contains all of his user settings, as well as a series of folders representing his Desktop, his Start Menu, and his My Documents among others. In addition to any files or folders copied in from the Default User profile, Richard also seamlessly sees all of the items corresponding to the Documents and Settings\All Users profile, although they will not exist in his own Rlang directory hierarchy. He also may not be able to remove or delete the files and shortcuts if he doesn't have the permission to do so.

Logging On Locally to the Workstation

Windows 2000 stores much more data in Richard's profile than Windows NT would. In addition, more registry keys have been added to both portions of the registry to enable much more fine grained control over what happens in a profile. I'll have more to say about this later.

If Richard logs off and then on again, the system will detect that he already has a profile folder on the workstation and so will continue to use that rather than create a new one. That is why when Richard creates a desktop file and logs off and on again, the file is still visible on Richard's desktop. If Richard logs off and an administrator logs on and installs a Windows NT/2000-conversant piece of software, this is likely to install itself into the All Users profile, adding folders and files, and changing the registry as required. So when the administrator logs off and Richard logs back on, the new software in the All Users profile will be available to him as if it were part of his own profile; this includes providing any All Users NTUSER.DAT HKCU registry settings that he may need for the application.

TIP: As the registry settings are held in the All Users profile, you might think that Richard cannot change them. This is not the case. As soon as he changes a setting, the system will write it out to his own registry, and this will override any future value for that setting from the All Users profile. Richard's profile will thus contain only the customizations that override the defaults passed in from the All Users profile.

Logging On to the Domain

Now let's say that Richard instead logs on to a Windows NT/2000 domain. If you set the system up in the standard manner, when Richard logs on for the first time to the domain, he is given a profile directory on the local workstation that he logs on to. In exactly the same manner as a logon to the workstation itself, this new profile is made from the Default User and All User profiles on the workstation. When Richard logs off, his profile stays at the workstation. If he then logs on to the domain from another workstation, he has a new profile created for him on that workstation. If Richard then logs off from this workstation and logs on at another, he gets a third profile created. Finally, if he logs back on to the first workstation, he will get his profile that he used there last. This default scenario is very limiting, and Windows NT and Windows 2000 provide three key profile technologies for domain usage that you need to be aware of to manipulate profiles to work in a better manner for your organization:

Having profiles stored on each workstation makes little sense. What would make a lot more sense would be storing the profiles centrally and having them accessible from anywhere on the network where you log on. This is possible and uses what are called roaming profiles. Under Windows NT, you simply filled in the relevant profile field for a user in the User Manager for Domains and pointed the new location at a share for that user. Under Windows 2000, you use Active Directory Users and Computers tool, but the concept is the same. If you did this for Richard, when he logged on for the first time, the system would detect that he did not currently have a roaming profile, and his profile would be created on the workstation as before. However, when he logged out, his profile would be copied up to the network location to become his roaming profile. Then when he logged back on again from anywhere on the network, his new profile on the network share would roam with him and would be downloaded to the workstation for him to use. This download on logon and upload on logout continues throughout the lifetime of the account, provided the account's profile property is not deleted.

Cached Profile Deletion

One problem can come up with this scenario. First, if Richard logs on at a hundred workstations throughout the life of the account, a hundred copies of his profile at various stages of development will exist on the a hundred workstations. To combat this, administrators can set a registry key on the workstations that forces them to discard the profile after the roaming profile upload on logout. The key is DWORD, is held in the system part of the registry, and is the same in Windows NT as in Windows 2000. Setting it to a value of 1 turns it on:

HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\DeleteRoamingCache

This setting needs to be applied to all the computers from which you wish to delete cached profiles. The fastest way to implement such a change in Windows 2000 is to use a group policy, unless you really relish changing the registry manually on every client. You simply make this one change centrally, then have it roll out to all computers that you wish to affect. Under Windows 2000, you do not even need to know that this is the key in the registry that is being modified, as this is one of the many default computer options that are available from the GUI, which hides the actual registry keys and values that you are changing.

A Server-Based Default User Profile

If you wanted to change a setting in the user portion of the registry or add a new icon to the desktop for all new users, you ordinarily would need to modify the Default User profile on every client. This is really an unacceptable solution. The simpler solution would be to store a centrally located copy of the Default User profile that the users automatically downloaded on first logon. That way, if you needed to make a change, you would need to make it only on the centrally stored copy and not on every client. This can be achieved by placing the Default User profile in the NETLOGON share for Windows NT or Windows 2000. Previously I said that when the user logs on to the domain for the first time the system copies the Default User profile from the client workstation. That is, in fact, true only when a Default User profile does not exist in the NETLOGON share; if a central Default User profile does reside in the NETLOGON share, that is used in creating the user's own profile.

TIP: The directory that NETLOGON actually refers to under Windows NT is %systemroot%\system32\repl\import\scripts and under Windows 2000 is %systemroot%\SYSVOL\sysvol<yourdomain><yourcorp>com\SCRIPTS.

The basic point is that while Windows 2000 profiles may be stored under different locations, may store more data, and may be more customizable than Windows NT profiles, they work on the same principles as their direct predecessors.

This is not true for policies, though, and I'm now going to cover what you can do with group policies before moving on to look at exactly how they work in Active Directory.

Capabilities of GPOs

GPOs are manipulated and changed using the Group Policy Editor, a Microsoft Management Console snap-in that graphically displays all the disparate policy settings that administrators can set. Most settings in a GPO have three states: enabled, disabled, and unconfigured. By default, all settings in a GPO are unconfigured. Any unconfigured settings are ignored during application, so the GPO comes into play only when settings have actually been set. Each setting needs to be configured as enabled or disabled before it can be used, and in some cases the option needs no other parameters. In other cases, a host of information must be entered to configure the option; it all depends on what the option itself does. All of this is done within the Group Policy Editor (GPE), the GUI tool for manipulating GPOs.

WARNING: Enabling and disabling most options is fairly straightforward. However, due to Microsoft's choice for the names of certain settings for GPOs, you actually can have the choice of enabling or disabling options with names like Disable Access to This Option. By default, this setting isn't in use, but you can disable the disable option (i.e., enable the option) or enable the disable option (i.e., disable the option). Be careful and make sure you know which way the setting is applied before you actually go through with the change.

GPOs can apply a very large number of changes to computer and user objects in Active Directory. These changes are grouped together within the GPE under the three headings of Software Settings, Windows Settings, and Administrative Templates. There are two sets of these headings, one held under Computer Configuration and one held under User Configuration. The items under the three headings differ, as the settings that will apply to users and to computers are not the same.

Some of the settings under Administrative Templates would look more sensible under the other two sections. However, the Administrative Templates section holds data that is entirely generated from the Administrative Template (ADM) files in the system volume. So it makes more sense to include all the ADM data together. ADM files contain the entire set of options available for each setting, including explanations that are shown on the various property pages in the GPE.

TIP: ADM files can be added and removed by right-clicking either Administrative Template location in the GPE and choosing Add/Remove Templates. Very comprehensive information on customizing GPOs and adding in your own templates can be found in Microsoft's Windows 2000 Group Policy technical white paper on their web site.

During my work on GPOs I ended up wanting an easy-to-access list that detailed which settings were available in general terms so that I could easily open up the GPE and locate the setting I was looking for. Because such a list did not exist, I compiled one myself, which I'll now go through and enumerate, explaining what each aspect of the GPO actually does.

Software Installation Settings (Computer and User)

Windows 2000 now comes with the ability to deploy applications automatically to users or computers using GPOs. These applications can now be installed, updated, repaired, and removed simply using GPOs and their interaction with a new Windows 2000 technology called the Microsoft Installer.

To comply with the Windows 2000 logo program, where an application gets the ability to sport the "Designed for Windows 2000" logo or equivalent, each application must ship with an installation routine that uses the Microsoft Windows Installer technology. During creation of a software application, the author can now create a new MSI (Microsoft Installer) file that is the descendant of the original SETUP.EXE files that used to be created. The MSI contains all of the data required to fully install the application and then some. It knows about the files that are required by the application, including notes such as sizes and version numbers, and it maintains a host of other information including language settings, where to install the application, what files are critical to the functional operation of the application, and so on. On any system that has the Microsoft Windows Installer service installed, the MSI file can be run as if it were an executable, and the application will install.

The administrator has a way of customizing the defaults for the MSI file to tailor the exact settings for the application, say installing it on drive Z: rather than C: or installing Spanish and Polish support in addition to English. The process of customizing the MSI file in this manner is known as creating a transform. The transform is used by the installer service to make sure that the MSI file installs the appropriate items in the correctly configured way.

TIP: Microsoft Office 2000 is the first application to ship with this technology. Prior to installing Office 2000 on any Windows 9x or NT client, Office has to install the Windows Installer service, which it does automatically. Once this is done, the MSI file for Office 2000 can be run by the new Windows Installer service.

That's not all, though; this technology has a lot more to it. First, it has the capability to self-repair applications. So let's say that a user accidentally deletes one or more of the core files required for the application to work. When the user attempts to run the application, the icon or application that the user tries to run first checks with the MSI and the transform to make sure that no critical data is missing. If it is, the data is copied to the appropriate locations, and the application is started. This effectively brings about fully functional self-repairing applications.

Applications also can be deployed using GPOs so that users get them as soon as they log on, or whenever they browse Active Directory to find the applications. You can even tell the MSI to auto-install on any client PC that attempts to open a file with an extension that an MSI-aware application can read.

TIP: Microsoft expects to release an SMS Repackager Step-Up tool after Windows 2000 to permit conversion of an SMS package to a Windows Installer package.

While the Microsoft Installer service is very useful and its configuration will become second nature to administrators as time goes on, the actual technology itself is not really appropriate to this book. If you want to find out more on the Windows Installer service and how you can write your own MSI for both existing and new applications, check out the InstallShield web site http://www.installshield.com/ for the newer version of the InstallShield tool that compiles MSI files, or search the Microsoft web site http://search.microsoft.com/us/dev/default.asp for the phrase Windows Installer.

Microsoft Installer files are inserted into a GPO from the Software Installation section. Figure 8-2 shows the GPE with two GPOs snapped into it, with one expanded in the scope pane to show the two Software Installation parts.

Figure 8-2. Software Installation settings for a GPO

 

Software Installation is listed under both the computer and user sections of the GPO, and thus you can deploy software installations to both computers and users through the two different parts of the GPO. Here, this GPO is deploying the Version 5.0 Systems Administration tools as an assigned application to all users that receive this GPO. If you remember the example from the start of this chapter, this GPO is used to auto-install the Systems Administration tools onto any client that certain systems administrators log on to. We know that it auto-installs, because that is one of the configured options that has been checked in the GPE in Figure 8-2. More information on Microsoft Installer applications can be found in the next section.

Windows Settings (Computer)

This part of a GPO holds startup and shutdown scripts as well as security settings. In Figure 8-3, the GPO being edited is the Default Domain Policy installed by default on creation of a domain. This GPO applies to all computers in the domain, so any change that I make to this GPO will affect DCs, member servers, and ordinary workstations alike.

Figure 8-3. Computer Security Settings and scripts

 

Startup and shutdown scripts can be made to execute asynchronously or synchronously. They can use VBScript, JScript, any other ActiveX scripting host language or even plain old CMD/BAT files that you may already be familiar with. You can even pass parameters to the scripts by configuring the parameters into the GPO.

The Security Settings portion of the GPO is by far the larger of the two sections covered by the Windows Settings heading. The items displayed in Figure 8-3 cover the following areas:

Account Policies
These policies allow you to apply settings that govern how accounts on the system will work.

WARNING: The settings for the following three policies can only be applied domain wide; they cannot have different values for different Organizational Units in a domain. This is why you need to consider multiple domains in the namespace design if you need to apply different settings to different sections of your organization.

Password Policy
These settings allow you to specify policy settings for passwords, such as how many days a password should exist before expiration.

Account Lockout Policy
These settings allow you to specify how many grace logons a user is allowed before he locks out his account due to bad logon attempts. You also specify how long the account should stay locked out.

Kerberos Policy
This setting is domain wide only, so it only exists in the Default Domain Policy. It allows you to configure the various Kerberos security and ticketing policies that apply to the domain.

Local Policies
These policies directly affect the operation of a local machine, be it a workstation or a DC.

Audit Policy
These policies list items that, when turned on, will write audit entries for success and/or failure to the security event log of any machine that is affected. In other words, if I were to turn on Audit Logon Events (Failure) in the Default Domain Policy, any failed logon attempts on any machine within that domain would be logged to the security event log on that same machine.

User Rights Assignment
While permissions are used to allow or deny access to an object in Active Directory or a part of a filesystem, user rights give special abilities to an account or the operating system, such as whether the machine can be accessed only locally or only across the network, whether an account can add workstations to a domain, or whether an account can act as part of the operating system and manipulate devices at a low level. These items used to be available from a menu in Windows NT's User Manager, but a few more items have been added to accommodate the changes to Windows 2000.

Security Options
These settings, which are displayed in the results pane of Figure 8-3, allow configuration of security on one or more computers throughout your organization.

Event Log Settings for Event Logs
These settings allow you to set various properties of the three main event logs (security, application, and system), such as the maximum size, how long to retain the logs, and so on, on any computer that receives this policy.

Restricted Groups
This allows you to indicate specific groups on any computer that receives this policy and force them to be members of other groups or to have members themselves.

System Services
This setting allows you to manipulate services that may be running on any machine that receives this policy and set the permissions for access to those services, such as who can start, stop, and change properties, as well as the default state (i.e., Automatic, Manual, or Disabled).

Registry
This setting allows you to add a registry key on any computer that receives this policy and automatically set its permissions and auditing properties. If you wanted to audit successful and unsuccessful accesses to the HKEY_USERS key for computers in one specific Organizational Unit only, you would do it by adding an entry to a GPO that affected that Organizational Unit.

File System
This setting allows you to add a file or directory on any computer that receives this policy and automatically set its permissions and auditing properties. If you wanted to set read, write, and change access permissions to the C:\WINNT or C:\WINNT\SYSTEM32 directory for every computer in one specific Organizational Unit only, you would do it by adding an entry to a GPO that affected that Organizational Unit.

IP Security Policies on Active Directory
This allows you to configure whether a server requires use of Internet standards on IP security (IPSec) when clients attempt to communicate with the server or whether it just requests IPSec if the client is capable. From the client side it allows you to dictate whether a client will always use IPSec of a certain form or whether it will use IPSec only when a server requests it. All aspects of IPSec can be configured from here.

Public Key Policies
This location allows you to set all manner of Public Key Infrastructure (PKI) settings that are now natively supported in Windows 2000. Administrators can specify that the system has a trusted certificate list that it considers reputable, that it will automatically pass certificates of a certain type out to users or computers without their intervention, and that key users (with the administrator as default) can be made Recovery Agents and thus gain the permission to use another user's public keys and certificates to decrypt that user's encrypted data. As these settings are specific to a GPO, and a GPO can be specific to a location in Active Directory, this allows you to set out a number of different policy settings that apply to different areas of the tree as required.

Administrative Templates (Computer)

This is the GPO location that stores changes to registry settings that affect the HKEY_LOCAL_MACHINE portion of the registry. The entire hierarchy of graphical items depicted in the list along with their settings and help descriptions has been assembled from the set of ADM template files that exist in the system volume for each GPO. This structure has not changed much since the Windows NT format, and administrators will be able to start adding their own templates as required, thus adding other branches and leaves to the hierarchy. Figure 8-4 shows the hierarchy of items.

Figure 8-4. Computer administrative templates

 
System
This contains a few keys that don't fit under the following three headings. It will become a catchall container for any nonspecific system keys as time goes on.

Logon
This includes a number of items related to how the system is to operate during logon. For example, you can set when and how the system detects a slow link during a logon and what actions to take when a slow link is detected. Actions could include choosing a locally cached profile over the network profile or loading the network profile anyway. This area allows fairly heavy customization of how user profiles will work under Windows 2000, and you can even specify that a user who fails to find his network profile is automatically logged out rather than being able to log on with a default profile or a cached profile. Couple this with the setting to delete cached copies of roaming profiles, and you instantly gain the ability to secure a workstation against keeping a user's roaming profile after he has logged out and making sure that he cannot log on with a temporary profile if the system can't find his roaming profile at any point. This is a good example of making sure that your own rules for how profiles are dealt with as far as GPOs are concerned are acted on centrally.

Disk Quotas
This section contains settings that allow you to turn disk quotas on at any machines that receive this GPO, as well as manipulate a variety of settings.

Group Policy
This is one of the most significant areas, as it contains settings that govern how computers this policy applies to are going to implement Group Policy. The contents are depicted in Figure 8-4.

Network Offline Files
This is a large set of values that govern exactly how files and folders are to be made available on the local machine when it is offline. You can turn offline folders on and off, set the cache size to be used for such items, define how synchronization is to occur, and so on.

Network Network and Dial-up Connections
This location has one key that determines whether users can enable, disable, and configure the shared access feature of a dial-up connection from any Windows 2000 computer that this policy applies to. Shared access lets users configure their system as an Internet gateway for a small network of machines, providing network services, such as name resolution, to that network.

Printers
This location has a series of keys that provide a number of new options for printers, dictating whether printers can be shared at all from a computer, whether they can be autopublished into Active Directory, and so on.

Printer objects in Active Directory have a number of extra attributes now, and these attributes can and will be regularly searched. Take an example like the attribute called Location; users can search for printers based on location from a simple pop up box that appears when you choose Search. . . For Printers from the Start menu on a network client. Users also can search for "printers near me," making use of a location tracking feature. Location tracking lets you design a location scheme for your enterprise, based on room number, floor number, building name, city, country, and so on and assign computers and printers to locations in your scheme. Location tracking overrides the standard method of locating and associating users and printers, which uses the IP address and subnet mask of a computer to estimate its physical location and proximity to other computers. GPO settings here allow you to force a workstation to search as if it were in a specific location (i.e., forcing your own value for location whenever that client searches for printers nearby), as well as turning on location tracking and its associated options.

Windows Components Task Scheduler
Ordinary logged-on domain users normally can manipulate the task scheduler on a machine. As an administrator you may not want this, or you may want to set certain tasks and not allow users to delete them. These options allow you to disable creation and deletion of tasks, prevent the running or stopping of tasks on an ad hoc basis, prevent scheduling any applications that do not appear anywhere other than the user's Start menu, and so on.

Windows Components Windows Installer
These settings allow an administrator to configure a number of Microsoft Installer options that will apply to all applications installed on this computer. These include options such as whether to disable the use of MSI files on that client, whether to install all MSI files with elevated privileges (i.e., whether to install using the local SYSTEM account which has full rights to the files and folders on the machine's disks, which the user may have no rights to), how much logging is to be done, and so on.

Windows Components Internet Explorer
A few settings here allow an administrator to dictate whether IE can autodetect missing components and new versions as well as what its security zone settings are.

Windows Settings (User)

While this section contains only a few settings, the contents are likely to become very familiar to you. This area holds logon and logoff scripts, allows you to redirect core system folders to network areas from the normal hard disk locations, and allows you to specify IP security policies. Figure 8-5 shows a snapshot of the contents.

Figure 8-5. Windows Settings (user)

 
Folder Redirection
This is a very useful setting that is easy to understand and manage. If an administrator wants to redirect the My Documents, My Pictures, Application Data, Desktop, and Start Menu locations from their defaults, this section allows it to be done. For example, at Leicester University we use roaming profiles, but we don't want the My Documents folder to roam with the user because of the large number of folders and files it would contain. In other words, downloading and uploading My Documents would slow down logon/logoff considerably. So instead we redirect the user's My Documents folder (and the My Pictures folder within it) to the network paths when he logs on. That way, whenever an application, such as Microsoft's Office 2000, attempts to save a document to the My Documents folder, the folder that the user sees is the My Documents folder located in his home folder.

This part of the GPO is different from the others in that it doesn't contain settings as such. Instead, the folders listed should be right-clicked and the Properties item selected from the drop-down menu that appears. This brings up the main redirection settings window for that folder. This window allows you to redirect all users who receive this GPO to one folder or allow a finer-grained control so that users who are members of a certain group get Folder A, users who are members of another group get Folder B, and so on. You can then specify other settings such as whether the existing folder is to be moved when this GPO takes effect and whether the folder is moved back when the policy stops taking effect.

WARNING: I find this policy somewhat useful. Its main problem stems from the fact that you can't use environmental variables in the strings, as the GPO will take effect before environmental variables are set. So if you have a set of users who are to have their My Documents redirected to folders that correspond to their usernames, there is no way of getting the usernames into the folder path using the %USERNAME% variable in the same way that there is for profiles.

If you do want to redirect but don't want the hassle of doing it this way, edit the relevant keys in the following two user registry locations to point the folders elsewhere. Note that both must be edited for the process to take effect:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Logon/Logoff scripts
This is where you can specify the logon and logoff scripts that users will execute. Whether these are executed synchronously or asynchronously is specified in the User Configuration Administrative Templates section of the GPO.

Security Settings IP Security Policies on Active Directory
These settings correspond to those held under Windows Settings in the computer portion of the GPO. The results pane of Figure 8-5 shows the three default policies held under this location. Note the two extra icons in the top right of the MMC; the first allows you to create an IP security policy, and the second allows you to manage IP filter lists and their actions. Both are also available by right-clicking in the usual manner.

Security Settings Public Key Policies
These settings correspond to those held under Windows Settings in the computer portion of the GPO.

Administrative Templates (User)

This is the core of the settings that will govern how the administrator controls the system's look and feel for the user. The settings here are all geared to various lockdowns that you may wish to make to a user's account; if you do not wish to lock down a user's account, most of these settings will not be of much use. If roaming profiles are turned on, these settings roam with the user's profile as he logs on at each client. Figure 8-6 shows the full branch expanded.

Figure 8-6. Administrative Templates (user)

 
Start Menu & Taskbar
This location is used when the administrator wishes to customize how the Start menu and the taskbar appear to the users this policy applies to. Here an administrator can disable various options on the Start menu, such as the control panel, printers, logoff, or the shutdown button, and also can remove various items, such as Run, Search, or Favorites, entirely if so desired.

Desktop
Like the last item, this section is used to lock down the desktop. Here you can remove the various icons, such as My Network Places, as well as configure whether the desktop settings themselves can be changed and whether they are even saved on logout. Active Desktop is configured (or disabled) from here.

Control Panel Add/Remove Programs
This allows you to set how the new Windows 2000 Add/Remove Programs control panel is customized for an individual user. You can disable the option entirely, hide some of the options, or even force the system to bypass the addition of other software but still add official components to the system by going straight to the Components menu.

Control Panel Display
This can be used to disable individual tabs on the Display control panel, so that users cannot change wallpaper, the screensaver, or the settings for their display (such as display drivers), which as administrators well know, can cause immense problems.

Control Panel Printers
Here you can disable adding or deleting printers, as well as decide whether to hide various property pages on the Add Printer wizard.

Network Offline Files
These settings allow the administrator to govern how cached files for offline access will actually operate. For example, these control whether the files are automatically synchronized at logoff, how much event logging is done, how much space can be used up by the offline cache, and so on.

Network Network and Dial-up Connections
This section allows the administrator to configure how RAS and LAN connections will work for the user. Figure 8-6 shows the full list of options.

System
A few extra features live here, as they don't fit under any other category. Items such as how programs interpret two-digit years, whether to disable the Windows registry editors--Regedt32.exe and Regedit.exe, or whether to allow only a specified list of programs to run for a user.

Logon/Logoff
This is a useful set of keys that really should be called Logon, Logoff, and Profiles. The logon/logoff part allows the administrator to specify whether logon/logoff scripts run visibly and whether they run synchronously.[4] Administrators also can disable the Lock Workstation, Task Manager, Change Password, and Logoff buttons on the Windows Security screen that you get when you press Ctrl-Alt-Del while being logged on.

In the profile settings you can specify whether certain directories do not roam with the user's profile. This is a very useful option if you don't want the Internet Explorer cache and history files or the My Documents files roaming with the user. Administrators also can specify whether the user's roaming profile should be limited in size to a certain value, along with various warnings that occur regularly; this is a useful addition that was first introduced in Service Pack 4 for Windows NT.

Group Policy
As it was in the Computer section of Administrative Templates, this is one of the most significant areas. It contains configuration data that governs how group policies apply to users. For example, it allows you to configure when and how a slow link is detected, how often the user section of this GPO is refreshed, and whether GPOs are downloaded only from the FSMO PDC role owner (described in Chapter 2, Active Directory Overview) or from any DC.

Windows Components Windows Explorer
These settings relate to how the shell and desktop look and feel. You can customize whether specific icons (such as drives in My Computer or Entire Network in My Network Places) are displayed, decide whether certain normal modes of operation (such as whether to disable workgroup contents in My Network Places or remove the Folder Options menu from the Tools menu) are blocked, or change the default settings (such as changing the maximum number of recent documents from 15 to a lower or higher value).

Windows Components Windows Explorer Common Open File Dialog
This setting allows administrators to tailor the dialog box that is displayed automatically by programs whenever users need to browse to and open a file. For example, you can specify whether the Back button or the Common Places bar--which contains icons representing History, Desktop, Favorites, My Documents, and My Network Places--are displayed. If this seems confusing, run up any program on Windows 2000 and open a file to see what I mean.

Windows Components Microsoft Management Console
While you may use the MMC to create your own consoles regularly, you may wish users to be able to use only existing consoles and not create new ones. Alternatively, you may want to allow users to create consoles but limit them to only a few snap-ins. These settings allow you to do either.

Windows Components Microsoft Management Console Restricted Permitted Snap-ins
This section contains the entire set of snap-ins that are available standard. Administrators use this policy to prevent users from gaining access to individual snap-ins or explicitly permit them to use each one. As with all settings, by default these snap-ins are unconfigured, which means all users get all snap-ins.

Extension snap-ins
Some snap-ins can come with what are termed extensions, extra sets of configurable options that you can add to give more functionality to the snap-in. This section contains a list of all permitted extensions and allows you to enable or disable them as you wish.

Group Policy
These items correspond to the headings that I've been going through here. You can decide, for example, to allow a certain set of users access only to the Administrative Templates (User) section that I'm discussing here. Another set of users may have access to manipulate Group Policy objects, but the MMC allows them to see only the Software Installation (User) and Software Installation (Computer) parts. This effectively blocks their ability to manage parts of policies that you as the administrator don't give them rights to.

Windows Components Task Scheduler
This contains settings to allow the administrator to configure the ability of users to use the task scheduler on clients. Administrators can disable the ability to create new tasks, prohibit viewing existing tasks, or limit certain functionality.

Windows Components Windows Installer
This area contains configuration settings for users that relate to the software packages in MSI form that have been deployed to the user. For example, the administrator can configure whether applications are always deployed with elevated privileges, in what order locations are searched for MSI packages (used when a user requests a list of packages or a user attempts to open a file with an unknown extension), and whether the ability to roll back a failed installation is enabled or disabled.

Summary

Whew! That was a lot of settings. I've now covered the basics of what profiles can do and how modifications to a standard centralized profile make a lot of sense and are easy to manage. I've also taken a very in-depth look at the diverse sort of registry, user interface, file permission, and system changes that can be made using GPOs.

It's now time for a good look at exactly how Windows 2000 GPOs actually work from under the hood, so to speak.

1. A random time interval of 0-30 minutes is added so that all workstations do not attempt to redownload the policy at the same time.

2. %systemroot% is the system environment variable that refers to the location of the Windows NT system files. If Windows NT were installed onto drive C: in the normal way, then %systemroot% would be C:\WINNT.

3. As the SYSTEM.DAT file is not specific to any particular user, but rather to the client itself, it is held in the %systemroot% folder on the client.

4. You can't run a logon script synchronously if it needs to interact with the user's environment. Synchronous logon scripts will always finish prior to environment variables being set and prior to the user's profile being loaded. It isn't possible to query the number of new mail messages a user has in a synchronous logon script by reading the user's name from the environment variables or profile, for example, as the user is not yet fully logged on when the script runs. The solution is to run the script asynchronously.

Back to: Windows 2000 Active Directory

oreilly.com Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
 International | About O'Reilly | Affiliated Companies | Privacy Policy

© 2001, O'Reilly & Associates, Inc.