Background:
I have been wrestling with Forefront Client Security and the fact that I cannot get my deployed clients to update their definition files from the server. If I take the distribution server offline, the clients will update from the web without issue. This is the expected process, outside of the failure to update fro my server to begin with.
After much troubleshooting, I was able to isolate one of my issues to a problem with WSUS not downloading updates. If the updates would sit long enough, they would eventually download, but since I have the server configured to sync updates four times a day and new definitions are being released frequently, the definitions would expire before they would finish downloading.
What I found in researching the download "failures" (it wasn't that it failed, they just never downloaded before they expired) I found that the BITS download process is using HTTP 1.1 and performing the downloads in a background process. Sometimes, firewalls or other security software/hardware can cause this process to appear flaky. In my environment I am using ISA 2004 and am not blocking any outgoing traffic, but there still seemed to be an issue with background downloading of updates in WSUS. Instead of opening a larger can of worms and tackling the ISA issues, I implemented this workaround that moves the WSUS BITS download process into a foreground process. By running the following command, it reconfigures the updates to run in the foreground and all of my updates completed quickly. I would probably not recommend this if you using WSUS for all of your security updates, but because mine are just Forefront definition updates, the impact to the server is negligible. The following fix assumes that you have the WSUS database locally on the WSUS server and are using WSUS 3.0 or higher. If the database is on a separate server, execute it on the server that you have the tools or database on.
From a command prompt, execute the following:
C:\>NET STOP WSUSSERVICE
C:\><path to SQL tools>\sqlcmd.exe -S <sqlserver\instance> -E -b -Q "USE SUSDB update tbConfigurationC set BitsDownloadPriorityForeground=1"
C:\>NET START WSUSSERVICE
You should see the approved updates start downloading within a few minutes. I am still waiting to see if that totally resolves my client update issues, but I can definitely say that clients are not going to update if they can get to the most recent definitions.
If you didn't already have this process down, here is a decision tree to help assist you in deciding whether to repackage and application or to look for automation options already available to the the application. There are three processes in the tree that are assumed to be documented or used already:
- Software Repackaging - capturing an already built installation for automation and tweaks for deployment
- Software Automation - using MSI, INI, ISS, Scripts, or any other means to automate an already created installation
- Software Packaging - creation of an installation or customizations from scratch
Hope it helps you.
I find myself asking this more as I finish up teaching a training series on software deployment and repackaging. I found that the questions on the last day lead me to lean towards defining it as a discipline or almost, dare I say, and art form.
While there are definite reasons and decisions that are made to identify how you automate a software installation, the final act of automating is really up to the "artist". Some may find it better to analyze and recreate, while others may capture everything which is like throwing mud at a wall to see what sticks.
Some re-engineer software installations like they are ornate sculptures or grand buildings, needing to endure time itself. Then again, some just throw something together, like a preschool finger painting, and hope that it doesn't break anything. And software suites for repackaging don't help. They try to give you all the answers through pretty wizards and an overflow of tools, even before you even know there were questions. (Not helpful, BTW)
When I entered the last day of the class today, I was feeling proud, knowing that I provided many days of technical knowledge that should have raised everyone's skill level to the point of installing anything and understanding what changes were being made and why. What I totally missed, in all that pride, was the real WHY. Why repackage? Why this method over that one? Why a transform over a script? Who is really right in the end if it all installs correctly and will be updated in a year or so anyway? And who really runs patches anyway (outside of MS products)? Almost any system I've implemented, ends up with removing the old and installing a new version as the upgrade path.
I guess part of it was that I assumed that these answers and questions were obvious. I mean, why take a class on repackaging unless you understand some basics about why to automate. I found myself wishing that I had spent more time actually teaching them why I made decisions for using one automation method over another based on what I was trying to accomplish and what technology was being used initially.
I was able to create a decision tree for them that would aid in defining some of the decisions, but in the end the choice was really up to the artist and how much time and pride he had time for or wanted to invest in the automation.