MetaEdit 2.2 Is on the Job

MetaEdit 2.2 is a Windows application that lets administrators edit the IIS metabase. The metabase is a state store for IIS configuration information—in other words, the metabase stores information about the state of IIS's configuration. Knowing about the metabase's background and structure is helpful when you start using MetaEdit. With this knowledge, you can better understand how MetaEdit reads and writes data to the metabase so that you can access master or individual Web sites, prompt the inheritance of properties, and add properties. After you know these basics, you can use MetaEdit to make metabase changes that you can't achieve with Internet Services Manager (ISM).

Metabase 101
You can think of the metabase as a registry for IIS. In fact, the metabase developed out of the need for a better registry. During the design of Windows NT 4.0, developers and software manufacturers added all their state information into the registry. They often used the registry because it had a good editor for their customers and a simple UI with which to program. (If they didn't use the registry, they had to use proprietary binary files for which they had to build a UI.) As a result, Microsoft needed to store more data than the registry could hold, so the company developed a new standard for state information: the metabase.

Unlike the registry, the metabase contains required and optional entries and definitions for values' data types. In addition, child objects can inherit information from parent objects in the metabase. In this respect, the metabase is similar to Active Directory (AD). Just as you can use Active Directory Service Interfaces (ADSI) to read and write information to AD, you can use ADSI to read and write state information to the metabase.

ADSI can have different meanings for different people. A domain administrator might consider ADSI as a programming interface to access the domain users and groups in AD, whereas a Web server administrator might consider ADSI as a programming interface for accessing IIS configuration information. Both views are correct. ADSI is a technology that lets Microsoft and other vendors use a standard format to read and write their state information. Several Microsoft server applications (e.g., IIS, Exchange 2000 Server, Site Server) include an ADSI namespace. You can access each namespace programmatically by using a standard set of ADSI objects that ship with Windows XP, Windows 2000, and NT 4.0.

By default, the metabase file (metabase.bin) resides on your hard disk in the winntsystem32inetsrv folder. You use ADSI objects to access the metabase. These objects communicate directly with the namespace provider. The namespace provider for the metabase is inetinfo.exe, which runs as the IIS Admin Server Service. In other words, to access the metabase, you need to start the IIS Admin Server Service. If you try to access the metabase without starting this service, ADSI starts the service for you. Inetinfo.exe is also the process that runs the SMTP, Web, and FTP services. However, these services don't start automatically when you use ADSI, nor do they access the metabase through ADSI. These services run in the namespace provider's process space, so they access the metabase directly.

MetaEdit 101
Some applications that use ADSI objects to change the metabase provide a GUI so that you don't have to use a script to call the objects. (Using a GUI is easier than using a script; however, good reasons exist for using a script. For more information, see "Use Scripts to Configure IIS," page 12.) One such application is MetaEdit. This Windows application is a free download from Microsoft's Web site. For more information about this download, see the Microsoft article "HOW TO: Download, Install, and Remove the IIS MetaEdit 2.2 Utility" (Q232068, http://support.microsoft.com).

Before you use MetaEdit, I highly recommend that you back up the metabase. To perform a metabase backup, follow these steps:

The backup file goes into the winntsystem32inetsrvmetaback folder on your machine. The file has the extension .mdx, where x is a number that's incremented when duplicate filenames exist. Although the backup file has the .mdx extension, it contains the same data as metabase.bin. After you've backed up your metabase, you're ready to open MetaEdit and begin viewing the metabase structures.

When you open MetaEdit, you'll probably notice that it looks similar to regedit. MetaEdit has a treeview on the left and a list on the right, as Figure 1 shows. Because the metabase is a structured state store, it doesn't store all the state information in the same registry key.

You can obtain a Web site's instance ID by writing a simple Active Server Pages (ASP) page that contains the code

<%  Response.Write(Request.  ServerVariables("INSTANCE_ID"))%>

Another way to figure out which instance ID relates to which Web site is to open MetaEdit, navigate to LMW3SVC1, and view the ServerComment property, which contains that Web site's name. Then, go to LMW3SVC2 and view the ServerComment property, and so on, until you find the Web site you want to edit.

If you use ISM to view the properties of a Web site node, you'll notice that some properties are related to the Web site and other properties are related to the files in the root of the Web site. For example, whether the directory has read/write access is a directory property, whereas the IP address is a Web site property. The metabase stores these different types of properties in different locations. For example, the LMW3SVC1 subkey stores the properties related to the instance 1 Web site (i.e., the Default Web site), and the LMW3SVC1ROOT subkey stores the properties related to the files in the root of the instance 1 Web site. LMW3SVC1 has a KeyType property of IISWebServer, whereas LMW3SVC1ROOT has a KeyType property of IISWebVirtualDir. As this example shows, the metabase represents the properties for the root of a Web site as if they were for a virtual directory. However, the Web site doesn't appear as a virtual directory because the Web site is at the top level in the directory structure.

The top-level keys are LM (which stands for local machine) and Schema. The LM key contains information about the local machine and is equivalent to the ADSI path IIS:\localhost. The Schema key contains information about the rules for setting data types and default values. Typically, you edit the Schema key only when you want to add custom properties to the metabase—a practice that I don't recommend for beginners.

Every key under LM has an assigned class, and this class determines what values of what type you can set in the key. A key's KeyType property declares that key's class. For example, the KeyType property of the LMW3SVC key is IIsWebServer, which corresponds to the schema in the SchemaIIsWebServer key. The SchemaIIsWebServer key contains all the defined settings and their default values. An important note is that all IIS properties are defined as optional; however, not all are optional. ADSI lets you define values as optional and mandatory, regardless of whether the service uses optional and mandatory values.

You'll edit and view keys under LM most of the time. Because all inetinfo.exe services use the metabase, the LM key includes subkeys for each service. For example, the settings for Web services are in the LMW3SVC subkey, the settings for SMTP services are in the LMSmtpSvc subkey, and the settings for FTP services are in the LMMSFTPSVC subkey. (You can use ISM to access most but not all of the information in these subkeys.)

Each key and subkey in the metabase has properties. In MetaEdit, these properties appear in the list on the right. As Figure 1 shows, the list has six columns: Id, Name, Attribute, UT (short for User Type), DT (short for Date Type), and Data. For the most part, you can ignore all but three columns: Name, DT, and Data.

One of MetaEdit's useful features is that it ensures that a property has the correct data type when you edit a property's data value. If you double-click the name of the property that you want to modify, the Edit Metabase Data dialog box, which Figure 2 shows, appears. This dialog box specifies the correct data type, regardless of whether that data type is DWord, String, or MultiSz. MetaEdit won't let you enter a wrong data type for a data value. However, MetaEdit lets you enter a data value that IIS might not understand. For example, the LMW3SVC subkey contains the AppAllowDebugging property, which is the property for server-side debugging. MetaEdit lets you change this DWord property to any valid DWord value, even though the only valid IIS values are 1 and 0. For this reason, you need to be careful when modifying values. Microsoft provides a good reference to AppAllowDebugging and all the other properties in the Microsoft Developer Network (MSDN) Library (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iisref/html/psdk/asp/apro1cms.asp).

MetaEdit doesn't always include all the properties in the metabase. Take, for example, the properties for the LMW3SVC subkey. In the metabase, this subkey includes the AnonymousUserName and AnonymousUserPass properties. However, MetaEdit doesn't display the AnonymousUserPass property, supposedly for security reasons. Interestingly, the metabase stores the AnonymousUserPass property's Data value in plain text, and you can use ADSI COM objects to obtain this value.

Accessing Master and Individual Web Sites
Each key and subkey in the metabase has a special association with one or more IIS Web sites. IIS assigns each Web site an instance ID; in the metabase, IIS uses these instance IDs to reference the Web site properties. (These instance IDs are the same IDs that you use to enumerate your log files.) If no instance ID is given, the properties apply across all the Web sites. For example, the LMW3SVCFilters subkey stores state information about the Internet Server API (ISAPI) filters installed across all the Web sites, whereas the LMW3SVC1Filters subkey stores state information about the ISAPI filter installed on the instance 1 Web site.

Understanding Inheritance and Adding Properties
If you look at the LMW3SVC1 subkey, you'll notice that not all the properties defined in the IISWebServer schema are configured. If a property isn't set, it has the same value as the property of the same name in the parent key as long as the parent property is marked with an inheritance flag. This concept is called inheritance. For example, LMW3SVC1 inherits the properties of its parent key LMW3SVC. LMW3SVC has a property called AspAllowSessionState, which has an Inh attribute (aka inheritance attribute). If you set Inh to 1, the sessions are on for all Web sites; if you set Inh to 0, all sessions are off. However, if the AspAllowSessionState property exists in a Web site subkey such as LMW3SVC1 and the Inh attribute is set to the opposite value, the Web site's Inh value of the parent key, overrides the parent's Inh value for this Web site.

If you look in the LMW3SVC1 subkey and AspAllowSessionState doesn't exist, you can add it by right-clicking in the right pane and choosing New DWord. Then, select AspAllowSessionState from the drop-down list. MetaEdit fills the drop-down list with all the possible DWord choices. (You can add a property that isn't defined in the subkey's class, but doing so isn't a good idea because it can cause the metabase to become corrupt.) After you select the property, you need to select the correct User Type and enter the Data value. You can obtain the User Type from the property list in the MSDN Library or from the parent key. If you select the Inherit check box, the children of the key can inherit the property.

MetaEdit-Only Properties
The metabase includes many properties that you can set to perform helpful tasks or customize IIS. Only MetaEdit can set some of these properties. For example, you must use MetaEdit to set the AspThreadGateEnabled, Realm, AspRequestQueueMax, AspTrackThreadingModel, and AspQueueConnectionTestTime properties.

AspThreadGateEnabled. The AspThreadGateEnabled property controls the number of threads that IIS uses under a particular CPU load. This property is available only in Win2K and is accessible only through MetaEdit. When processor usage drops below 50 percent, threads might be blocked (e.g., because the processor is waiting for an external database to return the results of a query) or the load might be light. If requests are pending, IIS 5.0 can increase the number of active threads so that other requests can be serviced in a timely manner. When processor usage exceeds 80 percent, which indicates a heavy load, IIS 5.0 deactivates threads to reduce the amount of context switching.

By default, the AspThreadGateEnabled property is disabled. To enable it, you need to add a Boolean property called AspThreadGateEnabled and set its Data value to True. After you've enabled the AspThreadGateEnabled property, you can set the low and high CPU numbers to make fine adjustments to the thread usage. By default, the AspThreadGateEnabled property's lower value is 50 percent and the upper value is 80 percent. You can change these defaults by adding the AspThreadGateLoadLow and AspThreadGateLoadHigh properties. These two properties must be in the same subkey as the AspThreadGateEnabled property, which you can set in the LMW3SVC or LMW3SVC1 subkey.

Realm. In Windows .NET Server (Win.NET Server) 2003 and IIS 5.1, you can change the name of the realm that the logon dialog box displays during Basic authentication. You simply add a String property called Realm in the LMW3SVC or LMW3SVC1 subkey. Enter the custom realm name (e.g., Wayne's World) in the Realm property's Data value.

AspRequestQueueMax. By default, the maximum number of concurrent ASP requests is 500. If the maximum is reached, the Web server produces an error such as HTTP 500 Server Too Busy. To change this default, you can add a DWord property called AspRequestQueueMax. Don't increase the number too high, though—the CPU and other system resources might become flooded.

The Web service setting for the AspRequestQueueMax property is applicable to all in-process and pooled out-of-process application nodes at all levels. IIS ignores metabase settings at the LMW3SVC or LMW3SVC1 subkey levels for in-process and pooled out-of-process applications. However, IIS uses settings at these levels if the node is an isolated out-of-process application.

AspTrackThreadingModel. You can change metabase properties to debug ASP applications. If you create a Boolean property called AspTrackThreadingModel and set its Data value to 1, ASP tracks the threading model of the COM objects created within that ASP page. This tracking significantly slows the server, so you shouldn't add this property on production servers. However, when you're debugging applications, setting this property can help determine whether the COM objects have a threading problem.

AspQueueConnectionTestTime. The AspQueueConnectionTestTime property specifies how often ASP checks the pending requests in the ASP queue to determine whether the client disconnected before the request finished. By default, ASP checks every 3 seconds. In Win2K, you can add AspQueueConnectionTestTime (a DWord property) to change this default to the number of seconds you want. Decreasing this number creates extra work for the server. However, the server will quickly disconnect old connections, which conserves resources. Decreasing this number is especially helpful for ASP pages that take a long time to be generated.

If you request a page with ASP buffering off, the browser typically returns that page with the data broken down into HTTP 1.1 transfer-encoding chunks. As a result, the HTML appears in pieces, like streamed HTML. If you don't want this situation to occur, you can add a Boolean property called AspEnableChunkedEncoding in either the LMW3SVC or LMW3SVC1 subkey. Enter False for the Data value.

A Helpful Tool
Administering IIS typically involves making changes to the metabase to optimize performance and security. Some changes can't be made with ISM. However, you can make them with MetaEdit.