The value “GUID value” of property archiveguid is used by another recipient object please specify a unique value

 

How to fix Office365 user provisioning issues that are generated by faulty Exchange attributes

The steps described in this article can be applied only to scenarios where you have the users synced from Active Directory. You can also have a local Exchange Server or you have recently decommissioned it, after the migration to the cloud was completed.

At the same time, if you are facing an issue where a cloud user was licensed and the mailbox was not provisioned at all, for instance you cannot see the mailbox in the list of active mailboxes from Exchange Online, this article will not help you, as this type of issue will not be addressed here.

These provisioning issues that are caused by wrong Exchange attributes  can be indentified with one of below symptoms:

• you have recently migrated the users from on-premises and you assigned them a license, but when an user is logging into Office365 portal he sees the Exchange apps with “Setting up” status.
• you have made some attributes changes in Active Directory for an user, for example you changed the user primary SMTP, and you noticed that these changes do not reflect to Exchange Online.
• some users  that have been provisioned as remote mailboxes are reporting they are seeing “Setting up” for OWA/People/Contact icons in Office365 portal, but if they browse to direct OWA url https://outlook.office365.com/, they can access their emails.

When I say “wrong” Exchange attributes, I mean that we have to deal in most of the cases with Exchange validation errors, where Exchange Online fails to validate some of the users attributes that are synced from AD.

In order to see if the affected user has a validation error in the cloud, you need to connect with  Azure AD PowerShell and run below command:
(Get-MsolUser -UserPrincipalName user@domain.com).errors.errordetail.objecterrors.errorrecord| fl

We will discuss in this article about 2 types of provisioning errors:
Part 1: Fixing provisioning errors related to ArchiveGuid mismatch:
“Failed to sync the ArchiveGuid 00000000-0000-0000-0000-000000000000 of mailbox 28b656595f-924b-4c5b-a4be-ea255450f  because one cloud archive 45e245ba67-a5ed-4408-8ced-a4d124521 exists”

Part 2: Fixing provisioning errors related to Archiveguid/ ExchangeGuid being used by another recipient.

•  The value “08073974-1902-4542-88ea-37ba310f0c5c” of property “ArchiveGuid” is used by another recipient object. Please specify a unique value.
• The value “ec5475a8-5b78-4c92-870b-cad24fcffa” of property “ExchangeGuid” is used by another recipient.Please specify a unique value.

Part 1: Fixing provisioning errors related to ArchiveGuid missmatch:
Failed to sync the ArchiveGuid 00000000-0000-0000-0000-000000000000 of mailbox 28b656595f-924b-4c5b-a4be-ea255450f  because one cloud archive 45e245ba67-a5ed-4408-8ced-a4d124521 exists

From my experience, around 90% of the provisioning issues are related to the ArchiveGuid mismatch. This means that we already have an active online archive for that user in the cloud , but at the same time this user is synced from AD with another value for ArchiveGuid. Exchange Online cannot validate this value, since it would mean to overwrite the existing cloud archive GUID, fact that will lead to losing the access to the archive data.

As you can imagine, we need to fix the issue in Active Directory, then the AADSync tool can sync to cloud the correct value for the faulty attribute, so it can match the value of his equivalent attribute from Exchange Online.

Depending on your on-premises configuration, there are 3 scenarios in which you can find yourself, each of them having a different fix.
For all these scenarios you have to identify first the validation error for affected user and after you applied the mentioned steps,  you must trigger the AADConnect sync, so the changes to be synced to the cloud as well.

IMPORTANT troubleshooting steps that can apply to all  3 scenarios:
In case you will follow the steps below to populate the ArchiveGUID, as per your scenario, and you notice that the changes are still not synced to the cloud, you might want to check below 2 aspects:
a) Make sure that MailNickName attribute is being populated for the affected users, in your Active Directory.
-by design AAD Connect uses a sync rule for Exchange attributes, that is triggered only for the users with “MailNickName” attribute populated.
-so you have to double check if this attribute is populated in AD for the affected users, otherwise any changes to their local Exchange attributes will not be synced to cloud.
b) Check the AAD Connect connectors configuration , to confirm that the local Exchange attributes are included in the synchronization schema.
-additionally, you might have to run again the AADsync configuration wizard, just to update the sync configuration with the Exchange attributes, in case you have recently extended the AD schema.

• Scenario 1

If you still have an active hybrid environment, in order to fix the archiveGUID mismatch issue,  you can run below command from local Exchange Management Shell:
Set-RemoteMailbox -Identity user@domain.com -ArchiveGuid ‘Value of the cloud archiveGUID’
If you don’t know the value of the cloud archive guid, you can get it from an Exchange Online PowerShell session:
Get-Mailbox user@domain.com | fl archiveguid

• Scenario 2

You no longer have an Exchange Server in your organization, but you still have the Exchange attributes in your AD schema.
I need to mention first that managing the Exchange Attributes for cloud users from AD PowerShell or from ADSIedit is not supported and we strongly recommend keeping an active Exchange Server in your Active directory with minimum roles, just for being able to manage the Exchange attributes that shall be synced to the cloud.
For more information about these recommendations, you might find interesting below public article:
https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx
Here you can see this mention:
“The question of whether a third-party management tool or ADSIEDIT can be used is often asked. The answer is you can use them, but they are not supported. The Exchange Management Console, the Exchange Administration Center (EAC), and the Exchange Management Shell are the only supported tools that are available to manage Exchange recipients and objects. If you decide to use third-party management tools, it would be at your own risk. Third-party management tools often work fine, but Microsoft does not validate these tools. “

However, you might want to use below steps, if you have only few users affected:
a) From a domain controller, open Active Directory PowerShell and run first:
     Import-Module ActiveDirectory
b) Run below command to store the cloud archiveguid in a variable:
     [guid]$guid = “Value of the cloud archiveGUID”
c) Set the ArchiveGUID property on the affected user:
    get-Aduser “UserAlias” | set-aduser -Replace @{msExchArchiveguid=$guid.tobytearray()}
 

• Scenario 3

You do not have any Exchange Server in the organization and you are also missing the Exchange attributes from your AD schema.
As you can imagine, since the attribute that you need to change is msExchArchiveguid, you won’t have this attribute available on the AD user attribute list.
Therefore, the recommended option is to install an Exchange Server with the Client Access role. That will help you extend the AD schema and will provide you access to Exchange Management Shell, from where you can edit any Exchange attribute.
Once you have a local Exchange Server, you can apply the fix from scenario 1.

DEMO

You can find below a scenario in which  I reproduced an user provisioning issue in my lab, where I have hybrid setup.
The affected user mailbox is called  provisioned1  and we can see in below picture what the user experience, when he goes to Office365 portal  page:

My affected user can connect with Outlook client and can access OWA if he goes to https://outlook.office365.com/owa, but he has into Office365 portal all Exchange apps greyed out.

I want to confirm if the user has indeed a validation error:

This user has also an active online archive in the cloud that works just fine.
The next step is to compare the ArchiveGUID value in on-premises for this remote mailbox, with the ArchiveGuid attribute value from Exchange Online.

Output from Exchange Online:

Output from local Shell:

I had to follow the steps from scenario 1: from local EMS I populated the archiveguid with the same value as in the cloud:

Set-RemoteMailbox -Identity provisioned1 -ArchiveGuid ’35bda72e-195b-4aa9-85f8-72874254331e’

Afterwards I have forced the sync for AD Connect  and the new archive GUID has been pushed to cloud and the issue was fixed.

Part 2: Fixing provisioning errors related to Archiveguid/ ExchangeGuid being used by another recipient.

In this part I will explain what should be done if you notice that your users are getting one of below validation errors:

•  The value “08073974-1902-4542-88ea-37ba310f0c5c” of property “ArchiveGuid” is used by another recipient object. Please specify a unique value.
• The value “ec5475a8-5b78-4c92-870b-cad24fcffa” of property “ExchangeGuid” is used by another recipient.Please specify a unique value.

These errors can generate a lot of issues. Besides the main issue, where all the Exchange attributes changes from on-premises are not being replicated into Exchange Online, the biggest issue is that you cannot migrate the users with such provisioning errors, as MRS verifies first if the Archiveguid (in case you want to migrate the archive only) or the ExchangeGuid of the object from Exchange Online is matching the equivalent guid attribute of the user from local Exchange server.

What can we do?
In order to fix this validation error, you will have to find the faulty user that is using the same guid: it can be another active user(a very rare scenario), but most likely a soft-deleted mailbox or a soft-deleted mailuser. Once you found this object, you will have to purge it from EXO directory, so your affected user can be provisioned properly.

Fix:

First use this command to get the ExchangeGUID/ArchiveGUID value from the validation error:
(Get-MsolUser -UserPrincipalName affecteduser@domain.com).errors.errordetail.objecterrors.errorrecord| fl

Search in EXO PowerShell for the object that is using the mentioned EXchangeGUID or ArchiveGUID:
Get-Recipient -IncludeSoftDeletedRecipients ‘ExchangeGUID value’|ft RecipientType,PrimarySmtpAddress,*WhenSoftDeleted*

Once you found the object that is using this ExchangeGUID or ArchiveGUID, you have to purge it:

1. If it is a softdeleted MailUser:
Remove-MailUser ‘ExchangeGUID value’ -PermanentlyDelete
2. If it is a softdeleted UserMailbox, run:  
Remove-Mailbox ‘ExchangeGUID value’ -PermanentlyDelete
-if this command fails due to mailbox being protected by hold, you have to disable the hold first(check if data backup is required):
Set-Mailbox user@domain.com -LitigationHoldEnabled $false -InactiveMailbox
3. If it turns to be an active mailuser/mailbox that is using this ExchangeGUID/ArchiveGUID, you need to evaluate the option to purge that user.
4. After the faulty object has been purged from EXO, we need to fix the validation error by forcing the object provisioning:
Get-MsolUser -UserPrincipalName user@domain.com |fl *objectID*
Redo-MsolProvisionUser -ObjectId ‘paste the *objectID* value from above command’
5. Wait for 5 minutes and then run the next command, to confirm if your validation error is fixed:
(Get-MsolUser -UserPrincipalName user@domain.com).errors.errordetail.objecterrors.errorrecord| fl
Please note that usually the “redo” command should force the user provisioning in a few minutes, but it can happen sometimes to take several hours.

Demo
I will practice the above fix in my lab, against an user that has the validation error “ The value “08073974-1902-4542-88ea-37ba310f0c5c” of property “ArchiveGuid” is used by another recipient object. Please specify a unique value.”
  
In my case I found that the user causing the conflict is actually a soft-deleted mailuser copy of the affected user:

The user called Aduser1 has a on-premises mailbox and in EXO it is synced as a mailuser. A while ago I have moved this AD user account into an OU that was not synced to the cloud, fact the caused the deletion of the msoluser from Azure AD and at the same time the associated maiuser object from EXO was also softdeleted.
If you will going to purge the soft-deleted msoluser from Azure AD, this action will not trigger also the purge of the associated mailuser from EXO and you will end in the same scenario as mine, when the soft deleted mailuser will still be retained for 30 days, unless you decide to purge it manually, with “Remove-MailUser -PermanentlyDelete”
Going further with the steps, we will purge the conflicting mailuser and we will force the user provisioning afterwards: