What is our primary use case?
I am supporting a client and serving as an administrator of BigFix. My responsibilities include taking care of the whole infrastructure, patch deployment, vulnerability scanning, vulnerability assessment, third-party application vulnerability mitigation, generating reports, and ensuring compliance with security standards such as the CIS checklist. We handle all the security standards related to BigFix.
What is most valuable?
BigFix has several good features. Firstly, its client on the endpoints consumes less than 2% of CPU memory. Unlike other solutions like CrowdStrike or Tenable, where clients communicate with the database once a day or collect data every two days, BigFix offers real-time detection of endpoints. For example, if we have predefined conditions for monthly OS patches on various operating systems like AIX, Windows, Linux, and Mac, BigFix provides its own external sites where patches released by Microsoft or Mac are stored. These patches and content are integrated with the BigFix network. Each patch or package has relevant conditions that continuously evaluate the endpoints to determine if they are applicable. When creating software packages, we ensure that relevant conditions are met to prevent redundant deployments. This is important as continuous patching without checks can lead to system corruption or device issues.
We are currently managing more than a hundred devices. So, upon creating a package with the relevant condition in place, there are already thousands of devices that have that specific package deployed. The condition checks to ensure that the package is not redeployed to those devices, avoiding any potential issues that can arise from repeated deployments.
In some internal solutions, continuously deploying patches to an endpoint can lead to system corruption, device hang-ups, or other problems. However, BigFix prevents such issues by evaluating the relevance of each patch and ensuring it is only deployed when necessary.
BigFix is an endpoint customer solution that offers various capabilities. It enables compliance management, pack management, software and OS deployment, and power management. You can also integrate One Ready scanning tools like Qualys or Tenable, allowing vulnerability feeds to be directly evaluated within BigFix.
If BigFix does not have a pre-existing solution, we can create our own scripts using its action script and relevant language. The platform supports multiple scripting languages, including PowerShell and Python, providing flexibility for deployments.
What needs improvement?
One aspect that could be improved is the speed of the console. Sometimes it can be slow, which is something that needs to be addressed. When compared to other solutions like Tenable or CrowdStrike, BigFix constantly communicates with the database in real time, which can cause some slowness.
For how long have I used the solution?
I have been working dedicatedly with BigFix for the past five years. We are currently using version 10.0.4 of BigFix.
What do I think about the stability of the solution?
BigFix is stable overall. However, like any software, you may encounter occasional issues, but they are manageable.
What do I think about the scalability of the solution?
It is a scalable solution. Scalability is relatively easy to achieve with BigFix. We already have a capacity planning guide in place that outlines predefined steps to check and scale the environment. It provides guidelines for designing the infrastructure to meet scalability requirements.
Currently, I'm working with a large enterprise that uses BigFix.
How are customer service and support?
The technical support for BigFix is really amazing. There are dedicated technical support engineers available, and you can open tickets or seek help through the BigFix forum. Additionally, there are technical solution architects who can assist you. Just open a ticket with the Excel support team, and they will be there to help you.
The support is generally excellent, but there may be occasional delays due to their workload.
How would you rate customer service and support?
How was the initial setup?
When it comes to the root server, you have the option to use either Windows or Linux. Deploying the root server is a straightforward process. Deploying the root server is the first step. After that, if you're considering deploying the complete infrastructure, you'll need to follow the capacity planning guidelines. It will help determine the appropriate infrastructure requirements. For instance, if you have 10,000 devices, it is recommended to use a server with at least 128 GB of RAM, 32-core processors, and a robust server configuration. You can choose to host it in a cloud-based environment or a dedicated environment, but it should meet the necessary specifications in terms of RAM and processor capacity.
Once you have the server set up, you will define your release strategy. This involves setting up top-level releases and renewal releases. The reason for having multiple releases is to distribute the load and avoid overburdening the root server. Top-level releases communicate with the root server and receive data from it, which they then distribute to the lower-level releases. These releases, in turn, distribute the data to the endpoints.
As for the installation process, it is quite straightforward. Once the root server is installed, you need to install the console. Once the console is installed, you can proceed to deploy clients or agents on the endpoints.
BigFix provides a built-in client deployment tool called the Data Tool. Using this tool, you can leverage your active directory credentials to scan and analyze your network, identifying devices that have or do not have BigFix installed. Once the scanning process begins, the tool will start deploying the agents to the appropriate endpoints. The installation of the agents does not require a reboot. However, when deploying the infrastructure itself, a reboot may be necessary. But for clients deployed on agents or endpoints, whether it's servers, Windows 10 machines, or Linux machines, the agent installation does not require a reboot.
Once the agents are installed, they automatically refresh themselves every 15 minutes. They communicate with the nearest relay to check if any new content needs to be deployed to that particular endpoint. The agent keeps checking with the relay and deploys content if there is any to be received.
What about the implementation team?
For the complete infrastructure deployment, you need to follow capacity planning guidelines. This will help determine the required infrastructure.
Recently, we have set up new infrastructure, and capacity planning is a time-consuming process. Depending on the client and their requirements, it can take a couple of days to two weeks to finalize the agreement, especially if there are cost constraints. Companies often have limitations on project expenses. Once everything is finalized, it takes just one day to get the entire infrastructure up and running.
As for the endpoints, when we start deploying agents on laptops or desktops used by end users (not servers), it can take up to 30 days. This is because the agents are deployed as the endpoints come online intermittently. We keep the deployment policy open for five business days to accommodate this.
So, to summarize, infrastructure installation is typically completed within six to eight hours. After that, the network team checks the network utilization and load, and if necessary, they adjust the bandwidth. Deployment of agents onto clients usually takes about a week, but in server environments with a large number of servers (e.g., 5,000 servers), all the clients can be deployed within an hour or two. Once the entire infrastructure is up and running, we need to monitor the dashboards to ensure that BigFix is performing as expected. This monitoring period lasts for 30 days. Once everything is set up and functioning properly, we can start using BigFix.
For the basic setup of BigFix, you would typically require two architects: one familiar with Windows and another familiar with Linux. Additionally, networking expertise is needed to enable and disable certain ports. The involvement of various teams is necessary, especially the network team, which handles port opening and tunnel creation. For environments larger than 20,000 endpoints, two architects are needed. However, if the environment has around 5,000 to 10,000 endpoints, one architect is sufficient. Apart from the architects, you would also need two sole operators to manage all the modules within BigFix, such as inventory, compliance, cash management, and lifecycle management, which includes package deployment and patch deployment.
Currently, we have two people managing the maintenance of over a thousand devices. However, we recently increased the team to three members. They provide 24/5 support and handle various issues, including configuration and web application problems. If you require 24/5 support, it's recommended to have two architects and two operators who have a good understanding of BigFix. During peak times, the architects are available, and during off-peak hours, the operators can handle the tasks.
What other advice do I have?
I would say that with great power comes great responsibility. As a BigFix admin, it is crucial to be careful and use the tool wisely. You have the ability to bring positive outcomes, but one incorrect deployment can have severe consequences and potentially disrupt the entire network.
Overall, I will give BigFix an alpha ten out of ten.