IBM BigFix is popular with Managed Service Providers (MSPs) for it’s ability to manage hundreds of thousands of endpoints via a single multi-tennant architecture. BigFix provides MSP’s the flexibility for either centralised or delegated administration models.
Bigfix is typically installed in a centralised architecture as show below. A single Bigfix server is installed at the MSP to manage several clients from one platform. The BigFix server may be installed with Distributed Server Architecture (DSA) for larger environments. Some MSP’s prefer to leverage virtualisation technologies for disaster recovery such as VMware Site Recovery Manager (SRM).
BigFix can manage thousands of separate customer networks (each with thousands of endpoints), without requiring a VPN connection to each client. This is achieved via BigFix relays. A relay is essentially any endpoint but performing some additional responsibilities. BigFix can also manage roaming endpoints which may have left those clients and are working at other remote locations (home, hotels etc).
Top Level Relays (MSP Relays)
To manage these endpoints, the MSP will need to separate the BigFix server from the public internet via one or more relays. These relays can be designated relay1, relay2, relay3 etc. as extra capacity is required. The suggested guideline is approximately one of these MSP’s will support 1000 child relays, which you can think of is approximately 1000 MSP managed customers.
Including another relay for redundancy is good practice. So for most MSP’s with two top level relays, this could support around 2000 child relays (or managed customers). For the purposes of this.. example, I have called this top level relay relay1.msp.com.
At each customer office that will be managed by the MSP, it’s recommended to install a relay. If you don’t, each endpoint will communicate back directly to the top level relays. So there is additional bandwidth requirements. Each endpoint will most likely need to have command polling enabled. So each endpoint ‘phones home’ on a regular basis.
If you deploy a relay, this can be an existing server already in the DMZ (running a range of Windows, Linux or Unix operating systems). The BigFix agent is installed which communicates back to the top level relay called relay1.msp.com. The server relay1.internal.org is promoted as a relay using Fixlet ID 1642 Install IBM Endpoint Manager Relay (Version 9.0.787.0). Check of course for later versions.
Network and DNS Requirements
Ensure you have TCP ports 52311 open at both the MSP and client firewalls. You can check this by performing the following telnet commands:
telnet relay1.msp.com 52311 telnet relaycust1.msp.com 52311
You can also also use a web browser and browsing to the relay’s address and append :52311/relaydiagnostics as shown below:
The MSP should designate the DNS name of the top level relays for client registration purposes (see below). The MSP doesn’t need to define DNS entries for the client relays (such as the name relaycust1.msp.com), although you might simple do this to assist with future network diagnosis.
Endpoints at each of the remote offices need to register back to the MSP’s BigFix server. This is not possible via direct communication. It’s achieved by configuring the remote client to register via a nearby relay. In our example above, this is to relay1.internal.org as detailed in this article. The client then registers all the way back to the MSP’s BigFix server via the relay servers.
Most MSP’s allocate each client a unique Client Identification (CID) as outlined in this wiki article. They do this so all the endpoints can be easily classified and grouped together. Select Computers, Tools – Manage Properties and create the following cid property:
The cid value can be defined at endpoint registration time via a clientsettings.cfg setting. This number can be allocated from the BigFix console, by selecting the server, clicking the right mouse button, then selecting Edit Computer Settings… Then select Add, and enter a setting name of cid and the appropriate number you’ve designated. ie. 0001. Once you’ve clicked ok, it can take a few minutes for this new value to be applied to the endpoint and the results sent back to the BigFix console.
You can define separate administrator accounts to only manage those clients endpoints. To do this, create a local account or LDAP role. Then as shown below, only assign computers that match the appropriate cid value. When the user logs back into the BigFix console, they will only be able to administer computers with the cid of 0001.
As outlined in this article, circumstances may arise whereby the MSP is required to manage and/or deploy custom content for a specific customer. To avoid all customers BigFix Clients downloading and evaluating this custom content, the MSP must create “Custom Sites” and subscribe only the specific customers BigFix Clients to that site. Create custom sites for each client and assign computers to them using the following example:
Also note that by default, the BigFix Operator accounts you create for each customer cid will have no access to the IBM External sites, such as Patches for Windows, Asset Discovery, Inventory & License, etc, so you will need to give “Reader” access for any of these sites that are required by these customer specific BigFix Console Operator accounts.
Running Actions to remote endpoints
With the above BigFix architecture in place, the administrator can deploy a patch to a remote endpoint and see it’s progress in realtime. Here is a short five minute video showing a small Microsoft hotfix being applied to a remote server. Remember that this server is isolated at the remote clients network, and has no direct communication to the Internet or central MSP BigFix server. All communication is performed via the BigFix relays.
You can see how BigFix provides a flexible multi-tenant service for Managed Service Providers (MSPs) without complex networking or server requirements.