If your SCEP clients fall out of date, the approach you will need to take in your troubleshooting efforts will depend largely on which of the five available update mechanisms you selected during the policy creation process. For this recipe, we will be working on a client that has been enabled by the policy to use the SCCM definition packages, WSUS, Microsoft updates, and the Microsoft Malware Protection Center as definition update sources. Leveraging multiple definition update sources is a common scenario that any organization should consider implementing, as it provides redundancy.
In order to complete this recipe, you'll need to utilize an account that has local administrator privileges on the affected client. This recipe will walk you through the process of examining a client which has not been updated for several days. We will examine the logs for a root cause and then remediate any issues we find.
Follow these steps:
This means the client is able to communicate with the update repository on your network, but the update repository does not have a newer definition than the one the client already has. Resolving this issue permanently will likely require some remediation effort on the server and not the client. For now, we will continue to troubleshoot and find out what update sources this client has been attempting to utilize and determine why the client was not able to get out to Microsoft Updates on the web, if the internal update server was severely out of date. Refer to the following screenshot:
C:ProgramDataMicrosoftMicrosoft
AntimalwareSupport
. (Note that Program
Data
is normally a hidden folder in Windows.) Open the log in Notepad and place your cursor at the very top of the log. Press Ctrl and F keys simultaneoulsy to bring up the Find window. Type in the word, updated
, and click on the Find next button. This should take you immediately to a log entry similar to the one shown in the following screenshot. The words updated via MMPC indicate that this workstation was not able to get an update from any internal resource or to reach Microsoft Updates; it then reached out to the Microsoft Malware Protection Center (MMPC) to get a definition. As MMPC was the last update source in our policy, we can assume that all other update sources have failed. Refer to the following screenshot:Due to the redundancy that Microsoft has built into the SCEP client by allowing SCEP definitions to be pulled from multiple sources, the client is very good at keeping itself up-to-date. As the client does not, by default, report from where it obtained an update (only the version number of its current definition), it is not always immediately apparent that a prescribed definition update source has failed.
By logging into a client and reviewing its MPLog, we can surmise when a client failed over to secondary update methods. If many of your clients are doing so, it's likely that a configuration setting has changed. It is recommended that you review the component status messages for the SUP component and verify the configuration of your Automatic Deployment Rules for SCEP.