Wie ich bereits vor ein paar Tagen im Artikel Internet Explorer 8: So klappt’s mit dem Rollout! erwähnte, möchte ich euch heute das Excelsheet zur Prüfung der Version des Internet Explorers vorstellen. Dieses kann die Version des Internet Explorers remote prüfen und setzt lediglich Excel 2000/XP/2003/2007 auf einem administrativen Client voraus, da es auf VBA basiert.

Funktionsweise des Makros

Das Makro fragt im ersten Schritt die Erreichbarkeit eines Systems ab. Konnte das System kontaktiert werden, so wird die Version des Internet Explorers über WMI geprüft. Hierfür sind natürlich lokale Adminrechte notwendig, da sonst der Zugriff auf die Systeme nicht möglich ist.

  Check IE-Version 1.0 (1.1 MiB, 120 hits)

Links

blog – port 389: Check IE-Version 1.0

Sascha Giebelhausen

Group Policy + IEAK 8 = IE8 Rollout!

Es kommt leider erschreckend oft vor, dass wir in Kundenumgebungen, die unterschiedlichsten Browserversionen feststellen. Vom guten “alten” Internet Explorer 5 über die Version 6 und 7 ist eigentlich alles vertreten. Manchmal findet sich aber auch ein IE8 – in den meisten fällen ist dies dann aber ein Notebook, mit erhöhten Berechtigungen (lokaler Administrator – schlecht! ), welches ohne Angst auf Verluste sämtliche Softwarekomponenten, einschließlich Windows Updates (gut!) installiert.

Für all diejenigen, die es bisher nicht geschaft haben oder noch in der Testphase stecken, haben wir in diesem Artikel, einen Lösungsweg von vielen, einmal genauer Untersucht und beschrieben. Unserer Meinung nach ist dies ein Weg, den man durchaus so weiterempfehlen kann. Mit einer vernünftigen Testphase, sind so fast keine Überraschungen zu erwarten. In einer Kundenumgebung mit mehr als 300 Workstations traten hierbei keine nennenswerten Fehler auf. Zudem verlief die Umstellung für die Benutzer nahezu unsichtbar – wie von Geisterhand.  Im Fall des IE 8 kann mit dem so genannten IEAK 8 das Rollout hervoragend vorbereitet und durchgeführt werden.

Erstellung des MSI-Paketes mit dem IEAK 8

Mit dem IEAK 8 kann so gut wie jede Einstellung des Internet Explorers automatisch bei der Installation konfiguriert werden. Folgende Einstellungen müssen so nicht mehr händisch festgelegt werden:

• Erstellung eines MSI-Paketes, einer CD mit Autorun und eines Konfigurationspaketes
• Anpassung der Verbindungseinstellungen
• Hinzufügen wichtiger Links und Favoriten
• Übernahme oder Löschung der bisherigen Favoriten des Anwenders
• Anpassung der Such-Provider
• Sicherheitseinstellungen

Hierbei ist jedoch zu beachten, dass lt. Microsoft für folgende Betriebssysteme unterschiedliche Installationspakete erstellt werden müssen. Dies gilt auch für die eingesetzte Sprache des Betriebssystems.

• Windows XP mit SP2/SP3 (x86)
• Windows Server 2003 mit SP2 (x86)
• Windows Vista SP1 und Windows Server 2008 (x86)
• Windows XP mit SP2 und Windows Server 2003 mit SP2 (x64)
• Windows Vista SP1 und Windows Server 2008 (x64)

Um euch von den Vorteilen des IEAK 8 zu überzeugen, habe ich euch einmal die Erstellung einen MSI-Paketes für den Internet Explorer 8 mit Screenshots dokumentiert.

1.  Auswahl der Betriebssystemplattform

2.  Auswahl der Sprache

3.  Aussuchen der Bereitstellungsmethode

4.  Festlegen der Installationoptionen

5.  Anpassung der Benutzeroberfläche

6.  Eingrenzung der Suchanbieter

7.  Festlegung der Homepage

8.  Anpassung der Favoriten und Feeds

9.  Optionen zur Verwaltung vorhandener Objekte

10.  Einstellung der einmaligen “Willkommen Seite” nach der Installation

11.  Anpassung der Proxyeinstellungen

12.  Sicherheits- und Datenschutzeinstellungen

13.  Erstellung des MSI-Paketes

Einbindung einer Gruppenrichtlinien zur Installation des Internet Explorer 8

Für die automatische Installation empfiehlt sich der Gebrauch von Gruppenrichtlinien. Da diese in den Server-Betriebssystemen von Microsoft enthalten sind, muss hierfür nicht extra eine Lösung zur Softwareverteilung implementiert werden und die Kunden sparen dann auch noch Geld. Mit diesen GPO’s kann die Installation des vorab erstellten MSI-Paketes schnell und ohne großen Aufwand durchgeführt werden. Dafür muss nur eine neue Computerrichtline für die Softwareinstallation erstellt werden. Diese muss die Software dem jeweiligen System zuweisen.

Auswirkungen für die Anwender

Je nach Installations-Methode kann die Auswirkung für den Anwender verschwindend gering gehalten werden. Hierbei ist jedoch zu beachten, dass das System unbedingt nach der Installation des Internet Explorer 8 neugestartet werden sollte.

1. Anwendungsinstallation

2. Erste für den Anwender erkennbare Veränderung

3. Erste Ausführung des Internet Explorer 8

Tools zur Prüfung der Version des Internet Explorers

Sollte es innerhalb der vorgefundenen Umgebungen keine Inventarisierungs-Lösung geben, so gibt es auch die Möglichkeit, den Status via WMI zu überwachen. Dabei können jedoch nur eingeschaltete und domänenintegrierte Systeme geprüft werden. Ich werde euch in den kommenden Tagen wieder ein Excelsheet für Administratoren bereitstellen, mit welchem ihr den Status abfragen könnt.

Links

Microsoft: Internet Explorer 8 Deployment Guide

Microsoft: Internet Explorer Administration Kit 8

Microsoft: Gruppenrichtlinien für die Remoteinstallation

Sascha Giebelhausen

Ist es euch auch schon passiert, dass ihr den Auftrag erhalten habt, “im gesamten Clientnetz” irgendeine Einstellung zu prüfen oder ein Software zu installieren? Also mir passiert so was schon häufig und der zeitintensivste Teil dieser Aufgaben war es meist, erstmal rauszufinden, welche Systeme in selbigen Netz überhaupt erreichbar sind. Diese Liste könnte dann im zweiten Schritt für irgendwelche Programme weiter genutzt werden.

Damit ich jedoch keine so genannten Ping-Tools von Drittanbieten installieren musste, habe ich mir vorerst ein VB-Script geschrieben, welches die vom Betriebssystem bereit gestellten Funktionen nutzt. Leider musste ich nach kurzer Zeit feststellen, dass diese Methode nicht sehr benutzerfreundlich war. Damit bin ich dann auch schon beim Thema. Im Downloadbereich könnt ihr nun ein Ping-Tool auf der Basis eines Excel-Makros finden. Dieses kann die Verfügbarkeit von Systemen wie Clients, Server, Firewalls oder Switchen prüfen. Die Prüfung erfolgt auf der Basis des Hostnamens oder der IP-Adresse.

Das Tool ist selbserklärend und kann von jedem System mit Excel ausgeführt werden.

  Ping Check 1.1.xls (860.0 KiB, 179 hits)

Links

blog – port 389: check_state_remote_1.0.xls

Sascha Giebelhausen

Oder: Was ist mit dem Zeitdienst los?

Wie mein Kollege Florian Thiessenhusen vor ein paar Tagen absolut treffend in seinem Blog-Beitrag geschrieben hat, gehört NTP bzw. der Zeitdienst W32Time zu den wichtigsten Komponenten innerhalb einer Active Directory Infrastruktur. Nahezu alle Technologien greifen auf eine einheitliche Zeitbasis zurück – aber nicht jeder erkennt diese enorme Wichtigkeit! Immer wieder treffen wir auf die abstrusesten Selfmade-Lösungen. Dabei stellen Infrastrukturen die gar nicht konfiguriert sind oder Infrastrukturen mit mehr als 30 als autorisierend konfigurierte Zeitserver, sicherlich die Ausnahme dar…

…Es ist ehrlich gesagt keine große Herausforderung eine funktionierende und vorallem Best-Practice-konforme NTP-Struktur aufzubauen. Es gilt jedoch einige entscheidene Faktoren zwingend zu berücksichtigen.

Bei der Migration (Ablösung durch zusätzliche Domain Controller) einer bestehenden Windows 2003 auf eine Windows Server 2008 R2 Domäne, kann es jedoch manchmal ein bisschen länger dauern bzw. um es im “Consulting-deutsch” zu sagen “Warum geht die Schei… nicht?”. Hier muss zwangsläufig der autorisierende Zeitserver der Domäne (in den meisten Fällen der PDC-Emulator) nach dem verschieben der FSMO-Roles angepasst werden. Das geht in der Regel am schnellsten mit folgendem Befehl:

w32tm /config /update /manualpeerlist:pool.ntp.org /syncfromflags:MANUAL /reliable:YES

Pool.ntp.org ist hierbei ein Zeitserver-Pool im Internet mit vier Zeitservern und einer durchaus vernünftigen Verfügbarkeit. Mehr als ebenbürtig sind auch die Server der Physikalisch-Technische Bundesanstalt in Braunschweig (ptbtime1.ptb.de, ptbtime2.ptb.de, ptbtime3.ptb.de).

In mehr als der Hälfte alle Fälle (je nach Unternehmen: Kritische Infrastruktur?, Produktionsunternehmen? Finanz-, Geld- und Versicherungswesen?) empfiehlt es sich (siehe Bundesamt für Sicherheit in der Informationstechnologie, BSI) einen eigenen NTP-Server im lokalen Netz bereitzustellen – hier bieten sich Systeme mit DCF-77 oder GPS geradezu an.

Um nun seinen restlichen Domain Controllern den neuen autorisierenden Zeitserver bekannt zu machen, geht man am einfachsten wie folgt vor:

1. Eingabeaufforderung (ab 2008 Server als Administrator ausführen!)
2. net stop w32time (Zeitdienst beenden, ansonsten gibt es eine “access denied message”)
3. w32tm /unregister (Zeitdienst “deinstallieren”)
4. w32tm /register (Zeitdienst “installieren”)
5. net start w32time (Zeitdienst starten)
6. w32tm /resync (synchronisieren mit Zeitgeber)

In meinem Fall, mussten die Systeme nicht gebootet werden. In manchen Situationen muss jedoch zwischen Schritt drei und vier das System neugestartet werden.

Testen kann man dann seine Konfiguration mit:

w32tm /monitor

Die “RefID” sollte nun überall der autorisierende Zeitserver sein. Beim PDC-Emulator bzw. beim autorisierenden Zeitserver muss diese (RefID) wiederum der Zeitserver im Internet (bsp. pool.ntp.org) oder der Zeitserver im internen Netzwerk sein. Im Optimalfall sollte die Zeit nun bis auf die vierte oder fünfte Stelle im Millisekundenbereich synchron sein.

Thomas Gronenwald

Links:
M 4.227 Einsatz eines lokalen NTP-Servers zur Zeitsynchronisation
Kritische IT-Infrastrukturen, BSI

DHCP-Migration mit Hilfe der Windows-Server-Migrationstools…

Ein Kunde möchte seine Active-Directory-Infrastruktur von Windows Server 2003 SP2 auf Windows Server 2008 R2 migrieren. Ein In-Place-Upgrade kommt nicht in Frage, zumal dank Virtualisierung eine Koexistenz schnell geschaffen werden kann. Hierbei sollen alle Domain Controller auf 2008 R2 migriert werden – ein Domain Controller fungiert zudem als DHCP-Server für Clients im Netzwerk. Da Aufgrund der Vielzahl an Reservierungen und Leases nicht einfach ein neuer DHCP mit identischen Einstellungen in Betrieb genommen werden kann, muss die DHCP-Server-Datenbank, sowie die Einstellungen exportiert und auf dem neuen System importiert werden.

Was aber mache ich, wenn die in der Vergangenheit bewährten Methoden nun nicht mehr funktionieren?

In der Vergangenheit gab es einige Möglichkeiten, einen DHCP-Server erfolgreich und schnell zu migrieren. Ein Ex- und Import mit “netsh dhcp server export C:\dhcp.txt all und netsh dhcp server import c:\dhcpdatabase.txt all” beispielsweise oder direkt die DHCP-Server-Funktion “Sichern und Wiederherstellen”.

Die Migration stellt sich nicht immer so einfach dar – ein Domain Controller mit DHCP-Server-Rolle macht die Migration nicht unbedingt einfacher, da es keinen lokalen Administrator mehr gibt der jedoch für den Export vorrausgesetzt wird.

Artikel KB 325473:
…if you plan to promote it to a domain controller, we suggested that you perform the DHCP database migration before promoting it to a domain controller. Although you can migrate the DHCP database to a Windows 2003 domain controller, the migration to a member server will be easier because of the existence of the local administrator account…

Soweit so gut…

Auch die Möglichkeit einen Domain Controller im Wiederherstellungsmodus zu starten und dann mit “lokalem Administrator” den DHCP zu importieren, ist nicht gerade eine präferierte Option.

Hier kommen die Windows Server-Migrationstools zum Einsatz. Diese Powershell cmdlets stehen ab Windows Server 2008 R2 standardmäßig als Feature bereit und können im Server-Manager hinzugefügt werden. Mit diesen Tools ist es nun möglich, von Windows Server 2003 SP2 nach Server 2008 R2, von physikalisch nach virtuell und von einer x86 zu einer x64-Architektur zu migieren – also genau das was ich benötige. Was jedoch nicht möglich ist, ist die Migration bei dem sich die Sprache der Benutzeroberfläche von der des Quellservers unterscheidet. Daher ist es nicht möglich z. B. die Windows Server-Migrationstools zum Migrieren von Rollen, von einem Computer unter Windows Server 2008 mit einer französischen Systembenutzeroberfläche zu einem Computer unter Windows Server 2008 R2 mit einer deutschen Systembenutzeroberfläche zu verwenden. Genauso wenig möglich ist die Migration von Server Core-Rollen, da schlichtweg die Vorraussetzungen (kein .NET Framework verfügbar) im Server Core nicht verfügbar sind.

Vorbereiten der Migration

Step 1: Installieren der Windows Server-Migrationstools (Zielserver, Windows Server 2008 R2)

Als erstes müssen auf dem späteren DHCP-Server und Domain Controller die Windows Server-Migrationstools installiert werden. Im Vorfeld sollte optimalerweise auch das System auf den aktuellsten Stand gebracht werden. Außerdem muss mindestens das .NET Framework 2.0 und die Windows PowerShell 1.0 verfügbar sein. Die Installation der Windows Server-Migrationstools kann einfach über den Server-Manager, über Features hinzufügen, installiert werden.

Step 2: Erstellen eines Server-Migrationtool-Deployment-Package (Quellserver, Windows Server 2003 SP2 x86)

Um die Migrationstools für den Export auch auf unserem Quellserver nutzen zu können, muss nun ein Installationspaket für unseren Windows Server 2003 SP2 x86 mit den installierten Tools auf unserem Zielserver erstellt werden.

Hierzu wechseln wir auf der Kommandozeile in das Verzeichnis “C:\Windows\System32\ServerMigrationTools” und führen folgenden Befehl zum erstellen des Paketes aus:

>SmigDeploy.exe /package /architecture X86 /os WS03 /path c:\

Hiermit wird auf dem Zielserver (Windows Server 2008 R2) in Laufwerk C:\ ein Ordner mit dem Namen “SMT_<Betriebssystem>_<Architektur>”,  in meinem Fall der Ordner “SMT_WS03_x86″ erstellt.

Step 3: Kopieren des Ordners “SMT_WS03_x86″ vom Ziel- auf den Quellserver

Nun muss der komplette Ordner noch auf den Quellserver (Windows Server 2003 SP2) kopiert werden. In meinem Fall kopiere ich diesen auch in “C:\SMT_WS03_x86″. Auch auf dem Quellserver muss zur Ausführung der Tools mindestens das .NET Framework 2.0 und die PowerShell 1.0 installiert sein.

Step 4: Registrieren der SmigDeploy.exe auf dem Quellserver

Um die cmdlets der Migrationstools auch auf dem 2003 Server nutzen zu können, müssen diese wie folgt registriert werden. Dazu wechseln wir auf der Kommandozeile in das Verzeichnis “C:\SMT_WS03_x86″ und führen folgenden Befehl aus:

>.\Smigdeploy.exe

Step 5: Exportieren der DHCP-Datenbank und Einstellungen mit Export-SmigServerSetting cmdlet (Quellserver)

Um nun die bestehenden DHCP-Einstellungen zu exportieren, empfiehlt es sich zuallererst den DHCP-Dienst zu stoppen. Dann wechseln wir in der Kommandozeile in den eben kopierten Ordner “C:\SMT_WS03_x86″ und führen zum Export folgenden Befehl aus:

>Export-SmigServerSetting -FeatureID “DHCP” -Path “C:\” -Verbose

Für die zu exportierende Datei muss noch ein Password mit mindestens sechs Stellen vergeben werden. Nach Erfolgreichem Export, erhalten wir in Lauwerk “C:\” eine Datei mit dem Namen “servermig.mig”. Jetzt kann der temporär gestoppte DHCP-Dienst vorläufig wieder aktiviert werde.

Step 6: Importieren der DHCP-Datenbank und Einstellungen mit Import-SmigServerSetting cmdlet (Zielserver)

Nun kopieren wir die exportierte Datei wieder auf unseren Zielserver. Der Einfachheithalber auch hier wieder auf “C:\servermig.mig” und wechseln auf die Kommandozeile. Mit dem Befehl:

>Import-SmigServerSetting -FeatureID “DHCP” -Path “C:\” -Verbose

importieren wir die Konfiguration auf unserem neuen Windows 2008 R2 Server. Das tolle daran ist, dass nicht einmal ein DHCP-Server vorab installiert werden muss. Die Import-Routine erkennt, ob der DHCP installiert ist oder nicht und installiert diese Rolle eigenständig. Es kann dabei durchaus sein, dass der Import mehrere Minuten dauert auch wenn die *.mig-Datei nur wenige KB groß ist  – hiervon sollte man sich aber nicht irritieren lassen.

Step 7: Prüfen der importierten Einstellungen

Jetzt gilt es noch die importierten Einstellungen zu prüfen, den alten DHCP-Server zu deaktivieren und die Autorisierung im AD aufzuheben, den neuen DHCP-Server in Betrieb zu nehmen und zu autorisieren. Wichtig ist es auch vorab noch bestimmte Schnittstellen zu prüfen, die den alten DHCP-Server nutzen. Dies kann zum einen eine VPN-Appliance sein und zum anderen Server die als DHCP-Relay fungieren – hier muss die IP-Adresse bzw. der DNS-Name auch umgestellt werden. Diese Schnittstellen gilt es jedoch vor der Migration, in der eigentlichen Planung, genauer unter die Lupe zu nehmen.

Sind alle benötigten Einstellungen vorhanden, steht der Promotion zum Domain Controller nichts mehr im Wege.

Nächster Artikel: DHCP-Split-Scope

Links:
Handbuch zur DHCP-Server Migration (Technet)

Thomas Gronenwald

Tool – Remote Sharecreator v1.0

Wie zuvor in der Beitragsreihe “Disaster Recovery” mit Wireshark erwähnt, habe ich jetzt den Remote Sharecreator soweit modifiziert das ein wirklich, nettes und kleines “Tool” entstanden ist. Das ganze basiert auf dem .net Framework 3.5 und kann jetzt eine oder mehrere Freigaben auf dem lokalen oder einem entfernten System im Netzwerk erstellen. Zudem gibt es die Möglichkeit, über eine Importfunktion auf bestehende CSV-Dateien zuzugreifen. Folgende gängigen Betriebssysteme werden unterstützt:

• Windows 2000 Professional
• Windows 2000 Server
• Windows XP
• Windows Server 2003
• Windows Server 2003 R2
• Windows Vista
• Windows 7
• Windows Server 2008
• Windows Server 2008 R2

Die wichtigsten Voraussetzungen für die Erstellung von Freigaben ist eine funktionierende Domänenstruktur, .net Framework 3.5, ein Nutzer mit den notwendigen Berechtigungen und das vorhandensein des freizugebenden Ordners auf dem Remotesystem.

Vorgehensweise bei der Erstellung einer Freigabe

Für die Erstellung einer Freigabe werden nur die Atribute Computername, Pfad und Freigabebezeichnung benötigt. Die müssen in folgendem Format eingetragen werden.

Computername: [HOSTNAME]
Pfad (Local): [LAUFWERKSBUCHSTABE]:\[Ordner1]...\[OrdnerN]
Freigabebezeichnung: [FREIGABENAME]

Vorgehensweise für die Erstellung mehrerer Freigaben

Zur Erstellung mehrerer Freigaben können diese händisch in den Remote Sharecreator eingetragen oder über eine CSV-Datei importiert werden. Hierbei ist jedoch zu beachten, dass mit dieser Version ein Import über die Zwischenablage von Excel noch nicht möglich ist. Dies ist jedoch für eine der kommenden Versionen angedacht. Die CSV-Datei kann eine beliebigen Stelle im Netzwerk oder im Dateisystem des lokalen Systems abgelegt werden. Diese muss über folgende drei Spalten verfügen.

• Spalte 1: Servername
• Spalte 2: Lokaler Pfad
• Spalte 3: Freigabe

Die Kopfzeile der CSV-Datei beliebig angepasst werden. Es ist jedoch notwendig, dass die Reihenfolge beibehalten wird.

Für den Import der Datensätze der CSV-Datei muss der Remote Sharecreator geöffnet und die Ansicht für die Erstellung mehrerer Freigaben geöffnet werden. Dann könnt ihr einfach über die Schaltfläche “Import von CSV” die gewünschte Datei auswählen und importieren.

Sascha Giebelhausen

Wie schließe ich die Rücksicherung erfolgreich ab?

Wie mein Kollege Thomas Gronenwald bereits in Teil 1 angerissen hat, wird für eine erfolgreiche Rücksicherung eine funktionierende Dateisicherung vorausgesetzt. Hier muss jedoch beachtet werden, dass zuerst die letzte erfolgreiche Vollsicherung und dann erst die Zuwachssicherungen wiederhergestellt werden. Leider beinhalten Dateisicherungen keine Freigaben für die fehlenden Fileshares (lerdiglich die NTFS-Berechtigungen). Nun gibt es  zwei Methoden zur Wiederherstellung der fehlenden Fileshares:

Methode 1: Wiederherstellung via Registry Export

Wie im Blog-Eintrag von Thomas Gronenwald bereits beschrieben ist ein Export/Import der benötigten Registry-Schlüssel (Systemstatebackup) zur Rücksicherung geeignet.

Methode 2: Halbautomatische Erstellung über eine Exceltabelle mit VBA

Sollten die Registrierungsschlüssel nicht vorhanden sein (so wie keine Dokumentation über bestehende Shares), so gibt es nicht sehr viele Möglichkeiten. Eine davon ist jedoch die im Blog-Eintrag Disaster Recovery: Letzte Ausfahrt Wireshark? Teil 1 beschriebene Vorgehensweise. Nachdem die fehlenden Freigaben enumeriert wurden, müssen diese noch erstellt werden. Diese Methode ist sehr zeitintensiv und fehlerträchtig -  wir sind ja auch nur Menschen.

Aus diesem Grund habe ich in Excel 2003 ein Makro zur Erstellung von Fileshares unter Windows 2000, Windows XP und Windows Server 2003 geschrieben.

Dies ermöglicht ein automatisiertes Erstellen von Fileshare auf einem Remote-System. Wichtig ist nur, dass die notwendigen administrativen Berechtigungen bereits vorhanden sind.

In der ersten Version wird vorerst bei einem erreichbaren Remote-System eine Freigabe erstellt. Der lokale Ordner und der Freigabename kann selbst gewählt werden. Hier können nun die mit Wireshark enumerierten und als *.csv exportierten Freigaben hinzugefügt werden.

Nachdem mit diesem Tool alle enumerierten Freigaben erstellt wurden, kann nochmals mit Wireshark überprüft werden ob alle SMB-Anfragen richtig beantwortet werden.

Das Tool ist derzeit noch in der Betaversion und wird weiter entwickelt. Gerne nehme ich dazu auch Anregungen und Verbesserungen entgegen. Eine Haftung schließe ich jedoch über diesen Weg generell aus.

Download:
Remote share creator 1.0

Sascha Giebelhausen

KMS – was ist möglich, was nicht?

Themen rund um den KMS-Host werfen zumeist noch einige Fragen auf – daher möchte ich an dieser Stelle noch einmal zusammenfassend ein paar von diesen beantworten.

Kann ich sowohl MAK als auch KMS-Schlüssel zur Bereitstellung in meiner Organisation verwenden?

Antwort: Ja, Volumenlizenzkunden können KMS, MAK oder beides verwenden, um ihre Computer zu aktivieren.

Quelle: Microsoft Licensing – Grundlagen der Lizenzierung

Woher weiß ich, welche Product Keys verwendet werden müssen?

Antwort: Product Keys sowohl für KMS und MAK sind für Product Key-Gruppen (d. h. Windows 7 und Windows Server 2008 R2) gültig und nicht für einzelne Betriebssystemeditionen (d. h. Windows 7 Enterprise, Windows 7 Professional, Windows Server 2008 Enterprise oder Windows Server 2008 Standard).

Es sind nur jeweils ein MAK- und ein KMS-Key mit der Windows Client-Produktgruppe verknüpft. Es gibt drei Product Key-Gruppen für Windows Server 2008 und Windows Server 2008 R2:

• Windows Web Server 2008/ Windows Server 2008 HPC Edition (MAK/KMS A)
• Windows Server 2008 Standard/ Windows Server 2008 Enterprise (MAK/KMS B)
• Windows Server 2008 Datacenter/Windows Server 2008 für Itanium-basierte Systeme (MAK/KMS C)

MAK-Product Keys sind direkt mit einer einzelnen Product Key-Gruppe verknüpft und können nur die Windows-Editionen innerhalb dieser spezifischen Produktgruppe aktivieren. Wenn z. B. Lizenzen für Windows Server 2008 Enterprise gekauft werden, muss der MAK verwendet werden, der mit Windows Server 2008 Enterprise (MAK B-Key) verwendet werden, um diese Systeme zu aktivieren. Ein MAK für Windows Server 2008 Datacenter (MAK C-Key) funktioniert nicht. Und ein MAK für Windows 7 funktioniert nicht für Windows Vista.

KMS-Keys funktionieren anders als MAK-Keys, da es hier eine Hierarchie gibt. Wenn Sie z. B. Lizenzen für Windows Server 2008 Datacenter R2 und für Standard-Editionen besitzen, sollten Sie den KMS-Key verwenden, der mit dem Datacenter-Produkt verknüpft ist (KMS C-Key), um den KMS-Host zu aktivieren. Der KMS-Dienst kann dann die Computer aktivieren, auf denen Windows Server 2008 Datacenter R2 und die Computer, auf denen Windows Server 2008 Standard R2 installiert ist.

Quelle: Microsoft Licensing – Grundlagen der Lizenzierung

Welches Aktivierungsverfahren sollte für virtuelle Computer verwendet werden?

Antwort: Für die Aktivierung virtueller Computer können sowohl MAK- als auch KMS-Keys verwendet werden. KMS ist jedoch das bevorzugte Verfahren, wenn es in Ihrer Umgebung implementiert werden kann. Jedes Mal, wenn ein Computer mittels eines MAK-Keys aktiviert wird, wird eine Aktivierung von der verfügbaren Anzahl abgezogen. Dies gilt sowohl für physische als auch für virtuelle Computer.

Quelle: Microsoft Licensing – Grundlagen der Lizenzierung

Der Hostcomputer meines Unternehmens wurde mittels eines Windows Server 2008 KMS-Keys aktiviert. Kann derselbe Computer als Host für die Bereitstellung von Windows Server 2008 R2 verwendet werden?

Antwort: Vorhandene KMS-Hosts, auf denen Windows Server 2003, Windows Server 2008 oder Windows Vista installiert ist, benötigen ein Update, um die Aktivierung von Windows 7/Windows Server 2008 R2-Systemen zu unterstützen. Das entsprechende Update wird über Windows Server Update Services (WSUS), das Microsoft Download Center und die TechNet-Seite für die Volumenaktivierung verfügbar sein. Nach der Installation des Updates können Sie den Windows Server 2008 R2 KMS-Key auf dem Host installieren und aktivieren.

Quelle: Microsoft Licensing – Grundlagen der Lizenzierung

Was passiert, wenn wir unsere Computer nicht aktivieren?

Antwort: Die Aktivierung soll Benutzern eine transparente Aktivierung ermöglichen. Wenn die Aktivierung nicht während der Karenzzeit (in der Regel 30 Tage) erfolgt ist wird der Computer in den Benachrichtigungsmodus versetzt. In diesem Modus werden dem Benutzer während der Anmeldung und im Wartungscenter Aktivierungserinnerungen angezeigt. Außerdem ist der Desktophintergrund in diesem Modus schwarz.

Quelle: Microsoft Licensing – Grundlagen der Lizenzierung

Kann ich den KMS-Host auf einem Domain controller installieren?

Antwort: prinzipiell ja! Laut einer Case Study der Microsoft IT, beeinträchtigt diese Funktionalität nicht die Performance eines Domain controllers. Jedoch sollte man immer bedenken, dass man sich so gewisse Abhängigkeiten schafft – Stichwort: Single point of failure.

One of Microsoft IT’s goals was to measure the impact of adding the KMS service to a domain controller. It collected metrics from the domain controller acting as a KMS host and from other domain controllers in the same domain. When Microsoft IT compared the metrics of the KMS host that was installed on a domain controller with the metrics of other domain controllers in the same domain, it found no measurable performance decrease on the domain controller that was also a KMS host. Microsoft IT concluded that adding the KMS service to a domain controller did not hinder its performance.

Quelle: Microsoft Licensing – Case Study Microsoft IT

Erhöht KMS die Serverlast?

Antwort: Natürlich. Die Frage sollte stattdessen heißen “Erhöht KMS die Serverlast so, dass meine Applikationen und Funktionalitäten darunter leiden? In einer Case Study der Microsoft IT, wurden mehrere Testszenarien durchgeführt. Ergebnis war, dass durch das regelmäßige anfragen (jede Minute) eines KMS-Clients die Performance negativ beeinflusst wird. Daraufhin wurde dieses Interval von “einmal pro Minute” auf einmal pro Woche” angehoben.

Initially, performance metrics indicated that the activations were placing stress on the processor of the KMS hosts. CPU usage kept spiking at 100 percent, even though the number of KMS clients was small. Upon investigation, Microsoft IT found that the KMS clients were renewing their activations too often. It increased the activation renewal interval from once every minute to once every seven days. As the deployment progressed through subsequent phases, Microsoft IT found that reducing this interval was a simple way to stress test KMS hosts.

Quelle: Microsoft Licensing – Case Study Microsoft IT

Links:

Windows Server 2008 R2: Key Management Service (KMS) Teil 1 – wieso, weshalb, warum?
Windows Server 2008 R2: Key Management Service (KMS) Teil 2 – wie konfiguriere ich einen KMS-Host im Unternehmen?
Windows Server 2008 R2: Key Management Service (KMS) Teil 3 – wie ändere ich einen MAK- in einen KMS-Client?

Microsoft:
Grundlagen der Lizenzierung
Case Study Microsoft IT – KMS

Thomas Gronenwald

Client mit KMS-Key aktiviert – hab ich jetzt ein Problem? – nein.

Nach der Implementierung einer KMS-Lösung im Unternehmen (Teil1 und Teil2), steht man zumeist vor dem Problem, dass einige Clients über eine MAK-Lizenz aktiviert wurden sind. Jetzt möchte man natürlich alle Clients über die neue KMS-Lösung aktivieren. Dazu müssen die Clients noch einmal mit einem sogenannten Setup-Key initialisiert werden.

Hierzu müssen nun die MAK-Clients umgestellt werden:

Initialisieren des Setup-Keys auf dem Client:

slmgr.vbs /ipk <Setup-Key>

Aktivieren des Setup-Keys auf dem Client:

slmgr.vbs /ato

Danach sollten sich die Clients automatisch über den SRV-Record beim zuständigen KMS-Host melden und sich aktivieren.

Hinweis: Die KMS-Setup-Keys sind öffentlich bekannt und abhängig von der jeweiligen Edition – es besteht also kein Lizenzverstoß!

Weitere Setup-Keys (Windows Vista und 2008 Server) findet ihr hier.

Thomas Gronenwald

So geht’s:

Wie in meinem letzten Blog-Eintrag bereits beschrieben, gibt es seit Windows Vista, Windows 7 und Windows Server 2008 / R2 eine neue Methode zur Produktaktivierung. Das gute daran ist, dass jeweils nur noch ein Datenträger existiert und benötigt wird (32- oder 64-bit). Durch die Eingabe des Produktschlüssels wird dann nach der Installation festgelegt um welche Lizenz es sich handelt.

Was muss ich aber nun beachten? Welche Vorraussetzungen gibt es?

• Windows Server 2008 R2 KMS-Hosts (kann auch Windows Vista (KMS v1.2, KB968915) Windows Server 2003 (KMS v1.2, KB968915) oder 2008 sein)
• gültigen KMS-Schlüssel
• Software License Manager (slmgr.vbs unter C:\Windows\System32)
• KMS-Host benötigt zur Einmalaktivierung eine Internetverbindung (Port 80, TCP) / optional ist auch eine telefonische Aktivierung möglich
• Kommnikation zwischen KMS-Host und KMS-Clients über Port 1688, TCP

Wichtiger Hinweis:
Bitte keine KMS-Schlüssel auf einzelnen Client-Systemen installieren. Für die Aktivierung von Clients außerhalb einer KMS-Infrastruktur bitte die dafür vorgesehenden MAK-Schlüssel nutzen. Jeder KMS-Schlüssel kann im Normalfall nur auf weiteren sechs KMS-Hosts (KMS-Server) aktiviert werden.

Unter Windows 7 und Windows Server 2008 erhält man dazu einen Warnhinweis:

In der Regel sollte man einen KMS-Schlüssel der höchsten Kategorie (Server Group C) auf dem KMS-Host aktivieren. Wichtig an dieser Stelle ist, dass der Windows Server 2008 R2 KMS-Schlüssel für die Aktivierung des KMS-Hosts genutzt wird – dieser wiederum ermöglicht die Aktivierung von Windows Server 2008, Windows 7 und Windows Vista. Es muss daher nicht! für jedes Produkt das aktiviert werden soll ein KMS-Key installiert werden.

Windows Server 2008 und Windows Vista KMS-Schlüssel können Windows 7 oder Windows Server 2008 R2 nicht aktivieren.

Wir konfiguriere ich nun einen KMS-Host im internen Netzwerk?

1. Installieren des KMS-Schlüssels auf dem KMS-Host (Server) über die Kommandozeile:
   cscript C:\windows\system32\slmgr.vbs /ipk <KMS-Schlüssel>

Die Eingabe des KMS-Schlüssels muss mit erhöhten Administratorberechtigungen vorgenommen werden.

1. Aktivieren des KMS-Hosts bei Microsoft.
   1. Für die Onlineaktivierung über die Kommandozeile:
      cscript C:\windows\system32\slmgr.vbs /ato

   

   1. Für die telefonische Aktivierung über die Kommandozeile:
      slui.exe 4
2. Neustart des Softwarelizenzierungsdienstes nach Abschluss der Aktivierung über services.msc.

Durch die Aktivierung des KMS-Schlüssel wird automatisch ein DNS-Eintrag für den KMS-Server angelegt. Hierüber erhalten die KMS-Clients dann ihre benötigten Informationen über den KMS-Host im Netzwerk.

Wenn der KMS-Host richtig konfiguriert ist, erkennt man es daran, dass die Anzahl der KMS-Clients ansteigt. Mittels slmgr.vbs /dli, kann die aktuelle Anzahl abgerufen werden. Ausserdem kann auch das Protokoll des Schlüsselverwaltungsdiensts im Ordner Anwendungs- und Dienstprotokolle auf Ereignisse mit der Nummer 12290 überprüft werden, mit denen Aktivierungsanforderungen von KMS-Clients aufgezeichnet werden. Bei jedem Ereignis werden der Name des Computers und der Zeitstempel der Aktivierungsanforderung angezeigt.

Zudem sollte noch die Erreichbarkeit des KMS-Host über den automatisch angelegten SRV-Record geprüft werden:
nslookup -type=srv _vlmcs._tcp.<your DNS domain>

Übrigens kann für die Lokalisierung des KMS-Host auch ein BIND 9.x kompatibler DNS-Server genutzt werden.

Für KMS ist eine Mindestanzahl (Aktivierungsschwellenwert) von (physikalischen oder virtuellen) Computern in einer Netzwerkumgebung erforderlich. Für die Aktivierung von Windows Server 2008 R2 müssen in der Organisation mindestens fünf Computer vorhanden sein, für die Aktivierung von Windows 7-Clients mindestens 25. Daher kann es zu fehlern bei der Aktivierung kommen, solange der Schwellenwert nicht erreicht wurde.

Coming soon:
Windows Server 2008 R2: Key Management Service (KMS) Teil 3 – wie ändere ich einen MAK- in einen KMS-Client?
Windows Server 2008 R2: Key Management Service (KMS) Teil 4 – FAQ?

Thomas Gronenwald