about_Remote_Troubleshooting
簡単な説明
PowerShell でリモート操作のトラブルシューティングを行う方法について説明します。
詳細な説明
PowerShell リモート処理を使用する前に、構成と基本的な使用に関するガイダンスについては、about_Remoteとabout_Remote_Requirementsを参照してください。
ドライブ内のローカル コンピューターの設定を表示または変更するには、管理者権限が WSMan:
必要です。 これには、セッション構成、信頼されたホスト、ポート、またはリスナーの変更が含まれます。
[管理者として実行] オプションを使用して PowerShell を実行する必要があります。
管理者として実行する方法
エラーの場合:
エラー: アクセスが拒否されました。 管理者特権のプロセスからこのコマンドレットを実行する必要があります。
[管理者として実行] オプションを使用して 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 で要求をリッスンするように構成されていることを確認します。
[リスナーの自動構成を許可する] ポリシーを有効にして、doメイン 内のすべてのコンピューターのリスナーを構成します。
ポリシーは、次のグループ ポリシー パスにあります。
Computer Configuration\Administrative Templates\Windows Components
\Windows Remote Management (WinRM)\WinRM service
ポリシーを有効にし、IPv4 フィルターと IPv6 フィルターを指定します。 ワイルドカード (*
) を使用できます。
パブリック ネットワークでリモート処理を有効にする方法
Enable-PSRemoting
は、ローカル ネットワークがパブリックであり、 SkipNetworkProfileCheck パラメーターがコマンドで使用されていない場合に、このエラーを返します。
エラー: ファイアウォールの状態をチェックできません
Windows のサーバー バージョンでは、 Enable-PSRemoting
すべてのネットワーク プロファイルで成功します。 これにより、プライベートおよび doメイン ("Home" および "Work") ネットワークへのリモート アクセスを許可するファイアウォール規則が作成されます。 パブリック ネットワークでは、同じローカル サブネットからのリモート アクセスを許可するファイアウォール規則が作成されます。
Windows のクライアント バージョンでは、Enable-PSRemoting
プライベート ネットワークと doメイン ネットワークで成功します。 既定では、パブリック ネットワークでは失敗しますが、SkipNetworkProfileCheck パラメーターを使用すると、成功し、Enable-PSRemoting
同じローカル サブネットからのトラフィックを許可するファイアウォール規則が作成されます。
Note
Windows PowerShell 2.0 では、サーバー バージョンの Windows を実行しているコンピューターで、プライベート、do、Enable-PSRemoting
およびパブリック ネットワークでリモート アクセスを許可するファイアウォール規則メインを作成します。 Windows のクライアント バージョンを実行しているコンピューターでは、Enable-PSRemoting
プライベート ネットワークと doメイン ネットワークでのみリモート アクセスを許可するファイアウォール規則を作成します。
パブリック ネットワークのローカル サブネット制限を削除し、任意の場所からリモート アクセスを許可するには、次のコマンドを実行します。
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
このSet-NetFirewallRule
コマンドレットは、NetSecurity モジュールによってエクスポートされます。
Note
ファイアウォール規則の名前は、Windows のバージョンによって異なる場合があります。 ルールの一覧を表示するために使用 Get-NetFirewallRule
します。 ファイアウォール規則を有効にする前に、規則のセキュリティ設定を表示して、構成が環境に適していることを確認します。
グループ ポリシーを使用してファイアウォール例外を有効にする方法
エラーの場合:
- エラー: アクセスが拒否されました
- エラー: リモート ホストへの接続が拒否されました。 WS-Management サービスがリモート ホストで実行されており、正しいポートと HTTP URL で要求をリッスンするように構成されていることを確認します。
Windows ファイアウォールを使用する: doメイン 内のすべてのコンピューターでファイアウォール例外を有効にするローカル ポート例外ポリシーを許可します。
ポリシーは、次のグループ ポリシー パスにあります。
Computer Configuration\Administrative Templates\Network
\Network Connections\Windows Firewall\Domain Profile
このポリシーにより、管理istrators グループのメンバーは、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 を変更するには、ドライブ内のSet-Item
コマンドレットをWSMan:
使用します。 セッション構成のセキュリティ記述子を変更するには、SecurityDescriptorSDDL パラメーターまたは ShowSecurityDescriptorUI パラメーターを指定してコマンドレットを使用Set-PSSessionConfiguration
します。
ドライブの詳細についてはWSMan:
、「about_WSMan_Provider」を参照してください。
管理者の資格情報を指定する方法
エラーの場合:
エラー: アクセスが拒否されました
既定のリモート セッション エンドポイントに接続する管理istrators グループのメンバーである必要があります。 またはコマンドレットの Credential パラメーターをNew-PSSession
Enter-PSSession
Invoke-Command
使用して、代替資格情報を使用してリモート エンドポイントに接続できます。
次の例は、管理者ユーザーの資格情報を指定する方法を示しています。
Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01
Credential パラメーターの詳細については、New-PSSession、Enter-PSSession、または Invoke-Command のヘルプを参照してください。
管理者以外のユーザーに対してリモート処理を有効にする方法
エラーの場合:
エラー: アクセスが拒否されました
既定では、コンピューター上の 管理istrators グループのメンバーのみが、既定のセッション構成を使用するアクセス許可を持ちます。 そのため、コンピューターにリモートで接続できるのは、管理istrators グループのメンバーだけです。
他のユーザーがローカル コンピューターに接続できるようにするには、ローカル コンピューターの既定のセッション構成に対する実行アクセス許可をユーザーに付与します。
次の使用例は、ローカル コンピューターの既定 Microsoft.PowerShell
のセッション構成のセキュリティ記述子を変更できるプロパティ シートを開きます。
Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI
詳細については、「about_Session_Configurations」を参照してください。
他の do で管理者のリモート処理を有効にする方法メイン
エラーの場合:
エラー: アクセスが拒否されました
別の doメイン のユーザーがローカル コンピューターの 管理istrators グループのメンバーである場合、ユーザーは、管理istrator 特権でローカル コンピューターにリモート接続できません。 既定では、他の doメイン からのリモート接続は、標準のユーザー特権トークンのみで実行されます。
LocalAccountTokenFilterPolicy レジストリ エントリを使用して既定の動作を変更し、管理istrators グループのメンバーであるリモート ユーザーが管理istrator 特権で実行できるようにします。
注意事項
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 構成設定に追加する必要があります。
およびInvoke-Command
コマンドレットの New-PSSession
Enter-PSSession
ComputerName パラメーターは、有効な値として IP アドレスを受け入れます。 ただし、Kerberos 認証では IP アドレスがサポートされていないためです。 IP アドレスを指定すると、NTLM 認証が使用されます。
NTLM 認証をサポートするには、次の要件を満たす必要があります。
- HTTPS トランスポート用にコンピューターを構成するか、リモート コンピューターの IP アドレスをローカル コンピューターの TrustedHosts リストに追加します。
- すべてのリモート コマンドで Credential パラメーターを使用します。 これは、現在のユーザーとして接続する場合でも必要です。
ワークグループ ベースのコンピューターからリモートで接続する方法
エラーの場合
エラー: WinRM クライアントは要求を処理できません。 認証スキームが Kerberos と異なる場合、またはクライアント コンピューターがドメインに参加していない場合は、HTTPS トランスポートを使用するか、宛先マシンを TrustedHosts 構成設定に追加する必要があります。
ローカル コンピューターが doメイン に存在しない場合は、次の要件を満たす必要があります。
- HTTPS トランスポート用にコンピューターを構成するか、リモート コンピューターの IP アドレスをローカル コンピューターの TrustedHosts リストに追加します。
- ワークグループ ベースのコンピューターでパスワードが設定されていることを確認します。 パスワードが設定されていない場合、またはパスワード値が空の場合は、リモート コマンドを実行できません。
- すべてのリモート コマンドで Credential パラメーターを使用します。 これは、現在のユーザーとして接続する場合でも必要です。
信頼されたホストの一覧にコンピューターを追加する方法
TrustedHosts 項目には、コンピューター名、IP アドレス、および完全修飾 doメイン 名のコンマ区切りの一覧を含めることができます。 ワイルドカードを使用できます。
信頼されたホストの一覧を表示または変更するには、ドライブを WSMan:
使用します。 TrustedHost 項目がノード内WSMan:\localhost\Client
にあります。 コンピューター上の 管理istrators グループのメンバーのみが、コンピューター上の信頼されたホストの一覧を変更する権限を持ちます。
注意事項
TrustedHosts 項目に設定した 値は、 コンピューターのすべてのユーザーに影響します。
信頼されたホストの一覧を表示するには、次のコマンドを使用します。
Get-Item wsman:\localhost\Client\TrustedHosts
次の例では、ワイルドカード文字 (*
) を使用して、すべてのコンピューターを信頼済みホストの一覧に追加します。
Set-Item wsman:localhost\client\trustedhosts -Value *
また、ワイルドカード文字 (*
) を使用して、特定の do のすべてのコンピューターをメイン信頼されたホストの一覧に追加することもできます。 たとえば、次のコマンドを実行すると、Fabrikam doメイン 内のすべてのコンピューターが追加されます。
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
、リスナー リーフ ノードの ポート 値を変更します。
たとえば、次のコマンドは既定のポートを 8080 に変更します。
Set-Item wsman:\localhost\listener\listener*\port -Value 8080
プロキシ サーバーを使用してリモート処理を構成する方法
エラーの場合:
エラー: クライアントは、要求で指定された宛先に接続できません。 宛先のサービスが実行されていて、要求を受け入れていることを確認します。
PowerShell リモート処理では HTTP プロトコルが使用されるため、HTTP プロキシ設定の影響を受けます。 プロキシ サーバーがある企業では、ユーザーは PowerShell リモート コンピューターに直接アクセスできません。
この問題を解決するには、リモート コマンドでプロキシ設定オプションを使用します。
- コマンドレットの ProxyAccessType、ProxyAuthentication、ProxyCredentialパラメーター
New-PSSessionOption
を使用して、エンタープライズのプロキシ設定を持つ PSSessionOption オブジェクトを含む変数を作成します。 - PSSessionOption オブジェクトを含む変数を使用して、SessionOption パラメーター、
New-PSSession
Enter-PSSession
またはInvoke-Command
コマンドです。
$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
、署名されていないスクリプト ファイルと書式設定ファイルを含むモジュールを作成します。
これらのコマンドレットによって作成されたモジュールをインポートするには、現在のセッションの実行ポリシーを指定することもできませんRestricted
AllSigned
。 詳細については、「about_Execution_Policies」を参照してください。
ローカル コンピューターの実行ポリシーを変更せずにモジュールをインポートするには、Scope パラメーターを使用して、1 つのプロセスに対して制限のSet-ExecutionPolicy
緩い実行ポリシーを設定します。
たとえば、次の例では、現在のプロセスの実行ポリシーを RemoteSigned
設定します。 変更は現在のプロセスにのみ影響します。
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
ExecutionPolicy パラメーターを使用して、制限のPowerShell.exe
緩い実行ポリシーで 1 つのセッションを開始することもできます。
pwsh.exe -ExecutionPolicy RemoteSigned
クォータを設定および変更する方法
クォータを使用すると、ローカル コンピューターとリモート コンピューターを、偶発的および悪意のあるリソースの過剰な使用から保護できます。 クォータがコマンドと競合すると、PowerShell によって次のエラーが生成されます。
エラー: リモート クライアントから受信したデータの合計が許可された最大値を超えました。
WSMan プロバイダーには、次のクォータ設定があります。
- ノードの MaxEnvelopeSize KB (キロバイト) および MaxProviderRequests の設定、およびノードの
WSMan:<ComputerName>
MaxConcurrentOperations、MaxConcurrentOperationsPerUser、および MaxConnections の設定WSMan:<ComputerName>\Service
。 - コマンドレットの MaximumReceivedDataSizePerCommand パラメーターと MaximumReceivedObjectSize パラメーター
New-PSSessionOption
と基本設定変数を$PSSessionOption
使用して、ローカル コンピューターを保護できます。 - リモート コンピューターを保護するには、コマンドレットの MaximumReceivedDataSizePerCommand MB (メガバイト) パラメーターと MaximumReceivedObjectSize MB (メガバイト) パラメーターを使用して、セッション構成に制限を
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 リモート処理」を参照してください。
関連項目
PowerShell