Link to home
Start Free TrialLog in
Avatar of jeabou
jeabouFlag for United States of America

asked on

SCCM WMI client issue

I am having a problem with about 10-15 computers. They install the client just fine, but they do not report to the management point. I am quite certain it is a WMI issue based on the logs I have been reading on the client. I tried running every WMI fix I could find on the internet and still no luck. I have attached the log file generated when running WMI DIAG on one of the clients. I also attached the error message that shows up in the ClientIDManagerStartup.log file.
WMIDIAG-V2.0-XP---.CLI.RTM.32-PA.LOG
9-3-2010-2-05-13-PM.png
Avatar of Abdul Jalil Abou Alzahab
Abdul Jalil Abou Alzahab
Flag of Canada image

This may occur because of a missing registry key, check the below reg key and let me know

1. Open Regedit

2. Got o: HKLM\System\CurrentControlSet\Services\TCPIP\Paramaters

3. Create a Reg_sz called 'Domain'

4. add the name of domain
Have you tried reinstalling the SCCM Client? This often solves the WMI issues also.
I would say 95% of WMI problems are fixed by deleting the WMI repository:
Stop the SMSEXEC service
Stop the Windows Management Instrumentation Service
Delete (or rename): C:\Windows\System32\wbem\repository
Restart WMI service
Restart SMSEXEC
The CCM client should repair itself within 5 minutes.  See if the errors go away now.
Avatar of zivko
zivko

Hello,

To help you quickly solve your issue, I would recommend to use a wonderful and free tool called "SCCM Client Center" from R. Zander (thanks to him).

With this tool, you can directly perform a WMI repair but some other very interesting functions such as Hard Policies reset and much more.

Until now, using these functions (very well implemented in that utility) permit us to solve nearly 98% of our issues and the remaining 2% usually require a repair of the SCCM agent.

Here is the link:
http://sourceforge.net/projects/smsclictr/

Hope this will help.
Regards
Avatar of jeabou

ASKER

I have tried re-installing the SCCM client. That was the FIRST thing I did.

I have tried deleting the WMI repository.

I have used the SCCM Client Center tool too . All of those steps have already been taken.

I will check the registry key setting to see if that helps.
Avatar of jeabou

ASKER

I decided to try a different machine that is having this same issue that I have not worked on yet. Here are the steps I took in order.

1. I checked the registry setting (HKLM\System\CurrentControlSet\Services\TCPIP\Paramaters) on one of the clients that is having this issue, and that registry setting is there.

2. I uninstalled the client and deleted the CCMSETUP folder from C:\Windows\System32.

3. I then stopped the WMI service and renamed the C:\Windows\System32\wbem\repository to repository.old.

I then rebooted the computer

After rebooting, I installed the client. Same issue. Again, I believe it has to do with WMI because of messages I am seeing in the SETUPPOLICYEVALUATOR.LOG.

I have included screen shots of the Configuration Manager tabs and the log files that show up. You'll notice that not everything is filled in and there are only a few log files populating.
9-10-2010-8-48-53-AM.jpg
9-10-2010-9-00-58-AM.jpg
9-10-2010-8-12-05-AM.jpg
Avatar of jeabou

ASKER

I made a mistake in my previous post....the log file I attached is the ClientIDManagerStartup log file not the SetupPolicyEvaluator log.
Avatar of jeabou

ASKER

SMSCLUUI.LOG is showing the following error messages.
9-10-2010-9-17-17-AM.jpg
Just curious...can you run MSINFO32 from a PC, go to View>Remote Computer and then enter computer name of one of the problem PCs?  If that works, then WMI is actually working correctly and the problem lies elsewhere.  I've seen DCOM permission issues with Remote Control and SCCM.  It might not hurt to compare the DCOM permissions between a working computer and one that doesn't (I know you aren't having problems with remote control, but trying this shouldn't hurt):
http://technet.microsoft.com/en-us/library/bb633148.aspx
That link addresses the DCOM issue between the console and server, but you can use  dcomcnfg.exe to  compare the permissions on each PC.  The artcle states that WMI relies on DCOM, so if DCOM isn't workly correctly, that could be causing it to fail.
Avatar of jeabou

ASKER

OK, tried that. I am able to connect but it "can't collection information". I have attached a screen shot.

I am able to connect to the client remotely using Computer Management and can see all the local users and groups and even logs but when I click on Device Manager it just hangs.

Do you still think it could be related to DCOM?
9-10-2010-11-14-08-AM.jpg
I think we just confirmed it that is definitely a WMI issue and not a DCOM/SCCM issue.
I know you said you tried everything, but did you try:
rundll32.exe setupapi,InstallHinfSection WBEM 132 %windir%\inf\wbemoc.inf
from http://windowsxp.mvps.org/repairwmi.htm?  This should completely re-install WMI.
Avatar of jeabou

ASKER

OK, I tried running "rundll32.exe setupapi,InstallHinfSection WBEM 132 %windir%\inf\wbemoc.inf"

It did not fix the issue. :-(

I even repeated all of my prior steps after doing that and still.....nothing.

Any other ideas?
Avatar of jeabou

ASKER

I did that.....it is in my very first post.
Right you are: I missed that.
Now that I said DCOM was fine, I found this in the log file:

17669 21:24:52 (0) **    - An application has changed the COM/DCOM settings of OLE32.DLL and/or OLEAUT32.DLL.
17670 21:24:52 (0) **    - The registry settings of COM/DCOM has been damage or wrongly modified.
17671 21:24:52 (0) ** => To correct this situation, you must re-register the original COM/DCOM DLLs with REGSVR32.EXE
17672 21:24:52 (0) **    i.e. 'REGSVR32.EXE OLE32.DLL'
17673 21:24:52 (0) **    i.e. 'REGSVR32.EXE OLEAUT32.DLL'

and this
17603 21:24:52 (0) **    You can attempt to resynchronize the WMI performance classes with the existing Windows
17604 21:24:52 (0) **    performance counters with the following commands:
17605 21:24:52 (0) **    i.e. 'WINMGMT.EXE /CLEARADAP'
17606 21:24:52 (0) **    i.e. 'WINMGMT.EXE /RESYNCPERF'

Try running those commands, then re-run msinfo32 and see if you can attach to the computer remotely.
I just noticed something weird:
WMIDiag v2.0 started on Saturday, August 07, 2010 at 21:20.
This log is over a month old?  When did you run it?
I would also compare the running services (services.msc) on a working box and one that isn't work.  I believe WMI relies at least on the RPC service to be running.
Avatar of jeabou

ASKER

I did do as you suggested earlier today, I checked the services of two computers (one that was working and the one that wasn't) and could not find anything that looked out of the ordinary. I ran WMIDIAG again on the computer I have been working on will attach the log and text files. I will also attach a screen shot of all the services that are running. Normally, I would just re-image these systems but it is in a child division and I don't have the ability or desire to do so.
WMIDIAG-V2.0-XP---.CLI.RTM.32-CH.LOG
WMIDIAG-V2.0-XP---.CLI.RTM.32-CH.TXT
9-10-2010-8-08-29-PM.jpg
9-10-2010-8-08-57-PM.jpg
Avatar of jeabou

ASKER

Oh, also....I did run the four commands you suggested

'WINMGMT.EXE /RESYNCPERF'
'REGSVR32.EXE OLEAUT32.DLL'
'WINMGMT.EXE /CLEARADAP'
'WINMGMT.EXE /RESYNCPERF'

Uninstalled and re-installed the client.....and still the same result.
Avatar of jeabou

ASKER

Sorry, meant to include this:

'REGSVR32.EXE OLE32.DLL'
I hear you on rebuilds.  They are the last solution I use myself. This time I just used "wmi 0x80004002 No such interface supported" for a search query and came up with this batch file called fixwmi.cmd:
http://social.msdn.microsoft.com/Forums/en-US/Vsexpressinstall/thread/632ca405-1c38-405b-9ed3-01785c9f99d1
And these two deal with permission fixes:
https://www.experts-exchange.com/questions/23709629/SQL-2005-WMI-Problem.html 
http://boyersnet.com/blogs/chucks_blog/archive/2007/12/13/fix-for-sql-server-system-configuration-checker-cannot-be-executed-due-to-wmi-confiuration.aspx
The other thing you could try doing is running Procmon (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) on the bad PC, then connect to its WMI database from your PC while the trace is running.  After it fails, stop Procmon and attach the log (PML file) to this message.  This could show any possible permission issues.
Avatar of jeabou

ASKER

OK.....finally got it working. I think the problem may be related that these systems were migrated into our domain. I used the ADMT to migrate the computer accounts, but its possible not all of the security settings migrated as well. Not sure....anyway, I added Authenticated Users to have full control of HKLM\Software\Microsoft\WBEM\CIMOM and I added the network service account to the local admin group. After running process monitor I was able to see that there were access denied messages to that key.

I found the information that helped here:

http://social.msdn.microsoft.com/Forums/en-US/sqlsetupandupgrade/thread/ac1f944f-8446-4f37-b598-20ae6dd31b9b
I think you're right.  I have over 900 clients here and never seen that issue.  We went from Novell to Windows NT, so ADMT was never used here.
Avatar of jeabou

ASKER

I'd like to reward points to ALEINSS even though I found the solution on my own because had I not used process monitor I wouldn't have discovered that. Is there a way to do that while making my entry show up as the solution?
ASKER CERTIFIED SOLUTION
Avatar of Adam Leinss
Adam Leinss
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial