about_Remote_Troubleshooting
簡単な説明
PowerShell でリモート操作のトラブルシューティングを行う方法について説明します。
長い説明
PowerShell リモート処理を使用する前に、構成と基本的な使用に関するガイダンスについては、「 about_Remote と about_Remote_Requirements 」を参照してください。
ドライブ内のローカル コンピューターの設定を表示または変更するには、管理者権限が WSMan: 必要です。 これには、セッション構成、信頼されたホスト、ポート、またはリスナーの変更が含まれます。
[管理者として実行] オプションを使用して PowerShell を実行 する必要があります。
管理者として実行する方法
エラーの場合:
エラー: アクセスが拒否されました。 管理者特権のプロセスからこのコマンドレットを実行する必要があります。
[管理者として実行] オプションでWindows PowerShellを開始するには、[スタート] メニューの [PowerShell] アイコンを右クリックし、[管理者として実行] を選択します。
リモート処理を有効にする方法
エラーの場合:
- エラー: アクセスが拒否されました
- エラー: リモート ホストへの接続が拒否されました。 WS-Management サービスがリモート ホストで実行されており、正しいポートと HTTP URL で要求をリッスンするように構成されていることを確認します。
リモート コマンドを受信するには、コンピューターで PowerShell リモート処理を有効にする必要があります。 Windows PowerShellリモート処理は、Windows Server の新しいリリースWindows Server 2012既定で有効になっています。 リモート処理が無効になっている場合は、 を実行 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 同じローカル サブネットからのトラフィックを許可するファイアウォール規則が作成されます。
注意
Windows PowerShell 2.0 では、サーバー バージョンの Windows を実行しているコンピューターで、プライベート、Enable-PSRemotingドメイン、パブリック ネットワークでリモート アクセスを許可するファイアウォール規則を作成します。 Windows のクライアント バージョンを実行しているコンピューターでは、 Enable-PSRemoting プライベート ネットワークとドメイン ネットワークでのみリモート アクセスを許可するファイアウォール規則を作成します。
パブリック ネットワークのローカル サブネット制限を削除し、任意の場所からのリモート アクセスを許可するには、次のコマンドを実行します。
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
コマンドレットは Set-NetFirewallRule 、 NetSecurity モジュールによってエクスポートされます。
注意
ファイアウォール規則の名前は、Windows のバージョンによって異なる場合があります。 ルールの一覧を表示するには、 を使用 Get-NetFirewallRule します。 ファイアウォール規則を有効にする前に、規則のセキュリティ設定を表示して、構成が環境に適していることを確認します。
グループ ポリシーを使用してファイアウォール例外を有効にする方法
エラーの場合:
- エラー: アクセスが拒否されました
- エラー: リモート ホストへの接続が拒否されました。 WS-Management サービスがリモート ホストで実行されており、正しいポートと HTTP URL で要求をリッスンするように構成されていることを確認します。
[Windows ファイアウォール: ローカル ポート例外を許可する] ポリシーを使用して、ドメイン内のすべてのコンピューターでのファイアウォール例外を有効にします。
ポリシーは、次のグループ ポリシーパスにあります。
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 では、既存のセッション構成は変更されません。
注意
既定のセッション構成を復元しても Enable-PSRemoting 、構成の明示的なセキュリティ記述子は作成されません。 代わりに、構成は RootSDDL のセキュリティ記述子を継承します。これは既定でセキュリティで保護されています。
RootSDDL セキュリティ記述子を表示するには、次のように入力します。
Get-Item wsman:\localhost\Service\RootSDDL
RootSDDL を変更するには、ドライブの Set-Item コマンドレットをWSMan:使用します。 セッション構成のセキュリティ記述子を変更するには、SecurityDescriptorSDDL パラメーターまたは ShowSecurityDescriptorUI パラメーターを指定して コマンドレットを使用Set-PSSessionConfigurationします。
ドライブの WSMan: 詳細については、「 about_WSMan_Provider」を参照してください。
管理者の資格情報を指定する方法
エラーの場合:
エラー: アクセスが拒否されました
既定のリモート セッション エンドポイントに接続するには、Administrators グループのメンバーである必要があります。 、または Invoke-Command コマンドレットの Credential パラメーターをNew-PSSessionEnter-PSSession使用して、代替資格情報を使用してリモート エンドポイントに接続できます。
次の例は、管理者ユーザーの資格情報を指定する方法を示しています。
Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01
Credential パラメーターの詳細については、New-PSSession、Enter-PSSession、または Invoke-Command のヘルプを参照してください。
管理者以外のユーザーに対してリモート処理を有効にする方法
エラーの場合:
エラー: アクセスが拒否されました
既定では、コンピューター上の Administrators グループのメンバーのみが、既定のセッション構成を使用するアクセス許可を持ちます。 そのため、Administrators グループのメンバーのみがリモートでコンピューターに接続できます。
他のユーザーがローカル コンピューターに接続できるようにするには、ローカル コンピューターの既定のセッション構成に対する 実行 アクセス許可をユーザーに付与します。
次の例では、ローカル コンピューターの既定 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-PSSessionEnter-PSSessionInvoke-CommandComputerName パラメーターは、有効な値として 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 使用して接続し WSMan: 、コンピューターの追加に使用 Set-Item するリモート コンピューターを駆動します。
詳細については、 Connect-WSMan のヘルプを参照してください。
代替ポートでリモート処理を構成する方法
エラーの場合:
エラー: 指定されたリモート ホストへの接続が拒否されました。 WS-Management サービスがリモート ホストで実行されており、正しいポートと HTTP URL で要求をリッスンするように構成されていることを確認します。
PowerShell リモート処理では、既定で HTTP トランスポートにポート 80 が使用されます。 既定のポートは、ユーザーがリモート コマンドで ConnectionURI パラメーターまたは ポート パラメーターを指定しない場合に常に使用されます。
コマンドレットを使用して Set-Item 、リスナー リーフ ノードの Port 値を変更します。
たとえば、次のコマンドは既定のポートを 8080 に変更します。
Set-Item wsman:\localhost\listener\listener*\port -Value 8080
プロキシ サーバーを使用してリモート処理を構成する方法
エラーの場合:
エラー: クライアントは要求で指定された宛先に接続できません。 宛先のサービスが実行されていて、要求を受け入れることを確認します。
PowerShell リモート処理では HTTP プロトコルが使用されるため、HTTP プロキシ設定の影響を受けます。 プロキシ サーバーを持つ企業では、ユーザーは PowerShell リモート コンピューターに直接アクセスできません。
この問題を解決するには、リモート コマンドでプロキシ設定オプションを使用します。
- エンタープライズのプロキシ設定を使用して PSSessionOption オブジェクトを含む変数を作成するには、コマンドレットの
New-PSSessionOptionProxyAccessType、ProxyAuthentication、ProxyCredential パラメーターを使用します。 - PSSessionOption オブジェクトを含む変数を使用して、、
Enter-PSSession、またはInvoke-Commandコマンドの SessionOption パラメーターをNew-PSSession使用します。
$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 セッションのすべてのリモート コマンドに対してこれらのオプションを設定するには、ユーザー設定変数を PowerShell プロファイルに追加 $PSSessionOption します。 PowerShell プロファイルの詳細については、「 about_Profiles」を参照してください。
64 ビット コンピューターで 32 ビット セッションを検出する方法
エラーの場合:
エラー: ツール名>という用語<は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。 名前が正しく記述されていることを確認し、パスが含まれている場合はそのパスが正しいことを確認してから、再試行してください。
リモート コンピューターが 64 ビット バージョンの Windows を実行していて、リモート コマンドで Microsoft.PowerShell32 などの 32 ビット セッション構成が使用されている場合、WinRM は WOW64 プロセスを読み込みます。 Windows は、ディレクトリへのすべての参照を $env:Windir\System32 自動的に $env:Windir\SysWOW64 リダイレクトします。
その結果、ディレクトリ内に System32 対応するツールがないディレクトリで実行しているツールが SysWow64 見つかりません。
セッションで使用されているプロセッサ アーキテクチャを見つけるには、 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: このシステムではスクリプトの実行が無効になっているため、ファイル <ファイル名> を読み込めません。
コマンドレットと Export-PSSession コマンドレットはImport-PSSession、署名されていないスクリプト ファイルと書式設定ファイルを含むモジュールを作成します。
これらのコマンドレットによって作成されたモジュールをインポートするには、現在のセッションの実行ポリシーを または AllSignedにRestrictedすることはできません。 詳細については、「about_Execution_Policies」を参照してください。
ローカル コンピューターの実行ポリシーを変更せずにモジュールをインポートするには、 の Set-ExecutionPolicyScope パラメーターを使用して、1 つのプロセスに対して制限の緩い実行ポリシーを設定します。
たとえば、次の例では、現在のプロセスの実行ポリシーを に RemoteSigned 設定します。 変更は現在のプロセスにのみ影響します。
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
ExecutionPolicy パラメーター を使用して、制限のPowerShell.exe緩い実行ポリシーで 1 つのセッションを開始することもできます。
pwsh.exe -ExecutionPolicy RemoteSigned
クォータを設定および変更する方法
クォータを使用して、ローカル コンピューターとリモート コンピューターを、偶発的および悪意のあるリソースの過剰な使用から保護できます。 クォータがコマンドと競合すると、PowerShell によって次のエラーが生成されます。
エラー: リモート クライアントから受信したデータの合計が許可された最大値を超えました。
WSMan プロバイダーには、次のクォータ設定があります。
- ノードの MaxEnvelopeSizeKB と MaxProviderRequests 設定、およびノードの
WSMan:<ComputerName>MaxConcurrentOperations、 MaxConcurrentOperationsPerUser、 MaxConnections 設定WSMan:<ComputerName>\Service。 - ローカル コンピューターを保護するには、コマンドレットとユーザー設定変数の
New-PSSessionOptionMaximumReceivedDataSizePerCommand パラメーターと$PSSessionOptionMaximumReceivedObjectSize パラメーターを使用できます。 - リモート コンピューターを保護するには、コマンドレットの MaximumReceivedDataSizePerCommandMB パラメーターと MaximumReceivedObjectSizeMB パラメーターを使用して、セッション構成に制限を
Register-PSSessionConfiguration追加します。
エラーを解決するには、リモート コマンドを変更してクォータに準拠するか、クォータを増やしてコマンドを完了できるようにします。
たとえば、次のコマンドは、リモート コンピューター上の 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 プロバイダーには、次のタイムアウト設定があります。
- ノードの
WSMan:<ComputerName>MaxTimeoutMs 設定と、ノードの EnumerationTimeoutMs と MaxPacketRetrievalTimeSeconds 設定WSMan:<ComputerName>\Service。 - コマンドレットと基本設定変数の 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 リモート処理」を参照してください。