Fellow CDW-ite Andrew Hunkins has written a nice level 200 description of Lync 2013 Pool Pairing.
Four hours of my life gone.
I had a customer call and say that on ONE of their Exchange 2010 servers the EMC would not open.
The EMS would give this error: “Connecting to remote server failed with the following error message : Access is denied.” PowerShell would then happily connect to another server in the site.
The EMC would simply go nowhere with a message that “kerberos authentication failed.” How nice.
My user was in the Organization Management group, domain admins, and almost everything else needed to install, configure, and be a super-admin in Exchange 2010. The server was a member of the Exchange Servers group. The server, a multi-role server, was still hosting active mailboxes and delivering mail. OWA worked just fine. There were no user complaints of Exchange services not being rendered in any way, shape, or form. Just that the EMC would balk at the failed Kerberos and then be useless, and the EMS would not connect locally, but would connect to another server.
We checked: IIS, PowerShell vdir, perms, auth, bindings, winrm quickconfig, net time, SPN’s, user accounts, Exchange component group membership, IIS webconfig files. We removed registry entries, files and folders in the user profile, and spattered chicken blood on the walls. I must have read about 100 different websites, blogs, and forums. They all had the same information, and none of it worked. Some of the advice was inane, recommending removing exchange, or just slapping in the next SP. Take a gander at this forum thread; it contains a pretty good approximation of the issue and the failed resolution.
I then found this article. Down at the bottom, there was a suggestion that this could be a certificate problem, but the solution was to put the self-signed Exchange server cert into the Trusted Root store – see below. This just had to be wrong, right? WTF?
Figuring that I had already failed for the last 225 minutes, I had nothing to lose. Well, what do you know! 15 seconds of copy and paste, and the EMC and the EMS are functioning normally again. I then removed the self-signed cert from that store, and the EMC and EMS still work. Having trepidations over that action of removing the cert that appears to have resolved the issue, I put the cert back into the Trusted Root store just to be safe and retested. Still works.
I sit here, pondering on how and why this fix worked. And I cannot come up with a good answer. Maybe someone, someday, can explain it to me.
It would appear that Veeam does not play well with volume mount points. At a recent project, we migrated into a new Exchange 2010 environment using volume mount points attached to c:\volmtpt – Veeam would see the empty folder, but never the contents.
We were providing the the raw drive space with RDM. So we tried the same drive space, but mounted as a direct drive. Veeam could not see that either. Veeam support forums hinted that RDM may or may not work – apparently depending on the phase of the moon. There are some folks who claim to have it working – but not me.
In the end, we went with raw drive space vmdk. Now it works as expected. But what if you don’t want 24 drive letters? Or even more than 1? Windows Server Backup, in the same scenario had no issues with the mount point construction.
WASSUP WID DIS?
Script to update sfb 2019 install to enable the new control panel contained in the SfB July 2019 CU. Add-WindowsFeature RSAT-ADDS, Web-Serve...