Configuring IIS 5.0 for an Intranet

Follow these tips to establish a well-performing internal application

Intranet applications are a hot development topic these days. Intranet applications are applications that employees or members of an organization use for tasks related to their work or membership in the organization. For example, many companies have intranets that provide human resources (HR) information such as insurance information and forms. Some companies also provide an online store at which employees can buy products. Many intranets take over as internal business systems for production functions.

Intranet applications don't typically run just internally on an organization's LAN or WAN. Many employees and organization members travel or work from home and need access to intranet applications from outside an organization's network environment.

An intranet might provide access to sensitive corporate data. Therefore, it will probably require tighter security in some areas than a public Internet or extranet site or application, which might be separated from corporate data and contain only more public information. For example, an intranet site that publishes HR or accounting data might have stringent security requirements, including the use of Secure Sockets Layer (SSL). But an intranet application that publishes product information might rely on the internal network's standard security mechanisms.

The architecture of intranet applications, especially those that an ISP hosts, is often significantly different from that of Internet applications. Although most intranet and Internet applications use Active Server Pages (ASP), most ISPs won't host custom COM components (i.e., DLLs) on their servers for fear the components will cause problems with other applications on the servers. Thus, most ISP-hosted applications don't use custom COM components unless the ISP hosts a dedicated server for the applications. However, many intranet applications running internally on corporate LANs or WANs use custom COM components, which make the applications easier to create and maintain and improve their performance, so intranet administrators need to work out ways to handle them.

Intranet applications have some special characteristics that you must plan for. I show you the type of server architecture you need to have for developing and deploying intranet applications, where to put the files that the applications use, and how to configure Windows 2000 and IIS 5.0 to best run the applications.

More Servers Are Better
As with IIS Internet applications, one of the best things you can do for IIS intranet applications is keep other applications—including test applications—off the production intranet servers. For example, if your intranet applications access a Microsoft SQL Server database, run SQL Server on a separate server. If you must run multiple applications on your intranet server, expect performance and possibly maintenance problems.

You can and should use staging and possibly test servers to augment your intranet server. Developers can build your intranet applications on their workstations or on a development server. To test the applications, move them to a test server. If you can't do that, at least move them to another Web site on the development server. Using different servers takes the development and testing load off of your production intranet server and reduces the likelihood that problems in application development or testing will affect your production intranet server. Staging servers let you schedule the movement of applications into production.

The hardware requirements for the different servers vary. Typically, the development and staging servers can be lighter weight than the test and production servers. Development and staging servers don't need to handle user traffic, so they don't usually need high-performance features. Test servers should mirror the capabilities of production servers to allow for load testing.

Databases and Directories
Most intranet applications require a database such as Microsoft Access or SQL Server. If your developers use an Access database, you must place the Access database where the IIS application can access its files. You might also need to provide a file share to the directory holding the database so that developers can access the database. For example, you can place an Access database (.mdb file) in one of the intranet application directories and share that directory so that developers can access it over the LAN or WAN.

SQL Server and Microsoft SQL Server Desktop Engine (MSDE—i.e., SQL Server junior) don't require a file share, but they put more memory demands on the server. If you're running either of these databases on your intranet server, you should carefully monitor how much memory the OS, other applications on the same server, and the database are using. As I mentioned earlier, you should put SQL Server on a separate server if at all possible.

If your intranet application uses COM components, you must design a directory structure to support them. The directory structure

C:Components      Application1      Application2      Application3

supports components from multiple applications. Common components go in the Components directory, and application-specific components go into the appropriate application directory. You can also create a Components folder in each application directory to hold the components that only those applications use. Give the application directories the same name as the applications with which they're associated.

The intranet application users must have at least Read and Execute permissions to the components. For example, if you're using Anonymous authentication, the IUSR_machinename account needs at least Read and Execute permission to the Components folder and the components.

Configuring Win2K
A few Win2K settings will make your production intranet server run more smoothly. First, make sure that performance is optimized for background services, the default setting for Win2K servers. This setting causes Win2K to provide equal processing to foreground processes and background processes such as IIS and SQL Server. To check this setting, open the Control Panel System applet. Click the Advanced tab, then click Performance options. Make sure that Background services is selected, as Figure 1 shows, and click OK.

While you're on the Advanced tab, click Startup and Recovery. Figure 2 shows the default values for the options that control Win2K's actions when the OS starts. For an intranet, you might want to change the boot delay to 10 seconds or fewer so that the server restarts faster after a reboot. (The default length of time that the system displays the OS list before booting is 30 seconds.)

I also recommend that you make sure that the Automatically reboot check box is selected so that Win2K will automatically restart if it should shut down for any reason. Automatic rebooting is handy on development, staging, and testing intranet servers, which applications in progress can cause to go down. Automatic rebooting can also be handy on intranet production servers. Intranets often seem to be relegated to older servers, while newer and more robust servers become Internet servers. The older intranet servers are more prone to hardware problems and, thus, crashes and restarts.

Configuring IIS
Now, let's take a look at configuring IIS 5.0 for intranet applications. In my Windows 2000 Magazine article "Tweaking NT and IIS for ASP Applications" (March 2000), I provided some tips for improving the performance of IIS Web sites and applications. Many of those tips also apply to intranet servers, but let's revisit them with intranets specifically in mind.

First, you must decide whether your intranet application will be part of an existing Web site or have its own, new Web site. If you intend to add the intranet application to an existing Web site, you can put its files in the Web site's home directory or elsewhere on the server or network in a virtual directory. If you want to create a new Web site for the intranet application, you'll likely put the application's files in the new Web site's home directory.

When you're making the choice between a new virtual directory in an existing Web site and a new Web site, consider that a new Web site lets you set more properties specifically for your intranet application. A virtual directory in an existing Web site inherits some properties from its associated Web site and thus gives you control over fewer properties. Figure 3 shows the Properties dialog box and tabs for a Web site—in this case, the Default Web Site. A virtual directory has the following subset of Web site Properties tabs: Virtual Directory (similar to a Web site's Home Directory tab), Documents, Directory Security, HTTP Headers, and Custom Errors.

On the Web Site tab of a Web site's Properties dialog box, you can control the site's TCP port. Thus, you can assign a port other than 80 for your intranet application. You can also assign specific IP addresses to an application. The Web Site tab also lets you limit the number of connections to a reasonable number for the application. When or if more than the allotted number of users try to access the application, you can decide to increase the number of connections, add more hardware (e.g., memory, CPU, disk), implement a load-balancing system, or move the application to another server.

The Operators tab in the Web site's Properties dialog box lets you manage operators for the Web site or intranet application. Operators can set access permissions, control logging, change the default document or footer, set content expiration, and enable content ratings, but they can't administer settings such as bandwidth throttling that affect IIS. You can also place operators' user accounts in groups and assign them NTFS permissions to directories for the application. However, most organizations don't use the Operators settings but rather give administrative control of Web sites to a Win2K administrator.

The ISAPI Filters tab is useful for performance reasons. On this page, you can install Internet Server API (ISAPI) filters on or remove them from your Web site. ISAPI filters are DLLs that process HTTP requests. For example, you might have an ISAPI filter that modifies the URL with the cookie data, then intercepts the URL when requests come back. Each filter consumes system resources, so use filters only on applications that need them. Thus, if your intranet application requires one or more ISAPI filters but your existing Web site doesn't need them, or vice versa, you should probably create a new Web site for your intranet application rather than putting the application in a virtual directory in your existing Web site.

The Server Extensions tab gives you control over Microsoft FrontPage Server Extensions. If you disable authoring permissions on a Web site, developers can't use FrontPage and Microsoft Visual InterDev to directly work on that site. They can, of course, create or modify content, which you can use another method such as FTP, WWW Distributed Authoring and Versioning (WebDAV), or file transfer over the LAN or WAN to post to the site. If you put your intranet application in a new Web site instead of in an existing Web site's virtual directory, you can control direct authoring for the application.

You can also tune to some degree the way server extensions perform. Click Settings on the Server Extensions tab to see a list of cache settings that you can adjust. Figure 4 shows the default settings. Instead of tuning the settings individually, you can select from three options:

If your intranet application hosts only 50 users per day, you might want to set the three cache fields to lower values, especially if your server has a limited amount of RAM and is hosting many other sites. If your intranet hosts 200 users per day or if response time is extremely important, make the settings higher. If your application doesn't use the FrontPage search options, you can set Full-text search index size to 0. You can change Max cached document size to limit the total memory dedicated to the cache.

By now, you can see that creating a new Web site for an intranet application provides you many more options than using a virtual directory does. These options primarily let you control the application's performance and management.

Now let's look at the properties that you can set for both a Web site and a virtual directory. Start Internet Services Manager (ISM), then right-click a Web site or virtual directory and select Properties. Either the Home Directory tab on the Web site's Properties dialog box (which Figure 3 shows) appears, or the Virtual Directory tab on the virtual directory's Properties dialog box (which looks similar) appears.

Several properties on these tabs are of key importance for intranets. First, the options at the top of the tabs control the directory that's used as the home directory for the Web site or virtual directory. The first option directs the Web site or virtual directory to a particular directory on a local disk or to a mapped drive on the network. The second option redirects the Web site or virtual directory to a network share by using a Universal Naming Convention (UNC) name. You can also use either of these options when storage or performance requirements dictate changing the directory used for the application. For example, if your local C drive runs short of space, you can map a network drive and move the application to the new drive, then change the local path to point to the new drive. The third option points to a URL. For performance reasons, I highly recommend that you use local storage, unless you have good reasons to use remote storage.

The set of check boxes in the middle of the tab is also useful. Many intranets let users browse directories to look for files because users are authenticated on the network and are thus trusted. If you don't select Directory browsing, users won't be able to browse files when they try to access a site that doesn't have a default document (such as default.asp).

Note that you can set these properties for a Web site or for a directory or virtual directory under that Web site. Earlier, I listed the properties tabs that are common to Web sites and virtual directories. You can use those tabs to set options at the Web site level, then override those settings at the virtual directory or directory level. For example, let's say you put your intranet files in a virtual directory under an existing Web site. You don't want the Web site to allow directory browsing, but you want your intranet to allow it. You can use the virtual directory's Virtual Directory tab in the Properties dialog box to select Directory browsing for only that directory. Then, users will be able to browse files in that virtual directory but not in other directory trees in the same Web site.

At the bottom of the Home Directory and Virtual Directory tabs are the Application Settings, which control the behavior of the ASP applications running in the Web site or virtual directory. The key setting here is Application Protection. Much has been written about this setting and how it relates to performance. Here's a quick review of the options:

I usually choose the Low setting unless I think that an application running on the server might be causing problems. Then I change the setting to Medium or High until I find and resolve the problem. You might want to try the Medium or High setting for your intranet application Web site or virtual directory. If the intranet doesn't perform adequately, you can reset this property to Low.

The IIS documentation recommends that you don't run more than 10 out-of-process applications (i.e., applications with the High setting) on a server. This number is merely a suggestion. Test your applications to determine how many applications your server can support.

If you want to tweak the settings, click Configuration on the Home Directory or Virtual Directory tab and open the Application Configuration dialog box. Unless your intranet application has performance problems, you shouldn't have to tweak these settings for performance reasons. However, because intranet applications are private and typically have fewer users than public applications, you might want to enable session state, tweak timeout values, and enable authentication.

The App Options dialog box, which you access by clicking Configuration on the Home Directory tab, controls the settings for ASP applications. The Enable session state setting can be useful for intranet applications. However, session state doesn't work well for Internet and extranet applications because it doesn't scale well. Fortunately, many intranet applications run on one server and don't need to scale up the way public applications do, so they can be good candidates for session state. If you use session state, monitor application performance to make sure it remains adequate.

If you enable session state, you might need to tweak the Session timeout setting in the App Options dialog box. Session timeout specifies the number of minutes that must pass before the session times out. If you have an application that serves only a few users and those users use the application all day long, you can probably raise this value from the default 20 minutes to 60 minutes or longer. If you have many users who are in and out of the application, you can lower the value to consume fewer resources. Be aware that developers can override your settings in their applications, but they can't turn on session state if you've disabled it.

You might also need to increase the ASP script timeout setting in the App Options dialog box—the default is 90 seconds. This change should be necessary only if your intranet application has long-running processes (such as a complex query on a large database) and the developers don't set this property higher in the code.

One other setting that you'll probably want to change for intranets is accessible through the Web site's or virtual directory's Directory Security tab. Click Edit on the Directory Security tab to open the Authentication Methods dialog box. Most (or all) users of an intranet have accounts in the corporate domain, so you can clear the Anonymous access option and enable some type of Windows authentication (e.g., Integrated Windows authentication). Allowing anonymous access when you want to force users to use Windows authentication will leave a security hole in your system.

User Connections
As I mentioned at the beginning of the article, most users will access your intranet application over the LAN, but some might also require access from remote locations. To accommodate remote users, you can expose the intranet server to the public Internet, provide dial-up access, or provide VPN access.

Placing the intranet server on the Internet means that you must set up security and management like you would for any Internet server. Dial-up access keeps the intranet off the Internet but is slow and requires users to dial in to one of your modems.

A VPN arguably provides the best solution. You secure and manage the VPN, and the intranet server is just a network server to users. VPNs do have a high degree of overhead, so take performance into account before you decide to use a VPN for access.

Hosting intranet applications is much easier than hosting traditional client-server applications. However, as you've seen in this article, intranet applications are different from Internet and extranet applications; consequently, you must configure Win2K and IIS differently to host these applications. However, the nice thing about IIS is the ease with which you can move things. For example, you can place an application in a virtual directory to begin with. If that approach doesn't work, you can always create a new Web site and move the application there.