When deploying an update package for Adobe Reader the package fails to install with error code 1638.
When an Adobe Reader update package is deployed the installation fails.
Adobe Reader comes in two versions. In this solution, we will refer to them as the consumer version and the enterprise version. The consumer version will refer to the .exe installer. The enterprise version will refer to the .msi installer. The differences are described below.
The .exe installed version, which is intended for consumers:
- is meant to be updated through the Adobe Update Service known as ARM. It is possible to update the consumer version through incremental updates (.msp packages) but errors might occur.
- does not allow for configuration prior to installation.
The .msi installed version, which is intended for enterprises:
- is meant to be updated through incremental updates (.msp packages) deployed through whichever tool the enterprise uses for deploying updates (WSUS/SCCM/etc.). It is possible to update the enterprise version through the ARM service, but some enterprises report errors installing it.
- The enterprise version allows for multiple configurations prior to deployment, and also supports the Adobe Customization Wizard tool.
In order to make our package as resilient, error-free, easy-to-use and configurable as possible, as well as complying with Adobe's best-practice, we have included the enterprise (.msi) installer.
The consumer version installer of Adobe Reader is not compatible with the enterprise version installer, and the two were unable to interact with each other without resulting in an error code of 1638.
We, therefore, implemented the clean install workaround, which allows the package to uninstall previous versions of Adobe Reader, and then install the enterprise version, which is what Adobe recommends:
http://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/basics.html#installation-best-practices
The drawback of this workaround is the loss of settings, but a clean install has always been completely dependent on the uninstaller of the product, so this was inevitable. Since the workaround ensured that the enterprise version would be installed instead, the workaround only had to be applied once, after which the bug would no longer appear. This means that the bug would be a one-time-inconvenience with our workaround, rather than continuously causing issues.
on
Nov 15, 2018
05:30 PM
- edited on
Sep 16, 2019
02:12 PM
by
RDanailov