about_Remote_Troubleshooting
簡単な説明
PowerShell でリモート操作のトラブルシューティングを行う方法について説明します。
詳細な説明
PowerShell リモート処理を使用する前に、構成と基本的な使用に関するガイダンスについては、 about_Remote と about_Remote_Requirements を参照してください。
WSMan:
ドライブ内のローカル コンピューターの設定を表示または変更するには、管理者権限が必要です。 これには、セッション構成、信頼されたホスト、ポート、またはリスナーの変更が含まれます。
管理者として実行 オプションを使用して PowerShell を実行する必要があります。
管理者として実行する方法
エラーの場合:
エラー: アクセスが拒否されました。 管理者特権のプロセスからこのコマンドレットを実行する必要があります。
Run as administrator オプションを使用して Windows PowerShell を起動するには、[スタート] メニューの PowerShell アイコンを右クリックし、[ 管理者として実行] を選択します。
リモート処理を有効にする方法
エラーの場合:
- エラー: アクセスが拒否されました
- エラー: リモート ホストへの接続が拒否されました。 WS-Management サービスがリモート ホストで実行されており、正しいポートと HTTP URL で要求をリッスンするように構成されていることを確認します。
リモート コマンドを受信するには、コンピューターで PowerShell リモート処理を有効にする必要があります。 Windows PowerShell リモート処理は、Windows Server 2012 以降のリリースの Windows Server で既定で有効になっています。 Enable-PSRemoting
を実行して、リモート処理が無効になっている場合は再び有効にすることができます。 詳細については、「 Enable-PSRemotingを参照してください。
企業でリモート処理を有効にする方法
エラーの場合:
- エラー: アクセスが拒否されました
- エラー: リモート ホストへの接続が拒否されました。 WS-Management サービスがリモート ホストで実行されており、正しいポートと HTTP URL で要求をリッスンするように構成されていることを確認します。
1 台のコンピューターでリモート PowerShell コマンドを受信し、接続を受け入れるようにするには、 Enable-PSRemoting
コマンドレットを使用します。
企業内の複数のコンピューターに対してリモート処理を有効にするには、次のスケーリングされたオプションを使用できます。
- リスナーの自動構成グループ ポリシーを有効にして、リモート処理用のリスナーを構成します。
- Windows ファイアウォール: ローカル ポート例外の許可グループ ポリシーを構成して有効にします。
- WinRM サービスのスタートアップの種類を
Automatic
に設定し、サービスを開始します。
グループ ポリシーを使用してリスナーを有効にする方法
エラーの場合:
- エラー: アクセスが拒否されました
- エラー: リモート ホストへの接続が拒否されました。 WS-Management サービスがリモート ホストで実行されており、正しいポートと HTTP URL で要求をリッスンするように構成されていることを確認します。
リスナーの自動構成ポリシーを有効にして、ドメイン内のすべてのコンピューターのリスナーを構成します。
ポリシーは、次のグループ ポリシー パスにあります。
Computer Configuration\Administrative Templates\Windows Components
\Windows Remote Management (WinRM)\WinRM service
ポリシーを有効にし、IPv4 フィルターと IPv6 フィルターを指定します。 ワイルドカード (*
) を使用できます。
パブリック ネットワークでリモート処理を有効にする方法
Enable-PSRemoting
は、ローカル ネットワークがパブリックであり、コマンドで SkipNetworkProfileCheck パラメーターが使用されていない場合に、このエラーを返します。
エラー: ファイアウォールの状態を確認できません
Windows のサーバー バージョンでは、 Enable-PSRemoting
はすべてのネットワーク プロファイルで成功します。 プライベート ネットワークとドメイン ("Home" ネットワークと "Work" ネットワーク) へのリモート アクセスを許可するファイアウォール規則が作成されます。 パブリック ネットワークでは、同じローカル サブネットからのリモート アクセスを許可するファイアウォール規則が作成されます。
Windows のクライアント バージョンでは、 Enable-PSRemoting
はプライベート ネットワークとドメイン ネットワークで成功します。 既定ではパブリック ネットワークでは失敗しますが、 SkipNetworkProfileCheck パラメーターを使用すると、 Enable-PSRemoting
成功し、同じローカル サブネットからのトラフィックを許可するファイアウォール規則が作成されます。
Note
Windows PowerShell 2.0 では、サーバー バージョンの Windows を実行しているコンピューターで、プライベート、ドメイン、パブリック ネットワークでリモート アクセスを許可するファイアウォール規則を作成 Enable-PSRemoting
。 クライアント バージョンの Windows を実行しているコンピューターでは、 Enable-PSRemoting
はプライベート ネットワークとドメイン ネットワークでのみリモート アクセスを許可するファイアウォール規則を作成します。
パブリック ネットワークのローカル サブネット制限を削除し、任意の場所からリモート アクセスを許可するには、次のコマンドを実行します。
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
Set-NetFirewallRule
コマンドレットは、NetSecurity モジュールによってエクスポートされます。
Note
ファイアウォール規則の名前は、Windows のバージョンによって異なる場合があります。 ルールの一覧を表示するには、 Get-NetFirewallRule
を使用します。 ファイアウォール規則を有効にする前に、規則のセキュリティ設定を表示して、構成が環境に適していることを確認します。
グループ ポリシーを使用してファイアウォール例外を有効にする方法
エラーの場合:
- エラー: アクセスが拒否されました
- エラー: リモート ホストへの接続が拒否されました。 WS-Management サービスがリモート ホストで実行されており、正しいポートと HTTP URL で要求をリッスンするように構成されていることを確認します。
Windows Firewall: Allow local port exceptions policy to enable a firewall exception for all computers in a domain.
ポリシーは、次のグループ ポリシー パスにあります。
Computer Configuration\Administrative Templates\Network
\Network Connections\Windows Firewall\Domain Profile
このポリシーにより、Administrators グループのメンバーは、Windows リモート管理 (WinRM) サービスのファイアウォール例外を作成できます。
ポリシーの構成が正しくない場合は、次のエラーが表示される可能性があります。
クライアントは、要求で指定された宛先に接続できません。 宛先のサービスが実行されていて、要求を受け入れていることを確認します。
ポリシーの構成エラーが発生すると、 ListeningOn プロパティの値が空になります。 次のコマンドを使用して値を確認します。
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 サービスのスタートアップの種類を設定する方法
エラーの場合:
エラー: アクセスが拒否されました
PowerShell リモート処理は、Windows リモート管理 (WinRM) サービスに依存します。 リモート コマンドをサポートするには、サービスが実行されている必要があります。
Windows のサーバー バージョンでは、WinRM サービスのスタートアップの種類が Automatic
。
ただし、Windows のクライアント バージョンでは、WinRM サービスは既定で無効になっています。
次の例を使用して、WinRM サービスのスタートアップの種類を Automatic
に設定し、サービスを開始します。 ComputerName パラメーターは複数の値を受け入れます。
$invokeCimMethodSplat = @{
ComputerName = 'Server01', 'Server02'
Query = 'Select * From Win32_Service Where Name = "WinRM"'
MethodName = 'ChangeStartMode'
Arguments = @{StartMode = 'Automatic'}
}
Invoke-CimMethod @invokeCimMethodSplat
既定のセッション構成を再作成する方法
エラーの場合:
エラー: アクセスが拒否されました
Enable-PSRemoting
を使用すると、ローカル コンピューターに既定のセッション構成が作成されます。 リモート ユーザーは、リモート コマンドに ConfigurationName パラメーターが含まれていない場合は常に、これらのセッション構成を使用します。
コンピューターの既定の構成が登録解除または削除された場合は、 Enable-PSRemoting
コマンドレットを使用して再作成します。 このコマンドレットは繰り返し使用できます。 機能が既に構成されている場合、エラーは生成されません。
既定のセッション構成を変更し、元のセッション構成を復元する場合は、構成を削除して再作成できます。
Unregister-PSSessionConfiguration
コマンドレットを使用して、変更されたセッション構成を削除します。 Enable-PSRemoting
を使用して、元のセッション構成を復元します。 Enable-PSRemoting
では、既存のセッション構成は変更されません。
Note
Enable-PSRemoting
が既定のセッション構成を復元する場合、構成の明示的なセキュリティ記述子は作成されません。 代わりに、構成は既定でセキュリティで保護された RootSDDLのセキュリティ記述子を継承します。
RootSDDLセキュリティ記述子を表示するには、次のように入力します。
Get-Item wsman:\localhost\Service\RootSDDL
RootSDDLを変更するには、WSMan:
ドライブで Set-Item
コマンドレットを使用します。 セッション構成のセキュリティ記述子を変更するには、SecurityDescriptorSDDL または ShowSecurityDescriptorUI パラメーターでSet-PSSessionConfiguration
コマンドレットを使用します。
WSMan:
ドライブの詳細については、「about_WSMan_Provider」を参照してください。
管理者の資格情報を指定する方法
エラーの場合:
エラー: アクセスが拒否されました
既定のリモート セッション エンドポイントに接続するには、Administrators グループのメンバーである必要があります。 New-PSSession
、Enter-PSSession
、またはInvoke-Command
コマンドレットの Credential パラメーターを使用して、代替資格情報を使用してリモート エンドポイントに接続できます。
次の例は、管理者ユーザーの資格情報を指定する方法を示しています。
Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01
Credential パラメーターの詳細については、New-PSSession、Enter-PSSession または Invoke-Command のヘルプを参照してください。
管理者以外のユーザーに対してリモート処理を有効にする方法
エラーの場合:
エラー: アクセスが拒否されました
既定では、コンピューター上の Administrators グループのメンバーのみが、既定のセッション構成を使用するアクセス許可を持ちます。 そのため、Administrators グループのメンバーのみがリモートでコンピューターに接続できます。
他のユーザーがローカル コンピューターに接続できるようにするには、ローカル コンピューターの既定のセッション構成 Execute アクセス許可をユーザーに付与します。
次の例では、ローカル コンピューターの既定の Microsoft.PowerShell
セッション構成のセキュリティ記述子を変更できるプロパティ シートを開きます。
Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI
詳細については、「 about_Session_Configurations」を参照してください。
他のドメインの管理者に対してリモート処理を有効にする方法
エラーの場合:
エラー: アクセスが拒否されました
別のドメインのユーザーがローカル コンピューターの Administrators グループのメンバーである場合、ユーザーは管理者特権でローカル コンピューターにリモート接続できません。 既定では、他のドメインからのリモート接続は、標準のユーザー特権トークンのみで実行されます。
LocalAccountTokenFilterPolicy レジストリ エントリを使用して既定の動作を変更し、Administrators グループのメンバーであるリモート ユーザーが管理者特権で実行できるようにします。
注意事項
LocalAccountTokenFilterPolicy エントリは、影響を受けるすべてのコンピューターのすべてのユーザーのユーザー アカウント制御 (UAC) リモート制限を無効にします。 ポリシーを変更する前に、この設定の影響を慎重に検討してください。
次のコマンドを使用して、 LocalAccountTokenFilterPolicy レジストリ値を 1 に設定します。
$newItemPropertySplat = @{
Name = 'LocalAccountTokenFilterPolicy'
Path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
PropertyType = 'DWord'
Value = 1
}
New-ItemProperty @newItemPropertySplat
リモート コマンドで IP アドレスを使用する方法
エラーの場合:
エラー: WinRM クライアントは要求を処理できません。 認証スキームが Kerberos と異なる場合、またはクライアント コンピューターがドメインに参加していない場合は、HTTPS トランスポートを使用するか、宛先マシンを TrustedHosts 構成設定に追加する必要があります。
New-PSSession
、Enter-PSSession
、および Invoke-Command
コマンドレットの ComputerName パラメーターは、有効な値として IP アドレスを受け取ります。 ただし、Kerberos 認証では IP アドレスがサポートされていないためです。 IP アドレスを指定すると、NTLM 認証が使用されます。
NTLM 認証をサポートするには、次の要件を満たす必要があります。
- HTTPS トランスポート用にコンピューターを構成するか、リモート コンピューターの IP アドレスをローカル コンピューターの TrustedHosts 一覧に追加します。
- すべてのリモート コマンドで Credential パラメーターを使用します。 これは、現在のユーザーとして接続する場合でも必要です。
ワークグループ ベースのコンピューターからリモートで接続する方法
エラーの場合
エラー: WinRM クライアントは要求を処理できません。 認証スキームが Kerberos と異なる場合、またはクライアント コンピューターがドメインに参加していない場合は、HTTPS トランスポートを使用するか、宛先マシンを TrustedHosts 構成設定に追加する必要があります。
ローカル コンピューターがドメインにない場合は、次の要件を満たす必要があります。
- HTTPS トランスポート用にコンピューターを構成するか、リモート コンピューターの IP アドレスをローカル コンピューターの TrustedHosts 一覧に追加します。
- ワークグループ ベースのコンピューターでパスワードが設定されていることを確認します。 パスワードが設定されていない場合、またはパスワード値が空の場合は、リモート コマンドを実行できません。
- すべてのリモート コマンドで Credential パラメーターを使用します。 これは、現在のユーザーとして接続する場合でも必要です。
信頼されたホストの一覧にコンピューターを追加する方法
TrustedHosts項目には、コンピューター名、IP アドレス、および完全修飾ドメイン名のコンマ区切りの一覧を含めることができます。 ワイルドカードを使用できます。
信頼されたホストの一覧を表示または変更するには、 WSMan:
ドライブを使用します。 TrustedHost 項目は、WSMan:\localhost\Client
ノードにあります。 コンピューター上の Administrators グループのメンバーのみが、コンピューター上の信頼されたホストの一覧を変更する権限を持ちます。
注意事項
TrustedHosts 項目に設定した値は、コンピューターのすべてのユーザーに影響します。
信頼されたホストの一覧を表示するには、次のコマンドを使用します。
Get-Item wsman:\localhost\Client\TrustedHosts
次の例では、ワイルドカード文字 (*
) を使用して、すべてのコンピューターを信頼済みホストの一覧に追加します。
Set-Item wsman:localhost\client\trustedhosts -Value *
ワイルドカード文字 (*
) を使用して、特定のドメイン内のすべてのコンピューターを信頼済みホストの一覧に追加することもできます。 たとえば、次のコマンドを実行すると、Fabrikam ドメイン内のすべてのコンピューターが追加されます。
Set-Item wsman:localhost\client\trustedhosts *.fabrikam.com
次の例では、信頼されたホストの一覧を 1 台のコンピューターに設定します。
$server = 'Server01.Domain01.Fabrikam.com'
Set-Item wsman:\localhost\Client\TrustedHosts -Value $server
信頼されたホストの既存の一覧にコンピューター名を追加するには、最初に現在の値を変数に保存します。 次に、現在の値と新しい値を含むコンマ区切りリストを含む文字列に値を設定します。
次の例では、信頼されたホストの既存の一覧に Server01 を追加します。
$newServer = 'Server01.Domain01.Fabrikam.com'
$curValue = (Get-Item wsman:\localhost\Client\TrustedHosts).Value
Set-Item wsman:\localhost\Client\TrustedHosts -Value "$curValue, $newServer"
特定のコンピューターの IP アドレスを信頼されたホストの一覧に追加するには、次のコマンド形式を使用します。
Set-Item wsman:\localhost\Client\TrustedHosts -Value <IP Address>
次に例を示します。
Set-Item wsman:\localhost\Client\TrustedHosts -Value 172.16.0.0
リモート コンピューターのTrustedHosts一覧にコンピューターを追加するには、Connect-WSMan
を使用して、Set-Item
を使用してリモート コンピューターWSMan:
ドライブに接続し、コンピューターを追加します。
詳細については、 Connect-WSMan のヘルプを参照してください。
代替ポートでリモート処理を構成する方法
エラーの場合:
エラー: 指定されたリモート ホストへの接続が拒否されました。 WS-Management サービスがリモート ホストで実行されており、正しいポートと HTTP URL で要求をリッスンするように構成されていることを確認します。
PowerShell リモート処理では、既定で HTTP トランスポートにポート 80 が使用されます。 ユーザーがリモート コマンドで ConnectionURI または Port パラメーターを指定しない場合は常に、既定のポートが使用されます。
Set-Item
コマンドレットを使用して、リスナー リーフ ノードの Port 値を変更します。
たとえば、次のコマンドは既定のポートを 8080 に変更します。
Set-Item wsman:\localhost\listener\listener*\port -Value 8080
プロキシ サーバーを使用してリモート処理を構成する方法
エラーの場合:
エラー: クライアントは、要求で指定された宛先に接続できません。 宛先のサービスが実行されていて、要求を受け入れていることを確認します。
PowerShell リモート処理では HTTP プロトコルが使用されるため、HTTP プロキシ設定の影響を受けます。 プロキシ サーバーがある企業では、ユーザーは PowerShell リモート コンピューターに直接アクセスできません。
この問題を解決するには、リモート コマンドでプロキシ設定オプションを使用します。
New-PSSessionOption
コマンドレットの ProxyAccessType、ProxyAuthentication、および ProxyCredential パラメーターを使用して、エンタープライズのプロキシ設定を持つ PSSessionOption オブジェクトを含む変数を作成します。- PSSessionOptionオブジェクトを含む変数を使用して、
New-PSSession
、Enter-PSSession
、またはInvoke-Command
コマンドの SessionOption パラメーターを使用します。
$newPSSessionOptionSplat = @{
ProxyAccessType = 'IEConfig'
ProxyAuthentication = 'Negotiate'
ProxyCredential = 'Domain01\User01'
}
$SessionOption = New-PSSessionOption @newPSSessionOptionSplat
$newPSSessionSplat = @{
ConnectionUri = 'https://www.fabrikam.com'
SessionOption = $SessionOption
}
New-PSSession @newPSSessionSplat
New-PSSessionOption
コマンドレットの詳細については、「New-PSSessionOptionを参照してください。
現在のセッションのすべてのリモート コマンドに対してこれらのオプションを設定するには、 $PSSessionOption
基本設定変数を作成した PSSessionOption オブジェクトに設定します。 詳細については、「 about_Preference_Variables」を参照してください。
ローカル コンピューター上のすべての PowerShell セッションのすべてのリモート コマンドに対してこれらのオプションを設定するには、 $PSSessionOption
基本設定変数を PowerShell プロファイルに追加します。 PowerShell プロファイルの詳細については、「about_Profiles」を参照してください。
64 ビット コンピューターで 32 ビット セッションを検出する方法
エラーの場合:
エラー: <tool-name> という用語は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。 名前が正しく記述されていることを確認し、パスが含まれている場合はそのパスが正しいことを確認してから、再試行してください。
リモート コンピューターが 64 ビット バージョンの Windows を実行していて、リモート コマンドで Microsoft.PowerShell32 などの 32 ビット セッション構成を使用している場合 WinRM は WOW64 プロセスを読み込みます。 Windows は、 $env:Windir\System32
へのすべての参照を $env:Windir\SysWOW64
ディレクトリに自動的にリダイレクトします。
その結果、SysWow64
ディレクトリに対応するツールがないSystem32
ディレクトリで実行されているツールが見つかりません。
セッションで使用されているプロセッサ アーキテクチャを見つけるには、 PROCESSOR_ARCHITECTURE 環境変数の値を使用します。
$s = New-PSSession -ComputerName Server01 -ConfigurationName CustomShell
Invoke-Command -Session $s {$env:PROCESSOR_ARCHITECTURE}
x86
詳細については、「 about_Session_Configurations」を参照してください。
ポリシーと基本設定に関する問題のトラブルシューティング
このセクションでは、ローカル コンピューターとリモート コンピューターで設定されたポリシーと基本設定に関連するリモート処理の問題について説明します。
Import-PSSession および Import-Module の実行ポリシーを変更する方法
エラーの場合:
エラー: Import-Module: file <filename> は、このシステムでスクリプトの実行が無効になっているため、読み込むことができません。
Import-PSSession
およびExport-PSSession
コマンドレットは、署名されていないスクリプト ファイルと書式設定ファイルを含むモジュールを作成します。
これらのコマンドレットによって作成されたモジュールをインポートするために、現在のセッションの実行ポリシーを Restricted
または AllSigned
することはできません。 詳細については、「about_Execution_Policies」を参照してください。
ローカル コンピューターの実行ポリシーを変更せずにモジュールをインポートするには、Set-ExecutionPolicy
の Scope パラメーターを使用して、1 つのプロセスに対して制限の緩い実行ポリシーを設定します。
たとえば、次の例では、現在のプロセスに対して実行ポリシーを RemoteSigned
に設定します。 変更は現在のプロセスにのみ影響します。
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
PowerShell.exe
の ExecutionPolicy パラメーターを使用して、制限の緩い実行ポリシーで 1 つのセッションを開始することもできます。
pwsh.exe -ExecutionPolicy RemoteSigned
クォータを設定および変更する方法
クォータを使用すると、ローカル コンピューターとリモート コンピューターを、偶発的および悪意のあるリソースの過剰な使用から保護できます。 クォータがコマンドと競合すると、PowerShell によって次のエラーが生成されます。
エラー: リモート クライアントから受信したデータの合計が許可された最大値を超えました。
WSMan プロバイダーには、次のクォータ設定があります。
WSMan:<ComputerName>
ノードの MaxEnvelopeSizeKB および MaxProviderRequests MaxConcurrentOperations、MaxConcurrentOperationsPerUser、および MaxConnectionsWSMan:<ComputerName>\Service
の設定。New-PSSessionOption
コマンドレットの MaximumReceivedDataSizePerCommand および MaximumReceivedObjectSize パラメーターと$PSSessionOption
基本設定変数を使用して、ローカル コンピューターを保護できます。- リモート コンピューターを保護するには、
Register-PSSessionConfiguration
コマンドレットの MaximumReceivedDataSizePerCommandMB および MaximumReceivedObjectSizeMB パラメーターを使用してセッション構成に制限を追加します。
エラーを解決するには、リモート コマンドを変更してクォータに準拠するか、クォータを増やしてコマンドの完了を許可します。
たとえば、次のコマンドを実行すると、リモート コンピューター上の Microsoft.PowerShell セッション構成のオブジェクト サイズ クォータが 10 MB (既定値) から 11 MB に増やされます。
$setPSSessionConfigurationSplat = @{
Name = 'Microsoft.PowerShell'
MaximumReceivedObjectSizeMB = 11
Force = $true
}
Set-PSSessionConfiguration @setPSSessionConfigurationSplat
WS-Management クォータの詳細については、「 about_WSMan_Provider」を参照してください。
タイムアウト エラーを解決する方法
タイムアウトを使用して、ローカル コンピューターとリモート コンピューターを、偶発的および悪意のあるリソースの過剰な使用から保護できます。 ローカル コンピューターとリモート コンピューターの両方でタイムアウトが設定されている場合、PowerShell は最短のタイムアウト設定を使用します。
タイムアウト値が操作の完了を許可しない場合、PowerShell は操作を終了し、次のエラーを生成します。
エラー: WS-Management サービスは、OperationTimeout で指定された時間内に操作を完了できません。
WSMan プロバイダーには、次のタイムアウト設定があります。
- maxTimeoutMs
WSMan:<ComputerName>
ノードの設定と、WSMan:<ComputerName>\Service
ノードの EnumerationTimeoutMs および MaxPacketRetrievalTimeSeconds 設定。 - CancelTimeout、IdleTimeout、OpenTimeout、OperationTimeout
New-PSSessionOption
コマンドレットのパラメーターと$PSSessionOption
基本設定変数を使用して、ローカル コンピューターを保護できます。 - セッションのセッション構成でプログラムでタイムアウト値を設定することで、リモート コンピューターを保護することもできます。
エラーを解決するには、タイムアウト間隔内で完了するようにコマンドを変更するか、タイムアウト間隔を長くしてコマンドの完了を許可します。
次の例では、 OperationTimeout 値が 4 分 (MS) のセッション オプションを作成し、セッション オプションを使用してリモート セッションを作成します。
$pso = New-PSSessionOption -OperationTimeout 240000
New-PSSession -ComputerName Server01 -SessionOption $pso
WS-Management タイムアウトの詳細については、 about_WSMan_Providerを参照してください。
応答しないコマンドを中断する方法
ユーザー インターフェイスを備えたプログラム、入力を求めるコンソール アプリケーション、Win32 コンソール API を使用するコンソール アプリケーションなど、一部のネイティブ プログラムは、PowerShell リモート ホストで正しく動作しません。
これらのプログラムを使用すると、出力なし、部分的な出力、完了しないリモート コマンドなど、予期しない動作が発生する可能性があります。
応答しないプログラムを終了するには、「 Ctrl+c」と入力します。 ローカル ホストとリモート セッションの Get-Error
を使用して、報告された可能性のあるエラーを表示します。
操作エラーから復旧する方法
操作が完了する前に終了すると、次のエラーが返されます。
エラー: スレッドの終了またはアプリケーション要求が原因で、I/O 操作が中止されました。
通常、これは、他の WinRM 操作の進行中に WinRM サービスが停止または再起動したときに発生します。
この問題を解決するには、WinRM サービスが実行されていることを確認し、もう一度コマンドを試してください。
管理者として実行 オプションを使用して PowerShell を起動します。
次のコマンドを実行します。
Start-Service WinRM
エラーを生成したコマンドを再実行します。
Linux と macOS の制限事項
PowerShell リモート処理は、SSH 経由でリモート処理を使用する Linux および macOS です。 詳細については、「SSH 経由のPowerShell リモート処理を参照してください。
関連項目
PowerShell