Skip to main content
impoole691974
impoole691974
Participating Frequently
May 12, 2026
Answered

AUSST fails to generate webfeed due to 404 on AcroRdrClassicx64Upd2400130365_MUI.msp. Anyone else hitting this? Adobe support hasn't been able to engage on it.

  • May 12, 2026
  • 5 replies
  • 108 views

ISSUE: AUSST 6.3.0.1 silently fails to generate webfeed manifest 
(updaterfeed.xml) due to AcroAUSST sub-tool returning error 9 on a 
404 from Adobe's CDN.

ENVIRONMENT:
- AUSST version: 6.3.0.1 (also reproduced on 6.2.0.3)
- OS: Windows Server 2019
- Web server: IIS
- Storage: D:\inetpub\wwwroot\updates

ROOT CAUSE:
AcroAUSST attempts to download:
https://ardownload3.adobe.com/pub/adobe/acrobat/win/AcrobatClassic/2400130365/AcroRdrClassicx64Upd2400130365_MUI.msp

This URL returns HTTP 404 (verified via Invoke-WebRequest from the 
AUSST server). AcroAUSST returns error code 9. The parent 
AdobeUpdateServerSetupTool then reports exit code 0, masking the 
failure. Webfeed manifest generation does not occur.

 

IMPACT:
- AUSST server cannot serve updates to clients
- All clients receive error 113
- Affects all AUSST deployments syncing current Acrobat updates
- No documented workaround

REQUESTED ACTION:
1. Restore the missing file at the URL above, OR
2. Remove the broken reference from the AcroAUSST manifest, OR
3. Patch AcroAUSST to skip individual file failures rather than 
   aborting the entire manifest-generation step

    Correct answer Tariq Ahmad Dar

    Hi ​@impoole691974, 

     

    Thank you for your patience. 
    The engineering team have updated the list and technically AUSST shouldn’t be able to find this feed anymore. The the list has been updated and refereshed, let me know if you are still getting this error. 

     

    ~Tariq

    5 replies

    impoole691974
    impoole691974Author
    Participating Frequently
    May 21, 2026

    Thanks - On another sync that reference has disappeared and successfully sync’d. Attached report on the next bug, which adds an issue with the web.config files. Turns out the updaterfeed.xml was a redherring as this only got used in previous versions for --legacyUpdates (which isn’t a valid switch)

      T
      Community Manager
      Tariq Ahmad DarCommunity Manager
      Community Manager
      May 22, 2026

      ​@impoole691974 - Glad to hear that. 

      And thanks for sharing the additional information. 

      impoole691974
      impoole691974Author
      Participating Frequently
      May 21, 2026

      So turns out the updaterfeed.xml is a red herring and effectively doesn’t exist anymore. I have noticed now that the list is now updated and downloads without error, thanks. The real repo references ffc.xml or if you use a groupname then ‘groupNAMEffc.xml’

        impoole691974
        impoole691974Author
        Participating Frequently
        May 20, 2026

        Still having the same errors, I have now run AdobeUpdateServerSetupTool.exe with every concievable option but nothing changes the fact that it errors and doesn’t build the updaterfeed.xml.

        Any one else expericencing this?

        T
        Community Manager
        Tariq Ahmad DarCommunity ManagerCorrect answer
        Community Manager
        May 21, 2026

        Hi ​@impoole691974, 

         

        Thank you for your patience. 
        The engineering team have updated the list and technically AUSST shouldn’t be able to find this feed anymore. The the list has been updated and refereshed, let me know if you are still getting this error. 

         

        ~Tariq

        impoole691974
        impoole691974Author
        Participating Frequently
        May 14, 2026

        Attached is a more ‘readable’ response

        T
        Community Manager
        Tariq Ahmad DarCommunity Manager
        Community Manager
        May 14, 2026

        Hi ​@impoole691974,

         

        Thank you for submitting this investigation report. The level of documentation provided — particularly the parallel HTTP HEAD responses, DNS resolution chain, proxy configuration evidence, and cross-environment reproducibility — is exactly what is needed to move this forward. 
        I will be discussing this internally with the product team. 
        Earlier i didnt pay attention, now I was trying to compare this version number with the released versions we have available, and I can’t match this number here: https://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotesDC/index.html 

         

        These are the only versions that we released. I am also trying to confirm the version you have listed. And why are you using the old version?  

         

        ~Tariq
         

        impoole691974
        impoole691974Author
        Participating Frequently
        May 14, 2026

        Thanks for engaging with this so thoroughly.

        Quick clarification on the version question: 24.001.30365 is from the Acrobat Classic track, not the Continuous track. The release notes you linked (/index.html) lead to the Continuous track installer list — Classic track versions don't appear there because Classic has its own separate release notes.

        The relevant Classic release notes page is: https://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotesDC/acrobatclassic/acrobatclassic24.001mar2026qfe2.html

        This documents the March 2026 QFE2 release as version 24.001.30365. The Classic track deliberately keeps the major version at 24.001 because customers on perpetual Classic licenses (typically regulated industries) do not want auto-rollover to new major versions — they receive security and stability QFEs only.

        Additional confirmation that this is a current release, not an old one: the Last-Modified header on the working sibling file (also from build 2400130365) returned by Adobe's CDN is Tue, 14 Apr 2026 09:25:10 GMT — see the curl output in our previous email. So Adobe's own CDN confirms this is a 2026 file.

        To be clear on the question of "why are you using the old version": we are not selecting a version. AUSST synchronises whatever release the Adobe CDN manifest advertises as current at the time of sync. AcroAUSST itself fetches the manifest from Adobe and processes whatever files it lists. When we run AUSST against current Adobe endpoints, 24.001.30365 is in the manifest — that's how we know it's the version Adobe is currently advertising to AUSST customers.

        Please confirm with the Acrobat Classic team whether:

        1. The AcroRdrClassicx64Upd2400130365_MUI.msp Reader Classic Windows x64 Multi-Language file was intended to be part of the March 2026 QFE2 release; and
        2. Whether the file was uploaded to the CDN at the same time as its sibling files.

        If the answer to (1) is yes and (2) is no, then the file simply needs uploading. If (1) is no, then the manifest needs the reference removed. Either way, the asymmetric state where the manifest references a file that doesn't exist on the CDN is what's breaking AUSST manifest generation globally.

        T
        Community Manager
        Tariq Ahmad DarCommunity Manager
        Community Manager
        May 13, 2026

        Hi ​@impoole691974, 

         

        Sorry for the troubled experience. And thanks for the detailed write-up.

        Before we escalate this as a CDN-side issue, we want to make sure we have ruled out the most common causes at the network and environment levels — especially since a CDN-wide file availability issue would typically affect all AUSST deployments simultaneously, which we are not observing. 

        Please work through the triage steps below and share your findings. This will help us narrow down whether the issue is environmental or requires further escalation.


        STEP 1 — CHECK THE ACROUSST LOG DIRECTLY

        The main AUSST log can mask AcroAUSST failures. Review the dedicated sub-tool log for the actual error detail:

           Location (Windows): %TEMP%\AdobeAcrobatUpdateServerSetupTool.log

        Look for lines referencing:
           • HTTP 404 or "file not found."
           • The build string: 2400130365
           • Any proxy or SSL-related errors

        Please share the relevant section of this log in your reply.


        STEP 2 — VERIFY THE REQUEST IS ACTUALLY REACHING ADOBE'S CDN

        A 404 returned by Invoke-WebRequest does not necessarily mean the file is absent from Adobe's CDN. A proxy server, firewall, or SSL inspection appliance sitting between your AUSST server and the internet can intercept the HTTPS connection and return a synthetic 404 without the request ever reaching ardownload3.adobe.com.

        To verify end-to-end:

           # Check the actual response headers — look at the 'Server' field.
           # If it returns an internal proxy hostname instead of Adobe's CDN, the request is being intercepted.
           Invoke-WebRequest -Uri "https://ardownload3.adobe.com/pub/adobe/acrobat/win/AcrobatClassic/2400130365/AcroRdrClassicx64Upd2400130365_MUI.msp" - Method Head -Verbose | Select-Object StatusCode, Headers

           # Also test DNS resolution — confirm ardownload3.adobe.com resolves to an Adobe CDN IP, not an internal proxy.
           Resolve-DnsName ardownload3.adobe.com

        Could you share the StatusCode, the Server response header value, and the resolved IP address?


        STEP 3 — CONFIRM PORT 443 IS OPEN TO ADOBE'S CDN ENDPOINTS

        AUSST communicates with Adobe's update servers over HTTPS (port 443). Even if general internet access is available on your server, firewall ACLs or web proxy policies may selectively block or intercept traffic to specific CDN hostnames or IP ranges.

        Test connectivity directly:

           Test-NetConnection -ComputerName ardownload3.adobe.com -Port 443

        Expected result: TcpTestSucceeded = True

        Also, verify the following Adobe CDN hostnames used by AUSST are all reachable on port 443 from your AUSST server:
           • ardownload3.adobe.com
           • ardownload2.adobe.com
           • swupdl.adobe.com
           • swupmf.adobe.com
           • prod-rel-ffc-ccm.oobesaas.adobe.com

         

        For more information on the domain list and network ports, please visit this: https://helpx.adobe.com/enterprise/kb/network-endpoints.html.

         


        STEP 4 — CHECK PROXY CONFIGURATION

        If your environment routes outbound HTTPS traffic through a proxy:

           • Are you passing proxy credentials to AUSST?
             AdobeUpdateServerSetupTool.exe --root="..." --fresh --proxyServer=<host:port> --proxyUsername=<user> --proxyPassword=<pass>

           • Is SSL/TLS inspection (deep packet inspection) enabled on your proxy or firewall?
             This is one of the most common causes of synthetic 404 responses on HTTPS downloads — the proxy re-signs the certificate, and the CDN or the download tool rejects or misreads the response.

           • Does your proxy allowlist Adobe CDN domains explicitly, or does it use a blocklist approach?


        STEP 5 — CLARIFYING QUESTIONS

        To help us understand the full picture:

           1. Was AUSST working previously in this environment, or is this a first-time setup?
           2. If it was working before, what changed? (Network policy update, proxy change, AUSST version upgrade, Windows Server patch?)
           3. Are other Adobe CDN downloads (Creative Cloud app updates, non-Acrobat products) syncing successfully via AUSST?
           4. Can you successfully download any other file from ardownload3.adobe.com from the AUSST server using a browser or PowerShell?


        NEXT STEPS

        Once you share the outputs from the steps above, we can figure out whether this needs to be escalated to our infrastructure team or addressed through a configuration change on your end.

        If you are on an active Adobe Enterprise contract and need faster resolution, you can also open a support case directly:https://helpx.adobe.com/contact/enterprise-support.html. 

        Looking forward to your findings.

         

        ~Tariq

         

        Terms & ConditionsAccessibility statement
        Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices