アクティブ化されない Active Directory ベースのライセンス認証 (ADBA) クライアントのトラブルシューティング

Note

この記事は、2018 年 3 月 26 日に TechNet ブログとして最初に公開されたのもです。

最近、あるお客様の環境への Windows Server 2016 の展開を支援しました。 この機会に、ライセンス認証方法も KMS サーバーから Active Directory によるライセンス認証へと移行することにしました。

すべての変更を行うための適切な手順として、お客様のテスト環境で移行を開始しました。 展開を開始するには、「Active Directory ベースのアクティブ化とキー管理サービスの手順に従います。 テスト環境のドメイン コントローラーはすべて Windows Server 2012 R2 を実行していたため、フォレストを準備する必要はありませんでした。 Windows Server 2012 R2 ドメイン コントローラーに役割をインストールし、ボリュームのアクティブ化方法として Active Directory ベースのライセンス認証を選択しました。 KMS キーをインストールし、"KMS AD ライセンス認証 (** LAB)" という名前を付けます。ブログの投稿の手順に従いました。

2 つの Windows 2016 Server Standard と 2 つの Windows 2016 Server Datacenter という 4 つの仮想マシンを構築することから始めました。 この時点で、すべてが素晴らしいものでした。 Windows 2016 Server Standard を実行する物理サーバーを構築し、マシンを正常にアクティブ化しました。

実際のところ、セットアップと構成は非常に簡単でした。その部分についてはシンプルで容易でした。 しかし、前の週に構築したすべての仮想マシンは、アクティブ化されていないことを示しました。 物理マシンを調べましたが、問題はありませんでした。 何が起こったのかを話し合うため、お客様のところに行きました。 最初の質問は、「週末に何が変わったか」でした。そして、いつものように答えは「何もない」でした。今回は何も変更されておらず、何が起こっているのかを把握する必要がありました。

問題のあるサーバーの 1 つにアクセスし、コマンド プロンプトを開き、 slmgr /ao-list コマンドからの出力を確認しました。 /ao-list スイッチには、Active Directory 内のすべてのアクティブ化オブジェクトが表示されます。

結果は、Windows Server 2012 R2 用の 2 つのアクティブ化オブジェクトと、Windows Server 2016 ライセンスである新しく作成された KMS AD ライセンス認証 (** LAB) を持っていることを示しています。 これにより、Active Directory が Windows KMS クライアントをアクティブ化するように正しく構成されていることが確認されます。

slmgrコマンドがライセンス認証用であることを知って、私はさまざまなオプションを続けました。 /dlvスイッチを試しましたが、詳細なライセンス情報が表示されます。 これは問題なく見えましたが、Windows Server 2016 の Standard バージョンを実行していました。アクティブ化 ID、インストール ID、検証 URL、プロダクト キーの一部さえあります。

ここで私が何を見逃したか、おわかりになりますか? 他のトラブルシューティング手順の後に戻りますが、このスクリーンショットの答えは十分です。

私の考えでは、何らかの理由でキーが壊れているので、現在のキーをアンインストールする /upk スイッチを使用しています。 これはキーの削除に効果的でしたが、一般的にこれを行う最善の方法ではありません。 新しいキーを取得する前にサーバーを再起動する必要がありますか。 /ipkスイッチ(トラブルシューティングの後半で行います)を使用すると、既存のキーが上書きされ、より安全なルートであることがわかりました。

/dlvスイッチをもう一度実行して、詳細なライセンス情報を表示しました。 残念ながら、それは私に有用な情報を与えませんでした、ちょうどプロダクトキーが見つかりませんエラー。 私はちょうどそれをアンインストールしたので、キーがないため。

私はそれが長いショットだと思ったが、私は既知のKMSサーバー(または場合によっては Active Directory)に対してWindowsをライセンス認証する必要がある /ato スイッチを試した。 やはり、製品が見つからないというエラーが表示されただけでした。

次の考えは、サービスを停止して開始するとトリックが行われることがあるので、次に試しました。 Microsoft ソフトウェア保護プラットフォーム サービス (SPPSvc サービス) を停止して開始します。 管理コマンド プロンプトから、信頼できる net stop と net start コマンドを使用します。 最初はサービスが実行されていないことに気付くので、私はこれがそうでなければならないと思います。

しかし、サービスを開始してWindowsをもう一度ライセンス認証しようとすると、製品が見つからないというエラーが表示されます。

次に、問題のサーバーのうち 1 台でアプリケーション イベント ログを調べました。 コード 0x8007007B の、ライセンス認証、イベント ID 8198 に関するエラーを見つけました。

このコードを調べている間に、エラー コードがファイル名、ディレクトリ名、またはボリューム ラベルの構文が正しくないという記事が見つかりました。 この記事で説明されている方法を読んでも、どの方法も状況に合っていないようです。 nslookup -type=all _vlmcs._tcpコマンドを実行したときに、既存の KMS サーバー (環境内の Windows 7 と Server 2008 のマシンが多数あるため、それを維持する必要がありました) だけでなく、5 つのドメイン コントローラーも見つかりました。 これは、DNS の問題ではなく、問題が他の場所にあることを示しました。

これで、DNS に問題がないことがわかりました。 Active Directory は、KMS ライセンス認証ソースとして適切に構成されています。 物理サーバーが正常にアクティブ化されました。 これは VM だけの問題になるのでしょうか? ここで興味深いことに、お客様が私に、別の部門の誰かも 10 数台以上の仮想 Windows Server 2016 マシンを構築することにした、と話してくれました。 だから今、私はそれに対処する別の十数台のサーバーがアクティブにならないと思います。 ただし、これらのサーバーは正常にアクティブ化されました。

さて、私はこれらのモンスターを活性化させる方法を理解するために slmgr コマンドに戻った。 今回は、プロダクト キーをインストールできる /ipk スイッチを使用します。 Appendix A: KMS クライアント セットアップ キーにアクセスして、Windows Server 2016 の Standard バージョンに適したキーを取得しました。 一部のサーバーはデータセンターですが、最初にこれを修正する必要があります。

/ipk スイッチを使用してプロダクト キーをインストールし、Windows Server 2016 Standard キーを選択しました。

ここからは、Datacenter で実行した結果だけをキャプチャしたのですが、同じものとなります。 /atoスイッチを使用してアクティブ化を強制しました。 製品が正常にアクティブ化されたことを示す素晴らしいメッセージが表示されます。

/dlv スイッチをもう一度使用すると、Active Directory によってアクティブ化されたことがわかります。

では、何が問題だったのでしょうか? 私はなぜ、これらのマシンが正しくライセンス認証されるように、インストールされたキーを削除してこれらの汎用キーを追加する必要があったのでしょうか? 他の 10 数台以上のマシンが問題なくライセンス認証されたのはなぜなのでしょうか? 前にお話ししたとおり、この問題を調べる最初の段階で、私は重要な何かを見逃していたのです。 私は徹底的に混乱していたので、最初のブログからポスターに手を差し伸べられました。 ポスターはすぐに問題を見て、早い段階で私が逃していたものを理解するのに役立ちました。

最初の /dlv スイッチを実行したとき、説明にはキーが含まれます。 説明は、"Windows® Operating System, RETAIL Channel" となっていました。 私はこれを見て、RETAIL Channel は購入済みであることを示し、有効なキーであると考えました。

適切にアクティブ化されたサーバーからの /dlv スイッチの出力を見ると、説明に VOLUME_KMSCLIENT チャネルが示されていることに注意してください。 これにより、実際にボリューム ライセンスであることを確認できます。

では、RETAIL channel とはどういう意味なのでしょうか? これは、オペレーティング システムのインストールに使用されたメディアが MSDN ISO である、ということを意味するのです。 私はお客様に、もしかしたら 2 つ目の Windows Server 2016 ISO がネットワークに存在するのでは、とたずねました。 答えはイエスでした。ネットワーク上に別の ISO があり、他の 10 数台のマシンの作成に使用されていたのです。 お客様は 2 つの ISO を比較し、仮想サーバーを構築するために私に割り当てられたのが、やはり MSDN ISO であったことがわかりました。 その MSDN ISO がネットワークから削除され、既存のすべてのサーバーがアクティブ化され、今後のビルドでライセンス認証が失敗する心配がなくなります。