0
votes

I have a WIX installer which creates an app pool as follows, using ApplicationPoolIdentity as a default identity.

<Component Id="MyConsoleAppPool" Guid="{my_guid_here}" KeyPath="yes" NeverOverwrite="yes" Win64="yes">
<iis:WebAppPool Id="MyAppPool"
                Name="My Web Console" 
                ManagedPipelineMode="Integrated"
                ManagedRuntimeVersion="v4.0" />
</Component>

Some of our customers choose to change the application pool user to a different (custom) IIS user after installation.

On upgrades, their app pool user is being reset to the default of ApplicationPoolIdentity. This is causing them headaches to deal with on every upgrade.

Is there a way of preserving the existing app pool user, ideally without requiring the user password to be re-entered? We would like this to occur silently during the upgrades.

Note: We have a helper library in C# which can be called via CustomAction if any supporting code is needed there.

1

1 Answers

0
votes

The reason the app pool was being reset is that, since it was a component created internally from the installer, it would be fully removed and re-installed on upgrades.

Rather than build the app pool in the "iis:WebAppPool" element, I decided simply to reference the app pool as follows, outside of any WIX component:

<Fragment>
    <iis:WebAppPool Id="MyAppPool" Name="My Web Console"/>
</Fragment>

Then I created the following custom actions to handle the app pool create/remove:

<CustomAction Id="CreateIISAppPool"
                  Directory="TARGETDIR"
                  ExeCommand="[SystemFolder]inetsrv\appcmd add apppool /name:&quot;My Web Console&quot; /managedRuntimeVersion:&quot;v4.0&quot; /managedPipelineMode:&quot;Integrated"
                  Execute="deferred"
                  Return="ignore"
                  Impersonate="no" />

<CustomAction Id="DeleteIISAppPool"
                  Directory="TARGETDIR"
                  ExeCommand="[SystemFolder]inetsrv\appcmd delete apppool &quot;My Web Console&quot;"
                  Execute="deferred"
                  Return="ignore"
                  Impersonate="no" />

And the sequencing, which states that the app pool is not touched on any upgrade scenarios:

<InstallExecuteSequence>
      <Custom Action="DeleteIISAppPool" Before="CreateIISAppPool">(NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")</Custom>
      <Custom Action="CreateIISAppPool" Before="InstallFiles">(NOT UPGRADINGPRODUCTCODE) AND (NOT Installed) AND (NOT REMOVE="ALL")</Custom> 
      <!-- continue with rest of custom actions here -->
</InstallExecuteSequence>     

Note: This solution does not account for a user deleting their app pool manually (by mistake or otherwise). They will need to uninstall their current version and re-install to recreate the app pool. This can be resolved by adding another custom action to look for the app pool, and if it doesn't find it, install it on an upgrade with the UPGRADINGPRODUCTCODE condition.