BigFix Reviews

It's mostly patch-inflated. For the company I currently work for, we manage about 7,000 servers, and we use BigFix Enterprise to do most of the relevant software updates and patches to stay within compliance and away from vulnerabilities for many of our product users.

I'm not sure how the company functioned before. I'm fairly new.

The product is easily accessible. We already did the network setup and things like that. It is to manage servers conveniently throughout the company if it's already listed on BigFix. Where it has the BigFix client on it, it's just a matter of sending the patches and waiting for it to run.

We have the management side of BigFix as well. Most of the time, we typically don't have any problem, however, every once in a while, we try to find out why a patch didn't work, and things like that. It helps us keep on top of things.

BigFix has always been easier to use when managing servers, especially when you deal with so many servers. We have 7,000. That's a lot of services to manage, and it's convenient to patch them all at once.

It's easy to set up. 

Once in a while, some servers don't get patched, usually from our end of things. Maybe a server hasn't been reported in the last few weeks, and we don't know whether that server has been decommissioned or not. That's not on in BigFix in particular.

The relevant language takes a little getting used to since it's not used anywhere else in the industry. It's just in the BigFix environment. If there's anything that could be improved, it would be making the relevant language more readable and more common. 

We'd like the solution to be agentless, similar to, for example, Ansible. 

I've used the solution for six months. 

It's been around for a while, according to what I've seen. It used to be an IBM product before the move to an HTC, so I'm pretty sure it doesn't have a lot of complications. It'll still be a pretty stable product moving on into the future.

For now, it seems like BigFix has been the most popular for server management.

Considering the fact that the company I work for is pretty big, if that's the product they're using for their server management, I would say it's offering pretty good scalability. It's a very scalable application for managing servers. Some people use it for one or two servers, or maybe 30 or 40. We use it for pretty much all the servers managed here, and to my knowledge, that's about 7,000. It used to be 10,000. However, we decommissioned a bunch of irrelevant servers.

We do not plan to expand usage just yet.

We talk to HTC from time to time. We do lunch and learns with them and take most of our questions directly. They're quite easily contactable for the company to reach out to and set up a meeting, and they're usually very helpful. They're a great resource.

Positive

I did not previously use a different solution. The company's been around for a long time, and it seems like everybody's just known BigFix to be one we used. I'm a bit newer to the company.

The implementation was fairly straightforward. Documentation was online, so you just have to read it and follow instructions. It's pretty straightforward.

The deployment strategy more or less depends on our current environment for the company. It took me a while, not due to BigFix, just due to the company restrictions for onboarding employees. You have to have permission to access this and that. So it took a little longer than it would if it was on a local system, my private system, or something like that. 

Currently, we have two teams that can handle deployment and maintenance. There are those on the Window side, for managing the Windows servers, and there's the Linux OS applications team. They both pretty much do the same thing for two different operating systems.

The deployment was handled in-house. However, we are looking to try and automate more in Ansible going forward. 

I don't deal directly with licensing. 

My understanding is that it is  affordable. We have had conversations about other licenses, and other applications like Splunk, and we know that one is more expensive. Pricing hasn't been anything that's even come up in conversation.

While we are using the on-premises deployment, we are moving towards the private cloud. 

I'd advise new users to read a lot of the documents before subscribing to their licensing. Read much of the documentation and know what use cases would work for you. Before you get into it, try the trial version, as it might help to test it out to see what it is.

I'd rate the solution eight out of ten. 

Our primary use of this solution is for the server side patching and compliance remediation. We use it for all of Windows server patching, remediation, vulnerability scanning, and inventory management of IBM licensing.

We're able to single console manage all departmental Windows, Linux, AIX servers, and from a single console, we can grant access via role base depending on department status and access. It's just easy to get a big picture on a single screen.

It reduces network traffic when it comes to downloading patches. It's a single patch repository on the root server, all patches start on the root server, and then they are disseminated via relevance as required, up above a chain and a single connection via the relays up until it gets to the bottom of the last relay and then it disburses to the client. Storage and network wise, it makes the smallest download possible down to the last band and then disseminates from there, so you can take your relays as far down as possible to make a small download chain size wise. 

We use it to compare current and past patch cycles. We do monthly compliance verification and we use external vulnerability scanning, and we compare that to the BigFix compliance results and make a mesh of the two for our monthly reports for executives. We do that on a monthly basis.

It has helped us to compress our patch cycles. It's been condensed 100 percent. Our patch cycle is now under 10 days for everything that we patch, and we get no complaints from our compliance people about that. They've given us requests and we recondense it. Depending on how much urgency we put on it we can take it down as much as possible.

Finally, it has helped to reduce help desk calls. We actually know if there's an issue before the help desk finds out. We'll report a server down sometimes before the server owner knows, and we'll let them know that there may be an issue and then we can actually roll back a patch via BigFix before the server owner knows that there's an issue. Altogether, help desk calls have been reduced by around 50%.  

Some of the most valuable features are its: 

• Ease of use
• The fact that it's a single port access across the board. There's only one firewall to be required.
• The user community is great, very helpful. 
• There's not a lot of overhead to the client. There's a bit of set up to do but it's pretty simple once it gets running to maintain it. It basically maintains itself. As such for as big of a system, it only requires a little manpower. There's only a couple of people that have to manage it.

My impressions of peer to peer file transfer in relation to BigFix, is that it's a relay structure that goes up and down the chain, as servers check in they check into their relays, the relays pass up and down the chain. It has tight security. They say it heals itself. It doesn't put a load on the system and doesn't give our guys any headaches or anything. It just seems to work pretty well and it's easy to maintain.

I'd like to see:

• More visibility
• Better reporting
• I'd like for it to be more futuristic, for it to be less plain Windows looking with a little more pizazz. 
• Better integration, with the different applications within BigFix. Instead of sometimes feeling like four or five different applications, they need to be integrated a little better within themselves. 
• Better folder structure internally.

I've been admining the system for two and a half years now and other than server side issues we have never had stability problems. My core system is four servers and they're not maxed out. We've never had any performance issues.

Scalability is amazing. We have over 10,000 systems and could easily add to that without a performance hit. We'd have to increase our relay structure to keep it manageable but I don't think we'd have any problems.

Between the user groups, the community, the AVP support, the direct access via technical route and the PMR support, half the time I don't even need to do a formal PMR because the solutions from the community resolve whatever issues we're having. It's the best community and support based system I've ever used.

We implemented in-house. 

The main reason why we chose BigFix is because at the time we were looking for a single solution for multiple OS, and SCCM at the time couldn't handle a Windows, Linux, and AIX coverage as BigFix does. I haven't directly managed SCCM myself, but I do feel that BigFix is a much simpler set up, simpler configuration. It's better accepted by our marketing solutions, to get into some of the restricted VLANs, we have a much easier time connecting to restricted LANs than they do. BigFix has better reporting, they're just better integration. The one part where I think SCCM is better is in the remote control. The BigFix solution remote control is a little dated. 

I would rate it an eight out of ten. An eight because of the stability and the ease of use. Not a ten because I'm looking for more modernization, but I do have to give the BigFix community credit because they seem to listen to us.

I would advise someone considering this solution to talk to the community. Talk to the BigFix users, ask their honest opinion on what they think is good and bad about it. 

We use the solution to manage servers in the data center. Then the other client monitors the server, including Windows 10.

BigFix is integrated with the development process, making it easy for developers to remediate vulnerabilities directly from the outside.

Some clients have adopted it but have expressed concerns about its flexibility. They have other tools that effectively address this flexibility. BigFix offers basic vulnerability management capabilities, but it lacks integration.

I have been using the solution for eight and a half years. We are using the V10 of the solution.

The product is stable.

The solution has high scalability. Most of our clients are the big ones like National Banking.

I rate the solution’s scalability a nine out of ten.

There have been some technical issues that have required us to contact support. Support has helped troubleshoot and fix these issues, but it can sometimes be a problem, depending on the case.

Positive

The initial setup is easy and takes an hour.

The tool offers a good return on investment. There are many defects, but it can provide solutions for the company.

The product is affordable. I rate the solution’s pricing a three out of ten, where one is cheap, and ten is high.

BigFix provide a comprehensive set of device monitoring features. BigFix can monitor not only the device's hardware and software, but also its security posture and performance. This information can be used by the IT team to troubleshoot problems, improve performance, and maintain security.

Overall, I rate the solution a ten out of ten.

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

We use BigFix for deploying applications for updating, setting up configurations, making modifications, or customizing Windows. For example, what are the applications that need to run, and what configure is needed.

The most valuable point is when you deploy an application, you have to make sure that the application has been deployed to all computers and that is working perfectly. This solution works well at deployments. 

Other solutions can have failures, such as ManageEngine, and you have to deploy the application again. In BigFix, once the computer has communicated with the BigFix server, the agent workstation, you can be sure that the application will be deployed and delivered properly.

Sometimes the workstations communicate back to the BigFix server two or three days in a week or something similar. Sometimes there can be a delay reporting back to the server for a variety of reasons, such as users turning their computer off when they go home. When the user comes back and turns the computer back on BigFix needs to synchronize and sometimes it can take some time, approximately one week. The communication between the agent and the server should be faster, there is room for improvement in this area.

I have been using BigFix for approximately two years.

BigFix is reliable and stable, it is perfect.

Performance-wise is the best. When you have to do deployments you are sure that all the workstations will receive it, even though that there is sometimes a delay in reporting back to the server. The only time the deployment would not work is if the computer is decommissioned or not available.

BigFix is simple to scale, we are using the solution regularly. We use it every other week whenever we have meetings, we rely on it.

We have approximately 10 technicians and 3,000 users who receive a patch or use the solution in some way.

We have not had any big issues that would need the support. However, we did have some minor issues and the support was good and responsive.

I have used ManageEngine previously.

In my usage, I have found BigFix is more professional than ManageEngine. The reason that I'm saying this is when you deploy an application, you are sure and you are guaranteed that all workstations will receive it. However, for the ManageEngine, for some reason, you will find it may fail for 13 workstations. You might have to redeploy again, otherwise, you have to do it manually.

One of the positives of ManageEngine is it can be easy for users to deploy an application compared to BigFix.

The deployment process of BigFix was straightforward. You need to have a small number of programming skills or scripting skills to complete it. If you have skills, it is very easy to deploy. For somebody who's experienced, and has knowledge of some programming or scripting skills, it's very easy.

There were approximately three people, the vendors, and our technical teams that did the implementation.

BigFix requires specific maintenance, whenever there is a new release we manage it.

You are charged per server and per workstation when using BigFix. ManageEngine is a lot cheaper than BigFix. There are some additional costs, such as support.

I recommend BigFix as long as they have the budget. If they don't have that much money, they can use ManageEngine, which is satisfying for small and medium companies. For example, companies that have 250 computers. I have used ManageEngine at companies that had multiple locations. You can use some ManageEngine on one central location and then deploy it to all your branch offices.

I rate BigFix a nine out of ten.

I have used BigFix for patch management, compliance for security, and inventory OS deployment to software.

The most valuable feature of BigFix is the software deployment.

The solution could improve by adding support drivers for different systems and equipment. When you have a lot of different computers if they could fix how to install any updates, firmware, or drivers for different systems or servers it would be good.

In an upcoming release, they should add database support included and deliver the solution as a cloud service similar to the services on Microsft Azure.

I have been using BigFix for approximately 10 years.

BigFix is extremely stable.

I have found BigFix to be highly scalable. BigFix can be used on 10 computers, 10,000 and 1,000,000 computers. It doesn't matter the number of computers.

We have approximately 50 people using this solution in my organization. We use the solution daily.

BigFix is suitable for both SMB and enterprise customers.

The support from BigFix is excellent.

I rate the support from BigFix a five out of five.

I have used other similar solutions previously. The main difference between the other solutions and BigFix is you can do more for a lesser price with BigFix. You can do more with less effort to get it up and work properly. Its broader support for different OS systems.

I rate the implementation difficulty of BigFix a five out of five.

If you choose, for example, Microsoft SSM Configuration Manager, you need a lot of servers, databases, and the configuration of firewalls, et cetera. It's a tremendous cost before you get up and running. With BigFix, in 10 to 15 minutes, you're up and running. Everything is working well.

The price of BigFix is better than the solutions. You are able to pay monthly or annually. There are not any hidden costs with BigFix. There is an additional cost for the SQL database.

I rate the price of BigFix a five out of five.

I would recommend this solution to others. I would advise others the solutions are suitable for small to medium-sized companies, and enterprises.

I rate BigFix a ten out of ten.

We are using BigFix for sending patches to our servers and desktops, such as security and regular updates.

BigFix has enhanced our organization by demonstrating its efficacy in delivering software updates to endpoints. For example, Microsoft releases patches and we are able to easily make them available for our end-user computing platforms. Additionally, by utilizing the network inventory feature in BigFix, we have been able to substantially improve error percentages and completion statuses, and generate reports on patching percentages within a day and subsequent weeks.

The most valuable aspect of BigFix is its ability to patch desktops. While we have complete control over servers and can easily push patches to them, desktops pose a greater risk for leaks and vulnerabilities if patches are not installed in a timely manner. By using BigFix, we have significantly improved our ability to patch desktops, whether they are laptops, desktops, or other mobile devices used by end-users.

In order to derive maximum benefit from BigFix, it is essential that we configure all of its features and implement them effectively. If the automation could be improved we would be able to mitigate the risks associated with zero-day threats.

I have used BigFix within the last 12 months.

The solution is stable. The primary role of the solution is to patch the systems to the latest released security updates. We have not had any issues once we had deployed the solution correctly.

During our exploration of available solutions, we found that very few in the market offer comprehensive security features. In our evaluation of BigFix, we were particularly impressed with its VMware functionality, which far exceeded that of other solutions we considered. Rather than having to configure multiple solutions, BigFix provided us with basic security information and VMware management detection and response all in one. While the effectiveness of BigFix is certainly a key consideration, its ability to consolidate security features was a major factor in our decision to choose it.

I rate the stability of BigFix an eight out of ten.

I rate the scalability of BigFix an eight out of ten.

I rate the support of BigFix an eight out of ten.

Positive

We were using Microsoft SCCM prior to BigFix. We switched toBigFix because we wanted to have a complete solution. Microsoft SCCM was lacking features, such as managing the network endpoints, the discovery of the endpoints, VMware functionality, and Linux patching.

The deployment of BigFix is complicated. There are a lot of firewall ports that need to be configured and with a company with 50,000 employees, this can be a challenge. The configuration could improve by being more streamlined in the future.

We were assigned a project manager from the BigFix team who provided us with a comprehensive list of requirements for establishing effective communication. However, implementing these requirements across multiple countries and coordinating with various network teams posed a challenge, particularly in terms of opening the necessary communication channels through firewalls. This was a daunting task, especially if the application utilizes codes that are commonly blocked by firewalls.

The full deployment of the solution took three months.

The price of the solution is high. There are not any additional fees from the standard license.

I rate the price of BigFix a seven out of ten.

For those considering the use of BigFix, my advice is to pay close attention to the deployment phase. This involves identifying the necessary firewall ports and ensuring that the servers are configured to communicate with the internet to download patches. Proper deployment is critical for ensuring smooth operation in the future, as troubleshooting can be difficult once the solution is fully deployed.

I rate BigFix an eight out of ten.

It matches with the ILMT tool. We're trying to validate the licensing for IBM software. 

We're using the permanent discovery tool for septic for hardware and software too. For IBM, we have to use that due to the reporting of sub-capacity licenses.

It's mostly easy to use.

The sub-capacity licensing is the most valuable aspect of the product right now for us. 

It's good for reporting hardware and software. 

The solution is stable.

Technical support is helpful.

It scales well.

It's got some complexity when we're trying to figure out the IBM setup for software.

The sub-capacity licensing was a challenge for some of it. We had trouble getting it to calculate right.

It's better for hardware discovery. We get to increase its capabilities for hardware discovery. They need to enhance their sub-capacity capabilities, so we can use it easier for sub-capacity so that it is less of an art form and more of a science.

We'd like agents to be able to collect usage.

I've used the solution on and off for about eight years or so. I've used it for quite a while now. 

It is stable and reliable. There are no bugs or glitches. It doesn't crash or freeze.

The solution has scaled well for what we are doing. 

Technical support has been very good. Sometimes they can't do things if it is not a function of the system; however, if the function of the system is possible, they help us and make it work. We are satisfied with the level of support we get. 

The initial setup was not overly complex. The complexity was the handling of configurations. 

The pricing was good. We had government pricing going into the project and it was pretty fair. 

I am using the latest version of the solution. I am not sure of the exact version number. I help different companies. Some are on the latest, and some aren't.

I'd advise people to understand what data they need and that the solution can actually pull that data in the right format for them.

I'd rate the solution eight out of ten.