こんにちは。
Windows プラットフォーム サポートの横山です。
本日は、[Hyper-V マネージャー] を利用した操作に関するログを取得する方法についてお伝えいたします。
[Hyper-V マネージャー] の処理詳細を確認するためのトレースとして Hyper-V UI トレースが実装されております。本トレースでは、[Hyper-V マネージャー] からの仮想マシンの作成 / 起動失敗や仮想マシンの一覧が表示されない現象に関するログを確認することができます。更には、仮想マシン接続 (vmconnect.exe) に関するログも取得できるため、仮想マシン接続が行えない場合にも有効なトレースです。本トレースは既定では有効化されておらず、VMClientTrace.config というファイルを作成する必要がございます。有効化の手順は以下の通りです。
1. "%appdata%\Microsoft\Windows\Hyper-V\Client\1.0\" のパス配下に "VMClientTrace.config" という名前の空ファイルを配置します。
※ 拡張子を表示した状態でファイル名を設定してください。
2. 作成した VMClientTrace.config ファイルをテキスト エディタで開き、以下の内容を記述して保存します。
※ Windows Server 2008 / 2008 R2 と Windows Server 2012 / 2012 R2 (Windows 8 / 8.1) で異なるため、それぞれを記載いたします。
// Windows Server 2008 / 2008 R2
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<Microsoft.Virtualization.Client.TraceConfigurationOptions>
<setting name="TraceTagFormat" type="System.Int32">
<value>3</value>
</setting>
<setting name="BrowserTraceLevel" type="System.Int32">
<value>6</value>
<setting name="VMConnectTraceLevel" type="System.Int32">
<setting name="InspectVhdTraceLevel" type="System.Int32">
</Microsoft.Virtualization.Client.TraceConfigurationOptions>
</configuration>
// Windows Server 2012 / 2012 R2
<value>127</value>
3. [Hyper-V マネージャー] の再起動後、トレースが開始されますので、調査対象の現象を再現させます。
※ 仮想マシン接続の場合は、仮想マシン接続 (vmconnect.ext) を再起動します。
4. [Hyper-V マネージャー] を終了し、ログの書き込みを完了させます。
※ 仮想マシン接続の場合は、仮想マシン接続 (vmconnect.ext) を終了します。
5. ログ ファイルは %temp% もしくは %userprofile%\AppData\Local\Temp\ に保存されます。
※ [Hyper-V マネージャー] の操作に関するログは "VMBrowser_Trace_日時.log" として保存され、仮想マシン接続に関するログは "VMConnect_Trace_日時.log" として保存されます。
ログの出力を停止する場合は作成した VMClientTrace.config のリネームを行うか、削除してください。
こんにちは。Windows プラットフォーム サポートの北原です。
2014 年 10 月にロシアのタイム ゾーンが通年冬時間となる変更が行われましたが、弊社ではそれに対応する更新プログラムをこれまで 2 つ公開いたしました。本記事において、それぞれの目的について解説いたします。
========================タイム ゾーン情報の変更について========================まずはその前提となる話として、更新プログラム適用によるタイム ゾーン情報の変更についてご説明をさせていただきます。Windows OS では、各タイム ゾーンの設定 (サマー タイムの情報も含む)をレジストリ上で管理しており、対応する更新プログラムを適用することで、その内容が正しいものに変更されます。
各政府機関がタイムゾーンの変更を公式発表すると、弊社ではその知らせを受けて、更新プログラム(または、修正プログラムや Fix it) を公開しますが、今回のケースのようなサマー タイムの開始や廃止といったケースでは、その開始と終了の 2 回の変更に対応するため、通常 1 対の更新プログラムをリリースしております。
例えば、今年のモロッコのラマダンによるサマー タイムの変更については、以下の技術文書にある通り、2 つの Fix it をリリースしており、時期をずらしてそれぞれを適用するようお願いしております。
2014 - Morocco Ramadan DST changes - Fix it solutionshttp://support.microsoft.com/kb/2974661/en-us
========================今年の 9 月 23 日に公開した KB2998527 ========================ロシアではこれまでサマー タイムを設定しておりましたが、これを 10 月 26 日から通年冬時間で固定するとの公式発表がありました。弊社でもこれに対応するため、更新プログラム KB2998527 を 9 月 23 日に公開しました。
A September 2014 time zone update for Russia is availablehttp://support.microsoft.com/kb/2998527/en-us
KB2998527 公開当時は、これを 10 月 26 日の前に適用することで、10 月 26 日から始まる冬時間への変更に対応できました。ただし、元々設定されていた次回のサマー タイムの開始日 (2015 年 1 月) の設定が適用後も残されており、2015 年 1 月 7 日になると夏時間が開始してしまいます。これに対応可能な更新プログラムが、次にご説明する KB3013410 となります。
========================今年の 12 月 11 日に公開した KB3013410========================この更新プログラムは、各国のタイム ゾーンに関する変更をまとめた累積の更新プログラムですが、ロシアの通年冬時間を来年以降も正常に動作させる修正も含まれております。つきまして、ロシアのタイムゾーンで運用されているコンピューターにおきましては、必ずこちらの更新プログラムをご適用くださいますようお願いいたします。
December 2014 cumulative time zone update for Windows operating systemshttp://support.microsoft.com/kb/3013410/en-us
========================KB3013410 適用に関する注意事項========================以下の条件において、KB3013410 を手動または Windows Update で適用中に「インストールが完了されませんでした。」といったエラー メッセージが出力されることがあります。
- Windows Server 2003 (日本語環境)- タイム ゾーンをロシアのいずれかのタイム ゾーンに設定している- KB2998527 を適用していない
このメッセージは無害なもので、インストール自体は問題なく完了しておりますので、無視していただいて問題ございません。
========================まとめ========================KB2998527 は今年の 10 月の冬時間への切り替えに対応するために用意されたものであり、それを置き換える更新プログラム (KB3013410) が公開された現在においては、適用自体不要です。それに伴って Windows Update からも外されております。
現在では、KB3013410 のみを適用いただくことで、ロシアのタイム ゾーンの通年冬時間への対応が可能となります。以下の図はそれぞれの更新プログラムがカバーできる期間を示すものとなります。
いつも弊社製品をご利用いただきまして誠にありがとうございます。Windows プラットフォーム サポートの加藤です。
本項では、グループ ポリシーを用いてリムーバブル デバイスへのアクセス制御を行う際にご注意いただきたい点についてご紹介させていただきます。
ポリシーを適用して制御を行う前にご注意いただけますことを推奨しておりますが、ポリシーを用いてリムーバブル デバイスへのアクセス制御を既に行っているお客様につきましても、“意図した制御が行えていない場合の対処策” もしくは “不具合に対する予防措置” としてご利用いただくことをお奨めしております。
また、記載させていただいている不具合の内容は、弊社に報告されている事象の中でも代表的なシナリオでございます。そのためお客様の運用状況に一致しない場合でも、確認及び適用をご検討いただけますと幸いです。
<本項の概要>----------------------------------------------------------------------------------------------------------------■ある一定の条件下で起こる不具合に対する対処方法 (該当のOS)
1. グループ ポリシーを用いたデバイスのアクセス制御の設定が反映されない (Windows 8, Windows 8.1)
■弊社製品の不具合に起因した問題に対する KB 及び修正プログラム (該当のOS)
1. リムーバブル記憶域へのアクセス制御ポリシーを設定しても正しく適用されない (Windows Vista, Windows Server 2008)
2. リムーバブル デバイスへのアクセス制御ポリシーを設定後、光学デバイス (DVD, CD) ドライブがエクプローラー等から見えなくなる (Windows Vista, Windows 7, Windows Server 2008、Windows Server 2008 R2)
3. アクセス制御ポリシーを設定していないにも関わらず、監査ポリシーを設定するとリムーバブル デバイスへのアクセスが拒否される (Windows 8、Windows Server 2012)----------------------------------------------------------------------------------------------------------------
■ある一定の条件下で起こる不具合に対する対処方法 (該当のOS)
----------------------------------------------------------------------------------------------------------------1. グループ ポリシーを用いたデバイスのアクセス制御の設定が反映されない (Windows 8, Windows 8.1)
----------------------------------------------------------------------------------------------------------------
弊社では、Windows 8 および Windows 8.1 のクライアント PC に対してリムーバブル デバイスへのアクセス制御を行なった場合、意図した制御が行えなくなる事象が発生することを確認しております。以下の 3 つの条件すべてに該当する構成の場合は、リムーバブル デバイスへのアクセス制御が正しく反映されませんのでご注意ください。
< 既知のグループ ポリシーを用いたデバイスのアクセス制御の設定が反映されない 3 つの条件 >
• 制御対象のクライアント PC が Windows 8 もしくは Windows 8.1 である。 • グループ ポリシーは "ユーザーの構成" を使用して "リムーバブル記憶域へのアクセス" の設定を行っている。 • 監査ポリシーの "リムーバブル記憶域の監査" が有効になっている。
これらの条件に該当した場合は、以下のいずれかの対応をご検討いただく必要がございます。
<対処方法>
• "リムーバブル記憶域へのアクセス" の設定を "ユーザーの構成" ではなく "コンピュータの構成" で行う。 • 監査ポリシーの "リムーバブル記憶域の監査" を未構成に設定する。
3. アクセス制御ポリシーを設定していないにも関わらず、監査ポリシーを設定するとリムーバブル デバイスへのアクセスが拒否される (Windows 8、Windows Server 2012)
----------------------------------------------------------------------------------------------------------------1. リムーバブル記憶域へのアクセス制御ポリシーを設定しても正しく適用されない (Windows Vista, Windows Server 2008)
---------------------------------------------------------------------------------------------------------------
こちらは光学デバイス (DVD, CD) ドライブがエクプローラー等から見えなくなる現象に対する修正プログラムです。下記ご紹介の修正プログラムを適用いただいた後、レジストリー エディタにてレジストリを追加します。
なお、一度、光学デバイスが無効化されてしまうと、デバイス マネージャーから光学デバイスの削除を行い、再度デバイスを認識させる必要があります。修正プログラムの適用前にレジストリーを追加しておいても問題ございませんが、修正プログラムが適用されるまでは ApplyPolicyOnUserLogoff の値は無視されます。更新プログラムとレジストリー追加後は再起動いただく必要がございます。
<KB 及び修正プログラム>
対応文書番号: 979621
A removable storage device is disabled when you enable a Group Policy to deny write access or to deny read access to the device on a computer that is running Windows Vista or Windows Server 2008
http://support.microsoft.com/kb/979621/en-us
<追加するレジストリ>-----------------------------------------キー
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\RemovableStorageDevices
ApplyPolicyOnUserLogoff
種類 : REG_DWORD
値 : 0x00000000------------------------------------------
----------------------------------------------------------------------------------------------------------------2. リムーバブル デバイスへのアクセス制御ポリシーを設定後、光学デバイス (DVD, CD) ドライブがエクプローラー等から見えなくなる (Windows Vista, Windows 7, Windows Server 2008、Windows Server 2008 R2)
こちらはグループ ポリシーが正しく適用されない現象に対する修正プログラムです。修正プログラム適用後は再起動いただく必要がございます。
文書番号: 2738898
Users cannot access removable devices after you enable and then disable a Group Policy setting in Windows Server 2008, in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2738898/en-us
----------------------------------------------------------------------------------------------------------------3. アクセス制御ポリシーを設定していないにも関わらず、監査ポリシーを設定するとリムーバブル デバイスへのアクセスが拒否される (Windows 8、Windows Server 2012)
こちらはWindows 8 および、Windows Server 2012 で、監査ポリシーを設定するとリムーバブル デバイスへのアクセスが拒否される現象に対するロール アップです。月例のWindows Update を実施いただいている場合は、既に適用されているので、改めて適用いただく必要はございません。
ロールアップ適用後は再起動いただく必要がございます。
<ロールアップ>
Windows 8 および Windows Server 2012 の更新プログラムのロールアップ (2013 年 4 月)
http://support.microsoft.com/kb/2822241/ja
<問題の詳細>
Issues when the Audit object access policy is enabled on Removable Storage in Windows 8 or Windows Server 2012
http://support.microsoft.com/kb/2811670
参考:
Windows 8 および Windows 8.1 のリムーバブル デバイスへのアクセス制御の注意点について
http://blogs.technet.com/b/askcorejp/archive/2014/05/19/windows-8-windows-8-1.aspx
グループ ポリシーを用いたデバイスのアクセス制御について
http://blogs.technet.com/b/askcorejp/archive/2014/04/28/3516088.aspx
グループ ポリシーを用いた WPD デバイスの制限について
http://blogs.technet.com/b/askcorejp/archive/2014/08/18/wpd.aspx
いつも弊社製品をご利用いただきまして誠にありがとうございます。Windowsプラットフォーム サポートの加藤です。 昨今、情報漏えい対策の一環として多くのお問い合わせをいただいておりますグループ ポリシーを使用してリムーバブル デバイスを制御する方法についてご紹介させていただきます。グループ ポリシーを使用してリムーバブル デバイスを制御する方法は大きく分けると以下の 2 点の方法がございます。
- グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法 本項ではこちらの方法についてご紹介させていただきます。
- グループ ポリシーを使用してリムーバブル デバイスのインストールを制御する方法 こちらにつきましては以下のページでご紹介させていただいております。 『グループ ポリシーを用いた WPD デバイスの制限について』 http://blogs.technet.com/b/askcorejp/archive/2014/08/18/wpd.aspx
併せて、以下もご参照いただけますと幸いです。
『グループポリシーを用いて リムーバブル デバイス アクセス制御を行う前に行っていただきたいこと』 http://blogs.technet.com/b/askcorejp/archive/2014/12/11/3641905.aspx
<本項の概要>----------------------------------------------------------------------------■グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法1. リムーバブル記憶域へのアクセス制御の概要2. 設定方法 ■補足情報1. コンピューターの構成とユーザーの構成----------------------------------------------------------------------------
■グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法1. リムーバブル記憶域へのアクセス制御の概要2. 設定方法
----------------------------------------------------------------------------------------------------------------1. リムーバブル記憶域へのアクセス制御の概要
このグループ ポリシーでは、リムーバブル デバイスとして認識されたデバイスに対し、書き込み、読み取り、実行の制御を行うことが出来ます。対象OSは Windows Vista 以降のクライアント OS, サーバーOSです。リムーバブル記憶域へのアクセス制限のグループ ポリシーを設定すると、グループ ポリシー サービス (Gpsvc) から通知を受けた Portable Device Enumerator Service (WPDBusEnum) サービスが、制御の対象となるデバイスを特定し、デバイスのアクセス コントロール リスト (ACL) を設定します。
このグループポリシーでは、下記の 5 つに分類されるリムーバブル デバイスについてアクセス制御を行うことが可能です。またこのあとご紹介させていただく カスタム クラスをご利用いただくことにより、デバイス セットアップ クラス GUID によるデバイスのアクセス制御を行うことも可能です。
SD カードは一般的には WPD デバイスとして認識されますが、製造メーカーによってはリムーバブル ディスクとして認識されるものもございます。制御を行いたいデバイスが特定のものである場合は、念のため製造メーカーにご確認いただければ幸いです。
<参考情報>[タイトル] System-Defined Device Setup Classes Available to Vendors (英語) http://msdn.microsoft.com/en-us/library/ff553426(VS.85).aspx
---------------------------------------------------------------------------------------------------------------- 2. 設定方法
1. リムーバブル記憶域へのアクセス制御の設定方法
以下は、グループ ポリシーを用いて、ローカルのコンピュータに対して 『リムーバブル ディスク への書き込み』 を制御する手順についてご紹介します。
[スタート] 右クリック - [ファイル名を指定して実行] gpedit.msc と入力します - [コンピューターの構成] - [管理用テンプレート] - [システム] - [リムーバブル記憶域へのアクセス] - [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 有効
■補足情報----------------------------------------------------------------------------------------------------------------1. コンピューターの構成とユーザーの構成
以下のようなシナリオをベースにご紹介させていただきます。
<シナリオ>-------------------------------------------------------------------情報漏えい対策の一環として、コンピュータの構成で [リムーバブル ディスクの読み取りアクセス権の拒否] と [リムーバブル ディスクの書き込みアクセス権の拒否] を有効にしている。
しかし一部のユーザー (User A) は、USB メモリを使用する必要があるため User A に対してのみ [リムーバブル ディスクの読み取りアクセス権の拒否] と [リムーバブル ディスクの書き込みアクセス権の拒否] を無効に設定したい。 想定する設定方法- コンピュータの構成でポリシーを有効化- User A に対いてポリシーの無効化-------------------------------------------------------------------
上記のような方法で設定を行った場合、結果は User A に対しても [リムーバブル ディスクの読み取りアクセス権の拒否] と [リムーバブル ディスクの書き込みアクセス権の拒否] が有効になってしまします。これはグループ ポリシーのリムーバブル記憶域へのアクセス制御については、設定項目がユーザーの構成とコンピュータの構成で重複した場合、コンピュータの構成が優先されるためです。
グループ ポリシーのリムーバブル記憶域へのアクセス制御で優先される構成
コンピュータの構成 > ユーザーの構成
従いまして、本シナリオの要件を満たすためには、コンピュータの構成で設定を行うのではなく、ユーザーの構成で全ユーザーに対してアクセス拒否のポリシーの有効を設定いただいた上で、User A に対いてポリシーの無効化を設定いただきますようお願いいたします。
<設定方法例>新規で作成した AccessEnableOUに User A を追加し、 新規で作成した AccessDenyOU に全ユーザーを追加します。それぞれの OU に対して以下のように GPO をリンクさせます。GPOをリンクさせるとき、AccessEnableOU , AccessDenyOU の順番で行います。
AccessEnableOU → - [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 無効 - [リムーバブル ディスク: 読み取りアクセス権の拒否] 設定値: 無効
AccessDenyOU → - [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 有効 - [リムーバブル ディスク: 読み取りアクセス権の拒否] 設定値: 有効
なお、グループ ポリシーのリムーバブル記憶域へのアクセス制御を特定のユーザーに設定する場合は、以下の手順で行うことが出来ます。
[スタート] 右クリック - [ファイル名を指定して実行] gpedit.msc と入力します - [ユーザーの構成] - [管理用テンプレート] - [システム] - [リムーバブル記憶域へのアクセス] - [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 有効
参考:Windows 8 および Windows 8.1 のリムーバブル デバイスへのアクセス制御の注意点についてhttp://blogs.technet.com/b/askcorejp/archive/2014/05/19/windows-8-windows-8-1.aspx グループ ポリシーを用いたデバイスのアクセス制御についてhttp://blogs.technet.com/b/askcorejp/archive/2014/04/28/3516088.aspx
グループ ポリシーを用いた WPD デバイスの制限についてhttp://blogs.technet.com/b/askcorejp/archive/2014/08/18/wpd.aspx
こんにちは、Windows サポートチームの頂です。
ご利用環境によって、Windows 8.1 や Windows Server 2012 R2 で日本語 IME 辞書の更新 (KB 2880582) が適用されていない、Windows Update に検出されないといったお問い合わせを頂いておりますので、Windows 8.1 および Windows Server 2012 R2 の IME 辞書ファイルの更新についてご紹介いたします。
文書番号: 2880582 Windows 8.1 での日本語 IME 辞書の更新http://support.microsoft.com/kb/2880582/ja
技術文書にて公開いたしております、日本語 IME の辞書は、スタート スクリーン内の検索チャームやストア アプリなどで利用される IME (以下 Modern IME) 専用のアップデート辞書となります。そのため、Modern IME が有効となっていない環境の場合、Windows Update にて更新項目として表示されません。
以下のように、検索チャームやストア アプリなど日本語入力を有効にした時点で、OS 上で Modern IME が有効と判断され、Windows Update の検出対象となります。
Modern IME が無効な状態で Windows Update の更新をスキャンした場合
Modern IME が有効な状態で Windows Update の更新をスキャンした場合
Windows Update で公開されております IME 辞書アップデートについてと IME 辞書アップデート適用後の確認方法についても併せてご紹介いたします。
対象となる IME 辞書アップデートは、バージョン情報にて確認ができます。
Modern IME 用: 製品バージョン 16.XX通常の IME 用: 製品バージョン 15.XX
以下のように、インストール後は、[プログラムと機能] から適用されたIME 辞書のアップデートについて確認できます。
赤枠で囲った項目が、Modern IME 用の更新となります。
2014/12/02 現在
本日は、Windows Server 2012 R2 環境で出力される Quota 6 イベントについてお伝えいたします。
クォータの設定を行っているドライブを Window Server バックアップで取得した場合、バックアップ期間中に Quota 6 のイベントがシステム ログに記録されます。Quota 6 のイベントはクォータ ドライバーをボリュームに対して接続できず、正常にクォータの設定が行えなかったことを示します。バックアップ期間中に表示される Quota 6 に記載のボリュームは、VSS (Volume Shadow Copy) を取得する際に利用されるボリュームです。本ボリュームは書き込みが保護されているため、クォータ ドライバーの接続は Windows Server バックアップによるバックアップ処理への介入を行う処理ではございません。そのため、Quota 6 のイベントがバックアップ期間中にのみ記録され、それ以外のタイミングでは記録されていない場合は、本イベントは無視可能なイベントであり、バックアップ データにも影響を与えないイベントです。
なお、クォータがボリュームに対して正常に設定されているかを確認するにあたりましては fltmc コマンドをご利用ください。
>fltmc instances -f quota
実行例: C:\>fltmc instances -f quota
Instances for quota filter:
Volume Name Altitude Instance Name Frame VlStatus ------------------------------------- ------------ ---------------------- ----- -------- C: 125000 quota 0 D: 125000 quota 0
正常にクォータ ドライバーが接続されている場合、対象のボリュームが上記の通り表示されます。クォータの設定が外れている場合は、以下のコマンドを利用し、クォータの再設定をご実施ください。
>fltmc attach quota <ボリューム名>
実行例: C:\>fltmc attach quota e: ATTACH successful... Instance Name: quota
こんにちは。Windows プラットフォーム サポートの世古です。
日々のサポート業務の中で、お問い合わせを頂く内容についてご紹介します。
今回は Window 7 で標準の機能となっている「スタートアップ修復」の無効化方法についてご紹介します。管理上「スタートアップ修復」によるシステムの復元をユーザーに行わせたくない場合には以下の手順をご参照下さい。まず「スタートアップ修復」の機能について知りたい方は “補足（スタートアップ修復について）” で説明しておりますので、そちらを先にご確認ください。
「スタートアップ修復」は既存の設定でシステムの復元機能が有効になっており、実行すると直近の復元ポイントに復元されます。最近インストールしたドライバやソフトウェアなどが起動障害の原因である場合、システムの復元が自動実行されることで障害が取り除かれます。
しかしグループ ポリシーなどで復元ポイントの作成を無効にしている環境では、新たに復元ポイントが作成されることはなく古い復元ポイントのみが残ってしまっている場合があり、スタートアップ修復が行われた結果として、システムを構築した時点の環境に復元されてしまう場合があります。このような環境においては、以下に記載したスタートアップ修復の無効化および復元ポイントの削除が有効な場合がございます。
・スタートアップ修復の無効化方法
以下にスタートアップ修復を無効化する手順を紹介いたします。
1. コマンド プロンプトを管理者権限で起動します。
2. 下記の 2 つのコマンドを実行します。
bcdedit /set {current} recoveryenabled No
bcdedit /deletevalue {current} recoverysequence
また以下のコマンドにて再度有効にする事が出来ます。
REAgentc /Enable
(補足)
対象となるWindows ブート ローダーの identifier に {current} 以外の値が設定されている場合は、各端末毎にGUID を確認していただく必要がございます。
Windows ブート ローダーの値の確認は bcdedit コマンドで確認できます。
・復元ポイントの削除方法について
以前の復元ポイントに戻る事を回避する為に、スタートアップ修復の無効化に加え、システムの復元ポイントを削除する場合には以下の手順をご参照ください。
システムの保護は、シャドウ コピーの機能を利用して情報を管理しており以下のコマンドの実行により、復元ポイントの削除が可能です。
Vssadmin Delete shadows /All
削除されたかどうかは、下記のコマンドを実施し、「クエリを満たす項目が何もありませんでした」となれば、削除は成功しています。
Vssadmin List Shadows
・補足（スタートアップ修復について）
Windows 7 では既定で自動フェールオーバーという機能が有効であり、システムの起動に何らかの要因で失敗した場合、Windows RE (回復環境)にフェール オーバーさせ、[スタートアップ修復] の機能を提供します。
システムの起動後、以下の様な画面が表示されます。
しばらくすると、選択されている項目で自動的に起動されます。ここでスタートアップ修復の起動（推奨）が選択されていた場合には以下の画面が表示されます。
そして次に [システムの復元] を実施するかの選択画面に推移します。
単に [スタートアップ修復] を実施するのであれば問題はありませんが、ここで誘導される [システムの復元] を行う場合にはいつの復元ポイントに戻るかについて考慮する必要があります。
Windows 7 では Windows Update などによる更新プログラムのインストールやドライバのアップデートの際、自動で復元ポイントが作成され、あるいは前回復元ポイントが作成されてから 7 日以上経過している場合は自動で復元ポイントが作成されます。
以下参考情報となりますので併せてご参照ください。
<参考情報>
Windows RE の機能: http://technet.microsoft.com/ja-jp/library/dd744291(v=ws.10).aspx
Windows 回復環境テクニカル リファレンス: http://technet.microsoft.com/ja-jp/library/dd744255(v=ws.10).aspx
こんにちは。Windows サポートチームの太田です。 今回はパフォーマンス モニターの表示に関する問題を確認いたしましたので、ご紹介いたします。
[概要]パフォーマンス モニターを用いて、グラフにてリアルタイムのパフォーマンス データを表示させている際に、実際のシステム時刻からずれた時刻が表示される場合があります。
[詳細]この現象は、長期間連続稼働させていることによって表示上の問題が発生する場合があります。パフォーマンスデータやグラフの描画自体はリアルタイムに正しく表示されますが、表示される時刻が実際のシステム時刻よりも過去の時刻が表示されます。
具体例を示します。
図の例では、システム時刻は 23:52 ですが、パフォーマンスモニターに表示されるリアルタイムの時刻は、17:52 となり 6時間遅れています。
[影響]この事象は、パフォーマンスモニターの時刻表示に限定した問題で、時刻以外は正確な情報が表示されます。また、データ コレクターを用いて採取するパフォーマンスログはこの影響を受けません。
[回避策]定期的にパフォーマンスモニターを終了/起動していただくようお願いいたします。
[対象OS]Windows Server 2008 /Vista 以降の Windows にて発生することを確認しております。
ご不便をおかけいたしますが、上記回避策にてご対応くださいますようお願いいたします。
Windows プラットフォーム サポートの吉田です。
今回は、リモート デスクトップ サービス (旧ターミナル サービス) で利用される CAL (Client Access License) の概要および動作についてご説明いたします。
Windows Server に多数のセッションを同時に接続させるためには、リモート デスクトップ サービス環境を構築する必要がありますが、ご利用いただくためには、各クライアントに対して、リモート デスクトップ サービス クライアント アクセス ライセンス (RDS CAL) を発行します。
※ Windows Server 2008 までは、ターミナル サービス クライアント アクセス ライセンス (TS CAL) が正式名称となりますが、本稿では全て CAL と記載します。
CAL の動作原理や有効期限について、よくいただくご質問を以下にまとめました。
ぜひご参考ください。
1. CAL の概要
--------------------------
CAL は大きく以下の 2 種類に分類されます。
この 2 種類は、お客様のリモート デスクトップ サービス環境に応じて、使い分けていただく必要があります。
簡単に説明すると、デバイス CAL は接続元デバイス (クライアント) 毎に対して発行され、ユーザー CAL は接続ユーザー毎に発行されます。
例えば、一つのデバイスを複数人でご利用いただく環境の場合はデバイス CAL、一人のユーザーが複数のデバイスをご利用いただく環境の場合は、ユーザー CAL をご利用する事で、購入 (インストール) いただく CAL の数量を効率よく管理できます。
重要なポイントとして、一台のセッション ホスト サーバー (ターミナル サーバー) に対しては、デバイス CAL を使って接続させるか、ユーザー CAL を使って接続させるかに応じて、いずれかのライセンス モードを選択する必要があります。
セッション ホスト サーバーが両方の CAL に応じる事はできません。
なお、一台のライセンス サーバーに、デバイス CAL、ユーザー CAL の両方をインストールする事は可能です。
デバイス CAL、ユーザー CAL はそれぞれ発行動作が異なります。
次項でそれぞれの動作概要をご説明します。
2. デバイス CAL について
---------------------------
デバイス CAL は、クライアント コンピューター (デバイス) に対してセッション ホスト サーバーへアクセスする権限を与えます。
デバイス CAL が一度発行されると、その情報がクライアント コンピューター上に保持されます。
デバイス CAL の情報は、クライアントの以下のレジストリに格納されます。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store\LICENSE00x
図 1 : デバイス CAL 情報 レジストリ
デバイス CAL は、初回接続時に発行される一時 CAL と、二回目の接続時に発行される恒久 CAL の二種類が存在します。
[一時 CAL]
クライアント コンピューターからセッション ホスト サーバーに初めて接続した時に発行されるライセンスです。
一時 CAL の有効期限は、一律で 90 日間となり、恒久 CAL の余剰数がない状態の場合は、二度目以降の接続時も一時 CAL のまま接続します。
一時 CAL の発行数に制限はありません。
図 2 : 一時 CAL 発行例
[恒久 CAL]
一時 CAL を持っているクライアント コンピューターが二回目に接続した時に発行されるライセンスです。
恒久 CAL の有効期限は、52 日間から 89 日間のランダムな期間が設定されます。
この有効期限を任意の期間にすることはできません。
ライセンス サーバーにインストールした数量を上限として発行されます。
図 3 : 恒久 CAL 発行例
----
上記の通り、デバイス CAL には一時 CAL、恒久 CAL ともに有効期限をもっています。
その有効期限を過ぎた場合には、もちろん接続ができなくなります。
そのため、セッション ホスト サーバーに接続するクライアント コンピューター数を適切に管理する必要があります。
[恒久 CAL の更新について]
恒久 CAL の有効期限は、52 日間から 89 日間のランダムな期間が設定されますが、その有効期限日の 1 週間前から CAL の更新期間となります。
更新期間中にセッション ホスト サーバーに接続する事で、新たに 52 日間から 89 日間のランダムな期間が設定されます。
[ライセンスの失効について]
Windows Server 2008 以降の CAL については、ライセンス マネージャー上から、失効処理を行う事ができます。
接続する事がなくなったクライアントや、誤って接続して発行させてしまったクライアントに対して、発行された CAL を失効させ、別のクライアントのために発行の余剰を作ることができます。
※ Windows Server 2003 以前の CAL については失効処理を行う事ができません
図 4 : 失効
失効できる数はインストールしている CAL 総数の 20 % までとなります。
また、失効された CAL につきましても、発行先のクライアントが保持する CAL の情報は変わりませんので、有効期限内は接続する事が可能です。
失効処理は、あくまでライセンス サーバー上の管理上の情報となります。
極端な例となりますが、100 CAL が存在し、全ての CAL が発行済みであるとします。
その状態で上限となる 20 % の CAL を失効させ、さらに新規で 20 台のクライントが接続し、恒久 CAL が発行された場合、一時的には 120 台のクライアントが恒久 CAL を持つ状態となります。
[クライアント の識別について]
セッション ホスト サーバーは、接続元のクライアントをコンピューター名ではなく、各クライアントが一意で持つ Hardware ID で識別します。
仮に同様のホスト名を持つクライアントからの接続が受け付けた場合においても、別のクライアントとして管理されます。
Hardware ID は、クライアント コンピューターの以下のレジストリにあります。
HKLM\Software\Microsoft\MSLicensing\HardwareID\ClientHWID
図 5 : Hardware ID
ただし、ライセンス マネージャー上では、コンピューター名のみで表示されますので、同じコンピューター名を持つクライアントが存在する環境や、コンピューター名の変更が発生する場合には注意が必要です。
また、ライセンス マネージャー上は、初回 CAL 発行時のコンピューター名で表示されますので、CAL を持つクライアントのコンピューター名を変更した場合においても、旧コンピューター名のまま表示されます。
3. ユーザー CAL について
ユーザー CAL には、デバイス CAL のような、一時 CAL や恒久 CAL といった概念はありません。
ま���、デバイス CAL のように、接続元クライアントのレジストリに情報が記録される動作でもありません。
CAL の発行情報は、ドメイン コントローラー上の各ユーザー コンテナに情報として格納されます。
その情報については、Windows Server 2012 以降の環境あれば、ライセンス マネージャー上に表示されますが、Windows Server 2008 R2 以前のバージョンにおいては、ライセンス マネージャー上には表示されず、レポート機能を使用する必要があります。
以下は Windows Server 2012 ライセンス サーバーの例となります。
ライセンス サーバーが、ドメイン環境かつ Windows Server 2012 以降の場合は、ライセンス マネージャー上でユーザー CAL の発行状況を確認する事ができます。
図 6 : ユーザー CAL 発行例
なお、ユーザー CAL の有効期限は一律で 60 日間となっておりますが、その有効期限は、あくまでその時点で発行されているユーザー CAL の情報管理のため使われるものとなり、有効期限を超過した場合も、超過直後の接続時に新たな有効期限が付与されますので、長期間アクセスが無い場合においても、接続不可となる事は発生いたしません。
ユーザー CAL (ユーザー数ライセンス モード) では、1 人のユーザーに対して、無制限の数のクライアントからセッション ホスト サーバーにアクセスする権限が与えられます。
ユーザー CAL (ユーザー数ライセンス モード) はライセンスによって強制されることはありません。
そのため、ライセンス サーバーにインストールされている CALの数に関係なく、クライアント接続を行うことができます。
ただしこれによって、各ユーザーに有効な CAL を持たせなければならないという、マイクロソフト ソフトウェア ライセンス条項の要件から管理者が免除されるわけではありません。
接続ユーザー数ライセンス モードを使用している場合に、各ユーザーに有効な CAL を持たせることができなければ、ライセンス条項違反となります。
4. デバイス CAL 運用において、クライアントが接続できなくなった際の暫定対策について
------------------------------------------------------------------------------------------
ライセンス マネージャー上で、対象クライアントに対して、正常にライセンスが 発行されているにも関わらず、クライアントがセッション ホスト サーバーに接続ができなくなった場合や、恒久 CAL の余剰数がない状態で、有効期限が超過したクライアントをどうしても接続させる必要がある場合の暫定対策として、クライアントで保持しているライセンス情報、および HardwareID を削除して、ライセンス サーバーに対して、新規接続のクライアント と判断させて接続する方法があります。
<暫定対策 : クライアントのレジストリ削除>
[ハードウェア ID] および、ライセンス情報のレジストリを削除することで、セッション ホスト サーバー側で、新規接続のクライアントだと判断され、ライセンス サーバーから一時 CAL が発行されます。
そのため、一時 CAL にて、90 日間は リモートデスクトップ 接続が可能となります。
恒久 CAL に使用可能な数が残っている場合には、 2 度目の接続から 一時 CAL から恒久 CAL に変わります。
削除する必要のあるレジストリは以下となります。
1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\HardwareID\ClientHWID
2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store\LICENSE00x
(LICENSE00x は x に数字が入ります。いくつか存在する場合がありますので、その際は全て削除します)
なお、上記手順の実行につきましては、クライアント PC の administrator 権限のあるユーザーにて実行する必要があります。
また、初回接続時に、新たに HardwareID レジストリが作成されますので、初回接続時につきましても、administrator 権限のあるユーザーにて実施する必要があります。
補足情報 : 多段 RDP 接続について
Windows Server 2008 R2 までは、多段 RDP 接続はサポートされておりません。
例 : Windows 7 ---- RDP ----> Windows Server 2008 R2 (1) ---- RDP ----> Windows Server 2008 R2 (2)
英語文献とはなりますが、以下に公開情報がございます。
- Running a Remote Desktop session within another Remote Desktop session is not supported http://support.microsoft.com/kb/2582684
しかしながら、条件つきとはなりますが、Windows Server 2012 からは、正式にサポートされております。
- Running a Remote Desktop Connection session within another Remote Desktop Connection session is supported with Remote Desktop Protocol 8.0 for specific scenarios http://support.microsoft.com/kb/2754550
例 : Windows 8 ---- RDP ----> Windows Server 2012 (1) ---- RDP ----> Windows Server 2012 (2)
上記のように、クライアントは Windows 8 以降であり、サーバーはいずれも Windows Server 2012 以降である必要がございます。
なお、CAL については、[Windows Server 2012 (1)] に接続するために、[Windows 8] に必要となり、[Windows Server 2012 (2)] に接続するために、中継となる [Windows Server 2012 (1)] に発行される必要がございますので、数量の管理にはご留意願います。
---------------------------------------------------
-参考文献
リモート デスクトップ サービス クライアント アクセス ライセンス (RDS CAL)
http://technet.microsoft.com/ja-jp/library/cc753650.aspx
リモート デスクトップ ライセンスの概要
http://technet.microsoft.com/ja-jp/library/cc725933.aspx
リモート デスクトップ サービス クライアント アクセス ライセンス (RDS CAL) を管理する
http://technet.microsoft.com/ja-jp/library/dd759163.aspx
Removing Terminal Server licenses from an RDP client
http://support.microsoft.com/kb/187614/ja
Windows プラットフォーム サポートの片山です。
今回は、Windows 7 での RemoteFX USB リダイレクトを使用するうえで注意事項を紹介させて頂きます。
リモート デスクトップ接続した際、リモート セッション上でローカル コンピューター (クライアント) のデバイスやリソースを使用したい場合に、リダイレクトという機能を使用することが可能です。しかしながら、従来のリダイレクトできるデバイスは限られており、Web カメラ、スキャナ等は MTP (メディア転送プロトコル) または PTP (画像転送プロトコル) がサポートがされていない場合リダイレクトを行うことができませんでした。
そこで、どのデバイスでもリダイレクトが出来るように、RemoteFX USB リダイレクトがWindows 7 SP1 及び Windows Server 2008 R2 SP1 に KB 2592687 を適用することによりサポートされるようになりました。
RemoteFX USB リダイレクトでは、厳密にはリダイレクトを行いたいUSB デバイス だけでなく、USB ポートのエミュレートも行います。そのため、ローカルのデバイスとして、USB 2.0 Driver が使用されていた場合においても、RemoteFX USB リダイレクトでは、まず、自身に最適なデバイスである USB 3.0 の使用を試みます。Windows 7 では USB 3.0 が ネイティブにサポートされていないため、USB 3.0 ポートを認識することができず、リダイレクトを行うことができません。
上記の動作は Windows 7 を RDP クライアントとしてご利用いただく上での機能上の制限となります。Windows 7 でUSB デバイスのリダイレクトを行う場合には USB 2.0 ポートとしてリダイレクトをご利用いただく必要がございます。なお、Windows 8 以降の OS では、USB 3.0 スタック はネイティブに実装されているため、RemoteFX USB リダイレクトとして USB 3.0 を使用することが可能です。
- 参考文献USB ドライバー スタック アーキテクチャhttp://msdn.microsoft.com/ja-jp/library/windows/hardware/hh406256(v=vs.85).aspx
ローカルのデバイスとリソースをリモート セッションで使用できるようにするhttp://technet.microsoft.com/ja-jp/library/cc770631.aspx
Windows 7 と Windows サーバー 2008 R2 のリモート デスクトップ プロトコル (RDP) 8.0 更新http://support.microsoft.com/kb/2592687※ RemoteFX USB リダイレクトを利用する為には上記の修正プログラムを適用し、Remote Desktop Connection 8.0 以上を使用する必要があります。
こんにちは。 Windows プラットフォーム サポート 松田です。
今回は Windows の情報を一括で採取する便利なツールをご紹介させて頂きます。
本ツールを利用することで、Windows 7/ Windows Server 2008 R2 以降の環境で追加コンポーネントをインストールすることなく、自動的にシステム情報を採取することができます。
何か問題が起こった際、まずは本手順にて資料を採取いただければ、後で採取された情報から調査することも可能であり、採取された資料を Microsoft に送信することで、自動的に存在する可能性のある問題を見つけることもできます。
なお、本ツールによる情報を行う際には、一時的に CPU 使用率が上がる可能性がありますので、予めご注意ください。
// 事前準備
用意していただくものは Microsoft アカウントだけです。 Microsoft アカウントは以下のサイトより入手してください。
Microsoft アカウントhttp://www.microsoft.com/ja-jp/msaccount/default.aspx
// 資料の採取手順
今回は、Windows セットアップ関連の情報を採取する方法をご紹介します。
本手順は採取された情報は手元に保存しておけるので、一般的な情報を採取し、後で解析する場合にも有効です。
– “Portable_Diagnostic.exe” の取得 –
1. 以下のサイトにアクセスします。 (Microsoft アカウントでサインインしていない場合には、サインインページにリダイレクトされます。)
Support Diagnostics
https://wc.ficp.support.microsoft.com/SelfHelp?knowledgebaseArticleFilter=&lcid=1041
2. “Windows セットアップのトラブルシューティング ツール” の診断パッケージを選択します。
3. [作成] ボタンを押下し、ダウンロードを選択し、実行ファイル (.exe) を保存します。
4. 実行ファイルを起動し、その場で実行するか、他のマシンで実行するか選択します。
5. “Save to run later on another PC” を選択した場合、任意の場所に “Portable_Diagnostic.exe” を保存できます
– “Portable_Diagnostic.exe” の実行 –
1. “マイクロソフト自動トラブルシューティングサービス” が起動しますので、同意する」をクリックします
2. ウィザードにしたがって情報の採取を実施します。
3. 送信するファイルのチェックがありますが、採取したくないファイルがある場合にはチェックを外して、「次へ」をクリックします。
4. 実行完了後、採取されたファイルを保存します。
なお、採取されたファイルをその場で保存することもできますし、Microsoft に送信することもできます。
Microsoft に送信した場合には、サインインしているアカウントにメールで解析結果が届きます。
// 参考情報
マイクロソフト自動トラブルシューティング サービスとサポート診断プラットフォームについて
http://support.microsoft.com/kb/2598970
こんにちは。 Windows プラットフォーム サポート 三浦です。
今回は DevNodeClean で削除対象のデバイスに関してご紹介させて頂きます。
DevNodeClean では、すでに接続されていない等の理由により、不要となったデバイスのレジストリ情報を削除します。
その際に削除対象としている Device Class は以下の通りです。
{4d36e967-e325-11ce-bfc1-08002be10318} : DiskDrive
{71a27cdd-812a-11d0-bec7-08002be2092f} : Storage Volumes
{533c5b84-ec70-11d2-9505-00c04f79deaf} : Storage Volume Snapshots
また、処理の中で、setupapi が呼ばれ、合わせて以下も削除されます。
{53f56307-b6bf-11d0-94f2-00a0c91efb8b} : GUID_DEVINTERFACE_DISK
{53f5630d-b6bf-11d0-94f2-00a0c91efb8b} : GUID_DEVINTERFACE_VOLUME
{7f108a28-9833-4b3b-b780-2c6b5fa5c062} : GUID_DEVINTERFACE_HIDDEN_VOLUME
System-Defined Device Setup Classes Available to Vendors
http://msdn.microsoft.com/en-us/library/windows/hardware/ff553426(v=vs.85).aspx
これら削除対象のデバイスは DevNodeClean の Version によって更新される可能性がある為、新しい Version で更新がされ次第、改めて Blog でご案内させて頂きます。
Microsoft DevNodeClean
http://www.microsoft.com/en-us/download/details.aspx?id=42286
Windows Server 2003 またはそれ以降のバージョンを実行しているコンピューターで再び使用されることはありません、デバイスのレジストリ情報を削除する方法
http://support.microsoft.com/kb/934234/ja
<Enlish follows Japanese>
こんにちは。日本マイクロソフトの徐です。
今回は、Windows 7 環境で動作するアプリケーション/プロセスが、既にアンロードされた ws2_32.dll を参照し、異常終了する場合がある問題についてご紹介します。
現象について
+++++++++++
Windows 7 環境で動作するアプリケーション/プロセスが、既にアンロードされた ws2_32.dll を参照し、異常終了する場合があります。
発生原因について
+++++++++++++
アプリケーション/プロセスにおいて、ロードする DLL モジュールの初期化処理 (DllMain 関数) の延長上で、API WSAStartup を呼び出す実装が含まれる場合、本現象が発生する可能性があります。 DllMain 関数からAPI WSAStartup を呼び出す制限事項の詳細につきましては、以下技術情報をご参照ください。 WSAStartup function http://msdn.microsoft.com/en-us/library/windows/desktop/ms742213(v=vs.85).aspx
The WSAStartup function typically leads to protocol-specific helper DLLs being loaded. As a result, the WSAStartup function should not be called from the DllMain function in a application DLL. This can potentially cause deadlocks. For more information, please see the DLL Main Function
http://go.microsoft.com/fwlink/p/?linkid=109533
本事象は、DLLモジュールのDllMain 関数の実装による問題ですが、CEIP機能が動作することにより問題が顕在化します。
解決方法について
++++++++++++++++
恒久的な解決策としては、DllMain 関数の処理中にAPI WSAStartup を呼び出す DLL モジュールの製造元にお問い合わせください。
DLL モジュールの製造元から恒久的な解決策を入手するまで、一時的な回避方法としては、カスタマー エクスペリエンス向上プログラム (Customer Experience Improvement Program, 以降 “CEIP” と表記) の無効化を行うことで、本現象を回避できる可能性があります。
CEIP を無効化するには、以下のレジストリ値を設定します。 レジストリキー：HKLM\Software\Microsoft\SQMClient\Windows\CEIPEnable 値：0（無効） http://msdn.microsoft.com/en-us/library/dd405474(VS.85).aspx
補足情報について
補足情報1：本現象が発生する条件(DllMain の実装問題が顕在化する条件) について 本現象が発生する条件は、以下 2 つの CEIP に関わるレジストリキーの値が共に 1 に設定される場合です。 HKLM\Software\Microsoft\SQMClient\Windows\CEIPEnable HKLM\SOFTWARE\Microsoft\SQMClient\Windows\CEIPSampledIn レジストリキー CEIPEnable は、CEIP 機能が有効するかどうかを制御するためのレジストリキーです。 CEIPEnable の値が 1 に設定された場合、CEIP 機能は有効となります。 EIPEnable の値が 0 に設定された場合、CEIP 機能は無効となります。 レジストリキー CEIPSampledIn は、CEIP 機能を有効に設定した場合に、対象マシンから収集されたCEIP 情報をマイクロソフトへ送付するかどうかを制御するためのレジストリキーです。 CEIPSampledIn の値が 1 に設定された場合、収集されたCEIP に関わる情報をマイクロソフトへ送付します。 CEIPSampledIn の値が 0 に設定された場合、CEIP に関わる情報をマイクロソフトへ送付しません。 補足資料2：レジストリキー CEIPSampledIn の設定、及びその必要性について wsqmcons.exe と呼ばれるアプリケーションは、Windows 7 インストール時にタスク スケジューラに登録され、19 時間間隔で実行されます。 本アプリケーションの実行時に、レジストリキー CEIPSampledIn が追加/変更される可能性があります。 タスク スケジューラ ライブラリ -> Microsoft -> Windows -> Customer Experience Improvement Program -> Consolidator レジストリキー CEIPSampledIn の値は、基本的に以下の三つのレジストリキーにより決まります。 そのうち、レジストリキー RacSampleNumber は、8 バイトの乱数を基に作成されます。 HKLM\Software\Microsoft\SQMClient\Windows\CEIPSamplingRangeLow (既定値は 1)
HKLM\Software\Microsoft\SQMClient\Windows\CEIPSamplingRangeHigh (既定値は 10,000,000)
HKLM\Software\Microsoft\Reliability Analysis\RAC\RacSampleNumber (最大値は 0xFFFFFFFF = 4,294,967,295 までの乱数) 上記 3 つのレジストリキーに対して、以下の条件を満たす場合には、CEIPSampledIn の値が 1 に設定されます。 条件を満たさない場合には、CEIPSampledIn の値が 0 に設定されます。 CEIPSamplingRangeLow の値 <= RacSampleNumber の値 <= CEIPSamplingRangeHigh の値 上記のような実装を行う理由としては、CEIP 機能を有効に設定するマシンが膨大な数になる可能性があるためです。 そのため、CEIP 情報のマイクロソフトへの送付を、サンプリングするように実装されます。 すなわち、上記の条件を満たした場合（RacSampleNumber の値は 1 ～ 10,000,000 の範囲内である場合）のみ、該当マシンは CEIP のサンプリングの対象となり、CEIPSampledIn が 1 に設定され、CEIP 情報をマイクロソフトへ送付します。 RacSampleNumber の値が 1 ～ 10,000,000 の範囲外の場合には、該当マシンは CEIP のサンプリングの対象外となり、CEIPSampledIn が 0 に設定され、CEIP 情報をマイクロソフトへ送付しません。
本現象に関する日本語技術情報は、以下KB2979267をご参照ください。
アプリケーション／プロセスは、既にアンロードされた ws2_32.dll を参照し、異常終了する場合があります。
http://support2.microsoft.com/kb/2979267/ja
カスタマ エクスペリエンス向上プログラム（CEIP）の詳細及びマイクロソフトへ送付されるCEIPレポートに含まれる情報の詳細につきましては、以下技術情報をご参照ください。 Microsoft カスタマ エクスペリエンス向上プログラム http://www.microsoft.com/products/ceip/JA-JP/default.mspx
Microsoft® カスタマ エクスペリエンス向上プログラムのプライバシーに関する声明 http://www.microsoft.com/products/ceip/JA-JP/privacypolicy.mspx
SYMPTOMS
--------------------
Application/Process crashes when referencing unloaded ws2_32.dll in Windows 7.
CAUSE
Application/Process crashes when API WSAStartup is called from initializing process (DllMain function) in an application DLL.
For the limitations of calling API WSAStartup by DllMain function, visit the following Microsoft website:
WSAStartup function
http://msdn.microsoft.com/en-us/library/windows/desktop/ms742213(v=vs.85).aspx
The WSAStartup function typically leads to protocol-specific helper DLLs being loaded. As a result, the WSAStartup function should not be called from the DllMain function in a application DLL. This can potentially cause deadlocks. For more information, please see the DLL Main Function(http://go.microsoft.com/fwlink/p/?linkid=109533).
The root cause is the way of an implementation of DllMain function in an application DLL. However, this issue only occurs when CEIP is enabled.
RESOLUTION
To resolve this issue permanently, please contact the application vendor of an application DLL calling the DllMain function.
However, you may disable Customer Experience Improvement Program (CEIP) by setting the following registry key as a temporary workaround before you get the permanent solution from application vender.
KEY：HKLM\Software\Microsoft\SQMClient\Windows\CEIPEnable
VALUE：0（Disabled）
http://msdn.microsoft.com/en-us/library/dd405474(VS.85).aspx
ADDIONAL INFORMATION
--------------------------------
Additional Information 1: The conditions of the issue occurs.
This issue occurs when both of the following registry keys related to CEIP are set to 1.
HKLM\Software\Microsoft\SQMClient\Windows\CEIPEnable
HKLM\SOFTWARE\Microsoft\SQMClient\Windows\CEIPSampledIn
CEIPEnable key is to enable or disable CEIP.
CEIP is enabled when CEIPEnable key is set to 1.
CEIP is disabled when CEIPEnable key is set to 0.
CEIPSampledIn key is to decide to send CEIP information to Microsoft.
CEIP information is sent when CEIPSampledIn is set to 1.
CEIP information is not sent when CEIPSampledIn is set to 1.
Additional Information 2: CEIPSampledIn key setting and the needs.
wsqmcons.exe is run every 19 hours by task scheduler in Windows 7 by default.
When wsqmcons.exe is run, CEIPSampledIn is possibly changed or added.
Task Scheduler Library -> Microsoft -> Windows -> Customer Experience Improvement Program -> Consolidator
The value of CEIPSampledIn is basically decided by the following three registry keys.
RacSampleNumber key is created based on a 8 bytes random number.
HKLM\Software\Microsoft\SQMClient\Windows\CEIPSamplingRangeLow (Default value is 1)
HKLM\Software\Microsoft\SQMClient\Windows\CEIPSamplingRangeHigh (Default value is 10,000,000)
HKLM\Software\Microsoft\Reliability Analysis\RAC\RacSampleNumber (Max value is a random number up to 0xFFFFFFFF = 4,294,967,295)
CEIPSampledIn is set to 1 when the following condition is met or else CEIPSampledIn is set to 0.
The value of CEIPSamplingRangeLow <= The value of RacSampleNumber <= The value of CEIPSamplingRangeHigh
The systems enabled CEIP may become huge amount. Therefore, CEIP infomation is sampled by the above implementation. More specifically, only when the above condition is met (RacSampleNumber is between 1 and 10,000,000), the system's CEIP becomes a sampling target.
Therefore CEIPSampledIn is set to 1 and CEIP infomation is sent to Microsoft. When RacSampleNumber is not between 1 and 10,000,000 the system's CEIP does not become a sampling target and CEIP information is not sent to Microsoft.
For the information of Customer Experience Improvement Program (CEIP), visit the following Microsoft website:
Microsoft Customer Experience Improvement Program http://www.microsoft.com/products/ceip/en-us/default.mspx
Privacy Statement for the Microsoft® Customer Experience Improvement Program http://www.microsoft.com/products/ceip/en-us/privacypolicy.mspx
こんにちは。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 が少しでも皆様のお役に立てれば幸いです。
こんにちは。Windows プラットフォーム サポートの加藤です。本日は、ノード再起動後にクラスター サービスが起動できなくなる障害事例についてご紹介します。
今回ご紹介させていただく内容としましては以下の3 点です。
<障害内容><回避策><原因特定の調査について>
<障害内容>ノードを再起動させた際に、イベント ログに以下のエラーが記録され、クラスター サービスの起動に失敗する。
-------------------------------ログの名前: Systemソース: Service Control Managerイベント ID: 7024レベル: エラー説明:Cluster Service サービスは、サービス固有エラー ログ サービスで、無効なログ ブロックが見つかりました。 で終了しました。-------------------------------
また、クラスター ログには以下のエラー ログが記録されます。
---------------ERR [CS] Service CreateNodeThread Failed, ERROR_LOG_BLOCK_INVALID(6609)' because of '::CreateLogFile( fileName.c_str(), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, sa, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL )'---------------
上記ログに記録された [無効なログ ブロックが見つかりました。] と [ERROR_LOG_BLOCK_INVALID(6609)'] は、クラスター サービスが使用するファイルの一部である clusdb.blf というファイルが破損している場合に発生することが確認されています。クラスターは起動時にこのファイルを読み込みますが、ファイルが破損していると正しく内容を読み込めず、サービスの起動に失敗します。
- クラスタ ログはどこ？http://blogs.technet.com/b/askcorejp/archive/2009/04/21/windows-server-2008-failover-clustering.aspx
<回避策>本ファイルは、削除またはリネームすることで Cluster Service 起動時に自動的に再作成されます。万が一上記の問題が発生した場合には、以下の手順にて clusdb.blf ファイルを再作成し、Cluster Service が正常に起動するかどうかご確認ください。
1. c:\windows\cluster\clusdb.blf を clusdb.old などの名前にリネームします。2. [サービス] 管理コンソールや net start clussvc コマンドを利用して、Cluster Service を起動します。
上記ファイルを再作成する事でのシステム影響はございません。
<原因特定の調査について>ファイル破損の原因は、その破損の瞬間を捉えた詳細調査が必要となり、明確な判断は往々にして困難です。しかし、論理的には以下の要因が挙げられます。
A. ディスク関連の障害B. ウイルス対策ソフトウェアがファイルへアクセスした場合
それぞれの詳細は以下の通りです。
-----------A. ディスク関連の障害-----------イベント ログに NTFS 関連のエラーやディスク関連のエラーが記録されている場合には、ディスク関連の障害でファイルが破損した可能性もございます。なお、NTFS のエラーは、通常 ID:55 などが記録されます。これらエラーが記録されていた場合には、ハードウェアベンダー様へハードウェアのチェックの依頼をお願いします。
-ソース : NTFS、ID: 55 のイベントhttp://blogs.technet.com/b/askcorejp/archive/2013/03/11/ntfs-id-55.aspx
------------------B. ウイルス対策ソフトウェアがファイルへアクセスした場合----------ウイルス対策ソフトウェアがファイルへアクセスした際に、クラスターサービスによる同ファイルへの適切なアクセスが妨害され、これにより、ファイルのデータが不正な状態に陥った可能性も考えられます。弊社では Windows Server 2008 のフェールオーバー クラスタ (WSFC) 環境において、ウイルス対策ソフトウェアのスキャンの対象から除外すべきフォルダーを以下の Blog で公開しております。この除外対象のフォルダには、今回問題の発生したファイル clusdb.blf の配置されている %systemroot%\Cluster も含まれております。そのため、もし除外対象になっていない場合には、切り分けと安定運用のために、除外の設定をお願いいたします。
クラスタ環境でのウィルス スキャンの除外設定についてhttp://blogs.technet.com/b/askcorejp/archive/2010/06/10/wsfc.aspx
アンチウイルス スキャン対象から除外したいファイルやフォルダhttp://blogs.technet.com/b/jpepscrt/archive/2010/04/28/3328757.aspx
こんにちは。日本マイクロソフトの松岡です。 今回は、比較的よくお問い合わせをいただく NTFS 55 についてご紹介します。
------------------- イベントの種類: エラー イベント ソース: NTFS イベント ID: 55 説明: ディスク上のファイル システム構造が壊れていて使えません。chkdsk ユーティリティをボリューム "Drive_letter" で実行してください -------------------
ソース : NTFS、ID: 55 のイベントについて
ソース : NTFS、ID: 55 のイベントは、ファイルシステム データ構造に不整合を発見した場合に記録されるイベントです。このイベントが記録されるタイミングとしては、ファイル システム構造が破損した状態で、その破損個所にアクセスした際に記録されます。また、破損時点と 本イベントが記録された時点には差異があり、この情報からその前に何が発生したのか原因追求を行うことは困難です。したがって、オペレーションの観点から特に問題がない場合、関連するデバイス ドライバーや、ファームウェアのアップデートを行うことが一般的な対策です。
一般的な本イベントの要因について
一般的にこの破損が発生する原因としては、以下の状況が考えられます。
1. 不正なシャットダウンが発生した場合
不正なシャットダウンが発生すると、ディスク上の情報を正しく保存せずにシステムが終了するため、ファイル システムに不整合が発生する可能性があります。
2. ハードウェアの破損による場合
ハードウェアの破損、故障により、ディスク上のデータが破損して不整合が発生する可能性があります。
3. ディスクが突然取り外れた、あるいは、アクセスできなかった場合
ディスクが突然取り外れた、あるいは、アクセスできなくなったような場合には、1 同様、ディスク上の情報が正しく保存されず、ファイルシステムに不整合が発生する可能性があります。
4. ドライバやアプリケーションによる不正なアクセスがあった場合
ファイル システム ドライバーや、その他カーネル モードのコンポーネントの不具合により発生する可能性があります。ドライバーやアプリケーションによっては、NTFS ファイル システムを経由せずに、ディスクへ直接アクセス、書き込みを行うものがあります。これらの作用により、 NTFS の意図しない変更がディスク上のデータに加えられ、破損が発生する場合があります。または、ドライバーやアプリケーションによりディスクへのアクセスが突然遮断され、3 のような状況となり、現象が発生する可能性も考えられます。
本イベントへの対応について
本イベントへの対応としては、フォーマット後にバックアップからデータを復元するか、修復モードでの chkdsk コマンドを実施します。なお、大容量のボリューム で chkdsk を実行する場合、ボリュームのサイズやマシンのスペック等により、所要時間が非常に長くなることがあります。システムのダウンタイムを考慮した場合、修復モードでの chkdsk の実行よりフォーマットによる対応方法の方が、より少ないダウンタイムで対応が完了する状況も考えられます。事象が発生した環境により、フォーマット後にバックアップ データを復元、または修復モードでの chkdsk の実行を検討してください。
1. Chkntfs コマンドによる破損が発生しているボリュームの確認
2. フォーマットによる対応
3. 修復モードでの chkdsk コマンドによる対応
※ 対応は 2、3 のいずれかの対応で問題ありません。(両方実施する必要はありません。)
1. Chkntfs コマンドによる破損が発生しているボリュームの確認について
ファイル システムの破損が発生しているボリュームを特定するには、chkntfs コマンドが使用できます。
※ Chkntfs コマンドは、ファイル システムの状態を参照するコマンドのため、サーバーへの大きな負荷はかかりません。
実行例)
> Chkntfs C:
ファイル システムの破損が発生していない場合の実行結果
######################################## ファイル システムの種類は NTFS です。 C: は正常です。 ########################################
ファイル システムの破損が発生している場合の実行結果
######################################## ファイル システムの種類は NTFS です。 C: が正しくありません。 ########################################
- 参考情報
Chkntfs
http://technet.microsoft.com/ja-jp/library/cc731298(v=ws.10).aspx
2. フォーマットによる対応について
フォーマットによる対応をされる場合には、必要に応じて該当ボリュームにあるデータを別の領域に退避し、ボリュームを再フォーマットします。フォーマットの完了後、必要に応じて、退避したデータをリストアします。
3. 修復モードでの chkdsk コマンドによる対応ついて
chkdsk コマンドはオプションが指定されていない場合、読み取り専用モードで実行されます。chkdsk を /R または /F オプションを指定することにより、ファイルシステムの不整合を修復することができます。なお、修復モードでの chkdsk コマンドを実行した場合でも、実際に破損しているデータについては、修復することはできませんが状態が悪化することはありません。修復モードの chkdsk の実行によりファイル システムの不整合が修復されます。
> chkdsk c: /R
なお、chkdsk d: /R の実行時に、何らのプロセスが実行対象のボリュームを利用している場合には、以下のメッセージが表示されます。
コマンドの実行結果
######################################## ボリュームが別のプロセスによって使用されているため、Chkdsk を実行できません。 Chkdsk を実行するにはこのボリュームのマウントを解除する必要があります。########################################
メッセージ1
######################################## このボリュームを強制的にマウントを解除しますか? (Y/N) ########################################
メッセージ2
######################################## ボリュームが別のプロセスで使用されているため、CHKDSK を実行できません。次回のシステム再起動時に、このボリュームのチェックをスケジュールしますか (Y/N)? ########################################
いますぐ chkdsk /R を実行する場合には、メッセージ1 にて Y を、再起動時に chkdsk /R を実行する場合には、メッセージ2 にて Y を選択し実行します。
- 補足
オプション /R を指定した場合は、/F も暗黙的に指定されます。対象のボリュームに対して chkdsk /R または /F コマンドの実行によりセクタの修復を試みます。/R は /F に加えて物理的な不良セクタのチェックを行います。
Chkdsk.exe で使用可能な新しいスイッチ /C および /I について
http://support.microsoft.com/kb/314835/ja
Chkdsk
http://technet.microsoft.com/ja-jp/library/cc730714(WS.10).aspx
再発防止策について
ハードウェアの破損以外の原因で 本イベントが発生した可能性が考えられる場合には、関連するデバイス ドライバーやファームウェアの最新バージョンを確認し、アップデートを行います。 OS 観点では、ファイルシステム ドライバーの既知の不具合により発生している可能性がありますので、最新の修正プログラム (NTFS.sys) を適用します。また Windows 7、Windows Server 2008 R2 RTM では、NTFS 55 が誤検知されるという、Ntoskrnl.exe の不具合がありますので、こちらも最新の修正プログラムを適用します。
2014 年 9 月 9 日時点の各 OS に対する最新の修正プログラムは以下のとおりです。
- Windows Server 2003
文書番号: 973870
Windows Server 2003 をランダムに実行しているコンピューターは、データをバックアップするときを応答を停止します。
http://support.microsoft.com/kb/973870
- Windows Vista、Windows Server 2008
文書番号: 2951098
Event ID 137 is logged when you back up the system state in a 32-bit version of Windows Server 2008
http://support.microsoft.com/kb/2951098
- Windows 7、Windows Server 2008 R2
文書番号 : 2885209
イベント ID 55 が Windows 7 SP1 または Windows Server 2008 R2 SP1 ベースのファイル サーバーで記録され、Windows がクラッシュすることがある (2014 年 2 月 14 日)
http://support.microsoft.com/kb/2885209
文書番号: 2981965 (Ntoskrnl.exe)
更新管理に Windows のファイル システム ドライバーがすべてのシリアル化のフラッシュ メモリを削除するには
http://support.microsoft.com/kb/2981965
-Windows Server 2012
文書番号: 2973052
Windows Server 2012 R2 または Windows Server 2012 でボリュームがマウントされているときに"0x00000018"の停止エラー
http://support.microsoft.com/kb/2973052
-Windows Server 2012 R2
文書番号: 2975719
Windows RT 8.1、8.1 の Windows、および Windows Server 2012 の R2 用の更新プログラムのロールアップ 2014年 8 月
http://support.microsoft.com/kb/2975719
※ 2014 年 4月以降にリリースされる全ての Windows Server 2012 R2 および Windows RT 8.1、Windows 8.1 におけるアップデートやセキュリティ更新プログラム/修正プログラムは KB 2919355 の適用が前提条件として必要となります。そのため、KB 2975719 を適用する前に、KB 2919355 を適用してください。
-文書番号: 2919355Windows RT 8.1、8.1 の Windows および Windows Server 2012 の R2 の更新プログラム: 2014 年 4 月http://support.microsoft.com/kb/2919355
KB 2919355 につきましては、以下のブログも併せてご確認ください。
Windows 8.1 Update が公開されました。http://blogs.technet.com/b/askcorejp/archive/2014/04/09/windows-8-1-update.aspx
EVENT ID 55: When Good Bits Go Bad
http://blogs.technet.com/b/askcore/archive/2012/05/09/event-id-55-when-good-bits-go-bad.aspx
最近、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 プラットフォーム サポートの北原です。最近、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) メモリ ダンプとは
====================================
メモリ ダンプ ファイルは、システムのある瞬間の物理メモリの情報をファイルとして出力させたものです。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 プラットフォーム サポートのけまるやです。
最近、Windows 8 や Windows 8.1 環境をお使いの方から "デバイスとプリンター" 画面に削除できないプリンターのアイコンが出現するという現象についてお問い合わせをいただくことがあります。
この問題は弊社でも詳しい調査が行われておりますが、事象を改善する方法が見つかりましたため、ご紹介させていただきます。
弊社では、複数のユーザーが 1 台のコンピューターにログオンすることがある端末において、以前コンピューターを使用していたユーザーがログオフ後、コンピューターの再起動や、印刷スプーラー サービスの再起動が発生すると、別のユーザーがログオンしたときに、"デバイスとプリンター" 画面に以前ログオンしていたユーザーが使用していたネットワーク共有プリンターのアイコンが見えてしまう事象が発生することが報告されております。
この時に表示されるネットワーク共有プリンターは、もともとログオンしていたユーザーでも削除できず、管理者権限を使用しない限り、削除できません。
以下は今回の事象を再現したときのビデオです。ネットワーク共有プリンターを削除しても復活してしまったり、そもそも削除できないプリンターが出現したりします。
お問い合わせの問題が発生しており、対処が必要な場合には、まずは以下の画面のように RemovePrintersAtLogoff のレジストリ値を 1 に設定いただくことをご検討ください。
キー : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider名前 : RemovePrintersAtLogoff種類 : REG_DWORD値 : 1
※レジストリ設定後の参考画像です
Windows では、ユーザーがネットワーク共有プリンターに接続したとき、次回ログオン時にすぐにネットワーク共有プリンターが使えるよう、情報の一部をキャッシュします。今回の問題は、このキャッシュの情報の一部に問題が発生することで、ほかのユーザーのプリンターが見えてしまう問題であることがわかっています。
RemovePrintersAtLogoff のレジストリ設定を行い、印刷スプーラー サービスを再起動いたしますと、ユーザーのログオフ時にプリンターのキャッシュ情報を削除するようになります。
また、RemovePrintersAtLogoff のレジストリ設定を行っても、すべてのキャッシュ情報がすぐに削除されるわけではありません。削除できないプリンターをすぐに消したい場合には、管理者権限を持ったアカウントで以下の対処策を実施いただき、状況が改善されるかどうかをご確認ください。
印刷スプーラー サービスを停止します。
レジストリ エディタを開き、以下のレジストリ キー配下を空にします。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider
RemovePrintersAtLogoff を 1 に設定します。
印刷スプーラー サービスを再開します。
デバイスとプリンター画面を開きます。
削除できなかったプリンターのアイコンをそれぞれ右クリックして、削除を実行します。
※プリンターの削除画面
弊社では、この問題について引き続き調査を継続していますので、新しい情報がわかりましたらお伝えしたいと思います。
こんにちは、Windows プラットフォーム サポート担当の頂です。
今回は、ファイルやフォルダーを削除されないようにするためのアクセス権設定をコマンドから実行する方法についてご紹介いたします。ファイルやフォルダーを削除されないようにするためには、フォルダーやファイルの [プロパティ] の [セキュリティ] タブから、削除を拒否するためのアクセス権設定を変更することでできますが、今回は、同様の設定を icacls コマンドを使用して行う場合の手順と注意点について、ご紹介いたします。
icacls コマンドとは----------------------------------------------------フォルダーやファイルのアクセス権について設定へ変更などを行う事ができるコマンドです。Windows Server 2003 SP2 で提供され、Windows Vista ( Windows Server 2008 ) 以降では、標準のコマンドとして実装されました。
- 設定方法まずは、ファイルやフォルダーについて、削除や読み取りなどを拒否する場合に利用できる、”拒否” のアクセス権を設定するコマンドについてご紹介いたします。
“拒否” のアクセス権を設定する際のコマンド基本型--------------------------icacls "<対象のファイルまたはフォルダーのパス>" /deny "<ユーザー名>":(拒否対象の権限)
ファイルやフォルダーについて、削除させないようにするために、"削除 (DELETE)" の権限を拒否に設定する場合には以下コマンドを利用します。
"削除 (DELETE)" の権限を拒否に設定する場合のコマンド--------------------------ファイルやフォルダーを削除されないように、"削除 (DELETE)" の権限を拒否に設定する場合には、“(拒否対象の権限)” 設定を必ず、(DE) と設定します。
icacls "<ファイルまたはフォルダーのパス>" /deny <ユーザー名>:(DE)コマンド例図
- 注意点icacls コマンドのヘルプでは、"D -削除のアクセス権" と記載されておりますが、下記コマンド例のように、"削除 (DELETE)" の権限を拒否設定する場合に、(D) を使用すると、/deny <ユーザー名> に指定したユーザーが、コマンド実行対象のファイルやフォルダーにアクセスできなくなります｡これは、“(拒否対象の権限)” に (D) を指定することで、"削除 (DELETE)" の権限だけで無く、"同期 (SYNCHRONIZE)" の権限も拒否されることによる動作となります。
コマンド例icacls "<ファイルまたはフォルダーのパス>" /deny <ユーザー名>:(D)
"同期 (SYNCHRONIZE)" の権限が拒否された場合には、以下手順でファイルやフォルダーにアクセス出来なくなります。
・ コンピューターにログオンした状態で、フォルダーやファイルにアクセスする。・ SMB2 を利用したネットワーク経由でフォルダーやファイルにアクセスする。
現在設定されているアクセス権を確認する場合にも、icacls コマンドは利用できますが、コマンド プロンプト上には､"同期 (SYNCHRONIZE)" の権限は表示されないため､ /Save オプションを利用して､ファイルへSDDL形式での出力、もしくは PowerShell の Get-Acl コマンドレッド での確認が必要となります｡そのため､ファイルへの出力をせずに､アクセス権の確認が必要な場合には、PowerShell の Get-Acl コマンドレッドをご利用ください。
PowerShell Get-Acl コマンドレッドの実行結果icacls "<ファイルまたはフォルダーのパス>" /deny <ユーザー名>:(D) コマンドを利用した場合には、"同期 (SYNCHRONIZE)" の権限が､DENY (拒否のアクセス権) に、設定されていることを確認できます。
なお、icacls コマンドのオプション設定により、アクセスが拒否される動作については、以下技術文書で公開いたしております。
文書番号: 2784859 icacls コマンドで、オブジェクトに削除拒否の設定を行うと、リモートからの接続時にアクセスが拒否されることがありますhttp://support.microsoft.com/kb/2784859/ja
Windows Server 2008 のアクセス制御の新機能http://technet.microsoft.com/ja-jp/library/cc731677(v=WS.10).aspx
Get-Acl コマンドレットの使用http://technet.microsoft.com/ja-jp/library/ee176838.aspx
こんにちは。Windows High Availability サポート チームの吉井です。
今日は、Windows Server 2012 R2 でWindows Server バックアップを実行した時に記録される、以下の 「ソース: disk、ID: 157」 の警告について説明したいと思います。
-------------------------------------
ソース: disk
イベント ID: 157
レベル: 警告
説明:
ディスク X が突然取り外されました。
Windows Server 2012 R2 では、ディスクの取り外しが行われた場合に、ソース: disk、ID: 157 の警告イベントを記録する機能が追加されています。運用中のシステムでディスクが取り外される状況 (取り外されたと認識される状況) は、一般的にディスク接続周りに何らかの問題が生じていることが多い状況ですので、このことを検知できるように Windows Server 2012 R2 で実装されました。
参考情報:
Event ID 157 "Disk # has been surprise removed"
http://blogs.msdn.com/b/ntdebugging/archive/2013/12/27/event-id-157-quot-disk-has-been-surprise-removed-quot.aspx
Windows Server バックアップでは、バックアップ データの保持形式として仮想ディスク イメージ (VHD/X) を採用しており、バックアップ処理中にこの仮想ディスクの接続と切断が発生します。
そのため、仮想ディスク切断時に disk、ID: 157 のイベントが記録されますが、これは Windows Server バックアップの動作として想定される動作となりますので、警告イベントによる悪影響はなく、安全に無視可能です。バックアップも正常に完了していれば、バックアップ データの整合性にも問題ありません。
無視可能ではあるものの、"警告" レベルでイベントが記録されることで、システム運用監視上の負担となる場合もありますので、仮想ディスクの切断時にはこの警告を出力しないようにする更新プログラムをリリースしています。
(この更新プログラムを適用しても、仮想ディスクの切断時に警告が記録されなくなるのみであり、実際に物理ディスクが取り外されたようなシナリオでは警告は出力されます。)
文書番号: 2955164
May 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2
http://support.microsoft.com/kb/2955164
この更新プログラムを適用することでイベント出力の抑止が可能です。
また、本事象について説明した技術情報もご紹介いたします。
文書番号: 2958027
Extraneous log entries are created when you remove virtual disk devices in Windows 8.1 or Windows Server 2012 R2
http://support.microsoft.com/kb/2958027
Windows Server 2012 R2 でWindows Server バックアップを実行した時に記録される、「ソース: disk、ID: 157」の警告は安全に無視可能です。
ただし、本警告を抑止したい場合には KB 2955164 の適用をご検討ください。
こんにちは。日本マイクロソフトの松岡です。
Windows Server 2003 や、Windows Server 2008、Windows Server 2008 R2 環境で Microsoft iSCSI イニシエーターを利用する際に、NIC をチーミングしたいというお問い合わせをいただくことがあります。しかしながら、Windows Server 2012 より前の OS では Microsoft iSCSI イニシエーターを利用する環境では、NIC のチーミングはサポートされていませんでした。これは、NIC チーミングは 3rd party 製のソリューションのみであったので、弊社製品ではない部分に動作が依存してしまうため、非サポートとさせていただいていました。
=== 注意事項 ===Windows Server 2012 または Windows Server 2012 R2 環境においても Microsoft iSCSI イニシエーター、及び Microsoft iSCSI ターゲットをご利用される NIC にて 3rd party 製チーミング アプリケーションを使用した NIC チーミングはサポートされません。==============
ただし、Windows Server 2012 より OS の機能である "負荷分散とフェールオーバー (LBFO)" を利用して NIC チーミングを構成した環境はサポートされます。
また、NIC を iSCSI 専用のインターフェースとして利用する場合 (他のサービス等では利用しない) には、LBFO を使用せず、MPIO のみで冗長構成を行うことを推奨しています。(NIC チーミングと MPIO 両方を構成すると重複した構成となり、複雑性を増す一方で利点がないため)
そのため、Windows Server 2012 または Windows Server 2012 R2 環境で、Microsoft iSCSI イニシエーター、または Microsoft iSCSI ターゲットを利用する際に、NIC チーミングをご利用されたい場合には LBFO をご利用ください。また、MPIO が利用可能な場合にはそちらもご検討ください。
- 参考情報 Is NIC Teaming in Windows Server 2012 supported for iSCSI, or not supported for iSCSI? That is the question… http://blogs.technet.com/b/askpfeplat/archive/2013/03/18/is-nic-teaming-in-windows-server-2012-supported-for-iscsi-or-not-supported-for-iscsi-that-is-the-question.aspx
NIC チーミングの概要 http://technet.microsoft.com/ja-jp/library/hh831648.aspx
こんにちは。Windows プラットフォーム サポートの吉田です。
今回は、Windows Server 2012 (R2 含む) における、標準的なリモート デスクトップ サービス環境の構築手順をご案内いたします。
なお、構築の前提条件といたしまして、対象サーバーが Active Directory に参加している環境としています。
ワークグループ環境での構築につきましては、以下を参照ください。
- Windows Server 2012 リモート デスクトップ環境の構成について
http://blogs.technet.com/b/askcorejp/archive/2012/12/28/windows-server-2012.aspx
また、本稿においては、[セッション ベースのデスクトップ展開] に特化した手順となっており、MS VDI (Virtual Desktop Infrastructure) 環境の構築には言及しておりません。
VDI 環境の構築につきましては、別途公開させていただく予定としています。
--------------------------------------------------------
Windows Server 2012 以降においては、リモート デスクトップ サービスおよび RemoteApp アプリケーションを公開するためには、同一ドメイン内に 下記の役割を持つサーバーが必須となっています。
なお、下記の役割は全て一台のサーバーに集約する事が可能です。
また、Windows Server 2012 以降においては、リモート デスクトップ サービスおよび RemoteApp を [セッション コレクション] という概念で、管理・公開いたします。
[セッション コレクション] の単位にて、複数台のセッション ホスト サーバーを管理する事が可能となっており、[サーバー マネージャー] 上に展開される [リモート デスクトップ 管理サービス (RDMS)] にて一元管理、設定が可能です。
[セッション ベースのデスクトップ展開] におきましては、以下 2 種類の展開方法があります。
一台のサーバーに展開する場合、[クイック スタート] での展開が簡易ですが、評価環境での構築を意図しているため、一台のサーバーに展開いただく場合においても、[標準の展開] を選択いただく事を推奨いたします。
以下の手順におきましては、[標準の展開] での構成方法をご案内いたします。
<サーバーの追加>
複数台のサーバーに各役割をインストールいただく場合には、接続ブローカーの役割をインストールいただくサーバーにおいて、各サーバーを管理対象としていただく必要があります。
一台のサーバーに全ての役割をインストールする場合には、この手順は必要ありません。
<役割のインストール>
< セッション コレクションの作成 >
<セッション コレクションのプロパティ>
<RemoteApp アプリケーションの公開>
<ライセンス サーバーのインストール>
<ライセンス モードの設定>
ライセンス サーバーのアクティブ化およびライセンスのインストールにつきましては、Windows Server 2008 R2 と同様となりますので、下記を参照願います。
- リモート デスクトップ ライセンス サーバーをアクティブ化する
http://technet.microsoft.com/ja-jp/library/cc771547.aspx
- リモート デスクトップ サービス クライアント アクセス ライセンスをインストールする
http://technet.microsoft.com/ja-jp/library/cc725890.aspx
上記までを実施いただくことで、標準的なリモート デスクトップ サービス環境が構成されます。
なお、Windows Server 2012 以降においては、RemoteApp アプリケーションは RD Web アクセスのポータル サイトからのご利用が標準となっています。
クライアントから、以下の URL にアクセスいただいてご利用ください。
https://(Web アクセス サーバー FQDN 名)/rdweb
例 : https://WebAccess.contoso.com/rdweb
今回は、デバイスのトラブルシューティングに利用頂けるツールをいくつかご紹介したいと思います。
===============(A) デバイスのトラブルシューティング ツール===============Windows 7 及び Windows 8 には、デバイスの問題を自動的に検出し、修復を試みるツールが OS に付属されています。何かデバイスの問題が発生した際には、まずこちらを試してみることをお勧めします。以下はトラブルシューティング ツールの起動手順です。
1. コントロール パネルを開きます2. [システムとセキュリティ] をクリックします3. [コンピューターの問題のトラブルシューティング] をクリックします4. [デバイスを構成する] をクリックします5. ウィザードに従ってトラブルシューティングを行います
Windows トラブルシューティング - Microsoft Windowshttp://windows.microsoft.com/ja-jp/windows7/products/features/windows-troubleshooting
Windows Vista は OS に組み込まれておりませんが、以下のページからツールの入手が必要です。
Windows でのトラブルシューティング - Windows ヘルプhttp://windows.microsoft.com/ja-jp/windows/troubleshooting-windows#troubleshooting-windows=windows-vista※ [ハードウェアおよびデバイスのトラブルシューティングを実行するには] の項にあります
===============(B) デバイス マネージャー===============トラブルシューティング ツールで問題が解決しない場合は、従来通り、デバイス マネージャーを利用します。
1. Windows キーを押しながら、Pause/Break キーを押下します2. [デバイス マネージャー] をクリックします
デバイス マネージャーが起動すると、現在接続されているすべてのデバイスが表示されます。まずは以下のようなアイコンが無いかを確認します。
1. 無効化アイコンに画像のような下矢印マークが付いている場合、そのデバイスは無効化されていることを示しています。デバイスが無効化されていると、PC はそのデバイスを使用できません。通常、デバイスが自動的に無効化されることはほとんどありません。何かの不具合があった場合に、人為的に無効化させる場合がほとんどです。
デバイスを有効化するには、対象のデバイスを右クリックし、[有効] をクリックします。
2. 不明なデバイス画像のように [ほかのデバイス] に含まれているデバイスは、該当するデバイスの種別が判別できなかったものになります。これは、多くの場合、必要なデバイス ドライバーがインストールされていないことによるものです。解決にはデバイスの開発元のサイトから最新のデバイス ドライバーを入手する必要があります。
そもそも、そのデバイスが何であるか分からない場合は、[詳細] タブの [プロパティ] から[デバイス インスタンス パス] を調べ、それをキーワードに指定してインターネット検索をしてみることをお勧めします。デバイスに関する情報が得られる場合があります。また、この方法で大した情報が得られなかった場合は、パスに含まれる VEN_XXXX の 4 桁の英数字と "Vender ID" という文字列、あわせて 2 つのキーワードを指定してインターネット検索をすると、製造元の企業名がヒットする場合があります。
3. エラーアイコンに画像のような ! マークが付いている場合、そのデバイスが何らかの理由で正常に動作していないことを示しています。発生しているエラーには様々な種類があり、種類ごとにエラー コードが割り振られています。当該のデバイスをダブルクリックすることで、エラー コードを確認することができます。
以下の KB には各エラー コードの説明と対応策が記載されています。これを参考に Windows 8.1 までの OS 上でトラブルシューティングを行うことができます。
Windows のデバイス マネージャーのエラー コード http://support.microsoft.com/kb/310123/ja-jp (日本語機械翻訳)http://support.microsoft.com/kb/310123/en-us (英語)
===============(C) devcon.exe===============devcon.exe は、デバイス マネージャーと同等の機能を持つコマンド ライン ツールです。コマンド プロンプトでデバイスのトラブルシューティングをする場合に最適です。
以下は devcon.exe を使ってデバイスを有効化した例です。
devcon.exe は、Windows Driver Kit (WDK) の中に含まれておりますので、WDK をインストールすることで、devcon.exe を入手できます。現在の最新の WDK のインストーラーは以下のページにあります。
WDK と WinDbg のダウンロードhttp://msdn.microsoft.com/ja-jp/windows/hardware/hh852365※ [WDK 8.1 Update のダウンロード] にあります
なお、WDK 8.1 内のデフォルトの devcon.exe の保存場所は以下のとおりです。
- x86 版 C:\Program Files (x86)\Windows Kits\8.1\Tools\x86\devcon.exe- x64 版 C:\Program Files (x86)\Windows Kits\8.1\Tools\x64\devcon.exe
詳細なツールの使い方は、以下の技術文書に記載があります。
デバイス マネージャーとして機能する DevCon コマンド ライン ユーティリティhttp://support.microsoft.com/kb/311272/ja
余談ですが、devcon.exe はデバイスのトラブルシューティング以外でも、スクリプトに組み込むことで日々の運用にも使用できます。例えば、現在 OS に接続されていないデバイスの中から、クラスが「ポータブル デバイス」のものを全て削除したい場合、以下のような VB スクリプトを用意することで実現できます。
on error resume next' 未接続を含む ポータブル デバイスの一覧を取得しますSet objShell = CreateObject("WScript.Shell")If UCase(objShell.Environment("Process").Item("PROCESSOR_ARCHITECTURE")) = "X86" Then strDevcon = "x86\devcon.exe"Else strDevcon = "x64\devcon.exe"End IfSet outExec = objShell.Exec(strDevcon & " findall =WPD")Set outStream = outExec.StdOut
' 現在接続されているデバイスの一覧を取得しますSet objWMIService = GetObject("winmgmts:\\.\root\cimv2")Set colServices = objWMIService.ExecQuery("Select * From Win32_PnPEntity")Do While Not outStream.AtEndOfStream strLine = outStream.ReadLine() arrFields = Split(strLine," ") FLG = 0 For Each objService in colServices ' Win32_PnPEntity の結果と devcon findall コマンドの結果を比較します If arrFields(0) = objService.DeviceID Then FLG = 1 Exit For End If Next ' 比較後、一致する情報が無い (未接続デバイ���) 場合、ドライバを削除します If FLG = 0 and not IsNumeric(arrFields(0)) Then If Right(arrFields(0), 1) = ":" Then strDevice = Left(arrFields(0), Len(arrFields(0)) - 1) else strDevice = arrFields(0) End If objShell.Run strDevcon & " remove @" & chr(34) & strDevice & chr(34) End IfLoopSet colServices = NothingSet outStream = NothingSet outExec = NothingSet objWMIService = NothingSet objShell = Nothing
スクリプトの簡単な解説ですが、devcon.exe の findall オプションを使うと、未接続のデバイスも含めた全てのデバイスのリストを出力させることができます。そして現在接続中のデバイスの一覧を WMI から取得し、それらを突き合せることで未接続のデバイスだけを抽出しています。
また、findall オプションの引数に "=" とクラス名を付けると、特定のクラスのデバイスのみを抽出することができます。ここではポターブル デバイス クラスだけを抽出するよう設定しています。findall オプションの詳しい指定方法については、以下の技術文書をご参照ください。
DevCon FindAllhttp://msdn.microsoft.com/ja-jp/library/windows/hardware/ff544761(v=vs.85).aspx
スクリプトの最後で、抽出した未接続のポータブル デバイスを remove オプションで一つ一つ削除しています。
※ 上記のスクリプトはあくまでサンプルです。ご使用の際には必要に応じてカスタマイズをし、 十分にテストをされた上でご使用ください。