The third element of the presence that is created by assignment is more behind-the-scenes than the first two. Many Windows applications contain COM components — be they ActiveX controls or OLE servers — that can be reused by other applications. When you assign such an application, it makes Registry entries in HKEY_CLASSES_ROOT. These registrations are sort of placeholders for those COM components. When another application references an interface within a COM component that has been assigned, that placeholder registration tells the application where to get the actual .dll or .exe that contains that component. For example, you might have assigned Word to a particular OU. When users within that OU log on to their workstations, the Explorer shell registers the shortcut, the file association, and any COM registrations associated with Word.
However, suppose you have another application, such as Microsoft’s email client, Outlook. Outlook gives you the option of using Word as a mail editor, but Word has not been installed — only assigned. When you select the Outlook option of using Word, a COM interface is called to bring up that portion of Word code. Because that COM interface is part of the assigned Word application, that functionality is "faulted in" right at the time it is invoked, and voila! — Word email editing. COM’s ability to "understand" what’s needed is a function of changes made to the way COM works in Win2K. Specifically, when an application invokes a COM interface, the system knows that, even though the component has yet to be installed, it has been assigned by the AD and needs to be faulted in.
Note: When I say that changes are made in HKEY_CLASSES_ROOT, I ignore the fact that Win2K has machine- and user-specific areas of the Registry for class registrations. What really happens in HKCR during application assignment is a function of the particular user’s security rights. If the user has administrative access over a machine, when the registrations are made, they are made in HKLM\Software\Classes. If the user is a "normal" user — without sufficient rights to write to HKLM — then assigned application registrations are written to HKCU\Software\Classes. However, this default behavior can be overridden within the .msi package — where you can specify that the application is installed only on a per-user or per-machine basis.
In summary, when you assign an application, the following three things happen to the users’ environment:
A shortcut is placed on the desktop (if specified in the application package).
An association(s) is made in HKCR for that application’s supported file extensions.
OLE/COM registrations are made in HKCR for that application’s supported components.
These Windows Installer presences are also called "entry points," because they provide an entry point into an application that is assigned, but not yet installed.
Earlier in the chapter, the listing in Figure 2 showed that references to published and assigned applications are housed within the GPT under the Machine\Applications and User\Applications folders. The GUIDs you see under these folder represent product GUIDs for that particular application. Product GUIDs are explored in the discussion about the Windows Installer technology and how it uses the Registry later in this chapter.
Note: As I mentioned previously, publishing an application is supported only within the user settings portion of the GPO. You can’t publish an application to a machine. On a per-machine basis, you can only assign applications. When you assign an application to a machine, that application is actually installed at system startup time, rather than when a user clicks on an icon or activates a file extension. This lets you deliver application installations in an unattended way to a workstation or server — albeit with a workstation or server reboot.
HOW GROUP POLICY ADMINISTRATIVE TEMPLATES AFFECT THE REGISTRY
NT 4.0 and Win95/98 support system policies, which are special Registry hive files that you could create and deliver to users at logon time. These Registry files (by default called ntconfig.pol and config.pol in NT 4.0 and Windows9x, respectively) are used to modify HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE entries in a centralized way. Further, within a given policy file, you could specify different Registry modifications based on user ID, machine name, or Global Group. However, system policies were limited and using them was complicated.
Template .adm files controlled which Registry keys and values you could modify and what the possible values could be. These text files used a kind of macro language to specify which key or value you wanted to modify and how the value was filled in. In some cases, you could either check a box to put some DWORD into a value or enter free-form text for those Registry values that accommodated that.
You could customize the .adm files to your heart’s content. In most cases, the standard policies that came with NT or Win95/98 out-of-the-box were used to "lock down," or restrict access, to parts of the Explorer shell related to both the machine and the user. For example, I could remove the Run option from a user’s Start menu. In particular, the following two keys were the primary targets of many system policy lockdowns related to the Explorer shell:
NT 4.0 and Win95/98 system policies have been fairly limited in their capabilities and hard to manage. You could have only one policy file in a given authentication domain, and if you tried to manage too many Global Groups-based settings within a single policy file, they quickly became unwieldy. To make matters worse, once you had "tattooed" HKLM and HKCU with policy-based lockdowns or modifications, the Registry changes were not easily removed. Simply removing the system policy file from the domain did not remove the Registry modifications. Rather, the Registry modifications had to be explicitly turned off by another policy that counteracted the first. Further, the tool that was used to edit Group Policy files, the System Policy Editor, was a slow and clunky interface.
In Win2K, much of this has changed. What was system policies in downlevel Windows versions has now become part of the larger GPO. Referring back to Table 1, note that the Administrative Templates portion of GPOs performs the identical function to old system policies. GPO-based administrative templates still use the .adm file format. Two default templates — System.adm and inetres.adm — are loaded by default within a Win2K GPO and are stored under the \ADM folder within the GPT. Win2K also comes with a number of other .adm files, usually found in %systemroot%\inf, which provide some application-specific templates for common Microsoft applications, such as NetMeeting.
Figure 5 shows part of the System.adm file as an example of how these file are structured. As you can see from the file format, the structure of Win2K .adm files is similar to that of NT 4.0 .adm files. The main difference is that Win2K supports additional macro keywords to provide added functionality. One new keyword, EXPLAIN, lets the author of an .adm file create some Help text associated with a given policy item. Each GPO can have a different set of .adm files, and, as I mentioned before, a given machine or user can process multiple GPOs. The flexibility you get in the area of desktop and application control and lockdown is as granular as you want to make it.
Having looked at the mechanics of how administrative templates are used, let’s look at what administrators see when they edit a GPO using administrative templates. The first thing to do is to start up the Group Policy tool MMC snap-in, focused on a GPO. Every Win2K domain contains a Default Domain Policy when first installed, so if you haven’t created any other GPOs, you can start by editing that one.
From the AD Users and Computers snap-in, right click the domain name, choose Properties and then select the Group Policy tab. Highlight the GPO of interest and select Edit. The GP tool launches focused on that GPO. Underneath the GPO name, you see two nodes — Computer Configuration and User Configuration. To discuss Administrative Templates, let’s focus on the User Settings. If you expand the User Configuration node, then again expand the Administrative Templates node, you see a tree of folders representing the available areas for administrative template controls (Figure 6).
What you see is really a graphical representation of the .adm files that are loaded by this particular GPO. The .adm files dictate which folders, Registry keys, and values are presented here. Each folder, such as Control Panel and System, represent .adm categories. And, within each category are sets of policies that you can set. For example, if we expand the System folder, we see a subfolder called Logon/Logoff. Under Logon/Logoff, the right-hand pane of the GP tool exposes all of the available Registry lockdowns related to logon and logoff (Figure 7).
Like NT 4.0 policies, Win2K policy items, such as those listed in the right-hand pane of Figure 7, can have three different states, as follows:
Not Configured — The particular Registry value behind this policy item is not changed, regardless of its state.
Disabled — This particular policy item is disabled. That is, if the policy is "Remove Folders from Settings on Start Menu," then disabling it means that Folders are always in the Settings portion of the Start Menu. That is, they are "unremoved."
Enabled — This policy item is enforced at all times.
Of course, if you have multiple GPOs being applied to a user or machine, you can have two of the same policy items from different GPOs that contradict each other (i.e., one enables an item and the other disables it). In this case, it’s the "last-writer-wins" approach that resolves the conflict. The last-writer may not always be obvious because you can have GPOs at the Site, Domain, or OU levels — and at each of those levels you can have multiple GPOs. I have already mentioned the order of precedence in the Directory (LSDOU), but you can also set the order of precedence within one of those containers. A set of up/down buttons next to the list of available GPOs lets you set the order of precedence within a container. The higher a GPO is in the list, the later it is processed, and its settings override previous ones.
Once you set all of the policy items within a GPO, where is this information kept? As you might have guessed, it is replicated in the Sysvol directory, in the Group Policy Template for that GPO. Both machine- and user-based administrative template settings are stored in a file called registry.pol. However, each is stored in its own folder. For example, user-specific registry.pol is located in %systemroot%\sysvol\domain\policies\<GPO_GUID>\User. Registry.pol replaces the ntconfig.pol and config.pol files in earlier Windows versions. However, registry.pol is not a valid Registry hive file, as ntconfig.pol was. You can’t load it into a temporary hive, nor can you view it. It is a text file, but it contains nonprintable characters and is not editable by a text editor, such as Notepad.
Another drawback of NT 4.0 policies has been the effect of tattooing. That is, when you remove an NT 4.0 policy from the domain, the entries are left in the Registry for the affected user or machine. This is not the case in Win2K. If you disable or remove a GPO that has made Registry changes, the corresponding changes are also removed from the Registry.
In NT 4.0, the default path for policy restrictions has been in HKCU or HKLM, under the Software\MS\Windows\CurrentVersion\Policies keys (see full path earlier in this section). In Win2K, the default path for policy settings has been changed to HKCU and HKLM under the Software\Policies key. As long as your .adm templates make changes to either of these Win2K policy keys (the old NT 4.0 paths are supported also), any tattooing is cleaned up when you remove a GPO. Of course, you are not limited to these keys. You could just as easily create an .adm file that enforces Registry policy on HKLM\Software\Myapp. However, if you or a third party has created a custom .adm file that strays from the well-known keys, then those custom keys you modify won’t get cleaned up when the GPO is removed.
WINDOWS INSTALLER TECHNOLOGY AND THE REGISTRY
When discussing GPOs and software installation earlier in the chapter, I talked around the mechanisms that are used to actually deliver and install the applications. Let’s look now at how the Windows Installer technology interacts with the operating system and — most importantly — with the Registry.
To start with, there are two sides to software installation: the application install package itself and the Windows Installer service. The install package, often referred to as an MSI file (Microsoft Installer), is an integral part of software installation. In fact, with the exception of ZAP files I mentioned previously, you can’t publish or assign applications in the AD that haven’t been packaged using the MSI format. So, what is MSI? It is an API that defines how to configure and install software. Software vendors use the MSI API to write application-packaging tools whose created packages comply with the Windows Installer specification. Vendors such as InstallShield, Seagate, and Microsoft, for example, provide packaging tools that build MSI files with a consistent format. These application packages can then be published or assigned within a GPO.
Note: The version of the Windows Installer that ships with Windows 2000 is 1.1. The version of the Installer that shipped with the original Office 2000 package was 1.0.
An MSI file is itself a kind of database. An MSI file is referred to as Object Linking and Embedding (OLE) Structured Storage. OLE Structured Storage (OSS) is a way of putting more intelligence into a file that is otherwise a series of bits that are read sequentially. OSS files are composed of streams and storage objects. Streams correspond to files, and storage objects correspond to directories. In a way, an OSS file is really like a file system within a file system. That is, the MSI file is a single file on your NTFS partition, but applications that use that file can access different objects (i.e., streams and storage) within that file in an organized way. The advantages of OSS files are that you can keep richer information in a file. In the context of MSI, OSS provides a database of information within the file that describes an application. The database itself is composed of tables and columns, just like an Access or SQL Server database might be.
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
