Build a hardened ESXi 6.5 image for HPE hardware

As part of the series for ESXi 6.5 this post should give you an idea of how to handle a ESXi image build in detail. No long introduction. Let’s start:


  1. Get you the latest ESXi 6.5 offline bundle available from
    VMware Patch Repository (MyVMware Login required)

  2. Get the required drivers and agents from HPEFirst check the recipe for the right firmware and driver combinations. This maybe requires you to update firmware on your boxes.
    HPE ProLiant server and option firmware and driver support recipe 

    Download the required drivers for the latest folder container esxi-650-* hierachie
    (alternatively you could connect this online, but have to build the image without a proper internet connection)

    The “esxi-650-devicedrivers” folder contains the right offline bundles for the drivers. Pick the ones you need for your hardware. If you have no idea how to find our what driver is required, please play around a little bit with the “esxcfg-*” commands on the ESXi Shell. List your network and storage adapters on an existing ESXi, best installed with vendor image, and note down the drivers are used.

    The “esxi-650-bundles” contains all additional agents and tooling. Just download the hpe-esxi6.5uX-bundle-* file as this does contain the  hpe-smx-provider CIM provider integration you need for proper hardware monitoring.Some of the drivers are double zipped. Just extract the first layer so you have the offline bundle. The second zip file should not contain any further *.zip file, but *.vib or a vib20 folder.

  3. Setup a PowerCLI 6.5 environment on a compatible Windows machine


  1. Load the VMware ESXi vanilla image
    Add-EsxSoftwareDepot .\
  2. Clone it for further modification
    PS> Get-EsxImageProfile | Select Name
    Select the standard image. For other patch offline depots you might see for Image Profiles. Pick the standard one without “s” behind the number.
    New-EsxImageProfile -CloneProfile ESXi-6.5.0-20170304101-standard -Name "ESXi-650-custom-hpe-hardened"  -Vendor "schoen computing"
    The Acceptance Level gets automatically inherited from the source image. You don’t need to explicitly specify the parameter.

  3. Remove packages
    Remove-EsxSoftwarePackage -ImageProfile ESXi-650-custom-hpe-hardened -SoftwarePackage xhci-xhci
    I removed these packages for my use case:
    This list does also contain drivers now get removed, but later added from the HPE depot in a newer version.

    Attention: Not all packages can be removed in the listed order as there dependencies between them. If the CLI does not allow you to remove a package as it is a required for another package, just remove the other first and try again.

  4. Export the stripped image
    Export-EsxImageProfile -ImageProfile ESXi-650-custom-hpe-hardened -ExportToBundle -FilePath .\
    This image now does contain only the left packages. I prefer now to close the PowerCLI session and load the exported image in a new session like in step 1.

  5. Add HPE offline depots
    Add-EsxSoftwareDepot .\<hpe driver/bundle>.zip
    Add all downloaded and extracted zips in the way above.

  6. Add the HPE packages to the image
    Add-EsxSoftwarePackage -ImageProfile ESXi-650-custom-hpe-hardened -SoftwarePackage <package name>
    The package names can be get from the offline depot zip files. These contain a folder for each package name in  vib20  folder. For my use case these packages were added:
  7. Export the finale image
    Export-EsxImageProfile -ImageProfile ESXi-650-custom-hpe-hardened -ExportToBundle -FilePath .\
    Export-EsxImageProfile -ImageProfile ESXi-650-custom-hpe-hardened -ExportToIso -FilePath .\ESXi-650-custom-hpe-hardened.iso

     Keep the ZIP store anywhere as you can use it for updating and extending the image.

ESXi 6.5 security/hardening

ESXi Hardening – loved and hated. What do have already in this space? VMware provides a hardening guide for all the latest versions of ESXi. Looks like with 6.5 there was a change in naming: “Security Configuration Guide“.  I think is pretty much well known, but in my day-to-day work this is only one part to build a hardened hypervisor. Especially if you work with large and security sensitive customers, you should put more brain work into this topic. As this is a growing topic, best is to set up a series for it:
  1. ESXi image
  2. SSL/TLS
  3. DMZ
  4. Monitoring
Stay tuned!

VMware Validated Designs does not exclude Stretched Cluster in general

Working as an architect in the VMware space you will sooner or later come across the VMware Validated Designs (VVD). Just a few weeks ago the latest version 4.0 was released to make adjustments for vSphere 6.5. It can be found here:

VMware Validate Designs Documentation

The designs are a great source for building your own architectures or building architectures for customers. The incorporated component architectures are natively built for availability, reliability and scalability. These are exactly the main goals I try to put in the designs I create for customers. The VVDs show up a good practise for a detailed setup that can be used for several use cases like Private Cloud or VDI deployments. VMware Cloud Foundation also makes use of the VVDs for its implementations.

But apart from this I also like to treat them as a framework which gives me the chance to keep the setup supported by VMware but also adjust it to the customer needs and make it fit like a second skin based on customers requirements.

Across their history they mainly relied/rely on a two region concept with one primary and fail-over region. This is a quite common architecture for U.S. setups. In the European space and especially in Germany customers often stick their existing architectures based a two datacenters setup working as an active/active pair. If you see this also as a two region setup or you would aggregate this into one region like me, is up to you. I prefer one region because the datacenters are in a short distance because of their synchronous replication/mirroring and so they build up a logical domain because for their active/active style.  This is why I split the region down to two physical availability zones (AWS term) and one virtual across two datacenters. This does not need to be undestand now, it will get clearer in later chapter.

In my understanding the VVD framework needs some extension in regards to Stretched Clusters and this is why I like to set up a series which guides through a forked version of the VVDs I personally use for customer designs:

  1. General thoughts
  2. Additions/Changes to physical architecture
  3. Additions/Changes to virtual architecture
  4. Additions/Changes to cloud management architecture
  5. Additions/Changes to operations management architecture
  6. Additions/Changes to business continuity architecture

Stay tuned!






Set up vCenter HA in advanced mode with different heartbeat networks

Setting up vCenter HA in basic mode is pretty straight forward.

Doing the same in advanced mode is a little bit more tricky. But first, why I need to go with the advanced vCenter HA mode?

  • the VCSA is managed by another vCenter (for example if the setup is according to the VMware Validated Design 3.0)
  • the heartbeat vNICs are not in the same IP subnet

Luckily I to cater with both in a project.

I don’t want to create much content by copying from VMware documentation, so I only like to give some hints and describe some pitfalls you might get into, when setting this up and last but not least describe what VMware missed in there official documentation:

Preparation pitfalls

DNS reverse lookup

Basics, basics, basics. Ensure that you have a proper DNS reverse lookup implemented. Also take care of the exact writing of the host names. Don’t maintain a hostname entry in the DNS system with capital letters and use a non-capital or mixed one in your VCSA. This basically does not work, because the self-lockup fails. The GUI won’t tell you that, but if you run the preparing with prepare-vcha cmd line interface I will show up some more info.


Procedure pitfalls

When have you clicked through the first step in GUI, the next step is to clone the VCSA two times, once for the passive node and second one for the witness node. Very important is, that you don’t clone before the first step has finished. Otherwise the communication between the appliances won’t work because they use the wrong SSH keys. This is also valid, if you try to use the same cloned appliances for setting this up a second time – this won’t work. You need to throw them away and clone new ones at the right point in time.


The official documentation does not describe the customization stuff in much detail. Maybe that is not necessary, but if something is not totally clear to you, here some hints:

Passive node: documentation is clear, but really, you need to configure the first NIC (NIC 0) with the same IP config like the primary vNIC of your original VCSA. The adapter gets automatically shut down while first boot, so there is no IP conflict in your network – or better only for a short moment. NIC 1 set to the heartbeat network info you have prepared. Ensure that you really don’t set a gateway on this adapter.

Witness node: the documentation stated here to also leave the gateway out for the required heartbeat NIC. I have not done this, as I set the first adapter unused or shut it down. The second one I set to the heartbeat IP and used also a gateway. The gotcha was, that the witness had an IP in a totally different subnet than the active and the passive VCSAs. Static routes might also do the job, but I had some trouble with that.

First start

Start up the appliances. The IP conflict resolves as described above. Before to click the next step in the GUI, ensure that you do the following:

Go to both active and passive VCSA and add a static route so they can reach the witness via the heartbeat interface:

Edit /etc/systemd/network/ and add the following lines at the end:


The destination can be limited to the heartbeat IP of the witness VM. The gateway must be the gateway of the IP subnet used for the heartbeat in the local VCSA appliance. Repeat this on the passive appliance (best is to SSH to it via the active one).

Now and only now hit “Finish” in the GUI and all should go well. You can check the log /var/log/vmware/vcha/vcha.log for further info.

vSphere Replication mit eigenen Zertifikaten

Der Einsatz von vertrauenswürdigen Zertifikaten für die Absicherung von internen Diensten wird in vielen Unternehmen stark vernachlässigt. Viele Unternehmen setzen sie ausschließlich für extern gehostete Dienste bzw. Dienste, die über die hauseigene DMZ bereitstellt werden, ein. Fragt man nach den Gründen, warum intern genutzte Dienste vernachlässigt werden, wird oft der Aufwand der Implementation und die fehlende Certificate Authority (CA)-Infrastruktur angeführt. Nahezu alle Unternehmen nutzen das Microsoft Active Directory (AD) zur Bereitstellung von Verzeichnisdiensten. Viele wissen jedoch nicht, dass dies die ideale Methode zur Verbreitung von unternehmensweiten Zertifikaten ist. Am Anfang steht jedoch der Aufbau einer internen CA, da die Unternehmen zumeist eigene DNS-Namensräume (Domänen) verwenden bzw. die Kosten alle internen Client/Server mit einem Zertifikat zu versorgen, unterverhältnismäßig sind. Microsoft bietet im Lieferumfang des Windows Server 2008 R2 eine Rolle an mit der sich eine CA betreiben lässt, was somit für fast alle Unternehmen kostenfrei ist. Über das AD kann dann das erstellte Root-CA-Zeritifkat bzw. auch die erstellten Intermediate-CA-Zertifikate an die Client-Truststores ausgerollt werden. Somit sind alle von der Root- oder Intermediate-CA ausgestellten Zertifikate innerhalb des Unternehmens-AD vertrauenswürdig. Für spezielle Dienste wie z. B. das VMware vCenter können dann zusätzlich zu den dann bereits vorhandenen Client-Zertifikat weitere Server-Zertifikate bei der CA beantragt werden. Dies garantiert eine gesicherte Kommunikation auch innerhalb des Unternehmens. Für Server, unabhängig ob physikalisch oder virtuell, die mit Unix/Linux-Derivaten betrieben werden ist ein manueller Import der CA-Zertifikate nötig. So auch bei den Appliances von VMware. Im Fall der vSphere Replication Appliance wird das Root-CA-Zertifikat und ein eventuell vorhandenes Intermediate-CA-Zeritifkat einerseits in den Java-Truststore der Anwendung als auch in den Linux-System-Truststore importiert. Zusätzlich machen wir beide CA-Zertifikate auch dem Webserver für die Managementoberfläche bekannt. 1. Vorbereitungen a) Root-CA-Zertifikat (bspw. “root.crt”) und Intermediate-CA-Zertifikat (bspw. “intermediate.crt”) per SCP auf die vSphere Replication Appliance kopieren b) aus beiden Zertifikaten wird nun eine Zertifikatskette (Chain) erzeugt: 2. Zertifikat in den Java-Truststore von vSphere Replication importieren: 3. Zertifikat in den Linux-Truststore importieren: 4. Zertifikat dem Webserver der Managementoberfläche bekannt machen: Im Anschluss kann das vorbereitete Server-Zertifikat im PFX-Format über die Managementoberfläche https://myreplicationappliance:5480/ > Configuration eingespielt werden.

Erneute Probleme mit SSO in vCenter 5.1 U1a

Auch mit vCenter 5.1 U1a kann es erneut zu Probleme mit der SSO-Komponente kommen. Diese scheinen im Gegensatz zu den vorherigen Versionen anders gelagert zu sein. Bei Tests ergab ich ein Problem mit Benutzern, die in einer Active Directory Group sind, die wiederum zu den lokalen Administratoren hinzugefügt wurde. Wurde nun bei der Installation des vCenter’s die lokale Administratorengruppe mit der Rolle “Administrator” auf das Inventory-Root (vCenter Objekt) berechtigt, kann dies dazu führen, dass der Benutzer der AD-Gruppe die Meldung bekommt, der er keine Rechte auf die nötigen Objekte hat. Der Web Client ermöglicht zwar einen Login, jedoch sind keine vSphere Ressourcen aufgrund ebenfalls fehlender Rechte sichtbar. Einigen Nutzern der AD-Gruppe kann ein Login trotzdem möglich sein, wenn diese schon über eine andere AD-Gruppe zu den lokalen Administratoren hinzugefügt wurden. Es gibt zwei Möglichkeiten um dieses Problem zu umgehen, da es bisher noch keinen Patch seitens VMware gibt:
  1. Es wird eine zweite lokale Gruppe hinzugefügt und die AD-Gruppe dort als Mitglied aufgenommen. Achtung: Die zweite lokale Gruppe muss danach noch gesondert auf das Inventory berechtigt werden.
  2. Es wird eine SSO-Gruppe angelegt und die AD-Gruppe als Mitglied aufgenommen. Achtung: Die SSO-Gruppe muss danach noch gesondert auf das Inventory berechtigt werden.
Beide Workarounds setzen voraus, dass noch Zugriff aus das vCenter Inventory besteht. Alternativ sollte man bei der Installation stattdessen einen Service-AD-Account berechtigen oder direkt eine AD-Gruppe. Beide Methoden umgehen ebenfalls das Problem. Die Problem werden ebenfalls von Magnus Andersson hier beschrieben:

vCenter Hochverfügbarkeit mit vSphere Replication

Das Management ist in IT-Infrastrukturen oft das schwächste Glied in der Umgebung und wird in vielen Desaster-Plänen nicht beachtet. Fällt in einer vSphere-Infrastruktur beispielsweise das vCenter aus, können wichtige Funktionen, welche zum Betrieb und Management der Infrastruktur notwendig sind, nicht mehr ausgeführt werden.  Hierzu zählt z.b. Dynamic Resource Scheduling (DRS), vMotion oder auch Storage vMotion. Genauso ist der Zugriff auf die Distributed Switche eingeschränkt. Unter anderen aus diesen Gründen besteht bei Kunden immer wieder die Notwendigkeit, Lösungsszenarien dazustellen,  welche die wichtigen Management Komponenten hochverfügbar machen. Wo liegt das Problem? Grundlegend gibt es vier Fehlerszenarien, die den Betrieb des vCenter unterbrechen können. Dabei wird jeweils der Betrieb des Applikationsservers mit allen vCenter-Komponenten (vCenter Server, Inventory Service, Orchestrator, SSO, Update Manager) sowie einer externen MSSQL-Datenbank angenommen. Alle Szenarien lassen sich aber ebenso für verteilte vCenter-Komponenten, sprich verteilt auf verschiedenen Server, anwenden. Folgende Ausfallszenarien können eintreten:
  1. Probleme auf Betriebssystem- und Software-Komponentenebene (Update)
  2. Ausfall oder Störung eines Blades im Enclosure
  3. Ausfall oder Störung des gesamten Enclosures
  4. Ausfall oder Störung des gesamten Datacenters
Szenario Eins kann beispielsweise beim Einspielen von Windows Patches und dem Update von vCenter-Komponenten auf einen neuen Release-Stand eintreten. Hiergegen sollte man sich vor einem Updat,e mit Backups der Datenbanken (SQL und ADAM) sowie einem zusätzlichen Snapshot der VM’s, vor dem Update absichern. Szenario Zwei skizziert den Wegfall des ESXi-Host, der im dem Moment des Ausfalls die vCenter-VM(s) oder die Datenbank bzw. mehrere vCenter Komponenten ausführt. Um die Komponenten in diesen Fall möglichst schnell wieder in den normalen Betrieb zu nehmen, sollte man auf ein, bei der Inbetriebnahme des Clusters aktiviertes, vSphere HA setzen. Dieser startet nach dem Ausfall die VM’s des ESXi-Hosts auf anderen Hosts im Cluster neu solange die nötigen Ressourcen hierfür vorhanden sind. Für Szenario Drei muss bei Blade-Umgebungen auf das vorliegende Cluster-Design geachtet werden. Bestmöglichst, erstreckt sich ein vSphere Cluster über mindestens zwei Blade-Enclosures. Weiterhin ist darauf zu achten, das die nicht ausgefallenen Enclosures genug Failover-Kapazität (Admission Control) bereit halten. So lassen sich die ausgefallenen VM’s, wie in Szenario 2, dort neustarten und so eine möglichst geringe Ausfallzeit garantieren. Vorsicht ist geboten, wenn alle vSphere Hosts (Blades) im Cluster in nur einen Enclosure sind. In diesen Fall muss über eine andere Lösung zur schnellen Wiederaufnahme des Betriebs gesetzt werden, da vSphere HA in dieser Situation nicht greift. Erschwerend kann hinzukommen, dass die Datastores/LUN’s auf denen die entsprechenden VM’s liegen, lediglich den ESXi-Hosts dieses Clusters präsentiert werden (z. B. Fibre Channel Zoning). Für dieses Szenario muss also eine Replikation der Daten auf ESXi-Host-Ebene (Block-based; Host based Replication) oder auf Applikationsebene erfolgen. Für beide Szenarien bietet VMware jeweils ein Produkt an. Für beide Ansätze wird kein zusätzliche Array-basierte Replikation (z.B. EMC SRDF) benötigt. Eine Lösung ist VMware vCenter Server Heartbeat. VMware vCenter Server Heartbeat arbeitet auf Applikationsebene und spiegelt die Dienste auf eine “Failover”-VM. Im Falle des Ausfalls der primären Seite, kann die Failover-Seite nahezu unterbrechungsfrei den Betrieb aufnehmen. Eine kostengünstigere Alternative mit einer etwas höheren Wiederherstellungszeit und manuellen Eingriff bietet die Lösung “vSphere Replication”. Diese ist bereits in allen vSphere-Paketen ab der “Essentials Plus”-Variante mit Lizenziert. Weitere Details zu dieser Lösung finden sich im zweiten Abschnitt. Szenario vier, bspw. verursacht durch einen Stromausfall im gesamten Datacenter, stellt eine Situation dar, in der zumeist der Betrieb des vCenter’s obsolet ist, da alle verwalteten Ressourcen auch ausgefallen sind. vSphere Replication Eine Replikation mit vSphere Replication unterscheidet sich gegenüber vCenter Server Heartbeat (nachfolgend Heartbeat genannt) grundlegend in zwei Merkmalen. Es findet entgegen Heartbeat eine Replikation von Speicherblöcken auf vSphere Hypervisor-Ebene statt und zusätzlich ist die Replikation nicht synchron. Im Unterschied zu Heartbeat kann diese Replikation aber für alle VM’s angewendet werden, da sie für das Betriebssystem transparent ist. VMware Heartbeat beschränkt zusätzlich nur auf Windows-Systeme. vSphere Replication erlaubt eine periodische Replikation der geänderten Speicherblöcke einer VM in einem Abstand von 15 min bis zu 24 h, der sogenannten RPO (Recovery Point Objective). Dabei werden am Ende der Periodendauer mittels CBT (Changed Block Tracking) alle geänderten Blöcke aus dem CBT-Log auf eine “Failover”-Seite übertragen. Diese Mthode entlastet die Replikationsstrecke und ermöglicht kürzere Replikations-Zyklen. Voraussetzung für die Replikation der vCenter-Komponenten sind zwei vCenter-Instanzen, die sich später idealerweise über Kreuz replizierten. Zusätzlich wird für beide vCenter-Instanzen jeweils eine vSphere Replication Appliance benötigt, die an das vCenter als vService gebunden wird. Beide vCenter müssen vSphere-Ressourcen verwalten, die später als Quelle und Ziel für die Replikationen dienen. Dabei werden die Blöcke einer VM vom ESXi-Host auf dem die VM ausgeführt zur vSphere Replication-Appliance des zweiten vCenters repliziert, die wiederum die Blöcke über einen ESXi-Host auf den gewählten Datastore der anderen Seite herunterschreibt. Nachfolgende Grafik soll dies verdeutlichen: vSphere Replication architecture Der Hauptgrund für das Vorhandensein einer zweiten vCenter-Instanz ist der Recovery-Prozess. Für die Inbetriebnahme der ausgefallenen VM’s ist das vSphere Replication-Plugin im Webclient nötig. Ist dies gegeben, lässt sich relativ einfach über den Webclient der Betrieb der VM’s wieder aufnehmen. Nutzt man man nur ein vCenter und eine vSphere Replication-Appliance kann man zwar die VM’s auf andere Datastores und Cluster replizieren, jedoch hat man das Henne-Ei-Problem, der Dienste die zum Wiederherstellen der VM’s gebraucht werden. Man sollte nicht unerwähnt lassen, dass solange die VM-Dateien (VMX, VMDK) vorhanden sind sich der Betrieb auch wieder per Hand aufnehmen lässt. Nur ist diese Möglichkeit wesentlich komplizierter und erfordert eine gut dokumentierte Anleitung. vSphere Replication ist nicht auf Szenario drei begrenzt. Es eignet sich auch für Szenario eins. Hier kann die Replikation, der zu aktualisierenden VM’s auch pausiert werden, sodass etwaige Fehler nicht in das Replikat übertragen werden. In diesem Falle kann ein einfach Rollback über die Recovery-Funktion des vSphere Replication gemacht werden. Dies stellt eine weitere Alternative zu Snapshots dar. Die Einrichtung sowie die spätere Konfiguration erfolgt ausschließlich über den vSphere Webclient. Über das Plugin, im vCenter “1”, lässt sich das gegenüberliegende “vCenter 2” als zweite “Site” hinzufügen und umgekehrt. Die Konfiguration der Replikation auf VM-Basis erfolgt über das Kontextmenü in der gewohnten Inventory-Sicht. Besonders zu erwähnen ist im Falle von SQL-Datenbankservern die VSS-Funktionalität. Mit dieser lassen sich die Datenbanken zum Zeitpunkt der Replikation in einen konsistenten Zustand versetzten. Der Status und die initiale Synchronisation der eingerichtete Replikation kann dann wieder über das vSphere Replication-Plugin im Webclient begutachtet werden. Nachfolgende Videos sollen die Installation und Konfiguration der Umgebung verdeutlichen. Diese Lösung wurde durch VMware validiert und wird nach der Veröffentlichung eines Whitepapers/KB-Artikel als “supported” gekennzeichnet werden.

Login Passthrough vSphere Web Client 5.1

Durch die Anbindung des vCenter’s an das firmeninterne Active Directory bietet der vSphere Client sowie der vSphere Web Client die Möglichkeit durch setzen der Checkbox “Windows-Sitzungsanmeldedaten verwenden” ein Passthrough der Windows-Anmeldung zur SSO-Komponente zu nutzen. Mit der Version 5.1 bzw. 5.1 U1(a) kann es nun passieren, dass diese Variante der Anmeldung im Web Client nicht mehr funktioniert. Ursache dafür können unzureichende Rechte für das Starten des RSA SSPI-Service  durch den Network Service sein. Um dies zu prüfen, reicht es festzustellen ob im Task-Manager unter Prozesse der Eintrag “sspiservice.exe” aufgeführt wird. Ist dies nicht der Fall, lässt sich das Problem wie folgt behandeln:
  1. im Windows Explorer in das folgende Verzeichnis wechseln:
  2. in das Eigenschaftsmenü des Ordners “windows-x86_64” wechseln
  3. die Rechte des Ordners für den “Netzwerkdienst” bzw. “Network Service” auf “Lesen und Ausführen” bzw. “Read and Execute” setzen, nur lesend ist nicht ausreichend (ggf. muss der Dienst explizit hinzugefügt werden)
  4. der SSPI-Service muss danach neuinstalliert werden mit folgendem Kommando: der Port kann aus folgenden Datei entnommen werden:
Der SSPI-Service sollte danach automatisch gestartet werden und der Login mittels Passthrough funktionieren.

vCenter Update Manager 5.1 U1(a) und das signierte Zertifikate-Problem

Es gibt mehrere Fallstricke, wenn man die VMware Installer-Zertifikate durch intern oder öffentlich signierte austauschen möchte. vSphere 5.1 verlangt ein eindeutiges Zertifikat für alle Dienste, wie z. B. vCenter Server, Inventory Service oder Update Manager um die Vertrauensstellung zur SSO-Komponente abzubilden. Alle diese Zertifikate können mit dem VMware SSL Certificate Automation Tool ( oder auf dem manuellen Weg ausgetauschet werden. Stellen Sie auf jeden Fall sicher, dass Sie die Version 1.0.1 des Tools einsetzen, welches zahlreiche Fehlerbereinigungen enthält. Vor dem Austausch der ersten Zertifikate sollte der integrierte Steps Planner ausgeführt werden, der eine detaillierte Liste der nötige Schritte erstellt und ausgibt. Das Austauschen des Update Manager-Zertifikats ist dabei der letzte Schritt. Wenn Sie alle Schritte des Plans korrekt ausführen und die verwendeten Zertifikate den Vorgaben von VMware entsprechen, sollte der Austausch leicht von der Hand gehen. Meldet man sich nun erfolgreichem Austausch des Zertifikats des Update Managers am vSphere Web Client an und wechselt auf den “Monitor” und “Update Manager”-Tab eines Clusters oder Hosts erhält man folgende Meldung: vum Hinweis: Seit vSphere 5.1 U1 existiert ein vSphere Web Client Plugin mit dem sich Baselines zu Hosts und Clustern zuordnen lassen und sich diese Objekte auf neue Updates scannen lassen.  Nach dem Login über den Web Client lassen sich mehrere Fehler mit dem Text “SSL handshake errors” im Log des Update Managers finden. Diese gelten nur für den Web Client. Ausführen von Funktionen mit dem Update Manager im vSphere Client lösen keinerlei SSL-Fehler aus. Parallele Tests die Zertifikate mittels des VMwareUpdateManagerUtility.exe auszutauschen, verliefen ebenfalls erfolgreich, jedoch verschwinden die Fehlermeldungen nicht aus dem Log-File. VMware  arbeitet zur Zeit an einer Lösung. Ich hoffe, dass Sie relativ schnell einen Hotfix bzw. ein Update für das Problem herausbringen. Bis dahin sind folgende Workarounds möglich: 1. Neuregistrieren des Update Managers mit dem vCenter Server. Dies hilft nicht bei allen Kunden, aber bei einigen (Information von VMware). Das VMwareUpdateManagerUtility.exe kann im Programm Ordner des Update Managers gefunden werden. vum_utility 2. Deaktivieren des Update Manager Web Client Plugins. Melden Sie sich dazu am Web Client mit dem SSO admin (admin@System-Domain) an und wechseln Sie zu  “Administration” und “Plugin Management” und deaktivieren Sie über das Kontextmemü das entsprechende Plugin. Nach einem erneuten Login sind alle Update Manager Widgets verschwunden. Von hier an, kann der Update Manager nur noch vom vSphere Client gesteuert werden. Das Plugin kann auch auf dem selben Weg auch wieder aktiviert werden. vum_webclient