Windows Server System
Windows Server System
Reference Architecture
Reference Architecture
Lab Implementation
Lab Implementation
Published: July 2005 Published: July 2005For the latest information, please see
For the latest information, please see http://www.microsoft.com/wssrahttp://www.microsoft.com/wssra
Abstract Abstract
Windows er!er ystem" #eference $rchitecture %W#$& deli!ers architectural 'uidance Windows er!er ystem" #eference $rchitecture %W#$& deli!ers architectural 'uidance onon enterprise () infrastructure. *rucial to the credibility of this 'uidance is the testin' and pro!in' of the enterprise () infrastructure. *rucial to the credibility of this 'uidance is the testin' and pro!in' of the 'uidance to ensure the e+pected !alue can be
'uidance to ensure the e+pected !alue can be deri!ed from it when desi'nin' and implementin' ()deri!ed from it when desi'nin' and implementin' () infrastructure based on icrosoft- products and technolo'ies. )his document describes the process infrastructure based on icrosoft- products and technolo'ies. )his document describes the process followed to use the
followed to use the Reference BlueprintsReference Blueprints by inectin' a fictitious scenario and then buildin' and testin' by inectin' a fictitious scenario and then buildin' and testin' the resultant desi'n.
Information in this docu
Information in this document, including URL and ment, including URL and other Internet Wother Internet Web siteeb site referen
references, is subject ces, is subject to change without notice. The entire risk to change without notice. The entire risk of the use orof the use or the results of the use
the results of the use of this document remains with the user.of this document remains with the user.
The example companies, organiations, products, domain names, e!mail The example companies, organiations, products, domain names, e!mail addresses, logos, people, places, and e"ents depicted herein are fictitious. #o addresses, logos, people, places, and e"ents depicted herein are fictitious. #o association with an$
association with an$ real compan$, organiareal compan$, organiation, product, domain name,tion, product, domain name, email address, logo, person, places, or e"ents is inte
email address, logo, person, places, or e"ents is inte nded or should bended or should be inferred.
inferred.
%ompl$ing with all applicable cop$right laws is
%ompl$ing with all applicable cop$right laws is the responsibilit$ of the user.the responsibilit$ of the user. Without limiting the rights under cop$right, no part of
Without limiting the rights under cop$right, no part of this document ma$ bethis document ma$ be repr
reproduced, stored in or introduced into a retrie"al s$stem, or transmitted oduced, stored in or introduced into a retrie"al s$stem, or transmitted inin an$ form or
an$ form or b$ an$ means &electronic, mechanical, b$ an$ means &electronic, mechanical, photocop$ing, recordphotocop$ing, recording,ing, or otherwise', or for an$ purpose, without the
or otherwise', or for an$ purpose, without the express written permission ofexpress written permission of (icrosoft %orpo
(icrosoft %orporation. (icrosoft ma$ haration. (icrosoft ma$ ha"e patents, patent applications,"e patents, patent applications, trademarks, cop$rights, or other intellectual propert$ rights co"ering trademarks, cop$rights, or other intellectual propert$ rights co"ering subjectsubject matter in this document. )xcept
matter in this document. )xcept as expressl$ pro"ided in an$ written licenseas expressl$ pro"ided in an$ written license agreement from (icro
agreement from (icrosoft, the furnishing of tsoft, the furnishing of t his document does not gi"e $ouhis document does not gi"e $ou an$ license to these patents, trademarks, cop$rights, or other intellectual an$ license to these patents, trademarks, cop$rights, or other intellectual propert$
propert$..
* +- (icrosoft %orporation. ll rights
* +- (icrosoft %orporation. ll rights reser"ed.reser"ed. (icrosoft, cti"e /ir
(icrosoft, cti"e /irector$, 0rector$, 0roject, Windows, Woject, Windows, Windows 1er"erindows 1er"er, and W, and Windowsindows 1er"er 1$stem are either registered trademarks or trademarks of (icrosoft 1er"er 1$stem are either registered trademarks or trademarks of (icrosoft %orporation in the United 1tates and2or other countries.
%orporation in the United 1tates and2or other countries.
The names of actual companies and products mentioned herein ma$ be the The names of actual companies and products mentioned herein ma$ be the trademarks of their respecti"e owners.
trademarks of their respecti"e owners. (icrosoft %orpo
(icrosoft %orporation 3 4ne (icrosoft Wration 3 4ne (icrosoft Wa$ 3 Redmond, Wa$ 3 Redmond, W 56-+!7855 3 56-+!7855 3 U1
)
)able
able of *on
of *ontents
tents
EXECUTIVE SUMMARY...1
EXECUTIVE SUMMARY...1
INTRODUCTION...2
INTRODUCTION...2
W WHOHO S SHOULDHOULD R R EADEAD T THISHIS D DOCUMENTOCUMENT...2...2
K K NOWLEDGE NOWLEDGE P PREREQUISITESREREQUISITES...2...2
ARCHITEC ARCHITECTURE TURE DRIVEN DRIVEN DESIGN..DESIGN...3...3
D DESIGNESIGN S STRATEGYTRATEGY...3...3
D DESIGNESIGN P PROCESSROCESS...3...3
D DESIGNESIGN S SCENARIOCENARIO...5...5
N NETWORK ETWORK D DESIGNESIGN...6...6
N NAMINGAMING S STANDARDSTANDARDS...7...7
BUILD STRATEGY...13
BUILD STRATEGY...13
B BUILDUILD P PROCESSROCESS...13...13
B BUILDUILD S SEQUENCEEQUENCE...14...14
%onfigur %onfigure e and and 1ecure 1ecure the the #etwork..#etwork...9:...9:
%onfigur %onfigure e the the /e"ices.../e"ices...9-
...9- /eplo$ the 4 /eplo$ the 4perating 1$stem.perating 1$stem...9-
...9- ;uild the < ;uild the <oundational Infroundational Infrastructure astructure 1er"ices...1er"ices...9-
...9- ;uild the R ;uild the Remaining 1er"iemaining 1er"ices...ces...97 ...97
;uilding the ;uilding the )n"iron)n"ironment 1e=uentiallment 1e=uentiall$...$...9> ...9> TEST STRATEGY...19
TEST STRATEGY...19
T TESTEST O OBJECTIESBJECTIES...1!...1!
T TESTEST P PROCESSROCESS...1!...1!
T TESTEST M METHODOLOGYETHODOLOGY...23...23
T$pes of Testing...+8
T$pes of Testing...+8
T Test est 1e=uence...1e=uence...+- ...+-Test %$cle...+7
Test %$cle...+7
T TESTEST S SCOPECOPE...27...27
R R ELEASEELEASE C CRITERIARITERIA "OR "OR T TESTINGESTING...27...27
0ass2<ail % 0ass2<ail %riteria for Triteria for Test %ases....est %ases...+6...+6
;ug 1e"erit ;ug 1e"erit$ 1cale...$ 1cale...+6...+6
T TESTEST L LABAB C CON"IGURATIONON"IGURATION...2#...2#
II NTEGRATED NTEGRATED E E NIRONMENT NIRONMENT T TESTSESTS...2!...2!
T TESTEST T TOOLSOOLS...2!...2!
SUMMARY...31 SUMMARY...31 REFERENCES...32 REFERENCES...32 A$$%&'()%*...33 A$$%&'()%*...33
Executive Summary
Windows Server System™ integrated server software provides the ability to develop,
deploy, and operate IT infrastructure more eectively and eciently. This is done by
delivering the Windows Server System infrastructure environment, a framewor for
reducing comple!ity and ensuring easier and more successful integration. The three ey
aspects of this are "ommon #ngineering "riteria, $eference %rchitecture, and Infrastructure
Solutions.
Windows Server System™ $eference %rchitecture &WSS$%' is a documentation set that
helps organi(ations design and deploy )icrosoft* technologies to create the most
integrated, standardi(ed, and optimi(ed Windows Server System platform. %ny reference
architecture is only as good as the amount of proving it has been through. The WSS$%
guidance provides architectural principles and blueprints used to create a sample
implementation that is tested and proven in a lab by leading hardware and software partners
for a truly integrated view of technology architecture.
To accomplish this, the documentation set was created to be relevant to all appropriate
audiences at each stage of an implementation pro+ect. It was wrien to be relevant at all
levels of granularity with respect to speci-c pain points, technology issues, and desired end
states. The typical audience includes technical and business decision maers, architects,
designers, administrators, and developers.
The most highlevel use of the documentation is as an aid to organi(ations trying to develop
standardi(ed approaches to technology infrastructure. This architectural approach will solve
many typical enterpriselevel problems that arise through unstructured, piecemeal, and non
standards based growth. The lowlevel use of the documentation, in the areas of design,
build, test, and operation provides a tactical approach to solving implementation issues or as
best practice guidance to reduce implementation time, ris, and cost.
The reference architecture provides the fundamental principles from which designs are
derived. This reference architecture, in combination with speci-c re/uirements, produces a
design to meet the common business re/uirements of enterprise IT organi(ations. 0or the
purpose of testing the reference architecture, we developed a model enterprise to de-ne the
re/uirements and built out a lab instantiation accordingly. This process itself was
documented in the WSS$% Implementation Guides.
% similar process can be followed by customers who wish to use the full content set through
the life cycle of an IT implementation pro+ect to produce a uni/ue solution that meets their
re/uirements.
Introduction
%ny reference architecture is only as good as the level of testing and proving that goes into
it. Without this, it would be +ust a whitepaper as opposed to a proven reference architecture.
Windows Server System $eference %rchitecture &WSS$%' fully embraced this sentiment and
performed e!tensive build and test procedures to ensure that the value of the resultant
documentation could be ma!imi(ed.
With a problem space as comple! and diverse as that addressed by WSS$%, it would be
naive to thin it can be described in a 1one si(e -ts all2 fashion. %s a result, it is always the
case that the Reference Blueprints are the right starting point to understand the architectural
principles and design options used to meet the established re/uirements and business
scenarios.
The process used is inherently reusable. The resultant design is one that meets the
re/uirements of a particular -ctitious organi(ation, and it is not e!pected that any
organi(ation could or should implement e!actly as per this lab implementation. 3aving said
that, there is a large amount of reusable best practice guidance in terms of speci-c
implementation details, and it is encouraged that these are reused. To that e!tent, the lab
implementation is a great way to redistribute implementation best practice4 it +ust should not
be seen as some ind of 1ultimate2 solution that all must comply with.
This document e!plains the process used to design, build, and test the lab implementation,
and provides as appendi!es in most cases, all the design and con-guration speci-cs. )ost
con-guration speci-cs and all con-guration -les can be found in the Deployment Kit
associated with this document.
Who Should Read This Document
This document is wrien to help anyone who wants to /uicly understand the lab
implementation speci-cs of WSS$% and how it may be used to help with the design and
deployment of )icrosoft Windows*based infrastructure. This audience spans all the
various roles of an IT professional from architects to implementers.
Knowledge rere!uisites
$eaders of this document must have a broad understanding of IT infrastructure design and
implementation issues. It is recommended that the other overview documents available in
WSS$% are read -rst, because relevant information has not been repeated here for the sae
of brevity. This document may also be read in con+unction with the Reference Blueprints to
beer understand the foundational principles for all service design. 5nderstanding the
concepts in this document will improve understanding of the service implementation
guidance provided as a signi-cant portion of WSS$%.
Architecture Driven Design
The Architecture Blueprints provide the architecture principles for designing IT infrastructure
of an enterpriseclass organi(ation. Integration of services in the IT infrastructure is vital for
an organi(ation to ma!imi(e bene-ts from it. The architecture design provides the
framewor for this integration and directly in6uences the options available to the architects
and engineers woring on the design of individual services in the architecture. This ensures
that the services wor within tightly de-ned architectural re/uirements.
To help ensure that design decisions are understood within the conte!t of the actual
instantiation, several appendi!es at the end of this document present the 1nuts and bolts2 of
the architecture design data along with other planning information presented in this
document.
Design Strategy
The lab implementation of WSS$% was designed by following a strategy of meeting
predetermined business re/uirements, understanding technical constraints, following a
structured and consistent process, and testing from bare metal devices to full functionality
across multiple service streams.
The primary business re/uirements that had to be addressed in the design strategy were7
The architecture must be inherently secure.
The architecture must provide for high availability.
The architecture must be manageable using commonly available management tools.
The architecture must be predictable in design, deployment, and operations.
The architecture must facilitate interoperability with partner solutions and
components.
The architecture must be supportable in a sustainable, cost eective way.
To meet these business re/uirements, the lab implementation made use of the )icrosoft
platform and partnered with )icrosoft development and service partners to plan, build,
deploy, and test a WSS$% lab environment against business scenarios de-ned by the
-ctitious "ontoso "orporation, a wholly owned subsidiary of Woodgrove 3oldings. The
document sets that compose WSS$% were followed se/uentially and by service to perform
the detailed design, planning, build, and operations used to meet the business goals
established in the design and supporting lab functional test scenarios.
Design rocess
When planning the design process for the test lab environment, the design team prioriti(ed
the following si! primary business drivers into three components7
Security: The design used threat modeling techni/ues and applied a mitigation
strategy called defenseindepth.
High availability: #very component in the architecture had a failover strategy
applied to ensure that there is no single point of failure. This included redundant
components, parallel capabilities, hardware load balancing, and software failover
through clustering amongst others.
Predictability: It was important to be predictable in design through high degrees of
standardi(ation and policybased principles, predictable in deployment through
high degrees of automation, and predictable in operation through lab proving, which
includes load and functional stability tests and veri-cation.
Manageability: )anagement tools and process were included in the design process
tests.
Interoperability with partner technologies: 8etworing, server, and storage devices
from )icrosoft partners were used e!tensively throughout WSS$% lab
implementation, as well as partner software products for capabilities that were not
provided by the )icrosoft platform.
Supportability: Supportability is a primary cost factor and was measured as a factor
in determining the best practices. %ll involved partners, as well as )icrosoft, had the
resultant design rati-ed by their respective support organi(ation.
#ach individual service9s blueprint was developed to be as autonomous as possible.
3owever, dependencies on other services or tass within another service were necessary.
Tass across all blueprints were inspected for dependencies on other tass and the WSS$%
se/uence was optimi(ed to do as much as possible in parallel to help reduce the overall lab
implementation time.
"reation of comprehensive and usable enterprise infrastructure design documentation is a
comple! endeavor. 0re/uently, information that ought to have been in the documentation
never maes it there remaining stuc within the heads of the various systems architects and
design engineers. This can lead to several serious problems, such as poor understanding of
the design rationale and incomplete con-guration details. Worst of all, an incomplete or
incorrect understanding of systems design or maintenance procedures might even result in
downtime or data loss in the implemented IT infrastructure.
The Implementation Guides are organi(ed around IT services so that IT professionals can
rapidly access the information relevant to a desired service and from there, understand
related and:or dependent services. In addition, WSS$% comprises a number of scenarios that
are designed to address the ey business re/uirements in an enterprise. This release focuses
on the centrali(ed data center &";"' and satellite branch oce &S<=' scenarios.
The IT service guides document the whole lab design and the build and test processes. 0or
each IT service currently included within WSS$%, there are three guides called the Planning
Guide , Build Guide , and Operations Guide. "ustomers and partners may use this
documentation for a detailed understanding of the test lab environment, what decisions
were made and why. These three guides can be e!plained as follows7
The Planning Guide can be used as a starting point for future instantiations based on
the Architecture Blueprints and the Service Blueprints. <y following the planning
processes and design decisions provided, an organi(ation can create a design plan
/uicly and eciently to accelerate an information technology &IT' infrastructure
pro+ect.
The Build Guide is designed to clarify the se/uence of events and procedures that are
and ecient manner. &=ur scenarios are detailed in the >Introduction to %rchitecture
<lueprints> chapter of the Architecture Blueprints.'
The Build Guide for each of the services provides stepbystep instructions for
building the individual WSS$% service components as well as test guidance for each
of the services, including information about test methodology, the tools that were
used, and the dierent types of tests that were conducted. This serviceoriented test
guidance complements the information presented in the >Test =b+ectives, Strategy,
and )ethodology> section in this introductory document and certain other
documents in the !esting folder of the Deployment Kit.
The Operations Guide simply provides lins and information relevant to the operation
of the particular service. There was no e!pectation that the test lab would be re
created, as customers build to their uni/ue re/uirements. Therefore, it was decided
that e!plicit operations guidance such as daily, weely, monthly tass had lile
relevance.
Design Scenario
#ach IT service speci-c guide is organi(ed into a number of sections. #ach section addresses
the re/uired design information and processes for that speci-c service &or technology
components within the service, for e!ample ;8S, ;3"?, and WI8S within 18etwor
Services2' in the following scenarios7
Centralized Data Center (CDC): This scenario supports enterpriselevel services for
employees of the organi(ation &for e!ample, directory services and -le and print
services'. It is also the hub for the implementation of enterprisewide strategies &for
e!ample, security and management'. The ";" scenario may also contain a basic
Internet presence.
Satellite ranch !"ce (S!): This scenario addresses the geographically
distributed nature of an organi(ation through a physically decentrali(ed
environment. % branch oce that does not have local services is referred to as S<=.
The IT services addressed in the documentation have considerations that span the entire IT
life cycle. Therefore, there is separate guidance on planning, building, and operating each
service in customer solutions.
The following table lists the services documented in this release.
Service Technologies
Network Devices Routers, switches, virtual local area network (!AN", load #alancers $om%uting Devices Server classes, hardware re&uirements
Storage Devices Direct'attached storage (DAS", network'attached storage (NAS", storage area network (SAN"
De%loyment Services Installing and conguring o%erating systems )in*E, Sys*re%, and RIS+ Network Services DNS, D$*, and )INS+
-irewall Services *erimeter and internal rewalls and )e# %roxy service (ISA Server"+ Directory Service Active Directory. directory service+
-ile and *rint Services Distri#uted -ile System (D-S", %rinting congurations, and %rint
Service Technologies
devices+
Data Services /icroso0t S1! Server2 3444, )indows clusters+ )e# A%%lication
Services
/icroso0t Internet In0ormation Services (IIS" 5+4+
In0rastructure
/anagement Services
De#ug 0acilities, de%loyment ca%a#ilities, and remote management and tools+
6acku% and Recovery Data and systems #acku% and recovery in0rastructure+ $erticate Services *u#lic key in0rastructure (*7I"+
Remote Access Services
Site'to'site virtual %rivate network (*N", $lient *N, routing and remote access service (RRAS", Internet authentication service (IAS"+ /iddleware Services +NET -ramework+
/essaging Services /icroso0t Exchange Server 3448
Ta#le 9+ )SSRA Services !ist
"etwor# Design
The process of designing these services in the ";" and S<= scenarios resulted in a complete
and fully functional networ infrastructure. This infrastructure was then tested and
documented in the "et#or$ Services Build Guide. To illustrate the highlevel networ view of
this design, a logical networ diagram has been created. The legend for this diagram is as
follows.
%igure &. "et#or$ Design Overvie# 'egend
The following -gure is the ";" and S<= networ design overview, a detailed view of the
complete physical infrastructure is available in the appendi! at the end of this document.
%igure (. "et#or$ Design Overvie#
"aming Standards
The physical and logical e/uipment names use the following format7
@@@;;A0000SS B CCCCCCD
Where7
$ode /eaning Descri%tion
!!! !ocation 8 al%ha#etic characters (0or exam%le, SEA, !:N"+
$ode /eaning Descri%tion
DD Domain 3 al%ha#etic characters (0or exam%le, NA, AS, E;"+
---- -unction 3'< al%hanumeric characters (0or exam%le, D$, S1!9, -I!, )E6"+
SS Se&uence 3 numeric characters (0or exam%le, 49 through =="+
irtual Name 9'5 al%hanumeric characters (0or exam%le, S1!3I8, )E6$<"+
Ta#le 3+ Naming Standards
5sing dashes between the -elds enables easier parsing of the name by automation tools and
sorting for reporting or display interfaces. This also maes it easier for the reader to see the
-elds clearly separated.
The domain -eld is necessary because some sites have multiple domains and it helps the
operators identify in which domain the computer is.
0unction names can include a number at the end to help identify an 8@< or failover cluster.
The se/uence number is used to identify the uni/ue node within the cluster. 0or e!ample,
SE@FGH would be node H of SE@ cluster F.
0or 8@< cluster aliases and failover cluster virtual names, a special condition will be used.
;rop the se/uence, use no more than characters for the alias name, and do not put a dash
in the alias name. 0or e!ample, SE@F may be the failover cluster alias and SE@FIF might
indicate SE@ Server instance F on a cluster named SE@F.
8etwor devices that are not associated with a domain can use the domain placeholder
value of 8; for networ device.
The following table lists the location codes, type of oce, and si(e as de-ned by the scenario
re/uirements.
$ode !ocation :>ce Ty%e :>ce Si?e
AT! Atlanta, @A ;SA Sales o>ce 94 6$! 6arcelona, S%ain Sales o>ce 6EI 6eiBing,$hina Sales o>ce 6@! 6angalore, India Research and develo%ment 8 6!/ 6loomington, I! ;SA InsuranceC * $ 9,44 6:N 6onn, @ermany Telecommunications 3,44 6RS 6russels, 6elgium @overnment sales, Euro%ean ;nion
location
9
$AI $airo,Egy%t Saleso>ce $6/ $am#ridge, /A ;SA Education 85 $DR $edar Ra%ids, IA ;SA Sales o>ce $!@ $algary, $anada Sales o>ce 9< $:* $o%enhagen, Denmark Sales o>ce 9 $R $aracas, ene?uela Sales :>ce 9 DA! Dallas,TF;SA *etroleum 34 DEN Denver, $:;SA Saleso>ce 94 D;6 Du#lin, Ireland Research and develo%ment 944
$ode !ocation :>ce Ty%e :>ce Si?e
D;A Du#ai, ;nited Ara# Emirates Sales o>ce ED6 Edin#urgh, Scotland Research, develo%ment and sales
o>ce
<4
--D -aireld, $T ;SA Develo%ment de%artment's%ecic NA -- -aireld, $T ;SA R de%artment's%ecic NA --! -aireld, $T ;SA $om%any head&uarters and
diversied nancials
,444
7@ ong 7ong, $hina Sales o>ce :D ouston, TF ;SA Develo%ment de%artment's%ecic NA :; ouston, TF ;SA Airlines 9,44 RT art0ord, $T ;SA ealthcare 3,44 GA7 Gakarta, Indonesia Sales :>ce <
7;! 7uala !um%ur, /alaysia Research and develo%ment and Regional site
H
!:N !ondon, ;nited 7ingdom Research, develo%ment, sales o>ce and regional site
34
/EF /exico $ity, /exico Sales :>ce 8 /IA /iami, -! ;SA Sales o>ce and regional site 4 /RS /arseille, -rance Research, develo%ment and sales
o>ce
8
/;N /unich, @ermany Sales o>ce N)N Newark, NG ;SA Sales o>ce and regional site 9 N$ New ork, N ;SA Securities 5,444 :DS :dessa, Russia *etroleum locationJ research and
develo%ment
*IT *itts#urgh, *A ;SA Sales o>ce RD; Raleigh, N$ ;SA Sales o>ce R:/ Rome,Italy Saleso>ce SAT San Antonio, TF ;SA $om%uters, :>ce E&ui%ment 8,<4 SEA Seattle, )A ;SA So0tware 9,<H4 SE: Seoul,7orea Sales:>ce = S-/ San -rancisco, $A ;SA $ommercial #anks (Em#arcadero" 3< S-: San -rancisco, $A ;SA S%ecialty retailing 9,44 SI Shira?, Iran *etroleum location 3 SN@ Singa%ore, Singa%ore Research, develo%ment and sales
o>ce
4
ST! St+ !ouis, /: ;SA Sales o>ce 94 ST; Stuttgart, @ermany Develo%ment and sales o>ce <= SD Sydney, Australia Research and develo%ment and
Regional site
<=
TAI Tai%ei, Taiwan Sales o>ce T!A Tel Aviv, Israel Sales o>ce < T:7 Tokyo, Ga%an Regional Site 5
$ode !ocation :>ce Ty%e :>ce Si?e
T:R Toronto, $anada Sales o>ce 3 )S@ )ashington, D$ ;SA @overnment sales
Ta#le 8+ !ocation $odes and :>ces
The following table lists the domain codes.
Code Domain A/ Americas AS Asia $* $or%orate*erimeter D Develo%ment E; Euro%e E- Extranet-orest R umanresources ID ID$interior I* ID$%erimeter ND Networkdevice RT Root
SA Standalone, no domain a>liation
Ta#le <+ Domain $odes
The following table lists the function codes.
$ode /eaning
A** A%%lication Servers (/iddleware Servers"
6A7 6acku%
$A $erticate authority server D$ Domain controller (generic" DE* De%loymentserver
D$* D$*Server
DNS Domain name server (generic" DNSA Domain name server (announcer" DNSR Domain name server (resolver" DS! Denitive So0tware !i#rary server EF6 Exchange #ridgehead server
EFD$ Exchange s%ecic @$ (D$ with @$ ena#led" EF- Exchange 0ront'end server
EFI Exchange Internet server EF/ Exchange mail#ox server EF* Exchange %u#lic 0olders server EFR Exchange routing server
$ode /eaning
-AAE SAN -a#ric A Edge Switch -A6$ SAN -a#ric 6 $ore Switch -A6E SAN -a#ric 6 Edge Switch
-I! -ileserver
-*S -ile and %rint server -)I -irewall (internal" -)* -irewall (%erimeter"
IAS Internet Authentication Service (RADI;S" /@T /anagement server (generic"
/:/ /icroso0t :%erations /anager
/S/1 /S/1server
/S* /ulti%le service %rovider
NAS Network Attached Storage server N6R Network #order router
NRTR Networkrouter
NS) Network switch
N)A* Network wireless access %oint
*7I *7Iserver
*RN *rintserver
*RF *roxyserver
*RFA A%%lication *roxy
*RF: In#ound :utlook )e# Access *roxy server *FE *re#oot Execution Environment server S/A SAN /anagement A%%liance
SITE Site'to'site *N server
S/TI S/T* server ()indows, in#ound" S/T: S/T* server ()indows, out#ound" S/T* S/T* server ()indows, generic" S1! S1! data#ase server (generic" S1!/ S1! management server S1!; S1! data#ase server (;nisys" S1!R Re%licated S1! server
S1;/ S1! management Server (;nisys" S;S So0tware ;%date Services
;T! ;tility
*N irtual *rivate Network server (RRAS" RS Anti'irus So0tware Services server
)E6 )e# server
)INS )INSserver
Ta#le + -unction $odes
#$a%ples
0ollowing are some of the e!amples7
00@%S;"GH
This server is the domain controller GH for the %sia domain located in the 0air-eld,
"T 5S% location.
@=8#5SE@HIF
This is a cluster virtual server name located in the @ondon site, and is part of the
#urope domain. 0rom the virtual server name, it is SE@ Server instance F in the SE@H
failover cluster.
6uild Strategy
The process of building an IT infrastructure is one that has many interdependencies among
the various service components. IT professionals and consultants typically have speciali(ed
nowledge of certain aspects of the process, but there is considerable need for coordination
of the overall process.
This section describes the strategy and se/uence used to build the ";" and S<= scenarios in
the test labs.
$uild rocess
When planning the build process for the test lab environment, the development team
wored with the following three primary business drivers7
&educe the build ti%e: To verify the build documentation, the test team planned to
build the environment three times focusing on the eciency of the build
documentation. It was necessary to reduce the build time as much as possible to
reduce the overall test cycle time to validate the eciency of the complete,
documented process.
'se dierent roles to peror% dierent tas*s: %n IT organi(ation typically has
dierent people performing various parts of a build process. The overall build
strategy needed to account for the separate roles that perform tass within and
across the dierent service build guides.
#nviron%ent is in production %ode: %lthough the environment was built in a test
lab, the build process needed to accommodate a secured, e!isting production
environment. This consideration allowed the build guidance for each service to be
more relevant for implementation in an e!isting production environment.
#ach individual service9s build guide was developed to be as autonomous as possible.
3owever, dependencies on other services or tass within another service9s build guide were
necessary. The tass across all the build guides were inspected for dependencies on other
tass and the build se/uence was optimi(ed to do as much as possible in parallel to help
reduce the build time. 0or e!ample, most of the device con-guration tass were done in
parallel because they were not dependent on each other or on other services. <ecause the test
team consisted of ten people or more, the build process could further tae advantage of
many people performing various tass in parallel to shorten the build time.
#ach tas in each build guide identi-es the role that performs the tas, and the test team
assigned a lead person for building each service and one or more persons for support. In this
way, each person performed a dierent role for building the various services. The tas
se/uencing was coordinated between the service leads to ensure that a tas was not
performed prematurely.
$uild Se!uence
The networ and foundational infrastructure services such as %ctive ;irectory, ;8S, ;3"?,
WI8S, and 0irewall already e!ist in most IT production environments, which are also
secured following the organi(ation9s security policies. The build process put the
environment in this con-guration as soon as possible.
The tass used to build the environment in the test lab can be grouped into the following
series of phases, each of which contains the build for one or more services7
"on-gure and secure the networ.
"on-gure the computing and storage devices.
;eploy the operating system.
<uild the foundational infrastructure services.
<uild the remaining services.
Within &and in some cases across' each phase, tass can be performed in parallel or serial.
?arallel tass are those that can be accomplished without aecting other services. 0or
e!ample, the operating system can be installed on any or all servers without waiting for any
one server build to be completed.
Serial tass are those that must be accomplished in a speci-c se/uential order and cannot be
e!ecuted until a previous tas has been completed. 0or e!ample, the -rst domain controller
in the forest must be installed before installing any subse/uent domain controllers in the
same forest.
The build process for most of the services is dependent on the successful installation and
con-guration of one or more other services. The service dependencies are identi-ed in the
individual build guide. 0or more information on the dependencies for each individual tas,
refer to >%ppendi! J.KL<uild Se/uence ;etails> at the end of this document and
BuildOrder.mpp in the Deployment Kit.
The following subsections describe each of the listed phases in detail.
%on&gure and Secure the "etwor#
The tass described in the "et#or$ Devices Implementation Guides were used to con-gure the
router, switch, and load balancer devices. The interior networs were secured by following
the tass in the >Interior 0irewalls> section in the %ire#all Services Implementation Guides.
The tass in this phase were performed in parallel with those in the >"on-gure the ;evices>
phase, because most of the tass in >"on-gure the ;evices> phase do not re/uire the
networ. "on-guring and securing the networ before anything else enabled the other
services to be installed as if the environment was in a production mode.
%on&gure the Devices
This phase comprised tass from the )omputing Devices Build Guide and Storage Devices Build
Guide. <ecause no networ was re/uired, the tass in the )omputing Devices Build Guide were
completed in parallel with the tass in the "et#or$ Devices Build Guide.
)ost of the con-guration tass for the S%8 fabric and storage devices were performed in
parallel until a point where dependency on the networ was reached. Cerifying the <rocade
S%8 fabric re/uires all the host bus adapters &3<%s' be installed and con-gured on the
various servers. The 3? S%8 Storage )anagement %ppliance re/uires the directory service
so that the %ppliance computer can +oin the %ctive ;irectory domain. The #)" dis devices
re/uire that the 3<%s be installed and con-gured on the 5nisys servers before the storage
can be presented to the servers. The con-guration of the S%8 diss on both the 3? and #)"
storage devices was performed prior to their speci-c dependencies and did not prevent
installation of the server operating system.
Deploy the 'perating System
This phase comprised tass from the Deployment Services Build Guide. The deployment server
was built in parallel with the networ con-guration because it did not re/uire the networ.
When the networ was available, the Sysprep reference computers were built and the
operating system dis images were captured &and are documented in the Deployment Services
Build Guide'. 8e!t, the operating system was deployed and con-gured on all the computers
in the environment, including the servers in the perimeter networ, which were temporarily
connected to a separate switch device until the networ con-guration scripts re/uired the
server to be placed on its production networ.
$uild the (oundational Infrastructure Services
With the operating system deployed, the perimeter -rewalls and e!ternal pro!y servers were
con-gured using the tass in the >?erimeter 0irewalls> and >#!ternal ?ro!y Servers> sections
in the %ire#all Services Build Guide. Since these servers were standalone servers, they were
installed in parallel. ?erforming these tass at this point completed the process of securing
the networ.
%ll tass in the Directory Service Build Guide were performed in se/uence to create the
internal corporate and perimeter %ctive ;irectory forests and associated domains, which
enabled functioning of ;8S namespaces so that the rest of the servers could +oin their
appropriate domains.
With the internal domain created, the 3? S%8 management appliance was +oined to the
domain and its con-guration was completed. This allowed the management con-guration of
the S%8 multipath software prior to installing the 3<% drivers on the S%8aached
computers.
The tass in the >;8S> section in the "et#or$ Services Build Guide were used to build the ;8S
namespace for the internal and perimeter (ones.
The tass in the >;3"?> section in the "et#or$ Services Build Guide were used to build the
;3"? service on a server failover cluster. <ecause ;8S on the domain controllers was
already con-gured, these tass were performed in parallel with the >;8S> tass.
Immediately following the >;3"?> tass, the tass in the >WI8S> section in the "et#or$
Services Build Guide were used to build the WI8S service on the same server failover cluster
as the ;3"? service. The >WI8S> tass were performed after the >;3"?> tass because the
>;3"?> tass built the cluster.
With the internal corporate %ctive ;irectory domain created, the internal pro!y servers were
built using the tass in the >Internal ?ro!y Servers> section in the %ire#all Services Build Guide.
These tass were performed in parallel with the ;8S, ;3"?, and WI8S because they were
not dependent on these services.
%t this point, the networ was built and secured, the S%8 storage was con-gured and ready
for servers to wor with, all computers had the operating system installed, the %ctive
;irectory domains were built, the -rewalls and pro!y servers were built, and ;8S, ;3"?,
and WI8S were built.
$uild the Remaining Services
With the foundational services built, the rest of the services were installed and con-gured.
The se/uence of the discussion below is appro!imately how the rest of the services were
installed. )ost of the remaining services were built in parallel4 however, some services were
dependent on the build of other services. 5nless noted in the discussion below, each of the
services were built in parallel.
The tass in the Infrastructure *anagement Services Build Guide were performed to
build the management servers in the interior and perimeter (ones. Installing these
servers prior to the other services allowed the remote management functions to be
available for the other services9 build tass.
The tass in the >0ile Service> and >?rint Service> sections in the %ile and Print Services
Build Guide were followed to build the -le and print services on their associated
server failover clusters. These two services were built in parallel after their
foundation services &directory service and S%8 storage' were complete.
The tass in the Data Services Build Guide were followed to build the data service for
each of the various con-gurations. ;uring the data service installation on the 5nisys
computers, the remaining tass for building the #)" S%8 storage device were
performed.
The tass in the +e, Application Services Build Guide were followed to build the
internal corporate and e!ternal perimeter Web servers. These tass only built the
service to a point where it was ready to support Web sites. The Web sites used for
testing were built as part of the testing scenarios.
The tass in the *iddle#are Services Build Guide were followed to build the internal
corporate and e!ternal perimeter middleware application servers. These tass only
built the service to a point where it was ready to support middleware applications.
The applications used for testing were installed as part of the testing scenarios.
The tass in the )erti-cate Services Build Guide were followed to build the root,
intermediate, and issuing certi-cation authority &"%' servers for the corporate (one
and the root:issuing "% server for hardware router devices. <ecause the root and
intermediate "% servers were standalone, oMine servers, the initial con-guration
tass were performed immediately after the operating system was deployed.
3owever, because the certi-cates needed to be published to a Web site, the Web
publishing tass for the root and intermediate certi-cates and all of the tass for the
issuing "% servers were performed after the Web servers were built in the +e,
Application Services Build Guide. The tass for the root or issuing "% for hardware
router devices were performed after the root corporate domain was created in the
Directory Service Build Guide and the Web servers were built in the +e, Application
Services Build Guide.
The tass in the Remote Access Services Build Guide were followed to build the
$%;I5S and C?8 servers and the S<= C?8 router device. <ecause the C?8 service
re/uired certi-cates to operate correctly, the tass in this guide were performed after
the certi-cates were published in the )erti-cate Services Build Guide.
The tass in the *essaging Services Build Guide were followed to build the message
stores, S)T?, public folders and #!change pro!y services. )essaging services were
built out as an overlaying service using several base and supporting services of the
Windows Server System $eference %rchitecture. This allowed for validation of the
supporting services against the messaging service components, and the validation of
the messaging services running on the standard WSS$% architecture.
The tass in the Bac$up and Recovery Services Build Guide were followed to build the
bacup and recovery service. The initial con-guration of the "ommServe and
)edia%gent servers was performed immediately after the tass in the Directory
Service Build Guide were completed, which allowed testing of networ
communication between the bacup media servers as well as operation of the tape
devices through S%8. The tass for installing the idata%gents were performed after
all the dependent servers were completely installed and properly functioning.
Waiting until the other servers were complete reduced confusion and comple!ity of
the build process.
$uilding the )nvironment Se!uentially
In some cases, to reduce the build comple!ity, it may be advantageous to build the
environment se/uentially with no parallel activity. 5se the following list in the order
presented as a guide7
J. ?erform all the tass in the "et#or$ Devices Build Guide , which will build and
secure the networ including the interior -rewall. The perimeter -rewall and
pro!y servers will be built later.
H. ?erform all the tass in the )omputing Devices Build Guide.
F. ?erform all the tass in the Storage Devices Build Guide but perform the dependent
tass re/uiring the directory service and the tass for the #)" storage device for
installing the 3<%s later.
N. ?erform all the tass in the Deployment Services Build Guide.
K. ?erform the tass in the >?erimeter 0irewalls> and >#!ternal ?ro!y Servers>
sections in the %ire#all Services Build Guide , which will complete securing the
networ.
. ?erform all the tass in the Directory Service Build Guide.
O. ?erform the remaining tass in the >3? S%8 Storage ;evices> section in the
Storage Devices Build Guide.
P. ?erform the tass in the >;8S> sections in the "et#or$ Services Build Guide.
Q. ?erform the tass in the >;3"?> sections in the "et#or$ Services Build Guide.
JG. ?erform the tass in the >WI8S> sections in the "et#or$ Services Build Guide.
JJ. ?erform the tass in the >Internal ?ro!y Servers> section in the%ire#all Service Build
Guide.
JH. ?erform all the tass in the Infrastructure *anagement Services Build Guide.
JF. ?erform the tass in the >0ile Service> sections in the %ile and Print Services Build
Guide.
JN. ?erform the tass in the >?rint Service> sections in the %ile and Print Services Build
Guide.
JK. ?erform all the tass in the Data Services Build Guide. In addition, complete the
remaining tass in the >#)" S%8 Storage ;evices> section in the Storage Devices
Build Guide.
J. ?erform all the tass in the +e, Application Services Build Guide.
JO. ?erform all the tass in the *iddle#are Services Build Guide.
JP. ?erform all the tass in the )erti-cate Services Build Guide.
JQ. ?erform all the tass in the Remote Access Services Build Guide.
HG. ?erform all the tass in the Bac$up and Recovery Build Guide.
HJ. ?erform all the tass in the *essaging Services Build Guide.
Test Strategy
This section provides a test plan overview of the -rst prescriptive implementation of WSS$%
that was built and tested in )icrosoft test labs. This section describes test ob+ectives, strategy,
and methodology and identi-es the test scope and the de-ning release criteria that were
used to determine successful completion of the testing phase.
Test 'b*ectives
WSS$% tests are designed to reduce or eliminate uncertainty in the performance and
capabilities of the services provided by WSS$% to support both )icrosoftoriginated
solution oerings and customi(ed solutions developed for individual customers. This results
in direct time and cost savings to WSS$% documentation users because they can more easily
debug their implementations nowing that fundamental environmental issues have already
been solved.
The speci-c test ob+ectives for the testing eorts were7
To validate the documentation /uality by ensuring that the content of the guidance
was clear, accurate, consistent, easy to use, and met the re/uirements of de-ned
customer scenarios.
"ustomers should be able to rely on the documentation to design, implement, and
operate data center instantiations based on WSS$%.
To verify that the architecture for each service met design re/uirements for
availability, security, manageability, recoverability, and usability.
The architecture should provide the highest degree of system and networlevel
security without interfering with the ability of any system to carry out its ey
functions. %ll systems in the architecture should be manageable both locally and
remotely without any security riss.
To ensure that all the services wored together concurrently in the integrated
WSS$% environment.
System integration testing was used to uncover any coe!istence issues between the
mi! of )icrosoft and third party services and components used in the test lab
instantiation.
To describe performance levels of ey networ and operating system services both
on a servicebyservice basis and as an integrated whole without tuning or
optimi(ation.
Test rocess
The test team began by formulating highlevel plans, schedule estimates, and stratagems
based on the pro+ect scope document, customer scenarios, initial services lists, and e!isting
architectural and design documentation. %s the pro+ect progressed, these plans were
ad+usted to meet updated technical information, scope changes, and operational realities.
The test team used nowledge gained from their involvement in reviewing all stages of
architectural and design development as well as their e!perience from previous releases to
derive initial test case speci-cations. @ater, planning documentation was evaluated to
determine what claims were being made and which of those claims would re/uire speci-c
testing by the test team. The following -gure depicts a de-ned process.
%igure . !urning Speci-cations Into !est )ases
This process is supported by the following templates, which are available in the !esting
folder of the Deployment Kit7
)laims Document / !emplate.doc
Relevant )laims Document / !emplate.doc
!est Design Speci-cations Document / !emplate.doc
These templates were used to e!tract and develop relevant claims into re-ned test case
speci-cations, which were then used to create test cases in a test case management tool.
The process of deploying the test lab was used to ensure the /uality of prescriptive guidance.
It began with veri-cation of the labRs hardware as assembled, raced, and wired compared
against the )on-guration*atri0.0ls -le &available in the Deployment Kit'. =nce it was
established that the lab hardware was conformant, the test team built the lab from the
ground up following the build guidance e!actly as wrien. This allowed testers to uncover
errors in se/uencing, omissions, and accuracy of the build guidance at the earliest stage in
the test process. =nce the lab system was built, short con-guration audits and simple build
veri-cation tests &<CTs' were performed to ensure that all systems were functional and no
human errors had crept into the deployment process. 5pon ensuring that the systems as
built conformed to the prescriptive guidance, the indepth functional, load, and security tests
were performed.
To verify the accuracy of the documentation, the test team designed speci-c test cases to
validate statements made within the documentation. %ny claims that described speci-c
functions or performance levels for a service in the Planning Guide that were not already
substantiated through published test results or case studies from )icrosoft or partners were
validated in the test labs during functional, load, or security testing.
The test team devised various user scenarios with corresponding e!erciser applications to
stress the ey systems. #!ercising these scenarios activated a suite of interdependent services
across the environment, which e!posed integration and interoperability issues that were
corrected.
The test team applied the same loads to the system while testing for availability during the
outage of various system components. #ach redundant component was failed so that its
bacup component carried the full load. ?erforming these tests under heavy load e!posed
issues that would not have appeared if the failover tests had been performed with only
nominal loads.
Security penetration tests were run by both the test team and by )icrosoft 0oundstone
security assessment e!perts to ensure that nown cracing e!ploits would fail against
WSS$%. These tests were performed while load tests were also running to beer simulate
hacing aempts against a woring system. The published 0oundstone assessment can be
found at the following 5$@7
hp7::www.foundstone.com:inde!.htm
subnavresources:navigation.htmUsubcontent:resources:whitepapers.htm
#ach service was built and tested independently. %fter all services had passed independent
testing, integrated testing was performed against all services at once. %ny errors that were
uncovered in documentation, system components, interoperability, or failure to meet design
goals were entered and traced as bugs.
=nce all other tests in a pass were completed, the test team launched an integrated test
pro-le based on the estimated average usage paern for a HN hour day at the "ontoso
organi(ation. The pro-le simultaneously e!ecuted all e!erciser applications that had been
used earlier to test each individual service. ;uring the test, individual service components
were not saturated but instead were run together with varying loads according to the
estimated "ontoso business activity pro-le. This was done to e!pose any system bolenecs
resulting from multiple usages of critical components as well as any remaining integration
issues.
<efore concluding the -rst test pass, all changes made as a result of resolved bugs were
evaluated for the lielihood that they may have destabili(ed previously tested systems or
invalidated earlier e!ecuted test cases. If there was a medium or higher probability of such,
regression tests of the earlier cases were performed.
;uring the second test pass, the lab was rebuilt. % full repetition of the test suite was then
performed, followed once again by any needed regression tests. In the third and -nal test
pass, the lab was once again rebuilt. The lab was then used to regress all remaining issues
from the earlier passes as well as to perform a -nal combined services integration test.
Test +ethodology
This section describes overall test methodology in testing. It -rst de-nes the types of testing
and then describes the se/uence of test e!ecutions and test cycles.
Types of Testing
The focus of testing WSS$% guidance is dierent from that of product testing. ?roduct
testing focuses on the individual product and its features, while testing of WSS$% guidance
emphasi(es on system integration as well as interoperability and product coe!istence4 this
testing is an e!tension to product testing, because it bridges product development and
customer deployment in the -eld. The test team considered the following types of testing for
each area of coverage7
Docu%ent veri+cation testing: This testing preceded all other formal testing to
ensure that subse/uent test phases were carried out on a system that was con-gured
e!actly as documented. ;ocumentation veri-cation began with a critical review of
planning and deployment documentation with an eye towards identifying any errors
in accuracy, consistency, readability, or clarity. =nce the identi-ed errors were
corrected and the lab hardware was ready, the lab was built by following the
deployment documentation e!actly as it was wrien. <uild guide veri-cation
ensured that the instructions and guidance on how to deploy the services was
correctly se/uenced, clear, accurate, and unambiguous.
uild veri+cation tests (,-s):
<CTs included con-guration audits and short or
/uic tests that veri-ed basic core functionality of the systems and services to ensure
that services were functional and deployed per documentation. These tests were
useful because they e!posed human errors that occurred during the build process.
.vailability testing: This testing helped ensure that networ adapter teaming &8I"
teaming', 8etwor @oad <alancing, Windows "lustering, and other servicesR
primary or secondary availability features were available and woring under
varying conditions. %vailability tests were typically carried out by causing a failure
in one of the redundant components and verifying that the bacup component too
up the functionality with no une!pected interruption of service. %vailability tests
were -rst run without signi-cant load on the target server, and then rerun with near
saturation loads.
&ecoverability testing: This testing was done to aid production support in ensuring
that ade/uate procedures were in place for restoring the system should a disaster
occur. ;ierent services of the architecture had dierent bacup and restoration
needs. #ach service was tested with both bacups under high system load and
restoration to blan systems.
Manageability testing: This testing was performed to prove that the environment
had ade/uate monitoring and alerting mechanisms. #ach ey service had its own set
of metrics to monitor and command capabilities to verify. %dditionally,
manageability tests were almost always performed through %dministrator virtual
private networ &C?8' connections to ensure remote accessibility.
Security testing: Security testing in WSS$% was performed to ensure that only users
with the appropriate authority were able to use the applicable services of the
architecture and that system entry points were appropriately protected from
hacing. Two approaches were used for security testing7 audits and penetration
testing. %udit tests were run during the build and installation phases to ensure that
securityrelated con-gurations were correctly documented in the build guidance and
that they had been correctly carried out by the system builders. ?enetration tests
were carried out after the whole environment was completely built and all account
policies and networ security had been applied and loced down. ?enetration tests
were conducted in depth, with each defenseindepth layer of the architecture
successively probed for vulnerabilities and threats using hacing tools and
approaches that are nown to the security community. ?enetration tests were
performed by the test team, )icrosoft security e!perts and 0oundstone security
assessment teams.
Peror%ance load testing: This testing was necessary to understand systemRs
capacity and behavior under overloaded conditions. =nce the capacity of each server
or group of servers and aached hardware is nown, a system designer can mae
beer scaling decisions. 5nderstanding the systemRs behavior under abnormally
high loads at or near system saturation allows a system designer to decide whether it
is appropriate to design in e!cess capacity where compromised responsiveness is not
acceptable.
Scalability load testing: Scalability is a /ualitative measure of how easy it is to
e!pand the infrastructure. Scalability testing was performed to determine how
systemRs overall capacities would change due to changes in component capacities
within the system.
Stability load testing: Stability testing is designed to ensure that the architecture is
stable when e!posed to prolonged load tests. This type of testing fre/uently e!poses
memory leas and other cumulative error conditions in the products and services.
Some degree of stability testing could be achieved through performance load testing
and scalability testing. % more deliberate and systematic stability test was done at
the end of each test pass.
Integration testing: Integration testing was used to beer understand the interactive
relationships between the individual service elements within WSS$% thus ensuring
that these elements wored together smoothly.
The test team built a pro-le to emulate the estimated usage paerns of the
hypothetical "ontoso organi(ation during a typical business day. @oad generation
tools for all relevant service components were then run simultaneously with varying
loads according to the pro-le with the intention of e!posing any integration issues or
system bolenecs resulting from multiple usages of critical components.
Test Se!uence
The test team e!ecuted three test cycle passes. Within each cycle, a se/uence of -ve distinct
test phases too place. The build phase was followed by <CT phase, which was always
completed before moving on to the functional test phase. There was greater 6e!ibility in the
later test phases, but for the most part, functional tests were substantially completed before
moving on to any load tests. Security penetration tests were performed concurrently with
load tests. #!ecution of individual test cases within each phase, depended on individual
details of each case, but allowed for greater 6e!ibility in general. #ach phase is described in
more detail as follows7
uild phase: #ach test cycle began with this phase. %t the beginning of this phase,
hardware was in place and raced but all servers and device con-gurations were
blan. The e!act steps outlined in the e!isting build guidance were then used to
build and con-gure servers, networing, S%8, and other devices. %ny problems
encountered with regard to se/uencing, clarity, accuracy, or ambiguousness of the
build guidance were logged and corrected as bugs.
uild veri+cation testing phase: 0ollowing the build phase, the test team performed
a set of con-guration audits and <CTs to ensure that hardware and software
components were operational as well as built and con-gured per documentation.
<CTs /uicly e!posed human errors made during deployment as well as errors in
deployment guidance that resulted in services not functioning properly. <CTs caught
these errors early so that later tests were not run against improperly built or
con-gured systems.
/unctional testing phase: =nce <CTs were completed, the test team focused on
verifying ey design goals of WSS$% including high availability, recoverability, and
manageability. 0unctional testing of various security features was also con-rmed at
this stage. #ach service had its own speci-c test cases that were used to verify that
functional design re/uirements were met for that service. )any functional tests were
performed both with and without loads placed on the service components being
tested.
0oad testing phase: %fter functional testing, the lab team focused on load tests.
There were four distinct types of load tests that too place during this phase7
performance, scalability, stability, and integrated systems load tests. Within this
phase, the test se/uence was generally to understand the performance behavior -rst,
then test the scalability of the design, and -nally test the integration with all other
system components. Stability testing typically occurred at mi!ed points throughout,
often in con+unction with one of the other load test types.
Security penetration testing phase: While load tests were running, the test team and
the )icrosoft security teams conducted security penetration testing using publicly
available tools.
Test %ycle
The test team completed three complete test cycle passes following the se/uencing outlined
above. #ach test pass began with blan server computers. While all three test passes shared
common testing activities, each had its own additional uni/ue testing themes that can be
e!plained as follows7
The theme of the -rst test pass cycle was to validate service build guidance. %
strategy of building and testing service components in a layered approach was used4
the approach was to build and test the overall system in sections that consisted of
coherent sets of servers and services. <efore moving on to additional sections, a
concentrated eort was made to resolve and regress any signi-cant bugs. <y
following this methodology, each subse/uently added section was assured of a
stable foundation. #ach additional section was added to the services provided by the
previous sections so that by the time the complete system was built, it had been
substantially tested for all but a few load tests and the remaining entire systems
integration test.
The themes of the second test pass cycle included validation of service build
guidance again &although a dierent strategy was used' as well as additional
independent security testing.
The build strategy used for the second test pass was to build:rebuild the lab entirely
before e!ecuting any test cases. This allowed a more integrated testing of the
updated build guidance.
