In Exchange 2013 CU11, we introduced a change to the way Remote PowerShell (RPS) functioned.
Prior to CU11, Exchange 2013 routed Remote PowerShell requests by finding a random mailbox that is either higher than the ExchClientVer that is specified in the URL, or if the ExchClientVer is not specified, by using the current CAS version in which the client connected. We refer to this behavior as server version-based routing.
With CU11, we changed Remote PowerShell to route requests to an anchor mailbox. Typically, this anchor mailbox would be the mailbox of the user attempting the connection. In the event the user attempting the connection did not have a mailbox, the request would be routed to the organization arbitration mailbox.
There were several perceived benefits with this approach:
New-PSSession : [ems.contoso.com] Processing data from remote server ems.contoso.com failed with the
following error message: [ClientAccessServer=E2K13-1,BackEndServer=e2k13-1.contoso.com,RequestId=76229690-2343-4
f-9a51-48184587c5cf,TimeStamp=8/14/2015 2:20:36 PM] [FailureCategory=WSMan-InvalidShellID] The request for the Window
Remote Shell with ShellId DD266254-5C1F-43C0-A4DA-1797C253C0C0 failed because the shell was not found on the server.
Possible causes are: the specified ShellId is incorrect or the shell no longer exists on the server. Provide the
correct ShellId or create a new shell and retry the operation. For more information, see the
about_Remote_Troubleshooting Help topic.
At C:\Scripts\test.ps1:8 char:12
+ $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri ht ...
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemoti
+ FullyQualifiedErrorId : CannotConnectTargetSessionDoesNotExist,PSSessionOpenFailed
Import-PSSession : Cannot validate argument on parameter 'Session'. The argument is null. Provide a valid value for
the argument, and then try running the command again.
At C:\Scripts\test.ps1:10 char:18
+ Import-PSSession $Session
+ CategoryInfo : InvalidData: (:) [Import-PSSession], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.ImportPSSessionCommand
This error occurs when a load balanced RPS request shifts from one version of Exchange to another, whether that be Exchange 2013 coexisting with Exchange 2016, or different versions of cumulative updates for the same version of Exchange.
Unfortunately, the changes in CU11 introduced several issues with Remote PowerShell in the on-premises world that we did not anticipate. After reviewing each issue and performing an in-depth code review, we made the decision to revert the CU11 change and return to utilizing server version-based routing for Remote PowerShell requests beginning in Exchange 2013 CU12. Exchange 2016 (including CU1) will also use server version-based routing.
If you were planning to take advantage of the changes in Remote PowerShell routing in CU11, you may now be wondering what options are available to you beginning in CU12. Fortunately, you have several options:
$cred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://servername.contoso.com/powershell -Authentication Kerberos -Credential $cred
For more information, please see the TechNet article, Connect to Exchange servers using Remote PowerShell.
$cred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri “https://lb.contoso.com/powershell?serializationlevel=Full;ExchClientVer=126.96.36.199" -Authentication Basic -Credential $cred
We will continue to evaluate ways we can improve the routing of Remote PowerShell requests for on-premises deployments.
Ross Smith IV
Principal Program Manager
Office 365 Customer Experience
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.