共用方式為

針對未啟用的 Active Directory 型啟用 (ADBA) 客戶端進行疑難解答

  • 發行項

注意事項

本文最初發佈為TechNet部落格，於2018年3月26日。

我最近協助客戶在其環境中部署 Windows Server 2016。 我們利用這個機會也將其啟用方法從 KMS 伺服器移轉至 Active Directory 型啟用。

作為進行所有變更的適當程序，我們已在客戶的測試環境中開始移轉。 我們遵循 Active Directory-Based 啟用與金鑰管理服務中的指示開始部署。 測試環境中的域控制器全都 Windows Server 2012 R2 執行，因此我們不需要準備樹系。 我們在 Windows Server 2012 R2 域控制器上安裝角色，並選擇 [Active Directory 型啟用] 作為大量啟用方法。 我們已安裝 KMS 金鑰，並將其命名為「KMS AD 啟用 (** LAB) 」。我們已逐步遵循部落格文章。

我們一開始會建置四部虛擬機、兩部 Windows 2016 Server Standard 和兩部 Windows 2016 Server Datacenter。 此時一切都很棒。 我們建置了執行 Windows 2016 Server Standard 的實體伺服器，且機器已正確啟動。

事實上，設定和設定非常簡單，因此該元件簡單且直接。 不過，我前一周建置的所有虛擬機都顯示它們未啟用。 我回到實體機器，沒關係。 我已前往客戶討論發生什麼事。 第一個問題是「週末有什麼變更？」和往常一樣，答案是「沒有」。這次沒有任何變更，我們必須找出發生什麼事。

我前往其中一個問題伺服器、開啟命令提示字元，並檢查命令的 slmgr /ao-list 輸出。 參數 /ao-list 會顯示 Active Directory 中的所有啟用物件。

顯示 slmgr 命令的螢幕快照。

顯示 slmgr 命令結果的螢幕快照。

結果顯示我們有兩個啟用物件：一個用於 Windows Server 2012 R2，另一個則是新建立的 KMS AD 啟用 (** LAB) 這是 Windows Server 2016 授權。 這會確認 Active Directory 已正確設定為啟用 Windows KMS 用戶端。

知道命令 slmgr 是用於授權啟用，我繼續使用不同的選項。 我已嘗試 /dlv 切換，這會顯示詳細的授權資訊。 這看起來沒問題，我執行的是標準版本的 Windows Server 2016、有啟用標識碼、安裝標識碼、驗證 URL，甚至是部分產品密鑰。

顯示 slmgr /dlv 命令結果的螢幕快照。

此時是否有人看到我錯過的內容？ 在其他疑難解答步驟之後，我們會回到該處，但表示答案已在此螢幕快照中就已足夠。

我們現在的想法是，由於某些原因，密鑰已中斷，因此我使用 /upk 參數，這會卸載目前的密鑰。 雖然這可有效移除密鑰，但通常不是最佳做法。 伺服器應該在取得新金鑰之前重新啟動，它可能會讓伺服器處於錯誤狀態嗎？ 我發現使用 /ipk 參數 (我稍後在疑難解答中所做的) 會覆寫現有的密鑰，並且是更安全的路由。

顯示 slmgr /upk 命令及其結果的螢幕快照。

我再次執行 /dlv 參數，以查看詳細的授權資訊。 可惜的是，這並未提供任何有用的資訊，只是找不到產品密鑰的錯誤。 因為我剛才卸載密鑰，所以沒有密鑰。

[命令提示字元] 視窗的螢幕快照，其中顯示 slmgr /dlv 命令和產生的 [找不到產品密鑰] 錯誤訊息。

我認為這是一個很長的嘗試，但我嘗試了 /ato 切換，這應該會針對已知的 KMS 伺服器 (或 Active Directory 啟動 Windows，因為案例可能) 。 同樣地，只有找不到產品的錯誤。

[命令提示字元] 視窗的螢幕快照，其中顯示 slmgr /ato 命令和產生的 [找不到產品] 錯誤訊息。

下一個想法是有時候停止和啟動服務會執行技巧，因此我接下來嘗試了。 我需要停止並啟動 Microsoft 軟體保護平台服務 (SPPSvc 服務) 。 從系統管理命令提示字元中，我使用信任的 net stop 和 net start 命令。 我一開始注意到服務並未執行，所以我認為這必須是它。

顯示 net stop 和 net start 命令結果的螢幕快照。

不過，啟動服務並嘗試再次啟用 Windows 之後，我仍會收到找不到產品的錯誤。

接著，我查看了其中一部疑難伺服器上的應用程式事件記錄檔。 我發現與授權啟用、事件標識碼 8198 相關的錯誤，其代碼為 0x8007007B。

顯示事件標識碼 8198 詳細數據的螢幕快照。

查閱此程式代碼時，我發現一篇文章指出錯誤碼表示檔名、目錄名稱或磁碟區卷標語法不正確。 閱讀文章中所述的方法，似乎都不符合此情況。 當我執行 nslookup -type=all _vlmcs._tcp 命令時，我發現現有的 KMS 伺服器 (環境中仍有許多 Windows 7 和 Server 2008 機器，因此必須將它保留在) ，同時也需要五個域控制器。 這表示這不是 DNS 問題，而且問題位於其他位置。

顯示 nslookup 命令結果的螢幕快照。

所以我知道 DNS 沒問題。 Active Directory 已正確設定為 KMS 啟用來源。 實體伺服器已正確啟動。 這是否只是 VM 的問題？ 目前有趣的一點是，我的客戶通知我，不同部門的某人也決定建置十幾部虛擬 Windows Server 2016 機。 因此，現在我假設有另外十幾部伺服器要處理，但不會啟用。 不過，這些伺服器啟動正常。

我回到 slmgr 命令，以瞭解如何啟用這些巨量。 這次我要使用 /ipk 參數，這可讓我安裝產品密鑰。 我前往附錄 A：KMS 用戶端安裝金鑰，以取得標準版 Windows Server 2016 的適當密鑰。 有些伺服器是 Datacenter，但我需要先修正此問題。

顯示 KMS 用戶端安裝金鑰清單的螢幕快照。

我使用 /ipk 參數來安裝產品金鑰，並選擇 Windows Server 2016 標準密鑰。

顯示 slmgr /ipk 命令及其結果的螢幕快照。

從這裡開始，我只會從數據中心體驗擷取結果，但結果相同。 我使用 /ato 參數來強制啟用。 我們收到一則很棒的訊息，指出產品已成功啟用。

[命令提示字元] 視窗的螢幕快照，其中顯示 slmgr /ato 命令和產生的 Product Activated Successfully 訊息。

/dlv再次使用 參數，我們可以看到Active Directory 現在已啟用。

[命令提示字元] 視窗的螢幕快照，其中顯示 slmgr /dlv 命令和產生的訊息，指出 Active Directory 已啟用使用者。

現在，發生什麼錯誤？ 為什麼必須移除已安裝的金鑰，並新增這些一般金鑰，才能讓這些機器正常啟用？ 為什麼其他十幾部機器啟動時沒有問題？ 如先前所述，我在查看問題的初始階段遺漏了一些索引鍵。 我徹底混淆了，因此從初始部落格接觸到海報。 海報立即看到問題，並協助我瞭解我稍早錯過的內容。

當我執行第一個 /dlv 參數時，描述中的 是索引鍵。 描述為 Windows® 作業系統零售通道。 我已看過該問題，並認為零售通路表示該通道已購買且是有效的密鑰。

顯示 slmgr /dlv 命令結果的螢幕快照，其中已醒目提示 RETAIL 通道資訊。

當我們查看正確啟動之伺服器的 /dlv 交換器輸出時，請注意描述現在會指出VOLUME_KMSCLIENT通道。 這可讓我們知道它確實是大量授權。

顯示 slmgr /dlv 命令結果的螢幕快照，其中已醒目提示VOLUME_KMSCLIENT通道資訊。

那麼，該零售通路代表什麼意思？ 這表示用來安裝作業系統的媒體是 MSDN ISO。 我回到客戶，詢問是否有第二個 Windows Server 2016 ISO 在網路周圍浮動。 結果是，網路上有另一個 ISO，而且已用來建立其他十幾部機器。 他們會比較這兩個 ISO，並確定提供給我建置虛擬伺服器的 ISO 事實上是 MSDN ISO。 他們已從其網路中移除該 MSDN ISO，現在我們已啟用所有現有的伺服器，且不再擔心未來組建的啟用失敗。