rat hat geschrieben:Mir fällt aber jetzt das hier auf:
Der Product Key XXXXX-XXXXX-XXXXX-XXXXX-XXXXX wurde erfolgreich installiert.
Warum tut einer den allgemein bekannten Win 7 Pro Client Key "verXeln"? Da müßte doch der
FJ82H-XT6CR-J8D7P-XQJJ2-GPDD4
stehen.
Das war Blödsinn meinerseits. Der Key, mit dem der KMS-Server registriert wird, ist einmalig. Ich hatte das mit dem generischen Client-Key verwechselt.
rat hat geschrieben:
Wenn der Andre weiblich und mit ......
dann würde ich schon auf einen Schoßplatz bestehen
Das driftet gerade ab hier.
Und sorry, dass ich dich enttäuschen muss.
uncle_scrooge hat geschrieben:Normalerweise sucht der 'KMS-Client', egal ob per GUI oder slmgr.vbs nach diesem SLP record. Und nutzt dann den/die zurückgegebenen Werte.
Mit /skms setzt Du das außer Kraft. Und der 'KMS-Client' nutzt den mitgegebenen Server.
Aber es wäre nicht das erste Mal, daß Microsoft sich nicht an die eigene Dokumentation hält. Und nach dem immer mehr um sich greifenden Grundsatz verfährt: Mir egal, was der Admin da macht - ich weiß es besser.
Du hattest Recht, Microsoft ignoriert offensichtlich den skms-Parameter, zumindest solange Opsi den Befehlt durchführt. Warum, weiß ich nicht.
nslookup hat ergeben, dass der KMS-Server nicht aufgelöst wurde.
Bisher stand in unserem Bind der Eintrag
Nach einem Hinweis von
hier habe ich vorne den FQDN unserer Domäne mit integriert.
Damit funktioniert die Auflösung wieder und damit auch die Aktivierung. Was genau die Änderung verursacht hat, kann ich nicht sagen. Vielleicht ein Update vom Bind. Bescheuert ist hierbei allerdings die Inkonsistenz des Programmverhaltens, womit der skms-Parameter nach Belieben ignoriert wird.
Danke euch für die Hilfe.