How to Configure COM+ Application Server on Windows Server 2025
COM+ (Component Object Model Plus) is the Windows middleware layer that provides enterprise services — object pooling, distributed transactions, role-based security, and loosely coupled events — to COM components running on Windows Server. COM+ sits between IIS/application code and the raw Windows API, offering the Component Services infrastructure used by many legacy enterprise applications, ERP systems, and financial middleware still in active production. While modern architectures favour microservices and containers, COM+ remains essential for running mission-critical line-of-business applications written for Windows DNA, classic ASP, or early .NET. This guide explains how to configure COM+ on Windows Server 2025, create COM+ applications, manage object pooling and distributed transactions, and troubleshoot common DCOM errors.
Prerequisites
- Windows Server 2025 with an administrator account
- At least one registered COM or .NET DLL to host (or the ability to register a test DLL)
- PowerShell 5.1 or later
- Active Directory membership is optional but required for distributed transactions spanning multiple servers
- Microsoft Distributed Transaction Coordinator (MSDTC) running if you need distributed transactions
Step 1: Verify COM+ and Component Services Are Available
COM+ is a built-in Windows Server component and does not require a separate feature installation. The Component Services MMC snap-in is available on every Windows Server 2025 installation.
# Verify COM+ System Application service is running
Get-Service -Name "COMSysApp" | Select-Object Name, Status, StartType
# Start it if stopped
Start-Service -Name "COMSysApp"
# Also check MSDTC for distributed transactions
Get-Service -Name "MSDTC" | Select-Object Name, Status, StartType
Start-Service -Name "MSDTC"
Set-Service -Name "MSDTC" -StartupType Automatic
Step 2: Open the Component Services MMC
The primary management interface for COM+ is the Component Services MMC snap-in, accessible via dcomcnfg.exe:
- Press Win + R, type
dcomcnfg.exe, press Enter. - In the left tree, expand: Component Services → Computers → My Computer → COM+ Applications.
- You will see built-in COM+ applications (IIS Out-Of-Process Pooled Applications, COM+ Utilities, COM+ Explorer) already listed.
Alternatively, open it from Server Manager or via PowerShell:
# Launch Component Services MMC
Start-Process dcomcnfg.exe
# Or launch directly into the COM+ Applications node
Start-Process comexp.msc
Step 3: Understand COM+ Application Types
COM+ applications come in two hosting modes that affect isolation, performance, and security:
- Library Application — The COM+ components run in-process within the client’s process address space. No process boundary crossing means faster calls but less isolation. A crash in a library application can take down the host process.
-
Server Application — The COM+ components run in a separate
dllhost.exesurrogate process. The client calls cross a process boundary via DCOM. This provides full fault isolation: a crash in the COM+ server application does not affect the client, and you can configure a separate identity for the surrogate process.
For most production deployments, use Server Application unless the performance overhead of cross-process marshalling is unacceptable.
Step 4: Register a COM DLL and Create a COM+ Application
Before adding a component to COM+, the DLL must be registered in the Windows Registry using regsvr32 (for classic COM) or regasm (for .NET assemblies).
# Register a classic COM DLL
regsvr32 "C:MyAppsOrderProcessorOrderProcessor.dll"
# Register a .NET assembly for COM interop
# The assembly must have ComVisible(true) and a strong name
regasm "C:MyAppsOrderProcessorOrderProcessor.dll" /tlb /codebase
# Verify registration succeeded
reg query "HKCRCLSID" | findstr /i "OrderProcessor"
Now create a new COM+ Server Application from the MMC:
- Right-click COM+ Applications → New → Application.
- Choose Create an empty application.
- Name it
OrderProcessorApp, select Server application, click Next. - Set the Application Identity (see Step 5), finish the wizard.
- Expand the new application → right-click Components → New → Component.
- Choose Install new component(s) and browse to
OrderProcessor.dll.
Step 5: Configure Application Identity (DCOM Security)
Server applications run under a specific Windows account. Setting this correctly prevents the most common COM+ security errors:
- Right-click your COM+ application → Properties → Identity tab.
- Options:
- Interactive user — runs as the currently logged-on desktop user. Do not use in production.
- This user — runs as a specific service account. Recommended for production.
- Local Service / Network Service / Local System — built-in accounts; use Network Service for domain-authenticated scenarios.
- Enter the service account credentials and click OK.
Via PowerShell and WMI:
# List COM+ applications and their identities
$comAdmin = New-Object -ComObject COMAdmin.COMAdminCatalog
$apps = $comAdmin.GetCollection("Applications")
$apps.Populate()
foreach ($app in $apps) {
Write-Host "$($app.Name) — Identity: $($app.Value("Identity"))"
}
# Change the identity of a specific application
foreach ($app in $apps) {
if ($app.Name -eq "OrderProcessorApp") {
$app.Value("Identity") = "CORPsvc-complus"
$app.Value("Password") = "SecureP@ss123"
}
}
$apps.SaveChanges()
Step 6: Configure Object Pooling
Object pooling reuses COM component instances instead of creating and destroying them on every client request, dramatically improving throughput for expensive-to-initialize components (e.g., those that open database connections on construction).
To enable pooling on a component:
- Expand your COM+ application → Components.
- Right-click the component → Properties → Activation tab.
- Check Enable object pooling.
- Set Minimum pool size (objects pre-created at startup), Maximum pool size (hard cap), and Creation timeout (ms to wait if pool is exhausted).
Typical production values for a database access component:
Minimum pool size : 5
Maximum pool size : 50
Creation timeout : 30000 (30 seconds)
The component class must implement IObjectControl (classic COM) or be decorated with the [ObjectPooling] attribute (.NET) to participate correctly in pooling.
Step 7: Configure Distributed Transactions
COM+ integrates with MSDTC to provide automatic transaction enlistment. Components can declare their transaction requirements via attributes or the COM+ catalog:
Transaction attribute values (set on the Transactions tab of each component’s Properties):
- Disabled — component never participates in transactions
- Not Supported — component ignores any transaction context from the caller
- Supported — component shares the caller’s transaction if one exists
- Required — component uses the caller’s transaction or creates a new one
- Requires New — component always creates a new transaction, independent of the caller
# Check MSDTC network access is configured correctly
# Required when transactions span multiple servers
# Open MSDTC Security Configuration
Start-Process msdtc -ArgumentList "-config"
# Or configure via PowerShell/registry
Set-ItemProperty `
-Path "HKLM:SOFTWAREMicrosoftMSDTCSecurity" `
-Name "NetworkDtcAccess" -Value 1
Set-ItemProperty `
-Path "HKLM:SOFTWAREMicrosoftMSDTCSecurity" `
-Name "NetworkDtcAccessTransactions" -Value 1
Restart-Service -Name "MSDTC"
Step 8: Configure Role-Based Security
COM+ supports role-based security at the application, component, interface, and method level. Roles are named groups that map to Windows user accounts or groups.
- Right-click your COM+ application → Properties → Security tab.
- Enable Enforce access checks for this application.
- Set security level to Perform access checks at the process and component level.
- Expand the application → right-click Roles → New Role. Create roles like
OrderManagersandReadOnly. - Expand each role → Users → add Windows users or groups.
- Assign roles to specific components or interfaces by expanding the component and setting roles on the Security tab.
Step 9: Troubleshoot DCOM Error 80070005 (Access Denied)
Error 0x80070005 (Access is Denied) is the most common COM+ issue. It typically occurs when the calling identity lacks Launch or Access permissions on the COM+ application:
# Check DCOM permissions via registry (DCOM AppID)
# First find the AppID for your COM+ application
reg query "HKCRAppID" | findstr /i "OrderProcessor"
# Check Windows Event Log for DCOM errors
Get-WinEvent -LogName "System" |
Where-Object { $_.ProviderName -eq "Microsoft-Windows-DistributedCOM" } |
Select-Object TimeCreated, Message |
Format-List
Resolution checklist for error 80070005:
- In Component Services, right-click the application → Properties → Security tab — verify the calling account is in an assigned role.
- Right-click My Computer → Properties → COM Security tab — add the calling account to Launch and Activation Permissions and Access Permissions.
- Verify the application identity account has Log on as a service and Log on as a batch job user rights (secpol.msc → Local Policies → User Rights Assignment).
- If calling remotely, ensure Windows Firewall allows DCOM traffic (TCP port 135 + dynamic RPC range 49152–65535).
# Allow DCOM through Windows Firewall
New-NetFirewallRule -DisplayName "DCOM RPC Endpoint Mapper" `
-Direction Inbound -Protocol TCP -LocalPort 135 -Action Allow
New-NetFirewallRule -DisplayName "DCOM Dynamic RPC" `
-Direction Inbound -Protocol TCP -LocalPort 49152-65535 -Action Allow
Conclusion
COM+ on Windows Server 2025 continues to provide a robust enterprise services layer for organizations running legacy COM and .NET Framework applications. By following this guide, you have verified the COM+ infrastructure, created a Server Application with a dedicated service account identity, registered and hosted COM components, enabled object pooling for high-throughput scenarios, configured MSDTC for distributed transactions, and applied role-based security. Understanding DCOM error codes and their resolutions — particularly the ubiquitous 80070005 access denied — will save significant troubleshooting time in production. For new projects, evaluate whether .NET 8 hosted services or containerized microservices can replace COM+ over time, but for existing investments, the Component Services infrastructure on Windows Server 2025 remains fully supported and production-ready.