BigFix Reviews

Our primary use of this solution is for endpoint patching and to deply operating system level patches to seventy-five thousand plus Mac and Windows endpoints.

Before we had BigFix, we had problems with some malware. BigFix allows us to immediately patch all instances of endpoints that are vulnerable to antivirus and initiate scans. That's key.

It helps us to compress our patch cycles. With our patches, I can make sure 80% of the community has got their endpoint patching up to current standards, which is a current patch cycle within a week and a half.

Finally, it has helped us to avoid compliance issues, potentially by millions. We use it for device compliance. It's key that endpoints with a certain type of data, if they were to get lost and not encrypted, would need to be reported and those would need to be reported to a federal agency. This can mean associated fines in the hundreds of thousands if not millions. We have lost endpoints with data on there, but because we can confirm with BigFix that they were verifiably encrypted, we are protected and don't have to make those sorts of reports. It has saved us maybe millions in funds.

One of the most valuable features is the ability to be able to check relevance. You can see what's applicable for what patches and deploy only the required patches to those individual endpoints.

The peer to peer file transfers feature is scary to me. I'm a security engineer, so thinking about sending updates or any sort of infrastructure level software communications coming from an endpoint that I didn't build or maybe don't trust is a bit scary.

I want to see a solution for being able to deploy automated software to a Mac running OS X 10.13, something that's going to deal with kernel exceptions and answering prompts for user permissions for data folders and whatnot. They need to really streamline and automate the Mac software deployment.

Stability is totally safe. We've been using it for years and years and it hasn't done us wrong.

Scalability is awesome. We've gone from twenty thousand machines to seventy thousand machines and there's plenty of room for lots more.

Any time I've had to call or take it up with the support at BigFix, I've had nothing but the best support. The engineers get what it is we're trying to do. We've had an outstanding relationship with them, and some of them even know us on a first name basis. Very good support.

The initial setup was pretty straightforward, but that was 2006, 2007. A lot has changed. It would be a little bit more intense right now.

We also looked at Altiris but BigFix came in because of its unique capabilities. It was Mac and PC compliant and worked with our endpoints. At the time, the price was right for us. There was local support and we had a very personal relationship with BigFix.

SCCM will do most of the Mac stuff I want but doesn't give you the highly targeted capabilities I have in deploying anything I want to endpoints in any configuration that I choose.

I would rate BigFix a ten out of ten. It has saved me so much time in patching alone. The capabilities it gives me for very granular targeting of endpoints based on whatever criteria that I can come up with is great. It is very simply a tool that can do just about anything. There is always room for improvement. I want to see better capability in Mac software deployments. Apple changed some of their policies, so I'd like to see BigFix get up to speed with that. 

I would advise someone considering this solution to jump heavily into the community features. The BigFix forums are fantastic, we have an amazing user community that has been so helpful for me and it's a great learning resource for folks who are new to BigFix. It's a great community for people who are more experienced, people share that and help each other out. The community is fantastic.

The primary use case of this solution is for patch management, software distribution, inventory, and power management.

BigFix has helped us to compress our patch cycles. We typically do one release a month. Where we really benefited from this solution is that we now have one to two people whereas previously we would need thirty to forty people taking care of it. That's where we benefited from BigFix the most. We've never had central patching before, so BigFix has improved things quite a bit.

It has helped to reduce software spend. We do have the inventory component, but it's not fully implemented yet. We know that the software does take out certain data and so now we have better data.

We are able to go from patching thousands of machines by twenty to thirty people to one person. 

I would like better support on the backend.

It's stable. We occasionally run into hic-ups here and there. We've been working with BigFix for eight-plus years and occasionally things happen. 

We're in the tens of thousands and we're under twenty thousand endpoints. It's been pretty easy to maintain.

Their technical support can be helpful. We send a PMR and they are pretty helpful. I would give them, on a scale from one to five, with five being the best, around a four.

The initial setup was straightforward on the BigFix side. We had some internal stuff that caused some issues but otherwise it's pretty straightforward. 

We implemented in-house. 

We were looking for something that could run Mac and Windows. At the time SCCM didn't do anything with the backend side. We tried to set SCCM up but it seems to be more complicated than it needs to be. BigFix has one central database and is easier. 

I would rate it an 8.5 out of ten. BigFix has a great community, there's a lot of people that believe in it, it's whatever they advertise, and they listen to customers' feedback. We are heavily on-prem and with BigFix we have that option of staying on-prem. 

Our primary use for BigFix is in the industrial environment, we put BigFix into industrial facilities.

It allows for visibility into the OT, the industrial environments, that didn't exist before which is a big piece and has benefited my organization. Second, the speed at which people can patch is night and day versus SCCM or another similar solution.

When it comes to downloading patches it has helped our network tracking. Our networks are very low bandwidth and very sensitive. For instance, we're running a power plant and that power plant has to be up 99.99% of the time. That network that it's running on was built 35 or 40 years ago, without all the modern technologies, so we can't do it without BigFix.

Many of our clients have compliance requirements that they have to patch within a certain window and so we have to be able to give them data of when the cycle happened and if they complete the patches.

It has also helped to compress our client's patch cycles. For our clients, what was normally a full 30 days of work is now down to a couple of days to get the data in and actually get out and patch the thing. We tuned the BigFix console to enable that a little bit easier so it's a 75 to 80% reduction.

The ability for the agent to be customized, to both, run the fix list and the relevant language, but also to be able to be designed so that it only allows for outbound ports rather than inbound is the most valuable feature. We work in a lot of environments where there are segmented networks and we have to have an agent and a communication where we don't have any inbound ports into that environment. Having that agent be really small, and the ability to not have to have any open inbound ports into that environment is wonderful.

I would like to see different types of reporting and the ability to integrate closer with the cloud. 

It's very stable.

Their technical support is very good. The BigFix community is the best part. The support is nice, but the fact that we've got all those other practitioners out there, that's the best part.

Our clients have definitely seen ROI from using BigFix. 

I would rate it a nine out of ten. Not a ten because the reporting side of things could be improved and I'd like to see how they're going to fit it in with the cloud. 

I would advise someone considering BigFix to look at it and try it. It's really easy to say SCCM is free so you'll just use it but you don't know what you're missing until you actually give BigFix a shot and try it. It's dramatically easier. It significantly reduces the time and effort that it takes to do things and it's more certain. You know what you've got rather than getting in there and guessing each time.

Our primary use case is for content automation and application delivery.

The use of fast query has been extremely valuable providing insight in real time of the endpoints.

Reliability of the agent and the ability to troubleshoot actions after they've been taken are the most valuable features. 

The self-service application seems to need some work to replace the client UI. There are a lot of pop-ups if you use a baseline as the object that you're setting to a workstation. Unless you're using web UI, the message is not customizable in the user notification.

The stability is good overall. 

The scalability seems to be fine. 

I have to contact technical support infrequently, which is good. When I have to use them, I do get responses in a relatively timely manner.

Our previous solution was extremely unstable. We had a lot of downtime and the inability to reach clients. We ended up choosing BigFix because it was already in an aspect of our organization, and so it was easy to adopt for our endpoints.

I would rate it an eight out of ten. The applications are stable, although at times a little dated on how they display information or how they chunk through information. It's stable and it functions.

The best advice I can give is to reach out to the user community when you're running into trouble. You'll find a lot of the answers have already been asked and answered for you on the forums.

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

We use the solution to push patches to our servers, primarily for desktop and server security updates.

We proved the endpoint's effective delivery of software updates and conducted a network inventory in BigFix. This significantly improved the completion status and generated reports on the percentage of patching immediately after Microsoft releases the patches. This report is easily available for our end-user computing platform.

Desktop patching is the most valuable feature, because with servers, we have complete control over them, and we can simply push patches to the servers. However, desktops are one of the most common sources of leakage, which can occur for different reasons if patches are not uploaded on time. We have significantly improved the desktop side of it. This includes endpoints such as laptops, desktops, and other mobile devices.

The deployment has room for improvement and can be more streamlined.

The automation has room for improvement.

I have been using the solution for one year.

I give the stability an eight out of ten.

I give the scalability an eight out of ten.

We previously used Microsoft Windows Server Update Services, but we switched because we could not have a complete schedule for a server to receive updates. We have a few other features in BigFix, such as managing network endpoints, discovering endpoints, and a scanner. All of these features are not available with Microsoft and Linux patching.

It is very important to use the solution effectively. In most installations, we deploy without configuring all the features and implementing them, so we do not gain much from it. Therefore, I think some automation processes can be adjusted to prevent the zero-rate thread.

The deployment phase was somewhat complex due to the need to open many firewalls within the network. Considering the large scale of the company, with fifty thousand employees around the world, I believe that in my previous job, we could have improved communication by reducing the number of ports required for the servers to communicate within the network.

We had a project manager assigned from the BigFix team who listed out all the requirements for effective communication to be established. However, the challenge of implementing BigFix in multiple countries and coordinating with multiple network teams in order to open the required communication between the firewalls was a seemingly hopeless task. If the application uses specific codes that are common in nature, typically those ports are already allowed in the network.

The deployment took us three months.

I give the pricing a seven out of ten. The cost is slightly high.

I give the solution an eight out of ten.

In the deployment phase, we need to get the firewall ports that are required and open ports to the Internet for the DNC-based servers to communicate and download patches. These tasks need to be taken care of during the deployment phase, as it will be very difficult to troubleshoot and fix things once they are implemented. Therefore, the deployment phase needs to be covered effectively. Thinking of the features at a later point in time will not solve all the problems.

When evaluating solutions, there were very few in the market that provided most of the security features. When we evaluated BigFix, it was the VMDR functionality that stood out compared to the others. We would have to use a piecemeal solution or multiple products to be configured in the system. The effectiveness of BigFix was secondary, but we at least had some basic information available regarding security, VMDR management, detection, and response.

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.