GPOを作成しようとすると「このセキュリティID はこのオブジェクトの所有者として割り当てられない可能性があります」と言われて作成できない

ここしばらくずっと困ってたのがやっと解決したのでメモ。

ドメインコントローラに domain\administrator でログイン、グループポリシーの管理を開いて新しいグループポリシーオブジェクトを作成しようとすると、何故か「このセキュリティID はこのオブジェクトの所有者として割り当てられない可能性があります」というエラーが発生、GPO が作成できませんでした。

解決策は social.microsoft.com のこのスレッドの最後にありました。

1. グループポリシーの管理を開いて、既存の「Default Domain Controllers Policy」を選択、編集を開始
2. 「コンピュータの構成」「ポリシー」「Windows の設定」「セキュリティの設定」「ローカルポリシー」「ユーザの権利の割り当て」を選択
3. 「ファイルとディレクトリの復元」を開き、Administrators グループがあるか確認、無ければ追加する
4. gpupdate /force を実行してGPOを有効にする
5. 一度サインアウトして、サインインを行う

なんでやねん!って思わず突っ込みそうになりましたが確かに Administrators を追加するこの手順で直りました。

日本語では見つけられなかったので、備忘録代わりに。

Windows Server 2016 仮想化ベースのセキュリティ

Windows Server 2016 では様々なレイヤーでのセキュリティの強化が実装されていますが、その中の一つに「仮想化ベースのセキュリティ」と呼ばれる一連の機能があります。

機能名としては「Device Guard」や「Credential Guard」など呼ばれるものです。その詳細についてはマイクロソフトのこちらのページをご参照頂ければと思います。

ポイントとしては上記ページの以下の図が分かりやすいかと思います。

https://technet.microsoft.com/ja-jp/library/mt483740(v=vs.85).aspx より引用

これは Credential Guard の例ですが、ドメイン環境でのサインイン時に、ActiveDirectory から得られた認証情報(Credentials)は、通常ですと OS のメモリ空間のどこかに存在します。このため、カーネル内を含めメモリを読むことができる特権を得られれば、それをメモリから読み取り、奪い取ることができてしまいます。そのアカウントのパスワードを知らずとも、得られた認証情報をつかうことでそのユーザーとしてドメイン内のリソースへアクセスできてしまいます。

Credential Guard を有効にすると、Hyper-V による仮想化を利用して認証情報が切り離されます。 (厳密には異なりますが)ざっくりとしたイメージとしては本来の Windows Server を実行する仮想マシンと、認証情報だけを抱えた小さな仮想マシンの2つが Hyper-V にのっかっているという感じです。

仮想マシン同士のメモリ空間はハイパーバイザーによって分断されており、ある仮想マシンのメモリ空間の端から端までアクセスしても、他の仮想マシンのメモリ空間にはアクセスできません。これらは Intel-VT や SLAT といったハードウェアの機構により実現されており、ハイパーバイザー上のゲストOSやアプリケーションでは越えることができません。
つまり、別空間に切り離された認証情報を従来と同じ方法では盗めない、切り離された秘匿情報は正当なAPIを通じてのみアクセスが許可されます。

これが、Credential Guard です。また、仮想化ベースのセキュリティの一例となります。


要件は冒頭のページを見て頂ければと思いますが、ざっくりとは以下の感じです。

• OS: Windows 10 Enterprise ないしは Windows Server 2016
• CPU: 64bit CPU, Intel VT (AMD-V)および SLAT対応
• TPM: 1.2 ないし 2.0 対応 (1.2の場合は Windows10 1511以降)

あと、セキュアブートも必要となってきます。

物理PC上での利用が前提(Windows 10 の場合仮想マシン上はサポート外)ですが、Windows Server 2016 と Windows 10 で可能となった、nested Hyper-V を使えば仮想マシン上でも試すことはできます。

そこで、実際に仮想マシンで Credential Guard を有効にしてみました。


● 事前準備

まず、Hyper-V 上で G2 仮想マシンを作成します。
従来型の G1仮想マシンは BIOSベースのファームウェアで、ブートドライブとしてIDEのエミュレーションが、デフォルトのNICもエミュレーションベースのものになります。物理PCとの互換性は高いのですが、性能的に制約がある次第です。

G2 仮想マシンは UEFIベースのファームウェアで稼働し、IDEやNICのエミュレーションをしません。高性能の代わりに Hyper-V に対応していないOSはインストールできません。もっとも、Windows ならば Vista 以降、Linux でも最近のものなら標準で Hyper-V 向けのデバイスドライバーを持っており後から統合サービス(IC)をインストールしなくても良くなってます。

あと、重要なポイントとして、G2仮想マシンは UEFI上でのセキュアブートを実現しているという点です。今回はセキュアブート環境を用意したいために、G2を選択しています。


Windows Server 2016 をインストールして、Windows Update の実行など一般的な処理をおこなっておきます。別に ServerCore でも構わないのですが、後での動作確認を楽にするためにデスクトップエクスペリエンスありを利用しております。

一旦シャットダウン後、Enable-NestedVM.pl を利用して仮想マシン上での Hyper-V の実行を許可します。方法がよく分からない場合は、こちらの動画を参照してください。

その後、仮想マシンを再び起動し、Hyper-V の役割を有効化します。
以前の Windows10 ではこのときに「分離ユーザーモード」 の機能も有効化する必要がありました。
が、Windows Server 2016 および最近の Windows10 では分離ユーザーモードの選択肢が存在しません。OSに標準組み込みになったので特に選択する必要眼漠なったようです。

Hyper-V の役割のインストールに伴い再起動が発生するので、一回再起動しておきます。

これで、Credential Guard を有効化するための準備は完了です。


● Credential Guard の構成

Credential Guardの設定はグループポリシーを通じて行います。今回はドメインに参加していない1台だけのため、mmc.exe を起動、スナップインの追加でグループポリシーの編集を追加、ローカルコンピューターポリシーを編集しますが、ドメイン環境下の場合、GPOを配布することでドメイン下のメンバーサーバなどにまとめて一気に設定をすることもできます。

ともあれ、設定するポリシーは以下になります。

「コンピューターの構成」->「管理テンプレート」->「システム」->「DeviceGuard」の下に、「仮想化ベースのセキュリティを有効にする」があります。これをダブルクリックしてます。

まずは上のラジオボタンを未構成から「有効」にします。

次に、「プラットフォームのセキュリティレベルを選択する」を今回は「セキュアブートと DMA保護」から、「セキュアブート」だけにします。前者のDMA保護は VT-d (ないしは IOMMU) で実現されていますが、Hyper-V上の仮想マシンではVT-d/IOMMUのエミュレーションは行われていないためです。

OKをおして保存後、ポリシーを確実に読み込ませるために、OSを再起動しておきます。
ドメイン環境でGPOをドメインコントローラから配信している場合は、再起動前に gpupdate /force を実行しておくといいかもしれません。
(GPOは更新されて即時に展開されるわけではなく、ある程度時間をかけて浸透していきます。クライアント側から gpupdate を実行することで、強制的に最新のポリシーをドメインコントローラに取りに行かせるわけです。もちろん、検証や数台のサーバからの実施ならばいいのですが、大量のサーバから gpupdate で即時取得を繰り返すのはドメインコントローラに負荷がかかるのでご注意ください。)
 
これで構成は完了です。


● Credential Guard の確認

では実際にメモリをダンプして Credentail を読み取れなくなったか確認してみましょう...、ではさすがに洒落にならないので、UIから動作確認します。

コマンドラインなどから msinfo32.exe を実行すると、システム情報というウィンドウが立ち上がります。左側のツリーでは標準選択されてている「システムの要約」をそのまま、右側の一覧をスクロールダウンしてくと、最後の方に Device Guard から始まる情報がいくつか記載されています。

まず、「Device Guard 仮想化ベースのセキュリティ」 が「実行中」になっているかがポイントだ。構成されていない場合はこれが「無効」になっており、構成されていても条件が整わなくて起動していない場合は「有効(停止中)」などになります。

次の、「Device Guard の必要セキュリティプロパティ」 が、仮想化ベースのセキュリティを実行させるにあたり必要となる機能で、その次の「Device Guard の利用可能なセキュリティプロパティ」が、実行している環境が提供できる機能の一覧になります。

つまり、必要側に書かれてる機能が利用可能側に記載がない場合、仮想化ベースのセキュリティは機能不足で稼働しないものになります。

構成済みの Device Guard セキュリティサービス が、GPOなどで構成したサービスです。ここでは Credential Guard が記載されていることが分かります。一方、その下の「実行中の Device Guard セキュリティサービス」が実際に稼働しているサービスを指します。こちらも Credential Guard の記載がある、つまりは Credential Guard が有効である事が分かります。

また、上から9行目ほどに「セキュアブート」がありますが、これが「有効」なものは、UEFIからはじまりブートローダー、OS、デバイスドライバと起動時から順に読み込まれていったモジュールがすべて有効な電子署名が施されている、改ざんされていないことを示します。


●うまく構成できていない例

たとえば Hyper-V は有効にしたものの、GPOをまだ設定していない場合には、以下のように「仮想化ベースのセキュリティ」 が単に「無効」と表示されます。

プラットフォームのセキュリティレベルを「セキュアブートとDMA保護」にしたにも関わらず、VT-d, IOMMU などがない場合は、以下のようになります。

必要なセキュリティプロパティに「DMA保護」 が入っていますが、その下の利用可能なセキュリティプロパティに「DMA保護」はありません。条件を満たさなかったためセキュリティサービスとして Credential Guard が表示されていないのが分かります。


また、VMware Fusion で構成を試してみた例がこちらです。Fusion でも nested VM を有効にして、Hyper-V をインストールしたのですが、Credential Guard が有効になってません。よくよく見るとDMA保護だけではなく、仮想化の基本サポート以降の機能がまったくありません。従って、Credential Guard は元より、仮想化ベースのセキュリティも実行されていません。

そもそも、VMware の仮想マシンではセキュアブートが使えません。
例の上から9行目のセキュアブートの項目を見ても「サポートされていません」になっているのが分かります。

セキュアブートが有効でない都言うことは、OS起動時のブートローダを改ざんしたり、間にプロセスを介入させることで仮想化ベースのセキュリティを有効化する前に悪意あるコードを混ぜ込むことが可能となってしまいます。いくらハイパーバイザーでセキュリティを保とうとしても、あく怒るコードの方が先にハイパーバーザーとして起動されてしまう恐れがある訳です。

そのためか、これまでみてきたように仮想化ベースのセキュリティでは、セキュアブートが「必要なプロパティ」として要求されています。

vSphere 上での Nano Server のインストール

この記事は、vExperts Advent Calendar 2016 に参加しています。


Windows Server 2016 では Nano Server と呼ばれる、軽量化されたOSが含まれています。Windows Server 2016 をベースに新しいアプリケーションやインフラストラクチャーを対象に、そのための機能に研ぎ澄ましたもので、稼働させるだけなら数百MB程度のメモリとディスクがあれば動きます。

Windows Server 2016 そのものも 512MB が最低必要量になってますが、インストール時には 800MB 程度、デスクトップエクスペリエンスを備えるならやはり 2GBが必要となります。ストレージ容量なら32GBが最低容量となります。

一方、Nano Server は「研ぎ澄まされ」ているため、用途としては不適となります。たとえばローカルコンソールで操作できることは本当に最低限のため、リモート管理が必須となります。役割や機能もフルインストールの Winodows Server がサポートするものが全てサポートされるわけではありません。ライセンスから見ても、アップデートがCBBモデルなのもありSAが必須となります。

こうしたことから、インストーラーでぽんとインストールできるわけではありません。

Windows Server 2016 のインストーラーでは、デフォルトのの Server Core か、
デスクトップエクスペリエンス付きかの選択肢しかない

むしろ、インストールしてから用途に向けてセットアップしていくのではなく、コマンドラインで
「必要な機能を組み込んでいく」必要があります。

インストール手順自体はこちらにありますが、少々敷居の高いものとなっています。
では、VMware の仮想マシン上にインストールするにはどうすればいいでしょうか? ちょっと試してみました。

● EFI か、BIOSか?

まず最初に決めるべき事は、ファームウェアを従来のPC-BIOSか、UEFIにするかです。PC-BIOS
はこれまで使われてきたファームウェアで、リアルモードで動作するものになります。UEFI はより新しいファームウェアで、ブート前の状態でより多くの機能を提供できるものです。

Nano Server をインストールするにはどちらでも構いません。多くの VMware 製品は普通に仮想マシンを作ると PC-BIOS を設定します。VMware Fusion については macOS をゲストOSにしない限り、EFI は選択されません。(ユーザーインターフェイスから設定できない。ただし vmx ファイルを直接書き換えることで設定可能)

ここでは、最初に BIOS でのインストールを、次に EFI でのインストールを試してみます。

● Nano Server のインストール (BIOS編)

まず、仮想マシンを作成する。特に普通に作れば良い。今回はメモリは 1GB程度にしました。
仮想ディスクのサイズも1GB以上ならば問題ありません。

ESXi の仮想マシンのプロパティ
「リソース」の「起動オプション」にてファームウェアの指定が可能

注意点としては、ゲストOSとしては「Windows Server 2016(64bit)」を選択すると言うことぐらいです。

仮想マシンの作成画面より
OSは Windows Server 2016 (64bit) にする

できあがった仮想マシンに Windows Server 2016 のインストールメディアを認識させ、こちらから起動します。

Windows Server 2016 のインストールメディアから起動
通常はここでキーボードや言語の選択を行いウィザードを進めるが
Nano Server の場合はここで一旦停止

この画面が表示されたところで「SHIFT+F10」をおす。すると、コマンドプロンプトウィンドウが開きます。

Windows Server のインストールメディアでは、SHIFT-F10 でコマンドプロンプトウィンドウが開く
ここでは、D: ドライブの内容を dir で確認している

デフォルトの状態では、X:ドライブに一時的な起動ドライブが作成されております。インストールメディア自体はD:ドライブにマウントされており、初期状態では仮想ディスクはフォーマットもされていないため、どこにもマウントされていません。
D:\NanoServer フォルダ以下に、Nano Server の素の状態のイメージ(NanoServer.wim) と、デバイスドライバや役割、機能を備えたパッケージ(*.pkg)があります。


さて、ここからインストールを行います。インストールで行わなければならないことは、以下の4つです。

1. ディスクのパーティション作成と、フォーマット
2. Nano Server イメージの展開
3. その他必要なパッケージのインストール
4. 起動パーティションとして指定

・パーティションの作成

パーティションの作成とフォーマットは diskpart コマンドで実施します。まず、「diskpart」と入力し実行して、diskpart コマンドを起動します。このとき、「DISKPART>」のプロンプトが出ずハングする場合があります。その時は Ctrl-C をおして diskpart コマンドを終了し、しばらく待ってから再度実行するとプロンプトが出てきます。

diskpart コマンドを実行

DISKPART> のプロンプトが出たら、以下のコマンドを実行します。

• select disk 0
• create partition primary
• format quick fs=ntfs label="nano server"
• assign letter=c
• active

select disk 0 で接続されている最初のドライブを選択します。
次の create partition で選択されたドライブに新しいパーティションを作ります。このとき、 primary を指定することでMBR のプライマリパーティションとしてパーティションが作成されます。
(MBRでは、そのままだと最大4つのパーティションしか作成できない。これらを「プライマリパーティション」と呼ぶ。4つ以上パーティションが必要な場合は、そのうちどれかを入れ子にして、別途パーティションテーブルを作成、分割する。この入れ子で作成されるパーティションを「論理パーティション」と呼ぶ )

上記コマンドに従い、パーティションを作成、フォーマットを実行

最近?の diskpart では、作成したパーティションが選択された状態になっているので、そのまま fomat コマンドを実行することで作成したばかりのパーティションをフォーマットします。fs=ntfs でntfsを選択、ボリュームラベルは nano server を指定、quick を付けることでクイックフォーマットを行ってます。
assign letter=c で、このパーティションを「C」ドライブと名付けます。名付けた時点で C: でアクセスが可能になります。

最後が重要です、active を実行することで、MBRに「このパーティションから起動する」という指名をします。この操作をしていないと、起動パーティションが分からずブートに失敗しますので注意してください。

起動パーティションを指定
list partition で先頭に*があるのがそれだ

終わったら、DISKPART> のプロンプトで exit を入力する、もしくは Ctrl-C で終了できます。

・Nano Server イメージの展開

空のC:ができたところで、ここにOSのイメージを流し込みます。
まず、カレントディレクトリを d:\NanoServer に移動しておきます。

ここで、以下コマンドを実行します。少々長いので打ち間違いに気をつけてください。

• dism /apply-image /imagefile:.\NanoServer.wim /index:1 /applydir:c:\

dism コマンドでWIMイメージを展開

dism.exe は WindowsVista から用意された、Windows の展開イメージの管理コマンドです。インストーラーが使用する WIM形式のイメージや仮想ディスクイメージである VHD/VHDX形式、それからディスクに展開された Windows のシステムを管理することができます。

ここでは、imagefile で指定した WIM形式のイメージを applydir で指定したパスに書き出しています。/index:1 は、WIMイメージの2つめのボリュームを対象にしていることを指します。このWIMイメージの中にはEFIシステムパーティションがあるので、C: に相当するのは二つ目の(0オリジンで1の)ボリュームだからです。

dir c: とかすると、Program Files や WINDOWS など、おなじみのフォルダが展開されているのが分かります。

・その他必要なパッケージのインストール

このままでは Nano Server そのものしかインストールされておらず、起動する以上の意味を持ちません。追加のデバイスドライバや役割、機能をここでインストールします。

CABパッケージの追加インストールには、dism /add-package を使用します。
パッケージは d:\NanoServer\Packages フォルダの下に格納されております。

ここでは、d:\NanoServer\Packages フォルダにカレントディレクトリを移動させた後、Microsoft-NanoServer-OEM-Drivers-Package.cab を追加しています。

• dism /add-package /packagepath:.\Microsoft-NanoServer-OEM-Drivers-Package.cab /image:c:\

add-package ではインストール先の「システムイメージ」を指定しますが、ここでは c:\ 以下に展開されたイメージが対象のため、c:\ としています。

パッケージを追加
警告が気になる場合は、2GB以上のディスクを用意する事

ここではディスク容量が小さく作業領域(ScratchDir)が小さいせいで警告が出ています。確かに、今回ディスクサイズを1GBにしたので、イメージを展開した分容量が取られており、空き領域が 1GBを切っています。仮想マシンのディスクサイズをそもそも2GB程度にすればこの警告は生じませんし、今回のように強行しても、1個ぐらいのパッケージなら問題なく展開できたりもします。

VMware 上の仮想マシンの場合、この Microsoft-NanoServer-OEM-Drivers-Package.cab は必ず入れてください。この中に LSI Logic の SCSIドライバなども含まれているため、このパッケージを追加しないと、OS起動後に C:ドライブをマウントできず、BSODになります。

その他の役割については、こちらのページを参照してほしい。「Creating a custom Nano Server image」の項目にある表が、概ね機能と対応するパッケージになります。厳密にはこの表は、事前にパッケージを組み込んだ NanoServer.wim を作るために使用する New-NanoServerImage コマンドレットの引数になってますが、たとえば Hyper-V の役割をインストールするための「-Compute」なら、「Microsoft-nanoServer-Compute-Package.cab」とか類推がつくかと思います。

また、c:\NanoServer\Packages フォルダの直下だけではなく、言語ごとのフォルダもあります。日本語の場合、c:\NanoServer\Packages\ja-jp というフォルダがあり、同名のパッケージがあるのでこちらもインストールしておいてください。
(ただし、NanoServer のコンソール画面は英語しか表示できないため、ローカルコンソールでの日本語関係は化けてしまいます。)

・起動パーティションとして指定

さて、最後に起動パーティションとして指定します。これは、bcdboot コマンドを使用します。

• bcdboot c:\Windows /s c:

bcdboot でブートローダーの設定を作成

bcdboot.exe もまた WindowsVista から導入されたコマンドで、winload によるOS起動を制御します。ここでは、c:\Windows から Windows  を起動することを指定しています。その設定は c: に、つまり同じドライブに書き込まれます。

実のところ、これはちょっとした手抜きです。Windows をGUIからインストールした場合は PC-BIOS の場合も先頭に100MB程度のシステムパーティションが作成され、こちらに OS起動の設定が書き込まれます。UEFIの場合、EFIシステムパーティションが必須であり、こちらで認識する必要があるから別パーティションを用意する必要はあります。

一方、PC-BIOS の場合はその必要性はさしてないですし、仮想マシンの場合固定したOSを固定したパーティションから起動する、せいぜい起動オプションを変えたモードを用意するぐらいですので、これでも問題ない、という判断からです。
なお、Microsoft のページでも、「不要なら削除して構わない」となってます。

気になる方はシステムパーティションを作成し、/s の指定先をそちらにした方が良いでしょう。

bcdboot で設定が正しく書き込まれたかは、bcdedit コマンドで確認できます。

• bcdedit /store c:\Boot\BCD

bcdedit コマンドでブートローダーの設定を確認
bcdedit 単体で実行すると、現在起動したOS(この場合はX:)の設定を表示するため、
ここでは /store でどこにある設定を読み込むかを指定している

Windows ブートマネージャー の項目が、ブートマネージャーそのものの設定、たとえば表示言語(ここではen-us)などが表示されます。ブートマネージャーの default に表示されている Identifier の項目が起動時に使われます。また、次の displayorder に複数の Identifier が表示されている場合、この順でメニュー表示され、どの設定から起動するかを選択することができます。メニューを表示して何秒待ったら起動するかは、timeout に設定されます。

ここでは {default} という Identifier の設定が一つだけ、 Windowsブートローダーの項目に表示されています。

詳細な内容については、こちらのページもあわせてご参照ください。


さて、これで準備は終わりました。コマンドプロンプトウィンドウを閉じて、下のインストーラーのパネルを閉じる事で再起動されます。または、コマンドプロンプトウィンドウから「wpeutil reboot」コマンドを実行する事でも再起動が行われます。

再起動後、HDDから起動が行われ、Nano Server が起動してきます。

Nano Server 起動中

ブートローダーはフルインストールと同じためここだけはグラフィカルだ

Nano Server 起動。
本当に何のUIもなく真っ黒だった 以前のTPと異なり、
TP5やリリース版では最低限のUIはついた。本当に最低限だが

初期状態では Administrator にパスワードが入っていませんので、ユーザ名に Administrator を指定してリターンをたたくと、初期パスワードを入力を要求されます。

ここで Administratror のパスワードを設定

DHCPから採取された IPアドレスなどは画面に表示されるので、あとはRSATを使って管理する、または SMTを使って管理するなどで、Nano Server を扱うことができます。
( Azure 管理コンソールで Windows Server もまとめて管理できる SMT は、マイブームだったり(笑) )

Networking を選択、リターンを押すとIPアドレスの設定が確認できる

● EFI の場合は?

PC-BIOS と EFI で異なるのは、ブートの手順になります。

BIOSの場合は、MBR に記載されたシンプルな一次ブートローダーがアクティブに指定されたパーティションの二次ブートローダー、つまりは winload を呼び出し、winload が bcdboot で記入した設定を読み込み、ブートします。MBR に入れることができるブートローダーはリアルモードかつ容量も限られているので、winload そのものを入れるのではなく、二段構えになっています。

EFI の場合は、 EFI システムパーティションに組み込まれたブートローダーがOSを起動します。Windows の場合は EFI に winload が存在し、これが Windows を起動します。EFIシステムパーティションは100MBないしそれ以上あり、EFIがブートローダーに提供する機能も BIOS に比べ張るかに高機能なことから、winload が直接利用できるわけです。

このことから、二つの部分がかわってきます。
一つはパーティションの作成。GPTパーティション形式にした上で、EFIシステムパーティションを用意する必要が出てきます。
二つ目は、bcdboot での指定。BIOSの場合は winload も bcdboot の設定も c: にごっちゃに入れてましたが、EFI の場合は /s で指定する格納先は EFIシステムパーティションになります。

では、手順を見てみましょう。

最初に重要なのは、仮想マシンを作成したら「ファームウェアをEFIにしておく」事です。ゲストOSの設定にもよりますが、Windows Server 2016(64bit)を選択してもデフォルトはBIOSになってます。

仮想マシンのプロパティの「オプション」「起動オプション」で
ファームウェアをEFI にして、OKを押す

そこからインストールメディアで起動し、diskpart を起動するところまではBIOSとわりません。

Windows Server 2016 のインストールメディアから起動
ここからコマンドプロンプトウィンドウを出すところは同じ

実行する DISKPART のコマンドが少し変わって、以下になります。

• select disk 0
• convert gpt
• create partitoin efi size=100
• format quick fs=fat32 label="System"
• assign letter=s
• create partition msr size=128
• create partition primary
• format quick fs=ntfs label="nano server"
• assign letter=c

select disk0 で1本しか繋いでいない仮想ディスクを選択するところまでは一緒です。
次の convert gpt でパーティションの記録形式をデフォルトのMBR形式から EFI で使用する GPT パーティション形式にしておきます。

次に、create partiton efi で、EFIシステムパーティションを作成しておきます。GPTパーティション形式では、内部的には UUID でそのパーティションがどういうものかを記録しております。が、一々 長い UUID を入力するのは人間業では辛いので、「efi」というシンボルで EFIシステムパーティションであるというUUIDを入れてもらっている訳です。なお、size=100 は 100MiB のサイズで確保する事をさします。create partition でサイズ無指定だと開いてる所全部、となります。

その後、FAT32形式でフォーマットします。EFIシステムパーティションの実体はFAT32のため、FAT32でフォーマットする次第です。ボリュームラベルは Windows のデフォルトインストーラにあわせて「System」にしています。

また、ここでドライブレター「S」を割り当てております。EFIシステムパーティションはOS起動後はマウントされない、不可視のものですが、ここではBCDの起動設定を入れなければならないので、邪魔にならないところにマウントしている訳です。

EFIシステムパーティションの作成。
なお、EFIシステムパーティションを略してESPと呼ぶこともあります。

続けて、「create partition msr size=128」で MSR を128MiBで確保してます。MSRは、Microsoft 予約パーティションの略で、他のシステムパーティションに関する情報が格納される、とあります。(どうも、Reserved の R ではなく Recovery の R ではないのか?って気はするけど、さておき。)

ともあれ、EFIシステムパーティションの次、C: ドライブとなる Windows パーティションの前に配置することになってます。これはパーティションが存在すれば良く、フォーマットしたり一時的にドライブレターを割り当てて中に何かかき込む必要はありません。

さて、三つ目がプライマリパーティションで、要は Windows をインストールするパーティションです。パーティション作成後、NTFSでフォーマットして、C:をアサインしてます。

なお、BIOSでの起動(MBRパーティション形式)の時と異なり、active でアクティブパーティションを決める必要はありません。EFIは必ず、EFIシステムパーティションを見に行き、そこのブートローダを利用する、どのパーティションから起動するというのはブートローダ側の仕事となっているからです。

続き、MSRとC:ドライブを作成

WIMイメージからの展開と、ドライバーなどのパッケージの導入はBIOSの時と同じです。

さて、ブートローダの設定がBIOSの時とはまた変わってきます。

今回、実行するコマンドは以下になります。

• bcdboot c:\Windows /s s:

WIMイメージの展開、パッケージの導入の後、bcdboot で起動ドライブを設定

起動するOSとして c:\Windows を指定するところまでは同じです。が、その後、ブートローダの設定をかき込むのは EFIシステムパーティションである s: ドライブになります。
その後の bcdedit での確認も、以下になります。

• bcdedit /store s:\EFI\Microsoft\Boot\

EFIシステムパーティションでのブートローダなどは、ルートのEFIフォルダに格納されます。Windows のブートローダーwinload の設定は EFI\Microsoft\Boot 以下に記載される訳です。これはBIOSの時の\Boot\BCD とパスが違うので注意です。

さて、あとはシャットダウンして再起動するだけで、BIOSの時と同じように起動してきます。

一応、EFIから起動した Nano Server...別にBIOSの時と変わらないのですが。

BitLocker などを使わない限りは別にEFIでもBIOSでもOS起動後の動作は変わらないですし、そもそも vSphere では TPMが使えない(仮想TPMが存在しない...これも何とかしてほしいのですが)ので、ことさら EFI にする必要はない、といえます。

.

Fusion 上の NanoServer に関する短いメモ

最近は WindowsServer 2016 TP2 のメディアから NanoServer をインストールしていろいろ見ている。

まだ、Hyper-V のロールが提供されていないので本当に動かして遊んでいるだけだが、確かに小さいし、余計なものは一切入ってないので ESXi のようにミニマムなハイパーバイザ環境としても使えるし、ファイルサーバや iSCSIのターゲットとして使うもよし、来たるべき Windows のコンテナのベースとしても良さそうだ。

さて、NanoServer を Fusion 上にインストールすると、起動時のボールがくるくる弧を描くのががずっと続いて、起動にすごく時間がかかっているのかと思っていたのだが、どうもそうではないようだ。

先日の Bonjour を有効にすることで気がついたが、仮想マシンをパワーオンしてからほぼ一瞬で起動しており Bonjour に返事をしていた。
WinRM 等を使ってコマンドを一個でも実行すると即座に黒字に「_」だけの画面になる。

どうも、Fusion 上では起動画面を切り替えるタイミングが何故かはわからないがミスってるっぽく、切り替わらずだらだらと弧を描いている模様だ。