Hello everyone!
I'm Stefan Röll, Customer Engineer at Microsoft Germany for Microsoft Endpoint Manager. Over the past month, some of my customers had challenges with the distribution of Defender Definition Updates using MECM. With this Blog, I would like to share my learnings from the field.
What is special about Defender Updates?
Defender Updates are getting updated multiple times per day. If you have a lot of Distribution Points (DPs), slow links or other conditions, it will be difficult to keep them updated every few hours.
If you use the build-in mechanism of distributing Definition Updates with MECM, every few hours the package transfer manager and distribution manager thread need to process the changes. Especially in large environments the changed content is not completely processed before the next Definition Update needs to be handled.
Best ways to distribute Defender Updates
The most frustration-free way of distributing Defender Updates is to let Defender update itself using Microsoft Update.
If you configure Microsoft Update in the Definition Update Sources only Defender will update from Microsoft Update. Monthly Cumulative Updates and other Updates are not affected by this setting.
As MECM admin, you only must configure this setting once, test it and you will most likely not hear of outdated Defender Definitions anymore. Additionally, you can increase the scan frequency, as no internal system is utilized for scanning of new updates.
However, I have heard two valid reasons why this is not possible:
We do not want our systems to reach the internet
While most of the time not technically correct (systems only need to reach Microsoft Update), the reason is valid for high secure offline systems and MECM provides a great way to manage these on premises systems.
If all clients download updates from the internet, we will have bandwidth issues
I never had a customer where Defender Updates caused bandwidth issue. Yes, Updates are a few hundred kilobytes per client, but if you open any website on the internet, you have already downloaded more data. Additionally, updates can be distributed over peer-to-peer technology like Delivery Optimization.
The most stable solution for offline clients I have seen in the field is to use your existing Software Update Point (SUP) infrastructure.
The solution requires a little bit of planning and implementation work, but once set up it will run without daily operations overhead.
How does it work?
A SUP is a Windows Server Update Service (WSUS) server that is managed via MECM. Normally we do not support approving updates in the WSUS console directly, but there is one exception and that is for Defender Updates .
Pro:
- MECM does not need to process content changes
- Distribution Manager and Package Transfer Manager are not involved in the process
- Automatic Deployment Rules do not need to run
- Clients don't need to process policy chances to be able to find and install Definition Updates
Con:
- Content will be downloaded from a central place in your infrastructure
- Increases hardware requirements for your SUP (it depends on number of targeted clients)
Recommended SUP design
This is not specific to Defender Updates, but I highly recommend a simple SUP design. This helps to ensure that clients always reach the correct SUP, can scan for Windows Updates and in our case, download and install Defender Updates.
For a single primary site with less than 60k Clients use a single SUP in hierarchy, place it as close as possible to your primary site and ensure that all clients can reach it.
For more than 60k clients (up to the support limit of 150k clients) use two SUPs with a shared DB and shared content location.
In a hierarchy with CAS and multiple primary sites, use one SUP on the CAS and up to two SUPs with shared DB and shared content location for each primary site.
Always place the SUPs as close as possible to your Site Servers.
In this Setup clients might need to go over slow links for scanning against the SUPs, but apart from the first scan you will be unlikely to notice this traffic.
This is not an official Microsoft best practice setup, but a setup I have successfully implemented for multiple customers and sizes (up to 350k Clients).
Of course, this setup is supported if you follow the hardware and scale recommendations.
In Part 2 of the Blog, we will look into the technical details, how to set it up and some tips for a successful implementation.
Stefan Röll
Customer Engineer - Microsoft Germany
About this Blog - Learnings from the field
Please note that this Blog is not an official Microsoft best practice guide. Every environment is different and may need a different setup. It only represents my learnings from different customer environments.
Resources:
Enable Endpoint Protection malware definitions to download from WSUS for ConfigMgr
https://docs.microsoft.com/en-us/mem/configmgr/protect/deploy-use/endpoint-definitions-wsus
Recommended hardware for Configuration Manager
https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/configs/recommended-hardware
Size and scale numbers for Configuration Manager
https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/configs/size-and-scale-numbers
How to implement a shared SUSDB for Configuration Manager Software Update Points
Disclaimer:
This posting is provided "AS IS" with no warranties and confers no rights
