プリントサーバーの共有プリンターを一元管理する方法

プリントサーバーの共有プリンターを一元管理するには、Windows Serverへ［Print Server］役割を追加し、［印刷の管理］でサーバー、ドライバー、ポート、キュー、共有名、権限をまとめて管理します。最初に決めるのは、プリンター名ではなく「誰が、どの拠点から、どのキューを使うか」です。本記事ではWindows Server 2016以降とWindows 10／11クライアントを想定し、役割追加から共有、GPO展開、監視、障害切り分け、移行までを安全な順序で説明します。既存環境では設定をエクスポートし、少人数のテスト用OUで確認してから全社へ広げてください。

プリントサーバーで一元管理できるもの

プリントサーバーは、複合機へ直接印刷する代わりに、サーバー上の論理キューをクライアントへ共有します。管理者はキューごとにドライバー、印刷設定、利用者、ジョブ、優先度、設置場所を管理できます。利用者は通常、\\PRINT01\Tokyo-3F-Colorのような共有パスへ接続するだけです。プリンター本体のIPアドレスを変更しても、サーバー側のポートを直せば利用者の接続先を変えずに済みます。

共有キュー：表示名、共有名、場所、コメント、既定の印刷設定を統一する。
ポート：Standard TCP/IP Portなど、プリンター本体への通信先を管理する。
ドライバー：製造元、バージョン、アーキテクチャ、署名状態を把握する。
アクセス権：印刷、ドキュメントの管理、プリンターの管理を役割別に分ける。
ジョブと状態：一時停止、エラー、オフライン、滞留ジョブをサーバー側で確認する。

一元管理は、障害が起きないという意味ではありません。サーバー停止やスプーラー障害の影響範囲は大きくなります。拠点数、同時印刷量、WAN障害時の要件に応じて、拠点別サーバー、冗長化、直接印刷の非常手順も設計します。

作業前に決めておく設計項目

設定画面を開く前に命名規則と管理境界を決めます。たとえばサーバー名はPRINT01、キュー名はTYO-3F-MFP01-Color、共有名はTYO3F-Colorとし、［場所］には建物・階・部屋、［コメント］には機種名と保守窓口を入れます。名前を短くするだけでなく、利用者が選択を誤らず、監視通知から現物を特定できることが重要です。

サーバー：固定IPまたは予約、DNS、時刻同期、ドメイン参加、更新、バックアップを確認する。
プリンター：固定IP、ゲートウェイ、ファームウェア、管理パスワード、使用プロトコルを確認する。
ドライバー：製造元が対象OSをサポートする署名済みパッケージ対応版を優先する。
ネットワーク：クライアントから共有先、サーバーからプリンターへの必要通信だけを許可する。
容量：スプール先ディスクの空き、巨大なPDFや図面、同時印刷数を見積もる。
復旧：設定エクスポート、OSバックアップ、旧キューへ戻す条件、連絡担当を決める。

ドメインコントローラーに印刷役割を同居させる構成は、障害とセキュリティの影響範囲を広げます。これはWindowsの絶対的な禁止条件ではありませんが、業務環境では専用または役割を限定したメンバーサーバーを使うのが安全です。現行サーバーを変更するときは、まず［印刷の管理］の移行機能や組織のバックアップ手順で設定を退避します。

Print Server役割を追加する

Server Managerを開き、［Manage］、［Add Roles and Features］を選びます。
［Role-based or feature-based installation］を選び、対象サーバー名を確認します。
［Print and Document Services］を選び、必要な管理ツールを追加します。
Role servicesでは少なくとも［Print Server］を選びます。不要なInternet Printingなどは目的がない限り追加しません。
確認画面で対象サーバーと選択内容を記録し、メンテナンス時間内にインストールします。
完了後、Server Managerの［Tools］から［Print Management］を開きます。

Server Managerは複数のWindows Serverを管理できますが、役割を追加する対象を取り違えないことが重要です。サーバー名、OS、再起動要否を確認し、管理端末からリモート操作する場合は接続先を二度確認します。PowerShellで自動化する場合も、初回はGUIで役割名と影響を確認し、承認済みのスクリプトに限定してください。

印刷の管理へプリントサーバーを追加する

［印刷の管理］はPrint Managementコンソールであり、実行名はprintmanagement.mscです。左側の［Print Servers］を右クリックし、［Add/Remove Servers］から管理対象を追加します。コンソールを別の管理端末で使う場合、表示できることと変更権限があることは別です。日常監視用の読み取り担当と、ドライバーやキューを変更できる管理者を分離します。

追加後は対象サーバー配下の［Printers］、［Drivers］、［Ports］を開き、既存状態を記録します。意図しないローカルプリンター、古いドライバー、使われていないポートがあっても、利用実績を調べずに削除しません。まずキュー名、共有名、ポート、ドライバー、場所、権限、印刷設定を台帳へ対応付けます。

プリンターポートと共有キューを作成する

プリンター本体に管理用の固定IPまたはDHCP予約を設定し、サーバーから到達できることを確認します。
［Printers］を右クリックして［Add Printer］を開始し、ネットワーク上の新しいプリンターを追加する経路を選びます。
自動検出に頼らず管理する場合はStandard TCP/IP Portを作成し、本体のIPアドレスまたは安定したDNS名を指定します。
製造元のサポート情報と照合したドライバーを選びます。似た型番や古いCDのドライバーを流用しません。
キュー名、共有名、場所、コメントを命名規則どおりに入力し、共有を有効にします。
サーバー上でテストページを印刷し、用紙、両面、カラー、給紙トレイなどを確認します。
テスト端末から共有パスへ接続し、一般利用者の権限で再度印刷します。

SNMPを使って状態を取得する環境では、機器側とポート側のコミュニティ名や有効状態が一致しないと、実際には到達できてもオフライン表示になることがあります。切り分けのために無条件でSNMPを無効化するのではなく、監視設計と機器設定を確認します。またRAW 9100、LPR、IPPのどれを使うかは、機器の公式仕様と組織の暗号化方針に合わせます。

ドライバーを安全に管理する

共有プリンターでは、ドライバーの品質がサーバーと多数のクライアントへ影響します。製造元が対象Windows ServerとWindowsクライアントを明記した、署名済みのパッケージ対応ドライバーを使用します。Universal Driverは台数を減らせる反面、ステープル、認証印刷、特殊トレイなど固有機能が不足する場合があります。機種別ドライバーとの比較表を作り、業務機能をテストします。

新しいドライバーをいきなり既存キューへ割り当てず、複製した検証キューで印刷します。Office文書、PDF、画像、両面、カラー、部単位、認証印刷など代表データを確認し、スプーラー停止やアプリ異常がないか監視します。問題があれば旧ドライバーへ戻せるよう、バージョン、入手URL、導入日、対応キューを記録します。

共有プリンターの権限を分ける

プリンターのプロパティにある［Security］では、利用者へ必要最小限の権限を付与します。一般利用者には［Print］、ヘルプデスクには必要に応じて［Manage documents］、プリンター設定担当には［Manage this printer］を割り当てます。個人を直接追加せず、ADのセキュリティグループで管理すると、異動や退職時の追跡が容易です。

印刷グループ：対象キューへジョブを送信できる。
ジョブ管理グループ：滞留ジョブを確認・削除できるが、ドライバー変更はできない。
プリンター管理グループ：キューや共有設定を変更できるため、少人数に限定する。
サーバー管理者：OS、役割、更新を管理する。日常のジョブ削除に常用しない。

［Everyone］へ広い管理権限を付けたり、問題回避のために利用者をローカル管理者へ昇格したりしません。拒否権限は許可権限より優先して予想外の結果を生むため、明確な要件がない限りグループ単位の許可で設計します。

GPOで共有プリンターを展開する

台数が多い場合は、共有パスを利用者に手入力させず、グループポリシーで展開します。［印刷の管理］から共有プリンターを右クリックして［Deploy with Group Policy］を使う方法と、Group Policy Preferencesの［Printers］を使う方法があります。ユーザーが端末を替えても同じプリンターが必要ならユーザー構成、特定PCへ常に必要ならコンピューター構成を選びます。

検証用OUとテスト用の利用者・端末を用意し、既存GPOの継承を確認します。
新しいGPOを作成して目的が分かる名前を付け、対象共有パスを登録します。
セキュリティフィルターや項目レベルのターゲットで対象を限定します。
テスト端末でポリシー適用後、接続、ドライバー導入、通常使うプリンター、印刷を確認します。
イベントログとサーバー負荷を確認し、段階的に対象OUを広げます。

削除や置換のアクションは、共有名の誤りや条件漏れがあると多数端末からプリンターを消します。最初は作成・更新で検証し、旧キューの削除は利用状況とロールバック手順を確認して別の変更として実施します。GPOの即時更新を全社端末へ強制するのではなく、通常の更新周期とメンテナンス計画を利用します。

Point and Printの安全性を下げない

共有プリンター接続時のドライバー導入は、Point and Printのセキュリティ設定とWindows更新の影響を受けます。MicrosoftはPrint Spoolerの脆弱性対策後、管理者以外が新しいプリンタードライバーを導入する動作を厳格化しています。接続エラーを解消するために昇格確認を広範囲に無効化したり、信頼するサーバーを無制限にしたりする変更は避けます。

承認済みプリントサーバーのFQDNを限定し、署名済みパッケージ対応ドライバーを事前配布または管理者管理で導入し、サーバーとクライアントを更新します。［Point and Print Restrictions］や［Package Point and Print – Approved servers］を使う場合は、Microsoftの現行資料と組織のセキュリティ基準を確認します。レジストリ値だけを紹介する古い回避策は、現在の更新状態と矛盾する可能性があります。

日常監視で見る場所

［印刷の管理］では、キューの状態、ジョブ数、エラー、ドライバー、ポートを確認できます。これに加えて、PrintService関連イベントログ、Print Spoolerサービス、スプール先ディスクの空き、サーバーCPU・メモリ、プリンター本体の消耗品とエラーを監視します。監視で「停止」と出ても、サーバー、ポート、本体、ジョブのどこが原因かを分けます。

毎日：オフライン、エラー、長時間滞留ジョブ、ディスク空き、サービス状態を確認する。
毎週：キュー別の障害傾向、プリンター本体のログ、バックアップ結果を確認する。
毎月：Windows更新、ドライバーとファームウェア情報、不要キュー候補をレビューする。
変更時：設定前後の一覧、テスト結果、承認者、ロールバック可否を記録する。

PowerShellのPrintManagementモジュールにあるGet-Printerは、プリンター一覧の取得と台帳照合に利用できます。Add-Printerなど変更系コマンドは再現性を高めますが、対象名やパラメーターを誤ると影響も一括化します。まずGet系コマンドで読み取り、検証環境で結果を確認し、変更スクリプトはコードレビューと承認を通します。

印刷できないときの切り分け順

影響範囲を確認します。1ユーザー、1端末、1キュー、1機種、全キューのどこまでかを分けます。
プリントサーバー自身からテストページを印刷します。失敗するならクライアントGPOよりサーバー以降を調べます。
サーバーからプリンター名またはIPへ到達できるか、ポート設定と本体状態を確認します。
キューに一時停止、オフライン使用、滞留ジョブがないか確認します。
クライアントからサーバー名を名前解決でき、共有パスを開けるか確認します。
ドライバー導入時の昇格やPoint and Print関連エラーをイベントログで確認します。
別の既知文書、別ユーザー、別端末で比較し、文書・アプリ・端末・キューを切り分けます。

滞留ジョブを削除する前に、所有者、文書名、時刻、サイズ、エラーを記録します。Print Spoolerサービスの再起動は全キューに影響し、処理中のジョブが失われる場合があります。サービス再起動やスプールファイル削除を最初の手段にせず、利用者へ影響を通知し、承認された復旧手順で行います。

移行・更新・廃止の進め方

OS更改やサーバー移行では、現行設定をエクスポートし、新サーバーへインポートして終わりにしません。ドライバーが新OSをサポートするか、共有名とDNS別名を維持できるか、GPOがどのサーバーを参照するかを確認します。新旧サーバーを短期間並行稼働し、代表機種と代表業務をテストしてから切り替えます。

旧キューを廃止するときは、ジョブ履歴、問い合わせ、GPO、ログオンスクリプト、手順書、端末の手動接続を調査します。先に新キューを展開し、旧キュー名へ廃止予定を明記し、利用がなくなったことを確認して共有停止、削除の順に進めます。ドライバー削除は、ほかのキューが同じパッケージを使っていないか確認してから行います。

構築完了チェックリスト

サーバー名、IP、DNS、更新、バックアップ、スプール容量を確認した。
キュー名、共有名、場所、コメント、ポート、ドライバーを台帳へ記録した。
一般利用者、ヘルプデスク、管理者の権限をADグループで分離した。
サーバー上と一般利用者端末の両方から代表文書を印刷した。
Point and Printの警告や昇格を無効化せず、承認済みサーバーとドライバーに限定した。
検証OUから段階展開し、GPOの対象、結果、戻し方を記録した。
キュー、イベントログ、スプーラー、ディスク、本体を監視対象にした。
障害時の連絡先、直接印刷などの代替手段、復旧判断者を定めた。

一元管理の効果は、コンソールへサーバーを追加しただけでは生まれません。命名、権限、署名済みドライバー、段階展開、監視、台帳、復旧手順を同じ単位で運用して初めて、利用者の接続先を安定させ、障害時の調査時間を短縮できます。まず1台・1キュー・1グループで一連の手順を完成させ、そのテンプレートを次のプリンターへ横展開してください。

公式情報・参考資料

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。