IISCnfg.vbs - IIS Settings Replication
IISCnfg.vbs - IIS Settings Replication
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've 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 4 main commands: save, export, import and copy. I'll 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'm 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 that 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 doesn't take care of deletes. So if you delete a site or an application pool or remove a folder as an application, those won't 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 of each method, I use a Merge whenever possible, but 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.
Metabase ACL Issue
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 doesn't need to be changed except for very specific requirements, but the push doesn't 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 aren't handled correctly. They are /w3svc/AppPools and /w3svc/Filters.
It’s easier for me to explain by showing the output of the metaacl.vbs tool. Here is an example of an untouched metabase:
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. But now let's look at the same node after a push.
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 won't 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 some 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. So I have another script called RemoveAdminACLline.vbs that takes care of that. That makes the /merge even cleaner yet because it doesn't touch the ACLs on the destination server.
Removing the Password Requirement - IISCnfg2.vbs
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. But, 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's 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's 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 didn't 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. Don't 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 don't 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'm 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:
--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\.
Download: http://weblogs.asp.net/blogs/owscott/ClusterUtils.zip
That’s it! I hope that you have found this useful and are able to utilize parts or all of it in your environment.