none
FEP2010 client not seeing updates on WSUS

    Вопрос

  • Hello!

    We have a typical setup with SCCM and FEP.  We decided that we would use WSUS instead of SCCM for definition updates.  I setup the WSUS role and auto-approved the Forefront updates.  Now when I hit the update button on the client it searches, but doesn't find anything.  When kicking-off the update through the FEP client WindwsUpdate.log file indicats "Updates found = 0".   Instead if seems that the updates are being installed through the automatic updates (via Windows) instead of through the FEP client.  I know the auto-updates should be set to "not configured" (or set to diabled all together), but that isn't in my power to fix.

    My questions is:  Does having the automatic updates enabled and set to auto-install everything interfere with the FEP client's built in method of updating?  Does anyone know why the FEP client wouldn't be able to see the update on the WSUS server but the Windows Update agent can?

    Thanks in advance!

    11 июля 2012 г. 18:39

Ответы

  • Our suspicions align.  We used to have it setup correctly in the past without the auto-updates enabled and it was more elegant being able to watch the client go through the motions of searching, downloading, and installing the updates.  I guess I'll just have to wait for the AD guy to fix the GPO problem before I can confirm our theories.  At least the updates are going out!

    With the GPOs the way they are I cannot patch with ConfigMan because our ConfigMan server is also our WSUS server.  Having the auto updates enabled makes all of the workstations and servers by-pass ConfigMan and get updates directly from WSUS.  It was a painful way to learn that the GPOs had changed from "Disabled" to "Configured: Auto-install every day". 

    I'll post again with my findings after the GPO settings are fixed.

    Thanks for letting me bounce this against your brain Kevin!

    • Помечено в качестве ответа Rick TanModerator 24 июля 2012 г. 1:47
    12 июля 2012 г. 17:28

Все ответы

  • When you click the update button or the FEP client checks for an update according to its internal schedule that you configure in the policy, it updates directly from the internet, not WSUS or SCCM. With WSUS and SCCM, the server is offering the client an update and only installs it if the client version is older. The trick is to set the client update schedule to longer than it would take WSUS to update the client. For example, if WSUS is synching with the update catalog every 12 hours but the FEP client is checking for updates every 4 hours, chances are that it's already going to have the latest update from the Internet before the (now older) update being offered through WSUS can install. In my environment, we update with SCCM but the concept in the same. The update sync happens twice a day at 5 AM and 5PM and the client update schedule is set to 24 hours. This ensures enough time for the update to be delivered from SCCM/WSUS before the client reaches out to get it from the Internet.
    11 июля 2012 г. 21:28
  • Good info.  We have FEP setup to not update from the internet though (as we don't have external access on most of our servers).  Instead we have FEP setup to pull from our WSUS server via policy.  I imported a new FEP def. update into WSUS, let it marinate for a minute, then went and pushed the update button on a FEP client.  The FEP client doesn't get an error or anything it just doesn't recognize that there's a new update.  Then I notice a few minutes later that it gets installed by the Windows Update auto install method.  Our auto-install patch config is setup to only install patches at 4:00AM every day.  So what it seems is that pushing the FEP client's update button is invoking Windows' auto update feature.

    Everything is working as the def. updates are getting installed.  I'm just trying to better understand what the interaction process is between the FEP client and Windows' update process.

    Thank you!

    12 июля 2012 г. 14:06
  • Yeah, I should have clarified that the behavior I described is only true if you have "Updates from Microsoft Update" checked as one of the fallback update locations in your policy. I think the more general issue here is that the Update button is only capable of performing an "unmanaged" update. If you use a utility like SCCM Client Center that has the ability to show you a list of running processes and the command line action that generates them, you'll see that pressing the update button initiates a MpCmdRun.exe instance with the SignatureUpdate and UnmanagedUpdate switches. In an environment where Internet updates are enabled, that means it goes directly there. In your environment, it can't do that so it just returns that no new update is available. Now, I don't have any evidence of this, but what it may be doing in addition to the "unmanaged" update is triggering a Software Updates scan cycle which would pick up the fact that the WSUS server has a new update which would then be installed through WU. This could explain what is happening during the few minutes between pushing the update button and when the update is actually installed.
    12 июля 2012 г. 14:29
  • Our suspicions align.  We used to have it setup correctly in the past without the auto-updates enabled and it was more elegant being able to watch the client go through the motions of searching, downloading, and installing the updates.  I guess I'll just have to wait for the AD guy to fix the GPO problem before I can confirm our theories.  At least the updates are going out!

    With the GPOs the way they are I cannot patch with ConfigMan because our ConfigMan server is also our WSUS server.  Having the auto updates enabled makes all of the workstations and servers by-pass ConfigMan and get updates directly from WSUS.  It was a painful way to learn that the GPOs had changed from "Disabled" to "Configured: Auto-install every day". 

    I'll post again with my findings after the GPO settings are fixed.

    Thanks for letting me bounce this against your brain Kevin!

    • Помечено в качестве ответа Rick TanModerator 24 июля 2012 г. 1:47
    12 июля 2012 г. 17:28