"Software Tools to Maximize Up-time and Automate Functions in Microsoft’s Internet Information Server”

Home

Server Automation Tools

John On Automation

Reviews and Articles

List All Articles

Everything But Computers

Just Thinking

Site Marketing

Past Newsletters

DomainReportIt PRO. A Short Brief - Part II.

by John Cesta

Printer Friendly Version

DomainReportIt PRO - Part Two

In Part One of this short brief I discussed the reporting capabilities of our DomainReportIt PRO (DRP) program. Part Two I will discuss its more powerful feature of actually creating scripts to run on a new IIS install which will create new Web sites from the existing data.

A brief look at where IIS stores its data...

Let's start at the beginning. Where is the IIS data stored? Most of it, not all, but 95% is stored in the metabase.bin. The metabase, by default, lives in the C:\WINNT\system32\inetsrv\MetaBase.bin directory.

You can move/hide the metabase.bin (good idea) if you want, for security purposes, and here is how:
 http://support.microsoft.com/default.aspx?scid=kb;en-us;321142
(If the URL is dead the Microsoft Knowledge Base Article is - 321142.)

You can really see the inner workings of the metabase by using the metabase editor. You can download it here:

MetaBase, download and install: http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b301386#3

(If the URL is dead the Microsoft Knowledge Base Article is - 301386.)

The other 5% of the IIS data is stored in the registry. This is one of the major reasons why simply copying the metabase onto a new Win2k IIS server to build a new IIS system does not work. You're leaving behind some important pieces in the registry of the old installation.

Now let's move on to the DRP program's inner workings...

Now that we know where IIS stores it's data let's move on to how our DRP program works. Basically it traverses the metabase, going through each index value, see the image below, extracting the important properties. The important properties are the ones required to create a new Web site on a brand new server.

The important pieces are the:

Index value
Server comment
Server Bindings
Domain's root path on the server

Let's look at the metabase properties of the magicstore.com domain...

Notice the index values on the left. These represent the actual Web sites in your IIS installation. They are numbers because, programmatically, it's easier and faster to itemize integers than text strings. When you start adding hundreds of sites in IIS you will notice the time it takes to display them all in the MMC.

Index value number 5 is our site: magicstore.com

Notice the serverbindings in the metabase and compare them to the serverbindings in the MMC properties for magicstore.com in the two images above. Notice the similarity? They are the same, oh yea, they would be. ;-)

Continuing on to the ROOT directory of index 5 (magicstore.com) shows us a little more information. First notice the KeyType? It is now an IIsWebVirtualDir instead of an IIsWebServer.

In the two images directly above, compare the top image, which is a picture of the exposed metabase properties of magicstore.com, with the MMC's picture of the properties. Identical.

As you can see the required information to create a new identical Web site via a script is present in the metabase and there for the taking, or, in our case, extracting.

Before you run the DRP program to extract sites and create the new vbscripts look at this image and read the note following it.

IMPORTANT NOTE: This is the MASTER Properties sheet of an IIS installation. The MASTER Properties sheet contains the default values that will be used when creating a new Web site in IIS. Whatever properties are contained in the MASTER Properties will be used to create your new site. So, before you create your vbscripts with DRP spend a little time reviewing the MASTER Properties. Set them the way you want the majority of your sites to be configured.

For example.

Set your logfile settings in the MASTER Property sheet.

Set the Default Document mappings you want your new Web sites to inherit.

One IMPORTANT NOTE: The Application Protection in you new sites will not match the Application Protection in your MASTER Properties. I don't know why, I could never get it work. But in our script you can set the Application Protection to the value you want all your new sites to inherit. By editing the script you will see a well documented section on this. You will only need to set a variable to 0, 1, or 2 depending on the level of protection you want your new sites to inherit.

The vbscript DRP creates is a bat file that looks like this:

magicstore.bat

The bat file is named after the servercomment defined in the Web site in IIS. This way all bat files are unique and can be visually scrutinized.

The contents of the bat file look like this:

createaweb.vbs -c localhost -r "D:\webroot\mstore" -t "magicstore" -i 216.219.241.36 -o 80 -b 216.219.241.36:80:,216.219.241.36:80:magicstore.com,216.219.241.36:80:www.magicstore.com

Can I modify the vbscript?

When run, the script will create the new site in IIS. You also have the option of modifying the script to add an FTP server or an SMTP server to the site and/or set the value for FP extensions. You can change the anonymous user of the site to change from the default of IUSR_computername if you are of the school that has a different anonymous for each Web site.

What else can I use the vbscript for?

The final benefit of using our DRP program is that the vbscript can be used in an automated hosting company. The script can be populated via a Web form and saved as a bat file to a directory on the server. You can then use our FileSpider program, which runs via a scheduler, to run every hour. It will itemize the bat files in the directory, run each one and you've just automated the process of creating your client's Web sites.

If you like this article or maybe had a similar experience and would like to share it with other readers then feel free to:

Simply fill in YOUR e-mail address, your name and your comment. Click the SEND button.
After submitting your comment, you will be transported back to the article you commented on!

Name E-Mail Address

You

Sending to

Your Message

John Cesta is a contract programmer. John's current project is designer and lead developer of the automated hosting software at bestcfhosting.com, a ColdFusion MX hosting company. John is currently working on commercializing his programs and offering them to the IIS community at serverautomationtools.com