A:
Windows XP introduces quite a few new Group Policy Object (GPO)-based Administrative Template settings as well as some new policy functionality—such as software-restriction policies. If you’re deploying Windows XP clients in a Windows 2000 (Win2K)-based Active Directory (AD) domain, you can “upgrade” your AD-based GPOs to support the new policies. Remember that the actual processing “smarts” behind a GPO are stored in so-called Client Side Extensions (CSEs) on the workstation or server that is processing the GPO. As such, it makes complete sense that Windows XP comes with newer or more capable policies than those found in Win2K. So if you want to deploy Windows XP in your existing Win2K AD domain, how do you take advantage of those new policies without breaking policy on your Win2K machines? It’s quite simple really.The first thing you need to do is to be able to open GPOs using the standard Microsoft
Management Console (MMC) snap-ins that you are used to in Win2K. Unfortunately, the server management tools, such as Active Directory Users and Computers and AD Sites and Services that are part of the Win2K Administration Tools Pack, no longer work in Windows XP. As of this writing, the only way you can manage AD-based GPOs on a Windows XP machine is to download and install the .NET Server Beta 3 Administration Tools Pack .MSI file from Microsoft’s Web site.
The .NET Server Beta 3 administration tools for Windows XP can be found at
http://www.microsoft.com/downloads/release.asp?ReleaseID=34032&area=search&ordinal=9. After you’ve installed the Beta 3 administration tools, you’re ready to convert your existing AD- based GPOs into Windows XP–capable policies. The process is very straightforward. All you need to do to upgrade your GPOs, is to open each GPO in your AD domain using the Group Policy MMC snap-in tool running on a Windows XP workstation. The act of opening the GPO upgrades it to be able to support Windows XP–based policies; at the same time, your Win2K policies are still intact. You need to perform this GPO open process on every GPO within your AD domain that you want to support XP clients.
What’s happening behind the scenes during this process is pretty straightforward. Remember that the Group Policy Template (GPT) portion of a GPO holds the actual files and settings that
represent the current policy that has been set. When you open a GPO using Windows XP, Windows XP uploads the newer .adm Administrative Template files into the Adm folder within the GPT for that GPO (see Figure 7.17).
Figure 7.17: Viewing the Adm folder within a GPO’s GPT.
This process of opening the GPO automatically enables Administrative Template policy that is Windows XP–specific to be set within that GPO. Windows XP introduces the SUPPORTED tag into Administrative Template .adm files. This tag lets the client determine whether the policy is meant for its version of the OS or a newer one. If you try to set an Administrative Template policy that is only meant for Windows XP but that is processed by Win2K workstations, the individual policy item (not the entire GPO) will simply be ignored.
Another thing to keep in mind is that after you’ve upgraded your GPOs to be Windows XP– capable, you aren’t limited to editing them on Windows XP clients. You can continue to edit them using either Win2K or Windows XP administration tools.
Q 7.7: How is Group Policy Object history stored and used on the
client?
A:
The default behavior of Group Policy Object (GPO) processing is that a client will not process a GPO if the GPO has not changed since the last processing time. But how does the client know whether the GPO has changed? The answer is that the client knows by using GPO History.GPO History is nothing more than a set of keys and values in the registry on Windows 2000 (Win2K) and Windows XP systems in which a history of GPO processing is kept. This history is stored both a per-user and per-computer basis, corresponding to the fact that GPOs have both computer- and user-specific parts. The per-computer history can be found in the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History subkey. And the per-user history is in the corresponding key in
HKEY_CURRENT_USER:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History. Under the History keys, you fill find a number of GUID-named keys. These keys correspond to the various client-side extensions (CSEs) that implement policy on a given machine. You can cross-reference these CSE GUIDs to the actual policy function they provide by looking in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPExtensions subkey. Under each GUID-named key is the
numerically named subkeys that correspond to each GPO that the computer or user has processed for a given CSE (see Figure 7.18).
Figure 7.18: Viewing the contents of GPO History stored in the registry on a Win2K computer.
In Figure 7.18, the keys named 0 and 1 under each CSE key correspond to the GPOs that have been processed by this computer. If I select one of these numbered folders, I can see more detail about the GPO and its version when last processed. Figure 7.19 shows what this looks like.
Figure 7.19: Viewing the detailed history information for the last processing of a GPO.
What Figure 7.19 shows:
• This system ran the Scripts CSE (defined by the GUID in the left pane beginning with {42B5F…) against the Default Domain Controllers policy.
• The DSPath value points to the Machine folder underneath the Group Policy Container (GPC) for this GPO and the FileSysPath value points to the Machine folder within the Group Policy Template (GPT) for this GPO.
• The Extensions value lists all the CSEs that are implemented within this particular GPO (that is, which types of policy have been set in the GPO) by their CSE GUID.
• The GPOLink value describes where in AD or on the local computer this particular GPO was linked to when it was processed. The number 4 corresponds to an OU-linked GPO. A number 1 in this value corresponds to the local GPO, 2 to a site-linked GPO, and 3 to a domain-linked one.
• The GPOName is, of course, the friendly name of this GPO.
• The Link value shows the full AD path to where this GPO was linked when it was processed—in this case, to the Domain Controllers OU.
• IParam is an optional value that is used by some CSEs.
• The Options value shows whether No Override or Disabled flags have been enabled for this GPO.
• The Version value shows the current version of this GPO. This is the version number stored in the GPT and GPC, not the number of revisions on the GPO. This version number is key because it helps the user or computer know whether the GPO has changed on subsequent processing cycles. If it has not changed and the default processing
behavior has not been modified, the GPO will be skipped for this CSE until the version number does change.
As you can imagine, the per-user and per-computer history keys provide a valuable service not only in determining whether a GPO has changed from the last processing cycle, but also in helping Win2K and Windows XP know when a GPO no longer applies to the user or computer. In this case, policy settings that no longer apply can successfully be removed during the next policy processing cycle.