Messages

We are having this issue as well.  However, I restarted the PMPC service yesterday then kicked off a sync and saw a number of applications successfully published.  But this morning, the e-mail report showed that Chrome published an update but didn't include any applications updated.  Checking the PatchMyPC.log file shows the same errors we were having yesterday (including in OP post).

So had the described problem, restarted PMPC service, problem resolved... for a while.  Then problem resurfaced today.

I'm sorry, but it is obvious you didn't read the post completely.  First, I stated an example application in my original post.  Second, I didn't say that it happens every time.  I said that it happens sometimes.  So with the Chrome example, as I explained in my original post, it was replacing the application with each version as expected, but the version after 115.0.5790.110 instead of replacing that version of the application it created a new one.  The new one then received updates (again, as per the setting in PMPC).  But our deployments and task sequence references still point at the old version because it created a new application instead of replacing the existing one.

That is the whole point of the post and if you read my post above it should be apparent... I already have that setting set and most of the time it _does_ update the existing application.  However, I have specific examples where, even with the setting set, it creates a new application instead of updating the existing one.

This isn't the first time we've seen this and it isn't a one-time occurrence.  It is something I've noticed happens from time-to-time with some applications.  Another example was that we had Adobe Acrobat Reader selected as like one of the first applications we selected.  It started off at version 20.x and upgraded the existing application.  But at some point, it created a new one (I think somewhere in the middle of 21.x) and started updating that one.  Again later, it created another new one (somewhere in the 22.x versions) and started updating that one.  Each time this happens we have to update our deployments to the new version and update all task sequences that reference the old application.

As subject says, sometimes a selected application (application creation, not update), doesn't update the previous application and instead creates a new application.  The most recent example is Google Chrome.  It has been updating the same application in SCCM from somewhere around version 70.x, which is now 115.0.5790.110 which is referenced by task sequences and has required deployments.  But now there is a 117.0.5938.92 application also.  So for some reason PMPC didn't update the existing application (115.x) to 117.x (more likely to 116.x or whatever version came after 115.0.5790.110).  Since it created a new application, we have to go through all of our task sequences and update references and create deployments using the new application and remove deployments from the old one.

Is there any known reason why this occurs and how we can prevent it or know when it happens so we can take action.  Right now, I have to tell my team to just monitor the folder periodically to see if PMPC creates a new application instead of updating the existing one.

I posed my question over at Reddit while I was waiting to get the e-mail to reset my password here:

https://www.reddit.com/r/PatchMyPC/comments/15xnhlo/intune_app_custom_requirements_or_detection_script/

Essentially, we have numerous security agents which can't be updated except by the self-updating mechanism.  In SCCM we target these at a collection using hardware inventory installed software to target devices "missing" the security agent.  But that isn't available in Intune.  Microsoft's recommended solution is to use a custom script for Requirements to filter out devices because that moves the processing load from the server to the client.  However, there is no option in PMPC to modify Requirements of an Intune App, so I'd have to manually edit the app PMPC creates each time.  A more detailed description is in the Reddit link above.

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.

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.

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

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.

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.

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.

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.

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.