I don’t do a whole lot of playing with AD Backup/Restore ops and authoritative restores, I am a big fan of building systems such that they don’t allow people to delete objects accidentally in the first place. However, I have been working on a project that has as a portion of the work some user migrations within a forest. One of the things we need to account for is the case where we move a user and for some reason or other they have some app that just absolutely not work once they are moved; we need to put the user back exactly as they were before…
Again I don’t play with auth restores and I never have tried to auth restore a user who has been moved across domains. So here is what I did…
- Create two domains D1 and D2
- Create in D1 an OU structure of accounts/incoming
- Create in D2 an OU structure of accounts/migrate
- Create 20 users in D2 in the migrate OU
- Backup systemstate on D1 and D2
- Use ADMT or AdMod to crossdom move 10 users from D2/accounts/migrate to D1/accounts/incoming
- Verify LCS/Exchange/etc works normally
- Delete 5 of the migrated users
- Come up in DSRM on D2
- Restore systemstate
- auth restore the 5 users that were deleted
- Reboot D2 DC.
What happened? Users were there when the system first came up, as soon as it started replicating they disappeared… Seems AD was smart enough to realize that the users I auth restored existed as tombstones in D1 which means duplicate GUIDs and to protect itself it zilched out the auth restored user objects. I had no idea that would happen. Actually I had no idea what would happen so I was wide open to anything it might do from refusing to replicate to asking me to somehow straighten out the conflict.
So from that I quickly came up with a strategy, instead of deleting the object in D1 and auth restoring, migrate the users back to the original domain (again ADMT or AdMod should work for a simple cross dom move) and then auth restore them. If you have gotten stuck in the spot already then you need to undelete the objects on D1 and then migrate them back and auth restore them.
joe
We have a (very complicated) mechanism that deals with this. This is an explicitly tested and coded scenario, and quite frankly it’s what makes cross-domain move SO hard.
Cool thanks for the info Eric.
This is a particularly nasty issue. Rollback for intraforest is not auth-restore, but re-migrate from target->source. If you delete the objects in target, then restore in source, they just get deleted 🙂