Completing DFSR SYSVOL migration of domains that use Entra ID passwordless SSO

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 fix the issue introduced by a very modern add-on.

Background 

Decades after Windows 2000 first shipped and introduced the world to Domain Controllers, the File Service, and SYSVOL, Azure released the Entra ID Passwordless security key sign-in to on-premises resources. With it, can issue ticket-granting tickets for your domain. Users can sign in to Windows with modern credentials, such as FIDO2 security keys, and then access traditional Active Directory-based resources. Service Tickets and authorization continue to be controlled by your on-premises DCs. 

fido2-ticket-granting-ticket-exchange-process.png

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 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 . 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 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 

 

This article was originally published by Storage at Microsoft. You can find the original article here.