• support@amsys.co.uk
  • 020 8660 9999

OS X Packaging Thoughts…

Hi All. This blog is a little bit different… and a little bit the same.

Since getting involved with Mac Administration and consultancy, I’ve observed and assisted others with converting applications from what a vendor supplies, to something that is mass-deployable, and suitable for enterprise usage.
During this time, I’ve seen increased usage of snapshot packaging as a first choice.
Additionally, I’ve also seen increasing comments from vendors that if their applications or installers are repackaged, then any issues raised will be unsupported (e.g. you’re on your own)!
I am by no means an expert in this area, but after keeping an eye on areas such as Slack, Munki-Dev / Munki-Discuss, JAMFNation, Mac Enterprise, conference videos and the like, I’ve developed my own set of rules I try to follow. For this blog I thought I’d share them.

Why Repackage?

Why do admins repackage vendor-supplied installers? Why bother spending time doing it at all?
There are a number of reasons that a Mac Admin may feel the need to repackage software to deploy. These may include:

  • Some vendor-supplied installers aren’t deployable in enterprise solutions. Reasons could include:
    • The use of .app installers, or installers that need user interaction during the installation
      • Including Firey Printer Drivers, Sophos (see below) and NetSupport Assist (also below)
  • Some vendor’s supply .app Application bundles
    • (these can be deployed but some deployment solutions will require them to be wrapped in a package)
  • Some applications will need additional configuration post-install.
    • This could include licensing, and initial user pre-configuration
  • Some institutes / companies require that initial ‘first run’ screens are suppressed.
    • This includes Microsoft Office, Sibelius, Pro Tools and many, many more.

 

Examples

A few examples of what I’m talking about regarding the comments from developers:

Microsoft Office 2016 and the license file

As specified by Paul Bowden (@pbowden – Software Engineer for Office for Mac/iOS at Microsoft) on the Mac Admins Slack:
p bowden
This has come from a discussion where the previous version of Office for Mac (‘Office for Mac 2011’) allowed the use of the same licensing .plist file on multiple Macs.
This specifically would be the situation if you:

  • Used monolithic imaging to image your Macs
  • Repackaged the Office for Mac 2011 suite with the license file (e.g. with the use of a snapshot repackage).

With the release of Office for Mac 2016, this same trick also appeared to work. With the above comment from Paul (from the #microsoft-office channel, at 7.25PM GMT on 1st December 2015) it was confirmed that the fact this worked was indeed a bug and it would be ‘fixed’ in an upcoming release.
For the Mac administrator, this meant that if you’d previously been copying the file around and / or used a snapshot packaging method to capture the file, it will stop working with a future update.
Main takeaways:

  • Monolithic Imaging, snapshot repackaging and other methods to manually copy files around outside the developers’ installer tool can lead to more problems down the line.
  • Utilise the developer provided installers unless you have a reason not to. Not the other way around (e.g. ‘always snapshot packages, unless you have a reason not to’ is bad).

 

Sophos and it’s keychain file

Bob Cook (Sophos Employee) added this comment on one of Rich Trouton’s Sophos deployment blogs:
bob cook comment
Bob advised that the copying around of the Sophos.keychain file between machines is not supported and, much like Office 2016, will stop working in a future update.
He also provided a link to their supported method of pre-configuring the deployment.
Again, for the Mac administrator, this meant that if you’d previously been copying the file around and / or used a snapshot packaging method to capture the file, it will stop working with a future update.
Main takeaways:

  • Monolithic Imaging, snapshot repackaging and other methods to manually copy files around outside the developers installer can lead to more problems down the line.
  • Always research any application that you feel requires a snapshot repackage before doing so. There possibly are Knowledge Base (‘KB’) articles and / or others who’ve completed the hard-work for you so that you don’t have rediscover the process.

 

NetSupport Assist

This is a product I’ve had to deploy for a few education institutions.
The ‘installer’ provided is a .app installer will requires licensing and configuration as part of the setup process. Lacking a better option, I’ve followed this write-up with reasonable success.
However, after trying to log a support ticket, I found that any repackaging of any kind is not supported by the developer, and they don’t have any solution to mass deploy the product.
Not what you want to hear on a 150+ Mac deployment.
After a lengthy chat with the support and development teams they understood the issues and asked for details on what they could do to improve things.
Main takeaways:

  • If you can’t find official documentation on how to deploy a developers product, reach out to their support and see where you get. If the developers aren’t aware of a shortcoming, to them it doesn’t exist!
  • Also if you ever get asked by a developer what they can change to help, send them this link as a starter.

 

Rules

So based on a combination of the above examples, advice from other Mac Admins and many conference videos and slides. I’ve drawn up the following rules I personally stick to (and recommend as a starting point for your own):
Rule 1
Do NOT Snapshot repackage vendor-supplied packages.
Rule 2
Do NOT Snapshot repackage vendor-supplied packages.
Rule 3
Do NOT Snapshot repackage vendor-supplied packages.
Seriously, don’t. Snapshotting should be the last and final of all possible options and really shouldn’t be taken lightly. It’s too easy to package the wrong items and break Macs you have out in the field. Probable fixes would likely involve reinstalling the OS’s on affected devices! Even with a long and detailed understanding of  OS X, it’s a potential minefield.
Remember: With great power, comes great responsibility
18f
 
Anyway, back onto more helpful suggestions. What can you do if you need to repackage an installer?
Step 1: If it’s a package (.pkg / .mpkg) just try it.
Seems obvious but, if the Vendor / Developer supplies you with a standard package file (and not one of those fake VISE installers) then your first step should be to try and deploy it as-is. If the install later requires a license file, or some preferences pre-set, these should be packaged / managed (don’t forget your config profiles!) separately from the core, Vendor-supplied package.
You’d be surprised how often this works
Step 2: Check the Vendor’s website
Quite often, the Vendor will have supplied deployment information as a KB article on their own site. Some examples:

Quite often, the Vendors will have their own packaging solution which, more importantly, will be fully supported in use. For example, Adobe has their Creative Cloud Packager (CCP) tool.
Finally, if you’re getting nowhere, contact the Vendor’s support department. At the end of the day, you are paying for a product and that typically includes telephone and / or email support.
Even if nothing else, you let the developer’s know about the shortcoming and it is more likely this will be resolved in the future (see my example about NetSupport Assist above).
Step 3: Reach out to the community
This includes checking for existing recipes from other Mac Admins for use in AutoPKG or AutoPKGr, or utilising AutoDMG  and CreateOSXInstall to ‘package’ OS installations and local user account creation. This also includes search through other community members blog posts, including (but not limited to):

And don’t forget Mailing lists and forums:

And finally, of course you could ask in the Mac Admins Slack!
Step 4: Snapshot…
If you’re still getting no-where, you can use the snapshot ‘repackaging’ method.
However, instead of packaging what you find and deploying it, you can use it the show a list of changed files to help you figure out any additional items the application may move around on first launch.
A good example of this is the Pro Tools deployment I blogged previously.
One of the methods used to discover all the files and locations was a snapshot package.
And if you really must…
If, despite all of the above suggestions, you really must snapshot package that app (and I’m sure there’s a few ‘special snowflakes’ out there), then please take great care.
Sometimes Vendors will only listen when you vote with your wallet and maybe, that’s a better choice.

The Utopian View

So, after all the rules, how about something more uplifting? How about what an ideal ‘packaged application’ should look like?
This is something that will vary greatly, by application, by Vendor and by Mac Admin, but here goes!

  • 3 – 4 items per application deployed, consisting of:
    • 1) Vendor-supplied installation package to carry out the initial installation of the software item
    • 2) 1 (or more) Vendor-supplied update packages to bring the software up to date.
      • These are often replaced with a ‘full installer update’ package, like Firefox or Web browser plugins.
      • For example: previously, this would have included the Office 2011 update packages.
    • 3) 1 (ideally Vendor-supplied, but potential packaged) package and / or script to deploy and license the software item, if required.
    • 4) 1 (or more) configuration profiles with the desired settings for the software item.
      • This would be used to prevent first run screens, configure auto-updates, configure default settings for new users etc.

Summary

That’s it! Hopefully that’ll give other Mac Admins some food for thought.
But what if you disagree with me? Or you have your own suggestions to add?
Any questions, queries or comments? Let us know below and I’ll try to respond to and delve into as many as I can.
The usual Disclaimer:
While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. Amsys will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Close
Search

Hit enter to search or ESC to close