Share via

Another random AD change in SP1

  • Article

The other day over on activedir it was mentioned that in SP1 we added sidHistory to the list of attributes preserved on tombstones. I thought I’d mention this here, and provide some clarity around what actually changed, since there was some confusion around what we did and how we did it.

In looking at tombstone reanimation, we realized that sidHistory is particularly tricky to restore. For a variety of reasons, we enforce rules on the insertion of values in to sidHistory when using the proper APIs (like DsAddSidHistory()). That said, restoring this attribute to a previous state can be non-trivial.

Therefore, it makes sense to preserve this one on tombstones, such that if you reanimate a tombstone you get it back like it was before.

Normally when such changes are made, they are done in the schema. On each attribute definition, we have an attribute searchFlags, and within searchFlags there is a bit which tells the DS to preserve attributes on tombstones (0x8). So adding an element to this set of preserved attributes is as simple as flipping this bit.

Now I said “normally” above, because in this case, we didn’t do this. In addition to looking at searchFlags, there is actually a second mechanism by which we decide what to preserve on tombstones. We maintain a hard-coded list in the DSA code itself. I can’t authoritatively say why we did this (before my time) but I would speculate it is so that even a schema change which removes something we really need from this attribute set doesn’t cause us to enter a state which could be detrimental to the environment.

So, in SP1, we added sidHistory to that list of always preserved attributes.

Why did we add it to this list rather than changing searchFlags? Well, feedback has been that schema changes are painful, and that they slow adoption. Therefore, we clearly didn’t want to have a schema change associated with SP1. Further, this isolated the change to only SP1 DCs, which was desirable. You don’t have a forest wide change at one moment in time, but rather incrementally introduce this. While we don’t expect a problem (and haven’t seen one to date), it’s safer to always assume one is there and we just don’t know about it yet.

What’s the downside of doing this vs. changing searchFlags? Well, in making this change in the code vs. searchFlags, this means that you could have an inconsistent experience if you have a mix of DCs, some with SP1 and some without. Namely, if you delete an object on an SP1 DC, it will preserve sidHistory. But if you delete it on a non-SP1 DC, it won’t. We understand this isn’t ideal, but if you want to get this feature today w/o waiting for Longhorn and without making a schema change, this is the best we could do. :)

(Edit: fixed weird font thing)

Comments

  • Anonymous
    January 01, 2003
    PingBack from http://www.keyongtech.com/2845855-domain-controllers-at-different-sp

  • Anonymous
    January 01, 2003
    PingBack from http://stuart.amanzi.co.nz/2006/09/04/some-new-feeds-for-feeddemon/

  • Anonymous
    July 13, 2005
    Eric,

    What happens to non SP1 DC's when you reanimate a object on a DC SP1 machine that has the SIDHistory. Do those objects on the non SP1 DC's then appear to have their SIDHistory recreated?

    Thanks
    Carlos

  • Anonymous
    July 13, 2005
    Reanimation is independent of what's there. If you reanimate, no matter where you reanimate, it will be brought along. Non-SP1 DCs don't know why sidHistory is there, nor do they care. They'll just carry it along through the reanimation and it'll be preserved w/o issue.