こんにちは。Windows プラットフォーム サポートの加藤です。
本日は、Windows Server 2008 R2 のクラスター共有ボリューム (CSV) の最大数についてお伝えします。

クラスター共有ボリューム (CSV) の最大数自体には制限がないため、登録できるボリュームの数は、OS で認識可能な LUN の数と同じです。

Windows Server 2008 R2 のサポートする LUN の最大数は、以下の通りです。

SCSI、FC 接続
- 各 HBA アダプターにつき 8 個のバス
- ひとつのバスにつき 128 個のターゲット ID
- ひとつのターゲット ID につき 255 個の LUN

iSCSI 接続
- Windows Server 2008 R2 標準の iSCSI イニシエーターの最大ターゲット数は 255 個
- ひとつのターゲット ID につき 255 個の LUN

なお、OS 側の制限に達する前に、ストレージの仕様により、最大数の制限を受ける可能性があります。
例えば、Microsoft iSCSI Software Target 3.3 では、ひとつのターゲットにマッピングできる LUN 数は 128 個までという制限があります。
ストレージ側の仕様については、ハードウェアベンダーにお問い合わせください。

[参考資料]
文書番号 : 310072
- Adding support for more than eight LUNs in Windows Server 2003 and in Windows 2000
http://support.microsoft.com/kb/310072/en-us
※ Windows Server 2003 までの情報となっておりますが、Windows Server 2008 R2 についても同様です。

文書番号 : 2821904
Windows Server 2008 R2 における iSCSI イニシエーターの最大接続数について
http://support.microsoft.com/kb/2821904

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

今回は HPC Pack 2008 R2 にて大幅に変更されたサポート機能について紹介させていただきます。

HPC Pack 2008 R2 SP2 までは、HPC ジョブ スケジューラ サービスにアクセスするための機能

として HPC Basic Profile Web Service がサポートされておりました。

しかしながら、HPC Pack 2008 R2 SP2 で、新たに Web Service Interface という機能が

追加されたため、HPC Pack 2008 R2 SP3 から HPC Basic Profile Web Service のサポートが

終了いたしました。そのため、HPC Pack 2008 R2 SP3 以降は、Web Service Interface を

お使いいただく必要がございます。

大幅にサポート機能が変更されることにより、お客様には構築や運用にて

お手数をお掛けすることになりますが、何卒宜しくお願いいたします。

Web Service Interface をお使いになる際、参考となる資料を以下にご紹介いたしますので、

ご参照いただけますと幸いでございます。なお、Web Service Interface に関するご質問、

また構築の際にトラブルが発生した場合には、弊社までお問い合わせください。

= 参考資料 =

- サポート機能変更に関する記述

HPC Server Basic Profile Web Service Operations Guide

http://technet.microsoft.com/en-us/library/cc972837.aspx

- HPC ヘッド ノードでの設定方法

Install the Microsoft HPC Pack Web Components

http://technet.microsoft.com/en-us/library/hh314627.aspx

- Web Service Interface の REST API に関して

Creating and Submitting Jobs by Using the REST API in Windows HPC Server 2008 R2

http://social.technet.microsoft.com/wiki/contents/articles/7737.creating-and-submitting-jobs-by-using-the-rest-api-in-windows-hpc-server-2008-r2.aspx

- Web Service API サンプル コード (HPC2008R2.SampleCode.zip)

HPC Pack 2008 R2 SDK with Service Pack 4

http://www.microsoft.com/en-us/download/details.aspx?id=29992

こんにちは。日本マイクロソフトの松岡です。
今回は、比較的よくお問い合わせをいただく NTFS 55 についてご紹介します。

-------------------
イベントの種類: エラー
イベント ソース: NTFS
イベント ID: 55
説明:
ディスク上のファイル システム構造が壊れていて使えません。chkdsk ユーティリティをボリューム "Drive_letter" で実行してください
-------------------

ソース : NTFS、ID: 55 のイベントについて

ソース : NTFS、ID: 55 のイベントは、ファイルシステム データ構造に不整合を発見した場合に記録されるイベントです。このイベントが記録されるタイミングとしては、ファイル システム構造が破損した状態で、その破損個所にアクセスした際に記録されます。また、破損時点と 本イベントが記録された時点には差異があり、この情報からその前に何が発生したのか原因追求を行うことは困難です。したがって、オペレーションの観点から特に問題がない場合、関連するデバイス ドライバーや、ファームウェアのアップデートを行うことが一般的な対策です。

一般的な本イベントの要因について

一般的にこの破損が発生する原因としては、以下の状況が考えられます。

1. 不正なシャットダウンが発生した場合

不正なシャットダウンが発生すると、ディスク上の情報を正しく保存せずにシステムが終了するため、ファイル システムに不整合が発生する可能性があります。 

2. ハードウェアの破損による場合

  
ハードウェアの破損、故障により、ディスク上のデータが破損して不整合が発生する可能性があります。

3. ディスクが突然取り外れた、あるいは、アクセスできなかった場合

ディスクが突然取り外れた、あるいは、アクセスできなくなったような場合には、1 同様、ディスク上の情報が正しく保存されず、ファイルシステムに不整合が発生する可能性があります。

4. ドライバやアプリケーションによる不正なアクセスがあった場合

ファイル システム ドライバーや、その他カーネル モードのコンポーネントの不具合により発生する可能性があります。ドライバーやアプリケーションによっては、NTFS ファイル システムを経由せずに、ディスクへ直接アクセス、書き込みを行うものがあります。これらの作用により、 NTFS の意図しない変更がディスク上のデータに加えられ、破損が発生する場合があります。または、ドライバーやアプリケーションによりディスクへのアクセスが突然遮断され、3 のような状況となり、現象が発生する可能性も考えられます。

本イベントへの対応について

本イベントへの対応としては、フォーマット後にバックアップからデータを復元するか、修復モードでの chkdsk コマンドを実施します。なお、大容量のボリューム で chkdsk を実行する場合、ボリュームのサイズやマシンのスペック等により、所要時間が非常に長くなることがあります。システムのダウンタイムを考慮した場合、修復モードでの chkdsk の実行よりフォーマットによる対応方法の方が、より少ないダウンタイムで対応が完了する状況も考えられます。事象が発生した環境により、フォーマット後にバックアップ データを復元、または修復モードでの chkdsk の実行を検討してください。

1. Chkntfs コマンドによる破損が発生しているボリュームの確認

2. フォーマットによる対応

3. 修復モードでの chkdsk コマンドによる対応 

※ 対応は 2、3 のいずれかの対応で問題ありません。(両方実施する必要はありません。)

1. Chkntfs コマンドによる破損が発生しているボリュームの確認について

ファイル システムの破損が発生しているボリュームを特定するには、chkntfs コマンドが使用できます。

※ Chkntfs コマンドは、ファイル システムの状態を参照するコマンドのため、サーバーへの大きな負荷はかかりません。

実行例) 

> Chkntfs C:

ファイル システムの破損が発生していない場合の実行結果

########################################
ファイル システムの種類は NTFS です。
C: は正常です。
########################################

ファイル システムの破損が発生している場合の実行結果

########################################
ファイル システムの種類は NTFS です。
C: が正しくありません。
########################################

- 参考情報

Chkntfs

http://technet.microsoft.com/ja-jp/library/cc731298(v=ws.10).aspx

2. フォーマットによる対応について

フォーマットによる対応をされる場合には、必要に応じて該当ボリュームにあるデータを別の領域に退避し、ボリュームを再フォーマットします。フォーマットの完了後、必要に応じて、退避したデータをリストアします。

3. 修復モードでの chkdsk コマンドによる対応ついて

chkdsk コマンドはオプションが指定されていない場合、読み取り専用モードで実行されます。chkdsk を /R または /F オプションを指定することにより、ファイルシステムの不整合を修復することができます。なお、修復モードでの chkdsk コマンドを実行した場合でも、実際に破損しているデータについては、修復することはできませんが状態が悪化することはありません。修復モードの chkdsk の実行によりファイル システムの不整合が修復されます。

実行例)

> chkdsk c: /R

なお、chkdsk d: /R の実行時に、何らのプロセスが実行対象のボリュームを利用している場合には、以下のメッセージが表示されます。

コマンドの実行結果

########################################
ボリュームが別のプロセスによって使用されているため、Chkdsk を実行できません。
Chkdsk を実行するにはこのボリュームのマウントを解除する必要があります。
########################################

メッセージ1

########################################
このボリュームを強制的にマウントを解除しますか? (Y/N)
########################################

メッセージ2

########################################
ボリュームが別のプロセスで使用されているため、CHKDSK を実行できません。次回のシステム再起動時に、このボリュームのチェックをスケジュールしますか (Y/N)?
########################################

いますぐ chkdsk /R を実行する場合には、メッセージ1 にて Y を、再起動時に chkdsk /R を実行する場合には、メッセージ2 にて Y を選択し実行します。

- 補足

オプション /R を指定した場合は、/F も暗黙的に指定されます。対象のボリュームに対して chkdsk /R または /F コマンドの実行によりセクタの修復を試みます。/R は /F に加えて物理的な不良セクタのチェックを行います。

- 参考情報

Chkdsk.exe で使用可能な新しいスイッチ /C および /I について

http://support.microsoft.com/kb/314835/ja

Chkdsk

http://technet.microsoft.com/ja-jp/library/cc730714(WS.10).aspx

再発防止策について

ハードウェアの破損以外の原因で 本イベントが発生した可能性が考えられる場合には、関連するデバイス ドライバーやファームウェアの最新バージョンを確認し、アップデートを行います。 OS 観点では、ファイルシステム ドライバーの既知の不具合により発生している可能性がありますので、最新の修正プログラム (NTFS.sys) を適用します。また Windows 7、Windows Server 2008 R2 RTM では、NTFS 55 が誤検知されるという、Ntoskrnl.exe の不具合がありますので、こちらも最新の修正プログラムを適用します。

2013 年 11 月 25 日時点の各 OS に対する最新の修正プログラムは以下のとおりです。

- Windows Server 2003

文書番号: 973870

データのバックアップ中に、Windows Server 2003 を実行しているコンピューターが不規則に応答を停止します

http://support.microsoft.com/kb/973870

- Windows Vista、Windows Server 2008

文書番号: 2824200

Windows Vista または Windows Server 2008 を実行しているコンピューター上の"0x00000024"または"0x00000050"Stop エラー

http://support.microsoft.com/kb/2824200

- Windows 7、Windows Server 2008 R2

文書番号 : 2885209

[MS13-036] Windows ファイル システム カーネル モード ドライバー (ntfs.sys) セキュリティ更新プログラムについて (2013 年 4 月 9 日)

http://support.microsoft.com/kb/2885209

文書番号: 2878068 (Ntoskrnl.exe)

Windows 7 SP1 または Windows Server 2008 R2 の SP1 で、ConvertSecurityDescriptorToStringSecurityDescriptor 関数が失敗した後、アプリケーションがクラッシュします。

http://support.microsoft.com/kb/2878068

- 参考情報

EVENT ID 55: When Good Bits Go Bad

http://blogs.technet.com/b/askcore/archive/2012/05/09/event-id-55-when-good-bits-go-bad.aspx

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

今回は Window Server 2012 にてシャットダウンまたは再起動の際にコメントを記入する方法についての記事となります。

Windows Server 2003 以降ではイベント追跡ツールによってシャットダウンまたは再起動の際にコメントを記入する事ができます。このコメント欄にユーザーがシャットダウン理由を記入する事で管理者が後でなぜその時にシャットダウンが行われたかイベントビューアーから確認出来ます。

Windows Server 2012 でも引き続きこの機能は有効ですが、シャットダウンの方法によって、従来通りのコメント入力を行う方法と、コメントを省略し、より簡易的に理由を選択できる方法と、動作が分かれております。

具体的には、チャームの「設定」より「電源」を選択した場合には、コメントを省略し、より簡易的に理由を選択できる方法でシャットダウンが行われます。

もし管理上、従来通りのコメント入力を行いたい場合は Alt+F4 またはコマンドよりコメントを記入する事が可能です。

また、VBScript と組み合わせてシャットダウン画面を表示する方法もございますので、これらの方法についてそれぞれご紹介させていただきます。

- ショートカットキーを利用する方法

デスクトップ上でショートカットキー (Alt + F4) 操作によって、コメント欄付きのシャットダウンウィンドウを表示する事が出来ます。

- コマンドを利用する方法

タスクやバッチジョブ等と組み合わせて実行する場合には、以下の shutdown コマンドを使用してコメントを入力する方法が有効です。

      Shutdown /c "コメント" /s

コマンドを実行しても結果等は表示されませんが、暫くするとサインオフの画面が表示されシャットダウンが実施されます。シャットダウン時には入力した“コメント“が表示されます。

- VBScriptを利用する方法

GUI よりコメント記入欄を表示する場合には、VBScript を使用する事でシャットダウンのアイコンを作成する方法もございます。

以下の VBScript のコードをメモ帳より .vbs ファイルとして保存する事で、[Alt] + [F4] キーを押した際と同様の結果が得られるアイコンを作成出来ます。

--- VBScript のコード ---

dim objShell
set objShell = CreateObject("shell.application")
objshell.ShutdownWindows
set objShell = nothing

------

-  補足：VBScript ファイルのアイコンをショートカットにピン止めするには

Windows Server 2012 では、VBScript のファイル自体またはショートカットをピン止めする事ができません。

ピン止めするには以下を手順をご参照ください。

1.         VBScript のファイルを任意の場所に置きます。

2.         新規作成でデスクトップにショートカットを作成します。

3.         以下の様な画面が出てくるので、”cscript” + “VBScript の配置場所”を指定し、「完了」をクリックします。

4.         ショートカットの名前を指定し、「完了」を押します。

すると以下の様なアイコンが出来ます。

5.         アイコンを右クリックし、「スタートにピン留め」を選択する事でピン留めが可能です。

さらにアイコンの画像を変更したい場合には次の手順に進んでください。

6.         ショートカットを右クリックし「プロパティ」をクリックします。

7.         「ショートカット」タブの「アイコンの変更」ボタンをクリックします。

8.         「アイコンの変更」画面より「参照」ボタンをクリックします。

9.         %SystemRoot%\system32\SHELL32.dll を選択し、「開く」をクリックします。

10.       「アイコンの変更」画面よりアイコンを選択し、「OK」をクリックし、更にシャットダウンのプロパティ画面でも「OK」をクリックし画面を閉じます。ショートカットのアイコンが変更されます。

11.       アイコンを右クリックし「スタートにピン留め」をクリックする事で、以下のようにタスクバーにショートカットを配置する事が出来ます。

チャームの「設定」より「電源」を選択した場合の理由を選択できる項目は以前のバージョンよりも多くご用意しておりますが、選択肢に該当項目が無い、または手動でコメントを残したい場合にはこの記事で紹介いたしました方法をご利用ください。

*1 2013/12/15 VSS の修正プログラムの情報を追記しました。
こんにちは。Windows プラットフォーム サポートの加藤です。

Windows Server 2008 以降のクラスター環境において、OS の負荷が原因で、クラスター ハートビート通信が失敗するお問い合わせをいただくことがよくあります。
また、場合によっては、一部のノードのクラスター サービスが停止し、フェールオーバーが発生する場合があります。

クラスター ハートビート通信の詳細とハートビートのタイムアウト変更手順については、下記 Blog にてご紹介しているため、ここでは省略させていただきます。
フェールオーバー クラスターのハートビートについて
http://blogs.technet.com/b/askcorejp/archive/2012/03/22/3488080.aspx

クラスター ハートビート通信は、上記の Blog でも触れられているように、既定で 5 秒間通信が途絶えるとハートビート通信の失敗と判断され、エラーが記録されます。
「通信が途絶える」という点については、ネットワーク上の問題以外にも、OS の負荷が著しく増加した場合にハートビート パケットの送信が一定期間できなくなり、ハートビート通信が失敗と判断されることがあります。

ハートビートの通信を妨げる高負荷の原因としては様々な要因がありますが、弊社製品では VSS (Volume Shadow Copy Service) が、大容量のディスクに対し SnapShot を作成した際に、この問題が発生する事例が報告されております。Snapshot が作成されるタイミングとしては、該当ボリュームのバックアップを取得しようとした際や、共有フォルダのシャドウ コピーを有効にしている場合があります。
また、Windows Server 2012 では、重複排除機能を有効にした場合にも VSS が使用されます。

Snapshot 作成時には、一時的にボリュームに対する I/O を停止する必要があるため、できる限り高い優先度で素早く実行する必要があります。そのため、ハートビートなどの Snapshot 作成以外の処理が待たされ、結果としてハートビート通信が失敗する場合があります。 また Snapshot 対象のボリュームのサイズが大きければ大きいほど作成処理にかかる時間も長くなるため、結果としてハートビート通信の失敗が発生しやすくなります。

弊社ではこの問題を回避するために VSS の処理を見直し、Snapshot 作成時にほかの処理が待たされないよう変更しました。(2013年9月11日にリリース)
下記の公開情報で修正プログラムがダウンロードできますので、Snapshot 作成時にハートビート通信の失敗が発生している環境に適用し、現象が回避できるか確認をお願いいたします。

I/O failures occur when you create a snapshot for a large volume in Windows Server 2012 or Windows Server 2008 R2 SP1
http://support.microsoft.com/kb/2871085/en-us
※ Windows Server 2012 R2 ではすでにこの修正プログラムと同様の動作に変更されております。

上記修正プログラムは Windows Server 2008 R2 SP1 以降の OS のみ適用可能なため、それ以外の OS をご利用の場合や、上記修正プログラムで改善しない場合には、負荷を下げるか、ハートビートの閾値を大きくします。
VSS が負荷の原因であった場合には、Snapshot 作成にかかる時間を短くする必要があります。CPU など、ハードウェアをより高性能なものに変更するといった方法もありますが、それ以外の現実的な対処としては、対象のボリューム サイズを小さくすることです。トータルのサイズを小さくできない場合には、ボリュームを複数に分割し、それぞれの SnapShot 作成のタイミングをずらすことで回避可能です。

この現象を抑制するための最適なボリュームのサイズについては、実際にはハードウェアのスペックなどに依存するため、具体的なサイズをお伝えすることは難しいです。そのため、推奨するボリューム サイズや、上限サイズなども特に定義はしておりません。
参考情報といたしまして、弊社の事例にて、5 TB のボリュームの Snapshot 作成時にハートビート通信が失敗したという環境がございました。
なお、VSS 以外の負荷原因を特定するには、現象発生時のパフォーマンスログが調査に有効な情報となります。

ボリュームの分割が難しい場合や、VSS 以外の負荷で発生しており、その負荷を下げることができない場合には、負荷が発生する時間帯に、ハートビートの閾値と間隔を延ばしていただく回避策の実施をご検討ください。
バックアップなどの負荷がかかるジョブを実行する前に、ハートビートの閾値を延ばすコマンドを組み込んだバッチファイルをタスク スケジューラなどで実行し、ジョブ完了後に、閾値を元に戻すコマンドを組み込んだバッチファイルを実行する方法などが回避策として有効です。

ハートビートのタイムアウト値については推奨値はなく、環境に合わせて柔軟に変更可能ですので、OS やネットワーク負荷によるハートビート通信が失敗している環境では、適宜変更をお願いします。

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

Windows をご利用のお客様から、OS の予期せぬシャットダウンのお問い合わせをよくいただきますが、原因としてどのようなことが考えられるのかをご紹介します。

 サーバーやクライアント PC が突然再起動する現象が発生し、以下のイベントが記録されることがあります。

 -------------------------------------

ソース: EventLog

イベント ID: 6008

メッセージ: 以前のシステム シャットダウン ( YYYY/MM/DD HH:MM:SS) は予期されていませんでした。

-------------------------------------

 このイベントとは別に、以下のイベントが記録されている場合もあります。

 ----------------------------------------------

ソース: Microsoft-Windows-Kernel-Power

イベント ID:41

メッセージ：システムは正常にシャットダウンする前に再起動しました。

----------------------------------------------

これらのイベントからは前回のシャットダウンが正常ではなかったことはわかりますが、予期せぬシャットダウンが発生した理由はわかりません。

 ご存知の方も多くいらっしゃると思いますが、STOP エラー (ブルー スクリーン) により再起動が発生し、このようなイベントが記録された場合はメモリダンプから発生原因の調査をすることが有効です。

ただし、メモリ ダンプを取得するよう設定しているにも関わらず、メモリ ダンプが生成されない場合もあります。また、STOP エラーが発生していないにも関わらず、予期せぬシャットダウンが発生する場合もあります。

以下に、予期せぬシャットダウンが発生した際の考えられる原因およびメモリ ダンプが作成されない原因についてもご説明いたします。

考えられる原因は？

------------------

 予期せぬシャットダウンのイベントが記録される考えられる原因としましては、大きく分けて、ソフトウェア要因とハードウェア要因の 2 種類に分類できます。

- ソフトウェア要因

 Windows のシャットダウンプロセスは、通常、次の流れで行われます。

1. デスクトップ上で動作するプロセスの停止

2. サービスプロセスの停止

3. デバイスの停止

4. I/O 要求の抑止

5. ファイルシステムキャッシュ情報のフラッシュ

6. ハードウェアのリセット/電源 OFF

Windows では、通常のシャットダウンとは異なるメカニズムでシャットダウンが行われると、EventLog サービスがソース: EventLog, ID 6008 のイベントを記録します。

また、EventLog サービスが正常終了した場合でも、その後シャットダウン処理が正しく行われないと、ソース: Microsoft-Windows-Kernel-Power の ID:41 イベントを記録します。

このイベントの検知については、技術情報がありますので、後述の参考文書 (KB2028504) をご参照ください。

通常、STOP エラーによる再起動が発生した場合には、 Eventlog イベント ID: 6008 と共に、次のような System Error イベント ID: 1003 および Save Dump イベント ID: 1001 が記録され、メモリ ダンプが生成されます。

<System Error イベント ID: 1003>

イベントの種類: エラー

イベント ソース: System Error

イベント カテゴリ: (102)

イベント ID: 1003

説明:

エラー コード xxxxxxxx、パラメータ1 xxxxxxxx、パラメータ2 xxxxxxxx, パラメータ3 xxxxxxxx、パラメータ4 xxxxxxxx.

<Save Dump イベント ID: 1001>

イベントの種類: 情報

イベント ソース: Save Dump

イベント カテゴリ: なし

イベント ID: 1001

説明:

このコンピュータはバグチェック後、再起動されました。

バグチェック: xxxxxxxx (xxxxxxxx, xxxxxxxx,
xxxxxxxx, xxxxxxxx)

ダンプが保存されました: C:\WINDOWS\MEMORY.DMP

なお、現象時には、状況によりダンプ ファイルが取得できないことも考えられますが、その場合は、System Error イベント ID: 1003 のエラー イベントが記録されます。

- 参考資料

Source: System Error Event ID: 1003
(Windows Operating System 5.2) - Technet Events And Errors Message Center:Message Details

http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=1003&EvtSrc=System+Error&LCID=1033

 メモリダンプ（memory.dmp）は既定の設定で C:\windows の直下に作成されますので、この情報をもとに、エラーの原因を調査することができます。

 一般的に、ソフトウェア要因にて STOP エラーが発生する要因は以下の 2 種類です。

A.     OS、もしくはドライバーの動作過程にて、ハンドル出来ない例外 (Secondchance exception) が発生する。

B.     OS、もしくはドライバーの動作過程にて、異常が発生したため、その処理内で意図的に　STOP エラーを発生させる。

A は、通常、OS 上で動作するアプリケーションだと、アプリケーション単体でクラッシュする状況です。これが OS の処理内で発生すると、システム全体が停止します。

B は、そのような本来予定していないデータを検知するなど、「このまま OS を動作させていると、安定した動作が約束されない」という状況をプログラム内で想定しており、そのような事態になった場合に発生します。

STOP エラーが発生した場合、「OS かドライバーの処理に問題があったためである」というのが原則です。

ただし、問題を検知した場合も、どのようなコンポーネントが問題であったのか等、詳細はメモリダンプを解析して確かめる必要があります。

原則としては、ソフトウェア要因の場合にはメモリダンプが記録されますが、ディスク ドライブの問題など、ダンプ自体が記録出来ない場合にはメモリダンプが記録されない場合もあります。このような場合には、原因の特定は困難です。

- ハードウェア要因

 メモリ ダンプを取得するよう設定しているにも関わらず、メモリダンプが確認できない場合には、ハードウェア的な要因で発生している可能性が高いと考えられます。

メモリ、システム ボード、CPU などに異常が発生している場合に、サーバー異常を検知するハードウェア側の自動システム復旧の機能により再起動が行われる場合がございます。

この再起動によって、EventLog サービスの動作が中断され、ソース: EventLog, ID 6008 のイベントが記録されます。

ただし、この場合は、OS 側でエラ―を検知した状況ではないため、STOP エラー等は発生せずダンプ ファイルも生成されません。

メモリダンプが作成されない原因は？

----------------------------------

 上述のように、メモリダンプが作成されない原因として、ハードウェア要因により自動システム復旧の機能で再起動が行われたことが考えられます。

この場合、STOP エラーの形跡が残らずメモリダンプも作成されない状況が発生しえます。

また、メモリダンプの作成途中で自動システム再起動が行われた場合も同様の結果となりメモリダンプが作成されません。

このような状況では、OS 側から原因を調べることはできず、ハードウェア観点から原因を確認していく必要があります。

また、メモリダンプが作成されない原因としては、以下のような設定や構成上の問題である場合もございます。

・ブートドライブ上のページング ファイル（pagefile.sys）が存在しない

・ブートドライブ上のページング ファイルのサイズが十分でない

・ブートドライブ上のページング ファイル が断片化している

・メモリダンプがすでに存在し、上書きをしない設定になっている（[既存のファイルに上書きする] チェック ボックスがオフ）

・メモリダンプの保存先に、存在しないフォルダやドライブが指定されている

・メモリダンプの保存先に、Memory.dmp ファイル作成に必要な空き容量がない

予期せぬシャットダウンのイベントが記録されました場合、お問い合わせ環境で確認いただきたい項目としては以下の 2 点になります。

1．ハードウェア要因により自動システム復旧の機能で再起動が行われたかどうか確認します

2．ダンプを生成する設定や構成上の問題がないか確認します

上記の内容が予期せぬシャットダウン発生の問題についてご参考になれば幸いです。

補足情報

------------------------

Windows 7 および Windows Server 2008 R2 環境にて、以下の既知の問題が報告されています。

文書番号： 2549760

タイトル：レジストリの WaitToKillServiceTimeout 値は Windows 7 または Windows サーバー 2008 R2 で機能しません。

http://support.microsoft.com/kb/2549760/ja
(機械翻訳)

WaitToKillServiceTimeout registry valuedoes not work in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2549760/en-us

下記のレジストリ値を設定することで、サービス コントロール マネージャが、サービスがシャットダウン要求を完了するまで待つ時間を設定することが出来ます。(ミリ秒単位で指定します。)

HKLM\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout　

この設定値は、既定値として12秒に設定されておりましたが、Windows 7 または Windows サーバー 2008 R2 では、この設定値が適切に処理されておらず、設定値の有り無しにかかわらず、5秒にてサービスが強制的に終了されてしまいます。

その為に、例えば多くのサービスがインストールされている状態などにおいて、特定のアプリケーション サービスの終了処理に時間がかかってしまうと、イベントログサービスの停止処理にも影響を与える可能性があります。この場合に ID 6008 が記録される場合もあります。

 修正プログラム (技術情報 2549760） をインストールするだけで、正しい既定値である12秒に設定されます。

また、修正を適用することで該当レジストリ値を変更して待機時間のチューニングが可能となります。

Windows 7 または Windows Server 2008 R2 をご利用のお客様は上記もご参考いただければと存じます。

-参考情報

 文書番号: 972110

タイトル: Windows Server 2003 でカーネル ダンプファイルまたは完全メモリ ダンプ ファイルを生成する方法

URL: http://support.microsoft.com/kb/972110/ja

文書番号: 130536

タイトル: クラッシュ後Windows でメモリ ダンプ ファイルが保存されない

URL: http://support.microsoft.com/kb/130536/ja

文書番号: 824674

タイトル: Windows Server 2003 でカーネル メモリダンプを保存する際にカウンタが 99 で止まる

URL: http://support.microsoft.com/kb/824674/ja

文書番号: 2028504

タイトル:Windows 7 または Windows Server 2008 R2 で Windows カーネルイベント ID 41 エラー"システムは正常にシャットダウンする前に再起動しました" が発生する

URL: http://support.microsoft.com/kb/2028504/ja

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

 以前、リソース不足について – 番外編1 (64bit 環境での注意点)という記事で、64 bit 環境でシステムキャッシュ (RAMMap で確認した場合は Mapped File や Metafile)  で物理メモリを大量に使用してしまう動作についてご紹介しました。この記事の中では、Windows 7 以降の OS ではシステム  キャッシュ周りのデザイン変更が行われているとご説明しましたが、やはり Windows Server 2008 R2 でも同様の状況が発生するとのお問い合わせをいただく事があります。 

Windows 7 以降の OS では、システムキャッシュをより早く解放出来るようになっているので、物理メモリの大半をシステムキャッシュが占めていてもメモリ確保には問題がない場面も多いのですが、それでも一度にまとまった要求が行われた場合などには「メモリ不足」のエラーになってしまう事があります。対処策としては、システムキャッシュのワーキングセットの閾値を指定する事になりますが、これを行うためのツールとして弊社が公開している Microsoft Windows Dynamic Cache Serviceでは、Windows 7 以降 (OS バージョン 6.1 以降) では意図的に動作しないように制限がかけられているため、これを解除してビルドし直す必要があります。今回の投稿では、Windows Server 2008 R2 環境でMicrosoft Windows Dynamic Cache Serviceを利用する方法についてご紹介します。

OS バージョンのチェックの箇所

Microsoft Windows Dynamic Cache Service には、ダウンロード ファイルの中にこのツールのソースコードも含まれています。この中の DynCache.cpp の 1141 行目付近がバージョン チェックを実施していますが、Windows Server 2008 R2 環境で利用するには下記の (OSVerInfo.dwMinorVersion > 0) を (OSVerInfo.dwMinorVersion > 1) に変更する必要があります。

ビルド方法

ここでは Microsoft Windows SDK for Windows 7 (以下 SDK) と Windows Driver Kit Version 7.1.0 (以下 WDK) を用いた方法をご紹介します。
 

1. 以下のダウンロードセンターから、ビルド環境にあったものをダウンロードします。(ISO ファイルになっているので DVD に一旦焼くか、Hyper-V や Virtual PC のゲスト環境でビルド環境を構築できる場合には、ISO のキャプチャで読み込む事になります。) 

Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1 (ISO)

Windows Driver Kit Version 7.1.0

 自動再生でインストールが始まりますが、始まらない場合は SDK の場合は setup.exe をクリックしてインストールを開始します。SDK のインストールはウィザードに沿って既定のまま進めて問題ありません。

WDK のインストールは、KitSetup.exe を実行し、インストールのチェックボックスでは Full Development Environment にチェックを入れ、インストールを実行します。

 
2. インストール完了後、SDK のインストールフォルダ内にある以下を C:\SDK など、スペースを含まないパスへコピーします。

•  Include 
• Lib

3. Microsoft Windows Dynamic Cache Service 内の DynCache\source フォルダ内にある sources を右クリックのプロパティで読み取り専用を外した後に notepad.exe などのテキスト エディタで開き、以下のように書き換えます。(項目 2 のフォルダを C:\SDK 配下にコピーした場合の例です)

4. DynCache.cpp の内容変更後 (こちらも読み取り専用のチェックを外す必要があります)、以下のコマンドプロンプトを起動します。

[スタート] - [すべてのプログラム] - [Windows Driver Kits] - [WDK 7600.16385.1] - [Build Environments] - [Windows 7] -  [x64 Free Build Environment]

5. 起動したコマンドプロンプト内で、DynCache の source フォルダへ移動し、以下のコマンドでビルドが開始されます。

(画面出力例)

source フォルダ内の obj\amd64 フォルダに DynCache.exe が生成されます。Microsoft Windows Dynamic Cache Service はこのファイルに置き換えて利用ください。Microsoft Windows Dynamic Cache Service のご利用方法については、Read me や Dynamic Cache Service についてをご参照ください。

こんにちは。Windows テクノロジー サポート チームです。

WMI に関するお問い合わせを多くいただいておりますので、
WMI に関する修正プログラムについてご紹介したいと思います。

なお、今回は Windows Server 2012 および Windows Server 2008 R2 を
対象にご紹介しておりますが、Windows Server 2008 を対象にした
修正プログラムについては、以下のブログで紹介させて頂いておりますので
よろしければ合わせてご確認ください。

まず、Windows Server 2012 の WMI に関する
既知の現象といたしましては以下の 2 点があります。

Windows Server 2012

これら 2 つの現象については、
以下の 2013 年 4 月の累積の更新プログラムを適用する事により
対処する事が可能です。
(KB2792123 については個別の修正プログラムもございます。)

以下では Windows Server 2008 R2 の WMI に関する
修正プログラムについて、各カテゴリごとにまとめさせていただきました。

Windows Server 2008 R2/Windows 7

- メモリ リーク

上記の修正プログラムには、印刷処理に関する修正や電源管理についての修正も含まれます。
ご利用いただいている環境構成により適用をご検討ください。

- 処理応答遅延/停止

上記は、パフォーマンス ダウンや WMI 関連サービスの予期せぬ停止などの際に適用をご検討ください。

- クラスター環境

上記の修正プログラムには、クラスターを構成している環境にて発生し得る問題に対しての修正となります。

- パフォーマンス オブジェクト関連

- その他

[2013 年 6 月 20 日 追記]

なお、上記は同じモジュールの更新を複数含むリストとなりますため、
以下では、Windows Server 2008 R2 SP1 対象のモジュールを
最新の状態とするために必要な最小限の更新プログラム リストを
ご紹介させていただきます。

こんにちは。Windows テクノロジー サポート チームです。

前回 WMI に関する修正プログラムについて、
Windows Server 2012 および Windows Server 2008 R2 を
対象にご紹介いたしましたが、今回は Windows Server 2008 用の
修正プログラムについていてご紹介したいと思います。

なお、Windows Server 2012 および Windows Server 2008 R2 の
修正プログラムについては、以下のブログで紹介させて頂いておりますので
よろしければ合わせてご確認ください。

Windows Server 2008

- メモリ リーク

上記の修正プログラムは、メモリ リークに対しての修正となります。

- 処理応答遅延/停止

上記は、パフォーマンス ダウンや WMI 関連サービスの予期せぬ停止などの際に適用をご検討ください。

- クラスター環境

上記の修正プログラムには、クラスターを構成している環境にて発生し得る問題に対しての修正となります。

- パフォーマンス オブジェクト関連

- リポジトリ破損

- その他

[2013 年 6 月 20 日 追記]

なお、上記は同じモジュールの更新を複数含むリストとなりますため、
以下では、Windows Server 2008 SP2 対象のモジュールを
最新の状態とするために必要な最小限の更新プログラム リストを
ご紹介させていただきます。

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

日々のサポート業務の中で、お問い合わせを頂く内容についてご紹介します。

今回は Window 7 で標準の機能となっている「スタートアップ修復」の無効化方法についてご紹介します。管理上「スタートアップ修復」によるシステムの復元をユーザーに行わせたくない場合には以下の手順をご参照下さい。まず「スタートアップ修復」の機能について知りたい方は “補足（スタートアップ修復について）” で説明しておりますので、そちらを先にご確認ください。

「スタートアップ修復」は既存の設定でシステムの復元機能が有効になっており、実行すると直近の復元ポイントに復元されます。最近インストールしたドライバやソフトウェアなどが起動障害の原因である場合、システムの復元が自動実行されることで障害が取り除かれます。

しかしグループ ポリシーなどでシステムの復元を無効にしている環境では、新たに復元ポイントが作成されることはなく古い復元ポイントのみが残ってしまっている場合があり、スタートアップ修復が行われた結果として、システムを構築した時点の環境に復元されてしまう場合があります。このような環境においては、以下に記載したスタートアップ修復の無効化および復元ポイントの削除が有効な場合がございます。

・スタートアップ修復の無効化方法

以下にスタートアップ修復を無効化する手順を紹介いたします。

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

2. 下記の 2 つのコマンドを実行します。

bcdedit /set {current} recoveryenabled No

bcdedit /deletevalue {current} recoverysequence

また以下のコマンドにて再度有効にする事が出来ます。

bcdedit /set {current} recoveryenabled Yes

(補足)

対象となるWindows ブート ローダーの identifier に {current} 以外の値が設定されている場合は、各端末毎にGUID を確認していただく必要がございます。

Windows ブート ローダーの値の確認は bcdedit コマンドで確認できます。

・復元ポイントの削除方法について

以前の復元ポイントに戻る事を回避する為に、スタートアップ修復の無効化に加え、システムの復元ポイントを削除する場合には以下の手順をご参照ください。

システムの保護は、シャドウ コピーの機能を利用して情報を管理しており以下のコマンドの実行により、復元ポイントの削除が可能です。

Vssadmin Delete shadows /All

削除されたかどうかは、下記のコマンドを実施し、「クエリを満たす項目が何もありませんでした」となれば、削除は成功しています。

Vssadmin List Shadows

・補足（スタートアップ修復について）

Windows 7 では既定で自動フェールオーバーという機能が有効であり、システムの起動に何らかの要因で失敗した場合、Windows RE (回復環境)にフェール オーバーさせ、[スタートアップ修復] の機能を提供します。

システムの起動後、以下の様な画面が表示されます。

しばらくすると、選択されている項目で自動的に起動されます。ここでスタートアップ修復の起動（推奨）が選択されていた場合には以下の画面が表示されます。

そして次に [システムの復元] を実施するかの選択画面に推移します。

単に [スタートアップ修復] を実施するのであれば問題はありませんが、ここで誘導される [システムの復元] を行う場合にはいつの復元ポイントに戻るかについて考慮する必要があります。

Windows 7 では Windows Update などによる更新プログラムのインストールやドライバのアップデートの際、自動で復元ポイントが作成され、あるいは前回復元ポイントが作成されてから 7 日以上経過している場合は自動で復元ポイントが作成されます。

以下参考情報となりますので併せてご参照ください。

<参考情報>

Windows RE の機能: http://technet.microsoft.com/ja-jp/library/dd744291(v=ws.10).aspx

Windows 回復環境テクニカル リファレンス: http://technet.microsoft.com/ja-jp/library/dd744255(v=ws.10).aspx

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

今日は iSCSI ソフトウェア イニシエーターを利用される場合の注意点についてお話ししたいと思います。

Windows OS では Windows Server 2003 以降 Microsoft iSCSI Software Initiator を利用することで、iSCSI ターゲットへの接続を行うことができます。
Windows Server 2003 では、以下の弊社ダウンロード センターからイニシエーターをダウンロードする必要がありますが、Windows Vista/Windows Server 2008 以降は OS の標準機能として搭載されています。

 Microsoft iSCSI Software Initiator Version 2.08
 http://www.microsoft.com/en-us/download/details.aspx?id=18986

iSCSI Software Initiator を利用すると、既存のネットワーク インフラストラクチャーを利用して iSCSI ストレージへの接続が可能になるため、比較的手軽に SAN 環境を利用でき、多くのお客様にご利用いただいています。

ただし、iSCSI 環境特有の障害お問い合わせも少なからず頂戴しています。
iSCSI Software Initiator では、ハードウェアの HBA を用いた接続と比べ、ハードウェアの行っている処理部分をソフトウェア部分で代行していることになりますため、高パフォーマンスが必要な状況下や、複数のテクノロジーを組み合わせた処理を行っている状況下で、接続が不安定になるという障害報告が内容として多い状況です。

具体的には、弊社フェールオーバー クラスタリング (WSFC) や、Hyper-V、VSS (ボリューム シャドウ コピー) と併用した場合などがあります。フェールオーバー クラスタリングと Hyper-V を組み合わせた環境や、Hyper-V 環境でゲストの稼働中に VSS バックアップを行う場合 (オンライン バックアップ) などはストレージに対して、複雑、かつ、高パフォーマンスが求められる処理が行われますので、ネットワークの問題が顕在化する場合があります。
これらの環境で iSCSI をご利用の際には、事前に負荷テストも含めた十分な検証を実施されることを強くお勧めします。

また、iSCSI の性質上、ストレージ通信のための処理とネットワーク通信の処理が重なっているために処理が複雑になっている点や、ネットワーク環境側の問題の可能性、ネットワーク機器との相性/親和性も考慮する必要があるため、トラブルシュートが非常に難解になる場合が多いです。
ネットワーク パケットを確認するという調査アプローチもありますが、流量が膨大であるため、この解析から根本原因にたどり着けるケースは残念ながら多くない状況です。

そのため、iSCSI の問題の場合、一般的に以下の対応や切り分けのアプローチをお願いしています。
iSCSI の接続が不安定になるなどの問題が発生したときの対処方法として、参考にしていただければと思います。

ご確認項目
=====================
1. ネットワーク経路、ターゲット デバイスの確認について
2. NIC の受信バッファ サイズ、遅延 ACK に関する設定の変更について
3. 最新ドライバーのインストールについて
4. その他最適化機能の無効化について
5. イニシエーターの接続設定について

以下に各項目について説明します。

1. ネットワーク経路、ターゲット デバイスの確認について
-----------------------------------------------------------
まずはターゲット デバイスや、ネットワーク経路に問題 (機器側のエラーや再送の多発など) が発生していないかをご確認ください。

2. NIC の受信バッファ サイズ、遅延 ACK に関する設定の変更について
----------------------------------------------------------------------
iSCSI の接続が不安定な状況やパフォーマンスが出ていない場合、以下の公開情報に記載されている事象が発生している可能性があります。
受信バッファ サイズの拡張や、遅延 ACK の無効化をご検討ください。

文書番号: 981482
Windows Server 2008 および Windows Server 2008 R2 環境に、遅延 ACK が有効に設定されたネットワーク環境と iSCSI 接続されたストレージを持つ場合一般的な操作をするとシステム イベント ログに iScsiPrt のエラーが出力される
http://support.microsoft.com/kb/981482

なお、受信バッファ サイズについては基本的にはなるべく大きなサイズに設定することを推奨しています。メモリ消費量が多くなる可能性がありますが、基本的に大きな差異はありません。
遅延 Ack については、無効にすることで上記問題の影響を確実に切り分けることができるメリットがありますが、本来パフォーマンス向上のための機能ですので、無効時には逆にパフォーマンスが悪くなる可能性があります。
ただし、顕著に遅くなるなどの障害は基本的には起きませんので、問題の切り分けには有効です。

3. 最新ドライバーのインストールについて
-------------------------------------------------
NIC ドライバーの最新版への更新をご検討ください。最新版ドライバーの入手方法はご提供元のベンダー様へご確認ください。
また、iSCSI 用のドライバー (msiscsi.sys) の最新版 (2013 年 6 月時点) の適用をご検討ください。

// Windows Server 2012 用
文書番号 : 2779768
Windows 8 および Windows Server 2012 の累積的な更新プログラム (2012 年 12 月)
http://support.microsoft.com/kb/2779768

// Windows Server 2008 R2/Windows Server 2008 用
文書番号: 2684681
Iscsicpl.exe プロセスは、ストレージ デバイスは、Windows Vista、Windows Server 2008、Windows 7 は、または Windows Server 2008 R2 を実行しているコンピューターに再接続しようとするとを応答を停止します。
http://support.microsoft.com/kb/2684681

// Windows Server 2003 用
文書番号 : 2277122
Stop error in Windows Server 2003 or in Windows Server 2008 R2 if a computer has some iSCSI disks and the computer is under a heavy stress situation: "0x000000D1"
http://support.microsoft.com/kb/2277122

4. その他最適化機能の無効化について
----------------------------------------
SNP (Scalable Networking Pack) や、VMQ など、ネットワーク通信に関する最適化機能を用いている場合、ご利用の NIC デバイス等の親和性の問題により接続が不安定になる場合があります。
以下の参考資料をご参照いただき、無効化などの切り分けをご検討ください。

予期せぬ挙動が!?　新機能 Scalable Networking Pack をご存知ですか?
http://blogs.technet.com/b/jpntsblog/archive/2010/03/23/scalable-networking-pack.aspx

Hyper-V 環境では以下もご確認ください。
仮想マシンの通信速度遅延 - VMQ 無効化手順 -
http://blogs.technet.com/b/jpntsblog/archive/2013/04/12/vmq.aspx

また、その他ジャンボ フレームなど、NIC 側の最適化機能がありましたら、一時的に無効化して切り分ける方法もご検討ください。

なお、上記は本来はパフォーマンスを向上させるための機能であり、無効化時には逆にパフォーマンスの問題が生じる可能性がありますのでご注意ください。

5. イニシエーターの接続設定について
----------------------------------------
イニシエーターから接続を行う際に使用されるアダプター、IP アドレス等は既定では自動選択される状態になっています。
この選択については、ターゲットへ接続する際に [詳細設定] メニューを開き、これを “既定値” から変更することで明示的に指定することが可能です。
この設定により、意図しない接続ルートが使われることを抑止できますので、この設定もご検討ください。

設定方法 (Windows Server 2008 R2 の例)

iSCSI イニシエーターを起動します。
[接続] を押します。  

[詳細設定] を押します。

 “ローカル アダプター”、”イニシエーター IP”、”ターゲット ポータル IP” を 「既定値」から変更し、明示的に設定します。

 *** 

以上、iSCSI ソフトウェア イニシエーターを利用されている環境で問題が発生した場合の手助けになれば幸いです。

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

日々のサポート業務の中で、お問い合わせを頂く内容についてご紹介します。

Windows Server 2008 ベースのクラスター環境においてパブリック ネットワークにデフォルト ゲートウェイを設定していない事によってクラスターのフェールオーバーが意図通りに発生しないというお問い合わせをいただく事があります。これは Windows Server 2003 と2008 におけるネットワークの正常性確認の動きが違う事に起因して発生します。今回はその仕組みについてご紹介します。

まずそれぞれの OS のネットワーク障害の検出と回復についての基本的な動作については、以下のURL をご確認ください。

- 参考 Windows Server での正常性確認について：

・Windows Server 2003 ベース

2 ノードのサーバー クラスタにおけるネットワーク障害の検出と回復

http://support.microsoft.com/kb/242600/ja

・Windows Server 2008 ベース

2 ノードのサーバー クラスタにおけるネットワーク障害の検出と回復(2008 ベース)

http://support.microsoft.com/kb/2862888

クラスターのネットワーク障害の検出は、クラスターがサービスを提供するパブリック ネットワークでノード間通信が正常に行われない場合に実施されます。その際、ネットワークのどこで障害が発生したかを検知するために、各ノード共通でアクセス可能なアドレスに疎通確認を行います。Windows Server 2003 ベースでは PING を送信する宛先リスト（PINGLIST）を作成し、このリストに従い複数のアドレスに疎通確認を行います。しかしWindows Server 2008では複数の PING の送信先を持たず、デフォルト ゲートウェイのみに疎通確認を行います。そのため、Windows Server  2008 においてはサービスを提供するネットワーク（大体はパブリック ネットワークとして構成）に必ずデフォルト ゲートウェイを設定する必要があります。

デフォルト ゲートウェイを設定しない場合にはノード間通信に失敗した際にどのネットワーク インターフェースで障害が起きたか検知されません。つまりネットワークで障害が発生した場合にどちらのノードが正常か判断できないため、例えば NIC の障害が発生したノードでリソースを持っていても、正常なノードにフェールオーバーされません。

以下の簡単なシナリオをご参考ください。

シナリオ：デフォルト ゲートウェイの設定が無い場合（2008 ベース）

• ノード A のネットワーク インターフェースでネットワーク障害が発生します。

• ノード A とノード B は通信できません。

結果

• ノード A とノード B 両方のネットワーク インターフェースの状態は到達不能となり、ネットワークの状態はパーティション分割になります。

• リソース グループはフェールオーバーせず、オンラインのまま現在の所有者のノードに留まります。

Windows Server 2003においては PINGLIST が作成され、優先順位の高いものから順番に PING が送信されます。PINGLIST には両ノードからアクセス可能なアドレスが選ばれます（PINGLIST の詳細については上記URLの2003 ベースを確認してください）。しかし Windows Server 2008からはネットワーク障害が検知されてからなるべく早く正常なノードへフェールオーバーを行う観点から、デフォルト ゲートウェイのみに PING が送信されます。Windows Server 2008において PING の送信先をレジストリなどから変更することはできません。

また Windows Server 2003においては PINGLIST のすべてのアドレスからの応答がなかった場合には、一定時間後に再度優先順位の高いアドレスに PING が再送されていましたが、Windows Server 2008においては再送される設定はありません。

上記においてバージョンにおけるネットワークの障害の検出方法を比較しましたが、Windows Server 2008 でデフォルト ゲートウェイが設定されていれば、通常運用においては Windows Server 2003 と大きな違いはありません。

こんにちは。

Windows サポートの丸山です。

本日は、Windows 7 から新しく追加された "デバイスとプリンター" 画面で発生する現象についてお話しします。

弊社では、"デバイスとプリンター" 画面からプリンターの追加を行っても、追加したプリンターが表示されないことがある。といったお問い合わせをいただくことがあります。

この動作は、Windows 7 からの "デバイスとプリンター" 画面に実装された、多機能デバイス サポートのためのデバイス コンテナーのグループ化機能によるものです。

"デバイスとプリンター" 画面では、プリンターとスキャナー機能を併せ持った複合機など、複数の機能を持った多機能デバイスをより直感的に表示するために、ContainerIDと呼ばれるデバイスのパラメーターを参照し、同じ物理デバイスであると認識されるデバイスをグループ化して表示します。

また、このとき、プラグ アンド プレイ経由でのパラメーター取得が行われないローカル プリンターでは、同じプリンター ドライバー、同じポート (LPT1: など) を指定してプリンターのインストールを行った場合に、それらのプリンターはすべて同一の ContainerIDが割り当てられる動作であることがわかっています。

たとえば、"MS Publisher Color Printer" というプリンター ドライバーを使用して、"MS Publisher Color Printer 1" というプリンターと、"MS Publisher Color Printer 2" という 2 つのプリンターを追加する例を見てみましょう。

プリンターを作成し、"デバイスとプリンター" 画面を開きますと、次のような画面になります。

デバイス コンテナーがグループ化されているため、プリンターのアイコンはひとつしか表示されておりません。

ここでは、グループ化されたアイコンを右クリックして、オプションを選択すると、すべてのプリンターを見つけることができます。

また、グループ化されたアイコンの名前は、グループ化されているプリンターの中から、どれかひとつの名前が表示されています。

- プリンターのグループ化が好ましくない場合には

なんらかの理由があり、複数のプリンターがグループ化されて表示されてしまうことが好ましくない場合には、次の手順を参考に、デスクトップ上にカスタム フォルダーを作成することを検討してください。

1. 管理者権限を持ったユーザーにて、レジストリ エディターを開きます。

2. 以下のレジストリ キーを展開し、選択します。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace

3. "NameSpace" レジストリ キーを右クリックして '新しいキー' をクリックします。

4. 次の通り、新しいレジストリ キーの名前を入力してください。

{2227a280-3aea-1069-a2de-08002b30309d}
※角かっこはそのまま含めるようにしてください。

5. 右側のウィンドウでレジストリ値 (既定) を右クリックし、"修正" をクリックします。

6. 次の通り、新しい値を入力してください。

プリンター
※値を設定後の画面はこのようになります。

7. レジストリ エディターを終了します。

8. デスクトップ上を右クリックし、[更新] をクリックします。

以上の手順を実行しますと、デスクトップ上に 'プリンター' と呼ばれる新しいアイコンが表示されます。

新しいアイコンをダブルクリックして開きますと、従来通り、すべてのプリンターが個別に表示され、印刷キューの管理などを実施することができます。

※レジストリに関する注意事項

レジストリの直接編集により誤った設定を行った場合、システムが起動しなくなるなどの重大な問題を引き起こす可能性があります。
レジストリを直接編集する場合は、検証環境で事前に手順を確認するか、システムのバックアップをあらかじめ作成しておくなど、十分な配慮をお願いします。

- プリンターの ContainerID について

弊社では、ローカルプリンターを作成する際に、以下の要因によってプリンターの ContainerIDが作成されることを確認しております。

• 同じプリンター ドライバーが使用されている
• 同じポートが割り当てられている
• HardwareIDが同一である

なお、ネットワーク共有プリンターへの接続を行い、表示されているプリンターには、それぞれ個別の ContainerIDが割り当てられることを確認しております。

- 参考情報

下記資料はハードウェア開発者向けの資料ですが、Windows 7 からの新しいデバイス エクスペリエンスについて記載されています。ご興味があれば参照してみてください。

Windows デバイス エクスペリエンス
http://msdn.microsoft.com/ja-jp/library/windows/hardware/br259107.aspx

こちらもハードウェア開発者向けの資料ですが、デバイス コンテナーのグループ化について詳しく記述されています。

多機能デバイス サポートとデバイス コンテナーのグループ化
http://msdn.microsoft.com/ja-jp/library/windows/hardware/gg463141.aspx

また、このブログ記事は、以下のブログ記事、技術情報を参考に記述しています。

Windows 7: Where are my printers?
http://blogs.technet.com/b/askperf/archive/2010/03/02/windows-7-where-are-my-printers.aspx

Printers installed using the same driver and port on Windows are grouped as one when viewed within Devices and Printers
http://support.microsoft.com/kb/2015694

まだまだ暑い日が続きます。
おからだにはお気を付けてお過ごしください。

Windows プラットフォーム サポート担当
けまるや

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

Windows Server 2012 フェールオーバー クラスター + Hyper-V の環境で、仮想マシンのクイック マイグレーションを行った後に仮想スイッチが「構成エラー」と表示される件について説明します。

この記事でご案内する現象は、仮想マシン リソースを停止した状態でクイック マイグレーション (仮想マシンのオーナー ノードの変更操作) を行った後、マイグレーション先のターゲット ノードで仮想マシンの設定画面を表示することで確認することができますが、他にイベント ログやエラー ダイアログなどは表示されません。また、この状態で仮想マシンを起動すると「構成エラー」だった表示は正しい仮想スイッチの設定に更新され、起動後の仮想マシン(ゲスト OS )は正常に動作します。

また仮想マシンがオンライン状態で行われるマイグレーション処理ではこの表示は表面化することはなく、影響もありません。

なお、Windows Server 2008 R2 までのフェールオーバー クラスター + Hyper-V 構成ではこの表示は発生しません。

結論から申し上げますと、この表示は Windows Server 2012 に含まれる Hyper-V のデザイン変更によるものであり、この「構成エラー」は無視していただいて問題ありません。

この動作について

Windows Server 2012 ではクイック マイグレーションによってターゲット ノードに仮想マシンが移動した際のリソース (ネットワーク デバイスなど) の修正は仮想マシンのワーカー プロセス (vmwp.exe) の起動時に、動的に仮想マザーボードの Power On 処理内で実行するよう変更されました。そのため、仮想マシンの起動のタイミングで正しい値に更新が行われる動作となります。

Windows Server 2008 R2 ではクイック マイグレーション時に仮想マシン管理サービス (vmms.exe) が仮想マシン構成リソースのオンライン処理の延長でターゲット ノード側の仮想スイッチ/ポート情報に適用させるよう構成ファイルの修正を行っていました。そのため、仮想マシンを起動する前のタイミングで既に構成情報は更新済みとなっています。

Windows Server 2012 からは仮想マシンのワーカー プロセス (vmwp.exe) が起動時に変更を行うため、上記のようにオフライン状態で クイック マイグレーションを行いターゲット ノードに移動した場合、このタイミングではまだ仮想マシン プロセスは起動していないため、仮想スイッチ/ポート情報の変更が行われておらず構成情報上は「構成エラー」という形で見えてしまうようになります。この動作の違いは仮想マシン内のリソースの管理を仮想マシン管理サービス (vmms.exe) ではなく、仮想マシンのワーカー プロセス (vmwp.exe) が個別にすべての権限持って行うよう、Windows Server 2012 の仕様として変更されたことに起因しています。

上記の通り、Windows Server 2012 ではクイック マイグレーション後に仮想マシンのワーカー プロセス (vmwp.exe) が起動するタイミングで初めて構成ファイルからターゲットホスト側の仮想スイッチを検索し、検出できれば仮想 NIC の割り当てが行われます。そして、その構成変更処理の延長で構成情報が正しい内容へ修正されます。そのため、仮想マシンの起動前のタイミングで表示される「構成エラー」は無視していただいて問題ありません。

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

今回は Windows の NFS サーバーで利用される NFS Cookie についてお話しします。

NFS Cookie とは、NFS サーバーと NFS クライアント間の通信において、ディレクトリの個々のファイル エントリーに対して NFS サーバー側で割り振る値です。
NFS version 3 では、以下の RFC に記載されているとおり 64 bit Cookie が主に利用されます。

NFS Version 3 Protocol Specification
http://www.ietf.org/rfc/rfc1813.txt

READDIR
The READDIR arguments now include a verifier to allow the server to validate the cookie. The cookie is now a 64 bit unsigned integer instead of the 4 byte array which was used in the NFS version 2 protocol. This will help to reduce interoperability problems.

しかしながら、Windows で利用される NFS サーバーでは、64 bit Cookie に対応できないクライアント アプリケーションを考慮して、既定では NFS Version 3 であっても 32 bit Cookie が利用されます。
(Windows Server 2012 からは既定で 64 bit Cookie が利用されます)

一方、Windows の NTFS ファイル システム上では、それぞれのファイルは 64 bit 長の NTFS FileID という一意な値で管理されています。
32 bit Cookie ではこの NTFS FileID を利用して 32 bit Cookie が生成されますので、稀に同じ値の Cookie が異なるファイル エントリーに対して作成されてしまい、NFS クライアントで無限ループや、意図しない動作などが発生する場合があります。

その場合には、以下のサポート技術情報を参照し FileCookieV3Size の値を 4 に変更し、64 bit Cookie を使用するように構成して下さい。

FIX: You receive an error message and a client computer may stop responding when you try to run the ls command to list files or subdirectories on a large directory in Windows Services for UNIX 2.3
http://support.microsoft.com/kb/910609/en-us

上記の資料に記載されている FileCookieV3Size レジストリは、Windows Server 2012 まで同様に有効です。

また、一緒に記載されている DisableFilenameHashing については32 bit Cookie の生成時に既定で利用されるファイル名のハッシュ情報を含んだ算出方法を無効化するレジストリです。

DisableFilenameHashing  のレジストリを変更することで、32 bit Cookie の内部算出方法が変更されますので、これにより 32 bit Cookie の重複を回避できる可能性があります。
ただし、本レジストリは Windows Server 2003 R2 までは利用可能ですが、Windows Server 2008 については以下のサポート技術情報で公開されている修正プログラムを適用し、DisableFilenameHashing  を設定可能な状態に変更する必要があります。
(Windows Server 2008 R2 以降では DisableFilenameHashing による 32 bit Cookie 生成方法の変更はできません)
また、Cookie の生成に際して NTFS FileID のみが使用されるようになるため、同一 FileID を持つ、ハード リンクされたファイル同士が同一の Cookie を持つようになる点を考慮する必要もあります。

Can't perform a file operation from a UNIX client to a Windows Server 2008-based NFS server
http://support.microsoft.com/kb/2813363/en-us

NFS Version 3 が利用される環境で、NFS クライアントが 64 bit Cookie に対応している場合には、64 bit Cookie を利用していただくのが推奨される構成となりますので、NFS 通信において無限ループが発生するような場合には64 bit Cookie の利用について是非ご検討ください。

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

日々のサポート業務の中で、お問い合わせを頂く内容の中から有益な情報をご紹介いたします。

今回は Windows Server 2012 (R2 を含む) における、LUN (論理ユニット番号) の最大数をご紹介いたします。Windows Server 2012、2008 R2 のサポートする LUN の最大数は、以下の通りに変更されております。

ご覧の通り、Windows Server 2012 では、アダプターあたりのバス数の最大数が大幅に増えています。  

以前に以下のブログで Windows Server 2008 R2 のクラスター共有ボリューム (CSV) の最大数についてご紹介いたしましたが、Windows Server 2012 においても、登録できるボリュームの数は、OS で認識可能な LUN の数と同じです。

・クラスター共有ボリューム (CSV) の最大数について

http://blogs.technet.com/b/askcorejp/archive/2013/02/28/csv.aspx

-  補足

Windows Server 2008 R2 においては、サポートされているバスの最大数（8）を超えたハードウェアを利用した場合にはシステムの動作が不安定になる可能性がございますので、ご利用のハードウェア ベンダに動作が保障されているかをご確認ください。 

また、8 個以上のバスが搭載されたハードウェアを使用している場合に、警告ログを出すための修正プログラムがリリースされておりますので、適用をご検討ください。

・No warning logged when the Storport
miniport driver tries to use more than 8 SCSI buses in Windows Server 2008 R2

http://support.microsoft.com/kb/2871163

[参考資料]

文書番号 : 310072

Adding support for more than eight LUNs in Windows Server 2003 and in Windows 2000

http://support.microsoft.com/kb/310072/en-us

※ Windows Server 2003 までの情報となっておりますが、Windows Server 2008 R2 についても同様です。

文書番号 : 2821904

Windows Server 2008 R2 における iSCSI イニシエーターの最大接続数について

http://support.microsoft.com/kb/2821904

こんにちは。

Windows プラットフォーム サポートの丸山です。

最近弊社では、Windows 8 や Windows 8.1 のお問い合わせが増えてきており、盛り上がりを感じておりますが、皆様はいかがお過ごしでしょうか。

さて、本日は、Windows 8 および Windows 8.1 環境にて、移動ユーザー プロファイルにまつわるポリシー設定をおこなった場合に発生する問題について、ご紹介いたします。

まずは以下の画面をご覧ください。

図1 : Windows 8 にログオンした場合

図2 : Windows 8.1 にログオンした場合

これは、Windows 8 や Windows 8.1 に初めてユーザーがログオンしたときの画面なのですが、本来であれば、ログオン時にはスタート スクリーンに多数のタイルが並んでいるところ、この画面には少しのアイコンしかありません。また、ログオンそのものにもいつもより時間がかかるなどの事象が発生するという報告もございます。

この問題について、弊社にて確認しましたところ、この問題は、コンピューターに一時記憶されているプロファイルのコピーを管理者ユーザーが手動で削除した場合などに発生するほか、”一時記憶された移動プロファイルのコピーを削除する” のポリシーが有効な環境でも発生することがわかりました。

“一時記憶された移動プロファイルのコピーを削除する” のポリシー設定は、以下の画面にて設定することができます。

図3 : “一時記憶された移動プロファイルのコピーを削除する” のポリシー設定

問題が発生した場合の対処策について

同様の問題が発生した場合には、お手数ですがまずは “一時記憶された移動プロファイルのコピーを削除する” のポリシー設定を “未構成” に戻していただくことをご検討ください。

また、この場合にはユーザーがログオフしても移動プロファイルのコピーがそのまま残ってしまいますため、移動プロファイルのコピーを削除する必要がある場合には、同じ画面で設定可能な ”システム再起動時に指定した日数を経過しているユーザー プロファイルを削除する” のポリシーを設定していただくか、delprof ツールをご利用いただき、プロファイルの定期的な削除を行うことをご検討ください。

Download User Profile Deletion Utility (Delprof.exe)
http://www.microsoft.com/en-us/download/details.aspx?id=5405

ユーティリティ スポットライト - User Profile Deletion Utility
http://technet.microsoft.com/ja-jp/magazine/2009.05.utility.aspx

図4 : Delprof ツールのヘルプ

図5 : Delprof ツール実行時の画面例

※ Delprof ツールは、弊社 Windows 8、Windows 8.1 検証環境にて期待通りに動作していることを確認していますが、Windows 8、Windows 8.1 環境での正式動作保証はございませんため、ご注意ください。

“一時記憶された移動プロファイルのコピーを削除する” のポリシー設定について

学校のコンピューター室や会社の共有コンピューター、VDI 環境など、ドメインに所属するユーザーがいつも違ったコンピューターにログオンする状況を思い浮かべてみてください。

ログオンするコンピューターが異なってしまうと、デスクトップのアイコンの配列やマイドキュメント、お気に入りやアプリケーションの設定といった情報が、ログオンするコンピューターによって違ってしまうのは不便です。

移動プロファイルを使用することで、ユーザー固有の情報をファイル サーバーに集約し、どのコンピューターにログオンしても同じ設定が行われている状況を維持することができます。

移動プロファイル環境では、ユーザーのログオン時に移動プロファイルが格納されているファイル サーバーからプロファイルのコピーをダウンロードして、ログオフ時には更新があった情報のみをアップロードします。

また、サーバーからダウンロードした移動プロファイルのコピーはログオフ時に削除されず、次回ログオンにも使用されますので、ログオンするたびにすべてのファイルをダウンロードする必要はありません。

これは便利な仕組みなのですが、コンピューターにたくさんのユーザーが入れ代わりログオンするような状況では、時間の経過とともに移動プロファイルの一時記憶情報がどんどん蓄積されてしまいます。

このため、Windows では、ログオフ時に一時記憶された移動プロファイルのコピーを削除するためのポリシー設定を行うことで、多数のユーザーが入れ代わりログオンしても、移動プロファイルのコピーが蓄積されないよう、設定を行うことができます。

最後に

今回ご紹介した事象につきましては、類似の事象についての技術情報も公開されております。

あわせてご参考いただけますと幸いです。

Win8: App: Modern: Application considrations for roaming profiles
http://support.microsoft.com/kb/2795607

今後も Windows 8 や Windows 8.1 などの新しい OS に関する情報を積極的に公開していきます。

皆様も末永いお付き合いをどうぞよろしくお願いいたします。

Windows プラットフォーム サポート担当

けまるや 

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

今回は Windows 8、Windows 8.1 および Windows Server 2012、Windows Server 2012 R2 のサポート ライフサイクルの考え方についてご紹介いたします。 

まずはじめに、Windows 8 と Windows 8.1、Windows Server 2012 と Windows Server 2012 R2 の関係については、以下のようにご認識ください。

-----------

製品としての扱い

----------

・Windows 8.1 / Windows 8はそれぞれ別製品

・Windows Server 2012 R2 / Windows Server 2012 はそれぞれ別製品

----------

サポートライフサイクル

-----------

・Windows 8.1 ⇒サービス パックポリシーと同等
       Windows 8 から Windows 8.1 への移行が “必要”

・Windows Server 2012 R2 ⇒ 個別にサポートライフサイクルが存在

       Windows Server 2012 からWindows Server 2012 R2 への移行は “不要”

それぞれの OS について、以下に詳細をご説明いたします。

- Windows 8、Windows 8.1 について

現在Windows 8 をお使いであれば、Windows 8.1 は無償で Windows Store からダウンロードしアップデートいただけます。

テクノロジ上の分類では、Windows 8.1は、Windows 8 とは異なるプロダクトです。しかし、サービス パックと同等のライフサイクル ポリシーが適用されるため、サポート期限としては、両 OS ともに同じ日 2023 年 1 月 10 日に終了します。

また、Windows 8 は、Windows 8.1 更新プログラムの一般公開後 24 か月以内に Windows 8.1 に移行していただく必要があります。

24 か月経過後も Windows 8 を引き続きお使い頂く事はできますが、サポートは限定されます。 詳細は後述の ※参考1 をご参照ください。

※ 2013年10月24日現在の情報です。

2013 11月07日現在、Windows 8.1 の問い合わせについても問題なく弊社サポート サービスをご利用いただけます。

・Windows 8、Windows 8.1 サポート ライフサイクル

http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=Windows+8&Filter=FilterNO

- Windows Server 2012、Windows Server 2012 R2 について

Windows Server 2012 と Windows Server 2012 R2は、サポート期限やライセンスについて、それぞれの製品毎に個別に存在しております。製品がそれぞれ異なりますので、Windows Server 2012 においては、Windows Server 2012 R2 がリリースされた後も、R2 へ移行いただく事は必須ではありません。

※ 2013年10月24日現在の情報です。

2013 11月07日現在、Windows Server 2012 R2 の問い合わせについても問題なく弊社サポート サービスをご利用いただけます。

・Windows Server 2012、Windows Server 2012 R2 サポート ライフサイクル

http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=Windows+server+2012&Filter=FilterNO

以下のサポート ライフサイクルの例も併せてご参考ください。

※参考 1

・Windows 製品のサポート ライフサイクル について

http://www.microsoft.com/ja-jp/windows/lifecycle/default.aspx

サービスパックサポートポリシー

•サービスパックがリリースされる際、その 1 つ前にリリースされたサービスパックは、製品ファミリー (たとえば、Windows、Office、サーバーまたは開発者ツール) によって異なりますが、12 か月間、または 24 か月間サポートが提供されます。

•サービスパックのサポートが終了した場合は、そのサービスパックに対する新たなセキュリティアップデート、修正プログラム、およびその他の更新は提供されません。後述するような限定的なサポートは提供されます。

•製品のサポート期間が終了した場合、その製品向けのサービスパックのサポートも終了します。製品のサポート期間は、サービスパックのサポートポリシーよりも優先されます。

•サービスパックのサポートスケジュールは、製品ファミリーで共通しています。

•1 つ前にリリースされたサービスパックのサポート期間は、最新のサービスパックのリリース時に発表します。

最新の状態を保ち、最もセキュアなバージョンをお使いいただくためには、サポート対象となっている最新のサービスパックを適用されることを強くお奨めいたします。

サポート対象外のサービスパックをご利用のお客様には、下記の限定的なサポートが提供されます。

1.マイクロソフトサポートからの、break/fix に対する限定的なサポート、もしくはプレミアサポートなどのマネージトサポートオファリングの提供

2.マイクロソフト製品開発リソースを活用するオプションは提供されず、技術的回避策は限定的かもしくはご利用いただけません

3.お問い合わせがさらなるガイダンスの作成、ホットフィックスもしくはセキュリティアップデートを必要とする場合、サポート対象であるサービスパックにアップグレードを求められます

- 参考 2

・Windows 8 から Windows 8.1 にアップデートする

http://windows.microsoft.com/ja-jp/windows-8/update-from-windows-8-tutorial

・Windows Server
2012 R2 Preview のシステム要件とインストール情報

http://technet.microsoft.com/ja-jp/library/dn303418.aspx

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

今回は今月 11 月にリリースされた修正プログラム一覧の中から、クラスターに関連する修正プログラムをご紹介いたします。弊社クラスター製品をご使用の方は、必要に応じて以下の修正プログラムを適用ください。

＝＝＝＝＝＝＝＝＝＝

タイトル: Error message when you try to schedule a shadow copy task in Windows Server 2012

URL: http://support.microsoft.com/kb/2894464

概要:

Windows Server 2012 の環境において、シャドウ コピーのタスクをスケジュールを設定しても、タスクはすぐに作成されません。設定後には以下のエラー メッセージが表示されます。

----------

Failed to create a default schedule for creating shadow copies of volume xx. Error 0x80070102: The wait operation timed out

----------

＝＝＝＝＝＝＝＝＝＝

タイトル: NFS sharing type resources do not come online after the Cluster service fails over a cluster group in Windows Server 2008 R2 SP1

URL: http://support.microsoft.com/kb/2897770

概要:

Windows Server 2008 R2 Service Pack 1 (SP1) の環境において、一つのグループ内に 10 個以上の NFS 共有リソースを作成した場合、リソースはオフラインになります。またリソースのオフラインに伴い、グループのフェールオーバーが行われます。フェールオーバー先のノードにおいても、すべての NFS 共有リソースがオンラインになりません。

イベント ログには以下のエラーが記録されます。

----------

特定のリソースの共有違反がありました。しばらくしてから再試行するか、または管理者に問い合わせてください。

----------

＝＝＝＝＝＝＝＝＝＝

タイトル: Cluster group that has dependent resources does not fail over on a Windows Server 2008 SP2-based computer

タイトル: 依存するリソースを持つクラスター グループが Windows Server 2008 SP2 ベースのコンピューターにフェールオーバーしません。(日本語自動翻訳)

URL: http://support.microsoft.com/kb/2881151

URL: http://support.microsoft.com/kb/2881151/ja(日本語自動翻訳)

概要:

Windows Server 2008 Service Pack 2 の環境において、クラスター グループ内にあるリソースの依存関係に影響し、リソースが正常にオフラインになりません。この状況においては、クラスター グループは実行中のままオフラインになりません。またクラスター グループもフェールオーバーフェールオーバーされません。

＝＝＝＝＝＝＝＝＝＝

タイトル: Clustered virtual machine cannot access LUNs over a Synthetic Fibre Channel after you perform live migration on Windows Server 2012-based Hyper-V hosts

URL: http://support.microsoft.com/kb/2894032

概要:

Windows Server 2012 の環境において、仮想マシンのライブ マイグレーションを実施後、仮想マシンは Synthetic Fibre Channel を介した LUN へのアクセスが出来なくなり、フェールオーバーに失敗します。

詳しい内容につきましては、それぞれの公開情報をご確認ください。

- 補足

また過去にリリースしている修正プログラムの中から、クラスター環境に適用を推奨している修正プログラムについて、弊社エンジニアが記載したブログがございますので、合わせてご覧いただけますと幸いです。

タイトル: Recommended hotfixes and updates for Windows Server 2012-based Failover Clusters

URL:http://support.microsoft.com/kb/2784261

タイトル: Recommended Hotfixes for Windows Server 2012 Failover Clusters

URL:http://blogs.technet.com/b/scottschnoll/archive/2013/06/17/recommended-hotfixes-for-windows-server-2012-failover-clusters.aspx

タイトル: クラスター環境に適用を推奨する修正プログラムについて

URL: http://blogs.technet.com/b/askcorejp/archive/2012/08/16/3514648.aspx

クラスターに修正プログラムを適用する手順についても、上記ブログでご紹介しているので是非ご参考ください。

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

日々のサポート業務の中で、お問い合わせを頂く内容についてご紹介します。

今日は Windows Server 2012 における MSFC(Microsoft Failover Clustering）と SCVMM(System Center Virtual Machine Manager) の関係および新機能についてご紹介します。今までクラスターの管理を MSFC で実施していた方には、是非 SCVMM も併せて活用し、日々の業務を円滑に進めていただければ幸いです。

System Center 2012 Virtual Machine Manager では、今までのSystem Center Virtual Machine Manager 2008 R2 、MSFC の機能では出来なかった、「クラスターからスタンドアロン コンピューターへのバーチャル マシンのライブマイグレーション」や「クラスターからクラスターへのバーチャル マシンのライブ マイグレーション」を実行する事ができます。そのため SCVMM を使用するにあたり以下のメリットがあります。

•柔軟性の向上

新機能によって複数のホストやクラスターにまたがるバーチャル マシンの移動が簡易化されます。 したがって、動的なデータセンターをより簡単に管理できます。

•容易なメンテナンス

ライブ マイグレーションによって、スタンドアロン ホストやクラスター ホストをメンテナンスや移行のためにオフラインにする必要が少なくなり、ダウンタイムを減らすことができます。 移行とメンテナンスを同時に実行できるので、ライブ マイグレーションに必要な時間によっては移行のタイムフレームを短縮できます。 さらに、Hyper-V モビリティの計画プロセスも簡易化されます。

•ハードウェア使用率の向上

インフラストラクチャ全体にわたるバーチャル マシンの配分を最適化できます。 可用性を中断せずにバーチャル マシンと記憶域を余剰能力のあるスタンドアロン サーバーやクラスターに移動できます。 バーチャル マシンを別のホストに移動して、必要のないホストの電源を切断することにより消費電力を節約できます。

•Windows Server 2012 の機能

System Center 2012 SP1 の VMM (Virtual Machine Manager) では、Windows Server 2012 リリースで新しく追加されたフェールオーバー クラスタリング機能を利用できます。 これにはバーチャル マシンを別のクラスター ノードに移行するための新しい API や、ダウンタイムなしでフェールオーバー クラスターとの間でバーチャル マシンを移行できるようにする接続/接続解除機能の改善が含まれます。

- バーチャル マシンのライブ マイグレーションのサポート

次の表は、バーチャル マシンのライブ マイグレーションのサポート マトリックスをまとめたものです。

その他、バーチャル マシン記憶域の移行につきましては、以下の URL をご参考ください。

バーチャル マシンと記憶域の移行の概要:

http://technet.microsoft.com/ja-jp/library/jj628158.aspx

- 補足: SCVMM について

Virtual Machine Manager (VMM) は、仮想化されたデータ センター向けの管理ソリューションです。バーチャル マシンおよびサービスを作成してプライベート クラウドに展開することを目的として、仮想化ホスト、ネットワーク リソースと記憶域リソースを構成および管理する機能が備わっています。

以下参考情報となりますので併せてご参照ください。

<参考情報>

・Virtual Machine Manager:

http://technet.microsoft.com/ja-jp/library/gg610610.aspx

・VMM での Hyper-V ホスト クラスターの作成の概要

http://technet.microsoft.com/ja-jp/library/gg610576.aspx