ネットワークプリンター-サーバー上の直接または共有プリンターを介して印刷しますか？
ワークステーションがプリンターに接続するには、次の2つの方法があります。
- ローカルにインストールされたプリンタードライバーを使用して、プリンターのIPに直接印刷します。
- サーバー上にある印刷キューとの
\\Server\Printer1共有への印刷。
どちらの方法が好ましいですか？
ネットワークトラフィックの観点からは、サーバーを経由するのではなく、ネットワークプリンターに直接印刷するのが最も効率的だと思います。一方、サーバープリンターの共有は、適切なドライバーがワークステーションに自動的にダウンロードされるため、管理が容易になります。
また、グループポリシーの基本設定を使用して、このプリンターをワークステーションにインストールするのはどうですか。特定の方法が必要ですか？
プリントサーバーでプリンタを共有するもう1つの利点は、プリンタの検出です。 ADでプリンターを公開すると、ユーザーがプリンターを見つけて追加するのがかなり簡単になります。
また、これは私の意見ですが、大規模な企業環境での私の経験に基づいています。1つまたは複数のプリントサーバーからプリンターを共有することが、ユーザーがプリンターを利用できるようにするための標準的な方法であることがわかります。ユーザーがプリンタに直接接続している企業環境（数人以上のユーザー）を見たことがありません。プリンターの管理、制御、トラブルシューティングがもっと面倒になると思います。 ITインフラストラクチャの管理の大部分は効率であり、ユーザーをプリンターに直接接続することは、管理性の観点からはあまり効率的ではありません。
ADやサーバーが存在しないSOHO環境では、ユーザーがプリンターに直接接続している可能性が高くなります。
答えは、ネットワークのサイズによって異なります。
小規模なネットワーク（おそらくADやサーバーがない）の場合、ユーザーはIP経由でプリンターに直接接続するだけで十分です。その小さなネットワークでは、プリンターを共有しているワークステーションが突然オフになった場合に備えて、別のワークステーションから共有プリンターを使用するよりも、直接接続する方がよい場合があります。
中小規模のネットワーク（Active Directoryを使用）の場合、私は通常、ADをプリンターサーバーとして使用し、プリンタードライバー（32および64ビット）をロードしてActive Directoryにリストします。
大規模なネットワークでは、プリントサーバー（または複数）をActive Directoryから分離することを検討する必要がありますが、それらをActive Directoryに一覧表示することもお勧めします。 ACLと権限に関する応答のその他のコメントも参照してください。
プリントサーバーを使用すると、プリンターを集中管理できます（プリンタージョブ/キュー管理用）。プリンターの数が多いほど、プリントサーバーでのプリンターの管理も多くなります。中央管理ポイントからプリンターにアクセスして、スタックしたジョブをクリアできることで、プリンターのステータスなどが確認できる場合があります。
プリンターを初めてインストールするときに、ユーザーがプリントサーバーからドライバーを自動ダウンロードできるのは素晴らしいことです。それらをADにリストすると、クライアントワークステーション/エンドユーザーが見つけやすくなり、プリンターにわかりやすい共通の名前を付けることができます。
少なくともプリンターの名前を単純に保つことができるAD（またはプリンターサーバーでさえ）を一覧表示/使用する代わりに、プリンターのIPにマップされたローカルネットワークDNS名を使用する（そしてプリンターのIPを静的に設定する） ）。ユーザーがプリンターを見つけたり、プリンターを追加したり、わかりやすい名前や識別しやすい名前であるかどうかを知るのはそれほど難しくありません。
異常に大量の印刷ジョブや信頼性の低いプリントサーバーがない限り、プリントサーバーを経由することは問題になりません。
Linux/MacのSambaが非常にうまく機能している場合でも、LinuxまたはMacシステムでSambaとの接続をセットアップする必要がないように、時々（まれに）IP経由で直接印刷します。
編集：以下のコメントからのフィードバックに基づいて更新されました。
ネットワークプリンターに十分なRAM=と処理能力がある場合は、そうです。IP経由で直接印刷するのが標準的な方法です。ただし、部門への印刷などを監査して、エージェント（不動産で一般的）またはデバイス自体によって提供されないその他のメトリックの場合、デバイスをプリントサーバー（WindowsまたはLinux）にインストールして共有する必要があります。もちろん、OSプラットフォームは、監査/監視ソフトウェア要件。
プリントサーバーを介した印刷の唯一のrealの利点は、ドキュメントを一元的に管理できるため、ドキュメントをはるかに簡単に管理できることです。これは、問題がある場合に重要になることがあります。理想的な世界ではすべての印刷はプリントサーバーを介して行われますが、その理由だけでも、Windowsは理想的な世界には存在しません。
プリントサーバー経由で接続するときに、ドライバーの問題や奇妙な動作が発生することは珍しくありません。これは、32ビットと64ビットのオペレーティングシステムを混在させる場合にも一般的であり、64ビットとHPの「ユニバーサル」ドライバーの1つを使用する場合にはさらに一般的であることに気付きました。この文脈での「ユニバーサル」とは、何に対してもうまく機能しないことを意味します。
私がしたいのは、まずプリントサーバーを構成し、その方法で全員を接続することです。すぐには解決できない問題が発生した場合にのみ、直接プリンターに接続します。
それはあなたのサイト、そしてどのような機能が必要かによって異なります。プリントサーバーが提供する追加機能が必要ない場合...なぜそれを含めるのですか？もう1つの障害ポイントが導入されているだけで、余分な冗長性はありません。
ネットワークトラフィックの点でどちらが最も効率的かを質問している場合は、大量のドキュメントを印刷しているのでない限り、心配する必要はありません。プリントサーバー用。
さらなる調査の結果、Computer Config GPPはTCP/IPプリンターを直接マップできることがわかりました。そのプリンタードライバーを取得するために使用する「ダミー」プリンター共有が必要なだけです。それは実際に印刷のためにそのダミー印刷キューを使用しません、それは直接ネットワークプリンターにそれをします。