Microsoft Site Server 3.0 Security Components Capacity and Performance Analysis

August 1999

Microsoft Corporation

Definition of Terms

Security-Specific Terms Meaning
User An individual user connected to a service.
Concurrent User A user active on the system; a subset of total users calculated based on user profile.
Member An individual who has information in the Membership Directory.
Attributes Specific information associated with a file or an object.
Broker The code that runs on the Web server that does caching and authentication.
Negotiate The first phase of an HTTP GET request that is secured. The client makes a request for a page and the server responds with the type of authentication necessary to view the page.
Directory Repository for all user information, including a password.
Least Squares Method of approximating a polynomial equation onto a non-linear data set.

General Terms Meaning
Pentium Pro equivalent MHz (PPEM) A unit of measure for processor work.

A 200 Pentium Pro equivalent MHz is delivered by a 200 MHz Pentium Pro processor.

A computer with two 200 MHz Pentium Pro processors will deliver 400 Pentium Pro equivalent MHz.


Chapter 1:  Overview

Analyzing Security Components

Microsoft® Site Server 3.0 supports two security modes: Membership Authentication mode and Microsoft® Windows NT® Authentication mode. Each mode has a specific set of identification and authentication methods. The preferred mode depends entirely on the needs of a particular site. Intranet and Internet sites have different security needs, as do Web sites that host large user communities.

The two security modes can be used alone, in combination, or in combination with Microsoft® Windows NT Server’s Internet Information Server (IIS) services Anonymous access.

Windows NT Authentication mode supports the following identification and authentication methods:

Membership Authentication mode supports these identification and authentication methods:

Projecting Total Resource Cost

A model is designed in which total resource cost is calculated for a variable number of concurrent users. Essentially:

C = n × K

where C is the resource cost, n is the number of concurrent users, and K is the sum of the costs of each user operation.

Separate equations are created for each type of resource (CPU, memory, disk, and network). Thus, it is possible to predict intelligently the maximum number of users a particular hardware configuration can support, or conversely, the required hardware resources for a given number of users.

Verification Testing

The accuracy of these calculations is confirmed by comparing the results of the calculations with a series of verification tests. A test script is created that simulates a typical user behavior as defined in the user profile. The predicted resource costs calculated from the model are charted against actual resource costs generated by running the verification script.

Note   Your performance numbers may vary from those provided here based on your hardware and software platform.

System Configuration

Processor Scaling

Web Server1: CPU: 4,2,1 x 200 MHz Pentium Pro
  Memory: 512 MB of RAM
Network: 100BaseT switched
Software: Windows NT 4.0 Option Pack version 622 (final)

1. To test the scaling of the authentication service, the number of processors in the Web server was varied at one, two, and four.

LDAP Server: CPU: 2 x 200 MHz Pentium Pro
  Memory: 256 MB of RAM
Network: 100BaseT switched
Software: Windows NT 4.0 Option Pack version 622 (final)

SQL Server: CPU: 4 x 200 MHz Pentium Pro
  Memory: 512 MB of RAM
Disk: 6 x 9.1 GB disks in a Hardware RAID 5     implementation, 100 percent write cache enabled
Network: 100BaseT switched
Software: Microsoft® SQL Server™ 6.5 SP3

Membership Directory Description

Introduction to Security

Whether you choose Membership Authentication mode or Windows NT Authentication mode depends on the sensitivity and value of a site's data, the client software that the site supports, and the expected threats to the site. Choosing between security and performance is a trade off. The less secure methods are generally faster or easier to administer.

In general, transactions are separated into pairs. The first part of the pairing represents the first page request a user makes to a secure page. When this first request is made, the Web server returns an access-denied error to the client and requests user credentials. This is the negotiation phase and is more expensive.

Although the initial transaction includes the negotiation phase, the second transaction contains multiple page requests. Subsequent page requests do not require negotiation. Typically, a Web browser continues to pass credentials to the same Web server for subsequent requests. In these transaction groups nine additional page requests were made.

The Automatic Cookie Authentication scenario is a special case, and is broken down into three parts. In the first scenario, the first time a user visits an Automatic Cookie Authentication- protected site, a new user is created in the Membership Directory, which is quite expensive. The second scenario models a new user who visits the site for the first time and then performs nine more page requests using the new cookie. The third scenario is a user who already has a cookie and performs page requests.

There are no additional objects on any of the Web pages used for the analysis.

Transactions

Method Description
Automatic Cookie Automatically creates a new user each time in the SQL Server database for each anonymous connection.
Automatic Cookie with credentials User encounters initial authentication and makes more requests with credentials.
Automatic Cookie, no creation User with a cookie returns to the site, and does not encounter a negotiation phase.
Membership Basic Authentication Authenticates using the name and password from the Membership Directory. This authentication method sends the user name and password unencrypted across the network.
Membership Basic Authentication with credentials User encounters initial authentication and makes more requests with credentials.
DPA Authenticates using DPA with the name and password from the Membership Directory. This method has a challenge and response.
DPA with credentials User encounters initial authentication and makes more requests with credentials.
HTML Forms Authenticates by redirecting the user to an HTML form where the user POSTs a name and password, which is then compared against the Membership Directory.
HTML Forms with credentials User encounters initial authentication and makes more requests with credentials.
Windows NT Basic Authenticates using the name and password from Windows NT, but passes it in clear text format.
Windows NT Basic with credentials User encounters initial authentication and makes more requests with credentials.
NTLM Authenticates using the name and password from Windows NT using standard Windows NT security.
NTLM with credentials User encounters initial authentication and makes more requests with credentials

User Profile

The security user profile is determined by planning a typical Web user visit to an authenticated site. In this example, the typical user visits the site for an average of 10 minutes. During the 10-minute visit, the user will visit five Web pages. All of these Web pages are authenticated. The first 4 pages are secured with Automatic Cookie Authentication. The users already have cookies, so their cookies will not have to be created in the Membership Directory. Their fifth page GET will be secured with Membership Basic Authentication. At this point, the user will have to enter a name and password.

All pages requested have no additional objects.

Web Client

Elements Values Frequency
Average length of session 10 minutes  
Number of pages accessed during session 5
Percentage of pages that are authenticated 100%
Percentage of pages that are automatically authenticated with preexisting cookies. For example, no cookie creation. 80% .006667 per sec
Percentage of pages using Membership Basic Authentication. 20% .001667 per sec

Summary of Scalability and Performance

Based on the data collected in this document, the following assertions can be made about scaling and performance:

Maximum Authentications per Second

Method Four Proc Two Proc One Proc
Automatic Cookie 11 11 10
Automatic Cookie with credentials 92 93 77
Automatic Cookie, no creation, with credentials 502 499 538
Membership Basic 235 171 145
Membership Basic with credentials 489 520 338
DPA 248 107 91
DPA with credentials 363 370 213
HTML Forms 95 80 73
HTML Forms with credentials 430 473 320
Windows NT Basic 121 125 103
Windows NT Basic with credentials 311 273 245
NTLM 107 116 95
NTLM with credentials 120 129 101

Security Service Scaling

Every authenticated user adds to the resource overhead of the Web server running the Broker Service. Additionally, if the requested user information is not cached in the broker, then a request is made to the LDAP server, which will in turn request the user information from the SQL Server. NTLM and Windows NT Basic Authentication are not supported in the broker service and its cache.

Chapter 2:  Detailed Discussion of Scalability and Performance

Processor Usage

The PPEM costs of the transactions for Authentication are not all constants. They vary with the rate of the transaction. When the transaction rate is low, the costs tend to be higher, and likewise, when the transaction rate becomes higher, the costs of some of the transactions rise. Thus, the PPEM is not always a constant; it could be a downward or upward slope. This table represents the least squares approximation of the PPEM versus Transaction Rate curves that were measured in the test environment. The relative accuracy of these measurements is confirmed in the following verification section.

The PPEM at a given rate on a given processor equals C1 + C2r.

Refer to Appendix A for a detailed explanation and example of how PPEM is calculated.

Formulas for Calculating Expected CPU

Four-processor

Authentication Method Valid Range for r PPEM C1
Automatic Cookie 1 - 11 2.13
Automatic Cookie with credentials 1 - 92 1.33
Automatic Cookie, no creation 1 - 502 0.56
Membership Basic 1 - 235 2.38
Membership Basic with credentials 1 - 489 1.08
DPA 1 - 248 2.1
DPA with credentials 1 - 363 1.85
HTML Forms 1 - 95 6.11
HTML Forms with credentials 1 - 430 1.24
Windows NT Basic 1 - 121 3.65
Windows NT Basic with credentials 1 - 311 1.8
NTLM 1 - 107 3.3
NTLM with credentials 1 - 120 1.74

Two-processor

Authentication Method Valid Range for r PPEM C1 PPEM C2
Automatic Cookie 1 - 11 0.84  
Automatic Cookie with credentials 1 - 93 0.45
Automatic Cookie, no creation 1 - 499 0.49
Membership Basic 1 - 171 2.08
Membership Basic with credentials 1 - 520 0.78
DPA 1 - 107 3.26
DPA with credentials 1 - 370 1.05
HTML Forms 1 - 80 3.30
HTML Forms with credentials 1 - 473 0.66
Windows NT Basic 1 - 125 1.72 0.0038
Windows NT Basic with credentials 1 - 273 0.92  
NTLM 1 - 116 2.53 -0.0009
NTLM with credentials 1 - 129 2.08 0.0015

One-processor

Authentication Method Valid Range for r PPEM C1
Automatic Cookie 1 - 10 1.29
Automatic Cookie with credentials 1 - 77 0.39
Automatic, no creation 1 - 538 0.4
Membership Basic 1 - 145 1.19
Membership Basic with credentials 1 - 338 0.64
DPA 1 - 91 2.2
DPA with credentials 1 - 213 0.75
HTML Forms 1 - 73 2.9
HTML Forms with credentials 1 - 320 0.63
Windows NT Basic 1 - 103 1.7
Windows NT Basic with credentials 1 - 245 0.82
NTLM 1 - 95 1.84
NTLM with credentials 1 - 101 1.76

Memory Usage

The following table represents the additional memory overhead associated with running this type of authentication on a Web server that is not running authentication.  The calculations are not based on a per-transaction cost, but are based on the cost overhead for running any particular security method. There is an additional cost of 24K per current connection.

The memory cost was determined as follows. The Web service was restarted and the authentication service stopped. The memory usage was measured at this point. Then the authentication service was started and several authentications of the corresponding type were performed. The memory was again measured. The difference between the two measured costs represents the additional memory overhead.

Transaction Size in Megabytes
Automatic Cookie Authentication 3 MB
Membership Basic Authentication 1.5 MB
DPA 2.5 MB
HTML Forms 4 MB
Windows NT Basic 1.8 MB
NTLM 1.5 MB

Network Usage

The bitwise network traffic for security should be measured in the number of packages that constitute the overhead. The amount of bit traffic is obviously dependent on the items returned. This table describes the number of protocol roundtrips required to do the different authentications.

Method Description
Automatic Cookie Authentication Creation phase generates 3 roundtrips
Automatic Cookie Authentication with credentials 1 roundtrip for the non-creation requests
Automatic Cookie Authentication, no creation 1 roundtrip per request
Membership Basic Authentication 2 roundtrips
Membership Basic Authentication with credentials 1 roundtrip for subsequent requests
DPA 3 roundtrips
DPA with credentials 1 roundtrip for subsequent requests
HTML Forms 2 roundtrips and 1 redirect
HTML Forms with credentials 1 roundtrip for subsequent requests
Windows NT Basic 2 roundtrips
Windows NT Basic with credentials 1 roundtrip for subsequent requests
NTLM 3 roundtrips
NTLM with credentials 1 roundtrip for subsequent requests

SQL Server Usage

The chart below shows SQL Server resource utilization per transaction type. The cached queries do not make any requests to the SQL Server. This chart also assumes that the user information is not in the broker cache. The PPEM for the user password search is low. Furthermore, when the user password is retrieved, all of the user’s other data is retrieved, as well, which speeds up subsequent user request information. This chart further assumes a small member object size. If the member size is larger than one SQL Server disk read, then the Read Data operations will be higher.

Transaction PPEM Read data Write data Read log Write log
Automatic Cookie create 6 2 5 1 1
Membership Basic Authentication 0.22 1 0 0 0
DPA 0.22 1 0 0 0
HTML Forms 0.22 1 0 0 0
Windows NT Basic 0.22 1 0 0 0
NTLM 0.22 1 0 0 0

Resource Usage Calculations

Resource usage calculations are created to answer the question: What is the cost to support a given number of users? Given this information, the next question is: What is the maximum number of users this configuration of resources can support?

In order to determine capacity for each resource, equations can be designed that measure resource cost against number of users.

Profile Calculations

An examination of the user profile needs to occur before looking at specific components of the CPU, disk, and network calculations. Using the number of concurrent users to determine maximum capacity is difficult if user behavior is not taken into consideration.

Multiplying the user profile by the number of users generates this table. For example, 500 users multiplied by the frequency of cookie authentication per second (0.006667) gives 3.33 cookie authentications per second on the server.

The following table is an expansion of this concept by user count and the transactions in the user profile space.

User Profile Frequency

Concurrent Users Auto Cookie Auth per Sec. Membership Basic Auth per Sec. Total per Sec.
500 3.33 0.83 4.17
1,000 6.67 1.67 8.33
1,500 10.00 2.50 12.50
2,000 13.33 3.33 16.67
2,500 16.67 4.17 20.83
5,000 33.33 8.33 41.67
7,500 50.00 12.50 62.50
10,000 66.67 16.67 83.33
20,000 133.33 33.33 166.67
25,000 166.67 41.67 208.33

Processor Calculations for Web Server

This graph exhibits the scaling behavior of the user profile across multiple processors.

The following tables show the individual data values used to generate the graph.

Four-processor

Concurrent Users Cookie PPEM Membership Basic PPEM Total PPEM %CPU
500 6.42 1.32 7.74 0.97
1,000 12.85 2.64 15.48 1.94
1,500 19.27 3.96 23.23 2.90
2,000 25.69 5.29 30.98 3.87
2,500 32.12 6.62 38.74 4.84
5,000 64.23 13.35 77.58 9.70
7,500 96.35 20.18 116.53 14.57
10,000 128.47 27.13 155.59 19.45
20,000 256.93 55.97 312.91 39.11
25,000 321.17 71.04 392.21 49.03
50,000 642.33 152.85 795.19 99.40

Two-processor

Concurrent Users Cookie PPEM Membership Basic PPEM Total PPEM %CPU
500 2.97 0.92 3.88 0.97
1,000 5.93 1.83 7.77 1.94
1,500 8.90 2.75 11.65 2.91
2,000 11.87 3.67 15.53 3.88
2,500 14.83 4.58 19.42 4.85
5,000 29.67 9.17 38.83 9.71
7,500 44.50 13.75 58.25 14.56
10,000 59.33 18.33 77.67 19.42
20,000 118.67 36.67 155.33 38.83
25,000 148.33 45.83 194.17 48.54
50,000 296.67 91.67 388.33 97.08

One-processor

Concurrent users Cookie PPEM Membership Basic PPEM Total PPEM %CPU
500 2.23 0.97 3.20 1.60
1,000 4.47 1.93 6.40 3.20
1,500 6.70 2.90 9.60 4.80
2,000 8.93 3.87 12.80 6.40
2,500 11.17 4.83 16.00 8.00
5,000 22.33 9.67 32.00 16.00
7,500 33.50 14.50 48.00 24.00
10,000 44.67 19.33 64.00 32.00
20,000 89.33 38.67 128.00 64.00
25,000 111.67 48.33 160.00 80.00

Network Calculations

The number of roundtrips for authentication per user is one each for the first four cookie authentications plus two for the Membership Basic Authenticated page.

This scenario generates a total of six round trips per visit.

Disk Calculations

The following table enumerates the expected disk reads on the SQL Server for the authentications. These numbers are not measured, but are logically determined because SQL Server requires a read from the user directory to retrieve the password information for a user.

One disk read will occur for the group of cookies and one for the Membership Basic Authentication information.

It should be noted however that the Authentication Service reads the entire user object that contains the cookie information as well as the additional password. So, it should not be necessary to make this additional read. However, in this scenario the additional request is performed. This user makes a unique call into the Membership Basic- secure section of the Web site. This call requires a separate read from disk.

Additionally, these disk numbers assume that the index for the members is in the cache. For a worst-case scenario it should perform four reads per user lookup. Although in that scenario the SQL Server computer is severely overloaded and more RAM should be added to increase the caching.

Concurrent Users Disk Read for Cookie Disk Read for Membership Basic Total Disk Reads
500 0.83 0.83 1.67
1,000 1.67 1.67 3.33
1,500 2.50 2.50 5.00
2,000 3.33 3.33 6.67
2,500 4.17 4.17 8.33
5,000 8.33 8.33 16.67
7,500 12.50 12.50 25.00
10,000 16.67 16.67 33.33
20,000 33.33 33.33 66.67
25,000 41.67 41.67 83.33
50,000 83.33 83.33 166.67

Sample Configuration

Site Configuration Example

This example illustrates how to determine an optimal configuration for a given number of users.

200,000 total users

4 percent online at peak time = 8,000 concurrent users

Profile Calculations

Determine the transaction rate T for the individual transactions that make up the user profile.

n x f = T

8000concurrent users * 0.006667frequency for cookie auth = 53.33 = Tcookie

8000concurrent users * .001667frequency for basic auth = 13.33 = T membership basic

Sample Processor Calculations

PPEM = T * cost

2-proc: PPEMcookie = 53.33 * 0.49 = 26.13 PPEM

2-proc: PPEMm. basic = 13.33 * 2.08 = 27.73 PPEM

For a total of 53.86 PPEM which is 13.46 percent CPU utilization on a two-processor computer.

Sample SQL Server Disk Calculations

Disk Reads = T * cost

Disk Readcookie = 13.33 * 1 disk reads/sec

Disk Readm.basic = 13.33 *1 disk reads/sec

For a total of 26.66 SQL Server disk reads per second.

Sample SQL Server Processor Calculations

This calculates the number of accesses necessary to read the user information in order to fill the broker cache. Each lookup operation costs .22 PPEM on the four-processor SQL Server.

SQL PPEMcookie = 13.33cookie lookups * 0.22member lookup cost = 2.93 PPEM

SQL PPEMm. basic = 13.33m. basic lookups * 0.22member lookup cost = 2.93 PPEM

For a total of 5.87 PPEM or .73-percent CPU utilization.

Appendix A:  Testing Methodology

Calculating the Per Transaction Cost

To calculate the PPEM from observed data, the load was simulated on a per transaction basis. In this case, Automatic Cookie Authentication cached with creation. An automated script was run that cycled through a changing user load. The values were captured in a perfmon.exe log file. This log file was then exported to a tab-delimited text file and imported into Microsoft® Excel. Next, using an Excel macro, the log was distributed and averaged. Each row in the chart below represents several minutes of the transaction load. Many values are captured, too, but these figures are the most important for calculating PPEM.

To establish a valid range of samples, context switches are observed. The context switch rate must be below a certain threshold to be considered running optimally. However, the processor should be exercised across a full range.

This table represents the actual counter objects and values of the system during simulation.

DPA Auth successes/sec Current connections % Total processor time Context switches/sec PPEM
Site Server Authentication Service Web Service System System  
3.69 1.00 0.60 541.05 1.31
7.58 2.00 1.43 804.69 1.51
15.42 3.84 8.55 1224.58 4.43
28.09 7.15 8.72 2106.31 2.48
53.75 12.29 15.59 3403.49 2.32
89.35 26.20 33.70 5063.99 3.02
91.46 37.73 49.90 4441.05 4.37
90.81 52.23 27.93 4687.99 2.46

In the next chart, below, total processor time is multiplied by the clock capacity of the system, which in this case is 4 x 200, and then is divided through by the number of authentications per second. Next, the overall PPEM is calculated by taking a polynomial fit using least squares approximation of the PPEM value at the transaction rate. This equation generates the formulas presented in Chapter 1 for each transaction.

In this case, the best fitting is a constant value.

Verifying Actual versus Calculated

The user profile was then tested and run in the lab. The site had five Web pages: a.htm through e.htm. The first four were protected with Automatic Cookie Authentication and e.htm was protected with Membership Basic Authentication. The test client computers were running InetMonitor. They used a cookie list file with 96 valid cookies. When the client hit the e.htm page, the client and the broker switched to basic authentication and used the password for the user. The script paused between GET requests to simulate a user reading their information. This script is included in Appendix D.

The following table shows the data that were collected while testing the Web server with four processors enabled.

Five hundred users were run against the system for 10-15 minutes so that stability could be achieved. These PerfMon results were averaged over a 1,000-second period. PerfMon recorded the actual number of authentications of each type per second. In order to calculate expected CPU on this four-proc system, the number of Automatic Cookie Authentications was multiplied by the PPEM value to achieve an overall PPEM calculated for Automatic Cookie Authentication. For example, at 500 users the 32.90auto cookie * 0.56PPEM 4proc auto-cookie = 18.42 PPEM.

This process was repeated for Membership Basic Authentication costs. Then, the CPU % was calculated by adding the 2 PPEM values and dividing through by PPEM of the four-processor system. For example, 18.42PPEM Auto-cookie + 16.85PPEM M.basic = 35.27PPEM Total = 35.27 / (4 x 200) = .044 = 4.4% CPU.

Users 500 1,000 1,500 2,000 2,500
% Processor 5.26 12.10 12.90 18.70 25.50
Context Switches 579.00 1691.00 1840.00 2302.00 2520.00
Get Requests 49.10 169.50 193.40 246.00 296.00
Non-anonymous user/sec 41.00 141.50 162.60 204.00 247.00
Automatic Cookie Authentication 32.90 114.00 131.40 163.50 197.00
Basic Authentications/sec 8.10 27.50 31.20 40.50 50.00
PPEM Basic 16.85 57.20 64.90 84.24 104.00
PPEM Cookie 18.42 63.84 73.58 91.56 110.32
CPU Calculated 4.41 15.13 17.31 21.98 26.79

This is the two-proc table for the same verification scenario.

Concurrent users 500 1,000 1,500 2,000 2,500
% Processor 8.13 15.77 18.20 26.20 35.20
Context Switches 450.00 738.00 156.00 1516.00 1711.00
Get Requests 50.22 100.30 149.80 199.00 249.50
Non-anonymous user/sec 41.60 83.25 124.80 166.40 208.00
Automatic Cookie Authentication 33.44 66.66 99.60 133.40 166.90
Basic Authentication/sec 8.16 16.59 25.20 33.00 41.10
PPEM Basic 9.47 19.24 29.23 38.28 47.68
PPEM Cookie 16.39 32.66 48.80 65.37 81.78
CPU Calculated 6.46 12.98 19.51 25.91 32.36

Appendix B:  Scaling Summary

This graph shows an approximate comparison of the processor configurations versus the cost for each operation. It is only approximate because it ignores the second term for several PPEM values. It does, however, accurately reflect the relative inefficiency of the four-processor configuration.

Appendix C:  Critical Monitoring Counters

All counters noted can be found in the Windows NT Performance Monitor. These counters will be distributed among the computers in the Personalization and Membership (P&M) service group. The counters in the system and memory objects can be used to monitor capacity.

Site Server LDAP Service

Connection Current

Static Search per second

Site Server Authentication Service

Automatic Cookie Authentication Successes per second

ClearText Authentication successes per second

DPA successes per second

HTML Forms Authentication successes per second

Requests served from cache

SQL Server

SQL Server I/O transactions per second

Physical Disk

Disk Writes/secondDisk activity should not sustain maximum transaction rate

Disk Reads/second

ASP Object

Requests/second

Current requests

Web Object

NonAnonymous Users/second

Get requests

System Object

Context switches/second should be fewer than 15,000

%Total Processor should be less than 80 percent

Processor Object

%Processor Utilization (average)should be less than 80 percent (for each processor)

Memory Object

Available Bytesshould be greater than 4 MB

Appendix D:  Authentication Service Transactions

Set up to verify:

  1. Create a virtual root with a verify subdirectory.

  2. Set a,b,c,d.htm with Automatic Cookie Authentication.

  3. Set e.htm to Membership Basic Authentication.

  4. Pull the cookie list from the list of globally unique identifiers (GUIDs) for authenticated cookie users or net capture the results of cookies that are automatically generated.

  5. Have a set of users in your directory with names tst1-tst1000 and password = password.

Verification Script

USER tstRANDNUMBER(1,1000) password
GET url:/verify/a.htm
SLEEP 120000
GET url:/verify/b.htm
SLEEP 120000
GET url:/verify/c.htm
SLEEP 120000
GET url:/verify/d.htm
SLEEP 120000
GET url:/verify/e.htm
SLEEP 120000

Information in this document, including URL and other Internet web site references, is subject to change without notice.  The entire risk of the use or the results of the use of this resource kit remains with the user.  This resource kit is not supported and is provided as is without warranty of any kind, either express or implied.  The example companies, organizations, products, people and events depicted herein are fictitious.  No association with any real company, organization, product, person or event is intended or should be inferred.  Complying with all applicable copyright laws is the responsibility of the user.  Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.  Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 1998-2000 Microsoft Corporation.  All rights reserved.

Microsoft, Windows and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries/regions.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.