Home
About
Contact
Monday, August 16, 2010

In Part 1 I hadn’t decided if I was going to use Web Deploy as the base of this blog series or the PowerShell scripts I already had in production. I decided to give Web Deploy a chance. In the end I didn’t regret it, but I must admit it was not straight forward. Hopefully this post will make it a breeze for you :-)

Web Deploy With VS 2010 and TFS 2010

VS 2010 and TFS 2010 now comes with Web Deploy integration and works great for low to medium complex web apps. When I tried it out with my requirements I did not manage to get my solution to work so I reverted back to the command line version.

The documentation for this topic is also sparse, and it looks/feels unfinished. Here’s some resources if you’re going down that road:

The Web Deploy MSBuild schema: C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web

The official doc: http://msdn.microsoft.com/en-us/library/dd394698.aspx

Web Deploy @PDC: http://www.microsoftpdc.com/2009/FT56

FAQ: http://blogs.msdn.com/b/aspnetue/archive/2010/03/05/automated-deployment-in-asp-net-4-frequently-asked-questions.aspx

MSBuild Web Deploy arguments + more resources: http://weblogs.asp.net/jdanforth/archive/2010/04/24/package-and-publish-web-sites-with-tfs-2010-build-server.aspx

THE commands

The two commands below solves all the requirements I listed in my previous post. I spent a great deal of time learning and studying Web Deploy in order to come up with this, so I hope you find it useful. It might not look too hard now, but nothing is when you have the solution in front of you :-) I’m always open for better ways if you find one though. If I could ask the Web Deploy team for a new feature, it would be to make the two commands below really simple.

The rest of this post will discuss these commands in detail. Text in blue can be replaced with your own values.

Create package:

msdeploy.exe 
	-verb:sync 
	-source:manifest=PackageManifest.xml
	-dest:package=Package.zip,encryptPassword="certificatePassword" 
	-enableLink:AppPoolExtension
	-disableLink:CertificateExtension 
	-disableLink:ContentExtension 
	-replace:objectName=httpCert,targetAttributeName=hash,replace=08bf3e051bd10cd8d89ac1a3ac431887886ed343
	-replace:objectName=logFile,targetAttributeName=directory,replace=C:\Web\Logs 
	-replace:objectName=virtualDirectory,targetAttributeName=physicalPath,match="C:\\WebDeployTemplateWebSites",replace="C:\Web" 
	-declareParam:name=HttpsBinding,kind=DestinationBinding,scope=webSiteName,match=.*:443: 
	-declareParam:name=HttpBinding,kind=DestinationBinding,scope=webSiteName,match=.*:80:
	-declareParam:name=AppPoolUsername,kind=DeploymentObjectAttribute,scope=processModel,match=processModel/@userName 
	-declareParam:name=AppPoolPassword,kind=DeploymentObjectAttribute,scope=processModel,match=processModel/@password

Install package:

msdeploy.exe 
	-verb:sync 
	-source:package=Package.zip,encryptPassword="certificatePassword" 
	-dest:manifest=InstallManifest.xml,computerName=FQDN,username="domain\user",password="domainUserPassword" 
	-setParam:name=HttpsBinding,value=10.0.0.21:443: 
	-setParam:name=HttpBinding,value=10.0.0.21:80:
	-setParam:name=AppPoolUsername,value=MyDomain\AppPoolServiceAccount
	-setParam:name=AppPoolPassword,value=MySecureAppPoolPassword

Note that the above commands are one-liners. I only structured them the way I did to make them readable.

Complex

Web Deploy was built for the purpose of deploying web applications, so at first it looked like the perfect solution. However, I soon realized I had to study it in great detail to make it do what I wanted. I’m talking days not hours. Time I was not eager to spend to replace something already working or just for the sake of this blog post (sorry guys :-)). The reason for not giving up on it entirely was because Web Deploy had the potential to simplify/replace my scripts, have fewer moving parts, and make the total solution easier to maintain.

Around the same time as I published Part 1 I tweeted my concern about Web Deploy’s complexity and the @wdeploy team contacted me. I sent them a long email describing my concerns and they promised to do “creative things in the future” to make it less complex. I’ve been in contact several times after that and they are very responsive and eager to get feedback on the product. I’m personally looking forward to see (and maybe help influence) how this product will evolve.

Web Deploy Command Options

Before diving into the inner workings of these commands, we need to know a bit more about the tool. Web Deploy have a lot of functionality and is extremely powerful. Here’s the command line syntax:

	msdeploy.exe -verb:<verbName>
	-source:<provider>[=<pathToProviderObject>
		[,<providerSetting>=<providerSettingValue>]]
	[-dest:<provider>[=<pathToProviderObject>
        	         [,<providerSetting>=<providerSettingValue>]]
	]
	[-<MSDeployOperationSetting> ...]

Doesn’t look too scary right? There is more to it though…

Verbs
The following verbs exist:

  • delete
  • dump
  • getDependencies
  • getParameters
  • getSystemInfo
  • sync

Providers
Let’s look at which providers it has:

These are of course only the built-in providers, then you can create your own or use 3rd party ones if you like. A quick scan through this list shows that it does a lot more that just web stuff, like COM objects, registry settings, certificates, gac, databases.. the lot.

Provider Settings
The providers again have a set of common provider settings:

  • authType
  • computerName
  • encryptPassword
  • getCredentials
  • ignoreErrors
  • includeAcls
  • password
  • storeCredentials
  • tempAgent
  • userName
  • wmsvc

MSDeployOperationSetting
From the documentation:

Web Deploy operation settings are non-provider specific command-line flags. They modify all of a Web Deploy operation.

  • allowUntrusted
  • declareParam
  • declareParamFile
  • dest
  • disableLink
  • disableRule
  • disableSkipDirective
  • enableLink
  • enableRule
  • enableSkipDirective
  • postSync
  • preSync
  • removeParam
  • replace
  • retryAttempts
  • retryInterval
  • setParam
  • setParamFile
  • showSecure
  • skip
  • source
  • useCheckSum
  • verb
  • verbose
  • whatif
  • xml
  • xpath

Manifest Provider
We now have an overview of the command line syntax of the tool, but there are a few other important aspects. The first one being the manifest provider. Most likely you want to use more than one provider in your command, and that’s exactly what this provider does. Here’s an example from the documentation:

<sitemanifest>
   <appHostConfig path="mySite" />
   <gacAssembly path="System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
   <comObject path="Microsoft.ApplicationHost.AdminManager" />
   <contentPath path="c:\source" />
   <regKey path="HKLM\Software\ODBC" />
</sitemanifest>

I would actually preferred having these on the command line instead. When I trigger my commands from a build, I’m inserting variables into the command anyways and I would be better of with the ONE command and not have to maintain the xml files as well. Actually I would like to have both options. In the command I would suggest something like this (which would adhere to the existing conventions):

-source:appHostConfig=mySite,gacAssembly=System.Web…,[…]=[…]

Link Extensions
Another one is the concept of link extensions, which can be enabled/disabled by using the enableLink and disableLink operations. One example drawn from the documentation is:

…if you specify -disableLink:ContentExtension on the command line, you can prevent content from being included in a sync operation. This enables you to synchronize two Web servers without moving any content.

Web Deploy Rules
Web Deploy rules exists to disable or enable built-in or custom rules (using e.g. the enableRule and disableRule operations) for the sync verb. This is however (naturally) only true if the isDefault attribute is set to true in the rule definitions. See here to find the built-in rules. By creating the file Msdeploy.exe.configsettings in %program files%\IIS\Microsoft Web Deploy folder, you can add custom rules.

Packages and Archives
From the docs:

The Web Deploy package and archiveDir features let you create a snapshot backup of your Web site or Web server into a .zip file or archive directory. In addition, the parameterization and manifest features let you customize the archive or package that you create. You can then use your package files to deploy Web sites and Web servers to other computers or computer locations.

What’s wrong?

That’s a lot of stuff to consume! In order to effectively use this tool for deployment, you have to learn most of these verbs, providers and operations, figure out how they work and how you can take advantage of them.

This is (in my opinion) what Greg Young have been talking about and expressed in the NDC Magazine article Failure (well worth the read), where the intent is lost in the system and the user is forced to “reverse engineer” it to make sense of it all.

I’m fully aware of the endless amount of user scenarios that exists, and I don’t expect the Web Deploy team to cover them all, but the most common ones would be nice. Like the one I’m showing in this post I would think would be quite common for auto deployment scenarios. The advanced configuration could still be available for the not-so-common scenarios. Instead I’m “forced” to spend a lot of time learning the inner workings of a complicated tool, which in the end create a lot of value. How valuable wouldn’t it be if I didn’t have to invest so much time in learning the tool?

I’m also aware of the new TFS 2010 integration that exists, which simplifies many of these tasks, but that solution lacks documentation and the advanced options are hard to get at.

Setting up Web Deploy for remote access

To be able to access a server remotely, Web Deploy must be given access to the server. Several options are available, but I’ll focus on the Web Deployment Agent Service, which requires administrator privileges to use.

The Agent Service requires Web Deploy to be installed on the target server. You can find the detailed installation instructions here: http://technet.microsoft.com/en-us/library/dd569030(WS.10).aspx

Basic Usage

Let’s look at some vanilla examples for deploying web stuff remotely:

msdeploy
  -verb:sync
  -source:contentpath=c:\data,
  -dest:contentpath=c:\data,
      computerName=Server2,
      username=admin,
      password=pass

This copies your local C:\data directory to the server Server2, and provide a username and password to get access to the remote server. This is done by using the sync verb and the contentpath provider. So we can push files, which is nice cause we don’t have to use FTP, BITS or similar.

Deployment Requirements 

We want to do a lot more than just copy files. Here’s a list extracted from my previous post of what I want to deploy to remote servers:

  • File content
  • Virtual Directories and Applications settings
  • AppPools settings
  • Certificates
  • Bindings
  • Log location settings
  • Virtual Directory file location settings

Packaging structure

My commands can be used to produce one package per web site multiplied by the number of environments you have (e.g. Dev, Test and Prod). So if you have 4 web sites and 3 environments, you create 12 packages.

To better understand why this is, here’s a list of the settings that are specific for each environment and common across all servers in one specific environment:

  • File content
  • SSL Certificate password
  • Certificate hash/thumbprint
  • Web site log directory location
  • Virtual directory root locations

For server specific differences we create the package so that it accepts parameters for:

  • User and password for the service account under which the worker process of the Application Pools runs
  • The https binding (if used)
  • The http binding (if used)

If we did not define the last three parameters, we would have to multiply the packages with the amount of servers in the different environments as well. 4 web sites, 3 environments and 2 servers in each environment = 24 packages. You don’t want to go there…

Another option would be to define all possible changes as parameters, leaving you with only one package. I tried that. I could not figure out how to accomplish all of these using params, so I analyzed what I needed and used a little of both. It works, but could be better.

As an example of the above, a package for the web site blog.torresdal.net could be created for e.g. Dev with these settings:

  • File content = E:\MyBuildOutput\blog.torresdal.net
  • Certificate password = MySecureSSLPassword
  • Certificate hash=08bf3e051bd10cd8d89ac1a3ac431887886ed343
  • Web site log dir = E:\Logs\blog.torresdal.net
  • Virtual Directory locations = E:\Web

…and used these parameters when deploying:

  • Username for AppPool = MyDomain\AppPoolServiceAccount
  • Password for AppPool = MySecureAppPoolPassword
  • Https binding = 10.0.0.21:443:
  • Http binding = 10.0.0.21:80:

Notes on Application Pool

Note on bindings: You have to use either http or https or both. If you want to use hostname you could do: *:80:blog.torresdal.net
Note that host names are not supported on SSL in IIS 7, even though it’s technically possible to do.

Note on the service account for the application pool: On Windows Server 2008, IIS support Application Pool Identities. These are Windows virtual accounts that are assigned to the application pool effectively isolating it from other services. If you want to use these, then you don’t have to declare the parameters for the app pool identities as long as your source is using App Pool Id’s.

Dissecting The Create Package Command

I believe you now have an idea of what the commands above do, but lets pull it apart and describe each piece by itself.

The package manifest file
First we’re going to look at the manifest file which contains all source providers used to create the package:

<sitemanifest>
   <appHostConfig path="blog.torresdal.net" />
   <cert path="my\08bf3e051bd10cd8d89ac1a3ac431887886ed343 " />
   <dirPath path="E:\MyBuildDrop\LatestVersion\Dev\blog.torresdal.net" />
</sitemanifest>

This is the way that Web Deploy allows you to use more than one provider. Here’s a short description of each provider and what it does:

appHostConfig Gets all IIS specific settings from a web site.
cert Gets the certificate with the given thumbprint/hash.
dirPath Gets the content from the given path.

The create Package command
Now lets look at each section of the command:

-verb:sync Tells Web Deploy to do a sync
-source:manifest=PackageManifest.xml Points to the manifest file showed above containing all providers to use as source.
-dest:package=Package.zip,
encryptPassword="certificatePassword"
Use the package provider as destination for creating a package (zip) containing all content and information needed to deploy a package to a server. Since we’re using the cert provider (in the manifest) we need to provide the password to get access to the certificate.
-enableLink:AppPoolExtension I want the application pool to be synced as well.
-disableLink:CertificateExtension The appHostConfig provider include certificate and content by default. I want to control which certificate and what content to include, so I use –disableLink to disable these extensions. That is why I’ve added the cert and dirPath providers in the manifest so that I can be explicit about these.
-disableLink:ContentExtension See previous…
-replace:objectName=httpCert,
targetAttributeName=hash,
replace=08bf3e051bd10cd…
The appHostProvider and the cert provider are unaware of each others actions, so the appHostProvider outputs the thumbprint from the certificate found in IIS. I need to replace the httpCert hash property with the same hash used in the manifest file or else the web site would be bounded to the wrong certificate.
-replace:objectName=logFile,
targetAttributeName=directory,
replace=C:\Web\Logs
I want to replace the IIS log directory to a different path than the IIS I’m exporting from.
-replace:objectName=virtualDirectory,
targetAttributeName=physicalPath,
match="C:\\WebDeployMasterWebSites",
replace="C:\Web"
The web site I’m exporting from reside in C:\WebDeployMasterWebSites\{webSiteName}, and all Virtual Directories are located below this path. I want to control the root path, so I replace it.

Note: This would be a natural candidate for a parameter, but with params you can only replace the complete value, not just part of it.

Here’s a description of the parameter declarations allowing us to pass in params when deployment the package (these are also part of the same command):

-declareParam:name=HttpsBinding,
kind=DestinationBinding,
scope=webSiteName,
match=.*:443:
I want to control the SSL binding for the web site.
-declareParam:name=HttpBinding,
kind=DestinationBinding,
scope=webSiteName,
match=.*:80:
Same as above only for HTTP.
-declareParam:name=AppPoolUsername,
kind=DeploymentObjectAttribute,
scope=processModel,
match=processModel/@userName
I want to set the user name of the account under which the worker process of the Application Pools runs
-declareParam:name=AppPoolPassword,
kind=DeploymentObjectAttribute,
scope=processModel,
match=processModel/@password
Same as above only for the password.

To shorten the above command a tiny bit you can define the parameters in an xml file instead, like this:

<parameters>
   <parameter name="HttpsBinding" description="Web Site Binding for SSL">
      <parameterEntry kind="DestinationBinding" scope="sikker.frende.no" match=".*:443:" />
   </parameter>
   <parameter name="HttpBinding" description="Web Site Binding for http">
      <parameterEntry kind="DestinationBinding" scope="sikker.frende.no" match=".*:443:" />
   </parameter>
   <parameter name="AppPoolUsername" description="Account username for this application pool">
      <parameterEntry kind="DeploymentObjectAttribute" scope="processModel" match="processModel/@userName"/>
   </parameter>
   <parameter name="AppPoolPassword" description="Account password for this application pool">
      <parameterEntry kind="DeploymentObjectAttribute" scope="processModel" match="processModel/@password"/>
   </parameter>
</parameters>

You will then replace the –declareParam operation settings above with this:

-declareParamFile:MyParamFile.xml

However, if you’re going to execute this command from TFS or some other build tool, you’re better off leaving them inside the command. Less moving parts.

Dissecting The Deploy Package Command

We also need a manifest file when installing the package. This is ALMOST identical to the manifest we used when creating the package:

<sitemanifest>
   <appHostConfig path="blog.torresdal.net" />
   <cert path="my\08bf3e051bd10cd8d89ac1a3ac431887886ed343 " />
   <dirPath path="E:\Web" />
</sitemanifest>

The only difference between the two is in the dirPath provider. For the package we used files from E:\MyBuildDrop\LatestVersion\Dev\blog.torresdal.net, but when deploying we PUT files to E:\Web.

The deployment package command
Each section in detail:

-verb:sync Tells Web Deploy to do a sync
-source:package=Package.zip,
encryptPassword="certificatePassword"
Uses the earlier created package as source. Since this package contains a certificate, you need to provide the certificate password in order to get access to it.
-dest:manifest=InstallManifest.xml,
computerName=FQCN,
username="domain\user",
password="domainUserPassword"
Points to the manifest file to use for deployment, and to which server we are deploying to with the username/password.
-setParam:name=HttpsBinding,
value=10.0.0.21:443:
Set the SSL binding for the web site. Using IP 10.0.0.21 on port 443 (SSL).
-setParam:name=HttpBinding,
value=10.0.0.21:80:
Same as above only for HTTP.
-setParam:name=AppPoolUsername,
value=MyDomain\AppPoolServiceAccount
Set the user name for the account under which the worker process of the Application Pools runs
-setParam:name=AppPoolPassword,
value=MySecureAppPoolPassword
Same as above, only for the password

The Build/Deploy Process Using Web Deploy

Here’s the exact same deployment process overview as in my previous post, only now with Web Deploy. As a result the process got two steps shorter :-)

image

What’s Next?

In my next post I’ll either show you how to control the load balancer during deployment or integration with TFS. Both will be covered in the end.

.Net | ASP.NET | Deployment | IIS | Tools | WebDeploy
Monday, August 16, 2010 7:21:00 AM (W. Europe Daylight Time, UTC+02:00)
Thursday, August 05, 2010

Update: Part 2 is now available, covering Web Deploy (a.k.a. msdeploy)

Getting code deployed should be as easy as open up a web site (only taking slightly longer :-)). Devs or IT people should not spend manual labor (with the possibility of mishaps) on getting files from one place to another, making changes to IIS (or whatever you’re using), restarting servers, copy/changing web.config files etc. That’s the job for scripts and automation tools. Not to mention the cost savings of not needing IT people to do deployment. I bet you there’s no one manual step in the process of deployment that cannot be automated. Saying that, you have to consider how many times you deploy per day/week/month or year before going for full automation. However, if you’re serious about being Agile/Lean, you can’t do without a auto deployment scheme.

In the coming blog posts I’ll walk you through the steps I went through to automate our deployment, and hopefully you’ll find it interesting and even suggest improvements.

Overview
Below is an overview of the environments we’re deploying to:

image

One Load Balancer (LB) in each environment, two web servers in Dev and Test, and 3 in Prod. The actual numbers might or might not be true ;-), but that doesn’t really matter. In addition there’s SQL Servers, but I will not cover that here.

Why have a LB in Dev? Reason number one is to catch any possible LB issues in Dev before going to Test and Prod, and have the exact same environment in Dev as in Prod. It’s also useful to try out new stuff, like having the LB do caching etc.

Deployment Frequency
For Dev we auto deploy every night (part of nightly build) and at will during day. For Test, 2-4 times per week and to Prod 1-2 times every 2nd week. That was yesterday! :-) Today we can do it when the sun comes out of the clouds (not often in Bergen), every time I refill my coffee cup or whenever we feel like. The point being: we are no longer constrained by how often we can deploy.

Why All These Environments?
You can read about that here, but for us:

  • Dev is where we try out things without physically hurting users, but still being in a real server environment avoiding the “works on my machine” issue.
  • Test is as close to Prod as we can get (at external hosting provider, different network, firewalls etc) and where we make sure things run smoothly before going to Prod.
  • Prod is Prod

Tech Details
Here’s the tech stuff we use which might be relevant:

  • All servers are running Windows Server 2008 R2
  • Web servers are running on IIS 7.5 (since we’re on R2)
  • Application Request Routing in IIS is used as Load Balancer and runs on 2008 R2 Server Core (if you like, check out my previous post about setting up and configuring ARR)
  • TFS 2010 for builds
  • Team City for CI

Also note that we have access to the actual subnet where Test and Prod lives. This does however not mean we have access to all servers and features in all environments, it just means we can be given access to certain things not recommended through external firewalls, like PowerShell Remoting. This is where your environments might be different from ours.

Some General Advice

Consider Using a LB Even If You Don’t Need One For Performance Reasons
Load Balancers are useful for other things than load balancing. The biggest benefit (except from its core task), is that you can do upgrades and maintenance on servers without taking the whole site offline, by always leaving at least one server online.

Consider Turning Off IIS Recycling
Do you know that IIS automatically recycle your applications every 1740 minute, effectively restarting them? Are your web sites free from memory leaks or do you want to know if you have memory leaks? Why not turn off recycling? This is too big of a topic to cover here, but go Google: IIS7 recycle.

Consider Using Windows Server 2008 R2 Server CORE 
This should get you slightly better performance, but for me it’s more about scripting. Most of the things that needs to be done on server core, must be performed from command line, forcing you to create scripts.

Why Is Deployment Difficult?
First of all because every environment is different and there are no really good tools to automate the whole process. The challenge is to find the right tools to solve the problems your organization is facing, and have the tools work for you to get to the final goal.

What’s The Challenges?
For us it was about:

  1. How can we safely move files from a build server to Dev, Test and Prod?
  2. How can we automate the process of taking a node out of an LB cluster?
  3. How can we safely execute an upgrade on a server in Dev, Test or Prod and get feedback of progress, errors, and abort and roll back on failure?
  4. How can we remotely make changes to IIS?
  5. How can we avoid all manual tasks? (like adding a virtual directory in IIS or copy a web.config file)

Safety and automation is two keywords that sticks out. Where safe means no-one else than the intended persons or services should be able to perform the specified tasks. Automation meaning no manual operations should ever be needed in either Dev, Test or Prod except from IT maintenance like hardware upgrades, windows update etc.

What tool options have we?

Copy files:

  • Secure FTP in IIS 7 on a non public/available IP
  • or PowerShell with BITS
  • or WebDeploy

Taking LB nodes offline/online:

  • Use PowerShell Remoting to execute PowerShell scripts on ARR server
  • or the Web Farm Framework

Safely execute an upgrade:

  • Use PowerShell Remoting to execute PowerShell scripts on web servers
  • or WebDeploy

Avoid manual tasks:

  • Script all tasks, so they can be repeated

The Build/Deploy Process     
image

What About MSI’s?
If you read my blog you know I’ve done quite a bit of MS Installer stuff and WiX in particular. MSI’s are perfect for deploying to multiple places where you have no control. The drawback is that most developers don’t know how to customize MSI’s and often end up with a versioning problem and leaving lots of old stuff behind on the server after upgrades. If you have people skilled in Windows Installer, please feel free to use MSI, but I personally find XCopy to be very easy and is what I recommend if you’re not an ISV. With MSI’s you still have to install them remotely, which could be done with WMI or PowerShell.

Notes on WebDeploy
I’m currently looking at using Web Deploy to simplify/reduce the amount of scripts needed. WebDeploy would replace the FTP and deploy steps, but first impression is that it’s too generic, making it really hard to do simple things without spending quite a bit of time learning the tool, it’s underlying package schema and IIS schemas. Hopefully one day Web Deploy will be the only tool I’ll need to execute the whole deployment process.

What’s Coming?
In future blog posts I’ll walk you through step-by-step how to accomplish the above solution. While I’m writing this I’m not 100% sure if it will be a solution using PowerShell (which I have in production) or a slightly modified version using Web Deploy. It all depends on which one is easiest and which has the potential of being maintained by other people than me in the long run.

Hopefully this will give you the input you need to fully automate your deployment process as well.

Agile | ASP.NET | Deployment | IIS | Lean | Tools
Thursday, August 05, 2010 8:30:29 AM (W. Europe Daylight Time, UTC+02:00)
Monday, February 15, 2010

In part 1 I explained why I needed a load balancer that was capable of doing smart balancing decisions using more than just IPs and why I decided to use IIS7 and Application Request Routing (ARR). In this part I will give a detailed explanation of how to setup ARR on Windows Server 2008 R2 Web Server Core.

Server Core provide the following benefits over traditional installations according to Microsoft:

  • Reduced maintenance
  • Reduced attack surface
  • Reduced management
  • Less disk space required

I concluded that the above points is quite important for a load balancer, as you don’t want it to spend its resources on anything else than load balancing.

In this guide I will walk you through the steps needed to install Windows Server 2008 Web Server Core. Secondly I will show you how to create the necessary scripts to automate about 99% of the installation and configuration of ARR.

Before we dig deep, here’s a short description of the setup I used for my ARR environment:

Two Web Servers with:

  • 3 websites running both SSL and normal HTTP
  • Each website needed its own IP
  • Each website needed its own SSL certificate

ARR Server:

  • In order to avoid the “clients NAT’ed behind one IP” problem, I needed to configure ARR Server Affinity to UseCookie.
  • As for the Load Balancing Algorithm I used Weighted Round Robin (you should look into the other alternatives that suite your needs)
  • The ARR server is responsible for distributing traffic to two web servers mentioned above

All of the above can of course be changed in the scripts that I’ll be showing later to suite your configuration needs. Below is an illustration of the infrastructure:

image

Installing Windows Server 2008 R2 Web Server Core:

  1. Install Windows Server 2008 R2 Web - Server Core
  2. Set password for admin (when prompted)
  3. Rename server:
    NETDOM renamecomputer %computername% /newname:[nameOfServer]
  4. Restart:
    shutdown /r /t 0
  5. Set static IP:
    netsh interface ipv4 set address "Local Area Connection" static [IP] [Subnet] [Gateway]
  6. Set Primary DNS server:
    netsh interface ipv4 add dnsserver "Local Area Connection" [IP]
  7. Set Secondary DNS server:
    netsh interface ipv4 add dnsserver "Local Area Connection" [IP] index=2
  8. If you want the server to join a domain:
    netdom join %computername% /domain:[domainname] /userd:[username] /passwordd:*
  9. Restart:
    shutdown /r /t 0
  10. If you want to enable Remote Desktop:

    For Vista/Win7/2008 clients:
    cscript %windir%\system32\SCRegEdit.wsf /ar 0

    For earlier clients:
    cscript %windir%\system32\SCRegEdit.wsf /cs 0

    For both new and earlier clients run both of the above
  11. If you want to allow remote MMC management (e.g. to simplify managing users etc):
    netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
  12. Activate Windows:
    start /w slmgr.vbs –ipk [key]
    start /w slmgr.vbs –ato

Now the server is ready for ARR installation and configuration, but since the OS is a server core, creating some scripts to automate this procedure is very helpful. Next I will show you the scripts I created and used, which hopefully will make this task easier for you than for me :-) I’ve made all the files and scripts available in this zip file.

Creating script for installing SSL certificates (do this on some client computer, not the ARR Server):

Note: You can skip this section (except step 1 and 2) if you’re not using SSL.

  1. Create a folder called ARRInstall
  2. In the ARRInstall folder, create a new folder called Utils
  3. Download capicom_dc_sdk.msi and place MSI in the Utils folder
  4. Download winhttpcertcfg.msi and install with default options on a client computer
  5. Browse to C:\Program Files (x86)\Windows Resource Kits\Tools\ and copy winhttpcertcfg.exe into your Utils folder
  6. Create a folder called Certificates in your ARRInstall folder
  7. The above folder must contain all your certificates (both with and without private keys). For my setup this looks like this:

    ARRInstall 
      |-- Certificates 
            |-- site1.torresdal.net.cer 
            |-- site1.torresdal.net.pfx 
            |-- site2.torresdal.net.cer 
            |-- site2.torresdal.net.pfx 
            |-- site3.torresdal.net.cer 
            |-- site3.torresdal.net.pfx
  8. Copy the script below, read comments in script and modify accordingly. Then save the script as _SetupCertificates.cmd in the ARRInstall folder:
    @echo off
    
    echo Installing CAPICOM...
    
    echo.
    
    msiexec /qn /i "%~dp0Utils\capicom_dc_sdk.msi"
    
    echo Removing existing certificate from store...
    
    REM Example:
    
    REM certutil -delstore Root "blog.torresdal.net"
    
    certutil -delstore Root "[certificate name]"
    
    echo Removing SSL certificate from IIS...
    
    netsh http delete sslcert ipport=0.0.0.0:443
    
    echo Installing certificates...
    
    echo.
    
    REM Example:
    
    REM certutil -f -addstore Root "%~dp0Certificates\blog.torresdal.net.cer"
    
    certutil -f -addstore Root "%~dp0Certificates\[certificate name].cer"
    
    IF EXIST "%PROGRAMFILES%\Microsoft CAPICOM 2.1.0.2 SDK" (
    
        SET capicompath="%PROGRAMFILES%\Microsoft CAPICOM 2.1.0.2 SDK\Samples\vbs\cstore.vbs"
    
        SET cscript=%windir%\system32\cscript.exe
    
    )
    
    IF EXIST "%PROGRAMFILES(x86)%\Microsoft CAPICOM 2.1.0.2 SDK" (
    
        SET capicompath="%PROGRAMFILES(x86)%\Microsoft CAPICOM 2.1.0.2 SDK\Samples\vbs\cstore.vbs"
    
        SET cscript=%windir%\syswow64\cscript.exe
    
        ECHO Setting up CAPICOM for 64 bits environment...
    
        copy /y "%PROGRAMFILES(x86)%\Microsoft CAPICOM 2.1.0.2 SDK\Lib\X86\capicom.dll" %windir%\syswow64
    
        %windir%\syswow64\regsvr32.exe /s %windir%\syswow64\capicom.dll
    
    )
    
    REM Example:
    
    REM %cscript% /nologo %capicompath% delete -l LM -subject "blog.torresdal.net" -noprompt
    
    %cscript% /nologo %capicompath% delete -l LM -subject "[certificate name]" -noprompt
    
    REM Example:
    
    REM %cscript% /nologo %capicompath% import -l LM "%~dp0Certificates\blog.torresdal.net.pfx" "somePassword"
    
    %cscript% /nologo %capicompath% import -l LM "%~dp0Certificates\[certificate name].pfx" "[password]"
    
    REM Example:
    
    REM "%~dp0Utils\winhttpcertcfg.exe" -g -c LOCAL_MACHINE\My -s blog.torresdal.net -a "IIS_IUSRS"
    
    "%~dp0Utils\winhttpcertcfg.exe" -g -c LOCAL_MACHINE\My -s [certificate name] -a "IIS_IUSRS"
    
    echo.
    
    echo ============================
    
    echo Certificates Setup finished!
    
    echo ============================
    
    REM pause
    
    :end
  9. Your folder structure should now look like this:
    ARRInstall 
      |-- Certificates 
            |-- site1.torresdal.net.cer 
            |-- site1.torresdal.net.pfx 
            |-- site2.torresdal.net.cer 
            |-- site2.torresdal.net.pfx 
            |-- site3.torresdal.net.cer 
            |-- site3.torresdal.net.pfx
      |-- Utils
            |-- capicom_dc_sdk.msi
            |-- winhttpcertcfg.exe
      |-- _SetupCertificates.cmd

Create script for installing and configuring ARR:

  1. Download the x64 installer for ARR from the ARR website: http://www.iis.net/expand/ApplicationRequestRouting
  2. Copy the downloaded file (ARRv2_setup_x64.EXE) into the Utils folder
  3. Download IIS7Util.exe which I’ve made available for you on my site. (The source code can be found at the foaf-ssl-dotnet project. Just browse code and search for “iis7util”, to make it clear where I got it from :-))
  4. Copy the IIS7Util.exe into the Utils folder
  5. Copy the script below, read comments in script and modify accordingly. Then save the script as InstallARR.cmd in the ARRInstall folder. You should then have this file structure:

    ARRInstall 
      |-- Certificates 
            |-- site1.torresdal.net.cer 
            |-- site1.torresdal.net.pfx 
            |-- site2.torresdal.net.cer 
            |-- site2.torresdal.net.pfx 
            |-- site3.torresdal.net.cer 
            |-- site3.torresdal.net.pfx
      |—Utils
            |-- ARRv2_setup_x64.EXE
            |-- capicom_dc_sdk.msi
            |-- IIS7Util.exe
            |-- winhttpcertcfg.exe
      |-- _SetupCertificates.cmd
      |-- InstallARR.cmd

    Note: If you’re not using SSL, comment out this line in your script:
    call %~dp0_SetupCertificates.cmd

    @echo off
    
    REM =====================
    
    REM 	CONFIGURATION
    
    REM =====================
    
    REM =============================================
    
    REM IP's for the different sites on the LB Server
    
    REM =============================================
    
    SET Site1IPNLB=10.0.0.51
    
    SET Site2IPNLB=10.0.0.52
    
    SET Site3IPNLB=10.0.0.53
    
    REM =============================
    
    REM IP's for back end web servers
    
    REM =============================
    
    SET Site1IPWeb01=10.137.13.61
    
    SET Site2IPWeb01=10.137.13.62
    
    SET Site3IPWeb01=10.137.13.63
    
    SET Site1IPWeb02=10.137.13.71
    
    SET Site2IPWeb02=10.137.13.72
    
    SET Site3IPWeb02=10.137.13.73
    
    REM ==============================
    
    REM Host names for different sites
    
    REM ==============================
    
    SET Site1HostName=site1.torresdal.net
    
    SET Site2HostName=site2.torresdal.net
    
    SET Site3HostName=site3.torresdal.net
    
    REM ==================================
    
    REM Name of Server Farms for each site
    
    REM ==================================
    
    SET ARRServerFarm1=Site1
    
    SET ARRServerFarm2=Site2
    
    SET ARRServerFarm3=Site3
    
    REM ============================
    
    REM File locations for web sites
    
    REM ============================
    
    SET Site1FileLoc=C:\%ARRServerFarm1%
    
    SET Site2FileLoc=C:\%ARRServerFarm2%
    
    SET Site3FileLoc=C:\%ARRServerFarm3%
    
    REM ==========
    
    REM AppCmd.exe
    
    REM ==========
    
    SET AppCMD=%windir%\system32\inetsrv\appcmd.exe
    
    REM =========================
    
    REM	INSTALLATION
    
    REM =========================
    
    Echo Installing IIS...
    
    start /w pkgmgr /l:log.etw /iu:IIS-WebServerRole;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI;NetFx2-ServerCore;NetFx2-ServerCore-WOW64;IIS-ManagementService
    
    Echo Enabling remote management of IIS...
    
    reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server /v EnableRemoteManagement /t REG_DWORD /d 1 /f
    
    sc config WMSVC start= auto
    
    Echo Installing Application Request Routing (ARR)...
    
    net stop was /y
    
    net stop wmsvc /y
    
    "%~dp0utils\ARRv2_setup_x64.EXE" /Q
    
    net start was
    
    net start wmsvc
    
    Echo Disable Idle Timeout on Application Pool...
    
    %AppCMD% set apppool "DefaultAppPool" -processModel.idleTimeout:"00:00:00" /commit:apphost
    
    %AppCMD% set config -section:system.applicationHost/applicationPools /[name='DefaultAppPool'].recycling.periodicRestart.time:"00:00:00" /commit:apphost
    
    Echo Installing certificates...
    
    call %~dp0_SetupCertificates.cmd
    
    Echo Adding aditional IPs for web sites...
    
    netsh interface ipv4 add address "Local Area Connection" %Site1IPNLB% 255.255.255.0
    
    netsh interface ipv4 add address "Local Area Connection" %Site2IPNLB% 255.255.255.0
    
    netsh interface ipv4 add address "Local Area Connection" %Site3IPNLB% 255.255.255.0
    
    Echo Creating folders for web sites...
    
    md %Site1FileLoc%
    
    md %Site2FileLoc%
    
    md %Site3FileLoc%
    
    Echo Creating web sites in IIS...
    
    %AppCMD% add site /name:%site1HostName% /bindings:"http/%Site1IPNLB%:80:,https/%Site1IPNLB%:443:" /physicalPath:"%Site1FileLoc%"
    
    %AppCMD% add site /name:%site2HostName% /bindings:"http/%Site2IPNLB%:80:,https/%Site2IPNLB%:443:" /physicalPath:"%Site2FileLoc%"
    
    %AppCMD% add site /name:%site3HostName% /bindings:"http/%Site3IPNLB%:80:,https/%Site3IPNLB%:443:" /physicalPath:"%Site3FileLoc%"
    
    Echo Adding farms and servers to ARR...
    
    %AppCMD% set config  -section:webFarms /+"[name='%ARRServerFarm1%']" /commit:apphost
    
    %AppCMD% set config  -section:webFarms /+"[name='%ARRServerFarm1%'].[address='%Site1IPWeb01%']" /commit:apphost
    
    %AppCMD% set config  -section:webFarms /+"[name='%ARRServerFarm1%'].[address='%Site1IPWeb02%']" /commit:apphost
    
    %AppCMD% set config  -section:webFarms /+"[name='%ARRServerFarm2%']" /commit:apphost
    
    %AppCMD% set config  -section:webFarms /+"[name='%ARRServerFarm2%'].[address='%Site2IPWeb01%']" /commit:apphost
    
    %AppCMD% set config  -section:webFarms /+"[name='%ARRServerFarm2%'].[address='%Site2IPWeb02%']" /commit:apphost
    
    %AppCMD% set config  -section:webFarms /+"[name='%ARRServerFarm3%']" /commit:apphost
    
    %AppCMD% set config  -section:webFarms /+"[name='%ARRServerFarm3%'].[address='%Site3IPWeb01%']" /commit:apphost
    
    %AppCMD% set config  -section:webFarms /+"[name='%ARRServerFarm3%'].[address='%Site3IPWeb02%']" /commit:apphost
    
    REM ==============================================================================
    
    REM ALERT!: REMEMBER THAT SSL RULES FOR EACH SITE MUST BE BEFORE THE HTTP RULES!!!
    
    REM 	    E.g. 1) Rules for Site1 SSL
    
    REM              2) Rules for Site1 HTTP
    
    REM		 3) Rules for Site2 SSL
    
    REM		 4) Rules for Site2 HTTP
    
    REM		 5) etc.
    
    REM
    
    REM	    If we had switched 1 and 2, it would match on HTTP first, and would
    
    REM	    have redirected to a non SSL site, resulting in SSL offloading.
    
    REM
    
    REM	    If SSL offloading is the wanted behaviour, only the HTTP rule is 
    
    REM	    nessesary.
    
    REM ==============================================================================
    
    echo Adding rewriting rules to ARR...
    
    %AppCMD% clear config -section:system.webServer/rewrite/globalRules
    
    REM Site1 SSL
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm1%_SSL', patternSyntax='Wildcard',stopProcessing='True']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm1%_SSL',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*"  /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm1%_SSL',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTPS}',pattern='on']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm1%_SSL',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTP_HOST}',pattern='*%Site1HostName%*']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm1%_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite" /[name='%ARRServerFarm1%_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.url:"https://%ARRServerFarm1%/{R:0}" /commit:apphost
    
    REM Site1 HTTP
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm1%', patternSyntax='Wildcard',stopProcessing='True']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm1%',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*"  /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm1%',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTP_HOST}',pattern='*%Site1HostName%*']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm1%',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite" /[name='%ARRServerFarm1%',patternSyntax='Wildcard',stopProcessing='True'].action.url:"http://%ARRServerFarm1%/{R:0}" /commit:apphost
    
    REM Site2 SSL
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm2%_SSL', patternSyntax='Wildcard',stopProcessing='True']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm2%_SSL',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*"  /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm2%_SSL',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTPS}',pattern='on']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm2%_SSL',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTP_HOST}',pattern='*%Site2HostName%*']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm2%_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite" /[name='%ARRServerFarm2%_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.url:"https://%ARRServerFarm2%/{R:0}" /commit:apphost
    
    REM Site2 HTTP
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm2%', patternSyntax='Wildcard',stopProcessing='True']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm2%',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*"  /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm2%',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTP_HOST}',pattern='*%Site2HostName%*']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm2%',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite" /[name='%ARRServerFarm2%',patternSyntax='Wildcard',stopProcessing='True'].action.url:"http://%ARRServerFarm2%/{R:0}" /commit:apphost
    
    REM Site3 SSL
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm3%_SSL', patternSyntax='Wildcard',stopProcessing='True']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm3%_SSL',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*"  /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm3%_SSL',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTPS}',pattern='on']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm3%_SSL',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTP_HOST}',pattern='*%Site3HostName%*']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm3%_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite" /[name='%ARRServerFarm3%_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.url:"https://%ARRServerFarm3%/{R:0}" /commit:apphost
    
    REM Site3 HTTP
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm3%', patternSyntax='Wildcard',stopProcessing='True']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm3%',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*"  /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /+"[name='%ARRServerFarm3%',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTP_HOST}',pattern='*%Site3HostName%*']" /commit:apphost
    
    %AppCMD% set config  -section:system.webServer/rewrite/globalRules /[name='%ARRServerFarm3%',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite" /[name='%ARRServerFarm3%',patternSyntax='Wildcard',stopProcessing='True'].action.url:"http://%ARRServerFarm3%/{R:0}" /commit:apphost
    
    REM ===============
    
    REM Server Affinity
    
    REM ===============
    
    Echo Adding Server Affinity...
    
    %AppCMD% set config  -section:webFarms /[name='%ARRServerFarm1%'].applicationRequestRouting.affinity.useCookie:"True"  /commit:apphost
    
    %AppCMD% set config  -section:webFarms /[name='%ARRServerFarm2%'].applicationRequestRouting.affinity.useCookie:"True"  /commit:apphost
    
    %AppCMD% set config  -section:webFarms /[name='%ARRServerFarm3%'].applicationRequestRouting.affinity.useCookie:"True"  /commit:apphost
    
    REM ========================
    
    REM Load Balancing Algorithm
    
    REM ========================
    
    Echo Adding Load Balancing Algorithm...
    
    %AppCMD% set config  -section:webFarms /[name='%ARRServerFarm1%'].applicationRequestRouting.loadBalancing.algorithm:"WeightedRoundRobin" /commit:apphost
    
    %AppCMD% set config  -section:webFarms /[name='%ARRServerFarm2%'].applicationRequestRouting.loadBalancing.algorithm:"WeightedRoundRobin" /commit:apphost
    
    %AppCMD% set config  -section:webFarms /[name='%ARRServerFarm3%'].applicationRequestRouting.loadBalancing.algorithm:"WeightedRoundRobin" /commit:apphost

Installing Application Request Routing:

  1. From the ARR server connect to your client containing the script files:
    net use [some drive letter]: \\clientComputerName\[drive on client]$ /user:domain\user
    Example:
    net use r: \\myClient\c$ /user:torresdal\jon
  2. Make a directory on the server to copy the files to:
    E.g.: md c:\temp\arr
  3. Copy the ARRInstall folder from your client to C:\temp\arr on your server
  4. Run InstallARR.bat, watch for errors and wait for it to finish
  5. Install Remote IIS Manger on a PC that will administrate IIS and connect to the ARR server: http://www.iis.net/expand/IISManager
  6. In Internet Information Services Manager connected to ARR do:
    1. Select Sites->Site1
    2. Click Bindings (upper right corner)
    3. Click https –> Edit
    4. Select proper certificate
    5. Repeat for all other sites
  7. Under Sites:
    1. For each site that require SSL:
      1. Click SSL Settings
      2. Check Require SSL
  8. Start IIS on ARR server:
    iisreset /start
  9. Using Internet Information Services Manager:
    Stop “Default Web Site”
  10. You’re done!

I hope this helped in making the installation and configuration of the ARR server easier, and that my scenario is applicable to others except me :-) Let me know if I can help with questions or if you find any errors.

Next time I will talk about how to avoid the ARR server being the Single Point of Failure.

Monday, February 15, 2010 8:00:00 AM (W. Europe Standard Time, UTC+01:00)
Wednesday, February 10, 2010

image A few weeks back I had to solve a performance problem at work. For some of our applications most of our users are NAT’ed behind the same IP, making the default load balancer (NLB) in Windows direct the majority of all traffic to one server. NLB in Windows work on layer 3 (network layer) in the OSI model (that thing you learned at uni), meaning we can only take advantage of IP stuff. So usually you use what’s often called Sticky Sessions (Single Affinity) to keep track of which IP’s got redirected to which server, and keep doing that from that point on for that IP. This was the setup we had.

You can work around that problem by disabling Sticky Sessions, but it might influence performance and could give you unwanted consequences. As an example, if you use ASP.NET Web Forms you will probably run into an issue with ViewState and possibly session issues. For SSL however (which was the case for us), Sticky Session is not recommended.

Other “smarter” load balancers work on layer 7 (application layer), providing us with a much bigger toolbox to inspect traffic and make smarter choices for where to redirect traffic. So I started to look for a load balancer on layer 7. The obvious first choice was hardware LB. This is often the quickest solution, but also the most expensive. I looked at Cisco’s Application Control Engine Module (ACE) and F5 BigIP, but the price was and issue as well as the lack of people with know-how inside our organization of how to configure them.

My next option was setting up a Linux server running Apache and LB, but then I came across a Microsoft module on IIS7: Application Request Routing (ARR). I found some really good documentation and it looked quite easy to set up. Since I (and others in my organization) are used to working with IIS, this seamed to be worth investigating.

In my next post I’ll go trough all the details of setting up ARR on Windows 2008 R2 Server Core. Everything from installing and configuring the OS to automate installation of ARR by scripts.

Wednesday, February 10, 2010 7:00:00 AM (W. Europe Standard Time, UTC+01:00)
Friday, October 24, 2008

This is my fourth post in my WiX and DTF series. Here are some others I’ve written:

Intro

In this article I’ll cover how to allow a user to choose which web site to install an application to by listing available web sites in a list box in the MSI installation wizard. As mention in my previous articles I'm applying best practices (at the best of my knowledge) to have the installer pass the Vista certification, so hopefully that will be the case if you use any of this in production :-)

When doing lookups in IIS using custom actions in the InstallUISequence (as we need to do in order to get available web sites), elevated privileges is required (at least in Vista SP1). This means we need the installation to run as admin. This is also an issue in the WiX extension for IIS as described in this bug report. See my previous article of a workaround for both the UI Sequence part and the bug: Using a bootstrapper to force elevated privileges in Vista

If you did not quite understand what I just said about the sequence stuff, elevated privileges etc., relax and keep reading, you will know by the end of this post and/or by clicking the link above :-)

Overview

This article assume you’ve read my previous article about Using WiX to author MSI installations or that you are somewhat familiar with WiX. If you haven’t done so already and want to follow this article step-by-step, download the WiX project from my previous article here: SimpleWebApp.zip

There is another possibility of course :-) If you’re lazy and just want the complete source for this article, you can download everything from here: SimpleWebApp_WSSelect.zip

Since this article became rather long I’ve structured it into 3 main sections with related sub sections, which hopefully will help you later if you need to look up something:

Now let’s dig into it!

Custom actions

To add a CA to your solution, do this:

  1. Add a new class library project to your solution and name it IISCustomAction
  2. Add a reference to Microsoft.Deployment.WindowsInstaller found in the WiX SDK
  3. Add a reference to System.DirectoryServices
  4. Rename the class created by VS to CustomAction.cs
  5. Add the following using’s to CustomAction.cs:
    1. using System.DirectoryServices;
    2. using Microsoft.Deployment.WindowsInstaller;

When building your project a couple of things happens:

  • The managed dll (IISCustomAction.dll) is created as expected by a class library
  • MakeSfxCA.exe (which is automatically called when building in VS) is creating a new dll based on the managed dll named IISCustomAction.CA.dll (this is the one you need to use in your WiX project)

It’s MakeSfxCA.exe that does all the magic here. The output dll that MakeSfxCA has created is actually a Win32 DLL. Here’s what Christopher Painter says about this:

At runtime, MSI thinks it’s calling a Win32 DLL in it’s own sandbox but in reality the CLR is being fired up out of process and communicated with through a named pipe.

Read the complete article here.

A typical CA looks something like this:

[CustomAction]
public static ActionResult MyCustomAction(Session session)
{
    try
    {
        ...
    }
    catch (Exception ex)
    {
        session.Log("CustomActionException: " + ex.ToString());
        return ActionResult.Failure;
    }
    return ActionResult.Success;
}

The [CustomAction] attribute is needed to tag this method as a CA. The ActionResult returns either (in my case) Failure or Success allowing the installer to respond accordingly. The parameter for this method is a Session object. This object gives me access to the MSI database and the inner workings of Windows Installer allowing me to query the database, access MSI properties etc.

Now you have what you need to start writing CA’s for the Windows Installer, so let’s get cranking.

Custom action – Get web sites
Copy and paste the code below into the CustomAction.cs class in the project you created above:

[CustomAction]
public static ActionResult GetWebSites(Session session)
{
    try
    {
        View listBoxView = session.Database.OpenView("select * from ListBox");
        View availableWSView = session.Database.OpenView("select * from AvailableWebSites");
        DirectoryEntry iisRoot = new DirectoryEntry("IIS://localhost/W3SVC");
        int order = 1;
        foreach (DirectoryEntry webSite in iisRoot.Children)
        {
            if (webSite.SchemaClassName.ToLower() == "iiswebserver" && 
                webSite.Name.ToLower() != "administration web site")
            {
                StoreWebSiteDataInListBoxTable(webSite, order, listBoxView);
                StoreWebSiteDataInAvailableWebSitesTable(webSite, availableWSView);
                order++;
            }
        }
    }
    catch (Exception ex)
    {
        session.Log("CustomActionException: " + ex.ToString());
        return ActionResult.Failure;
    }
    return ActionResult.Success;
}

Here’s what I’ve done in the code above:

  • Open two views to the msi database. One for the ListBox table and one for a custom table which I will cover later called AvailableWebSites.
  • Get the root entry in IIS by using an LDAP query.
  • Iterate every child of the web site to get and store the information I need.

Here’s the code for the two helper methods I use to store the IIS data to the Windows Installer database:

private static void StoreWebSiteDataInListBoxTable(DirectoryEntry webSite, int order, View listBoxView)
{
    Record newListBoxRecord = new Record(4);
    newListBoxRecord[1] = "WEBSITE";
    newListBoxRecord[2] = order;
    newListBoxRecord[3] = webSite.Name;
    newListBoxRecord[4] = webSite.Properties["ServerComment"].Value;
    listBoxView.Modify(ViewModifyMode.InsertTemporary, newListBoxRecord);
}
private static void StoreWebSiteDataInAvailableWebSitesTable(DirectoryEntry webSite, View availableWSView)
{
    //Get Ip, Port and Header from server bindings
    string[] serverBindings = ((string)webSite.Properties["ServerBindings"].Value).Split(':');
    string ip = serverBindings[0];
    string port = serverBindings[1];
    string header = serverBindings[2];
    Record newFoundWebSiteRecord = new Record(5);
    newFoundWebSiteRecord[1] = webSite.Name;
    newFoundWebSiteRecord[2] = webSite.Properties["ServerComment"].Value;
    newFoundWebSiteRecord[3] = port;
    newFoundWebSiteRecord[4] = ip;
    newFoundWebSiteRecord[5] = header;
    availableWSView.Modify(ViewModifyMode.InsertTemporary, newFoundWebSiteRecord);
}

The first method stores data in the ListBox table and the second in my custom AvailableWebSites table.

My custom table (which I’ll explain in more detail later) contains the following columns:

  • WebSiteNo
  • WebSiteDescription
  • WebSitePort
  • WebSiteIP
  • WebSiteHeader

The ListBox table has these four columns:

  • Property
  • Order
  • Value
  • Text

For the ListBox table the Property is used for identifying one specific list box and will allow you to get the Value of the selected item later. The Property must be the same for every record that you want displayed in one single UI list box. Order defines in which order the item are displayed in the list. Value is what’s being returned to you when accessing the property later on. The Text field is what is shown in the UI list box that the end user sees in the MSI wizard.

In my code I set the Property for all records to WEBSITE. The Order is set to 1 the first time and then incremented by 1 every iteration. The Value is set to the web site id and theText is set to the web site name.

After the user have selected the web site we can find out which one by using the WEBSITE property, which will give us the id of the web site (the Value field).

In my custom AvailableWebSites table I store some more details about every web site. But before I can do that I need to get the server bindings from IIS which is formatted like this: ip:port:header. I split these up and add them to to the database. I do the same with WebSiteNo and WebSiteDescription.

In both cases I store the values to the record and update the database (using modify). Note that you have to use InsertTemporary because you’re not allowed to write permanent data to the MSI database during installation.

Custom action – Add selected web site info to properties
After the user have selected a web site in the list box, I call a CA where I store the details about the web site to some public properties. This will make more sense later when we stitch everything together in the WiX product file, but for now here’s the code:

[CustomAction]
public static ActionResult UpdatePropsWithSelectedWebSite(Session session)
{
    try
    {
        string selectedWebSiteId = session["WEBSITE"];
        session.Log("CA: Found web site id: " + selectedWebSiteId);
        View availableWebSitesView = session.Database.OpenView("Select * from AvailableWebSites where WebSiteNo=" + selectedWebSiteId);
        availableWebSitesView.Execute();
        Record record = availableWebSitesView.Fetch();
        if ((record[1].ToString()) == selectedWebSiteId)
        {
            session["WEBSITE_DESCRIPTION"] = (string)record[2];
            session["WEBSITE_PORT"] = (string)record[3];
            session["WEBSITE_IP"] = (string)record[4];
            session["WEBSITE_HEADER"] = (string)record[5];
        }
    }
    catch(Exception ex)
    {
        session.Log("CustomActionException: " + ex.ToString());
        return ActionResult.Failure;
    }
    return ActionResult.Success;
}

Remember the id for the web site that the user selected is stored in the WEBSITE property in the ListBox table? I can get this value by calling session[“WEBSITE”]. I then query my custom table that I populated earlier for details about this web site using Select with the id of the web site in the where clause. I then store these values to the properties: WEBSITE_DESCRIPTION, WEBSITE_PORT, WEBSITE_IP and WEBSITE_HEADER. These properties and where they came from will be explained later :-)

Create a new dialog

To have the user see and select from available web sites, we need to create a dialog displaying a list box. Add a new wxs file to your project and name it SelectWebSiteDlg.wxs. Then replace any generated xml with this xml:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Fragment>
    <CustomAction Id="UpdatePropsWithSelectedWebSite" BinaryKey="WebSiteCA" DllEntry="UpdatePropsWithSelectedWebSite" Execute="immediate" Return="check" />
    <Binary Id="WebSiteCA" SourceFile="$(var.SolutionDir)\IISCustomAction\bin\Debug\IISCustomAction.CA.dll" />
  </Fragment>
  <Fragment>
    <UI>
      <Dialog Id="SelectWebSiteDlg" Width="370" Height="270" Title="Select Web Site">
        <Control Id="Next" Type="PushButton" X="236" Y="243" Width="56" Height="17" Default="yes" Text="!(loc.WixUINext)" />
        <Control Id="Back" Type="PushButton" X="180" Y="243" Width="56" Height="17" Text="!(loc.WixUIBack)" />
        <Control Id="Cancel" Type="PushButton" X="304" Y="243" Width="56" Height="17" Cancel="yes" Text="!(loc.WixUICancel)">
          <Publish Event="SpawnDialog" Value="CancelDlg">1</Publish>
        </Control>
        <Control Id="Description" Type="Text" X="25" Y="23" Width="280" Height="15" Transparent="yes" NoPrefix="yes" Text="Please select which web site you want to install to." />
        <Control Id="Title" Type="Text" X="15" Y="6" Width="200" Height="15" Transparent="yes" NoPrefix="yes" Text="Select Web Site" />
        <Control Id="BannerBitmap" Type="Bitmap" X="0" Y="0" Width="370" Height="44" TabSkip="no" Text="!(loc.InstallDirDlgBannerBitmap)" />
        <Control Id="BannerLine" Type="Line" X="0" Y="44" Width="370" Height="0" />
        <Control Id="BottomLine" Type="Line" X="0" Y="234" Width="370" Height="0" />
        <Control Id="SelectWebSiteLabel" Type="Text" X="20" Y="60" Width="290" Height="14" NoPrefix="yes" Text="Select web site:" />
        <Control Id="SelectWebSiteCombo" Type="ListBox" X="20" Y="75" Width="200" Height="150" Property="WEBSITE" Sorted="yes" />
      </Dialog>
    </UI>
  </Fragment>
</Wix>

This xml file is separated into two fragments; one for the CA and one for the actual UI. The CA entry define in which assembly the CA is located and defines an id we can use later when calling the CA. This CA is the one I created previously for updating some properties with IIS data. The reason I’m defining it here is that I can, and it makes sense to group it with the dialog that are using it. Because, as you will see later, we’re going to call this CA after the user have clicked next on this dialog.

The UI section is where the layout of the actual UI components is defined. Most elements are default for any dialog, except SelectWebSiteLabel and SelectWebSiteCombo which is the two controls specific to the web site dialog.

I also need to update MyUI.wxs which controls which and in which order the dialogs are displayed in the wizard. I’ve added the SelectWebSiteDlg between InstallDirDlg and VerifyReadyDlg as shown here:

<Publish Dialog="InstallDirDlg" Control="Next" Event="SetTargetPath" Value="[WIXUI_INSTALLDIR]" Order="1">1</Publish>
<Publish Dialog="InstallDirDlg" Control="Next" Event="DoAction" Value="WixUIValidatePath" Order="2">1</Publish>
<Publish Dialog="InstallDirDlg" Control="Next" Event="SpawnDialog" Value="InvalidDirDlg" Order="3"><![CDATA[WIXUI_INSTALLDIR_VALID<>"1"]]></Publish>
<Publish Dialog="InstallDirDlg" Control="Next" Event="NewDialog" Value="SelectWebSiteDlg" Order="6"><![CDATA[WIXUI_INSTALLDIR_VALID="1"]]></Publish>
<Publish Dialog="InstallDirDlg" Control="ChangeFolder" Property="_BrowseProperty" Value="[WIXUI_INSTALLDIR]" Order="1">1</Publish>
<Publish Dialog="InstallDirDlg" Control="ChangeFolder" Event="SpawnDialog" Value="BrowseDlg" Order="2">1</Publish>
<Publish Dialog="SelectWebSiteDlg" Control="Next" Event="DoAction" Value="UpdatePropsWithSelectedWebSite" Order="1">1</Publish>
<Publish Dialog="SelectWebSiteDlg" Control="Next" Event="NewDialog" Value="VerifyReadyDlg" Order="2">1</Publish>
<Publish Dialog="SelectWebSiteDlg" Control="Back" Event="NewDialog" Value="InstallDirDlg" Order="1">1</Publish>
<Publish Dialog="VerifyReadyDlg" Control="Back" Event="NewDialog" Value="SelectWebSiteDlg" Order="1">NOT Installed</Publish>
<Publish Dialog="VerifyReadyDlg" Control="Back" Event="NewDialog" Value="MaintenanceTypeDlg" Order="2">Installed</Publish>

See that I use DoAction to call the CA I defined earlier? This is how you hook up a CA to the “click event” of a button (or any control for that matter). Not quite as easy as in Win Forms, but it’s still quite logical.

Also note that I’ve changed the Next event for InstallDirDlg and the Back event for VerifyReadyDlg to point to my new dialog. This so the wizard will navigate correctly when the user clicks the next and back buttons.

Changes to Product.wxs (the main WiX file)

Custom Table – Storing web site info
I promised to cover my custom table in more detail later, so here it is. First the code:

<CustomTable Id="AvailableWebSites" >
  <Column Id="WebSiteNo" Category="Identifier" PrimaryKey="yes" Type="int" Width="4" />
  <Column Id="WebSiteDescription" Category="Text" Type="string" PrimaryKey="no"/>
  <Column Id="WebSitePort" Category="Text" Type="string" PrimaryKey="no"/>
  <Column Id="WebSiteIP" Category="Text" Type="string" PrimaryKey="no" Nullable="yes"/>
  <Column Id="WebSiteHeader" Category="Text" Type="string" PrimaryKey="no" Nullable="yes"/>
  <Row>
    <Data Column="WebSiteNo">0</Data>
    <Data Column="WebSiteDescription">Bogus</Data>
    <Data Column="WebSitePort">0</Data>
    <Data Column="WebSiteIP"></Data>
    <Data Column="WebSiteHeader"></Data>
  </Row>
</CustomTable>

When a user have selected the web site to install to, instead of querying IIS for details about the web site (web site number, description, port etc), I can just get it from my AvailableWebSite table. Note that I’ve added some dummy data in the first row. Without this the custom table was not stored to the MSI and I did not find any other way of getting this to work.

Properties: Define, store and retrieve
Earlier I created a CA that stored info about the selected web site into some public properties. Where did these properties come from? Well, they’re defined in the Product.wxs file like this:

<Property Id="WEBSITE_DESCRIPTION">
  <RegistrySearch Id="WebSiteDescription"
          Name="WebSiteDescription"
          Root="HKLM"
          Key="SOFTWARE\torresdal.net\SimpleWebApp\Install"
          Type="raw" />
</Property>
<Property Id="WEBSITE_PORT">
  <RegistrySearch Id="WebSitePort"
          Name="WebSitePort"
          Root="HKLM"
          Key="SOFTWARE\torresdal.net\SimpleWebApp\Install"
          Type="raw" />
</Property>
<Property Id="WEBSITE_IP">
  <RegistrySearch Id="WebSiteIP"
          Name="WebSiteIP"
          Root="HKLM"
          Key="SOFTWARE\torresdal.net\SimpleWebApp\Install"
          Type="raw" />
</Property>
<Property Id="WEBSITE_HEADER">
  <RegistrySearch Id="WebSiteHeader"
          Name="WebSiteHeader"
          Root="HKLM"
          Key="SOFTWARE\torresdal.net\SimpleWebApp\Install"
          Type="raw" />
</Property>

I’ve also defined a registry search within each property. Why? In order to have access to these values during e.g. repair or uninstall we need to store them in the registry for later use. Why? Well, the Windows Installer does not maintain state (except from INSTALLDIR and maybe a few others). Meaning any values or selections a user did during installation is not kept for later use. Since we will need to know which web site the user installed the application to, so we can remove it on uninstall, we need to store the state to the registry. If the application has been installed before, the registry search above get’s these values from the registry and stores them in their respective properties.

But how did they end up in the registry to begin with? I do that by defining a new component like this:

<Component Id="PersistWebSiteValues" Guid="C3DAE2E2-FB49-48ba-ACB0-B2B5B726AE65">
  <RegistryKey Root="HKLM" Key="SOFTWARE\torresdal.net\SimpleWebApp\Install">
    <RegistryValue Name="WebSiteDescription" Type="string" Value="[WEBSITE_DESCRIPTION]"/>
    <RegistryValue Name="WebSitePort" Type="string" Value="[WEBSITE_PORT]"/>
    <RegistryValue Name="WebSiteIP" Type="string" Value="[WEBSITE_IP]"/>
    <RegistryValue Name="WebSiteHeader" Type="string" Value="[WEBSITE_HEADER]"/>
  </RegistryKey>
</Component>

And we need to reference the component under the Feature tag:

<ComponentRef Id="PersistWebSiteValues" />

Registry key’s in WiX require a component, which is good. That means that these keys/values will be added on install and removed on uninstall, saving us manual work. The registry key above is created at SOFTWARE\torresdal.net\SimpleWebApp\Install. The actual values are the properties as you see in the Value attributes. To reference a property just use [MY_PROPERTY]. This comes in handy many times when authoring MSI installations.

Reference CA’s
One of the CA’s (the UpdatePropsWithSelectedWebSite) is actually already referenced in the SelectWebSiteDlg, but we need to reference the GetWebSites CA as well:

<CustomAction Id="GetIISWebSites" BinaryKey="IISCA" DllEntry="GetWebSites" Execute="immediate"  Return="check" />
<Binary Id="IISCA" SourceFile="$(var.SolutionDir)IISCustomAction\bin\Debug\IISCustomAction.CA.dll" />

The CustomAction tag defines a logical entry that we can use later to call this CA by using the id GetIISWebSites. In addition there is a Binary node that tells where WiX can find this CA when build the project. The CustomAction node point to this by using the BynaryKey attribute.

Then we need to make sure it’s being called:

<InstallUISequence>
  <Custom Action="GetIISWebSites" After="CostFinalize" Overridable="yes">NOT Installed</Custom>
</InstallUISequence>

The above code tells the installer to run this CA in the UISequence only when the application is not already installed (defined by the NOT Installed condition).

Change the WebSite standard action
In order for the installer to pick up the properties we’ve set for the selected web site (description, port, ip etc) we need to change the code we had previously:

<iis:WebSite Id='DefaultWebSite' Description='Default Web Site'>
    <iis:WebAddress Id='AllUnassigned' Port='80' />
</iis:WebSite>

To this:

<iis:WebSite Id="SelectedWebSite" Description="[WEBSITE_DESCRIPTION]">
  <iis:WebAddress Id="AllUnassigned" Port="[WEBSITE_PORT]" IP="[WEBSITE_IP]" Header="[WEBSITE_HEADER]" />
</iis:WebSite>

Makes sense right? I’ve also changed the id to SelectedWebSite which is more accurate in this case, meaning you need to update the WebSite reference in WebVirtualDir in the IISAppplication component as well. If you fail to do this the WiX compiler will complain, so you’re in safe hands :-)

The complete Product.wxs
There’s a lot of snippets above, so for your convenience I’ve included the complete code for Product.wxs here so you see everything together:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" xmlns:iis="http://schemas.microsoft.com/wix/IIsExtension">
  <Product Id="77da05c4-1644-4bc3-ac14-c0f721fe31fe" Name="Simple Web App" Language="1033" Version="1.0.0.0" Manufacturer="Jon Torresdal" UpgradeCode="a897ccc5-1c81-47e0-a837-65c07a72a7bc">
    <Package InstallerVersion="400" Compressed="yes" />
    <Media Id="1" Cabinet="WixProject1.cab" EmbedCab="yes" />
    <Property Id="TARGETVDIR" Value="SimpleWebApp"/>
    <Property Id="WEBSITE_DESCRIPTION">
      <RegistrySearch Id="WebSiteDescription"
              Name="WebSiteDescription"
              Root="HKLM"
              Key="SOFTWARE\torresdal.net\SimpleWebApp\Install"
              Type="raw" />
    </Property>
    <Property Id="WEBSITE_PORT">
      <RegistrySearch Id="WebSitePort"
              Name="WebSitePort"
              Root="HKLM"
              Key="SOFTWARE\torresdal.net\SimpleWebApp\Install"
              Type="raw" />
    </Property>
    <Property Id="WEBSITE_IP">
      <RegistrySearch Id="WebSiteIP"
              Name="WebSiteIP"
              Root="HKLM"
              Key="SOFTWARE\torresdal.net\SimpleWebApp\Install"
              Type="raw" />
    </Property>
    <Property Id="WEBSITE_HEADER">
      <RegistrySearch Id="WebSiteHeader"
              Name="WebSiteHeader"
              Root="HKLM"
              Key="SOFTWARE\torresdal.net\SimpleWebApp\Install"
              Type="raw" />
    </Property>
    <CustomAction Id="GetIISWebSites" BinaryKey="IISCA" DllEntry="GetWebSites" Execute="immediate"  Return="check" />
    <Binary Id="IISCA" SourceFile="$(var.SolutionDir)IISCustomAction\bin\Debug\IISCustomAction.CA.dll" />
    <InstallUISequence>
      <Custom Action="GetIISWebSites" After="CostFinalize" Overridable="yes">NOT Installed</Custom>
    </InstallUISequence>
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="INSTALLLOCATION" Name="SimpleWebApp">
          <Component Id="Default.aspx" Guid="fc46b1a2-35e9-4a17-896b-80b2daaae567">
            <File Id="Default.aspx" Name="Default.aspx" Source="$(var.SolutionDir)SimpleWebApp\Default.aspx" DiskId="1" KeyPath="yes" />
          </Component>
          <Component Id="Web.config" Guid="2ED81B77-F153-4003-9006-4770D789D4B6">
            <File Id="Web.config" Name="Web.config" Source="$(var.SolutionDir)SimpleWebApp\Web.config" DiskId="1" KeyPath="yes" />
            <util:XmlFile Id="AppSettingsAddNode" File="[INSTALLLOCATION]Web.config" Action="createElement" ElementPath="/configuration/appSettings" Name="add" Sequence="1" />
            <util:XmlFile Id="AppSettingsKeyAttribute" Action="setValue" File="[INSTALLLOCATION]Web.config" ElementPath="/configuration/appSettings/add" Name="key" Value="AddedDuringInstall" Sequence="2" />
            <util:XmlFile Id="AppSettingsValueAttribute" Action="setValue" File="[INSTALLLOCATION]Web.config" ElementPath="/configuration/appSettings/add" Name="value" Value="This text was added during installation." Sequence="3" />
          </Component>
          <Directory Id="binFolder" Name="bin">
            <Component Id="SimpleWebApp.dll" Guid="7FC6DA37-12E5-463d-8E7E-08F73E40CCF2">
              <File Id="SimpleWebApp.dll" Name="SimpleWebApp.dll" Source="$(var.SolutionDir)SimpleWebApp\Bin\SimpleWebApp.dll" DiskId="1" KeyPath="yes" />
            </Component>
          </Directory>
        </Directory>
      </Directory>
      <Directory Id="ProgramMenuFolder">
        <Directory Id="MyWebAppStartMenuFolder" Name="SimpleWebApp">
          <Component Id="StartMenuFolder" Guid="B3AEC4C4-3F8E-4865-B87A-B750533776B5" >
            <util:InternetShortcut Id="SimpleWebAppShortcut" Name="SimpleWebApp" Target="http://localhost/SimpleWebApp/Default.aspx" Directory="MyWebAppStartMenuFolder" />
            <RemoveFolder Id="RemoveStartMenuFolder1" On="uninstall"/>
            <RegistryKey Root="HKCU" Key="SOFTWARE\torresdal.net\SimpleWebApp\SimpleWebAppShortcut">
              <RegistryValue Type="string" Value="Default Value"/>
            </RegistryKey>
          </Component>
        </Directory>
      </Directory>
      <Component Id="IISApplication" Guid="FFA12D9C-5AEC-45f8-AA7D-5C4CEC7FA466">
        <iis:WebAppPool Id="SWAAppPool" Name="SWAAppPool" />
        <iis:WebVirtualDir Id="VirtualDir" Alias="[TARGETVDIR]" Directory="INSTALLLOCATION" WebSite="SelectedWebSite">
          <iis:WebApplication Id="SimpleWebAppApp" Name="[TARGETVDIR]" WebAppPool="SWAAppPool" />
          <iis:WebDirProperties Id="WebVirtualDirProperties" Execute="yes" Script="yes" Read="yes" WindowsAuthentication="no" AnonymousAccess="yes" IIsControlledPassword="yes" />
        </iis:WebVirtualDir>
      </Component>
      <Component Id="PersistWebSiteValues" Guid="C3DAE2E2-FB49-48ba-ACB0-B2B5B726AE65">
        <RegistryKey Root="HKLM" Key="SOFTWARE\torresdal.net\SimpleWebApp\Install">
          <RegistryValue Name="WebSiteDescription" Type="string" Value="[WEBSITE_DESCRIPTION]"/>
          <RegistryValue Name="WebSitePort" Type="string" Value="[WEBSITE_PORT]"/>
          <RegistryValue Name="WebSiteIP" Type="string" Value="[WEBSITE_IP]"/>
          <RegistryValue Name="WebSiteHeader" Type="string" Value="[WEBSITE_HEADER]"/>
        </RegistryKey>
      </Component>
    </Directory>
    <CustomTable Id="AvailableWebSites" >
      <Column Id="WebSiteNo" Category="Identifier" PrimaryKey="yes" Type="int" Width="4" />
      <Column Id="WebSiteDescription" Category="Text" Type="string" PrimaryKey="no"/>
      <Column Id="WebSitePort" Category="Text" Type="string" PrimaryKey="no"/>
      <Column Id="WebSiteIP" Category="Text" Type="string" PrimaryKey="no" Nullable="yes"/>
      <Column Id="WebSiteHeader" Category="Text" Type="string" PrimaryKey="no" Nullable="yes"/>
      <Row>
        <Data Column="WebSiteNo">0</Data>
        <Data Column="WebSiteDescription">Bogus</Data>
        <Data Column="WebSitePort">0</Data>
        <Data Column="WebSiteIP"></Data>
        <Data Column="WebSiteHeader"></Data>
      </Row>
    </CustomTable>
    <iis:WebSite Id="SelectedWebSite" Description="[WEBSITE_DESCRIPTION]">
      <iis:WebAddress Id="AllUnassigned" Port="[WEBSITE_PORT]" IP="[WEBSITE_IP]" Header="[WEBSITE_HEADER]" />
    </iis:WebSite>
    <Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION" />
    <UIRef Id="MyUI" />
    <Feature Id="ProductFeature" Title="SimpleWebApp" Level="1">
      <ComponentRef Id="Default.aspx" />
      <ComponentRef Id="Web.config" />
      <ComponentRef Id="SimpleWebApp.dll" />
      <ComponentRef Id="StartMenuFolder" />
      <ComponentRef Id="IISApplication" />
      <ComponentRef Id="PersistWebSiteValues" />
    </Feature>
  </Product>
</Wix>

The End! 
That’s that! If you’ve come this far you (hopefully) have a functional CA with goodies that allow your user to select web sites in your installer. Hope you found this post useful and let me know if you find any errors or questions, and I’ll help you out. Btw here’s the end result:

MsiSelectWebSite

.Net | CSharp | Deployment | IIS | WiX
Friday, October 24, 2008 10:41:23 PM (W. Europe Daylight Time, UTC+02:00)
Sunday, December 23, 2007

iis7logoSP's are a necessity, but what I want to know is what have they done to improve IIS 7? Here's what the release notes for SP1 RC says:

IIS was included in some Windows Vista SKUs to enable web-based developers to write and test their applications. IIS in Windows Server 2008 is a significant server role which requires Internet-level scalability and performance requirements. The IIS7 components have gone through significant performance and reliability enhancements since Windows Vista originally shipped, in order to be a large-scale server component. These changes do not affect most Windows Vista users who do not even have the IIS7 components installed, however because Windows Vista and Windows Server are aligned, these changes are included in Windows Vista SP1.

You can find the "complete" change log here: http://technet2.microsoft.com/windowsvista/en/library/005f921e-f706-401e-abb5-eec42ea0a03e1033.mspx?mfr=true

So does this mean that there is a full UI and ftp support? The current IIS available in Vista is very limited by this. You can configure most of the stuff in config files (like I did with http redirect and logging bandwidth and referrers), but I would at least expect the features found in IIS 6 to be available from the UI in IIS 7. I've googled around to find some  more info, but nothing yet. I guess I'll have to install the RC to find out. Not sure if I want to risk it though...

IIS | Microsoft | Software | Vista | Windows
Sunday, December 23, 2007 12:59:30 AM (W. Europe Standard Time, UTC+01:00)
Saturday, August 11, 2007
Christian Weyer has an article on MSDN Mag together with Steve Maine and Dominick Baier about using Windows Process Activation Service (WAS) for non http protocols. Actually it's about much more than that, but that is what I found interesting. Hosting WCF services in WAS gives you the possibility to use NetTcp, Named Pipes and MSMQ protocols. For more info about WAS you should read the article. Anyway, using WAS as a host for WCF services sounds like a good idea. You don't have to create and maintain your own NT Service and you get stuff like "on-demand activation, process health monitoring, enterprise-class manageability and rapid failure protection" for free. But then you also get some lifetime management "features":

"...WAS does demand activation (as you know, the "A" in "WAS" stands for activation). This means that the application domain hosting a service only gets created when a request message comes in. Application domains shut down again after a configurable idle period. There are also several reasons why WAS or the ASP.NET runtime may decide to recycle the application domain or even the whole worker process."
So I suspect there would be some overhead of creating and shutting down the app domain, unless you can set the idle period to infinite of course. And then you have the recycle bit... Hmmm.... Do I want that?

If I were asked: "WAS or NT Service?", I think I'll go for the NT Service, unless there's something I totally missed out on here... which definitely could be the case <smile>.

If you want to try this out you might find these code samples interesting in addition to the article mentioned.
.Net | IIS | WCF
Saturday, August 11, 2007 1:46:31 AM (W. Europe Daylight Time, UTC+02:00)
Wednesday, February 21, 2007
I'm using SmarterStats for my blog statistics and have been annoyed by two things for a while. I get no statistics for bandwidth and referers. I looked around on the web and found that these things are actually not logged in IIS by default. I found this article describing how to enable it in IIS 6. Now I had to find out how to do the same thing in IIS 7. As I and others have mentioned earlier, IIS 7 in Vista don't have much UI yet, so most of the work is done in config files. I checked out the schema and came up with this:

<sites>
  <
site name="Default Web Site" id="1">
   
<
application path="/" applicationPool="ASP.NET 1.1">
     
<
virtualDirectory path="/" physicalPath="" />
   
</
application>
    <
bindings>
      <
binding protocol="http" bindingInformation="*:80:" />
   
</
bindings>
    <
logFile logExtFileFlags="Date, Time, ClientIP, UserName, ServerIP, Method, UriStem, UriQuery, HttpStatus, Win32Status, ServerPort, UserAgent, HttpSubStatus, BytesSent, BytesRecv, Referer" />

  </site>
</
sites>

After these changes I went into SmarterStats and found values for both bandwidth and referers. Fantastic!
IIS | Vista
Wednesday, February 21, 2007 7:29:47 PM (W. Europe Standard Time, UTC+01:00)
Wednesday, January 24, 2007
MsdnLive.jpgDon't forget to register for MSDN Live in Bergen 13. February! It's no surprise that Ajax and IIS 7 attract a lot of people to this event, so register now before it's full. You don't want to become the guy, who wasn't there, would you? ;) You can even pick up some Tips & Tricks for VS 2005. If this Tips & Tricks session is the same as at TechEd, you'll have to see it!
Wednesday, January 24, 2007 12:37:07 AM (W. Europe Standard Time, UTC+01:00)
Wednesday, December 27, 2006
When I moved my blog from Blogger to DasBlog I wanted to keep rss.xml and atom.xml, and redirect them to the new DasBlog url’s. I googled a bit but didn’t find much. And the ones I found I wasn’t able to use (maybe because I’m running Vista RC2). Anyway, last night enough was enough and I decided to put this to an end. I started to look at IIS’s config file applicationHost.config (usually found at C:\Windows\System32\inetsrv\config) and one section got my attention: <httpRedirect enabled="false" />

The problem was finding schema documentation for this element. After a while I found this (http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=946&p=24). To solve my problem I used this:

<httpRedirect     enabled="true"

exactDestination="true

httpResponseStatus="Permanent">

        <add      wildcard="/rss.xml"

destination="/SyndicationService.asmx/GetRss" />

        <add      wildcard="/atom.xml"

destination="/SyndicationService.asmx/GetAtom" />

</httpRedirect>

So if you have a similar problem I hope this helps.

Update:
I upgraded to Vista Release and suddenly the redirect didn't work anymore. I tried and tried and tried and gave up. I tried again and came over this:


WindowsFeatures.jpg

That nailed it. Don't know why I didn't see this before, but it would be nice though if the error message said something about enabling this feature.
DasBlog | IIS | Vista | Web
Wednesday, December 27, 2006 3:27:57 PM (W. Europe Standard Time, UTC+01:00)
RSS RSS - Comments Twitter LinkedIn
         
SEARCH
 
 
         
TOP POSTS
   
         
NAVIGATION
   
         
CATEGORIES
  .Net (61) ADFS (3) Agile (30) Ajax (5) Architecture (20) Articles (1) ASP.NET (6) ASP.NET-MVC (1) Blogging (12) Books (2) BPEL (1) CleanCode (1) CloudComputing (7) Community (4) CSharp (11) DasBlog (5) Database (2) DDD (5) Deployment (16) DSL (1) Events (38) ExtremeProgramming (6) Fun (6) Gadgets (4) IIS (10) InfoQ (4) Java (2) Lean (3) Linq (2) MemoryLeaks (5) Microsoft (37) MVC (1) NDC (2) NNUG (36) Other (10) Patterns (9) Performance (3) Scrum (17) Security (7) ServiceBus (1) Silverlight (4) Software (19) TeamManagement (11) TechEd (7) Testing (4) Tools (25) TvGuide (1) WCF (8) Web (15) WebDeploy (1) WIF (3) Windows (10) Vista (15) VisualStudio (16) WiX (9) Work (16) Workflow (3)  
         
ARCHIVE
   
         
BLOGROLL
   
         
ON THIS PAGE...
 
No-Click Web Deployment – Part 2 – Web Deploy (a.k.a. msdeploy)
No-Click Web Deployment – Part 1
Using IIS7 And Application Request Routing as Load Balancer – Part 2
Using IIS7 And Application Request Routing as Load Balancer – Part 1
WiX and DTF: Using a Custom Action to list available web sites on IIS
Windows Vista SP1 - IIS 7
Hosting WCF services in WAS
Logging bandwidth and referers on IIS 7
MSDN Live in Bergen
Http redirect on IIS7