Microsoft Site Server 3.0 Membership Directory Capacity and Performance Analysis

April 1999

Microsoft Corporation

Definition of Terms

Chapter 1 Overview

This document evaluates the performance and scalability characteristics of the Microsoft® Site Server Membership Directory. The document also demonstrates procedures for identifying these characteristics. Using these procedures, you can determine how user-load impacts hardware resources and which resources are the most likely to be performance bottlenecks. You can then use this information to calculate maximum capacity for a particular hardware configuration, to assess the value of adding additional resources, and to determine which resources would satisfy greater capacity needs.

Analyzing the Membership Directory and LDAP Services

The Membership Directory is a central data repository that stores user records including personal profile information used in personalization and address book information. The persistent contents of the Membership Directory are stored in the Membership Directory database, typically using Microsoft® SQL Server^™. The Membership Directory contents are accessed using the Lightweight Directory Access Protocol (LDAP) Service, which provides platform-independent access to the Membership Directory. To obtain performance and scalability information, the Membership Directory database and the LDAP Service were analyzed in separate tests using various server configurations.

Projecting Total Resource Cost

A model is designed in which total resource cost is calculated for a variable number of concurrent users. From this model, the following equation is obtained:

C = n × K

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 intelligently predict the maximum number of users a particular hardware configuration can support, or conversely, the hardware resources required for a given number of users.

Verification Testing

For credibility, 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 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.

Scalability

Given a model for predicting resource requirements, it is important to test scalability. For example, does investing in a multiple processor system enhance the performance of the LDAP Service? How does partitioning the Membership Directory database across multiple servers affect overall performance, and LDAP Service performance in particular? How well does the LDAP Service scale to multiple servers?

System Configuration

In three test scenarios, two-to-four servers were used in the following configurations:

Note   The Microsoft Access database solution is not part of this document.

1. One LDAP server was used to test LDAP processor scaling. Three LDAP servers were used to test scaling to multiple servers.

2. To test Membership Directory database scalability, the database was partitioned across two Microsoft SQL Servers.

3. Microsoft SQL Server was configured with 75 percent available RAM, 300 user connections, no truncate on checkpoint, and 120 minute checkpoint interval.

Membership Directory Description

The Membership Directory is the central repository of user data, including personalization profiles and address book information. The Membership Directory stores both persistent data, which is retained indefinitely, and dynamic data, which is never written to disk, but is maintained in random access memory (RAM) while current. This report only details the static Membership Directory. The Dynamic Directory performance is discussed in the article Microsoft Site Server 3.0 Dynamic Directory Service Capacity and Performance Analysis.

The Membership Directory is accessed using LDAP version 3.0. LDAP is an Internet standard for accessing user information in directories, and allows standard, platform-independent access to the Membership Directory.

The Membership Directory data objects, their optional and required attributes, and the permitted parent-child relationships between objects are defined in the schema, which is stored in the Membership Directory and can be queried by applications. This arrangement allows applications to know the complete up-to-date structure of the Membership Directory at all times, and therefore allows you to make changes to meet your needs without interfering with the operation of system processes and tools.

Small Web sites can effectively deploy a Web server, a Membership Server containing an Active User Object (AUO), an LDAP Service, an Authentication Service, and a Membership Directory on a single computer. For increased scalability, larger sites can deploy the Membership Directory on a dedicated server. Additional performance advantages can be achieved by dedicating one or more servers to the LDAP Service. For environments with heavy transaction volumes, the Membership Directory can be allocated to different physical databases using Microsoft SQL Server.

Transactions

The following table highlights some standard Membership Directory transactions.

Tested Membership Directory Transactions

Large User Profile

The following profile captures typical Membership Directory transactions. The database contains 200,000 members in a single partitioned directory service.

Typical Membership Directory Transactions

A user with twenty additional attributes is a large user. In contrast, a user added by Auto-Cookie authentication only has three additional attributes.

Summary of Scalability and Performance

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

• The base object search speed for cn is the same as the search speed for all attributes within the directory service due to the indexing scheme.

  Note   In a partitioned environment the partitions are hashed on the cn value. Thus, base object searches will occur on all partitions for all other attribute types.

• The LDAP server scales in the CPU-bound transaction to multiple processors as detailed in Appendix B.
  
  
• Deploying the LDAP Service on multiple servers increases transaction speed and rate. The rate of these increases is linear with the number of servers running the service.
  
  
• Adjusting the SQL Server configuration parameters can greatly affect performance. Refer to Microsoft Site Server 3.0 Membership Directory Configuration and Tuning Guidelines for details about optimizing.
  
  
• Partitioning the Membership Directory onto multiple SQL Server computers enhances performance linearly with the number of servers. The cost of subtree and one level searches increase because the request spans the partitions.

Note   As a general rule, groups larger than 750,000 elements should consider partitioning.

• The modify and add transactions are bottlenecked by the speed of the SQL Server disk subsystem.
  
  
• The LDAP server relies on Microsoft Open Database Connectivity (ODBC) and OLEDB technology to perform its SQL Server operation. Each piece has a major performance upgrade.
  
  
• The MDAC 2.0 drivers increased the raw throughput of the Membership Directory and made scalability to multiple processors more efficient. See Appendix E, MDAC 2.0 Capacity and Performance, for details.
  
  
• If the requestor has performed a bind as the anonymous user, there is an ACL lookup for each transaction. In current versions of Windows NT, this ACL lookup does not scale to multiple processors.

Scaling Projections

The LDAP portion of the directory service scales in more than one way. A single server scales to roughly 100 independent connection and anonymous binds per second, but the rate for search scales independently of this rate to rates discussed in the next chapter. The other way an LDAP server scales is in a server farm environment. Adding multiple LDAP servers scales linearly with the number of servers. Additionally, if the level of power is needed, the database back end can be partitioned across multiple SQL Server computers. Thus the LDAP Service can scale to meet almost every need.

The following section gives a quick view of the number of servers required to support five million to 50 million members. The following are the assumptions used:

• At peak, concurrent users are two percent of total members.
  
  
• A user needs to fetch data from the LDAP/SQL Servers every five minutes.
  
  
• All servers are four-processor Pentium Pro 200 MHz. The computers running SQL Server are equipped with high-end disk subsystems including four controllers per server, two cabinets per controller, and seven disks per cabinet. The disk subsystem is configured to be RAID 1.

Chapter 2 Detail Discussion of Scalability and Performance

Processor Usage

The PPEM costs of the transactions for the directory service are not constants. They vary with the rate of the transaction. In some cases, when the transaction rate is low, the costs tend to be higher. 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, r on a given processor is: r * (C₁ + C₂r + C₃r²).

Four-processor

4. This maximum was disk-bound on the SQL Server.

5. This maximum was disk-bound on the SQL Server.

6. This maximum was disk-bound on the SQL Server.

7.The Adds measured had 20 additional attributes. Smaller Adds such as anonymous users were measured up to 11 per second.

Two-processor

8. This maximum was disk-bound on the SQL Server.

9. This maximum was disk-bound on the SQL Server.

10. This maximum was disk-bound on the SQL Server.

One-Processor

11. This maximum was disk-bound on the SQL Server.

Network Usage

The exact contents of the network packets for the LDAP server are specified in the LDAP RFC (RFC 1959). This table describes the typical bit usage of the transactions that were measured. These numbers should be in line with typical usage.

Disk Usage

There is no measurable local disk utilization on the LDAP server. The disk utilization occurs on the database server. The SQL Server database disk utilization is discussed in the next section.

SQL Server Usage

The SQL Server usage per transaction plays a large role in determining final system configuration. The table below outlines the CPU and disk usage for the transaction set.

• Base object searches simply read from the data device.
  
  
• One level and subtree searches utilize the TempDB device.
  
  
• Add transactions write to the transaction log several times because it updates the indices as well as the Object attributes table. The add transaction also reads and writes to the data device.
  
  
• Modify transactions must update the log and the data device.
  
  
• Attribute data are clustered on disk device.

SQL Server resource utilization per transaction type

The previous table gives the measured cost per transaction in our measured environment. The disk input/output (I/O) rate that is computed should be assessed, and the final number of spindles in the RAID devices should be computed based on the designated type of RAID setup.

Disk usage is sorted according to the device used to support the database: SQL Server can use a distinct device for storage, transaction log, and the TempDB. Storage contains the data and clustered indices. Transaction log holds the record of changes to the data. The TempDB is a temporary creation for computing the relational work necessary to compute a query.

It should be noted that the disk access numbers in the measured environment have a lower level of caching than might be expected from a different environment such as the environment presented in the authentication service.

Disk Space

The disk space calculations do not take into account the current user rate. The current user rate is the static space that all users in the system take up independent of their activity.

The following assumptions were made for this test:

• Index fill factor of 30 percent.
  
  
• Small container overhead.
  
  
• 1080 MB of disk space in SQL Server for every 100,000 users.

This table enumerates the user profile for the data.

Resource Usage Calculations

Resource usage calculations are created to determine what it costs to support a given number of users. Once you obtain this information, you must determine the maximum number of users this configuration of resources can support.

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

Profile Calculations

Before looking at specific components of the CPU and disk and network calculations, the user profile will be examined. Using the number of concurrent users to determine maximum capacity is difficult if user behavior is not taken into consideration.

Taking the previous user profile, expand it to determine a frequency table.

Next, compute the number of transactions per second given a number of concurrent online users. This table does not take into account the length of a business day, or the percentage of potential users who would actively use the service. The table represents the number of concurrent users having the previous profile.

Processor Calculations

The first step in determining the processor utilization on the LDAP server is to determine the transaction rate for each of the defined transactions. If this calculation is made with the user profile as previously described, the following table is generated.

Each processor type yields a different processor calculation for each transaction. The results can quickly be calculated in Microsoft® Excel to produce this table.

Four-Processor

Two-Processor

One-Processor

Note that the one- and two-processor formats do not allow for the higher user profiles.

Network Calculations

The table below contains the measured cost per transaction for the measured transactions in bits per second (bps). Plugging the user profile into the measure network bit traffic yields this table.

Memory Calculations

The following table represents the memory necessary to support the active number of connections. On the LDAP server all transactions have the same cost, and so the table can be simplified.

Each additional connection costs 5 KB.

This table does not take into account the root memory overhead of running the LDAP server. The LDAP server caches the directory information tree (DIT) and other objects that will require additional RAM. Thus, results will vary based on the complexity of the directory structure.

SQL Server Calculations

This table represents the overall SQL Server utilization for processor and disk for the user profile sets of transactions. It is once again calculated with the user profile.

SQL Server Processor

Disk

This disk utilization is the calculated disk throughput at one arbitrary data point, 500 users.

Disk Space

Using the previous profile, data and indices of this size is generated.

Site Configuration Example

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

Sample Processor Calculations

The first step in determining the sample configuration is the user profile. The user profile is determined by modeling typical user behavior. The best possible way to do this calculation is to sample an existing similar configuration for exact transaction rates. However, if this configuration is not available, the analysis can be done to predict users’ behavior.

For this sample, the user profile that was described for typical per-user transaction rates is used. Then, the number of users that will be supported is determined.

For a medium Internet Service Provider (ISP) the calculation takes into account 50,000 current users, but the system to build out should be ready to grow to accommodate 200,000 users.

Assuming that, at most, two percent of users are online at any time, the average user-load is 4,000.

The calculations should be done at peak load time, which is roughly two times average for a maximum concurrent user load of 8,000 users.

The user load multiplied by the frequency generates this transaction rate table.

To carry out only Base Object search calculations, use the formula from the PPEM table for four processors:

PPEM_BaseObject= 2.6782 + .0048r = 2.92

To achieve actual CPU usage, multiply PPEM by rate to yield 148.02.

This table expands all of the transaction across all of the processors.

The final column calculates the expected CPU rate for the server at this load by dividing the PPEM by the CPU capacity of the system.

Memory Calculation

66.67_{Peak transaction rate}* 5 KB per connection = 333.3 KB

The memory calculations show that the server should have an additional 333.3 KB of memory for handling the peak LDAP traffic.

Network Calculation

2.0_{Add Peak Transaction Rate} * 7440_{Add Network bit cost} = 14,880 bps.

This calculation represents the network traffic that the LDAP server itself will generate in bps.

SQL back end the processor load

SQL PPEM_Add =15

15 * 2.0_{Add Peak Transaction Rate} = 30 PPEM for Add.

SQL Disk Utilization

Multiply the transaction rate by the disk cost per device to generate this table.

On the primary data device, the SQL Server system must support 173.73 read transactions per second and 68 write transactions per second.

Calculating the RAID array to support this rate occurs as follows:

RAID Level 0 =ceiling ((Read_Max/sec + Write_Max /sec)/60_{average maximum disk I/O speed}) (Maximum disk I/O is the average rate for a 7200 rpm drive.)

RAID Level 1 = ceiling (Read_Max/sec + (2 * Write_Max /sec))/60_{average maximum disk I/O speed})

RAID Level 5 = ceiling ((Read_Max+ (4*Write_Max ))/60_{average maximum disk I/O speed})

Read_Max is the necessary maximum number of disk reads per second. Write_Max is the necessary maximum number of disk writes per second.

The denominator of 60 assumes a 7200 rpm, 4.3-gigabyte disk drive. Different controllers and faster disk drives will change performance. Refer to hardware benchmarks for more information.

RAID Level 0 for data disk = ceiling (250 + 100)/60 = ceiling(5.83) = 6

RAID Level 1 for data disk = ceiling (250 + 2 * 100)/60 = ceiling(7.5) = 8

RAID Level 5 for data disk = ceiling (250 + 4 *100)/60 = ceiling(10.8) = 11

Disk Space Calculation

The cost per user in this model is a constant, thus 200,000 users in the directory equals 2060 MB of disk space on the SQL Server device.

The transaction log should be large enough to handle all of the activity for the period between maintenance. The SQL Server administrative staff should determine this calculation.

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, Auto-Cookie 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. The log file was then exported to a tab-delimited text file and imported into Microsoft Excel. Then, using a macro, the log was distributed and averaged.

Each row in the chart represents a several-minute run of the transaction load. Many values were captured, but these rates were the most important for calculating PPEM. To establish a valid range of samples, context switches were 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.

The required calculation for this table is a multiplication of the total processor time by the clock capacity of the system. In this case the equation is 4 times 200. The product is then divided by the number of authentications per second. Next, the overall PPEM is calculated by taking a least squares approximation of the PPEM value at the transaction rate. This result generates the formulas presented in Chapter 1 for each transaction.

The data points are plotted and then a polynomial fitting is applied using least squares to generate the line. The values of the lines is 1.37537 + .009077 * T.

Verification Sample:

The following chart represents measured CPU utilization versus actual CPU utilization for LDAP running on a two-processor computer. The calculated number represents the processor load calculated using the formulas with the rates taken from the real performance counters at each data point. The other line is the actual CPU load on the system.

Verifying Actual versus Calculated

The next two charts show the SQL Server verification. The same calculated transaction rates are pulled from the real performance counters and calculated using the PPEM rates in the SQL Server table.

The disk transaction rates for SQL Server are calculated using the previous table, with one important distinction. The measured disk load on a SQL Server system should be doubled to account for additional SQL Server overhead when running in a mixed environment.

The disk writes on the SQL Server are sporadic due to SQL Server's maintenance schedule and other hard-to-control activities. This chart represents a real scenario. The disk I/O lag that is evident in all numbers should be expected in every user’s final implementation.

Appendix B:  LDAP Service Processor Scaling

Every user that accesses the LDAP server increases the hardware utilization on that server. This chart shows the maximum rate of the transactions on a server with one, two and four Pentium Pro 200 MHz processors.

Maximum transaction rates per processor

Adding More LDAP Servers

Another way to scale the LDAP Service is to add more computers running the LDAP Service independently. This table shows that adding more LDAP servers can increase the total number of transactions per second that a group of servers can handle. All three of these LDAP servers were making requests against one SQL Server. The costs were linear.

The table details reveals that the average CPU and transactions per second are equally balanced and that the cost per transaction is roughly the same as it is in a non-distributed environment.

Transaction costs using multiple LDAP servers

Transaction Scaling Summary

This chart shows how the transaction rate levels off for the search type transactions. In contrast, however, the modify scripts will decay in performance as the SQL Server falls behind while writing the transactions to disk.

Partitioning the Membership Directory

Partitioning the Membership Directory allows the administrator to manage smaller databases within SQL Server. Partitioning allows for more reasonable manageability in both data and index size. Furthermore, by breaking up the data into separate databases, the locking inherent in SQL Server’s implementation of indices is avoided.

You can, thus, speed up the disk bound transactions that are typically the modify and the add by partitioning to multiple disk systems.

Partitioning the Membership Directory

Appendix C:  Critical Monitoring Counters

All counters noted can be found in Microsoft® 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 Add per second

Static Modify per second

Static Search per second

Site Server Authentication Service

Auto-Cookie Authentication Successes per second

Clear Text 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 per secondDisk activity should not sustain maximum transaction rate

Disk Reads per second

ASP Object

Requests per second

Current requests

Web Object

NonAnonymous Users per sec

Get requests

System Object

Context switches per secondshould be less 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 Bytes should be greater than four megabytes.

Appendix D:  Membership Directory Transactions

Scripts

Base Object Script

CONNECT
LOOP RANDNUMBER(15,30)
 SEARCH BASE RETURN ALL dn=cn=tstRANDNUMBER(1,200000),ou=members,o=microsoft; filter=(objectclass=*);
 SLEEP RANDNUMBER(200,350)
ENDLOOP
QUIT

One Level Script

CONNECT
LOOP RANDNUMBER(15,30)
 SEARCH ONELEVEL RETURN ALL dn=ou=members,o=microsoft;filter=(cn=tstRANDNUMBER(1,200000));
 SLEEP RANDNUMBER(200,350)
ENDLOOP
QUIT

Add One User Script

CONNECT
BINDSIMPLE dn=cn=administrator,ou=members,o=microsoft;password=pw;
LOOP 10
 ADD dn=cn=RANDALPHA(20),ou=members,o=microsoft;objectClass=member;guid=RANDNUMERIC(32);telephoneNumber=RANDNUMERIC(10);street=RANDALPHA(60);postOfficeBox=RANDNUMERIC(6);postalCode=RANDNUMERIC(9);postalAddress=RANDNUMERIC(60);st=RANDALPHA(2);givenName=RANDALPHA(40);sn=RANDNUMERIC(9);c=RANDALPHA(2);language=RANDALPHA(5);userComment=RANDNUMERIC(20);homepage=RANDALPHA(8);description=RANDALPHA(8);userpassword=password;mail=RANDALPHA(20)@corp.com;mailerNoEmail=0;mailerNumNDR=0;mailerEmailInvalid=0;
 sleep 1000
ENDLOOP
QUIT

Connect and Bind Script

CONNECT
BINDSIMPLE dn=cn=administrator,ou=members,o=microsoft;password=pw;
SLEEP 200
QUIT

Subtree Search Script

CONNECT
 LOOP RANDNUMBER(15,30)
 SEARCH SUBTREE RETURN ALL dn=o=microsoft; filter=(|(cn=tstRANDNUMBER(1,200000))(cn=tstRANDNUMBER(1,200000)));
 SLEEP RANDNUMBER(200,350)
 ENDLOOP
QUIT

Modify Add Script

CONNECT
LOOP RANDNUMBER(15,30)
 MODIFY userComment=RANDALPHA(32): A;dn=cn=tstRANDNUMBER(1,200000), ou=members, o=microsoft;
 SLEEP RANDNUMBER(200,350)
ENDLOOP
QUIT

Modify Replace Script

CONNECT 
LOOP RANDNUMBER(15,30)
 MODIFY postalcode=RANDNUMERIC(9):R;dn=cn=tstRANDNUMBER(1,200000), ou=members, o=microsoft;
 SLEEP RANDNUMBER(200,350)
ENDLOOP
QUIT

Verify Test

CONNECT
 BINDSIMPLE ANONYMOUS
 LOOP 100
 %29 SKIP 2
 SEARCH BASE RETURN ALL dn=cn=tstRANDNUMBER(1,200000),ou=members,o=microsoft; filter=(objectclass=*);
 SLEEP RANDNUMBER(200,350)
 %92 SKIP 2
 SEARCH ONELEVEL RETURN ALL dn=ou=members,o=microsoft;filter=(cn=tstRANDNUMBER(1,200000));
 SLEEP RANDNUMBER(200,350)
%97 SKIP 2
 ADD dn=cn=RANDALPHA(20),ou=members,o=microsoft;objectClass=member;guid=RANDNUMERIC(32);telephoneNumber=RANDNUMERIC(10);street=RANDALPHA(60);postOfficeBox=RANDNUMERIC(6);postalCode=RANDNUMERIC(9);postalAddress=RANDNUMERIC(60);st=RANDALPHA(2);givenName=RANDALPHA(40);sn=RANDNUMERIC(9);c=RANDALPHA(2);language=RANDALPHA(5);userComment=RANDNUMERIC(20);homepage=RANDALPHA(8);description=RANDALPHA(8);userpassword=password;mail=RANDALPHA(20)@corp.com;mailerNoEmail=0;mailerNumNDR=0;mailerEmailInvalid=0;
 SLEEP RANDNUMBER(200,350)
%89 SKIP 2
 MODIFY postalcode=RANDNUMERIC(9):R;dn=cn=tstRANDNUMBER(1,200000), ou=members,o=microsoft;
 SLEEP RANDNUMBER(200,350)
ENDLOOP
QUIT

Appendix E:  MDAC 2.0 Capacity and Performance

Processor Usage

The PPEM costs of the transactions for the directory service are constant due to the scalability enhancements in the MDAC 2.0 code. This table represents the average of the PPEM values that were measured in the test environment.

The PPEM at a given rate, r on a given processor, is: r x C₁.

Four-processor

12. This maximum was disk-bound on the SQL Server.

13. This maximum was disk-bound on the SQL Server.

14. This maximum was disk-bound on the SQL Server.

15. The Adds measured had 20 additional attributes. Smaller Adds such as anonymous users were measured up to 11 per second.

Two-processor

16. This maximum was disk-bound on the SQL Server.

17. This maximum was disk-bound on the SQL Server.

18. This maximum was disk-bound on the SQL Server.

One-Processor

19. This maximum was disk-bound on the SQL Server.

MDAC 2.0 Enhanced Processor Calculations

The results can quickly be calculated in Microsoft® Excel to produce this table. This table and the accompanying chart represents the new scalability results.

Four-Processor

Two-Processor

One-Processor

Note that the one- and two-processor formats do not allow for the higher user profiles.

This chart is a graphical representation of the new data in the preceding tables.

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.

© 1999-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.