Remote Information Collector

[SkinnyWhiteGuy]

Remote Information Collector

What it does:

This program will attempt to collect a range of information from remote computer systems witout you having to install special scripts on the remote systems as quickly as possible.

What the zip file contains:

I have included the source files needed to compile the program. One of the source files, Project_Compile, can be used to recompile the program from source and know that it will work (compiles files in order so that the last file that FileInstalls some of the others is done then). The program is called RIC.exe, and is over 1 MB when compiled (just to big to put on the forums).

How it works:

This is my simple attempt at explaining as much of this code as I can here. Of course, if anyone has any more in-depth quetions, just reply here, or send me a PM. I know I won't be able to cover everything.

This program is actually 3 seperate scrips that run at the same time (with one part running multiple times). I did this because AutoIt doesn't do multi threading itself, and this made the script faster than doing everything in one file. It also gave me the ability to handle stuck components with the 3rd script I added recently to this. Here is how things are split up:

• Main Script, called RIC. This script actually just deals with the GUI, sends commands to scan computers, and tries to watch for processes that are stuck to restart them.
• Plugin Script, called Plugin. This is the script that actually pulls the information from a computer. It is ran once per computer, so seeing a lot of this script running at scanning time is not uncommon.
• Watcher Script, called Watcher. This script, added recently, is to help with some computers that, when scanned, somehow manage to lock the Main Script up and keep it from managing the sub-processes. (More on why I think that is later.)

From here, things get a lot more in-depth, so I'll tackle the scripts one at a time.

Main Script

This is the main program people see when I compile it. All other files are compiled/FileInstalled into this one, so I can distribute just this file to others and not worry about anything not being there. The support files are installed to a temp directory, and are deleted out when the program exits normally. While loading, it reads the newly installed Plugin.exe file, and reads the list of entries it supports from the FileVersion information that is set on compilation, so I can update just the Plugin and know the main script will keep up. This list is used to make the columns in the Gui (except the name, that one is static).

From the main GUI screen, you can scan computers a few different ways. Simplest method is to double click on an empty area, which inserts a blank entry and allows you to type in a computer name/ip address. Once the control looses focus, it will ping, then scan the computer. For mass operations, which the program was really designed for, there are 2 options: load a list of computers from a text file, or scan an IP range, both options available from the File Menu at the top. It will scan as many of the computers as it can (rescanning entries that take too long to respond, up to 3 retries), and pull information from any computer it can successfully ping and connect to the WMI. While the program is scanning, the title will have a "Working" listed on it, and once it is done, that will disappear.

I use the WMI method of pinging computers, coupled with ExecQueryAsync, to make the ping step run a lot faster than possible with AutoIt's builtin Ping command. I didn't find a lot of information on the forums about ExecQueryAsync (actually, besides my post, there was only one other post that even mentioned this feature of WMI, and that wasn't explained, but just shown off). ExecQueryAsync works just the same as the tried and true ExecQuery that Scriptomatic gives everyone, except it allows us to request information, and without stopping, go do something else. When the data is ready, it fires off a predefined function in our script, and then goes right back to what it was doing before. Not having to wait for one computer to fail a ping before we move on to the next makes things run a lot faster. I also make use of this method in the Plugin to get all the data we want.

If a computer is online, I run the Plugin script with the name of that computer as one paramater passed into it. The other is a special value used to only run the queries we need for the columns we actually show. The plugins use ExecQueryAsync, along with GetAsync for registry values, to ask for each bit of information we need, and returns what it finds via a COPYDATA send message to our main script. To keep things running smoothly, all the main script does when it receives that message is pull the data out of the structure, store it in a queue, and then send itself a PostMessage with our special value to let the program know that, when it has time, there is new data to update the GUI with. Thanks to Uten for this method, as this keeps the script from waiting that much while the COPYDATA message is processed (which does block anything else from happening).

The main GUI has a lot of other stuff going on (hiding columns, rearranging columns, rescanning and deleting specific entries, saving output to a csv file), but all that can be seen in the file by itself.

Plugin

The plugin script is much simpler than the main script, even if it does the heavy lifting for the program. It double checks our command line, and ensures we only scan a particular computer once at a time. It then sets up the Plugins information to run. Note that the order here should be the same as the order in our resource update string, as that's how the special flags parameter is coded. I haven't figured how to update that dynamically for the plugin, nor have I decided that just running the Plugin with no parameters just lists the supported entries.

It then connects to the remote computer via ConnectServer, sets up security on the connection, and fires off the Async queries that are needed (based on the flags parameter we receive). If it could not connect to the remote computer's WMI, it tells the main script to show a yellow entry for that, meaning the computer is online, but we couldn't get any other information from it. Each query is custom tailored to pull just the info we need from it, and send that information back to the main script as a COPYDATA message.

Some queries are done the normal WMI way, just returning the first entry we need to the main script. Others aggregate data across all entries, and upon finishing finding all that data, send it to the main script in that way. Asking for information from the registry on remote computers is a little different, but easy enough. Just research the different ways you ask for data from the registry via WMI, and it explains everything in detail.

Once all queries are completed, the plugin terminates.

Watcher

This is the simplest script in the bundle, but at times, it can be the most important. With all the message passing, copying info, and running of programs, some plugin processes can cause both it and the main script to hang and not respond to anything. The best solution I found for those was to kill the Plugin process that had the program locked up, which caused everything else to continue to run smoothly. Rather than do this by hand, I made this script, which watches for our Plugins scripts to run, and while they are running, keeps up with how long each program is running. If any Plugin program has been running for more than 15 seconds, it's command line is read, it is terminated, and then reran to attempt to still read the data. I chose 15 seconds here, mainly because the main GUI will do much the same thing, but for 10 seconds before it reruns a script. This second check here is for locked processes only, since the main GUI would catch slow plugins before it would. Watcher runs as long as the main GUI does, and closes out when it disappears.

Design Considerations:

I tested a lot of solutions in coming to the current version of this setup. I tried separate processes for each data entry we wanted, but that made the number of files grow very fast, as well as flooded the computer with different processes all running at the same time. I tried running everything from within the main GUI, but it tended to slow things down, since it could only do one thing at a time, even with the Async methods I have. I tried having the Plugin modify the Main GUI's listview itself instead of passing messages, but that was also slow, as well as prone to errors/not showing data. I tried running pings from everywhere, and the current solution was the quickest for pinging multiple computers quickly. I have the Main GUI repinging computers that return online, but no WMI 3 times, because when massively pulling data, some computers returned no WMI on one run, but when reran just a few minutes later with less traffic, they returned good data. For the most part, when I used my own versions of functions that I know AutoIt has UDF's for, it was to run faster, and ignore some error conditions that didn't matter to me. I'm sure that's not all, so if you wonder anything else about this setup, just say so.

What's next:

Even though the script is fairly complete in terms of scanning and returnning good results, I still have a lot of ideas to implement in this script.

• Search function for all columns
• Built-in Print functionality
• Reset entry to blank out all values for a computer to then rescan
• Cosmetic changes to Menu entries
• Possible Help File/Installer
• More output options when saving a file
• Ini file to hold info on hidden columns, column order, last used file location for loading entries, etc...
• Double checking the existence of our Plugin/Watcher scripts after installing, to keep some AV's from blowing things up for us
• The ability to use Alternative Credentials just to pull info with (the main script can be run with different credentials and work just fine, this would just make things easier)

And I have more general Ideas, like using these methods of remote information collection in a script like RAS found on the forums to make it run faster/smoother.

My only other dilema is with software, or more specifically, how to list it. I can easily get a list of all installed software from a computer using these steps, but then how would I show it? Each Software entry gets it's own column? What if only one computer out of 100 has that software, that's wasted space for every other entry. All software in one column? That column would get rather large for some computers, and be very hard to just look at for quick info. And, with all our other columns already there, it would simply hide everything else we wanted to see. To that effect, the only thing I could think to do, would be to either make it a separate program all together, or have a Software tab on this program that just received all software in the background, while our main tab became a Hardware tab to show all the hardware information we have. I haven't made my mind up on that yet.

The End

If you have any questions/comments, please feel free. If you want to use this script at your workplace, have at it. Coworkers have asked me when I would start selling this, but everything I put into this, I found information freely on the forums to do it. I hope to encourage more of that, and hopefully help others with this for free. I also wouldn't mind if some one took my idea here, and improved it even more, making it that much better.

My only thing with this, like most other people, is just don't take it, and claim it as your own creation. I have 4 separate folders with old files, test runs, figures, test scripts, and many other things I used in making this. It took me awhile of testing, and many long nights where I couldn't sleep any way were used to help make this program better. After all that, and after giving the results away for free, I would at least like to have the credit for making this version of it.

RIC.zip

[cherdeg]

Remote Information Collector

Hey, that's veeery VEEERY cool.

With the tool being targeted at a Windows environment, the "Scan" function could be improved easily by adding the possibility of asking an Active Directory for its sites, Domains, OUs or Groups. The user would enter the FQDN of the top level structure (aka "the Forest") and the tool would provide a summary of its different units to select from (or select all). Using both ways to scan in parallel one could find hosts in a network range not being members of AD. It would be cool to have a generic hostname lookup by DNS, maybe there's an UDF somewhere around here...

...stop! I'm dreaming. 1st I'll need to understand what you did (please don't disturb until 2012).

[SkinnyWhiteGuy]

Thanks cherdeg.

I also had the idea at one point about using Active Directory as a source of computers. I currently don't have access to a domain to test this (we have one at work, but I'm not supposed to play with it), but once I can play with that some, that may very well become an option. What others are doing now, is exporting a list of computers from AD to a text file, and then importing those into the program. A little awkward, but it gets the job done.

As to the DNS lookup, it almost does that now. Basically, if you can ping it with a specific name from the command line, you should be able to enter it into the program and have it work. I'm not sure how fully supported that is with WMI, as I just pass whatever name is given to the WMI functions.

And yeah, I do need to clean up the code some more. I at least need to rename some functions and organize things where they actually make sense.

[mikeyr]

WOW !

What a great program and I am already using it

It worked on 2 computers but not 3 of them in our test lab, I am guessing there is some priv or protection that is different on those 3, any ideas what would be the issue.

Next level is 38 computers

[yehia]

WOW GR8 project didnt know we can get all that info using ip thanks alot for sharing

btw after some testing it worked only on my ip xD dont know y

Edited April 29, 2009 by yehia

[SkinnyWhiteGuy]

The trick with getting it to work on lots of PCs is that you have to run the program as a user that has Admin rights on the boxes you are trying to remotely collect info on. Works great here at work, with an account that is setup as a local admin on each box. There are ways to give it other credentials, but that's another update. If you look in the source, there is a USER and PASSWORD constant variables you can set, and it will try to connect to the remote machines using those credentials. Those variables should be in the Constants.au3 file.

[UEZ]

How about command line parameters? E.g. if you want to scan the systems periodically silent in the background (scheduled) and save the results to a file.

I didn't test it yet, only local on my pc, but is it able to do multi threading reading information from systems?

Maybe I can test it tomorrow!

UEZ

[mikeyr]

Setting the user/pass in constants to a Admin user did not work

I did notice that if I turn off the firewall on the machines I am scanning, the "square" in the first column is a greenish color vs. when the firewall is on and then its a blue square, so I am guessing I need to open a port on the firewall at the very least but even with it OFF it did not come back with info.

Comparing the 2 that work with the 3 that don't right now.

[SoftVoile]

huh, you should also add short description. Btw: it's a nice and good code. also useful... thanks

5*****

[yehia]

Setting the user/pass in constants to a Admin user did not work

I did notice that if I turn off the firewall on the machines I am scanning, the "square" in the first column is a greenish color vs. when the firewall is on and then its a blue square, so I am guessing I need to open a port on the firewall at the very least but even with it OFF it did not come back with info.

Comparing the 2 that work with the 3 that don't right now.

yes same for me and i guess if u meant admin privs for the remote box then there is something wrong i looked up about 15 ip all found but yellow and from your explanation that meants cant get info

is this a bug or just the script limits?

Edited April 30, 2009 by yehia

[cherdeg]

And yeah, I do need to clean up the code some more. I at least need to rename some functions and organize things where they actually make sense.

Don't get me wrong...my comment wasn't targeting your code but only my -quite limited- ability to rapidly understand it.

I'm very looking forward to all the improvements the guys here will post - and to you keeping the code alive.

[UEZ]

How about command line parameters? E.g. if you want to scan the systems periodically silent in the background (scheduled) and save the results to a file.

I didn't test it yet, only local on my pc, but is it able to do multi threading reading information from systems?

Maybe I can test it tomorrow!

UEZ

I tested it and it seems to be working. I used similar technique in SIC2 but I'm using only 1 exe and it is command line only (thus not very popular)!

UEZ

[mdwerne]

Very cool script, I can already see some potential uses using the techniques you employed. Thank you for posting it.

I have a quick question if you don't mind, is there anyway to modify your code to do the WMI query using environmental variables for the %SystemDrive% instead of hard coding in "c:\". While infrequent, some people load the OS on "D" or other random drive letters.

I wish I had something worthy of posting that followed your lead and attitude of sharing.

Thanks again,

Mike

[makiel]

Remote Information Collector

What it does:

This program will attempt to collect a range of information from remote computer systems witout you having to install special scripts on the remote systems as quickly as possible.

What the zip file contains:

I have included the source files needed to compile the program. One of the source files, Project_Compile, can be used to recompile the program from source and know that it will work (compiles files in order so that the last file that FileInstalls some of the others is done then). The program is called RIC.exe, and is over 1 MB when compiled (just to big to put on the forums).

How it works:

This is my simple attempt at explaining as much of this code as I can here. Of course, if anyone has any more in-depth quetions, just reply here, or send me a PM. I know I won't be able to cover everything.

This program is actually 3 seperate scrips that run at the same time (with one part running multiple times). I did this because AutoIt doesn't do multi threading itself, and this made the script faster than doing everything in one file. It also gave me the ability to handle stuck components with the 3rd script I added recently to this. Here is how things are split up:

• Main Script, called RIC. This script actually just deals with the GUI, sends commands to scan computers, and tries to watch for processes that are stuck to restart them.
• Plugin Script, called Plugin. This is the script that actually pulls the information from a computer. It is ran once per computer, so seeing a lot of this script running at scanning time is not uncommon.
• Watcher Script, called Watcher. This script, added recently, is to help with some computers that, when scanned, somehow manage to lock the Main Script up and keep it from managing the sub-processes. (More on why I think that is later.)

From here, things get a lot more in-depth, so I'll tackle the scripts one at a time.

Main Script

This is the main program people see when I compile it. All other files are compiled/FileInstalled into this one, so I can distribute just this file to others and not worry about anything not being there. The support files are installed to a temp directory, and are deleted out when the program exits normally. While loading, it reads the newly installed Plugin.exe file, and reads the list of entries it supports from the FileVersion information that is set on compilation, so I can update just the Plugin and know the main script will keep up. This list is used to make the columns in the Gui (except the name, that one is static).

From the main GUI screen, you can scan computers a few different ways. Simplest method is to double click on an empty area, which inserts a blank entry and allows you to type in a computer name/ip address. Once the control looses focus, it will ping, then scan the computer. For mass operations, which the program was really designed for, there are 2 options: load a list of computers from a text file, or scan an IP range, both options available from the File Menu at the top. It will scan as many of the computers as it can (rescanning entries that take too long to respond, up to 3 retries), and pull information from any computer it can successfully ping and connect to the WMI. While the program is scanning, the title will have a "Working" listed on it, and once it is done, that will disappear.

I use the WMI method of pinging computers, coupled with ExecQueryAsync, to make the ping step run a lot faster than possible with AutoIt's builtin Ping command. I didn't find a lot of information on the forums about ExecQueryAsync (actually, besides my post, there was only one other post that even mentioned this feature of WMI, and that wasn't explained, but just shown off). ExecQueryAsync works just the same as the tried and true ExecQuery that Scriptomatic gives everyone, except it allows us to request information, and without stopping, go do something else. When the data is ready, it fires off a predefined function in our script, and then goes right back to what it was doing before. Not having to wait for one computer to fail a ping before we move on to the next makes things run a lot faster. I also make use of this method in the Plugin to get all the data we want.

If a computer is online, I run the Plugin script with the name of that computer as one paramater passed into it. The other is a special value used to only run the queries we need for the columns we actually show. The plugins use ExecQueryAsync, along with GetAsync for registry values, to ask for each bit of information we need, and returns what it finds via a COPYDATA send message to our main script. To keep things running smoothly, all the main script does when it receives that message is pull the data out of the structure, store it in a queue, and then send itself a PostMessage with our special value to let the program know that, when it has time, there is new data to update the GUI with. Thanks to Uten for this method, as this keeps the script from waiting that much while the COPYDATA message is processed (which does block anything else from happening).

The main GUI has a lot of other stuff going on (hiding columns, rearranging columns, rescanning and deleting specific entries, saving output to a csv file), but all that can be seen in the file by itself.

Plugin

The plugin script is much simpler than the main script, even if it does the heavy lifting for the program. It double checks our command line, and ensures we only scan a particular computer once at a time. It then sets up the Plugins information to run. Note that the order here should be the same as the order in our resource update string, as that's how the special flags parameter is coded. I haven't figured how to update that dynamically for the plugin, nor have I decided that just running the Plugin with no parameters just lists the supported entries.

It then connects to the remote computer via ConnectServer, sets up security on the connection, and fires off the Async queries that are needed (based on the flags parameter we receive). If it could not connect to the remote computer's WMI, it tells the main script to show a yellow entry for that, meaning the computer is online, but we couldn't get any other information from it. Each query is custom tailored to pull just the info we need from it, and send that information back to the main script as a COPYDATA message.

Some queries are done the normal WMI way, just returning the first entry we need to the main script. Others aggregate data across all entries, and upon finishing finding all that data, send it to the main script in that way. Asking for information from the registry on remote computers is a little different, but easy enough. Just research the different ways you ask for data from the registry via WMI, and it explains everything in detail.

Once all queries are completed, the plugin terminates.

Watcher

This is the simplest script in the bundle, but at times, it can be the most important. With all the message passing, copying info, and running of programs, some plugin processes can cause both it and the main script to hang and not respond to anything. The best solution I found for those was to kill the Plugin process that had the program locked up, which caused everything else to continue to run smoothly. Rather than do this by hand, I made this script, which watches for our Plugins scripts to run, and while they are running, keeps up with how long each program is running. If any Plugin program has been running for more than 15 seconds, it's command line is read, it is terminated, and then reran to attempt to still read the data. I chose 15 seconds here, mainly because the main GUI will do much the same thing, but for 10 seconds before it reruns a script. This second check here is for locked processes only, since the main GUI would catch slow plugins before it would. Watcher runs as long as the main GUI does, and closes out when it disappears.

Design Considerations:

I tested a lot of solutions in coming to the current version of this setup. I tried separate processes for each data entry we wanted, but that made the number of files grow very fast, as well as flooded the computer with different processes all running at the same time. I tried running everything from within the main GUI, but it tended to slow things down, since it could only do one thing at a time, even with the Async methods I have. I tried having the Plugin modify the Main GUI's listview itself instead of passing messages, but that was also slow, as well as prone to errors/not showing data. I tried running pings from everywhere, and the current solution was the quickest for pinging multiple computers quickly. I have the Main GUI repinging computers that return online, but no WMI 3 times, because when massively pulling data, some computers returned no WMI on one run, but when reran just a few minutes later with less traffic, they returned good data. For the most part, when I used my own versions of functions that I know AutoIt has UDF's for, it was to run faster, and ignore some error conditions that didn't matter to me. I'm sure that's not all, so if you wonder anything else about this setup, just say so.

What's next:

Even though the script is fairly complete in terms of scanning and returnning good results, I still have a lot of ideas to implement in this script.

• Search function for all columns
• Built-in Print functionality
• Reset entry to blank out all values for a computer to then rescan
• Cosmetic changes to Menu entries
• Possible Help File/Installer
• More output options when saving a file
• Ini file to hold info on hidden columns, column order, last used file location for loading entries, etc...
• Double checking the existence of our Plugin/Watcher scripts after installing, to keep some AV's from blowing things up for us
• The ability to use Alternative Credentials just to pull info with (the main script can be run with different credentials and work just fine, this would just make things easier)

And I have more general Ideas, like using these methods of remote information collection in a script like RAS found on the forums to make it run faster/smoother.

My only other dilema is with software, or more specifically, how to list it. I can easily get a list of all installed software from a computer using these steps, but then how would I show it? Each Software entry gets it's own column? What if only one computer out of 100 has that software, that's wasted space for every other entry. All software in one column? That column would get rather large for some computers, and be very hard to just look at for quick info. And, with all our other columns already there, it would simply hide everything else we wanted to see. To that effect, the only thing I could think to do, would be to either make it a separate program all together, or have a Software tab on this program that just received all software in the background, while our main tab became a Hardware tab to show all the hardware information we have. I haven't made my mind up on that yet.

The End

If you have any questions/comments, please feel free. If you want to use this script at your workplace, have at it. Coworkers have asked me when I would start selling this, but everything I put into this, I found information freely on the forums to do it. I hope to encourage more of that, and hopefully help others with this for free. I also wouldn't mind if some one took my idea here, and improved it even more, making it that much better.

My only thing with this, like most other people, is just don't take it, and claim it as your own creation. I have 4 separate folders with old files, test runs, figures, test scripts, and many other things I used in making this. It took me awhile of testing, and many long nights where I couldn't sleep any way were used to help make this program better. After all that, and after giving the results away for free, I would at least like to have the credit for making this version of it.

[makiel]

Remote Information Collector

What it does:

This program will attempt to collect a range of information from remote computer systems witout you having to install special scripts on the remote systems as quickly as possible.

What the zip file contains:

The script is not running. Do we need to have domain admin account on AD? if yes, we do not. We only control our OU. Is there any way we can use it in using our permission to the OU?

Thanks

I have included the source files needed to compile the program. One of the source files, Project_Compile, can be used to recompile the program from source and know that it will work (compiles files in order so that the last file that FileInstalls some of the others is done then). The program is called RIC.exe, and is over 1 MB when compiled (just to big to put on the forums).

How it works:

This is my simple attempt at explaining as much of this code as I can here. Of course, if anyone has any more in-depth quetions, just reply here, or send me a PM. I know I won't be able to cover everything.

This program is actually 3 seperate scrips that run at the same time (with one part running multiple times). I did this because AutoIt doesn't do multi threading itself, and this made the script faster than doing everything in one file. It also gave me the ability to handle stuck components with the 3rd script I added recently to this. Here is how things are split up:

• Main Script, called RIC. This script actually just deals with the GUI, sends commands to scan computers, and tries to watch for processes that are stuck to restart them.
• Plugin Script, called Plugin. This is the script that actually pulls the information from a computer. It is ran once per computer, so seeing a lot of this script running at scanning time is not uncommon.
• Watcher Script, called Watcher. This script, added recently, is to help with some computers that, when scanned, somehow manage to lock the Main Script up and keep it from managing the sub-processes. (More on why I think that is later.)

From here, things get a lot more in-depth, so I'll tackle the scripts one at a time.

Main Script

This is the main program people see when I compile it. All other files are compiled/FileInstalled into this one, so I can distribute just this file to others and not worry about anything not being there. The support files are installed to a temp directory, and are deleted out when the program exits normally. While loading, it reads the newly installed Plugin.exe file, and reads the list of entries it supports from the FileVersion information that is set on compilation, so I can update just the Plugin and know the main script will keep up. This list is used to make the columns in the Gui (except the name, that one is static).

From the main GUI screen, you can scan computers a few different ways. Simplest method is to double click on an empty area, which inserts a blank entry and allows you to type in a computer name/ip address. Once the control looses focus, it will ping, then scan the computer. For mass operations, which the program was really designed for, there are 2 options: load a list of computers from a text file, or scan an IP range, both options available from the File Menu at the top. It will scan as many of the computers as it can (rescanning entries that take too long to respond, up to 3 retries), and pull information from any computer it can successfully ping and connect to the WMI. While the program is scanning, the title will have a "Working" listed on it, and once it is done, that will disappear.

I use the WMI method of pinging computers, coupled with ExecQueryAsync, to make the ping step run a lot faster than possible with AutoIt's builtin Ping command. I didn't find a lot of information on the forums about ExecQueryAsync (actually, besides my post, there was only one other post that even mentioned this feature of WMI, and that wasn't explained, but just shown off). ExecQueryAsync works just the same as the tried and true ExecQuery that Scriptomatic gives everyone, except it allows us to request information, and without stopping, go do something else. When the data is ready, it fires off a predefined function in our script, and then goes right back to what it was doing before. Not having to wait for one computer to fail a ping before we move on to the next makes things run a lot faster. I also make use of this method in the Plugin to get all the data we want.

If a computer is online, I run the Plugin script with the name of that computer as one paramater passed into it. The other is a special value used to only run the queries we need for the columns we actually show. The plugins use ExecQueryAsync, along with GetAsync for registry values, to ask for each bit of information we need, and returns what it finds via a COPYDATA send message to our main script. To keep things running smoothly, all the main script does when it receives that message is pull the data out of the structure, store it in a queue, and then send itself a PostMessage with our special value to let the program know that, when it has time, there is new data to update the GUI with. Thanks to Uten for this method, as this keeps the script from waiting that much while the COPYDATA message is processed (which does block anything else from happening).

The main GUI has a lot of other stuff going on (hiding columns, rearranging columns, rescanning and deleting specific entries, saving output to a csv file), but all that can be seen in the file by itself.

Plugin

The plugin script is much simpler than the main script, even if it does the heavy lifting for the program. It double checks our command line, and ensures we only scan a particular computer once at a time. It then sets up the Plugins information to run. Note that the order here should be the same as the order in our resource update string, as that's how the special flags parameter is coded. I haven't figured how to update that dynamically for the plugin, nor have I decided that just running the Plugin with no parameters just lists the supported entries.

It then connects to the remote computer via ConnectServer, sets up security on the connection, and fires off the Async queries that are needed (based on the flags parameter we receive). If it could not connect to the remote computer's WMI, it tells the main script to show a yellow entry for that, meaning the computer is online, but we couldn't get any other information from it. Each query is custom tailored to pull just the info we need from it, and send that information back to the main script as a COPYDATA message.

Some queries are done the normal WMI way, just returning the first entry we need to the main script. Others aggregate data across all entries, and upon finishing finding all that data, send it to the main script in that way. Asking for information from the registry on remote computers is a little different, but easy enough. Just research the different ways you ask for data from the registry via WMI, and it explains everything in detail.

Once all queries are completed, the plugin terminates.

Watcher

This is the simplest script in the bundle, but at times, it can be the most important. With all the message passing, copying info, and running of programs, some plugin processes can cause both it and the main script to hang and not respond to anything. The best solution I found for those was to kill the Plugin process that had the program locked up, which caused everything else to continue to run smoothly. Rather than do this by hand, I made this script, which watches for our Plugins scripts to run, and while they are running, keeps up with how long each program is running. If any Plugin program has been running for more than 15 seconds, it's command line is read, it is terminated, and then reran to attempt to still read the data. I chose 15 seconds here, mainly because the main GUI will do much the same thing, but for 10 seconds before it reruns a script. This second check here is for locked processes only, since the main GUI would catch slow plugins before it would. Watcher runs as long as the main GUI does, and closes out when it disappears.

Design Considerations:

I tested a lot of solutions in coming to the current version of this setup. I tried separate processes for each data entry we wanted, but that made the number of files grow very fast, as well as flooded the computer with different processes all running at the same time. I tried running everything from within the main GUI, but it tended to slow things down, since it could only do one thing at a time, even with the Async methods I have. I tried having the Plugin modify the Main GUI's listview itself instead of passing messages, but that was also slow, as well as prone to errors/not showing data. I tried running pings from everywhere, and the current solution was the quickest for pinging multiple computers quickly. I have the Main GUI repinging computers that return online, but no WMI 3 times, because when massively pulling data, some computers returned no WMI on one run, but when reran just a few minutes later with less traffic, they returned good data. For the most part, when I used my own versions of functions that I know AutoIt has UDF's for, it was to run faster, and ignore some error conditions that didn't matter to me. I'm sure that's not all, so if you wonder anything else about this setup, just say so.

What's next:

Even though the script is fairly complete in terms of scanning and returnning good results, I still have a lot of ideas to implement in this script.

• Search function for all columns
• Built-in Print functionality
• Reset entry to blank out all values for a computer to then rescan
• Cosmetic changes to Menu entries
• Possible Help File/Installer
• More output options when saving a file
• Ini file to hold info on hidden columns, column order, last used file location for loading entries, etc...
• Double checking the existence of our Plugin/Watcher scripts after installing, to keep some AV's from blowing things up for us
• The ability to use Alternative Credentials just to pull info with (the main script can be run with different credentials and work just fine, this would just make things easier)

And I have more general Ideas, like using these methods of remote information collection in a script like RAS found on the forums to make it run faster/smoother.

My only other dilema is with software, or more specifically, how to list it. I can easily get a list of all installed software from a computer using these steps, but then how would I show it? Each Software entry gets it's own column? What if only one computer out of 100 has that software, that's wasted space for every other entry. All software in one column? That column would get rather large for some computers, and be very hard to just look at for quick info. And, with all our other columns already there, it would simply hide everything else we wanted to see. To that effect, the only thing I could think to do, would be to either make it a separate program all together, or have a Software tab on this program that just received all software in the background, while our main tab became a Hardware tab to show all the hardware information we have. I haven't made my mind up on that yet.

The End

If you have any questions/comments, please feel free. If you want to use this script at your workplace, have at it. Coworkers have asked me when I would start selling this, but everything I put into this, I found information freely on the forums to do it. I hope to encourage more of that, and hopefully help others with this for free. I also wouldn't mind if some one took my idea here, and improved it even more, making it that much better.

My only thing with this, like most other people, is just don't take it, and claim it as your own creation. I have 4 separate folders with old files, test runs, figures, test scripts, and many other things I used in making this. It took me awhile of testing, and many long nights where I couldn't sleep any way were used to help make this program better. After all that, and after giving the results away for free, I would at least like to have the credit for making this version of it.

[makiel]

It show status is pending and no data populate back on the Remote info gather screen.

[mdwerne]

It show status is pending and no data populate back on the Remote info gather screen.

A few things...

1) Are you an admin on the boxes your collecting data from?

1a) If so, are you hard coding your username and password in the Constants.au3 file or are you simply logged into your machine as the account that is also an admin on the other boxes? (try both methods)

2) What happens if you do a single scan of 127.0.0.1?

3) How many machines are you scanning at once?

4) Are all the machines on a/the same domain?

[Skrip]

What kind of information can be collected using this program? I don't see anything on that in the op.

[mdwerne]

What kind of information can be collected using this program? I don't see anything on that in the op.

By default these are the collected items, some of which I'm unclear as to their utility. Depending on someone skillz(mine are limited), more/different items can be collected.

AD Object,Asset Tag,BIOS Version,Free/Total C:,Error 1085,Error 1096,Gina,Install Date,IP,Last BootUp Time,MAC,Vendor Model,Novell Object,OS,Processor,Total Ram,Display Resolution,SAV/SEP Version,Service Pack,Service Tag,User Name,Video Controller

-Mike

Edited May 6, 2009 by mdwerne

[SkinnyWhiteGuy]

Thanks for listing that mdwerne, I forgot to list those out. These are the ones that people here at work asked for over time, and made it into the current version. Anything that WMI can pull, reading remote registry, and even reading remote files can be added. I'll try to give a quick rundown as to why the ones that are in there are there.

1st off, in my current job, I'm really just a hardware tech. I get the task of upgrading machines, and picking machines to be replaced. I added most of these entries just to help in that respect:

Free/Total C:

Vendor Model

Processor

RAM

Video Controller

The different objects (AD and Novell) where to help track down computers based on where they were listed in our system. We try to keep things organized by location within those systems.

BIOS Version, Gina, Install Date, OS, SAV/SEP (Symantec Antivirus and Symantec Endpoint Protection), and Service Pack are all there to help others with Software upgrades that we may need to perform (when we image a machine, it has been sysprepped, so the Install Date is effectively the date of when the machine was last imaged). Gina refers to whether or not they are logging in with Microsoft's Gina, or Novell's (we are currently migrating from Novell to Microsoft).

Asset Tag is to help identify computers for our records (these should be set to our asset number on file). Last Bootup Time and User Name are to help when someone calls with a problem. It's nice to not have to ask "did you try rebooting your computer", when this script will report that they haven't rebooted since January, and they are logged in as someone else.

IP and MAC address are always nice to have for remote systems, and have proven helpful in tracking down a machine that we knew had a virus in the past.

The only other thing would be Error 1085 and Error 1096. These refer to errors that we encounter frequently, and under the Event Log show up with these Event Codes. The actual functions check file versions for certain files, and depending on the age of the file, show that the system is vulnerable to these errors (which cause many problems) or are safe. I have a feeling that these will be removed in the future. I have code for remotely querying a machine's Event Log to see if certain errors are listed in there, as that is how those two started out in life. I can post that later, if anyone is interested.