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

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

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

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

ソース: EventLog

イベント ID: 6008

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

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

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

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

ソース: Microsoft-Windows-Kernel-Power

イベント ID:41

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

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

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

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

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

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

考えられる原因は？

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

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

- ソフトウェア要因

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

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

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

3. デバイスの停止

4. I/O 要求の抑止

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

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

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

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

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

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

<System Error イベント ID: 1003>

イベントの種類: エラー

イベント ソース: System Error

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

イベント ID: 1003

説明:

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

<Save Dump イベント ID: 1001>

イベントの種類: 情報

イベント ソース: Save Dump

イベント カテゴリ: なし

イベント ID: 1001

説明:

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

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

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

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

- 参考資料

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

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

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

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

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

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

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

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

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

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

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

- ハードウェア要因

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

補足情報

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

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

文書番号： 2549760

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

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

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

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

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

HKLM\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout　

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

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

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

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

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

-参考情報

 文書番号: 972110

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

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

文書番号: 130536

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

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

文書番号: 824674

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

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

文書番号: 2028504

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

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

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

タスク スケジューラに関してお問い合わせを多くいただいておりますので、タスク スケジューラに関連する修正プログラムと確認されております発生事象についてご紹介いたします。

なお、タスク スケジューラに関する修正は、ロール アップ パッケージのような形で公開はしておりませんが、最新の修正プログラムで過去の問題も含んで修正されますので、最新版の適用をご案内いたしております。

Windows Server 2008 SP2 / Windows Vista SP2 につきましては、KB 2884927 と KB 2787046 と KB 2649317 の 3 つを適用いただくことで、タスク スケジューラ関連のモジュールは最新となります。

お問い合わせの多い問題に対しての個別の修正プログラムついて、下記に記載いたします。

最新ではなく個々の問題に対して修正頂く際には、下記の修正プログラムの適用をご検討下さい。

Windows Server 2008 R2 / Windows 7 につきましては以下をご参照下さい。

タスク スケジューラに関する修正プログラムについて (Windows Server 2008 R2 / Windows 7) へのリンク

Windows Server 2008 / Windows Vista

タスク スケジューラをご利用いただいております際に、上記に該当する事象を確認されましたら、修正プログラムの適用についてご検討くださいますようお願いいたします。

皆さんこんにちは。

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 のレジストリ設定を行っても、すべてのキャッシュ情報がすぐに削除されるわけではありません。削除できないプリンターをすぐに消したい場合には、管理者権限を持ったアカウントで以下の対処策を実施いただき、状況が改善されるかどうかをご確認ください。

1. 印刷スプーラー サービスを停止します。

2. レジストリ エディタを開き、以下のレジストリ キー配下を空にします。

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider

3. RemovePrintersAtLogoff を 1 に設定します。

4. 印刷スプーラー サービスを再開します。

5. デバイスとプリンター画面を開きます。

6. 削除できなかったプリンターのアイコンをそれぞれ右クリックして、削除を実行します。

※プリンターの削除画面

弊社では、この問題について引き続き調査を継続していますので、新しい情報がわかりましたらお伝えしたいと思います。

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

Windows Vista および Windows Server 2008 から
新しく導入されましたボリューム アクティベーション 2.0 の
KMS ライセンス認証方式についてご紹介したいと思います。

なお、本日ご紹介させていただきます内容については
Windows 7 および Windows Server 2008 R2 にも当てはまる内容となりますので
今後導入予定の方も参考にしていただけましたら幸いです。

コンテンツ

• ボリューム アクティベーション 2.0 (VA 2.0) について
• ボリューム アクティベーション 1.0 とボリューム アクティベーション 2.0 の相違点
• リテール パッケージおよびボリューム ライセンス メディアからのセットアップについて
• KMS ライセンス認証について
• KMS ホストと KMS クライアントの見分け方
• KMS ホストから KMS クライアントへの変更方法
• まとめ

ボリューム アクティベーション 2.0 (VA 2.0) について

ボリューム アクティベーションとはボリューム ライセンス用プロダクトの
ライセンス認証方式の事で、ボリューム アクティベーション 2.0 では
以下 2 種類のライセンス認証方式が用意されています。

• KMS (キー マネージメント サービス) ライセンス認証
• MAK (マルチプル アクティベーション キー) ライセンス認証

今回は、上記 KMS ライセンス認証がどういったライセンス認証方式なのかおよび
誤解や勘違いされる事が多い KMS ライセンス認証用のプロダクト キーの扱い等について
順を追って説明していきたいと思います。

KMS ライセンス認証用のプロダクト キーの使われ方が誤解される理由としては、
従来のボリューム アクティベーション 1.0 (VA 1.0)と
同じ感覚でプロダクト キーが利用されているためであることが多いようです。

そのため、まずは従来のボリューム アクティベーション 1.0 のおさらいと
ボリューム アクティベーション 2.0 の相違点からご説明していきたいと思います。

ボリューム アクティベーション 1.0 とボリューム アクティベーション 2.0 の相違点

以下にボリューム アクティベーション 1.0 とボリューム アクティベーション 2.0 の
代表的な特徴についてそれぞれ挙げてみます。

- ボリューム アクティベーション 1.0

• ボリューム ライセンス用メディアからの各ソフトウェアのインストール時において、
  ボリューム ライセンス用のプロダクト キーを入力する事により、
  ソフトウェアのインストール後にはライセンス認証がされた状態となり、ライセンス認証の作業が不要。
• ソフトウェア インストール後において、プロダクト キーやライセンス認証方式の変更が不可。

対象ソフトウェアの例

Windows XP

Windows Server 2003

Microsoft Office 2003

Microsoft Office 2007

など

- ボリューム アクティベーション 2.0

• ボリューム ライセンス用メディアからのインストール時において
  プロダクト キーの入力画面が表示されない(※)。
• ソフトウェアのインストール後に、別途ライセンス認証の作業が必要。
• ソフトウェア インストール後にプロダクト キーの変更が行え、ラインセンス認証方式の変更も可能。
• プロダクト キーごとにライセンス認証可能な回数の上限値が設けられている。

対象ソフトウェアの例

Windows Vista

Windows Server 2008

Windows 7

Windows Server 2008 R2

など

リテール パッケージおよびボリューム ライセンス メディアからのセットアップについて

次に Windows Server 2003 と Windows Server 2008 を例に、
リテール パッケージ用のインストール メディアおよび、
ボリューム ライセンス用のメディアからのセットアップ時の
プロダクト キーの入力画面の様子を見てみます。

リテール パッケージ用メディアによるセットアップ時

ボリューム ライセンス用メディアによるセットアップ時

ここでの違いは表示されているメッセージからもお分かりの通り、
リテール パッケージ用のプロダクト キーを入力するか
ボリューム ライセンス用のプロダクト キーを入力するかという点になります。

それぞれ適切なプロダクト キーを入力する必要がありますので、
ボリューム ライセンス用メディアからのインストール時に
リテール パッケージ用のプロダクト キーを入力してセットアップを続行する事や
リテール パッケージ用メディアからのインストール時にボリューム ライセンス用の
プロダクト キーを入力してセットアップを続行する事はできません。

続いて Windows Server 2008 の方も見てみます。

ボリューム ライセンス メディア利用時にプロダクト キーの入力が不要である事を確認するため、
セットアップ開始画面からの一連の流れとして見ていきます。

リテール パッケージ用メディアによるセットアップ時

ボリューム ライセンス用メディアによるセットアップ時

上記 2 点の動作をご確認いただく事でボリューム ライセンス用メディアからのインストール時には、
リテール パッケージ用メディアからのセットアップ時にはあったプロダクト キーの入力画面が
省略されている事をご確認いただけたかと思います。

次はここまでの内容をふまえまして、KMS ライセンス認証とは
どういった構成なのかについてをご説明していきます。

KMS ライセンス認証について

KMS ライセンス認証では、KMS ホストと KMS クライアントと呼ばれる
2 種類の端末が存在し、構成図としては以下のような形になります。

KMS 環境の構成図

KMS ライセンス認証は、上記図のようにサーバ・クライアント モデルのような構成となります。
なお、KMS ホストはサーバ OS とは限らず、クライアント OS でも KMS ホストにする事は可能です。

KMS ホストとして構成可能な OS は以下の通りです。

• Windows Server 2003 SP1 以降
• Windows Vista
• Windows Server 2008
• Windows 7
• Windows Server 2008 R2

実際のライセンス認証については、まず KMS ホストが Microsoft のライセンス認証サーバにライセンス認証を行います。
KMS クライアントは直接 Microsoft のライセンス認証サーバからライセンス認証を行うのではなく、
KMS ホストに対してライセンス認証を行う動作となります。

この構成は WSUS (Windows Server Update Service) をご存知の方であれば
KMS の構成は WSUS と同じような構成とお考えいただけると分かりやすいかもしれません。

WSUS サーバは Microsoft Update サーバからのセキュリティ更新プログラム等を
クライアントに対して提供するサーバであり、各クライアントは Microsoft Update サーバから
直接セキュリティ更新プログラムをダウンロードするのではなく WSUS サーバからセキュリティ更新プログラムを
ダウンロードしてインストール作業を行います。

つまり、KMS と WSUS の違いは、クライアントにライセンス認証を提供するか
セキュリティ更新プログラムを提供するかの違いとなります。

WSUS の構成図も参考までに以下に載せておきます。
KMS 構成図とほぼ同じである事がお分かりいただけると思います。

WSUS 環境の構成図

次に KMS 用のボリューム ライセンス キーの扱いについてご説明いたします。

KMS 用に提供させていただいているボリューム ライセンス キーは
KMS ホスト用のプロダクト キーとなり、各端末 1 台 1 台に
インストールするものではありません。

この点が KMS ライセンス認証の構成を構築するにあたって非常に重要な点となり、
誤解が多い部分でもあります。

ボリューム アクティベーション 1.0 では、ボリューム ライセンス用のプロダクト キーは
全ての端末に一律同じプロダクト キーをインストールしていたため、
KMS 用のプロダクト キーも同じような使われ方がされている事が多数見受けられますので、
ぜひご注意いただければと思います。

一見、全ての端末に KMS 用のボリューム ライセンス キーをインストールして
KMS ホストとしてライセンス認証を行ってしまってもよいのでは？と思われるかもしれません。

しかし、ボリューム アクティベーション 2.0 の特徴のところにも記載させて頂きましたが
ボリューム ライセンス キーにはライセンス認証可能な上限値が設けられており、
KMS 用のボリューム ライセンス キーはこの上限値が 10 回までとなっています。

そのため、前述の通り全ての端末にインストールしてライセンス認証を行う使い方ではなく、
KMS ホストのみでご利用いただくような適切な使い方をしていただく必要があります。

なお、KMS ホストについては、通常 1 台ご用意いただくだけで大多数の KMS クライアントを
管理する事が可能ですので、冗長構成をする場合にのみ 2 台程度
KMS ホストにしていただければ十分なものとなります。

それでは、次に KMS クライアント用のプロダクト キーはどうすればよいかと言いますと
実は KMS クライアント用のプロダクト キーは通常インストールする必要がありません。

これは、先程ボリューム ライセンス用のメディアからのセットアップ時に
プロダクト キーの入力画面が表示されない様子をご確認いただいたかと思いますが、
セットアップ時に KMS クライアント用のプロダクト キーが自動的にインストールされているためとなります。

つまり、ボリューム ライセンス用のインストール メディアを使用してセットアップを実施した場合、
セットアップ完了後は、KMS クライアントとして構成された状態である事を意味します。

KMS ライセンス認証の構成を構築する手順をまとめますと、一般的には以下のような流れとなります。

1. ボリューム ライセンス用インストール メディアを使用し、
   KMS ホストとする端末のセットアップ (OS インストール) を行います。
2. KMS ホストに KMS 用のボリュームライセンス キーをインストールします。

   ※ セットアップ後のプロダクト キーのインストール(変更)方法については、
   後述する KMS ホストから KMS クライアントへの変更方法 の手順をご確認ください。

3. KMS ホストでライセンス認証を実施します。

   ※ KMS ホストで KMS クライアントのライセンス認証を行うには
   KMS ホスト自身がライセンス認証されている必要があります。

4. ボリューム ライセンス用インストール メディアを使用し、
   KMS クライアントとなる端末のセットアップを行います。

上記により、KMS クライアントは KMS ホストに対しライセンス認証を行う
KMS ライセンス認証の構成となります。

※ KMS クライアントがライセンス認証されるためには、KMS ホストに対し一定数以上の
KMS クライアントをご用意いただく必要があります。

KMS ホストと KMS クライアントの見分け方

OS がセットアップされた状態では、一見 KMS ホストとして構成されているのか
KMS クライアントとして構成されているかの区別がつきません。

ここでは、現在の環境が KMS ホストとして構成されているのか
KMS クライアントとして構成されているかの確認方法をご紹介いたします。

KMS ホストか KMS クライアントかを区別する方法としては、
OS 標準で付属している "Windows ソフトウェア ライセンス管理ツール" である
slmgr.vbs を利用する方法があります。

コマンド プロンプトを管理者として起動していただき、以下のコマンドを実行します。

KMS ホストか KMS クライアントであるかは slmgr.vbs の実行結果の
"説明" 欄に含まれている内容で判断が可能です。

- KMS ホストの場合

- KMS クライアントの場合

それぞれの環境でのコマンド実行例を以下に紹介します。

KMS ホスト環境での実行例

KMS クライアント環境での実行例

なお、同様の方法により、MAK ライセンス認証をご利用の環境か
どうかについても確認が可能です。

- MAK クライアントの場合

MAK クライアント環境での実行例

KMS ホストから KMS クライアントへの変更方法

ここでは、誤って KMS 用のボリューム ライセンス キーをインストールし、
KMS ホストとして構成してしまった場合に KMS クライアントに戻す方法について
ご紹介いたします。

また、KMS クライアントとしてセットアップされた状態から
MAK ライセンス認証の構成または、KMS ホストとして構成する際の
ボリューム ライセンスキーのインストール方法も同じ手順となります。

ボリューム アクティベーション 2.0 の特徴にも記載いたしましたが、
OS セットアップ後において、プロダクト キーの変更が可能となっており、
プロダクト キーの変更により、KMS ホストの環境から KMS クライアントへの環境変更が可能です。
また、反対に KMS クライアントから KMS ホストへの変更も可能です。

KMS ホストから KMS クライアントに戻す場合は、KMS クライアント用の
セットアップ キー (プロダクトキー) を入力する必要があります。
(KMS クライアントから KMS ホストにする場合は、KMS 用のボリューム ライセンス キーを入力します。)

このセットアップ キーは OS およびエディションによってあらかじめ
決められている固定のプロダクト キーを使用します。

代表的なものついては以下の表にまとめさせていただきましたので、
お使いの環境に合わせてご利用ください。

※ ボリューム ライセンス プログラムとしての KMS プロダクト キーはあくまで KMS ホスト用のものになります。

プロダクト キーの変更方法としては GUI からの方法および
上記でご紹介した slmgr.vbs の 2 通りの方法があります。

GUI の場合は、コントロール パネル内にある "システム" を開き、
以下 "システム" 画面内にある "プロダクト キーの変更" から行います。

一方、slmgr.vbs から行う場合は、前回同様コマンド プロンプトを管理者として起動していただき、
以下のコマンドを実行します。

以下は、KMS ホストから KMS クライアントに変更後、
KMS クライアントに変更されている事を確認した際のコマンド実行例となります。
(Windows Server 2008 Enterprise 用の KMS クライアント セットアップ キーを使用しています。)

まとめ

最後に今回ご説明いたしました内容について
抑えて頂きたいポイントのまとめと参考情報のご紹介をさせていただきます。

• KMS ライセンス認証は KMS ホストと KMS クライアントの 2 種類の環境の構成となる
• KMS 用ボリューム ライセンス キーは KMS ホスト用のプロダクトキーである
• ボリューム ライセンス用インストール メディアでセットアップを行うと
  自動的に KMS クライアントとして構成される
• KMS ホストか KMS クライアントの判断およびプロダクトキーの変更は slmgr.vbs から行う事が可能

2013/09/13 追記。

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

本日は、Windows Server 2012 リモート デスクトップ環境の構成に関するコマンドをご紹介いたします。

Windows Server 2012 リモート デスクトップ環境では、RDMS (Remote Desktop Management Service) を利用してリモート デスクトップ サービス関連の設定の変更を行います。

しかしながら、RDMS は "リモート デスクトップ サービスのインストール" を使用してリモート デスクトップ サービスのインストールを行わない限り、インストールされません。
また、"リモート デスクトップ サービスのインストール" は、非ドメイン環境では実行できず、ドメイン環境でのみ実行可能であり、ドメイン環境であってもドメイン コントローラー単一では、"リモート デスクトップ サービスのインストール" が実行できません。

その為、ドメイン コントローラーや WORKGROUP 環境の Windows Server 2012 にリモート デスクトップ セッション ホストの各種設定を行うには、WMI コマンドの利用やレジストリの編集が必要です。

※ ドメイン コントローラーへの "リモート デスクトップ サービスのインストール" については、KB2871777 にて公開されている更新プログラムをインストールして再起動することにより、実行可能となります。

今回は、PowerShell を利用したリモート デスクトップ セッション ホスト / リモート デスクトップ ライセンスのインストール、ライセンス サーバーの設定、また、RemoteApp の公開、RemoteApp 接続を行うための .rdp ファイルの作成方法についてお伝えいたします。

- リモート デスクトップ セッション ホストのインストール
1. [ツール] より、[Windows PowerShell] を起動します。

2. [リモート デスクトップ セッション ホスト] 役割サービスをインストールします。
   > Add-WindowsFeature -Name RDS-RD-Server

3. [デスクトップ エクスペリエンス] をインストールします。
   > Add-WindowsFeature -Name Desktop-Experience

4. [ライセンス診断] ツールをインストールします。
   > Add-WindowsFeature -Name RSAT-RDS-Licensing-Diagnosis-UI

5. システムの再起動を行います。

- リモート デスクトップ ライセンスのインストール、ライセンス サーバーの設定
1. [ツール] より、[Windows PowerShell] を起動します。

2. [リモート デスクトップ ライセンス] の役割サービスをインストールします。
   > Add-WindowsFeature -Name RDS-Licensing

3. [RD ライセンス マネージャー] をインストールします。
   > Add-WindowsFeature -Name RDS-Licensing-UI

4. [リモート デスクトップ ライセンス モード] を変更します。
   > (gwmi -Class Win32_TerminalServiceSetting -Namespace root\cimv2\TerminalServices).ChangeMode(4)
   ※ 4 は [接続ユーザー数] モードです。[接続デバイス数] モードは 2 です。
  
5. [リモート デスクトップ ライセンス サーバー] を指定します。
   > New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers" -Name SpecifiedLicenseServers -Value "<IP アドレス>" -PropertyType MultiString
また、以下のコマンドを実行しても同様の処理が行えます。
   > (gwmi -Class Win32_TerminalServiceSetting -Namespace root\cimv2\TerminalServices).SetSpecifiedLicenseServerList("<IP アドレス>")
コマンド例:
   > New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers" -Name SpecifiedLicenseServers -Value "192.168.0.1" -PropertyType MultiString
   > (gwmi -Class Win32_TerminalServiceSetting -Namespace root\cimv2\TerminalServices).SetSpecifiedLicenseServerList("192.168.0.1")

6. 以下のコマンドで正常にライセンス サーバーが指定されていることを確認します。
   > Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers" -Name SpecifiedLicenseServers
   ※ 以下のコマンドを実行しても同様の処理が行えます。
   > (gwmi -Class Win32_TerminalServiceSetting -Namespace root\cimv2\TerminalServices).GetSpecifiedLicenseServerList()
 

- RemoteApp の公開方法、RemoteApp 接続用の .rdp ファイルの作成方法
1. 下記コマンドを実行し、RemoteApp として公開したいアプリケーションを登録します。
   ※ 以下は mspaint.exe を登録する手順です。
   > $regPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications"
   > New-Item $regPath -Name mspaint
   > New-ItemProperty $regPath\mspaint -Name CommandLineSetting -Value 0 -PropertyType Dword
   > New-ItemProperty $regPath\mspaint -Name Name -Value Paint -PropertyType String
   > New-ItemProperty $regPath\mspaint -Name Path -Value C:\Windows\System32\mspaint.exe -PropertyType String
   > New-ItemProperty $regPath\mspaint -Name RequiredCommandLine -PropertyType String
   > New-ItemProperty $regPath\mspaint -Name SecurityDescriptor -PropertyType String
   > New-ItemProperty $regPath\mspaint -Name ShowInTSWA -Value 1 -PropertyType Dword

2. クライアントには下記内容を含む .rdp ファイルを配布します。
   =========================================
   redirectclipboard:i:1
   redirectposdevices:i:0
   redirectprinters:i:1
   redirectcomports:i:1
   redirectsmartcards:i:1
   devicestoredirect:s:*
   drivestoredirect:s:*
   redirectdrives:i:1
   session bpp:i:32
   prompt for credentials on client:i:1
   span monitors:i:1
   use multimon:i:1
   remoteapplicationmode:i:1
   server port:i:3389
   allow font smoothing:i:1
   promptcredentialonce:i:1
   authentication level:i:2
   gatewayusagemethod:i:2
   gatewayprofileusagemethod:i:0
   gatewaycredentialssource:i:0
   full address:s:<サーバー名もしくは IP アドレス>
   alternate shell:s:||mspaint <------------ レジストリ キー名
   remoteapplicationprogram:s:||mspaint <--- レジストリ キー名
   gatewayhostname:s:
   remoteapplicationname:s:Paint <---------- Name に記載のデータ
   remoteapplicationcmdline:s:
   =========================================
   ※ <------ とその後の文字列は削除してください。

- 参考情報
Win32_TerminalServiceSetting class (Windows)
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383640(v=vs.85).aspx

Windows Server 2012 ドメイン コントローラーで "リモート デスクトップ サービスのインストール" ができない。
http://support.microsoft.com/kb/2795837

A servicing stack update is available for Windows RT, Windows 8, and Windows Server 2012: September 2013
http://support.microsoft.com/kb/2871777