結論から言うと、プリントサーバー移行で見直すべきはドライバー分離の設定値そのものではなく、「どのドライバーを残すか」です。ドライバー分離は、印刷ドライバーを Print Spooler とは別プロセスで動かして障害の巻き込みを減らす仕組みですが、Point and Print の権限問題や、v3／v4／IPP の仕様差まで自動で解決してくれるわけではありません。export/import の前にドライバーの生存判定をできるかどうかで、移行後の安定性は大きく変わります。 (Microsoft Learn)
Print Management の「Migrate Printers」を使えば、プリンターキューとドライバーのエクスポート／インポート自体はできます。ただし Microsoft の移行ガイドでも、元サーバーが複数ロールを持つ場合は単純なロール移行ではなく、個別設計の手順を取るよう案内しています。つまり、「移せる」ことと「そのまま持ち込んでよい」ことは別です。 (Microsoft Learn)
プリントサーバー移行で最初に決めるべきこと
プリントサーバー移行で先に決めるべき順番は、次の4つです。
- そのキューでメーカー独自機能が本当に必要か
- 残すなら、v3 packaged／v4／IPP のどれで維持するか
- 残すドライバーを Shared / Isolated / None のどこに置くか
- クライアント配布を GPO、Point and Print、手動配布、クラウドのどれで回すか
ここを逆にして「まず全部 Isolated にする」「まず新サーバーへ全部 import する」と進めると、移行後にクライアント接続、権限、UI差異、仕上げ機能の不一致がまとめて噴き出します。ドライバー分離、Point and Print、v4 sharing は Microsoft の資料でも別の仕組みとして扱われています。 (Microsoft Learn)
実務では、まずキューを次の3群に分けると判断しやすくなります。
- 高機能MFP群
ホチキス、中綴じ、パンチ、認証印刷、部門管理、独自フォームなどが必要なキュー。 - 一般事務印刷群
A4、両面、トレイ切替程度で十分なキュー。 - レガシー温存群
古い業務アプリ、特殊帳票、LPR、古いモデル専用ドライバーに依存するキュー。
この分類が先にできると、「分離をどうするか」よりも「そもそも残す価値があるドライバーか」で判断できるようになります。
ドライバー分離の仕様を先に押さえる
Windows の Execute print drivers in isolated processes は、Print Spooler が読み込むドライバーを分離するためのポリシーです。一方、Isolate print drivers from applications は、アプリケーション側に読み込まれる印刷ドライバー部品を分離する別ポリシーです。名前が似ているため混同しやすいのですが、片方を変えてももう片方の障害モードは変わりません。 (Microsoft Learn)
見落としやすいのは、分離設定がキュー単位ではなくドライバー単位で効くことです。Microsoft Learn でも、Print Management で対象の「ドライバー」に対して isolation mode を設定する形で説明されています。同じドライバー名を複数キューで共有しているなら、1台だけの変更のつもりでも、実際の影響範囲はそのドライバーを使う全キューに及びます。 (Microsoft Learn)
Shared / Isolated / None の違い
以下は Microsoft の定義をもとに、実務での判断基準まで含めて整理したものです。定義自体は公式ドキュメントの Shared / Isolated / None の説明に基づいています。 (Microsoft Learn)
| モード | 何が分かれるか | 向く運用 | 注意点 |
|---|---|---|---|
| Shared | Spooler とは別プロセス。ほかの分離対応ドライバーとは共有プロセス。 | 分離対応している現行ドライバーの標準運用。最初の候補。 | ほかの分離ドライバーと同一プロセスになる前提は残る。 |
| Isolated | Spooler とも、ほかのドライバーとも別プロセス。 | 特定ドライバーだけ不安定、競合しやすい、障害切り分けを明確にしたい場合。 | 同じドライバーを使う全キューで再テストが必要。 |
| None | Spooler プロセス内で動作。 | 分離非対応、または分離で必要機能が崩れるドライバーの一時避難。 | 障害時に Spooler を巻き込みやすい。恒久運用には向きにくい。 |
さらに重要なのが、INF が DriverIsolation=0 を明示しているドライバーは、管理者でも強制分離できない点です。逆に、互換性があり個別モード未設定のドライバーは shared で動く挙動が既定になります。つまり「全部 Isolated に寄せれば安全」という考え方は、仕様上そのままでは通りません。 (Microsoft Learn)
プリントサーバー移行で見直すべきドライバーの種類
移行で本当に差が出るのは、Shared と Isolated の違いだけではありません。もっと効くのは、v3 を残すのか、package-aware v3 に寄せるのか、v4 や IPP に置き換えるのかです。Microsoft は v4 ドライバーモデルについて、共有を効率化し、プロセッサ アーキテクチャをまたいだドライバー管理を不要にすると説明しています。一方で v4 は configuration plug-in を使わない設計なので、従来のメーカー独自 UI や細かな機能表現は、そのまま同等とは限りません。Windows 10 / 11 の現行方針では、IPP inbox class driver と Print Support Apps を組み合わせる「modern print platform」が推奨されています。 (Microsoft Learn)
どのドライバー戦略を選ぶべきか
| 選択肢 | 向くケース | 移行での利点 | 先に確認すべきこと |
|---|---|---|---|
| package-aware v3 | 仕上げ、部門管理、認証印刷、独自フォームなどを落とせない | 既存機能を保ちやすい。signed package 配布の前提を持てる | 標準ユーザーの新規接続・更新時の権限設計、分離対応可否 |
| non-package-aware v3 | 代替がなく、一時的に残すしかない | 既存アプリとの互換維持 | セキュリティプロンプト、配布設計、将来の保守負荷が重い |
| v4 | 一般事務印刷中心。高度な独自 UI に依存しない | 共有がしやすく、クロスアーキ管理を減らせる | 独自機能や UI を再検証する必要がある |
| IPP inbox class driver + PSA | Windows 10 / 11 の標準印刷中心。将来負債を減らしたい | Microsoft 推奨の現行設計に寄せられる | 端末・プリンター側の対応、必要機能の再検証 |
package-aware Point and Print は、署名済みドライバーパッケージをクライアントへ配布でき、legacy Point and Print で必要だったセキュリティプロンプトを減らす方向の仕組みです。ただし、2021年8月10日以降の更新以後は、Point and Print での新規インストールや既存ドライバー更新に管理者権限が既定で必要になりました。つまり、package-aware なら何もしなくてよいわけではなく、配布ルールまで含めて設計する必要があります。 (Microsoft Learn)
v4 へ切り替えるときに勘違いしやすいのが、共有の考え方まで変わることです。Microsoft は v4 sharing について、legacy v3 のようにサーバーからメーカー独自ドライバーをそのまま配る前提ではなく、enhanced Point and Print によってクライアント側の取得・互換ドライバー・client-side rendering を使う設計として説明しています。移行の途中で v3 から v4 へ変えるなら、サーバー上の印刷テストだけでなく、新規クライアント接続の体験そのものを別物として確認すべきです。 (Microsoft Learn)
移行前に必ずやる棚卸し
Print Management のウィザードを開く前に、まずはドライバー、キュー、ポート、印刷設定を棚卸ししてください。PowerShell の PrintManagement モジュールには、Get-PrinterDriver、Get-Printer、Get-PrinterPort、Get-PrintConfiguration があり、いずれもリモート取得ができます。 (Microsoft Learn)
$server = "OLD-PRINT01"
Get-PrinterDriver -ComputerName $server -Name * |
Sort-Object Name |
Select-Object Name, Manufacturer, MajorVersion
Get-Printer -ComputerName $server |
Select-Object Name, DriverName, PortName, Shared, ShareName
Get-PrinterPort -ComputerName $server |
Select-Object Name, PrinterHostAddress, PortNumber
Get-Printer -ComputerName $server | ForEach-Object {
Get-PrintConfiguration -ComputerName $server -PrinterName $_.Name |
Select-Object PSComputerName, PrinterName, DuplexingMode, PaperSize, Color
}この一覧に、少なくとも次の列を足しておくと移行判断がしやすくなります。
- 業務上必須の機能
例: ホチキス、パンチ、中綴じ、部門コード、ICカード認証、独自フォーム - 利用クライアント
例: 一般PC、RDS、VDI、設計端末、工場端末 - 配布方法
例: GPO、スクリプト、手動、セルフサービス - 標準ユーザーで初回接続が必要か
- 同じドライバー名を使うキュー数
- 廃止候補かどうか
PrintBRM が失敗しやすい場所
Microsoft の PrintBRM イベント一覧を見ると、移行で詰まりやすいポイントはかなり具体的です。特に注意したいのは、アーキテクチャ違いのドライバー、移行プラグイン DLL、LPR ポート、カスタムフォーム、スプールフォルダーのパス差異です。これらは「import 後に印刷できない」「見た目だけ復元される」原因になりやすい項目です。 (Microsoft Learn)
| 見落としやすい項目 | 起きやすいこと | 移行前にやること |
|---|---|---|
| ネイティブアーキ不一致 | 目的サーバーで native driver を見つけられず import 失敗 | x64 など目的環境の最新ドライバーを先に用意する |
| ベンダーの migration plug-in DLL | import は通っても正常動作しない | 現行 OEM ドライバーへ更新、残す価値があるか再判定する |
| LPR ポート | 互換性や設定不足で再現できない | ポート設定を一覧化し、必要なら TCP/IP へ寄せる |
| カスタムフォーム | 復元失敗、既存フォームと競合 | フォーム定義を別資料でも残す |
| カスタム spool フォルダー | 目的サーバーで存在せず既定値へ戻る | 同じパスを作るか、移行後の配置変更を設計する |
移行中に Print Spooler 側の障害で復元が止まる場合、Microsoft 自身が「ドライバー分離を有効にして復元を継続できる」回避策を案内しています。つまり、分離設定は移行後の安定化だけでなく、移行作業そのものの継続性にも効きます。 (Microsoft Learn)
ドライバー分離モードの現実的な判断基準
ここまで整理したうえで、ドライバー分離の運用ルールは次のように決めると現実的です。
残すドライバーの初期値は Shared から始める
互換性があり、個別モード未設定のドライバーは shared で動くのが基本挙動です。移行後に残す現行ドライバーで、まず大きな問題が出ていないものは Shared を初期値にするほうが、運用が素直です。いきなり Isolated へ振り切るより、障害範囲とテスト量を読みやすくできます。 (Microsoft Learn)
Isolated は「問題ドライバーの隔離」に使う
Microsoft の説明でも、Isolated が有効なのは、ほかのドライバーとプロセスを共有しにくいケースや、ファイル名競合、頻繁な fault、メモリリークが疑われるケースです。過去に Spooler 落ち、特定メーカー系だけの不安定さ、アップデート後の異常を起こしたドライバーは、そのドライバーだけ Isolated に切り分けるのが筋です。 (Microsoft Learn)
None は互換性のための例外扱いにする
分離設定が合わない、あるいは DriverIsolation=0 で強制分離もできないドライバーは、やむを得ず None で残すことがあります。ただしこれは恒久対策ではなく、置き換え対象の棚上げです。None のままにするなら、「いつまでに別ドライバーへ移すか」「その間どのキューだけで使うか」を決めておかないと、移行後の技術的負債がそのまま固定されます。 (Microsoft Learn)
分離は安定性の設定であって、権限や配布の設定ではない
ここを混同すると対処がずれます。ドライバー分離は Spooler 障害の巻き込みを減らす仕組みであり、標準ユーザーの初回接続可否や Point and Print の権限設計は別問題です。クライアント配布で困っているなら、分離設定より driver packaging、approved servers、権限ポリシー を見るのが先です。 (Microsoft Learn)
GPO・Point and Print で詰まりやすい落とし穴
2021年8月10日以降の Windows 更新では、Point and Print で新しいプリンターのインストールや既存ドライバーの更新に管理者権限が既定で必要になりました。移行後に標準ユーザーが新サーバーへ初めて接続すると失敗するケースは、サーバー移行の失敗というより、この既定動作に引っかかっていることが少なくありません。 (マイクロソフトサポート)
症状から逆引きすると見直しやすい
| 症状 | まず疑うこと | 優先して確認する場所 |
|---|---|---|
| 標準ユーザーで新規接続できない | Point and Print の既定動作、approved servers 未整備 | RestrictDriverInstallationToAdministrators、approved servers、ドライバー方式 |
| 毎回管理者プロンプトが出る | サーバーとクライアントのドライバーファイル不整合 | サーバー／クライアントのドライバーバージョン、OEM 更新状況 |
| 旧サーバーでは接続できたのに新サーバーでは失敗 | GPO の UNC パス、信頼サーバー一覧の未更新 | GPO、スクリプト、ポリシーのサーバー名 |
package-aware かどうかで見るべき GPO が変わる点も重要です。Microsoft サポートでは、non-package-aware ドライバーには Point and Print Restrictions、package-aware ドライバーには Package Point and Print - Approved servers を使う流れを案内しています。ここを逆に見ていると、設定しているのに効かない状態になりがちです。 (マイクロソフトサポート)
また、RestrictDriverInstallationToAdministrators=0 を安易に使うのもおすすめできません。Microsoft は、これを 1 にする状態と等価な緩和策の組み合わせはないと明言しています。どうしても 0 に戻すなら、対象サーバーを厳しく絞り、approved servers と警告／昇格プロンプトを前提にした一時措置として扱うべきです。 (マイクロソフトサポート)
GPO で共有プリンターを配る運用では、プリンター接続は完全修飾 UNC パスで参照され、その共有接続がドライバーのインストール元として使われます。したがって、サーバー名や共有パスが変わる移行では、旧パスを維持する設計にするか、GPO・スクリプト・許可サーバー一覧を同時に更新するかのどちらかが必要です。ここを曖昧にすると、サーバー側は正常でもクライアントだけ取り残されます。 (Microsoft Learn)
なお、毎回「このプリンターを信頼しますか」や管理者資格情報の入力が出る場合、Microsoft は FAQ で、サーバーとクライアントの同名ドライバーファイルのバージョン不整合が原因になり得ると説明しています。移行時にドライバーを整理しきれず、旧サーバーと新サーバーで微妙に違う OEM パッケージが混在すると、この症状が出やすくなります。 (マイクロソフトサポート)
代替策まで含めて決める
一般事務印刷が中心で、Windows 10 / 11 クライアントが主流なら、古いサードパーティ製ドライバーを抱え続けるより、IPP inbox class driver + PSA への寄せ方も現実的です。Microsoft はこれを Windows 10 / 11 における推奨の modern print platform と位置づけています。さらに、Microsoft は 2025 年公開の文書で、2026 年 7 月 1 日から Windows Update のドライバー順位付けを Windows IPP inbox class driver 優先に変更し、2027 年 7 月 1 日から はセキュリティ修正を除いてサードパーティ製プリンタードライバー更新を許可しない計画を示しています。いま移行するなら、古い OEM ドライバーを温存する設計は中長期で不利です。 (Microsoft Learn)
Microsoft 365 前提のクラウド寄り運用なら、Universal Print も比較対象に入ります。Microsoft Learn では、Universal Print は print server を不要とし、Microsoft 365 にコミットした組織では Windows Server print server の機能を置き換えるものとして説明されています。オンプレの print server を「移行するか」だけでなく、「そもそも残すか」から考えたい環境では有力です。 (Microsoft Learn)
ざっくり整理すると、選び方は次のとおりです。
- 高機能MFPを確実に維持したい
→ on-prem print server を残し、package-aware v3 を軸に Shared / Isolated を使い分ける。 - 一般事務印刷が多く、特殊機能が少ない
→ v4 や IPP へ寄せて、ドライバー数そのものを減らす。 - Microsoft 365 / クラウド中心へ寄せたい
→ Universal Print を含めて、print server 依存を下げる。
移行直前と移行後のチェック
最後に、プリントサーバー移行でドライバー分離を見直すときの確認項目を、実務向けに絞ると次のようになります。
- ドライバー一覧を DriverName 単位で整理したか
- 同じドライバーを使うキューを横串で把握しているか
- 高機能MFPと一般事務印刷を分けて扱っているか
- 目的サーバー向けの native driver を事前に用意したか
- LPR、カスタムフォーム、spool フォルダー差異を記録したか
- 標準ユーザーの新規接続テストを clean client で実施したか
- approved servers と GPO の UNC パスを更新したか
Noneのまま残すドライバーに置換期限を付けたか
最初の一手としておすすめなのは、現行サーバーから DriverName 単位の一覧を出し、各ドライバーに 「残す／置き換える／廃止」、「Shared／Isolated／None」、「標準ユーザー初回接続あり／なし」 の3項目を付けることです。ここまで決まれば、移行作業はかなり読みやすくなります。逆に、この整理を飛ばして export/import だけ先に進めると、問題は移行後にクライアント側で表面化します。 (Microsoft Learn)
コメント