And I don’t know why. My strong guess is that it is related to one of the 10+ recent Microsoft security patches I’ve deployed to the fleet. (I’m looking at you .Net Framework 2.0)
The fix so far? Rebuild WMI and repair the SMS client.
I do this by:
- copying wmirebuild.bat and runrepair.vbs to the target computer.
the purpose of runrepair.vbs is to HIDE the running of wmirebuild.bat, so the end user doesn’t see it.
- remotely run runrepair.vbs via a PSEXEC command.
Yes, it’s a bit kludgey. It’s a fast fix.
runrepair.vbs
Dim objFSO,objNet,objShell,drive_status
Dim objWMIService, objProcess, colProcess, strComputer, strProcessKill
Dim sWbemPath,sSystemRoot
On Error Resume Next
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objShell = CreateObject("WScript.Shell")
sSystemRoot = objShell.ExpandEnvironmentStrings("%systemroot%")
'check that system32 directory exists.
If Not objFSO.FolderExists(sSystemRoot) Then
WScript.Quit(99)
End If
If Not objFSO.FileExists("c:\temp\wmirebuild.bat") Then
WScript.Quit(99)
Else
objShell.Run "c:\temp\wmirebuild.bat", 0, True
End If
Set objShell = Nothing
Set objFSO = Nothing
WScript.Quit
wmirebuild.bat
net stop ccmexec
net stop VMAuthdService
net stop winmgmt
c:
cd %systemroot%\system32\wbem
rem rd /S /Q repository
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
mofcomp cimwin32.mof
mofcomp cimwin32.mfl
mofcomp rsop.mof
mofcomp rsop.mfl
for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s
net start winmgmt
net start VMAuthdService
net start ccmexec
echo done >>c:\temp\done.txt
Then kick it all off with
psexec \\COMPNAME -s c:\winnt\system32\cscript.exe //B c:\temp\runrepair.vbs
Update: the wmirebuild.bat script I found here: How Do I Rebuild A Corrupt WMI Repository?
The next post in this series is, “Grumble grumble – revisiting the WMI fix”.
