none
EP updates pushed out to clients through SCCM 2012

    Question

  • I've been looking in this forum for an answer so forgive me if I missed it but I'm trying to setup SCCM 2012 to push out Endpoint Protection updates. I have my site server setup with all the roles it needs, I have WSUS installed, and I've followed a step-by-step on how to make this all work. Everything looks good on the server, the updates download and they are marked "yes" for Deploy. This was all setup with an "Automatic Deployment Rule" that created the right package successfully etc. And when I right-click on a workstation under the Collection this rule is tied to and go to Properties and then look on the Deployment tab I see the most recent FEP updates listed so all should be fine. But, the client never gets any updates (I've gone two days on and off now waiting to see if something changes).  I have my Antimalware Policy setup to just use Config Manager as the source for definitions. When I do that and try run an update manually from the client it instead fails going to www.microsoft.com for updates (these clients don't have internet access that way). If I change the source listing for the Policy ton include the WSUS from Group policy (which is the same server as SCCM 2012) then the manual update will run but not find any updates (they aren't setup in WSUS but in SCCM 2012). So, is there anything I am missing? Do I need to be more patient? Any ideas would be helpful to see how I can get these updates pushed out to the clients successfully so I can look to rolling this out to replace another Anti Malware product (I don't want to have to use WSUS for the updates and set it to auto-accept if I can avoid it).

    Steve
    Thursday, May 31, 2012 8:40 PM

Answers

  • ok, I think I may have found the issue (not all clients have picked up the updates so it isn't definite). It looks like there was a conflict on how the WSUS server was defined in Group Policy versus what SCCM had (GP just had the server name and port and SCCM had the FQDN and port). Once I removed the GP setting all together and updated the policy etc then it seemed like things started to happen. What led me to this was finally fishing in the logs on the client (c:\windows\CCM\logs) and looking for errors. In the UpdateDeployment.log I was seeing these errors:

    Job error (0x87d00692) received for assignment ({76d342f7-e312-4c6d-9c60-29be10cc5212}) action

    and when I did some digging on the error code it lead me to a conflict on the WSUS server. Then in another log file (I can't remember which one) I found errors where WUA was being set to the FQDN for the WSUS server but then being changed\overwritten by Group Policy with the plain name and giving an error.

    Anyway, I think this was the trick. I will give it a day and make sure all is well and then reply here.

    Steve

    • Proposed as answer by Rick TanModerator Monday, June 04, 2012 2:31 AM
    • Marked as answer by scarr4 Monday, June 04, 2012 4:55 PM
    Thursday, May 31, 2012 11:53 PM

All replies

  • Make sure that the "Check for definition updates using the following interval" setting in your policy is set for a longer interval than the the schedule of your automatic deployment rule. For example, if the SCEP client is set to check for updates every 4 hours, but you have the definition package set to update once a day, the client will get the updates from the Internet (microsoft.com) and the ones in SCCM will never be new enough to be installed. Here's how I have mine set up:

    The SUP is scheduled to sync with WSUS every day at 5 AM and 5 PM

    The auto deployment rule is set to update the definition package at 6 AM and 6 PM

    The EP client is set to check for updates once every 24 hours

    This gives SCCM ample time to deliver the updates before the EP client goes to check for them.

    Edit: I reread the part where you said the updates are failing from the Internet...so perhaps this advice will not work afterall.
    Thursday, May 31, 2012 9:01 PM
  • thanks for the response

    I had the SUP and the deployment rule set similarly to what you have but I had the EP client set to check every two hours. I switched that to 24 hours to see if that helps. this helps me understand why it is trying to contact www.microsoft.com (when I don't have the WSUS set as a source) but it doesn't explain why the client never gets pushed the updates anyway. I would assume the updates would get pushed out after a day or two (since it has been that long for one of the clients) since they are set to be deployed.

    Steve

    Thursday, May 31, 2012 10:03 PM
  • I just remembered that this blog post was created fairly recently. Maybe it will be relevant to your issue:

    antimalware definition updates are not deployed as expected via an Automatic Deployment Rule in System Center 2012 Configuration Manager

    Thursday, May 31, 2012 10:12 PM
  • Yeah, those are definitely check (the Endpoint products) and I see them in the deployment tab of the workstations of the collection so they are there and synced on the server. It just seems like the clients aren't getting them pushed out for some reason. Thanks for sending suggestions though as I'm probably missing something like that.

    Steve

    Thursday, May 31, 2012 10:19 PM
  • ok, I think I may have found the issue (not all clients have picked up the updates so it isn't definite). It looks like there was a conflict on how the WSUS server was defined in Group Policy versus what SCCM had (GP just had the server name and port and SCCM had the FQDN and port). Once I removed the GP setting all together and updated the policy etc then it seemed like things started to happen. What led me to this was finally fishing in the logs on the client (c:\windows\CCM\logs) and looking for errors. In the UpdateDeployment.log I was seeing these errors:

    Job error (0x87d00692) received for assignment ({76d342f7-e312-4c6d-9c60-29be10cc5212}) action

    and when I did some digging on the error code it lead me to a conflict on the WSUS server. Then in another log file (I can't remember which one) I found errors where WUA was being set to the FQDN for the WSUS server but then being changed\overwritten by Group Policy with the plain name and giving an error.

    Anyway, I think this was the trick. I will give it a day and make sure all is well and then reply here.

    Steve

    • Proposed as answer by Rick TanModerator Monday, June 04, 2012 2:31 AM
    • Marked as answer by scarr4 Monday, June 04, 2012 4:55 PM
    Thursday, May 31, 2012 11:53 PM
  • Finally!  This was my issue exactly. The setup recommends the short name for your GPO but I wasn't seeing deployments reach any of the endpoints.  Changing to the FQDN of the server in the GPO fixed the issue and I'm now seeing percentage completed stats and deployments working. Thank you. 
    Friday, June 22, 2012 7:13 PM
  • Been seeing this exact same problem but the opposite,  error occurs when GPO is set to Plain servername:port rather than servername.domain.locl:port.  Will try FQDN see if that resolves the issue...

    Wednesday, August 08, 2012 11:20 AM