Some time ago I’ve discussed with Jorge some disaster recovery scenarios. At the end of this MSN chat Jorge said – great topic for blog post, and here it is. As always he wrote excelent entry about it and I don’t want to repeat these informations. Anyone interested in how to recover deleted object from a bit old backup should read Jorge blog entry.
So about what I will talk here?? I have one more scenario which is not covered in Jorge post and which is a reason why I wrote a little introduction about Infrastructure Master and its role in domain.
So let’s consider following scenario: we are migrating object within the same forest between domain, from domain A to domain B. Regardless of tool used we are moving object with the same GUID and probably SID stored in sidHistory (but SID is irrelevant here). What we (or AD) have to do is to remove this object from source domain.
And here we have some problem – because we have moved this object it exists but in different naming context. We can’t delete it as it has the same GUID as source object. So how we (better to say AD) can solve it? Once again Infrastructure object plays important part here. A new instance of infrastructureUpdate object class is being created as a child of Infrastructure and instantly it is being deleted. Such object is being called proxy objects and it holds information about source and destination object which was a subject of intra domain move. These informations can be used by all other DCs in source domain (A) to remove information about this object from database.
So information about our source object is being removed from domain and we are happy ( Vincent, are we happy ?).
But something went wrong and we may want to bring this object back to the original state. So we are taking our backup media and following authoritative restore procedure we are recovering this object from our backup, reboot and … our object disappears from the domain right away. Maybe our version was to low … so we may want to recover it once again, increase version … reboot … gone again. What happens ???
Here Infrastructure Master and our proxy object is playing important role. Because this object (with the same GUID) exists in our forest IM is preventing, based on information from proxy update object, existence of old (source) object in original domain. When somebody will recover it from backup IM will delete it on basis of proxy update information. Are we in a deep … hole?
Not really, what we have to do is to migrate object back again from domain B to A (that’s why You should always keep sidHistory in migration scenarios … unless You are sure You will not need it). In such case we will have source object back in source domain and if we will maintain sidHistory we will have also SID back again in its token. Of course such move will result in creating proxy update object in domain B :).
And why object which is migrated back again is not being deleted by IM in domain A? Some additional information regarding object maintained in proxy (like epoch) are playing role here. But maybe it will be topic for another creeping story from AD land :).
BTW – You can check for existance of proxy update object through LDAP query or using repadmin.exe with /showproxy switch.