As discussed in the last post, you can run both 32-bit and 64-bit app pools side-by-side on Windows Server 2008.  I decided I didn't want to have to remember to change the settings on one of my app pools every time I install my application on x64, so I added a custom action to the installer to do it for me. 

Assuming you have already added the correct elements to create your application pool, all you need to do is add a custom action, like so:

   1: <InstallExecuteSequence>

   2:     <RemoveExistingProducts After="InstallFinalize" />

   3:     <Custom Action="ConfigureAppPools" After="InstallFinalize"><![CDATA[NOT Installed AND VersionNT64 >= 600]]></Custom>

   4: </InstallExecuteSequence>

   5: <!-- SNIP -->

   6:  

   7: <CustomAction Id="ConfigureAppPools" Return="check" Directory="TARGETDIR" ExeCommand="[SystemFolder]inetsrv\appcmd set apppool /apppool.name:&quot;Your App Pool Name&quot; /enable32BitAppOnWin64:true" />

The magic is performed by appcmd.exe.  You just tell it the name (not the WiX ID!) of your app pool, the property you want to set, and the value, and it does the rest.  Sadly this only works on IIS 7/Windows Server 2008, but the technique can be used to do all kinds of crazy things to your IIS configuration.  Check out the documentation for appcmd.exe to see what other wonderful things you can come up with.

It looks like "upgrading" our installers to work on Windows Server 2008 wasn't as painful as I expected, at least not once I figured out some of the core issues.  This post summarizes some of the lessons learned.

Install IIS 6.0 Management Capability Feature

Out of the box, WiX can't talk to IIS 7, so any extensions you use for IIS-related tasks won't work.  You can get around the issue by installing a compatibility layer over IIS 7.  Details here.

Built-in Accounts Have Changed

In Windows Server 2003, the Internet guest account is "IUSR_[MachineName]".  All anonymous activity in IIS runs as this user.  In Windows Server 2008, this user has been removed and is instead replaced by the group "IIS_IUSRS".  This means you have to do some trickery with your installation if you want to grant the Internet guest account access to your installed web application in a cross-platform manner.  Details here.

In addition, the ASPNET user, which was unused by still there in Windows Server 2003, has been completely removed in Windows Server 2008.  If your installer must work with even older versions of Windows, you will need to use a similar condition-based technique to find the correct user based on the installation environment.

Double-check your conditions!

Sadly I spent a couple of hours trying to figure out why a particular feature was always disabled in Windows Server 2008.  It turns out that the feature had the condition "VersionNT = 502", so it was only installable on Windows Server 2003.  A quick change to "VersionNT >= 502" fixed that.

When it all goes wrong, msiexec is your friend.

I ran into a lot of problems while trying to get these installers working, but fortunately msiexec can generate some fairly useful logging information.  To do so, run your installer using "msiexec /Log log.txt /i YourInstaller.msi".  If anything goes wrong, the log will give you details.  It isn't always the most straight-forward thing to debug, but it is much better than flying in the dark with the "helpful" errors MSI gives you by default.  In particular, I recommend looking at the "ADDLOCAL" property to verify that the features you think are being installed are actually being installed.  The log also contains the values of all properties and entries indicating which custom actions executed. 

(Whoa, my goal was to hit three posts by the end of the week, but I've already hit three today!  Now taking bets on how long until I get bored...)

A fair bit of my days involve some sort of agonizing over WiX.  That's because I maintain the installers for my employer's product, which is broken up into three separate logical tiers.  Each tier has its own installer, and none of them are simple.  Two of them involve installing web applications, and the third installs/updates SQL Server databases and installs SQL CLR modules.  As I may have hinted at in previous posts, WiX is terribly painful (but powerful).  It's like one of my "friends" said as he left me to manage this WiX nightmare: "With great power comes great pain in the @$$". 

Anyway, since I'm having to rework a fair bit of the installers to get them to work on both Windows Server 2003 and 2008 at the same time, I'll try to throw up any useful snippets that I divine.  First up: installing a task that will run whether the current user is logged in or not:

   1:  <CustomAction Id="CreateScheduledTask" Return="check" Directory="Scripts" 

   2:  ExeCommand=""[SystemFolder]SCHTASKS.EXE" /CREATE /SC DAILY

   3:   /TN "Run Scheduled Queries" /ST 00:00:00 /SD 01/27/2006 /TR 

   4:  .\InvokeQueryScheduler.vbs /RU [%USERDOMAIN]\[LogonUser] /RP" />

So the magic is in invoking "schtasks.exe".  That's not really anything special, but on Win 2k8, you have to specify the "/RU" flag, or the task won't run unless the user performing the install is logged on.  If the target server is on a domain, you have to include the domain prefix, which you can get with "[%USERDOMAIN]".  The "[%...]" property allows you to reference an environment variable (in this case, USERDOMAIN, which holds the domain of the current user). 

At this point, I now have one of three installers working correctly on both Windows Server 2003 and Windows Server 2008.  Sadly it is also the most trivial of the installers, so look for more "WiX Snippet" posts as things progress.

In my previous post, I discussed how I was having difficulty getting a WiX-built MSI installer to correctly assign permissions for the Internet guest account to a folder on both Windows Server 2003 and Windows Server 2008.  The thing about WiX/MSI is that if you keep hammering at it long enough, you can usually find a solution (even if it is ugly and convoluted).  That proved true again today (for better or for worse).

My solution uses two properties (one to store the account name, the other the domain), and two sets of custom actions to correctly populate the properties based on the OS version.  Here is the relevant bits of code:

   1:  <Property Id="WEBUSER" Value="Byah" />

   2:  <Property Id="WEBDOMAIN" Value="Byah" />

   3:  <CustomAction Id="SetWebuserIIS7" Return="check" Property="WEBUSER" Value="IIS_IUSRS" />

   4:  <CustomAction Id="SetWebuserIIS6" Return="check" Property="WEBUSER" Value="IUSR_[ComputerName]" />

   5:  <CustomAction Id="SetDomainIIS7" Return="check" Property="WEBDOMAIN" Value="" />

   6:  <CustomAction Id="SetDomainIIS6" Return="check" Property="WEBDOMAIN" Value="[ComputerName]" />

   7:  <!-- SNIP -->

   8:  <CreateFolder>

   9:      <util:PermissionEx User="NetworkService" GenericAll="yes"  />

  10:      <util:PermissionEx User="Administrators" GenericAll="yes"/>

  11:      <util:PermissionEx User="Users" GenericRead="yes" GenericExecute="yes"  />

  12:      <util:PermissionEx User="[WEBUSER]" Domain="[WEBDOMAIN]" GenericRead="yes" GenericExecute="yes"/>

  13:  </CreateFolder>

For the past couple of days, I've been trying to upgrade a "simple" WiX installer to work with Windows Server 2008 (note that the installer works fine on Windows Server 2003).  This has proven to be an exercise in PAIN, and here's why.

What's changed?

Well, lots.  First, IIS was completely rewritten between Windows Server 2003 and Windows Server 2008.  Out of the box, WiX cannot perform any tasks on IIS 7; you have to enable the legacy IIS 6 metabase stuff first.  That's easy enough to do, just follow the steps listed here.

That's just the tip of the iceberg though.  In addition, IIS 7 anonymous users run under the "IIS_IUSRS" *group*, not the "IUSR_[ComputerName]" account like they did in IIS 6.  This is where I'm currently stuck.  WiX-baked MSI installers "gracefully" explode if you try to assign permissions to a user/group that doesn't exist, so you have to do some sort of conditional install.  I first tried storing the account name in a property, but if it is a Windows Server 2003 machine on a domain, you have to specify "[ComputerName]" as the domain, like so:

<util:PermissionEx User="IUSR_[ComputerName]" 

Domain="[ComputerName]" GenericRead="yes" GenericExecute="yes"/>

However, on Windows Server 2008, the installer explodes if you specify a domain.  So, properties are out.  I next turned to conditional installation.

I created two components, one for each PermissionEx entry, and placed them into two different features.  I gave each feature a condition that should enable/disable the feature correctly based on the OS version:

   1:  <Feature Id="Iis7" Title="IIS 7 Stuff" Level="0">

   2:      <Condition Level="1"><![CDATA[NOT Installed AND VersionNT = 600]]></Condition>

   3:      <ComponentRef Id="Iis7Permissions"/>

   4:  </Feature>

   5:   

   6:  <Feature Id="Iis6" Title="IIS 6 Stuff" Level="0">

   7:      <Condition Level="1"><![CDATA[NOT Installed AND VersionNT <> 600]]></Condition>

   8:      <ComponentRef Id="Iis6Permissions"/>

   9:  </Feature>

Sadly though, this doesn't work either.  As near as I can tell, the features are enabled/disabled correctly, and it even works fine on Windows Server 2003, but on Windows Server 2003, the Iis6Permissions are installed no matter what I do. 

So, if you found this post looking for answers, I'm sorry, but at this time I have none.  I've never been all that impressed with WiX.  It's built on top of MSI, which near as I can tell is a convoluted mess, so it isn't like there was a lot to work with I suppose.  Instead, I'm looking at perhaps using PowerShell or something to automate our deployments... but wait!  The IIS extensions for PowerShell only work on Windows Server 2008!  Stay tuned for more tales of things that Do Not Work!

UPDATE: Check out my latest post for my solution.