When a VM guest that contains an Active Directory Domain
Controller (AD DC) is restored with Data Protection for VMware, the
DC (on that VM) is restored from a backup copy of the AD database.
Before you begin
The original VM must be powered off before the restored VM
is started. In addition, the restored VM must be manually rebooted
for replication to occur.
About this task
The following tasks occur upon a successful
Data Protection for VMware restore
and subsequent reboot of the VM guest that contains the AD DC:
Procedure
- The DC is updated from a backup copy of the AD DC database.
A new invocationID is assigned to the Directory Server.
This update is indicated by event 1109 in the event
log on the VM guest. To verify this update:
- In the Computer Management window
on the restored system, go to .
- When the AD DC restored successfully, the Information type
event for the restored DC displays the following message:
ActiveDirectory 1109 Replication
The
message in the Event Viewer also confirms a successful restore because
of the changed invocationID attribute:The invocationID attribute for this directory server has been changed.
The highest update sequence number at the time the backup was created is <time>
InvocationID attribute (old value):<Previous InvocationID value>
InvocationID attribute (new value):<New InvocationID value>
Update sequence number:<USN>
The InvocationID is changed when a directory server is restored from backup media
or is configured to host a writeable application directory partition.
- The restored DC replicates itself non-authoritatively with
its replication partners in the network. It is updated with the most
current domain, schema, configuration, and application partitions:
Note: Data Protection for VMware does
not support authoritative restore.
- Log in to the VM guest that was restored by using Data Protection for VMware as an
Administrator.
- Open a Windows command prompt.
- Check the status of the last replication that involved
the restored DC by issuing the repadmin /showrepl command1. This command shows the replication partners for each
directory partition on the DC and the status of the last replication.
If the replication schedule did not start, you can manually
start the replication operation. Go to the Active Directory
Sites and Services, select the replication partners, and
right-click Replicate Now.
For detailed
information about initiating replication, see the following Microsoft
Knowledge Base article:
http://support.microsoft.com/kb/232072
When
the status is newer than the restore time, this status means that
the replication was successful and completed automatically. The
following output shows that replication was successful:
Repadmin: running command /showrepl against full DC localhost
Default-First-Site-Name\DC12012
DSA Options: IS_GC
Site Options: <none>
DSA Object GUID: 8393da24-f18b-453a-b197-b8dc6956d51f
DSA invocationID: 8393da24-f18b-453a-b197-b8dc6956d51f
==== INBOUND NEIGHBORS ===============================
CN=Configuration,DC=his,DC=local
Default-First-Site-Name\DC22012 via RPC
DSA Object GUID: 790c6f2d-61f1-4704-bdcf-6ef731bcb96e
Last attempt @ 2013-01-25 14:33:10 was successful.
When
the repadmin /showrepl command displays a successful
replication, the AD DC replication is considered successful. No additional
tasks are required.
- When the repadmin /showrepl command
shows that replication was not successful, output similar to the following
is shown:
Repadmin: running command /showrepl against full DC localhost
Default-First-Site-Name\DC12012
DSA Options: IS_GC
Site Options: <none>
DSA Object GUID: 8393da24-f18b-453a-b197-b8dc6956d51f
DSA invocationID: 8393da24-f18b-453a-b197-b8dc6956d51f
==== INBOUND NEIGHBORS ===============================
CN=Schema,CN=Configuration,DC=his,DC=local
Default-First-Site-Name\DC22012 via RPC
DSA Object GUID: 790c6f2d-61f1-4704-bdcf-6ef731bcb96e
Last attempt @ 2013-01-25 14:30:32 failed, result 1908 <0x774>:
Could not find the domain controller for this domain.
1 consecutive failure(s).
Last success @ 2012-12-14 15:01:36.
If a replication
failure exists or persists, follow the instructions provided in the
next section.
Recover from Replication Failures
Use the following
methods to investigate the cause of a persistent replication failure:
- Use the Microsoft Domain Controller Diagnostics tool (dcdiag.exe)
to view information about all components, objects, and permissions
that are required for successful replication. For example:
- Open a Windows command prompt as an administrator.
- Issue the dcdiag /test:replications command.
Use the output information to resolve any issues. If the command fails,
investigate the events that are at .
- Use the Microsoft Repadmin.exe command-line
tool to view the retired invocationID on a DC. For
example:
- Open a Windows command prompt as an administrator.
- Issue the repadmin /showsig [DC_LIST] command.
This output shows that restore from Tivoli® Storage
Manager was successful
because a retired invocationID exists:
C:\Users\Administrator>repadmin /showsig rodc
Default-First-Site-Name\RODC
Current DSA invocationID: ed8ea6b9-d347-4695-b886-b5128be280c4
2c995946-2389-4d98-bc78-3708ba906e01 retired on 2012-12-19 16:56:21
at USN 17703
When the output contains the statement No
retired signatures, the AD was not restored from Tivoli Storage
Manager correctly.
As a result, replication cannot be completed because the partner DCs
mistake the new invocationID as evidence for a completed
replication. For example:C:\Users\Administrator>repadmin /showsig rodc
Default-First-Site-Name\RODC
Current DSA invocationID: ed8ea6b9-d347-4695-b886-b5128be280c4
No retired signatures
When the invocationID is
retired, the replication can be started. However, this statement does
not guarantee success of the replication.