What is most valuable?
- 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.
How has it helped my organization?
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.
What needs improvement?
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.
For how long have I used the solution?
We have used this for seven years.
What was my experience with deployment of the solution?
No. Deployment of the server, relays and endpoints is very simple especially compared to other products that I have worked with.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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).
How is customer service and technical support?
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.
Which solutions did we use previously?
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.
How was the initial setup?
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.
What about the implementation team?
This was implemented in-house.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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).
What other advice do I have?
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”.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Nov 01 2017