\[Author's Note: Each month, this column discusses various aspects of the advanced administration of e-business sites. This month, I focus on the administrative features in IIS 6.0—the completely rearchitected Web server that's part of the upcoming Windows .NET Server (formerly code-named Whistler).\]
Almost 2 million Web sites run on IIS 5.0 and Windows 2000. When Win2K shipped, many people were concerned about upgrades from Windows NT and IIS 4.0 to Win2K and IIS 5.0. However, in-place upgrades were painless, reliability was dramatically better, and sites generally received over 33 percent better performance simply by upgrading. So, administrators quickly learned that upgrading from IIS 4.0 to IIS 5.0 was easy.
By now, you've probably heard what's looming around the corner—IIS 6.0 on .NET Server. IIS 6.0, which was in beta 2 release at the time of this writing, promises the same 33 percent performance boost with minimal effort on your part. Coupled with ASP.NET and Microsoft's .NET strategy, you could even see performance gains of 75 percent. This month, I introduce you to some of the more exciting features of IIS 6.0 as they relate to administration and manageability.
Working with Metabase.xml
The metabase in IIS 5.0 and IIS 4.0 is a proprietary binary file called metabase.bin that's not easily readable or editable. (For more information about working with the IIS metabase, see "Related Reading.") When IIS 6.0 ships, the metabase as we know it will be dead in Microsoft OSs.
Starting with .NET Server, IIS 6.0 replaces metabase.bin with a plaintext XML-formatted file called metabase .xml, which resides in the \windows\ system32\inetsrv directory. Fortunately, this new format doesn't mean that your current scripts and tools will no longer work. Because the XML metabase and the IIS 6.0 API are 100 percent compatible with their predecessors, you'll be able to use them. You'll also get the added benefit of improved performance because the binary metabase's hierarchical structure makes the file slow to read from and write to. Other benefits of an XML-formatted plaintext metabase are
- improved backup and restore capabilities on machines that experience critical failures
- improved troubleshooting and metabase-corruption recovery
- you can extend the metabase schema—that is, you no longer need a software developer for this task
- you can edit the metabase directly with common text-editing tools, such as Microsoft Notepad or XML editors
Metabase.xml isn't a small file. The file contains a wealth of information. I've included a sample metabase.xml file that you can peruse. You can download this file from the Code Library on the IIS Administrator Web site (http://www.iisadministrator.com). If you plan to examine this sample file's structure, look at it in a program that renders XML, such as Microsoft Internet Explorer (IE) 4.0 or higher. (Looking at a large XML data file in a formatted view is less intimidating than staring at XML in Microsoft Notepad.)
In earlier versions of IIS, changes to the metabase aren't reflected until you restart the Web site. One of the best features of IIS 6.0 manageability is Direct Metabase Edit. This feature lets you edit metabase.xml while IIS 6.0 is running. When you save your changes, they immediately go into effect; you don't need to restart the server. I put this feature to the test immediately after installing .NET Server.
You turn on the Direct Metabase Edit feature at the IIS service level. When you right-click your server in the Microsoft Management Console (MMC) Internet Information Services snap-in, you'll see a new tab called Internet Information Services, which Figure 1 shows. On this tab, you enable direct metabase editing. By default, the Direct Metabase Edit feature is disabled, most likely because of the security implications of an authenticated user with Write privileges making a naive mistake.
After enabling direct metabase editing, I tested the feature by creating a Web application that had a virtual directory. Using a text editor, I found the spot in the metabase file where the application should reside by navigating through the XML schema toward the bottom of metabase.xml where all the Web sites are defined. I pasted the XML code that Listing 1 shows into metabase.xml. If you look closely at the XML code, you can see that I added a sixth Web server called TomHuckaby.com to my IIS configuration with a virtual directory called IISHelp that points to the IIS Help application. After I saved the .xml file in Notepad, I switched back to the Internet Information Services snap-in and clicked Refresh. Figure 2 shows the new site and virtual directory in the Internet Information Services snap-in.
Although I pasted the new XML code into the section of metabase.xml in which all the Web sites are defined, when I saved the file in my text editor and viewed it in IE, I found that IIS 6.0 had placed my new XML at the bottom of the file. I speculate that this placement is how IIS 6.0 efficiently tracks changes and is able to roll them back.
Backup and Restore with Metabase.xml
Another excellent enhancement in IIS 6.0 is that you perform metabase backup and restore through iisback .vbs. IIS 6.0 automatically stores (i.e., creates versions) each revision of the metabase in the \windows\system 32\inetsrv\history directory, which makes rolling back unwanted changes easy. Historically, when a metabase was corrupt, you typically had to completely reinstall IIS. With IIS 6.0, you simply roll back a change while IIS is still running. Figure 3 shows the restore syntax.
Importing and Exporting Site Information
The XML metabase makes importing and exporting site information easy. Microsoft's IIS team has replaced the machine-dependency feature in the metabase file with an import-export tool called iiscnfg.vbs, so you can easily use a default template to ensure that all sites receive the same settings. In earlier versions of IIS, you could hard-code the server name of the metabase that you import or export into the metabase backup file (depending on the branch you imported or exported). In IIS 6.0, you simply export the branch of the XML metabase you want to move to another site, then import the branch to the new servers. The tool essentially lets you clone a virtual directory from one server to another. Iiscnfg.vbs has separate modes for import and export. Figure 4 shows the syntax for exporting from metabase .xml. Notice that you can use a source path as low or as high as you require in the XML metabase hierarchy. Iis cnfg.vbs supports flags for inheritance and child nodes.
The WMI Interface and Command-Line Tools
Microsoft now ships a Windows Management Instrumentation (WMI) provider in the box with IIS 6.0. WMI provides an easy way for you to leverage Windows OS features. The IIS WMI provider contains a set of programming interfaces that offer more powerful and flexible ways to administer your Web sites than the traditional approaches in Active Directory Service Interfaces (ADSI). For example, the IIS 6.0 WMI provider contains underlying query support, which lets you write SQL queries in your administrative scripts. The command
Select * from IIS_WebVirtualDirSetting where AccessWrite = true
shows the syntax for querying all virtual directories on which you've enabled Write permissions.
In addition, many command-line tools (i.e., scripts) are available that leverage the WMI provider in .NET Server's \system32 directory. The command-line tools with WMI let you manage the entire system, including IIS. Iisweb.vbs lets you start, stop, pause, continue, delete, create, and query IIS sites. Because this script is written to leverage the IIS WMI provider, it's not limited to performing administrative functions on the server on which it's running. Iisweb .vbs can perform administrative functions remotely on the IIS machines on your LAN or in your Web farm. Let's take a look at the query features of iisweb.vbs.
The script's /query switch lets you examine the details of existing Web sites. Figure 5 shows the syntax for this switch. The script's query functionality is easy to use yet powerful. By simply executing iisweb.vbs with the command
Cscript iisweb.vbs /query
you receive a list of all the Web sites on a server, their site names, metabase paths, IP addresses, ports, and host names. Executing the script with the command
Cscript iisweb.vbs /query "Default Web Site"
gives you the same summary as the previous command but for the Default Web Site only.
The WMI provider in iisweb.vbs facilitates the easy creation of Web sites. The script's /create switch provides functionality that's similar to the functionality that IIS 5.0's mkw3site.vbs script provides. However, because iisweb.vbs uses the WMI provider, you can use this script to create Web sites on remote servers. To obtain the syntax for the /create switch, use the command
Cscript iisweb.vbs /create /?
Pay particular attention to the optional /dontstart parameter. You don't want to create sites programmatically in a production Web farm and have a load balancer immediately route traffic to them. The /dontstart parameter creates the site in a Stopped mode so that you can move the contents and components to the site before you turn each site on.
Another significant parameter is /a. This parameter grants specified file-system user access rights to a defined user in the form of Read, Write, Change (Write), or Full control upon creation of the site, which saves you the hassle of granting rights manually through a UI after you've created the site.
With the XML metabase, you can transfer server-configuration information between computers. The XML metabase also allows for remote administration and Direct Metabase Edit capability. Load the XML metabase into any editor: See what's there, telnet in, and make repairs if you have to. If you need to make a change, just save the file; the changes take effect without having to restart the server. Earlier versions of IIS simply don't have that power.
IIS 6.0 includes more command-line scripts and the WMI provider. The WMI provider uses COM object interfaces to provide access to IIS meta-base data in an easier, more manageable manner than ADSI. In addition, the WMI provider supports SQL queries, which makes finding objects in the metabase easier.
Next month, I'll return to Microsoft Application Center. I'll show you how to move an existing IIS Web server farm (or one IIS server) to an Application Center cluster and tell you what you can expect to gain from the move.
You can obtain the following articles from IIS Administrator's Web site at http://www.iisadministrator.com.|
"Getting to Script the Metabase," April 2001, InstantDoc ID 20058
"Getting to Edit the Metabase," February 2001, InstantDoc ID 16462
"Getting to Know the Metabase," January 2001, InstantDoc ID 16179