COMADMIN_E_ROLE_DOES_NOT_EXIST (0X80110447) – Quick Fix

Quick Answer for Advanced Users

Open Component Services, navigate to the COM+ application, go to Roles, add the missing role name exactly as it appears in the error, then restart the application.

Why This Error Happens

You're seeing 0X80110447 because someone assigned a security role to a component, interface, or method in a COM+ application — but that role was never actually created in the application's role list. Classic configuration drift. I see this most often after exporting/importing a COM+ application between servers, or when a dev pushed an updated MSI that changed role names but didn't clean up old assignments. The COM+ runtime is strict: it won't let you call a method protected by a ghost role.

Here's the real-world trigger: A developer on Server A added a role called "AdminUsers" to the component, but forgot to add it under Roles. Then they exported the app. On Server B, the import creates the role assignment but not the role itself. Boom, error.

Fix Steps (Numbered)

1. Open Component Services — Run dcomcnfg from an admin command prompt. Expand Component Services > Computers > My Computer > COM+ Applications.
2. Locate the problem app — Expand your COM+ application, then expand Components. Find the component mentioned in the error (check Application event log if needed). Right-click it, go to Properties > Security tab.
3. Note the missing role name — Under "Roles assigned to this component", you'll see one or more roles listed. Write down the exact name of the role that's checked but doesn't exist. It's usually plain text like "Managers" or "PowerUsers".
4. Add the missing role — Go back up to your application node, expand Roles. If the role name you noted isn't there, right-click Roles > New > Role. Enter the exact name. Click OK. No users needed — just the role name being present is enough to satisfy COM+.
5. Restart the application — Right-click your COM+ application > Shut Down. Then right-click again > Start. This forces COM+ to reload the role list.
6. Test the call — Run whatever client code was throwing the error. It should work now. If not, double-check the role name you added — case and spaces matter.

Alternative Fixes if the Main One Fails

If adding the role didn't stick or the error keeps appearing:

• Delete and re-add the component — Sometimes a component's role assignments corrupt. Remove the component from the COM+ app (right-click > Delete), then re-import or re-register it. Then reassign roles.
• Export and re-import the entire application — Right-click the app > Export > Application Proxy or Server Application. On a clean test server, import it. If the error disappears, the original app's role list was hosed. You can then re-export and deploy to production.
• Check the Windows event log — Any Application event with source "COM+" will have the exact component name and method that's failing. Use that to narrow down which component has the ghost role.
• Turn off role-based security temporarily — In the application's Properties > Security tab, uncheck "Enforce access checks for this application". This is a band-aid, not a fix, but it'll keep the lights on while you troubleshoot.

Prevention Tip

Always validate role names match between your development environment and production. Before exporting a COM+ app, run a quick PowerShell check: Get-ComApplication -ApplicationName "YourApp" | Get-ComApplicationRole — that lists all roles. Then do Get-ComApplication -ApplicationName "YourApp" | Get-ComApplicationComponent | Get-ComApplicationComponentRole to see what's assigned. If you see a role on a component that's not in the role list, fix it before export.

One more thing: never rely on case-insensitivity. COM+ roles are case-sensitive. "Admin" and "admin" are two different roles. Keep them consistent.