Authoritative restore of groups can result in inconsistent membership information across domain controllers (280079)
The information in this article applies to:
- Microsoft Windows Server 2003, Datacenter Edition
- Microsoft Windows Server 2003, Enterprise Edition
- Microsoft Windows Server 2003, Standard Edition
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Server
- Microsoft Windows Small Business Server 2003, Premium Edition
- Microsoft Windows Small Business Server 2003, Standard Edition
This article was previously published under Q280079 SYMPTOMS 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:
840001
How to restore deleted user accounts and their group memberships in Active Directory
Note KB article 840001 supersedes this article. CAUSE 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.
RESOLUTIONWarning: 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:
- Perform a full backup of the computer state to back up this
authoritative copy of Active Directory in case an error occurs during this
procedure.
- Disable both intra-site and inter-site topology generation.
For additional information about how disable
intra-site and inter-site topology, click the article number below to view the
article in the Microsoft Knowledge Base:
242780 How to Disable the Knowledge Consistency Checker From Automatically Creating Replication Topology
- Start the Active Directory Sites and Services snap-in, and
then delete all the connection objects under the NTDS Settings object for the
authoritative domain controller.
When you complete this step, the
domain controller is prevented from replicating any changes during this
procedure. The replication partners of the authoritative domain controller
still have connection objects that point to that server that enable them to
pull the authoritative data from the server. - Restart the computer into Active Directory Restore mode.
- Authoritatively restore each required account individually.
For example, to restore James Smith's user account in the Accounting
organizational unit in NWTRADERS.MSFT, use the following syntax:
authoritative restore: restore subtree "cn=James
Smith,ou=Accounting,dc=nwtraders,dc=msft"
Note: Because the Ntdsutil tool can be scripted, you can generate a
list of user accounts to be restored and then pass that to your script. A
sample script is described in the "More Information" section in this article.
You can also restore a whole OU here if it mostly contains users and
groups. - Restart the computer into Normal mode.
- Allow the restored users to replicate normally.
To force partners to replicate from the authoritative domain controller, use
either the ReplMon tool, or the Active Directory Sites and Services snap-in.
- When the users are replicated to all domain controllers,
restart the computer into Active Directory Restore mode.
- Authoritatively restore each group account that contained
the previously restored objects. For example, to restore the Web Administrator
group in the ITG organizational unit in NWTRADERS.MSFT, use the following
syntax:
authoritative restore: restore subtree "cn=Web
Administrator,ou=ITG,dc=nwtraders,dc=msft"
Note: Because the Ntdsutil tool can be scripted, you can generate a
list of groups to be restored and then pass that to your script. A sample
script is described in the "More Information" section in this article.
- Restart the computer into Normal mode.
- Allow the restored groups to replicate normally.
To force partners to replicate from the authoritative domain controller, use
either the ReplMon tool, or the Active Directory Sites and Services snap-in.
- Undo the changes on the site object that you made in step
two of this procedure.
STATUSMicrosoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
Modification Type: | Major | Last Reviewed: | 4/29/2004 |
---|
Keywords: | kbprb KB280079 |
---|
|