MicrosoftMicrosoftI'm a partner working with an Enterprise client and finishing up a migration from a 3rd party hosted resource forest Exchange design. ADConnect was syncing this resource forest and their Corporate AD forest, however, their local AD forest never had an Exchange server and the schema was never extended for Exchange. We needed to use 1.6.x in order to facilitate defining attributes across multiple directories (when we started the project there was a bug regression in the 2.0.x version that prevented us from seeing this page), and as part of the migration, we had Exchange Hybrid deployment enabled in the install._This allowed us to represent a single object in Azure AD with the immutableID coming from the corporate AD forest and Exchange attributes contributing from the resource forest. The metaverse presented the 2 source forests' attributes very nicely.
_As we're decom'ing the 3rd party hosted resource forest from the M365 design, we cut off Directory Sync as one of the final steps (Set-MsolDirSyncEnabled -EnableDirSync $false) to shift user mailboxes, shared mailboxes, and distribution lists to Cloud only, and this worked rather flawlessly (avoiding having to rebuild DLs in EO, etc). The main reason for moving to cloud-only temporarily (less than 24 hours) was to clear the immutableID of the shared mailboxes (which equated to 35% of their total mailboxes) so we could manage their proxy addresses and other facets of Exchange management purely in the cloud.
But we needed to reenable DirSync against their Corporate AD forest for SSO with Password Hash sync, however, this AD was never extended for the Exchange schema, and told them this is not something they want to be in the business of managing.
_Once we reinstalled ADConnect (to remove the old resource forest references, get the client up to a supported version, and not have Exchange hybrid deployment enabled in ADConnect), we did our first sync and the Synchronization Service did its job and matched the users in the Corporate AD forest nicely against their immutable ID, and changed them from Cloud back to Windows Server managed. In doing so, it cleared all the Exchange managed attributes that were previously in the resource forest.
_Yet, We still cannot manage the proxyaddresses for these users in the cloud.
_"In a perfect world" it would be great to go into the MSOnline module, run a command (say Get-MsolDirSyncConfiguration) and see if Exchange Hybrid deployment is enabled or disabled. If it's enabled, then things like proxyaddresses, etc would be within dual write scope. If it's disabled, you can manage them in Exchange Online).Another "negative" impact of the reinstall of the DirSync and the Corporate AD users from Cloud to Windows Server synced is that not have the schema extended for Exchange and not having the proxyaddresses populated, the email aliases and X.500 addresses from the resource forest were wiped out and many users are getting failures on email replies, updating calendar messages, etc. You can see when it did the first sync it wiped these out, and it cleared the msExchRemoteRecipientType attribute (which in my mind should be another flag that the object its not under the dual write scope)
What's interesting here is that I cannot add an X.500 address en-mass to all my users via Powershell, because I get the same error
BUT if i do this via Exchange Online admin center, it adds it with no issues
And all of my AD Synced users daily have (check out Correlation ID d8135576-6305-4b86-9b03-75de490163d8) have the Microsoft Substrate Management (which is tied to ADConnect) error
