Yet another DCOM error related to SCCM

Posted on Updated on

(or a few things you need to know about DCOM, DCM 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

The following screenshots are taken from a session which had a Dutch language configured, so it differs a bit from the description above.

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 {B07C1D3E-637B-4C71-BC2F-06665F376A59}

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\{B07C1D3E-637B-4C71-BC2F-06665F376A59} on 64 bit Windows (on 32 bit Windows this would be HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{B07C1D3E-637B-4C71-BC2F-06665F376A59}, 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 “DCM Agent Class”. 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) “DCM Agent Class”. The latter the DCM client agent part of the System Center Configuration Manager (SCCM) client, also called Client Configuration Manager (CCM). Perhaps you know SCCM also under the name of ConfigMgr. Anyway, DCM stands for Desired Configuration Management, makes it possible to define configuration baselines and check systems against them and is part of the SCCM software package (it used to be a separate “solution accelerator”, but that lies in the past now). “SMS Agent Host” is 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, including the DCM client agent.

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? In my case I haven’t found an event that told me SMS Agent Host wasn’t up and running at the time of the logged error…

I’ve analyzed some other events just before and after the event described here and I’ve noticed the error was logged a little bit after the SMS Agent Host was started, even before another DCOM error that typically occurs some time after the SCCM client starts up (read for more information). The only difference is “the other” DCOM error happens every time after SMS Agent Host starts, while the DCM related DCOM error has only been logged once… I think the SCCM client was still starting up, so the DCM client agent wasn’t still (completely) up and running; something running as SYSTEM thought it was down and tried to launch it again, but normally this shouldn’t be needed (that’s why the permissions for a local launch are missing for SYSTEM). It’s not really clear to me what that something is, but it wouldn’t surprise me if it’s something internal to the SCCM client. In my case DCM is enabled (see figure 14), but I don’t know if it could occur when DCM is disabled (it could be, as disabling DCM also disables the DCM client agent, but on the other hand it could still be the DCM client agent itself should always be there (even if it doesn’t do a thing) (just like it’s the case with the NAP client agent; see the link a few sentences above) and as the error refers to the launching of this client agent, this could mean it can also occur when DCM is disabled… So I don’t know the answer on that one…). The error seems to be very occasional, so I guess it only happens when the system is having a hard time with serious performance degradation. In my case it happened at boot time…

Figure 14

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). So assigning the Local Launch permission doesn’t change a thing, except no more error logging, but in a less secure environment, while the situation does get better on its own (as the SCCM client is still starting up, so a little bit more patience and everything probably works fine, except when timing would be important here, but I don’t have any proof or suspicion for that). I think this local launch shouldn’t be here at all (and thus not the error being logged), as IMO it should be checked first if permissions allow the local launch action…

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 a sub key 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. This means the COM class exists in 1 form: a standalone exe. 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 executable can be launched many times…).

Figure 15

Side note 3: To finish I would just like to show a few other places where the CLSID and AppID can be found in the registry. I’m not going to discuss their meaning here (as it doesn’t really matter for the purpose of this blog post), but it can be interesting to be aware of their existence.

Figure 16

Figure 17

Figure 18

Figure 19




3 thoughts on “Yet another DCOM error related to SCCM

    i3laze said:
    16/04/2013 at 14:43

    That’s nice article. But what if i get this error everytime i press F5 on Software Center app? This way app show clear list, without correct apps available.

    i3laze said:
    16/04/2013 at 14:50

    Sometimes after “Microsoft Policy Platform Local Authority” has started (set as Manual) and everything works. WTF with this SCCM 2012 🙂

    FoxDeploy said:
    15/10/2013 at 15:21

    I think this is an extremely informative article, nice write-up!

    It may benefit from a short summary in the beginning though, I know I got lost for a bit in the detail!

Leave a Reply

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

You are commenting using your 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