Authoritative Restore of SYSVOL after Deallocation of Azure DCs

The Problem

If you run an isolated lab in Azure IaaS with more than one Domain Controller and are in the habit of shutting down and de-allocating the VMs to save money, you may have found that SYSVOL doesn’t replicate when you start them back up.

The Cause

De-allocation/re-allocation of a VM changes the VM generation ID and Active Directory forces a safe recovery on restart. The problem with safe recovery in an isolated Azure IaaS lab is that no DC is authoritative.

The Solution

A manual authoritative restore of DFSR SYSVOL is required using steps outlined in KB2218556.

The Whinge

I’m fed up with doing this so wrote a PowerShell script

The Script

 # Get the list of all DCs in the local domain
$domainControllers = Get-ADDomainController -Filter *

# Use the first DC in the list as the primary member for DFSR
# If a specific DC is preferred, use Get-ADDomainController -Identity <DC_Hostname>
$primaryDC = $domainControllers[0]

# Stop DFSR on all DCs
foreach ($dc in $domainControllers)
{
    Invoke-Command -ComputerName $dc.HostName -ScriptBlock {Stop-Service DFSR}
}

# Modify DFSR subscription object to disable the SYSVOL replica in AD and replicate it
foreach ($dc in $domainControllers)
{
    $sysvolSubscriptionObject = "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings," + $dc.ComputerObjectDN
    Get-ADObject -Identity $sysvolSubscriptionObject | Set-ADObject -Server $primaryDC -Replace @{"msDFSR-Enabled"=$false}
    Get-ADDomainController -filter * | foreach {Sync-ADObject -Object $sysvolSubscriptionObject -Source $primaryDC -Destination $_.hostname}
}

# Start and then stop DFSR on all DCs
foreach ($dc in $domainControllers)
{
    Invoke-Command -ComputerName $dc.HostName -ScriptBlock {Start-Service DFSR}
    Start-Sleep -Seconds 20
    Invoke-Command -ComputerName $dc.HostName -ScriptBlock {Stop-Service DFSR}
}

# Modify DFSR subscription to enable the SYSVOL replica in AD and set the primary
# Force replication of these changes
$sysvolSubscriptionObject = "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings," + $primaryDC.ComputerObjectDN
Get-ADObject -Identity $sysvolSubscriptionObject | Set-ADObject -Server $primaryDC -Replace @{"msDFSR-Options"=1}

foreach ($dc in $domainControllers)
{
    $sysvolSubscriptionObject = "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings," + $dc.ComputerObjectDN
    Get-ADObject -Identity $sysvolSubscriptionObject | Set-ADObject -Server $primaryDC -Replace @{"msDFSR-Enabled"=$true}
    Get-ADDomainController -filter * | foreach {Sync-ADObject -Object $sysvolSubscriptionObject -Source $primaryDC -Destination $_.hostname}
}

# Start DFSR on all DCs
foreach ($dc in $domainControllers)
{
    Invoke-Command -ComputerName $dc.HostName -ScriptBlock {Start-Service DFSR}
}

The Warning

I’d caution against setting this as a scheduled task or anything too creative. You really do want all DCs booted and running before you do this

The Conclusion

Hopefully it’s useful to some

Comments

• Anonymous
  November 06, 2017
  Having done this a few times manually, having a script would've been a lifesaver. I had to do it once so many times that I gave up and called MS support, at which time they actually had to do the same steps another 3 times before it worked. In other words, don't be surprised if you do this more than once to get things back in proper order.
• Anonymous
  November 06, 2017
  Thank Mark. I have been searching a way on how to do this.
• Anonymous
  November 06, 2017
  Agree; DC is an always on workload. If cost is an issue you might consider Azure B-series VMs (currently in preview).https://docs.microsoft.com/en-us/azure/virtual-machines/windows/b-series-burstable
  • Anonymous
    November 06, 2017
    This blog post addresses a special case - isolated lab where it's likely you're going to power down and de-allocate for periods of time.
  • Anonymous
    November 07, 2017
    Not only that look at - Reserved VMs for more price saving
• Anonymous
  November 08, 2017
  The comment has been removed
  • Anonymous
    November 08, 2017
    Thanks for the catch. Corrected now.
• Anonymous
  December 20, 2017
  Perfect! Would this also work for azure site recovery scenarios where we restore a DC in Azure and other DC's still exist on-prem?The recommendation is that a DC in Azure 24/7 should be used for AD-Replication but in some cases the on-premise DC has other roles installed that we need to protect e.g. a file share
  • Anonymous
    December 20, 2017
    Let me see whether I understand you correctly first - I think what you're saying is that you have on-premises DCs that you are protecting with Azure Site Recovery and that in a recovery scenario, those DCs may be restored into an Azure vNet. If I've got that right and the Azure vNet has connectivity back to on-premises via a VPN or ExpressRoute circuit, the restored DCs should communicate with on-premises DCs and handle the safe recovery automatically. There should be no requirement for this script.