jeabou
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
WMIDIAG-V2.0-XP---.CLI.RTM.32-PA.LOG
9-3-2010-2-05-13-PM.png
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\r epository
Restart WMI service
Restart SMSEXEC
The CCM client should repair itself within 5 minutes. See if the errors go away now.
Stop the SMSEXEC service
Stop the Windows Management Instrumentation Service
Delete (or rename): C:\Windows\System32\wbem\r
Restart WMI service
Restart SMSEXEC
The CCM client should repair itself within 5 minutes. See if the errors go away now.
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
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
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.
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.
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\CurrentContro lSet\Servi ces\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\r epository 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
1. I checked the registry setting (HKLM\System\CurrentContro
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\r
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
ASKER
ASKER
I made a mistake in my previous post....the log file I attached is the ClientIDManagerStartup log file not the SetupPolicyEvaluator log.
ASKER
SMSCLUUI.LOG is showing the following error messages.
9-10-2010-9-17-17-AM.jpg
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.
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.
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 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,InstallHinfSectio n WBEM 132 %windir%\inf\wbemoc.inf
from http://windowsxp.mvps.org/repairwmi.htm? This should completely re-install WMI.
I know you said you tried everything, but did you try:
rundll32.exe setupapi,InstallHinfSectio
from http://windowsxp.mvps.org/repairwmi.htm? This should completely re-install WMI.
ASKER
OK, I tried running "rundll32.exe setupapi,InstallHinfSectio n 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?
It did not fix the issue. :-(
I even repeated all of my prior steps after doing that and still.....nothing.
Any other ideas?
Try running WMIDiag (http://www.microsoft.com/downloads/en/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en) and attach the log here.
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.
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.
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
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
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.
'WINMGMT.EXE /RESYNCPERF'
'REGSVR32.EXE OLEAUT32.DLL'
'WINMGMT.EXE /CLEARADAP'
'WINMGMT.EXE /RESYNCPERF'
Uninstalled and re-installed the client.....and still the same result.
ASKER
Sorry, meant to include this:
'REGSVR32.EXE OLE32.DLL'
'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.
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.
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\WB EM\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 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.
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
1. Open Regedit
2. Got o: HKLM\System\CurrentControl
3. Create a Reg_sz called 'Domain'
4. add the name of domain