Someone emailed a question to the GPOGUY GPTalk mailing list today that I thought was worth chatting about. The question pertained to disappearing Group Policy links. Namely, he had a situation where links to GPOs would periodically disappear from Active Directory containers. I thought this was interesting as it brings up one of the poor design decisions that MS made around this particular facet of Group Policy. Specifically, Group Policy links are stored within the gpLink attribute on an AD container (in the case of GP, the container is a site, domain or OU object). But its how they are stored that is the problem. Links are stored as a concatenated list of strings that specify the DN of the groupPolicyContainer object in AD. In addition, the state of the link (e.g. enforced, disabled, enabled) is also stored as a flag within this string. For example, an OU’s gpLink attribute with multiple GPOs linked to it would look something like this:
Each link is delimited by brackets (). The flags that control the behavior the behavior of the link follow the DN and are delimited by semi-colons (;). So, what’s wrong with this picture??
Well, think about the problems that MS had with AD security group membership when they shipped Windows 2000. Group memberships were stored in AD such that someone making a change to a group’s membership on one DC could overwrite a membership change happening on another DC, because the membership was treated as a single object. You had to be really careful about where you modified memberships. Then MS introduced linked value replication (LVR) and that problem basically went away.
Well you have the same problem here with GP links except its a bit worse. Group memberships in AD are stored as links–i.e. they are references to member objects rather than just strings of member names. Not so with GP links, which have no association to the underlying GPO they reference. So, you have two problems here–one not so big and one really big. The not so big problem is that if you want to find out where a particular GPO is linked, you have to search every container object and do string matching to find that GPO’s DN on the container. That’s a pain but not terrible unless you have really big environments. The bigger problem is around making link changes. Because all links are held in essentially one big long string on the gpLink attribute, if two people make a link change on the same container from two different DCs, the last writer will overwrite the first writer completely. Meaning that if Admin A removes a GPO link or disables a link, and then Admin B comes along shortly thereafter, before Admin A’s changes have replicated, and makes another change, the GPO link that Admin A removed or modified will be get replicated back because Admin B’s change comes later.
Obviously GPMC mitigates this issue somewhat by defaulting to always focus on the PDC emulator, but you can tell it to make changes against different DCs, and that’s where problems can occur. It would have been much better if MS hade made the gpLink attribute store links to GPO objects rather than strings.
As for tools for managing GPO links, besides GPMC, I will of course mention the free PowerShell GPMC cmdlets we have, that include get-sdmgplink, add-sdmgplink and remove-sdmgplink for managing links. In all cases, those cmdlets will default to the PDC emulator DC to make changes.
SDM Software is also getting ready to release a Group Policy backup and recovery product and one of its features will be the ability to backup and recover GPO links!