Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's English Pages


Engineering and troubleshooting by Directory Master!
MCM: Directory

Quick Launch

Ondrej Sevecek's English Pages > Posts > The DistributedCOM error 10016 is not always about what it says
April 07
The DistributedCOM error 10016 is not always about what it says

You know the error event probably. I mean the notorious problem with some DCOM services not being accessible to a particular user account because of application-specific permissions or machine wide DCOM permission limits - the following example mentions AD CS certification authority service GUIDs/UUIDs/CLSID/APPID:

Event log: System
Event ID: 10016
Event level: error
Source: DistributedCOM
Message: The application-specific permission settings do not grant Remote Launch permission for the COM server application with CLSID {D99E6E74-FC88-11D0-B498-00A0C90312F3} and APPID {D99E6E74-FC88-11D0-B498-00A0C90312F3} to the user GPS\someuser SID (S-1-5-21-somedomain-somerid) from address running in the application container. The security permission can be modified using the Component Services administrative tool snap-in.

This is a common error also with SharePoint or some instances of SQL server by my experience. No problem solving it. Just open regedit, find the application name for the AppId in HKEY_CLASSES_ROOT (my case is CertSrv Request), go to the Component Services console (comexp.msc) and modify either the application permissions (if it is grayed-out or disabled, you must take ownership of the registry key), or change the machine wide DCOM permission limits (COM Security tab at the My Computer root node) if they are actually preventing the user from reaching the DCOM application at all.

Everybody does this daily.

But stop!

It is not always the case of permissions really. Exactly my case here with AD CS. Read the message carefuly. The message says Remote Launch. It does not say Remote Activation or Remote Access. And that is the point!

Remote Launch is required to have the DCOM start the Windows service if it is not running. Even remotely. Yes, some DCOM services work this way. Their associated Windows service is set to Manual startup typ and the DCOM server starts the service on-demand when a client tries to activate its interface.

For example, DPM agent (dpmra) is launched from its DPM server this way anytime the DPM server wants to do some backup or restore operation on the agent machine.

But not AD CS. With the certification authority service, the default DCOM permissions allow only Remote Activation and Remote Access. Why not. The certsvc (certsrv.exe) service is set to Automatic start type by default. If the service goes down for any reason (usually an administrator doing a servicing), we do not want remote clients to have the service started again automatically upon their own pleasure.

So why the error event?

The reason in my case was that I have set the AD CS service to delayed autostart - Automatic (Delayed) - to prevent some error messages about AD not yet available during the fast boot and allow for easy ADCS initialization. But my clients were hitting the CA yet before the service started. And the DCOM server thought it would be nice to start the service, but the clients didn't have the appropriate permissions, so DCOM server was disapointed it cannot help and logged the message.


Think. Check if the error message is not related to some transitional state, such as the service not running yet. And possibly do nothing. Do not modify the permissions just because you are fast with some blog post.


You are a legend

What a superb write up
 on 07/12/2018 20:00

Add Comment

Sorry comments are disable due to the constant load of spam *

This simple antispam field seems to work well. Just put here the number.


You do not need to provide any value this column. It will automatically fill with the name of the article itself.

Author *

Body *