Microsoft Entra provisioning Agent Error
Hello, I have deployed the Microsoft Entra provisioning agent in my organization, with synchronization configured from AD to Microsoft Entra ID. I am encountering an issue on the server where the Cloud Sync agent is installed: when connecting to Microsoft endpoints via a Squid proxy, I receive the error shown in the screenshot. The synchronization itself works perfectly, and the configuration status in the cloud is "Healthy." I frequently see the error shown in the screenshot (error code 12015), and I also occasionally encounter error code 12011. Has anyone experienced a similar issue? Could you please advise on how to resolve it? Thanks.
Microsoft Entra ID Provisioning: SelectUniqueValue and the "Apply this mapping" limitation
In Microsoft Entra ID's provisioning service, the SelectUniqueValue() expression has a specific restriction: When an attribute mapping uses SelectUniqueValue(), the "Apply this mapping" setting must be configured as "Only during object creation." It cannot be configured as "Always." This restriction is related to how the provisioning engine generates unique attribute values and how those values are maintained throughout an object's lifecycle. 1. How SelectUniqueValue() works The SelectUniqueValue() function evaluates a list of candidate values in priority order and selects the first value that does not conflict with an existing value in the target directory. For example, consider generating a user's userPrincipalName: SelectUniqueValue( Join("", [FirstName], [LastName], "@company.com"), Join("", [FirstName], ".", [LastName], "@company.com"), Join("", [FirstName], [LastName], [EmployeeID], "@company.com") ) The provisioning engine evaluates candidates in sequence: JohnSmith _AT_ company.com John.Smith _AT_ company.com JohnSmith12345 _AT_ company.com It selects the first available candidate. The important distinction is that this is a uniqueness-selection operation, not simply a string transformation. 2. Why the "Always" setting is incompatible Consider the following scenario. Initial provisioning Two employees exist: Employee Generated UPN John Smith (Employee 100) JohnSmith _AT_ company.com John Smith (Employee 200) John.Smith _AT_ company.com The second employee receives the alternate UPN because the preferred value is already taken. Subsequent provisioning cycles Suppose Employee 100 leaves the organization and email address removed for privacy reasons eventually becomes available. If SelectUniqueValue() were evaluated continuously as an ordinary update mapping, Employee 200 could potentially receive a different result: Attribute Value Existing UPN John.Smith _AT_ company.com Newly preferred candidate JohnSmith _AT_ company.com That could result in an unwanted identity change, even though Employee 200's name and other source attributes have not changed. Restricting the mapping to object creation avoids this class of problem. There is also an important implementation distinction: selecting a unique value during creation is different from evaluating whether an existing object's current value should be retained during an update. The latter requires preserving identity stability, not merely finding an available candidate. The example illustrates the design rationale; it does not establish that Microsoft's engine would actually perform that reassignment if the restriction were removed. 3. What Microsoft officially documents Microsoft explicitly states that: SelectUniqueValue() is intended only for object creation. The mapping must use Only during object creation. The function must be top-level and cannot be nested inside another function. The target attribute cannot have a matching precedence configured. These are documented product restrictions, not merely recommended practices. Microsoft Learn+1 Microsoft does not explain the internal implementation reason for the creation-only restriction in that documentation. The identity-stability explanation above is a plausible rationale, rather than a confirmed statement from Microsoft engineering. Official reference: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/functions-for-customizing-application-data?utm_source=chatgpt.com#selectuniquevalue 4. Implications for Workday-to-Active Directory (or any external directory) provisioning This limitation becomes particularly relevant when provisioning sAMAccountName or userPrincipalName from Workday. Suppose an employee's last name changes: Event Desired UPN Initial hire Jane.Smith _AT_ company.com Marriage/name change Jane.Jones _AT_ company.com With SelectUniqueValue() configured for object creation, the provisioning service will not reevaluate the UPN mapping for the existing AD user. Consequently, you cannot use that same mapping to both: Generate a collision-free UPN when creating a user. Automatically update the UPN when Workday reports a name change. 5. Feature Request / Future Development: Removing the SelectUniqueValue() Restriction Microsoft could significantly improve the Entra ID provisioning service by extending SelectUniqueValue() to support the "Always" attribute mapping setting, allowing uniqueness validation during both object creation and subsequent updates. The current restriction creates a functional gap in identity lifecycle management, particularly for organizations integrating authoritative HR systems such as Workday with Active Directory. 5.1 Proposed enhancement Microsoft should introduce an update-aware implementation of SelectUniqueValue() that supports the following behaviors: Preserve existing values: If the target attribute already contains a valid value and the source attributes have not changed, retain that value rather than selecting a different candidate. Detect source attribute changes: When an authoritative source attribute changes, such as FirstName, LastName, or PreferredName, reevaluate the expression and determine whether an identity update is appropriate. Perform uniqueness validation: Evaluate candidate values against existing objects in the target directory, excluding the object currently being updated. Support collision-free updates: If the preferred candidate is already assigned to another object, evaluate subsequent candidates in the expression, just as the function does during initial provisioning. Maintain identity stability: Prevent unintended renaming simply because a previously unavailable candidate becomes available. 5.2 Proposed configuration options Rather than simply removing the restriction, Microsoft could introduce an additional configuration setting governing how uniqueness expressions behave during updates. Proposed mode Behavior Creation Only Current behavior; evaluate only during initial provisioning Always — Preserve Existing Retain the existing value unless it is empty or an explicit reevaluation condition is met Always — Reevaluate on Source Change Recalculate when relevant source attributes change Always — Force Reevaluate Recalculate on every provisioning cycle, even when source attributes remain unchanged The "Always — Reevaluate on Source Change" option would be particularly valuable for HR-driven identity provisioning. 5.3 Technical considerations for Microsoft To implement this functionality reliably, Microsoft would need to address several technical challenges. Self-exclusion during uniqueness checks When evaluating a candidate against Active Directory, the provisioning engine must exclude the current object's identity from the uniqueness search. Otherwise, the existing user could incorrectly be identified as a collision with themselves. Concurrency and race conditions Two provisioning operations could generate the same candidate simultaneously. Microsoft should ensure that uniqueness is revalidated immediately before committing an attribute change, with appropriate conflict handling. Distinguishing source changes from directory changes A newly available username should not automatically trigger a rename. The engine should distinguish between changes in authoritative source attributes and changes in the availability of candidate values. Safe updates to identity attributes Updates to userPrincipalName, sAMAccountName, and other identity-related attributes can affect authentication, email addressing, and downstream applications. The feature should provide optional controls for preserving existing values, auditing changes, and restricting automatic renaming. 5.4 Business justification This enhancement would deliver several benefits: Complete identity lifecycle automation: Support initial provisioning and subsequent identity changes using the same expression framework. Reduced administrative overhead: Eliminate the need for custom PowerShell scripts, scheduled tasks, or external automation solely to manage uniqueness during updates. Consistent naming policies: Apply the same collision-handling rules throughout an employee's lifecycle. Improved reliability: Reduce the risk of duplicate identities and inconsistent naming conventions. Better HR integration: Allow Workday and other authoritative HR systems to drive name changes without requiring separate provisioning mechanisms. 5.5 Recommended feature request to Microsoft Feature Request: Support SelectUniqueValue() with "Always" Attribute Mapping in Microsoft Entra ID Provisioning Product: Microsoft Entra ID — Inbound HR Provisioning / Workday to Active Directory Current Limitation: The SelectUniqueValue() expression is restricted to attribute mappings configured with "Apply this mapping" set to "Only during object creation." This prevents organizations from using the provisioning service's built-in uniqueness validation when updating existing Active Directory objects. Requested Enhancement: Extend SelectUniqueValue() to support the "Always" mapping option, enabling uniqueness validation during both object creation and updates. The enhanced functionality should: Exclude the current target object from uniqueness checks. Support reevaluation when relevant source attributes change. Preserve existing values when no relevant changes have occurred. Evaluate alternate candidates when a proposed value conflicts with another directory object. Provide configurable controls to prevent unintended identity changes. Business Impact: Organizations using Workday or other HR systems as authoritative identity sources cannot fully automate changes to identity attributes such as userPrincipalName and sAMAccountName while maintaining uniqueness through the native provisioning expression engine. This limitation requires additional automation outside Microsoft Entra ID, increasing operational complexity, maintenance requirements, and potential points of failure. Expected Outcome: Enable Microsoft Entra ID provisioning to provide consistent, collision-aware identity attribute management throughout the complete employee lifecycle, including initial hiring, name changes, rehiring, and other HR-driven identity updates. This enhancement would reduce dependence on external scripts and improve the completeness of Microsoft's native HR-driven identity provisioning capabilities. 5.6 Current Microsoft position Microsoft's documentation continues to explicitly restrict SelectUniqueValue() to object creation. I found no documented commitment or announced release date for update support. Microsoft Learn+1 The feature request above is therefore a proposed product enhancement, not an existing capability or announced roadmap item.
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.
