I have a small development environment with two Windows domain controllers. One rebooted during patch installation about three weeks ago and came up in Safe Mode. Nobody noticed because this is only a lightly used lab, and the server is protected by Veeam.
I'm not sure whether a patch caused the issue, whether Veeam's application-aware Active Directory processing left a recovery or Safe Mode setting behind, or whether both events happened together. Since the affected domain controller has been offline from normal operation, it has not replicated with the other controller for three weeks.
Before I clear the Safe Mode setting and reboot, is there anything specific I should check or be concerned about? I'd like to handle this as though it were production so I can document the correct procedure, even though this environment is small and disposable.
5 Answers
If the server needs to be restored from backup, use a non-authoritative domain controller restore so the healthy controller remains the source of current directory data. A fresh replacement may be even simpler for this lab, but make sure the backup product is not leaving boot or directory-recovery settings enabled after application-aware processing.
There is no longer a primary and secondary domain controller distinction in modern Active Directory. Multiple domain controllers are peers, although FSMO roles are assigned to particular servers. Assuming this is a normal writable domain controller and not an RODC, clearing the Safe Mode condition and rebooting is reasonable. Check replication with the usual health and event-log tools once it is online.
A domain controller is generally easy to replace. If the affected server continues having problems, demote or remove it as cleanly as possible, clean up its metadata on the healthy controller, and promote a fresh server. In a development environment, rebuilding is often safer and faster than trying to preserve a questionable installation.
After only three weeks, replication should normally be recoverable. Bring the domain controller back into normal mode and monitor the boot, Directory Services logs, and replication status afterward. Since this is a tiny development domain with very few changes, the risk of a large replication conflict is low. If it fails to boot normally or replication does not recover, treat it as a failed domain controller and rebuild it rather than spending too much time repairing it.
If you do rebuild it, remove the failed controller cleanly where possible and perform metadata cleanup on the healthy controller before promoting the replacement.
The small number of objects makes this a good controlled test. Record the current boot configuration, clear only the Safe Mode setting, reboot, and then verify DNS, Active Directory services, replication partners, and event logs. Do not assume that a successful boot means replication is healthy.
That makes sense here. The environment only has a handful of users and computers, so rebuilding is a practical fallback. I mainly want to determine whether the backup workflow could cause this before testing it in production.