Adobe Reader DC failing to install VIA TS

[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.

[will.locke]

Thread necro because this issue cropped back up again today.  Acrobat Reader has been working fine since 2022, but had this same problem again today.  I don't suppose PMPC had any luck with what you were trying or if you would reconsider my idea above of extracting the contents of the Adobe .exe first before packaging the application (which is what we have to do manually for the workaround when this happens).

[JoeG NHS]

Thread necro because this issue cropped back up again today.  Acrobat Reader has been working fine since 2022, but had this same problem again today.  I don't suppose PMPC had any luck with what you were trying or if you would reconsider my idea above of extracting the contents of the Adobe .exe first before packaging the application (which is what we have to do manually for the workaround when this happens).

I can confirm we are also seeing this issue, we are using the 32bit adobe reader within our OSD Task Sequence. When I manually run the installer within the task sequence, it does extract and install fine all within the Task Sequence environment. But fails with error 150201 when trying to do it via the PMPC scriptrunner.

This is on windows 11 23H2 (Nov 2024 Eng Int build)

Failing in OSD TS



Successful install from previous version of adobe last week

[Andrew Jimenez (Patch My PC)]

We've actually found a workaround on this and have been trying to dissect why this specific behavior is occurring over the last week. The workaround is to set the "Run installation and uninstall program as 32-bit processes on 64-bit clients." on the deployment type for Adobe.

What we are planning on doing, since this issue keeps reoccurring, is to add this option into the Publisher directly, and have the Publisher set this flag automatically for applications that run into this issue.

[JoeG NHS]

We've actually found a workaround on this and have been trying to dissect why this specific behavior is occurring over the last week. The workaround is to set the "Run installation and uninstall program as 32-bit processes on 64-bit clients." on the deployment type for Adobe.

What we are planning on doing, since this issue keeps reoccurring, is to add this option into the Publisher directly, and have the Publisher set this flag automatically for applications that run into this issue.

Thank you, yes this would be the ideal resolve as from reading other posts, that option if you set it manually for the Application in SCCM (vs in PMPC Publishing app which you cant do atm), will not persist on the next app version bump, and with Adobe, thats almost every week!

I think we all appriciate that Adobe software is very hard to predict what changes or things break each time a new version is released.

Your addition to the publisher would be very much appreciated, keep up the good work

[will.locke]

We've actually found a workaround on this and have been trying to dissect why this specific behavior is occurring over the last week. The workaround is to set the "Run installation and uninstall program as 32-bit processes on 64-bit clients." on the deployment type for Adobe.

What we are planning on doing, since this issue keeps reoccurring, is to add this option into the Publisher directly, and have the Publisher set this flag automatically for applications that run into this issue.

Setting the indicated setting did fix the issue for us as well.  So a little different than the original thread.  But thank you for the response and the updated for how PMPC will make a more permanent fix.  Appreciate the support.