Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
Authoritative restore of groups can result in inconsistent membership information across domain controllers
Article ID: 280079 - View products that this article applies to.
This article was previously published under Q280079
After you perform an authoritative restore of users and groups, the membership in the restored groups may be inconsistent across domain controllers.
If the group is empty on the restored domain controller, but is populated on a replica domain controller, then when a user is added to the group on the restored domain controller, users are removed from the group on the replica domain controllers.
The same behavior may occur with the ManagedBy attribute, which may be empty after an authoritative restore.
For additional information about these types of issues, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/840001/ )How to restore deleted user accounts and their group memberships in Active Directory
Note KB article 840001 supersedes this article.
This issue can occur because group membership is stored as the Member attribute on the group object. When a security principal (user, group, or computer) is added to a group, a backlink is added to the MemberOf attribute on the principal's object. During an authoritative restore, if the group object is restored before the user object, then Active Directory removes the value from the Member attribute on the group because a user does not exist that has a matching backlink.
After the authoritative restore, the version information on the Member attribute of the restored groups is consistent on each domain controller, even though the values in that attribute are not. Whenever the membership of the group is modified, the version number is incremented, and the contents of that group are replicated out to all domain controllers. If the group is modified on a domain controller that has a valid group membership, then the complete contents of the group are replicated, and data is not lost. However, if the group is modified on the restored domain controller, then only the added users are replicated, and users are removed from the group on the replica domain controllers.
Note This issue may occur even if the users are authoritatively restored and the groups are not. If a System State restore is done and only users are marked as authoritative, their group membership will be restored on the domain controller that the restore was done on (because the forward links in the group objects would have been restored in the System State restore). If the membership of the groups has not changed since the System State backup was done, no replication for the groups will be done after the restore. This results in inconsistent group membership between domain controllers. Changing the membership to the group on one domain controller will replicate the current contents of that group on that domain controller to the other domain controllers.
Warning: Read the following information carefully before you perform the procedure described in this section. User and group information can be irretrievably lost if you do not follow this procedure exactly. Remember to make and verify a backup file of Active Directory on the authoritative domain controller before you proceed.
To resolve this issue, all security principal objects (users, groups, and computers) must be authoritatively restored and replicated out to all domain controllers, and then all group objects must be authoritatively restored and replicated out to all domain controllers again. When you use this procedure, all potential group members (users, groups, and computers) are in the database before the second restore, and the backlinks are maintained.
When you authoritatively restore user accounts and their group memberships, find a domain controller with sufficient information to be marked as authoritative, and then disconnect that domain controller from the network. This server becomes the authoritative domain controller.
To resolve this issue:
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
After the authoritative domain controller has been unplugged from the network, you can run the following script before the computer is started into Active Directory Restore mode to get the list of users:
Note: Make sure that you change the organizational unit path in the first line to point to the path that contains the users and groups to be restored. Also, you can use this same script to create a list of either users or groups.
List.vbs -------- Set strOU = GetObject("LDAP://localhost/ou=layer two,ou=layer one,ou=test,dc=i,dc=j,dc=com") strOU.Filter = Array("user") For Each Member in strOU Wscript.Echo Chr(92) & Chr(34) & member.distinguishedname & Chr(92) & Chr(34) Next
To list groups, change the filter in the second line to:
To run this script and get the output to a text file, type the following command at the command prompt (run this command in the same folder as the script):
cscript //nologo list.vbs > users.txtAfter you have created the list of users and the list of groups, you can use Ntdsutil to authoritatively restore each entry:
To run this script for every entry in the list of users or groups, use the for command to read the entry in the list and pass it to the batch file described earlier. Type the following command at the command line (create these files in the same folder as the two text files that you created earlier):
Authrest.cmd ------------ @echo off ntdsutil "popups off" "authoritative restore" "restore subtree %1" quit quit
for /f "tokens=*" %i in (users.txt) do authrest %iThis command loops through each line of the text file and authoritatively restores the user.
Article ID: 280079 - Last Review: December 3, 2007 - Revision: 11.4