Check WMI Connectivity
in [VbScript]
|
From: Toan Do on 7 Oct 2005 03:21 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
From: //o// on 7 Oct 2005 05:21 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" wrote: > 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 >
From: Toan Do on 7 Oct 2005 06:49 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(a)discussions.microsoft.com> wrote in message news:570389A8-9CBF-4384-B804-7EAFF4ED3FE5(a)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 ) > > (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
From: Al Dunbar [MS-MVP] on 8 Oct 2005 15:46 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" <toandn(a)cybersoft-vn.com> wrote in message news:ud6URzyyFHA.2960(a)tk2msftngp13.phx.gbl... > > 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(a)discussions.microsoft.com> wrote in message > news:570389A8-9CBF-4384-B804-7EAFF4ED3FE5(a)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 ) > > > > (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 > >
From: //o// on 8 Oct 2005 16:56 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\/\/
|
Next
|
Last
Pages: 1 2 Prev: PasteSpecial: values and formats possible in vbs? Next: HTA Exit Codes |