Moving devices from Adobe Shared Device License to Adobe Named User License

Hey folks, this question came up a while ago in the MacAdmins #adobe Slack channel, and recently reappeared so I thought I’d document it!

In some cases you may need to convert an already deployed Mac away from Adobe’s Shared Device Licensing (SDL) and change it to unlicensed or Named User Licensing (NUL). This is indeed possible but there are a few hoops to jump through.

I know, I just need to deactivate the license!

Well, yes and no.

It is indeed possible to deactivate an SDL using either the portal or the Adobe Licensing Toolkit (Deactivating Adobe Shared Device Licenses). However, as soon as an Adobe ID is used to log into the Adobe Apps, the SDL is re-activated.

“However, as soon as a users sign into Adobes app on each of these machines, the machines are immediately licensed again.” – Source

Ok, what else should I do?

So before you go ahead with the second part, I’d still strongly recommend you deactivate the license either via the Admin Console or using the Adobe Licensing Toolkit. If not, you may be stuck with a ‘used’ SDL in your portal that it won’t be easy to flush out.

So the next step came from an older discussion in the #adobe channel

This directory lives at /Library/Application Support/Adobe/OperatingConfigs

Once you’ve de-activated the license, removing this directory and restart the Mac. This can either be manually, or via a script.

The next time you launch an Adobe App, you’ll be asked to login with an Adobe ID account with a license, or to start an Adobe trial! Removing this directory actually permanently removes the SDL from this Mac.

Outro

Another Adobe post 😉 I hope it makes things a little easier for someone 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.

Deactivating Adobe Shared Device Licenses

Hey folks, this post documents the two methods to deactivate Adobe Shared Device Licenses (SDL).

Some of you may be lucky enough to have unlimited SDLs to deploy out (I believe it’s those with ETLA agreements), but that does leave others who have to keep track of where they are in use.

How do I find out how many I’ve used?

Log into the Adobe Console at https://adminconsole.adobe.com with one of the your deployment administration accounts. On the main overview page, lookout for an item called “Creative Cloud All Apps for XXXX – Shared Device” (e.g. “Creative Cloud All Apps for K-12 – Shared Device”). This will then show you how many licenses you have, and how many have been deployed and activated. In the example below, we have 350 licenses paid for, and 24 used.

If you’re one of the luck ones with unlimited licenses, you’ll see your used license count on the left, and “1” on the right, as shown below

How do I find out where they’ve been used?

This one has a few more steps, log into the Adobe Console at https://adminconsole.adobe.com with one of the your deployment administration accounts. Navigate to “Products” in the top menubar, then select your SDL in the left hand side. Once here, click on the profile you are using (most folks will just be using one single profile).

Almost there! Once viewing the profile, click the ellipsis (“…”) in the upper right corner, and select “Create Report”. This will create and download a CSV report.

How do I deactivate those licenses from the console?

This method is recommended if the activated devices have been wiped, or no longer bootable. It’s also useful if you’re feeling lazy, but this will deactivate licenses for all devices under that profile.

First navigate to the same area you produced your report above. In the same ellipsis menu, you’ll see an option to “Recover Licenses”. Click this and confirm.

This will deactivate the license for any devices under this profile, which could be all of your devices. There is a possibility that this can cause issues if you have rendering jobs in progress, or users logged in and using the Adobe Apps, so please ensure to minimise this risk. Maybe only run this out of hours?

For devices that are in use, they will automatically re-activate the next time a user logs in with an Adobe ID:

“However, as soon as a users sign into Adobes app on each of these machines, the machines are immediately licensed again.” – Source

How do I deactivate those licenses from the device?

If the device/s in question are still operational, you can deactivate the SDL on the device by using the Adobe Licensing Toolkit. More details on using this tool can be found here, but we’ll summarise the steps below:

1. Log into the Adobe Console at https://adminconsole.adobe.com with one of the your deployment administration accounts.
2. Navigate to “Packages” > “Tools” > “Licensing Toolkit” > ” Download for Mac”
3. Open the downloaded disk image
4. Put the included “adobe-licensing-toolkit” binary somewhere on the device (or run from the disk image if that option is available on this device)
5. Run the binary with the flag --deactivate with admin rights

e.g. sudo ./adobe-licensing-toolkit --deactivate

Again, if someone logs in with an Adobe ID on that device after running the deactivate command, the device will automatically reactivate its SDL:

“However, as soon as a users sign into Adobes app on each of these machines, the machines are immediately licensed again.” – Source

I’ll discuss how to permanently remove the SDL from a device in a future post!

Outro

Another Adobe post 😉 I hope it makes things a little easier for someone 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.

Session Video is now live from MacAdmins Campfire Sessions 2020 (PSU 2020)

Hi folks,

The amazing team at PSU have been working hard releasing session videos within days of them being delivered. You can find the entire playlist on YouTube here.

Once again I delivered another Adobe talk! You can find a direct link to the video here, as well as an updated resources post here.

Again, I’d like to take the time to thank the great crew at PSU who made (and continue to make) a remotely delivered awesome conference a success. Fingers crossed that I’ll be able to make next years one!

And if you’re around for the next two Thursdays from 6PM BST, they’re still going. Details here.

What’s new with Adobe 2020 in Education – Content

Hi all,

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

This talk is a update of my previous talk Adobe CC2019 in Education – PSU 2019

Video

Slides

whats-new-with-adobe-2020-in-education-v2.0Download

Link Dump

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

• London Apple Admins – https://londonappleadmins.org.uk
• Daz Wallace – Adobe CC2019 in Education – PSU 2019
• Adobe – Identity types on Adobe Admin Console
• Adobe – Create Directories
• Adobe – Set up SSO with Azure AD Connector
• Adobe – Set up Google federation for SSO with Adobe
• Adobe – Set up the User Sync tool
• Sound Mac Guy – The Adobe User Sync Tool – I’ve got that “syncing” feeling
• Adobe – Migrate from Device Licensing to Shared Device Licensing
• dataJAR – jamJAR
• dataJAR – Auto-Update
• Daz Wallace – Catalina and Adobe Deployment: 6 Months On
• Daz Wallace – The Great British Adobe Test
• Daz Wallace – Catalina and Adobe Deployment Fixes!
• Adobe – Uninstall products using command line
• Daz Wallace – Using Adobe Creative Cloud Packager to create an uninstaller in preparation for Adobe Creative Cloud 2019 Shared Device License deployment
• Mac Mule – Customising The Adobe Creative Cloud Desktop App
• Sound Mac Guy – Customising the Creative Cloud Desktop App – what Adobe doesn’t tell you
• dataJAR – Adobe CC 2019 Recipes
• dataJAR – Adobe 2020 Recipes
• Adobe – Feature Request/Bug Report Form
• Adobe – Student access to Creative Cloud during COVID-19 campus closures
• Adobe – Shared Device Licensing | Deployment guide
• Adobe – Create Shared Device Licensing packages
• Adobe – Shared Device Licensing | What’s new
• Adobe – Shared Device Licensing FAQ
• Adobe – Manage shared device license profiles
• Adobe – Recover shared device licenses
• Adobe – Shared Device Licensing | Known Issues
• Adobe – Named User and Student Licensing Pack (SLP) Deployment
• Adobe – Creative Cloud for education deployment resources

Thanks again to everyone who could attend!

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

Last year I had the privilege of speaking at MacAdmins at PSU around Adobe 2019 and it’s use in education. You can find more on that here.

This year, I’m lucky enough to have another session, which I’ll be using to present on Adobe again, including some changes from 2019 to 2020.

MacAdmins Campfire Sessions?

With the current pandemic still affect most of the world, this year the folks at PSU elected to switch out the usual on-site deliver of the conference, in favour of a 2-session per week, remote delivery, over 9 weeks.

These are completely free and run 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 2020 in Education

As if my Adobe drum has been sitting ideal too long, I’ll be delivering an updated and refined version of the talk I gave last year, including any new things with 2020 from CC2019.

Over a year has passed since Adobe announced the new Shared Device Licenses. What’s changed? What hasn’t? How many bottles of [beverage] will you need to get you through it?
In this session we’ll look to cover the changes since that first release of CC 2019, SDL and now 2020. We’ll revisit the various deployment workflows and suggestions for taming this beast. Based on experiences from the front line and real world examples.

My talk will be on Thursday 16th July at 6:00PM 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.

I hope to see you there!

Catalina and Adobe Deployment Fixes!

Hey folks. This time I bring you good news: As of last week, the Adobe deployment issues I’ve been experiencing have been resolved!

I’ve re-built 36 different installation packages for the Adobe CC 2019 and 2020 suites, and all have installed successfully on macOS Catalina (10.15.4) both at the login window (via SSH / CLI) and via a Munki “RequireLogout” installation.

How do I get a hold of these fixed installers?

You’ll need to go into your Adobe Admin console, and recreate all of your CC 2019 and 2020 Application packages. If you’ve done this between Wednesday 20th May and today, you should have the fixed packages.

How do I check if I have the “fixed” packages?

It is indeed a long task to recreate your packages if you don’t need to (guess what I was up to last week / weekend), but it is possible you could have the fixes in the packages you have currently. I’ve included the steps below to check:

1) Unzip your downloaded Adobe Package/s

2) Navigate to ./[package name]/Build/[package name].pkg

3) Right-click the package and select “Show Package Contents”

4) Navigate to ./Contents/Resources/optionXML.xml

5) Open this in your XML viewer of choice

6) Look for the below line in the XML file. It should be in the “InstallInfo”>”HDMedias” dictionary.

  <SAPCode>LIBS</SAPCode>

7) In the “prodVersion” key, you need to have a version number of 3.8.26 or higher

8) In the “productVersion” key, you need to have a version number of 3.8.26.14 or higher

If you have both versions mentioned above (or newer), you should be good to go.

What is LIBS?

I’m afraid I’m not fully sure what the LIBS item is. It appears to be a collection of libraries Adobe use for various tasks. Evidently this also includes during installation!

Outro

Well… It’s taken 7 months since the release of the current OS, macOS Catalina, but we finally have a fix to deploy Adobe packages!

Big thanks to Foigus for rallying the troops, and “Dom Adobe” for listening to the issues and relaying this internally.

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.

Security Updates released for Adobe Acrobat Reader DC and Adobe Acrobat DC

On Tuesday 12th May, Adobe released critical updates for Adobe Acrobat Reader DC and Adobe Acrobat DC. These patch a vulnerability that allows an attacker to gain arbitrary code execution, with some reports claiming this to be as root.

Affected Versions

Adobe list the following as affected versions for both macOS and Windows:

Product	Affect Versions
Acrobat DC (Continuous)	2020.006.20042 and earlier versions
Acrobat Reader DC (Continuous)	2020.006.20042 and earlier versions
Acrobat 2017 (Classic 2017)	2017.011.30166  and earlier versions
Acrobat Reader 2017 (Classic 2017)	2017.011.30166  and earlier versions
Acrobat 2015 (Classic 2015)	2015.006.30518 and earlier versions
Acrobat Reader 2015 (Classic 2015)	2015.006.30518 and earlier versions

Patching Affected Versions

To patch Acrobat Reader DC, I’d strongly suggest using the AutoPKG recipe to package this up. You can find the recipes for this here.

To patch Acrobat DC, you’ll need to either:

• Use Remote Update Manager (RUM) to install the update; or
• Create an updated package from the Adobe Admin console.

Surprisingly, there is an issue with the Adobe Admin Console when it comes to Acrobat DC…well two issues:

1) The latest version listed for Acrobat DC is currently always v20.0, despite the version being 20.00X.XXXXX

The actual version is 20.006.20034!

2) Any existing packages created in the Admin console for Acrobat DC will show as “Up to date”, even if they’re not!

In this scenario, I’d suggest re-creating your package for Acrobat DC just in case to ensure you have a package for a patched version.

Note: These two issues have been logged with Adobe as of today (14th May 2020) so hopefully should be resolved at some point!

More Information

For more information, check out the following links:

• Adobe Security Bulletin – https://helpx.adobe.com/security/products/acrobat/apsb20-24.html
• Security Flaws in Adobe Acrobat Reader Allow Malicious Program to Gain Root on macOS Silently – https://rekken.github.io/2020/05/14/Security-Flaws-in-Adobe-Acrobat-Reader-Allow-Malicious-Program-to-Gain-Root-on-macOS-Silently/

Catalina and Adobe Deployment: 6 Months On

Update: Now fixed! See Catalina and Adobe Deployment Fixes!

Aka “The one where I moan!”

Hey folks. If my Google-Fu serves correctly, April 7th 2020 should mark 6 months since Apple dropped macOS Catalina 10.15 for the public. Based on previous years, this also marks the halfway point of this OS cycle.

I felt this was a good time to provide an update on the Adobe deployment issues I shared on a previous post, The Great British Adobe Test.

TL; DR?

The short answer is, nothing has changed. Deploying Adobe CC2019 and Adobe 2020 packages created from the Adobe Admin Console to macOS Catalina at the login window fails to work in my own testing (as well as a fair few others in the #adobe channel on Slack), six months after Catalina’s release.

A Quick Refresher

A quick refresher on the key points from my previous blog post:

• Installations of Adobe CC2019 and 2020 packages, created from the Adobe Admin Console, fail at the Login Window on macOS Catalina (10.15)
• The same installation packages, installed via the same method on macOS Mojave (10.14) work as expected
• The same installation packages, installed when a user is logged in, work as expected on macOS Catalina (10.15)*
• The failures happen if the installations are:
  • Ran via the installer command line tool, through an SSH connection
  • Ran via a Munki Optional Install with the “RequireLogout” key enabled.
• Even if the installer command reports a failure, the CCDA (Creative Cloud Desktop App) is still installed, but no other Adobe Apps are installed.

* As long as there is no conflicting Adobe process running!

Possible Workarounds

As part of the troubleshooting with Adobe Support, we’ve been trying a few workarounds with mixed success. Even though most / all of these are not usable for us, I thought I’d share them to see if they prove helpful to others.

Reinstallation

Simply re-run the exact same Adobe installation package after the first failure is reported to work for some Admins.

We could not get this to work for our testing.

Reinstallation, plus an install command

After the first Installation failure, run the below two commands:

cd "/Library/Application Support/Adobe/Creative Cloud Libraries/CCLibrary.app/Contents/libs"

sudo ./node ../js/customhook.js install

And then re-run the same installation package a second time.

This worked for us in manual testing, but we could not find a way to make this work with any automated deployments via Munki (lots of combinations of preinstall scripts, postinstall scripts, and chaining Adobe installs together with no success).

Force the package language

When creating the Adobe Package/s, force the language to be the same as the macOS language on the devices you’ll be deploying to.

This is done in the package creation wizard. Disable the “Use OS locale” option and set your language as required.

Untick/Turn off this option

We haven’t tested this option, purely as we work with plenty of multi-national companies and having to package, update, and manage a large number of packages for every single Adobe title is not practical (or indeed sane!)

What now?

So what now?

It’s been 6 months since Apple released macOS Catalina (potentially halfway through the OS release cycle) and we’re still not at a resolution.

We’re still working closely with Adobe Support and Engineering to try and get this resolved, but so far no luck.

And, full disclosure, there are some Mac Admins who have not seen the issue, but there’s also a bunch of us in #adobe who are fighting it.

Outro

Well, there’s an update post I’d rather was more positive…

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.

The Great British Adobe Test

Update: Now fixed! See Catalina and Adobe Deployment Fixes!

Aka “Adobe Deployment Testing: Autumn 2019”

Updated 2019.11.20 – See below

Updated again 2019.12.07 – See below

Hey folks. Hot on the heels of my last Adobe post, is another one! Strap in, it’s gonna be a long one…

Almost a month ago, Apple announced the release of their new macOS, Catalina. And there was much rejoicing.

Shortly after this, a few reports started to emerge in the MacAdmins #Adobe channel regarding deployment issues and this new OS.

I must admit, between other work commitments and time zone differences from here to the U.S. I missed a fair amount of the conversation. I found myself a little lost in what was confirmed and what was still suspected.

On November 7th Foigus shared a testing plan he’d completed to try and nail down some specifics. I decided to extend his testing further, both to confirm his findings and to check other conditions.

This post details the tests performed and the findings. Hopefully it’ll be useful to some!

TL; DR?

All Adobe installs on macOS Mojave (10.14.6) should work fine as before (with the usual random failures).

Almost all Adobe installs on macOS Catalina (10.15.1) at the login window will fail with the error code 84. Regardless of the result, CCDA will still be installed but no other Applications.

Testing Setup

The plan was to test a selection of packages, with various options across both ‘current’ macOS versions. This would also take into account different user scenarios and deployment techniques. In order to speed things up, I elected to use Virtual Machines for each test. This would allow me to quickly rollback changes between tests and allow repetition if required.

Virtual Machine Setup

I created two macOS Virtual Machines, both of which were assigned 2 processor cores, 4 GB RAM and 80GB of storage. These were built in the latest version of VMWare Fusion Pro (v11.5.0, build 14634996), with the latest non-beta release of the Munki tools installed (v3.6.4). One was built with the latest release of macOS Mojave (10.14.6, build 18G1012), with the other the latest build of macOS Catalina (10.15.1, build 19B88).

The creation process for each VM was:

1. Fresh installation of macOS in VMWare Fusion Pro using the relevant Install macOS application
2. Manual edit of the VM configuration file to add a ‘real’ Serial Number and a Model Identifier of iMac18,2
3. No MDM or management solution enrolment
4. Creation of 1 local administrator account (“Admin User”)
5. Creation of 1 local non-administrator account (“Non-Admin User”)
6. Log into each account to clear any first run or setup messages
7. Enabling of SSH and ARD (Remote Management) options
8. Installation of the VMWare Tools
9. Installation of all available macOS software updates
10. The Adobe Log Capture tool disk image copied into /Users/Shared/
11. Munki client tools installed and configured to use a test Munki Repo
12. No further additional software or applications installed
13. Shutdown of VM
14. VM snapshot taken.

This then formed the basis for the tests.

Applications Used

I decided to use 3 different Applications, all at the latest versions at the time of testing:

• Adobe CCDA only (5.0.0.354)
• Adobe Photoshop CC 2019 (20.0.7)
• Adobe Photoshop 2020 (21.0)

Packages Used

In order to test all options with the above Applications, 7 packages were created. All packages were created as NUL (Named User Licensing):

DW-Test-CCDA-SS-PKG

This package is a “Self-Service” package, with no other options or applications. It only contains the Adobe CCDA.

DW-Test-CCDA-Managed-PKG-Default

This package is a “Managed” package with the default options enabled. The language was left as “Use OS locale” and “English (North American)”. It only contains the Adobe CCDA.

DW-Test-CCDA-Managed-PKG-Extra

This package is a “Managed” package with the default options enabled plus all additional options. The language was left as “Use OS locale” and “English (North American)”. It only contains the Adobe CCDA.

DW-Test-Photoshop-2020-MGD-PKG-Default

This package is a “Managed” package with the default options enabled. The language was left as “Use OS locale” and “English (North American)”. It contains the Adobe CCDA and Photoshop 2020.

DW-Test-Photoshop-2020-MGD-PKG-Extra

This package is a “Managed” package with the default options enabled plus all additional options. The language was left as “Use OS locale” and “English (North American)”. It contains the Adobe CCDA and Photoshop 2020.

DW-Test-Photoshop-2019-MGD-PKG-Default

This package is a “Managed” package with the default options enabled. The language was left as “Use OS locale” and “English (North American)”. It contains the Adobe CCDA and Photoshop CC 2019.

DW-Test-Photoshop-2019-MGD-PKG-Extra

This package is a “Managed” package with the default options enabled plus all additional options. The language was left as “Use OS locale” and “English (North American)”. It contains the Adobe CCDA and Photoshop CC 2019.

macOS Versions Used

As mentioned above, all testing was performed on two versions of macOS, Mojave (10.14.6, build 18G1012) and Catalina (10.15.1, build 19B88).

Deployment Methods Used

I originally planned to use 4 different deployment methods for each test, however I didn’t have a license for Apple Remote Desktop (ARD), so I dropped this. This is still mentioned in the results spreadsheet but left blank. The 3 final deployment methods I decided on were:

• SSH / CLI, consisting of:
  • Copying the zipped installers to the VM into /Users/Shared/
  • Unzipping the installers on the VM
  • SSH’ing into the VM
  • Running the package with the command
  • sudo installer -pkg /Users/Shared/path/to/unzipped/package.pkg -target / -verbose
  • Successful installation criteria is an install successful message from the installer binary

• Munki, consisting of:
  • Adding the packages into Munki (stored in a disk image as they are bundle packages)
  • Initiating the installation via the Managed Service Centre “Update” button
  • Some tests had the installs also ‘require a logout’ to force an install at the login window.
  • Successful installation criteria is an install successful message from the Munki installer command

• GUI, consisting of:
  • Coping the zipped installers to the VM
  • Unzipping the installers on the VM
  • Double-clicking to launch the package in the installer application.
  • Successful installation criteria is an install successful message from the Installer App.

Scenarios Used

In addition to all the above components, I tested the following scenarios:

• Admin user logged in and screen unlocked
• Admin user logged in and screen locked before performing installation
• Non-Admin user logged in and screen unlocked
• Non-Admin user logged in and screen locked before performing installation
• No user logged in (at the login window)

The Testing Process

For each test, the same process was followed in order to maintain consistency:

1. Power up VM
2. Run the relevant test
3. If the test involved Munki, grab a copy of the logs from /Library/Managed Installs/Logs/ (no matter the result)
4. Run the Adobe Log Capture Tool and save the logs (no matter the result)
5. Copy log files to test numbered folder on VM Host’s Desktop
6. Restore VM snapshot.

Testing Tweaks and Changes

During the testing, 3 tweaks / changes were made:

• If a test failed, after the logs were gathered the VM was reverted and a repeat of the test was conducted. Logs were also collected and stored for the repeated test
• I realised I didn’t have a license for Apple Remote Desktop (ARD) so I skipped those tests
• Some theoretical scenarios were not possible and so were skipped. Examples include:
  • Running a GUI installation at the login window
  • Triggering a Munki install with a locked screen via Managed Software Center

Testing Results and Findings

So of the originally planned 280 different tests, 158 were actually performed. A full spreadsheet of the results can be found here. Green indicates a successful deployment, Red a failure, and yellow a test that wasn’t possible.

And so my findings…

• Sometimes deployments would fail in 10.14.6. No correlation between the failures, and second runs of the exact same test (on rolled back VMs) worked fine
  • This one I’m probably gonna chalk up to standard random failures
• If you enable the “Enable browser based login” for a package, each user login results in the Adobe CCDA auto-launching minimised, with an Adobe login page opened in the default browser
  • This might be an annoying new feature for most
• Installations on 10.15.1 via SSH/CLI at the login window resulted in a failure.
  • If this was a CCDA-only package, the CCDA still appeared to install and work fine.
  • If this was another package, the CCDA appeared to install and work fine, but the accompanying Application install did not.
  • Re-running this test under the same conditions occasionally resulted in a successful installation, even with the VM restored to the same pre-install point. No specific pattern was found.
• Some installations on 10.15.1 via Munki “logout required” (at the login window) failed.
  • As above, the CCDA still installed and appeared to work
• All installations on 10.15.1 via Munki “logout required” (at the login window) failed if they contained a version of Photoshop.
  • As above, the CCDA still installed and appeared to work but Photoshop was not installed

What now?

The issue has been raised by a number of Mac Admins in the Adobe channel and with Adobe themselves. I’ve also raised this with Adobe direct.

I’d strongly suggest you verify at least the failures I’ve mentioned above, then log tickets with Adobe support. Include your impact numbers and exact steps to replicate where possible.

Also, other Admins have been kind enough to share their ticket numbers, with a current list available here. Feel free to link them into yours, then add yours to the list.

From my own interactions, Adobe is aware of the issue and has escalated it to Product Engineering as a high priority bug. No details on an ETA to resolution yet.

Follow Up Testing

At the moment, I’m a little tested-out, but I’ve got further thoughts about follow up testing that may be useful if no progress is made:

• Testing with SDL Packages
• Testing with other Adobe applications
• Testing with Apple Remote Desktop deployments
• Testing with Jamf deployments
• Testing with other Mac management venders

Outro

Well there you go, that’s the full details of my testing of Adobe Packages last weekend!

Phew

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 2019.11.20

There have been some reports that issues with deployments on Jamf Pro should be resolved now. I conducted a second set of very compressed tests and found there is still no changes to the results I’ve found above.

Full breakdown of these additional tests can be found in the second workbook called “Round 2”, found here.

Update 2019.12.07

On the 5th December, there was further reports that more fixes have been implemented. I ran another very small selection of tests on macOS Catalina 10.15.1 at the login window and found there is still no changes to the results I’ve found above.

For the record, the new packages were created on the 5ht December from scratch, and tested on the 7th December.

Full breakdown of these additional tests can be found in the second workbook called “Round 3”, found here.

Adobe News Update 2019.11.12

Hey all, this is a combination of a number of posts I kept meaning to write but never got around to. It feels like enough changes and new things have come out that it’s become more valuable to spread the news (along with a little plug or two!)

Changes to Adobe Shared Device Licensing

Since I gave my talk at Penn State, there have been a number of updates, tweaks and changes to Adobe’s SDL:

2019.08.23 – Removal of 90-minute popup

Adobe releases an update to CCDA that removes the often complained about 90-minute timeout / popup.

If you’re on the latest version of Adobe SDL (v1.5 at the time), you don’t have to do anything. However, if you’re on v1 you’ll need to redeploy the CCDA in order to take advantage (Source).

2019.08.02 – User Provisioning from SSO / SAML providers

In August, it was found that if you link your Adobe web console to an Azure AD or Google Federated service for SSO / SAML, it can also be used for user provisioning. This means you are no longer required to use the User Sync Tool, CSV, or the web interface to create Adobe IDs for your users (Source).

The bad news is if you already have Azure AD / Google setup for SSO / SAML you will not be able to take advantage of this.

Helpful links:

• Configure Microsoft Azure for use with Adobe SSO
• Set up Google federation for SSO with Adobe
• Tutorial: Azure Active Directory integration with Adobe Creative Cloud

2019.10.XX – Dimension, Self Service and Sign in

In October, SDL saw 3 new features:

• Support for Adobe Dimension. Adobe Dimension is now fully supported for SDL licensed devices.
• You can now deploy SDL packages with support for Self Service installs and updates via the CCDA. Optionally you can also limit this to local admin users only.
• A new message is shown when SDL users log into the CCDA, asking them to logout and to ensure they save data off-device once they’re finished

2019.10.07 – 2019.10.28 – Venezuela and Executive Orders

In order to comply with a U.S. Government Executive Order, any customers registered in the country of Venezuela had their Adobe Apps licenses and cloud service access removed. Later on, Adobe was granted a license by the U.S. Government in order to continue providing their services.

TL;DR: Stuff changed for Venezuelans, then changed back (Source).

2019.10.24 – Adobe and Catalina

Shortly after Apple’s slightly surprising release of macOS Catalina, Adobe carried out some further testing and released a new KB outlining supportability and known issues. At the time I chucked up a post outlining the main information (Plug).

ETC…

It took me way too long to find this nice, constantly updated KB article from Adobe on all the changes that have come to Shared Device Licensing:

• Shared Device Licensing | What’s new

This is something that will be worth bookmarking and checking in on periodically going forward.

Changes to the way Admin console packages are downloaded

At the end of October, Adobe admins who downloaded newly created packages from the Admin console found that instead of providing the built package, Adobe instead provided a download of a new Application; the Adobe Package Downloader (APD?).

An official reason isn’t provided, but it’s believed this may be to help with the “quarantine bits” that get added to the zipped, downloaded packages (detailed in the KB – Known issues with Creative Cloud packages on macOS 10.15 Catalina).

Either way, the new process is to:

1. Build your package
2. Download the downloader (APD)
3. Use the downloader (APD) to download the zipped package
4. Unzip the package
5. Deploy / add to your deployment solution of choice.

You can run multiple APDs at the same time so there’s that… (source).

The release of Adobe (CC) 2020

Around November 7th, Adobe surprised us with a release of the latest instalment of their Creative Cloud Suite: 2020 (Source).

With this, all Apps and promotional material have dropped the “CC” from their titles. Helpful if you’re using Application titles to determine installs. Not so helpful if you’re managing Docks (although the path tends to change every year regardless).

As with prior major Adobe upgrades, Remote Update Manager (RUM) can’t be used to upgrade clients from CC201X to 2020 for most Apps. You’ll either need to install via CCDA, or create some new packages.

If you need to access the older Apps in the Admin console, you can use the “Show older versions” tick box as before.

Please Note: If you try to create an “Update Package” of your existing packages in the Admin console, they will be ‘updated’ to the 2020 version of Apps, so bear that in mind.

Updates to the dataJAR Adobe CC 2019 importer

During my Penn State talk earlier this year, we (dataJAR) shared the official release of a tool to import all the Adobe CC 2019 App packages correctly into both Munki and Jamf via AutoPKG (complete with corrected install arrays).

Last week, I had the fun task of working on this for Adobe 2020’s suite of Apps. Thanks to the work by Ben Toms (Mac Mule) it wasn’t too difficult a task and the updated scripts can be found here.

Deployment Issues with macOS Catalina

As alluded to in my last post, there were some reported issues trying to deploy any of the Adobe suite of Apps to any macOS Catalina devices. The #adobe channel on MacAdmins Slack was full of reports, however with the time difference between myself and my colleagues-from-another-employer, I found it tricky to follow.

Last weekend I went through 160 tests (of an originally planned 180+) covering various deployment techniques, scenarios, packages and both ‘current’ macOS versions (10.14.6 and 10.15.1) and documented the results. I’ll be writing that up shortly and plan to get it out by the end of the week.

Outro

Right, that’s all the current Adobe news I felt relevant all caught up. 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.