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 0.0.0.0 – 255.255.255.255. 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
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 0.0.0.0 – 255.255.255.255 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
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 https://miketerrill.net/