Run Setup.exe as 32-bit using VBS script?
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:
----------------------------------------------------------------------------------------------
MsgBox("Working?")
----------------------------------------------------------------------------------------------
But still nothing. No msgbox popped up.
I'm stumped, and suffering from a lack of understanding.
Can someone offer some guidance?
Thanks.
QUICK UPDATE:
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?
Thanks.
NEWEST UPDATE 12/4/14
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.
Thanks.
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:
----------------------------------------------------------------------------------------------
MsgBox("Working?")
----------------------------------------------------------------------------------------------
But still nothing. No msgbox popped up.
I'm stumped, and suffering from a lack of understanding.
Can someone offer some guidance?
Thanks.
QUICK UPDATE:
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?
Thanks.
NEWEST UPDATE 12/4/14
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\
Thanks.
4 Comments
[ + ] Show comments
Answers (0)
Please log in to answer
Be the first to answer this question
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? - anonymous_9363 9 years ago
Thanks. - benevida 9 years ago
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. - anonymous_9363 9 years ago
Thanks. - benevida 9 years ago
EDIT: Using the information provided, I've investigated and expanded the original question above. - benevida 9 years ago
My experience of Danish developers is very positive, but YMMV. - EdT 9 years ago