Adobe Acrobat Reader DC 22.003.20258 is failing to install via the TS getting a exit code 150201 in the appenforce.log. I have already tried the allow user interaction and still doing the same thing. any thoughts or insights would be greatly appreciated or if I need to gather further logs please let me know.
Thanks
We're having the exact same problem.
We are also seeing failures during TS installs.
The TS exit code is listed as 16389.
Same problem here. Our imaging process is blocked by this issue since Acrobat Reader is in the imaging task sequence and it fails every time.
We're having the same issue. Appenforce.log shows same exact error, TS fails and imaging is at a standstill until this is fixed. Pulled from TS for now, but nothing I've tried seems to help.
Quote from: will.locke on October 18, 2022, 02:08:02 PMSame problem here. Our imaging process is blocked by this issue since Acrobat Reader is in the imaging task sequence and it fails every time.
Quote from: natel on October 19, 2022, 08:36:00 AMWe're having the same issue. Appenforce.log shows same exact error, TS fails and imaging is at a standstill until this is fixed. Pulled from TS for now, but nothing I've tried seems to help.
To allow for imaging to proceed, I'd recommend enabling on the Install Application step "If an application installation fails, continue installing other applications in the list". I do not have Continue on error enabled.
An error is still logged to notify what machines failed on it if you're using a TS monitor tool.
The install works fine when going back and doing so from Software Center.
The following thread shed the most light on the situation for me:
https://www.reddit.com/r/SCCM/comments/qqzrcm/adobe_reader_x64_installation_error_exit_code/
The first workaround in the thread suggests setting the application to allow user interaction makes it so the application cannot be used in an OSD task sequence. The implication and other suggestion above was just to let the application not install during the task sequence and install it post imaging via required deployment. This is not a solution in my opinion. The whole point of OSD imaging is that a system should come out complete post imaging. If we're just going to install stuff as required deployments afterward, why even include it in imaging?
However, the second solution was more interesting. It suggests that Adobe fouled up something with their extraction process... something I'd seen in another thread here in the PMP forums I think. So the file downloaded from Adobe (and packaged by PMP) is just a compressed wrapper. It is the process of extracting those files that is failing when the process is run as SYSTEM (succeeds when run under user context). So the workaround I implemented is this:
- Copy package folder created by PMP for Adobe Acrobat Reader to another folder on our source drive
- In the copied folder, use 7zip or WinRAR to extract the contents of the Adobe file
- Modify the PMP .xml definition file to tweak the cmdline to run setup.exe instead of the Adobe wrapper installer
- Clone the PMP created application in the SCCM console
- In the cloned copy, change the source to point to the copied source path above
I put this cloned/modified application into the imaging sequence in place of the PMP automatically created one. We'll use this version until a permanent fix is implemented in the PMP created application.
If you're having trouble installing Acrobat reader, try the following:
Enable JavaScript. ...
Check for anti-virus updates.
Try a different browser.
Try a direct download link.
Ensure a stable Internet connection.
Update the video card driver (Windows only)
Troubleshoot for specific error messages.
Regards,
Rachel Gomez
We have the same issue with Adobe Installer as described by @will.locke.
Our workaround was to create a new package based on PSADT with the extracted source and commands from PMP.
We were getting this error (exitcode 150201 when running in an OSD TS) with Adobe Acrobat Reader DC 22.003.20258. We tried syncing again last week and the error persisted during the imaging process. We tried re-downloading it through the PMPC publishing tool again today, and there's now a new version 22.003.20263. However, this application is doing the same thing - fails during the task sequence with exitcode 150201.
(https://i.imgur.com/Fsod9yR.png)
Quote from: KylieDanger on October 25, 2022, 02:48:10 PMWe were getting this error (exitcode 150201 when running in an OSD TS) with Adobe Acrobat Reader DC 22.003.20258. We tried syncing again last week and the error persisted during the imaging process. We tried re-downloading it through the PMPC publishing tool again today, and there's now a new version 22.003.20263. However, this application is doing the same thing - fails during the task sequence with exitcode 150201.
See the link (Reddit) in my post above. That post describes the exact same exit code you mentioned (150201). I thought this was a recent issue since we only started having the problem week before last, but that Reddit thread is over a year old which doesn't give me a lot of hope that Adobe will fix their installer.
The process we've had to implement to work around this:
- Clone PMP created application and source folder
- In cloned source folder, extract contents of compressed installer via 7zip or WinRAR
- Change source of cloned application to point to above folder
- Substitute the above cloned application in OSD TS
- Created collection of systems with Acrobat Reader installed (any version; based on HW inventory)
- Targeted PMP version of Acrobat Reader as required to above collection
- On new version released via PMP: test new application in TS
- If new version works (no 150201 error), then we're good
- If new still fails, either leave old extracted version in TS or recreate new extracted version using same process as above
- If leave old extracted version in, systems get updated to latest build via required deployment after imaging is complete. Not as ideal as installing during OSD, but InfoSec/Vulnerability Mitigation teams are satisfied.
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.
Quote from: KLUSA on October 27, 2022, 11:47:24 AMWe'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.
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.
Quote from: KLUSA on October 27, 2022, 01:55:32 PMWe'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!
Quote from: will.locke on October 27, 2022, 12:10:47 PMQuote from: KLUSA on October 27, 2022, 11:47:24 AMWe'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.
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)
(https://i.imgur.com/iV5kF0s.png)
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
(https://i.imgur.com/zBi8kXI.png)
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)
(https://i.imgur.com/LhbBi2w.png)
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.
Thanks for the response, Andrew. That provides a lot of context and deeper information than I've seen before. That's very useful.
Ben Whitmore takes all the credit here! I just copied and pasted his response :)
Quote from: KylieDanger on October 27, 2022, 03:36:56 PMQuote from: KLUSA on October 27, 2022, 01:55:32 PMWe'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.
Quote from: will.locke on October 28, 2022, 02:11:08 PMThanks 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.
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.
Quote from: KLUSA on October 31, 2022, 09:18:28 AMQuote from: KylieDanger on October 27, 2022, 03:36:56 PMQuote from: KLUSA on October 27, 2022, 01:55:32 PMWe'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.
Quote from: KylieDanger on October 31, 2022, 10:05:06 AMQuote from: KLUSA on October 31, 2022, 09:18:28 AMQuote from: KylieDanger on October 27, 2022, 03:36:56 PMQuote from: KLUSA on October 27, 2022, 01:55:32 PMWe'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.
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/ (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
MsiExec.exe /i "%~dp0AcroRead.msi" PATCH="%~dp0AcroRdrDCUpd2200320263.msp" DISABLEDESKTOPSHORTCUT=1 /qn
abcpy.ini
[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.
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.
Quote from: Andrew Jimenez (Patch My PC) on October 31, 2022, 04:23:40 PMI 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.
Quote from: will.locke on October 31, 2022, 04:27:19 PMThe 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!
Quote from: Andrew Jimenez (Patch My PC) on October 31, 2022, 04:23:40 PMI 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.
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).
Quote from: will.locke on December 13, 2024, 12:36:42 PMThread 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
(https://i.imgur.com/loWD1Ja.png)
Successful install from previous version of adobe last week
(https://i.imgur.com/DaS1e3d.png)
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.
Quote from: Andrew Jimenez (Patch My PC) on December 16, 2024, 10:49:20 AMWe'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 :)
Quote from: Andrew Jimenez (Patch My PC) on December 16, 2024, 10:49:20 AMWe'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.