This project has moved and is read-only. For the latest updates, please go here.

.msp files now longer work for Adobe Reader XI

Topics: Publishing Issue
Oct 21, 2015 at 3:26 PM
Dear Community,

we have a standard image for our clients which includes Adobe Reader 11.0.10 MUI.
On WPP we've created an update package via .msp file for version 11.0.11 (MUI) which runs perfectly.
Meanwhile Adobe released update versions .12 and .13, but neither .msp file will show up in Windows update.
We've created the packages in the same way as for version 11.0.11, the WSUS report shows installs for approval and not applicable for status.
Any thoughts or ideas?

Thanks in advance
Oct 21, 2015 at 11:29 PM
I have noticed that .12 and .13 do not report as needed if you use the Adobe SCUP catalog or you create a standard update package. However, the msp file will install OK manually. I ended up creating custom scripted packages like this:

@echo off
call msiexec.exe /update "%~dp0AdbeRdrUpd11013.msp" /quiet /norestart
exit /B %EXIT_CODE%

I tried to troubleshoot the metadata in the msp file but it is beyond my capability.

-Jim B.
Oct 26, 2015 at 4:04 PM
Version 11.0.12 works for me but not 11.0.13. WsusPP displays the status as "Not Applicable" - and the client does not show, download or install the update.

Is it possible to find out with WsusPP, why the update is not applicable?

Nov 2, 2015 at 2:18 PM
I have found a solution for the update 11.0.13 that requires no extra script:
  1. create an normal update with the msp file
  2. on the page for installed updates select MSI Patch Installed For Product and click Add Rule
  3. Patch Code: ac76ba86-7ad7-0000-2550-7a8c40011013
  4. Product Code: AC76BA86-7AD7-1053-7B44-AB0000000001
  5. repeat step 2-4 on the page for installable updates, but check Reverse Rule
Nov 6, 2015 at 5:18 AM
Well my solution doesn't work in all cases. I have a network with a SBS 2008, where the clients download and install the update and everything is alright.

On another network with a SBS 2011 the clients also download and install the update without an error. But then the clients download the update again just to see they don't need it. And then again and again and ... I had to expire the update to stop the loop.

I checked the rules on both servers and they are identical. Are there any explanations for this behaviour?
Nov 18, 2015 at 4:16 PM
Got the same problem with 11.0.13 and decided to switch over to latest Adobe Reader 2015 (Classic Track!) since I was not able to find out the problem...
Nov 23, 2015 at 9:01 PM
Thanks Boesi - this initially threw the 0x8024000F error when we first put it in, that and selecting 'All Computers' for the approval, not a good idea, still catching up after that fiasco. I'll try to post any similar results I see. Beginning an incremental push = small groups of a dozen here & there. Few first test systems worked fine.
Nov 24, 2015 at 8:36 AM
Dear All,

we used the manuall install via "msiexec" for now, which runs without any errors.

msiexec.exe /update AdbeRdrUpd11013_MUI.msp /quiet /norestart
(MSIPatchInstalledForProduct | Patch-Code: ac76ba86-7ad7-ffff-2550-7a8c40011013 | Product-Code: ac76ba86-7ad7-ffff-7b44-ab0000000001)

Meanwhile we've noticed the release of a new WPP version (1.3.1511.15):
  • Fix a bug that prevent client computers to read MSI/MSP MetaData
  • Fix a bug that prevent WPP to display "File Exist Prepend Reg SZ"
  • Add Windows 10 in the quick selection OS version list
  • Display Update revision in the UpdateDetailViewer
Does someone know whether the first bugfix is releated to our threat?

Best regards