A Pretty Good Solution for Deploying Forefront Definition Updates (with ConfigMgr)

Microsoft Forefront is an excellent solution for the antivirus needs of your enterprise. Not only is it a top ranked solution, but it is also quite affordable. Many customers have made a decision to abandon solutions like Symantec Antivirus or Mcafee in favor of Forefront as a superior and less expensive solution that they may already own as part of their Microsoft E-Cal.

Deployment of Microsoft Forefront is not overly complex and there are walk-throughs for the server setup available from Microsoft. However there is a challenge with the deployment of the Forefront definition updates which can be as large at 35mb. A pure Forefront deployment requires the use of WSUS to deploy the definition updates. WSUS manages the definition updates and will deploy delta updates for most of the updates. Still, about once a month the entire 35mb must be downloaded to each client. For customers with many locations over slow or moderate network links having a single WSUS server could create network flooding issues as the clients attempt to copy content from a single location to clients all over the network. There are a couple existing approaches to solve this problem, each with its own advantages and disadvantages. I will attempt to summarize the existing options.

The Multiple WSUS Server Solution
One solution is to deploy multiple WSUS servers as children to a centralized WSUS server. This enables you assign clients to WSUS servers with group policy and they would receive the updates from the server to which they are assigned. An advantage here is that you don't need another solution like ConfigMgr in order to efficiently deploy definitions. You may however require a lot of WSUS servers and that may lead to a complicated WSUS environment. WSUS would require IIS to be installed on remote servers and to have servers in field offices.

The ConfigMgr/SMS 2003 Software Distribution Solution
This is a popular solution originally created and published http://blogs.microsoft.co.il/blogs/yanivf/archive/2008/02/24/updating-forefront-client-security-definitions-using-sms2003.aspx. With this solution you configure a scheduled task on your ConfigMgr site server to download the Forefront definitions. You then create a configuration manager package containing the x86 and x64 definitions and deploy that out to your ConfigMgr Distribution Points. An advertisement then is created to run/install the definitions. This solution is good because it doesn't require an extensive WSUS or Software Update Point environment. It utilizes existing distribution points that are utilized for other software distributions in your environment. It also takes advantage of the excellent software distribution status reporting capabilities available in ConfigMgr. However there are some disadvantages with this approach. Namely, the entire 35mb definitions and possibly even the x64 definitions are downloaded to each client each time the definitions are updated. If you schedule this daily that can be 35mb or 70mb per day per client. If all your clients have local distribution points this may not be a problem, but if you have clients going over the WAN (slow boundary) this could cause network flooding.

Deploying FCS definition updates with a shared System Center Configuration Manager WSUS infrastructure
As the only solution that is supported by the ConfigMgr team, this solution is generally what I start with when I'm working with a customer to deploy ConfigMgr and Forefront simultaneously or one after the other. For customers with smaller networks this may be the only solution needed, and one of my fellow MVPs (John Marcum) implemented this with 3 WSUS/SUP servers and over 100 locations. He states he never received any compliants about network bandwidth using this solution. However, with this solution the majority of your definitions updates occur over the WAN from the WSUS server. You can of course have multiple WSUS servers and could install SUPs on all your secondary sites. This would reduce the number of updates going over the WAN, but increase the complexity of you ConfigMgr site architecture. More information about this solution here: http://technet.microsoft.com/en-us/library/dd185652.aspx.

So there is a summary of the existing solutions up until now. I have recently implemented a 4th solution at a customer which solves many challenges while eliminating the need to deploy many many WSUS/SUP servers. So finally, what you have been waiting for. The 4th solution -

A Pretty Good Solution for Deploying Forefront Definition Updates (with ConfigMgr)
This solution started out as the previously mentioned ConfigMgr Software Distribution solution for deploying Forefront Definitions. However as I worked with that solution and began deploying definitions to more and more to clients over the WAN it became apparent the solution needed to be enhanced or I'd have to abandon it for the officially supported MS solution. I didn't really want to deploy more than 100 WSUS/SUP servers so I opted to try to enhance it.

The first piece I adjusted was the deploydefinitions.vbs used to download the definition .exes to a local folder on the site server. After the definitions are downloaded, the vbscript was adjusted to extract (as opposed to simply copying) the definitions to an x86 and x64 folder. This enhancement enabled me to have two packages, one for x86 and one for x64. By splitting the definitions into different folders I reduced the size of my download and execute per client from 70mb to 35mb. The extracted definitions consisted of several files: MPASBASE.VDM, MPAVBASE.VDM, MPAVDLTA.VDM, MPASDLTA.VDM, mpengine.dll, am_full_engine.ini, and mpsigstub.exe. An analysis of these files comparing several days worth of definitions files indicated that the BASE.VDM’s changed monthly, and the DLTA.VDM’s (Delta) would change with each definition release. The Delta files were usually 2mb at most and the base files were as large as 20mb. I was really curious about the mpsigstub.exe and upon launching it I noticed it silently updated the definitions on my test system. It also produced a mpsigstub.log in the temp directory indicating its success/failure. Ok – now worst case I could use xcopy delta to only copy the changed files from the package source to a temporary folder on the forefront clients and then launch mpsigstub.exe.

Using a simple script to copy only the files that were different I was able to substantially reduce the size of the re-occurring daily definition updates. However I still had a large number of systems receiving content over the WAN without a local distribution point. These weren’t causing problems with the small delta xcopies, but I knew the BASE.VDM’s would eventually be updated and I didn’t want them to be copied down via SMB over the WAN. I really wanted to take advantage of BITS and my BITS enabled central distribution point. Unfortunately ConfigMgr Download and Execute does not provide any delta capabilities between the distribution point and the client otherwise this solution would be a lot simpler!

So I developed a script that I added to the package source. When run from the distribution point the script checks to see if the content can be accessed via http or not. If not it assumes the DP is local and copies the content down (delta) via SMB and then launched the mpsigstub.exe. If the content is available via http, the script will use BITSADMIN to copy the content and then execute mpsigstub.exe upon completion of the copy. The end result for this customer is that their ForeFront definitions are more up to date than ever before and we are looking at updating the defs more frequently than just once a day.

Look for another post coming soon with step-by-step instructions and script examples to implement this solution in your environment. It should also be handy if you don’t have Forefront, but want to utilize BITSADMIN and customize status MIFS for your non-forefront related packages.