Delen via

Authoritative Restore of SYSVOL after Deallocation of Azure DCs

  • Artikel

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.