In the last two weeks, I have seen several customers where Active Directory (AD) replication is reporting normal, but Group Policy is acting “odd”. Here is what I found.

If you are still using FRS (Flaky Replication System) instead of DFSR (Darn Fine Replication System), you should migrate from FRS to DFSR.

To determine if FRS or DFSR is used, run the following command on one of your DCs:

dfsrmig /getmigrationstate

Possible results:

1. The current domain functional level is not Windows Server 2008 or above.
   DFSRMig is only supported on Windows Server 2008 or above level domains.
2. DFSR migration has not yet initialized. To start migration please
   set global state to desired value. [sic]
3. All domain controllers have migrated successfully to the Global state (‘Start’).
   Migration has reached a consistent state on all domain controllers.
   Succeeded.
4. All domain controllers have migrated successfully to the Global state (‘Prepared’).
   Migration has reached a consistent state on all domain controllers.
   Succeeded.
5. All domain controllers have migrated successfully to the Global state (‘Redirected’).
   Migration has reached a consistent state on all domain controllers.
   Succeeded.
6. All domain controllers have migrated successfully to the Global state (‘Eliminated’).
   Migration has reached a consistent state on all domain controllers.
   Succeeded.

If you see either number 1 or 2, you are using FRS. It would be best if you migrated to DFSR as soon as possible. If you see numbers 3 through 5, you should finish your migration from FRS to DFSR. You want to see the text from number 6.

Here is a quick PowerShell script to gather the state of SYSVOL of all Domain Controllers (DCs).

You do not need the Active Directory or Group Policy PowerShell modules.

You do not have to run this elevated.

You will need to run as an account with access to the DCs.

$DCs = dsquery server -o rdn
$DCs = $DCs | Sort-Object
$SysvolStatus = New-Object System.Collections.ArrayList
ForEach($DC in $DCs)
{
    $Results = Get-WMIObject -ComputerName $DC -Namespace "root/microsoftdfs" -Class "dfsrreplicatedfolderinfo" -Filter "ReplicatedFolderName = 'SYSVOL Share'" | Select-Object State

    If($? -and $Null -ne $Results)
    {
        $obj1 = [PSCustomObject] @{
            DCName       = $DC
            SysvolState  = $Results.State
        }
        $null = $SysvolStatus.Add($obj1)
    }
    Else
    {
        $obj1 = [PSCustomObject] @{
            DCName       = $DC
            SysvolState  = "Unknown: $($Results.State)"
        }
        $null = $SysvolStatus.Add($obj1)
    }
}

If($SysvolStatus.Count -gt 0)
{
    ForEach($Item in $SysvolStatus)
    {
        "DC: $($Item.DCName)`tSYSVOL State: $($Item.SysvolState)"
    }
}

You should see output similar to:

DC: LABDC1 SYSVOL State: 4
DC: LABDC2 SYSVOL State: 4

You do not want to see something similar to the following.

DC: LABDC1 SYSVOL State: 2
DC: LABDC2 SYSVOL State: 5

The possible State values are:

0 = Uninitialized
1 = Initialized
2 = Initial Sync
3 = Auto Recovery
4 = Normal
5 = In Error

A state value other than 4 should be investigated.

I added this information to the AD documentation script update 3.03, which is currently in testing. If you want to test this script update, send me an email. If the SYSVOL State is not 4, I highlight the value in Red in the Word/PDF/HTML output. In the Text output, I use “***”.

I use this Microsoft article to troubleshoot and fix the incorrect state values.

How to troubleshoot missing SYSVOL and Netlogon shares

I hope your SYSVOL is normal and healthy.

Thanks

Webster