Exchange Solutions

While deploying an Exchange server, you may run into the following error during setup, which will block the installation from continuing.

[07/01/2020] ErrorRecord: Cannot find an overload for "CompareTo" and the argument count: "1".
[07/01/2020] ErrorRecord: System.Management.Automation.MethodException: Cannot find an overload for "CompareTo" and the argument count: "1".

This error is definitely cryptic. Thankfully the Exchange Setup Logs (located at “C:\ExchangeSetupLogs\ExchangeSetup.txt”) is excellent at providing more clues when troubleshooting.

In our case, the logs identified that setup was trying to process the Offline Address Book (“OAB”) at the time of the error. The error occurred during a function that contained OAB-related PowerShell commands, including Get-OfflineAddressBook, Get-OabVirtualDirectory, and Set-OfflineAddressBook. So, this was the logical place to continue troubleshooting.

From another Exchange Server, we ran the PowerShell command Get-OfflineAddressBook, and strangely, three address books were returned.

 C:\> Get-OfflineAddressBook | Format-List Name

Name: Default Offline Address List
Name: Default Offline Address List (Ex2013)
Name: Default Offline Address List (Ex2013)
      CNF:3e4b413a-e5d6-4371-8541-defecb812f98

The returned results were strange.

• Default Offline Address List is an OAB from a legacy Exchange installation (Exchange 2010 and earlier) and is common to see in an Exchange environment.
• Default Offline Address List (Ex2013) is present whenever an Exchange 2013 or 2016 server is installed into a legacy Exchange environment. This address list is standard, and it is common to see both this OAB and the first OAB coexisting in mixed Exchange environments.
• Default Offline Address List (Ex2013)CNF:<GUID>, is an address list I had never seen before.

Default Offline Address List (Ex2013)CNF:<GUID> being an unknown quickly became the focus of our investigation.

When introducing a new Exchange Server into your existing Exchange environment, the installer may throw the error “Database is mandatory on UserMailbox” and prevent you from continuing.

If you examine the Exchange Setup Logs (which can be found at “C:\ExchangeSetupLogs\ExchangeSetup.txt”) you may find a few more clues as to which mailboxes are missing their databases parameter.

Towards the end of our Exchange setup log, we found the following two error lines.

[07/01/2020] [1] [ERROR] Database is mandatory on UserMailbox.
[07/01/2020] [1] [ERROR-REFERENCE] Id=SystemAttendantDependent___04cc4eded45c32a6bf14ee3fe543df60 Component=EXCHANGE14:\Current\Release\PIM Storage\Discovery

The key here is “SystemAttendant.” The System Attendant is an arbitration mailbox. Let’s check on the health of all our arbitration mailboxes. We can do this by entering the following command into the Exchange Management Shell.

 C:\> Get-Mailbox -Arbitration | Select Name | Format-Table

Name
----
SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}
FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042
SystemMailbox{1f05a927-7f83-496b-a118-a96cdde1cd3c}
WARNING: The object SKARO.LOCAL/Users/SystemMailbox{1f05a927-7f83-496b-a118-a96cdde1cd3c}
has been corrupted, and it's in an inconsistent state. The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.
WARNING: Database is mandatory on UserMailbox.
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}
SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}
Migration.8f3e7716-2011-43e4-96b1-aba62d229136
SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA}

The output from this command identifies that we have a single broken system mailbox.