OCS 2007 R2 and Exchange 2010 RU4: “Did the remote peer accept our certificate”?
Configuring the link between OCS 2007 R2 and Exchange 2007/Exchange 2010 seems pretty easy, and it all boils down to:
- Getting the rights certificates:
- does the Common Name match the FQDN of the Exchange UM server, and the one used by OCS, does the Common Name match the FQDN of the Pool…
- are the certificate issuers trusted by both the Exchange Server and the OCS environment
- are the certificates still valid?
- Creating a Dial Plan in Exchange, and making sure the Location Profile matches the FQDN of that Dial Plan
- Running the ExchUCUtil script on the Exchange UM Server to set the needed permissions
- Running the OCSUMUtil tool on the OCS Server to create one or two OCS-Enabled users for the Exchange Subscriber Access &/or the Auto Attendant
- Double-check it all in the published guidelines, and then…TEST….:-)
And then when it doesn’t work….it’s time to troubleshoot. Today I’ve been busy troubleshooting an Exchange 2010-OCS 2007 R2 setup that refused to work…here’s a list of things run into…
Step 1. Log into Exchange and check the configuration of the Exchange UM Settings
As it turned out, Exchange didn’t run, and a closer look revealed that the installation of RU4 failed before. After restarting the installation of RU4, it succeeded, but there was no working Exchange, since all Exchange services were set to “Disabled”.
The following link helped to make sure all necessary services were started again: Overview of Services Installed by Exchange Setup
But next to these, make sure also the World Wide Web Publishing service is set to Automatic, and the IIS Admin service :-)
Here’s a print of an Exchange 2010 Sp1 Beta box, running Mailbox Server Role, Client Access Server role, Hub Transport Server role, and Unified Messaging Server role
Next problem… when using the Exchange Management Console, and getting the properties of the Exchange Server, the following error message popped up:
An error occurred while accessing the registry on the server "*****". The error that occurred is: "The network path was not found". It was running the command 'Get-AntispamUpdates -Identity *******’.
Solution there was to start the Remote Registry service…and set it to Automatic (since it was disabled in our case).
After double-checking everything both on the Exchange side, and the OCS side, still no luck in calling the Exchange AutoAttendant.
Step 2. Start a new debug session on OCS, and use the Snooper tool to find out where connection is dropped.
Including with this, we maximized logging for all Exchange UM properties. No luck, except for the error message stated in the subject of this blog post. Then time to check if all had been done to be able to install OCS 2007 R2 on top of a Windows 2008 R2! All prerequisites have been clearly documented in the following article:
It became clear that one step was forgotten:
Install the Hotfix that is described in KB 975858 for Windows Server 2008 R2.
975858 (http://support.microsoft.com/kb/975858/ ) An application or service that calls the InitializeSecurityContext function together with the ISC_REQ_EXTENDED_ERROR flag may encounter a TLS/SSL negotiation failure on a computer that is running Windows Server 2008 R2 or Windows 7 operating system
After requesting the hotfix, and installing it on both the Exchange UM Server (running Windows 2008 R2) and the OCS Server, time to reboot and try again….
And it failed again, but now with quite a bit of information in the Event Log….
Giving me information that made absolutely no sense at all like…
“The Unified Messaging server wasn’t able to retrieve the custom prompt data for the UM Dial Plan”… there was no custom prompt configured!
“The discover mailbox, a hidden default mailbox that is required to search mailboxes, can’t be found”….. but it did exist!
“The Unified Messaging server cannot find a valid UM hunt group”…. there was a valid UM hunt group, associated with the UM IP gateway!
“The Telephony Manager declined a call….”
And the a quick Bing search, got me to the following link: Accidental deletion of discovery mailbox , where David Strome posted the solution :-)
A Copy-Paste of the solution :-)
The UM team was able to reproduce this error using the steps that appear to have happened. The culprit seems to be the user SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}. If it's not properly enabled as an arbitration mailbox, this error can occur.
To try and resolve this, try the following in an Exchange Management Shell prompt:
Enable-Mailbox "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}" -Arbitration
If that completes successfully, then try calling the auto attendant again. If you don't get the error, great. If the Enable cmdlet failed, or you still get the error, try the following from an Exchange Management Shell window:
Remove-Mailbox "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}" -Arbitration
Get-User "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}"
Get-User "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}" -Arbitration
The "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}" user should no longer appear.
Then, from a cmd.exe window, run the following:
Setup.exe /PrepareAD
Once completed, open the Exchange Management Shell again and run:
Get-User "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}"
The "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}" user should show up as a regular user, not UserMailbox. Run the following:
Enable-Mailbox "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}" -Arbitration
This should enable the "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}" user as an arbitration mailbox.
Try to call the auto attendant again and see if the error occurs. If it does, let me know and please include any other error messages you receive either in the shell or in the event log.
David.Senior Technical Writer - Exchange This posting is provided "AS IS" with no warranties, and confers no rights.
I had to use Active Directory Users and Computers to delete the two System Mailboxes:
After that I ran Setup.com /PrepareAD:
Turned the SystemMailbox{{e0dc1c29-89c3-4034-b678-e6c29d823ed9} into an arbitration mailbox using the EMS cmdlet Enable-Mailbox:
And then the test…and it worked :-)
It was a fun day…happy everything worked when going home :-)
Thanks Pieter!
Ilse