I recently switched from another product to ImageForWindows. I like its features and really like the fact it is a relatively small utility (the other product has grown to become much too big and complicated).
Two features that I miss from the other product are: (1) the ability to request a differential backup backup without concern for whether the full-backup file exists, and (2) having a scheduled backup be visible to a user with restricted credentials.
I may need to explain (2). When I use the Windows task scheduler to run IFW with Admin credentials, another user who is logged on at the time the backup is scheduled to run will not see any window or icon in the system tray to indicate the backup is running. If the backup fails or is not scheduled as expected, the user may not realize there is a problem.
I wrote two vbscripts to give me these features. I use it on a WinXP system. My design objectives were:
-- scripts can be run by a user with less than Administrator privileges
-- backup operation is visible to the user
-- differential backup will not fail if full-backup file does not exist
I use two vbscripts. The first script (ImageVolume.vbs) is invoked by the user who specifies the volume to backup, the full-backup file name and the type of backup to take (full or differential). The second script (ImageVolumeProc.vbs) is invoked by the first script. It runs with Admin privileges and it runs ImageForWindows with the needed Admin privileges.
If a differential backup is requested and the full-backup file does not exist, the backup type is changed to full.
I use a third-party freeware program called RunItAs from http://www.chessware.ch
to invoke the second script with Admin credentials. Unforunately, using a vbscript in this way opens a hole in system security. The second vbscript could be changed accidentally or intentionally to do something harmful and it would run with elevated privileges. This is not a problem for me because I use this on a system where I am the only user.
This problem could be avoided by either requiring the user to enter the Adminstrator's password or replace the second vbscript with a compiled program that cannot be changed without breaking the RunItAs connection. If you prompt for password, RunItAs is not needed. The second vbscript can be invoked directly using the shell.Run command with the "runas" parameter.
There is at least one other item where there is room for improvement so I welcome comments. The mapping between volume letter and drive/partition numbers is hard coded.
These items may be intolerable for others. For my purposes, I can live with these shortcomings although I would be very interested in learning how to dynamically map volume to drive/partition.
If you wish to use the Windows task scheduler with the first script, you should create a task that invokes wscript with appropriate parameters. For example:
wscript C:\Util\ImageVolume.vbs F H:\Bkups\Volume DIFF
The two scripts are attached. I hope their comments are sufficient to explain how they work. If you do want to use them, you will need to change the code that maps volume letters to drive/parition numbers and probably will want to change file and folder names according to your preferences.
I am not sure what is the proper procedure for this forum. I did not include any type of ReadMe file or identifying information. If that is needed, I will be happy to provide it.
- (4.27 KiB) Downloaded 2007 times