AAD Sync; make mobile attribute authoritative again after AAD/tenant/portal update
AAD Sync; make mobile attribute authoritative again after AAD/tenant/portal update.
If you update the mobile attribute as a user or admin in the tenant, this no longer flows from on premises AAD Sync. If the user has made a mistake and you wish this to flow again from on premises, there is no way to make it authoritative again.
We currently do not plan to implement this functionality.
Loyld Glenn commented
It was mentioned that this was addressed inside of MC222474 which expired some time ago.
It linked to the following blog about the fix - https://developer.microsoft.com/en-us/graph/blogs/breaking-change-to-microsoft-graph-users-api-updates-to-on-premises-sync-enabled-user-contact-numbers-are-no-longer-allowed/
Jason Stuhre commented
With regards to this I am a support engineer for Azure Active Directory Connect (AADC)/Azure AD Sync and their is a current customer that is experiencing complications with the syncing of the attribute Mobile from AD (Active Directory) to Azure Active Directory (AAD).
Come on MS this needs to be fixed. This is core user information and needs to be consistent across an organisation. You setup the AD framework and now you break it ??
Huge bummer. This is very unfortunate.
It is not acceptable that Microsoft does not fix this bug. Our organization synchronizes by provisioning primarily mobile numbers to many systems from azure.
Please fix this urgently to allow proper production !
Thanks Microsoft for introducing another bug. Please fix this. We are just another paying customer with On-Prem AD that is migrating to O365.
Do your job!!
LET US VOTE!
Grégory BOUVIER commented
This have to be fixed!!! It's a bug!!! Not paying for bugs! but for solutions!
Lain Robertson commented
Declining this request shows how disconnected you are from back-office administration realities. These "shadow" attributes are increasing, not decreasing problems and administration.
I'm with a client who as part of testing the on-boarding of MFA a while back manually entered the mobile attribute via the Azure interfaces rather than on-prem AD. I'm not sure how many accounts this applies to but anecdotally, it sounds like it's more than a few.
Fast-forward to now, and there's a new business request to propagate the mobile numbers out from the HR source of truth into AD, and via AAD Connect, out to AAD, which we can't fully implement because of this shortcoming.
It is not a responsible position to take to effectively say to us (through declining functionality we need) "disconnect (and therefore de-provision) and re-connect (resulting in a re-provision, which may or may not present issues even though the same objects are re-connected) the on-prem AD account to the Azure AD account via AAD Connect".
The chance that an end user is going to be aware that they are being impacted by this issue is zero to none. Similarly, it's naive to think a two-way transition for just about any topic isn't ever going to be needed by customers.
This is up there with the inability to appropriately manage other shadow attributes like proxyAddresses and extensionAttributes; the non-existent-to-poor handling of multi-value attributes, and the inconsistency of the interfacing tools (umpteen dozen PowerShell modules; dynamic group rule builder limitations; gaps in OPATH functions support; etc.)
The focus on end user-facing consumption is positive but the back-office cross-product support neglect appears to be an ever-growing issue and diminishes the notion that hybrid is well-catered to.
Kristof Kuderko commented
On this issue, I tried going through Microsoft support to get the permissions for that attribute changed on affected accounts, and was told they can't do anything about it. Now that the properties can also not be modified via Powershell, the only available workaround is to manually update the property for every affected account - and then they still won't sync if changes are made. We need a method to procedurally reset these permissions without having to drill down into every account.
This needs to be fixed. The only work around is is to unsync the object then to resync the object. This in itself has downstream effects and not a viable option with thousands of users. This was working Microsoft needs to fix this.
Fixed in MC222474
Starting near the beginning of October, updates to the mobilePhone property of on-premises sync-enabled users will no longer be allowed via Microsoft Graph, Azure AD Graph, or PowerShell. Updates to this property should instead be made in on-premises Active Directory and synced to the cloud. Updates to on-premises sync-enabled objects are not allowed because any changes to these objects are overwritten at the next Azure AD Connect sync cycle, since the source of authority of the objects is on-premises
George McDonald commented
Please explain how this feature can be by design? What design? What rationale? Can you please describe one use case where this behaviour makes sense?
I can describe one where it doesn't! Administrator by mistake adds a space at the end of the Mobile phone attribute in Exchange online. This action renders that AD account's field not authoritative. When this then cascades down to the GAL, and then Synced into Staff's Mobile contacts, then in an emergency situation when users from the organisation attempt to call the contact, the number doesn't work and the call is rejected!
When attempting to troubleshoot, the AD object is correct, it has the correct number string in the mobile phone property, and on the surface that number is also synced in AzureAD>>>Exchange....but hold on, ACTUALLY it isn't!
I have no good words to describe that design feature, so I'll refrain from saying whats on my mind! I will simply suggest that IF MS has no intention of either:
a) Provide documentation with a use case where this design feature is functional beyond theory.
b) Accept your bad judgement and fix this bug.
Then, at the very least, make it easily identifiable for an Admin at a glance when a User in Exchange has this attribute modified in Exchange!
Also, expecting Admins to have to manage these properties from different admin interfaces for users in the same organisation is Ridiculous! This implementation reeks of "individual" profile not a "organisation" profile.
Joshua Lapchuk commented
So, if we don't even have the ability ability to even identify users who have modified their own mobile field in AAD/Portal... How can we even put a ticket in with Microsoft!? My organization is switching to mobile phones for all IT staff, so I feel this is only the tip of the iceberg of increased calls/tickets to our support desk.
Phil Shand commented
This makes setting a standard mobile phone signature via a 3rd party impossible by not having our on premise AD to be the source of truth. Business critical to have a single source of truth and not have to deal with work arounds. Operationally this is absolutely crazy. We're also trying to use email signature software which uses this mobile AD field and want the mobile number to be displayed in the correct format and controlled via AD only. Please fix this issue.
Unbelievable that Microsoft won't fix this.
Dr Barry Clark commented
This is crazy - it needs fixed ASAP for all the reasons given above. This is not an idea or a suggestion - it's a BUSINESS CRITICAL thing if AD won't synchronise with Azure AD! Hardly anyone uses landlines these days - so not syncing the mobile fields is unbelievable.
John Freeman commented
This apparently remains an issue and I cannot comprehend Microsoft's reasoning behind not fixing this issue.
We now have a 'mix' of users that fall in one category or the other and this is simply unmanageable from an Operational and Security perspective.
Its shame MS are not planning to implement the functionality to change the attribute to be authoritative from AD again. We're using email signature software which uses this field and want the mobile number to be displayed in the correct international format, not the format the user inputs.