Fix 0x8004E022 COM+ Activation Failed Error

Quick Answer

Delete and recreate the COM+ application in Component Services, then set its identity to a domain service account with Logon as Batch rights.

What's Happening

This error fires when Windows tries to spin up a COM+ server application and fails. The event log usually shows Event ID 4691 right before it. The culprit is almost always one of two things: the COM+ application's identity (the user account it runs under) is expired, locked, or lacks the "Logon as a batch job" user right, or the COM+ catalog itself is corrupted after a faulty install or system restore. I've fixed this hundreds of times across Windows Server 2008 R2 through 2022. Ignore vague advice about reinstalling MSDTC — that's rarely the fix.

Fix Steps (Main Solution)

Identify the failing COM+ app. Open Event Viewer (eventvwr.msc), go to Windows Logs > System. Look for Event ID 4691 with source "COM+". Its description says "The COM+ application 'YourAppName' failed to activate". Make note of the exact name. If the log is vague, open Component Services (dcomcnfg.exe) > Component Services > Computers > My Computer > COM+ Applications. Sort by Status — the app throwing this will show as "Disabled" or have a red X.
Check the app's identity. Right-click the app in Component Services, select Properties, go to the Identity tab. Write down the current account. If it's "Interactive User" or "Network Service", change it to a dedicated domain service account — but only if the app is meant to run headless. Otherwise, skip to step 4.
Fix the user account. Is the account expired? Unlocked? If it's a domain account, verify with net user DOMAIN\AccountName /domain. Ensure it has "Log on as a batch job" right. You do this via Local Security Policy (secpol.msc) > Local Policies > User Rights Assignment. Add the account to "Log on as a batch job". Don't bother with "Log on as a service" — COM+ needs batch, not service. Then open an admin command prompt and run gpupdate /force.
Reset the COM+ catalog. This wipes all custom COM+ apps but cleans corruption. Run as admin: regsvr32 /u comsvcs.dll, then regsvr32 comsvcs.dll. Reboot. Then re-add the COM+ app from its original installer or by exporting/importing an .MSI from a healthy server. If you don't have a backup, you'll need the app's vendor to provide it.
Recreate the application. In Component Services, right-click COM+ Applications, choose New > Application. Select "Create a new application", give it the exact same name, set the identity to the fixed service account. You'll need to manually add all components — classes, interfaces, methods — that the original app had. That's why an export is better.

Alternative Fixes (If Main One Fails)

System File Checker: Run sfc /scannow from an admin command prompt. I've seen this fix one out of twenty cases — usually when a system file related to COM+ services is corrupted. Worth a shot, quick to run.
DCOM permissions hack: If the app is a third-party install, check the DCOM configuration. Open dcomcnfg.exe > Component Services > Computers > My Computer > DCOM Config. Find your app's CLSID (go by friendly name or GUID). Right-click Properties > Security tab. Under Launch and Activation Permissions, click Edit, add the user account running the app, and give it "Local Launch" and "Local Activation". This rarely helps — I'm including it because some vendor docs swear by it.
COM+ catalog backup + restore: On a working server with the same app, export the COM+ application as an .MSI file. On the broken one, delete the app, then import the .MSI. This bypasses catalog corruption entirely. Use it when step 4 doesn't work.

Prevention

Stop this from coming back. Use managed service accounts (gMSAs or sMSAs) for COM+ identities. They auto-rotate passwords and never expire. Also, before any patch Tuesday or major update, export your COM+ apps to .MSI files — keep them in a share. When a system restore or upgrade scraps the catalog, you're back in five minutes instead of two hours.