Abstract
This chapter explores a feature new with Windows 2000 — the Active Directory — and its relationship to the Registry. You will become familiar with group policies and Windows Installer technology. And you will learn about the Active Directory Class Store, which is really the first "centralized Registry" that Windows has provided and likely to form the basis for the future of the Registry in large and small enterprises alike.
USING THE ACTIVE DIRECTORY TO MODIFY AND MANAGE THE REGISTRY
The Active Directory (AD) is Windows 2000’s new Global Directory Service and, in some ways, it is an extension of the machine-based Registry — a separate "super Registry." The SAM database, which used to be a Registry hive on NT 4.0 domain controllers, is now part of the AD. The AD is now the home for user and machine information, as well as a whole host of other types of objects — from printers, to shared volumes, to group policies, to applications. You need to understand how these services — in Win2K for the first time stored in a central repository — impact the Registry and how they might challenge your ability to troubleshoot Registry problems. This chapter examines all of those new interrelationships.
Group policies are arguably the most complex new technology in Win2K. They not only replace NT 4.0 and Win95/98 system policies, but also provide Registry security enforcement and application installation features. Application deployment through the Windows Installer technology provides a whole new way of distributing Registry changes to computers and users.
This chapter focuses on the AD features that help you modify and manage a Win2K device’s local Registry. Think of the Registry as a local, nonreplicated database residing on each Win2K device (and on each NT 4.0 device before that). Then, think of the AD as a centralized, replicated Registry extension. For example, using AD-based group policies, you can create centralized security templates to control Registry security on devices in your AD domains. Using the software installation feature within group policy, you can manage application installations and thus manage how Registry modifications are made to computers and users. Finally, the Class Store, which is integrally tied to the software installation feature, is a set of objects in the AD that look and act like a centralized version of HKEY_CLASSES_ROOT.
GROUP POLICY OBJECTS
One of the key features in Microsoft’s Change and Configuration Management (CCM) strategy in Win2K is the ability to use the AD as a kind of application repository. That is, you can "advertise" applications such as Word, Excel, or Visio as AD objects, which can then be distributed to and installed by end-users, depending upon where in the directory the objects related to the users or their computers reside. The name of the feature you use for this advertisement function is Software Installation.
Specifically, Software Installation is defined within a Group Policy Object (GPO). GPOs are AD objects that can be applied to a local machine, a site, a domain, or an organizational unit (OU). In fact, the acronym LSDOU (Local, Site, Domain, OU) is used to describe the order in which GPOs are applied to users and machines. Although an in-depth discussion of GPOs and their design is beyond the scope of this chapter (for more information, see http://www.microsoft.com/windows2000/library/technologies/management/default.asp), I discuss how GPOs impact and interrelate with the Registry. GPOs themselves are multifunction AD objects. They contain multiple "nodes," and each node provides a different kind of control over users or computers. Table 1 summarizes the per-computer and per-user nodes available in Win2K GPOs.
For the purposes of our Registry discussions, we are most interested in the Software Installation and Administrative Templates nodes. Remember that GPOs are applied to user objects and computer objects only. They are not applied to security groups. However, the effect of a GPO can be filtered by security groups. That is, you can have a GPO assigned to a particular OU (all of its users and computers), but you can then restrict how that GPO is applied based on the particular security group to which those users or computers belong.
As might be expected, computer-specific nodes and their settings are only applied to computer objects when the computer processes the GPO — usually at system startup and at periodic intervals thereafter that you can configure via group policy. User objects process user-specific settings only at user logon time — the settings can be updated manually at periodic intervals that you can configure via group policy. Hence, you could face the challenge of having a user who logs on to a particular computer processing different GPOs — if the computer account is in one OU and the user is in another (Figure 1).
You also can trigger computer and user policy manually by using the secedit.exe command with the /refreshpolicy option. However, note that secedit.exe does not trigger any software installation policy you may have defined.
Note: Given the hierarchical nature of the AD, calculating effective policy for a given user or computer is a huge challenge if you have many different GPOs at different levels within a Domain. Unfortunately, Microsoft does not provide any tools for "modeling" the results of multiple policies being applied to a given user or computer. Your best tool for doing so is to test all of your policies before putting them into production. The Windows 2000 Server Resource Kit also includes a command-line tool called GPResult.exe that will output a list of current GPO settings for a given user logged onto a given computer.
One more thing to note about GPOs is their actual physical makeup. GPOs are composed of two physical "pieces" — the Group Policy Template (GPT) and the Group Policy Container (GPC). The first piece, the GPT, is comprised of a set of files and folders that are replicated to all domain controllers in an AD domain. By default, GPOs are replicated as part of the "Sysvol." In Win2K, Sysvol replaces NT 4.0’s Netlogon share. Sysvol is a share that is created automatically on Win2K domain controllers. Files contained in the Sysvol share are automatically replicated on the same schedule as the Active Directory replication. The NT File Replication Service (NTFRS) is responsible for replicating Sysvol. The Sysvol share physically resides in %systemroot%\sysvol\sysvol for a given domain controller. The source files for Sysvol, however, are kept in %systemroot%\sysvol\domain. If you expand this folder, you see a Policies subfolder. In this Policies subfolder, you see a number of folders with names that look like GUIDs, which they are — for the corresponding GPOs in the directory.
Tip: You can get a GPO’s GUID by starting the Group Policy Microsoft Management Console (MMC) snap-in focused on the GPO of interest. After it loads, right-click the GPO name and select Properties. The GUID is listed as the "Unique Name" for that object under the "General" information tab.
Note: There are a couple of ways to bring up the Group Policy tool, but perhaps the easiest is to load the MMC snap-in for "Active Directory Users and Computers." Right-click on a Domain or OU name and select Properties from the context menu. You see a Group Policy tab, which lists all available GPOs at that level and lets you edit them. You can also load the Group Policy tool by typing gpedit.msc from a command line. However, when you launch the tool this way, it is automatically focused on the local GPO for that computer, rather than a domain, OU, or site-based one.
Figure 2 shows a directory listing for one GPO in the Sysvol folder. As you see in Figure 2, a lot goes into a GPO — and all of those directories, subdirectories, and files for each GPO are replicated to every domain controller in the domain. This collection of files that makes up the GPO is referred to as a Group Policy Template (GPT). For the purposes of this chapter, we explore only those pieces of the GPO that touch the Registry. For Figure 2, that would include the following subdirectories and their contents:
\Adm
\Machine\Applications\*.*
\User\Applications\*.*
The second physical piece of a GPO, the Group Policy Container (GPC) is the part of a GPO that resides within the AD itself. That is, the GPC is a set of Active Directory Objects that are created when you first create a GPO. The GPC can be viewed using the AD Users and Computers MMC snap-in. From the MMC menu, choose View/Advanced Features. Then, drill down into your AD domain and you should see a folder called System. Under System there is a subfolder called Policies and within that folder are GUID-based folders that correspond to each GPO you’ve created within your domain.
How Software Installation Works
Now that you have some of the foundation for understanding GPOs, I present some of the GPO features that have an impact on the Registry. The first of these is the Software Installation feature. Software Installation is a tool that enables software distribution and desktop configuration management via the AD. What that means is that you can tell the AD that you want to make applications X,Y, and Z available to a given domain, site, or OU’s computers. Likewise, you can make applications A, B, and C available to users within a domain, site, or OU.
The overall effect is that users who sit down at machines subject to that GPO get applications X, Y, Z installed for them. And users subject to that GPO who logon at the same machine get applications A, B and C installed as well. Of course, the installation process does not happen all at once, which would render the machine useless under the weight of six simultaneous application installations. Rather, the applications are installed in a "just-in-time" fashion, depending upon how you have configured it within the GPO.
Using the Software Installation feature, you can present an application for installation to a user or machine two ways: you can either publish or assign it. The difference between the two lies in how an application presents itself to the user’s desktop and how it uses the Registry to enable just-in-time installation. When you are ready to add an application to a GPO in the Active Directory, you need to decide which mode to use.
Publishing an Application
When you publish an application, you make it available to your users to be installed if they need it. (Note that, based on this definition, there is no support for machine-based application publishing. You can publish only on a per-user basis within a GPO.) It is an "optional" application, so to speak. For example, you may have an accounting application that not all users in your environment use, but you want to make it available to those who need it. Publishing serves that purpose. Specifically, when you publish an application, Win2K makes it available to the user via the Control Panel’s Add/Remove Programs applet. Figure 3 shows an example of Excel 97, published via a GPO called "AppDeployment" as it appears in the Add/Remove Programs Control Panel applet. If I select this application and click Add, the setup routine for Excel 97 starts and the application is installed on my local workstation.
When you publish an application, it requires that the user (or machine) log off and log on to show up in the Add/Remove Programs Control Panel applet. When you select Add New Programs the Win2K client queries the AD to determine which applications have been published for this user.
To actually publish an application, you would use the Group Policy tool snap-in to the MMC console, with a focus on the GPO in which you are interested. Figure 4 shows an example of what a published application (Excel 97) looks like within the GP tool.
Note: Before I discuss how assigning an application works, you should know what it is that you are actually publishing (or assigning) when you use the GPO’s Software Installation feature. Briefly, Software Installation supports a new package setup format called the Windows Installer. I discuss the Installer technology in more detail later in the chapter; application setups packaged using the Windows Installer have an .msi extension. Before I discuss how assigning an application works, you should know what it is that you are actually publishing (or assigning) when you use the GPO’s Software Installation feature. Briefly, Software Installation supports a new package setup format called the Windows Installer. I discuss the Installer technology in more detail later in the chapter; application setups packaged using the Windows Installer have an .msi extension.
Tip: The Software Installation feature also supports a format other than .msi, called Zero Administration Packaging (ZAP). ZAP files are simple text .ini files that let you publish (not assign) your existing application setups without having to convert them to the .msi format.
Assigning an Application
Assigning an application is different from publishing. Namely, when you assign an application, you also take the first step toward installing that application for a user or machine. Specifically, you "advertise" the application in the user’s environment and in the Explorer shell. By advertising, I mean that an icon for that application is placed on the user’s Start Menu or Desktop. Assigning an application also creates an association between the file extensions for that application and the application itself within HKEY_CLASSES_ROOT.
Tip: If you are publishing an application, you can also tell the GPO to associate a file extension with the published application. This means that when you click on a file for a published extension, the application installation process is triggered.
For example, if you assign Microsoft Word to a user or computer, the assignment process creates an entry for .doc files within HKEY_CLASSES_ROOT that refers to the assigned application. Then, even if the application has yet to be installed, the user can invoke the installation process by simply accessing a file that has such an extension type. For example, suppose that I receive an
e-mail message with an attached Word document. When I choose to open that document, the system notices that .doc files have been associated with an assigned application, and the application is installed.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
