Understanding the Problem
The core of the issue lies in the recovery partition size. Some systems may have a recovery partition too small to accommodate the updates, causing the update process to fail. This is particularly problematic for system administrators managing multiple endpoints, where manual resizing of partitions is impractical.
Automated Solution by Action1
To address this, we at Action1 have developed a set of PowerShell scripts that facilitate the resizing process at scale. These scripts automate the data gathering and partition resizing steps, making it easier to manage multiple systems.
Script 1: Data Gathering
The first script is designed to check if WinRE is enabled, determine if it is the last partition on the target drive, and ascertain its current size. Note: This script will not work if the WinRE partition is not the last partition, as it cannot be resized in that configuration.
This script outputs whether WinRE is enabled, if it can be resized, and the current size of the partition, and can be used as a direct data source in Action1 to view all endpoints in an organization.
Script 2: Resizing the Partition
If you’ve identified systems that have failed to update due to partition size restrictions, then you have partitions that potentially need resizing, the next script will handle this. It shrinks the left adjacent partition and resizes the WinRE partition by 250MB, provided it’s enabled. Note the need for this corrective action will be identified by receiving either of the following error messages while installing the referenced updates.
• Windows Recovery Environment servicing failed. (CBS_E_INSUFFICIENT_DISK_SPAC
• 0x80070643 – ERROR_INSTALL_FAILURE
This script performs the necessary disk operations, ensuring the WinRE partition is appropriately sized.
How to apply these scripts using Action1
1. Log in to the Action1 Platform or sign up for an account, the first 100 endpoints are free with no feature limitations.
2. Add a DataSource and its associate report:
- On the left side scroll down and navigate to “Data Sources” then on the right, choose “+ New”.
- Enter the relevant details, and choose “Next Step”.
- On the next screen, select all text in the text box and delete everything that is there by default, then copy in the text from GitHub exactly as it is in the RAW content, do not modify it in any way. Then choose “Next Step”.
- On the next screen, select an endpoint to test, and choose “Detect”.
This does not have to be a lab computer as this is query only, no changes are being made at this time.
- You should now see that the script has executed and the columns have been detected. Click “Finish” and now we’re good to make a report to use the new data source.
3. Make a report to use the new data source.
- On the left side scroll down and navigate to “Custom Reports” then on the right, choose “+ Add”.
- Fill in the relevant information, and choose “Next Step”
- Choose “Simple Report”, and then “Add Columns”.
- On the popup, choose “Column Name” which will select all columns for the report. Then choose “Next Step”
- Add filter if your needs require one, and then choose “Finish”
- You should now have a report that shows the status of all endpoints
4. Add the script to resize
- On the left scroll down and select “Script Library” then choose “+ New Script”
- Fill in the relevant information then choose “Next Step”
- On the next screen, Ensure it reads PowerShell (Default) as language, then select all text in the text box and delete everything that is there by default, then copy in the text from GitHub exactly as it is in the RAW content, do not modify it in any way. Then choose “Next Step”
- It is recommended on the next screen you run this by a system “IN YOUR TEST ENVIRONMENT”
Be aware this step WILL run on the client and could potentially act in ways not yet understood, ensure whatever system is being tested on has proper backup recovery procedure.
These scripts provide a streamlined approach to a problem that could be cumbersome, especially in large-scale environments. By automating the process of resizing the WinRE partition, system administrators can ensure that their affected systems remain up to date and functional without the need for time-consuming manual interventions. Also, this should assist them with the ability to receive future updates without encountering this specific issue.
Note: These scripts should be used with caution and tested in a controlled environment before widespread deployment, as they involve significant modifications to disk partitions. The administrator should ensure all needed recovery options, such as backups or snapshots, are in place, should something go wrong in this process. Action1 assumes no liability for use of this tool or negative outcomes resulting from its use.