Forum Discussion
MaxRie
Jan 23, 2024Copper Contributor
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...
- Jan 23, 2024
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
MaxRie
Jan 23, 2024Copper Contributor
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
Max
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
Max
LainRobertson
Jan 23, 2024Silver Contributor
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
- MaxRieJan 24, 2024Copper ContributorHi 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- LainRobertsonJan 24, 2024Silver Contributor
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- MaxRieJan 24, 2024Copper ContributorHi 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
Max