PowerShell Remoting(WinRM)入門 ── 複数台のWindowsを一括管理する

「Windows Updateのあと、サーバー20台の起動状態を確認したい」「全拠点のPCで、同じ設定値を調べたい」。リモートデスクトップで1台ずつログインすると、1台3分でも20台で1時間かかり、確認漏れも起こり得ます。

PowerShell Remotingは、こうした複数台への同じ作業を、まとめて実行する仕組みです。Windowsでは標準搭載のWinRMを土台にし、Windows Serverでは既定で有効になっています。ただし、接続先の準備、認証、実行するコマンドの権限は、分けて確認する必要があります。¹²

本記事は、中小企業の情シス・運用担当者に向けて、接続の準備 → 読み取りによる一括管理 → つながらないときの調査 → 安全な運用という流れで説明します。ワークグループの認証や、接続先からさらに別サーバーへ進むsecond hopも、最初の接続とは分けて扱います。

状況・目的から読む

最初は読み取り系の処理を1台で確認します。 接続設定の変更と、接続後の業務データ・サービスの変更は別です。変更系のコマンドを一括実行する前には、8章の安全運用も確認してください。

前提とする環境

• 接続される側: Windows Server 2012以降のWindows Serverでは、PowerShell Remotingは既定で有効です。² クライアント版のWindowsではWinRMサービスが既定で無効なので、Enable-PSRemotingでの有効化が必要です。²
• 接続する側: この記事のコマンド例は、Windows PowerShell 5.1とPowerShell 7のどちらにも存在するコマンドレットだけで書いています。ただしWSMan:ドライブやTest-WSManなどのWS-Management関連コマンドレットはWindows上のPowerShellでのみ使えます(Linux・macOSのPowerShellでは第6章のSSHベースRemotingを使います)。³
• 権限: リモート側の設定変更(Enable-PSRemoting、TrustedHosts、リスナー)は、いずれも管理者として起動したPowerShellが必要です。²
• ネットワーク: ドメイン環境とワークグループ環境の両方を扱います。違いは第3章にまとめました。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全24件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

1. まず結論

接続の土台・認証・権限を分ける

• PowerShell RemotingはWinRM(WS-Management実装)の上で動き、既定でHTTP 5985 / HTTPS 5986ポートを使います。HTTPでも通信内容は認証プロトコルによるメッセージレベル暗号化がかかります。¹
• 接続できるのは既定でリモート側Administratorsグループのメンバーだけで、セッションは接続ユーザーのコンテキストで動きます。「Remotingを有効にしたら誰でも入れる」わけではありません。¹
• Enable-PSRemotingがやることは明確に定義されています。WinRMサービスの開始と自動起動化、リスナー作成、ファイアウォール例外、セッション構成の有効化です。Windows Serverでは既定で有効、クライアントWindowsでは手動で有効化します。⁴¹
• ドメイン環境はKerberosでそのまま動き、ワークグループはNTLM + TrustedHosts + 明示的な資格情報が必要です。TrustedHostsは「相手を信頼する」設定ではなく「相手の身元確認を諦めるリスト」なので、最小限に絞ります。⁵¹

実行方法と、値・資格情報の渡り方を分ける

• 一括実行はInvoke-Command、対話操作はEnter-PSSession、状態を保って何度も使うならNew-PSSessionです。Invoke-Commandは既定で同時32台まで並列に処理します。⁶⁷
• リモートから返ってくるのはデシリアライズされたオブジェクトで、メソッドがありません。操作はScriptBlockの中(リモート側)で完結させ、手元では結果の集計だけを行います。⁸⁷
• 接続先からさらに別のサーバーへはアクセスできません(second hop問題)。これは欠陥ではなく、資格情報をリモートへ送らない安全設計の帰結です。対処方法は複数あり、要件で選びます。⁹
• PowerShell 7ではSSHベースのRemotingも使えます。Linuxとの相互管理が必要な場合や、WinRMを開けたくない環境の選択肢になります。³

2. 仕組み ── WinRMの上で、誰が、どう入るのか

2.1. 通信を暗号化することと、接続を許可することは別

PowerShell Remotingの土台はWinRM(Windows Remote Management)です。WinRMは標準プロトコルWS-ManagementのMicrosoft実装で、PowerShell RemotingはこのWinRM経由でリモートコンピューター上のPowerShellにコマンドを届けます。¹ 通信は既定でHTTP 5985番、HTTPS 5986番ポートを使います。¹⁵

「HTTPで平文なのでは」と心配されますが、初回認証の完了後はWinRMが通信を暗号化します。HTTPSではTLS、HTTPでは認証プロトコルがネゴシエートしたメッセージレベル暗号化(Kerberosなら現代の環境でAES-256)です。¹ また、接続できるのは既定でリモート側のAdministratorsグループのメンバーだけで、セッションは接続したユーザーのコンテキストで実行されるため、ファイルやレジストリへのアクセス制御は普段どおり適用されます。¹

2.2. 接続される側を準備し、接続する側から確かめる

受け側の準備はEnable-PSRemotingです。このコマンドレットが何をするかは公式に列挙されています。内部でSet-WSManQuickConfigを実行し、(1)WinRMサービスの開始、(2)スタートアップ種別の自動化、(3)任意のIPアドレスで受けるリスナーの作成、(4)WS-Management通信のファイアウォール例外の有効化、(5)セッション構成(エンドポイント)の作成・有効化とリモートアクセス許可、を行ったうえでWinRMサービスを再起動します。⁴

次の2つは実行するPCが違います。 Enable-PSRemotingは接続される側、Test-WSManは接続する側で実行します。後者が成功しても、認証と実行権限の確認は残ります。詳しくは7章で切り分けます。

# 接続「される」側で、管理者権限のPowerShellから1回だけ実行する
# (Windows Serverでは既定で有効なので通常は不要。クライアントWindowsで必要)
Enable-PSRemoting

# 接続「する」側からの疎通確認 ── これが通ればRemotingの土台はできている
Test-WSMan -ComputerName sv-app01

2.3. パブリックネットワークでは、Windowsの種類で挙動が違う

まず、ファイアウォールの条件を確認します。サーバー版WindowsではEnable-PSRemotingがパブリックネットワーク向けにも「同一サブネットからのみ許可」の規則を作りますが、クライアント版ではネットワークプロファイルがパブリックだと有効化自体がエラーになります(検証機を社内Wi-Fiにつないだときの定番トラブルです)。この場合は-SkipNetworkProfileCheckを付けるか、プロファイルをプライベートに直します。⁴

2.4. 手元のPowerShellと、接続先で動くPowerShellを確認する

次に、PowerShellのバージョンとエンドポイントの関係です。Enable-PSRemotingは「実行したPowerShellのバージョン用」のエンドポイントを構成します。PowerShell 7で実行してもWindows PowerShell 5.1のエンドポイントには影響せず、逆も同様です。⁴ しかもPowerShell 7から接続しても、既定ではWindows PowerShell 5.1の既存エンドポイント(Microsoft.PowerShell)が使われるため¹⁰、「手元は7なのに、リモートで動いているのは5.1だった」はごく普通に起きます。リモート側で$PSVersionTableを表示して確認する癖をつけてください。

3. ドメインとワークグループ ── 認証の壁はここにある

Remotingの入門でつまずく最大のポイントは、コマンドの文法ではなく認証です。環境によって必要な準備が変わります。

コンピューター名で接続する場合の基本形

ドメイン環境ならKerberosによる相互認証(クライアントもサーバーも互いを検証)が働くため、Invoke-Command -ComputerName sv-app01 { ... } がそのまま通ります。ワークグループではKerberosが使えないため⁵、接続側のTrustedHostsに相手を登録します。

# 接続「する」側で、管理者として起動したPowerShellから実行(ワークグループのみ必要)
# TrustedHostsの変更にも管理者権限が要る。既存の値は上書きされるので、まず現在値を確認する
Get-Item WSMan:\localhost\Client\TrustedHosts

# 必要最小限のホスト名だけを追記する。-Concatenateなしだと既存の登録が消える。'*'での全許可は避ける
Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'sv-app01,sv-app02' -Concatenate

# 資格情報を明示して接続テスト
$cred = Get-Credential sv-app01\Administrator
Invoke-Command -ComputerName sv-app01 -Credential $cred -ScriptBlock { hostname }

TrustedHostsは、接続先の身元を保証するものではない

ここで重要なのがTrustedHostsの意味です。公式ドキュメントは「TrustedHostsに載せたコンピューターは認証されず、クライアントが資格情報を送ってしまう可能性がある」と明記しています。⁵ つまりこれは「信頼できる相手のリスト」というより、「サーバーの身元を検証できないという警告を抑止するリスト」です。¹ DNSやARPを細工された環境では、偽サーバーに管理者資格情報を渡すリスクがあります。だからワイルドカード登録を避け、固定のホスト名・IPを最小限だけ載せる。本格運用するワークグループ環境やDMZでは、証明書を用意してHTTPS(5986)リスナーを構成する方が筋が良い、というのが実務の判断です。¹

資格情報の保存方法と、空パスワードにも注意する

なお、Get-Credentialで受け取った資格情報をスクリプトに平文で書き始めたら黄信号です。資格情報の保存と受け渡しの定石は、同時公開の「PowerShellで資格情報を安全に扱う」にまとめています。

ワークグループでもうひとつ見落としやすいのがパスワードの有無です。接続先のアカウントにパスワードが設定されていない(空パスワード)場合、リモートコマンドは実行できません。²

3.1. HTTPS(5986)リスナーを構成する

ワークグループやDMZで常用するなら、TrustedHostsで済ませずHTTPSリスナーを立てます。手順の骨子はこうです。¹²

接続される側: 証明書からリスナー・ファイアウォールへ

1. サーバー認証用の証明書を用意する。要件は「ローカルコンピューターのサーバー認証証明書であること」「CN(またはサブジェクト代替名)がホスト名と一致すること」「有効期限内で、失効しておらず、自己署名でないこと」です。社内CAがあればhttps://<証明機関のサーバー>/certsrvのWeb登録から要求できます。
2. 証明書をローカルコンピューターの個人ストアに入れる。確認は証明書スナップイン(MMCで「証明書」を追加し、ウィザードで「コンピューター アカウント」を選ぶ)の 証明書(ローカル コンピューター) > 個人 > 証明書 です。

3. HTTPSリスナーを作る。手軽なのは次の1行です。

    winrm quickconfig -transport:https
   

   証明書が複数あってどれを使うか明示したい場合は、PowerShellから拇印を指定して作ることもできます(拇印はGet-ChildItem Cert:\LocalMachine\Myで確認できます)。

    New-Item -Path WSMan:\localhost\Listener -Address * -Transport HTTPS -CertificateThumbPrint '証明書の拇印' -Force
   

4. ファイアウォールでTCP 5986の受信を許可する。Enable-PSRemotingが作る規則はHTTP(5985)向けなので、HTTPSは別途必要です。

5. リスナーができたか確認する。

    winrm enumerate winrm/config/listener
   

接続する側: HTTPSを指定して接続する

接続する側は-UseSSLを付けるだけです。

Invoke-Command -ComputerName sv-app01.example.local -UseSSL -Credential $cred -ScriptBlock { hostname }

リスナーを作れないときは、証明書の条件へ戻る

証明書の条件を満たしていないと、リスナー作成時に「Cannot create a WinRM listener on HTTPS because this machine does not have an appropriate certificate.(エラー番号 -2144108267 / 0x80338115)」というエラーになります。この場合は証明書の有効期限、発行先がホスト名と一致しているか、拡張キー使用法に「サーバー認証」が含まれているか、証明のパスが有効かを順に確認します。¹²

4. Invoke-Command ── 「20台に同じことをする」の基本形

まず、読み取り結果をサーバー名付きで集める

Remotingの主役はInvoke-Commandです。-ComputerNameに複数台を渡し、-ScriptBlockに「リモートでやること」を書きます。⁶ まずは読み取り専用の棚卸しから始めるのが安全運用の鉄則です。

$servers = 'sv-app01', 'sv-app02', 'sv-db01'

# パッチ適用後の状態確認 ── 読み取りだけなので安心して流せる
$result = Invoke-Command -ComputerName $servers -ScriptBlock {
    # このブロックの中は「リモート側」で実行される
    $os = Get-CimInstance Win32_OperatingSystem
    [PSCustomObject]@{
        LastBoot   = $os.LastBootUpTime                      # 再起動が済んだか
        SpoolerRun = (Get-Service -Name Spooler).Status      # 業務に必要なサービスの状態
        FreeGB     = [math]::Round((Get-PSDrive C).Free / 1GB, 1)
    }
}

# どの結果がどのサーバーのものかはPSComputerNameで分かる
$result | Sort-Object PSComputerName |
    Select-Object PSComputerName, LastBoot, SpoolerRun, FreeGB |
    Export-Csv -Path .\patch-check.csv -NoTypeInformation -Encoding UTF8

結果の順番ではなく、PSComputerNameで接続先を区別する

各サーバーへの接続は並列に処理され、既定の同時実行数(ThrottleLimit)は32です。⁷ 結果は届いた順に混ざって返るため、上の例のように自動付与されるPSComputerNameプロパティで並べ直します。⁸

4.1. 変数の渡し方 ── $using: と -ArgumentList

ScriptBlockはリモートで実行されるので、手元の変数はそのままでは見えません。値を持ち込む方法は2つあります。¹³

$threshold = (Get-Date).AddDays(-30)

# 方法1: $using: ── 呼び出し側の変数の「値のコピー」をリモートに埋め込む
Invoke-Command -ComputerName $servers -ScriptBlock {
    (Get-ChildItem 'D:\AppLogs' -Filter *.log |
        Where-Object LastWriteTime -lt $using:threshold).Count
}

# 方法2: -ArgumentList ── ScriptBlock側のparamで受け取る(引数が多いときに読みやすい)
Invoke-Command -ComputerName $servers -ScriptBlock {
    param($limit)
    (Get-ChildItem 'D:\AppLogs' -Filter *.log |
        Where-Object LastWriteTime -lt $limit).Count
} -ArgumentList $threshold

$using:で渡る値はリモート側では独立したコピーです。リモート側で書き換えても手元の変数は変わりません。¹³

4.2. 返ってくるのは「スナップショット」── デシリアライズされたオブジェクト

Remotingの結果で最初に戸惑うのがこれです。生きた.NETオブジェクトはネットワークを越えられないため、リモートの出力はXML(CLIXML)にシリアライズされて送られ、手元でデシリアライズされたオブジェクトに復元されます。これは実行時点のプロパティのスナップショットで、メソッドを持ちません。⁸⁷

操作はリモート側で行い、手元では報告用に加工する

たとえばGet-Serviceの結果をローカルで受けて.Stop()を呼ぶことはできません。サービスを止めたいなら、ScriptBlockの中でStop-Serviceを実行する── つまり操作はリモート側で完結させ、手元に持ち帰るのは報告用のデータだけ、と役割を分けるのが正しい形です。プロパティの選別・整形・CSV化といった手元での加工は普段のPowerShellと同じ感覚で行えます(このあたりの基本操作は「PowerShellコマンドの基本」を参照してください)。

5. Enter-PSSessionとNew-PSSession ── 対話と使い回し

5.1. 1台を対話的に調べる: Enter-PSSession

1台を対話的に調べたいときはEnter-PSSessionです。プロンプトが[sv-app01]: PS>に変わり、入力したコマンドがリモートで実行されます。exitで抜けます。¹¹ リモートデスクトップと違って画面は持ち込まれませんが、「ログを見る」「設定を確認する」程度ならこちらの方が速く、接続にもAdministratorsグループのメンバーであることが必要なのは同じです。¹¹

5.2. 状態を保って繰り返し調べる: New-PSSession

一方、Invoke-Commandを-ComputerNameで呼ぶたびに、接続の確立と破棄が毎回行われます。¹⁴ 同じサーバー群に何度もコマンドを投げる調査作業では、New-PSSessionで持続的なセッションを作って使い回すと速く、しかもリモート側の変数や状態がコマンド間で保持されます。¹⁴¹⁵

セッションを使い終わったら、finallyで片付ける

# セッションを一度だけ張り、変数$sで使い回す
$s = New-PSSession -ComputerName $servers
try {
    # 1回目: リモート側に$hotfixという変数を作る
    Invoke-Command -Session $s { $hotfix = Get-HotFix | Sort-Object InstalledOn -Descending }

    # 2回目: 前のコマンドで作った変数がそのまま使える(セッションが状態を保持している)
    Invoke-Command -Session $s { $hotfix | Select-Object -First 5 }
}
finally {
    # 途中でエラーや中断があっても必ず破棄する(リモート側のリソースを解放する)
    Remove-PSSession $s
}

6. 落とし穴 ── second hop、そしてSSHという選択肢

6.1. second hop(ダブルホップ)問題

A→Bにつながっても、B→Cの認証は別に必要

現場で最も有名な壁がこれです。手元のPC(A)からサーバーBにRemotingで入り、Bの中から\\fs01\share(サーバーC)を読もうとするとアクセス拒否になります。既定のKerberos/NTLM認証は資格情報そのものをBへ送らずに認証する安全な方式のため、Bはあなたの代理としてCへ認証できないのです。¹⁹

先に、中継をなくせないか考える

そもそも「Bを経由してCのファイルを読む」のではなく、手元からC相手に直接Invoke-Commandする構成にできないかを先に考えるのが、いちばん安い解決策です。

中継が必要なら、資格情報と権限の扱いで方法を選ぶ

対処は複数あり、公式ドキュメントが推奨順に整理しています。⁹ 主なものだけ挙げると次のとおりです。

• ScriptBlock内で資格情報を明示的に渡す ── サーバー側の構成変更が不要で最も手軽。$using:credで内側のInvoke-Commandに資格情報を渡します。⁹ ただし資格情報オブジェクトが中継サーバー(B)のセッションに渡る以上、Bが侵害されていれば渡した資格情報も使われうるため、Bを完全に信頼できる場合に限り、渡すアカウントもC側で必要最小限の権限を持つ専用アカウントにするのが前提です。
• リソースベースのKerberos制約付き委任 ── 資格情報を保存せず、アクセス先(C)側で「Bからの委任を受ける」と構成する方式。ドメイン管理者権限なしで構成でき、セキュリティと構成の簡単さのバランスが良い選択肢です。⁹
• JEA(Just Enough Administration) ── 「その業務に必要なコマンドだけ」を許可した専用のエンドポイントを用意し、権限を絞り込むPowerShellの仕組みです。仮想アカウントを使う構成にすれば、利用者は管理者以外の資格情報で接続しながら、許可された管理コマンドだけを実行できます。¹⁶ second hopの文脈では、中継サーバー(B)に管理者資格情報を配る代わりに、Cへのアクセスを含む定型作業だけを実行できる窓口を作る、という使い方になります。⁹
• CredSSP ── 資格情報がリモートサーバーにキャッシュされるため、そのサーバーが侵害されると資格情報ごと盗まれます。既定で無効であり、有効化は最も信頼できる環境に限定すべきです。⁹

掲載例は、BからCへ新しいRemoting接続を作る

# 最も手軽な回避: 内側のInvoke-Commandに$using:credで資格情報を渡す
# 外側(sv-app01)へは自分自身の資格情報で接続し、内側に渡すのはfs01側で
# 必要最小限の権限を持つ専用アカウントだけにする(管理者の資格情報を配らない)
#
# 【前提】内側の呼び出しは「sv-app01からfs01への新しいRemoting接続」なので、次が要る:
#   1. sv-app01からfs01へWinRM(5985/5986)が到達できること
#   2. ワークグループやIPアドレス指定なら、sv-app01側のTrustedHostsにfs01が登録済みであること
#   3. $credがfs01で有効なアカウント(ドメインアカウント、またはfs01のローカルアカウント)であること
# これらを確認せずにコピペすると「手元では動くのに中継サーバーからは失敗する」になりがち
$cred = Get-Credential CONTOSO\svc-fileread
Invoke-Command -ComputerName sv-app01 -ScriptBlock {
    Invoke-Command -ComputerName fs01 -Credential $using:cred -ScriptBlock { hostname }
}

6.2. PowerShell 7ならSSHベースのRemotingも選べる

PowerShell 6.0以降は、WinRMの代わりにSSHで接続するRemotingが使えます。Invoke-Command / Enter-PSSession / New-PSSessionに-HostName、-UserName、-KeyFilePathというSSH用のパラメーターセットが追加されており、WindowsとLinuxをまたいだ管理ができます。³ 接続先にはSSHサーバーとPowerShellのSSHサブシステム構成が必要で、WinRMベースにあるエンドポイント構成やJEAのような機能は現状サポートされません。³ Linuxサーバーが混在する環境や、鍵認証で運用を統一したい場合の選択肢として覚えておくとよいでしょう。Windows PowerShell 5.1にはこの機能はないので、必要なら移行の動機になります(違いの全体像は同時公開の「Windows PowerShell 5.1とPowerShell 7の違い」を参照)。

Remotingは、RDPのデスクトップ操作とは別の仕組み

ちなみに、RemotingのセッションはRDPのようなデスクトップセッションを作りません。「リモートで動く」という意味が両者でどう違うかは「Windowsのセッション分離をどう理解するか」で整理しています。

7. つながらないときの切り分け

入門者がRemotingを諦める理由の大半は「つながらない」です。しかも失敗の原因は、サービス・リスナー・ファイアウォール・認証・権限のどこにでもありえます。上流から順に潰していくと迷いません。

7.1. 切り分けの順番

以下の8ステップは、次の3つに分けると追いやすくなります。途中で設定を変える前に、どの段階で止まっているかを確かめます。

1. 疎通を見る。まず接続する側からTest-WSMan -ComputerName sv-app01。ここが通れば、WinRMサービス・リスナー・ファイアウォールまでは生きています(認証や権限の問題は残ります)。通らなければ以下へ。
2. リモート側でWinRMサービスが動いているか。サーバー版はスタートアップ種別が自動ですが、クライアント版のWindowsではWinRMサービスが既定で無効です。² Get-Service WinRMで確認し、必要ならEnable-PSRemoting(サービス起動・自動起動化・リスナー・ファイアウォール例外・セッション構成をまとめて構成)を実行します。⁴

3. リスナーが待ち受けているか。リモート側で次を実行し、ListeningOnが空でないかを見ます。空の場合は、グループポリシーでリスナーを配っている環境での設定ミスが定番です。²

    Get-WSManInstance winrm/config/listener -Enumerate
   

4. ネットワークプロファイルを見る。クライアント版でネットワークがパブリックだと、Enable-PSRemoting自体が「Unable to check the status of the firewall」で失敗します。プロファイルをプライベートに直すか、-SkipNetworkProfileCheckを付けます。²
5. ファイアウォール規則を見る。サーバー版でもパブリックプロファイルでは「同一サブネットからのみ許可」の規則になります。別サブネットから入るなら規則の見直しが要ります(Get-NetFirewallRuleで規則名を確認してから変更してください。規則名はWindowsのバージョンで異なります)。²
6. 認証方式の条件を満たしているか。ワークグループ、非ドメイン参加、IPアドレス指定の場合はKerberosが使えずNTLMになるため、TrustedHostsへの登録(またはHTTPS)と-Credentialの明示指定が必須です。接続先アカウントに空パスワードは使えません。²
7. 接続できる権限があるか。既定のエンドポイントに接続できるのはリモート側Administratorsのメンバーだけです。別ドメインのユーザーやローカルアカウントは、既定では標準ユーザーのトークンになるため、管理者として振る舞えません(必要ならLocalAccountTokenFilterPolicyですが、UACのリモート制限を全ユーザーに対して無効化する設定なので影響を理解したうえで)。²
8. エンドポイントのPowerShellバージョンを確認する。つながったのに「そのコマンドレットがない」と言われるときは、第2章のとおりWindows PowerShell 5.1側のエンドポイントに入っている可能性があります。Invoke-Command -ComputerName sv-app01 { $PSVersionTable.PSVersion }で確かめ、必要なら-ConfigurationNameで明示します。¹⁰

7.2. 代表的なエラーメッセージの読み方

エラー文はほぼ定型なので、覚えるというより「この文言ならここを見る」と対応づけておくのが実用的です。²

切り分けのコツは、「手元の問題か、経路の問題か、相手の問題か」を1つずつ確定させることです。Test-WSManが通るかどうかで経路と相手のサービスまでを切り分け、通ったあとのエラーは認証と権限の話に絞る。この2段構えにすると、原因不明のまま設定をいじり回すことがなくなります。

8. 実務の定石(判断表)

変更系は、1台で確認してから範囲を広げる

最後の行は強調しておきます。Invoke-Commandは「20台を一瞬で直すコマンド」であると同時に「20台を一瞬で壊すコマンド」です。幸い、Stop-ServiceやSet-ItemPropertyのような変更系コマンドレットの多くは-WhatIfに対応しており、ScriptBlockの中でもそのまま使えます。新しいスクリプトはまず1台に、次に-WhatIf付きで全台に、最後に本実行という三段階を習慣にすると、事故率が目に見えて下がります。

9. まとめ

• RemotingはWinRM(WS-Management)上で動き、既定ポートはHTTP 5985 / HTTPS 5986。接続できるのは既定でリモート側Administratorsのメンバーだけで、通信は認証後に暗号化されます。
• Enable-PSRemotingはWinRMサービス起動・リスナー作成・ファイアウォール例外・セッション構成有効化を行います。実行したPowerShellのバージョン用のエンドポイントが構成される点に注意してください。
• ドメインはKerberosでそのまま、ワークグループはTrustedHosts + 明示的資格情報。TrustedHostsは身元検証の放棄リストなので最小限に。
• 一括実行はInvoke-Command(既定32並列)、対話はEnter-PSSession、状態を保つならNew-PSSessionの再利用。結果はメソッドを持たないデシリアライズ済みオブジェクトなので、操作はリモート側で完結させます。
• 接続先からさらに先へは届きません(second hop)。まず資格情報の明示渡し、恒常運用ならリソースベースのKerberos制約付き委任を検討します。
• 「つながらない」ときは、Test-WSManで経路と相手のサービスまでを切り分けてから、認証(TrustedHosts・資格情報)と権限(Administrators)に絞って見ます。代表的なエラー文と対応先は第7章の表にまとめました。
• 運用はまず読み取り系から。変更系は1台 → -WhatIf → 本実行の三段階で。ファイルサーバーの棚卸しに応用する具体例は同時公開の「PowerShellでファイルサーバーを棚卸しする」をどうぞ。

関連記事

• PowerShellコマンドの基本 ── まず覚える操作と安全な使い方
• PowerShell実用コマンド集 ── 日常作業でよく使う小さな機能を増やす
• PowerShellでファイルサーバーを棚卸しする ── 容量調査とアクセス権(ACL)監査
• PowerShellで資格情報を安全に扱う
• Windowsのセッション分離をどう理解するか ── Session 0・RDP・複数ユーザー同時実行
• Windowsの偽装トークンを正しく扱う ── スレッド単位の権限借用と安全な戻し方

関連する相談領域

合同会社小村ソフトでは、PowerShellによるサーバー・クライアントの一括管理の仕組みづくり、Remotingを組み込んだ運用スクリプトの設計・レビュー、「つながらない」「特定環境でだけ認証に失敗する」といったWinRM/認証まわりの調査を扱っています。

• 技術相談・設計レビュー
• 不具合調査・原因解析
• Windowsアプリ開発
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Enable-PSRemotingを実行すると何が起きますか？

内部でSet-WSManQuickConfigが実行され、WinRMサービスの開始とスタートアップの自動化、任意のIPアドレスで要求を受けるリスナーの作成、WS-Management通信のファイアウォール例外の有効化、セッション構成(エンドポイント)の有効化とリモートアクセス許可への変更が行われます。Windows Serverでは既定で有効ですが、クライアントWindowsでは自分で実行する必要があります。接続を受ける側だけに必要で、接続する側では実行不要です。

ワークグループ環境(ドメインなし)でPowerShell Remotingを使うには何が必要ですか？

ドメインがないとKerberos認証が使えないため、NTLM認証になります。接続する側で接続先をWSManのTrustedHostsリストに登録し、-Credentialで資格情報を明示的に渡すのが基本形です。ただしTrustedHostsに載せた相手は認証(なりすまし検証)されないまま資格情報が送られる可能性があるため、ワイルドカードではなく必要最小限のホスト名だけを登録し、可能ならHTTPS(5986)リスナーの構成を検討してください。

Invoke-Commandの結果オブジェクトでメソッドが呼べないのはなぜですか？

リモートコマンドの出力はネットワーク越しに送るためにXML(CLIXML)へシリアライズされ、手元ではデシリアライズされたオブジェクトとして復元されるからです。これは実行時点のプロパティのスナップショットであり、生きたオブジェクトではないためメソッドを持ちません。サービスの停止のような操作はローカル側でメソッドを呼ぶのではなく、ScriptBlockの中(リモート側)で実行する必要があります。

second hop(ダブルホップ)問題とは何ですか？

PC AからサーバーBにRemotingで入り、Bからさらに別のサーバーC(ファイルサーバーなど)へアクセスしようとすると拒否される問題です。既定のKerberos/NTLM認証は資格情報そのものをBへ送らないため、BはあなたとしてCへ認証できません。対処には、ScriptBlock内で資格情報を明示的に渡す方法、リソースベースのKerberos制約付き委任、CredSSP(資格情報がリモート側に渡るためリスク増)などがあり、要件に応じて選びます。

PowerShell Remotingには誰でも接続できてしまうのですか？

いいえ。既定ではリモートコンピューターのAdministratorsグループのメンバーだけが接続できます。また、接続後のセッションは接続したユーザーのコンテキストで動くため、OSのアクセス制御はそのまま適用されます。とはいえ管理者にとっては強力な入口なので、ファイアウォール規則の見直し、HTTPSリスナー、必要な管理者だけへの限定といった多層の防御と組み合わせて運用してください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。