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.
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:
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!
Introduction
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:
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
Output:
RemoteUpdateManager version is : 2.5.0.3
Starting the RemoteUpdateManager...
**************************************************
No new updates are available for Acrobat/Reader
**************************************************
Following Updates are applicable on the system :
(PPRO/14.9.0.52/osx10-64)
(PHSP/21.2.5.441/osx10-64)
**************************************************
Following Updates are to be downloaded :
(PPRO/14.9.0.52/osx10-64)
(PHSP/21.2.5.441/osx10-64)
**************************************************
*** Downloading (PPRO/14.9.0.52/osx10-64) ...
*** Successfully downloaded (PPRO/14.9.0.52/osx10-64) ...
*** Downloading (PHSP/21.2.5.441/osx10-64) ...
*** Successfully downloaded (PHSP/21.2.5.441/osx10-64) ...
All Updates downloaded successfully ...
**************************************************
*** Installing (PPRO/14.9.0.52/osx10-64) ...
*** Successfully installed (PPRO/14.9.0.52/osx10-64) ...
*** Installing (PHSP/21.2.5.441/osx10-64) ...
*** Successfully installed (PHSP/21.2.5.441/osx10-64) ...
All Updates installed successfully ...
**************************************************
Following Updates were successfully installed :
(PHSP/21.0/21.2.5/osx10-64)
(PPRO/14.0/14.9/osx10-64)
**************************************************
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
Output:
RemoteUpdateManager version is : 2.5.0.3
Starting the RemoteUpdateManager...
**************************************************
No new updates are available for Acrobat/Reader
**************************************************
Following Updates are applicable on the system :
(PPRO/14.9.0.52/osx10-64)
(PHSP/21.2.5.441/osx10-64)
**************************************************
Following Updates are to be downloaded :
(PPRO/14.9.0.52/osx10-64)
(PHSP/21.2.5.441/osx10-64)
**************************************************
*** Downloading (PPRO/14.9.0.52/osx10-64) ...
*** Successfully downloaded (PPRO/14.9.0.52/osx10-64) ...
*** Downloading (PHSP/21.2.5.441/osx10-64) ...
*** Successfully downloaded (PHSP/21.2.5.441/osx10-64) ...
All Updates downloaded successfully ...
**************************************************
*** Installing (PPRO/14.9.0.52/osx10-64) ...
*** Successfully installed (PPRO/14.9.0.52/osx10-64) ...
*** Installing (PHSP/21.2.5.441/osx10-64) ...
*** Failed to install (PHSP/21.2.5.441/osx10-64) ...
Some Updates failed to install ...
**************************************************
Following Updates failed to Install :
(PHSP/21.0/21.2.5/osx10-64)
**************************************************
Following Updates were successfully installed :
(PPRO/14.0/14.9/osx10-64)
**************************************************
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
RemoteUpdateManager version is : 2.5.0.3
Starting the RemoteUpdateManager...
**************************************************
No new updates are available for Acrobat/Reader
**************************************************
Following Updates are applicable on the system :
(PHSP/21.2.5.441/osx10-64)
(PPRO/14.9.0.52/osx10-64)
**************************************************
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)
Output:
Troubleshooting
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?).
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.
Outro
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.
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:
Remove the installer_type key (which will be set to “AdobeCCPInstaller“); or
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.
Title
Version
Task
Key value
Result
XD
31.1.32.2
Installation
AdobeCCPInstaller
Failed
XD
31.1.32.2
Installation
[Blank]
Success
XD 2020
33.1.12.4
Installation
AdobeCCPInstaller
Success
XD 2020
33.1.12.4
Installation
[Blank]
Success
Media Encoder 2021
15.0
Installation
AdobeCCPInstaller
Failed
Media Encoder 2021
15.0
Installation
[Blank]
Success
Media Encoder 2020
14.9
Installation
AdobeCCPInstaller
Success
Media Encoder 2020
14.9
Installation
[Blank]
Success
Photoshop 2021
22.3.0
Installation
AdobeCCPInstaller
Failed
Photoshop 2021
22.3.0
Installation
[Blank]
Success
Photoshop 2020
21.2.6
Installation
AdobeCCPInstaller
Failed
Photoshop 2020
21.2.6
Installation
[Blank]
Success
Photoshop CC 2019
20.0.10
Installation
AdobeCCPInstaller
Success
Photoshop CC 2019
20.0.10
Installation
[Blank]
Success
Photoshop 2021
22.3.0
Uninstallation
AdobeCCPInstaller
Success
Photoshop 2021
22.3.0
Uninstallation
[Blank]
Success
Photoshop 2020
21.2.6
Uninstallation
AdobeCCPInstaller
Success
Photoshop 2020
21.2.6
Uninstallation
[Blank]
Success
Photoshop CC 2019
20.0.10
Uninstallation
AdobeCCPInstaller
Success
Photoshop CC 2019
20.0.10
Uninstallation
[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.
Outro
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.
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:
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.
Outro
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.
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 https://github.com/adobe/adobe-license-decoder.rs.
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!
./adobe-license-decoder
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:
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:
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.
Outro
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 https://github.com/adobe/adobe-license-decoder.rs
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.
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:
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).
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 5.3.2.471, where-as Apple Silicon devices will get version 5.3.5.518. 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!
Outro
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:
Something I missed earlier, with the release of "the rest" of the Adobe 2021 suite, the admin console now has the ability to create Apple Silicon installs. No these aren't universal so you'll need to double up on packages etc…#Adobe#MacAdminspic.twitter.com/42nZcFVtza
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.
What?
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.
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
Exceptions!
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.
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 Title
LTS version (Up to Oct 2021)
Comments
After Effects
17.x
Part of the 2020 suite. Also Feature updates until early 2021, and security updates only after
Animate
20.5
Part of the 2020 suite
Adobe Audition
13.x
Part of the 2020 suite. Also Feature updates until early 2021, and security updates only after
Adobe Bridge
10.1
Part of the 2020 suite
Character Animator
3.x
Part of the 2020 suite. Also Feature updates until early 2021, and security updates only after
Dreamweaver
20.2
Part of the 2020 suite
Illustrator
24.3
Part of the 2020 suite
InCopy
15.1
Part of the 2020 suite
InDesign
15.1
Part of the 2020 suite
Lightroom Classic
9.4
Part of the 2020 suite
Adobe Media Encoder
14.x
Part of the 2020 suite. Also Feature updates until early 2021, and security updates only after
Photoshop
21.2
Part of the 2020 suite
Premiere Pro
14.x
Part 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:
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).
Outro
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.
So this is part 2 of my mini series on using ReEnroller. Part 1 can be found here and covers the initial setup. This part will look to cover the process and some basic troubleshooting, as well as some post migration tasks.
Process
So if you followed my guide from last time, you should hopefully have a working migration process. With the configuration I’ve talked through, the process that the ReEnroller will carry out is:
User triggers the ReEnroller package installation workflow
The policy will install the ReEnroller package and “Completes”
Due to this, I’d suggest added a ‘policy completion’ message to the policy to let users know the rest will run in the background
ReEnroller will now launch and start doing its thing:
ReEnroller will now move the current Jamf enrolment pieces to one side
If MDM enrolled, it will now try a local removal of the MDM Profile.
If this fails, it’ll try and call the MDM API removal policy on the source server. This runs an unmanage command – the only way to remove a DEP un-removable MDM Profile
If this fails too, ReEnroller will revert the enrolment back to the source server
ReEnroller will now create a new enrolment invitation on the destination server and enrol to it
If this fails, ReEnroller will revert the enrolment back to the source server. If the MDM Profile was removed, ReEnroller will use the Jamf binary to enrol the MDM side without UAMDM.
ReEnroller will now use the Jamf binary to enrol the MDM side, but without UAMDM
Once reenrolled, the “migration complete” policy will be called to confirm all was successful
Once again, if this fails, ReEnroller will revert the enrolment back to the source server. If the MDM Profile was removed, ReEnroller will use the Jamf binary to enrol the MDM side without UAMDM.
Migration should now be complete, but will not be UAMDM’d
If at any point ReEnroller failed the migration, it’ll repeatedly try again every 30 minutes (unless you change this setting in the ReEnroller application)
Troubleshooting
If you’re seeing issues with the migration, there are a few things you can check:
The ReEnroller process actually logs its work in the jamf.log at /var/log/jamf.log. This should be the first place to check for errors
You should also check the logs for the policies to check if they did run, and if they had any errors! This should be the “migration complete” policy and (if used) the API MDM removal policy.
What about UAMDM?
As mentioned above, these MDM Profile enrolments are via the Jamf binary and so will result in a non-UAMDM enrolment. I’d suggest documenting the process to accept the MDM profile and sharing this out with your end users. For this same reason, you shouldn’t block the Profiles System Preference Pane on migrated devices.
Jamf has an option to nag users to accept this, but they’ll need the user to launch Self Service, or to allow Self Service notifications (something you can’t force-on until the device is UAMDM’d)!
I heard a rumour…
What about the next macOS, Big Sur? I heard a rumour that it may add further obstacles to command line profile installation, and these would break the ReEnroller workflow above. At this stage, I can only suggest testing with Big Sur and filing feedback with Apple / Jamf / the ReEnroller project.
Outro
That should complete the ReEnroller mini-series! Hopefully it’ll help guide you through the process to a working solution, or a base to make your own tweaks and changes.
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.
