If you've ever had the misfortune of having to manage the deployment of Adobe applications at scale, then you'll most likely be well aware of the Adobe Update Server (AUS) and the Adobe Update Server Setup Tool (AUSST).
What is AUSST
In an enterprise environment, you usually have many users who require various Adobe apps and updates. Each user is required to download and install the apps individually. Allowing all your end users to individually download and install apps from the Adobe servers will consume a sizeable amount of network bandwidth in your organization.
To address the issue of network bandwidth consumption, Adobe provides Adobe Update Server Setup Tool (AUSST). AUSST enables you to centralize the download of Adobe apps and updates to a server location. After implementing AUSST, you can redirect your end users to download the Adobe apps and updates from the internal update server. This way, a single download from the Adobe servers is required for each app or update.
– Shamelessly copied from https://helpx.adobe.com/enterprise/using/update-server-setup-tool.html
Sounds like a really useful tool, right? Wrong. If it's not something you've ever had to deal with, continue to pray you never have to lay hands on it. The Adobe forums are plagued with people asking why it does things, and why it doesn't. There are countless threads where Adobe "support" answers once or twice, suggests you contact them directly, and then proceed to ignore you for eternity. It provides an intermittent, unreliable service at best. I guess they're keeping it in line with all of their other products and services ...
The Problem
As with most companies, recent times dictated that many of our employees began working from home. This now meant that all of those devices that were configured to contact our internal update server for Adobe updates were now hammering back over the VPN resulting in the following:
Internal Update Server - Downloads updates (if you're lucky)
Client requests update
Overrides point to internal server
Client connects to internal server over VPN
Client downloads update from internal server
On an internal network without the VPN, this would be fine. But now we're just wasting resources. Not only that, but if your internal server is having a moment, then your clients aren't going to receive the updates, as they won't query Adobe directly.
And that server moment is precisely the thing that's happened. Again. Despite the permissions being correct, and the content being available on the server, it's returning 404's and 401's to the client requests. My only remaining option is to completely rebuild the server and start from scratch. But I've got clients that need updates now to mitigate CVE's that affect us.
The Solution
So, what can you do when your internal server isn't available? Well, according to Adobe, you make sure you tick a little box when creating the overrides on the admin dashboard - https://helpx.adobe.com/lt/enterprise/using/update-server-setup-tool.html - "What happens if your internal update server is down" (because who wants anchor links ...)
Well, that seems simple enough. But wait a minute, how are my existing clients going to know about this change if the package has already been installed (package and overrides were created by someone else). I'm not being prompted to change the configuration on the server, because it's "down", and the overrides file on the machine is telling it to get the updates from adobeupdates.yourdomain.com (please note: this is probably a really, awful idea, especially if it's available externally without a VPN).
After ticking that box, I diffed the override XML. To my complete lack of surprise, nothing had changed. I generated a new installer package, and after searching for far too long, I finally found the reference to the bypass.
Hiding in a file named Binary.optionXML, there's a section with the following:
<feature>
<name>AdobeFallbackForAUSST</name>
<enabled>true</enabled>
</feature>All I needed to do next, was find out where this particular block needed to be added. After more searching and file content indexing, I found that the other settings stored with this block are in the ServiceConfig.xml file. This can be found in the following location
Windows: C:\Program Files (x86)\Common Files\Adobe\OOBE\Configs\
macOS: /Library/Application Support/Adobe/OOBE/Configs/
Insert the fallback block in to this file somewhere and save it. It will probably look a little something like this:
<config>
<panel>
<name>AppsPanel</name>
<visible>true</visible>
</panel>
<panel>
<name>FilesPanel</name>
<masked>false</masked>
</panel>
<panel>
<name>MarketPanel</name>
<masked>false</masked>
</panel>
<feature>
<name>SelfServeInstalls</name>
<enabled>true</enabled>
</feature>
<feature>
<name>BrowserBasedAuthentication</name>
<enabled>false</enabled>
</feature>
<feature>
<name>SelfServePluginsInstall</name>
<enabled>false</enabled>
</feature>
<feature>
<name>AdobeFallbackForAUSST</name>
<enabled>true</enabled>
</feature>
</config>After you've made this change, you'll need to restart the machine. Restarting the Creative Cloud Desktop application didn't seem to have any affect. Probably due to the disgusting number of processes it holds open in the background, despite being "Quit". Trying to end all of these manually just isn't worth the effort.
Deploying the Fix
If this works for you in test, then the only thing left to do is to deploy the change to your devices. I felt that this would be easier than re-creating packages and deploying those out, due to the vast difference in file sizes. You should always consider that some users may have bandwidth / usage caps. ~5 KB file rather than a few hundred MB is far easier to manage (yes, the Windows Creative Cloud Desktop App is almost 800 MB by itself).
With the majority of our Windows-based devices now being co-managed via Intune ... Sorry, Microsoft Endpoint Manager, I'll be pushing the file out as a Win32 app. This allows me plenty of control to make a copy of the existing file while copying the new file to the locations required.
For our macOS-based devices, I'll be pushing that out with Jamf. I'm not sure which method I'm going to use for this yet. I'm torn between creating a package with the new file in it, or using a combination of a script to make the copy, and then pull the updated file from an internal repo.
On typing that, and with a few minutes reflection. I think I will create a package with the file, and a preinstall script to make a copy of the old one before "installing" the new one.
Pro's & Con's
Doing this may not be an option for everyone, especially if you need to tightly control the versions that are being deployed within your environment. But for those of us who were just trying to save on data costs from within the network, this may be an option.
By doing this, you are telling the client to reach out directly to Adobe in the event that your internal server isn't contactable. You could then block access to your server via the VPN, ensuring that anything physically outside your network will contact Adobe directly. Those still inside will attempt to download from the server first.
- Pro - External users are no longer hammering the VPN tunnels with Adobe updates
- Pro - In the event that your internal update server is down, clients can still download their updates and stay up-to-date with patches
- Pro - Smoother experience for the end user
- Con - Loss of control over deployed versions
- Con - If your internal server is down, your internal devices could potentially give your connection a beating
Even that second con isn't necessarily a forgone conclusion. Anything that physically remains inside your network, such as a desktop, could always be excluded from receiving the new file.
Important: Keep in mind that any future packages generated via the admin portal will contain this fallback option.