Cooking, Personal

Daz’s Christmas Ham

For the last few years, I’ve been lucky enough to have my family request I cook a Christmas Ham (or three). It’s something I actually enjoy and I’m not all that bad at. So every year, I spend a few hours cooking up the Ham, as well as spamming my social media pages, work Slack channels as well as the #London MacAdmins’ Slack channel with pictures as I go.

The recipe I use is a mix-and-match of a few recipes I’ve found on the Internet as well as some tweaks I’ve made over the last few years. It’s by no means perfect, but I like it…and the family haven’t complained to my face about it 😉

The recipe has lived on a random sheet of A4 paper in a pad somewhere for the last few years, until this year I finally decided to digitise it! Partly in case I loose the paper, and partly because, as each year has gone on, I keep spilling more things on it.

Daz’s Christmas Ham


  • 2-2.5KG Unsmoked boneless Gammon joint
  • 2 Carrots
  • 2 Celery Sticks
  • 1 Onion
  • 2 Cinnamon Sticks
  • 2 Bay Leaves
  • 2-3 Litres of Coke (Not sugar free)
  • 150ml Maple Syrup
  • Red Wine Vinegar
  • Wholegrain mustard
  • Whole Cloves
  • Whole Black Peppercorns


1) Cut the 2 Carrots and 2 Celery sticks into roughly 1-inch thick slices then peel and quarter an Onion. Take 2 Cinnamon Sticks, 1/2 (half) a tablespoon of whole black peppercorns, 2 bay leaves and a pinch or so of whole Cloves. Add all to a cooking pot.

2) Remove the packaging from the Unsmoked Gammon. If you have butchers twine (Thanks for the suggestion James H!) remove all the packaging including the wrap, then tie together. If you don’t have the twine and the ham is wrapped in a plastic sleeve, leave this on. Add to the pot.

3) Add in 2-3 litres of Coke (not sugar free) to the pot, enough to cover the ham. You may need to top up a little with boiling water depending on how big the pot is.

Ham and bits on the hob

4) Bring the pot to the boil with the lid on and reduce to a simmer. This might take 20-30 minutes depending on the amount of liquid. It will make your kitchen smell rather Christmasy.

5) Simmer for 2.5 hours, checking periodically to make sure the pot isn’t spilling over or running low on liquid. If needed, top up the liquid with more boiling water to keep the ham covered as best as possible. The ham will swell a little as well as possibly float, which can make this a little interesting!

6) Once the 2.5 hours are up, drain the pot and set your oven to 170°C. This will let the oven heat up whilst we prep the ham.

7) Remove any wrappings and cut the skin off the ham, leaving behind an even layer of fat. Score the fat in a diagonal fashion to create a a cross-hatch pattern. Push into the fat a whole clove at each intersection of the scoring.

8) Mix the maple syrup, 2 tablespoons of wholegrain mustard, and 2 tablespoons of red wine vinegar in a jug to make the glaze mixture.

9) Move the ham to a roasting pan and pour over roughly half of the glaze mixture.

Ham, scored and poured

10) Roast the ham in the oven for 15-minutes

11) Pour over the rest of the glaze mixture and put back in the oven for 15 minutes

12) Baste with any of the glaze that ran off and put back in the oven for a last 15 minutes

13) Remove from the oven and leave to rest for at least 30 minutes.

14) Have fun cleaning up all the now-sticky kitchen bits you’ve used 🙂

Have a great Christmas and a brilliant New Year!

Mac Admin

Jamf Pro, Intune* and the Jamf Cloud Connector

For this post, I thought I’d share a mixture of things in and around Jamf Pro, the Intune* integration, and the new Jamf Cloud Connector. This is a mixture of a few smaller things I’ve seen in testing that I’d not seen written up anywhere and thought it’d be worth sharing.

First up, What is the Jamf Cloud Connector?

The Jamf Cloud Connector is a new feature added to Jamf Pro a few months back. This is limited to Jamf Cloud customers only (no on-premise or 3rd party hosted options at this time I’m afraid) and, amongst other things, allows you to connect multiple Jamf Pro instances to a single Azure AD tenant for the Jamf Pro / Intune* device compliance solution. This is the only method to link multiple Jamf Pro instances to a single Azure AD tenant!

Jamf documentation on this can be found here. The initial setup process (the Jamf Pro to Intune* connection) is also a little easier than the previous manual method. It’s also worth noting at this point that the previous manual method is still an option (and the only option if you are not hosted with Jamf Cloud).

With the background out the way, I’ll share some of the odd bits and pieces I’ve seen in testing so far.

Passing over the Consent URL

First thing I noticed with the Jamf Cloud Connector method, is it’s no longer possible to ‘just’ pass over the Consent URL to your Global Administrator (or equivalent) as before.

What do I mean by that? Well, with the previous manual setup, you could configure the Jamf Pro side, then grab the Consent URL for your Azure Global Administrator (GA) to approve. They could approve this, complete the setup their side and all worked well. This method was handy if you were in a situation where your Jamf administrator wasn’t an Azure GA, and your Azure GA wasn’t a Jamf administrator.

With this new Jamf Cloud Connector method, there’s less manual tasks, however there is a number of browser redirects back and forth meaning you can’t just send the Consent URL to be approved (or at least I haven’t found a simple way). As a result, you’d either need to:

  1. Give your Azure GA admin access to the Jamf instance/s to set everything up
  2. Apply to get (temporary) Azure GA for your Jamf administrator, and set everything up
  3. Work side by side with your Azure GA to enter their credentials at the Azure screen/s as required (not always ideal in a COVID world!)

Testing between two Jamf Pro Instances

The next thing I came across was in testing enrolments between multiple instances. I was using the same physical device when testing the Intune* connection on both Jamf instances. I enrolled and deployed the test device on Jamf Pro instance “A”, and registered this with Intune* – no problems.

I then wiped the test device, and enrolled and deployed this on Jamf Pro instance “B”. All worked fine, until it came to the Intune* registration. The Company Portal launched as normal, but showed the “This device is already registered” message. I selected the “done” button and Company Portal closed. Shortly after which Self Service / Jamf AAD popped up a message to say that device registration failed due to the user closing Company Portal too soon.

This same behaviour was repeated when I re-ran registration, wiped and re-deployed the device, and also after removing the device from Azure AD (and waiting the 30-60 minutes for things to settle down).

In the end, the resolution was to remove the old device record from the first Jamf Pro server (Jamf Pro instance “A” above). After a few minutes, the registration worked fine.

I can only imagine that the first Jamf Pro server (instance “A”) was still sending data into Intune* and this was holding some sort of partial record in Azure I couldn’t get access to.

I tweeted about this shortly after seeing it, but realised how difficult it would be to explain in a Tweet!

Migrating from the Manual Intune Connector to the Jamf Cloud Connector

Lastly little snippet of things to share is regarding migrating from the previous manual Intune* connection, to the new Cloud Connector. This is something you’d need to do if you had a requirement to link two or more Jamf Cloud instances to the same Azure AD tenant.

After some calls with Jamf Support, it’s as simple as hitting the edit option under “Settings” > “Global Management” > “Conditional Access”, selecting the “Cloud Connector” option, and following the rest of the steps to set this up (don’t forget the documentation here). Once the setting is saved and the connection confirmed (should be within 5 minutes) devices should be fine and stay compliant.

All of the above went off without a hitch, however one thing we did see that wasn’t mentioned is that users will see a popup from JamfAAD (the solution that handles the local aspects of the Intune* registration and data submission). Each user with a device already registered with Intune* will see a popup along the lines of “” wants to use “” to sign in, with the options to Continue or Cancel. Users should click “Continue” and the message will disappear and all will be happy!

Something to be aware of and perhaps pre-warn your users about if you’ll be looking to migrate your setup.


Something a little different from the last few posts I’ve done, but I hope there’s enough helpful information there to help someone out, and save you some faff.

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace in Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

* I’ve used the term Intune here as its familiar to most people who’d be working through the above. Be aware that Microsoft has rebranded this recently to “Microsoft Endpoint Manager” with a new admin URL. Consult your Microsoft documentation for more details.

Mac Admin

What’s new with Adobe 2021 in Education – Content

Hi all,

If I time this right, this post should be going live about halfway through my talk at the PSU Campfire Sessions on Adobe 2021 and Shared Device Licenses in Education. 

This talk is a continue update and expansion on my previous talks, Adobe CC2019 in Education – PSU 2019 and What’s new with Adobe 2020 in Education.

This post contains links to URLs mentioned as well as eventually copies of the video and slides.



Link Dump

As promised, heres a list of URLs from the presentation, as well as some further reading suggestions:

MacAdmins Conference

Thanks again to everyone who could attend!

Mac Admin

MacAdmins at PSU 2021: Campfire Sessions – What’s new with Adobe 2021 in Education

For the last 2 years I have had the privilege of speaking at MacAdmins at PSU around Adobe and it’s use in education. You can find more on that here and here.

Once again, I’m very luck to have another slot to talk about, you guessed it, Adobe in Education!

MacAdmins Campfire Sessions?

As we’re still not fully out of the woods yet with the current worldwide pandemic (boo!) the folks at PSU have elected to repeat the success of their Campfire sessions from last year. Instead of an in-person conference delivered over a few days, they have switched to an online, remotely delivered conference with 2-sessions per week, delivered remotely over 7 weeks.

These are completely free and run 1PM to 3PM ET (6PM to 8PM BST – local time for me – ideal if you’re stuck at home after work)! Once you’re signed up and registered for each session, you’ll be emailed joining links the day before each session. You can also join everyone on Slack in the #psumac channel.

As mentioned, sign up is free and can be done here.

What’s new with Adobe 2021 in Education

As I continue my relentless hammering of the Adobe drum with blog posts and smaller content, I’ll be delivering a slightly longer and expanded version of the talk from last year. Don’t worry, there’s plenty of updates and changes to cover even from last year!

We’re now almost into the 4th year of Adobe’s new Shared Device Licensing, and to top it off, we’ve had a whole new architecture to deal with. What’s changed? What hasn’t? Can you still deploy Adobe Fireworks on Big Sur? Can you _really_ manage the Desktop App? How many bottles of [beverage] will you need to get you through it? All this and (maybe) more!

My talk will be on Thursday 10th June at 1:30PM ET (US) / 6:30PM BST (UK) time, and you can register for it here.

Resources and Recording

The session is being recorded and I’ll add links to that and resources as soon as they’re available.

One more thing…

I’m very happy to announce that we also have two of my friends and colleagues from dataJAR also presenting this year:

I hope to see you there! 😊

Mac Admin

Adobe Remote Update Manager

So I started the testing for this post a few years ago, and after a recently written post about patching Adobe titles for dataJAR I thought it’d be a good chance to revisit and actually get something out! Today’s post is about the Adobe Remote Update Manager, another command line tool that can check for and install Adobe updates. Read on to learn more!


Full Disclosure: I’ve played around a fair bit with the Remote Update Manager tool, but I don’t have a need or the opportunity to use it in anger or full-on in the real world. Your mileage may vary and please test before rolling anything into your own environment.

The Adobe Remote Update Manager (or RUM) has been around for a good few years now, and offers a command line tool to run Adobe title updates. It runs on both macOS and Windows, and can work with a local Adobe Auto Update server.

There are some limitations in what it can do:

  • RUM will only work with updates to installed Adobe Apps. It can’t install upgrades (e.g. Photoshop 2020 to Photoshop 2021) and it cannot install applications that are not present already on the system
  • It can’t patch some native Adobe items such as Adobe Flash (now end of life), Gaming SDK and Adobe Air application updates
  • It can’t patch Adobe Acrobat or Reader unless their own updaters are version 1.0.14 or newer (see “Applying updates for Acrobat and Reader” here)
  • It can’t patch the Creative Cloud Desktop App (CCDA) or RUM itself
  • You can’t use the download action with the binary for Adobe Acrobat or Reader (see more below)
  • Unlike the ALD, the RUM command needs to be run with local admin privileges

How do I get RUM?

So as this is a binary, you’ll need to make sure this is installed on all the devices you wish to use it with. There’s three ways you can get RUM onto your Macs:

Option 1: Direct download

You can download the binary from the Adobe Admin console under “Packages” -> “Tools” -> “Remote Update Manager”. Once downloaded, this should be installed into /usr/local/bin/RemoteUpdateManager

Option 2: Include in your Application Packages

The second option is to add RUM to your Application and / or licensing packages. This is probably the easiest method and will supply an Adobe-made (and therefore Adobe supported!) RUM install using a macOS installer package. This option is found under the packaging options when building the package

Option 3: Use an AutoPKG recipe

The folks over at Moof IT have an AutoPKG recipe in their repo here, that can download and package RUM into an installer package.

How do I use RUM?

So a typical RUM command would look something like this:

/usr/local/bin/RemoteUpdateManager --proxyUserName=XXX --proxyPassword=XXX --channelIds=XXX --productVersions=XXX --action=XXX

This can be broken down as follows:

  • --proxyUserName=XXX --proxyPassword=XXX
    • Optional. You can pre-supply proxy details for the updates, but this will require service account details and isn’t a great idea. I’d really suggest consulting Adobe’s networking requirements KB and opening the required connections
  • --channelIds=XXX
    • Optional. Replace XXX with the channel ID/s of the specific products you wish to update. You can specify multiple channel IDs with a comma (but no space!) between the values. If you do not specify any channel IDs, all updates are considered.
    • You can find a list of channel IDs in Adobe’s Admin Guide here. These will only go up to Adobe CC 2015. If you have titles newer than this, use the --productVersions option instead.
    • If any specified updates have linked recommended updates (such as Camera RAW), these will automatically be considered and run too.
  • --productVersions=XXX
    • Optional. Replace XXX with the SAP code and version of the specific product/s you wish to update. You can specify multiple product versions with a comma (but no space!) between the values. If you do not specify any product versions, all updates are considered.
    • You can find a list of SAP codes and versions at the link here. Note that the current major versions of titles are at the top, with the previous versions under the “Previous Versions” disclosure triangle
    • Again, if any specified updates have linked recommended updates (such as Camera RAW), these will automatically be considered and run too.
  • --action=XXX
    • Optional. Replace XXX with the action you wish to perform. If no action is provided, the tool will automatically try and check, download and install any updates that should be considered.
    • Options are:
      • --action=list – This will check and display a list of updates that are available. The output is a little tricky, but there might be room to turn that into a Jamf Pro Extension Attribute if you’re feeling bold.
      • --action=download – This will check and download the specified updates that are available. It will not carry out any installations
      • --action=install – This will check, download and install the specified updates that are available. If an update has already been download, RUM will use the local copy.

Usage Examples

For these examples, I’ve used a macOS 10.15.7 VM, with Adobe Photoshop 2021 (v22.2.0 – latest at the time of writing), Photoshop 2020 (v21.2.0 – not current), and Premiere Pro 2020 (v14.3 – not current).

Running RUM without any options and with all Apps closed

Command: sudo /usr/local/bin/RemoteUpdateManager


RemoteUpdateManager version is :
Starting the RemoteUpdateManager...
No new updates are available for Acrobat/Reader
Following Updates are applicable on the system :
Following Updates are to be downloaded :
*** Downloading (PPRO/ ...
*** Successfully downloaded (PPRO/ ...
*** Downloading (PHSP/ ...
*** Successfully downloaded (PHSP/ ...
All Updates downloaded successfully ...
*** Installing (PPRO/ ...
*** Successfully installed (PPRO/ ...
*** Installing (PHSP/ ...
*** Successfully installed (PHSP/ ...
All Updates installed successfully ...
Following Updates were successfully installed :
RemoteUpdateManager exiting with Return Code (0)

Notes: This command was run without any of the Adobe titles open or running (besides CCDA).

Running RUM without any options and with Photoshop 2020 open

Command: sudo /usr/local/bin/RemoteUpdateManager


RemoteUpdateManager version is :
Starting the RemoteUpdateManager...

No new updates are available for Acrobat/Reader
Following Updates are applicable on the system :
Following Updates are to be downloaded :
*** Downloading (PPRO/ ...
*** Successfully downloaded (PPRO/ ...
*** Downloading (PHSP/ ...
*** Successfully downloaded (PHSP/ ...
All Updates downloaded successfully ...
*** Installing (PPRO/ ...
*** Successfully installed (PPRO/ ...
*** Installing (PHSP/ ...
*** Failed to install (PHSP/ ...
Some Updates failed to install ...
Following Updates failed to Install :
Following Updates were successfully installed :
RemoteUpdateManager exiting with Return Code (2)

Notes: This command was run with Adobe Photoshop 2020 open and running. You can see the update for Premiere Pro went through whilst the Photoshop update failed. You’ll also note the different exit / return code. More on this below.

Running RUM with the list action and with Photoshop 2020 open

Command: sudo /usr/local/bin/RemoteUpdateManager --action=list


RemoteUpdateManager version is :
Starting the RemoteUpdateManager...

No new updates are available for Acrobat/Reader
Following Updates are applicable on the system :
RemoteUpdateManager exiting with Return Code (0)

Notes: This command will just list the updates available. As mentioned above, without any arguments, it’ll show all available updates for all locally installed titles.

Jamf Pro Policy?

How does the output look when run through a Jamf Policy? Turns out, pretty nice!

Command: /usr/local/bin/RemoteUpdateManager --action=list (via a Jamf Pro Policy ‘Files and Processes’ task)



As with all things, you might hit some issues and not be sure where to look. I’ve chucked a few suggestions below to help you out with troubleshooting.

Running updates with Adobe Apps open

Strangely, Adobe call this out explicitly in their KB article (here) without much explanation:

Adobe Applications for which updates are to be installed should not be running when Remote Update Manager is invoked.

I read this as “here be dragons, we’re just not sure what kind” and advise that you do what you can to make sure you’re running RUM with the Adobe apps not running on your users’ devices.

In my testing, this seems to fail to update any running Adobe titles, but I haven’t seen it cause major issues. Maybe I was lucky? Maybe I didn’t test all areas that doing this may have broken?

Exit / Return codes

When running RUM, it’ll always return an exit code within it’s output text. This will be one of three possible options, which I’ve detailed below:

RemoteUpdateManager exiting with Return Code (0)

Everything worked fine. Either all updates / actions performed fine, or there are no updates found

RemoteUpdateManager exiting with Return Code (1)

Something didn’t work. Could be that the Application was open, the network isn’t live or some installer error

RemoteUpdateManager exiting with Return Code (2)

Some tasks worked, but some didn’t. Could be there was two updates to apply and one failed.

Log Files!

Adobe seem to have very strange rules on where logs are stored, and RUM is no exception.

If a user is logged in, the logs will be stored at /Users/[logged in user]/Library/Logs/RemoteUpdateManager.log

This is the same if the user is an admin user or not, if they’re the user that ran the command, or even if it was pushed out via a Jamf Pro policy.

If no users are logged in, the logs will go to /var/root/Library/Logs/RemoteUpdateManager.log

Again, it doesn’t matted how the command was ran. only who is logged in (or not).

What about updating RUM?

RUM, being an item of software, will have updates time to time. As mentioned above, RUM cannot update itself, so I guess that maybe we need some sort of RUM Remote Update Manager (a RUM RUM? A Rum Double?).

Credit to accidentalmacadmin on Slack

Ok, yes this was a silly excuse to get that (I feel funny) meme into this post. On a serious note, this will depend on how you’re deploying RUM initially, with the simplest method being to keep including it in packages you create. Alternatively, you can use the AutoPKG recipe mentioned above, or manually deploy updated versions as needed.


So that was significantly longer that I thought it’d be and possibly why I didn’t write things up until now. RUM can be a pretty powerful and handy tool, but does have limitations and some oddities. If you’re looking for more information on RUM, you can find it here – Adobe | Use Adobe Remote Update Manager. I hope this post has at least given you an idea of what you’re getting into!

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace in #adobe on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

Mac Admin

Adobe installers, Munki and Error 82

Over a week ago, reports started coming in that newly created Adobe deployment packages were failing to install via Munki, with the error message of “Adobe Setup error: 82: Unknown error“. After some digging and help in the MacAdmins Slack community we’ve found a possible solution. Read on to find out more.

What happened?

The first inklings of an issue were reported in the #adobe channel in Mac Admins Slack on March 16th. The day before, Adobe had released updates to a number of titles including:

  • Illustrator 2021 (25.2.1)
  • Animate 2021 (21.0.4)
  • Photoshop 2021 (22.3)
  • Photoshop 2020 (21.2.6)
  • Premiere Rush 2021 (1.5.54)

If you tried to deploy these titles using Munki, as well as a selection of other 2021 titles, they would fail the install shortly after starting. You’d then find the following entry in the Munki error.log, install.log and ManagedSoftwareUpdate.log (found at /Library/Managed Installs/Logs/)

ERROR: Adobe Setup error: 82: Unknown error

This was the same on different versions of macOS, and if installed with a user logged in, or at the login window. The exact same packages would install fine when attempted via the GUI or via another deployment tool.

What was the fix?

After some detailed discussions in Slack, it was found that Munki detected these packages as Adobe titles and “installed” them in a different way. This different method was being tripped up by changes Adobe have made to the recent installer packages and so was failing.

The fix was to force Munki to treat these packages as “normal” installer packages (although anyone who’s dug into them knows they’re far from normal)! To implement the fix, any affected installer packages should have their pkginfo modified to either:

  1. Remove the installer_type key (which will be set to “AdobeCCPInstaller“); or
  2. Set the installer_type key to a blank (or rather empty) value

Either of these options will force Munki to treat the package as a normal installer package, and seemed to install fine.

How do I implement the change?

Note: This change resolved this issue for us and in testing. Please test in your environment before rolling out.

This will depend greatly on how you specifically work on your Munki repo, but a few suggestions:

I manually edit the text files in my Munki repo

You should find and edit the pkginfo file/s for the affected Adobe packages in your repo to remove the installer_type key as mentioned above

I use Munki Admin to work on my Munki repo

Bring up the details pop-up window on each affect Adobe installer, and on the “Basic Info” tab, clear out / remove the value in the “Installer Type” box. Save and repeat as needed.

I use the dataJAR AutoPKG recipes to import my Adobe application installers

First of all, thanks! We find those things useful and glad others do too.

Secondly, as per this commit, we’ve now added this key to both our 2020 and 2021 Munki parent recipes. If you pull down the changes (and update your local trust info/s) any new imports should take advantage of this.

I’m afraid for anything already in you Munki repo, you’ll need to change the value manually.

Testing Notes

I wouldn’t be involved with an Adobe issue without some structured testing!

For this testing, I used a macOS 10.15.7 VM with VM Fusion Pro. I ran a number of titles through a single test each via Munki. Each title was configured to require a logout and the VM was restored to a snapshot before any Adobe installation for each test.

Additionally I tested Photoshop 2021, 2020 and CC2019 installs and uninstalls, both with and without the change above to briefly test both the installation of older, unaffected packages, and the uninstallation packages.

TitleVersionTaskKey valueResult
XD 202033.1.12.4InstallationAdobeCCPInstallerSuccess
XD 202033.1.12.4Installation[Blank]Success
Media Encoder 202115.0InstallationAdobeCCPInstallerFailed
Media Encoder 202115.0Installation[Blank]Success
Media Encoder 202014.9InstallationAdobeCCPInstallerSuccess
Media Encoder 202014.9Installation[Blank]Success
Photoshop 202122.3.0InstallationAdobeCCPInstallerFailed
Photoshop 202122.3.0Installation[Blank]Success
Photoshop 202021.2.6InstallationAdobeCCPInstallerFailed
Photoshop 202021.2.6Installation[Blank]Success
Photoshop CC 201920.0.10InstallationAdobeCCPInstallerSuccess
Photoshop CC 201920.0.10Installation[Blank]Success
Photoshop 202122.3.0UninstallationAdobeCCPInstallerSuccess
Photoshop 202122.3.0Uninstallation[Blank]Success
Photoshop 202021.2.6UninstallationAdobeCCPInstallerSuccess
Photoshop 202021.2.6Uninstallation[Blank]Success
Photoshop CC 201920.0.10UninstallationAdobeCCPInstallerSuccess
Photoshop CC 201920.0.10Uninstallation[Blank]Success

I fully admit this wasn’t an all encompassing test (unlike the last lot of testing I did) but I feel it covered enough for our needs.

Background information

After some detailed discussions on Slack, I found out some more background about how Munki handles these installs when the installer_type key is set to AdobeCCPInstaller.

More of an issue in older years (and still very much the case on Macs with spinning rust Hard Drives), Adobe installers could take a long time to install their payloads. I have regularly seen as long as 30+ minutes per application package! As Adobe packages don’t utilise the expected payload behaviour, and instead use a post install script to move data around and perform actions, the feedback to both the user and macOS isn’t great. The user will see a message along the lines of “running package scripts” for much of the time the installation is processing. In normal usage, Munki would use this same output to display progress to the end user.

Munki showing a message along the lines of “running package scripts” for ~30 minutes per Adobe package could often lead to users thinking the deployment has become stuck, when the issue is more with how the vender is using the package. It was discovered that Munki could trigger the same deployment tool inside the Adobe package that the post install script does, and that this would give much much better output, and so this is what the value of AdobeCCPInstaller for the installer_type key does.

At some point between now and then, this method continued to work, but the output from the tool was reduced and this method arguably isn’t too useful anymore. This has now culminated in Adobe making changes to how their deployment tool works that affects the deployment method used.

I’ve created a discussion on the Munki-Discuss mailing list to discuss this issue. If you’re seeing the same behaviour, please feel free to contribute here.


This post is out later than I wanted to but real life got in the way! I hope if you’ve encountered this issue, the above information will help you get up and running again.

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace in #adobe on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

Mac Admin

Grabbing Application Icons from Adobe installer packages

When adding applications to Jamf’s Self Service or an option install for Munki’s Managed Software Centre, it makes sense to use the proper software icons for a nice and complete user experience. Did you know you can easily grab the icons from Adobe Admin Console packages, without having to install the package? Read on to find out more.

Previously when I’ve had to grab the icons for Adobe Apps, I’ve had to install them, before manually copying the icons from the application bundles themselves. This process is time consuming and fiddly. After checking a few things today, I realise Adobe ship the icons in an easy-to-grab location inside the Admin Console generated packages!

Where can I find the icons?

This icons can be found in the following location:

./[package name]/Build/[package name]_Install.pkg/Contents/Resources/HD/[SAP Code]/

Here you’ll find two icon files, one at a ‘normal’ resolution (appIcon.png) and one at a retina resolution (appIcon2x.png).

For example in my Bridge package, these can be found at the below location:


Tip: As the Adobe Admin console packages are bundle style, you can right-/control-click on the package and use “Show Package Contents” to access the path via Finder.

Simply generate the packages as you need, pull out a copy of the icon file you need, then you can upload both into your deployment solution of choice.

How do I know what the SAP Code is?

The simplest method is to try and figure it out from the application title, and the options presented when browsing the directory. For example:

  • Adobe Bridge 2021 has a SAP Code of KBRG11.0.1
  • Adobe Dimension 2020 has a SAP Code of ESHR3.4.1

Ah ok so maybe it’s not always so simple! Adobe has a KB that details the SAP codes if you do need to refer to it. This can be found here.


Hopefully this little tip will help speed up (or beautify) your Adobe deployments.

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace in #adobe on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

Mac Admin

Adobe License Decoder

Updated 31st March 2021: Update to add a few clarifications and changes after the crew at Adobe rolled out some fast fixes and improvements.

Welcome back to another Adobe post, you didn’t think you could get away that easy? Today’s post is about the Adobe License Decoder binary, a command line tool that can decode Adobe Shared Device (SDL) and Feature Restricted (FRL) licenses. Read on to learn more.

The Adobe License Decoder (or ALD as I’ll refer to it) was brought up in the #Adobe MacAdmins Slack channel back in November last year (2020), and again recently at the start of this month. This time I had a brief skim read before realising how useful this may be for folks and how it might be worth a post.

What is the ALD and what does it do?

The ALD was an internal Adobe tool for pulling apart installations on devices, in packages or on captured “OperatingConfigs” directories and showing information on the licenses the device used (limited to SDL and FRL licenses). The tool has been written in Rust, works on both macOS and Windows, and has now been made available to the general public from the GitHub Repo at

As mentioned, this is a command line tool with the output being text-based (no GUIs here) and doesn’t need any kind of admin rights to run. As this is a self-contained binary, you can download it onto a device with a suspected Adobe license issue, and run it as needed.

How do I use it?

Once downloaded, simply drag the binary into your command line tool (probably Terminal if you’re on macOS) and run it!


This will output the licensing details for the device you’re running it on.

How about for an Adobe installation package? Simply run the command again, but drag in the directory containing your Adobe package, as so:

./adobe-license-decoder /path/to/Adobe/Package/Directory/

Just to confirm, you need to specify the package folder and not the installer package itself (e.g. the directory that contains the Build and Exceptions directories, and the .ccp file). The reason is the tool will inspect the .ccp file for the data needed.

Lastly, if you’ve copied the OperatingConfigs directory from /Library/Application Support/Adobe/OperatingConfigs on another Mac, you can run the binary against that:

./adobe-license-decoder /path/to/copied/OperatingConfigs/

What sort of output should I expect?

I’ve tested this with a few scenarios and here’s some examples of the outputs you can expect.

No Adobe Apps installed:

Error: There are no licenses installed on this computer

Adobe Apps installed, but with no license (or Named User Licenses – NUL):

Error: There are no licenses installed on this computer

(Yes that’s the same output as with no Apps installed)

Adobe Apps installed, with SDL applied:

License files for npdId: [REDACTED]:
License type: SDL
License expiry date: controlled by server
Precedence: 90 (CC All Apps)
Filenames (shown with '…' where the npdId appears):
1: [REDACTED]-…-90.operatingconfig
App ID: AcrobatDC1
Install date: 2021-03-06 15:49:47 +00:00
2: [REDACTED]-…-90.operatingconfig
App ID: AdobeXD1
Install date: 2021-03-06 15:49:38 +00:00
3: [REDACTED]-…-90.operatingconfig
App ID: AfterEffects1
Install date: 2021-03-06 15:49:33 +00:00
4: [REDACTED]-…-90.operatingconfig
App ID: Animate1
Install date: 2021-03-06 15:49:17 +00:00
5: [REDACTED]-…-90.operatingconfig
App ID: Audition1
Install date: 2021-03-06 15:49:51 +00:00
6: [REDACTED]-…-90.operatingconfig
App ID: Bridge1
Install date: 2021-03-06 15:49:45 +00:00
7: [REDACTED]-…-90.operatingconfig
App ID: CharacterAnimator1
Install date: 2021-03-06 15:49:31 +00:00
8: [REDACTED]-…-90.operatingconfig
App ID: Dreamweaver1
Install date: 2021-03-06 15:49:35 +00:00
9: [REDACTED]-…-90.operatingconfig
App ID: Illustrator1
Install date: 2021-03-06 15:49:32 +00:00
10: [REDACTED]-…-90.operatingconfig
App ID: InCopy1
Install date: 2021-03-06 15:48:56 +00:00
11: [REDACTED]-…-90.operatingconfig
App ID: InDesign1
Install date: 2021-03-06 15:49:44 +00:00
12: [REDACTED]-…-90.operatingconfig
App ID: LightroomClassic1
Install date: 2021-03-06 15:49:53 +00:00
13: [REDACTED]-…-90.operatingconfig
App ID: MediaEncoder1
Install date: 2021-03-06 15:49:41 +00:00
14: [REDACTED]-…-90.operatingconfig
App ID: Nimbus1
Install date: 2021-03-06 15:49:54 +00:00
15: [REDACTED]-…-90.operatingconfig
App ID: Photoshop1
Install date: 2021-03-06 15:49:36 +00:00
16: [REDACTED]-…-90.operatingconfig
App ID: Prelude1
Install date: 2021-03-06 15:49:34 +00:00
17: [REDACTED]-…-90.operatingconfig
App ID: PremierePro1
Install date: 2021-03-06 15:49:52 +00:00
18: [REDACTED]-…-90.operatingconfig
App ID: Rush1
Install date: 2021-03-06 15:49:55 +00:00

I’ve redacted the NPD ID incase it’s anything confidential, but pretty cool huh?

How can I use this information?

So this could be helpful if you’re troubleshooting issues with Adobe licensing on devices (again, SDL or FRL only), and it could be helpful to pass onto any Adobe Support reps you may be working with. If you’re a Jamf Pro customer, it’d also be kinda handy as an Extension Attribute, right? It just so happens I’ve knocked up an example one you can try. If the device comes back with a valid license, it’ll show the license type and the expiry. You can find the EA in my GitHub repo here.

In order to use this EA, you’ll need to make sure a copy of the Adobe License Decoder has been deployed to your devices, and (by default) it’s expected at /Library/Adobe License Decoder/adobe-license-decoder.

What if you can’t be bothered to package this up? I’ve also created an AutoPKG recipe based on the above location that you can find in the dataJAR autoPKG recipe repo here.


Well I thought the ALD was a pretty cool tool and its great to see Adobe sharing this freely. I hope the above gave you an idea of how it works. If you’re looking for more information, check it out at

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace in #adobe on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

Mac Admin

Deploy Adobe Applications to Apple Silicon Devices

UPDATED 2021.03.10: See below

Adobe have made some efforts towards deploying and using their suite of software on Apple’s new silicon (currently M1) devices, announced in November 2020. This post is intended to share the work required to achieve this and hopefully help some folks out!

Before I begin, full-disclosure: I’ve not had the chance to test any of this on an Apple Silicon device myself, and the information shared is from Adobe’s official sources and work from members of the MacAdmin community (#adobe).

The Current Situation – General Usage

Most Adobe Suite applications will run on Apple Silicon devices but through the use of Rosetta 2. The exception to this is Lightroom 4.1 which is Adobe’s first native Apple Silicon application. Details of compatible applications can be found here. For reference these are currently listed as:

  • Acrobat Pro (with known issues detailed here)
  • After Effects
  • Animate
  • Adobe Audition
  • Adobe Bridge (with known issues detailed here)
  • Character Animator
  • Dreamweaver
  • Illustrator
  • InCopy
  • InDesign
  • Lightroom Classic (with known issues detailed here)
  • Adobe Media Encoder  
  • Photoshop (with known issues detailed here. There is also a beta with native Apple Silicon compatibility available here)
  • Premiere Pro
  • Premiere Rush
  • Adobe XD (with known issues detailed here)

It is not specified which versions of these applications are compatible but I’d assume it’ll be the latest version (2021 for the vast majority, with 2020 for those yet to have a 2021 version).

Users can download these installers from the usual end-user download page at

The Current Situation – Mass Deployment

As it currently stands, the installation packages you’ve created for Adobe deployments on macOS will not work on Apple Silicon devices. This includes those created from the Adobe Admin Console, with additional applications or those with the Creative Cloud Desktop App (CCDA) only.

So I can’t deploy Adobe Apps…again?

Well, yes and no. It is possible to actually edit your current installers to work with Apple Silicon (they’ll still require and run through the Apple Rosetta 2 translation environment). The good news is these new packages will work on both Intel and Apple Silicon devices automatically, so you’ll likely not need to keep duplicates of the packages. The bad news is the packages will install one of two different versions of CCDA depending on the architecture you’re deploying to.

Graham Pugh covered this in some detail within his blog post here, but the super-short TL;DR is: Currently Intel Macs will have CCDA version, where-as Apple Silicon devices will get version Both of these are correct and current for each architecture, and both come from your same identical package!

Adobe have documented the process to convert your current / new Adobe packages to be “compatible” with Apple Silicon deployments here (remember, this is still via Rosetta 2). As per my comments above (The Current Situation – General Usage) this will only work for applications that are supported on Rosetta 2. The process requires you to open up your current package, delete and insert a hot fix, clear out any quarantine bits from the package and re-upload to your deployment system of choice.

Certainly better than nothing, but still not ideal.

Oh and one MacAdmin has knocked up a script that can semi-automate the package manipulation process with a copy on the MacAdmins Slack here. Obviously test fully with your own specific use-case and environment!

Progress is coming

Adobe are working on bringing full support (as you can imagine!) as fast as possible. No I don’t have insider information, but the following is observable:

  • The Adobe re-packaging KB (Deploy packages to Apple Silicon devices) specifically mentions “Temporary workaround to deploy Named User or Shared Device Licensing packages to Apple desktop devices that use the M1 chip.” (emphasis is mine).
  • The Adobe M1 compatibility KB (Do Adobe apps work on Apple computers that use the M1 chip?) mentions that Photoshop is planned for a 2021 release (“We plan to release a native version of Photoshop in 2021“) and they’re working on the other applications but don’t have release dates yet

Additionally, Ryan Ball made a nice discovery on Thursday that they shared with the community – Adobe has an updated KB with a link to an arm64 (the architecture reported for Apple’s Silicon devices) installation of CCDA – Download the Creative Cloud desktop app. The links can be found under the “macOS | Alternative downloads” section.

As mentioned up top, I haven’t had the chance to test these for myself, but the fact that Adobe has provided a (what appears to be) native installation mechanism for CCDA on Apple Silicon is a good sign that progress is being made. No I’m sorry to say it’s not a native Apple package installer 😉 And yes, its separated out and not a universal app or installer, which leads my onto my wish list…

Wish in one hand…

I’ve knocked up a few wish list items below, directly related to Adobe and Apple Silicon. These are aimed at the deployment side directly related to my needs!

First of all: Automate the package modifications you’ve outlined above and integrate into your package build systems. You have the full details, and all the files. You now also have an example script to do the work! This would be a quick-win and help out Admins perform less work to deploy your products.

Secondly: Please work towards universal builds (and universal packages) of your applications, not split builds for Intel and Apple Silicon devices as it looks like with the CCDA above (Progress is coming). The reasons for this are two fold:

  • If we have to deploy different versions of your applications dependant on device architecture, we immediately need to double up on storage space for packages. Depending on the applications we as admins need, this could mean a requirement for an additional 20-40GB of space for distribution. It’ll also double up on the effort to run the already manual process to create and download packages, and repeated again each time there are patches or updates released.
  • If we have to deploy different versions of your applications dependant on device architecture, we will need to add extra complexity to our deployment solutions. I’d argue that adding complexity to anything increases the risk of issues, mistakes and hitting unexpected conditions. In some cases this might even affect the user experience negatively.

Now I’m well aware of the phrase “wish in one hand, do…something else in the other and see which one fills up first” and so I’ll be logging the above with Adobe at their Feature Request pages (here) after this post goes live. If you’re also affected I’d strongly request and suggest that you follow suit and maybe we can improve things further!


And that’s another Adobe post done 😉 I felt it was something that was worth sharing and digging into, and I hope that it’ll help out some of you folks out there.

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

UPDATE 2021.03.10:

Mac Admin

Adobe Announces Long Term Support (LTS) for Creative Cloud

Today started with an unusual email from Adobe (which can be viewed here). In this email, the Adobe Creative Cloud Team announced a new support option of Long Term Support or LTS. They also took this opportunity to clarify their support areas and where they will apply.

Unless otherwise noted, N refers to the current version of an Adobe product.


So Adobe have announced that applications older than the current version can be supported under LTS for an additional version. For Example:

  • Photoshop 2021 is current and has full support for security and feature patches.
  • Photoshop 2020 is one behind current (N-1) and so is supported for security updates only, under LTS
  • Photoshop 2019 (and older) is more than one behind current (N-2[+]) and os is not supported for patches.

To be honest, I’d describe this more as “Extended Support” instead of LTS, as LTS has a different meaning for most people.

This is detailed further in the Adobe KB article – Creative Cloud Support Policy

Adobe Support?

So Adobe have also used that document to detail their various support levels and options. Highlights include:

  • Feature Updates – Updates to software to add new features and functionality. These will typically increment the second number in the version of an App (e.g. v2.2.2 becomes v2.3.0)
  • Bug Fixes – Updates to software to remove bugs and unwanted behaviour. These will typically increment the third number in the version of an App (e.g. v2.2.2 becomes v2.2.3)
  • Security Updates – Updates to software to address security vulnerabilities. These will also increment the third number in the version of an App (e.g. v2.2.2 becomes v2.2.3)
  • OS Compatibility – (For Apple devices) Adobe will support the latest macOS, and the two preceding versions (OS N-2 support). For iOS, this drops down to the latest and one preceding version (OS N-1 support).
  • Browser Support – Only the latest versions of Safari, Google Chrome, Microsoft Edge and Firefox.
  • Assisted Support – Adobe customer support and assistance. Support for N-3 or older is at their discretion

Ok so what support applies where?

So for the current (N) version of Adobe software, all customers can expect:

  • Feature Updates
  • Bug fixes
  • Security Updates
  • OS Compatibility
  • Assisted Support

For anything else Adobe, all non-enterprise customers (including Individuals and Teams) can expect:

  • Assisted Support, only

For Enterprise customers, you get access to LTS for the previous version of software (N-1), for a maximum combined 24 months. This covers:

  • Security Updates
  • Assisted Support

For everyone, Support for N-2 and older is limited to:

  • Assisted Support, only


As you can imagine, there are exceptions to the above support:

  • LTS for Photoshop is available to Teams and individual customers
  • LTS versions of “cloud-first” titles are not available due to the integrations with web services. These include: Lightroom, Fresco, Adobe XD and Premier Rush.
  • LTS versions of 3D apps and not available. These include: Dimension and Substance.
  • Acrobat has its own release system, covered more here – Continuous or Classic track.

Adobe have a complete list of titles currently in LTS in a table here. They’ve said this will be updated yearly in November. I’ve repeated the current table below but the source doesn’t include the press-release names (e.g. no Photoshop 2020). I’ve added these below to try and help out.

Software TitleLTS version (Up to Oct 2021)Comments
After Effects17.xPart of the 2020 suite. Also Feature updates until early 2021, and security updates only after
Animate20.5Part of the 2020 suite
Adobe Audition13.xPart of the 2020 suite. Also Feature updates until early 2021, and security updates only after
Adobe Bridge10.1Part of the 2020 suite
Character Animator3.xPart of the 2020 suite. Also Feature updates until early 2021, and security updates only after
Dreamweaver20.2Part of the 2020 suite
Illustrator24.3Part of the 2020 suite
InCopy15.1Part of the 2020 suite
InDesign15.1Part of the 2020 suite
Lightroom Classic9.4Part of the 2020 suite
Adobe Media Encoder14.xPart of the 2020 suite. Also Feature updates until early 2021, and security updates only after
Photoshop21.2Part of the 2020 suite
Premiere Pro14.xPart of the 2020 suite. Also Feature updates until early 2021, and security updates only after

Note: This table is only a snapshot in time. Please consult the source page for up to date information, linked here.

Changes to packaging and title avalibility

As you can imagine, with these changes (or I guess clarifications) on Adobe supported software, there will be some changes to what you see in your portals. Adobe have stated:

  • By default, only titles that receive security or feature updates (e.g. the latest, and LTS versions) are visible for enterprise admins
  • You can also include older packages in your list, but these require a setting change in your console (select Available application versions in package preferences (Admin Console > Packages > Preferences))
  • NOTE: Applications titles more than 3 versions behind latest are not supported and are not available for download! If you currently have access to these, you may download and retain these for future (unsupported) use.

Just to make this clear:

NOTE: Applications titles more than 3 versions behind latest are not supported and are not available for download! If you currently have access to these, you may download and retain these for future (unsupported) use.

It’s not yet clear how this will look for Self Service users in CCDA but it is expected these users simply will not be shown updates and installs for titles outside LTS (for Enterprise accounts) or outside current (for everyone else).

Important Dates

So it looks like most of the above changes have not yet been implemented. Adobe have provided some key dates on the KB that I have repeated below:

  • Nov 10, 2020: Support page updated, introducing the Long Term Supported versions for Enterprise customers.
  • Dec 1, 2020: Creative Cloud Enterprise IT Admins receive email notice of key updates.
  • Dec 1, 2020 – Feb 4, 2021: LTS notification banner appears on the Packages tab inside the Admin Console.
  • Feb 4, 2021: Download availability restricted to align with policy (Creative Cloud for enterprise customers restricted to N-2; Creative Cloud for teams customers restricted to N-1).  


Another Adobe post, this time covering some upcoming chnages with how Adobe support and offer their software.

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.