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?
Related
At work we are constantly juggling multiple licenses of a software package. The license key is stored in the registry in HKEY_LOCAL_MACHINE so I wrote a Windows Batch File that when run as administrator, edits the registry key to one of the license strings.
Most recently I've written a GUI based application in VB.net that uses the software package's API to add some cool functionality. I also wanted to include a GUI based license switching module to make the juggling even easier. However, I haven't been able to succeed in doing so.
I've tried multiple methods, running the program as Administrator:
Using VB.Net's Registry module
Dim key As RegistryKey = Registry.LocalMachine
Dim autoshell As RegistryKey
autoshell = key.OpenSubKey(registryKeyDirectory, True)
autoshell.SetValue("Software", licenseKey)
autoshell.Close()
Running a .reg script
Dim p As New ProcessStartInfo
p.FileName = "regedit.exe"
p.UseShellExecute = True
p.Arguments = """C:\test.reg"""
Process.Start(p)
Sending the Registry edit command to CMD
Dim process As New Process()
process.StartInfo.FileName = "cmd.exe"
process.StartInfo.Verb = "runas"
process.StartInfo.UseShellExecute = True
process.StartInfo.Arguments = "/K reg add ""HKEY_LOCAL_MACHINE\SOFTWARE\Software\Licenses\Serial Numbers"" /f /v ""Software"" /t REG_SZ /d """ + licenseKey + """"
process.Start()
Running the Windows Batch Script through CMD in a similar way to above
'Code is much the same as above
All of these methods worked perfectly with editing a Key in HKEY_CURRENT_USER. I thought it might be the particular key and the permissions relating to it, but after further testing I found that none of the above code could edit any arbitrary key in HKEY_LOCAL_MACHINE.
I've looked at just about every link on Stack Overflow relating to this and no-one seems to be having the same problem as me. I suspected it might have to do with the privileges of my user account on the office network, so I took the code and tested it on my home PC but to no avail.
At this point I'm really at my wit's end and would greatly appreciate any help!
Thank you in advance for reading :)
This is caused by the Registry Redirector. (Noted: This link seems to be written in the win7 era and kind of outdated). Your program is 32-bit, when running on a 64-bit OS, the call to registry is redirected to the 32-bit logical view of the registry.
In Visual Studio, compile your program to target AnyCPU, also uncheck the "Prefer 32-bit" checkbox. Then the program would run as 64-bit on 64-bit OS, and 32-bit on 32-bit OS.
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!
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".
I'm using c#, .net 4, WIX 3.5, Windows Vista.
I have made my application compatible with RestartManager by p/invoking the RegisterApplicationRestart method and by handling the WM_QUERYENDSESSION and WM_ENDSESSION window messages (I return new IntPtr(1);).
If I try to update my application manually, then everything works as it should:
Launch application;
Launch msi file containing new app version;
During the installation/update, I'm prompted to close the running application;
Upon continuing the running app is closed, install completes, and the app is restarted;
If I try to update my application from the application itself, then I run into problems:
1) Launch application;
2) Download the new msi file;
3) Launch msi file with:
using (System.Diagnostics.Process p = new System.Diagnostics.Process())
{
p.StartInfo.UseShellExecute = false;
p.StartInfo.FileName = "msiexec";
p.StartInfo.Arguments = "/i \"" + downloadPath + "\" /passive";
p.StartInfo.UserName = "Administrator";
p.StartInfo.Password = securePassword;
p.Start();
}
4) Because I'm using passive mode, the application is closed automatically;
5) After the installation, my application is not restarted and under Event Viewer I have an
Event 10007 - Application or service 'MyApp' could not be restarted.
I have tried:
Not to use passive mode for msiexec;
Launch msiexec via cmd.exe (cmd.exe /C "msiexec /i ....") - in the hopes that launching msiexec from another process would solve the problem;
Wait for 60+ seconds before launching the msi update (shouldn't be relevant in my scenario, but MSDN documentation has something about it...)
But none of the above has worked (always the same result).
Having to launch the setup with elevated permissions might have something to do with the issue, because during the manual update I get a warning in the Event Viewer - Application MyApp (pid 3220) cannot be restarted - Application SID does not match Conductor SID.
Despite this, restarting the app still works. Googleing the warning yields no good/specific results, only that this warning is probably caused by running the msi in an elevated prompt.
How do I fix (or workaround) this issue, so that I can update my application from the application itself and restart my application afterwards?
Edit - extra testing:
There doesn't seem to be a need to respond to WM_QUERYENDSESSION and WM_ENDSESSION messages, because application restart during a manual upgrade works without them, so we can rule them out;
If I don't provide administrator credentials to the application initiated upgrade and instead I type them in during the upgrade, then app restarting works;
If I run an elevated command prompt and initiate an application upgrade from there (manually), then app restarting still works;
In order for application upgrade to work at all under Standard user accounts (so far I tested under an Administrator account with UAC), then I also have to set p.StartInfo.LoadUserProfile = true;. Otherwise nothing happens. (application restart still doesn't work though);
I tried all other process StartInfo parameters that I could set - WorkingDirectory, Redirect, Verb
(= "runas") - no change in results;
I installed Vista SP2 onto the virtual machine that I have been testing on (so far ran SP1), but no change;
I performed an "automatic" application upgrade with verbose logging. In the end there was an error message - RESTART MANAGER: Failed while restarting applications. Error: 352. That error code is very generic (http://msdn.microsoft.com/cs-cz/library/aa373665), inorder to get more detailed info I would have to write my own installer that would call RmGetList after the error, then I might get more details (this though is something I'm not willing to do);
Edit 2 - msi log file:
http://mommi.planet.ee/muu/log.txt
Assuming that the manual process indeed works without any problem it seems that your need for Administrator privileges in combination with the "updating itself" leads to these problems. I see the following options:
create a batch file to execute the update
When you want to update call this batch file (with elevated privileges), make the app close itself... the batch file should wait some seconds, then check whether the app is still running (and close it in case) and then run the commandline you need to run msiexec - don't restart the app from within msiexec but after a successfull run of msiexec from the batch file.
create a batch file which is always used to start the app
When the time comes to update you just end the app. Either the batch file check for an available update and applies it, starting the app after successfull update OR the app set some environment variable which is then accordingly processed by the rest of the batch file.
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"""