Share This Post

Auto deploy forefront definition updates from an SCCM distribution point

The following Microsoft website explains how to auto deploy forefront client security definition in a step-by-step guide.

In this step-by-step guide, they essentially go into the WSUS Console to create an Auto-Acceptance rule. First of all this should make any ConfigMgr admin shiver, as it should have been drilled into your head that you are supposed to do software updates management from the ConfigMgr administrator console.

Now, I have never understood why they didn’t solve that in a more elegant manner. The solution works, however has a couple of drawbacks. First of all the original article was written by the FCS product team and hence initially their has been some debate whether this was a supported solution. That has all been sorted out now, and the solution is officially supported.

Additionally in a multi distribution point environment, the actual definition updates will always come from the Software update point, whereas normal software updates come from the distribution points. In other words, this impacts scale quite a bit, and forefront definitions come out at a very frequent pace meaning they are hitting you software update point harder than anything else.

The main problem, is that in SCCM 2007 we have no “easy” way to create an Auto-Acceptance rule. However, the SDK contains an end-to-end sample on software updates that:

  1. Downloads specified software updates
  2. Puts them in a Software Updates package
  3. Distributes the package to all distribution points
  4. And subsequently deploys these updates to a collectionid you can specify when running the end-to-end application.

A couple of weeks ago John Marcum asked whether this couldn’t be used to auto-approve forefront definition updates as he didn’t like the current implementation.

I shot off my big mouth (should have known that staying quiet and shy gets you into less problems), saying that this shouldn’t have to be terribly difficult, and hence John called my bluff asking to have it built. Did that and delivered on it 2 weeks ago, and after John and me running some thorough tests, it seems to work fine. I will be sharing a link to the tool at the bottom of this post. All I did was

  • Modify the SDK Sample to work with FCS and FEP 2010 updates as opposed to the original security updates in the provided sample
  • fixed a bug where the tool would crash if a software updates package existed with the same name, essentially killing the ability to re-run the tool.
  • Added a test for whether the updates had already been download to avoid downloading updates 2 times
  • Made the code to reuse the same deployment and update package each time around as creating new ones each time a definition would come in in would just generate way too many objects.

That worked out fine, however left me with a command line tool that needed to be ran for new definitions to be approved, which beats approving them manually, but fails horribly in stacking up against the WSUS auto-acceptance rule approach. So we needed some eventing to solve that issue. I could have reverted to my new found love of “WMI eventing” however I figured that approving new definition updates didn’t need to be instantaneous, so instead of using WMI evening, I relied on status filter rules for this particular “eventing” need.

I configured my Software Update Point to sync with microsoft update every hour, and created a status filter rule for the deployment to occur after each successful Wsus Sync.


And on the Actions tab:

Have the status filter rule run the following program:

“d:\sources\Sum E2E FEP autoApproval\sum_e2e_deployment.exe” sccm01 S0100055

IMPORTANT: Read the SDK EULA.RTF in the zip file before using this. This remains a sample, and it is your responsibility to test this before using it! No warranties or support of any kind is given with this free tool.

Share This Post

Leave a Reply