Windows を実行しているクライアントをアクティブ化する
Key Management Service (KMS) または Active Directory ベースのアクティブ化がネットワークで構成された後、Windows を実行しているクライアントのアクティブ化は簡単です。 コンピューターが汎用ボリューム ライセンス キー (GVLK) で構成されている場合、IT またはユーザーは何も行う必要はありません。 ライセンス認証は完了しています。
Enterprise エディションのイメージとインストール メディアは、既に GVLK で構成されています。 クライアント コンピューターを起動すると、ライセンス サービスが、コンピューターの現在のライセンス状態を調べます。
ライセンス認証またはライセンス再認証が必要な場合は、次の処理が実行されます。
コンピューターがドメインのメンバーである場合は、ボリューム ライセンス認証オブジェクトをドメイン コントローラーに要求します。 Active Directory によるライセンス認証を構成している場合は、ドメイン コントローラーがオブジェクトを返します。 オブジェクトが次の要件を満たしている場合:
- インストールされているソフトウェアのエディションと一致します
- 一致する GVLK がある
その後、コンピューターがアクティブ化 (または再アクティブ化) されます。 オペレーティング システムはより短い一定の間隔で再アクティブ化を試みますが、コンピューターを 180 日間再度アクティブ化する必要はありません。
コンピューターがドメインのメンバーではない場合、またはボリューム ライセンス認証オブジェクトが使用できない場合、コンピューターは DNS クエリを発行して KMS サーバーの検索を試みます。 KMS サーバーに接続できる場合、KMS にコンピューターの GVLK と一致するキーがある場合、アクティブ化が発生します。
コンピューターは、MAK で構成されている場合、Microsoft サーバーに対してライセンス認証を試みます。
クライアントがそれ自体を正常にアクティブ化できない場合は、定期的に再試行します。 再試行の頻度は、現在のライセンス状態と、クライアント コンピューターが過去に正常にアクティブ化されたかどうかによって異なります。 たとえば、以前に Active Directory ベースのライセンス認証を使用してアクティブ化を行ったクライアント コンピューターは、再起動のたびにドメイン コントローラーへの接続を定期的に試行します。
キー管理サービスのしくみ
KMS では、クライアント/サーバー トポロジが使用されます。 KMS クライアント コンピューターは、DNS または静的構成を使って KMS ホスト コンピューターを見つけることができます。 KMS クライアントは、TCP/IP 上の RPC を使用して KMS ホストに接続します。
キー管理サービスのライセンス認証のしきい値
物理コンピューターと仮想マシンは、KMS ホストに接続することでアクティブ化できます。 KMS ライセンス認証の資格を得るには、対象となるコンピューターの最小数が必要です。 この最小値は、アクティブ化のしきい値と呼ばれます。 KMS クライアントは、このしきい値が満たされた後にのみアクティブ化されます。 各 KMS ホストは、しきい値が満たされるまでアクティブ化を要求したコンピューターの数をカウントします。
KMS ホストは、KMS クライアントからの有効なライセンス認証要求のそれぞれに対して、ライセンス認証のために KMS ホストに既に接続しているコンピューターの数を応答します。 ライセンス認証のしきい値を下回る数を受け取るクライアント コンピューターはアクティブ化されません。 たとえば、KMS ホストに接続する最初の 2 台のコンピューターが現在サポートされているバージョンの Windows クライアントを実行している場合、最初のコンピューターはアクティブ化カウント 1 を受け取り、2 台目はアクティブ化カウント 2 を受け取ります。 次のコンピューターが、現在サポートされているバージョンの Windows クライアントを実行している仮想マシンである場合、ライセンス認証数は 3 になります。 25 以上のライセンス認証数に達する必要があるため、これらのコンピューターはいずれもアクティブ化されません。
KMS クライアントは、KMS がアクティブ化しきい値に達するのを待機している場合、2 時間ごとに KMS ホストに接続して現在のアクティブ化数を取得します。 しきい値が満たされるとアクティブになります。
この例では、KMS ホストに接触する次のコンピューターが現在サポートされているバージョンの Windows Server を実行している場合、アクティブ化カウントは累積されるため、アクティブ化カウントは 4 になります。 現在サポートされているバージョンの Windows Server を実行しているコンピューターが、5 つ以上のアクティブ化カウントを受け取った場合は、アクティブ化されます。 現在サポートされているバージョンの Windows クライアントを実行しているコンピューターがアクティブ化カウント 25 以上を受け取った場合は、ライセンス認証されます。
ライセンス認証カウントのキャッシュ
ライセンス認証のしきい値を追跡するために、KMS ホストでは、ライセンス認証を要求した KMS クライアントの記録が保存されます。 KMS ホストは、各 KMS クライアントにクライアント ID を指定し、KMS ホストは、各クライアント ID をテーブルに保存します。 既定では、各ライセンス認証要求が、最長で 30 日間、テーブルに保存されています。 クライアントがアクティブ化を更新すると、キャッシュされたクライアント ID がテーブルから削除され、新しいレコードが作成され、30 日間が再び開始されます。 KMS クライアント コンピューターが 30 日以内にライセンス認証を更新しない場合、KMS ホストは対応するクライアント ID をテーブルから削除し、アクティブ化数を 1 ずつ減らします。
ただし、KMS ホストでキャッシュされるのは、ライセンス認証のしきい値に達するために必要な数の 2 倍の数のクライアント ID のみです。 そのため、テーブルには最新の 50 個のクライアント ID のみが保持され、クライアント ID は 30 日より早く削除される可能性があります。
アクティブ化しようとしているクライアント コンピューターの種類によって、キャッシュの合計サイズが設定されます。 たとえば、KMS ホストがサーバーからのみアクティブ化要求を受け取る場合、キャッシュは必要なしきい値の 5 の 2 倍の 10 個のクライアント ID のみを保持します。 ただし、Windows クライアントを実行しているクライアント コンピューターが KMS ホストに接続した場合、KMS は、より高いしきい値に対応するためにキャッシュ サイズを 50 に増やします。 KMS がキャッシュ サイズを減らすことはありません。
キー管理サービスの接続性
KMS ライセンス認証では、TCP/IP 接続が必要です。 既定では、KMS ホストおよびクライアントは DNS を使って KMS を公開し、検索します。 既定の設定を使用できます。管理操作がほとんど必要ないか、まったく必要ありません。 ただし、KMS ホストとクライアント コンピューターは、ネットワーク構成とセキュリティ要件に基づいて手動で構成できます。
キー管理サービスのライセンス認証の更新
KMS ライセンス認証の有効期間は 180 日間 (ライセンス認証の有効期間) です。 ライセンス認証を維持するために、KMS クライアント コンピューターは、180 日ごとに 1 回以上、KMS ホストに接続してライセンス認証を更新する必要があります。 KMS クライアント コンピューターは、既定で 7 日ごとにライセンス認証を更新します。 KMS ライセンス認証に失敗した場合、クライアント コンピューターは 2 時間ごとに再試行します。 クライアント コンピューターのライセンス認証が更新されると、アクティブ化の有効期間が再び開始されます。
キー管理サービスの公開
KMS では、DNS のサービス (SRV) リソース レコードを使って、KMS ホストの場所を保存し、通信します。 KMS ホストは、利用可能な場合は DNS 動的更新プロトコルを使って、KMS サービス (SRV) リソース レコードを公開します。 動的更新が利用できない場合、または KMS ホストにリソース レコードを発行する権限がない場合は、次のいずれかのアクションを実行する必要があります。
- DNS レコードは手動で発行する必要があります。
- 特定の KMS ホストに接続するようにクライアント コンピューターを構成する必要があります。
キー管理サービスのクライアント検出
既定では、KMS クライアント コンピューターは、KMS 情報を DNS に照会します。 KMS クライアント コンピューターは、最初に KMS 情報を DNS に照会するときは、DNS が返すサービス (SRV) リソース レコードの一覧から KMS ホストをランダムに選びます。 サービス (SRV) リソース レコードを含む DNS サーバーのアドレスは、KMS クライアント コンピューターのサフィックス付きエントリとして一覧表示できます。 この機能を使用すると、1 つの DNS サーバーが KMS のサービス (SRV) リソース レコードをアドバタイズし、KMS クライアント コンピューターを他のプライマリ DNS サーバーと一緒にアドバタイズして検索できます。
KMS の DnsDomainPublishList レジストリ値には、優先順位と重みのパラメーターを追加できます。 KMS ホストの優先順位のグループ化と各グループ内での重み付けを確立すると、クライアント コンピューターが最初に試行する必要がある KMS ホストを指定し、複数の KMS ホスト間でトラフィックのバランスを取ることができます。 現在サポートされているすべてのバージョンの Windows と Windows Server では、これらの優先順位と重みのパラメーターが提供されます。
クライアント コンピューターが選択した KMS ホストが応答しない場合、KMS クライアント コンピューターは、その KMS ホストをサービスの一覧 (SRV) リソース レコードから削除し、その一覧から別の KMS ホストをランダムに選択します。 KMS ホストが応答すると、KMS クライアント コンピューターはその KMS ホストの名前をキャッシュし、その後のライセンス認証と更新の際に、そのホストを使用します。 キャッシュされた KMS ホストが後続の更新で応答しない場合、KMS クライアント コンピューターは、DNS for KMS サービス (SRV) リソース レコードに対してクエリを実行することで、新しい KMS ホストを検出します。
既定では、クライアント コンピューターは、TCP ポート 1688 を介して匿名 RPC を使用してアクティブ化のために KMS ホストに接続しますが、既定のポートは変更できます。 クライアント コンピューターが KMS ホストとの TCP セッションを確立した後、クライアント コンピューターは 1 つの要求パケットを送信します。 KMS ホストは、ライセンス認証カウントで応答します。 カウントがアクティブ化のしきい値を満たすか超えた場合、クライアント コンピューターがアクティブ化され、セッションが閉じられます。 KMS クライアント コンピューターは、これと同じ手順を更新要求にも使います。 通信のそれぞれの方向に 250 バイトが使用されます。
ドメイン ネーム システム サーバーの構成
既定の KMS 自動公開機能には、サービス (SRV) リソース レコードと、DNS 動的更新プロトコルのサポートが必要です。 KMS クライアント コンピューターの既定の動作と KMS サービス (SRV) リソース レコードの発行は、次の場合にサポートされます。
- Microsoft ソフトウェアを実行している DNS サーバー。
- サービス (SRV) リソース レコード (インターネット エンジニアリング タスク フォース [IETF] Request for Comments [RFC] 2782) と動的更新 (IETF RFC 2136 ごと) をサポートする DNS サーバー。
たとえば、Berkeley Internet Domain Name バージョン 8.x と 9.x は、サービス (SRV) リソース レコードと動的更新をサポートしています。 KMS ホストは、サービス (SRV)、IPv4 ホスト (A)、および IPv6 ホスト (AAAA) の各リソース レコードを DNS サーバーで作成し、更新するために必要な資格情報を持つように構成する必要があります。そうしない場合は、これらのレコードを手動で作成する必要があります。 KMS ホストに必要な資格情報を与えるために推奨される解決策は、AD DS にセキュリティ グループを作成し、そのグループにすべての KMS ホストを追加することです。 Microsoft ソフトウェアを実行している DNS サーバーで、このセキュリティ グループに_VLMCS._TCP レコードを完全に制御できることを確認します。 この要件は、KMS サービス (SRV) リソース レコードを含む各 DNS ドメインで発生する必要があります。
最初のキー管理サービス ホストのライセンス認証
ネットワーク上の KMS ホストには、KMS キーをインストールし、Microsoft によるライセンス認証を実行する必要があります。 KMS キーをインストールすると、KMS ホストで KMS が有効になります。 KMS キーをインストールした後に、電話またはオンラインで KMS ホストのライセンス認証を完了します。 この初期ライセンス認証以外に、KMS ホストは Microsoft に情報を伝達しません。 KMS キーは KMS ホストにのみインストールされます。個々の KMS クライアント コンピューターにはインストールされません。
2 回目以降のキー管理サービス ホストのライセンス認証
各 KMS キーは、6 台までの KMS ホストにインストールできます。 これらのホストは、物理コンピューターと仮想マシンのいずれかです。 KMS ホストをアクティブ化した後、同じキーを使用して同じホストを最大 9 回再アクティブ化できます。 organizationに 6 つ以上の KMS ホストが必要な場合は、Microsoft ボリューム ライセンスライセンス認証センターを呼び出して例外を要求することで、organizationの KMS キーに対して追加のライセンス認証を要求できます。
マルチ ライセンス認証キーのしくみ
MAK は、Microsoft のホストされているライセンス認証サービスで 1 回限りのライセンス認証に使用されます。 各 MAK では、許可されるライセンス認証の数が、あらかじめ決められています。 この番号はボリューム ライセンス契約に基づいており、organizationの正確なライセンス数と一致しない可能性があります。 Microsoft がホストするライセンス認証サービスで MAK を使う各ライセンス認証では、ライセンス認証の制限までカウントします。
コンピューターは、次の 2 つの方法で MAK を使用してアクティブ化できます。
MAK 個別ライセンス認証。 各コンピューターがインターネットまたは電話を使って、それぞれ独立して Microsoft に接続し、ライセンス認証を実行します。 MAK の独立したライセンス認証は、企業ネットワークへの接続を維持しないorganization内のコンピューターに最適です。 図 16 は、MAK 個別ライセンス認証を示しています。
図 16. MAK 個別ライセンス認証
MAK プロキシ ライセンス認証。 MAK プロキシ ライセンス認証を行うと、マイクロソフトへの 1 つの接続で、複数のコンピューターの一元的なライセンス認証要求が可能になります。 MAK プロキシのアクティブ化は、VAMT を使用して構成できます。 MAK プロキシ ライセンス認証は、セキュリティ上の理由により、インターネットや企業ネットワークへの直接アクセスが制限される環境に適しています。 また、この接続性がない開発ラボやテスト ラボにも適しています。 図 17 は、VAMT による MAK プロキシ ライセンス認証を示しています。
図 17. VAMT による MAK プロキシ ライセンス認証
MAK は次の場合に推奨されます。
- 企業ネットワークにほとんど接続しない、またはまったく接続しないコンピューター。
- ライセンス認証を必要とするコンピューターの数が KMS ライセンス認証のしきい値を満たしていない環境。
MAK は、個々のコンピューターまたは Microsoft 展開ソリューションを使用して複製またはインストールできるイメージで使用できます。 MAK は、KMS ライセンス認証を使用するように最初に構成されたコンピューターでも使用できます。 KMS から MAK への切り替えは、コンピューターをコア ネットワークから切断された環境に移動する場合に役立ちます。
複数のアクティブ化キー (MAK) アーキテクチャとアクティブ化
MAK 個別ライセンス認証では、クライアント コンピューターに MAK プロダクト キーがインストールされます。 キーは、そのコンピューターに、インターネット経由で Microsoft サーバーに対して、それ自体のライセンス認証を実行するよう指示します。
MAK プロキシ のアクティブ化では、VAMT:
- クライアント コンピューターに MAK プロダクト キーをインストールします。
- ターゲット コンピューターからインストール ID を取得します。
- クライアントの代わりにインストール ID を Microsoft に送信します。
- 確認 ID を取得します。
次に、確認 ID がインストールされることで、クライアント コンピューターのライセンス認証が行われます。
標準ユーザーとしてのライセンス認証
現在サポートされているバージョンの Windows では、アクティブ化に管理者権限は必要ありません。 ただし、"リアーム" などの他のアクティブ化またはライセンス関連のタスクには、管理者アカウントが引き続き必要です。
関連するコンテンツ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示