Installing Reader DC 15.016.20039 using SCCM 2012

[BrettHusted]

I'm having an issue pushing out Reader DC 15.016.20039 using an application package I created with SCCM 2012R2. I believe I've narrowed down the issue to the Command-Line syntax I'm using. I'm trying to install Reader with an MST file I created using Adobe's Customization app.

If I use the following syntax msiexec /i "AcroRead.msi" /q, then Reader will install successfully on any workstation I push it to.

When I use the following syntax msiexec /i "AcroRead.msi" /q TRANSFORMS="AcroRead.mst", the installation fails.

I am able to manually install Reader with the MST file using the following syntax msiexec /i [UNC PATH]\AcroRead.msi TRANSFORMS="AcroRead.mst" /qb so I know it's not an issue with the shared folder, permissions or the MST file I had created.

Any help, advice or recommendations would be greatly appreciated!!!

[BrettHusted]

**Update** - I was finally able to install Adobe Reader DC 15.016.20039 with an MST file, but now have a new issue. Using the same application package, I am unable to install the MSP (Patch) file that I extracted from the executable.

According to Adobe's "Windows cmd line and msiexec" document (Windows cmd line and msiexec — Enterprise Administration Guide), the proper syntax should be msiexec /i "AcroRead.msi" /q PATCH="AcroRdrDCUpd1501620039.msp" TRANSFORMS="AcroRead.mst". When I deploy the package to workstation, it fails.

Has anyone come across a similar issue?

[CRoth2]

Patch has to be a full path, can't be relative if I remember correctly.  The easier way is to download the entire Enterprise deployment https://get.adobe.com/reader/enterprise/ and extract to a folder.  Then edit the "Setup.ini" that comes with it.

Change it from:

[Startup]
RequireMSI=3.0

[Product]
PATCH=AcroRdrDCUpd1501620039.msp
msi=AcroRead.msi

[MSI Updater]
Path=http://ardownload.adobe.com/pub/adobe/reader/win/8.x/8.0/misc/WindowsInstaller-KB893803-v2-x86.exe

To be:

[Startup]
RequireMSI=3.0
CmdLine=/sAll /rs

[Product]
PATCH=AcroRdrDCUpd1501620039.msp
msi=AcroRead.msi

CmdLine=TRANSFORMS="Reader.mst"

[MSI Updater]
Path=http://ardownload.adobe.com/pub/adobe/reader/win/8.x/8.0/misc/WindowsInstaller-KB893803-v2-x86.exe

This adds your MST Transform file "Reader.mst" to the command line of the MSI as well as the patch.  The other command line ("/sAll /rs") makes the "Setup.exe" run silently.  Now all you do is import the AcroRead.msi into SCCM update the version information to be 15.016.20039.  This way it gets the MSI Product code to use for uninstall and detection method.  Then go edit the deployment type to change the install command line.  The install command line is now nothing but "Setup.exe" with no switches whatsoever.  Dues to the configuration of the Setup.ini it will run silently, apply for transform and apply the patch.

Works like a champ!

[CRoth2]

BrettHusted​ did that resolve your issue?

[BrettHusted]

Sorry for the delay.

I didn't get a chance to try your method. I ended up creating two deployment types within a single application package. One two install the MSI and MST files. The second to install the Patch. It took some tweaking, especially with the dependencies, but I was finally able to get it to work and install the up to date version.

I'll probably test your method as well, especially since mine was a lot of work. I'll try setting yours up this week and test it out on a few workstations. I'll let you know how it goes.

Thanks for the recommendation.

[CRoth2]

Adobe releasing yet another version of Reader will give you that chance.  If you wanted to use one of these:  15.016.20045 Optional update, June 02, 2016 — Acrobat and Adobe Reader Release Notes​ then you'd download the 15.016.20039 from the enterprise site as mentioned above and extract everything.  Then replace the AcroRdrDCUpd1501620039.msp file in there with the newly downloaded:  ftp://ftp.adobe.com/pub/adobe/reader/win/AcrobatDC/1501620045/AcroRdrDCUpd1501620045.msp

All you have to do beyond the directions above in the previous post is also change this line in the Setup.ini:

    PATCH=AcroRdrDCUpd1501620039.msp

to be:

    PATCH=AcroRdrDCUpd1501620045.msp

This will give you a one Deployment Type Application in SCCM with no Dependencies.  Enjoy!

[NorandaSupport]

I am happy i found this post, it seems a never ending story with adobe patches. I end up having to do something different each time, but your solution seems like it might work every time.

my question though is what do you set as the detection rule, as the product ID doesn't change from patch version to patch version.

it stays {68AB67CA7DA73301B744CAF070E41400} so if i keep that as my detection method it will think each new deployment is already installed?

[RedPanigale]

Did you ever figure this out. I followed CRoth2​ method and it works great for clean installs but will not apply the patch or the transform to existing installs. Older versions show up as "already compliant" in my deployment status.

[CRoth2]

RedPanigale and NorandaSupport It works just as well for the updates, we use it for everything.  I didn't elaborate above on the one step you're missing...when creating the new Application for the newer version, you need to edit the Detection Method to use both the MSI Product code AND the MSI Version  (DisplayVersion) number.  This allows SCCM to differentiate between the versions, as Adobe uses "proper" MSI and MSP patching techniques that most don't and the product id stays the same for all versions of 15.x and even now the 17.x it seems, but the version number changes as the MSPs are installed.  See images below: 

And...

Give it a try and report back!

[NorandaSupport]

I did resolve this by using a file system as the detection rule.

I used the previously installed file version and set the detection as greater than, this worked for the previous deployment, i have not made a new one since then to verify that it will work with new patch, but i don't see why it wouldn't.

[RedPanigale]

I tried this and the deployment fails but with a different error this time: "application not detected after installation". Not sure what I'm missing. You posted screenshots for both 15.x and 17.x. Was that just to say "use whichever applies to you" or do i need to have 2 detection methods? I only set up 1. Also, I'm entering the version number of whats getting installed.. or the new version. Should i be entering the existing or old version?

[CRoth2]

Only one detection method.  That was, whichever version applies to you, and to show that the MSI Product code still hasn't changed even though the software is no longer version 15.x, but now 17.x.  The version that you are installing is the version you put in the detection method.  I am installing the newest, 17.009.20044, so that is what we have entered.  From your files screenshot, I'd say you're installing the 17.009.20044 also.

1. Did you change you current application or did you create a new one?  If you changed it, did you "Update Content" on the Deployment Type?  If not, changes won't be propagated.
2. Are you using "Setup.exe" as your installation program?  Using MSI (msexec /i acroread.msi ...) won't work right as it can't find the patch that way.
3. What version does your Adobe -> Help -> About say after installing?

Trying to determine if the right version is installed and not being detected, or if the detection is working, but wrong version is installed.

[RedPanigale]

Looks like I solved this by unchecking "detect associated content dependencies and add them to this distribution" when distributing the content. This causes Adobe Reader DC to be listed as a dependency in the summary section. I leave this checked for other deployments (checked by default) and it works fine but not with reader apparently.

The only other issue I'm having now is that the transform does not get applied to existing updated installs. If a previous install (non customized) has auto updated to the latest version then it succeeds as "already compliant" and the transform is not applied.

[CRoth2]

Glad it seems to be working better, but neither of the two things you mention should be an issue.  I wonder if it just fixed it because you redistributed the software.  I'd check the references tab and the dependency map to see if you mistakenly have something as a dependency or maybe you have an application that requires Reader DC as a dependency.  You don't need any dependencies for this install.

Was this a clean/newly created application or did you update an existing application you already had created?

As for updated ones, that is correct.  It would not update anything because it is already detected.  You'll either need to use the uninstall option and reinstall, or just wait until the next update is released and make sure you get your application out early.  Upon upgrade it will take the new settings.

[RedPanigale]

Clean application from scratch. Think I'll try getting the next version out asap before the existing installs have a chance to update. Thanks!

[CRoth2]

Hopefully that does the trick for you and gets everyone using the MST settings you want them to have.  Once of which I hope is to disable auto-updating 🙂

[RedPanigale]

Any idea why Acrobat DC and Reader DC show up in "installed updates" as if they are windows updates? Pushed acrobat to a user last night and the windows 8.1 dialog forcing a reboot came up as if windows updates were installed. I selected "suppress reboot" in the Customization Wizard. This has only happened on 1 machine as far as I know.

[CRoth2]

MSP updates do show as an update.  Mine are the same way.  I don't know why you'd be rebooting though as it should not if you've configured the MST file correctly and have it in the Setup.ini command line section properly.  I'd have to see it happen on multiple machines before being concerned.  It may just be that machine had other updates that were installed, or also needed reboot.

If the reboot prompt is a normal SCCM Software Center prompt for reboot I'd assume the installer returned a 3010 code or similar stating it requires reboot.  As long as it is not forcing reboot immediately without prompting I wouldn't be concerned.

Also make sure you are not accidentally forcing a reboot User Experience tab:

[RedPanigale]

Yep all that is set correctly and the reboot is only happened on 1 machine so far. Thanks again for your help!

[CRoth2]

No problem.  Feels good to be able to share when I've found answers from so many others in the past.  If you don't mind feel free to mark any particular comments as helpful, only if you felt them to be of course!  Thanks!

[Guest]

Hey guys! Great info here. I am stuck in a similar situation with SCCM. Long story short, I can deploy the latest Adobe Acrobat Reader DC with no issues. The problem comes when we try to remove it via SCCM. It fails with error 1605. If I recall, the previous SCCM Admin had the same issue initially. However, he is no longer with the company and I am pulling my hair out trying to figure out WHY I cannot remove Adobe Reader.

If it does not remove, we may see issues later on with Patching with Shavlik as we have seen in the past (Error 1603).

Are you guys successfully able to Uninstall the packge via SCCM or Software Center?

[Guest]

Nevermind! Looks like it is working now after I deleted the package/deployment and recreated it.

With this method, have you guys seen any issues patching with 3rd party tools like Shavlik? Re: Installing Reader DC 15.016.20039 using SCCM 2012​

[CRoth2]

We use Shavlik also (not sure if I mentioned before and didn't read back through to check).  Yes, and no.  The issue I found was if I have not yet updated the Reader DC Application, but we released Shavlik updates for Reader DC.  Shavlik/Software Update in SCCM updates the computer without any issue, which changes the Version/DisplayVersion.  Here is where the issue starts.  If you have the detection method the way I do with Version is equal to 17.009.20044, then when Shavlik updates the computer the version no longer matches so it is not detected.  IF you have Reader DC deployed as Required, this will trigger SCCM to try and install again, since it is no longer detected.

In the case of Reader DC (I think Acrobat also) this can be solved by, either setting the detection method to Version is greater than or equal to 17.009.20044 or by adding a Requirement to the Deployment Type that the Version is either "less than or equal to 17.009.20044 or the version doesn't exist at all" (in case of not being installed yet).  The greater than or equal to method is valid for these products because the MSI Product Code is not changed as I detailed in previous post.  Therefore even if you are several version behind on the Application and Shavlik updated the computer the detection method will still be valid and more importantly the uninstall string is still valid since the MSI Product Code is the same.  I personally do NOT like this method because the Application still says the old version number is installed, even though if you check programs and features and the new version is indeed installed.

I do the second option because it is applicable to MORE programs.  I'll try to explain.  By using a detection method with version is equal to coupled with a Requirement, when a newer version is installed by Shavlik, the next time "Application Deployment Evaluation Cycle" runs (we do daily in client settings) the Application is no longer displayed in software center at all since a newer version is installed than the application I have deployed, since the Requirement is no longer met.  This IS a bit over kill for Reader DC since it uses MSI/MSP relationships properly, but most programs don't.  Case in point, Flash Player.

Expanding on this, most programs MSI Product Code changes when a new version is installed, like Flash Player.  Flash Player is even more of a PITA, because the EXE install is totally different than the MSI, it is not just a wrapped MSI with and EXE.  Adobe Flash Player 21.0.0.213 NPAPI not detecte... |Shavlik User Community.  So we cannot use the MSI Product Code for detection, but rather we needed something that does bot EXE and MSI.  That answer is:  "[HKEY_LOCAL_MACHINE\SOFTWARE\Macromedia\FlashPlayerPlugin]".    So with this example you can see when a new version is installed by Shavlik, even if your detection says it is still installed, the uninstall string will be broken, because the MSI Product Code has changed.  So Software Center still says the software is installed, but if you try to uninstall it will not be able to since MSI Product code has changed.  In this way the Requirement just no longer displays the deployed version of Flash Player in Software Center to avoid confusion and issues for the user. 

Hope this all makes sense!  I know I went a bit crazy here, but without detail it is even more confusing.  My entire argument for my method is debunked though if you don't deploy updates from shavlik until you update the application that is deployed via software center.  We just never seem to be ready with Applications when we're doing updates with Windows/Shavlik to our users.  😞

[deborah93111]

I am trying to deploy acrobat reader 2017 base and patch update in a single application in SCCM

I have the base install 2017 installing fine but the secondary deployment type of the update is not deploying with it.

this below is my detection rule for the update - the version is the base that I am currently deploying.

[NorandaSupport]

Doesn't seem like i can edit my previous post. so let me add some more info here.

I use the .exe as the installation program (see my other post for detection method)

which in turn uses the setup.ini file to install the program with my transforms.