The Great British Adobe Test

Aka “Adobe Deployment Testing: Autumn 2019”

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.

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.

Adobe and macOS Catalina

This evening Apple released their latest Mac operating system, macOS 10.15 or Catalina. This was just in time for the folks this side of the pond to get home after an evening of work (totally not annoying 😉).

Around the same time, Adobe released a related KB, Known issues with Creative Cloud packages on macOS 10.15 Catalina.

TL; DR

The KB isn’t too long and is certainly worth a read but there are 4 key points:

1) The zipped archive/s downloaded from the Adobe Admin web console will contain a quarantine bit. In macOS Catalina you won’t be able to unzip these until the quarantine bit is removed. Workaround: Remove this using the below command, then extract the packages from the zip and deploy as normal:

xattr -d com.apple.quarantine /path/to/zip

2) If your packages were created before 16th September 2019, they may fail to deploy on 10.15 devices if they are extracted on a 10.15 device. Workaround: Create a new update package, create a brand new package or extract the package on a device that isn’t running macOS Catalina

3) Adobe Creative Cloud Packager (CCP) can (will?) create packages containing 32-bit components, and these will fail to install on macOS Catalina. Workaround: If you need to deploy these packages to 10.15 devices, you will need to delete the two following paths before deploying the package (also note point 4 below):

[PackageName]/Build/[PackageName]_Install.pkg/Contents/Resources/ASU2

[PackageName]/Build/[PackageName]_Install.pkg/Contents/Resources/Patches/AdobeApplicationManager-1.0_update14

4) CC2018 and early Adobe applications contain 32-bit components and will not launch on macOS Catalina. Workaround: Only Adobe CC2019 Apps are compatible with macOS Catalina and you will need to upgrade.

BONUS:

5) There looks to be an issue when running Adobe Admin Console generated deployment packages on macOS Catalina in certain contexts, which cause the installs to fail. This is still a developing issue and looks to possible affect Jamf and Munki deployments, as well as deployments over SSH (it’s not known if it’ll affect other management deployment tools but it is likely).

Some working of the issue can be found in the Munki-Discuss mailing list and if you’re affected, it is strongly recommended to log tickets with Adobe and / or Apple.

Hmm, how do I postpone the install of macOS Catalina until I can workaround these?

Mac Mule (Blocking macOS Catalina With Jamf Pro) and Rich Trouton (Preventing the macOS Catalina upgrade advertisement from appearing in the Software Update preference pane on macOS Mojave) have you covered.

Summary

This post covers the newly released Adobe KB regarding known issues with macOS Catalina. 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.

Installing the Jamf Software Server (JSS) onto Windows Server – Crib Sheet

Hey all. As mentioned previously, I recently had a requirement to install a Jamf Software Server onto a Windows Server on-premise. In case you didn’t notice, I’m a big fan of crib sheets and checklists to ensure that, in the heat of the moment, I’m not missing steps unknowingly.

This post is part-update, part-new version of my almost 2 year old Amsys post “Jamf Pro Server / Casper JSS Windows Upgrade Crib Sheet“. It’ll also pull from a few Jamf KB articles that are linked at the end.

It’s designed to act as a starting point for your own crib sheet / checklist for a fresh JSS install, as well as a possible basis for an upgrade crib sheet. It won’t go into all the customisations and options you may require for your environment so make sure to test everything and adapt as required. This also assumes you’ll be running the JSS on port 8443 and MySQL and Tomcat on the same server.

PLEASE NOTE: Before you touch anything, and at various points throughout, TAKE BACKUPS. I’m serious, they’ll get you out of trouble more times then you want and you’ll be glad each time.

Dates and Versions

In order to ensure this ages as gracefully as possible, I’m including dates and versions of the items used to build this guide. Please always check the KBs and your own notes in case of any changes required.

• Date drafted: 2019-08-18
• JSS Version: 10.14.0
• Java Version: 11.0.4.11.1
• MySQL Version: 8.0.17

The Guide

Without further ado, lets get cracking

Installing Java and MySQL

1) Download the Windows .msi for Corretto Java from here

2) Run through the standard installer for Corretto Java

3) Download the MySQL Community Server 64-bit MSI installer for Microsoft Windows from here

4) Launch the installer and pick “Server Only” for setup type and click Next

5) The installer will check the environment before continuing. If the ‘Microsoft Visual C++ Redistributable’ needs to be installed, it’ll let you know. If so, click ‘Execute’ to install it. Click Next

6) Click Execute to start the install

7) Once complete, you’ll be taken through the initial configuration options

8) Select the “Standalone MySQL Server” option and click Next

9) Select “Server Computer” and click Next

10) Select the “Use Legacy Authentication Method (Retain MySQL 5.x Compatibility)” and click Next

11) Set a password for the MySQL root account and click Next. Ensure it’s a long and complex password and is recorded somewhere safe.

12) These should be set by default, but ensure the options for “Configure MySQL Server as a Windows Service”, “Start the MySQL Server at System Startup” and “Standard System Account” are enabled. Click Next.

13) Click “Execute” to apply the configuration

14) Click “Finish” to complete the install and close the installer.

Configuring MySQL

1) Stop the MySQL server (either via the command line, or via the “Services” Windows application).

2) Make a backup of the MySQL configuration file (normally found at C:\ProgramData\MySQL Server 8.x\my.ini )

3) Open this file in your preferred code editor (don’t forget about possible issues with Notepad, as discussed here!)

4) Find the line [mysqld]

5) Add the following on a new line below this:

default-authentication-plugin=mysql_native_password

6) Find the setting for innodb_buffer_pool_size

7) Edit this to a value appropriate for your server. The Jamf KB discusses this in detail but an example I’ve used initially is:

12GB Total Server RAM = 6GB for the Tomcat service, 2GB for the host OS, and so 4GB for the innodb_buffer_pool_size

8) Find the setting for innodb_file_per_table and set this to 1

9) Save the file and restart MySQL

Create the MySQL Database

1) Launch the “MySQL Command Line Client”

2) Enter the MySQL root password we set above

3) Run the below command to create the Jamf Pro database, swapping out [MyGreatDatabase] for the database name of your choosing.

CREATE DATABASE [MyGreatDatabase];

4) Run the below command to create the JSS database user, swapping out [MyDatabaseUser] for a username of your choosing, and [MyDatabaseUserPassword] for a long and complex password for this user. Ensure it’s recorded somewhere safe.

CREATE USER '[MyDatabaseUser]'@'localhost' IDENTIFIED WITH mysql_native_password BY '[MyDatabaseUserPassword]';

5) Grant this user access to the database, swapping in the values as before:

 GRANT ALL ON [MyGreatDatabase].* TO '[MyDatabaseUser]'@'localhost';

6) Exit the application

exit

Jamf Pro Software Server Installation

1) Run the downloaded Jamf Pro Server installer .msi as the Local Administrator User (not a network user with local administration rights). Ensure to run a ‘complete’ install

2) Once complete, stop the Tomcat service (either via the command line, or via the “Services” Windows application).

3) Find the Jamf DataBase.xml file (normally in C:\Program Files\JSS\Tomcat\webapps\ROOT\WEB-INF\xml\DataBase.xml)

4) Take a backup of this file and open it in your code editor of choice

5) Edit the DataBaseName, DataBaseUser and DataBasePassword with the values set when you created the MySQL Database

6) Save and close the file

7) Start the Tomcat service, and ensure the webpage loads as required.

8) Launch the Jamf Pro Server Tools from C:\Program Files\JSS\bin\server-tools-gui.jar

9) Go to “Tomcat Settings” and find the “Tomcat maximum memory” field

10) Set this appropriately for your server (see “Configuring MySQL” – step 7 above)

11) Restart the Tomcat service.

Configure Database Backups

1) Launch the Jamf Pro Server Tools from C:\Program Files\JSS\bin\server-tools-gui.jar

2) Go to “Scheduled Backups”

3) Configure this as required

Links

• Installing Java and MySQL for Jamf Pro 10.14.0 or Later
• Configuring MySQL 8.0 for Jamf Pro
• Manually Editing the Database Connection
• Editing the Database Connection Using Jamf Pro Server Tools
• Starting and Stopping Tomcat
• Jamf Pro Web App Memory
• Backing Up the Database
• Installing Jamf Pro Using the Installer
• Creating the Jamf Pro Database Using the Jamf Pro Server Tools Command-Line Interface
• SSL Certificate

Summary

This post covers a template crib sheet / check list for a new Jamf Pro Server installation on Microsoft Windows Server. 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.

Editing the MySQL Configuration File on Windows Server

Hey All. I recently had a requirement to install a Jamf Software Server to an on-premise Windows Server. Typically, this is not something we’d do at dataJAR, preferring to host customers on our own .mobi platform.

As part of the installation process, I had to make some tweaks to the MySQL configuration file, located at  C:\ProgramData\MySQL Server 8.x\my.ini. Typically, I’d download and use the Notepad++ free source code editor to ensure that the file remains in plain text (ANSI) and no fancy “smart” quotes or dashes are added. However as this was to only be a few edits, I decided to just rock-on with the built in Notepad App.

I made a copy of the file, made my edits as per the Jamf documentation, saved and restarted MySQL.

The service failed to start…

Huh? I must have screwed something up

My first thought was I must have used an unexpected value somewhere or otherwise ‘fat-fingered’ the changes. I restored the original copy of the file and the service started fine.

I went back in, made my changes again (being extra careful) , saved the file and restarted MySQL.

The service failed to start again…

Weird

Ok, I restored my backup file, restarted MySQL and all worked again.

This time I opened the file in Notepad, made no changes and re-saved the file. I restarted MySQL and…

The service failed to start again!

Help from the Interwebs

As with most IT issues, I did a quick Google search to try and find if someone else had the same issue. After some digging and lots of trying of ideas, I came across this post.

It turns out the default MySQL 8.0 my.ini file on Windows has some text that Notepad transforms into non-ANSI characters when you save the file, rendering the configuration file invalid!

The line in question contains the following:

1. “Unique” means that each ID must be different.

Those double quotes get changed to “smart” or curly quotes and the file is saved as non-ANSI.

The fix, or TL;DR

Either edit the file using the command line, or a code editor like Notepad++, or remove that line and have Notepad Save-As the file as ANSI.

After this, restart MySQL and the service starts as expected!

Summary

This post covers a workaround when installing MySQL 8.0+ on Windows and editing the configuration file causes the service not to start. 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 Videos are live from MacAdmins at Penn State 2019 (PSU 2019)

Hi folks,

The amazing team at PSU have finished their work and released the session videos for the 2019 conference. You can find the entire playlist on YouTube here.

This was my first non-domestic talk and (as no surprise) it was on Adobe 2019!

You can find a direct link to the video here, as well as an updated resources post here.

I’d like to take the time to thank the great crew at PSU who made an awesome conference a success. Fingers crossed that I’ll be able to make next years one!

Adobe CC2019 in Education – PSU 2019

Hi all,

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

This talk is an extension and expansion of my previous meet up talk Moving out of the Pool: Adobe’s new Shared Device Licensing.

Video

Video

Slide-deck

deployment-considerations-and-workflows-for-adobe-cc2019-in-education-1.3-1.pdf

Attendee Notes

Massive thank to Nate Felton, there’s a Google Doc provided to attendees to allow them to make notes on the session. I’ve linked this here.

Links

As promised, here is a list of all the links from the presentation:

• Mac Mule: Adobe Creative Cloud 2019, The Death Of Creative Cloud Packager, Serial Numbers & Device Pool Licensing
• Mac Mule: Adobe Shared Device Licensing
• Adobe-supported identity types
• Adobe Set up the User Sync tool
• Sound Mac Guy: The Adobe User Sync Tool – I’ve got that “syncing” feeling
• Adobe Set up user identity in the Adobe Admin Console
• Adobe Enabling Single Sign-On with SAML
• Adobe Create Named User Licensing Packages
• Adobe Shared Device License Webinar
• Adobe Check expiration of volume or CC enterprise serial numbers with AdobeExpiryCheck tool
• Adobe Shared Device Licensing | Deployment guide
• Adobe Migrate from Device Licensing to Shared Device Licensing
• 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: Modifying the deployed CCDA after deployment 
• Sound Mac Guy: Customising the Creative Cloud Desktop App – what Adobe doesn’t tell you 
• dataJAR’s Adobe CC2019 import tool
• Daz Wallace: The Great Adobe Purge of ’19
• Adobe Coming soon – Automatic student asset migration for education

Aaand follow ups I suggest reading / viewing when you get the chance:

• Adobe Application Manager Enterprise Edition (AAMEE)
• Sound Mac Guy: Adobe Shared Device Licensing – Answers to questions you probably didn’t want to ask
• Daz Wallace: University of Utah MacAdmins Meeting, and Adobe’s new SDL licensing – The Content!
• Adobe Licensing overview
• Adobe GitHub User Sync tool configuration wizard
• Adobe Deploy Packages for Adobe Creative Cloud
• Adobe Shared Device Licensing FAQ
• Adobe Creative Cloud for education deployment resources
• Adobe Manage identity types in Adobe Enterprise Offerings
• Adobe Shared Device License 1.5 webinar 
• Adobe Shared Device Licensing | What’s new
• Adobe Recover shared device licenses
• Adobe Apps not available in Creative Cloud Packager | CC 2019
• Adobe Shared device configuration User Access Policy
• Adobe User Sync Tool Documentation
• Adobe Create Shared Device Licensing packages
• Adobe Use Adobe Remote Update Manager