Windows 11 Device TPM Problem

[Kelvin Cheung]

I have over 30 desktop computers running Windows 11 in the computer lab, when user login with the same local accounts and Microsoft Office 365 are installed on these desktop computers.

While user want to use the Word, Excel, Power Point or other Office App on the desktop, login with Microsoft account is required. All users are provided with one Microsoft account from school, but they cannot login, the error message Device TPM Problem is displayed, and no further action can be done to use Office 365.

I have tried several solutions on solving Device TPM Problem, however, it is still not allowed to login with other account, and the original MS account login with these computers cannot be used too.

Could you tell the reason of this situation? Could you please provide a feasible, simple solution to tackle this problem?

Thank you.

 

[ChatGPT]

Thanks — this is a common cluster of issues (TPM/device-attestation + Office sign-in/activation tokens). Below I’ll explain the cause, give a short safe checklist you can run on one test PC, and then next‑steps for a lab-wide fix.

Why this happens (short)​

• The error 0x8029040E / “Device TPM Problem” normally means the device-attestation data stored in the TPM looks invalid or the OS/Office cannot use it to prove device identity. That breaks the token/attestation step Office uses for school/work (Azure AD / work/school) accounts and stops sign‑in/activation.
• Office sign-in errors (0xCAA82EE2, 657rx, etc.) commonly occur together when local AAD/credential broker caches or device registration tokens are corrupt.

Quick, safe checklist (test on 1 machine first)​

1. Close all Office apps.
2. Clear the AAD broker cache:
   • Open File Explorer, paste:
     %localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
   • Delete all files/folders inside, then reboot. This often fixes sign-in token problems.
3. Sign out of Office (File → Account → Sign out), then open Word and try signing in again. If you still see “Device TPM Problem”, continue below.
4. Check TPM status: Run Windows+R → tpm.msc and note the TPM status and version (ready, not ready, owner auth needed). If the TPM shows errors or “Not found,” that indicates a TPM issue.
5. If BitLocker is enabled: do NOT clear the TPM before you back up BitLocker recovery keys. Clearing TPM removes TPM‑stored keys and can force BitLocker recovery. Back up all recovery keys first.
6. If you recently changed motherboard/CPU or deployed an image from a different machine, TPM data is a likely root cause. In that case you can either:
   • Re‑register the device with your school’s Azure/Entra/MDM (Settings → Accounts → Access work or school → Disconnect then Re‑connect), or
   • If you accept the consequences and have BitLocker recovery keys, clear the TPM (Settings → Privacy & security → Device security → Security processor → Security processor troubleshooting → Clear TPM) and then re‑provision Windows Hello / re-register the device. Clearing is destructive to TPM keys so only do it after recovery keys are secured.

Office activation / token steps to try if sign-in still fails​

• Run Microsoft Support and Recovery Assistant (SaRA) for Office to reset activation tokens and repair sign-in. Also try the Office activation cleanup/diagnostic steps recommended by Microsoft if SaRA doesn’t fix it.
• If devices are Azure AD / Entra joined, consider removing and re‑joining the device to Entra/Azure AD — that has resolved cases where device registration/attestation is broken.

Longer-term / lab-scale options​

• If lab PCs are using the same school Microsoft accounts on many local accounts, consider one of these:
  • Make the PCs properly managed (Azure AD / Intune or AD join + GPO) so devices and credentials are centrally enrolled (prevents repeated device-attestation/token problems).
  • If students must share accounts, use Microsoft 365 Shared Computer Activation for lab‑style deployments (reduces per‑device activation problems) — consider moving to centrally managed licensing rather than signing in per‑user on unmanaged local profiles. (If you want I can add the SCA setup steps.)

Recommended immediate plan​

1. Pick 1-2 representative machines (one that works and one that fails).
2. Run the Quick checklist above (clear AAD broker cache, SaRA, check tpm.msc). Reboot and test Office sign-in.
3. If still blocked and BitLocker is not a concern (or keys backed up), clear TPM on that test machine and re-register the device. Test again.
4. If that fixes it, you have a repeatable sequence for the rest of the lab; if it doesn’t, collect the exact error codes & Office logs and we’ll dig deeper.

What I need from you to proceed​

Please tell me:

• Exact error text (screenshot is helpful) and any error code (e.g., 0x8029040E).
• Are these PCs Azure AD / Entra joined, domain-joined, or just workgroup/local only?
• Were the machines imaged/cloned recently or had hardware changes (motherboard/CPU)?
• Is BitLocker enabled on the drives?

If you want, I can give the exact commands/PowerShell or a short script to run the cache-clear + SaRA steps and a safe checklist to perform at scale.

 

[ussnorway]

@Kelvin Cheung have any of the students perhaps used their own Microsoft accounts on one of these workstations?

 

[ChatGPT]

Good question — two quick clarifiers before you run checks: are these workstations domain‑joined / Azure AD joined, or standalone lab PCs? That changes the easiest method.
If you just want a quick manual check on one PC

• Open Settings → Accounts → Your info (or Email & accounts). If the user signed in with a Microsoft account you’ll see their email (e.g. user@outlook.com) and “Sign in with a local account instead” option.
• Also check Settings → System → Activation — if a digital license is linked to an MS account you’ll see “Windows is activated with a digital license linked to your Microsoft account.”

For checking multiple local profiles (admin PowerShell — runs on the PC)

• This script looks for stored Microsoft identities in each user hive and prints any MSA addresses it finds. Run PowerShell as Administrator:

# Run locally as Admin
$found = @()
Get-ChildItem Registry::HKEY_USERS | Where-Object { $_.Name -notmatch 'S-1-5-18|S-1-5-19|S-1-5-20' } | ForEach-Object {
  $sid = $_.PSChildName
  $key = "Registry::HKEY_USERS\$sid\Software\Microsoft\IdentityCRL\StoredIdentities"
  if (Test-Path $key) {
    Get-ChildItem $key | ForEach-Object {
      $found += [PSCustomObject]@{ SID=$sid; Identity=$_.PSChildName }
    }
  }
}
if ($found) { $found | Format-Table -AutoSize } else { 'No stored MSA identities found in user hives.' }

To run remotely against a list of machines (from an admin workstation)

$computers = 'PC1','PC2'   # replace with hostnames
$script = { <# paste the script block above without the leading comments #> }
Invoke-Command -ComputerName $computers -ScriptBlock $script -ErrorAction SilentlyContinue

Notes and next steps

• If machines are Azure AD / Intune managed, check the Azure AD portal (Users → Devices or Sign‑ins) for which accounts have registered those devices.
• If you want, paste the PowerShell output here and I’ll help interpret it (which account, which user SID → map to C:\Users\ folder).

Want me to prepare a one‑click script you can run across all lab PCs and collect results centrally?