Incorrect or missed configurations can lead to errors causing mailbox provisioning failures. One such error, often encountered in the Microsoft Admin Center, is represented by the message: “Exchange Online: An unknown error has occurred. Refer to correlation ID GUID.” This post will help you understand how to identify the cause of this error and provide steps to resolve it.

Understanding the Problem

The error message “Exchange Online: An unknown error has occurred. Refer to correlation ID” typically occurs due to a configuration provisioning failure for a user mailbox. For instance, if a user with a valid mailbox requests to be removed from Exchange Online, the user might be unassigned the license and disabled from AD. However, the account may still appear in Exchange Online.

When selecting the user in the Microsoft Admin Center, this error message might appear. So, how can you find the real cause of the error?

Identifying Provisioning Errors Using the MSOL Module.

Using the MSOL Module is the simplest way to identify provisioning errors, although Microsoft has deprecated it in favor of the Graph SDK for PowerShell. Here’s how you can use the MSOL Module.

  • Open Windows PowerShell 5.1
  • Import the MSOnline module and connect to the MSOnline Service
Import-Module MSOnline
Connect-MsolService
  • Run the following command to find users with provisioning errors
Get-MsolUser -HasErrorsOnly -All
  • Identify the user with a failure and run
(Get-MsolUser -UserPrincipalName MyUser@MyDomain.com).errors[0].ErrorDetail.objecterrors.ErrorRecord.ErrorDescription

This command will provide the exact reason for the provisioning error. Common errors include

  • Litigation Hold Issues: “Exchange can’t disable the mailbox because it is on litigation hold.”
  • Duplicate Archive GUIDs: The value GUID of property “ArchiveGuid” is used by another recipient object. Please specify a unique value. error message can be
    Failed to sync the ArchiveGuid 00000000-0000-0000-0000-000000000000 of mailbox 3960d7c0-9c2e-45ce-9d88-6b96658c32ac because one cloud archive 4422f4b0-a8c0-4c33-b7a0-6d4d27acb2f2 exists.
  • An object doesn’t have a valid SMTP: The mailbox d7615ef8-c23a-c23a-c23a-397717def0e5 doesn’t have a SMTP e-mail address.
Failed user

Oh, by the way, I wrote a post on how to fix the Archive Sync issue,

FIX: Exchange Failed to enable the new cloud archive using PowerShell

Using PowerShell 7 to load the MSOnline is not supported and you will get error
Connect-MsolService: Could not load type ‘System.Security.Cryptography.SHA256Cng’ from assembly ‘System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’

But the MSOnline module won’t be there forever, and soon it might disappear, so we much switch to graph.

Transitioning To The Graph API To Find Provisioning Errors

The MSOL Module will not be available indefinitely, so it’s essential to transition to using the Graph API. As of now, error details are available in the beta version of the Graph API. Unfortunately, the Get-MgBetaUser command doesn’t return the full error information, requiring us to use Invoke-WebRequest to fetch the details.

Here’s a complete script that supports pagination, useful if you have many users:

PowerShell Script to Fetch Provisioning Errors Using Graph API

You can copy and paste this script in your ISE or VSCode and only update the $tenantId, $clientId, and $clientSecret


# Define your Azure AD application details
$tenantId = "Get you Tenant ID" #Change This value
$clientId = "Create an App Regisration with User.Read.all" #Change This value
$clientSecret = "Secure your key" #Change This value
$scope = "https://graph.microsoft.com/.default"

# Build the token request URI
$tokenRequestUri = "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token"

# Define the request body
$body = @{
    grant_type    = "client_credentials"
    scope         = $scope
    client_id     = $clientId
    client_secret = $clientSecret
}

# Make the token request
$response = Invoke-RestMethod -Method Post -Uri $tokenRequestUri -ContentType "application/x-www-form-urlencoded" -Body $body

# Extract the access token
$accessToken = $response.access_token

# Define the authorization header
$headers = @{
    "Authorization" = "Bearer $accessToken"
    "Content-Type"  = "application/json"
}

# Define the request URI
$requestUri = "https://graph.microsoft.com/beta/users?$select=id,userPrincipalName,serviceProvisioningErrors"

$response = Invoke-WebRequest -Uri $uri -Headers $headers -Method Get
# Parse the response
$result = $response.Content | ConvertFrom-Json
$allUsers=@()
if (!($result.'@odata.nextLink')){
    $allUsers += $result.value | Where-Object {$_.serviceProvisioningErrors -notlike $null}
}
else {
    do {
        write-host "Loading Page" -ForegroundColor Green
        $response = Invoke-WebRequest -Uri $result.'@odata.nextLink' -Headers $headers -Method Get
        $result = $response.Content | ConvertFrom-Json
        $allUsers += $result.value | Where-Object {$_.serviceProvisioningErrors -notlike $null}
    
        # Update the request URI to the next link, if it exists
        $uri = $result.'@odata.nextLink'
        Write-host "Getting to the next page.. Please"  -ForegroundColor Green
    } while ($uri -ne $null)
}

$allUsers | select userPrincipalName, @{n="Errors";e={([xml]$_.serviceProvisioningErrors.errorDetail).ServiceInstance.ObjectErrors.ErrorRecord.ErrorDescription } }

The result of the above script is a list that contains the username and the error message

And now you know why the user has the error, all you need to do is fix these points and the provisioning will move forward.

Conclusion

By following the steps outlined above, you can identify and resolve provisioning errors in Exchange Online. Transitioning from the deprecated MSOL Module to the Graph API is essential for future-proofing your troubleshooting process. Implement these solutions to ensure smooth mailbox provisioning.

5/5 - (1 vote)