g1n

Hej Norbert und Jarazul, vielen Dank für eure Hilfe, jetzt hab ich das System kapiert. Mit einer Windows 7 Maschine konnte ich den KMS nun erfolgreich etablieren. Die Hitze in den letzten Tagen hat mein Gehirn wohl überlastet ;) Aber dank eurer Hilfe läufts nun :) Gruß g1n

Okay, hm, das war die naheliegende Lösung da wir schon einige Hosts mit Domain-Diensten haben, die alle auf 2008R2-Datacenter laufen. D.h. um meine Windows 7 und Office 2010-Lizenzen per KMS zu aktivieren, müsste ich demzufolge (laut MS) eine Win Vista/7/2003R2 KMS1.2 Maschine aufsetzen und dann sollte es klappen, oder? Gruß g1n

Ich danke euch für die Antworten! Das Problem ist aber nun, das ich keinen KMS-Host-Key für den 2008 R2 Datancenter habe. Wir haben die Datacenter-Lizenzen für unsere neuen Systeme von HP als OEM-Variante bekommen, nicht als Volumen-Lizenz. Im VLSC finde ich nur die KMS-Keys für Windows 7 und Office 2010, aber leider keinen KMS-C-Key für Windows 2008 R2 Data. Es gibt zwar KMS-Client-Keys für Windows 2008 R2 Data, allerdings benötige ich dafür ja einen bestehenden KMS der diese Version aktivieren kann, da der alte KMS nur ein 2003 R2 Standard ist, kann dieser den 2008R2 Data ja nicht aktivieren :( Was nun? oder bin ich nur zu doof das Prinzip zu verstehen :( ?

Die neue virtuelle Maschine ist ein Win2k8R2 Datacenter, OEM-aktiviert schönen Abend g1n

Hi Leute, nach tagelangem googlen, stell ich mein Problem nun doch mal hier ein um die weisen Nutzer um Rat zu fragen, bevor ich komplett verzweifle. Folgende Ausgangssituation: Windows 2003 R2-Domain mit 3 DCs Win7SP1-32bit Clients KMS auf einem der DCs Office 2010 wird aktuell über den KMS aktiviert Win7 wird noch manuell aktiviert Soll Situation: Nach umfangreichen Umbaumaßnahmen (neu Hardware, Virtualisierung mit VMWare) bei denen ich die neue, virtualisierte Umgebung (Windows 2008 R2 Dataccenter) in die bestehende Domain aufgenommen habe, begann die Migration der Dienste, die bis dato auch hervoragend lief. Nun versuche ich bereits seit letzter Woche den KMS auf einer neue virtuellen Maschine (Win2k8R2 Datacenter, OEM-Key aktiviert) zum laufen zu bekommen, leider vergebens. Wenn ich die diversen Artikel richtig verstanden habe, läßt sich der KMS auf besagter Maschine aktivieren, in dem man slmgr.vbs /ipk {KMSKey} eintippt. und genau hier besteht das Problem. Weder mein KMS-Key für Windows 7 noch für Office 2010 wird angenommen, das Tool gibt die Rückmeldung dass die Keys ungültig seien. Ich hab bereit gecheckt dass der DNS-Eintrag richtig sitzt und auch die FW ist entsprechend präpariert. Der KMS auf der alten Windows 2003 R2 Standard 32-bit-Kiste (aktiviert mit OEM-key) aktiviert problemlos das unsere Office 2010 (wenn ich den DNS-Eintrag auf den alten Server zurückstelle). Ich finde leider keine hilfreichen Informationen, warum auf der 2008er virtuellem Maschine die KMS-Keys als ungültig angesehen werden. Wahrscheinlich bin ich einfach nur unfähig. Weiß jemand Rat? Beste Grüße g1n

Hi, ich wollte das Thema eigentlich nicht nochmal ausbuddeln, aber evtl. ist die Antwort für andere hilfreichen. Der Auslöser des Problems war die Aufstellung der Netzstruktur (mehr oder weniger). Das Exakte Problem war, dass der Standort der die Probleme hatte zwar in der Firewall nicht gesperrt war, aber diese FW NAT nutzte...was z.b. nur eine einzelne SMB-Verbindung zulässt. Das System wurde leicht umgestrickt so dass kein NAT mehr von Nöten war und schon hat sich das Problem erledigt ;)

sorry das ich solange nicht geantwortet habe, war krank. @Sunny danke für den Tipp, dass GPO-Setting ist bei allen Rechner aktiviert (gab sonst Probleme bei der Installation von MSI-Paketen per GPO). Ich werde bei der nächsten Gelegenheit werde ich die netsh-Befehle mal probieren. melde mich g1n

Als Sicherheitssoftware verwenden wir die Windows Firewall, die aber exakt genauso konfiguriert ist wie davor unter Windows XP. Ich hatte auch erst die Vermutung das diese evtl. dazwischenfunkt und habe sie testhalber deaktiviert. Leider ohne Erfolg. Als Antivirensoftware setzten wir F-Secure for Windows Workstations in Version 9 ein, dort wird nicht in die Netzwerkkonfig eingegriffen. Hier mal IP-Config eines der Rechner...wie es der Zufall will, lässt sich das Problem gerade nicht reproduzieren ;) ich hab aber jedesmal bei der ipconfig reingeschaut wenn das Problem bestand. DHCP stand auf aktiv und Windows hatte dem Rechner einfach eine 169er IP zugeteilt mit 255.255.0.0 Subnetzmaske...der Klassiker wenn Windows kein DHCP-Signal bekommt ;) Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : PC-4200100 Primäres DNS-Suffix . . . . . . . : domain.local Knotentyp . . . . . . . . . . . . : Unbekannt IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : domain.local Ethernet-Adapter LAN-Verbindung 3: Verbindungsspezifisches DNS-Suffix: domain.local Beschreibung. . . . . . . . . . . : Marvell Yukon 88E8057-PCI-E-Gigabit-Ethernet-Controller Physikalische Adresse . . . . . . : 44-87-FC-44-F1-63 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::f5ad:21cb:5c1a:de04%15(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 192.168.3.34(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Lease erhalten. . . . . . . . . . : Freitag, 3. September 2010 09:29:39 Lease läuft ab. . . . . . . . . . : Samstag, 4. September 2010 09:29:39 Standardgateway . . . . . . . . . : 192.168.3.2 DHCP-Server . . . . . . . . . . . : 192.168.3.11 DHCPv6-IAID . . . . . . . . . . . : 306481148 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-13-91-4C-BF-00-01-6C-95-A0-3B DNS-Server . . . . . . . . . . . : 192.168.3.11 192.168.3.12 NetBIOS über TCP/IP . . . . . . . : Aktiviert Tunneladapter isatap.domain.local: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: diffferent.local Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja

Hi Leute, da ich seit neustem meine Laptops auf Arbeit nach und nach auf Windows 7 Professional umstelle, bemerke ich nach und nach immer mehr Problem mit dem Netzwerkstack (kann sein das diese Problem bereits unter Windows Vista bestanden, habe ich nur nie eingesetzt im Unternehmen). Wenn die Thinkpads (T400s/T400/L412) mit Netzwerkstecker angesteckt hochfahren ist alles in Ordnung. Wenn dann aber der Netzwerkstecker entfernt und später wieder eingesteckt wird, kommt es sehr häufig vor, dass der Rechner vom DHCP-Server keine IP mehr zugewiesen bekommt (die Netzwerkerkenung mahnt dann ein "nicht identifiziertes Netzwerk" an). Der DHCP-Server läuft auf einem Windows 2003 R2 Server, wo es mit diesen Rechnern die vorher mit Windows XP SP3 liefen, nie solche Probleme gab. Ich habe spaßeshalber per Regedit auf einigen der Rechner die Netzwerkidentifizierung deaktiviert ([HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NlaSvc\Parameters\Internet\ "EnableActiveProbing"=dword:00000000), was aber nicht unbedingt einen großen Effekt hatte. Ich verwende, soweit ich das sehe, die aktuellste treiber für die Netzwerkchips. Hat jemand bei sich ähnliche Situationen beobachtet und evtl. eine Idee wie man solche Vorkommnisse minimieren kann? Beste Grüße und danke fürs Lesen, g1n

hm....Genau das macht mich ja stutzig. Da in der EULA in keiner Weise geklärt ist wie ich und von welchem Medium ich die Installation zu berwerkstelligen habe. Zumind. habe ich dazu keinen Abschnitt gefunden. Das würde ja laut deiner Erklärung bedeuten dass ich Windows quasi garnicht neuinstallieren darf ;)

@Dr. Melzer Die genaue Fallnummer aufzuführen hielt ich für überflüssig, schließlich ist dieser Urteil zum damaligen Zeitpunkt groß durch die Presse gegangen, und jeder der irgendwas mit diesem Thema zu schaffen hat, kennt auch das Ergebnis dieses Urteils....ein Fallnummer aufzurufen ist Haarspalterei, es ging schließlich nur um den Sachverhalt dass OEM-Lizenzen nicht an Hardware gebunden sind. Und zu erwähnen das es ein BGH-Urteil zu einem Thema gibt (auch wenn man die Fallnummer nicht angibt), halte ich für alles andere als wertlos wenn der Inhalt sinngemäß wiedergegeben wird. Wer alles in Beamtendeutsch nachlesen will kann schließlich selbst google bemühen. Und danke für die Links :) ich habe mir gerade die EULA zur OEM-Version von windows 7 professional durchgelesen, darin findet sich kein Generalausschluss und kein Hinweis darauf, das ich ein bestimmtes Medium für die Installation zu verwenden habe. Alle Inhalte die in diese Richtung schlagen, betreffen ausschließlich die erworbene Lizenz (Punkte: Überlizenzsierung, Übetragung etc.). Kannst ja gern mal rüberschauen, wenn du dort etwas in der Art findest, kannst du den Abschnitt ja mal posten.

Hallo Dr. Melzer, ich hab das Urteil des BGH mal fix gegoogled (BGH Urteil vom 06.07.2000 I ZR 244/97 OEM-Version). Das Urteil bezieht sich auf den Verkauf von OEM-Lizenzen, womit quasi die Bindung an Hardware als nichtig erklärt wurde. Worauf ich hinaus will ist, das ich quasi die Möglichkeit sehe, die OEM-Lizenz auch mit einer Installation von einer Retail-CD (die nicht mit einer Lizenz erworben wurde) zu betreiben. Denn unter dem Strich steht die OEM-Lizenz für mich genauso da wie die Retail, nur ohne Support, denn die Schlüssel die auf den Retailaufklebern sind quasi zu den Schlüsseln der OEM-Lizenz identisch. Und Microsoft lässt schließlich auch die Aktivierung zu (Installation vom Retail-Medium mit OEM-Schlüssel). Davon mal ganz abgesehen, sind die zu erwerbenden OEM-Lizenzen, mit einem Medium ausgestattet das vom Inhalt her absolut identisch mit dem der Retail-DVD ist. Würde Microsoft für OEM-Software andere Schlüssel verwenden damit sich Retailmedien mit diesen Schlüsseln nicht installieren lässt (ähnlich ist es ja auch mit Retail-Schlüsseln und Installtionsmedien die für Volumenlizenzen gedacht sind), dann könnte ich das ganze nachvollziehen. Steht denn in den EULAs explizit drin, dass man für die Installation kein Retailmedium verwenden darf? Gibt's eine kurz gehalten Auflistung von Facts in denen die Unterschiede der EULAs zu finden sind? Sowas würde mich brennenend interessieren :) Gruß g1n

Hallo TiTux, ja der DC vor Ort ist als DHCP und DNS-Server aktiv, die User-Anmeldung erfolgt auch am lokalen DC...meistens jedenfalls. Es kommt auch ab und zu vor, dass der clientrechner seine Anmeldung und ebenfalls die User-Anmeldung am Standort gegenüber vornimmt, auch wenn der lokale DC problemlos erreichbar ist :( Ich muss mal schauen ob ich die Firewallrules vorübergehend außer Kraft setzen kann, bei den Linux-Kisten find ich das manchmal etwas tricky ;) Gruß g1n

Sorry fürs "kapern"! Um meinen Beitrag nochmal zu komplettieren: Wenn ich einen Rechner erwerbe der eine OEM-Lizenz (Windows 7 Professional 32-bit) beinhaltet (mit Lizenzaufkleber inkl. Lizenzschlüssel) und überlicherweise über eine Vorinstallation verfügt die "zugemüllt" ist, erhält man im Normalfall nur eine Recovery-CD/DVD dazu, die bei Verwendung quasi das ganze "zugemüllte" wieder installiert, müsste mir doch die Möglichkeit gegeben sein, einen Datenträger aus dem Handel zu verwenden um eine saubere Neuinstallation zu bewerkstelligen. Schließlich läßt sich solch eine Neuinstalltion mit dem Lizenzschlüssel der unter dem Rechner klebt, aktivieren. Aus diesem Grund sehe ich dort keine Probleme, schließlich wurde die Lizenz korrekt erworben. Nach einem Gerichtsurteil aus dem Jahre 200x, wurde bestätigt, das die OEM-Nutzungsbedingungen seiten MS in Deutschland keine Wirkung zeigen, mit Bezug auf den Teil in dem MS die Nutzung der OEM-Lizenz auf einem anderen Rechner untersagt, und damit auch den Weiterverkauf von OEM-Lizenzen ohne HardwareBundle unterbinden wollte. Demzufolge sind OEM-Lizenzen als komplett eigenständige Lizenzen zu werten die auch weiterverkauft werden dürfen. Sind die Harwarebündelung und der fehlende Support seitens MS, nicht die einzigsten Unterschiede zur normal erhältlichen Retail-Version, oder gibt es dort noch mehr Regeln? Meines Wissens nach nicht, daraus schlußfolgere ich, dass sich eine Installation mittels Retailmedium (ohne dafür eine weitere Lizenz erworben zu haben) mit einer OEM-Lizenz betreiben lassen, schließlich hat man eine Lizenz die sich auch aktivieren lässt. p.s. ich bin natürlich jeder Zeit offen für neue Informationen :)

Hallo Leute, ich habe seit einiger Zeit ein "kleines Problemchen". Hier mal kurz und knapp die Netzwerkkonstellation: -1 Domäne mit 2 Standorten, jeder Standort hat sein eigenes Subnetz, verbunden über einen openVPN-Tunnel - Standort 1 beherbergt 2 DCs mit Windows 2003 R2, auf diesen DCs laufen DFS-Shares die mit dem Standort Hannover synchronisiert werden - Standort 2 beherbergt 1 DC mit Windows 2003 R2 dort laufen die DFS-Shares die mit den Shares an Standort 1 per DFSR replliziert / synchronisiert werden. -Die DFS-Shares / Clients sind so eingestellt, dass standortübergreifende Zugriffe nicht möglich sein sollte (die Clients sollten nur die Sharepoints an ihrem eigenen zur Verfügung gestellt bekommen) - an beiden Standorten hängen Firewalls die den Traffic zwischen iNet / Netzwerk reglementieren, aber den Zugriff über das VPN ist komplett uneingeschränkt (keinerlei Sperren, alles wird durchgelassen). Bis die Firewalls ins System kamen funktionierte alles wunderbar (DFS-Replikation, Bereitstellung der standortbezogenen Shares), die VPN-Verbindung wurde ganz normal mit den Routern an den jeweiligen hergestellt ohne Firewall dazwischen. Seit dem die Firewalls stehen, erkennen die Clientrechner an Standort 2 ihren Standort nicht mehr korrekt. Die Clients geben vor sich an Standort 1 zu befinden und bekommen natürlich nur die Dort vorhandenen Server zur Verfügung gestellt...was natürlich so nicht richtig ist. Die Replikation unter den Server funktioniert hingegen einwandfrei. Ich habe schon diverse Test durchs VPN laufen lassen die mir attestierten dass keinerlei Einschränkungen bei Ports existieren. So langsam bin ich mit meinem Latein am Ende. Weiß jemand anhand welcher Daten ein Client erkennt an welchem Standort er sich befindet? ich bin immer davon ausgegangen dass das anhand der IP-Adresse geschieht, da bin ich aber scheinbar auf dem Holzweg. Ich hoffe meine Angaben sind halbswegs hilfreich ;) Beste Grüße g1n