Unser Skript “Bert” verbindet sich per WMI (Windows Management Instrumentation) mit einem Windows-System und liest die wichtigen Eckdaten der IP-Konfiguration aus. Diese zeigt er als separierte Liste auf der Kommandozeile an. Leitet man diese Ausgabe in eine zentrale Datei auf einem Server um, so entsteht eine CSV-Datei, aus der man etwa mit Excel die IP-Konfigurationen direkt verarbeiten kann. Das Skript funktioniert lokal und über das Netzwerk.

Syntax und Verwendung

Die Grundsyntax von Bert sieht folgendermaßen aus:

cscript //nologo Bert.vbs [Rechner] /header:[yes|no]

Es handelt sich um ein Konsolenskript, daher muss es mit cscript aufgerufen werden. Der Schalter “//nologo” unterdrückt die Ausgabe der WSH-Informationen, sodass nur die eigentliche Ausgabe des Skripts erscheint. Mit dem Schalter “/header” gibt man an, ob die Spaltenüberschriften in der Ausgabe erscheinen sollen. Lässt man diese nur beim ersten Rechner ausgeben und unterdrückt sie bei allen anderen, so kann man die Ausgabe in einer einzigen Datei sammeln, die dann einmalig mit den Spaltenüberschriften beginnt.

Das Skript erfasst folgende Daten:

• Computername
• Adaptername
• MAC-Adresse
• DHCP-Nutzung
• IP-Adressen
• DNS-Server

Gibt man keinen Rechnernamen an, so wertet Bert die IP-Konfiguration des lokalen Rechners aus. Wenn man einen entfernten Rechner über das Netzwerk auswerten möchte, benötigt man dort Administratorrechte (das ist bei lokaler Ausführung nicht nötig), oder man muss die WMI-Berechtigungen auf dem Remote-System bearbeiten. Außerdem darf keine Firewall die WMI-Schnittstelle blockieren.

Eine zentrale Sammlung der Konfigurationen in der Datei “IP-Daten.txt” in einer Dateifreigabe zeigt folgendes Beispiel:

cscript //nologo C:\Pfad\Bert.vbs DC01 /header:yes > \\SERVER007\IPData$\IP-Daten.txt
cscript //nologo C:\Pfad\Bert.vbs EX01 /header:no >> \\SERVER007\IPData$\IP-Daten.txt
cscript //nologo C:\Pfad\Bert.vbs SQL01 /header:no >> \\SERVER007\IPData$\IP-Daten.txt

Um die Einschränkungen bei der Remote-Auswertung zu umgehen, kann man Bert auch aus einem Start- oder Logonskript aufrufen. Da normale Anwender die WMI-Schnittstelle lokal aufrufen dürfen, sind hierzu keine besonderen Benutzerrechte nötig. In diesem Fall muss man darauf achten, dass für die Anwender (bei Logonskripts) bzw. für die Computerkonten (bei Startskripts) Schreibrechte auf die Sammel-Datei bestehen.

Um beim Einsatz per Logonskript Schreibkonflikte durch gleichzeitigen Zugriff auf die Zieldatei zu vermeiden, kann man z.B. über folgendes Batch die Daten des lokalen Rechners in jeweils eine eigene Datei schreiben:

@echo off
rem Schreibt die IP-Grundkonfiguration des Rechners in eine Textdatei

SET Target=\\SERVER\IPData$\Clients\%computername%.txt
SET Bert=\\SERVER\IPData$\Bert.vbs

COPY %Bert% "%userprofile%"

cscript //nologo "%userprofile%\Bert.vbs" /header:no > %Target%

DEL "%userprofile%\Bert.vbs"

Dieses Batch kopiert zunächst die Skriptdatei ins lokale Userprofil, damit es keine Berechtigungsfehler beim Aufruf von einem Share aus gibt. Das Ergebnis der Ausführung landet dann in einer Textdatei auf einer Dateifreigabe, die den Namen des lokalen Rechners trägt. Am ende entfernt das Batch die Skriptdatei wieder vom System.

In der Freigabe liegen dann zahlreiche Dateien – eine pro Rechner. Um sie nachträglich zu einer Datei zusammenzufassen, eignet sich dieses Kommando, das man in einem CMD-Fenster aus dem Ordner ausführt, wo die Dateien liegen:

for /F "usebackq" %i in (`dir /b`) do @type %i | find /i ";" >> "IP-Konfigs Clients.txt"

Keine verwandten Beiträge.

Unabhängig davon macht das BSI viele sinnvolle Vorschläge, die jedoch auch als ebensolche angesehen werden sollten, und keinesfalls als "Vorgaben" zu interpretieren sind. Wie auch die Autoren schreiben, ist jede Einstellung auf Sinnhaftigkeit für die eigene Situation und Kompatibilität mit vorhandenen Anwendungen zu prüfen.

Die Empfehlungen sind sorgsam recherchiert. Einige kleine Fehlerchen konnte ich dennoch finden:

• Seite 66, "Datenausführungsverhinderung"
  Es wird empfohlen, DEP für alle Programme und Dienste einzuschalten. Dies kann jedoch zu Fehlfunktionen bei manchen Programmen führen und erfordert gründliches Testen.
• Seite 75, "Neue Drucker automatisch in Active-Directory veröffentlichen"
  Es wird empfohlen, dies zu deaktivierten. Die Einstellung ist jedoch für Windows 7 ohnehin nicht wirksam.
• Seite 75, "Installation von Druckern, die Kernelmodustreiber verwenden, nicht zulassen"
  Es wird empfohlen, dies zu deaktivierten. Die Einstellung ist jedoch für Windows 7 ohnehin nicht wirksam.

Alles in allem ein sinnvolles Dokument, dessen Lektüre für jeden auf Sicherheit bedachten Administrator selbstverständlich sein sollte. Es ist übrigens das erste Dokument des BSI zu Windows 7. Bislang musste sich, wer Empfehlungen des BSI befolgen wollte, mit dessen Informationen zu Windows Vista behelfen.

Verwandte Beiträge:

1. Drucken unter Windows 7 in der Domäne
   Unter Windows 7 haben sich mal wieder die Sicherheitseinstellungen für...
2. Kompatibilitätsliste für Windows-7-Applikationen
   Microsoft stellt ein umfangreiches Dokument bereit, das Aufschluss über die...
3. Windows 7 und Watchguard-VPN
   Ich stehe kurz davor, Windows 7 (RC) in den Produktionsbetrieb...

[Windows 8 Hyper-V Feature Glossary]
http://www.aidanfinn.com/?p=11979

Keine verwandten Beiträge.

• Administratoren löschen das Protokoll
• Das automatische Überschreiben ist abgeschaltet
• Die Größe ist zu stark beschränkt

Gerade der letzte Fall ist immer wieder zu beobachten, wenn es Probleme auf einem System gibt. Häufig schreibt Windows dann sehr viele Einträge in das Protokoll, sodass es sich schnell füllt. Erreicht das Protokoll dann die maximale Größe, so löscht Windows vom Ende her “alte” Ereignisse, um die neuen schreiben zu können. Schnell führt das dann dazu, dass die Informationen nur noch wenige Tage oder wenige Stunden in die Vergangenheit reichen, sodass man keine Informationen mehr findet, wann und wie das Problem begonnen hat.

Wie groß sollte man denn dann die Protokolle einstellen?

Die Antwort auf diese Frage hängt leider vom eingesetzten System ab. Vor allem ist zu unterscheiden, ob man eine 32-Bit- oder eine 64-Bit-Plattform einsetzt:

• 32-Bit: Auf “älteren” Systemen (XP und Windows Server 2003) steht dem Betriebssystem für alle Protokolle zusammen nur ein Platz von etwa 300 MB zur Verfügung. Die Summe aller Protokolle sollte diesen Wert also nicht übersteigen.
  Im Fall von Vista und Server 2008 gibt es diese Beschränkung auch bei 32-Bit-Systemen nicht mehr.
• 64-Bit: Alle 64-Bit-Systeme haben kein Limit, das die Nutzung des Eventlogs ernsthaft einschränkt. Microsoft empfiehlt, dass einzelne Logs nicht größer als 4 GB werden und die Größe aller Logs zusammen nicht über 16 GB liegen sollte.

Standardmäßig sind die Logs bei aktuellen Systemen auf maximal 20 MB gesetzt, doch diese Größe darf und sollte man bei wichtigen Systemen durchaus hochsetzen.

Wie hoch man den Wert setzen sollte, lässt sich pauschal nicht sagen. Es hängt davon ab, wie viele Events man aufbewahren möchte; gleichzeitig sollte man natürlich auch den verfügbaren Speicherplatz im Auge behalten. Eine Faustformel: Ein Event-Eintrag belegt durchschnittlich 500 Bytes. Möchte man in der Lage sein, über einen Zeitraum von vier Wochen pro Tag 5000 Ereignisse aufzubewahren, so muss das Log mindestens 500 × 5000 × 28 Bytes groß sein, also 70000000 Bytes (oder einfacher: 70 MB). Dabei muss der Wert, den man einträgt, ein Vielfaches von 64 KB sein – hier wäre der einzutragende Wert also 70016 KB.

Dabei sollte man aber berücksichtigen, dass es durchaus auch größere Einträge geben kann und dass ein modernes Windows-System eine maximale Lograte von 5000 Einträgen pro Sekunde erreichen kann. Ein Standardwert für “alles” lässt sich also nicht festlegen.

Mehr dazu:

[Recommended settings for event log sizes in Windows Server 2003, Windows XP, Windows Server 2008 and Windows Vista]
http://support.microsoft.com/kb/957662/en-us

[Event Log]
http://technet.microsoft.com/de-de/library/dd349798(WS.10).aspx

[Event log size limitation removed from R2?]
http://social.technet.microsoft.com/Forums/en/windowsserver2008r2general/thread/772bf5dd-4d8d-4171-9fbb-f2a6288c1670

Verwandte Beiträge:

1. TechNet TechDays zu Windows 7
   Microsofts TechNet-Programm führt im Juni seine TechDays-Reihe zu Windows 7...
2. Special Event zu Windows 7: Drei Communities laden ein
   Vielen Dank an alle Teilnehmerinnen und Teilnehmer am 4. Juni...
3. vSphere-Client auf Windows 7 installieren
   Der aktuelle vSphere-Client (früher: VI-Client) von VMware läuft nicht auf...

Autoren von faq-o-matic.net sind als Sprecher dabei. Bestätigt sind bereits Marc Grote mit Sessions zu Windows Server “8” und SCVMM 2012 sowie Nils Kaczenski mit Vorträgen zu Active Directory, Hyper-V und File-Services, alles in den neuen Fassungen von Windows Server “8”.

Parallel zur WinOne führt der Veranstalter ppedv zwischen dem 30. Januar und dem 3. Februar 2012 gleich vier Konferenzen durch: VSone, SharePoint, ASP und WINone. Die Tickets gibt es in Varianten für einen oder mehrere Tage und berechtigen zum Eintritt in alle parallelen Veranstaltungen. Ergänzend zur WinOne gibt es einige Ganztages-Workshops zu Exchange, Hyper-V und SCVMM. Ein spannendes Paket also – die Anmeldung ist geöffnet, die Plätze sind begehrt.

[WinOne 2012]

http://www.winone.at/munich/default.aspx

Verwandte Beiträge:

1. heise-Konferenz: Virtualisierung
   Im November 2009 veranstaltet heise Netze eine Konferenz-Reihe zur Servervirtualisierung....
2. Exchange 2007 auf Windows Server 2008 R2 installieren
   Mit dem Service Pack 3 für Exchange Server 2007 ist...
3. SCVMM 2008 R2 SP1 ist jetzt auch da
   Kurz nach der Veröffentlichung der Beta von SCVMM 2012 hat...

Die neue Funktion erlaubt es, einen einheitlichen DHCP-Adressbereich gleichzeitig und vollständig auf zwei Servern bereitzuhalten. Eine Aufteilung auf beide Server ist nicht notwendig, denn die Partner gleichen ihren Adresspool und die Leases untereinander ab. Das vermeidet eine Reihe von Einschränkungen, die im klassischen “Split Scope”-Verfahren vorliegen. Das Failover-Feature setzt genau zwei Server voraus, größere Verbünde lassen sich damit nicht aufbauen.

Die Einrichtung erfolgt assistentengesteuert oder per PowerShell. Zwischen den beteiligten DHCP-Servern erzeugt die Administratorin eine Failover-Partnerschaft, die sich auf einen, mehrere oder alle IP-Adressbereiche  bezieht, die per DHCP verteilt werden. Für jeden Bereich kann man dabei aus zwei Optionen wählen:

1. Load Balancing: Neben dem Failover im Fall eines Serverfehlers arbeiten beide DHCP-Server im Normalbetrieb parallel und versorgen Clients mit IP-Konfigurationen. Dadurch entsteht eine Aktiv-/Aktiv-Partnerschaft.
2. Hot Standby: Die einfachere Konfiguration arbeitet mit einem primären und einem Standby-Server. Nur wenn der primäre Server einen Scope nicht mehr bedient, springt der Standby-Server ein. Hierfür lässt sich vorab ein Teil der Adressen reservieren.

Die Einrichtung der neuen Funktion ist recht einfach und weitgehend selbsterklärend.

Neben dieser Funktion wird der neue DHCP-Server auch ein “Policy-based Assignment” unterstützen, mit dem verschiedene Adressbereiche und Konfigurationen auf Basis selbst definierter Richtlinien an DHCP-Clients ausgegeben werden. Das erlaubt eine gezielte Segmentierung des Netzwerks nach logischen Kriterien bei vergleichsweise einfacher Administration.

Verwandte Beiträge:

1. Wie kann man einen DHCP-Server unter Windows ausfallsicher gestalten?
   Der erste Gedanke zielt an dieser Stelle meist in Richtung...
2. DHCP-Server autorisieren ohne Organisations-Admin-Rechte
   Um in einer Active-Directory-Umgebung einen auf Windows 2000/2003 basierenden DHCP-Server...
3. Dynamische DNS-Updates seit Vista nicht mehr per DHCP-Client
   Gerade machte Yusuf Dikmenoglu auf ein Detail aufmerksam, das ich...

Alle Angaben beziehen sich auf die Developer Preview von Windows Server “8”, die derzeit den MSDN-Abonnenten zugänglich ist. Es handelt sich um eine Pre-Beta-Version, also kann sich noch alles ändern.

Im Wesentlichen konzentrieren die Neuerungen sich auf drei Bereiche:

1. Virtualisierung und Cloning
2. Management
3. Neue Berechtigungsstrukturen für Dateiserver

Virtualisierung

Schon in den aktuellen Windows-Versionen ist es problemlos möglich (und auch unterstützt), Domänencontroller virtuell zu betreiben. Bislang gibt es dabei aber ein paar wesentliche Einschränkungen in den Virtualisierungsfunktionen, die man auf virtuelle Domänencontroller anwenden darf. So sollte man tunlichst davon absehen, DCs per VM-Snapshot zu konservieren und insbesondere auf einen Snapshot zurückzuspringen. Die Folge wäre ein USN-Rollback, durch das der “zurückgesetzte” DC nicht mehr korrekt an der AD-Replikation teilnimmt. Aus demselben Grund ist es derzeit nicht möglich, einen DC zu kopieren (klonen), um einen neuen DC daraus zu erzeugen: Auch hier würde ein USN-Rollback für gravierende Probleme sorgen.

In Windows Server “8” gibt es einen neuen Mechanismus, der beide Vorgänge für VM-DCs möglich macht. Man sollte sich allerdings der Grenzen bewusst sein, um nicht versehentlich doch in das USN-Problem zu laufen.

Die Snapshot-Unterstützung nutzt eine neue Funktion in Active Directory und in aktualisierten Virtualisierungs-Plattformen namens “VM-Gerenation ID”. In diesem Attribut hinterlegt der Hypervisor eine Kennung für die aktuelle Version der VM. Setzt man die VM auf einen früheren Snapshot zurück, so muss der Hypervisor diese ID ändern und über eine definierte Schnittstelle mitteilen.

Ein Domänencontroller unter Windows Server “8” speichert die VM-Generation ID in einem neuen AD-Attribut, das er lokal hält und nicht repliziert. Jeder virtuelle DC weiß so, auf welchem VM-Stand er sich befinden sollte. Vor jeder Änderung (Transaktion) in seiner Kopie der AD-Datenbank vergleicht der Domänencontroller nun seine gespeicherte ID mit derjenigen, die der Hypervisor an ihn berichtet. Stimmen sie überein, so geht der DC davon aus, dass er auf dem aktuellen Stand ist und führt die Transaktion aus. Sind die IDs hingegen unterschiedlich, so ist dies für den DC ein Signal, dass er auf einen älteren VM-Snapshot zurückgesetzt wurde. Er wird die Transaktion dann zurückstellen und zunächst eine Bereinigung ausführen. Hierzu erzeugt er eine neue Datenbank-Kennung (Invocation ID) und verwirft seinen RID-Pool (Relative Identifier), damit er keine Duplikate von Sicherheitsprinzipalen (Benutzer-, Gruppen- oder Computerkonten) erzeugt. Durch die neue Invocation ID erkennen alle anderen DCs einen neuen Replikationspartner und passen ihre Replikationsvorgänge auf diese Situation an. Im Wesentlichen entspricht der Vorgang demjenigen, der auch bei einem ordentlichen Recovery des Active Directory über ein Systemstate-Backup erfolgt. Erst nach Abschluss dieser Prozesse führt der DC die ausstehende Transaktion aus.

Wichtig dabei: Derzeit gibt es nur einen einzigen Hypervisor, der die neue Technik der VM-Generation ID beherrscht, und das ist Hyper-V 3.0 – also die neue Fassung von Windows Server “8”. Ältere Hyper-V-Versionen sowie alle anderen Anbieter können das (noch) nicht. Microsoft arbeitet aber nach eigener Aussage mit den anderen Herstellern zusammen, damit diese die Funktion ebenfalls implementieren. Ebenso wichtig: Auf Active-Directory-Seite unterstützt ebenfalls nur Windows Server “8” dieses Feature.

Dem Vernehmen nach rät Microsoft auch weiterhin davon ab, VM-Snapshots in Produktionsumgebungen für Domänencontroller zu nutzen. Stattdessen sind auch weiterhin die offiziellen Backup-Prozeduren zu verwenden. Die neue Funktion soll in erster Linie die fatalen Auswirkungen “versehentlicher” Snapshot-Rollbacks für DCs verringern.

Zudem ist zu berücksichtigen, dass die neuen Mechanismen ausschließlich mit virtuellen Domänencontrollern funktionieren. Image-Backups von DCs sind damit auch weiterhin keine nutzbare Alternative!

Die neue “VM-Generation ID” ist bislang nur sehr rudimentär öffentlich dokumentiert. Details zur Implementierung liegen noch weitgehend im Dunkeln. Dazu gehört auch die durchaus kritische Frage, wie ein virtueller DC vor Fehlern des Hypervisors geschützt wird. Denkbar ist etwa eine Situation, in der der Hypervisor keine neue ID erzeugt, obwohl er dies tun müsste. Auf der anderen Seite könnte es passieren, dass der Hypervisor durch eine Fehlfunktion oder einen Angriff ständig neue IDs erzeugt und damit einen DC handlungsunfähig macht, weil er laufend neue Invocation IDs erzeugen muss.

DC-Cloning

Der neue Mechanismus der VM-Generation ID bildet auch die Grundlage für das erstmals unterstützte Klonen von Domänencontrollern. Dadurch kann man neue DCs auf Basis einer Vorlage erzeugen und so deutlich schneller ausrollen als bisher. Man sollte dabei allerdings in Betracht ziehen, dass auch der traditionelle Weg, einen neuen DC zu erzeugen, in den meisten Umgebungen weniger als eine halbe Stunde Zeit erfordert. Das Cloning sollte daher nicht als neuer Königsweg gelten, sondern eher als zusätzliche Option.

Das Klonen von DCs erfordert in Windows Server “8” einige Vorbereitungen. Zunächst braucht es mindestens zwei DCs mit dem neuen Betriebssystem: Den PDC-Emulator (Inhaber der entsprechenden Betriebsmasterrolle) und einen weiteren DC, der als Vorlage für die Klone dient. Der PDC-Emulator selbst kann nicht als Vorlage herhalten – in neu aufgesetzten Domänen ist dies stets der allererste DC.

Um die Klon-Funktion zu nutzen, muss man zunächst den Vorlagen-DC als solchen autorisieren. Dies geschieht über eine neue AD-interne Berechtigung auf Domänenebene, die man dem DC-Computerkonto zuweist (“Allow a DC to create a clone of itself”). Durch diesen Vorgang soll die Berechtigung, DC-Klone zu erzeugen, in der Hoheit der AD-Administratoren liegen, damit die Betreiber der VM-Umgebung nicht wahllos Kopien dieser sensiblen Komponente erzeugen.

In einem zweiten Schritt muss man dann eine Reihe von XML-Dokumenten erzeugen, die den Namen und die Netzwerkkonfiguration des neuen Klon-DCs sowie Informationen zu weiteren lokal laufenden Applikationen und Komponenten enthalten. In der aktuellen Preview-Version des Server-Windows gibt es keine grafischen Editoren dafür, man muss sie also im Quelltext bearbeiten.

Für das eigentliche Cloning fährt man den Vorlagen-DC herunter und kopiert dann die virtuelle Festplatte oder über die VM-Verwaltung die ganze VM. Der Hypervisor muss dabei eine neue “VM-Generation ID” erzeugen – was (siehe oben) derzeit nur Hyper-V 3.0 beherrscht. Beim ersten Start des Klon-DCs stellt dieser dann anhand der ID und der XML-Dateien fest, dass er geklont wurde, und kontaktiert den PDC-Emulator, um sich ins AD einzubinden. Falls im Konfigurations-XML kein Name und keine Netzwerkkonfiguration vorgegeben ist, generiert der PDC-Emulator eine neue Identität und weist sie dem neuen Klon zu. Diese letztere Funktion unterstützt vor allem Massen-Rollouts und die Automatisierung in großen Cloud-Umgebungen.

Microsoft positioniert die neue Funktion vor allem für große Umgebungen mit hohen Automatisierungs-Anforderungen sowie zur Vereinfachung des Forest Recovery in großen Netzwerken. Wie oben angemerkt, dürfte sie für kleine und mittlere Netzwerke kaum eine sinnvolle Erleichterung darstellen.

Management

Für die Verwaltung von Active Directory hat Microsoft besonders das “Active Directory Administrative Center” mit dem schönen Kürzel “ADAC” erweitert, das erstmals mit Windows Server 2008 R2 vorgestellt wurde. Im Gegensatz zur aktuellen Fassung wird die neue Version deutlich erweitert sein und nicht nur einfache Basis-Operationen unterstützen.

Neben der besseren Verwaltung von AD-Berechtigungen bringt das neue ADAC vor allem eine grafische Oberfläche für den AD-Papierkorb (AD Recycle Bin) mit, der zwar mit Windows Server 2008 R2 schon zur Verfügung steht, aber dort noch ohne eigene Oberfläche daherkommt. Das Wiederherstellen versehentlich gelöschter Objekte ist so viel einfacher möglich.

Auch für die “Fine-Grained Password Policies” gibt es nun eine grafische Oberfläche im ADAC. Diese Funktion gibt es bereits seit Windows Server 2008, doch ist sie weitgehend unbekannt geblieben, weil eben kein GUI dafür bereitsteht. Durch diese Policies ist es möglich, mehr als eine Kennwortrichtlinie in derselben Domäne umzusetzen und etwa administrative Konten besser zu schützen als die “Allgemeinheit”.

Schon in der 2008-R2-Fassung beruht das ADAC auf der PowerShell. In der neuen Version bringt es nun eine “PowerShell History” mit, sodass man GUI-Vorgänge besser in PowerShell-Skripts übernehmen kann. Vielleicht führt dies durch Einübung zu einer weiteren Verbreitung der PowerShell in Admin-Kreisen.

Außerhalb des ADAC wurde vor allem die Installation von Domänencontrollern überarbeitet. Erstmals seit Windows 2000 gibt es nun kein “dcpromo” mehr. Das vormals separate Kommando zum Hoch- oder Runterstufen eines DCs ist nun vollständig in den neuen Server-Manager sowie in die PowerShell überführt worden. Der neue Installationsprozess automatisiert nun weit mehr Vorgänge als bisher, was vor allem beim nachträglichen Einfügen neuer DCs in bestehende Domänen hilfreich ist. Das früher ebenfalls separate “adprep.exe” ist nun nicht mehr notwendig, aber als Option weiter verfügbar (in der Developer Preview allerdings nur als x64-Version für Windows Server 2008 und R2!).

Die PowerShell-Commandlets für Active Directory sind künftig deutlich umfangreicher als zuvor. Vor allem bringen sie nun alles mit, was man zum Steuern und Überprüfen der AD-Replikation benötigt. Das lässt sich durchaus als Hinweis verstehen, dass die bisherigen Kommandozeilentools für diese Vorgänge bald evtl. nicht mehr unterstützt werden.

Neue Berechtigungsstrukturen für Dateiserver

Eher in die Kategorie “Revolution” fällt ein neues Berechtigungssystem für Dateiserver. Unter dem Namen “Flexible Access” wird Windows Server “8” erstmals ein neues Prinzip der Zugangsverwaltung mitbringen, das nicht mehr ausschließlich auf festen Berechtigungslisten (Access Control Lists, ACL) beruht. Mit Hilfe dieser Technik wird es möglich sein, den Zugriff auf Dateien über verschiedene Attribute zu steuern. Neben der Mitgliedschaft in Gruppen können dazu weitere Eigenschaften eines Users zählen, etwa der eingetragene Standort. Solche Daten kann ein “8”-Dateiserver mit Tags vergleichen, die Dateien oder Ordnern zugewiesen sind. So lassen sich Logiken aufbauen wie “Zugriff erhalten Anwender aus der Zentrale, die in der Personalabteilung arbeiten”.

Diese Funktion wird einiges an näherer Betrachtung erfordern, und es handelt sich nicht ausschließlich um ein Active-Directory-Feature. In zukünftigen Artikeln werden wir uns damit beschäftigen.

Verwandte Beiträge:

1. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 4
   Hier als letzter Teil unserer kleinen Artikelserie zu Hyper-V 3.0...
2. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 1
   Eine der Funktionen, die Microsoft im kommenden Windows Server “8”...
3. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 2
   Diese zweite Folge unserer Artikelserie zu Hyper-V 3.0 konzentriert sich...

Abbildung 1

In Abbildung 1 ist die Bibliothek Dokumente gezeigt. Der erste Pfad ist benutzerbezogen und verweist auf %userprofile%\Documents. Der zweite Eintrag verweist auf den Ordner %public%\Documents und wird den meisten Admins Sorgen bereiten, wenn mehrere Benutzer an diesem Computer arbeiten und darüber Daten ausgetauscht werden – besonders problematisch bei Terminalservern. Auch in deutschsprachigen Windows-Versionen werden diese Pfadangaben verwendet, erkennbar in Abbildung 3, wenn man in die Adresszeile klickt.

Abbildung 2

Abbildung 3

Analog gelten auch immer zwei Pfade für die anderen Bibliotheken Bilder, Musik und Videos:

• Bilder
  • Eigene Bilder = %userprofile%\pictures
  • Öffentliche Bilder = %public%\pictures
• Dokumente (Abbildung 1, 2 und 3)
  • Eigene Dokumente = %userprofile%\documents
  • Öffentliche Dokumente = %public%\documents
• Musik
  • Eigene Musik = %userprofile%\music
  • Öffentliche Musik = %public%\music
• Video
  • Eigene Videos = %userprofile%\videos
  • Öffentliche Videos = %public%\videos

Leider hat Microsoft anscheinend vergessen, eine zentrale Konfigurationsmöglichkeit der Bibliotheken über Gruppenrichtlinien (GPO) zur Verfügung zu stellen. Man vermisst dies bei zentralisierten Netzwerken mit Windows-7-Clients ebenso wie bei der Einrichtung von Terminalservern unter Windows Server 2008R2. Dabei kann es durchaus sinnvoll sein, für verschiedene Benutzergruppen an einen zentralen Bilder- oder Video-Ordner im Netzwerk umzuleiten, dabei gibt es ein paar Stolpersteine zu beachten. Im einfachsten Falle möchte man einfach nur bei allen Benutzern den Eintrag zu Öffentliche Bilder, Öffentliche Dokumente, Öffentliche Musik und Öffentliche Videos entfernen.

Prinzipiell lassen sich die Bibliotheken ganz einfach über das Kontextmenü konfigurieren, siehe Abbildung 1. Dabei werden die Einstellungen in die Dateien

• Documents.library-ms
• Music.library-ms
• Pictures.library-ms
• Videos.library-ms

im Pfad

%userprofile%\AppData\Roaming\Microsoft\Windows\Libraries

abgespeichert und werden im Windows Explorer in Deutsch und ohne Dateiendung angezeigt. Die Dateien sind nur zu sehen, wenn man versteckte Dateien anzeigen lässt. Wer will, kann diese Dateien auch mit dem Notepad einmal öffnen. Ich finde es zu umständlich, mit Skripten die richtigen Pfade in den Dateien anzupassen. Daher hier ein anderer möglicher Weg zum Ziel …

Abbildung 4

Vorbereitungen

Man erstellt sich eine zentrale Freigabe im Netzwerk \\server\libraries und platziert dort die vier Dateien Documents.library-ms, Music.library-ms, Pictures.library-ms und Videos.library-ms von irgendeinem Benutzerprofil. Per Kontextmenü passt man sich diese Vorlagen nach den Wünschen an und speichert diese ab, z.B. ohne Öffentliche Dokumente (%public%\documents), Bilder, Musik und Videos. Dass entsprechende Leserechte für die Freigabe, den Ordner und die Dateien konfiguriert werden, setze ich jetzt voraus.

Die Umsetzung

Wir erstellen uns eine Gruppenrichtlinie, die die vier Standard-Dateien im Benutzerprofil mit den Vorlagen aus der zentralen Freigabe vom Server ersetzt. Die Einstellungen in der Gruppenrichtlinie finden wir über Benutzerkonfiguration, Einstellungen, Windows-Einstellungen, Dateien:

Abbildung 5

Hier erstellt man ein neues Dateiobjekt mit der Aktion Ersetzen. Für das Beispiel der Bibliothek Dokumente verwendet man als Quelle

\\server\libraries\documents.library-ms

Für Zieldatei verwendet man den Eintrag

%Userprofile%\AppData\Roaming\Microsoft\Windows\Libraries\documents.library-ms

Man beachte, dass man NICHT über die Durchsuchen-Schaltfläche an die Dateien *.library-ms gelangt. Hier ist Eintippen oder Kopieren/Einfügen angesagt. Unter Gemeinsame Optionen ist eingestellt: „Im Sicherheitskontext des angemeldeten Benutzers ausführen (Benutzerrichtlinienoption)“. Damit ist die Konfiguration abgeschlossen. Viel Erfolg!

Verwandte Beiträge:

1. Virtueller Launch von Windows 7 und Windows Server 2008 R2
   Microsoft hat neben seiner “Joint Launch”-Tour und einigen internationalen Veranstaltungen...
2. Wo ist das Startmenü in Windows 7 und Server 2008 R2?
   Da ich es selbst immer wieder nachschlagen muss … sind...
3. Bilder drucken in Windows 7
   Gerade hatte ich eine Reihe von Bildern zu drucken. Es...

Die Liste ist rein subjektiv, relativ spontan und natürlich unvollständig.

[Windows Server 8 Developer Preview, What's new in Hyper-V 3.0]
http://www.rozmazat.cz/articles/2011/09/15/windows-server-8-developer-preview-whats-new-in-hyper-v-3-0.html

[Windows Server 8 Host Maximums]
http://www.aidanfinn.com/?p=11849

[Build Windows 2011 Review]
http://www.aidanfinn.com/?p=11806

[Building Continuously Available Systems with Hyper-V]
http://www.aidanfinn.com/?p=11791

[How Many NICs for Clustered Windows Server 8 Hyper-V?]
http://www.aidanfinn.com/?p=11787

[It’s Official: Hyper-V on Windows 8 Desktop]
http://www.aidanfinn.com/?p=11536

[Hyper-V Replica DR Strategy Musings VS What We Can Do Now]
http://www.aidanfinn.com/?p=11419

[BUILD2011: Hyper-V | Channel 9]
http://channel9.msdn.com/events/BUILD/BUILD2011?sort=sequential&direction=desc&term=&t=hyper-v

[Windows Server 8 Hyper-V new features | Hyper-v.nu]
http://www.hyper-v.nu/archives/hvredevoort/2011/09/windows-server-8-hyper-v-new-features/

[Windows Server 8 will bring us this! | Hyper-v.nu]
http://www.hyper-v.nu/archives/pnoorderijk/2011/09/windows-server-8-will-bring-us-this/

[What's New in Windows 8 for Hyper-V Based Cloud Computing (Part 1) - Hyper-V Key Features]
http://www.virtualizationadmin.com/articles-tutorials/microsoft-hyper-v-articles/general/whats-new-windows-8-hyper-v-based-cloud-computing-part1.html

[Virtualized Networking Interfaces in Hyper-V]
http://msdn.microsoft.com/en-us/library/windows/hardware/hh205419(v=vs.85).aspx

[What is SR-IOV? - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers]
http://blog.scottlowe.org/2009/12/02/what-is-sr-iov/

[Vortrag zu Hyper-V R3 vom zweiten Hyper-V-Community « Hyper-V Server Blog der Rachfahl IT-Solutions GmbH & Co. KG]
http://www.hyper-v-server.de/videos/hyper-v-community-hyper-v-r3-bersicht-ber-die-highlights/

Ergänzend hier der Verweis auf die Microsoft Virtual Academy (MVA). Dort gibt es kostenlose, thematisch aufbauende Kurse zu Virtualisierungs- und Cloud-Themen. Wer Kurse belegt und abschließt, füllt damit ein Punktekonto, das Auskunft über das Bildungs-Engagement gibt.

[Microsoft Virtual Academy – Kostenlose Schulungen zu Microsoft-Cloudtechnologien]
http://www.microsoftvirtualacademy.com/Home.aspx?ocid=otc-n-de-loc–MVA-NK

Verwandte Beiträge:

1. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 3
   Dies ist der dritte Teil unserer kleinen Artikelserie zu den...
2. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 1
   Eine der Funktionen, die Microsoft im kommenden Windows Server “8”...
3. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 2
   Diese zweite Folge unserer Artikelserie zu Hyper-V 3.0 konzentriert sich...

In diesem Artikel geht es vor allem um Funktionen zur Verfügbarkeit virtueller Maschinen. Das ist selbstverständlich eine Kernanforderung an die Virtualisierung: Schließlich will man sich auf seine virtuellen Server verlassen können. In der aktuellen Fassung von Hyper-V gibt es dazu die Clusterfunktion und die “Live Migration”, obwohl letztere nur die Verfügbarkeit in planbaren Situationen gewährleistet und keine Ausfallsicherheit bietet. Der Nachteil: Ein Cluster erzeugt erheblichen Aufwand und – wenn man es richtig macht – durchaus auch erhebliche Kosten. Mit Windows Server 2008 R2 gibt es kaum eine sinnvolle Möglichkeit, unterhalb der Cluster-Ebene die Verfügbarkeit zu erhöhen, jedenfalls nicht mit Bordmitteln.

In Hyper-V 3.0 ändert sich diese Situation dramatisch. Im Vordergrund stehen dabei die Replikations-Funktion, die Live Migration und der Cluster-Aufbau.

Replikation

Hyper-V kann in der neuen Version einzelne virtuelle Maschinen von einem auf einen anderen Host replizieren. Diese Übertragung erfolgt asynchron auf Basis von VM-Snapshots: Die replizierte VM ist also kein synchrones Abbild des Originals, sondern steht immer in einer gewissen Latenz. Das Szenario, das man hiermit bedienen kann, ist das schnelle Umschalten auf ein “nahezu” aktuelles Ausweich-System mit derselben Identität im Netzwerk. Das Prinzip unterscheidet sich also von der Funktion “Fault Tolerance” in VMware oder der Marathon-Integration in Citrix XenServer.

Die Voraussetzungen für die Replikation sind sehr gering. Man benötigt keinen Cluster, kein SAN und zumindest grundsätzlich auch keine spezielle Infrastruktur. Sobald man zwei oder mehr Hyper-V-Hosts hat, kann man die Replikation aktivieren und dann für einzelne VMs einrichten. Die Hosts müssen dabei auch nicht demselben Active Directory angehören (auch wenn dies die Konfiguration erleichtert). Man kann problemlos VMs von einer lokalen Host-Festplatte auf die lokale Platte eines anderen Hosts replizieren.

Folgende Einstellungen kann man in der Developer Preview auf Host-Ebene vornehmen, um die Replikation vorzubereiten:

Für einzelne VMs hilft dann ein Assistent durch die nötigen Einstellungen:

Eine interessante Zusatzfunktion: Die Replikation kann nicht nur den jeweils aktuellen Stand der VM auf einem anderen Host vorhalten, sondern auch eine Historie. Das ermöglicht in bestimmten Situationen, Fehler “rückgängig” zu machen. Vorsicht aber: Nicht jede Applikation wird damit klarkommen, dass plötzlich ein “alter” Zustand aktiv ist (beispielsweise Active Directory bis einschließlich Windows Server 2008 R2).

Sollte die zu replizierende VM bzw. der Inhalt ihrer Festplatte(n) bereits sehr groß sein, so kann man die Erstreplikation auch auf Basis eines Mediums vornehmen, etwa einer transportablen Festplatte. Danach kann die Hyper-V-Replikation dann die Unterschiede (Delta) replizieren.

Live Migration

Die Live Migration kam in Hyper-V erst recht spät hinzu. Während sie ursprünglich schon im ersten Release mit Windows Server 2008 geplant war, hat es noch etwa anderthalb Jahre länger bis zum Nachfolger 2008 R2 gedauert,  bis das Verschieben einer VM von einem Host auf einen anderen ohne Funktionsunterbrechung möglich war. Nun macht Microsoft den nächsten Schritt.

In der aktuellen Fassung von Hyper-V ist für die Live Migration ein Cluster nötig. Das erfordert auf jeden Fall ein SAN und darüber hinaus eine clusterfähige Version des Betriebssystems, also entweder den spartanischen (und im Support eingeschränkten) kostenlosen Hyper-V Server 2008 R2 oder aber die teure Enterprise oder Datacenter Edition von Windows. In Windows Server “8” wird das Cluster-Erfordernis entfallen: Die Live Migration wird auch zwischen “einzeln stehenden” Hostservern funktionieren, und als Ablage für die virtuellen Maschinen kommt auch eine Netzwerkfreigabe (ein CIFS-Share) in Betracht – oder gleich die lokalen Platten des Hostsystems. Um es deutlich zu sagen: Für die Live Migration in Windows Server “8” wird man kein gemeinsames Speichermedium an den Hosts mehr benötigen. Natürlich erfordert dies entsprechend leistungsfähige Hardware und ein performantes Netzwerk, denn die Speicherdaten müssen so von einem Host zum anderen gelangen. Allerdings ist Microsoft derzeit der einzige Virtualisierungsanbieter, der VM-Übertragungen im laufenden Betrieb ohne gemeinsamen Speicher ermöglicht (wenn auch derzeit nur in Pre-Beta-Fassung).

Ebenso ermöglicht potente Hardware im neuen Windows-Server auch eine höhere Zahl gleichzeitiger Live Migrations. Um das Abbruchrisiko einzuschränken, kann man die Zahl paralleler Übertragungen pro Host einschränken.

Cluster

Für viele Zwecke bleibt trotz Replikation und verbesserter Live Migration das Clustering von Host-Servern die Methode der Wahl, denn nur sie ermöglicht das automatisierte Fail-over in unerwarteten Fehlersituationen. Neben den deutlich erweiterten Limits, die wir im ersten Teil unserer Artikelserie vorgestellt haben – bis zu 64 Server pro Cluster, bis zu 4000 gleichzeitig aktive VMs – steht hier vor allem die Datenablage auf klassischen Dateifreigaben im Vordergrund. Sie erlaubt hochverfügbare Installationen ohne SANs. Gleichzeitig hat Microsoft einiges getan, um Cluster-Konstrukte noch flexibler zu machen. Die Hardware der Hosts darf sich noch mehr voneinander unterscheiden als bislang bereits.

Eine weitere Serverkomponente ist auch für kleinere Virtualisierungsumgebungen interessant. Im neuen Server-Windows ist das iSCSI-Target enthalten, das Microsoft für Windows Server 2008 R2 erst vor kurzem als kostenlosen und unterstützten Aufsatz freigegeben hat.

Verwandte Beiträge:

1. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 4
   Hier als letzter Teil unserer kleinen Artikelserie zu Hyper-V 3.0...
2. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 2
   Diese zweite Folge unserer Artikelserie zu Hyper-V 3.0 konzentriert sich...
3. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 1
   Eine der Funktionen, die Microsoft im kommenden Windows Server “8”...