フィードバック

about_Remote_Requirements

  • [アーティクル]

簡単な説明

PowerShell でリモートコマンドを実行するためのシステム要件と構成要件について説明します。

長い説明

このトピックでは、PowerShell でリモート接続を確立し、リモートコマンドを実行するためのシステム要件、ユーザー要件、およびリソース要件について説明します。 また、リモート操作を構成する手順についても説明します。

注意

多くのコマンドレット (、 Get-Process Get-WMIObject 、、 Get-EventLog 、および Get-WinEvent コマンドレットを含む Get-Service ) は、Microsoft .NET Framework メソッドを使用してオブジェクトを取得することにより、リモートコンピューターからオブジェクトを取得します。 PowerShell リモート処理インフラストラクチャは使用しません。 このドキュメントの要件は、これらのコマンドレットには適用されません。

Computername パラメーターを持ち、PowerShell リモート処理を使用しないコマンドレットを見つけるには、コマンドレットの computername パラメーターの説明を参照してください。

システム要件

Windows PowerShell 3.0 でリモートセッションを実行するには、ローカルコンピューターとリモートコンピューターに次のものが必要です。

  • Windows PowerShell 3.0 以降
  • Microsoft .NET Framework 4 以降
  • Windows リモート管理3.0

Windows PowerShell 2.0 でリモートセッションを実行するには、ローカルコンピューターとリモートコンピューターに次のものが必要です。

  • Windows PowerShell 2.0 以降
  • Microsoft .NET Framework 2.0 以降
  • Windows リモート管理2.0

Windows PowerShell 2.0 および Windows PowerShell 3.0 を実行しているコンピューター間でリモートセッションを作成することができます。 ただし、Windows PowerShell 3.0 でのみ実行される機能 (セッションを切断して再接続する機能など) は、両方のコンピューターで Windows PowerShell 3.0 を実行している場合にのみ使用できます。

インストールされている PowerShell のバージョン番号を確認するには、自動変数を使用 $PSVersionTable します。

Windows リモート管理 (WinRM) 3.0 および Microsoft .NET Framework 4 は、Windows オペレーティングシステムの Windows 8、Windows Server 2012、およびそれ以降のリリースに含まれています。 WinRM 3.0 は、古いオペレーティングシステムの Windows Management Framework 3.0 に含まれています。 必要なバージョンの WinRM または Microsoft .NET Framework がコンピューターに搭載されていない場合、インストールは失敗します。

ユーザーのアクセス許可

リモートセッションを作成してリモートコマンドを実行するには、既定で、現在のユーザーがリモートコンピューターの Administrators グループのメンバーであるか、管理者の資格情報を提供している必要があります。 それ以外の場合、コマンドは失敗します。

リモートコンピューター (またはローカルコンピューター上のリモートセッション) でセッションを作成し、コマンドを実行するために必要なアクセス許可は、セッションの接続先となるリモートコンピューター上のセッション構成 ( エンドポイント とも呼ばれます) によって確立されます。 具体的には、セッション構成のセキュリティ記述子は、セッション構成にアクセスできるユーザーと、それを使用して接続するユーザーを決定します。

既定のセッション構成のセキュリティ 記述子、 Microsoft.powershell32、および Microsoft. powershell は、 Administrators グループのメンバーのみにアクセスを許可します。

現在のユーザーがセッション構成を使用するアクセス許可を持っていない場合は、コマンドを実行して (一時セッションを使用)、またはリモートコンピューターで永続的なセッションを作成するコマンドは失敗します。 ユーザーは、セッションを作成するコマンドレットの ConfigurationName パラメーターを使用して、別のセッション構成 (使用可能な場合) を選択できます。

コンピューターの Administrators グループのメンバーは、既定のセッション構成のセキュリティ記述子を変更し、異なるセキュリティ記述子を使用して新しいセッション構成を作成することによって、コンピューターにリモート接続するアクセス許可を持つユーザーを判断できます。

セッション構成の詳細については、「 about_Session_Configurations」を参照してください。

ネットワークの場所の Windows

Windows PowerShell 3.0 以降では、 Enable-PSRemoting コマンドレットを使用して、プライベート、ドメイン、およびパブリックネットワーク上の Windows のクライアントとサーバーのバージョンでリモート処理を有効にすることができます。

プライベートネットワークとドメインネットワークを使用した Windows のサーバーバージョンでは、Enable-PSRemoting コマンドレットにより、無制限のリモートアクセスを許可するファイアウォール規則が作成されます。 また、同じローカルサブネット内のコンピューターからのリモートアクセスのみを許可する、パブリックネットワーク用のファイアウォール規則も作成します。 このローカルサブネットファイアウォール規則は、パブリックネットワーク上の Windows のサーバーバージョンでは既定で有効になっていますが Enable-PSRemoting 、変更または削除された場合には、規則が再適用されます。

プライベートネットワークとドメインネットワークを使用した Windows のクライアントバージョンでは、コマンドレットによって、無制限のリモートアクセスを許可するファイアウォール規則が既定で作成され Enable-PSRemoting ます。

パブリックネットワークを使用して Windows のクライアントバージョンでリモート処理を有効にするには、コマンドレットの Enable-PSRemoting SkipNetworkProfileCheck パラメーターを使用します。 同じローカルサブネット内のコンピューターからのリモートアクセスのみを許可するファイアウォール規則を作成します。

パブリックネットワークのローカルサブネットの制限を削除し、Windows のクライアントバージョンとサーバーバージョンのすべての場所からのリモートアクセスを許可するには、 netsecurity モジュールのコマンドレットを使用 Set-NetFirewallRule します。 次のコマンドを実行します。

Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any

注意

ファイアウォール規則の名前は、Windows のバージョンによって異なる場合があります。 を使用 Get-NetFirewallRule して、ルールの一覧を表示します。 ファイアウォール規則を有効にする前に、規則のセキュリティ設定を表示して、構成が環境に適していることを確認します。

Windows PowerShell 2.0 では、Windows のサーバーバージョンで、 Enable-PSRemoting すべてのネットワークのリモートアクセスを許可するファイアウォール規則が作成されます。

Windows PowerShell 2.0 では、Windows のクライアントバージョンで、プライベートネットワークとドメインネットワークにのみファイアウォール規則を Enable-PSRemoting 作成します。 ネットワークの場所がパブリックの場合、 Enable-PSRemoting は失敗します。

管理者として実行

次のリモート処理操作には、管理者特権が必要です。

  • ローカルコンピューターへのリモート接続を確立する。 これは、一般的に "ループバック" シナリオと呼ばれます。

  • ローカルコンピューター上のセッション構成を管理する。

  • ローカルコンピューター上の WS-Management 設定を表示および変更します。 WSMAN: ドライブの LocalHost ノードの設定を次に示します。

これらのタスクを実行するには、ローカルコンピューターの Administrators グループのメンバーであっても、[管理者として実行] オプションを使用して PowerShell を起動する必要があります。

Windows 7 と Windows Server 2008 R2 で、[管理者として実行] オプションを使用して PowerShell を起動するには、次のようにします。

  1. [スタート]、[すべてのプログラム]、[アクセサリ] の順にクリックし、PowerShell フォルダーをクリックします。
  2. [PowerShell] を右クリックし、[ 管理者として実行] をクリックします。

[管理者として実行] オプションを使用して Windows PowerShell を開始するには:

  1. [スタート] をクリックし、[すべてのプログラム] をクリックして、PowerShell フォルダーをクリックします。
  2. [PowerShell] を右クリックし、[ 管理者として実行] をクリックします。

[管理者として実行] オプションは、PowerShell の他の Windows エクスプローラーのエントリ (ショートカットを含む) でも使用できます。 項目を右クリックし、[ 管理者として実行] をクリックするだけです。

Cmd.exe などの別のプログラムから PowerShell を起動する場合は、[ 管理者として実行 ] オプションを使用してプログラムを起動します。

リモート処理用にコンピューターを構成する方法

サポートされているすべてのバージョンの Windows を実行しているコンピューターは、PowerShell でリモート接続を確立し、構成なしでリモートコマンドを実行できます。 ただし、接続を受信し、ローカルおよびリモートのユーザー管理 PowerShell セッション ("PSSessions") をユーザーが作成して、ローカルコンピューターでコマンドを実行できるようにするには、コンピューターで PowerShell リモート処理を有効にする必要があります。

既定では、Windows サーバーの Windows Server 2012 および新しいリリースでは、PowerShell リモート処理が有効になっています。 設定が変更された場合は、コマンドレットを実行 Enable-PSRemoting して既定の設定を復元できます。

その他のサポートされているすべてのバージョンの Windows では、コマンドレットを実行 Enable-PSRemoting して PowerShell リモート処理を有効にする必要があります。

PowerShell のリモート処理機能は、WinRM サービスによってサポートされています。これは、Web Services for Management (WS-MANAGEMENT) プロトコルの Microsoft による実装です。 PowerShell リモート処理を有効にした場合、WS-Management の既定の構成を変更し、ユーザーが WS-MANAGEMENT に接続できるようにするシステム構成を追加します。

リモートコマンドを受信するように PowerShell を構成するには

  1. [ 管理者として実行 ] オプションを使用して PowerShell を起動します。
  2. コマンド プロンプトに Enable-PSRemoting を入力します。

リモート処理が正しく構成されていることを確認するには、次のコマンドのようなテストコマンドを実行します。このコマンドは、ローカルコンピューターでリモートセッションを作成します。

New-PSSession

リモート処理が正しく構成されている場合、コマンドはローカルコンピューター上にセッションを作成し、そのセッションを表すオブジェクトを返します。 出力は次のサンプル出力のようになります。

Id Name        ComputerName    State    ConfigurationName
-- ----        ------------    -----    -----
1  Session1    localhost       Opened   Microsoft.PowerShell

コマンドが失敗した場合は、「 about_Remote_Troubleshooting」を参照してください。

ポリシーについて理解する

リモートで作業する場合は、PowerShell の2つのインスタンスを使用します。1つはローカルコンピューター上に、もう1つはリモートコンピューター上にあります。 その結果、作業内容は、ローカルコンピューターとリモートコンピューターの Windows ポリシーと PowerShell ポリシーの影響を受けます。

一般に、接続を確立する前に、ローカルコンピューター上のポリシーが有効になります。 接続を使用すると、リモートコンピューター上のポリシーが有効になります。

Linux と macOS の基本認証の制限事項

Linux または macOS システムから Windows に接続する場合、HTTP 経由の基本認証はサポートされていません。 基本認証を HTTPS 経由で使用するには、対象サーバーに証明書をインストールします。 証明書には、ホスト名と一致する CN 名、期限切れまたは失効していない名前が必要です。 自己署名証明書は、テスト目的で使用できます。

詳細については、「 方法: HTTPS 用に WINRM を構成する 」を参照してください。

管理者特権のコマンドプロンプトから次のコマンドを実行すると、インストールされている証明書を使用して Windows の HTTPS リスナーが構成されます。

$hostinfo = '@{Hostname="<DNS_NAME>"; CertificateThumbprint="<THUMBPRINT>"}'
winrm create winrm/config/Listener?Address=*+Transport=HTTPS $hostinfo

Linux または macOS 側で、[認証および-UseSSl] の [基本] を選択します。

注意

基本認証をドメインアカウントと共に使用することはできません。ローカルアカウントが必要であり、アカウントが Administrators グループに含まれている必要があります。

# The specified local user must have administrator rights on the target machine.
# Specify the unqualified username.
$cred = Get-Credential username
$session = New-PSSession -Computer <hostname> -Credential $cred `
  -Authentication Basic -UseSSL

HTTPS 経由の 基本認証 の代わりに Negotiate があります。 この結果、クライアントとサーバー間の NTLM 認証が HTTP 経由で暗号化されます。

次の例では、と共に New-PSSession Negotiate を使用しています。

# The specified user must have administrator rights on the target machine.
$cred = Get-Credential username@hostname
$session = New-PSSession -Computer <hostname> -Credential $cred `
  -Authentication Negotiate

注意

Windows サーバーでは、組み込みの管理者以外の管理者が NTLM を使用して接続できるようにするために、追加のレジストリ設定が必要です。 「リモート接続の認証で認証を ネゴシエート する」の LocalAccountTokenFilterPolicy レジストリ設定を参照してください。

関連項目