Fix COMADMIN_E_INVALIDUSERIDS (0X80110410) Error

I know getting the COMADMIN_E_INVALIDUSERIDS error when installing a COM+ application file is a real headache. You've done everything right, but Windows just won't let it go. Let's fix it.

The Fastest Fix: Remove Bad User References

The error shows up because your COM+ application file references a user account that no longer exists on the machine. Maybe the user was deleted, renamed, or you moved the app to a different server. Windows won't install an app with invalid user IDs.

Step 1: Open Component Services

Hit Windows + R, type comexp.msc, and press Enter. You'll see Component Services snap-in.

Step 2: Find Your Application

Navigate to Component Services > Computers > My Computer > COM+ Applications. Find the application that won't install. Right-click it and choose Export. Save it as an .msi file on your desktop. Keep the default export options.

Step 3: Edit the Export File

This is the trick. The exported .msi file is really a CAB file in disguise. Rename the .msi to .zip and extract it to a folder.

Inside, look for a file named AppName.cab. Open that with 7-Zip or WinRAR. Find the CLSID folder, then look for a subfolder with a GUID that matches your application's GUID (you can see it in the file names).

In there, you'll see a file called Users.xml. Open it with Notepad. This file lists every user the app expects. You'll see entries like:

<User>DOMAIN\OldUserName</User>

Delete the entire <User> lines that reference missing accounts. Save the file.

Step 4: Rebuild the Export

Put the Users.xml back inside the CAB file (overwrite the old one). Then zip the whole folder back up, rename it to .msi, and run the installer. This time it should work.

If you're on a domain, you might also see entries like Everyone or Interactive User — leave those alone. They're built-in groups, not bad users.

Why This Works

The COM+ installer checks every user reference in the application file against the local SAM or Active Directory. If a user SID can't be resolved to a name, the installer stops and throws 0X80110410. By removing those stale entries, you let the app install cleanly. The app still works because COM+ only needs those user references for launch permissions, not for core functionality.

Less Common Variations of the Same Problem

Sometimes the error triggers for other reasons:

User was renamed — Windows keeps the old SID, but the app has the old name. Same fix.
Cross-domain migration — A user from DomainA is referenced in the app file, but you're installing on DomainB. Edit Users.xml to match a valid user in DomainB.
Built-in account got deleted — Rare, but if someone removed IUSR or NETWORK SERVICE from the Users.xml, you need to add them back. Create a fresh Users.xml with only:

<Users>
  <User>Everyone</User>
</Users>

That's usually enough to get the installer past the check.

How to Prevent This Next Time

When you export a COM+ application, try to use role-based security instead of specific user accounts. Go into Component Services, open the app's properties, and under the Security tab, choose Perform access checks only at the component level. Then assign roles (like 'Managers' or 'Users') instead of individual user names. Roles don't break when people leave the company.

Also, before migrating a COM+ app to a new server, run a quick check on the Users.xml file from the old server's export. Delete any users that won't exist on the new server. Saves you the headache later.

If you're stuck with a corrupted export and can't install the app at all, you can also rebuild the app from scratch using Component Services and re-export. It's more work, but sometimes the cleanest path.