Task #1 today was to uninstall a vestigial Exchange 2010 installation that was using up space on our TFS box. Uninstall wouldn’t proceed until I’d cleaned up remaining mailboxes, etc., so I launched Exchange Management Console, intending to scorch some earth. When I clicked “Microsoft Exchange On-Premises”, I got this error:

[server FQDN] Connecting to remote server failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer (server FQDN:80) returned an 'access denied' error. Change the configuration to allow Kerberos authentication mechanism to be used or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server:     Negotiate For more information, see the about_Remote_Troubleshooting Help topic.

Turns out that as of 2010, the Exchange Management Console works by remoting PowerShell commands over to a http://servername:80/powershell virtual directory on the target server. Since this Exchange server had been set up (and after the last time anyone had used it), some port-juggling had been done on IIS on that box; SharePoint was now listening on port 80, and the default website (in which the powershell virtual directory was configured) had been moved off to port 8888.

The fix was simple: temporarily stop the SharePoint website (currently listening on port 80), create a new binding for the Default Web Site so that it would listen on port 80, and then re-launch Exchange Management Console.

Now, back to mailbox-razing.