DCOM 10009 Errors in HPSIM

[Rob Buxton]

Hi All,

Anyone else seeing these errors?
They seem to be generated whenever I trigger an Auto-Discovery for Servers that do not have any form of DCOM Access.

It seems about 2 errors are generated per non NT Server interrogated.

I didn't see this behaviour on CIM 7. But they are different servers and the CIM 7 Server is still on W2000 SP3.

[Steve Kadish]

Yes, I am getting them too. Lots and lots of them, and although they do arrive in batches, I don't think they are tied to my kicking off a discovery.

My SIM install is running on W2K SP4. I also get DCOM 10006 for NT4 servers:

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10006
Date: 1/5/2004
Time: 4:05:54 PM
User: NT AUTHORITY\SYSTEM
Computer:
Description:
DCOM got error "Class not registered " from the computer when attempting to activate the server:
{8BC3F05E-D86B-11D0-A075-00C04FB68820}

They are pretty much swamping the Event Log on the SIM server.

- Steve

[John Kramer · Accepted solution]

See the thread DCOM Windows System Events, HP indicates this is a problem they are looking into.

[Rob Buxton]

John,
Thanks for the pointer, I missed that thread.

[David Claypool]

We now have a workaround for this issue. Please note that this is a workaround and does not change the fact that during identification every device will be queried via DCOM to see if it speaks WMI. The request will fail, but it won't be logged. This also means that any valid issue won't be logged either, so proceed at your own risk:

On the machine where the WMIMapper is installed, and serves as the WMIMapper proxy for the HP SIM server, it is very possible that the error message 'DCOM was unable to communicate with computer using any of the configured protocols.' will appear in your NT Event Log during Initial Device Identification and Daily Device Identification. These error messages are not generated by WMIMapper. Rather, they are generated by the Microsoft Windows Management Instrumentation (WMI) service when it is unable to communicate with the target machine to get the WMI information. Most of the time, the target machine is a non-Windows machine.

You can disable logging the WMI errors to the NT Event Log by the following steps:

On the machine where WMIMapper is installed:
1). Stop the 'Pegasus WMI Mapper' service

2). Right mouse click on the 'My Computer' icon from desktop

3). Select 'Manage' from the pop-up menu, the 'Computer Management' page will be displayed

4). Expand the 'Services and Applications' node

5). Select 'WMI Control', and right mouse click on it, the 'WMI Control Properties' page will be displayed

6). Click on the 'Logging' tab on the top

7). Select 'Disabled' from the 'Logging level' section, click on the 'OK' button to close this page

8). From the 'Computer Management' window, double click on 'Services', then select 'Windows Management Instrumentation' service, stop it and then start it again

9). Start the 'Pegasus WMI Mapper' service from the 'Services' page

[Rob Buxton]

David,
Thanks for this, I've implemented it and will see what happens after the next discovery is run.

[Rob Buxton]

Nope still getting the errors.

I'm a bit confused by the "Pegasus WMI Mapper Service". I can find no mention of Pegasus here, I just stopped the WMI Mapper Service, made the changes and started the service.

[Steve Kadish]

I am also still getting the errors after discovery. I was able to follow all the steps, including starting and stopping the Pegasus WMI Mapper, which appears as one of my services.

Thanks,
- Steve

[David Claypool]

Okay, folks, thanks for the feedback; will advise. When I received the info, I passed it on without trying it out myself. I'll get my personal response and the response from the dev guys posted here as soon as I can.

[Tim McGue]

Can we revisit this error?

I've been trying to understand what is going on here. It looks like you are using The Open Group's Pegasus WMI Mapper. According to SIM documentation the Mapper does this:
"The WMI Mapper proxy is a configuration setting for WMI. The WMI Mapper receives client CIM/XML WBEM requests and converts the requests to WMI requests. The WMI results are converted to CIM/XML format and returned to the client."

OK, we also know that we are seeing the error for non-WMI enabled devices (i.e. ILO boards, Unix boxes, etc.). I don't think we can blame Windows for this error. I think HP SIM should not initiate WMI request to non-WMI enabled devices. It appears that (according to the same documentation) the following should occur:
"The Discovery and Identification task uses the proxies in the WMI Mapper proxy list to discover whether a system is a WMI-enabled system or not. If the system is WMI-enabled, then the identification information for that system based on that specific proxy is returned."

It seems like what should happen is a new device is discovered. If it is WMI enabled then it should allow future WMI calles be made to it. If not, no future calls and therefore no future DCOM 10009 errors. Is that the design intention?

I was trying to see if there was a flag or something set to signify this for the systems. When I looked at the "enabled protocols" for these non-WMI enabled devices WBEM was NOT one of the listed protocols.

So to me, it sounds like the fix is to not have HP SIM send WBEM/WMI requests to non WBEM/WMI enabled devices.

Thoughts?

Tim

[David Claypool]

This actually goes on all the time with all the protocols during identification tasks; it's just that the DCOM failure is the only one that shows up in the Windows event log.

In other words, during the "Daily Device Identification" task, hpSIM runs through a litany of "Do you..." queries to see if anything has changed. The theory is that you may have discovered a device and identified it only by ping and SNMP, but now web agents are loaded, and the only way to find that out is to query it periodically with all the protocols.

Eliminating DCOM 10009 will never be possible, because we'll always have to make at least that initial query. We have discussed, and at this point it doesn't look like it will make it into 4.1, is that once we have positively identified a device as "unlikely" to speak WMI (as Tim suggests, things like switches, iLO, etc) and to not ask it again during subsequent identifications. However, since it is possible that a WinNT box is discovered without WMI and that through adding the WMI package or upgrading to W2K, as long as the WBEM protocol box is enabled during Daily Device Identification, we will continue to ask it whether it speaks WMI, which will result in a DCOM 10009 until it does.

[Steve Kadish]

So, if I understand correctly, the behavior is not going to change - once per day, during the Daily Device Identification, we will get DCOM 10009 errors for every device which is not WMI enabled.

I know I can disable WBEM completely using the "global protocol settings" menu item. What would be the impact of this?

Thanks,
- Steve

[matthew hood]

any update to this issue

[Steve Kadish]

I would also like to know - my last question about disabling WEBM never got answered. Is this still an issue with HPSIM 4.1?

Thanks,
- Steve Kadish

[Gary Cooper_1]

Are there any updates on this issue? Or do we still have to live with loads of DCOM errors in the Event log?

Thanks,

Gary

[Rory_10]

Still no update on this problem?

[k_kovacs]

I am getting these errors with CIM 4.2 Doesn't seem to be any resolutions. My application guys are driving me hard to clear them up. I guess I will have to pass this message thread onto them to explain it is something HP is working on.

[David Claypool]

This isn't something that can be "fixed" as it is an outgrowth of supporting WMI.

During the Device Identification process, HP SIM interrogates each device to find out what its capabilities are. If you have enabled WBEM and have the WMI mapper installed, one of the interrogatories will be through DCOM as that is the transport WMI uses.

An attempted connection using WMI/DCOM to a device that does not support it (e.g. switch, printer) will result in a DCOM error. If you have multiple login/password combinations identified in the global protocol settings page, HP SIM will use each one of them in an attempt to make a connection. The ones that turn out to be invalid for a particular device will fail to log on and will result in a DCOM error.

[Robert Foster_2]

I've also gotten the following in my System Event Log:

* * *

DCOM got error "Class not registered " from the computer BLAH-BLAH when attempting to activate the server:
{5A5AA0AA-1DEB-4683-96B0-B43301E83971}

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

* * *

I've read through the above responses and I think I get the point. However, I compared the CLSID number above to those listed in the DCOM Component Services Control Panel and there is no match. In other words, there is one ID listed in the Registry that does not match an ID in the DCOM control panel. The program for the Registry entry is:
C:\WINDOWS\system32\HPBPRO.EXE

Which I assume is an HP program of some sort?

At one point yesterday I had to un-install the HP printer software and then reinstall it. My question/suggestion: Was the Windows Registry perhaps not updated to reflect the second install I did after my first un-install? Is this the source of the "class not registered" error, that the registry entry does not match any DCOM entry?

[David Claypool]

Robert:

HPBPRO.EXE is part of an HP Printer driver and is unrelated to HP Systems Insight Manager and this forum.

[Robert Foster_2]

Oh sorry, I thought this was a support forum. Most admins will move a post to a proper thread but I guess that is not possible here. I'll make my post elsewhere.

By the way, my search for similar threads on DCOM errors indicated links to this thread, that is why I posted here.

[Preston Gallwas]

This DCOM error is ...distressing to say the least.

App log set to rollover, i guess. *shrug*

[Rob Buxton]

This thread has started to take on a life of its own. So I'll let new threads be opened as appropriate.