About Me

My photo
TsooRad is a blog for John Weber. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


Exchange 2010 EMC & EMS winrm “access is denied”

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 Situation

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.

The Fix

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.



Unknown said...

I literally cannot thank you enough.
This had me stumped and for some reason, that I also cannot explain this worked first time.

Unknown said...

I literally cannot thank you enough.
This had me stumped and for some reason, that I also cannot explain this worked first time.

Argahlji said...

Where did you remove the cert from? Local User Computer or Exchange Server?

tsoorad said...

Argahlji, the cert is removed from the local computer personal container.

Sfb 2019 July 2019 CU

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...