0x8011081B: Legacy COM+ components blocked in nonbase partition

1. You're trying to install a legacy COM+ app into a nonbase partition

This is by far the most common trigger. You have a COM+ application built with an older version of COM+ — maybe from the Windows 2000 or XP era — and you're trying to install it into a partition you created explicitly, not the base (default) partition. COM+ simply refuses. The error 0x8011081B translates to COMADMIN_E_LEGACYCOMPS_NOT_ALLOWED_IN_NONBASE_PARTITIONS, which tells you exactly what's wrong: legacy components can't live in nonbase partitions.

Why does COM+ block this? The partition system was introduced in COM+ 1.5 (Windows 2000) to allow multiple application instances with different configurations. But legacy COM+ components (from COM+ 1.0) weren't designed with partitions in mind. They don't understand partition IDs, isolation boundaries, or the routing logic. If COM+ let them install, they'd break in unpredictable ways — cross-partition activation failures, class identity collisions, you name it. So Microsoft locked the door.

The fix isn't complicated: install the application into the base partition. Here's how.

1. Open Component Services (dcomcnfg from Run or Command Prompt).
2. Expand Component Services → Computers → My Computer → COM+ Applications.
3. Right-click COM+ Applications and choose New → Application.
4. Walk through the wizard, choosing Install pre-built application if you have a .MSI or .DLL to register, or Create an empty application if you're adding components manually.
5. Don't select any partition during the wizard — by default it installs into the base partition. That's the whole trick.
6. If the wizard asks for a partition (some newer versions do), explicitly pick Base (default).

This works because the base partition is the only one that has the legacy compatibility shims COM+ needs. The rest of the partitions are strictly for modern, partition-aware COM+ applications.

2. The application's installer is hardcoded to target a specific nonbase partition

Sometimes the error shows up even when you didn't manually pick a partition. What's happening here is the application's own installer script or MSI package already contains a directive that says "install into partition X". That's rare, but I've seen it with older enterprise apps like custom CRM tools or line-of-business apps that were deployed across multiple isolated environments on the same server.

The installer calls COMAdmin.ICatalogCollection or uses a partition-specific install flag. When that partition ID doesn't match the base partition, COM+ throws 0x8011081B because the installer tries to push a legacy component into a nonbase partition.

Your move: edit the installer or override its behavior.

Override via command line

If the installer is an MSI, run it with a transform (MST) that clears the partition property. That's the cleanest path. But most people don't have an MST editor handy. The practical hack is to use the COM+ admin script approach instead.

Set objCatalog = CreateObject("COMAdmin.COMAdminCatalog")
Set objApplications = objCatalog.GetCollection("Applications")
objApplications.Populate
' Find the application by name, force it into base partition
For Each app In objApplications
    If app.Name = "YourAppName" Then
        app.Value("PartitionID") = "{00000000-0000-0000-0000-000000000000}"
        objApplications.SaveChanges
        Exit For
    End If
Next

That partition ID GUID — all zeros — is the base partition. Run this VBScript before the installer tries to register the components. This pre-creates the application entry in the base partition, so when the installer fires, it sees the app already exists and (usually) merges components into it.

If you can't pre-create, you'll need to modify the installer. Open it in Orca (Windows SDK tool) and look for the ComPlusApp table or the _ComPlusAppRegistration custom action. Change the PartitionId column value to {00000000-0000-0000-0000-000000000000}. That's the nuclear option, but it works.

3. You're mixing 32-bit and 64-bit COM+ components in a partition

Less common, but I've seen it on x64 Windows Server 2008 R2 and 2012 R2 boxes where someone tried to host a legacy 32-bit COM+ DLL alongside a 64-bit component in the same partition. COM+ partitions enforce a single bitness per partition. If you've got a mixed-bitness scenario and one of the components is legacy, the error shows up as 0x8011081B because COM+ sees the legacy component as incompatible with the partition's bitness flag.

The real issue: the partition wasn't created with legacy compatibility mode enabled. When you create a partition in Component Services, there's a checkbox: Enable legacy components in this partition. Most admins miss it because it's hidden under the Partition Properties → Advanced tab. Without that flag, any legacy component install into the partition is blocked.

To fix it:

1. Open Component Services.
2. Expand Component Services → Computers → My Computer → COM+ Partitions.
3. Right-click the partition that's failing and choose Properties.
4. Go to the Advanced tab.
5. Check Enable legacy components in this partition.
6. Click OK, then restart the COM+ System Application service (net stop COMSysApp && net start COMSysApp).

That checkbox adds a compatibility shim to the partition's activation context. It tells COM+ to treat the partition like the base partition for legacy component routing. But be warned: this bypasses some of the isolation guarantees. Only use it if you really need legacy components in that specific partition and you can't move them to the base.

Quick-reference summary