How to Build a Web Development Environment - 19 Nov 1999

Last month, I discussed the first part of a project I implemented for a customer. I set up a Windows NT 4.0 IIS 4.0 server to host Web domains for Web-content-only authors who use Microsoft FrontPage. I described the company's plan for implementing the development environment and the method I used to structure the Web domains and sites on the FrontPage development server. This month, I describe the other part of my assignment: setting up an NT 4.0 IIS 4.0 server to host the application developers who use Microsoft Visual InterDev.

The company wanted one set of naming conventions and one standard set of rules for all developers to follow in setting Execute permissions on their applications directories. In addition, managers wanted to be able to view (i.e., browse) Web projects under development at any time and see all the projects that a particular developer owned. To help meet these needs, developers would

Setting Up the Web Application Server
Setting up the application development server was more complicated than setting up the Web content development server because it entailed installing more software to prepare for Visual InterDev and for Microsoft Site Server 3.0. The team planned to install Site Server 3.0 after we shook out the development environment with Visual InterDev. We chose Site Server as the product suite for providing membership services, site usage reporting, and search and direct mail capabilities. The company would use Site Server to handle membership, subscriptions, logons, and user information storage between sessions. The sidebar "Tips for Setting Up IIS and Site Server" suggests ways to optimize the installation.

The dual-processor server the company had built included NT 4.0 Service Pack 3 (SP3) and NT Option Pack 4, which includes IIS 4.0, the Microsoft Management Console (MMC), and the FrontPage 98 server extensions. When we installed NT Option Pack 4 on this server, we also installed the Index Server, the SMTP server, and of course, the Microsoft Transaction Server (MTS) to accommodate applications developed with Visual InterDev and Site Server. After the option pack, we installed Microsoft SQL Server 6.5 for applications developed with Visual InterDev and Site Server to use, and SQL Server SP4, which Site Server requires. Finally, we installed Visual InterDev 6.0a and the Microsoft Developer Network (MSDN) Library on the application server and on each of the developers' NT workstations.

After this initial installation, the team performed the following steps:

Set Up the Domains
Just like developers on the Web content server, each application developer has a Web domain on the application server. The rationale for this configuration is that each developer needs to have his or her projects on Web sites in a separate domain rather than a proliferation of Web sites defined on various ports with no organizational structure to show whom they belong to or what state they're in. We used host headers to implement these developer domains because host headers let us use the default port (i.e., port 80) and create many Web sites that use the same IP address. See my article "Using Host Headers to Set Up a Multihomed Server" (October 1999) for details about defining host headers. With this configuration, developers could work in two ways: They could develop applications on their workstation and periodically update their domain in the Application Development Web domain, or they could use Visual InterDev in Master Mode to work directly on a Web project in their Web domain.

To set up the developer domains, I first added several IP addresses to the machine the company would use just for the Application Development Web domain and the test Web domains. (The host header article explains how to add these IP addresses.) Then I set up the file directories for the development domain:

D:AppDevD:AppDevDanesDomainD:AppDevDemarisDomain

In this example, all Dane's Web projects are subdirectories under the DanesDomain subdirectory, and all Demaris' Web projects are subdirectories under DemarisDomain.

Next, I used one of the IP addresses on port 80 to define the new primary Web domain, with the home directory of D:AppDev. You can define the Web domain in the MMC by right-clicking the machine name and selecting New, Web Site. Follow the steps in the wizard. Select the specific IP address (e.g., 205.174.179.101) that you'll use for the Web domain; don't select All Unassigned. Next, select the directory (e.g., D:AppDev). Finally, accept the Allow Read Access and Allow Script Access default permissions, and click Finish.

Right-click the new Web site, and open the Properties window. Set the IP address, if necessary; sometimes the IP address will be All Unassigned even if you selected an IP address in the wizard. Screen 1 shows the new Web domain in this example.

Go to the Home Directory tab, and select the FrontPage Web check box to install the FrontPage extensions in the Web site. Click Apply and OK to close the Properties window. Selecting the FrontPage check box in the MMC has the same effect as going to the FrontPage Server Administrator and choosing Install. Also, installing the option pack installs the FrontPage Server Administrator. You won't see all the new FrontPage directories until after you shut down and restart the MMC. Now, start the new Web site.

You must define a primary domain (i.e., a domain that uses the IP address on port 80 and has no host header) before you can define host header domains on that IP address. In my example, this primary Web domain is Application Development. If you don't define the primary Web do-main, a new host header domain that uses the same IP address as the primary Web domain will give you an error message when you try to start it, telling you to check for conflicts in other Web site definitions.

Finally, I defined a host header domain for each developer. I followed the same procedure as for the Application Development Web domain, except that the developers' domains have host headers. After you create the new Web site, right-click it, and select Properties. Check the IP Address field, make sure the IP address is correct, then click Advanced. Highlight the IP identity, and click Edit to open the Advanced Web Site Identification window you see in Screen 2, page 14. Add the host header name for the Web site (e.g., Danes_Domain), and click OK twice. Select the FrontPage Web check box on the Home Directory tab. Click Apply and OK in the Properties window. Now, you can start the developer's Web site.

Repeat this process for each developer's domain. Screen 3, page 14, lists the site names, their IP addresses, host headers, and ports of all the sites running on the Internet Information Server *zeus. You get to this helpful view by left-clicking the machine name in the left pane. Notice that the Application Development, Danes_Domain, and Demaris_Domain servers all have the same IP address and that Application Development doesn't have a host header because it's the primary domain in the group.

Notice in the left pane that the Application Development virtual server has both the DanesDomain and the DemarisDomain subdirectories beneath it. Because of the directory structure's inheritance property, you can reach these two Web sites either by their host header names (e.g., http://danes_domain) or as sub-Webs under the Application Development domain (e.g., http://appdev/danesdomain). The team decided to use the host header name as the description in the Web site Properties as a standard practice so that no one would have trouble finding a host header domain in the MMC.

Distribute the HOSTS File on the Network
The company had decided to use a HOSTS file rather than DNS in the development environment so that developers could easily access the development domains. Screen 4 shows the updated HOSTS file for the development domains. In NT 4.0, the HOSTS file resides in the C:winntsystem32drivers directory. You can use Notepad to easily edit the HOSTS file. Just be sure to save the file without any extension. (Notepad tries to tack on a .txt extension.)

Because the HOSTS file is just a text file, you can distribute it to those who need access to the sites by sending the file to them as an email attachment. After you distribute the HOSTS file, all the developers can access the development domains by typing the host header name in the location field of their browser (e.g., http://danes_domain).

Set Permissions
Next, you need to set permissions for the Browse, Author, and Administrator levels of security for each new domain. The domain's permissions become the default permissions for any sub-Web you create under the domain. The most common way to set permissions on a Web site is through Windows Explorer. Right-click the Web site directory, select Properties, and go to the Security tab. You can add authors, users, and administrators by clicking Permissions and adding the users or groups with appropriate permissions. For example, to add the NT user Dane as an author and administrator in the DanesDomain Web site, select the user's ID, and grant the user Change permissions. This permission appears as Change (RWXD); RWXD stands for read, write, execute, delete.

To create Web applications (i.e., projects) on the server, the operator must be a member of the domain administrators' group. Also, the developer's workstation must be in the same domain as the application Web server or in a trusted domain.

Use Visual InterDev in the New Development Domain
The developer's Web site (e.g., http://danes_domain) needs to become a project before Visual InterDev can support development in it and before the developer can move Visual InterDev projects into it. Microsoft calls this kind of Web site or virtual server an application server.

From a developer's workstation, start Visual InterDev. Select New Web Project to launch the Web Project Wizard. Select the server you want to use (e.g., Danes_Domain—the host header for this developer's domain is the server name; for our example, the application server is danes_domain). Make sure you've updated and distributed the HOSTS file that includes the IP address for Danes_Domain, or Visual InterDev won't be able to find the server in the network. I named the project home and accepted Master Mode as the mode to work in. Click Next.

Select Connect to an Existing Web Application on Danes_Domain; the name will be because is the only Web on the virtual server at this time. Click Finish. Select Yes to install the Visual InterDev Script Library on the new Web application. To test the new application server, you need a home page. So, on the Project menu in Visual InterDev, select Add Item, highlight the HTML page, and name it default.htm. However, because this site is a Visual InterDev Web site, a more appropriate approach would be to click the Active Server Pages (ASP) page and name it default.asp; default.asp is the traditional starting place for a Visual InterDev Web site. Add the content you want to the ASP page, and save the file.

If you get an error message when you type only the host header name, try entering the full URL to the default.asp page (e.g., http://danes_domain/default.asp). If the browser displays the page, return to the MMC and define default.asp as a default document: Go to the MMC, right-click the domain, and select Properties. Select the Documents tab, and click Add. Type default.asp, and click OK to add the document to the Documents window. Now click Apply and OK in the domain's Properties window.

Transfer the Developers' Projects to the New Domain
The team gave all application developers domain Administrator permissions so that they can create projects and Web sites in their domain. Developers were responsible for publishing their projects from their former location to their new domain.

If you're using Visual InterDev, the easiest way to import an existing project is to open it in Visual InterDev and select New Deployment Target from the Project menu. Type the URL of the new site (e.g., http://danes_domain/carriagesupply). After Visual InterDev has catalogued the project, select Deploy Solution from the Project menu. Visual InterDev publishes the project—complete with all content, pictures, and application directories—to the new server. In the MMC, the project appears as a subdirectory under the developer's domain, or application server.

Making It All Work Together
As I explained in the host header article, the DNS and the HOSTS file can't specify a port number, only an IP address and its textual alias (i.e., the domain name). If an IP address and a port number specify a Web site's identity, you must type in that numeric address (e.g., http://205.174.179.101:1244) every time. This numeric address doesn't give you any information about the site. By contrast, a URL such as http://danes_domain/carriagesupply tells the user both the developer and the name of the Web site. Using the host header as part of the Web site's identity lets you use the default port (i.e., port 80) and create many Web sites that all use the same IP address. So, instead of having to support several development servers, the company can combine several developers on one server and at the same time facilitate keeping track of all the projects under development.

The solution continues to evolve. Because this company's management wanted to be able to view Web projects under development at any time, the team decided that all developers would keep a home page in the root of their development domain with links to each of their Web projects. Because the home page is HTML, you can easily add notes about each project in one convenient location.

This idea has grown a lot since I completed this project. Today, the developers' home page has a list of all their projects, and each project has a status page. Each project's status page has links to everything related to the project, including the client agreement, the project plan (dates, deliverables, and status), and links to one or more versions of the project. The home page idea worked so well in the developers' Web domains that the development manager started publishing the work schedules, planned publishing schedule, departmental milestones, and kudos announcements on the Application Development Web domain home page.

Giving the developers ownership of their projects and a Web domain to put them in helped management understand its developers' activities and progress. Having individual domains helped developers get all their applications' ducks in a row. Using host headers to pack all those development domains on two servers saved the company the cost of multiple development servers and the cost of administering and backing up multiple servers.