Fix COMQC_E_UNTRUSTED_ENQUEUER (0x80110606) in Message Queuing

The 30-Second Check: Is the User in the Right Group?

This error pops up when someone — or something — tries to move or requeue a message via the MSMQ COM component (the MSMQQueueInfo or MSMQQueue objects) and that account isn’t in the QC Trusted User local group on the machine. Don’t bother checking MSMQ service accounts first — the real fix is almost always group membership.

Open Computer Management (right-click This PC → Manage), go to System Tools → Local Users and Groups → Groups. Look for QC Trusted User. If it’s missing, skip to the advanced section — that machine’s MSMQ install is hosed. If it’s there, double-click it and see who’s inside.

If the account that’s running the requeue operation isn’t listed, that’s your problem. Add it:

1. Click Add.
2. Type the account name (domain\username or local username).
3. Click Check Names to verify.
4. Click OK twice.

Test the application again. If the error’s gone, you’re done. If not, move on.

The 5-Minute Fix: Verify the COM Component’s Identity

Sometimes the account that’s listed in the group isn’t the account actually calling the COM object. This happens when a service or scheduled task runs under a different identity than you think. Here’s how to check:

1. Open Component Services (run dcomcnfg).
2. Expand Component Services → Computers → My Computer → DCOM Config.
3. Look for MSMQ Queue Info or MSMQ Queue — might be listed as Message Queuing COM Component. Right-click → Properties.
4. Go to the Identity tab. If it’s set to Launching User, that means whoever calls the COM object needs to be in the QC Trusted User group. If it’s set to This user, that specific account needs membership.
5. Adjust the group membership accordingly. A reboot of the calling application (not the whole server) usually does it.

I’ve seen this trip up people running MSMQ from a Windows Service running as NETWORK SERVICE. That account is NOT in QC Trusted User by default. Add it, restart the service, done.

The 15-Minute Advanced Fix: Re-register and Re-secure MSMQ

If the above didn’t work, the MSMQ COM registration is likely corrupt or the security descriptor on the role itself is messed up. Don’t bother with a reinstall of MSMQ yet — try this first.

Step 1: Re-register the MSMQ COM Components

Open an admin command prompt and run:

regsvr32 /u mqoa.dll
regsvr32 mqoa.dll

This re-registers the Message Queuing Object Library. Then reboot — not optional, the COM runtime caches this stuff.

Step 2: Reset the QC Trusted User Group’s Security

Use ADSI Edit (on a domain controller) or net localgroup to verify the group actually exists. On a domain-joined machine, the group might be a domain local group — check AD under CN=QC Trusted User,CN=Groups,CN=YourDomain,.... If it’s missing entirely, you can manually create it via PowerShell:

New-ADGroup -Name "QC Trusted User" -GroupScope DomainLocal -Path "CN=Groups,DC=yourdomain,DC=com"

Then add the account that needs access.

Step 3: Check MSMQ Queue Security

Rare, but I’ve seen it: someone locked down the individual queue’s permissions so that even a QC Trusted User can’t requeue. Open Computer Management → Services and Applications → Message Queuing → Private Queues (or Public Queues). Right-click the queue throwing the error → Properties → Security. Make sure the account has at least Receive Message and Peek Message permissions. The QC Trusted User group should inherit these generally, but explicit denial overrides it.

Real-world trigger: I’ve seen this exact error when a backup script used MSMQ COM to requeue poison messages under a service account that wasn’t in the QC Trusted User group. Took me two hours the first time. Now I check the group first.

If none of that works, you’re looking at a MSMQ reinstall. Uninstall the Message Queuing feature, reboot, reinstall it, reboot again. But honestly, that’s overkill for 99% of cases. The group membership is almost always the culprit.