simmsman

You can either create two different deployments for the same update groups. * One deployment as described above for your identified machines that leverage VPN * One deployment for internal machines (of which you would have to download the software updates to the DP and deploy as you would normally). OR * You could do "deploy directly from Microsoft" for all machines but then all your machines will go out to MS for the patch - so if your concern is network bandwidth utilization on your WAN that will also see an uptick DO (Delivery Optimization) and Branche Cache will also help if you use it.

if you do any co-mgmt. with intune your best bet is to use Windows Update for Business (WUfB). It has come a LONG ways and it is pretty much ... hate to say it ... set it and forget.

then set up a different deployment for your vpn users. If you dont check the "do not install updates" it WILL go to you DP's.

Then just tell the clients not to download from any of the DP's. Leave the box checked to go to MS. Im assuming then you have M/S split tunneled in your VPN environment, otherwise they will go through your concentrators to get the updates "directly from MS. Which will be twice the load on your network. Remember, unlike apps and packages, updates will immediately start downloading and wait to deploy. (apps & packages wont download until the deadline or user starts it). At least that is the way it was. Even if you didnt make the update available right away)

As long as the devices can get checked by SCCM and scanned you should be able to set your deployment within your Software Group "download settings" to also download direct from Microsoft Updates. This way, if they dont hit your SUP, they know to go direct to MS.

Using PSDK (Powershell deployment toolkit) we added a step to create a scheduled task, after the reboot, the scheduled task is then removed. The actual deployment will copy the package down to the machine. (If there was already a folder named it will rename the folder to "old".) will create a scheduled task to run at next log on will remove the task afterwards

We've done a scheduled task deployment to run at Log on to update VPN clients on endpoints (our company will not use the auto update mechanism for anyconnect). We deploy the updated client and have it install on next log on).