You're in Component Services, trying to move a COM+ component from one application to another, and bam—COMADMIN_E_COMP_MOVE_DEST (0X8011081D) pops up. I've seen this on Windows Server 2012 R2 through 2019, usually when you're reorganizing DCOM configs after a migration or when you're trying to consolidate multiple components into a single application. The trigger is almost always the same: the destination application already has a component with the same CLSID or ProgID. Windows doesn't tell you that directly—it just throws this cryptic hex code at you.
What's Actually Happening
Under the hood, COM+ thinks you're trying to create a duplicate. The move operation isn't a simple cut-and-paste—it's a copy to the destination, then a delete from the source. If the destination already holds a component with the same identifier, the copy step fails because COM+ enforces uniqueness per application. The error is misleading because it says "dest" but really it's about a conflict, not a permissions issue.
The first time I hit this, I spent an hour checking DCOM permissions and registry ACLs. Don't do that. The fix is about cleaning up the destination, not loosening security.
The Fix: Clear the Destination and Re-move
- Open Component Services (run
dcomcnfgas admin). Navigate to Component Services > Computers > My Computer > COM+ Applications. - Expand the destination application (the one you're moving to). Look under Components for any entry that matches the component you're trying to move. Pay attention to the CLSID—that's the real identifier.
- If you find a matching component, right-click it and select Delete. Confirm you want to remove it. Don't worry if you think you might need it—if it's identical, the move will bring it back.
- Now go back to the source application, find the component you were moving, right-click, and choose Move. Select the destination application again.
- If the move still fails, close Component Services and reopen it. Sometimes the console caches the component list, and it doesn't see the deletion until you refresh. Right-click the destination application and hit Refresh before trying again.
That usually does it. But there's a sneakier variant: duplicate ProgIDs in the registry. The console might not show a conflict, but the registry has stale entries.
If It Still Fails: Check the Registry
Open regedit and go to:
HKEY_CLASSES_ROOT\CLSIDSearch for the CLSID of the component you're moving (you can find it in the Component Services console under the component's properties, on the General tab). If you see multiple entries under that CLSID with different subkeys like InprocServer32 or LocalServer32, that's not the issue—but if you see an AppID value pointing to a different application, that can cause the move to fail with this error. Export the key as a backup, then delete the faulty AppID value (not the whole key) and retry the move.
Also check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\Applications. If there's a leftover entry for the destination application that references the component's CLSID, delete that reference (again, back it up first).
Why This Happens in Real Scenarios
I've most often seen this after a botched uninstall or when someone copied a COM+ directory from an old server without properly exporting and importing. The old application's components linger in the registry, and when you try to move a fresh copy, the system sees the ghost. The registry cleanup above is the real fix in those cases.
One more thing: if you're moving a component that's part of a transactional queue or that has a role assignment, the move might also trip over role conflicts. Check the Security tab on the destination application—make sure the component's roles are defined there, or temporarily remove role restrictions, move, then re-add them.
If you've done all this and the error persists, reboot the server. It sounds cliché, but COM+ caches a lot in memory, and a reboot clears out those ghost references. I've had that be the final step more than once.