Distributing Enterprise Applications to macOS devices using MDM

Distributing Enterprise Applications to macOS devices using MDM

In an earlier blog post, Bennett described how to create and deploy VPP software packages to macOS and iOS devices using LANDESK Management Suite 2016.3 and later. You may have noticed a radio button in the console UI that, at the time, was ignored:

Yep, you can deploy your own software packages using LDMS MDM, not just those software applications available on the App Store.

If you select the Manifest URL button, you get some additional UI:

The additional UI allows you to enter the URL of a manifest plist file, and the Bundle ID and version of the application being installed. This can seem pretty daunting. Thank goodness Apple has provided a web page documenting the requirements for software distribution via MDM. It’s a good read, and answers a lot of questions, but, at least for me, it didn’t get to the point of being able to create something I could distribute via MDM. But let me summarize:

To distribute software or other things (like fonts for example), you need:

1. Create an installer package (a .pkg file) created with the productbuild command-line tool, and signed with the root certificate of your mdm solution.
2. A manifest file in the form of a property list (.plist) which describes and points to the installer package in very specific ways (see the above link for a sample)
3. A webshare, accessible from your intranet or the Internet. You can place the package and manifest file in a hidden directory or in any location that’s readable using https. It must be readable using https, and using a non-self-signed certificate, since Apple URL services will not connect via https to a server with a self-signed cert.

Once you have these three things, you can fill out the Manifest URL UI to create an LDMS package to distribute to enrolled macOS devices using MDM.

The installer package

Creating an installer package for an application you want to install can be as easy as running the command line tool product build. For example, to create an installer package on my external drive “Work” for Google Chrome, which is sitting in my Applications folder, the following terminal command will do the trick:

productbuild --component "/Applications/Google Chrome.app" "/Applications", "/Volumes/Work/Google Chrome.pkg" --sign identity-name

You will need to replace identity-name with the name of a valid signing certificate on your computer. If you have enrolled your macOS device in the LDMS MDM service, you can find the certificate for the MDM service in your system keychain. This is a valid signing certificate for deployment with our MDM solution.

The manifest file

If you read the Apple documentation (see above), you were given an example manifest file to fill out with our package-specific info (I’ve simplified this by removing some items that are not applicable to the LANDESK environment:

Sample macOS content manifest file for an application bundle

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">
     <dict>
         <key>items</key>
         <array>
              <dict>
                   <key>assets</key>
                   <array>
                       <dict>
                            <key>kind</key>
                            <string>software-package</string>
                            <key>md5-size</key>
                            <integer>10485760</integer>
                            <key>md5s</key>
                            <array>
                                 <string>41fa64bb7a7cae5a46bfb45821ac8b99</string>
                                 <string>51fa64bb7a7cae5a46bfb45821ac8b98</string>
                                 <string>61fa64bb7a7cae5a46bfb45821ac8b97</string>
                            </array>
                            <key>url</key>
                            <string>https://www.example.com/apps/myapp.pkg</string>
                       </dict>
                   </array>
                   <key>metadata</key>
                   <dict>
                       <key>bundle-identifier</key>
                       <string>com.example.myapp</string>
                       <key>bundle-version</key>
                       <string>1.0</string>
                       <key>items</key>
                       <array>
                            <dict>
                                 <key>bundle-identifier</key>
                                 <string>com.example.myapp-unique</string>
                                 <key>bundle-version</key>
                                 <string>1.7.4</string>
                            <dict>
                       </array>
                       <key>kind</key>
                       <string>software</string>
                       <key>sizeInBytes</key>
                       <string>26613453</string>
                       <key>title</key>
                       <string>Example My App Package</string>
                   </dict>
              </dict>
         </array>
     </dict>
</plist>

Things to know about if you are planning to do this by hand:

Once we have the package built as above, to fill out this manifest file, the application needs to know:

1. The location of the the installer package on the https server. Replace “https://www.example.com/apps/myapp.pkg” with the actual name and location of the hosted package.
2. The md5-hash of each 1 megabyte chunk of the installer package file. Replace the array of md5 hash (labeled “md5s” above) with the actual hashes.
3. The bundle identifier and version of the application you are installing. Replace the strings labeled “bundle-identifier” and “bundle-version” above with those strings.
4. The size in bytes of the application package. Replace the string labeled “sizeInBytes” above with this.

When the manifest file (“something.plist”) has been successfully created, it needs to be moved to the same server that is actually serving the installer package. Best practice is probably to place both the manifest plist file and the installer package file in a directory appropriately named on the https server. So, for example, if our application was named “Example.app”, we might have Example.pkg and manifest.plist files sitting on the server in a directory named “Example”.

The LDMS Manifest Package UI

Once we have the package and manifest file build correctly and hosted on our https server of choice, filling out the LDMS Manifest Package UI is pretty simple. I paste the manifest file url into a web browser, load it up, and copy and paste the bundle id and version into the LDMS Manifest Package UI, along with the manifest file url.

Conclusion

Well, there you go, you now have all of the information you need to be able to build your own manifest distribution packages for the LDMS MDM solution. I can vouch for these instructions, as they have allowed me to attain nearly a 25% success rate manually setting things up. I’m sure you can do even better…

But we couldn’t get anywhere getting our own work done without starting to automate some of the pieces of this task, and at this point we’ve managed to produce an early version of an app we’re calling Manifester, which you can point at an application bundle, or a directory with an application bundle, put in your signing cert, and have it create a directory with an installer package and manifest file in it that you can just copy to the correct location on your https server:

Manifester will create a .manifestation folder which you then upload to the location on your https webshare that you specified in the Manifester UI.

Manifester currently supports creating manifest distribution for macOS applications. We will be enhancing it as we get time to support other file types (probably fonts will be first). It should be available through the LANDESK Community site soon after the first of the year.