Hi all,

We have trouble deploying x86 software on x64 WInows 7.
We create an application and deploy it without nay problems. The native x64 bit MSI is working fine.
But x32 MSI is giving us headache.

Example:
We try to deploy Adobe Acrobat Standard 11.0.0
When I run the command manually it installs without any issues:
msiexec /i AcroStan.msi TRANSFORMS=AcroStan.mst /q

When we install it via SCCM, the installation completes successfully according to Software Center.
However, when we run the software the Windows installer starts to run over and over again.
We cannot start the software.

We had the same issue with Autodesk DesignReview.

We don't have any x86 systems in our enviroment but we have noticed that this issue happens with 32 bit installers.

Any suggestions?

Thank you.
Answer Summary:
Cancel
5 Comments   [ + ] Show Comments

Comments

  • doesn't v11 have a pre req of Vis C++?? if you run the MSI it will install without the vis C++ but you may get either an error, or what you are seeing.
  • >you may need to change your deploy to call the 32 msiexec directly. <BR>

    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.
  • Isn't there a defined cache folder for SCCM packages or has that been deprecated in recent versions?
  • There is, but the deployment creates a folder with its package ID as its name.
  • Vis C++ is a pre req but it is already installed on all our systems.
    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.
Please log in to comment

Community Chosen Answer

2

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.

Answered 01/13/2015 by: rschauer
Senior White Belt

  • 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
    • 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.
Please log in to comment

Answers

0
Check the event logs, and if necessary enable Windows Installer logging (voicewarmup) to see if it sheds any light on your issue.

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
Answered 01/13/2015 by: dunnpy
Red Belt

Please log in to comment
0
you may need to change your deploy to call the 32 msiexec directly. 
try using c:\windows\syswow64\msiexec /i AcroStan.msi TRANSFORMS=AcroStan.mst /q
Answered 01/13/2015 by: SMal.tmcc
Red Belt

Please log in to comment
0
Thx for your input guys.
I'll check this in two days and get back to you as I have a training tomorrow so I won't be able to test anything.
Answered 01/13/2015 by: dinci5
Senior White Belt

Please log in to comment
0

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.

Answered 01/15/2015 by: vjaneczko
Seventh Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity

Share