Extend the Automatic Deletion of Windows 10 Feature Update Backups

  • Article

By Alex Popham, Modern Desktop Technical Solutions Professional at Microsoft

As you will all be aware, Windows has moved to an “As-A-Service” model. Every six months (March & September) a new “feature” update will be pushed through the usual update channels. Each feature update release will be supported for 18 months, so organisations can plan effectively around these very predictable timescales. On top of that, those who are signed up to the Windows Insider program will get early access to the upcoming feature release, allowing them to test their business-critical applications before a feature update is commercially available. More information on Windows-as-a-service can be found here.

One of the first concerns people have when evaluating this new update model is the frequency of the feature updates and how it will strain the organisation’s test and patching cycle. The advice I would give to organisations is as below:

  • We provide early releases of feature updates through the Windows Insider program for Business.
  • Create new patching processes using deployment rings to pilot new feature updates within your organisation before broad deployment.
  • Utilise our free Upgrade Readiness platform within Azure to provide deep analytics into application and driver compatibility within your organisation for each feature update release.
  • We also expect very strong compatibility of Win32 applications between each feature release.
  • If a feature release does cause unexpected behaviour on a device, the organisation has the chance to rollback to the previous feature release within a certain period and pause feature updates to subsequent Windows 10 clients.

It’s the last bullet point that I want to address in this blog post. By default, Windows will automatically remove the backup of the previous installation after 10 days, which tends to be adequate for most organisations. However, given the extent of their estate, one of my customers felt that 10 days was not long enough to test all applications and drivers, and that 30 days would be more adequate. Once a backup is removed (Windows.old folder) a rollback is not possible under any circumstances and a re-build of the device to the previous version will be required.

There is currently no supported or documented method of increasing the rollback deadline from 10 days, so I set to work investigating the possibility of increasing the default time period of when the backup is removed.

First step, identify what is triggering the deletion of the previous version backup. This took me to the Task Scheduler console. When a feature update is being installed, a new task (SetupCleanupTask) is created in this location: “\Microsoft\Windows\Setup\”. It is configured to execute every 5 days, but within the “action” of the scheduled task is a check to make sure 10 days have passed since the update. This can be seen from this screenshot below:

So, I needed to find a way to prevent this scheduled task from running before the suggested period of 30 days. This can be achieved by editing the existing trigger from:

  • one-time, start immediately, every 5 days, indefinitely

to

  • one-time, start 30 days from now, every 1 days.

This can be achieved through manual configuration of the Task Scheduler UI, which would be fine for smaller organisations but for larger customers like the one in this scenario, we will need to automate and deploy centrally.

This leads on to my second step, which is to script this change with a view to deploy from a management tool, in this case System Center Configuration Manager. Within PowerShell on Windows 10 there are many cmdlets that allows us to control scheduled tasks, as detailed here.

Using that information, it is possible to construct a PowerShell script that will update the “SetupCleanupTask” scheduled task and extend it to run in 30 days time.

The script can be packaged up and delivered via System Center Configuration Manager straight after the feature update has completed or later if preferred. This can be achieved very easily now using the new PowerShell script deployment capability in the latest System Center Configuration Manager update (1706). More details on that can be found here.