次の方法で共有

リモート トラブルシューティングについて

  • [アーティクル]

概要

PowerShell でリモート操作のトラブルシューティングを行う方法について説明します。

詳細説明

このセクションでは、WS-Management テクノロジに基づく PowerShell のリモート処理機能を使用するときに発生する可能性のある問題の一部について説明し、これらの問題の解決策を提案します。

PowerShell リモート処理を使用する前に、構成と基本的な使用に関するガイダンスについては、「 about_Remote と about_Remote_Requirements 」を参照してください。 また、各リモート処理コマンドレット (特にパラメーターの説明) のヘルプ トピックには、問題の回避に役立つ有用な情報があります。

注意

セッション構成、信頼されたホスト、ポート、またはリスナーの変更など、WSMan ドライブのローカル コンピューターの設定を表示または変更するには、[管理者として実行] オプションを使用して PowerShell を起動します。

アクセス許可と認証に関する問題のトラブルシューティング

このセクションでは、ユーザーとコンピューターのアクセス許可とリモート処理の要件に関連するリモート処理の問題について説明します。

管理者として実行する方法

エラー: アクセスが拒否されました。 管理者特権のプロセスからこのコマンドレットを実行する必要があります。

ローカル コンピューターでリモート セッションを開始するか、WSMan: ドライブ内のローカル コンピューターの設定を表示または変更するには(セッション構成、信頼されたホスト、ポート、またはリスナーの変更を含む)、"管理者として実行" オプションを使用してWindows PowerShellを開始します。

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

  • Windows PowerShell (または ISE Windows PowerShell) アイコンを右クリックし、[管理者として実行] をクリックします。

    [Windows 7 および Windows Server 2008 R2 で管理者として実行] オプションを使用してWindows PowerShellを開始します。

  • Windows タスク バーで、Windows PowerShell アイコンを右クリックし、[管理者として実行] をクリックします。

    Windows Server 2008 R2 では、Windows PowerShell アイコンは既定でタスク バーにピン留めされています。

リモート処理を有効にする方法

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to
listen for requests on the correct port and HTTP URL.

コンピューターがリモート コマンドを送信できるようにするための構成は必要ありません。 ただし、リモート コマンドを受信するには、コンピューターで PowerShell リモート処理を有効にする必要があります。 有効化には、WinRM サービスの開始、WinRM サービスのスタートアップの種類の自動設定、HTTP および HTTPS 接続のリスナーの作成、既定のセッション構成の作成が含まれます。

Windows PowerShellリモート処理は、Windows Server の Windows Server 2012 以降のリリースで既定で有効になっています。 他のすべてのシステムで、 コマンドレットを Enable-PSRemoting 実行してリモート処理を有効にします。 リモート処理が無効になっている場合は、 コマンドレットをEnable-PSRemoting実行して、Windows Server のWindows Server 2012以降のリリースでリモート処理を再度有効にすることもできます。

リモート コマンドを受信するようにコンピューターを構成するには、 コマンドレットを Enable-PSRemoting 使用します。 次のコマンドは、必要なすべてのリモート設定を有効にし、セッション構成を有効にし、WinRM サービスを再起動して変更を有効にします。

Enable-PSRemoting

すべてのユーザー プロンプトを非表示にするには、次のように入力します。

Enable-PSRemoting -Force

詳細については、「 Enable-PSRemoting」を参照してください。

企業でリモート処理を有効にする方法

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to
listen for requests on the correct port and HTTP URL.

1 台のコンピューターでリモート PowerShell コマンドを受信し、接続を受け入れるようにするには、 コマンドレットを Enable-PSRemoting 使用します。

企業内の複数のコンピューターに対してリモート処理を有効にするには、次のスケーリングされたオプションを使用できます。

  • リモート処理用にリスナーを構成するには、"リスナーの自動構成を許可する" グループ ポリシーを有効にします。 手順については、「グループ ポリシーを使用してリスナーを有効にする方法」を参照してください (以下)。

  • 複数のコンピューターで Windows リモート管理 (WinRM) のスタートアップの種類を [自動] に設定するには、 コマンドレットを Set-Service 使用します。 手順については、「How to Set the Startup Type of the WinrM Service」(WinrM サービスのスタートアップの種類を設定する方法) を参照してください (以下)。

  • ファイアウォール例外を有効にするには、"Windows ファイアウォール: ローカル ポート例外を許可する" グループ ポリシーを使用します。 手順については、「グループ ポリシーを使用してファイアウォール例外をCreateする方法」を参照してください (以下)。

グループ ポリシーを使用してリスナーを有効にする方法

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to listen
for requests on the correct port and HTTP URL.

ドメイン内のすべてのコンピューターのリスナーを構成するには、次のグループ ポリシー パスで "リスナーの自動構成を許可する" ポリシーを有効にします。

Computer Configuration\Administrative Templates\Windows Components \Windows Remote Management (WinRM)\WinRM サービス

ポリシーを有効にし、IPv4 フィルターと IPv6 フィルターを指定します。 ワイルドカード (*) を使用できます。

パブリック ネットワークでリモート処理を有効にする方法

ERROR:  Unable to check the status of the firewall

このコマンドレットは Enable-PSRemoting 、ローカル ネットワークがパブリックであり、SkipNetworkProfileCheck パラメーターが コマンドで使用されていない場合に、このエラーを返します。

Windows のサーバー バージョンでは、 Enable-PSRemoting すべてのネットワークの場所の種類で 成功します。 プライベートおよびドメイン ("Home" および "Work") ネットワークへのリモート アクセスを許可するファイアウォール規則が作成されます。 パブリック ネットワークの場合、同じローカル サブネットからのリモート アクセスを許可するファイアウォール規則が作成されます。

Windows のクライアント バージョンでは、 Enable-PSRemoting はプライベート ネットワークとドメイン ネットワークで成功します。 既定では、パブリック ネットワークでは失敗しますが、 SkipNetworkProfileCheck パラメーターを使用すると、成功し、 Enable-PSRemoting 同じローカル サブネットからのトラフィックを許可するファイアウォール規則が作成されます。

パブリック ネットワークのローカル サブネット制限を削除し、任意の場所からリモート アクセスを許可するには、次のコマンドを実行します。

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

コマンドレットは Set-NetFirewallRule NetSecurity モジュールによってエクスポートされます。

注意

Windows PowerShell 2.0 では、サーバー バージョンの Windows を実行しているコンピューターで、プライベート、Enable-PSRemotingドメイン、パブリック ネットワークでリモート アクセスを許可するファイアウォール規則を作成します。 Windows のクライアント バージョンを実行しているコンピューターでは、 Enable-PSRemoting プライベート ネットワークとドメイン ネットワークでのみリモート アクセスを許可するファイアウォール規則を作成します。

グループ ポリシーを使用してファイアウォール例外を有効にする方法

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to
listen for requests on the correct port and HTTP URL.

ドメイン内のすべてのコンピューターで ファイアウォール例外を有効にするには、次のグループ ポリシー パスで "Windows ファイアウォール: ローカル ポート例外を許可する" ポリシーを有効にします。

Computer Configuration\Administrative Templates\Network \Network Connections\Windows Firewall\Domain Profile

このポリシーにより、コンピューター上の Administrators グループのメンバーは、コントロール パネルの Windows ファイアウォールを使用して、Windows リモート管理サービスのファイアウォール例外を作成できます。

WINRM サービスのスタートアップの種類を設定する方法

ERROR:  ACCESS IS DENIED

PowerShell リモート処理は、Windows リモート管理 (WinRM) サービスによって異なります。 リモート コマンドをサポートするには、サービスが実行されている必要があります。

Windows のサーバー バージョンでは、Windows リモート管理 (WinRM) サービスのスタートアップの種類は [自動] です。

ただし、Windows のクライアント バージョンでは、WinRM サービスは既定で無効になっています。

リモート コンピューターでサービスのスタートアップの種類を設定するには、 コマンドレットを Set-Service 使用します。

複数のコンピューターでコマンドを実行するには、コンピューター名のテキスト ファイルまたは CSV ファイルを作成します。

たとえば、次のコマンドは、Servers.txt ファイルからコンピューター名の一覧を取得し、すべてのコンピューターの WinRM サービスのスタートアップの種類を [自動] に設定します。

$servers = Get-Content servers.txt
Set-Service WinRM -ComputerName $servers -startuptype Automatic

結果を表示するには、 コマンドレットと Get-WMIObjectWin32_Service オブジェクトを使用します。 詳細については、「 Set-Service」を参照してください。

既定のセッション構成を再作成する方法

ERROR:  ACCESS IS DENIED

ローカル コンピューターに接続してコマンドをリモートで実行するには、ローカル コンピューターにリモート コマンドのセッション構成を含める必要があります。

を使用 Enable-PSRemotingすると、ローカル コンピューターに既定のセッション構成が作成されます。 リモート ユーザーは、リモート コマンドに ConfigurationName パラメーターが含まれていない場合は常に、これらのセッション構成を使用します。

コンピューター上の既定の構成が登録解除または削除されている場合は、 コマンドレットを Enable-PSRemoting 使用して再作成します。 このコマンドレットは繰り返し使用できます。 機能が既に構成されている場合、エラーは生成されません。

既定のセッション構成を変更し、元の既定のセッション構成を復元する場合は、 コマンドレットを Unregister-PSSessionConfiguration 使用して変更されたセッション構成を削除してから、 コマンドレットを Enable-PSRemoting 使用して復元します。 Enable-PSRemoting では、既存のセッション構成は変更されません。

注意

既定のセッション構成を復元しても Enable-PSRemoting 、構成の明示的なセキュリティ記述子は作成されません。 代わりに、構成は RootSDDL のセキュリティ記述子を継承します。これは既定でセキュリティで保護されています。

RootSDDL セキュリティ記述子を表示するには、次のように入力します。

Get-Item wsman:\localhost\Service\RootSDDL

RootSDDL を変更するには、WSMan: ドライブの コマンドレットを使用 Set-Item します。 セッション構成のセキュリティ記述子を変更するには、SecurityDescriptorSDDL パラメーターまたは ShowSecurityDescriptorUI パラメーターを指定して コマンドレットを使用Set-PSSessionConfigurationします。

WSMan: ドライブの詳細については、WSMan プロバイダーのヘルプ トピック ("Get-Help wsman") を参照してください。

管理者の資格情報を指定する方法

ERROR:  ACCESS IS DENIED

PSSession を作成するか、リモート コンピューターでコマンドを実行するには、既定では、現在のユーザーがリモート コンピューターの Administrators グループのメンバーである必要があります。 現在のユーザーが Administrators グループのメンバーであるアカウントにログオンしている場合でも、資格情報が必要になる場合があります。

現在のユーザーがリモート コンピューターの Administrators グループのメンバーである場合、または Administrators グループのメンバーの資格情報を指定できる場合は、 コマンドレットまたは Invoke-Command コマンドレットの New-PSSessionEnter-PSSession Credential パラメーターを使用してリモート接続します。

たとえば、次のコマンドは管理者の資格情報を提供します。

Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01

Credential パラメーターの詳細については、「New-PSSession」、「Enter-PSSession」、または「Invoke-Command」を参照してください。

管理者以外のユーザーに対してリモート処理を有効にする方法

ERROR:  ACCESS IS DENIED

PSSession を確立するか、リモート コンピューターでコマンドを実行するには、リモート コンピューターでセッション構成を使用するアクセス許可が必要です。

既定では、コンピューター上の Administrators グループのメンバーのみが、既定のセッション構成を使用するアクセス許可を持ちます。 そのため、Administrators グループのメンバーのみがリモートでコンピューターに接続できます。

他のユーザーがローカル コンピューターに接続できるようにするには、ローカル コンピューターの既定のセッション構成に対する実行アクセス許可をユーザーに付与します。

次のコマンドは、ローカル コンピューター上の既定の Microsoft.PowerShell セッション構成のセキュリティ記述子を変更できるプロパティ シートを開きます。

Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI

詳細については、「 about_Session_Configurations」を参照してください。

他のドメインの管理者に対してリモート処理を有効にする方法

ERROR:  ACCESS IS DENIED

別のドメインのユーザーがローカル コンピューターの Administrators グループのメンバーである場合、ユーザーは管理者特権でローカル コンピューターにリモートで接続できません。 既定では、他のドメインからのリモート接続は、標準のユーザー特権トークンのみで実行されます。

ただし、LocalAccountTokenFilterPolicy レジストリ エントリを使用して既定の動作を変更し、Administrators グループのメンバーであるリモート ユーザーが管理者特権で実行できるようにすることができます。

注意事項

LocalAccountTokenFilterPolicy エントリは、影響を受けるすべてのコンピューターのすべてのユーザーのユーザー アカウント制御 (UAC) リモート制限を無効にします。 ポリシーを変更する前に、この設定の影響を慎重に検討してください。

ポリシーを変更するには、次のコマンドを使用して、LocalAccountTokenFilterPolicy レジストリ エントリの値を 1 に設定します。

New-ItemProperty -Name LocalAccountTokenFilterPolicy `
  -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System `
  -PropertyType DWord -Value 1

リモート コマンドで IP アドレスを使用する方法

ERROR:  The WinRM client cannot process the request. If the
authentication scheme is different from Kerberos, or if the client
computer is not joined to a domain, then HTTPS transport must be used
or the destination machine must be added to the TrustedHosts
configuration setting.

および コマンドレットの New-PSSessionEnter-PSSessionInvoke-Command ComputerName パラメーターは、有効な値として IP アドレスを受け入れます。 ただし、Kerberos 認証では IP アドレスがサポートされていないため、IP アドレスを指定するたびに NTLM 認証が既定で使用されます。

NTLM 認証を使用する場合は、リモート処理に次の手順が必要です。

  1. HTTPS トランスポート用にコンピューターを構成するか、リモート コンピューターの IP アドレスをローカル コンピューターの TrustedHosts リストに追加します。

    手順については、以下の「TrustedHosts リストにコンピューターを追加する方法」を参照してください。

  2. すべてのリモート コマンドで Credential パラメーターを使用します。

    これは、現在のユーザーの資格情報を送信する場合でも必要です。

ワークグループ ベースのコンピューターからリモートで接続する方法

ERROR:  The WinRM client cannot process the request. If the
authentication scheme is different from Kerberos, or if the client
computer is not joined to a domain, then HTTPS transport must be used
or the destination machine must be added to the TrustedHosts
configuration setting.

ローカル コンピューターがドメインにない場合は、リモート処理に次の手順が必要です。

  1. HTTPS トランスポート用にコンピューターを構成するか、リモート コンピューターの名前をローカル コンピューターの TrustedHosts リストに追加します。

    手順については、以下の「TrustedHosts リストにコンピューターを追加する方法」を参照してください。

  2. ワークグループ ベースのコンピューターでパスワードが設定されていることを確認します。 パスワードが設定されていない場合、またはパスワード値が空の場合は、リモート コマンドを実行できません。

    ユーザー アカウントのパスワードを設定するには、コントロール パネルの [ユーザー アカウント] を使用します。

  3. すべてのリモート コマンドで Credential パラメーターを使用します。

    これは、現在のユーザーの資格情報を送信する場合でも必要です。

信頼できるホストの一覧にコンピューターを追加する方法

TrustedHosts 項目には、コンピューター名、IP アドレス、完全修飾ドメイン名のコンマ区切りの一覧を含めることができます。 ワイルドカードを使用できます。

信頼されたホストリストを表示または変更するには、WSMan: ドライブを使用します。 TrustedHost 項目は WSMan:\localhost\Client ノードにあります。

コンピューター上の Administrators グループのメンバーのみが、コンピューター上の信頼されたホストの一覧を変更するアクセス許可を持っています。

注意: TrustedHosts 項目に設定した値は、コンピューターのすべてのユーザーに影響します。

信頼されたホストの一覧を表示するには、次のコマンドを使用します。

Get-Item wsman:\localhost\Client\TrustedHosts

コマンドレット (alias = cd) を Set-Location 使用して、WSMan: ドライブをその場所に移動することもできます。 例:

cd WSMan:\localhost\Client; dir

すべてのコンピューターを信頼済みホストの一覧に追加するには、次のコマンドを使用して、ComputerName に * (all) の値を配置します。

Set-Item wsman:localhost\client\trustedhosts -Value *

ワイルドカード文字 (*) を使用して、特定のドメイン内のすべてのコンピューターを信頼済みホストの一覧に追加することもできます。 たとえば、次のコマンドは、Fabrikam ドメイン内のすべてのコンピューターを信頼済みホストの一覧に追加します。

Set-Item wsman:localhost\client\trustedhosts *.fabrikam.com

特定のコンピューターの名前を信頼済みホストの一覧に追加するには、次のコマンド形式を使用します。

Set-Item wsman:\localhost\Client\TrustedHosts -Value <ComputerName>

各値 <ComputerName> には次の形式が必要です。

<Computer>.<Domain>.<Company>.<top-level-domain>

例:

$server = 'Server01.Domain01.Fabrikam.com'
Set-Item wsman:\localhost\Client\TrustedHosts -Value $server

信頼されたホストの既存のリストにコンピューター名を追加するには、最初に現在の値を変数に保存し、値を現在の値と新しい値を含むコンマ区切りのリストに設定します。

たとえば、信頼されたホストの既存の一覧に Server01 コンピューターを追加するには、次のコマンドを使用します。

$curValue = (Get-Item wsman:\localhost\Client\TrustedHosts).value

Set-Item wsman:\localhost\Client\TrustedHosts -Value `
  "$curValue, Server01.Domain01.Fabrikam.com"

特定のコンピューターの IP アドレスを信頼されたホストの一覧に追加するには、次のコマンド形式を使用します。

Set-Item wsman:\localhost\Client\TrustedHosts -Value <IP Address>

例:

Set-Item wsman:\localhost\Client\TrustedHosts -Value 172.16.0.0

リモート コンピューターの TrustedHosts リストにコンピューターを追加するには、 コマンドレットを Connect-WSMan 使用して、リモート コンピューターのノードをローカル コンピューターの WSMan: ドライブに追加します。 次に、 コマンドを Set-Item 使用してコンピューターを追加します。

コマンドレットの Connect-WSMan 詳細については、「 Connect-WSMan」を参照してください。

コンピューターの構成に関する問題のトラブルシューティング

このセクションでは、コンピューター、ドメイン、または企業の特定の構成に関連するリモート処理の問題について説明します。

代替ポートでリモート処理を構成する方法

ERROR:  The connection to the specified remote host was refused. Verify
that the WS-Management service is running on the remote host and
configured to listen for requests on the correct port and HTTP URL.

Windows PowerShellリモート処理では、既定で HTTP トランスポートにポート 80 が使用されます。 既定のポートは、ユーザーがリモート コマンドで ConnectionURI パラメーターまたは Port パラメーターを指定しない場合に常に使用されます。

Windows PowerShell使用する既定のポートを変更するには、WSMan: ドライブのコマンドレットを使用Set-Itemして、リスナー リーフ ノードの [ポート] の値を変更します。

たとえば、次のコマンドは、既定のポートを 8080 に変更します。

Set-Item wsman:\localhost\listener\listener*\port -Value 8080

プロキシ サーバーを使用してリモート処理を構成する方法

ERROR: The client cannot connect to the destination specified in the
request. Verify that the service on the destination is running and is
accepting requests.

PowerShell リモート処理では HTTP プロトコルが使用されるため、HTTP プロキシ設定の影響を受けます。 プロキシ サーバーがある企業では、ユーザーは PowerShell リモート コンピューターに直接アクセスできません。

この問題を解決するには、リモート コマンドでプロキシ設定オプションを使用します。 次の設定を使用できます。

  • ProxyAccessType
  • ProxyAuthentication
  • ProxyCredential

特定のコマンドに対してこれらのオプションを設定するには、次の手順に従います。

  1. エンタープライズのプロキシ設定を使用してセッション オプション オブジェクトを作成するには、コマンドレットの New-PSSessionOption ProxyAccessType、ProxyAuthentication、および ProxyCredential パラメーターを使用します。 オプション オブジェクトを変数として保存します。

  2. オプション オブジェクトを含む変数を、、Enter-PSSession、または Invoke-Command コマンドの SessionOption パラメーターのNew-PSSession値として使用します。

たとえば、次のコマンドは、プロキシ セッション オプションを含むセッション オプション オブジェクトを作成し、 オブジェクトを使用してリモート セッションを作成します。

$SessionOption = New-PSSessionOption -ProxyAccessType IEConfig `
-ProxyAuthentication Negotiate -ProxyCredential Domain01\User01

New-PSSession -ConnectionURI https://www.fabrikam.com

コマンドレットの New-PSSessionOption 詳細については、「 New-PSSessionOption」を参照してください。

現在のセッション内のすべてのリモート コマンドに対してこれらのオプションを設定するには、$PSSessionOption基本設定変数の値に を作成する New-PSSessionOption option オブジェクトを使用します。 $PSSessionOption基本設定変数の詳細については、「about_Preference_Variables」を参照してください。

ローカル コンピューター上のすべての PowerShell セッションのすべてのリモート コマンドに対してこれらのオプションを設定するには、$PSSessionOption基本設定変数を PowerShell プロファイルに追加します。 PowerShell プロファイルの詳細については、「about_Profiles」を参照してください。

64 ビット コンピューターで 32 ビット セッションを検出する方法

ERROR: The term "<tool-Name>" is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the
name, or if a path was included, verify that the path is correct and try
again.

リモート コンピューターが 64 ビット バージョンの Windows を実行していて、リモート コマンドが Microsoft.PowerShell32 などの 32 ビット セッション構成を使用している場合、Windows リモート管理 (WinRM) は WOW64 プロセスを読み込み、Windows によってディレクトリへのすべての参照がディレクトリに$env:Windir\System32$env:Windir\SysWOW64自動的にリダイレクトされます。

その結果、SysWow64 ディレクトリに対応するものがない System32 ディレクトリ内のツール ( Defrag.exeなど) を使用しようとすると、 ディレクトリにツールが見つかりません。

セッションで使用されているプロセッサ アーキテクチャを見つけるには、PROCESSOR_ARCHITECTURE環境変数の値を使用します。 次のコマンドは、セッションのプロセッサ アーキテクチャを $s 変数で検索します。

$s = New-PSSession -ComputerName Server01 -ConfigurationName CustomShell
Invoke-Command -Session $s {$env:PROCESSOR_ARCHITECTURE}

x86

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

ポリシーと基本設定に関する問題のトラブルシューティング

このセクションでは、ローカル コンピューターとリモート コンピューターで設定されたポリシーと基本設定に関連するリモート処理の問題について説明します。

IMPORT-PSSESSION および IMPORT-MODULE の実行ポリシーを変更する方法

ERROR: Import-Module: File <filename> cannot be loaded because the
execution of scripts is disabled on this system.

コマンドレットと Export-PSSession コマンドレットはImport-PSSession、署名されていないスクリプト ファイルと書式設定ファイルを含むモジュールを作成します。

または Import-Moduleを使用Import-PSSessionしてこれらのコマンドレットによって作成されたモジュールをインポートするには、現在のセッションの実行ポリシーを Restricted または AllSigned にすることはできません。 (Windows PowerShell実行ポリシーの詳細については、「about_Execution_Policies」を参照してください。

レジストリに設定されているローカル コンピューターの実行ポリシーを変更せずにモジュールをインポートするには、 の Set-ExecutionPolicy Scope パラメーターを使用して、1 つのプロセスに対して制限の緩い実行ポリシーを設定します。

たとえば、次のコマンドは、RemoteSigned 実行ポリシーを使用してプロセスを開始します。 実行ポリシーの変更は現在のプロセスにのみ影響し、PowerShell ExecutionPolicy レジストリ設定は変更されません。

Set-ExecutionPolicy -Scope process -ExecutionPolicy RemoteSigned

また、 PowerShell.exe の ExecutionPolicy パラメーターを使用して、制限の緩い実行ポリシーを使用して 1 つのセッションを開始することもできます。

PowerShell.exe -ExecutionPolicy RemoteSigned

コマンドレットの詳細については、「、、および Import-Module」を参照してください。Import-PSSessionExport-PSSession 実行ポリシーの詳細については、「about_Execution_Policies」を参照してください。 PowerShell.exe コンソールのヘルプ オプションの詳細については、「PowerShell.exe -?"」と入力します。

クォータを設定および変更する方法

ERROR: The total data received from the remote client exceeded allowed
maximum.

クォータを使用して、ローカル コンピューターとリモート コンピューターを、偶発的にも悪意のあるものも含め、過剰なリソース使用から保護できます。

基本構成では、次のクォータを使用できます。

  • WSMan プロバイダー (WSMan:) には、ノードの MaxEnvelopeSizeKB と MaxProviderRequests 設定、ノードの WSMan:<ComputerName>MaxConcurrentOperations、MaxConcurrentOperationsPerUser、MaxConnections 設定など、いくつかのクォータ設定がWSMan:<ComputerName>\Service用意されています。

  • ローカル コンピューターを保護する場合は、コマンドレットの MaximumReceivedDataSizePerCommand パラメーターと MaximumReceivedObjectSize パラメーター New-PSSessionOption と$PSSessionOption基本設定変数を使用します。

  • リモート コンピューターを保護するには、コマンドレットの MaximumReceivedDataSizePerCommandMB パラメーターと MaximumReceivedObjectSizeMB パラメーターを使用するなど、セッション構成に制限を Register-PSSessionConfiguration 追加します。

クォータがコマンドと競合すると、PowerShell でエラーが生成されます。

このエラーを解決するには、クォータに準拠するようにリモート コマンドを変更します。 または、クォータのソースを特定し、クォータを増やしてコマンドの完了を許可します。

たとえば、次のコマンドを実行すると、リモート コンピューター上の Microsoft.PowerShell セッション構成のオブジェクト サイズ クォータが 10 MB (既定値) から 11 MB に増やされます。

Set-PSSessionConfiguration -Name microsoft.PowerShell `
  -MaximumReceivedObjectSizeMB 11 -Force

コマンドレットの New-PSSessionOption 詳細については、「」を参照してください New-PSSessionOption。

WS-Management クォータの詳細については、「 about_WSMan_Provider」を参照してください。

タイムアウト エラーを解決する方法

ERROR: The WS-Management service cannot complete the operation within
the time specified in OperationTimeout.

タイムアウトを使用して、ローカル コンピューターとリモート コンピューターを、偶発的にも悪意のあるものも含め、過剰なリソース使用から保護できます。 ローカル コンピューターとリモート コンピューターの両方でタイムアウトが設定されている場合、PowerShell では最短のタイムアウト設定が使用されます。

基本的な構成では、次のタイムアウトを使用できます。

  • WSMan プロバイダー (WSMan:) には、ノードの MaxTimeoutms 設定、ノードの WSMan:<ComputerName>EnumerationTimeoutms および MaxPacketRetrievalTimeSeconds 設定など、クライアント側とサービス側の WSMan:<ComputerName>\Service タイムアウト設定がいくつか用意されています。

  • コマンドレットと$PSSessionOption基本設定変数の CancelTimeout、 IdleTimeout、 OpenTimeout、 OperationTimeout の各パラメーターを New-PSSessionOption 使用して、ローカル コンピューターを保護できます。

  • また、セッションのセッション構成でプログラムでタイムアウト値を設定することで、リモート コンピューターを保護することもできます。

タイムアウト値が操作の完了を許可しない場合、Windows PowerShellは操作を終了し、エラーを生成します。

エラーを解決するには、タイムアウト間隔内に完了するようにコマンドを変更するか、タイムアウト制限の原因を特定し、タイムアウト間隔を長くしてコマンドを完了させます。

たとえば、次のコマンドでは、 コマンドレットを New-PSSessionOption 使用して OperationTimeout 値が 4 分 (MS) のセッション オプション オブジェクトを作成し、セッション オプション オブジェクトを使用してリモート セッションを作成します。

$pso = New-PSSessionoption -OperationTimeout 240000

New-PSSession -ComputerName Server01 -sessionOption $pso

WS-Management タイムアウトの詳細については、WSMan プロバイダーのヘルプ トピックを参照してください (「Get-Help WSMan」と入力してください)。

コマンドレットの New-PSSessionOption 詳細については、「 New-PSSessionOption」を参照してください。

応答しない動作のトラブルシューティング

このセクションでは、コマンドの完了を妨げるリモート処理の問題について説明し、PowerShell プロンプトの戻りを防止または遅延させます。

コマンドを中断する方法

ユーザー インターフェイスを備えたプログラム、入力を求めるコンソール アプリケーション、Win32 コンソール API を使用するコンソール アプリケーションなど、一部のネイティブ Windows プログラムは、PowerShell リモート ホストで正しく動作しません。

これらのプログラムを使用すると、出力なし、部分的な出力、完了しないリモート コマンドなど、予期しない動作が発生する可能性があります。

応答しないプログラムを終了するには、「」と入力します CTRL+C。 報告された可能性のあるエラーを表示するには、ローカル ホストとリモート セッションを入力 $error します。

操作エラーから回復する方法

ERROR: The I/O operation has been aborted because of either a thread exit
or an  application request.

このエラーは、操作が完了する前に終了すると返されます。 通常、これは、他の WinRM 操作の進行中に WinRM サービスが停止または再起動したときに発生します。

この問題を解決するには、WinRM サービスが実行されていることを確認し、コマンドをもう一度試してください。

  1. [管理者として実行] オプションを使用して PowerShell を起動します。

  2. 次のコマンドを実行します。

    Start-Service WinRM

  3. エラーを生成したコマンドを再実行します。

関連項目

about_Remote

about_Remote_Requirements

about_Remote_Variables