Another DCOM error related to SCCM

Posted on Updated on

(or learn some connections between DCOM, SENS 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

Figure 4

I first discovered the error on a Remote Desktop Session Host (RDSH), but it’s not specific for RDSH; at the contrary, it’s a quite generic issue. I have already said too much with the title, so yes, it’s System Center Configuration Manager (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 {1CCB96F4-B8AD-4B43-9688-B273F58E0910} 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\CLSID\{1CCB96F4-B8AD-4B43-9688-B273F58E0910} on 32 bit Windows and on 64 bit Windows we find HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{1CCB96F4-B8AD-4B43-9688-B273F58E0910}.

Figure 5

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 ISensLogon2 Implementation Class”. An AppID is also 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 6

Figure 7

Figure 8

Figure 9

We see our AppID is registered at the 32 bit level and on 64 bit Windows also on the 64 bit level. It’s name is “SMS Agent Host”.

SMS Agent Host is a COM object of the type (class) “CCM ISensLogon2 Implementation Class”. The latter is a class for System Center Configuration Manager (SCCM) client, also called Client Configuration Manager (CCM). Perhaps you know SCCM also under the name of ConfigMgr. Anyway, the class implements an interface named ISensLogon2 (interfaces typically begin with the “I” prefix). “Sens” actually means “SENS” here, standing for System Event Notification Service, a Windows service. An application can subscribe to SENS to receive notifications for certain events. ISensLogon and ISensLogon2 (the newer version of ISensLogon) handle notifications for logon events. 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.

So, SMS Agent Host is a COM object of the type (class) “CCM ISensLogon2 Implementation Class”, meaning it’s an SHA. 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 10

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

Figure 11

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 6 and 8). The friendly name of this service is SMS Agent Host (indeed, the same name as the actual COM object):

Figure 12

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 12) 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 13

Figure 14

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 12: 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 when the following event is logged in the System event log just before our event:

Figure 15

Figure 16

Figure 17

Event ID: 45058

Description: A logon cache entry for user USER@DOMAIN was the oldest entry and was removed. The timestamp of this entry was DATE TIME.

Source: LsaSrv

Level: Information

User: N/A



Task Category: Logon Cache

Keywords: Classic

OpCode: Info

The event source LsaSrv refers to the Local Security Authority (LSA). The event tells us a cached credential is deleted from the cache. By default Windows keeps 10 credentials cached (you can change this value through the registry or group policy; please read MS KB2555663 to know how: (“Cached User logon fails when LSASRV event 45058 indicates FIFO deletion of cached credential”)). When a new user logs on the oldest cached credential is removed from the cache to make place for the new user’s cached credentials. So this event not only means a cached credential was removed from the cache, but it also implies a user has logged on. This means SENS tried to notify subscribers of this kind of event. The SCCM client has subscribed to this event when it has started and has a COM object with an interface that takes care of those notifications (ISensLogon2). But it seems the SCCM client couldn’t be accessed and that’s why a local launch is attempted, which fails of course, because SYSTEM doesn’t have that permission on the COM object “SMS Agent Host”. And that’s correct, because the service should be started in a normal way. So, could it be that the service wasn’t up and running? Or perhaps the service experienced some problems? Well, take a look at the following event that was logged a few seconds before:

Figure 18

Indeed, the SCCM client wasn’t available (it was terminated unexpectedly, but I’m not going to discuss why, that’s food for another story J)! A little bit later the service went up again:

Figure 19

So it all makes sense, isn’t it? J The bottom line is this error is quite logical, as the service was terminated in a not-so-clean way, so SENS still wants to send logon notifications to the SCCM client. As long as you don’t fix the “unexpected terminations” of the SCCM client there is really nothing you can do about it… But you shouldn’t do a thing about the DCOM error itself. To be ignored! J

Does this mean there is a bug? No. It’s just a self-repairing mechanism, so in a way it’s a good thing. SENS tries to start the SCCM client again. The thing is it doesn’t make a real difference as long as SYSTEM doesn’t have the Local Launch permission for the COM object. I would call it a slightly bad design: SENS should check if it is allowed to launch the COM object before trying and certainly should not log an error for this when the permission is missing. Also, it should never try for a disabled service.

Oh yes, one last thing. I’ve written an article about another CLSID, but the same AppID. This means a certain COM object can be instantiated from different COM classes. The other class I’ve written about was “CCM WMI Event Provider”. The blog post was called “DCOM error related to SCCM” (hence this article’s name J) and can be found at




Side note: 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), 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 scenario (normal non-service use) there is no predefined instance registered (the executable can be launched many times too…).

Figure 20


3 thoughts on “Another DCOM error related to SCCM

    Anthony said:
    13/12/2012 at 15:35

    Hey I know this article is a few months old, but thank you! Great article on DCOM and it’s magical ways.

    Ollie Townsend III said:
    21/10/2014 at 14:26

    Like Anthony, I am a bit further behind finding this article, but I wanted to say thanks for the information. It cleared up an error that I was worrying about apparently for no reason.

    user12345 said:
    08/12/2014 at 22:32

    Agreed. Very detailed and helpful!

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