共用方式為


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

注意

本文最初是在 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 Activation (** 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,另一個是 Windows Server 2016 授權的新建立 KMS AD Activation (** LAB)。 這確認 Active Directory 已正確設定為啟用 Windows KMS 用戶端。

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

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

有人看到我在這個時間點錯過了什麼? 在我的其他疑難解答步驟之後,我們會回到它,但足以說明答案在此螢幕快照中。

我現在的想法是,因為某些原因,密鑰已中斷,所以我使用 /upk 參數,這會卸載目前的密鑰。 雖然這在移除密鑰方面很有效,但通常不是最佳方式。 伺服器應該在取得新的金鑰之前重新啟動,它可能會讓伺服器處於不良狀態? 我發現使用 /ipk 參數(稍後在疑難解答中執行此動作)會覆寫現有的密鑰,而且是一個更安全的路線。

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

我再次執行 /dlv 開關,以查看詳細的授權資訊。 不幸的是,這並沒有給我任何有用的資訊,只是找不到產品密鑰錯誤。 因為我剛卸載它,所以沒有密鑰。

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

我想這是一個很長的鏡頭, 但我嘗試 /ato 了開關, 這應該啟用 Windows 對已知的 KMS 伺服器 (或 Active Directory 可能的情況) 。 同樣地,只有找不到產品錯誤。

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

下一個想法是,有時停止和啟動服務會做這個技巧,所以我下一步嘗試。 我需要停止後啟動 Microsoft 軟體保護平台服務 (SPPSvc 服務)。 從系統管理命令提示字元中,我使用信任 net stopnet 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 命令,以及產生的產品啟動成功訊息。

/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,且不出所料,事實上提供給我建置虛擬伺服器的是 MSDN ISO。 他們從其網路中移除了 MSDN ISO,現在我們已啟動所有現有的伺服器,且不再擔心未來組建上的啟用失敗。