IIS – How to tackle multiple web servers & keep them in sync

2017-12-07T12:08:33+00:00 December 23rd, 2009|Azure, Cloud|

I’ve recently been engaged on a project where we have multiple web servers (IIS7.5 on 2008r2 for those interested) which require exactly the same content and configuration (they’re sitting behind a Forefront TMG server using a web farm).  The configuration in IIS for this application happens to be complicated & while I have documented how to configure the servers, doing it over and over will not only be tedious but probably introduce some human error. 

To resolve this issue I implemented IIS 7’s shared configuration and put a process in to replicate the content between web servers.

You will need a domain account (or local account on each web server if your web servers aren’t domain joined) which will be used to access the shared configuration (it only does this – your web applications continue to run under what ever application pool identity you have set) and a file share to store the configuration on.

Assuming you’re at the stage of having a configured web server with the IIS configuration how you want it you need to export the configuration:

  1. On the first web server / machine which will host the shared configuration create a directory & share it giving full share and ntfs permissions to the service account created, all other permissions should be removed.
  2. In IIS manager on the server with IIS configured as per the previous steps click on the server node in the left pane, then open shared configuration in the right pane, then finally select the export configuration option on the right, store the export in the directory created in step 1, entering an encryption key (this should be recorded as it is needed for all nodes which will be accessing the shared configuration).
  3. When exported tick the ‘Enable shared configuration’ box, enter the UNC path to the configuration (eg machinenameiisconfig) enter the username domainserviceaccount and the password for that account, press apply, you will be prompted for the encryption key provided in step 2.
  4. Restart the server to apply configuration, then check IIS is still functioning and the IIS manager can be accessed.

The above steps will reconfigured your already configured web server to work from the shared configuration, now we need to replicate the web content and configure all other web servers to work from the same configuration.

There are several ways of replicating the physical content, DFSR is one option, however I chose not to use it as the content on the web servers is staying static so frequent updates to the other nodes will not be required and it gives the operator responsible for the servers more control over how content updates are deployed.  So instead I used robocopy (which has been built in since Vista / Server 2008) to mirror the content from the configured server to all others (this was executed on the web server to be copied to):

 

robocopy configuredwebserverc$inetpubwwwroot c:inetpubwwwroot /MIR

 

Once the file content was in place two quick steps are required to configure IIS to use the shared configuration:

  1. Open IIS manager, click on the server name in the left pane, then select the shared configuration option in the right pane, tick the ‘Enable shared configuration’ box, enter the UNC path to the configuration as specified on the first web server (eg machinenameiisconfig) enter the username domainserviceaccount and the password for that account, press apply, you will be prompted for the encryption key.
  2. Restart the server to apply configuration, then check IIS is still functioning and the IIS manager can be accessed.
    This process will replicate all application pools and IIS configuration, however if you have ODBC data sources etc.. (things external to IIS which your web applications are using) then you will need to find a way to replicate these settings as well. 
    An important point is how IIS behaves if the configuration becomes unavailable, under Server 2008 (not R2) if the configuration disappears IIS will essentially stop, under R2 the server will detect this, continue working and reconnect when the configuration source comes back online.  You can enable offline files for added resiliency should you require it.