Use PowerShell to Back Up System State Prior to Making Changes

Did you know you can use PowerShell to back up the system state?

Understanding the Computer Restore cmdlets

One of the easiest ways to ensure system reliability is to create a restore point prior to making potentially damaging changes. In this way, if a problem arises, it is rather simple to roll back the changes. In Windows PowerShell, the easy way to create a restore point is to use the Windows PowerShell cmdlets. These cmdlets require administrator rights (due to access to protected registry keys and other vital configuration files). Therefore, you need to right-click the Windows PowerShell icon and select Run As Administrator from the Action menu. Keep in mind that these cmdlets only work on client systems later than Windows XP. These cmdlets do not work on server versions of the operating system.

There are several cmdlets that you can use to work with system restore. These cmdlets and their associated descriptions are listed here.

Note   The following command retrieved the information in the previous table:

"*restore*","checkpoint*" | % {get-help $_ }| select name, synopsis | ft -AutoSize –Wrap

The good thing is that the *restore* cmdlets use a standard WMI class: the SystemRestore WMI class. This class has documentation on MSDN, so MSDN is a great place to find additional information about the Windows PowerShell cmdlets.

Use CheckPoint-Computer to create a restore point

To create a new restore point, you use the CheckPoint-Computer cmdlet. If the name of this cmdlet bothers you, you can create an alias to New-ComputerRestorePoint by using the New-Alias cmdlet as shown here.

new-alias -Name New-ComputerRestorePoint -Value Checkpoint-Computer

When creating a new restore point via the CheckPoint-Computer cmdlet, you can specify one of five values for the RestorePointType parameter. The values are shown here.

The default value for the RestorePointType parameter is APPLICATION_INSTALL. Therefore, leaving the RestorePointType parameter out of the command causes the cmdlet to create this type of restore point.

Because you are getting ready to modify the registry, you can use the default RestorePointType value. This command is shown here.

Checkpoint-Computer -Description "prior to adding registry key"

You can use the Get-ComputerRestorePoint cmdlet to obtain a list of the most recent computer restore points. This command is shown here.

PS C:\> Get-ComputerRestorePoint

Warning   Column "RestorePointType" does not fit into the display and it was removed.

CreationTime           Description                    SequenceNumber    EventType

————           ———–                    ————–    ———

4/17/2012 4:51:37 PM   Windows Update                 38                BEGIN_SYS…

4/19/2012 3:53:55 PM   Windows Update                 39                BEGIN_SYS…

4/19/2012 3:57:07 PM   Windows Live Essentials        40                BEGIN_SYS…

4/19/2012 3:57:19 PM   Installed DirectX              41                BEGIN_SYS…

4/19/2012 3:57:24 PM   Installed DirectX              42                BEGIN_SYS…

4/19/2012 3:57:48 PM   WLSetup                        43                BEGIN_SYS…

4/24/2012 9:11:12 AM   Windows Update                 44                BEGIN_SYS…

4/25/2012 1:48:52 PM   Windows Update                 45                BEGIN_SYS…

4/29/2012 9:43:11 AM   Windows Update                 46                BEGIN_SYS…

4/30/2012 11:27:01 AM  Installed Microsoft  File T… 47                BEGIN_SYS…

5/2/2012 10:51:17 AM   Installed Intel(R) PROSet/W… 48                BEGIN_SYS…

5/2/2012 10:04:24 PM   Windows Update                 50                BEGIN_SYS…

5/4/2012 10:22:41 AM   Windows Update                 51                BEGIN_SYS…

5/7/2012 12:01:48 PM   Windows Update                 52                BEGIN_SYS…

5/7/2012 2:02:12 PM    prior to adding registry key   53                BEGIN_SYS…

Verifying the status of the last restore point

Unfortunately, this command provides no information about the success of the last attempt to create a restore point for the computer. Selecting the most recent checkpoint and sending the output to the Format-List cmdlet with the Force parameter, displays additional information, but it does not provide any information about the success or failure of the checkpoint. This command and associated output are shown here.

PS C:\> Get-ComputerRestorePoint -RestorePoint 53 | fl * -Force

__GENUS          : 2

__CLASS          : SystemRestore

__SUPERCLASS     :

__DYNASTY        : SystemRestore

__RELPATH        : SystemRestore.SequenceNumber=53

__PROPERTY_COUNT : 5

__DERIVATION     : {}

__SERVER         : EDLT

__NAMESPACE      : root\default

__PATH           : \\EDLT\root\default:SystemRestore.SequenceNumber=53

CreationTime     : 20120507180212.613222-000

Description      : prior to adding registry key

EventType        : 100

RestorePointType : 0

SequenceNumber   : 53

Scope            : System.Management.ManagementScope

Path             : \\EDLT\root\default:SystemRestore.SequenceNumber=53

Options          : System.Management.ObjectGetOptions

ClassPath        : \\EDLT\root\default:SystemRestore

Properties       : {CreationTime, Description, EventType, RestorePointType…}

SystemProperties : {__GENUS, __CLASS, __SUPERCLASS, __DYNASTY…}

Qualifiers       : {dynamic}

Site             :

Container        :

The Get-ComputerRestorePoint cmdlet does have a LastStatus switched parameter, which according to Help, “Gets the status of the most recent system restore operation.” Unfortunately, the parameter provides only cryptic information such as shown here.

PS C:\> Get-ComputerRestorePoint -LastStatus | fl *

The last attempt to restore the computer failed.

Without any dates, operation IDs or other detailed information, the LastStatus parameter cannot be relied on to make a decision in relation to the success or failure of the computer’s system restore point.

See the Event Log for restore point status

The best place to determine the success (or failure) of the attempt to create a restore point for the computer is the Application Event Log. The pertinent event (event ID 8194) is shown here.

Because you already have Windows PowerShell open, it is much faster to use the Get-EventLog cmdlet to obtain this information than to open the Event Viewer utility, navigate to the Windows Logs, select the Application log, and find the 8194 events in the log viewer. The command to find the latest 8194 event from the application log is shown here.

Get-EventLog -LogName application -InstanceId 8194 -Newest 1 | fl *

The command and the associated output are shown in the image that follows.