Implementieren von Volume Activation 2.0 für Windows Vista und Windows Server 2008

Ausgangslage

Volumenlizenzkunden von Microsoft müssen nun eine Produktaktivierung durchführen. Microsoft beabsichtigte, diesen Kunden ein Tool zur Verfügung zu stellen, mit dem sie diese Aufgabe einfach und automatisch ausführen können.

Lösung

Zusammen mit einem Produktentwicklungsteam hat Microsoft IT die Volumenaktivierungstools getestet und weiterentwickelt. Das Ergebnis dieser Arbeit ist Volume Activation 2.0.

Vorteile

  • Automatische Volumenaktivierungen.
  • Niedrige zusätzliche Auslastung und Ressourcenverwendung
  • Ein Aktivierungsmodell für fast alle Aktivierungsanforderungen

Produkte und Technologien

  • Volume Activation 2.0
  • Windows Vista
  • Windows Server 2008
  • Windows Server 2003
  • Microsoft Operations Manager 2005
  • DNS-Serverdienst

Veröffentlicht: Mai 2008

Volume Activation 2.0 (VA 2.0) dient der Automatisierung und Verwaltung des Aktivierungsvorgangs für Volumenlizenzeditionen der Betriebssysteme Windows Vista® und Windows Server® 2008. Mit Volume Activation 2.0 stellt Microsoft ein Modell für Aktivierungen in den meisten Netzwerkumgebungen bereit.

Als Produktaktivierung wird der Vorgang der Überprüfung von Software beim Hersteller bezeichnet. Früher war eine Produktaktivierung für Windows® nur für Microsoft-Software erforderlich , die im Einzelhandel und bei Originalgeräteherstellern (OEMs) erworben wurde. Über Microsoft-Volumenlizenzprogramme erworbene Softwarelizenzen mussten nicht aktiviert werden. Allerdings ließ sich die Nutzung von Product Keys für Volumenlizenzen aufgrund ihrer Struktur und der Art der Verwendung nur schwer kontrollieren. Dadurch wurden Product Keys für Volumenlizenzeditionen von Windows XP und Windows Server 2003 zur Hauptquelle für raubkopierte Software. Tatsächlich sind über 80 Prozent der Windows XP-Piraterie darauf zurückzuführen , dass für Volumenlizenzkunden ausgegebene Product Keys offen gelegt wurden.

Viele Kunden , die eine nicht lizenzierte Kopie von Microsoft-Software erwerben , werden unwissentlich Opfer eines Verbrechens , denn sie verwenden häufig unbewusst Product Keys , die berechtigten Volumenlizenzkunden entwendet wurden. Obwohl die finanziellen Auswir-kun--gen nicht lizenzierter Software für Softwarehersteller und -anbieter schwerwiegend sind , gibt es auch Folgen , die über finanzielle Schäden dieser Organisationen hinausgehen. Nicht lizenzierte Software wird in zunehmendem Maße als Mittel für die Verbreitung von Viren und Malware eingesetzt , die ahnungslose Benutzer der Gefahr der Beschädigung oder des Verlusts von persönlichen oder geschäftlichen Daten und des Identitätsdiebstahls aussetzen.

Kunden müssen nun in Übereinstimmung mit der Aktivierungsrichtlinie von Microsoft alle Editionen der Betriebssysteme Windows Vista und Windows Server 2008 aktivieren , um dieser Gefahr entgegenzuwirken. Dies gilt auch für im Rahmen eines Volumenlizenz-programms erworbene Editionen. Diese Anforderung gilt für die Ausführung von Windows auf physikalischen und auf virtuellen Computern. VA 2.0 besteht aus einer neuen Gruppe von Tools , die Kunden bei der Automatisierung des Aktivierungsvorgangs auf Computern unterstützen , auf denen Volumeneditionen von Windows Vista und Windows Server 2008 ausgeführt werden. Die Volumenaktivierung ist als Aktivierungsoption nur dann verfügbar , wenn die Software über ein Microsoft-Volumenlizenzprogramm lizenziert ist. Kunden , die Windows Vista- und Windows Server 2008-Produkte im Einzelhandel oder bei einem Originalgerätehersteller (OEM) erwerben , führen die Aktivierung mithilfe anderer Methoden aus.

In dieser Fallstudie wird beschrieben , wie VA 2.0 von Microsoft Information Technology (Microsoft IT) seit den ersten Editionen von Windows Vista bis zur Markteinführung von Windows Server 2008 implementiert wurde , und Sie erfahren , welche Schlüsse aus der Implementierung gezogen wurden. Es werden die Probleme , die aufgetreten sind , und bewährte Methoden erläutert , die die geringsten Verwaltungskosten verursachen. Dieses Dokument wurde für Leiter der PR-Abteilung , IT-Leiter , Lösungsarchitekten und Entscheidungs-träger für technische Angelegenheiten verfasst , die erfahren möchten , wie VA 2.0 von Microsoft in das eigene Netzwerk integriert wurde.

Auf dieser Seite

Ausgangslage
Lösung
Bewährte Methoden
Zusammenfassung
Weitere Informationen

Ausgangslage

Zu den Benutzern , die von Microsoft IT unterstützt werden , gehören zahlreiche Anwender , die bereits in frühen Phasen neue Betriebssysteme einsetzen. Dadurch hatte Microsoft IT die Möglichkeit , Volumenaktivierungstools zu testen , als Windows Vista in der Betaversion vorlag und der Entwicklungszyklus der Volumenaktivierungstools noch nicht abgeschlossen war. Ziel von Microsoft IT bei der Implementierung der Volumenaktivierung war , in Zusammen-arbeit mit dem Produktentwicklungsteam für VA 2.0 eine groß angelegte Implementierung zu testen und die Aktivierungslösung für die Kunden zu verfeinern und zu verbessern.

Implementierungsziele

Zusammen mit dem Produktentwicklungsteam hat Microsoft IT während der Implementierung der Volumenaktivierung an der Erreichung der folgenden Ziele gearbeitet:

  • Für die Benutzer transparente Aktivierung der Betriebssysteme Windows Vista und Windows Server 2008

  • Überarbeiten der Konfiguration von VA 2.0 bei Bedarf zum Verringern von Verwaltungskosten und Gesamtbetriebskosten

  • Erhöhen des Nutzens des Microsoft Windows Key Management Service (KMS) Management Pack für Microsoft Operations Manager 2005

  • Belastungstest der KMS-Hostserver

  • Ermitteln der besten Methoden zum Steuern des automatischen Verhaltens von KMS-Clients

  • Erfassen der Auswirkungen von Aktivierungen auf den Netzwerkverkehr

  • Ermitteln der optimalen Anzahl von KMS-Hostservern

Aktivierungsmethode

VA 2.0 stellt zwei verschiedene Modelle für die Implementierung von Volumenaktivierungen zur Verfügung: Schlüsselverwaltungsdienst (Key Management Service , KMS) und Mehrfachaktivierungsschlüssel (Multiple Activation Key , MAK). Mit KMS werden Betriebssys-teme im lokalen Netzwerk aktiviert , sodass einzelne Computer zu Aktivierungszwecken niemals eine Verbindung mit Microsoft herstellen müssen. Zu diesem Zweck wird ein Client/Server-Modell verwendet. KMS-Clients stellen eine Verbindung mit einem KMS-Server her , der als KMS-Host bezeichnet wird , um die Aktivierung anzufordern oder eine aktuelle Aktivierung zu erneuern. MAK wird für eine einmalige Aktivierung mit den gehosteten Aktivierungsdiensten von Microsoft verwendet. MAK erfordert entweder eine direkte Aktivierung bei Microsoft oder ermöglicht einem Computer eine zentralisierte Aktivierungs-anforderung im Namen mehrerer Computer unter Verwendung einer Verbindung mit Microsoft.

Microsoft IT hat sich aus zwei Gründen für KMS als primäres Aktivierungsmodell entschieden: Erstens wurde KMS als Aktivierungsmethode für Computer im Kernnetzwerk einer Organisation erstellt. Microsoft IT beabsichtigte die Aktivierung von Computern , auf denen Windows Vista bereits in einer frühen Phase ausgeführt wurde und die alle mit dem Kernnetzwerk der Organisation verbunden waren. Zweitens wurde diese Implementierung von Microsoft IT entworfen , um dem Produktteam für VA 2.0 reale Vorgaben in Bezug auf eine groß angelegte Bereitstellung mit KMS an die Hand zu geben. Microsoft IT konnte eng mit dem Produktentwicklungsteam zusammenarbeiten , um Probleme zu ermitteln sowie den KMS-Aktivierungsvorgang zu vereinfachen und zu verbessern. Microsoft IT konnte MAK als Ausweichaktivierungsmethode für Systeme verwenden , auf denen bei der KMS-Aktivierung Fehler aufgetreten waren.

Lösung

Microsoft IT implementierte VA 2.0 vor der Übergabe an Betriebsteams in fünf Phasen. Im Mittelpunkt der Implementierung stand die Verwendung und Verbesserung der automatischen Features von VA 2.0.

Phase 1: Labortests

In Phase 1 der VA 2.0-Implementierung wurden nur die Installation von KMS-Hosts und die grundlegende Funktionalität des KMS-Diensts getestet. Diese Phase wurde in einer Labor-umgebung in einer vom Rest des Produktionsnetzwerks getrennten Struktur ausgeführt. Microsoft IT beabsichtigte in Phase 1 die Installation von zwei KMS-Hosts , nämlich auf einem eigenständigen Computer und auf einem Domänencontroller. Danach überwachte Microsoft IT die Aktivierung von ca. 100 KMS-Clients , die sich auch in der Testlaborumge-bung befanden. Phase 1 lief drei Wochen. In dieser Zeit wurden alle Clients mit KMS aktiviert; MAK-Aktivierungen waren nicht erforderlich.

Anforderungen an die DNS-Konfiguration

Standardmäßig fragt ein KMS-Client den Namen eines KMS-Hosts von DNS (Domain Name System) ab. Dieser Name befindet sich in einem Diensteintrag (SRV) , durch den der KMS-Dienst veröffentlicht wird. Für die KMS-Version für Phase 1 musste Microsoft IT manuell einen SRV-Eintrag auf dem DNS-Server erstellen. Nach der Erstellung des Eintrags konnten die KMS-Clients die KMS-Hosts finden und die Aktivierung durchführen , ohne dass weitere Administratoraktionen ausgeführt werden mussten.

Aktivierungsschwellenwerte

Beim Testen einer kleinen Anzahl von KMS-Clients erkannte Microsoft IT , dass auch zu viele KMS-Hosts vorhanden sein können. Dies liegt an den KMS-Aktivierungsschwellenwerten. KMS wurde für mittlere und große Netzwerkumgebungen konzipiert. Aus diesem Grund erfordert KMS eine als Aktivierungsschwellenwert bezeichnete Mindestanzahl von physika-lischen Computern in einer Netzwerkumgebung. Eine Organisation muss über mindestens fünf physikalische Computer verfügen , um Windows Server 2008 aktivieren zu können , und über mindestens 25 physikalische Computer , um Clients mit Windows Vista mithilfe von KMS aktivieren zu können. Ein KMS-Host zählt die Anzahl von physikalischen Computern , die im Netzwerk ihre Aktivierung anfordern , und die KMS-Clients werden erst aktiviert , wenn dieser Schwellenwert erreicht ist.

Jeder KMS-Host speichert seinen eigenen Aktivierungsschwellenwert. Wenn in einem Netzwerk nicht die erforderliche Anzahl von physikalischen Computern vorhanden ist , beenden einzelne KMS-Hosts ggf. die Aktivierung von Clients , weil der Aktivierungs-schwellen-wert nicht erreicht ist. Microsoft IT hat herausgefunden , dass in Netzwerken mit weniger als 100 KMS-Clients dieses Problem dadurch umgangen werden kann , dass nur ein KMS-Host vorhanden ist.

Leistung

Anfangs deuteten Leistungsmetriken darauf hin , dass die Aktivierungen die Prozessoren auf den KMS-Hosts belasteten. Die CPU-Auslastung lag gleichmäßig bei einem Spitzenwert von 100 Prozent , obwohl nur wenige KMS-Clients vorhanden waren. Eine Untersuchung ergab , dass die KMS-Clients ihre Aktivierungen zu oft erneuerten. Das Intervall für die Aktivierungs-erneuerung wurde daraufhin von einmal pro Minute in einmal alle sieben Tage geändert. In den nachfolgenden Phasen der Bereitstellung erkannte Microsoft IT , dass die Herabsetzung des Intervalls eine einfache Methode darstellte , KMS-Hosts einem Belastungstest zu unterziehen.

Netzwerkverkehr

Netzwerkverkehrtests haben ergeben , dass der KMS-Dienst nur eine minimal höhere Auslastung nach sich zieht. Bei einem vollständigen KMS-Aktivierungsaustausch werden in jede Richtung weniger als 250 Bytes gesendet , zuzüglich TCP-Sitzungseinrichtung und -beendigung. Zusätzlicher Netzwerkverkehr entsteht , wenn ein KMS-Client einen KMS-Host von DNS abfragt , aber dies geschieht in der Regel nur einmal pro KMS-Client. Wenn ein KMS-Client einen KMS-Host gefunden hat , sendet er alle zukünftigen Anforderungen für eine Aktivierungserneuerung an denselben KMS-Host. Ein KMS-Client sucht nur dann nach einem neuen KMS-Host , wenn der aktuelle KMS-Host nicht antwortet. Zwischen KMS-Hosts tritt kein Netzwerkverkehr auf. Jeder KMS-Host verwaltet seine eigene Liste mit KMS-Clients , und es gibt keine Replikation oder Freigabe von Informationen zwischen KMS-Hosts.

Phase 2: Pilotbereitstellung

Geplant für Phase 2 war eine eingeschränkte Bereitstellung von KMS-Clients aus dem Produktionsnetzwerk mit einem Setup , das nur minimale Auswirkungen auf das Netzwerk haben würde. Microsoft IT wählte zu diesem Zweck aus dem Produktionsnetzwerk eine beschränkte Anzahl von KMS-Clients aus. Um mögliche Auswirkungen der Hinzufügung des KMS-Diensts im Netzwerk zu verringern , wurden die KMS-Hosts für Phase 2 in einer Struktur installiert , die nur zum Testen von Bereitstellungen verwendet wird und nicht Teil des Produktionsnetzwerks ist.

Zu den für VA 2.0 verwendeten Betriebssystemen zählten Vor-Beta-Versionen von Windows Vista und Windows Server 2008. Zu den für Phase 2 ausgewählten Clientcomputern gehörten Mitglieder einer Bereitstellungstestdomäne sowie Mitglieder einer kleinen mit dem Kernnetzwerk verbundenen Domäne. Microsoft IT wählte zudem aus der Hauptdomäne im Kernnetzwerk eine beschränkte Anzahl von Clients aus. Für die Computer , die zur Haupt-domäne gehörten , wählte Microsoft IT Gruppen von Benutzern aus , die sich in räumlicher Nähe zueinander befanden. Auf diese Weise sollten die Auswirkungen auf den Netzwerk-verkehr im physikalischen Subnetz getestet werden. Microsoft IT forderte diese Benutzer auf , ihre Systeme auf eine nicht veröffentlichte , volumenlizenzierte Version von Windows Vista oder Windows Server 2008 zu aktualisieren. Damit belief sich für diese drei Umgebungen die Gesamtanzahl der Systeme , die in Phase 2 für die Aktivierung ausgewählt waren , auf ca. 3.000.

DNS-Serverkonfiguration

Da die DNS-Server Unterstützung für dynamisches DNS boten , forderte Microsoft IT eine Änderung in KMS an , der zugestimmt wurde. Die Änderung bestand darin , dass ein KMS-Host die für KMS erforderlichen DNS-Einträge erstellen und aktualisieren würde , sodass diese Einträge nicht von Administratoren manuell erstellt werden mussten. Mit dieser Änderung erstellt der KMS-Host den DNS-SRV-Eintrag automatisch , wenn der KMS-Dienst aktiviert wird. Bei jedem Start des Diensts und einmal täglich ersetzt KMS den SRV-Eintrag. Der neue Eintrag gibt alle Änderungen wieder.

Für Phase 2 und nachfolgende Phasen sah Microsoft IT KMS-Clients aus mehreren DNS-Domänen vor , die KMS-Hosts hingegen sollten einer einzelnen DNS-Domäne angehören. Standardmäßig veröffentlichen KMS-Hosts automatisch den KMS-Dienst durch Erstellen eines SRV-Eintrags in der eigenen DNS-Standarddomäne. Außerdem führen KMS-Clients nur in der zugehörigen DNS-Standarddomäne eine Abfrage nach dem Standort eines KMS-Hosts aus. Damit keine DNS-Einträge manuell erstellt werden müssen , forderte Microsoft IT einen neuen Registrierungsschlüssel für KMS-Hosts an und bekam diesen auch gewährt. Mit dem Registrierungsschlüssel DNSDomainPublishList können Administratoren alle DNS-Domänen auflisten , denen der KMS-Host einen SRV-Eintrag für den KMS-Dienst hinzufügen soll. Auf diese Weise konnte Microsoft IT Zeit sparen , weil keine SRV-Einträge für den KMS-Host in mehreren DNS-Domänen erstellt und verwaltet werden mussten.

Während Phase 2 ließ der DNS-Server in der Laborumgebung zu , dass der KMS-Host die Veröffentlichung selbst durchführte , in Produktionsumgebungen hingegen wird die Erstellung und Aktualisierung von DNS-Einträgen kontrolliert , wie das auch in vielen Organisationen der Fall ist. Damit der KMS-Host den KMS-Dienst veröffentlichen kann , benötigt er die Rechte zum Erstellen und Aktualisieren von SRV- , A- und AAAA-Ressourceneinträgen in allen DNS-Domänen , in denen KMS-Clients vorhanden sind. Microsoft IT wies die erforderlichen Anmeldeinformationen für den DNS-Server den KMS-Hosts zu. Dazu wurde eine Sicherheits-gruppe in den Active Directory®-Domänendiensten (Active Directory Domain Services , AD DS) erstellt , der alle KMS-Hosts hinzugefügt wurden. Microsoft IT erteilte dieser Sicherheitsgruppe Vollzugriffsberechtigungen für den Eintrag _VLMCS._TCP für jede DNS-Domäne mit KMS-Clients.

Phase 3: Installieren von KMS-Hosts im Kernnetzwerk

Hauptziel der Phase 3 war die Installation von KMS-Hosts im Kernnetzwerk. Die in Phase 2 verwendeten KMS-Hosts wurden in Phase 3 nicht verwendet. Stattdessen wurden zwei KMS-Hosts in der Gesamtstruktur-Stammdomäne des Kernnetzwerks installiert. Ein KMS-Host wurde auf einem Produktionsdomänencontroller und ein weiterer auf einem eigen-ständigen Server installiert. Da auf den KMS-Hosts keine Informationen freigegeben werden , startete der Aktivierungsvorgang für alle KMS-Clients erneut , als die neuen KMS-Hosts online geschaltet wurden. In Zahlen heißt das für Phase 3: 3.000 KMS-Clients aus Phase 2 sowie weitere 4.000 Clients , insgesamt also 7.000 KMS-Clients.

Eines der Ziele von Microsoft IT bestand darin , die Auswirkungen der Hinzufügung des KMS-Diensts zu einem Domänencontroller zu ermitteln. Zu diesem Zweck wurden die Metriken von dem Domänencontroller , der als KMS-Host fungierte , und von anderen Domänen-controllern in derselben Domäne erfasst. Beim Vergleich der Metriken des auf einem Domänencontroller installierten KMS-Hosts mit den Metriken der anderen Domänencontroller in derselben Domäne konnte kein messbarer Leistungsabfall auf dem Domänencontroller festgestellt werden , der auch als KMS-Host fungierte. Microsoft IT folgerte daraus , dass das Hinzufügen des KMS-Diensts zu einem Domänencontroller nicht zu Leistungseinbußen führt.

Phase 4: Windows Vista Beta 2-Bereitstellung

Da keine messbare Belastung der Server oder im Kernnetzwerkverkehr auftrat , sollte in Phase 4 die Anzahl von KMS-Clients deutlich erhöht werden. Zeitlich fiel Phase 4 mit der Veröffentlichung von Windows Vista Beta 2 und der umfassenden Einführung des Betriebssystems Windows Vista im Kernnetzwerk zusammen. Die Benutzer aktualisierten weitere 23.000 Systeme auf eine volumenlizenzierte Version von Windows Vista oder Windows Server 2008 , sodass für Phase 4 rund 30.000 KMS-Clients zur Verfügung standen. Bei einigen dieser KMS-Clients handelte es sich um Laptops , die die Verbindung über ein internes Drahtlosnetzwerk herstellten. Es wurden keine Leistungsprobleme auf diesen Clients gemeldet.

Für die erhöhte Anzahl von KMS-Clients installierte Microsoft IT zwei weitere KMS-Hosts auf Domänencontrollern in der Gesamtstruktur-Stammdomäne des Kernnetzwerks , d. h. , die Anzahl der KMS-Hosts wurde auf vier erhöht. Einer dieser KMS-Hosts war ein Server mit Windows Server 2003. Dieser Server unterstützte 25 Prozent der KMS-Clients , ohne dass Probleme auftraten. Zudem war einer dieser KMS-Hosts nur für KMS-Clients mit IP-Version 6 (IPv6) zuständig und bot keine Unterstützung für IP-Version 4 (IPv4). Microsoft IT konnte keinen Unterschied bezüglich des Betriebs und der Leistung dieses KMS-Hosts feststellen , und es gab auch keine Probleme bei der Aktivierung von KMS-Clients mit IPv6.

Hinweis:KMS ist automatisch im Lieferumfang von Windows Server 2008 und Windows Vista enthalten , nicht jedoch im Lieferumfang von Windows Server 2003. Organisationen , die KMS unter Windows Server 2003 hosten möchten , müssen KMS für Windows Server 2003 herunterladen und installieren. Dieses Produkt steht unter http://go.microsoft.com/fwlink/?LinkID=82964 in mehreren Sprachen zum Download zur Verfügung. Die 64-Bit-Version ist unter http://go.microsoft.com/fwlink/?LinkId=83041 verfügbar.

Phase 5: Windows Vista RC-Bereitstellung

Zeitlich fiel Phase 5 mit der Veröffentlichung von Windows Vista Release Candidate (RC) zusammen. Es wurden weitere 60.000 KMS-Clients hinzugefügt , sodass die Gesamtzahl rund 90.000 betrug. Microsoft IT fügte der Gesamtstruktur-Stammdomäne des Kernnetz-werks einen weiteren KMS-Host zu und erhöhte somit die Anzahl von KMS-Hosts auf vier Domänencontroller und einen eigenständigen Server.

Obwohl sich alle KMS-Hosts in der Gesamtstruktur-Stammdomäne des Kernnetzwerks befanden , wiesen einige der in Phase 5 hinzugefügten Clients Computerkonten in einer anderen Struktur auf , die keine Vertrauensstellung mit der Struktur des Kernnetzwerks aufwies. Zu Beginn traten bei der Aktivierung dieser Clients Fehler auf. Eine Untersuchung ergab , dass diesem Problem IP-Sicherheitseinstellungen (IPSec) zugrunde lagen. Die Aktivierungen konnten erfolgreich ausgeführt werden , nachdem Microsoft IT IPSec die Berechtigung erteilte , Verbindungen von diesen Domänen mit den KMS-Hosts zuzulassen.

Während Phase 5 wurde eine weitere separate , kleine Bereitstellung ausgeführt. Einige KMS-Clients befanden sich an einem Remotestandort , der über ein virtuelles privates Netzwerk (VPN) mit dem Kernnetzwerk verbunden war. Diesen Clients wurde ein separater KMS-Host zugeteilt. Die Auswertung der erfassten Leistungsmetriken ergab , dass KMS keinen KMS-Host benötigt , um eine Verbindung mit KMS-Clients über eine Verbindung mit hoher Bandbreite herzustellen. Die Latenz betrug nur wenige Sekunden , wohingegen es bei der Erfüllung der Aktivierungsanforderungen um Wochen geht. Selbst wenn bei einer Verbindung mit einem KMS-Host eine Zeitüber-schreitung auftrat und zu einem späteren Zeitpunkt der Vorgang wiederholt wurde , nahm der Benutzer dies nicht wahr.

Aktuelle Konfiguration

Nach Abschluss von Phase 5 ging VA 2.0 von Bereitstellung und Tests in Betrieb und Wartung über. VA 2.0 wird nach wie vor für alle volumenlizenzierten Editionen von Windows Vista und Windows Server 2008 verwendet. Die Konfiguration mancher Server , die VA 2.0 im Kernnetzwerk unterstützen , wurde jedoch geändert.

DNS-Serverkonfiguration

Bei der ursprünglichen Implementierung von VA 2.0 verwendete Microsoft IT den DNS-Serverdienst unter Windows Server 2003. Später aktualisierte Microsoft IT diese Server auf die aktuelle Konfiguration des DNS-Serverdiensts unter Windows Server 2008. Beide Versionen von DNS-Servern unterstützen SRV-Einträge entsprechend RFC 2782 (Request for Comments) und dynamische Aktualisierungen entsprechend RFC 2136. Alle DNS-Server , die diese RFCs und die BIND-Versionen 8. x und 9. x ( Berkeley Internet Domain Name) unterstützen , können dem KMS-Host die automatische Veröffentlichung der KMS-Diensteinträge erlauben.

Aktuelle KMS-Hostkonfiguration

Eines der Hauptziele von Microsoft IT bestand darin , KMS-Hosts Belastungstests zu unterziehen , um zu ermitteln , wie viele KMS-Clients ein KMS-Host unterstützen kann und ob KMS-Hosts zusammen mit anderen Diensten gehostet werden können. Ein KMS-Host kann auf einem Computer mit Windows Server 2008 , Windows Server 2003 oder gar Windows Vista ausgeführt werden. Ein KMS-Host , der unter Windows Vista ausgeführt wird , kann jedoch nur Windows Vista-basierte Systeme aktivieren. Bei einem KMS-Host kann es sich um einen physikalischen Computer oder ein virtuelles System handeln.

Microsoft IT testet auch weiterhin neue Konfigurationen für KMS-Hosts. Derzeit unterstützen zwei KMS-Hosts alle KMS-Clients im Netzwerk. Diese Server sind keine Domänencontroller , sondern Lizenzserver. Sie unterstützen nicht nur KMS-Clients , sondern auch Lizenzen für Terminaldienste. In Tabelle 1 werden die Spezifikationen dieser Server aufgeführt.

Tabelle 1: Hardwarespezifikationen für KMS-Hosts

Komponente

Microsoft IT-Konfiguration

Prozessor

2 AMD64-Prozessoren mit jeweils 2.205 MHz (MHz)

Speicher

2.046 Megabytes (MB)

Netzwerk

1-Gigabyte-Ethernet

Festplatte

eine physikalische Festplatte mit 70 GB

KMS ist rechenzeitintensiv. Kurzzeitig kann die CPU-Auslastung auf einem Computer mit einem Prozessor bis zu 100 Prozent erreichen , wenn mehrere Aktivierungsanforderungen verarbeitet werden. Allerdings werden Aktivierungsanforderungen für KMS-Clients oftmals gestaffelt ausgeführt. Bei dem Versuch der Selbstaktivierung während des anfänglichen Aktivierungszeitraums führt ein KMS-Client standardmäßig alle zwei Stunden eine Aktivierungsanforderung und eine Erneuerungsanforderung einmal alle sieben Tage nach der Aktivierung aus.

Bewährte Methoden

Microsoft IT ist zu dem Ergebnis gekommen , dass das KMS-Aktivierungsmodell in den meisten Netzwerkumgebungen mit zu vernachlässigenden Auswirkungen auf das Netzwerk und den Computer funktioniert hat , der als Host für den KMS-Dienst fungiert. Eine MAK-Aktivierung war nur für nicht verbundene Netzwerke erforderlich , z. B. Hochsicherheits-netzwerke , die nicht die Anzahl von physikalischen Computern aufwiesen , die laut KMS-Aktivierungsschwellenwerten erforderlich sind. Die folgenden bewährten Methoden wurden von Microsoft IT im Rahmen der Fallstudie ermittelt:

  • KMS ist für die meisten Netzwerkumgebungen geeignet. Wann immer geeignet, sollte eine Organisation KMS verwenden.

  • In Netzwerkumgebungen mit aktuellen DNS-Servern müssen für KMS-Aktivierungen nur wenige Setupschritte ausgeführt werden.

  • Server, auf denen andere Funktionen ausgeführt werden, können mit vernachlässigbaren Auswirkungen auf die Serverleistung KMS-Hostingaufgaben übernehmen.

  • Kleine Netzwerkumgebungen sollten nur einen KMS-Host aufweisen.

  • Nach der Konfiguration benötigt der Schlüsselverwaltungsdienst (KMS) wenige Verwaltungsressourcen.

Überwachen der KMS-Clientaktivierung

Wenn KMS-Hosts zum ersten Mal online geschaltet werden , sollten Administratoren neben der Anzahl der Aktivierungen , die die einzelnen KMS-Hosts ausführen , den Erfolg der Clientaktivierungen überwachen. Ein KMS-Client zeichnet Aktivierungsanforderungen ,  
-erneuerungen und -antworten im lokalen Anwendungsprotokoll des KMS-Clients auf. Der KMS-Host protokolliert einen separaten Eintrag für jede Anforderung , die er von einem KMS-Client empfängt. Diese Einträge werden im Protokoll des Schlüsselverwaltungsdiensts im Ordner Anwendungs- und Dienstprotokolle gespeichert.

Ein Administrator hat die Möglichkeit , KMS-Ereignisprotokolle manuell zu archivieren und zu überprüfen. Und wenn die Organisation Microsoft Operations Manager 2005 verwendet , kann Microsoft Windows Key Management Service (KMS) Management Pack für MOM 2005 verwendet werden. In diesem Management Pack sind detaillierte Aktivierungsberichte für Computer mit Windows Vista und Windows Server 2008 enthalten. Der KMS-Aktivitäts-übersicht (KMS Activity Summary) kann die Anzahl neuer KMS-Aktivierungen entnommen werden , die für jeden KMS-Host bereitgestellt werden können.

Wenn die ersten Aktivierungen abgeschlossen sind , kann ein Administrator Warnungen im KMS Management Pack festlegen , über die Benachrichtigungen gesendet werden , wenn der Aktivierungszeitraum oder die aktuelle Aktivierung für einen Computer abläuft. Ein Administrator kann zudem der Übersicht über den Lizenzstatus (Licensing Status Summary) die Anzahl von Tagen entnehmen , die bis zu einer Erneuerung der Aktivierung von KMS-Clients verbleiben.

Lastenausgleich auf KMS-Hosts

Wenn in einer Netzwerkumgebung mit zwei KMS-Hosts beide KMS-Hosts gleichzeitig online geschaltet werden , weist der DNS-Server KMS-Clients abwechselnd beiden KMS-Hosts zu , sodass die KMS-Clients auf die KMS-Hosts aufgeteilt werden. Wenn jedoch ein KMS-Host später als der erste KMS-Host online geschaltet wird , übernimmt der neue KMS-Host keine KMS-Clients. Dies liegt an dem Standardverhalten der KMS-Clients.

Wenn ein KMS-Client erfolgreich aktiviert wurde , sendet er alle zukünftigen Anforderungen für eine Aktivierungserneuerung an den ursprünglichen KMS-Host , von dem er aktiviert wurde. Solange der ursprüngliche KMS-Host dem KMS-Client antwortet , sucht der Client nicht nach einem anderen KMS-Host. Für diesen Fall hat Microsoft IT zwei Möglichkeiten für den Lastenausgleich zwischen einem aktuellen KMS-Host und einem neuen KMS-Host gefunden. Zunächst kann ein Administrator den ursprünglichen KMS-Host neu starten und beide Hosts gleichzeitig online schalten. Dadurch wird der Aktivierungscache auf dem ursprünglichen Host gelöscht , und die Zählung für den Aktivierungsschwellenwert wird neu gestartet.

Wenn ein Neustart nicht in Frage kommt , kann auf dem ursprünglichen KMS-Host der Port gesperrt werden , der vom KMS-Dienst verwendet wird , also TCP-Port 1688. Erneuerungs-versuche von Clients bleiben dann unbeantwortet , sodass sie einen neuen KMS-Host von DNS abfragen. Der Administrator muss die Anzahl von Clients überwachen , die zu dem neuen KMS-Host gewechselt sind , um bestimmen zu können , wann die Sperrung des Ports aufgehoben werden kann. Die Anzahl von Tagen , an denen der Port gesperrt ist , muss geringer sein als die Anzahl der Tage des Erneuerungsintervalls der Clients. Wenn der Administrator den Port für das gesamte Clienterneuerungsintervall (standardmäßig sieben Tage) sperrt , wechseln alle KMS-Clients zu dem neuen KMS-Host.

Zusammenfassung

Die Produktaktivierung muss für alle Editionen von Windows Vista und Windows Server 2008 ausgeführt werden. Mit VA 2.0 können Volumenlizenzkunden den Aktivierungsvorgang automatisieren , sodass nur wenige oder gar keine Auswirkungen für Endbenutzer entstehen. Zwar bietet VA 2.0 Volumenlizenzkunden zwei Modelle zum Aktivieren von Windows Vista und Windows Server 2008 , die meisten Aktivierungsanforderungen erfüllt jedoch das KMS-Modell. Dank der niedrigen Ressourcenverwendung und niedrigen zusätzlichen Netzwerk-auslastung kann KMS in verschiedensten Netzwerkumgebungen verwendet werden.

Ziel der Implementierung der Volumenaktivierung durch Microsoft IT war nicht nur das Testen der Aktivierungen in großem Rahmen , sondern auch eine gesteigerte Zufriedenheit der Kunden mit dem Produkt. Dies hatte Verbesserungen an VA 2.0 zur Folge , die den Volumenaktivierungsvorgang vereinfachen und automatisieren.

Weitere Informationen

In dieser Fallstudie wird die Implementierung von VA 2.0 in einer großen Organisation dargestellt. Organisationen stehen für die Planung und Implementierung von VA 2.0 zahlreiche Ressourcen und Tools zur Verfügung. Weitere Informationen zu verwendeten Begriffen oder Verfahren zum Ausführen der in dieser Fallstudie erläuterten Aufgaben finden Sie in der folgenden Dokumentation:


Weitere Informationen zu Microsoft-Produkten oder -Diensten erhalten Sie in den Vereinigten Staaten im Microsoft Sales Information Center unter der Telefonnummer (800) 426-9400. Wenden Sie sich in Kanada an das Microsoft Canada Information Centre unter (800) 563-9048. Wenden Sie sich außerhalb der Vereinigten Staaten und Kanadas an eine Microsoft-Niederlassung vor Ort. Informationen im Internet finden Sie unter den folgenden Adressen:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

Herunterladen Implementieren von Volume Activation 2.0 für Windows Vista und Windows Server 2008

Anzeigen: