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

本日は今月リリースされた以下の修正プログラムについてご紹介します。

 文書番号 : 2885209
 Event ID 55 is logged on a Windows 7 SP1 or Windows Server 2008 R2 SP1-based file server
 イベント ID 55 が、Windows 7 SP1 または Windows Server 2008 R2 の SP1 ベースのファイル サーバーに記録されます。(日本語機械翻訳)
 http://support.microsoft.com/kb/2885209
 http://support.microsoft.com/kb/2885209/ja (日本語機械翻訳)

この技術情報の修正プログラムでは、NTFS ファイル システム ドライバー (ntfs.sys) の不具合により、ファイル システム構造に破損が発生し、同時にその破損を検知して、ソース : NTFS、ID: 55 エラーが記録される事象に対応を行っています。

この事象の発生条件として、ファイル システムのアロケーション ユニット サイズ (クラスター サイズ) が 4KB より大きい (4KB 丁度は含みません) という条件があります。

アロケーション ユニット サイズの既定値は多くの場合 4KB ですが、16 TB を超える大容量のボリュームでは 4KB より大きな値が既定値で設定されます。
各ボリューム サイズと既定のアロケーション ユニット サイズは以下の技術情報をご参照ください。

 文書番号 : 140365
 NTFS、FAT、および exFAT のデフォルトのクラスター サイズ
 http://support.microsoft.com/kb/140365/ja

そのため、16 TB を超える大容量のボリュームをご利用の場合 (もしくはアロケーション ユニット サイズを変更して利用している場合) には、2885209 の事象が発生する可能性がありますので、修正プログラムの適用をご検討ください。
なお、本事象は Windows Server 2008 R2 RTM (サービスパックを適用していない環境) でも発生します。その際はまずサービスパック 1 (SP1) を適用の上、上記修正プログラムを適用してください。

なお、すでにファイル システムの破損が発生している場合には、上記修正プログラム適用によるファイル システムの修復効果はありませんので、一度修復モードの Chkdsk を実行する必要があります。
修復モードで実行するには /F オプション、または、/R オプションを指定します。

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

参考 1
------------
現在の各ボリュームのアロケーション ユニット サイズを確認するには fsutil fsinfo ntfsinfo コマンドを利用します。

>fsutil fsinfo ntfsinfo (ドライブ レター):

例) >fsutil fsinfo ntfsinfo E:
 :
クラスターあたりのバイト数              : 4096  << 4KB です。
(英語では Bytes Per Cluster )
:

参考 2
------------
現在各ボリュームにファイル システムの破損が発生しているかは Chkntfs コマンドで確認が可能です。

> Chkntfs (ドライブ レター):

例) > Chkntfs E:

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

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

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

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

参考リンク
---------------------------------
その他のシナリオでも発生する場合については以下のエントリーもご覧ください。

 ソース : NTFS、ID: 55 のイベント
 http://blogs.technet.com/b/askcorejp/archive/2013/03/11/ntfs-id-55.aspx 

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

最近よ��お問い合わせをいただく Windows Vista、Windows 7、Windows Server 2008、Windows Server 2008 R2 の STOP エラー、またハングアップの情報についての公開情報をまとめました。

切り分けとして非常に有効ですので、ハングアップが発生した場合は、まずはご一読頂ければ幸いです。

STOPエラーが発生した場合は、発生したエラーコードと照らし合わせて適用頂く修正プログラムを判断してください。

ハングアップ系の公開情報

タイトル : Windows Server 2008 のシャットダウンが完了しない

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

タイトル : Windows Vista Service Pack 1 or Windows Server 2008 stops
responding (hangs) during startup

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

タイトル : Stress tests may cause a Windows Server 2008 system that has the
Hyper-V role installed to hang

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

タイトル : A computer that is running Windows Vista or Windows Server 2008
stops responding and hangs at the "Applying User Settings" stage of
the logon process

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

タイトル : Windows Vista, Windows Server 2008, Windows 7, or Windows Server
2008 R2 may stop responding at the Welcome screen after you enter the user
credentials to log on to the computer

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

タイトル : An application stops responding when a file has a circular
reference in Windows 7 or Windows Server 2008 R2

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

STOP エラーの公開情報

タイトル : "0x0000007F" Stop error occurs when the connection to
some shared files is lost on a computer that is running Windows Vista, Windows
Server 2008, Windows 7 or Windows Server 2008 R2

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

タイトル : "0x0000007E" or "0x00000050" Stop error when
you create snapshots of a volume in Windows Server 2008 R2 or in Windows 7

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

タイトル : Stop error 0x0000007a occurs on a virtual machine that is running
on a Windows Server 2008 R2-based failover cluster with a cluster shared
volume, and the state of the CSV is switched to redirected access

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

タイトル: A "0x000000B8" Stop error occurs when you try to shut
down or hibernate a computer that is running Windows 7 or Windows Server 2008
R2

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

タイトル: Stop error 0x0000007E occurs when multiple users establish Remote
Desktop Services sessions to a Windows Server 2008 R2-based computer

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

タイトル : "0x0000003B" Stop error in Windows 7 or in Windows
Server 2008 R2

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

タイトル : "0x000000D1 DRIVER_IRQL_NOT_LESS_OR_EQUAL" Stop error
on a Windows 7 SP1 or Windows Server 2008 R2 SP1-based computer

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

タイトル : "0x000000D1 DRIVER_IRQL_NOT_LESS_OR_EQUAL" Stop error
on a Windows 7 SP1 or Windows Server 2008 R2 SP1-based computer

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

タイトル : "0x0000009E" Stop error and disk volumes cannot be
brought online on a Windows Server 2008 R2-based failover cluster

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

タイトル : A Stop Error 0x000000C2 in the Srv2.sys file may occur and SMB
clients cannot obtain data from the SMB 2 server in a Windows 7 or Windows
Server 2008 R2 environment

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

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

こんにちは。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

こんにち��。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 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 プラットフォーム サポートの丸山です。

最近弊社では、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 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 の 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 フェールオーバー クラスター + 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 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 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 プラットフォーム サポートの吉井です。

今日は 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 テクノロジー サポート チームです。

前回 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 対象のモジュールを
最新の状態とするために必要な最小限の更新プログラム リストを
ご紹介させていただきます。

[2014 年 4 月 1 日 追記]

上記以降にリリースされた更新プログラムについて追記いたします。

こんにちは。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 対象のモジュールを
最新の状態とするために必要な最小限の更新プログラム リストを
ご紹介させていただきます。

[2014 年 4 月 1 日 追記]

上記以降にリリースされた更新プログラムについて追記いたします。

こんにちは。 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

*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 プラットフォームサポートの世古です。

今回は 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.       アイコンを右クリックし「スタートにピン留め」をクリックする事で、以下のようにタスクバーにショートカットを配置する事が出来ます。

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

こんにちは。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

こんにちは。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 プラットフォーム サポートの戸田です。

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

複数の Windows が連携して動作するフェールオーバー クラスター環境では、ノード間の相互接続が正常であることが、クラスターの安定動作のために重要です。

フェールオーバー クラスターを構築する場合、冗長化のために少なくとも各ノード毎に 2 つの物理 NIC を用意いただくことを推奨していますが、環境によってさらに物理 NIC が必要となります。

構成により様々な用途でネットワークが使用されるため、結局いくつの NIC が必要になるのかが分からないといった声もいただきます。この記事では、フェールオーバー クラスター環境を計画、構築いただく際に考慮いただきたいネットワーク構成についてお伝えします。

まずは表で簡単にまとめ、それぞれについては以下に説明します。

まずクラスターで使用されるネットワークは以下の 2 種類の役割(a)(b)を持っています。

(a) クラスターノードのみで使用するネットワーク

 プライベート ネットワークとも呼ばれ、ノード間の同期、クラスター通信に利用されます。「フェールオーバー クラスター マネージャー」のネットワークのプロパティで「このネットワークでのクラスター ネットワーク通信を許可する 」が選択されたネットワークです。

(b) クライアント アクセス ポイントで使用するネットワーク

パブリック ネットワークとも呼ばれます。上記に加えクラスター外のホストとの通信を行います。デフォルト ゲートウェイの設定を持ち、ドメイン コントローラーとの通信や、DNS サーバーとの通信で使用されます。「フェールオーバー クラスター マネージャー」のネットワークのプロパティで「このネットワークでのクラスター ネットワーク通信を許可する 」と「クライアントにこのネットワーク経由の接続を許可する」が選択されたネットワークです。このネットワークのみでもクラスターを構成することは可能ですが、クラスター相互接続の冗長化のため、複数のネットワーク経路を用意いただくことを推奨しています。

- 参考資料
  フェールオーバー クラスターのネットワーク設定を変更する
     http://technet.microsoft.com/ja-jp/library/cc725775.aspx

CSV を使用するライブ マイグレーション環境ではさらに以下の用途(c)(d)(e) のネットワークを考慮していただく必要があります。

(c) CSV (Cluster Shared Volumes) へのアクセス (リダイレクト I/O ) のためのネットワーク。

通常 (a) のネットワークが使用されるので、個別に用意する必要はありません。

(d) ライブ マイグレーション用のネットワーク

仮想マシンのライブ マイグレーション処理では、仮想マシンのメモリー情報をこのネットワークを使って転送します。定常的ではないにしろ、相当量のトラフィックが流れることが予想されるため独立したネットワークを用意します。このネットワークの選択は 「フェールオーバー クラスター マネージャー」 から仮想マシンのプロパティを開き、[マイグレーション用ネットワーク] タブで、指定と優先順位の設定ができます。

(e) Hyper-V 仮想マシン(ゲスト OS) 用のネットワーク

ホスト マシン、ゲスト マシンのトラフィックを分けるため  「Hyper-V マネージャー」の「仮想ネットワークマネージャー」 にて 「管理オペレーティングシステムにこのネットワーク アダプターの共有を許可する」 のチェックを外し、仮想マシン専用の 物理 NIC として使用されることを推奨します。

ライブ マイグレーション環境では上記 (a) ～ (d) ( a と c は併用) のネットワーク として、また仮想マシン専用(e)の NIC を加えて 4 つの物理 NIC を用意いただくことを推奨します。

(f)  iSCSI ストレージ用のネットワーク

 iSCSI のストレージをご利用いただく場合には、さらに専用の NIC が必要となります。この 物理 NIC はクラスターでは使用せずネットワークのプロパティで 「このネットワークでのクラスター ネットワーク通信を許可しない」を選択しておきます。

フェールオーバー クラスターは障害検出を以って高可用性を実現するプロダクトです。一時あるいは定常的に流れる大量のトラフィックによってクラスター通信の遅延などが発生しないように考慮いただくことがネットワーク分離の考え方の基となっています。 (f) は iSCSI ストレージ用とご案内していますが、クラスター用途とは直接の関係のない、バックアップやデータ転送などの用途で使用するネットワークも同様の扱いとなります。

なお、この記事でご案内したネットワーク (NIC) の数については、クラスター環境で必ずこうしなければいけないというものではなく、一つの指針としてご理解ください。もし現在運用されているクラスター環境でネットワーク障害が検出されることが多いという場合にはこれら、用途別のネットワークの分離について一度ご確認をいただけると幸いです。

詳細については以下の公開資料がありますので、ご一読いただければと思います。

- 参考資料
  Hyper-V: Live Migration Network Configuration Guide公開
    http://technet.microsoft.com/en-us/library/ff428137(WS.10).aspx

こんにちは。 Windows テクノロジー サポートの江田です。

今回は、 ドメインコントローラーに Windows Server 2012 が存在しない環境において Windows Server 2012 のドメインに参加するサーバー上にてファイル サーバー リソース マネージャーの機能を導入している際に、以下のイベント (ソース:SRMSVC,イベント ID:12339,12344) が 15分程度の間隔で記録される場合の対処方法についてご紹介いたします。

本メッセージ自体は、ドメイン コントローラーと同期した際に Windows Server 2012 に対応したスキーマ定義がないことが原因で記録されます。

対応策としては、以下のいずれかとなります。なお、イベントについては、 ドメイン コントローラーに Windows Server 2012 より追加された機能を保有しているかの確認をし、保有していない旨のイベントになりますので無視していただいても構いません。 

• Windows Server 2012 のドメイン コントローラーを導入していただく
• 現在使用している DC のスキーマのバージョンを Windows Server 2012 にする

なお、スキーマのバージョン アップの手順については、以下の資料をご参照ください。

           Adprep.exe の実行 
           http://technet.microsoft.com/ja-jp/library/dd464018(v=ws.10).aspx
           -> adprep.exe /forestprep
           -> adprep.exe /domainprep

運用や環境に合わせて対策を選択していただければと思います。

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

今回は、Windows 8 / Windows Server 2012 の新機能のひとつ、自動メモリ ダンプについてご紹介いたします。

自動メモリ ダンプは、ページング ファイルのサイズを自動で割り当てる機能と連動します。普段はページング ファイルを小さめに設定し、STOP エラーなどの障害発生時にページング ファイルを物理メモリとほぼ同等のサイズに割り当てなおすことで、次回にSTOP エラーが再発した場合に、正常なダンプ ファイルが出力されるようにするという機能です。出力されるダンプ ファイルの種類はカーネル メモリ ダンプです。

自動メモリ ダンプの機能を発揮するためには、仮想メモリを [すべてのドライブのページング ファイルのサイズを自動的に管理する] や  [システム管理サイズ] に設定している必要があります。つまり、[カスタム サイズ] で任意のサイズに設定している場合は、”自動メモリ ダンプ” に設定していても、従来の ”カーネル メモリ ダンプ” に設定している場合と、あまり差異はないということになります。

従来の OS では、仮想メモリの設定を  [システム管理サイズ] に設定している場合、搭載している物理メモリと同程度のページング ファイルを作るようにしていましたが、物理メモリの大容量化、SSD の普及により、ページング ファイルの省サイズ化もニーズとして求められています。そこで Windows 8 / Windows Server 2012 では、物理メモリよりもページング ファイルのサイズを小さくするように動作が変更されています。

しかし、STOP エラーなどの障害発生時に正常なメモリ ダンプを出力するためには、STOP エラー発生時のメモリの使用状況にもよりますが、ページング ファイルのサイズが小さいと、ダンプ ファイルは完全な形では出力されない場合があります。自動メモリ ダンプは、STOP エラーなどによる障害が発生した際、自動的にページング ファイルのサイズを調整し、物理メモリと同程度まで拡張させることで、次回 STOP エラーが発生すると正常なカーネル メモリ ダンプ ファイルが出力されるように備えます。

4GB (4096MB) の物理メモリを搭載している環境で、ちょっとした検証をしてみましょう。

自動メモリ ダンプを有効にし、仮想メモリはシステム管理サイズに設定します。

1) [現在の割り当て] を確認するとページング ファイルのサイズは 704 MB となっています。

2) STOP エラーを発生させます。

3) STOP エラー発生後のページング ファイルを確認すると、4096 MB に拡張されました。

STOP エラーによって再起動された場合、レジストリ キーに “LastCrashTime” という項目を追加し、障害発生時のタイム スタンプを記録します。LastCrashTime が記録されたタイム スタンプから 4 週間、STOP エラーが発生しなければ、ページ ファイルのサイズは自動的に元の拡張前のサイズに縮小させます。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

  名前: LastCrashTime

  種類: REG_DWORD

なお、直ちに、ページ ファイルのサイズを拡張前のサイズに戻す必要がある場合は、レジストリから “LastCrashTime” を手動で削除し、システムの再起動を行うと拡張前のサイズに戻すことも可能です。

現在使っているシステムでは、どの種類のメモリ ダンプを選べば良いのかという疑問も出てくるかと思いますが、その点については仮想メモリのサイズをどうしたいのか、という部分と密接に関係しているので、また別の機会に改めてご紹介したいと思います。

こんにちは。Windows プラットフォーム サポートの加藤です。
本日は Server サービス異常終了時に、クラスターサービスに与える影響と回避策についてお伝えします。

・現象

CSV を使用したHyper-V クラスター環境で、突然 CSV のコーディネーター ノード以外のノードから CSV にアクセスできなくなり、仮想マシンが停止してしまうお問い合わせを多くいただいています。

また、ファイルサーバーをクラスター化している環境では、ファイル サーバー リソースが障害となりフェールオーバーするお問い合わせもいただいております。

これらの現象が発生した際、以下の Server サービスの予期せぬ停止イベントが記録されていることがあります。

 システム ログ
------------------
エラー,Service Control Manager,7031,,Server サービスは予期せぬ原因により終了しました。このサービスの終了は 1 回目です。次の修正操作が 60000 ミリ秒以内に実行されます: サービスの再開。
------------------

また、上記の Server サービスの予期せぬ停止イベント以外にも多数のサービスが停止したイベントが記録されます。
同時間帯には、アプリケーション ログに以下のようなエラーも記録されます。

アプリケーション ログ
例:
------------------
エラー,Application Error,1000,(100),"障害が発生しているアプリケーション名: svchost.exe_ProfSvc、バージョン: 6.1.7600.16385、タイム スタンプ: 0x4a5bc3c1
障害が発生しているモジュール名: wmiprvsd.dll、バージョン: 6.1.7601.17514、タイム スタンプ: 0x4ce7ca79
------------------

上記のアプリケーション エラーは、svchost.exe が、何らかの原因でクラッシュしたことを示しています。
svchost.exe は、OS内の各種サービスをホストする汎用的なプロセスで、ひとつの svchost.exe で複数のサービスを管理しています。
あるサービスの処理において異常が発生すると、svchost.exe 自体がクラッシュし、当該 svchost.exe によって起動されたサービスはすべて停止します。
そのため、このクラッシュが Server サービス以外のサービスの問題により発生しても、Server サービスも影響を受けてしまいます。

Server サービスが停止した場合には、CSV を正常に利用することができません。
その理由は、CSV のコーディネーターノード以外のノードから、CSV にアクセスする際には、コーディネーターノードとの SMB による通信が必要なためです。
Server サービスは、SMB 通信を提供するサービスであり、このサービスが停止すると、非コーディネーターノードから、CSV へのアクセスが一切できなくなります。

また、同様にファイルサーバー リソースも、Server サービスが停止するとアクセスができなくなり、クラスターの正常性チェックで異常が検出され、フェールオーバーが発生します。

根本原因を解決するには、svchost.exe がクラッシュした原因を追究する必要がありますが、原因が特定できるまでの間に現象が再発してしまうと、再び仮想マシンが停止し業務に影響が発生します。
そこで、他のサービスの問題で svchost.exe がクラッシュした際に CSV への影響を抑えるために、プロセスを分離する回避策があります。

・ホストプロセスの分離
前述のように、svchost.exe は複数のサービスを管理しています。
Server サービス以外のサービスの問題が、Server サービスに影響を与えないようにするには、ひとつの svchost.exe で Server サービスを管理するように構成を変更します。
これにより、Server サービスは、他のサービスの svchost.exe とは独立するため、他のサービスの問題に起因する svchost.exe のクラッシュの影響を受けなくなります。
なお、分離を実施することで svchost.exe プロセスがひとつ増えますが、もともと OS には複数の svchost.exe が存在しており、増えることでシステムに影響を与えることはありません。

- 手順
Server (LanmanServer) サービスにおけるホストプロセスの分離について

---------------------------------------------------------
(1) コマンド プロンプトから "Tasklist /svc" を実行し、Server (LanmanServer) サービスが含まれている svchost.exe を確認します。

実行例：
C:\>Tasklist /svc

イメージ名                     PID サービス
========================= ======== ============================================
System Idle Process              0 N/A
System                          4 N/A
：
：
svchost.exe                   1020 AeLookupSvc, Appinfo, AppMgmt, BDESVC,
                                   BITS, CertPropSvc, EapHost, gpsvc, hkmsvc,
                                   IKEEXT, iphlpsvc, LanmanServer, MMCSS,
                                   ProfSvc, Schedule, SENS, ShellHWDetection,
                                   Themes, wuauserv
：
：

(2) コマンドプロンプトから "sc config LanmanServer type= own" を実行します。

実行例：
C:\>sc config LanmanServer type= own
[SC] ChangeServiceConfig SUCCESS

(3) OS をリブートします。

(4) コマンドプロンプトから "Tasklist /svc" を実行し、LanmanServer サービスが他多数のサービスと分離して、単独のホストプロセスにロードされたことを確認します。

実行例：
Tasklist /svc

イメージ名                     PID サービス
========================= ======== ============================================
System Idle Process              0 N/A
System                          4 N/A
：
：
svchost.exe                   3136 LanmanServer
：
：
：

以上で分離作業は完了です。

こんにちは。日本マイクロソフトの永野です。

弊社クラスター製品には、リソースの操作時にそのリソースの応答を待ち続けることで、

クラスターの動作が停止することを防ぐため、設定されたタイムアウト期間で応答が

得られなかった場合には、デッドロックのような状態が発生したと判断し、リソースを

再起動する機能が備えられています。

タイムアウト期間は、各リソースの以下のプロパティに格納されています。

DeadlockTimeout : IsAlive や LooksAlive など一般的な操作のタイムアウトに利用

PendingTimeout : オンラインやオフライン時の Pending 状態のタイムアウトに利用

このタイムアウトによるリソース再起動に伴って、Windows Server 2003 では resrcmon.exe が、

Windows Server 2008, Windows Server 2008 R2 では rhs.exe が再起動し、

Windows Server 2008 の場合には、イベント ログに

Microsoft-Windows-FailoverClustering ID:1230 のエラーが記録されます。

Event ID 1230 — Cluster Service Startup

http://technet.microsoft.com/en-us/library/cc773436%28v=ws.10%29.aspx

その際、どういった処理で止まっていたのか確認するため、プロセス ダンプから

調査することが有効ですが、Windows Server 2008 にはプロセス ダンプを出力する

機能がありませんでした。

※ Windows Server 2003 と Windows Server 2008 R2 にはプロセス ダンプを出力する機能があります

2013 年 1 月に Windows Server 2008 でもデッドロック発生時にプロセス ダンプを

出力する機能が実装された rhs.exe が以下の技術情報で公開されました。

Hotfix enables a dump file to be generated when the Rhs.exe process detects a deadlock condition in Windows Server 2008

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

こちらを適用していただくことで、Windows Server 2008 R2 と同様に

Windows Error Reporting (WER) の機能を利用して以下のパスに

プロセス ダンプが作成されます。

 %LOCALAPPDATA%\Microsoft\Windows\WER\ReportQueue

もし、Microsoft-Windows-FailoverClustering ID:1230 が記録される問題が

発生しているようであれば、前述の技術情報で公開されているモジュールを

適用していただき、プロセス ダンプを採取することをご検討ください。

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

今回は、CD / DVD メディアの書き込み方式の違いと書き込み速度について記載します。

CD / DVD メディアにデータを書き込む方法としては、「ライブ ファイル システム形式」と「マスタ形式」があります。それぞれの特徴は、以下の通りです。

ライブ ファイル システム形式

フロッピー ディスクや USB フラッシュ ドライブと同じように、選択したファイルを即座にコピーできます。書き込んだあと、新たにファイルをコピーすることも可能です。

マスタ形式

書き込み対象のファイルは、一度、ローカル ディスクの一時領域へコピーされます。すべての書き込み対象ファイルの準備ができた時点で、書き込みを実施しますが、選択されたファイルは、一度に書き込みます。このため、書き込み後、ファイルを追加することはできません。

各形式については、以下の公開情報もございますので、参考にして頂ければと思います。

CD/DVD 形式の選択

http://windows.microsoft.com/ja-JP/windows-vista/Which-CD-or-DVD-format-should-I-use

ディスクの書き込み : よく寄せられる質問

http://windows.microsoft.com/ja-JP/windows-vista/Disc-burning-frequently-asked-questions

各形式には、このような特徴がありますが、書き込み時の処理内容も異なります。

ライブ ファイル システム形式では、ファイルの追記が行えるため、ファイル書き込みの際にファイルの情報を管理している領域を更新しながら書き込みを行います。つまり、1 ファイル追加するごとに、ファイルのデータと管理領域の 2 つに対する書き込みが発生します。

一方、マスタ形式では、ファイルの追記ができないため、ファイルの管理情報を一度構成すれば、更新する必要がありません。このため、複数のファイルを書き込む場合でも管理領域の書き込みは 1 度だけとなります。

このような書き込み処理の違いがあることから、両書き込み方式においてデータの書き込みにかかる所要時間が異なる結果となります。

例えば、ライブ ファイル システム形式とマスタ形式で、同じファイル数のデータを一度に書き込む場合、上記の書き込み処理の違いから、マスタ形式で書き込む方が早くなります。大量のファイルをライブ ファイル システム形式で書き込む場合、書き込みの所要時間が極端に長くなりますので、ご使用状況によって適切な形式を選択して頂ければと思います。