Messages

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.

I have adjusted detection for Adobe Acrobat Reader MUI (x64) to detect whether it was MUI based on the Product code instead of the IsMUI registry value. Anyone having this issue can republish the Intune Update/ConfigMgr App/Intune App, and detection will be adjusted.

Thanks for pointing this issue out!

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

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.

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.

It looks like for some reason it is not setting the IsMUI key in some cases. I am working on updating detection to account for this.

Hello,

This is the first I have seen this issue. I wonder if the certificate for the drivers was not installed somehow which leads to this failure.

Hello Mark,

I believe it will keep the customizations that are in place when updating.

Hi George,.

Thank you for these suggestions, I honestly think the solution here will be to replace Visual C++ 2015-2019 with Visual C++ 2015-2022. I am going to do some research on this and see if that will be an acceptable solution.

Hello,

We have not tried this ourselves, have you tried specifying both the Language to install as well as the transform?
https://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/language.html#pre-deployment-configuration

Hello,

This app is definitely troublesome with all of the apps that must be closed to update it. We are actually adding a few other apps that we have found block it's installation as well. My only suggestion here is to use the "Manage Conflicting Processes" notifications to let your users know that they need to close the app in order for it to update.

Another workaround if you are on ConfigMgr is, you can deploy the app to update existing installs, and set it to run if no users are logged on.

Copying from another thread:

The version of Firefox ESR in our catalog at this time is still up-to-date, it should contain the same security fixes that were added in version 102. The next ESR release will be 102,

The current version of Firefox ESR in our catalog is 91.13 released on 8/23/2022
https://www.mozilla.org/en-US/firefox/91.13.0/releasenotes/
Security Vulnerabilities fixed in Firefox ESR 91.13 — Mozilla

The current 102 release of ESR is 102.2 also released on 8/23/2022
Security Vulnerabilities fixed in Firefox ESR 102.2 — Mozilla

Patch My PC will be moving to Firefox ESR 102 upon the release of ESR 102.3 on 9/20/2022

I compared the list and 102 does indeed have 2 extra fixes over 91.13, however the only High criticality vulnerability that is fixed in 102 that is not fixed in 91.13  (CVE-2022-38477) is fixing a bug that only existed in the 102 and greater branch. The other, low impact CVE does not mention the versions affected.

Firefox keeps 2 versions of ESR alive for 3 point releases when they have a major ESR release, the older version is more stable, and this gives Mozilla time to stabilize the newer ESR release. Mozilla still provides the same vulnerability patches to both versions while they are both supported. Patch My PC has decided to stick with the more stable ESR, as we assume customers that choose the ESR release are doing so for the stability benefits.

We do not intend to add the newer ESR release at this time as it would significantly increase the number of Firefox updates in our catalog, it would also introduce complicated applicability considerations.

Hello,

Unfortunately, Microsoft has expired the ConfigMgr Client Toolkit. It is currently being decommissioned in our catalog for full removal. https://patchmypc.com/how-products-are-handled-at-end-of-life-eol-or-become-incompatible

Hello,

Unfortunately, there isn't an "easy" way to check these rules. Most of our rules are much less complicated than this (in fact, we do not utilize WMI based rules at all because they are slow). Sorry we can't be of more help!

Hi Matthias,

You should be able to right click the app in the Patch My PC interface, and choose to "Republish" the app during the next sync schedule, then run a sync.