SCCM 2012: Problems deploying x86 software on x64 systems
Answers (5)
For acrobat, I believe they changed the way setup is run. We are using the exe instead of the msi. You can add a setup.ini file to add command line switches, link in the transforms and point to patch files. You can modify the msi and transforms with the customization wizard. I don't recall if this is all documented, but I got the adobe customization wizard here http://www.adobe.com/support/downloads/product.jsp?product=1&platform=Windows
So my "Installation Program" is literally just "Setup.exe" and it automatically runs everything silently as long as the above ini files are in the proper content location.
Our environment is windows 7 x64 and windows 8 x64 so it definitely works from SCCM 2012 to those machines.
Comments:
-
Oke, this is working for me!
I am not a fan of this method because the AIP (Administrative Install) approach is easier to install future updates.
For now, my boss is happy with this solution :)
Thx - dinci5 9 years ago-
I think you're missing something. This method is REALLY easy to install updates. You simply download the msp and drop it in the root folder of the acrobat install. Then update your setup.ini to include PATCH=filename.msp. Then update your detection method to the newest version and update your content and you're ready to roll. Redeploy and it updates to the newest version. - rschauer 9 years ago
As they are MSI files, if SCCM says it's deployed then it should be - I suspect that there is some self repair/healing going on and it isn't completing for your user.
SCCM deploys in the system context, not the user context as your manual install would have been run in.
The logs will confirm this, or point you in the right direction.
Once you have a bit more informaiton on what is occurring post back and the community will try and help you futher.
Dunnpy
I've installed lots of Acrobat across many clients with SCCM using the MSI and never had a problem regardless of the OS bit version. My guess is that the installation is attempting to finish the install with a user which does not have local admin rights. Login to a fresh install with an Admin ID to test.
If this is the case, you can add an Active Setup key to the transform file and have it launch a repair command. It'll leverage the local system account instead of the local user.
On a related note...
I *think* I may have mentioned once or twice before...always, always, always, always, always, always use full paths to files. Since you can't know where SCCM is likely to deposite locally cached files, use the %~DP0 ruse. - anonymous_9363 9 years ago
I have tried to install it with the "IGNOREVC10RT = 1" switch as this skips the check.
I didn't try to use the x86 msiexec but I thought that if you choose the option "Run installation and uninstall program as 32-bit process on 64-bit clients."
Now I'm not sure anymore :)
Well, as somebody else sugested I used the Bootstrapper install method (setup.exe) now and it seems to work.
Even though I'm not a fan of this method because the "Administrative Install (AIP)" is easier for updates and management. - dinci5 9 years ago