Oktober 2008 Oktober 2008
Virtualisierung: Einführung in Hyper-V in Windows Server 2008
Die Einführung von Hyper-V macht die Virtualisierung zu einer noch überzeugenderen Lösung für IT-Umgebungen. Verschaffen Sie sich einen Überblick über den heutigen Virtualisierungsmarkt, und sehen Sie selbst, wie Hyper-V die Verwaltbarkeit, Zuverlässigkeit und Sicherheit der Virtualisierung verbessert. Rajiv Arunkundram
Virtualisierung: Verwalten Sie Ihre virtuellen Umgebungen mit VMM 2008
System Center Virtual Machine Manager bietet eine konsolidierte Schnittstelle für die Verwaltung Ihrer virtuellen Infrastruktur. In der aktuellen Version wurde Unterstützung für Windows Server 2008 Hyper-V sowie für virtuelle VMware-Computer hinzugefügt. Lernen Sie die neuen Features kennen, und verschaffen Sie sich einen Überblick darüber, wie Sie mit VMM Ihre Verwaltungsaufgaben zentralisieren können. Edwin Yuen
Virtualisierung: Erste Schritte mit Microsoft Application Virtualization
Mit Microsoft Application Virtualization (App-V) können Sie virtualisierte Desktops auf Clientsystemen in Ihrer gesamten Organisation einrichten. Dies vereinfacht die Systemverwaltung und befreit die Mitarbeiter von ihrem Schreibtisch. Sehen Sie selbst, wie App-V arbeitet, und entdecken Sie, wie Sie diese Lösung in Ihrer Organisation bereitstellen können. Anthony Kinney
Virtualisierung: Gewährleisten hoher Verfügbarkeit für Hyper-V
Die Konsolidierung von Servern auf einer geringeren Anzahl physischer Computer bietet enorme Vorteile, aber die hohe Verfügbarkeit der Systeme muss sorgfältig geplant werden. Hier erfahren Sie, wie Sie mittels Windows Server 2008-Failoverclustering hohe Verfügbarkeit für Ihre virtuellen Hyper-V-Computer erzielen können. Steven Ekren
Virtualisierung: Sicherung und Notfallwiederherstellung für die Servervirtualisierung
Virtualisierung bringt erhebliche Änderungen für die Notfallwiederherstellung mit sich. Hier wird eine Einführung in die Verwendung der Microsoft-Virtualisierungsplattform in Ihrem Notfallwiederherstellungsplan geboten, und es werden Optionen und Überlegungen zur Sicherung und Wiederherstellung mittels Windows Server 2008 Hyper-V erörtert. Adam Fazio
Virtualisierung: Wichtige Tools zum Planen Ihrer virtuellen Infrastruktur
Ist Ihre Infrastruktur bereit für die Virtualisierung? Das Microsoft Assessment and Planning Toolkit, ein Tool für die netzwerkweite Bewertung der Infrastruktur, kann Ihnen helfen, Ihre IT-Infrastruktur besser zu verstehen und zu bestimmen, ob Ihre Systeme für die Aktualisierung oder die Migration zu verschiedenen Technologien einschließlich Virtualisierung bereit sind. Jay Sauls und Baldwin Ng
Columns
Mitteilung der Redaktion: Schöne neue Welt der Virtualisierung: | Briefe: Leser sagen ihre Meinung: | Toolbox: Neue Produkte für IT-Experten:
SQL – Fragen und Antworten: Große Transaktionsprotokolle, Verwendungsfälle für repair und mehr: In dieser Ausgabe beantwortet Paul Randal Fragen zur Sicherung und Wiederherstellung, erläutert die Unterschiede zwischen Protokollversand und Datenbankspiegelung und erklärt, warum die repair-Funktion nur als letzter Ausweg verwendet werden sollte.Paul S. Randal | Schwerpunkt Dienstprogramme: Offline Virtual Machine Servicing Tool: Virtuelle Computer, die offline gespeichert sind, erhalten nicht automatisch die notwendigen Aktualisierungen, mit denen ihre Sicherheit und Kompatibilität gewährleistet wird. Dies kann ein Risiko für Ihre gesamte IT-Umgebung darstellen. Erfahren Sie, wie Sie mit dem kostenlosen Offline Virtual Machine Servicing Tool den Prozess für die Aktualisierung virtueller Computer automatisieren können.Peter Skjøtt Larsen und Suveen Kumar Reddy Vuppala | Windows PowerShell: Leistungsfähige Profile: Haben Sie sich je gewünscht, dass Windows PowerShell mit einer auf Ihre Anforderungen zugeschnittenen Arbeitsumgebung gestartet wird? Don Jones zeigt Ihnen, wie Sie die Windows PowerShell-Shell mithilfe von Profilen anpassen können.Don Jones
Hey, Scripting Guy!: Berühmte letzte Worte: Die Scripting Guys sprechen über Sokrates und befassen sich noch einmal mit dem Abfragen von XML-Dateien. Dieses Mal ist die XML-Datei aber so strukturiert, dass nicht untergeordnete Knoten verwendet werden, sondern zusätzliche Eigenschaftswerte als Attribute konfiguriert sind.Die Scripting Guys von Microsoft | Die Desktopdateien: Anpassen der Windows-Bereitstellungsdienste: Wes Miller befasst sich mit den Windows-Bereitstellungsdiensten und zeigt, wie Sie diese anpassen und konfigurieren können, um die Anforderungen Ihrer Organisation zu erfüllen.Wes Miller | Sicherheit auf dem Prüfstand: Neubetrachtung der 10 unveränderlichen Gesetze zur Sicherheit, Teil 1: Es ist etwa acht Jahre her, seit die „10 unveränderlichen Gesetze zur Sicherheit“ erstmalig veröffentlicht wurden, und viel hat sich seitdem geändert. Diesen Monat beginnt Jesper Johansson mit einer dreiteiligen Reihe, in der er die Gesetze aus heutiger Sicht analysiert, um festzustellen, ob sie weiterhin gültig sind.Jesper M. Johansson
Berichte aus der Praxis: Farbbarcode mit hoher Kapazität: Gavin Jancke hat einen neuen Barcode entwickelt, bei dem Farben und Dreiecke verwendet werden und der eine viel höhere Datenkapazität als traditionelle Schwarzweißbarcodes aufweist. Sehen Sie sich diese leistungsfähigen Farbbarcodes einmal näher an.Gavin Jancke | Windows Confidential: Arbeiten Sie härter, nicht intelligenter: Raymond Chen befasst sich mit der verzerrten Beziehung zwischen Bugs und Fehlern und erklärt, warum es wichtig ist, dass Programmierer nicht nur Ergebnisse liefern, sondern auch leiden.Raymond Chen


Virtualisierung
Einführung in Hyper-V in Windows Server 2008
Rajiv Arunkundram
Auf einen Blick:
  • Was ist Virtualisierung?
  • Drei Virtualisierungsarchitekturen
  • Mikrokernel-Hypervisor oder monolithischer Hypervisor
  • Vorgänge bei Hyper-V

Inhalt
Der Markt für die Servervirtualisierung
Funktionsweise der Servervirtualisierung
Arten von Virtualisierungslösungen
Windows Hypervisor
Die übergeordnete Partition
Gerätefreigabearchitektur
Integrationskomponenten
Der Funktionsumfang von Hyper-V
Skalierbarkeit
Hohe Verfügbarkeit
Sicherheit
Verwaltbarkeit
Zusammenfassung
In letzter Zeit wird viel über die Virtualisierung gesprochen, wobei es meist um die Servervirtualisierung geht. Dies ist einer der aufregendsten Trends in der Branche, und noch dazu ein Trend, der das Potenzial hat, das Paradigma über die Bereitstellung von IT-Systemen in den kommenden Jahren zu verändern. Aber die Servervirtualisierung wird nicht nur die Denkweise von IT-Administratoren und -Architekten zu Servern und zur Systemnutzung ändern, sondern sie wird sich auch auf die Prozesse und Tools auswirken, mit denen eine immer dynamischere Umgebung verwaltet wird.
Eigentlich ist die Virtualisierung gar nicht mehr so neu, aber die Technologie entwickelt sich immer noch weiter. Selbst der Begriff an sich hat für unterschiedliche Personen immer noch eine unterschiedliche Bedeutung. Ganz allgemein wird bei der Virtualisierung eine Schicht des Technologiestapels von der nächsten Schicht abstrahiert, beispielsweise der Speicher vom Server oder das Betriebssystem von den Anwendungen. Die Abstraktion der verschiedenen Schichten ermöglicht wiederum die Konsolidierung und eine bessere Verwaltbarkeit.
Das Konzept der Virtualisierung greift für Speicher, Netzwerke, Server, Anwendungen und Zugriff. Bei Speichern und Netzwerken besteht das Ziel der Virtualisierung darin, eine Reihe unterschiedlicher Geräte zusammenzufassen, sodass der gesamte Ressourcenpool als eine Einheit erscheint und agiert. So können Sie beispielsweise eine 40-TB-Speicherlösung anstelle einer Gruppe von zwanzig Speichergeräten mit je 2 TB konfigurieren. Bei anderen Komponenten verhält sich die Virtualisierung dagegen genau umgekehrt: aus einem einzelnen System werden scheinbar mehrere Systeme gebildet. Das häufigste Beispiel hierfür ist die Servervirtualisierung, bei der mehrere Betriebssysteminstanzen und Umgebungen auf einem einzigen Server gehostet werden.
Microsoft hat die Virtualisierung auf mehreren Ebenen in Angriff genommen und mit Lösungen für Servervirtualisierung, Anwendungsvirtualisierung, Präsentationsvirtualisierung und Desktopvirtualisierung vom Desktop auf das Datencenter erweitert. Der rote Faden ist hierbei die Verwaltung mit Microsoft System Center. In diesem Artikel konzentriere ich mich auf die Servervirtualisierungskomponente und speziell darauf, wie Hyper-V, eines der wichtigsten Features von Windows Server 2008, in die Gleichung für ein dynamisches Datencenter passt.

Der Markt für die Servervirtualisierung
Zuerst sollten wir die derzeitigen Gegebenheiten betrachten und den allgemeinen Markttrend untersuchen. In Abhängigkeit von den Forschungsergebnissen, die Sie lesen, schätzen einige Analytiker, dass 5 % bis 9 % aller derzeit verkauften physischen Server als Virtualisierungshosts verwendet werden. Dies erscheint Ihnen vielleicht als großer Anteil an Systemen in einem Markt, in dem mehr als neun Millionen physische Server pro Jahr ausgeliefert werden. Aber eines ist sicher: Es gibt immer noch eine riesige Marktchancen, da immer mehr Kunden sich mit der Virtualisierung vertraut machen und ihren Einsatz planen.
Beachten Sie die Stellen, an denen die Virtualisierung auf Akzeptanz stößt. Unternehmenskunden haben sicherlich eine Vorreiterrolle gespielt, weil sie als erste die Virtualisierung testeten und einsetzen. Es gibt jedoch auch kleine und mittlere Unternehmen, die die Virtualisierung implementieren. Die Akzeptanz der Virtualisierung erstreckt sich über verschiedene Arten von Arbeitsauslastungen, von Geschäftsanwendungen über die Verwaltung bis hin zum Web und zu E-Mails.
Warum sorgt die Virtualisierung also jetzt für so viel Aufsehen? Dabei spielen einige Faktoren eine Rolle, nicht zuletzt der richtige Zeitpunkt. Einige wichtige Branchenfaktoren sind gleichzeitig aufgetreten, was die Akzeptanz der Virtualisierung kräftig förderte. Diese Branchenfaktoren umfassen die Umstellung auf 64-Bit-Computing, Mehrkernprozessoren und sogar den Wunsch nach nachhaltiger Computernutzung, um die Systemnutzung zu verbessern.
Systeme werden immer größer, und sie erfordern eine Technologie wie die Virtualisierung, um ihre Leistungsfähigkeit voll ausspielen zu können. Aber auch wenn es nicht zu leugnen ist, dass die Computerkerntechnologie (und das Mooresche Gesetz) stets die Nase vorn hatten, weil stets mehr Verarbeitungskapazität bereitgestellt wurde als die Systeme nutzen konnten, sind wir uns nun auch der Umweltauswirkungen, des Energieverbrauchs und der Kühlkosten bewusster.
Alle diese Faktoren und dazu das einfache Argument der Rendite bei Einsatz der Virtualisierung sollten zusammengenommen die Einführung der Virtualisierung in großen und kleinen Unternehmen gleichermaßen beschleunigen. Wir, die IT-Experten, können davon ausgehen, dass alle Hauptbeteiligten in den kommenden Jahren weiter in diese Technologie investieren werden, um die Features noch weiter zu optimieren.

Funktionsweise der Servervirtualisierung
Bei der Servervirtualisierung werden im Grunde auf einem einzelnen physischen Gerät zwei oder mehr Betriebssystemumgebungen installiert (und gleichzeitig ausgeführt). Diese Umgebungen können voneinander abweichen und unterschiedliche Identitäten, Anwendungsstapel usw. nutzen. Hyper-V gehört zu den Virtualisierungstechnologien der nächsten Generation, die auf einem 64-Bit-Hypervisor beruhen und dabei zuverlässige und skalierbare Plattformfunktionen bieten. Gemeinsam mit System Center bietet Hyper-V eine einzelne Gruppe integrierter Verwaltungstools sowohl für physische als auch für virtuelle Ressourcen.
Alle diese Punkte tragen dazu bei, die Kosten zu senken, die Nutzung zu verbessern, die Infrastruktur zu optimieren und die Bereitstellung neuer Server zu beschleunigen. Um Ihnen einen Einblick in den Aufbau von Hyper-V zu geben, betrachten wir zunächst die verschiedenen Arten von Virtualisierungslösungen.

Arten von Virtualisierungslösungen
Bei der Servervirtualisierung kommen im Prinzip drei allgemeine Architekturen zum Einsatz, wie in Abbildung 1 gezeigt. Die grundlegenden Unterschiede hängen mit der Beziehung zwischen der Virtualisierungsschicht und der physischen Hardware zusammen. Die Virtualisierungsschicht ist die Softwareschicht, die als VMM bezeichnet wird (Virtual Machine Monitor, nicht zu verwechseln mit Virtual Machine Manager). Diese Schicht bietet die Möglichkeit, mehrere isolierte Instanzen zu erstellen, die dieselben zugrunde liegenden Hardwareressourcen nutzen.
Abbildung 1 Die drei Architekturen der Virtualisierung (zum Vergrößern auf das Bild klicken)
Die Typ-2-VMM-Architektur findet man beispielsweise bei JVMs (Java Virtual Machine). Hier besteht das Ziel der Virtualisierung darin, eine Laufzeitumgebung zu erstellen, in der der Prozess eine Reihe von Anweisungen ausführen kann, ohne auf das Hostsystem zurückgreifen zu müssen. In diesem Fall wirkt sich die Isolierung auf die verschiedenen Prozesse aus, und eine einzelne Anwendung kann auf verschiedenen Betriebssystemen ausgeführt werden, ohne dass Betriebssystemabhängigkeiten zu Schwierigkeiten führen. Die Servervirtualisierung fällt nicht in diese Kategorie.
Typ-1-VMMs und Hybrid-VMMs sind heutzutage am weitesten verbreitet. Der Hybrid-VMM ist eine Phase, in der der VMM parallel zum Hostbetriebssystem ausgeführt wird und dazu beiträgt, virtuelle Computer darauf aufzubauen. Hybrid-VMMs sind beispielsweise Microsoft Virtual Server, Microsoft Virtual PC, VMware Workstation und VMware Player. Diese Arten von Lösungen eignen sich hervorragend für ein Clientszenario, in dem virtuelle Computer nur zeitweise ausgeführt werden. Die VMMs sorgen für eine erhebliche Mehrbelastung und sind daher für ressourcenintensive Arbeitsauslastungen nicht geeignet.
In einer Typ-1-VMM-Architektur wird die VMM-Schicht direkt auf der Hardware ausgeführt. Dies wird häufig als Hypervisorschicht bezeichnet. Diese Architektur wurde ursprünglich in den 1960er Jahren von IBM für Mainframesysteme entwickelt und wurde vor kurzem für x86/x64-Plattformen mit verschiedenen Lösungen zur Verfügung gestellt, unter anderem mit Windows Server 2008 Hyper-V.
Es sind Lösungen erhältlich, bei denen Hypervisor in die Firmware eingebettet ist. Dies ist jedoch nur eine Verpackungsoption, die die zugrunde liegende Technologie nicht im eigentlichen Sinn ändert.
Bei Typ-1-VMMs gibt es im Grunde zwei Hauptmöglichkeiten zum Aufbauen der Hypervisorlösungen: als Mikrokernel-Hypervisor oder als monolithischer Hypervisor. Wie aus Abbildung 2 hervorgeht, sind beide Vorgehensweisen echte Typ-1-VMMs, bei denen der Hypervisor direkt auf der physischen Hardware installiert ist.
Abbildung 2 Die beiden Möglichkeiten zum Aufbauen von Hypervisorlösungen (zum Vergrößern auf das Bild klicken)
Beim monolithischen Hypervisor wird der Hypervisor/der VMM in einer einzigen Schicht gehostet, die auch die meisten erforderlichen Komponenten enthält, z. B. den Kernel, die Gerätetreiber und den E/A-Stapel. Dieses Verfahren kommt bei Lösungen wie VMware ESX und bei traditionellen Mainframesystemen zum Einsatz.
Der Mikrokernel-Hypervisor umfasst einen sehr dünnen, spezialisierten Hypervisor, der ausschließlich die zentralen Aufgaben der Partitionsisolierung und der Speicherverwaltung ausführt. Diese Schicht enthält keinen E/A-Stapel und keine Gerätetreiber. Diese Methode wird bei Hyper-V verwendet. In dieser Architektur befinden sich der Virtualisierungsstapel und die hardwarespezifischen Gerätetreiber in einer speziellen Partition, die als übergeordnete Partition bezeichnet wird.

Windows Hypervisor
Um die gründliche Trennung zwischen mehreren Betriebssystemen sicherzustellen, werden virtuelle Prozessoren, Speicher, Zeitgeber und Interruptcontroller erstellt. Die Betriebssysteme nutzen diese virtuellen Ressourcen auf dieselbe Weise wie ihre physischen Gegenstücke.
Windows Hypervisor, Teil von Hyper-V, führt die folgenden Aufgaben aus:
  • Erstellen logischer Partitionen.
  • Verwalten der Speicher- und Prozessorplanung für Gastbetriebssysteme.
  • Bereitstellen von Methoden zur Virtualisierung der Ein- und Ausgabe und zur Kommunikation zwischen den Partitionen.
  • Durchsetzen der Speicherzugriffsregeln.
  • Durchsetzen der Richtlinie für die CPU-Nutzung.
  • Bereitstellen einer einfachen programmgesteuerten Schnittstelle (auch als Hypercalls bezeichnet).
Windows Hypervisor fungiert als Mikrokernel-Hypervisor und ist daher relativ klein (kleiner als 1 MB). Dieser minimale Platzbedarf trägt dazu bei, die Sicherheit des gesamten Systems zu erhöhen.
Eine der Anforderungen beim Ausführen von Hyper-V ist die Nutzung eines x64-Systems mit Intel VT- oder AMD-V-Technologien. Die x64-Technologie ermöglicht den Zugriff auf einen größeren Adressraum und unterstützt Systeme mit mehr Speicher, sodass eine größere Anzahl virtueller Computer auf einem einzigen Hostsystem ausgeführt werden kann. Intel VT und AMD-V sind hardwaregestützte Virtualisierungslösungen, die eine ultraprivilegierte Schicht in der Ringarchitektur bieten, mit der die Ausführungsumgebung des Hypervisors vom restlichen System getrennt gehalten wird. Außerdem kann Hyper-V damit ein unverändertes Gastbetriebssystem ausführen, ohne dass beträchtliche Leistungseinbußen entstehen.

Die übergeordnete Partition
Hyper-V besteht aus einer übergeordneten Partition, die im Grunde ein virtueller Computer mit besonderem oder privilegiertem Zugriff ist. Dies ist der einzige virtuelle Computer mit Direktzugriff auf Hardwareressourcen. Alle anderen virtuellen Computer, die als Gastpartitionen bezeichnet werden, wickeln den Gerätezugriff über die übergeordnete Partition ab.
Die Existenz der übergeordneten Partition ist relativ transparent. Wenn Sie beginnen, Hyper-V zu installieren, müssen Sie zuerst Windows Server 2008 x64 Edition auf dem physischen System installieren. Anschließend öffnen Sie Server-Manager. Aktivieren Sie dort die Hyper-V-Rolle, und starten Sie das System neu. Sobald das System neu gestartet ist, wird zuerst Windows Hypervisor geladen, und dann wird der restliche Stapel konvertiert, um als übergeordnete Partition zu dienen.
Die übergeordnete Partition fungiert als Eigentümer für Tastatur, Maus, Videoanzeige und andere Geräte, die am Hostserver angeschlossen sind. Sie besitzt keine direkte Kontrolle über die vom Hypervisor verwendeten Zeitgeber und Interruptcontroller.
Die übergeordnete Partition enthält einen WMI-Anbieter (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation), der die Verwaltung aller Aspekte der virtualisierten Umgebung vereinfacht, sowie einen Virtualisierungsstapel, der hardwarebezogene Aufgaben im Auftrag der untergeordneten Partitionen ausführt. Darüber hinaus befinden sich sämtliche IHV-Treiber (Independent Hardware Vendor, unabhängiger Hardwarehersteller), die für die Hostsystemhardware benötigt werden, in der übergeordneten Partition, und auch alle Treiber, die für Windows Server 2008 x64 Edition erstellt werden, arbeiten in der übergeordneten Partition.

Gerätefreigabearchitektur
Eine der innovativen Architekturkomponenten in Hyper-V ist die neue Gerätefreigabearchitektur, die emulierte und synthetische Geräte in jedem Gastbetriebssystem unterstützt. Die Geräteemulation unterstützt ältere Betriebssysteme mit Gerätetreibern, die für frühere Generationen der Hardware vorgesehen waren. Hyper-V enthält beispielsweise eine Emulation des Intel 21140-Netzwerkadapters, der in Zeiten älterer Betriebssysteme als DEC 21140-Netzwerkadapter bezeichnet wurde.
In der Regel ist die Geräteemulation langsam, nicht ohne Schwierigkeiten zu erweitern und nicht gut zu skalieren. Aber die Emulation ist immer noch wichtig, weil Sie damit die meisten x86-Betriebssysteme auf Hyper-V ausführen können. Die Virtualisierung entwickelt sich derzeit von einer Nischentechnologie, die hauptsächlich zum Testen und Entwickeln genutzt wurde, zu einer unentbehrlichen Technologie für Produktionsumgebungen, weshalb die Benutzer eine höhere Leistung brauchen, um größere Arbeitsauslastungen verwenden zu können. Emulierte Geräte erfüllen diesen wachsenden Bedarf nicht mehr.
Eine alternative Lösung ist die Verwendung synthetischer Hyper-V-Geräte. Synthetische Geräte sind virtuelle Geräte, die direkt physischen Geräten zugeordnet sind. Im Unterschied zu emulierten Geräten emulieren synthetische Geräte keine veraltete Hardware. Mit dem Hyper-V-Hardwarefreigabemodell können unterstützte Gastbetriebssysteme direkt mit synthetischen Geräten interagieren, auch wenn diese keine physischen Gegenstücke besitzen. Diese Betriebssysteme nutzen VSCs (Virtual Service Client, virtueller Dienstclient), die als Gerätetreiber im Gastbetriebssystem fungieren.
Statt direkt auf physische Hardware zuzugreifen, greifen die VSCs über den VMBus, einen schnellen, speicherinternen Bus, auf VSPs (Virtual Service Provider, virtueller Dienstanbieter) in der übergeordneten Partition zu. Die VSPs in der übergeordneten Partition verwalten dann den Zugriff auf die zugrunde liegende physische Hardware, wie in Abbildung 3 dargestellt. Ein wichtiger Vorteil synthetischer Geräte besteht darin, dass ihre Leistung über den VMBus näher an der Leistung nicht virtualisierter Hardwaregeräte liegt.
Abbildung 3 VSCs greifen über den VMBus auf VSPs zu, die wiederum den Zugriff auf die zugrunde liegende physische Hardware verwalten (zum Vergrößern auf das Bild klicken)

Integrationskomponenten
Hyper-V sorgt dafür, dass die verschiedenen Instanzen, die auf einem Computer ausgeführt werden, streng voneinander getrennt sind. Die Integrationskomponenten von Hyper-V ermöglichen die Interaktion zwischen dem Gastbetriebssystem und dem Hostbetriebssystem und stellen einige zusätzliche Funktionen für unterstützte Gastbetriebssysteme bereit.
Die Hyper-V-Integrationskomponenten unterstützen die folgenden Features:
  • Zeitsynchronisierung
  • Volumeschattenkopie-Dienst (Volume Shadow Copy Service, VSS)
  • Taktfunktionen
  • Herunterfahren von Gastcomputern
  • Schlüssel/Wert-Paar-Austausch (für den Zugriff auf die Registrierung eines Gastbetriebssystems)
  • Betriebssystemidentifizierung
Der Funktionsumfang von Hyper-V
Je stärker sich die Virtualisierungsplattform der Handlungsweise physischer Server nähert, desto einfacher wird es natürlich für Organisationen, virtuelle Arbeitsauslastungen bereitzustellen und sich darauf zu verlassen. Meiner Meinung nach gibt es vier Hauptbereiche, in denen Sie die verschiedenen Features der Virtualisierungsplattform sehen können.
Heutzutage liegen die auf Hypervisoren beruhenden Virtualisierungslösungen relativ dicht beieinander, wenn es um die Features und Funktionen geht. Auf dem Weg in die Zukunft werden Aspekte wie die Gesamtkosten und die Benutzerfreundlichkeit zu wichtigen Unterscheidungsmerkmalen. Für die Verwaltungslösungen werden weiterhin Investitionen und Entwicklungsarbeit geleistet, damit wir der Vision einer dynamischen IT-Umgebung näher kommen, in der die Infrastruktur so flexibel ist, dass sie sich an die Anforderungen des Unternehmens anpasst, und in der die Automatisierung und Verwaltung mit Modellen und Richtlinien vorangebracht werden.

Skalierbarkeit
Dank der Mikrokernel-Hypervisorarchitektur verursacht Hyper-V einen sehr niedrigen CPU-Aufwand, sodass viel Raum zur Virtualisierung der Arbeitsauslastungen bleibt. Mit Hyper-V können die virtuellen Computer leistungsfähige Features und Hardware nutzen, beispielsweise Mehrkerntechnologie, verbesserten Datenträgerzugriff und größeren Speicher, wodurch Hyper-V die Skalierbarkeit und die Leistung der Virtualisierungsplattform erhöht.
In Kombination mit den anderen Funktionen in Windows Server 2008 sind Sie mit Hyper-V in der Lage, den Großteil der Arbeitsauslastungen (sowohl 32-Bit- als auch 64-Bit-Arbeitsauslastungen) auf einem einzigen System zu konsolidieren. Sie können damit die Umsetzung der 64-Bit-Technologie durch die fortgesetzte Unterstützung von 32-Bit-Arbeitsauslastungen ergänzen, die bereits in Ihrer Umgebung verwendet werden.
Die Tatsache, dass Hyper-V ein 64-Bit-Hostsystem mit hardwaregestützter Virtualisierung erfordert, hilft sicherzustellen, dass das Hostsystem Zugriff auf einen großen Pool von Speicherressourcen erhält. Hyper-V kann bis zu 1 TB Speicher auf dem Host unterstützen und bis zu 64 GB Speicher auf jedem virtuellen Computer. Dies ist ein wichtiges Argument beim Planen der Virtualisierung speicherintensiver Arbeitsauslastungen wie Exchange Server und SQL Server.
Hyper-V unterstützt außerdem bis zu 16 logische Prozessoren auf dem Hostsystem, wodurch sich Hyper-V auf die meisten handelsüblichen Systeme mit zwei oder vier Sockets und mehreren Kernen skalieren lässt. Darüber hinaus können Sie einen virtuellen Computer mit bis zu vier virtuellen Prozessoren erstellen, um Arbeitsauslastungen zu unterstützen, die Mehrprozessorfunktionen erfordern oder nutzen.
Durch die Serverkonsolidierung mit Hyper-V erhalten diese Server auch eine stabile Netzwerkunterstützung, beispielsweise Richtlinien für VLAN, Netzwerkadressübersetzung (Network Address Translation, NAT) und Netzwerkzugriffsschutz (Network Access Protection, NAP) (Quarantäne). Als Feature von Windows Server 2008 arbeitet Hyper-V problemlos mit anderem Windows Server-Features wie BitLocker und Windows PowerShell zusammen.

Hohe Verfügbarkeit
Die hohe Verfügbarkeit ist ein Szenario, in dem Hyper-V und Hostclusteringfunktionen zusammenarbeiten, um die Geschäftskontinuität und die Anforderungen hinsichtlich der Notfallwiederherstellung zu erfüllen. Geschäftskontinuität ist die Möglichkeit, sowohl die geplante als auch die ungeplante Ausfallzeit zu minimieren. Das umfasst die Zeit, die bei Routineaufgaben wie Wartung und Sicherung sowie unerwarteten Ausfällen verloren geht.
Die Notfallwiederherstellung ist eine wichtige Komponente der Geschäftskontinuität. Naturkatastrophen, Angriffe und sogar einfache Konfigurationsprobleme, wie etwa Softwarekonflikte, können Dienste und Anwendungen lähmen, bis Administratoren die Probleme gelöst haben und sämtliche Daten wiederhergestellt wurden. Eine zuverlässige Strategie für Geschäftskontinuität und Notfallwiederherstellung muss minimalen Datenverlust und leistungsfähige Remoteverwaltungsfunktionen bieten.
Die hohe Verfügbarkeit gliedert sich in drei verschiedene Kategorien: geplante Ausfallzeit, ungeplante Ausfallzeit und Sicherungen. Der Schutz für die geplante Ausfallzeit ist in der Regel erforderlich, wenn virtuelle Computer vom Hostsystem getrennt werden müssen, sodass Sie die Hardwarewartung durchführen oder Patches für das Hostsystem oder die Virtualisierungsplattform anwenden können (was möglicherweise einen Neustart erfordert).
Die meisten Organisationen haben Fenster für die geplante Wartung festgelegt. In diesem Fall versuchen Sie, den Zeitraum zu minimieren oder ganz zu beseitigen, in dem die virtuellen Computer nicht verfügbar sind, während das Hostsystem zu Wartungszwecken heruntergefahren ist. Mit dem Quick Migration-Feature können Sie einen gerade ausgeführten virtuellen Computer von einem physischen Knoten in Sekundenschnelle auf einen anderen Knoten verschieben. Folglich können Sie Ihre virtuellen Computer für die Produktion verfügbar halten, während Sie gleichzeitig Wartungsarbeiten am ursprünglichen Host durchführen. Nach Abschluss der Wartung können Sie die virtuellen Computer mittels Quick Migration zurück auf das ursprüngliche Hostsystem verschieben.
Ungeplante Ausfallzeit sind Ausfallzeiten, die nicht vorhersehbar sind. Hierzu zählen beispielsweise Naturkatastrophen oder auch so einfache Dinge wie das unbeabsichtigte Ziehen eines Netzkabels, wodurch ein Server deaktiviert wird. So unwahrscheinlich das klingt: Im Verlauf der Jahre habe ich viele Administratoren bei Tech•Ed, VMworld und anderen Konferenzen getroffen, die so manches darüber erzählen können, wie ein Server unbeabsichtigt von einem Kollegen ausgeschaltet wurde.
Mit Hyper-V können Sie einen Hostcluster für die verschiedenen Hostsysteme einrichten und alle virtuellen Computer als Clusterressourcen konfigurieren, für die dann ein Failover auf ein anderes System durchgeführt wird, falls einer der Hosts ausfällt. In der Zwischenzeit können Sie mit der Funktion für Mehrfachstandortclustering in Windows Server 2008 einen geografisch verteilten Cluster einrichten. Sollte Ihr primäres Datencenter ausfallen, haben Sie damit die Möglichkeit, die verschiedenen virtuellen Computer in einem Remotedatencenter wiederherzustellen.
Dies trägt auch zum Schutz Ihrer sämtlichen Zweigstellen bei. Einer der Vorteile bei der Unterstützung ungeplanter Ausfallzeiten mit Hyper-V besteht darin, dass das Gastbetriebssystem keine Rolle spielt. So können Sie die Vorteile der hohen Verfügbarkeit auch auf virtuelle Linux-Computer und auf ältere Versionen von Windows Server ausdehnen und diese Systeme ähnlich schützen und wiederherstellen.
Bei ungeplanter Ausfallzeit ist zu beachten, dass die Wiederherstellung dem Ausschalten und Neustarten des Systems entspricht. Alle Statusinformationen gehen damit verloren. Je nach Arbeitsauslastung, die auf dem virtuellen Computer ausgeführt wird, kann dies u. U. zu Problemen führen. Deswegen ist es wichtig, die Sicherung im Kontext hoher Verfügbarkeit zu betrachten.
Mit Hyper-V können Sie Sicherungen von jedem virtuellen Computer anfertigen oder mit VSS konsistente Sicherungen von allen VSS-fähigen virtuellen Computern erstellen, während sie noch ausgeführt werden. Mit VSS können Sie die Durchführung von Sicherungen in bestimmten Intervallen einrichten, ohne dass sich diese Sicherungen auf die Verfügbarkeit der Produktionsarbeitsauslastungen auswirken. Gleichzeitig können Sie für einen fortlaufenden Sicherungsplan sorgen, mit dem Sie den Systemzustand im Falle einer ungeplanten Ausfallzeit problemlos wiederherstellen können. Weitere Informationen zu Hochverfügbarkeitslösungen mit Hyper-V finden Sie im Artikel „Gewährleisten hoher Verfügbarkeit für Hyper-V“ von Steven Ekren in dieser Ausgabe des TechNet Magazins (technet.microsoft.com/magazine/cc837977).

Die Mikrokernel-Hypervisorarchitektur soll die Angriffsfläche minimieren und die Sicherheit verbessern, insbesondere wenn Hyper-V als Server Core-Rolle implementiert ist. Server Core ist eine Installationsoption von Windows Server 2008. Der Hypervisor enthält keine Gerätetreiber und keinen Drittanbietercode, wodurch eine stabilere, dünnere und sicherere Grundlage für das Ausführen virtueller Computer entsteht. Hyper-V bietet außerdem leistungsstarke rollenbasierte Sicherheit mit der Active Directory-Integration. Hyper-V bietet virtuellen Computern die Vorteile von Sicherheitsfeatures auf Hardwareebene, beispielsweise das NX- bzw. XD-Bit (No eXecute/eXecute Disable), sodass die Sicherheit der virtuellen Computer weiter erhöht wird.
Hyper-V hat wie alle Komponenten in Windows Server den Sicherheitsentwicklungszyklus (Security Development Lifecycle, SDL) durchlaufen, und mit umfangreichen Bedrohungsmodellen und Analysen wurde die hohe Sicherheit von Hyper-V als Virtualisierungsplattform gewährleistet. Wenn Sie Hyper-V bereitstellen, beachten Sie in jedem Fall die bewährten Methoden zum Bereitstellen von Windows Server 2008 und auch die bewährten Methoden für Hyper-V. Denken Sie an Active Directory und an Antivirus- und Antimalwarelösungen als Teil Ihres Plans. Nutzen Sie die Funktionen für die delegierte Verwaltung, um sicherzustellen, dass Sie die richtigen Administratorzugriffsberechtigungen für Hyper-V-Hosts verwenden.

Verwaltbarkeit
Eine ein wenig ineffiziente Servernutzung kann rasch zu extrem ineffizienter Nutzung virtueller Computer führen. Dieses Risiko entsteht, weil virtuelle Computer so leicht bereitgestellt werden können. Mit der erhöhten Mobilität virtueller Computer müssen Sie auch genau wissen, wo die einzelnen virtuellen Computer ausgeführt werden, müssen ihre Sicherheitskontexte überwachen und vieles mehr.
Aber mit Hyper-V müssen Sie keine separate Verwaltungsinfrastruktur für Ihre virtuelle Umgebung erstellen. Hyper-V lässt sich in Microsoft-Verwaltungstools, in System Center Virtual Machine Manager und in Microsoft System Center Operations Manager integrieren, ebenso wie in Verwaltungstools von Drittanbietern. Damit können Sie alle Ihre physischen und virtuellen Ressourcen von einer einzigen Konsole aus verwalten. Weitere Informationen zu System Center Virtual Machine Manager 2008 finden Sie im Artikel „Verwalten Sie Ihre virtuellen Umgebungen mit VMM 2008“ von Edwin Yuen in dieser Ausgabe des TechNet Magazins (technet.microsoft.com/magazine/cc836456). Unterdessen erleichtert die Unterstützung für Windows PowerShell die Automatisierung von Aufgaben.
Hyper-V verleiht außerdem virtuellen Computern eine beispiellose Fähigkeit zur Nutzung verfügbarer Hardware. Alle Treiber mit WHQL-Zertifikat (Windows Hardware Quality Lab) können in der übergeordneten Partition ausgeführt werden, sodass Hyper-V eine breite Kompatibilität für Treiber und Geräte bietet. Das bedeutet wiederum, dass Sie die verschiedenen Treiber, die in Ihrer Umgebung ausgeführt werden, viel einfacher verwalten können.

Zusammenfassung
Wie ich bereits erwähnt hatte, ist die Verwaltung ein wichtiger Bereich der Entwicklung und Differenzierung. In den kommenden Jahren werden Sie mit Sicherheit viel Bewegung in diesem Bereich beobachten können. Insgesamt ist dies eine wirklich aufregende Zeit, wenn die Virtualisierung immer gebräuchlicher wird. Wenn Sie Hyper-V noch nicht ausprobiert haben oder einfach weitere Informationen wünschen, besuchen Sie die Website unter microsoft.com/Hyper-V.
Rajiv Arunkundram ist leitender Produktmanager bei Microsoft und befasst sich mit der Servervirtualisierung in der Windows Server-Marketingabteilung. Der Haupttätigkeitsbereich von Rajiv Arunkundram ist die Zusammenarbeit mit Kunden und Partnern, wobei er ihnen die Virtualisierungsstrategie und die Lösungen von Microsoft aus technischer und geschäftlicher Sicht erläutert.


Virtualisierung
Verwalten Sie Ihre virtuellen Umgebungen mit VMM 2008
Edwin Yuen

Dieser Artikel basiert auf einer Vorabversion von Virtual Machine Manager 2008. Änderungen an den in diesem Artikel enthaltenen Informationen sind vorbehalten.
Auf einen Blick:
  • Unterstützung für virtuelle VMware-Computer
  • Skripting und Automatisierung auf Grundlage von Windows PowerShell
  • Konsolidierte, zentralisierte Verwaltung
  • Installationsverfahren

Inhalt
Einführung in Virtual Machine Manager 2008
Integration in System Center
Installation von Virtual Machine Manager 2008
Hinzufügen von VMware-ESX-Hosts
VMotion-Migration
Schlussbemerkung
Letztes Jahr hat Microsoft System Center Virtual Machine Manager 2007 eingeführt – eine Lösung, die eine konsolidierte Schnittstelle für die Verwaltung einer virtuellen Infrastruktur bietet, in der Microsoft Virtual Server 2005 ausgeführt wird. Jetzt wurde parallel zur Veröffentlichung des neuen Hypervisors „Windows Server 2008 Hyper-V“ eine neue Version von Virtual Machine Manager (VMM) veröffentlicht. Mit System Center Virtual Machine Manager 2008 können nicht nur Installationen von Microsoft Virtual Server 2005 und Windows Server 2008 Hyper-V verwaltet werden, sondern die Unterstützung wurde auch auf VMware Infrastructure 3-Server (ESX/ESXi) ausgedehnt. Mit VMM verfügen Sie jetzt über eine integrierte Verwaltungsschnittstelle, die in Verbindung mit Ihrer gesamten virtuellen Infrastruktur funktioniert, einschließlich Microsoft- und VMware-Systemen.
VMM unterstützt alle traditionellen Virtualisierungsaufgaben wie schnelle Bereitstellung virtueller Computer auf Grundlage von Vorlagen und vorkonfigurierten virtuellen Computern, P2V-Konvertierungen (Physical-to-Virtual), eine zentralisierte Bibliothek virtueller Infrastrukturobjekte und sogar V2V-Konvertierung (Virtual-to-Virtual) von virtuellen VMware-Computern (VMX-Konfigurationsdateien und virtuelle VMDK-Datenträger) in virtuelle Hyper-V-Computer. Darüber hinaus wird durch die Integration von VMM in die anderen Produkte der System Center-Familie die Verwaltung physischer und virtueller Systeme über eine einzige Oberfläche ermöglicht.
In diesem Artikel werden VMM 2008 sowie die neuen Features für IT-Administratoren vorgestellt. Dann folgt eine Erläuterung der Anforderungen und Schritte zum Erstellen einer VMM-Installation. Abschließend wird die Verwendung einiger der neuen Features von VMM 2008 näher betrachtet.

Einführung in Virtual Machine Manager 2008
System Center Virtual Machine Manager 2008 ist eine eigenständige Anwendung, die Unternehmen die zentralisierte Verwaltung virtueller Computer ermöglicht, die unter Microsoft Virtual Server 2005 R2 SP1, Windows Server 2008 Hyper-V, Microsoft Hyper-V Server 2008 und auf VMware Infrastructure 3-Servern (ESX/ESXi) ausgeführt werden. Zusammen mit anderen System Center-Produkten bietet VMM eine End-to-End-Verwaltung der physischen und virtuellen Infrastruktur. Abbildung 1 zeigt das architektonische Layout von Virtual Machine Manager.
Abbildung 1 Architektur von System Center Virtual Machine Manager 2008 (zum Vergrößern auf das Bild klicken)
Wie diejenigen unter Ihnen, die mit VMM 2007 vertraut sind, bemerken werden, sind in VMM 2008 wesentlich mehr Schnittstellen zum VMM-System vorhanden (siehe Abbildung 1). Die Felder oben links stellen VMM 2008 und die Felder oben rechts System Center Operations Manager 2007 dar, und die verwalteten Systeme und Schnittstellen sind darunter dargestellt. Die roten Felder zeigen die Verwaltungsserver und die blauen Felder die Systemeingänge. Die grünen Felder sind die verwalteten Hostsysteme mit ihren verwalteten Objekten, die gelb dargestellt sind.
Das rote Feld oben links stellt den Virtual Machine Manager 2008-Serverdienst dar. Darüber befinden sich die verschiedenen Schnittstellen zum Dienst: die Administratorkonsole, die Windows PowerShell-Schnittstelle und das Self-Service-Webportal mit delegiertem Benutzerzugriff. Windows PowerShell bildet die Grundlage für den gesamten Zugriff auf den VMM-Server. Die VMM-Administratorkonsole basiert vollständig auf Windows PowerShell, sodass Sie einfach Windows PowerShell-Skripts erstellen können, die vom VMM-Serverdienst ausgeführt werden. Daher ist Windows PowerShell die öffentliche API für VMM 2008, und jedes Programm kann VMM mithilfe von Windows PowerShell nutzen. Ein hervorragendes Beispiel hierfür ist die Integration von XenDesktop Desktop Delivery Controller von Citrix in Virtual Machine Manager, die vollständig über Windows PowerShell erfolgt.
VMM wird durch eine SQL Server 2005- oder SQL Server 2008-Datenbank unterstützt – entweder eine vollständige Installation oder SQL Server Express Edition, wenn keine andere Datenbank verfügbar ist. Obwohl im Diagramm sowohl Operations Manager als auch Virtual Machine Manager auf SQL Server zeigen, verwenden die beiden Programme keine Datenbank gemeinsam. Sie werden einfach beide unter derselben Version von SQL Server ausgeführt. Die eigentliche Integration zwischen Virtual Machine Manager und Operations Manager erfolgt durch einen Connector, der über VMM verfügbar ist. Dieser Connector ermöglicht es, dass VMM und OpsMgr Daten gemeinsam verwenden, wodurch in OpsMgr Virtualisierungsinformationen und in VMM OpsMgr-Daten für Aktionen bereitgestellt werden.
Die untere Hälfte des Diagramms zeigt die verwalteten Hosts. In VMM 2008 werden nach wie vor virtuelle Computerhosts mit Virtual Server 2005 R2 SP1 und eine zentralisierte Bibliotheksfreigabe verwaltet, so wie es in VMM 2007 der Fall war. Beachten Sie, dass in VMM die Bibliotheksfreigabe kein spezieller Dateispeicher oder Server ist. Sie ist einfach eine Windows-Dateifreigabe, die von VMM verwaltet wird. Sie können die Bibliothek über VMM verwalten oder problemlos Dateien aus der Dateifreigabe kopieren und löschen und VMM die Ermittlung der Änderungen überlassen. Es können auch mehrere Bibliotheken vorhanden sein, was für delegierte Sätze von Servern und für Server in Remotebüros nützlich ist.
Neu in VMM 2008 ist die Möglichkeit, die Hyper-V- und ESX-Hypervisoren zu verwalten. Die Verwaltung von Hyper-V-Hosts erfolgt über die Windows-Remoteverwaltung (Windows Remote Management, WinRM) und die WMI-Schnittstelle (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation). Tatsächlich wird, wenn ein potenzieller Hyper-V-Host hinzugefügt wird, die Hyper-V-Rolle in Windows Server 2008 nicht aktiviert. VMM kann diese Rolle für den Administrator automatisch aktivieren. Dieses Feature ist auch für potenzielle Virtual Server-Hosts für Windows Server 2003-Systeme verfügbar.
Die Verwaltung von VMware VI3-ESX-Hosts erfolgt über einen VMware VirtualCenter-Server. Die VirtualCenter Web Services-API bildet die Schnittstelle zwischen VMM 2008 und VirtualCenter. Daher wird für die VMware-Verwaltung ein VirtualCenter-Server benötigt, und die meisten Unternehmensinstallationen von VMware verfügen über mindestens einen VirtualCenter-Server. Das Einzigartige an VMM 2008 ist die Möglichkeit, mehrere VirtualCenter-Server zu verwalten. Mit VMM können mehrere VirtualCenter-Server hinzugefügt werden, sodass ein Administrator die gesamte VMware-Infrastruktur aggregieren und eine einzige Unternehmensansicht bereitstellen kann, was zuvor nicht möglich war.
Als Bestandteil der System Center-Produktfamilie verwendet VMM die System Center- oder Outlook-artige Oberfläche in der Administratorkonsole. Die VMM-Administratorkonsole ist kein MMC-Snap-In, sondern eine vollständig neue Anwendung, die unter Verwendung von Microsoft .NET Framework auf Windows PowerShell 1.0 aufgebaut ist. Tatsächlich wird, wie bereits erwähnt, durch jede in der Administratorkonsole durchgeführte Aktion der entsprechende Windows PowerShell-Befehl aufgerufen. Somit wird Windows PowerShell für die Benutzeroberfläche verwendet. Alle Befehle oder Funktionen, auf die in der Administratorkonsole zugegriffen wird, können auch über die Befehlszeile in Windows PowerShell aufgerufen werden.
Jeder Assistent der Administratorkonsole besitzt eine Schaltfläche namens „Skript anzeigen“, über die das mit dem auszuführenden Befehl verknüpfte Windows PowerShell-Skript angezeigt wird. Dies bietet einen hervorragenden Ausgangspunkt dafür, die Beziehung zwischen Windows PowerShell und VMM näher kennenzulernen. Neu ist in VMM 2008, dass durch die Aktion „Skript anzeigen“ diese Skripts nun in Editor geöffnet werden, sodass Sie sie problemlos direkt in VMM bearbeiten können. Sie können die bearbeiteten Skripts zudem mühelos speichern und sie dann direkt in der VMM-Bibliothek wiederverwenden – ein weiteres neues Feature von VMM 2008. Die Cmdlets von VMM 2007 wurden für VMM 2008 aktualisiert, einschließlich Unterstützung für VMware-Server. Ein und dieselben Cmdlets funktionieren auf verschiedenen Virtualisierungsplattformen, wodurch Cmdlets wie „New-VM“ sowohl auf Microsoft- als auch auf VMware-Systemen verwendet werden können. IT-Administratoren können daher denselben Satz von Cmdlets zur Verwaltung von Virtual Server-, Hyper-V- und VMware-ESX-Hosts verwenden.
Virtual Machine Manager 2008 wurde dafür entwickelt, IT-Administratoren drei wichtige Vorteile zu bieten:
  • Maximierung der Ressourcen
  • Erzielung höherer Flexibilität
  • Nutzung vorhandener Fähigkeiten
Diese Vorteile beruhen auf verschiedenen Features und Funktionen. VMM hilft Ihnen durch Integration der Verwaltung Ihrer gesamten virtuellen Infrastruktur – unabhängig von Hypervisor – bei der Maximierung Ihrer Ressourcen. Durch die Integration von Microsoft- und VMware-Systemen bietet VMM 2008 eine einzige Ansicht aller Hosts und virtuellen Computer (siehe Abbildung 2) und ermöglicht Administratoren, ihre Systeme nach Parametern wie Host, Betriebssystem, Besitzer, Hinzufügedatum usw. zu filtern und anzuzeigen.
Abbildung 2 Die VMM-Konsole zeigt die integrierte Microsoft- und VMware- Verwaltung (zum Vergrößern auf das Bild klicken)
VMM unterstützt die Maximierung der Systemressourcen auch durch einfache Serverkonsolidierung mit Konvertierungen wie P2V und V2V. Mit P2V können Sie Ihre vorhandenen physischen Computer in virtuellen Computern konsolidieren, ohne diese Computer neu installieren zu müssen. Dies ist insbesondere beim Konvertieren von Computern von Nutzen, deren Hardware nur wenig genutzt wird. Somit können Sie die Ressourcen maximieren, indem Sie mehrere Computer mit niedriger Auslastung auf einem einzigen physischen Hardwaregerät zusammenfassen. P2V ist ein integriertes Feature von VMM und erfordert weder zusätzliche Software noch zusätzliche Server. Für VMM 2008 wurde Unterstützung für eine größere Zahl physischer Systeme hinzugefügt, einschließlich Windows Vista-, Windows Server 2008- und x64-Hosts. Die P2V-Funktionalität von VMM ist eine hervorragende Ergänzung zu Planungstools wie dem MAP-Tool (Microsoft Assessment Planning), das dabei hilft, Kandidaten für die Serverkonsolidierung zu identifizieren (in dieser Ausgabe des TechNet Magazins Thema des Artikels von Baldwin Ng und Jay Sauls).
Wenn Sie bereits über virtuelle Computer im VMDK-Format von VMware verfügen, ermöglicht Ihnen VMM, mithilfe von V2V Ihre vorhandenen VMDKs in das VHD-Format zu konvertieren. Dabei handelt es sich um einen Offlineprozess – der virtuelle VMware-Computer muss heruntergefahren werden, während der V2V-Prozess die VMDK-Datei in eine VHD-Datei konvertiert. Sie können auch einen ausgeführten virtuellen VMware-Computer mithilfe der P2V-Funktion konvertieren. Dies kann ein wenig verwirrend sein, aber es ist wichtig, sich daran zu erinnern, dass virtuelle Computer in erster Linie Computer und erst in zweiter Linie virtuell sind. Da alle anderen Systeme virtuelle Computer als ausgeführte Computer erkennen, trifft dies auch auf die P2V-Funktionalität von VMM zu, mit der Sie einen unter einer beliebigen Virtualisierungssoftware ausgeführten virtuellen Computer in eine Microsoft-VHD konvertieren können.
VMM bietet IT-Administratoren durch mehrere Features höhere Flexibilität. Eines der wichtigsten Features, das VMM ermöglicht, ist die Migration von virtuellen Computern zwischen Hosts, was zur Aufrechterhaltung von hoher Verfügbarkeit und Serveroptimierung beitragen kann. In Verbindung mit Hyper-V-Hosts unterstützt VMM 2008 das Feature „Quick Migration“, mit dem ein virtueller Computer mit nur wenigen Sekunden Ausfallzeit zwischen Hyper-V-Hosts verschoben werden kann. Dies erfordert einen Windows Server 2008-Cluster und freigegebenen Speicher, aber VMM erleichtert die Verwaltung und Konfiguration.
In Verbindung mit einem VMware-ESX-Host unterstützt VMM 2008 auch VMware VMotion – das VMware-Feature, mit dem virtuelle Computer ohne wahrnehmbare Ausfallzeit für die Benutzer verschoben werden können. Hierzu werden VMotion-fähige VMware-ESX-Hosts, ein Cluster und ein SAN-Back-End wie Quick Migration benötigt. Im weiteren Verlauf dieses Artikels werden die Schritte einer VMotion-Migration mit VMM 2008 beschrieben.
Mit VMM 2008 kann auch ein vorhandener virtueller Computer, der unter Virtual Server 2005 ausgeführt wird, auf einen Hyper-V-Host migriert werden, wobei alle für die Migration erforderlichen Aktualisierungen und Konvertierungen automatisch durchgeführt werden.
Als Bestandteil jeder neuen oder durch Konvertierung gestarteten Bereitstellung (einschließlich der oben beschriebenen Migrationen) verwendet VMM einen als „Intelligent Placement“ (Intelligente Platzierung) bezeichneten Prozess, um die virtuellen Computer auf den Hosts bereitzustellen. Über Intelligent Placement fragt VMM auch alle von VMM verwalteten virtuellen Computerhosts ab, ruft verschiedene Parameter zur Ressourcenverfügbarkeit dieser Hosts ab und gibt dann eine gewichtete Liste von Hosts zurück, die für die Bereitstellung des virtuellen Computers empfohlen werden. Wie Sie in Abbildung 3 sehen können, unterstützt Intelligent Placement Microsoft- und VMware-Hosts zusammen mit ihren Speicherkonfigurationen. Bei Intelligent Placement in VMM 2008 werden sowohl die Plattform als auch die Konfiguration berücksichtigt. Daher werden nur Hosts empfohlen, die zu der jeweiligen Hostplattform passen. Wenn hohe Verfügbarkeit erforderlich ist, werden nur Clusterhosts und für virtuelle x64-Computer nur x64-fähige Hosts empfohlen.
Abbildung 3 Analyse aller verfügbaren Hosts über Intelligent Placement (zum Vergrößern auf das Bild klicken)

Integration in System Center
Eines der wichtigsten Features von VMM 2008 ist die Integration in System Center Operations Manager 2007. Während VMM 2007 in bestimmtem Umfang in Operations Manager integriert war, enthält VMM 2008 einen Produktconnector für Operations Manager, der die Funktionalität der Integration wesentlich erhöht. Durch die Integration in Operations Manager bietet VMM sowohl über die Administratorkonsole als auch über ein neues Feature, das als „Performance and Resource Optimization“ (PRO) bezeichnet wird, konsolidierte Operations Manager-Berichte.
PRO ermöglicht VMM 2008, als „PRO-Tipps“ bezeichnete Warnungen zu erstellen und sogar automatisierte Abhilfemaßnahmen auf Grundlage von Überwachungsparametern von Operations Manager durchzuführen. Abbildung 4 zeigt einige Beispiele für PRO-Tipps. Bei Verwendung eines PRO-fähigen Management Pack (PRO Pack) kann VMM 2008 automatisierte Aktionen wie Migrationen von virtuellen Computern und Erstellung neuer virtueller Computer auf Grundlage von host-, hypervisor-, hardware- und sogar arbeitsauslastungsbasierten Leistungsparametern durchführen.
Abbildung 4 PRO-Tipps bieten Warnungen und Abhilfemaßnahmen für Probleme in der virtuellen Infrastruktur (zum Vergrößern auf das Bild klicken)

Installation von Virtual Machine Manager 2008
Für eine Installation von System Center VMM 2008 müssen mehrere Voraussetzungen und neue Systemanforderungen erfüllt werden. Der VMM 2008-Server erfordert Windows Server 2008 x64. Der Server kann nicht unter Windows Server 2003 oder auf x86-Versionen von Windows Server 2008 installiert werden. Die Administratorkonsole und andere Komponenten können weiterhin unter Windows Server 2003 und Windows XP oder Windows Vista (im Fall der Konsole) installiert werden, wobei dieselben Anforderungen und Installationsverfahren wie bei VMM 2007 gelten.
VMM 2008 erfordert zudem für das Sicherheitsmodell von VMM eine Installation in einer Active Directory-Domäne. VMM 2008 unterstützt die Verwaltung von (keiner Domäne angehörenden) Umkreisnetzwerkhosts, einschließlich der P2V-Konvertierung von Nichtdomänensystemen, was in VMM 2008 neu ist. Einer der Vorteile der Verwendung von Windows Server 2008 als Installationsplattform besteht darin, dass viele der Voraussetzungen für VMM (wie .NET Framework 3.0, WinRM und Windows PowerShell 1.0) bereits integriert sind. VMM 2008 erfordert darüber hinaus das Windows Automated Installation Kit (WAIK) 3.0, obwohl das VMM 2008-Installationsprogramm die Installationsdateien enthält.
Obwohl es sich empfiehlt, in einer Produktionsumgebung jede VMM-Komponente auf einem separaten Produktionsserver zu installieren, wird in diesem Artikel eine Einzelserverinstallation beschrieben. Als Hardware für eine VMM-Serverinstallation werden ein x64-basierter Server mit 2,8 GHz oder höher und mindestens 2 GB RAM empfohlen. Da es sich hier um eine Einzelserverinstallation mit einer lokalen SQL-Datenbank handelt, werden 7 GB Festplattenspeicher benötigt. Beachten Sie, dass bei Verwendung einer Remotedatenbank bereits 1 GB Festplattenspeicher für die VMM-Installation selbst genügt. Für die Installation der lokalen Bibliothek werden zusätzlich 80 GB Speicher auf der Festplatte empfohlen.
Wie bereits erwähnt, wird VMM unter einer Windows Server 2008 x64-Installation ausgeführt. Weitere Softwareanforderungen sind .NET Framework 3.0, Windows PowerShell 1.0, WinRM sowie IIS 6.0 oder höher für das Self-Service-Portal. Microsoft MSXML 6.0 Parser wird ebenfalls benötigt, ist aber in .NET Framework 3.0 enthalten.
Wenn Sie die VMM-Installation starten, werden Ihnen fünf Optionen angeboten: der Virtual Machine Manager-Server, die Administratorkonsole, das Self-Service-Portal und der lokale Agent sowie eine Option zur Konfiguration des Operations Manager Management Pack. Wie bereits erwähnt, werden alle Komponenten auf einem einzigen Computer installiert, wobei mit dem VMM-Server begonnen wird. Nachdem die Installation gestartet wurde, werden auf den ersten Bildschirmen die Systemvoraussetzungen geprüft.
Zusätzlich zu den bereits genannten Anforderungen muss der Computer einer Domäne angehören. Bei der VMM-Serverinstallation werden die integrierten Funktionen automatisch aktiviert, sodass Sie sie nicht manuell aktivieren müssen.
Nachdem Sie das Installationsprogramm gestartet haben, sollten Sie mithilfe der Windows Update-Option sicherstellen, dass VMM 2008 auf dem neuesten Stand ist. Das Installationsprogramm überprüft dann die Optionen, die sich hauptsächlich auf die SQL-Datenbankinstallation beziehen. Im Beispiel für diesen Artikel wird SQL Server 2005 Express Edition verwendet.
Als Nächstes werden Sie vom Assistenten zur Angabe des Speicherorts für die zentralisierte Bibliothek aufgefordert. Dabei kann es sich um ein lokales Verzeichnis auf dem VMM-Server (und eine für dieses Verzeichnis erstellte Freigabe) oder um eine vorhandene Dateifreigabe handeln. Der Standardspeicherort lautet „C:\ProgramData\Virtual Machine Manager Library Files“.
Den nächsten Schritt bilden die Portzuweisungen. An dieser Stelle werden der Port für die Verbindung von der Administratorkonsole zum zentralen VMM-Serverdienst (standardmäßig Port 8100), der von WinRM für die Durchführung der Verwaltungsfunktionen verwendete Port (standardmäßig Port 80) sowie der Port konfiguriert, der vom intelligenten Hintergrundübertragungsdienst (Background Intelligent Transfer Service, BITS) dafür verwendet wird, Dateien auf die virtuellen Computerhosts zu verschieben (standardmäßig Port 443). Wenn Sie alle diese Informationen eingegeben haben, wird ein Übersichtsbildschirm angezeigt, und die Serverinstallation kann abgeschlossen werden.
Als Nächstes wird die Administratorkonsole installiert, für die ähnliche Systemvoraussetzungen wie für den VMM-Server gelten. Die einzige Konfigurationsoption außer dem Installationsverzeichnis dient der Bestätigung des Kommunikationsports, der für die Verbindung zum zentralen VMM-Serverdienst verwendet wird. Dabei muss Port 8100 verwendet werden, der bei der VMM-Serverinstallation konfiguriert wurde.
Am Ende der Installation haben Sie die Wahl, eine Desktopverknüpfung für die Administratorkonsole zu erstellen und im Anschluss an die Installation die Konsole zu öffnen. Es empfiehlt sich, beide Optionen auszuwählen. Wenn Sie die Administratorkonsole zum ersten Mal öffnen, werden Sie aufgefordert, eine Verbindung zum Server herzustellen. Bei der Einzelserverinstallation ist „localhost“ auf Port 8100 die richtige Einstellung, und Sie können einfach die Eingabetaste drücken, um die Konsole zu starten.
Zum Schluss wird das Self-Service-Portal installiert. Die Voraussetzungen dafür sind IIS 6.0 oder 7.0, .NET Framework 3.0 sowie Windows PowerShell 1.0. (Windows PowerShell ist erforderlich, weil das Self-Service-Portal einfach eine weitere Schnittstelle zu den zentralen VMM-Diensten ist, die Windows PowerShell verwenden.) Für Windows Server 2008 müssen Sie die IIS-Rolle aktivieren, bevor Sie die VMM 2008-Installation starten. Stellen Sie dabei sicher, dass die folgenden IIS-Rollendienste aktiviert sind:
  • Allgemeine HTTP-Features (Statischer Inhalt, Standarddokument, Verzeichnissuche, HTTP-Fehler)
  • Anwendungsentwicklung (ASP.NET, .NET-Erweiterbarkeit, ISAPI-Erweiterungen, ISAPI-Filter)
  • Sicherheit (Anforderungsfilterung)
  • Kompatibilität mit der IIS 6.0-Verwaltung
Wenn diese Rollendienste aktiviert sind, besteht die Installation die Voraussetzungsüberprüfung, und die Installation wird fortgesetzt. Während der Installation werden nur Konfigurationsoptionen für die vom Self-Service-Portal verwendeten Ports geboten. Der erste dieser Ports ist Port 8100, der Port für die Verbindung zum zentralen VMM-Dienst, der mit dem für die Administratorkonsole verwendeten Port identisch ist. Der zweite Port ist der Port, auf dem das Portal ausgeführt werden soll. Als Standardeinstellung ist Port 80 vorgegeben, aber in vielen Konfigurationen ist dieser Port bereits vergeben. Wenn dies der Fall ist, werden Sie vom VMM-Installationsprogramm mit einer Warnung darauf hingewiesen. Ändern Sie gegebenenfalls den vorgegebenen Standardport in einen anderen freien Port, z. B. Port 81. Das Installationsprogramm erstellt dann eine Homepage für das Microsoft System Center Virtual Machine Manager 2008-Self-Service-Portal. Die Konfiguration kann im Server-Manager geändert werden.
Wenn die Installation von IIS abgeschlossen ist, können Sie die Website öffnen, indem Sie einfach in Internet Explorer zu „localhost:8080“ wechseln. Wenn Sie beim Öffnen der Website zur Authentifizierung aufgefordert werden, liegt dies an Ihren Internet Explorer-Sicherheitseinstellungen. Das Self-Service-Portal sollte in Internet Explorer im Intranetkontext ausgeführt werden. Möglicherweise müssen Sie in Internet Explorer den VMM-Server der Liste der Intranetsites hinzufügen. Sobald diese Konfigurationen vorgenommen wurden, können Sie Self-Service-fähige virtuelle Computer in VMM 2008 erstellen und verwenden.

Hinzufügen von VMware-ESX-Hosts
Obwohl VMM 2008 mit zahlreichen neuen Features aufwartet, ist das wohl am sehnsüchtigsten erwartete Feature die hinzugefügte Unterstützung für die VMware-ESX-Hostverwaltung. Mit dieser Unterstützung kann VMM jetzt die virtuelle Infrastruktur der meisten IT-Abteilungen von Unternehmen verwalten.
Das Verfahren zum Hinzufügen von ESX-Hosts in Virtual Machine Manager 2008 ist relativ einfach. Wie bereits erwähnt, verwaltet VMM 2008 VMware-Hosts über einen VirtualCenter-Server, der die Version 2.0.1 oder 2.5 aufweisen muss. Um die VMware-ESX-Server in der Verwaltungskonsole hinzuzufügen, fügen Sie den VirtualCenter-Server einfach mithilfe der entsprechenden Aktion oben rechts im Aktionsbereich hinzu.
Nach dem Start des Assistenten geben Sie den Computernamen des VirtualCenter-Servers zusammen mit dem Administratorkonto für den VirtualCenter-Server ein. VMM fügt die ESX-Hosts, einschließlich der vorhandenen Hostgruppenstruktur von VirtualCenter, in der VMM-Schnittstelle hinzu. Dieser Vorgang kann mehrere Minuten dauern, aber Sie können den Fortschritt über das VVM-Menü „Aufträge“ überwachen.
Wenn alle Server importiert wurden, sollte in VMM die gleiche VMware-ESX-Hostserverstruktur wie in VirtualCenter angezeigt werden. Um einen weiteren VirtualCenter-Server hinzuzufügen, wiederholen Sie einfach den Vorgang. Nachdem die Hoststruktur in VMM hinzugefügt wurde, können Sie Nicht-VMware-Server in derselben Gruppenstruktur hinzufügen. Natürlich werden die Nicht-VMware-Server in VirtualCenter nicht angezeigt.
Obwohl VMM 2008 VirtualCenter zur Verwaltung von ESX-Hosts verwendet, muss VMM für bestimmte Funktionen wie V2V, das Speichern des Zustands und das Klonen virtueller Computer von ESX-Hosts aus direkt auf die ESX-Hosts zugreifen können. Daher wird nach dem Hinzufügen des VirtualCenter-Servers in VMM für die Hosts der Zustand „OK (begrenzt)“ angezeigt. Um die vollständige Verwaltung zu ermöglichen, geben Sie auf der Seite „Eigenschaften“ der einzelnen ESX-Hosts in VMM die entsprechenden Anmeldeinformationen für den Host ein, um die Server direkt verwalten zu können.

VMotion-Migration
Wenn die VMware-Verwaltung in Virtual Machine Manager 2008 erörtert wird, taucht unweigerlich die Frage auf, ob VMM VMotion und andere VirtualCenter-Funktionen ausführen kann. Da VMM für die VMware-Verwaltung VirtualCenter verwendet, lautet die Antwort auf diese Frage „Ja“!
Funktional betrachtet, behandelt VMM VMotion wie jede andere Migration. Um eine VMotion-Migration zu starten, wählen Sie zuerst den virtuellen Computer aus, den Sie verschieben möchten. Dann wählen Sie im Aktionsbereich auf der rechten Seite von VMM die Option „Virtuelle Maschine migrieren“ aus. Danach wird in VMM das Intelligent Placement-Fenster für diesen virtuellen Computer geöffnet, in dem die potenziellen Zielhosts mit dem Transfertyp „Live“ angezeigt werden (siehe Abbildung 5). Mithilfe von Intelligent Placement können Sie die richtigen Zielhosts für Ihre virtuellen Computer auswählen. Beachten Sie, dass dieser Prozess mit einem Quick Migration-Vorgang unter Verwendung von Hyper-V-Hosts identisch ist.
Abbildung 5 VMotion mit Intelligent Placement (zum Vergrößern auf das Bild klicken)
Wählen Sie den Zielhost für den virtuellen Computer aus – in diesem Fall ist dies der Server namens „cqaesxi003.contoso.com“. Klicken Sie dann auf „Weiter“. Im letzen Fenster „Zusammenfassung“ (siehe Abbildung 6) wird die angeforderte Aktion angezeigt.
Abbildung 6 Fenster „Zusammenfassung“ für VMotion (zum Vergrößern auf das Bild klicken)
Wie bereits erwähnt, ist in jedem Assistenten in VMM die Schaltfläche „Skript anzeigen“ vorhanden, über die das Windows PowerShell-Skript für einen Auftrag in Editor angezeigt werden kann. Dadurch bietet sich die Gelegenheit, einmal zu betrachten, wie Windows PowerShell in VMM 2008 in Verbindung mit VMware funktioniert. Hier ist das Skript für diese Aktion:
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq "cqaesxi003.contoso.com"}
$VMHost = Get-VMHost -VMMServer localhost |   where {$_.Name -eq "cqaesxi003.contoso.com"}
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
Die VMotion-Migration für dieses System wird mit drei einfachen Befehlen durchgeführt. Im Beispiel wird der virtuelle Computer „MyVM“ vom VMware-Server „cqaesxi003.contoso.com“ auf den Server „cqaesxi001.contoso.com“ verschoben. Der erste Befehl besteht darin, den virtuellen Computer zu identifizieren, der über VMotion migriert werden soll. Wie Sie sehen können, wird in dieser Befehlszeile der Wert des virtuellen Computers der Variablen „$VM“ zugewiesen:
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq " cqaesxi003.contoso.com"}
Der zweite Befehl besteht darin, das ESX-Zielhostsystem für den virtuellen Computer zu identifizieren. In dieser Zeile wird die Variable „$VMHost“ dem ESX-Host „cqaesxi003.contoso.com“ zugewiesen:
$VMHost = Get-VMHost -VMMServer localhost | where
  {$_.Name -eq " cqaesxi003.contoso.com"}
Abschließend wird der Befehl „Move-VM“ verwendet, um den virtuellen Computer tatsächlich zu verschieben. Hier sind die vollständige Befehlszeile und die Parameter für „Move-VM“:
Move-VM [-VM] [<String VM>] -VMHost [<String Host>]
  [-JobGroup <Guid>] [-JobVariable <String>] [-Path
  <String>] [-PROTipID] [-RunAsynchronously]
  [-StartVMOnTarget <Boolean>] [-UseLAN <Boolean>]
  [<CommonParameters>]
Wie Sie sehen, ist der Befehl weder anbieter- noch softwarespezifisch, was mit der heterogenen Verwaltungsphilosophie von Virtual Machine Manager im Einklang steht. Um die VMotion-Migration abzuschließen, geben Sie den folgenden Befehl aus:
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
Dadurch wird VMM angewiesen, „Move-VM“ für den virtuellen Computer in „$VM“ auszuführen, den virtuellen Computer auf das Hostsystem in „$VMHost“ zu verschieben und den Auftrag asynchron auszuführen. Nachdem der Auftrag gestartet wurde, kann der gesamte Prozess in VMM im Fenster „Aufträge“ überwacht werden. Erneut kann derselbe grundlegende Befehl für Quick Migration-Vorgänge auf Hyper-V-Clustern und sogar auf Nichtclusterhosts mithilfe einer LAN-basierten Übertragung verwendet werden.
Wie Sie sehen, wurden in System Center Virtual Machine Manager 2008 die großartigen Features und Funktionen von Virtual Machine Manager 2007 durch neue Verwaltungsplattformen und Features erweitert. Durch die Beschreibung des Installationsvorgangs und einiger Features in diesem Artikel haben Sie hoffentlich einen Eindruck erhalten, wie einfach die Verwaltung mehrerer Hypervisoren in VMM 2008 ist.
VMM 2008 wurde als konsolidierte Verwaltungssoftware für die Virtualisierung entwickelt, die physische und virtuelle Systeme von Microsoft und VMware vereint. Mit dieser neuen Version von Virtual Machine Manager können VMware-Administratoren, Microsoft Virtual Server 2005-Administratoren und neue Hyper-V-Administratoren alle ein einziges Tool, eine einzige Skriptingschnittstelle und – was am wichtigsten ist – einen einzigen Verwaltungsprozess für ihre virtuelle Infrastruktur nutzen.

Edwin Yuen arbeitet in der Abteilung „Windows Enterprise Management“ als technischer Produktmanager für System Center Virtual Machine Manager. Edwin Yuen ist im Juli 2006 durch die Übernahme von Softricity zu Microsoft gestoßen. Er verfügt über 13 Jahre Erfahrung als technischer Berater in der Privatwirtschaft und bei Behörden. Er hat an der Johns Hopkins University einen Bachelor of Science in Elektrotechnik erworben.


Virtualisierung
Erste Schritte mit Microsoft Application Virtualization
Anthony Kinney

Dieser Artikel basiert auf einer Vorabversion von App-V. Änderungen an den in diesem Artikel enthaltenen Informationen sind vorbehalten.
Auf einen Blick:
  • App-V-Architektur
  • Verwalten virtueller Anwendungen
  • Verwenden des App-V-Sequencers
  • Integrieren von App-V in Configuration Manager

Inhalt
Die App-V-Architektur
Funktionsweise der vollständigen App-V-Infrastruktur
Aktualisieren virtueller Anwendungen
Sequenzierung
Version 4.5
Microsoft Application Virtualization (oder App-V) liegt mir sehr am Herzen. App-V wurde früher als SoftGrid bezeichnet, und ich bin zu Microsoft gekommen, als Microsoft das Unternehmen Softricity übernahm, in dem SoftGrid entwickelt wurde. Ich freue mich sehr, diesen Artikel für das TechNet Magazin schreiben zu dürfen, weil sich seit der Übernahme viel geändert hat.
Die beste Herangehensweise an App-V besteht darin, zunächst über die Herausforderungen zu sprechen, denen IT-Experten bei der Unternehmensverwaltung gegenüberstehen. Der moderne Geschäftsdesktop ist von Anwendungen geradezu überflutet. Bevor eine Anwendung installiert wird, muss sie langwierige Regressionstests durchlaufen, um sicherzustellen, dass sie mit den anderen auf dem System installierten Anwendungen zusammenarbeiten kann, ohne deren Funktionsfähigkeit zu beeinträchtigen. Die Anwendung muss dann eine Reihe von Bereitstellungsprozessen absolvieren, bevor sie in Produktion geht. Weil eine Anwendung im Grunde nur dann verfügbar ist, wenn sie installiert ist, sind Ihre Benutzer an bestimmte Computer gebunden. Dies erschwert komplexe, kritische Projekte noch weiter, beispielsweise die Migration von Betriebssystemen und Anwendungen, Sicherheitsaktualisierungen und Pläne für die Notfallwiederherstellung.
Mit App-V wird das alles anders. Die Desktopadministration verwandelt sich mit App-V von einer komplexen Reihe zeitaufwändiger, ressourcenbelegender Schritte in einen einfacheren, stärker automatisierten Prozess. Sie können die Anwendungen einfacher bereitstellen, patchen, aktualisieren und beenden, und das mit besseren Ergebnissen.
Mit App-V kann sich ein Benutzer an einen beliebigen Desktop setzen und dort auf seine Anwendungen zugreifen. Die Anwendungen werden bei Bedarf bereitgestellt, werden jedoch so ausgeführt, als wären sie tatsächlich lokal installiert. Folglich gibt es keinen Grund, die Anwendungskomponenten zu installieren oder das Hostgerät zu verändern.
Diese Nutzung der Virtualisierung könnte die Verwaltung der Desktops durch die IT-Experten deutlich verändern. Die Nichtveränderung des Hostgeräts und das Ausführen virtualisierter Anwendungen bieten zahlreiche Vorteile, wie beispielsweise folgende:
  • Weniger Anwendungskonflikte
  • Schnellere und einfachere Aktualisierung von Anwendungen
  • Möglichkeit zum parallelen Ausführen mehrerer Versionen einer Anwendung
  • Flexible Anwendungen, die dem Benutzer online und offline folgen
  • Weniger Regressionstests zwischen Anwendungen

Die App-V-Architektur
Betrachten wir nun die wirklichen Abläufe im Hintergrund der App-V-Plattform. Die Plattform besteht aus einigen Hauptkomponenten: Sequencer, Datenbank, Clients, Verwaltungsserver, Streamingserver und Verwaltungskonsole (siehe Abbildung 1).
Abbildung 1 Anordnung einer App-V-Umgebung (zum Vergrößern auf das Bild klicken)
Das Herzstück des App-V-Systems ist der App-V-Client. Es stehen zwei Arten von Clients zur Auswahl: der Terminalserverclient und der Desktopclient. In jeden Fall muss der Client auf jedem Desktop und Terminalserver installiert werden, auf dem virtuelle Anwendungen bereitgestellt werden sollen. Der Client belegt nur relativ wenig Speicherplatz. Er installiert einen Treiber und besitzt eine sichtbare Benutzerlaufzeitkomponente, die als Symbol in der Taskleiste angezeigt wird.
Der Client stellt eine Liste virtueller Anwendungen vom App-V-Verwaltungsserver zusammen und zeigt die verfügbaren virtuellen Anwendungen an. Er kümmert sich um den Start dieser Anwendungen (wenn ein Benutzer den Start initiiert) sowie um die Verwaltung des clientseitigen Cache. Der Client ist auch für die Erstellung der virtuellen Laufzeitumgebung zuständig, und er stellt sicher, dass jede Umgebung in ihrer eigenen virtuellen Blase ausgeführt wird. Diese virtuelle Umgebung enthält mehrere Komponenten, unter anderem eine virtuelle Registrierung, ein virtuelles Dateisystem sowie eine virtuelle Diensteverwaltung.
In App-V 4.5 stehen drei Optionen für die Bereitstellung der Infrastruktur zur Auswahl: eine vollständige Infrastruktur, eine grundlegende Infrastruktur und der eigenständige Modus. Wenn Sie eine vollständige Infrastruktur bereitstellen, enthält das Back-End den App-V-Verwaltungsserver und den App-V-Streamingserver (dies ist eine neue Komponente, auf die ich noch näher eingehen werde). Der App-V-Verwaltungsserver hostet die zentralisierten virtuellen Anwendungen und stellt sie bereit. Außerdem aktualisiert er die virtuellen Anwendungen, wenn Patches oder Updates angewendet werden.
Dieser Verwaltungsserver lässt SQL Server die App-V-Datenbank hosten, die die Konfiguration und die Einstellungen für die virtuellen Anwendungen enthält. Sie sollten Active Directory-Gruppen als zentrales Verwaltungstool zum Einrichten und Steuern der Berechtigungen für virtuelle Anwendungen verwenden.
Um die Einstellungen und die Konfiguration zu verwalten, bietet die App-V-Plattform einen Microsoft .NET Framework-Webdienst, der auf denselben Server geladen werden kann, sofern IIS installiert ist. Dieser Webdienst fungiert als Verbindung zwischen der App-V-Verwaltungskonsole – einem MMC-Snap-In (Microsoft Management Console) – und der App-V-Datenbank. Administratoren können virtuelle Anwendungen über die Konsole veröffentlichen und verwalten, Active Directory-Gruppen zuweisen und die Servereinstellungen steuern sowie Berichte über die Nutzung virtualisierter Anwendungen ausführen (siehe Abbildung 2).
Abbildung 2 Verwaltungskonsole (zum Vergrößern auf das Bild klicken)
Die grundlegende Infrastruktur enthält den App-V-Streamingserver, der Streamingfunktionen wie die aktive Aktualisierung oder die Paketaktualisierung ermöglicht. Diese Option erfordert Active Directory oder SQL Server. Sie umfasst keinen Desktopkonfigurationsdienst, und auch Lizenzierungs- und Messfunktionen sind nicht vorhanden. Die grundlegende Infrastruktur ermöglicht jedoch das Hinzufügen von Streamingfunktionen zu SCCM (System Center Configuration Manager) und zu Drittanbieterlösungen zur Unternehmenssoftwarebereitstellung (enterprise software deployment, ESD).
Im eigenständigen Modus kann der App-V-Sequencer eine MSI-Datei erstellen, die die Ergänzung der virtuellen Anwendung automatisiert (siehe Abbildung 3). Die MSI-Datei enthält Metadaten, mit denen jedes ESD-System die virtualisierte Anwendung erkennen und steuern kann. Bei diesem Modus muss der Client in den eigenständigen Modus wechseln, bei dem nur MSI-basierte Aktualisierungen der virtuellen Anwendungen möglich sind. Streaming ist im eigenständigen Modus nicht zulässig. Dieser Modus gibt Organisationen die Möglichkeit, die App-V-Isolierungsfunktionen zu verwenden.
Abbildung 2 App-V-Sequencer (zum Vergrößern auf das Bild klicken)
MSI-Dateien sind sehr flexibel, können komplett eigenständig mit nur einem App-V-Client ausgeführt werden und benötigen keine Serverkomponenten. Dies bedeutet, dass sie manuell, mit einem Datenträger oder über herkömmliche Bereitstellungstools bereitgestellt werden können.
App-V 4.5 unterstützt nunmehr die Protokolle HTTP und HTTPS für das Streaming. Dies ermöglicht eine bessere Leistung des Streaming sowie die Nutzung eines weit verbreiteten Protokolls, besonders für das Streaming über sichere WAN-Umgebungen (Wide Area Network) und über das Internet.

Funktionsweise der vollständigen App-V-Infrastruktur
Ein Benutzer meldet sich bei einem Gerät an, auf dem einer der Clients (App-V-Terminaldiensteclient oder App-V-Desktopclient) installiert ist, und der Client sendet dem Server eine Anforderung über eine Liste der Anwendungen, die dem aktuellen Benutzer zugewiesen sind. Der Server kommuniziert mit Active Directory und ermittelt die Gruppen, denen der Benutzer als Mitglied angehört, und gibt dann die Liste der Anwendungen zurück an den Client. Der Client beginnt, Ankündigungen für die virtuellen Anwendungen zu erstellen, die diesem bestimmten Benutzer zugewiesen sind.
In diesem Veröffentlichungsprozess werden mehrere Aktionen durchgeführt:
  • Konfigurationsdateien werden kopiert
  • Desktopsymbole werden erstellt
  • Empfängerlinks werden erstellt
  • Startmenüordner werden erstellt
  • Dateitypen werden konfiguriert
Dieser Prozess ist sehr schnell, und was noch wichtiger ist, er sorgt dafür, dass die Umgebung genau so aussieht, wie der Benutzer es erwartet, ganz ohne optische Änderungen. Die virtuellen Anwendungen arbeiten, als wären sie lokal installiert, aber natürlich verändern sie den Hostcomputer nicht. Die Symbole zeigen nicht auf ausführbare Dateien, die sich im Programmverzeichnis befinden, sondern auf den App-V-Client, der für seine Konfiguration eine Startprogrammdatei (eine OSD-Datei) nutzt.
Beachten Sie, dass dieser Prozess sich nur geringfügig auf das Netzwerk auswirkt, weil im Unterschied zu herkömmlichen Softwarebereitstellungen nichts installiert wird. Dies bietet ernorme Vorteile, insbesondere in Roamingbenutzerumgebungen, weil die Anwendungen für den Benutzer verfügbar sind, aber erst dann etwas bereitgestellt wird, wenn eine Anwendung tatsächlich gestartet wird. Diese Ankündigungsmethode ist auch die Grundlage für die bedarfsgesteuerten Features und die Roaminganwendungsfeatures von App-V.
Wenn der Benutzer eine virtuelle Anwendung startet, liest der Client eine OSD-Konfigurationsdatei, die auf dem lokalen Computer gespeichert ist. Diese Datei teilt dem Client mit, welches Protokoll er beim Kommunizieren mit dem App-V-Verwaltungsserver verwenden soll und auf welchem Server sich die Anwendung befindet.
Der jeweilige Server antwortet auf den Client, indem der anfängliche Startschwellenwert durch Streaming übertragen wird, der in der Regel bei 20 % bis 40 % der vollständigen Anwendung liegt. Sobald der gesamte Startschwellenwert per Streaming übertragen wurde (wiederum nur 20 % bis 40 % der Anwendung), ist die virtuelle Anwendung ausführungsbereit.
Das Streaming ist tatsächlich eines der wichtigsten Elemente bei der Paradigmaverschiebung, die sich mit App-V ergab. Hiermit kann so viel von einer Anwendung gesendet werden, dass sie ausgeführt werden kann, ohne wertvolle Netzwerkbandbreite zu verschwenden. Alle Daten, die dem Client übermittelt werden, befinden sich in einer lokalen Cachedatei auf dem Gerät, und jeder nachfolgende Start der Anwendung erfolgt aus dem lokalen Cache heraus, wodurch zusätzlicher Netzwerkverkehr vermieden wird.
Sobald das Streaming für die virtuelle Anwendung abgeschlossen ist, erstellt der Client eine isolierte Umgebung, sodass die Anwendung den lokalen Computer nicht verändern kann (mit anderen Worten, die Anwendung meldet keinen Speicherbedarf auf dem Client an). Der Client ermöglicht der virtuellen Anwendung allerdings den Zugriff auf das lokale Dateisystem, wenn Dateien gespeichert und bearbeitet werden, und er ermöglicht der Anwendung auch die Interaktion mit lokalen Diensten (z. B. Drucken), sofern der Benutzer die entsprechenden Berechtigungen auf dem lokalen System besitzt. Jegliche Änderungen, die eine virtuelle Anwendung an den Dateien im lokalen System und an der Registrierung vornimmt, werden jedoch an die virtualisierte Umgebung umgeleitet, damit das Hostgerät unverändert bleibt.
Beim Ausführen der Anwendung werden alle Features, die bislang nicht verwendet wurden, nur bei Bedarf geliefert und zur späteren Verwendung im Cache zwischengespeichert. Der Vorteil hierbei besteht darin, dass nur die Komponenten, die der Benutzer benötigt, beim anfänglichen Starten geladen werden. Nicht genutzte Features belegen keine Netzwerkressourcen. (Die neue Version bietet einige Verbesserungen für den clientseitigen Cache, die eine intelligentere Cacheverwendung sowie das Streaming im Hintergrund ermöglichen.)
Betrachten Sie beispielsweise Microsoft Office Word. Fast alle Benutzer verwenden eine Rechtschreibprüfung (ich könnte diesen Artikel sonst gar nicht schreiben!). Deshalb wird sie beim anfänglichen Start mitgeladen. Aber was ist mit dem Hilfefeature in Word? Längst nicht so viele Benutzer verwenden dieses Feature, sodass es beim anfänglichen Start nicht geladen werden braucht. Stattdessen könnte es dem Benutzer gesendet werden, sobald er das erste Mal darauf zugreift.
Wenn der Benutzer die Arbeit beendet und die Anwendung schließt, baut der Client die virtuelle Umgebung ab und speichert alle Benutzereinstellungen an einem vom Benutzer angegebenen Speicherort, damit die Umgebung erhalten bleibt und beim nächsten Start wiederaufgebaut werden kann. Der per Streaming übertragene Anteil der virtuellen Anwendung verbleibt im lokalen Cache und steht für den nächsten Start zur Verfügung. Wenn ein anderer Benutzer sich bei demselben Hostsystem anmeldet und dieselbe virtuelle Anwendung startet, profitiert dieser neue Benutzer von der Anwendung, die bereits im Cache gespeichert ist.
Um die Ankündigungen für die virtuellen Anwendungen zu entfernen, entfernen Sie einfach den Benutzer aus der jeweiligen Active Directory-Gruppe. Um die virtuelle Anwendung vollständig von einem Desktop zu deinstallieren, löschen Sie einfach den Cache. Die Anwendung wurde nie lokal installiert, weshalb es keine ärgerlichen Nachfragen gibt wie: „Möchten Sie diese gemeinsam genutzte Komponente wirklich entfernen?“
Achtung: Selbst wenn eine virtuelle Anwendung in einem Cache gespeichert ist, bedeutet das noch lange nicht, dass alle Benutzer Zugriff darauf haben. Im Unterschied zu lokal installierten Anwendungen, wo die Benutzer einfach nach ausführbaren Dateien suchen können, für die sie keine Rechte besitzen, gibt es keine visuellen oder physischen Anzeichen, dass die virtuelle Anwendung existiert, es sei denn, der Benutzer hat durch Active Directory explizite Rechte für diese Anwendung erhalten.

Aktualisieren virtueller Anwendungen
Die Aktualisierung wird über den Sequencer abgewickelt. Sobald eine Anwendung überarbeitet und ein Update entwickelt wurde, wird dieses Update direkt neben der früheren Version auf dem App-V-Verwaltungsserver gespeichert. Der Server benachrichtigt dann den Client beim nächsten Start, dass eine Änderung vorgenommen wurde. Wenn ein Benutzer die frühere Version noch in Gebrauch hat, besitzt der Benutzer weiter den Zugriff auf diese Version, bis er die virtuelle Anwendung schließt. Beim nächsten Start werden die Deltas, die das Update ausmachen, per Streaming auf den Client übertragen und in den Cache geladen, sodass eine aktualisierte Version der Anwendung entsteht.
Ein Beispiel: In Ihrer Organisation führen 1.000 Benutzer die Anwendung Word 2000 aus. Ein Administrator muss Word 2000 (word2K.sft) auf Word 2000 SP3 aktualisieren. Deshalb kopiert er die Datei „word2K.sft“ auf die Sequenzierungsstation und wählt im Sequencer die Option „Open for Package Upgrade“ (Für Paketaktualisierung öffnen) aus. Durch Auswählen der Option „Open for Package Upgrade“ beginnt der Administrator mit dem letzten Paketzustand. Sie kann dann DLLs kopieren, Updates ausführen oder Patches anwenden, um die virtuelle Anwendung auf Word 2000 SP3 zu aktualisieren. Anschließend speichert der Administrator dieses aktualisierte Paket.
Der Sequencer weist dem Paket automatisch einen neuen Dateinamen zu (word2K_2.sft), um doppelte Dateinamen zu verhindern und um die Sequenzierungsversion zu kennzeichnen. Dieses neue Paket wird in dasselbe Verzeichnis auf dem App-V-Verwaltungsserver gespeichert wie das alte Paket, sodass sich Word 2000 (word2K.sft) und Word 2000 SP3 (word2K_2.sft) letztlich im selben Verzeichnis befinden. Danach verknüpft der Administrator die beiden SFT-Dateien über die App-V-Verwaltungskonsole.
Auf der Clientseite können Benutzer, die eine aktive Sitzung von Word 2000 ohne SP3 geöffnet haben, normal weiterarbeiten. Benutzer, die eine neue Sitzung der Anwendung starten, nachdem der Administrator diese Verknüpfung eingerichtet hat, erhalten eine Nachricht, dass eine Änderung erkannt wurde. Der Client beginnt dann, nur die Deltaänderungen zwischen word2K.sft und word2K_2.sft per Streaming zu übermitteln, wobei die Anwendung automatisch auf Word 2000 SP3 aktualisiert wird.
Aufgrund der Dynamik virtueller Anwendungen ist auch das Zurücksetzen relativ einfach. Öffnen Sie einfach erneut die App-V-Verwaltungskonsole, und entfernen Sie die neu hinzugefügte Version. Damit setzt der Client die Anwendung beim nächsten Starten auf die frühere Version zurück. Um eine Überkreuzung der Paketdaten zu verhindern, löscht der Client automatisch den Cache, und die richtige SFT-Datei wird erneut per Streaming geladen. Dies ist ein angemessener Kompromiss, wenn Sie bedenken, was getan werden muss, um eine Aktualisierung für eine Anwendung zurückzusetzen, die physisch mit herkömmlichen Softwarebereitstellungstools installiert wurde.

Um die Vorteile von App-V nutzen zu können, müssen Sie virtuelle Anwendungspakete erstellen. Hier kommt der App-V-Sequencer ins Spiel. Alle Kenntnisse und Erfahrungen beim Schreiben von Skripts und beim Erstellen von Paketen für herkömmliche Softwarebereitstellungstools werden Ihren Umstieg auf die Sequenzierung erleichtern. (Ich möchte an dieser Stelle darauf hinweisen, dass die Sequenzierung allein schon einen Artikel füllen könnte.)
Die meisten Softwarebereitstellungslösungen nutzen Skripts, die die Schritte zur Installation der Anwendung aufzeichnen und dann dieses Verfahren auf anderen Computern duplizieren. Damit ist es nicht mehr nötig, jeden Computer einzeln aufzusuchen, um Anwendungen zu installieren oder zu aktualisieren. Sobald die Anwendung installiert ist, entfernen herkömmliche Softwarebereitstellungstools das Paket. Dann müssen Sie bestimmte Abhängigkeiten installieren, auf denen die Anwendung aufbauen kann, weitere Skripts ausführen oder auch manuelle Schritte einleiten, um die Anwendung für Ihre Anforderungen zu konfigurieren.
Die grundlegende Änderung in App-V besteht darin, dass der Sequenzierungsprozess ein Abbild einer bereits installierten Anwendung erzeugt, komplett mit sämtlichen Abhängigkeiten und Konfigurationen. Dieses Abbild kann vom App-V-Client „wiedergegeben“ werden, ohne das Gerät zu verändern, auf dem diese Wiedergabe erfolgt.
Der Sequencer erzeugt verschiedene Dateien, wobei die SFT-Datei die wichtigste ist. Diese Datei enthält alle Anwendungsressourcen, Abhängigkeiten und Konfigurationsinformationen. In einigen Fällen kann sie auch mehrere Anwendungen enthalten. Diese Datei kann daher naturgemäß relativ groß sein. Es gibt einige Komprimierungsoptionen, aber grundlegende Kenntnisse über Ihr Netzwerk und die Geräteleistung sind unerlässlich. Mit der Symboldatei (.ico), die der Sequencer erstellt, wird die virtuelle Anwendung angekündigt, sodass sie so arbeitet, als wäre sie lokal installiert.
Die OSD-Datei ist auch sehr wichtig, und sie bietet unzählige Optionen. Standardmäßig ist dies eine XML-basierte Datei, mit der dem App-V-Client mitgeteilt wird, wie er die virtuelle Anwendung starten soll. Die OSD-Datei kann auch so geändert werden, dass sie den Start und die Ausführung der virtuellen Anwendung konfiguriert und steuert. Ich möchte Ihnen dringend raten, das Administratorhandbuch für die Sequenzierung und das Dokument mit den bewährten Methoden bei der Sequenzierung zu lesen, damit Sie sich mit den verfügbaren Eigenschaften und Werten in der OSD-Datei vertraut machen können.
Nicht zuletzt enthält die neue manifest.xml-Datei paketbasierte Konfigurationsinformationen und kann für die Integration in ESD-Lösungen und MSI-Bereitstellungen von Drittanbietern verwendet werden. Der Sequencer kann außerdem eine MSI-Datei für das virtuelle Anwendungspaket erzeugen. Hiermit können Sie die virtuellen Anwendungen auf eigenständige (serverlose) Clients und über ein ESD-System laden.
Der Sequencer selbst ist ein assistentengestütztes Tool, mit dem Sie als „Verpacker“ durch das Verfahren der Installation einer Anwendung und ihrer Transformation in eine virtuelle Anwendung geführt werden (siehe Abbildung 4). Im ersten Schritt können Sie Standardeigenschaften für das Paket konfigurieren. Zu diesen Eigenschaften, die in der OSD-Datei gespeichert sind, gehören Paketnamen und Kommentare. Mit einigen der erweiterten Einstellungen können Sie den Server angeben, von dem aus die Streamingübertragungen laufen, außerdem das Inhaltsverzeichnis sowie die Betriebssysteme, die das Paket unterstützen soll.
Abbildung 4 Der Sequenzierungsassistent (zum Vergrößern auf das Bild klicken)
Im zweiten Schritt installieren, konfigurieren und testen Sie die Anwendung. Während der Installation zeichnet der Sequencer alle Änderungen auf, die am lokalen System vorgenommen werden, unter anderem am Dateisystem, an der Registrierung und am System. Dieser Assistent enthält auch einige Dienstprogramme, die beispielsweise die Integration in Windows Update ermöglichen.
Der nächste Schritt besteht darin, die Dateitypzuordnungen zu konfigurieren und den Ort für die Verknüpfungen anzugeben. Standardplatzierungen sind beispielsweise das Startmenü, der Desktop und die Schnellstartleiste, aber Sie können auch individuelle Speicherorte erstellen.
Anschließend starten Sie die Anwendung und konfigurieren den anfänglichen Startschwellenwert. In diesem Schritt ermittelt App-V den anfänglichen Anteil der Anwendung, die für den Client bereitgestellt werden muss, damit die Anwendung gestartet werden kann.
Um diesen anfänglichen Code zu konfigurieren (in der Regel als Featureblock 1 oder FB1 bezeichnet), starten Sie einfach die Anwendung, und nutzen Sie die Features, die die Benutzer am häufigsten verwenden. Starten Sie beispielsweise Word, und aktivieren Sie dann die Rechtschreibprüfung. Alle DLLs, Dateien und Registrierungsschlüssel, die die Anwendung während dieser Phase aufruft, werden automatisch als Teil von FB1 festgelegt. Sämtliche Dateien, Einstellungen und Komponenten, die zu diesem Zeitpunkt nicht verwendet wurden, gelangen in FB2. Wenn die Anwendung dann verwendet wird, erhält der Client eine Schema der SFT-Datei, aus dem hervorgeht, wo FB1 anfängt und endet und wo weitere Dateien in FB2 vorliegen, damit der Client diese Dateien abrufen kann, wenn dies erforderlich wird.
Der letzte Schritt im Sequenzierungsprozess besteht darin, die richtige Konfiguration sicherzustellen. Der Sequencer zeigt das in Abbildung 5 dargestellte Dialogfeld an. Dort sehen Sie die SFT-Datei, und Sie können noch letzte Ergänzungen oder Änderungen am Paket vornehmen.
Abbildung 5 Bestätigen und Anpassen des endgültigen Pakets (zum Vergrößern auf das Bild klicken)

Version 4.5
Nach zwei Jahren Entwicklungszeit ist die Veröffentlichung von App-V 4.5 noch für dieses Jahr geplant. Dies ist die erste von Microsoft für die Veröffentlichung vorgesehene Version des Produkts, und sie bietet mehrere wichtige Verbesserungen zur Optimierung der Anwendungsvirtualisierung, beispielsweise die dynamische Interaktion virtueller Anwendungen (Dynamic Virtual Application Interaction), die erweiterte Skalierbarkeit und die bessere Erfüllung der Internalisierungs- und Sicherheitsanforderungen von Microsoft.
Die dynamische Interaktion virtueller Anwendung bildet die Grundlage für die Interaktion virtualisierter Anwendungen. Diese Interaktion wird als Dynamic Suite Composition (DSC) bezeichnet. DSC ist kein Ersatz für die Möglichkeit, einem einzelnen Paket mehrere Anwendungen hinzuzufügen. Stattdessen bietet diese Lösung ein neues Verfahren, mit dem Abhängigkeiten, Middleware und Plug-Ins integriert werden können, die gemeinsam von virtuellen Anwendungen genutzt werden sollen.
Die Administratoren können festlegen, welche virtualisierten Anwendungen miteinander interagieren. Ein Beispiel: Angenommen, Sie nutzen fünf Webanwendungen, die dieselbe Java-Version erfordern. In App-V 4.1 müssten Sie diese Java-Version in jedes der fünf separaten Pakete aufnehmen. Weiterhin angenommen, dass ein Patch für die Java-Version erforderlich ist. Der Administrator müsste dann die fünf verschiedenen Pakete patchen. Mit DSC können Sie Java einmal verpacken und dann als Paket konfigurieren, das von allen fünf Webanwendungen verwendet werden soll. Demzufolge müsste der Administrator das Java-Paket nur einmal patchen.
Dieses Szenario gilt auch für Middleware und Plug-Ins. Ich habe Blogs über weitere Anwendungsfallszenarios geplant, sobald der Termin zur Veröffentlichung durch Microsoft näher rückt und jegliche späte Ergänzungen abgeschlossen sind.
Die Verbesserungen der Skalierbarkeit wirken sich sowohl auf das Streaming als auch auf die Back-End-Infrastruktur aus. Die Back-End-Komponenten wurden überarbeitet und bieten nunmehr eine noch bessere Unterstützung in Clustering- und Failoverszenarios, und das Streaming ist stärker auf die WAN- und LAN-Anforderungen ausgerichtet. Die Verbesserungen ergeben sich aus mehreren wichtigen Ergänzungen.
Die erste Ergänzung ist die neue Streamingserverkomponente, die das Streaming ohne Back-End-Infrastruktur mit Active Directory und SQL Server ermöglicht. Sie erhalten weiterhin all die fantastischen Vorteile der bedarfsweisen Bereitstellung und der zentralisierten Aktualisierung der Pakete, aber ohne die massiven Back-End-Anforderungen. Dies kommt insbesondere in Zweigstellenszenarios und bei der Integration in ESD-Lösungen von Drittanbietern zum Einsatz.
Der App-V-Client hat ebenfalls einige Verbesserungen vorzuweisen. Beispielsweise speichert der Client jetzt alle Nutzungsinformationen lokal, sodass diese Informationen jederzeit nachverfolgt werden können, unabhängig davon, ob das Clientsystem mit dem Netzwerk verbunden ist oder nicht. Auch der Clientcache wurde erweitert und verbessert, um so noch höhere Leistungen in Szenarios mit begrenztem Speicherplatz zu erzielen. Außerdem werden jetzt die Sequenzierung von nicht englischsprachigen Anwendungen, die Ausführung von App-V auf nicht englischsprachigen Betriebssystemen sowie die Lokalisierung in mehrere andere Sprachen unterstützt.

Integrieren von App-V in Configuration Manager
Für die Integration von App-V in SCCM 2007 R2 wurden einige Verbesserungen und neue Features in App-V 4.5 eingeführt. Wie bereits erwähnt, bieten die Virtualisierung und das Streaming einige Funktionen zum Bereitstellen von Anwendungen, die herkömmliche Softwarebereitstellungstools nicht besitzen. Ich will damit nicht sagen, dass App-V diese Tools ersetzen wird, sondern vielmehr, dass App-V diese Tools ergänzen und erweitern kann.
Mit dieser Integration erhalten Sie alle Skalierbarkeits-, Berichterstattungs-, Geräteerkennungs- und WAN-Features von SCCM zusammen mit allen Streaming- und Isolierungsfeatures von App-V. Hier einige Beispiele für Bereiche, die von der Integration dieser beiden Technologien profitieren:
Anwendungsbereitstellung – Die Integration von SCCM Version 2 unterstützt alle Funktionen für bedarfsweise Bereitstellung, Anwendungsroaming, anfängliche Startschwellenwerte und Bereitstellung der Anwendungen, ohne die Clientcomputer zu verändern.
Aktualisierungen – Die SCCM-Verteilungspunkte (Distribution Points, DPs) können einfach nur die Deltaänderungen virtueller Anwendungen bereitstellen, wenn Pakete aktualisiert werden. So wird die zentralisierte Fähigkeit geboten, virtualisierte Anwendungen mit einem einzigen Klick auf frühere Versionen zurückzusetzen.
Verwaltung – Mit Version R2 wurde ein neuer Assistent für die Ankündigung virtueller Anwendungen eingeführt, mit dem die Administratoren in der Lage sind, sowohl virtualisierte Anwendungen als auch herkömmliche Softwarepakete und Ankündigungen von einer einzigen Konsole aus bereitzustellen.
Verpackung – Anwendungen müssen nicht neu verpackt werden, wenn App-V in SCCM integriert wird. Die anfängliche Sequenzierung einer Anwendung muss mithilfe des App-V-Verfahrens außerhalb von SCCM vorgenommen werden, aber die Administratoren haben die Möglichkeit, vorhandene Pakete unter Zuhilfenahme von SCCM zu aktualisieren.
Lizenzierung – Virtuelle Anwendungen können zu Lizenzierungs- und Messzwecken mit den vorhandenen Tools in SCCM nachverfolgt werden.
BITS – SCCM bietet ein neues Verfahren zum Bereitstellen virtualisierter Anwendungen in App-V mit dem branchenüblichen BITS-Protokoll. Die SCCM-DPs sind zwar streamingfähig, aber unter Umständen ist das Streaming nicht die ideale Methode zum Bereitstellen virtualisierter Anwendungen. Beim Bereitstellen über SCCM haben Sie zwei Optionen. Sie können wahlweise das Standardstreaming verwenden oder auch die QoS-Features (Quality of Service) von BITS, um so die Bereitstellung noch besser zu steuern. Dies ist auch in Szenarios von Nutzen, in denen zunächst Informationen vorab in den Cache geladen werden sollen, bevor die Benutzer die virtuelle Anwendung starten.
Computerbereitstellungen – SCCM bietet die Möglichkeit, virtualisierte Anwendungen auf bestimmten Computern bereitzustellen und dabei die benutzerorientierte Vorgehensweise der App-V-Plattform weiter zu unterstützen. Dies kann günstig sein, wenn Sie virtuelle Anwendungen auf Laptops, Kiosks und Computern in Testumgebungen bereitstellen. Auch als Hilfe bei der Lizenzsteuerung ist dieses Verfahren von Nutzen, wenn die Lizenzierung Ihrer Software pro Gerät erfolgt, nicht für namentlich aufgeführte Benutzer.
Skalierbarkeit – Die Notwendigkeit, zwei separate Tools mit weitgehender Überlappung bereitzustellen, ist häufig ein Problem. Durch die Kombination der Skalierbarkeits- und WAN-Vorteile von SCCM und der Isolierungs- und Streamingvorteile von App-V sind Sie in der Lage, den vorhandenen SCCM zu nutzen, der ein einziges Tool für die Verwaltung und die Bereitstellung bietet, ohne die Komplexität noch weiter zu erhöhen.

Anthony Kinney ist als Technical Sales Professional zuständig für das Microsoft Desktop Optimization Pack. Er kam mit der Übernahme von Softricity im Jahr 2006 zu Microsoft. Während seiner Tätigkeit bei Softricity hat Anthony Kinney das erste Schulungsprogramm für SoftGrid (jetzt App-V) geschrieben und konzipiert. Sie können ihn unter Anthony.kinney@microsoft.com erreichen.


Virtualisierung
Gewährleisten hoher Verfügbarkeit für Hyper-V
Steven Ekren
Auf einen Blick:
  • Konsolidieren von Servern mittels Hyper-V
  • Sicherstellen hoher Verfügbarkeit für virtuelle Computer
  • Einrichten eines Failover für Windows Server 2008

Inhalt
Hohe Verfügbarkeit
Hosts und Gäste
Verfügbarkeit der Gäste
Erzielen hoher Verfügbarkeit für VMs
Voraussetzungen
Exemplarische Vorgehensweise für hohe Verfügbarkeit
Überlegungen
Die Servervirtualisierung steht in den Startlöchern, um in den IT-Abteilungen von Unternehmen ganz neue Möglichkeiten zu eröffnen, und Hyper-V mit Windows Server 2008 kann dies Wirklichkeit werden lassen. Die Konsolidierung von Servern auf einer geringeren Anzahl physischer Computer bietet enorme Vorteile durch Ressourcen- und Kosteneinsparungen, aber bei der Planung müssen zwei Hauptfaktoren berücksichtigt werden. Die Benutzer haben immer höhere Erwartungen an die Verfügbarkeit ihrer Software, und zwar sowohl bei Branchenanwendungen als auch bei Tools wie Messagingplattformen und Plattformen zur Zusammenarbeit. Außerdem können sich Probleme oder Fehler auf Servern erheblich stärker auf den Betrieb auswirken. Windows Server 2008 und Hyper-V bieten Lösungen, mit denen hohe Verfügbarkeit (High Availability, HA) sowohl für virtuelle Computer (virtual machine, VM) als auch für die in den VMs gehosteten Arbeitsauslastungen implementiert werden kann.

Hohe Verfügbarkeit
Verfügbarkeit bedeutet, dass die Benutzer auf ein System zugreifen können, um ihrer Arbeit nachzugehen. Mit der hohen Verfügbarkeit gehen beträchtliche Erwartungen einher, wie z. B. dass die Benutzer immer auf das System zugreifen können. Die hohe Verfügbarkeit wurde entworfen und implementiert, um Betriebskontinuität zu gewährleisten.
Hohe Verfügbarkeit für Hyper-V wird durch die Verwendung der Failovercluster-Features in Windows Server 2008 erreicht. Geplante und ungeplante Ausfallzeiten wirken sich gleichermaßen auf die hohe Verfügbarkeit aus, und das Failoverclustering kann die Verfügbarkeit der virtuellen Computer in beiden Kategorien deutlich erhöhen.
Virtuelle Computer können über den Failovercluster verwaltet werden, und der Failovercluster kann in virtuellen Computern zum Einsatz kommen, um dort die Arbeitsauslastungen zu überwachen und zu bewegen, die auf diesem VM gehostet werden. Ich werde beide Konfigurationsszenarios ausführlicher beschreiben, aber der Großteil dieses Artikels befasst sich mit der Verwaltung virtueller Computer. Zu Beginn sollten Sie sich jedoch die Randleiste „Nützliche Hyper-V-Begriffe“ ansehen.

Hosts und Gäste
Weil auf einem Hyper-V-System mehrere Betriebssysteme ausgeführt werden, kann es schwierig werden, zwischen den erörterten Schichten oder Betriebssystemen zu unterscheiden. Ich verwende den Begriff „Gast“ für das Betriebssystem und die Umgebung innerhalb eines Hyper-V-VM, die in einer untergeordneten Partition ausgeführt werden. Mit dem Begriff „Host“ bezeichne ich den physischen Computer, der vom Betriebssystem auf der übergeordneten Hyper-V-Partition verwaltet wird.
Die Hostverfügbarkeit behandelt die Probleme, die sich aus dem „Alles auf eine Karte setzen“-Szenario ergeben, zu dem die Serverkonsolidierung führen kann. Der Windows Server 2008-Failovercluster kann auf der übergeordneten Hyper-V-Partition (Host) konfiguriert werden, sodass untergeordnete Hyper-V-Partitionen (virtuelle Computer oder Gäste) auf ihre Integrität überwacht und zwischen den Knoten im Cluster verschoben werden können. Diese Konfiguration bietet die folgenden Hauptvorteile:
  • Wenn der physische Computer (auf dem sich Hyper-V und der VM befinden) aktualisiert, verändert oder neu gestartet werden muss, können die VMs auf andere Knoten im Cluster verschoben werden. Sobald der physische Computer wieder funktionsfähig ist, können die VMs wieder zurückverschoben werden.
  • Falls der physische Computer mit Hyper-V und den VMs ausfällt (z. B. durch einen Hauptplatinenfehler) oder erheblich nachlässt, werden die anderen Mitglieder im Windows-Failovercluster die Eigentümerschaft der VMs übernehmen und diese automatisch online schalten.
  • Wenn der VM ausfällt, kann er auf demselben Hyper-V-Server neu gestartet oder auf einen anderen Hyper-V-Server verschoben werden. Der Windows Server-Failovercluster erkennt dies und leitet automatisch Wiederherstellungsschritte ein, die auf den Einstellungen in den Ressourceneigenschaften des VM beruhen. Die Ausfallzeit wird aufgrund der automatisierten Erkennung und Wiederherstellung minimiert.
Abbildung 1 zeigt die möglichen Abläufe in solchen Situationen. Zuerst befindet sich VM2 auf Host A, dann wird VM2 auf Host B verschoben. Beachten Sie, dass der Knoten, dem die SAN-Speicher-LUN 2 gehört, bei dieser Verschiebung von Host A zu Host B wechselt. Um sicherzustellen, dass Ihre Lösung für hohe Verfügbarkeit Ihre Anforderungen erfüllt, überlegen Sie sorgfältig, wo die VMs untergebracht werden sollen. Denken Sie sowohl an die Kapazität als auch an die Leistung.
Abbildung 1 Ein virtueller Computer und sein Speicher werden auf einen neuen Host verschoben (zum Vergrößern auf das Bild klicken)
Die Kapazität der Knoten sollte ausreichend sein, um alle VMs zu hosten und den Ausfall oder die Entfernung von x Knoten aus der aktiven Clusterteilnahme zu verkraften. (x steht für die Anzahl der Knoten, die der Cluster verlieren kann, ohne dass er unfähig wird, alle VMs zu hosten.) Bei der Kapazität können Sie einige Knoten, die normalerweise keine VMs hosten, als Reserve bestimmen. Alternativ können Sie die VMs auf alle Knoten verteilen, wobei Sie darauf achten sollten, dass jeder Knoten genug zusätzliche Kapazität hat, um die Eigentümerschaft der VMs zu übernehmen und die VMs zu starten, wenn x Knoten ausfallen.
Aus Sicht der täglichen Leistung ist die Verteilung der VMs auf alle Knoten im Cluster sinnvoll. Wenn Knoten in Reserve gehalten werden und keine VMs hosten, nutzen die Knoten, auf denen sich die VMs befinden, mehr Ressourcen, was sich negativ auf die Leistung der VMs und der Verwaltungspartition auswirken kann. Die Verteilung der VMs auf die Knoten verringert die Last für die einzelnen Knoten und ermöglicht eine bessere Leistung der VMs und der Verwaltungspartitionen. Dies kann jedoch zu größeren Schwierigkeiten bei der Kapazitätsplanung führen. Verwaltungssoftware wie System Center Virtual Machine Manager 2008 bietet Berechnungshilfen für die Kapazität beim Ausfall von Knoten und bei der Platzierung der VMs.

Verfügbarkeit der Gäste
Bei der Verfügbarkeit der Gäste liegt der Schwerpunkt darauf, die auf einem VM ausgeführte Arbeitsauslastung hoch verfügbar zu machen. Häufige Arbeitsauslastungen sind beispielsweise Datei- und Druckserver, IIS und Branchenanwendungen. Die Analyse der Anforderungen für hohe Verfügbarkeit sowie der Lösungen für Arbeitsauslastungen in VMs läuft praktisch auf dieselbe Weise wie bei eigenständigen Servern ab. Die richtige Lösung ist abhängig von der jeweiligen Arbeitsauslastung.
Einige Arbeitsauslastungen können hohe Verfügbarkeit durch Windows-Netzwerklastenausgleich (Network Load Balance, NLB) erreichen, bei dem mehrere Server zu einem Pool mit einem gemeinsamen Netzwerknamen zusammengefasst werden. Die Clients stellen Verbindungsanforderungen über diesen virtuellen Netzwerknamen, und die Verbindungen werden zu einem der Knoten im NLB-Cluster hergestellt. Ein typisches Szenario mit NLB-Clustering ist der Aufbau von Webfarmen mit IIS, bei denen jedes einzelne System IIS mit denselben Webseiten sowie Zugriff auf dieselben Daten besitzt. NLB bietet Lastenausgleich sowie die Möglichkeit, Server zu Wartungszwecken oder bei Problemen aus der Mitgliedschaft zu entfernen, wodurch höhere Verfügbarkeit erzielt wird. Wenn Windows Server 2008 auf einem Hyper-V-VM (oder einer früheren Version von Windows Server mit NLB) ausgeführt wird, kann der Gast ein Mitglied eines NLB-Clusters mit anderen Gästen auf demselben oder auf anderen Hyper-V-Hosts sein.
Gäste, auf denen Windows Server 2008 ausgeführt wird, können mit dem Failovercluster-Feature in Windows hohe Verfügbarkeit für ihre Arbeitsauslastungen erzielen. Es gibt mehrere Vorteile bei der Verwendung von Windows-Failoverclustering in einem Gast (Gastclustering):
Zustandsüberwachung der Arbeitsauslastung Der Windows-Failovercluster umfasst einen Ressourcenmonitor, der Aufrufe an die dem Cluster zugeordnete Ressourcen-DLL vornimmt. Bei jeder Ressource wird mit der Zustandsüberwachung die Anwendung oder der Dienst getestet, die bzw. der von der Ressource verwaltet wird, um so die ordnungsgemäße Funktion sicherzustellen. Diese Überprüfungen werden in der Regel als IsAlive-/LooksAlive-Überprüfungen bezeichnet. Wenn die Ressource bei einem dieser Aufrufe scheitert, fällt auch die Ressource selbst aus. Je nach Konfiguration der Eigenschaften versucht die Ressource, den Dienst oder die Anwendung neu zu starten, oder der Dienst bzw. die Anwendung wird auf einen anderen Knoten im Windows-Failovercluster verschoben.
Wartung der virtuellen Computer Wenn die Konfiguration des VM geändert oder das Betriebssystem oder die Software aktualisiert oder geändert werden muss, ist es möglich, die Arbeitsauslastung auf einen anderen Knoten im Cluster zu verschieben und den VM entweder herunterzufahren oder zu aktualisieren, und das mit minimalen Auswirkungen für die Endbenutzer.
Wartung des Hostcomputers Wenn Wartungsarbeiten oder eine Aktualisierung der Software auf dem physischen Computer, auf dem ein Hyper-V-VM gehostet wird, anfallen und weitere Mitglieder des Windows-Failoverclusters auf anderen Hyper-V-Hosts vorliegen, ist es möglich, die Arbeitsauslastung im VM auf einen anderen Knoten im Cluster zu verschieben und diesen VM herunterzufahren, damit die Änderungen oder die Neustarts des physischen Servers durchgeführt werden können.
Ausfall des virtuellen Computers oder des Hostcomputers Beim Ausfall des physischen Hyper-V-Hosts oder des virtuellen Gastcomputers erkennen die anderen Knoten im Windows-Failovercluster, dass das Clustermitglied nicht mehr antwortet oder am Cluster teilnimmt. Die weiterhin funktionsfähigen Knoten schalten dann die Anwendungen oder die Dienste online, die auf dem ausgefallenen VM ausgeführt wurden.

Nützliche Hyper-V-Begriffe
Die folgende Liste mit Begriffen definiert die Komponenten oder Funktionen eines hoch verfügbaren Hyper-V-Systems (Hostcluster).
Übergeordnete Partition Allen Betriebssystemen, die auf einem Hypervisorserver ausgeführt werden, sind Hardwareressourcen zugeordnet, beispielsweise RAM, CPU und andere Systemkomponenten. In Hyper-V wird die Partition, die die Konfiguration vom Hypervisor und die Systemressourcen verwaltet, oft als übergeordnete Partition bezeichnet. Wenn die Hyper-V-Rolle konfiguriert ist und der Server neu gestartet wird, wird die Installation von Windows Server 2008, die das systemeigene Betriebssystem auf dem System war, zum Betriebssystem in der übergeordneten Partition des Hyper-V-Servers.
Untergeordnete Partition Eine isolierte Umgebung auf einem Hyper-V-Server, die konfiguriert wird, um ein Gastbetriebssystem aufzunehmen und Hardwareressourcen für dieses Betriebssystem zu bieten.
Hyper-V-Host Der physische Server, der Hyper-V und das Betriebssystem in der übergeordneten Partition hostet.
Virtueller Hyper-V-Computer Die Hyper-V-Konfigurationsinformationen und die Daten, mit denen eine untergeordnete Hyper-V-Partition gestartet und ausgeführt wird. Hierzu gehören die Konfigurationsinformationen zum Erstellen der untergeordneten Partition sowie die VHD-Dateien oder Pass-Through-Datenträger, auf denen sich die Daten dieser Partition befinden.
Pass-Through-Datenträger Ein Speichergerät, das in der Datenträgerverwaltung als physischer Datenträger sichtbar ist und für die exklusive Verwendung durch einen Hyper-V-Gast zugewiesen wird. Der Hyper-V-Gast stellt den Datenträger bereit und nutzt ihn als lokal angeschlossenes Speichergerät.
Virtuelle Festplatte (Virtual Hard Disk, VHD) Eine Datei, zu der eine untergeordnete Hyper-V-Partition eine Verbindung herstellt. Diese Datei ist im Betriebssystem als Speichergerät (Datenträger) sichtbar. Die VHD-Datei befindet sich auf einem Speichergerät, das von der übergeordneten Partition bereitgestellt wird: entweder einem direkt angeschlossenen Speichergerät oder auch einem Speicher, zu dem eine Verbindung über ein SAN, einen NAS oder einen SMB hergestellt wird.
Erzielen hoher Verfügbarkeit für VMs
Zum Konfigurieren eines virtuellen Computers für hohe Verfügbarkeit genügt es, den HA-Rollenassistenten in der Failovercluster-Verwaltung durchzuarbeiten. Virtuelle Hyper-V-Computer besitzen mehrere Hauptkomponenten, die in Betracht gezogen werden müssen, wenn sie als hoch verfügbar verwaltet werden sollen. Betrachten wir nun einige der wichtigen Konzepte und allgemeinen Voraussetzungen.
Failoverclusterknoten Jeder physische Server, der Teil eines Failoverclusters ist, wird als Knoten bezeichnet. Für das Hostclustering wird der Failovercluster-Dienst in Windows Server 2008 auf der übergeordneten Partition des Hyper-V-Systems ausgeführt. Damit ist es möglich, die in untergeordneten Partitionen auf denselben physischen Servern ausgeführten VMs als hoch verfügbare virtuelle Computer zu konfigurieren. Die virtuellen Computer, die für HA konfiguriert sind, werden als Ressourcen in der Failovercluster-Verwaltungskonsole aufgeführt.
HA-Speicher Hoch verfügbare virtuelle Computer lassen sich so konfigurieren, dass sie virtuelle Festplatten (Virtual Hard Disks, VHDs), Pass-Through-Datenträger und differenzierende Datenträger verwenden. Um das Verschieben von virtuellen Computern zwischen Failoverclusterknoten zu ermöglichen, muss Speicher vorhanden sein (der als Datenträger in der Datenträgerverwaltung aufgeführt ist), auf den jeder Knoten zugreifen kann, auf dem der VM gehostet wird und der durch den Failovercluster-Dienst verwaltet wird. Der Failovercluster sollte mit Pass-Through-Datenträgern als Datenträgerressourcen ergänzt werden, und auf den Datenträgern, die dem Failovercluster als Datenträgerressourcen hinzugefügt werden, müssen sich VHD-Dateien befinden.
VM-Ressource Failovercluster-Ressourcentyp, der den virtuellen Computer repräsentiert. Wenn die VM-Ressource online geschaltet wird, erstellt Hyper-V eine untergeordnete Partition, und das Betriebssystem auf dem virtuellen Computer wird gestartet. Die Offlinefunktion der VM-Ressource entfernt den VM aus Hyper-V auf dem Knoten, auf dem er gehostet wurde, und die untergeordnete Partition wird aus dem Hyper-V-Host entfernt. Wenn der virtuelle Computer heruntergefahren, angehalten oder in den gespeicherten Status versetzt wird, wird diese Ressource in den Offlinezustand versetzt.
VM-Konfigurationsressource Failovercluster-Ressourcentyp, der zur Verwaltung der Konfigurationsinformationen für einen VM dient. Für jeden virtuellen Computer gibt es eine VM-Konfigurationsressource. Eine Eigenschaft dieser Ressource enthält den Pfad zur Konfigurationsdatei, die alle nötigen Daten enthält, um den virtuellen Computer in den Hyper-V-Host aufzunehmen. Der Zugriff auf die Konfigurationsdatei ist erforderlich, damit eine VM-Ressource starten kann. Die Konfiguration wird von einer separaten Ressource verwaltet, weshalb die Konfiguration einer VM-Ressource sogar dann geändert werden kann, wenn der VM offline ist.
VM-„Dienste und Anwendungen“-Gruppe Um hohe Verfügbarkeit für einen Dienst oder eine Anwendung über Failoverclustering zu erzielen, müssen mehrere Ressourcen auf demselben Failoverclusterknoten gehostet werden. Um sicherzustellen, dass diese Ressourcen immer auf demselben Knoten sind und fehlerfrei zusammenarbeiten, werden die Ressourcen im Windows Server 2008-Failovercluster in einer Gruppe unter „Dienste und Anwendungen“ platziert. Die VM-Ressource und die VM-Konfigurationsressource für einen virtuellen Computer befinden sich stets in derselben „Dienste und Anwendungen“-Gruppe. Eine „Dienste und Anwendungen“-Gruppe kann auch einen oder mehrere physische Datenträgerressourcen (oder andere Speicherressourcen) mit VHDs oder Konfigurationsdateien oder Pass-Through-Datenträger enthalten.
Ressourcenabhängigkeiten Die VM-Konfigurationsressource muss online geschaltet werden, bevor die VM-Ressource online geschaltet (gestartet) wird. Umgekehrt darf die VM-Konfigurationsressource erst dann offline geschaltet werden, nachdem die VM-Ressource offline geschaltet (beendet) wurde. Um diese Online/Offline-Reihenfolge sicherzustellen, werden die Eigenschaften für die VM-Ressource so festgelegt, dass diese von der VM-Konfigurationsressource abhängig ist. Wenn es eine Speicherressource gibt, auf der sich die Datei für die VM-Konfigurationsressource oder VM-Ressource befindet, sollte die Ressource von diesen Speicherressourcen abhängig gemacht werden. Wenn der virtuelle Computer beispielsweise VHD-Dateien auf Datenträger G: und Datenträger H: verwendet, sollte die VM-Ressource von der Konfigurationsdateiressource, der Ressource für Datenträger G: und der Ressource für Datenträger H: abhängig sein.

Voraussetzungen
Für das Erzielen hoher Verfügbarkeit für virtuelle Hyper-V-Computer mithilfe des Failovercluster-Features in Windows Server 2008 gelten die folgenden drei Voraussetzungen:
  1. 1. Das Failovercluster-Feature in Windows Server 2008 muss für jeden Knoten im Cluster konfiguriert werden. Weitere Informationen zum Konfigurieren und Verwalten von Failoverclustern finden Sie in der Randleiste „Hyper-V-Ressourcen“.
  2. 2. Die Hyper-V-Rolle muss installiert werden. Die Hyper-V-Updates sollten installiert sein, und die Rolle sollte für jeden Knoten im Failovercluster konfiguriert werden (beachten Sie wiederum die Randleiste „Hyper-V-Ressourcen“). Hyper-V bietet ein Updatepaket, mit dem die Hyper-V-Serverkomponenten installiert werden, und ein weiteres Paket für die Installation der Hyper-V-Verwaltungskonsole. Sobald das Update für die Hyper-V-Serverkomponenten installiert ist, können Sie die Rolle über den Server-Manager oder ServerManagerCMD hinzufügen.
  3. 3. Für die virtuellen Computer muss freigegebener Speicher verfügbar sein. Der Speicher kann vom Failovercluster als integrierter Ressourcentyp eines physischen Datenträgers verwaltet werden, oder es kann eine Drittanbieterlösung zur Verwaltung des freigegebenen Speichers verwendet werden. Die Drittanbieterlösung muss dabei natürlich Windows Server 2008-Failovercluster unterstützen.

Exemplarische Vorgehensweise für hohe Verfügbarkeit
Im Folgenden sehen Sie, wie eine Lösung für hohe Verfügbarkeit eingerichtet wird. Der erste Schritt besteht darin, einen virtuellen Computer einzurichten. Konfigurieren Sie auf einem der Knoten im Failovercluster, auf dem die Hyper-V-Rolle installiert ist, mittels Hyper-V-Manager einen virtuellen Computer (siehe Abbildung 2). Verwenden Sie wahlweise einen neuen, manuell konfigurierten VM, oder importieren Sie einen bereits vorhandenen VM. Die VHDs sollten sich auf einem Datenträger befinden, der vom Windows Server 2008-Failovercluster verwaltet wird und der derzeit auf dem Knoten, auf dem der VM konfiguriert wird, online geschaltet ist.
Abbildung 2 Konfigurieren eines virtuellen Computers (zum Vergrößern auf das Bild klicken)
Versetzen Sie jetzt den virtuellen Computer in den Status „Beendet“. Fahren Sie den Computer hierzu herunter, schalten Sie ihn aus, oder versetzen Sie ihn in den Speicherstatus. Nur virtuelle Computer mit dem Status „Beendet“ können für die Verwaltung durch den Failovercluster konfiguriert werden.
Öffnen Sie die Failovercluster-Verwaltungskonsole (siehe Abbildung 3) auf einem beliebigen Server, auf dem die Windows Server 2008-Failovercluster-Rolle ausgeführt wird, oder auf einem Windows Vista-Client, auf dem die Remoteserver-Verwaltungstools (Remote Server Administration Tools, RSAT) ausgeführt werden. Stellen Sie eine Verbindung zum Failovercluster her. Wählen Sie hierzu die Aktion „Cluster verwalten...“, und wählen Sie dann einen Knoten oder den Clusternamen aus, oder wählen Sie die Option zum Aufbauen einer Verbindung zum Cluster auf dem Knoten, auf dem die Konsole ausgeführt wird.
Abbildung 2 Virtueller Computer in der Failovercluster-Verwaltungskonsole (zum Vergrößern auf das Bild klicken)
Wählen Sie in der Failovercluster-Verwaltungskonsole die Aktion „Dienst oder Anwendung konfigurieren...“. Der Assistent für hohe Verfügbarkeit wird geöffnet. Dieser Assistent führt Sie schrittweise durch das Konfigurieren von Diensten, Anwendungen oder virtuellen Computern, die durch den Failovercluster verwaltet werden sollen. Wählen Sie im Assistenten auf der Seite „Dienst oder Anwendung auswählen“ die Option „Virtueller Computer“ und dann die Option „Weiter“.
Auf der Seite „Virtuellen Computer auswählen“ werden alle virtuellen Computer aufgeführt, die auf einem Knoten im Failovercluster konfiguriert sind. Wählen Sie einen virtuellen Computer aus, und wählen Sie dann „Weiter“. Die Seite „Bestätigung“ im Assistenten zeigt jegliche Warnungen oder Fehler an. In diesem Schritt wird die Konfiguration des virtuellen Computers geprüft, um festzustellen, ob dieser als HA-Ressource konfiguriert werden kann. Außerdem wird sichergestellt, dass der VM auf den Knoten gehostet werden kann. Wenn Sie hier „Weiter“ wählen, wird der virtuelle Computer als hoch verfügbare Ressource in den Failovercluster aufgenommen.
Die Seite „Zusammenfassung“ enthält Informationen zu den Ergebnissen beim Hinzufügen des virtuellen Computers als hoch verfügbare Ressource, einschließlich aller eventuell aufgetretenen Warnungen. Mit der Schaltfläche „Bericht anzeigen“ rufen Sie Details zu den Aufgaben ab, mit denen die hohe Verfügbarkeit für den virtuellen Computer erzielt wurde, außerdem sämtliche Warnungen oder Fehler. Wählen Sie abschließend die Option „Fertig stellen“, um den Assistenten für hohe Verfügbarkeit zu schließen.
Wie das Fenster in Abbildung 3 zeigt, wird in der Failovercluster-Verwaltungskonsole ein Objekt mit dem Standardnamen „Virtueller Computer(x)“ im linken Fensterbereich unter dem Clusternamen und unter „Diensten und Anwendungen“ aufgeführt. Wenn Sie den virtuellen Computer in dieser Baumstruktur markieren, werden die Ressourcen, die zu dieser „Dienste und Anwendungen“-Gruppe gehören, im mittleren Fensterbereich der Konsole angezeigt. Wenn ein anderer virtueller Computer seine Dateien in demselben Speicher abgelegt hat wie der ausgewählte Computer, wird dieser virtuelle Computer ebenfalls in die Gruppe aufgenommen. Die VM-Ressource und die VM-Konfigurationsressource werden für jeden virtuellen Computer angezeigt, der in die Gruppe aufgenommen wurde.
Der Informationsfensterbereich für die „Dienste und Anwendungen“-Gruppe zeigt den Status, die Warnungen, die bevorzugten Besitzer und den aktuellen Besitzer für die Gruppe an. Der Knoten „Besitzer“ ist der Knoten, auf dem der virtuelle Computer derzeit konfiguriert ist oder ausgeführt wird. Wählen Sie die Aktion „Move Virtual Machine(s) to another node“ (Virtuelle Computer auf einen anderen Knoten verschieben), damit der virtuelle Computer offline geschaltet und dann auf einem anderen Knoten wieder online geschaltet wird. Es gilt allgemein als bewährte Methode, einen VM auf jeden Knoten zu verschieben, der im Failovercluster als Host fungieren könnte, um so sicherzustellen, dass der VM fehlerfrei verschoben und dann gestartet und ausgeführt werden kann.

Hyper-V-Ressourcen
  • Beschreibung des Updates für die endgültige Version der Hyper-V-Technologie für Windows Server 2008
  • Schritt-für-Schritt-Anleitung für Hyper-V: Testen von Hyper-V und Failoverclustering
  • Einführung in Failoverclustering für Windows Server 2008 (von Chuck Timon, TechNet Magazin, Juli 2008)
  • Der NLB-Host konvergiert auf virtuellen Hyper-V-Computern mit Windows Server 2008 nicht wie vorgesehen
  • Webcasts zu Windows 2008-Clustern
  • Die Microsoft-Unterstützungsrichtlinie für Windows Server 2008-Failovercluster
Überlegungen
Beachten Sie die folgenden wichtigen Punkte, wenn Sie virtuelle Computer für hohe Verfügbarkeit einrichten:
Speicher Wenn virtuelle Computer VHD-Dateien auf demselben freigegebenen Datenträger besitzen, werden sie in derselben „Dienste und Anwendungen“-Gruppe platziert, selbst wenn sie sich auf verschiedenen Volumes auf dem gleichen Datenträger befinden. Einer der Vorteile beim Freigeben des Datenträgers besteht darin, dass die Nutzung des verfügbaren freigegebenen Speicherplatzes verbessert wird.
Der Nachteil ist jedoch, dass bei jedem Verschieben eines virtuellen Computers alle virtuellen Computer in der Gruppe verschoben werden, unabhängig davon, ob die Verschiebung aufgrund der automatisierten Wiederherstellung nach einem Problem mit dem virtuellen Computer oder auf Anweisung eines Administrators stattfindet.
Laufwerkbuchstaben und GUIDs Volumes können ohne zugewiesene Laufwerkbuchstaben erstellt werden. Virtuelle Computer können diese Volumes verwenden, und die Volumes können vom Failovercluster verwaltet werden. Wenn Volumes auf einer Datenträgerressource vorliegen, die GUIDs statt Laufwerkbuchstaben verwenden, werden die GUIDs in der Clusterverwaltung angezeigt. Wenn Sie virtuelle Computer erstellen und den Pfad für die VHDs festlegen, muss die GUID im Pfad der GUID entsprechen, die in der Clusterverwaltung für das Volume aufgeführt ist. Ansonsten kann der virtuelle Computer ggf. nicht erfolgreich auf anderen Knoten im Failovercluster gestartet (online geschaltet) werden.
Es gibt mehrere Gründe, warum die GUIDs u. U. nicht übereinstimmen. Wenn ein Volume auf Knoten online geschaltet wurde, bevor diese als im Failovercluster verwaltete Datenträgerressource hinzugefügt wurden, kann das Volume auf jedem Knoten eine andere GUID haben. Ein Volume kann auch mehrere GUIDs auf einem einzigen Knoten besitzen. Wenn ein Datenträger in einen Failovercluster als physische Datenträgerressource aufgenommen wird, werden die genutzten Volume-GUIDs auf dem Knoten, bei dem der Datenträger online geschaltet ist, in den Eigenschaften für die Datenträgerressource vermerkt.
Die GUIDs für die Volumes werden einem Knoten hinzugefügt, sobald die Datenträgerressource online geschaltet wird. Damit ist sichergestellt, dass die GUID, die im Failovercluster für das Volume vermerkt ist, ein gültiger Pfad auf jedem Knoten ist, der den Datenträger online schaltet. Dieser Knoten enthält unter Umständen weitere GUIDs, die ebenfalls demselben Volume zugeordnet sind. Ein Benutzer könnte daher eine GUID finden, die für das Volume auf diesem Knoten gültig ist, aber dies ist nicht die GUID, die laut den Angaben im Failovercluster für das Volume auf anderen Knoten verwendet wird. Das Symptom dieses Problem besteht darin, dass eine VM-Ressource, meist die Konfigurationsressource, nicht online geschaltet werden kann und eine Fehlermeldung eingeblendet wird, dass der Pfad ungültig ist. Der Pfad in der Fehlermeldung enthält die GUID, die nicht im Cluster für das Volume verwaltet wird.
Bereitstellungspunkte Volumes, die in einem Ordner auf einem anderen Volume bereitgestellt werden, statt einen Laufwerkbuchstaben zuzuweisen oder eine GUID zu verwenden, können mit Hyper-V und Failoverclustern verwendet werden. Sowohl das bereitgestellte Volume als auch das Volume, das den Bereitstellungspunkt hostet, müssen auf demselben Failoverclusterknoten liegen. Daher müssen sich alle Datenträger, die zum Bereitstellungspunkt gehören, in der „Dienste und Anwendungen“-Gruppe in demselben Failovercluster befinden.
Wenn sich die Volumes auf demselben Datenträger befinden, ist dies offensichtlich kein Problem. Falls die Volumes auf verschiedenen Datenträgern liegen, gibt es jedoch definitiv ein Problem. Es ist ebenso offensichtlich, aber dennoch erwähnenswert, dass sowohl das bereitzustellende Volume als auch der Host für den Bereitstellungspunkt im freigegeben Speicher liegen müssen, der für die Verwaltung durch den Failovercluster konfiguriert ist.
Differenzierende Datenträger Alle VHD-Dateien, die zu differenzierenden Datenträgern gehören, müssen sich in freigegebenem Speicher in derselben „Dienste und Anwendungen“-Gruppe wie der VM befinden, der die differenzierenden Datenträger verwendet. In der einfachsten Konfiguration umfasst ein differenzierender Datenträger zwei VHDs. Eine VHD fungiert als übergeordnetes Element und enthält eine Datenmenge, die als Basis herangezogen wird. Die andere VHD ist ein unterordneter Datenträger, der dem übergeordneten Datenträger zugeordnet ist.
Der differenzierende Datenträger erscheint dabei wie der übergeordnete Datenträger. Wenn sich Daten auf dem übergeordneten Datenträger befinden, werden sie von dieser VHD gelesen. Alle Schreibvorgänge erfolgen auf der untergeordneten VHD. Wenn sich Daten auf dem untergeordneten Datenträger befinden, würde ein Lesevorgang für diese Daten auf die untergeordneten VHD verweisen.
Wenn ein VM so konfiguriert ist, dass sich die untergeordnete VHD auf freigegebenem Speicher befindet, die übergeordnete VHD dagegen entweder nicht auf dem freigegebenen Speicher in derselben Gruppe oder aber auf einem lokal angeschlossenen Speichergerät, wäre es nicht möglich, den VM zu starten (online zu schalten), wenn er auf einen anderen Knoten verschoben würde. Der Assistent für hohe Verfügbarkeit prüft, ob dieser Punkt auf dem VM fehlerfrei konfiguriert wurde. Ist dies nicht der Fall, sollte der Assistent eine Fehlermeldung ausgeben, wenn dieses Problem erkannt wird, was bei Änderungen an der VM-Konfiguration von Vorteil ist.

Steven Ekren ist leitender Programmmanager im Team für Windows Server-Failovercluster und hohe Verfügbarkeit. Steven Ekren war 12 Jahre lang beim Microsoft-Support tätig, wo er Unternehmenskunden bei der Implementierung und Problembehandlung für Windows Server-Failovercluster und Virtualisierungstechnologien zur Seite stand, unter anderem Windows Hyper-V, System Center Virtual Machine Manager, Microsoft Virtual Server und Microsoft Virtual PC.


Virtualisierung
Sicherung und Notfallwiederherstellung für die Servervirtualisierung
Adam Fazio
Auf einen Blick:
  • Überlegungen bei der Planung der Notfallwiederherstellung
  • Hochverfügbarkeitslösungen für die Notfallwiederherstellung
  • Sichern und Wiederherstellen mit Windows Server-BackupItem

Inhalt
Grundlagen der Notfallwiederherstellungsplanung
Notfallwiederherstellung und Virtualisierung
Konvertierung von physischen zu virtuellen Computern
Snapshots des virtuellen Computers
Sichern von Hyper-V
Windows Server-Sicherung
Sichern virtueller Computer mit WSB
Überlegungen
Wiederherstellen virtueller Computer mit WSB
Data Protection Manager
Skriptgesteuerte Sicherungen
DiskShadow
Schlussbemerkung
Mit der Weiterentwicklung der Servervirtualisierungstechnologie und der zunehmenden branchenweiten Akzeptanz erkennen Organisationen Vorteile, die weit über die beliebteste Virtualisierungsrechtfertigung hinausgehen: verringerte Infrastrukturkosten und eine erhöhte IT-Flexibilität. Das nächste Ziel besteht darin, mithilfe der Virtualisierungsplattform Notfallwiederherstellungsstrategien zu ermöglichen oder zu verbessern.
Weshalb ist die Bereitschaft zur Notfallwiederherstellung fortwährend eines der heißesten Themen für die IT-Branche? In Studien wird darauf hingewiesen, dass Unternehmen bei Ausfallzeiten einen Verlust von durchschnittlich 80.000 bis 90.000 Dollar pro Stunde erleiden und dass sehr wenige Unternehmen nach einem schwerwiegenden Datenverlust langfristig überleben. Dieser Artikel bietet anhand der Microsoft-Virtualisierungsplattform eine Einführung in die Notfallwiederherstellung sowie einen tieferen Einblick in die Optionen und Überlegungen zur Sicherung und Wiederherstellung für Windows Server 2008 Hyper-V.

Grundlagen der Notfallwiederherstellungsplanung
Die Notfallwiederherstellung ist der Prozess der Wiederherstellung wichtiger Dienste im Falle eines Ausfalls und sollte ein Teil des Geschäftskontinuitätsplans jedes Unternehmens sein. In solch einem Plan wird definiert, wie das Unternehmen während oder nach einem Notfall seinen Betrieb aufrechterhalten wird. Diese Pläne sind der Grundstein jeder Notfallwiederherstellungsinitiative.
Einige Anbieter behaupten, dass ihre Automatisierungstechnologie für die Notfallwiederherstellung den Bedarf an einem ausführlichen und gut geprobten Plan verringert oder überflüssig macht. Es trifft zwar zu, dass Automatisierung die Wiederherstellungszeiten verbessern und die Abhängigkeit von Eingriffen des Menschen verringern kann. An dieser Stelle ist es jedoch Zeit für eine öffentliche Bekanntmachung: Sie können das Risiko eines Notfalls mit Technologie allein nicht erfolgreich begrenzen. Die Personen und Prozesse sind immer so wichtig wie die Technologien.
Genau genommen, werden Sie es fast unmöglich finden, die richtigen Technologien auszuwählen, ohne zuerst alle Einschränkungen und Ziele zu kennen, die sich aus dem Notfallwiederherstellungsplan ergeben. Aus Platzgründen kann in diesem Artikel kein vollständiger Notfallwiederherstellungsplan definiert werden, aber die Elemente, die für die Auswahl der richtigen Technologien und Implementierungen notwendig sind, sollen hier hervorgehoben werden. Im Folgenden sollen einige wichtige Technologietreiber, die in keinem Notfallwiederherstellungsplan fehlen dürfen, kurz beschrieben werden.
Dienstdefinitionen und Priorisierung Was genau definiert den gesamten Dienst, den Sie zu schützen versuchen, und wie wichtig ist er für die Organisation? Abbildung 1 zeigt Beispiele für Unternehmensdienste, die wahrscheinlich in jedem Notfallwiederherstellungsplan vorkommen.
Abbildung 1 Beispiel für Dienstdefinitionen und Priorisierung
Dienst | Hauptbestandteile | Abhängigkeiten | Geschäftliche Verwendung | SLA
Öffentliche Website | Netzwerklastenausgleich, drei Webserver, zwei Datenbankserver | DNS, Netzwerk, Firewall, Verzeichnis, SAN-Speicher (Storage Area Network) | Produkterwerb und Auftragsverfolgung; eCommerce; Kundendienstportal; Unternehmensinformationen | 99.99%
Finanzsystem | Zwei Datenbankserver, ein Anwendungsserver | DNS, Netzwerk | Aufzeichnung des Unternehmensumsatzes wie durch Gesetze und Bestimmungen vorgeschrieben | 99.99%
E-Mail-System | Drei E-Mail-Server, ein Webserver | DNS, Netzwerk, Firewall, Verzeichnis | Unternehmenskommunikation; Kundendienst | 99.5%
Nachdem Sie die Dienste definiert haben, können Sie beginnen festzustellen, welche Systeme und Abhängigkeiten sich für welche Art von Notfallwiederherstellungsstrategien eignen. Es könnte sein, dass Sie nach einer Prüfung aller Dienste und Abhängigkeiten feststellen, dass Sie einige verschiedene Ebenen von Notfallwiederherstellungsfunktionen in Betracht ziehen müssen, da eine einzige Notfallwiederherstellungslösung für alle erfolgsentscheidenden Dienste zu teuer und komplex wäre.
Vereinbarungen zum Servicelevel Eine Vereinbarung zum Servicelevel (Service Level Agreement, SLA) ist eine Vereinbarung oder ein Vertrag zwischen dem Dienstanbieter (IT) und dem Kunden (der Organisation), die bzw. der die Verfügbarkeitsziele für einen bestimmten Dienst definiert. Diese können sehr lang oder recht kurz und bündig sein, wie z. B. „Das E-Mail-System wird während allgemeiner Geschäftszeiten zu 99,95 Prozent der Zeit und während nicht allgemeiner Geschäftszeiten zu 98 Prozent der Zeit verfügbar sein, ausschließlich geplanter Wartungszeiten, die monatlich berechnet werden.“ Meist werden SLAs in Stufen aufgeteilt, denen die IT-Dienste zugewiesen werden können, gemessen über einen vordefinierten Zeitraum.
Vereinbarungen zum Betriebslevel Vereinbarungen zum Betriebslevel (Operating Level Agreements, OLAs) beschreiben grundsätzlich die Vereinbarungen zwischen verschiedenen IT-Gruppen, die durch ihre Arbeit eine SLA unterstützen, einschließlich des Prozesses und der Antwortzeiten für die Bereitstellung ihrer Dienste. Angenommen, Sie haben eine erfolgsentscheidende Website mit einem SLA-Ziel von 99,99 Prozent, aber eine Datenbank, von der sie inhaltsmäßig abhängt, hat nur ein Verfügbarkeitsziel von 95 Prozent. Die OLA ist nützlich bei der Klärung dieser Nichtübereinstimmung und beim Ausrichten der IT-Teams auf das gleiche Ziel.
Wiederherstellungspunktziele und Wiederherstellungszeitziele Ein Wiederherstellungszeitziel (Recovery Time Objective, RTO) definiert, wie lange ein Dienst nicht verfügbar sein kann, bevor eine Lücke in der Kontinuität entsteht, während ein Wiederherstellungspunktziel (Recovery Point Objective, RPO) definiert, welches Maß an Datenverlust die Organisation als akzeptabel ansieht. Deshalb hat also ein Dienst mit einer SLA von 99 Prozent ein RTO von 7 Stunden und 18 Minuten pro Monat. Wenn Sie dies mit einem RPO von beispielsweise 24 Stunden kombinieren, können Sie jetzt Ihre Sicherungsverfahren und Zeitpläne genau definieren.
Datenaufbewahrungsrichtlinien Die Aufbewahrungsrichtlinien einer Organisation definieren genau, wie lange und wo die Sicherungen aufbewahrt werden. Sie werden meist von rechtlichen Anforderungen gesteuert.
Datenkategorisierung Außerdem muss die Natur der Daten in Betracht gezogen werden. Wenn Sie Ihre Daten in Kategorien einteilen, können Sie schnell sehen, dass nicht alle Daten die gleiche Priorität der Notfallwiederherstellung erfordern. Zum Beispiel kann eine einzige Datenbank andere Verfügbarkeitsanforderungen haben als ein Active Directory mit mehreren Domänencontrollern, die jeweils ein Replikat des Verzeichnisses enthalten. Ähnlich können Dateiserverdaten ganz andere Wiederherstellungsverfahren haben als CRM-Daten.
Notfallszenarios Es ist wichtig, alle Szenarios zu definieren, für die Sie planen wollen, da bei jedem Szenario andere Wiederherstellungsverfahren, Geschäftsauswirkungen und damit verbundene Kosten gegeben sind. Es ist hilfreich, alle möglichen Szenarios zu betrachten und dann zu entscheiden, auf welche Sie abzielen wollen, wenn Sie an Notfallwiederherstellungsplänen für Ihre Umgebung arbeiten:
  • Verlust einer gesamten Website
  • Verlust eines einzigen Datencenters
  • Verlust eines Systems (Betriebssystem- oder Hardwareausfall)
  • Verlust von Daten (Datenlöschung oder -beschädigung)
  • Verlust einer wichtigen Abhängigkeit
Offensichtlich gibt es sehr unterschiedliche Überlegungen, was das Wiederherstellen bei einem Verlust einer gesamten Website im Gegensatz zu einem einzigen System angeht. Außerdem empfiehlt sich die Definition der Schwellenwerte für die Wiederherstellung auf Grundlage Ihrer SLAs. Angenommen, dass beispielsweise eine gesamte Website aufgrund eines größeren ISP-Netzwerkausfalls offline ist. Wenn die SLA für den betroffenen Dienst 8 Stunden für die Dienstwiederherstellung vorsieht und 48 Stunden für die Datenwiederherstellung, würden Sie gegebenenfalls Dienstfailoververfahren für Ihre Sicherungswebsite durchführen, aber den Datenwiederherstellungsprozess nicht tatsächlich durchlaufen, da Sie ein recht schnelles Failback zur Produktionswebsite erwarten würden.
Nicht schlecht! All diese Arbeit, und von Technologie war noch gar nicht die Rede. Die Bedeutung des Planens darf nicht unterschätzt werden. Eine Implementierung der Notfallwiederherstellung ohne einen dokumentierten Plan ist nur eine „Notfallwiederherstellungshoffnung“.

Notfallwiederherstellung und Virtualisierung
Nachdem jetzt die Grundlagen für die Notfallwiederherstellungsplanung gelegt sind, bleibt die Frage, was die Virtualisierung beizutragen hat. Viele Unternehmen melden die Wiederherstellungszeiten für Berichtsdienste mit virtualisierten Servern in Minuten im Gegensatz zu Tagen oder Wochen für ihre physischen Entsprechungen. Weil das gesamte Serverbetriebssystem jetzt nur ein Satz von Dateien ist, die von der zugrunde liegenden Hardware abstrahiert werden, öffnen sich neue Türen, was die Wiederherstellbarkeit betrifft.
Eine heute weit verbreitete Theorie lautet, dass einige oder alle Notfallwiederherstellungsziele mit Hochverfügbarkeitslösungen erreicht werden können. Die Idee dahinter ist folgende: Bei Clusterknoten an separaten physischen Speicherorten, wobei Daten zwischen den Websites synchronisiert werden, kann im Falle eines Fehlers der passive Knoten wieder Vorgänge aufnehmen, und Sie können nahezu in Echtzeit wiederherstellen.
Dies ist wahr, aber wenn Sie sich die oben definierten Notfallszenarios ins Gedächtnis rufen, ist klar, dass dies keine Lösung für alle Szenarios ist. Sie benötigen eine Kombination von Technologien, um sich auf alle Szenarios vorzubereiten, und dies umfasst in der Regel eine Form von regelmäßigen Sicherungen. Hohe Verfügbarkeit schützt nicht vor allen möglichen Ausfällen und schließt den Bedarf an einer Form von Sicherungsstrategie nicht vollständig aus.
Hohe Verfügbarkeit mit Hyper-V erfordert, dass Sie die Speicherschicht sorgfältig planen, weil dies ein entscheidender Faktor ist, damit die Wiederherstellung erfolgen kann. Zum Beispiel hat ein 2-Knoten-Hyper-V-Cluster mit freigegebenem Speicher immer noch das Speichersubsystem und die Daten als einzelne Fehlerquelle, selbst wenn sich die Clusterknoten in separaten Datencentern befinden.
Sie sollten jedoch wissen, dass der gleiche 2-Knoten-Hyper-V-Cluster mit nicht freigegebenem Speicher den Speicher- oder Datenverlust auf einem der Knoten überleben kann. Dies erfordert Replikationstechnologien, um den Speicher in einem synchronisierten Zustand zu halten, und es ist mit einigen Komplexitäten verbunden (siehe Abbildung 2).
Abbildung 2 Mehrfachstandort-Hyper-V-Cluster (zum Vergrößern auf das Bild klicken)
Es gibt einige sehr interessante Entwicklungen im Bereich der Datenreplikation und -synchronisierung, die aber von Microsoft derzeit nicht angeboten werden. Es lohnt sich, auf der Seite zum Mehrfachstandortclustering in Windows Server 2008 (microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx) einen Blick auf die präsentierten Partner zu werfen. Eine andere Ressource ist der Windows Server-Katalog (siehe windowsservercatalog.com), in dem die Speicherhersteller mit für Windows Server 2008 zertifizierten Replikationstechnologien aufgelistet werden.
Wie Sie sehen können, gibt es viele verschiedene Hochverfügbarkeits- und Speicherkonfigurationen, die in Betracht kommen. Dies ist wiederum der Grund, weshalb Sie dafür sorgen müssen, dass Ihre Geschäftsanforderungen definiert sind, sodass diese die technischen Anforderungen steuern und nicht umgekehrt.

Konvertierung von physischen zu virtuellen Computern
Virtualisierung bietet offensichtlich eine einmalige Wiederherstellungsflexibilität, aber was ist mit physischen Systemen, die keine guten Virtualisierungskandidaten sind? Zu System Center Virtual Machine Manager (SCVMM) gehört die Möglichkeit, Konvertierungen von physischen zu virtuellen (P2V) Windows-Servern durchzuführen, die einen startbaren virtuellen Hyper-V-Computer ergeben, der ein genaues Replikat des physischen Quellservers ist. Jetzt können Sie diesen virtuellen Computer so wie seine virtualisierten Entsprechungen auf dem Campus oder im restlichen Land replizieren und ähnliche Wiederherstellungszeiten erreichen.
Dieser Ansatz unterscheidet sich insofern von einer traditionellen Bare-Metal-Wiederherstellung, als Ihr Wiederherstellungsspeicherort nicht mehr die gleiche Anzahl oder die gleiche Art physischer Systeme wie Ihr Produktionsspeicherort benötigt. Sie können also Ihre Wiederherstellungshardware überbeanspruchen und sie nach Bedarf anpassen, je nachdem welche Auswirkung der Notfall hat.
Obwohl SCVMM keinen Planer für P2V-Konvertierungen enthält, da die grafische Benutzeroberfläche vollständig auf Grundlage von Windows PowerShell ausgeführt wird, kann dies problemlos mit dem New-P2V-Cmdlet programmiert werden. Genau genommen, zeigen alle Assistenten in SCVMM den zur Ausführung eines Auftrags verwendeten Code an, und Sie können den Code von einer Test-P2V in Ihrer Umgebung kopieren und sie für die zukünftige automatisierte Verwendung ändern. Abbildung 3 zeigt einen Beispielcode. Sie können den SCVMM P2V-Assistenten in Ihrer Umgebung ausführen, um ein eindeutiges, anpassbares Windows PowerShell-Skript zu erhalten.
Abbildung 3 Vom SCVMM-P2V-Assistenten bereitgestellter Code
$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>"
-Credential $Credential -RunAsynchronously

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F"
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External"
-MachineConfig $MachineConfig

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM
-UseHardwareAssistedVirtualization $false -StopAction SaveVM

Snapshots des virtuellen Computers
Obwohl er technisch gesehen keine Sicherung darstellt, stellt ein Snapshot eines virtuellen Computers einen Zeitpunkt bereit, den Sie wiederherstellen können, indem Sie differenzierende Datenträger und eine Kopie der Konfigurationsdatei des virtuellen Computers verwenden. Wenn der Notfall zufällige Datenlöschungen innerhalb des virtuellen Computers umfasst, kann dies als ein Notfallwiederherstellungsfeature betrachtet werden, da der virtuelle Computer auf den Snapshot zurückgesetzt und der Schaden rückgängig gemacht werden kann. (Snapshots des Volumeschattenkopie-Diensts (Volume Shadow Copy Service, VSS) werden weiter unten behandelt.)

Sichern von Hyper-V
Hostbasierte Sicherungen Ein interessanter Vorteil, den die Servervirtualisierung bietet, ist die Aussicht darauf, die virtualisierten Systeme nicht mehr individuell sichern zu müssen. Nun, da diese Systeme einfach Dateien sind, die sich auf dem Dateisystem eines Hosts befinden, könnten Sie einfach eine Sicherungskopie der Dateien erstellen und hätten alles erledigt, oder? Nicht so ganz. Weil es sich um Livecomputer handelt, die aus speicherinternen Daten, Daten auf Datenträgern, Systemkonfigurationen und offenen Dateien bestehen, muss einiges beachtet werden. Wie wird also die Konsistenz der Sicherungsdaten gewährleistet angesichts all dieser beweglichen Teile?
Eine erhebliche Verbesserung der Windows Server-Sicherung ging mit Windows Server 2003 und der Veröffentlichung von VSS einher. VSS bietet einen Standardsatz erweiterbarer APIs, die VSS-Schreiber (Hooks in Anwendungen und Diensten, die für die Bereitstellung konsistenter Schattenkopien nützlich sind) verwenden, um Sicherungen offener Dateien und Anwendungen zu erstellen. Mit dem VSS, den VSS-Anbietern und -Schreibern kann die Sicherungsanwendung sehr schnell eine zeitpunktgenaue Kopie eines Volumes erstellen, eine Kopie, die die Anwendung erkennt und entsprechend verarbeiten kann.
Hyper-V verfügt über seinen eigenen VSS-Schreiber, der Softwareherstellern ermöglicht, überzeugende Sicherungslösungen zu erstellen. Der Schreiber ermöglicht, dass Sicherungsanwendungen hostbasierte VSS-Sicherungen aktuell ausgeführter virtueller Computer erzielen. Wenn in dem im virtuellen Computer ausgeführten Betriebssystem die Hyper-V-Integrationskomponenten und der VSS (verfügbar in Windows XP SP1 und Windows Server 2003 und höher) installiert sind, findet die hostbasierte Sicherung so statt, als ob sie innerhalb des Gasts ausgeführt wird. Die Sicherung wird durchgeführt, während der virtuelle Computer ausgeführt wird, und die Daten sind konsistent (siehe Abbildung 4).
Abbildung 4 VSS-Sicherung (zum Vergrößern auf das Bild klicken)
Wenn das Gastbetriebssystem jedoch die Integrationskomponenten oder den VSS nicht unterstützt, erfordert der Sicherungsprozess, dass der Gastcomputer in einen gespeicherten Zustand versetzt wird und dass ein hostbasierter VSS-Snapshot der Datendateien des virtuellen Computers erstellt wird, der für eine zeitpunktgenaue Wiederherstellung verwendet werden kann. Bei VSS-Snapshots mit gespeichertem Zustand fällt eine Ausfallzeit des virtuellen Computers an (kann in der Regel auf 5–10 Minuten begrenzt werden), wobei vollständige Sicherung-auf-Band-Verfahren anhand der VSS-Kopie der Daten stattfinden.
Gastbasierte Sicherungen In einer physischen Umgebung müssen Server und Anwendungen individuell gesichert werden, und solche Sicherungen können sicherlich in einem virtualisierten Datencenter fortgesetzt werden. In dieser Situation müssen die gleichen Überlegungen berücksichtigt werden wie beim Erstellen einer Sicherungskopie eines virtuellen Computers, wie z. B. Netzwerkkapazitätsanforderungen für netzwerkbasierte Sicherungen und Leistungsauswirkungen auf das System während des Sicherungsfensters. Mit gastbasierten Sicherungen können Sie eine dedizierte physische Netzwerkschnittstellenkarte (Network Interface Card, NIC) im Host einrichten, die an ein virtuelles Netzwerk gebunden ist, das alle Gäste verwenden.

Windows Server-Sicherung
Windows Server 2008 umfasst die VSS-fähige Windows Server-Sicherung (Windows Server Backup, WSB), die verwendet werden kann, um host- und gastbasierte Hyper-V-Sicherungen Ihrer virtuellen Computer durchzuführen. Weil sie vollständig VSS-fähig ist, kann sie hostbasierte Sicherungen Ihrer virtuellen Computer durchführen, was natürlich vorzuziehen ist.
Bei virtuellen Computern ohne installierte Integrationskomponenten wird VSS jedoch nicht verwendet. In dem Fall stehen Ihnen einige Optionen zur Verfügung. Sie können weiterhin WSB verwenden, um eine Sicherungskopie eines virtuellen Computers zu erstellen, auf dem die Integrationskomponenten nicht installiert sind. Das heißt, der Zustand des virtuellen Computers wird gespeichert, und die Sicherung erfasst dann die virtuellen Datenträger und Konfigurationsdateien des virtuellen Computers.
Dies ist jedoch unter Umständen bei einer Anwendung wie z. B. Exchange nicht wünschenswert, weil die Anwendung nicht erkennt, dass eine Sicherung ausgeführt wurde, sodass Anwendungsprotokolle nicht gekürzt werden. Außerdem fällt auf dem virtuellen Computer eine Ausfallzeit an, die je nach Dauer der Sicherung unterschiedlich ausfällt.
Alternativ kann eine Sicherung von innerhalb des virtuellen Computers ausgeführt werden, so als ob es sich um einen physischen Computer handelt, wobei entweder NTBackup oder WSB verwendet wird, je nach Betriebssystem des virtuellen Computers. Als Nächstes wird untersucht, wie WSB für unterstützte Gäste verwendet wird, auf denen die Integrationskomponenten installiert sind.

Sichern virtueller Computer mit WSB
Hyper-V registriert seinen VSS-Schreiber nicht automatisch für die Verwendung mit WSB. Sie müssen den in Abbildung 5 gezeigten Registrierungsschlüssel und -wert manuell hinzufügen, damit WSB eine Hyper-V-Sicherung unterstützt. Sie können sie über die Befehlszeile hinzufügen, etwa so:
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v
Abbildung 5 Schlüssel und Wert für das Registrieren des Hyper-V-VSS-Schreibers
Pfad | Registrierungsschlüssel oder -wert | Typ
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} | Schlüssel | Nicht zutreffend
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier | Wert | REG_SZ (z. B. Hyper-V)
Dies erfordert keinen Neustart, da WSB diesen Schlüssel/Wert zur Sicherungslaufzeit sucht. Der folgende Befehl wird angezeigt, wenn der Eintrag festgelegt wurde:
reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s
Hier ist die Vorgehensweise zum Installieren von WSB. Klicken Sie auf „Start“ | „Server-Manager“. Klicken Sie im linken Fensterbereich auf „Features“ und anschließend im rechten Fensterbereich auf „Features hinzufügen“. Erweitern Sie auf der Seite „Features auswählen“ die Windows Server-Sicherungsfeatures, und aktivieren Sie die Kontrollkästchen für Windows Server-Sicherung und Befehlszeilentools. Führen Sie jetzt die folgenden Schritte aus, um Ihre Sicherung zu konfigurieren:
  1. Gehen Sie zu „Start“ | „Verwaltung“ | „Windows Server-Sicherung“.
  2. Wenn Sie eine Sicherungskopie eines Remotehosts erstellen, wählen Sie „Verbindung mit anderem Computer herstellen“ aus, und geben Sie den Hyper-V-Host ein.
  3. Wählen Sie entweder „Einmalsicherung“ oder „Sicherungszeitplan“ aus.
  4. Wählen Sie die Sicherungskonfiguration aus, entweder „Vollständiger Server“ oder „Benutzerdefiniert“. Wenn Sie „Benutzerdefiniert“ auswählen, stellen Sie sicher, dass Sie alle Volumes abrufen, die Daten enthalten, die sich auf den zu sichernden virtuellen Computer beziehen, einschließlich der Konfigurationsdaten, der virtuellen Datenträger und der Snapshots des virtuellen Computers.
  5. Wählen Sie den Speicherort aus, um die Sicherung zu speichern.
  6. Wählen Sie entweder „Vollständige VSS-Sicherung“ oder „VSS-Kopiesicherung“ aus. Wählen Sie für hostbasierte Sicherungen, bei denen keine anderen Sicherungen mit den virtuellen Computern stattfinden, die Option „Vollständige VSS-Sicherung“ aus.
  7. Wählen Sie, nachdem Sie die Details bestätigt haben, die Option „Sicherung“ aus.
Überlegungen
  • Sie müssen eine Sicherungskopie aller Volumes erstellen, die sich auf einen virtuellen Computer beziehen, einschließlich Virtueller Festplatten (Virtual Hard Disks, VHDs), Konfigurationsdateien und Snapshots virtueller Computer.
  • Wenn Sie einen Sicherungszeitplan erstellen, müssen Sie ein dediziertes lokales Volume verwenden, das ausschließlich von WSB formatiert und verwendet wird. Wenn Sie im Gegensatz dazu einen Einmalsicherungsauftrag durchführen, können Sie die Sicherung auf einem nicht dedizierten lokalen Volume, einem Wechseldatenträger oder einer Netzwerkfreigabe speichern.
  • Wenn die Integrationskomponenten nicht innerhalb des zu sichernden virtuellen Computers installiert sind, speichert WSB den Zustand des ausführenden virtuellen Computers, um die Datenkonsistenz der Sicherung sicherzustellen.
  • Nach Abschluss ist der Sicherungssatz übertragbar und kann mit jedem Hyper-V-Host verwendet werden.
Wiederherstellen virtueller Computer mit WSB
Obwohl WSB die Fähigkeit hat, einzelne Dateien wiederherzustellen, verwendet dieses Feature nicht VSS und könnte deshalb eine inkonsistente Wiederherstellung zur Folge haben, wenn der virtuelle Computer zum Zeitpunkt der Sicherung ausgeführt wurde. Zum Wiederherstellen gerade ausgeführter virtueller Computer müssen Sie das gesamte Volume (bzw. alle Volumes) wiederherstellen.
Gehen Sie hierfür zu „Start“ | „Verwaltung“ | „Windows Server-Sicherung“, und wählen Sie im Aktionsbereich die Option „Wiederherstellen“ aus. Wählen Sie den Server aus, der die wiederherzustellenden Daten enthält (den Server, auf dem sich die WSB-Sicherungsdaten befinden), und wählen Sie das Datum der wiederherzustellenden Daten aus. Jetzt können Sie den Wiederherstellungstyp auswählen.
Hier muss eine Entscheidung getroffen werden. Wenn Sie den gesamten virtuellen Computer benötigen, einschließlich seiner Konfiguration, der Snapshots und der virtuellen Datenträger (z. B. bei einem vollständigen Hostausfall), wählen Sie die Anwendungswiederherstellung und anschließend „Hyper-V“ aus (siehe Abbildung 6). In diesem Fall steht Ihnen die Option zum Wiederherstellen einzelner Dateien nicht zur Verfügung. Sie müssen alles wiederherstellen, was in diesem Sicherungssatz enthalten ist. Beachten Sie, dass dadurch die vorhandenen Konfigurationsdaten von Hyper-V und des virtuellen Computers, die sich seit der Sicherung geändert haben, nicht überschrieben werden.
Abbildung 6 Wiederherstellen einer Hyper-V-Sicherung (zum Vergrößern auf das Bild klicken)
Wenn Sie nur die VHD benötigen und die Konfigurationsdaten und Snapshots für den virtuellen Computer unbeschädigt sind, können Sie unter „Dateien und Ordner“ die benötigte einzelne VHD-Datei auswählen. Beachten Sie, dass bei diesem Prozess der VSS-Schreiber nicht verwendet wird. Die Sicherung des virtuellen Computers hätte dies berücksichtigen und seinen Zustand als Erstes speichern müssen.
Wenn Sie einen vollständigen System- und Datenverlust erlitten haben und den Hyper-V-Host selbst wiederherstellen müssen, einschließlich des Windows Server 2008-Betriebssystems und aller darin ausgeführten virtuellen Computer, müssen Sie in der Windows-Wiederherstellungsumgebung starten und Ihre Wiederherstellung von dort aus durchführen. Dies kann vom Windows Server 2008-Setupdatenträger oder einer vorkonfigurierten Datenträgerpartition aus durchgeführt werden.

Data Protection Manager
Es wurden für Hyper-V-Hosts und -Gäste Sicherungs- und Wiederherstellungsschritte untersucht und Überlegungen angestellt. Dabei wurde die zuverlässige und kostenlose integrierte Windows Server-Sicherung verwendet, aber WSB ist keine für Unternehmen geeignete Datenschutzlösung. Wo WSB endet, beginnt Data Protection Manager (DPM) 2007 SP1. Derzeit ist seine Veröffentlichung gegen Ende 2008 geplant. DPM SP1 wird Hyper-V unterstützen und einige überzeugende Features bieten:
  • Eine einzige Verwaltungskonsole für alle Hyper-V-Hosts und -Gäste.
  • Kontinuierlicher Datenschutz, der in 15-minütigen Abständen VSS-basierte Snapshots erstellt und dabei nur die geänderten Anteile berücksichtigt.
  • Hyper-V-Cluster-Erkennung, die der Sicherung ermöglicht, den Bewegungen des virtuellen Computers zwischen Clusterknoten zu folgen.
• Replikation von DPM-Server zu DPM-Server.
  • Unterstützung für Datenträger und Bandmedien (Datenträger zu Datenträger, Datenträger zu Band oder Datenträger zu Datenträger zu Band).
  • Sicherungs- und Wiederherstellungsfunktionen über das ganze Spektrum der Daten hinweg, einschließlich Hyper-V-Hosts und -Gästen; agentlose VSS-Sicherungen aktuell ausgeführter Gäste; Unterstützung für das Wiederherstellen einzelner virtueller Computer; Failoverclusterdaten; erstklassige anwendungsspezifische Features für SQL Server, Exchange, SharePoint, Hyper-V und Virtual Server.
  • Skripterstellung vor und nach der Sicherung.
Wenn Sie derzeit eine Drittanbieter-Sicherungslösung verwenden, halten Sie nach Updates für die Anwendung Ausschau, denn die meisten Anbieter arbeiten hart daran, hostbasierte Hyper-V-Lösungen auf den Markt zu bringen.

Skriptgesteuerte Sicherungen
WSB enthält eine Befehlszeilenschnittstelle (WBadmin.exe) und einen Satz von Windows PowerShell-Cmdlets für die Verwendung bei der Skripterstellung. Beim Verwenden dieser Cmdlets werden die gleichen Sicherungsregeln angewendet wie oben beschrieben. Auch hier muss der Hyper-V-VSS-Schreiber über die Registrierung manuell registriert werden.
Abbildung 7 zeigt einige WBAdmin-Befehle. Die vollständige WBAdmin-Dokumentation finden Sie unter go.microsoft.com/fwlink/?LinkId=124380. Wie Sie sehen können, gibt es nichts in WBAdmin, um die Sicherungsrichtlinie selbst zu konfigurieren, aber es gibt ein Windows PowerShell-Snap-In zum Verwalten dieser Einstellungen. Sie können mit dem folgenden Befehl testen, ob dieses Snap-In registriert ist:
Get-PSSnapin -Registered
Abbildung 7 WBAdmin-Befehle
WBAdmin-Befehle | Beschreibung
ENABLE BACKUP | Ermöglicht oder ändert eine geplante tägliche Sicherung.
DISABLE BACKUP | Deaktiviert das Ausführen geplanter täglicher Sicherungen.
START BACKUP | Führt eine Sicherung durch.
STOP JOB | Beendet die derzeit ausgeführte Sicherung oder Wiederherstellung.
GET VERSIONS | Listet Details der Sicherungen auf, die von einem bestimmten Speicherort wiederhergestellt werden können.
GET ITEMS | Listet Elemente auf, die in der Sicherung enthalten sind.
START RECOVERY | Führt eine Wiederherstellung durch.
GET STATUS | Meldet den Status des derzeit ausgeführten Auftrags.
GET DISKS | Listet die Datenträger auf, die derzeit online sind.
START SYSTEMSTATERECOVERY | Führt eine Systemstatuswiederherstellung durch.
START SYSTEMSTATEBACKUP | Führt eine Systemstatussicherung durch.
DELETE SYSTEMSTATEBACKUP | Löscht die Systemstatussicherungen.
Sie können Folgendes verwenden, um ein Snap-In namens „Windows.ServerBackup“ zu laden:
Add-PSSnapin windows.serverBackup
Nachdem es geladen ist, haben Sie Zugriff auf die Windows PowerShell-Cmdlets für WSB (siehe Abbildung 8). Führen Sie für eine ausführliche Beschreibung der einzelnen Cmdlets den folgenden Befehl aus:
Get-Command -PSSnapin windows.serverBackup | select name | get-help –full
Abbildung 8 Cmdlets für die Windows Server-Sicherung
Cmdlet | Beschreibung
Add-WBBackupTarget | Fügt der Sicherungsrichtlinie ein Sicherungsziel hinzu.
Add-WBVolume | Fügt der Sicherungsrichtlinie ein Volume hinzu.
Get-WBBackupTarget | Ruft Sicherungsziele aus einer Richtlinie ab.
Get-WBDisk | Ruft alle Datenträger ab.
Get-WBPolicy | Ruft die aktuelle Sicherungsrichtlinie ab.
Get-WBSchedule | Ruft den Sicherungszeitplan in der Richtlinie ab.
Get-WBSummary | Ruft den Sicherungsverlauf und die Zusammenfassung ab.
Get-WBVolume | Ruft alle Volumes ab.
New-WBBackupTarget | Erstellt ein neues Sicherungsziel.
New-WBPolicy | Erstellt eine neue leere Richtlinie.
Remove-WBBackupTarget | Entfernt ein Sicherungsziel aus der Richtlinie.
Remove-WBPolicy | Löscht die Sicherungsrichtlinie.
Remove-WBVolume | Entfernt ein Volume aus der Richtlinie.
Set-WBPolicy | Speichert das WBPolicy-Objekt, um eine geplante Sicherung zu erstellen.
Set-WBSchedule | Setzt den Zeitplan auf die Sicherungsrichtlinie.

Es gibt ein anderes Dienstprogramm, das in Windows Server 2008 integriert ist, das auch den Hyper-V-VSS-Schreiber verwenden und Ihren Skripterstellungsoptionen Flexibilität geben kann. DiskShadow.exe ermöglicht, dass eine Schattenkopie erstellt und als Laufwerk bereitgestellt werden kann, wodurch Administratoren bei der Sicherung eine größere Auswahl haben als beim Verwenden von WSB. Denken Sie unbedingt daran, dass DiskShadow keine Eingabe über die Windows PowerShell-Pipeline akzeptiert. Stattdessen erfordert es, dass Befehle durch ein Skript übermittelt werden, was folgendermaßen aussehen könnte:
Delete Shadows Volume C:
Set Context Persistent
Begin Backup
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow
Create
End Backup
Expose %MyShadow% X:
Exit
Dieses Skript löscht zuerst alle vorhandenen Schattenkopien des Laufwerks C:, und stellt dann sicher, dass die Schattenkopie beibehalten wird, nachdem DiskShadow ausgeführt wurde. Als Nächstes erstellt es einen Transaktionsblock. Falls einer der Schritte fehlschlägt, schlägt der ganze Prozess fehl. In diesem Block überprüft DiskShadow, ob der Schreiber für Hyper-V geladen ist, und fügt Laufwerk C: der Liste der zu sichernden Laufwerke hinzu.
Laufwerk C: ruft eine GUID ab, um ihn zu identifizieren, und diese GUID wird in einer Umgebungsvariablen gespeichert, die „MyShadow“ genannt wird. Sobald dies abgeschlossen ist, ist die Schattenkopie erstellt.
Die Sicherung wird mithilfe der Umgebungsvariablen als Laufwerk X: verfügbar gemacht. Mit den Daten auf X: kann Verschiedenes durchgeführt werden, und dann kann DiskShadow erneut mit dem Befehl „Unexpose X“ ausgeführt werden, um das Laufwerk zu entfernen.
Beachten Sie, dass das Wiederherstellen virtueller Computer für Hyper-V, die über DiskShadow gesichert wurden, derzeit ein manueller Prozess ist (der virtuelle Computer muss erneut aufgebaut werden, Snapshots werden nicht aufbewahrt und so weiter). Dies hat zwar einige offensichtliche Nachteile, aber die Daten sind geschützt.
Die Notfallwiederherstellung kann ein anstrengender Prozess sein, der scheinbar nie ein Ende hat. Die Servervirtualisierung bringt jedoch neue Möglichkeiten mit sich, sowohl aufgrund der Technologien als auch wegen des kostengünstigeren Einstiegs. Microsoft bietet nicht nur Virtualisierung, sondern ein gesamtes Ökosystem. Die Kombination aus Servervirtualisierungsplattform und System Center-Produktfamilie bietet ganzheitlichere Lösungen angesichts der zunehmenden komplexen Herausforderungen, denen Organisationen gegenüberstehen. Dazu gehört die Notfallwiederherstellung.
Ich möchte James O'Neill für seinen Beitrag zu diesem Artikel danken.

Adam Fazio fing vor 2 Jahren bei Microsoft Consulting Services an und ist jetzt für den US-amerikanischen öffentlichen Sektor tätig. Er stand 10 Jahre lange im Dienst der IT-Branche und hat an verschiedenen Infrastrukturprojekten und Datencentervorgängen für Fortune 100-Unternehmen und neu gegründete Internetfirmen gearbeitet. Adam Fazio ist derzeit der Leiter für technische Eskalationen für das globale Virtualization Rapid Deployment Program bei Microsoft.


Virtualisierung
Wichtige Tools zum Planen Ihrer virtuellen Infrastruktur
Jay Sauls und Baldwin Ng
Auf einen Blick:
  • Kosteneindämmung
  • Bestandserfassung von Computern
  • Festlegen von CPU, Datenträger-E/A und Netzwerkauslastung

Inhalt
Wichtige Merkmale des Tools
Ermitteln des Vorhandenen
Bestimmen der aktuellen Verwendung
Empfehlungen für die Serverplatzierung
Virtuelle Computerkonfiguration
Einschränkungen für die Platzierung
Ihre Optionen
Anforderungen
Zusammenfassung
Die Virtualisierung ist keine neue Technologie, aber sie dringt heute in viele neue Bereiche vor, die weit über die in den sechziger Jahren von IBM entwickelte Plattformvirtualisierung hinausgehen. Ein Hauptgrund für dieses schnelle Wachstum ist das Potenzial von Virtualisierungstechnologien beim Eindämmen von Kosten im Datencenter und beim gesamten IT-Betrieb. Bei steigenden Energiekosten und zunehmendem Appetit nach mehr IT-Diensten in verschiedenen Teilen Ihrer Organisation könnte es schwierig sein, mit dem Serverwachstum mitzuhalten und gleichzeitig die Betriebskosten niedrig zu halten. Hier kann die Virtualisierung helfen. Microsoft und andere Softwarehersteller haben neue Technologien einschließlich Server-, Desktop- und Anwendungsvirtualisierung entwickelt, die virtuelle Ressourcen besser verfügbar machen.
In diesem Artikel geht es um ein Toolset, das Ihnen bei Ihren Virtualisierungsprojekten helfen kann: das Microsoft Assessment and Planning Toolkit (MAP), das Mitglied der der Microsoft Solution Accelerators-Familie ist. Was sind Solution Accelerators? Einfach ausgedrückt, sind es Automatisierungstools und Anleitungen, die Sie für fast jedes IT-Projekt benötigen. Solution Accelerators sind kostenlose, maßgebliche Ressourcen, die Ihnen helfen, Ihre IT-Infrastruktur proaktiv zu planen, bereitzustellen und zu betreiben, angefangen bei Desktops bis hin zu Servern, und zwar im physischen und im virtuellen Bereich.
Solution Accelerators wurden in Zusammenarbeit mit Branchenfachleuten entwickelt und in echten Kundenumgebungen getestet. Sie bieten genau die richtige Mischung aus ausführlicher Anleitung und Automatisierung, um hohe Leistung zu erzielen und eine produktübergreifende IT-Infrastruktur zu erstellen, ohne ein komplett neues Verfahren entwickeln zu müssen. Diese Ressourcen konzentrieren sich auf wichtige Probleme von Unternehmen jeglicher Größe, wie z. B. Infrastrukturbewertung und -planung, Virtualisierung, Kommunikation und Zusammenarbeit sowie Sicherheit und Einhaltung von Bestimmungen.

Wichtige Merkmale des Tools
Das neu veröffentlichte MAP Toolkit 3.1 (siehe Abbildung 1) ist ein netzwerkweites Infrastrukturbewertungstool, das Ihnen helfen soll, schnell ein grundlegendes Verständnis Ihrer Server und Desktops zu gewinnen, sodass Sie wissen, ob sie für Aktualisierungen oder die Migration zu Technologien wie Hyper-V, Microsoft Application Virtualization, Windows Server 2008, Windows Vista, Office 2007 und SQL Server bereit sind.
Abbildung 1 Das Microsoft Assessment and Planning Toolkit 3.1 (zum Vergrößern auf das Bild klicken)
Wie Abbildung 2 zeigt, generiert MAP automatisch Berichte zur Bereitschaftsbewertung einschließlich Vorschlägen, sodass Ihnen viel Arbeit erspart wird, die Sie sonst selbst leisten müssten. Das MAP Toolkit 3.1 unterstützt sowohl Server- als auch Desktopszenarios, einschließlich der Evaluierung der Desktopcomputer für die Aktualisierung auf Windows Vista und des Planens der Einführung von Microsoft Application Virtualization.
Abbildung 2 Beispiel eines automatisch generierten Migrationsvorschlags (zum Vergrößern auf das Bild klicken)
Bei der Servervirtualisierungsplanung können Ihnen drei Hauptfeatures des Tools helfen zu bestimmen, welche Ihrer physischen Computer gute Kandidaten sind: Serverbestandsaufnahme, Sammeln der Leistungsmetrik und Empfehlungen für die Virtualisierungsplatzierung. Im Folgenden ist ein Szenario aufgeführt, das Ihnen zeigt, wie Sie diese Features verwenden können, um ein ausführliches Bild Ihrer aktuellen Umgebung zu erstellen und den Übergang zur Virtualisierung zu planen.

Ermitteln des Vorhandenen
Viele große Unternehmen verfügen über eine Form von Serververwaltungsinfrastruktur, z. B. System Center Operations Manager. Einige Umgebungen werden weniger aktiv verwaltet. Wenn Sie in einer Umgebung arbeiten, in der Sie sich nicht sicher sind, welche Server vorhanden sind oder was auf ihnen ausgeführt wird, kann das Server Inventory-Feature schnell Klarheit schaffen. Server Inventory kann Computer in Ihrer Umgebung mithilfe von Active Directory, mittels eines IP-Adressbereichsscans oder durch einfaches Importieren einer Liste der Computer aus einer Flatfile erkennen. Wie Abbildung 3 zeigt, können Sie auch mehrere Ermittlungsmethoden gemeinsam verwenden (beispielsweise Active Directory und IP-Adressbereichsscan), um Computer zu finden, die in Active Directory vorhanden sein sollten, es aber nicht sind.
Abbildung 3 Wahl der Computerermittlungsmethode (zum Vergrößern auf das Bild klicken)
Beim Ermitteln von Computern versucht MAP Toolkit 3.1, eine Verbindung zu jedem einzelnen Computer herzustellen und mehr als 50 Klassen von Daten über die Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) abzurufen. Auf Grundlage dieser Daten können mehrere verschiedene Arten von Berichten generiert werden. Bei der Serverkonsolidierung mit Virtualisierung interessieren wir uns besonders für die Berichte, die erstellt werden, wenn Sie sich für das Migrieren spezifischer Rollen und Dienste zu Windows Server 2008 entscheiden.
Selbst wenn Sie zum jetzigen Zeitpunkt keine Migration zu Windows Server 2008 durchführen, sind die beiden Berichte, die durch dieses Szenario erstellt werden, wertvoll beim Bestimmen der Art von Hardware in Ihrer Umgebung (einschließlich Prozessortyp und Geschwindigkeit, Datenträgergrößen und installiertem Speicher) sowie der Softwarerollen, die Sie jedem Server (DNS-Server, Domänencontroller und Terminaldienste) zugewiesen haben.
Diese Berichte werden als Microsoft Excel-Arbeitsmappen bereitgestellt, sodass es einfach ist, die Sortier- und Filtertools in Excel zu verwenden, um genau zu festzustellen, welche Computer in Ihrer Umgebung gute Kandidaten für die Virtualisierung sind.
Die Serverbestandsaufnahmeberichte bieten Daten für mehrere Attribute an, die Sie beim Auswählen von Servern zum Virtualisieren in Betracht ziehen können. Sie könnten beispielsweise sicherstellen wollen, dass die Computer, die virtualisiert werden, ein Betriebssystem ausführen, das von der Hyper-V-Virtualisierungsplattform unterstützt wird. In der WS2008HardwareAssessment-Excel-Arbeitsmappe, die bei der Serverbestandsaufnahme erstellt wird, können Sie auf der Registerkarte „Server Inventory“ (Serverbestand) die Spalten „Current Operating System“ (Aktuelles Betriebssystem) und „Service Pack“ überprüfen, um Systeme zu finden, die aktualisiert werden müssen.

Bestimmen der aktuellen Verwendung
Der nächste Schritt bei der Suche nach Virtualisierungskandidaten besteht darin zu messen, wie stark die physischen Computer verwendet werden. Der Performance Metrics Wizard in MAP Toolkit 3.1 (siehe Abbildung 4) zeichnet Leistungsindikatoren aus einer Liste der Computer auf, die Sie als Virtualisierungskandidaten identifiziert haben. CPU-Auslastung, Datenträger-E/A-Nutzung und Netzwerkauslastung werden alle zur späteren Prüfung erfasst.
Abbildung 4 Der Performance Metrics Wizard (zum Vergrößern auf das Bild klicken)
Dieser Teil des Tools wurde entworfen, um Computer über einen ziemlich langen Zeitraum (bis zu einem Monat) zu beobachten, sodass Sie eine gewisse Flexibilität bei der Verwendung haben. Wenn Sie bereits eine gute Vorstellung von der höchsten Nutzung in Ihrer Umgebung haben (Sie haben beispielsweise ein wöchentliches Fenster zur Batchverarbeitung), können Sie den Assistenten so einrichten, dass er nur für einige Stunden um diesen Zeitpunkt herum ausgeführt wird. Wenn Sie sich jedoch nicht sicher sind, wann die höchste Nutzung bei Ihnen stattfindet, oder wenn Sie viele Computer beobachten möchten, die verschiedene Zeiten der Spitzenauslastung haben, können Sie den Assistenten so einrichten, dass er mehrere Tage oder Wochen lang ausgeführt wird, um Daten Ihrer Computer aufzuzeichnen. Auf diese Weise kann das Tool automatisch Spitzenauslastungen in einem größeren Datensatz identifizieren.
Mithilfe der Informationen aus Ihrer vorherigen Bestandsaufnahme greifen Sie auf die Sortier- und Filterfunktionen in Excel zu, um eine Liste der Computer zu erstellen, die Sie überwachen möchten. Der Performance Metrics Wizard akzeptiert diese Liste als Flatfile mit einem Computernamen pro Zeile. Kopieren Sie die Liste der Computernamen aus Excel in eine neue, leere Textdatei in Editor, und speichern Sie die Datei. Wenn Sie dazu aufgefordert werden, importieren Sie diese Datei in den Assistenten, und legen Sie die Endzeit des Zeitraums für das Sammeln der Leistungsdaten fest. Der Assistent geht über in den Datensammlungsmodus und sammelt alle fünf Minuten Leistungsindikatoren der angegebenen Computer.
Nach Abschluss des Performance Metrics Wizard wird ein ausführlicher Excel-Bericht erstellt, der alle beobachteten Computer und alle Leistungsdaten für verschiedene Nutzungskategorien auflistet: CPU, physischer Datenträger, logischer Datenträger und Netzwerk. Mithilfe dieser Informationen können Sie Ihre Liste von Kandidaten, die für die Virtualisierung in Betracht kommen, weiter verfeinern.
Sie können auf Computer mit äußerst niedriger Auslastung abzielen und möglicherweise mehrere von ihnen als virtuelle Computer auf einem einzelnen Host konsolidieren, oder Sie können diese Informationen mit den Bestandsdaten kombinieren, um Computer mit besonders wichtigen Diensten zu finden, für die hohe Verfügbarkeit erforderlich ist. Die Virtualisierung kann zum Bereitstellen verbesserter Notfallwiederherstellungsfunktionen für hochverfügbare Umgebungen verwendet werden. Nach Ihrer Analyse können Sie zum letzten Schritt übergehen und Empfehlungen für die virtuelle Computerplatzierung generieren.

Empfehlungen für die Serverplatzierung
Mithilfe des Server Virtualization and Consolidation Wizard können Sie die Konfiguration eines hypothetischen Virtualisierungshostcomputers hinsichtlich CPU, Netzwerk, Datenträgersubsystem und Speicher angeben. Mithilfe der vom Performance Metrics Wizard gesammelten Daten berechnet der Server Virtualization and Consolidation Wizard eine gute Zuordnung von virtuellen Gastcomputern zu virtuellen Hostcomputern und stellt sicher, dass jeder Host gut ausgelastet ist, ohne eine zu starke Nutzung während der Spitzenauslastung zu riskieren.
Nach Abschluss des Server Virtualization and Consolidation Wizard wird eine ausführliche Excel-Tabelle mit der vorgeschlagenen Zuordnung von virtuellen Gastcomputern zu physischen Hosts erstellt. Für jeden virtuellen Computer und Host zeigt der Bericht die voraussichtliche Datenträger-E/A, Netzwerk-E/A und die CPU-Auslastung an. Beim Hinzufügen virtueller Gastcomputer zu physischen Hostcomputern während des Anpassungsprozesses werden neue Hostcomputer zugeordnet, wenn vorherige Hosts ihre Kapazitätsgrenze erreichen. Für jeden neuen Host wird eine Nachricht angezeigt, die angibt, warum ein neuer Host zugeordnet werden musste.
Wenn mehrere Ihrer Hosts dieselbe Nachricht erhalten, könnten Sie den Placement Wizard erneut mit einer anderen Hostkonfiguration ausführen, um die Anzahl der Gäste zu erhöhen, die jedem Host zugewiesen werden. Wenn beispielsweise mehrere Hosts die Nachricht anzeigen, dass die Speichergrenze erreicht wurde, könnten Sie versuchen, den Assistenten erneut auszuführen und einen größeren Arbeitsspeicher für die Hostkonfiguration anzugeben. Dadurch sollte die Anzahl der Gäste erhöht werden, die jedem Host zugewiesen werden kann.

Virtuelle Computerkonfiguration
Jede Seite im Server Virtualization and Consolidation Wizard ermöglicht Ihnen das Konfigurieren einer Hauptkomponente der hypothetischen Computerkonfiguration, die zum Modellieren der Kapazität des virtuellen Hostcomputers verwendet wird. Modelle werden sowohl für Virtual Server 2005 R2 als auch für Hyper-V bereitgestellt, und Sie werden gefragt, welche Virtualisierungstechnologie Sie auf der ersten Seite des Assistenten verwenden möchten (siehe Abbildung 5).
Abbildung 5 Auswahl der Virtualisierungstechnologie für Platzierungsempfehlungen (zum Vergrößern auf das Bild klicken)
Modelle für mehrere Familien von CPUs sowohl von AMD als auch Intel werden auf der CPU-Konfigurationsseite bereitgestellt. Wenn für Ihre CPU kein Modell verfügbar ist, wählen Sie das Modell, das ihm am nächsten kommt. Sie können auf dieser Seite die Zahl physischer Prozessoren, Kerne und Hyperthreads pro Kern konfigurieren. Sie sollten beachten, dass bei der Wahl von Hyper-V als Virtualisierungsplattform nur 64-Bit-CPUs zur Auswahl stehen (siehe Abbildung 6).
Abbildung 6 Host-CPU-Konfiguration (zum Vergrößern auf das Bild klicken)
Auf der dritten Seite des Assistenten können Sie ein Datenträgersubsystem im Hinblick auf die Anzahl der Laufwerke und die RAID-Technologie konfigurieren, um den auf dem Host verfügbaren Gesamtspeicherplatz und einen Wert für den Durchsatz des Datenträgersubsystems zu berechnen. Der Durchsatzwert wird automatisch basierend auf der Schnittstellentechnologie und der ausgewählten RPM-Geschwindigkeit (Reliability and Performance Monitor, Zuverlässigkeits- und Leistungsüberwachung) des Datenträgers bereitgestellt.
Im MAP Toolkit 3.1 wird keine direkte Unterstützung für das Modellieren von SAN- (Storage Area Network) und NAS (Network Attached Storage)-Datenträgerlösungen bereitgestellt. Wählen Sie für eine ungefähre Annäherung die SCSI-Datenträgertechnologie, und konfigurieren Sie eine RAID-Stufe, die Ihrer SAN-Konfiguration ähnelt, mit Datenträgern ähnlicher Geschwindigkeit. Diese Annäherung sollte für Ihre anfängliche Planung ausreichen.

Einschränkungen für die Platzierung
Beim Zuordnen virtualisierter Gastcomputer zu physischen Hosts werden sechs Faktoren in Betracht gezogen, um zu bewerten, ob ein Gastcomputer zur verbleibenden Kapazität eines Hostcomputers passt:
  • CPU-Auslastung
  • Netzwerk-E/A-Auslastung
  • Datenträgersubsystem-E/A-Auslastung
  • Speicher
  • Festplattenspeicher
  • Unterstützung für das Gastbetriebssystem bei der angegebenen Virtualisierungstechnologie
Die Auslastung von CPU, Netzwerk und Datenträgersubsystem ist ziemlich transparent. Gemessene Auslastungen beim physischen Gastcomputer, der als Virtualisierungskandidat in Frage kommt, werden in eine entsprechende Auslastung auf dem Virtualisierungshostcomputer konvertiert, die dann der vorhandenen Auslastung des Hosts hinzugefügt wird. Wenn die resultierende Gesamtauslastung aller Gäste, die diesem Host für diese Ressource zugewiesen wurden, weniger als die Schwellenwertbeschränkung beträgt, wird der Gast dem Host zugewiesen. Ist dies nicht der Fall, wird der Gast nicht platziert, und es werden Versuche mit anderen Gästen angestellt, um festzustellen, ob ein passender vorhanden ist.
Ein Beispiel: Angenommen, Sie haben Leistungsdaten über einen Computer mit einer Pentium 4-CPU mit 1,2 GHz gesammelt, für den eine CPU-Auslastung von 32 Prozent angezeigt wurde. Wenn Sie einen Virtualisierungshost mit einer Vierkern-CPU der Intel Xeon 5300-Serie konfigurieren, wird die ursprüngliche gemessene CPU-Auslastung des potenziellen Gastcomputers auf eine gleichwertige, voraussichtliche Auslastung auf dem Hostcomputer extrapoliert. Diese neue Auslastung wird aufgrund der neuen CPU-Architektur, eines anderen CPU-Takts und der Hinzufügung von mehr Kernen geringer sein als der ursprüngliche gemessene Wert.
Wenn Sie umgekehrt einen Hostcomputer mit einer weniger leistungsfähigen CPU als der CPU des Gasts konfiguriert haben, wird die voraussichtliche Auslastung höher sein, wenn sie für den Host extrapoliert wird. In beiden Fällen wird die neue extrapolierte CPU-Auslastung beim Berechnen der Gesamtauslastung des Hostcomputers verwendet, wenn ihm Gäste zugewiesen werden.
Es lohnt sich, kurz zu erörtern, wie die Auslastung von Speicher und Speicherplatz ermittelt wird. Die Gesamtgröße des physischen Speichers, der auf jedem potenziellen Virtualisierungsgast installiert ist, wird auf dem Hostcomputer reserviert. Zusätzlich wird ein wenig Speicherplatz (512 MB) für den Host selbst reserviert. Wenn der Gesamtspeicher auf dem Host aufgrund der Zuweisung von Gästen plus Hostbelastung ausgeschöpft ist, dürfen auf diesem Hostcomputer keine Virtualisierungsgäste mehr platziert werden.
Speicherplatz wird ähnlich behandelt: Die Gesamtgröße des physischen Speichers auf jedem potenziellen Virtualisierungsgast wird auf dem Hostcomputer reserviert. Zusätzlich werden 50 GB des Speicherplatzes für die Verwendung durch den Virtualisierungshost reserviert. Wenn die gesamte Datenträgernutzung aller Gäste, die dem Host zugewiesen wurden, plus dem für den Host selbst reservierten Platz die in der Hostkonfiguration angegebene Größe erreicht, können keine Gäste mehr zugewiesen werden.
Auf Grundlage der ausgewählten Virtualisierungsplattform werden Überprüfungen durchgeführt, um sicherzustellen, dass das auf dem Gastcomputer ausgeführte Betriebssystem tatsächlich von der Virtualisierungsplattform unterstützt wird. So werden beispielsweise 64-Bit-Betriebssysteme von Virtual Server 2005 R2 nicht als Gäste unterstützt, d. h., sie werden nicht platziert, wenn Sie diese Virtualisierungstechnologie auswählen.

Ihre Optionen
Durch mehrmaliges Ausführen des Server Virtualization and Consolidation Wizard ist es einfach, die Ergebnisse verschiedener Auswahlmöglichkeiten für Hardware für den Virtualisierungshostcomputer zu vergleichen. Jedes Mal, wenn der Assistent ausgeführt wird, können Sie verschiedene CPU-, Datenträger- und Speicheroptionen auswählen, um die Lösung zu finden, die am besten zu Ihrer Umgebung passt.
Achten Sie auf die Spalte „Last Placement Failed Reason“ (Grund für die letzte fehlgeschlagene Platzierung) auf der Registerkarte „Consolidation Recommendations“ (Konsolidierungsempfehlungen) in der Excel-Arbeitsmappe für die Serverkonsolidierung. Diese Gründe geben Ihnen Anhaltspunkte dafür, warum nicht mehr Gastcomputer auf einen bestimmten Host platziert werden konnten. Wenn für mehrere Hosts derselbe Grund angezeigt wird (beispielsweise „Memory utilization of guest exceeds available memory on host“ – Speicherauslastung des Gasts liegt über dem verfügbaren Speicher des Hosts), könnte das Erhöhen der Speichermenge in der Hostkonfiguration die Gesamtzahl der erforderlichen Hosts verringern.

Anforderungen
Einer der Vorteile von MAP Toolkit 3.1 besteht darin, dass auf den inventarisierten Computern keinerlei Software erforderlich ist. Alle Vorgänge werden von einem Remotestandort aus durchgeführt. Es müssen jedoch einige Faktoren in Betracht gezogen werden, damit alles richtig funktioniert.
Damit der Inventory Wizard und der Performance Metrics Wizard ihre Arbeit abschließen können, müssen einige TCP-Ports auf dem Zielcomputer offen und für den Computer zugänglich sein, auf dem das MAP Toolkit installiert ist. Im Handbuch für die ersten Schritte werden die Anforderungen ausführlich beschrieben. Kurz gesagt, müssen die Ports für Authentifizierung, DCOM und WMI auf den inventarisierten Computern offen sein. Wenn auf dem Netzwerk zwischen den Computern, auf denen das MAP Toolkit 3.1 ausgeführt wird, und den Zielen für die Bestandsaufnahme Firewalls installiert sind, müssen diese Firewalls so konfiguriert werden, dass dieser Datenverkehr ebenfalls zugelassen ist.
Das MAP Toolkit 3.1 ist für die Bestandsaufnahme in Umgebungen mit bis zu 100.000 Computern und zum Sammeln von Leistungsdaten von bis zu 3.000 Computern auf einmal ausgelegt. Standardmäßig installiert dieses Tool eine private Instanz von SQL Server 2005 Express Edition. Aufgrund der Größenbeschränkung der Datenbank von 4 GB in SQL Server Express ermöglicht diese Konfiguration nur die Bestandsaufnahme von etwa 20.000 Computern, bevor die von SQL Server Express durchgesetzte Dateigrößenbegrenzung erreicht wird. Um während der Bestandsaufnahme mit mehr Computern arbeiten zu können, müssen einige Standardeinstellungen geändert werden.
Zum Arbeiten in größeren Umgebungen muss eine Vollversion von SQL Server, z. B. SQL Server 2005 Standard Edition, verwendet werden. Installieren Sie vor der Installation des MAP Toolkit eine neue Instanz von SQL Server 2005, und nennen Sie die Instanz „MAPS“. Führen Sie dann das MAP Toolkit-Installationsprogramm wie gewohnt auf demselben Computer aus. Für das MAP Toolkit ist eine lokale Instanz von SQL Server erforderlich, und das Installationsprogramm erkennt automatisch eine lokale „MAPS“-Instanz des Datenbankservers und wird dort installiert, statt dass SQL Server Express Edition installiert wird.
Für noch größere Umgebungen können Sie das Skalierungsfeature verwenden, das es mehreren Hilfscomputern, auf denen das MAP Toolkit installiert ist, ermöglicht, eine große Bestandsaufnahme gemeinsam auszuführen und alle gesammelten Daten in einer zentralen Datenbank zu speichern. Für diese Konfiguration ist ebenfalls die Verwendung von SQL Server Standard Edition erforderlich, um die Dateigrößenbegrenzung von 4 GB zu vermeiden.
Im Handbuch für die ersten Schritte finden Sie Einzelheiten zum Installieren dieses Tools in dieser Konfiguration und zum entsprechenden Bearbeiten der Datenbankverbindungszeichenfolgen für diesen Modus. Das Skalierungsfeature kann auch verwendet werden, um SQL Server auf einem anderen Computer zu installieren als dem, auf dem das MAP Toolkit installiert ist.

Zusammenfassung
Solution Accelerators wie das Microsoft Assessment and Planning Toolkit dienen der Durchführung der schweren Arbeiten für Ihre IT-Projekte, sodass Sie diese Aufgaben nicht selbst durchführen müssen. Das MAP Toolkit hat vielen Benutzern Hunderte von Stunden IT-Planungszeit für Hyper-V-Bereitstellungen gespart. Sind Sie bereit, es auszuprobieren?
Sie können das Microsoft Assessment and Planning Toolkit kostenlos unter microsoft.com/map herunterladen. Andere Virtualization Solution Accelerators sind unter microsoft.com/vsa erhältlich. Besuchen Sie den MAP Toolkit-Teamblog unter blogs.technet.com/mapblog, um mehr Tipps zu erhalten und sich Demovideos anzusehen.

Jay Sauls ist Senior Program Manager in der Solution Accelerators-Gruppe bei Microsoft, wo er an der Entwicklung und Implementierung von Tools wie beispielsweise der Windows Vista-Hardwarebewertung und dem Microsoft Assessment and Planning Toolkit gearbeitet hat. Vorher war Jay Sauls in anderen Microsoft-Produktteams einschließlich Microsoft Commerce Server, Microsoft BizTalk und System Center Capacity Planner tätig.

Baldwin Ng ist Senior Product Manager für das Microsoft Solution Accelerator Core Engineering Team. Zu seinen derzeitigen Projekten zählen das Microsoft Assessment and Planning Toolkit und Virtualization Solution Accelerators. Baldwin Ng verfügt über mehr als 16 Jahre Erfahrung in der Produktverwaltung und -entwicklung in den Bereichen IT, E-Commerce und drahtlose Internetdienste bei Microsoft, Corbis und Alltel. Er veröffentlicht häufig Blogs unter blogs.technet.com/MAPBLOG.


Mitteilung der Redaktion Schöne neue Welt der Virtualisierung
Joshua Hoffman

Virtualisierung ist keine neue Technologie. Das ist möglicherweise nicht die enthusiastischste Art, meine Mitteilung an Sie in diesem Monat zu beginnen, aber es ist wahr. Das Konzept der Virtualisierung – die Trennung eines Betriebssystems von den zugrunde liegenden Hardwareressourcen – gibt es schon seit 1967, dem Jahr der Einführung des Betriebssystems IBM CP/CMS. Obwohl das Konzept gut etabliert sein mag, hat sich in den letzten 40 Jahren viel verändert.
2008 erreichen wir einen Wendepunkt bei der Computervirtualisierung. Da die Notwendigkeit zur Kostensenkung, Vereinfachung der Verwaltung und Einführung nachhaltiger Computerpraktiken mit der Entwicklung leistungsfähigerer Mehrkernprozessoren und neuer Hypervisortechnologie einhergegangen ist, ist es nun an der Zeit, dass die Virtualisierung in den Mittelpunkt rückt. Um dieses Thema dreht sich alles in dieser Ausgabe des TechNet Magazins. Es enthält Artikel zu der interessanten neuen Hyper-V-Plattform in Windows Server 2008, zu Tools für die Verwaltung einer virtuellen Umgebung, zu Verfahren für die Bereitstellung virtueller Anwendungen und mehr.
In eigener Sache möchte ich im Namen des gesamten TechNet Magazin-Teams den beitragenden Redakteuren Greg Stemp und Jean Ross, den berüchtigten Scripting Guys von Microsoft, meinen besonderen Dank ausdrücken. Ich weiß, dass es Sie möglicherweise schockiert, dass die Scripting Guys von Microsoft in Wirklichkeit keine kleinen Männchen in weißen Kitteln mit ungewöhnlich großen Köpfen sind, die auf den Fluren von Microsoft mit einem Reagenzglas in der einen und einem Skript in der anderen Hand umherlaufen. Stattdessen haben Greg und Jean in den letzten drei Jahren die Artikel für die Rubrik „Hey, Scripting Guy!“ des TechNet Magazins verfasst und es dadurch zu weltweiter Anerkennung gebracht. „Hey, Scripting Guy!“ ist nicht nur zur beliebtesten Rubrik unserer Publikation geworden, sondern hat auch mehrere Auszeichnungen erhalten und zieht mehr Lob und E-Mails von Lesern nach sich, als wir zählen können.
Aus all diesen Gründen und vielen mehr (von denen die Tatsache, dass wir sie besonders mögen, nicht der Geringste ist) macht es uns hier beim TechNet Magazin traurig, dass wir uns in diesem Monat von Greg und Jean verabschieden müssen. Doch wie es den Besten von uns zwangsläufig geht, möchten sich Greg und Jean neuen Herausforderungen stellen. Glücklicherweise werden sie weiter durch die Flure von Redmond spazieren und ihr Talent zum Vorteil der Microsoft-Kunden einsetzen. Daher wünschen wir den beiden das Allerbeste und können nur hoffen, dass ihre Worte unsere Seiten eines Tages erneut schmücken werden.
In der Zwischenzeit hat sich Dean Tsaltas, ein verdienter ehemaliger Scripting Guys-Mitarbeiter, freundlicherweise bereit erklärt, vorläufig die Rubrik „Hey, Scripting Guy!“ zu übernehmen, während wir nach der nächsten Generation von Scripting Guys suchen. Dean wird im nächsten Monat zu uns stoßen, um die Details der Windows-Verwaltungsinstrumentation zu erläutern. Lassen Sie sich das nicht entgehen! – Joshua Hoffman

Unser Dank gilt folgenden technischen Experten von Microsoft: Karri Alexion-Tiernan, Carmen Asher, Scott Culp, Steve Ekren, Trina Gorman, Michael Michael, Mike Mitchell, Michael Murgolo, Rob Polly, Dan Reger, Jez Sadler, Bill Scheidel, Bryon Surace und Jim Truher.


Briefe Leser sagen ihre Meinung

SQL-Datenbankverwaltung
Vielen Dank für den Artikel „SQL Server: Die besten Tipps für effektive Datenbankwartung“ in der Ausgabe vom August 2008 (verfügbar unter technet.microsoft.com/magazine/cc671165). Endlich ein Artikel zum Thema SQL, der sich an uns „unfreiwillige DBAs“ richtete, die einfach nur sicherstellen müssen, dass eine Anwendung namens „SQL Server“ ausgeführt und gesichert wird.
Gleich auf der nächsten Seite folgte dann „Windows-Verwaltung: Fühlen Sie den Puls Ihres Servers“ (technet.microsoft.com/magazine/cc718984). Das war großartig. Ich habe diese Artikel aus dem Magazin ausgeschnitten, um sie aufzubewahren – was bei digitalen E-Magazinen nicht möglich ist. Ich werde diese beiden Artikel noch oft zurate ziehen. Nur weiter so!
Es freut uns zu hören, dass Ihnen diese beiden Artikel gefallen haben. Wir hören immer gern, dass unsere Informationen nützlich sind. Obwohl wir überschwängliches Lob nie ablehnen werden, lassen Sie es damit nicht auf sich beruhen! Sie können uns jederzeit Vorschläge für beliebige andere Themen zusenden, die Ihrer Ansicht nach in zukünftigen Ausgaben behandelt werden sollten. Wir warten immer auf Anregungen seitens unserer Leser.
– Joshua Hoffman, Chefredakteur

ImageX und Windows PE
Vielen Dank für den Artikel zur Bereitstellung älterer Betriebssysteme mit ImageX und Windows PE („Duales Starten mit Windows XP und Windows PE 2.0“, Februar 2008, technet.microsoft.com/magazine/cc194422). Ich habe das Potenzial dieser Tools im letzten Jahr erkannt und begonnen, mit ihnen zu experimentieren, um das Abbilderstellungstool zu ersetzen, das bisher in meinem Unternehmen verwendet wurde (Acronis Snap Deploy). Vor etwa sechs Monaten habe ich erreicht, dass alles wie gewünscht funktioniert, und es ist jetzt tatsächlich das einzige Abbilderstellungstool, das wir verwenden.
Dann habe ich Ihren Artikel gelesen und Ihre Empfehlung bezüglich des Hinzufügens der Option „bootsect.exe /n52“ bemerkt. Ich hatte noch nie von dieser Option gehört. Vor dem Anwenden der Abbilder bereinigen wir lediglich die Festplatte mithilfe von DiskPart mit dem enthaltenen Skript (commands.txt). Bisher sind noch keine Probleme aufgetreten, aber könnte dies in Zukunft ein Problem darstellen?
Früher war dieser Befehl notwendig. Nach der Veröffentlichung dieses Artikels wurde ich jedoch von einem Teammitglied darüber informiert, dass er nicht mehr erforderlich ist, weil der Startcode _jetzt_ Logik für die Suche nach dem neuen Startmanagercode enthält. Wenn dieser nicht gefunden wird, wird nach NTLDR gesucht, bevor ein Fehler auftritt. Daher kann er vollständig weggelassen werden, ohne dass Probleme auftreten.
– Wes Miller, Kolumnist, Die Desktopdateien

Testabbildumgebung
Ich habe Ihre Rubrik „Die Desktopdateien“ zur Implementierung von Abbildern mit dem Tool „ImageX“ und zum Ermöglichen von Multicastübertragungen über die Windows-Bereitstellungsdienste gelesen („Duales Starten mit Windows XP und Windows PE 2.0“). Ich möchte eine Testumgebung bereitstellen und würde gern genau wissen, welche Tools erforderlich sind. Muss ich Windows Server 2008 für eine Multicastimplementierung installieren? Ist zudem für Spiegelbilder die Verwendung von ImageX für die Installation von Deployment 4 oder Windows Automated Installation Kit (WAIK) und WDS erforderlich?
Um Multicast über die Windows-Bereitstellungsdienste verwenden zu können, müssen Sie Windows Server 2008 installiert haben. Die Multicastkomponenten sind für Windows Server 2003 nicht verfügbar (und werden auch nicht verfügbar sein).
Deployment 4 ist für die Verwendung von Multicast nicht erforderlich. Um Multicast verwenden zu können, benötigen Sie Windows Server 2008 sowie die veröffentlichte Version des WAIK für Windows Server 2008. Diese Version des WAIK ist die erste Version, die die erforderlichen Elemente für die Multicastübertragung nach Windows PE enthält.
– Wes Miller

WDS-Multicast
Ich habe versucht, ImageX zum Klonen von Abbildern auf Computer und von Computern zu verwenden. Bald stand ich vor einem Problem: ImageX unterstützt keine Multicastübertragungen. Ich möchte den gleichen Vorgang mithilfe von WDS-Servern und Multicastübertragungen durchführen. Ist das möglich? Anscheinend lässt sich dies mit dem Wdsmcast-Befehl erreichen. Wie kann ein WDS-Client einen WDS-Server darüber informieren, welches Abbild heruntergeladen werden soll?
Tatsächlich ist ImageX nicht für Multicast ausgelegt. Sie müssen mithilfe von Wdsmcast (im WAIK von Windows Server 2008) angeben, zu welcher Übertragung eine Verbindung hergestellt werden soll (nachdem Sie sie auf dem Server gestartet haben). Das Whitepaper „Verwenden des Transportservers“ bietet grundlegende Informationen dazu, wie mithilfe von Wdsmcast eine Verbindung hergestellt werden kann (technet.microsoft.com/library/cc725964). Lesen Sie den Abschnitt „Verbinden eines Clientservers mit einem Namespace mittels Wdsmcast.exe“.
– Wes Miller

Kontakt Sie möchten uns etwas mitteilen? Senden Sie Ihre E-Mails in englischer Sprache an tnmag@microsoft.com, oder besuchen Sie unser Blogforum unter blogs.technet.com/tnmag.


Toolbox Neue Produkte für IT-Experten
Greg Steen

Alle Preise wurden am 19. August 2008 bestätigt, Änderungen vorbehalten. Die in diesem Artikel ausgedrückten Meinungen sind ausschließlich die des Autors und spiegeln nicht zwangsläufig die Meinungen von Microsoft wider.

Mobile Anwendungen
PortableApps.com
PortableApps.com
Als IT-Experte bewegen Sie sich wahrscheinlich viel von einem Computer zum nächsten. Bei diesen Gelegenheiten wünschen Sie sich wahrscheinlich, Ihren standardmäßigen Satz an Anwendungen, Tools und Dokumenten immer zur Hand haben. Eine Startprogrammplattform, wie sie von PortableApps.com bereitgestellt wird, bietet eine tolle Möglichkeit, diese Bedürfnisse zu erfüllen. Auf deren Website finden Sie sowohl die kostenlose PortableApps.com-Open-Source-Plattform als auch eine Reihe portabler Anwendungen, die ausschließlich von einem USB-Flashlaufwerk, einer Speicherkarte, einer tragbaren Festplatte oder einem digitalen Musikplayer aus ausgeführt werden können.
Es gibt auch eine PortableApps.com-Suite. Dieser nützliche Download enthält ein Paket der verfügbaren portablen Anwendungen zusammen mit der Basisplattform – alles in einem Installationsprogramm. Es gibt zwei Versionen der Suite. Suite Light enthält Mozilla Firefox, Thunderbird und Sunbird zusammen mit ClamWin Antivirus, Pidgin für Instant Messaging, den PDF Reader „Sumatra“, den Kennwortmanager „KeePass“, das Textverarbeitungsprogramm „AbiWord“, einen Audioplayer und ein paar einfache Spiele. Suite Standard enthält ebenfalls alle diese Anwendungen und außerdem die Office-Suite „OpenOffice.org“ mit Writer, Calc, Impress, Base und Draw.
Zusätzlich gibt es eine Reihe weiterer Open-Source-Anwendungen auf der Website, die „portabel“ gemacht wurden. Diese umfassen FileZilla für FTP, PuTTY für Telnet und SSH, WinSCP für SFTP und SCP, PNotes und Task Coach für schnelle Listen, 7-Zip zum Archivieren, eine Eingabeaufforderung, Eraser zum Löschen von Dateien, InfraRecorder zum Brennen von CDs/DVDs, WinDirStat zum Visualisieren der Inhalte eines Datenträgers, winMd5Sum zum Überprüfen von Dateien und WinMerge zum Feststellen von Unterschieden zwischen Dateien bzw. Verzeichnissen. (Wenn Sie meine Toolbox-Artikel häufiger lesen, haben Sie u. U. bemerkt, dass ich einige dieser Anwendungen in früheren Ausgaben erörtert habe.)
Es gibt auch eine sehr aktive Benutzercommunity, die an portablen Versionen solcher Netzwerkdienstprogramme wie WinPCap und Wireshark arbeitet. (Diese beiden Tools können Ihnen bei Ihren administrativen Aufgaben und Problembehandlungsaufgaben wirklich helfen.) Die Foren bieten sogar einen Ort speziell zum Vorschlagen von Anwendungen, die portabel gemacht werden sollten.
Diese Anwendungen sind auf dem verwendeten Speichergerät in sich geschlossen. Wenn sie in die Registrierung schreiben oder Zugriff „außerhalb“ des Datenträgers erfordern, sollten sie beim Beenden alles wieder in den Zustand vor ihrer Ausführung zurückversetzen. Sie können die Anwendungen auch ohne die PortableApps.com-Plattform ausführen, denn sie sind in ihr eigenes Installationsprogramm gepackt erhältlich, um genau dies zu ermöglichen. Davon abgesehen werden Sie die Features der Plattform sowieso nutzen wollen. Die Suite ist ein großartiger Ort, um eine angepasste Umgebung zu starten, die Sie mitnehmen können.
Die PortableApps.com-Plattform ist für den automatischen Start eingerichtet. Wenn Sie also Ihr USB-Flashlaufwerk oder tragbares Laufwerk an den Windows-Hostcomputer anschließen, erhalten Sie die Option, die Plattformanwendung auszuführen. Sobald Sie die Plattform gestartet haben, wird ein Taskleistensymbol angezeigt. Wenn Sie auf dieses Symbol klicken, wird ein Menü ähnlich dem Windows-Startmenü angezeigt. Dieses Anwendungsstartprogramm bietet Quicklinks zu allen Ihren portablen Anwendungen, zusammen mit Links zu den Dokumentordnern auf Ihrem portablen Laufwerk, einem Indikator, der den freien Speicherplatz auf Ihrem Laufwerk anzeigt, einem Sicherungsprogramm für die Dokumente auf dem Laufwerk, einem Suchprogramm und einem Link zum Installieren neuer portabler Anwendungen. Sie können diese Oberfläche anpassen und eine von mehr als 30 Oberflächensprachen auswählen.
Nachdem Sie eine Weile mit der Plattform herumexperimentiert haben, fragen Sie sich u. U., wie Sie eine Anwendung portabel machen können. Die Website hat auch ein aktives „Portable App Development“-Forum, um Ihnen weiterzuhelfen. Alles in allem ist dies ein toller Satz an Tools in einem portablen Paket.

Preis: Kostenlos.
Mobile Tools mit PortableApps

Fehlerbehebung in Remotesystemen
TeamViewer
teamviewer.com
Wenn Sie Anwendungsprobleme beheben, Produktdemos und Lernprogramme vorführen oder lediglich versuchen, die Frage eines Benutzers zu verstehen, gibt es nichts Besseres, als sich an den fraglichen Computer zu setzen. Aber häufig ist dies einfach nicht möglich. Die nächstbeste Lösung besteht in der Verwendung eines Tools, mit dem Sie an Ort und Stelle sind, ohne wirklich dort zu sein. TeamViewer von der TeamViewer GmbH macht genau dies möglich.
Dieses Dienstprogramm verfügt über einen einfachen Installationsvorgang, mit dessen Hilfe Sie schnell eine Verbindung zu einem Remotecomputer herstellen können. Es gibt vier grundlegende Betriebsmodi, die von TeamViewer unterstützt werden. Da wäre die Remoteunterstützung (Remote Support), mit der Sie den Remotecomputer steuern können, um Probleme zu beheben, um beim Betrieb und bei der Wartung zu helfen und um den Benutzer bei einer Aktivität anzuleiten. Dann gibt es die Präsentation (Presentation), mit der Sie Ihren Desktop auf dem System des Remotebenutzers anzeigen können, damit Sie eine Aktivität vorführen oder eine Präsentation geben können. Ein weiterer Modus ist die Dateiübertragung (File Transfer), mit der Sie Dateien zwischen den beiden Computern übertragen können, ohne die Desktops wirklich gemeinsam zu nutzen. Und schließlich gibt es VPN. Mit diesem Modus können Sie sofort ein virtuelles privates Netzwerk zwischen Ihrem Computer und dem Hostcomputer erstellen. Dabei wird die Installationsoption „TeamViewer VPN Adapter“ verwendet.
Hinsichtlich der Sicherheit werden in der Anwendung ein RSA-Schlüsselaustausch und eine 256-Bit-AES-Sitzungscodierung verwendet. Durch den Schlüsselaustausch können Sie sicher sein, dass kein „Man-in-the-Middle“ (einschließlich des TeamView-Routingservers) den Datenstrom abhört. Wenn Sie außerdem eine Verbindung zu einer Supporter-Sitzung herstellen („Supporter“ ist der Begriff für denjenigen, der die Sitzung hostet), werden eine Sitzungskennung und ein Kennwort generiert, die der Remotebenutzer eingeben muss, um die Verbindung herzustellen. Falls Sie eine Verbindung zu einem Computer herstellen möchten, ohne dass jemand am anderen Ende sitzt (etwa um Ihre Server zu verwalten), bietet TeamViewer die Option, als Systemdienst installiert zu werden. Dadurch können Sie immer noch problemlos Dateien übertragen, Remotesteuerungsfunktionen verwenden, ein VPN erstellen oder sogar den Remotecomputer neu starten.
Ein weiteres tolles Feature ist das TeamViewer QuickSupport-Modul (oder Kundenmodul), besonders wenn Sie die Anwendung zum Support oder für Präsentationen verwenden möchten. Das ist eine relativ kleine ausführbare Datei, die für ihre Ausführung keine Softwareinstallation oder Installationsrechte auf dem Remotecomputer erfordert. Der Endbenutzer muss nur auf die exe-Datei doppelklicken und die Sitzungskennung sowie das Kennwort eingeben. Dann Sie können sogleich Ihre Sitzung mit dem Computer verbinden.
TeamViewer hat einige sehr nützliche Konfigurationsoptionen. Sie können die Anzahl der Farben optimieren, die in der Anzeige verwendet werden, das Remotehintergrundbild aus der Anzeige entfernen oder das Windows Vista Aero-Glas aktiviert lassen. Des Weiteren können Sie die allgemeinen Qualitäts- und Geschwindigkeitseinstellungen für Ihre Sitzungen anpassen. Außerdem können Sie steuern, ob Sie verschiedene Features zulassen möchten, einschließlich Remotesteuerung, Dateiübertragung, VPN-Verbindungen, Tastatur- und Mauseingaben von einem Remotestandort, Wechsel zwischen dem lokalen Host und den Remotehosts und Anzeigen des Remotebildschirms.
Sie können Sitzungen zur späteren Wiederholung oder für Überwachungszwecke aufzeichnen. Wenn Sie nicht durch die Server von TeamViewer weitergeleitet werden möchten, vielleicht aufgrund Ihrer Sicherheitskonfiguration, können Sie TeamViewer so einstellen, dass für die Weiterleitung nur LAN-Verbindungen verwendet werden.
Die Premium Edition, die unbegrenzte Supporter-Installationen unterstützt, enthält auch eine Portable Edition. Diese können Sie auf einem CD- oder USB-Flashlaufwerk speichern, um das Tool mitzunehmen. Die Premium Edition enthält auch den TeamViewer Manager, mit dem Sitzungsdetails protokolliert werden und mit dem Sie Partnerdetails speichern können. Dies sind beides nützliche Features, um Ihre Kunden zu erfassen, ihnen Bericht zu erstatten und ihnen die Rechnungen zu schicken. TeamViewer ist auch für Mac OS X erhältlich und unterstützt plattformübergreifenden Zugriff. Dadurch können Sie auf Ihrem Windows-Computer bleiben, während Sie eine Verbindung zu einem Mac herstellen.

Preis: Für Privatanwender kostenlos. Ab 699 $ für die Business Edition für eine Supporter-Installation. Die Premium Edition kostet 1.399 $ und ermöglicht unbegrenzte Supporter-Installationen.
Herstellen einer Verbindung zu einem Remotesystem mit TeamViewer

Buchbesprechung
End-to-End Network Security: Defense-in-Depth
Netzwerksicherheit umfasst heutzutage mehrere Schichten proaktiver Technologien, um die Angriffsfläche zu verringern und das Potenzial für Sicherheitsverletzungen von innerhalb und außerhalb der Netzwerkinfrastruktur zu begrenzen. End-to-End Network Security: Defense-in-Depth (Cisco Press, 2007) von Omar Santos kann Ihnen helfen, sich in der stetig zunehmenden Komplexität bei der Verteidigung Ihres Netzwerks zurechtzufinden.
Obwohl dieses Buch aus offensichtlichen Gründen auf Cisco-Technologie ausgerichtet ist, bietet es dennoch viele allgemeingültige Sicherheitsinformationen. Dadurch wird es zu einem guten Nachschlagewerk für jeden Netzwerkexperten oder Systemadministrator, dem die Sicherheit der Infrastruktur am Herzen liegt.
Das Buch beginnt mit einem Überblick über Netzwerksicherheitstechnologien, von Firewalls und VPNs bis hin zu Systemen für die Angriffserkennung und -verhinderung sowie die Identitätsverwaltung. Anschließend wird in sechs Schritten eine Methode zur Behandlung von Sicherheitsverletzungen geschildert: Vorbereitung, Identifikation (von Sicherheitsbedrohungen), Klassifizierung (von Sicherheitsbedrohungen), Rekonstruktion, Reaktion und abschließende Analyse.
Danach wird in dem Buch ein proaktives Sicherheitsframework diskutiert, in dem verschiedene Geräte und Tools einschließlich IDS/IP, NAC, AAA, SNMPS, Syslog und VLANs verwendet werden. Dann geht es um den Tiefenverteidigungsansatz von Cisco. Dabei werden drahtlose Netzwerke, IP-Telefonie, Datencentersicherheit und IPv6-Sicherheit erörtert, insbesondere wo Lösungen von Cisco für diese Bereiche der Netzwerksicherheit betroffen sind. Das Buch wird mit drei Fallstudien beschlossen, in denen praktische Sicherheitslösungen für kleine, mittlere und große Unternehmen diskutiert werden.

Preis: 49,50 US-Dollar (direkt).

Untersuchen von Geräte-IDs
PCIDatabase.com
PCIDatabase.com
Haben Sie jemals versucht, ein System zu aktualisieren, und hatten am Ende ein oder zwei unbekannte Geräte, deren Beschreibungen Ihnen außer „PCI-Gerät“ nichts mitteilten? Sie hatten keine Ahnung, wo Sie einen Treiber herbekommen oder wie Sie herausfinden sollten, worum es sich bei dem Gerät handelt, ohne die Abdeckung Ihres Computers abzureißen und mit einer Taschenlampe herumzusuchen? Vielleicht haben Sie auch herauszufinden versucht, welches der zugrunde liegende Chipsatz auf einem bekannten Gerät ist. PCIDatabase.com ist ein kostenloser Dienst, der dabei helfen kann.
Diese benutzerunterstützte Datenbank kann anhand von Anbietern, Gerätenamen und IDs nach mehr Informationen durchsucht werden. Öffnen Sie einfach den Geräte-Manager, klicken Sie mit der rechten Maustaste auf das fragliche Gerät und dann auf „Eigenschaften“. Wählen Sie dann die Eigenschaft „Hardwarekennungen“ aus. Daraufhin wird ein Satz von Zeichenfolgen mit einigen Hexadezimalwerten angezeigt, denen „VEN_“ (für vendor/Anbieter) bzw. „DEV_“ (für device/Gerät) vorangestellt ist.
Auf der Website werden Links zu einigen nützlichen Ressourcen geboten. Mit deren Hilfe können Sie herausfinden, ob für das nachgeschlagene Gerät Treiber erhältlich sind. Denken Sie auch daran, auf der Website des Herstellers nachzusehen.
Ein weiteres tolles Feature von PCIDatabase.com: Wenn Sie einen bestimmten Anbieter nachschlagen, wird eine Seite mit der Adresse des Hauptgeschäftssitzes, den Telefonnummern, geeigneten Websites, Kontakten, den Hexadezimalkennungen des Anbieters für PCI-Geräte und eine Liste aller Geräte des Anbieters angezeigt, die auf der Website genannt sind. Da die Website von Benutzern unterstützt wird, werden Sie dazu angeregt, Ihre Kenntnisse hinzuzufügen.

Preis: Kostenlos.
Abrufen von Anbieter- und Geräteinformationen bei PCIDatabase.com (zum Vergrößern auf das Bild klicken)

Überwachungs- und Bestandsressourcen
CCS Network Inventory
crowcanyon.com
Herausfinden zu können, was auf einem Ihrer Clientcomputer installiert ist, ohne Ihren Schreibtisch verlassen zu müssen, kann eine echte Zeiteinsparung bedeuten. Seien wir ehrlich, das Nachverfolgen dieser Ressourcen ist Teil Ihrer Arbeit. Crow Canyon Systems kann Ihnen mit seiner CCS Network Inventory-Lösung bei der Erledigung dieser Aufgaben helfen.
Die Anwendung ist ein Bestands- und Überwachungstool ohne Agent, das Ihr LAN nach Arbeitsstationen durchsucht und dabei Informationen zu Hardware, Software, Diensten und Benutzern sammelt. Da CCS Network Inventory keinen Remoteagent verwendet, wird in Ihrem Ausführungskontext RPC, Computersuchdienst, Remoteregistrierungsdienst, Datei- und Druckerfreigabe und Zugriff auf die ADMIN$-Freigabe für die Computer benötigt, die Sie inventarisieren möchten (wie bei den meisten anderen Bestandsaufnahmeprodukten ohne Agent).
In der Anwendung können Sie alternative Anmeldeinformationen für Abfragen verwenden. Das ist nützlich, wenn der Scan mehrere Domänen umfasst. Nach dem Installieren der Anwendung können Sie einen IP-Adressbereich scannen, die Windows-Netzwerkermittlung verwenden, eine Liste von Computern importieren oder manuell eine Liste zu inventarisierender Windows-Arbeitsstationen angeben.
Von der Überwachungsfunktion von CCS Network Inventory werden Softwaredetails gesammelt: welche Anwendungen sind installiert, welche Hotfixes wurden angewendet, welches Betriebssystem und welches Service Pack sind auf dem Computer installiert bzw. welche Schriftarten sind installiert. Bei der Computerkonfiguration können Sie sehen, welche Dienste und sonstigen Prozesse ausgeführt werden, welche Ordner freigegeben sind, des Weiteren Laufwerkszuordnungen, Umgebungsvariable, Benutzerkonten, geplante Aufgaben, Startbefehle und welche Netzwerkprotokolle ausgeführt werden. Bei der Hardware können Sie die Details angeschlossener Monitore, Drucker, Festplatten (sowie deren Größen und Partitionen), Informationen zu CD- und DVD-Laufwerken, Prozessoren, Arbeitsspeicher und so weiter sehen. Außerdem können Sie benutzerdefinierte Scans für Registrierungswerte durchführen, die Dateianzahl ermitteln (z. B. Anzahl der mp3-Dateien) und den freien Speicherplatz auf Laufwerken einrichten.
Alle diese Informationen werden in der benutzerdefinierten Datenbank der Anwendung gespeichert und können dann zur Erstellung von Berichten verwendet werden. CCS Network Inventory bietet eine Reihe integrierter Berichte zum Visualisieren und Transportieren der Daten zur Überwachung und Berichterstattung. Wenn die integrierten Berichte und Abfrageinformationen nicht genau das enthalten, was Sie benötigen, können Sie mit dem integrierten SQL Query Builder-Tool eine ausführlichere oder spezifischere Abfrage der Daten schreiben.
Im Laufe der Zeit ist es meist eine gute Idee, Snapshots von der Umgebung anzufertigen, damit Sie Veränderungen erkennen können. Mit CCS Network Inventory können Sie diese Änderungen sehen, indem Sie zwei Instanzen der Informationsdatenbanken miteinander vergleichen. Beispielsweise können Sie den aktuellen Scan mit einem Scan vergleichen, der vor einem Jahr durchgeführt wurde, um zu sehen, wie viele Arbeitsstationen zu Windows Vista gewechselt haben, wie viele ihre Hardwarekomponenten im vergangenen Jahr aktualisiert haben oder welche Benutzer weiterhin nicht unterstützte Software ausführen, nachdem Sie sie gewarnt haben.
Als dieser Artikel verfasst wurde, wurde Windows 2008 Server durch CCS Network Inventory nicht vollständig unterstützt, aber es wurden die anderen Versionen von Windows bis hin zu Windows Vista unterstützt.

Preis: Ab 235 US-Dollar für bis zu 25 Knoten.
Verwalten von Remoteressourcen mit CCS Network Inventory

Schreiben an Toolbox Wenn Sie ein Lieblingstool oder -dienstprogramm haben, das Ihrer Meinung nach hier vorgestellt werden sollte, dann schreiben Sie eine E-Mail (in englischer Sprache) an den Autor unter tntools@microsoft.com.

Greg Steen ist Technologieexperte, Unternehmer und Enthusiast. Er ist immer auf der Suche nach neuen Tools, um IT-Experten Betriebs-, Qualitätssicherungs- und Entwicklungsprozesse zu erleichtern.


SQL – Fragen und Antworten Große Transaktionsprotokolle, Verwendungsfälle für repair und mehr
Paul S. Randal

F: Ich habe in Verbindung mit Sicherungen ein seltsames Verhalten bemerkt, von dem ich hoffe, dass Sie es mir erklären können. Wir sichern gelegentlich unsere 62 GB große Produktionsdatenbank, um die von unseren Anwendungsentwicklern verwendeten Daten zu aktualisieren. Dabei löschen wir stets die alte Kopie, bevor wir die neue wiederherstellen. Die wiederhergestellte Kopie hat die gleiche Größe wie die Produktionsdatenbank, und die Daten sehen identisch aus, der Wiederherstellungsvorgang dauert jedoch viel länger als der Sicherungsvorgang. Woran liegt das? Warum dauert die Wiederherstellung so viel länger als die Sicherung?
A: Die beschriebene Situation hat nichts Seltsames an sich. In Abhängigkeit von den Umständen ist dieses Verhalten im Allgemeinen zu erwarten. Der Unterschied zwischen der für eine Sicherung und der für eine Wiederherstellung benötigten Zeit beruht auf den Schritten, die bei den einzelnen Prozessen durchgeführt werden müssen.
Das Sichern einer Datenbank umfasst zwei Schritte. Im Grunde werden nur E/A-Lesevorgänge in der Datenbank und E/A-Schreibvorgänge auf dem Sicherungsgerät durchgeführt:
Sicherungsschritt 1 Alle zugeordneten Daten in den Datendateien lesen und auf das Sicherungsgerät schreiben.
Sicherungsschritt 2 Ein bestimmtes Transaktionsprotokoll lesen und auf die Sicherungsgeräte schreiben.
Die genaue Menge der erforderlichen Transaktionsprotokolleinträge kann stark variieren. Dabei handelt es sich um die Menge, die erforderlich ist, um die Datenbank bis zu einem konsistenten Zeitpunkt wiederherstellen zu können. (Eine ausführlichere Erklärung hierzu ist in meinem Blogbeitrag unter sqlskills.com/blogs/paul/2008/01/31/MoreOnHowMuchTransactionLogAFullBackupIncludes.aspx zu finden.)
Die Wiederherstellung einer Datenbank kann hingegen bis zu vier Schritte umfassen. Zudem sind die durchzuführenden Aufgaben komplizierter als reine E/A-Lese- und -Schreibvorgänge:
Wiederherstellungsschritt 1 Wenn die Datenbankdateien nicht vorhanden sind, diese erstellen.
Wiederherstellungsschritt 2 Alle Daten und das Transaktionsprotokoll der Sicherung lesen und in die betreffenden Datenbankdateien schreiben.
Wiederherstellungsschritt 3 Die Rollforwardphase der Wiederherstellung für das Transaktionsprotokoll ausführen.
Wiederherstellungsschritt 4 Die Rollbackphase der Wiederherstellung für das Transaktionsprotokoll ausführen.
Die erforderliche Gesamtzeit für beide Sicherungsschritte sollte ungefähr der für Wiederherstellungsschritt 2 benötigten Zeit entsprechen (bei ähnlicher Hardware und einem Server ohne Benutzeraktivität). Schritt 1 der Wiederherstellung kann viel Zeit in Anspruch nehmen, wenn die Datendateien groß sind und mit Null initialisiert werden müssen (das Verhalten in SQL Server 2000 und das Standardverhalten in SQL Server 2005).
Um dies zu verhindern, dürfen Sie vor dem Starten der Wiederherstellung die vorhandenen Dateien nicht löschen. Alternativ können Sie die sofortige Initialisierung aktivieren, damit die Dateien sehr schnell erstellt werden (weitere Informationen hierzu finden Sie unter msdn.microsoft.com/library/ms175935.aspx).
In Wiederherstellungsschritt 3 und 4 wird die Wiederherstellung für die Datenbank ausgeführt, um sie im Hinblick auf die Transaktionen in einen konsistenten Zustand zu überführen. Dabei handelt es sich um den gleichen Prozess, den eine Datenbank bei der Wiederherstellung nach einem Systemabsturz durchläuft. Die Dauer dieser Wiederherstellung hängt von der Menge der zu verarbeitenden Transaktionsprotokolleinträge ab. Wenn beispielsweise eine Transaktion mit sehr langer Laufzeit aktiv war, als die Sicherung erstellt wurde, befindet sich das gesamte Transaktionsprotokoll für diese Transaktion in der Sicherung und muss zurückgesetzt werden.

F: Ich versuche, mich in Bezug auf die Bereitstellung einer redundanten Kopie unserer Produktionsdatenbank zwischen Protokollversand und Datenbankspiegelung zu entscheiden. Ich bin hinsichtlich der Menge der Transaktionsprotokolleinträge besorgt, die zwischen den Servern versandt werden müssen, insbesondere für die Vorgänge zur Indexneuerstellung, die wir jede Nacht durchführen. Ich habe gehört, dass bei der Spiegelung anstelle des Transaktionsprotokolls die tatsächlichen Neuerstellungsbefehle gesendet werden und die Neuerstellungsvorgänge in der Spiegeldatenbank durchgeführt werden. Trifft dies zu? Dadurch sollte die Spiegelung eine noch bessere Lösung als der Protokollversand mit dem Modell der massenprotokollierten Wiederherstellung sein, oder?
A: Was Sie gehört haben, entspricht nicht der Wahrheit. Bei der Datenbankspiegelung werden die tatsächlichen Transaktionsprotokoll-Datensätze aus der Prinzipaldatenbank an den Spiegelserver gesendet, wo sie in der Spiegeldatenbank „wiedergegeben“ werden. Für eine gespiegelte Datenbank findet keinerlei Übersetzung oder Filterung statt, und T-SQL-Befehle werden nicht abgefangen.
Die Datenbankspiegelung unterstützt nur das vollständige Wiederherstellungsmodell, was bedeutet, dass ein Vorgang zur Indexneuerstellung stets vollständig protokolliert wird. Je nach der Größe der betroffenen Indizes kann dies die Generierung einer Vielzahl von Transaktionsprotokolleinträgen und somit eine große Protokolldatei für die Prinzipaldatenbank und eine beträchtliche Netzwerkbandbreite für das Senden der Protokolldatensätze zur Spiegeldatenbank bedeuten.
Sie können sich die Datenbankspiegelung als Echtzeitprotokollversand vorstellen (tatsächlich wurde in den frühen Entwicklungsphasen von SQL Server 2005 diese Bezeichnung für das Feature verwendet). Beim Protokollversand werden Sicherungen des Transaktionsprotokolls der primären Datenbank regelmäßig an den sekundären Server versandt und in der sekundären Datenbank wiederhergestellt.
Der Protokollversand unterstützt das vollständige Wiederherstellungsmodell und das Modell der massenprotokollierten Wiederherstellung. Für eine Indexneuerstellung in einer Datenbank mit Protokollversand und dem vollständigen Wiederherstellungsmodell wird dieselbe Menge von Transaktionsprotokolleinträgen wie für eine gespiegelte Datenbank generiert. Bei dem Datenbankszenario mit Protokollversand werden die Daten jedoch nicht kontinuierlich, sondern in einer Protokollsicherung (oder eine Reihe von Protokollsicherungen) an die redundante Datenbank gesendet.
Wenn das Modell der massenprotokollierten Wiederherstellung während der Indexneuerstellung in der Datenbank mit Protokollversand verwendet wird, wird nur eine minimale Menge von Transaktionsprotokolleinträgen generiert. Die nächste Transaktionsprotokollsicherung enthält dann jedoch auch alle Datendateiblöcke, die durch die Indexneuerstellung mit minimaler Protokollierung geändert wurden. Dies bedeutet, dass die Protokollsicherungen, die die Indexneuerstellung beim Modell der massenprotokollierten Wiederherstellung abdecken, nahezu dieselbe Größe aufweisen wie die Protokollsicherungen, die die Indexneuerstellung beim vollständigen Wiederherstellungsmodell abdecken.
Daher ist die Menge der Informationen, die an die redundante Datenbank gesendet werden müssen, für eine Indexneuerstellung in einer gespiegelten Datenbank und in einer Datenbank mit Protokollversand nahezu identisch. Der wirkliche Unterschied liegt darin, wie die Informationen gesendet werden – kontinuierlich oder in Batches.
Bei der Wahl zwischen diesen beiden Ansätzen sind zahlreiche weitere Faktoren zu berücksichtigen (die in nur einer Ausgabe von „SQL – Fragen und Antworten“ nicht alle erläutert werden können). Sie sollten feststellen, inwieweit alle diese Faktoren zu Ihren Anforderungen passen (beispielsweise akzeptable Datenverlustgrenze und zulässige Ausfallzeit), bevor Sie eine Entscheidung treffen.

F: Ich führe SQL Server 2005 aus, und eine meiner Datenbanken weist ein Transaktionsprotokoll auf, dessen Größe ständig zunimmt. Die Datenbank befindet sich im vollständigen Wiederherstellungsmodus, und ich führe Transaktionsprotokollsicherungen durch. Ich war davon ausgegangen, dass dies die Größenzunahme des Transaktionsprotokolls verhindern sollte. Wo genau liegt der Fehler?
A: Sie haben recht, dass die Durchführung von Transaktionsprotokollsicherungen im vollständigen Wiederherstellungsmodus von entscheidender Bedeutung ist. Es gibt jedoch weitere Faktoren, die dazu beitragen können, dass die Größe des Transaktionsprotokolls zunimmt. Es kommt vor allem darauf an, aus welchem Grund das Transaktionsprotokoll benötigt wird (oder aktiv sein muss). Weitere allgemeine Faktoren (außer fehlenden Transaktionsprotokollsicherungen), die Ihr Problem verursachen können, sind Replikation, Datenbankspiegelung und eine aktive Transaktion.
Bei der Replikation werden Ihre Transaktionsprotokoll-Datensätze asynchron gelesen und dann die zu replizierenden Transaktionen in eine separate Verteilungsdatenbank geladen. Alle Transaktionsprotokoll-Datensätze, die noch nicht vom Task „Replikationstransaktionsprotokoll-Leser“ gelesen wurden, können nicht freigegeben werden. Wenn Ihre Arbeitsauslastung zahlreiche Transaktionsprotokoll-Datensätze generiert und Sie ein großes Intervall für die Ausführung des Replikationstransaktionsprotokoll-Lesers festgelegt haben, kann sich eine große Menge von Datensätzen ansammeln und dazu führen, dass die Größe des Transaktionsprotokolls zunimmt.
Wenn Sie eine asynchrone Datenbankspiegelung ausführen, könnte es einen Überhang von Transaktionsprotokoll-Datensätzen geben, die noch nicht von der Prinzipaldatenbank zur Spiegeldatenbank gesendet wurden (als Sendewarteschlange der Datenbankspiegelung bezeichnet). Die Transaktionsprotokoll-Datensätze können erst freigegeben werden, nachdem sie erfolgreich gesendet wurden. Bei einer hohen Anzahl von generierten Transaktionsprotokoll-Datensätzen und begrenzter Bandbreite im Netzwerk (oder anderen Hardwareproblemen) kann der Überhang recht groß werden und dazu führen, dass die Größe des Transaktionsprotokolls zunimmt.
Wenn ein Benutzer eine explizite Transaktion startet (z. B. mithilfe einer BEGIN TRAN-Anweisung) und dann eine bestimmte Änderung vornimmt (beispielsweise durch eine DDL-Anweisung oder eine Einfüge-/Aktualisierungs-/Löschaktion), müssen die generierten Transaktionsprotokoll-Datensätze gespeichert werden, bis der Benutzer für die Transaktion einen Commit oder Rollback ausführt. Das bedeutet, dass alle nachfolgenden Transaktionsprotokoll-Datensätze, die durch andere Transaktionen generiert werden, ebenfalls nicht freigegeben werden können, da das Transaktionsprotokoll nicht selektiv freigegeben werden kann. Wenn dieser Benutzer beispielsweise nach Hause geht, ohne die Transaktion abzuschließen, nimmt die Größe des Transaktionsprotokolls weiter zu, da immer mehr Transaktionsprotokoll-Datensätze generiert werden, aber nicht freigegeben werden können.
Sie können feststellen, warum das Transaktionsprotokoll nicht freigegeben werden kann, indem Sie wie folgt die sys.databases-Systemkatalogsicht abfragen und die log_reuse_wait_desc-Spalte prüfen:
SELECT name AS [Database],
  log_reuse_wait_desc AS [Reason]
FROM master.sys.databases;
Wenn sich herausstellt, dass die Ursache eine aktive Transaktion ist, können Sie mithilfe der DBCC OPENTRAN-Anweisung weitere Informationen zur Transaktion abrufen:
DBCC OPENTRAN ('dbname')

F: Ich habe gehört, dass REPAIR_ALLOW_DATA_LOSS nur als letzter Ausweg zur Wiederherstellung nach einer Beschädigung verwendet und die Wiederherstellung stattdessen mithilfe von Sicherungen durchgeführt werden sollte. Können Sie erklären, warum „repair for SQL Server 2005“ nicht verwendet werden sollte und warum diese Option angesichts ihrer „Gefährlichkeit“ überhaupt im Produkt enthalten ist?
A: Zunächst einmal möchte ich darauf hinweisen, dass repair für SQL Server 2005 von mir geschrieben wurde. Das Problem bei REPAIR_ALLOW_DATA_LOSS (im Folgenden einfach als „repair“ bezeichnet) besteht darin, dass nicht klar ist, wie diese Option funktioniert. Der Name der repair-Option wurde gewählt, um darauf hinzuweisen, dass ihre Ausführung zum Verlust von Daten in der Datenbank führen kann. Die Methode, mit der das Feature in der Regel eine fehlerhafte Datenbankstruktur repariert, besteht darin, die fehlerhafte Struktur zu löschen und dann alle anderen Elemente in der Datenbank zu reparieren, auf die die gelöschte Struktur verwiesen hat oder die auf sie verwiesen haben. Die repair-Option ist wirklich als letztes Mittel dafür vorgesehen, die Datenbank in einen strukturell konsistenten Zustand zu überführen, und zielt nicht auf das Speichern von Benutzerdaten ab. Zwar legt es repair nicht darauf an, Benutzerdaten zu löschen, aber es werden auch keine Anstrengungen zum Speichern von Benutzerdaten unternommen.
Dies mag wie eine unverantwortliche Methode für die Durchführung von Reparaturen erscheinen, aber wenn die repair-Option verwendet werden muss, bietet sie die schnellste und zuverlässigste Methode für die Behebung von Schäden. Im Falle einer Notfallwiederherstellung ist Geschwindigkeit von höchster Wichtigkeit und Korrektheit unbedingt erforderlich. Es ist fast unmöglich, komplexere Reparaturalgorithmen zu entwickeln, die nachweislich in allen Fällen schnell und korrekt funktionieren. Der repair-Code enthält einige komplexe Algorithmen für den Fall, dass zwei Indizes beispielsweise dieselbe Seite oder derselbe Block zugewiesen ist. Der Algorithmus ist jedoch hauptsächlich für die Reparatur und damit verbundene Korrekturen vorgesehen.
Dennoch gibt es einige Probleme in Verbindung mit repair, die Sie kennen sollten:
  • Von repair werden beim Löschen fehlerhafter Strukturen keine Fremdschlüsseleinschränkungen berücksichtigt, sodass möglicherweise Datensätze in einer Tabelle gelöscht werden, die eine Fremdschlüsselbeziehung zu einer anderen Tabelle aufweist. Es kann nur festgestellt werden, ob dies geschehen ist, indem nach der Ausführung von repair DBCC CHECKCONSTRAINTS ausgeführt wird.
  • Repair berücksichtigt keine inhärente Geschäftslogik und keine auf Anwendungsebene definierten Datenbeziehungen, die durch das Löschen bestimmter Daten unterbrochen werden könnten. Eine solche Berücksichtigung ist auch nicht möglich. Beschädigungen können wiederum nur festgestellt werden, indem die in die Anwendung integrierte benutzerdefinierte Konsistenzüberprüfung ausgeführt wird.
  • Bestimmte Reparaturvorgänge können nicht repliziert werden. Die Ausführung von repair für einen Verleger oder einen Knoten in einer Peer-to-Peer-Topologie kann innerhalb der Topologie zu Inkonsistenzen führen, die manuell korrigiert werden müssen.
Aus diesen Gründen empfiehlt es sich stets, die Wiederherstellung nach einer Beschädigung mithilfe einer Sicherung und nicht durch Ausführung der repair-Option vorzunehmen. Repair wird jedoch im Produkt geboten, weil immer die Möglichkeit besteht, dass eine Situation eintritt, in der Ihre Datenbank fehlerhaft ist, keine Sicherung vorhanden ist und Sie eine Methode benötigen, mit der Sie die Datenbank schnell wieder online bringen können.

F: Ich bin gerade als DBA zu einem neuen Unternehmen gewechselt, und mir wurde die Verantwortung für mehrere Anwendungen und ihre Back-End-Datenbanken übertragen. Eine der Anwendungen weist bei der Durchführung von Aktualisierungen eine sehr schlechte Leistung auf. Ich habe das Problem untersucht und festgestellt, dass für jede der Tabellen, die von der Anwendung verwendet werden, eine enorme Anzahl von Indizes vorhanden ist. Ich habe mich umgehört, und es scheint so, als ob der vorherige DBA die Gewohnheit hatte, einen Index jeder Tabellenspalte sowie einige Kombinationen hinzuzufügen. Ich kann nicht glauben, dass all diese Indizes notwendig sind – wie kann ich feststellen, welche ich ohne Bedenken löschen kann? Wir verwenden SQL Server 2005.
A: Wie Sie bereits vermuten, trägt die große Anzahl von Indizes höchstwahrscheinlich wesentlich zu der schlechten Leistung bei. Jedes Mal, wenn eine Zeile in der Tabelle eingefügt, aktualisiert oder gelöscht wird, müssen entsprechende Vorgänge in jedem nicht gruppierten Index durchgeführt werden. Dadurch entsteht ein hoher Mehraufwand in Bezug auf E/A, CPU-Auslastung und Transaktionsprotokollgenerierung.
In SQL Server 2000 bestand die einzige Möglichkeit festzustellen, welche Indizes verwendet wurden, darin, Profile zu verwenden und Abfragepläne zu untersuchen. SQL Server 2005 enthält eine neue dynamische Verwaltungssicht (Dynamic Management View, DMV), mit der die Indexverwendung überwacht werden kann – sys.dm_db_index_usage_stats.
Diese DMV verfolgt, wann (und wie) ein Index seit dem Start der Datenbank, deren Bestandteil er ist, verwendet wurde. Die Statistiken für alle Datenbanken gehen beim Beenden von SQL Server verloren, und die Statistiken für eine einzelne Datenbank gehen verloren, wenn diese geschlossen oder getrennt wird. Dahinter steht der Gedanke, dass ein Index seit dem Start der Datenbank nicht verwendet wurde, wenn er nicht in der Ausgabe angezeigt wird.
Ein einfacher Ansatz für die langfristige Überwachung der Indexverwendung besteht darin, regelmäßig Snapshots der DMV-Ausgabe zu erstellen und die Snapshots dann zu vergleichen. Vielen Benutzern entgeht, dass Sie die Indexverwendung über einen gesamten Geschäftszyklus hinweg überwachen müssen. Wenn Sie lediglich einen Snapshot für einen einzigen Tag erstellt haben, finden Sie möglicherweise mehrere Indizes, die nicht verwendet werden. Falls diese Indizes aber verwendet werden, damit beispielsweise die Monatsendberichte schneller ausgeführt werden, sollten die Indizes wahrscheinlich nicht entfernt werden. Wenn ein Index wirklich über einen gesamten Geschäftszyklus hinweg nicht verwendet wurde, können Sie ihn wahrscheinlich löschen und dadurch Speicherplatz freigeben und die Leistung erhöhen.
In meinem Blogbeitrag unter sqlskills.com/blogs/paul/2007/10/05/IndexesFromEveryAngleHowCanYouTellIfAnIndexIsBeingUsed.aspx finden Sie einfachen Code, den Sie zum Erstellen periodischer Snapshots der DMV verwenden können.

Paul S. Randal ist der leitende Direktor von SQLskills.com und ein SQL Server-MVP. Er schrieb DBCC CHECKDB/repair für SQL Server 2005 und war bei der Entwicklung von SQL Server 2008 für das Kernspeichermodul zuständig. Als Experte für Notfallwiederherstellung, hohe Verfügbarkeit und Datenbankwartung ist Paul Randal ein regelmäßiger Referent bei Konferenzen. Sein Blog befindet sich unter SQLskills.com/blogs/paul.


Schwerpunkt Dienstprogramme Offline Virtual Machine Servicing Tool
Peter Skjøtt Larsen und Suveen Kumar Reddy Vuppala

Inhalt
Sicherheitsalbtraum
Aus dem Nähkästchen
Wartungsinfrastruktur
Verwenden des Tools
Vorschau
Die Virtualisierung einer Computerarbeitsauslastung bedeutet einfach, die Arbeitsauslastung mithilfe eines virtuellen Computers (virtual machine, VM) von der zugrunde liegenden Hardware zu lösen. In modernen IT-Abteilungen sind VMs in vielen Situationen von Nutzen, wie z. B. in folgenden:
Verschieben von Arbeitsauslastungen Mit VMs können Sie problemlos die Bandbreite der Arbeitsauslastungen für mehrere Setups je nach Nutzungsbedarf erhöhen oder verringern, ohne die Hardware entsprechend ändern zu müssen.
Entwickeln und Prüfen von Anwendungen Es ist möglich, mehrere VMs für jede Konfiguration anzulegen, die eine Anwendung unterstützen soll, ohne dass dedizierte Hardware nötig wäre.
Softwareaktualisierungen Mit VMs können Sie die neue Version eines Softwarepakets online schalten, während Sie die frühere Version offline nehmen, und das alles auf derselben Hardware.
Softwareverteilung VMs können als Verteilungsmedium für eine Branchenanwendung verwendet werden, die aus einer konsistenten Kombination von Software in einem vorgetesteten Paket besteht.

Sicherheitsalbtraum
Einer der Vorteile beim Einsatz von VMs besteht darin, dass Sie sie in einem Offlinezustand als VM-Abbilder speichern können. Sobald Sie die VMs benötigen, können Sie sie „wecken“ und damit viel schneller bereitstellen, als Sie die entsprechende Hardware bereitstellen könnten.
Das Bereithalten einer immer größeren Anzahl von Computerumgebungen im Offlinezustand stellt jedoch einige Herausforderungen hinsichtlich der Wartung. Bei vielen Methoden zur Softwareaktualisierung müssen die erforderlichen Systeme online sein, um nach Aktualisierungen suchen oder diese automatisch abrufen zu können.
Wenn ein VM nicht online ist, handelt es sich lediglich um eine Datei in einem Computer, weshalb er nicht mit Aktualisierungsmethoden interagieren kann. Ein VM, der nach einigen Monaten im Offlinezustand wieder online geschaltet wird, kann folglich zu einer Bedrohung für das Netzwerk werden, oder das Netzwerk könnte umgekehrt eine Bedrohung für den VM darstellen.
Es geht nicht einfach nur um fehlende Betriebssystemaktualisierungen. Veraltete Anwendungen oder Virenprofile können den VM anfällig machen, oder der VM entspricht nicht mehr den Unternehmensstandards.
Um Kunden bei der Herausforderung zu helfen, offline geschaltete VMs auf dem neuesten Stand zu halten, hat das Microsoft Solution Accelerator Team das Offline Virtual Machine Servicing Tool entwickelt. Gemeinsam mit System Center Configuration Manager (SCCM) 2007, Windows Server Update Services (WSUS) 3.0 und System Center Virtual Machine Manager (VMM) 2007 koordiniert dieses Tool die Aktualisierung gespeicherter VMs. Abbildung 1 zeigt eine konzeptionelle Darstellung des Tools sowie das Herstellen einer Verbindung zu verschiedenen externen Komponenten.
Abbildung 1 Funktionsweise des Offline Virtual Machine Servicing Tool (zum Vergrößern auf das Bild klicken)
Um VMs für Aktualisierungen verfügbar zu machen, stellt das Tool die VMs vorübergehend mithilfe von VMM auf Wartungshosts bereit. Eine Wartungshostkonfiguration umfasst in der Regel die erforderliche CPU und den nötigen Speicher, um mehrere VMs gleichzeitig auszuführen, sodass das Tool die VMs in Batches verwalten kann.
Sobald die VMs auf den Wartungshosts aktiv sind, kann entweder SCCM oder WSUS die notwendigen Aktualisierungen bereitstellen. Nach dem Anwenden der Aktualisierungen versetzt das Tool die VMs mit VMM wieder in den Offlinezustand zurück. (Beachten Sie, dass das Tool nur VMs unterstützt, die von VMM verwaltet werden.)

Aus dem Nähkästchen
Das Offline Virtual Machine Servicing Tool koordiniert mittels Windows Workflow Foundation (WF) den Aktualisierungsprozess für einen VM. Der Prozess umfasst einige Entscheidungspunkte: ein geeignetes Updateverwaltungssystems auswählen; den nächsten verfügbaren Wartungshost auswählen, der für den VM geeignet ist; die erfolgreiche Durchführung der Aktualisierung prüfen; Ausnahmen bewältigen.
Eine Windows WF-basierte Lösung bot dem Entwicklungsteam die größtmögliche Flexibilität, um den Prozess zu ändern und weiterzuentwickeln. Auch Benutzer erhalten damit eine stabile Lösung, die sich auf bestimmte Anforderungen zuschneiden lässt. An kritischen Stellen im Prozess ermöglichen integrierte Schritte vor und nach dem eigentlichen Workflow die Anpassung der Lösung.
Das Tool setzt einzelne Aufgaben unterhalb der Workflowebene um, was ideal an die Windows PowerShell-API in VMM anknüpft. Die Microsoft .NET Framework-basierte Benutzeroberfläche ist auf dieselbe Weise wie System Center-Produkte gestaltet, sodass neue Benutzer sich schnell zurechtfinden.

Wartungsinfrastruktur
Einer der Grundsätze bei der Wartungsinfrastruktur besteht darin, die Netzwerksicherheit so zu konfigurieren, dass die VMs während des Aktualisierungsprozesses vor Schaden bewahrt werden. In Version 1.0 des Tools wird dies mit einem virtuellen privaten Netzwerk (VPN) erzielt, mit dem der VMM und das jeweilige Aktualisierungssystem (WSUS oder SCCM) eine Verbindung herstellen. Die am besten geeignete Infrastruktur für eine VMM-Bibliothek ist ein Fibre Channel-SAN (Storage Area Network), das die rasche Übertragung von VM-Abbildern auf die Wartungshosts ermöglicht.
Alle VMs müssen Mitglieder derselben Domäne sein, die ihrerseits Active Directory und DNS verwenden muss. Für VMM, WSUS, SCCM und die VMM-Bibliothek können separate Server dediziert werden, aber in kleineren Umgebungen können auch Kombinationen von virtuellen Servern zum Einsatz kommen. Natürlich müssen die Wartungshosts physische Server sein.

Verwenden des Tools
Nachdem Sie die Wartungsinfrastruktur eingerichtet haben, müssen Sie bestimmte Einstellungen auf ihre Richtigkeit prüfen, bevor das Tool starten kann. Stellen Sie sicher, dass VMM alle geeigneten VMs verwaltet, dass auf jedem VM der richtige Aktualisierungsclient installiert ist und dass die notwendigen Aktualisierungspakete in WSUS oder SCCM konfiguriert sind. Die Prüfung, ob Wartungshostgruppen in VMM konfiguriert sind, ist optional.
Wenn Sie bereit sind, starten Sie das Offline Virtual Machine Servicing Tool. Dieses Tool umfasst eine Reihe eigener Konfigurationsschritte. Bestimmen Sie den VMM-Server und den zugehörigen WSUS- oder SCCM-Server, und geben Sie dann an, welche Gruppe von Wartungshosts (sofern die Wartungshosts zu Gruppen zusammengefasst sind) und welche Wartungshosts in dieser Gruppe verwendet werden sollen (siehe Abbildung 2). Auf Wunsch können Sie auch VM-Gruppen für die Verwaltung konfigurieren. Dies ist optional.
Abbildung 2 Konfigurieren des Offline Virtual Machine Servicing Tool (zum Vergrößern auf das Bild klicken)
Nach dem Konfigurieren des Tools erstellen Sie die Wartungsaufträge. Ein Wartungsauftrag enthält alle Informationen, mit denen das Tool bestimmte VMs verwaltet: Verwenden von WSUS oder SCCM für Aktualisierungen; Speicherorte des VMM-Servers und des WSUS- oder SCCM-Servers; Identitäten der verwalteten VMs; Typ (und ggf. Identität) des Netzwerks, das für den Prozess verwendet werden soll; Identität der zu verwendenden Wartungshosts; Anmeldeinformationen für den Zugriff auf die VMs, den VMM-Server und den WSUS- oder SCCM-Server; Zeitplan für die Ausführung des Wartungsauftrags (sofort ausführen oder zu einem bestimmten Termin).
Wenn Sie ein Datum und eine Uhrzeit Zeit für den Wartungsauftrag angeben, ermittelt die Windows-Aufgabenplanung den Zeitpunkt, zu dem der Auftrag gestartet werden soll. Während des Wartungsauftrags arbeitet das Offline Virtual Machine Servicing Tool die folgende Sequenz für jeden VM ab:
  • Nächsten VM aus der VMM-Bibliothek auswählen.
  • Abfrage an VMM senden und den am besten geeigneten Wartungshost ermitteln.
  • VM auf dem Wartungshost bereitstellen.
  • Verbindung des VM zum richtigen Netzwerk sicherstellen.
  • VM starten.
  • Prüfen, ob der richtige Aktualisierungsclient auf dem VM installiert ist.
  • Aktualisierungsprozess auslösen.
  • Beendigung des Aktualisierungsprozesses abwarten.
  • VM herunterfahren.
  • VM wieder in der VMM-Bibliothek speichern.
Der Zeitaufwand für die Aktualisierung der VM-Bibliothek schwankt beträchtlich, je nach der Anzahl und der Kapazität der Wartungshosts, der Zugriffsgeschwindigkeit des VMM-Bibliothekspeichers und der Art der Aktualisierungen.
Beachten Sie, dass die aktuelle Version (1.0) des Offline Virtual Machine Servicing Tool nicht den Netzwerkzugriffsschutz (network access protection, NAP) unterstützt, der eine äußerst attraktive Möglichkeit ist, die VMs vor dem Netzwerk zu schützen. Darüber hinaus werden auch die Hyper-V-Technologie in Windows Server 2008 sowie die Verwendung von Windows Server 2008 als Clientbetriebssystem nicht unterstützt.
In Kürze werden neuere Versionen von SCCM, WSUS und VMM veröffentlicht, und Version 2.0 des Offline Virtual Machine Servicing Tool wird diese Versionen ebenso wie Hyper-V und die Verwendung von Windows Server 2008 auf dem Client unterstützen. Außerdem wird das Tool den NAP für die Netzwerkisolierung unterstützen. Sie können das Offline Virtual Machine Servicing Tool unter technet.microsoft.com/cc501231 herunterladen.

Peter Skjøtt Larsen ist leitender Produktmanager bei Microsoft. Bevor er zu Microsoft kam, war Larsen sowohl an der Architektur als auch an der Entwicklung von Betriebssoftware für Telekommunikationsanbieter sowie an der Standardisierung und Entwicklung drahtloser Dienste beteiligt.
Suveen Kumar Reddy Vuppala ist leitender Softwareentwicklungsingenieur bei Microsoft. Zuvor befasste er sich sieben Jahre mit dem Entwurf und der Entwicklung von Echtzeitüberwachungstools und Bereitstellungslösungen für Microsoft.


Windows PowerShell Leistungsfähige Profile
Don Jones

Inhalt
Shells, Hosts und Profile
Verwenden Ihres Profils
Erstellen einer benutzerdefinierten Konsole
Weitere Profiltricks
Vorsicht, Profile!
Wenn Sie diese Rubrik regelmäßig lesen, wissen Sie jetzt, dass Windows PowerShell ein System von Profilen unterstützt. Dabei handelt es sich im Grunde um Shellskripts mit der Dateinamenerweiterung .ps1, die bei Ausführung der Shell automatisch ausgeführt werden. Sie stellen beispielsweise eine hervorragende Möglichkeit für das Definieren benutzerdefinierter Aliase dar. Bei jeder Ausführung der Shell können Sie das Profil Ihre Aliase automatisch definieren lassen, sodass sie bei jeder Verwendung der Shell verfügbar sind.
Die Shell definiert die folgenden vier verschiedenen Profile:
  • Ein Profil, das für alle Shells und alle Benutzer des Computers gilt.
  • Ein Profil, das für alle Benutzer und nur für die Microsoft PowerShell-Shell gilt.
  • Ein Profil, das für den aktuellen Benutzer und alle Shells gilt.
  • Ein Profil, das für den aktuellen Benutzer und nur die Microsoft PowerShell-Shell gilt.
Das Konzept „alle Shells“ kann etwas verwirrend sein. Die Terminologie beruht auf einigen frühen Entwicklungskonzepten von Windows PowerShell, die nicht in das Endprodukt aufgenommen wurden. Heute wäre der Begriff „alle Hosts“ wahrscheinlich passender.

Video
Don Jones führt vor, wie Sie Profile zur Anpassung der Windows PowerShell-Shell erstellen können.

Shells, Hosts und Profile
Windows PowerShell selbst ist ein Satz von Microsoft .NET Framework-Assemblys. Ich bezeichne diesen Teil der Shell gern als Windows PowerShell-Modul, da es die Funktionalität enthält, an die Sie bei Windows PowerShell im Allgemeinen denken. Es gibt jedoch keine integrierte Möglichkeit für Benutzer, mit diesem Modul zu interagieren. Damit Sie die Shell tatsächlich verwenden können, muss das Modul von einer Hostanwendung (einem Host) geladen werden.
Die Anwendung „powershell.exe“, an deren Ausführung Sie wahrscheinlich gewöhnt sind, ist ein solcher Host. Die in der Community Technology Preview (CTP) von Windows PowerShell 2.0 enthaltene Anwendung „gpowershell.exe“ ist ein weiterer Host. Diese Beziehung zwischen Hosts und Shells ist nicht ganz so einfach, wie ich es hier dargestellt habe, aber meine vereinfachte Erklärung deckt das Verhalten ab, das Sie sehen.
Es ist wichtig zu verstehen, dass Sie wahrscheinlich den Host „powershell.exe“ verwenden, wenn Sie über eine textorientierte Befehlszeilenschnittstelle mit der Shell interagieren. Dies gilt selbst dann, wenn Sie die Shell über eine Verknüpfung gestartet haben, die von einer anderen Anwendung wie der Exchange-Verwaltungsshell installiert wurde. Die Exchange-Verwaltungsshell ist keine andere Shell oder Hostanwendung, sondern der normale Host „powershell.exe“, der lediglich mithilfe einer Verknüpfung gestartet wurde, die einen Satz von vorab zu ladenden Snap-Ins und Skripts angibt. Diese Snap-Ins aktivieren die Exchange-Verwaltungsfunktionalität innerhalb der Shell. Sie verwenden aber nach wie vor die gleiche Shell.
Für die Profile für den Host „powershell.exe“ gelten (unter Windows Vista) die folgenden Speicherorte:
  • %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 Dieser Speicherort gilt für alle Benutzer des Computers und für alle Shells.
  • %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 Dieser Speicherort gilt für alle Benutzer des Computers, aber nur für die Microsoft.PowerShell-Shell.
  • %UserProfile%\Documents\WindowsPowerShell\profile.ps1 Dieser Speicherort gilt nur für den aktuellen Benutzer und für alle Shells.
  • %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 Dieser Speicherort gilt nur für den aktuellen Benutzer und nur für die Microsoft.PowerShell-Shell.
Diese Profile werden nicht standardmäßig erstellt. Sie sind nur vorhanden, wenn Sie sie erstellen.
Jede Hostanwendung ist für das Laden und Ausführen des richtigen Profils verantwortlich. Wenn eine bestimmte Hostanwendung „entscheidet“, überhaupt keine Profile zu laden, muss sie diese auch nicht laden. Die Profilausführung wird vom Windows PowerShell-Modul nicht automatisch durchgeführt.
Die einfachste Möglichkeit, den Überblick über alle diese Aspekte zu behalten, besteht darin, die Shell einfach zu öffnen, „$profile“ einzugeben und dann die Eingabetaste zu drücken. Dadurch wird der vollständige Pfad angezeigt, den die Shell als „primäres“ Profil zu verwenden versucht (das benutzer- und shellspezifische Profil). Sie können dieses Skript dann erstellen oder ändern, wonach es bei jedem Start der Shell ausgeführt wird.

Verwenden Ihres Profils
Wie bereits erwähnt, werden Profile häufig zum Definieren benutzerdefinierter Aliase verwendet. Sie können auch benutzerdefinierte PSDrives hinzufügen (dabei handelt es sich im Grunde um zugeordnete Laufwerke, die vollständig innerhalb von Windows PowerShell existieren.) Ein weniger häufiger Verwendungszweck besteht darin, auf Grundlage der Softwareprodukte, die Sie in Ihrer Umgebung verwenden, eine Art Supershell zu erstellen, die jede Verwaltungsaufgabe übernehmen kann, die Sie eventuell benötigen. Um das Konzept der Supershell wirklich erklären zu können, muss ich Ihnen zunächst einige Hintergrundinformationen liefern.
Die Produktgruppe innerhalb von Microsoft, die Windows PowerShell entwickelt, ist auch für viele andere zentrale Verwaltungstechnologien verantwortlich, einschließlich der Microsoft Management Console (MMC). Die MMC bietet eine gute Analogie für die Funktionsweise von Windows PowerShell. Wenn Sie mmc.exe ausführen, beginnen Sie mit einer leeren Konsole, die nicht viel Funktionalität bietet. Sie fügen MMC-Snap-Ins hinzu, um eine funktionsfähige Konsole zu erstellen.
Wenn Sie Ihre Konsole in der gewünschten Weise konfiguriert haben, speichern Sie die Konsole in einer Datei mit der Dateinamenerweiterung „.msc“. Diese gespeicherte Konsolendatei ermöglicht Ihnen, Ihre benutzerdefinierte Konsole jederzeit schnell erneut zu laden.
Statt benutzerdefinierte MMC-Konsolen zu erstellen, verwenden viele Administratoren ausschließlich die Konsolen, die zusammen mit den von ihnen verwalteten Produkten installiert werden. In Exchange Server wird z. B. eine Konsole erstellt, die nur das Exchange Server-Snap-In enthält. „Active Directory-Benutzer und -Computer“ ist eine weitere vorab erstellte Konsole, die nur ein einziges Snap-In enthält.
Windows PowerShell funktioniert weitgehend in derselben Weise. Das Symbol „Exchange-Verwaltungsshell“, das mit den Exchange Server 2007-Verwaltungstools installiert wird, ist tatsächlich eine Verknüpfung zu powershell.exe mit Anweisungen zum Laden einer Konsolendatei. Shellkonsolendateien besitzen die Dateinamenerweiterung „.psc1“ und enthalten eine Liste von vorab zu ladenden Snap-Ins (so wie eine .msc-Datei eine Liste von Snap-Ins enthält, die von der MMC für Sie vorab geladen werden). Sie sind jedoch nicht auf die Verwendung dieser im Voraus erstellten Konsolen angewiesen. Sie können – genau wie bei der MCC – eine benutzerdefinierte Konsole erstellen und diese zur Durchführung aller Ihrer Verwaltungsaufgaben verwenden. Profile spielen hierbei eine Schlüsselrolle.

Erstellen einer benutzerdefinierten Konsole
Um eine benutzerdefinierte Konsole zu erstellen, sollten Sie zunächst nach dem vollständigen Namen jedes Snap-Ins suchen, mit dem Sie arbeiten möchten. Stellen Sie sicher, dass alle erforderlichen Verwaltungstools auf Ihrem Computer installiert sind. Führen Sie dann in Windows PowerShell „Get-PSSnapin –registered“ aus. Dadurch werden alle verfügbaren Snap-Ins aufgelistet, die registriert sind, aber noch nicht geladen wurden. Erstellen oder bearbeiten Sie dann das entsprechende Windows PowerShell-Profil. Fügen Sie die Add-PSSnapin-Befehle zum Laden jedes Snap-Ins hinzu, das immer verfügbar sein soll. Hierzu können Snap-Ins für Exchange Server, System Center-Produkte und Snap-Ins von Drittanbietern wie die PowerShell-Communityerweiterungen gehören. Speichern Sie dann Ihr Profil (vergessen Sie nicht, das Profil digital zu signieren, wenn Ihre Windows PowerShell-Ausführungsrichtlinie dies erfordert), und schließen Sie die Shell. Wenn Sie die Shell erneut öffnen, werden alle in Ihrem Profil aufgelisteten Snap-Ins automatisch geladen.
Ein anderes Verfahren besteht darin, alle Ihre Snap-Ins (mit Add-PSSnapin und den Namen der Snap-Ins) in die Shell zu laden und dann „Export-Console“ auszuführen, um eine .psc1-Konsolendatei zu erstellen, die alle Snap-Ins enthält, die Sie gerade verwenden. Sie können diese .psc1-Konsolendatei zum Erstellen einer neuen Windows PowerShell-Verknüpfung verwenden, die den Parameter „PSConsoleFile“ und Ihre benutzerdefinierte .psc1-Datei angibt. Diese Verknüpfung würde dann Ihre Konsole verwenden und alle angegebenen Snap-Ins automatisch laden.

Weitere Profiltricks
Ich verwende mein Windows PowerShell-Profil, um bei jedem Start der Shell eine Reihe weiterer nützlicher Aufgaben durchzuführen. Wenn die Shell auf meinem System gestartet wird, werden unter anderem die folgenden Schritte durchgeführt:
  1. Ich führe „Get-Credential“ für mein Domänenadministratorkonto aus und speichere die Ergebnisse in einer Variablen namens „$cred“. Dadurch wird $cred in der gesamten Shell verfügbar. Ich kann die Variable dann an den –credential-Parameter verschiedener Cmdlets (z. B. des Cmdlet „Get-WmiObject“) übergeben. Da $cred das Kennwort speichert, kann ich diese Cmdlets verwenden, ohne nach einem Kennwort gefragt zu werden.
  2. Ich führe „Cd C:\“ aus, damit die Shell im Stammverzeichnis des Laufwerks C: meines Computers gestartet wird.
  3. Ich führe „New-Alias of Out-File“ aus, um einen Alias namens „of“ zu erstellen, damit ich dann „of“ anstelle von „Out-File“ verwenden kann. Da ich dieses Cmdlet sehr häufig verwende, ist die Definition des kurzen Alias sehr nützlich.
Ich versuche, einen Testschlüssel im Laufwerk HKLM: der Shell zu erstellen, das den HKEY_LOCAL_MACHINE-Teil der Registrierung darstellt. Wenn ein Fehler auftritt, weiß ich, dass die Shell ohne erhöhte Rechte gestartet wurde. Für meine Arbeit benötige ich in der Regel erhöhte Rechte, und auf diese Weise kann ich vorab schnell feststellen, ob ich über erhöhte Rechte verfüge, bevor ich ernsthaft mit der Arbeit beginne.
Ich definiere eine benutzerdefinierte Funktion namens „Ping-Address“, die einen Computernamen oder eine IP-Adresse annimmt und in Abhängigkeit davon, ob der Computer per Ping erreichbar ist, den Wert „True“ oder „False“ zurückgibt. Ich verwende diese Funktion häufig bei meiner Arbeit, und wenn sie in meinem Profil definiert ist, wird sie in meiner Shell global verfügbar.

Cmdlet des Monats: Get-WmiObject
Aufmerksamen Beobachtern dürfte auffallen, dass ich ein Cmdlet behandle, das ich schon einmal vorgestellt habe. Ich möchte Ihnen aber einen praktischen Trick verraten, der damit möglich ist. Ich sehe häufig, dass Administratoren versuchen, mit dem folgenden Verfahren WMI-Informationen (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation) von mehreren Computern abzurufen, deren Namen in einer Textdatei aufgelistet sind:
Get-Content c:\computers.txt | ForEach-Object
  { Get-WmiObject Win32_Service –comp $_ }
Obwohl dieses Verfahren funktioniert, sind Sie nicht wirklich darauf angewiesen, da „Get-WmiObject“ ein Array von Computernamen für den Parameter „–computerName“ annehmen kann. Um die gleiche Wirkung zu erzielen, können Sie einfach folgenden Code verwenden:
Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)
Wenn Sie den Befehl „Get-Content“ in Klammern setzen, wird die Shell angewiesen, den Befehl auszuführen und die Ergebnisse – ein Array von Computernamen – im Parameter „–computerName“ zu speichern.
Vorsicht, Profile!
Beachten Sie, dass powershell.exe nicht die einzige Anwendung ist, von der die Microsoft.PowerShell-Profile oder die für alle Shells geltenden Profile geladen werden. In vielen integrierten Entwicklungsumgebungen (integrated development environments, IDEs), die Windows PowerShell-Unterstützung bieten – einschließlich PrimalScript von SAPIEN Technologies, PowerGUI von Quest Software und PowerShell Plus von ShellTools – werden dieselben Profile geladen, um eine mit dem Host „powershell.exe“ vergleichbare Funktionalität zu bieten.
Ein großes Profil, das viele Snap-Ins lädt, kann dazu führen, dass diese Anwendungen langsamer gestartet werden, da das Windows PowerShell-Modul zahlreiche Anweisungen ausführen muss, bevor es für die Hostanwendung bereit ist. Tatsächlich kann selbst der Start von powershell.exe einige Zeit in Anspruch nehmen, wenn Sie ein sehr großes Profilskript ausführen müssen.
Snap-Ins, die Cmdlets mit demselben Namen definieren, können ebenfalls Konflikte verursachen. Wenn zwei Snap-Ins beispielsweise ein Cmdlet namens „Get-User“ definieren, führt Windows PowerShell keines der Cmdlets aus, bis Sie den vollqualifizierten Namen des Cmdlet verwenden, um das gewünschte Cmdlet anzugeben. Dieser vollqualifizierte Name kann sich als umständlich erweisen, da die Namen von Snap-Ins recht lang sein können. Wenn ich mit diesem Problem konfrontiert werde, gebe ich in der Regel das Vorhaben auf, diese beiden Snap-Ins gleichzeitig laden zu lassen. Stattdessen lade ich nur das Snap-In, das ich in meinem Profil am meisten verwende. Wenn ich dann das andere Snap-In laden und verwenden muss, verwende ich eine separate, „neue“ Shell.
Windows PowerShell-Profile können ein hohes Maß an zusätzlichem Komfort für die Shell bieten. Wenn sie aber von Malware zu böswilligen Zwecken bearbeitet werden, können Profile auch großen Schaden anrichten. Sie können Ihr Profil schützen, indem Sie es digital signieren und Windows PowerShell für die Verwendung der AllSigned-Ausführungsrichtlinie konfigurieren oder die NTFS-Dateiberechtigungen für alle Ihre Profile so ändern, dass sie über Ihr normales Benutzerkonto nicht geändert werden können.

Don Jones ist der Autor von Windows PowerShell: TFM und VBScript, WMI, and ADSI Unleashed. Sie können ihn über die Website PowerShellCommunity.org erreichen.


Hey, Scripting Guy! Berühmte letzte Worte
Die Scripting Guys von Microsoft

Der berühmte griechische Philosoph Sokrates († 399 v. Chr., kurz vor der Geburtsstunde des Skripting Editor) ist wohl am bekanntesten für seine Aussage: „Ein ungeprüftes Leben ist nicht lebenswert.“ Die meisten Menschen kennen diesen Spruch. Aber erstaunlicherweise haben die Scripting Guys vor kurzem entdeckt, dass Sokrates nie gesagt, dass ein ungeprüftes Leben nicht lebenswert. Wie sich herausstellt, war dies eine Fehlübersetzung eines mittelalterlichen Schreibers vor Hunderten von Jahren. Was Sokrates tatsächlich gesagt hatte, war: „Eine ungeprüfte XML-Datei ist nicht habenswert.“
Endlich gibt es einen philosophischen Spruch, der tatsächlich Sinn ergibt! XML wird heutzutage immer beliebter. Eine schnelle Suche mit einem Testcomputer der Scripting Guys liefert mehr als 500 XML-Dateien, die von verschiedenen Systemen oder Anwendungen verwendet werden.
Natürlich sind auch viele sehr wichtige Daten jetzt im XML-Format gespeichert. Das ist auch gut so. Es sei denn, die Daten sind ungeprüft. Leider ist das oft der Fall, manchmal sogar aus dem folgenden einfachen Grund: Viele Menschen wissen nicht, wie sie eine XML-Datei überhaupt untersuchen können. Insbesondere wissen sie nicht, wie sie diese XML-Datei abfragen und durchsuchen sollen.
Hinweis Falls Sie sich nicht sonderlich gut mit griechischen Philosophen auskennen: Sokrates war ein großer Befürworter der Methode, durch das Land zu ziehen und über Dinge zu sprechen, aber er hatte nicht allzu viel dafür übrig, tatsächlich etwas zu tun, weshalb seine Ehefrau Xanthippe ihn als „nutzlosen Müßiggänger“ bezeichnete. So ist gleich erkennbar, warum die Scripting Guys ein Faible für Sokrates haben.
Einige Leser werden jetzt natürlich denken: „He, einen Moment mal: Haben die Scripting Guys das Durchsuchen von XML-Dateien nicht schon in einem älteren Artikel behandelt („Autos nachjagen ... und XML“, technet.microsoft.com/magazine/cc162506)? Warum bringen sie dieses Thema jetzt wieder zur Sprache? Sind die Scripting Guys so faul, dass sie denselben Artikel glatt noch einmal schreiben?“
Ob Sie es glauben oder nicht: wir sind sogar noch fauler. Aber das ist nicht der wichtigste Grund, warum wir dieses Thema noch einmal anschneiden. In unserem früheren Artikel haben wir die Arbeit mit einer XML-Datei besprochen, die wie der Code in Abbildung 1 strukturiert war. Jeder einzelne Eigenschaftswert stellte dabei einen einzigen Knoten in der Datei dar.
Abbildung 1 XML-Datei nur mit Knoten
<?xml version='1.0'?>
  <INVENTORY>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Human Resources
      </department>
      <name>atl-ws-001</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Finance</department>
      <name>atl-ws-002</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows Vista</os>
      <department>Finance</department>
      <name>atl-ws-003</name>
    </COMPUTER>
  </INVENTORY>
Das ist toll, aber XML-Dateien können – wie viele Menschen sofort schrieben und anmerkten – nicht nur auf diese Weise strukturiert werden. Im vorhergehenden Beispiel besaß jeder Computer in der Datei einen eigenen Knoten, und jeder dieser Knoten umfasste wiederum einige untergeordnete Knoten (Betriebssystem, Abteilung, Name). Es ist jedoch auch möglich, eine XML-Datei zu erstellen, in der die einzelnen Knoten keine untergeordneten Knoten besitzen, sondern stattdessen zusätzliche Eigenschaftswerte als Attribute konfiguriert sind. So wie die Datei in Abbildung 2.
Abbildung 2 XML-Datei mit Attributen
<?xml version='1.0'?>
  <HARDWARE>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-001</COMPUTER>
      <COMPUTER os="Windows XP" department="Finance">atl-ws-002</COMPUTER>
      <COMPUTER os="Windows Server 2003" department="IT">atl-fs-003</COMPUTER>
      <COMPUTER os="Windows Vista" department="IT">atl-ws-004</COMPUTER>
      <COMPUTER os="Windows Vista" department="Human Resources">atl-ws-005</COMPUTER>
      <COMPUTER os="Windows Vista" department="Finance">atl-ws-006</COMPUTER>
      <COMPUTER os="Windows XP" department="Sales">atl-ws-007</COMPUTER>
      <COMPUTER os="Windows Server 2008" department="IT">atl-fs-008</COMPUTER>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-009</COMPUTER>
      <COMPUTER os="Windows Vista" department="Sales">atl-ws-010</COMPUTER>
  </HARDWARE>
Ist das ein Problem? Durchaus. Das Skript, das wir Ihnen vor längerer Zeit in einem uralten Artikel präsentiert hatten, funktioniert nicht mit einer XML-Datei, die wie die in Abbildung 2 gezeigte Datei strukturiert ist. Es geht einfach nicht. Das ist definitiv ein Problem, weil viele von Ihnen in der Lage sein müssen, diese Art von XML-Datei zu lesen.
Ihr Wunsch war uns Befehl. Nun ja, Ihr Wunsch und eineinhalb Jahre Zeit, bis wir das Problem endlich angingen.
Bevor wir weiter ins Detail gehen, wollen wir unsere XML-Datei näher betrachten. In diesem Fall haben wir eine Datei mit dem primären Knoten namens HARDWARE. Jeder einzelne Computer ist ein untergeordneter Knoten von HARDWARE. Außerdem besitzen diese Knoten je zwei Attribute: „os“ (hier wird der Name des Betriebssystems gespeichert, das auf dem Computer installiert ist) und „department“ (der Name der Abteilung, zu der der Computer gehört).
Angenommen, wir möchten eine Liste aller Computer abrufen, auf denen Windows XP ausgeführt wird. Können wir das mit einem Skript erledigen? Selbstverständlich.
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("HARDWARE.xml")

Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")

For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
Sehen wir einmal, was wir hier haben. Zunächst erstellen wir eine Instanz des Microsoft.XMLDOM-Objekts. Wie der Name schon sagt, gibt uns dieses Objekt die Möglichkeit, mit XML-Dateien zu arbeiten. Sobald wir das Objekt erstellt haben, setzen wir die Async-Eigenschaft auf „False“. Damit teilen wir dem Skript mit, dass wir das Dokument synchron statt asynchron laden möchten. Warum sollte das für das Skript wichtig sein? Um ehrlich zu sein, macht das dem Skript selbst nichts aus. Skripts sind schließlich unbelebte Objekte (wie die Scripting Guys).
Aber Sie sollten das wichtig nehmen. Wenn wir das Dokument asynchron geladen hätten, würde das Skript auf jeden Fall weiter abgearbeitet, selbst wenn das Dokument nicht vollständig geladen wird. Das ist nicht gut. Stellen Sie sich nur die Probleme vor, die auftreten könnten, wenn Sie versuchen, eine Aufgabe mit einem Dokument durchzuführen, das noch gar nicht vorhanden ist. Das synchrone Laden einer XML-Datei sorgt dafür, dass die Datei vollständig geladen wird, bevor das Skript weiter abläuft.
Welch überraschender Zufall: Jetzt sind wir an dem Punkt angelangt, an dem wir unsere XML-Datei laden. Hierzu rufen wir die Load-Methode auf, und wir öffnen die Datei „C:\Scripts\HARDWARE.xml“, die uns zur folgenden Zeile im Code bringt:
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")
Hier fragen wir die XML-Datei mit der selectNodes-Methode ab, und wir teilen dem Skript mit, welche XML-Knoten abgerufen werden sollen. Beachten Sie die Syntax, die zugegebenermaßen etwas ungewöhnlich ist.
Zunächst müssen wir den Pfad innerhalb der XML-Datei angeben. Unsere XML-Datei besitzt einen Knoten mit der Bezeichnung HARDWARE in der höchsten Ebene, gefolgt von einer Reihe von Knoten zweiter Ebene mit der Bezeichnung COMPUTER. Jeder dieser Knoten in der zweiten Ebene steht für einen einzelnen Datensatz in unserer XML-Datei. Darum beginnt unsere selectNodes-Abfrage wie folgt:
//HARDWARE/COMPUTER
An diesem Punkt treffen wir auf die folgende Konstruktion:
[@os='Windows XP']
Dieser Teil der Abfrage ähnelt einer WHERE-Klausel in einer SQL-Standardabfrage. Mit SQL würden wir eine ähnlich aufgebaute Datenbankabfrage verwenden, um eine Liste aller Computer abzurufen, auf denen das Windows XP-Betriebssystem ausgeführt wird:
SELECT Name FROM Hardware
    WHERE OS = 'Windows XP'
Mit der selectNodes-Methode gehen wir ähnlich vor: Wir verlangen eine Liste aller Computer, bei denen das os-Attribut (@os) den Wert „Windows XP“ aufweist. Um anzuzeigen, dass dies eine WHERE-Klausel ist, schließen wir die gesamte Klausel in eckige Klammern ein.
Hinweis Dieser Abfragetyp wird als XPath-Abfrage bezeichnet. Weitere Informationen zu XPath finden Sie unter msdn.microsoft.com/library/ms256115.aspx.
Wie schon gesagt: Es ist zwar ein bisschen merkwürdig, aber es funktioniert. Was ist, wenn wir eine Liste aller Computer abrufen möchten, die zur Finanzabteilung gehören? Das ist keine große Sache. Unser Aufruf von selectNodes wäre dann wie folgt aufgebaut:
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER" & _
   "[@department='Finance']")
Wieder ist unsere WHERE-Klausel in eckige Klammern eingeschlossen, wir leiten den Attributnamen („department“) mit dem At-Zeichen (@) ein, und dann geben wir den Wert an, für den wir uns interessieren.
Ganz einfach, oder?
Sobald wir die selectNodes-Methode aufgerufen haben, können wir die Computernamen zurückgeben, indem wir einfach die Reihe der zurückgegebenen Werte per Schleife durchgehen und dann die Text-Eigenschaft zurückgeben, so wie hier:
For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
Welche Art von Informationen können wir dann erwarten? Ehrlich gesagt, können wir zu Recht mit den folgenden Informationen rechnen:
atl-ws-001
atl-ws-002
atl-ws-007
atl-ws-009
Anders gesagt, werden die Namen aller Computer zurückgegeben, auf denen immer noch Windows XP ausgeführt wird.
Im Übrigen können Sie nicht nur den Computernamen zurückgeben lassen. Der Computername ist der „Standardwert“ für jeden Knoten, und genau diesen Wert bekommen wir zurück, wenn wir auf die Text-Eigenschaft verweisen.
Alternativ könnten wir die gesuchten Attributwerte exakt angeben. Betrachten Sie beispielsweise diese überarbeitete For Each-Schleife:
For Each objNode in colNodes
    Wscript.Echo objNode.Text
    Wscript.Echo objNode.Attributes. _
      getNamedItem("department").Text
    Wscript.Echo
Next
Wie Sie sehen, geben wir in dieser Schleife immer noch den Wert der Text-Eigenschaft zurück, aber wir haben auch die folgende Codezeile eingefügt:
Wscript.Echo objNode.Attributes. _
  getNamedItem("department").Text
In diesem Fall rufen wir den Wert des department-Attributs mit der getNamedItem-Methode ab, und anschließend geben wir die Text-Eigenschaft für dieses Attribut zurück. So können wir festlegen, welche Attributwerte wir auf dem Bildschirm anzeigen lassen möchten (und welche nicht). (Beachten Sie auch, dass wir den Wscript.Echo-Befehl eingefügt haben, mit dem eine Leerzeile zwischen den Datensätzen eingefügt wird.) Wenn wir dieses Skript ausführen, sollten wir das folgende Ergebnis erhalten:
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources
Und ja, Sie können auch komplexere Abfragen schreiben, wenn Sie möchten. Angenommen, Sie möchten beispielsweise eine Liste aller Computer abrufen, auf denen entweder Windows XP oder Windows Vista ausgeführt wird. In SQL würden Sie hierzu eine OR-Abfrage schreiben. Merken Sie was? Sie gehen hier genau so vor wie beim Abfragen einer XML-Datei:
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' or " & _
     "@os='Windows Vista']")
Sehen Sie, was hier geschehen ist? Innerhalb von nur zwei eckigen Klammern haben wir zwei Kriterien angegeben: @os='Windows XP' or @os='Windows Vista'. Mehr müssen Sie nicht tun, und schon erhalten Sie einen Bericht wie in Abbildung 3.
Abbildung 3 Ergebnis der OR-Abfrage
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-004
IT

atl-ws-005
Human Resources

atl-ws-006
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources

atl-ws-010
Sales
Wenn Sie die XML-Datei überprüfen, werden Sie feststellen, dass die Computer, auf denen Windows XP oder Windows Vista ausgeführt wird, in der Ausgabe aufgeführt werden, Computer mit Windows Server 2003 oder Windows Server 2008 dagegen nicht. Das sollen sie ja auch nicht.
Sie haben eine Frage? Sie möchten eine stärker eingeschränkte Abfrage schreiben, mit der nur Computer zurückgegeben werden, auf denen Windows XP ausgeführt wird und die zur Finanzabteilung gehören? Wie Sie sich vielleicht schon denken können, ist das ganz einfach: Hierzu müssen Sie nur eine AND-Abfrage wie die folgende schreiben:
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' and " & _
     "@department='Finance']")
Damit wird das folgende Dataset zurückgegeben:
atl-ws-002
Finance
Warum nur ein Element in unserem Bericht? Ganz genau: weil die Finanzabteilung nur einen einzigen Computer besitzt, auf dem Windows XP ausgeführt wird.
Wir hoffen, dass wir Ihnen helfen konnten, diese spezielle Art von XML-Dateien zu bewältigen. Wenn irgendwann einmal eine weitere Art von XLM-Dateien auftauchen sollte, dann viel Glück damit.
Wir haben den Artikel dieses Monats mit einem berühmten Ausspruch begonnen, und deshalb finden wir es passend, den Artikel auch in dieser Weise zu beenden. Wir schließen also mit den Worten von Kaiser Wilhelm II., die wir Scripting Guys in allen Ehren halten: „Ich verzichte hierdurch für alle Zukunft auf die Rechte an der Krone Preußens und die damit verbundenen Rechte an der deutschen Kaiserkrone.“
Der Scripting Perplexer von Dr. Scripto
Die monatliche Herausforderung, die nicht nur Ihr Talent zum Rätsellösen testet, sondern auch Ihre Skriptingfähigkeiten.

Oktober 2008: VBScript-Rätsel
Tragen Sie in jede Zeile die Bezeichnung einer VBScript-Funktion ein. Die Buchstaben in den blauen Quadraten bilden die Bezeichnung einer weiteren Funktion.

Antwort:
Der Scripting Perplexer von Dr. Scripto
Antwort: Oktober 2008: VBScript-Rätsel

Die Scripting Guys – Greg Stemp und Jean Ross – arbeiten für Microsoft.


Die Desktopdateien Anpassen der Windows-Bereitstellungsdienste
Wes Miller

Inhalt
Ersetzen des Vorhandenen
Betrachtung des Stapels
Netzwerkstartprogramm
WDS PXE-Anbieter
TFTP-Daemon
Startkonfigurationsdatenspeicher
Windows PE
Transportserver
Benutzerdefinierter Multicast
Zusammenfassung
Drei Monate lang habe ich mich mit den Windows-Bereitstellungsdiensten (Windows Deployment Services, WDS) beschäftigt. Dabei ging es um ihren Ursprung, gefolgt von einem Überblick, gefolgt von einer näheren Betrachtung einiger Themen für Fortgeschrittene wie WDSUtil und Multicasting. In diesem letzten Artikel der Reihe werden wir uns damit befassen, wo und wie Sie WDS anpassen und konfigurieren können, um die Anforderungen Ihrer Organisation zu erfüllen. Die meisten Microsoft-Tools sind für eine gewisse Konfigurierbarkeit ausgelegt. Aber erst wenn es um den tatsächlichen Einsatz geht, werden Sie feststellen, ob die Tools Ihren Anforderungen entsprechen oder ob sie für die Arbeit in Ihren Szenarios optimiert werden müssen, was wahrscheinlich häufiger der Fall ist.

Ersetzen des Vorhandenen
Eine Frage wurde mir von Lesern in letzter Zeit häufig gestellt: „Ich verfüge über x (eine vorhandene Bereitstellungstechnologie). Wird WDS bei mir funktionieren, und sind die Features mit denen von x vergleichbar?“ Aufgrund der veralteten automatisierten Bereitstellungsdienste (Automated Deployment Services, ADS) ist Folgendes von besonderem Interesse: „Wie kann ich eine hochvolumige, schnelle Bereitstellung oder erneute Bereitstellung von Servern durchführen? Erledigt WDS das für mich?“
Obwohl WDS nicht als gleichwertiger Ersatz für ADS geschaffen wurde und einige Hauptkomponenten fehlen, sodass WDS nicht als wirklicher Ersatz betrachtet werden kann, können Sie WDS mit ein wenig Arbeit so anpassen, dass ADS dadurch ersetzt werden kann. Wenn ein Aspekt von WDS für Sie in der vorliegenden Form nicht funktioniert, werden Sie feststellen, dass sich viele Komponenten mit einem unterschiedlichen Grad an Komplexität und technischem Aufwand ersetzen lassen. Im Folgenden wird die Bereitstellung über WDS erläutert. Es werden die Teile untersucht, die Sie möglicherweise anpassen möchten, und Sie erfahren, wie Sie dies tun können.

Betrachtung des Stapels
Abbildung 1 zeigt die Komponenten im WDS-Bereitstellungsprozess. Alle diese Schritte können bis zu einem gewissen Grad angepasst werden. Ich haben die einzelnen Schritte farblich gekennzeichnet, wodurch meiner Meinung nach die Komplexität (und damit die erforderliche Erfahrung im Entwickeln) für das Ersetzen oder Anpassen dargestellt wird. Je dunkler der blaue Farbton ist, desto schwieriger ist das Anpassen des jeweiligen Schritts.
Abbildung 1 Komplexität der Anpassung von WDS
Wie schwierig das Anpassen der einzelnen Schritte tatsächlich ist, hängt selbstverständlich sowohl von den Fähigkeiten Ihres Team (Entwicklung oder Skripting) als auch von Ihrem Verständnis von WDS, Windows Imaging-Format (WIM), Active Directory oder anderen Technologien ab, die Sie integrieren möchten, wie z. B. SQL oder ADSI. Wir wollen alle diese Schritte untersuchen und überlegen, wie sie angepasst werden könnten und welche Methoden Sie dazu verwenden würden.

Netzwerkstartprogramm
Ein benutzerdefiniertes Netzwerkstartprogramm (Network Boot Program, NBP) zum Ersetzen des bei WDS bereitgestellten müssen Sie wahrscheinlich nicht erstellen, aber die Möglichkeit dazu besteht. WDS enthält NBPs zur Verwendung mit kopflosen Systemen (gewöhnlich Server) oder Systemen, bei denen Sie zur Eingabe von F12 und so weiter auffordern können oder nicht. Diese NBPs können entweder mithilfe von WDSUtil in Active Directory vorbereitet werden, oder Sie können Startrom.com durch das NBP ersetzen, das Sie für alle Systeme verwenden möchten, die nicht vorbereitet sind (wenn beispielsweise alle Ihre Systeme kopflos sind oder wenn Sie nie zur Eingabe von F12 auffordern möchten).
Leider gibt es nicht viel Dokumentation zum Erstellen Ihres eigenen NBP (einige Informationen finden Sie unter msdn.microsoft.com/library/bb870970.aspx). Ein NBP ist eine sehr kleine, ausführbare 16-Bit-Datei mit starken Einschränkungen, für die ganz bestimmte Programmierfähigkeiten erforderlich sind. Ich empfehle gewöhnlich die Verwendung der vorhandenen NBPs, es sei denn, Sie versuchen, eine ganz bestimmte Anforderung zu erfüllen und verfügen über ein Entwicklungsteam mit den entsprechenden Fähigkeiten.

WDS PXE-Anbieter
Im Hinblick auf die Remoteinstallationsdienste (Remote Installation Services, RIS) hörten wir von Kunden oft, dass sie lieber einen anderen Datenspeicher als Active Directory für Clientsysteminformationen verwenden würden. Am häufigsten wurde SQL Server genannt. Bei WDS enthält der Entwurf eine austauschbare Infrastruktur für PXE-Anbieter (Pre-Boot eXecution Environment). Dies bedeutet, dass Sie bei der Entwicklungsarbeit einen anderen Sicherungsspeicher neben Active Directory für PXE-Informationen verwenden können.
WDS verfügt über einen eigenen Anbieter, der Active Directory verwendet. System Center Configuration Manager (SCCM) ist jetzt auch mit WDS verknüpft und implementiert einen eigenen Anbieter. Dokumentationen zum Schreiben eines eigenen Anbieters sind kaum vorhanden, und es gibt nicht viel Beispielcode (obwohl das Windows SDK etwas Dokumentation und einige Beispiele bietet). Diese Aufgabe erfordert also einiges. Wenn Sie für diesen Aspekt des Startvorgangs keine sehr spezifischen Anforderungen haben, empfehle ich auch hier wieder, keinen benutzerdefinierten PXE-Anbieter zu schreiben.

TFTP-Daemon
Manchmal haben Kunden in ihren eigenen Trivial File Transfer-Protokoll-Daemon (TFTPD) investiert, bevor es WDS gab. Da PXE-Server nicht gut zusammenarbeiten, bedeutet dies oft, sich für nur einen zu entscheiden.
Meiner Erfahrung nach bedeutet dies zumeist, einen vorhandenen, in der Regel Linux-basierten TFTPD zu verwenden und ihn dazu zu bringen, andere Betriebssysteme zu starten. Mit den ursprünglich verwendeten Infrastruktur-RIS war dies nicht möglich. Aber als der RAMDisk-Start zum Standard wurde, war dies möglich, und es ist mithilfe der WDS-basierten Startabbilder noch immer möglich.
Eines gilt es dabei zu bedenken: Es ist, was Microsoft betrifft, ein technisch nicht unterstützter Bereich, der sicherlich Probleme verursachen kann, die schwierig zu diagnostizieren sind. Außerdem könnte die Leistung nicht so gut sein, zumal der TFTPD in WDS verbessert wurde. Im Idealfall empfehle ich die Verwendung des vorhandenen WDS TFTPD. Versuchen Sie auch, PXE-Timeouts, Pre-Staging und/oder Netzwerkränder zu verwenden, um zu definieren, welche Clients über welchen PXE-Server starten, statt zu versuchen, einen vorhandenen Server anzupassen.

Startkonfigurationsdatenspeicher
Mit RIS war es nie möglich, auf der Startebene anzugeben, was gestartet werden sollte. Sie mussten immer den OS Chooser verwenden und eine Option auswählen (egal, ob es sich um das Setup, Windows PE (Windows Preinstallation Environment) oder etwas ganz anderes handelte). Da WDS ein vollständiges Ladeprogramm für den Netzwerkstart verwendet, wird auch die Anpassung des BCD-Speichers (Boot Configuration Data, Startkonfigurationsdaten), der für Clients bereitgestellt wird, unterstützt. Die Standard-BCD für jede Architektur befinden sich unter RemoteInstall\Boot\<arch>\Default.bcd, wobei <arch> die jeweilige Architektur des Systems ist, das gestartet wird.
Sie können diese BCD für jeden Client anpassen, und der Client verwendet sie zum Starten. Sie könnten beispielsweise einen BCD-Eintrag zum Starten des Setup einrichten, einen anderen zum Ausführen von Windows Recovery Environment (WinRE) und einen weiteren zum Ausführen eines Speichertests. Oder Sie könnten einen vollautomatisierten Setupeintrag als Standard und einen manuellen (oder eine benutzerdefinierte Setupfunktionalität) als vom Benutzer auswählbare Option verwenden. (Weitere Informationen finden Sie in dem Artikel „Bearbeiten des BCD-Speichers mittels Bcdedit“ unter go.microsoft.com/fwlink/?LinkId=115267.)

Der größte Teil der Arbeit von WDS findet natürlich in Windows PE statt. Das Optimieren von Windows PE zum Erfüllen Ihrer Anforderungen kann daher ein Schwerpunkt für ein benutzerdefiniertes Verfahren sein. WDS bietet als Standard eine standardmäßige Vorlage für das Setup, die die vollständige Setupfunktionalität umfasst. Bisweilen funktioniert dies aufgrund der Ihrer Bereitstellungsanforderungen nicht. In diesem Fall können Sie Ihr eigenes Windows PE-Startabbild erstellen. Beginnen wir ganz am Anfang.
Neben der Verwendung der BCD zum Anzeigen, welches Abbild verwendet werden soll, können Sie auch das Abbild angeben, indem Sie das Computerkontoobjekt (Machine Account Object, MAO) für einen Computer in Active Directory anpassen. In RIS speicherte ein bestimmtes MAO-Attribut jedes Element (welche Startrom- und Unattend-Datei (SIF) verwendet werden sollte). Bei WDS sind diese als Name/Wert-Paare unter dem Eintrag „netBootMirrorDataFile“ gespeichert. Das von einem bestimmten Computer zu verwendende Startabbild und die Unattend-Datei sind in diesem Eintrag gespeichert. Die Form der Einträge ist eine durch Semikolons getrennte Liste von Name/Wert-Paaren. Die Einträge zum Ändern des Startabbilds und der Unattend-Datei sind BootImage bzw. UnattendFilePath.
Selbstverständlich könnten Sie die vorhandene Setupfunktionalität ganz entfernen und Ihre eigene erstellen. Vielleicht benötigen Sie mehr Konfigurierbarkeit, mehr Automatisierung oder einen von SQL Server automatisierten Build. Vielleicht möchten Sie es wie anfänglich einige Kunden bei RIS und Windows PE machen und Ihr eigenes Front-End für das Setup erstellen. Bei den Hauptaufgaben, die unabhängig von der Setupfunktionalität durchzuführen sind, handelt es sich um folgende:
  • Ausfindigmachen aller computer- oder benutzerspezifischen Informationen. Diese Informationen sind beispielsweise über Benutzereingaben oder SQL Server oder eine Textdatei erhältlich.
  • Kopieren und Anwenden eines Setupabbilds auf das Clientsystem. Diese Aufgabe kann durch die direkte Verwendung des Setup durchgeführt werden, wobei ImageX zum Anwenden eines Abbilds aus einer Netzwerkfreigabe oder über Multicast verwendet wird (kopieren Sie einfach das Abbild, und wenden Sie es über ImageX an).
  • Stellen Sie eine Unattend-Datei bereit (in Abhängigkeit von der verwendeten Windows-Version beispielsweise Unattend.xml oder sysprep.inf), um das Setup abzuschließen.
  • Automatisieren Sie alle Migrationsschritte, die nach dem Setup durchgeführt werden sollen (oder alle Schritte zum Anwenden von Rollen im Fall von Windows Server 2008).
ADS hat das Konzept von Tasksequenzen initiiert, das das Zuweisen wiederholbarer Schritte zu einem oder mehreren Computern ermöglicht. Da ADS nicht zur Verwendung mit Windows XP entworfen wurde bzw. unterstützt wird, konnte es nicht zum Bereitstellen des Betriebssystems verwendet werden. Aber bei ADS-Tasksequenzen handelt es sich im Grunde nur um strukturierte Skripts, und Sie können dieselben Schritte mithilfe eines benutzerdefinierten Installationsvorgangs durchführen.
Ich bin bereits seit einiger Zeit Fan von Microsoft SQL Server (seit der Veröffentlichung von SQL Server 6.5), sodass ich eine solche Struktur instinktiv mithilfe von SQL erstelle. Selbstverständlich müssen Sie dazu Ihrem Windows PE-Build die SQL-Funktionalität hinzufügen. Darüber hinaus könnten Sie Ihre eigene grafische Benutzeroberfläche (eine HTML-Anwendung (HTA) oder eine kompilierte ausführbare Datei) schreiben oder Windows Script Host (WSH) verwenden, um eine minimalistische Setupfunktionalität nur über die Befehlszeile zu ermöglichen. HTA oder WSH müssten Windows PE ebenfalls hinzugefügt werden, damit sie verwendet werden können.
Die Komplexität beim Entwerfen Ihrer eigenen Setupfunktionalität hängt ganz von Ihren Fähigkeiten und Ihrer Vorstellungskraft ab. Ich habe recht elegante Systeme gesehen, die nur mithilfe von SQL und WSH oder HTA definiert wurden – Fähigkeiten, die sich relativ leicht erlernen lassen. Es ist jedoch sehr wichtig, an die Einschränkungen zu denken, die ich in früheren Artikeln erwähnt habe:
  • Windows PE verfügt über kein WOW-Subsystem (Windows on Windows), sodass für jede Architektur, die Sie unterstützen möchten, jeweils eine Kompilierung durchgeführt werden muss.
  • Sie können Visual Basic 6.0 nicht verwenden, wenn die Bereitstellung über x64 oder IA64 Windows PE erfolgen muss.
  • Sie können Visual Studio 2005 oder 2008 verwenden, um Anwendungen zu erstellen, aber Sie müssen eine nicht verwaltete Visual C++-Anwendung erstellen, da unter Windows PE kein Microsoft .NET Framework (egal, um welche Version es sich handelt) unterstützt wird.
  • Ohne .NET Framework kann auch Windows PowerShell nicht für die Automatisierung verwendet werden.
Sie können natürlich auch ein Drittanbieterdienstprogramm zum Erstellen von Abbildern über WDS verwenden, wenn Sie bereit sind, Ihre eigene Setupfunktionalität zu schreiben. Obwohl ich der Meinung bin, dass das WIM-Format und ImageX für die meisten Bereitstellungsszenarios ausreichen, könnte es bestimmte Anforderungen geben, die Ihr vorhandenes Abbilderstellungstool für Sie erfüllt.
Ebenso ist für bestimmte Szenarios eine benutzerdefinierte Partitionierung erforderlich. Möglicherweise stellen Sie Windows Vista mit BitLocker bereit, oder Sie erstellen Windows XP-Systeme und speichern Profildaten auf einem zweiten Volume, oder vielleicht stellen Sie ein Windows Server-System bereit und möchten ein separates Volume auf demselben Datenträger für die Protokollierung erstellen. Für alle diese Szenarios ist die Automatisierung von DiskPart erforderlich, die wie in früheren Versionen durch das Hinzufügen eines Skripts (in beliebigem Dateiformat) zu DiskPart erfolgt, das die Befehle enthält, die ausgeführt werden sollen, und mit „exit“ endet, um DiskPart zu beenden.
Das Erstellen einer eigenen Setupfunktionalität ist keine einfache Aufgabe, da Sie im Grunde die Setupdatei neu erstellen (oder zumindest ihre Funktionalität spiegeln), und dabei muss einiges entworfen und erstellt werden. Aber im Prinzip geht es darum, wie viel Funktionalität Sie standardmäßig in Ihren Build aufnehmen möchten und worin er erstellt wird (HTA oder WSH oder eine kompilierte Programmiersprache).

Transportserver
Wenn Sie nicht den größten Teil der standardmäßig im Lieferumfang enthaltenen Funktionen von WDS (wie z. B. Active Directory) verwenden oder Ihre eigene vollständige benutzerdefinierte Lösung erstellen, könnte der Transportserver Ihre Anforderungen erfüllen, ohne unerwünschte Anforderungen zu enthalten. Die Tabelle in Abbildung 2 (entnommen aus dem Artikel „Verwenden des Transportservers“ unter go.microsoft.com/fwlink/?LinkID=115298) zeigt, was als Teil der WDS-Transportserverrolle enthalten ist.
Abbildung 2 Bereitstellungsserver und Transportserver
 | Bereitstellungsserver | Transportserver
Serveranforderungen | Erfordert Active Directory-Domänendienste (ADDS), Dynamic Host Configuration-Protokoll (DHCP) und Dynamic Name Services (DNS) in der Umgebung. | Erfordert keine anderen Server in der Umgebung.
PXE | Unterstützt PXE-Start mit dem Standard-PXE-Anbieter. | Ein PXE-Anbieter ist nicht installiert, sodass ein benutzerdefinierter PXE-Anbieter erstellt werden muss.
Abbildserver | Enthält den Windows-Bereitstellungsdienste-Abbildserver. | Enthält nicht den Windows-Bereitstellungsdienste-Abbildserver.
Übertragungsmethode | Ermöglicht sowohl Unicasting als auch Multicasting. | Ermöglicht nur Multicasting.
Verwaltungstools | Wird entweder mit dem Windows-Bereitstellungsdienste-MMC-Snap-In oder dem WDSUTIL-Befehlszeilentool verwaltet. | Wird nur vom WDSUTIL-Befehlszeilentool verwaltet.
Anwendung auf dem Clientcomputer | Verwendet den Windows-Bereitstellungsdienste-Client (wobei es sich im Grunde um Setup.exe und unterstützende Dateien handelt), Wdsmcast.exe (im Windows AIK enthalten) oder eine benutzerdefinierte Multicastanwendung. | Verwendet nur Wdsmcast.exe oder eine benutzerdefinierte Anwendung.
Wenn ich sage, dass das Implementieren des Transportservers kompliziert ist, meine ich damit nicht, dass die Rolle an sich schwierig ist. Sie lässt sich problemlos bereitstellen (siehe Abbildung 3). Es ist die benutzerdefinierte Setupimplementierung um den Transportserver herum, die aufwändig ist. Bei effektiver Verwendung der Transportserverrolle wird der größte Teil der Benutzerfreundlichkeit entfernt, die in WDS als Rolle integriert ist.
Abbildung 3 Transportserver kann für benutzerdefinierte Bereitstellungsszenarios nützlich sein (zum Vergrößern auf das Bild klicken)

Benutzerdefinierter Multicast
Egal, ob Sie die Transportserverrolle verwenden oder nicht (aber besonders dann, wenn sie verwendet wird), gibt es ein gutes Argument für die Verwendung von Multicast, wenn Sie mehrere Systeme bereitstellen. ADS verfügte über ein sehr leistungsfähiges Multicastfeature, das Sie mithilfe von WDS mit Multicast duplizieren können. WDS verfügt selbst über Multicast, aber wenn Sie Ihre eigene benutzerdefinierte Lösung erstellen, können Sie Multicast mithilfe von WDSMCast nutzen, wie ich im letzten Monat erwähnt habe (siehe Abbildung 4). Wie Sie wissen, müssen Sie die bereitzustellenden Abbilddateien übertragen und dann anwenden. Gewöhnlich bedeutet dies, dass Sie ausreichenden lokalen Speicherplatz für das zu speichernde und dann anzuwendende Abbild benötigen.
Abbildung 4 Ausführen von WDSMCast (zum Vergrößern auf das Bild klicken)

Zusammenfassung
Für sich allein verwendet, ist WDS ziemlich leistungsfähig, was für viele Organisationen zum Erfüllen ihrer Anforderungen wahrscheinlich ausreicht. Wenn Sie aber Ihre eigene Lösung erstellen möchten, die über die Grenzen von WDS hinausgeht, ist dies durchaus möglich. Grenzen ergeben sich allein aus Ihrer Vorstellungskraft, Ihrem Zeitplan und Ihren Fähigkeiten.

Wes Miller ist Senior Technical Product Manager bei CoreTrace (CoreTrace.com) in Austin, Texas. Zuvor war er bei Winternals Software und als Programmmanager bei Microsoft tätig. Sie können Wes Miller unter technet@getwired.com erreichen.


Sicherheit auf dem Prüfstand Neubetrachtung der 10 unveränderlichen Gesetze zur Sicherheit, Teil 1
Jesper M. Johansson

Im Jahr 2000 veröffentlichte Scott Culp eine Abhandlung mit dem Titel „10 unveränderliche Gesetze zur Sicherheit“. Es ist eine der besten Abhandlungen zum Thema Sicherheit, die ich je gelesen habe. Die Informationen, die er vorstellte, sind noch immer Grundlage für alle Arbeiten im Bereich der Informationssicherheit, und ich empfehle Ihnen, den Artikel zu lesen (und auszudrucken), wenn Sie dies nicht bereits getan haben. Sie finden ihn unter microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx.
Die Abhandlung rief unterschiedliche Reaktionen hervor. Einige meinten sarkastisch, dass Microsoft damit vermied, Fehler zu beheben, die von vielen als ernste Probleme betrachtet wurden. Andere betrachteten den Artikel als ein fundamentales Dokument zum Thema Sicherheit und haben ihn aufgrund seiner enormen Wichtigkeit nach Belieben plagiiert. Einige meiner Lieblingsreaktionen sind jedoch jene, in denen die Leser dazu angeregt wurden, ihre eigenen Listen zu erstellen, wie beispielsweise jene, die unter edgeblog.net/2006/10-new-immutable-laws-of-it-security zu finden ist.
In den acht Jahren nach Veröffentlichung dieser Abhandlung ist im Bereich Sicherheit viel geschehen. Es wurde praktisch fast jeder bemerkenswerte Wurm veröffentlicht. Wir befinden uns nun in einem Informationskrieg (mit organisiertem Verbrechen, politischen Organisationen und so weiter). Verschiedene neue Wörter und Ausdrücke sind Teil des allgemeinen Wortschatzes geworden, beispielsweise Phishing, Pharming, Botnet, Spyware und siteübergreifende Anforderungsfälschung. Unter Windows werden einige der hochentwickeltsten Rootkits ausgeführt, die je erstellt wurden. Wir haben neue Betriebssystemversionen, die insbesondere Sicherheitsaspekte berücksichtigen, und andere Betriebssysteme, bei denen die Sicherheit zum größten Teil noch ignoriert wird.
Social Engineering hat sich zu einer großen Bedrohung entwickelt. Datenschutzverletzungen, wie beispielsweise durch einen großen Einzelhändler, der 94 Millionen Kreditkartennummern verfügbar machte, sind uns aus den Nachrichten vertraut (und dennoch wird weiterhin in solchen Geschäften eingekauft). Die Regierungen der USA und Großbritanniens haben es gemeinsam fertiggebracht, private Daten über einen beträchtlichen Prozentsatz der Einwohner der westlichen Welt einfach zu verlegen (und dennoch reichen die Betreffenden immer noch private Daten bei diesen Regierungen ein). Ein enormes Sicherheitstheater ist in unseren Leben – und an unseren Flughäfen – gang und gäbe.
Ich denke, es ist an der Zeit, noch einmal einen Blick auf die Gesetze zu werfen. Wenn wir alle Änderungen in den ersten Jahren dieses Jahrhunderts in Betracht ziehen, können wir dann immer noch behaupten, dass diese Gesetze unveränderlich sind? Wenn sie es sind (wenn sie die letzten 8 Jahre überdauert haben), können wir wahrscheinlich mit Sicherheit behaupten, dass sie auch die nächsten 10 überdauern werden.
In dieser dreiteiligen Reihe werde ich mich kritisch mit jedem der 10 Gesetze auseinandersetzen. In diesem Monat behandle ich die Gesetze 1 bis 3. Im Artikel des nächsten Monats geht es um die Gesetze 4 bis 7 und im letzten Artikel um die Gesetze 8 bis 10. Im dritten Teil werde ich außerdem zusätzliche Denkanstöße und Kommentare vorstellen, die angesichts der Dinge, die seit der ursprünglichen Veröffentlichung der Gesetze im Jahre 2000 geschehen sind, vernünftig scheinen.
Gesetz 1: Wenn ein Angreifer Sie überreden kann, sein Programm auf Ihrem Computer auszuführen, ist es nicht mehr Ihr Computer.
Dieses Gesetz erklärt im Prinzip, dass jede beliebige Software, die Sie auf Ihrem Computer ausführen, diesen Computer kontrollieren kann. Als die unveränderlichen Gesetze ursprünglich veröffentlicht wurden, waren die damaligen Microsoft-Betriebssysteme Windows 98, Windows Me und Windows NT 4.0. Heute haben wir Windows Vista und Windows Server 2008.
Unter Windows 98 und Windows Me hatte jede beliebige Software, die ausgeführt wurde, die vollständige Kontrolle über den Computer. Windows NT 4.0 hatte ein sehr stabiles zugrunde liegendes Sicherheitsmodell, aber wenn es als Administrator ausgeführt wurde, wurde sein Isolierungsmodell im Prinzip auf das von Windows 98 und Windows Me heruntergestuft. Es war möglich, Windows NT 4.0 als Nichtadministrator auszuführen, aber dies war ziemlich mühsam, und sehr wenige Organisationen hielten sich daran (Sie könnten wahrscheinlich die Gesamtzahl der Unternehmen, die sich daran hielten, abzählen, ohne Ihre Schuhe auszuziehen).
Angenommen, Sie haben Windows NT 4.0 als Nichtadministrator ausgeführt. Traf Gesetz 1 dann überhaupt zu, als es damals verfasst wurde? Die Antwort lautet „Ja“. Erstens wies Windows NT 4.0 eine große Zahl bedeutender Lücken auf. So gab es beispielsweise Berechtigungen, die strenger hätten sein können, insbesondere im Hinblick auf Kernelobjekte und in der Registrierung. Es gab auch viele Arten von Angriffen, die noch nicht entdeckt worden waren, die aber von Fachleuten erwartet wurden. So hatten Benutzer 1999 noch nicht erkannt, dass Prozesse, die mit erhöhten Rechten auf dem interaktiven Desktop ausgeführt wurden, den Computer beeinträchtigen konnten. Erst 2002 wurde dies allgemein bekannt, als Chris Paget sein Whitepaper zu Schmetterangriffen veröffentlichte („Exploiting the Win32 API“, seclists.org/bugtraq/2002/Aug/0102.html).
Hatte Microsoft diese Shatter-Angriffe vorhergesehen, als Gesetz 1 verfasst wurde? Nein, eigentlich nicht. Microsoft erkannte jedoch eine einfache Tatsache: Es gibt sehr wenige echte Sicherheitsbegrenzungen, die eine Anwendung, die auf einem Computer ausgeführt wird, daran hindern können, die Kontrolle über diesen Computer zu erlangen.
Windows Vista und Windows Server 2008 sind zwei Generationen von Windows NT 4.0 entfernt. Haben sie Gesetz 1 entkräftet? Gibt es andere Betriebssysteme, die dies tun? Das kommt ganz darauf an. Es gibt sicherlich stabilere Sicherheitsbegrenzungen in den neuen Betriebssystemen, und es gab damals im Jahr 2000 einige experimentelle Betriebssysteme, die richtige Sicherheitsbegrenzungen hatten. Es jedoch immer noch nur wenige dieser Begrenzungen. Die Codezugriffssicherheit in Microsoft .NET Framework beispielsweise ist eine Sicherheitsbegrenzung. Sie wurde so entworfen, dass sich Code, der innerhalb der Sandbox ausgeführt wird, nicht auf das zugrunde liegende Betriebssystem auswirkt.
Iframes in Internet Explorer bietet eine weitere Sicherheitsbegrenzung. Iframes wirken sich aber nicht auf den Zugriff auf das Betriebssystem selbst aus, sondern nur auf den Zugriff zwischen Teilen des Inhalts auf einer Webseite. Beim geschützten Modus in Internet Explorer, der in Abbildung 1 dargestellt ist, handelt es sich um eine Sicherheitsbegrenzung auf Betriebssystemebene. Ihr Zweck besteht darin, Code, der innerhalb eines Browsers ausgeführt wird, daran zu hindern, sich – ohne Benutzeraktion – auf das zugrunde liegende Betriebssystem auszuwirken. Es gibt einige andere, z. B. Standardbenutzerkonten, die ein Benutzerkonto daran hindern sollen, sich auf das zugrunde liegende Betriebssystem oder andere Benutzer auszuwirken.
Abbildung 1 Internet Explorer 7 verwendet eine Sicherheitsbegrenzung, die als geschützter Modus bezeichnet wird (zum Vergrößern auf das Bild klicken)
Es ist äußerst wichtig zu verstehen, was mit dem Begriff „Sicherheitsbegrenzung“ gemeint ist. Es handelt sich dabei nicht um eine unverletzliche Mauer, die garantiert undurchlässig ist und vollständige Isolierung bietet. Vielmehr ist damit gemeint, dass der Softwarehersteller, Microsoft beispielsweise, dafür verantwortlich ist, Verstöße gegen diese Begrenzung mithilfe eines Sicherheitspatches zu beheben. Software wird immer Fehler aufweisen, und wir werden zweifellos weitere Verstöße entdecken, die von den Softwareherstellern weiterhin gepatcht werden. Im Laufe der Zeit sollten sie ihre Software so verbessern, dass diese Sicherheitsrisiken im Vorfeld verhindert werden. Dies könnte als Bestätigung betrachtet werden, dass Gesetz 1 noch immer gilt.
Es gibt noch etwas Entscheidendes, das in Betracht gezogen werden muss. Ihnen dürfte vorhin der Begriff „ohne Benutzeraktion“ aufgefallen sein. Bei Gesetz 1 geht es eigentlich nicht um Mängel oder Sicherheitsrisiken in der Software. Vielmehr geht es um das menschliche Sicherheitsrisiko! Wichtig sind die Worte „Sie überreden kann“. Wenn ein Angreifer Sie überreden kann, sein Programm auszuführen, kann er Sie wahrscheinlich dazu überreden, dies in einem Kontext zu tun, der dem Programm erhöhte Berechtigungen gibt.
Selbst wenn Sie keine Administratorrechte haben, sind Sie nicht völlig geschützt. Sie haben als Standardbenutzer immer noch Zugriff auf viele interessante Informationen: Ihre Bankdateien, Liebesbriefe, Bilder, Videos und vertrauliche Unternehmensdaten. Alle diese Daten können für einen Angreifer möglicherweise interessant sein, und sie alle können ohne erhöhte Berechtigungen gelesen werden. Im Hinblick auf die Informationen, die Sie auf Ihrem Computer verwalten, wird durch die Ausführung eines schädlichen Programms alles, was sie tun, an den Angreifer übergeben. Wenn Sie Ihren Computer als die Daten definieren, die Sie auf Ihrem Computer verwalten, können Sie daher jegliche Diskussionen über Berechtigungen ignorieren und einfach zu dem Schluss kommen, dass Gesetz 1 noch immer gilt.
Auch ohne Haarspaltereien in Bezug auf die Definition Ihres Computers scheint dieses Gesetz die Zeiten überdauert zu haben. Bei Gesetz 1 geht es darum, dass Sie als Nutzer eines Computers die Verantwortung für die Software übernehmen müssen, die Sie auf diesem Computer ausführen. Wenn Sie einen schädlichen Treiber oder ein bösartiges Videocodec installieren, haben Sie die vollständige Kontrolle über diesen Computer an einen Kriminellen übergeben!
Obwohl Softwarehersteller viel tun können, um zufällige Gefährdungen zu verhindern (was im Grunde Sinn und Zweck von Sicherheitsbegrenzungen ist), wird das absichtliche Ausführen von Malware gewöhnlich alle diese Schutzmaßnahmen zunichte machen. Aus diesem Grund ist die Benutzererziehung neben der Sicherstellung, dass Benutzer nicht berechtigt sind, administrative Aufgaben durchzuführen, enorm wichtig. Daher können wir mit Sicherheit sagen, dass Gesetz 1 auch heute noch gilt, wobei wir aber die Definition Ihres Computers leicht ändern.
Gesetz 2: Wenn ein Angreifer das Betriebssystem auf Ihrem Computer verändern kann, ist es nicht mehr Ihr Computer.
Oberflächlich betrachtet, scheint dieses Gesetz recht unkompliziert. Wenn ein Angreifer das Betriebssystem auf Ihrem Computer verändern kann, können Sie dem Computer offensichtlich nicht mehr vertrauen. Aber was mit dem Begriff „Betriebssystem“ gemeint ist, hat sich mit der Entwicklung der IT-Anforderungen geändert. Vor vielen Jahren habe ich für die Blackwell Encyclopedia of Management (managementencyclopedia.com) eine Definition des Begriffs „Betriebssystem“ verfasst. Laut Definition verwaltet ein Betriebssystem den Zugriff auf Eingabe- und Ausgabegeräte, Zugriff auf Hardware und ähnliche Dinge. Ich habe nie eine Kopie der Enzyklopädie erhalten, und mein ursprünglicher Vorschlag ist verlorengegangen, aber ich habe mit Sicherheit nicht erwähnt, dass ein Betriebssystem Solitär, ein Tableteingabesystem und Videotranscoder enthält.
Aufgrund der zunehmend komplexeren Computertechnologie unterstützen Betriebssysteme heute viel mehr Funktionen. Das Ganze wird noch komplizierter, da OEMs oft ihre eigene Auswahl zusätzlicher Software hinzufügen, wobei diese zusätzliche Software sowohl nützlich als auch absolut schädlich sein kann. Ein Teil dieser zusätzlichen Software dupliziert Funktionen, die bereits in das Kernbetriebssystem integriert sind.
Eine Standardinstallation von Windows Server 2008 Enterprise Edition beispielsweise hat einen Speicherplatzbedarf von mehr als 5 Gigabyte. Windows Vista Ultimate Edition enthält über 58.000 Dateien und umfasst mehr als 10 Gigabyte. Dabei besteht das Betriebssystem aus mehr als nur aus Dateien. Es enthält viele tausend Konfigurationseinstellungen, und es gibt Daemons und Dienste.
Alle diese Dinge sind Teil des Betriebssystems. Es ist ein Sammelbegriff, der alle Dateien, alle Konfigurationseinstellungen und alle Dienste sowie alle Laufzeitobjekte (Semaphoren, Named Pipes, RPC-Endpunkte) umfasst, die von den Dateien und den Konfigurationseinstellungen erstellt werden. Sogar stark abstrakte Konstrukte wie die Systemzeit und bestimmten Datentypen, z. B. Ereignisprotokollinhalte, sollten als Teil des Betriebssystems betrachtet werden.
Trifft es angesichts des Wachstums und der Entwicklung des Betriebssystems wirklich zu, dass der Computer nicht mehr vertrauenswürdig ist, wenn eine dieser Dateien geändert wird? Die direkte Antwort lautet „Nein“. Windows Vista ist beispielsweise mit edlin.exe ausgestattet, dem alten MS-DOS-Zeileneditor. Ich kann es nicht mit Sicherheit sagen, aber ich würde darauf wetten, dass edlin.exe seit Veröffentlichung des Betriebssystems nur zweimal über alle installierten Kopien von Windows Vista hinweg aufgerufen wurde. Beide Aufrufe fanden vor ungefähr drei Minuten statt, als ich versuchte, mich an die Syntax zu erinnern. Wenn jemand edlin.exe oder eine andere Datei ändert, die niemand je verwendet, bedeutet dies wirklich, dass Ihr Computer nicht mehr Ihr Computer ist?
Edlin.exe ist ein unbestreitbar Teil des Betriebssystems, aber wenn die Datei nie ausgeführt wird, wie kann eine Änderung dann Ihren Computer beeinträchtigen? Die Antwort lautet natürlich, dass dies nicht geschehen wird. Das Ändern eines nie verwendeten Teils des Betriebssystems wird Ihren Computer nicht beeinträchtigen. Es gibt viele Teile des Betriebssystems, die nie verwendet werden.
Die indirekte Antwort lautet jedoch „Ja“. Sie können nicht nur betrachten, ob jemand eine Datei ausführt, wenn es darum geht, ob ihre Änderung zu einer Beeinträchtigung Ihres Computers führen könnte. Das Problem ist etwas komplizierter. Sehen Sie sich beispielsweise die Zugriffssteuerungsliste (access control list, ACL) für edlin.exe in Abbildung 2 an.
Abbildung 2 Die ACL für edlin.exe wirkt stark einschränkend (zum Vergrößern auf das Bild klicken)
Die ACL für edlin.exe wirkt stark einschränkend. Nur der TrustedInstaller-Dienst hat die Berechtigung, die ausführbare Datei zu ändern. Dies ist sehr wichtig: Es bedeutet, dass sich eine indirekte Auswirkung für einen Angreifer ergibt, der diese Datei auf Ihrem Computer ändert. Das Ändern von edlin.exe bedeutet, dass es nicht mehr Ihr Computer ist. Wesentlich ist hier die Tatsache, dass der böswillige Benutzer die Möglichkeit hat, edlin.exe zu ändern. Wenn der Angreifer diese Datei ändern kann, kann er jede beliebige Datei ändern, und das bedeutet, dass Sie auf dem Computer keiner Sache mehr vertrauen können.
Das Betriebssystem wird sich selbst schützen. Dienste sind vor nicht autorisierter Änderung geschützt. Konfigurationseinstellungen sind vor nicht autorisierter Änderung geschützt. Dateien auf dem Datenträger sind vor nicht autorisierter Änderung geschützt. Selbst die Semaphoren und RPC-Endpunkte, die vom Betriebssystem verwendet werden, sind vor nicht autorisierter Änderung geschützt. Wenn ein Angreifer irgendeines dieser geschützten Objekte ändern kann, kann er alle ändern und hat dies vermutlich bereits getan.
Dies ist ein wichtiger Punkt. Bei mehreren der unveränderlichen Gesetze ist es nicht die Handlung als solche, die dazu führt, dass Ihr Computer beeinträchtigt ist. Wichtig ist allein die Tatsache, dass jemand die Möglichkeit hat, etwas zu tun. Dieser Punkt darf nicht übersehen werden. Bei jedem Aspekt der Computersicherheit müssen Sie immer daran denken, dass die Fähigkeit oft weitaus wichtiger als die eigentliche Aktion ist.
Ist ein Computer, der für das Internet weit offen und monatelang ungepatcht ist, noch vertrauenswürdig? Nein. Dieser Computer muss als beeinträchtigt betrachtet werden. Sie können auf einem System, das möglicherweise beeinträchtigt wurde, keiner Sache vertrauen. (Ich habe dasselbe vor fünf Jahren in meinem Artikel „Hilfe! Mein Computer wurde gehackt. Was kann ich tun?“ geschrieben, der unter technet.microsoft.com/library/cc512587 verfügbar ist.) Wenn Sie es mit einem geschickten Gegner zu tun haben, zeigt ein beeinträchtigtes System möglicherweise keinerlei Anzeichen von Beeinträchtigung. Das System sieht u. U. völlig normal aus.
Fraglos trifft Gesetz 2 immer noch zu. Wenn ein Angreifer die Möglichkeit hat, irgendein geschütztes Objekt auf Ihrem Computer zu ändern, ist es nicht mehr Ihr Computer. Denken Sie daran, dass die Möglichkeit zum Ändern dieser Objekte wichtig ist, nicht die Tatsache, dass sie tatsächlich angegriffen wurden.
Gesetz 3: Wenn ein Angreifer uneingeschränkten physischen Zugriff auf Ihren Computer hat, ist es nicht mehr Ihr Computer.
Dieses Gesetz war im Jahr 2000 sehr wichtig. Vielen war nicht völlig bewusst, was bei physischem Zugriff auf ein System möglich ist. Selbst einige Regierungsbehörden, die es eigentlich besser wissen sollten, begriffen diesen grundlegenden Punkt nicht. Damals empfahlen Sicherheitsrichtlinien, die Option „Allow shut down without logon“ (Herunterfahren des Systems ohne Anmeldung zulassen) zu deaktivieren. Dadurch wird die Schaltfläche „Herunterfahren“ auf dem Anmeldebildschirm abgeblendet dargestellt. Dies beruhte auf der Theorie, dass sich der Benutzer zum Herunterfahren des Computers zuerst anmelden muss, sodass in einem Überwachungseintrag festgehalten wird, wer das System heruntergefahren hat.
Dies ist ein Fallbeispiel für fehlerhaftes Denken. Um über Zugriff auf die Schaltfläche „Herunterfahren“ auf dem Anmeldebildschirm zu verfügen, müssen Sie die Konsole vor sich haben. Wenn Sie an der Konsole sitzen und den Computer wirklich ausschalten wollen, können Sie dies normalerweise mithilfe der großen Taste vorn am Computer oder sogar mithilfe des Netzkabels tun. Das System ist abgeschaltet. Ein Überwachungsprotokoll ist nicht vorhanden.
Windows 2000 enthält eine Sicherheitseinstellung namens „Entfernen ohne vorherige Anmeldung erlauben“, und diese Option ist auch in Windows Vista immer noch verfügbar, wie Abbildung 3 zeigt. Es war dasselbe Prinzip. Um einen Laptop von seiner Dockingstation abzudocken, ist es erforderlich, sich zuerst beim System anzumelden.
Abbildung 3 Warum würden Sie nicht einfach den Computer und die Dockingstation stehlen? (zum Vergrößern auf das Bild klicken)
Der tatsächliche Sicherheitswert dieser Einstellung ist äußerst zweifelhaft. Ich denke, die Theorie dabei war folgende: Wenn jemand Zugang zum Laptop hat und ihn abdocken kann, könnte er ihn leicht stehlen. Ich selbst würde nie einen Laptop stehlen, aber wenn ich es wollte, würde mich diese Vorbeugemaßnahme nicht abschrecken. Ich würde wahrscheinlich einfach den Laptop zusammen mit der Dockingstation mitnehmen. Warum nicht auch gleich das Netzwerkkabel und das Netzkabel mitgehen lassen? Es ist eine absolut bedeutungslose Sicherheitsoptimierung!
Die Bedeutung des physischen Zugriffs wurde wirklich offensichtlich, als Petter Nordahl-Hagen seinen Offline NT Password & Registry Editor erstellte. Dabei handelte es sich einfach um eine Linux-Startdiskette mit einem experimentellen NTFS-Dateisystemtreiber, der Lese- und Schreibzugriff auf ein NTFS-Volume ermöglichte. Die Software auf der Startdiskette stellte die Registrierung auf dem lokalen Computer bereit und schrieb ein neues Kennwort für das Administratorkonto in die SAM-Struktur (Software Asset Management). Dazu waren lediglich physischer Zugriff auf das System und ein paar Minuten Zeit erforderlich.
Wegen Tools wie diesem wurde Gesetz 3 geschrieben. Tatsächlich wurde das Tool von Nordahl-Hagen in vielen Demos verwendet. Leider wurde dieser Punkt dem großen Publikum nie so recht bewusst. Ich habe das Tool persönlich in einigen Demos verwendet, gab dies aber auf, da ich genug hatte von Fragen wie: „Wie können wir dafür sorgen, dass unsere Benutzer solche Tools nicht kennen?“ oder „Was unternimmt Microsoft, um dieses Problem zu beheben?“ Ein erschreckend großer Anteil von Mitarbeitern in der IT-Branche wollte es einfach nicht akzeptieren oder verstehen, dass physischer Zugriff alles andere zunichte machen würde.
In dieser Umgebung war Gesetz 3 eine sehr wichtige Aussage. Die Kritiker fielen jedoch gnadenlos darüber her. Das Gesetz wurde als Versuch von Microsoft verlacht, das Beheben von Problemen zu vermeiden, die auch nur im Entferntesten an den physischen Zugriff gebunden sein könnten. Gesetz 3 wurde tatsächlich in mehreren Fällen verwendet, um Meldungen über Sicherheitsanfälligkeiten einschließlich des Offline NT Password & Registry Editor-Hack als bedeutungslos abzutun. Das Abblocken von Angreifern, die physischen Zugriff auf das System haben, ist allerdings wirklich nur auf eine Art und Weise möglich: Stellen Sie sicher, dass sie keinen Zugang haben.
Dort liegt möglicherweise der schwache Punkt von Gesetz 3. Seit die Gesetze geschrieben wurden, hat sich durch die Technologie zur vollständigen Datenträgerverschlüsselung eine mögliche Lösung ergeben. Mit vollständiger Datenträgerverschlüsselung, die richtiger als vollständige Volumeverschlüsselung bezeichnet wird, kann ein ganzes Volume (bei anderen Betriebssystemen als Partition bezeichnet) verschlüsselt werden. Wenn also das gesamte Startvolume (d. h. das Volume mit dem Betriebssystem) verschlüsselt ist, müssen wir uns die Frage stellen, ob Gesetz 3 noch immer gilt.
Die Antwort dürfte „sehr wahrscheinlich ja“ lauten. Zum einen müssen die Entschlüsselungsschlüssel irgendwo gespeichert werden. Der einfachste Speicherort für die Schlüssel und die Standardoption in BitLocker ist ein TPM-Chip (Trusted Platforms Module) auf dem Computer. Dadurch kann der Computer unbeaufsichtigt gestartet werden. Nachdem der Computer gestartet wurde, kann ein einfallsreicher und gut ausgestatteter Angreifer mit permanenter physischer Kontrolle über den Computer ihn auf vielfältige Weise angreifen. Da der Computer jetzt mit einem beliebigen Netzwerk verbunden werden kann, könnte es netzwerkbezogene Möglichkeiten für Angriffe auf das System geben.
Der Angreifer könnte beispielsweise mithilfe eines Geräts für den direkten Speicherzugriff (Direct Memory Access, DMA), wie z. B. einem USB-Flashlaufwerk, Lese- und Schreibvorgänge im Speicher durchführen. Wenn der Computer erst einmal ausgeführt wird, ist einem Angreifer mit physischem Zugriff auf diesen Computer alles möglich.
Wenn die Schlüssel nicht auf dem Computer selbst gespeichert werden, hängt der Erfolg des Angriffs davon ab, ob der Angreifer die Schlüssel erlangen oder erraten kann. Wenn ein PIN-Code zum Starten des Computers verwendet wird, kann der Angreifer den Code wahrscheinlich mit relativ wenig Mühe erraten. Wenn die Schlüssel auf einem separaten Hardwaregerät, z. B. auf einem USB-Flashlaufwerk oder einem Fob mit einem Einmalkennwort, gespeichert sind oder dort abgeleitet werden, muss der Angreifer Zugriff auf dieses separate Gerät haben. Es gibt sicherlich Möglichkeiten, sich diese Schlüssel zu verschaffen oder das Leben der Person, die darauf Zugriff hat, sehr unangenehm zu machen, wobei der erforderliche Aufwand jedoch etwas höher ist.
Sie könnten Gesetz 3 auch auf etwas andere Art interpretieren: „Falls ein Angreifer physischen Zugriff auf Ihren Computer hat, wurde der Computer wahrscheinlich gestohlen, und es ist daher unwahrscheinlich, dass Sie ihn zurückerhalten werden.“ Aus dieser Perspektive betrachtet, gehört der Computer Ihnen wirklich nicht mehr. Unter diesem Gesichtspunkt könnte es für den Angreifer bedeutungslos sein, ob er auf die Daten auf Ihrem Computer zugreifen kann oder nicht. Darum geht es jedoch im Gesetz 3 gar nicht. Vielmehr war damit gemeint, dass der Angreifer Zugriff auf die Daten auf Ihrem Computer und nicht nur auf den Computer selbst hatte.
Alles in allem Dinge gilt Gesetz 3 immer noch. Es stimmt, dass bestimmte Technologien heute viel dazu beitragen, viele Angreifer mit physischem Zugriff abzuwehren, und folglich die Anzahl der Angreifer minimieren, die auf Daten auf einem Computer mit implementierten Sicherheitsmaßnahmen zugreifen können. Abgesehen davon, hängt es immer von den Fähigkeiten des Angreifers ab, wie viel er tatsächlich erreichen kann, und neue Technologien wirken sich – in gewissem Maße – auf viele der 10 unveränderlichen Gesetze aus. Der physische Zugriff bietet aber immer Möglichkeiten zum Zugriff auf ein System, auch wenn sie komplexer sein mögen.
Bis jetzt erweisen sich die unveränderlichen Gesetze zur Sicherheit sowohl im Hinblick auf den technologischen Fortschritt als auch die Zeit als sehr stabil. Von den ersten drei Gesetzen steht das dritte am ehesten auf schwachen Füßen, aber auch dieses Gesetz gilt in einigen Fällen immer noch. Es ist jedoch das Gesetz, für das es die meisten leicht verfügbaren und stabilen Schutzmaßnahmen gibt. In den nächsten beiden Ausgaben des TechNet Magazins werde ich diese Diskussion fortsetzen und erörtern, ob die Gesetze 4 bis 10 immer noch unveränderlich sind.

Jesper M. Johansson ist Softwarearchitekt mit dem Schwerpunkt Sicherheitssoftware und schreibt redaktionelle Beiträge für das TechNet Magazin. Er hat seine Doktorarbeit zum Thema Management Information Systems geschrieben, verfügt über mehr als 20 Jahre Erfahrung auf dem Gebiet der Sicherheit und ist Microsoft MVP (Most Valuable Professional) im Bereich Unternehmenssicherheit. Sein aktuelles Buch ist das „Windows Server 2008 Security Resource Kit“.


Berichte aus der Praxis Farbbarcode mit hoher Kapazität
Gavin Jancke

Wir alle sind mit Barcodes so vertraut, dass wir sie oft nicht einmal bemerken. Sie sind im Alltag allgegenwärtig – auf Lebensmittelverpackungen bis hin zu Adressetiketten. Die ursprünglichen 1D-Barcodes, die 1974 in der Einzelhandelsbranche auftauchten, bestanden aus senkrechten Strichen unterschiedlicher Breite und speicherten eine 12-stellige Zahl. Die Barcodes entwickelten sich mit zunehmender Rechenleistung, und gegen Ende der 80er Jahre wurden Schwarzweiß-2D-Barcodes (Matrixcodes) entwickelt, die die Datendichte von ein paar Zahlen auf einige hundert Bytes erhöhten.
2003 begann ich mit der Arbeit an einem fälschungssicheren, biometrischen Ausweis, wobei es sich um ein Projekt für Microsoft Research handelte. Ich musste nicht nur den kryptografischen Text wie Namen und Alter speichern, sondern auch Fingerabdruck- oder Netzhautscanvorlagen. Um alle notwendigen Daten speichern zu können, hätte der existierende Schwarzweißbarcode größer als der Ausweis selbst sein müssen, sodass ein neuer Ansatz erforderlich war.
Ich musste festlegen, wie mehr als ein Bit an Informationen pro Symbol gespeichert werden konnten, was der Standard für Schwarzweiß-2D-Barcodes gewesen war. Durch die Verwendung von Farben statt Schwarz und Weiß konnte ich dies mithilfe von vier bzw. acht Farben auf zwei bis drei Bit an Daten erhöhen.
Ich experimentierte auch mit den Symbolformen, um festzustellen, ob sie dichter zusammengepackt werden konnten, ohne dass ihre Erfassung beim Scannen beeinträchtigt wurde. Anfänglich schienen Sechsecke eine gute Möglichkeit, aber die Formen verschmolzen miteinander, und der Computer konnte sie nicht deutlich genug wahrnehmen.
Schließlich entschied ich mich für Dreiecke, da sie sich in einem komprimierten Raum ordentlich schneiden, aber gleichzeitig ihre Identität als eindeutige Formen bewahren. Durch die Verwendung von Zeilen von Dreiecken in mehreren Farben konnte ich die Dichtheitsfunktion auf 3D erweitern.
Es galt viele Variable zu beachten. Eine der größten Herausforderungen bei der Arbeit mit Farbe ist die Abweichung in Druckspezifikationen und bei unterschiedlichen Beleuchtungsbedingungen. Obwohl Farbe für das menschliche Auge leicht erkennbar ist (zumindest für diejenigen, die nicht farbenblind sind), ist sie für einen Computer nicht so deutlich erkennbar.
Ich verwendete mehrere verschiedene Ansätze, um sicherzustellen, dass die Software die Farbe genau lesen konnte. Ich erstellte eine sehr kleine, fast nicht wahrnehmbare Palette innerhalb des Badcodes, die die Referenzfarben für die im eigentlichen Barcode vorhandenen Farben enthielt. Auf diese Weise wurde eine Kalibrierungsmethode bereitgestellt, die genau angab, wie beispielsweise ein bestimmtes Rot aussieht. Ich probierte auch komplexere Verfahren wie beispielsweise angepasste, einfache Farbclusteringalgorithmen aus, die die Farbbereichstheorie nutzen, um Farben in Sätzen zu kategorisieren. Beide Ansätze funktionieren gleichermaßen gut und ergänzen einander.
Eines meiner Ziele bei diesem Projekt bestand im Schreiben eines Programms, das Handys das Lesen von Barcodes ermöglichen würde. Bei Handys müssen Dinge wie schlechte Beleuchtung und nicht fokussierte Objektive mit fester Brennweite in Betracht gezogen werden. Eine weitere Herausforderung bestand darin, das gesamte Computersehvermögen auf ganzzahlbasierten, relativ langsamen Handy-CPUs umzusetzen, sodass das Team eine Theorie entwickeln musste, mit der der Barcode im Bild erkannt werden kann, wobei möglichst wenige Pixel berührt werden. Der Scan musste innerhalb eines Bereichs von Lesebedingungen arbeiten, von hellen, scharf eingestellten LCD-Monitoren bis hin zu verschwommenen physischen Drucken bei geringerer Beleuchtung.
Der fertige Algorithmus decodiert Barcodebilder in Echtzeit-Kameravideoframes schneller als die eigentliche Framerate (ungefähr 10 Millisekunden bei einer 200-MHz-CPU). In einem Bild beträgt die kleinste Zahl von Pixeln, die ein Barcode für die kleinste Datennutzlast verwenden kann, die immer noch erkannt wird, etwa 45 Pixel im Quadrat.
Es waren mehr als zwei Jahre Entwicklungsarbeit erforderlich, damit dies unter verschiedenen Bedingungen funktionierte. Diese Technologie wurde Drittanbietern kürzlich unter Lizenz zur Verfügung gestellt, und später in diesem Jahr wird es einige interessante Anwendungen geben.
Gavin Jancke, Director of Engineering für Microsoft Research, leitet die Advanced Development Group- und Web Experience-Teams. Zuvor war er als Product Support Engineer und Software Engineer für SQL Server tätig und war Mitglied des technischen Beraterstabs von Bill Gates.


Windows Confidential Arbeiten Sie härter, nicht intelligenter
Raymond Chen

Für Softwareentwickler besteht einer der großen Vorteile der Windows-Fehlerberichterstattung darin, dass sie reale Informationen dazu erhalten, welche Fehler in ihren Programmen auftreten. Diese Fehlerberichte sind für jeden Softwarehersteller verfügbar, der sich online unter winqual.microsoft.com registriert. Natürlich können Sie alle Arten von Tests in Ihren Testumgebungen ausführen, aber es gibt immer eine Lücke zwischen den Bedingungen in der Testumgebung und den realen Bedingungen. Dies kann zu Fehlern führen, die bei Ihren Tests nie auftreten, aber Ihre Kunden zur Verzweiflung bringen.
Vor einigen Jahren hat mir ein Programmierer, dem vom für die Zuverlässigkeit zuständigen Team seines Produkts eine Aufgabe übertragen wurde, eine interessante Geschichte erzählt. Das Team wollte die wichtigsten Gründe für Abstürze und Blockaden in einer bestimmten Komponente beseitigen. Nach einigen Verhandlungen einigten sich beide Parteien auf das Ziel, die Anzahl dieser Arten von Fehlern um den Faktor 2 zu reduzieren. Sie wollten Fehler beheben, die laut Windows-Fehlerberichterstattung für mindestens 50 Prozent der Abstürze und Blockaden in dieser Komponente verantwortlich waren.
Wir wissen alle, dass Fehler nicht gleichmäßig verteilt sind. Einige sind selten, andere treten häufig auf und wieder andere sind allgegenwärtig (relativ betrachtet). Der Entwicklungsprozess ist von Kompromissen geprägt: Angesichts begrenzter Ressourcen (Zeit, Geld und Personal) müssen Sie Ihre Ressourcen an den Stellen einsetzen, an denen sie die größte Wirkung haben. Da das Ziel lautete, die Anzahl der Abstürze und Blockaden zu verringern, bestand ein vernünftiger Ansatz darin, die von der Windows-Fehlerberichterstattung am häufigsten gemeldeten Fehler zu untersuchen, die zugrunde liegenden Ursachen zu verstehen und dann zu versuchen, diese häufig auftretenden Fehler zu beheben.
Die Windows-Fehlerberichterstattung bietet reale Informationen zu Programmfehlern (zum Vergrößern auf das Bild klicken)
Als der Programmierer die Fehlerdaten analysierte, wurde klar, dass mehr als 60 Prozent der Berichte auf fünf speziellen Abstürzen und Blockaden beruhten. Wenn der Programmierer die Programmfehler beheben könnte, die diese fünf Fehler verursachten, würde er die Anzahl der Abstürze und Blockaden um den Faktor 2,5 – deutlich über dem Zielfaktor von 2 – reduzieren.
Microsofts eigene Analyse der Windows-Fehlerberichterstattungsdaten zeigt, dass das Pareto-Prinzip eine erstaunlich gute Faustregel für Windows-Abstürze und -Blockaden ist: etwa 20 Prozent der Bugs verursachen 80 Prozent der Fehler. Dieselbe Studie führte zu einem noch überraschenderen Ergebnis: Nur 1 Prozent der Bugs verursacht 50 Prozent der Fehler. Nicht alle Programmfehler sind gleich, aber es ist wirklich eine Überraschung, wie hochgradig schief die Verteilung ist.
Nach der eingehenderen Untersuchung dieser fünf Fehler erkannte der Programmierer, dass ihnen allen dieselbe Ursache zugrunde lag. Die Abstürze und Blockaden waren nur verschiedene Erscheinungsformen desselben zugrunde liegenden Fehlers. Daher entwickelte und testete er eine Problembehebung und leitete in Zusammenarbeit mit den Mitarbeitern der Qualitätssicherungsabteilung die Schritte für die Aufnahme der Problembehebung in den nächsten Patch ein. Mit dieser einen Programmfehlerbehebung sank die theoretische Fehlerrate für die Komponente augenblicklich um den Faktor 2,5. Er hatte seine Aufgabe mit einer ziemlich einfachen Codefehlerbehebung erfüllt.
Als ich diese Geschichte hörte, war ich überrascht, dass die Fehlerverteilungskurve für die Komponente sogar noch steiler war als für Windows. Deutlich mehr als die Hälfte aller Abstürze und Blockaden wurde durch einen einzigen Programmfehler verursacht. Diese Art von Einblick in Ihren Code ist ohne die Daten, die von einem Dienst wie der Windows-Fehlerberichterstattung gesammelt werden, nicht möglich.
Man sollte meinen, dass das Zuverlässigkeitsteam hocherfreut war, sein Ziel so schnell erreicht zu haben. Das vereinbarte Ziel wurde in nur zwei Wochen mit einer einzigen Problembehebung übertroffen. Stattdessen war man aufgebracht.
„Das ist nicht akzeptabel – wir haben erwartet, dass es zwei Monate dauert. Das war zu einfach!“ Offensichtlich sollte der Programmierer härter und nicht intelligenter arbeiten.
Raymond Chen befasst sich auf seiner Website „The Old New Thing“ und in seinem gleichnamigen Buch mit der Geschichte von Windows und mit der Win32-Programmierung. Zwanzig Prozent seiner Kleidungsstücke sind für achtzig Prozent seiner Schmutzwäsche verantwortlich.