Forum Discussion
Duplicate proxyAddresses sync error
Hi, Max.
MOERA doesn't run for only mailboxes.
MOERA is triggered by any of the key mail attributes containing a value. Off the top of my head, these include:
- mailNickname
- proxyAddresses
And once MOERA has been triggered (it can take a short while - it's not instant), it will endeavour to populate the various Exchange Online-related attributes Azure-side. That's when you run into the "property conflict" errors.
With respect to ordering, I wouldn't think it matters, insofar as whichever was first should likely contain no error, while all subsequent introductions would fail with the property conflict.
Here's a contrived example I just created.
At the top there's two users with the same mail address. The entry that has a value for proxyAddresses (which is actually a guest user) has no error and MOERA was able to populate the proxyAddresses field. This is because it was created years ago and there was no conflicting entries.
The second entry is missing a value for proxyAddresses, which is a strong clue that there has been a provisioning error. I set mail (on the on-premise "Guest User" account) to the same address only a few minutes ago, so I expect this to be a conflict which has been found during the triggered MOERA process.
Checking the OnPremisesProvisioningErrors attribute of that second account, we do indeed see Azure telling us that proxyAddresses cannot be set as this mail address is already in use.
So, the outcomes here are that:
- Multiple users within Azure AD can contain the same mail address value; however
- This causes the MOERA process to fail updating other Exchange Online attributes; which leads to
- OnPremisesProvisioningErrors is updated to list (there can be multiple error items) the details of the conflict(s).
The resolution in my example is to change the on-premise value of mail for the second account.
If you want to remove the mail attribute from the Azure AD account (i.e. set it to null) that is "joined" to an on-premise account, it's more complicated as you can't set mail to null (see below for the "mail" attribute). Instead, you have to delete the user twice (the first produces a soft-delete and the second a hard delete), after which the account will be recreated on the next AAD Connect cycle.
This seems to be a Graph-induced limitation as AAD Connect talks directly to Azure AD and is quite happy to set mail equal to null.
Cheers,
Lain
since I didn't know exactly where the error should be, I just got everything with
Get-MgBetaUser -UserId "e164c9c4-24eb-4ffe-a0c8-012450aa288f" | fl
and looked at it. However, I could not find any errors. Maybe I'm looking at the wrong place?
In the first example, the guest user was in the Entra ID first and only then the AD user.
This is exactly where I would have expected the error because the guest user would have had to use the proxy address. But no
In the second example it is the other way around and this is exactly where the error is.
That somehow doesn't make sense to me.
Couldn't a solution for me be to delete the guest user in the Entra ID so that the AD user gets the proxy address?
Could I then somehow restore the user or would it have to be re-invited and all authorizations / access reassigned?
Or is there another way to somehow delete the proxy address for this user?
Cheers
Max
Hi, Max.
I don't know as I haven't tried "tricking" the system before - that's not my preferred path. You'd have to give it a go in order to know.
That said, I do think that it won't solve the error generation. MOERA is still going to trigger, run into a conflict and report an error no matter which order the accounts are tinkered with in.
So, if you remove one account so that the other can claim the address, and then bring the removed account back after that has happened, I'd expect that once MOERA has run, you'll simply find that the error simply transfers/manifests on that restored account.
Cheers,
Lain