Why leaving AD FS is becoming urgent
An Active Directory Federation Services (AD FS) farm represents a single point of failure for your entire organization. If this service goes down — server failure, expired certificate, network incident — every user instantly loses access to Microsoft Teams, Exchange Online, SharePoint and all cloud applications. Federated authentication relies on a precise flow: the user enters their email address, Entra ID detects that the domain is federated, redirects to AD FS, which validates the password against Active Directory and returns a token. This detour works, but it requires maintaining additional servers, certificates and permanent high availability — just so your employees can log in.
The official solution is to convert the domain from federated to managed, which switches all users simultaneously. One small misconfiguration, and you discover it in production in front of your entire company. This is precisely why Staged Rollout exists.
Prerequisites before any manipulation
Before touching anything in the portal, verify the following points:
- License: no specific Entra ID Premium license is required for Staged Rollout itself, but your Azure AD Connect configuration must be operational.
- Entra ID Role: Hybrid Identity Administrator (Hybrid Identity Administrator) or Global Administrator (Global Administrator).
- Azure AD Connect: up-to-date version, active synchronization, and Password Hash Sync enabled in the configuration wizard (even if your domain is currently federated).
- PowerShell Module:
Microsoft.Graphinstalled for the final cutover command. - Pilot Group: a cloud security group (not a distribution group, not a mail-enabled group) with fewer than 200 members for the first addition. Nested groups and dynamic groups are not supported.
- Complete Synchronization: at least one complete synchronization cycle must have run after enabling Password Hash Sync.
Unsupported Groups
Staged Rollout does not support nested groups or dynamic groups. Use exclusively cloud security groups with direct membership, limited to 200 members during the first deployment.
Understanding the hidden mechanism of Staged Rollout
Most administrators think Entra ID checks pilot group membership at login time. This is wrong — and this misunderstanding generates a lot of confusion.
Here's what actually happens:
- You add a user to the pilot group in the portal.
- A background job continuously monitors this group.
- When it detects the new addition, it inscribes a hidden attribute directly on the user's account in Entra ID, indicating that this user is now "managed".
- At login time, Entra ID reads this attribute on the account — never the real-time group composition.
Direct consequence: group changes can take up to 24 hours to take effect. If a test doesn't work immediately after adding a user, wait before concluding there's a problem.
Enable Password Hash Sync in Azure AD Connect
Open the Azure AD Connect wizard
On your server hosting Azure AD Connect, launch the Azure AD Connect application from the Start menu or the Desktop shortcut.
Select Configure on the home screen.
Enable Password Hash Sync
In the list of available tasks, choose Modify user sign-in, then click Next.
Log in with your Azure AD global administrator credentials when the wizard prompts you.
On the User Sign-in page, check Password hash synchronization in addition to your current federation method. AD FS can remain configured simultaneously — the two coexist.
Complete the wizard and let the synchronization run.
What you should see: in the Windows Event Log (Application), entries from the synchronization agent indicating that a complete synchronization cycle completed successfully.
Verify that a complete cycle executed
Open PowerShell on the Azure AD Connect server and run:
1Get-ADSyncSchedulerVerify that SyncCycleInProgress shows False and that LastSyncRunTime is recent. If necessary, manually trigger a cycle:
1Start-ADSyncSyncCycle -PolicyType DeltaConfigure Staged Rollout in the Entra portal
Access the Staged Rollout configuration
Open the Entra ID portal and navigate to:
Identity > Hybrid management > Azure AD Connect > Connect Sync
Click Enable staged rollout for managed user sign-in.
What you should see: a side panel opens with the three available authentication methods: Password Hash Sync, Pass-through Authentication, and Certificate-based authentication.
Enable Password Hash Sync and add your pilot group
Slide the Password Hash Sync button to On.
Click Manage groups, then Add groups. Search for and select your pilot security group. Confirm the selection.
Start with a group of fewer than 200 members — ideally 5 to 20 users representative of different profiles (domain-joined computers, mobile devices, VPN, etc.).
What you should see: the group appears in the list under Password Hash Sync with Active status.
Propagation Delay
After adding users to the pilot group, allow up to 24 hours for the hidden attribute to be written to each account. Don't conclude there's a malfunction before respecting this delay.
Known Staged Rollout limitations
Staged Rollout doesn't cover all authentication scenarios. Take them into account when composing your pilot group:
- Legacy authentication protocols (IMAP, POP3, SMTP AUTH): ignore the pilot group and continue using federation.
- Applications sending a domain hint: bypass the mechanism and remain federated.
- Password writeback: behavior is not guaranteed during rollout with Password Hash Sync — test carefully.
- Password expiration: not enforced by default for users in the pilot phase.
- Non-persistent VDI: must remain federated.
- Windows Hello for Business (certificate mode) and smartcards: not supported at all in Staged Rollout.
Staged Rollout is not a destination
Microsoft is explicit on this point: Staged Rollout is a testing mechanism, not a permanent configuration. An organization with some users federated and others managed indefinitely is not a supported architecture long-term. Test, validate, then complete the migration.
Validate a pilot user's sign-in
Once the propagation delay has elapsed, test with an account that is a member of the pilot group:
Test sign-in in private browsing mode
Open a private browsing window and go to https://myapps.microsoft.com.
Enter the email address of a user belonging to the pilot group.
What you should see: the Entra ID sign-in page with your organization's branding displays directly — without redirection to your AD FS server. The password field is provided by Entra ID itself.
If you still see the AD FS page, attribute propagation hasn't finished yet. Wait and try again.
Control sign-in logs
In the Entra ID portal, navigate to Identity > Monitoring & health > Sign-in logs.
Filter by pilot user. Verify that the Authentication requirement column shows Single-factor authentication (or MFA if configured) and that the Client app column does not mention AD FS.
Also check your AD FS farm logs to confirm that pilot user sign-ins no longer appear there.
Finalize the migration: convert the domain
When your pilot group has validated functionality over a sufficient period, the final migration is performed with a single PowerShell command. This is when the domain switches from federated to managed for all users.
Connect to Microsoft Graph with necessary permissions
1Connect-MgGraph -Scopes "Domain.ReadWrite.All"Authenticate with a Global Administrator or Hybrid Identity Administrator account. Accept the requested permissions.
Convert the domain to managed
Replace yourdomain.com with your actual domain:
1Update-MgDomain -DomainId "yourdomain.com" -AuthenticationType "Managed"This command is irreversible without manual intervention. Execute it during a maintenance window, outside peak hours. Propagation can take up to one hour.
Verify the domain conversion
1Get-MgDomain -DomainId "yourdomain.com" | Select-Object Id, AuthenticationTypeWhat you should see: AuthenticationType displays Managed.
Disable Staged Rollout
Return to Entra ID > Identity > Hybrid management > Azure AD Connect > Connect Sync and disable Staged Rollout. It has no reason to remain active once the domain is converted.
Recommended Maintenance Window
Schedule the cutover command for a Friday evening or weekend. The one-hour propagation can create intermittent interruptions. Notify your helpdesk and keep an administrator available to monitor logs.
If you encounter issues
Pilot users still see the AD FS page after 24 hours
Verify that the group used is indeed a cloud security group with direct membership (not nested, not dynamic). Confirm in Azure AD Connect synchronization logs that a cycle ran after the addition. If the problem persists, remove the user from the group, wait a few hours, then re-add them.
The Update-MgDomain command returns a permissions error
Make sure you launched Connect-MgGraph with the Domain.ReadWrite.All scope and that the account used actually has the Global Administrator or Hybrid Identity Administrator role. Disconnect and reconnect to Graph if the session is old:
1Disconnect-MgGraph2Connect-MgGraph -Scopes "Domain.ReadWrite.All"Legacy applications no longer work after cutover
Basic authentication protocols (SMTP AUTH, IMAP, POP3) no longer go through AD FS after domain conversion. Verify that the applications in question are configured to use modern OAuth 2.0 authentication, or enable basic authentication in Exchange Online for services that still require it (with associated security risks).
