Tagged: wmi

Change settings on all shares

We are enabling BranchCache on a few servers… and with that you probably want to change the settings on the shares you have.

Why not use some Powershell when you have the chance. 🙂

Get-WmiObject -Class Win32_Share | Where-Object -FilterScript {$_.Name -notlike '?$' -and $_.Name -ne "ADMIN$" -and $_.Path -ne ""} | ForEach-Object {
	Write-Host "Updating $($_.Name) - $($_.Path)"
	$netShare = NET SHARE $_.Name /Cache:BranchCache
	
	If ($netShare -notlike "*completed successfully*") {
		Write-Host $netShare -ForegroundColor Red
	}
}

Change /Cache:BranchCache to wahtever you want to do with the share.

Oh, btw… this works fine to do remote with something like this:

Invoke-Command -ComputerName SOMEREMOTESERVER -scriptblock {
	Get-WmiObject -Class  ... and the same code here ...
}

Check WMI on SCCM-server

If you have problems with WMI on a SCCM server you have will have loads of strange things happening.

Wrote a small VBScript to check WMI… here it is:

Set oLocator = CreateObject("WbemScripting.SWbemLocator")

' --- Checking local WMI
WScript.Echo " Connect: root\CIMV2"
Set oWMIService = oLocator.ConnectServer(".", "root\CIMV2", "", "")

WScript.Echo "   Query: Select UUID from Win32_ComputerSystemProduct"
Set oWmiQuery = oWMIService.ExecQuery("Select UUID from Win32_ComputerSystemProduct")
For Each oUuid In oWmiQuery
	sUuid = oUuid.UUID
	WScript.Echo "Response: " & sUuid
	Exit For
Next
WScript.Echo ""


' --- Figure out site code
WScript.Echo " Connect: root\sms"
Set oWMIService = oLocator.ConnectServer(".", "root\sms", "", "")

WScript.Echo "   Query: SELECT SiteCode FROM SMS_ProviderLocation WHERE ProviderForLocalSite=true"
Set oWmiQuery = oWMIService.ExecQuery("SELECT SiteCode FROM SMS_ProviderLocation WHERE ProviderForLocalSite=true")
For each currentSite in oWmiQuery
	sSccmSiteCode = currentSite.SiteCode
	WScript.Echo "Response: " & sSccmSiteCode
	Exit For
Next
WScript.Echo ""


' --- Connect to site
WScript.Echo " Connect: root\sms\site_" & sSccmSiteCode
Set oWMIService = oLocator.ConnectServer(".", "root\sms\site_" & sSccmSiteCode, "", "")

WScript.Echo "   Query: Select Name, ResourceID FROM SMS_R_System WHERE SmbiosGuid = '" & sUuid & "'"
Set oWmiQuery = oWMIService.ExecQuery("Select ResourceID FROM SMS_R_System WHERE SmbiosGuid = '" & sUuid & "'")
For each myMachine in oWmiQuery
	WScript.Echo "Response: " & myMachine.ResourceID
	Exit For
Next

Or download here: wmiTester.vbs

SCOM WMI Ping instead of script

In a post yesterday there was a script to ping some node, the script uses WMI to ping.
Did some testing, and… Why did I write a script when you can use the built in WMI-support to do the same thing?

Why (not) a script?
OK, there is one thing that (afaik) you can’t do with WMI-queries… JOIN.
I would like to do some sort of query that puts out CSName from Win32_OperatingSystem along with StatusCode and ResponseTime from Win32_PingStatus, but… I can’t figure out how.

Ok?
Since you have the performance mapper to point out Object, Counter and so on you can’t make a simple WMI-query that allows you to get the name of the agent. And if you can’t get that to work you will get a mix of multiple agents performance-data on one counter…
The script returns serverToPingFrom, thats what I’m missing.

The solution
When I first looked at it… I only looked at the WMI-query and didn’t think about what SCOM and the performance mapper can do.
The solution is to name the Counter with use of some data that SCOM already know.

Yada yada yada… on to the script!
Go to OM-Console -> Authoring -> Management Pack Objects -> Rules -> New… -> Collection Rules \ Performance based \ WMI performance
A few next-clicks and then paste the following:

WMI Namespace
root\cimv2

Query

select * from Win32_PingStatus where address = '192.168.0.10' and BufferSize=4096 And Timeout=1000

Perfomance mapper
Object = WMIPingRoundtrip
Counter = $Target/Property[Type=”System!System.Entity”]/DisplayName$
Instance = $Data/Property[@Name=’Address’]$
Value = $Data/Property[@Name=’ResponseTime’]$

Ominstallation av WMI

En kolega hade problem med ett gäng servrar som sprutade ut WMI-felmeddelanden… han hittade ett inlägg som Ivan Brugiolo skrev i newsgroup’en microsoft.public.win32.programmer.wmi:

—————8<--------------- From a very old post of mine in this same forum, how to check why WinMmgt became un-usable and how to repair it. Try to remove, if they are there

HKLM\Software\Microsoft\OLE 
“EnableRemoteConnect”=”Y” 
“LegacyAuthenticationLevel”=dword:00000001 
“LegacyImpersonationLevel”=dword:00000001 

Some legacy application from the Win9x era are known to create those key that impair many DCOM functionality on the machine.

check the following registry key HKLM\System\Software\Microsoft\WBEM\CIMOM\AutoRecover MOFs it is supposed to have a list of *.MOF and *.MFL files, and it MUST begin with cimwin32.mof
There are ISP connection kits and .NET Framework setups known to corrupt this key.
Please delete it content if it appears to have few files or if it appears corrupt.

check if in %windir%\system32\wbem there are about 40 MOF files.
There are certain applications known to delete them.
If you don’t have them, please recover them from the CD of WinXP.
The complete list is found in %windir%\IFM\wbemoc.inf

Please check the following:
-1- that you system path has still %windir%\system32\wbem in it.
-2- that there are no wmiutils.dll and wbemcomn.dll in the system path that comes before the one in system32\wbem.

c:\>for %i in ("wbemcomn.dll") do (echo %~$PATH:i) 
c:\>for %i in ("wmiutils.dll") do (echo %~$PATH:i) 

check if the wbemutils.dll registered as a COM component comes from the OS or from Visual Studio and/or other development tools. Make sure the OS Supplied one is used.

enable versbose logging

HKLM\Software\Microsoft\WBEM\CIMOM:Logging(REG_SZ) = "2"
HKLM\Software\Microsoft\WBEM\CIMOM:Logging File Max Size (REG_SZ) = "4000000"

find the PID of the svchost.exe process running WinMgmt

HKLM\Software\Microsoft\WBEM\CIMOM:ProcessID (REG_DWORD) = XXX

crosss check the pid

c:\>tlist -s | findstr /i winmgmt

it must be the same as above, if not, trust tlist.exe more than the registry for the steps below.

you can get “tlist .exe” and “kill.exe” (needed later) from http://www.microsoft.com/ddk/debugging/installx86.asp

c:\>sc config winmgmt start= disabled 
c:\>kill -f XXX    --- pid obtained before
c:\>cd /D %windir%\system32\wbem 
c:\WIN\system32\wbem>rmdir /s /q repository 
c:\WIN\system32\wbem>rmdir /s /q Logs 
c:\WIN\system32\wbem>mkdir Logs 
c:\WIN\system32\wbem>for /R %i in (*.dll) do (regsvr32 /s %i) 
c:\WIN\system32\wbem>regsvr32 /s fastprox.dll 
c:\WIN\system32\wbem>for /R %i in (*.exe) do (%i -regserver)    --- this will open wbemtest and/or wmic.exe. Just close it 
c:\WIN\system32\wbem>sc config winmgmt start= auto 
c:\WIN\system32\wbem>regsvr32 wbemupgd.dll    --- this can take 30 seconds to 2 minutes 
c:\WIN\system32\wbem>net start server && net start workstation && net start AudioSrv && net start termservice 

after this, please start %windir%\system32\wbem\wbemtest.exe, and connect to the root\cimv2 namespace.

If something goes wrong, please read the logs under %windir%\system32\wbem\Logs, just to see if there is something obviousely wrong there.

After all of this is done, there might be misconfiguration problems that have changed access permission to registry key and files for the NetworkService account.
The NetworkService account is the one running one of the Provider Host.
To test if this can be the problem, you ca add NetworkService to the administrators group

c:\>net localgroup administrators NetworkService /ADD

Please remember to remove it as soon as the misconfiguration problem have been identified
—————8<---------------

Written by Comments Off on Ominstallation av WMI Posted in MOM2005 Tagged with