Am einfachsten ist es, wenn Sie dazu das kostenlose Tool Rufus (http://rufus.akeo.ie) verwenden. Rufus muss nicht installiert werden, sondern steht auch als portable Version zur Verfügung. Die Vorgehensweise zum Erstellen eines Bootmediums für Hypervisor ist recht einfach:

1. Laden Sie sich Rufus als portable Version herunter und starten Sie das Tool.
2. Hat der Rechner eine Internetverbindung, können Sie nach dem Start prüfen lassen, ob eine neuere Version vorliegt.
3. Sobald Rufus einsatzbereit ist, wählen Sie im Feld Laufwerk zunächst den USB-Stick aus, den Sie für die Installation verwenden wollen. 
4. Klicken Sie danach auf das DVD-Symbol des Tools bei „Startfähiges Laufwerk erstellen mit“ und wählen Sie die ISO-Datei von vSphere Hypervisor 6 aus.
5. Als Partitionsschema verwenden Sie GPT.
6. Das Dateisystem können Sie auf FAT32 belassen.
7. Auf Wunsch können Sie noch die Einstellungen bei „Größe der Zuordnungseinheiten“ anpassen, notwendig ist das aber nicht.
8. Klicken Sie danach auf Start und lassen Sie den USB-Stick erstellen. Sobald der Stick zur Verfügung steht, können Sie auch mit diesem vSphere Hypervisor 6 auf einem Server installieren.

Hyper-03

vSphere Hypervisor 6 können Sie auch über einen USB-Stick installieren

Für Testumgebungen kann es sinnvoll sein, dass Sie den Hypervisor nicht auf einer internen Festplatte des Servers installieren, sondern auf einen USB-Stick. Verbinden Sie den USB-Stick mit dem Server, bootet dieser mit vSphere Hypervisor und lässt sich genauso verwalten, wie eine lokale Installation. Für Produktivumgebungen ist das zwar nicht geeignet, aber für Testumgebungen ist diese Möglichkeit durchaus interessant.  Für die Installation muss der Stick nur mit dem Server verbunden werden. Weitere Einstellungen sind nicht notwendig.

Das gilt auch für die Archivierung. Die Daten lassen sich nicht in ausfallsichere und stabile „echte“ SQL-Server ablegen. Zwar verbessert Microsoft mit jeder Exchange-Version die ESE-Datenbank in Exchange, allerdings wird die Situation für Datenbank-Administratoren dadurch nicht besser.

Retain 4 unterstützt dagegen die Speicherung der archivierten Daten auf echten Datenbank-Servern. Unternehmen können MySQL 5.6x, Oracle 10/11g, MS SQL Server 2008 R2, 2012, 2014 und PostgreSQL 9 zur Ablage der Daten nutzen. Nur dadurch ist die ordnungsgemäße und dauerhafte Speicherung der Daten sichergestellt. Außerdem lassen sich die Daten in diesen Systemen leistungsstark abfragen, und einfacher exportieren, zum Beispiel für Big Data oder andere Analyse-Systeme.

Darum sind SQL-Datenbanken besser für die Archivierung geeignet

Exchange 2016 baut immer noch auf der Datenbanktechnologie von Exchange 5.5 aus den 1990ern. Der Server basiert auf der Joint-Engine-Technologie (JET). Diese Datenbank sind vor allem dann gefährdet, wenn es auf einem Server zu einem unerwarteten Absturz kommt. Microsoft möchte seit Jahren Exchange-Datenbanken in SQL-Datenbanken zusammenführen. Leider haben es die Redmonder noch immer nicht geschafft, sodass Exchange-Administratoren weiterhin mit den ESE-Datenbanken kämpfen müssen, vor allem bezüglich Sicherung und Wiederherstellung.

ESE wurde ursprünglich als Zukunfts-Datenbank-System von Microsoft entwickelt.  Alle Microsoft-Server-Produkte sollten diese Datenbank nutzen. Allerdings hat sich das schnell als undurchführbar herausgestellt, sodass nur noch Exchange und Active Directory auf dieses veraltete System setzen. Bei Active Directory spielt die Datenbank keine große Rolle, da deren Größe beschränkt ist, und die Daten ohnehin zwischen Domänencontrollern repliziert werden.

Bei Exchange versucht Microsoft seit Exchange 2003 einen Wechsel, bekommt es aber nicht hin.  Im Gegensatz zu SQL-Datenbanken, verfügen ESE-Datenbanken über keine Zugriffsmöglichkeiten durch externe Abfragen und über sehr eingeschränkte Sicherungsmöglichkeiten. Als Datenbank für die Archivierung ist ESE eher ungeeignet. ESE-Datenbank sind allerdings in Teilen besser für das Speichern von E-Mails geeignet und können schneller E-Mails speichern. Das liegt an der dynamischen Struktur von ESE und der hohen I/O-Last. Für die dauerhafte und stabile Archivierung sind diese Datenbanken aber denkbar schlecht geeignet.