Virtual Trusted Platform Module (vTPM) auf ESXi ohne vCenter Server hinzufügen

Bereits ab vSphere 6.7 kann man ein virtuelles Trusted Platform Module (vTPM) zu VM Gästen hinzufügen. Damit können Gastbetriebssysteme ihre privaten Schlüssel in einem „physischen“ (meint: VM-Hardware) TPM 2.0-Chips erstellen und speichern. Für den Gast ist das vollständig transparent, dieser kann nicht feststellen das er nicht mit einem „echten“ TPM spricht.

Der wesentliche Vorteil von vTPM ist, dass im ESXi-Host kein physischer TPM-Chip eingebaut sein muss. Server-TPMs sind ja auch nicht gerade günstig. Die Secrets aus dem vTPM wiederum werden (verschlüsselt) in der .nvram Datei des ESXi zu jeder VM einzeln und lokal abgelegt.

Die Verschlüsselungsschlüssel für das vTPM selbst wird von einem „Schlüsselanbieter“ verwaltet. Das kann ein externer (KMIP) Key Provider (SKP) oder der im vCenter integrierte Native Key Provider (NKP) sein. Die (zentrale) Verwaltung der Schlüsselanbieter erfordert aber eigentlich immer den Einsatz des vCenters. Windows 11 auf einem ESX-Standalone Host als Gast zu betreiben ist also eigentlich nicht möglich.

Interessanterweise nutzt das vCenter zur Verwaltung nur public vSphere-APIs, die auf ESXi-Hosts verfügbar sind um Schlüssel hinzuzufügen oder zu entfernen. Die Funktionen zur Verwaltung der Schlüssel ist aber ESXi Bestandteil. Das bedeutet, man kann das auch manuell machen: nicht so komfortabel wie ein vCenter Server, aber trotzdem vTPM für VMs auf eigenständigen (Standalone) ESXi-Hosts.

vSphere Master Willian Liam hat dazu einen fantastischen Artikel geschrieben und ein PowerShell-Script erstellt, das einem den Großteil der Arbeit abnimmt.

vTPM auf einem ESXi Host aktivieren, ohne Neustart

⚠️ Wichtig: Nach dieser Prozedur starten VMs nach einem ESX Reboot nicht mehr. Man muss sich um die Schlüsselpersistenz der TPM-Keys selbst kümmern (siehe weiter unten).

  1. vmWare PowerCli Module installieren und importieren, sofern noch nicht geschehen:
    Install-Module VMware.PowerCLI
    Import-Module VMware.PowerCLI
  2. Herunterladen: vTPMStandaloneESXiFunctions.ps1 (lokaler Mirror) und das neue Script im aktuellen Verzeichnis „dot sourcen“:
    . .\vTPMStandaloneESXiFunctions.ps1
  3. PowerCLI mit dem ESXi-Host verbinden:
    Connect-VIServer -Server ESX.EXAMPLE.COM
  4. Den TPM-Provider einrichten, also den lokalen Host für den Anbieter vorbereiten:
    Prepare-VMHostForEncryption
  5. Einen ESXi Hostschlüssel erzeugen:
    New-InitialVMHostKey -Operation CREATE -KeyName "esx10-key-1"
    ⚠️ Diesen Vorgang nur ein einziges Mal durchführen!
  6. vTPM Schlüssel für VMs erstellen:
    New-VMTPMKey -Operation CREATE -KeyName "windows-11-key"
  7. Und endlich kann man das vTPM zu den VMs (jeweils einzeln) hinzufügen:
    Reconfigure-VMWithvTPM -KeyName "windows-11-key" -VMName "EXAMPLE-VM"

⚠️ Schlüsselpersistenz – Schlüssel nach (ESX-) reboots wiederherstellen

Standardmäßig speichert ESXi leider keine Verschlüsselungsschlüssel über einen Neustart hinweg. Man muss alle Host- und VM-Schlüssel nach einem Neustart erneut hinzufügen, sonst lässt sich eine solche VM nicht mehr starten.

Dies ist der Hauptvorteil des vCenters: Das Management des SKP (oder NKP) und der bereitgestellten Schlüssel für die ESXi-Hosts und VMs.

Als Workaround gibt es eine „automatische“ Sicherung der Verschlüsselungsschlüssel im Script. Das CSV-Backup wird bei der Generierung von Host- oder VM-Schlüsseln erstellt. Die Datei heißt tpm-keys.csv und sollte DRINGEND gut gesichert abgelegt werden Mit dieser Sicherungsdatei kann man alle Schlüssel (nach reboots) problemlos wieder auf den ESXi-Host importieren.

Wenn man über einen echten physischen TPM2.0 Chip verfügt (FIFO Modus, nicht CRB – bei HPE-Servern im BIOS umstellen!), kann man die „Schlüsselpersistenz“ im ESXi aktivieren. Damit werden die Schlüssel automatisch auf dem TPM-Chip gespeichert.

Wenn man keinen physischen TPM Chip hat, muss man sicherstellen, dass die Sicherungskopie der Host- und VM Schlüssel vorhanden ist. Nach dem Reboot kann man diese einfach wieder importieren. Man verbindet sich mit dem Host (siehe oben) und importiert die CSV wieder:

Prepare-VMHostForEncryption

New-InitialVMHostKey -Operation IMPORT -KeyName "esx-key-1" -CSVTPMKeyFile tpm-keys.csv

New-VMTPMKey -Operation IMPORT -KeyName "windows-11-key" -CSVTPMKeyFile tpm-keys.csv

Den Erfolgt des Imports kann man jederzeit mit Get-VMHostTPMKeys kontrollieren.

🆘Hinweis zu Windows 11, wenn es nicht mehr bootet

Wenn eine Windows 11 VM nicht mehr neu starten sollte, weil man kein Backup der Schlüssel mehr hat:

  • VM aus der Bestandsliste entfernen (de-registrieren)
  • Die VMX Datei der VM manuell bearbeiten
    • Alle Zeilen, die mit dem vTPM zu tun haben löschen:
      vtpm.ekCSR
      vtpm.ekCRT
      vtpm.present
      encryption.keysafe
      encryption.data
  • Dann die VM (*.vmx) erneut zur Bestandsliste hinzufügen

Die VM hat dann zwar eine neue ID bekommen und muss (wahrscheinlich) erneut zur Datensicherungslösung hinzugefügt werden, bootet aber wieder problemlos.

SFirm Fernwartung zulassen (schwarzer Bildschirm)

Ein guter alter Begleiter im IT-Alltag ist SFirm, das Banking-Programm der Sparkassen.

Ehrlicherweise ist das eines der deutlich besseren Tools dieser Klasse – und in aller Regel mit herausragendem Support gesegnet. Alleine das SFirm (SFirm32) ist manchmal ein Grund, bei der Sparkasse als Hausbank zu bleiben. Wir sind Admins, wir mögen abgehangene und gut dokumentierte Software. Wir mögen stabile Prozesse. Die Sparkasse auch.

Problem

In einer Support Remotesitzung (z.B. Windows-Remotehilfe, RustDesk, Anydesk, Teamviewer oder ähnliches) wird statt des SFirm-Fensters nur ein schwarzer Bildschirm angezeigt. Genauer: Ein schwarzes SFirm-Fenster, der Rest ist sichtbar. Außerdem sind keine Screenshots oder Aufzeichnungen möglich.

Prinzipiell eine nette Idee um ungewollte Beobachter auszusperren, aber manchmal beim Support hinderlich.

Lösung

Screenshots oder Bildschirmübertragungen von SFirm kann der ausführende Benutzer (kein Admin nötig) mit Tastenkombinationen zulassen. Wenn die Kombination erfolgreich ist, muss der Benutzer die Funktion mit seinem Kennwort freischalten.

Möglich sind (je nach Version):

  • STRG + F2
  • STRG + F8
  • STRG + F12

Windows 11 automatische Neustarts (Reboot) verhindern

Windows 11 startet im „Normalfall“ nach Fehlern (und Installationsfehlern bei Windows-Updates) automatisch den Computer neu. Irritierenderweise startet der Computer auch neu, wenn man „Update installieren und Herunterfahren“ auswählt, aber das ist ein anderes Thema.

Möchte man die automatischen Fehler-Reboots verhindern, bleiben eigentlich nur die Gruppenrichtlinien. Hat man grade keine Domäne oder GPEDIT zur Hand, tut es diese Pro-Maschine einstellung:

  • Einstellungen öffnen (Win+I)
  • Links auf „System“ > in der Mitte auf „Info“ > Erweiterte Systemeinstellungen
    • Bis 25H2 konnte dieses Fenster noch mit Win+Pause geöffnet werden
  • In diesem Fenster („Systemeigenschaften“) auf den Tab „Erweitert“ wechseln
  • Unten im Abschnitt „Starten und Wiederherstellen“ auf den Button „Einstellungen“
  • Das Kontrollkästchen „Automatisch Neustart durchführen“ entfernen

Ebenso irritierend ist, dass diese Einstellung erst nach einem Reboot aktiv wird …

Windows Server NAT (RRAS) umgeht die Windows Firewall?

Ab und an betreibt noch jemand Windows Server mit der „Routing und RAS“ Rolle als Router mit NAT. Obwohl Microsoft’s Implementierung der IPv6 NAT grundsätzlich einige Limitierungen mitbringt, schätzen manche Admins die Stabilität und Zuverlässigkeit der integrierten Lösung.

Aus gegebenem Anlass sei hiermit darauf hingewiesen, dass die NAT-Implementierung unter Windows Server 2003-2025 (und vermutlich folgende) die Windows-Firewall vollständig ignoriert. Regeln auf der ein- wie ausgehenden gehenden Seite werden nicht angewendet, Pakete werden nicht abgelehnt.

Warum ist das so?

Ein Bekannter hatte wegen irritierender Effekte in einer solchen Kombination ein Ticket bei Microsoft geöffnet. Es kam diese offizielle Auskunft zurück:

This behavior is a known limitation in Windows Server NAT configurations. The NAT service, especially when configured via RRAS (Routing and Remote Access Service), can bypass Windows Firewall rules under certain conditions. This is because NAT operates at a lower level in the networking stack and may use legacy interfaces that do not fully integrate with the Windows Filtering Platform (WFP), which the firewall relies on.

Selbstverständlich ist das sonst nirgends dokumentiert und kommt auch in den „learn“ Artikeln zu RRAS, NAT und Windows-Firewall nicht vor.

Windows 11 nervige „Erinnerung“ zum Microsoft-Konto abschalten

Nach gefühlt jedem Update und bei jeder passenden und unpassenden Gelegenheit nervt Windows mit der „Erinnerung“ doch endlich ein Microsoft-Konto einzurichten und den Konzern über die Anmeldung am eigenen Gerät bestimmen zu lassen. Bekanntlich will das niemand und die ständige Nachfragerei ist schon fast ärgerlicher als Werbung auf Youtube.

Lösung: Abschalten der Hinweise und Erinnerungen

Glücklicherweise ist das Abschalten dieser Eigenarten schnell erledigt:

Einstellungen-App > System > Benachrichtigungen (oder ms-settings:notifications)
Unten die Kategorie „Zusätzliche Einstellungen“ erweitern, alle Kästchen deaktivieren.

Je nach Windows-Version (hier 24h2) gibt es mehr oder weniger Auswahlmöglichkeiten.

Mehr Details

Wenn Windows „Sie „in drei Tagen“ erneut fragen möchte, kann man das direkt in der Aufgabenplanung deaktivieren. In der Aufgabenplanungsbibliothek gibt es dann eine Aufgabe, die (aktuell) „PostponeDeviceSetupToast [..]“ heißt. Der Trigger dieser Aufgabe ist (überraschend) auf alle drei Tage eingestellt. Wenn man diese Aufgabe löscht, gibt es die Erinnerung auch nicht mehr.