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

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

Coole Neuerungen: AD DS, AD PowerShell und Best Practice Analyzer

Die AD DS unter Windows Server 2008 R2 haben ja nun einige wirklich nette Neuerungen erfahren. So auch der jetzt integrierte Best Practice Analyzer für die verschiedensten Serverrollen wie die AD DS oder das DNS. Hierbei ist es nun möglich, nach der Initialen Konfiguration, die getätigten Einstellungen auf Best Practices zu prüfen.

In vielen Fällen erhält man nach der Überprüfung der AD DS die folgende Warnung:

Alle Organisationseinheiten in der Domäne müssen vor versehentlichen Löschungen geschützt werden.

Leider kommt es trotz eingeschränkter und delegierter Administration vor, dass versehentlich Organisationseinheiten (OUs) gelöscht werden – komischerweise sind es dann auch direkt immer die OUs der Geschäftsführung – mmh naja. Daher empfiehlt es sich im generellen alle bestehenden OUs vor dem zufälligen Löschen zu schützen.

Das funktioniert im Einzelfall wie folgt:

• Snap-in Active Directory Benutzer und Computer
• Auswählen der zu schützenden OU
• Rechtsklick auf OU -> Eigenschaften
• Im Reiter Objekt -> Haken setzen bei – “Objekt vor zufälligem Löschen schützen”

So erhält man nun beim Versuch die OU zu löschen folgende Fehlermeldung:

Beim erstellen von neuen OUs wird standardmäßig der Objektschutz gesetzt. Alle vorher angelegten OUs sind davon jedoch nicht betroffen – daher sind diese noch ungeschützt.

Turnschuhprojekt oder PowerShell?

Was aber macht man, wenn man eine große, verteilte Domänenumgebung mit mehr als 500 OUs betreut? – alles von Hand setzten und aus dieser Anforderung ein Turnschuhprojekt mit einem Monat Laufzeit machen? – Nein, natürlich nicht. Hier drängt sich die neue AD-Powershell gerade zu auf.

Mit folgendem PowerShell-Befehl lassen sich so innerhalb weniger Sekunden alle noch nicht geschützten OUs vor dem ungewollten Löschen schützen:

Get-ADOrganizationalUnit –filter { Name -Like “*” } -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion –eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

Und so können wir prüfen ob es funktioniert hat:

Get-ADOrganizationalUnit –filter { Name -Like “*” } -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion –eq $false}

Wenn wir hier keinen Output mehr erhalten, sollten jetzt alle OUs geschützt sein. Nichts desto trotz sollten noch ein paar Stichproben innerhalb des AD DS durchgeführt werden.

Thomas Gronenwald

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

Wieso, weshalb und warum ich einen Key Management Service brauche?

Die Produktaktivierung ist der gängige Prozess für die Validierung eingesetzter Betriebssysteme gegenüber Microsoft. Die Volumenaktivierung unterstützt Administratoren unter anderem bei der Automatisierung von Produktaktivierungen bei Windows Vista, Windows 7, Windows Server 2008 und Windows Server 2008 R2.

Die Volumenaktivierung unterscheidet dabei zwei Aktivierungsmodelle:

• Key Management Service (KMS)
• Multiple Activation Key (MAK)

KMS erlaubt es dabei die innerhalb des Unternehmens eingesetzten Betriebssysteme über einen so genannten KMS-Host automatisch im eigenen Netzwerk zu aktivieren. Dagegen arbeitet MAK auf Basis von Einmalaktivierungen. Hierbei können folgende Methoden der Aktivierung genutzt werden:

• telefonische Aktivierung
• Aktivierung über das Internet

Der wesentliche Vorteil von KMS ist jedoch, dass sich die Betriebssysteme gegenüber dem innerhalb des Netzwerkes zur Verfügung gestellten KMS-Host eigenständig aktivieren. Dieser KMS-Host wird im Vorfeld mit den eigentlichen Volumenaktivierungsproduktschlüsseln gegenüber Microsoft aktiviert. Hierdurch müssen keine Volumenaktivierungsschlüssel mehr an Systemerrichter herausgegeben werden – so soll unter anderem das weitergeben und verteilen von Produktschlüsseln an Dritte eingeschränkt werden.

Weiterhin können natürlich auch noch MAK-Schlüssel verwendet werden – dies beschränkt sich in der Regel jedoch auf Systeme die keine direkte Verbindung in das Corporate-Netzwerk (keine Verbindung zum KMS-Host) haben oder innerhalb von High-Security-Netzwerken betrieben werden.

Quelle: Microsoft Technet Volume Activation

Mit dem Umstieg auf Windows Server 2008 R2 und Windows 7 sollte die KMS-Host-Methode die präferierte Lösung für Unternehmen sein. Zu erwähnen sei an dieser Stelle noch, dass der KMS-Host einen gewissen KMS-Aktivierungsschwellenwert bei der Aktivierung von Systemen voraussetzt. Das heißt, dass die Anzahl an benötigten Aktivierungsanfragen an den KMS-Host erreicht werden muss, damit eine Aktivierung durchgeführt werden kann. KMS-Clients werden daher erst aktiviert, wenn der entsprechende Aktivierungsschwellenwert erreicht ist. Übrigens kann der KMS-Host sowohl physische als auch virtuelle Systeme aktivieren.

Folgende KMS-Aktivierungsschwellenwert sind zu beachten:

• Windows Vista: 25 Systeme
• Windows 7: 25 Systeme
• Windows 2008 R2: 5 Systeme

Hinweis:
Im Zuge der Implementierung eines KMS-Hosts im Netzwerk wird für diesen ein DNS-SRV-Record (_vlmcs._tcp) konfiguriert. Hierdurch erhalten die Clients die benötigten Informationen über den zu nutzenden KMS-Host im Netzwerk. Mehr dazu aber im 2. Teil – wie konfiguriere ich einen KMS-Host im Unternehmen?

Thomas Gronenwald

Links:
Windows-Volumenaktivierung
Volume Activation Planning Guide
Volume Activation Deployment Guide
Volume Activation Operations Guide
Volume Activation Technical Reference Guide