TPM Modell ändern

Jun 4, 2020
5
0
41
46
Guten Tag in die Runde,

wir haben das Problem, das unsere Windows VMs Intune nicht joinen können.
Wir bekommen die Fehlermeldung 0x800705b4 in der Windows VM.
Bei Recherchen hab ich folgendes gefunden:

800705B4 : Dieser allgemeine Fehler weist auf ein Timeout hin.
Eine häufige Ursache für diesen Fehler im Selbstbereitstellungsmodus ist, dass das Gerät nicht TPM 2.0-fähig ist.
Beispielsweise handelt es sich um einen virtuellen Computer.
Geräte, die nicht TPM 2.0-fähig sind, können nicht mit dem Selbstbereitstellungsmodus verwendet werden.
Link: https://learn.microsoft.com/de-de/autopilot/known-issues


Im englischen Forum hab ich folgenden Beitrag gefunden:
Dort hab ich keine funktionierende Lösung gefunden.


In meiner lokalen Windows VM mit Virt-manager hatte ich nicht das Problem.
Also hab ich mir den Qemu Aufruf von Proxmox und der Virt-Manager angeschaut und verglichen:
Proxmox nutzt TPM-tis und der Virt-Manager nutzt TPM-crb.
Da ich bei Proxmox das TPM-Modell nicht ändern konnte, hab ich im Virt-manager das TPM-Modell auf tis umgestellt.
Dann kommt in der Windows VM die gleiche Fehlermeldung wie in der Proxmox VM.

Deswegen gehe ich davon aus es am TPM-Modell liegt.
Weiß einer ob es möglich ist das TPM-Modell in Proxmox 9.2.4 zu ändern und wenn ja wie?
 
Hi,
Ohne Code-Änderung geht das nicht. Das TPM-Modell wird in PVE/QemuServer/TPM.pm festgelegt und außer der Version gibt es für den Aufruf von QEMU auch keinen anderen übergebenen Parameter.
 
Guten Tag in die Runde,

wir haben das Problem, das unsere Windows VMs Intune nicht joinen können.
Wir bekommen die Fehlermeldung 0x800705b4 in der Windows VM.
Bei Recherchen hab ich folgendes gefunden:

800705B4 : Dieser allgemeine Fehler weist auf ein Timeout hin.
Eine häufige Ursache für diesen Fehler im Selbstbereitstellungsmodus ist, dass das Gerät nicht TPM 2.0-fähig ist.
Beispielsweise handelt es sich um einen virtuellen Computer.
Geräte, die nicht TPM 2.0-fähig sind, können nicht mit dem Selbstbereitstellungsmodus verwendet werden.
Link: https://learn.microsoft.com/de-de/autopilot/known-issues slope game


Im englischen Forum hab ich folgenden Beitrag gefunden:
Dort hab ich keine funktionierende Lösung gefunden.


In meiner lokalen Windows VM mit Virt-manager hatte ich nicht das Problem.
Also hab ich mir den Qemu Aufruf von Proxmox und der Virt-Manager angeschaut und verglichen:
Proxmox nutzt TPM-tis und der Virt-Manager nutzt TPM-crb.
Da ich bei Proxmox das TPM-Modell nicht ändern konnte, hab ich im Virt-manager das TPM-Modell auf tis umgestellt.
Dann kommt in der Windows VM die gleiche Fehlermeldung wie in der Proxmox VM.

Deswegen gehe ich davon aus es am TPM-Modell liegt.
Weiß einer ob es möglich ist das TPM-Modell in Proxmox 9.2.4 zu ändern und wenn ja wie?
Wenn der Unterschied zwischen tpm-tis und tpm-crb den Fehler reproduzierbar beeinflusst, klingt das nach einer guten Spur. Ich würde den Sachverhalt auch im Proxmox-Bugtracker melden, da Autopilot und Intune inzwischen häufig genutzt werden und eine Auswahl des TPM-Modells für solche Fälle sinnvoll wäre.
 
Das TPM-Modell ist fest in TPM.pm verdrahtet, wie @fba sagt, ohne Patch änderst du das nicht. Aber tis vs crb ist wahrscheinlich gar nicht dein Problem.

Der Knackpunkt bei Autopilot im Self-Deploying/Pre-Provisioning-Modus ist die TPM-Attestation. Die will ein EK-Zertifikat, das von einem echten TPM-Hersteller signiert und über Microsoft verifizierbar ist. Der swtpm im QEMU hat aber nur ein selbstsigniertes EK, das MS nicht kennt, also läuft die Attestation ins Timeout, egal ob tis oder crb. Daher kriegst du in beiden Fällen den 0x800705b4.

User-driven Autopilot mit Benutzeranmeldung braucht keine TPM-Attestation und läuft auch in VMs. Für Self-Deploying/Pre-Provisioning mit einem virtuellen TPM siehts dagegen schlecht aus, das ist eher eine Windows/Intune-Limitierung als ein PVE-Thema.

Welchen Enrollment-Modus fahrt ihr denn? Und liegen efidisk0 + tpmstate0 auf persistentem Storage (nicht volatile)? Den Punkt aus dem englischen Thread würd ich vorher trotzdem checken.
 
  • Like
Reactions: Johannes S