I’d like to get the communities thoughts on using the Client Deploy Tool and the documentation behind using it.
We’ve recently had a task in our org to get BigFix agents installed on every compatible device possible which for us is amazing however it’s now caused some issues due to missing parts on the documentation etc…
As you can imagine, this was a massive problem. If we are logging on to servers to add the reg keys and also then reboot it, we’d be as well to just manually install, right?
I considered a GPO push to add the reg keys at the domain level however we have a very large number of domains and this would cause problems in itself not to mention it not resolving the reboot issue.
Ultimately I’m now at a loss…
As an organisation who WANTS to deploy BigFix everywhere, we now can’t without involving a number of other teams, engineers and raising more changes than we would ever be able to manage.
What’s your thoughts on this as a community? Have we missed something or is there a better way of doing the mass roll out? Have you been a successful user of the CDT on mass?
That’s a tough one. By default the administrative shares should be present, and they’ll definitely be required in order to “reach out and touch” the remote system to install the client. Where administrative shares are blocked, I’d also expect it to be questionable whether remote RPC is allowed either, which would throw another issue into the mix.
Do you have any other shares that are “standardized” in your environment, such that if we used some other share instead of C$ that it would be fairly reliable across the environment?
I’ve used the CDT at scale in several customers and for the most part, “it just works” but we also frequently have to use other tools instead for mass deployment - either because the admin shares or RPC is blocked, or systems are isolated behind firewalls, or the BigFix people will not be allowed endpoint credentials, or anything along those lines. So, we do have several strategies you might consider. In your use-case you already mention possibly using Group Policy to deploy the registry keys to enable admin shares; I think using a GPO to deploy the BESClient MSI package may be a good fit.
GPO-based deployment to the client. This is probably the most-often used method.
** The BigFix Installation Generator builds a custom version of the ClientMSI installer that includes your deployment’s masthead file. In many cases you can just put that installation into a Group Policy deployment and expect it to work.
**In more complex scenarios, where the client may not be able to reach the masthead server name, you’d need to configure things like Relay Selection; while we don’t support using a clientsettings.cfg with the MSI package, it is possible to modify the MSI (or generate an MST) using the ORCA msi editing tool from Microsoft. We have blog postings on that, I can help find if that’s of interest, but I don’t know whether we’ve published an official KB doc on it yet.
Use any deployment tools that were there before
** Often, a new BigFix deployment is displacing an earlier management tool. Before we decommission that tool, we might use it to deploy the BigFix client, and then use BigFix to remove the earlier tool as part of the migration.
Custom Scripting
** If we have remote RPC access but otherwise can’t connect to the admin network shares; or, if the person deploying the clients does not have BigFix operator accounts and can’t use the wizard, it’s fairly common to build custom scripts to download & run the installer remotely. Often we’d leverage something like ‘psexec’, PowerShell remoting, or the Task Scheduler to make the remote machine execute the installer.
Use the tools we don’t usually think of
** Often there is some tool deployed that has the ability to remotely run commands, even if that capability is not often used. Symantec Antivirus is one example that I’ve used in the past. We can leverage those tools to run commands on the endpoints to install BigFix clients on them.
Wheee-doggy. The answer is “sometimes”. CDT inherently has a lot of dependencies for network paths and access which may have been already closed off due to security concerns.
We’ve found that if it works, it works. But if not, it can be hell to discover and clear the bottlenecks.
A comment on producing the MSI, we do provide a tool that by default puts your masthead into the MSI but it can also do other things which help in this specified case.
Nice! I knew we could embed/change the masthead, I didn’t realize it supported secure registration and relayserver options - that at least covers the most-common needs I think.
The first time installing BigFix, one would use the “Installation Generator” to create the Server, Relay, Console, and Client Installer packages that are used for the initial install. By default those would go to C:\Program Files (x86)\BigFix Enterprise\BES Installers.
Through each upgrade your system should be relevant for the “Updated Installation Folders” fixlet from the BES Support site; but if you’ve migrated hardware you may not have the installers on your server anymore.
You can always download the Installation Generator from https://support.bigfix.com/bes/install/downloadbes.html but be aware of some nuance to the downloads. You’ll need to visit the “Version X Release Page”, because the install package on the front landing page is just the Server package (expecting you’d use Fixlets for the rest of the upgrade):
When you run the Installation Generator, it will ask for your masthead file (ActionSite.afxm) to be integrated into the installer packages it builds. The ClientMSI folder it creates includes the BESClientSetupMSI.exe that Alan references to customize the MSI package.
Ah, I found Brad Sexton’s blog post describing using ORCA to customize the MSI package, which should also work for the 9.5.14 installer (assuming you need more than just the masthead added to it)
If all you’re doing is adding the masthead, the Installation Generator graphical interface has already done that - you’d only need to do that yourself if you’re managing multiple deployments and need to keep separate installers for each masthead.
Does anyone know if we can get the MSI to silently install? From what I’ve tested it seems to launch the installer which is not any good for a deployment via GPO
