Has anyone had success with this?
I have tried it on the DC with Master roles and the
util. responds with success. I'm just unable to find the object restored even after a serach of AD.
All the documentation I find on the net are pretty much just replays of the original article from SysInternals.
Discussion on:
View:
Show:
Active Directory Recover can be a minefield if you are not very careful in how you perform it.
Some thoughts and pointers from my experience:
During a typical file restore operation, Microsoft Windows Backup operates in non-authoritative restore mode. In this mode, Windows Backup restores all files, including Active Directory objects, with their original Update Sequence Number (USN) or numbers. The Active Directory replication system uses the USN to detect and replicate changes to Active Directory to all the domain controllers on the network. All data that is restored non-authoritatively appears to the Active Directory replication system as old data. Old data is never replicated to any other domain controllers. The Active Directory replication system updates the restored data with newer data from other domain controllers. Performing an authoritative restore resolves this issue.
Use an authoritative restore with extreme caution because of the effect it may have on Active Directory. An authoritative restore must be performed immediately after the computer has been restored from a previous backup, before restarting the domain controller in normal mode. An authoritative restore replicates all objects that are marked authoritative to every domain controller hosting the naming contexts that the objects are in. To perform an authoritative restore on the computer, you must use the Ntdsutil.exe tool to make the necessary USN changes to the Active Directory database.
There are certain parts of Active Directory that cannot or should not be restored in an authoritative manner:
You cannot authoritatively restore the schema.
The configuration naming context is also very sensitive, because changes will affect the whole forest. For example, it does not make sense to restore connection objects. Connection objects should be recreated by the Knowledge Consistency Checker (KCC) or manually. Restoring server and NTDS settings objects makes sense when no destructive troubleshooting was done before.
In the domain context, do not restore any objects that deal with relative identifier (RID) pools. This includes the subobject "Rid Set" of domain controller computer accounts and the RidManager$ object in the SYSTEM container.
Another issue is that many distinguished name-type links may break when you restore. This may affect objects that are used by the File Replication Service (FRS). These exist underneath CN=File Replication Service,CN=System,DC=yourdomain and CN=NTFRS Subscriptions,CN=DC computer account.
Attempts to authoritatively restore a complete naming context will always include objects that can disrupt the proper functionality of crucial parts of Active Directory. You should always try to authoritatively restore a minimal set of objects.
Finally, similar issues might exist for objects created by other applications.
A system state restore replaces all new, deleted, or modified objects on the domain controller that is being restored.
A system state restore of a naming context that contains two or more replicas is an authoritative merge. In an authoritative merge, all objects that are deleted or modified are rolled back to when the backup was made. Objects that were created after the backup are replicated from naming context replicas. An authoritative merge represents a merge of the state that existed when the backup was made with new objects that were created after the backup.
When you non-authoritatively restore a naming context that contains a single replica, you actually perform an authoritative restore.
The tombstone period for Active Directory is 60 days. Recovery isn't possible in the live production network after 60 days has elapsed.
Using the Microsoft Methodology, it will require multiple authoritative restores to recover nested group members in a security group
When a user, a computer, or a group is deleted from Active Directory, the following actions occur:
The deleted security principal is moved into the deleted objects container.
A number of attribute values, including the memberOf attribute, are stripped from the deleted security principal.
Deleted security principals are removed from any security groups that they were a member of. In other words, the deleted security principals are removed from each security group's member attribute.
When you recover deleted security principals and restore their group memberships, the key point to remember is that each security principal must exist in Active Directory before you restore its group membership. (The member may be a user, a computer, or another security group.) To restate this rule more broadly, an object that contains attributes whose values are back links must exist in Active Directory before the object that contains that forward link can be restored or modified.
Recovering the SYSVOL is a different process than recovering an object in Active Directory.
My personal advice is that you purchase, learn and use Quest (formerly Aelia) Recovery Manager for Windows and Active Directory. They have an excellent whitepaper on Active Directory recovery available here:
http://itpapers.zdnet.com/abstract.aspx?&scid=236&docid=78418
Just as a note of personal experience, a large automotive manufacturing corporation's European division accidentally managed to delete an Organizational Unit with 170,000 nested security groups. Using the Microsoft methodology it took about 96 hours to fully restore the objects. Using the Aelita Recovery Manager for AD, it took less than 4 hours (most of this was replication time) to restore the objects in a recreation of the incident. Their product isn't cheap, but it does indeed work very well. If you or others, needs a contact at Quest, please feel free to contact me via my Peer Listing, as I know the folks very well up there in Ohio!
Some thoughts and pointers from my experience:
During a typical file restore operation, Microsoft Windows Backup operates in non-authoritative restore mode. In this mode, Windows Backup restores all files, including Active Directory objects, with their original Update Sequence Number (USN) or numbers. The Active Directory replication system uses the USN to detect and replicate changes to Active Directory to all the domain controllers on the network. All data that is restored non-authoritatively appears to the Active Directory replication system as old data. Old data is never replicated to any other domain controllers. The Active Directory replication system updates the restored data with newer data from other domain controllers. Performing an authoritative restore resolves this issue.
Use an authoritative restore with extreme caution because of the effect it may have on Active Directory. An authoritative restore must be performed immediately after the computer has been restored from a previous backup, before restarting the domain controller in normal mode. An authoritative restore replicates all objects that are marked authoritative to every domain controller hosting the naming contexts that the objects are in. To perform an authoritative restore on the computer, you must use the Ntdsutil.exe tool to make the necessary USN changes to the Active Directory database.
There are certain parts of Active Directory that cannot or should not be restored in an authoritative manner:
You cannot authoritatively restore the schema.
The configuration naming context is also very sensitive, because changes will affect the whole forest. For example, it does not make sense to restore connection objects. Connection objects should be recreated by the Knowledge Consistency Checker (KCC) or manually. Restoring server and NTDS settings objects makes sense when no destructive troubleshooting was done before.
In the domain context, do not restore any objects that deal with relative identifier (RID) pools. This includes the subobject "Rid Set" of domain controller computer accounts and the RidManager$ object in the SYSTEM container.
Another issue is that many distinguished name-type links may break when you restore. This may affect objects that are used by the File Replication Service (FRS). These exist underneath CN=File Replication Service,CN=System,DC=yourdomain and CN=NTFRS Subscriptions,CN=DC computer account.
Attempts to authoritatively restore a complete naming context will always include objects that can disrupt the proper functionality of crucial parts of Active Directory. You should always try to authoritatively restore a minimal set of objects.
Finally, similar issues might exist for objects created by other applications.
A system state restore replaces all new, deleted, or modified objects on the domain controller that is being restored.
A system state restore of a naming context that contains two or more replicas is an authoritative merge. In an authoritative merge, all objects that are deleted or modified are rolled back to when the backup was made. Objects that were created after the backup are replicated from naming context replicas. An authoritative merge represents a merge of the state that existed when the backup was made with new objects that were created after the backup.
When you non-authoritatively restore a naming context that contains a single replica, you actually perform an authoritative restore.
The tombstone period for Active Directory is 60 days. Recovery isn't possible in the live production network after 60 days has elapsed.
Using the Microsoft Methodology, it will require multiple authoritative restores to recover nested group members in a security group
When a user, a computer, or a group is deleted from Active Directory, the following actions occur:
The deleted security principal is moved into the deleted objects container.
A number of attribute values, including the memberOf attribute, are stripped from the deleted security principal.
Deleted security principals are removed from any security groups that they were a member of. In other words, the deleted security principals are removed from each security group's member attribute.
When you recover deleted security principals and restore their group memberships, the key point to remember is that each security principal must exist in Active Directory before you restore its group membership. (The member may be a user, a computer, or another security group.) To restate this rule more broadly, an object that contains attributes whose values are back links must exist in Active Directory before the object that contains that forward link can be restored or modified.
Recovering the SYSVOL is a different process than recovering an object in Active Directory.
My personal advice is that you purchase, learn and use Quest (formerly Aelia) Recovery Manager for Windows and Active Directory. They have an excellent whitepaper on Active Directory recovery available here:
http://itpapers.zdnet.com/abstract.aspx?&scid=236&docid=78418
Just as a note of personal experience, a large automotive manufacturing corporation's European division accidentally managed to delete an Organizational Unit with 170,000 nested security groups. Using the Microsoft methodology it took about 96 hours to fully restore the objects. Using the Aelita Recovery Manager for AD, it took less than 4 hours (most of this was replication time) to restore the objects in a recreation of the incident. Their product isn't cheap, but it does indeed work very well. If you or others, needs a contact at Quest, please feel free to contact me via my Peer Listing, as I know the folks very well up there in Ohio!
To testing I ran adrestore and it listed 20-25 items. I ran adrestore -r and selected yes on a user account and n for the rest. Open up AD Users and Groups and that user was back with all its correct memberships.
Is it nessasary to install this Util on the DC or can it work remotely with the Mangement console?
I recommend either Quest Object Restore for AD or NetWrix AD Object Restore Wizard. Object restore wizard is cheper, but both do the job well.
Queston?
How do i restore a deleted user back to active directory with backup exec?
How do i restore a deleted user back to active directory with backup exec?
Thanks for the tip Smart Guy. I just downloaded netWrix active directory object restore wizard, it may have just saved my job 
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
