Problem mit TPM in Windows Server 2025

L

lblaesius

New Member
Proxmox Subscriber
Nov 12, 2024
14
0
1
Hallo,

wir sind bei unserem Cluster auf ein Problem gestoßen. Mit dem neusten Sicherheitsupdate von Microsoft verlieren unsere Windows 2025 RDS Server ihr TPM Modul. TPM.MSC zeigt an, dass kein Modul verbunden wäre. Vor dem Update lief alles normal.

Ich habe mit Hilfe von Claude eine Diagnose gemacht. Diese ist im Anhang.

Kurzgesagt:
- Wir haben 5 AMD Epyc Server die alle identisch sind. Das Problem ist auf allen Hosts.
- Installiert man das Update von Microsoft, startet die VM neu ist das TPM Modul verschwunden
- Die Anmeldung bei Office Anwendungen wird somit blockiert
- Es wurde bereits die neusten Zertifikate eingespielt, TPM und EFI neu generiert und ein in Place Upgrade auf eine neuere ISO von Windows 2025 gemacht

All dies brachte kein Erfolg. Ich bin nun komplett Ratlos und finde im Internet keine vergleichbaren Probleme oder Lösungen.

Ich würde mich über eure Hilfe freuen.

Liebe Grüße,
Luca
 

Attachments

Hi @lblaesius

vielen Dank für deinen Post!

lblaesius said:
- Installiert man das Update von Microsoft, startet die VM neu ist das TPM Modul verschwunden
Click to expand...
Welches Update genau wurde installiert? Die KB Nummer wäre hilfreich, zu finden in der Update Historie in den Einstellungen

Gleichzeitig wäre auch noch interessant ob nach der Deinstallation des Updates das TPM Modul wieder funktioniert.
Ist natürlich keine Dauerlösung aber würde das Update als spezifischen Auslöser identifizieren.

Spannend ist nämlich dass ich bei einem frisch installierten Win Srv 25 mit allen Updates (Build: 26100.33158) aktuell scheinbar keine Probleme mit dem TPM Modul habe.
Das Kommando Get-TPM z.B. was dein KI-Helfer in der Zusammenfassung erwähnt hat funktioniert einwandfrei und gibt unter anderem TpmReady: True zurück.

MfG
Jonas
 
Hi @j.theisen

angefangen hatte es mit der KB5065426 diese wurde dann von uns über unsere Verwaltungsplattform zurückgehalten. Danach haben wir festgestellt, dass die darauffolgenden Sicherheitsupdates auch den gleichen Effekt haben.

Genau, nach einer Deinstallation ist das Modul wieder vorhanden. Betroffen sind bei uns 5 Windows 2025 RDS Server verschiedener Kunden. Wenn wir mit der neusten Version einen Server installieren weißt er auch keine Probleme auf.

Wir müssen nur irgendwie diese Systeme auf den aktuellsten Stand patchen ohne das TPM zu verlieren. Eine Neuinstallation ist mit den ganzen Programmen, Benutzerdaten und Downtime nicht möglich.

Bei uns liefert
Code: 
Get-TPM
vor dem Update das Gleiche und nach dem Update:
Code: 
PS C:\WINDOWS\system32> Get-TPM


TpmPresent                : False
TpmReady                  : False
TpmEnabled                : False
TpmActivated              : False
TpmOwned                  : False
RestartPending            : False
ManufacturerId            : 0
PpiVersion                :
ManufacturerIdTxt         :
ManufacturerVersion       :
ManufacturerVersionFull20 :
ManagedAuthLevel          : Full
OwnerAuth                 :
OwnerClearDisabled        : True
AutoProvisioning          : NotDefined
LockedOut                 : False
LockoutHealTime           :
LockoutCount              :
LockoutMax                :
SelfTest                  :


Grüße Luca
 
Ich hab das hier mal auf meinem Server 2025 getestet. Mit dem letzten Update scheint das TPM hier weiterhin normal zu funktionieren.

pve-manager/9.2.4/5e5ae681198514d4 (running kernel: 7.0.14-6-pve)

Hier noch meine VM-Config:

Code: 
agent: 1
bios: ovmf
boot: order=scsi0;ide0
cores: 8
cpu: x86-64-v2-AES
efidisk0: local-lvm:vm-173-disk-0,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=4M
hotplug: disk,network,usb,memory,cpu
ide0: none,media=cdrom
machine: pc-q35-11.0+pve2
memory: 10240
meta: creation-qemu=9.0.2,ctime=1736270603
net0: virtio=AC:24:34:61:E2:D1,bridge=vlan66,firewall=1
numa: 1
ostype: win11
rng0: source=/dev/urandom
scsi0: local-lvm:vm-173-disk-1,discard=on,iothread=1,size=60G,ssd=1
scsihw: virtio-scsi-single
sockets: 2
tpmstate0: local-lvm:vm-173-disk-2,size=4M,version=v2.0
vga: virtio
 

Attachments

  • tpm-ok-after-update.png
    tpm-ok-after-update.png
    761.5 KB · Views: 11
Wenn ich das PDF richtig gelesen habe, sind die problematischen VMs ursprünglich linked clones gewesen? Ggf. besteht eine Inkosistenz in den Metadaten.

Ich würde mal folgendes testen:

Problem VM runterfahren und sichern. Dann neue VM erstellen mit:
  • neuer VMID
  • neuer SMBIOS-UUID
  • neuer VMGenID
  • neuer EFI-Disk
  • neuem TPM-State
  • gleichem CPU-Typ
  • gleichem Machine-Type
Aber nicht Windows neu installieren, sondern die Systemdisk der gesicherten Problem-VM einhängen und booten lassen.

Dann in Windows:

Get-Tpm tpmtool getdeviceinformation

Wenn TPM funktioniert, liegt es mit Sicherheit an den Metadaten bzw. „historisch gewachsenen Daten“.
 
Das komplette neu erstellen einer VM und einbinden der Systemfestplatte hatte leider keinen erfolg:
Code: 
PS C:\WINDOWS\system32> Get-Tpm


TpmPresent                : False
TpmReady                  : False
TpmEnabled                : False
TpmActivated              : False
TpmOwned                  : False
RestartPending            : False
ManufacturerId            : 0
PpiVersion                :
ManufacturerIdTxt         :
ManufacturerVersion       :
ManufacturerVersionFull20 :
ManagedAuthLevel          : Full
OwnerAuth                 :
OwnerClearDisabled        : True
AutoProvisioning          : NotDefined
LockedOut                 : False
LockoutHealTime           :
LockoutCount              :
LockoutMax                :
SelfTest                  :



PS C:\WINDOWS\system32> tpmtool getdeviceinformation
Fehler beim Abrufen der Informationen.
Befehl mit 0x800710df fehlgeschlagen - Das Gerõt kann nicht verwendet werden.
PS C:\WINDOWS\system32>


Hier ist meine VM Config:
Code: 
bios: ovmf
boot: order=ide2;net0
cores: 8
cpu: x86-64-v2-AES
efidisk0: pool_ez_vm:vm-256-disk-0,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=1M
ide2: none,media=cdrom
machine: pc-q35-11.0
memory: 8192
meta: creation-qemu=11.0.0,ctime=1785408954
name: RDSNoTPM2
net0: e1000=BC:24:11:C7:98:D0,bridge=v12001,firewall=1,tag=10
numa: 0
ostype: win11
scsi0: pool_vm:vm-256-disk-0,cache=writeback,discard=on,iothread=1,size=175G
scsihw: virtio-scsi-single
smbios1: uuid=23578a2c-24dc-4364-973a-3b3e77a36c21
sockets: 1
tags: 12001_merios;zWindows2025
tpmstate0: pool_ez_vm:vm-256-disk-1,size=4M,version=v2.0
vmgenid: 949064b5-c615-48ad-ad36-9e54950e970e
 
Dann würde ich noch folgendes testen: in der „Test-VM“ das TPM entfernen:

pnputil /remove-device "ACPI\MSFT0101\1"

VM herunterfahren. tpmstate0 aus der VM löschen, einmal ohne TPM starten und wieder herunterfahren. Neues TPM hinzufügen und nach dem Hochfahren testen:

Get-Tpm tpmtool getdeviceinformation
 
Ich habe das alles getestet, jedoch kommt weiterhin der gleiche Fehler.

Ich werde nun mal noch im Microsoft Forum posten. Hoffentlich gibt es noch eine Lösung für dieses Problem.
Eine Neuinstallation von 7 Servern würde ich nur ungern in Betracht ziehen.

Ich habe mal noch die neusten Erkenntnisse angehangen.

Grüße,
Luca
 

Attachments

Spannend ist für mich vor allem, dass eine komplett neue VM mit frischem TPM-State plus der alten Systemdisk trotzdem failt, eine Neuinstallation mit demselben ISO aber sauber läuft. Das Problem liegt also in der Windows-Installation, nicht in der vTPM auf PVE-Seite. Bei @fireon steht ja auch ManufacturerIdTxt: IBM (der swtpm), bei dir ist ManufacturerId: 0 und alles leer, Windows sieht das Gerät also gar nicht mehr, egal welche vTPM du drunterlegst.

Die betroffenen Kisten waren ja wohl mal linked clones. Kommen die alle aus einem gemeinsamen Golden Image? Falls das Image damals nicht sauber sysprepped wurde, schleppen die alle den gleichen maschinenspezifischen State mit, und das erklärt, warum bei dir alle 5 ausfallen und bei anderen mit frischem Setup nichts passiert.

Zwei Sachen die ich checken würde: einmal auf dem Host dpkg -l | grep -E 'swtpm|libtpms' und die Versionen mit einem Host/Setup vergleichen wo Get-TPM nach dem Update noch läuft. Und in Windows im Event Viewer unter Microsoft-Windows-TPM-WMI schauen, was genau beim Start am TPM schiefgeht, 0x800710df von tpmtool ist nur "device cannot be used", das Log ist da meist konkreter. Was steht denn im Geräte-Manager am TPM-Eintrag, gelbes Ausrufezeichen mit Code, oder taucht es gar nicht mehr auf?
 
  • Like
Reactions: fireon and ThoSo
Was mir mal so ins Auge fällt:
@fireon - Konfig
agent: 1
cores: 8
cpu: x86-64-v2-AES
numa: 1
sockets: 2
net0: virtio

@lblaesius - Konfig:
cores: 8
cpu: x86-64-v2-AES
numa: 0
sockets: 1
net0: e1000

Braucht man eigentlich das TPM beim RDS Server 2025 unbedingt - oder ginge es auch ohne?
 
Last edited:
ThoSo said:
Was mir mal so ins Auge fällt:
@fireon - Konfig
agent: 1
cores: 8
cpu: x86-64-v2-AES
numa: 1
sockets: 2
net0: virtio

@lblaesius - Konfig:
cores: 8
cpu: x86-64-v2-AES
numa: 0
sockets: 1
net0: e1000

Braucht man eigentlich das TPM beim RDS Server 2025 unbedingt - oder ginge es auch ohne?
Click to expand...

Sollte normalerweise keine Auswirkung darauf haben wie Windows das TPM erkennt. Wäre ja fatal, wenn die Netzwerkkarte das TPM blockt. Aber Testen schadet ja grundsätzlich nicht.

Windows Server 2025 läuft auch ohne TPM, wenn man es nach der Installation entfernt. Wäre blöde, wenn man bei einem TPM failed den Server nicht mehr hochbekommen würde. Ob TPM für RDS 2025 Voraussetzung ist, kann ich dir nicht sagen. Aber Microsoft sagt in seinen Systemanforderungen definitiv, dass ein TPM Pflicht ist.
Wenn RDS noch ohne TPM auf 2025 funktioniert, dann ist es vermutlich nur eine Frage der Zeit wann dies auch eine Policy von Microsoft sein wird. Aber da bin ich nicht tief genug drinnen, das ich solch eine Behauptung aufstellen könnte.
 
Wenn ich das bei MS in den Anforderungen jetzt richtig gelesen habe, wird das TPM im Server auch nur für Bitlocker benötigt. Ich lese da auch nichts von Pflicht - "other Requirements - The following items are required only for certain features"

ich bin auch der Meinung, was ich in einer VM nicht zwingend benötige, kommt erst gar nicht rein, und kommt beim erstellen gleich raus.


update: außer (da hast du dann Recht mit der Pflicht) wenn ich einen SECURED-Core Server betreibe - was eine Variante wäre.
 
Last edited:
Ohne TPM läuft Server 2025 schon, das stimmt. Nur löst das @lblaesius' eigentliches Problem nicht, weil bei ihm ja die Office-/Entra-Anmeldung hängt und die läuft über TPM-gebundene Device-Keys. Wenn das TPM verschwindet, passen die hinterlegten Keys nicht mehr und der Login fliegt raus, egal ob das TPM formal Pflicht ist oder nicht. Wäre spannend was dsregcmd /status nach dem Update sagt, und ob ein Leave/Rejoin (Keys werden dann neu erzeugt, im Zweifel in Software) die Anmeldung wieder hinbekommt. Das wäre ein Workaround, bis die Ursache klar ist.

numa, sockets und e1000 vs virtio haben mit der TPM-Erkennung nichts zu tun, da bin ich bei @fireon. Was mir beim Vergleich aufgefallen ist: bei @fireon steht machine: pc-q35-11.0+pve2, bei dir nur pc-q35-11.0. Bin mir nicht sicher ob das am ACPI-Tisch für MSFT0101 was ändert, aber testen kostet nix. Was mich noch interessiert: was sagt der Event Viewer unter TPM-WMI beim Boot, und taucht das Gerät im Geräte-Manager noch mit Fehlercode auf oder ist es komplett weg?
 
  • Like
Reactions: ThoSo
Ich habe die config auch schon auf die gleichen Werte wie @fireon gesetzt und getestet. Es hat allerdings keinen Unterschied gemacht.

Wenn ich den Befehl
Code: 
dpkg -l | grep -E 'swtpm|libtpms'
auf unseren Hosts ausführe, liefern alle das gleiche Ergebnis:
Code: 
root@prox02:~# dpkg -l | grep -E 'swtpm|libtpms'
ii  libtpms0:amd64                       0.9.7+pve2                           amd64        TPM emulation library
ii  swtpm                                0.8.0+pve3                           amd64        Libtpms-based TPM emulator
ii  swtpm-libs:amd64                     0.8.0+pve3                           amd64        Common libraries for TPM emulators
ii  swtpm-tools                          0.8.0+pve3                           amd64        Tools for the TPM emulator
root@prox02:~#

In unserem Fall befinden sich funktionierende und nicht funktionierende VM´s (in Bezug auf das TPM) auf dem gleichen Host.

Die Windows Ereignisanzeige gibt folgenden Fehler:

Code: 
Integritätsprüfungen vor dem Nachweis bestätigen, dass eine kritische Komponente fehlgeschlagen ist und dass das Gerät nicht den Nachweis bestehen soll.
 Ausführliche Informationen zu den durchgeführten Überprüfungen finden Sie in C:\WINDOWS\Logs\MeasuredBoot\0000000005-0000000000.json.

C:\WINDOWS\Logs\MeasuredBoot\0000000005-0000000000.json:
Code: 
{"Version":2,"HealthStatus":"Cannot be attested","Required":[{"Field":"TpmPresent","Value":true,"DesiredValue":true},{"Field":"TpmMeetsMinimumVersion","Value":true,"DesiredValue":true},{"Field":"TpmIsResponsive","Value":true,"DesiredValue":true},{"Field":"EkCertIsAvailable","Value":false,"DesiredValue":true},{"Field":"TcgLogFound","Value":true,"DesiredValue":true}],"Expected":[{"Field":"PcrsMatchTcgLog","Value":true,"DesiredValue":true}],"Informational":[{"Field":"SecureBootEnabled","ValueFromComputer":true,"ValueFromTcgLog":true,"DesiredValue":true,"TcgValueIsVerifiable":true},{"Field":"VirtualSecureMemory","ValueFromComputer":false,"ValueFromTcgLog":false,"DesiredValue":true,"TcgValueIsVerifiable":true},{"Field":"SecureCorePCCompliant","ValueFromComputer":false,"ValueFromTcgLog":false,"DesiredValue":true,"TcgValueIsVerifiable":true},{"Field":"MostRecentBootTcgLogFoundInFileSystem","Value":true,"DesiredValue":true},{"Field":"CurrentTcgLogFoundInFileSystem","Value":true,"DesiredValue":true},{"Field":"EkCertRsa2048IsAvailable","Value":false,"DesiredValue":true},{"Field":"EkCertEccP256IsAvailable","Value":false,"DesiredValue":true},{"Field":"EkCertEccP384IsAvailable","Value":false,"DesiredValue":true},{"Field":"WindowsAikCertRsa2048IsAvailable","Value":false,"DesiredValue":true},{"Field":"WindowsAikCertEccP256IsAvailable","Value":false,"DesiredValue":true},{"Field":"WindowsAikCertEccP384IsAvailable","Value":false,"DesiredValue":true}]}

Im Gerätemanager wird folgendes angezeigt:

Screenshot 2026-08-07 143250.png

Ich habe als Machiene Type nur Folgende zur Auswahl. Ich weiß leider nicht warum manche "+pve" haben und manche nicht.

Screenshot 2026-08-07 143345.png
 
Oh interessant, laut dem log fehlt das EK Zertifikat.

Auch wenn du das TPM Modul während dem Troubleshooting schonmal neu erstellt hast würde ich das gerne manuell nochmal probieren.
Disclaimer: Das folgende Kommando ist destruktiv für den aktuellen TPM Stand. Benutzung auf eigene Gefahr!
Code: 
swtpm_setup --tpmstate file://<tpm-disk> --createek --create-ek-cert --create-platform-cert --lock-nvram --config /etc/swtpm_setup.conf --runas 0 --overwrite

Statt <tpm-disk> muss entsprechend der Pfad zur Disk des TPM Moduls eingesetzt werden.
Hieße für die VM aus deiner LLM Zusammenfassung z.B:
VM herunterfahren, dann das LVM Volume aktivieren und diesen File Parameter in das obige Kommando einsetzen
Code: 
lvchange -ay /dev/pool_vm/vm-216-disk-2
file:///dev/pool_vm/vm-216-disk-2

Sollten hier irgendwelche Fehler auftreten bitte gerne posten.

MfG und schönes Wochenende!
Jonas

Den Output einmal schön geparsed:
JSON: 
{
  "Version": 2,
  "HealthStatus": "Cannot be attested",
  "Required": [
    {
      "Field": "TpmPresent",
      "Value": true,
      "DesiredValue": true
    },
    {
      "Field": "TpmMeetsMinimumVersion",
      "Value": true,
      "DesiredValue": true
    },
    {
      "Field": "TpmIsResponsive",
      "Value": true,
      "DesiredValue": true
    },
    {
      "Field": "EkCertIsAvailable",
      "Value": false,
      "DesiredValue": true
    },
    {
      "Field": "TcgLogFound",
      "Value": true,
      "DesiredValue": true
    }
  ],
  "Expected": [
    {
      "Field": "PcrsMatchTcgLog",
      "Value": true,
      "DesiredValue": true
    }
  ],
  "Informational": [
    {
      "Field": "SecureBootEnabled",
      "ValueFromComputer": true,
      "ValueFromTcgLog": true,
      "DesiredValue": true,
      "TcgValueIsVerifiable": true
    },
    {
      "Field": "VirtualSecureMemory",
      "ValueFromComputer": false,
      "ValueFromTcgLog": false,
      "DesiredValue": true,
      "TcgValueIsVerifiable": true
    },
    {
      "Field": "SecureCorePCCompliant",
      "ValueFromComputer": false,
      "ValueFromTcgLog": false,
      "DesiredValue": true,
      "TcgValueIsVerifiable": true
    },
    {
      "Field": "MostRecentBootTcgLogFoundInFileSystem",
      "Value": true,
      "DesiredValue": true
    },
    {
      "Field": "CurrentTcgLogFoundInFileSystem",
      "Value": true,
      "DesiredValue": true
    },
    {
      "Field": "EkCertRsa2048IsAvailable",
      "Value": false,
      "DesiredValue": true
    },
    {
      "Field": "EkCertEccP256IsAvailable",
      "Value": false,
      "DesiredValue": true
    },
    {
      "Field": "EkCertEccP384IsAvailable",
      "Value": false,
      "DesiredValue": true
    },
    {
      "Field": "WindowsAikCertRsa2048IsAvailable",
      "Value": false,
      "DesiredValue": true
    },
    {
      "Field": "WindowsAikCertEccP256IsAvailable",
      "Value": false,
      "DesiredValue": true
    },
    {
      "Field": "WindowsAikCertEccP384IsAvailable",
      "Value": false,
      "DesiredValue": true
    }
  ]
}
 
Hallo Jonas,

der Befehl hat bei mir folgenden Output geliefert. Das TPM Modul ist aber immer noch wie vorher beschrieben bei tpm.msc nicht zu sehen.

Code: 
root@prox01:~# rbd map ez_pool_vm_metadata/vm-256-disk-1
/dev/rbd6
root@prox01:~# swtpm_setup --tpmstate file:///dev/rbd6 --createek --create-ek-cert --create-platform-cert --lock-nvram -
-config /etc/swtpm_setup.conf --runas 0 --overwrite
Starting vTPM manufacturing as root:root @ Mon 10 Aug 2026 03:34:54 PM CEST
TPM is listening on Unix socket.
swtpm: Formatting 'file:///dev/rbd6' as new linear NVRAM store
Successfully created EK.
  Invoking /usr/bin/swtpm_localca --type ek --ek ab47eeaf4d0c21529bd325eb98a15cfcae7b266b32248e6d71b97c850e937b2b47f808ab399c35fa50e442278bab512b71e33323504362c0fb9f11ea592315b8baf282514b06c241105d4b14349c42cec44e2e4eae6cd60172cc2402e71bf5db85b5e89bf43a39cc02f159b9877682fcbce3059e0c4e551319cce25d7c328d2c85761fb9844402473199d09545ba36242c0471476716d184a7c1a7893eff2407703a693e2fcd471aa224db6e7321938e6d8cf806bad4c351892472a44a4efc908a9d930d6f5270c43c50f8e9189284ce8be108c1ee2d8f4b0944064d1cc89f9b78d70585f45446f199553111c6de2a84618f0aa410ebf5597137bcc1c4857f39 --dir /tmp/swtpm_setup.certs.Q0IST3 --tpm-spec-family 1.2 --tpm-spec-level 2 --tpm-spec-revision 116 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:00740001 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
swtpm_localca: Successfully created EK certificate locally.
  Invoking /usr/bin/swtpm_localca --type platform --ek ab47eeaf4d0c21529bd325eb98a15cfcae7b266b32248e6d71b97c850e937b2b47f808ab399c35fa50e442278bab512b71e33323504362c0fb9f11ea592315b8baf282514b06c241105d4b14349c42cec44e2e4eae6cd60172cc2402e71bf5db85b5e89bf43a39cc02f159b9877682fcbce3059e0c4e551319cce25d7c328d2c85761fb9844402473199d09545ba36242c0471476716d184a7c1a7893eff2407703a693e2fcd471aa224db6e7321938e6d8cf806bad4c351892472a44a4efc908a9d930d6f5270c43c50f8e9189284ce8be108c1ee2d8f4b0944064d1cc89f9b78d70585f45446f199553111c6de2a84618f0aa410ebf5597137bcc1c4857f39 --dir /tmp/swtpm_setup.certs.Q0IST3 --tpm-spec-family 1.2 --tpm-spec-level 2 --tpm-spec-revision 116 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:00740001 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
swtpm_localca: Successfully created platform certificate locally.
Successfully created NVRAM area for EK certificate.
Successfully created NVRAM area for Platform certificate.
Successfully locked NVRAM access.
Successfully authored TPM state.
Ending vTPM manufacturing @ Mon 10 Aug 2026 03:34:54 PM CEST
root@prox01:~# rbd unmap /dev/rbd6
root@prox01:~# qm start 256

Grüße,
Luca
 
You must log in or register to reply here.
Top Bottom
Back