クライアント展開時の一般化 (Generalize) した Sysprep の実行について自分なりのメモをまとめてみたいと思います。
# 一般化 (Generalize) → Sysprep を Generalize したもの / 専用(専門) 化 (Specialized) → Sysprep を実行していない / Sysprep で Generalize していない
以下の情報をベースにまとめています。
マシン SID の重複神話
基本方針としては「複製されたシステムを利用する場合、Sysprep をしていない場合はサポートが受けられない」ことを念頭においておく必要があるかと。
Sysprep に関連する技術情報としては以下もとても参考になります。
Sysprep の機能と既知の問題について
プログラムの展開に影響する、Sysprep 使用時の既知の問題
イメージ展開時の Sysprep の必要性に関してはこちらに。
Windows XP インストールのディスク複製に関するマイクロソフトの方針
日本語の情報では Windows XP となっていますが英語の情報では、Windows 7 / Windows Server 2008 R2 も対象として記載されています。
The Microsoft policy for disk duplication of Windows installations
今回 SID を取得するために、PsGetSID という Sysinternals のツールを使用しています。
# PSTools に含まれています。
サーバーの Sysprep については、
サーバーの役割の Sysprep サポート
を参照されるとよろしいかと。
■ドメインにクライアント展開時に意識する SID
ドメインにクライアントを展開する際に意識する SID (Security Identifiers) としては以下の種類があるかと思います。
- マシン SID
- ローカルユーザー (グループ) SID
- ドメイン SID
- ドメインユーザー (グループ) SID
- コンピューターアカウント SID
マシン SID は各コンピューターのローカルに割り当てられている SID となります。
この SID はドメイン参加とは関連なく割り当てられているものになるので、ワークグループ環境のコンピューターにも設定がされています。
以下が今回の検証環境のマシン SID の値です。
一般化した Sysprep でクリアされる SID はこのマシン SID の値となります。
ローカルユーザーの SID はマシン SID + RID (Relative Identifier) の形式となります。
Administrator の RID は 500 で固定となっているため、以下の値となります。
一般化した Sysprep を実行しない場合は、本来各コンピューターで一意になるはずの、これらの SID が重複した状態となるようですね。
マシン SID の重複神話 には以下のように書かれています。
言い換えると、コンピューターへのアクセスを最終的に制御するのは、SID ではなく、アカウントのユーザー名とパスワードだということです。リモート システムのアカウントの SID を知っているだけでは、コンピューターやコンピューター上のリソースにアクセスすることはできません。
各コンピューターのマシン SID が重複して、ローカルユーザーの SID が同じになったとしてもそれだけではパススルーはできないようですね。
ドメイン SID はドメイン環境下でドメインに対して割り当てられる SID になります。
上記のマシン SID のコンピューターは Windows Server 2008 R2 を使用していますので、この環境をドメインコントローラーにしてドメイン SID を取得してみます。
ドメイン SID = マシン ID となるようですね。
この環境に 2 台目のドメインコントローラーを追加してみます。
ドメインコントローラー化する前のマシン SID が以下になります。
ドメインコントローラー化した後のマシン SID がこちら。
ドメインコントローラーにすることでマシン ID = ドメイン SID となるようですね。
ドメイン SID は最初にドメインコントローラーにしたマシン SID が使われるようです。
このことが、マシン SID の重複神話に以下のように記載されています。
最初に書きましたが、このルールには 1 つの例外があります。それは DC 自体です。各ドメインは、ドメインの最初のドメイン コントローラーのマシン SID から取得される一意のドメイン SID を持ち、そのドメインの DC のすべてのマシン SID はそのドメイン SID と一致します。したがって、これは、マシン SID が他のコンピューターから参照されるケースと言うことができます。つまり、ドメインのメンバー コンピューターは、DC、つまりはドメインのマシン SID と同じマシン SID を持つことができません。
ドメインユーザーの SID に関してはドメイン SID + RID となるようです。
最初のドメインコントローラーのコンピューターの Sysprep していないイメージを展開しなければこの SID は重複しないようですね。
コンピューターアカウントの SID はドメインに参加時に割り当てられますので、同一のマシン SID が使用されていてもユニークになります。
ドメインコントローラーはマシン SID は同一になっていますが、コンピューターアカウントは異なるものが設定されています。
コンピューターアカウントのSID にもドメイン SID が使用されているのが確認できますね。
同一のコンピューター名を使用しないのであればコンピューターアカウントの SID は重複しないかと思います。
マシン SID で (コンピューターアカウント SID ではなく) 何かを制御している場合に Sysprep でマシン SID をリセットしなかったときの問題が発生しそうですね。
通常のセキュリティはユーザー名とパスワードがベースになっているようなのでマシン SID 重複による影響はなさそうですが、マシン SID で何かを制御しているかどうかは使用しているソフトがどういう仕様になっているかが分からないとどうしようもないので、重複していて確実に問題がないとは言えなさそうですよね…。
今後、導入したアプリでマシン SID を使っている可能性がないとは言えないですし。
■コンピューター固有情報の削除
一般化した Sysprep ではマシン SID の情報だけでなくコンピューター固有情報のリセットも行っています。
コンピューター固有情報はその名の通り、そのコンピューター内で保持している本来はユニークになる情報のことですね。
マシン SID の重複神話では WSUS が例に出ていますので、私も WSUS を使用して検証してみたいと思います。
まずは一般化した Sysprep を実行していない環境を 2 台準備し、ドメインに参加した状態にしています。
# 異なるコンピューターアカウントを使用している状態にするため、コンピューター名だけは変更しています。
一般化した Sysprep を実行していないのでマシン SID は重複していますが、
コンピューターアカウントはユニークなっています。
コンピューターアカウントの一意性を出すためにマシン SID は使われていないようですね。
それでは、これらのコンピューターを WSUS に登録したいと思います。
AD 側のグループポリシーで Windows Update の参照先を LAN 内の WSUS に設定します。
あとは、各コンピューターで Windows Update の更新の確認をするか、[wuauclt /detectnow & wuauclt /reportnow] を実行します。
WSUS 構築直後ですので、まだ管理されているコンピューターはありません。
それでは、[-1] となっているコンピューターで Windows Update の更新の確認を実行してみます。
1 台登録されているのが確認できますね。
それでは [-2] となっているコンピューターで Windows Update を実行してみます。
[-1] が消えて、[-2] が追加されているのが確認できますね。
これはマシン SID ではなくコンピューター固有情報が重複しているために発生しれている現象になります。
WSUS に登録されているコンピューターは SQL Server 上では、SUSDB データベースの [tbComputerTarget] というテーブルに格納されています。
このテーブルの中は以下のようになっています。
ComputerID という一意識別子があるのですが、コンピューター固有情報をリセットしていない環境ではこの値が一致してしまっており、同一のコンピューターとして認識され、一台しか登録がされていないという状況が発生しているようです。
# 初回の Windows Update 時に値が設定されるようで、複製をする前に Windows Update をしていなければ重複しないかもしれないです。(未検証です
この ComputerID ですが、レジストリの [HKLMSOFTWAREMicrosfotWindowsCurrentVersionWindowsUpdate] の [SusClientId] に登録がされています。
こちらが [-1] のコンピューターの登録内容になります。
こちらが [-2] のコンピューターの登録内容になります。
両方のコンピューターで値が重複しているのが確認できますね。
それでは、[-2] で一般化しない Sysprep を実行してみます。
一般化していないのでマシン SID は変わっていません。
それでは先ほどのレジストリ値はどうでしょう。
レジストリの値も変わっていませんね。
[-1] で [wuauclt /ResetAuthorization /detectnow] を実行して WSUS に登録して、[-2] を再登録しようとしても、ID が重複している状態は変わりませんので一台しか登録することができます。
それでは、一般化した Sysprep を実行してみます。
マシン SID は一般化しているので変わっています。
レジストリに関しても値が変わっているのが確認できますね。
この状態で [wuauclt /ResetAuthoriztaion/ detectnow] を実行して登録状況を確認してみます。
先ほどとはレジストリの値が変わっていますので、複数の端末が登録できていますね。
今回の内容であれば一般化した Sysprep を実行しないでも以下の技術情報をベースに解決ができると思うのですが、それぞれを調べるのは大変ですよね。
Windows 2000、Windows Server 2003、または Windows XP のイメージを使用してセットアップされた Windows 2000 ベース、Windows Server 2003 ベース、または Windows XP ベースのコンピューターが WSUS コンソールに表示されない
マシン SID よりはコンピューター固有情報がクリアされないことによる問題の方が発生する頻度が高いのかもしれないですね。
マシン SID の重複神話では、
長い間、SID の重複の問題が疑問視されていなかったことには少し驚きますが、誰かしらがこの問題について正確に理解しているのではないかと誰もが思っていました。残念なことに、NewSID が実際に役立つことはありませんでしたし、提供を停止した今、惜しいと思うこともありません。Sysprep は、ほかにもマシン固有の状態をリセットします。それが重複していると、Windows Server Update Services (WSUS) などの特定のアプリケーションに問題が発生する可能性があるためです。したがって、マイクロソフトのサポート方針として、今後も複製されたシステムは Sysprep を使用して一意であることが要求されることに注意してください。
The Microsoft policy for disk duplication of Windows installations では、
We support the following operating systems that are prepared by using the Sysprep utility and then imaged
と書かれていますので、一般化した Sysprep で情報をリセットし一意にしないとサポートが受けられなくなる可能性が非常に高いですので、この点は注意しないといけなさそうですね。