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!

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:

/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

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

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

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 :
(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?).

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.


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.

Standard
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
XD31.1.32.2InstallationAdobeCCPInstallerFailed
XD31.1.32.2Installation[Blank]Success
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.

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.

Standard
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:

/Users/darren/Downloads/AdobeBridge2021/Build/AdobeBridge2021_Install.pkg/Contents/Resources/HD/KBRG11.0.1/appIcon2x.png

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.

Standard
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 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:

./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.

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.

Standard
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 creativecloud.adobe.com/apps

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 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:

Standard
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.

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.

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

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.
  • 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).  

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.

Standard
Mac Admin

Migrating macOS Devices from one Jamf Pro instance to another using ReEnroller – Part 2: Process and Troubleshooting

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:

  1. User triggers the ReEnroller package installation workflow
  2. The policy will install the ReEnroller package and “Completes”
    1. 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
  3. ReEnroller will now launch and start doing its thing:
    1. ReEnroller will now move the current Jamf enrolment pieces to one side
    2. If MDM enrolled, it will now try a local removal of the MDM Profile.
    3. 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
      1. If this fails too, ReEnroller will revert the enrolment back to the source server
    4. ReEnroller will now create a new enrolment invitation on the destination server and enrol to it
      1. 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.
    5. ReEnroller will now use the Jamf binary to enrol the MDM side, but without UAMDM
    6. Once reenrolled, the “migration complete” policy will be called to confirm all was successful
      1. 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.
    7. Migration should now be complete, but will not be UAMDM’d
    8. 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.

Standard
Mac Admin

Migrating macOS Devices from one Jamf Pro instance to another using ReEnroller – Part 1: Setup

So over the last few weeks I’ve seen a few questions pop up around the usage of the Jamf ReEnroller solution, and using it to migrate macOS devices from one Jamf Pro instance to another. It just so happens I’ve had to do this for a few customers to onboard them into datajar.mobi, so I thought I’d share what I’ve learnt!

I’m planning on a two post mini-series with this part 1 covering some background information as well as suggested setup details. Part 2 will look to cover the process and some troubleshooting tips.

What is ReEnroller?

ReEnroller is a tool created by the folks at Jamf. It produces an installer package that deploys an application and settings to migrate a macOS device from one Jamf Pro system to a second one. Ideal if moving providers or changing the Jamf Management URL.

Using an API script, it can also remove an MDM Profile that is set to be “Unremovable” via a ADE (previously DEP) enrolment.

Limitations

Don’t forget that the system you’re using to migrate is also running the migration, so this can be fragile. Also Apple doesn’t provide a supported way to migrate MDM solutions other than a full wipe and redeploy. It is fairly likely you’ll have a few devices (maybe more) which fail to migrate at all and will need a manual intervention, possibly even including a wipe to bring them back into service.

Also this won’t provide a User Approved MDM (UAMDM) enrolment, so your users will need to manually hit that “Approve” button post-migration. As a result, you’ll want to not block access to the “Profiles” System Preference Pane.

Lastly, in my experience, you need to have the destination Jamf Pro instance running the same or newer Jamf Pro version to minimise the risk of failed migrations.

Oh and depending how things end up, this process might not work on macOS Big Sur. More on this in part 2.

Where do I find more information or documentation?

Jamf have some documentation on the use of ReEnroller on the GitHub README file, but this doesn’t provide detailed implementation instructions. It does mention this line: Be sure to view the help for detailed usage instructions.

To view the implementation instructions, grab a copy of the application from the releases page, launch it and click the “?” next to the “Build” button. This will provide some detailed documentation on usage and implementation of ReEnroller.

Oh and also this blog series might help 😉

Setup work

For this walkthrough, I’ll be using the term “source” to mean the current or old Jamf Pro instance the device is currently enrolled in, and “destination” to mean the new Jamf Pro instance.

So in order to setup the Jamf ReEnroller we’ll need to:

  • Create a Jamf API account in the destination instance (and a second one in the source instance if you need to remove an ‘unremovable’ MDM profile)
  • Add the script to run an API command to remove an ‘unremovable’ MDM profile, if required
  • Create and upload the ReEnroller installer package into the source Jamf Pro instance
  • Create a policy in the source Jamf Pro instance to run the ReEnroller installer package (and possibly a second one for the MDM removal script, if required)
  • Create a policy in the destination Jamf Pro instance to run a one line command to confirm the migration is successful

Lets walk through each step in more detail

Create the Jamf Pro API enrolment account on the destination Jamf Pro instance

So first things first, we need to create an API enrolment account on the destination Jamf Pro instance. This will be used by the App to create an invitation enrolment and perform the enrolment.

  1. Log into your destination Jamf Pro server and create a new account. I’d suggest the username “ReEnrollerAPIEnrolment” to make things simple.
  2. Give it a long and complex password and set the privilege set to “Enrollment Only”.

(Optional) Create the Jamf Pro API MDM removal account on the source Jamf Pro instance

If you’ve enrolled macOS devices into your source server with DEP and a non-removable MDM Profile (option shown below), you’ll need to setup an account on the source Jamf Pro instance in order to remove the profile.

  1. Log into your source Jamf Pro server and create a new account. I’d suggest the username “ReEnrollerAPIMDMRemoval” to make things simple.
  2. Give it a long and complex password, set the privilege set to “Custom” and give it the following permissions only:
  • Jamf Pro Server Objects > Computers > Allow Create and Read
  • Jamf Pro Server Actions > Send Computer Unmanage Command > Allow

(Optional) Add the Jamf Pro API script to remove the MDM profile in the source Jamf Pro instance

Again, if you need to use the API to remove the MDM profile to migrate devices, we’ll need to add a script to the source Jamf Pro instance.

  1. Log into your source Jamf Pro server and create a new script. I’d suggest sticking with the default name of apiMDM_remove.
  2. For the content of the script, use the contents of this file from the GitHub repo. This should ensure that you’re using the most up to date version.
  3. Set the parameter names to the below:
  • Parameter 4 – Username
  • Parameter 5 – Password
  • Parameter 6 – Server

(Optional) Add the Jamf Pro policy to remove the MDM profile in the source Jamf Pro instance

Again-again, if you need to use the API to remove the MDM profile to migrate devices, we’ll need to add a policy to the source Jamf Pro instance.

  1. Log into your source Jamf Pro server and create a new policy. I’d suggest calling it something obvious like “API MDM Removal”.
  2. Set the Execution Frequency to “Ongoing” and the Trigger to “Custom”. In the Custom Event box, enter apiMDM_remove.
  3. Add the API script we added above (default name of apiMDM_remove)
  4. In the Username and Password parameter boxes, enter the details of the API MDM removal account we created above (suggested username of ReEnrollerAPIMDMRemoval)
  5. In the server parameter box, enter the source Jamf Pro instance address
  6. Under the Scope tab, configure “All Computers” as the target
  7. Save the policy

Create the Jamf Pro policy to confirm the migration in the destination Jamf Pro instance

We now need to create a ‘completed’ policy in the destination Jamf Pro server. The ReEnroller workflow will trigger this policy to confirm the migration has been successful.

  1. Log into your destination Jamf Pro server and create a new policy. I’d suggest calling it something obvious like “Migration Confirmation”.
  2. Set the Execution Frequency to “Ongoing” and the Trigger to “Custom”. In the Custom Event box, enter jpsmigrationcheck.
  3. Add the Files and Processes payload
  4. In the Execute Command box, enter the following (all on one line)
    1. touch /Library/Application\ Support/JAMF/ReEnroller/Complete
  5. Under the Scope tab, configure “All Computers” as the target
  6. Save the policy

Create the ReEnroller installer package with the required settings

Now we have some decisions to make. We need to use the ReEnroller Application to generate a package that will do the actual work. Below I’ll cover each option and offer my opinion on what to use. Feel free to experiment as long as you do plenty of testing afterwards!

First things first, download the latest copy of ReEnroller from the GitHub releases. Once obtained, launch the application.

Lets go through each box and option:

  • New Jamf Server URL – Set this to the destination Jamf Pro instance’s URL
  • Username – Set this to the username of the API Enrolment account (suggest name of ReEnrollerAPIEnrolment)
  • Password – Set this to the matching password of this account

  • Management Account – Enter the desired Management Account. If you already have a management account on the device, I’d suggest using those details unless you have a specific need to use something else.
  • Password / Verify Password – Enter the desired Management Account password. Again, if you already have a management account on the device, I’d suggest using those details unless you have a specific need to use something else.
    • Randomly Generate Password – Alternatively, you can use a randomly generated password and specify the number of characters.
      • Note: If you do go for the random password you’ll need to add a “Reset Management Account Password” payload to the migration complete policy in the destination server
  • Create the account if it does not exist – Tick to create the Management Account automatically. I’d suggest having this ticked
  • Hide the account – Hide the Management Account from the GUI. Set this to what you need
  • Configuration Profile – If you’re deploying a Wifi profile via MDM, you’ll need to upload a copy of the profile here. This will ensure the device stays connected to a network during the entire migration process.
    • Remove when done – If using a profile for Wifi, tick this to remove that profile after ReEnroller is done
  • Use for new enrollment – If you tick this, the outputted package will not work for migrations! Do not tick this if you’re using this solution to migrate devices
  • Remove profiles marked in DEP as not to be removed – If these devices are pre macOS 10.13, this will remove the MDM profile (needed if you’re migrating to a new server). If the device has a DEP non-removable MDM profile, it’ll use the policy we created above (recommended name “API MDM Removal”) to unenrol and remove the profile. I’d suggest ticking this.
  • Use existing site membership – Tick if you’re using Sites in Jamf and want the devices to try and enrol into the same Site on the destination instance
  • Enroll in site [XXXX] – Use this to instead specify a Site you want these device to enrol into
  • Skip MDM Verification – If you aren’t using APNs on the destination (for some reason?) you can skip this test. I’d suggest leaving this unticked
  • Create ‘Migration Complete’ policy on the new Jamf Server – You can leave this unticked as we’ve done this ourselves. This means we can use an enrolment only account with ReEnroller – much better security!
  • Run policy after verifying migration. Policy ID [XX] – If you have a specific policy you need to run on the destination server after migration, enter the policy ID number here. This could be a progress screen or some initial setup items you need on all Macs.
  • Call Automated Device Enrolment – When enabled, this can trigger an ADE / DEP prompt enrolment to the user. It’ll still require the user to perform a number of tasks so I prefer to not use this
  • Remove ReEnroller folder after migration – When ticked, it’ll clean up any leftovers! Handy to have unticked for testing but I’d strongly suggest ticking this option to make sure nothing sensitive is left behind.

  • Maximum number of retries [XX] – ReEnroller will retry automatically if it finds any issues (more on this in part 2). I’d suggest leaving this blank to have ReEnroller keep retrying until its successful.
  • Retry interval – ReEnroller will retry after 30 minutes by default. This is a pretty good default setting I’d suggest leaving as-is, but feel free to change if you need to.
  • Create Separate Packages – If ticked, this will create a separate package for the Launch Daemon and the migration tools. I’d personally not bother!
  1. Your ReEnroller application should look something like the above.
  2. Click the Build button to produce your ReEnroller package.
  3. Upload this to your source Jamf Pro Server

Create the Jamf Pro policy to run the ReEnroller installer package in the source Jamf Pro instance

Almost there! We now need to create a policy on the source Jamf Pro instance to run the ReEnroller package. This will be a fair bit of personal choice but generally speaking I’d suggest:

  • Obviously add the ReEnroller Package to the policy!
  • Set the frequency to “Ongoing”, the scope to “All Computers” (after testing) and put it in Self Service only
  • Give it a nice logo and a good description
  • Consider informing the user of the whole process in the description and require that they view it before running the policy
  • As a last ditch, you can switch it to a “recurring check in” trigger to get those last few devices over the line.

Test!

And lastly, test. Test, test, test and test some more. Then test again for good luck. the process can be fragile in the best of cases but you can at least test it enough to be confident of the best possible outcome.

Outro

Phew that was a long one. In part 2 I’ll look to cover the process, and any troubleshooting advise I can provide.

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.

Standard
Mac Admin

Uninstalling Adobe Software

Indeed it’s another Adobe post! How to remove Adobe software is a question that often comes up in the #adobe channel and, as with most things, there’s a number of ways to achieve this.

Nuke and Pave

The simplest method, but the one with the most collateral damage. Simple erase and reinstall the macOS onto the device to remove the Adobe software.

This can be done through the GUI, the command line, or external installation media. I’m planning to cover these options in a little more detail soon over on the dataJAR blog.

Uninstaller Package

If you’ve ever created an Adobe deployment package within the Creative Cloud Packager (CCP) or the admin console (https://adminconsole.adobe.com/) your finished project will contain two packages:

  • An installation Package, and
  • An uninstallation Package

You can upload this uninstaller package into your Mac software deployment tool of choice (Munki has an ‘uninstallpkg‘ flag to pass when uploading both packages) and “install” this to remove the corresponding software. Now it’s not as precise and will remove any matches for the major version (e.g. any “Animate 2020” uninstaller will remove any version of “Animate 2020” but won’t remove “Animate CC 2019”).

More information: Adobe | Uninstall Creative Cloud products

Uninstall “All the Things” Package

If you still have access to the older Creative Cloud Packager (CCP), it’s possible to generate an “uninstall all the things” package. I’ve detailed this in a previous post here – Using Adobe Creative Cloud Packager to create an uninstaller in preparation for Adobe Creative Cloud 2019 Shared Device License deployment.

Note: CCP wasn’t designed to be used on macOS Catalina (10.15) or newer and has had some reliance on 32-bit processes. This will probably also be the case for the uninstaller packages it generates. This may limit the usefulness to you.

More information: Adobe | Uninstall Creative Cloud products (different to the above article!)

Command Line

Lastly, there is indeed the command line option. All “Hyper Drive” Adobe installers (which is almost all, if not all of them for the last few years) will also deploy the means to run a command line uninstall of the software.

The syntax for this on Mac is as follows (that’s all on one line):

"/Library/Application Support/Adobe/Adobe Desktop Common/HDBox/Setup" --uninstall=1 --sapCode=PHSP --baseVersion=17.0 --platform=osx10-64 --deleteUserPreferences=true

This is broken down into the below:

  • "/Library/Application Support/Adobe/Adobe Desktop Common/HDBox/Setup"
    • Path to the command, note the quotes due to the spaces
  • --uninstall=1
    • Provide the number 1 to the uninstall flag to specify this is to uninstall
  • --sapCode=PHSP
  • --baseVersion=17.0
    • The base, or major version, of the application you wish to target. These will never match the PR version (e.g. CC 2019) so again Adobe has a (mostly) up to date reference table here – Adobe | Applications that can be deployed without their base versions. If you’re looking for older versions of Application base versions, check out the “Previous versions” disclosure arrow further down that page.
  • --platform=osx10-64
    • This differentiates between macOS and Windows. To be honest, as you’re running this on a Mac, I’m not sure why you need to specify the platform, but best to just use this as is!
  • --deleteUserPreferences=true
    • True here will also try to remove the user’s preferences. I’d suggest setting this to ‘false‘ unless you have a specific reason to remove those settings
  • --removeAll=All
    • (Not shown above) This will uninstall all installed Adobe suite applications
  • --eulaAccepted=1
    • (Not shown above) This is an undocumented feature (thanks Foigus!) to automatically accept the EULA when removing all installed software

As you can imagine, this command will need to be ran as root, however your software deployment / script running solution can achieve this. This will also probably need some trial and error to properly get right so ensure to always test!

More information: Adobe | Deploy packages

Note: This section has been removed from the non-localised version of the page above (link here) and may be deprecated. I’m awaiting clarification on this.

Creative Cloud Cleaner Tool

Adobe provide a cleaner tool that can remove installations back to CS3. It has both a GUI application and a command line binary, but the binary will require you to create your own XML file to feed into it.

More information: Adobe | Use the Creative Cloud Cleaner Tool to solve installation issues

Outro

That’s it, 5 different(-ish) ways to remove Adobe software should you need to. Thanks to Foigus on the MacAdmin Slack for at least half of these suggestions!

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.

Standard