Bootable USB メディアを作ろう

Windows 10 Anivasary Update 1607 が公開されました。
ワタシの環境は、Windows 10 Enterprise なので、Windows 10 更新アシスタントからの更新や
メディア作成ツールが使えません…。悲しい。

そうなると、自前で Bootable USB を作ることになるわけ(わざわざ、DVD に焼くのが勿体無い)で
忘れないように残しておきます。やることは 3 つのステップです。

  1. USB メディアのフォーマットとアクティブ化
  2. インストールメディアファイルの全コピー
  3. ブートセクタの書き込み

まずは、「USB メディアのフォーマットとアクティブ化」を Diskpart コマンドを使ってやります。

管理者権限でコマンドプロンプトを開く
Diskpart コマンド実行
DISKPART> list disk
DISKPART> select disk X (USB メディアのディスク番号)
DISKPART> clean
DISKPART> create partition primary
DISKPART> select partition 1
DISKPART> active
DISKPART> format fs=fat32
DISKPART> assign
DISKPART> exit

続いて、持っている ISO イメージをマウントして、「インストールメディアファイルの全コピー」を xcopy で
全てコピーします。

マウントした ISO ドライブを S: ドライブ、USB メモリを U: ドライブとする
XCOPY S:\*.* /S /E /F U:\

最後に「ブートセクタの書き込み」です。これはインストールメディアにある bootsect コマンドを使います。

マウントした ISO ドライブを S: ドライブ、USB メモリを U: ドライブとする
管理者権限でコマンドプロンプトを開く
S:\boot> bootsect /nt60 U:\

これでおしまい。

広告

LDR と GDR

よく聞かれるので、まとめておこうと思う。

Microsoft は製品に何らかの不具合が見つかった場合に修正プログラムを提供しているのですが、この修正プログラムには

  • LDR : Limited Distribution Release
  • GDR : General Distribution Release

の二種類が存在します。
LDR も GDR も特定の問題に対する修正を行ったモジュールなのですが、LDR は局所的にテストを行ったもので、GDR は広範囲にテストを行ったものと認識してください。そのため、提供方法も若干異なります。
LDR はサポート技術情報(KB)からの個別ダウンロード & インストールとなるのですが、
GDR は、それに加えて、「重要な更新プログラム」という位置づけになると Microsoft Update でダウンロードされインストール
されることもあります。

  • 重要な更新プログラム
  • 更新プログラム
  • 更新プログラムのロールアップ
  • セキュリティ更新プログラム

よく、QFE という言葉を耳にしますが、本来、QFE(Quick Fix Engineering)は LDR のこと指しています。
なお、完全に特定環境における個別問題に対する修正モジュールを Hotfix と呼んでいます。

LDR に関しては一つ注意しておかなければならないことがあります。
一度でも LDR でモジュール適応した後、何かのタイミングで、そのモジュールがさらに更新されたとしても
LDR モジュールが適応され続けます。
更新されたモジュールに新しい LDR があれば、その新しい LDR が適応されることになります。
つまり、GDR が適応されることはなく、GDR を適応させたいという場合には、LDR をアンインストールした後に
GDR を適応する必要があります。

こんな事情があるので、Windows Vista 以降の GDR には、LDR が含まれています。
GDR は大体、拡張子 .msu (MIcrosoft Update Standalone Package)で提供されているのですが、
実は、このファイル展開することができます!

では、GDR の中にある LDR のインストール方法を紹介します。

  1. msu ファイルを個別に KB サイトからダウンロードする
  2. 適当なワークフォルダーを作成する
  3. コマンドプロンプトを開く(管理者用コマンドプロンプトである必要はない)
  4. コマンドプロンプトで
    expand -F:* <msuファイル名> <作成したワークフォルダー>
    を実行すると、ワークフォルダーにファイルが展開されます。
  5. ワークフォルダーに展開されたファイルの中に キャビネットファイル(.cab)がありますので、それを展開します。
    コマンドプロンプトで
    expand -F:* <cabファイル名> <作成したワークフォルダー>
    を実行すると、ワークフォルダーにファイルが展開されます。
  6. cab ファイルを展開したワークフォルダーに update-bf.mum というファイルがあることを確認します。
    これをパッケージマネージャーを使ってインストールします。
    pkgmgr /ip /m:<your dir>update-bf.mum

なお、ファイルのバージョン情報を見ると、LDR と GDR の区別ができます。

Win10: OS のバージョン

Windows 10 RTM が目前に迫ってきました。
常に付きまとうバージョン問題。ここらで、一度、Windows 10 のバージョン値を確認しておこうと思います。
バージョン番号を取得する際、お約束の GetVersion() と GetVersionEx() になりますが、実は
Windows 8.1 以降では、GetVersion() および GetVersionEx() は推奨されない API になっていて
versionhelpers.h で定義されている Version Helper 関数を使うように推奨されています。
ただ、Version Helper 関数だと、具体的なメジャーバージョン、マイナーバージョンの値を取ることができず
Windows 10 以降とか、Windows 7 以降とか、そういう判定しかできない。
おそらく、Microsoft としては、もうメジャーバージョンとかマイナーバージョンで判断するのは辞めれって
メッセージなのでしょう。
実際、Windows 10 以降、OS メジャーアップグーレードの概念を変えるとアナウンスされていますし。

MSDN によると、OS のバージョン番号を取るにはシステム DLL に対して、GetFileVersionInfo() で見なさいと
言っているので、ちと面倒だ。DllGetVersion() という API ものがあるのですが、これは Shell 系の API なので
サービスからは使えないので、やはり、GetFileVersionInfo() を使うことになるのか。

試したところ、Windows 10 でも、まだ、GetVersionEx() が使えるようなので、こっちを使ってバージョン値を
調べてみますが、いつ何時消えるかもしれないので、製品開発では使わない方がいいと思います。

OSVERSIONINFOEX osvi;
BOOL bOsVersionInfoEx;

// OSVERSIONINFOEX構造体を用いて、GetVersionEx()を呼び出してみる
ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);

bOsVersionInfoEx = GetVersionEx((OSVERSIONINFO *)&osvi);
if (!bOsVersionInfoEx)
{
    osvi.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
    if (!GetVersionEx((OSVERSIONINFO *)&osvi))
    {
        return GetLastError();
    }
}

Windows 8.1 / Windows Server 2012 R2 では、アプリケーションマニフェストの SupportedOS で
明示的な 8.1 宣言をしないと、GetVersionEx() は Windows 8 の 6.2 を返すという互換性処理がありました。
Windows 10 はどうなのかな…というわけでやってみます。
なお、Windows 10 の supportedOS の guid は MSDN ですでに公開されています。

<!– Windows 10 –>
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
<!– Windows 8.1 –>
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!– Windows 8 –>
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!– Windows 7 –>
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!– Windows Vista –>
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>

まずは、マニフェストで supportedOS を記述しなかった場合は…

マニフェストなし

内部バージョンは 6.2 で返します。 ということは、Windows 8 ってことか。
次にマニフェストで supportedOS に Windows 8 を記述してみると…

Win8マニフェスト

まぁ、当然ですが、6.2 を返すわけです。
では、supportedOS に Windows 8.1 を記述してみると…

Win81マニフェスト

あー、6.3 ですか。そうですか。
では、最後に supportedOS に Windows 10 を記述してみると…

Win10マニフェスト

おー、きたきた!! バージョン情報が大きく上がった!!
では、まとめます。

OS 名称 バージョン値#1 バージョン値#2 バージョン値#3
Windows 10 10.0
supportedOS に Win10
6.3
supportedOS に Win8.1
6.2
Windows 8.1 / Windows Server 2012 R2 6.3
supportedOS に Win8.1
6.2 N/A
Windows 8 / Windows Server 2012 6.2 
N/A N/A
Windows 7 / Windows Server 2008 R2 6.1 N/A N/A
Windows Vista / Windows Server 2008 6.0 N/A N/A

MSDN に記載がある通りの結果になりました。
Windows 8 まではマニフェストの supportedOS への記述では OS モードだけの差異でしたが、Windows 8.1 以降は
OS バージョンと ビルド番号も変更しています。
しかし、Windows 10 で内部バージョンが一気に上がりましたねぇ。

名前募集!?

マイクロソフトが窓辺家に、1名キャラを加えるそうだ。
DSP 版の情報サイト「Windows Navi+」で応援キャラクターを公開しとる。

    01

なんともすごい設定だわ。
100 年後の未来の窓辺家からやってきたとか…
Windows 10 だから、テンコ はダメだよね。

IPv6 を無効にするレジストリ

IPv6 を無効にするには、レジストリにて以下のエントリー(DWORD値32ビット)を作成して、

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters@DisabledComponents

値に DisabledComponents = 0xffffffff という周知なことだと思っていたのですが、
ここ最近、実は値が変わっているとのこと。まじか!?

ここに Important ということで情報があるではないか!?
DisabledComponents = 0xffffffff
ではなく
DisabledComponents = 0xff
が正しいと…
今さら言われちゃってもねぇ。困るよ。 影響範囲は、システムスタートで 5 秒の遅延が発生するとのこと。
ってことは、今まで 5 秒遅くなってたわけね。

リモートで Windows Server 2012 / R2 のデバイスマネージャーに繋ぎたいのに

最近、SCVMM 2012 R2 をいじっています。
Hyper-V ホストに Hyper-V Server 2012 R2 を使っているのですが、これのリモート管理が思った以上に面倒。
中でも、きっついなぁというのは、リモートでデバイスマネージャーに繋ぐことができないってこと。
既存 OS(Vista/2008/7/2008R2)は、以下の設定でリモートでデバイスマネージャーに繋ぐことができました
(ただし、参照 Only)。

リモートでデバイスマネージャーを開けるようにする方法(2008 R2 まで有効)

  1. MMC を実行
  2. グループポリシーオブジェクトエディターを選択する
  3. リモートコンピューターを指定する
  4. リモートコンピューターに接続したら
    [コンピューターの構成]
    -[管理用テンプレート]
    -[システム]
    -[デバイスのインストール]
    から [プラグアンドプレイインターフェイスへのリモートアクセス] を有効にする

ポリシー設定

ところが、エラーとなり、見ることができません。がーん

デバイスマネージャーに接続できない

ショックです。

    これ、仕様変更なんだとか。なぜに!?

イベント ログ ファイルの形式

Windows Vista 以降のイベント ログは、拡張子 .evtx という新しいフォーマットになりました。
この変更により、従来のイベント ログ拡張子 .evt 形式の互換性ですが、保存はできず、読み込みだけが可能です。
ただし、WMI の API である BackupEventLog() をプログラムで実装することで、拡張子 .evt で保存することができます。
ここで拡張子 .evt について、一つ注意事項があります。
.evt 形式ですが、従来のイベントログ形式 (.evt) と Windows Vista 以降で API BackupEventLog() で作成した .evt は
同じ拡張子でも、フォーマット形式が異なります。

  1. 旧イベントログ フォーマット形式 (拡張子 .evt)
    Windows Server 2003 までの OS で使用していたイベントログ フォーマット形式
  2. レガシー イベントログ フォーマット形式 (拡張子 .evt)
    Windows Vista 以降の OS で BackupEventLog() を使い、出力したイベントログ フォーマット形式
    このイベントログは、Windows Server 2003 までの OS では正しく読み込めないので、
    Windows Vista 以降の OS で読み込む必要がある
  3. 新イベントログ フォーマット形式 (拡張子 .evtx)
    Windows Vista 以降の OS で採用されているイベントログ フォーマット形式

同じ拡張子で、フォーマットが異なるのは悩ましいところです。
なお、拡張子 .evt のフォーマットを .evtx に変換するには、イベントビューアーで .evt を開いて、.evtx で保存するか
wevtuil.exe というコマンドラインツールを使う方法があります。

例えば、wevtuil.exe を使うなら

wevtutil epl application.evt app_new.evtx /lf:true

という具合です。

なお、新イベントログ フォーマット形式 (拡張子 .evtx) を操作するには、新しい API セットがありますので
こちらを使うようにしましょう。

イベントログは奥が非常に深いです。

Win8 & 2012: アプリケーション マニフェストの SupportedOS

Windows 7 & Windows Server 2008 R2 で追加になった Compatibility セクションの SupportedOS ですが
Windows 8 & Windows Server 2012 用に GUID が追加されています。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!–Windows 8 Mode–>
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
      <!–Windows 7 Mode–>
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" /
      <!–Windows Vista Mode–>
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />
    </application>
  </compatibility>
</assembly>

  • Compatibility セクションは Windows 7 からサポートされる
  • Compatibility セクションがないアプリケーションは Windows Vista モードで動作する
  • Windows 7 以降の OS では、Compatibility セクション内の最も新しい OS レベルで実行モードを決定する

OS 実行モードの違いは次のようになります。

項目 Windows 8 Windows 7 Windows Vista
RPC の既定スレッドプール NT スレッドプール NT スレッドプール プライベートスレッドプール
DirectDraw の Lock API によるプライマリデスクトップビデオバッファーのロック 不可 不可
DirectDraw のクリッピングウィンドウなしでプライマリデスクトップビデオバッファーへのビットブロック転送 不可 不可
GetOverlappedResult API の複数回呼出しでの競合 競合は解決される 競合は解決される 競合は解決されない
ハイ コントラスト モードでの Shell Theme のステータス テーマ設定状況が返される テーマ設定できないことが通知される テーマ設定できないことが通知される
IPersistFile ハンドラー呼出しへの相対パスの使用 呼び出しに失敗する 続行する 続行する
プログラム互換性アシスタント (PCA) PCA による軽減策は適応されない PCA による互換性問題が追跡される PCA による互換性問題が追跡される

モードの確認方法も Windows 7 のときと同じで、リソースモニターを使うことで確認することができます。

リソースモニター

Windows 7 では、Windows Vista モードの実行モジュールが目立ちましたが、
Windows 8 では、多くの実行モジュールが Windows 8 モードや Windows 7 モードになりました。

ちなみに、Windows 8 の内部バージョンは 6.2 になります。

Win8 & 2012: OS のバージョン

Windows 8 & Windows Server 2012 ですが、メジャーバージョン 6 世代の 3 代目 OS になります。
ということは、内部バージョンは…

OS 名称 バージョン値
Windows Vista / Windows Server 2008 6.0
Windows 7 / Windows Server 2008 R2 6.1
Windows 8 / Windows Server 2012 6.2

OS のバージョンチェックですが、Vista 以降では、GetProductInfo() が推奨されていますが、VerifyVersionInfo() を
使っても大丈夫です。

このことからも、Steven Sinofsky から Windows 8 開発者向けのメッセージ

Everything that runs on Windows 7 runs on Windows 8

って納得ですね。

OSバージョン

ワタシは、Enterprise を使っています。