Forum Discussion
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.
Sometimes it is necessary that the same external person also needs a user account in our local environment (AD), for example to access servers or similar locally in the environment.
In the local environment, the user is created in AD (no email mailbox) and only the "Email" field is filled in, as some applications read this attribute and send emails to this address. The "proxyAddresses" field is NOT filled in.
If I then try to synchronize the external user with the Azure AD / Entra ID, I get the message that the "Proxy Addresses" of the guest user and the user in the AD are identical, which gives me a synchronization error.
It's hard to imagine that I'm the only one with this problem. Nevertheless, I have not yet been able to find a solution.
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.
This is expected as an Azure AD-side process named MOERA will calculate what should go into proxyAddresses based on on-premise attributes like mail and userPrincipalName (amongst others).
You can read about it here, where from your description you'll be hitting Scenario 2:
You cannot use the e-mail address from the external guest user on the on-premise account's mail attribute.
Cheers,
Lain
- Hello Lain,
I've skimmed the article but I still don't understand why Entra ID means to set a proxy address for the AD user. The local AD user has no email mailbox, is not an email active user, is not included in any email distribution lists, ... Only the email field is filled in for the user.
Your last sentence was:
„You cannot use the e-mail address from the external guest user on the on-premise account's mail attribute.“
But I have several examples where I have exactly the same situation. This means that a guest user exists in Entra ID as well as in the local AD and is synchronized into Entra ID. And both objects have the same e-mail address. And I do not receive an error message for this user/guest.
Is this possibly related to the order in which the users are created (first guest or first AD user)?
Cheers
MaxHi, 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
