Updating a package with a Windows service resets the service account and password

I had a phone call with FireGiant about this problem and we came up with a solution.

Background:

• When installing our application, MSI first installs Windows Service using LocalService
  
  , however, our real desktop software changes it to NetworkService
  
  or even a custom user account, which may be necessary in certain network environments.

• Our element <Component> <ServiceInstall>
  
  had Account="NT AUTHORITY\LocalService"
  
  and looked like this:

  <Component Id="Comp_File_OurServiceExe" Guid="*">
  
      <File Source="$(var.TargetDir)OurService.exe" id="File_OurServiceExe" KeyPath="yes" />
  
      <ServiceInstall
          Id           = "ServiceInstall_OurServiceExe"
          Vital        = "yes"
  
          Name         = "RussianSpyingService"
          DisplayName  = "Russian Spying Service"
          Description  = "Crawls your network for incriminating files to send to the FSB"
          Account      = "NT AUTHORITY\LocalService"
          Type         = "ownProcess"
          Arguments    = "-mode service"
          Interactive  = "no"
          Start        = "auto"
          ErrorControl = "normal"
      >
  
          <ServiceConfig DelayedAutoStart="yes" OnInstall="yes" OnUninstall="no"  OnReinstall="yes" />
          <util:ServiceConfig FirstFailureActionType="restart" SecondFailureActionType="restart" ThirdFailureActionType="none" ResetPeriodInDays="1" />
      </ServiceInstall>
  </Component>
  
        
  
          
          
          
        
  
      

• Performing these repeated steps will unintentionally reset the service registration / configuration:

  1. Complete the installation using MSI version 1.0.0
  2. Open Services.msc
     
     and change RussianSpyingService
     
     to use NT AUTHORITY\NetworkService
     
     (instead of NT AUTHORITY\LocalService
     
     )
  3. Create a new MSI using the same files *.wxs
     
     but with higher file versions and give it a higher version like 1.0.1 (remember MSI only uses the first 3 components of the version number and ignores the 4th version)
  4. After completing this installation, make sure it has RussianSpyingService
     
     been reset for use NT AUTHORITY\LocalService
     
     .

Also, I asked FireGiant (their consultants previously worked at Microsoft and helped other company teams use MSI) who other software, such as SQL Server, can use MSI to install Windows services that work fine despite configuration changes between updates- They told me that products like SQL Server often use custom actions to configure a Windows service, and despite the general advice to avoid custom actions, it is acceptable because the SQL Server team at Microsoft is large enough to allocate resources for development and testing to make them work.

Decision

• In short: "Use MSI properties!"
• Specifically, define the MSI property that represents the attribute value Account
  
  , and load that value from the registry at MSI startup time, and if no value is present, use the default NT AUTHORITY\LocalService
  
  .
• Ideally, the property value should be stored in its own application registry key, and the application should ensure that this value matches the current service configuration.
  • This can be done by creating a new registry key in HKLM
    
    which allows LocalService
    
    or NetworkService
    
    (or any other service account) to write to it, so when the service starts, it writes the name of its user account there. - But it is difficult.
  • Don't use HKCU
    
    values ​​for storing because that won't work: HKCU
    
    Allows completely different registry hives (which may not even be loaded or accessible) for different users.
• The other option is not technically supported by Microsoft because it uses its own services
  
  Windows registry key value ObjectName
  
  (account name), which is usually in the same format that the attribute uses AccountName=""
  
  . This is also the most pragmatic, and this is what is described below:

Here's what worked for us:

1. In your element <Wix> ... <Product>...
   
   add this declaration <Property>
   
   and element <RegistrySearch />
   
   :

   <?xml version="1.0" encoding="UTF-8"?>
   <Wix
       xmlns       = "http://schemas.microsoft.com/wix/2006/wi"
       xmlns:netfx = "http://schemas.microsoft.com/wix/NetFxExtension"
       xmlns:util  = "http://schemas.microsoft.com/wix/UtilExtension"
   >
   
       <Product
           Id="*"
           UpgradeCode="{your_const_GUID}"
           otherAttributes="goHere"
       >
   
           <!-- [...] -->
   
           <Property Id="SERVICE_ACCOUNT_NAME" Value="NT AUTHORITY\LocalService">
               <!-- Properties used in <RegistrySearch /> must be public (ALL_UPPERCASE), not private (AT_LEAST_1_lowercase_CHARACTER) -->
               <RegistrySearch Id="DetermineExistingServiceAccountName" Type="raw" Root="HKLM" Key="SYSTEM\CurrentControlSet\Services\RussianSpyingService" Name="ObjectName" />
           </Property>
   
           <!-- [...] -->
   
       </Product>
   </Wix>
   
         
   
           
           
           
         
   
       

2. Update the item <ServiceInstall
   
   to use the new MSI property SERVICE_ACCOUNT_NAME
   
   for Account=""
   
   instead of the previous hardcoded one NT AUTHORITY\LocalService
   
   :

   <ServiceInstall
       Id           = "ServiceInstall_OurServiceExe"
       Vital        = "yes"
   
       Name         = "RussianSpyingService"
       DisplayName  = "Russian Spying Service"
       Description  = "Crawls your network for incriminating files to send to the FSB"
       Account      = "[SERVICE_ACCOUNT_NAME]"
       Type         = "ownProcess"
       Arguments    = "-mode service"
       Interactive  = "no"
       Start        = "auto"
       ErrorControl = "normal"
   >
   
       <ServiceConfig DelayedAutoStart="yes" OnInstall="yes" OnUninstall="no"  OnReinstall="yes" />
       <util:ServiceConfig FirstFailureActionType="restart" SecondFailureActionType="restart" ThirdFailureActionType="none" ResetPeriodInDays="1" />
   
   </ServiceInstall>
   
         
   
           
           
           
         
   
       

3. Build and run Setup, run the update script, and you will see that the account username of any configured service will persist between update installations.

You can generalize this approach to other properties as well.

Denial of responsibility:

• Microsoft does not officially endorse user-space programs that directly interact with a registry key HKLM\SYSTEM\CurrentControlSet\Services\
  
  . All operations in Windows Services are designed to execute the documented and supported Win32 Service Control Manager API: https://docs.microsoft.com/en-us/windows/desktop/services/service-control-manager
  • This means that Microsoft can, at its discretion, change the configuration of the Windows service so that it no longer uses the key HKLM\SYSTEM\CurrentControlSet\Services\
    
    .
  • (This can break a lot of third-party software; if Microsoft did, they would probably add some sort of virtualization or remapping system to it, as they do with SysWow6432Node
    
    ).
• I've only tested with LocalService
  
  and NetworkService
  
  . I haven't seen what happens if you change the service configuration to use a custom user account after installation before running the update. I expect it to preserve the configuration in this case as well, as it will perform string comparison for the value ObjectName
  
  in SCM and it has no access to passwords.