Configuring IIS 5.0 for an Intranet

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.

   Previous  [1]  2  3  4  Next