I am using WIX 3.8, Windows 8 Pro, Visual Studio 2013, and I am doing a Silent Installation.
When I run with no /quiet arguments, Ir runs OK. But when I put "/quiet", nothin happend.
There is some problems with /qn Arguments... Any other Arguments Runs OK.
string arg = " SetupWIX.msi";
Process p = new Process();
p.StartInfo.FileName = "msiexec.exe";
p.StartInfo.CreateNoWindow = true;
p.StartInfo.Arguments = "/i " + arg +" /quiet /l*v log.txt";
p.Start();
And it give error 3.
MainEngineThread is returning 1603.
Any Ideas?
Tahnks
Based on the log you sent me, your MSI need to be elevated.
Not all MSI's do. Most do. If you are installer in a per-machine context and/or writing to restricted areas ( Program Files, HKLM, Windows an so on ) you'll need elevation. Typically when you double click an MSI the UI sequence runs as standard user and then when it transitions to the Execute sequence it'll prompt for elevation if required. However when you run /quiet it can't do that so it just fails instead. The two ways around this are to elevate the calling process or first 'advertise' the MSI so that the system trusts it. In that case the UI->Exec elevation happens automatically without a UAC request.
I SOLVE IT!! Thanks yopu all for your time
I was MIssing
p.StartInfo.Verb = "runas";
I did not know I need Administrator Privilegies to execute "/quiet".
Related
I created MSI installer using WiX.
when I double clicked it, it works, when I install it through CMD it also works, but when I try to install it from CMD using /quiet parameter it does not launch,
I want to launch my installer from CMD like this : setup.msi /quiet
how to do ?
Please help
Admin Rights: Please make sure you launch your MSI installer from an elevated command prompt (cmd.exe):
Search for cmd.exe and right click it and select Run as Administrator.
Now run the MSI with the /quiet parameter.
Debugging & Logging: It helps to create a log file to determine what is going on. Please see information on MSI logging here. You can enable logging for all MSI operations, or define logging via the command line or via settings inside the MSI. Please visit the link for details.
Express Logging (Verbose): Simplest possible, verbose logging from cmd.exe:
msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log
I want to verify that an MSI is installable by normal users. Is there any way to emulate the permissions flow of an install using UAC without having the graphical prompts?
Background:
I work with an application that is distributed on Windows via an MSI. We do automated testing on it by running msiexec and then testing the resulting application. This works, but we recently ran into an edge case it doesn't cover.
We recently added a CustomAction in our wix setup that is run at the end of the install and which requires elevated permissions to run. The problem is CustomActions, by default, run with Impersonate="yes" which means they run with the running user's permissions and not the elevated permissions granted by UAC.
In our testing, we're running from an administrator context so the install succeeds. However typical users will require a UAC prompt to grant the MSI temporary admin rights to install. Since the custom action is not running with that admin context, the install fails.
So what I want to do is set up an automated test environment that emulates the user experience more closely. UAC is generally designed to not be scripted for security reasons, which complicates the issue. So what I'm wondering is if there's any way to exercise the permissions flow in a way that is automateable, given I have full control over the environment.
Elevated Rights: A per-machine setup can run with temporary admin rights - as you put it - without being a per-user install. This is done via Group Policy / Active Directory and distribution systems that handle this kind of scenario properly.
Emulate Elevated Rights: To emulate the elevated rights on a regular PC (without a distribution system), you can use a group policy / registry hack called AlwaysInstallElevated. Once applied, it essentially means that all users can run with elevated rights just launching an MSI. Sizable security hole, so don't use it for fun. You can, however, kick off any install and install with elevated rights - if that is what you need.
Deferred Mode Custom Action: Only deferred mode custom actions have elevated rights. Immediate mode custom actions can not elevate and if they try to do something to the system that requires admin rights you will get a runtime error. If you run such a failing MSI with "real" admin rights, then you will see the MSI appear to successfully install (though it will fail with elevated rights for a standard user).
Implementing a deferred mode custom action generally (for non-trivial purposes) requires some involved steps. Perhaps you are familiar with them? You can't access properties directly, you need to "send them to deferred mode" via a mechanism called CustomActionData (SO). And adding a marginal WiX sample for deferred mode.
UPDATE: New link to samples for deferred mode custom actions: How to hide the value of customactiondata in logs of MSI? - you will find links to this github sample (and other samples): https://github.com/glytzhkof/WiXDeferredModeSample
Lobbing you some links for now (too many, but just thought I'd hand you the bunch - I think the first link will do, 5 for classic technical article, 6 for a modern approach using JSON):
1: Tip: MSI Properties and Deferred Execution
2: How to Access Windows Installer Property in Deferred Execution
3: It Wants Me to do What? Some Notes on CustomActionData in InstallShield
4: Just Be Yourself: Understanding Windows Installer (MSI) Custom Action Contexts
5: Installation Phases and In-Script Execution Options for Custom Actions in Windows Installer
6: Beam Me Up: Using JSON to serialize CustomActionData
Privileged: If you want to ensure that the MSI package installs per-machine properly for a standard user, I would add a launch condition to the MSI to abort if privileged rights are not available (no chance of success). Note that this does not check for admin rights, but for privileged rights (elevated rights).
<Condition Message="Elevated rights required to install package.">Privileged</Condition>
msiexec.exe: And just for the record, adding a little batch to check for msiexec.exe error codes (not tested recently, but here goes - note that a number or error codes indicate success - for example "reboot initiated" and stuff like that):
1603 = Fatal error. See link above for more.
start /wait msiexec.exe /i Setup.msi /l*v Setup.log
if "%errorlevel%" == "0" goto OK
if "%errorlevel%" == "1603" goto err
if not "%errorlevel%" == "0" goto err
:OK
GOTO END
:err
rem print message and return errorlevel
echo "Error: Msiexec failed with errorlevel = %errorlevel%"
exit /b %errorlevel%
:END
Note that a number of exit codes indicate success (beyond just 0):
1641: ERROR_SUCCESS_REBOOT_INITIATED
3010: ERROR_SUCCESS_REBOOT_REQUIRED
There are probably others I have forgotten. Sample only.
I have a program that auto-updates itself when it finds a newer version MSI. I used to create the MSI with a VS2008 Setup project. I migrated the development to VS2013, lost the Setup project, tried IS and got extremely frustrated and finally landed with WIX.
The MSI created with WIX does all I need but fails in the auto-update logic:
Because the program can be running under a limited user account, when it detects a newer MSI, it first Advertises it with the credentials of an Administrator. These credentials are stored encrypted in an XML file.
Then, once the MSI has been advertised, it is launched with the current user. The code (in short)
Process^ advertise = this->advertiseMSI(shortpath,mydomain,myusername,mypassword);
advertise->WaitForExit();
Process^ install = this->installMSI(shortpath);
Where advertiseMSI is:
Process^ process = gcnew Process();
process->StartInfo->UseShellExecute = false;
process->StartInfo->FileName = "C:\\Windows\\System32\\msiexec.exe";
process->StartInfo->Arguments = "/jm " + "\"" + msiPath + "\"";
process->StartInfo->WorkingDirectory = Environment::GetEnvironmentVariable("WINDIR");
process->StartInfo->UserName = userName;
process->StartInfo->Password = this->getSecureString(Password);
process->StartInfo->Domain = userDomain;
process->StartInfo->Verb = "runas";
process->Start();
return process;
and installMSI just launches the Msiexec in a silent install with the current user.
This worked fine with the MSI created with VS2008 but it fails with the WIX MSI.
The log of the msiexec is:
"Error 1730. You must be an Administrator to remove this application..."
If I run the MSI manually, it works when logged as admin but when logged as user it fails and doesn't ask for elevating privileges.
I have set InstallPrivileges="elevated" InstallScope="perMachine" in the Package section and does not make a difference (I have tried every possible combination of those). It seems to me that the MSI is not advertised but the code does not fail. Looks like the MSI is always run with limited privileges.
I have also tried to set AllowAdvertise="yes" in the only one Feature of the product.
One main difference I can see with the MSI produced with VS2008 is that the later had two features, Admin and user.
I don't know if you're still struggling with this problem, but I've come across a similar problem with an installer built with NSIS, so perhaps this will help you or others. I was able to overcome this in my situation by using command shell indirection as follows (C# code):
ProcessStartInfo processInfo = new ProcessStartInfo("cmd", "/C myapp_installer.exe /S /D"); // Options /S /D apply to myapp_installer.exe.
processInfo.UseShellExecute = false;
processInfo.Domain = domain;
processInfo.UserName = username;
processInfo.Password = password; // Obtain securely not hard-coded.
Process process = Process.Start(processInfo);
I can't fully explain why this works, when directly calling the installer fails to pass the required credentials, but I'm pretty certain that it has to do with what is explained by Chris Jackson on the MSDN Blog, which incidentally was referenced in the answer to your related question.
I hope this helps!
Exit code 1625 is "This installation is forbidden by system policy. Contact your system administrator."
What I'm doing is calling it this way:
Process installProcess = Process.Start(msiPath, "/quiet");
I can run the msi fine if I open it manually. This is on windows server 2008...
The intent of this is to automatically update my .net forms program with the latest version. Anybody have a clue what sort of setting is causing this? I mean, the clients are going to be using vista/7/xp, but I still need to know what kind of security settings will ruin my plan.
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.Arguments = "/i " + "\""+Directory.GetCurrentDirectory()+"\\"+msiPath +"\"" +" /q";
startInfo.FileName = "msiexec.exe";
startInfo.Verb = "runas";
Process installProcess = Process.Start(startInfo);
Calling the msi this way did the trick.
Turned out to be some kind of UAC issue I think. The runas verb somehow elevates the permissions the program has. Even though my UAC prompts were disabled on server 2008 I still had to do this to get around it.. strange huh?
When i try to run a msi using System.Process.Start("test.msi") in a vb app i get the following error.
The installation package could not be opened. Contact application vendor...
Msi file works fine when double clicked, tried System.Process.Start with text files and exe files and they work fine, problem only with msi
files. Running vista. Also tried xp but no luck
Thanks
If you have a setup.exe with your msi, run that instead. Otherwise, use this code:
Process p = new Process();
p.StartInfo.FileName = "msiexec";
p.StartInfo.Arguments = "/i PathToYour.msi";
p.Start();
(from here: MSI doesn't run from within C#)
The reason for needing to do it this way is that when you do System.Process.Start("file.txt") it will work since it is (sort of) calling notepad.exe %1 which will work for a text file but msiexec %1 will not work for a msi, since msiexec has a required parameter (Option).
You can test this yourself, by trying msiexec file.msi on the command line - it will give you this helpful little message:
To help pinpoint the problem, try running some other .exe from your code, like notepad.exe.
System.Process.Start("notepad.exe")
Had the same problem. The problem lies on declaring the path of the msi. You need to put double quotes around it.
Instead of
p.StartInfo.Arguments = "/i PathToYour.msi"
try
p.StartInfo.Arguments = "/i ""PathToYour.msi"""