Error with Set-Mailbox -identity -WindowsEmailAddress

Question

Our organization will sometimes have the default return address on someone’s mailbox get set incorrectly (@onmicrosoft...). From a powershell properties standpoint this is governed by the WindowEmailAddress property, which is not accessible to set from our Active Directory and must be set via powershell. We use Exchange Online.

The only way to fix this is to run a set-mailbox command and set the WindowsEmailAddress property. Here’s the command:
Set-Mailbox -identity user@keyman .org -WindowsEmailAddress user@keyman .org

This has always worked for us, but is currently failing and returning this error:

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: 601cbb66-6ecb-4d0e-a49a-e4c1b34f638f
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=(redacted),RequestId=9089622f-171a-4e64-940e-16a03d377d61,TimeStamp=4/11/2022
5:44:57 PM] [FailureCategory=Cmdlet-UnableToWriteToAadException] 32AC7017,Microsoft.Exchange.Management.Recipient
Tasks.SetMailbox
+ PSComputerName : outlook.office365.com

Troubleshooting done:
-I have tested this set-mailbox command against other accounts and they give the same error.
-I have tested other Set-Mailbox commands in this environment and they work successfully.
-I logged in to our AAD sync server and it is indicating success in sync cycles.
-We are not migrating any accounts in Azure
-I logged in to Azure Active Directory admin console to see if I may edit the address there and I cannot

Answer 1

For the record, this has never been a supported scenario, just a workaround. Changes need to be made on-premises, if you want them to persist.
In any case, this was certainly a useful workaround, and it will be a bummer if Microsoft decided to can it. I'll try to repro with my test tenants.

Answer 2

Apologies for not updating sooner - unfortunately the answer that it doesn't work anymore seems to be the actual answer.