Heya folks, Ned here again. A customer recently reached out to me in the comments section of the well-worn Streamlined Migration of FRS to DFSR SYSVOL article, asking about a problem he was seeing with a single DC that wouldn't complete the process. Today I'll explain how to fix the issue introduced by a very modern authentication add-on.
Background
Decades after Windows 2000 first shipped and introduced the world to Domain Controllers, the File Replication Service, and SYSVOL, Azure released the Entra ID Passwordless security key sign-in to on-premises resources. With it, Entra ID can issue Kerberos ticket-granting tickets for your Active Directory domain. Users can sign in to Windows with modern credentials, such as FIDO2 security keys, and then access traditional Active Directory-based resources. Kerberos Service Tickets and authorization continue to be controlled by your on-premises DCs.
Under the covers, this works by an admin provisioning an Entra DC. A pseudo-Domain Controller, as it were, named "AzureADKerberos". It's not a real physical or virtual DC, but simply a computer object in AD pretending to be a DC so that Entra ID works in this scenario.
The Issue
So, with that in mind, you're following the DFSR migration steps and notice that one domain controller named "AzureADKerberos" is not migrating, but instead always stays in the Started state:
dfsrmig.exe /getmigrationstate
The following domain controllers have not reached Global state ('Eliminated'):
Domain Controller (Local Migration State) - DC Type
===================================================
AzureADKerberos ('Start') - Writable DC
Migration has not yet reached a consistent state on all domain controllers.
State information might be stale due to Active Directory Domain Services latency.
Since this isn't a real domain controller, it's not participating in FRS or DFSR SYSVOL replication. It doesn't even have the AD leaf object and links to do so! But DFSRMIG doesn't know this, it just sees a DC and therefore thinks it must be migrated.
Fixing the issue
OK, so how do we fix this pseudo-domain controller blocking the migration? It's pretty straightforward once you understand how migration state works under the covers. For that, take a look at Verifying the State of SYSVOL Migration and the equally well-worn AskDS blog post DFSR SYSVOL Migration FAQ: Useful trivia that may save your follicles.
Anyway, let's do this:
1. Logon to one of your DCs as a domain admin.
2. Run ADSIEDIT.MSC, right click ADSI Edit and connect to the 'Default Naming Context'.
3. Navigate to the Domain Controllers OU.
4 Right click the "AzureADKerberos" computer object and click New > Object.
5. In 'Select a class', choose msDFSR-LocalSettings and click Next.
6. In 'Value', type DFSR-LocalSettings and click Next.
7. Click Finish.
8. Right-click the new 'DFSR-LocalSettings' leaf object and click Properties.
9. Scroll to 'msDFSR-Flags' and set it to a value of 48.
10. Click ok and ok, close ADSIEDIT.MSC.
11. Allow AD replication to complete.
12 Continue your migration until completed and verify all DCs are now in Global state eliminated by running:
dfsrmig.exe /getmigrationstate
All domain controllers have migrated successfully to the Global state ('Eliminated').
Migration has reached a consistent state on all domain controllers.
Succeeded.
Last thoughts
Technical debt is a real pita, but you already knew that! Just be glad that you're finally getting that old FRS system out and moving to DFSR for your SYSVOL.
That streamlined migration article has 702,000 views even after being migrated from the old TechNet blog platform. But the old dog still learns new tricks :).
Until next time,
Ned Pyle