Link to home
Create AccountLog in
Avatar of grsychckn

asked on

VS2008: Service MSI causing "Access is Denied" errors when coupled with ClickOnce

I have a service I wrote using VS2005.  It also used ClickOnce (CO) as a deployment agent so I can simply publish my changes and the service will fetch the latest code on a periodic basis.  The MSI is setup to install as a "User" and prompts me correctly for the username/password account to run the service under.  I have been using this combination for about 5 months now.

Fast forward:  I'm trying to migrate the solution to VS2008.  I have currently left all projects to be targeted at the .NET Framework 2.0 version (trying to migrate one thing at a time).  I can build all my projects without modification of my source.  I did change references as I'm no longer referencing the projects for my dependencies, but rather their release versioned DLLs.

In VS2008, the MSI builds and I can walk through the installer, but immediately after I enter the administrator username/password I get the following error:

Error 1001.  Access to the path '(my network publish share)' is denied.

Now, I build in VS2005 and I don't get this error at all (on the same machine).  I've tried different user accounts during the setup (including our domain administrator account) but to no avail.  Any help would be appreciated.
Avatar of grsychckn


Ok, I managed to do some more testing and found that when I run Filemon the Access Denied error reveals some things that might be of some help.  First, the Access Denied result passed back from the msiexec.exe for the CO publish location says "NT_AUTHORITY\SYSTEM" in the "other" column.  It is my guess that I'm somehow getting the Access Denied because instead of using either my domain credentials or my impersonated Admin credentials, it's using the local system account to try to reach out to the shared publish directory.  Fast forward, below is the code I use in the derived ServiceProcessInstaller class.  If you can find anything questionable about this code, let me know because I can't seem to find anything abnormal with what's being done.

Remember, this is the exact same code that's working using VS2005.
public override void Install(IDictionary stateSaver)
  string username = base.Username;
  string directoryName = Path.GetDirectoryName(username);
  username = Path.GetFileName(username);
  if (directoryName == ".")
    directoryName = Environment.MachineName;
    base.Username = Path.Combine(directoryName, username);
  string clickOnceStartupUrl = this.ClickOnceStartupUrl;
  if (!string.IsNullOrEmpty(clickOnceStartupUrl))
    string password = base.Password;
    InstallStatePropertyWrapper wrapper = new InstallStatePropertyWrapper(stateSaver);
    wrapper.Password = password;
    wrapper.Username = base.Username;
    wrapper.ProductName = ReadProductNameFromApplicationFile(clickOnceStartupUrl);
    wrapper.ClickOnceStartupUrl = clickOnceStartupUrl;
    ProcessStartInfo startInfo = new ProcessStartInfo("rundll32.exe");
    startInfo.Arguments = "dfshim.dll,ShOpenVerbApplication " + clickOnceStartupUrl;
    startInfo.UserName = username;
    startInfo.Domain = directoryName;
    startInfo.Password = this.ToSecureString(password);
    startInfo.CreateNoWindow = true;
    startInfo.UseShellExecute = false;
    startInfo.LoadUserProfile = true;
    using (Process process = Process.Start(startInfo))

Open in new window

Avatar of grsychckn

Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
I've found that the VS2005 build of my MSI appears to startup only one instance of msiexec.exe and that instance is running under my current credentials.

VS2008 however, creates two msiexec.exe instances each of which are running under my current user credentials, but when it comes time for the username and password dialog to appear, a third instance of the msiexec.exe is created and runs under SYSTEM.  I always appear to have one instance of the msiexec.exe running under SYSTEM, so this is a second - new msiexec.exe that appears and runs under SYSTEM.  This only happens when the username/password dialog pops up and the ClickOnce .application file is attempted to execute following our impersonation code.

It is my belief that this third msiexec.exe shouldn't appear and that at the very least should be running under the current user's credentials.  This leads to impersonation failing because when the call is made for my .application file to execute, it tries to authenticate as the most restrictive credential in the chain which is the local system account (from the SYSTEM msiexec.exe instance).  I sure wish I could fix this because my development is all but stopped due to this problem.