Adobe Reader DC failing to install VIA TS

[Andrew Jimenez (Patch My PC)]

We're also experiencing this issue.  Adobe Reader will install successfully through configuration manager, but will fail as part of a new image task sequence. 

The task sequence failed to install application Adobe Acrobat Reader DC 22.001.20117 for action (Install Application) in the group () with exit code 16389. The operating system reported error 2147500037: Unspecified error.

We tested with the 64-bit version and same issue.

Was hoping someone from PatchMyPC would have chimed in by now as I've seen recent responses to other threads.  The Reddit article posted earlier doesn't quite match what we're seeing. 

You're right; at first we were receiving the same error code as you.  Then it changed to the error code in the Reddit post, and most recent build changed back to the error code you listed.  In both exit codes, the pre-extracted package I described successfully work around the issue.

I'm wondering if PMP can work that into their process.  Probably a pie-in-the-sky scenario, but if PMP could download the file from Adobe, extract it, then build their application based on the extracted bits that would solve this problem.

As much as we'd love to do the extraction solution (and trust me we've thought about it). We do not have a way to accomplish this at the moment. We've gone into a lot of troubleshooting for this particular error and I will post our current response shortly.

[Andrew Jimenez (Patch My PC)]

The Adobe 150201 issue has been around for a while. We have it reported on our known issues page at https://patchmypc.com/known-issues-and-considerations-when-using-patch-my-pc

Typically, we saw that required deployments, including installs from a task sequence, for Adobe Acrobat Reader DC Continuous (x64) failed with exit code 150201. Clicking "retry" would intermittently succeed and "available" deployments often didn't exhibit this behaviour.

We did originally find a workaround. ConfigMgr customers would set the user experience option on the deployment type to "Allow users to view and interact with the program installation". However, this workaround would not always work to fix the application when installed during a Task Sequence and we are seeing more reports of this error lately from our customers. Additionally, we were unable to find a similar workaround if the error was encountered when deploying the app, as required, from Intune.

We are testing in our lab, again, to try and find the "common denominator" on devices where the 64bit installer results in the above exit code. This is what we have observed so far:-

The Adobe installer, when launched, will extract 2 bin files to C:\ProgramData\Adobe\Temp\xxxx (where xxxx is a random folder name)


The installer would then extract the installer.bin file to C:\Program Files\Common Files\Adobe\Acrobat\Setup\{GUID}

But the installation failed at this point, notice the file sizes below


The installer would extract content from installer.bin and create the files used for installation, however, the write stream was never initiated which resulted in the files having no content.

Below shows a process trace. The upper image shows a failed install, and no write file stream. The lower image shows a successful install and a file write stream. (We used the 32bit installer to illustrate a working installation for comparison)


We are finding this issue as frustrating as our customers and are exploring ways to reach out to Adobe for guidance.
We want to make your patching experience as painless as possible which is why we are committed to spending time and resources on trying to help with this Adobe issue.

We don't have a magic formula, yet, but will come back with more information if we find anything new in our testing.

[will.locke]

Thanks for the response, Andrew.  That provides a lot of context and deeper information than I've seen before.  That's very useful.

[Andrew Jimenez (Patch My PC)]

Ben Whitmore takes all the credit here! I just copied and pasted his response

[KLUSA]

We're probably just going to revert to an older version of Adobe Reader and continue deploying updates to get it up to the latest version. The manual method is too cumbersome to keep up with.

This is what we're doing right now as well. Thankfully we have set the retention settings to keep the old versions!

Which version did you go with?  We're still having trouble with it for some reason, but probably just need to go further back.

[KLUSA]

Thanks for the response, Andrew.  That provides a lot of context and deeper information than I've seen before.  That's very useful.

Yes, nice to see these details. Much appreciated.  Hopefully Adobe can be helpful in working this out.

[mpotase]

Thankfully I had a recent version of the adobe reader dc client I had manually imported into sccm with a transform file then I just run setup.exe.  I generated the transform file using the Adobe customization wizard utility and have the adobe client set to auto update (us do need to extract the Contents from Adobe's installer and point the customization wizard at the msi file). yes this installs and older client on the build process but adobe reader phones home an auto updates within 30 min of imaging the device.

then I just use ADR rules and have PMPC update any stragglers for now along with our monthly updates if needed.

[KylieDanger]

We're probably just going to revert to an older version of Adobe Reader and continue deploying updates to get it up to the latest version. The manual method is too cumbersome to keep up with.

This is what we're doing right now as well. Thankfully we have set the retention settings to keep the old versions!

Which version did you go with?  We're still having trouble with it for some reason, but probably just need to go further back.

The last working version we got from PMPC was "Adobe Acrobat Reader DC 22.002.20191" - we have it deployed to collection(s) and in task sequences, where it seems to be working fine.

22.003.20258 and 22.003.20263 are both not working in task sequences - haven't dared to deploy them to collections yet.

[KLUSA]

We're probably just going to revert to an older version of Adobe Reader and continue deploying updates to get it up to the latest version. The manual method is too cumbersome to keep up with.

This is what we're doing right now as well. Thankfully we have set the retention settings to keep the old versions!

Which version did you go with?  We're still having trouble with it for some reason, but probably just need to go further back.

The last working version we got from PMPC was "Adobe Acrobat Reader DC 22.002.20191" - we have it deployed to collection(s) and in task sequences, where it seems to be working fine.

22.003.20258 and 22.003.20263 are both not working in task sequences - haven't dared to deploy them to collections yet.

Yep, that one worked!  We're just going to use this as a solution for now.

[MrRobot13]

I referenced this blog post today and was able to get a working application in a TS.
https://silentinstallhq.com/adobe-reader-dc-silent-install-how-to-guide/

Following some instructions from the Adobe Reader DC Silent Install (MSI) area.
This worked with Adobe Acrobat Reader DC 22.003.20263.

I did this by copying the application PMP had made and the source content.
I left the detection script in place which worked fine.

Install.cmd

Code Select Expand

MsiExec.exe /i "%~dp0AcroRead.msi" PATCH="%~dp0AcroRdrDCUpd2200320263.msp" DISABLEDESKTOPSHORTCUT=1 /qn
abcpy.ini

Code Select Expand

[OEM Install]
INSTALLDIR=
ALLUSERS=1
EULA_ACCEPT=YES
DISABLE_ARM_SERVICE_INSTALL=1
UPDATE_MODE=0
Hope this helps!

EDIT: Use will.locke's suggested route, quicker and less to modify.

[Andrew Jimenez (Patch My PC)]

I hesitate to install via the MSI directly, as I believe that initial installs using the MSI usually end up running into the dreaded 1612 issue down the line. I believe the setup.exe (within the original install EXE), would be better suited to run instead of the MSI, however, I do not know if that setup.exe has the same issue during a task sequence than the original install exe.

[will.locke]

I hesitate to install via the MSI directly, as I believe that initial installs using the MSI usually end up running into the dreaded 1612 issue down the line. I believe the setup.exe (within the original install EXE), would be better suited to run instead of the MSI, however, I do not know if that setup.exe has the same issue during a task sequence than the original install exe.

The setup.exe inside the original file is fine.  Please see my post earlier in this thread where I posted that was our solution.  I copied the PMP source folder to somewhere else on our share, extracted the files to that folder and modified the PMP .xml to run setup.exe.  Then cloned the application in SCCM and pointed the clone at the folder containing the extracted files.  This works in the OSD task sequence.

[MrRobot13]

The setup.exe inside the original file is fine.  Please see my post earlier in this thread where I posted that was our solution.  I copied the PMP source folder to somewhere else on our share, extracted the files to that folder and modified the PMP .xml to run setup.exe.  Then cloned the application in SCCM and pointed the clone at the folder containing the extracted files.  This works in the OSD task sequence.

I gave this a whirl this morning and I do prefer this over mine from yesterday.
It was very quick to put together and less adjustments. Much appreciated!

[will.locke]

I hesitate to install via the MSI directly, as I believe that initial installs using the MSI usually end up running into the dreaded 1612 issue down the line. I believe the setup.exe (within the original install EXE), would be better suited to run instead of the MSI, however, I do not know if that setup.exe has the same issue during a task sequence than the original install exe.

On a side note not directly related to this thread issue... you mentioned the 1612 issue.  We have implemented a work-around that seems to be working.  The first piece to the puzzle is that the installer looks for previous installer source in the registry key HKCR:\Installer\Products for Acrobat Reader.  If it cannot locate the previous msi in a source folder listed in that location, then you get the 1612 error.  Often the entry in that reg key will be a ccmcache location which no longer exists.

The other piece of the puzzle is that Adobe stores their installer locally at "C:\Program Files (x86)\Common Files\Adobe\Acrobat\Setup\{AC76BA86-7AD7-1033-7B44-AC0F074E4100}\RDC" (for Acrobat Reader).  This is working for 22.x and I don't know how often that product code changes (if at all) so this work around may require an update if that product code ever changes.

So I wrote a detection and remediation script and deployed via SCCM Configuration Baseline.  The detection script searches the above registry key for an installed product of Acrobat Reader.  If found, the script retrieves the first path in the source path list (I could loop through them all but chose to only check the first one).  If AcroRead.msi exists in that path then Compliant = True (because you won't get 1612), if not then Compliant = False (as would result in 1612).  Remediation script overwrites the found path with the one I listed above (after doublechecking that it is valid).

After implementing this Configuration Baseline, our number of 1612 errors on the Acrobat Reader deployment dropped significantly.