If your company has deployed or is planning to deploy SCEP, you will certainly have to plan to deploy definition updates.
In my observations, the most common solution that administrators use is to create an ADR (see below) and let it run on a schedule:
This will certainly get the updates deployed, but there is more to consider.
Make Updates Available Outside of Configuration Manager
What happens if the CM Software Update Agent fails to install definitions? What happens if the end user forces an update by pressing the update button in the SCEP user interface? In these situations, we’ll need to better understand the setting for definition update sources in the Antimalware Policy. If you’re not familiar with this, navigate to Assets and Compliance, Endpoint Protection, Antimalware Policies. You could have quite a few Antimalware policies, but I’ll be working with the default policy in my screenshots today.
At this point, those who are familiar with these settings may be ready to skip ahead. Please hang with me.
What do these settings actually do?
You’ve got a few options here, so let’s discuss what they actually do.
When the SCEP client definitions become too far out of date, or if the end user clicks Update in the UI, the SCEP client looks for a FallBackOrder registry key in HKLM\Software\Policies\Microsoft\Microsoft Antimalware\Signature Updates . The SCEP client will check each update source in order until it locates a source that has available definitions. If none of the sources have definitions available, the SCEP client will return an error.
Updates distributed from Configuration Manager
Selecting this option sets a registry value called AuGracePeriod in HKLM\Software\Policies\Microsoft\Microsoft Antimalware\Signature Updates . By default, this is set to 4,320 minutes, or 72 hours. You can modify this value in your Antimalware Policy. This value represents (in minutes) the amount of time the SCEP client will ‘sleep’ and wait for CM to bestow signatures upon it. When this period expires, it will attempt to pull definitions from the order defined by policy and stored in the Fallback registry key. Believe it or not, SCEP cannot use CM as an update source location for definitions, which is why this setting does not modify the FallBackOrder registry key.
Updates from UNC file shares
If we select this option, we must also define the UNC paths in the definition updates section of the antimalware policy. This can be seen a few screenshots above. This option modifies both the FallbackOrder key and the DefinitionUpdateFileShareSources key. Multiple UNC paths can be specified, as seen below. This can leverage existing DFS infrastructure if it exists. A few drawbacks of this option are that the UNC file share is not populated automatically and it does not take advantage of binary delta differentials. Also, if out of date definitions are left on the UNC share, it can cause the clients to fail checking any further sources in the fallback list.
Updates distributed from Microsoft Update
This one sounds fairly obvious. It is useful for clients that are off of your network for a while, unless you are set up to manage internet based clients or are using DirectAccess. Of the two Microsoft hosted fallback locations, this is ideal as it results in the smallest payload delivered to the client.
Updates distributed from Microsoft Malware Protection Center
MMPC should always be last in your source list, as the payload from this location will be much larger.
Updates distributed from WSUS
Configuration Manager admins generally stay out of the WSUS console, except to periodically perform a WSUS cleanup or other maintenance. While it’s true that WSUS is mostly controlled by Configuration Manager, it will still function happily as a standalone WSUS instance for the purposes of making SCEP definition updates available. If you have WSUS listed as an update source, you should plan to create an Automatic Approval rule for SCEP definitions. It will look something like this:
Fuente: Microsoft Technet