We are an MSP with a 130+ customers and tens of thousands of systems. Multi-tenancy is a beast with every customer having unique needs and being managed by hundreds of Desktop and Server System Admins. Automation is key and we are currently managing all daily patching activities with just two full time employees.
Each of our customers have a site for just their systems and unique customer policies. Customer systems are Identified by an Entity ID and added to the site with that ID. Each customer has unique policies which covers their unique needs.
Outside of patching, we are also managing security tool installs as well as configuration settings for vulnerability management and hardening.
This tip is how we automate security tool installs with BigFix to replace GPO software installs. Many customers are moving away from installing tools via GPO for several reasons, including many systems not being on the domain or are full time, remote, off the internal network.
We have a global policy for the tool deployment with relevance that a certain registry key must exist with a certain value, in the registry. The policy is always running dynamically. To make a system applicable we simply add the key to the system.
When we onboard a customer, we deploy the key to a few systems at first, as a test. Then we add the key to the customer custom policy so all new systems that call in get the key, and therefore the tool.
Most BigFix client installs are automated, through a GPO and remote install, using a script. The GPO is unavoidable but with BigFix installing other tools, this may be the only GPO install in the environment.
I am often asked we don’t use the unmanaged assets and client deployment tool. With 130+ customers, and 150+ domains, each having unique user names and passwords, the necessary access to the environment to install anything is untenable. We do setup a GPO for BigFix client install that runs from the DFS. The script has some AI in it to build the clientsettings.cfg on the fly, to find known good relays and add the customers Entity ID. When we have a new agent version of a new version of the script, we update it with BigFix. No need to log into the customers environment.
I also have a policy in place to copy the ActionSite.afxm file from the local client folder (On DCs) to the DFS when the date is older, to keep it up to date.
The customer specific dat file contains the customer’s relays, domain and entity ID. The install script uses the relays from the list to check to see if they are responding and have the port open. It also checks the domain the system is on compared to the domain listed in the dat file. This is a failsafe to prevent a customer dat file from one customer being used at another customer. If the domain is the same, the entity ID is added as a client property so when it calls in, it will be added to the correct customer site.
I have a lot of “multi-tenant” oriented processes and configurations. It is critical we do not allow a system from one customer to show in reports for another customer. As I said, multi-tenancy is a beast.