AUSST not downloading Acrobat DC internally

Report · May 27, 2018

Hi All,

Recently, instead of any download & installation of Acrobat DC going via our local product repository set up as part of our AUSST deployment, it attempts to go externally to download from the Adobe servers (blocked by our proxy by default). All other products such as, Photoshop, Illustrator, Premiere, etc. all download as they should from our internal repo.

We've completed a fresh synchronisation twice now - to no avail. It is only the Acrobat DC product which is affected.

Any way to get all download requests to reach our internal services like all our other products?

Thanks in advance,

JT

Report · May 28, 2018

Moving this to the correct forum: Enterprise Deployment (Acrobat and Reader)

*Response Editted.

Report · Jun 05, 2018

Would you be able to consider re-categorising my post instead of keeping it in the selected forum? My issue is not with Installing, or Updating & Subscribing. My issue is that Acrobat will not get sourced from AUSST (internal repository) and continuously seeks to venture out to Adobe's download servers (which in our organisation, blocks that particular traffic by default).

Report · Jun 06, 2018

Hi JT,

Sorry for the delay in response.

When you deployed Acrobat have you turned off the automatic updates for Acrobat? Do you have Adobe RUM in place in your update setup environment: Use Adobe Remote Update Manager For information AUSST: Use the Adobe Update Server Setup Tool (AUSST)

You may also contact our technical support immediate assistance.

-Tariq Dar

Report · Jun 06, 2018

Hi Tariq,

Thanks for the response! When we originally used Creative Cloud Packager, we had selected 'Use internal update server' and specified our internal AUSST server as the endpoint, we disabled AUM, but kept RUM enabled.

The way in which we synchronise products to our AUSST server is by using the "AdobeUpdateServerSetupTool.exe" executable with either Incremental or Fresh switches. We've not had to employ the use of "RemoteUpdateManager" commands to perform these tasks. Is your recommendation to use "RemoteUpdateManager" instead of "AdobeUpdateServerSetupTool.exe"?

Further info:

We also have an Overrides file that we apply to each Creative Cloud installation that points back to our the AUSST web server to consume the Application list as well as the executable files needed for installation (typical AUSST architecture).

JT

Report · Jan 03, 2019

*Bump*

This is still a problem/annoyance. I'm hoping to see if there's anything available recently to try given the last response was over 6 months ago.

DLM.log states immediately that it's trying to reach 'ccmdls.adobe.com/AdobeProducts/APRO/19'... The same folder with abbreviation APRO doesn't exist within the freshly synchronised file repository we have internally. The only Acrobat files we've been able to obtain is when we utilise the --acrobatonly switch with the AUSST utility; and even then, only synchronises patch/update files - not base installations. On that basis, are we then required to create a specific deployment for Acrobat DC initially (in our case, SCCM), which, once the Creative Cloud desktop client recognises there's an installation present - it then allows future updates via our internal AUSST repository?

Does Adobe not intend to allow Enterprise customers to download it in this fashion like all their other products - or is there a way to modify the XML/JSON objects to route this internally? Surely it's possible, but it would require a similar file hierarchy as all the other CC products available.

JT

Report · Jan 06, 2019

I also have this issue.

Report · Jan 07, 2019

Update

After creating an SCCM deployment specifically for Acrobat DC, it appears that in combination with the Creative Cloud desktop client, updates are completing as expected. IIS log demonstrating this below:

HEAD /Acrobat/arm-manifests/win/ArmManifest2.msi - 80 - #.#.#.# Microsoft+BITS/7.8 - 200 0 0 31

GET /Acrobat/arm-manifests/win/ArmManifest2.msi - 80 - #.#.#.# Microsoft+BITS/7.8 - 200 0 0 0

HEAD /Acrobat/pub/adobe/acrobat/win/AcrobatDC/1901020069/AcrobatDCUpd1901020069_incr.msp - 80 - #.#.#.# Microsoft+BITS/7.8 - 200 0 0 15

GET /Acrobat/pub/adobe/acrobat/win/AcrobatDC/1901020069/AcrobatDCUpd1901020069_incr.msp - 80 - #.#.#.# Microsoft+BITS/7.8 - 200 0 0 609

It's not ideal, but until Adobe can introduce the base installation for Acrobat DC like all other products - this at the very least, works without needing to grant special access to our users through our corporate proxy. The updates are also automatic - so other clients obtained the incremental update without an issue.

At this point in time, there is no correct answer, and the issue remains unresolved from the originally stated issue.