Problembehandlung bei Active Directory-basierten Aktivierungsclients (ADBA), die nicht aktiviert werden
Hinweis
Dieser Artikel wurde ursprünglich als TechNet-Blog am 26. März 2018 veröffentlicht.
Ich leistete kürzlich Support für einen Kunden bei der Bereitstellung von Windows Server 2016 in seiner Umgebung. Wir nutzen die Gelegenheit, um zugleich die Aktivierungsmethode von einem KMS-Server auf Aktivierung über Active Directory umzustellen.
Als ordnungsgemäßes Verfahren zum Vornehmen aller Änderungen haben wir die Migration in der Testumgebung des Kunden gestartet. Wir haben mit der Bereitstellung begonnen, indem wir die Anweisungen in der Active Directory-basierten Aktivierung im Vergleich zu Schlüsselverwaltungsdienst s befolgen. Die Domänencontroller in der Testumgebung haben alle Windows Server 2012 R2 ausgeführt, daher mussten wir die Gesamtstruktur nicht vorbereiten. 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 folgen dem Blogbeitrag schritt für Schritt.
Wir haben begonnen, vier virtuelle Computer zu erstellen, zwei Windows 2016 Server Standard und zwei Windows 2016 Server Datacenter. An diesem Punkt war alles großartig. Wir haben einen physischen Server mit Windows 2016 Server Standard erstellt, und der Computer wurde ordnungsgemäß aktiviert.
Ja, es stimmt schon, das Setup und die Konfiguration waren superleicht, dieser Teil war wirklich einfach und geradlinig. Allerdings haben alle virtuellen Computer, die ich in der vorherigen Woche erstellt habe, gezeigt, dass sie nicht aktiviert wurden. Ich kehrte zum physischen Computer zurück, und der war in Ordnung. Ich setzte mich mit dem Kunden in Verbindung, um zu erörtern, was passiert war. Die erste Frage lautete "Was hat sich am Wochenende verändert?" Und wie üblich war die Antwort "nichts". Diesmal war nichts wirklich geändert worden, und wir mussten herausfinden, was gerade passiert war.
Ich ging zu einem der Problemserver, öffnete eine Eingabeaufforderung und überprüfte die Ausgabe des slmgr /ao-list Befehls. Die /ao-list Option zeigt alle Aktivierungsobjekte in Active Directory an.
Die Ergebnisse zeigen, dass wir zwei Aktivierungsobjekte haben: eine für Windows Server 2012 R2 und die neu erstellte KMS AD-Aktivierung (** LAB), die die Windows Server 2016-Lizenz ist. Dadurch wird bestätigt, dass Active Directory ordnungsgemäß konfiguriert ist, um Windows KMS-Clients zu aktivieren.
Ich weiß, dass der Befehl für die slmgr Lizenzaktivierung vorgesehen ist, habe ich mit verschiedenen Optionen fortgesetzt. Ich habe versucht, den /dlv Switch zu verwenden, der detaillierte Lizenzinformationen anzeigt. Das sieht gut aus, ich habe die Standardversion von Windows Server 2016 ausgeführt, es gibt eine Aktivierungs-ID, eine Installations-ID, eine Überprüfungs-URL, sogar einen teilweisen Product Key.
Fällt jemandem auf, was mir an dieser Stelle entgangen ist? Wir kehren nach meinen anderen Schritten zur Problembehandlung zurück, reichen aber aus, um zu sagen, dass sich die Antwort in diesem Screenshot befindet.
Mein Denken ist jetzt, dass der Schlüssel aus irgendeinem Grund unterbrochen ist, also verwende ich den /upk Schalter, der den aktuellen Schlüssel deinstalliert. Obwohl dies beim Entfernen des Schlüssels wirksam war, ist dies im Allgemeinen nicht die beste Methode, dies zu tun. Sollte der Server neu gestartet werden, bevor er einen neuen Schlüssel erhält, kann er den Server in einem fehlerhaften Zustand belassen? Ich fand, dass die Verwendung des /ipk Schalters (die ich später in meiner Problembehandlung tue) den vorhandenen Schlüssel überschreibt und eine sicherere Route ist.
Ich habe die /dlv Option erneut ausgeführt, um die detaillierten Lizenzinformationen anzuzeigen. Leider gab mir das keine hilfreichen Informationen, nur ein Product Key nicht gefunden Fehler. Da es keinen Schlüssel gibt, da ich ihn gerade deinstalliert habe.
Ich stellte fest, dass es ein langer Schuss war, aber ich habe versucht, den /ato Switch zu aktivieren, der Windows für die bekannten KMS-Server (oder Active Directory, wie der Fall sein kann) aktivieren sollte. Wieder nur ein Produkt nicht gefunden-Fehler.
Der nächste Gedanke war, dass manchmal stoppt und ein Dienst startet, also habe ich versucht, dies als nächstes. Ich musste den SPPSvc-Dienst (Microsoft Software Protection Platform Service) beenden und neu starten. Aus einer Administratorbefehlsaufforderung verwende ich die Vertrauensstellung net stop und net start Befehle. Ich stelle zunächst fest, dass der Dienst nicht ausgeführt wird, also denke ich, dass dies sein muss.
Nach dem Starten des Diensts und dem Versuch, Windows erneut zu aktivieren, wird das Produkt jedoch weiterhin nicht gefunden.
Anschließend sah ich mir das Anwendungsereignisprotokoll auf einem der Problemserver an. Ich fand 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 Volumebezeichnungssyntax falsch ist. Durch die im Artikel beschriebenen Methoden zu lesen, scheint es nicht, dass einer von ihnen in die Situation passt. 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 zu umgehen), aber auch die fünf Domänencontroller. Dies hat darauf hingewiesen, dass es sich nicht um ein DNS-Problem handelte und die Probleme an anderer Stelle aufgetreten waren.
Also ist klar, dass DNS in Ordnung ist. Active Directory ist ordnungsgemäß als KMS-Aktivierungsquelle konfiguriert. Der physische Server wurde ordnungsgemäß aktiviert. Konnte dies ein Problem sein, das nur virtuelle Computer betrifft? Als interessanten Aspekt am Rande teilte mit mein Kunde mit, dass jemand in einer anderen Abteilung sich entschieden hatte, ebenfalls virtuelle Windows Server 2016-Computer aufzubauen, gleich mehr als ein Dutzend. Jetzt gehe ich also davon aus, dass ich noch ein dutzend Server habe, mit denen ich umgehen kann, die nicht aktiviert werden. Diese Server sind jedoch nur in Ordnung.
Nun, ich ging zurück zum slmgr Befehl, um herauszufinden, wie diese Monster aktiviert werden. Diesmal verwende ich den /ipk Switch, der es mir ermöglicht, einen Product Key zu installieren. Ich ging zu Anhang A: KMS-Clientsetupschlüssel , um die entsprechenden Schlüssel für die Standardversion von Windows Server 2016 zu erhalten. Einige Server sind Datacenter, aber ich muss diese zuerst beheben.
Ich habe die /ipk Option zum Installieren eines Product Keys verwendet und den Windows Server 2016 Standard-Schlüssel ausgewählt.
Von hier an habe ich nur noch Ergebnisse für die Datacenter-Server erfasst (es waren die gleichen). Ich habe den /ato Schalter verwendet, um die Aktivierung zu erzwingen. Wir erhalten die tolle Nachricht, dass das Produkt erfolgreich aktiviert wurde.
Wenn Sie den /dlv Switch erneut verwenden, können wir sehen, dass wir jetzt von Active Directory aktiviert wurden.
Tja, aber was war eigentlich schief gelaufen? Warum musste ich den installierten Schlüssel entfernen und diese generischen Schlüssel hinzufügen, um eine ordnungsgemäße Aktivierung dieser Computer zu erreichen? Warum ließ sich das andere Dutzend (oder so) Computer problemlos aktivieren? Wie ich bereits erwähnt habe, war mir in der Frühphase meiner Auseinandersetzung mit dem Problem etwas entgangen. Ich war gründlich verwirrt, also erreichte 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 die erste /dlv Option ausgeführt habe, war in der Beschreibung der Schlüssel. Die Beschreibung lautete „Windows® Operating System, RETAIL Channel“. Ich hatte mir das angesehen und gedacht, „RETAIL Channel“ bedeute, dass der Schlüssel erworben worden war und also einen gültigen Schlüssel darstellte.
Wenn wir die Ausgabe des /dlv Switches von einem ordnungsgemäß aktivierten Server betrachten, beachten Sie, dass die Beschreibung jetzt den VOLUME_KMSCLIENT Kanal angibt. Dies teilt uns mit, dass es sich tatsächlich um eine Volumenlizenz handelt.
Also was bedeutet dann „RETAIL channel“? Nun, in diesem Fall bedeutet es, dass das zur Installation des Betriebssystems verwendete Medium ein MSDN-ISO-Image war. Ich wandte mich also wieder an meinen Kunden und fragte ihn, ob möglicherweise ein zweites Windows Server 2016-ISO-Image im Netzwerk vorhanden war. Und es stellte sich heraus: Ja, es gab ein weiteres ISO-Image im Netzwerk, und das war verwendet worden, um das andere Dutzend Computer zu erstellen. Die beiden ISO-Images wurden verglichen, und das, welches ich erhalten hatte, um die virtuellen Server zu erstellen, war ein MSDN-ISO-Image. Sie haben die MSDN-ISO aus ihrem Netzwerk entfernt, und jetzt haben wir alle vorhandenen Server aktiviert und machen sich keine Sorgen mehr über den Aktivierungsfehler bei zukünftigen Builds.