Windows Server（仮想マシン）でプリンター追加がうまくいかないとき、原因は「クライアントがサーバーの共有プリンターへ接続できない」のか「サーバー自身がネットワークプリンターへ到達できない」のかで、開けるべきポートが変わります。切り分けと必要ポート、設定ポイントをまとめます。
最初に切り分けるべき「プリンターを追加」の意味
同じ「プリンターを追加できない」でも、通信経路が違えば必要なネットワークポートも違います。仮想マシン上の Windows Server では、クラウドのセキュリティグループや仮想スイッチ、社内FWなど複数の境界が重なりやすく、どこで止まっているかを先に整理すると解決が早くなります。
よくある接続パターン
- パターンA：印刷サーバー（共有プリンター）として使う
クライアント → Windows Server（共有プリンター）→（必要に応じて）プリンター - パターンB：サーバーがネットワークプリンターへ直接接続して使う
Windows Server → ネットワークプリンター（TCP/IPポートで印刷） - パターンC：クライアントがプリンターへ直接接続して使う
クライアント → ネットワークプリンター（サーバーは関係しない）
質問で意図しているのは多くの場合「パターンA（クライアントがサーバーの共有プリンターを追加できない）」です。ただし、サーバー側でプリンター自体の追加（ポート作成）ができないならパターンBの確認が必要です。
結論：開けるべきポートは「どこからどこへ」かで決まる
ネットワーク側の許可設定では、通信の向き（inbound / outbound）と到達先（Windows Serverか、プリンター本体か）を間違えないのが最重要です。次の表のどれに当てはまるかを先に決めてください。
| 目的 | 通信の向き | 主な許可ポート | 想定する失敗例 |
|---|---|---|---|
| クライアントが印刷サーバーの共有プリンターを追加・印刷する（パターンA） | クライアント → サーバー（サーバー側の受信許可） | TCP 445（SMB）、必要に応じて TCP 139 / UDP 137 / UDP 138 | 共有プリンターが見えない、追加が途中で止まる、ドライバー配布で失敗する |
| サーバーがネットワークプリンターへ直接印刷する（パターンB） | サーバー → プリンター（サーバー側の送信許可、プリンター側の受信許可） | TCP 9100（RAW/JetDirect）、TCP 515（LPR）、TCP 631（IPP）、（構成により）UDP 161/162（SNMP） | ポート作成はできるが印刷が詰まる、オフライン表示、ステータス取得不可 |
| クライアントがプリンターへ直接印刷する（パターンC） | クライアント → プリンター | プリンター仕様に依存（9100/515/631など） | サーバーは問題ないのに端末だけ印刷できない |
パターンA：Windows Server を印刷サーバーとして使う場合に必要なポート
印刷サーバーとして共有プリンターを提供する場合、クライアントとサーバーの間は基本的にファイル共有（SMB/NetBIOS）と同じ考え方になります。共有プリンターの参照、ドライバー配布、印刷ジョブの送信は SMB を中心に動くため、ここが閉じていると「追加できない」「印刷できない」になりやすいです。
クライアント ⇔ 印刷サーバーで許可すべき代表ポート
| ポート | プロトコル | 用途 | どんな環境で必要になりやすいか | 優先度 |
|---|---|---|---|---|
| 445 | TCP | SMB（共有プリンター接続、ドライバー配布、ジョブ送信） | 現行の Windows 環境の基本。DNS名（FQDN）で接続する運用と相性が良い | 最優先 |
| 139 | TCP | NetBIOS over TCP（SMBの旧来経路） | 古いクライアント、NetBIOS名前解決に依存する環境、特定のレガシー運用 | 必要時のみ |
| 137 | UDP | NetBIOS Name Service（名前解決） | DNSが使えない/使っていない、短いホスト名での参照が多い | 必要時のみ |
| 138 | UDP | NetBIOS Datagram（ブラウズ/通知系） | レガシーなネットワーク参照や検出に依存している場合 | 必要時のみ |
現実的なおすすめとしては、まずはTCP 445 だけを許可し、クライアント側はDNS（FQDN）で印刷サーバーを指定します。それで解決しない場合に、環境要件（古い端末やDNS未整備など）があるときだけ 139/137/138 を追加検討すると、開放範囲を必要最小限にできます。
Windows Server 側で確認したいサービスと設定
- Print Spooler（スプーラー）サービス：停止していると共有プリンターが機能しません。
- 共有設定：プリンターの「共有」チェック、共有名、アクセス許可（印刷/管理）。
- Windows Defender Firewall（高度なセキュリティ）：許可ポートを“ネットワーク側”で開けても、サーバーOS側の受信規則がブロックしていると失敗します。
Windows Defender Firewall で実務的にやるべきこと
GUI 操作でも良いのですが、作業者が複数いる環境では「何を開けたか」を再現しやすいように、ルール名とスコープ（許可する送信元）を決めておくと後で事故が減ります。
- 推奨：受信ルールで TCP 445 を許可し、送信元IP（クライアントのサブネット）を限定する
- 必要時のみ：TCP 139 / UDP 137 / UDP 138 を追加し、同様に送信元を限定する
- 避けたい：インターネット（0.0.0.0/0）から 445 を開ける。攻撃対象になりやすくリスクが高い
パターンB：サーバーがネットワークプリンターへ直接接続する場合に必要なポート
サーバー自身にプリンターを追加する（Standard TCP/IP ポートなどを作成する）場合は、クライアントではなくサーバー → プリンターの通信が成立している必要があります。ここで必要になるのは SMB ではなく、印刷プロトコル（RAW/LPR/IPP 等）です。
サーバー ⇔ プリンター間でよく使われるポート
| ポート | プロトコル | 名称・方式 | 特徴 | よくある用途 |
|---|---|---|---|---|
| 9100 | TCP | RAW / JetDirect | 実装が広く、設定が簡単。プリンターメーカーの「標準TCP/IP（RAW）」で選ばれやすい | 多くのオフィス向けプリンターで主流 |
| 515 | TCP | LPR/LPD | 古くからある方式。キュー名設定が必要な場合がある | UNIX系と混在、レガシー機器 |
| 631 | TCP | IPP | HTTPベース。機種や環境によっては管理・認証と組み合わせやすい | IPP対応プリンター、サーバー連携 |
| 161/162 | UDP | SNMP | 印刷自体ではなく状態監視（用紙切れ/トナー等）。監視を切っても印刷は通る構成が多い | オンライン/オフライン表示、状態取得 |
「どれを開ければよいか」は、Windows のプリンター追加ウィザードで作るポート種類（RAW/LPR/IPP）と、プリンター機種の仕様で確定します。迷ったら、まずはStandard TCP/IP ポート（RAW 9100）で試し、メーカー推奨が別方式なら切り替えるのが現場では早いです。
いま何の方式でつながっているかを確認する方法
すでに作成済みのポートがあるなら、サーバー上で「ポート番号」と「SNMP有効/無効」を確認すると、ネットワーク側で開けるべきものが見えます。
- GUI：印刷の管理（Print Management） → 対象サーバー → ポート
- PowerShell：Get-PrinterPort で PortNumber を確認
Get-PrinterPort | Select-Object Name, PrinterHostAddress, PortNumber, Protocol, SNMPEnabledPortNumber が 9100 なら RAW、515 なら LPR、631 なら IPP の可能性が高い、という形で当たりを付けられます（環境によっては例外もあります）。
「サーバーに追加できない」ときに起きがちな勘違い
現場で多いのが、サーバー側で追加できないのに、クライアント→サーバーのポート（445など）だけを疑ってしまうケースです。追加対象が「共有プリンター」なのか「プリンター本体」なのかで、見るべき経路が変わります。
| やりたいこと | つながるべき相手 | 主に疑うべき場所 |
|---|---|---|
| クライアントが \\サーバー\\共有プリンター を追加したい | クライアント → サーバー | ネットワークFW/ACLの受信許可、サーバーのWindows Firewall、名前解決（DNS/NetBIOS） |
| サーバーから IPアドレス指定でプリンターを追加したい | サーバー → プリンター | サーバーの送信許可、プリンター側の受信許可、ルーティング/VLAN、NATの有無 |
ポートが開いていても追加に失敗する代表的な原因
ネットワークポートは重要ですが、実際には「ポートは開いているのに追加できない」もよく起きます。仮想マシン上の Windows Server では、OS側の制限や運用設計が原因になることも多いので、以下も合わせて確認してください。
名前解決の問題（DNSか、NetBIOSか）
- クライアントが \\SERVER のような短い名前で参照している
- DNSが引けない/誤っているため、NetBIOSにフォールバックする
この状態だと、445 を開けても環境によってはうまく見えず、137/138/139 が必要になることがあります。可能なら、運用をFQDN（例：print01.example.local）に寄せ、DNSを整備する方が安定します。
ドライバー配布・インストール権限の問題（Point and Print）
共有プリンターの追加は、状況によってはクライアント側でプリンタードライバーのインストールが走ります。ここで権限やポリシーに引っかかると、ネットワークは通っていても追加に失敗します。
- 端末側が標準ユーザーで、ドライバーインストールに管理者権限が必要になっている
- 「ポイント アンド プリント」の制限で、信頼済みサーバー以外からのドライバー取得が拒否される
- サーバー側に用意したドライバーが端末OSと合わない（x64のみ、古すぎる等）
対策としては、信頼する印刷サーバーを明示する、パッケージ化ドライバー（Type 4 等）を検討する、端末配布をGPOで制御するなどが現実的です。ポートだけ開け続けて悩むより、ここを点検した方が早く解決することも多いです。
スプーラー（Print Spooler）が停止している
セキュリティ対策や運用都合でスプーラーが無効化されていると、共有も追加も動きません。まずはサーバーでサービス状態を確認します。
Get-Service Spooler
Start-Service Spooler仮想ネットワークの落とし穴（NAT/セグメント分離）
- 仮想マシンが NAT 配下で、プリンター（物理ネットワーク）へ到達できない
- オンプレとクラウド間でルーティングが無く、ICMPは通ってもTCPが通らない
- セキュリティグループ/NSGが「送信は許可、受信は拒否」など非対称になっている
特にパターンB（サーバー→プリンター）では、FWだけでなく経路（ルート）が無いことが原因のケースが目立ちます。ping が通る/通らないだけで判断せず、必要ポートで疎通確認するのが確実です。
疎通確認に使える実用コマンド（PowerShell）
「どこまで通っているか」を短時間で判断するための定番です。現場では、まずこれでポートレベルの可否を確認し、次に Windows 側のログへ進むと効率的です。
クライアント → サーバー（共有プリンター用）
Test-NetConnection -ComputerName <PrintServerNameOrIP> -Port 445サーバー → プリンター（RAW/JetDirect の例）
Test-NetConnection -ComputerName <PrinterIP> -Port 9100サーバー → プリンター（LPR/IPP の例）
Test-NetConnection -ComputerName <PrinterIP> -Port 515
Test-NetConnection -ComputerName <PrinterIP> -Port 631Test-NetConnection が成功しても印刷が動かない場合は、次の「ログ」と「権限・ドライバー」へ進むのが近道です。
Windows のログで原因を確定させる
「追加に失敗する」系は、画面のエラーだけだと原因が曖昧になりがちです。Windows Server 側でログを確認すると、通信なのか、ドライバーなのか、権限なのかが見えやすくなります。
確認したいイベントログ
- Microsoft-Windows-PrintService/Operational（印刷関連の詳細）
- System（サービス停止、ドライバー関連）
# 印刷サービスの運用ログを有効化していない場合は有効化してから確認
wevtutil sl Microsoft-Windows-PrintService/Operational /e:trueログに「アクセス拒否」「ドライバーが見つからない」「名前解決できない」などが出ていれば、ポート追加よりも先に直すべきポイントが分かります。
設計として押さえたいセキュリティと運用のコツ
プリンター関連は「動かす」だけなら簡単ですが、ネットワークでポートを広く開けると運用リスクが上がります。仮想マシンで印刷サーバーを運用するなら、次の方針が扱いやすいです。
最小開放の原則
- 共有プリンター運用（パターンA）は、基本 TCP 445 をクライアントサブネットからのみ許可
- サーバー→プリンター（パターンB）は、プリンターVLAN/サブネットへの 必要ポートだけ を許可
- レガシー要件が無いなら、NetBIOS（137/138/139）はむやみに開けない
プリンターを置くネットワークを分けると運用が楽になる
プリンターを業務端末と同一セグメントに置くと、端末から直接印刷（パターンC）が増え、トラブルの切り分けが難しくなります。可能なら、プリンターは専用VLANに寄せ、印刷サーバーだけが到達できる構成にすると、通信経路が単純になり「どこが悪いか」が早く特定できます。
ドライバー配布は「誰が管理するか」を決める
共有プリンター追加の成否は、ネットワークよりもドライバー配布で詰まることがあります。印刷サーバー側でドライバーを統一し、端末へはGPOなどで配布する方針にすると、現場対応が大幅に減ります。
症状別チェックリスト
| 症状 | まず疑うこと | 確認・対処の例 |
|---|---|---|
| \\サーバー にアクセスできない／共有プリンターが一覧に出ない | TCP 445、名前解決 | Test-NetConnection 445、FQDNで指定、FWで445受信許可（送信元限定） |
| 共有プリンターは見えるが、追加時にエラーになる | ドライバー配布・権限 | 端末側が管理者権限か、Point and Print ポリシー、サーバーのドライバー整備 |
| サーバーでネットワークプリンター（IP指定）を追加できない | サーバー→プリンターの経路とポート | Test-NetConnection 9100/515/631、ルーティング、プリンター側の受信設定 |
| 印刷ジョブが溜まる／オフラインになる | プロトコル不一致、SNMP、スプーラー | ポート種類（RAW/LPR/IPP）見直し、SNMP設定、Spooler稼働、ログ確認 |
まとめ
Windows Server（仮想マシン）でプリンター追加に失敗するときは、まず「クライアントがサーバーの共有プリンターへ接続できない」のか「サーバーがプリンターへ到達できない」のかを切り分けるのが最短ルートです。共有プリンター運用なら基本は TCP 445（SMB）、サーバーがプリンターへ直接接続するなら 9100/515/631 など印刷方式に応じたポートがポイントになります。加えて、名前解決・ドライバー配布・権限・スプーラーの状態まで確認すると、再発しにくい形で解決できます。
コメント