Do you find the Support WebCast transcripts helpful?
Let us know!

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Bill Staples: It's pretty exciting to come and talk about Microsoft® IIS 6.0. This product has been in development for almost three years now, and the architecture and design for it even longer. So it's been a long time coming, and now that we're finally wrapping it up and getting ready to deliver it, it's good to come talk about what it is and how you can get there. Today we're going to have an overview of IIS 6.0 and the key features, and we'll talk about important implications as you design and build your ISS implementation and migrate to the new version of IIS.

The agenda (slide 2) is as follows: We'll have the overview and then we'll go over the reliability, security, performance, and management improvements in the product. We'll talk about some of the considerations you need to make, and I'll point you to some resources. Then we'll follow it up with as much Q&A as we can fit in the time allowed.

One of the most important changes in IIS 6.0 is a new architecture for hosting and isolating applications. We did this primarily for reliability reasons (slide 3), although it does have some great performance and security benefits as well. Our primary goal was to completely isolate applications from the rest of the Web server to prevent rogue applications from affecting the IIS service as a whole, and also to prevent applications from hurting one another. To do this, we essentially split out the Web service functionality, which was primarily hosted in INETINFO in previous versions of IIS, into three separate components.

The first is HTTP.sys, which is a new kernel-mode listener and request router. This kernel-mode driver listens on the network for requests, accepts them, and queues them. When the application actually generates a response, it then can cache them and send them on. We'll be talking a little bit more about those features in a minute.

W3SVC, the Web service, contains the logic that configures the HTTP.sys driver, as well as configures and manages the processes that host Web applications. One thing to note is that no application code can run in either W3SVC or HTTP.sys. This means that no application code can prevent those services from running.

The W3Core is where Web applications are loaded. More specifically, this is where ISAPI extensions and filters are loaded, including ASP and ASP.NET.

Multiple W3Core .dll files can be loaded into W3WP.exe files. The process model can take one of two forms. The default is what we term the worker process isolation mode, and the most compatible (and the upgrade path) is called the IIS 5.0 isolation mode.

To show what that looks like, let's first recap what IIS 5.0 architecture looks like (slide 4). This screen is a diagram of the IIS 5.0 process model. Requests were routed up to IIS through Winsock. INETINFO was the master process in which many things ran: FTP, SMTP, and NNTP services, in addition to the Web features, but also the metabase, which is the IIS configuration store, and the W3SVC.

If you run IIS 4.0 or IIS 5.0 today, you'll note that you can run in a low isolation mode or an in-process isolation mode, which means your applications are running inside that INETINFO process. One of the implications of this is that if the application does experience problems, if it hangs or leaks memory or other random problems, it can affect the entire service, because INETINFO is that master process. If you run in pooled, medium isolation, or high isolation mode, with IIS 5.0 we created DLLHOST processes to host the applications. These work pretty well, and in IIS 5.0 you can create one pooled out-of-process application and host multiple applications in it. The rest, the high isolation mode applications, run in their own DLLHOST. ASP.NET introduced its own worker process, the ASPNET_WP.exe, which hosted all ASP.NET applications.

This architecture, as you can see, is a bit confusing. It means that if I have an application that's composed of ASP.NET, ASP pages, and hosted in either a high or a medium isolation pool, as well as static content, all three of those different pieces of my application are served from different processes. This can sometimes lead to some inconsistencies in the behavior of your application, where maybe the static content will still work. You'll still get responses for static requests, but ASP pages will hang, or ASP.NET will somehow go away.

The next slide (slide 5) shows the IIS 6.0 worker process isolation mode. This is how applications are intended to run with the new process model. Now instead of Winsock receiving requests from the network, HTTP.sys receives the requests in the kernel. It can route requests directly to the application, the worker process W3WP.exe, that's hosting your application code. This includes all of the application code within the defined URL namespace: static content, ASP pages, and ASP.NET pages as well, anything in that URL namespace.

The dotted lines around the W3WP.exe files are application pools. This is a concept similar to the medium isolation in IIS 5.0, where you could have a pool of applications. In IIS 6.0 you can now have multiple application pools. You can create as many of those as you want, and you can host one or many applications in a single pool. The application pool is the container on which you could find some of the run-time characteristics for your application. We'll get into some of the things you can configure in just a minute.

W3SVC runs inside of Svchost.exe. Again, this is where the configuration management as well as process management occurs. INETINFO is still around, and it still runs the FTP, SMTP, and NNTP services, as well as the metabase.

I told you that you can configure a lot of the runtime settings for your application on the application pool container. We're going to go through some of those now.

The application pool (slide 6) is the boundary that you define to contain applications. You can configure your applications to run in one or multiple worker processes, called Web gardens. Each worker process, or W3WP.exe, serves only one pool. You can use these pools to isolate your applications based on the sites, if you're hosting a number of sites or customers on a single box, based on the functionality. For example, if you have an application built from legacy ASP or COM components that you've had for several years, you could put those in one application pool and put some of the newer ASP.NET and managed code applications in a second pool to make sure that there wasn't any effect on those different types of applications. You could also run them in a single pool.

We've also seen customers create application pools to create isolation boundaries for reliability reasons. If you know that one specific application that you received from a vendor, or from someone who's no longer with the company, and that application has reliability issues and needs to be recycled or restarted regularly, you could isolate it from the rest of the applications and ensure that it's well contained.

One of the most important things you can configure on the application pool boundary is the periodic process recycling (slide 7). Recycling is not a very new concept. Many customers we've talked to use the Iisreset command that came with Windows® 2000 to periodically recycle the IIS service. Unfortunately, that had a pretty negative effect on the IIS service itself. It means that the service was shut down completely and then restarted. If you're running in a production environment, that's obviously not good, because it means that during the time that the service is restarting, customers making requests are rejected. Some customers we talked to do this every day, and in fact even several times a day.

We wanted to provide something in IIS 6.0 that did this a little more elegantly and provided you with the option to restart applications without having an affect on the service uptime. The way we did this was to use the new architecture to allow processes or applications hosted within your process to be recycled, and during that recycling to continue to accept requests in HTTP.sys and queue them until the application comes back online.

You can configure applications to be recycled based on the uptime of the application, based on the number of requests it served, based on the schedule, and based on the amount of memory it's using — virtual memory as well as private bytes. You can also, of course, recycle applications on demand.

Of the effects that you should be aware of when configuring applications to be recycled or when recycling them is that for any in-process state, for example, session state, if you're storing it in-process or in a cache, any cached data for the application will be lost on recycle.

The other issue to note is that during a recycle multi-instance issues could occur. If your application, for example, writes to a file on disk, or takes a lock on some resource exclusively, during a recycle we allow the existing application that's running to continue to serve the requests it has accepted as it drains off those requests, so that the new instance of the application can begin accepting new requests. That means that during that transitional period there could be two W3WP.exe files serving your application. This is called an overlapped recycle. You can configure around it. There is the ability to configure a non-overlapped recycle, which means we will signal the current W3WP.exe to shut down. As it drains requests, we wait. As soon as it has completed all the requests, we shut it down and start up a new one. But the default is for that overlapped recycle behavior.

Another key aspect of the application pool that you can configure is the self-healing architecture (slide 8). This includes health pinging, which means we ping the worker processes that are hosting applications to see if there are threads available to service requests. If we detect that there are no available threads, we can shut down the process, and it will be automatically restarted.

There is optional behavior that can be configured to allow processes to be orphaned or set aside and hooked up to a debugger while a new worker process is started to service the application. One reason you'd want to do this is, if you see this happening regularly on your application you can set it aside so that a developer can debug it later at his convenience. In the meantime it's nice to have a new worker process started to continue servicing requests so the application uptime isn't affected.

Another feature that can be configured on the application pools is the rapid-fail protection feature (slide 9). This allows you to configure the amount of time that IIS should restart an application, should it fail. If the application is crashing, you may not want it to be continually restarted over a period of time because it is possibly thrashing the box. You can configure the number of failure retries we should attempt for your application within a given period of time. Note that if this threshold is exceeded we will turn off the application pool, stop it essentially, and any further requests for that application will receive a 503 response, or service unavailable, until the application pool is restarted.

Let's talk about some of the effects this may have on your applications and the considerations you should take in designing your applications (slide 10). One thing we strongly recommend is that you design your application to be recycled. Web applications, typically, are meant to be long-running applications — a service that runs over days, weeks, and even months. Over that period of time it's very likely that the application will need to be recycled, if not for reliability reasons for the application, then possibly for patching and other reasons. Take into account that any session state or caching should be persisted outside of your application process. For ASP.NET, this is pretty easy. ASP.NET ships an external session state service, which can be turned on and configured to either store state in a separate process or on a remote SQL Server™ computer.

Another issue to be aware of is that it's now possible for your application to be loaded into multiple worker processes. This means that if your application is writing to a single file or reading from a file, if it's taking an exclusive lock on a resource, then multiple applications taking that resource could deadlock and lock the application. We talked about recycling behavior and how to configure around that, but it is an issue to be aware of.

In addition, there are a number of changed IIS 5.0 behaviors that no longer apply in the IIS 6.0 worker process isolation mode. The first is that the worker processes no longer run as LocalSystem. We'll talk about how to configure this in a minute, but by default IIS runs applications as NetworkService, a much lower privileged account.

In addition, COM+ out-of-process support is no longer available for the out-of-process applications. There is no COM+ package created for the highly isolated or the medium isolated application pool. If you were relying on that behavior, it is best to go back to the IIS 5.0 isolation mode.

Global data filters are also an issue, in that they can no longer be global. If multiple application pools are created, those filters are loaded multiple times in each worker process.

I did mention at the start that the new IIS process model can be configured to run in a very compatible fashion with IIS 5.0, the IIS 5.0 isolation mode. This loads the W3Core back into INETINFO, the same as IIS 5.0, and it does allow for that same IIS 5.0 isolation model with DLLHOSTs for medium and highly isolated applications.

Let's talk about security for IIS 6.0 (slide 11). Security was a pretty important focus for us, obviously. We learned a lot of lessons last year, following Code Red and Nimda, and how to protect our customers from seeing those kinds of things in the future.

One of the biggest changes is that IIS is no longer installed by default on Windows .NET Server. This does apply to all server SKUs, with the exception of Small Business Server and the Web Edition of Windows .NET Server 2003. To get IIS you'll need to install it using the Configure Your Server Wizard, in which case it's under the Application server role, which does allow you to install ASP.NET and the FrontPage® Server Extensions in the same wizard, although they're not enabled by default. Or you can install it through Add/Remove Windows Components in Control Panel.

One consideration to make is that if you're upgrading from Windows 2000, you have IIS installed, and you haven't run the IIS Lockdown Tool yet, the W3SVC will be disabled on upgrade. If we detect that you ran the IIS Lockdown Tool, the W3SVC will be left enabled. We did this to protect customers who are running non-IIS servers — that is, file and print servers or domain controllers — who didn't realize that Windows 2000 had IIS installed by default, and therefore they had it still running.

Another set of security features that you should be aware of in IIS 6.0, that could potentially affect your application, is the restriction list. The restriction list (slide 12) is a new feature in IIS 6.0 that allows you to define exactly which features are allowed to run on your server. This is configured on a per binary basis, and you can define and enable single binaries to be allowed or prohibited on your server.

No functionality in IIS is enabled by default. This includes ASP, server side includes, ASP.NET, and so on. Any requests for an extension that has not been enabled will return a 404 response; that's a common "File not found," which is what it looks like to the client. This was done so that hackers attempting to determine what kinds of features were enabled on the server would not receive a response that indicated, in a way to them, what might be enabled and what might be accessible for them to hack, versus what was turned off. If you look in the W3C log file you'll see the extension .2. 404.2 means that the request was prohibited because of this restriction list. This can help in troubleshooting 404 responses for your customers.

The MMC snap-in that you see pictured here has a new node in it called the Web Service Extensions node. This is where you click to configure the restriction list. Another new security feature in IIS 6.0 is to serve only file requests with known extensions. We get the known extensions list on the MIMEMAP list. If you go into the MMC, into MIME Type Properties, any MIME types listed there are allowed to be served on the server. Any extension not on that list will be rejected. Clients, again, will receive a 404 response, a "File not found." In the log file you'll see a .3 extension, indicating that it was rejected because the extension was not found in the known extensions list.

One effect this has, which we're aware of with Visual Studio® .NET customers, is that Visual Studio relies on the .tmp extension to be serviced when it interacts with FrontPage to create and publish applications. To make this work we recommend that you add the .tmp files if you're publishing to a server from Visual Studio. It is not there by default. The Visual Studio .NET team does plan to fix this in Service Pack 1 for Visual Studio.

Another security feature that I alluded to earlier is the fact that IIS 6.0 no longer runs applications as LocalSystem by default. The new default is NetworkService (slide 13), which is a much lower privileged account and is a safer account for running applications. You can change the identity under which applications run back to LocalSystem if your application relies on that, or on a specific, configured identity.

To specify a user account under which to run your application you'll need to do a couple of things. First you'll need to add that account to the IIS_WPG group. This group was created so that common or shared resources for IIS can be accessed by your new identity. If you fail to perform this step, all requests for that application will receive a 503 response.

There are a couple of other things to be aware of. If you choose to use the new Passport authentication feature included with IIS 6.0, the application will need to run as LocalSystem. In addition, if you're using Kerberos authentication and you have a custom or a configured worker process identity, you may need to add a Service Principal Name (SPN) to Active Directory® for the clients to receive a Kerberos ticket as they authenticate to your application.

Another security change in IIS 6.0 is that the sub-authentication feature was removed (slide 14). Sub-authentication was a feature that allowed IIS to control passwords in previous versions of IIS. This meant that if your IUSR or your IWAM password expired, IIS could automatically override that and impersonate that user for you. This was a security hole, obviously, that IIS could override passwords. We removed this feature by default. The effect is that the IWAM and IUSR accounts may have expired passwords and will need to be reset.

Another change we made was to restrict the maximum length of URLs that can be requested from the server, obviously preventing some of the more gratuitous buffer overruns that relied on long URLs. The new limit is 16 KB, and there are more restrictive parsing rules for accepting a request.

There are no virtual directories created on the server by default that have execute-and-write permissions, a change from previous versions. The \Scripts directory is no longer there. A new change for the server itself is that all command-line tools found in the System32 directory are ACL-ed to allow administrators only. This may affect CGI applications, for example, that rely on Cmd.exe to run.

What are our recommendations around security (slide 15)? That's a very common question. The first recommendation is that customers perform a clean install versus an upgrade. With an upgrade we try to create the best balance between maintaining compatibility and keeping your applications running after the upgrade and security. With the clean install, we very much favor security. As we've talked about, IIS 6.0 is locked down. Clean install is the right way to go. There is no lockdown tool for IIS 6.0 upgrades yet; that's a work in progress that we will target for launch time.

We also recommend that you only enable the features, after you've done your clean install, that are vital to the application itself. Prohibit everything else that is not used by the application. This reduces the attack surface available for hackers to compromise your server.

We also recommend regularly checking the IIS hit logs and the HTTPERR log. The HTTPERR log is a separate log also found in the log files directory. But HTTP.sys, the kernel-mode driver I talked about earlier, logs to errors (when it encounters errors) that are not yet applicable to a specific application.

Performance in IIS 6.0 is greatly improved. This slide (slide 16) is a nice chart showing some great numbers, but one thing I always recommend to customers is that you look for what other customers say about the product. One of the most exciting things about IIS 6.0 is working with a number of prerelease customers deploying IIS 6.0 in production, going back almost a year now. There are a number of high-profile customers on public record running IIS 6.0 already, including Nasdaq, Microsoft.com, and others. There are public hosting offerings from Interland, one of the major ISPs in the United States, as well as Schlund and One-2-One, European hosts that are already offering in-production public hosting services on IIS 6.0.

In addition to the numerous security and reliability benefits we've already talked about, performance has been a key benefit. Look for not only the things I'm telling you about today, but as we get closer to launch, look for case studies and other things that customers are saying about IIS 6.0 to validate the things I'm talking about today.

One of the reasons performance is so good in IIS 6.0 is that the new HTTP.sys kernel-mode driver can cache responses (slide 17). This means the cached content can be served straight from the kernel without any user-mode transitions. One of the implications, obviously, is the application will not see requests that are served from the cache.

All static files are cached by default, although there is a smart caching algorithm that looks for more than one request within a given time period before the kernel-mode cache is actually used, to avoid over-caching a lot of infrequently used content.

One of the best ways to control a cache is to use the "Expires" header, which can be set on a per-response basis that determines staleness, the time-out period for a response. This kernel-mode caching is available to ASP.NET customers. You can use the OutputCache directive, specifying the Location="Server" to mark a response as cachable by the kernel. Again, use the "Expires" header to specify when the time-out for that response should occur. This can vastly improve performance for ASP.NET applications that are returning a set of content or a set of data that does not change frequently. Even if you're using, for example, data that does not update within a matter of seconds, like 10 seconds or 30 seconds, marking that as cachable by the kernel will have a great effect on your performance.

Another new feature in IIS 6.0 is the ability to use the capacity planning and tracing tools to determine where resources on your machine are being spent most of the time (slide 18). One of our internal customers runs the http://www.microsoft.com/ site and uses this feature daily to track which pages are using the most CPU on their machines. This is available as part of the event tracing for Windows. There are a number of tools in the box. This will be fully documented in the resource kit as well. It will be available at launch time, or within 90 days of launch. It essentially allows you to turn on tracing for every request on the system that comes through IIS. We log start and stop events throughout the entire request processing, including start and stop events in the HTTP.sys driver, for each ISAPI and for each ASP and ASP.NET page.

A few other features that affect performance in IIS 6.0, including Web gardens (slide 19), a feature I mentioned earlier, which allow you to run your application in multiple processes. When you configure your application pool to do this, connections are round-robined through the garden, each connection taking turns through the number of processes you configured for the Web garden. Web gardens can be used to multi-instance an application, and it will improve performance on applications that have software bottlenecks — for example, long-running database queries — to allow multiple instances of the application to run and service requests.

Another feature that can be turned on is processor affinitization. This allows you to bind a worker process to one or more CPUs. This is especially beneficial on large multiprocessor machines — so 8 or 16 processor machines, or even higher — where you can take advantage of the affinitization feature to silo an application onto one or more processes. In that case we do recommend that you affinitize based on the multiprocessor architecture, affinitizing the applications to the CPUs on the same pod.

One implication to be aware of: recycling on Web gardens does occur simultaneously on the schedule and on an on-demand basis. For memory-based recycling, it is on a per-worker process basis.

Another feature to be aware of in considerations around performance is the idle timeout feature (slide 20). This allows you to configure an application to time out and automatically shut down if it is idle for a certain period of time. This means there are more resources available to the system and other applications. By default, idle time-out is enabled. This means that after an elapsed period of time, the applications are automatically shut down.

Note that applications are only started when there is a queued request for the application. If there are no requests for an application, IIS does not start the application at all. You may consider disabling idle timeout if the application startup does take a noticeable period of time or if there's considerable lag in the first request being served.

There are quite a few manageability improvements with IIS 6.0 as well, the first one being a new storage format for the configuration data (slide 21). As you know, in previous versions of IIS the Metabase.bin file was a binary file that was inaccessible for the most part. There were a few ways to configure IIS in the past, including the UI and the ADSI scripting object, but otherwise there was no way to get directly at the configuration data. In IIS 6.0 the configuration data is now stored in XML, and there are some great new features like autoversioning of the Metabase.xml files for each saved copy of the metabase.

We do support editing that file directly to make configuration changes while IIS is running. By default, this edit-while-running feature is not enabled, and you'll need to turn it on either in the UI or by shutting down the IIS service, editing the configuration file, and then restarting the service. Any editor that can read XML can be used, including Notepad or PERL, in addition to Visual Studio and other XML-aware tools.

Note that this feature is targeted toward the more advanced user. It's probably easier for most customers to use the UI or ADSI, but it is completely supported and has been quite beneficial to a number of customers.

If you see a Metabase.bin file in the INETSRV directory, it is only there as a legacy file for backup applications that are sometimes dependent on it. It does not contain any useful configuration data.

One new feature with the XML metabase is the ability to import and export configuration for your application (slide 22). This can be done on any node of the metabase. The nodes translate, obviously, to the W3SVC down through sites and virtual directories. There are options with the export and import that allow you to specify whether inherited properties should be exported for the application, whether the entire node or the entire tree should be exported or imported, as well an option to specify a password to encrypt any sensitive information, like passwords and other data.

With ASP.NET we recommend that to enable XCOPY deployment on your development machine, take your ASP.NET files and Web.config files, but also export the metabase node that translates to the virtual directory or site that your application lives in, and then pass that along to the production server. There it can be imported, and the IIS configuration data can be maintained.

Another new management feature in IIS 6.0 is a WMI Provider for WMI support. This includes the common features of WMI, including query support for using a SQL-like language in your WMI scripting to query collections and other attributes. Associations allow you to associate the IIS WMI information, for example a virtual directory, to a file system class or a disk class. And you can script configuration using the WMI support.

For our command-line support in IIS 6.0 (slide 23) we've leveraged the WMI Provider to provide all of the basic administrative functions for you. These are in the System32 directory. They all begin with IIS, and they are Visual Basic® script samples that you can open and use. You can extend them for custom behaviors or use them as is for all the common administrative functions.

To summarize (slide 26), we talked about a number of improvements in IIS 6.0. We talked about a new architecture that makes it a lot more reliable and performant to run applications. We talked about a number of security changes and security features that will prevent the kinds of Code Red and Nimda issues that we've seen in the past. We talked about a number of management improvements that hopefully will make it easier for you to manage IIS.

There are a number of resources already (slide 27) publicly available on the Web to give you more information about IIS 6.0. There is a feature and benefits overview on TechNet (http://www.microsoft.com/windows.netserver/evaluation/overview/technologies/iis.mspx) that you may want to look at, as well as a technical overview (http://www.microsoft.com/windows.netserver/docs/IISOverview.doc). These guides go into a lot more detail on some of the features I've talked about today. And there will be even more content as we get closer to launch.

Thank you for joining the WebCast today. I'd like to introduce someone else who's joined us for our question-and-answer period. This is Chris Adams, who is with the IIS Support Team. Thank you for coming out, Chris.

Chris Adams: Thank you for having me.

Otto Cate: Before we jump into the Q&A today, I'd like to share a couple of program notes with our audience.

A reminder, the Q&A portion of the Support WebCast is intended to encourage further discussion of the topic today. One-on-one product support issues that require some complex technical assistance are outside the scope of what we're able to address. If you do need some more complex technical assistance, please submit an incident on the Web or contact Product Support Services directly by phone.

The first question we have: Will there be a desktop/non-server version of IIS 6.0 available for development efforts?

Bill: That's a great question, and it's one we hear quite often. Right now we're focusing on delivering IIS 6.0 for servers in the Windows .NET Server 2003 launch, and I see there are a number of questions about when that will be. That is still targeted at first quarter of next year. It will be available for all server releases of Windows .NET Server 2003. This includes, as I mentioned, a Web edition, which is a low-priced edition targeted at standalone Web servers as well as development servers. There is no download version of IIS 6.0 currently planned for Windows 2000 or Windows XP customers, although that is something that we heard a number of requests for and are that we are considering.

Otto: Because ISAPI filters run in the application pools, does this imply that a failure of the filter in one application pool will not bring down all the other sites in the other application pools? Is that accurate?

Bill: That's correct. That's one of the primary reasons we're defining the application pools, is to define the process boundary in which application code, including ISAPI filters, can be isolated, such that any errors or any conditions that may affect the application do not affect other applications on the box.

Otto: Do you have an overall recommendation on the maximum number of application pools that should be held on one Web server?

Bill: Another great question. That really does come down to the type of applications you're running and the resources that they may require. It's really dependent on what you are running on the box. There is a certain amount of memory that's consumed by each worker process that loads, and the basic binaries we depend on. If you're loading ASP.NET, obviously the ASP.NET and the CLR take up some memory and some CPU time as well. We've tested up to 2,000 worker processes running simultaneously on the machine. Your mileage may vary, depending on the type of application you're running.

Otto: Can the periodic process recycling be configured per application pool or does it apply to the entire application pool?

Bill: Periodic recycling is configured on the application pool level. You can create as many application pools as you wish. Application pool is the boundary where those kinds of run-time configurations occur, including, for example, recycling. If you have multiple applications, you can create multiple application pools for them and then configure the recycling to happen independently. I hope that answers your question.

Chris: Let me add one other thing that often confuses customers going from IIS 5.0 to IIS 6.0. The application pool is configurable per application. The catch is that by default there's only one pool, the default application pool. In the real world customers can have a development environment as well as a production environment. You will have pools for each one of those. Each one of those can have different and varying numbers, as Bill said.

If you're running development code you would probably want to extend the amount of recycling time to make sure that you're not masking any potential problems in the development code, as opposed to a production site, which you would want to keep up and running as long as you possibly could. By doing that you would drive those numbers down to keep from hindering your performance.

Otto: Will the ping from the self-healing architecture show up in the logs?

Bill: Yes. When threads are deadlocked or there are no available threads for accepting requests, or when ASP or ASP.NET detects that their thread pools are hindered, IIS does shut down that worker process and log an event, indicating that that type of failure has occurred. As I mentioned previously, you can also configure IIS to launch a debugger to attach to that worker process if you don't want it shut down. That way it's available later for debugging.

Otto: It appears that the Web service extension interface applies to the entire Web server. Is this correct? There's a follow up here: Is there a way to configure the Web service extensions per Web site rather than the entire Web server?

Bill: Web service extensions is a global setting for the entire server. The thinking there is that we want it to be really easy and obvious for customers to know what is enabled on the server, what binaries are allowed to load and run on the server. We've heard the requests. I appreciate the feedback, that you may like it a little more granular than that. For IIS 6.0 this is a global setting, and there's one place you go to see what binaries are allowed to run on the server.

Otto: Can you add and remove items from these two lists (Exclude and MIMEMAP)?

Chris: I know part of the answer, to the MIMEMAP. That is a configurable list, if that's what they're talking about. By default, in the IIS 5.0 and the IIS 4.0 world, we delivered just the raw contents of the file, similar to static, when we didn't have a known file type. This is as opposed to IIS 6.0, where our behavior is to deliver, I believe, a 404 error if we do not have it in our configurable MIME list. I think what they're asking is, can we remove that and add to it on the MIME? For the exclusion, I don't know.

Bill: Perhaps he's referring to the Web Service Extensions, what we just talked about, where you define which binaries are enabled on the server. You can add and remove from that list as well as the MIME type list.

Otto: Thank you for the clarification. If we have not run the lockdown tool before, will we need to run it after the upgrade to enable W3SVC?

Bill: No, you will not. The only thing we do there is mark the W3SVC startup type as disabled. You can select Services, then select Management in Control Panel and set it back to Automatic or Manual, whatever you prefer. It will restart just as before. We recommend running the lockdown tool before the upgrade if you haven't done so, so that you ensure that the server is as locked down and as secure as it can be.

Otto: Does the HTTP.sys caching still log the hits?

Bill: Yes, it does. By default logging does occur in HTTP.sys, and it logs all requests, including cached responses.

Otto: This looks like it's a similar question, perhaps they're looking for a little more detail. The question is: How will Web statistic packages handle hits properly if HTTP.sys intercepts the request even before it hits the Web site? And how are those hits handled in the Web site logs?

Bill: They are all logged, just as before. Even cached responses will appear in the log just as before, as they normally would. There's just a difference in the way the requests are handled. Essentially, any user-mode processing is bypassed, and the response is returned straight from the kernel for performance reasons. But logging is not affected.

I will take the opportunity to note that there is a new method of logging in IIS 6.0 that wasn't there before. This is binary logging. There's a new binary format that you can log to, and it's a single file for all sites on the server, whereas before there was a log file per site. This is for performance reasons. If you're very concerned about performance, then there's this new log file format. We will also provide an export and query tool for it.

Otto: Why won't your application see requests from the cache?

Bill: I think we were talking about the kernel-mode cache on that as well. The HTTP.sys driver, when it accepts a request for a URL that has been cached, does not notify the application that a request has been made. Instead it looks up the response in its cache and sends that response directly back to the customer. Again, it does log that request, but it does not pass a notification to the application that a request has been made.

One thing to note, one reason you may expect the application to be notified is an instance where you're running an ISAPI filter to somehow modify each incoming request or response as it comes in and is being sent out. If you're running an ISAPI filter, the kernel-mode cache in that application, for that application pool, is disabled. You can mark an ISAPI filter as "cache aware" and continue caching in the kernel, but by default if you add an ISAPI filter to an application pool, the kernel-mode cache is disabled. Therefore every request would be accepted by the application.

Otto: Will IIS 6.0 be available for Windows 2000 Server or Windows 2000 Advanced Server as an upgrade, or is it only going to be available with Windows .NET Server 2003?

Bill: For now it will only available through Windows .NET Server 2003, which, as I mentioned, will be available early next year. It's still planned for Q1 of next year. There are currently no plans to have it available for earlier platforms, Windows XP or Windows 2000. Although that is a request we hear quite often. Thank you.

Otto: Where will all of the new logging that allows tracing be kept? Is this going to be Access.log, or is it going to be somewhere else?

Bill: It's actually a binary log file, and when you start the tracing you can specify where you want the log file to be placed. This is kind of a "fire hose" type of approach where, as I mentioned, with every request there are a number of events that are logged per request. You'll want to specify a disk that has a lot of available space on it.

Otto: Is IIS URLScan recommended for version 6.0?

Chris: It actually isn't available at this time, and Bill can speak to its future capabilities, but a lot of this functionality has been built into the kernel-mode driver as well as into some other features. I think most of it is the fact that it's HTTP.sys, but Bill can add to what our future may be.

Bill: Actually, there is nothing preventing it from running in IIS 6.0 today. In fact, it will be supported on IIS 6.0 going forward. Pretty much all of the capabilities of URLScan, with the exception of a few, are already baked into IIS 6.0, and we believe IIS 6.0 provides a better and easier way to manage those features. For example, the extension restriction list that we talked about, as well as the known extensions controlled through the MIMEMAP, those cover the bulk of functionality that URLScan was built for. And they do it in a way that's baked right into the Web service itself. However, as I mentioned, nothing is stopping you from running URLScan on IIS 6.0, and it will continue to be available for those needs.

Otto: What is an application pod?

Bill: When I referred to "pod" I was talking about the hardware architecture on large multiprocessor machines, in which they divide the bus on the machine into sections. For example, on an 8-processor machine quite typically there will be two pods of four processors each. There is an I/O bus between them. If you are affinitizing application pools to processors, you'll want to affinitize the application to processors on the same pod for the best performance. I hope that clarifies the question.

Otto: Can you speak to IIS 6.0 and cluster support?

Bill: Sure. There are a number of different types of clustering support. If you're referring to the built-in Microsoft clustering support, previously called Wolfpack clustering or fail-over clustering, this is still available in IIS 6.0/Windows .NET Server 2003, with one change. Previously in Windows 2000 you could fail over individual sites. With IIS 6.0/Windows .NET Server 2003 this is only available for the entire W3SVC. This was done because of the new fail-over and reliability features for applications in IIS 6.0, with the new architecture.

If you're talking about NLB clustering or load balance clustering, Windows load balancing services, those kinds of things — yes, obviously they are supported as well. It's a very common configuration for customers to run IIS servers under.

There are also some new features in IIS 6.0 that allow it to be a little more intelligent about how it interacts with those kinds of load balancers. You can configure IIS to behave in slightly different ways, depending on whether you have a level-seven load balancer or an NLB-style load balancer. IIS can return TCP disconnects for load balancers that are not as intelligent about HTTP error codes and need a TCP reset to indicate that the application is no longer available. You can also configure it to return 503s and other HTTP error codes so that the more intelligent level seven load balancers will know that the application is offline, and therefore stop routing requests for that application to that node. Documentation on how to get that feature to work is available in the core documents for IIS. Just search for "load balancers."

Chris: I can add one other thing, coming from a support standpoint, regarding Microsoft Clustering Services. One of the issues you might be concerned with is the Iissync utility, which is to replicate the metabase configuration between the nodes. It has been ported over to a VBScript file, and I was hoping that Bill would talk longer so I could actually find that. I don't know the name of it.

Bill: It's Iiscnfg.

Chris: Iiscnfg.vbs. That functionality has been ported over to that file, and I know that for many customers on IIS 5.0 and IIS 4.0 who were running clustering services, it was a painful process to troubleshoot that executable. So let me add that.

Otto: Thank you for the extra information. What tools will be available to help us in the migration from an IIS 5.0 to an IIS 6.0 environment when we've performed a clean install of version 6.0?

Bill: We do have an IIS 4.0 and IIS 5.0 to IIS 6.0 migration tool in development. We plan on releasing it to the Web at around launch time. It's entering a beta test phase right now.

Otto: Just a clarification on compatibility: Will Application Center 2000 work on the Web server-only version of .NET?

Bill: Application Center 2000 is supported for all server SKUs. I believe it does require their Service Pack 2, which I believe is in beta right now. They plan on releasing that on or around launch as well. Application Center will be supported with Windows .NET Server 2003 and IIS 6.0.

Otto: Did I read correctly that the Web server version of IIS 6.0 will not support Terminal Services? If not, can I at least manage it the way that I do with Windows XP Remote Desktop? I'm currently the only user, but I manage about 20 .NET sites through remote access.

Bill: That's a good question. I believe the question is, "Can I remotely manage my Web server SKU — Windows .NET Server 2003 Web Edition server." I'm not 100 percent confident on this, but I am pretty sure that the answer is yes, you can connect using the Remote Desktop feature. I think that when they say Terminal Services isn't supported, that means that you cannot install Terminal Server features to allow multiple clients to connect and use the Web server as a desktop.

Chris: In the application mode, as opposed to the remote administration mode in Terminal Services.

Bill: Exactly.

Otto: What's required to query WMI with third-party applications, as far as permissions and rights? The customer had some problems querying WMI information using some other third-party tools with servers running Exchange; I'm not sure if that quite applies here.

Bill: If the question is, "What permissions or privileges do you need to query IIS configuration data using WMI," the answer is you must be an administrator. Only administrators can get at IIS configuration data, and that applies to ADSI, to WMI through the UI, or to editing that XML file.

Chris: I don't think that's changed from IIS 4.0 to ISS 5.0 or to ISS 6.0. You still have to be an administrator to query any of that type of data.

Otto: I'd imagine that you could get further support from those third-party tool developers as well, if they're having problems with those tools.

Bill: Correct.

Otto: Okay. How about some debug tools for IIS 6.0 by default? Or will we still use the existing debug tools that are supplied?

Chris: I'll tackle this one and try to give you the best answer I can. Yes, it's a painful spot, unfortunately. In a development platform such as IIS, one of the big concerns is how we are capable of handling debugging situations. At this point I can only say that yes, we're going to continue to use the same tools that we use today, the debugging tools for Windows. And customers who are familiar with this know this as AD+.

We do have some future plans to address this and try to hit this concern of customers. But at this point I think that the best IIS 6.0 feature is, as Bill mentioned during his presentation, that you have configurability with your application pools. You can tell the application pool to attach to a debugger. I believe this was in the health monitoring section of the slides. We introduced what we are terming as the orphan state for processes. In the IIS 5.0 and IIS 4.0 world one of the more troublesome issues is that after it's terminated, if a debugger is not attached, it puts the customer, as well as Microsoft, in a tough position — they are unable to perform a debug until they have the debugger actively attached. That orphan state is going to allow us to continue to keep the process or the memory available so that we can attach a debugger and find out what went wrong.

I think the debugging process is improving, and it will continue to improve in the future. I can tell you, from a support standpoint as well as from the IIS product group, that we're definitely concerned with how we can help our customers get better at debugging.

Otto: When we're considering the migration from IIS 5.0 to IIS 6.0, do you recommend starting with clean install versus the upgrade path? What are the pros and cons?

Bill: We do recommend, as I mentioned, going straight to the clean install and then migrating your application code over to the new server. This is for reasons of security, as well as to ensure that any third-party software or other configurations that may have occurred on the existing machine over time, which may affect the health and reliability of your application, aren't brought forward. The migration tool does handle bringing content over to ASP, HTML, and ASP.NET —essentially everything in the Web root that can be brought over. It also handles the configuration that applies to the sites you're migrating. It also performs the FrontPage Server Extensions configuration around the site, if that applies.

There are a few known migration issues that make it a little more complex than this tool can handle. For example, if the application calls into out-of-process COM+ applications or uses COM+ packages, those are not exported and brought across. That will need to be done manually. If the ASP pages reference a DSN for a database connection, for example, that will need to be manually brought across as well, or scripted. The migration tool doesn't handle that. There are some limitations in the migration tool itself.

We're hoping to provide more thorough documentation on the kinds of things it does and what your application may be dependent on that you'll need to make considerations for and/or bring across manually. We recommend starting from clean install and using the tool to migrate over to the new box.

Otto: We've upgraded from Windows 2000 to .NET. They don't specify exactly which release. We're having some problems where the application pool options are not available. Is that a known issue?

Bill: Yes. If they're not available, that probably means you're running in the IIS 5.0 isolation mode that's available for maximum compatibility and that is also the default mode for upgrades. Chris, Do you know if it's on the computer node or on the Web site node? It's one of those two nodes. If you right-click and go to Properties, you'll see a check box that says "Run in IIS 5.0 isolation mode." If that's selected you're running in that mode, and that's why the application pools are not available.

Chris: It should be under the Web site node. Select Properties, and then there's a Service tab. One key thing that I think tuned us into that is that he said an upgrade. Customers, any time you upgrade you need to keep in mind that a conscious decision was made to ensure that when we perform the upgrade we do not introduce a lot of the different architecture changes that we have implemented in IIS 6.0. We go and move up using compatibility mode. That is most likely why you do not see that. After you select that, it will tell you, I believe, that the service needs to be restarted. At that point, after we've cycled the services, you will be in the new isolation mode.

Bill: One thing to note about that switch. If you previously isolated applications in either medium or high isolation, and you make that switch to the new architecture, all applications will be running in the default application pool. Essentially there will be no more isolation between them. You'll need to go in, create new application pools, and then re-isolate the applications as you had them before, if that's indeed what you want.

Otto: A question concerning pool recycling: It was stated during the presentation that pool recycling was added to essentially resolve memory leak issues. Can you go into a little bit more detail on this? I thought that some of the .NET components wouldn't necessarily have memory leak problems.

Bill: The Visual Basic managed code environment does address some of those issues by making it a little harder to not have to deal with pointers and lose objects. That feature is there to help with other code, existing code, using COM or some of the Visual Basic scripting that has traditionally had issues with memory leaks. A lot of the Visual Basic COM .dll files that people built experienced those kinds of issues.

I wanted to clarify that it is not there to take care of IIS infrastructure issues or leaks. We were very careful about testing our own infrastructure code to make sure that we can sustain long-running applications. In fact, we run it for weeks before we sign off on shipping the product to make sure that it can stay up, run, and support a very, very heavy load over a long period of time without recycling. This is to make sure that, if that's the kind of support you need, it's there for you. It is there for handling application errors and application leaks.

Chris: To add to that, we mentioned during the presentation that customers requested to have that ability (which in the past we have been unable to do) during that cycle period, when we were recycling the services. It's not to avoid or to mask leaks. Instead of having the entire service go down, have requests get lost, or have service interruption, we have that ability; we built that gap to have a gray area where we put things until we get back up and running completely. I think it was to address not potential problems, but requests. Because in the support world we do know that a lot of customers use their own implementations of recycling, with the products that we have today. We introduced that because of the customer requests.

Bill: Yes. I can give you an example of one customer we've been working with. They're running in a production environment with a pretty heavy load. Every day they would have to take their IIS 5.0 server out of the cluster, take it offline, and run Iisreset. This was because of some of the COM server .dll files they had in their application that they were troubleshooting, and then put the node back in the cluster. That was, obviously, a very labor-intensive process.

Through this troubleshooting period they deployed IIS 6.0, and they were able to turn on the automatic recycling, which is done automatically by IIS. It doesn't affect service uptime. They no longer had to take nodes out of the cluster. They're actually running those same applications, for which they had to perform such labor-intensive work, over a period of a couple of months without any service interruptions, without ever taking IIS offline. That was a pretty impressive thing for us, and it validated that the work that we did in the real world actually does help.

Otto: This is a follow up to the remote question we had a little earlier: Do you know if I can run Exchange Server on the "light" Web server version of .NET? It looks like he's just trying to make sure he has one machine that can handle all things Web-related.

Bill: Right. I believe the answer to that is no. The Web Server SKU of Windows .NET Server 2003 is targeted at lower-end hardware machines. I think it's limited to two processors, and it's really there for customers who want a standalone, low-cost Web server that is dedicated to just that. It's not licensed for other .NET servers, including Exchange or Commerce Server, those kinds of Microsoft servers.

Otto: If an internal caching appliance is already being used, can server caching be completely disabled?

Bill: Yes, it can.

Otto: Will there be any functionality to help export or import Web server and Web site configuration?

Bill: Absolutely. In the UI, in the MMC snap-in, you can right-click a site or a virtual directory, and one of the tasks that is available is Save to file, which is the friendly name for export. There is a Load from file and a Create a new site. Not only can you import a configuration to a new virtual directory or site, but you can also apply it to an existing one. In addition, there are command-line options, under that Iiscnfg command tool, where you can export and import a configuration from the command line. One thing to note about those command-line tools that I didn't mention before is that they also work on remote servers. If you have admin privileges on a remote server, you can run those from your machine, specify your credentials, and perform all the same activities you would as if the service was local.

Chris: One of the things that customers asked for, and I think we did deliver on, is that in the past our metabases were not capable, as a whole, to be moved from machine to machine. This was a request for IIS 6.0, and this is a feature that you can see in the product. In Windows XP/IIS 5.1 we gave a little bit of an idea of where we were going. If you go to the Web site node and select All Tasks, one of the tasks that you can perform is backup or restore. That functionality was in IIS 5.0. The only catch was that that backup was only good on that machine because the metabase was encrypted with the machine keys of the machine itself.

One of the options that now exists is a check box, and the wording, you'll have to excuse me, is something like, "Make it so it's not secured." Basically remove any of the machine key information and just give me a raw file. That allows customers to move their metabase from one machine to another. Then, as Bill said, you can also do it down to the actual virtual directory or Web site level.

Otto: We have a question that's related to importing the metabase: Re-importing the metabase XML file, is there any way to automate it, or is it a manual process when deploying an application?

Bill: It can be scripted. There are also WMI and ADSI methods to control it. As I said, there are command-line tools as well, so you can script it and automate it in that way.

Otto: Have any changes been made for WebDAV support?

Bill: Not a lot has changed with Web Distributed Authoring and Versioning (WebDAV). It's still there, still available. It is controlled through the Web Service Extensions. You can enable or disable it there. But there are not a lot of feature changes, per se, in the WebDAV provider.

Otto: Is there any advantage to moving IIS administrative scripting over to WMI from ADSI?

Bill: It depends on how you define advantage, I guess. In terms of performance, no, there is no advantage to moving it. In fact, WMI may be even a little bit slower than ADSI is. If you're looking for more cross-platform/cross-service support, so that you can enhance your scripts to not only stop the Web site but also turn off some part of the hardware or control some other piece of software on the machine in the same script, WMI is the Microsoft standard for that kind of thing, for managing all of the Windows services. It's an industry standard for all types of software and hardware devices. There is some advantage there. If you have existing scripts that work for you just fine in ADSI, ADSI is still supported, and it ships in IIS 6.0, and they'll keep on running.

Otto: Are there any provisions for automatically associating an XSL file with XML files in a directory based on browser type? This capability currently exists in SharePoint™ Portal Server, but I was wondering if it may have been extended to IIS.

Bill: No. Unfortunately, that functionality is not in IIS.

Chris: It will probably remain in SharePoint, if it was popular. There will be a new version. This is a question I'm asking across the panel here. For SharePoint, is the existing version supported on IIS 6.0? Do you know?

Bill: I would have to ask the SharePoint team what their support stance is on that. I know it is available for Windows 2000 today, and therefore it should run just fine in the IIS 5.0 isolation mode. I know they're working on a new version for Windows .NET Server. I don't know exactly what their plans are, though.

{Follow-up answer: SharePoint Portal Server is not currently supported on Windows.NET Server 2003.}

Otto: Will tools be available for creating Web usage reports?

Bill: Not in the Windows box. That's not an area we've invested a lot of time in, unfortunately. There are a lot of external resources, external to Microsoft, a lot of freeware and low-cost solutions for that kind of thing. We point customers there as much as we can.

Chris: Log Parser is a tool that will be coming out in the near future. Just keep that name in the back of your mind. It will have the ability to get a lot of what the data is; for example, your most-hit Web pages and how many bytes are being sent. And it's very expandable. However, like he said, Log Parser will not be on the CD and is not version specific, but that is in development and will be released in the future. Keep an eye out for it. I think it's Log Parser 2.0.

Otto: Will the IIS logs indicate whether a hit was served from the cache or from the application pool?

Bill: That's a great question, and I believe the answer is no. There is no indication as to whether they were cached or not. That's something I should look up, and maybe I can post that to the newsgroups. If you're on the public newsgroups, that's a great place to ask that question, and I'll be happy to answer it.

{Follow-up answer: Unfortunately, no. However, the capacity planning and tracing support that was discussed will help determine this.}

Otto: Next question: Are there any built-in objects available to check if a user is a member of an Active Directory group?

Bill: I think that question probably falls outside of the scope of IIS.

Otto: Will socket pooling be disabled or enabled by default in IIS 6.0?

Chris: The disable socket pooling function, which existed in IIS 5.0, is still a metabase key in IIS 6.0. However, its functionality is moot for all intents and purposes, in that it doesn't do anything, mainly because we went away from Winsock in the IIS 5.0 and 4.0 world. In IIS 6.0 we have this kernel-mode listener driver, HTTP.sys. All of that functionality is moved over to HTTP.sys, and that functionality will be configurable using tools that work with that. To answer the question, it's there. But does it play a role? The answer is no.

Otto: If kernel-mode caching is disabled for an application because of an ISAPI filter, does that also disable static caching for that application?

Bill: There is a secondary cache in the worker process that can continue to cache. The kernel-mode caching is the cache that's disabled with ISAPI filters. I hope that answers your question.

Otto: What are the minimum hardware requirements to install IIS 6.0? Is there a public URL we can point them to?

Bill: I believe the hardware requirements are posted on the Windows .NET Server 2003 page. I don't have them offhand. If you go to http://www.microsoft.com/windows.netserver/, I believe it's listed off of there.

Otto: Will IIS 6.0 and ASP.NET allow me to dynamically parse and reroute URL requests, say for using the URLs to identify a magazine's volume, issue, date, article IDs, and so on, without using ISAPI filters?

Bill: Yes, actually. I can speak from the ISAPI side first. There is a new ISAPI service support function that allows you to process a request using the ISAPI and then put the request back in the processing chain for another ISAPI or for continued processing by the worker process. You can use that, for example, to change the URL without having an ISAPI filter and then allow continued processing on the new URL. One thing to note about that, however, is that if you rewrite the URL to be outside of the namespace that the current application pool is serving, you will receive an error. Essentially, if the URL is outside of the current scope of the worker process, it cannot send it back down to the kernel to have it routed to a new application pool. Instead, it will just give an error. You have to be careful about the extent to which you're rewriting URLs and take that into consideration.

Chris: I'm clarifying — from W3WP over, you can't move from one W3WP to another with it wanting to go back to the kernel. The kernel is going to reject that.

Bill: Yes, there are no application pool-to-application pool channels to pass back and forth requests, and there are no rerouting services in the kernel for that either.

Otto: We have a few users who were a bit confused about the Terminal Services situation. For instance: Can you please elaborate on what will or will not be possible with Terminal Services under .NET Server, as it relates to IIS 6.0? The documentation indicates that Terminal Services is supported, but is it not supported in IIS 6.0?

Bill: I probably should go back and check on this. I did notice a comment that says, "Remote Desktop for administration is listed as a feature for .NET Server Web Edition." I believe that is correct. To clarify, I believe it is possible to use Remote Administration to connect to the Web edition and manage it, but you cannot run Terminal Services as an application service to allow multiple users to use that Web edition as a desktop. But we'll be sure to follow up on that question after the event today.

{Follow-up answer: On the Windows .NET Server 2003 Web Edition SKU, it's Terminal Services admin only. There is no Terminal Services Session Directory.}

Otto: Okay. Currently in IIS 5.0 I cannot see ASP queuing per application or site. In IIS 6.0, will I be able to see that queuing per application pool?

Bill: Maybe I can ask a clarifying question there. Are you looking for a performance counter that lists the number of queued requests?

Chris: Yes, it's a common request, when you enable ASP logging or the Active Server Pages Counters object, to have some counters. One is "Request queuing." You can see that value growing. The question that I think that we often are asked regarding IIS 5.0 and IIS 4.0 is, "Okay, I know they're queuing. What is queuing?" Currently, because that happens within Asp.dll, we're unable to tell what's in there. We're only able to tell you that there are requests queuing. I personally don't know the answer in IIS 6.0, but I can venture to say it probably hasn't changed. But I'd have to check it.

{Follow-up answer: Unfortunately no, there are no more granular ASP request queue performance counters available in IIS 6.0.}

Bill: If the question is, "Can I see which actual URLs or requests are queuing," or long-running requests of that sort, that is what that capacity planning tracing feature is for, so that you can trace requests over a given period of time. Then extract the data that shows you which of the URLs are the longest running on the box, or that are consuming the most CPU. Maybe you can get at that information that way. There is no run-time data available to show what requests are in queue, which actual URLs are being queued, although we're looking at some plans for attacking that problem. But there is nothing available yet.

Chris: In capacity tracing, how much overhead is there in a production environment? Are we recommending not doing that in the course of production?

Bill: It can actually be done in production. Microsoft.com, as I mentioned before, does it daily. A couple of considerations: it is a "fire hose" approach and log files grow very quickly when this is turned on, especially in high volume traffic. You'll want to watch the log file size. I believe Microsoft.com turns it on for just 5 or 10 minutes, and that gives them a good enough snapshot to know what's happening over the course of the day. Also, the performance effect is there. I believe it's something around the magnitude of 10 percent or 15 percent.

Otto: Thank you, guys. When I'm configuring Web Service Extensions, do I need to specifically enable all executables for each application? For instance, if an executable calls another that may not specifically be allowed, what would happen in that case?

Bill: For example, if you had a CGI .exe that called another CGI .exe? Is that the question?

In that case I believe the answer is it would work, because the second CGI .exe is a child process of the original one and is not loaded by the IIS worker process. Therefore we wouldn't even see it. You'll want to be careful about what you enable, make sure that the first order executable is the one that you're either enabling or disabling, and therefore trusting or not trusting.

Chris: In that case you would want to build your security into your original of the first CGI .exe.

Otto: Early on you were talking about exporting the specific keys. Is it "Encrypt configuration using password?" Is that the phrase controlling whether specific keys are exported or not?

Chris: Yes. I think they're just referring to the key that you have to use when you're scripting the backup, what the value of that key is, if I understand the question.

Bill: I think he's referring to the text on the dialog that you use when you go to the backup option. To back up, that is indeed, I think, what it says. What that means is when you specify a password, any of the sensitive data like passwords and such will be encrypted using that password, that key you specify. If you do not select that option, we do not back up the metabase in a way that can be restored on a separate machine.

Otto: This is another follow up to the remote versus Terminal Services situation: Because you indicated that the Web Server version of .NET really won't support Exchange, which is actually complete overkill for my needs anyway, what about simple SMTP/POP3 services? Basically I just need to have some Internet mail functionality, and it just has to run on the same box. Does that sound applicable?

Bill: That's a very good question. Unfortunately I don't have the feature list in front of me. If you go to http://www.microsoft.com/windows.netserver/ there is a link to a matrix of all the features that are supported and available on that Web edition. It is worth noting, I think, that there is a new POP3 service to .NET Server 2003. This is not a part of IIS, but it is another part of Windows .NET Server 2003 that is shipped there, and that does support POP3 mailboxes. Of course SMTP is still there as well, so you can run a low-end, simple mail server on server editions. I'm just not positive which ones are supported in that Web edition and which aren't.

Otto: I'm not sure if this is within the scope here, but I'm going to ask it just in case: I've noticed that support for VPN has been limited on the Windows .NET Server 2003 Web Edition. Will this also limit the functionality of running an extranet and WebDAV on this version? Currently we're using Windows 2000 Server and we're looking at an upgrade.

Bill: That is a good question. Unfortunately, I think that falls out of the scope of my knowledge. We'll have to follow up later on that.

{Follow-up answer: On the Windows .NET Server 2003 Web Edition SKU, VPN is limited to one per media type. Yes, it's worth purchasing the standard edition. }

Otto: Overall, what improvements have been made to the indexing engine?

Bill: The indexing engine isn't a part of IIS proper, either. Therefore, I'm not aware of the changes they've made to that technology. I don't believe there are substantial changes there, but that's also something we could follow up on.

{Follow-up answer: Windows .NET is primarily a maintenance release for us. Here is what we added:

• Brand new English, Chinese Simplified, Chinese Traditional, Korean, Thai, and Japanese wordbreakers for faster indexing and more accurate queries. These address many customer requests.
• Complex queries and/or proximity components over large indexes can be over twice as fast.
• Indexing of properties on .mp3, .wma, and other media files.
• Indexing performance fixes, mostly for very large indexes (half a million documents and up).
• Additions to the HTML filter to keep up with the latest encodings and standards.
• Hundreds of bug fixes, more reliability, and security fixes.}

Otto: I know during the presentation you mentioned some high-profile users who are already running IIS 6.0. A couple of users are trying to get the overall feel whether or not it's safe to install a production application in IIS 6.0 RC1.

Bill: Absolutely. If you go to http://www.netcraft.com {Editor's note: This site is external to the Microsoft domain and Microsoft is not responsible for its content}, which is one of the Internet sites that's available to show the market usage of various Web servers, you'll find that there are several thousand customers running IIS 6.0 right now.. We've been supporting production deployments since Beta 3 for many, many customers. We've been through a lot of beta testing over the past year, so we're very confident that it's ready. If you have a preview download or you are a beta customer, you can go to those newsgroups to get some answers and support. Obviously, support is limited through the PSS support channels, but it is available through the preview channels, the preview newsgroups, and beta newsgroups. We're coming up on launch quickly, so it will be available for everyone in just a few months.

Otto: What about the memory improvements of the SMTPSVC? Do you know if that's improved?

Bill: I don't know. That service is also owned by a separate team. We can follow up and see if anything has changed, and we'll post that answer later.

{Follow-up answer: The biggest difference in SMTP from Windows 2000 to Windows .NET is in its DNS client code. It is much faster and resilient.}

Otto: A follow up on that simple POP3 service that appears to be supported in the Web edition: Do you know if it has a Web front-end at all?

Bill: Actually, it does have a Web front-end. I remember going into the Add/Remove Programs and seeing that it did indeed have a Web-based management option. I haven't used it, so I can't speak about how it works or anything else, but I remember seeing it there.

Otto: Okay. That's definitely good to know. There appears to be a new security release regarding MDAC. Do you know if that issue is going to affect IIS 6.0?

Bill: It's a question of whether that bug is in Windows .NET Server 2003. I believe the answer is no; however, that is a great thing to follow up on. I believe if it is applicable it would be posted to the preview newsgroups. The bulletins now state the applicability of the bug to beta releases. If it's not in the bulletins, I'm fairly confident it's not applicable to Windows .NET Server 2003.

Chris: It currently doesn't show up on the bulletins.

{Follow-up answer: No, the MDAC bulletin does not apply to Windows .NET Server 2003.}

Otto: This next question seems to be related to IIS 5.0 and licensing. Let me ask it just in case. I'm not sure if we can speak to this or not, but the question is: Is that to say that IIS 5.0 with Terminal Services can be used for Remote Desktop for unlimited use? If so, then how is the license used? Is it just like desktops, or just under a Terminal Services license? Do we know?

Bill: Unfortunately, I'm not a licensing expert and I can't give you that answer.

Otto: Is there a URL that you know of that we could point that user to?

Chris: I can only say that, and this is from an IIS support standpoint, that Windows NT 4.0 and Terminal Server and were separated as two different SKUs. At that time, IIS 4.0 wasn't officially supported. I don't have that article. It wasn't supported on Terminal Server Edition. For IIS 5.0, in Windows 2000, Terminal Services merged with the operating system.

We do often allow remote administration of Web servers, but in that general plane, IIS and Terminal Services are separated. One is one application, and one is another, so you can today, in IIS 5.0, with just your five client access licenses or more, definitely remote administer —remote in, log onto your server, and check things out. I think the bigger question at hand, and we still have to follow up on this afterward, is that there's confusion about whether I actually own licenses for application mode, and does IIS support that. I can say that in IIS 5.0 we did not. I don't know if that's something that has changed in IIS 6.0, but we can look into it.

{Follow-up answer: The basic server license in Windows 2000 Server covers remote administration scenarios. No additional client access is required.}

Otto: With that, it appears that we've answered all the questions that were submitted to the queue today. I definitely want to thank everyone for joining us and hope that all this information was useful to you. I want to thank our presenters for coming in and giving us an excellent presentation and a lot of really good information during this Q&A.

As we end the show today, if you have any suggestions for future topics, comments about the session today, or even comments on the WebCast program as a whole, that feedback is absolutely important to us. Please send your feedback to supweb@microsoft.com.

There is one last question. It looks like we do have a couple of minutes. I'll ask it quickly: Is there a tool available to migrate Apache Web servers over to IIS 6.0?

Bill: There is indeed a tool that is being tested right now and that will be available at launch to help you migrate from Apache. We want customers to use that tool.

Otto: Thank you. We hope that everyone has the opportunity to tune in again soon. Thank you all, and have a great day.