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, 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| 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 -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 | 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:

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.





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, 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.




First use this command to get the ExchangeGUID/ArchiveGUID value from the validation error:

(Get-MsolUser -UserPrincipalName| 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 -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 |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| 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.




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:



Comments (11)
  1. Alex Populeanu says:

    This is an amazing article that is applicable for a wide spectrum of root causes, starting from standard provisioning issues to failed migration users.
    Congrats for this great knowledge sharing!

  2. Adam Morris says:

    I tried Scenario 2 with no luck. I have the exchange schema and I can see the attributes go into AD correctly. The sync completes using AAD connect and shows the update but when I go to the user in Office 365 they still display as Exchange: Failed to sync the ArchiveGuid 00000000-0000-0000-0000-000000000000. Anyone got any ideas?

    1. Adam Morris says:

      After some trial and error I worked out what to do. Once all the required attributes were added to the AD user and synced to Office 365 using AAD Connect I needed to force the Office 365 account to “reprovision”. I did this by moving the user to a non-synced OU and running a delta sync which moves them to “deleted”. I then moved the user back into a synced OU and ran another delta sync, thus restoring them. When the system restores the account it uses the recently synchronised “new” msexharchiveguid. The error disappears and the Office 365 account provisioning process completes fully and we are back to a normal functioning account.

      As Nic mentions the MailNickName is key as without that your msexcharchiveguid will not get synchronised anyway.

      Hope this helps someone when your chips are down..

      1. Nicu Simion says:

        Hi Adam,
        Thanks a lot for sharing your experience with us. I am pretty sure that it will be useful to other persons that will encounter this issue.

        Sometimes, when you have already populated the AD user with the proper ArchiveGUID, there are other factors that can impact the synchronization of the new attributes to the cloud.

        Besides double-checking MailNickName attribute, most of these issues are related to AAD connect configuration, as when you do not have an existing Exchange Server, it can happen that the synchronization schema to not be extended with the Exchange related attributes. To fix this issue, you have to run again the AAD connect wizard, to refresh the list of attributes that are being synced to the cloud.

  3. Fazal Zaidi says:

    Thanks for such wonderful knowledge sharing!

  4. JJ says:

    I’m getting the error (when looking at the MSOL object) stating ‘The value “921acb7b-5357-4885-9e59-cb4f4ff37c53” of property “ArchiveGuid” is used by another recipient object’
    The user mailbox and archive mailbox have not yet been migrated – but they won’t migrate due to this error. I’ve searched all objects for this archiveguid and it doesn’t exist anywhere. I’ve removed all inactive mailboxes, removed all mailusers from Exchange Online soft deleted area… but as soon as I sync the object again, the error is there immediately. Any ideas?

    1. Nicu Simion says:


      Thank you for your comment. As per your error message, it looks like that archive GUID is already present on another object in EXO, it could be an active or a soft deleted mailbox/mailuser. Can you please check if you don’t have any soft deleted mailuser that has the same ArchiveGUID:
      Get-MailUser -SoftDeletedMailUser|fl PrimarySmtpAddress, *guid*
      If above command returned you any results, you should purge that user using below command:
      Remove-MailUser -PermanentlyDelete
      Once the softdeleted mailuser was purged, you can do the re-provisioning of affected user with the next command and then check if the validation error is gone:
      Get-MsolUser -UserPrincipalName |Redo-MsolProvisionUser

  5. Navjot says:

    This is great, this helped us fixing the exact same issues we had.
    We used scenario 3 in this case as we recently decommissioned the exchange server and didn’t had exchange in our environment. For that, we did re-installed exchange with CAS role only.
    However, can you please advise if we can go ahead and remove/uninstall the exchange server again once the GUIDs are fixed.?

    1. Nicu Simion says:


      Our advice is that if you still have the users synced from Active Directory, it is recommended to keep the Exchange CAS role (doesn’t need a license). It is possible that in the future you will need to change some particular Exchange attributes for your cloud users, that will require a local Exchange server to perform these changes.

  6. Isaac Gonzalez says:

    For scenario 3, it was not necessary for me to install exchange server. I merely just had to run setup /preparead /organizationname: using the exchange setup, and it extended the schema for my environment. There was also an issue with the way azure ad connect was installed since it didn’t pick up the extra attributes, so I uninstalled and reinstalled, chose exchange hybrid, and it picked up the msarchiveguid changes for the users affected. Thanks for this excellent post. Has already helped me twice.

  7. Geni Hawkins says:

    Thank you! I was tearing my hair out this morning over scenario #2. This worked perfectly.

Comments are closed.

Skip to main content