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

You might get an error like this one:

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, 90% of these type of 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 AD Connect tool can sync to the cloud the correct value for the faulty attribute, so it can match the value of his equivalent attrribute 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 AAD connect sync, so the changes to be synced to the cloud as well.


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


IMPORTANT mention that can occur in all 3 scenarios:

It is good to be aware of the fact that once you have extended the AD schema and you have populated the affected Exchange atrributes, you can notice that the none of these atrributes are synced to cloud, even after you forced the sync for several times. The main reason for this behavior is the fact the AAD Connect uses a sync rule for Exchange attributes that will be triggered only for the users with “MailNickName” attribute populated. So you have to double check if indeed this attribute is populated in AD for the affected users, otherwise their local Exchange attributes will not be synced to cloud.




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.



If you get other validation errors which are not related to archiveGUID mismatches , but to other Exchange attributes, and you are not sure about how to proceed further, please open a case with our support team.


Comments (9)

  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.

Skip to main content