Tuesday, 13 October 2015

Exchange 2010, 2013, 2016 Cross Forest Remote PowerShell

If you are attempting a remote PowerShell connection to an Exchange server cross forest (no forest trust) using the method here, you will get the below error:Connecting to remote server [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 logon servers available to service the logon request.

The problem here is that the PowerShell application in IIS on the Exchange server is only configured to accept Windows Authentication by default which means that you need to connect using Kerberos. To achieve this, you need to meet all the requirements in the error above and that means needing to authenticate to a domain controller to check SPNs in that domain which just won't be possible as you're running under a different account on a different domain.To work around this, one option is to enable other authentication methods on Exchange but sometimes this is not an option. For example, for a hosting provider where there are 100 Exchange servers all in different AD forests and you cannot reduce the security on them for various reasons.The other option is to use one method of authentication to connect to the Exchange server using PS Remoting then connect to Exchange PowerShell using Kerberos.

First of all, PowerShell doesn't allow connections to all hosts so configure it to do so by running this command:

winrm
s winrm/config/client '@{TrustedHosts="*"}'

Now can connect to our Exchange server, litex01.litwareinc.com using PS Remoting:

Enter-PSSession litex01.litwareinc.com -Credential $cred

Once connected to the Exchange server, we now need to connect to Exchange PowerShell using the below commands:

This error is because we have specified credentials to remotely connect to Exchange and now we are using the same credentials to make another remote connection. This is two hops. Double hop. Remember this from those Server 2003 MCSE days? Kerberos? Ok, perhaps not. You cannot do a double hop with the same credentials.

So, this isn't so hard to get around. You need to pass the credentials again so it is just another single hop:

Once done, we can use the Exchange cmdlets and work away as if we just opened the Exchange Management Shell from an Exchange server:

So, this is good but a bit of a hassle and a lot of commands to remember so it's pretty much easier to just log into Exchange however you can write the whole process into a single PowerShell function and run cross-forest Exchange commands in a single line using the Invoke-ExchangeCommand as below:

1 comment:

A great article! I would highly recommend EdbMails Edb to PST converter software for its easy to use User interface and fast export performance.EdbMails is a one stop solution for all exchange server recovery needs. It is quick and uses deep scan to recover most data out of even corrupted databases.It supports public, private folder recovery. And also supports migration to Live exchange and Office 365. Archive mailbox migration is also supported by edbmails