8件のコメント

sysprepの意味

ディスクイメージを作成し、それをクローニングする作業の中ではよくsysprepが実行されます。ここでは「なんのためにsysprepを実行するのか」「実際には裏で何が行われているのか」といったことを整理してみます。

sysprepは何をしてくれるのか

sysprepはそもそも何をしてくれるものなのか、という点に関してはTechNetに記述がありますので、引用します。

Sysprep ユーティリティは下記の 3 つの異なる用途で使用できます。

  1. ディスクの複製。Sysprep を使用してディスク複製の準備を行うと、完全にインストールされたシステムを同様のハードウェアにコピーできます。Sysprep によって、ローカル コンピュータのセキュリティ ID (SID) がコンピュータごとに一意になるように変更されます。詳細については、次を参照してください。Sysprep を使用してディスク複製用のイメージを準備する方法 (英語)
  2. 監査。 コンピュータの監査を実行した後に Sysprep を使用すると (–nosidgen コマンド ライン オプションを使用)、Sysprep によって、エンド ユーザーが Windows を実行できる準備が整えられます。詳細については、次を参照してください。Sysprep を使用して監査をインストールする方法 (英語)
  3. ミニ セットアップの自動化。Sysprep では簡易形式の GUI モード セットアップが作成されます。このセットアップでは、通常 45 ~ 60 分かかる処理が 5 ~ 6 分で済み、エンド ユーザーは使用許諾契約書 (EULA) の同意や、プロダクト キーの入力、ユーザー名および会社名の入力など、ユーザー固有の必須情報を入力するだけで済みます。このモードで Sysprep を使用するには、Windows XP をローカル コンピュータにプレインストールした後、–nosidgen パラメータを付けて Sysprep を実行し、次の手順に従います。詳細については、次を参照してください。Sysprep を使用してミニ セットアップを自動化する方法

大きく3つの用途があるということですが簡単に言ってしまえば以下の3つです。

  1. SIDの変更
  2. 監査の実行
  3. ミニセットアップの実行

が、はっきりいって2と3は普通行いません。通常はディスクの複製時におけるSIDの変更のためにsysprepが実行されると思っておいて良いでしょう。

具体的な動作ロジックに関してはsysprepではなく類似のSID変更ツールであるNewSIDに詳細に書かれており、sysprepでも同じことが行われていると考えてよいものと私は考えています。

以下NewSID v4.10から引用しました。

NewSID starts by reading the existing computer SID. A computer’s SID is stored in the Registry’s SECURITY hive under SECURITY\SAM\Domains\Account. This key has a value named F and a value named V. The V value is a binary value that has the computer SID embedded within it at the end of its data. NewSID ensures that this SID is in a standard format (3 32-bit subauthorities preceded by three 32-bit authority fields).

Next, NewSID generates a new random SID for the computer. NewSID‘s generation takes great pains to create a truly random 96-bit value, which replaces the 96-bits of the 3 subauthority values that make up a computer SID.

Three phases to the computer SID replacement follow. In the first phase, the SECURITY and SAM Registry hives are scanned for occurrences of the old computer SID in key values, as well as the names of the keys. When the SID is found in a value it is replaced with the new computer SID, and when the SID is found in a name, the key and its subkeys are copied to a new subkey that has the same name except with the new SID replacing the old.

The final two phases involve updating security descriptors. Registry keys and NTFS files have security associated with them. Security descriptors consist of an entry that identifies which account owns the resource, which group is the primary group owner, an optional list of entries that specify actions permitted by users or groups (known as the Discretionary Access Control List – DACL), and an optional list of entries that specify which actions performed by certain users or groups will generate entries in the system Event Log (System Access Control List – SACL). A user or a group is identified in these security descriptors with their SIDs, and as I stated earlier, local user accounts (other than the built-in accounts such as Administrator, Guest, and so on) have their SIDs made up of the computer SID plus a RID.

The first part of security descriptor updates occurs on all NTFS file system files on the computer. Every security descriptor is scanned for occurrences of the computer SID. When NewSID finds one, it replaces it with the new computer SID.

The second part of security descriptor updates is performed on the Registry. First, NewSID must make sure that it scans all hives, not just those that are loaded. Every user account has a Registry hive that is loaded as HKEY_CURRENT_USER when the user is logged in, but remains on disk in the user’s profile directory when they are not. NewSID identifies the locations of all user hive locations by enumerating the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList key, which points at the directories in which they are stored. It then loads them into the Registry using RegLoadKey under HKEY_LOCAL_MACHINE and scans the entire Registry, examining each security descriptor in search of the old computer SID. Updates are performed the same as for files, and when its done NewSID unloads the user hives it loaded. As a final step NewSID scans the HKEY_USERS key, which contains the hive of the currently logged-in user as well as the .Default hive. This is necessary because a hive can’t be loaded twice, so the logged-in user hive won’t be loaded into HKEY_LOCAL_MACHINE when NewSID is loading other user hives.

Finally, NewSID must update the ProfileList subkeys to refer to the new account SIDs. This step is necessary to have Windows NT correctly associate profiles with the user accounts after the account SIDs are changed to reflect the new computer SID.

NewSID ensures that it can access and modify every file and Registry key in the system by giving itself the following privileges: System, Backup, Restore and Take Ownership.

sysprepはどこで手に入るのか

sysprep自体はOSのインストールディスク内のSupport\Tools\Deploy.cab内に配置されています。ですが、基本的にはWebから最新版を取得し、それを使うのが良いでしょう。

sysprep以外のツール

sysprep実行のための目的をSIDの変更と捕らえるならば、SIDを変更するツールはsysprep以外にも存在します。有名なものを以下にあげます。

これらはどちらも明確な「SID変更ツール」です。NewSIDはWindowsを実行したまま実行することができる非常に手軽なツールであり、GhostWalkerはGhostと組み合わせて実行することが多いDosのツールです。

sysprepでもNewSIDでもGhostWalkerでもどれでもSIDを変更してくれるわけですからどれを使っても技術的にはいいはず・・・なのですが、そう一筋縄ではいかないのがこの業界の面白いところ(おかしいところ?)です。なんとマイクロソフトはsysprepを実行した状態でディスクイメージを取得したもの以外はサポートしていないのです。このあたりに関しては以下のKBで明確に言及されています。

では、かならずsysprepをつかっておけば問題ない・・・のかというとそうでもないのが困ったところです。sysprepを使う場合には以下のような問題があります。

  1. sysprepを実行するとミニセットアップが走ってしまうのでディスクイメージ複製後の初回起動に長い時間がかかり、トータルの作業時間への影響が大きい。
  2. sysprepをそのまま実行するとミニセットアップの項目に全て答えなくてはいけないため、時間がかかりすぎる、そのため、自動応答ファイルを用意、配置しておくなどの準備作業が事実上必須となり、手間がかかる。
  3. sysprep実行後のミニセットアップで「何か」が変わってしまい、完全なディスクイメージ複製ではなくなってしまう。

1,2は時間がかかるだけなのでまだいいとしても、3が致命的なんです。色々と細かいところまで仕様をつめて、細かくがんばって設定をしたマスター機のイメージを取得しているのに、「あれ、ここの設定が元に戻っちゃってるんだけど・・?」ということが発生してしまうのです。そうなると、結局また全ての変更箇所をチェックして、さらにそれをクライアント展開時の作業に盛り込んで・・・ということをする必要が出てきてしまいます。これが非常につらいのです。

NewSID、GhostWalkerであれば上記の1,2,3のデメリットは何もありません。でも、マイクロソフトノンサポートなのです。なかなか判断に困るところです・・・。

実際の案件ではお客さんとこの当たりのことを相談しながら手法を選択することになります。作業としての簡易さを取るか、マイクロソフトのサポートを取るか、ケースによってまちまちですね。

sysprepを実行しないとどうなる?

さて、それでは、sysprepやその他のツールを実行してSIDを変更しなかった場合にはどのような問題が起こるのでしょうか?

これに関しては、私もつい最近まで以下のように誤解をしていました。

  • SIDを変更しないと、ActiveDirectoryにドメイン参加したときに他のPCとSIDがバッティングしてしまい、正常にドメイン上で機能しない

しかし、実際にはこのようなことは起こらないそうです。より正確に書くと以下のようになります。

  • 動作する:ドメイン参加前のコンピューターを複製→それぞれドメイン参加
  • 動作しない:ドメイン参加後のコンピューターを複製

NewSIDのページに詳細が書かれていましたので再度引用します。要約すると、「コンピュータのローカルのアカウントのSIDが同じになってしまうので、ローカルアカウントに関してのセキュリティ上の問題が発生する」という事だそうです。

The SID Duplication Problem

The problem with cloning is that it is only supported by Microsoft in a very limited sense. Microsoft has stated that cloning systems is only supported if it is done before the GUI portion of Windows Setup has been reached. When the install reaches this point the computer is assigned a name and a unique computer SID. If a system is cloned after this step the cloned machines will all have identical computer SIDs. Note that just changing the computer name or adding the computer to a different domain does not change the computer SID. Changing the name or domain only changes the domain SID if the computer was previously associated with a domain.

To understand the problem that cloning can cause, it is first necessary to understand how individual local accounts on a computer are assigned SIDs. The SIDs of local accounts consist of the computer’s SID and an appended RID (Relative Identifier). The RID starts at a fixed value, and is increased by one for each account created. This means that the second account on one computer, for example, will be given the same RID as the second account on a clone. The result is that both accounts have the same SID.

Duplicate SIDs aren’t an issue in a Domain-based environment since domain accounts have SID’s based on the Domain SID. But, according to Microsoft Knowledge Base article Q162001, “Do Not Disk Duplicate Installed Versions of Windows NT”, in a Workgroup environment security is based on local account SIDs. Thus, if two computers have users with the same SID, the Workgroup will not be able to distinguish between the users. All resources, including files and Registry keys, that one user has access to, the other will as well.

Another instance where duplicate SIDs can cause problems is where there is removable media formated with NTFS, and local account security attributes are applied to files and directories. If such a media is moved to a different computer that has the same SID, then local accounts that otherwise would not be able to access the files might be able to if their account IDs happened to match those in the security attributes. This is not be possible if computers have different SIDs.

An article Mark has written, entitled “NT Rollout Options,” was published in the June issue of Windows NT Magazine. It discusses the duplicate SID issue in more detail, and presents Microsoft’s official stance on cloning. To see if you have a duplicate SID issue on your network, use PsGetSid to display machine SIDs.

この動きを理解した上で、「運用上問題ない」という理由からあえてSIDの変更を行わないでActiveDirectory上にクライアントを参加させている企業も実際にあるようです。

Volume Activation 2.0とsysprep

ここまでの話がWindowsXP時代の話でした。理解したうえで別ツールを使ったり、あるいは何もしなくてもいい、という話だったのですが、Windows Vista時代になるとそうも行かなくなったようです。

上記KBに書かれていることは結局「Vistaの場合にはsysprep中でCMIDを変更しているよ」ということです。そしてCMIDは重複させてはいけない値なわけです。

このことから考えると、Windows Vistaの大量展開時にはsysprepの使用が事実上必須になった、といえると思います。(Windows Vista対応GhostWalkerではCMIDも書き換えてくれるのかもしれませんが、情報を探しても見つかりませんでした)

 

この当たりの知識はクライアントの大量展開の場面では必須になってきます。きちんと理解し、きちんと運用していきましょう。

子供3人。家族優先。都内SIer勤務。Windows系中心のインフラよりの何でも屋。脱原発。 Microsoft MVP for Cloud and Datacenter Management.

8件のコメント

  1. とてもよくまとまった記事で参考になりました。
    昔、仕事でWindowsXPの大量展開をしたときに、この記事があればなぁと思いましたが。

    sysprepのデメリットとして挙げられている、

    3.sysprep実行後のミニセットアップで「何か」が変わってしまい、完全なディスクイメージ複製ではなくなってしまう。

    というのは私も身に覚えがあって、Default User のプロファイルが
    Administratorアカウントのプロファイルで上書きされてしまう、という問題にあたった事があります。
    バグだと思うので、最新版の sysprep では直っているのかもしれませんが。
    いずれにしても、使いづらいツールですね。

  2. slmgr /rearm でCMIDは初期化できますよ。
    KSM でライセンスが払いだされない現象を回避した時に使いました。
    (sysprep がかかっていないイメージで複製したのが原因です)
    TechNetに載っています。slmgrのヘルプには書かれていませんが、、、

    1. ぞえさん、情報ありがとうございます!

      確かに!こちらの情報ですね。

      Run sysprep /generalize or slmgr /rearm to reset the client computer ID (CMID) and other product-activation information. Otherwise, each client computer looks identical, and the KMS host does not count them as separate KMS clients.

      http://technet.microsoft.com/en-us/library/dd772270.aspx

      これはいいですね。有益な情報ありがとうございます!

  3. White Lionさん。コメントどうもありがとうございます。

    情報が役に立ったということで、非常にうれしく思います。

    情報もありがとうございます。CMIDの書き換えは技術的に(ライセンス的に?)難しいのかもしれませんね。sysprepをうまく付き合う方法を考えていかなくてはいけなそうですね…。

  4. こんにちわ。
    White Lionと申します。

    こちらの情報がとても役に立ちました。
    ありがとうございました。

    ここで一つ情報を・・・
    「Volume Activation 2.0とsysprep」の所で「Windows Vista対応GhostWalkerではCMIDも書き換えてくれるのか」とありますが、CMIDの書き換えは行えないようです。
    私も期待をしていたのですが、残念な結果となり、MSのSysprepを使用しなければならなくなりそうです。
    ちなみにGhostのバージョンは、GhostSolutionSuite2.5です。

コメントを残す

メールアドレスが公開されることはありません。