Resolving client-side definition update issues

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.

Getting ready

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.

How to do it...

Follow these steps:

  1. Log in to the workstation you are troubleshooting and open the SCEP client UI from the system tray.
  2. Click on the Update tab, take note of the Definitions created on and Definitions last checked dates. If, like in the following screenshot, the Definitions last checked date is significantly closer to the present date and time than the Definitions created on date, this would indicate a problem with the update sources this client is trying to utilize.

    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:

    How to do it...
  3. Next, we will verify that the client PC has been opted into Microsoft Updates in order to receive definition updates directly from Microsoft. Generally, this should have occurred as a post-image installation task, or through the deployment of a regkey. The fastest way to determine whether opt-in has occurred is to launch Windows Update and look for a message that reads Get Updates for other Microsoft products. Refer to the following screenshot:
    How to do it...
  4. If you do not see this message in the Windows Update UI, then your client has already been opted in; the reason it has not pulled definitions from Microsoft Updates is likely network related. This means Microsoft Updates is most likely blocked at the web proxy level. If you do see the message that the client needs to be opted in, click on the blue link titled Find out more and agree to the EULA. Refer to the following screenshot:
    How to do it...
  5. If you have just opted in the workstation for Microsoft Updates, return to the SCEP client UI and force an update. While this will resolve the issue temporarily, you should continue to troubleshoot in order to determine why your internal update resources failed.
  6. Next, we will review the client's MPLog. To find this log, navigate to 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:
    How to do it...
  7. You can continue to shift through the log by hitting F3 to jump to the next entry that contains the word updated. As we remediated an issue with the Microsoft Updates EULA and forced an update, we should expect to see a change in the latest entry. If the client was able to reach Microsoft Updates for a definition, your latest entry should read Signature updated via MicrosoftUpdateServer. Refer to the following screenshot:
    How to do it...
  8. If every effort has failed so far and you simply need to get the client up-to-date for the immediate future, it is possible to manually download a complete definition file from Microsoft's security portal. Open Internet Explorer and follow the instructions for manual download at this site: http://www.microsoft.com/security/portal/Definitions/HowToForeFront.aspx. Refer to the following screenshot:
    How to do it...

How it works...

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset