AN ALTERNATIVE APP STORE: INSTALLOMATOR (USAGE WITH JAMF PRO)

If you manage iPhone or iPad fleets in your company, the App Store is your only source for applications to deploy to devices. When you want to distribute an iOS or iPadOS application available on the App Store via MDM, you can accomplish this through several different methods.

When the original iPhone was released in 2007, there was no app store. That year, Apple promoted web applications. A year later, with the iPhone 3G model, the SDK was also released, and applications began appearing on the App Store.

In short, iPhone and iPad have been closed to sideloading applications from day one. Of course, I’m excluding the Jailbreak option and Custom/Enterprise applications from this.

In contrast, the situation is somewhat different for macOS, which has been in continuous development since the early days of Apple. Since the days when Steve Jobs and Steve Wozniak posed in front of a prototype motherboard, software companies have been developing applications for Apple platforms. And since then, all applications written for Mac have been reaching users through various channels. In the past, they were distributed via floppy disks, CDs, and DVDs. After the WWW era, they became downloadable from companies’ websites.

When Apple released the Mac App Store in 2011 with the macOS X 10.6.6 update, there were already thousands of applications in the Apple ecosystem. Compared to these “outside” applications, the number of apps in the Mac App Store was quite small. And this is still the case today.

If you want to distribute a Mac application to your users without requiring any interaction using MDM, the most effective method is to use the VPP distribution mechanism.

How to distribute applications via VPP is an entirely separate article topic. But to explain very briefly: you purchase the desired application in the desired quantity through Apple Business Manager or Apple School Manager. This application then starts appearing on your MDM server, which you previously connected to ABM or ASM. You can distribute it to the devices or groups you want to install the application on.

This workflow is extremely easy and works smoothly. The application is silently and automatically installed on the user’s device. The license ownership remains with the company. And it does not prompt the user for an Apple Account.

The only problem with this scenario is the requirement that the application must be available on the App Store. With this method, you can only distribute applications found on the Mac App Store. To give a specific example, you can distribute Microsoft Word using this method. However, you cannot distribute Google Chrome via VPP because Google distributes the Chrome web browser through its own website instead of the Mac App Store.

And Google Chrome is not the only example. As I mentioned above, a very large portion of Mac applications are still not available on the Mac App Store.

What Is Our Alternative?

This is where alternative app stores come into play. Since Macs are not closed systems like iPhone and iPad, applications can be installed from sources other than the Mac App Store. As in the Google Chrome example, if you cannot find the application on the App Store, you can download and install it from Google‘s website with a quick internet search.

In MDM-managed environments, you will need alternative methods to VPP for distributing applications that are not available on the Mac App Store. MDM vendors have developed some solutions for this problem. Examples include Jamf‘s App Catalog, Kandji‘s Auto Apps, Mosyle‘s App Catalog, and so on.

If for any reason you cannot use one of these application repositories either, then you can turn to one of the script-based application methods. The open-source Installomator can be considered the most commonly used among these methods.

How Will We Use It?

How you use the Installomator script varies depending on which MDM solution you are using. But roughly speaking, you should be familiar with two separate components of Installomator. One is the script itself, and you can download the latest version, v10.8, from https://github.com/Installomator/Installomator.

The other component is a file called Labels, which contains Installomator’s application repertoire. You can view the contents of this file at https://github.com/Installomator/Installomator/blob/main/Labels.txt.

Usage with Jamf Pro

You can follow the steps below to deploy the Installomator script with Jamf Pro:

1. Log in to Jamf Pro.
2. Click on Settings in the lower-left corner to access Jamf Pro‘s settings.
3. Among all the settings that appear, you need to find the Scripts heading. You can also use the search box if you prefer.
4. Once you enter the Scripts section, click the +New button in the upper-right corner to begin uploading a new script.
5. On the screen that appears, you need to give this script a name under the General tab. You can use a name like Installomator or Installomator v10.8.
6. If you have previously created categories within Jamf Pro, you can select one under the Category heading to assign it to that category.
7. Then switch to the Script tab. You can either drag and drop the Installomator.sh script you downloaded from GitHub into the script window, or copy the entire script content and paste it into the script field.
8. The Installomator script downloaded from GitHub is initially in DEBUG mode. To disable DEBUG mode and start using it in a production environment, you need to change DEBUG=1 on line 30 to DEBUG=0.
   
9. After adding the script, I recommend going to the third tab called Options. Here you will find some options called Parameters. We will not use these parameters from here right now, but they will be useful later. You can leave the Options section without making any changes.
10. From the last tab, Limitations, if there are certain macOS versions where you do not want this script to run, you can add them separated by commas, such as 13.5.1, 14.5.3. However, I would not recommend making this distinction here. We will be placing the script inside a Policy and sending it to devices that way. You can make this distinction as you wish using Jamf Pro‘s Smart Groups.
11. Click the Save button in the lower-right corner to save your script to Jamf Pro‘s script repository.
12. After saving the script, you need to click on the Computers section from the menu on the left side of the Jamf Pro interface. Under the Computers heading, navigate to the Policies section.
13. Once the Policies page opens, click the +New button in the upper-right corner to create a new Policy.
14. After creating the Policy, on the screen that opens, you should first give this Policy a name under the General section. For the naming, you can write the name of the application you will distribute with Installomator. For example, Zoom_Installomator.
15. If previously defined, you should make your Jamf Pro Site and Category selections.
16. As the Trigger, you can check the Enrollment Complete and Recurring Check-in options. These two options will ensure that Installomator is installed on newly enrolled devices and on devices that are already enrolled through this Policy.
17. In the Execution Frequency section, you can select the Once per computer option. Since the Policy we are creating will contain a script, if you do not want this script to run again every day or every week, the Once per computer option will be sufficient. After all, we do not want to reinstall Zoom every day. There is one more small piece of information you should know about the Execution Frequency section: if you want to place the application you will install through this Policy in Jamf Pro‘s Self Service instead of automatically installing it on the user’s computer, then you should select Ongoing instead of Once per computer.
18. If you wish, you can also check the Automatically re-run policy on failure option and retry the installation on the next Check-in in the event of an error. Under the Retry Attempts heading, you can specify how many additional attempts you want.
19. After configuring the general settings of the Policy under the General tab, click on the Scripts heading to add your script to the Policy.
20. After adding the Scripts payload, on the screen that appears, you can see the parameters to be used for Installomator. In the Parameter 4 field, you should enter the name of the application you want to deploy. However, how you write the application name in this field matters. There is a difference between writing the application name as Zoom versus zoom. You should find the correct label for the application you are going to deploy in the Labels document accessible at https://github.com/Installomator/Installomator/blob/main/Labels.txt and write it exactly as it appears there.
    
21. Then switch to the Scope tab to select which computers or computer groups you want to send the application to, and click the Save button to complete the deployment.
22. If you want to send the application to Jamf Pro‘s Self Service application (which is already installed on users’ computers) instead of installing it automatically, you can configure the desired settings from the Self Service tab. When you enable the Make the policy available in Self Service option, settings such as the name and icon with which the Policy will appear in Self Service will be displayed. If you choose to use Self Service, please do not forget to pay attention to the Execution Frequency option mentioned in step 17.

Photo by Mariia Shalabaieva on Unsplash