Time to Round Up Those Scripts

I have to admit that after many years of scripting I have scripts all over the place on my computer. They're in a variety of folders on different drives. Some are well organized, and some are not. Some I forgot about, while others have been hiding out in inconspicuous locations for a very long time.

To make matters worse, PCs aren't backed up where I work. Needless to say, if I were to have a disk go bad and lose all my scripts, I would be quite upset.

Instead of trying to hunt down all my scripts and copy them to a USB drive or a network location that is backed up, I decided to round them all up with a script. ScriptRoundUp.vbs uses Windows Management Instrumentation (WMI) to find all the .vbs and .hta files on my local C and D drives. The query used in the script can easily be modified to look at different local drives and to look for other file extensions, so you could round up Windows PowerShell scripts, Microsoft Word documents, or Microsoft Excel spreadsheets by making just a slight modification. Let's look at how to use ScriptRoundUp.vbs and how it works.

How to Use the Script
Locating files using WMI is nothing new to most scripters, so what sets ScriptRoundUp.vbs apart from the many WMI scripts that you might already have? The main difference is that ScriptRoundUp.vbs makes copies of all the files meeting the specified criteria and places those copies in a centralized location so that you have all your scripts in one location. You can then copy them from the centralized location to a USB drive or network location in one fell swoop. This centralized location is hardcoded in the script as C:\Scripts\AllScripts\ScriptFiles. The script doesn't create this folder, so you must create it prior to running the script.

If you want to store the copies in a different folder, you just need to find the code

ColPath = "C:\Scripts\AllScripts\"
DestRoot = ColPath & "ScriptFiles"

at the beginning of ScriptRoundUp.vbs. (You can download this script by clicking the Download the Code Here link at the top of the page.) ColPath is the collection path where the script creates and stores an .xml database that contains information about all the files returned by the WMI query. In this case, the C:\Scripts\AllScripts folder contains the .xml database. DestRoot specifies the destination root folder where all the scripts will be stored—in this case, it's the ScriptFiles folder. You can change this subfolder by modifying the second line, but be sure to leave the variable names ColPath and DestRoot intact. Once again, you need to create the subfolder before running the script.

VBScript files and HTML Applications (HTAs) usually don't take up a lot of space. (I have well over a thousand scripts and HTAs and they consume only about 56MB total.) However, if your C drive is extremely low on disk space, you might want to change the ColPath value to another folder location on a different drive.

The only other code you might want to modify is the WMI query

strQuery = "Select Drive,Name,Extension,Path from CIM_DataFile " & _
  "Where (Drive='c:' OR Drive='d:') AND (extension='vbs' OR extension='hta')"

This query looks for VBScript and HTA files on the C and D drives. You can easily modify this code to look for different types of files on different local drives. For example, if you want to find JScript and PowerShell files, you'd modify the statement to look like

strQuery = "Select Drive,Name,Extension,Path from CIM_DataFile " & _
  "Where (Drive='c:' OR Drive='d:') AND (extension='js' OR extension='ps1')"

After running the script (which could take a while), open the destination root folder. You should find a folder for each of the hard drives listed in the query. If you open these folders, you should see a myriad of subfolders that contain your VBScript scripts and HTAs.

Before running ScriptRoundUp.vbs a second time, I suggest that you delete all the files and folders from the C:\Scripts\AllScripts folder after you've copied them to a safe place. If you leave them on your hard drive and run the script again, you'll end up collecting those files as well, virtually doubling the time it takes to run the script and doubling the amount of space used to house the files.

I should also point out that I chose to use a database as an interim holding tank because using a database makes the process much cleaner than copying files directly from WMI collections. Plus, if I decide to extend this script's functionality (e.g., have it look for duplicate files), I would have a means to do so.