Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 773 other subscribers


  • LinkedIn
  • RSS Feed for Posts
  • Twitter
  • StumbleUpon

How to connect to a domain-joined Exchange server from a stand-alone PC [Solved]

Special thanks to my colleague Eric Snijders for his contribution!


Be Aware:

This is not the best practice!

We have done this in order to decommission the current mail server!


This week I encountered some troubles connecting from my local machine to a domain-joined server with PowerShell.

By default, PowerShell seems to use Kerberos authentication which can’t be used in this case, since my local machine wasn’t part of the same domain as the remote host. The error you’ll receive is as followed:


New-PSSession : [] Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no log-on servers available to service the

log-on request.

Possible causes are:

-The user name or password specified are invalid.

-Kerberos is used when no authentication method and no user name are specified.

-Kerberos accepts domain user names, but not local user names.

-The Service Principal Name (SPN) for the remote computer name and port does not exist.

-The client and remote computers are in different domains and there is no trust between the two domains.

After checking for the above issues, try the following:

-Check the Event Viewer for events related to authentication.

-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.

Note that computers in the TrustedHosts list might not be authenticated.

-For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting

Help topic.


After changing the New-PSSession cmdlet to try Basic or Negotiate Authentication (New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri “http://$Exch/PowerShell/?SerializationLevel=Full” -Credential $Credentials –Authentication basic) I encountered the following error:


test-wsman : <f:WSManFault xmlns:f=”” Code=”2150858974″ Machine=”XXXX.XXXX.XXXX”><f:Message>The WinRM client cannot process the request. Unencrypted traffic is currently disabled in the client configuration. Change the client configuration and try the request again.


I enabled Unencrypted Traffic on the remote host using the following command


PS C:\Windows\system32> winrm set winrm/config/service ‘@{AllowUnencrypted=”true”}’


To be sure, I also enabled Basic Authentication with the following command since it was set to False:


PS C:\Windows\system32> winrm set winrm/config/service/auth ‘@{Basic=”true”}’


After changing those entries, I tried connecting again to the remote host using Basic authentication, and the following error appeared:


New-PSSession : [] Connecting to remote server failed with the following error message : The WinRM client cannot process the request. The authentication mechanism requested by the client is not supported by the server or unencrypted traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the service configuration or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the 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 computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubleshooting Help topic.


The last step I took to make it working was checking and changing IIS settings on the Remote Host. You should check the PowerShell Virtual Directory within IIS to see what Authentication options are enabled, and to make sure the server is not requiring an SSL connection.

2015-06-25 22_07_26-RE_ PowerShell V2 WinRM buiten domein - Bericht (HTML) 2015-06-25 22_07_10-RE_ PowerShell V2 WinRM buiten domein - Bericht (HTML)

It might not be the fastest or most safe way to go, but in this case the remote host was an Exchange server being migrated to Office 365. Installing the Management Framework 3.0 was the first thing I tried, but the server had to reboot which couldn’t be done since the Exchange server was still in production.