Jump to content


Recommended Posts

I've spent the better part of a day trying to add Adobe reader to our Software Center for users to install.

I extracted the MSI files from the executable. I used their Customization app to create the .MST.

I've tried setting the install up multiple different ways with no luck. The majority of the time it results in the install in Software Center spinning until it times out. Or it will begin the install correctly, except it's not paying attention to the settings I made in the MST file, and when it finishes, Software Center gives an error that when Googled equates to Software Center being unable to detect that it was installed.

Someone out there has to have this working and can throw me a bone.

Share this post


Link to post
Share on other sites


I have it working in mine.  I can't do anything about it for you over the weekend, but when I get back in Monday I'll take a look at my notes and my deployment and update here.

Share this post


Link to post
Share on other sites

Our environment deploys Acrobat Pro to all users, though I would assume the steps would be similar for Reader. You may need to tweak some of the below to fit your environment.

I personally use the PowerShell App Deployment Toolkit to control the installer and give users to the opportunity to shutdown their Acrobat before continuing. Since Acrobat allows them to edit documents (and they do quite a bit), I can't just go around shutting their Acrobats down. I will also show potential msiexec examples instead of just the PS App Deploy version. If you are using the latest builds of ConfigMgr Current Branch, you could also use the built-in application detection/close function, though it is still not as feature rich as the App Deploy Toolkit.

The following are some snippets of my PS App Deploy script. At the moment, I will assume you have some familiarity with the framework, but feel free to ask questions.

Remember, if you are installing Acrobat/Reader fresh, you wouldn't need to worry about shutting down apps beforehand (and the installers may handle this automatically, but I like handling it myself). If you don't need to worry about user surprises or loss of work, you could just brute force shut down the relevant applications.For Full Installs (PS App Deploy Toolkit):

Show-InstallationWelcome -CloseApps 'acrobat,acrodist,AcroRd32,AcroCEF' -CloseAppsCountdown 12600 -BlockExecution -MinimizeWindows $false

## Show Progress Message (with the default message)
Show-InstallationProgress -WindowLocation 'BottomRight' -TopMost $false

(SNIP Installation defaults from framework)
        
## Install base MSI with Transform
Execute-MSI -Action Install -Path "$dirFiles\AcroPro.msi" -Transform "$dirFiles\AcroPro-SerialLicense.mst" -Parameters "REBOOT=ReallySupress /qn"
        
## Install patch
Execute-MSI -Action Patch -Path "$dirFiles\AcrobatDCUpd1701220093.msp" -Parameters "REBOOT=ReallySuppress /qn"

       
For Updates Only (PS App Deploy Toolkit):
        Just don't have the 'install base MSI with Transform
               

Straight Up msiexec installs:
   (I personally would place this in a batch script or PowerShell script. If using PS, I would use Start-Process with an install variable for the 'ArgumentList') Remember, to use %~dp0, you must be using a batch script.

msiexec /i AcroPro.msi /qn PATCH="%~dp0AcrobatDCUpd1701220093.msp" TRANSFORMS="%~dp0AcroPro-SerialLicense.mst" REBOOT=ReallySuppress

 You could also run the patch separately if you would like (mimics my above PS App Deploy scenario).
        

msiexec /update AcrobatDCUpd1701220093.msp /qn REBOOT=ReallySuppress

        
Regarding the transform not applying:
I have seen this occur in our environment to a limited extent, but usually the only parts that do not apply properly are the registry policy settings I have created. To resolve this issue, I made a PowerShell script that removes the associated Policy Registry keys and then re-applies them directly. Our helpdesk can then fire this off across a Remote PowerShell session when a user runs into issues. Other customizations, such as whether or not to install features, usually apply correctly for me.
        

Detection Method:

I always detect on the MSI, such as '{AC76BA86-1033-FFFF-7760-0C0F074E4100}'. For fresh installs, I do not depend on the version. For Updates, I require the MSI to match the version I am installing. 

 

Hopefully this helps you figure out what is happening for your installs.
 

Edited by AlexE

Share this post


Link to post
Share on other sites

Now that I'm back where I can look, I have one quick question: 

Whatever method you're using to run the installation, can you drop to elevated command prompt, run the silent installer and have it successfully run?

Share this post


Link to post
Share on other sites

I found my first problem. I was trying to use an Acrobat .msp file instead of a reader .msp.

Now that I've corrected that, I can perform the install from an elevated command prompt, but when I transfer the same command into SCCM, I get a 1612 error when trying to install.

Share this post


Link to post
Share on other sites

1612?  Looking that one up:  "Error 1612: Installation source for this product is not available"

You could try dropping the Adobe cleaner in with your install and have it run this command before kicking off the installation:

AdbeArCleaner_v2.exe /silent /product=1

Product=1 means Adobe Reader, so it won't touch any Adobe Acrobat installs. 

The downside to this is that if the cleaner successfully runs and the reader install fails, you've just removed the old version and you haven't installed a new one.

Share this post


Link to post
Share on other sites

I have a working installation through Software Center of Acrobat Reader 2017.

Cap1.PNG.41eab86d2335e55f75b08b6e51e37352.PNGcap2.PNG.28632f07e65584d72a6462b8a101e6a1.PNG

Here is the directory structure (Ignore the batch file, I'm not using it), and the application command.

Install and uninstall works fine.

If you are using a version that needs to be patched and you're choosing to use an MSP

Try this: (I haven't had luck with the patches using /qn or /q)
 

Put the following command (this is an example so replace the filename with the actual filename) into a batch file (call it update_reader.bat)

msiexec /p "AcrobatReader123476.msp" /qb!

I like to use dependencies, so I create a new deployment type use the registry key containing the String value DisplayVersion (The example is for Acrobat DC (2015) )

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{AC76BA86-1033-FFFF-7760-0E0F06755100}

Cap3.PNG.439a9e809c774d2ccff331d1c0e7abfc.PNG

Once your detection method is setup, create a dependency for the actual installer, and only deploy the "Patch" (name it like Acrobat Reader DC & Updates)

Then test.

 

Hopefully this helps.

Share this post


Link to post
Share on other sites
33 minutes ago, dj3094 said:

Hi where should we provide license key

You should be using the Acrobat Customization Wizard, when you open AcroPro.MSI to create a new transform, you'll see the following. Place the serial number in there, choosing the "grant offline exception & Disable registration"
image.thumb.png.09c0c152c4848bedfecb1cfe2fea8247.png

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...