PHS staged rollout works for existing users but not new synced users
We are troubleshooting an Entra ID PHS staged rollout issue with a federated domain using a third-party WS-Fed IdP. The intended behavior is that normal federated users redirect to the IdP, while users in the PHS staged rollout group receive the Microsoft/Entra password prompt instead. Existing users in the staged rollout group continue to work correctly. They enter their UPN and receive the Microsoft password prompt. One known-good test user is not provisioned in the third-party IdP and still signs in successfully through the Entra password prompt, so the working path does not require the user to exist in the IdP. The issue is only with newly created AD-synced users. Newly synced users in the same staged rollout group are still being routed to the federated IdP at HRD instead of receiving the Entra password prompt. We’ve verified the staged rollout policy and group membership from Graph, confirmed the affected users are properly AD-synced with clean immutableID/sourceAnchor, and confirmed PHS is working. Federation metadata and HRD policies also look clean. Seamless SSO/AZUREADSSOACC was checked and remediated, but the behavior did not change. For failed attempts, there is no Entra sign-in log entry, including tenant-wide interactive and non-interactive logs. However, the federated IdP logs show a WS-Fed inbound request from login.microsoftonline.com for the affected user. That makes it look like Entra HRD is routing the user to federation before sign-in logging or token issuance. The issue started around an Entra Connect AD connector/DC-path change. We have since reverted the connector to the previous known-good configuration. After reverting, we created a clean-room test user with the correct UPN set before first sync, confirmed sync/PHS/sourceAnchor, added the user directly to the staged rollout group, and waited 60+ minutes. The clean-room user still redirected to the federated IdP instead of getting the Entra password prompt. So the current behavior is that established staged-rollout users still get the Entra password prompt, but newly created synced staged-rollout users are sent to the federated IdP by HRD. Has anyone seen staged rollout get into this state, where existing users work but new synced users remain on the federated HRD path despite valid rollout policy, group membership, synced password hash, and clean immutableID/sourceAnchor? Is there any known backend cache/state reset or escalation path for HRD/staged rollout routing?
mail@mydomain is causing a cert mismatch error in all browsers for Outlook.com
Hello, I have created a CNAME for our users in my domain so that they can access webmail. For example, it's called mail.mycustomdomain.com, and it is directed to Outlook.com But when I try to visit mail.mycustomdomain.com, it shows a security warning and recommends going back. I can understand because the SAN name in the certificate presented by Outlook doesn't include my CNAME. Is there anything I can do as a workaround so our users can enter the CNAME without encountering a Certificate Mismatch Error? It is causing repeated calls to the helpdesk, and we would like them to use something simple they can remember. ThanksO365 Email Migration to Another Tenant while Deferring Migration of Sharepoint files
Hi, This is the context: ChildCompany has O365 and it has an Azure AD in hybrid mode synchronizing to a on-prem AD server. They have an internal domain ChildCompany.com, and an external domain ChildCompany.com where they also receive and send email using O365. ParentCompany is going absorb the ChildCompany some time in next year, and I was asked about the integration options. According to this https://download.microsoft.com/download/b/a/1/ba19dfe7-96e2-4983-8783-4dcff9cebe7b/microsoft-365-tenant-to-tenant-migration.pdf I could do a phased migration, where the end state is that they decomm their onprem AD and that they only use our ParentCompany systems. The business requirement is to start their integration with Email, and then in later phases do the Sharepoint integration as that requires way more analysis on their data sources, as they also have wikis and many other on prem legacy stuff. They are less than 50 users, so I can use Quest migration tools for the email part, but I wonder what needs to happen in what order. This is what I have in mind: Migrate their current O365 into our ParentCompany Office 365 subscription, so that they can continue logging in into their domain joined windows machines using childCompany.co, so they start using ParentCompany.com email addresses, but the problem then is how can they continue using their sharepoint and onedrive resources associated with the Azure and local domain at ChildCompany.com? This is more or less what I have in mind, for the intermediate step, the cutover: Child Company ParentCompany --------------------- ---------------- On-Prem | MS Cloud: | MS Cloud: ---------------|----------------------|-------------- Local AD (ADFS)| Azure Subscription | Azure Sub | Azure AD | Azure AD |--------------------- |--------------------- | O365 Sub -> | O365 Sub | Exchange mailboxes-> | Exchange mailboxes | Sharepoint? -> | ??? | -------------------- |--------------------- I wonder how could it be possible to defer the sharepoint and onedrive migration, so that the child company users can still work on their sharepoint files using their normal auth methods, while disabling childcompany.com as MX so they start using ParentCompany.com mailboxes.Is that even possible? Would make more sense to try to migrate everything at once? That is way more work, but I'm weighting my options.Hybrid Join Lifecycle Model
Microsoft Entra hybrid join is still a common reality in enterprise environments. For many organizations, it remains necessary because legacy applications still rely on Active Directory machine authentication, Group Policy is still in use, and on-premises operational dependencies have not fully been retired. At the same time, the long-term direction for endpoint identity is increasingly cloud-native. That creates an important architectural question: Should hybrid join be treated as a permanent device state, or as a lifecycle stage in a broader modernization journey? In practice, hybrid join is often discussed as a binary condition: the device is either hybrid joined or it is not. But from an operational perspective, that view is too limited. In real enterprise environments, hybrid join behaves much more like a lifecycle. A device moves through provisioning, registration, trust establishment, management attachment, steady-state operation, recovery, retirement, and eventually transition. That distinction matters because most hybrid join issues do not fail loudly. They usually appear as stale objects, pending registrations, broken trust, inconsistent management ownership, and environments that remain temporarily hybrid far longer than intended. Why a lifecycle model is useful Treating hybrid join as a lifecycle helps explain why so many organizations struggle with it even when the initial implementation appears technically correct. The challenge is usually not the first successful join. The challenge is everything that happens around it: Provisioning quality Trust validation Management ownership Drift detection Stale object cleanup Exit criteria for transition to Entra join Without that lifecycle view, hybrid join often becomes a static design decision with no clear operational model behind it. The eight phases 1. Provisioning The lifecycle starts when the device is built, imaged, or provisioned. This stage is more important than it looks. If the device is provisioned from a contaminated image, or if cloning and snapshot practices are not handled carefully, later identity issues are often inherited rather than newly created. Provisioning should be treated as an identity-controlled event, not just an OS deployment task. 2. Registration The device becomes known to Microsoft Entra. This is where many environments confuse visibility with readiness. A device object may exist in the cloud, but that does not automatically mean the hybrid identity state is healthy or operationally usable. 3. Trust Establishment This is the point where hybrid join becomes real. A device should not be considered fully onboarded until both sides of trust are present and healthy. In operational terms, this means the device is not only registered, but also capable of supporting the expected sign-in and identity flows. 4. Management Attachment Once trust exists, governance becomes the next question. Many organizations still balance Group Policy, Configuration Manager, Intune, and legacy application dependencies at the same time. That is exactly why hybrid join often persists. But if management ownership is not clearly defined, organizations end up with overlapping policy planes, inconsistent control, and unclear accountability. 5. Operational Steady State Hybrid join does not stop at successful registration. The device must remain healthy over time, and that means monitoring trust health, registration state, token health, line-of-sight to required infrastructure, and management consistency. A device that was healthy once is not necessarily healthy now. 6. Recovery Every real environment eventually encounters drift. Pending states, broken trust, orphaned records, reimaged devices, and inconsistent registration scenarios should not be treated as unusual edge cases. They should be expected and handled with formal recovery playbooks. Recovery is not an exception to the lifecycle. It is part of the lifecycle. 7. Retirement Retirement is one of the weakest areas in many hybrid environments. Devices are replaced or decommissioned, but their identity records often remain behind. That leads to stale objects, inventory noise, and administrative confusion. A proper lifecycle model should include a controlled retirement sequence rather than ad hoc cleanup. 8. Transition This is the most important strategic phase. The key question is no longer whether a device can remain hybrid joined, but whether there is still a justified reason to keep it there. Hybrid join may still be necessary in many environments today, but in many cases it should be treated as transitional architecture rather than the target end state. Practical takeaway Looking at hybrid join as a lifecycle creates a more useful framework for architecture decisions, operational ownership, troubleshooting, directory hygiene, governance, and transition planning toward Microsoft Entra join. That is the real value of this model. It does not replace technical implementation guidance, but it helps organizations think more clearly about why hybrid join exists, how it should be operated, and when it should eventually be retired. Final thought Hybrid join is still relevant in many enterprise environments, but it should not automatically be treated as a default destination. In many cases, it works best when it is managed as a lifecycle-driven operating model with defined phases, controls, and exit criteria. That makes it easier to stabilize operations today, while also creating a clearer path toward a more cloud-native endpoint identity model tomorrow. Full article: https://www.modernendpoint.tech/hybrid-join-lifecycle-model
Frequent Account lockouts
We are having passthrough authentication setup and we see lot of errors recently with the below process Process Information: Caller Process ID: 0x8e4 Caller Process Name: C:\Program Files\Microsoft Azure AD Connect Authentication Agent\AzureADConnectAuthenticationAgentService.exe Users are getting locked out too frequently. The auditing software points to the server where AD connect is installed. I am not sure why this is happening but need your advice and suggestions please. Thank you all.Display On-prem Password Policy on SSPR Page
Hi All We are beginning to rollout SSPR with on-prem writeback. So far so good. Is there a way we can display our on-prem password policy requirements on the SSPR screen? I have seen the MS docs, but can't really make any sense of them so any help would be greatly appreciated. SK
My Azure login is stuck at MFA and cannot proceed
In August, I was still able to log in to Azure, and by logging in through GitHub I could bypass 2FA. But now, no matter how I try, logging in via GitHub always requires 2FA. I can’t access my Azure account anymore—nothing works. The system prompts me to use Microsoft Authenticator to confirm a two-digit code in real time. My Microsoft Authenticator on my iPhone is logged into the same Microsoft account, but I’m not receiving any verification requests for Azure login. No matter how much I refresh, nothing shows up. I’ve already updated the Microsoft Authenticator app to the latest version from the App Store. However, my personal Microsoft account works fine and can log in without any issues.
