MThomas

Dann sind wir uns jetzt ja alle einig und ich stelle fest: Für Clientaktivierungen sind 25 Zähler notwendig, wobei die Zählersumme aus Servern und Clients bestehen kann. (z.B. 6 Server und 19 Clients) Jetzt wäre es noch interessant, ob 23 Clients und 2 Server ebenso für eine Aktivierung der Server ausreichen würden. Gruß Thomas

Und wie komme ich dann auf einen Zählerstand von 7 ?? :confused: Und ebenso hätten die W7-Clients dann nach Deiner Theorie sofort aktiviert werden müssen - das ging aber erst bei Stand 25.

Zitat aus meinem Posting: Daher stand der KMS-Zähler auf 7 und es meldeten sich die W7-Clients über DNS beim KMS-Host. Bei Zählerstand 25 wurde das erste W7 aktiviert. Also: 7 Server wurden bereits aktiviert. Nach weiteren 18 W7-Clients bin ich auf die Gesamtanzahl 25 gekommen, so dass die W7-Clients aktiviert worden sind, ohne die Anzahl "25 W7-Clients" zu erreichen. Und darum ging's ja ;-))) Schönes WE allen hier

Hallo Norbert, Wieso? Ich habe keine 25 Windows7-Clients gebraucht, um die Aktivierung zu erreichen. Die Anzahl Server + Clients ist bei mir 25 gewesen. Daher ist ein Mischbetrieb zumindest in der Konstellation möglich, ohne 25 Clients in Betrieb nehmen zu müssen. ;)

Ich hatte einen KMS für 2k8R2 Datacenter. Da ich zur Zeit 7 Hosts virtuell laufen habe, wurden diese schon vor dem W7-Rollout aktiviert. Daher stand der KMS-Zähler auf 7 und es meldeten sich die W7-Clients über DNS beim KMS-Host. Bei Zählerstand 25 wurde das erste W7 aktiviert. Server sind während des bisherigen Rollouts keine hinzugefügt worden. ... hoffe geholfen zu haben Grüße Thomas

Hallo zusammen, kurze Rückmeldung: der KMS-Host hat die Clients ab 25 Hosts aktiviert. Das bedeutet, dass in der Regel die Summe von Client- und Serversystemen von 25 für Aktivierungen ausreichend ist. Das wiederum bedeutet: zahni hat Recht ;-D Viele Grüße Thomas

Kurze Rückmeldung: Der KMS-Host hat hochgezählt. Es war nur verwirrend, dass er Server- und Clientsysteme unter einem Zähler hochgezählt hat. Ich werde berichten, wann er bei mir aktivieren wird. Vielen Dank für die freundliche Hilfe

Ich glaube, dass wir aneinander vorbeireden ;-) Weder auf dem KMS-Host noch auf dem Client bzw. remote gelingt es mir, die Anzahl der Aktivierungsanfragen für Windows7 herauszufinden. Oder ich sitze gerade auf der Leitung und verstehe nicht, was Du meinst ;-) Ich werde mir aber nochmals alle Optionen für slmgr durchlesen, ob ich etwas übersehen habe und hier abschließend berichten. Gruß Thomas

So, nun habe ich nur gelesen, dass ich mir die Anzahl mit slmgr.vbs /dli am Client anzeigen lassen kann. Da bekomme ich nur die Info, dass die Anzahl nicht ausreicht. VAMT hatte ich mit WAIK/MDT schon installiert. Aus dem aktuellen WAIK habe ich nur die Version 1.2.300.0 - werde mir die andere Version mal suchen Danke auf jeden Fall für die bisherige Hilfe!

Der Zähler ist für mich interessant, da ich gesysprepte Images auf die KMS-Funktion überprüfen möchte.

Hallo zahni, das ist mir klar. Dennoch brauche ich die Info und wüßte gerne, wo ich sie finde. Gruß Thomas

Nach dem BIOS-Update gibt es nun keine Probleme mehr mit dem KMS. Er scheint nur noch über die Anzahl der Aktivierungsanfragen mit einem Fehler 0xC004F038 zu meckern. Wo kann ich denn nun auf dem KMS-Host den Zähler für W7 abfragen? Danke für die bisherige Hilfe - Grüße Thomas

Hallo zahni, das kann es ja nicht sein. Ich habe Komplettversionen von W7Prof und dazu die SAs gekauft. Da ich ein Rollout mittels MDT vorgesehen habe, kann es ja nicht sein, dass ich vorher erst noch ein altes System installieren muss. Mir wurde vom Verkauf versichert, dass das nicht der Fall sein wird. Wenn ich nachfragen darf: Wie wird hier im allgemeinen Windows7-Enterprise installiert? Grüße Thomas

Danke für die schnelle Antwort - aber ich stehe ein wenig auf dem Schlauch: Wie soll ich denn feststellen, wieviele z.B. Windows7-Aktivierungsanforderungen gemacht worden sind?! Normalerweise macht man das doch auf dem KMS-Host, oder? Ein "slmgr.vbs /dlv all" auf dem Client nützt mir ja nichts. Was verstehe ich falsch?

Danke für die Antworten. Ist es denn korrekt, wenn in der Ausgabe von "slmgr.vbs /dlv all" nur Office2010 und die Serverversionen geschrieben stehen? Erscheint der Windows7-Eintrag erst nach einem Aktivierungsversuch?

Hallo zusammen, ich habe auf einem Windows2008R2 einen KMS-Host installiert. Der KMS-Key stammt aus meinem Open-Vertrag über 2008R2-Datacenter. Der Aufruf von "slmgr.vbs /dli" ergibt u.a. VOLUME_KMS_R2_C channel. "slmgr /dlv all" gibt lediglich meine Server- und Officelizenzen aus. W7 ist dort nicht hinterlegt. Nun habe ich SA für meine Clients mittles OpenValue erworben und über das VLS die Enterpriseversionen mit dem KMS-Key erhalten. Der KMS-Key lässt sich nicht auf dem KMS-Host installieren, da ja schon der übergeordnete Key "VOLUME_KMS_R2_C channel" installiert ist. Leider lassen sich so keine Windows7-Clients aktivieren bw. der Zähler geht nicht hoch, da ja "slmgr /dlv all" keinen Windows7-Eintrag enthält. Die Fehlermeldung am Client nach "slmgr /ato" lautet: Fehler 0xc004f035 entspricht "fehlendes qualifiziertes OS", was auf den Slic-table deutet. Aber zuerst einmal möchte ich sicher stellen, dass der KMS-Host richtig arbeitet bzw. den richtigen KMS-Key erhalten hat. Daher meine Fragen: 1. Ist es möglich, dass nicht alle "Kategorie-C-KMS-Keys" Windows7 beinhalten? Muss "slmgr /dlv all" Einträge für Server und Clientsysteme ausgeben? Oder erscheint der Eintrag erst, nachdem sich ein W7-Client aktivieren möchte? 2. Kann ich einen neuen Key beantragen, der alle Einträge enthält? Beim VLC-Service konnte mir niemand helfen, da zu technisch 3. Empfiehlt es sich, einen zweiten KMS-Host auf einem anderen 2008R2 zu installieren und dort den KMS-Schlüssel für Windows7 zu installieren? 4. Kommen sich, falls Punkt 3 in Frage kommt, die beiden KMS-Hosts in die Quere? Einer wäre dann für Office2010 und 2008R2datacenter verantwortlich und der zweite Host eben für Windows7-Enterprise. Über Eure Empfehlungen würde ich mich sehr freuen. Grüße Thomas

Stimmt, Du hast Recht. Die 64-Bit-Probleme bekomme ich nur, wenn ich eine z.B. 32Bit-SB-non_OSB-Version umziehe und ein 64Bit-Image einsetzen möchte, ohne für diesen Rechner eine SA zu besitzen. Danke für die Richtigstellung! Grüße Thomas

Was macht ihr bzw. werdet ihr machen mit 64Bit-Rechnern? Ein 64Bit-W7 dürftet ihr dann nicht reimagen - so habe ich es verstanden. Grüße Thomas

Danke für Deine Antwort, allerdings sehe ich das anders: 1. Ich habe ca. 70 Maschinen mit XP Prof und viele der Rechner sind Windows7-fähig. Um nur eine SA zu erstehen, brauche ich ein qualifiziertes OS - am preiswertesten: SB+SA 2. Wenn ich mir dann schon ein OS kaufen muß, dann wird es sicherlich keine OEM-Version sein. Das wäre sparen am falschen Ende. 3. Später kann ich mir dann aussuchen, ob ich Rechner mit OEM oder ohne System kaufen möchte. Allerdings habe ich bisher immer bessere Angebote ohne OS bekommen - auch bei einzelnen PCs. Gerne poste ich bei Bedarf den Link. 4. Ich kann meine Rechner schneller inkl. aller von mir benötigten Programme intern ausrollen, anstatt z.B. eine OEM-Version zu benutzen. Hinzu kommt, dass die meisten OEM-PCs vorinstalliert und ohne Datenträger ausgeliefert werden. Das heißt, dass ich entweder eine Sicherungsimage machen muß oder eine CD/DVD erhalten muß. "Echte" Recovery-CDs brauchen ggf. eine Partition auf der HD zum recovern. Im Vorwege die passende OEM-Version zu wählen, einscheint also ebenso mit Aufwand verbunden zu sein, als von Anfang an eine korrekte SB-Version zu wählen und meine Volume-Edition schnell auszurollen. 5. Bei der korrekten Wahl einer SB-Version, spricht in meinen Augen auch nichts dafür, sich für wiederkehrende OEM-Ausgaben zu entscheiden. 6. Letztendlich ist es eine Geschmacksache :-) Vielen Dank für alle Antworten. Ich habe keine Fragen mehr zum Thema. Grüße Thomas

Hallo zusammen, da nun niemand eine Glaskugel hat, formuliere ich meine Frage mal anders: http://www.mcseboard.de/microsoft-lizenzen-50/ubertragen-lizenzen-ersatzgeraet-187794.html In dem oben verlinkten Betrag hat Die.Minka geschrieben: "Eine andere Variante wäre vor dem Zuweisen der SB-Windows-Lizenz die SA "drauf" zu packen, dann würden für diese Lizenz die PURs gelten, aber in den PURs steht folgendes: Im Allgemeinen können folgende Elemente nicht neu zugewiesen werden: • Lizenzen auf einer kurzfristigen Basis (d. h. nicht innerhalb von 90 Tagen nach der letzten Zuweisung) • Lizenzen für das Windows-Desktop-Betriebssystem " Ich zitiere nun der Vollständigkeit halber von Seite 11 der PURs: "• Neuzuweisung von Software Assurance für das Windows-Desktop-Betriebssystem. Entgegen der allgemeinen Regel, nach der Software Assurance nicht getrennt von der zugrunde liegenden Lizenz neu zugewiesen werden darf, sind Sie berechtigt, Software Assurance für das Windows-Desktop-Betriebssystem auf einen Ersatzcomputer zu verschieben. Bedingung ist, dass diese Neuzuweisung nicht kurzfristig erfolgt (d. h. nicht innerhalb von 90 Tagen nach der letzten Zuweisung) sowie dass das Ersatzgerät für ein berechtigendes Betriebssystem gemäß den Anforderungen in der Produktliste lizenziert ist. Nach der Neuzuweisung von Software Assurance für das Windows-Desktop-Betriebssystem von einem Gerät auf ein anderes müssen Sie alle zugehörigen Desktop-Betriebssystem-Upgrades von dem bisherigen Gerät entfernen. " Da auf dem Ersatzgerät ein berechtigtes Betriebssystem gemäß den Anforderungen in der Produktliste vorhanden sein muß, kann ich anscheinend nicht jede SB-Version nehmen und somit sollte "die SA draufpacken" keinen Vorteil bei z.B. OEM bringen, oder? @Die.Minka: Mit welcher Bezeichnung hast Du Deine SB-Version gekauft? @lizenzdoc: Wie sieht es aus mit dem EULA von Deinen SB-Versionen aus? Mit welcher Bezeichnung hast Du Deine Versionen gekauft? Stimmt Dein EULA bsiher bei allen non-OSB-Versionen? Eventuell kann noch jemand zum EULA der jetzigen "non-OSB"-SB-Versionen etwas sagen, ob sich am EULA etwas geändert hat. Letztendlich geht es mir darum, 70 SB-Versionen zu kaufen, die ich laut EULA auch umziehen darf bzw. das Bundle SA + SB-Version umziehen darf. Einen Fehlkauf möchte ich vermeiden ;-) Grüße Thomas

Hallo Franz, vielen Dank für Deine Hilfestellungen. Ich habe mich die letzten Tage ausführlicher mit Deinen Infos und dem Lizenzrecht auseinandergesetzt. Mich würde interessieren, ob ich mit einigen möglichen Wegen, die für mich interessant sein könnten nun richtig liege: Möglichkeit 1: Bei ca. 70 Rechnern Windows 7 Prof SB non OSB einsetzen, keine Volumenlizenz und keine SA Kosten ca. 7.700,-€ einmalig - Nachteile: z.B. kein Re-Imaging, neue Versionen müssen wieder gekauft werden Entscheidung für 32Bit oder 64Bit-Version Möglichkeit 2: Wie bei Möglichkeit 1 die SB-Software kaufen und 5 Arbeitsplätze mit einer Volumenlizenz versorgen. Kosten: 7.700,-€ einmalig + 5 mal Open license Upgrade only für ca. 1000,- € Vorteile: Re-Imaging möglich Nachteile: Re-Imaging nur bei gleicher Version (32Bit oder 64Bit) möglich Möglichkeit 3: Für ca. 70 Rechnern Windows 7 Prof SB 32Bit non OSB , SA innerhalb von 90 Tagen dazukaufen - für mich interessant Open Value non company wide Kosten: 7.700,-€ einmalig, ca. 4130,-€ jährlich (Teilzahlung) über 3 Jahre u. erweiterbar Summe: ca. 20.090 ,-€ Vorteile: große Flexibilität durch Volumelizenzen und SA, ich kann ebenso ein W7 Enterprise wahlweise 64Bit oder 32Bit reimagen, Lizensierung per KMS, aktuelles OS usw. Ich habe mich für Möglichkeit 3 entschieden, da der Mehraufwand pro Rechner pro Monat bei ca. 15 Euro liegt und ich diesen Aufwand schnell einsparen werde und zudem innerhalb meiner SA auf Windows8 updaten könnte. In den PUR 04.2012 habe ich nun auch unter Neuweisung von Liz. Seite11 gelesen, dass ich eine SA für mein OS unter Bedingungen neuzuweisen darf- soweit gut. Nun muß ich noch die richtige SB-Version mit entsprechendem EULA wählen. Folgende Diskussion habe ich verfolgt: http://www.mcseboard.de/microsoft-lizenzen-50/ubertragen-lizenzen-ersatzgeraet-187794.html Wie kann ich vor einem Kauf erkennen, ob mir das EULA ein Übertragen des SB-Windows7 auf andere Hardware erlaubt? Da ich mir Rechner meistens ohne OS kaufe, wäre die Beantwortung für mich interessant und auf ein "non OSB" möchte ich mich nicht verlassen. Wie macht ihr das, wenn ihr keine OEM-Version einsetzt? Grüße Thomas

Hallo zusammen, folgende Situation: Es ist eine gemischte Systemumgebung vorhanden, das heisst, dass Clientmaschinen mit XP Prof OEM, XP Prof SB usw. vorhanden sind. Im Zuge einer Umstellung auf Windows 7 möchte ich Volume-Lizenzen inkl. SA einführen. Zu meiner geplanten Vorgehensweise: 1. Clients, die den W7-Anforderungen genügen haben auch mit XP-OEM eine gültige Basislizenz für Volumelizenzen. 2. OEM-Clients, die ersetzt werden müssen , bekommen eine gültige z.B. günstige Vollversion von Windows NT Workstation , so dass eine gültige Basislizenz vorhanden ist. 3. Volumelizenzen inkl. SA kaufen - Die SA ist ab diesem Zeitpunkt den PCs fest zugeordnet. 4. Bei Austausch der Clienthardware kann die SA übertragen werden, wenn auf dem neuen PC die am Datum der Zuweisung erhältliche neueste Version des Desktop-Betriebssystems vorhanden ist. Die Upgradeversionen müssen auf dem alten PC gelöscht werden. Gelesen habe ich hier u.a. ohne Einwände: siehe vorletzte Antwort von Lizenzdoc: http://www.mcseboard.de/microsoft-lizenzen-50/lizenzkleber-oem-fpp-geht-hardwaretausch-4-154670.html Zitat: ...immer dazu rate langfristig zu denken und die Hardware nur mit SB (Systembuilder) OS zu kaufen ( Kein Porblem beim Übertragen !)und dazu passend die SA ( Übertragung erlaubt)... Frage: Die angesprochene Übertragung der SA auf einen anderen PC ist doch nicht erlaubt, wenn dort zu diesem Zeitpunkt nicht das aktuellste Windows installiert ist. Also ist es in absehbarer Zeit doch egal, ob ich die SB-Version übertragen kann, denn sie ist irgendwann nicht mehr aktuell. Bei der Erstanschaffung müßte es demnach empfehlenswerter sein, für neue PCs ein z.B. "Windows NT Workstation Vollversion" zu kaufen, da Windows NT, 98SE, W2000 usw. als Basislizenz akzeptiert wird. Das einzige Risiko wäre der PC-Ausfall, denn dann müßte ich mir ein aktuelles OS für die neue Hardware kaufen. Aber bei z.B. 20 neuen Rechnern sehe ich den Preisvorteil bei einer NT-Lizenz (beispielsweise 1 Euro) gegenüber den SB-Versionen (über 100,- Euro). Ich würde ca. 2000,- Euro sparen und und hätte nur das Restrisiko, falls ein neuer PC kaputt gehen würde. Quelle für z.B. Basislizenz NT unter qualifizierte Betriebssysteme: Microsoft Volume Licensing - Windows 7 Irgendwann sollte ich dann bei einer zukünftigen Übertragung der SA auf eine neue Clienthardware wieder die günstigste aber aktuellste Basislizenz wählen - in dem Fall dann die aktuellste SB-Version. Liege ich mit meiner Denkweise falsch? Warum sollte ich von vornherein eine SB-Version von W7 für viel Geld kaufen? Grüße Thomas

Vielen Dank. Die Idee mit der separaten VM finde ich sehr gut. Somit habe ich nun die für mich perfekte Lösung. Grüße Thomas

Hallo zusammen, sicherlich habt ihr Recht: Neu aufsetzen ist die beste und sicherste Lösung. Snapshot und State zurücksichern ist aber die schnellste Lösung ;-)) zumal bei uns im AD nicht zu viel passiert. Dazu bin ich nebst Urlaubsvertretung der einzige Admin, der Änderungen an den Servern vornimmt und die USN sich so nicht unerwartet erhöhen kann. Vielen Dank aber für die Kritik. Ich werde daher eine VM vorbereiten, die im Notfall zum DC gemacht wird und die Rollen übernehmen kann. Das schließt dann wohl jedes Risiko aus und geht auch recht schnell. Eventuell weiss jemand, ob ich dann einfach einen neuen KMS aufsetzen kann, ohne den alten KMS irgendwo entfernen zu müssen. Das gleiche gilt für eventuelle Lizenzserver, die auf dem DC in Zukunft laufen könnten, denn der virtuelle DC wird Rollenmaster, zweiter Katalogserver, DNS, KMS und Lizenzserver sein. Gerade die letzten genannten Gründe haben mich zur Überlegung bewegt, eventuell doch eher auf die Sicherungen und Systemstate zurückzugreifen - damit würde ich zu 99% keine Objekte im AD verlieren und hätte innerhalb von 10 Minuten die DCs wieder aktiv. Voraussetzung wäre natürlich eine regelmäßige Systemstatesicherung, um ein USN-Rollback zu vermeiden. Danke für die vielen Stellungnahmen und die gute Diskussion Viele Grüße Thomas

Ich sehe bei Snapshotsicherungen keine Probleme, wenn ich ich die VM zurücksichere und ausgeschaltet lasse. Dann trenne ich die VM vom Netzwerk, fahre sie hoch und spiele das gesicherte Systemstate zurück. Anschließend spiele ich auf dem anderen DC ein zeitgleiches Systemstate zurück und fahre die DCs wieder im Netzwerk hoch. Das müsste doch klappen, oder? Grüße Thomas