How to Get System Restore Status with PowerShell for IT Professionals

Want to learn how to get System Restore status with PowerShell? System Restore is a critical feature in Windows operating systems, providing a safety net for users by allowing them to revert their system to a previous state in case of malfunction or unwanted changes.

For IT professionals and Managed Service Providers (MSPs), monitoring the status of System Restore across multiple devices is essential for maintaining system health and reliability. The provided PowerShell script is a powerful tool designed to check the status of System Restore on a device and optionally record the result in a custom field.

Background

In a landscape where system stability is paramount, System Restore offers a valuable service by enabling quick recovery from system failures. For IT professionals, especially those managing numerous devices, ensuring that System Restore is enabled can prevent significant downtime and data loss.

This script simplifies the process of verifying System Restore status and integrates seamlessly with NinjaOne, a popular IT management solution, to log the status in a custom field if needed.

The Script

#Requires -Version 5.1

<#
.SYNOPSIS
    Checks the status of System Restore on the device.
.DESCRIPTION
    Checks the status of System Restore on the device.
    When a Custom Field is specified the results will be saved to the Custom Field as "Enabled" or "Disabled".

.EXAMPLE
    (No Parameters)
    ## EXAMPLE OUTPUT WITHOUT PARAMS ##
    [Info] System Restore is Disabled

PARAMETER: -CustomFieldName "SystemRestore"
    Saves the results to a custom field.
.EXAMPLE
    -CustomFieldName "SystemRestore"
    ## EXAMPLE OUTPUT WITH CustomFieldName ##
    [Info] Attempting to set Custom Field 'SystemRestore'.
    [Info] Successfully set Custom Field 'SystemRestore'!
    [Info] System Restore is Enabled

.NOTES
    Minimum OS Architecture Supported: Windows 10, Windows Server 2016
    Release Notes: Renamed Script
By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
#>

[CmdletBinding()]
param (
    [Parameter()]
    [String]$CustomFieldName
)

begin {
    function Set-NinjaProperty {
        [CmdletBinding()]
        Param(
            [Parameter(Mandatory = $True)]
            [String]$Name,
            [Parameter()]
            [String]$Type,
            [Parameter(Mandatory = $True, ValueFromPipeline = $True)]
            $Value,
            [Parameter()]
            [String]$DocumentName
        )
    
        $Characters = $Value | Measure-Object -Character | Select-Object -ExpandProperty Characters
        if ($Characters -ge 10000) {
            throw [System.ArgumentOutOfRangeException]::New("Character limit exceeded, value is greater than 10,000 characters.")
        }
        
        # If we're requested to set the field value for a Ninja document we'll specify it here.
        $DocumentationParams = @{}
        if ($DocumentName) { $DocumentationParams["DocumentName"] = $DocumentName }
        
        # This is a list of valid fields that can be set. If no type is given, it will be assumed that the input doesn't need to be changed.
        $ValidFields = "Attachment", "Checkbox", "Date", "Date or Date Time", "Decimal", "Dropdown", "Email", "Integer", "IP Address", "MultiLine", "MultiSelect", "Phone", "Secure", "Text", "Time", "URL", "WYSIWYG"
        if ($Type -and $ValidFields -notcontains $Type) { Write-Warning "$Type is an invalid type! Please check here for valid types. https://ninjarmm.zendesk.com/hc/en-us/articles/16973443979789-Command-Line-Interface-CLI-Supported-Fields-and-Functionality" }
        
        # The field below requires additional information to be set
        $NeedsOptions = "Dropdown"
        if ($DocumentName) {
            if ($NeedsOptions -contains $Type) {
                # We'll redirect the error output to the success stream to make it easier to error out if nothing was found or something else went wrong.
                $NinjaPropertyOptions = Ninja-Property-Docs-Options -AttributeName $Name @DocumentationParams 2>&1
            }
        }
        else {
            if ($NeedsOptions -contains $Type) {
                $NinjaPropertyOptions = Ninja-Property-Options -Name $Name 2>&1
            }
        }
        
        # If an error is received it will have an exception property, the function will exit with that error information.
        if ($NinjaPropertyOptions.Exception) { throw $NinjaPropertyOptions }
        
        # The below types require values not typically given in order to be set. The below code will convert whatever we're given into a format ninjarmm-cli supports.
        switch ($Type) {
            "Checkbox" {
                # While it's highly likely we were given a value like "True" or a boolean datatype it's better to be safe than sorry.
                $NinjaValue = [System.Convert]::ToBoolean($Value)
            }
            "Date or Date Time" {
                # Ninjarmm-cli expects the GUID of the option to be selected. Therefore, the given value will be matched with a GUID.
                $Date = (Get-Date $Value).ToUniversalTime()
                $TimeSpan = New-TimeSpan (Get-Date "1970-01-01 00:00:00") $Date
                $NinjaValue = $TimeSpan.TotalSeconds
            }
            "Dropdown" {
                # Ninjarmm-cli is expecting the guid of the option we're trying to select. So we'll match up the value we were given with a guid.
                $Options = $NinjaPropertyOptions -replace '=', ',' | ConvertFrom-Csv -Header "GUID", "Name"
                $Selection = $Options | Where-Object { $_.Name -eq $Value } | Select-Object -ExpandProperty GUID
        
                if (-not $Selection) {
                    throw [System.ArgumentOutOfRangeException]::New("Value is not present in dropdown")
                }
        
                $NinjaValue = $Selection
            }
            default {
                # All the other types shouldn't require additional work on the input.
                $NinjaValue = $Value
            }
        }
        
        # We'll need to set the field differently depending on if its a field in a Ninja Document or not.
        if ($DocumentName) {
            $CustomField = Ninja-Property-Docs-Set -AttributeName $Name -AttributeValue $NinjaValue @DocumentationParams 2>&1
        }
        else {
            $CustomField = Ninja-Property-Set -Name $Name -Value $NinjaValue 2>&1
        }
        
        if ($CustomField.Exception) {
            throw $CustomField
        }
    }
    if ($env:customFieldName -and $env:customFieldName -ne "null") {
        $CustomFieldName = $env:customFieldName
    }
}
process {
    # If the registry value is 1, System Restore is enabled.
    $RegValue = Get-ItemPropertyValue -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore\" -Name "RPSessionInterval" -ErrorAction SilentlyContinue

    $SystemRestoreStatus = if ($RegValue -ge 1) {
        # If either of the above conditions are met, System Restore is enabled.
        Write-Output "Enabled"
    }
    else {
        Write-Output "Disabled"
    }

    # If a Custom Field Name is provided, set the Custom Field with the System Restore Status.
    if ($CustomFieldName) {
        try {
            Write-Host "[Info] Attempting to set Custom Field '$CustomFieldName'."
            Set-NinjaProperty -Name $CustomFieldName -Value $SystemRestoreStatus
            Write-Host "[Info] Successfully set Custom Field '$CustomFieldName'!"
        }
        catch {
            Write-Host "[Error] Failed to set Custom Field '$CustomFieldName'."
        }
    }
    Write-Host "[Info] System Restore is $SystemRestoreStatus"
}
end {
    
    
    
}

 

Detailed Breakdown

Let’s dive into how this PowerShell script works.

Script Initialization

The script begins with some metadata in the form of comments, detailing its purpose, usage examples, and supported operating systems. It supports Windows 10 and Windows Server 2016, indicating it’s designed for modern environments.

This line specifies that the script requires PowerShell version 5.1 or higher.

Parameters

The script defines a single optional parameter, CustomFieldName, which allows users to specify a custom field name where the status will be saved.

Helper Function: Set-NinjaProperty

The script includes a helper function, Set-NinjaProperty, which is responsible for setting the custom field value in NinjaOne. This function handles various data types and validates inputs against predefined criteria.

Main Logic

The script then checks the registry to determine if System Restore is enabled. It reads the RPSessionInterval value from the registry key HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore. If the value is greater than or equal to 1, System Restore is considered enabled.

If a custom field name is provided, the script attempts to set this field with the System Restore status using the Set-NinjaProperty function.

Potential Use Cases

Imagine an IT professional managing a fleet of Windows devices for a mid-sized enterprise. Ensuring that System Restore is enabled on all devices is crucial for quick recovery from potential issues. The professional can use this script in conjunction with NinjaOne to regularly check and log the status of System Restore across all devices, ensuring they can act swiftly if the feature is disabled on any machine.

Comparisons

There are various methods to check the status of System Restore, such as using the graphical user interface or different command-line utilities. However, this PowerShell script offers a streamlined, automated approach that integrates with NinjaOne, providing a scalable solution for IT professionals managing multiple systems. Unlike manual checks, this script can be scheduled and executed across devices, saving time and reducing human error.

FAQs

Q: Can this script enable System Restore if it is disabled?

A: No, the script is designed to check the status of System Restore and log it. Enabling System Restore would require additional commands.

Q: Is the script compatible with older versions of Windows?

A: The script is designed for Windows 10 and Windows Server 2016. Compatibility with older versions is not guaranteed.

Q: What happens if the custom field name is not provided?

A: If no custom field name is provided, the script will simply output the status of System Restore without attempting to log it.

Implications

Knowing the status of System Restore across all managed devices helps IT professionals ensure that systems are recoverable in case of failures. This proactive approach can significantly enhance system reliability and reduce the impact of potential issues.

Recommendations

When using this script, ensure that it is executed regularly to keep track of the System Restore status. Integrate it into a broader system monitoring and management strategy to maintain system health. Always test the script in a controlled environment before deploying it across multiple devices to avoid unexpected issues.

Final Thoughts

NinjaOne offers robust tools for IT management, and scripts like this enhance its capabilities by providing automated, scalable solutions for routine checks. Ensuring that System Restore is enabled across devices is just one of many tasks that can be streamlined with NinjaOne, helping IT professionals maintain system integrity, reliability, and efficiently.