Check WMI Connectivity

[Toan Do]

Hi all,

I want to check WMI Connection to all PCs in my domain. Script code is as following:

 

For Each strComputer in arrComputers

    Set objWMIService = GetObject("winmgmts:\\" & strComputer &"\root\cimv2") '(*)

    If Err.Number > 0 Then
        WScript.Echo strComputer & " - Unable to connect to WMI. Error " & Err.Number & "-" & Err.Description
        Err.Clear
    Else
        WScript.Echo strComputer & "Connect to WMI: OK!"
    End If

Next

 

WMI, DCOM, COM+ services are running well in all PCs. Domain Group Policy forces Windows Firewall in all PCs to open port 135 & 445.

There're times that WMI Connection to some PCs cannot be successful because Domain Group Policy are not applied at the PCs. So when the script runs, it stops at line (*) about 1 hour (If you choose Properties at WMI Control in Computer Management, you will have to wait a long time).

This issue occurs in all Wins XP SP2 & Wins 2K SP4.

This issue can be solved by running command "gpupdate /force" OR "secedit /refreshpolicy ..."

 

I want to decrease time to wait PCs' WMI unconnectable. I want to know whether a PC is connectable or not immediately. There is any way?

 

Thanks

 

[/\/\o\/\/]

try this

its setting
WBEM_FLAG_CONNECT_USE_MAX_WAIT

No timeout :

Set objWMIService =
objSWbemLocator.ConnectServer(strComputer,"root\CIMV2","","","","",&H0 )

2 minute timeout

Set objWMIService =
objSWbemLocator.ConnectServer(strComputer,"root\CIMV2","","","","",&H80 )

(only 2 options)

you can not do this with a moniker, I think

I did find a way to do a more ganular control in MSH but it uses .NET

MSH > $scope = new-object system.management.managementscope
MSH > $p = new-object system.management.managementpath
MSH > $p.server = "fake"
MSH > $p.NamespacePath = "root\cimv2"
MSH > $scope.set_path($p)
MSH > $t = new-object System.TimeSpan(0, 0, 5)
MSH > $t.duration()
MSH > $ogo.timeout = $t
MSH > $ogo

MSH C:\MowMSH> $scope.connect()

UseAmendedQualifiers Context Timeout
-------------------- ------- -------
True {} 00:00:05

MSH H:\> $scope.set_Options($ogo)
scope.connect()

greetings /\/\o\/\/

PS could not realy test tis I don't have the problem when using a fake adress

[Toan Do]

Thank U very much.
I use iSecurityFlags = "&H80" and it saves my script from hanging!
I used to read SWbemLocator.ConnectServer but I did not pay caution at
iSecurityFlags.
Thank again!

=================================================================
"/\/\o\/\/" <o...@discussions.microsoft.com> wrote in message
news:570389A8-9CBF-4384...@microsoft.com...

> try this
>
> its setting
> WBEM_FLAG_CONNECT_USE_MAX_WAIT
>
> No timeout :
>
> Set objWMIService =
> objSWbemLocator.ConnectServer(strComputer,"root\CIMV2","","","","",&H0 )
>
> 2 minute timeout
>
> Set objWMIService =

> objSWbemLocator.ConnectServer(strComputer,"root\CIMV2","","","","", &H80 )

[Al Dunbar [MS-MVP]]

Depending on your purpose, and the typical cause of non-connectivity,
another method that can save time is to avoid attempting connection to any
computer that is not currently listed in the master browser.

We use this with WMI and other scripts we use to collect info from our
workstations and/or to make scripted configuration changes. Basically you
trap the output of a "net view" command, and then have your script skip any
computers that do not appear in that list.

The main reason our systems are not in the browse list or not otherwise
accessible is because the users have turned them off. If we absolutely need
to update or query all, we just keep a list of which have been touched, and
periodically re-run the script that tries to touch them all.

The master browser does not update itself instantaneously, so that creates
some latency with the following ramifications:

1) a system could have just been powered ON and ready for our script to run,
but not be touched because it is not yet listed in the browser.

2) a system could have just been powered OFF. Our script then wastes timeout
time waiting for a system that will nto respond.

Since our main purpose is to keep the runtime of our scripts reasonable,
this is a good tradeoff. The best time to run our scripts is therefore
between 8:30 and 11:00, as most machines that will be on in the day will be
on then. Quitting time is the worst time for the opposite reason.

If your connectivity issues are more GPO based, you might find that systems
are browsable, but not accessible to your purposes. In that case you may
have little to gain from this method.

/Al

"Toan Do" <toa...@cybersoft-vn.com> wrote in message
news:ud6URzyy...@tk2msftngp13.phx.gbl...

[/\/\o\/\/]

Al Dunbar [MS-MVP] wrote:

>
> If your connectivity issues are more GPO based, you might find that systems
> are browsable, but not accessible to your purposes. In that case you may
> have little to gain from this method.
>

computers, that ARE off don't usualy give problems,
computers that ARE on but have problems, in this case the firewall,
but also it happens (to mutch)that WMI is corrupt,

correct this like this :

Stop the WMI service.
Delete the WMI repository directory.
Restart the WMI service. The WMI repository is reinstalled shortly after

see also
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/reinstalling_wmi.asp

to quicken things further you can start more checks in parralel.

gr /\/\o\/\/

[/\/\o\/\/]

>
> Al Dunbar [MS-MVP] wrote:
>
>>
>> If your connectivity issues are more GPO based, you might find that
>> systems
>> are browsable, but not accessible to your purposes. In that case you may
>> have little to gain from this method.
>
>

> to quicken things further you can start more checks in parralel.
>
> gr /\/\o\/\/

to process more than 1 at the same time, so that a few "bad Apples" do
not keep you up to mutch.

you can use following script(s).

1 calling and 1 script(go.cmd) to put your code in.

you can set MaxProcess and Delay to finetune the process

gr /\/\o\/\/

________________________________

Main Script
________________________________
@Echo off
echo 0 > count.txt

set maxProcess=5
set Delay=5

:start
for /f %%i in (count.txt) do set count=%%i
if %count% LSS %maxProcess% call :go
echo %count% processes Running
ping -n %Delay% 127.0.0.1 > nul
goto :start
:EOF

:go
start /b go.cmd
echo New Process started
set /a count=%count%+1
echo %count% > count.txt
:EOF

______________________________
Go.cmd
______________________________

@echo off
::::::::::::
:: Code Here
::::::::::::

cscript //nologo sleep.vbs

::::::::::::::::::
:: Sync management
::::::::::::::::::

for /f %%i in (count.txt) do set count=%%i
set /a count=%count%-1
echo %count% > count.txt

echo Process Ended
exit

[Al Dunbar [MS-MVP]]

"/\/\o\/\/" <a...@mow.com> wrote in message
news:uE6jQrEz...@TK2MSFTNGP10.phx.gbl...

>
> Al Dunbar [MS-MVP] wrote:
>
> >
> > If your connectivity issues are more GPO based, you might find that
systems
> > are browsable, but not accessible to your purposes. In that case you may
> > have little to gain from this method.
> >
> computers, that ARE off don't usualy give problems,
> computers that ARE on but have problems, in this case the firewall,
> but also it happens (to mutch)that WMI is corrupt,

I guess we are just lucky then, as we our workstations are all on the same
side of the firewall, and we do not seem to have WMI corruption problems.
Still, we do save some wasted time by this method - just not as much as the
OP wastes because of the problems he has and we don't.

> correct this like this :
>
> Stop the WMI service.
> Delete the WMI repository directory.
> Restart the WMI service. The WMI repository is reinstalled shortly after
>
> see also
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/reinstalling_wmi.asp
>
> to quicken things further you can start more checks in parralel.

That sounds like a very useful approach if one expects to have some
computers taking minutes to fail out from a WMI call...

/Al