Mar 29 2022 06:18 PM
Mar 29 2022 06:18 PM
Running 2 Exchange 2013 servers on 2012 R2 in a DAG. We have 2 mailbox databases.
Every few minutes am getting 31 1121 errors as below, with differing Request GUID's.
The Microsoft Exchange Mailbox Replication service was unable to process a request due to an unexpected error.
Request GUID: 'cbcde8dc-cee6-4016-849a-210d35c3a7a8'
Database GUID: '25af4ecf-7834-4c3c-b748-c23799877a9c'
Error: Database '8ddbf292-7634-4189-b342-0a3bb62c78dc' doesn't exist..
The database GUID beginning 25a... is one of our mailbox databases. 8dd... does not exist (it's not the GUID of the other database).
Things I've tried:
Remove-MoveRequest command using the request GUID. No such requests exist. get-mailboxrequest returns nothing.
ADSI edit. I've read that requests can appear in "Configuration/.../MailboxExportRequests" but there is nothing there.
Anyone know where these requests might be sitting to so I can remove them?
Mar 30 2022 07:13 PM
Thanks for the reply Thomas.
We are on CU23. We haven't conducted any mailbox moves recently so am not sure what these requests would have been for. I just noticed them but unforunately our logs only go back a week so am unsure when they started appearing.
Mar 30 2022 11:30 PM
Please check the Cluster configuration node of each server using RegEdit if there is an orphaned database entry.
Ideally, there are only two entries matching your two existing databases in the format \Private-GUID
You want to just check if there is such an entry from an older database that has not been cleaned up properly.
Did you check the Databases node on the AD configuration partition? Are there any orphaned database entries?
Mar 31 2022 03:32 PM
So there are 11 Private-GUID entries under the registry key you specified, including the guid mentioned in the errors. Same on both servers.
Under Config/Services/MS-Ex/Us/Admin Groups/Ex Admin Group/Databases there are only our existing 2 databases listed. Unless there was somewhere else?
Apr 05 2022 08:04 AM
This Cluster registry hive is often referred to as the Cluster Configuration Store. This information is used by the Windows Cluster Failover components.
Normally, Exchange removes a Private-GUID entry after the removal of a database. The cluster members communicate using DCOM. Sometimes this communication is blocked by GPO settings or misconfigured firewalls.
The Exchange Configuration node you mentioned (Config/Services/MS-Ex/Us/Admin Groups/Ex Admin Group/Databases) contains the information used by Exchange itself.
You can remove the orphaned entries in the cluster hive manually at your own risk. You should double-check the GUIDs with your existing databases.
Apr 06 2022 04:45 PM
I'll wait for a quiet(ish) time and start by removing one of the orphans, perhaps one that I can't see mentioned anywhere, then sit back and watch for any issues.
If that goes ok I'll slowly remove the others.