Partager via

Exchange 2013 CU12 および Exchange 2016 でのリモート PowerShell のプロキシ転送時の処理

  • Article

(この記事は 2016 年 3 月 1 日に Exchange Team Blog に投稿された記事 Remote PowerShell Proxying Behavior in Exchange 2013 CU12 and Exchange 2016 の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

 

Exchange 2013 CU11 では、リモート PowerShell (RPS) の動作が変更されました。

CU11 よりも前のバージョンの Exchange 2013 では、リモート PowerShell の要求をルーティングするとき、URL で指定された ExchClientVer よりも新しいバージョンのメールボックスを無作為に選択するか、または ExchClientVer が指定されていない場合は、クライアントが接続されている現在の CAS (クライアント アクセス サーバー) のバージョンを使用して実行していました。この動作は、「サーバー バージョンによるルーティング」と呼ばれます。

CU11 ではリモート PowerShell の要求のルーティング方法が変更され、アンカー設定されたメールボックスに送られるようになりました。通常、このアンカー設定されたメールボックスは、接続を試みているユーザーのメールボックスになります。接続を試みているユーザーのメールボックスが存在しない場合、要求は組織の調停メールボックスにルーティングされます。

この手法には下記のようなメリットがあります。

  1. この手法では複数のバージョンが共存する場合の問題が解決され、操作を実行するメールボックスのバージョンに基づいて RPS が確実に実行されます。CU11 よりも前のバージョンのサーバー バージョンによるルーティングでは、クライアントに下記のエラーが返される場合がありました。

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

gTransportException

+ 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

このエラーは、Exchange 2013 と Exchange 2016 が共存する場合、または異なるバージョンの累積更新プログラムが適用された同一バージョンの Exchange が共存する場合などに、あるバージョンの Exchange から他のバージョンの Exchange に負荷分散された RPS 要求が送られると発生します。

  1. この手法では、Office 365 でプロキシ転送を処理するリモート PowerShell に同一のコード パスを使用できます。

しかし、CU11 に実装された変更により、オンプレミス環境のリモート PowerShell では予想外の問題が複数発生しました。これらの問題について詳細にコードを見直した結果、CU11 に実装された変更を取り消し、Exchange 2013 CU12 のリリース時に従来のサーバー バージョンによるルーティングを使用するように戻すことになりました。Exchange 2016 (CU1 を含む) でも、サーバー バージョンによるルーティングに戻します。

CU11 に実装されているリモート PowerShell のルーティング方法を CU12 でも使用するには、複数の方法があります。

  1. リモート PowerShell から Exchange に接続するときに、負荷分散対象の名前空間ではなくサーバーの FQDN を指定します。

$cred = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://servername.contoso.com/powershell -Authentication Kerberos -Credential $cred

Import-PSSession $Session

この詳細については、TechNet 記事「リモート PowerShell を使用した Exchange サーバーへの接続」を参照してください。

  1. リモート PowerShell から Exchange に接続するときに負荷分散対象の名前空間を指定する場合は、接続するサーバーのバージョンを ExchClientVer に指定します。

$cred = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri “https://lb.contoso.com/powershell?serializationlevel=Full;ExchClientVer=15.0.225.0" -Authentication Basic -Credential $credImport-PSSession $Session
  1. リモート PowerShell の要求にセッション アフィニティを使用するようにロード バランサーを構成します。
  2. 負荷分散プールから古いバージョンの Exchange を削除します。

マイクロソフトでは、引き続きオンプレミス環境におけるリモート PowerShell の要求のルーティング方法の改善に取り組んでまいります。

Ross Smith IV

プリンシパル プログラム マネージャー

Office 365 カスタマー エクスペリエンス担当

 

※ 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。