Adobe Acrobat Pro DC and SCCM deployment

[jesseg75371303]

I am not sure if this is the right place to post this, but the "contact us for help" options just kept sending me to the same page over and over again.

I recently jumped through all the hoops attempting to push Adobe Acrobat Pro DC through our SCCM server and have run into several issues.  For one, it will not actually call the Acrobat Pro installation to put it onto the computer.  It does however show that it is "installed" when you log into the cloud on said PC.  Has anyone had issues with this before?

We are running SCCM version 1511.  Thank you very much.

[Jeff A Wright]

Moving this discussion to the Enterprise Deployment (Acrobat and Reader) forum.

[Guest]

The licensing information is installed by the setup.exe or the MSI in the "build" directory, so you need to execute that as well, e.g.

cd Exceptions\APRO15.0en_US\Adobe Acrobat\

start /wait msiexec /i "AcroPro.msi" /qn /lv* %TEMP%\AcrobatInstall.log

cd ..\..\..\Build

start /wait msiexec /i "PackageName.msi" /qn /lv* %TEMP%\PackageName.log

cd ..\Exceptions

ExceptionDeployer --workflow=install --mode=post

Note that if you choose to use the msiexec method to install Acrobat, the default language will be determined by the operating system language.

The ExceptionDeployer is necessary for the possibility there are other applications in the package (e.g. Edge Code, Scout) which need to be installed after the main "build" directory's packages. Learn more about sccm!!

[davidt191088]

This still doesn't address the black screen issue. Also the SCCM training link does nothing for this discussion. This package is junk. I ended up going  the serial key route and it avoids the CC installer black screen/killing Explorer crap. Works for now but they need to update the documentation to reflect SCCM 2012+. Also, why do we have to script this stuff. It is an MSI already!

[jsutherland1]

We're having the same issue in our environment.  Contacted Adobe directly about it who escalated the issue.  Still waiting for a response.

If we receive some insight from their engineers I'll pass it on.

[jsutherland1]

Haven't heard back from Adobe post-escalation but we have narrowed down the issue in our environment and resolved it.

In our case, AcroPro during installation was looking for Microsoft Visual C++ 2013 (x64) runtime which is a core-app installed on each machine in our environment already.  After downloading the latest 2013 redistributable from MS and installing the installation was still failing, both locally and through SCCM deployment.

To resolve we skipped the C++ runtime check using IGNOREVCRT64=1 property in the command line:

msiexec.exe /i "AcroPro.msi" IGNOREVCRT64=1 TRANSFORMS="AcroDCTransform.mst" /qn

After, we're back in business.  What we haven't been able to determine is why this was working for so long in production prior to suddenly breaking without having made any changes to the package or the deployment.

If this isn't the issue you're running into, enable logging on the deployment and parse the installation log to narrow down the issue.

Hope this helps.

[sourabsharma · Accepted solution]

Hi,

As i can see you are using the base .msi file for installation , it should work fine with latest patch .Please include Patch in the commandline you are using or use setup.exe for the deployment .

I hope it will solve your problem.

Regards,

Sourab Sharma