On the surface, everything appeared normal. The domain controller was running, Active Directory Domain Services was operational, users were authenticating successfully, and there were no warnings in the Directory Services event logs. The system gave no indication that anything was wrong.
The problem only revealed itself when I attempted to create an Install From Media (IFM) backup using ntdsutil ifm. That's when ntdsutil informed me that the database had experienced a dirty shutdown and needed recovery.
If you are curious and would like to investigate if you have this problem you can run the command below to confirm this:
ntdsutil "activate instance ntds" ifm "create full c:\temp\ifm_test nodefrag" quit quit
This is the insidious nature of dirty shutdown conditions: because the database is already mounted and Active Directory is running, Windows doesn't immediately flag the problem. The real danger lies in what happens next—if I had rebooted the server at that point, NTDS would likely have failed to mount the database entirely, leaving me with a non-functional domain controller holding all the FSMO roles.
Decision Tree
This is a visual of this guide, based on a small domain where you will be moving/seizing the FSMO roles at the same time.
Understanding the Critical Decision Point
When you discover a dirty shutdown on a FSMO role holder, you face a critical fork in the road. The decision you make at this moment determines whether you'll have a smooth recovery or a crisis.
Option 1: Reboot and Attempt Soft Recovery (The Risky Path)
The instinctive response might be to reboot into Directory Services Restore Mode (DSRM) and attempt a soft recovery. This approach uses esentutl /r to replay transaction logs and bring the database back to a clean state—it's non-destructive and should be the first recovery attempt when needed.
However, here's the critical risk: Once you commit to rebooting, if the soft recovery fails, Active Directory won't start and your FSMO role holder is offline. At that point, your only option is to seize the FSMO roles onto another domain controller. Seizing roles is an emergency operation that should only be performed when the original role holder will not be brought back online, and it's inherently more disruptive than a graceful transfer.
In other words: if soft recovery fails after reboot, you've lost the ability to gracefully transfer FSMO roles.
Option 2: Transfer FSMO Roles First (The Safe Path)
The safer approach—and the one I recommend—is to proactively transfer the FSMO roles to another healthy domain controller before you reboot the problematic server.
Role transfer is a cooperative, graceful handoff where the current FSMO owner communicates with the target domain controller, updates replicate normally, and directory consistency is maintained. This requires the source DC's Active Directory service to be running and accessible on the network.
The advantage of this approach:
- FSMO roles move gracefully to another DC
- Replication maintains consistency across the environment
- If the dirty-shutdown DC fails to start after reboot, you only need to worry about restoring or rebuilding that one server—not managing a forest-wide role seizure
- You remove the single point of failure before attempting any risky recovery operations
My Decision-Making Framework
Here's the decision tree I follow when discovering a dirty shutdown on a FSMO role holder:
1. Is Active Directory currently running and responding?
- Run
dcdiag /vandrepadmin /showreplto verify AD health - Confirm that replication is working properly
2. If AD is operational:
- Transfer FSMO roles immediately to another healthy DC
- Verify the transfer completed successfully
- Document the new role holder
- Only then consider recovery operations on the original DC
3. If AD is not operational or has already failed:
- You have no choice but to seize the FSMO roles
- Follow proper seizure procedures
- Ensure the failed DC never returns to the network without proper cleanup
How to Transfer FSMO Roles Before Recovery
Since my domain controller was still operational despite the dirty shutdown, I chose to transfer the roles. Here's the process:
Step 1: Verify Current State
# Check AD health
dcdiag /v /c /d /e > C:\Temp\dcdiag.log
repadmin /showrepl > C:\Temp\repl.log
# Verify current FSMO role holders
netdom query fsmo
Step 2: Choose a Target DC
Select a healthy domain controller that is:
- Up-to-date with replication
- Properly patched
- Ideally a Global Catalog server
Step 3: Transfer All Five Roles Using PowerShell
Small Domain
If you have a small domain then you can use PowerShell to move all the roles (this will require Domain Admins, Enterprise Admins and Schema Admins)
# Transfer all five FSMO roles to the target DC
Move-ADDirectoryServerOperationMasterRole -Identity "TargetDC" -OperationMasterRole 0,1,2,3,4
Where the roles are:
- 0 = PDCEmulator
- 1 = RIDMaster
- 2 = InfrastructureMaster
- 3 = SchemaMaster
- 4 = DomainNamingMaster
Larger Domains
If you have a larger domain with multiple sites and geographically dispersed domain controllers then you may wish to move the FSMO roles is the last impacting first and confirm the data before and after the move, lets look at that now. (for health checks, in orange see Step 3a - below - before you run the other commands)
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
repadmin /replsummary
Get-ADReplicationFailure -Scope Site
Move-ADDirectoryServerOperationMasterRole -Identity "BearDC2" -OperationMasterRole Schema
Get-ADForest | Select-Object SchemaMaster
Move-ADDirectoryServerOperationMasterRole -Identity "BearDC2" -OperationMasterRole DomainNamingMaster
Get-ADForest | Select-Object DomainNamingMaster
Move-ADDirectoryServerOperationMasterRole -Identity "BearDC2" -OperationMasterRole RIDMaster
Get-ADDomain | Select-Object RIDMaster
Move-ADDirectoryServerOperationMasterRole -Identity "BearDC2" -OperationMasterRole PDCEmulator
Get-ADDomain | Select-Object PDCEmulator
Move-ADDirectoryServerOperationMasterRole -Identity "BearDC2" -OperationMasterRole InfrastructureMaster
Get-ADDomain | Select-Object InfrastructureMaster
Step 3a - Pre-Move : Health Check and Results
It is important to ensure that your Domain Controller are healthy before we proceed to moving these FSMO rules, so lets break these commands down, first we have commands to see where the FSMO roles are currently located:
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMasterThen we need to check the replication status of all the Domain Controllers with the command below:
repadmin /replsummaryThis will the give you a view of the replication status, this can be seem below, here we need to ensure that the "fails" column is zeroed:
Beginning data collection for replication summary, this may take awhile:
............
Source DSA largest delta fails/total %% error
BearDC1 55m:34s 0 / 10 0
BearDC2 11m:27s 0 / 5 0
BearDC3 57m:18s 0 / 5 0
BearDC4 08m:33s 0 / 10 0
Destination DSA largest delta fails/total %% error
BearDC1 57m:19s 0 / 5 0
BearDC2 07m:11s 0 / 5 0
BearDC3 55m:35s 0 / 10 0
BearDC4 06m:05s 0 / 10 0Get-ADReplicationFailure -Scope Site | Select Server,FailureType,FailureCountServer FailureType FailureCount
------ ----------- ------------
BearDC4.bear.local Link 0
BearDC4.bear.local Link 0
BearDC3.bear.local Link 0
BearDC3.bear.local Link 0
BearDC3.bear.local Link 0
BearDC3.bear.local Link 0
BearDC1.bear.local Link 0
BearDC1.bear.local Link 0
BearDC2.bear.local Link 0
BearDC2.bear.local Link 0Step 4: Post Commands : Verify the Transfer
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
repadmin /replsummary
repadmin /showrepl
Get-ADReplicationFailure -Scope Site
Critical: Reconfigure NTP After Transferring PDC Emulator
Before proceeding with any recovery operations, there's one critical post-transfer task: reconfiguring the NTP time source.
The domain controller holding the PDC Emulator role serves as the authoritative time source for the entire domain. When you transfer the PDC Emulator role to another DC, the NTP configuration does not automatically follow the role, you may wish to follow the article here for more detail.
On the New PDC Emulator
Configure it to sync with an external NTP source and make it reliable:
w32tm /config /manualpeerlist:"<ntp-source>,0x1" /syncfromflags:MANUAL /reliable:yes
w32tm /config /update
w32tm /resync
w32tm /resync /rediscover
On the Old Server (the one not a PDC anymore)
You then need to make this original NTP source unreliable so it not used by Active Directory:
w32tm /config /reliable:no /update
net stop w32time
net start w32timeThen on all the other domain controllers you then need to update that configuration as well to point at the new NTP source:
w32tm /config /syncfromflags:DOMHIER /update
net stop w32time & net start w32time
w32tm /resync /force
w32tm /query /source
After Transfer: Safe Recovery Options
Now that the FSMO roles are safely on another domain controller and NTP is reconfigured, you can address the dirty shutdown without the pressure of forest-wide implications.
Option A: Attempt Soft Recovery in DSRM
Reboot into Directory Services Restore Mode
- Press F8 during startup
- Select "Directory Services Restore Mode"
- Log in with DSRM credentials
Perform Soft Recovery
The correct first step is always soft recovery, which replays transaction logs non-destructively:
esentutl /r edb /l "C:\Windows\NTDS" /s "C:\Windows\NTDS"
Where:
/r edb= soft recovery with log prefix "edb"/l= path to log files/s= path to system files
- If Soft Recovery Succeeds
- Reboot normally
- Verify Active Directory starts
- Check event logs for any errors
- Confirm replication is working
Option B: Hard Recovery (Last Resort Only)
If soft recovery fails and logs cannot restore the database, hard recovery using esentutl /p is the last resort. Microsoft explicitly warns that this repair is destructive and deletes data from the database to fix corruption.
Only use hard recovery if absolutely necessary:
esentutl /p "C:\Windows\NTDS\ntds.dit"
esentutl /g "C:\Windows\NTDS\ntds.dit"
esentutl /d "C:\Windows\NTDS\ntds.dit"
Where:
/p= repair (destructive, discards corrupted pages)/g= integrity check/d= offline defragmentation
After using esentutl /p for repair, Microsoft recommends rebuilding the domain controller from scratch rather than continuing to use it in production, as the data loss may cause unpredictable problems later.
Option C: Rebuild the DC
Given that FSMO roles are now safely on another DC, the cleanest option might be:
- Demote the problematic DC (if possible)
- Format and reinstall
- Promote as a new domain controller
- Let replication bring it up to date
If Recovery Fails: Seizing FSMO Roles
If you attempted soft recovery first but it failed, and the domain controller cannot mount its database, you'll need to seize the FSMO roles. This is the emergency path you're forced into when the original role holder cannot be brought back online.
Understanding RID Pool Increment During Seizure
Critical: When you seize the RID Master role, the system automatically increments the next available RID pool to prevent duplicate Security Identifiers (SIDs). This is a safety mechanism to avoid conflicts.
This "RID burn" is intentional—it creates a buffer zone to ensure that if any objects were created on the failed DC using RIDs from its pool, those RIDs won't conflict with objects created on the new RID Master. While this consumes available RID ranges more quickly, it's a necessary trade-off to maintain directory integrity.
Important: After seizing any FSMO role, the original role holder must never be brought back online without proper cleanup. Having two domain controllers both claiming the same FSMO role will cause serious Active Directory issues.
Seizing FSMO Roles Using PowerShell
If soft recovery has failed and the DC won't start, seize all five roles to the healthy DC:
# Seize all five FSMO roles
Move-ADDirectoryServerOperationMasterRole -Identity "TargetDC" -OperationMasterRole 0,1,2,3,4 -Force
The -Force parameter performs a seizure instead of a transfer. You'll be prompted to confirm each role, this will also address the RID increment by 30,000.
Or seize roles individually:
Move-ADDirectoryServerOperationMasterRole -Identity "TargetDC" -OperationMasterRole PDCEmulator -Force
Move-ADDirectoryServerOperationMasterRole -Identity "TargetDC" -OperationMasterRole RIDMaster -Force
Move-ADDirectoryServerOperationMasterRole -Identity "TargetDC" -OperationMasterRole InfrastructureMaster -Force
Move-ADDirectoryServerOperationMasterRole -Identity "TargetDC" -OperationMasterRole SchemaMaster -Force
Move-ADDirectoryServerOperationMasterRole -Identity "TargetDC" -OperationMasterRole DomainNamingMaster -Force
Seizing FSMO Roles Using NTDSUTIL
Alternatively, use ntdsutil:
ntdsutil
roles
connections
connect to server TargetDC
quit
seize schema master
seize naming master
seize rid master
seize pdc
seize infrastructure master
quit
quit
Post-Seizure Cleanup
After seizing roles, you must perform metadata cleanup for the failed DC:
ntdsutil
metadata cleanup
connections
connect to server HealthyDC
quit
select operation target
list sites
select site <site number>
list servers in site
select server <server number>
remove selected server
quit
quit
Confirm the metadata cleanup in Active Directory Sites and Services to ensure all references to the failed DC are removed.
Verify Role Seizure
# Confirm new role holder
netdom query fsmo
# Verify AD health
dcdiag /v
# Check replication
repadmin /showrepl
Don't Forget: Reconfigure NTP After Seizing PDC Emulator
If you seized the PDC Emulator role, follow the NTP reconfiguration steps outlined earlier to ensure the new PDC Emulator syncs with an external time source.
Why This Approach Matters
Transferring FSMO roles before attempting recovery fundamentally changes the risk profile:
- Before transfer: Any recovery failure creates a forest-wide emergency requiring role seizure
- After transfer: Recovery failure only affects one non-FSMO DC, which can be rebuilt at your convenience
The key insight is that rebooting a dirty-shutdown FSMO holder without transferring roles first puts you in a corner. Once the DC fails to mount the database, seizure becomes your only path—and that's always more disruptive than a planned transfer.
The Five FSMO Roles: A Quick Reference
For context, here are the five roles you're protecting:
Forest-wide roles:
- Schema Master: Controls all schema modifications
- Domain Naming Master: Controls adding/removing domains
Domain-wide roles:
- RID Master: Assigns RID pools to domain controllers for object creation
- PDC Emulator: Handles password changes, time sync, Group Policy
- Infrastructure Master: Resolves cross-domain object references
Losing access to these roles can impact various Active Directory operations, though most roles aren't immediately critical. However, the PDC Emulator role is essential for password operations and should be prioritized.
Conclusion
Discovering a dirty shutdown on your FSMO role holder doesn't have to be a crisis. The key is making smart decisions before you commit to a recovery path that might fail.
By transferring FSMO roles while Active Directory is still operational, you transform a potential forest-wide emergency into a manageable single-server issue. It's the difference between "I need to recover the FSMO holder or the forest is at risk" and "I can rebuild this DC at my convenience while everything else runs normally."
Remember the golden rule: If the FSMO holder is still running Active Directory, transfer the roles first, only if that's impossible should you proceed with in-place recovery or role seizure.