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
Hi, Max.
I wasn't overly-methodical in my approach since I set all the "usual suspect" attributes in one pass, but the ones I set were:
| Attribute | Value | Example |
| <the external mail address> | lain_robertson(at)hotmail.com | |
| mailNickname | <the prefix of the external mail address> | lain_robertson |
| msExchRecipientDisplayType | 6 | 6 |
| msExchRecipientTypeDetails | 128 | 128 |
| targetAddress | <same as mail above> | lain_robertson(at)hotmail.com |
Note: These forums strip out mail-like addresses, so I've used "(at)" instead of the "@" symbol in the example values.
With respect to the licencing, yes, the synchronised account from Active Directory would need to have the licences transferred off the Azure guest account onto it - if it needs any, that is.
So, it's no extra cost. It's just moving the licencing from one account to the other if necessary.
It's worth noting though that no licence is required to exist purely as an Exchange Online "mailuser" object. If they need to exist as a "mailbox", then they will need a licence, but not for just a "mailuser".
And yes, you're right about the impact on Teams and logging in twice. But given Teams just added the ability to log in to multiple accounts concurrently, this ought not to be a big issue.
But now matter how you try and work it, they're going to have to use two logins at some point anyway, since to access the internal Active Directory resources, they're having to use those credentials instead of their Azure guest credentials anyway.
It sounds like a little bit of a "six one way, half a dozen the other" kind of scenario you're facing, where nothing really represents a perfect answer.
Don't read too much into this next statement as I don't know nearly enough about the relationship between your company and theirs, but I can't help wondering if other options relating to classic Active Directory forest trusts combined with Azure guest users might not have been a "better" path. The administrative overhead would be greater but it could bring the remote partner closer to an SSO experience
Or another option could be using AAD Connect to filter out the on-premise Active Directory partner accounts if they don't actually need to be in Azure (which would implicitly solve all potential conflict scenarios), meaning they'd continue to use their Azure guest account for all Azure stuff. (Not that this would have any bearing on the partner still needing to know how to use two accounts.)
Anyhow, don't overthink those as they're way off topic from where this all started. Just figured I'd drop it in here in case you wanted to do your own research on it.
Cheers,
Lain
Thanks again for the detailed explanation.
However, there is one point where I have to disagree, or rather, I have to ask for clarification.
You write:
„With respect to the licencing, yes, the synchronised account from Active Directory would need to have the licences transferred off the Azure guest account onto it - if it needs any, that is.
So, it's no extra cost. It's just moving the licencing from one account to the other if necessary.“
But we do not give licenses to external users in Entra ID. The external user has received his license from his own company and can therefore access SharePoint/Teams.
However, if I then delete the external user in the Entra ID and the external user uses the internal user from the AD, he then again needs a license that WE have to provide him with.
This means that there are extra costs involved.
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
- Hello 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.
Yes, your picture appears to make perfect sense (I'm making an assumption at this stage).
Rather than checking the guid beginning with "ad9b" from your first set, you want to be checking the one beginning with "e164". Remember, it's the one without a value for proxyAddresses that will feature the error (if there are any).
This comes back to what I mentioned about which was populated first:
- From the first batch of two, "ad9b..." was the first to claim "stefan.kampkoetter".
- In the second batch, "04a8..." was the first to claim "andre.rauer".
It's not about guest vs. member - the type of user has no bearing on this - nor does being synchronised vs. Azure-native. It's purely first in wins, with anything later losing the right to that mail address featuring in the proxyAddresses.
Cheers,
Lain
Hi Lain,
as I mentioned at the beginning, I only have this error in some cases and not in others.
I have now picked out one case where the error does not occur and one where the error does occur.
According to your statement, this should not be the case.
Can you explain to me why I don't get an error in the first case?
Cheers
MaxHi, Max.
Azure licencing is an absolute minefield, but if you're only leveraging SharePoint and OneDrive external sharing (linked below) then you're correct, and there would be additional cost if you removed the guest account.
I'd mistakenly assumed the guests might be accessing more than that, which is what my comments around transferring the licencing related to.
We operate in both the B2C and B2B spaces where access to more than just SharePoint is required, so for us, we are frequently required to add additional licences on our side at our cost.
If the on-premise Active Directory accounts are exclusively to provide these external people with access to domain-joined resources and you don't need those Active Directory accounts synchronised into Azure, perhaps consider my earlier suggestion that it might be easier just to exclude these new Active Directory accounts from being synchronised to Azure via AAD Connect. That would solve your conflict problem and allow you to not have to make any changes Azure-side at all.
Cheers,
Lain
