TPM errors in Windows 11

The last several machines I’ve built–and several long-running machines with nothing wrong with them–have suddenly started displaying strange errors regarding Microsoft 365. The affected machines can neither register Office365 apps to the entire machine successfully, nor will they accept user logins to the Outlook desktop app.

Although you don’t get any obvious errors when Outlook refuses to accept a valid password–confirmed by entering the same password successfully to log into Outlook on the Web in the same machine’s browser–scouring Event Viewer carefully enough will lead you to notice TPM related warnings and errors in the System log, occurring each time you attempt to log into desktop Outlook or attempt to register Office365 apps globally.

The extremely poorly documented actual fix requires at least one and sometimes up to three steps, followed by a reboot. If you want to perform all three steps pre-emptively then reboot, fine–but if you find you need to perform more steps, please realize you will need to reboot again following those additional steps!

Step one: regedit

First, you need to update two registry keys (you may save this text as a .reg file and add it to your Registry directly; the key names have been the same on the ten or so machines I’ve fixed in the last several weeks, despite looking like there might be GUIDs there):

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity\Identities]
"EnableADAL"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb]
"ProtectionPolicy"=dword:00000001

Step two: (DANGER!) clear TPM (DANGER!)

Next, consider deleting the values currently stored in your TPM. 

WARNING WARNING WARNING: if you are using Bitlocker, make certain you will still be able to decrypt the drive after destroying the secrets in your TPM! At a minimum, this means making sure you’ve got scratch codes available. If you don’t have a full backup available that you are prepared and ready to use, strongly consider decrypting the drive before destroying the data in your TPM–if you turn out not to have the scratch codes, or have the wrong scratch codes, etc etc etc, there is no turning back.

If you have decided to go ahead and clear out your TPM now, click Start, type in tpm.msc, and hit Enter. The TPM settings dialog will pop up. Click “clear TPM.” 

Again, do not blindly clear your TPM if you are using BitLocker!

Once you have decided whether or not to pre-emptively clear your TPM, reboot the system, and check to see if your Microsoft 365 woes have been resolved. If they have not, and you haven’t cleared the TPM yet, you’ll need to make arrangements to ensure safety of your data, then clear the TPM, reboot once more, and try again.

If you still have no joy after completing both steps one and two and rebooting, it’s unfortunately time for the last and most obnoxious step.

Step three: create a new, clean Windows user profile

If you’ve added the registry keys and manually cleared the TPM, then rebooted, and your Microsoft 365 login and registration problems still aren’t fixed, the problem is very likely in an undiagnosed area of your user profile.

I only needed to perform this step on two of the ten or so machines I’ve resolved these TPM errors on in the last few weeks–but on those two machines, there was no getting around it; the whole user profile had to go.

The good news is, you can test whether this is necessary before actually destroying anything! Create a new local user on your system (or log in with a different domain user which has never logged into the local system, in an Active Directory environment), log out as the current user, and log in as the brand-new user profile.

Now, try to first activate Office365, then set up Outlook to access the affected user’s email. If you already completed steps one and two, this attempt should succeed with no issues. Once you’ve successfully both registered Office 365 to the affected user’s email account, and successfully logged into that user’s email account in desktop Outlook, you know your problem really was in the original Windows user profile.

At this point, you can do one of three things. You can:

  • Either continue setting up the new Windows profile for regular use, move the user’s data to the new profile, then destroy the old profile
  • Or you can back up the user’s data, destroy the user’s old profile, create a new profile with the same username / log into Active Directory with the same user credentials, then restore the user’s data
  • Or you can get out your Mad Scientist toolkit and start feverishly trying to analyze the broken profile and figure out why it’s broken (I have had no luck with this approach, myself).

Conclusion

I don’t know what’s going on at Microsoft right now, but these TPM errors have been a plague for quite a while, and Microsoft keeps failing to either fix the issue or even provide the sort of comprehensive workaround I’m documenting here.

The good news is, despite needing to fix ten or so machines and counting so far, the majority of the affected machines were fine after nothing but Step 1 (add registry keys) and a reboot, and most of the rest were okay with only adding Step 2 (clear TPM values) and a reboot.

Again, I beg, plead, warn, scream at you: do not blindly clear the TPM without considering the impact on associated services, especially BitLocker.

Finally, of the two machines that still refused to work properly after clearing the TPM, Step 3 (blowing away the user’s Windows profile, then either manually recreating it from scratch or logging in again into an AD environment to recreate it from scratch) worked a treat.

So far, I have not encountered any machine that wouldn’t resume O365 functionality after following this guide. (Knock on wood). Good luck, fellow sysadmin or helldesk veteran, and may the Force be with you…

And please, please, please do not blindly clear the TPM without considering the consequences to associated services such as but not limited to BitLocker!

Troubleshooting Exchange 2007/2010: a quick guide

This is mostly intended for myself… but if it helps you, you’re welcome.

Exchange 2007/2010 with Outlook 2007 clients is a hellkitten to get right, and I do not say this affectionately.  You need to get RPC over HTTP working, or the Out-Of-Office Assistant will not work, and neither will the offline Address Book (or, very likely, the GAL).

In order to get RPC over HTTP working, you must have several virtual directories running right in IIS, you must have client certificates ignored on those virtual directories, you must have both Basic AND Integrated authentication on those directories, and you must have a proper SSL certificate on the site.  On a standard Exchange setup, this will be the (Default Web Site).  On an SBS setup, this will be the (SBS Web Applications) site.

Definition of “proper” SSL certificate: you must have both the internal domain name AND any external domain names ON THE SAME CERT.  If your internal domain is “domain.local” or something like that, this probably means you’re going to have to use self-signed certs (and deal with security warnings on clients outside the local domain).  If you have an FQDN, you ought to be able to get everything on one UCC certificate… you will need, at a minimum, internaldomain.com, mail.internaldomain.com, externaldomain.com, and mail.externaldomain.com.  If possible, you also want autodiscover.externaldomain.com and autodiscover.internal.com, but they aren’t strictly necessary.

Here are some incredibly brief tips toward finagling the virtual directories and the certificates.  Except where specified otherwise, these are all commandlets run from the Exchange Management Shell – there is very little you can or should be doing from the Exchange Management Console for working with these issues.

Testing from Outlook:
control-right-click the Outlook icon in the system tray, and you will have options for “Connection Status…” and “Test E-Mail Autoconfiguration…” available.  Your ultimate goal here is to get the “Test E-Mail Autoconfiguration…” option working.  If you DON’T get this working, you’re not going to have a fully functional Exchange setup, regardless of what anything in the “Connection Status…” tells you.  To get this working, you will need to have either mail.yourdommainname.com or autodiscover.yourdomainname.com both in DNS and on the SSL certificate bound to the site in IIS which hosts the virtual directories for Available Services, the OAB, UM, and OWA.  If you specified both internalurls and externalurls in your virtual directory setup, both
of them need to work properly from inside the domain or local clients will not work; you can’t really control whether they decide to use the internalurl or the externalurl, and in my experience, they will frequently choose to use the externalurl, even if they’re plugged into the same switch and sitting physically right next to the Exchange server.

If your “Testing Autoconfiguration…” comes up with failures, you’ve got problems with your certificates, your virtual directories, your settings for URLs to your virtual directories, or all three… head to the tips below to examine and troubleshoot.

A word of warning about the Exchange Management Shell:
The EMS commandlets sometimes use Uri and sometimes use Url for their argument names… so be careful; even though they both mean the same thing, you have to get the right arbitrary spelling for the right arbitrary commandlets.  (Thanks for that, Microsoft…)

Another word of warning about the EMS:
you can get away with using all lower case for the commandlets themselves, but argument names for the commandlets require CamelCase as shown in the examples below.

A third and final word of warning about the EMS:
The examples I’ve shown below are extremely terse, and assume that, once pointed to examples of working usage, you can figure out the gist of what they mean, what they do, and likely useful ways to do related things just from seeing the syntax shown.  If you don’t feel comfortably that this is the case, then for the love of working systems stop right now and hire a (more experienced) professional!

And now, on to the actual EMS usages:


test basic RPC proxy connectivity:
rpcping -t ncacn_http -s servername -o RpcProxy=proxyservername -P "user,domain,pass" -I "user,domain,pass" -H 2 -u 10 -a connect -F 3 -v 3 -E -R none
test RPC proxy through to Information Store default port on back-end:
rpcping -t ncacn_http -s servername -o RpcProxy=proxyservername -P "user,domain,pass" -I "user,domain,pass" -H 1 -F 3 -a connect -u 10 -v 3 -e 6001
test RPC proxy through to IS backend default port using Mutual auth:
RpcPing –t ncacn_http –s ExchangeMBXServer  -o RpcProxy=RpcProxyServer -P "user,domain,password" -I "user,domain,password" -H 1 –F 3 –a connect –u 10 –v 3 –e 6001 –B msstd:server_certificate_subject
test all web services:
Test-OutlookWebServices
setting the Exchange cert: (note that not all services may be installed)
enable-ExchangeCertificate -thumbprint "thumbprintfromcert" -services "IIS,IMAP,POP,SMTP,UM"
if private key is missing: get serial number from cert and…
certutil -repairstore my "serialnumberfromcert"
Autodiscover:
Get-ClientAccessServer | Select Name, *Internal* | fl
Set-ClientAccessServer -Identity servername -AutoDiscoverServiceInternalUri: https://mydomain.com/Autodiscover/Autodiscover.xml
OAB:

in EMS, Server Configuration -> Client Access -> select server in top window -> click Offline Address Book Distribution tab in bottom window -> click OAB properties in right window, under Actions; set internal and external URLs from there

Web Services:
Get-WebServicesVirtualDirectory | Select name, *url* | fl
Set-WebServicesVirtualDirectory –Identity “<EWS Name>” –InternalUrl: https://url.domain.local/EWS/Exchange.asmx
Unified Messaging:
Get-UMVirtualDirectory | Select Name, *url* | fl
Set-UMVirtualDirectory –Identity: “<UM Virtual Directory>” –InternalURL: <URL/UnifiedMessaging/Service.asmx>