Basically just a follow up here. I wanted to use the script in Part 1, with some backup hardware and Windows Scheduler to automate this task.

I wanted to use something that was easy to swap media out and had a large capacity. With the price of hard drives these days, it seemed reasonable that I use something that used a standard SATA internal hard drive. After some research, I decided upon a

NexStar Hard Drive Dock

. 

I picked one up for under $40 and with a 1TB SATA drive, it seemed like a great addition to my backup solution.

Windows Scheduler

Now we need some way to kick of the script. To set the script from the previous post to run automatically on a schedule, I used a utility found in Windows called “Windows Scheduler” You can find this tool under Control Panel. Here’s a picture of what it looks like with this job already setup:

As you can see the job is named “Network Backup” and setup to run once every day at 7:17 PM. I set it up like this since I was unsure of when or if the computers being backed up would be turned on and available or not. I figured there was a pretty good chance that at least once a week, it would get lucky and backup the files on each computer. If you read the previous post, you’ll remember that I only created new backup folders for each week of the month. This will cause the backup files to be placed in the same folder for one week, and then switch to the next folder the following week. That way, I’ll be have the option to go back at least 4 weeks to get a copy of some file or set of files.

Here’s how Windows Scheduler looks with this job setup:

And here is the same window but viewing the schedule information:

With a standard hard drive in the dock, here’s what it looks like:

With the external SATA (eSATA) cable hooked up, this can write files as fast as my 100mb network can feed it.

One thing I promised myself was at some point (early on) I would create an automated backup solution for my home computers. I wanted an automated and easy to configure system that I was confident of backing up my most important files. The criteria for this operation were the following:

• Must use a well known and free backup command-line tool that I could script out exactly how and what I wanted it to do

• Must be capable of being run from a scripting language (preferably VBScript).

• Should be able to copy both large files and large quantities of files that might crash less robust tools

• Have the ability to copy from Windows’ default hidden shares like “C$\” and UNC paths like “\\Foo”

A friend of mine had mentioned a long-time windows utility called Robocopy (he also provided some of the VBScript that I used). This command line tool was designed by Microsoft for reliable mirroring of directories and directory trees. You can check out the wikipedia article for Robocopy if you are so inclined.

Robocopy meets all of the requirements mentioned above.

After setting up the computers on the workgroup with the required permissions and settings, the next step was to create a script file that would for now, manually backup files (I’ll cover an automated solution as well as a database configuration and logging solution in future articles).

I wanted to have a process that would eventually create multiple copies of all the files required for backup. There would be a separate copy of each file for each week of the month. This means I would only get a fresh backup of files once every week. For the types of stuff I wanted to backup (family pictures, music and movie files, code and design files) I felt this was adequate. When viewing the backup destination, I would see a maximum of 6 folders (since there could be 6 different weeks in a month) with names like Week1, Week2, Week3, etc. The directories and files would all be inside these folders. Here’s a copy of what that backup destination structure could look like:

For a script and Robocopy to do this, it should have the following steps:

• Setup of global parameters including a collection of machine\directory paths for configuration

• A process of adding the path information to the destination area including machine name and share name

• From a script, Robocopy will only be provided one source and one destination at a time so there will be a primary loop in the script that loops through all specified source paths

• A process to capture and write the results from the process so it may be reviewed at a later date.

• Functions to determine the week of the month, attempt to create the week folder, and create a name for the results file

• A method of executing the Robocopy tool with the proper commands and capturing the information it provides while executing. This is the key to the whole process!

Robocopy requires a command set like the following example:

“Robocopy \\foo\c$\documents D:\Backups\Week1 /S /NP /R:2 /W:5”

This will tell Robocopy to attempt to connect to the hidden share “c$”  on machine “foo”, and copy everything under the directory “documents”  to the backup destination “d:\Backups\Week1”. The stuff behind the destination are known as switches. The “/S” copies all subdirectories unless they are empty. The “/NP” tells Robocopy to not provide any progress information while copying files. The “/R” is tells the tool to retry 2 times before giving up when there is an error. Finally, the “/W” provides the time to wait before retrying, in this case 5 seconds. There are many other switches, but I’ll leave it to you to research all the unique ways Robocopy can be manipulated.

I won’t go into all of the code, but here is a chunk of code for specifying what source paths there are:

Dim array_Sources(3) ‘Source Paths Array
Dim array_Destinations(3) ‘Destination Paths Array

array_Sources(1)    = “\\octavious\e$\Sierra”
array_Sources(2)    = “\\spartan\c$\logs\”
array_Sources(3)    = “\\Minimac\Lisa\”

As you can see one of the machines is a Mac Mini, which with SMB and the proper account settings, can be backed up as well.

Here’s the key to the whole VBScript and Robocopy marriage to get this system to work:

Set oWSH = WScript.CreateObject(”WScript.Shell”)
Set oCOMMAND = oWSH.Exec(sCommand)

Where sCommand is basically a string containing the Robocopy command line for that specific source and destination set as shown above.

Here’s a copy of the entire VBScript backup solution file.

You can probably find a copy of Robocopy somewhere on Microsoft’s site if you dig around a little.

There’s also a GUI for Robocopy that someone at Microsoft built along with all the files and documentation.

Next I’ll be looking at providing some hardware to this solution so I can easily switch out my backup media with another. Remember, this is only the first step in the overall solution…Eventually we’ll have a database tied to this so we can dynamically assign backup sources and log backup metrics for reporting and monitoring of the backup process.

So one of the things I would like to include in my Home Automation project is the ability to track performance and capacity metrics for all computers in the household. I would like to monitor PC information like hard drive capacity, free drive space, CPU utilization, current processes, maybe a list of installed software, etc.

Fortunately, all of these PCs run Windows XP so that helps considerably. I do have other devices on the local network, but that will be a topic for a later post. Since I know VB quite well and there are a LOT of examples on the web using it and Windows Management Instrumentation (WMI) to gather information on the Windows devices, I’ll use these two tools to do the bulk of this work. Also, I wanted to remotely gather this information and not have each PC contain scripts scheduled to run.

Here’s some information on my current setup:

• All PCs are in the same Windows Workgroup

• All PCs have the same accounts with similar passwords (1 account for logging in and one account for remote access)

• All devices on the network are setup with DHCP for addressing

• Some of the PCs have Windows Firewall enabled

Although XP is pretty open out of the box, there are a few things we need to do before we can successfully run WIM-based VB Scripts remotely:

Windows Security – We need to setup the windows account we’re going to use similarly across all PCs we intend to remotely access. This account should be in the Administrator’s group.

Windows Firewall – We must be able to remotely connect to a PC running Windows Firewall with WMI and VB Script. This will be done by configuring a secure WMI connection in Windows.

Guest User – In a Windows XP workgroup, all remote connections coming from the “network” will be authenticated as a Guest User. A Guest User has very few rights so we must determine how to configure Windows to recognize the account used by the remote connection.

Here are the last two configuration settings in further detail:

Windows Firewall Settings For A Secure WMI Connection –

On the remote computer, we need to grant DCOM (DCOM is basically a Microsoft technology for communicating among software components) remote launch and activation permissions for the user we setup earlier. There’s a good article about this on the MSDN site. There’s a utility  in Windows called DCOMCnfg.exe that’s found in Administrative Tools in Control Panel (you can run this from Start->Run if you prefer). If you open this utility up, it should look something like this:

Once this is open, right-click on “My Computer” and click on the “COM Security” tab. You should see something like this:

For both the “Access Permissions” and “Launch and Activation Permissions” we need to add the user we setup above to the names list in both and make sure all of the “Allow” settings are checked on both dialog boxes. Once this is done, Windows Firewall will allow remote WMI connections to this computer.

Guest User Settings for Remote WMI Connections –

This one was a little tough to find. I had been attempting to run some WMI commands (more on this later) against several PCs and getting Access Denied messages until I discovered this behavior in Windows – When a remote connection is made to a computer in a Windows Workgroup, the user will be authenticated using the “Guest User” account in Windows. This can be reset to use the connection’s credentials by changing a setting in the registry. If you don’t feel comfortable changing registry settings in Windows, don’t attempt this. The registry key is located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and is called “ForceGuest”. By default, this setting is set to 1 (Windows will try to log on using the “Guest” account). If this setting is changed to 0 (disabled), the connection will be logged on as the specified user.  Once this setting is set to 0, you should be able make remote WMI connections using you current account. Their is an article on Microsoft’s support site that walks you through setting this up.

I’ll be working through some VB Script WMI calls in later posts but here is a simple script to find all of the drives on the specified computer “Spartan”:

Set objShell = CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")

strComputer = "Spartan"

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * From Win32_LogicalDisk Where DriveType = 3")

For Each objItem in colItems

    strDriveLetter = objItem.DeviceID

    Wscript.Echo("Found Drive " & strDriveLetter & " On Computer " & strComputer)

Next

After putting this stuff together and working with various scripts across a Windows Workgroup, I’m quite excited about what can be done with WMI and VBScript, but getting the security and configuration setup correctly was much more of a job that I originally thought it would be. A Windows Domain would make this far easier, but I really wanted to stay away from that kind of a setup for my household. I really do hope this helps anyone attempting else using WMI, VBScript and a Windows Workgroup.

I just received my LabJack U3, so I’ll be checking that out in an upcoming post along with more on current and temperature sensors.