Die DesktopdateienBereitstellen von Windows in einer virtuellen Welt

Wes Miller

Die virtuelle Computertechnologie ist allgegenwärtig. Wenn Sie sie noch nicht nutzen, wird es jetzt Zeit. Die Virtualisierung verringert die Hardwareabhängigkeit, indem im Wesentlichen eine eigene Hardwareabstraktionsschicht erstellt wird und es Ihnen ermöglicht wird, ein oder mehrere Gastsysteme, z. B. Windows Server- oder Windows-Clientbetriebssysteme, zwischen Hostsystemen zu verschieben.

Natürlich unterscheidet sich die Virtualisierung insofern von der Emulation, als dass sie nicht den Prozessor des Gasts imitiert. Sie stellt einfach die Ressourcen des Hostsystems so dar, dass Gastsysteme auf sie zugreifen können. Daher sind Hostsysteme für Gäste generisch. Sie können im Allgemeinen einen virtuellen Gast vom System eines OEMs auf das System eines anderen OEMs verschieben, wobei die Hardware des Hosts in der Regel keine Rolle spielt. Es sind jedoch einige Punkte zu beachten. Wenn Sie beispielsweise einen Gast von Hardware mit einem Prozessor eines CPU-Herstellers wie AMD auf Hardware mit einem Prozessor eines anderen Herstellers wie Intel verschieben, könnten je nach der von Ihnen verwendeten Virtualisierungstechnologie Probleme auftreten. Dies beruht darauf, dass durch die virtuelle Computertechnologie lediglich Informationen zwischen Host und Gast übertragen werden und keine spezifische CPU für den Gast emuliert wird (wie dies beispielsweise der Fall ist, wenn Microsoft® Virtual PC auf einem PowerPC-basierten Macintosh-Legacycomputer ausgeführt wird).

Bei der Virtualisierung werden jedoch wichtige Hardwarekomponenten für den Gast emuliert. Dies beschränkt sich zumeist auf Netzwerk-, Video- (in der Regel ein stark eingeschränktes Gerät ohne hoch entwickelte emulierte GPU) und Massenspeichergeräte. Die Funktionsweise bei dieser Art von Verbund besteht darin, dass eine oder mehrere durch Software emulierte Geräte für den Gast dargestellt werden. Wenn Sie die Artikel dieser Rubrik bereits seit einer Weile lesen, werden Sie bemerkt haben, dass es sich dabei um die gleiche Liste von Geräten handelt, auf die auch Windows® PE abzielt. Bei der Virtualisierung sind dies die gleichen Arten von Geräten, die erforderlich sind, damit Windows wirklich funktioniert. Darüber hinaus müssen alle Virtualisierungstechnologien ein BIOS emulieren. Obwohl auch Extensible Firmware Interface (EFI) emuliert werden könnte, ist dies aufgrund der begrenzten Auswahl von EFI-basierten Betriebssystemen derzeit nur von eingeschränktem Nutzen. Diese Emulation ermöglicht das Starten von virtuellen Gästen. Das BIOS und jedes der Geräte emulieren ein tatsächliches Gerät in der Software und stellen dieses Gerät für Gäste dar. Dies bedeutet, dass die gleichen Treiber (nicht immer durch Windows bereitgestellt) erforderlich sind, die das tatsächliche Gerät erfordern würde. Dies ist ein wichtiges Konzept, das zu beachten ist.

Obwohl einige Virtualisierungstechnologien auch Schnittstellen zu USB- (oder USB 2.0-) Geräten ermöglichen, soll an dieser Stelle nicht auf die Einzelheiten dieser Technologien eingegangen werden. Abgesehen von den USB-Geräten, die entweder Treiber (Drucker, drahtlose USB-Netzwerkkarten usw.) oder bestimmte DirectX®-Unterstützung (bei den meisten Virtualisierungstechnologien in der Regel nicht vorhanden) erfordern, sollte kein großer Aufwand erforderlich sein, damit sie funktionieren. Beachten Sie, dass die Unterstützung für USB-Geräte oder andere nicht emulierte Geräte natürlich von der verwendeten Virtualisierungstechnologie abhängt. Sie sollten auf jeden Fall die Einschränkungen oder Nachteile des von Ihnen verwendeten Virtualisierungsprodukts kennen, bevor Sie versuchen, neue Geräte in Verbindung mit dieser Technologie zu verwenden.

Derzeit gibt es zwei Hauptanbieter von Virtualisierungstechnologie für Windows: Microsoft und VMware (vmware.com). Darüber hinaus gibt es weitere vielversprechende Anbieter wie Parallels (parallels.com).

Da Sie jetzt eine Vorstellung davon haben, worum es bei der Virtualisierung geht, wird im Rest dieses Artikels erläutert, wie sie eingerichtet wird, wie die häufigsten Fehler vermieden werden und wie Sie sie auf einer Reihe von Computern in Ihrer Umgebung bereitstellen können.

Virtuelle Bereitstellung

Die Bereitstellung virtueller Systeme muss sich nicht von der Bereitstellung physischer Systeme unterscheiden. Wie Sie jedoch sehen werden, gibt es einige gute Gründe, sie anders zu gestalten.

Unter Windows NT® mussten Sie anfangs die Bereitstellung über das Setup vornehmen. Sie konnten dafür ein Skript erstellen, mussten jedoch den gesamten Prozess durchlaufen. Nach Abschluss des Setups wurde das Kopieren dieses Abbilds auf mehrere Systeme – obwohl ein recht praktisches Konzept – einfach nicht unterstützt.

Schließlich entschied Microsoft jedoch, dass es sinnvoll war, mittels Datenträger duplizierte oder „geklonte“ Windows NT-Systeme zu unterstützen. Daher steht heute jede Methode, die bei der Bereitstellung physischer Systeme verfügbar ist, auch für die Bereitstellung virtueller Systeme zur Verfügung. Sie können folgende Methoden verwenden: Winnt32 (oder setup.exe im Fall von Windows Vista® und Windows Server® 2008), Windows PE (1.x oder 2.x, abhängig vom bereitgestellten Client, wie in früheren Artikeln erläutert), die Remoteinstallationsdienste (Remote Installation Services, RIS), die Windows-Bereitstellungsdienste (Windows Deployment Services, WDS) oder Sysprep (das mit Windows NT 4.0 eingeführte Systemvorbereitungsprogramm für die Bereitstellung) sowie Ihre bevorzugte Technologie zur Datenträgerduplizierung (beispielsweise ImageX).

Natürlich ist dies nur bei der erstmaligen Bereitstellung eines bestimmten Betriebssystems erforderlich. Danach können Sie es einfach kopieren. Mit datenträgerbasierten Duplizierungsmethoden wie den gerade genannten ist jedoch ein Problem verbunden.

Verwenden von Sysprep

Die ursprüngliche Entscheidung von Microsoft, die datenträgerbasierte Duplizierung nicht zu unterstützen, beruhte hauptsächlich auf der Windows NT-Sicherheitskennung (Security Identifier, SID). Glücklicherweise bietet Sysprep eine Lösung. Sehen Sie sich jedoch zunächst das Problem an, das durch Sysprep gelöst wird. Wie unter support.microsoft.com/kb/314828 beschrieben, besteht die SID aus einer SID-Strukturrevisionsnummer (in der Regel eine GUID (Globally Unique Identifier)), die einen einzelnen Windows-basierten Computer identifiziert. Diese ID wird dann als Stammteil des Bezeichners für alle lokalen Konten verwendet. Lokale Konten verfügen über einen eigenen eindeutigen Bezeichner, der als relative ID (Relative Identifier, RID) bezeichnet wird. Die RID besteht aus einer Konto-ID, die mit dem Ende der SID verkettet wird. Daher wird die Kombination der beiden IDs zum Bezeichner für lokale Konten.

Betrachten wir nun anhand der Administrator-SID S-1-5-21-191058668-193157475-1542849698-500, warum dies ein Problem darstellt. Hier ist S-1-5 der Deskriptor, der definiert, dass es sich hierbei um eine SID handelt (das S ist in der Textdarstellung einer SID immer vorhanden). 1 stellt die Revisionsnummer der Windows NT-SID und 5 den Autoritätsbezeichnerwert (hier Windows-Sicherheit) dar. Der Rest ist die eigentliche SID, einschließlich der Zahl 500, die diese SID als bekannte SID kennzeichnet – das Windows-Administratorkonto. Das Administratorkonto, das standardmäßig bei allen Windows-Installationen erstellt wird (und nicht gelöscht werden kann), besitzt eine SID, die mit der Zahl 500 endet. Bei lokalen Benutzerkonten, die Windows nach der Installation hinzugefügt werden, wird oberhalb von 1000 mit der Iteration begonnen.

Mit dem über Windows Sysinternals erhältlichen Tool PSGetSID (im Artikel zu den PSTools unter technetmagazine.com/issues/2007/03/DesktopFiles erwähnt) können Sie eine SID für einen bestimmten Benutzer auf einem System oder die SID des Systems abrufen. Die Ausgabe von PSGetSID für die SID des virtuellen Systems und die SID für das Benutzerkonto 1003 dieses Beispiels ist in Abbildung 1 dargestellt.

Abbildung 1** Ausgabe von PSGetSID für die SID eines virtuellen Systems und die SID des Benutzerkontos 1003 **(Klicken Sie zum Vergrößern auf das Bild)

Da die RIDs lokaler Konten auf dieser SID basieren, sollte das Problem, das auftritt, wenn Sie ein System mittels Datenträgern duplizieren oder einfach das Abbild eines virtuellen Computers kopieren, relativ offensichtlich sein. Da die SID nicht geändert wird (die primäre, aber nicht die einzige Aufgabe von Sysprep), erhalten Sie eine Kopie der Schlüsselkomponente, die ein Windows-System einzigartig macht. Wenn System A und System B die gleiche Administrator-SID aufweisen, würden sich Benutzer auf jedem der Systeme legitim als derselbe Benutzer identifizieren. Dasselbe gilt für alle lokalen Konten von System B bei der Authentifizierung bei System A und umgekehrt. Noch schlimmer ist, dass diese Systeme bei der Darstellung für Active Directory® dieselbe SID aufweisen. Wenn Sie es also zulassen, dass sich System A bei einer Domänenressource authentifiziert, dies System B jedoch nicht gestatten, tritt ein Konflikt auf. Wenn Sie für B die Ablehnung festlegen, wird A ebenfalls abgelehnt.

Daher ist es äußerst wichtig, dass Sie SIDs auf Systemen mit Sysprep neu generieren – insbesondere in Szenarios mit virtuellen Systemen, da Systemabbilder allzu einfach übertragen werden können. Sie sollten kein Drittanbietertool zum Ändern von SIDs verwenden, sondern ausschließlich Sysprep. Sysprep ist ein von Microsoft für die Vorbereitung von Systemen auf die Duplizierung (sogar von virtuellen Systemen) entwickeltes, getestetes und unterstütztes Tool. In Abbildung 2 sehen Sie ein Beispiel dafür, wie Sysprep aussieht, bevor die SID auf einem System geändert wird. Stellen Sie sicher, dass das Kontrollkästchen „Don't regenerate security identifiers“ (Sicherheitskennungen nicht erneut generieren) stets deaktiviert ist, wenn Sie als nächsten Schritt das System auf die Duplizierung vorbereiten.

Abbildung 2** "Don't regenerate security identifiers (Sicherheitskennungen nicht erneut generieren)" sollte bei der Vorbereitung auf die Duplizierung deaktiviert sein **

Neben der Aktualisierung der SID auf eine neue ID werden durch Sysprep auch alle privaten Datenspeicher geändert, die dem Tool bekannt sind, sodass sie die SID und den Computernamen widerspiegeln, oder um ihre Verschlüsselung so zu ändern, dass sie mit der neuen SID funktioniert. Einige Beispiele hierfür sind der Datenspeicher „Geplante Aufgaben“ und die zugehörigen Werte in der IIS-Metabasis (wenn IIS installiert ist).

Sysprep löscht zudem zwangsweise jede Netzwerkkarte im System und entfernt gleichzeitig die Netzwerkkonfigurationsdaten für die Netzwerkkarte. Da die Netzwerkkonfiguration von der Netzwerkkarte in der Registrierung abhängt und die Beziehung dieser Netzwerkkarte auf der Hardware-ID der Netzwerkkarte basiert (die außerhalb von Verschiebungsvorgängen zwischen virtuellen Systemen leicht zerstört werden kann), werden diese üblicherweise nicht beachteten Daten von Sysprep bereinigt.

Sysprep bereinigt zudem alle Informationen zur Active Directory-Mitgliedschaft in einem System. Daher muss das Programm im Rahmen seiner Arbeit ein System zwangsweise aus der Domäne entfernen. Dadurch wird sichergestellt, dass Systeme, die gerade neue SIDs erhalten haben, der Domäne auf sichere Weise beitreten können. Einige Dienstprogramme, die SIDs ändern, ermöglichen es Ihnen, die SID eines Computers zu ändern, ohne ihn aus der Domäne zu entfernen. Dies ist jedoch weder zuverlässig, noch sicher. Wenn Sie Sysprep unbedingt auf einem Computer ausführen müssen, der ein Domänenmitglied ist, entfernen Sie ihn vor der Ausführung von Sysprep aus der Domäne, oder führen Sie Sysprep aus, und lassen Sie das Programm diese Aufgabe durchführen.

In diesem Zusammenhang gilt auch: Wenn Sie einen Ihrer Domänencontroller (DCs) virtualisieren, müssen Sie Systeme duplizieren, bei denen es sich um rein eigenständige Server handelt, die nicht zu DCs heraufgestuft wurden und nicht mit der Domäne verbunden sind. Mit Ausnahme von Windows Server 2003 Small Business Server Edition können Sie einen DC nicht mittels Datenträgern auf sichere Weise duplizieren. Zur sicheren Erstellung neuer DCs sollten Sie ein Datenträgerabbild eines Servers erstellen, der für den Beitritt zur Domäne und die Heraufstufung zu einem DC bereit ist. Außer im sehr speziellen Fall von SBS mit einer einzelnen Gesamtstruktur/einem einzelnen Server ist Sysprep nicht bekannt, wie SIDs auf einem DC auf sichere Weise geändert werden.

Neben der Änderung der SID und dem Entfernen des Computers aus der Domäne ändert Sysprep abschließend auch den Namen des Computers.

Möglicherweise erscheint es Ihnen übertrieben, dass Sie alle vorstehenden Aufgaben beim Erstellen von Abbildern oder selbst beim einfachen Kopieren virtueller Systeme durchführen müssen. Dies ist jedoch äußerst wichtig, insbesondere wenn Sie diese Systeme in einem Netzwerk mit anderen physischen oder virtuellen Systemen, in einer Domäne oder zusammen mit einer anderen Kopie von ihnen im Netzwerk verwenden.

Wenn Sie Sysprep beim Duplizieren virtueller Systeme nicht verwenden, werden fast zwangsläufig verschiedene offensichtliche (Active Directory- oder andere Netzwerkkonflikte) und auch einige unerwartete Probleme auftreten. Ihre virtuellen Abbilder sind beispielsweise sehr anfällig für Hackerangriffe, da durch „Knacken“ eines Abbilds der Zugriff auf die anderen Abbilder möglich wird.

Treiber und Hardwareabstraktionsschichten

Es wurde bereits erwähnt, dass die in einem virtuellen Abbild enthaltenen virtuellen Geräte möglicherweise nicht über die standardmäßig mitgelieferten Treiber für Windows verfügen. Stellen Sie bei der Bereitstellung (oder bei der Bereitstellung von Datenträgerabbildern mit Sysprep) sicher, dass Sie über Treiber für Ihre Geräte verfügen, da der gefürchtete Treiberfehler „0x0000007B“ beim Verschieben eines virtuellen Abbilds von einem Speicherbustreiber zum anderen genauso leicht auftreten kann wie bei der Arbeit mit physischer Hardware. Dasselbe gilt für Netzwerkkarten. Obwohl bei den meisten Virtualisierungsprodukten versucht wurde, ein weitgehend universelles virtuelles Gerät bereitzustellen, benötigen Sie möglicherweise dennoch einen zusätzlichen Treiber dafür.

Sie dürfen auch nicht das Problem der Hardwareabstraktionsschicht (HAL) ignorieren. Im Idealfall sollten Sie Ihre virtuellen Computer so erstellen, dass sie ACPI-Multiprozessoren (Advanced Configuration and Power Interface) unterstützen (siehe intel.com/technology/iapc/acpi), sofern dies von Ihrer Virtualisierungstechnologie unterstützt wird. Die Konvertierung zwischen HALs wird im Allgemeinen nicht unterstützt (weitere Informationen finden Sie unter support.microsoft.com/kb/309283). Einige Virtualisierungstechnologien – oder, was noch wichtiger ist, viele Migrationstechnologien – verheißen, dass eine Windows-Installation, die ACPI nicht unterstützt, auf sichere Weise zu einer ACPI-Installation verschoben werden kann und umgekehrt. Dies ist nicht wahr, und die resultierende Windows-Installation wird darüber hinaus von Microsoft nicht unterstützt, wenn Probleme auftreten. Die gleichen Einschränkungen, die auf der gerade erwähnten Supportwebseite erläutert werden, gelten auch für virtualisierte Systeme. In Abbildung 3 finden Sie ein Beispiel dafür, wie die HAL im Geräte-Manager auf einem meiner virtuellen Computer angezeigt wird – in diesem Fall erfolgt die Ausführung mit der ACPI-Uniprozessor-HAL. Diese ist mit ihrem Multiprozessor-Gegenstück austauschbar und darf nicht mit einem Einzelprozessor verwechselt werden.

Abbildung 3** HAL im Geräte-Manager auf einem virtuellen Computer **(Klicken Sie zum Vergrößern auf das Bild)

Verschiedene Änderungen

Ändern Sie, was Sie können, und übernehmen Sie alle anderen Aspekte

Wenn Sie die Migration von physischen zu virtuellen Systemen oder umgekehrt in Erwägung ziehen, müssen Sie die Aspekte berücksichtigen, die Sie ändern bzw. nicht ändern können. Die folgenden Aspekte einer Windows-Installation können geändert werden:

• Die HAL (jedoch nur von einer Uniprozessor- in eine Multiprozessor-HAL oder umgekehrt, sofern sie auf der gleichen Energiekonfiguration basieren).
• Massenspeichercontroller (dies ist nicht einfach, aber bei den meisten Lösungen für die Migration von physischen zu virtuellen Systemen wird bereits von selbst ein entsprechender Versuch unternommen). Beachten Sie, dass die meisten Anbieter eine IDE- und eine SCSI-Speicherlösung bereitstellen. Treffen Sie bei der Bereitstellung die richtige Wahl, da es nicht gerade einfach ist, von einer Lösung auf die andere umzustellen. In der Regel führt die Auswahl von SCSI zu einem zuverlässigeren Gerät (dies ist bei den meisten Anbieterimplementierungen der SCSI-Geräteemulation der Fall).
• Netzwerkcontroller (obwohl dieser bei einem Szenario zur Migration von virtuellen zu virtuellen Systemen im Rahmen der Technologien eines bestimmten Anbieters im Allgemeinen gleich ist).

Die folgenden Aspekte einer Windows-Installation können nicht geändert werden:

• Die HAL (außer im oben genannten Fall, in dem dieselbe Energiekonfiguration verwendet wird). Denken Sie nicht, dass eine Migrationslösung, bei der dies der Fall ist, zu einer stabilen oder zuverlässigen Windows-Installation führt. (Noch wichtiger ist, dass sie von Microsoft nicht unterstützt wird.)

Neben der SID und dem Computernamen müssen Sie auch bestimmte Werte ändern, die für die von Ihnen verwendete virtuelle Computertechnologie spezifisch sein können. Sie müssen insbesondere die MAC-Adresse (die eindeutige ID für Netzwerkgeräte) ändern. Darüber hinaus weisen viele virtuelle Anwendungen ebenfalls einen eigenen eindeutigen Bezeichner auf. Bei den meisten Anwendungen werden diese in Konfigurationsdateien des Computers gespeichert. Daher sollten Sie wissen, wie diese Einträge geändert werden (und ihre Gültigkeit aufrechterhalten wird). Beachten Sie, dass viele Virtualisierungsprodukte, die PXE (Pre-Boot eXecution Environment) unterstützen, die SMBIOS-UUID auf der Basis ihrer eigenen eindeutigen ID erzeugen – wodurch die Notwendigkeit deutlich wird, diese zu ändern (oder die Änderung von der Virtualisierungssoftware vornehmen zu lassen, sofern dies unterstützt wird), wenn Sie sie mit einer Domäne verbinden. Andernfalls kann es unmöglich werden, WDS- oder RIS-Clientsysteme (bei GUID-Konflikten) zu verwalten. Bei den meisten Virtualisierungslösungen, mit denen ich gearbeitet habe, können im Fall doppelter MAC-Adressen schwerwiegende Netzwerkprobleme auftreten. Wenn Sie nicht einfach einen virtuellen Computer verschieben, ist es sehr wichtig, dass die MAC-Adresse geändert wird, wenn dies nicht von der Virtualisierungssoftware übernommen wird.

Andere Komponenten, an die Sie denken müssen, wenn ein virtuelles System auf die Bereitstellung vorbereitet wird, sind verknüpfte Datenträger oder Snapshots. Abhängig von Ihrer Virtualisierungslösung können diese auch als „differenzielle Datenträger“ bezeichnet werden oder einen anderen Namen tragen. Wenn Sie jedoch Sysprep zur Vorbereitung eines Systems ausführen und über Snapshots (oder einen anderen wiederherstellbaren Zustand) verfügen, die zum virtuellen System gehören, müssen diese zerstört werden, damit das Abbild bei der Duplizierung sicher, zuverlässig und geschützt bleibt. Im Fall eines Snapshots oder eines anderen Technologieansatzes zum „Rückgängigmachen von Datenträgeränderungen“ könnte das Wiederherstellen eines Snapshots den Rückschritt zu einem Zustand bedeuten, bei dem mehrere Systeme, für die der ursprüngliche virtuelle Computer als Quelle diente, jetzt miteinander in Konflikt stehen (oder sogar mit dem ursprünglichen Quellsystem, wenn es wiederhergestellt wird). Daher sollte für alle Snapshots oder differenziellen Datenträgerbeziehungen bereits Sysprep ausgeführt worden sein.

Optimierung

Die meisten Virtualisierungstechnologien umfassen Ergänzungen oder Tools für virtuelle Computer, die dabei helfen, die Leistung und die Benutzerfreundlichkeit bei der Interaktion mit dem Gast vom Host aus zu verbessern. Hierzu gehören in der Regel Arbeiten, durch die neben anderen Leistungsverbesserungen die Maus- und Tastatureingabe optimiert wird, sowie in vielen Fällen verbessertes Kopieren und Einfügen (oder andere Interaktionen zwischen Host und Gast). Installieren Sie vor der Bereitstellung die neueste Version dieser Tools auf Ihren virtuellen Systemen.

Sie müssen zudem sicherstellen, dass der Clientarbeitsspeicher nicht nur für das Gastbetriebssystem, sondern auch im Kontext mit den Hosts, auf denen es bereitgestellt wird, optimal konfiguriert ist. Vermeiden Sie den Fehler, dass ein Windows XP-Abbild, das auf die Verwendung von 1 GB RAM festgelegt ist, auf Hostsystemen bereitgestellt wird, die gar nicht über einen so großen Arbeitsspeicher verfügen.

Berücksichtigen Sie auch die Einschränkungen, denen die meisten virtuellen Technologien derzeit noch unterliegen. Daher ist es für Ihre Benutzer wichtig, wie sie mit an das virtuelle System angeschlossenen Peripheriegeräten interagieren können, sowie welche Anwendungen unter dem Gastbetriebssystem (nicht) funktionieren (die meisten Anwendungen unterstützen beispielsweise DirectX 9 oder 10 nicht, oder sie unterstützen ältere Versionen nur in begrenztem Umfang). Die Benutzer wissen möglicherweise nicht, was dies bedeutet oder wie es erkannt wird (in einigen Anwendungen werden derartige Fehler nicht wirksam behandelt).

Hostprobleme

Im Allgemeinen müssen Sie sich nicht viele Gedanken über den Host-PC machen, auf dem die Virtualisierungstechnologie ausgeführt wird, unabhängig davon, ob ein vollständiges Betriebssystem oder ein Typ-1-Hypervisor, der direkt auf der Hardware läuft, ausgeführt wird. Die meisten Virtualisierungstechnologien sind darauf ausgelegt sicherzustellen, dass das Gastbetriebssystem keine (oder nur wenige) Informationen über den Host benötigt. Sie müssen jedoch wissen, welche Hosts verwendet werden, falls bei einem Gast, der von einem Host auf einen anderen verschoben wird, Probleme auftreten. Informieren Sie sich außerdem über die Einschränkungen des Produkts Ihres Virtualisierungsanbieters auf bestimmten Plattformen. Sie können zwar möglicherweise zwischen verschiedenen Plattformen wechseln, verlieren oder gewinnen dabei aber eventuell bestimmte Features des Typ-2-Hypervisors (der Virtualisierungsanwendung) des Hostbetriebssystems.

Andere Bereitstellungsmethoden

Verwandte Sysprep-Links

In den folgenden Dokumenten finden Sie viele hilfreiche Informationen zu Sysprep:

• Entwerfen von Abbildinstallationen mit Sysprep
• Verwenden von Sysprep zum Automatisieren der erfolgreichen Bereitstellung von Windows XP
• Verwenden des Systemvorbereitungsprogramms (Sysprep.exe) zur Durchführung einer Datenträgerduplizierung
• Verwenden des Systemvorbereitungsprogramms auf nicht identischen Computern

Die Verwendung von Sysprep oder die Datenträgerduplizierung (bzw. das einfache Ausführen von Sysprep und das Kopieren des virtuellen Computers) sind offensichtliche Optionen für die Bereitstellung virtueller Systeme, es gibt jedoch noch weitere Möglichkeiten. Tatsächlich kann unabhängig davon, ob Sie die Abbilderstellung oder das Setup verwenden, die Verwendung von Windows PE in Verbindung mit der Virtualisierung einfacher sein als mit physischen Computern, da Sie nicht mit einer physischen CD, sondern mit ISO-Dateien arbeiten. Beachten Sie, dass einige Virtualisierungstechnologien in Verbindung mit DVD-Medien nicht optimal funktionieren. Fragen Sie Ihren Virtualisierungsanbieter daher unbedingt, ob diese unterstützt werden. Sie können winnt32 oder setup.exe (im Fall von Windows Vista oder Windows Server 2008) verwenden, es gibt jedoch keine besonderen Vorteile. Wenn Sie andere Microsoft-Bereitstellungstechnologien wie beispielsweise die automatischen Bereitstellungsdienste verwenden, unterstützt Ihre Virtualisierungstechnologie PXE, sodass eine netzwerkbasierte Bereitstellung ausgelöst wird, genau als ob RIS oder WDS verwendet würde.

Migration

Vergessen Sie neben der tatsächlichen Migration eines gesamten PCs nicht das Migrationsprogramm für den Benutzerstatus (User State Migration Tool, USMT). USMT ermöglicht es Ihnen, die Einstellungen eines Benutzers von einem physischen Client problemlos auf ein neues virtuelles System zu verschieben. Wenn Ihre Benutzer also ihre alten Daten und Einstellungen zu einem neuen virtuellen Computer migrieren möchten, könnten Sie beispielsweise die Dateien und Einstellungen auf einfache Weise von Windows XP abrufen, sie in einer UNC speichern und sie dann auf einen neuen virtuellen Computer übertragen.

Wes Miller lebt in Austin, Texas. Früher arbeitete er bei Winternals Software in Austin und bei Microsoft als Programmmanager und Produktmanager für Windows. Sie können Wes Miller unter technet@getwired.com erreichen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.