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

注:

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

私は最近、顧客が自分の環境にWindows Server 2016をデプロイするのを手伝いました。 この機会に、ライセンス認証方法を KMS サーバーから Active Directory ベースのアクティブ化に移行しました。

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

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

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

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

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

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

この時点で見逃した内容は誰にも表示されますか? 他のトラブルシューティング手順の後に戻りますが、このスクリーンショットの答えは十分です。

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

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

私はそれが長いショットだと思ったが、私はスイッチを /ato 試してみました。これは、既知のKMSサーバー(または場合によっては Active Directory)に対してWindowsをアクティブにする必要があります。 ここでも、製品が見つかりませんエラーです。

次の考えは、時にはサービスを停止して開始するとトリックを行うので、私は次に試してみました。 Microsoft Software Protection Platform Service (SPPSvc サービス) を停止して開始する必要があります。 管理コマンド プロンプトから、信頼 net stop と net start コマンドを使用します。 私は最初、サービスが実行されていないことに気付くので、私はこれがそうでなければならないと思います。

しかし、サービスを開始し、Windowsをもう一度アクティブ化しようとすると、製品が見つからないというエラーが表示されます。

その後、問題のあるサーバーの 1 つでアプリケーション イベント ログを確認しました。 ライセンスライセンス認証、イベント ID 8198 に関連するエラーが見つかります。コードは0x8007007B。

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

だから私はDNSがうまくいっている知っている。 Active Directory は、KMS アクティブ化ソースとして適切に構成されています。 物理サーバーが正しくアクティブ化されました。 これは VM だけの問題になる可能性がありますか? この時点で興味深いサイドノートとして、私の顧客は、別の部署の誰かが12台以上の仮想Windows Server 2016マシンを構築することに決めたことを私に知らせます。 だから今、私はアクティブ化されない対処する別の十数のサーバーを持っていると仮定します。 ただし、これらのサーバーは正常にアクティブ化されました。

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

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

ここから私はデータセンターの経験からの結果のみをキャプチャしましたが、それらは同じでした。 私はスイッチを /ato 使用してアクティブ化を強制しました。 製品が正常にアクティブ化されたことを示すすばらしいメッセージが表示されます。

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

さて、何が間違っていたのですか? インストールされているキーを削除し、これらの汎用キーを追加してこれらのマシンを適切にアクティブ化する必要があるのはなぜですか? 他の 12 台ほどのマシンが問題なくアクティブ化されたのはなぜですか? 先ほど述べたように、問題を見る最初の段階で何か重要なものを見逃しました。 私は徹底的に混乱していたので、最初のブログからポスターに手を差し伸べられました。 ポスターはすぐに問題を見て、私が早い段階で見逃したことを理解するのに役立ちました。

私が最初 /dlv のスイッチを実行したとき、説明の中でキーでした。 説明は Windows® オペレーティング システム、RETAIL チャネルでした。 私はそれを見て、リテールチャネルは、それが購入され、有効なキーであることを意味すると思っていました。

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

では、リテール チャネルとはどういう意味ですか? これは、オペレーティング システムのインストールに使用されたメディアが MSDN ISO であることを意味します。 私は顧客に戻り、偶然、ネットワークの周りに2つ目のWindows Server 2016 ISOが浮かんでいるかどうかを尋ねた。 はい、ネットワーク上に別の ISO があり、他の 12 台のマシンを作成するために使用されていたことが判明しました。 彼らは2つのISOを比較し、仮想サーバーを構築するために私に与えられたものを十分に確かめたのは、実際にはMSDN ISOでした。 その MSDN ISO がネットワークから削除され、既存のすべてのサーバーがアクティブ化され、今後のビルドでライセンス認証が失敗する心配がなくなります。