Tips On Deploying a .pkg file which needs settings .ini to go along

New Contributor III

I am looking for a solid process that works for deploying a .pkg application via Casper which requires an .INI settings file to be ran along side. The .INI file contains the settings needed for the application to point to the correct server when installation completes. The application in question is Carbon Black.


Legendary Contributor III

Seems like something very similar has already come up today on this discussion:

Look through those posts to see an example of how to do this.

Contributor III

Hi @bjones,

Does the .ini file need to be used during the installation only, or ongoing by the App?

If it's the first, you can use @rtrouton's Office deployment workflow blog, and adapt it to run your install.

If it's the second, I imagine (but test!) you just need the file to be on disk somewhere that the App expects it (maybe /Library/[foo]?). If so, just create a second package with this file to put it in that location.

Hope that helps!



@bjones where you able to come up with a solution to deploy the carbon black pkg?

if yes could you please share your solution.

thank you.

New Contributor III


Hey hope all is well... Back when we were using the carbon black application i created a .pkg that went in and placed the files into a tmp directory and ran the executable next to the place .ini files. Once the application was installed and running i place the objects in a smart group referencing systems with com.carbonblack.daemon service running. And to clean up this process i had another script to remove the files that were placed in the tmp directory for installation purposes.

New Contributor III

Hi @bjones

When we have had to deploy things like Carbon Black we use @rtrouton 's method for deploying. Using Packages, drop the script in the "Additional Resources", then use a postflight to call the installer. You don't need any manual cleanup, as the install process will clean up the temp files for you. This way you can also keep your own version history and you can use that to target machines that need newer versions if necessary.


Perfect, thank you everyone for their responses, that's what I was looking for...thanks!

Contributor II

you can just zip the files and deploy it like any other

Hi prbsparx,

could you explain how?

New Contributor

This worked perfectly, thanks.