I’m looking at our strategy for baselines and can’t help but wonder that this is not necessarily the best method.
What I try to create is a baseline for each month (MS Patches only).
If you look at Feb 2008, there are a number of patches and in total, witht he corrupt patches, there are 111 patches (not recommended in BES).
The other issue is changing the deployments with No Default Action to Action 1 and then constantly having to sync them when they are changed. BES 7 helps this witht he sync all components
I find this an administrative headache and was wondering if there are better solutions.
It would be nice if there would be a filter not in the relevance only for OS selection. For example, when selecting all Fixlets, filter by OS so that only XP fixlets would show up in you’re selection list.
Also, what is the benefit of having multiple component groups?
I second that… Don’t get me wrong, BigFix is flexible as all get out and works great. However often times I’m left scratching my head thinking there has got to be a better way (when it comes to MS patches).
BigFix version 7 with efficient MIME makes baselines much more efficient so the 100 Fixlet baseline limit is no longer necessary.
I think most customers don’t include the “Corrupt Patches” in their montly patch baselines because “Corrupt Patches” often need to be dealt with independently with a separate restart anyway. This might cut back on the number of Fixlets by a factor of 2 or so.
Multiple components in a group are available for you to separate the Fixlets into logical groupings you can name. They don’t really have any functional differences beyond that.
Does CTRL-F searching help you with the OS selection question you asked about? For instance, search for “Windows 2000”. We looked at trying to add filters for OS at one point, but many patches are OS independent (for instance, Office, IE, and other application Fixlets) and there didn’t appear to be a great way to do this other than the searching.
Many Fixlets don’t have default actions on purpose (usually because we want you to read the description of the Fixlet) so be careful with those.
We added the “sync all components” to BES 7.0, is there something more useful we can do in this area?
So baselines can now be greater then 100 fixlets? Is there a recommended maximum? I’d love to have one baseline for each year with all MS patches. Then as new ones come out we just add them instead of having to build a new baseline every month. Do you guys have a best practices guide for this? Thanks
A best practice or methods/concepts to patching would be great… 2nd again…
The other thing about doing baselines like you are talking MC. Do you make every single patch for 2006 part of that baseline, or only the relavent ones for your systems? Then if one super seeds it, do you manually have to remove that patch from that year? And do you do an action for ever year’s baseline?
I’m not sure if you utilize a “standard image” for your workstations - but for us what I do - is I have a baseline just for our “imaged” workstations. Among a few other tasks and fixlets - it contains the monthly patches. Our image gets updated about once a quarter (hotfixes, patches, etc). After that image update - I remove the MS patches from my baseline that are really no longer relevant - as all the existing workstations are up to date - and the new image is up to date. That helps keep my baseline smaller - and I can then reuse it - instead of building a new one every year.
I call that my “security and compliance” baseline. I also have baselines for “BES compliance” and then a couple for “Anti Pest”. I like breaking my baselines up a little - that way they are a little more specific - and I can target different groups. For instance - the “BES compliance” baseline (latest agent, firewall settings, auto-relay, etc) is targeted for ALL systems. While the “security and compliance” is primarily for our imaged workstations. Our server engineers do their own baselines for their servers.
The great thing about the baseline - is that once targeted and filled with content - I never have to worry about new or reverent systems not being in compliance. I used to spend a lot of time in the console - making sure all the agents had what they needed - but now compliance has become very “operational” and the need to babysit has lowered immensely.
That’s great your environment is that static Mgoodnow, however the issues I tend to run into is some developer loads up a Windows 2000 server on there VM server using there MSDN CD and joins it to the domain and of cource never bothers patching it or installing AV, etc. Or even in your case, you could deploy an image run that on a virtual server and create a snapshot then a few months from now someone reverts back to that snapshot and the system is now un-patched. And by now your standard image has been updated and the patches that VM is missing are now removed from your baseline (I’ve run into that as well).
Base lines are great, and now that we’ve moved to ver 7 I think they will work just fine. I’d still like to have a set it and forget it option. Always having to cancel the deployment, add new patches to the baseline, re-sync older patches, re-deploy the action. Just does not make sense to me.
You make a good point. Sounds like you might be heading towards NAC being a good solution for whom you allow on your network (or not) - based on compliance. We are heading down that path ourselves. Not an easy path - but we are starting it slowly.
Our images might be fairly static - but we still have the same issue with new “non” image workstations (the rogues), servers and VM test systems. Plus we have vendor supported systems that we have them put Big Fix on - so that we can report on them - but we can’t patch them (and we don’t always know about new systems that are added to the network). So an all encompassing baseline is not ideal for us either.
Which is why NAC is looking better and better all the time.
Initial Patch Tuesday deployments can be handled both ways. While individually you are correct that it takes a lot of clicking you can still have their actions deploy at the same time and end at the same time. I have found that monitoring specific actions are better handled through individual deployments as it is a bit more convoluted monitoring through the baseline action. But again not impossible. The biggest advantage I have found is if an unforseen issue occurs (but these never happen, right? NOT!). It becomes much easier to stop 1 action while the remainder continue to remediate your environment rather than stopping a baseline and either removing the offending fixlet or just changing its individual relevance to FALSE. Then having to redeploy the entire baseline.
But after the initial remediation of your environment and the end of your initial individual actions a baseline to keep your environment remediated going forward.
This is just one lowly Admin’s opinion… I would look forward to other Admin’s opinion out there in the real world.
