BigFix Reviews

Vulnerability scanning and patch automation.

Also, software deployment in distributed environments, as it provides control over compliance and saves us a lot of time.

Before an internal IT team performed all these activities manually, which took time and did not guaranteed full control over compliance. These activities required access to a corporate network via LAN, because VPN often generated errors. 

Now, the process is centrally controlled, reported, and has an independently formed location (also over Internet).

There is no support for patch management on SLES on IBM pSeries (only the Intel platform is supported). This should be improved as soon as possible. It is a stopper for us to roll-out BigFix to all datacenter servers (500+).

About three years for PCs and one year for servers.

No issues.

No issues.

There was a technology consultant available in Poland, who was very helpful, but recently he has left and no one has replaced him.

Yes, Itelligence Germany uses HP automation and we had a pilot implementation.

We have complex requirements.

We offer BigFix as a service for our datacenter hosting customers.

Patch is a given and it is the flagship feature since the late 1990s. The architecture for patching and the 100% correct reporting makes BigFix stand apart from other solutions. Software Distribution is another powerful and strong feature that automates deploying software and saves a ton of time. The BigFix framework also gives you the ability to remove software and updates files, like configuration.

Patching is completed usually within a day or two. 98% of the endpoints are patched in the first pass no matter if they are all the corporate or traveling.

The new EDR (Endpoint Detection and Response) feature, Detect, is new and still needs a few updates. This is close to being a great addition to help when an attack has occurred.

Five years.

No stability issues. If relays are not configured correctly, then this can cause a performance issue. An occasional health check is needed to ensure the solution is running at peak performance.

BigFix can scale up to 250,000 endpoints on one server.

The deep technical resources are very good and can isolate an issue very quickly.

We started with SCCM and decided to switch because of inaccurate reporting, limited OS support, and we were unable to patch remote endpoints.

Initial setup is very simple. With the Web User Interface, it makes the learning curve very short.

I would stay with the Managed Virtual Server license model, which is a 1-to-1 license per OS whether it is virtual or physical.

Yes. SCCM, LANDESK, Altiris, and Tanium.

You will not be impressed with the looks of the reports, but they are accurate. The BigFix.me forum is a great place to learn from others.

Ability to run custom reports and custom relevance.

It allowed us to proactively seek out issues as well as quickly react to issues and target only computers which needed fixes. It was very easy to streamline down to what was needed.

We need a much better multi-tenant option. 

We had 60 plus divisions and there was no real way to effectively give those people the help at the division sufficient rights within the console to see just their responsibilities. We wanted Bob at one of our divisions to have console access and only be able to manage his computers. We were not able to find a way to effectively do this. They had a web console that did not really handle our needs. 

My current company is a consulting firm. If they had a better way to have multi-tenant access, this could be a product that could potentially do great good for us. As it was, when I last used it, it would not work for us without setting up a new instance for every customer we manage. Not really effective for our needs.

I have used it for about four years.

Yes, occasionally we did.

Yes, we did find some “quirks” and had to get creative, but we were able to work within the solution to streamline transfer speeds to not saturate networks between sites when synchronizing enormous install packages to our relays scattered around the country. Also, we could not easily scale the management to multiple tenants as we hoped and as we were able to do with other products in the past.

I didn’t have to deal with them much. Others did. We frequently found that we were bringing solutions to them.

I did not do the initial setup.

This was not my responsibility.

I was not the decision-maker here.

It is a great product. Spend some time really learning about the capabilities and how things are organized within the product. Then, spend some time really planning your structure and how the organizational groups should play out. It will make things a lot easier down the road when you need to send something to just one area of your business. Unfortunately, it is usually after a product is implemented that we truly understand how to best implement for our environment.

• Patching support: IBM BigFix supports most of the major OSs with natively packages patches. This includes Windows, MacOSX, Oracle Linux, Solaris, AIX, RedHat, Ubuntu and others.
• Pre-packaged support for many third-party applications such as Adobe, Google, Mozilla, Sun (Java), WinZip, and others.
• Near real-time view of the environment. Most systems will report their current patch state within 15 minutes.
• The IBM BigFix console provides a single pane view into the entire environment. This also provides a common interface for taking actions, such as patching, to any operating system with a similar look and feel.
• Ease of installation, maintenance and troubleshooting. IBM BigFix is one of the easiest tools to install for an Endpoint Management tool, especially compared to IBM’s predecessors and Microsoft’s SCCM. As an example, the first time installing IBM BigFix in my lab with about 10 systems took approximately one hour from start of installation to applying OS patches. IBM BigFix is also very easy to scale by adding new relays. The design is flexible enough to be able to “add as you go” without having to perform a major architectural review.
• For troubleshooting, the log file structure is very simple, as most files are in the same place and have a standard format.
• Adding new components such as IBM BigFix Compliance or IBM BigFix Inventory does not require new agents to be installed. By enabling the content, by clicking on a hyperlink in the License Management Dashboard, and taking action with a couple packages, the infrastructure is ready to start gathering more information.
• Reporting capabilities: With the IBM BigFix console, I am able to quickly provide information to any group. With the use of the IBM BigFix Web Reports, I am able to design reports that I can save and provide to users to execute when they desire. These reports can also be scheduled to run and email the users.

Our primary use for IBM BigFix is around patching and reporting on Microsoft Windows servers. We are also using the reporting capabilities for patching state on AIX, Solaris, and Red Hat Linux. These reports are being presented to the Safeguards groups and are being used to report MSA compliance for our server environment.

IBM BigFix has provided our Windows server team more flexibility for scheduling the deployment of patches in their environment which has caused them a lot of issues in the past. Also with the near realtime reporting, the server teams know the state of their environment right away. We have also been able to see where patches are failing to install on systems that previously were assumed to have been installed. This has identified many systems that were thought to be in compliance, that were not.

Some other useful information that we are able to gather with IBM BigFix:

• Currently logged on user(s)
• Servers in pending restart state
• Hardware and software information
• Symantec Endpoint Protection state (client version, signature version, etc.)
• Installed MSSQL databases

We gather a lot of other information too. Although all of this information is available in other sources, with IBM BigFix, we are able to bring all of this into one console view which can be used for filtering and reporting.

We have also linked IBM BigFix into ServiceNow’s CMDB to “brand” systems with CMDB data. This is also useful for filtering, grouping, and reporting.

We have used IBM BigFix to develop software packages to deploy new versions of Symantec Endpoint Protection, Microsoft SCOM agents, Flexera agents, and others.

The most recent task that came up was the deployment of the MS17-010 patch to address the “WannaCry” malware. With IBM BigFix, we were able to quickly identify out of compliance systems and remediate them and validate the successful completion of the installation.

IBM has been heavily focused on adding and improving features to the tool, especially with new components like IBM BigFix Detect. While all these new features are great and provide useful information, IBM has not focused on the Web Reports capabilities. This is not to say that the Web Reports is bad, but at this time, it is currently the weakest part to me. IBM has also introduced the BigFix Web UI, which is a start to addressing the web based reporting. I believe that this is going to be the direction to modernize the web reporting capabilities along with providing a web based console.

We have used this for seven years.

No. Deployment of the server, relays and endpoints is very simple especially compared to other products that I have worked with.

I have not had any issues that were due to the product itself. I have had issues that are user related, such as admins using incorrect installer in DMZ, and other external issues that impacted IBM BigFix, but not the product itself.

The installer for the BigFix agent is comprised of an MSI and a file called masthead.afxm, which is the file that contains configuration information such as the BigFix Server host name and a key. With only these two files, the agent has to be able to communicate with the BigFix Server on port 52311. If the agent cannot communicate over this port, it will fail to register and will never connect to the BigFix Server. In order to get around this, a file called clientsettings.cfg is included to configure the agent to talk to a different BigFix server called a relay. This relay would have the ports open to allow communication between the agent and the BigFix server. This is a very standard practice for devices in secured networks. So even though I have provided this install method and the users have been provided documentation, it still seems to get missed once in a while. Here is an article on this http://www-01.ibm.com/support/docview.wss?uid=swg21505838

At a site I worked at a while back, the user insisted that every support tech, help desk person and server admin be allowed to have console access to the BigFix infrastructure. This ended up being about 350 users which is way more than they had in other tools and it was strongly recommended that they do not do this and we only give it to people who were trained and would actually use it. This leads to issues with people not using the tool correctly (lack of training) and not understanding the tool. As part of the administrators for the tool, there was no way for us to provide training to the 350 users. This again is not a tool issue, but a process issue.

Couple other external issues we have seen that impacted BigFix

- Proxy issues stopped content from being downloaded to BigFix server

- SAN issues caused performance problems. BigFix can be very I/O intensive, so degradation in I/O can really bottleneck transactions and console performance.

I am sure I could think of a couple more, but usually these are not tool issues, just user/process problems.

There were no issues with scalability. When we added more systems then originally scoped, all that was needed was a new relay. Since our IBM BigFix server is on a VM, we also added two CPUs and more RAM (currently at 16GB).

IBM Support has been pretty good. For the most part, solutions are provided quickly (couple days), but I have had one that required more analysis and it took a couple weeks. I also find that using the user forum (forum.bigfix.com) is also very useful as some of the IBM BigFix support people are there along with very knowledgeable users.

At the current site, they were using WSUS to patch the Windows servers and native tools for the AIX, Red Hat, and Solaris environments. Although these tools were “doing the job”, there was no easy reporting capabilities out of any of them. SCCM was also used in the Windows server environment at one point, but due to a major issue that was caused, it was removed from the servers.

For the extra data that IBM BigFix collects, there are other tools that provide the information, but required logging into the different tool consoles to gather and then manual consolidation.

IBM BigFix is one of the easiest client management tools to install. Once the operating system and database are installed and configured, installing the IBM BigFix server takes about 30 minutes to complete. After that, enabling content (Windows, AIX, etc., patching) takes a couple minutes. Once this is ready, deploying the agents can be done with a client deployment tool provided by IBM. This tool is capable of deploying to Windows and non-Windows systems. To deploy to one system will take about two minutes, but the tool is capable of parallel deployment, so deploying to 20 systems would take about five minutes. We were able to deploy about 400 Windows agents in a morning.

This was implemented in-house.

We estimate the ROI to be about 6 months, possibly less. The reason for this is the standardized reporting for all the platforms that we support. Each OS tool had capabilities to report on the patch compliance, but none were the same and some were very manual. We were also able to produce more timely reports as the process was simpler in BigFix. We used to only provide annual reports which could take a couple weeks to get all the data into a similar format. Once we standardized on the format, we now have reports that can be generated at any time within a few minutes.

Also our patching process is fairly standard across the various OSs. Once setup, the methods to deploy a patch is very similar for each OS.

With our new process, we have also reduced the number of "manually" patched servers as we have more flexibility for scheduling.

IBM BigFix comes with many different packages depending on the functions that are required. IBM BigFix Patch is the most basic package which provides the ability to patch almost any operating system with many third-party applications. It also provides the capability to create custom content such as software packages (called Fixlets), inventory scans (called Analysis) and create custom reports. All of the other IBM BigFix packages also provide patches.

When purchasing, buying with other IBM tools provided us with a very good discount in pricing. Also since we were deploying to a highly virtualized environment, the use of RVU (Resource Value License) was very beneficial for us.

We evaluated SCCM. This was already in-house, but not desirable by the Windows team. It also did not support the non-Windows platform (at least not to the extent that BigFix does).

IBM BigFix is simple to implement and can quickly provide insight into the environment. By looking for “pain points” that the various groups have, IBM BigFix can be used to quickly assist.

As an example, the Windows server team would at times leave themselves logged into a server which would cause account lockouts. They did have PowerShell scripts to detect this, but they took a while to report back and if the system was behind a firewall, they would not see it.

By using IBM BigFix, we were able to collect this information (default data collection) and present it in the console. Another example was identifying systems in a “Pending Restart state”.

I have been using the patch management and server automation feature of this product. In terms of vulnerability management, it gives tough competition by providing a single management console with multiple benefits. Customization as per the requirements is one of of best it offers and almost any form of scripts and any OS can be supported for those customization.

The automation aspect has surely reduced the manual efforts leading to diverting those into other productive areas. Instead of manually bringing down any application prior to maintenance, this tool offers the capability to bundle a script ahead of patching, so maintenance and the corresponding patching is just a click of a button.

The tool should be more friendly in terms of Web UI and should be having better vulnerability scanning mechanisms so a third-party application is not required to fulfill that aspect.

I have been using the product for almost five years and have explored quite a lot with respect to its utilization and benefits.

The tool has been quite stable. It has improvements within each version, which have made it become better and more powerful.

No issues. It can well support clients, even if it is more than 100,000, easily and efficiently.

The support from IBM is good. It sometimes takes them a while to identify and come up with a workaround which can impact the environment.

Not really, I have been using multiple tools like BigFix/SCCM/Tanium for vulnerability remediation/inventory management. I never really switched from any other tool, but used them in parallel for different projects.

The setup is pretty straightforward, if you have a good knowledge about the geographical spread of your clients, so the relays are appropriately mapped.

Understand the requirements and the amount of use before choosing it. If you are just managing Windows machines with the regular MS released updates, than WSUS might be a cheaper and more viable solution. If you are looking forward to a single tool with third-party vulnerability remediation and in-house customization, then this is product is good to go.

SCCM was an option at one point, but we zeroed in on BigFix due to the customization possible.

It is a niche tool with good exposure to required customization and automation, but still requires quite a lot of expertise to handle in comparison to its competitive tools.

Software distribution and patch management are the most valuable. Patch management is the native first usage of this product. Bulletin and Security Update are ready to use. Software deployment is fast and the product can be tuned for poor bandwidth network.

This product has massively reduced the wasted time for a technician to deploy or upgrade a security patch or a software version. With only one technician, you can deploy a large application in less 24 hours (Office, SAP, AutoCAD) in all your computers worldwide. We have used this product to upgrade Office 2000 to 2010 and now Office 365, for 80,000 users.

The console interface is not friendly, and requires training before using it in production. The levels of permissions are too complex to share the product with other teams. The technician must have all permissions to work easily. There is no web interface.

I have been using BigFix for three years.

We had problems with stability from the first use. There was network bandwidth outage when we deployed a huge application or a lot of security patches. This problem was solved by specific client settings and their management, and some changes to the architecture of the product.

Customer service and technical support people have a high level of knowledge. The forum and knowledge database are very interesting and up to date.

I previously used Symantec Altiris v6.5. We stopped using this product because the maintenance cost of the hardware infrastructure was too high. This solution requires high numbers of servers, as opposed to IBM BigFix.

The initial setup was straightforward. Installation was easy and a basic configuration is enough to start to work locally in the same network. But it is more complex when you need to deploy it worldwide.

Our implementation was done through a vendor partner team. My advice: choose a partner with real experience on this product. The settings and design of this product are not complex but require a great deal of experience to adapt it to your IT ecosystem.

I cannot reply about ROI.

I can estimate the reduced cost of servers maintenance to approximatively $500,000.

During deployment and design of this product you must involve the services that will use the product. You have to change the mindset (concept) of your team if you used another product in the past.

• Being able to see inside every asset that we have
• Finding those assets
• Being able to deep dive and pull reports of any kind that we want
• Customizable

If we're looking for some data that is not there natively, we can make it appear in our reports.

We get audited quite a bit because of PCI compliance. There are a lot of requirements that we have to meet on our endpoints to reach that certification for the compliance. BigFix allows us to see the data and remediate those vulnerabilities quickly and easily.

Providing information about areas with room for improvement is tough. I recently attended a roadmap session, and they're pretty much addressing a lot of the stuff we have.

I would like to see more automation, and that's the name of the game. That's our world: automation. I would like to see a way in which we could simplify things even further, so it would be almost like automation on top of automation. It's kind of a funny idea.

But if you have a solution to patch things, then we're going to automate the patching. That makes sense. Then we're going to automate the automation. That's pretty impressive.

When you look at the console of the tool, it is very basic. But basic can be good, too. Too much information is just going to convolute anything. It is just all text-based and it's kind of ugly, but you don't need it to be pretty either.

The stability is great. Any product that can basically run itself, requires minimal intervention, and is self-healing is a great tool.

The scalability is even better because all you have to do is just whip up another server, and boom, you can support another thousand clients. And that takes a whole five minutes.

It's been a few years since we used technical support, but we got direct contact from an engineer right away. He was not just a sales guy, but an actual engineer who came in and worked with us. That was good.

Currently, we have our solution and we put in the BigFix solution. It was all because of the PCI compliance. We got a new security team in and they were completely focused on PCI. The previous solution didn't quite meet the requirements that made it easy. Now with BigFix, it's a lot more straightforward.

The first setup was complex. The second time was much simpler, when we knew what we were doing.

The first setup was kind of wedged in and we had a very small time frame. It was a brand new tool that we didn't know much about. We also didn't know that we had engagement support available to us. That is why the second setup went smoother.

You've got to do a proof of concept and a proof of technology. Get it in there and see what it can do. But more importantly, as you're putting it in, see how quickly you can do it and then see how easy it is to remediate those vulnerabilities. You'll be amazed.

When it comes to selecting a vendor, it's got to be brand. You have the big names: Microsoft, Oracle, IBM, and all that good stuff. But price has to be considered as well. If you can get a great product at a good price, it's very important.

It eases automation. We have been using it to automate Windows. We are currently using it on our AIX boxes to deploy patches; basically, to automate patch installation and OS upgrades.

It saves time and reduces human error. We are still experimenting with more of its features, such as how we can roll back some of the patches that we have already installed and so on. It definitely looks good.

We use it on the AIX. I think it worked fine. I work on the AIX and we are still in the testing period, so it would be interesting to see, if there's an issue with it. But, the team that does most of the automation thinks that it should work fine. Because they didn't see any issues with Linux, they don't see any issues with the AIX either.

Maybe, if they could provide a better GUI, it would be a nice thing to have.

Stability is good.

We're using it on Windows and have used it on Linux. It worked well on Linux and now, we are actively moving to test it on the AIX.

We were using HPE Server Automation, which we were formerly using to automate most of the Linux patching. We were using HPE SA for our automation. It automates but it doesn't have the feature as to where we can back out the patches that were pushed and BigFix offers that to us.

In my opinion, trust and reputation are the most important criteria when selecting a vendor. IBM is known for that.

Definitely, without any hesitation, I would recommend that you should implement and use it. Try it out!