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

「Windows Updateのあと、サーバー20台が全部ちゃんと起動しているか見てきて」「全拠点のPCで、あの設定値がどうなっているか調べてほしい」── この手の依頼を、リモートデスクトップで1台ずつログインして確認していないでしょうか。1台3分でも20台で1時間。人間は途中で飽きますし、確認漏れも起きます。

PowerShell Remotingは、この「複数台への同じ作業」をコマンド1発に変える仕組みです。WindowsにはWinRMというリモート管理の土台が標準搭載されており、Windows Serverでは既定で有効になっています。つまり多くの現場では、追加ソフトなしで今日から使えます。にもかかわらず「なんとなく怖い」「ワークグループでつながらなかったので諦めた」という声をよく聞きます。

この記事では、中小企業の情シスや運用担当者を対象に、Remotingの仕組み(何がどのポートで動き、誰が接続できるのか)から、Invoke-Commandによる一括実行、ドメイン環境とワークグループ環境の違い、second hop問題のような有名な落とし穴、そして「読み取りから始める」安全運用までを整理します。

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の上で、誰が、どう入るのか

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グループのメンバーだけで、セッションは接続したユーザーのコンテキストで実行されるため、ファイルやレジストリへのアクセス制御は普段どおり適用されます。¹

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

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

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

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

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

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

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

各サーバーへの接続は並列に処理され、既定の同時実行数(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 ── 対話と使い回し

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

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

# セッションを一度だけ張り、変数$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(ダブルホップ)問題

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

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

• ScriptBlock内で資格情報を明示的に渡す ── サーバー側の構成変更が不要で最も手軽。$using:credで内側のInvoke-Commandに資格情報を渡します。⁷ ただし資格情報オブジェクトが中継サーバー(B)のセッションに渡る以上、Bが侵害されていれば渡した資格情報も使われうるため、Bを完全に信頼できる場合に限り、渡すアカウントもC側で必要最小限の権限を持つ専用アカウントにするのが前提です。
• リソースベースのKerberos制約付き委任 ── 資格情報を保存せず、アクセス先(C)側で「Bからの委任を受ける」と構成する方式。ドメイン管理者権限なしで構成でき、セキュリティと構成の簡単さのバランスが良い選択肢です。⁷
• CredSSP ── 資格情報がリモートサーバーにキャッシュされるため、そのサーバーが侵害されると資格情報ごと盗まれます。既定で無効であり、有効化は最も信頼できる環境に限定すべきです。⁷

# 最も手軽な回避: 内側のInvoke-Commandに$using:credで資格情報を渡す
# 外側(sv-app01)へは自分自身の資格情報で接続し、内側に渡すのはfs01側で
# 必要最小限の権限を持つ専用アカウントだけにする(管理者の資格情報を配らない)
$cred = Get-Credential CONTOSO\svc-fileread
Invoke-Command -ComputerName sv-app01 -ScriptBlock {
    Invoke-Command -ComputerName fs01 -Credential $using:cred -ScriptBlock { hostname }
}

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

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のようなデスクトップセッションを作りません。「リモートで動く」という意味が両者でどう違うかは「Windowsのセッション分離をどう理解するか」で整理しています。

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

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

8. まとめ

• 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制約付き委任を検討します。
• 運用はまず読み取り系から。変更系は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 ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。