Re: Multiple WMI Connections


Gerry Hickman wrote:
Hi,

I've run a similar system too, but I wrote my own ping provider because
we use Win2k. You are talking "synchronous" here as opposed to "async",
that's fine, mine is synchronous too.

I wrote a WMI script to connect to iterate through a list of 2,000
workstations and:

1. ping each one using win32_pingstatus
2. if online connect with WMI with an array of passwords
3. get the version of a specific file and write it to a CSV file

OK, this is pretty easy. I do this all the time to test for patch
compliance.

What I discovered was that even with the initial PING the list took too
long to process.

Define too long? I don't understand the problem here. Did you test it
carefully to find out which part was taking "too long".

There was no particular bottleneck at a point in the script, it was
simply that it took 4 hrs to get through all 2000 computers.


As a possible solution I took the list of 2000 and broke it down into 4
lists of 500.

Yes, I do that sometimes, but not if I just want a file version.

In the case I split it up so instead of requesting the file version of
1 computer at a time it requested the version from 4 at a time. Of
course this decision was made quickly under stress and now I am looking
to see what other options there may be...


The report generated showed the incorrect results and I am concerned I
am missing something.

Define "incorrect"

The report showed some duplicates or missing entries. Analysis is
ongoing but my first thought was the variables or objects in the 4
scripts were stepping on one another. I don't beleive that is possible
but I wanted to ask anyway.


What needs to be changed in a script if multiple instances are running?

But you said you "iterate" them, so there are not multiple instances??
Iterate means you are connecting to each one and then disconnecting,
then releasing handles to objects, then moving to the next one?

In the beginning there was one script and 2000 workstaitons, that
script would iterate through 2000 workstations. Then, there were 4
scripts (exactly the same) processing 4 lists of 500 workstations.


Would the variables each script creates need to be uniquely named?

Don't understand, surely there's only one script here?? The whole point
of WMI is that the calling script is remoting to each machine - that the
beauty of it.

There was one script and 2000 workstations. In a pinch, I converted
that to 4 copies of the same script and 4 lists of 500 each.


If you're using async it's a whole different ball game. None of the
above applies.

--
Gerry Hickman (London UK)

What is comes down to is that now that I have some time, how can I best
process large numbers of calls across the network to thousands of PCs.
The solution may lie in one script that makes use of Asynchronous Mode
and the SWbemSink.OnObjectReady event to handle multiple calls...

.

Relevant Pages

  • Re: Disable/Delete unused workstations
    ... This script will remove inactive machine accounts in Active Directory ... > is there a way to automatically disable or delete workstations not used in ...
    (microsoft.public.win2000.group_policy)
  • Re: Deploying Red Hat Workstations
    ... > can easily make changes to the workstations all at once. ... Have the central server push out to each host. ... > This script will contain any changes that I need to make. ... I would automate SCP from the server to a user account (not ...
    (Fedora)
  • Re: Change local administrator password for all PCs in the domain
    ... > I have about 200 workstations in my Windows 2000 domain. ... you could setup a custom script or Group Policy (in ... no workgroup machines. ...
    (microsoft.public.windows.server.scripting)
  • Starter Script
    ... This is the script I use to manage admin passwords on our ... workstations. ... 'Set oNetwork = CreateObject ...
    (microsoft.public.win2000.security)
  • Re: Add domain user to local group script troubleshoot
    ... What I would like to with this is get a list of all the workstations, ... I'd like to take it one step further and have the script ... > The local group object's Add method does not understand an LDAP AdsPath. ...
    (microsoft.public.windows.server.scripting)
Loading