Problembehandlung für ADBA-Clients (Active Directory-basierte Aktivierung), die nicht aktiviert werden

Hinweis

Dieser Artikel wurde ursprünglich als TechNet-Blog am 26. März 2018 veröffentlicht.

Vor kurzem habe ich einem Kunden bei der Bereitstellung von Windows Server 2016 in seiner Umgebung geholfen. Wir haben diese Gelegenheit ergriffen, um auch ihre Aktivierungsmethodik von einem KMS-Server zur Active Directory-basierten Aktivierung zu migrieren.

Als geeignetes Verfahren für alle Änderungen haben wir die Migration in der Testumgebung des Kunden gestartet. Wir haben die Bereitstellung mit den Anweisungen unter Active Directory-Based Activation vs. Key Management Services begonnen. Die Domänencontroller in der Testumgebung wurden alle Windows Server 2012 R2 ausgeführt, sodass wir die Gesamtstruktur nicht vorbereiten mussten. Wir haben die Rolle auf einem Windows Server 2012 R2-Domänencontroller installiert und active Directory-basierte Aktivierung als Volumenaktivierungsmethode ausgewählt. Wir haben den KMS-Schlüssel installiert und ihm den Namen "KMS AD Activation (** LAB)" gegeben. Wir haben den Blogbeitrag Schritt für Schritt verfolgt.

Wir haben zunächst vier virtuelle Computer erstellt, zwei Windows 2016 Server Standard und zwei Windows 2016 Server Datacenter. An diesem Punkt war alles super. Wir haben einen physischen Server mit Windows 2016 Server Standard erstellt und der Computer ordnungsgemäß aktiviert.

Ehrlicherweise waren die Einrichtung und Konfiguration sehr einfach, so dass dieser Teil einfach und unkompliziert war. Alle virtuellen Computer, die ich in der Vorwoche erstellt hatte, zeigten jedoch, dass sie nicht aktiviert wurden. Ich ging zurück zur physischen Maschine und es war in Ordnung. Ich ging zum Kunden, um zu besprechen, was passiert war. Die erste Frage war: "Was hat sich am Wochenende geändert?" Und wie gewohnt lautete die Antwort "nichts". Dieses Mal hatte sich nichts wirklich geändert, und wir mussten herausfinden, was los war.

Ich ging zu einem der Problemserver, öffnete eine Eingabeaufforderung und überprüfte die Ausgabe des slmgr /ao-list Befehls. Der /ao-list Schalter zeigt alle Aktivierungsobjekte in Active Directory an.

Die Ergebnisse zeigen, dass wir über zwei Aktivierungsobjekte verfügen: eines für Windows Server 2012 R2 und das neu erstellte KMS AD Activation (** LAB), bei dem es sich um die Windows Server 2016 Lizenz handelt. Dadurch wird bestätigt, dass Active Directory ordnungsgemäß für die Aktivierung von Windows KMS-Clients konfiguriert ist.

Da ich wusste, dass der Befehl für die slmgr Lizenzaktivierung vorgesehen ist, fuhr ich mit verschiedenen Optionen fort. Ich habe den /dlv Schalter ausprobiert, der detaillierte Lizenzinformationen anzeigt. Das sah gut aus, ich habe die Standard-Version von Windows Server 2016 ausgeführt, es gibt eine Aktivierungs-ID, eine Installations-ID, eine Validierungs-URL, sogar einen partiellen Product Key.

Sieht jemand, was ich an diesem Punkt verpasst habe? Wir werden nach meinen anderen Schritten zur Problembehandlung darauf zurückkommen, aber es genügt, um zu sagen, dass die Antwort in diesem Screenshot enthalten ist.

Ich denke jetzt, dass der Schlüssel aus irgendeinem Grund beschädigt ist, also verwende ich den /upk Schalter, der den aktuellen Schlüssel deinstalliert. Obwohl dies beim Entfernen des Schlüssels effektiv war, ist dies in der Regel nicht die beste Methode. Sollte der Server neu gestartet werden, bevor er einen neuen Schlüssel erhält, kann er den Server in einem fehlerhaften Zustand zurücklassen? Ich habe festgestellt, dass die Verwendung des /ipk Schalters (den ich später in meiner Problembehandlung mache) den vorhandenen Schlüssel überschreibt und eine sicherere Route ist.

Ich habe den /dlv Switch erneut ausgeführt, um die detaillierten Lizenzinformationen anzuzeigen. Leider hat mir dies keine hilfreichen Informationen gegeben, nur einen Product Key nicht gefunden Fehler. Da es keinen Schlüssel gibt, da ich ihn gerade deinstalliert habe.

Ich dachte, es war ein langer Schuss, aber ich habe versucht, den /ato Schalter, der Windows gegen die bekannten KMS-Server (oder Active Directory, wie der Fall sein könnte) aktivieren sollte. Auch hier ist nur ein Produkt nicht gefunden Fehler.

Der nächste Gedanke war, dass manchmal das Beenden und Starten eines Diensts den Trick tut, also habe ich das als Nächstes versucht. Ich muss den Microsoft Software Protection Platform Service (SPPSvc-Dienst) beenden und starten. An einer administrativen Eingabeaufforderung verwende ich die Befehle trusty net stop und net start . Ich stelle zunächst fest, dass der Dienst nicht ausgeführt wird, daher denke ich, dass dies der Fall sein muss.

Nach dem Starten des Diensts und dem Versuch, Windows erneut zu aktivieren, erhalte ich jedoch immer noch den Fehler Produkt nicht gefunden.

Anschließend habe ich mir das Anwendungsereignisprotokoll auf einem der Problemserver angesehen. Ich finde einen Fehler im Zusammenhang mit der Lizenzaktivierung, Ereignis-ID 8198, mit dem Code 0x8007007B.

Beim Nachschlagen dieses Codes habe ich einen Artikel gefunden, der besagt, dass der Fehlercode bedeutet, dass der Dateiname, der Verzeichnisname oder die Volumebeschriftungssyntax falsch ist. Wenn Sie die in diesem Artikel beschriebenen Methoden durchlesen, schien es, dass keine von ihnen der Situation passte. Als ich den nslookup -type=all _vlmcs._tcp Befehl ausgeführt habe, fand ich den vorhandenen KMS-Server (immer noch viele Windows 7- und Server 2008-Computer in der Umgebung, daher war es notwendig, ihn beizubehalten), aber auch die fünf Domänencontroller. Dies deutet darauf hin, dass es sich nicht um ein DNS-Problem handelte und die Probleme an anderer Stelle aufgetreten sind.

Ich weiß also, dass DNS in Ordnung ist. Active Directory ist ordnungsgemäß als KMS-Aktivierungsquelle konfiguriert. Der physische Server wurde ordnungsgemäß aktiviert. Könnte dies ein Problem nur bei VMs sein? Als interessante Randnotiz an diesem Punkt informiert mich mein Kunde, dass jemand in einer anderen Abteilung beschlossen hat, auch mehr als ein Dutzend virtuelle Windows Server 2016 Computer zu bauen. Jetzt gehe ich davon aus, dass ich ein weiteres Dutzend Server habe, die nicht aktiviert werden. Diese Server wurden jedoch gut aktiviert.

Nun, ich ging zurück zum slmgr Befehl, um herauszufinden, wie man diese Monster aktiviert. Dieses Mal verwende ich den /ipk Switch, mit dem ich einen Product Key installieren kann. Ich bin zu Anhang A: KMS-Clienteinrichtungsschlüssel gegangen, um die entsprechenden Schlüssel für die Standardversion von Windows Server 2016 zu erhalten. Einige Server sind Datacenter, aber ich muss diesen Server zuerst beheben.

Ich habe den /ipk Switch verwendet, um einen Product Key zu installieren und den Windows Server 2016 Standardschlüssel auszuwählen.

Von hier an habe ich nur die Ergebnisse meiner Rechenzentrumserfahrungen erfasst, aber sie waren identisch. Ich habe den /ato Schalter verwendet, um die Aktivierung zu erzwingen. Wir erhalten die großartige Nachricht, dass das Produkt erfolgreich aktiviert wurde.

Wenn Sie den /dlv Schalter erneut verwenden, können Sie sehen, dass wir jetzt von Active Directory aktiviert wurden.

Was war schief gelaufen? Warum musste ich den installierten Schlüssel entfernen und diese generischen Schlüssel hinzufügen, damit diese Computer ordnungsgemäß aktiviert werden können? Warum haben die anderen Dutzend Computer ohne Probleme aktiviert? Wie ich bereits sagte, habe ich in den ersten Phasen der Betrachtung des Problems etwas Wichtiges verpasst. Ich war völlig verwirrt, also sprach ich auf das Poster aus dem ersten Blog. Das Poster sah das Problem sofort und half mir zu verstehen, was ich früh verpasst hatte.

Als ich den ersten /dlv Switch ausgeführt habe, war in der Beschreibung der Schlüssel. Die Beschreibung lautete Windows-Betriebssystem®, RETAIL Channel. Ich hatte mir das angesehen und dachte, dass RETAIL Channel bedeutete, dass es gekauft wurde und ein gültiger Schlüssel war.

Wenn wir uns die Ausgabe des /dlv Switches von einem ordnungsgemäß aktivierten Server ansehen, beachten Sie, dass die Beschreibung nun den VOLUME_KMSCLIENT Kanal angibt. Dadurch wissen wir, dass es sich tatsächlich um eine Volumenlizenz handelt.

Was bedeutet dieser RETAIL-Kanal dann? Nun, es bedeutet, dass das Medium, das zum Installieren des Betriebssystems verwendet wurde, eine MSDN-ISO war. Ich ging zurück zu meinem Kunden und fragte, ob es zufällig eine zweite Windows Server 2016 ISO im Netzwerk gab. Stellt sich heraus, dass ja, es gab eine weitere ISO im Netzwerk, und es wurde verwendet, um die anderen Dutzend Computer zu erstellen. Sie haben die beiden ISOs verglichen und sicher genug, dass die, die mir zum Erstellen der virtuellen Server gegeben wurde, tatsächlich eine MSDN-ISO war. Sie haben diese MSDN ISO aus ihrem Netzwerk entfernt, und jetzt haben wir alle vorhandenen Server aktiviert und haben keine Sorgen mehr, dass die Aktivierung bei zukünftigen Builds fehlschlägt.