Windows 7 のインストールでどうやらファイルの展開中にフリーズしてしまうケースがあるようです。 こういった場合は HDD の不良か、DVD の不良かと考えるのですが、手動でファイルの展開をしてしまえばもっとはっきりするのではないかと考えました。 そうです、ImageX の Apply オプションを使って直接ハードディスクに展開してしまおうと言うわけです。 通常のセットアッププロセスを飛ばして Apply するので、アップグレード版などの場合、ちゃんと既存 OS の認識をしてくれてプロダクトキーが通るかどうかは不明ですが、少なくとも install.wim が正しく展開できるかどうかは確認できるはず。
[すでに Vista がインストールされている場合を想定]
補足: Windows Pre-install environment (Win PE) に ImageX と Install.wim を入れたディスクなり、USB メモリースティックが用意できれば、Win PE で起動して、既存 OS なしで、 Install.wim を直接展開もできます(通常版ならプロダクトキーも通ります)が、Win PE を準備して、そこに Install.wim と imageX を入れて、ISO 等を作成するというのは結構な手間なので省略します^^;
[準備するもの]
Windows 自動インストールキット (WAIK) - この中に Image X がありますので、ダウンロードして Vista にインストールしておきます。
Windows 7 DVD - この中の Install.wim を展開適用します。 Vista を起動して、DVD ドライブに挿入しておきます(D ドライブと仮定します)。
空きパーティション(ディスクの縮小とかで開けられます)か、別の HDD を接続し、Windows 7 をインストールできる領域を用意します(E ドライブと仮定します)。
[手順]
1. Deployment ツールのコマンドプロンプトを管理者権限で開きます
次のようなコマンドプロンプトが開きます。
2. ImageX /info d:\sources\install.wim を実行して含まれているイメージを確認します
販売されているパッケージでは 5 つのイメージが含まれており、次のようになっています。
1 = Starter
2 = Home Basic
3 = Home Premium
4 = Professional
5 = Ultimate
購入したパッケージに含まれているプロダクト キーはそのエディション専用になりますので、購入されたパッケージと同じエディションを選択する必要があるので、番号を覚えておきます。
(ここでは Ultimate と仮定します)
3. E ドライブに対して、次のコマンドを使用してイメージを展開します。
imagex /apply d:\sources\install.wim 5 e:\
これが 100% になれば完了です。 DVD に問題があるか、HDD に問題がある場合にはここで止まるか、エラーになるはずです。
この作業が、通常セットアップの [ファイルを展開しています] に該当します。
大体 10 分ほどで展開が終わります(HDD の書き込みが遅いともう少しかかるかもしれません)。
次のように、Successfully applied image. と表示されれば完了です(この例では 5 分 41秒で終わりました)。
4. Windows 7 を起動できるようにする
このままでは、Windows 7 は起動してきませんので、ブートローダーを置き換えて、Windows 7 が起動できるようにします。
E:\Windows\System32 に移動し、bcdboot e:\Windows /s c: と入力します。
5. 再起動します
再起動後、ブートメニューから “Windows 7” を選ぶと、次のようにインストールの処理が行われます。
順を追ってスクリーンショットを入れておきたいのですが、容量の関係で表示される言葉記述しますので、参考にしてみてください。
a. サービスを開始しています
b. デバイスのインストール中(XX %) と % が増加していきます
c. システム設定の適用中
d. コンピューターを再起動した後、セットアップを続行します
再起動後がここで行われます
e. 初めてコンピューターを使用するための準備をしています
f. ここから先は一般的な新規インストール後と同じ画面です。
次のように起動すれば、インストールの完了です
以上、このように直接 HDD へイメージを展開してしまうやり方でもインストールができますので、どうしても通常の方法でうまくいかないときには試してみるとよいでしょう。
インストール準備編
さて、3 つの EXE がダウンロードできましたので、準備を始めます。
1．MS Storeから EXE 版のダウンロードファイル下記 3 つのファイルを同じディレクトリに保存します(32 bit 版の例)
Win7-U-Retail-ja-jp-x86.exe
Setup1.box
Setup2.box
2．Win7-U-Retail-ja-jp-x86.exe を実行します。
3．expandedSetupフォルダが作成され、セットアップファイルが展開されます。
4．展開が終了すると、自動的にセットアップ画面が立ち上がります。後は、一般的なインストールの手順と同じです。
※補足：Install.wim、boot.wimはexpandedsetup\sourcesディレクトリ内に保存されます。
ここで、発生するであろうエラーをあげて起きます
3 つのファイルがダウンロードできておらず、setup1.box がない場合
![clip_image002[6]](http://blogs.msdn.com/blogfiles/fmo_jp/WindowsLiveWriter/MSStoreWindows72_11154/clip_image002%5B6%5D_thumb.jpg "clip_image002[6]")
展開先のディレクトリに Boot.wim が存在しない場合
![clip_image002[8]](http://blogs.msdn.com/blogfiles/fmo_jp/WindowsLiveWriter/MSStoreWindows72_11154/clip_image002%5B8%5D_thumb.jpg "clip_image002[8]")
展開先のディレクトリに Install.wim が存在しない場合
![clip_image002[10]](http://blogs.msdn.com/blogfiles/fmo_jp/WindowsLiveWriter/MSStoreWindows72_11154/clip_image002%5B10%5D_thumb.jpg "clip_image002[10]")
Boot.wim が破損・正しいファイルでない場合
![clip_image002[12]](http://blogs.msdn.com/blogfiles/fmo_jp/WindowsLiveWriter/MSStoreWindows72_11154/clip_image002%5B12%5D_thumb.jpg "clip_image002[12]")
ダウンロード編
一度画面を閉じてしまったと仮定して、購入履歴からダウンロードを行ってみます。
1． https://www.microsoftstore.jp/Form/Order/OrderHistoryList.aspx にアクセスします。
2. [マイアカウント] をクリックします
3. 注文履歴の画面になります。 赤い四角の部分にプロダクトキーが表示されています。
4. ドロップダウン リストボックスから、目的のファイルを選択します。
<<注意>>
1/3、2/3、3/3 の表記がある EXE は、3つともすべてダウンロードする必要があります。 3 つがそろって初めて展開できます。
ISO の場合は1つだけダウンロードすれば OK です。
また、Windows XP 上から Internet Explorer 6 を使ってダウンロードする場合には、2GB の上限に引っかかってしまう場合があるので、Internet Explorer 7 以上を使います。
[XP] 2GB 以上のファイルのダウンロードに失敗します
5. 次のように選択し、[ダウンロード] をクリックします(この場合は 1/3 を選んだので残りの、2/3 と 3/3 もダウンロードする必要があります)
6. ダウンロードの確認画面がでたら、[保存] をクリックして、ローカルに保存します。
この例の場合には、2/3 と 3/3 も同様の手順で繰り返しダウンロードします。
次はインストール準備編
なにやら、MS Store から Windows 7 を購入した人がうまくダウンローを行えないでいるようです。 というわけで、そのコンテンツを作ってしまいましょうというわけです。
購入編
1. まずは欲しい製品をカートに入れます。
2. 個人情報の取り扱いについて確認します。
![clip_image002[8]](http://blogs.msdn.com/blogfiles/fmo_jp/WindowsLiveWriter/MSStoreWindows71_10BF5/clip_image002%5B8%5D_thumb.jpg "clip_image002[8]")
3. 本人情報を入れます
4. 支払い情報を入力します
5. 注文内容確認画面
6. 注文完了
以上で、購入完了です。 赤く塗りつぶしたところにプロダクトキーが表示され、ダウンロードできるようになっています。
次はダウンロード編です。
明日、明後日 (10/24, 25) で開催される、セブン博 http://windows7.jp.msn.com/journal/jo01.htm ですが、2F には PC メーカーや周辺機器メーカーからの Windows 7 対応機器が並べられ、さわったり説明を聞いたりと、Windows 7 の世界を体験できる場所が用意されます。
また、2F の片隅には Windows 7 アップグレード相談コーナーが設けられますので、そこでアップグレードに関する相談も受けられます。
私もこのアップグレード相談コーナーに両日ともおりますので、お近くの方でアップグレードに不安な方は是非いらしてください。
テスト環境(作成した環境ではない環境)でテストです。
今回のシナリオでは、 Windows Virtual PC + XP MODE が便利です。 そのまま XP 環境を Windows 7 にアップグレードしてしまえばテストに使えます。
まずは、テスト証明書をテスト環境にインストールします(開発環境で、Cer ファイルにエクスポートしておきます)。
1. Cer ファイルをダブルクリックして、表示して[証明書のインストール]をクリックします。
2. ウィザードに従って進めていきますが、場所を選択するところで、[信頼されたルート証明期間] を選びます。
後は画面に従って完了します。
では実行です。 USMT のコピーが終わった後に troubleshooting pack が起動してきました。
次へを押して進めると、Windows.old フォルダがあるので、scanstate が動きます。
scanstate が問題なく終わると、loadstate が動きます。
loadstate が問題なく終わると、usmtutils を使ってマイグレーションストアの削除を行います。 入力を求められるので Y を入力し、Enter を押します。
その後は、1分後に再起動です。 見つかった問題も解決済みになっています。
再起動後 XPMUser のプロファイルが追加されています。
XPMUser でログインすると、デスクトップにはアイコンがあり、ファイルもちゃんとドキュメントに入っています。 テーマが解除されているので、テーマは再設定の必要があります。
テーマを再設定すると下記のようになります。
今回はレジストリの内容まで確認していませんが、USMT はレジストリの内容まで移行するので、アプリケーションを入れなおせば設定された内容で使えるはずです。
テストは問題ないので、後は本番用に実行するパックと EXE にちゃんとしたサインを施せば OK という感じですね。
#とりあえずテスト証明書の段階でも試してみたい方は、ファイルを下記に入れておきましたので、どんな感じなのかを確認いただけます。
http://zx9b0w.blu.livefilestore.com/y1pKV38ynqDRYtCMm2soaPp8ln3dai8B-g27H02Fp8PcXJRnn7ezhvlA5T02f0SuJqMKPwxHb3StFmFWUOuPcsI-KLm1PAjH_Oh/GetWinOld.zip?download
テスト＆パッケージ作成
ここのスクリプトのテストは、スクリプトエディタで実行してみることができますが、出来上がったパックを一連で流したい場合には、まずは UI 上から下図のボタンを押して実行する事ができます。
実行すると次のような画面が表示され、実際のトラブルシューティングパックとして動作の確認ができます。
この操作をすると実際にはパッケージ作成も行われていますので、プロジェクトが保存されているディレクトリの下の Output の下の CAT ディレクトリに、拡張子 .diagcab のファイルが作成されます。
これで、トラブルシューターとしては完成なのですが、注意事項があります。
diagcab には証明書によってサインされているのですが、これは下図のようにテスト用のルート証明書が入っている事が前提なので、ほかの環境へ持っていくとこのままでは実行できません。 なので出来上がったパックをちゃんと Deploy するときには正式な証明書によるサインが必要となります。
今回のシナリオの場合、このままでは WAIK が入っていないと動きません。 使ってもらう人に WAIK をダウンロードしてインストールしてもらえばよいのですが、シナリオ的に Windows.old からのデータ吸い上げを行いたいだけなのに WAIK のインストールはちょっと大変です。
というわけで、USMT を最初にコピーしてしまう処理をを入れたいのですが、単にファイルのコピーなので、バッチファイルで行います。
準備
1. InstallUSMT&RUN.bat というファイル名で次の内容を含んだバッチファイルを作成します。
robocopy .\USMT "%LOCALAPPDATA%\Microsoft\Windows AIK\Tools\USMT" *.* /E
"Geathering Data form Windows.old.diagcab"
2. バッチファイルを CAT フォルダに保存します。
3. %ProgramFiles%\Windows AIK\Tools の中にある、USMT のディレクトリごと CAT フォルダにコピーします。
下図のような感じなります
4. この 3 つのファイルを 1つの ZIP ファイルにします。
5. WinZip の SelfExtractor を使って、EXE 化と伸張後に installUSMT&RUN.bat を実行するように設定します
4 および 5 はフォルダを丸ごと圧縮＆パッケージして、EXE を作って伸張後に installUSMT&RUN.bat が動かせるならどのようなツールでも OK です。
これで完成した EXE を対象となる環境で動かせば OK です。
次は実際にテスト環境で動かしてみます。
スクリプト編です。
(PowerShell スクリプトのスペシャリストではないので、スクリプトの記述に関しては平凡だと思いますので、あらかじめご了承お願いします。)
最初の [Edit Troubleshooter Script] をクリックします。 Windows 7 にはデフォルトで Power Shell 2.0 用のエディタがありますので、これが起動します。
一番上の部分にスクリプトを記述して、F5 を押すか、ツールバーの実行ボタンを押すと、真ん中にその結果が表示されます。
一番下の Window は直接コマンドをいれてその様子を見たいときに使います。 結果は同様に真ん中に表示されます。
Troubleshooter Script
ここでのポイントは、
1. Windows.old\Windows フォルダが存在する
2. USMT が使える状態にある
をチェックします。 この条件に合致した場合には、 Root Cause を見つけたことになるので、update-diagrootcause を呼び出して $true を設定するというものです。
今回は WAIK をインストールしているだけではなく、USMT をあらかじめコピーしてから troubleshooting pack を実行する事も考慮して、2 箇所に USMT のフォルダがあるかどうかを調べています。
# TroubleshooterScript - This script checks for the presence of a root cause
# Key Cmdlets:
# -- update-diagrootcause flags the status of a root cause and can be used to pass parameters
# -- get-diaginput invokes an interactions and returns the response
# -- write-diagprogress displays a progress string to the user
$RootCauseID = "DataFromXP"
# Your detection Logic Here
$WinOldPath = $env:SystemDrive + "\Windows.old\Windows"
$USMTDir = $env:ProgramFiles + "\Windows AIK\Tools\USMT\" + $env:PROCESSOR_ARCHITECTURE
$USMTDir2 = $env:LOCALAPPDATA + "\Microsoft\Windows AIK\Tools\USMT\" + $env:PROCESSOR_ARCHITECTURE
$WinOld = Get-Item $WinOldPath
$USMT = Get-Item $USMTDir
$USMT2 = Get-Item $USMTDir2
if (!$WinOld) {
Write-DiagProgress "Windows.old is not found"
$RootCauseDetected = $false
update-diagrootcause -id $RootCauseId -detected $RootCauseDetected
return
} else {
Write-DiagProgress "Windows.old is found"
}
if (!$USMT -and !$USMT2) {
Write-DiagProgress "Windows Automated Installation Kit is not instelled. Please, install from http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=696dd665-9f76-4177-a811-39c26d3b3b34"
$RootCauseDetected = $false
update-diagrootcause -id $RootCauseId -detected $RootCauseDetected
return
} else {
Write-DiagProgress "Windows Automated Installation Kit is instelled or USMT is found."
}
Write-DiagProgress "There is Windows.old folder and Windows AIK is installed. Done for checking"
$RootCauseDetected = $true #Replace "$true" with the result of your detection logic
#The following line notifies Windows Troubleshooting Platform of the status of this root cause
update-diagrootcause -id $RootCauseId -detected $RootCauseDetected
Resolver Script
[Edit Resolver Script] をクリックすると、実際に問題を修正するスクリプトの記述となります。
ここでは特に、何かの値を返す必要があるという事はありません。 少し複雑なので、途中に日本語コメントを入れながら色を変えて記述します。
# Resolver Script - This script fixes the root cause. It only runs if the Troubleshooter detects the root cause.
# Key cmdlets:
# -- get-diaginput invokes an interactions and returns the response
# -- write-diagprogress displays a progress string to the user
# Your logic to fix the root cause here
$USMTDir = $env:ProgramFiles + "\Windows AIK\Tools\USMT\" + $env:PROCESSOR_ARCHITECTURE
$USMTDir2 = $env:LOCALAPPDATA + "\Microsoft\Windows AIK\Tools\USMT\" + $env:PROCESSOR_ARCHITECTURE
$USMT = Get-Item $USMTDir
$USMT2 = Get-Item $USMTDir2
#ここでは USMT のディレクトリのうち見つかったほうをディレクトリを使うようにしています。
if (!$USMT) {
$USMTDir = $USMTDir2
}
if(!$USMT -and !$USMT2) {
return $false
}
#次の Veryfier で Fix ができたかどうかを確認したいのですが、Global 変数でも値の保存ができなかったので、レジストリ上にキーを作ってその存在で判断しています
Remove-ItemProperty -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion -Name "GetDataFromWindowsOld"
Write-DiagProgress "Prepartion was done. Start scanscate for gathering information"
#カレントディレクトリを USMT のディレクトリに変更し、scanstate をパラメータつきで呼び出します。このとき –Wait を指定してプロセスが終了するまで待つ設定です。
Set-Location $USMTDir
Start-Process "scanstate.exe" -Wait -ArgumentList ($env:SystemDrive + "\migs /auto /offlineWinOld:" + $env:SystemDrive + "\windows.old\Windows /hardlink /nocompress /efs:hardlink /c")
#プロセスが終わると、ログファイル scanstate.log が作られるので、これを読み出してエラーが記録されていないかどうかを確認します。 エラーが記録されている場合には処理を中止して戻ります。
$ErrorCheck=""
$ErrorCheck = select-string -path scanstate.log -pattern "Failed.\[gle=0x"
if($ErrorCheck) {
Write-DiagProgress ("Error has occured :" + (Get-Content scanstate.log))
return $false
}
#scanstate が正常終了すると、マイグレーションストアが %SystemDrive%\migs に作成されていますので、loadstate をパラメータつきで呼び出して、そこからデータを吸い上げて、動作中の Windows 7 に適用します。 同様に –wait をつけています。
Write-DiagProgress "Start loadstate for applying information in Windows 7"
Start-Process "loadstate.exe" -Wait -ArgumentList ($env:SystemDrive + "\migs /auto /hardlink /nocompress /lae /lac /c")
#同様に loadstate.log を読みこんでエラーチェックを行いますが、ここではすでにマイグレーションストアが作られているので、ストアの削除を行う必要があるので、エラーになったという記録だけを行って、処理を続行します。
$ErrorCheck=""
$ErrorCheck = select-string -path loadstate.log -pattern "Failed.\[gle=0x"
$NoError = $true
if($ErrorCheck) {
Write-DiagProgress ("Error has occured :" + (Get-Content loadstate.log))
$NoError = $false
}
#マイグレーション ストア の削除を usmtutils を使って行います。 ここではどうしても、Yes か No の選択がコマンドプロンプトで求められるので、ユーザーに Y を押してもらう必要があります。
Write-DiagProgress "Start usmtutils for deleting migration store. Please, input ""Y"" in command window"
Start-Process "usmtutils.exe" -Wait -ArgumentList ("/rd " + $env:SystemDrive + "\migs")
#次は再起動のための shutdown の呼び出しですが、loadstate でエラーになっていた場合は再起動を行いません。 loadstate まで成功した場合には、レジストリにキーを作成して、shutdown を呼び出して 1分後 に再起動を行います。
if($NoError) {
Write-DiagProgress "Done and Restart the computer within 60 second"
New-ItemProperty -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion -Name "GetDataFromWindowsOld" -PropertyType Binary -Value 1
Start-Process "Shutdown.exe" -ArgumentList "/r /t 60"
return $true
} else {
return $false
}
Verifier Script
[Edit Verifier Script]をクリックすると、問題が修正されたかどうかのチェックを行うスクリプトの編集となります。
このスクリプトでは、先の Resolver で最後まで正常にスクリプトが走った場合に作成される、レジストリの値を調べて、存在する場合には、$RootCauseDetected = $false ということで、update-diagrootcause を呼び出します。
# Verifier Script - This script confirms that a root cause has been resolved correctly
# Key Cmdlets:
# -- update-diagrootcause flags the status of a root cause and can be used to pass parameters
# -- get-diaginput invokes an interactions and returns the response
# -- write-diagprogress displays a progress string to the user
$RootCauseID = "DataFromXP"
# Your detection Logic Here
$Flag = Get-ItemProperty -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion -Name "GetDataFromWindowsOld" | Select-Object GetDataFromWindowsOld
if(!$Flag) {
$RootCauseDetected = $true #$false #Replace "$false" with the result of your detection logic
} else {
$RootCauseDetected = $false #$false #Replace "$false" with the result of your detection logic
}
#The following line notifies Windows Troubleshooting Platform of the status of this root cause
update-diagrootcause -id $RootCauseId -detected $RootCauseDetected
ここで気がつかれた方もいらっしゃると思いますが、troubuleshooter で update-diagrootcause に True を設定して、 Verifier で false を設定する事で、Fix が行われたという認識となります。
つまり、troubleshooter では update-diagrootcause が false の場合には Resolver には進みませんし、Verifier で True のままだと問題が修正されていないという認識となります。
次はテストとパッケージの作成を行っていきます。
今回は Windows 7 で実行可能なトラブルシューティング パックを自作してみたいと思います。
まず、Windows 7 の SDK が必要となりますので、これをダウンロードしてインストールします。
インストールが完了すると、下記のように Windows Troubleshooting Pack Designer があるのがわかります。 これを使って作成します。
起動した画面
ここで、Project メニューから New を選んで作成していくのですが、何の問題に対して修復するのかというシナリオを考えておかないといけません。
そこで今回は、「Windows XP や Windows Vista の環境に Windows 転送ツール等でデータを吸い上げずに、Windows 7 を入れちゃって、Windows.old からデータを吸いあげる」 というシナリオでいきたいと思います。
Root Cause としてはいくつも登録できるのですが、今回は1つだけで行きます。 このシナリオでは Fix のために USMT を使うので、Windows Automated Installation kit が必要となります。
料理番組のようで申し訳ないですが、すでに出来上がっているプロジェクトが下記です。 実際 New を選んだ後は、ウィザード形式で進めていくので、この画面までは比較的簡単にできます。
では順番にそれぞれの内容のスクリーンショットを載せていきます。 下図は Root Cause のメイン画面です。 複数の Root Cause に対しての torubleshooting pack を作る場合には、この Root Cause の項目がたくさん存在することになります。
下図はトラブルシューターを動かすときの基本的な設定です。
最初のオプションは管理者モードで実行させる必要があるかどうかです。 今回は USMT のツールを実行するので、ここは必須で管理者モードで実行させる必要があります。
次のオプションはユーザーに質問項目を表示させて、その内容を元に判断する必要があるかというものですが、今回は必要ないので No を選んでいます。
どのような場合に使われているかというと、デフォルトで Windows 7 に入っているトラブルシューターの [プログラムの互換性] で、ユーザーが選ぶ箇所があります。 そういったインターフェースを表示して入力を求めるかどうかですね。
下図は Resolver の設定です。 ここでは 3 つのオプションがあるのですが、先の画面と違うのがプロンプトを表示する必要があるかどうかです。 何らかのメッセージを表示する必要があるときは、ここを Yes にしますが、今回のシナリオでは No でいきます。
後の 2 つのオプションは先の画面と同じで、Troubleshooter ですでに管理者権限を要求しているので、ここでは No で OK です。
というのは、 Windows 7 の場合プロセスが一度管理者権限で起動した場合、それ以降はすべて管理者権限として動くので、あえて設定する必要がないのですが、 Troubleshooter で No を設定して、実際の Resolver で管理者権限が必要になるようであれば、ここで Yes を選びます。
下図は Verifier の画面です。 問題が Fix されたかどうかを確認する部分です。
これを設定しないと最後のトラブルシューターがちゃんと緑のチェックマークで終わりませんでしたので、最初のオプションは Yes を選び、次のオプションは No を選びます。 残りの 2 つは一番最初の画面と同じです。
下図が Scripts の画面です。
上記 3 箇所の設定に相当するスクリプトが下記の 3 つとなり、具体的な 3 つのスクリプトを記述することで、1 つの Root Cause を Fix するトラブルシューティング パックとなります。
次は具体的なスクリプトの記述に入っていきます。
次はスクリプトを書いていきます。
2009/9/30 PC メーカー向けに XPMODE が RTM しました。 なので、早速手に入れてセッティングしてみました。 下記は Internet Explorer 6, 7, 8 の画面を同時にだしてスクリーンショットを取ったものです。
基本となるコンポーネント
- Windows 7 専用 Virtual PC 事、Windows Virtual PC (KB958559)
- XPMODE (Windows XP Professional SP3 が入った VHD)
※Windows 7 の Professional 以上では、XPMODE を実行するためのライセンスが付属しますので、XP 環境を用意するには XPMODE が一番楽ですが、Windows XP Professional 版の正規ライセンスユーザーであれば、Windows 7 Home Premium でも 自分で、Virtual PC 上に Windows XP をインストールして、Service Pack 3 まで当てる事で、同じ環境を作り出すことが可能です。
一般的に書かれている事を書いても面白くないので、自分で仮想 OS をインストールする場合についての注意点を記述したいと思います。
上記のような画面にするには、RemoteApp のコンポーネントが必要です。 RemoteApp 自体は Windows Server 2008 のターミナルサービスの新機能として取り入れられたものです。 Windows Virtual PC では統合コンポーネントを入れて、RemoteApp コンポーネントを入れることで、Windows Server 2008 の RemoteApp と同様にウィンドウだけを表示することができるというものです。
統合コンポーネントをインストールできる OS とサービスパック
Windows XP SP3
Windows Vista SP1
Windows 7
RemoteApp コンポーネントをインストールできる OS とエディション
Windows XP Professional
Windows Vista Enterprise または Ultimate
(Windows 7 Enterprise または Ultimate: Windows 7 の場合は標準対応ですが、RemoteApp 対応はこの 2 つのエディションのみです)
つまり、上記をあわせてフル機能を使うには、次のようになります。
Windows XP Professional SP3 (-> XPMODE の VHD にはこれが入っています)
Windows Vista Enterprise または Ultimate の SP1 以上
Windows 7 Enterprise または Ultimate
RemoteApp 用コンポーネントダウンロード先
XP 用: http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=e5433d88-685f-4036-b435-570ff53598cd
Vista 用: http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=26a2de17-8355-4e8d-8f33-9211e48651fb
※この内容を書いているときは v3 ですが、一般リリース時点ではバージョンがあがるかもしれません
インストール順番
- OS をインストール
- サービスパックをインストール (サービスパック込み出ない場合)
- 統合コンポーネントをインストール
- RemoteApp 用コンポーネントをインストール
という訳で、Windows 7 Professional 以上では XPMODE として XP イメージを使えますので、ダウンロードしてインストールした方が楽です。 Vista は上記のようにインストールするしかないですが・・・。
ちなみに、Windows 7 をゲスト OS として動かす場合は、現時点では 2 と 4 は必要ありません。 さらに Windows 7 の場合には、下図のように仮想 OS 内でもエアロが有効になります。 そのため、英語版と日本語版のちょっとしたチェックとかも実環境に近い表示イメージでできます。
XPMODE を使えるようにする前準備
PC メーカー向けの XP MODE はいきなりチュートリアルが走って、すぐに使えるようになるものではありませんでした。
単純に VHD が伸張できる EXE になっているだけです。 そのため、インストラクションに沿って、使えるようにしていきます。
- Windows XP Mode_en-US.exe を実行して、VHD を C:\WindowsXPMode\ へ伸張します (日本語版は最後が ja-jp です)
- 手動で Virtual PC を起動するための設定を行いますので、[仮想マシンの作成] から行います。 名前は "Prep for Windows XP Mode" とでもしておきます。
- 仮想ハードディスクを追加する画面で、[既存の仮想ハードディスクを使用する] を選び、1 で伸張した場所にある、Windows XP Mode base.vhd を選び、[作成] ボタンを押して作成します。
- "Prep for Windows XP Mode" を起動し、一通り必要な設定を行ったら、出荷可能状態にする必要があります。 注意:この時点では Administrator のパスワードは必ず空(設定しない) にしておくこと。 XPMUser のアカウントは無効で、パスワードは同じく空であること。
- パスワードが空の状態の Administrator でログインして(デフォルトのままであればこの状態です)、コマンドプロンプトを起動し、次のコマンドを入力します。
cd /d c:\sysprep
sysprep –quiet –mini –reseal - Sysprep ツールが出荷状態にして、VHD をシャットダウンします。
XPMODE を展開する
1. 準備ができたので、展開しますといっても同じPC上で使えるようにするだけなので、次のような内容を含むバッチファイルを作って実行します
mkdir "%PROGRAMFILES%\Windows XP Mode"
copy "C:\WindowsXPMode\Windows XP Mode base.vhd" "%PROGRAMFILES%\Windows XP Mode\"
xcopy C:\WindowsXPMode\VXPEULA.txt "%PROGRAMFILES%\Windows XP Mode\"
xcopy C:\WindowsXPMode\Key.txt "%PROGRAMFILES%\Windows XP Mode\"
xcopy C:\WindowsXPMode\Tutorial "%PROGRAMFILES%\Windows XP Mode\Tutorial" /e
2. 次に コピーされた先 %PROGRAMFILES%\Windows XP Mode\ に入っている、Windows XP Mode base.vhd の セキュリティ設定を変更します。
2-1. Administrators に対して次の権限を無効にします
Write data
Append data
Write attributes
Write extended attributes
Delete
2-2 所有者を SYSTEM に変更します(SYSTEM が一覧に出てこない場合には追加します)
3. レジストリの設定を行います。 次のような内容を含むバッチファイルを作って実行します。
reg add "HKLM\Software\Microsoft\Windows XP Mode" /v InstallDir /t REG_SZ /d "%PROGRAMFILES%\Windows XP Mode\Windows XP Mode base.vhd"
reg add "HKLM\Software\Microsoft\Windows XP Mode" /v TutorialPath /t REG_SZ /d "%PROGRAMFILES%\Windows XP Mode\Tutorial\VXPTutorial.html"
reg add "HKLM\Software\Microsoft\Windows XP Mode\XPM Custom Configuration\Default Options" /v "ui_options/seconds_to_save" /t REG_DWORD /d 60
最後のレジストリは 起動しているアプリケーションを終了させたときに、どれくらいの時間後ろで動いている仮想環境を起動しておくのかの設定で、私は 60 秒 にしました。 つまり、たとえば Internet Explorer 6 を愁傷させて、すぐに起動しなおす分には仮想環境が残っていますが、1 分経過すると仮想環境を終了させるというわけです。
XPMODE を使える状態にする
スタートメニューの Windows Virtual PC の下に表示されている、Windows XP Mode をクリックします。 すると、今までと同じようにチュートリアルが走って、XPMUser へのパスワードへの設定などを行って使えるようになります。
同じPCで使う場合、最初に作った "Prep for Windows XP Mode" は削除して大丈夫です。
というわけで、この方法を使えば企業展開などでも、どうしても XP でしか動かないアプリケーションがある場合など、あらかじめ XPMODE 上にインストールした状態で展開ができそうですね。 要は上記の "XPMODE を展開する" まで行った時点で、ImageX で Windows 7 ごと WIM にしてそれを利用してインストールすればよい気がします(試してはいませんのであしからず)
フォーラムオペレータ大久保です。いつも同じ内容ですみません。
2009 年 4 月 17 日（金曜） AM 10:00 より、フォーラム システムのメンテナンスが行われます。
ダウンタイムは発生しない見込みですが、一時的に接続できない等の現象が発生する可能性がございます。
この場合は少々時間をおいてのアクセスをお試しください。
ご利用の皆様にはご不便をおかけいたしますが、なにとぞご理解くださいますようお願いします。
こんにちは！
フォーラム オペレーターの服部清次です。
ここ最近、どういう訳か肌寒い日が続いていますが、皆さんはお元気ですか？
僕は、冬服をしまったばかりのタイミングでしたので、ちょっとビックリしています。 (^^;)
桜の開花も遅れているようですが、、、今週末は期待していいのでしょうか・・・
さて、今日は、アメリカの Visual C++ チームのブログに掲載されている Internet Explorer 8 関連のニュースを紹介してみようと思います。
こちらは、アメリカ現地時間の3月28日（土）に公開されたスレッドですので、かなり新しい情報です。
ぜひご一読ください！
＊ なお、日本語に翻訳するうえで表現のニュアンスを変えている箇所などがありますので、ご了承ください。
◆ Visual Studio 2005 および Visual Studio 2008 のウィザードでポップアップ スクリプト エラーが出る。（原題： “Some VS2005 and VS2008 Wizards Pop Up Script Error.”）
Visual C++ チームは、現行リリースされている Internet Explorer (Internet Explorer 8) のインストール後に、いくつかの VC++ ウィザードが正常に機能しなくなるということを発見しました。 この影響を受ける製品は、Visual Studio 2005 と Visual Studio 2008 で、以下のウィザードが影響を受けます。
l 関数の追加
l 変数の追加
l スマート デバイス – 新規プロジェクト作成
l スマート デバイス – クラスの追加
IE8 がインストールされているマシン上の Visual Studio 2005 および Visual studio 2008で、上記のいずれかのウィザードを起動すると、ポップアップ スクリプト エラーが出ます。 このエラーに遭遇された方のために、回避策があります。
以下の手順に従ってください。
l regedit を開く（64 ビット OS では、32 ビットの regedit を開いてください。）
l 以下のレジストリ キー内に（まだ存在しない場合は）1000 という名前の新しいキーを作成してください。
“HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones”
l 以下の内容で、作成したキーに DWORD 値を入力します。
o 名前 = 1207
o 種類 = REG_DWORD
o データ = 0x000000
なお、この回避策を Visual Studio 2005 で行なうには、Visual Studio 2005 SP1 （および Windows Vista 用 Visual Studio 2005 SP1 アップデート）がインストールされている必要があります。
以下は、この問題とその回避策の簡単な説明になります：
VC++ ウィザード エンジンは、IInternetSecurityManager インターフェイスを実装しています。 この実装では、Internet Explorer が問い合わせを行なうポリシーに基づいて特定のアクションを許可または却下します。 IE8 では、カスタム セキュリティ マネージャもまた、URLACTION_ACTIVEX_OVERRIDE_REPURPOSEDETECTION ポリシーに基づいて特定のアクションを許可または却下します。 以前の Internet Explorer では、このVC++ ウィザード エンジンが iexplore.exe プロセスの中で動作していない場合、カスタムセキュリティ マネージャにはデリゲートされませんでした。 VC++ ウィザードのカスタム ゾーンにはこのアクションに対するポリシーが存在しないため、Internet Explorer エンジンは、このアクションに失敗します。 私たちは現在、IE8 におけるこの変更が仕様であるかどうかを確認している段階で、その結果によって、おそらくウィザードまたは IE コンポーネントの修正プログラムという形で対処する予定です。
上記の回避策によって、ポリシー 1207 (URLACTION_ACTIVEX_OVERRIDE_REPURPOSEDETECTION) がゾーン 1000 （VC++ ウィザード エンジンのカスタム ゾーン）で許可されます。 これにより、ウィザードコードが意図されたとおり動作します。
この問題が原因で、皆さまにご迷惑をお掛けしましたことをお詫び申し上げます。よろしくお願いいたします。
Visual C++ チーム
大久保です。またメンテナンス関連ですみません。
2009 年 3 月 28 日（土） AM 10:00 より、フォーラム システムのメンテナンスが行われます。
メンテナンス中、一時的に接続ができない、接続に時間がかかる、投稿の反映に時間を要する等の影響が予想されます。
作業は 3 時間程度を予定しておりますが、予定より時間がかかる場合もございますのであらかじめご承知ください。
ご利用の皆様にはご不便をおかけいたしますが、なにとぞご理解くださいますようお願いします。
こんにちは！
フォーラム オペレーターの服部清次です。
皆さん、今朝の World Baseball Classic (WBC) アメリカ戦は観られましたか？
もちろん、僕は仕事中でしたので観ていませんが、、、なぜか日本が 9-4 で勝ったことを知っています。。。 (^^;)
明日の決勝戦は、今大会5度目の韓国戦！
また新たな名勝負を見せてほしいですね。
そして、ぜひ日本代表チームに WBC 2連覇を達成してほしいと思います！
さて、今日は、久々にアメリカの Windows Azure ブログに掲載されている Windows Azure 関連のニュースをお届けします。
こちらは、アメリカ現地時間の3月18日（水）に公開されたスレッドです。
＊ なお、日本語に翻訳するうえで表現のニュアンスを変えている箇所などがありますので、ご了承ください。
◆ 今週発生した Windows Azure の故障 （原題： ”The Windows Azure Malfunction This Weekend”）
まず最初に重要なことを言わなければなりません。 本当に申し訳ございませんでした。 Windows Azure の動作に不具合が生じた結果、Community Technology Preview (CTP) に参加してくださった多くの方々に、サービスの機能低下やダウンタイムといった問題が発生してしまいました。 なお、Windows Azure ストレージは影響を受けませんでした。
このスレッドの残りの部分では、不具合の内容とその影響、私たちが予定している修正について説明したいと思います。
故障の内容
3月13日（金）に行なわれた OS の定期アップグレードの最中に、ネットワークの問題により、Windows Azure 内の展開サービスの速度が低下し始めました。 これにより、多くのサーバーがタイムアウトとなり、機能を停止しました。
これらのサーバーが機能を停止した時点で、私たちは監査システムからアラートを受信しました。 同時に、ファブリック コントローラーは、影響を受けたアプリケーションを別のサーバーに移行することによって修復するという手順を自動的に開始しました。 ファブリック コントローラーは、大掛かりな修復手順を行なうにあたって非常に注意深く設計されているため、一度に少数のアプリケーションを修復し始めます。 この一連のプロセスに長い時間を要したため、私たちは並行してアップデートプロセスを続行することを決め、無事、すべてのアプリケーションを修復することができました。
影響
サーバーが停止した際、単一インスタンスのみを実行している全てのアプリケーションが停止しました。 インスタンスの停止により機能が低下したアプリケーションがありましたが、複数のインスタンスを実行している、ごく少数のアプリケーションも停止しました。
また、修復プロセスの継続中にファブリック コントローラーの作業がたまっていたため、多くのアプリケーションに関しまして、Web ポータルから管理タスクを実行する機能も利用できなかったようです。
将来的な防止策
私たちは、今回の経験から多くのことを学びました。 私たちはネットワークの問題に対処し、故障に対して素早く的確に対応できるように、修復アルゴリズムを改善／調整する予定です。
アップグレード中にも継続して利用するために、アプリケーションの所有者の皆さんには、各ロールの複数のインスタンスでアプリケーションを展開することをお勧めします。 私たちは、プロジェクト テンプレートやサンプルにおいて、2つをデフォルトとする予定です。 クォータ制限に対する2つ目のインスタンスは数えませんので、CTP に参加されている皆さんは、各アプリケーション ロールの2つのインスタンスを快適に実行することができます。
こんにちは！
毎度お馴染み、フォーラム オペレーターの服部清次です。 (^^)
いよいよ、あと約1時間で World Baseball Classic (WBC) 第2ラウンドの韓国戦が始まりますね。
前回は無念の完封負けを喫してしまった相手なので、今回はしっかり勝ってほしいと思います！
さて、今日は、昨日投稿しましたスレッドの中の「2009年1月に公開された Windows Azure SDK と Windows 7 ベータ版との互換性（原題： "Windows Azure Jan 2009 SDK compatibility with Windows 7 Beta"）」で登場していました David Lemphers のブログ記事をご紹介させていただきます。
彼は、ワシントン州 Redmond にあるマイクロソフト本社の Windows Azure チームでシニア プログラムマネージャーを務めています。
ぜひ昨日のスレッドと併せて、お楽しみください！ (^_^)v
＊ なお、日本語に翻訳するうえで表現のニュアンスを変えている箇所などがありますので、ご了承ください。
◆ Windows 7 ベータ版で Windows Azure SDK を動かす！（原題： ” Windows Azure SDK on Windows 7 Beta!”）
最近、SDK および Visual Studio 用ツールや Windows 7 ベータ版がリリースされたことを受けて、皆さんの中には、両方をあわせて試された方がいらっしゃるかもしれません。。。
実は、すでに試したにもかかわらず機能しないパーツがあり不思議に感じている方や、まだ試しておらずこれから試そうと考えている方、まだ試していないが（私が去年のマイクロソフト従業員向けクリスマスパーティで着たような）藤色の伸縮性ベロアパンツを着たら似合うのではないかと思っていた方のために、ちょっとした情報があります。
まず最初に、Windows 7 ベータ版で SDK （ツールではありません）を実行した場合、問題が生じます。 原則的に、SDK をインストールすることは可能ですが、ローカルの開発ファブリックでプロジェクトを実行しようとした際につまずいてしまいます。
2つ目に、私たちは Windows 7 チームと共に、この問題に積極的に取り組んでいますので、解決策が見つかり次第、皆さんに報告させていただく予定です。
当面はどうすればよいのかですって？ 私の個人的なアプローチは、VSTS 2008 SP1/TFS SP1 無料評価版 Virtual PC （2009年12月31日に有効期限が切れますが、この問題を解決するには充分な時間があるはずです）をダウンロードし、その上に SDK をインストールした後、Virtual PC 2007 SP1 の中で起動しています。
更新： 実は、またしても、私は大急ぎでスレッドを投稿してしまい、私の良くない推測のせいで、多くの皆さんの時間を無駄にする結果となってしまいました。。。 本当に本当に申し訳ございません！ 何が起きたのかですって？ 実は、Windows 7 と Windows Azure SDK の問題を切り抜けるために、私は、デモ用にノート PC 上で Virtual PC 環境を実行しています。 この Virtual PC は、私が社内で入手したものなのですが、私は、これが Windows Server 2003 上で動作する VSTS 2008 だと思っていました。 SDK をインストールしたところ快適に動いたので、自分が使用しているものと同一であると私が思って（推測して）いた一般公開の Virtual PC を皆さんに紹介するために、上記の内容を投稿しました。L ところが、実際はそうではありませんでした。 私が実際に使用していたのは、Windows Server 2003 ではなく Windows Server 2008 であることが分かりました。 私が使用しているものをここに投稿することはできませんので、回避策を1つ紹介したいと思います。
手順 1. こちらから Windows Vista または Windows Server 2008 の基本 VHD を手に入れてください。
手順 2. Visual Studio 2008 の評価版をダウンロードして、インストールしてください。
手順 3. その上に Windows Azure SDK と Visual Studio 用 Windows Azure ツールをインストールしてください。
へまをやらかしてしまい、本当にすみませんでした。ぜひお楽しみください！ J
