Hyper-V 上の Nano Server で EMS（Emergency Management Services）を有効化すると、GUI がない環境でもシリアル経由で起動直後からトラブルシュートできます。ただし COM1 を名前付きパイプに割り当て、Windows 10 ホストから PuTTY（Serial）で開こうとすると「Unable to open serial port」で接続できないことがあります。原因と対処を具体的に整理します。
発生する症状：PuTTY で「Unable to open serial port」になり、名前付きパイプを開けない
今回の前提は次のような構成です。
| 項目 | 内容（例） | ポイント |
|---|---|---|
| 仮想化基盤 | Windows 10 上の Hyper-V | ホスト側から PuTTY を起動して接続する |
| ゲスト OS | Nano Server VM | 基本的に GUI がなく、障害時にコンソールが欲しい |
| 目的 | EMS（Emergency Management Services）を有効化 | シリアル（SAC）から復旧・確認できるようにする |
| COM1 の割り当て | 名前付きパイプ：\\.\pipe\web01 | ホストの PuTTY からこのパイプへ接続したい |
この状態で PuTTY の接続タイプを Serial にして、Serial line に \\.\pipe\web01 を入れて接続すると、次のようなエラーで止まります。
- Unable to open connection to \\.\pipe\web01
- Unable to open serial port
見た目は「シリアル設定が違うのかな？」と感じやすいのですが、実際には 名前付きパイプへのアクセス権（権限）が原因になっているケースが多いです。
結論：PuTTY を管理者権限で実行すると接続できる可能性が高い
最優先で試すべき対処はこれです。
対処：PuTTY（putty.exe）を「管理者として実行」し、同じ設定で再接続する。
Hyper-V が作る名前付きパイプは、状況によっては 管理者権限（昇格トークン）がないと開けない ACL になっていることがあります。通常権限の PuTTY からは内部的に「アクセス拒否」になり、PuTTY 側には “serial port を開けない” という形で返ってきます。
手順（GUI）：PuTTY を「管理者として実行」して接続する
- PuTTY を終了していることを確認します（起動中なら閉じる）。
- スタートメニューや putty.exe を右クリックし、「管理者として実行」を選びます。
- PuTTY の Session で Connection type: Serial を選びます。
- Serial line に
\\.\pipe\web01、Speed に115200を入力します。 - Open を押して接続します。
これだけで繋がる場合は、ほぼ「権限が原因」だったと判断してよいです。
手順（コマンドライン）：管理者で PuTTY を起動して一発接続
運用で何度も接続する場合は、ショートカットやコマンドライン起動が便利です。PuTTY はオプションでシリアル指定ができます。
putty.exe -serial \\.\pipe\web01 -sercfg 115200,8,n,1,N※最後の N はフロー制御（None）を意味します。環境によっては設定画面から保存しておく方が確実です。
そもそも EMS と「名前付きシリアル パイプ」で何ができるのか
EMS（Emergency Management Services）は、Windows が提供するシリアル経由の緊急管理機能です。サーバーがネットワークに出られない、GUI がない、リモート管理が効かないといった状況でも、起動直後からコンソールで状態確認ができます。
物理サーバーでは実際のシリアルポートを使うことが多いですが、Hyper-V では COM ポートを名前付きパイプに接続できます。つまり、ホスト側のアプリ（PuTTY など）を「シリアル端末」として使い、ゲストの EMS/SAC コンソールへ入れるわけです。
設定の全体像：Hyper-V（COM1）とゲスト（EMS）の両方が揃って初めて動く
「パイプを開けない」問題は PuTTY 側に出ますが、接続に必要な要素は大きく分けて 2 つです。
| 層 | 設定する場所 | 要点 |
|---|---|---|
| 仮想ハードウェア | Hyper-V の VM 設定（COM1） | COM1 を「名前付きパイプ」にし、パイプ名と方向を正しくする |
| OS（起動設定） | Nano Server の BCD（bcdedit） | EMS を有効化し、ポートとボーレートを合わせる |
どちらか片方が欠けると、接続自体はできても画面が何も出ない、または接続すらできないといった状況になります。この記事では、特に「接続すらできない」側の原因を優先して潰していきます。
Hyper-V 側の確認ポイント：COM1 の「名前付きパイプ」と方向
Hyper-V マネージャーで VM の設定を開き、COM1 を確認します。ここが少しでもズレていると、PuTTY は正しく接続できません。
| 設定項目 | 推奨（PuTTY から接続する場合） | よくあるミス |
|---|---|---|
| 接続先 | 名前付きパイプ | 「物理 COM ポート」になっている |
| パイプ名 | \\.\pipe\web01（完全一致） | \\.\pipe\web01 の綴り違い、余計な空白、別名 |
| このエンドは | サーバー | クライアントになっていて、外部アプリが接続先を作れない |
| 相手のエンドは | クライアント | 設定の意図が逆転している |
ポイントは方向です。PuTTY は基本的に 「既に存在する名前付きパイプへクライアントとして接続」する動きになります。そのため、Hyper-V 側は「このエンドはサーバー」にして、パイプ（例：\\.\pipe\web01）を作って待ち受ける構成が分かりやすく、失敗しにくいです。
パイプが作られているかをホストで確認する
VM を起動した状態で、ホスト側からパイプの存在を確認すると切り分けが楽になります。
dir \\.\pipe\PowerShell なら次の方法でも確認できます。
Get-ChildItem \\.\pipe\ | Where-Object Name -like '*web01*'ここで web01 が見えない場合は、Hyper-V 側の COM1 設定が反映されていない、VM が停止している、方向が逆でパイプが作られていない、といった可能性が上がります。
PuTTY 側の推奨設定：まずは「王道の 115200 / フロー制御なし」から
シリアルのパラメータが違っても「開けない」にはなりにくいのですが、接続後に文字化けしたり、何も表示されない原因になります。EMS は一般的に 115200 bps が使われることが多いので、まずはこの値で合わせるのが無難です。
| PuTTY 設定 | 値（例） | 補足 |
|---|---|---|
| Connection type | Serial | SSH や Telnet ではなく Serial を選ぶ |
| Serial line | \\.\pipe\web01 | COM1 などではなく、名前付きパイプのパスを入れる |
| Speed (baud) | 115200 | ゲストの EMS 設定と揃える |
| Data bits / Stop bits | 8 / 1 | 標準設定のままでよいことが多い |
| Parity | None | 通常は None |
| Flow control | None | RTS/CTS にすると入力が止まることがある |
なぜ「管理者として実行」で直るのか：名前付きパイプの ACL と UAC の罠
名前付きパイプは Windows の IPC（プロセス間通信）機構で、ファイルに近い扱いでアクセス制御（ACL）がかかります。Hyper-V が作成するパイプは、作成元プロセス（VMWP など）側でセキュリティが設定されます。
ここでハマりやすいのが UAC です。たとえ「管理者グループ」に所属していても、通常起動のアプリは 非昇格トークンで動き、管理者権限が必要なオブジェクトにアクセスできないことがあります。PuTTY を昇格して起動すると、その差分でパイプを開けるようになり、エラーが消えるという流れです。
つまり、設定や配線が正しいのに開けないときは、まず「権限の問題では？」と疑い、管理者として実行を最初に試すのが効率的です。
それでも開けない場合の追加チェック：ありがちな落とし穴を一気に潰す
管理者で起動してもエラーが出る場合、次のポイントを上から順に確認すると原因に辿り着きやすいです。
| チェック項目 | 確認方法 | 典型症状 |
|---|---|---|
| パイプ名が完全一致しているか | Hyper-V の COM1 と PuTTY の Serial line を見比べる（コピペ推奨） | Unable to open connection / そもそもパイプが存在しない |
| 方向（サーバー/クライアント）が想定通りか | Hyper-V の COM1 で「このエンドはサーバー」になっているか確認 | VM は起動しているのに dir \\.\pipe\ にパイプが出ない |
| VM が起動しているか | Hyper-V マネージャーで状態確認 | 停止中は当然パイプが作られず、接続できない |
| 別プロセスが同じパイプを掴んでいないか | 同じ PC で別の端末ソフトを起動していないか確認 | 多重接続できない構成だと 2 台目で開けない |
| PuTTY を「Serial」で開いているか | Connection type が Serial になっているか | SSH などのままだと当然接続できない |
| セキュリティソフトやポリシーでブロックされていないか | 他の管理ツールも同様にブロックされるか切り分け | 管理者でも開けない、イベントログに拒否が出る |
ゲスト（Nano Server）側の確認：EMS が有効でないと「繋がっても何も出ない」
今回の本題は「開けない」ですが、権限問題を解消して接続できた後に画面が真っ黒のままで悩むことも多いので、最低限の確認ポイントもまとめます。
Nano Server 側で EMS が有効化されているかは、OS 内から bcdedit で確認できます（リモート PowerShell などで入れる前提）。代表的な設定例は次の通りです。
bcdedit /ems {current} on
bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200設定値は環境により異なる場合がありますが、重要なのは EMSPORT（COM 番号） と EMSBAUDRATE（速度） を Hyper-V / PuTTY と揃えることです。例えば Hyper-V 側で COM1 を使っているなら、EMSPORT も 1 を選ぶのが自然です。
なお、設定変更後は再起動が必要になることがあります。接続はできるが何も出ない場合は、VM を再起動して起動ログの段階から確認してみてください。
接続できたら何が見える？：SAC コンソールの目安
PuTTY が正しくつながると、ゲストの状態によっては起動メッセージの後に SAC（Special Administration Console）風のプロンプトが表示されます。環境によって表示は多少異なりますが、「SAC」や「channel」といった文言が出ていれば概ね成功です。
ここまで到達すれば、あとはネットワーク復旧前の緊急時でも最低限の操作ができます。たとえば、起動に失敗してリモート PowerShell が入れないとき、IP 設定が壊れていて WinRM が応答しないときなどに、状態確認の糸口になります。
運用のコツ：この問題を再発させないための実践ポイント
最後に、同じエラーで再び時間を溶かさないための小ワザ・設計ポイントをまとめます。
- パイプ名は VM 名と用途を含める：
\\.\pipe\nano-web01-emsのようにして衝突を防ぎます。 - PuTTY のセッションを保存する：Serial line や速度を固定し、入力ミスを減らします。
- 接続用のショートカットは「管理者として実行」に設定：毎回右クリックする手間と権限ミスを減らします。
- 方向（サーバー/クライアント）は方針を統一：「Hyper-V 側がサーバー」を標準にすると、端末側がシンプルです。
- 多重接続が必要なら設計段階で検討：1 本のパイプに 1 クライアントしかつながらない運用だと、切り分け時に詰まります。
まとめ：まずは権限を疑い、管理者 PuTTY で素早く復旧する
Hyper-V の名前付きシリアル パイプは、設定さえ決まれば Nano Server の EMS を非常に強力にしてくれます。一方で、エラーの見え方が「シリアルが開けない」なので、設定値ばかり追いかけてしまいがちです。
同じ症状に当たったら、最初に PuTTY を管理者として実行し、それでもダメなら パイプ名の完全一致と 方向（このエンドはサーバー）を重点的に確認する、という順番が最短ルートになります。
権限トラブルを減らす小技：PuTTY を「常に管理者」で起動できるようにする
原因が権限で確定した場合、毎回右クリックして昇格するのは地味に面倒です。運用で使うなら、次のどちらかで「管理者 PuTTY」を標準化すると再発が減ります。
| 方法 | 手順のイメージ | 向いているケース |
|---|---|---|
| ショートカットの互換性設定 | ショートカットのプロパティで「管理者としてこのプログラムを実行する」を有効 | 特定の端末 PC から頻繁に接続する |
| PowerShell で昇格起動 | Start-Process putty.exe -Verb RunAs | 運用手順書に「昇格して起動」を明記したい |
ただし、管理者での常用は最小限にし、必要なときだけ昇格する運用が理想です。特に共有 PC では、誤操作の影響範囲が大きくなるため注意してください。
「権限」以外で開けないときの補足：方向が逆だと PuTTY は接続先を作れない
もう一つ、現場で多いのが 方向の取り違えです。Hyper-V の COM ポート設定で「このエンドはクライアント」になっていると、Hyper-V は“どこかに存在するパイプへ接続しに行く側”になります。
この構成だと、ホスト側にパイプをサーバーとして作るアプリが必要ですが、PuTTY は基本的に「既存のパイプへ接続するクライアント」なので、噛み合わずに失敗しやすくなります。切り分けでは次の視点が有効です。
- VM を起動してもパイプが見えない：Hyper-V がサーバーとして作っていない可能性が高い
- パイプは見えるのに PuTTY だけ開けない：権限（ACL）や多重接続、パイプ名不一致を疑う
切り分けのおすすめ手順：最短で原因に辿り着く流れ
同じエラー文でも原因が複数あるため、闇雲に設定をいじるより「観測できる事実」から潰す方が早いです。おすすめの流れをまとめます。
| 順番 | やること | 分かること |
|---|---|---|
| 最初 | VM を起動し、dir \\.\pipe\ でパイプ名を確認 | Hyper-V 側が「サーバーとして」パイプを作れているか |
| 次 | PuTTY を管理者として実行して接続 | 権限が原因かどうか（最頻出ポイント） |
| 次 | パイプ名の完全一致、方向、VM の COM1 を再確認 | 設定ミス（タイポや逆設定）を排除 |
| 最後 | 接続はできるが表示がない場合、Nano 側の EMS 設定と再起動を確認 | “開けない” ではなく “何も出ない” 問題へ切り分け |
よくある質問
PuTTY を管理者で起動しても同じエラーです。次に見るべきは？
まずは パイプが存在しているか（dir \\.\pipe\）と、Hyper-V の COM1 が 「このエンドはサーバー」になっているかを確認してください。パイプが見えないなら PuTTY の前に Hyper-V 側の作成に失敗しています。
接続はできたのに画面が真っ黒です。壊れている？
壊れているとは限りません。EMS が無効、ポート番号が違う、ボーレートが違う、再起動していない、などで「つながるけれど出力がない」ことがあります。まずは EMS 設定と速度（例：115200）を揃え、VM を再起動して起動ログの段階から確認してみてください。
なぜ名前付きパイプを使うの？ 物理 COM ではダメ？
Hyper-V ホストに物理 COM ポートが無い環境が多く、またリモート管理でも「ローカルで完結する」手段が欲しいためです。名前付きパイプなら、ホスト上の端末ソフトだけでシリアルコンソールを再現でき、VM ごとに独立した接続口を作れます。
コメント