When dealing with Office 365 environments that span multiple data centers, you might encounter issues related to accessing shared resources, such as shared mailboxes. These problems can manifest as the inability to “Send As” a shared mailbox or a complete loss of access within Outlook or Webmail. A common error message associated with this is “Can’t connect to the mailbox of user Mailbox database guid.” This article explores the causes and provides solutions to resolve this specific error.
One prevalent error you might encounter looks like this in Outlook:
“The specified object was not found in the store., Can’t connect to the mailbox of user Mailbox database guid: XXXX because the ExchangePrincipal object contains outdated information. The mailbox may have been moved recently. Email could not be sent. The message has been moved to your Drafts folder.”
Webmail users might see a more generic message:
“Your request can’t be completed at this time.”
Identifying the Root Cause: Mailbox Database Mismatch
The primary reason for these errors is often a mismatch in the mailbox database location. Specifically, when a user’s mailbox resides in a different data center than the shared resource they are trying to access, connectivity issues can arise. The data center location is often indicated by a specific naming convention within the database name. For example, in the database name “GBRP123DG075-db123,” “GBRP” represents the country location, and “123” signifies the data center. Discrepancies in these numbers between users and the shared mailbox can lead to access problems.
Diagnosing the Issue: Using PowerShell
To determine if a mailbox database mismatch is the root cause, you can leverage PowerShell to inspect the mailbox and database information. Connect to your remote PowerShell environment and execute the following command:
Get-MailBox | select Displayname,DatabaseThis command will output a list of mailboxes along with their corresponding database:
DisplayName Database
----------- --------
Owner 1 GBRP123DG081-db136
Owner 2 GBRP123DG077-db006
Discovery Search Mailbox GBRP123DG059-db037
User 1 GBRP123DG065-db120
User 2 GBRP123DG058-db105
User 3 GBRP265DG075-db123Carefully examine the output, focusing on the data center identifiers within the database names. If a user’s mailbox is located in a different data center than the shared mailbox, you have confirmed the source of the problem. In the example above, User 3’s mailbox resides in a different data center (GBRP265) than the others (GBRP123).
Resolving the Issue: Moving the Mailbox
The solution to this problem is to move the affected user’s mailbox to the correct database, aligning it with the shared resource’s location. To initiate the mailbox move, use the New-MoveRequest cmdlet in PowerShell:
New-MoveRequest -identity [[email protected]](/cdn-cgi/l/email-protection)Replace [[email protected]](/cdn-cgi/l/email-protection) with the actual email address of the user whose mailbox needs to be moved.
This command starts the process of moving the mailbox to the appropriate database.
Monitoring the Mailbox Move
To track the progress of the mailbox move, you can use the Get-MoveRequest cmdlet:
Get-MoveRequest -identity [[email protected]](/cdn-cgi/l/email-protection)This command will display the current status of the move request, including the target database:
DisplayName Status TargetDatabase
----------- ------ --------------
User 3 InProgress GBRP123DG071-db070The TargetDatabase field confirms that the mailbox is being moved to the correct database.
Conclusion
The “Can’t connect to the mailbox of user Mailbox database guid” error in Office 365 environments with multiple data centers is often caused by mailbox database mismatches. By using PowerShell to diagnose the issue and the New-MoveRequest cmdlet to relocate the mailbox, you can resolve this connectivity problem and restore access to shared resources. Regularly monitoring the mailbox move process ensures a smooth transition and minimizes disruption to users.
