Managing software installs using JSS

[J_Martinez]

Hello admins,

I'm relatively new to managing macOS, but have been slowly learning JSS and using it to deploy policies to workstation. We are currently using K1000 to install applications to clients, however i would like to start using JSS for this.

My questions is how do you manage application deployment on JSS? Can you configure JSS to not re install the app every time it checks in? How do you manage patching applications?

I'd be happy if anyone could point me in the right direction. Thanks

[Asnyder]

As far as reinstalling just set the policy to recurring checkin and set it as once per computer. As far as updates go, you can either write a script or find one online that will keep the software up to date, or just push out another policy to install whatever version. typically I stay a version or two behind depending on the software in case new releases break something.

[a_holley]

By default, the policy is set to once per computer. You then set the trigger you wish to use - typically recurring check in, which most people set to be every 15 minutes.

I do 100% of the software updates for our 500+ Macs, and JSS is the only way we do this now. I've set it up to email me whenever there is an update to software that we use. I then either grab the .pkg file from the developer or update the app in place, drag the app into Composer and let Composer build me a pkg.

[sdagley]

@BreakingZeus You have complete control of how the JSS deploys applications. A few examples would be install automatically when the machine checks in, cache the package on the machine and install at a later time (which you can trigger from the JSS or have the user initiate from Self Service), have the user initiate a download and install from a Self Service policy. There's no shortage of ways to decide when, and when not to, install.

Patch management is somewhat less straightforward, and Jamf is working towards major improvements in that area in the upcoming Jamf Pro 10 release. In the meantime you have several tools that will make keeping your Macs up to date easier:
- AutoPkgr - A free tool that makes it easy to install and configure AutoPkg which will automatically download specific app updates and add them to your JSS
- NetSUS - Pre-packaged Linux VM that provides a NetBoot service and incorporates the Reposado clone of Apple's Software Update Service. While SUS is going away in favor of Apple's new Caching Server approach to providing a local update cace it's still useful in that it allows you to control which OS updates are available vie the softwareupdate tool (App Store apps use a different update mechanism and can't be restricted via SUS)
- MAU Caching Server - Provides a local cache of Microsoft Office 2011 and 2016 updates as well as allowing control of which updates are available

You'll find numerous posts on Jamf Nation regarding the use of those tools, and feel free to post questions.

[J_Martinez]

@a.holley When you use Casper Composer, does the composer app grab all user settings and creates a copy of that. Whats the end result pkg look like when its installed on another system. Do most people just have a master machine they use to capture these pkgs?

@sdagley Thanks for the info, Will look into some of these solutions.

[sdagley]

@BreakingZeus I should have added that you will also want to set up a Mac with macOS Server to provide Apple's new Caching Service mechanism.

Be careful about the approach of using Composer to capture what's laid down by an installer (as opposed to just dragging an application to Composer to have it create a .pkg as @a.holley suggested). When you do that Composer will happily include every file touched by the installation, so you have to make sure things you don't want in your Composer built installer are removed before you build it. Also be aware that the Composer generated installers will try and replace any previously existing files on the users machine, so you could end up overwriting any prefs changes users had made.

[J_Martinez]

@sdagley Thanks for the info. Just one last questions regarding deployment of applications. I asked how do you deal with patch management. Lets say I'm actively deploying Firefox 55.0 and a new version comes out 56.00 is JSS smart enough to distinguish what each system has and install the newest. Would you need an Extension Attribute. Also when adding a pkg to JSS there is an option under limitations Install Only if Available in Software Update"
what exactly is this referring to.

Thanks again !!!

[sdagley · Accepted solution]

@BreakingZeus You'd use a Smart Group rather than an EA. Create one named something like "Firefox is current" with a criteria of Application Title is Firefox.app and Application Version is 56.00 (assuming 56.00 is the current version). To target all of your machines which didn't already have that version you would have a Policy where the Scope Targets was "All Managed Clients" (it's a pre-defined Computer Group) and Exclusions was "Firefox is current". The rest of the Policy settings would depend on how & when you wanted to install.

The Install Only if Available in Software Update would only be useful if you were going to use the JSS to deploy a package that was also available via Apple's softwareupdate tool.

[a_holley]

@sdagley's point is a very good one - I try and avoid using snapshots as much as possible. I don't want to include every file touched by the installer. That's why I just drag and drop the app into Composer to build a .pkg of just the application. I don't want my users to lose bookmarks or other prefs.

@BreakingZeus, I do have a master machine that I do all of my Casper work on. I usually reimage it about once a fortnight, just to keep it clean and to make sure I don't inadvertently introduce an unwanted setting.

[sdagley]

@BreakingZeus I'll add an emphatic 2nd to @a.holley's suggestion of using a clean system for building packages with Composer. It copies everything you add to a package to a cache directory, so using it on a production machine will result in multiple copies of apps existing. I once got into an argument with App Store.app about an installed update that didn't appear to exist only to discover that it'd updated the copy in the Composer cache rather than the one in my /Applications folder.

A variation of using a freshly imaged machine I'd also recommend is building a base macOS VM in VMware Fusion Pro then creating a Linked Clone VM (Parallels Desktop offers a similar feature, but I prefer Fusion Pro) for each package you want to build. The Linked Clone VMs are simply deltas from the base VM, so they take almost no time to spin up and have a very small disk footprint compared to a full VM. When you're done you just delete the Linked Clone, no need to roll back a snapshot of the base VM.