Generischer Fehler in der „Joining Network“

Question

Ich habe einen brandneuen Laptop, der sich weigert, unserem Tenant beizutreten. Ich habe den Hash, die Benutzerlizenz und den MDM-Scope überprüft – alles ist perfekt. Dennoch schlägt der Vorgang in der Phase „Joining Network“ mit einem generischen Fehlercode fehl. Ich kann einen anderen Laptop aus derselben Charge nehmen und dort funktioniert es. Gibt es ein „verstecktes“ Log oder eine Hardware-Eigenart, die ich übersehe?

Answer 1

Hallo Reil,

Das von Ihnen identifizierte Diagnoseziel ist korrekt, aber Sie müssen sich speziell auf den ManagementService-Kanal im ModernDeployment-Diagnostics-Provider-Log für das spezifische Ausfallereignis konzentrieren. Obwohl der generische Fehler während der Joining Network Phase frustrierend ist, überdeckt er oft eine Auszeit oder einen Fehlschlag beim kryptografischen Handshake. Du kannst den vollständigen Zustand erfassen, indem du mit Shift+F10 eine Eingabeaufforderung öffnest und mdmdiagnosticstool.exe -area Autopilot ausführst; TPM -zip c:\users\public\AutopilotLogs.zip documents\ bietet einen detaillierten Überblick über den Registrierungsstatus und etwaige zugrundeliegende 0x800705b4 Fehler, die auf eine Auszeit hinweisen.

Die Hardware-Besonderheit, die oft in identischen Chargen übersehen wird, ist ein TPM-Attestations-Timeout. Selbst wenn die Hardware neu ist, muss das TPM seine Identität erfolgreich gegenüber der Microsoft Entra-ID und den Intune-Diensten nachweisen. Wenn das TPM im "Bereit"-Zustand ist, aber der Endorsement-Schlüssel nicht richtig registriert ist oder die Uhr nicht synchron mit dem Attestationsserver ist, schlägt der Join fehl. Du solltest versuchen, das Modul zurückzusetzen, indem du die tpm.msc-Konsole ausführst und die Option TPM löschen auswählst, oder indem du das Clear-TPM-CMDLET in PowerShell verwendest. Dies erzwingt eine Neuinitialisierung des Sicherheitshandschlags.

Wenn die obige Antwort deine Frage beantwortet, klicke bitte auf "Antwort akzeptieren", damit andere in der Community mit ähnlichen Problemen leicht die Lösung finden können. Ihr Beitrag wird sehr geschätzt.

Domic

Answer 2

Reil

Der Verdacht, dass Sie einen 0x800705b4 Fehler in den ManagementService-Protokollen finden würden, ist höchst logisch und in vielen Fällen das genaue "Rauchende Beweisstück" für dieses Szenario. Dieser spezifische Fehlercode führt zu einem generischen Timeout, der im Kontext von Windows Autopilot fast immer darauf hinweist, dass das TPM seinen Attestationshandshake während der Geräteeinrichtungsphase nicht innerhalb des vorgegebenen Zeitrahmens abschließt.

Wenn du die Diagnosedatei entpackst, gehe zum Autopilot-Ordner und öffne die MDMDiagReport.html. Schau dir speziell die Abschnitte Gerätevorbereitung und Geräteeinrichtung an. Wenn Sie dort den 0x800705b4-Code sehen, bestätigt er, dass der Hardware-Hash zwar vom Dienst akzeptiert wurde, das lokale TPM jedoch seinen Endorsement Key (EK) nicht beim Microsoft Azure Attestation-Dienst verifizieren konnte. Dies ist bei bestimmten Hardware-Chargen üblich, bei denen die TPM-Firmware-Version ein bekanntes Kompatibilitätsproblem mit der zu implementierenden Windows-Version aufweist.

Um das Problem zu beheben, ohne das Mainboard zu ersetzen, können Sie versuchen, das BIOS/UEFI auf die neueste Version des Herstellers zu aktualisieren, da diese Updates oft TPM-Firmware-Patches enthalten, die diese spezifischen Timing-Probleme beheben. Wenn die Firmware bereits aktuell ist, musst du eventuell einen "TPM-Reset" über die BIOS-Einstellungen statt über Windows durchführen, um sicherzustellen, dass die kryptografische Identität beim nächsten Start vollständig gelöscht und neu generiert wird.