皆さん、こんにちは。Windows サポート チームの神田です。

本日は、エラーとしてイベント ログに記録されるが、対策や処理などは必要のないイベントについて説明いたします。
後述するイベントは、ご利用いただいているシステムやユーザー環境に影響がなく、特別な対策を取る必要は無いものですが、Windows として「エラー」と記録するように規定されており度々お客様から質問があるため、ブログとして情報を公開させていただきました。

– 事象
Windows の起動時やログオン時、アプリケーション イベント ログに以下のイベントが記録される場合があります。
——————————————————–
ソース:           ESENT
イベント ID:       490
説明:
svchost (nnnn) Unistore: 読み取りまたは書き込みのためにファイル “”C:\Users\<User_Name>\AppData\Local\Comms\UnistoreDB\USS.jtx”” を開こうとしましたが、システム エラー 32 (0x00000020): “”プロセスはファイルにアクセスできません。別のプロセスが使用中です。 “” が発生したため開けませんでした。ファイルを開く処理は、エラー -1032 (0xfffffbf8) のため失敗します。
——————————————————–
ソース:           ESENT
イベント ID:       454
説明:
svchost (nnnn) Unistore: 予期しないエラー -1032 が発生したため、データベースの回復または復元に失敗しました。
——————————————————–
ソース:           ESENT
イベント ID:       489
説明:
svchost (nnnn) Unistore: 読み取るためにファイル “”C:\Users\<User_Name>\AppData\Local\Comms\UnistoreDB\USS.jtx”” を開こうとしましたが、システム エラー 32 (0x00000020): “”プロセスはファイルにアクセスできません。別のプロセスが使用中です。 “” が発生したため開けませんでした。ファイルを開く処理は、エラー -1032 (0xfffffbf8) のため失敗します。
——————————————————–
ソース:           ESENT
イベント ID:       455
説明:
svchost (nnnn) Unistore: ログ ファイル C:\Users\Administrator\AppData\Local\Comms\UnistoreDB\USS.jtx を開いているときに、エラー -1032 (0xfffffbf8) が発生しました。
——————————————————–
ソース:           Service Control Manager
イベント ID:       7023
説明:
User Data Access_nnnn サービスは、次のエラーで終了しました: クラスが登録されていません
——————————————————–

– 説明
上記のイベント内に記載されている UnistoreDB とは、UnistoreSvc (User Data Storage) と呼ばれるサービスにより参照されているデータベースです。サービスのプロセスがデータベース ファイルへアクセスを試みた際に、既にほかのプロセスが排他的にファイルへアクセスしていると、共有違反 (ERROR_SHARING_VIOLATION) が発生します。その場合、上述したエラーがアプリケーション イベント ログに記録されます。

UnistoreDB が既に排他でファイル アクセスされている要因の一つとして、同一のアカウントでリモート デスクトップのセッションが複数
確立している場合等が考えられます。

UniStore のデータベースはユーザー単位で保持される情報になり、当該データベースにアクセスできない状況でもシステム全体への影響はありません。また、データベースへのアクセスが次回の試行時に成功すれば、データベースの更新は正常に行われるため、エラーが発生した場合の対策を実施する必要はありません。
Windows Server 2016 の標準構成におきましては、Unistore サービスへのアクセスを行うアプリケーションがインストールされていない状況になりますので、サーバーのエディションにかぎりましては、Unistore に関連するエラー イベントの記録されている場合にも、業務に影響が発生することはありません。

– 補足
UnistoreSvc サービスは、連絡先情報、予定表、メッセージ、その他のコンテンツなどのユーザー データを管理しており、アプリケーションへのデータ アクセスを提供しております。

– 参考資料
Per-user services in Windows 10 and Windows Server
https://docs.microsoft.com/en-us/windows/application-management/per-user-services-in-windows
UnistoreSvc : User Data Storage
Handles storage of structured user data, including contact info, calendars, and messages. If you stop or
disable this service, apps that use this data might not work correctly.

こんにちは。Windows プラットフォーム サポートの加藤です。

本日は、Hyper-V クラスター環境で、クラスター対応更新 (CAU) の実行中にライブ マイグレーションがメモリ不足で失敗し、クラスター対応更新が停止する事象についてご案内いたします。

クラスター対応更新では、更新プログラムの適用時に、役割のドレイン (他のノードに退避) やノードの再起動、再起動完了後のフェールバックを自動で実施しますが、Hyper-V クラスター環境では、このフェールバックのライブ マイグレーションがメモリ不足で失敗する場合がございます。

これは、クラスター対応更新の実施時に、ドレインとフェールバックのライブ マイグレーションが状況によっては、同時に実施される可能性があるためです。

ドレインでは、移動時に全ノードのメモリの空き容量を確認し、各ノードのメモリ使用率が均等になるように、各仮想マシンの移動先を決定するため、メモリ不足で失敗することはありませんが、フェールバックでは、ノードのメモリの空き容量は考慮せず、必ず元のノードに戻ろうとします。

そのため、フェールバック先のノードのメモリがドレインで移動してきた仮想マシンによって全て使われてしまうと、フェールバックのライブ マイグレーションがメモリ不足で失敗します。

以下に、この時のシナリオを記載します。
—————–
1. ノード1が修正プログラムのインストールのために、ノード 1 の仮想マシンを他のノードに退避するためにドレインを開始します。ノード1上の仮想マシンはライブ マイグレーションにて、各ノードに分散されます。

2. ノード1の修正プログラム適用が完了し、再起動も完了すると、各ノードに分散していた仮想マシンは、ライブ マイグレーションにて、ノード1 へフェールバックを開始します。

3. 直後にノード2が修正プログラムのインストールのために、他のノードに退避するためにドレインを開始します。ノード 2 の仮想マシンはライブ マイグレーションにて、各ノードのメモリ使用状況を確認し、分散を開始します。

4. この時、ノード2のライブ マイグレーションのキューにはドレインによってノード 1 に移動する仮想マシンがいます。更にフェールバックでノード1 に移動する仮想マシンもライブ マイグレーションのキューに入ります。

5. ライブ マイグレーションのキューの処理順番は、ライブ マイグレーションが開始された順番とは関係ないため、場合によってはドレインの仮想マシンが先に移動され、フェールバックの仮想マシンは後に回されることがあります。

6. フェールバックは、移動先のメモリの空き容量は考慮せず、必ず元のノードに戻ろうとするため、ドレインで移動した仮想マシンでノード1のメモリが使われてしまうと、フェールバックの仮想マシンがメモリ不足でライブ マイグレーション失敗します。
—————–

上記の事象は、一般的には、仮想マシンの数に対して、メモリの空き容量に余裕がない場合に発生します。
例えば、10 ノードクラスターの環境で、1 ノードを停止した際に、残りの 9 ノードのメモリをほぼ使い切ってしまう環境です。

上記事象は以下の 2 つの回避策があります。

1. クラスター対応更新でフェールバックを無効にする。
2. 指定時間 WAIT するスクリプトを作成し、クラスター対応更のPreUpdateScriptまたはPostUpdateScript に登録します。

1. フェールバックの無効化
===================
GUI で CAU を設定すると、フェールバックが有効となるため、フェールバックを無効にするためには、Set-CauClusterRole コマンドで設定する必要があります。

1) Get-CauClusterRole コマンドで現在の CAU の設定が確認できますので、まずは現在の設定を確認します。

2) Set-CauClusterRole のコマンドを 1) で確認した設定と -FailbackMode NoFailback を引数で指定して実行します。

Set-CauClusterRole -FailbackMode NoFailback -＜他の設定の引数＞

Set-CauClusterRole
https://docs.microsoft.com/ja-jp/previous-versions/windows/powershell-scripting/hh847234(v=wps.630)

— 抜粋 —
-FailbackMode

Specifies the method used to bring drained workloads back to the node, at the end of updating the node. Drained workloads are workloads that were previously running on the node, but were moved to another node.
The acceptable values for this parameter are: NoFailback, Immediate, and Policy. The default value is Immediate.
——

2. クラスター対応更のPreUpdateScriptまたはPostUpdateScript を使用する。
===================
クラスター対応更新の設定で、フェールバックとドレインの間にWAITを入れ、時間調整することでドレインとフェールバックの競合を避けます。
具体的には、PowerShellコマンドのStart-Sleepを使用して、指定時間 WAITするスクリプトを作成し、作成したスクリプトをCAUのオプションのPreUpdateScriptまたはPostUpdateScriptで設定します。

例：20分(1200秒)WAITする場合
テキストファイルに以下のコマンドを記載し、拡張し ps1 で保存します。

Start-Sleep -s 1200

作成したスクリプトを全ノードの同じパスに配置して、以下の PreUpdateScriptまたはPostUpdateScriptにてパスを指定します。

これにより、ノードの再起動完了から次のノードのドレインが開始されるまで、待ち時間を設定することができますので、ドレインとフェールバックのライブ マイグレーションが重なる状況を防げます。
必要なWAIT時間は環境によって異なりますが、ドレイン時に各ノードに 10 台ずつ分散される環境の場合には、10 台のライブ マイグレーションが完了する時間を計測して、その時間の 1.5倍で設定します。
足りない場合には、更に WAIT 時間を延長します。

このブログが皆様のお役に立てれば幸いです。

Windows プラットフォーム サポートの佐々木です。

2018 年 9 月 第 3 週に公開しました更新プログラムや、より新しい更新プログラムを適用した環境では、有効化したタスクが実行されない事象が発生する可能性があります。
現在、本事象の発生原因の調査、および修正に向けた対策を進めています。本事象の調査状況につきましては、本ブログにて随時更新予定です。

事象の発生条件

以下の Windows へ、2018 年 9 月 第 3 週以降の更新プログラムが適用されている場合に発生します。

• Windows Server 2016
• Windows 10 Version 1607
• Windows 10 Version 1709

2018 年 9 月 第 3 週以降に公開しました更新プログラムはこちらです。
これ以降の更新プログラムを適用した場合も同様の問題が発生する可能性があります。

Windows Server 2016 / Windows 10 Version 1607 用:
2018 年 9 月 21 日 — KB4457127 (OS ビルド 14393.2515)
https://support.microsoft.com/ja-jp/help/4457127/

Windows 10 Version 1709 用:
2018 年 9 月 27 日 — KB4457136 (OS ビルド 16299.699)
https://support.microsoft.com/ja-jp/help/4457136/

事象の概要

以下の 2 つのシナリオで問題が発生します。

• 事前に無効化してエクスポートしておいたタスク (XML) をインポートし、その後 有効化しても、スケジュールされた時刻に実行されません。
• タスクを無効化した状態でシステムのシャットダウン、再起動を行い、その後 有効化しても、スケジュールされた時刻に実行されません。

回避策

タスクを有効化後に、再度、無効化 -> 有効化の手順を実施することで、回避可能です。
※ 1 度の有効化ではタスクが実行されませんが、その後、もう 1 度有効化することで、タスクが実行されることを確認しています。

事象の再現手順

以下にて、1 つ目のシナリオを用いた事象の再現手順を記載します。

1. 作成したタスクを無効化します。

2. 無効化したタスクをエクスポートします。

3. Test タスクを削除して、手順 2. でエクスポートしたタスクをインポートします。

4. インポートされた Test タスクは、無効化されています。次回実行時刻は、2018/10/25 17:00:00 です。

5. Test タスクを有効化します。

6. 次回実行時刻である、2018/10/25 17:00:00 になると、次回実行時刻は、2018/10/26 17:00:00 に更新されますが、タスクが実行されません。

※ 2018/10/26 17:00:00 以降もタスクは実行されません。

みなさん、こんにちは。Windows サポートの神田です。

今回は、Windows Powershell の入力において発生する表示の問題について記載します。
なお、本事象は Windows 10、Windows Server 2016 以降のオペレーティング システムで発生します。
また、問題は表示上のみであり、スクリプトの実行には影響はありません。

– Powershell モジュール PSReadLine について
Windows Powershell には、コンソールに入力した内容に応じて、自動的に色分けを行うモジュール PSReadLine が提供されています。このモジュールが有効な場合、入力内容に応じて画面上の文字に自動で色付けが行われます。
例えばコマンドは黄色、変数は緑色、コマンド オプションは灰色、といった感じで色付けが行われます。

このモジュールは上記のようにスクリプトを入力する際には非常に便利なのですが、入力文字に日本語など 2 バイト文字と呼ばれる文字が含まれる場合 – 例えばファイル名やアイテム名など – に、コンソール画面上で編集を行うと画面の表示に問題が生じる場合があります。

問題の事象は、文字をダブルクォーテーション ( ” ) でくくっていて、その文字を操作した場合に発生します。

例えば、以下のようにファイル名に日本語を含んだパスを指定してプログラムを起動する場合ですが、ファイルまでのパスを Powershell のコンソールに一度 $path に代入するためにペーストしたとします。$path を指定して、プログラムはそのファイルを正常に開くことができます。

上記のパスですが、途中に空白などは開いていないので、ダブルクォーテーション ( ” ) を外そうとすると、パスの末尾と先頭のダブルクォーテーションを削除した段階で、表示がおかしくなってしまいます。なお、内部的には正しくダブルクォーテーションが除かれたパスが格納されるので、$path を指定してファイルを開く事は可能です。

上記のように、表示上の問題となりますが、編集しているうちに正しいパスが画面上で確認できなくなってしまうため、コンソール上での編集が正しく行えない状況となってしまいます。
これは、先に記述した Powershell モジュール PSReadLine の想定しない動作により発生する問題です。

本事象は、Windows の Powershell の問題として認識しており、次期バージョンにて問題が修正されるよう障害情報には登録をしております。
なお恐れ入りますが現行製品では現時点で修正は予定されておりません。その場合は、モジュール PSReadLine をアンインストールすることで表示が不正となる問題は発生しなくなります。

// PSReadLine のアンインストール コマンド
Remove-Module PSReadline

※ ご注意
上記コマンドにて PSReadLine をアンインストールすると、文字の表示を色付けする機能が無効になるため、入力中の色分けが行われなくなります。
ご利用いただいている環境や運用状況に応じて、パスやファイル名、アイテム名を 1 バイト文字に統一するか、PSReadLine をアンインストールして色分け機能を無効にした状態で使用するか、いずれかをご検討いただきますようお願いいたします。

– 参考資料
PSReadLine
https://docs.microsoft.com/en-us/powershell/module/psreadline/?view=powershell-6

Use PSReadLine for More Efficient PowerShell Console
https://blogs.technet.microsoft.com/heyscriptingguy/2015/04/28/use-psreadline-for-more-efficient-powershell-console/

こんにちは。日本マイクロソフト Windows Deployment サポート チームです。

今回は、OEM 版の Windows 10 がプリインストールされている端末において、ライセンス認証が正常に完了しなかった場合に、プロダクト キーの再インストールおよびライセンス認証を行う方法をご案内いたします。

＜環境＞
Windows 10 Pro

＜手順の流れ＞
A) OEM プロダクト キーの確認
B) プロダクト キーの再インストール
C) ライセンス認証
D) 現在のライセンス認証の状態の確認

＜手順詳細＞

A) OEM プロダクト キーの確認

A-1) コマンド プロンプトを管理者権限で起動します。

A-2) 以下のコマンドを実行し、OEM プロダクト キーを表示します。

wmic path SoftwareLicensingService get /value | findstr OA3x
※ コマンド末尾の “OA3x” は、”OA” のみ大文字で入力します。

A-3) 手順 A-2 のコマンドの実行結果の “OA3xOriginalProductKey=” より、プロダクト キー (25 桁) を確認します。

B) プロダクト キーの再インストール

以下のコマンドを実行し、手順 A-3 で確認したプロダクト キー (25 桁) を再インストールします。

– 書式
cscript %WinDir%\system32\slmgr.vbs /ipk ＜プロダクト キー＞

– 例
cscript %WinDir%\system32\slmgr.vbs /ipk AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

C) ライセンス認証

インターネットに接続してライセンス認証を行う方法と、電話によるライセンス認証を行う方法がございますので、それぞれの方法をご案内します。

◆ インターネットに接続している場合

——————————————————————
C-1) 以下のコマンドを実行し、ライセンス認証を行います。
cscript %WinDir%\system32\slmgr.vbs /ato

C-2) コマンドの実行結果に、正常にライセンス認証された旨のメッセージが表示されたことを確認します。

◆ インターネットに接続していない場合 (電話によるライセンス認証)

—————————————————————————————————————–
※ インターネットに接続してライセンス認証を行った場合は、この後の手順 C-a ～ C-e を行う必要はございません。

C-a) 以下のコマンドを実行し、電話によるライセンス認証を行うための画面を表示します。

slui.exe 4

C-b) [国または地域を選んでください] と表示されましたら、[日本] を選択し [次へ] をクリックします。

C-c) 画面に表示された弊社のライセンス認証窓口 (0120-801-734) に電話をおかけください。
電話の音声ガイダンスに従って、画面に表示されているインストール ID を電話機で入力します。
入力が完了しましたら [確認 ID を入力] ボタンをクリックします。

C-d) 電話の音声ガイダンスに従って、電話で応答のあった確認 ID を画面に入力し、[Windows のライセンス認証] ボタンをクリックします。

C-e) ライセンス認証が完了すると、手続きが完了した旨のメッセージが表示されますので、[閉じる] をクリックします。

D) 現在のライセンス認証の状態の確認

D-1) コマンド プロンプトを起動します。

D-2) 以下のコマンドを実行し、現在のライセンス認証の状態を確認します。

cscript %WinDir%\system32\slmgr.vbs /dlv

“ライセンスの状態” に “ライセンスされています” と表示されていれば問題ございません。

本ブログが少しでも皆様のお役に立てますと幸いです。

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは。日本マイクロソフト株式会社 高谷 です。

弊社では、Windows Server バックアップでのバックアップ取得に失敗するというお問い合わせを多くいただいております。
原因は様々ございますが、今回のブログではVSS Writer が全て消失してしまうことによりバックアップが取得できない、という事例についてご紹介したいと思います。
もし、お客様の環境で Windows Server バックアップによるバックアップが取得できない事象が発生している場合は、この事例に合致するかご確認ください。合致する場合は比較的容易に改善が可能ですので、対処方法をお試しください。

■ VSS Writer とは？

.
VSS Writer とは、ボリューム シャドウ コピー サービス (VSS) を構成する 4 つのコンポーネントのうちの 1 つです。

VSS サービスからの指令により、シャドウ コピーを作成するために、各アプリケーションを一旦静止する役割を持っています。アプリケーションごとに存在し、各 VSS ライターは自身に紐づいたアプリケーションの静止処理を行います。

ボリューム シャドウ コピー サービス (VSS) とVSS Writer については以下のブログにて詳しくご説明しています。よろしければこちらをご覧ください。

– 公開情報
ボリューム シャドウ コピー サービス (VSS) について
https://blogs.technet.microsoft.com/askcorejp/2018/08/15/aboutvss/
.

■ VSS Writer の確認方法

.
お客様の環境にどのようなVSS Writer が存在するかは、vssadmin コマンドで確認が可能です。各 VSS Writer のステータス等も確認が可能です。

正常な環境での vssadmin コマンド実行例
—————————————————————————————

C:\Windows\system32>vssadmin list writers
vssadmin 1.1 – ボリューム シャドウ コピー サービス管理コマンド ライン ツール
(C) Copyright 2001-2013 Microsoft Corp.

ライター名: ‘System Writer’
ライター Id: {a1111111-1a11-2222-a33a-1050253ae220}
ライター インスタンス Id: {a1111111-1a11-2222-a33a-eacf897c2bb2}
状態: [1] 安定
最後のエラー: エラーなし

ライター名: ‘ASR Writer’
ライター Id: {a1111111-1a11-2222-a33a-531aa6355fc4}
ライター インスタンス Id: {a1111111-1a11-2222-a33a-3f05d6e23c18}
状態: [1] 安定
最後のエラー: エラーなし

ライター名: ‘Registry Writer’
ライター Id: {a1111111-1a11-2222-a33a-71dbb18f8485}
ライター インスタンス Id: {a1111111-1a11-2222-a33a-5a769b979293}
状態: [1] 安定
最後のエラー: エラーなし

ライター名: ‘WMI Writer’
ライター Id: {a1111111-1a11-2222-a33a-49d8f43532f0}
ライター インスタンス Id: {a1111111-1a11-2222-a33a-d7228e01237e}
状態: [1] 安定
最後のエラー: エラーなし

ライター名: ‘COM+ REGDB Writer’
ライター Id: {a1111111-1a11-2222-a33a-7847f01fc64f}
ライター インスタンス Id: {a1111111-1a11-2222-a33a-6b3475ddad24}
状態: [1] 安定
最後のエラー: エラーなし

ライター名: ‘Shadow Copy Optimization Writer’
ライター Id: {a1111111-1a11-2222-a33a-3bee2926fd7f}
ライター インスタンス Id: {a1111111-1a11-2222-a33a-f0ba3a6d115c}
状態: [1] 安定
最後のエラー: エラーなし

—————————————————————————————

例えば上記のような結果が出た場合は、6 種類の VSS Writer が存在し、すべての Writer のステータスが安定していることが確認できます。今回ご紹介する事例では、これらの VSS Writer が「全て」消えてしまう事象です。
.

■ VSS Writer が全て消失してしまうことによりバックアップが取得できない事例のご紹介

.
バックアップ取得に失敗しているお客様は、以下にご紹介する確認ポイントをご確認いただき、合致するようであれば後述の対処方法をお試しください。

.
確認ポイント (1) ：vssadmin コマンドの実行結果

今回ご紹介する事例の最大の特徴は、Vssadmin コマンドの結果、VSS Writer が 1 つも表示されない点です。まずは VSS Writer が表示されるかどうかご確認ください。

vssadmin コマンド実行結果
———————————————————————————–

C:\Windows\system32>vssadmin list writers
vssadmin 1.1 – ボリューム シャドウ コピー サービス管理コマンド ライン ツール
(C) Copyright 2001-2013 Microsoft Corp.
.

———————————————————————————–
※ VSS Writer が一つも表示されません！！

.
確認ポイント (2) ：環境の確認

事象が報告されている環境は以下の通りですが、これ以外の環境でも発生する可能性はあります。
こちらは参考程度にご確認ください。

・OS: Windows Server 2012R2
・VMWare 環境上の仮想サーバー
・Windows Server バックアップで、サーバー全体のバックアップを日次で実行
.

確認ポイント (3) ：ソース:VSS のエラーのイベント ログ

バックアップ失敗のタイミングでイベント ログにソースを VSS とする複数のエラーが記録されているか、ご確認ください。

ソース:VSS、ID:8193 のエラーのイベント ログ
———————————————————————————–

レベル:エラー
日付と時刻:2018/10/01 21:00:19
ソース:VSS
ID:8193
メッセージ:ボリューム シャドウ コピー サービス エラー: ルーチン CoCreateInstance の呼び出し中に予期しないエラーが発生しました。
hr = 0x800401fb, Object is not registered.

Operation:
Subscribing Writer

Context:
Writer Class Id: {ee000eee-11ee-4422-9c9c-531aa6355aa6}
Writer Name: ASR Writer
Writer Instance ID: {ee000eee-11ee-4422-9c9c-cb9a0863baa6}

———————————————————————————–
※ Writer Name は環境によって異なります。複数の Writer で表示される場合が多くございます。

ソース:VSS、ID:13 のエラーのイベント ログ
———————————————————————————–

レベル:エラー
日付と時刻:2018/05/09 21:00:19
ソース:VSS
ID:13
メッセージ:ボリューム シャドウ コピー サービス情報: CLSID {2222aaaa-2ee2-11d1-9944-00c04fbbb111} および名前 CEventSystem を持つ COM サーバーを開始できません。[0x800401fb, Object is not registered]

Operation:
Subscribing Writer

Context:
Writer Class Id: {ee000eee-11ee-4422-9c9c-531aa6355aa6}
Writer Name: ASR Writer
Writer Instance ID: {ee000eee-11ee-4422-9c9c-cb9a0863baa6}

———————————————————————————–
※ Writer Name は環境によって異なります。複数の Writer で表示される場合が多くございます。

VSS Writer に何らかの異常が発生していることが、エラーのメッセージから読み取れます。
.

確認ポイント (4) ：COM+ Event System サービスのプロセス svchost.exe の実行状況

この事象のもう一つの大きな特徴として、COM+ Event System サービスのプロセスである svchost.exe に、他のサービスが同居していることが挙げられます。Tasklist コマンドで svchost.exe の状況をお確かめください。
単一のプロセスとして COM+ Event System サービスのプロセス svchost.exe が実行されている場合は、この事例には当てはまりません。
.

Tasklist コマンド実行結果の例)
———————————————————————————–

C:\Windows\system32>tasklist /svc |findstr /i svchost

Image Name       PID     Services
===========  ====   ============================
svchost.exe        816      EventSystem, FontCache, netprofm, nsi

———————————————————————————–

この例のコマンド実行結果では、COM+ Event System サービスは、Windows Font Cache サービス(Fontcache)、Network List Service サービス(netprofm)、Network Store Interface サービス(nsi) が同居していることがわかります。
.

■ 対処方法

.
VSS Writer は呼び出される際に COM+ Event System サービスと連動して呼び出されます。
従って、COM+ Event System サービスに問題が発生していると、VSS Writer との通信が正常に行えません。
COM+ Event System サービスのプロセス svchost.exe にて、同居する別サービスが異常な動作を行ったことによって COM+ Event System サービスが影響受け、VSS Writer が呼び出しに応じられなくなるような事例が複数報告されております。
再び VSS Writer が呼び出しに応じることができるようになるためには、異常なサービスを正常に戻す、もしくはサービスを分離してしまう方法が効果的です。

お客様の環境で起きている事象が、以上の 4 つの確認ポイントに合致している場合は、次の対処方法を実行いただくことで事象が改善する可能性が高いです。
次の内からどれか一つを実行ください。
.

対処方法（1）サーバー再起動

サーバー再起動によってプロセスがリセットされ、異常な状態となっているサービスも起動しなおします。サーバー再起動が可能な状況であればサーバー再起動をお試しください。この対処方法の場合、一時的に事象は改善しますが、しばらく時間が経過すると事象が再発することがあります。
.

対処方法（2）サービス再起動

サーバー再起動ができない場合は、確認ポイント（4）で表示されたサービスを全て再起動してください。
この対処方法の場合、一時的に事象は改善しますが、しばらく時間が経過すると事象が再発することがあります。
.

対処方法（3）サービス再起動および各プロセスの分離

サービス再起動時に複数のサービスをホストする svchost.exe プロセスから、COM+ Event System サービスを分離することで、COM+ Event System サービスが他のサービスからの影響を受けずに動作することができます。
.

=============================
サービスの分離方法
=============================

手順 1. コマンド プロンプトを管理者として起動し、Tasklist のコマンドにて COM+ Event System サービスをホストしている svchost.exe を確認します。※ 確認ポイント（4）と同様のコマンドです。

Tasklist コマンド実行結果の例)
———————————————————————————–

C:\Windows\system32>tasklist /svc |findstr /i svchost

Image Name       PID     Services
===========  ====   ============================
svchost.exe        816      EventSystem, FontCache, netprofm, nsi

———————————————————————————–

手順 2. sc config のコマンドにて、COM+ Event System サービスを分離します。

構文)
sc config <サービス名> type= own

sc config コマンドの例)
———————————————————————————–

sc config EventSystem type= own

———————————————————————————–

手順 3. “手順 2.” で分離したCOM+ Event System サービスを services.msc などから再起動します。サーバーの再起動でも問題ございません。再起動すると、単一の svchost.exe にて起動しますので、正常に起動したかを確認します。

Tasklist コマンド実行結果の例)
———————————————————————————–

C:\>tasklist /svc |findstr /i svchost

Image Name       PID     Services
===========  ====   ============================
svchost.exe         816      FontCache, netprofm, nsi
svchost.exe        1025      EventSystem

———————————————————————————–

このように、COM+ Event System サービスが他のサービスから分離され、独立した svchost.exe のプロセスとして動作していることが確認できます。

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てますと幸いです。

今回は、入力する文字や使用するフォントの差によって、文字幅が異なる場合がある事象についてご案内いたします。

同じ文字、たとえば「し」を入力した際、その文字の前後に来る文字が「しす」や「して」のように変わることによって、
「し」という文字単体で入力いただいた際と文字幅が変化する場合がございます。

このような事象の原因ですが、1 つのフォントの中に、特定の文字に対するグリフがひとつだけではなく複数含まれていることに起因します。
どのフォントでもこのようになっているわけではありませんが、これは、主に以下のような機能を実現するために用意されています。

– 読みやすさのため、横書き向けと縦書き向けにそれぞれ用意された異なる字形を選択する
– 毛筆風を再現するために前後の文字ときれいにつながるような字形を選択する
– 画数の多い漢字の直後にシンプルなひらがなが来る場合等、バランスを考慮して若干大きさの異なる字形を用意し選択する

フォントに含まれる字形のバリエーションや字形選択のロジックに依存するため、
フォントの種類やバージョンによっても、変化する文字幅の量や変化する文字同士の組み合わせが変化いたします。
また、すべてのフォントがこのような処理を行ってはいないため、全く事象が発生しないフォントもございます。

この事象によって、テキストの行末の折り返し位置が変わったり、行末がきれいに揃わない等の差異が発生する場合がございますが、
Windows の設定等で制御することはできず、フォントまたは文字列を変更いただくことでしかご対応いただけません。

必ず文字間で同じ文字幅であることが要求される文書を作成される際には、「ＭＳ ゴシック」や「ＭＳ 明朝」など、等幅フォントをご利用ください。

Windows に付属の游ゴシック フォント ファミリーおよび游明朝 フォント ファミリーにおいても、
バージョンや種類による差異はございますが、前述の事象が発生することを検証により確認いたしました。下記表をご覧ください。

<テスト結果>
※表内の数字はフォント ファイルのバージョンとなります。

× : 「し」と、「しす」の「し」の文字幅が異なる
〇 : 「し」と、「しす」の「し」の文字幅が同じ

こんにちは、Windows デプロイ サポート チームの弓正です。

Windows 10 Version 1803 以降の環境において Cookie が正常に保存できない事象が確認されております。
この事象に起因し、Internet Explorer の Cookie を利用する他社製品も影響を受ける可能性がありますので、
本事象についてご紹介いたします。

この事象が発生するシナリオは以下の2つです。
・Windows 10 Version 1709 の環境にて Sysprep による CopyProfile を使用してイメージ展開を行った後、機能更新を適用した場合
・Windows 10 Version 1803 もしくはそれ以降の環境にて Sysprep による CopyProfile を使用してイメージ展開を行った場合
(Windows 10 Version 1703 もしくはそれ以前の環境で Sysprep による CopyProfile を使用してイメージ展開し機能更新適用しても本事象は発生しません。)

本事象の対処方法をマスターイメージ作成段階、展開済みの段階、それぞれ記載いたします。

マスター イメージの作成段階で本事象を回避する場合、以下の手順を実施してください。
——————————————————————–
1. マスター イメージを作成している端末においてメモ帳を開き、以下の内容を記載し、”SetupComplete.cmd” のファイルー名で、一旦任意の場所に保存します。

————-
rmdir /s /q c:\Users\Default\AppData\Local\Microsoft\Windows\Webcache
rmdir /s /q c:\Users\Default\AppData\Local\Microsoft\Windows\INetCache
del %0
————-
※ del %0 コマンドで、実行後に自分自身の .bat ファイルも削除し、展開後のテンプレートに残らないようになっております。

2. 保存した “SetupComplete.cmd” ファイルをテンプレートの
以下のフォルダー内に保存します。

C:\Windows\Setup\Scripts
※ Scripts フォルダは既定で存在しませんので新規に作成します。

3. これまでの手順で Sysprep を行います。
———————————————————————-

すでに展開済みの環境で問題が発生している場合、以下のスクリプトを vbs 形式で保存し、対象環境に管理者権限で実施していただくことで、既存ユーザーおよび新規ユーザーに対して事象が解消されます。
———————————————————————-
On Error Resume Next
Dim objFileSys
Dim objFolder
Dim objSubFolder

strUsersFolder = “C:\Users\”
strWebCacheFolder = “\AppData\Local\Microsoft\Windows\WebCache\”
strINetCacheFolder = “\AppData\Local\Microsoft\Windows\INetCache\IE\”
strINetCacheFolderLow = “\AppData\Local\Microsoft\Windows\INetCache\Low\IE\”

Set objFileSys = WScript.CreateObject(“Scripting.FileSystemObject”)
Set objShell = WScript.CreateObject(“WScript.Shell”)

‘起動中のプロセスやサービスを停止する
ret = objShell.Run(“net stop COMSysApp”,0,true)
ret = objShell.Run(“taskkill /F /IM dllhost.exe”,0,true)
ret = objShell.Run(“taskkill /F /IM taskhost.exe”,0,true)
ret = objShell.Run(“taskkill /F /IM taskhostex.exe”,0,true)
ret = objShell.Run(“taskkill /F /IM taskhostw.exe”,0,true)

‘ユーザー フォルダーを取得する
Set objFolder = objFileSys.GetFolder(strUsersFolder)

‘FolderオブジェクトのFilesプロパティからFileオブジェクトを取得
For Each objSubFolder In objFolder.SubFolders

‘削除しなくてもよいユーザー以外の場合にのみ実行する
If objSubFolder.Name <> “All Users” And _
objSubFolder.Name <> “Public” And _
objSubFolder.Name <> “Default User” Then

‘WebCache フォルダー
strDelFolder = strUsersFolder + objSubFolder.Name + strWebCacheFolder
If objFileSys.FolderExists(strDelFolder) Then
If objFileSys.GetFolder(strDelFolder).Files.Count > 0 Then
objFileSys.DeleteFile strDelFolder + “*.*”, true
End If
End If

‘INetCache フォルダー
strDelFolder = strUsersFolder + objSubFolder.Name + strINetCacheFolder
If objFileSys.FolderExists(strDelFolder) Then
If objFileSys.GetFolder(strDelFolder).Files.Count > 0 Then
objFileSys.DeleteFile strDelFolder + “*.*”, true
End If
If objFileSys.GetFolder(strDelFolder).SubFolders.Count > 0 Then
objFileSys.DeleteFolder strDelFolder + “*”, true
End If
End If

‘INetCache (Low) フォルダー
strDelFolder = strUsersFolder + objSubFolder.Name + strINetCacheFolderLow
If objFileSys.FolderExists(strDelFolder) Then
If objFileSys.GetFolder(strDelFolder).Files.Count > 0 Then
objFileSys.DeleteFile strDelFolder + “*.*”, true
End If
If objFileSys.GetFolder(strDelFolder).SubFolders.Count > 0 Then
objFileSys.DeleteFolder strDelFolder + “*”, true
End If
End If
End If
Next

‘サービスを再開する
ret = objShell.Run(“net start COMSysApp”,0,true)

Set objSubFolder = Nothing
Set objFileSys = Nothing
Set objShell = Nothing
—————————————————————————-

本ブログは予告なく変更される場合がございますのでご了承下さい。

こんにちは、Windows プラットフォーム サポートの徳永です。
本記事では、イベントビューアーで確認されております事象についてご紹介いたします。

更新履歴
2018/11/28

事象

イベント ビューアー内、右ペインの “現在のログをフィルター” にてフィルターし、”全てのイベントを名前をつけて保存” メニューで .evtx 形式以外の拡張子でイベントを保存すると、一部情報が欠落することがございます。

原因

イベント ビューアーにてフィルターしたイベントを保存する処理の中で、スレッド間の処理が競合することにより、発生している事象となります。

回避策

イベント ビューアーにて、フィルターしたイベントを保存する場合には、.evtx 形式の拡張子で保存いただくか、イベント ビューアーを使用せず、コマンドを使用してテキストに出力することで、事象を回避することができます。

下記は Get-WinEvent コマンドを使用して、日時を指定した場合のコマンド例になります。

▼ 特定の期間のイベントを .csv 形式でエクスポートする
– コマンド
　 Get-WinEvent -Filterhashtable @{Logname=’イベント名’;Starttime=’yy/mm/dd hh:mm:ss;Endtime=’yyyy/mm/dd hh:mm:ss’} | export-csv -encoding default -path

– 記述例
　 Get-WinEvent -Filterhashtable @{Logname=’System’;Starttime=’2018/09/01 10:00:00′;Endtime=’2018/11/01 01:00:00′}| export-csv -encoding default -path C:\Export.csv

▼ 特定の期間のイベントを .txt 形式でエクスポートする
– コマンド
Get-WinEvent -Filterhashtable @{Logname=’イベント名’;Starttime=’yy/mm/dd hh:mm:ss;Endtime=’yyyy/mm/dd hh:mm:ss’} | Out-File

– 記述例
Get-WinEvent -Filterhashtable @{Logname=’System’;Starttime=’2018/09/01 10:00:00′;Endtime=’2018/11/01 01:00:00′} | Out-File c:\test.txt

▼ 参考情報
Get-WinEvent
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent?view=powershell-6

wevtutil
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/wevtutil

備考

いつも弊社製品をご利用いただきまして誠にありがとうございます。
Windows プラットフォーム サポートの石田です。

今回は、Disk2VHD ツールを利用した物理環境の安全な P2V 化についてご紹介させていただきます。
Disk2VHD ツールは VSS に対応しているためオンラインで実施可能ではございますが、VSS に対応していないアプリケーションや実行時の負荷などを考慮すると、オフラインで実施いただいた方が安全かつ確実です。

ハードウェアの保守の終了に伴い P2V による仮想化をご検討いただいているお客様も増えてきておりますので、こちらの情報がお客様のお役に立てると幸いでございます。

なお、Windows Server 2008/2008 R2 など延長サポート終了を迎える製品については弊社 Azure 環境に移行することで延長サポート終了後も無償で延長セキュリティー更新プログラムの提供が受けられるメリットもございますので、是非とも Azure への移行もご検討頂ければと存じます。

まずは、以下準備を行います。

• オフライン起動用の Windows PE (WinPE) メディアの作成
• Disk2VHD ツールのインストール
• P2V 化した仮想ディスク (VHD) ファイルの保存用のディスクもしくはファイルサーバー

注意点:
今回ご紹介の Disk2VHD による P2V 化対象のシステムは BIOS 環境のシステムとなり、UEFI 環境の P2V については対応しておりませんのでご了承ください。また、Disk2VHD ツールは Windows 標準ツールではございませんのでサポート内容については使用許諾をご確認いただきご理解いただいた上でご利用ください。

Windows PE (WinPE) メディアの作成

1. 作業用の Windows 10 環境にて Windows ADK をインストールします。
Download and install the Windows ADK
>Download the Windows ADK for Windows 10, version 1809
>Download the Windows PE add-on for the ADK

2. 以下のサイトを参考に x86 版の WinPE のブートメディアを作成します。
WinPE: ブート CD、DVD、ISO、VHD の作成

copype x86 c:\WinPE_x86
MakeWinPEMedia /ISO C:\WinPE_x86 C:\WinPE_x86.iso

3. DVD または CD に書き込むには、エクスプローラーにて作成した ISO ファイルを右クリックし、[ディスク イメージの書き込み]、[書き込み] の順に選んで、指示に従います。

Disk2VHD ツールのインストール

1. 以下のサイトより Disk2VHD を取得します。

Disk2VHD
https://docs.microsoft.com/ja-jp/sysinternals/downloads/disk2vhd

2. P2V を行うマシンにコピーして、展開します。

3. C ドライブにラベル名を付けておきます。

4. システムをシャットダウンして、OS メディアから起動します。

Windows PE メディアを利用した P2V の実施

1. Windows PE メディアから起動します。
コマンド プロンプトが起動し、wpeinit の自動実行が完了するとプロンプトが戻ります。
※ 5 分から 10 分程かかる場合がございます。

2. Diskpart コマンドを実行して “list volume” と入力して “C Drive” ラベルのドライブ文字を確認します。

※ 今回の環境では、同様に C ドライブに割り当てられております。C ドライブ以外の文字が割り当てられている場合は、Disk2VHD ツールを実行するドライブ文字を割り当てられた文字に置き換えてください。

3. 事前に展開した Disk2vhd コマンドを実行します。
※ 使用許諾に同意 (Agree) していただいた上でご利用ください。

4. Disk2vhd の画面にて以下のように構成します。

– vhd 化するシステム ディスクのみにチェックをつけます。
– “Use Volume Shadow Copy” のチェックを外します。
– “VHD File name” にvhdx の保存先とファイル名を指定します。
※ ネットワークドライブを保存先に指定する場合は、後述の参考情報に記載しております IP アドレスの設定とファイルサーバーへの接続を行います。

5. “Create” をクリックして実行します。

6. 作成された仮想ディスクを確認します。

7. 正常に完了しましたら、以下のコマンドを入力してシステムを停止します。

wpeutil shutdown

参考情報

ネットワークドライブに保存するためには、IP アドレスの設定を行った上で、接続を行います。
ただし、システムに搭載されているネットワークインターフェースカード (NIC) が WinPE に含まれている標準ドライバーで認識できる必要がございます。認識されない場合は、個別にハードウェアベンダー様より提供されているドライバーを適用した状態で Windows PE メディアを作成してください。

1. コマンドプロンプトにて netsh コマンドを利用して IP アドレスを設定します。

netsh int ipv4 show int
※ 対象のネットワークアダプターの Idx の番号を確認します。
netsh int ipv4 set address "Idx の番号" static "IP アドレス" "サブネットマスク" "ゲートウェイ" "メトリック(省略可)"

2. Net コマンドにてファイルサーバーに接続します。

net use "ドライブ文字:" "共有パス" /user:"接続するアカウント" "パスワード"

3. Disk2VHD にて保存先をネットワークドライブのパスを指定します。

以上となります。

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

皆さん、こんにちは。Windows プラットフォームサポートの山崎です。
本記事では、Windows 10 1809 64bit版 におけるMSINFO32に関する技術情報をご紹介いたします。

MSINFO32は、使用しているハードウェア、システム コンポーネント、およびソフトウェアの環境に
関する情報をわかりやすく表示させるためにツールです。
既定では “msinfo32” コマンドを実行すると、 “C:\Windows\System32” 配下に存在する実行ファイル
“msinfo32.exe” が起動します。

なお、”msinfo32.exe” は、”C:\Program Files (x86)\Common Files\microsoft shared\MSInfo” 配下にも
ございますが、このフォルダの “msinfo32.exe” の実行時に必要なmuiファイルである “C:\Program Files (x86)\
Common Files\microsoft shared\MSInfo\ja-JP\msinfo32.exe.mui” がWindows 10 1809 64bit版では、OS の
イメージサイズ節約のため、OS イメージに含まれておりません。

この実装の変更にともない Windows 10 1809 64bit版 では “C:\Program Files (x86)\Common Files\microsoft shared\
MSInfo\msinfo32.exe” を起動できませんので、MSINFO32を実行する場合は、”C:\Windows\System32\msinfo32.exe”
をお使いください。

//　参考情報：システム情報 (MSINFO32) の各種スイッチの使い方
https://support.microsoft.com/ja-jp/help/300887/how-to-use-system-information-msinfo32-command-line-tool-switches

本 Blog が少しでも皆様のお役に立てれば幸いです。

Windows プラットフォーム サポートの佐々木です。

[デバイスとプリンター] 画面のプリンター アイコンの表示に時間がかかる事象のお問い合わせをいただくことが増えているため、本事象についてご紹介させていただきます。

[デバイスとプリンター] 画面でのプリンター アイコンの表示には、”Function Discovery” という枠組みを利用して、様々なデバイス情報を収集し、アイコンを表示します。この “Function Discovery” という枠組みの中で実行される、”デバイス メタデータ” の取得に時間がかかる、または取得できない場合に、プリンター アイコンの表示に時間がかかるという事象の報告があります。なお、本事象は、OS の想定する動作であり、不具合ではありません。

本ブログでは、本事象の概要、発生条件や、回避策についてご紹介いたします。

事象の概要

OS 起動直後や、プリンター追加時に、[デバイスとプリンター] 画面のプリンターのアイコンが、[未指定] にカテゴライズされ、[プリンター] にカテゴライズされるまでに時間がかかります。(下記 「図 1-1」の状態が継続します。)

図 1 [未指定] にカテゴライズされている状況

一定時間が経過すると、[未指定] から、[プリンター] にカテゴライズされます。
具体的な表示時間は、環境により異なりますため、定量的にご説明することができません。

図 2 [プリンター] にカテゴライズされた状況

事象の発生原因

本ブログの冒頭でもご説明のとおり、[デバイスとプリンター] 画面でのプリンター アイコンの表示では、”Function Discovery” という枠組みを利用して、様々なデバイス情報を収集し、アイコンを表示します。すべての場合ではありませんが、この “Function Discovery” という枠組みにおいて、インターネット経由で取得される、”デバイス メタデータ” と呼ばれる情報の取得に時間がかかる、または取得できないことにより、本事象が発生するケースが報告されています。

デバイス メタデータとは

“デバイス メタデータ” とは、機器メーカーによって提供される、デバイスに固有の情報です。[デバイスとプリンター] 画面にアイコンを表示したり、機器メーカーによって拡張された機能を提供することが可能となり、ユーザーによる対象デバイスの設定変更等が容易になるという利点がございます。また、”デバイス メタデータ” は、デバイス ドライバーの一部として提供される場合もありますが、随時の機能拡張すること目的として、Windows Update 経由で更新を行うことがあります。Windows Update 経由で “デバイス メタデータ” が取得される場合、WMIS サーバーと呼ばれるインターネット上の弊社サーバーから情報を取得します。

なお、”デバイス メタデータ” の取得が失敗した場合でも、印刷ができなくなるなどの事象に発展することはございません。”デバイス メタデータ” は [デバイスとプリンター] 画面上での表示などを制御する情報になります。

事象の発生条件

以下のような条件で、本事象が発生いたします。

・インターネットに接続できない。
・Windows Update への接続を制限している。
・Proxy サーバーなどにより、WMIS サーバーへの接続が制限されている。

上記のような条件の環境では、”デバイス メタデータ” 取得のための、WMIS サーバーへの接続が失敗し、リトライを繰り返すため、Function Discovery の枠組みでのアイコン構成が完了せず (時間がかかり)、[未指定] から、[プリンター] にカテゴライズされるまでに、時間がかかります。

本事象は、Windows Server 2012 以降の OS で発生することが想定され、Windows 7 / Windows Server 2008 R2 以前の OS では発生することは想定されません。

事象発生時の印刷の実行

“デバイス メタデータ” の取得に時間がかかる、または失敗することにより、[デバイスとプリンター] 画面のプリンター アイコンが完了しておらず、[未指定] にカテゴライズされている状況でも、印刷を実行することができます。本事象発生中に、印刷が可能であるかどうかの確認は、[コモン ダイアログ] や、[プリンター フォルダー] に、プリンター アイコンが表示されているかどうかにより、ご確認いただくことができます。本事象は、[デバイスとプリンター] 画面の表示上の事象であるため、プリンターの利用ができないわけではありません。

[デバイスとプリンター] 画面のプリンター アイコンが、[未指定] にカテゴライズされている期間に、[コモン ダイアログ] や、[プリンター フォルダー] と呼ばれる画面から、プリンター アイコンを確認することができる場合、印刷を実行することができます。[コモン ダイアログ] や、[プリンター フォルダー] は、[デバイスとプリンター] 画面を表示する際に実行される、”Function Discovery” を実行せず、Print Spooler サービスが管理するプリンターの情報のみからアイコンを構成するため、”デバイス メタデータ” の取得が完了していない状況 ([未指定] にカテゴライズされている状況) でも、プリンターを利用する準備が整っている場合は、アイコンの表示が完了します。

[コモン ダイアログ] による確認

[コモン ダイアログ] は、メモ帳などから、Ctrl + P キーを押下すると表示することができます。

図 3 コモンダイアログ

[プリンター フォルダー] による確認

[プリンター フォルダー] を表示するには、以下のコマンドを実行します。

explorer.exe ::{2227A280-3AEA-1069-A2DE-08002B30309D}

図 4 プリンター フォルダー

また、以下の手順で [プリンター フォルダー] を作成することができます。

1. デスクトップに新しいフォルダーを作成します。
2. フォルダーの名前を ” PrinterFolder.{2227A280-3AEA-1069-A2DE-08002B30309D}” に変更します。
3. 上記 2. で作成した、特殊フォルダを開くと [プリンター フォルダー] 画面が表示されます。

回避策

[デバイスとプリンター] 画面でのプリンター アイコンの構成時に実行される、“デバイス メタデータ” の取得は、グループ ポリシーにより抑止することができます。
そのため、本事象に合致した事象である場合には、下記のグループ ポリシーを適用することで、プリンター アイコンの表示に時間がかかる事象を回避することができます。

[ローカル コンピューター ポリシー]
– [コンピューターの構成]
– [管理用テンプレート]
– [システム]
– [デバイスのインストール]
“デバイス メタデータをインターネットから取得しない”
–> 有効

[ローカル コンピューター ポリシー]
– [コンピューターの構成]
– [管理用テンプレート]
– [システム]
– [デバイスのインストール]
“デバイス ドライバーを検索する場所の順序を指定する”
–> 有効 (“Windows Update を検索しない”)

こんにちは、Windows プラットフォーム サポートの大川です。
今回は Hyper-V の仮想マシンに設定する “自動開始アクション” についてのお話になります。

[概要]
“自動開始アクション″ の設定は 3 つのオプションから一つを選択することができますが、
クラスターのリソースとして稼働させている仮想マシンは、この設定に依存せず、
クラスターにて状態が管理されるため、”1. 何もしない” が自動的に設定されます。

[詳細]
Hyper-V の仮想マシン設定に “自動開始アクション” という設定があります。これは、
物理マシンの起動時に、仮想マシンの状態をどのようにするかを設定するものになります。
具体的には、以下の 3 つのオプションから一つ選択することが可能です。

1. 何もしない
2. サービスが停止したときに実行されていた場合は自動的に起動する
3. 常にこの仮想マシンを自動的に起動する

“1. 何もしない” を設定した場合は、物理マシンを起動しても仮想マシンは停止したままの状態で、
手動で仮想マシンを起動する必要があります。

“2. サービスが停止したときに実行されていた場合は自動的に起動する” を設定した場合は、
物理マシン停止時の仮想マシンの状態によって動作が変わります。もし、物理マシン停止時に
仮想マシンが起動していた場合には、自動的に起動しますが、仮想マシンが停止していた場合
には、仮想マシンは自動的に起動しません。

“3. 常にこの仮想マシンを自動的に起動する” を設定した場合は、物理マシンが起動した際には、
常に仮想マシンが自動的に起動されます。

仮想マシンをクラスターのリソースとして稼働させていない場合は、既定値は
“2. サービスが停止したときに実行されていた場合は自動的に起動する” になっていますが、
クラスターのリソースとして稼働させた環境においては、この値が “1. 何もしない” になります。
これは、仮想マシンの状態を物理マシンの起動に依存させるのではなく、クラスターのリソース
として管理するためです。

この値の変更は仮想マシンをクラスターのリソースとして登録したり、ライブマイグレーションを
行ったりすると、自動的に変更されます。弊社としてはクラスター上で稼働させる仮想マシンは
“1. 何もしない” を推奨としておりますので、変更せずにそのままご利用いただければと思います。

※注
フェールオーバー クラスター マネージャーの画面から”自動開始アクション″ の設定変更が可能であり、
画面上からも変更されたように見えますが、実際に仮想マシンが動作する内容としては、
“1. 何もしない” になります。

なお、クラスター上の仮想マシンはクラスターリソースとして扱われます。また、クラスターサービス停止時に
実行されていたクラスターリソースは、次回クラスターサービス起動時に自動的に起動されます。そのため
“1. 何もしない” が設定されていても、クラスターサービス停止時に起動していた仮想マシンは、次回クラスター
サービス起動時に自動的に起動されますので、ご安心いただければと存じます。

本ブログが少しでも皆様のお役に立てますと幸いです。

Windowsプラットフォームサポートの平井です。

本記事では次の条件がすべて当てはまった場合に、サードパーティー製のWindowsサービスがc0000005(STATUS_ACCESS_VIOLATION)やc0000006(STATUS_IN_PAGE_ERROR)のアプリケーションエラーで異常終了するシナリオについて解説します。尚、この事象はPCのシャットダウン後の次回起動時に発生します。

条件は次の通りです。

条件1:高速スタートアップが有効な場合
条件2:対象のサードパーティー製Windowsサービスの実行ファイルやDLLがデータボリューム(C:以外)に存在する場合
条件3:対象のボリュームにページングファイルが非設定である場合
条件4:対象のドライブにBitLockerの構成がデバイス暗号がオン、保護状態がオフの状態の場合

本事象が発生する理由は次の通りです。

高速スタートアップが有効の場合にPCをシャットダウンした場合、Windowsサービスのプロセスはメモリ上に残った状態で休止状態となります。

この際、BitLockerの構成がデバイス暗号がオン・保護状態がオフの状態である場合、次回起動時にデータボリュームのデータを暗号化するためのキーを初期化する処理が発生し、BitLockerの仕様上ボリュームのディスマウントが必要となります。

ボリュームのディスマウントが発生した結果、メモリ上にマッピングされたWindowsサービスのプロセスの実行ファイルやDLLの情報に不整合が発生し、c0000005(STATUS_ACCESS_VIOLATION)やc0000006(STATUS_IN_PAGE_ERROR)等のアプリケーションエラーで異常終了する状況が発生します。

もし、上述の条件がすべて合致する環境にて、同様の問題を検出された場合、次の対応が必要となります。

対応1:サードパーティー製Windowsサービスの実行ファイルやDLLをシステムドライブ(C:)配下にインストールする

Windowsでは既定で、ページングファイルはシステムドライブ配下に保持されます。Windowsはページングファイルが存在するボリュームに対してディスマウントは発行しないため、本事象は発生しません。

対応2:高速スタートアップを無効化する

高速スタートアップが無効の場合にPCをシャットダウンした場合、Windowsサービスのプロセスは完全に停止し、メモリ上にプロセスに紐づく情報は残りません。

対応3:BitLockerをデバイス暗号化/保護状態が共にオンに構成する

BitLockerの設定がデバイス暗号化/保護状態が共にオンの場合、データボリュームの暗号化キーを初期化する処理が発生いたしません。このため、ボリュームのディスマウント処理が発生しないため、本事象は発生いたしません。

対応4:ページングファイルをデーターボリュームにも配置する

Windowsはページングが有効になったボリュームに対してディスマウント処理を発行しないため、、本事象は発生いたしません。

1.コントロールパネル\システムとセキュリティ\システムから、[システムの詳細設定]を開きます。
2.[システムのプロパティ]&amp;gt;[詳細設定]タブを開き、[パフォーマンス]セクション配下の[設定]を選択します。
3.[仮想メモリ]セクション　配下の、[変更]を選択します。
4.[すべてのドライブのページングファイルのサイズを自動的に管理する]のチェックボックスが有効の場合は、外します。
5.D:ドライブを選択し、[システム管理サイズ]&amp;gt;[設定]を選択し、[OK]を選択します。
6.システムを再起動し、設定を適用します。

こんにちは、Windows プラットフォームサポート Setup チームの宮崎です。

本記事では Windows 製品の更新プログラム (KB) のインストールが失敗してしまう事象について一般的な対処策をお伝えいたします。本手順は一般的に業務への影響が少なく、また多くの事象の解決・進展が得られる内容であることから、弊社のサポート サービスにお問合せいただいた際にも広くご利用いただいておりますことからご紹介とさせていただきました。適用時のトラブルに遭遇した場合にはぜひご実施ください。

一般的な対処策

A. DISM /Restorehealth コマンド及びシステム更新準備ツール コマンドでの修復

以下の技術情報の内容を実行いただきます。

DISM またはシステム更新準備ツールを使用することによって Windows 破損エラーを解決する
https://support.microsoft.com/ja-jp/help/947821/

OS ごとの対処方法は以下の通りです。

• Windows 7, Windows Server 2008/2008 R2:
  上記の URL からシステム更新準備ツールのパッケージを入手して実行します。
• Windows 8.1, Windows Server 2012 以降の OS:
  管理者権限で以下のコマンドを実行してください。
  DISM.exe /Online /Cleanup-image /Restorehealth

– 補足

本対処策は、システム内部の不整合をスキャンし、問題が見つかった場合は自動的に修復を試みます。問題が検出された場合には Windows Update サイトから修復が必要なファイルをダウンロードしますので可能であればインターネット接続可能な状況で実施ください。なお、インターネット接続が難しい場合にも問題の検出は可能であり、ログに状況が記録されます。

システム更新準備ツールの実行中の UI は、通常の更新プログラムと同様にウィザードを進めインストールするという形式を取りますが、実際にシステム内に新たなモジュールが追加するような変更は行っておりません。

本作業では通常、システムの再起動は発生いたしません。スキャン・修復処理のためマシンの負荷が高くなることがありますが、通常 OS のリソースをすべて占有する程にはいたりません。作業は 10～20 分程度で完了します。途中、プログレス バーが一向に進まないように見える時もありますが、終了するまでお待ちください。

B. sfc コマンドでの修復

管理者権限で以下のコマンドを実行してください。

sfc /scannow

– 補足

システム ファイル チェッカー ツール (SFC.exe) は OS 標準に含まれるツールであり、システムの整合性チェックし、問題があれば自動的に修復を試みます。本作業では通常、システムの再起動は発生いたしません。スキャン・修復処理のためマシンの負荷が高くなることがありますが、通常 OS のリソースをすべて占有する程にはいたりません。作業は 10～20 分程度で完了します。途中、プログレス バーが一向に進まないように見える時もありますが、終了するまでお待ちください。

システム ファイル チェッカー ツールを使用して不足または破損しているシステム ファイルを修復する
https://support.microsoft.com/ja-jp/help/929833/

C. Windows Update クライアント情報のクリア

更新プログラムのダウンロードとインストールに用いられるSoftwareDistribution フォルダー上の不整合を解消することでトラブルを回避できる場合がございます。以下 URL にて案内している手順を実施ください。

Windows Update クライアントの情報をクリアにする手順
https://blogs.technet.microsoft.com/jpwsus/2014/12/02/windows-update-3/

D. 最新のサービス スタック更新プログラムのインストール

サービス スタック更新プログラムとは OS のインストール処理自体を改善する更新プログラムで、最新にすることでトラブルを回避できる場合がございます。最新のサービススタック更新プログラムについては以下 URL を確認ください。

ADV990001 | 最新のサービス スタック更新プログラム

https://portal.msrc.microsoft.com/ja-jp/security-guidance/advisory/ADV990001

– 補足

以下の URL にて詳細を解説しております。

Servicing stack updates
https://docs.microsoft.com/en-us/windows/deployment/update/servicing-stack-updates

更新プログラムのインストール処理を改善するサービススタック更新プログラムについて
https://blogs.technet.microsoft.com/askcorejp/2018/07/12/servicingstack_guide/

E. スタンドアロンインストーラーでのインストール

通常、Windows 製品の更新プログラムの多くは *.msu 形式のスタンドアロンインストーラーとして Microsoft Update カタログより提供しています。一般的な Windows Update の機能を通じた更新プログラムの適用では、ダウンロードとインストールの大きく２つのフェイズがございますが、スタンドアロンインストーラーを利用することで、ダウンロードに関連したトラブルかどうかを切り分けすることが可能でございます。

Microsoft Update カタログ
https://www.catalog.update.microsoft.com/Home.aspx

本記事が皆様の運用の一助となりましたら誠に幸いです。

本記事におきましては予告なく内容を変更させていただくことがあります。今後、情報のアップデートがあれば、本ブログにて引き続き情報を提供いたします。

参考情報

以下の記事では、スタンドアロンインストーラーに限定せず Windows Update からの適用と失敗について紹介しております。一部の手順については重複しておりますが必要に応じてご参照ください。

Windows Update に失敗したら
https://blogs.technet.microsoft.com/jpwsus/2018/06/29/wufailed/

なお、上記記事では一部、ログの分析方法についても触れておりますが、スタンドアロンインストーラーでインストールに失敗するところまでが切り分けられている場合、調査対象とするログは主に以下になります (※ 1)。

• Setup イベント ログ
• CBS ログ (C:\Windows\Logs\CBS 配下のファイル)
• (System イベント ログ ※ 2)
• (Application イベント ログ ※ 2)

※ 1: 事象によって他のログが必要となる場合がございます。
※ 2: 事象の前後関係を確認するための補足資料として参照する場合がございます。

こんにちは、Windows プラットフォームサポート 宮崎です。

本ブログ内の ”Windows 製品の更新プログラム (KB) のインストールの失敗 … 一般的な対処策” の記事で OS の更新プログラムの適用に失敗する際の一般的な対処策をお伝えしましたが、事象によっては解決せず、ログの調査に進む必要がございます。本記事ではログの分析調査の準備と進め方についてご紹介いたします。

ログの調査方法

スタンドアロンインストーラーでインストールに失敗するところまでが切り分けられている場合、調査対象とするログは主に以下になります。

• Setup イベント ログ
• CBS ログ (C:\Windows\Logs\CBS 配下のファイル)
• (System イベント ログ)
• (Application イベント ログ)

基本的には Setup イベントログと CBS ログを参照しながら、その後、事象に応じて他の情報を参照していく流れとなります。System イベント ログや Application イベント ログ等、他の情報は事象の前後関係や裏付けをとるための補足資料として参照する場合がございます。

Setup イベントログでイベント ID 3 のイベントを検索すると、以下のようにエラーコードが記録された失敗のイベントが確認できエラーの日時や理由がわかります。

ログの名前: Setup
ソース: Microsoft-Windows-Servicing
イベント ID: 3
レベル: 情報
ユーザー: SYSTEM
説明: パッケージ KBxxxxxxx を状態 インストール済み に変更できませんでした。状態: 0xXXXXXXXX。

エラーコードをマイクロソフトの公式ページから検索し、エラーの内容を確認します。

以下は更新プログラムのインストールで発生しやすい代表的なエラーコードです。

エラーコードから以下のようにおおよその事象の見立てを行っていきます。

• 0x80073712 や 0x800F081F であれば、必要なコンポーネント ストアの破損やパッケージの不足であることから、OS 内部の不整合であることが疑われます。
• 0x80070020 や 0x80070005 であれば、正しくアクセスできない状況にあるので、何等かのサードパーティー製品やアクセス対象が正しくアクセスできる状況にあるか確認が必要となります。サードパーティー製品の無効化やアンインストールを検討する必要があります。
• 0x800705B4 や 0x800f0816 であれば、タイムアウトやインストール処理のタイミングが直接の事象となります。複数回のリトライで改善されないか、リソース・他のソフトウェアの影響により動作影響がないか確認が必要となります
• 0x80070422 であれば、本来既定で有効となっているサービスを無効に設定していないか確認が必要となります
• 0x80240017 であれば、更新プログラムがそもそも適用可能な対象であるかの確認が必要となります。また場合によっては、更新予定のモジュールがすでにすべて新しいものに置き換えられていて、適用不要となっている場合もこのエラーコードが記録されます。

次に CBS ログから、事象の発生日時前後でエラーのレコードを調査していきます。まずは最新の情報が記録されている CBS.log から “, error” を含むレコードを抽出いただくと素早くご確認いただけます。

2017-04-25 22:38:33, Error CSI 00000002 (F) Logged @2017/3/25:13:38:33.230 : [ml:322{161},l:320{160}]”EventAITrace:Provider Microsoft-WindowsAzure-Diagnostics{{9148c98f-152c-44d3-a496-26350c475d74}} is missing channels under the channelreferances registry key. ” [gle=0x80004005]

抽出されたレコードの意味やその前後関係、公開技術情報をキーワードから検索していきます。上記レコードからは何等かのレジストリ キーの不整合であることがわかり、以下 URL に記載の問題に該当します。

Windows 仮想マシンにて更新プログラムの適用に失敗する場合のトラブルシュート
https://blogs.technet.microsoft.com/jpaztech/2017/05/16/troubleshooting-patch-installation-failure/

本記事ですべてのエラーコードやログの分析方法について紹介しかねますが、上記の流れを参考に分析を進めていただくことでお客様ご自身でも問題が解決できる場合がありますので参考にしてください。

補足. Windows Update のログは調査に使われないのか

C:\Windows\Windowsupdate.log や C:\Windows\Logs\WindowsUpdate\*.etl は Windows Update の主に検出、ダウンロードする部分を担うログ ファイルとなります。スタンドアロンインストーラーでのインストールの場合には、検出やダウンロードの処理が割愛されますので、Setup イベントログや CBS ログからの調査で進めることができ、Windows Update のログは補足資料として用います。

解決しない場合

サポート サービスで分析支援を行っておりますが、ログ分析には一定の調査期間を要します。また事象によっては数日の調査で解決することもあれば、追加の採取や切り分けの実施を繰り返し 1 か月程度の調査期間を経ても解決に至らないことがあります。

対処策が得られない場合やトラブルに至った端末が一部である場合、現象の回避を優先した再構築の対応が妥当な場合がございます。ただし、業務機能の再構築が運用上の負荷が高い対応となり特にサーバー マシンでは採択が難しい傾向があります。その場合、弊社では再構築を実施する前にインプレースアップグレードによる上書きインストールを提案しております。

インプレース アップグレードとは OS の構成やユーザーがインストールしたアプリケーションやデータなどを可能な限り残し、OS 部分のみを上書きインストールする方法です。アップグレードと表記いたしておりますがこのような事象でインプレースアップグレードを行う目的は OS 部分の上書きとなりますので、上位バージョンへ更新するためのアップグレード作業ではなく、お使いいただいてる OS と同バージョンのメディアでアップグレード作業を行うことで修復を行います。再構築とは異なり可能な限り構成やデータを引継ぎますので、新規に OS を入れ直すよりは迅速に問題の解決を進めることができます。

具体的な手順は以下を参考にしてください。以下は Windows 10 を例としておりますが、Windows 10 以前のクライアント OS やサーバー OS でも同バージョンのインストール メディアでアップグレード操作を行うことで対応が可能です。

Media Creation Tool から Windows 10 の最新バージョンへアップデートする方法
https://sway.office.com/icArYOWCI87zzyul

注意事項

問題の原因によっては、インプレース アップグレード自体が失敗するケースも存在し、状況によっては OS の起動が出来なくなるケースもございますため、インプレース アップグレードを実施する前に、重要なデータはバックアップしておくことを強くお勧めいたします。また、インストール済みの更新プログラムは削除されますので、再度インストールが必要となります。 アプリケーションや設定によっては、 再インストールや再設定が必要となる場合がございます。 インプレース アップグレード自体が失敗する、あるいはインプレース アップグレードは成功したが、問題が解消しないという場合には、改めて新規に OS を再インストールすることをご検討ください。

サポート サービスにお問合せいただく前に

事象について弊社のサポート サービスやパートナー様にご相談いただく前に、以下の情報が把握できていますと、運用状況に対しての現実的な対処方法や追加の資料採取の検討が行えます。ぜひお問合せ前にご確認いただくことを推奨いたします。

• エラーとなる更新プログラムの KB 番号
• 事象が再現するインストール方法
  • スタンドアロンインストーラーか Windows Update か
  • WSUS/SCCM 等の配信のインフラがあるか
• エラーに至るまでの画面遷移（スクリーンショット等）
  • 例 1. スタンドアロンインストーラーの実行中にエラーが表示される
  • 例 2. インストール後の再起動中に「Windows 更新プログラムを構成できませんでした 変更を元に戻しています」と表示され元に戻る
  • 例 3. スタンドアロンインストーラーではインストールに成功するが、Windows Update ではダウンロードの完了まで至らない
• 発生規模
  • 何台中何台が失敗しているか、成功しているマシンがあるか
  • 複数台発生する場合、エラーコードや画面遷移は同様か
  • 利用用途、ソフトウェア、ハードウェアなどの差異はあるか

本記事が皆様の運用の一助となりましたら誠に幸いです。

本記事におきましては予告なく内容を変更させていただくことがあります。今後、情報のアップデートがあれば、本ブログにて引き続き情報を提供いたします。

参考情報. エラーコードの解釈の方法

エラーコードの解釈の方法については以下の URL をご確認ください。

2.1 HRESULT
https://msdn.microsoft.com/en-us/library/cc231198.aspx

Win32 Error Codes
https://msdn.microsoft.com/library/cc231199.aspx

例えば、先頭の桁が “8007” は Win32 エラーコードとなります。この時、末尾 4 桁が合致するエラーコードを Win32 Error Codes から検索します。

その他には、例えば “800f” は Facility 値が 15 (0xf) となり FACILITY_SETUPAPI エラー、また “8024” は 36 (0x24) となり FACILITY_WINDOWSUPDATE のエラーと分類されます。Win32 エラーコード以外のエラーコードについて、残念ながらすべての情報公開はいたしておりませんが、本記事のように個別に紹介いたしておりますので、弊社の技術情報を検索、確認いただけましたら幸いです。

こんにちは。
日本マイクロソフト株式会社 高谷です。

今回は、フェールオーバー クラスター マネージャーから役割として登録された仮想マシンを選択し、右クリックからシャットダウンを行うと、正常にシャットダウンされずに強制停止となってしまう事象についてご紹介いたします。
※ 本事象は Windows の想定された動作であり、不具合ではございません。

■ 事象の発生条件

.
・ OS: Windows Server 2016
・ Hyper-V ホスト 2 台～ にてフェールオーバー クラスターを構成
・ Hyper-V 仮想マシンはフェールオーバー クラスターの役割として構成されている
・ Hyper-V 仮想マシンにサインインし、ロック状態にする

■ 事象について

.
上記の条件において、フェールオーバー クラスター マネージャー画面の役割一覧から、ロック状態の Hyper-V 仮想マシンを右クリックして「シャットダウン」を選択すると、正常にシャットダウンされることなく「停止」されてしまいます。

Hyper-V ホストからフェールオーバー クラスター マネージャー経由で仮想マシンをシャットダウンする場合、クラスターは仮想マシン内のユーザー “SYSTEM” を偽装して “シャットダウン” というリソースの操作を実行します。
しかしながら、ログオン中/ロック中のユーザーがいれば、クラスターは ”SYSTEM” ではなくそのユーザーを偽装して仮想マシン リソースの操作を実行する動作となります。
通常、SYSTEM 以外のユーザーには Hyper-V ホスト側のフェールオーバー クラスター マネージャーからのリソース操作が許可されておりませんので、ログオン中/ロック中のユーザーがいる場合は、権限不足が発生し、仮想マシン リソースが “失敗” となり、仮想マシンが強制的に停止状態となってしまいます。

■　影響と回避策

.
本事象により、稼働中のマシンが強制停止されるため、該当の仮想マシンのシステムが破損する可能性がございます。
そのため、回避策といたしましては、下記の 2 つの方法があります。

▼ 回避策 1

——————————————————————
ロック状態にせずに (全てのユーザーをサインアウトした状態にする)、フェールオーバー クラスター マネージャー画面の役割一覧から、シャットダウンを行う
——————————————————————

上述の通り、ログオン中/ロック中のユーザーがいなければ SYSTEM 権限でシャットダウンが行われ、これは権限のある正常なシャットダウンとなります。
弊社環境にて、全てのユーザーがサインアウトしている状態であれば、フェールオーバー クラスター マネージャー画面の役割一覧からシャットダウンを行った場合であっても、正常にシャットダウンが行えることを確認しています。

▼ 回避策 2

——————————————————————
仮想マシン接続画面のウィンドウのシャットダウン ボタンから、シャットダウンを行う
——————————————————————

仮想マシンの接続画面ウィンドウからシャットダウンする場合は、フェールオーバー クラスター マネージャーを経由しておりません。
(Hyper-V マネージャーから接続画面を呼び出した場合と同じ動作となり、”リソースの操作” という観点がございません。)
従って、接続画面からシャットダウンを実行すると事象が回避でき、正常にシャットダウンが可能です。

なお、回避策 2 を実施する際にも、ロック状態のユーザーが存在する場合は、下記のような警告が表示されます。状況に応じて、ロック状態をサインアウト状態にしてからシャットダウンをご実施ください。
補足) ここで [強制する] を選択しても、強制停止とはならず、正常なシャットダウンが実行されますので、ご安心ください。

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てますと幸いです。

いつも弊社製品をご利用いただきまして誠にありがとうございます。
Windows プラットフォーム サポートの石田です。

今回は、Microsoft Windows Server Failover Cluster の共有ディスクに対する予約 (Persistent Reservation) の
動作についてご紹介させていただきます。
クラスターサービスでは共有ディスクの排他制御を行うため、SCSI-3 で規格されている
Persistent Reserve コマンドセットを利用しています。
そのため、利用する HBA と共有ディスクを提供するストレージは SCSI-3 に対応している必要がございます。

クラスターで利用される共有ディスクにアクセスする際、ディスク毎に管理されている Reservation Table に
ノード毎に一意に識別できる予約キーを登録します。
最初にキーを登録できたノードがディスクをオンラインにします。
既に別のノードによってキーが登録されておりキーの登録に失敗した場合は、キーが解放されるまで待機状態となります。
ディスクをオンラインにしているノードはディスクに対して 3 秒ごとに Persistent Reserve コマンドを
発行して予約情報を更新します。
ノード 1 とノード 2 にてディスクへ予約キーが登録されるまでの流れ、および障害が検知された際の動作については
以下のようになります。

1. ノード 1 のクラスター起動時に対象のストレージに向けて Register & Reserve を発行しストレージの
Registration TableおよびReservation Tableに予約キーを登録します。
2. ノード 1 では続けて予約キーが登録されているかどうか確認します。
3. ノード 2 のクラスター起動時に対象のストレージに向けて Register & Reserve を発行し予約キーの登録を試みます。
ただし、Reservation Table へのキーの登録は既にノード 1 のキーが登録されているため失敗します。

4. ノード 1 にて 3 秒間隔で対象のストレージに向けて Read コマンドを発行し、予約キーの更新を行います。
5. ノード 2 にて対象のストレージに向けて Preempt コマンドを発行し、再度、予約キーの登録を試みます。
ただし、ノード 1 にて予約キーが更新されているため、失敗します。
また、ノード 1 では継続して対象のストレージに向けて Read コマンドを発行し、予約キーの更新を行います。
ノード 2 はクラスターの正常性が変化するまで待機します。

6. ノード 1 にてハングアップやシステム停止などが発生すると、予約キーの更新が行われなくなります。
7. クラスター ディスク リソースのフェール オーバーが発生するとノード 2 にて対象のストレージに向けて
Register & Reserveを発行し予約キーの登録を試みます。ただし、Reservation Table へのキーの登録は
既にノード 1 のキーが登録されているため失敗します。
8. ノード 2 にて対象のストレージに向けて Preempt コマンドが発行され、再度、予約キーの登録を試みます。
この際、ノード 1 にて予約キーの更新は行われていないため、成功します。
9. ノード 2 にて 3 秒間隔で対象のストレージに向けて Read コマンドを発行し、予約キーの更新を行います。

10. ストレージ 装置に障害が発生すると、ノード2から発行されているPersistent Reserveコマンドが失敗します。
11. Persistent Reserveコマンドが失敗すると、ノード 2 のディスク リソースの正常性チェック (IsAlive) が
失敗しディスク リソースの障害が検知されます。

以上となります。
本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。