BigFix Reviews

• 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”.

• 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.

Our primary use case of this solution is for endpoint management. 

Prior to BigFix we used Altiris, which was distributed. We had to manage multiple servers, and duplicate the tasks that we did on each server. BigFix tremendously reduced the amount of work that we had to do on each server in a centralized manner. We could minimize the work that we had to do, and we had a lot more control over the tasks and what machines they ran on.

It has helped to reduce help desk calls by 60-70%. Using the self-service portal allows our users a lot of access to fix their own problems as far as errors, as well as policies that auto-resolve issues as they come up without the user even knowing.

Finally, it has helped us to avoid compliance fines in the tens of thousands of dollars, if not more. We've used it for software audits numerous times and saved significant amounts of money with being able to clearly identify what machines have what software, then verify that we're licensed for the software that we have.

Power to query anything on the machine servers and problem resolution is where we find a lot of value in being able to turn around and find a fix, and identify machines that are having an issue, and being able to resolve that.

I believe that the peer to peer file transfers feature will speed up the time to get files to individual machines. I haven't used it myself, but I think that as far as clients go, instead of having to use one server for that, being able to get that data from their clients will be a lot faster and more efficient.

I would like to see for it to be a little easier for new users to be able to learn and create relevant statements. In my opinion, that's the hardest part for bringing on new people that haven't had BigFix experience. Being able to have easier ways to build relevance in ActionScript would be the biggest improvement I'd like to see.

It's very stable. There's minimal maintenance on the server infrastructure itself.

It's very scalable. We've had mergers that have come in and put a relay out there, and immediately get the information back for their clients. It's very scalable, we don't have to worry about putting too much burden on our other servers.

Their technical support is very good. 

We switched to BigFix mainly because of scalability and for centralizing the work that we did, rather than being distributed. From what I know of SCCM, and the little that I've used it, the granularity that relevance an ActionScript allows you over the endpoint, and the information coming back from the endpoint is fairly significant compared to the work that you would have to do to script all that out in SCCM to get that information back.

I would rate it an eight out of ten. Not a ten because of the training aspect of getting new users up and going on the technology. That would be the only downfall because it does take quite a bit of time to train new users. As far as the power, it's by far the best.

If you're considering BigFix look at the power that it allows you to have visibility into your system. If you don't have visibility into your systems, it takes a lot longer to get something resolved. Whereas if you can instantly get that information back from your client that's having a problem, being able to know that that issue needs to get fixed on that client's machine and being able to fix it instantly, could save you hundreds of hours.

Server management patch management and software deployment, where we have multiple platforms, such as Windows Servers, Linux, Unix, etc.

• Patch compliance reached 100%.
• Patch management, because it significantly improved the patch compliance.

Patch management, because it very much improved the patch compliance and has the capability to manage Windows and non-Windows clients.

• OSD and other features listed in SCCM, like desired configuration management
• Internet-based client management
• Offline patching of virtual machines
• Network Access Protection (NAP) technologies to prevent computers with vulnerabilities from gaining access to networks.

I'm a full stack developer and we are customers of BigFix. 

All the vendor patches are synchronized automatically, which is something you don't find in other tools. It enables an unlimited number of management fixes to be created automatically. For software deployments and software package staging, we can easily use a web script and deploy directly which is another great feature.

Improvements can be made when it comes to in-place and OS upgrades. For example, SCCM provides a feature upgrade that's automatically synchronized, whereas in BigFix it doesn't synchronize for feature updates for Windows 10.
I'd also like to see some more advanced reporting tools. 

I've been using this solution for about four years. 

The solution is generally stable although sometimes our customers will report some issues and it's not always easy to find the source. 

The scalability is fine. 

We don't really use customer support. We have enough knowledge for reporting and deployments, and we have a TRC that allows us to access the remote of the end-users and check any problems. 

The initial setup is straightforward. 

If you compare BigFix with SCCM, both have their own specialty tools. In some cases, I prefer BigFix and in others I prefer SCCM. If you're talking about patching, I'd go with BigFix but if it's connected to image management, then I'd go with SCCM.

I rate this solution seven out of 10. 

We rely on BigFix to provide patch remediations in conjunction with instant response engagements that we have. Once CyFIR finds a problem, we tend to leverage BigFix to automate the solution across the entire environment.

We rely on BigFix as part of our consulting engagements. It's more efficient from a visibility and discovery standpoint on the initial phase, the consulting engagement. It also increases our efficiencies on the remediation phase of our engagements. 

We use it to compare the current state of patch and diff that with where it should be and to also push CVE patches and things out that are specific to a problem we have found. 

The combination of CyFIR and BigFix has allowed one of our major customers, one of the top Fortune 50 financial firms in the world, to reduce their forensic investigator count by about 4 FTE with the combination of CyFIR and BigFix.

Compared to SCCM it's much more robust, much more capable, and you can be much more targeted with SCCM. The challenge with SCCM is it doesn't have much of a discovery module so if we're going in blind to a network, we really want to know what's there, not what they think is there. BigFix provides us that picture.

With BigFix, the ability to do device discovery and the installation of our CyFIR agent across the environment is a very autonomous, automatic-type function that is a very significant feature for us. We combine CyFIR and BigFix to provide a total cybersecurity solution, including computer forensics disk imaging, memory analysis imaging. As part of that, we tend to leverage BigFix from the remediation side and from the installation side. 

The peer to peer file transfers as a solution are fine. 

I'd like to see better API integration with BigFix. We have some tremendous API capability inside of CyFIR and the ability to take textual search results, for example, and bring that back into the BigFix dashboard. This would be of extreme interest to us and our customers. 

It's very stable. 

Scalability is very good. 

Their technical support is very responsive. 

We're always looking for innovation and the most efficient and effective way to serve our client base. BigFix came up on our radar as part of that continual enhancement search.

From our perspective, it's pretty easy engagement. It's not just for our network, we use this for our engagements with our clients so the complexity is typically not introduced by BigFix but by the customer client networks and their specific requirements.

We implemented it ourselves. 

The fewer consulting hours that we spend is ROI for us. BigFix enables us to produce maximum results.

I would rate it a 9.5 out of ten. It's pretty close to being perfect. It's stellar.

For me, BigFix is my virtual operator, and the capabilities BigFix actually brings to our servers to do everything. I don't need a personal operator. I can reach out to our partners for the solution.

BigFix enables us to handle data from many vendors with the scale for our servers, improving our performance.

We are looking for better images for third-party operations like article databases, for example, other article application servers, and the SAP applications. We appreciate that BigFix can produce a better image for everything on a single product.

Also, the web console could be improved as we need to use it more than the desktop console.

I believe the solution is very stable and we have never had an outage of the solution. Communication with our agents is always well-synchronized. Stability is very nice.

It is scalable. We have, for example, 7000 servers communicating with only three or four structured servers on the BigFix environment and it responds very quickly for everything we do.

We usually use the technical support for some troubleshooting when we have a specific problem with agents because in an environment with 7000 servers, we have a certain rate of problems which are specific problems, not general problems. Every time, the support attends to us quickly and the success factor is high.

See if the solution has good capabilities for them and if the solution can communicate well. Integration with many vendors is necessary.

Our primary use of this solution is for patching all of our systems and maintaining their security compliance.

It enables us to patch our systems quickly and within expectations and to increase our volume as needed. It has also helped us compress our patch sites. We used to do it monthly but now we do it weekly.

Compared to SCCM, I always feel like I'm fighting the tool. I do not feel that way with BigFix.

The ability to build custom content and scale to additional endpoints without increasing staff time is the most valuable feature. 

I'd definitely like to see additional feature parody in the web UI versus the console. There are certain things that you can only do in the console and they're very cumbersome to do, like secure parameters, for example. That's definitely something that has a wide degree of utility but it needs to be easier to surface. At this particular juncture between the transition, between the Legacy console and the web UI, it's hard to justify dealing with the cumbersome aspects of the Legacy console when theoretically everything's been through the web UI.

Stability is very good. We have no issues with it.

Technical support has always been useful and they have always ultimately provided a solution.

The initial set up was very simple, single server. We've since grown to a server plus an array of relays and we even use relays to get into some difficult to reach network areas. It's been pretty useful.

We implemented in-house. 

I would rate it an eight out of ten and I'd advise someone considering this solution to start with one relay. Remember that it is a root shell robot. If you can do it on the shell you can do it with BigFix.