ディスク署名／識別子の重複実話（とSysprepが重要な理由）：その知識、ホントに正しい？ Windowsにまつわる都市伝説（105）（1/2 ページ）

「マシンSIDの重複神話」をご存じでしょうか。この神話についてはすぐ説明しますが、仮想マシンのコピーからクローンを次々に作成する場合に、知っておくべき事実です。これになぞらえて、今回はOSのインストール先ディスクに書き込まれるディスク署名が、競合（重複）によって書き換わってしまったときのトラブルの話を紹介します。

[山市良，テクニカルライター]

Windowsにまつわる都市伝説

マシンIDの重複神話――実は、マシンIDが一意であることは重要ではない

　「マシンSIDの重複神話」（原題：The Machine SID Duplication Myth［and Why Sysprep Matters］）は、「Windows Sysinternals」の生みの親の一人であり、現在はMicrosoft Azureの最高技術責任者（CTO）であるマーク・ルシノビッチ氏が、2009年に自身のブログに投稿した記事です。この記事は、Windows Sysinternalsでかつて提供されていた「NewSID」ユーティリティーの提供終了に合わせて、その理由と「Sysprep（System Preparation Utility）」の重要性について説明したものです。

• マシンSIDの重複神話（Windows IT Pro Center）

　マシンSID（Machine Security Identifier：マシンセキュリティ識別子）は、Windowsのセットアップ時に自動生成される（おそらく世界中で）一意の識別子であり、ローカルユーザーやグループのSIDのベースになるものです。Active Directoryドメイン環境では、1台目のドメインコントローラーのマシンSIDが、ドメインSIDのベースとして使用されます。

　Windowsコンピュータが持つこのマシンSIDは、ネットワーク上で一意でなければならないと長い間信じられてきましたが、「マシンSIDの重複神話」は実際のSIDを見ながら、ローカルコンピュータのマシンSIDはローカルでのみ使用されて、リモートから参照されることはないため、クローン展開した同じマシンSIDを持つコンピュータがあっても、問題にはならないことを示しています。

　Windowsの「システム準備ツール」（Sysprep.exe）は、マシンSIDの再作成を指示します。「マシンSIDの重複神話」でもSysprepでイメージを準備することがベストプラクティスであると強調されていますが、それはマシンSIDの再生成よりもむしろ、その他にコンピュータ固有の情報をリセットのために重要なのです。言い換えるなら、場合によってはSysprepの実行なしで、次々にクローンを展開することも不可能ではないということです（ただし、コンピュータ名の変更など、調整は必要です）。

　仮想化環境が一般的になると、仮想マシンの構成と仮想ハードディスク（Hyper-Vの場合はVHD／VHDX）のマスターのコピーからエクスポート／インポート機能などを利用することで、次々に仮想マシンを展開することが可能になりました。もちろん、Sysprepでマスターイメージを一般化しておくことがベストプラクティスですが、テスト環境を準備する場合にはSysprepを実行することなく、単純にコピーして利用することができます。

　前置きが長くなりましたが、今回の話題は「マシンSIDの重複神話」とは全く関係ありません。Hyper-V環境において、Windows仮想マシンのコピーから新しい仮想マシンを展開するときに、仮想ハードディスク（VHD／VHDX）をオフラインメンテナンスする場合があると思います。今回の話題は、その際に遭遇する可能性のある「ディスク署名／識別子の競合（重複）」問題です。このことを知らないと、オフラインメンテナンス後にその仮想ハードディスクから仮想マシンを起動できなくなるかもしれません。

ディスク署名が書き換わると起動不能になる、だから“安全装置”がある

　Windowsは標準で、Hyper-Vの仮想ハードディスク形式であるVHDおよびVHDXをローカルシステムに接続し、物理ディスクと同じようにボリュームやファイルシステムを扱うことができます（VHDのローカルマウントは、Windows 7／Windows Server 2008 R2からサポート）。VHD／VHDXのローカル接続と切断操作は、「エクスプローラー」（Explorer.exe）や「ディスクの管理」スナップイン（Diskmgmt.msc）、「DISM」コマンド（attach vdisk／detach vdisk）、Windows PowerShellコマンドレット（Mount-WindowsImage／Dismount-WindowsImage）で行えます。

　ファイルコピーはもちろん、DISMコマンドを使用してマウントしたディスクに対して更新プログラムを適用することもできます。また、Windowsの機能（Windows Serverの役割と機能）を有効化／無効化することも可能です。Hyper-Vで仮想マシンを作成、管理する人は、知っておいて損はないテクニックです。例えば、仮想マシンでWindows Updateによる更新がどうしても成功しない場合でも、オフラインで更新プログラムをインストールすることで解決したりします。その一例を以下の記事で示しました。

• 最近のWindows Updateは、本当にどうかしている（と思う）（連載：山市良のうぃんどうず日記 第103回）

　今回の説明のために、Hyper-Vで作成した仮想マシンにWindows 10をインストールしてエクスポートしたものを、同じHyper-Vホストにインポート（コピー指定）して、全く同じ構成の2台の仮想マシンを作成しました（画面1）。

画面1　エクスポートされた同じ仮想マシンをインポートして作成した、同一構成（仮想マシンのハードウェア構成およびゲストOSのインストール）の2台の仮想マシン。スタンドアロンで利用する限り、Sysprepを実行していなくても特に問題は発生しないはず

　これらの仮想マシンはスタンドアロン（ワークグループ）構成であるため、「マシンSIDの重複神話」で説明されている通り、問題は生じません（ネットワークアダプターのMACアドレスおよびIPアドレスは動的割り当てのため異なりますが、相互に通信する場合は、コンピュータ名を変更するべきです）。

　2台の仮想マシンを停止して、OSがインストールされている仮想ハードディスク（VHDX）をエクスプローラーでダブルクリックしてローカルに接続します。1つ目の仮想マシンの仮想ハードディスクは問題なくマウントされ、仮想マシンのCドライブだったボリュームに別のドライブ文字が割り当てられ、エクスプローラーで開かれます。次に2つ目の仮想マシンの仮想ハードディスクを同じようにマウントしようとすると、次のようなエラーメッセージが表示されます（画面2）。

ディスクイメージは初期化されていないか、認識できないパーティションが含まれているか、またはドライブ文字が割り当てられていないボリュームが含まれています。ディスクの管理スナップインを使用して……

画面2　同じ仮想マシンのコピーから作成した2台の仮想マシンの仮想ハードディスク（VHDX）を同時にマウントしようとすると、後からマウントしようとしたものが失敗する

　エラーメッセージにある通り、「ディスクの管理」スナップインを開いて確認してみると、後から接続した仮想ハードディスクがオフライン状態となっており、その理由について次のようなメッセージが表示されました。

オンラインである他のディスクと署名が競合しているために、ディスクはオフラインです

　Windows（Windows Vista以降）は、ボリュームのようなオブジェクトを対応するディスクにマップするために、そのコンピュータに接続されたディスクで一意である「ディスク署名（識別子）」を内部的に使用しています。

　マスターブートレコード（MBR）ディスクの場合は、4バイトのディスク署名（例：5F1B2C36）がディスクの開始セクター（のオフセット0x1B8から4バイト）に書き込まれています。GUIDパーティションテーブル（GPT）ディスクの場合は、16バイトのGUID形式（例：BAF784E7-6BBD-4CFB-AAAC-E86C96E166EE）のディスク識別子が開始セクター（のオフセット0x238から16バイト）に書き込まれています。任意のディスクバイナリエディタを使用すれば、ディスク署名／識別子を確認できます。

　Windowsの「DISKPART」コマンドを使用すると、選択したディスクのディスク署名／識別子を参照できます。次のように、「LIST DISK」でディスク番号を確認し（2行目）、「SELECT DISK」で目的のディスクを選択後（3行目）、「UNIQUEID DISK」を実行します（4行目）。先ほどの仮想ハードディスクの場合、マウントされたディスクとオフライン状態で接続されたディスクが同じディスク署名／識別子を持ちます（画面3）。

DISKPART
> LIST DISK
> SELECT DISK <ディスク番号>
> UNIQUEID DISK

画面3　仮想マシンのディスクは「ディスク9」と「ディスク10」。これらのディスクは、同じディスク署名／識別子を持つことが分かる（この例はMBRディスクのためディスク署名）

　「ディスクの管理」スナップインを使用してオフライン状態のディスクを右クリックし、「オンライン」を実行すると（またはDISKPARTのONLINE DISKコマンドを実行すると）、ディスク署名／識別子の競合を無視して強制的にマウントさせることが可能です。その場合、強制的にマウントされたディスクのディスク署名／識別子は、競合しないように新たなディスク署名／識別子に変更されます（画面4）。

画面4　ディスク署名／識別子の競合を無視してディスク10をオンラインにすると、オンラインにしたディスクに新しいディスク署名／識別子が書き込まれる。この例では、ディスク署名が「62988157」から「AA88B04」に変更されている

　ここまでの作業は、Hyper-Vの第1世代仮想マシンで進めてきました。第1世代仮想マシンはBIOSベースのレガシハードウェアであり、OSがインストールされているボリュームはMBRディスク上にあります。同じディスク署名を持つ仮想ハードディスクのローカルマウントを強行したことで、2つ目の仮想マシンのディスク署名は書き換わってしまいました。ローカルマウントされた仮想ハードディスクを切断し、2つの仮想マシンを起動してみましょう。すると、ディスク署名が書き換わった2つ目の仮想マシンが以下のエラーで起動しなくなります（画面5）。

要求されたデバイスが接続されていないか、デバイスにアクセスできません。
エラーコード：0xc000000e

画面5　ディスク署名／識別子が書き換わると、Windowsのブート環境が壊れる

　選択可能な回復オプションとして、再実行（［Enter］キーを押す）や、スタートアップ設定の表示（［F8］キーを押す）がありますが、どちらもエラーとなり、回復することはできません。前述のように、Windowsはディスク署名／識別子を使用して、ボリュームをディスクに対応付けています。ディスク署名／識別子が変わったことで、WindowsブートマネージャーとWindowsブートローダーの参照先を発見できなくなったのです。回復オプションを提供する「Windows回復環境」も使えないということは、回復オプションが存在する場所も行方不明ということです。

　Windowsが同じディスク署名／識別子を持つディスクをマウントせずにオフライン状態で接続するのは、ブート環境を破壊する可能性があるため、それを回避するための“安全装置”だったというわけです。なお、データディスクとして使用するつもりで仮想ハードディスクをコピーし、同じ仮想マシンに接続した場合は、同様にディスク署名／識別子が競合するため、オフライン状態で接続されることがあります。その場合は、OSディスクのような影響はないので、強制マウントしてディスク署名／識別子を書き換えてしまっても問題ないでしょう。