Quantcast
Channel: Ask CORE
Viewing all 590 articles
Browse latest View live

DevNodeClean で削除される Device Class

$
0
0

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

 

 


マイクロソフト サポート診断パッケージについて

$
0
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 7 での RemoteFX USB リダイレクトについて

$
0
0

こんにちは。

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 以上を使用する必要があります。

RDS (TS) CAL について

$
0
0

こんにちは。

Windows プラットフォーム サポートの吉田です。

今回は、リモート デスクトップ サービス (旧ターミナル サービス) で利用される CAL (Client Access License) の概要および動作についてご説明いたします。

Windows Server に多数のセッションを同時に接続させるためには、リモート デスクトップ サービス環境を構築する必要がありますが、ご利用いただくためには、各クライアントに対して、リモート デスクトップ サービス クライアント アクセス ライセンス (RDS CAL) を発行します。

 ※ Windows Server 2008 までは、ターミナル サービス クライアント アクセス ライセンス (TS CAL) が正式名称となりますが、本稿では全て CAL と記載します。

 

CAL の動作原理や有効期限について、よくいただくご質問を以下にまとめました。

ぜひご参考ください。

 

1. CAL の概要

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

CAL は大きく以下の 2 種類に分類されます。

  • デバイス CAL
  • ユーザー CAL

この 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 権限のあるユーザーにて実施する必要があります。

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

 -参考文献

 リモート デスクトップ サービス クライアント アクセス ライセンス (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

パフォーマンス モニターの時刻表示ずれについて

$
0
0

こんにちは。Windows サポートチームの太田です。
 
今回はパフォーマンス モニターの表示に関する問題を確認いたしましたので、ご紹介いたします。

[概要]
パフォーマンス モニターを用いて、グラフにてリアルタイムのパフォーマンス データを表示させている際に、
実際のシステム時刻からずれた時刻が表示される場合があります。

[詳細]
この現象は、長期間連続稼働させていることによって表示上の問題が発生する場合があります。
パフォーマンスデータやグラフの描画自体はリアルタイムに正しく表示されますが、表示される時刻が実際のシステム時刻よりも過去の時刻が表示されます。

具体例を示します。

図の例では、システム時刻は 23:52 ですが、パフォーマンスモニターに表示されるリアルタイムの時刻は、17:52 となり 6時間遅れています。

[影響]
この事象は、パフォーマンスモニターの時刻表示に限定した問題で、時刻以外は正確な情報が表示されます。
また、データ コレクターを用いて採取するパフォーマンスログはこの影響を受けません。

[回避策]
定期的にパフォーマンスモニターを終了/起動していただくようお願いいたします。

[対象OS]
Windows Server 2008 /Vista 以降の Windows にて発生することを確認しております。

ご不便をおかけいたしますが、上記回避策にてご対応くださいますようお願いいたします。




スタートアップ修復の無効化について

$
0
0

こんにちは。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 Server 2012 R2 環境で Quota 6 イベントが記録される

$
0
0

こんにちは。

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

本日は、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 8.1 や Windows Server 2012 R2 での日本語 IME 辞書の更新について

$
0
0

こんにちは、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 現在


グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法

$
0
0

いつも弊社製品をご利用いただきまして誠にありがとうございます。
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 によるデバイスのアクセス制御を行うことも可能です。

 制御対象代表的なデバイス
CD および DVDCD および DVD
フロッピー ドライブUSB フロッピーを含むフロッピー
リムーバブル ディスクUSB メモリ、USB ディスク等
テープ ドライブテープ ドライブ
WPD デバイスメディア プレーヤー、デジタルカメラ、SD、MD、携帯電話(スマートフォン)等

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

グループ ポリシーを使用してリムーバブル デバイス アクセス制御を行う前に行っていただきたいこと

$
0
0

いつも弊社製品をご利用いただきまして誠にありがとうございます。
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)

 

----------------------------------------------------------------------------------------------------------------
1. グループ ポリシーを用いたデバイスのアクセス制御の設定が反映されない (Windows 8, Windows 8.1)

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

弊社では、Windows 8 および Windows 8.1 のクライアント PC に対してリムーバブル デバイスへのアクセス制御を行なった場合、意図した制御が行えなくなる事象が発生することを確認しております。
以下の 3 つの条件すべてに該当する構成の場合は、リムーバブル デバイスへのアクセス制御が正しく反映されませんのでご注意ください。


< 既知のグループ ポリシーを用いたデバイスのアクセス制御の設定が反映されない 3 つの条件>

 • 制御対象のクライアント PC が 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)

 

----------------------------------------------------------------------------------------------------------------
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)

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

こちらはグループ ポリシーが正しく適用されない現象に対する修正プログラムです。
修正プログラム適用後は再起動いただく必要がございます。

 

<KB 及び修正プログラム>

文書番号: 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

 

 

 

 

ロシアのタイム ゾーンが通年冬時間となる変更に対応した更新プログラムについて

$
0
0

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

2014 年 10 月にロシアのタイム ゾーンが通年冬時間となる変更が行われましたが、弊社ではそれに対応する
更新プログラムをこれまで 2 つ公開いたしました。本記事において、それぞれの目的について解説いたします。

 

========================
タイム ゾーン情報の変更について
========================
まずはその前提となる話として、更新プログラム適用によるタイム ゾーン情報の変更について
ご説明をさせていただきます。Windows OS では、各タイム ゾーンの設定 (サマー タイムの情報も含む)
をレジストリ上で管理しており、対応する更新プログラムを適用することで、その内容が正しいものに変更されます。

各政府機関がタイムゾーンの変更を公式発表すると、弊社ではその知らせを受けて、更新プログラム
(または、修正プログラムや Fix it) を公開しますが、今回のケースのようなサマー タイムの開始や廃止
といったケースでは、その開始と終了の 2 回の変更に対応するため、通常 1 対の更新プログラムを
リリースしております。

例えば、今年のモロッコのラマダンによるサマー タイムの変更については、以下の技術文書にある通り、
2 つの Fix it をリリースしており、時期をずらしてそれぞれを適用するようお願いしております。

2014 - Morocco Ramadan DST changes - Fix it solutions
http://support.microsoft.com/kb/2974661/en-us

 

========================
今年の 9 月 23 日に公開した KB2998527
========================
ロシアではこれまでサマー タイムを設定しておりましたが、これを 10 月 26 日から
通年冬時間で固定するとの公式発表がありました。弊社でもこれに対応するため、
更新プログラム KB2998527 を 9 月 23 日に公開しました。

A September 2014 time zone update for Russia is available
http://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 systems
http://support.microsoft.com/kb/3013410/en-us

 

========================
KB3013410 適用に関する注意事項
========================
以下の条件において、KB3013410 を手動または Windows Update で適用中に
「インストールが完了されませんでした。」といったエラー メッセージが出力されることがあります。

- Windows Server 2003 (日本語環境)
- タイム ゾーンをロシアのいずれかのタイム ゾーンに設定している
- KB2998527 を適用していない

このメッセージは無害なもので、インストール自体は問題なく完了しておりますので、
無視していただいて問題ございません。

 

========================
まとめ
========================
KB2998527 は今年の 10 月の冬時間への切り替えに対応するために用意されたものであり、
それを置き換える更新プログラム (KB3013410) が公開された現在においては、適用自体不要です。
それに伴って Windows Update からも外されております。

現在では、KB3013410 のみを適用いただくことで、ロシアのタイム ゾーンの通年冬時間への対応が
可能となります。以下の図はそれぞれの更新プログラムがカバーできる期間を示すものとなります。

[Hyper-V マネージャー] のトレース (Hyper-V UI トレース) について

$
0
0

こんにちは。

 

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>

        <setting name="VMConnectTraceLevel" type="System.Int32">

            <value>6</value>

        </setting>

        <setting name="InspectVhdTraceLevel" type="System.Int32">

            <value>6</value>

        </setting>

    </Microsoft.Virtualization.Client.TraceConfigurationOptions>

</configuration>

 

 

// Windows Server 2012 / 2012 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>127</value>

        </setting>

        <setting name="VMConnectTraceLevel" type="System.Int32">

            <value>127</value>

        </setting>

        <setting name="InspectVhdTraceLevel" type="System.Int32">

            <value>6</value>

        </setting>

    </Microsoft.Virtualization.Client.TraceConfigurationOptions>

</configuration>

 

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 Server 2012 R2 の Hyper-V クラスターの環境で Cluster.exe の CPU 使用率が増える

$
0
0

こんにちは。Windows プラットフォーム サポートの加藤です。
本日は、最近お問い合わせのあった Windows Server 2012 R2 の Hyper-V クラスター + SCVMM の環境で Cluster.exe の CPU 使用率が増える現象についてご紹介します。

<現象>
Windows Server 2012 R2 の Hyper-V クラスター + SCVMM の環境で、全ノードの Cluster.exe の CPU 使用率が 15 ~ 20 % まで増加します。


<原因>
この現象は Windows Server 2012 R2 の Hyper-V クラスター環境では "Global Update Manager" (GUM) の動作が以前のクラスターとは異なるために発生します。

※ "Global Update Manager" (GUM) はクラスターのノード間の同期とクラスター データベースの更新を実施するコンポーネントです。

"Global Update Manager" (GUM) の基本的な動作は、あるノードが更新の通知を送信し、更新通知を受け取ったノードはアップデートを実施後に、通知元のノードに応答を返します。
Windows Server 2012 以前のクラスターでは、すべてのノードから応答を受け取ったタイミングでクラスター データベースにコミットし、更新完了となっておりました。
つまりすべてのノードが更新を受け取り、応答を返さなければ、クラスター データベースにコミットできないため、更新を通知したノードはすべてのノードが処理を完了するまで待ち続けます。
この方法ですと 1 台でも更新処理に時間のかかるノードが存在していた場合、応答をすぐに返せず、その結果、当該処理の更新完了はまたされることになります。

Windows Server 2012 R2 では、この動作を変更できるようになり、DatabaseReadWriteMode が 1 の場合には、過半数のノードからの更新完了の応答を受け取れば、クラスター データベースにコミット可能としました。
これによりすべてのノードの更新完了を待ち続ける必要がないためパフォーマンスが向上します。

※ 既定では Hyper-V クラスター環境は、1 に設定されます。その他の構成では 0 に設定されます。
※ DatabaseReadWriteMode の値が 0 の場合は従来のモードで動作します。

しかしながら、DatabaseReadWriteMode が 1 の場合には、ノード間のクラスター データベースの情報に差異が生じます。
そのため、一貫性を強く求められるシナリオでは、この値を 0 にする必要がございます。

SCVMM を使用してる場合も DatabaseReadWriteMode が 1 の場合、SCVMM が全ノードにクエリを出して取得した情報に一貫性がないため、一貫性が得られるまでクエリを出し続け、その結果、Cluster.exe の CPU 使用率があがる現象が報告されておりました。

- 参考
What's New in Failover Clustering in Windows Server
http://technet.microsoft.com/en-us/library/dn265972.aspx#BKMK_GUM
Configure the Global Update Manager mode
Warning:
Do not use either of the majority modes (1 or 2) for scenarios that require strong consistency guarantees from the cluster database.
(クラスター データベースの強い一貫性を保証を必要とするシナリオでは、モード 1 または 2 は使用しないでください)


<回避策>
この現象は DatabaseReadWriteMode の値を 0 に変更していただくことで回避されます。(従来の GUM モード)
そのため、同様の構成で Cluster.exe の CPU 使用率が増加する場合には、管理者権限で以下の PowerShell のコマンドで値の変更をお願いいたします。

- 変更手順
(Get-Cluster). DatabaseReadWriteMode = 0

※ 再起動は不要です。

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

Windows Server バックアップ実行時に記録される、ソース: disk、ID: 157 の警告について

$
0
0

こんにちは。Windows High Availability サポート チームの吉井です。

 

今日は、Windows Server 2012 R2 Windows Server バックアップを実行した時に記録される、以下の 「ソース: diskID: 157」 の警告について説明したいと思います。

 

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

ソース:           disk

イベント ID:       157

レベル:           警告

説明:

ディスク X が突然取り外されました。

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

 

ソース: diskID: 157 のイベントについて

Windows Server 2012 R2 では、ディスクの取り外しが行われた場合に、ソース: diskID: 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 バックアップ実行時に記録される理由について

Windows Server バックアップでは、バックアップ データの保持形式として仮想ディスク イメージ (VHD/X) を採用しており、バックアップ処理中にこの仮想ディスクの接続と切断が発生します。

 

そのため、仮想ディスク切断時に diskID: 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 バックアップを実行した時に記録される、「ソース: diskID: 157」の警告は安全に無視可能です。

ただし、本警告を抑止したい場合には KB 2955164 の適用をご検討ください。

 

文書番号: 2955164

May 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2

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

注意

Hyper-V 環境において、ホスト側から VM 単位もしくは VM が格納されているボリュームのバックアップを実施した場合、VM 側にて一時的にバックアップのための複製ディスクが認識され切断されますが、VM 側から想定された切断と認識できないため本イベントについては更新プログラムを適用しても、抑止することはできません。ただし、本状況で記録された「ソース: diskID: 157」の警告は想定された切断となるため安全に無視可能です。

 

クラスター ノード間通信障害の一般的な対処方法について

$
0
0

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

最近いくつかいただいたお問い合わせで、フェールオーバー クラスターの構成ノードを再起動したところ、クラスターに参加できなくなった、というお問い合わせがありました。

これらのお問い合わせでは、ネットワーク ボードの IPv6 設定が無効 (ネットワーク ボードのプロパティからチェックボックス OFF) に設定されている状態でノードを再起動した所、クラスターに参加するタイミングで他のノードとのノード間通信に失敗し、参加に失敗するという事象が発生していました。

このような設定を行っている場合、ネットワーク ボードの IPv6 設定は無効になっているものの、OS の内部で使用されている仮想ネットワークでは IPv6 設定が有効になっておりシステム全体、たとえば Microsoft Failover Cluster Virtual Adapter 等では IPv6 が使用されております。

このような状態に陥っていた環境では以下の対処を行うことで改善されました。

 

IPv6 コンポーネントの無効化手順
-----------------
レジストリを変更して IPv6 コンポーネントを無効化します。

・対象レジストリ

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\

  (1) regedit.exe を起動して 対象レジストリアドレス に移動します。
  (2) メニューバーから [編集]-[新規]-[DWORD (32 ビット) 値] を選択します。
  (3) 名前には [DisabledComponents] と入力します。
  (4) [DisabledComponents] をダブルクリックし、以下の値を入力します。

  [DisabledComponents]
  値: ff (16進数)

  上記の設定行うことにより、IPv6 ループバック インターフェイス以外のすべての IPv6 コンポーネントを無効にし、さらにプレフィックス ポリシーを IPv6 ではなく IPv4 (Internet Protocol version 4) を使用します。

 (5) 上記の設定内容を反映させる為、システムを再起動します。

 

・参考 サイト
Windows Vista、Windows7、および Windows Server 2008 で特定の IPv6 (Internet Protocol version 6) を無効にする方法
http://support.microsoft.com/kb/929852/ja

連載 IPv6 入門 - 第三回 IPv6 の無効化方法
http://blogs.technet.com/b/jpntsblog/archive/2010/06/17/ipv6-3.aspx

 

もし、同じような現象が発生した場合には、IPv6 コンポーネントの無効化で改善されるかどうかご確認ください。

===============================================================================

 

■ノード間通信に問題が発生した場合の切り分けについて
----------------------------------------------------------------------
また、上記のようなノード間通信の問題によって障害が発生する場合、他に弊社では以下のような対処を実施いただき、切り分けをお願いしております。

 

1. すべてのノードの再起動
----------------------------------------------------------------------
事象発生ノードを含むすべてのノードを停止し、クラスターを一度停止した後、再起動を実施し、改善するかご確認ください。

 

2. クラスター モジュールの最新化
----------------------------------------------------------------------
非常に多くのお客様が RTM の環境や、Service Pack 1 のみ適用した環境で弊社にお問い合わせいただきます。

非常に多くの問題が累積にて修正されておりますので、システムの安定稼働のため、以下のエントリーでもご紹介させていただいております、最新のクラスター関連修正モジュールの適用をご検討ください。

クラスター環境に適用を推奨する修正プログラムについて
http://blogs.technet.com/b/askcorejp/archive/2012/08/16/3514648.aspx

Windows Server 2008 R2 では既知の不具合として、以下の修正プログラムが提供されております。

--クラスターへの再参加に関する問題。
Cluster node cannot rejoin the cluster after the node is restarted or removed from the cluster in Windows Server 2008 R2
http://support.microsoft.com/kb/2549472/en-us

--ノード間通信に関するクラスターの問題
A Windows Server 2008 R2 failover cluster loses quorum when an asymmetric communication failure occurs
http://support.microsoft.com/kb/2552040/en-us

A transient communication failure causes a Windows Server 2008 R2 failover cluster to stop working
http://support.microsoft.com/kb/2550886/en-us

ノード間通信に関する修正プログラムは 2550886 の修正プログラムを適用することにより、2552040 の不具合は解消されますので、2550886 の適用をご検討ください。

 

3. Scalable Networking Pack(SNP)およびタスクオフロードの機能の無効化
----------------------------------------------------------------------
SNP は従来 OS 側で行っていたネットワークパケット処理をネットワークボード 側に委任する機能で、Windows Server 2003 SP2 以降に含まれております。

無効化を行うにはドライバー側でオフロード関連の設定を無効にしていただいた後、OS側の設定も無効にしていただく必要がございます。

OS 側で設定可能な対処は以下のサイトをご覧ください。

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

 

4. ネットワーク ボード ドライバーの更新
----------------------------------------------------------------------
利用されている ネットワークボード ドライバー の製造元より、最新のドライバーを入手し、適用することで改善するかご確認ください。

 

5. サードパーティ製 の アンチウィルス、 Firewall ソフトについて
----------------------------------------------------------------------
過去弊社にお問い合わせいただきました中で比較的よくある事例として、サードパーティ製 の アンチウィルス、 Firewall ソフトがノード間通信を疎外していたために事象が発生していたケースがございました。

このような状況の場合、サービスのみ無効化を実施する場合ではフィルタ ドライバーなどが無効化されない為、事象が改善せずにプログラムのアンインストールを実施しないと事象が改善しないケースが多数ございます。

事象が発生した場合にはクラスターを構成しているすべてのノードにてプログラムのアンインストールをご検討ください

 

6. ノード間通信の問題についての技術情報
----------------------------------------------------------------------
クラスターのノード間通信に関する問題として、以下の技術情報を公開させていただいておりますので、ご紹介します。

今後の安定稼働のため、以下の技術情報ご確認いただき、設定の変更や修正モジュールの適用といった対処の実施をご検討いただければ幸いです。

UDP communication is blocked by the Windows Firewall rule in WSFC when the network connection is interrupted and then restored
http://support.microsoft.com/kb/2701206/en-us
[機械翻訳]
http://support.microsoft.com/kb/2701206/ja

The network location profile changes from "Domain" to "Public" in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2524478/en-us
[機械翻訳]
http://support.microsoft.com/kb/2524478/ja

 

もし、ノード間通信において問題が発生してお困りの状況であれば、上記の対処についてご検討いただければ幸いです。

 


LBFO (Load Balancing and Failover:負荷分散とフェールオーバー) をクラスター環境で使う場合の注意事項について

$
0
0

こんにちは。Windows プラットフォーム サポートの加藤です。
本日は、最近お問い合わせのあった LBFO (Load Balancing and Failover:負荷分散とフェールオーバー) をクラスター環境で使う場合の注意事項についてご紹介します。

<現象>
LBFO とは Windows Server 2012 から新しく実装された NIC のチーミング機能ですが、クラスター環境で、本機能を Active - Standby モードで設定していると、ハートビート通信の unreachable や場合によってはフェールオーバーが発生する可能性がございます。

<原因>
LBFO を Active - Standby モードで使用している場合、Active 側の NIC がリンクダウンし、全ての Active NIC が無くなると LBFO から上位のドライバーにメディアの切断が通知される仕様のため、この問題が発生します。
Active 側の NIC がリンクダウンした場合、以下のように状態が瞬時に遷移します。

(1) 1 つの Active NIC がダウンします。
(2) チーミングで Active NIC が存在しなくなるため、メディアの切断が上位ドライバ (netft.sys など) に通知されます。
(3) Standby NIC が Active に変化します。
(4) メディアの接続が上位ドライバーに通知されます。

クラスターでは、(2) でメディアの切断が通知されると、当該 NIC を使用して、他のノードとハートビート通信できなくなると判断され、直ちに unreachable となります。
(ハートビートのダウンのしきい値まで待つことなく直ちに unreachable となります。)
そのため、すべてのクラスター ネットワークでこの事象が発生するとすべてのノード間通信のルートが失われるため、リグループ処理が発生し、何れかのノードのクラスター サービスが停止します。
また、IP アドレス リソースを所有しているノードのパブリックネットワークでこの事象が発生すると、IP アドレス リソースが障害となりフェールオーバーが発生します。

<対処策>
この現象を回避するために、クラスター環境で LBFO を使用する場合には、Active – Active の構成か、2 以上の Active NIC と Standby の組み合わせで構成で設定し、Active NIC が同時にすべて失われないように構成を見直してください。

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

KB 2781571 の Windows Server 2008 版の修正について

$
0
0

こんにちは、Windows サポートチームの頂です。

以下 サポート技術文書 KB 2781571 と Windows Vistaの関連についてご説明いたします。

          文書番号: 2781571
          Windows での TDI ドライバーをインストールした後"0x000000D1"の停止エラー
          http://support.microsoft.com/kb/2781571

KB 2781571 の修正は LDR 版となっており、Windows 7 SP 1、Windows Server 2008 R2  SP 1 と Windows Server 2008 SP 2 に適用可能です。

この修正の Windows Server 2008 SP 2 版が作成される際に、Windows Vista はすでに延長サポートフェーズに移行していましたため、Windows Vista は対象外となり、また KB 2781571 からダウンロードした Windows Server 2008 用のモジュールは Windows Vista に適用してもエラーになり、適用自体もできません。

しかしながら、KB 2781571 の技術文書の以下のところに、Windows Vista の表記があります。

      1. 「ファイル情報」の「Windows Server 2008 のファイル情報のメモ」の部分

      2. 「修正プログラムのダウンロード」のリンクから「修正プログラムのダウンロード」ページに移動して、その中の「修正プログラムを選択する」部分

この 2 つの部分に Windows Vista の表記があるのは、KB 作成時に使用されるテンプレートでは Windows Vista / Windows Server 2008 の修正についてこのようになっているためです。
ダウンロードした修正モジュール自体は、前述のように Windows Vista に適用できないので、ご理解いただければと思います。

なお、afd.sys の修正について、KB 2781571より後に以下のセキュリティ修正 ( KB 2961072 ) がリリースされております。

          文書番号: 2961072
          [MS14-040] Ancillary Function ドライバーのセキュリティ更新プログラムについて (2014 年 7 月 8 日)
          http://support.microsoft.com/kb/2961072


この修正はセキュリティ修正という位置づけのものですので、サポート延長フェーズに移行した Windows Vista にも適用できるように作成されております。
そして、KB 2961072 の LDR 版の修正には、KB 2781571 の修正が含まれておりますので、Windows Vista に KB 2961072 の LDR 版の修正を適用すれば、KB 2781571 の問題も回避されます。
以下の手順で、Windows Vista に KB 2961072 の LDR 版を適用できます。

     1. Afd.sys の LDR 版の修正  KB 977332 を適用

(すでに KB 977332 が適用済みの場合、この手順は不要です。)

          文書番号: 977332
          Windows Vista と Windows Server 2008 では、TF_REUSE_SOCKET フラグと Winsock API 関数が呼び出されると、メモリ リークが発生します。
          http://support.microsoft.com/kb/977332

この修正を適用することによって、現在のシステムにインストールされている afd.sys の最新修正の LDR 版に切り替わります。

     2. Afd.sys の最新のセキュリティ修正 KB 2961072 を適用

(すでに KB 2961072 が適用済みの場合、この手順  は不要です。手順 1 によって、LDR 版に切り替わっています) 。

          文書番号: 2961072
          [MS14-040] Ancillary Function ドライバーのセキュリティ更新プログラムについて (2014 年 7 月 8 日)
          http://support.microsoft.com/kb/2961072

これで KB 2961072 の LDR 版が適用されます。

スプール ファイルの削除に失敗したことを示すイベント ログについて

$
0
0

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

 

大量の印刷を行っている場合等に、スプール ファイルの削除に失敗したことを示すエラー イベントがイベント ログに記録されることがあります。

 

# 記録されるイベントの例

ログの名前:         Microsoft-Windows-PrintService/Operational

ソース:           Microsoft-Windows-PrintService

日付:            XXXX/XX/XX XX:XX:XX

イベント ID:       812

タスクのカテゴリ:      ファイル操作を実行しています

レベル:           エラー

キーワード:         印刷スプーラー

ユーザー:          SYSTEM

コンピューター:       XXXXXXXXXX

説明:

ファイル C:\Windows\system32\spool\PRINTERS\00170.SPL の削除に失敗しました。エラー コード 0x2。コンテキスト情報については、イベント ユーザー データを参照してください。

 

※この時のエラー イベント 0x2 は、ほかにも次のようなファイル システム関連のエラー コードが含まれていることがございます。

 

・エラー コード 0x5 (ERROR_ACCESS_DENIED)

・エラー コード 0x20 (ERROR_SHARING_VIOLATION)

 

今回は、上記のようなエラー イベントが記録された場合の対処方法をご案内いたします。

(スプール フォルダは既定で <システム ルート ディレクトリ>\System32\Spool\Printers に設定されていますので、ご確認ください。)

 

# ERROR_FILE_NOT_FOUND の場合

既にそのスプール ファイルが削除されていたことが原因ですので、スプール フォルダ内にスプール ファイルが残っていることはありません。

そのため、エラーを無視していただいて問題ありません。

 

# ERROR_SHARING_VIOLATION および ERROR_ACCESS_DENIED の場合

スプール フォルダ内にスプール ファイルが残存している場合があります。

その場合は、システム再起動時等のタイミングで、削除に失敗して残っているスプール ファイルを削除してください。

 

なお、スプール ファイルの削除は、その印刷ジョブの印刷が完了していることが前提で実行されます。

そのため、これらのエラー イベントが記録されたとしても、その他のエラーが記録されていなければ、印刷そのものは正常に実行されておりますのでご安心ください。

 

続いて、本エラー発生に関する spoolsv.exe 内部動作についてお伝えいたします。

 

# spoolsv.exe 内部動作

1. spoolsv.exe 以外のプロセス (アプリケーションやサービス等) から、オープン中のプリンター ハンドルのクローズが行われる。

2. RPC 経由で、spoolsv.exe に対しプリンター ハンドル クローズ (ClosePrinter) のリクエストが送信される。

3. spoolsv.exe から、ClosePrinter を実行するためのスレッド (以下「ClosePrinter 実行スレッド」) が起動される。

4. オープン中のプリンター上に印刷ジョブが残っていなければ、「ClosePrinter 実行スレッド」がその印刷ジョブに紐づくスプール ファイルを削除した上で、プリンター ハンドルをクローズする。

 

上記のとおり spoolsv.exe 内部では、「印刷ジョブを処理するスレッド」と「ClosePrinter 実行スレッド」の間で、スプール ファイル削除処理の同期が行われておりません。

その結果、タイミングによってはどちらかのスレッドから行われたスプール ファイル削除の処理が、ERROR_SHARING_VIOLATION/ERROR_FILE_NOT_FOUND/ERROR_ACCESS_DENIED 等のエラーにより失敗することがあり、エラー イベントとしてイベント ログに記録されます。

 

以上の動作につきましては、現在の spoolsv.exe の設計上、回避できない仕様上の制限事項となります。

設計として好ましい動作ではないと思いますが、このようなエラー イベントが記録された場合には、参考にしていただけると幸いです。

HKLM\SOFTWARE のサイズ確認方法と、肥大化した場合の圧縮方法

$
0
0

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

Windows プラットフォームのシステム管理をする上で、避けて通れないのがレジストリですよね。
今回は、このレジストリの中で、比較的サイズが大きくなりやすい HKLM\SOFTWARE のサイズを
確認する方法と、万が一肥大化している場合に、サイズを圧縮する方法をご紹介いたします。

こちらの技術情報では、圧縮する手順の中で、レジストリの元となるファイル (レジストリ ハイブ) が
オペレーションの対象となっております。圧縮作業を実施する際には、慎重に作業いただきますよう
お願いいたします。万が一、置き換え対象を間違えたりした場合、システムが起動できなくなる場合も
あります。

▼ 事前準備

1. Windows Sysinternals のサイトから Registry Usage と PendMoves/MoveFile を
    ダウンロードします。

   Registry Usage (ru.exe)
   http://technet.microsoft.com/ja-jp/sysinternals/dn194428

   PendMoves と MoveFile
   http://technet.microsoft.com/ja-jp/sysinternals/bb897556

▼ レジストリのサイズ確認する手順

1. 管理者権限をもったユーザーでログオンします。
2. コマンド プロンプトを "管理者として実行" で起動します。
3. ru.exe を使用して、HKLM\SOFTWARE のサイズを確認します。

   > ru.exe HKLM\SOFTWARE
  
   ※ サイズが大きい場合、表示されるまでに時間がかかる場合があります。
        気長にお待ちくださいませ。

      例)
     
      > ru.exe HKLM\SOFTWARE

      Ru v1.0 - report registry key usage
      Copyright (C) 2013 Mark Russinovich
      Sysinternals - www.sysinternals.com

      Values:       259999
      Keys:         174423
      Size:         30,833,788 bytes 


   Size を確認し、1GB (1,073,741,824 byte)  以上のサイズであった場合には、
   圧縮をご検討ください。

▼ 肥大化した HKLM\SOFTWARE のレジストリ ハイブを圧縮する手順

1. 管理者権限をもったユーザーでログオンします。
2. レジストリ エディター (regedit.exe) を起動します。
3. 現在のレジストリ キー (HKLM\SOFTWARE) を基に、サイズを圧縮させた
    レジストリ ハイブを作成します。

   3-1. 以下のキーまで移動し、右クリックし "エクスポート" を
          クリックします。
     
           HKEY_LOCAL_MACHINE\SOFTWARE
          
   3-2. エクスポート画面にて、C ドライブの何れかのフォルダーを
          指定します。
   3-3. エクスポート画面にて、ファイルの種類を "レジストリ ハイブ ファイル" を
          クリックし、任意のファイル名をつけて保存します。
          
        例)
        ファイル名: SOFTWARE-new
        ファイルの種類: レジストリ ハイブ ファイル (*.*)
        選択された部分: HKEY_LOCAL_MACHINE\SOFTWARE

4. 手順 3 で圧縮したレジストリ ハイブと、元々のレジストリ ハイブのサイズを
    比較します。

   ※ 元々のレジストリ ハイブは  C:\Windows\System32\config\SOFTWARE です。
  
▼ 圧縮した HKLM\SOFTWARE のレジストリ ハイブと、元のレジストリ ハイブを置き換える手順

1. 管理者権限をもったユーザーでログオンします。
2. コマンド プロンプトを “管理者として実行” にて起動します。
3. 事前準備でダウンロードした PendMoves と MoveFile の場所に移動し、
    以下のコマンドを実行します。
     
   例) 圧縮したレジストリ ハイブが C:\tmp\SOFTWARE-new だった場合
     
   > movefile.exe C:\Windows\System32\config\SOFTWARE C:\Windows\System32\config\SOFTWARE-old
   > movefile.exe C:\tmp\SOFTWARE-new C:\Windows\System32\config\SOFTWARE
  
  【 補足 】
     
     上記はシステム再起動のタイミングで、肥大化したレジストリ ハイブに
     -old をつけて、リネームしておき、その後、圧縮したレジストリ ハイブに
     置き換えるよう、設定しています。

4. 以下のコマンドを実行し、指定したオペレーションの順番 (リネームの後、置き換えを行う) を
    再度、確認します。
     
   > pendmoves.exe
  
   例) 実行結果の例

       PendMove v1.2
       Copyright (C) 2004-2013 Mark Russinovich
       Sysinternals - wwww.sysinternals.com

       Source: C:\Windows\System32\config\SOFTWARE
       Target: C:\Windows\System32\config\SOFTWARE-old

       Source: C:\tmp\SOFTWARE-new
       Target: C:\Windows\System32\config\SOFTWARE

5. システムを再起動します。
6. 再起動後、冒頭のサイズ確認手順にて、レジストリのサイズを確認します。

    > ru.exe HKLM\SOFTWARE

▼ SQL Server 2012 SP1 を利用している環境についての補足

    SQL Server 2012 SP1 の利用環境で、HKLM\SOFTWARE が肥大化している場合、
    以下のブログで掲載している不具合に合致する可能性があります。

    レジストリ ハイブの肥大化について(KB 2793634)
    http://blogs.msdn.com/b/jpsql/archive/2014/08/29/kb-2793634.aspx

    ブログ内で紹介している Service Pack 2 をご適用の上、上述の圧縮手順をお試しください。

▼ 補足

    レジストリの肥大化について、マイクロソフト サポートにお問い合わせいただく場合には、
    肥大化しているキーの詳細を確認するため、以下のコマンドラインで情報を採取いただけますと、
    調査がスムーズに進む場合があります。

    例) HKLM\SOFTWARE が大きかった場合の情報採取

        > ru.exe -v -c HKLM\SOFTWARE > registory-list.csv 2>&1

   上記 registory-list.csv をサポート担当者に、ご提供ください。

Windows Server 2012 / 2012 R2で BitLocker の GUI 設定が表示されない場合、再起動をお試しください

$
0
0

 

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

 

サーバー OS である Windows Server 2012 / 2012 R2 では、クライアント OS である Windows 8 / 8.1 と異なり、 BitLocker ドライブ暗号化機能は標準搭載されておりません。

BitLocker の機能を利用する場合は、サーバーマネージャーの「役割と機能の追加」から、「BitLocker ドライブ暗号化」機能をインストールするなど、追加の手順を経る必要があります。

 

 

この際、機能インストール後に再起動しただけでは、コントロールパネルの「 BitLocker ドライブ暗号化」アプレットや、エクスプローラーのオペレーティングシステムドライブを右クリックして表示される「 BitLocker を有効にする」メニューなど、 GUI 設定項目が表示されないことがあることを確認しております。

その場合、もう一度再起動を実施いただくと、正常に表示されるようになります。この記事では、当方で検証した手順をご紹介いたします。

 

Windows Server 2012 の場合

 

  • 「 BitLocker ドライブ暗号化」機能をインストール後、指示に従い再起動します。

  • この状態では、コントロール パネルに「 BitLocker ドライブ暗号化」アプレットは表示されますが、エクスプローラーのオペレーティング システム ドライブを右クリックして表示される「 BitLocker を有効にする」メニューは表示されません。

 


 

  • この後、もう一度再起動を実施すると、右クリックで「 BitLocker を有効にする」メニューが表示されるようになります。


 

Windows Server 2012 R2 の場合

 

  • 「 BitLocker ドライブ暗号化」機能をインストール後、指示に従い再起動します。

  • この状態では、エクスプローラーのオペレーティング システム ドライブを右クリックして表示される「 BitLocker を有効にする」メニューが表示されないことに加え、コントロール パネルに「 BitLocker ドライブ暗号化」アプレットも表示されません。

 


 

  • この後、もう一度再起動を実施すると、コントロール パネルに「 BitLocker ドライブ暗号化」アプレットが表示されるとともに、右クリックで「 BitLocker を有効にする」メニューが表示されるようになります。

 


 

 

<参考:その他の追加機能のインストールの必要性について>

 

Windows Server 2012 / 2012 R2 BitLocker GUI 設定機能を利用するためには、「サーバーグラフィックシェル」機能が必要ですが、これは標準インストールの際に含まれているため、「 BitLocker ドライブ暗号化」以外の機能の追加は必要ありません。

「サーバーグラフィックシェル」とは、インストール時のオプションで "フル インストール" を選択した場合に追加される機能で、 Server Core インストールを行った場合には、追加されません。

 

詳細については、下記の公式ドキュメントをご参照ください。

 

デスクトップエクスペリエンスの概要

https://technet.microsoft.com/ja-jp/library/cc772567.aspx

 

サーバーグラフィックシェルがインストールされていない場合は、一部の機能しか使用できません。

ヘルプコンテンツは使用できません。

イベントビューアーの詳細ビューは使用できません。

Windows ファイアウォール用のグラフィカル管理ツールは使用できません。

BitLocker ドライブ暗号化はコマンドラインで管理する必要があります。

 

なお、当方での検証では、「デスクトップ エクスペリエンス」のインストールは必要ありませんでした。

サーバー グラフィック シェルは、視覚的なインターフェース 画面を表示するコンポーネントで、従来の Server 製品と同等の簡易操作を提供する機能です。

デスクトップ エクスペリエンスは、テーマ表示や動画再生など、より流麗な視覚効果を持たらす機能で、BitLocker の管理には、デスクトップ エクスペリエンス機能は必須ではありません。

 


Viewing all 590 articles
Browse latest View live




Latest Images