17 Mar 2012

Easy Sync for IIS7 - No Web Farm required

In a previous post I detailed procedure for installing the Microsoft Web Farm Framework to facilitate IIS load balancing and replicated content sync for Server 2008 EC2 instances in AWS, a system that in theory sounds ideal but in practice isn't that reliable (or even possible) if you have existing live sites, however there is a much simpler and cleaner way to achieve IIS replicated goodness using a bit of the old and a bit of the new. I use Robocopy for content sync combined with IIS7 shared config (for shared config), here's how......

So, we have Box1 and Box2, to replicate content you'll first need to share C:\inetpub\wwwroot on Box2. Once done open relevant ports to enable connectivity on both your AWS security group & OS firewall. The actual drive mapping isn't required at this stage as we'll be calling a batch file to take care of it.

For obvious reasons it's a good idea to restrict user account access and tie open ports down between your AWS elastic IPs, this is easily done thanks to the simple and clean config provided by AWS security groups.

Ok, Robocopy, this you run on Box1. I use the task scheduler to manage it via a batch file which also includes a drive mapping. I find the scheduler works fine as you can choose to run any task whether logged on or not, which is what we want in this instance.
Here's an example batch file to use for replication, it maps the drive and kicks off replication when a change is detected, copies updated files with all their attributes and will purge files from the destination if they don't exist on the source.

NET USE w: \\\wwwroot /USER:IP-0A1B3C44\Administrator password
C:\inetpub\wwwroot w:\ /S /E /COPYALL /PURGE /MON:1 /MOT:1 /XO

Make sure you have your machine name fixed as default EC2 instances rename themselves at reboot (De-check the relevant entry in the EC2 Config Service Settings).

Next we need to set up IIS shared config. I won't go into this in any detail as there are multiple How-Tos around the internet and it's quite a simple procedure, however here's a short breakdown....
  • Create a matched user account on both boxes to use for shared config.
  • Open the shared config utility in IIS Manager
  • Create a folder either locally or on a remote location.
  • Export your config into it, creating a secure encryption key password when asked.
  • Complete relevant details to enable (As shown in Fig:1).
  • Apply.
  • Do the same on Box2 (Using the UNC path).
  • Refresh (NOT restart) IIS manager to show any changes.

Fig:1 - Shared Configuration connection details box.

Ideally you should have a third location to host the config files however you can get by holding them in a UNC share on Box1 and reverse mapping back to it from Box2, that is if you're happy having Box1 as your master and are confident of its ability to stay live, different setups have different needs, just choose a level of resilience you're comfortable with.

And that's it, simple, clean, visible and a damn site easier to setup than the ridiculously over convoluted Web Farm Framework. I've lost days, if not weeks, trying to get WFF to work, but why over complicate things? Life is too short and I'd rather not spend it stuck down a Microsoft rabbit hole.


Anonymous said...

Using a shared configuration is safer if you use Offline Files:


That'll allow you to reboot the server as needed and the configuration is still cached for dependent servers to use.

RichBos said...

Hi, thanks for the comment and yes, very true, we actually discovered this only last week when the 'main' box went offline, as such we configured it 'offline' files the day after. We didn't realise IIS would balk, although we should have realised had we thought about it.

Post a Comment