Windows Server 2019 にHPなどのネットワークプリンターを追加しようとすると、pingは通るのにWeb管理画面が開けず、SNMPを有効にするとオフライン、無効でも印刷できない──。この症状はファイアウォールや上位FWで必要ポートが遮断されているケースが多く、確認ポイントを押さえると短時間で復旧できます。
起きている現象を“症状”として分解する
まずは状況をそのまま整理します。Windows Server 2019 Standard（v1809）で、HP LaserJet P4515n / CP2025 などのネットワークプリンターを追加する場面で、次のようなパターンがよく見られます。
- サーバーからプリンターのIPへ ping（ICMP）は通る
- しかし、ブラウザーで http://プリンターIP を開いても Web管理画面（EWS）が表示できない
- 「標準 TCP/IP ポート」で追加自体はできるが、SNMP 状態監視を有効にすると “オフライン”扱い
- SNMP を無効にすると “準備完了” に見えるが、テスト印刷や実印刷が通らない
- サーバーマネージャー / Print Management / コントロールパネル、どの追加方法でも結果は同じ
- ドライバは HP Universal Print Driver（PCL6） を HPサイト版・Windows Update版で試しても改善しない
この時点で「ドライバが悪いのでは？」と疑いたくなりますが、Web管理画面（80/443）が開けないことが重要な手がかりです。印刷以前に、サーバーからプリンターへ必要な通信が到達していない可能性が濃厚です。
pingが通るのにWeb管理画面が開けない理由
pingが成功しても「ネットワーク的に全部OK」とは限りません。pingはICMPという別系統の通信で、HTTP/HTTPS（TCP 80/443）とは扱いが異なります。
| 確認したいこと | 代表コマンド/操作 | 通っていれば言えること | 通らない場合の示唆 |
|---|---|---|---|
| IP到達性 | ping プリンターIP | IP経路は概ね生きている | 経路/ACL/アドレスの誤りを疑う |
| Web管理画面（HTTP） | ブラウザー、Test-NetConnection -Port 80 | TCP 80 が到達 | FW/ACLで80遮断、またはプリンター側で無効 |
| 印刷（RAW/JetDirect） | Test-NetConnection -Port 9100 | 印刷経路（9100）が到達 | FW/ACLで9100遮断、別プロトコル運用 |
| 状態監視（SNMP） | UDP 161の許可、SNMP設定 | “オフライン”判定の改善が期待できる | SNMP遮断/コミュニティ不一致でオフライン化 |
つまり、pingは通るがHTTP/印刷ポートは遮断という状況が、今回の症状ときれいに一致します。サーバー側の Windows Defender Firewall だけでなく、上位ファイアウォール、ネットワークACL、セグメント間のポリシー（ゼロトラスト系）などで、特定ポートだけ落とされていることがあります。
最短で原因を特定する切り分け（サーバー側で完結）
現場で効くのは「ポート単位で疎通を見て、どこで止まっているかを決め打ちする」ことです。Windows Server 2019 なら PowerShell でかなり正確に切り分けできます。
PowerShellで“必要ポート”の疎通を確認する
プリンターのIPを 192.0.2.50 とすると、次のように確認します（管理者権限のPowerShell推奨）。
Test-NetConnection 192.0.2.50 -Port 80
Test-NetConnection 192.0.2.50 -Port 443
Test-NetConnection 192.0.2.50 -Port 9100
Test-NetConnection 192.0.2.50 -Port 515
Test-NetConnection 192.0.2.50 -Port 631TcpTestSucceeded : True になれば、そのポートは到達しています。ここで80/443がFalseなら、Web管理画面が開けないのはほぼ説明できます。9100がFalseなら「準備完了に見えるのに印刷できない」も説明できます。
ブラウザーで開けない＝必ずしも“ページが存在しない”ではない
HTTP/HTTPS が遮断されている場合、ブラウザーは「接続できません」「応答がありません」といった形になります。一方で、プリンターが古くてHTTPSの暗号方式が合わない場合は、接続自体はできても証明書やTLSの警告で止まることがあります。今回のようにそもそも表示できない場合は、まずポート遮断を疑うのが合理的です。
原因の本命：ファイアウォール（サーバー側／上位FW／GPO配下）でブロック
結論から言うと、最も多い原因はこれです。
- Windows Defender Firewall（詳細設定）で、送信（Outbound）を制限している
- 上位FWやL3スイッチのACLで、サーバー→プリンターのTCP/UDPが遮断されている
- GPOでファイアウォールルールが集中管理されていて、ローカル変更が効かない
特に「サーバーは堅めに」運用している環境では、受信（Inbound）だけでなく送信（Outbound）もデフォルト拒否に近い設定になっていることがあります。プリンター追加の失敗は、この“送信制御”で説明できるケースが多いです。
プリンター関連で許可されがちな通信ポート一覧
環境によって使うプロトコルは異なりますが、トラブルシュートの観点では「何を許可すべきか」を一覧で把握しておくと速いです。
| 用途 | プロトコル | ポート | 使いどころ | 現場メモ |
|---|---|---|---|---|
| Web管理画面（EWS） | TCP | 80 / 443 | 設定確認、ネットワーク/トナー/ジョブ状況 | まずここが開ける状態にするのが最短 |
| RAW/JetDirect印刷 | TCP | 9100 | HP系で最も一般的な印刷経路 | 印刷できないならここが止まっていることが多い |
| LPR/LPD印刷 | TCP | 515 | UNIX互換の印刷方式、古い運用で残りがち | キュー名が必要な場合がある |
| IPP印刷 | TCP | 631 | IPP/IPP over HTTPSの運用 | 新しい機種やセキュア運用で採用される |
| SNMP状態監視 | UDP | 161（照会）/ 162（Trap） | “オフライン判定”や残量取得 | 遮断されるとオフラインになりやすい |
今回の症状を同時に満たす典型例は、TCP 80/443 と TCP 9100 と UDP 161 がいずれか（または全部）ブロックされている状態です。
解決の手順：まずWeb管理画面を通してから、印刷ポートを通す
「プリンター追加」をゴールにするより、先にサーバーからWeb管理画面（80/443）に到達させるほうが、切り分けが一気に進みます。Web管理画面が見えれば、プリンター側の設定（有効なプロトコル、IP設定、SNMP設定）も確認できるためです。
手順のチェックリスト
- サーバー→プリンターIP の TCP 80/443 が通る（Web管理画面が開ける）
- サーバー→プリンターIP の TCP 9100（または運用プロトコルのポート）が通る
- 状態監視が必要なら UDP 161 も通す（不要なら監視を切る）
- その後に「標準 TCP/IP ポート」で追加し、テスト印刷
Windows Defender Firewall（詳細設定）で確認すべきポイント
サーバー側のファイアウォールは、GUIでもPowerShellでも確認できます。GUIの場合は wf.msc（Windows Defender Firewall with Advanced Security）を開きます。
- どのプロファイルが適用中か（ドメイン/プライベート/パブリック）
- 送信（Outbound）ルールに「ブロック」が存在しないか
- GPO管理の場合、ローカルで追加したルールが上書きされていないか
「受信（Inbound）を許可したのに直らない」というケースは、そもそも必要なのが送信（Outbound）側の許可だった、ということが少なくありません。
PowerShellで“適用プロファイル”とブロック傾向を確認
Get-NetFirewallProfile | Format-Table Name, Enabled, DefaultInboundAction, DefaultOutboundActionここで DefaultOutboundAction が Block になっているプロファイルが適用されている場合、許可ルールを作らない限り、プリンター向け通信は通りません（環境によっては例外ルールのみ通る運用もあります）。
許可ルールの作り方（例：プリンター1台にだけ絞って安全に）
セキュリティの観点では、むやみに全宛先・全ポートを開けるのは避け、RemoteAddress（プリンターIP）を絞るのが実務的です。
| ルール名（例） | 方向 | プロトコル | ポート | RemoteAddress |
|---|---|---|---|---|
| Allow Printer Web | Outbound | TCP | 80, 443 | プリンターIP |
| Allow Printer RAW | Outbound | TCP | 9100 | プリンターIP |
| Allow Printer SNMP | Outbound | UDP | 161 | プリンターIP |
PowerShellで作るなら次のようなイメージです（プロファイルは環境に合わせて絞ってください）。
# Web管理画面（HTTP/HTTPS）
New-NetFirewallRule -DisplayName "Allow Printer Web (TCP 80)" -Direction Outbound -Action Allow -Protocol TCP -RemoteAddress 192.0.2.50 -RemotePort 80 -Profile Domain,Private
New-NetFirewallRule -DisplayName "Allow Printer Web (TCP 443)" -Direction Outbound -Action Allow -Protocol TCP -RemoteAddress 192.0.2.50 -RemotePort 443 -Profile Domain,Private
# RAW/JetDirect印刷（9100）
New-NetFirewallRule -DisplayName "Allow Printer RAW (TCP 9100)" -Direction Outbound -Action Allow -Protocol TCP -RemoteAddress 192.0.2.50 -RemotePort 9100 -Profile Domain,Private
# SNMP状態監視（UDP 161）
New-NetFirewallRule -DisplayName "Allow Printer SNMP (UDP 161)" -Direction Outbound -Action Allow -Protocol UDP -RemoteAddress 192.0.2.50 -RemotePort 161 -Profile Domain,Private上位FW/ACLが原因の場合は、同じポートをネットワーク側でも許可する必要があります。サーバー側で許可しても、L3境界やFWで落ちていれば届きません。サーバー→プリンターセグメントの許可ルールを、ネットワーク運用チームの標準に沿って追加します。
プリンター追加のおすすめ設定（標準 TCP/IP ポート）
疎通が取れたら、追加自体はオーソドックスに進めるのが安定です。ポイントは「WSDではなく標準 TCP/IP」「プロトコルはRAW 9100優先」「SNMPは状況により切り替え」です。
追加手順（GUIの要点）
- 「プリンターの追加」→「必要なプリンターが一覧にない」→「TCP/IP アドレスまたはホスト名を使ってプリンターを追加」
- デバイスの種類は「TCP/IP デバイス」
- ポート名は分かるように（例：
IP_192.0.2.50_RAW9100） - 検出が失敗する環境では「プリンターを照会して使用するドライバーを自動的に選択する」のチェックを外す
- プロトコルは基本は RAW、ポートは 9100
SNMPの扱い：オフライン問題の核心
Windowsの標準TCP/IPポートは、設定によってSNMPでプリンター状態を監視します。ここでUDP 161が遮断されていたり、コミュニティ名が合っていないと、印刷データは送れているのに「オフライン」と判定されることがあります。
| 状況 | 見え方 | 対処 | 向いている運用 |
|---|---|---|---|
| SNMPを有効にしたらオフライン | “オフライン”でキューが詰まる | UDP 161を許可、コミュニティ確認 | 状態監視が必要、残量/アラートが欲しい |
| SNMPを無効にすると準備完了だが印刷不可 | 表示は正常でも出力されない | TCP 9100（または使用プロトコル）を許可 | まずは印刷経路の復旧を優先 |
| 状態監視は不要 | 印刷だけできればよい | SNMPステータスを無効で運用 | 小規模/監視は別系統で行う |
今回のケースでは、SNMPのON/OFFで表示が変わるのに印刷できないため、SNMP（UDP 161）だけでなく、印刷ポート（多くはTCP 9100）も通っていない可能性が高いです。「表示」ではなく「印刷データが届いているか」を確認することが重要です。
ドライバは“原因の切り分け”として使う（まず通信を直す）
HP Universal Print Driver PCL6 は便利ですが、通信が止まっている状態では、どのドライバにしても結果は変わりません。順番としては、
- まずWeb管理画面（80/443）と印刷ポート（9100等）の疎通を確立
- 次にドライバ（UPD PCL6 / PS / 機種別）を検討
という流れが安全です。
それでもドライバが疑わしい場合は、次の観点で確認します。
- UPD（PCL6）で不安定なら、機種が対応する範囲で PSドライバや機種別ドライバも試す
- 印刷サーバーとして共有するなら、クライアントOSとの組み合わせも意識する（x64のみ、パッケージドライバ等）
- 「双方向サポート（Bidirectional Support）」が絡む挙動もあるため、切り分け中は無効化して挙動が変わるか見る
それでも直らないときの追加チェック（現場でよくハマる）
プリンター側でWeb管理画面が無効、またはHTTPSへ強制リダイレクト
ネットワークは通っているのに80/443が開かない場合、プリンター側設定でWebが無効なこともあります。とはいえ、多くの機種では初期状態で有効です。サーバー以外のPC（別セグメント含む）から開けるか試すと切り分けが早いです。
ポート9100を使っていない（LPR/IPP運用）
組織の標準がLPR（515）やIPP（631）になっている場合、9100を開けても印刷できないことがあります。プリンター管理画面や既存の印刷サーバー設定を確認し、実際に使っているプロトコルに合わせます。
LPRの“キュー名”が違う
LPRはキュー名（印刷キュー/プリンタ名）が必要な場合があります。誤っていると疎通があっても印刷が落ちます。既存環境の設定値（例：RAW、lpなど）を踏襲します。
Windows Server側のPrint Spoolerが不安定
疎通が取れているのにキューが詰まる場合は、スプーラーの再起動が効くことがあります。
Restart-Service Spoolerまた、印刷ジョブが破損していると復旧しないことがあるため、切り分け中はキューを空にしてから再試行します（運用影響に注意）。
ログで“どこで失敗しているか”を掴む
Windows Server 2019 には印刷のイベントログがあります。障害時は、まずここを見ると遠回りしません。
- イベントビューアー → アプリケーションとサービスログ → Microsoft → Windows → PrintService → Operational
- 同じく PrintService の Admin
「ポートに接続できない」「ジョブが送信できない」など、通信遮断が原因のときはそれっぽいエラーが出ます。
パケット採取で確定させる（時間がない現場で強い）
「FWが怪しいが確証がない」「ネットワーク側が変更できない」場合、サーバー側で接続試行が出ているかを見るのが有効です。組織のルールに従ったうえで、Windows標準のトレース機能を使います。
netsh trace start capture=yes scenario=NetConnection tracefile=C:\temp\printer_trace.etl
# テスト印刷や Test-NetConnection を実行
netsh trace stopETL解析は少し手間ですが、「SYNを投げているが返ってこない」などが分かると、上位FW/ACLが原因と説明しやすくなります。
再発防止：ルール設計と運用のコツ
ネットワークプリンターは“社内で当たり前に使う”一方で、サーバーのセキュリティ基準とは相性が悪いことがあります。再発防止としては、次の設計が効きます。
- 印刷サーバーからプリンターへの許可は、宛先IP（プリンター群）とポート（80/443/9100/161など）を最小化して明文化する
- プリンター用のセグメント/VLANを分け、サーバー→プリンターの通信だけを許可する
- SNMP v1/v2cを使うなら、コミュニティ名をデフォルトのままにしない、可能なら管理用IPからのみ許可する
- 運用で不要なら、状態監視（SNMP）を無理に有効化しない（印刷経路の安定を優先）
- GPOでFW管理している場合、例外ルールをテンプレ化して、新サーバー追加時に漏れない仕組みにする
また、切り分けの小技として「別PCからプリンターのWeb管理画面に入れるか」「既存の印刷サーバーからは印刷できているか」を早めに確認すると、プリンター故障・設定ミス・ネットワーク制限のどれかに素早く寄せられます。
補足：再発防止と切り分けに効く小ネタ
最後に、今回のような「通信が怪しいのか、ドライバや互換性が怪しいのか」で迷ったときに役立つ、実務寄りの確認ポイントをまとめます。
「ファイルとプリンターの共有」を有効にする場面
サーバーを印刷サーバーとして運用し、クライアントPCへプリンターを共有する場合は、クライアント→サーバー側の通信も成立している必要があります。Windows Defender Firewall のルールセットとしての「ファイルとプリンターの共有」が無効だと、共有印刷に絡む動作に影響することがあります（環境のセキュリティ基準に合わせて最小権限で許可します）。
| 観点 | よくある症状 | 確認/対処 |
|---|---|---|
| クライアント→サーバーの共有印刷 | 共有プリンターに接続できない、印刷ジョブがサーバーに届かない | サーバー側で「ファイルとプリンターの共有」関連の受信ルール、SMB/RPCの設計を確認 |
| サーバー→プリンターの直印刷 | 本記事のテーマ（Web管理画面が開けない/印刷できない） | まずはTCP 80/443/9100、UDP 161の“送信”許可を確認 |
ドライバは“自動更新に最新が来ない”前提で見る
Windows Update 経由のドライバは、企業環境だと配信が遅れたり、意図的に制御されていたりします。印刷品質や不具合が疑われるときは、メーカーサイトの最新版（HP Universal Print Driver など）も合わせて確認すると、遠回りを減らせます。
PCで共有したプリンターにサーバーから接続してみる
切り分けの裏技として、いったん別のPCでプリンターを追加→共有し、サーバーからその共有プリンターへ接続して印刷できるか試します。これで印刷が成功するなら、ドライバ互換性よりもサーバー→プリンター直通の通信（FW/ACL/ポート）が原因である可能性が高まります。逆に共有でも失敗するなら、ドライバ/スプーラー/OS側の問題に寄せて調査できます。
まとめ
Windows Server 2019 で「ネットワークプリンターを追加できない」「pingは通るのにプリンターのWeb管理画面が開けない」「SNMPを有効にするとオフライン」「SNMPを無効にしても印刷できない」といった症状は、ドライバよりも先に通信（FW/ACL）を疑うのが近道です。
- まずはサーバーから TCP 80/443 が通り、Web管理画面が開ける状態にする
- 次に TCP 9100（または運用プロトコル）を通してテスト印刷する
- 状態監視が必要なら UDP 161 を通す／不要ならSNMPステータスを無効化する
- 最後にドライバ最適化（UPD PCL6/PS/機種別）で品質を詰める
この順番で進めれば、サーバーマネージャーやPrint Managementで遠回りする前に、原因を確定して復旧できます。
コメント