Microsoft will es dem Kunden ja nur einfacher machen. Darum wurde ja der KMS Dienst eingeführt. Somit braucht man sich während der Installation des Betriebssystems nicht mehr um die Aktivierung kümmern. Sobald eine funktionierende KMS Umgebung vorhanden ist, aktiviert sich der Client von alleine.
Wirklich immer? Nein, es kommt manchmal vor, dass sich der Client trotz funktionierender KMS Umgebung nicht aktivieren kann. Ein Kollege von mir, wurde an einem Rechner mit dieser Fehlermeldung begrüßt:
Da die Maschinen alle per SCCM 2007 SP2 betankt wurden, konnte man davon ausgehen, dass die Software (incl. OS) auf allen Maschinen gleich war. In der Testphase gab es auch nur 4 Rechnertypen, diese hatten bis jetzt auch keine Probleme. Der KMS konnte gleichzeitig aber andere Maschinen aktivieren. Wo sollte dann das Problem liegen?
Auch konnte man den Rechner nicht von Hand per Kommando gegen einen KMS Server aktivieren. Der Versuch mit:
wird mit der folgenden Fehlermeldung quittiert:
Auch ein Auslesen der KMS Client Informationen per folgendem Befehl zeigte keine Auffälligkeiten:
Der Lizensierungsmodus stand auf KMS und der Host hatte noch 30 Tage zum Aktivieren. Des Weiteren konnte man auch noch zwei Mal die Aktivierung des Clients verschieben:
Um zu überprüfen, ob es sich um ein valides Betriebssystem handelt, wurde das “Microsoft Genuine Advantage Diagnostic Tool” heruntergeladen und installiert. Nach dem Test stellte sich heraus, dass es doch kein valides Betriebssystem ist?! Alle Rechner wurden per SCCM mit der gleichen Testsequence betankt, trotzdem verhalten sie sich in diesem Fall völlig unterschiedlich. Wie kann dies sein?
Zum Glück kann man das Ergebnis des “Microsoft Genuine Advantage Diagnostic Tool” in eine Textdatei exportieren. Dort sieht man im Bereich “OEM Activation 2.0 Data”, dass nicht alles wie gewünscht geprüft werden konnte. Der ominöse “Windows marker” konnte nicht ausgelesen werden. Wozu wird dieser Marker den überhaupt benötigt? Damit OEM Hersteller sich in Ihren Fertigungsanlagen keine eigene KMS Infrastruktur aufbauen müssen, gibt es ein bestimmtes Abkommen zwischen den OEM Herstellern und Microsoft. Die OEMs erweitern Ihre BIOS Systeme um ein bestimmtes Feld. Dieses lautet “Software Licensing table” In diesem werden die benötigten “Windows marker” Daten eingetragen. Hierdurch weiß der KMS Dienst dann, das er sich auf einem OEM System bewegt und verhält sich dementsprechend.
In diesem Fall war es dann so, dass zwar der “Software Licensing table” vorhanden war, aber die Daten in dem Feld waren entweder korrupt oder gar nicht vorhanden. Im Log stand dann folgender Eintrag:
BIOS valid for OA 2.0: yes, but no Windows marker
Windows marker version: N/A
OEMID and OEMTableID Consistent: yes
Also wurde schnell ein BIOS Update gemacht. Dadurch wurde der “Software Licensing table” mit den benötigten OEM Informationen gefüllt. Das Ergebnis des “Microsoft Genuine Advantage Diagnostic Tool” lieferte dann folgendes Ergebnis im Log:
BIOS valid for OA 2.0: yes, but no SLIC table
Windows marker version: N/A
OEMID and OEMTableID Consistent: N/A
Zwar kann immer noch nicht die Version ausgelesen werden (oder diese soll nicht mehr angezeigt werden?), aber die Fehlermeldung ist weg. Danach ließ sich der Rechner auch ohne Probleme aktivieren. Auch nach einer automatisierten Neuinstallation funktionierte die Aktivierung wie gewohnt. Der Fehler ist auch reproduzierbar. Sobald die alte Firmware eingespielt wird, kann der Rechner nicht mehr aktiviert werden.
Somit steht es wieder mal fest. In der IT ist alles gleich, nur manches ist gleicher… 
Ein sehr interessanter Artikel.
Hallo Andreas,
vielen Dank.
Gut zu wissen, dass es für andere Interessant ist.
Gruß
Thorsten