Conectare
 
Pagina de pornireBibliotecăInformațiiFişiere de descărcatSuportComunitateForumuri
Resurse pentru profesionişti IT >
> 
> 
VBScript in an HTA - swbemlocator keeps connecting to remote host

Răspuns VBScript in an HTA - swbemlocator keeps connecting to remote host

  • 10 mai 2012 16:49
     
      Are cod
    Sign in pentru a vota
    0

    Hello,

    I created an HTA as a front-end for a VBScript program that is gathering information from remote computers on our network. All the computers are running Windows XP Service Pack 3. It is basically "Sydi-server" with some custom modifications. The HTA allows the user to input a range of IP addresses or a list of hostnames, choose the information they want to collect, specify the output directory, etc. The HTA can run with a "regular" user account, but the user has to input the username and password of an administrative user to get permission for remote acquisition.

    The connection to the WMI service is created the usual way:

    Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
Set objWMIService = objSWbemLocator.ConnectServer(strComputer,"root\cimv2",strUserName,strPassword)

    I assumed that the connection would be broken with:

    Set objSWbemLocator = Nothing
Set objWMIService = Nothing

    Well, I got a call from one of our remote locations wondering why I have been logging in and out of his computer every 90 seconds. I verified with netstat that TCP connections created by the script are staying established with the remote computers even though the objects are destroyed. And every 90 seconds or so, another connection is made, which correlates with a login event in the Security log of the remote computer. 30 seconds later there is a logout event.

    These connections continue to be made for as long as the HTA is active. They timeout when I close the application.

    Is there a way to disconnect from a remote WMI Server? I've found many examples of scripts that connect to the server, but nothing that really says how to disconnect. Or is my only solution to close the application after each run? I'm often scanning a hundred computers one after the other, which can take several hours. I'd really rather not be logging in and out of remote computers every 90 seconds for that whole timespan.

    Thanks for the help.

     

Toate mesajele

  • 10 mai 2012 18:14
     
      Are cod
    Sign in pentru a vota
    0

    Simple - do not destroy the SWebemLoao object each time.  Just connect it to a different server.

    Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
for each strComputers in collecionOfComputers
Set objWMIService = objSWbemLocator.ConnectServer(strComputer,"root\cimv2",strUserName,strPassword)
 ... more code
Next
Exit script.

    Th elocator object does not get removed from memory even when you set its refernce to Nothing.  If you resuse it a new connection will be seen as an implicit disconnect from the previous system.

    Of course you can aslo have other code issues which we cannot address with no code posted.

    ¯\_(ツ)_/¯

     
  • 11 mai 2012 13:30
     
      Are cod
    Sign in pentru a vota
    0

    I have restructured my code as you suggested. Here is a condensed version:

    Dim objLocator
Set objLocator =CreateObject("WbemScripting.SWbemLocator")

Sub Main
   Dim objServer
   <populate objDbrComputers with user input, get username and password, option list, etc.>
   Do While Not objDbrComputers.EOF
      strComputer = objDbrComputers("IPAddress")
      objServer = objLocator.ConnectServer(strComputer,"root\cimv2",strUserName,strPassword)
      GatherWMIInformation(objServer)
      Set objServer = objLocator.ConnectServer(strComputer,"root\default",strUserName,strPassword)
      Set objServer = objServer.Get("StdRegProv")
      GatherRegInformation(objServer)
      objDbrComputers.MoveNext
   Loop
   Set objServer = objLocator.ConnectServer(".","root\default")								
End Sub

Sub GatherWMIInformation(objWMI)
   <various WMI queries populating recordsets>
End Sub

Sub GatherRegInformation(objReg)
   <various Registry queries populating recordsets>
End Sub

    Obviously I have left out a lot of code - but these are the sections that deal with the connections.

    Sub Main is called when the user clicks a button on the HTML app. I added the connection to the local machine at the end in the hope that it would break any remote connections.

    Running this program against a batch of 5 remote computers results in 5 "ESTABLISHED" TCP sessions that persist for as long as the HTA is running. My computer then sends a login request to the remote computer every 90 seconds, with a logout request 30 seconds later. These login/logout sequences are captured in the Security log. The connections are broken when the HTA is closed.

     
  • 11 mai 2012 14:00
     
      Are cod
    Sign in pentru a vota
    0

    That will not work. You are still not reusign the connection and your super fix is probably the source of some of the problem.

    Dim objLocator
Set objLocator =CreateObject("WbemScripting.SWbemLocator")
Dim objServer
Sub Main
   Do While Not objDbrComputers.EOF
      strComputer = objDbrComputers("IPAddress")
      Set objServer = objLocator.ConnectServer(strComputer,"root\default",strUserName,strPassword)
      Set reg = objServer.Get("StdRegProv")
      GatherRegInformation(reg)
      objDbrComputers.MoveNext
   Loop
				
End Sub

    Note that I fixed  two mistakes in your code.

    YOu were overwriting the objServer wilt teh reference to StdRegProv and you were conenctiing twice to the locator.

    By making the objServer global we can avoind it becomeing orphaned.

    You need to run and test thisas a VBS before putting it in an HTA.  HTAs are event oriented and can hide many cocing errors.  Get the code working correctly before placing it in an HTA.

    ¯\_(ツ)_/¯

     
  • 11 mai 2012 19:25
     
      Are cod
    Sign in pentru a vota
    0

    There are two connections to the locator because I need two different namespaces.

    The first one:

    Set objServer = objLocator.ConnectServer(strComputer,"root\cimv2",strUserName,strPassword)

    Is for the WMI provider, and the second one:

    Set objServer = objLocator.ConnectServer(strComputer,"root\default",strUserName,strPassword)
Set objServer = objServer.Get("StdRegProv")

    Is for the Registry provider. If you know of a way to change the namespace of an existing connection, please let me know and I'll try that. I searched for a way but was unsuccessful.

    Making objServer global results in 2 TCP connections to each host persisting when the script is finished, instead of 1. 

    Overwriting objServer with the reference to StdRegProv did not hurt anything. In fact, using another variable there also caused 2 TCP connections to persist for each host. I could eliminate the second persistent connection by doing:

    reg = ""

    at the end of each loop. I tried doing:

    objServer = ""

    at the end of each loop as well, but it didn't do anything.

    I tried just the WMI part, and then just the Registry part. Both end up with the same result - a persistent TCP connection to the remote host.

    Testing this as a VBS (ie: with cscript) is not very helpful. Proving that the connections disappear when the script finishes is fine, but that's not the problem. They disappear when the HTA is closed as well. I want them to disappear when they are finished collecting information. I put an infinite loop in at the end of the script to verify that the TCP connections persist while the script is in memory - and they do. Also, the point of this exercise is for me to write something that allows "regular users" to avoid the command line.

     
  • 11 mai 2012 19:56
    Moderator
     
     Răspuns
    Sign in pentru a vota
    0

    Hi,

    I don't see a way to disconnect said connections using the script APIs (SWbemLocator, et. al.).

    Bill

     
  • 11 mai 2012 20:21
     
     
    Sign in pentru a vota
    0

    I fon't think you understand locator.  It is namespace indeiiferet. It just connects to WMI on the specified server.  If you need to switch namespaces that is OK.  Namespace specifiies the conenction.  You can reconnect as along as you use a persistent object.

    Before you try using an HTA be sure torun all of this in a VBS until it is working correctly.  I think you will eventually find other errors that are causing some of this issue.

     Ther is no disconnect. The connection will eventually disappear after you have connected teh object to a different location.  The connections will disappear after they timeout.

    Before you were just creating a new locator and server object each tiume.  These willliely not get removed even if you set = othing.  The GC is very lazy in VBScript.

    ¯\_(ツ)_/¯

     
  • 15 mai 2012 19:52
     
      Are cod
    Sign in pentru a vota
    0

    I've had a chance to work with this again today, and figured a couple of things out.

    "jrv" is correct, the connections will time out after about three minutes with no activity. I set up this test code:

    Dim arrComp, currentComp
arrComp = Array("10.6.8.135","10.6.8.201","10.6.8.73")
Dim objLocator, objServer
Set objLocator = CreateObject("WbemScripting.SWbemLocator")

For Each currentComp in arrComp
   Set objServer = objLocator.ConnectServer(currentComp,"root\cimv2",strUserName,strPassword)
   Set objServer = objLocator.ConnectServer(strComputer,"root\default",strUserName,strPassword)
   Set objServer = objServer.Get("StdRegProv")			
Next

Set objServer = objLocator.ConnectServer(".","root\cimv2",strUserName,strPassword)

Do While True
Loop

    The connections are made, and then about three minutes later, they are gone. This worked both as a VBS and an HTA. The connection is made to the local server at the end,  otherwise the last remote server that was connected to stays active.

    I added the GatherWMIInformation() call to the loop and the connections persisted. I then noticed that some of the calls to ExecQuery were missing the flags for "wbemFlagForwardOnly." The default appears to be "wbemFlagBidirectional," and the description says that it "Causes WMI to retain pointers to objects of the enumeration until the client releases the enumerator." That sounded like something I didn't want to do. So, for example, when the "48" was missing from:

    Set colItems = objServer.ExecQuery("Select Name, Description, Path, Type from Win32_Share",,48)

    the connection remained open. There were three calls to ExecQuery in the original code that were missing the flags, and fixing those got rid of the persistent WMI connections.

    I then added the GatherRegInformation() call and didn't have any persistent connections when running as a VBS. As an HTA, however, connections remained persistent. I have narrowed it down to statements like this:

    objServer.GetDwordValue HKEY_LOCAL_MACHINE,"SYSTEM\CurrentControlSet\Control\Terminal Server","TSAppCompat", nTerminalServerMode

    I ran the GatherRegInformation() function with ONLY that statement, and the connections remained open - one for each remote machine (actually two for the last machine). So it seems that, in an HTA, getting something from the registry causes a TCP connection to stay active, even when you connect the server object to something else afterward.

    I may have to try restructuring this program so the HTA calls the script externally - but that's a fairly major undertaking. Any thoughts?


     
  • 15 mai 2012 19:54
    Moderator
     
     
    Sign in pentru a vota
    0

    Hi,

    Why is it so important to disconnect?

    Bill

     
  • 15 mai 2012 20:46
     
     
    Sign in pentru a vota
    0

    Hi,

    I don't see a way to disconnect said connections using the script APIs (SWbemLocator, et. al.).

    Bill

    Bill - that has nothing to do with what is happening.  If you reconenct a locator it will drop the previous conenction.  If you jsut create a new conenction from scatch using a new instance of teh variable the old connection will persist until the garbage collector removes the variable.  If you are in a tight loop this will never happen.  There are also other errors in the script that can aggravate this.

    Rememebr that this is an HTA.  Events are being received by the browser architecture.  Many things can be happening that will cause teh script to retain open conenctions. Explicity reuing the object and declaring it as a global object will minimize the excess connections.  I also suspect that the code that has been posted is NPOT the actual running code.  It can't be.  The actual code has more erros I am sure.  Addressing the fixes I posted will help to shake these things out. 

    ¯\_(ツ)_/¯

     
  • 15 mai 2012 20:53
     
     
    Sign in pentru a vota
    0

    Hi,

    Why is it so important to disconnect?

    Bill

    The question appears to indicate that ALL connections are ging to the wwrong servers.  REstructuring will help to shake this out. 

    You are correct.  Old connections are not a problem as they will age out on there own unless threre is an issue with WMI.

    ¯\_(ツ)_/¯

     
  • 15 mai 2012 20:56
    Moderator
     
     
    Sign in pentru a vota
    0
    Bill - that has nothing to do with what is happening.

    Of course; I was just pointing out that there's not a script method that explicitly disconnects a WMI connection.

    Bill

     
  • 15 mai 2012 21:35
     
     
    Sign in pentru a vota
    0
    Bill - that has nothing to do with what is happening.

    Of course; I was just pointing out that there's not a script method that explicitly disconnects a WMI connection.

    Bill

    Yes - I relized that and you are correct however, that is not a solution to the question. It is a statement about what is not possible.  I replied because the disconnect will be as a result of destroying the object (Not set to Nothing but garbage collected) or by reconnecting it which should force the current connection to be dropped.

    Unfortunately the WMI connection has no real open/close semantics.  It only has 'connectserver' and destroy connection.  By forcing reuse I am hoping that the user will see where there might be a coding error.  Of course the error can be subtle and this will not find it.

    I had a similar question some time ago.  The computer loop was

    for each strComputer in aComputers
         strComputer = "."
    ....

    The OP only posted the WMI bits and we went in circles for a bit.

    This post is one where the posted code cannot be the code that is running. It has been modified or is an older or demo version.

    A test shows that a connection persists on the remote for 60 to 90 seconds after the script terminates.  This is with TCPView and not from the WMI logs which would be a better guage.

    ¯\_(ツ)_/¯


     
  • 15 mai 2012 21:47
    Moderator
     
     
    Sign in pentru a vota
    0
    Yes - I relized that and you are correct however, that is not a solution to the question.

    It is a solution if the question is how to programmatically disconnect using a WMI method. This is why I asked why it matters.

    Bill

     
  • 16 mai 2012 13:19
     
      Are cod
    Sign in pentru a vota
    0

    The code that I posted 7 posts above this one is my basic test script. The only thing missing was "Dim strUserName, strPassword." Those variables are empty at execution time, but it works because I run it using a command prompt with administrator privileges. I didn't post the contents of GatherWMIInformation() or GatherRegInformation() because together they are about 3500 lines long.

    GatherWMIInformation is a series of conditional statements that get information from the WMI provider of a remote computer. Here is a sample:

    '*** bWMIHardware ***
If (bWMIHardware) Then
  ' sound card
  If bVerbose Then
    WriteLog FormattedDate, " Gathering Sound Device information"
  End If
  Set colItems = objServer.ExecQuery("Select Name, Manufacturer from Win32_SoundDevice",,48)
  Set objDbrSoundDevice = CreateObject("ADOR.Recordset")
  objDbrSoundDevice.Fields.Append "Name", adVarChar, MaxCharacters
  objDbrSoundDevice.Fields.Append "Manufacturer", adVarChar, MaxCharacters
  objDbrSoundDevice.Open
  For Each objItem in colItems
    objDbrSoundDevice.AddNew  
    objDbrSoundDevice("Name") = objItem.Name
    objDbrSoundDevice("Manufacturer") = objItem.Manufacturer
    objDbrSoundDevice.Update
  Next
  ' video card
  If bVerbose Then
    WriteLog FormattedDate, " Gathering Video Controller information"
  End If
  Set colItems = objServer.ExecQuery("Select AdapterCompatibility, AdapterRAM, Name from Win32_VideoController",,48)
  Set objDbrVideoController = CreateObject("ADOR.Recordset")
  objDbrVideoController.Fields.Append "AdapterCompatibility", adVarChar, MaxCharacters
  objDbrVideoController.Fields.Append "AdapterRAM", adVarChar, MaxCharacters
  objDbrVideoController.Fields.Append "Name", adVarChar, MaxCharacters
  objDbrVideoController.Open
  For Each objItem in colItems
    objDbrVideoController.AddNew
    objDbrVideoController("AdapterCompatibility") = objItem.AdapterCompatibility
    If objItem.AdapterRAM <> "" Then	' some situations result in this field being empty for some reason
      objDbrVideoController("AdapterRAM") = objItem.AdapterRAM
    Else
      objDbrVideoController("AdapterRAM") = 0
    End If
    objDbrVideoController("Name") = objItem.Name
    objDbrVideoController.Update
  Next
End If ' bWMIHardware

    There are a dozen similar conditional blocks populating recordsets with different information. The user chooses which scripts to run with check boxes on the HTA. During my testing I just set the conditions to TRUE one at a time until I found the "iFlags" error.

    After the collection takes place, another subroutine is called that creates an XML file containing the information from the recordsets. I removed this subroutine from the tests as it shouldn't be relevant.

    Note that the WMI scripts are not causing persistent connections any more, since I fixed the "iFlags" that were missing on some ExecQuery calls. When I only run WMI options, the connections time out after about 3 minutes whether I'm running with "cscript" on a command line like my test script above (with the infinite loop keeping the script in memory) or when I run the HTA program.

    GatherRegInformation() is similar, except it gets information from the registry. I pared down that subroutine to this:

    Function GatherRegInformation
  objServer.GetDwordValue HKEY_LOCAL_MACHINE,"SYSTEM\CurrentControlSet\Control\Terminal Server","TSAppCompat", nTerminalServerMode
End Function

    "nTerminalServerMode" is a global variable.

    Adding this subroutine to the script, and running it as a VBS with cscript, the connections time out after about three minutes - just like they should. Calling this function while running the HTA however, causes a persistent connection to be made to each remote computer. I tried pointing objServer to the WMI provider and calling GatherWMIInformation() after GatherRegInformation() in the hope that redirecting objServer would get rid of the connection, but it didn't.

    AbqBill wrote: "Why is it so important to disconnect?"

    It's important because persistent connections are resulting in "Logon/Logoff" events being recorded in the remote computer's Security Event log. Every 90 seconds there is a Logon, followed 30 seconds later by a Logoff. This isn't a big deal when I only gather a few computers at a time, because I can just quit the HTA and break the connection. Occasionally I am tasked to gather a subnet with 200 computers. That can take several hours, and the computers at the beginning of the range end up with Security logs full of logon/logoff events tied to my username.

    Thanks for the help so far, both of you, I'm learning quite a bit.

    Andrew

     
  • 16 mai 2012 13:53
     
     
    Sign in pentru a vota
    0

    In that much code there is a very good chance that you have a design and/or logic error.

    If you do not globalize and reuse the conenction then you will not get the desired results.

    The conenctions are being made becuse soemwher youare specifying the computer by name.  If you are using the connection repeatedly then you MUST have some glpobal mechanism to be sure you are using the same connection.

    Again I am going to recommend that yo run this in a VBS and not in an HTA.  A Placing it in an HTA adds too many issues to the variables.  Start by running just part of the scritp in a VBS and be suer it does not produces repeated connection to only one machine.  Be sure the machine in question is NOYT the one you are testing with.  The error can be because of an issue with DNS.

    Since no one is giong to review 3500 lines of code you are pretty much on your own.  YOu could hire a consultant to work with yo on this but no one will do this for you for free.

    Trying to use VBScript for a project this big is a great challenge.  You will either become a very good script writer or be hopspitalizwed with for mental exhaustion.

    All of the information you are gathering is already being collected by SystemInfo which can be run with oprtions to tailor your information.  You sould look into using it.  Sydi-Server is basically an attempt at replacing SysInfo with a script.  It works as is but is not designed to be changed easily as it has a lot of very location dependent code written into it.  THe write used it to learn to write script.  I remember working on questions about how to do many things in Sydi Server. I still have one of teh original copies of V1 that I proposed some fixes to.

    Good luck and consider whether you are trying to reinvent the wheel.

    ¯\_(ツ)_/¯

     
  • 16 mai 2012 16:07
     
      Are cod
    Sign in pentru a vota
    0

    I am a student and figuring this out is my project, so we won't be hiring anyone else. Our version of Sydi has been modified and expanded to gather more information that is relevant from a security perspective. For example, rather than just listing the software that is installed, I'm listing the user profile that was active when the software was installed and the path it was installed from. I've also written a script that creates an MDB database from the XML report files, and then allows the user to search for various things.

    I have brought this down to a simple test script. When I run this from a command prompt with administrator privileges:

    Set objLocator = CreateObject("WbemScripting.SWbemLocator")	
Const HKEY_LOCAL_MACHINE = &H80000002			
Set objServer = objLocator.ConnectServer("10.6.8.73","root\default")
Set objServer = objServer.Get("StdRegProv")
Set objServer = objLocator.ConnectServer(".","root\default")
Do While True
Loop

    the connection to 10.6.8.73 (which is not my machine) appears and then is gone after about 3 minutes - just as expected. The connection to the local server at the end is required in order to break the connection to 10.6.8.73.

    When I run this instead:

    Set objLocator = CreateObject("WbemScripting.SWbemLocator")	
Const HKEY_LOCAL_MACHINE = &H80000002			
Set objServer = objLocator.ConnectServer("10.6.8.73","root\default")
Set objServer = objServer.Get("StdRegProv")
objServer.GetDwordValue HKEY_LOCAL_MACHINE,"SYSTEM\CurrentControlSet\Control\Terminal Server","TSAppCompat", testVar
Set objServer=objLocator.ConnectServer(".","root\default")
Do While True
Loop

    the connection to 10.6.8.73 is not removed. The only difference is the GetDwordValue command. I tried setting testVar to Nothing before the infinite loop starts, but that didn't help. I let it run for 15 minutes and the connection was still active.

    Thanks for the tip about SysInfo, but it doesn't give all the information I need. I looked at msInfo32 as well, but it doesn't give everything either.

    Andrew

     
  • 16 mai 2012 16:34
     
     
    Sign in pentru a vota
    0

    Just to be clear: The scripts above were written in Notepad++ and saved as "test.vbs". I didn't leave anything out - those are the exact scripts.

    They were executed from a command prompt with administrative privileges by typing "cscript test.vbs".

    The TCP connections were checked by running "netstat 30 > tcp.txt" and looking at "tcp.txt" every couple of minutes.

    Andrew


    • Editat de AndrewK123 16 mai 2012 16:39 added last sentence
    •  
     
  • 16 mai 2012 16:34
     
      Are cod
    Sign in pentru a vota
    1

    I am a student and figuring this out is my project, so we won't be hiring anyone else. Our version of Sydi has been modified and expanded to gather more information that is relevant from a security perspective. For example, rather than just listing the software that is installed, I'm listing the user profile that was active when the software was installed and the path it was installed from. I've also written a script that creates an MDB database from the XML report files, and then allows the user to search for various things.

    I have brought this down to a simple test script. When I run this from a command prompt with administrator privileges:

    Set objLocator = CreateObject("WbemScripting.SWbemLocator")	
Const HKEY_LOCAL_MACHINE = &H80000002			
Set objServer = objLocator.ConnectServer("10.6.8.73","root\default")
Set objServer = objServer.Get("StdRegProv")
Set objServer = objLocator.ConnectServer(".","root\default")
Do While True
Loop

    the connection to 10.6.8.73 (which is not my machine) appears and then is gone after about 3 minutes - just as expected. The connection to the local server at the end is required in order to break the connection to 10.6.8.73.

    When I run this instead:

    Set objLocator = CreateObject("WbemScripting.SWbemLocator")	
Const HKEY_LOCAL_MACHINE = &H80000002			
Set objServer = objLocator.ConnectServer("10.6.8.73","root\default")
Set objServer = objServer.Get("StdRegProv")
objServer.GetDwordValue HKEY_LOCAL_MACHINE,"SYSTEM\CurrentControlSet\Control\Terminal Server","TSAppCompat", testVar
Set objServer=objLocator.ConnectServer(".","root\default")
Do While True
Loop

    the connection to 10.6.8.73 is not removed. The only difference is the GetDwordValue command. I tried setting testVar to Nothing before the infinite loop starts, but that didn't help. I let it run for 15 minutes and the connection was still active.

    Thanks for the tip about SysInfo, but it doesn't give all the information I need. I looked at msInfo32 as well, but it doesn't give everything either.

    Andrew

    You cannot disconenct or do a garbage collection when you are in an infinite loop.

    Try this:

    While True
       WScript.Sleep 500
    Wend

    This should allow the GC to remove all refrences to any discarded variables.  Doing a SET on objServer just throws away (sets to nothing) the existing version of the object but the GC never gets to remove it.  The connection is cached and remains valid.  The same will be true in the HTA.  Until the event (function) completes back to the GUI there will be no GC so all connections will remain open.  If the loop take an hour to complete then all conenctions will remain for that long.

    Using an HTA for this is a very bad idea.  You do not have enough control over the process.  I told the original writer of SYDI that this would be the case. 

    You are also doing something that PowerShell was created to make possible.  VBScript and WSH have limits.  They perform poorly and unrealialbly in big projects.  PowerSHell has facilities to overcome these limitations.

    You might be able to get this to work but it may take a considerable amount of difficult debugging.  It is probably a good learning tool to teach how not to design something.

    I suspect but am not convinced that WSH will do a GC when memory gets low for the app session.  I have not seen this documented but it would seem to be a proper way to design an application memory manager so the probelm may not persist forever - just until you are very low on app memory.

    ¯\_(ツ)_/¯

     
  • 16 mai 2012 16:40
    Moderator
     
     
    Sign in pentru a vota
    0

    Another suggestion would be to simply ignore the logon/logoff events for certain time frames when you run the tool.

    Bill

     
  • 16 mai 2012 16:55
     
     
    Sign in pentru a vota
    0

    Another suggestion would be to simply ignore the logon/logoff events for certain time frames when you run the tool.

    Bill

    That would be nice - and is possible as a last resort. But, the whole thing got started because one of our remote admins called me and was rather concerned that his security logs had the username of a "security guy" all over them. If I can't fix it, we'll just have to live with it.

    Thanks,

    Andrew

     
  • 16 mai 2012 16:57
    Moderator
     
     Răspuns propus
    Sign in pentru a vota
    0

    You could also create a special account under which to run this tool and run the tool only using that account. In this way you could ignore security events generated by this account during the times you know the tools has been run. (If the account's name appears outside of those time frames then you would have cause for concern.)

    Bill

     
  • 16 mai 2012 17:10
     
      Are cod
    Sign in pentru a vota
    0

    Using an HTA for this is a very bad idea.  You do not have enough control over the process.  I told the original writer of SYDI that this would be the case. 

    You are also doing something that PowerShell was created to make possible.  VBScript and WSH have limits.  They perform poorly and unrealialbly in big projects.  PowerSHell has facilities to overcome these limitations.

    Unfortunately, PowerShell is not available.

    What do you think about using the Sydi-Wrapper design instead? Ie: I would use the HTA to get the collection options, then the loop would look something like this:

    For Each strComp In arrComp
  Create a shell object
  execute "cscript sydi.vbs strComp <option list>" in that shell
Next

    Do you think I'd just end up with the same problems? Or would the connections be broken when "sydi.vbs" finishes executing and the program moves on to the next computer and creates another shell object. I'm going to try this anyway - if it doesn't work, at least I'll have learned something.

    Thanks,

    Andrew

     
  • 16 mai 2012 17:18
    Moderator
     
     
    Sign in pentru a vota
    0
    Unfortunately, PowerShell is not available.

    Just FYI - you don't have to have PowerShell installed on all the machines you're querying unless you're doing remoting. All you need is PowerShell on the computer from which you're running the script (except, as I said, if you need to do remoting).

    Bill

     
  • 16 mai 2012 17:27
     
      Are cod
    Sign in pentru a vota
    0

    Using an HTA for this is a very bad idea.  You do not have enough control over the process.  I told the original writer of SYDI that this would be the case. 

    You are also doing something that PowerShell was created to make possible.  VBScript and WSH have limits.  They perform poorly and unrealialbly in big projects.  PowerSHell has facilities to overcome these limitations.

    Unfortunately, PowerShell is not available.

    What do you think about using the Sydi-Wrapper design instead? Ie: I would use the HTA to get the collection options, then the loop would look something like this:

    For Each strComp In arrComp
  Create a shell object
  execute "cscript sydi.vbs strComp <option list>" in that shell
Next

    Do you think I'd just end up with the same problems? Or would the connections be broken when "sydi.vbs" finishes executing and the program moves on to the next computer and creates another shell object. I'm going to try this anyway - if it doesn't work, at least I'll have learned something.

    Thanks,

    Andrew

    That seem like a big pain in the neck but it would allow all objects to be deleted before starting a new computer.  YOu will still have to aggregate all of the information somehow.

    In all cases you are trying to do something that is at teh limit of the intended use of WSH/VBScript.  It can be made ot work nu twhy?  The SysteInfo program already gives you all of that information.  If someone has assigned this as homework that that instuctor is a sadist.  Even seasoned scripters would have too many issues with this assignment.

    Administrators will use and write scripts but for something of this size we would usualyy grab a third party tool.  I would just pull the info into XML from the MSInfo tool and parse that.

    ¯\_(ツ)_/¯

     
  • 16 mai 2012 17:30
     
     
    Sign in pentru a vota
    0

    Just FYI - you don't have to have PowerShell installed on all the machines you're querying unless you're doing remoting. All you need is PowerShell on the computer from which you're running the script (except, as I said, if you need to do remoting).

    Bill

    Thanks, but it's not likely to be installed on my machine just for this. They are supposed to be rolling out Windows 7 starting sometime in the Fall, and my term is finished at the end of August.

    Hopefully, whatever solution I find will work on Windows 7 machines.

    Andrew