When This Error Shows Up
You're in the Component Services snap-in (dcomcnfg). You go to a COM+ application, open Properties, click the Identity tab, and change it from "Interactive user" to "This user." You type in a domain account like ACME\jsmith and a password. Click OK — and boom, you get the error dialog: CO_E_RUNAS_SYNTAX (0x80004017) - A RunAs specification must be
This happens most often on Windows Server 2019, Windows 10 Pro, and Windows 11. You'll see it when the COM+ application needs to run under a service account or a managed service account (gMSA).
Root Cause
What's actually happening here is that the COM+ system is not using the same parser as the Windows login dialog. The Identity tab takes the text you type and stores it in a registry value called RunAs under the COM+ application's GUID key. The format must be DOMAIN\User with a single backslash — no extra spaces, no forward slashes, no UPN format like user@domain.com.
The tricky part: the COM+ admin tool sometimes adds a trailing space or interprets a backslash wrong if you copy-paste from somewhere. Also, if you're using a local account, you must write .\Username or just Username — but the tool may reject the dot-backslash format. This is a known quirk on Windows 10 1809 and later.
The Fix
Skip the GUI trickery. The reliable way is to edit the registry directly. Here's how.
- Open Regedit as Administrator.
- Find your COM+ app's GUID. Go to:
HKEY_CLASSES_ROOT\AppID\{YourAppGUID}If you don't know the GUID, open Component Services, right-click your application, choose Properties, and look at the General tab — the GUID is listed as "Application ID" with curly braces.
- Look for the RunAs value. It's a REG_SZ string. If it's missing, create it.
- Double-check the format:
- For a domain account:
DOMAIN\Username— exactly one backslash, no spaces before or after. - For a local account:
Username(no dot-backslash, no computer name). Windows fills in the computer name automatically. - For a managed service account:
DOMAIN\gMSAName$— note the dollar sign at the end.
- For a domain account:
- Set the password in the same key. Create a REG_BINARY value named
RunAsPassword. The password must be encoded as a binary. The easiest way is to delete the existingRunAsPasswordand let the COM+ admin tool recreate it: go back to the Identity tab, type the correct RunAs string again, and enter the password. This time it won't error because the RunAs string is already correct in the registry.
Why This Works
The reason step 3 and 4 work is that by editing the registry first, you bypass the GUI's validation logic. The GUI checks the RunAs string before saving — and it's too strict. But the actual COM+ runtime only reads the registry value. So if you put the correct format in the registry directly, the application will start fine, even if the GUI would have rejected it.
What to Check If It Still Fails
- Hidden characters: If you copy-pasted the username from a text file or email, there might be a non-breaking space (U+00A0) instead of a regular space. Type the username manually.
- Account permissions: The account you're using must have Log on as a batch job user right. Without that, COM+ can't launch the application. Check this with
secpol.msc→ Local Policies → User Rights Assignment. - Group Managed Service Accounts: If you use a gMSA, make sure you've installed the AD module and run
Install-ADServiceAccounton the machine. The RunAs format must include the trailing$. - Event Viewer: Look under Windows Logs → System for Event ID 1000 or 1001 from COM+. The error message there often says
RunAs specification is invalid— that's the same problem.
One more thing: if you're on a domain controller, local accounts don't work for COM+ applications. You must use a domain account or the Network Service / Local System built-in accounts. The error 0x80004017 is more common on DCs because people try to use local admin accounts.