DCOM error related to SCCM

Posted on Updated on

(or what you need to know about DCOM and SCCM)

On some systems the following error appears in the System event log:

Event ID: 10016

Description: The application-specific permission settings do not grant Local Launch permission for the COM Server application with CLSID




to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

Source: DistributedCOM

Level: Error




Task Category: None

Keywords: Classic

OpCode: Info

Figure 1

Figure 2

Figure 3

I first discovered the error on a Remote Desktop Session Host (RDSH), but it’s not RDSH related at all; at the contrary, it’s a quite generic issue. I have already said too much with the title, so yes, it’s SCCM related. There are a lot of possible DCOM errors of this kind, that’s why I had to include part of the solution in the title. Anyway, let’s take a closer look at this issue.

First a little bit about (D)COM…

The event source DistributedCOM refers to Distributed COM (DCOM), the “network” (“distributed”) version” of Component Object Model (COM). COM is a model based on objects, representing software components. Some software pieces (components) are built based on this model and they are often called “COM objects”. COM makes it possible to create modular software components that can be called and loaded at runtime and on-demand across process boundaries, making interprocess communication possible. It’s similar to CORBA and Java Beans. COM was introduced by Microsoft in 1993 and was the successor of the older Object Linking and Embedding (OLE) technology, which was introduced in 1991, targeted compound documents only and built on top of an even earlier technology called Dynamic Data Exchange (DDE). DDE was born in 1987 and made it possible to send and receive message in “conversations” between applications; OLE was building on that and became the first object based framework for software componentry and interprocess communication, but still only limited to compound document scenarios… This changed with the next version, launched in 1992 and included in Windows: OLE 2. This was the first “general-purpose” object based framework for software componentry and interprocess communication. As already said, the technology has been replaced with a new, more modern COM in 1993. Besides all this Microsoft also released a similar mechanism for use in Visual Basic (VB): Visual Basic Extensions (VBX). In 1994 OLE was updated with a successor for VBX, called OLE custom controls (OCX). At the same time Microsoft stated OLE 2 was just renamed to “OLE”, wasn’t officially an acronym anymore and was a collection name for all their component technologies. So the name OLE as a specific technology name “died” and became a synonym for all the Microsoft implementions of this technology type. How confusing is that?! Anyway, in 1996 Microsoft used OCX in IE, renamed all their OLE technologies related to the Internet to ActiveX (calling ActiveX objects “ActiveX controls”) and began starting to rename other OLE pieces to ActiveX too, except for the compound document part. Later in 1996 COM got a “network version”, called DCOM, meant to compete with other network technologies like CORBA. Microsoft launched an extension to COM, called Microsoft Transaction Server (MTS), with Windows NT 4. This was included with Windows 2000 and renamed COM+. It included a lot of new features, including support for distributed transactions and event publication and subscription. These events are called COM+ Events and make use of the Microsoft Message Queuing (MSMQ) technology. Components using this system are called Queued Components. The introduction of the .NET Framework made the whole OLE/COM/… technology set legacy, although it’s still possible to make use of those mechanism from .NET applications through COM Interop. A COM object is exposed through one or more interfaces, defined with the Interface Definition Language (IDL). Different threading models exist for COM objects at the “COM server side”. Every COM object and thread is assigned to a conceptual entity called an apartment. There can be only 1 COM object related to an apartment, which can have multiple threads assigned to it though. The way threads are assigned to an apartment is called the apartment model. For example, Single-Threaded Apartment (STA) is a model that states only 1 thread can be assigned to an apartment (and thus to a COM object).

A COM object is of a certain type (class). A class is identified by a class ID (CLSID) and an object by an application ID (AppID). Both IDs are Globally Unique Identifiers (GUIDs). COM objects can be called by other software (COM clients) that tries to make use of the functionality of those COM objects. Of course the COM objects should be loaded by and made available through some kind of a (local or remote) COM server (COM provider), which actually exposes the object’s interface. For example, a weather application could be implemented as a COM object and be used by Internet Explorer (IE), so IE is the COM client communicating with a COM server that hosts that COM object. A COM object is reusable and can also be consumed in complete different scenarios and exposed by different COM servers, even on the same system and simultaneously. A COM server can be implemented by an executable and thus run as a standalone process, outside other processes and exposing COM interfaces to COM clients (local or remote). A COM server can also be implemented by a DLL (typically with the .dll or .ocx extension) and thus run inside another process, while offering COM interfaces inside that process (but not outside). The first type is logically called an out-of-process COM server, while the 2nd type is called an in-process COM server. The 2nd type can be implemented in a special way though (as a DLL Surrogate), making it possible to be loaded in a surrogate executable (by default that’s the DLL Host Manager, dllhost.exe, which can appear more than once on a Windows system), which then acts as an out-of-process COM server, so it gets the same benefits as the first type of COM server. COM server files contain already the COM objects they should take care of. In the case of IE and the weather application, the weather COM object is typically implemented in a DLL, serving as an in-process COM server, which is loaded into IE, which as a whole is the COM client. Both types of COM servers can be used as a Windows service. A lot of Windows services are actually in-process COM servers containing a COM object which represents the “real” Windows service functionality and being implemented in a DLL file; such DLLs are loaded by generic Windows service host processes (svchost.exe). As you probably know, the Service Control Manager (SCM) sets up and maintains this whole set of Windows services.

If the COM object resides on the local system, it’s all about simple, classic COM. When COM clients and servers on different systems talk to each other (so over the network), we speak of DCOM. DCOM implies the DCOM network protocol. If a COM server can serve calls from over the network, it’s a DCOM server. DCOM should be considered as more than just calling a COM object over the network: it’s used A LOT for all kinds of remote scenarios, including for remote management purposes, and you would be surprised which mechanisms build on top of it. (D)COM is a powerful, but difficult technology. It has its benefits, but also its disadvantages. It’s becoming more and more something legacy though and a lot of scenarios already have a more modern solution now (for example, WMI (Microsoft’s implementation of WBEM) will use WinRM (Microsoft’s implementation of WS-MAN) as the transport protocol, although DCOM will still be supported for compatibility). (D)COM uses Remote Procedure Call (RPC) as the underlying mechanism for the transport of so-called Remote COM messages. For local COM this kind of RPC is called Local RPC (LRPC, or Leightweight RPC), also named Local Procedure Call (LPC), for the transport of so-called Local COM messages. Oh yes, have you heard of (COM) monikers? Well, these are special COM objects which identify other COM objects you might need. So they have some kind of an intermediate and referring role. COM clients calling them are called moniker clients, while COM servers hosting them are called moniker providers.

When a COM server is started, COM objects aren’t active yet. You need activation permissions to activate (create/instantiate) a COM object: there is a Local Activate (LA) and Remote Activate (RA) permission. If an activation is attempted when an object’s COM server hasn’t been launched yet, you also need launch permissions for that object: a Local Launch (LL) and a Remote Launch (RL) permission exists. Last but not least, there are also Local Access (Local Access calls, LC) and Remote Access (Remote Access calls, RC) permissions which determine who can call the COM object. Asking activation (and so possibly a launch) occurs through the “DCOM Server Process Launcher” Windows service (with the technical name “DcomLaunch”). The activation information has been registered in the registry by the COM server at installation time. Oh, if you wonder what this launch is all about, it depends a little bit on the type of COM object. For instance, for an out-of-process COM object not related to a Windows service (type “Local Server”), the related executable is started. For a COM object related to a Windows service (whether out-of-process or in-process) (type “Local Service”) the service is started.

I’m not going deeper about (D)COM in this blog post, as it would take me way too far. You know more than enough for this article.

Side note: the event source DistributedCOM is technically registered with the name “DCOM” (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\System\DCOM). No DLL is configured here, but there is a referral to a GUID ({1B562E86-B7AA-4131-BADC-B6F3A001407E} ) for more information through the REG_EXPAND_SZ named value providerGuid. A provider with this GUID is registered in the registry at the location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{1b562e86-b7aa-4131-badc-b6f3a001407e} (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers is the place where event providers are registered), which contains the provider’s name (Microsoft-Windows-DistributedCOM) and the DLL that is used for the event logging (oleres.dll).

The error…

Ok, the error… The description tells us the user NT AUTHORITY\SYSTEM (= LOCAL SYSTEM), with SID S-1-5-18 (which is always the SID for LOCAL SYSTEM), wants to launch a local COM object from the system the event is logged on (so localhost, hereby mentioned as LocalHost), so the attempted launch is a so-called Local Launch. This launch is attempted through LRPC, the underlying “transport”/”communication” mechanism for (local) COM. The COM object (and thus COM server (application), here called “COM Server application”) is identified by it class ID (CLSID) and application (AppID, here mentioned as APPID). The CLSID is {05D1D5D8-18D1-4B83-85ED-A0F99D53C885}

and the APPID is {AD65A69D-3831-40D7-9629-9B0B50A93843}. It seems the permission settings for this COM object don’t grant SYSTEM the Local Launch right for this application. (D)COM stuff can be configured through the MMC snap-in Component Services.

Let’s find out which COM object we’re dealing with. A CLSID is registered in the registry at this address:

  • 32 bit Windows or 64 bit COM classes on 64 bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID
  • 32 bit COM classes on 64 bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID

For our CLSID we find HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{05D1D5D8-18D1-4B83-85ED-A0F99D53C885} on 64 bit Windows (on 32 bit Windows this would be HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{05D1D5D8-18D1-4B83-85ED-A0F99D53C885}, but the latter path isn’t there on 64 bit Windows).

Figure 4

We see our CLSID is registered at the 32 bit level, has a related AppID {AD65A69D-3831-40D7-9629-9B0B50A93843} and carries the name “CCM WMI Event Provider”. The AppID is registered in the registry at the following locations:

  • 32 bit Windows or 64 bit COM objects on 64 bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID
  • 32 bit COM objects on 64 bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\AppID
    • = HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\AppID
    • = HKEY_CLASSES_ROOT\Wow6432Node\AppID

Figure 5

Figure 6

Figure 7

Figure 8

We see our AppID is registered at the 64 bit and 32 bit level (on 64 bit Windows) and has the name “SMS Agent Host”.

So, SMS Agent Host is a COM object of the type (class) “CCM WMI Event Provider”. The latter is a WMI Event provider for System Center Configuration Manager (SCCM) client, also called Client Configuration Manager (CCM). Perhaps you know SCCM also under the name of ConfigMgr. Anyway, it’s actually more than just a provider of WMI Events, as it implements a great part of the client functionality. The instance name is “SMS Agent Host”, the “host” containing the SCCM client, which is an agent. SMS stands for Systems Management Server and is the former name of System Center Configuration Manager. So, in a nutshell: the COM object we’re dealing with implements at least a part of the core of the SCCM client.

A COM object can be of a certain type. Let’s start Component Services, look for the COM object and get its properties, so you can get to know the application type of this COM object. Open Component Services from Administrative Tools (or run “dcomcnfg”) and expand Component Services – Computers – My Computer – DCOM Config.

Figure 9

Then go to the COM object’s name, SMS Agent Host, right-click it and select “Properties”. A dialog box appears:

Figure 10

On the General tab we see the field “Application Type”, with the value “Local Service”. This means the COM object is of the Windows service application type, which actually means it’s a COM object that actually implements a Windows service. To be complete: the file that implements the Windows service is a COM server containing the COM object, which represents the “real” Windows service. The field “Service Name” contains the technical name of the Windows service (“CcmExec”), as can also be read in the registry from the REG_SZ named value LocalService (see figures 5 and 7). The friendly name of this service is SMS Agent Host (indeed, the same name as the actual COM object):

Figure 11

As already said, some Windows services have their own executable to run, others rely on a generic Windows service hosting executable (svchost.exe). In the last case the Windows service is implemented in a . The “path to executable” (see figure 10) tells us that’s not the case, so our service runs in its own process, with the image named “CcmExec.exe” (the full path is C:\Windows\SysWOW64\CCM\CcmExec.exe on 64 bit Windows). For completeness, a Windows service is described through its own key (with the technical service name as the key name) in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services, so for our service this is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CcmExec. This key also tells us which executable implements the Windows service (or thus the COM server/object). For this type of Windows service this is defined by the REG_EXPAND_SZ named value ImagePath.

So, with all this new information, let’s translate the error into a more understandable form. The system (as the user SYSTEM) tries to locally launch the COM object “SMS Agent Host”, which runs as the SMS Agent Host Windows service. The problem is this seems to fail, because SYSTEM doesn’t seem to have the permission to ask for a Local Launch of this COM object.

Let’s take a look at the permissions. Right-click “My Computer” in Component Services and select “Properties”. Go to the “COM Security” tab and note the “Launch and Activation Permissions” section. Click the button “Edit Default…” and a new dialog box (“Launch and Activation Permission”) pops up. On the one and only tab (“Default Security”) we can see SYSTEM has the Local Launch permission. Of course this is the permission set at a general level, but we can check if something has changed on the specific COM object level. Right-click the COM object, select Properties and select the Security tab. You see everything, including the “Launch and Activation Permissions” section, is not grayed out as is the case for many other COM objects.

Figure 12

Figure 13

We see the COM object’s launch and activation permissions don’t follow the default settings and are customized (the radio button for the choice “Customize” is selected). Click the “Edit…” button and you can see in the new dialog box SYSTEM does NOT have Local Launch permissions for this COM object (at the contrary, it is even denied)!

If you give SYSTEM the Local Launch permission for our COM object and remove the deny permission, you will see the error isn’t logged anymore! But is this what we really want…? If you give the permission the SMS Agent Host service can be started by the “launcher”, but hey, take a look again at figure 11: the Windows service’s startup type is set to Automatic (well, that is, by default). This means the service should be running in a “normal” situation, so then why this Local Launch attempt?

I’ve analyzed some other events just before and after the event described here and I’ve noticed a pattern. It seems our DCOM error only appears a short while before the SMS Agent Host service is stopped. Personally I think “something” needs this service and if the service isn’t available anymore, I tries to “local launch” the service’s COM object (resulting in starting the service). This fails because of a lack of permissions, but the permissions should suffice the way they are (except when you would do special stuff with a weird, extreme form of customization), as typically Windows services’ COM objects are only meant to be launched by the Service Control Manager (SCM). Let’s call that tight (but correct) security. So its seems “something” is behaving in a way it actually shouldn’t… Or is that “something” a special case… And if so, does that mean that we should assign the Local Launch permission (and remove the deny permission) to SYSTEM…? For that to know, we should get to know more.

Figure 14

Let’s think about it again. The local launch pops up because the service is down. But on the other hand the event telling us the service is down is logged later! So it could be the SCCM client is having a hard time at a certain moment or is busy cleaning up before the final stopping, still being started “officially”, but in practice not able to behave correctly/completely. This could make that “something” think there is something wrong, triggering the local launch attempt, which of course fails.

Stopping the service doesn’t trigger the attempt, so it must be something internal to the SCCM client (which could be right, as the service runs under SYSTEM, the “user” the error was logged for). I think part of the SCCM client incorrectly tries to get up the SCCM client’s Windows service if that one seems to have difficulties.

In this article I’m talking about SCCM 2007. In the meantime SCCM 2012 has been released. I hope this kind of bug or “bad” design isn’t present in the latest version of SCCM. Of course it’s only a minor issue: the performance impact is extremely low and it’s far from a disaster to see this error in the event log and ignore it. Yup, ignore it, that’s what you should do, as you can do nothing about it. Yes, you could assign the Local Launch permission and the error will disappear, but at the same time security has been opened (everything running as SYSTEM can now local launch the COM object, so not only to correct our particular scenario). Secondly, the SCCM client’s service stops and starts on its own anyway, so what would we win? Well, nothing, as the local launch would fail too I guess, as it’s attempted at a moment the service hasn’t been stopped yet. So assigning the Local Launch permission doesn’t change a thing, except no more error logging, but in a less secure environment, while nothing else actually changes and the local launch attempt would still fail anyway. I know most sources on the Internet “solve” the issue by assigning the permission, but my advice would be to leave it the way it is now. I think this local launch shouldn’t be here at all…

Side note 1: for completeness it could be interesting to know what OLE DB is. It stands for “Object Linking and Embedding, Database” and is also called OLEDB or OLE-DB. It has nothing to do with the technology that was formerly called OLE, but it’s a set of interfaces exposed through COM to access data from different kinds of sources in a uniform way. OLE-DB is a successor of ODBC and extends the functionality with non-relational databases too (so it’s broader than just SQL). ODBC, by the way, stands for Open Database Connectivity, is similar to JDBC and offers applications access to DBMS systems in a uniform way, with ODBC drivers as intermediates for the translation, while the ODBC Driver Manager (DM) takes care of the loading of those drivers. ODBC drivers exist for many, many DBMS systems, like MySQL, Oracle, SQL Server,… An OLE DB-ODBC bridge exists to make it possible for applications to use OLE DB, while under the hood the requests are forwarded to ODBC. ODBC was first released as version 1.0 in 1992 and the latest version is 3.8 (included in Windows 7). OLE DB also has some kind of translation engine between applications and data sources and it’s called an OLE DB provider, while the applications using OLE DB are called OLE DB consumers. The future of OLE DB is unclear and it seems it will become something legacy soon. Even the older ODBC is called better for performance… Another data source interface is Jet Data Access Objects (DAO), which was launched with version 1.0 in 1992 under the name of VT Objects, but is deprecated now, leaving version 3.6 as the latest one. Also old and forgotten is Remote Data Objects (RDO), which could connect with ODBC. Anyway, the latest is ActiveX Data Objects (ADO), a set of interfaces exposed through COM and using OLE DB “behind the scene”. The .NET variant of ADO, ActiveX Data Objects for .NET (ADO.NET), is quite different though, but builds on OLE DB too. Don’t be confused with ADO.NET Entity Framework (EF), which is the object-relational mapping (ORM) framework of ADO.NET.

Side note 2: besides the AppID, which refers to the “SMS Agent Host” Windows service (that uses CcmExec.exe) in this case, the CLSID has 2 sub keys:

  • LocalServer32: “a local COM server”, but only for the out-of-process scenario and not related to a Windows service. It refers to the same CcmExec.Exe executable.
  • InProcServer32: an in-process COM server. It contains a reference to a DLL implementing the COM object (C:\Windows\System32\CCM\StatusAgent.dll for 32 bit Windows and C:\Windows\SysWOW64\CCM\StatusAgent.dll for 64 bit Windows).

This means the COM class exists in 2 forms: a standalone exe and a DLL. The executable is defined for use as a “normal” standalone process, but through the AppID also for use in a Windows service. The only real instance (COM object) defined is for the latter. For the other scenarios there is no predefined instance registered (the DLL could be loaded in any process and the executable can be launched many times too…).

Figure 15

Figure 16

Note that the executable loads the DLL (as I can show you thanks to Process Explorer), meaning the DLL contains the real functionality and CcmExec.exe exposes it to a broader level. So the core of the SSCM client is the SMS Agent Host Windows service, implemented by CcmExec.exe, which loads StatusAgent.dll, a WMI Event provider for SCCM. The AppID is probably called “SMS Agent Host” too, because it refers to the Windows service with the same name and CcmExec.exe, although technically the real COM functionality is what is really implemented in the DLL. It all makes sense now, right? J

Figure 17

Just to end (and then you deserve a drink) 2 screenshots of the file details of CcmExec.exe and StatusAgent.dll. The first is described as the CCM Executive, while the second is just called the “Status Agent”.

Figure 18

Figure 19




14 thoughts on “DCOM error related to SCCM

    b said:
    15/11/2012 at 04:26

    An impressive and comprehensive article

    Josh said:
    10/01/2013 at 23:05

    The only article that hit the nail on the head. My SCCM 2012 server was having this exact issue and nowhere else had this information. Not the windows-noob guys or Microsoft. Thanks for alleviating the panic.

    James said:
    28/04/2013 at 00:55

    I wish Technet would have articles this well detailed, I have a question about SCCM application catalog, everytime I open the CMApplicationCatalog website, it loads and then errors out with Cannot connect to application server. This error has driven me to almost give up with System Center, I cannot solve this problem,. I have uninstalled the MP and website roles many times and reinstalled, if you cAN help with this problem please contact me or post an answer with what more info you need thanks again for a great article.

    Samuel said:
    17/06/2013 at 17:38

    Wow, This is a good paper. Thanks.

    Samuel F.

    Manolis P. said:
    12/08/2013 at 10:22

    Great Article. Thanks.

    Thorbjørn Heidner said:
    05/12/2013 at 17:19

    Great article! I like the extensive detail level, and well descriped “issue”. Thanks a lot.

    […] here DCOM error related to SCCM A good blog explaining DCOM issues and the sccm […]

    B.v.Zanten said:
    19/08/2014 at 08:19

    Indeed a great article! I encounter the error when the SCCM service is stopped, and then becomes started by the scheduled task “Configuration Manager Health Evaluation” in Task Scheduler Library – Microsoft – Configuration Manager. This scheduled task runs every night on every client and does a few things, including checking the ccmexec service and starting it if it isn’t started. At that point I get the DCOM permission messages in Event log

    Zadoc said:
    05/01/2015 at 13:37

    Wow. Awesome article. Thanks for sharing!

    kilroyonline said:
    08/04/2015 at 23:08

    Superb article. Thank you!

    Ben-z Lawrence said:
    30/04/2015 at 17:34

    Saw the error in the event log (Win7-64) and looked it up. I’ve written COM objects before (not DCOM) so I actually understood this article. I wanted to say – this is the MOST comprehensive and informative article I think I’ve ever read. As you suggested, I’ll leave it alone and ignore it. Thank you for the time you spent on this!

    Mark Reny said:
    04/03/2016 at 18:25

    I have a few systems within the organization that I am now working for. The above article is exactly What I am experiencing with these systems. I am Using SCCM 2012 R2 and the clients are Win 7 Enterprise X64. These systems are no longer reporting into SCCM so I am unable to remotely manage them when it comes to applying new packages or applications. Is the simplest thing to do is uninstall SCCM and re-install or even re-image the system and go from there. Any suggestions would be greatly appreciated.

    Daniel said:
    03/10/2017 at 13:08

    Thanks for this great detailed article. (D)COM has become a lot clearer to me now. I have this error in a somewhat other form (another user and another COM object) but will take another look at this with the info from your article. Cheers!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s