This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Problems with Acrobat 10.1.4 msp

Has anyone had any luck deploying this (not for Reader, but Acrobatthe Std/Pro patch) using Patch Manager?

The patch alone can be applied to any 10.x version, however Patch Manager is reporting that it's not applicable to all clients except those that are at 10.0.0.

Any suggestions?

Thanks.

  • Ive tried it, and it does not work. In addition when applied to adobe installations modified with the ‘adobe customization wizard’, the msp’s do not even recognizing the custom installations. Its really lame, and adobe should fix it. maybe 11.x will work better.

    -mark

    Mark Reid | IT Director

    Direct: 916.851.3592 | capital-engineering.com <www.capital-engineering.com/>

  • If only there were a way for PM to run a script (or a cmd file that calls a script) that works with these .msp files then at least that would be one way to work around it.  You haven't by chance had any luck doing that have you?

    (Anything other than an actual .exe file would be so beneficial.)

  • That isn’t how msp files work. Msp files have no config scripts because those are built in and unchangeable. Basically the msp code looks at the system msi information to determine what can be updated. Its entirely up to the msi and msp programmer to make sure it all works in all scenarios. Unfortunately it appears adobe got it wrong. Pretty lame oversight not to test those msp’s with the their own customization wizard if you ask me.

    Have you tried running the msp locally? If that works you might be able to use some fancy login scripting. Other than that, you are out of luck using it with WSUS.

    -mark

    Mark Reid | IT Director

    Direct: 916.851.3592 | capital-engineering.com <www.capital-engineering.com/>

  • Sorry for not being clear - it was more of a generic question.  Since PM can only deploy using .msi, .exe, and .msp files - I was thinking it would be nice if PM could install something else (such as a .cmd file that performs the .msp installation), but still being able to use the PM detection rules for installation, etc.  It's how we install other 3rd party apps (like Firefox) with customizations using the PackageBoot.xml.  Unfortunately, because the .msp files are their own animal - even if you enabled the PackageBoot sections - it's ignored by PM.

    Running the .msp locally works fine - but that defeats the whole purpose when updating a large number of clients.

    So yes, bad for Acrobat for releasing something that clearly did not pass QA and wishing that PM could do a bit more.

  • I have never got the Acrobat 10.1.4 MSP file to successfully update a system with 10.1.3.  However, I worked around the issue by wrapping the MSP file and a custom cmd batch file using WinRAR Self-Extractor package.

    The cmd batch file called "Update.cmd" executes the MSP file and captures the errorlevel so that the batch file terminates with the proper errorlevel of the MSP execution.  The errorlevel is captured by the WinRAR self-extractor as long as the "Wait and return exit code" SFX option is selected.  I also do some additional cleanup after the patch applies to remove the "Adobe ARM", "Adobe Acrobat Speed Launcher" and the "Acrobat Assistant".  These are unnecessary and just take up memory.  You can obviously customize the commands as you wish, or add additional ones.

    --- START OF "Update.cmd" FILE ---

    @Echo Off

    Cmd /C MSIEXEC /p "%~dp0AcrobatUpd1014.msp" /qn /norestart ALLUSERS=1

    SET ERRLVL=%ERRORLEVEL%

    Cmd /C REG DELETE HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run /f /v "Adobe ARM"

    Cmd /C REG DELETE HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run /f /v "Adobe Acrobat Speed Launcher"

    Cmd /C REG DELETE HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run /f /v "Acrobat Assistant 8.0"

    Cmd /C REG DELETE HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /f /v "Adobe ARM"

    Cmd /C REG DELETE HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /f /v "Adobe Acrobat Speed Launcher"

    Cmd /C REG DELETE HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /f /v "Acrobat Assistant 8.0"

    EXIT /B %ERRLVL%

    --- END OF "Update.cmd" FILE ---

    So the steps are:

    1) Create a file called "Update.cmd" with the commands mentioned above.

    2) Use WinRAR to create an SFX package that contains the files:

    - Update.cmd

    - AcrobatUpd1014.msp

    3) WinRAR options to use (i'm just listing the variation from the defaults):

    - Archive format, select: RAR

    - Enable "Create SFX Archive"

    - Click Advanced tab -> SFX Options...

    - In SFX Options:

         - In "Module" tab:

              - Make sure "Default.SFX" is selected

         - In "Update" tab:

              - Overwite mode: Overwrite all files

         - In ""Setup" tab:

              - In "Run after extraction field" put:  Update.cmd

              - Enable "Wait and return exit code"

         - In "Modes" tab:

              - Enable "Unpack to temporary folder"
              - For Silent Mode, enable "Hide all"

         - In "Advanced" tab:

              - Enable "Request Administrative access"

    4) Proceed to create the WinRAR self-extracting exe file

    5) Create a new package in Patch Manager and choose EXE package, import your new WinRAR self-extracting Adobe Acrobat 10.1.4 file, and choose "Always requires reboot"

    6) VERY IMPORTANT:  Patch Manager 1.80 (possibly earlier) has a bug where you cannot change the Success Code.  It always gets reset to "0" which is a big problem because WinRAR adds a value of 1000 to all errorlevels reported from the executed file inside the package.  For example, if errorlevel 3010 was reported because the patch applied and was successful pending reboot, the WinRAR package would report "4010".  A value of "0" is reported as 1000.

    To work around this bug, you must make the patch "Always require reboot".  You must then specify the "Success Codes pending reboot" to be:  1000, 4010.  DON'T FORGET THIS STEP OR THE PATCH WILL INSTALL, BUT WILL REPORT FAILED.

    7) I specified to use PackageBoot to terminate the processes before execution:  Acrobat.exe, acrotray.exe, acrodist.exe, FormDesigner.exe

    8) For pre-requisites, I only made x86 and x64 processors

    9) For Applicability, I specifed an MSI rule to check for the Acrobat product code (you will need to find this out by checking the registry).  Mine is "AC76BA86-1033-F400-7760-000000000005", but yours may differ depending on your version and language.  Min version:  10.0.0, Max version:  10.1.3

    10) Patch installed rule:  MSI rule, put proper Acrobat product code, Min version: 10.1.4, Max version: 10.1.4

    This will help trying to deploy the Acrobat 10.1.4 MSP file and other MSP files.  You can also use this same method for many other things such as simply executing cmd batch files, deploying registry changes, etc.  Notice the "EXIT /B" command at the end of the "Update.cmd" file.  By using "EXIT /B <errorlevel>", the batch file will terminate with whatever errorlevel you specify.  Also, notice the "%~dp0" before the Acrobat patch file in the "Update.cmd" file.  Using this variable will automatically translate to the full path that the cmd file is running from.  It is necessary to specify this to get this method to work.

  • That was just the kind of answer I was hoping to get.

    Thank you for your trial and error efforts.

    You sir, just might have made Xmas come early.

    Update:  So wanted to report back that your post was very helpful.

    What I did instead though, was to create a dummy file and use the built in iexpress.exe tool to create the self-extracting file.

    (So the .exe does nothing more than extract a file when run)

    Then once the package was an ".exe" -type deployment, I could simply add the custom install scripts and .msp file as part of the PackageBoot package.

    Your applicability rules and installed rules worked great.

    Now the real trick will be to use that with the other custom packages that we have.