Forum Discussion
Solved
Duplicate proxyAddresses sync error
Hello everyone, I have a problem and need help with the solution. We invite external people as guests to our Azure AD or Entra ID so that they can actively participate in Teams. Someti...
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.
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 Lain,
Thanks you for the explanation.
As far as I have understood, there is no solution for me. Because I need the email attribute for the local AD user for other internal applications, I cannot delete it. And since the guest user in the Entra ID may also need to receive emails, the email address must also remain there.
Is this correct?
If so, can I somehow whitelist these warnings so that I don't always see the same users of the warning, but instead only get notified about new sync warnings?
Cheers
Max
Thanks you for the explanation.
As far as I have understood, there is no solution for me. Because I need the email attribute for the local AD user for other internal applications, I cannot delete it. And since the guest user in the Entra ID may also need to receive emails, the email address must also remain there.
Is this correct?
If so, can I somehow whitelist these warnings so that I don't always see the same users of the warning, but instead only get notified about new sync warnings?
Cheers
Max
Hi, Max.
There are possibly ways around this, but it depends on how far you're willing to go.
One option (the one I prefer in such circumstances) for these people that need to be both on-premise and in Azure is to delete their guest account, leaving the "normal" account that originated from on-premise and synchronised out to Azure AD intact.
If you still have an Exchange Server (aka on-premise server) you could then use the Enable-MailUser (or GUI equivalent, but I don't use the GUI so I can't offer steps on that) commandlet against the on-premise account to ensure they're registered as an external contact in Exchange Online.
If you don't have an on-premise Exchange Server, it's still possible, but you have to alter the four or so Active Directory attributes manually, which is more than I can easily explain here.
An additional benefit of this approach is that it's less confusing for the user since they don't have to remember two sets of credentials when accessing your environment.
This lends itself to benefitting your Azure applications and services teams where they only have to manage access for one account instead of two (which can easily lead to mistakes).
But again, it's largely a question of how far you're willing to pursue this.
The one thing that's not negotiable though is that you can't have two people with the same mail address and not run into errors.
In not being a GUI user, I don't know if the Azure Portal offers any way to suppress the reporting of the errors. Certainly, the errors are going to remain persisted within the underlying data, but whether the Portal provides any relief of its own, I cannot say (though my suspicions is it won't).
Cheers,
Lain- Hi Lain,
thanks again for your support.
We have a local Exchange to manage the attributes. But I would also know which attributes I have to change in order to create a mail-enabled user from the user.
What I don't quite understand is:
If I would delete the guest user from the Entra ID and change the local AD user to a mail enabled user, then wouldn't it be the case that the local AD user would have to receive a Teams / SharePoint license from our company to be able to access Teams / SharePoint accordingly?
Or am I wrong here?
Wouldn't it then also be the case that the external user would not be able to work with their own company user in his Team-client, but would have to login with a second account (their user from our AD) instead?
Cheers
MaxHi, 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 mail <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
