Exploiting System Restore
The script begins by defining command-line parameters, then prepares to exploit System Restore. The code in Listing 1 shows the latter process.
First, the code at callout A in Listing 1 includes several external helper functions. DecodeSystemRestoreFunction.vbs contains two functions—DecodeRestorePointType() and DecodeEventType()—to decipher the RestorePointType and EventType properties, respectively. DisplayFormattedPropertyFunction.vbs contains the DisplayFormattedProperty() function, which the script uses to display class properties and their values. TinyErrorHandler.vbs contains the ErrorHandler() function, which the script uses to handle execution errors.
Next, the code at callout B in Listing 1 creates two objects: the SWbemLocator object, which the script uses to perform the WMI connection, and the SWbemDateTime object, which the DisplayFormattedProperty() function uses to manipulate WMI date and time properties. The code at callout C defines two constants: cComputerName, which defines the name of the computer to which to connect, and cWMINameSpace, which defines the WMI CIM repository namespace (i.e., root\default) to which to connect. The code goes on to perform command-line parsing by using the Windows Script Host (WSH) 5.6 XML command-line parsing feature. (See "Secure Script Execution with WSH 5.6," August 2002, InstantDoc ID 25644, for information about this feature.) The code at callout D then establishes the WMI connection.
Viewing Restore Points
The code in Listing 2 displays existing restore points. The code at callout A in Listing 2 retrieves all instances of the SystemRestore class, then the code at callout B enumerates all retrieved SystemRestore instances and their properties. The script calls the DecodeRestorePointType() or DecodeEventType() function to decipher EventType and RestorePointType property values and, with the help of the previously created SWbemDateTime object, converts the CreationTime property's Distributed Management Task Force (DMTF) date and time string to a readable property.
Enabling and Disabling Disk Monitoring
The script uses a simple technique to enable or disable System Restore disk monitoring. The code in Listing 3 uses the Enable method to enable monitoring; the Disable method follows the same technique to disable monitoring. First, the code at callout A in Listing 3 retrieves a SystemRestore class instance. The Enable and Disable methods don't relate to a particular restore point instance but rather have a global effect on the System Restore subsystem. Therefore, the script retrieves an instance of the Restore class instead of retrieving an instance of a specific restore point.
As I explained earlier, you can invoke the Enable or Disable method against a specific disk or against all disks. When the script invokes the methods against all disks, the code at callout B in Listing 3 passes an empty string to the Enable method. The Enable method also accepts a second parameter in the form of a Boolean value to determine whether the method execution must wait until System Restore is fully enabled for the specified disk or disks before returning to the script execution. In the sample script, I've set this parameter to true.
Creating a Restore Point
The code in Listing 4 creates a restore point by invoking the CreateRestorePoint method, similar to the way in which the script invokes the Enable method. The code first retrieves an instance of the SystemRestore class. Then, the code at callout A in Listing 4 invokes the CreateRestorePoint method, which requires three parameters. The first parameter is a description of the restore point, which the script reads from the /Description switch, as I explained earlier. The second parameter corresponds to the RestorePointType property and must be one of the values listed in Web Table 2. The third parameter corresponds to the EventType property and must be one of the values listed in Web Table 1.
To keep the script short and simple, I hard-coded the RestorePointType property's APPLICATION_INSTALL value and the EventType property's BEGIN_SYSTEM_CHANGE value into the code to have the script create a restore point at the beginning of a new application installation. Usually, software-installation programs such as Windows Installer or InstallShield Software's InstallShield automatically create restore points before and after executing an installation. In such a case, you don't need to create your own restore point before you install an application.
When you run scripts that execute system changes or perform changes to the registry, however, you can use WMISystemRestore.wsf in conjunction with the /Action:CreateRestorePoint switch to manually create a preinstallation restore point. After completing an installation, you should edit the script to specify the END_SYSTEM_CHANGE value for the EventType property, which will create a postinstallation restore point. If you decide to cancel the system changes and want to remove that restore point, edit the script to specify the CANCELLED_OPERATION and END_SYSTEM_CHANGE values for the RestorePointType and EventType properties, respectively, to create a new restore point. (The RestorePointType and EventType labels are defined as constants in the DecodeSystemRestoreFunction.vbs file.)
Retrieving Restore Status
Getting the status of the most recent restore is a simple operation. The code in Listing 5 executes the GetLastRestoreStatus method, which is global to the System Restore subsystem, from an instance of the SystemRestore class (similar to the execution of the Enable and CreateRestorePoint methods). The method returns a value of 0, 1, or 2. A value of 0 means that the most recent restore operation was a failure, a value of 1 means that the restore was successful, and a value of 2 means that the restore was interrupted.
Restoring a System Checkpoint
Listing 6 shows the code to restore a system checkpoint. This operation is no more complicated than retrieving restore status. The Restore method must be executed from an instance of the SystemRestore class, and the only required input parameter is the restore- point sequence number, which you can determine by executing WMISystemRestore.wsf in conjunction with the /Action:List command-line parameter.
Updating Parameters
The code in Listing 7 lets you manage the properties that control the frequency of scheduled restore-point creations and the amount of disk space that System Restore consumes on each disk. To do this, the code at callout A in Listing 7 must retrieve an instance of the SystemRestoreConfig class. Only one instance of this class—the SR instance—exists. In the code at callout B, that instance exposes the disk percentage stored in the DiskPercent property and the three frequency properties stored in the RPGlobalInterval, RPLifeInterval, and RPSessionInterval properties. As I mentioned earlier, the script accepts the scheduling parameters in hours. Because the SystemRestoreConfig class exposes the corresponding properties in seconds, the script multiplies the values by 3600 during the property assignment. Because you can update one or several properties from the command line, the script tests which property has an assigned value. If the value differs from -1 (which is the default value when no new value assignment has been made from the command line), the script must update the property. The code at callout C saves the updated property or properties back to the CIM repository by invoking the Put_ method of the SWbemObject that represents the SystemRestoreConfig class instance.
Relax and Restore
Although many installation programs automatically create restore points before proceeding with an installation, the need to manually create a restore point does arise from time to time, such as when you must perform scripted system changes simultaneously on many XP Pro systems. In such situations, customized scripts can speed up and ease the process, but performing large-scale changes without first making a copy of each computer's system settings can be risky. To minimize the risk, you can script the creation of restore points as the first action of your custom script. Doing so guarantees a recovery path for your XP Pro systems in case you experience problems and is a great way to keep managed systems operational.