It is no longer possible to set the WindowsEmailAddress property on a synchronized user

In the world of Office 365, there are certain “gotchas” and workarounds we have accustomed ourselves to over the course of the last decade. One such useful workaround involved using the -WindowsEmailAddress parameter for the Set-Mailbox cmdlet. Invoking said parameter results in the provided value being stamped as the new Primary SMTP address of the user/mailbox, while preserving the previous PrimarySMTPAddress value as secondary alias. Oh, and it also updates the WindowsEmailAddress property, though we don’t much care for it in Exchange Online. Here’s an example use:

C:\> (Get-Mailbox room).Emailaddresses

C:\> Set-Mailbox room -WindowsEmailAddress

C:\> (Get-Mailbox room).Emailaddresses

Now why is this useful, you might ask? Surely, one can simply update the PrimarySMTPAddress value directly? Thing is, this nifty parameter worked even for synchronized users, as in objects for which the SOA was an on-premises AD. So you could use it to change the SMTP address without having any access to the on-premises environment. And in most cases, the change was not overwritten by subsequent directory synchronization cycles. This in turn made the parameter quite useful, although Microsoft has never ever stated that this is a supported scenario.

Until now, that is. As alerted by a post over at the Q&A platform, it looks like Microsoft has now “fixed” this behavior, for lack of a better term. While you can still use the -WindowsEmailAddress parameter to make changes against cloud-authored objects, it is no longer possible to use it as workaround to update the SMTP address of an on-premises synchronized user. Trying this will now result in the following error message:

C:\> Set-Mailbox gosho -WindowsEmailAddress
An Azure Active Directory call was made to keep object in sync between Azure Active Directory and Exchange Online. However, it failed. Detailed error message:
Unable to update the specified properties for on-premises mastered Directory Sync objects or objects currently undergoing migration. DualWrite (Graph) RequestId: 7b9c0db9-4b85-4da5-b0fc-5e3d56cbd783
The issue may be transient and please retry a couple of minutes later. If issue persists, please see exception members for more information.
+ CategoryInfo : NotSpecified: (:) [Set-Mailbox], UnableToWriteToAadException
+ FullyQualifiedErrorId : [Server=PR3PR09MB5346,RequestId=5bf0f47c-481d-42c8-b8ee-f7aae9ba8b26,TimeStamp=5/9/2022 8:31:37 AM] [FailureCategory=Cmdlet-UnableToWriteToAadException] 2A2BD17F,Micros
+ PSComputerName :

Bummer, but long time coming I suppose. As clearly stated by Microsoft, any changes to attributes for synchronized users should be made on-premises, as this is the only supported scenario. At least until they introduce some way to “transferring” the SOA, either on a per-object or per-attribute scope.

This entry was posted in Azure AD, Exchange Online, Microsoft 365, Office 365, PowerShell. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.