Team LiB
Previous Section Next Section

Internet Information Services 5.0

Here we will show you the architecture of IIS. We will start with IIS 5.0 and then continue with IIS 6.0. We will examine some of the exciting features in the latest version that let you build scalable Web applications and Web services, as well as how you can use IIS 5.0 in a scalable environment.

Architecture

Let us start with an exploration of IIS 5.0. IIS includes more than just the Web server as mentioned earlier, but because these other features fall outside of the scope of this book, we will not discuss them here. However, if you would like to learn more about these, please see http://www.microsoft.com/WindowsServer2003/iis/default.mspx.

As a service, IIS is running closely integrated with the operating system. This way it can use many of the other services running on Windows 2000. For example, security can be used in conjunction with Active Directory, and scalability can be improved with Network Load Balancing (NLB). By being this close to the Windows 2000 security model, dedicated user account administration is unnecessary. Even if the server is not running Active Directory, IIS employs its user account handling (see Figure 7-1).

Click To expand
Figure 7-1: The Windows 2000 user management feature

When it comes to administration and monitoring, IIS 5.0 also takes advantage of operating system tools like the System Monitor, Event Viewer, and MMC. A benefit of this is that administrators get tools similar to all other tools in Windows 2000, and therefore they do not have to learn a completely new user interface just to manage the Web server.

Figure 7-2 presents an architectural overview of IIS 5.0.

Click To expand
Figure 7-2: An overview of the IIS 5.0 architecture

All Windows-based services and applications are run in memory areas called processes. The Internet services in IIS 5.0 reside in the Inetinfo process (inetinfo.exe). This process also contains the shared thread pool, cache, and logging services of IIS.

Note 

The Inetinfo process is pageable. This means the system can remove all or part of this process from RAM and write it to disk if not enough RAM is left, which negatively affects IIS performance. The remedy is to provide enough RAM to your Web servers so you can avoid paging and keep the Inetinfo process in RAM at all times. But as you will see, there is a limit to how much RAM IIS can handle, which you also have to consider.

One of the problems of versions of IIS prior to version 5.0 was that a single application error could bring down the entire server, due to all Internet Server API (ISAPI) applications (like ASP) sharing the resources and memory of the Inetinfo process. When an application is run like this, it is said to run in-process. Another problem with such applications was that they could not be unloaded without a restart of the entire physical server. This provided some problems naturally, since all Web sites hosted on the server became affected by this. You might think such an approach to running applications had too many drawbacks, but it had its benefits, too. Performance for one thing was high, but honestly the disadvantages were so great that this was not enough to promote this technology in the long run.

IIS 5.0 provides three ways to run your applications, as listed here (and illustrated in Figure 7-3):

  • Running applications in-process in the Inetinfo process.

  • Running applications isolated from Web services in a process called dllhost.exe, which is called out-of-process.

  • Running applications in a pooled process separate from Web services. This is also an out-of-process procedure handled by the dllhost.exe.

Click To expand
Figure 7-3: The three different ways an application can be run in IIS 5.0

This solution is called application protection and provides for a much more stable and reliable application architecture than was possible before. If you run applications in a pooled process, an error will not take the whole server down. All applications in the pool will fail, but the Web server will still be up and running. If you have a very important application, you can run it as an isolated process. This application will then be run in a separate instance of dllhost.exe, making it hard for other applications to bring it down with them if they encounter an error.

But all good things usually come with a price tag. In this case, performance is negatively affected by running pooled or isolated applications. Microsoft has tried to overcome this performance drop by looking over the IIS 5.0 code, but our recommendation is not to run more than ten isolated applications on a server.

Figure 7-4 shows how to set the application protection level for a specific site. You can only set this on the Home Directory or Virtual Directory properties sheet of a Web site. You can select High (Isolated), Low (IIS Process), or Medium (Pooled) from the Application Protection drop-down list.

Click To expand
Figure 7-4: Setting the application protection for a Web application or site

The default setting for application protection specifies that Web services in inetinfo.exe will run in their own processes. All other applications will be run in a single, pooled process using dllhost.exe, unless you manually change the settings. We recommend keeping the default setting, and only letting applications with the highest priority run as isolated processes.

If an error occurs, the best way to solve the problem is not by rebooting the server. This behavior was what gave Microsoft's operating systems a bad reputation in the first place. Nonetheless, in the past this was necessary to unload troublesome applications from memory and restart the Web server. Imagine if the same had to be done if a CD player in a car started misbehaving: "Sorry, a CD player error has occurred. Please turn off the engine and restart the car." You would probably not buy that car. To overcome errors, Windows 2000 includes IIS Reliable Restart, which provides a faster, easier, and more flexible one-step restart, shown in Figure 7-5. The administrator can restart IIS by right-clicking an item in the MMC.

Click To expand
Figure 7-5: The new IIS Reliable Restart

You can also restart the IIS by issuing the iisreset command at the command prompt as Figure 7-6 shows.

Click To expand
Figure 7-6: The command-line tool to restart IIS

If an error takes down the Inetinfo process, IIS uses the Windows Service Manager to automatically restart IIS. By doing this it lessens some of the tasks an administrator otherwise has to do.

To increase performance, it is important to optimize access to your Web site. Clients access your site by an IP address and a port number. On a Web server the default port is port 80. This unique identifier (IP address:port number) is called a socket. In IIS 4.0, sockets were allocated on a per-Web-site basis. You could bind various Web sites to different IP addresses. Each site on an IP address had several sockets, but the sites did not share sockets. Since each socket consumed a good deal of RAM, performance would suffer if too many sites were hosted on a server.

In IIS 5.0, a technique called socket pooling enables the possibility of allocating sockets on a per-port basis. This means that sites on different IP addresses, using the same port, also share the same sockets. No matter how many sites you place on a port, they all share the same sockets. This reduces resource consumption dramatically.

Socket pooling is enabled by default. If you have a mission-critical Web site, it might be a good choice to disable this feature for that specific site. Although resource consumption is decreased with socket pooling, performance can still be affected if too many sites share the same port. Otherwise, we recommend not changing the default values. You must use a script to disable socket pooling because there is no GUI way of altering this setting. To change it, open a command prompt and enter x:\inetpub\adminscripts\cscript adsutil.vbs set w3svc/disablesocketpooling true, which will return "disablesocketpooling : (BOOLEAN) True" when the command has executed.

As you can understand from the preceding reasoning, IIS 5.0 can help you host several sites on one server. This is hardly anything new, though. IIS 5.0 offers three ways to distinguish between multiple sites:

  • Port numbers

  • IP addresses

  • Host header names

This is quite logical since each Web site has a unique identity consisting of three parts: IP address, port number, and host header name. By varying these parts, you can create unique identities for your main sites. You could, for instance, have your main site at address 192.168.0.1:8 and another site at 192.168.0.1:9, where the first site uses port 8 and the second port 9. They still share the same IP address. The problem here is that you always need to include the port number after the IP address or DNS name. Therefore, it might be better to use multiple IP addresses or perhaps different host header names.

Two more things in IIS 5.0 can help you increase performance on your sites. The first is process throttling, which helps you control how much processor time a Web site and its applications can use. This is something you can use only for out-of-process applications, so it is not possible to use with the Inetinfo process. The other, called bandwidth throttling, is similar to process throttling. The difference is that bandwidth throttling allows you to control the amount of bandwidth a site can use on the network interface card (NIC). Keep in mind that this solution, as well as process throttling, only affects static content like HTML files or graphics files. It does not affect dynamic ASP files or other dynamic content, so you cannot use this to trim your ASP sites. Please also note that if you use socket pooling, bandwidth throttling affects all applications in the pool on that port number.

Apart from the IIS architecture itself, a lot of improvements were made to enhance the application environment. With the help of flow control capabilities in ASP, you can write more efficient Web applications by cutting down on round-trips to the server. Figure 7-7 shows the benefits of using server.transfer instead of server.redirect when a redirect to another ASP page on the same server is necessary.

Click To expand
Figure 7-7: Server.transfer cuts the number of round-trips to the server, which increases performance

Many of the Web-based components were also improved to increase performance and to make them scale well. Most of them were in large part rewritten to accomplish this. An example of one of these components is browscap.dll, which determines browser capabilities.

IIS 5.0 creates up to four threads per CPU in its default settings. The number of threads is continuously changed by IIS depending on the activity on the server. For most systems this setting is okay, but in some cases it might be necessary to change this value. If you monitor your system and find that the CPU is not always active, but almost all threads seem to be busy, it might be a good thing to increase this value. But you must make sure you have enough processor capacity left, otherwise this change will lead to less processor time per thread. If you need to change this value, you must use a registry editor and add the MaxPoolThreads entry to the following registry string:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters

This entry sets the units of threads per processor and should be a value between 2 and 20. After this is added, it is important to monitor the system so that this change accomplishes what you wanted it to do. One tip is to try this in the lab before implementing it on a production server.

Caution 

As always, be careful when modifying the registry.

ASP thread gating is a part of the ASP self-tuning features. This feature monitors the CPU(s) and starts restricting the number of threads when a set threshold is reached. This is done by IIS to dynamically control the number of concurrent threads that are allowed to execute. By default, thread gating is disabled because the settings are appropriate for most applications anyway. If you change this setting when you really do not need to, performance can deteriorate. And IIS actually increases or decreases the number of threads anyway, even if thread gating is disabled.

IIS 5.0, being tightly integrated with Windows 2000, also works together with COM+ to enable developers to write and build Web applications. IIS uses COM+ for mostly three purposes:

  • Handling transaction coordination

  • Managing communication between COM components

  • Isolating applications into distinct processes

Performance and Scalability

Now that you have seen a little of the architecture of IIS 5.0, it might be a good idea to have a closer look at how to achieve good performance and scalability in an IIS 5.0 application. A lot of things need to be considered when designing the infrastructure for a scalable application. Both hardware and software work together to achieve this. What good is it to you if you design the best application possible, and you run it on low-budget, nonperforming hardware? And to turn that around: What use do you have for a top-of-the-line server park if your application designers do not know the benefits of good design and thorough testing?

This part of the chapter will focus on the IIS, but we cannot avoid consideration of other aspects as well, like operating system tuning and solutions to hardware issues in general.

So let us start with performance. How do you really know if performance is good or bad on your Web server? And if you really suspect performance is bad, how do you know what is causing this? To answer these questions, you need to develop a plan for evaluating performance. This plan might look different from Web site to Web site, but the main thing is that you sit down and consider this matter. There are, however, a few rules of thumb to follow when carrying out the plan:

  • Use a test lab where you have a controlled environment.

  • Monitor the test lab servers under different workloads.

  • Test applications and solutions before deployment.

  • Apply changes one at a time.

  • Monitor the production servers.

  • Have a backup plan.

The plan, as well as the tuning itself, will help you remove bottlenecks from your system. This can be beneficial to you in several ways. First of all, the user experience will improve because response times will be better. Secondly, your friends in the accounting department will be happy because you might not need to add as many servers to the cluster as you have calculated in the first place. The time before the next upgrade might be longer because you make better use of the resources you already have. But in our opinion, the most important reason is that by tuning your system to take advantage of your hardware in the best way, your applications can have more, and hopefully better, features that improve your business.

To be able to determine what to tune in your system, it is important to have a baseline for your system. To collect this baseline, you need to monitor your system for a period of time and under different loads before you start experimenting. That is right, experimenting, because most of the tuning is done by trial and error, which is why it is so important to only change one setting at a time.

To gather a baseline, you use the Performance Monitor in Windows 2000, shown in Figure 7-8, and the built-in performance counters that the operating system and IIS provide.

Click To expand
Figure 7-8: The Performance Monitor, which you use to collect a server baseline

When you have a baseline, you can start comparing your changes to this and see if performance was affected the way you wanted. This is done by running a new monitoring period after a change has been implemented and seeing what effect it has.

One important thing we cannot stress enough is testing. Many developers do not take testing as seriously as they should. This is a dangerous attitude that often will punish such developers in the long run. Before implementing anything, you need to be certain that everything has been tested and works as planned. You must be sure that your hardware is up to the task. You must be confident that the application design and your code have been thoroughly tested as well. You also must be certain any changes to your system have been tested before implementing them. To do this, you need to have a test plan and a test environment. In this test lab, you deploy your applications and test all aspects of them. To have a quality test, it might be a smart choice to have a test leader who is separate from the project. This way the test leader is more objective, which almost always leads to better testing.

Note 

In the lab you should also stress test your applications. This is done with a stress test tool like Web Application Stress Tool, from Microsoft, or Application Center Test, included with Visual Studio .NET Enterprise Architect version. These tools fake client requests based on values you have provided before the test and give you a summary report so you can evaluate performance afterwards.

When you finally have accepted the results of lab testing, you can start deploying the application, or changes, in your production environment. The monitoring does not stop here, however. Once you have deployed the application, you need to continue surveying it so you can catch possible misbehavior before it happens.

Next we will discuss just what you should monitor and what problems might be solved by this.

Hardware

If your hardware platform is under-dimensioned, you have a problem. No matter how well you have designed your application, performance will suffer anyway. You must first make sure your system has enough RAM to avoid problems. The absolute minimum amount of RAM to run Windows 2000 with IIS 5.0 is 128MB. But no one in his or her right mind would try to run a server with this configuration. Our recommendation is starting with at least 512MB or perhaps even 1GB of RAM, depending on the type of applications you are going to run on the system. By default the IIS file cache is set to use half of the RAM available, so the more the merrier, at least to a certain degree. If you have too much RAM, the IIS file cache cannot use it fully. Therefore, it might be good not to exceed 2GB to 3GB of RAM for a standard Web server.

Note 

The static file cache lives in the Inetinfo process and can store up to 1.5GB of content. But in reality the ObjectCacheTTL value is set to a default of 30 seconds, which is too small for the file cache to grow to this size. ObjectCacheTTL determines the amount of time objects (like files) are held in cached memory before they are discarded. This is a registry value not added by default, so if you want to change the default setting for this, you must use a registry editor to add MemCacheSize and ObjectCacheTTL to HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters.

For more information about this, please refer to http://www.microsoft.com/technet/ or the Windows 2000 Resource Kit.

To determine if memory provides a bottleneck, you should monitor and log the following performance counters on your system:

  • Memory: Available bytes: Try to have at least 10 percent available for times with heavy loads.

  • Memory: Page faults/sec: When a process requests a page in memory, and the system cannot find it at the requested location, we say a page fault has occurred. There are two kinds of page faults: soft page faults and hard page faults. Soft page faults can be measured with Memory: Transition faults/sec and occur when a page is found somewhere else in memory. This is not very serious since most operating systems handle these faults and minimize the impact they could have. Hard page faults, on the other hand, are more severe and can result in unnecessary delays. You measure this type of fault with Memory: Pages input/sec to determine how many pages were read from disk to resolve this. It might also be a good idea to monitor Memory: Page read/sec to find out how many times the disk was read to correct hard page faults. If these numbers are high, the rest of your system does not have enough memory because too much is reserved for the caches. To resolve this, you might have to lower the cache sizes or add more RAM.

  • Memory: Cache bytes: You should monitor this counter to see if your system cache is running out of memory. Remember that the IIS file cache by default is set to use a maximum of 50 percent of available memory.

  • Internet Information Services Global: File cache hits %: This counter tells you whether the requests find their target in the cache or not. The higher the value, the better performance you have. For static content, a good value might be as high as 80 percent.

  • Process (Inetinfo): Virtual bytes, Process (dllhost#n): Virtual bytes, Process (Inetinfo): Working set, and Process (dllhost#n): Working set: These monitor the amount of virtual space available to IIS 5.0 and the number of memory pages used by each process.

Another important thing to monitor is the capacity of the processor(s). You must be certain that one or more processes do not consume too much processor time. If they do, other processes must wait in queue to be executed. Even though memory issues are the biggest problems on a Windows 2000/IIS 5.0 system, you should not forget the processor(s). Before you add more CPUs to your system, however, you must rule out memory problems, because solving such problems often results in the biggest performance gains. IIS 5.0 scales very well on a two-four CPU system. If you have a system with more CPUs, you must do a little tuning to get it to work properly. Remember, you cannot get it to scale on more than eight CPUs without partitioning the system.

Note 

To learn more about this, please visit http://www.microsoft.com/technet/ or refer to the Windows 2000 Resource Kit.

Here are a couple performance counters to help you determine if the CPUs are a problem in your system:

  • Processor: % Processor time: If you have a constant high value here, you might begin to assume something is eating processor time. But before you take any action, you must check to see if the disk I/O and NIC usage are below capacity. If they are, you might assume you have a processor problem.

  • System: Processor queue length: This value indicates the number of threads waiting in the processor queue to be executed. If the value is two or higher for a longer period of time, you have a processor bottleneck.

If you have added CPUs to your system and still have problems, you have to turn to other methods to solve this issue. A good idea then is to scale out on more servers by using Network Load Balancing. This issue is dissected in Chapter 2.

There are more hardware issues to consider if you are to optimize your system. Network capacity and disk optimization are important too, but we will not go into these areas here. Some of these will pop up in the next chapter, and the rest we leave to system administrators. This does not mean they are not important; they just do not have that much to do with IIS.

Security

Even security has an impact on performance. This means you have a delicate situation to handle, because you must make your users feel secure when accessing your site and still give them a good user experience without bad performance. Let us consider when you use Secure Sockets Layer (SSL), for example. SSL connections are cached in the SSL session cache. The default setting for sessions to live in this cache is five minutes in Windows 2000. If a request needs to reconnect to a session that has expired, this comes with a penalty five times as expensive as finding the connection in the cache.

Note 

If you want to support longer SSL sessions, you must increase the time-out period by setting the ServerCacheTime value in the registry. Please refer to the Windows 2000 Resource Kit for how to change this value.

Since most security issues are tightly integrated with the operating system, it can be hard to monitor them separately. Therefore security overhead must often be measured by running tests. Run the tests with and without the security feature(s) and compare the results.

Web Applications

You are in a good spot if you have made sure your hardware is working smoothly. But does this really matter if your applications misbehave? Of course it does not. You must also make sure the applications work properly, as we have stressed before.

A badly written application can degrade performance terribly. This is the reason you must spend a good deal of time on designing and testing your applications.

Note 

If your applications retrieve information from legacy systems, like AS/400 and UNIX, or from other Web sites, you might not have control over the performance of these sources. You might also experience problems if remote SQL Servers behave poorly. If you can, you should try to monitor these applications as well, but this might not be possible in many cases.

If you suspect an application bottleneck, you need to determine if the problems are caused by your own server, or if the problems occur on systems out of your control. If they occur on your server, you still have a chance of taking care of them. If they appear on remote databases, you must begin to consider if it is worth the trouble of setting up a cache database on the same subnet as your system and configuring replication between this database and the remote system.

If you have a lot of ASP pages, the following performance counters are good to keep an eye on:

  • Active Server Pages: Requests/Sec: This counter will give you a hint whether your applications are causing the bottleneck. If values are low during peak traffic, you might have a troublesome application.

  • Active Server Pages: Requests executing: This shows how many requests are executing at the moment.

  • Active Server Pages: Requests wait time, Active Server Pages: Executing time, and Active Server Pages: Requests queued: These three counters should be close to zero if everything is okay. Otherwise, requests take too long to execute and others are waiting in the queue. The queue's maximum length is determined by the value ASPRequestQueueMax in the metabase. If these values are constantly high, you need to go over your code and try to rewrite to optimize performance where you can. It is a bit tricky to know the correct value for this, and you must consider many factors to calculate it. When trying to determine the value, please consider the number of CPUs, the setting for ASPProcessorThreadMax, and the number of processes hosting ASP.

  • Web Service: CGI requests/sec, Web Service: ISAPI extension, Web Service: Get requests/sec, and Web Service: Post requests/sec. The latter two counters show how many get and post requests are made to your system. This can give you a good estimate of the load on your system. If these values are constantly high, it might be a good solution to scale out on more servers. The first two counters should not drop under a heavy load. If the latter two are high and the first two are low, you need to do something about the design of your application or about the code itself.

We have so far mostly talked about scaling up—that is, adding more hardware and doing application rewrites to solve performance problems. There is, however, another way to increase performance, and we have mentioned it briefly earlier. What we are talking about is scaling out—that is, spreading the load on several servers in a cluster (or Web farm, as it is also called). Keep in mind, though, that scaling out in no way replaces scaling up or monitoring an individual server. In order to get as much performance as possible from your solution, you have to work on a broad front. Scaling out helps you in more ways than only enhancing performance. It is a great way of increasing both scalability and reliability, as Chapter 2 showed. In a Web cluster, one of the most common ways to enable load balancing is by using NLB, at least on a Microsoft solution. NLB is relatively easy to enable. The next chapter will show you how to enable it on a Windows 2000 Server and Windows Server 2003 solution.

Now you have seen a few of the monitoring possibilities for tuning a separate Web server running IIS 5.0. A lot of these tricks are also valid on IIS 6.0. There are several other important things to think about when you plan your Web application infrastructure as well. We will now take a look at some best practices when it comes to securing IIS 5.0. These can be a great help in preventing attacks against the Web server itself.

Security

During the writing of this book, a new attack on Internet servers had just occurred. The virus this time, called Slammer, infected SQL Servers and degraded performance on many servers all over the world. The irony in this is that Microsoft provided a fix for this some six months before someone actually exploited the vulnerability. This fix had been available for download all this time. But IT professionals all over the world had not updated their servers because the fix was a bit complicated to apply. Even Microsoft had several servers unpatched and experienced problems, which is the real irony. (Yes, we must admit, one of us missed a server as well.) Even though Microsoft should have made the patch easier to install, that is not what we would like to point out here. No, the point is the importance of keeping up to date with the latest security patches and service packs. This is important since outages of your systems cost a lot, and put in perspective to the cost of applying patches, there really is no discussion. You must keep your servers up to date on this issue.

There are a few ways to do this:

You should also change the default Web site location on your disk from c:\inetpub to some other volume, which would cause a hacker problems navigating the directory tree. In this case, the command "..\" would not give access to the C drive. To further hinder a hacker, you should disable the Enable parent paths option that allows you to use ".." in calls to functions such as MapPath. To disable it, follow these procedures:

  1. Right-click the root of the Web site.

  2. Choose Properties.

  3. Click the Home Directory tab.

  4. Click Configuration.

  5. Click the Apps options tab.

  6. Uncheck the Enable parent paths checkbox, shown in Figure 7-9.

Click To expand
Figure 7-9: The Enable parent path option

While we are talking about the directory structure, we might as well continue with removing the samples directories included with IIS 5.0. These are not necessary on a production server and could be a threat to your system. Remove the following (if they exist):

  • \inetpub\iissamples

  • %systemroot%\help\iishelp

  • \program files\common files\system\msadc

You should also consider removing unnecessary virtual directories in the inetpub directory. IISADMPWD is not needed unless you have an absolute demand for this management feature. If this is present, consider removing it.

The IIS Lockdown Tool, a handy helper, is available for free from Microsoft (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/locktool.asp). This tool enables you to lock down IIS 5.0 without specifying individual registry settings and security policies. Use this to reduce the area exposed to potential hackers.

Remove all unused script or application mappings. IIS is preconfigured to support common filename extensions such as .asp and .shtm. If you install the .NET Framework, even more mappings are added. Remove those that are not needed and rebind them to the 404.dll extension available with the IIS Lockdown Tool.

Make sure that all accounts used only have the minimum privileges they require. The ASPNET account used for running ASP.NET code, for example, should not be given more privileges than it needs. This is created as a local service account when installing the .NET Framework redistributable code and belongs to the users group on the machine. Add this account to the Web application group created by the IIS Lockdown Tool. This will prevent the account from running any unauthorized command-line executables if an attack occurs.

Another great tool included with IIS Lockdown Tool is URLScan. This is an ISAPI filter that can help you control which set of extensions can be used in the application, and also block long requests. Long requests are exploited when an attacker tries to insert malicious code by user input, and by using URLScan you can block that.

Another way to enhance security is by controlling access to the Web content directories. You should, as always, apply the rule of not letting anyone have more privileges than is absolutely necessary. The ASP.NET process often only needs read access to content files, for instance. Anonymous users should only have read-only permissions to the content according to what is appropriate for the situation. It is vital to look over the Access Control Lists (ACLs) so you do not miss anything.

You should also consider restricting access to the log files. This way you prevent a hacker from covering up his or her tracks by altering these files. But for this to be of any use, you obviously must enable logging on your server. Follow these steps to enable W3C extended logging format:

  1. Start the Internet Information Services Tool.

  2. Right-click the Web site.

  3. Choose Properties.

  4. Click the Web site tab.

  5. Check the Enable logging checkbox.

  6. Choose W3C extended log file format from the active log format drop-down list.

  7. Click Properties and click the Advanced tab.

  8. Click the Extended properties tab and select the following (see Figure 7-10):

    • Client IP Address

    • User Name

    • Service Name

    • Server Name

    • Server IP Address (if this applies to multiple sites)

    • Server Port

    • Method

    • URI Stem

    • URI Query

    • Protocol Status

    • Protocol Substatus

    • Win32 Status (for debugging)

    • User Agent

Click To expand
Figure 7-10: The extended logging options of the W3C extended log file format

These logs can help you determine what a hacker has tried to do to your system. It might be a good idea to let a developer write an application that scans these log files regularly and looks for, amongst other things, error 5 in Win32 status, which means access denied.

Another thing worth considering is setting an IPSec packet filtering policy on all Web servers to provide extra security if someone gets past your firewalls. Try to block all TCP/IP protocols and ports that you do not need to support.

By executing the NetBIOS adapter status command, a hacker could get access to the name of the currently logged-on user. To avoid this, you should consider disabling NetBIOS over TCP on public connections of the server. But before you do this on any of your connections, you must be sure none of your administrational applications, tools, or other applications depend on this. So our advice is to try this in the test lab before implementing it in the production environment.

Now you have seen various ways of enhancing performance, scalability, and security on systems running Windows 2000 and IIS 5.0. These are some of the best practices we have found relevant in many cases. But as always, they are not all applicable to every situation. Try them in the test lab first to avoid unexpected problems in your production environment later.

Next we will move on to Internet Information Services 6.0 and show you what is new in this latest version of IIS.


Team LiB
Previous Section Next Section