I’ve been struggling going forward with baselines since I moved to BigFix… It was much easier to just approve updates and then have the clients check in to see if they were applicable and then download and hold for the scheduled install time…
What does everyone here do? Do you group MS patches by quarter? Do you put all OS’s in their own baseline or do you combine them all in one (IE: All Windows XP MSXX patches from Jan-10 - April-10 in one baseline, All Windows 7 MSXX patches from Jan-10 - April-10 in one baseline, etc)?
After repeatedly struggling to find a workable solution, we’ve settled on the method below. I can tell you that 250 fixlets in a baseline will probably bring your clients to their knees. Support seems to dislike anything even close to 100. Perhaps with version 8 that has change
Each OS gets a baseline by fixlets year. We differentiate by 32 bit and 64 bit OS as well. So the names look like this:
Windows OS Security Patch Baseline - XP >SP3 - 2008 - 0710
Windows OS Security Patch Baseline - XP >SP3 - 2009 - 0810
Windows OS Security Patch Baseline - XP >SP3 - 2010 - 0810.1
Windows OS Security Patch Baseline - Win7 64bit - 2010 - 0810.1
The 4.1 digit number on the end is the last time the baseline was updated -
2 Digit Month
2 Digit Year
.
Revision Number for the Month
. That way when we deploy we can easily see the version we deployed.
So do you set these as policy then? So if a computer that hasn’t been turned on for a year gets booted up, agent installed, do you have the updates applied right then?
EDIT TO ASK:
Also, how do you create the baselines so it’s easy to just add by OS? Do you search and just type in “XP” for the “name” field? And so on??
Tom, yes, we deploy as policy actions with no reboot.
I think your other question is asking how we add content to the baseline. The answer is not a pretty one, but you are on the right track. We built custom filters to attempt to make the task easier. While this works 97% of the time, it misses the mark on fixlets that don’t have the OS listed in the name. For example “MS10-060: Vulnerabilities in the Microsoft .NET Common Language Runtime Could Allow Remote Code Execution - Microsoft Silverlight 2/3”.
So I put a feature request in (http://forum.bigfix.com/viewtopic.php?id=4593) as an attempt to make such updates easier. That way we could search on those tags / properties and get the exact content. Please add to the vote if you feel it would be useful.
Ok, so here is where we take a turn from the “norm”. I like dynamic and I like a single source of the truth. So what do I mean by that? Well, we want to know which computers are running XP, Win7, 2008, etc, but we only want to have one version of that relevance. So we build “Automatic Groups” that contain that relevance. And we nest the other automatic groups.
Example:
We have a group:
Windows Systems
using the relevance of - OS contains “Win”
We have another group:
Windows Workstations
Is member of
Windows Systems
AND (OS contains “winxp” OR “winvista” OR “win7”)
Then a few groups:
Windows XP Workstations
Is member of
Windows Workstations
AND OS contains “winxp”
Windows 7 Workstations
Is member of
Windows Workstations
AND OS contains “win7”
Then we build our baselines with relevance that references those Automatic Groups. For example, for Windows XP Baselines the relevance would be:
Is member of
Windows XP Workstations
.
Ok, so the downside to this is that if you change the Automatic Group relevance, you could trigger unintended actions if the actions are based entirely on the group membership. Something the underlying architecture of BigFix is designed to prevent. But it works for us. The “norm” is just to embed the relevance in each Baseline, and then update said relevance in all those places when you need to. The problem of relevance versions spurred another couple of feature requests of mine - (http://forum.bigfix.com/viewtopic.php?id=3861) and (http://forum.bigfix.com/viewtopic.php?id=4181).
Sweet mercy… Having to do this without being able to filter out by OS BLOWS! I know that it just blows because I am starting from scratch so need to go through years of patches but dayum!
Another question… You say you deploy as policy with no restart… Do you have a time window for this to happen or do they just start when the PC gets powered on?
Also, do you use the “Display message while action is running” option?
Yes, we have two baselines - Office 2003 and Office 2007.
I have a question for you. Have you configured update locations for Office patches to connect with the MSI files or have you found that to not be necessary?
@tscott - we do not display a message to the users while the action is running. we do have a reboot window and we alert the users via email and a bes message.
@TonyK - We have the update locations configured for Office 2003. Office 2007 does not need it, nor can you set one via the fixlets, afaik.
