Upgrade Windows 10 over the Internet with In-Place Upgrade Task Sequences and ConfigMgr


This is not exactly an A-Z guide on the topic, but rather a story of my experiences with upgrading Windows 10 over the Internet with In-Place Upgrade (IPU) Task Sequence using ConfigMgr and how it works in my environment.

I’m using a Cloud Management Gateway (CMG) with enhanced HTTP as well as initially being connected to the on-premises infrastructure with Always On VPN. The VPN in this scenario is a user-initiated tunnel and thus obviously disconnects once the upgrade restarts the computer. It’s not completely without challenges and I will try to cover those during this post.

Curious? Read on 🙂

Oh yeah, seeing I now allow IPU to happen over the Internet, I also created something in Powershell App Deployment Toolkit which extraordinarily warns the user if the upgrade is being initiated from outside the office network. A preview of that in the end of the post 🙂

Pre-Cache Content

If precaching content wasn’t considered mandatory already, making in-place upgrades available over the Internet surely does so.

In my opinion there’s absolutely no reason to make IPU available over the Internet, if content isn’t precached already, other than providing the end user with a horrible experience. We don’t want to do that 🙂

I have previously gone into details on the precaching part here: https://www.imab.dk/windows-as-a-service-sharing-my-precache-and-in-place-upgrade-task-sequences-part-1/

As I said, precaching is MANDATORY. When making IPU available through the Cloud Management Gateway, the task sequence is REQUIRED to be deployed with ‘Download all content locally before starting task sequence’. If content isn’t on the client already, you do the math. The complete download can take hours depending on Internet speed etc.


Time is precious. During my testing I realized how much time I spent watching a countdown to complete. The Windows setup still initiates a few reboots and each is being count down from 15-20 seconds.

Prevent that and any delays from any reboot during the task sequence by setting SMSTSRebootDelay to 0 (zero).


This might cause some wondering for some, but remember that in my scenario I initially have a user-centric Always On VPN tunnel active, which is being disconnected during the first reboot. From there the SCCM client switches to Currently Internet and connects to the Cloud Management Gateway and I’ve seen some waiting here and there for status messages to be sent back to the CMG. 

This is also to cater for poor private wifi connections. I want the highest chance of success, regardless of Internet connection.

Important: For now I set it twice. Once before the Upgrade OS step and once after. The first because this is where my VPN disconnects and the SCCM client doesn’t switch to the CMG instantly. The second due to the nature of the step, where the variable will be ignored after a reboot in case a status message is sent successfully. Read more here: https://docs.microsoft.com/en-us/sccm/osd/understand/task-sequence-variables#SMSTSDisableStatusRetry

Now, the second time is being set conditionally if the current Management Point is the Cloud Management Gateway. This is done to only skip status messages if the client indeed is being upgraded from the Internet and possibly will be done so from a crappy connection.

Additional Steps

This is more of a inspirational section, and will vary a lot depending on what your task sequence looks like.

During my usual IPU task sequence, I do stuff which is only possible if the client is inside local LAN/or have an active VPN tunnel. For one I manage groups in the local Active Directory through a web service. That is not possible for a Internet client through the Cloud Management Gateway without exposing the web service to the Internet, so that’s something to consider as well.

I have solved that by running steps conditionally and only manage AD groups if the current Management Point is my local Management Point.

And another step conditionally to only run if the CMG is acting as Management Point and the client thus is being considered on the Internet.


The task sequence is being deployed with the option ‘Allow task sequence to run for client on the Internet‘, allowing the TS to actually run regardless of my VPN connection being active or not.

More details

You can get the Management Point details from WMI running following Powershell:


While working through all of this, there are a bunch of useful logs to investigate:


Powershell App Deployment Toolkit preview

I use PSADT with an application to initiate the In-Place Upgrade task sequence. Though my content have changed slightly since then, you can find more on that here: https://www.imab.dk/how-can-i-in-place-upgrade-to-windows-10-1803-using-powershell-app-deployment-toolkit-and-sccm-system-center-configuration-manager-part-2/ 

  • The initial welcome message.

  • If installation is initiated outside of office network, below message is shown, allowing the user to continue or wait.

  • If the installation is initiated from a cellular/LTE connection, I currently prevent that with below message.

Hit me up if you need something elaborated – enjoy 🙂

9 thoughts on “Upgrade Windows 10 over the Internet with In-Place Upgrade Task Sequences and ConfigMgr”

  1. hi Martin,
    can you please share a short guide on how did you create the function Get-NetConnectionProfile and how did you use it in PSADT?
    i am not an expert in powershell 🙂 but i am using PSADT for my deployments and this is very useful to use it with windows 10 feature upgrades.

    thank you

  2. Thank you very much for the article. Is it possible for you to share your task sequence? We are about to push out the in-place upgrade where most users will be on VPN because of COVID-19. Our Windows 10 1709 will be out of support in April. Also, is your CMG configured with HTTPS?

  3. Hi Martin,
    I’m so happy I’m not the only one struggling with this scenario. I have AOVPN and have been testing IPU with CMG. My biggest struggle has been reporting. I’m confident that IPU works properly with the pre-cache and that the upgrade will complete correctly but how do I prove it? I’ve been messing with setting a custom regkey that I extended hardware inventory to capture but have mixed results with that. I’ve got over 5000 endpoints, all off site, that I need to upgrade and a good report will make everyone feel better. Any sort of guidance would be greatly appreciated!


Leave a Reply to Tom Cancel reply

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