WCF is changing the way we build software and make disparate systems work together. But configuration, management and diagnostics are WAY too complicated. I sure by the time Windows 2012 comes out, it will have a nice UI and be easy to fix, but in its current state (which is really 2.0) it is a hassle to administer. One of the systems that WCF depends on is the WMI Service. In working with my client’s data trying to get a WCF testbed up and running, I discovered that the WMI was not allowing logging to the Event Log
The WMI provider was not registered.
WMI Object: System.ServiceModel.Administration.WbemProvider/9144789
Error:80041003
Process Name: w3wp
Process ID: 3348
That may not seem like a big problem, on the other hand a system that is not working on a fundamental level is a system that is suspect until proven innocent. So I set out to make sure the underlying WMI Service was working as expected.
Google search sent me to download the WMI Service Diagnostics tool from MS. Its a VBS file that outputs a bunch of test results, but doesn’t fix breaks (just let’s you know what they are and makes suggestions). So out of 778 things the diagnostics looked at, and think about that, there are 778 things to LOOK AT, I had 9 errors entries that boiled down to this.
They were
- (CheckWMIProviderRegistration) : WMI Provider 'TPAUTOCONNDLL' DCOM registration data '{2C6594DB-04AD-490F-A447-DC8E2772E9CB}' is missing or is access denied.
- !! ERROR: Actual trustee 'NT AUTHORITY\NETWORK SERVICE' DOES NOT match corresponding expected trustee rights (Actual->Default)
- !! ERROR: Actual trustee 'NT AUTHORITY\LOCAL SERVICE' DOES NOT match corresponding expected trustee rights (Actual->Default)
- !! ERROR: Default trustee 'EVERYONE' has been REMOVED!
- !! ERROR: Overall WMI security status: ................................................................................. ERROR!
This blog entry is for you folks out there who may come across this error and how I solved them (if I did).
I’m going to leave the first one for last, and take care of the last one first,
The diagnostic puts out the error with suggested fixes, let’s start with the last piece of information provided: Overall WMI security status. We can quickly dispose of that one; this is just letting us know we had some errors, and there is nothing to do directly with this error.
Items 2, 3, and 4 are all related right next to each other in the output file. here is what was in the output log
** WMI namespace security for 'ROOT/SERVICEMODEL': ..................................................................... MODIFIED.
!! ERROR: Actual trustee 'NT AUTHORITY\NETWORK SERVICE' DOES NOT match corresponding expected trustee rights (Actual->Default)
** - ACTUAL ACE:
** ACEType: &h0
** ACCESS_ALLOWED_ACE_TYPE
** ACEFlags: &h2
** CONTAINER_INHERIT_ACE
** ACEMask: &h1
** WBEM_ENABLE
** - EXPECTED ACE:
** ACEType: &h0
** ACCESS_ALLOWED_ACE_TYPE
** ACEFlags: &h12
** CONTAINER_INHERIT_ACE
** INHERITED_ACE
** ACEMask: &h13
** WBEM_ENABLE
** WBEM_METHOD_EXECUTE
** WBEM_WRITE_PROVIDER
**
** WMI namespace security for 'ROOT/SERVICEMODEL': ..................................................................... MODIFIED.
!! ERROR: Actual trustee 'NT AUTHORITY\LOCAL SERVICE' DOES NOT match corresponding expected trustee rights (Actual->Default)
** - ACTUAL ACE:
** ACEType: &h0
** ACCESS_ALLOWED_ACE_TYPE
** ACEFlags: &h2
** CONTAINER_INHERIT_ACE
** ACEMask: &h1
** WBEM_ENABLE
** - EXPECTED ACE:
** ACEType: &h0
** ACCESS_ALLOWED_ACE_TYPE
** ACEFlags: &h12
** CONTAINER_INHERIT_ACE
** INHERITED_ACE
** ACEMask: &h13
** WBEM_ENABLE
** WBEM_METHOD_EXECUTE
** WBEM_WRITE_PROVIDER
**
** WMI namespace security for 'ROOT/SERVICEMODEL': ..................................................................... MODIFIED.
!! ERROR: Default trustee 'EVERYONE' has been REMOVED!
** - REMOVED ACE:
** ACEType: &h0
** ACCESS_ALLOWED_ACE_TYPE
** ACEFlags: &h12
** CONTAINER_INHERIT_ACE
** INHERITED_ACE
** ACEMask: &h13
** WBEM_ENABLE
** WBEM_METHOD_EXECUTE
** WBEM_WRITE_PROVIDER
**
** => The REMOVED ACE was part of the DEFAULT setup for the trustee.
** Removing default security will cause some operations to fail!
** It is possible to fix this issue by editing the security descriptor and adding the ACE.
** For WMI namespaces, this can be done with 'WMIMGMT.MSC'.
** Note: WMIDiag has no specific knowledge of this WMI namespace.
** The security diagnostic is based on the WMI namespace expected defaults.
** A specific WMI application can always require a security setup different
** than the WMI security defaults.
So how do I go about solving this one, Let’s start with a google search on ERROR: Actual trustee 'NT AUTHORITY\LOCAL SERVICE' DOES NOT match corresponding expected trustee rights WMI First link leads us to WMI Problem - Mike in Nebraska, Well no one has responded to this gentleman’s enquiry, but I note that he mentions he has installed .NET 3.5 with SP1, which I have done so as well, he then mentions that he is not sure how to fix it in WMIMGMT.MSC.
Now THAT looks very promising WMIMGMT.MSC is a snap-in management console, so off to run and try running that.
At first things don’t look too promising, but then I try a right mouse click then Properties, and that looks MUCH more promising
Since security seems to be the issue, let’s look at the Security Tab, and all of my errors are related to the Root\ServiceModel, so let’s look at the security permissions on that.
And hey, what do you know, everyone is missing from it
So to start with, let’s see what the permission’s are for Everyone (and local service and network service) on a different node that didn’t have any reported issues.
And local service and network service have the same permissions, so I’ll go correct those, and run the WMIDiag again.
And that fixed those problems so just one more to go
Finally here is the information on Item 1.
!! WARNING: WMI provider DCOM registrations missing for the following provider(s): ..................................... 1 WARNING(S)!
** - ROOT/THINPRINT, TPAutoConnDLL ({2C6594DB-04AD-490F-A447-DC8E2772E9CB})
** Provider DLL: 'WMI information not available (This could be the case for an external application or a third party WMI provider)'
** => This is an issue because there are still some WMI classes referencing this list of providers
** while the DCOM registration is wrong or missing. This can be due to:
** - a de-installation of the software.
** - a deletion of some registry key data.
** - a registry corruption.
** => You can correct the DCOM configuration by:
** - Executing the 'REGSVR32.EXE <Provider.DLL>' command.
** Note: You can build a list of classes in relation with their WMI provider and MOF file with WMIDiag.
** (This list can be built on a similar and working WMI Windows installation)
** The following command line must be used:
** i.e. 'WMIDiag CorrelateClassAndProvider'
!! WARNING: Re-registering with REGSVR32.EXE all DLL from 'C:\WINDOWS\SYSTEM32\WBEM\'
** may not solve the problem as the DLL supporting the WMI class(es)
** can be located in a different folder.
** You must refer to the class name to determine the software delivering the related DLL.
** => If the software has been de-installed intentionally, then this information must be
** removed from the WMI repository. You can use the 'WMIC.EXE' command to remove
** the provider registration data.
** i.e. 'WMIC.EXE /NAMESPACE:\\ROOT\THINPRINT path __Win32Provider Where Name='TPAutoConnDLL' DELETE'
** => If the namespace was ENTIRELY dedicated to the intentionally de-installed software,
** the namespace and ALL its content can be ENTIRELY deleted.
** i.e. 'WMIC.EXE /NAMESPACE:\\ROOT path __NAMESPACE Where Name='THINPRINT' DELETE'
** - Re-installing the software.
Well, to start with it seems reasonable to try to run the RegSvr32.exe on the TPAutoConnDll, It may not work, but it isn’t working now, so a quick look in that hint path ‘c:\windows\system32\wbem\’ doesn’t show that file, so I can’t register it there. A quick Google search on the file only reveals 5 links, non of which are any help. So I have the GUID of the item, its off to regedit and see if I can find it thru there.
It doesn’t exist at all, which means it’s not on my system, so I’m going to assume (for now) that I can safely delete it from the WMI using the suggestion in the warning. WMIC.EXE /NAMESPACE:\\ROOT\THINPRINT path __Win32Provider Where Name='TPAutoConnDLL' DELETE
Run the diagnostics once again, and no errors, so finally it’s time to retry the process I used earlier where I first saw my log entries, and see what I come up with.
Well I still get my original error:
The WMI provider was not registered.
WMI Object: System.ServiceModel.Administration.WbemProvider/9144789
Error:80041003
Process Name: w3wp
Process ID: 3348
which means I have more work to do. So I do a Google search on System.ServiceModel.Administration.WbemProvider and there are only 6 hits, none of which help.
I do see a note about the logging diagnostics for WCF can cause issues with performance counters, but I don’t have those turned on in my config file.
I’ll press on for now, and if I find a fix I’ll amend this entry.
