Apps Deployment

AirWatch has 2,5 mechanisms to deploy apps:

1. Apps & Books → Internal. You can only deploy 3 versions of an application called “Alpha”, “Beta”, “Production”;
2. Devices → **Staging & Provisioning →**Product List View → Add Product. Add Manifest → Install Application. Difference between this method and the one below is not clear, except slightly easier config;
3. Devices → Staging & Provisioning → Components → Files/Actions. Add Files/Actions → Add Manifest → Install Unmanaged Application.

I recommend the 3rd method as the most descriptive and stable if several versions of an application are needed in one Organization Group.

Things to check in application deployment

Application ID

Check if there is a modification of the Application ID while uploading the application in the Console via Staging & Provisioning → Components → Applications or check while uploading the Application, is it fetching the Application ID and populating the same name in the Application ID field.

Application Metadata

Once the app gets uploaded, AirWatch SQL writes down its’ metadata to SQL. Parsing the data:

SELECT a.name, a.versionhash, * FROM INTERROGATOR.APPLICATIONLIST AL
JOIN interrogator.Application A ON AL.ApplicationID=A.ApplicationID
WHERE DEVICEID in (1473) and isinstalled=1

See more on SQL querying apps

Application Deployment Logs

• Device receives command to install application
• Device is directed to app destination for download via Manifest.plist file - so search for “manifest” in the logs:

• Device is redirected to Manifest.plist URL
• Device locates Blobhandler.pblob URL:

• Device is redirected Blobhandler.pblob URL
• Application download begins

macOS Apps Deployment

External link:

• Troubleshooting macOS - https://github.com/micromdm/micromdm/wiki/Troubleshooting-MDM

You are able to deploy apps on Mac OSX devices either from Apps & Books or from Product & Provisioning method. If you have a pkg or dmg file, then you could simply use Apps & Books. However, if you have multiple files to be executed or scripts to run then you could use Product & Provisioning. In AirWatch 9.3+, all macOS application file types (.dmg, .pkg, .mpkg, .app) can be managed through the Internal Applications section. This new framework leverages the popular Mac Admin community tool, Munki.

Provisioning with Munki

Enabling Software Management

• Navigate to Settings > Devices & Users > Apple > Apple macOS > Software Management
• Enable Software Management , there is a check in place to verify if File Storage is enabled at this page. If there is no File Storage, the admin will be requested to enable File Storage.
• On-Prem deployments will need to enable CDN.

Before uploading macOS File to AirWatch

All primary macOS software file types will now be uploaded through Internal Applications (.pkg, .dmg, .mpkg). A .pkg file can be a Bootstrap Package or can be managed through full lifecycle management (this feature). In order to configure Advanced Management options for macOS software and for effective desired state management, which is achieved through the integrated Open-Source Munki library in the AirWatch Agent, a metadata file must be generated for the file separately before uploading it to the AirWatch Console. Munki’s deployment logic is built on the concept of pkginfo files, which are xml/plist files that contain metadata, configuration information, and more for a given application file. AirWatch requires this pkginfo file along with the application file to manage the deployment in the Console.

The pkginfo file is genetrated with VMware AirWatch Admin Assistant (see tools page for download). This is a GUI wrapper for a Munki command-line utility and is used to generate the pkginfo metadata file for a given application file.

Generating a pkginfo metadata file using VMware AirWatch Admin Assistant

1. Download and install the Admin Assistant tool to a macOS device or VM.

2. Open the Assistant. The Assistant dialog will ask for the application installer files to parse.

3. Upload an application installer file by dragging & dropping a .pkg, .dmg, .mpkg, .app file into the labeled field, or browse the local files on the machine in order to find an installer file.

   Note

   If the file is .app, it will be converted into a .dmg for deployment

4. Once the file is selected and uploaded, the Assistant will automatically start parsing process the process. Additional files can be added during this time if needed.

5. Once the parsing is complete, the tool will prompt to reveal the parsed metadata files in Finder. Store the metadata files in a local folder where they can be easily retrieved during the Software Distribution procedure.

Generating a pkginfo metadata file using Autopkg

There are multiple ways to obtain the metadata/pkginfo file aside from using the Admin Assistant. One of them is to use Autopkg and its’ GUI tool Autopkgr.

Uploading a macOS Application to the AW Console:

1. Navigate to Apps & Books > Applications > Native > Internal
2. Click Add Application
3. Upload app/software file (.pkg, .mpkg, .dmg)
4. Continue to the next screen and Upload the pkginfo .plist file
5. Continue to customize the app deployment. The proceeding screens will display any available configurations present in the pkginfo file (for example, a pkginfo from AutoPkg may contain an install_check script). Additional deployment configurations can be defined, and will be merged with the existing configurations
   • If the pkginfo file has one or more key and configuration that are not exposed in the UI, they will not be affected. This feature is important as it allows administrators to upload pkginfo files with keys that would be supported by the Munki client but would not be configurable in the UI. Any changes in the UI will be merged with the existing keys.

Pre/Post Install Scripts

A common reason to repackage software is to perform additional configuration tasks or to install additional items. A technique to avoid repackaging is to add pre-install scripts and/or post-install scripts to the configuration of an item. These scripts can take care of some of the tasks which previously may have required repackaging to implement.

An Exit Code of 0 will define the script as successfully executed in order to allow Munki to continue.

Uninstall Methods

There are multiple options available for uninstallation of software. The appropriate option will be selected by default by the VMware Admin Assistant tool based on the software’s file type. If needed options to override the default values are available in the AirWatch Console.

Remove Copied Items
Used primarily for software installed from a .dmg

• Pulls from items_to_copy array[dicts] in the pkginfo file
  • All file paths in this array will be deleted
• Future Console release will show the paths in the items_to_copy array in the UI

Remove App

• Pulls from installs array[dicts] in the pkginfo file
  • All file paths in this array will be deleted
• Future Console release will show the paths in the installs array in the UI

Remove Packages 
Used primarily for software installed from a .pkg

• Uses receipts and analyzes the packages to remove
  • Tries to determine what files were installed via the Bom file
  • Deletes receipt
• Will only remove if package is not associated with any other files or programs
• Future Console releases will show the receipts that Munki check for in the UI

Uninstall Script 
Can be used for any installer type

• Written in shell script
• Used to perform custom uninstall operations if needed
  • If the Admin has a customized deployment of an app, they will need to also write a corresponding uninstall script to remove their custom configurations

Install or Uninstall Verification

With some software, the Admin needs to configure what exactly defines a Successful Install or Uninstall. Munki allows this through setting an Install or Uninstall Check Script

Install Check Script - If present, this script is executed to determine if an item needs to be installed. A return code of 0 means install is needed; any other return code causes install to be skipped.

Uninstall Check Script - If present, this script is executed to determine if an item needs to be uninstalled. A return code of 0 means uninstall is needed; any other return code causes uninstall to be skipped.

Conditions

Conditions can defined on a per-application level so that they are evaluated prior to the download and installation of a software.

Built-in Conditions Currently available built-in attributes for conditional comparison:

Example:

machine_type == “laptop” AND os_vers BEGINSWITH “10.7”

date > CAST(“2016-03-02T00:00:00Z”, “NSDate”)

Dates in conditions:

The date string must be written in UTC format, this format is interpreted as a local date/time. The condition date > CAST("2013-01-02T00:00:00Z", "NSDate") is True if the local time is after midnight local time on 02 Jan 2013.

Literal types in comparisons

• Strings are delimited by either single or double-quotes: os_vers BEGINSWITH "10.7"

• Integers have no quotes: os_vers_major == 10

• Booleans are indicated as TRUE or FALSE (and have no quotes, or they’d be strings!): some_custom_condition == TRUE

• Dates are possible, but they must be cast from ISO 8601 strings: date > CAST("2013-01-02T00:00:00Z", "NSDate")

Updates

Updates can be managed similarly to the other platforms in the AirWatch Console. If a new version of the file needs to be added, perform the following:

1. Navigate to Apps & Books > Native
2. Click on the App that requires an update. Clicking the app will navigate to the Details View page.
3. In the top right side, click “Add Version”
4. Upload the new installer for the new app version
5. Upload the new pkginfo file for the new version
6. Make any additional changes and then save the configuration

Troubleshooting

The AirWatch Console will show report macOS app installation data from a device in several  locations:

• Apps & Books > Applications > Native > Internal. Click onto the Application to drill into Application Details > Devices Tab. The grid in this tab will display installation statuses for each device.
• Devices & Users > Devices > List View. Click on a device to drill into Device Details > Troubleshooting Tab. The grid on this tab will show activity on the device and provides filtering options to show information relating to Software Distribution.

Munki Logs can also be directly accessed on the device: /Library/Application\ Support/AirWatch/Data/Munki/Managed\ Installs/Logs/ManagedSoftwareUpdate.log

tail -n 20 -F /Library/Application\ Support/AirWatch/Data/Munki/Managed\ Installs/Logs/ManagedSoftwareUpdate.log

Munki Known Issues

• Once software has been published and installed on a few devices, if any of the configuration options such as “install script”, “uninstall script” etc.. are changed, devices which already have the application installed successfully will not receive the updated options as these can only be updated when an “InstallApplication” command. This is the only command that can update the locally cached PKGInfo files on the device. In order to update the scripts, administrators will have to manually select all of the devices which have the software installed and repush the command. Repushing the command will update the respective cached PKGinfo file with the latest information.
  Note: Repushing the command will NOT reinstall the application unless there is a change in the software version. Munki is has mechanisms in place to not reinstall software when the application is already installed.
• If a package has a dependency on another package or software then an administrator will have to manually provide a required key in the pkginfo of the package with a dependency. Providing the key in the pkginfo is the only way for Munki to recognize if there are any dependencies, and determine the sequence of installation steps for such dependent packages. Unless otherwise specified, packages are installed in random order. Such package installation will fail if a package dependency is not met during the installation. 
  Example: Netbeans requires that Java be present and installed on the machine. Netbeans will not implicitly install Java while installing the Netbeans software package. Even if administrators attempt to install Netbeans without utilizing M****unki or using standalone Munki, the installation will fail and will prompt the administrator to first install Java before installing Netbeans.
• For packages which have the same receipts array with same version even on an upgraded package, Munki will not be able to detect that a new package is an upgraded package. The reason is that the receipt array has the same version as the previous package. The impact of duplicated receipts arrays is that the packages will not be installed on User machines as Munki cannot determine that a new version needs to be installed.
  Note: The best solution for packages with duplicate versions in the Receipts Array is to use an Autopkg Recipe, which adds an installs array in the pkginfo. This method allows Munki to detect upgraded packages; alternatively an administrator can manually add an installs array into the pkginfo.

Example: Wireshark is an example of a package which has identical receipts which contain the same version, thus Munki cannot detect the when upgraded packages are deployed.

Legacy methods (AirWatch 9.2 & older)

Apps & Books

• Go to Groups & Settings > All Settings > Devices and Users > Apple > MAC OS > Software Distribution.
• Enable Software distribution.
• Now go to Apps and Books > Native > Internal > Add Application.
• Upload the .pkg or .dmg file.
• Once uploaded, click on Continue. You will get an option to download VMware AirWatch Admin Assistance tool.
• Download the tool.
• Upload the .pkg or .dmg file there.
• You will see that it will open the package into .dmg file, .plist file and .png file.
• Go back to the Console and upload the .plist file for metadata.
• Click on upload and you will see the application description.
• You will get an option to upload the image. Upload .png file there.
• Now assign the application to the required Smart Group.
• Click on Save and Publish.

Product provisioning

It allows you to create, through AirWatch, products containing profiles, applications, and files/actions (depending on the platform you use). These products follow a set of rules, schedules, and dependencies as guidelines for ensuring your devices remain up to date with the content they need.

• Navigate to Devices > Staging & Provisioning > Components > Files/Actions
• Click on Add > General
• Navigate to Files > Add Files and enter the specific path
• Navigate to Manifest. Under Install Manifest, click Add Action. Choose the action type Install and provide the specific path. 
• Under Uninstall Manifest, click Add Action and set the action type as Install, again providing the specific path. 
• Under Uninstall Manifest, click on Add Action and choose the action type Uninstall, and provide the exact application name with the extension as ‘.app’.
• Select Save
• Navigate to Staging & Provisioning > Product List View and select Add Product.
• Under General, verify the details and assignment group are filled in.
• Navigate to the Manifest tab and click on Add. Choose the created component after selecting Install/Action.

With this configuration, the application will first be downloaded to the Downloads folder on the Mac. You can then install the application, which will be available in the Applications folder. If you want only to uninstall the application which was previously installed, you may choose the Delete Files option while creating files and actions.

Recipes

Script recipies

TextWrangler Post Install Script Implement a post-install script that copies the command-line tools from the TextWrangler bundle to their intended locations.

After uploading the appropriate files to AirWatch, pre/post install scripts can be configured for the app in the Scripts tab of the Application Details. Simply paste the script into the appropriate field and AirWatch will format it to be used by Munki.

App recipes

Manifest recipies

Quick fix for root user login bug (https://techcrunch.com/2017/11/28/astonishing-os-x-bug-lets-anyone-log-into-a-high-sierra-machine/ )

Enable root user with random password

Below are steps to fix the issue via  Product Provisioning -

A. Create a File

1. Go to Devices > Staging & Provisioning > Components > Files /Actions.
   2.  Add Files / Actions > macOS
2. Manifest > Install Manifest > Run > Command Line and Arguments to run /usr/bin/dscl . -passwd /Users/root $(/usr/bin/openssl rand -base64 20)
3. Click Save

B. Create a Product to include above File

1. Go to Devices > Staging & Provisioning > Products List View  > Add Product > macOS
   2.  Click on Manifest > Add Manifest > Actions to Perform > Install Files / Actions > Files/Actions (Enter the saved file).
2. Save & Activate the product

Unsigned application launch bypassing Security & Privacy

Use above recipe with command Manifest > Install Manifest > Run > Command Line and Arguments to run:

sudo xattr -rd com.apple.quarantine /Applications/@cursor # where '/Applications/@cursor' is the target app