Content Management Server - Ford Motor Company Technical Deployment Guide

On This Page

Introduction
Project Overview
Timeline
Content Migration
Site Architecture
MSCMS Web Site Structure for Ford.com
Infrastructure Architecture
Site Deployment
Stress Testing
Performance
Summary

Introduction

Ford Motor Company's vision is to become the world's leading consumer company for automotive products and services. Core to that vision is building relationships through various customer touch points, including the Internet. The Internet is viewed as strategic to Ford Motor Company because of the mass of current and potential customers online, and the fact that it provides the company with a mechanism to track online usage patterns in order to better understand users' needs and wants.

Ford Motor Company's Internet presence is spearheaded by its flagship Web site at https://www.ford.com (Ford.com). Ford.com is the most visible and heavily visited Web site of the over 200 sites within the organization. Ford.com exists for three primary reasons:

• To build awareness of Ford Motor Company brands

• To represent the Ford Motor Company trust mark values

• To drive high-value traffic to the downstream Web sites (brand sites, international sites, purchasing sites, dealer sites, service sites, and ownership sites)

In the early part of 2000, Ford.com developed with a Java-based content management tool on top of Microsoft® Windows® 2000. The rewritten Ford.com Web site was launched at the end of 2000. However, the site proved unable to meet business expectations in the following areas:

• Business availability. Ford.com ran at 95 percent uptime, which amounts to 18.25 days of downtime per year.

• Business agility. The architecture could not support the business needs of quickly rolling content to production. It generally took one person at least one day to roll new content into production. This issue froze content on the site over stretches of time. It later stabilized, but the company then rolled new content to production only every two or three days because of the effort involved.

• Operational costs. Because of early outages, and because the content management tool was not designed for easy operation, Ford.com required two to three contract software engineers and one support person just to monitor the availability of the Web site. This level of dedicated support was significantly more than the support required for the other Ford Motor Company Web site properties.

• Hardware costs. With the previous content management tool, the Ford.com site required a large and costly server infrastructure of 10 quad-processor Web servers.

With the focus on trying to resolve the preceding issues, the Ford.com team was unable to deliver some critical business features to customers.

Microsoft Consulting Services (MCS) proposed to build the next generation of Ford.com to address these issues, and to work with Ford Motor Company to build a cohesive vision for the future of the Web site. Razorfish Inc., creative agency for Ford.com, was engaged to help with the design and layout of the site. For this project, MCS offered Microsoft Content Management Server (MSCMS) 2001, a comprehensive system that enables companies to quickly and efficiently build, manage, and deploy dynamic Web content.

Business goals of the new collaboration were to reduce the costs associated with operating and maintaining Ford.com, restore Ford Motor Company's agility in delivering fresh and relevant content to its user base, and provide Ford Motor Company with a comprehensive, long-term roadmap for advancing its site. In addition, the new site needed to be deployed rapidly.

Content Management Server provided the capability to meet these goals. The benefits of basing the Ford.com site on MSMCS were as follows:

• Business availability. The new Ford.com site has achieved 100 percent uptime to date.

• Business agility. The architecture has been able to support the need to add new content quickly. For example, for the section of Ford.com that is devoted to the Detroit 2002 North American International Auto Show, new content could be rolled out daily to incorporate the latest updates about the show.

• Operational costs. Business users can easily manage their own content without needing to involve an engineer in the process.

• Hardware costs. The new site runs on four quad Web servers and one database server, reducing the previous infrastructure by 60 percent.

Project Overview

Ford.com is the gateway to the other products and services offered by Ford Motor Company. It provides customers with the ability to navigate to vehicle information, corporate information, services information, and other brand Web sites.

One of the main reasons Ford Motor Company chose to use Content Management Server was the out-of-the-box functionality that the product provides. In particular, the company took advantage of the following features of Content Management Server:

• Built-in workflow system

• Web-based authoring

• Dynamic server load balancing

• Ease of development

• Connected pages

• Custom properties

Although Ford Motor Company was able to use the out-of-the-box features of Content Management Server, the company was also able to easily integrate Web applications like a shopping guide, vehicle recall information, a search engine, and a link for sending e-mail to the company.

Figure 1 shows the home page of the site built with Content Management Server.

Figure 1: The Current Ford.com Web Site

Timeline

A well-coordinated effort was required to deliver the solution rapidly—in 13 weeks. The project was a joint development effort between Microsoft Consulting Services and Ford Motor Company's internal development organization. In addition, this project was dependent on a parallel project with the Ford data center, where the Ford.com Web site would reside. To ensure timely delivery, the Microsoft Solutions Framework was used to complement and frame Ford's existing development methodologies.

The envisioning phase of the project began with a project kick-off meeting in September 2001, and lasted through week two. The envisioning phase served as the first deep phase of knowledge transfer to the technical and business teams on the capabilities of Content Management Server. Deliverables created in this phase included the following:

• Project Charter. This document served as an early form of planning, capturing what the customer and stakeholders deemed essential for the success of Ford.com.

• Risk Assessment Document. An initial risk assessment was performed in the envisioning phase, and was managed throughout the duration of the project.

The planning phase began in week three, and lasted until week five. The planning phase involved the creation of the following deliverables:

• Ford.com functional specification. Detailed the functional requirements of the Web site.

• Ford.com architecture document. Detailed the network, server, and security architecture for the development, quality assurance (QA), authoring, and production environments.

• Ford.com technical specifications. Detailed application architecture and design for how the Web site would be built. Separate specifications were created for each functionality: content management, shopping guide, vehicle recall, search, e-mail, and reporting.

• Master Project Schedule. Described the tasks associated with all team roles, including development, product management, testing, logistics, and user education.

• Revised Risk Assessment document. Provided an updated representation of project risks.

• Development and QA environments. The development and testing environments were built in this phase in preparation for the next phase.

The developing phase began in week six and lasted through week nine, culminating in the Scope Complete milestone. The developing phase focused on the following deliverables:

• MSCMS implementation. Encompassed the entire MSCMS implementation, including the creation of folders, channels, templates, and Web Author customizations.

• Content migration. Scripted import of the content from the existing Web site into MSCMS.

• Content tweaking. Included post-import activities to clean up any anomalies from the automated content import.

• Application development and integration. Integration of search, vehicle recall, and shopping guide functionality, which required the rewriting of some applications.

• Content author/editor training. Training of content authors and editors so that they could begin changing and auditing content after it was imported.

• Developer training. Initial developer training with the Ford Motor Company team that would contribute to the MSCMS implementation.

• Unit testing. First rounds of coverage testing were performed on the feature set.

The stabilizing phase began in week 10 and lasted through launch in week 13. The stabilizing phase focused on identifying and resolving bugs, and readying the site for launch. The following activities were performed:

• Integration testing. Integration testing was performed to ensure that MSCMS, in addition to the shopping guide, vehicle recall, search, e-mail, and reporting Web applications, met the functional and technical requirements identified in the planning phase.

• Load and stress testing. The Web site was tested against the load and stress metrics established during the planning phase.

• Deployment testing. Included testing the various deployment processes throughout each environment and into production under load.

• Building authoring and production environments. The authoring and production environments were completed during this phase in preparation for site launch.

• Environment audits. Final network, server, security, and application audits were performed to ensure that the site was ready for launch.

• Deploying the production environment. Consisted of making the necessary Domain Name System (DNS) changes to reroute Ford.com traffic to the new environment.

Figure 2 is a visual representation of the project timeline.

Figure 2: Timeline for Using MSCMS to Create the Ford.com Site

Content Migration

Through the use of ASP and the MSCMS Publishing application programming interface (API), Microsoft Consulting Services was able to automate the migration of existing Ford.com content and resources into the new MSCMS-based site. Rapid deployment is an important feature of MSCMS, as demonstrated in the migration process for Ford.com: MCS wrote an ASP script that traversed and parsed hundreds of Extensible Markup Language (XML) files—which represented the existing Web pages—and then imported the content into MSCMS by using an MSCMS template.

Approximately 70 percent of the existing Web content was able to be imported automatically into MSCMS. The script took only 15 minutes to import over 500 pages of content into 90 channels. The following paragraphs describe the process in greater detail.

Getting the Content

Because the content for the original Ford.com site was stored in a Java-based content management system, the first step in the migration process was to export all the content to XML files. This made writing the actual import script easier and compatible with ASP and the MSCMS Publishing API, because the development team could use the MSXML object to traverse each XML document, instead of possibly needing to write a component to query the Java-based system for the required data.

The actual Hypertext Markup Language (HTML) content was wrapped in the <content> node of the XML document, and during the import, the content was saved to the content well placeholder of the special template that the development team created. A placeholder is an object that accepts content within a template.

In addition to the main content, the script could map other XML nodes to the MSCMS system. The following table provides a few examples of how MCS mapped the values of several XML nodes to the Custom Properties of an MSCMS page. MSCMS Custom Properties are user-definable metadata that can be applied to pages and channels, and are often used to classify the content on a page.

XML nodes	MSCMS Custom Properties
<pagename>	Posting.DisplayName
<metakeyword>	Keywords
<description>	Posting.Description
<faqsection>	FAQ Section

Site Structure

The navigational architecture of Ford.com is made up of channels, each of which is an MSCMS container for postings. The channel structure of the new MSCMS-based site was designed to match the existing site structure, which was represented by <section> and <level #> elements in the XML files. Essentially, the script placed each of the new MSCMS pages in the channel structure according to the <section> and <level#> elements. The script searched for an object corresponding to the path indicated to determine whether the new page would become the default page for a channel or a normal page in the channel.

For example, <section>ourServices</section> and <level2>fordDirect</level2> translated to a new Uniform Resource Locator (URL) of /ourServices/fordDirect.htm because there wasn't a channel at /ourServices/fordDirect. On the other hand, <section>ourCompany</section*>* and <level2>investorInformation</level2> translated to a new URL of /ourCompany/investorInformation/default.htm because there was a channel at /ourCompany/investorInformation.

Links and Resources

During the import process, after the content was saved into the placeholder, a separate logic in the script went through the site and changed existing links in the form of (href="index.jsp?SECTION=ourServices&LEVEL2=fordDirect") to a best guess at the new URL (href="/ourServices/fordDirect.htm" or href= "/ourServices/fordDirect/default.htm"). If a page to link to was not found, an error was logged.

The resource gallery structure was built prior to the bulk import. The resource gallery path was derived from the <url> attribute of the XML document. When a resource was successfully moved, the XML document was also moved to determine whether any resources were not imported successfully. Files with no specified path were placed in the root resource gallery.

In addition to parsing the existing links, the script resolved references to resources by checking to determine whether the images found in placeholders were already in the resource gallery. If not, the script uploaded a new resource into the gallery. Also, all the image paths referenced in the HTML source code were updated to point at the MSCMS resources.

Site Architecture

Content Management Server runs on all Web servers for Ford.com, and interacts with a database server. As mentioned previously, the Ford.com application consists of a number of components. The following list describes these components—all of which are custom applications, and the first four of which are integrated with MSCMS by means of a template:

• Shopping Guide. Stores and retrieves database information with the server in a database that is separate from MSCMS.

• Vehicle Recall. Retrieves recall information from https://www.ownerconnection.com through Simple Object Access Protocol (SOAP) calls. For this functionality, the SOAP toolkit is required on all Web servers. Ownerconnection.com is a business-to-consumer Web site that provides vehicle owners with maintenance information, safety tips, service reminders, do-it-yourself pointers, and, in many cases, online manuals and warranty guides.

• Search. Processes search requests by remotely connecting to the Ultraseek search server through the ServerXMLHTTP feature in Microsoft XML 3.0.

• E-mail. Processes e-mail forms integrated into MSCMS. The e-mail forms collect information from users, create an e-mail message, and send the e-mail message by using Collaboration Data Objects (CDO) for Windows 2000 running on each Web server.

• Reporting. Provides the ability to integrate with the current site analysis tool.

Figure 3 shows the flow of information through the architecture of the Ford.com application.

Figure 3: Architecture of the MSCMS-Based Ford.com Site

File System Directory Structure

All MSCMS content, templates, resources, and user rights and roles are stored in the MSCMS database. Functional code contained in include files is stored on the file system.

The following hierarchy map represents the file system for the Ford.com site. The MSCMS installation maps the top-level folder, IIS_NR, to the /NR directory in Internet Information Services (IIS).

Note: This section describes the architecture of the file system directory structure for Ford.com. For a description of the MSCMS container structure, see the "MSCMS Web Site Structure for Ford.com" section later in this paper.

IIS_NR

fordcom

css

login

images

en

global

brand_logos

form_buttons

header

left_nav

top_nav

Web_author

our_company

our_services

our_vehicles

includes

script

Shopping Guide

The Ford.com site provides a shopping guide (shown in Figure 4) so that consumers can choose vehicle traits and receive a list of vehicles that most closely match those traits. It also includes functionality to compare different vehicles through the Yahoo vehicle comparator. For users who haven't decided on a particular vehicle, the shopping guide asks a series of lifestyle questions and selects the vehicles that most represent individual lifestyles.

Figure 4: Ford.com Shopping Guide

Architecture

The shopping guide consists of the following application components:

• A Web page implemented as an MSCMS template that contains the presentation of the shopping guide questions and results

• A series of Microsoft SQL Server™ database tables that house the vehicle data and rankings as compared with the shopping guide questions

• A SQL Server stored procedure that provides the business logic for calculating the vehicle rankings based on how a user answers the shopping guide questions

• A Component Object Model + (COM+) component that resides on each Web server and provides database access from the MSCMS-based Web page to the database

The COM+ component is based on the Fitch & Mather database access layer found at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfmstock/html/fm2ksetup.asp. The COM+ component uses Windows authentication for accessing the SQL Server database.

The shopping guide works as follows:

• The user submits answers to the questions presented on the shopping guide Web page.

• Server-side ASP code (running in the MSCMS template) processes the user's request and uses the COM+ component in the data access layer to pass the request data to the SQL Server stored procedure.

• The stored procedure processes the data and returns information about the vehicles that are most relevant to the user based on the user's answers to the shopping guide questions.

• The same MSCMS template reappears, with the results sorted by relevancy.

Vehicle Recall

Vehicle recall allows users to enter their vehicle identification numbers (VINs) to determine whether there are any outstanding recalls for their vehicles.

Architecture

A vehicle recall Web service was created by another team at Ford Motor Company and is available to any of the company's Web sites that need to incorporate vehicle recall functionality. The Web service is based on SOAP technologies, and Ford.com has the SOAP toolkit installed on each Web server.

The vehicle recall Web page is managed within MSCMS. When a user submits a VIN, a server-side ASP script processes the VIN and sends a request to the SOAP server to retrieve any recall information. Recall information is displayed to the user in a results page.

Search

Ford.com allows users to perform text-based searches for content located on Ford.com and on other Ford Motor Company Web site properties.

Architecture

The previous Ford.com architecture used a remote Ultraseek search server, but required a JavaBean™ installed on each Web server (which required Java application server software). For a cleaner architecture, Ford Motor Company decided to remove the requirement of having Java installed on each Web server, and instead to communicate with the Ultraseek server by using XML over Hypertext Transfer Protocol (HTTP).

MSCMS manages the search Web pages and uses ASP to process the search requests and display the results. ASP uses the ServerXMLHTTP feature of Microsoft XML 3.0 to pass requests to the Ultraseek search server.

E-Mail

Ford.com allows users to contact, through e-mail, the Ford Motor Company brands and services for support on a variety of topics. Information is collected from the user by means of secure Web forms (HTTP Secure, or HTTPS), and is submitted to the Ford Motor Company call center for processing. All future communications are made between the call center and the user directly through e-mail or some other mechanism.

Architecture

E-mail forms are maintained in MSCMS. A restricted-use e-mail template was created in MSCMS to house the ASP script used to process e-mail messages, and to dynamically present the required form fields for the e-mail topic. ASP uses CDO for Windows 2000 to send the messages to the call center through the Simple Mail Transfer Protocol (SMTP) service installed as part of IIS. The SMTP service was configured to use Open Database Connectivity (ODBC) logging to a database table in the application database for reporting purposes.

The decision to use ODBC logging versus file-based logging was made after balancing the low e-mail volume with the savings of having to write custom code to log the e-mail messages into a database for reporting. For sites with a high volume of e-mail traffic, file-based SMTP logging is recommended as a best practice. These messages are sent, and information is logged to a database table from which activity reports are later generated.

Finally, a Windows 2000 scheduled task was created to generate daily e-mail reports to an internal distribution group at Ford Motor Company.

Reporting

One of the requirements of the new version of Ford.com was to continue to support the various reporting capabilities previously used to analyze the site. This included broken-link software and analysis reporting on offline and online usage.

Architecture

The MSCMS implementation of Ford.com was able to support the existing Ford.com reporting tools, including those that required an Internet Server API (ISAPI) filter to be installed on the public Web site.

MSCMS Web Site Structure for Ford.com

The MSCMS site structure consists of a container structure that is used to display the Web site in the browser, and to organize pages, templates, and resources for authoring. Web designers and developers created the site structure by using the MSCMS Site Builder client shown in Figure 5.

Figure 5: Site Builder Client

Folders

A folder is an MSCMS storage space (a container) where pages are stored. The Ford.com folder hierarchy is defined according to the needs of controlling the authoring and editing process, in addition to site organization.

Channels

The channel structure forms the navigational architecture of Ford.com. A channel controls both how users browse through the site and how these users are restricted from accessing various parts of the site, depending on their authorization levels. Because of this, a page is not viewable on the site until a posting of a page is created in the appropriate channel. Because Ford.com is a public site, all users can browse all parts of the site.

Although folders can have an independent structure from channels, the Ford.com team generally followed the best practice of keeping the folder structure and channel structure the same for consistency and easier site management. The exception to this convention on the Ford.com site is in the Vehicle Showroom section. All of the vehicle detail pages are kept in a single folder (/Folders/en/ourVehicles/allVehicles). However, there are multiple channels for these vehicles (for example, allVehicles, 2DoorCoupes, sedans). This discrepancy between the folder and channel structures arose because each vehicle has a single page, but may be posted in multiple channels (through the Connected Pages feature of MSCMS).

Resource Gallery

The Ford.com resource gallery is a container to organize and control access to Ford.com resources. The resource gallery is broken down at a high level according to the site map (channel structure). There are special galleries for "Global" resources (generic images) and "Home" resources (images specific to the home page). Below the top level, the galleries have been broken down further depending on whether or not the subsection has enough unique images to warrant a new gallery. There may also be subgalleries simply for organization.

In general, it is a best practice to keep the number of resources in a single gallery to fewer than 250, because more images are more time-consuming for users to find, and because Site Builder slows considerably when browsing containers with more than 250 items. Access for authors and editors to add images to their content is controlled at the gallery (container) level, so images that need to be restricted should be placed in separate galleries. In addition, Ford.com restricts placeholders so that only images from the resource gallery (rather than from a user's computer) are accepted.

Template Gallery

The template gallery provided in Content Management Server is a container to organize and control access to templates. Most pages on the Ford.com site are based on templates in the "Content Templates" gallery. The following table lists the content templates and their uses.

Template name	Template use
Content Well Normal	Used for "standard" pages on the site. This template includes a single placeholder for the main HTML content. It will accept an optional header image to place above the content. If that is not specified, the template will generate a header by using the Display Name property given to the page, and the correct background color for the site section. Pages based on this template have a Related Topics bar down the right side and can also have varying items in the Vehicle Selector area (for example, Vehicle Selector, Contact Info, or Stock Quote). Classification for related topics is done through the use of MSCMS custom properties. You can see an example of the Contact Info area on the Ford Firestone Wilderness AT page, and an example of the Stock Quote area on the Investor Information pages.
Content Well Simple	Similar to the Content Well Normal template, but without the Related Topics bar. This template also includes the option (in Custom Properties) to use an automatic 8-pixel left margin in the main content area. The default value for this is TRUE and is suitable for content that contains text. Setting this value to FALSE may be useful for content that needs no left margin, such as the Detroit 2002 North American International Auto Show page. The use of the header functionality described in Content Well Normal is also optional in the Content Well Simple template. If a page does not have a standard header image and does not need a generated text header, the author can omit the header by setting the Use Header property to FALSE. An example of this can also be found on the Detroit 2002 North American International Auto Show page.
Vehicle Detail	This template is used for all of the main vehicle pages on the site. It accepts a main vehicle image as well as paths to the external links to use for each of the vehicle links. The external link pages needed for a vehicle must be created if they don't already exist. (For more information about external links, see the "External Link Gallery" section of this paper.) The Custom Properties for a vehicle detail page must be used to specify make and model. The shopping guide statistics for the vehicle are also stored in the Custom Properties on this template.

External Link Gallery

Another gallery that will be frequently used is the "External Link" gallery, which contains the External Link template. Pages based on this template are used as a means to store, maintain, and track external links—those outside Ford.com.

The External Link template was implemented to add the ability to manage links to pages that do not exist on Ford.com, such as a link to https://www.hertz.com. This is not out-of-the-box functionality with Content Management Server, but is a good solution for managing external links.

The template accepts a single text field with the URL of an external link. The behavior of the external URL depends on the mode in which the site is viewed. If the site is viewed in live mode—which allows navigation of the site and viewing of all published pages—the page will redirect immediately to the external URL specified. If the site is viewed in edit mode—which allows viewing of all pages, whether or not they are published—the external URL will be displayed (and can be changed).

Modifying an MSCMS-Based Site

Content Management Server includes a browser-based application called Web Author, which allows certain users to add, edit, and delete pages on an MSCMS-based Web site. The procedures for performing these tasks are part of standard MSCMS functionality.

To enable authors (and others, such as editors and administrators) to create and modify pages, the Ford.com development team used the Custom Properties feature in Content Management Server to add custom properties for the authors to use. For example, a Ford.com author can create a vehicle detail page and add the correct make and model for a car, and the page will automatically display the correct brand logos and the correct name.

To modify content on Ford.com, authors must first log in to the site. These users log in through the authoring environment and do not log in directly into the production environment, for security reasons and so that they can test the results of new content before deploying it to production. (For more information about the environments that support the Ford.com site, see the "Infrastructure Architecture" section later in this paper.)

The Ford.com login page prompts users for domain, user name, and password, which are stored in a Windows 2000 Active Directory® directory service store. Figure 6 shows the login screen.

Figure 6: Login Screen for Authoring on Ford.com

When the author first logs in, the Ford.com authoring environment opens in live (published) mode. To create or edit content, the author must switch to edit (unpublished) mode. Figure 7 shows the button that appears when the author logs in, allowing the author to switch to edit mode.

Figure 7: Where to Click to Switch to Edit Mode on Ford.com

Creating a Page

After the author logs in, switches to edit mode, and navigates to the desired location, creating a page in the Web Author consists of four steps:

1. In the drop-down list, click Create New Page.

   

2. Select a template on which to base the content.

   

3. Add content into the placeholders.

   

4. In the drop-down list, click Save or Save and Exit, and then give the page a name.

   

Editing a Page

After the author logs in to the authoring environment and navigates to the page that he or she wants to edit, editing content consists of three steps:

1. In the drop-down list, click Edit.

   

2. Edit the content.

   

3. In the drop-down list, click Save or Save and Exit.

   

Workflow

Ford.com is managed by using a two-step workflow process. First, Ford.com business users create content by using the Ford.com Web Author, as described previously. Then, business managers approve content created by the business users to be published on the site.

Content Management Server actually provides three workflow steps; the third is using moderators. Moderators are those people in charge of when the page is published and expired on the Web site. The Ford.com team may use the Publishing API in future versions to support additional steps, such as translation and legal approval. In addition, deployment can be thought of as a third step in the current version of the site: A person with deployment capabilities reviews the approved pages before deploying them.

Infrastructure Architecture

Four environments support the Ford.com Web site: development, QA/testing, authoring, and production. Figure 8 shows the architecture of these environments.

Figure 8: Infrastructure (Environment) Architecture of Ford.com

The following table describes the environments that support the Ford.com site.

Environment	Windows 2000 domain that servers are members of	Where servers reside	Activities
Development	DEVDOMAIN	Ford local area network (LAN)	A source code control system is used to maintain source code. No scale-out or redundancy requirements were required here, so the hardware is minimal.
QA/testing	DMZDOMAIN	Perimeter network (also known as DMZ, demilitarized zone, and screened subnet)	In this environment, two Web servers exist purely to provide the ability to test against a "farm" of servers. Although the application is designed to not require server-based session state, it can be confirmed here.
Authoring	DMZDOMAIN	Perimeter network	This server exists purely for adding content. The database for this environment resides on the production database servers (rather than on a separate database server) in an effort to minimize costs.
Production	DMZDOMAIN	Perimeter network	The production environment has a farm of Web servers, primarily for scale-out. However, this environment inherently provides a higher level of availability for the Web servers as well.

During the design of the Ford.com environments, discussion occurred about whether or not to separate the authoring and production environments. Microsoft Consulting Services listed the positive and negative aspects of each option, as shown in the following table.

	Advantages	Disadvantages
Separate environments	· The site can be viewed in its entirety before it is made live on the public site. · The site can then be deployed in its entirety (as a "version") to the public site. · Easier to back up versions of the site, because a database backup could be performed on the production environment before a new version is deployed.	· Additional servers are required. · An additional process is required to make data live on the public site. That is, after data is approved in the authoring environment, it is live in the authoring environment, but still must be deployed to the production environment before it becomes live on the Internet.
One environment	· After a posting is approved, it's live on the Internet; no deployment is necessary. · Fewer servers.	· Not as easy to back up versions, because authoring is allowed on the live site. · Changes in a version cannot all be viewed seamlessly. As soon as postings are approved (together or individually), they're live.

Ford Motor Company chose to separate the environments, primarily because doing so meant that the site could be viewed in its current state prior to deployment to production. Separating the environments is also a best practice, particularly for Internet-facing sites.

Each Web server is configured to run at least three Web sites; QA servers are configured to run four Web sites. The purpose of each of these sites is detailed in the following table.

Web site name	Purpose	Servers
Default Web Site	This is the publicly accessible Web site, listening on port 80/443 with a digital certificate bound to the clustered (if applicable) Internet Protocol (IP) address.	All
MSCMS Server Configuration Tool	This site is used for MSCMS server configuration. It runs on port 7399 (though it could be run on any other port) and can be accessed only from the local server; it cannot be accessed remotely. It is listening on the internal IP address (IP1).	All
MSCMS Authoring	This site is used to deploy MSCMS content to the QA database. All MSCMS content is ultimately placed in a database, but is deployed through a Web server. This normally occurs on the QA1, authoring, and PROD1 servers, but the site exists on all servers in the event that another server needs to be used to deploy content. This site can be accessed only from the Ford LAN, and listens on IP1 on port 80/443. This site requires a digital certificate to encrypt credentials during MSCMS content deployment.	All
File Upload	This site is used to copy files from development through the firewall to the QA servers. It uses WebDAV, which allows encrypted credentials to be passed over port 80/443. (This is unlike File Transfer Protocol [FTP], which sends credentials unencrypted, in clear text, over port 21). This site requires a digital certificate to encrypt credentials during file deployment.	QA1 and QA2 only

Configuration

Ford Motor Company operations personnel (FMCOP) installed the domain controllers for DMZDOMAIN and configured them for pre–Windows 2000 compatible access. This is a requirement for Content Management Server, because it requires an unauthenticated session to a domain controller to enumerate user accounts and groups.

Prior to starting the installation, FMCOP created accounts in DEVDOMAIN and DMZDOMAIN, assigned strong passwords, and granted rights. The following table lists these accounts, their purposes, and the rights, permissions, and roles that they required.

Account name	Purpose	Rights/permissions/roles needed
SQL-SVC	Used as the Microsoft SQL Server 2000 service account	Log on locally, log on as a service (to SQL Server).
MSCMS-SYSTEM	Used as the MSCMS system account	Log on locally (to the MSCMS server).
MSCMS-GUEST	The account that is used when anonymous Internet users browse the Ford.com Web site	Log on locally (to the MSCMS server).
APP	Used by the shopping guide application to access shopping guide data in the database	None.
qa-write (a global security group, not a user)	Allows members of the Ford.com team to move files to the QA servers	NTFS file system Write permissions to the appropriate directories on the QA1 and QA2 servers.
qa-mscms-admins (a global security group, not a user)	Allows members of the Ford.com team to administer the Ford.com MSCMS environment	This group needed to be made a member of the Administrators user role after the MSCMS-based site was configured.
authoring-mscms-admins (a global security group, not a user)	Allows members of the Ford.com team to administer the Ford.com authoring MSCMS environment	This group needed to be made a member of the Administrators user role after the MSCMS-based site was configured.
prod-mscms-admins (a global security group, not a user)	Allows members of the Ford.com team to administer the Ford.com production MSCMS environment	This group needed to be made a member of the Administrators user role after the MSCMS-based site was configured.

There are three "classes" of servers in the Ford.com architecture: Web servers, database servers, and search servers. The following table lists the servers that belong to each class. All the servers in a class are configured identically, aside from server-specific and environment-specific information (for example, server names, IP addresses, and databases they're configured to use).

Class	Servers
Database	DEV-DB, QA-DB, PROD-DB
Web	QA1, QA2, AUTHORING, PROD1, PROD2, PROD3, PROD4
Search	PRODSEARCH

FMCOP configured the servers in the order provided in the sections that follow. It is important to note that security is best applied in layers. The server installation processes for Ford.com thus incorporated security configuration best practices throughout. However, the following sections do not include suggestions for disabling services, setting logging/auditing properties, and other activities that can be (and should be for manageability) done within Windows 2000 Group Policy. A secure server configuration, coupled with strong Windows 2000 domain–based Group Policy, use of additional tools (such as IISLockdown and URLScan), and strong operational processes (such as monitoring and auditing, hotfix and service pack maintenance), highly increases the security and availability of servers.

General Server Configuration

FMCOP formatted all of the hard disks on the servers with NTFS and made the servers members of the appropriate Windows 2000 domain. For details, see Figure 9 later in the paper.

Database Configuration

FMCOP installed Windows 2000 with SP2 and SQL Server 2000 with SP1. The database that MSCMS would later use was created for the appropriate environment, as shown later in Figure 9. A SQL account (Windows authentication) for the Windows 2000 account MSCMS-SYSTEM was created and granted db_datareader and db_datawriter permissions on the appropriate MSCMS database for each environment. The application database for the appropriate environment (also shown in Figure 9) was then created. A SQL account (Windows authentication) for the Windows 2000 account APP was created and granted db_datareader and db_datawriter permissions on the application database.

To support SMTP service ODBC logging of sent mail, a table called MAIL_LOGGING was created. The table definition is standard for IIS ODBC logging and can be found in Microsoft Knowledge Base article 245243. FMCOP created a role for this database called role_mail_logging. This role was given the ability to insert and update the MAIL_LOGGING table in the *xx_*APP database (where xx is the current environment).

A SQL login (SQL authentication) called email_logger was created and assigned permissions to use the xx_APP database. Additionally, in the Database Roles box, the mail_logging role was selected. This step and the previous step were required in order to use the SMTP ODBC logging functionality in IIS, because this functionality requires a SQL Server account instead of a Windows 2000 account. This configuration gave the SQL Server login account the minimal permissions necessary to facilitate proper functionality.

Web Configuration

The Web servers were configured with two mirrored sets of drives. One mirrored set has two partitions, one has one partition. The operating system and page file were installed on the C partition on mirrored set 1. MSCMS was installed on the D partition on mirrored set 1, as was the IIS root directory. It is recommended that the IIS directory structure exist on a separate partition than the operating system for extra security. The E partition on mirrored set 2 was used for IIS logging only, but was separated onto its own mirrored set for performance.

An ODBC data source named "application" was configured to the application database for the appropriate environment. This ODBC data source was configured to use SQL authentication, with no user credentials specified.

FMCOP created a directory called /file_transfer on the QA1 and QA2 servers only so that the development team could copy files that supported the site through the firewall. (The operational policies of Ford Motor Company require that developers write files only to the QA servers. After the files are on the QA servers, FMCOP can use Terminal Services to connect to the QA servers and then copy the files through traditional drive mappings to the internal interfaces of the Web servers in the other environments.) NTFS permissions were set on this directory so that the qa-write group could read/write files to it.

On each server, Web sites with the properties listed in the following table were created. The Web site called Default Web Site was left intact from the IIS installation. This site allows the MSCMS SCA administration tool to be run only on the local server (it will not be possible to run the tool remotely). This site does not use a digital certificate. The site's IP Address and Domain name restrictions setting is configured for access from the local server only.

Property	Value
IP address	The IP address for the internally facing network interface card (referenced as IP1)
Port	7399 (an arbitrary port)
Directory	D:\Website
Description	MSCMS Server Configuration Tool
Other	Clear the Allow anonymous check box

As a general practice, content is deployed through only the QA1, AUTHORING, and PROD1 servers because content needs to be deployed through only one server per cluster. However, the Web site used to deploy MSCMS content exists on all servers so that if the primary deployment server fails, content can be deployed through another server in the cluster. The properties listed in the following table are for this Web site.

Property	Value
IP address	The IP address for the internally facing network interface card (IP1)
Port	80
Directory	D:\Website
Description	MSCMS Authoring
Other	Leave the Allow anonymous check box selected

The site created only on the QA1 and QA2 servers was configured the for Read, Directory Browsing, Write, and Script source access so that members of the development team could copy files through the firewall to the QA servers. (If Script source access is not configured, .asp files cannot be copied by means of WebDAV.) In addition, the NTFS permissions for the underlying directories were configured with the proper access control lists (ACLs).The properties listed in the following table are for the site created only on the QA1 and QA2 servers.

Property	Value
IP address	IP2 (the second IP address bound to the internal interface)
Port	80
Directory	D:\file_transfer
Description	File Upload
Other	Clear the Allow anonymous check box. In addition, select the Directory Browsing check box. Configure this site to use a digital certificate.

The following general changes were made to IIS:

• Session state was disabled.

• Parent paths were disabled (for security).

• The default ASP error messaging was made less verbose and more user friendly.

The SMTP service was configured to use the ODBC data source called "application" and the EMAIL_LOGGING table created in the database (both created previously). This is so that customers could send e-mail to Ford Motor Company customer service personnel from the Web site. The company wanted to be able to log the messages sent.

MSCMS was installed and configured to use the appropriate xx_MSCMS (where xx is the current environment) database in each environment. During the installation, the Web site called Default Web Site was chosen when asked for a Virtual site for hosting CMS (and Allow authoring was cleared), and the Web site called MSCMS Server Configuration Tool was chosen when asked for a Web Entry Point.

It's important to note that selecting Allow authoring enables the use of the Site Builder tool to write to a Web site (as long as credentials are valid). Because such an ability was not needed on the public-facing Web site, that site was configured for no authoring. The separate MSCMS Authoring site, however, was configured to allow authoring because its sole purpose is content production. The MSCMS Authoring site is configured to accept requests only on an IP address that is configured for a network interface card connected to the back side of the multi-homed Web servers.

The SCA tool was then used to confirm and/or set the settings listed in the following table.

Web site name	Is this an MSCMS-based site?	Servers
Default Web Site	Yes, no authoring	All
MSCMS Server Configuration Tool	No	All
MSCMS Authoring	Yes, with authoring	All
File Upload	No	QA1 and QA2 only

FMCOP required a Secure Sockets Layer (SSL) connection at the Web server for the login page that the MSCMS Site Builder tool authenticates against so that credentials would always be encrypted when sent to the server. The team accomplished this in the Internet Services Manager tool by expanding the default Web site, expanding the /NR directory, expanding the system directory, and then expanding the /ClientUI directory. The team then set the login.asp file to use SSL. Then, for the Site Builder shortcut on each user's desktop that uses Site Builder, the team modified the URL from the default of https://servername to https://servername.

The MSCMS managekey.exe application file was run to export the cookie encryption key from QA1 and PROD1. The application was then run on QA2, PROD2, PROD3, and PROD4 to import the respective keys. This application must be run on every server that is a member of a cluster. MSCMS uses the cookie encryption key to protect data in the resource gallery. If all servers in a cluster do not share that key, users will likely receive errors.

The SOAP toolkit was installed to support the application's SOAP call to remote servers for vehicle recall information.

Finally, the IISLockdown tool was used to secure the servers and to install URLScan. In the IISLockdown wizard, the Ford.com team chose not to disable ASP, because some ASP pages were part of the application. Even when a decision is made to leave WebDAV enabled in the IISLockdown wizard, the resulting urlscan.ini file is not set properly to support WebDAV. Therefore, all of the disabled HTTP verbs that would be in the resulting urlscan.ini file were enabled for WebDAV to work properly on the Ford.com site. However, this was an issue only on the QA1 and QA2 servers, because WebDAV was not used (was disabled) on all of the other servers.

In addition, it is important to note that by default, the urlscan.ini file will not allow certain file extensions. After installation, this file should be checked to ensure that no necessary file extensions are disabled. The Ford.com team verified that the default disabled extensions were correct.

Site Deployment

Each time Ford Motor Company deploys content to its Ford.com Web site, the company considers the content to be a "version" of the site. Because the Ford.com site actually consists of a number of elements (that is, a database to support the shopping guide, content that's managed by MSCMS, files on the file system that are part of the site but not managed through MSCMS, and a COM object for database connectivity), it actually has versions of each of these subcomponents. Each subcomponent has a different deployment mechanism.

The database connection object rarely changes. The Ford.com team did not address a specific process for the deployment of the database connection object, because it was the only COM object on the site. Instead, the team focused on the process for deploying the other three subcomponents. Figure 9 illustrates the process.

In Figure 9, a number indicates that this "set" of letters is typically completed concurrently. A letter indicates the activity being completed; that is, all steps containing the same letter are essentially the same process. (Number/letter combinations are defined in the "Flow of MSCMS Content and Structure" section later in this paper.) A single or double asterisk indicates a part of the process that is illustrated in more detail in Figure 10 and Figure 11, respectively.

Figure 9: Site Deployment

To make Figure 9 easier to follow, content was shown moving directly from MSCMS database to MSCMS database. In reality, that process happens as follows:

1. When deploying MSCMS content, the Site Builder tool is used to connect to a Web server running MSCMS. After the items to be deployed are chosen, MSCMS extracts the items from the database, packages them into a file with an .rop extension, and writes the .rop file to the workstation that is running Site Builder. This process happens over port 80 or 443.

2. Site Builder uploads the .rop file a Web server running MSCMS in the destination environment, unpacks the file, and adds that exported content to the MSCMS database of the destination environment. This process also occurs over port 80 or 443.

These steps are illustrated in Figure 10.

Figure 10: Content Flow

Again, to make Figure 9 easier to follow, site designers and content authors were shown working directly with the MSCMS database. In reality, that process happens as illustrated in Figure 11. The site designer or content author works through a Web server running MSCMS, which actually modifies the content in the MSCMS database. Nobody should ever directly modify the MSCMS database.

Figure 11: How Content in the MSCMS Database Is Modified

The MSCMS-based Ford.com Web site was created by, and is maintained by, a number of people who fill a total of seven roles. The following table details each of these roles.

Role	Functions/responsibilities
Developer	Develops ASP code and COM objects by using Microsoft Visual Basic® or Microsoft Visual C++®
Site designer	Designs the site based on knowledge of the MSCMS product and fluency in HTML
Operations	Has some level of administrative access to all the servers
Producer	Adds content to the site through the Web Author and administers MSCMS
Database administrator (DBA)	Administers the application database
Administrative business user	Deploys content from authoring to production

If the Ford.com site grows, or its requirements or business processes change, it may become necessary to alter the roles as follows:

• Separate the role of producer into two roles (one that adds content to the site and one that administers MSCMS)

• Separate the site designer role into two roles (one that designs the site and one that creates templates)

Each of these roles performs a function or functions shown in Figure 9. Those functions are defined in detail later in this paper. It is important to note, however, that a number of the functions defined for the roles involved with the Ford.com site are specific to the policies and procedures in place at Ford Motor Company, and do not reflect the technical requirements of every type of business Web site.

Flow of MSCMS Content and Structure

MSCMS content and structure are defined as anything that resides in the MSCMS database. The following table describes what happens in number/letter combinations previously shown in Figure 9. These are the steps taken every time the Ford.com team deploys content. (Note: When it is mentioned that content is propagated from one environment to the next, such content is propagated only from or to one server in each cluster. It is not necessary to involve other servers because all servers in a cluster share the same MSCMS database.)

Step	What's happening	Who does it?	What rights do they need?
1B	The folders, channels, pages, and postings that make up the site are created. Templates are created and managed by using a source control management system. They are checked in and out of the system and imported into the development MSCMS system.	Site designers	Check-in/check-out rights to the source control system and assignment to the MSCMS Administrators role for the development environment.
2E	Using the Site Builder tool, the portion of the site that is later to be published (typically when new pages or channels have been added) is propagated to the QA/testing environment for QA testing. Note: There may be portions of the site still in development that the Site Designer is not ready to publish yet, so those portions will not be propagated. This step is completed in a synchronized fashion with steps 2D and 2F (explained later), but only if files or the database changes. After initial deployment, content will change much more frequently than will either the files or the database.	Site designers	Assignment to the MSCMS Administrators role in both the development and QA/testing environments.
3E	If the site passes QA testing, the entire MSCMS-based site (without content) is propagated to the authoring environment (by using Site Builder) so that content can be added. Note: Content is never deployed from the QA environment to the authoring environment, because the authoring environment will always have newer content than QA. If, for example, a new channel were added to the site, content would be added to it here. This step is completed in a synchronized fashion with steps 3D and 3F (explained later), but only if files or the database changes. After initial deployment, content will change much more frequently than will either the files or the database.	Operations	Assignment to the MSCMS Administrators role in both the QA and authoring environments.
4G	Now that the site and its content have been tested and propagated to the authoring environment, content authors can use the Web Author to add content.	Producers	Assignment to the MSCMS Administrators role in the authoring environment. (They could actually be assigned to a role with fewer permissions; however, all Ford.com content authors are also administrators of MSCMS.)
5E	A Web page exists on the authoring server. MCS built a custom deployment (.vbs) script that this Web page calls to execute an incremental deployment of MSCMS content (that is, content that changed since the last time it was run), deploying the content from the authoring environment to the production environment. Note: Although this script deploys changed content, it doesn't necessarily deploy new templates that may be on the server since the last deployment. Deploying content inherently also deploys the templates that the content relies on. In a situation where a template changed in the authoring environment and needs to go to production, a content author would simply need to open a posting that relied on the changed template, and then save it. This would cause the incremental deployment script to consider the changed posting to be new content, and it would deploy the content (therefore also deploying the template that this new content relies on). Though this could be done by using the Site Builder tool, this configuration makes it very easy for a content author to deploy content to production. This step is completed in a synchronized fashion with steps 5D and 5F (explained later), but only if files or the database changes. After initial deployment, content will change much more frequently than will either the files or the database.	Producers	Assignment to the MSCMS Administrators role in both the authoring and production environments.
6E	Periodically, content is pushed back to the development environment so that developers have somewhat current content to work with when developing new functionality or modifying existing functionality. It is important to note that because shipping the content back will also take the templates with it, newer versions of templates in the development environment (versions that have not yet been through the QA process and deployed to authoring) may be overwritten. When this process is executed, site designers know that they need to get the latest version of all their templates out of the source control system and re-upload them into the MSCMS database of the development environment. This way, the site designers have the new content and the newest templates.	Producers or site designers	Assignment to the MSCMS Administrators role in both the development and authoring environments.

Flow of All Other Site Content

As discussed previously, the Ford.com Web site is made up of MSCMS content, files on the file system, data (database tables used for the shopping guide), and COM objects. The following table describes what happens in number/letter combinations previously shown in Figure 9. Because there is only one COM object—the database lookup object—and it will rarely (if ever) change, detail is not provided on COM object deployment. However, if there were more COM objects, a tool such as Microsoft Application Center 2000 could be used.

Step	What's happening	Who does it?	What rights do they need?
1A	Code and navigation templates that are required for the site's proper operation, but that do not reside in MSCMS, are created and placed on the file system.	Developers and/or site designers	Modify permissions on the portions of the file system that they must interact with on the DEV server
1C	The table structures and stored procedures are created to support the shopping guide. Initial data import is also completed.	DBAs or developers	SQL Server 2000 DBO permissions for the DEV_APP database
2D	The files are moved by means of WebDAV to the QA1 and QA2 servers for QA testing. This is completed in a synchronized fashion with both the MSCMS content propagation (step 2E) and the application database propagation (step 2F).	Site designers or developers	Modify permissions on the portions of the file system that they must interact with on the DEV, QA1, and QA2 servers
2F	The entire database is propagated to the perimeter network's QA-DB server for QA testing. This is completed in a synchronized fashion with both the MSCMS content propagation (step 2E) and file propagation (step 2D). Note: After a site is launched, the database structure will rarely change; this step will be completed only if the database structure of Ford.com changes.	DBAs or developers	Create database permission for the DEV_APP database on the DEV-DB server, and the QA_APP database on the QA-DB server
3D	The site is QA tested. If it fails, development continues and the site is retested until it passes. After the site passes QA testing, the files are copied from QA1 to the authoring server (although the files could have been copied from QA2, because their file systems contain the same files.) This is completed in a synchronized fashion with both the MSCMS content propagation (step 3E) and the application database propagation (step 3F). Because these servers are in the perimeter network and do not provide WebDAV functionality, operations personnel use Terminal Services to connect to the inside interface of the authoring server, then use traditional drive mappings to connect to the QA1 server to copy the files over. Ford Motor Company operational policy specifies that only operations personnel have the ability to perform this function. Note: After initial deployment, files will rarely change and will be deployed only if they change.	Operations	Modify permissions on the portions of the file system that they must interact with on the QA1 and authoring servers, and Administrator access on at least one of those servers (because Terminal Services is running in Administration mode, which requires administrator-level access)
3F	The entire database is propagated to the PROD-DB server (because the AUTHORING_APP database resides there). This is completed in a synchronized fashion with both the MSCMS content propagation (step 3E) and file propagation (step 3D). Note: After a site is launched, the database structure will rarely change; this step will be completed only if the database structure of Ford.com changes.	Operations or DBAs	Create database permission for the QA_APP database on the QA-DB server, and the AUTHORING_APP database on the PROD-DB server
4H	Content authors may modify the data in the database tables here. The most current data in the database will always reside in the AUTHORING_APP database, so after it is first deployed here, care will be taken in deploying any database structural changes to it that may be necessary in the future.	Producers	db_datareader and db_datawriter permissions to the AUTHORING_APP database
5D	The files are never changed on the authoring server, but are propagated from here to the production environment. The files are copied from the authoring server to the PROD1, PROD2, PROD3, and PROD4 servers. This is completed in a synchronized fashion with both the MSCMS content propagation (step 5E) and the application database propagation (step 5F). Because these servers are in the perimeter network and do not provide WebDAV functionality, operations personnel use Terminal Services to connect to the inside interface of the authoring server, then use traditional drive mappings to connect to the PROD1, PROD2, PROD3, and PROD4 servers to copy the files over. Ford Motor Company operational policy specifies that only operations personnel have the ability to perform this function. Note: After initial deployment, files will rarely change and will be deployed only if they change.	Operations	Modify permissions on the portions of the file system that they must interact with on the AUTHORING, PROD1, PROD2, PROD3, and PROD4 servers, and Administrator access on at least one of those servers (because Terminal Services is running in Administration mode, which requires Administrator-level access)
5F	The entire database is propagated to the PROD-DB server's PROD_APP database. This is completed in a synchronized fashion with both the MSCMS content propagation (step 5E) and file propagation (step 5D). Note: After a site is launched, the database structure will rarely change; this step will be completed only if the database structure or data of Ford.com changes.	Operations or DBAs	Create database permission for the AUTHORING_APP and PROD_APP databases on the PROD-DB server
6F	Periodically, updated data in the application database may be pushed back to the development environment so that developers have fresh data to work with. No real process was defined for this because it will rarely occur, and will therefore likely be handled ad hoc.	Operations or DBAs	Insert, update, and delete permissions for the AUTHORING_APP and DEV_APP databases

Database permissions for the application database were applied based on a cross-section of Ford standards, and user need. Microsoft recommends that all security permissions are applied so that a user is running under the least permissions required to perform his or her tasks.

Stress Testing

The Ford.com site went through two days (specifically, two days, 21 minutes, and eight seconds) of stress testing. The testing team used the Loadrunner tool to stress the site and measure the peak performance of the site. As a result of the two days of testing, the team decided that the site could not be stressed to its full potential due to hardware limitations for the servers running the load-testing software. However, the team determined that the load placed on the MSCMS servers could handle well above the expected amount of traffic at launch time. Therefore, the decision was made that Ford.com was ready for launch.

The following table summarizes the testing results.

	Day 1	Day 2	Total
Total throughput (bytes)	10,857,904,853	10,956,509,276	21,814,414,129
Throughput (bytes/second)	Average: 125,471	Average: 125,173	Average: 125,322
Total hits	4,667,410	4,708,465	9,375,875
Hits per second	Average: 53.935	Average: 53.792	Average: 53.864
Total transactions passed	1,846,095	1,862,871	3,708,966
Total transactions failed	95	470	565
Total transactions canceled	0	75	75

Performance

The main performance objectives for the new Ford.com site were:

• Increase site reliability and availability

• Decrease hardware costs

• Increase the response time to support 250 active concurrent user sessions per CPU with a response time of less than five seconds

During the first three weeks after the MSCMS-based Ford.com site was launched (from December 14, 2001 to January 6, 2002), the site had 100 percent uptime, and accomplished this with 60 percent less hardware. The performance of the site thus well exceeded that of the Java-based site. This is a testament to MSCMS and the performance of the Microsoft Platform.

The following table summarizes the statistics for the three-week period after site launch.

Site
Successful hits for entire site	133,990,454
Average hits per day	5,579,360
Page
Page views	11,502,906
Average page views per day	481,621
Dynamic pages and forms views	1,336,520
Document views	10,166,386
Visit
Visits	2,193,683
Average visits per day	90,854
Average visit length	4 minutes, 38 seconds
Unique visitors	1,700,224
Visitors who visited once	1,498,402
Visitors who visited more than once	201,822

The following list represents a glossary of terms used in the preceding table:

• Average hits per day. Number of successful hits divided by the total number of days in the log file.

• Average page views per day. Number of page views divided by the total number of days in the log file.

• Average visit length. Average of all non-zero-length visits in the reporting period. A zero-length visit occurs when all hits in that visit are logged with the exact same time stamp.

• Average visits per day. Number of visits divided by the total number of days in the log file.

• Document views. Number of hits to pages that are considered documents—not dynamic pages or forms—as defined by the system administrator.

• Dynamic pages and forms views. Number of hits to pages that are considered dynamic pages or forms. Any URL that contains options (as signified by a question mark in the URL) is considered a dynamic page. Any file with a POST command is considered a form.

• Hits. Each file requested by a visitor registers as a hit. There can be several hits on each page. Although the volume of hits reflects the amount of server traffic, it is not an accurate reflection of the number of pages viewed.

• Page view. A hit to any file classified as a page. Contrast the value for "page views" with the value for "successful hits for entire site," which includes hits to files of every type.

• Unique visitors. The total number of distinct visitors during the report period. A unique visitor is identified by IP address, domain name, or cookie.

• Visits. Number of visits to the site. A visit is a series of actions that begins when a visitor views the first page from the server, and ends when the visitor leaves the site or remains idle beyond the idle-time limit. The default idle-time limit is 30 minutes. This time limit can be changed by the system administrator.

• Visitors who visited more than once. Number of visitors who visited the site more than once during the reporting period.

• Visitors who visited once. Number of visitors who visited the site exactly once during the reporting period.

Summary

The Ford.com team accomplished the business goals set during the planning phase. MSCMS provided a content management solution that allowed business users to deliver fresh and relevant content, reduce the costs of operations for the Web site, and meet the aggressive project timeline of 13 weeks. Ford Motor Company has been very happy with the performance, reliability, and manageability of the site, and site visitors experience the up-to-date, dynamic content that they expect.