Optimizing Operating Systems Upgrades for Remotely Connected Clients

This post has been republished via RSS; it originally appeared at: Device Management in Microsoft articles.

First published on TECHNET on Aug 28, 2017
Hi everyone. My name is Kacey Krehbiel. I'm a service engineer responsible for application and operating system upgrade deployments within Microsoft. Today I'd like to focus on one small aspect of our operating system upgrade process.

Over the past couple of operating system upgrade cycles we have seen a huge increase in the numbers of users that are upgrading their operating system while being connected over VPN. An edge case that in the past would be dismissed with an answer of, "Wait until you're in the office," or "Sorry, the system wasn't built for that," is not acceptable. Users may never go into the office. With that in mind, when designing an OS upgrade using a Configuration Manager task sequence we need to make sure that we are making special consideration for remote clients.

Choosing between Windows 10 Servicing and Operating System Upgrade Task Sequences

A note on Windows 10 Servicing: Windows 10 Servicing is a great solution for installing Windows 10 feature updates for many environments that simplifies many of the challenges of a large-scale feature update deployment. Due to unique internal deployment timelines, as well as some customization specific to our environment, we have opted to use the Operating System Upgrade Task Sequence feature present in Configuration Manager. We encourage everyone to research the capabilities of Windows 10 Servicing, and determine if it is appropriate for your environment.


The first hurdle we need to overcome with remotely connected clients is ensuring that the download of the upgrade package is successful. If we get one chance at time of enforcement to download a 4GB operating system package, we are going to have some failures if users are getting that one chance while seated at a coffee shop. Pre-download helps to reduce that issue by increasing the number of times we attempt download before mandatory enforcement.

Every one of our required operating system upgrade deployments is available to users for at least 7 days before the mandatory date. This allows for remote users (and in-office users) plenty of warning before the mandatory enforcement.  It allows some remote users to be pro-active and initiate the upgrade when they are in the office that one day of the week, but most germane to our current topic, it allows for 7 days of attempted pre-downloads.

Pre-download is still a pre-release feature, so if you choose to use it, it will first need to be enabled. You can find it under Updates and Servicing -> Features -> "Pre-release - Task Sequence content pre-caching." Once you have the feature enabled, setting up pre-download is a simple process.  In the Upgrade Operating System Package properties, the Data Source tab will have radial buttons for x86 or x64 architectures. Pre-1706 you will need to put in the language code of the package, in 1706 simply select the language you wish from the drop-down menu.

If you have multiple upgrade packages in your task sequence you will still need to put in logic to specify which package you want to use.

When creating the task sequence deployment, to enable pre-download, select the "Pre-download content for this task sequence" box.

Task Sequence Design

Pre-download of the operating system upgrade package solves the largest outright failure scenario for a remotely connected client but we want to make sure that we are optimizing the task sequence itself to reduce other download failures, as well as reduce any delays that loss of connectivity may create.

To reduce any other download failures, we're minimizing the number of other packages we're sending during operating system upgrade. If application or driver updates need to be installed before operating system upgrade occurs, consider sending those separately before the upgrade. If you have your task sequence set to "Download content locally when needed by the running task sequence" keep in mind that after operating system upgrade completes VPN connectivity may no longer exist. In such cases you will want to ensure that any packages are downloaded locally before the upgrade step occurs.

This loss of VPN connectivity after upgrade is important to keep in mind in the actual order of your task sequence steps. The task sequence is going to want to send status updates for every step it completes, even if it is a step that it evaluates as skipped.

In our task sequence we have 32-bit and 64-bit packages of 5 different languages. If a client doesn't have MP connectivity it is still going to attempt to send status updates for each upgrade step it skips, adding a substantial amount of time into the process. Because of this, we put the upgrade steps in reverse order of popularity. The processor architecture/language combination with the fewest devices in our environment goes first, followed by the second fewest, all the way to the most common (in our case English 64-bit.) Organizing it this way allows the most people to have the least amount of delays while keeping a single task sequence.

Keeping those status delays in mind, we minimize the number of post-upgrade steps. We also make sure that the post-upgrade steps are not essential to a successful upgrade and a functioning device. Reporting of task sequence execution can be unreliable after MP connectivity is lost (an issue we are working the development team on,) and we don't want unreliable reporting of any essential action.


Perhaps the most essential addition we've added within our task sequence is one that doesn't perform a purpose in the upgrade, but assists in reporting and troubleshooting. Right before the upgrade step occurs we run a script to detect if the client is connected via VPN. This allows us to quickly determine if the attempt was made over VPN without checking any log or contacting the user. We're able to categorize top errors based on connectivity type, track the overall success of upgrade over VPN, and see the percentage of upgrades that are being attempted over VPN.

The Remote Connectivity Check can be a simple PowerShell script to look for whatever remote connectivity solutions exist in an environment:

$ErrorActionPreference = "SilentlyContinue"
if((Get-NetConnectionProfile -Name [domain.com]).InterfaceAlias -in ("[VPN Name]","[Second VPN Name]")){exit 2}
if((Get-DAConnectionStatus).status -eq 'ConnectedLocally' -or (Get-DAConnectionStatus).status -eq 'ConnectedRemotely')
{exit 3}
{exit 0}

In our case we check for both our main VPN profiles, as well as the older Direct Access connectivity.

We then make sure to set that step to "Continue on Error"

We can now use the v_TaskExecutionStatus table in the database to gather data on the connectivity of all upgrade attempts. Combining that connection information with the other details of the task sequence execution we are able to track both the number of users upgrading remotely.  We can also track the errors that are occurring on these attempts to improve the process for the next set of upgrades through a PowerBI Dashboard.

8/31 - Added clarity regarding enabling the Pre-download feature as it is still in pre-release.

Disclaimer : This task sequence configuration may not be explicitly supported and this blog post is for informational purposes. This post is provided “AS IS” with no warranties and confers no rights.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.