Microsoft provides a tool called IISCnfg for management of
the Internet Information Services (IIS) Settings. One of the features that
this includes is the ability to replicate the IIS settings from one server to
another. This is useful in a webfarm environment where you require all web
servers to be in sync.
IISCnfg.vbs is automatically placed in the %windir%/System32
folder if IIS6 is installed and is a command line tool to be run directly or
through a batch file.
I have been using IISCnfg for a few years on a number of
different webfarms and have worked through a few issues with it that I will
share here. I am also making a few scripts available that extend and help
better utilize the IISCnfg file. IISCnfg has a fair bit of flexibility, but it
has a couple shortcomings to become aware of and overcome.
IISCnfg.vbs has four main commands: save, export, import and
copy. I will summarize them here.
Save
This simply saves a copy of the IIS metabase as if you were
saving from the IIS Management tool. It will save it to the
%windir%/system32/inetsrv/MetaBack folder and you will see it as an available
backup to be restored from the IIS Management tool.
Export
This allows you to export the entire IIS metabase or parts
of it to a file that you specify. If you specify a password when exporting,
the machine specific information will be stripped out and you can restore this
on a different server.
Import
This is the opposite of Export and allows you to import a valid
file back into the Metabase.
Copy
A Copy uses a combination of Export and Import to copy the
IIS settings from one server to another. It will export the metabase to disk,
map a network drive to a target server, copy the file over and use Import on the
other end to load the metabase into the target server.
For metabase replication I use two terms to describe the
features that I want to utilize:
Push
When I mention a metabase push, I am referring to the /Copy
feature of IISCnfg. This is easy to set up and run, but the drawback is that
there is downtime on the target server while the import is run. In a
production environment this is often not acceptable unless you first disable
the web server from the load balancer so that no traffic goes to the target
server during the push.
Merge
A Merge on the other hand is not a built-in feature of
IISCnfg and needs to be handled manually. It will not do the export, map the
network drive and import on the other end like the /Copy feature does. MetabaseMerge.bat
in the included .zip file takes care of this for you.
The advantage of the Merge is that there is no downtime on
the remote servers. This makes it a better solution for day-to-day changes on
a webfarm. The thing to be aware of is that it only adds or updates the data
and does not take care of deletes. So if you delete a site or an application
pool or remove a folder as an application, those will not carry over to the
target server using Merge.
Push / Merge Comparison
|
PUSH
|
MERGE
|
|
Replicates everything including deletes
|
Deletes not replicated
|
|
Downtime on target server during Push
|
No downtime or slowness during Merge
|
|
/copy command takes care of all the hard work
|
/merge is a property of import and requires you to
manually take care of what /copy does automatically
|
Because there are a different set of advantages and
disadvantages for each method, I use a Merge whenever possible. If there are a
lot of changes that involve deletes, I will do a staggered replication push
while coordinating with the load balancer to take nodes offline during the
Push.
