/build/static/layout/Breadcrumb_cap_w.png

SCCM 2012: Problems deploying x86 software on x64 systems

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.
Asked 9 years ago 6290 views
5 Comments   [ + ] Show 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. - Badger 9 years ago
  • >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. - anonymous_9363 9 years ago
  • Isn't there a defined cache folder for SCCM packages or has that been deprecated in recent versions? - EdT 9 years ago
  • There is, but the deployment creates a folder with its package ID as its name. - anonymous_9363 9 years ago
  • 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. - dinci5 9 years ago

Answers (5)

Answer Summary:
Posted by: rschauer 9 years ago
Senior White Belt
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.

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
Posted by: dunnpy 9 years ago
Red Belt
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
Posted by: SMal.tmcc 9 years ago
Red Belt
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
Posted by: dinci5 9 years ago
Senior White Belt
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.
Posted by: vjaneczko 9 years ago
9th Degree Black Belt
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.

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ