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

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.

The IIS Metabase has permission settings (ACLs) on various nodes of the metabase and you can lock down or loosen the permissions using the command line tool metaacl.vbs or using Metabase Explorer included in the IIS Resource kit.  This is similar in concept to file system permissions on an NTFS disk volume.  Normally this is something that does not need to be changed except for very specific requirements, but the push does not handle the ACLs perfectly, requiring us to dig deeper.  The best I can tell, this is an oversight in the export or import function built into IIS.  The IIS_WPG group, which is commonly used, needs to be switched from a node specific SID of the source server to the SID of the target server.

The copy/import works properly in the root nodes of the metabase and some other nodes that have specific permissions, but there are two sections of the metabase that are not handled correctly.  They are /w3svc/AppPools and /w3svc/Filters.

It is easier for me to explain by showing the output of the metaacl.vbs tool.  Here is an example of an untouched metabase.

Listing 1

C:\admin>Metaacl.vbs "IIS://localhost/w3svc/apppools"
 BUILTIN\Administrators
 Access: RWSUED
 NLB1\IIS_WPG
 Access: U
 NT AUTHORITY\NETWORK SERVICE
 Access: U
 NT AUTHORITY\LOCAL SERVICE
 Access: U 

Notice the NLB1\IIS_WPG with U permissions.  Now let us look at the same node after a push.

Listing 2

C:\admin>Metaacl.vbs "IIS://localhost/w3svc/apppools"
 BUILTIN\Administrators
 Access: RWSUED
 S-1-5-21-2936230025-297186120-535571621-1007
 Access: U
 NT AUTHORITY\NETWORK SERVICE
 Access: U
 NT AUTHORITY\LOCAL SERVICE
 Access: U 

Notice where the IIS_WPG group used to exist; now there is just an invalid SID.  This will not cause your sites to stop, but it will cause issues with IIS being unable to read the private memory limits of the app pool and other similar issues.  So, when doing a push, make sure to clean that up.  The attached scripts take care of that as well.

When doing a Merge, I found that the easiest way to handle this is to remove the ACL lines completely and retain the permissions from the destination server.  I have another script called RemoveAdminACLline.vbs that takes care of that.  That makes the /merge even cleaner because it does not touch the ACLs on the destination server.

The other default behavior with IISCnfg that I have adjusted is the unnecessary requirement to put in the username and password of the target server.  IISCnfig makes these required fields, so if you leave them off, the /copy command will not work.  If the user identity running the script has permission to the target server, it should be able to pass that through to the target server without requiring you to put the username and password in the batch file.  If you need to put the username/password in the batch file, that means that you need to maintain it over time and it also means that you have a username/password in plain text in your batch files or scripts.  Fortunately, it was easy to comment out the requirement to do that and it works perfectly without it.  So, the attached files include IISCnfg2.vbs which has that modification.  I made a comment with my name (Scott Forsyth) beside each line that I changed so that you can tell what was changed.

Included Files

With the theory behind us, let us take a look at the files included in the download file.  Note that I did not try to pretty it up or put a lot of error checking in it.  It is simple and easy to understand, but that also means that you may need to do some digging into the files to make any changes or to troubleshoot any issues that I did not handle in a friendly way.

[The first two files are the ones that you will use to do a Metabase Merge or Push.] MetabasePush.bat

Usage: MetabasePush {ServerIP} [SMTP FQDN]

You can call this from a batch file that can live somewhere else, like on the desktop of your primary web server.  It will do a metabase push from the current server (localhost) to the target server specified by the ServerIP.

You can optionally add the SMTP FQDN and it will update that on the target server.  We use that at ORCS Web because each server node has a different SMTP FQDN.

MetabaseMerge.bat

Usage: MetabaseMerge {ServerIP} [SMTP FQDN]

This operates the same as MetabasePush except that it does a Merge instead.  The ServerIP is required and the SMTP FQDN is optional.  Do not forget the differences mentioned above between a Push and Merge.  This file calls RemoveAdminACLLine.vbs so that the target server retains its own security settings.

[The following files are helper files and do not need to be run directly.]

IIsCnfg2.vbs

This is a copy (confirmed up to date May 2006) of IIsCnfg.vbs, but with two minor modifications to make the target username and password optional.

Metaacl.vbs

This is an untouched Microsoft script to view and update the metabase ACLs permissions.

RemoveAdminACLline.vbs

This is used by MetabaseMerge.bat to remove the ACL lines so that the permissions on the target server are left untouched during a Merge.

ChangeSMTP-FQDN.vbs

This will change the fully qualified domain name of the SMTP server on the target server that you specify.  It is used when there are different SMTP DNS names on each server.

readme.txt

I am sure you can guess.

To utilize these scripts, simply extract the set of files to a folder on your server and then call MetabasePush.bat and MetabaseMerge.bat from your own batch files.  For example, you could create a batch file on the desktop of your primary web server that has the following in it.

Listing 3

--Metabase Merge.bat--
 d:\admin\ClusterUtils\MetabaseMerge.bat 192.168.2.11 web2.domain.com
 d:\admin\ClusterUtils\MetabaseMerge.bat 192.168.2.12 web3.domain.com
 d:\admin\ClusterUtils\MetabaseMerge.bat 192.168.2.13 web4.domain.com
 d:\admin\ClusterUtils\MetabaseMerge.bat 192.168.2.14 web5.domain.com
 d:\admin\ClusterUtils\MetabaseMerge.bat 192.168.2.15 web6.domain.com

If you double click on that file, it will do a Merge to the various servers on a WebFarm.  This assumes, of course, that you placed the files in d:\admin\ClusterUtils\.

Downloads

[Download Sample]

That is it!  I hope that you have found this useful and are able to utilize parts or all of it in your environment.

Scott Forsyth is Director of IT at ORCS Web, Inc. - a company that provides managed complex hosting for clients who develop and deploy their applications on Microsoft Windows platforms.