Forcing Configuration Manager VPN Clients to get patches from Microsoft Update


By now IT departments are scrambling to get as many users as possible to work from home as a result of the COVID-19 outbreak. What they are finding out is that Microsoft patches chew up a lot of bandwidth when these clients can download the patches directly from Microsoft Update (yet still be managed by Configuration Manager). I have seen a few blog posts on the topic that ultimately end up leading to more questions than they answer. So hopefully I can make this as complete as possible and answer as many of those outstanding questions as possible.

To set the stage, I am not going to be talking about scenarios that involve CMG (I am going to assume that you are already ahead of the game and do not face this challenge). This is more for the customers on the trailing edge that have not (been able to) adopt the cloud strategy and are stuck with distribution points on the corpnet. The goal is to work with your VPN team so that they configure it for split tunneling. I will not go into this part as each VPN configuration is unique, however, I will help provide you with the necessary URLs that are needed to be excluded from coming back through the corpnet. Also be sure to factor in other things like proxy servers or other apps that inspect/filter web traffic as they will need to exclude this traffic as well so it does not come back through corpnet.

Everything starts with boundaries and if you know me, I have never been a fan of boundaries for content location (p2p FTW!). The only boundaries that I configure for content location is when I need to protect a DP in a build center where I do not want other clients outside of the build center leaching off the build center DP. Other than that, who has time to manage boundaries that are constantly changing? Plus, in my environment I could not even tell you how many subnets we have let alone pretend to get it right.

The other goal of this is to keep the operational aspect as simple as possible. Meaning, don’t expect the Software Update person to now configure a bunch of different software update deployments just to allow the VPN clients to get their updates from MU.

This is hopefully going to be a simple example to get you up and running (plus I can’t really show our production environment, so don’t ask). IP Ranges are your friend. Ever since the CM Team optimized the queries for client location requests, big honking IP Ranges are the way to go. Forget IP Subnets and AD Sites (unless you really like to cause yourself pain). So think big, like – However for this example I am going to keep it simple. The following are my three ranges:

Boundary Groups are pretty simple as well:

Corpnet Boundary Group Properties

Uses the Data Center DP:

In this example, every IP range is accounted for so I have not defined a relationship to the Default Site Boundary Group (or any other Boundary Groups). However, your configuration may be different:

And I am not using peer cache (BranchCache FTW!) and we do not want our corpnet devices going out to MU:

VPN Boundary Group Properties:

VPN Boundary Group uses the dedicated VPN DP(s):

Not making any assumptions, I like to explicitly state that the VPN Boundary Group should never fallback to another boundary group’s distribution point (in case an admin screws up a check box on a deployment). And if your MP(s) and SUP(s) are in the Default BG, then you will want the VPN clients to be able to get to them:

Once again I am not using peer cache (BranchCache FTW!). The “Prefer cloud based scenarios over on-premise sources” is an interesting checkbox. Since we have everything pretty much protected, it would not hurt to check it however it isn’t necessary. It could be a good safe guard in the event that someone screws up and distributes Microsoft patches to the VPN DP Group:

Be sure to set up dedicated DP Groups. You will only want to distribute Microsoft patches to the Data Center Distributions Point Group (Corpnet) and not the VPN Distribution Points Group. However, 3rd Party Updates will need to be staged on both DP Groups (and for third party updates check out Patch My PC):

IMPORTANT: When you set up the Software Update Deployment configure it exactly as follows. Since we hopefully have defined all possible IP Ranges (remember I said thing big and carve up – accordingly), every client should have either a DP to get content from without falling back or in the case of VPN clients and Microsoft patches – Microsoft Update:

On the clients, you are going to want to check out two logs. The first one will be the CAS.log:

And the second one will be the ContentTransferManger.log:

And remember, just because it says it is getting it from Microsoft Update does not necessarily mean it is getting directly from MU. It could still be going back through the corpnet because the split tunnel was not set up correctly or a proxy is re-directing traffic. So work closely with these teams. From a CM stand point mission accomplished.

Now for the URLs. There is not a public Microsoft doc/KB (at least that I know of) that says these are exactly the URLs that are required for this feature when defining Client -> MU traffic. However, most of them are similar to what the SUP uses when it downloads the content.

(from Software Updates)

Office 365 Updates will be further down the page:

(from Manage Office 365)

Lastly, Windows 10 Updates have a slightly different URL:

(from Windows 10 servicing)

The download location can be found in the meta data for each patch:

Plus you can run a query in SQL to find it:

select top 1000 SourceUrl
from vSMS_CIContentFiles

Hopefully this helps in getting the Microsoft Update traffic off of your VPN links. If you have any suggestions or other useful tips, please leave them in the comment section below.

Originally posted on

21 thoughts on “Forcing Configuration Manager VPN Clients to get patches from Microsoft Update

  1. Pingback: How to find software update deployments enabled with download content from Microsoft update for clients from VPN CMG internet connected | All about Microsoft Endpoint Manager

  2. Really appreciate this post. I currently use sites as BG’s. Would it be more advantageous to switch those to IP address ranges to complement this procedure? Also would opening up the VPN clients to MU bring all updates including feature updates?

    • As far as the AD Sites vs. IP Ranges, I prefer the IP Ranges because I can be in total control and I can explicitly define the entire range. With AD Sites, that is not something I control nor is it easy to define the entire range. By allowing the VPN to split tunnel, you are just allowing the traffic to go through the individual’s ISP to the Internet vs. going back through the VPN tunnel to the corpnet and then out to the Internet. ConfigMgr will control the policies if this is how you have it configured.

  3. Thanks a lot. We use this method during two years. but today we see that SSU 03.2020 is not downloaded.
    We checked that MS link is not available to access from our SCCM server. Your article saved our time!

  4. Pingback: System Center Mart 2020 Bülten – Sertaç Topal

  5. Anything to add for clients who are on Direct Access? Gotcha’s when it comes to ADRs? Boundaries / Groups? Do’s and Don’t?

  6. nice, but you have overdone it.
    it is much easier to configure:
    \Software Library\Overview\Windows 10 Servicing\Windows Update for Business Policies
    and deploy it to VPN device collection

    • This policy that you mention is for Windows Update for Business. Configuration Manager does not use WUfB and you would need to split your managed clients up (I wouldn’t call this easy, especially for clients that go back and forth between the office and home).

  7. Mike, Thanks for the info, with this setup – does this mean I will have to set up 2 deployments for Windows\Office 365 updates (1 for corp & 1 for VPN)?

    • One other thing I was going to mention, I’m currently using 1E Nomad, v6.3.201 I have set the compatibility flags to allow it to source from MU – will this work with your set-up. Cant remember if BigBank is still using this. thanks for any light you can shed on this.

      • I think they finally fixed this in a later release and also a 6.3 hotfix. I just tested without the compat flags setting and Nomad failed and it fell back to using the default provider (which is able to successfully download from MU).

      • Yes – Nomad 6.3.201 will download from MU using the configuration Mike has very comprehensively set out in this blog. You need hotfix 20267 (released December 2018) or later and enable download from MU in CompatibilityFlags as you have done.

      • If you don’t care if CM downloads it, then you don’t need to worry about the compatflags as Nomad will just fail and then CM will get it.

    • Hi Vern, if everything is defined, meaning that it is either corpnet or vpn, then you can configure the deployment like the screen shot and only have one to cover everything.

  8. Hi Mike, Could you suggest what i should use as a VPN DP? is this an existing DP or would i need to create a new one?

    • It depends on your current hierarchy and how many DPs you already have. If you can easily add another DP (or DPs), then that might be the easiest way to go. Otherwise, if you take an existing DP (or DPs), and you want to follow my ease of operational guidance (by only managing one deployment), then you will want to remove all of the MSFT updated from this DP (or DPs).

      • Thanks Mike!

        i will be taking the approach of using an existing DP and just to clarify, the deployment packages need to be removed from the existing DP which will trigger downloading the updates from microsoft updates?

  9. Hi, we don’t have a separate boundary group for our VPN clients (which is a split tunnel configuration), nor a dedicated distribution point, nor a cloud distribution point, or CMG, as it was originally such a small scope that handled 5 to 10 users a few days a week.
    Now, we have increased that scope to almost 500 (our entire remote workforce, a relatively small organisation), and have 99 percent of our employees working from home with their SCCM management devices.
    My question is, can we just set our ADRs to not create a distribution group, and set the deployment properties to use Microsoft Update, thereby forcing *all* clients (whether corporate or VPN) to go direct to the internet? We use a cloud based web proxy as well, so only corporate traffic comes through the corporate VPN.
    Do you think this was work? If so, I think this would be a simpler approach during the COVID-19 pandemic to have all clients get updates from the Internet.


    • This highly depends on how your VPN is configured (and what it is capable of). If the only traffic that comes back through your VPN is corpnet traffic, then things might just work for you by enabling MU. But double check with your VPN team/vendor and also do some network traces (using something like WireShark). This should give you a better idea on the traffic flow.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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