macOS 12 Monterey Release Day – The Enterprise Conundrum

Today, 25^th October 2021 is macOS 12 Monterey release day.

I’m not going to list the what’s new but for some Enterprises this time of year the pressure is on. For some companies they may be Day 0 ready and allow users to hit the upgrade button on release but for many Profiles and Restricted Software settings will be in-place along with banners and various communications channels to prevent and inform users not to update but there will be those users who want to either upgrade today or will be wanting a new Mac that will ship with Monterey installed.

Why Not Day 0 Ready?
There are a number of reasons for this, experience suggests it can better to wait for the .1 or the .2 to resolve any initial issues that have not been picked up through the 4 months of beta testing. However, also consider that additional installed software may seem to run OK but is it supported by the vendor.

For example if you use a 3^rd party app for virus protection or VPN Connectivity if that app starts causing issues and you raise a ticket with the vendor have they actually stated macOS 12 Monterey is supported or will you ticket just be closed as running an unsupported OS. If it’s the latter then that may give you and your users a bit of headache.

IT Pressure
The pressure to allow macOS 12 Monterey is added to by the release of the new M1 Pro and M1 Max MacBook Pro’s, no one will want to buy an Intel MBP now even if you have access to stock but these new MacBook Pro’s and pretty much every Mac you can lay your hands on will now ship with Monterey and they can’t be downgraded. Even if you get a M1 Air with Monterey which last week shipped with Big Sur it should not be downgraded as potentially you are taking it out of any support agreements like Apple Enterprise Support (ACE).

So you have your conundrum of wanting to get the new amazing hardware and Monterey out to users to satisfy their requests but at the same time the potential of running apps that a vendor has not certified yet for Monterey. The best thing to do is communicate to your users, let them know the situation. The last thing you want is M1 Pros or even M1 Max running Monterey and the excitement that brings but then users getting a poor experience because of a crashing VPN client or a security app consuming the CPU!

Possible Solution
The best solution I have found for this for those who can’t wait is to provide an OS and /or hardware pilot. Just make it clear that it’s a pilot, list the apps that are not yet Monterey certified, lust any known issues, keep the pilot small and communications open perhaps via Slack or Teams channel and be on hand to help out at moments notice.

Work with your users, not against them. Let them know their Mac and apps could need updating at the drop of a hat. If you show them you care and are engaged most will help you out as you help them out and that way you will have a much better release ready for mass adoption when you are happy to go.

Worldwide Release Times
Honolulu, Hawaii — 7:00 a.m. HST
Anchorage, Alaska — 9:00 a.m. AKDT
Cupertino, California — 10:00 a.m. PDT
Vancouver, Canada — 10:00 a.m. PDT
Phoenix, Arizona — 10:00 a.m. MST
Denver, Colorado — 11:00 a.m. MDT
Chicago, Illinois — 12:00 noon. CDT
New York, New York — 1:00 p.m. EDT
Toronto, Canada — 1:00 p.m. EDT
Halifax, Canada — 2:00 p.m. ADT
Rio de Janeiro, Brazil — 2:00 p.m. BRT
London, United Kingdom — 6:00 p.m. BST
Berlin, Germany — 7:00 p.m. CEST
Paris, France — 7:00 p.m. CEST
Cape Town, South Africa — 7:00 p.m. SAST
Helsinki, Finland — 8:00 p.m. EEST
Moscow, Russia — 8:00 p.m. MSK
Istanbul, Turkey — 8:00 p.m. TRT
Dubai, United Arab Emirates — 9:00 p.m. GST
Delhi, India — 10:30 p.m. IST
Jakarta, Indonesia — 12:00 midnight WIB next day
Shanghai, China — 1:00 a.m. CST next day
Singapore — 1:00 a.m. SGT next day
Perth, Australia — 1:00 a.m. AWST next day
Hong Kong — 1:00 a.m. HKT next day
Seoul, South Korea — 2:00 a.m. KST next day
Tokyo, Japan — 2:00 a.m. JST next day
Brisbane, Australia – 3:00 a.m. AEST next day
Adelaide, Australia — 3:30 a.m. ACDT next day
Sydney, Australia — 4:00 a.m. AEDT next day
Auckland, New Zealand — 6:00 a.m. NZDT next day

Automate Mac App Updating in Jamf

A Jamf Admin’s tasks are never done….there always seems to be an app update you need to download from the vendor and upload to Jamf so your users are on the latest version and obviously the more apps you have the more you have to do so it can be quite a task to keep up.

Some of this can be controlled by Profiles for example Chrome can be set to be keystoned or configuring MAU to check and update Office but when you build a Mac you want it to be up-to-date straight away so that users does not get those update nags boxes to action.

So how can you keep the apps up-to-date in Jamf before deployment….Automation.

First off identify what apps you want to keep up-to-date automatically. If you already have set MAU to update Office and Chrome to stay up-to-date these are good candidates to have the very latest version install for your new builds but you might have some apps that you need to keep on a specific version until fully tested, perhaps a tool like Tanium or your VPN client.

Now you have your list there are two great options

Autopkg & Autopkgr – https://autopkg.github.io/autopkg/ & https://github.com/lindegroup/autopkgr

Installomator – https://github.com/Installomator/Installomator

Autopkg
Autopkg is framework that allows you to create recipes for software you want to update. It’s command line based but if that looks a little scary then Autopkgr is a UI for controlling Autopkg. I would highly recommend using Autopkgr just to keep things simple.

I’m not going to go into the detail of how you setup Autopkg/Autopkgr and create recipes as there are some great tutorials out there. What I will say is it requires an additional computer to run on. Perhaps you have an older Mac or a Mac mini, something that you can keep on 24/7 and connected to your network via Ethernet. It can be a little bit tricky to set up to begin with but once setup you can set it to check for a specific application like MS Office, download that app, package and upload to Jamf and update a policy. The policy then can be part of your new Mac setup process

So let’s say it’s the second Tuesday of the month and MS have just released Mac Office update. Overnight Autopkg will run, it will spot the update does its thing and uploads to Jamf. The next working day when a new Mac is built it will have that very latest update so on use no MAU update box for the user to deal with they will be on the very latest version of Office.

Autopkg is very capable and very flexible but it requires work and setup time.

Installomator
Installomator is a little different but my now preferred solution. Installomator is a script you add to Jamf and then create a Jamf policy add the installomator script and specify the app you want install in the first Script Parameter Value in the Script payload of the Jamf policy. The Installomator script contains hundreds of values of apps and the associated download URL.

When the Policy runs the script gets the application directly from the vendors CDN. Unlike Autopkg the package is not stored in your Jamf instance it comes direct when required from the vendors server so is a more on demand solution. The policy can then be added to your build process. If using DEPNotify simple create a custom trigger name and add that trigger name to your DEPNotify script and ensure the policy scoping is correct.

The downside and upside of Installomator depending upon your point of view is you are not having to hosting the pkg or dmg. Now for some that could be great if your Jamf is hosted and bandwidth can be an issue but others security may be a concern. Have a read of Armin Briegels post on Installomator. The other issue is if the vendor changes the location of the download or changes it format from pkg to dmg, this will result in a failed policy so keep an eye on your installomator policy logs. If something fails you can most likely work out the new URL and either edit the script or create your own definition, it’s very simple to do and also you can submit any missing items to the dev team and help build out the solution for all.

So there are the two options. This article is intended to be high-level just to give an overview of options available to automate deploying the latest version of some apps.

In both solutions you will find some apps not available as a recipe if Autopkg or a definition in the Installomator script this is usually apps are only available to download after logging into an account, these you will still have to download, check the app and upload to Jamf.

I hope this quick overview helps give you some ideas of taking some of the burden out of app updating but most of all allows your users to get working on their Mac straight away with the latest version of apps installed.

“Apple is not Enterprise” – Why this is not true.

I often hear from managers and IT leaders that “Apple is not Enterprise focused because…” and then a number of variations. There seems to be something in common with the people saying this and that is what they think is Enterprise. Their Enterprise is usually based 10,20 or 40 years experience of a Windows centric environments.

Apple is certainly Enterprise focused. I work with some amazing Apple Enterprise Engineers, Developers and Account Managers all from their Enterprise Division. Plus, support from Apple Enterprise Support and AppleCare for Enterprise. All this along with Apple Seed programme allows me extra insight and direct named contacts to aid deploying devices in the Enterprise and keeping them running with superb help and support. If Apple were not Enterprise why would these areas exist.

If you want control, simple use Jamf Pro. Jamf and Apple have a long-standing relationship, Jamf have a history of being Day 0 ready for major macOS releases. The same is true of Cisco, there is a deep partnership. These 3^rd parties and products are for the Enterprise, you don’t need to run Jamf at home. Why would Apple create and maintain these relationships if they were not Enterprise focused.

As said this opinion of Apple bot being Enterprise seems to come from the individuals understanding of what Enterprise is and that is mainly a Microsoft Windows centric view with devices using Active Directory having layers of additional security and user controls who are seemingly unwilling to depart from these thought processes.

Enterprise is in fact what you make it and it can be much better with Mac’s and Jamf Pro. The best Enterprise environments are where the user has choice, that way the user feels more confident and will be more comfortable with what they know and therefore more productive.

Mac’s can fit into your infrastructure with ease you just need to respect and work with its differences and not against them and not try and force them to work the way your Windows devices work, after all it’s a different platform, it requires different thinking, different support and management.

In the late 90’s and early 2000’s Apple had a Think Different campaign for their consumer products, that needs to come across to Enterprise IT leaders.

Apple tvOS 15 Homebridge Control

If you use Homebridge and have an Apple TV you may know since tvOS 15 on/off control stopped working with the Homebridge Apple TV Remote plugin, the plug fails to find your AppleTV and is not yet fixed.

However I have come come up with a workaround and now have tvOS 15 on/off control.

I run Homebridge on a Raspberry Pi and the first step is to install the latest version of https://pyatv.dev

Once installed I then paired my Apple TV using the command
atvremote -s APPLETVIPADDRESS --protocol companion pair

atvremote -s 192.168.1.100 --protocol companion pair Enter PIN on screen: 4337 Pairing seems to have succeeded, yey! You may now use these credentials: ac1c0e52f256dc5f7b47f5f1f4f1e2a40b3c5676f7d598ac686de8b2afc23a54:cba29ca821e92d98ffa8e1eeab5b18a26b2b6a431f5056b452021ee057fa4a6b:43463041354438422d384242362<SNIP>

I copied the long string of numbers and created 3 shell scripts, adding my IP address of the ATV and the long string of numbers to each:

appletv_on.sh
atvremote -s 192.168.1.100 --airplay-credentials ac1c0e52f256dc5f7b47f5f1f4f1e2a40b3c5676f7d598ac686de8b2afc23a54:cba29ca821e92d98ffa8e1eeab5b18a26b2b6a431f5056b452021ee057fa4a6b:43463041354438422d384242362<SNIP> turn_on

appletv_off.sh
atvremote -s 192.168.1.100 --airplay-credentials ac1c0e52f256dc5f7b47f5f1f4f1e2a40b3c5676f7d598ac686de8b2afc23a54:cba29ca821e92d98ffa8e1eeab5b18a26b2b6a431f5056b452021ee057fa4a6b:43463041354438422d384242362<SNIP> turn_off

appletv_state.sh
atvremote -s 192.168.1.100 --airplay-credentials ac1c0e52f256dc5f7b47f5f1f4f1e2a40b3c5676f7d598ac686de8b2afc23a54:cba29ca821e92d98ffa8e1eeab5b18a26b2b6a431f5056b452021ee057fa4a6b:43463041354438422d384242362<SNIP> power_state

I copied those 3 scripts to my Raspberry Pi at /var/lib/homebridge

I then installed homebridge-script2-ventrilo Homebridge plugin which is a simple plugin that can run the scripts and added the following config:

{
    "accessory": "Script2",
    "name": "ATV",
    "on": "/var/lib/homebridge/appletv_on.sh",
    "off": "/var/lib/homebridge/appletv_off.sh",
    "state": "/var/lib/homebridge/appletv_state.sh",
    "fileState": "/var/lib/homebridge/script1.flag",
    "on_value": "true"
}

In Home app I can now turn on and off the ATV 🙂

As I run the Alexa Homebridge plugin I told Alexa to discover devices, ATV was found and I added this to a routine “Watch Apple TV” which turns on the TV, AV Amp, switches HDMI input and now powers on the AppleTV 🙂