Windows as a Service: Detecting AlwaysOn VPN and LTE connectivity with Powershell and Powershell App Deployment Toolkit

Introduction

This post is long overdue and something I originally considered doing when I explained my Windows as a Service process.

The story is, that I allow In-Place Upgrades with Configuration Manager to happen over the Internet and over VPN. While I do allow upgrades over VPN, I still prefer them happening on local network and I certainly doesn’t want them to happen over LTE.

I use Powershell App Deployment Toolkit to initiate the Windows 10 In-Place Upgrade Task Sequence, and I wanted to add more user-friendliness to the experience, by notifying the end-user about possible VPN and LTE connections.

Note #1: LTE connectivity can be prevented altogether in the Client Settings, but I’m not doing that for various reasons. 🙂

Note #2: I do precache everything prior to making the upgrade available. Therefore download of binaries should be limited to zero, though the connection to the site server is still needed, as well as connection to the domain (depending on what you are doing throughout your task sequence).

Powershell

The magic lies in 2 Powershell functions I created for the purpose.

Note: The functions have only been tested in my own environment, and depending on how you have setup your AlwaysOn VPN profile, you might need to modify the content a bit.

  • Test-DomainVPNConnectivity
  • Test-LTEConnectivity

Each function outputs the current connectivity to the screen as well as an output to be used later in PSADT.

Below is an example of running the Test-DomainVPNConnectivity function manually. My production domain name is obfuscated, but the function recognizes that I’m currently connected through AlwaysOn VPN:

The Test-LTEConnectivity function does the same thing: Outputs the current LTE connectivity to the screen and for later use in PSADT:

Powershell App Deployment Toolkit

So how do I use that with the Powershell App Deployment Toolkit?

For your downloading pleasure, I have made the entire PSADT project used available for download here: PSADT_TestConnectivity.zip (81 downloads)

I have made a custom region paragraph within the Deploy-Application.ps1 file which contains the custom code. I hope most of this is self explanatory, assuming you have some sort of experience with PSADT already:

Results

  • Initially when PSADT is run, the user is greeted with this first welcome message:

  • If PSADT detects that the user currently is connected through a LTE connection, the user is notified and the installation is prevented:

  • If PSADT detects that the user currently is connected through VPN, the user is notified and given the option to wait or continue:

  • If PSADT detects that the user currently is not connected to either VPN or office network, the user is notified and the installation is prevented:
    • This is a scenario that might turn relevant if one are using a Cloud Management Gateway, and the device is not on VPN and not in the Office.

ENJOY 🙂

More information

9 thoughts on “Windows as a Service: Detecting AlwaysOn VPN and LTE connectivity with Powershell and Powershell App Deployment Toolkit”

  1. Hi! Great work! Is this the same way you prevent precaching via LTE or VPN? Do you run precaching task sequence required and run these PoSh-Script before task sequence is executed?

    Dietmar

    Reply
    • Hi and thanks! I don’t allow precaching over VPN nor LTE, and I prevent that through the boundaries and boundary groups 🙂

      Reply
    • It’s not the TS per say you prevent executing, it’s content download which cannot happen when the client falls out of the boundaries configured. When my clients are connected through alwayson vpn, they fall into a specific boundary group with no relationship to a DP and thus the precaching cannot happen 🙂

      Reply
    • The individual deployment options can bypass that, and for instance be allowed to grab content from a neighbor DP or even from the default site boundary group. So by default, clients on VPN is not allowed to download content unless you explicitly allow it on the deployment.

      I sense that you have associated a DP or included your VPN client into a boundary group which has a DP associated? 🙂

      Reply
  2. Ah, now I understand your thoughts. Perfectly fine! This is exactly what we need. We own ~2000 notebook and we currently switch from DirectAccess to AlwaysOn VPN. So this post and your comments come at just the right time. ? There is something to learn every day…

    Fortsæt med det store arbejde!

    Reply

Leave a Reply to DHaimann Cancel reply

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