(imported topic written by albert.arroyo91)
Are sys admins replacing their WSUS with BigFix or are you guys using both WSUS and BF? I’d like to hear some feed back from the field and any pros and cons.
(imported comment written by rmnetops91)
We replaced WSUS with BigFix. Cons are that WSUS and SCCM provide updates for non-critical updates that also show up on the Windows Update website vs. BigFix does not provide fixlets for non-critical updates. You can however create your own fixlets for the non-critical updates. IT staff that check Windows Updates on BigFix updated servers, may ask if BigFix is possibly missing updates. You just need to explain to them why.
Pro’s are BigFix will catch installed updates that have become corrupted on a system (i.e. previously installed updates that get their patched files overwritten with vulneable versions by a thirdparty app or other factor) vs. WSUS (and SCCM btw) will not, and will leave your system vulnerable, thinking it’s already been patched but in reality is still vulnerable.
(imported comment written by peter91)
I’m trying to figure out a way to move from WSUS to BigFix for Microsoft patching. There doesn’t seem to be an easy way to mimic WSUS’s administration process by simply approving patches. Since baselines are limited to the amount of fixlets that they can contain (<100), hundreds of baselines need to be maintained.
I was told by tech support that baselines are probably not the way to go because of the amount of effort required to maintain them.
I’d like to know what process BigFix admins use to keep their environments patched and how much effort is required for each monthly MS patch cycle.
(imported comment written by SystemAdmin)
WSUS is certainly simple and easy, but is not very thorough. As rmnetops pointed out, it is quite easy, even prevalent, to have patches get corrupted by other patches (perhaps from another vendor) or through installing a piece of software. WSUS and SCCM don’t provide that insight.
The trade-off for that degree of confidence is longer deployment times and a bit more complexity. The deployment cycle takes longer as fixlet relevance is evaluated both before and after the action. However, when it is done, you can be sure that it is complete and done correctly to a high degree of confidence. There is some complexity in developing a strategy that works for your organization, then maintaining that strategy at least monthly.
It isn’t uncommon to get mixed messages about baselines and patching strategy from Bigfix as there are differing internal opinions I’ve found. The catch-22 is that baselines are about the only sane way to deploy patches to large groups of machines, yet large baselines are difficult to manage and slow for agents to evaluate. The optimal size and construction of those baselines has been the subject of much debate. The truth is that it varies somewhat with the organization and its infrastructure topography.
When constructing security baselines, consider several things: how many platform variations do you support? What is your deployment window? Is the hardware recent with fast processors or old and slow? Are there any bandwidth constraints such as slow WAN connections?
You may need to experiment to find the proper number, scope, and size of baselines given the agent type, bandwidth, and deployment windows. Do this in the lab so there aren’t surprises in production. You need to strike the proper balance for your organization. Test, test, test …
A significant thing you can do to help yourself is to maintain current images with the latest security patches baked in. The more frequently and vigilantly you keep them updated, the less work you’ll have patching machines in the field.
(imported comment written by Mosbey91)
We have moved away from baselines for deployment of security patches. They were slow and growing to large. We now deploy our monthly patches in actions and leave the actions running for 3 months. Our image is updated every three months with the latest security fixes. Since we are a small shop (less that 1000) this seems to work best for us. We test the patch, incorporate it in the monthly actions, update our image every 3 months to incorporate the latest patches then start the cycle over again.
(imported comment written by rmnetops91)
We still struggle with the large baseline issue. We don’t have the capability to image all of our machines regionally so some machines will get built with the default OS and latest service pack (requring all post-SP patches).
(imported comment written by johnsonbj91)
We began facilitating the use of BigFix on our network (prior it was just all sneakernet) and we are thinking that it is probably best to simply turn off all MS updates via GPO and use BigFix for deploying critical updates. Prior to the sneakernet, it was WSUS, which didn’t work all too well.
Other than critical updates, are there really any good benefits of keeping the computers pointed to Microsoft’s update site? My customers are very ‘difficult’ and are slow to changes that impact their work (just got SP3 on them a bit ago, lol)
(imported comment written by tscott91)
I’m still trying to figure out this very thing… WSUS was so simple in the fact that you approved update(s) and then the PC’s did the rest… Checking in to see if it needs it, download it using BITS, and then install it at the scheduled time…
I’m in a predicament in that I have 1,400 PC’s with updates needed from 99 all the way to present day… I’m trying to wrap my head around how I should handle getting them all up to date with zero patches needed for each!
Once I do get that, I’m going to update my system images on a monthly basis with all updates so when a new machine comes online there is barely anything it will need to grab…
It’d be nice to hear more input on what others are doing.
Tom
(imported comment written by Tingram91)
Tscott,
I would run a catch up Action.
Target all machines with all relevant patches, a single action
Leave it open for 30 days, incase some are offline or Laptops offsite.
Then simply perform a monthly update action, Target all relevant machines.
Just note that some patches are going to require a reboot, so schedule that reboot to occur after hours, or non production.
(imported comment written by tscott91)
So you would select 350+ fixlets in one action? Wouldn’t that affect performance on the clients?
(imported comment written by Tingram91)
the clients aren’t going to utilize 100% CPU to perform these patches, there going to use the default of like 2% to process. And not every client is going to run this action (not relevant) there going to do a check and process through the list to determine what is required.
An example of this is to grab a list of 100 devices, highlight and right click View as Group.
Click the Fixlets tab and you will see that it will show 60/100 , 56/100… etc…
Highlight all the fixlets in that list and right click Take Default Action (Some aren’t going to let you)
As the action runs, machines are going to plow through the list of fixlets to determine what they actually need.
And double clicking the computer name under the actions, will show there status for each as they process
Once completed, you can also review the actions that occured for each machine.