自動インストールとドライブイメージング
自動インストールとドライブイメージングを介した展開の長所と短所は何ですか？ Windowsの場合、ドライブのクローンを作成する際のSID生成に問題があることを私は知っています。イメージを介してLinuxをデプロイする場合に同様の問題はありますか？
私はここでの答えのいくつかに同意しません。正しく行われた場合、画像を取得し、異なるハードウェアを使用して複数のシステムにロードできます。個人的には、最大30の異なるシステムをサポートする画像を見てきました。
あなたの質問に対する私の答えは、あなたが画像の作成について非常に肛門的であるならば、両方の方法を使用することです。自動インストールを作成してから、結果をsysprepします。これにより、繰り返し可能な自己文書化画像が作成されます。
また、保存された状態でディスクイメージに書き込むことができる場合は、sysprep中に実行できるスクリプトを含めることで、イメージ上にあるものを拡張できます。 OR sysprepを実行する前にシステムをバックアップし、それを拡張して、後でsysprepを実行することができます。
私は両方の方法を実行し、良い結果が得られました。
SIDの問題に関しては、常にSysprepを新しいイメージに使用する必要があります（NewSIDは機能しますが）。これにより、SIDの問題が解決されます。ただし、他にもGUIDをレジストリに書き込むアプリケーションがあり、クリーンアップする必要があります。私の頭のてっぺんから、AltirisとWSUSはこれを行う2つです。
イメージングは失われた提案です。 CentOSキックスタートの完全インストールには10分もかかりません。インストールが大幅に遅い場合は、調査する価値のある問題です。
イメージングの問題は、ビルドに変更を加えるときに、「ゴールデン」コピーを保持して更新する必要があることです。つまり、無人インストールのメカニズムが必要であり、変更するたびに、そのようなインストールを実行し、イメージを変更し（環境の自動カスタマイズのメカニズムが必要）、このコピーをゴールデンコピーにする必要があります。ゴールデンコピーに直接変更を加える場合は、何年にもわたるパッチ適用やアップグレードなどを行うと、すぐに混乱してしまいます。
システムをイメージ化する必要がある場合は、OSのデフォルトのビルドをイメージ化し、インストール後の作業（ローカルカスタマイズ）を新しいマシンごとに個別に実行する必要があります。このように、ビルドにささいな変更を加えるだけで、ゴールデンコピーを再構築する必要はありません。
ハードウェアがすべて同一ではない場合は、インストーラーの自動検出/構成を活用できます。 RedHat/CentOS 3、4、5とすべての種類のハードウェアの間で実質的に同一のキックスタート構成を使用しました。
私が今まで見た中で最悪のイメージングの結果は、ゴールデンイメージ（およびマルチパックを使用したdd）を使用してSolarisシステムをインストールするシステムでした。彼らのインストーラーとパッチ適用は非常に遅いので、これは理にかなっているように見えました。残念ながら、インストールされたシステムのハードウェアを完全に変更することは簡単ではありません。各ハードウェアタイプには、独自の黄金のイメージがありました。些細なビルドの変更では、数十のディスクに変更を加える必要があります。 2番目に悪かったのは、Kickstartを使用したLinuxグループと比較して、Windowsグループのイメージングマシン（インストーラーが機能しなくなったため、やはり妥当）でした。 Linuxグループは、たとえばDNS構成への変更を数分で展開できます。 （ポストインストールを変更するために1分、次にテストビルド、次に既存のマシンへの構成の手動プッシュ）。 Windowsグループは、各ゴールデンイメージを起動し、変更を加え、ゴールデンイメージの起動によって発生した問題を元に戻し、テストビルドを実行する必要がありました。 （また、既存のマシンを変更するために、複数のマシンのシステム構成の変更を自動化するための特別なツールを購入する必要がありました）。 Windowsグループには、変更を加えるためにゴールデンイメージを再インストールするオプションもありましたが、OSと数十のアプリケーションの手動インストールであったため、数週間のテストが必要であり、本番システムが少なくなるリスクがあるたびに、わずかに異なります。他の方法と同じです。
どちらの場合も、ゴールデンイメージを使用したWindowsとSolarisのセットアップは可能な限り最善の方法で処理されず、関係する管理者が行った選択の一部は能力の欠如を信じていたことに注意してください。しかし、合理的ではない設計から始めることは役に立ちませんでした。
キックスタートは非常にうまく機能するので、他の方法で行うことを検討する理由はありません（私はそれについて少し不満がたくさんありますが、イメージングマシンで行われた場合は1000倍悪化します）。インストールプログラムがAnaconda以外のものであり、その自動インストールがキックスタートよりも役に立たない場合は、そのディストリビューションが本当にエンタープライズでの使用を目的としていたかどうかを検討する必要があります。
ドライブのイメージングは高速ですが、ハードウェアが機能するには非常に類似している必要があります。イメージのカスタマイズも難しく、Webサーバーや電子メールサーバーなどのベースイメージが必要になります。自動インストールを使用すると、すべてのマシンを同じネットワークロケーションからインストールできますが、サーバーの種類に応じて異なるスクリプトを使用します。複数の画像を保存して作成する必要はありません。
Linux側についてはコメントできませんが、Windowsの場合、画像に対して自動化されたプロセスを使用するプロはそれほど多くないと思います。
Microsoftから入手できるガイダンスはたくさんあります ここ 。
証拠はプリンにあります。 Microsoftは現在、Vista、Windows 2008、およびWindows 7でイメージベースの展開を使用しています。上記のリンクで説明されている新しいツールとプロセスを使用すると、ドライバーを完全にサポートし、多大な労力をかけずに、Windowsを任意のHALタイプ（XPを含む）に展開できます。 。
イメージを介したWindowsの展開は、MicrosoftがSysprepを使用してイメージを展開する前に「ファクトリシール」することで完全にサポートされています。 SysprepはSIDをリセットし、基本的に新しいマシン用にイメージを準備します。
ただし、単純な理由から、（小規模な会社でない限り）完全にスクリプト化されたインストールも行うことを強くお勧めします。画像を更新する必要があるたびに、2つのオプションがあります。
1）既存のイメージを継続的に変更し、毎回再sysprepします。これにより、同じイメージに何度もパッチを適用したり、変更したり、sysprepを実行したりすると、最終的に問題が発生します。
2）画像を最初から再作成します。これは非常に望ましい方法です。ただし、スクリプトビルドがない場合は、ビルド間で多くの不整合が発生するリスクが高くなります。
したがって、要約すると：
- スクリプトビルドを使用してイメージを作成する
- 展開にイメージを使用する
これらすべての追加の問題は、Windows Vista、2008、および7がすべてイメージベースのインストールを使用するため、イメージベースのインストールとスクリプトインストールを使用するメリットがとにかくなくなったことです。
インストールするアプリケーションと、イメージを更新しないでおく期間によって異なります。
毎月かなりの数のアップデートが行われるため、イメージからボックスを復元した後でも、アップグレードする必要があります。
sIDに関して-私が知る限り、一意の秘密鍵を生成すれば十分です[ssh、https、tls、たとえばsmtp/pop3サーバーなど]これは問題なく機能するはずです。また、一意のホスト名の生成はニースになります。これはディストリビューションによって異なる場合があります。私は主にDebianを使用しており、そのOSで仮想マシンのクローンを作成するのに問題はありませんでした。
非常によく似たこの質問をチェックしてください：
https://stackoverflow.com/questions/398410/windows-disk-cloning-vs-automatic-installation-of-servers
（serverfault.comがなかったとき、しばらく前にstackoverflow.comで質問しました）。
特に、ハードウェアが異なる場合は、自動化することをお勧めします。ウィンドウについては、無人で見てください。