We really need a way to push custom(ized) settings with the MSI client installer.
I know about clientsettings.cfg, but that only works with the EXE client installer. I need to use the MSI.
I know about setting registry keys via Group Policy, etc. This needs to be an all-in-one step.
I know that IBM doesn’t support such an action (or, at least, they didn’t in the last mention of this I found from a decade ago). I’m frankly amazed that they don’t have a supported solution for this problem as Group Policy uses MSIs exclusively and newer software deployment tools all prefer MSIs to EXEs.
Anyway … has anyone managed to put together an MST that works to push custom properties to the BigFix Client at install?
I haven’t tried it, but it should be possible to open the MSI in Orca, make edits, save it as an MST, then deploy as MSI+MST.
I don’t currently actively customize an MSI for this purpose but there shouldn’t be a difference between an edited MSI vs an MSI with an MST as far as the actual deployment is concerned.
We do some of this with the tool provided in recent 9.5 builds that has always been used to insert the masthead into the registry inside an MSI that we lay down with the Installation Generator. If you have a tool like Orca or something else that can lay down the correct settings inside the MSI’s registry keys then that would work as well.
I hope in the future to have the ability to use the same tool that will put the masthead inside the MSI to take a clientsettings.cfg and push its values inside the MSI as well to eliminate the need to know how to use Orca etc.
The settings file only works with the EXE installer. In my situation, I have to use the MSI installer.
(EDIT: Rereading your question, the scenario is that we have numerous departments using the system and access to a computer is granted based on the value of a particular custom field. In order to keep the Master Operators from having to manually assign this field a value, the installer should set the value at the time of install. Works great with the EXE and a clientsettings.cfg, but, again, I need to use an MSI file for a particular solution.)
Yeah, we’re good from a masthead standpoint, but we need to set a site-specific organizational value that we use to assign rights, as well as some of the other performance-tweaking values (like RelaySelect_Automatic).
I love the idea of the BESClientSetupMSI.exe ingesting a clientsettings.cfg as well as a masthead file. That would be awesome.
I’m somewhat familiar with using Orca and have tried a few different ways of having an MST add the necessary values, but none of them seem to be working. This is why I was asking if anyone actually has a functional MST.
I had one customer that handled this from a different tact.
They had a flat file that they would update that had computer name/department. The computer would then download the file via a fixlet and then could set the setting automatically.
I has a different customer that used a self extracting zip file and would package the setup.exe and the config file. If I remember correctly you could set the self extracting zip to run with the correct flags so it automatically runs also. That might be an answer also.
I’ve built self-extracting installers (with a clientsettings.cfg) for this before using iexpress, and they work pretty well, but this scenario is MSI or nothing.
The flat-file solution might work in a monolithic IT organization, but we literally have dozens of different IT groups that need this to work, each with one or more different values to set for this field.
That definitely happens. I would recommend editing a copy of the MSI directly for testing, then once you are confident in that, the create an MST and try that.
If you could document some of what you did, and what the MSI/MST contained, that would be very useful. Where in the MSI did you add the settings? (obviously you can obscure any org specific settings/values)
The only truly custom settings are those we use to tattoo the computer with the owner, department, support group, etc. I was hoping to be able to put these as properties on the command line instead of registry keys, but I’ll take what I can get.
Although, having a MSI support custom settings has a good use case, I noticed one of the responders above mentioned setting automatic relay selection settings at install time. Keep in mind, that automatic relay select on install time on a clean install would not be a good idea. You need the new client to register first so that it can pull the relay.dat file. (Otherwise how would it know which relays to search for?). Once it registers and gets the relay.dat file, then you can enable automatic relay selection (assuming you have all the affiliation and seek list settings as well). Many times those settings are already open in a policy fixlet to automate moving a client to correct relay automatically. A better strategy is to point a system to a relay on install time (manual selection), then the system will pull relay.dat and be ready for any relay automation settings. What would happen, if you pushed relay automatic select on a fresh client that hasn’t registered first, is it wouldn’t find any relays (it doesn’t have relay.dat yet) and would try to talk to core Bigfix server, which would be very bad for large organization deployments.
It is possible smaller customers or customers that don’t do large agent deployments in a short time period may not have an issue or notice as the agents would hit the core server, being unable to initially find a relay, they would register and then get the relay.dat and move off to one of their relays in their seek list. Issues would be noticed for large agent rollouts that had relay affiliation settings on install time as it could overwealm the core server by taking up all available Windows TCP sockets. Another possible issue could occur if the core server is not accessible by the endpoints in the field and systems set to auto relay selection on install time would be unable to register since they don’t have a relay.dat file and would be unable to find a relay. In these cases, setting agents to manual selection on install time would be your only course of action or by using a false core which is basically using DNS to point systems attempting to talk to core to hit another relay resolving as the core server that they can access.
