Mac Admin

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.

Standard
Mac Admin

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:

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

Standard
Mac Admin

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.

Standard
Mac Admin

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.

Monty Python And There Was Much Rejoicing GIF - Find & Share on GIPHY

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) :facepalm: 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.

Standard
Mac Admin

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:

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:

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.

Standard
Mac Admin

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.

Standard
Mac Admin

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

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.

Standard