Group Policy versioning
Well, I'm sitting here in the TechEd Technical Learning Center waiting patiently for someone to come by and ask me a question--so I thought I'd blog on an interesting discovery I made recently regarding Group Policy versioning. I had always thought, wrongly it turns out, that I knew how the GP engine figures out if a GPO has changed, and thus whether or not it needs to process a GPO. What I had thought was that, if the version number of a given GPO that was stored in the registry under the GP History keys (HKLM\Software\Microsoft\CurrentVersion\Group Policy\History) was less than the version number of the GPO as reflected in AD & SYSVOL, that that would constitute a changed GPO and thus GP would process that GPO. What I learned however, are two important nuances to that.
First, I learned that the GP version held in the registry doesn't have to be less than the version held in the GPC or GPT, it only has to be different. That is significant because it means that you could artificially tweak the version values in either the registry or the GPC and GPT up or downand this would still trigger a GP refresh (Note that the behavior I'm talking about here is only relevant for XP and greater). The GP engine just assumes that if there are any version differences between registry and server-side, it will just process GP anyway. This is also true if it finds version differences between the version number held in the GPC and that found in the GPT. If either is different than the version held in the registry, then GP is considered "changed" and is processed.
The second interesting thing I learned, with some good assistance from my friend Derek Melber, is that the version information held in the registry is not as straightforward as I once imagined. I had always thought at the version number held in the GP History and State keys (State is held HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\State) was simply the version number of the GPO, as found in the GPC's versionNumber attribute or in the gpt.ini file in the GPT. However, this is not true. The version number that you find in, say, the History key for machine-specific Administrative Template policy (e.g. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}\2) is really a much more interesting number than just the version of the GPO as found in the GPC or GPT. In fact, it stores not only the number of changes that have been made to either the computer or user side of the GPO but also whether or not the GPC and GPT are in sync with respect to their version numbers. For example, let's say that the version value for a GPO in the registry holds a hex value of 0x00220022. What does this mean? Well, it depends upon whether the registry value is under a machine or SID-based key, but let's assume the value is found in one of the machine-based keys. (e.g. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\GPO-List\1). What that number means is that the computer side of that GPO has had 22 changes. The listing of the number twice indicates whether or not the GPC and GPT are in sync, because each of their version numbers is queried when GP is processed. So the first 22 in that registry-based version number indicates the number of changes reflected in the version value in the gpt.ini file of that GPO in SYSVOL. The 2nd 22 indicates the number of changes reflected in the versionNumber attribute on the AD-based GPC object for that GPO. So when the GP engine processes policy, it derives the version number from the number of changes that have been made on a GPO, as stored in the registry, and uses that information to determine whether the GPO has changed or not. Simple! Well, not that simple since I didn't notice it until now. But it is nice that the version number in the registry also tells you whether or not the GPC and GPT was in sync during the last processing cycle.