Elevating a process to running an MSI from a standard user’s account

One of the questions that consistently comes up with the advent of Windows Vista and Windows 7’s use of the UAC is how to run applications or processes without being prompted for a username/password.  There are a number of places online that talk about how to use the C# classes + LogUser API to impersonate a user.  In fact, there is a very nice class written here that makes it quite easy.   However, these options don’t work for everything — and one specific use case is during installation.  So, for example, you’ve written a program and you want to provide automatic updating through the application.  To do the update, you’d like to simply shell to an MSI.  Well, there is a simple way to do this.  Using the System.Diagnostics assembly you can initiate a new process.  So, for example:

System.Security.SecureString password = 
                      new System.Security.SecureString();
string unsecured_pass = "your-password";
for (int x = 0; x < unsecured_pass.Length; x++)
{
  password.AppendChar(unsecured_pass[x]);
}
password.MakeReadOnly();
StringBuilder shortPath = new StringBuilder(255);

GetShortPathName(@�c:\your file name.msi�, shortPath, 
                 shortPath.Capacity);
System.Diagnostics.ProcessStartInfo myProcess = 
                 new System.Diagnostics.ProcessStartInfo();
myProcess.Domain = "my-domain"; 
myProcess.UserName = "my-admin";
myProcess.Password = password;
myProcess.FileName = "msiexec";
myProcess.Arguments = "/i " + shortPath.ToString();
myProcess.UseShellExecute = false; 
System.Diagnostics.Process.Start(myProcess);

So, using the above code, a program running as a standard user, could initiate a call to an MSI file and run it as though you were an administrator.  So, why does this work?  First, in order for this type of elevation to work, you need to make sure that UseShellExecute is set to fall.  However, if you set it to fall, you cannot execute any process that isn’t an executable (and a .msi isn’t an executable).  So we solve this by calling the msiexec program instead.  When you run an msi installer, this is the parent application that gets called.  So, we call it directly.  Now, since we are calling an executable, we can attach a username/password/domain to the process we are about to spawn.  This allows use to start the program as if we were another user.  And finally, when setting the path to the MSI file we want to run, we need to remember that we have to call that file using the Windows ShortFile Naming convention.  There is an API that will allow you to accomplish this. 

If you have this setup correctly — when the user runs an MSI file, they will not be prompted for a username or password — however, they will still see a UAC prompt asking to continue with the installation.  It looks like this (sorry, had to take a picture):

So, while the user no longer has to enter credentials to run the installer, they do have to still acknowledge that they wish to run the process.  But that seems like a livable trade off.

–TR