none
WMI FIX SCRIPT FOR WINDOWS XP AND 7

    Domanda

  • Hello All,

                There is very famous script to repair WMI.  Can anyone share it so that I can repair my WMI and instlal clients.  Thanks.

    domenica 23 ottobre 2011 13:41

Risposte

Tutte le risposte

  • Is this good:

     

     

    @echo on
     cd /d c:\temp
     if not exist %windir%\system32\wbem goto TryInstall
     cd /d %windir%\system32\wbem
     net stop winmgmt
     winmgmt /kill
     if exist Rep_bak rd Rep_bak /s /q
     rename Repository Rep_bak
     for %%i in (*.dll) do RegSvr32 -s %%i
     for %%i in (*.exe) do call :FixSrv %%i
     for %%i in (*.mof,*.mfl) do Mofcomp %%i
     net start winmgmt
     goto End
     
    :FixSrv
     if /I (%1) == (wbemcntl.exe) goto SkipSrv
     if /I (%1) == (wbemtest.exe) goto SkipSrv
     if /I (%1) == (mofcomp.exe) goto SkipSrv
     %1 /RegServer
     
    :SkipSrv
     goto End
     
    :TryInstall
     if not exist wmicore.exe goto End
     wmicore /s
     net start winmgmt
     :End

    • Proposto come risposta PaddyMaddy domenica 23 ottobre 2011 14:51
    domenica 23 ottobre 2011 14:12
  • Is this script famous/popular? Yes.

    Should you use it? No.

    Bad joo-joos as covered by the first major point in this blog post: http://blogs.technet.com/b/configmgrteam/archive/2009/05/08/wmi-troubleshooting-tips.aspx.

    Roger Zander's Client Center has the ability to actually repair WMI in a more graceful, non-destructive way.

    There are also third party solutions targeted at maintaining client health proactively including WMI.


    Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys
    domenica 23 ottobre 2011 15:19
  • I used the following when i had WMI issues on the client

    You can create a batch file with the following lines:

    %systemdrive%
    cd %windir%\system32\wbem
    net stop winmgmt /y
    for /f %s in ('dir /b *.dll') do regsvr32 /s %s
    if exist repository.old rmdir /s /q repository.old
    rename repository repository.old
    wmiprvse /regserver
    winmgmt /regserver
    net start winmgmt

    Next, run the batch file locally on the problem computer with Admin rights. WMI repository is now rebuilt.

     

    Though it didnt fix the problem for me as there were other DCOM related issues too so i had to try the Windows Repair and they were XP clients

     


    AMIM MUHAMMAD KHAN | CTTCNET USER GROUP LEAD | EVENT SPEAKER, MCT, MCTS, MCITP-ENTERPRISE, MCSA http://amimkhan.wordpress.com
    domenica 23 ottobre 2011 18:10
  • Renaming WMI is not a best think to do. I would suggest to keep this as last option.

    1. Use WMIDIAG tool to identify the problem.

    2. Try to repair it and If it's hapening again and again then find out the reason.

    3. If no other option left then goahead with the rename/deletion of the repositiry.

    If the WMI correction is pretty regular in your environment then I would suggest you to check the antivirus software scanning on repository is not causing the issue.


    Anoop C Nair - Twitter @anoopmannur

    MY BLOG:  http://anoopmannur.wordpress.com

    SCCM Professionals

    This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    lunedì 24 ottobre 2011 01:52
  • @Jason:  The client center does not allow does not connect to the client so one cannot repair the WMI through that? or can we?

    @Anoop:  Running WMIDIAG on scores of machines is very tedious.  Are you referring to c:\windows\system32\wbem directory to be excluded from antivirus?

    lunedì 24 ottobre 2011 06:49
  • @Jason:  The client center does not allow does not connect to the client so one cannot repair the WMI through that? or can we?
    WMI can also be repaired on remote machines using client center.
    Torsten Meringer | http://www.mssccmfaq.de
    lunedì 24 ottobre 2011 07:31
  • Thanks for the reply Torsten, but WMI Repair option does not highlight until SCCM Client Center is connected to the client.  And since it cannot connect to the client due to WMI Error, I cannot repair the WMI for the client.  And if I connecting wrongly do suggest. 
    lunedì 24 ottobre 2011 08:06
  • I use normally use's...CHRISTJAN'S CAT tool  http://blog.itminutes.net/?p=515

     


    This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    lunedì 24 ottobre 2011 08:16
  • Thanks for the reply Paddy.  I have that in place, but at the end, it fails to repair.  I do not know why, have used it before as well, but this time, it is failing to repair WMI.  I do not know why.

    lunedì 24 ottobre 2011 08:18
  • Howmany systems you have with this situation ? 

    If above all failed to repair the WMI.. only option is to Rebuild the system. if you don't agree then you might need to contact the Ms Support to resolve that issue.

     

    I am sure ..that above all mentioned steps would resolve your issues...

    before opting the support make sure that you have done these below ..

    http://myitforum.com/cs2/blogs/socal/archive/2007/08/22/troubleshooting-wmi-with-wmidiag.aspx

    http://windowsxp.mvps.org/repairwmi.htm

     


    This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    lunedì 24 ottobre 2011 08:43
  • Well, it all with client nto being installed on those machines.  When I looked into ccm.log, it showed WMI connection error.  Port 135 is accessable on client so it is not a firewall issue.  The SCCM Client Center does not connect to the client so that repair can be done.  The CAT does not fix it too. :(

    lunedì 24 ottobre 2011 10:00
  • Clients are on the WAN so any port that I might be missing?
    lunedì 24 ottobre 2011 10:00
  • what os does the client have?
    AMIM MUHAMMAD KHAN | CTTCNET USER GROUP LEAD | EVENT SPEAKER, MCT, MCTS, MCITP-ENTERPRISE, MCSA http://amimkhan.wordpress.com
    lunedì 24 ottobre 2011 12:27
  • XP AND 7.
    lunedì 24 ottobre 2011 12:31
  • Jason Sandys has a ConfigMgr client health startup script that I'd recommend checking out:

    http://blogs.catapultsystems.com/jsandys/archive/2010/12/30/updated-configmgr-startup-script.aspx

    Cheers,
    Trevor


    If this post was helpful, please click the little "Vote as Helpful" button :)

    Trevor Sullivan
    http://trevorsullivan.net

    lunedì 24 ottobre 2011 15:57
  • Thanks for the reply.  How would it help my cause.  The client is not installed on the clients.  Please advise.
    martedì 25 ottobre 2011 05:53
  • What you can do is try a windows repair on one of the machines and see if it helps solves your problem if it does then we can furthur investigate.

     

    Regards,

     

    Amim Muhammad Khan


    AMIM MUHAMMAD KHAN | CTTCNET USER GROUP LEAD | EVENT SPEAKER, MCT, MCTS, MCITP-ENTERPRISE, MCSA http://amimkhan.wordpress.com
    martedì 25 ottobre 2011 05:57
  • That is not fun mate.  There are scores of machines and besides there is nothing wrong with the operating system, sometimes WMI gets corrupted so was just looking for the WMI Repair script.
    martedì 25 ottobre 2011 06:28
  • I think, the first should be your clients and environment should be updated with the hotfixes available to fix the WMI errors?

    Have you tried to install them?

    Go through the below blog post and see this is applicable to you or not.

    Suggested hotfixes for WMI related issue on Windows platforms

     


    Anoop C Nair - Twitter @anoopmannur

    MY BLOG:  http://anoopmannur.wordpress.com

    SCCM Professionals

    This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    martedì 25 ottobre 2011 06:39
  • Dear blogpost missing?
    martedì 25 ottobre 2011 07:18
  • It was hyperlinked, viewing....

    martedì 25 ottobre 2011 07:19
  • Most of them are covered dear.  I am really tempted now to test the script? Any suggestions?

    mercoledì 26 ottobre 2011 11:15
  • Yes: test, test, test before deploying it into production.
    Torsten Meringer | http://www.mssccmfaq.de
    mercoledì 26 ottobre 2011 11:27
  • Im my experience, even if connecting using SCCM Client Center fails due to WMI etc, in most cases you can still use it to repair WMI.

    Make sure the account you use in SCCM Client Center has admin rights on the PC.  Click on the folder icon beside "Repair WMI" button.

    If "admin$\Temp" opens on the Client you are trying to fix... then "Repair WMI" should work.

    mercoledì 21 dicembre 2011 21:16
  • I can say that 9 times out of the 10 I have to do the wmi rename and repair option. The xp clients even after using a migration tool seem to have some real issues after a while. However, the clients before could have had issues as well but most of the time I end up spending time on these machines fixing ccm and fixing the wmi. I have a collection that will do the resinstall and working on a batch for the WMI as well. It seems though that it always comes back to the machines having configuration problems with the NIC cards, updated drivers and such. Also see lots of problems with the secedit file getting corrupt, after the fix which is adding a couple of reg entries in the batch and deleting the secedit, (which microsoft told us not to) but it fixes the issues that we were having as well. Again 9 times out of the 10 it seems to be related to ADMT migrations that we have done. I would not want to do that again and use that tool, image the machines and start fresh.

    Patrick Clark

    martedì 12 giugno 2012 11:55
  • Do not ever delete/rename the WMI Repository.  As per above / here 

    You can use PowerShell to troubleshoot and repair WMI ...
    http://blogs.technet.com/b/heyscriptingguy/archive/2012/03/29/use-powershell-to-troubleshoot-and-repair-wmi-errors.aspx

    As suggested, run WMIDiag.  It can be run remotely against multiple computers, using psexec, and bring back results to a central location.
    The doco for WMIDiag explains how.
    http://blogs.technet.com/b/askperf/archive/2012/02/03/wmidiag-2-1-is-here.aspx

    Here's how to repair WMI on Windows 7 ...
    http://blogs.technet.com/b/csstwplatform/archive/2011/05/20/how-to-reset-windows-7-wmi.aspx

    You may also want to look at WMI hotfixes here ...
    http://blogs.technet.com/b/askperf/archive/2011/08/05/suggested-hotfixes-for-wmi-related-issue-on-windows-platforms.aspx

    Re the secedit matter... put below into Google/Bing
    site:support.microsoft.com secedit.sdb


    Shane

    (Please "Vote as helpful" / "Propose as answer" / "Mark as answer"  if appropriate)



    sabato 16 giugno 2012 05:59
  • Thats not entirely true about deleting the WMI, it does not say NEVER delete. There are some cases where this has to happen with corruption and such..

    Don't delete the repository (though it may make problems seem to go away).

    Rebuilding the WMI repository is a destructive operation that can lead to data loss, applications breaking, and a whole host of slow to appear, difficult to diagnose problems.
    Generally speaking, the only time this operation should ~really~ be necessary is in the case of true corruption as indicated by tools such as WMIDiag or Winmgmt /verifyrepository.

    Can lost WMI data be recovered?
    Probably, but that's never a good state to be in. Therefore, I say avoid this operation whenever possible.
    On the flip side, I certainly recognize there is a tradeoff between operational needs and individual investigations.
    Over time some customers have seen that rebuilding the repository makes a problem seem to go away quickly. Typically this also comes with a loss of ability to find root cause, could mask other problems, and may not actually solve anything long term. On the whole I strongly recommend against deleting the repository folder as a means to resolving WMI issues.


    Patrick Clark

    lunedì 18 giugno 2012 13:56
  • the wmidiag is great but it takes way too long. That is great for 1 system, or troubleshooting a few systems manually. 



     I want something that simply tries to access wmi and runs a few querries, If it fails to return anything, then it rebuilds.  That way i can throw it in a start up script on 10000's of systems.  This is all for sccm.  SO the core things that it reports will get picked up anyway, and whatever info that may be missing (from some third party app that probably broke wmi in the first place i don't care about) That is what i find is 90% of our issues. We don't have the resources to troubleshoot 100's of systems.  the rebuild of the respository fixes 99% of our issues. What causes it to be corrupted, we never found a patern. 
    lunedì 14 gennaio 2013 14:13
  • The main thing that causes WMI corruption is users with local admin permissions doing stupid user things and users not cleanly shutting their systems down.

    Everyone wishes there was a magic button fix to WMI issues -- if one existed, everyone would be using it already. There simply is not a good answer for this IMO. Well, except upgrade to Win 8 which is supposed (to my knowledge) have a completely different WMI "engine".

    Assuming your client base is still on XP (where most WMI issues occur), have you deployed the recommend WMI hotfixes (from Shane's post above)? Have you removed local admins permissions from your users (this one will solve a lot of issues if you haven't done so already)?

    Mass and blindly deleting the repository is only fixing the symptom and is generally temporary as the true cause, in most cases, is as mentioned above: users. Very few workstation apps do anything with WMI, mostly just drivers.


    Jason | http://blog.configmgrftw.com

    lunedì 14 gennaio 2013 17:43
  • we are at sp3 already. I believe thos hotfixes where not applicable. 



    It could be users doing stupid things - our users are pretty locked down but when it comes right down to it, the sccm client being busted because of wmi is a critcal app. Be great to find the root causes via logs and so on, but generally if they can't get sccm working fairly quickly they simply send a tech to wipe and load the system again. 



    Normally when we spot check it's easy to fix, but i'd prefer a health check script that simply checks a few things and if it can't access wmi, the rebuilds the repository and kicks off a repair of sccm (even removes sccm and re-adds it). That would save a pile of work until we get to windows 8 :)
    mercoledì 16 gennaio 2013 22:58