MENU
  1. ホーム
  2. Active Directory
  3. Windows ServerとWindows 11を一括管理！KMSとADBAを使い分けるライセンス認証戦略

Windows ServerとWindows 11を一括管理！KMSとADBAを使い分けるライセンス認証戦略

Active Directory

企業のITインフラを運用していると、Windows ServerやWindowsクライアントのライセンス認証は避けて通れないテーマです。特にドメイン構成やワークグループ混在の環境では、KMSとADBAのどちらを選ぶべきか迷う方も多いでしょう。本記事では両方式の特徴と導入のポイントを詳しく解説します。

目次
  1. Windowsアクティベーションを取り巻く背景
    1. 環境の概要
  2. KMS(Key Management Service)の特徴
    1. 台数要件
    2. KMSの設定手順(概要)
  3. ADBA(Active Directory-Based Activation)の特徴
    1. ADBAの設定手順(概要)
  4. MAK(Multiple Activation Key)の位置づけ
  5. 運用上の考慮ポイント
  6. シナリオ別の推奨構成例
    1. 1. ADBA + MAK併用
    2. 2. KMS一本化(台数要件クリアを目指す)
    3. 3. KMS + ADBAの混在
  7. アクティベーション管理の具体的な流れ
  8. 導入前にチェックすべき注意点
  9. トラブルシューティングのヒント
  10. 将来的なスケーラビリティを見据えた選択
  11. まとめ: 選択のポイント

Windowsアクティベーションを取り巻く背景

Windowsのボリュームライセンス認証には主に3種類の方式があります。ひとつはKey Management Service(KMS)、もうひとつはActive Directory-Based Activation(ADBA)、そしてMultiple Activation Key(MAK)です。どれもMicrosoftから正規にライセンスを取得したユーザーを対象とした仕組みですが、それぞれ適した導入ケースや要件が異なります。ここでは2つのドメインと、ワークグループクライアントが混在する環境でどのようにアクティベーションを実施するか、具体的に比較・検討してみましょう。

環境の概要

  • ドメイン: 2つの異なるドメインが存在
  • Windows Server 2022: 合計約23台
  • Windows 11 クライアント(ドメイン参加): 8台
  • Windows 11 クライアント(ワークグループ): 8台

つまり、合計31台のドメイン参加クライアント、8台のワークグループクライアントがあることになります。サーバーが23台あるのでサーバーの台数要件はある程度満たされそうですが、KMSにはクライアントが25台以上必要というハードルがあります。

KMSとADBA、どちらを選ぶべきか

  • KMS(Key Management Service):
    ネットワーク経由でKMSホストにアクセスできる全端末を認証可能。ただし“クライアントは25台以上、サーバーは5台以上”というしきい値を別々に満たす必要があります。
  • ADBA(Active Directory-Based Activation):
    ドメインメンバーのみを自動認証する仕組み。ワークグループにいる端末は対象外になる点に注意が必要です。

KMS(Key Management Service)の特徴

KMSは企業ネットワークに「KMSホストサーバー」を立て、端末からKMSホストへアクセスしてアクティベーションを行う仕組みです。ドメイン参加・非参加に関わらず、KMSホストに到達できるネットワーク上にあるWindows端末であれば認証できます。ただし以下のような要件があります。

台数要件

KMSには「KMSカウント」という概念があり、一定数以上の台数がKMSホストにアクセスしないと認証が有効化されません。

  • Windowsクライアント(OS)の場合: 25台以上
  • Windowsサーバー(OS)の場合: 5台以上

これらは合算ではなく、クライアントの台数、サーバーの台数、それぞれ独立してカウントされます。今回の例ではサーバーが23台あるため、サーバー側の要件5台以上は明確にクリアしています。しかし、Windows 11クライアントのうちドメイン参加は8台、ワークグループは8台で、合計16台しかありません。KMSではクライアント用の25台要件を満たさないことになります。

KMSの設定手順(概要)

KMSを導入する際、管理者はKMSホストサーバーを1台(または冗長化のため複数台)用意し、以下の手順で構成します。

  1. KMSホストキーのインストール
    ボリュームライセンスで取得したKMSホストキー(VLK)をKMSホストに入力し、認証を行います。
    例:
   slmgr.vbs /ipk <KMSホストキー>
   slmgr.vbs /ato
  1. DNSレコードの自動登録
    KMSホストはDNSに_VLMCS._tcpというSRVレコードを登録します。このレコードによりクライアントは自動的にKMSホストを検出可能になります。
  2. クライアント側の設定
    通常はOS標準のGeneric Volume License Key(GVLK)を使えば、自動的にKMSサーバーへ問い合わせを行います。
   slmgr.vbs /ipk <GVLKキー>
   slmgr.vbs /ato
  1. クライアント数がしきい値に達する
    KMSホストに定期的にアクセスした台数の合計がクライアント25台以上となった時点で、KMS認証が有効化される仕組みです。

ADBA(Active Directory-Based Activation)の特徴

ADBAはActive Directoryドメインに参加している端末を自動認証する仕組みです。ドメイン参加が前提であり、ワークグループに属するマシンは認証できません。メリットとしては、台数制限のようなしきい値がないため、少数のドメイン参加クライアントであってもスムーズに運用できる点が挙げられます。

ADBAの設定手順(概要)

ADBAはWindows Serverの「Volume Activation Services」役割をActive Directory上で構成し、必要なキー(AVMAキーなどではなく、ADBA用のKMSホストキー)をAD DSに登録する流れです。

  1. ドメインコントローラー(DC)に役割を追加
    「サーバーマネージャー」→「役割と機能の追加」から「Volume Activation Services」をインストールし、構成ウィザードを立ち上げます。
  2. アクティベーション方式の選択
    ウィザードで「Active Directoryベースのアクティベーション(ADBA)」を選択します。
  3. プロダクトキーの入力
    Microsoftから入手した「KMSキー」を入力し、ライセンス認証を実施します。
  4. スキーマの拡張(初回のみ)
    ADBAではActive Directoryスキーマにライセンス情報を保存します。初めてADBAを導入する環境ではスキーマ拡張が必要です。通常はウィザードが自動で行ってくれます。
  5. クライアントの確認
    ドメイン参加しているクライアントであれば、自動的にAD DSに問い合わせを行いライセンス認証が完了します。追加の設定はほぼ不要です。

MAK(Multiple Activation Key)の位置づけ

本記事のケースでは、ドメインに参加していないワークグループクライアント(Windows 11)が8台存在します。これらはADBAでは認証できず、KMSでは「25台以上」のしきい値を満たさないため単独での認証が難しい状況です。そこで候補として挙がるのがMAKです。

MAKは端末ごと、あるいは複数台を一括で手動認証する仕組みです。台数が少ないケースや、ドメインに参加しない端末が点在する場合は、MAKキーを用いて個別にオンラインまたは電話経由で認証を行うことが可能です。大規模環境には向きませんが、台数が少ないならそれほど手間ではない場合があります。

運用上の考慮ポイント

今回のようにドメイン参加クライアントが少なく、ワークグループ端末も一定数あるケースでは、「ドメイン参加分はADBAで一括管理、ワークグループ端末にはMAKキーで対処」という組み合わせが有力です。もしクライアント端末全体が25台以上になり、KMS方式を選べばワークグループ端末もカバーできる点はメリットですが、実際にはKMSホスト設置やDNSレコードなど管理が煩雑になることもあります。

以下に、それぞれの認証方式に対するメリット・デメリットを表にまとめます。

認証方式メリットデメリット適用例
KMS– ドメイン参加・非参加を問わず認証可能
– ドメインをまたぐ環境で有効
– 一度設定すれば自動認証が行われる		– クライアント25台以上、サーバー5台以上が必要
– DNSのSRVレコード登録など初期構成が手間
– オフライン端末は認証が難しい		企業内でクライアントやサーバーが多数あり、ネットワークが整備されている環境
ADBA– ドメイン参加端末だけを簡単に一括認証
– 台数制限なし
– DCさえあれば追加コストなし		– 非ドメインメンバーの端末は認証不可能
– AD DSスキーマ拡張などドメイン環境の権限が必要		すべての端末(もしくは大半)をドメイン参加させることが可能で、小規模〜中規模のドメイン環境
MAK– 少数の端末を個別/一括で認証可能
– インターネット経由または電話で認証できる		– 台数が多いと管理が煩雑
– ライセンスキー入力作業が必要
– 再インストール時の手動認証負荷		ドメインに参加できない端末が少数だけ存在、あるいはテスト端末やリモート拠点など限定的な環境での利用

シナリオ別の推奨構成例

今回のケースを踏まえ、実際に考えられる構成例を紹介します。

1. ADBA + MAK併用

  • ADBA:
    ドメインに参加しているサーバー(23台)とWindows 11(8台)を一括で管理します。台数制限がなく、ドメインメンバーは自動認証されるため、運用コストが軽減できます。
  • MAK:
    ワークグループに所属するWindows 11ラップトップ(8台)はMAKキーを使って認証。台数が少ないので個別対応でもそれほど負荷になりません。

2. KMS一本化(台数要件クリアを目指す)

もし将来的にクライアント数が増え、ドメイン参加・非参加を含め合計で25台以上になる見込みがあるなら、KMSで一元管理も検討する価値があります。現時点ではクライアント16台(ドメイン8台+ワークグループ8台)しかありませんが、今後増える計画がある場合にはKMSホストを立ち上げておき、運用しながら台数を増やしてしきい値を超えるタイミングでKMSをフル活用するという方法もあります。

3. KMS + ADBAの混在

理論上、同じ環境でKMSとADBAの両方を同居させることも可能ですが、管理が複雑になるうえ、メリットが大きいわけではありません。複数ドメインにわたっている場合には、ドメインAではADBA、ドメインBではKMSといった運用もあり得ます。ただし、メリットとデメリットを天秤にかけた際、運用負荷が増すケースが多いです。

アクティベーション管理の具体的な流れ

ここでは「ADBA + MAK併用」パターンをもう少し詳しく見てみましょう。

  1. ドメインコントローラー側の設定(ADBAの有効化)
  • ドメインのいずれかのDCにVolume Activation Servicesの役割を追加。
  • ADBAを選択し、KMSホストキーを入力。
  • スキーマ拡張とドメイン上へのライセンスオブジェクト登録が完了すれば、ドメイン参加マシンは自動認証される。
  1. クライアント側(ドメイン参加端末)の動作
  • Windows 11ドメイン参加端末は初回起動時、Active Directoryに問い合わせを行い、自動でライセンス認証される。
  • 個別のコマンド操作は基本的になしで済む。
  1. ワークグループ端末へのMAK適用
  • ラップトップ(ワークグループ)は個別にMAKキーを入力して認証。
  • コマンド例:
    slmgr.vbs /ipk <MAKキー> slmgr.vbs /ato
  • まとめて対応する場合はスクリプトを使う、あるいは「VAMT(Volume Activation Management Tool)」を利用すると管理がしやすい。
  1. ライセンス証跡の管理
  • ADBAの状態はEvent Viewerや「スラッシュコマンド(slmgr.vbs)」で確認可能。
  • MAK認証した端末のライセンス状態も同様にコマンドやVAMTで確認し、更新や再インストール時に対応する。

導入前にチェックすべき注意点

  1. ボリュームライセンス契約の種類
    自社の契約形態によって使用できるキー(KMSホストキー、MAKキーなど)が変わります。確実にMicrosoft Volume Licensing Service Center(VLSC)などから正規のキーを取得してください。
  2. ネットワークトポロジー
    KMSはDNSやネットワークの構成に影響を受けるため、ワークグループ端末がVPNなどを介してKMSホストにアクセスできるか事前確認が必要です。一方ADBAはドメイン参加していれば基本的にカバーできます。
  3. ドメイン環境の権限
    ADBA導入にはスキーマ拡張が伴う場合があるため、ドメイン管理者かつスキーマ管理権限を持っているアカウントで作業する必要があります。
  4. OSバージョン互換性
    ADBAやKMSともに、対象となるWindows OSがサポートしているバージョンか確認しましょう。Windows Server 2022やWindows 11に対応するKMSキーを使用する必要があります。

トラブルシューティングのヒント

  • クライアントが認証されない場合
  • KMSの場合: SRVレコードがDNSに正しく登録されているか、クライアントがGVLKを設定しているか確認。
  • ADBAの場合: ドメイン参加が完了しているか、AD DSに正しくライセンスオブジェクトが登録されているか、ネットワーク接続に問題がないかをチェック。
  • KMSカウントが増えない
  • クライアントがKMSにアクセスするタイミング(通常2時間に1回)を待つ必要があります。
  • クライアントOSが何らかの理由でKMSホストに到達できていない可能性もあるため、ファイアウォールやルーティング設定を確認。
  • ライセンスキーの誤登録
  • ADBA用にKMSキーを登録する際、誤ってMAKキーを入力しないよう注意。
  • ライセンスの種類やキーを誤用した場合、認証は成立しません。slmgrコマンドでキーの種類を確認してから登録しましょう。

将来的なスケーラビリティを見据えた選択

少数端末から始める環境であっても、今後クライアント数が増加し25台以上になる計画があるかどうかで導入方針が変わってきます。例えば現在16台しかなくても、1年後に50台になる予定があるなら最初からKMSを導入し、運用しながら台数がしきい値を超えた段階でクライアント認証をスムーズに移行できるようにする戦略も有効でしょう。一方、台数の大幅な増加が見込めない場合は、ADBA + MAKで手堅く運用を開始するほうが簡素かつ管理しやすいです。

まとめ: 選択のポイント

  1. 台数要件: KMSはクライアント25台、サーバー5台のしきい値が別々に適用される。サーバー23台の要件はOKだが、クライアントは合計16台しかないため厳しい。
  2. ドメイン参加状況: ADBAはドメインメンバー限定。ワークグループ端末があるならADBAだけで完結しない。
  3. 運用の柔軟性: ワークグループ端末にはMAKの利用が無難。数が少ない場合は手動入力の手間もさほど大きくない。
  4. 将来計画: クライアント台数が増える場合、KMS環境を整備しておけば将来的に運用を一本化できる可能性がある。

結果として、ドメイン参加のサーバーやクライアントはADBAで一元管理し、ワークグループ端末のみMAKキーを使って個別にライセンス認証する方法が現実的な解決策と言えます。規模が拡大し、クライアント数が25台以上になれば、KMSへの移行も十分検討に値するでしょう。

Active Directory
Active Directory Windows Server アクティベーション

コメント

コメントする

目次
  1. Windowsアクティベーションを取り巻く背景
    1. 環境の概要
  2. KMS(Key Management Service)の特徴
    1. 台数要件
    2. KMSの設定手順(概要)
  3. ADBA(Active Directory-Based Activation)の特徴
    1. ADBAの設定手順(概要)
  4. MAK(Multiple Activation Key)の位置づけ
  5. 運用上の考慮ポイント
  6. シナリオ別の推奨構成例
    1. 1. ADBA + MAK併用
    2. 2. KMS一本化(台数要件クリアを目指す)
    3. 3. KMS + ADBAの混在
  7. アクティベーション管理の具体的な流れ
  8. 導入前にチェックすべき注意点
  9. トラブルシューティングのヒント
  10. 将来的なスケーラビリティを見据えた選択
  11. まとめ: 選択のポイント