こんにちは。
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 が割り当てられることを確認しております。
下記資料はハードウェア開発者向けの資料ですが、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 Printershttp://support.microsoft.com/kb/2015694
まだまだ暑い日が続きます。おからだにはお気を付けてお過ごしください。
Windows プラットフォーム サポート担当けまるや
こんにちは。 Windows テクノロジー サポートの田辺です。
システムの管理を行っていると必ずと言って良い程直面するのが、システムのリソース不足だと思います。
システム リソースって？と聞かれるとまず思いつくのが、物理メモリになるかと思いますが、システムで使用しているリソースは、実は物理的に搭載しているメモリだけではありません。
そこで今回はシステム リソースの中からも、デバイスの開発者やサポート業務等に従事している方以外にはあまり知られていないような、ページ プールや 非ページ プールといったリソースをピックアップして紹介させていただきたいと思います。
ページ プールと非ページ プールについて
一言で言うと、ページ アウトしないプール領域とページ アウトする事が出来るプール領域という事になりますが、言葉だけだとさっぱり分かりませんね。
そこで漠然とですが説明しますと、、
- ページ プール
ページ プールとは、カーネル モードで動作するドライバによって確保される仮想メモリ空間で、OS コンポーネントやアプリケーションにより利用される。
ページ プールはページング ファイルへの書き出し (ページ アウト) を行うことが可能。
ページ アウトが可能なため、確保されているページ プールが全て物理メモリ上に存在しているわけでは無い。
- 非ページプール
ページ プールとは異なり、ページ アウトが行われない領域。
となります。
ページ プール、非ページ プールの用途は多岐に渡りますが、実際にプール領域を比較的多く使用するモジュールとしては、OS モジュールのほか、I/O を処理するドライバや、ウイルス対策ソフト等に含まれるフィルタ ドライバが一般的に知られています。
そして、これらの領域は共有されているために、椅子取りゲームと同じで特定のフィルタ ドライバ等で多く確保されてしまうと、他のフィルタ ドライバで使う事ができなくなって、様々な問題が発生する可能性があります。
これらの領域が枯渇していきますと、有名なところではイベント ログでは、srv : 2019 や srv : 2020 といったイベントが記録されたり、ファイル共有にアクセスできなくなったり、システムがハングアップしてみたり etc... といろいろと不都合な現象が発生してきます。
さて、そこで気になるのがこれって最大でどのくらい使えるの？という事ですが、実は OS が 32-bit の環境と64-bit の環境では大きく違ってきます。
32-bit
64-bit
非ページ
256 MB (/3GB 有効時は 128MB)
128 GB
ページ
491.875 MB (Windows 2000, XP)
650 MB (Windows Server 2003)
※ 実際には上記を最大値として、物理メモリ サイズやそのシステムにインストールされているコンポーネントなど様々な要素によって決定されます (詳しい確認方法は続編で)。
ページ プール、非ページ プールの枯渇でお悩みの方がいれば、恒久的な対策としては 64-bit のシステムを導入する事が必要だという事にお気づきになるかと思います。
実は Windows Vista および Windows Server 2008 以降の Windows についてはまた異なるのですがそれはまたおいおいご紹介いたします。
32-bit のシステムが現役で、64-bit のシステムや Windows Server 2008 にはすぐに移行できない！
というのが現実ではあると思いますので、前置きが長くなりましたが、ここではこの 2つのリソースの監視方法について、紹介をさせていただきたいと思います。
何で見るか
ページ プールや 非ページ プールを監視する場合には、一般的にはパフォーマンス モニタを使います。
何を見れば良いか
パフォーマンス モニタを使用する場合には、以下のカウンタを確認します。
Memory\Pool NonPaged Bytes :
非ページ プールのサイズ (バイト単位) を測定します。
Memory\Pool Paged Bytes :
ページ プールのサイズ (バイト単位) を測定します。
どう見れば良いか
正常な状態からこれらの値を監視する事で、システムの平均的な値が確認できますので、定期的に監視をして健常性を確認する事をお勧めします。
パフォーマンス状況からは、異常の可能性が高いと判断できる状況としては、以下の二つがあげられます。
・リーク (長期的な上昇傾向)
・スパイク (一時的な高負荷)
定期的に上記カウンタ値を採取いただいて、徐々に増加を続けているような場合には、そのシステムではメモリ リークが発生している可能性があります。
逆に普段増加の傾向が見られないのに、あるタイミングで急増しているような場合には、その瞬間何らかのタスクの影響で瞬間的な負荷によりシステムの健常性が保たれなくなっている可能性があります。
どう対応すれば良いか
一時的な負荷の場合には、そのタイミングで登録しているタスクを確認したり、管理ツールで行われる処理やウイルス対策ソフトでスキャンの動作が行われていないか等を確認する事で原因が追求できる場合があります。
ドライバを更新した後からパフォーマンス モニタが正常時と比べて高い値を推移するようになった！
新しく管理用のツールをインストールした後から急にシステム リソース不足のエラーが多発するようになった！
といったような場合には、まずは最新版のドライバへの更新やアンインストール、更新後であればロールバックして現象が継続するかの切り分けをすることをお勧めします。
これは動作が変更されている、もしくは既知の障害が修正されている事を期待しての対策ではありますが、初動調査としては非常に有効な切り分けではありますので、是非問題がありましたら確認してみてください。
現象が収まった場合には、管理用ツールや更新したフィルタ ドライバが影響していると判断する事が出来ますので、モジュールの提供元へご確認いただく事で原因が判明する場合があります。
パフォーマンス モニタだけでは特定できない場合は？
ここまででご紹介しましたように、一時的な負荷や現象発生時に行われているタスクがある程度特定できるような場合は良いのですが、まったく想像もできない事が多々あります。
そのような場合には、ページ プールや非ページ プールをだれが一番多く確保しているのかを確認する必要があります。
残念ながらパフォーマンス モニタではそこまでは確認できませんので、第 2 回以降では確認方法も含めてより詳細な調査方法についてをご紹介させていただきたいと思います。
~ 第 2 回 へつづく ~
- リソース不足について - 第 1 回（今回）
- リソース不足について - 第 2 回
- リソース不足について - 第 3 回
こんにちは。Windows プラットフォーム サポートの北原です。最近、PC からスマート フォンへのデータの書き出しを禁止したいというお問い合わせを多くいただいております。以前の記事で、グループ ポリシーを用いたデバイスのアクセス制御をご紹介しましたが、今回は、その中でも主にスマート フォンが使用しているWindows Portable Device (WPD) デバイスへの制限について取り上げたいと思います。グループ ポリシーを用いたデバイスのアクセス制御についてhttp://blogs.technet.com/b/askcorejp/archive/2014/04/28/3516088.aspx================WPD の概要================WPDとは、Windows Vista 以降の OS に標準的に備わっている、携帯電話、デジタル カメラ、音楽プレーヤーのようなポータブル デバイスとの通信手段を提供するドライバ ベースのテクノロジーです。WPD は API を有しており、デバイスの状態を調べたり、デバイスを制御する (写真を撮る、メッセージを送るなど) アプリケーションを開発することができます。なお、Windows XP の場合、別途 Windows Media Player 10 または 11 をインストールする必要があります。スマート フォンや従来の携帯電話を USB で PC につないでファイルの転送をする際、通常、「MTP モード」や「PTP モード」など、事前にモードの選択をする必要があります。この MTP や PTP というのは WPD が使用している通信手段のことで、現在、WPD が主に使用しているものは以下の 3 つとなります。
(参考情報) WPD Drivershttp://msdn.microsoft.com/en-us/library/windows/hardware/ff597868.aspxこの記事では Windows Vista 以降の OS で使用可能な PTP/MTP による情報の持ち出しを制限するグループ ポリシーをご紹介します。
補足情報---------------MSC は USB メモリや USB ハード ディスクなどの大容量記憶デバイスを PC に接続して、エクスプローラー上でファイルのコピーなどをする際に使われるファイル転送技術です。一部のスマートフォンには、MTP/PTP のモード以外に、「ファイル転送モード」などの名前でMSC によるファイルの転送を可能にしているものもあります。この MSC のモードで PC に接続した際、マウントされたドライブを右クリックして、[ポータブル デバイスとして開く] を選ぶと、WPD を介した MSC による通信ができるものがあり、これが WPD における 3 つ目の通信手段となります。
この WPD を介した MSC の制限には、従来の USB メモリのデバイス制御と同じグループ ポリシーを使用します。例えばファイルの読み書きを制限したい場合は、以下のグループ ポリシーを使います。- [コンピューターの構成] - [管理用テンプレート] - [システム] - [リムーバブル記憶域へのアクセス] - [リムーバブル ディスク: 読み取りアクセス権の拒否] および - [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 有効===============PTP/MTP の制限方法について===============グループ ポリシーを用いて PTP/MTP による情報の持ち出しを制限する方法は 3 種類あります。これらは Windows Vista 以降の OS で使用可能です。
セキュリティ的な堅牢さの面では (1) が最も弱く、(3) が最も強いのですが、それに比例して、運用上の制限や煩雑さが増します。以下にそれぞれの特徴を紹介します。
(1) PTP/MTP による読み書きを制限する方法
接続したデバイスに対するフォルダ / ファイルの読み書きを制限するものです。この方法は、ファイルの読み取りだけ、またはファイルの書き出しだけ、特定のユーザーだけなど、柔軟な設定が可能で、最初に一度設定をすると運用後に設定を変える必要があまり無いため、運用が容易です。 その反面、この設定をしていたとしても、PC にインストールされたスマート フォン専用のアプリケーションによってデータの書き込みを行える場合があります。これは独自方法 (PTP/MTP 以外) によってファイルの転送を実装しているためです。これを回避するには、PC へのアプリケーションのインストールを制限するか、後述するWPD デバイスのインストールそのものを制限する方法を実施する必要があります。
(2) WPD デバイスのインストールを制限する方法
デバイスを PC に接続した際の WPD デバイスのドライバーのインストールを制限するものです。ドライバーのインストール自体が制限されているため、WPD デバイスは全く使用することができなくなります。なお、運用が煩雑になってしまいますが、特定メーカーの一部モデルのみインストールを禁止する設定も可能です。
その反面、スマート フォンの一部には、WPD デバイスとしてではなく、他のデバイスとして認識されるものが存在し、WPD デバイスのインストール制限だけでは、デバイスが使用できてしまう場合もあります。これを回避するには、後述するホワイト リストを使用して制限する方法を実施する必要があります。
(3) ホワイト リストによるデバイスのインストールを制限する方法
PC への接続が許可されているデバイスのリストをあらかじめ登録し、それ以外の全てのデバイスのインストールを禁止するというものです。許可されたデバイスのみインストールが行われるため、WPD デバイスはもちろんのこと、未知のデバイスにも対応できます。ソフトウェア レベルで最も堅牢な対策をしたい場合は、この方法が推奨されます。なお、許可リストには、特定の種類のデバイス、または特定のモデルのデバイスといった単位で設定が可能です。
その反面、許可対象のデバイスが増えるにつれ定義内容も増え、運用が煩雑になることがあります。また、デバイス検知時にインストールを制限するという性質上、既にインストール済みのデバイスについては、制限を行うことができません。このため、対象の PC の不要なデバイスをあらかじめ削除しておくなどの対処が必要です。
なお、参考情報となりますが、以下の記事に現在 PC に接続されていない WPD デバイスを devcon.exe で削除するサンプル スクリプトが記載されております。これをベースにお好みのスクリプトを作成いただけたら幸いです。
ハードウェア デバイスのトラブルシューティングについてhttp://blogs.technet.com/b/askcorejp/archive/2014/07/03/3634044.aspx
次の項では、それぞれのグループ ポリシーの実際の設定方法についてご紹介します。
===============設定方法===============前項で述べた 3 種類の方法について、それぞれ手順を説明していきます。
以下のグループ ポリシーにより設定します。 - [コンピューターの構成] - [管理用テンプレート] - [システム] - [リムーバブル記憶域へのアクセス] - [WPD デバイス: 読み取りアクセス権の拒否] および - [WPD デバイス: 書き込みアクセス権の拒否] 設定値: 有効
補足情報---------------特定のユーザーだけ読み書きを制限したい場合は、以下のグループ ポリシーを代わりに使用します。
- [ユーザーの構成] - [管理用テンプレート] - [システム] - [リムーバブル記憶域へのアクセス] - [WPD デバイス: 読み取りアクセス権の拒否] および - [WPD デバイス: 書き込みアクセス権の拒否] 設定値: 有効
以下のグループ ポリシーにより設定します。 - [コンピューターの構成] - [管理用テンプレート] - [システム] - [デバイスのインストール] - [デバイスのインストールの制限] - [これらのデバイス セットアップ クラスと一致するドライバーを 使用したデバイスのインストールを禁止する] 設定値: 有効 デバイス セットアップ クラス: {eec5ad98-8080-425f-922a-dabf3de3f69a} 既にインストール済みの一致するデバイスにも適用されます。: オン 設定したデバイス セットアップ クラス {eec5ad98-8080-425f-922a-dabf3de3f69a} は、WPD デバイスを意味します。以下の文書にデバイス セットアップ クラスの一覧があります。 (参考情報) System-Defined Device Setup Classes Available to Vendorshttp://msdn.microsoft.com/en-us/library/ff553426(VS.85).aspx [既にインストール済みの一致するデバイスにも適用されます。] は Windows 7 以降の機能ですが、これにチェックを入れると、ポリシー適用以前に接続したことのある WPD デバイスに対しても制限をかけることができます。
補足情報---------------特定メーカーの一部モデルのみインストールを禁止したい場合は、以下のグループ ポリシーを代わりに使用します。
- [コンピューターの構成] - [管理用テンプレート] - [システム] - [デバイスのインストール] - [デバイスのインストールの制限] - [これらのデバイス セットアップ クラスと一致するドライバーを 使用したデバイスのインストールを禁止する] 設定値: 有効 デバイス セットアップ クラス: 禁止したいデバイス セットアップ クラスを列挙 既にインストール済みの一致するデバイスにも適用されます。: オン
禁止リストに登録する値については、以下のブログ記事で述べられています。 グループ ポリシーを用いたデバイスのアクセス制御についてhttp://blogs.technet.com/b/askcorejp/archive/2014/04/28/3516088.aspx
以下の 3 つのグループ ポリシーを併用することにより設定が可能です。 - [コンピューターの構成] - [管理用テンプレート] - [システム] - [デバイスのインストール] - [デバイスのインストールの制限] - [他のポリシー設定で記述されていないデバイスのインストールを禁止する] 設定値: 有効 - [コンピューターの構成] - [管理用テンプレート] - [システム] - [デバイスのインストール] - [デバイスのインストールの制限] - [これらのデバイス セットアップ クラスと一致するドライバーを 使用したデバイスのインストールを許可する] 設定値: 有効 デバイス セットアップ クラス: 許可したいデバイス セットアップ クラスを列挙
- [コンピューターの構成] - [管理用テンプレート] - [システム] - [デバイスのインストール] - [デバイスのインストールの制限] - [これらのデバイス ID と一致するデバイスのインストールを許可する] 設定値: 有効 デバイス ID: 許可したいデバイス ID を列挙
なお、許可リストに登録する値については、以下のブログ記事で述べられています。 グループ ポリシーを用いたデバイスのアクセス制御についてhttp://blogs.technet.com/b/askcorejp/archive/2014/04/28/3516088.aspx
注意---------------ストレージ デバイスに限らず、すべてのデバイスが対象となります。このため、USB マウスやキーボードを使用する場合は、許可リストにマウスやキーボードも含めておくことをお勧めします。
===============終わりに===============以上の 3 つの選択肢から、システムのセキュリティ レベルや運用のルールにあったものをご検討いただけたら幸いです。
スマート フォンへの情報の書き出しを完全に防ぐためには、上記のソフトウェア側の対応だけではなく、USB の接続口をふさいだり、サーバー室にスマート フォンを持ち込ませないなどの物理的なセキュリティ対策もあわせて実施されることを強くお勧めします。 今後もデバイス制御に関して、随時ブログで情報をご提供してまいります。
*1 2013/8/27 Windows Server 2008 以降の動作についての補足を追記しました。
こんにちは。Windows プラットフォーム サポートの戸田です。
日々のサポート業務の中で、よくお問い合わせを頂く内容についてご紹介します。
今回は MSCS や WSFC でときどきお問い合わせを頂く「ハートビート」についての記事となります。新旧クラスター関連の記事で使用されている 「ハートビート (Heart beat)」 という表現について、この場を借りて一旦整理したいと思います｡また、ハートビートに関する設定値についてもご紹介します。
まず、一般的にコンピューター用語のハートビートとは分散コンピューティングにおいて相手コンピュータの生存確認を行うための仕組みです。フェールオーバー クラスターの用語では、ハートビート ネットワークとハートビート パケットがあります。混同しやすいところがありますのでまずは簡単に違いを説明します。
なお、この文書内で使用するプライベート ネットワーク、パブリック ネットワークという表現は、それぞれ以下のイメージを指しています。
ハートビート ネットワークについて
MSCS においてノードの正常性確認のための専用ネットワークを指す用語です。
クラスターを構成するノードでは随時ステータスの同期を行っており、もし同期に失敗するノードが見つかった場合には、そのノードはクラスターから切り離されます(切り離されたノードはクラスター サービスの再起動が行われ、あらためてクラスターに参加を試みます)。この同期処理のために用意する専用のプライベート ネットワークのことをハートビート ネットワークと呼びます。このハートビート ネットワークはクラスターの安定動作のために非常に重要視されており、固有の設定が必要とされています。詳細については以下の KB をご一読ください。
クラスター サーバーでのプライベート "ハートビート" の推奨構成http://support.microsoft.com/kb/258750/ja (WSFC 環境ではこの KB に記載されたハートビート固有の設定は行わない様にしてください。)
このハートビート ネットワークの推奨設定は Windows Serrver 2003 MSCS までは必要でしたが Windows Server 2008 WSFC 以降ではこの特別なネットワーク設定を行う必要がなくなりました。もちろん Windows Server 2008 WSFC でもこの同期処理が重要である点は同じですので、ノード間で相互接続が可能なネットワークは必要です (ノード間の相互ネットワークは単一障害点を避けるため、複数の経路を用意頂くことを強く推奨しています)。しかし、MSCS からのデザイン変更によって、「(特別な設定を持つ) ハートビート ネットワーク」を用意する必要がなくなったため、他のクラスター ネットワークとの設定差がなくなり、冗長性を高く保つことができるようになっています。
ハートビート パケットについて
ノード間を結ぶ相互ネットワークが疎通可能であるかどうかを確認するために定期的に送受信を行うパケットのことをハートビート パケットまたは単にハートビートと呼びます。ハートビートは即時応答性を重要視するため UDP プロトコルが使用され、クラスター サービスとして予約されたポート 3343 を使用し、クラスターで使用可能なすべてのネットワーク毎に送受信が行われます。
ハートビート パケットの送受信の間隔は以下のとおりです。
補足 Windows NT Server をベースにした MSCS では内部通信専用のプライベート ネットワークでのみ、ハートビート パケットの送受信が行われていました。そのため相手ノードの生存確認のためのネットワークとして、言葉通り「ハートビート ネットワーク」の意味合いが強いものでした。Windows 2000 Advanced Server 以降の MSCS ではネットワーク毎の疎通確認を目的として、クラスターで使用するネットワーク全てにおいて、ハートビート パケットの送受信が行われるようにデザインが変更されています。
定期的に送受信が行われるハートビートが一定の数(時間)応答が無い場合に、クラスターはハートビートの遅延、または切断として、そのネットワーク上でノード間の疎通に問題があることを認識します｡しかし、ノード間の疎通に失敗することがわかっても、送受信相手からの応答がないことがわかるのみで、障害発生箇所が途中のネットワーク経路なのか、相手ノードの問題なのかを確認することができません。そのため、クラスターはパブリック ネットワークでこのような状況が検知された場合にはさらに障害箇所の特定の為に、「外部ホスト」に対して、疎通確認を行い、障害箇所の特定を試みます。この「外部ホスト」とは各ノード共通でアクセス可能なネットワーク上の "第三者" のコンピュータで、デフォルト ゲートウェイなどです。疎通確認は ping を実行し、ICMP 応答の有無を以て障害箇所を探します。
この動作は、簡単にまとめると以下のような流れになります。
この動作は Windows Server 2000 を対象とした KB242600 にも詳細が説明されていますが、基本的な動作は Windows Server 2008 WSFC でも同様となります。
2 ノードのサーバー クラスタにおけるネットワーク障害の検出と回復http://support.microsoft.com/kb/242600/ja
*1Windows Server 2003 MSCS と Windows Server 2008 WSFC との動作の違いについて以下のBlogが公開されています。
2 ノードのサーバー クラスタにおけるネットワーク障害の検出とフェールオーバー動作についてhttp://blogs.technet.com/b/askcorejp/archive/2013/06/21/3580380.aspx
なお、ネットワーク ケーブルの切断 (リンク ダウンの検出) が行われた場合には、上記の様な障害箇所の特定を行うまでもなく、クラスターはネットワーク インターフェースの障害としてこれを検知します。この場合にはどのノードの、どのネットワーク インターフェースの問題であるかは即時にわかるため、関連づけられた IP アドレス リソースは失敗のステータスからフェールオーバーの動作となります。またこの様なパブリック ネットワークの状態変化もクラスター内で同期が行われ、各ノードでステータスを共有します。ここでもし、他に正常な相互接続ネットワークが存在しない場合にはこの同期が失敗するため、前述の通り(同期ができない)クラスター サービスが再起動します。
ハートビートが遅延してしまう場合には・・・
ご利用のクラスター環境でこのようなハートビートの失敗が発生する様な場合にはネットワーク障害の有無についての調査を検討してみてください。ご利用のネットワークで障害が発生していた場合にはその対処を優先すべきですが、負荷の高いネットワークであったり、 WAN 環境などでパケット遅延が発生しうる可能性がある場合、Windows Server 2008 WSFC 以降ではハートビートの間隔や、障害検知までのしきい値を変更することができます。
WSFC 環境のハートビートの既定の設定は以下となります。
ハートビート間隔 ： 1 秒切断検知までのしきい値 ： 5 回
1 秒間隔にハートビート パケットを送付し、このパケットが連続して 5 回失敗するとネットワークが切断されたと判断し、「パーティション分割」の状態となります。ネットワークが不安定な環境では、上記ハートビートの設定を 1 秒間隔で 5 回ではなく、2 秒間隔で 10 回まで、などに変更する事によってこのネットワークの問題に対応できる場合があります。
この設定値は、以下のクラスター プロパティ値として管理されています。
値の変更は cluster.exe コマンドで行うことができます。コマンド例をご紹介しますので状況に応じてお試し下さい。
この設定は 1 台のノードで実行することによりクラスター全体に即時に反映されます。
また、Windows Server 2003 MSCS では 1.2 秒毎のハートビート間隔は変更できませんが、SP1 以降ではハートビート遅延、切断の検知に関するしきい値を変更出来る様になっています。
An update is available that adds a file share witness feature and a configurable cluster heartbeats feature to Windows Server 2003 Service Pack 1-based server clusters http://support.microsoft.com/kb/921181/en-us
MSCS では 3 回のハートビートを受信しなかった場合にネットワークの切断が検出(イベント ID 1123 が記録) され、6 回を超えて受信しなかった場合には相手ノードとの切断と検出されます。これらの値はそれぞれプロパティ値 HeartBeatLostInterfaceTicks、HeartBeatLostNodeTicks で変更が可能で、以下の cluster.exe コマンドで変更を行うことができます。
cluster /priv HeartBeatLostInterfaceTicks=<回数>cluster /priv HeartBeatLostNodeTicks=<回数>
MSCS では値の反映にはクラスター サービスの再起動が必要です。これらの詳細については、以下の公開情報をご確認ください。
Windows 2000 ベースおよび Windows Server 2003 ベースのサーバー クラスタにおけるイベント ID 1123 とイベント ID 1122 のログの概要http://support.microsoft.com/kb/892422/ja
ご利用頂いているクラスター環境でネットワークが安定しない等の問題をお持ちの場合には、これらハートビートに関する設定変更についてもご検討をいただければと思います。
また、ネットワーク経路に問題が無い場合にも疎通が不安定となる事象などもありますので、以下も併せてご確認をいただければと思います。
クラスタのネットワークが不安定になる?http://blogs.technet.com/b/askcorejp/archive/2010/06/16/3338445.aspx
こんにちは。Windows プラットフォーム サポートの世古です。
日々のサポート業務の中で、よくお問い合わせをいただくメモリ ダンプ ファイルについてご紹介いたします。
画面が固まって動かない等の問題（ブルースクリーンやフリーズ等）が発生した場合、マイクロソフトで調査を行う為にメモリ ダンプ ファイルの採取を依頼する場合があります。今回はそのファイルの詳細と採取方法についてご説明いたします。
(1) メモリ ダンプとは
====================================
メモリ ダンプ ファイルは、システムのある瞬間の物理メモリの情報をファイルとして出力させたものです。OSが異常終了した際に、原因を調査する為にメモリ ダンプは役立ちます。システムの設定に依存しますが、異常終了（ブルースクリーン BSOD）が発生した際にメモリ ダンプ ファイルが作成されます。
具体的には以下の様な画面（ブルースクリーン BSOD）になった際にメモリ ダンプ ファイルが作成されます。
(2) メモリ ダンプの種類
メモリ ダンプには以下 3 つの種類がございます。
完全メモリ ダンプではすべての物理メモリの内容を出力でき、より詳細な調査に有効な情報を確認する事が出来ます。調査の為にメモリ ダンプを取得する場合には、完全メモリ ダンプを取得いただく事を推奨しております。
各ダンプで取得される情報についての詳細は以下の情報をご参照ください。
- 参考:
メモリ ダンプ ファイル オプションの概要
http://support.microsoft.com/kb/254649/ja
(3) メモリ ダンプの取得方法
実際にシステムがクラッシュした際にメモリ ダンプを生成するには、事前にシステムの設定をする必要がございます。具体的には以下 2 つの設定を行います。
上記 2 つの具体的な手順として完全メモリ ダンプの設定手順を以下にご案内いたします。
(4) 完全メモリ ダンプの採取のための事前設定
以下 2つの設定を行い、メモリ ダンプが正しく出力されるように設定します。
1. PageFile の大きさを設定する
PageFile の初期サイズと最大サイズを、物理メモリのサイズ + 300 MByte以上に設定します。
※ 300 MByte はダンプ ファイルのヘッダー情報や二次ダンプ ファイルのために使われる領域です。現在サポートしているどの OS のどの環境にでも対応できるように余裕を持たせた値となっております。弊社の KB やエンジニアがお送りしているメールによっては、より少ない値 (1MB など) でご案内している場合もございます
場所：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\Memory Management
名前：PagingFiles
種類：REG_MULTI_SZ
値：<ページ ファイル保存先> <初期サイズ (MB)> <最大サイズ (MB)>
例:）物理メモリのサイズが 4 GB (4096 MB) の場合
“c:\pagefile.sys 4396 4396”
※ 初期サイズを物理メモリ サイズより小さくした場合、システムに深刻なクラッシュが発生して PageFile のファイル サイズを必要な大きさまで拡張する機能が動作しなくなった際に、正常に完全メモリ ダンプが生成されなくなる可能性があります。必ず、初期サイズも最大サイズと同様に物理メモリ サイズより大きくしてください
2. メモリ ダンプが生成される設定にする
レジストリ エディタで、下記のレジストリの値を設定します。
場所： HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
名前： CrashDumpEnabled
種類： REG_DWORD
値： 1
値の説明:
0x0 = メモリ ダンプなし
0x1 = 完全メモリ ダンプ
0x2 = カーネル メモリ ダンプ
0x3 = 最小メモリ ダンプ
メモリ ダンプの出力先は以下のレジストリ値で確認できます。
名前： DumpFile
種類： REG_EXPAND_SZ
既定値： %SystemRoot%\MEMORY.DMP
上記レジストリの設定を変更した後は、設定値を反映する為にシステムの再起動が必要となります。
(5) 手動でメモリ ダンプを生成する方法
上述のダンプの設定を行った後、次回以降ブルー スクリーン エラーが発生するとメモリ ダンプが保存されます。実際にメモリ ダンプが生成されるか確認する場合には、後述にてお伝えいたします、手動でメモリ ダンプを生成する方法をご検討下さい。この方法はメモリ ダンプを強制的に取得したい場合（フリーズやハングアップ等）にも利用できます。なお、手動でダンプを生成する際にも、ブルー スクリーンの状態になりますので、サーバーの電源を強制的に OFF/ON した際と同様の影響があることを予めご了承ください。
手動でメモリ ダンプを生成するには、以下の 2 つの方法がございます。
尚、NMI スイッチを使用する事により、キーボード等で操作できない状況でもメモリダンプを採取できる可能性があります。NMI はキーボード操作より高い優先順位で割り込みを発生させますので、キーボード操作ができない場合も、ダンプが取得できる可能性があります。その為、可能な限り NMI でのメモリ ダンプ取得をご検討下さい。
※ ブルー スクリーンの “Dumping physical memory to disk” の値が 100 になったタイミング（後述の画面ピクチャ参照）で電源 OFF/ON による再起動を実施してください 。尚、自動再起動が設定されている場合は 100 になったタイミングで自動で再起動されます。
- 自動再起動の設定値について
自動再起動の設定は以下のレジストリ値よりご確認いただけます。
レジストリ キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\AutoReboot
値:
0 = 自動再起動無効
1 = 自動再起動有効
ブルー スクリーンが表示されている際には、物理メモリの情報をファイルとして出力しております。その出力状況が “Dumping physical memory to disk” の値です。その為、この値が 100 に達する前に再起動を実施した場合には正しくファイルが出力されない状況となりますので、必ず 100 になったことを確認してから再起動を実施ください。このファイル出力にかかる時間は、ディスクへの書き込み速度および物理メモリのサイズに応じて変化します。
(6) NMI を使用したメモリ ダンプ生成方法
NMI を有効にする為、まずはソフトウェア側のダンプ設定を行います。
1. [スタート] から [コンピューター] を右クリックし [プロパティ] をクリックします。
2. [システム] 画面から右下の [設定の変更] をクリックします。
3. [システムのプロパティ] 画面の [詳細設定] タブより、[起動と回復] 欄にある [設定] ボタンをクリックします。
4. [起動と回復] 画面より、デバッグ情報の書き込みを [完全メモリ ダンプ] に設定します。
5. [OK] をクリックし画面を閉じます。
6. 次に [レジストリ エディター] を開き、以下のレジストリ サブ キー を選択します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
7. [CrashControl] キーを右クリックし、[新規] から [DWORD 値] をクリックします。
8. 追加された DWORD 値の名前に ”NMICrashDump” と入力し、ENTER キーを押します。
9. NMICrashDumpを右クリックし、[修正] をクリックします。
10. [値のデータ] の空欄に ”1” を入力し [OK] ボタンをクリックします。
11. 再起動を実施し、レジストリの変更を反映します。
12. NMI スイッチを使用してダンプ ファイルが生成されるか確認します。
ダンプの取得する為の NMI スイッチはそれぞれのサーバーによって場所が異なります。NMI の発行方法につきましてはハードウェア ベンダーのご提供元様にお問い合わせください。
尚、Windows Server 2012、Windows 8 の環境においては NMI の設定が既定で構成されておりますので、上記レジストリの追加および変更は必要ありません。
Windows ベースのシステムに、NMI を使用して完全クラッシュ ダンプ ファイルまたはカーネル クラッシュ ダンプ ファイルを生成する方法
http://support.microsoft.com/kb/927069/ja
NMI_HARDWARE_FAILURE error when an NMI is triggered on Windows 8 and Windows Server 2012
http://support.microsoft.com/kb/2750146
(7) キーボードを使用したメモリ ダンプ生成方法
キーボードからの割り込み処理を有効にする為、レジストリの設定を行います。
[PS/2 キーボードの場合]
レジストリ エディタで、下記のレジストリの値を設定してください。
場所：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
名前：CrashOnCtrlScroll
種類：REG_DWORD
値：1
[USB キーボードの場合]
場所：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters
レジストリ値の変更後はシステムを再起動します。
- キーボードの種類を確認する方法について
上記キーボードの種別は、対象のコンピューター上にて msinfo32.exe を実行いただくことでご確認いただけます。
上記値などをご確認ください。
※ 判別が難しい場合は、両方のレジストリの値を設定いただいても問題ございません。
- 強制ダンプの採取手順
強制ダンプの採取手順は以下の通りです。
- 参考
キーボード操作でメモリ ダンプ ファイルを作成できる Windows の機能
http://support.microsoft.com/kb/244139/ja
Windows Server 2008 および Windows Server 2008 R2 でカーネルまたは完全メモリ ダンプ ファイルを生成する方法
http://support.microsoft.com/kb/969028/ja
ダンプの調査をご検討される方にとって上述の内容がご参考になりますと幸いです。
こんにちは。Windows Platform サポートです。本日付けで Windows 8.1及び Windows Server 2012 R2 をご利用になっているお客様にとって非常に重要なアップデートを公開いたしましたので、以下にご案内させていただきます。
Windows RT 8.1、8.1 の Windows、および Windows Server 2012 R2 の更新 4 月 2014http://support.microsoft.com/kb/2919355/ja (日本語機械翻訳)http://support.microsoft.com/kb/2919355/en (英語)
こちらのアップデートは、今後将来的にリリースされるアップデート (セキュリティ更新プログラム/修正プログラムなどを含む) を適用する為の前提条件となります。たとえば 2014 年 5 月にリリースされる更新プログラムを適用する場合には、技術情報 2919355 のアップデートを適用していることが必要になります。
----- 技術情報 2919355 より抜粋 -----All future security and nonsecurity updates for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 require this update to be installed. We recommend that you install this update on your Windows RT 8.1, Windows 8.1, or Windows Server 2012 R2-based computer in order to receive continued future updates.
Windows RT 8.1, Windows 8.1, Windows Server 2012 R2, をお使い頂いている環境ではこのアップデートをインストール頂く事を強く推奨いたします。これは、 Windows RT 8.1, Windows 8.1, Windows Server 2012 R2, 環境において今後リリースされるアップデートのインストールにこのアップデートが必要となる為です。----------
今回のアップデートによる具体的な改善点については以下の Blog をご参照ください。
マイクロソフト公式ブログWindows 8.1 Update - Windows エクスペリエンスにとっての重要な改良http://blogs.technet.com/b/microsoft_japan_corporate_blog/archive/2014/04/04/windows-8-1-update-windows.aspx
Windows 8.1 Update: The IT Pro Perspective http://blogs.windows.com/windows/b/springboard/archive/2013/10/18/windows-8-1-update-the-it-pro-perspective.aspx
※Windows Update を介さず手動インストールを行う場合は、以下のリンクをご利用頂けます。
Windows 8.1 Update (KB2919355) http://www.microsoft.com/ja-jp/download/details.aspx?id=42327
x64 ベース システム用 Windows 8.1 Update (KB2919355)http://www.microsoft.com/ja-jp/download/details.aspx?id=42335
Windows Server 2012 R2 Update (KB2919355)http://www.microsoft.com/ja-jp/download/details.aspx?id=42334
------ 上記リンクより抜粋 ------1. ダウンロードを開始するには、[ダウンロード] ボタンをクリックして次のいずれかを実行するか、[言語の変更] で別の言語を選択して [変更] をクリックします。[実行] をクリックすると、すぐにインストールを開始します。
[保存] をクリックすると、後からインストールするためのダウンロード ファイルをコンピューターにコピーします。
2. これらの更新プログラムは、次の順序でインストールする必要があります: KB2919442、KB2919355、KB2932046、KB2937592、KB2938439、KB2934018。
3. KB2919442 は、Windows 8.1 Update の前提条件であるため、KB2919355 をインストールする前にインストールする必要があります。
Windows 8.1 用更新プログラム (KB2919442) http://www.microsoft.com/ja-jp/download/details.aspx?id=42135
Update for Windows 8.1 for x64-based Systems (KB2919442)http://www.microsoft.com/en-us/download/details.aspx?id=42162--------------------------------
※追記 4/10
KB 2919355 のWSUS 経由での展開に関しましては、特定の WSUS 環境に起因した問題が確認されたため、現在のところ提供を延期しております。詳細は以下の WSUS Blog をご参照ください。
WSUS における Windows 8.1 Update (KB 2919355) の配信についてhttp://blogs.technet.com/b/jpwsus/archive/2014/04/10/wsus-windows-8-1-update-kb-2919355.aspx
Windows テクノロジー サポートの永野です。
ダンプの設定やサイズのお話をしましたので、今回は実際に解析しましょう。
まずは、以下のサイトからデバッガをダウンロードして、インストールしてください。
32bit版
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
64bit版
http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx
インストールが完了したら、シンボルのありかを環境変数に登録します。
[システムのプロパティ] - [環境変数] を開きます。
ユーザでもシステムでも構わないので、[新規] をクリックします。
変数名に "_NT_SYMBOL_PATH"、変数値に "SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols" を登録します。
C: ドライブに websymbols フォルダを作成してください。
これで環境が整いました。早速起動しましょう。
スタートメニューから Debugging Tools for Windows をたどって、WinDbg を選択してください。
起動したら [File] - [Open Crash Dump] から解析対象のダンプを選択します。
ちょっと時間がかかりますが、こんな画面が出ます。
ここで、
!analyze -v
と入力してください。
デバッガによる自動解析が始まります。
今回解析したダンプは、こんな感じでした。
1: kd> !analyze -v******************************************************************************** ** Bugcheck Analysis ** ********************************************************************************
MANUALLY_INITIATED_CRASH (e2)The user manually initiated this crash dump.Arguments:Arg1: 00000000Arg2: 00000000Arg3: 00000000Arg4: 00000000
Debugging Details:------------------
BUGCHECK_STR: MANUALLY_INITIATED_CRASH
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 5
LAST_CONTROL_TRANSFER: from 8fd53c6b to 81d070e3
STACK_TEXT: 805ecc40 8fd53c6b 000000e2 00000000 00000000 nt!KeBugCheckEx+0x1e805ecc70 8fd54174 00d54920 0026ebd8 00000000 i8042prt!I8xProcessCrashDump+0x255805eccb8 81c8d941 871e0280 86d54868 805ecce4 i8042prt!I8042KeyboardInterruptService+0x21e805eccb8 81ceeeae 871e0280 86d54868 805ecce4 nt!KiInterruptDispatch+0x51805ecd54 00000000 0000000e 131542b4 0d7306da nt!KiIdleLoop+0x1a
STACK_COMMAND: kb
FOLLOWUP_IP: i8042prt!I8xProcessCrashDump+2558fd53c6b 83fe01 cmp esi,1
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: i8042prt!I8xProcessCrashDump+255
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: i8042prt
IMAGE_NAME: i8042prt.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 47918f5d
FAILURE_BUCKET_ID: MANUALLY_INITIATED_CRASH_i8042prt!I8xProcessCrashDump+255
BUCKET_ID: MANUALLY_INITIATED_CRASH_i8042prt!I8xProcessCrashDump+255
Followup: MachineOwner---------
今回、ブルースクリーンを発生させたモジュールがサクッと表示されます。
ここに表示されたモジュールが犯人の可能性があります。
モジュールをアップデートすることで、障害が起きなくなるかどうか等、試してみてはいかがでしょうか？
ちなみに落ちた理由も、自動解析で表示されます。
今回は、
MANUALLY_INITIATED_CRASH (e2)The user manually initiated this crash dump.
なので、ユーザが自ら採取したダンプであることがわかります。
自分でダンプを採取して、遊びたい人のために次回はその方法をご紹介する予定です。
こんにちは。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 の無効化をご検討ください。
文書番号: 981482Windows 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 用文書番号 : 2779768Windows 8 および Windows Server 2012 の累積的な更新プログラム (2012 年 12 月)http://support.microsoft.com/kb/2779768
// Windows Server 2008 R2/Windows Server 2008 用文書番号: 2684681Iscsicpl.exe プロセスは、ストレージ デバイスは、Windows Vista、Windows Server 2008、Windows 7 は、または Windows Server 2008 R2 を実行しているコンピューターに再接続しようとするとを応答を停止します。http://support.microsoft.com/kb/2684681
// Windows Server 2003 用文書番号 : 2277122Stop 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 テクノロジー サポートの安達です。
Sysprep 実施中に任意のコマンドを実行する方法についてご紹介したいと思います。
なお、本日ご紹介させていただきますコマンドの実行方法についてはWindows Vista 以降の OS に付属の Sysprep を対象とした内容となります。
Sysprep はシステム準備ツールと呼ばれ、主にマスタ用に構築した環境を複数の端末に展開する場合に SID 等のシステム固有のデータを初期化するために使用されるツールです。
Sysprep は様々な設定を初期化し、クリーンアップ処理を行います。
それらの設定は Sysprep 実行時に指定可能な応答ファイルを用いる事で設定可能な項目もありますが、応答ファイルで用意されていない設定や個別のカスタマイズを行いたい場合は、Sysprep 中に特定のタイミングでコマンドを実行し、設定する方法があります。
Sysprep 中に任意のコマンドを実行する一般的な方法としては、以下の 3 つがあります。
上記 3 つの方法は実行されるタイミングや設定方法がそれぞれ異なりますので、個別にご紹介していきます。
1. SetupComplete.cmd を利用する方法
※ Scripts フォルダは既定で存在しませんので新規に作成します。 メモ帳から直接保存する事は出来ませんので、 一旦任意の場所に作成してから保存してください。
以下 "Windows のセットアップ" の最終処理中に実行されます。
2. 応答ファイルの <RunSynchronousCommand> を利用する方法
Sysprep 実行時に指定可能な応答ファイルに <RunSynchronousCommand> を設定する事により任意のコマンドを実行させる事が可能です。
今回は、Sysprep の Specialize と呼ばれる構成パス中にコマンドを実行する方法について紹介します。
以下 Sysprep の Specialize 構成パスにおける "システム設定の適用中" に実行されます。
3. 応答ファイルの <FirstLogonCommands> を利用する方法
Sysprep 実行時に指定可能な応答ファイルに <FirstLogonCommands> を設定する事により任意のコマンドを実行させる事が可能です。
<FirstLogonCommands> を利用する事により、Sysprep 完了後の初回ログオン時に1 度だけ任意のコマンドを実行させる事が可能です。
なお、ここでご紹介させていただく方法でのコマンド実行はログオンしたアカウントの権限で実行されます。管理者権限を持つアカウントでログオンした場合は、昇格された権限にて実行されます。
以下 Sysprep 後の初回ログオン時に実行されます。
Add a Custom Command to an Answer Filehttp://technet.microsoft.com/ja-jp/library/dd799295(en-us,WS.10).aspx
RunSynchronousCommandhttp://technet.microsoft.com/ja-jp/library/cc722359(WS.10).aspx
FirstLogonCommandshttp://technet.microsoft.com/ja-jp/library/cc722150(WS.10).aspx
Sysprep とはhttp://technet.microsoft.com/ja-jp/library/cc721940(WS.10).aspx
Windows 7 展開センターhttp://technet.microsoft.com/ja-jp/windows/ee517406.aspx
Windows 7 標準クライアント イメージの作成手順http://technet.microsoft.com/ja-jp/windows/ee676462.aspx
こんにちは。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を利用する方法についてご紹介します。
[2014 年更新]最新版の Microsoft Windows Dynamic Cache Service では、Windows 7 / Windows Server 2008 R2 でも動作するように変更が加えらえれました。Windows 7 以降の OS で DynCache サービスをご利用いただく場合は、以下のダウンロード センターより、最新版をダウンロードしてご利用ください。
Microsoft Windows Dynamic Cache Service
OS バージョンのチェックの箇所
Microsoft Windows Dynamic Cache Service には、ダウンロード ファイルの中にこのツールのソースコードも含まれています。この中の DynCache.cpp の 1141 行目付近がバージョン チェックを実施していますが、Windows Server 2008 R2 環境で利用するには下記の (OSVerInfo.dwMinorVersion > 0) を (OSVerInfo.dwMinorVersion > 1) に変更する必要があります。
// Make sure that the OS is not later than Windows Server 2008
OSVerInfo.dwOSVersionInfoSize = sizeof(OSVerInfo);
if ( (GetVersionEx (&OSVerInfo) == NULL) )
{
dwStatus = GetLastError();
DebugMessage(L"GetVersionEx failed with error code 0x%X!\n", dwStatus);
SvcCleanup(dwStatus);
return (FALSE);
}
else
if (OSVerInfo.dwMajorVersion == 6)
if (OSVerInfo.dwMinorVersion > 1) // 0 から 1 に変更します
DebugMessage(L"Dynamic Cache Service only runs on Windows Server 2008 or earlier versions.\n");
SvcCleanup(ERROR_RMODE_APP);
else if (OSVerInfo.dwMajorVersion > 6)
ビルド方法
ここでは 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 など、スペースを含まないパスへコピーします。
3. Microsoft Windows Dynamic Cache Service 内の DynCache\source フォルダ内にある sources を右クリックのプロパティで読み取り専用を外した後に notepad.exe などのテキスト エディタで開き、以下のように書き換えます。(項目 2 のフォルダを C:\SDK 配下にコピーした場合の例です)
############## DynCache sources file ####################
TARGETNAME=DynCache
TARGETPATH=.\obj
TARGETTYPE=PROGRAM
# Use the Windows SDK include and lib paths.
# The WDK does not contain files for using performance counters.
INCLUDES=C:\SDK\Include
SOURCES=DynCache.cpp \
Service.cpp \
debug.cpp \
DynCache.rc
C_DEFINES=-DUNICODE -D_UNICODE
# specify which C runtimes to link with (default is libc.lib)
USE_LIBCMT=1
UMENTRY=wmain
UMTYPE=console
UMLIBS= C:\SDK\Lib\x64\kernel32.lib \
C:\SDK\Lib\x64\user32.lib \
C:\SDK\Lib\x64\advapi32.lib \
C:\SDK\Lib\x64\Psapi.lib \
C:\SDK\Lib\x64\Pdh.lib
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 プラット フォーム サポートの高山です。
今回は、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 エラーが発生しなければ、ページ ファイルのサイズは自動的に元の拡張前のサイズに縮小させます。
名前: LastCrashTime
種類: REG_DWORD
なお、直ちに、ページ ファイルのサイズを拡張前のサイズに戻す必要がある場合は、レジストリから “LastCrashTime” を手動で削除し、システムの再起動を行うと拡張前のサイズに戻すことも可能です。
現在使っているシステムでは、どの種類のメモリ ダンプを選べば良いのかという疑問も出てくるかと思いますが、その点については仮想メモリのサイズをどうしたいのか、という部分と密接に関係しているので、また別の機会に改めてご紹介したいと思います。
こんにちは。Windows テクノロジー サポートの横山です。
Windows Server 2008 および Windows Server 2008 R2 で作成したパフォーマンス カウンタをシステム起動時から自動的に開始する方法を紹介します。
Windows Server 2008 および Windows Server 2008 R2 のパフォーマンス モニタでは、Windows 2000 Server および Windows Server 2003 のパフォーマンス モニタの時と同じ手順で、パフォーマンス カウンタをシステム起動時に自動的に開始させる事は出来ません。
Windows Server 2008 および Windows Server 2008 R2 においてシステム起動時に自動的にカウンタを開始するためには以下の 3 つを組み合わせて使用する必要があります。
a. logman.exe
b. バッチ ファイル
c. タスク スケジューラ
具体的には、以下に記載する設定を行う事でシステム起動時に自動的にカウンタを開始することができます。
- パフォーマンス カウンタを起動時から開始させる手順について
以下の手順にて、パフォーマンス カウンタをシステム起動時から開始させることができます。
1. メモ帳を開きます。
2. logman start <作成したデータ コレクタ セット名> と入力します。
3. 任意のファイル名を入力し、.bat ファイルとして保存します。
4. [タスク スケジューラ] を開き、[タスクの作成] を選択します。
5. 任意の名前を入力します。
6. [セキュリティ オプション] から、タスクの実行時に使うユーザー アカウントとして administrator (もしくは情報採取に必要な権限を持ったユーザー) を指定し、以下を選択します。
[ユーザーがログオンしているかどうかにかかわらず実行する (W) ]
[最上位の特権で実行する]
7. [トリガー] タブより [タスクの開始] から [スタートアップ時] を選択します。
8. [操作] タブより [プログラムの開始] を選択し、手順の 3. で作成した .bat ファイルを指定します。
9. タスク作成ウィザードを閉じ、タスクの作成を完了します。
以上の設定を行う事によって、システム起動時にタスク スケジューラから logman.exe が実行され、指定したデータ コレクタ セットが開始されます。
補足
======
- logman.exe について
logman.exe は Windows Server 2008 および Windows Server 2008 R2 に標準で実装されているツールとなり、既定では C:\Windows\System32 配下にあります。
logman.exe を使用することで、GUI 上からではなくコマンド プロンプトからデータ コレクタ セットを操作することができます。
(※ 採取するカウンタ類の設定は GUI 上で前もって定義、作成しておきます。)
今回使用するコマンドは以下の通りとなります。
> logman start <作成したデータ コレクタ セット名>
ここで、<作成したデータ コレクタ セット名> は、開始対象とするデータ コレクタ セットの名前を指定します。
(※ logman.exe の詳細につきましては、logman /? とコマンド プロンプトから実行していただくことでご確認いただけます。)
こんにちは。Windows プラットフォーム サポートの北原です。
最近、Service Pack 1 が既に適用されているのにもかかわらず、Windows 7 の Windows Update に Service Pack 1 が現れるというお問い合わせをいくつかいただいております。
誠に恐縮ながら、現在のところ、この事象について述べられている情報が、以下の KB 内の概要情報のみとなっておりますので、本記事にてこの更新プログラムの詳細についてご説明します。
Description of Software Update Services and Windows Server Update Services changes in content for 2014http://support.microsoft.com/kb/894199/en-us
=============概要=============この 2014 年 8 月 12 日に公開された Windows 7 Service Pack 1 (KB976932) は、実際の Service Pack 1 のインストーラーと全くの同名ですが、中身は別物で、10MB 以下の非常に小さなサイズとなっております。この中には、以下の 2 つの更新プログラムが含まれております。
KB2534366Windows 7 SP1 または Windows Server 2008 R2 SP1 をインストールするときに "0xC000009A" エラー メッセージが表示されるhttp://support.microsoft.com/kb/2534366/ja
KB2533552Windows 7 SP1、Windows Server 2008 R2 SP1、または Windows Embedded Standard 7 SP1 をインストールしたときに "0xC0000034" エラー メッセージが表示されるのを防ぐ更新プログラムを利用できますhttp://support.microsoft.com/kb/2533552/ja
この 2 つの更新プログラムは、Windows 7 に Service Pack 1 をインストールする際の問題に対処することを主な目的として用意されたもので、これまでは通常どおりWindows Update にて提供されてきました。
今回、この 2 つの更新プログラムが Windows 7 の Service Pack 1 に追加されることになったのですが、既存のバイナリには一切変更をせずに、別途、違うパッケージとして、提供する方法がとられました。以下は、そのイメージを表した図になります。
結局のところ、この「追加分の Windows 7 Service Pack 1 (KB976932)」の実体は、重要な更新プログラムの集まりとなりますので、Windows Update に現れましたら、他の重要な更新プログラムと同様に適用いただくことを強く推奨しております。
=============事象が起こる環境=============2014 年 8 月 22 日現在、この「追加分の Windows 7 Service Pack 1 (KB976932)」が Windows Update に現れる環境は以下の通りです。
対象: Windows 7 (Service Pack の有無は問わない) 上の Windows Update WSUS は現在のところ対象外です
(2014 年 8 月 29 日追記) x86 だけではなく、x64 も対象となりました
条件: 上記の 2 つの更新プログラムのどちらか、または両方がインストールされていないこと
※ 今後、このルールは変更になる可能性があります
=============事象のパターン=============現在、以下に示す 2 つのパターンで、「追加分の Windows 7 Service Pack 1 (KB976932)」がWindows Update に現れます。
(1) Service Pack 1 が適用されていない場合
Service Pack 1 が適用されておらず、上記の 2 つ更新プログラムも適用されていない場合、以下のスクリーンショットのように、「追加分の Windows 7 Service Pack 1 (KB976932)」が現れます。
※ 公開日が 8 月 14 日となっているのは、8 月 14 日に内部のメタ データに変更があったためです
「追加分の Windows 7 Service Pack 1 (KB976932)」を適用後、OS を再起動すると、[インストールされた更新プログラム] に上記の 2 つ更新プログラムが現れます。
ここでようやく Service Pack 1 のインストーラーの本体が Windows Update に現れますので、これをインストールすることで Service Pack 1 のインストールが完了します。
その後、Windows 7 Service Pack 1 (KB976932) という名前をしたパッケージが表示されることはありません。
(2) 既に Service Pack 1 が適用されている場合
Service Pack 1 が既に適用されてしまっている環境でも KB2533552 が適用されていない場合のみ、以下のスクリーンショットのように、「追加分の Windows 7 Service Pack 1 (KB976932)」が現れます。この中には、KB2533552 のみが含まれております。
※ Service Pack 1 適用後においては、KB2534366 が不要であるため、このような動きになっています
「追加分の Windows 7 Service Pack 1 (KB976932)」を適用後、OS を再起動すると、[インストールされた更新プログラム] に KB2533552 が現れます。
その後、Windows 7 Service Pack 1 (KB976932) という名前をしたパッケージが配信されることはありません。
=============まとめ=============2014 年 8 月 12 日に公開された「追加分の Windows 7 Service Pack 1 (KB976932)」の実体は、KB2534366 と KB2533552 になります。
繰り返しとなりますが、既に Service Pack 1 をご適用いただいている環境におきましても、この「追加分の Windows 7 Service Pack 1 (KB976932)」が Windows Update に現れましたら、他の重要な更新プログラムと同様にご適用いただくことを強く推奨しております。
Windows テクノロジー サポートの奥原です。
今回は、最近いただいたお問い合わせについてご紹介します。
- 現象Windows Server 2008 および、Windows Server 2008 R2 で、System State のバックアップを行うとバックアップに失敗する。vssadmin list writers コマンドにて VSS ライタの状況を確認すると"System Writer" が表示されていない。
VSS ライタ (アプリケーション ライタ) とはhttp://blogs.technet.com/b/askcorejp/archive/2009/08/11/dpm-2007-sp1-hyper-v.aspx
"System Writer" が表示されない現象は、以下の要因があげられます。
主な要因について=================================1. ファイルのアクセス権が何らかの理由で失われている場合2. ライターをホストするプロセス、または、COM+ Event System サービスが稼動していない場合3. サービスのセキュリティ権限が何らかの理由で失われている場合4. VSS ライターに関する初期化が何らかの理由にて失敗している場合
各要因の説明と対処方法は以下の通りとなります。
1. ファイルのアクセス権が何らかの理由で失われている場合---------------------------------ファイルのアクセス権やサービスのセキュリティ権限に問題がある場合、イベント ログに Microsoft-Windows-CAPI2 513 (または 512) イベントが記録されている可能性があります。
このイベントが発生している場合、技術情報 2009272 の対処方法を実施します。
技術情報 2009272 より抜粋-----------------------Takeown /f %windir%\winsxs\temp\PendingRenames /a icacls %windir%\winsxs\temp\PendingRenames /grant "NT AUTHORITY\SYSTEM:(RX)"icacls %windir%\winsxs\temp\PendingRenames /grant "NT Service\trustedinstaller:(F)"icacls %windir%\winsxs\temp\PendingRenames /grant BUILTIN\Users:(RX)Takeown /f %windir%\winsxs\filemaps\* /a icacls %windir%\winsxs\filemaps\*.* /grant "NT AUTHORITY\SYSTEM:(RX)"icacls %windir%\winsxs\filemaps\*.* /grant "NT Service\trustedinstaller:(F)"icacls %windir%\winsxs\filemaps\*.* /grant BUILTIN\Users:(RX) net stop cryptsvcnet start cryptsvc-----------------------上記、対処方法を実施後、vssadmin list writers コマンドを実施し、"System Writer" が表示されることを確認します。
System State backup using Windows Server Backup fails with error: System writer is not found in the backuphttp://support.microsoft.com/kb/2009272/
2. ライターをホストするプロセス、または、COM+ Event System サービスが稼動していない場合---------------------------------System Writer は Cryptographic Services 内のコンポーネントとして動作していますので、Cryptographic Services が動作していない場合には System Writer も動作できません。また、ライターと VSS との通信は COM 経由で行われますので、COM+ Event System サービスも動作している必要があります。
Cryptgraphic Services および Volume Shadow Copy サービスの起動を確認、起動していない場合は起動させ、"System Writer" が表示されることを確認します。
なお、サービスが起動しない、起動しているのに "System Writer" が表示されない場合、以下の対処を引き続き行います。
3. サービスのセキュリティ権限が何らかの理由で失われている場合---------------------------------Cryptgraphic Services および Volume Shadow Copy サービスが起動しない場合、サービスを実行するためのセキュリティ権限が何らかの理由で失われている可能性があります。
各サービスのセキュリティ権限を以下の方法で確認します。
コマンド プロンプトより、つぎのコマンドを実施し、時現在の設定を確認します。
sc sdshow cryptsvcsc sdshow EventSystem
念のため、上記コマンドの実行時、出力結果をリダイレクトでテキスト ファイルに出力する方法等により、バックアップを取得しておきます。
実行例>sc sdshow cryptsvc > cryptsvc.txtsc sdshow EventSystem > EventSystem.txt
出力されたテキスト ファイルと以下の内容と比較します。D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
上記と異なる場合には、cs sdset コマンドを実行します。実行例>Sc sdset cryptsvc D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)sc sdset EventSystem D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
Cryptographic Service を再起動後に "System Writer" が表示されることを確認します。
4. VSS ライターに関する初期化が何らかの理由にて失敗している場合---------------------------------VSS ライターの初期化について少し解説します。VSS Requestor よりバックアップを行う場合、VSS API GatherWriterMetadata を実行し、各 VSS Writerに関する Writer Metadata Document と呼ばれるメタデータ情報を取得する必要があります。その際、VSSサービスは、System Writerを含むすべてのVSS Writerに対してIdentifyイベントを送り、各自のメタデータ情報を準備させ、参照できるように要求します。
.Net Frameworkが実装されている環境において、System Writerは独自のメタデータ情報を準備するために、%WinDir%\Microsoft.Net\Framework 配下のサブフォルダを列挙して処理を進める必要があります。このフォルダにあるサブフォルダ数が 1,000 個以上存在する場合、システム実装上の制限によりSystem Writer がメタデータ情報を正しく準備できず、その結果、"System Writer" が表示されない現象が発生します。
IVssBackupComponents::GatherWriterMetadata method http://msdn.microsoft.com/en-us/library/windows/desktop/aa382668(v=vs.85).aspx
Overview of Backup Initialization - Writer Actions during Backup Initialization http://msdn.microsoft.com/en-us/library/windows/desktop/aa384577(v=vs.85).aspx
この現象を回避するには、次の対処を行います。
対処方法以下に Microsoft.NET\Framework\v2.0.50727 を例に、Temporary ASP.NET Files フォルダを別の場所に移動する方法を紹介します。
1. Temporary ASP.NET Files フォルダの移動先となるフォルダを作成します。 例 : "c:\ASPTEMP"
2. "C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files" と同じアクセス権を設定します。
3. "C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files" 内のフォルダ、ファイルを手順 1. で作成したフォルダに移動させるか削除を行います。
4. IIS の構成ファイル Web.config を開きます。
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Web.config
5. Web.config に tempDirectory 属性を追加します。
tempDirectory 属性の追加例: <compilation tempDirectory="c:\ASPTEMP">
6. IIS サービスを再起動します。
- 参照資料 compilation 要素 (ASP.NET 設定スキーマ) http://msdn.microsoft.com/ja-jp/library/s10awwz0(v=VS.90).aspx
How To Edit the Configuration of an ASP.NET Application http://support.microsoft.com/kb/815178/en-us http://support.microsoft.com/kb/815178/ja (機械翻訳)
IIS を再起動する http://technet.microsoft.com/ja-jp/library/cc758159(WS.10).aspx
参考までに、Windows Server 2003 でも、"System Writer" が表示されないという類似の事象が発生する場合があります。この場合には OS が異なりますため上記の対応は利用できませんが、Windows Server 2003 では技術情報 940184 の対応方法があります。Windows Server 2003 の場合には技術情報 940184 の対応をご検討ください。
Windows Server 2003 ベースのコンピューターで "vssadmin list writers" コマンドを実行するとエラー メッセージ "エラー: 0x8000FFFF" が表示される http://support.microsoft.com/kb/940184/ja
こんにちは。Windows テクノロジー サポートの服部です。
Windows Server 2008 でイベント ログを管理するためのセキュリティ アクセス許可の変更に関するお問い合わせを複数いただきましたので以下にご紹介したいと思います。
Windows Server 2003 では、以下の公開技術情報にもありますとおり"CustomSD" レジストリ値を編集する事により、イベント ログに対するセキュリティ アクセス許可をカスタマイズできます。
- ご参考Windows Server 2003 のイベント ログのセキュリティをローカルまたはグループ ポリシーで設定する方法 http://support.microsoft.com/kb/323076/
結論としましては、Windows Server 2008 においても上記技術情報 323076 に記載されている、Windows Server 2003 と同様の手順でイベント ログのセキュリティ アクセス許可を変更することが可能です。
ただし、Windows Server 2008 では、既定で CustomSD レジストリ値は存在しませんので技術情報 323076 の方法をご利用の場合は、新たに CustomSD レジストリ値を作成する必要があります。
また、Windows Server 2008 では、OS 標準でイベント ログに関するコマンドユーティリティとして wevtutil コマンドが付属しており、wevtutil コマンドからもイベント ログに関するアクセス許可の変更が可能となっています。
今回はアプリケーションログに対して wevtutil コマンドを用いてセキュリティアクセス許可を追加する方法についてご紹介します。
- wevtutil コマンドを用いたセキュリティ アクセス許可の追加方法
1. "スタート メニュー" から "コマンドプロンプト" を右クリックし、"管理者として実行" から起動します。
2. 以下のコマンドを実行します。
wevtutil sl application /ca:O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)(A;;0x3;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)(A;;0x3;;;DU)
※Windows Server 2008 でのアプリケーションログに対するアクセス権は既定で以下となります。
O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)(A;;0x3;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)
上記例では、Windows Server 2008 の既定値に "(A;;0x3;;;DU)" の値を追記する事で、アプリケーションログに対する "読み取り" および "書き込み" 権限を "Domain Users" に付与しております。
上記設定を行う事で、例えば、以下のスクリプト等を利用し、対象となる Windows Server 2008 に対して、"Domain Users" の権限でリモートからイベントログの書き込みを行う事も可能になります。
リモートイベント ログへのイベントの書き込みhttp://www.microsoft.com/japan/technet/scriptcenter/scripts/logs/eventlog/lgevvb18.mspx
wevtutil コマンドライン ツールについては以下の Technet の記事をご参照ください。
Wevtutilhttp://technet.microsoft.com/ja-jp/library/cc732848(WS.10).aspx
以下の Technet 記事にはコマンド ラインからイベント ログを消去する方法についての説明が含まれています。よろしければ併せてご参照ください。
イベントログを消去するhttp://technet.microsoft.com/ja-jp/library/cc722318.aspx
- 参考資料Event Logging Securityhttp://msdn.microsoft.com/en-us/library/aa363658(VS.85).aspx Eventlog Keyhttp://msdn.microsoft.com/en-us/library/aa363648(VS.85).aspx
Security Descriptor Definition Languagehttp://msdn.microsoft.com/en-us/library/aa379567(VS.85).aspx
ボリューム シャドウコピーを使用されている環境で、ボリューム シャドウコピーの履歴が消える現象が発生するときがあります。また、この現象について弊社公開情報もいくつか確認でき、公開情報の多くは、Windows Server 2003 を中心に記載されていますが、Windows Server 2008, Windows Server 2008 R2 環境でも条件がそろった場合発生します。
まずは、ボリューム シャドウコピーの機能と履歴が消える現象についてご説明します。シャドウ コピーは現在のボリュームの情報からの差分情報を Diff Area の領域に保持することで、以前の情報を保持しています。この Diff Area に格納されている差分情報が履歴となり、復元時は、この履歴情報をさかのぼることで、ファイルを復元します。
Diff Area は、スナップショットが作成されたタイミングで作成されますが、その時点では一定のファイル サイズ (環境によりサイズは異なります) で作成されます。作成された Diff Area は、すべての領域を使用しているわけではなく、ボリュームの変更情報を順次格納するためのバッファ領域として確保されます。その後、ボリュームへの変更が継続して行われると、それに応じて Diff Area 内に差分情報が格納されていきます。このデータが積み重なり、初期サイズを超過する可能性がある場合、Diff Area を拡張する処理が行われます。
この Diff Area の拡張処理で問題が発生し、差分情報が正しく書き込めないことがあります。差分情報が正しく書き込めなかった場合、履歴情報をさかのぼることができなくなり、格納している差分情報はすべて使用できなくなります。この結果、使用不能となった差分情報が削除され、ボリューム シャドウコピーの履歴が消える現象が発生します。
Diff Area 拡張処理での問題として多く寄せられますのが、以下の 2 点となります。
・Diff Area 拡張処理が完了するまでに Diff Area の領域が使い切ってしまった。 この場合、イベントログ上に Volsnap 25 のエラーイベントが記録されます。
・Diff Area 拡張処理を行った際に処理が失敗した。 処理が失敗する多くの原因は、システムリソース不足により失敗することが報告されています。 この場合、イベントログ上に Volsnap 20 のエラーイベントが記録されます。
ボリューム シャドウコピーの履歴が消える現象の発生を少なくする方法としては、以下があげられます。
1. あらかじめ Diff Area の初期サイズを増やしておく========================================ボリューム シャドウコピーのご使用環境によって使用する領域は異なりますが、Diff Area の初期サイズを増やしておくことで、上述の問題が発生する頻度が低下します。
Diff Area の初期値の拡張について----------------------------------------Diff Area の領域を変更するには、以下のレジストリ値を編集します。Diff Area の初期値は、次回シャドウ コピー実行のタイミングで反映されます。
- MinDiffAreaFileSize の変更手順------------------------------------1. [スタート] - [ファイル名を指定して実行] をクリックし、regedit と入力し、OK ボタンをクリックします。
2. 以下のレジストリキーをご確認いただき、クリックします。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VolSnap
3. メニューバーより、[編集] - [新規] を選択し、[DWORD 値] をクリックします。
4. MinDiffAreaFileSize と入力し、Enter キーを押します。
5. 続けて、[編集] - [修正] をクリックします。
6. 設定する Diff Area のサイズ※を入力し、[OK] をクリックします。※デフォルトの設定は 300 MB となり、最大値は 3 GB となります。
7. メニューバーより、[ファイル] - [レジストリエディタの終了] で終了します。
- 参考資料MinDiffAreaFileSizehttp://msdn.microsoft.com/en-us/library/bb891959(VS.85).aspx#mindiffareafilesize
技術情報:925799タイトル: Error message when a Windows Server 2003-based computer has a high level of I/O activity: "The shadow copies of volume Volume_Name were aborted because the diff area file could not grow in time"http://support.microsoft.com/kb/925799/ja (機械翻訳)
技術情報:925799 は、Windows Server 2003 を対象にした情報ですが、 レジストリ値 MinDiffAreaFileSize は Windows Server 2008 以降でも有効です。
2. 取得するボリューム シャドウコピーの履歴 (世代) 数を減らす========================================取得可能なスナップショットの世代数は、最大で 64 となりますが、世代数が多いとDiff Area の領域が大きくなり、環境によってはリソースに関連した問題が発生する場合がございます。世代数は以下のレジストリ値により変更が可能です。
世代数の変更について----------------------------------------スナップショットの世代数を変更するには、以下のレジストリ値を編集します。スナップショットの世代数は、コンピュータの再起動することで反映されます。
- MaxShadowCopies の変更手順------------------------------------1. [スタート] - [ファイル名を指定して実行] をクリックし、regedit と入力し、OK ボタンをクリックします。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings
4. MaxShadowCopies と入力し、Enter キーを押します。
6. 設定する世代数※を入力し、[OK] をクリックします。※最大値は 64 となります。
7. メニューバーより、[ファイル] - [レジストリエディタの終了] で終了します。8. コンピュータを再起動します。
補足Diff Area の設定値の確認方法========================================現在の Diff Area に割り当てられた値は、vssadmin list shadowstorage コマンドにてご確認いただけます。
実行結果例)シャドウ コピーの記憶域関連付け "/For" ボリューム: (E:)\\?\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxx}\ シャドウ コピーの記憶域ボリューム: (E:)\\?\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxx}\ シャドウ コピーの記憶域の使用領域: 3.078 MB シャドウ コピーの記憶域の割り当て領域: 500 MB シャドウ コピーの記憶域の最大領域: UNBOUNDED
vssadmin list shadowstorage コマンドの結果で表示される項目について----------------------------------------"/For" ボリューム : ボリューム シャドウコピーの対象ドライブシャドウ コピーの記憶域ボリューム : Diff Area の格納先シャドウ コピーの記憶域の使用領域 : 現在使用している Diff Area の使用容量シャドウ コピーの記憶域の割り当て領域 : 現在割り当てられている Diff Area のサイズシャドウ コピーの記憶域の最大領域 : Diff Area サイズの変更で割り当てた最大サイズになります。(既定では、無制限:UNBOUNDED)
参考情報Volsnap 25 イベントについてhttp://blogs.technet.com/b/askcorejp/archive/2012/02/22/volsnap-25.aspxVolsnap 25 イベントの解説と、VSS の動作について詳しく説明されております。
こんにちは。Windows プラットフォーム サポートの加藤です。本日はよくお問い合わせをいただく、エクスプローラーで確認した時のファイルサイズの合計とディスクのプロパティの使用領域に差異が発生する現象についてご紹介します。
<差異が発生する主な原因について>差異が発生する原因は様々ですが、ファイル システムが正常である場合、常に正しいサイズを表示しているのはディスクのプロパティの使用領域です。一般的にエクスプローラーで全ファイルを選択した場合のサイズは、ディスクのプロパティの使用領域よりも少なくなります。これは、エクスプローラーの既定では隠し属性やシステム属性のフォルダ、ファイルは表示されないため、全選択を実施しても実際には選択されないために差異が発生します。この問題はエクスプローラーの表示オプションを変更することで回避可能です。
また、サイズを確認したユーザーのアクセス許可がないフォルダ、ファイルが存在していると、これらフォルダ、ファイルはエクスプローラーからサイズが取得できないため、この場合にも差異が発生します。一般的に多く報告されているのは、以下の 3 つのフォルダです。
1. ごみ箱2. WER (Windows Error Reporting) の保存先フォルダ3. System Volume Information フォルダ (Volume ShadowCopy Service で作成されるシャドウ コピーが保存されます。)
他のユーザーのごみ箱には、アクセス許可がないため、サイズを取得することができません。WER の保存先フォルダは、設定によって変更可能ですが、保存先のフォルダにアクセス許可がない場合には、サイズを取得することができません。System Volume Information フォルダは、一般ユーザーにはアクセス許可がないため、サイズを取得することができません。
<対処策について>隠し属性やシステム属性のフォルダ、ファイルの対処方法は、エクスプローラーの以下の表示オプションを変更することで回避可能です。
--------------[ファイルとフォルダーの表示] - [隠しファイル、隠しフォルダ―、および隠しドライブを表示する] or [すべてのファイルとフォルダを表示する] を選択。[保護されたオペレーティング システム ファイルを表示しない] のチェックを外す。--------------
アクセス許可がないフォルダのうちごみ箱と WER 関しては、[ディスクのクリーンアップ] 機能でサイズの確認と削除が可能です。なお、[ディスクのクリーンアップ] 機能はクライアントには標準でインストールされていますが、サーバー OS の場合は、Windows Server 2008 以降は [デスクトップ エクスペリエンス] の機能を追加する必要があります。※ 機能の追加手順は後述します。
System Volume Information フォルダのシャドウ コピーのサイズを確認するためにはコマンド プロンプトで以下の vssadmin コマンドを実行します。
vssadmin List ShadowStorage
実行結果の [シャドウ コピーの記憶域の使用領域] が現在のシャドウ コピーのサイズです
実行例C:\WINDOWS\system32>vssadmin List ShadowStorage vssadmin 1.1 - ボリューム シャドウ コピー サービス管理コマンド ライン ツール(C) Copyright 2001-2013 Microsoft Corp.
シャドウ コピーの記憶域関連付け ボリューム: (C:)\\?\Volume{f16b0aa0-f241-11e1-b33e-ac162d026d14}\ シャドウ コピーの記憶域ボリューム: (C:)\\?\Volume{f16b0aa0-f241-11e1-b33e-ac162d026d14}\ シャドウ コピーの記憶域の使用領域: 9.71 GB (1%) シャドウ コピーの記憶域の割り当て領域: 10.8 GB (2%) シャドウ コピーの記憶域の最大領域: 45.0 GB (9%)
シャドウ コピーは vssadmin コマンドの Delete Shadows オプションで過去のバージョンを削除することが可能です。なお、シャドウ コピーは [共有フォルダのシャドウコピー] 機能以外でもバックアップソフトなどによって使用される場合もあるため、[共有フォルダのシャドウコピー] を使用していない環境でシャドウ コピーが作成されている場合には、そのシャドウ コピーの削除可否と削除方法についてバックアップソフトベンダー様に確認します。
vssadmin コマンドから確認できる使用領域のサイズはシャドウ コピー機能で使用されているサイズです。例えば、ウィルス対策ソフト等などで System Volume Information フォルダに書き込みが行われている場合には正確なサイズを確認することができません。そのため一時的に System Volume Information のプロパティからアクセス許可を変更して確認することも検討します。
- 参照資料System Volume Information フォルダへアクセスする方法http://support.microsoft.com/kb/309531/ja
vssadmin コマンドでシャドウ コピーが削除できない場合の対処方法についてhttp://blogs.technet.com/b/askcorejp/archive/2013/11/29/vssadmin.aspx
-------------------------------------------------機能 [デスクトップ エクスペリエンス] の追加手順-------------------------------------------------[スタート] - [管理ツール] - [サーバー マネージャ] をクリックしてサーバー マネージャーを起動します。左ペンインより [機能] をクリックして[機能の追加] のリンクより、機能の追加ウィザードを起動します。
機能 [デスクトップ エクスペリエンス] 横のチェックボックスを選択し、[インストール] をクリックし��す。
* 機能の追加後、再起動が必要です。
本 Blog が少しでも皆様のお役に立てれば幸いです。
KMS ライセンス認証で使用されるボリューム ライセンス用プロダクト キーのプロダクト キー グループの考え方等についてご紹介したいと思います。
なお、本日ご紹介させていただきます内容については、特に明記が無い限りプラットフォーム (x86, x64, IA64) に依存しない内容としてご紹介しております。
また、KMS ライセンス認証そのものについての説明は、以下のブログで紹介させて頂いておりますのでよろしければ合わせてご確認ください。
KMS ライセンス認証は、KMS ホストと呼ばれる端末が KMS クライアントに対してライセンス認証を提供する構成となります。
KMS ライセンス認証用のボリューム ライセンス プロダクト キーはKMS ホストとして構成する端末にインストールするためのプロダクト キーとなりますが、プロダクト キーごとにライセンス認証可能な KMS クライアントの OS が異なります。
上記 KMS ライセンス認証用のボリューム ライセンス プロダクト キーの種類を表す言葉として プロダクト キー グループ という表現が使われます。
現在提供されている KMS ライセンス認証用のプロダクト キーの"プロダクト キー グループ" および "プロダクト キー グループ" ごとにライセンス認証可能な KMS クライアントの OS を 1 つの図にまとめると以下のようになります。
KMS ライセンス認証の "プロダクト キー グループ" は階層構造を取っており、上位の "プロダクト キー グループ" は下位の "プロダクト キー グループ" の内容も含む形になります。
また、上記図における黒字の内容が "プロダクト キー グループ" の名称、白字の内容が該当の "プロダクト キー グループ" のプロダクト キーを使用した場合にライセンス認証が可能な KMS クライアントの種類となります。
※ "Windows Server 2008" と "Windows Server 2008 R2" では "サーバー グループ" という同じ表現を使用しますが、含まれる対象が異なりますのでご注意ください。
上記図では、便宜上左上にカタカナ 1 文字を付与しておりますが、このカタカナ 1 文字を用いて各 "プロダクト キー グループ" ごとにライセンス認証可能な KMS クライアントの組み合わせをまとめると以下のようになります。
例えば、上記 「カ」 の [Windows Server 2008 向け サーバー グループ B] のプロダクト キーでは、下位の [Windows Server 2008 向け サーバー グループ A] と[クライアント (Windows Vista) 用の プロダクト キー グループ] を包含しますので、最終的にライセンス認証可能な KMS クライアントとしては以下となります。
Windows Server 2008 向けサーバー グループ B を使用した場合にライセンス認証が可能な KMS クライアント
また、Windows Server 2008 R2 向け "プロダクト キー グループ" では、同一エディションの Windows Server 2008 についても KMS クライアントとしてライセンス認証を行うことができるようになっています。
例えば、上記 「ウ」 の [Windows Server 2008 R2 向けサーバー グループ A] のプロダクト キーでは、Windows Web Server 2008 R2 とWindows HPC Server 2008 R2 に加え、同一エディションの下位 OS であるWindows Web Server 2008 および Windows HPC Server 2008 についてもKMS クライアントとしてライセンス認証を行う事が可能です。
この事は、上記図内においては 「ウ」 配下に下位 OS の Windows Server 2008 向けのサーバー グループ A である 「キ」 が含まれるように記載する事で表現しています。
上記をふまえ、下位の "プロダクト キー グループ" も含めた最終的にライセンス認証可能な KMS クライアントをまとめると以下のようになります。
Windows Server 2008 R2 向けサーバー グループ A を使用した場合にライセンス認証が可能な KMS クライアント
現在 KMS のバージョンとしては "1.0" "1.1" "1.2" の 3 種類があります。KMS ホストとして構成する場合にはこの KMS バージョンの違いにより使用できる "プロダクト キー グループ" が異なります。
KMS ホストとして構成可能な OS ごとに KMS ホストとして構成した場合の既定の KMS バージョンおよび該当の OS を KMS ライセンス認証でホストする場合に必要な KMS バージョンをまとめると以下のようになります。
例えば Windows 7 の KMS クライアントを KMS ホストで管理する事を考えた場合、KMS のバージョンが "1.2" である必要があります。
また、Windows 7 は既定で KMS 1.2 のため、Windows 7 を KMS ホストとして構成すれば同じく Windows 7 の KMS クライアントを管理する事ができる事になります。
その他の OS については KMS 1.2 用のアップデート モジュールが別途提供されておりますので、これらのモジュールをインストールする事で、その他の OS でも KMS ホストとしてWindows 7 や Windows Server 2008 R2 をホストする事が可能となります。
ただし、原則的にはクライアント用の "プロダクト キー グループ" (クライアント VL) はクライアント OS で使用し、サーバー用 "プロダクト キー グループ" (サーバー グループ) はサーバー OS で使用する必要があります。
つまり、Windows 7 を KMS ホストとして構成した場合に Windows Server 2008 R2 用のプロダクト キーを使用したり、反対に Windows Server 2008 R2 でWindows 7 用のプロダクト キーを使用する事はできません。(Windows Vista および Windows Server 2008 でも同様の考え方となります。)
また、Windows Server 2003 を KMS ホストとして構成する場合は、他の OS を KMS ホストとして構成した場合とは若干扱いが異なり、全ての "プロダクト キー グループ" に対応した KMS ホストとして構成する事が可能です。
Windows Server 2003 の KMS ホストでは 上記表の "ホストする場合に必要な KMS バージョン"と同様に KMS のバージョンによって、以下のようにホスト���能な OS が異なります。
各 OS ごとの KMS 用アップデート モジュールについては以下よりダウンロードが可能となっておりますのでご確認ください。
最後にここまでの内容でご紹介させていただきました "プロダクト キー グループ" ごとのKMS ホストとして構成可能な OS および KMS クライアントとしてライセンス認証可能なOS について、各 OS 向けの "プロダクト キー グループ" ごとに一覧にさせていただきましたのでご確認ください。
最後に今回ご説明いたしました内容について抑えて頂きたいポイントのまとめと参考情報のご紹介をさせていただきます。
参考情報
Determine Product Key Needshttp://technet.microsoft.com/en-us/library/ff793411.aspx
リソース不足について - 第 2 回 では、ページ プールと非ページ プールについて もう少し掘り下げて見ていきたいと思います。
第 1 回と比較をすると細かい内容となりますが、トラブルシュートを行う上では欠かせない要素もいくつかありますので、がんばって進めていくことにしましょう。
割り当てられる領域につける名札について
ページ プールおよび非ページ プール内の領域が、各要求元のドライバに割り当て (Allocate) られる際には、Tag と呼ばれる 1 ～ 4 文字の名札がつけられます。
大抵この Tag には 要求元のドライバにより一意の文字が指定されるので、ドライバのどのような動作の際に確保されたプール (ページ プールもしくは 非ページ プール) なのかを判断する事ができ、この Tag 毎に使用されている値を見る事でプールの枯渇が発生した場合に、どのドライバが “限りあるリソース” を消費しているのかを追跡する事が可能となるのです。ただし、Tag そのものから確保されたプールがページ プールもしくは非ページ プールなのかを判別する事はできません。多くの場合、ページ プールと非ページ プールで共通の Tag が使用されます。
いくつか例を挙げてみますと、、、
MmSt - nt!mm - Mm section object prototype ptes
Ntf? - ntfs.sys - NTFS Specific allocation tags
Cc - nt!cc - Cache Manager allocations (catch-all)
といったものがあります。
これは OS が標準で使用しているものになりますが、各メーカーが開発しているドライバの中には、独自で指定している名前がいくつかあります。
余談ですがプールを確保する時は以下のようなパラメータを指定して Call されます。
PVOID ExAllocatePoolWithTag(
IN POOL_TYPE PoolType,
IN SIZE_T NumberOfBytes,
IN ULONG Tag <<<<<
);
Tag がこの名札にあたるわけですね。ULONG つまり 32-bit 値なので、慣例上 8-bit の ASCII コード 4 文字が使用されます。
また、PoolType でページ プールもしくは非ページ プールの種類を、NumberOfBytes で確保するページの大きさを指定します。
詳しくは以下の Windows Driver Kit の Reference (英語) をご参照ください。
// ExAllocatePoolWithTag
http://msdn.microsoft.com/en-us/library/ms796989.aspx
Tag ごとのプール使用量を確認する方法について
では、さっそく Tag ごとのプール使用量を確認する方法について見ていきましょう。
Debugger を使用して確認を行う方法等もありますが、今回は Poolmon というツールを利用する方法について紹介させていただきたいと思います。
Poolmon は、システムのページ プールと非ページ プールをプール割り当て Tag ごとにグループ化して表示させる事が可能な トラブルシュートには欠かせないツールです。
尚 Windows Server 2003 以降ではプールの Tag 付けは既定で有効になっているため、有効にする必要はありませんが、Windows Server 2003 よりも以前の OS では、プールの Tag 付けを有効にしてコンピュータを再起動する必要があります。
Windows Server 2003 よりも以前の OS で、プールの Tag 付けを有効にするには、gflags.exe を使用するか、レジストリを直接編集してグローバル フラグを設定する必要があります。
Poolmon の利用方法と併せて、プールの Tag 付けを有効にする方法については、技術情報 177415 でも紹介しておりますので、是非ご一読ください。
さて Windows Server 2003 の場合、poolmon は Windows Server 2003 の CD-ROM の \Support\Tools フォルダの中で人知れず眠っています。この保存場所は Windows 2000 と Windows XP の場合でも変わりません。
ここにある Support.CAB を展開すると、Poolmon.exe がいますので、目を覚ましてもらう事にしましょう。
(こう書くとちょっと怪しい技術書風になりますね)。
使用方法は至って簡単です。コマンド プロンプトの画面で、Support.CAB ファイルを展開したフォルダまで cd コマンドで移動して poolmon.exe と実行するだけです。
ちなみにコマンド プロンプトの画面は既定では小さなウインドウのため、[簡易編集モード] や [挿入モード] の有効化と、レイアウトの横と縦のバッファは十分な値を設定する事をお勧めします。この辺は好みに合わせてプロパティから変更してください。
私は コマンド プロンプトを使用する機会が多く、前に入力したコマンドが見えなくなってしまうのが困るので、縦が 9999、横が 200 くらいのバッファを指定していつも使ってます。こうすると全画面表示にも対応できる位のサイズになり、おかしな改行が入らないので非常に重宝します。
では さっそく Poolmon.exe を実行して、、、といきたいところですが、その前に第 1 回目の内容の復習も兼ねて実際に発生している問題のトラブルシュートを一緒に行っていきたいと思います。
まずは用意をしたテスト環境で前回ご紹介いたしました Memory\Pool NonPaged Bytes もしくは Memory\Pool Paged Bytes を見ていきます。
するとこの環境では、以下のように Pool Nonpaged Bytes が右肩上がりに上昇している事がわかりました。これだけで判断するには短期間過ぎではありますが、非ページプールが右肩上がりに上昇していて、リークが発生しているように見受けられます。
非ページ プールがリークしている可能性がある事がわかりましたので、ここからは実際に poolmon を使用して 非ページ プールを使用しているドライバを特定していきます。
コマンド プロンプト上で poolmon.exe と入力して実行すると、コマンド プロンプト上で以下のような画面が表示されたと思います。
この状態で 2 番目の列 "type" に "Nonp" という値が表示されるまで P キーを押します。
そして B キーを押すと、列の値が降順 (最大バイト利用数の順) で並べ替えられます。
簡易編集モードが有効の場合には、画面全体を選択してから右クリックをする事でコピーする事が出来ますので、そのまま notepad 等のテキスト エディタに張り付けます。この繰り返しで、そのタイミングの Tag 毎のプールの利用状況を残す事が出来ます。Poolmon.exe には、B の他にも出力を並べ替えるキーが 技術情報 177415 で紹介されてますので、目的に合わせてソートするようにしてください。
スナップショットはありませんが上の MeHE という Tag の使用量 (Bytes) が時間を追うごとに増えていることがわかります。ソートをしなおしても同じように増加をしていく Tag が無いため、全体量である Pool NonPaged Bytes を増加させていたのは、MeHE Tag である事がわかりました。
では 続いてこのドライバが何なのかを確認する事にしましょう。
Driver を特定する方法について
サードパーティ製のドライバによって使用されているプール Tag からドライバを特定する場合には、標準のコマンド “findstr” が大活躍します。
このコマンドを利用して各ドライバのバイナリ データから文字列を検索し、Tag 名と同じ文字列が含まれているドライバをある程度洗い出す事が出来るんですね。
サードパーティ製のドライバによって使用されているプール Tag の検索方法については、技術情報 298102 でも紹介しておりますので併せてご参照ください。
今回は MeHE という Tag で割り当てられた非ページ プールが時間を追う毎に増加しているような状況でしたので、MeHE という Tag を使っているドライバを特定したいと思います。
では早速実行してみましょう。
以下のコマンドを %systemroot%\system32\drivers 内のドライバに対して実行します。
> C:\Windows\System32\drivers>findstr /m /l MeHE *.sys
/m でファイルに一致する行があるときに、ファイル名のみを出力し、/l で検索文字列をリテラルとして使用、そして *.sys でドライバを指定しているといった塩梅です。検索を実行すると、実行後以下の結果が返されてきました。
> Sheep.SYS
この結果からは、Sheep.SYS に MeHE という文字列が含まれている事がわかりましたので、Sheep.SYS が非ページ プールを割り当てる際に、MeHE という Tag を使用している可能性がある事がわかりました。
今回は意図的にリークが発生するように実装したドライバ (Sheep.sys) を使用してテストを行いましたので、結果としてドライバの特定まで出来て大成功という事になります。
// 補足
コマンドからだけでは無く、Tag を使用してエクスプローラからの検索も行う事が出来ますので是非お試しください。
ちなみにファイルの場所は drivers 配下だけではなく、%SystemRoot%、%ProgramFiles%、%SystemDrive%、%ProgramData% などのより広い範囲を対象として実行するなど、より包括的な検索を行わなければドライバを特定できない可能性があります。
drivers 配下に無い場合には、色々なフォルダ内を確認いただければと思います。
Driver が特定出来たらどうするか
Driver が特定出来たらどうするか ですが、自分で Driver を書いている方であればそのまま修正のコードを入れる事も出来ますが、簡単に修正を入れる事が出来ない方のほうが大多数かと思います。その場合には、もしリークが発生していた場合には、回避策としては再起動しかありません。
後はドライバの提供元にご相談をしていただき、解放漏れがある処理が無いかを確認してもらい、その部分が修正したモジュールを提供いただく他には無いので、リソース不足からドライバの特定ができた場合には、まずは提供元のメーカーにご相談いただくのが一番確実な対応策になります。
切り分け方法としては findstr 等で特定していただいたドライバを一時的に無効にして現象に変化が無いかを確認したり、更新された最新のドライバがあれば最新版のモジュールをインストールして確認を行ったりといろいろとありますが、まずは最新版のモジュールに更新していただくのが良いかと思います。
既に修正されている可能性があり、一番効率的なトラブルシュートなため、存在するかもわからない場合には提供元のメーカーにご相談ください。
注意事項
ちなみに一番多く使用しているから悪いのか？と言われるとそうでも無いのが困ったところでもあります。
うっかりだまされてしまうと、なかなか問題の解決に至らずに取り返しのつかない事にもなりかねません。
実はどのドライバがリークを引き起こしているのか、もしくは問題があるのかというのは、私たちも判断が非常に難しい時があります。
椅子取りゲームよろしく 共有されているリソースを取り合っているだけなので、実は確保している事に問題が無いとか、そのタイミングでは絶対に必要なので、むしろ他の部分でトリミングを行わなければいけないといったような事があるために、ただ一番多く消費しているからといって、問題ではない場合もありますのでご注意ください。
最後に
第 2 回まででページ プールと非ページ プールについてざっくりとではありますが、確保しているドライバの特定方法も含めて踏み込んだ解説をさせていただきました。
ボリュームが大きく わかりづらい内容ではありますが、詳細なトラブルシュートをする上では理解しておく必要がある部分ではありますので、実際に問題があった時などにここで紹介させていただいた事を思い出していただければと思います。
次回の第 3 回では、第 1 回で少し触れました ページ プールと非ページ プールの最大値を確認する方法についてと、Windows Vista と Windows Server 2008 でのページ プールと非ページ プールについてを紹介させていただこうかと思います。
Windows Vista 以降ではいろいろと変更があり、寂しい限り？ですがリソースの枯渇という事もあまり聞かなくなりました。そんな Windows Vista 以降の OS で、ページ プールと非ページ プールについてを中心に第 3 回は紹介させていただきますのでどうぞご期待ください。
~ 第 3 回 へつづく ~
- リソース不足について - 第 1 回
- リソース不足について - 第 2 回（今回）
こんにちは。Windows プラットフォーム サポートの石田です。
最近、ローカル ドライブに保存されているシャドウ コピーのデータを削除したいが行えないというお問い合わせをいただきました。実は、シャドウコピーにはいくつかの種類があり、特定のシャドウ コピーに対しては特定のツールを使わないと削除できない場合があります。いただいたお問い合わせの現象や背景を踏まえて解説します。
現象
==========
Windows Server 2008 や Windows Server 2008 R2 にて、ローカル ドライブにバックアップデータを保管している。
共有フォルダへのバックアップとは異なり、複数のバージョンのバックアップ データが保管されていることを確認した。空き領域の確保のため古いシャドウ コピーを vssadmin delete shadows コマンドで削除しようとしたが、バックアップにより作成されたシャドウ コピーは削除されなかった。
まずはじめに、シャドウ コピーの種類と vssadmin delete shadows コマンドにてシャドウ コピーが削除されなかった理由について説明します。
シャドウ コピーの種類について
=================================
vssadmin list shadows コマンドにて確認できるシャドウ コピーには大きく分けて以下の 2 つの種類があります。
a. 共有フォルダーのシャドウ コピー機能の利用により作成されるシャドウ コピー
b. アプリケーションなどからの要求で作成されるシャドウ コピー
※ Windows Server バックアップで作成されるシャドウ コピーは b. に分類されます。
vssadmin delete shadows にて、削除可能なのは、a. のシャドウ コピーです。
一方、 b. のアプリケーションなどからの要求にて作成されるシャドウ コピーを明示的に削除するには、diskshadow ユーティリティを利用します。
シャドウ コピーが残る理由について
Windows Server バックアップにて、ローカル ドライブにバックアップを取得すると最新の世代は VHD ファイルとして保存されます。この時、バックアップ データの世代管理のために、バックアップの保存先にシャドウ コピーが作成されます。こちらは、世代管理に使用されており、バックアップ後に削除されないためにこの現象が発生します。
バックアップの保存先の違いについては、以下の参考資料を参照してください。
- 参考情報
Windows Server のバックアップ まとめ
http://blogs.technet.com/b/infrajp/archive/2011/03/18/windows-server.aspx
Windows Server バックアップの概要
http://technet.microsoft.com/ja-jp/library/cc732091.aspx
保管されるシャドウ コピーの合計サイズは、シャドウ コピー記憶域の最大サイズの設定により異なります。この現象を回避するには、最大サイズの設定を “制限なし” から ”制限値” に変更し、任意のサイズを設定することにより、空き領域を確保することが可能です。
但し、シャドウ コピー記憶域の最大サイズの設定をする際には、運用にあわせた見積もりが必要なため、何か他に対応はないか。という疑問が発生します。そのため、一時的に diskshadow コマンドにてシャドウ コピーを削除して空き領域を確保する方法をご紹介します。
シャドウ コピー削除手順について
diskshadow ユーティリティは Windows Server 2008 以降に標準で実装されています。
Windows Server 2003 や Windows 7 ではこの方法は利用できません。
1. 管理者権限にてコマンド プロンプトを起動します。
2. diskshadow と入力し diskshadow ユーティリティを起動します。
3. 削除したいシャドウ コピーにあわせ delete shadows コマンドを実行します。
以下に削除の実行例をご案内します。
実行例 1)
S ドライブの一番古いシャドウ コピーから 1 世代ずつ削除する場合は delete shadows oldest コマンドを実行します。
>diskshadow
>delete shadows oldest S:
実行例 2)
S ドライブの全てのシャドウ コピーを削除する場合には delete shadows volumeコマンドを実行します。
>delete shadows volume S:
実行例 3)
特定のシャドウ コピーを削除するには delete shadows SET <セット ID> や delete shadows ID <シャドウ ID> コマンドを利用します。
<セット ID> や <シャドウ ID> に指定する値は list shadows all コマンドにて確認が可能です。
各コマンドの詳細については、delete /? にてヘルプを参照するか、以下の参考情報を参照してください。
Delete shadows
http://technet.microsoft.com/en-us/library/cc754915(v=ws.10).aspx
Diskshadow
http://technet.microsoft.com/en-us/library/cc772172(v=ws.10).aspx
こんばんは。Windows テクノロジー サポートの吉井です。
今日は、Windows 7 の展開の際、Sysprep を実施したイメージのミニ セットアップにて、新規ユーザーの作成をスキップする方法についてご紹介します。
Sysprep されたイメージを初めて起動すると、ミニ セットアップと呼ばれる OS の新規インストール時と似た初期設定画面が表示されます。ここでは言語、時刻の設定や、新規ユーザーの作成、ネットワークの設定などを行います。
既定では、このミニ セットアップにて新規ユーザーを作成する必要がありますが、"応答ファイル" と呼ばれる設定ファイルを使用することで、ミニ セットアップにおけるユーザー作成をスキップすることができます。
(※ ただし、ユーザーが一人もいない状況になってしまうと誰もログオンできなくなりますので、そういった状況にならないよう注意してください。)
"応答ファイル" はこれまでも数回このブログで紹介していますが、弊社のダウンロード センターにある Windows 自動インストール キット (AIK) 内に含まれる Windows システム イメージ マネージャー (SIM) を用いて作成することができます。
以下に、新規ユーザー作成をスキップする方法について、Windows AIK の入手とインストールから、応答ファイルの作成、及び、Sysprep の実行まで一通り説明します。
Windows AIK は以下のサイトよりダウンロード可能です。
Windows 7 用の Windows 自動インストール キット (AIK) http://www.microsoft.com/downloads/details.aspx?familyid=696DD665-9F76-4177-A811-39C26D3B3B34&displaylang=ja
Windows AIK のインストール手順は、次の技術情報をご覧ください。
4. ステップ 1. テクニシャン コンピューターの準備 http://technet.microsoft.com/ja-jp/windows/ee676464.aspx "1.1. Windows 自動インストール キット (Windows AIK) のインストール" に 手順が記載されています。(1.2 以降の作業は今回は実施の必要はありません。)
1. スタート メニューから [Windows システム イメージ マネージャー] を開きます。
2. Windows システム イメージ マネージャーが起動します。 [Windows イメージ] ペインの、[Windows イメージまたはカタログ ファイルを指定してください] を右クリックし、[Windows イメージの選択] をクリックします。
3. [Windows イメージの選択] が表示されます。 Windows 7 のインストール メディアを DVD ドライブに挿入し、DVD 内の Sources フォルダー内にある Install.wim または、.clg の拡張子を持つ カタログ ファイルを選択し、[開く] をクリックします。
※ Install.wim を使用する場合は、一旦ローカル ディスク上に Install.wim ファイルをコピーし、ローカル ディスク上にある Install.wim を開いてください。
4. 次に、[応答ファイル] ペインで、[応答ファイルを作成または開きます] を右クリックし、[新しい応答ファイル] をクリックします。
5. 応答ファイルに対して、コンポーネントを追加します。 [Windows イメージ] ペインに設定項目 (コンポーネント) がリストされています。 今回は、[Windows イメージ] ペインから、[Components] を展開し、[Microsoft-Windows-Shell-Setup_neutral (※)] - [UserAccounts] - [LocalAccounts] - [LocalAcount] を右クリックし、[パス 7 oobeSystem に設定を追加] をクリックします。
※ なお、コンポーネントの名称の Microsoft-Windows-Shell-Setup の前には x86 または amd64 の接頭語がつきます。また、後ろにはバージョン番号が記載されていますので、適宜お読み替えください。
6. [応答ファイル] ペインに、[Microsoft-Windows-Shell-Setup_neutral] が追加されます。 [応答ファイル] ペインの [7 oobeSystem] - [Microsoft-Windows-Shell-Setup_neutral] - [UserAccounts] - [LocalAccounts] - [LocalAccount] をクリックします。
7. [LocalAccount プロパティ] ペインが表示されます。 [LocalAccount プロパティ] の [設定] 項目で以下を設定します。 Group : Administrators Name : Administrator
8. [Windows システム イメージ マネージャー] の [ファイル] メニューから、 [名前を付けて保存] をクリックし、任意の名前をつけて応答ファイルを保存します。 (例: unattend.xml 等の名称で保存します。)
参考イメージ
- 参考資料 LocalAccounts http://technet.microsoft.com/ja-jp/library/ff715535(en-us,WS.10).aspx
LocalAccount http://technet.microsoft.com/ja-jp/library/ff715847(en-us,WS.10).aspx
なお、Windows 7 では既定で Administrator アカウントが無効化されていますが、この手順は Administrator アカウントが無効の状態でも有効です。また、Administrator アカウントが自動的に有効化されることもありません。
作成した応答ファイルを指定して、Sysprep を実行するには、以下のコマンドを実行します。
1. コマンド プロンプトを管理者権限で起動します。2. 以下のコマンドを実行します。%systemroot%\System32\Sysprep\sysprep.exe /oobe /generalize /unattend:<応答ファイルのパス>例: %systemroot%\System32\Sysprep\sysprep.exe /oobe /generalize /unattend:unattend.xml
なお、応答ファイルはその他の方法でも指定できます。詳細は以下の資料を参照してください。
Windows セットアップの実行方法 http://technet.microsoft.com/ja-jp/library/dd744269(WS.10).aspx
上記手順 2-5 にて、以下の Technet の記載されているコンポーネントを追加して設定することで、ミニ セットアップ全体をスキップすることも可能です。よろしければご参照ください。
[Windows へようこそ] を自動化する http://technet.microsoft.com/ja-jp/library/dd744547(WS.10).aspx
- その他参考資料 Sysprep とは http://technet.microsoft.com/ja-jp/library/cc721940(WS.10).aspx
Windows 7 展開センター http://technet.microsoft.com/ja-jp/windows/ee517406.aspx
Windows 7 標準クライアント イメージの作成手順 http://technet.microsoft.com/ja-jp/windows/ee676462.aspx
こんにちは。Windows テクノロジー サポートの吉井です。
今日は弊社より提供している以下の Process Monitor ツールに関して、いくつかの Tips をご紹介しようと思います。
Process Monitor
http://technet.microsoft.com/ja-jp/sysinternals/bb896645.aspx
Process Monitor はファイル システム、レジストリ、プロセス、スレッド、およびネットワークの活動をリアルタイムで表示、記録する監視ツールです。
ファイル、レジストリに対するアクセスエラー発生箇所の特定や、書き換えを行ったプロセスの特定などが行える便利なツールでして、私たちも日常のトラブル シュートでよく利用しています。
非常に強力かつ汎用的なツールで、普通に使うだけでも重宝するのですが、以下により活用いただくために便利機能をいくつかご紹介させていただこうと思います。
Tip 1. システム起動時に情報を取る方法
システム起動時などで、Process Monitor の対面操作が間に合わない場合にも [Enable Boot Logging] オプションを利用することでシステム起動時のアクティビティを記録することができます。
起動の初期段階で発生する問題等の調査の場合にご利用ください。
- 使用手順
1. Procmon.exe を実行し、[Option] から [Enable Boot Logging] をクリックします。
2. [Process Monitor is configured to log activity during the next boot.] のポップアップで [OK] をクリックします。
3. システムを再起動し、ログオンします。
4. システムの起動後、再度 Procmon.exe を実行すると、以下の内容のポップアップが表示されますので、[はい] をクリックすると、イベントを保存できます。
A log of boot-time activity was created by a previous instance of Process Monitor. Do you wish to save the collected datat now?
Tip 2. イベントの保存をフィルターする方法
Process Monitor では、プログラム起動時などにイベントをフィルターする設定が表示されますが、このフィルターは表示上のフィルターであり、実際にはフィルターされたイベントも記録しています。
そのため、後からフィルターされていたイベントについてもフィルター設定を変えることで参照できます。
ただ、PML ファイルに保存するときなどに莫大な量になる場合もあるので、場合によってはすべてのイベントを保存したくない場合もあると思います。
その場合には [Filter] - [Drop Filtered Events] のチェックをオンにすると、フィルターされたイベントは保存されず破棄 (Drop) されます。
破棄することで過去のイベントは見えなくなりますので、その点についてはご注意ください。
Tip 3. コマンド ラインからフィルター設定した状態で開始/停止する方法
Process Monitor ではフィルター設定や上記 Drop Filtered Events のオン/オフ等を含む設定状態をエクスポートすることができます。
このエクスポートしたファイルを指定して起動することで、フィルターを適用した状態で Process Monitor を開始することができます。
- 設定のエクスポート方法について
1. Process Monitor を開始し、フィルターなどの設定を行います。
2. [File] - [Export Configration...] を選択します。
3. 保存ダイアログが表示されますので、設定ファイル名前をつけて保存します。
設定されたファイルは PMC (Procmon Configuration) 形式で保存されます。
この設定エクスポートしたファイルを /loadconfig オプションで指定して起動することでフィルターを適用した状態で起動できます。
これらを利用して、コマンドラインから Process Monitor をある程度制御することが可能です。
コマンドでフィルターを指定した上で自動で採取を開始し、かつ、任意のファイルにログするには以下のコマンドを利用します。
> procmon.exe /AcceptEula /quiet /backingfile <ファイル名> /minimized /loadconfig <PMC ファイル名>
<ファイル名> にはログファイル名を指定します。(なお、/AcceptEula オプションは EULA へ同意いただく意味になります。)
例 > Procmon.exe /AcceptEula /quiet /backingfile c:\log.pml /minimized /loadconfig c:\ProcmonConfiguration.pmc
Process Monitor をコマンド ラインから停止するには以下のコマンドを利用します。
> procmon.exe /terminate
PMC ファイルを作成した上で、上記コマンドとタスク スケジューラ等を組み合わせることで指定期間の自動採取等も可能です。
ただし、頻繁なアクティビティがある状況で Process Monitor を使用した場合、ログ ファイルが巨大になる危険性がありますので、十分にご注意ください。
Tip 4. スタックを確認する方法
Process Monitor 上で、イベントをダブル クリックするとプロパティ画面が表示されますが、ここに "Stack" タブがあります。
このタブではこのイベントが記録された際のスタックについての情報を参照できます。
ただ、通常ですとモジュール名 + オフセットとなってしまい、細かな情報は取得できません。
これにデバッグ シンボル情報を組み合わせると処理関数名 + オフセットまで知ることができます。
シンボルを設定するには、以下の手順を実行します。
1. Debugging Tools for Windows をインストールします。
シンボルを利用するには以下の Debugging Tools for Windows が必要ですので、
下記の URL から Debugging Tools for Windows をインストールします。
Windows 用デバッグ ツール: 概要
http://www.microsoft.com/japan/whdc/DevTools/Debugging/default.mspx
2. Process Monitor で設定を行います。
メニューから [Options] - [Configure Symbols] を選択します。
設定画面が表示されますので、以下を設定します。
Dbghelp.dll path : <Debugging Tools for Windows のインストール フォルダ>\dbghelp.dll
Symbols path : srv*http://msdl.microsoft.com/download/symbols
"Dbghelp.dll path" には、Debugging Tools for Windows のインストール
フォルダ配下にある dbghelp.dll を指定してください。
例 : C:\Program Files\Debugging Tools for Windows\dbghelp.dll
Symbols path の http://msdl.microsoft.com/download/symbols は弊社のシンボル サーバーです。ローカルに シンボル ファイル (pdb ファイル) がある場合などには、; (セミコロン) で区切って追加することもできます。
以下にシンボルを解決した場合の表示サンプルをご紹介します。
サンプルとして、SampleProgram.exe の SampleFunction() から CreateFile 関数を読んだイベントを使っています。
シンボル利用後
シンボル利用前
こんにちは。Windows テクノロジー サポートの高橋です。
今回は Windows Vista 以降の OS (Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2) で Sysprep を実行した際にドメインへ自動参加させるための方法について紹介したいと思います。
Windows AIK をご利用の方であれば、応答ファイルの Microsoft-Windows-UnattendJoin コンポーネントを使用してドメインへの参加が自動化できることをご存知かも知れません。ただし、このコンポーネントは specialize パスで処理されるため、ミニ セットアップ中 (oobeSystem パス) に入力したコンピューター名ではなく、セットアップ中に一時的に割り当てられたコンピューター名でドメインへの参加が行われてしまいます。
注: Windows Server 2008 R2 では、ミニ セットアップ中にコンピューター名を入力するように構成することはできません。このため、Windows Server 2008 R2 については応答ファイルの Microsoft-Windows-UnattendJoin コンポーネントを使用してドメインへ参加させても、上述の問題は発生しません。ユーザー指定の任意のコンピューター名を設定するには、セットアップ完了後にコンピューター名を変更する必要があります。
従いまして、Microsoft-Windows-Shell-Setup コンポーネントの ComputerName プロパティで明示的にコンピューター名を指定するか、または '*' を指定して自動生成されたコンピューター名を使用する場合以外、応答ファイルによるドメインへの参加は期待通り動作しません。言い換えますと、ミニ セットアップ中に入力したコンピューター名が反映された形でドメイン参加を行う場合、応答ファイルの Microsoft-Windows-UnattendJoin コンポーネントを使用することはできません。
上記につきましては、以下のサポート技術情報に記載させていた だいている通り、想定された動作であり、 Microsoft-Windows-UnattendJoin コンポーネントの制限事項となります。
回避策としては、上記サポート技術情報に記載されている通り、Microsoft-Windows-Shell-Setup コンポーネントの FirstLogonCommands を構成し、コンピューターをドメインに参加させるスクリプトを実行させる、という方法が一つの方法となります。ただし、運用上 FirstLogonCommands が使用できない (セットアップ完了後、管理者権限を持ったアカウントでログオンを行う事が保証されない) 場合や、ユーザー側に処理を見せたくない場合もあると思います。そこで、ここでは SetupComplete.cmd を利用した方法を紹介したいと思います。
SetupComplete.cmd の利用方法そのものにつきましては、以前安達が公開させていただいた以下のポストをご参照下さい。
ドメインへの参加自体は、KB944353 同様 Win32_ComputerSystem WMI クラスの JoinDomainOrWorkgroup メソッドを利用しますが、ここではバッチ ファイルから直接呼び出すため、wmic.exe コマンドライン ユーティリティを使用します。 wmic.exe を使用して JoinDomainOrWorkgroup メソッドを呼び出すための書式は以下の通りです。
ここで、<ドメイン名> は参加させたいドメイン名、<ユーザー名> および <パスワード> はドメイン参加の際に使用する認証情報、 <OU> は所属させたい OU 名 (省略可能)、<オプション> はドメイン参加時のオプション (省略時は 1) です。 JoinDomainOrWorkgroup メソッドの詳細につきましては、JoinDomainOrWorkgroup Method of the Win32_ComputerSystem Class をご参照下さい。
以下は、TestDomain.local.com ドメインの TestOU OU へ参加させる場合のサンプルです。
※ AccountOU パラメータで OU を指定する場合、Distinguished Name の区切り文字に ',' (カンマ) ではなく ';' (セミコロン) を使用してください。カンマを使用すると wmic.exe がコマンド パラメータの区切り文字として認識してしまうため、コマンドが期待通り動作しません (2014/2/26 修正)。
なお、上記内容の SetupComplete.cmd ファイルをそのまま残すと、ドメイン参加に使用したアカウント情報が他のユーザーから参照できてしまいます。SetupComplete.cmd 実行完了時に同ファイルを削除するようにするには、 SetupComplete.cmd の最後に以下の一行を入れます。
以上、Sysprep を使用して OS を展開する際の参考にしていただければ幸いです。
こんにちは、Windows サポートの新川です。
ゲスト OS のメモリ使用状況について、以下のご質問をいただく事があります。
これらは、そのゲスト OS のメモリ管理を “動的” に設定されているのであれば、バルーニング と呼ばれる仕組みによって発生しているものが大半を占めます。今回は、バルーニングの見え方について少しお話しします。
■ Dynamic Memoryの実装
まずはバルーニングの前に Dynamic Memory についての説明です。Windows Server 2008 R2 SP1 より、Hot Add Memory が可能なゲスト OS に対して、Hyper-V ホストからシステム稼働中に動的に物理メモリを割り当てる事が可能になりました。この機能により、ゲスト OS に割り当てられるメモリが動的に最適化出来るようになっています。ただし、Dynamic Memory のゲスト OS の要件には、Hot Add Memory というのはありますが、Hot Remove Memoryというのはありません。つまり、ゲスト OS は “動的に物理メモリを追加” さえサポートしていれば、”動的に物理メモリを削除” する事をサポートされていなくても、Hyper-V ホストはゲスト OS から使っていない物理メモリを回収しているという事になります。(Hyper-V Dynamic Memoryメモリの要求要件についての詳細は 、Hyper-V Dynamic Memory Configuration Guide をご参照ください。)
■ Hyper-V ホストはどのようにしてゲスト OS から物理メモリを回収するか。
それでは、Hyper-V ホストはどのようにゲスト OS から物理メモリを回収しているのでしょうか。実は、Dynamic Memory については既に詳細について記載されたホワイトペーパーが公開されており、Dynamic Memory Technical Overview whitepaper (英語) と Dynamic Memory の実装と構成 (日本語) – ベータ版 からダウンロード可能です。他にも Tech・Ed Japan 2010 の Effective Hyper-V R2 SP1 ～ 詳説 Dynamic Memory ～ には、Hyper-V 以外の製品との比較も含めて非常に細かく書かれています。簡単に説明すると、SP1 で新しくなった Hyper-V ホストの VSP (Virtual Service Provider) とゲスト OS の VSC (Virtual Service Client) で、ゲスト OS の物理メモリのニーズの判断や割り当てを行っています。
ゲスト OS から物理メモリの回収は、ゲスト OS 上で物理メモリを減らすのではなく、特定のメモリ ページにゲスト OS からアクセス出来ない状態にする事で実現します。この領域は、再びゲスト OS の物理メモリ使用量があがって必要になった場合は小さくなり、そのゲスト OS で利用可能な物理メモリ量が増えます。反対に、ゲスト OS で必要な物理メモリ量が減れば、このページは大きくなります。風船のように膨らんだり萎んだりする事から、この仕組がバルーニングと呼ばれています。
■ バルーニングの様子は、メモリ監視をしているとどのように見えるか。
それでは、動的メモリを意識せず、ゲスト OS 上のみでメモリ使用状況を監視していた場合、どのように見えるか確認してみましょう。この環境では、Windows の限界に挑むシリーズのMark’s ブログ でも利用されている testlimit ツール (こちらからダウンロード可能です)にて、大量にメモリを予約するテストを行った後、プロセスが停止してしばらく時間が経過しています。Hyper-V コンソールで確認すると、現在は 768MB が割り当てられています。
それでは、ゲスト OS 内の状況を確認してみましょう。まずは、ゲスト OS のタスクマネージャーを見てみます。以下のように搭載物理メモリが 6,981 MBで、うち 6.57GB (6,727 MB) が利用中となっています。
上記から、カーネル メモリの使用量が非常に少ないことは見えますが、プロセス タブを開いても、使用量の多いプロセスは見つかりません。
次に、ゲスト OS 上のパフォーマンス モニタです。Available Bytes が大きく増減していますが、物理メモリの内訳になりそうな、Pool NonPaged Bytes や Cache Bytes (= System Cache Resident Bytes + System Driver Resident Bytes + System Code Resident Bytes + Pool Paged Resident Bytes のカウンターの合計) や、Process\Working Set で全プロセスの合計を見ても、同じ単位での動きがありません。Committed Bytes が大きく上がっている事は見えますが、これだけでは何に使っているのかがわかりません。
更に、ゲスト OS 内で RAMMap ツールを用いるともう少し内訳が見え、Driver Locked が 6,229,244 KB (≒ 6083 MB ≒ 5.94 GB) を占めている事がわかります。しかし、これ以上の詳細は掴むことが出来ません。
(なお、RAMMap を動かした際にこのゲスト OS への物理メモリの割り当てが少し増えてしまったため、バルーニングのサイズは小さくなっています)
■ 動的メモリ割り当て状況を確認する方法
上述の通り、ゲスト OS 内だけでメモリ使用状況を確認しても、実際にゲスト OS 内でメモリ使用量があがって枯渇しかけているのか、バルーニングの動作で使用量が上がっているように見えるのか、判断が付きませんでした。これについてはHyper-V ホストで以下のカウンタなどが追加されているため、このカウンタから確認が可能です。
Hyper-V Dynamic Memory VM カウンタの中で、Hyper-V Dynamic Memory VM\Physical Memory というインスタンスが実際にゲスト OS に割り当てられているメモリサイズです。今回の例では、一時的に 6,982 MB (≒ 6.8GB) が割り当てられ、その後すぐに割り当てが 826 MB まで減っている事が確認出来ます。今後、物理メモリの利用状況を監視されている環境で動的メモリをご利用になる場合は、Hyper-V ホストのパフォーマンス ログも同時に取得ください。
■ おまけ。ゲスト OS のメモリ ダンプなどからバルーニングを認識出来るか？
ゲスト OS のメモリ ダンプしかない状況で、バルーニングによって利用されている事が特定出来るか確認してみます。
物理メモリの利用状況の確認には !memusage コマンドが用いられますが、以下のように AWE で 6,273,624 KB (≒ 6127 MB ≒ 5.98 GB ) 使用中となっています。
kd> !memusageloading PFN databaseloading (100% complete)Compiling memory usage data (99% Complete). Zeroed: 48307 (193228 kb) Free: 5 ( 20 kb) Standby: 19724 ( 78896 kb) Modified: 821 ( 3284 kb) ModifiedNoWrite: 0 ( 0 kb) Active/Valid: 1713940 (6855760 kb) Transition: 2 ( 8 kb) Bad: 383 ( 1532 kb) Unknown: 0 ( 0 kb) TOTAL: 1782799 (7131196 kb) Building kernel map Finished building kernel mapScanning PFN database - (100% complete)
Usage Summary (in Kb):Control Valid Standby Dirty Shared Locked PageTables nameffffffffffffd 6273624 0 0 0 0 0 AWEfffffa80308a69c0 1056 160 0 956 0 0 mapped_file( ntdll.dll )fffffa8031297690 4988 6080 0 0 0 0 mapped_file( System.ServiceModel.ni.dll )fffffa8030884ce0 100 696 4 0 0 0 mapped_file( $BitMap )fffffa80308a5e30 48 636 0 0 0 0 mapped_file( ntdll.dll )fffffa80327979d0 76 96 0 0 0 0 mapped_file( werconcpl.dll )fffffa8030881930 64 1896 0 0 0 0 mapped_file( $LogFile )fffffa80312d98b0 108 636 0 0 0 0 mapped_file( ntfrs.exe )fffffa803088ba50 4 0 0 0 0 0 No Name for File:-------- 0 0 0 ----- 0 ----- driver ( RDPDD.dll )-------- 436 16 0 ----- 0 ----- driver ( spsys.sys )-------- 56 0 0 ----- 0 ----- driver ( crashdmp.sys )-------- 48 0 0 ----- 0 ----- driver ( dump_ataport.sys )-------- 36 0 0 ----- 0 ----- driver ( dump_atapi.sys )-------- 67840 4 0 ----- 1048 160 ( Paged Pool )-------- 5820 156 1512 ----- 0 140 ( Kernel Stacks )-------- 42540 0 0 ----- 0 160 ( NonPaged Pool )-------- 188 0 0 ----- 0 24 ( System Working Set Structures )Summary 6855760 78904 3284 40764 75444 13432 Total
しかし、念のため AWE について確認しても、明示的に AWE を使っているプロセスはありません。
kd> !for_each_process "dt _eprocess @#Process AweInfo"nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null):nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null) nt!_EPROCESS +0x388 AweInfo : (null)
実は、!memusage コマンドで AWE フレームと認識されている領域には MDL で確保された領域が含まれるため、MmAllocatePagesForMdl などで確保された場合にもこのような結果になります。(RAMMap ではその点を正しく認識して表示しているので、AWE ではなく “Driver Locked” と表示されます)
残念ながら MDL 領域は、Pool のようにどのドライバから要求されたものかを確認する方法がないので、メモリダンプでも特定は困難です。下記のように MDL を使う可能性があるドライバを探しても複数あり、ここから黄色マークの dmsvc.sys によって確保された事を裏付ける事が出来ません。
kd> x nt!MmAllocatePagesForMdl*fffff800`015ef9a0 nt!MmAllocatePagesForMdl = <no type information>fffff800`015ef900 nt!MmAllocatePagesForMdlEx = <no type information>
// ドライバ内に nt!MmAllocatePagesForMdl のアドレス (fffff800`015ef9a0) が含まれており、MmAllocatePagesForMdl を使っている可能性があるもの (抜粋)
kd> !for_each_module ".echo ${@#ModuleName} ;s -q ${@#ModuleName} L?${@#Size} fffff800`015ef9a0"halfffff800`0142b098 fffff800`015ef9a0 fffff800`01473f04ntfffff800`0199e928 fffff800`015ef9a0 fffff800`0199c8a8CIfffff880`011ed0c0 fffff800`015ef9a0 fffff800`0155d420NDISfffff880`011ed0c0 fffff800`015ef9a0 fffff800`0155d420msrpcfffff880`011ed0c0 fffff800`015ef9a0 fffff800`0155d420ACPIfffff880`011ed0c0 fffff800`015ef9a0 fffff800`0155d420pcifffff880`011ed0c0 fffff800`015ef9a0 fffff800`0155d420Wdf01000fffff880`011ed0c0 fffff800`015ef9a0 fffff800`0155d420WDFLDRfffff880`011ed0c0 fffff800`015ef9a0 fffff800`0155d420vmbusfffff880`011ed0c0 fffff800`015ef9a0 fffff800`0155d420winhvfffff880`011ed0c0 fffff800`015ef9a0 fffff800`0155d420Ntfsfffff880`01992470 fffff800`015ef9a0 fffff800`018e2780tcpipfffff880`01992470 fffff800`015ef9a0 fffff800`018e2780fwpkclntfffff880`01992470 fffff800`015ef9a0 fffff800`018e2780volsnapfffff880`01992470 fffff800`015ef9a0 fffff800`018e2780CLASSPNPfffff880`01992470 fffff800`015ef9a0 fffff800`018e2780cdromfffff880`01992470 fffff800`015ef9a0 fffff800`018e2780dfsfffff880`01992470 fffff800`015ef9a0 fffff800`018e2780Nullfffff880`01992470 fffff800`015ef9a0 fffff800`018e2780vgafffff880`01992470 fffff800`015ef9a0 fffff800`018e2780VIDEOPRTfffff880`01992470 fffff800`015ef9a0 fffff800`018e2780rdbssfffff880`02858470 fffff800`015ef9a0 fffff800`015c4d40netbtfffff880`02858470 fffff800`015ef9a0 fffff800`015c4d40pacerfffff880`02858470 fffff800`015ef9a0 fffff800`015c4d40serialfffff880`02858470 fffff800`015ef9a0 fffff800`015c4d40blbdrivefffff880`02858470 fffff800`015ef9a0 fffff800`015c4d40raspptpfffff880`02858470 fffff800`015ef9a0 fffff800`015c4d40rassstpfffff880`02858470 fffff800`015ef9a0 fffff800`015c4d40rdpbusfffff880`02858470 fffff800`015ef9a0 fffff800`015c4d40ksfffff880`02858470 fffff800`015ef9a0 fffff800`015c4d40
// 同じく nt!MmAllocatePagesForMdlEx (fffff800`015ef900) を呼び出す可能性があるドライバ抜粋
kd> !for_each_module ".echo ${@#ModuleName} ;s -q ${@#ModuleName} L?${@#Size} fffff800`015ef900"ntfffff800`0199e940 fffff800`015ef900 fffff800`0199c1d0dmvscfffff880`00c17188 fffff800`015ef900 fffff800`014d09c0CLFSfffff880`00e41070 fffff800`015ef900 fffff800`014b3550CIfffff880`00e41070 fffff800`015ef900 fffff800`014b3550fffff880`011f13e8 fffff800`015ef900 00000000`00000000HIDCLASSfffff880`00e41070 fffff800`015ef900 fffff800`014b3550volmgrxfffff880`00e41070 fffff800`015ef900 fffff800`014b3550amdxatafffff880`00e41070 fffff800`015ef900 fffff800`014b3550NETIOfffff880`00e41070 fffff800`015ef900 fffff800`014b3550NDISfffff880`011f13e8 fffff800`015ef900 00000000`00000000msrpcfffff880`011f13e8 fffff800`015ef900 00000000`00000000ACPIfffff880`011f13e8 fffff800`015ef900 00000000`00000000pcifffff880`011f13e8 fffff800`015ef900 00000000`00000000Wdf01000fffff880`011f13e8 fffff800`015ef900 00000000`00000000WDFLDRfffff880`011f13e8 fffff800`015ef900 00000000`00000000vmbusfffff880`011f13e8 fffff800`015ef900 00000000`00000000winhvfffff880`011f13e8 fffff800`015ef900 00000000`00000000
// バルーニングを行なうドライバは、上記では黄色マークがついている以下の dmvsc.sys となります。しかし、メモリ ダンプから今回の MDL 領域が dmvsc.sys によって確保された事を裏付ける情報がありません。
Module[3006] [C:\WINDOWS\SYSTEM32\DRIVERS\DMVSC.SYS] Company Name: Microsoft Corporation File Description: Dynamic Memory Product Version: 6.1.7601.17514 File Version: 6.1.7601.17514 (win7sp1_rtm.101119-1850) File Size (bytes): 71168 File Date: ? 11 21 12:24:00 2010 Module TimeDateStamp = 0x4ce79b97 - Sat Nov 20 18:57:43 2010 Module Checksum = 0x000120f5 Module SizeOfImage = 0x00018000 Module Pointer to PDB = [dmvsc.pdb] Module PDB Guid = {1A806C15-8753-40A0-82DB-9868074FDFDC} Module PDB Age = 0x1
こんにちは。 Windows テクノロジー サポートの服部です。
今回は、ボリューム シャドウコピーを使用されている環境で発生するエラー イベントであり、特に多くお問い合わせをいただいているイベント ソース:VolSnap ID: 25 についてご紹介したいと思います。 シャドウ コピーの作成中に問題が発生し、次のシステムイベントが記録されることがあります。 ************************************************** Event Type: Error Event Source: VolSnap Event Category:None Event ID: 25 Description: The shadow copies of volume "VolumeName" were aborted because the diff area file could not grow in time. Consider reducing the IO load on this system to avoid this problem in the future. -訳 シャドウコピーの記憶域を時間内に拡大できなかったために、ボリューム"VolumeName" の シャドウコピーは削除されました。 システムIO負荷を減らすかまた は、シャドウコピーされていないシャドウコピーの 記憶域ボリュームを選んで下さい。 ************************************************** この Volsnap 25 のイベントは、Diff Area の拡張処理が失敗した場合に記録されるイベントです。このイベントが記録された場合、それまでに取得したスナップショットのファイルが全て削除されます。
この問題の詳細について VSS の動作を含めて説明いたします。 - VSS の動作について イベントの説明にあります Diff Area とは、ファイルへの書き込みなどによりボリュームへの変更処理が行われた際に、その変更が行われる前の状態を復元するためのデータを保存しておくファイルです。 Diff Area ファイルがないと、以前のバージョンを復元するためのデータを保存することができませんので、必然的に以前のバージョンを復元することができません。 そのため以前のバージョンの管理に必要不可欠な非常に重要なファイルです。 シャドウ コピーの設定を有効にしている状態で、ある時点でスナップショットを作成すると、[以前のバージョン] タブを使用して、スナップショット作成時のファイルの状態を復元することが可能ですが、これは、Diff Area ファイルと差分ファイルを基に実現されています。 具体的には、スナップショットを作成しますと、それまでの Diff Area ファイル内のデータが別の差分ファイルとして抽出され、同時に新たな Diff Area ファイルが作成されます。 その後、新しい Diff Area には引き続き、ボリュームへの変更が行われるたびに元のデータに復元されるための情報が保存されていきます。 スナップショット作成時のファイルの状態に戻す操作が行われた場合には、その操作を行った時点でのファイルの状態から、Diff Area ファイル内の変更履歴をさかのぼることで、スナップショット作成時の状態を復元しております。 さらにもう一世代前のスナップショットの状態に戻す場合には、直前のスナップショットまでさかのぼった後、さらに直近の差分ファイル（これは言い換えれば 1 世代前の Diff Area ファイルです）をさかのぼることで復元します。 ※この仕組みについて図にしますと、以下のようなイメージとなります。 ------------------------------------------- ┌─────────────┐ │3 世代前のスナップショット └─────────────┘ ↑ │（差分ファイル 1） │ ┌─────────────┐ │2 世代前のスナップショット
└─────────────┘ ↑ │（差分ファイル 2） │ ┌─────────────┐ │1 世代前のスナップショット
└─────────────┘ ↑ │（差分ファイル 3） │ ┌─────────────┐ │直前のスナップショット └─────────────┘ ↑ │（Diff Area ファイル） │ ┌─────────────┐ │現在の状態 └─────────────┘ 現在の状態はリアル タイムで変更されていきますので、その変更分が随時 Diff Area に格納されます。 たとえば、2 世代前のスナップショットの状態に復元する場合、現在のボリュームの状態から、Diff Area ファイル、差分ファイル 3、差分ファイル 2 の順に変更履歴をさかのぼることでファイルを復元します。 ------------------------------------------- 繰り返しとなりますが、Diff Area ファイルは非常に重要なファイルです。 このファイルが削除されたり不正な状態になりますと、以前のスナップショットの状態までさかのぼることができなくなるため、結果として以前のどの世代にも戻すことができなくなります。 - DiffArea ファイルについて 続いて、Diff Area ファイルの詳細な扱いについてご説明いたします。 Diff Area ファイルは、スナップショットが作成されたタイミングで新規に作成されますが、その時点では 300MB 程度（環境によりサイズは異なる場合があります）のファイルサイズとして作成されます。 その時点では実際に 300MB のすべての領域を使用しているわけではなく、ボリュームの変更情報を格納するためのバッファ領域として確保されているような状態となります。 その後、ボリュームへの変更が継続して行われますと、それに応じて Diff Area 内に復元のためのデータが格納されていきます。 このデータが積み重なり、初期サイズを超過する可能性がある場合、Diff Area のファイル自体を拡張する処理が行われます。 この拡張処理では、具体的には Diff Area のファイル サイズを300MB から 400MB などに拡張することになりますが、その処理が完了するまでの間に Diff Area ファイルの 300MBを使い切ってしまった場合、本来Diff Area に書き込まれるべき情報を格納する場所がなくなってしまいます。 この場合に Volsnap 25 が記録されることになります。 Diff Area の拡張処理は、通常の Diff Area への書き込み処理とは非同期で行われておりますため、拡張処理が完了するまでの間に Diff Area への書き込み処理が大量に行われると、先に Diff Area が一杯になってしまい、Diff Area への書き込みができなくなることになります。 これは、二つの処理が非同期で行われていることで、どうしても発生し得る現象となります。 また、この処理を同期的に行おうとした場合、Diff Area の拡張処理が完了するまでの間 Diff Area への書き込みを発生させない、つまり対象ボリュームに対する変更処理自体を待たせる必要があり、通常のファイル サーバー等としての機能を一時的に停止させるような大きな影響を与えることになると想定されます。 この現象が発生しますと、上述したイメージ図にてスナップショットを復元させるための基となる Diff Area ファイルをさかのぼることができなくなりますので、結果的にすべての世代に戻すことができなくなります。これまでに保存されていた差分ファイルは意味をなさなくなりますため、すべての差分ファイルが削除される動作となります。 - 対処するには？
最も重要なポイントは Diff Area の拡張処理が間に合わないことがあるという点になりますが、これは、I/O の頻度に大きく依存することになります。 シャドウ コピーの記憶域ボリュームと対象ボリュームが同じボリュームに設定されている場合に顕著に I/O が増加する傾向にありますが、これは具体的な要因としてはCopy-On-Write の影響があげられます。
対象ボリュームと記憶域ボリュームが同じボリュームに設定されている場合、Copy-On-Write など VSS に関連する書き込み処理が一つのボリュームに集中するため、対象ボリュームと記憶域ボリュームを異なるボリュームに設定する場合より Disk I/O の負荷が相対的に高くなります。
また、I/O が増加する要因として、ボリュームの断片化による影響も考えられます。
シャドウコピーの記憶域が割り当てられているボリュームの断片化が進んでいる際にこの影響を受けて拡張処理に時間がかかる可能性があります。Diff Area ファイル自体は連続したディスク領域である必要があり、そのため Diff Area ファイルの拡張においても、既存の Diff Area ファイルから、さらに連続領域として確保が必要となります。このため、拡張処理の際に場合によってはボリューム上のデータ ブロックの移動という最適化処理を行う必要があり、その分 Disk I/O が増加することがあります。 実際に弊社にお問い合わせいただく同様の事例では同じボリュームに設定されていることが原因である場合がほとんどです。もちろん、ディスク性能の劣化等、I/O 速度の問題などで、異なるボリュームでも発生する可能性はございますが、通常は問題ありません。 弊社では I/O 負荷の理由によりシャドウ コピーが削除される場合があることは認識しており、これを回避するためにシャドウ コピーの対象ボリュームと記憶域ボリュームを分けていただくことを推奨しております。 そのため、同じボリュームの構成にて現象が発生した場合には、異なるボリュームへの変更が最適な対処方法となります。 また重要なデータに関しては、こういった削除の可能性も踏まえ、シャドウ コピーだけでなくデータのバックアップを別途組み合わせてご使用いただくことも必要となります。 以下の Web サイトにてこの点も含めた注意点をご案内しておりますので、こちらも併せてご確認くださいますようお願いいたします。 共有フォルダーのシャドウコピーに関するヒント集 http://technet.microsoft.com/ja-jp/library/cc753975.aspx
(一部抜粋) ・シャドウ コピー用の記憶域には、異なるディスク上にある別のボリュームを使用する ディスク上の記憶域のうちシャドウコピーされていない領域を選択します。 別のディスク上にある個別のボリュームを使用することで、I/O 負荷の上昇が 原因でシャドウ コピーが削除される可能性がなくなり、パフォーマンスが向上します。 使用頻度の激しいファイルサーバーではこの構成をお勧めします。 ・ファイル サーバーのバックアップを定期的に実行する 共有フォルダーのシャドウコピーは定期的なバックアップの実行の代わりにはなりません。 データ保護のために、共有フォルダーのシャドウコピーだけでなく、バックアップ ユーティリティ (たとえば、Windows Server 2008 または Windows Server 2008 R2 の Windows Server バックアップ) も併用してください。 -- 参考情報-- VolSnap 33 が大量に出てしまう問題について http://blogs.technet.com/b/askcorejp/archive/2009/06/05/volsnap-33.aspx -- 参考情報-- Article ID: 925799 Error message when a Windows Server 2003-based computer has a high level of I/O activity: "The shadow copies of volume Volume_Name were aborted because the diff area file could not grow in time" http://support.microsoft.com/kb/925799/en-us http://support.microsoft.com/kb/925799/ja (機械翻訳)