about_Remote_Troubleshooting
簡単な説明
PowerShell でリモート操作のトラブルシューティングを行う方法について説明します。
長い説明
このセクションでは、WS-Management テクノロジに基づく PowerShell のリモート処理機能を使用するときに発生する可能性があるいくつかの問題について説明し、これらの問題の解決策を提案します。
PowerShell リモート処理を使用する前に、構成と基本的な使用に関するガイダンスについては、「 about_Remote と about_Remote_Requirements 」を参照してください。 また、各リモート処理コマンドレットのヘルプ トピック (特にパラメーターの説明) には、問題の回避に役立つ有用な情報があります。
注意
WSMan: ドライブ内のローカル コンピューターの設定 (セッション構成、信頼されたホスト、ポート、リスナーの変更など) を表示または変更するには、[ 管理者として実行 ] オプションを使用して PowerShell を起動します。
アクセス許可と認証に関する問題のトラブルシューティング
このセクションでは、ユーザーとコンピューターのアクセス許可とリモート処理の要件に関連するリモート処理の問題について説明します。
管理者として実行する方法
ERROR: Access is denied. You need to run this cmdlet from an elevated
process.
ローカル コンピューターでリモート セッションを開始する場合、または 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 2012以降の Windows Server リリースでリモート処理を再度有効にすることもできます。
リモート コマンドを受信するようにコンピューターを構成するには、 コマンドレットを使用します 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。ファイアウォール例外を有効にするには、 Windows ファイアウォール: ローカル ポート例外の許可 グループ ポリシーを使用します。
グループ ポリシーを使用してリスナーを有効にする方法
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 service
ポリシーを有効にし、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 のバージョンによって異なる場合があります。 ルールの一覧を表示するには、 を使用 Get-NetFirewallRule します。 ファイアウォール規則を有効にする前に、規則のセキュリティ設定を表示して、構成が環境に適していることを確認します。
注意
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 リモート管理サービスのファイアウォール例外を作成できます。
ポリシーの構成が正しくない場合は、次のエラーが発生する可能性があります。
The client cannot connect to the destination specified in the request. Verify
that the service on the destination is running and is accepting requests.
ポリシーの構成エラーが発生すると、 ListeningOn プロパティの値が空になります。 値をチェックするには、次のコマンドを使用します。
PS> Get-WSManInstance winrm/config/listener -Enumerate
cfg : http://schemas.microsoft.com/wbem/wsman/1/config/listener
xsi : http://www.w3.org/2001/XMLSchema-instance
Source : GPO
lang : en-US
Address : *
Transport : HTTP
Port : 5985
Hostname :
Enabled : true
URLPrefix : wsman
CertificateThumbprint :
ListeningOn : {}
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 グループのメンバーの資格情報を指定できる場合は、 の Credential パラメーターNew-PSSessionEnter-PSSessionまたは Invoke-Command コマンドレットを使用してリモート接続します。
たとえば、次のコマンドは管理者の資格情報を提供します。
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-PSSessionComputerName パラメーターは、有効な値として IP アドレスを受け入れます。Invoke-Command ただし、Kerberos 認証では IP アドレスがサポートされていないため、IP アドレスを指定するたびに NTLM 認証が既定で使用されます。
NTLM 認証を使用する場合は、リモート処理に次の手順が必要です。
HTTPS トランスポート用にコンピューターを構成するか、リモート コンピューターの IP アドレスをローカル コンピューターの TrustedHosts リストに追加します。
すべてのリモート コマンドで 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.
ローカル コンピューターがドメインにない場合は、リモート処理に次の手順が必要です。
HTTPS トランスポート用にコンピューターを構成するか、リモート コンピューターの名前をローカル コンピューターの TrustedHosts リストに追加します。
ワークグループ ベースのコンピューターでパスワードが設定されていることを確認します。 パスワードが設定されていない場合、またはパスワード値が空の場合は、リモート コマンドを実行できません。
ユーザー アカウントのパスワードを設定するには、コントロール パネルの [ユーザー アカウント] を使用します。
すべてのリモート コマンドで 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.
PowerShell リモート処理では、既定で HTTP トランスポートにポート 80 が使用されます。 既定のポートは、ユーザーがリモート コマンドで ConnectionURI パラメーターまたは Port パラメーターを指定しない場合に常に使用されます。
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
特定のコマンドに対してこれらのオプションを設定するには、次の手順に従います。
エンタープライズのプロキシ設定を使用してセッション オプション オブジェクトを作成するには、コマンドレットの
New-PSSessionOptionProxyAccessType、ProxyAuthentication、および ProxyCredential パラメーターを使用します。 オプション オブジェクトを変数として保存します。オプション オブジェクトを含む変数を、、
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」を参照してください。
現在のセッションのすべてのリモート コマンドに対してこれらのオプションを設定するには、ユーザー設定変数の値に を作成する New-PSSessionOption option オブジェクトを $PSSessionOption 使用します。 詳細については、「 about_Preference_Variables」を参照してください。
ローカル コンピューター上のすべての PowerShell セッションのすべてのリモート コマンドに対してこれらのオプションを設定するには、ユーザー設定変数を PowerShell プロファイルに追加 $PSSessionOption します。 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自動的にリダイレクトされます。
その結果、 などの Defrag.exeSysWow64 ディレクトリに対応するツールがない System32 ディレクトリ内のツールを使用しようとすると、 ディレクトリにツールが見つかりません。
セッションで使用されているプロセッサ アーキテクチャを見つけるには、 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 にすることはできません。 PowerShell 実行ポリシーの詳細については、「 about_Execution_Policies」を参照してください。
レジストリに設定されているローカル コンピューターの実行ポリシーを変更せずにモジュールをインポートするには、 の Set-ExecutionPolicyScope パラメーターを使用して、1 つのプロセスに対して制限の緩い実行ポリシーを設定します。
たとえば、次のコマンドは、実行ポリシーを使用してプロセスを RemoteSigned 開始します。 実行ポリシーの変更は現在のプロセスにのみ影響し、PowerShell ExecutionPolicy レジストリ設定は変更されません。
Set-ExecutionPolicy -Scope process -ExecutionPolicy RemoteSigned
の ExecutionPolicy パラメーターを使用して、制限の PowerShell.exe 緩い実行ポリシーで 1 つのセッションを開始することもできます。
PowerShell.exe -ExecutionPolicy RemoteSigned
実行ポリシーの詳細については、「about_Execution_Policies」を参照してください。 詳細を表示するには「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タイムアウト設定がいくつか用意されています。ローカル コンピューターを保護するには、コマンドレットと基本設定変数の CancelTimeout、 IdleTimeout、 OpenTimeout、 OperationTimeout パラメーター
New-PSSessionOptionを$PSSessionOption使用します。セッションのセッション構成でプログラムでタイムアウト値を設定することで、リモート コンピューターを保護することもできます。
タイムアウト値が操作の完了を許可しない場合、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 リモート ホストで正しく動作しません。
これらのプログラムを使用すると、出力なし、部分的な出力、完了しないリモート コマンドなど、予期しない動作が発生する可能性があります。
応答しないプログラムを終了するには、CtrlC キーを押します+。 報告された可能性のあるエラーを表示するには、ローカル ホストとリモート セッションを入力 $error します。
操作エラーから復旧する方法
ERROR: The I/O operation has been aborted because of either a thread exit
or an application request.
このエラーは、操作が完了する前に終了すると返されます。 通常、これは、他の WinRM 操作の進行中に WinRM サービスが停止または再起動したときに発生します。
この問題を解決するには、WinRM サービスが実行されていることを確認し、コマンドをもう一度試します。
[管理者として実行] オプションを使用して PowerShell を起動します。
次のコマンドを実行します。
Start-Service WinRMエラーを生成したコマンドを再実行します。
Linux と macOS の制限事項
認証
macOS では基本認証のみが機能し、他の認証スキームを使用しようとすると、プロセスがクラッシュする可能性があります。
OMI 認証の手順を参照してください。