Introduction

This is currently a very hot topic, all given the sad circumstances regarding the COVID-19 outbreak all over the world. So I figured it would make a relevant and helpful blog post, to share the details on how I have configured boundaries, boundary groups and everything related to deploying software and software updates in the different #WorkingFromHome situations with VPN and the Cloud Management Gateway.

We are using Always On VPN, and the configuration is something I have explained here as well: https://www.imab.dk/my-always-on-vpn-configuration-with-microsoft-intune-and-configuration-manager-explained/

Also, this is not a typical A-Z guide, but rather some insights to, how I have done some of the configurations in order to cater for remote work. Curious? Read on. 🙂

VPN boundary

Lets start off by taking a closer look on my boundaries, and specifically the boundary for my devices on VPN. (The rest are obfuscated because irrelevant and sensitive.)

Above range of IP addresses are exclusively added to the Boundary Group: BG – AlwaysOn VPN.

This translates into any device being online coming from our VPN, which again means they now are within a known location to Configuration Manager.

Taking a look on the References tab, you will see that I don’t reference or associate any site systems directly with this boundary group.

I do this, because I don’t want software deployments, whether it’s regular packages/applications or software updates, to apply to devices being online via VPN by default.

Instead I configure a fallback relationship with my Cloud Management Gateway, enabling devices to potentially get the content via the CMG in Azure.

Note: This configuration will only have effect, if I allow it in the deployment of packages or applications. More on that later.

I’m also allowing the devices to prefer cloud based sources over on-premises sources.

Note: This is something that’s used, when I deploy Software Updates (specifically Office 365 ProPlus updates) to devices on VPN. Also elaborated later.

Software Deployments via VPN

So what happens when I deploy software to devices on VPN? That depends on the configuration of the deployment. Lets take an example of deploying 7-Zip as a package.

When configuring a package for deployment, the Distribution Points tab of the deployment is highly relevant.

The configuration shown below will only run, if the content is found on a distribution point within the current boundary group (BG – Always On VPN). That translates into, if a site system with the Distribution Point role, is referenced directly in the Boundary Group.

Given my setup and configuration explained above, this deployment will not run while on VPN. Lets start off by digging into some of the log files.

execmgr.log

Because this is a regular package, the first place to look will be execmgr.log. When running this while on VPN, the log expectedly returns:

“[KR1208FB Per-system unattended KR10091B] Content is not available on the DP for this program. The program cannot be run now.”

So what do I do, if I really want this to install while on VPN?

First option is to allow the download to happen over VPN. In this scenario, the binaries will be downloaded from your on-premises Distribution Point.

This is achieved by configuring the deployment of the package as shown below:

In above situation, you allow the deployment, not only to reach out to a neighbor boundary group (if a fallback relationship is configured), but you also allow the deployment to use the Default-Site-Boundary-Group.

As per the explanation given about my boundaries and boundary groups above, I don’t allow fallback to another distribution point in another custom boundary group. Instead this is done via the Default-Site-Boundary-Group.

LocationServices.log

When running the deployment now, you will see that the Distribution Point used, is the one referenced in your Default-Site-Boundary-Group. As of such, the locality in LocationServices.log is SITE (this would otherwise have been BOUNDARYGROUP or NEIGHBORBOUNDARYGROUP).

CAS.log

The same details are mentioned in CAS.log once the download is allowed and begins:

Software Deployments via CMG

If you want to ease the load on your VPN, you can enable the installation to come from your Cloud Management Gateway. This makes for the second option, continuing on above scenario.

The first thing I do in this scenario, is to distribute the content to the CMG. I don’t distribute everything to the CMG, so when needed, I have to do this separately like shown in the following 2 illustrations:

What the deployment needs to look like in this scenario – given all my configuration – is similar to below. Here I’m enabling the deployment to grab content from a neighbor boundary group, but not the Default-Site-Boundary-Group.

The deployment will then see, that “BG – Cloud Management Gateway” is a neighbor boundary group, where fallback is allowed on the Distribution Point.

LocationServices.log

And again, taking a peek in LocationServices.log while the deployment is initiated, you will now see that the distribution points offered in the current location, is the CMG in Azure (Locality=’AZURE’).

Software Updates via Microsoft Update

I’m using Windows Update for Business for the regular Windows 10 updates. This is being managed by Intune.

Software Updates for Office 365 ProPlus (soon to be renamed into Microsoft 365 Apps for enterprise), is something I still manage with Configuration Manager. 

To ease the burden on my VPN even further, this is something I want to be serviced from the cloud, but only if and when devices are online via VPN.

This is pretty simple and easily achieved with these 2 configurations:

• Prefer cloud based sources over on-premises sources on the VPN Boundary Group (also shown earlier in this post)

• If software updates are not available on distribution point in current, neighbor or site boundary groups, download content from Microsoft Updates on the deployment of your Software Update Group.

ContentTransferManager.log

Now, with above 2 configurations in place, the content are found both on Distribution Points as well as in Microsoft Update. See the highlights below.

And when the updates are downloading, the Microsoft Update location is preferred due to the setting on our Boundary Group.

ENJOY 🙂

All of this was written while #WorkingFromHome and having the entire family around. Please excuse me if anything is unclear.

As always, don’t hesitate to reach out to me in the comments section down below or on Twitter.