Upcoming changes to Adobe Creative Cloud apps in App Installers

[JustinC]

If you are an admin that has access to the Adobe Admin Console, you can control what services and apps are available to users via the Creative Cloud desktop app. The following Adobe support articles document what customization options are available

https://helpx.adobe.com/enterprise/using/customize-creative-cloud-app.html

The settings are controlled on the end user machine by the ServiceConfig.xml file that is installed alongside the Adobe application withing the following location /Library/Application Support/Adobe/OOBE/Configs/

Since the launch of App Installers in Jamf Pro 10.37, the ServiceConfig.xml that App Installers installed alongside any Adobe deployments had the following settings configured:

Adobe Admin Console option	Adobe Admin Console value	ServiceConfig.xml key	ServiceConfig.xml value
Enable self-service install	No	AppsPanel	false
Allow non-admins to update and install apps	No	SelfServeInstalls	false
Disable auto-update for end-users	Yes	AppsAutoUpdate	false
Enable self-service plugin install	Yes	SelfServePluginsInstall	true
Disable file syncing	No	FilesPanel	false
Enable browser based login	No	BrowserBasedAuthentication	false
Enable install of beta apps	No	AppsCategories	false

Unfortunately this had the unintended consequence of regardless of what settings you may have previously set in your environment, the existing ServiceConfig.xml on an end users computer was overwritten by the one from App Installers as soon as their machine was in scope for an App Installers deployment for even a single Adobe Creative Cloud application. It also meant that your end users would see the following message from with the Creative Cloud desktop application "Youdon't have access to manage apps" even if you had previously had that option enabled.

Every Adobe Creative Cloud application published in App Installers from 1 June 2023 will now have the (default)settings configured:

 

Adobe Admin Console option	Adobe Admin Console value	ServiceConfig.xml key	ServiceConfig.xml value
Enable self-service install	Yes	AppsPanel	true
Allow non-admins to update and install apps	Yes	SelfServeInstalls	true
Disable auto-update for end-users	Yes	AppsAutoUpdate	false
Enable self-service plugin install	Yes	SelfServePluginsInstall	true
Disable file syncing	No	FilesPanel	false
Enable browser based login	No	BrowserBasedAuthentication	false
Enable install of beta apps	No	AppsCategories	false

The only exception to the default settings is the AppsAutoUpdate key being set to false. This will only prevent silent updates occurring in the background, as they are known to conflict with App Installers updates when both run at the same time, which can render the affected app unusable.

We have also made a change to the installation process so that the App Installers deployment will first check for the presence of the ServiceConfig.xml and if it exists, will not overwrite the file and will instead continue with the rest of the installation unless we detect that the AppsAutoUpdate value is true in which case it will be changed to false.

As a result of doing this check, if the end user computer has the previous ServiceConfig.xml provided by App Installers installed, it will not update it to the new one. You will first need to remove the existing ServiceConfig.xml from the end user computer. We would suggest that you do this by running a script to be run by a policy that contains the following command:

rm -f "/Library/Application Support/Adobe/OOBE/Configs/ServiceConfig.xml"

Once removed you can either deploy a replacement file (that you have generated from the Adobe Admin Console) to the required machines via a Jamf Pro Policy or just let App Installers install the new default file the next time it updates an Adobe Creative Cloud application on the Mac.

We hope that this change resolves a number of the end user experience issues that many of you have faced maintaining Adobe applications in your environment with App Installers.

[obi-k]

Thanks for posting. This is one of the gotchas that got us when we tried pushing the Photoshop update via App Installers. Users would call in with the "You Don't Have Privileges Message." 

Ended up putting a script to remove Adobe CC app and the OOBE folder in Self Service, then re-installing Adobe CC.

We want to Enable browser-based login (helps with our SSO issue) and Enable Auto-update for end users. So it doesn't look like we can use App Installers because Jamf will flip those to false.

[jhuls]

For what it's worth auto-update isn't all it's cracked up to be.

[JustinC]

The only value that we will overwrite is the autoupdate value. If you create your own ServiceConfig.xml file with the browser based login setting enabled, we do not change it. It is also worth clarifying that the autoupdate flag being set to false just stops the apps from trying to update themselves in the background. With this flag set to false the apps will either get updated by App Installers OR end users can manually update the application from within the Creative Cloud Desktop app.

[mm2270]

"We have also made a change to the installation process so that the App Installers deployment will first check for the presence of the ServiceConfig.xml and if it exists, will not overwrite the file and will instead continue with the rest of the installation unless we detect that the AppsAutoUpdate value is true in which case it will be changed to false."

The above is a welcome change for me. I work in a rather uptight and highly controlled environment and our software management team insists that we turn off all user controllable options for Adobe CC deployments and making sure users cannot self update. I know, it doesn't make a lot of sense, but it's how they roll and how we need to do it to stay in line with stringent compliance controls. So we have to push (or pull) updates down through management, i.e. Jamf policies or scripts. Users cannot update to the latest versions themselves.

So if Jamf App Installers will leave the default settings in place now and not overwrite them, that's good news! It means at some point I can begin using Jamf App Installers to update our Adobe CC applications, which I could not previously consider. Thanks for this!

[bfrench]

I am just getting started with deploying Adobe Acrobat.  My plan was to deploy the  Creative Cloud managed pkg from the Admin Console and then deploy Adobe Acrobat via the Jamf App Catalog.  I noticed that when then Adobe Acrobat app installed it also installed the Creative Cloud app.  Is the point of the managed package just to deploy management options? Is it necessary? 

[Jenncat]

Did you ever get an answer to this?

[glennu]

This is great! I opened a ticket about this back in August pointing out that XML file and folder and I suspected it was the App Installer being picky! Thanks for confirming and so glad this is taken care of!

[jporter1]

I appreciate this write-up, very detailed. Thank you.

[DaneAbernathy]

I just came across this post and I wonder if this issue I am having is due to this.

Here is what's happening:

• Adobe CC packaged from Adobe Admin Console - as a Flat Package (why did it take them so long?) with these settings:
  
• Policy pushed Adobe to lab computer, Adobe CC Installs
• Jamf App Installer for all the apps is scoped via self-service (also tried installing automatically and am getting the same situation I am about to explain)
• When you install, or Jamf auto installs, one of the Adobe apps, Adobe CC gets completely uninstalled and the app you are trying to install, never installs

Do I need to make my settings match the ones in your screenshot?

[DaneAbernathy]

Well, I just tried this, and it still happened. I can see in the install.log file that the OS is removing Creative Cloud.app