Software Deployment Question

Run Setup.exe as 32-bit using VBS script?

12/02/2014 6924 views
I'm trying to deploy an application from SCCM 2012 to Windows 7 x64 clients.

I need to run Setup.exe (with switches) and copy an XML configuration file to the installation directory.  So I wrote a VBS script called 'install.vbs':

Set objShell = CreateObject("Wscript.Shell")
strArgument = "Setup.exe /s /w /v" & chr(34) & "/qn /L*vx+ \" & chr(34) & "%temp%\AppNInstallation.log\" & chr(34) & " EULAACCEPTED=YES" & chr(34)
objShell.Run(strArgument), 0, TRUE
Set objShell = Nothing

Set filesys = CreateObject("Scripting.FileSystemObject")
If filesys.FileExists("BusinessSystemSettings.xml") Then
filesys.CopyFile "BusinessSystemSettings.xml", "C:\ProgramData\TheCompany\AppN\"
End If

When I run the script locally, things go perfectly.  When I run it as an application deployment from SCCM 2012 it errors out.  So, I took a look at what was happening.

When I double click the script (or run it from an elevated command prompt) Setup.exe runs as 'Setup.exe *32'.  When the script is run from SCCM 2012, Setup.exe runs as 'Setup.exe' (which I believe to be in a 64-bit context).  When I tried to deploy without using the /s switch on Setup.exe, I see the error message: "Windows Installer: The installation package could not be opened.  Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package."

I researched the question of how to create Wscript.Shell as 32-bit within the script, but I didn't come up with a method.

Then I tried checking the box "Run installation and uninstall program as 32-bit process on 64-bit clients".  When I tried to deploy the application that way, I got.....nothing.  Nothing happened. I see a process for 'wscript.exe *32' appear, but nothing gets executed.  I tried changing the script to:


But still nothing.  No msgbox popped up.

I'm stumped, and suffering from a lack of understanding.

Can someone offer some guidance?



I have found out that anytime this setup.exe is run under the system account (nt authority\system) that this error occurs.  I tried it using PsExec and I came across the same problem.  Another application by the same vendor has the same problem.  i tried getting to the msi directly, but there are multiple prerequisites that are also installed by the setup.exe, (and I can't make heads or tails out of it).  Any ideas?



Following the information from EdT, I looked at the changes made to the user folder when I installed the application under the context of my own username.  I noticed that it stores the msi during installation in 'C:\Users\\AppData\Local\Downloaded Installations'.  Could it be that because the LocalSystem account doesn't have a user folder that it's erroring out when it tries to do that step?  Or is the installation using an environmental variable that gives it an equivalent path when installing under LocalSystem?  I'll investigate, but any additional information would be appreciated.

4 Comments   [ + ] Show comments


  • One, there are NO paths in your copy statements.

    Two, most deployment systems, including SCCM, use the local System account for deployment so popping up message boxes is pointless, since that account has no console output. Use a log file.

    Three, clearly, the set-up program extracts and runs an MSI (the arguments give that away) so why not use the bare MSI with an MST and include the file in the MST?
    • SCCM 2012 copy the installation files to an arbitrary directory before running the install command against that directory. Given this, I don't know how to specify paths in the copy statement. Can you give me some tips? Also, how would you specify the log file that you suggest using to monitor output?

      • >arbitrary directory
        But that's not the path you need to specify, is it? You want to copy the file (presumably) from whatever folder the application installs to. It's *that* path that you need to specify.

        >how to specify paths
        [sarcasm] Tricky, when there are so few examples of such on the web [/sarcasm]

        The log file would need to be created by the script. There's an extraordinarily good class file for just such a purpose, which you can paste into your script.

        However...forget all that. The pre-requisites that you're having problems with *must* be documented by the vendor. If they're not, it can't be that hard to install the package on a VM and *find out* what they are by that means. Then, your deployment system can deploy them before the main app.

        As for the 64bit-vs-32bit question, surely that option is taken care of by choosing your target OS when setting up the package? And anyway, as I suggested, your best course of action is to extract the MSI, create an MST for it and use that combination.
  • Take a good look at the source media. The most common implementation of pre-requisite installs calls the installers from one or more folders on the source media. There is no guarantee that the setup.exe is calling the pre-req installers, as this could also be handled by the UISequence in the MSI. The bottom line is that you need to do some work in identifying what pre-reqs your software requires, and make sure they get installed before the main application. There may also be different pre-req lists for 32 bit and 64 bit environments, and if this is the case then your script is going to have to determine the O/S bitness as the first step in the installation. Check out Darwin Sanoy's site for examples of such scripts. If you are unable to use script to determine what folder your install is running from (and hence the location of your XML file), then why not write a section in your script that creates the XML file through code rather than copying it. It's really not that hard, and if you are a serious app packager then writing simple utilities to convert text files into code that creates the text file is one thing I feel is worth spending time on. I also don't see where you mention any reference to checking vendor installation documentation, which these days often provides for silent deployment using one of the many deployment solutions in the marketplace. You can waste a lot of time unnecessarily by not checking what the vendor provides before starting a packaging exercise
    • Thank you for your input. To clarify, the copying of the XML file has worked well even with the error during execution of setup.exe. I believe that issue to be a red herring. As to vendor documentation, I have poured over it. Additionally, I have been in touch with tech at the vendor and sent an email with screenshots that the tech is going to forward to the developers. Since my original post, I have learnt that another product by the same vendor has the same issue. I have also learnt that it is not a UAC issue, and that it pertains to using the local system account. I'll check out Darwin's site, but do you have any recommendation for a better understanding of how installing as the local system account changes things, or how I can pinpoint the cause of the Windows Installer error?
      • A local system account does not have a user profile. Therefore anything in the MSI that tries to install to a user profile is going to result in an error (usually). It can be something as simple as having user folders defined in the directory table, which of course will cause a failure during the costing process when the windows installer engine is unable to access the missing user folders. Another failure point can be caused by the installer looking for another application that it needs to install into, such as an excel add-in, which again involves a user profile. Yes, it is possible to fix such an MSI - basically by removing any content that requires a user profile (via a transform) and then deploying this missing content later, when a user profile is available, using Active Setup, for example. Finding vendors that do not understand local system deployment these days is getting quite tricky, but it seems you have stumbled upon one. Good luck getting this sorted. By the way, I notice in your postings that you have deliberately obscured the name of the application. I would normally advise to post the full details of the application as there may be other forum members that have already created a solution and which would be able to help you immediately, but perhaps there is some reason for you to keep this concealed.....
  • Thank you EdT!!!! I will look into the idea that the MSI is trying to access a user folder. The tech at the vendor has told me that I do not have permission to mess with anything (i.e. copying the preconfiged XML file to the installation directory) so I would just as soon leave my fiddling anonymous. i will say that the developers are in Denmark and who knows how they program over there! (cheap, ill-informed shot, I know).
    EDIT: Using the information provided, I've investigated and expanded the original question above.
  • Your best course of action is to generate a verbose log of the MSI install when using your own account, and then also generate a verbose log of the install attempted via your deployment system. However, the path that you refer to in the user profile makes me ask whether the MSI is actually being downloaded at some point. Internet access is also not available to the local system account, so a download attempt would fail. Also, a successful MSI installation caches a copy of the MSI in the c:\windows\installer folder (usually hidden), so if there is a copy in there, albeit with an obfuscated name, the installation completed successfully.
    My experience of Danish developers is very positive, but YMMV.
    • To be clear, the Danish comment was a joke, and a bad one at that. This 'Downloaded Installations' folder is not populated from the internet. It's got to be where the MSI is extracted to from the Setup.exe. I just don't have the experience to know if that location is commonplace, or how to change it. I'll examine the logs and come back later.

Be the first to answer this question

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