Cannot open EMC or EMS

Question

I am stuck.  I cannot open the EMC or EMS on either the Exchange 2010 server (all roles are on a single server) or on another server that I have the management tools installed on, both of which are Server 2012 R2.  I keep getting Access Denied,
though at times it was Internal Server error (see below).
What I have tried already:
EMTshooter - could not determine the problem "Could not connect to any Exchange server in the current site.  problem found: looking for error... unknown error"
Verified that kerbauth is registered on the PowerShell virtual directory and only the PowerShell virtual directory (Native/Local)
Ensured that SSL is not required on the root (Default Web Site), that it is required on the various virtual directories, except PowerShell, which it is NOT required on
Ensured that there is no redirection going on with any virtual directory or the root site
Verified the account is a member of the Organization Management Exchange Security Group and that that group is in the correct AD OU
Tried adding another Domain Admin account to the Org Mgmt group, and connecting as that user but same results
Tried resetting the Administrator profile and clearing all the cache files
Ensured the permissions on the physical directory grant my user (administrator, the account used to install exchange in the first place) access to it
Ensured it is pointing to the correct directory (C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell"
Gone through the web.config file at that location and replaced instances of %ExchangeInstallDir% with the actual path (C:\Program Files\Microsoft\Exchange Server\V14\)
Verified there is no web.config found at C:\inetpub\wwwroot
Verified in ApplicationHost.config the entry for WSMan (image="C:\Windows\system32\wsmsvc.dll")
Verified in ApplicationHost.config the entry for kerbauth (image="C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll")
Verified no duplicate SPNs exist on the machine
Verified the account has remotepowershellenabled:$true
Ran WinRM quickconfig which returned the expected results
Went through the steps provided by David Strome in his EMC Permissions Part Deux posting up to step 6, where I ended up getting Access Denied as well
Checked with ADSIEdit and it appears the management rolls are as they should be
Get-ManagementRollAssignment also appears to return expected values (when run from a PowerShell  session that has had the microsoft.exchange.managment.powershell.e2010 snap-in added); however, cannot run Get-ExCommand in that same PowerShell session
Ensured that Outlook is not and has not previously been installed on this machine (* as best I could... do not have entire history of the machine available)
The configuration of the machine is as so:
Exchange 2010 SP3 with Update Rollup 6 on Windows Server 2012 R2 fully patched and updated.  It is utilizing a certificate issued by the Enterprise Root CA which is also on the same server.  This certificate has the subject name of owa.domain.com
with an SAN of autodiscover.domain.com.  The internal domain is the same thing, but .local, however, the virtual directories have been configured with both internal and external URLs that are identical and use the external name.  DNS has been configured
the resolve the external names to the internal IP address for internal clients.  It is the server replacing a 2003 Exchange server (different machine, obviously) which is still online.
The issue reared its ugly head because there was one user still on the 2003 machine that needed to be moved to the 2010 machine and when trying to open the console to create a move request, that's when it was found we could not get into the console.
During the above troubleshooting, there was a time when it was instead returning "cannot determine the content type of the HTTP response" and when I analyzed a Network Monitor capture of the conversation it was actually receiving a 500 - Internal
Server error response instead, but this was only for a short while and it has returned to the Access Denied messages.
I get the message whether or not I access via the Exchange Shell or Console.  However, I can open PowerShell, add the exchange snap-in and run commands against the server.  I cannot, however, create a new-pssession. 
Enabling failure tracing on IIS for the PowerShell directory, the trace indicates the problem is that a parameter is incorrect:
Message
Failed to establish a secure encrypted connection.
Context
DoAuthentication
ErrorCode
The parameter is incorrect. (0x80070057)
However, what that parameter is, I have no clue since the request headers looked like this:
Connection: Keep-Alive Content-Length: 0 Content-Type: application/soap+xml;charset=UTF-8 Authorization: Kerberos YIIHOAYJKoZIhvcSAQICAQBuggcnMIIHI6ADAgEFoQMCAQ6iBwMFACAAAACjggWjYYIFnzCCBZugAwIBBaERGw9URU1QU1BMVVMuTE9DQUyiKDAmoAMCAQKhHzAdGwRIVFRQGxV0cHMwMy50ZW1wc3BsdXMubG9jYWyjggVVMIIFUaADAgEXoQMCAQKiggVDBIIFP5oYMjQ0bsXyMWhIfdYzVm6zJupBr2d11M0XQQcssgiWBg2VKIoOtZ2a9ZU7mJlS45jEBn+upJ4BA1qRUezOLdAZYL6EXVZLePPPSlsRgOcCkjHWMh+Ax2uo0Mfx7OYk+mAf6pYi/4tnY2UEvZZwWaYKZtYtS0L0FodkrgKeneL27NayhbdidzYjXm5ek5DxGJnO7cJfrGWs3Bl153p95IQpRYMfqjByxqCw+UT4Ll2uK10H4s6hdARmXgrH3pzRvn6+9vRa5YFkzerWExXPUoNgt4EmKWMl9gDQizVmUN9xsPkbThv/Tz6/e7NyM8WbLaISLspilF8teoThsOdTLLL2YOgNktjcXkAvX5uigdLhwgoOwPCQT9CW3m+57RszxvuaprQpuSq3c0D9k1b9Lcy4nszNRuRrZRhurZ9d2uF7NsAdpVX0PRBeoR7j6GYCFW7LgYFOPzquNQ4HIY94k1yoGuc1TnsTV9Oko+8YklrNCvNucAada33gZ+aLOjCquaPQsbIplDDz+RG3ZSWAmu3dBL6ht6zXSA2RfDvK3um9sIYB4A6tYO9OhY1vyV1GtI/TcFMIIYf2U6NqoPihcGtWpZL0g9fKE4cdPw9NqUi2AQHseH+qO9TGu9D9jeAS+olbWU5XcCGCdkZXVh9xLCuGOW5q8SgcOYtlU9UD+iWRiaaYyvPjdYsxWF2vH3aiVmZH07052RA0jf5Ueem5MfVAJY3g1XrIPSmeJ1MiXyQbim9I09NxMpN9QeZTYcq+cNHda6zYo5vG+pvZ8yY3o4YPWImiGEfkPbTGD9pdXv9njBP+dTzzJIPmfgNVOuekv5hrPadhRS3tyvmfnSXcEv8mgYrpD2TS4TcuyG2HGKsDijwRfJOO4uoXhCDPkN3Wf7DAYhKWofzoSu/UvDkwHy4uTWsp0407wUZlrpvLPlXO1sfu7PmYdYI+DX9h6+bGvsV1mqwDS5Qrq5wulXlJ3BihaZWYc7k9SiJA/zz4zRO6UeNFlUzllvl06nTWupddnrtwZyFHes3sT3Uon8SeztCXvQybBWWzifaaC6r9HjZ0+uXe1s//EsbRKmzBdkhnp5Ov6vIn+wXdnVydO5+CsVoIK1JWs3pGpCiOZLSxLLjOqgfWm+X7WVVcPZRihfoijdwKD/w+HDUWgcI/w3eaL3PYxV+H2mZLF0YAXKY+xORs7BQbtjjNc23a+0FP1ySMqfzlBnA4xHIkp/iK3/17b94xALz8AOkYLhl6Gtju+LIQho4pakp/OgPsya2ginv+hAR6SFohk/Q8hdtfJl/xhPLSlqaCePzVdn0bSOMQxXpFlzawGYGSW99n2BS/U8QeuAzoVw11GC1Gn/v+bTKoVG4SGRpngCHL6KEBQhQa4/Yyyb7NCFKg6k+QO4qdfQ1wzQvnQKH3pI4Ye1403eBrNzdgSUDFg1ehLgO0zf3FgfAkgGTThYMK6Dt1VzMZ339VEolDVlE8aWvWc0uONk7yh9jt/aKrmfOGfu6nE16DTtlGjC3bviszo2oUi7eu3oCoZO+iWUqN0eKJhsGbfKIuFMDZHDxo5jtOYGzqATSYT1LihfhquBetMlA0cHPbjY4z8x6tlHWsOOGAgtnGTLiGy9o6+2VVlOclhEhPMOBLScFIt77FDpE2dXgdi2NcEhv4x6aqYfruJa9H3Gs/0jZ+AMyp8IcuUs1HtJdFEE0juzrvLGLTcTErmidGOsrvSBXFqYVItAMG6ohgUEIAXSv2t2UhWTGUU6x0EEBeKh4vpqFGt3A34ZnTWK2L7bZenfqzpIIBZTCCAWGgAwIBF6KCAVgEggFUt9PUdFg50pYmU2KPNaKTDFZXc1Q0j3FSfcfftV/0BPoqYE3YsGVBqvdKLhDJDJaGfceXSddebADrVLUNt4DwN+6J2w6E618J7saTjrHjnqYaQIuVN4x3qssmIzmuDGftHPjvwHSr7bcB+iii/QhscbkXs54ViN0K6GvZhSXEd+H9cTXmcFpxPgn98ppZjSesmPEr/U9XHwJRxNH15qNc787+7ZcX0h7WtP8HIt/U0e67dE8DbahZl2isxnJr3moAL5aX9I8RUwAbynZeiIz0d2kOGr6dX5vfFQPFyKXXKagFy8l3GCGSwY4KpvoIxsar0Gzj07LD09wv74CMwtxTscKxkJ2un/sd8IW5i0pSm4YLRHB0tV9V3SFq8CO9e3J9T4k3S1up7x/A6eMeSgAPkGyQbS+JtcvwJjbsixu9wE4CE3MLH8iSGqTp0Kd9E6FRA7e0Xw==
Host: tps03.domain.local User-Agent: Microsoft WinRM Client
I would have liked to uninstall and reinstall Windows Management Framework and/or Windows Remote Management, but being Server 2012 R2, that is not an option. 
Interestingly enough, users currently have no problems accessing their mailboxes, via Outlook or OWA - it's just we cannot manage the server.  Any help on what to try next is greatly appreciated...
-Michael.

Answer 1

Two things I can think of to check.  In IIS, under Default Web Site, PowerShell virtual directory, ensure that in SSL, Require SSL is not selected.  In the HTTP Redirect virtual directory, ensure that there is no HTTP redirection selected. 
These can be set wrong when you incorrectly configure HTTP Redirect.
Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
Note where I said above:
Ensured that SSL is not required on the root (Default Web Site), that it is required on the various virtual directories, except PowerShell, which it is NOT required on
Ensured that there is no redirection going on with any virtual directory or the root site