Lab Implementation

Windows Server System
Reference Architecture
Lab Implementation
Published: July 2005

For the latest information, please see http://www.microsoft.com/wssra
Abstract
Windows Server System™ Reference Architecture (WSSRA) delivers architectural guidance on

enterprise IT infrastructure. Crucial to the credibility of this guidance is the testing and proving of the
guidance to ensure the expected value can be derived from it when designing and implementing IT
infrastructure based on Microsoft® products and technologies. This document describes the process
followed to use the Reference Blueprints by injecting a fictitious scenario and then building and testing
the resultant design.
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 document remains with the user.
The example companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted herein are fictitious. No
association with any real company, organization, product, domain name,
email address, logo, person, places, or events 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.
© 2005 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Project, Windows, Windows Server, and Windows
Server System are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the
trademarks of their respective owners.
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 •
USA 00
Table of Contents
EXECUTIVE SUMMARY............................................................................................................................1
INTRODUCTION..........................................................................................................................................2
WHO SHOULD READ THIS DOCUMENT.........................................................................................................2
KNOWLEDGE PREREQUISITES.......................................................................................................................2
ARCHITECTURE DRIVEN DESIGN........................................................................................................3
DESIGN STRATEGY........................................................................................................................................3
DESIGN PROCESS..........................................................................................................................................3
DESIGN SCENARIO........................................................................................................................................5
NETWORK DESIGN........................................................................................................................................6
NAMING STANDARDS....................................................................................................................................7
BUILD STRATEGY.....................................................................................................................................13
BUILD PROCESS..........................................................................................................................................13
BUILD SEQUENCE........................................................................................................................................14
Configure and Secure the Network........................................................................................................14
Configure the Devices............................................................................................................................15
Deploy the Operating System.................................................................................................................15
Build the Foundational Infrastructure Services.....................................................................................15
Build the Remaining Services.................................................................................................................16
Building the Environment Sequentially..................................................................................................17
TEST STRATEGY.......................................................................................................................................19
TEST OBJECTIVES........................................................................................................................................19
TEST PROCESS.............................................................................................................................................19
TEST METHODOLOGY.................................................................................................................................23
Types of Testing......................................................................................................................................23
Test Sequence.........................................................................................................................................25
Test Cycle...............................................................................................................................................26
TEST SCOPE.................................................................................................................................................27
RELEASE CRITERIA FOR TESTING...............................................................................................................27
Pass/Fail Criteria for Test Cases...........................................................................................................28
Bug Severity Scale..................................................................................................................................28
TEST LAB CONFIGURATION.........................................................................................................................28
INTEGRATED ENVIRONMENT TESTS............................................................................................................29
TEST TOOLS................................................................................................................................................29
SUMMARY...................................................................................................................................................31
REFERENCES.............................................................................................................................................32
Appendixes.....................................................................................................................................................33
Executive Summary
Windows Server System™ integrated server software provides the ability to develop,
deploy, and operate IT infrastructure more effectively and efficiently. This is done by
delivering the Windows Server System infrastructure environment, a framework for
reducing complexity and ensuring easier and more successful integration. The three key
aspects of this are Common Engineering Criteria, Reference Architecture, and Infrastructure
Solutions.
Windows Server System™ Reference Architecture (WSSRA) is a documentation set that
helps organizations design and deploy Microsoft® technologies to create the most
integrated, standardized, and optimized Windows Server System platform. Any reference
architecture is only as good as the amount of proving it has been through. The WSSRA
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 project. It was written to be relevant at all
levels of granularity with respect to specific pain points, technology issues, and desired end-
states. The typical audience includes technical and business decision makers, architects,
designers, administrators, and developers.
The most high-level use of the documentation is as an aid to organizations trying to develop
standardized approaches to technology infrastructure. This architectural approach will solve
many typical enterprise-level problems that arise through unstructured, piecemeal, and non-
standards based growth. The low-level 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, risk, and cost.
The reference architecture provides the fundamental principles from which designs are
derived. This reference architecture, in combination with specific requirements, produces a
design to meet the common business requirements of enterprise IT organizations. For the
purpose of testing the reference architecture, we developed a model enterprise to define the
requirements and built out a lab instantiation accordingly. This process itself was
documented in the WSSRA Implementation Guides.
A similar process can be followed by customers who wish to use the full content set through
the life cycle of an IT implementation project to produce a unique solution that meets their
requirements.
Lab Implementation 1
Introduction
Any reference architecture is only as good as the level of testing and proving that goes into
it. Without this, it would be just a whitepaper as opposed to a proven reference architecture.
Windows Server System Reference Architecture (WSSRA) fully embraced this sentiment and
performed extensive build and test procedures to ensure that the value of the resultant
documentation could be maximized.
With a problem space as complex and diverse as that addressed by WSSRA, it would be
naive to think it can be described in a “one size fits all” fashion. As 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 requirements and business
scenarios.
The process used is inherently reusable. The resultant design is one that meets the
requirements of a particular fictitious organization, and it is not expected that any
organization could or should implement exactly as per this lab implementation. Having said
that, there is a large amount of reusable best practice guidance in terms of specific
implementation details, and it is encouraged that these are reused. To that extent, the lab
implementation is a great way to redistribute implementation best practice; it just should not
be seen as some kind of “ultimate” solution that all must comply with.
This document explains the process used to design, build, and test the lab implementation,
and provides as appendixes in most cases, all the design and configuration specifics. Most
configuration specifics and all configuration files can be found in the Deployment Kit
associated with this document.
Who Should Read This Document

This document is written to help anyone who wants to quickly understand the lab
implementation specifics of WSSRA and how it may be used to help with the design and
deployment of Microsoft Windows®-based infrastructure. This audience spans all the
various roles of an IT professional from architects to implementers.
Knowledge Prerequisites
Readers 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
WSSRA are read first, because relevant information has not been repeated here for the sake
of brevity. This document may also be read in conjunction with the Reference Blueprints to
better understand the foundational principles for all service design. Understanding the
concepts in this document will improve understanding of the service implementation
guidance provided as a significant portion of WSSRA.
2Windows Server System Reference Architecture

Architecture Driven Design
The Architecture Blueprints provide the architecture principles for designing IT infrastructure
of an enterprise-class organization. Integration of services in the IT infrastructure is vital for
an organization to maximize benefits from it. The architecture design provides the
framework for this integration and directly influences the options available to the architects
and engineers working on the design of individual services in the architecture. This ensures
that the services work within tightly defined architectural requirements.
To help ensure that design decisions are understood within the context of the actual
instantiation, several appendixes at the end of this document present the “nuts and bolts” of
the architecture design data along with other planning information presented in this
document.
Design Strategy
The lab implementation of WSSRA was designed by following a strategy of meeting
predetermined business requirements, 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 requirements that had to be addressed in the design strategy were:
 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 effective way.
To meet these business requirements, the lab implementation made use of the Microsoft
platform and partnered with Microsoft development and service partners to plan, build,
deploy, and test a WSSRA lab environment against business scenarios defined by the
fictitious Contoso Corporation, a wholly owned subsidiary of Woodgrove Holdings. The
document sets that compose WSSRA were followed sequentially 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 Process
When planning the design process for the test lab environment, the design team prioritized
the following six primary business drivers into three components:
 Security: The design used threat modeling techniques and applied a mitigation
strategy called defense-in-depth.
 High availability: Every 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
standardization and policy-based principles, predictable in deployment through
high degrees of automation, and predictable in operation through lab proving, which
includes load and functional stability tests and verification.
 Manageability: Management tools and process were included in the design process
tests.
 Interoperability with partner technologies: Networking, server, and storage devices
from Microsoft partners were used extensively throughout WSSRA lab
implementation, as well as partner software products for capabilities that were not
provided by the Microsoft platform.
 Supportability: Supportability is a primary cost factor and was measured as a factor
in determining the best practices. All involved partners, as well as Microsoft, had the
resultant design ratified by their respective support organization.
Each individual service's blueprint was developed to be as autonomous as possible.
However, dependencies on other services or tasks within another service were necessary.
Tasks across all blueprints were inspected for dependencies on other tasks and the WSSRA
sequence was optimized to do as much as possible in parallel to help reduce the overall lab
implementation time.
Creation of comprehensive and usable enterprise infrastructure design documentation is a
complex endeavor. Frequently, information that ought to have been in the documentation
never makes it there remaining stuck 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 configuration 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 organized 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, WSSRA comprises a number of scenarios that
are designed to address the key business requirements in an enterprise. This release focuses
on the centralized data center (CDC) and satellite branch office (SBO) scenarios.
The IT service guides document the whole lab design and the build and test processes. For
each IT service currently included within WSSRA, there are three guides called the Planning
Guide, Build Guide, and Operations Guide. Customers 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 explained as follows:
 The Planning Guide can be used as a starting point for future instantiations based on
the Architecture Blueprints and the Service Blueprints. By following the planning
processes and design decisions provided, an organization can create a design plan
quickly and efficiently to accelerate an information technology (IT) infrastructure
project.
 The Build Guide is designed to clarify the sequence of events and procedures that are
required to build the IT infrastructures for each of the WSSRA scenarios in a secure

and efficient manner. (Our scenarios are detailed in the "Introduction to Architecture
Blueprints" chapter of the Architecture Blueprints.)
The Build Guide for each of the services provides step-by-step instructions for
building the individual WSSRA service components as well as test guidance for each
of the services, including information about test methodology, the tools that were
used, and the different types of tests that were conducted. This service-oriented test
guidance complements the information presented in the "Test Objectives, Strategy,
and Methodology" section in this introductory document and certain other
documents in the \Testing folder of the Deployment Kit.
 The Operations Guide simply provides links and information relevant to the operation
of the particular service. There was no expectation that the test lab would be re-
created, as customers build to their unique requirements. Therefore, it was decided
that explicit operations guidance such as daily, weekly, monthly tasks had little
relevance.
Design Scenario
Each IT service specific guide is organized into a number of sections. Each section addresses
the required design information and processes for that specific service (or technology
components within the service, for example DNS, DHCP, and WINS within “Network
Services”) in the following scenarios:
 Centralized Data Center (CDC): This scenario supports enterprise-level services for
employees of the organization (for example, directory services and file and print
services). It is also the hub for the implementation of enterprise-wide strategies (for
example, security and management). The CDC scenario may also contain a basic
Internet presence.
 Satellite Branch Office (SBO): This scenario addresses the geographically
distributed nature of an organization through a physically decentralized
environment. A branch office that does not have local services is referred to as SBO.
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 (VLAN), load balancers
Computing Devices Server classes, hardware requirements
Storage Devices Direct-attached storage (DAS), network-attached storage (NAS),
storage area network (SAN)
Deployment Services Installing and configuring operating systems WinPE, SysPrep, and RIS.
Network Services DNS, DHCP, and WINS.
Firewall Services Perimeter and internal firewalls and Web proxy service (ISA Server).
Directory Service Active Directory® directory service.
File and Print Services Distributed File System (DFS), printing configurations, and print
Service Technologies
devices.
Data Services Microsoft SQL Server™ 2000, Windows clusters.
Web Application Microsoft Internet Information Services (IIS) 6.0.
Services
Infrastructure Debug facilities, deployment capabilities, and remote management
Management Services and tools.
Backup and Recovery Data and systems backup and recovery infrastructure.
Certificate Services Public key infrastructure (PKI).
Remote Access Site-to-site virtual private network (VPN), Client VPN, routing and
Services remote access service (RRAS), Internet authentication service (IAS).
Middleware Services .NET Framework.
Messaging Services Microsoft Exchange Server 2003
Table 1. WSSRA Services List
Network Design
The process of designing these services in the CDC and SBO scenarios resulted in a complete
and fully functional network infrastructure. This infrastructure was then tested and
documented in the Network Services Build Guide. To illustrate the high-level network view of
this design, a logical network diagram has been created. The legend for this diagram is as
follows.
Figure 1. Network Design Overview Legend
The following figure is the CDC and SBO network design overview, a detailed view of the
complete physical infrastructure is available in the appendix at the end of this document.

Figure 2. Network Design Overview
Naming Standards
The physical and logical equipment names use the following format:
LLL-DD-[FFFF-SS | VVVVVV]
Where:
Code Meaning Description

LLL Location 3 alphabetic characters (for example, SEA, LON).
Code Meaning Description
DD Domain 2 alphabetic characters (for example, NA, AS, EU).
FFFF Function 2-4 alphanumeric characters (for example, DC, SQL1, FIL,
WEB).
SS Sequence 2 numeric characters (for example, 01 through 99).
VVVVVV Virtual Name 1-6 alphanumeric characters (for example, SQL2I3, WEBC4).
Table 2. Naming Standards

Using dashes between the fields enables easier parsing of the name by automation tools and
sorting for reporting or display interfaces. This also makes it easier for the reader to see the
fields clearly separated.
The domain field is necessary because some sites have multiple domains and it helps the
operators identify in which domain the computer is.
Function names can include a number at the end to help identify an NLB or failover cluster.
The sequence number is used to identify the unique node within the cluster. For example,
-SQL3-02 would be node 2 of SQL cluster 3.
For NLB cluster aliases and failover cluster virtual names, a special condition will be used.
Drop the sequence, use no more than 6 characters for the alias name, and do not put a dash
in the alias name. For example, SQL3 may be the failover cluster alias and SQL3I3 might
indicate SQL Server instance 3 on a cluster named SQL3.
Network devices that are not associated with a domain can use the domain placeholder
value of ND for network device.
The following table lists the location codes, type of office, and size as defined by the scenario
requirements.
Code Location Office Type Office Size

ATL Atlanta, GA USA Sales office 10
BCL Barcelona, Spain Sales office 5
BEI Beijing, China Sales office 5
BGL Bangalore, India Research and development 35
BLM Bloomington, IL USA Insurance: P & C 1,500
BON Bonn, Germany Telecommunications 2,500
BRS Brussels, Belgium Government sales, European Union 15
location
CAI Cairo, Egypt Sales office 5
CBM Cambridge, MA USA Education 36
CDR Cedar Rapids, IA USA Sales office 5
CLG Calgary, Canada Sales office 14
COP Copenhagen, Denmark Sales office 15
CRV Caracas, Venezuela Sales Office 17
DAL Dallas, TX USA Petroleum 250
DEN Denver, CO USA Sales office 10
DUB Dublin, Ireland Research and development 100

DUA Dubai, United Arab Emirates Sales office 5
EDB Edinburgh, Scotland Research, development and sales 40
office
FFD Fairfield, CT USA Development department-specific NA
FFH Fairfield, CT USA HR department-specific NA
FFL Fairfield, CT USA Company headquarters and 7,000
diversified financials
HKG Hong Kong, China Sales office 5
HOD Houston, TX USA Development department-specific NA
HOU Houston, TX USA Airlines 1,700
HRT Hartford, CT USA Healthcare 2,700
JAK Jakarta, Indonesia Sales Office 4
KUL Kuala Lumpur, Malaysia Research and development and 85
Regional site
LON London, United Kingdom Research, development, sales office 250
and regional site
MEX Mexico City, Mexico Sales Office 3
MIA Miami, FL USA Sales office and regional site 50
MRS Marseille, France Research, development and sales 37
office
MUN Munich, Germany Sales office 5
NWN Newark, NJ USA Sales office and regional site 15
NYC New York, NY USA Securities 6,000
ODS Odessa, Russia Petroleum location; research and 5
development
PIT Pittsburgh, PA USA Sales office 5
RDU Raleigh, NC USA Sales office 5
ROM Rome, Italy Sales office 5
SAT San Antonio, TX USA Computers, Office Equipment 3,450
SEA Seattle, WA USA Software 1,480
SEO Seoul, Korea Sales Office 9
SFM San Francisco, CA USA Commercial banks (Embarcadero) 245
SFO San Francisco, CA USA Specialty retailing 1,500
SHI Shiraz, Iran Petroleum location 2
SNG Singapore, Singapore Research, development and sales 50
office
STL St. Louis, MO USA Sales office 10
STU Stuttgart, Germany Development and sales office 49
SYD Sydney, Australia Research and development and 49
Regional site
TAI Taipei, Taiwan Sales office 5
TLA Tel Aviv, Israel Sales office 45
TOK Tokyo, Japan Regional Site 565
TOR Toronto, Canada Sales office 25
WSG Washington, DC USA Government sales 75
Table 3. Location Codes and Offices

The following table lists the domain codes.
Code Domain
AM Americas
AS Asia
CP Corporate Perimeter
DV Development
EU Europe
EF Extranet Forest
HR Human resources
ID IDC interior
IP IDC perimeter
ND Network device
RT Root
SA Standalone, no domain affiliation
Table 4. Domain Codes

The following table lists the function codes.
Code Meaning
APP Application Servers (Middleware Servers)
BAK Backup
CA Certificate authority server
DC Domain controller (generic)
DEP Deployment server
DHCP DHCP Server
DNS Domain name server (generic)
DNSA Domain name server (announcer)
DNSR Domain name server (resolver)
DSL Definitive Software Library server
EXB Exchange bridgehead server
EXDC Exchange specific GC (DC with GC enabled)
EXF Exchange front-end server
EXI Exchange Internet server
EXM Exchange mailbox server
EXP Exchange public folders server
EXR Exchange routing server
FAAC SAN Fabric A Core Switch

Code Meaning
FAAE SAN Fabric A Edge Switch
FABC SAN Fabric B Core Switch
FABE SAN Fabric B Edge Switch
FIL File server
FPS File and print server
FWI Firewall (internal)
FWP Firewall (perimeter)
IAS Internet Authentication Service (RADIUS)
MGT Management server (generic)
MOM Microsoft Operations Manager
MSMQ MSMQ server
MSP Multiple service provider
NAS Network Attached Storage server
NBR Network border router
NRTR Network router
NSW Network switch
NWAP Network wireless access point
PKI PKI server
PRN Print server
PRX Proxy server
PRXA Application Proxy
PRXO Inbound Outlook Web Access Proxy server
PXE Preboot Execution Environment server
SMA SAN Management Appliance
SITE Site-to-site VPN server
SMTI SMTP server (Windows, inbound)
SMTO SMTP server (Windows, outbound)
SMTP SMTP server (Windows, generic)
SQL SQL database server (generic)
SQLM SQL management server
SQLU SQL database server (Unisys)
SQLR Replicated SQL server
SQUM SQL management Server (Unisys)
SUS Software Update Services
UTL Utility
VPN Virtual Private Network server (RRAS)
VRS Anti-Virus Software Services server
WEB Web server
WINS WINS server
Table 5. Function Codes
Examples
Following are some of the examples:
 FFL-AS-DC-02
This server is the domain controller 02 for the Asia domain located in the Fairfield,
CT USA location.
 LON-EU-SQL2I3
This is a cluster virtual server name located in the London site, and is part of the
Europe domain. From the virtual server name, it is SQL Server instance 3 in the SQL2
failover cluster.

Build 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 specialized
knowledge of certain aspects of the process, but there is considerable need for coordination
of the overall process.
This section describes the strategy and sequence used to build the CDC and SBO scenarios in
the test labs.
Build Process
When planning the build process for the test lab environment, the development team
worked with the following three primary business drivers:
 Reduce the build time: To verify the build documentation, the test team planned to
build the environment three times focusing on the efficiency 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 efficiency of the complete,
documented process.
 Use different roles to perform different tasks: An IT organization typically has
different people performing various parts of a build process. The overall build
strategy needed to account for the separate roles that perform tasks within and
across the different service build guides.
 Environment is in production mode: Although the environment was built in a test
lab, the build process needed to accommodate a secured, existing production
environment. This consideration allowed the build guidance for each service to be
more relevant for implementation in an existing production environment.
Each individual service's build guide was developed to be as autonomous as possible.
However, dependencies on other services or tasks within another service's build guide were
necessary. The tasks across all the build guides were inspected for dependencies on other
tasks and the build sequence was optimized to do as much as possible in parallel to help
reduce the build time. For example, most of the device configuration tasks were done in
parallel because they were not dependent on each other or on other services. Because the test
team consisted of ten people or more, the build process could further take advantage of
many people performing various tasks in parallel to shorten the build time.
Each task in each build guide identifies the role that performs the task, 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 different role for building the various services. The task
sequencing was coordinated between the service leads to ensure that a task was not
performed prematurely.
Build Sequence
The network and foundational infrastructure services such as Active Directory, DNS, DHCP,
WINS, and Firewall already exist in most IT production environments, which are also
secured following the organization's security policies. The build process put the
environment in this configuration as soon as possible.
The tasks 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 services:
 Configure and secure the network.
 Configure the computing and storage devices.
 Deploy the operating system.
 Build the foundational infrastructure services.
 Build the remaining services.
Within (and in some cases across) each phase, tasks can be performed in parallel or serial.
Parallel tasks are those that can be accomplished without affecting other services. For
example, the operating system can be installed on any or all servers without waiting for any
one server build to be completed.
Serial tasks are those that must be accomplished in a specific sequential order and cannot be
executed until a previous task has been completed. For example, the first domain controller
in the forest must be installed before installing any subsequent domain controllers in the
same forest.
The build process for most of the services is dependent on the successful installation and
configuration of one or more other services. The service dependencies are identified in the
individual build guide. For more information on the dependencies for each individual task,
refer to "Appendix 1.5—Build Sequence Details" at the end of this document and
BuildOrder.mpp in the Deployment Kit.
The following subsections describe each of the listed phases in detail.
Configure and Secure the Network

The tasks described in the Network Devices Implementation Guides were used to configure the
router, switch, and load balancer devices. The interior networks were secured by following
the tasks in the "Interior Firewalls" section in the Firewall Services Implementation Guides.
The tasks in this phase were performed in parallel with those in the "Configure the Devices"
phase, because most of the tasks in "Configure the Devices" phase do not require the
network. Configuring and securing the network before anything else enabled the other
services to be installed as if the environment was in a production mode.
Configure the Devices

This phase comprised tasks from the Computing Devices Build Guide and Storage Devices Build
Guide. Because no network was required, the tasks in the Computing Devices Build Guide were
completed in parallel with the tasks in the Network Devices Build Guide.
Most of the configuration tasks for the SAN fabric and storage devices were performed in
parallel until a point where dependency on the network was reached. Verifying the Brocade
SAN fabric requires all the host bus adapters (HBAs) be installed and configured on the
various servers. The HP SAN Storage Management Appliance requires the directory service

so that the Appliance computer can join the Active Directory domain. The EMC disk devices
require that the HBAs be installed and configured on the Unisys servers before the storage
can be presented to the servers. The configuration of the SAN disks on both the HP and EMC
storage devices was performed prior to their specific dependencies and did not prevent
installation of the server operating system.
Deploy the Operating System

This phase comprised tasks from the Deployment Services Build Guide. The deployment server
was built in parallel with the network configuration because it did not require the network.
When the network was available, the Sysprep reference computers were built and the
operating system disk images were captured (and are documented in the Deployment Services
Build Guide). Next, the operating system was deployed and configured on all the computers
in the environment, including the servers in the perimeter network, which were temporarily
connected to a separate switch device until the network configuration scripts required the
server to be placed on its production network.
Build the Foundational Infrastructure Services

With the operating system deployed, the perimeter firewalls and external proxy servers were
configured using the tasks in the "Perimeter Firewalls" and "External Proxy Servers" sections
in the Firewall Services Build Guide. Since these servers were standalone servers, they were
installed in parallel. Performing these tasks at this point completed the process of securing
the network.
All tasks in the Directory Service Build Guide were performed in sequence to create the
internal corporate and perimeter Active Directory forests and associated domains, which
enabled functioning of DNS namespaces so that the rest of the servers could join their
appropriate domains.
With the internal domain created, the HP SAN management appliance was joined to the
domain and its configuration was completed. This allowed the management configuration of
the SAN multipath software prior to installing the HBA drivers on the SAN-attached
computers.
The tasks in the "DNS" section in the Network Services Build Guide were used to build the DNS
namespace for the internal and perimeter zones.
The tasks in the "DHCP" section in the Network Services Build Guide were used to build the
DHCP service on a server failover cluster. Because DNS on the domain controllers was
already configured, these tasks were performed in parallel with the "DNS" tasks.
Immediately following the "DHCP" tasks, the tasks in the "WINS" section in the Network
Services Build Guide were used to build the WINS service on the same server failover cluster
as the DHCP service. The "WINS" tasks were performed after the "DHCP" tasks because the
"DHCP" tasks built the cluster.
With the internal corporate Active Directory domain created, the internal proxy servers were
built using the tasks in the "Internal Proxy Servers" section in the Firewall Services Build Guide.
These tasks were performed in parallel with the DNS, DHCP, and WINS because they were
not dependent on these services.
At this point, the network was built and secured, the SAN storage was configured and ready
for servers to work with, all computers had the operating system installed, the Active
Directory domains were built, the firewalls and proxy servers were built, and DNS, DHCP,
and WINS were built.
Build the Remaining Services

With the foundational services built, the rest of the services were installed and configured.
The sequence of the discussion below is approximately how the rest of the services were
installed. Most of the remaining services were built in parallel; however, some services were
dependent on the build of other services. Unless noted in the discussion below, each of the
services were built in parallel.
 The tasks in the Infrastructure Management Services Build Guide were performed to
build the management servers in the interior and perimeter zones. Installing these
servers prior to the other services allowed the remote management functions to be
available for the other services' build tasks.
 The tasks in the "File Service" and "Print Service" sections in the File and Print Services
Build Guide were followed to build the file and print services on their associated
server failover clusters. These two services were built in parallel after their
foundation services (directory service and SAN storage) were complete.
 The tasks in the Data Services Build Guide were followed to build the data service for
each of the various configurations. During the data service installation on the Unisys
computers, the remaining tasks for building the EMC SAN storage device were
performed.
 The tasks in the Web Application Services Build Guide were followed to build the
internal corporate and external perimeter Web servers. These tasks 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 tasks in the Middleware Services Build Guide were followed to build the internal
corporate and external perimeter middleware application servers. These tasks 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 tasks in the Certificate Services Build Guide were followed to build the root,
intermediate, and issuing certification authority (CA) servers for the corporate zone
and the root/issuing CA server for hardware router devices. Because the root and
intermediate CA servers were standalone, offline servers, the initial configuration
tasks were performed immediately after the operating system was deployed.
However, because the certificates needed to be published to a Web site, the Web
publishing tasks for the root and intermediate certificates and all of the tasks for the
issuing CA servers were performed after the Web servers were built in the Web
Application Services Build Guide. The tasks for the root or issuing CA 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 Web Application
Services Build Guide.

 The tasks in the Remote Access Services Build Guide were followed to build the
RADIUS and VPN servers and the SBO VPN router device. Because the VPN service
required certificates to operate correctly, the tasks in this guide were performed after
the certificates were published in the Certificate Services Build Guide.
 The tasks in the Messaging Services Build Guide were followed to build the message
stores, SMTP, public folders and Exchange proxy services. Messaging services were
built out as an overlaying service using several base and supporting services of the
Windows Server System Reference Architecture. This allowed for validation of the
supporting services against the messaging service components, and the validation of
the messaging services running on the standard WSSRA architecture.
 The tasks in the Backup and Recovery Services Build Guide were followed to build the
backup and recovery service. The initial configuration of the CommServe and
MediaAgent servers was performed immediately after the tasks in the Directory
Service Build Guide were completed, which allowed testing of network
communication between the backup media servers as well as operation of the tape
devices through SAN. The tasks for installing the idataAgents were performed after
all the dependent servers were completely installed and properly functioning.
Waiting until the other servers were complete reduced confusion and complexity of
the build process.
Building the Environment Sequentially

In some cases, to reduce the build complexity, it may be advantageous to build the
environment sequentially with no parallel activity. Use the following list in the order
presented as a guide:
1. Perform all the tasks in the Network Devices Build Guide, which will build and
secure the network including the interior firewall. The perimeter firewall and
proxy servers will be built later.
2. Perform all the tasks in the Computing Devices Build Guide.
3. Perform all the tasks in the Storage Devices Build Guide but perform the dependent
tasks requiring the directory service and the tasks for the EMC storage device for
installing the HBAs later.
4. Perform all the tasks in the Deployment Services Build Guide.
5. Perform the tasks in the "Perimeter Firewalls" and "External Proxy Servers"
sections in the Firewall Services Build Guide, which will complete securing the
network.
6. Perform all the tasks in the Directory Service Build Guide.
7. Perform the remaining tasks in the "HP SAN Storage Devices" section in the
Storage Devices Build Guide.
8. Perform the tasks in the "DNS" sections in the Network Services Build Guide.
9. Perform the tasks in the "DHCP" sections in the Network Services Build Guide.
10. Perform the tasks in the "WINS" sections in the Network Services Build Guide.
11. Perform the tasks in the "Internal Proxy Servers" section in the Firewall Service Build
Guide.
12. Perform all the tasks in the Infrastructure Management Services Build Guide.
13. Perform the tasks in the "File Service" sections in the File and Print Services Build
Guide.
14. Perform the tasks in the "Print Service" sections in the File and Print Services Build
Guide.
15. Perform all the tasks in the Data Services Build Guide. In addition, complete the
remaining tasks in the "EMC SAN Storage Devices" section in the Storage Devices
Build Guide.
16. Perform all the tasks in the Web Application Services Build Guide.
17. Perform all the tasks in the Middleware Services Build Guide.
18. Perform all the tasks in the Certificate Services Build Guide.
19. Perform all the tasks in the Remote Access Services Build Guide.
20. Perform all the tasks in the Backup and Recovery Build Guide.
21. Perform all the tasks in the Messaging Services Build Guide.

Test Strategy
This section provides a test plan overview of the first prescriptive implementation of WSSRA
that was built and tested in Microsoft test labs. This section describes test objectives, strategy,
and methodology and identifies the test scope and the defining release criteria that were
used to determine successful completion of the testing phase.
Test Objectives
WSSRA tests are designed to reduce or eliminate uncertainty in the performance and
capabilities of the services provided by WSSRA to support both Microsoft-originated
solution offerings and customized solutions developed for individual customers. This results
in direct time and cost savings to WSSRA documentation users because they can more easily
debug their implementations knowing that fundamental environmental issues have already
been solved.
The specific test objectives for the testing efforts were:
 To validate the documentation quality by ensuring that the content of the guidance
was clear, accurate, consistent, easy to use, and met the requirements of defined
customer scenarios.
Customers should be able to rely on the documentation to design, implement, and
operate data center instantiations based on WSSRA.
 To verify that the architecture for each service met design requirements for
availability, security, manageability, recoverability, and usability.
The architecture should provide the highest degree of system and network-level
security without interfering with the ability of any system to carry out its key
functions. All systems in the architecture should be manageable both locally and
remotely without any security risks.
 To ensure that all the services worked together concurrently in the integrated
WSSRA environment.
System integration testing was used to uncover any coexistence issues between the
mix of Microsoft and third party services and components used in the test lab
instantiation.
 To describe performance levels of key network and operating system services both
on a service-by-service basis and as an integrated whole without tuning or
optimization.
Test Process
The test team began by formulating high-level plans, schedule estimates, and stratagems
based on the project scope document, customer scenarios, initial services lists, and existing
architectural and design documentation. As the project progressed, these plans were
adjusted to meet updated technical information, scope changes, and operational realities.
The test team used knowledge gained from their involvement in reviewing all stages of
architectural and design development as well as their experience from previous releases to
derive initial test case specifications. Later, planning documentation was evaluated to
determine what claims were being made and which of those claims would require specific
testing by the test team. The following figure depicts a defined process.

Figure 3. Turning Specifications Into Test Cases
This process is supported by the following templates, which are available in the \Testing
folder of the Deployment Kit:
 Claims Document - Template.doc
 Relevant Claims Document - Template.doc
 Test Design Specifications Document - Template.doc
These templates were used to extract and develop relevant claims into refined test case
specifications, 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 quality of prescriptive guidance.
It began with verification of the lab’s hardware as assembled, racked, and wired compared
against the ConfigurationMatrix.xls file (available in the Deployment Kit). Once it was
established that the lab hardware was conformant, the test team built the lab from the
ground up following the build guidance exactly as written. This allowed testers to uncover
errors in sequencing, omissions, and accuracy of the build guidance at the earliest stage in
the test process. Once the lab system was built, short configuration audits and simple build
verification tests (BVTs) were performed to ensure that all systems were functional and no
human errors had crept into the deployment process. Upon ensuring that the systems as-
built conformed to the prescriptive guidance, the in-depth functional, load, and security tests
were performed.
To verify the accuracy of the documentation, the test team designed specific test cases to
validate statements made within the documentation. Any claims that described specific
functions or performance levels for a service in the Planning Guide that were not already
substantiated through published test results or case studies from Microsoft or partners were
validated in the test labs during functional, load, or security testing.
The test team devised various user scenarios with corresponding exerciser applications to
stress the key systems. Exercising these scenarios activated a suite of interdependent services
across the environment, which exposed 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. Each redundant component was failed so that its
backup component carried the full load. Performing these tests under heavy load exposed
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 Microsoft Foundstone
security assessment experts to ensure that known cracking exploits would fail against
WSSRA. These tests were performed while load tests were also running to better simulate
hacking attempts against a working system. The published Foundstone assessment can be
found at the following URL:
http://www.foundstone.com/index.htm?
subnav=resources/navigation.htm&subcontent=/resources/whitepapers.htm
Each service was built and tested independently. After all services had passed independent
testing, integrated testing was performed against all services at once. Any errors that were
uncovered in documentation, system components, interoperability, or failure to meet design
goals were entered and tracked as bugs.

Once all other tests in a pass were completed, the test team launched an integrated test
profile based on the estimated average usage pattern for a 24 hour day at the Contoso
organization. The profile simultaneously executed all exerciser applications that had been
used earlier to test each individual service. During the test, individual service components
were not saturated but instead were run together with varying loads according to the
estimated Contoso business activity profile. This was done to expose any system bottlenecks
resulting from multiple usages of critical components as well as any remaining integration
issues.
Before concluding the first test pass, all changes made as a result of resolved bugs were
evaluated for the likelihood that they may have destabilized previously tested systems or
invalidated earlier executed test cases. If there was a medium or higher probability of such,
regression tests of the earlier cases were performed.
During the second test pass, the lab was rebuilt. A full repetition of the test suite was then
performed, followed once again by any needed regression tests. In the third and final 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 final combined services integration test.
Test Methodology
This section describes overall test methodology in testing. It first defines the types of testing
and then describes the sequence of test executions and test cycles.
Types of Testing
The focus of testing WSSRA guidance is different from that of product testing. Product
testing focuses on the individual product and its features, while testing of WSSRA guidance
emphasizes on system integration as well as interoperability and product coexistence; this
testing is an extension to product testing, because it bridges product development and
customer deployment in the field. The test team considered the following types of testing for
each area of coverage:
 Document verification testing: This testing preceded all other formal testing to
ensure that subsequent test phases were carried out on a system that was configured
exactly as documented. Documentation verification began with a critical review of
planning and deployment documentation with an eye towards identifying any errors
in accuracy, consistency, readability, or clarity. Once the identified errors were
corrected and the lab hardware was ready, the lab was built by following the
deployment documentation exactly as it was written. Build guide verification
ensured that the instructions and guidance on how to deploy the services was
correctly sequenced, clear, accurate, and unambiguous.
 Build verification tests (BVTs): BVTs included configuration audits and short or
quick tests that verified basic core functionality of the systems and services to ensure
that services were functional and deployed per documentation. These tests were
useful because they exposed human errors that occurred during the build process.
 Availability testing: This testing helped ensure that network adapter teaming (NIC
teaming), Network Load Balancing, Windows Clustering, and other services’
primary or secondary availability features were available and working under
varying conditions. Availability tests were typically carried out by causing a failure
in one of the redundant components and verifying that the backup component took
up the functionality with no unexpected interruption of service. Availability tests
were first run without significant load on the target server, and then rerun with near
saturation loads.
 Recoverability testing: This testing was done to aid production support in ensuring
that adequate procedures were in place for restoring the system should a disaster
occur. Different services of the architecture had different backup and restoration
needs. Each service was tested with both backups under high system load and
restoration to blank systems.
 Manageability testing: This testing was performed to prove that the environment
had adequate monitoring and alerting mechanisms. Each key service had its own set
of metrics to monitor and command capabilities to verify. Additionally,
manageability tests were almost always performed through Administrator virtual
private network (VPN) connections to ensure remote accessibility.
 Security testing: Security testing in WSSRA 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
hacking. Two approaches were used for security testing: audits and penetration
testing. Audit tests were run during the build and installation phases to ensure that
security-related configurations were correctly documented in the build guidance and
that they had been correctly carried out by the system builders. Penetration tests
were carried out after the whole environment was completely built and all account
policies and network security had been applied and locked down. Penetration tests
were conducted in depth, with each defense-in-depth layer of the architecture
successively probed for vulnerabilities and threats using hacking tools and
approaches that are known to the security community. Penetration tests were
performed by the test team, Microsoft security experts and Foundstone security
assessment teams.
 Performance load testing: This testing was necessary to understand system’s
capacity and behavior under overloaded conditions. Once the capacity of each server
or group of servers and attached hardware is known, a system designer can make
better scaling decisions. Understanding the system’s behavior under abnormally
high loads at or near system saturation allows a system designer to decide whether it
is appropriate to design in excess capacity where compromised responsiveness is not
acceptable.
 Scalability load testing: Scalability is a qualitative measure of how easy it is to
expand the infrastructure. Scalability testing was performed to determine how
system’s 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 exposed to prolonged load tests. This type of testing frequently exposes
memory leaks 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. A more deliberate and systematic stability test was done at
the end of each test pass.
 Integration testing: Integration testing was used to better understand the interactive
relationships between the individual service elements within WSSRA thus ensuring
that these elements worked together smoothly.
 The test team built a profile to emulate the estimated usage patterns of the
hypothetical Contoso organization during a typical business day. Load generation
tools for all relevant service components were then run simultaneously with varying
loads according to the profile with the intention of exposing any integration issues or
system bottlenecks resulting from multiple usages of critical components.
Test Sequence
The test team executed three test cycle passes. Within each cycle, a sequence of five distinct
test phases took place. The build phase was followed by BVT phase, which was always
completed before moving on to the functional test phase. There was greater flexibility 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. Execution of individual test cases within each phase, depended on individual
details of each case, but allowed for greater flexibility in general. Each phase is described in
more detail as follows:
 Build phase: Each test cycle began with this phase. At the beginning of this phase,
hardware was in place and racked but all servers and device configurations were
blank. The exact steps outlined in the existing build guidance were then used to
build and configure servers, networking, SAN, and other devices. Any problems
encountered with regard to sequencing, clarity, accuracy, or ambiguousness of the
build guidance were logged and corrected as bugs.
 Build verification testing phase: Following the build phase, the test team performed
a set of configuration audits and BVTs to ensure that hardware and software
components were operational as well as built and configured per documentation.
BVTs quickly exposed human errors made during deployment as well as errors in
deployment guidance that resulted in services not functioning properly. BVTs caught
these errors early so that later tests were not run against improperly built or
configured systems.
 Functional testing phase: Once BVTs were completed, the test team focused on
verifying key design goals of WSSRA including high availability, recoverability, and
manageability. Functional testing of various security features was also confirmed at
this stage. Each service had its own specific test cases that were used to verify that
functional design requirements were met for that service. Many functional tests were
performed both with and without loads placed on the service components being
tested.
 Load testing phase: After functional testing, the lab team focused on load tests.
There were four distinct types of load tests that took place during this phase:
performance, scalability, stability, and integrated systems load tests. Within this
phase, the test sequence was generally to understand the performance behavior first,
then test the scalability of the design, and finally test the integration with all other
system components. Stability testing typically occurred at mixed points throughout,
often in conjunction with one of the other load test types.
 Security penetration testing phase: While load tests were running, the test team and
the Microsoft security teams conducted security penetration testing using publicly
available tools.
Test Cycle
The test team completed three complete test cycle passes following the sequencing outlined
above. Each test pass began with blank server computers. While all three test passes shared
common testing activities, each had its own additional unique testing themes that can be
explained as follows:
 The theme of the first test pass cycle was to validate service build guidance. A
strategy of building and testing service components in a layered approach was used;
the approach was to build and test the overall system in sections that consisted of
coherent sets of servers and services. Before moving on to additional sections, a
concentrated effort was made to resolve and regress any significant bugs. By
following this methodology, each subsequently added section was assured of a
stable foundation. Each 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 different 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 executing any test cases. This allowed a more integrated testing of the
updated build guidance.
 The third pass focused on regression testing and closing remaining bugs. In addition,
a final complete integrated systems test was performed.

Test Scope
WSSRA is a tested, validated, and documented collection of already released software and
hardware. Because of this, each individual component had already been subjected to
substantial product group and often field testing before being selected for use in WSSRA. It
was not within the scope of the test team to duplicate this testing. Rather, the key focus of
the test team was on validating WSSRA documentation and assuring clean component
integration between the various WSSRA components.
Since WSSRA is a starting point for enterprise application development, the test team made
no attempt to tune for performance or server balancing. There are many mutually exclusive
ways to enhance performance of any piece of the environment, so tuning should only occur
once the applications are known and initially implemented.
The Planning Guide provides detailed information on scalability of services. The test team
tested various loads to validate predicted behavior, although complete scalability testing of
products was left to individual product groups.
In-depth security penetration testing was only done at the operating system services and
network levels. There was no way to predict exactly what software or additional services
would be run in a particular instantiation of WSSRA in the field. Therefore, the test team
only performed this testing on the base services provided by following the build guidance.
Because line-of-business services are widely varied in their architecture, ultimate security
can only be achieved through rigorous programming practices, security auditing, and
penetration testing at the site of each WSSRA instantiation in the field.
Release Criteria for Testing

The primary release criterion for testing was closely tied to the severity of bugs that were
found during the testing phase. Testing continued until all bugs that would potentially
prevent the successful deployment of a WSSRA infrastructure were resolved and
subsequently verified by testing. The WSSRA documentation was only released after
successful correction of all significant documentation bugs that were discovered during the
documentation review. The specific criteria used were:
 No open bugs of severity 1 and 2.
 All documentation is free of comments or revision tracking
 All open bugs are triaged by the project team and their impacts on the solutions are
fully understood.
 Successfully pass all three test cycles.
 All external reviews are completed and any gaps resolved.
Pass/Fail Criteria for Test Cases

A test case was considered to have passed if the actual results matched the expected results
documented for the case. If the actual results did not match the expected results, the case
was marked failed and a bug was created.
If a test case failed, it was not assumed that the feature was necessarily defective. For
example, misinterpretation of project documentation, incomplete documentation, or
inaccurate documentation could cause failures. Each failure was analyzed to discover its
cause, based on actual results and the results described in project documentation. Further
pass criteria were as follows:
 All processes ran without unexpected errors.
 All processes finished in accordance with benchmarks defined in the functional
specification.
 Load tests showed that a satisfactory level of capacity was in place and that
appropriate steps could be taken to scale out the system when necessary.
Bug Severity Scale

The following table lists the guidelines used to assign bug severity. Bug severity was
measured on a scale of 1 to 4, where severity level 1 represented the highest severity and
level 4 represented the lowest.
Severity Description
1 Fatal Bug. System did not work. Significant parts of the system were
inoperable. There was no viable workaround.
2 Serious Bug. Primary business requirements could not be met with the
system. There were no easily apparent viable workarounds. Performance,
functionality, or usability was seriously degraded.
3 Normal Bug. Business requirements can be met with the system. Any needed
workarounds are apparent. Performance, functionality, or usability is not
seriously degraded.
4 Minor Bug. Minor typos, wish list suggestions, a “nice to have,” but not
required change. Would not affect release accuracy or usability in any
significant way.
Table 6. Bug Severity Scale
Test Lab Configuration

To test WSSRA architectural and design guidance, a subset of the full Contoso enterprise
was built that consisted of three logical groupings corresponding to Contoso’s Fairfield
headquarters, their large London office, and their small SBO in Pittsburg. The following
figure depicts these groupings (or scenarios).

Figure 4. Test Lab - Scenario Locations
The Fairfield location was built with all WSSRA services and design redundancies
incorporated. The London location, however, was a minimal subset of the Fairfield
deployment that allowed testing of site-to-site functionality, such as directory replication.
The London site of the test lab was not meant to host all services, only those that required
more than one site to adequately test. The Pittsburg location allowed testing of SBO
functionality, and as such contained no servers—only a firewall and test clients. Pittsburg
clients consumed services provided in the Fairfield location through VPN tunneling through
the Internet and site firewalls. Fairfield was represented in the naming convention used in
the lab as FFL, London as LON, and Pittsburg as PIT.
For a detailed breakdown of the network, SAN, servers and test clients configuration in this
environment, refer to the Test Lab Environment document in the Deployment Kit.
Integrated Environment Tests

The integrated environment or “Day-in-the-Life” testing was designed to emulate a typical
day’s activity and load for the Contoso test cases. The goals of the simulation were to
validate the integrated solution and reveal any issues not discovered in the testing of
individual services. At the end of the simulation, performance logs and event logs were
reviewed to identify any anomalies related to integration and stability. Normal operations
were validated by the data collected and reviewed.
For a detailed explanation of each element of this testing, see the Integrated Environment
Testing document in the Deployment Kit.
Test Tools
Applications that were used to stress test our scenarios included the following:
 Application Center Test (ACT): Was used to test the intranet and extranet Web tier
along with various Web application services.
 Nile 3.0: Was used in conjunction with ACT to test the intranet and extranet Web tier
along with various Web application services.
 Fitch and Mather Stocks: Fitch and Mather Stocks version 7.0 (also called FMStocks)
was used as the sample application for testing the .NET Framework technologies.
 Load Harness: This is a tool set that was developed and used by the test team for
load testing Active Directory and file services. It comprised modules such as
ADLogon and FileCopy.
 WSSRA-OLTP: The WSSRA-OLTP tool is used for generating load on the data
services in WSSRA.
 Mirror: This tool was used to facilitate security testing for our scenarios. Mirror
behaves like a generic service that opens a range of TCP and UDP ports and accepts
incoming connections.
 PrintStress: Version 2.0.9.0 of PrintStress was used to verify and stress test the print
services running in the test lab.
 Scanline: This tool is a command-line network and port scanning utility produced
by FoundStone. Version 1.01 was used in WSSRA to verify the correct settings for the
ACLs and for the per-server port lockdowns.
 Virtual Private Networking (VPN) Multi-port Client Simulator: This tool (R5K.exe)
is a client simulator utility that was used to create multiple client connections to test
VPN functionality under load. Version 1.0 of the tool was used.
Functional, load, and integration tests were all performed using these tools. For more
information, refer to the Test Tools document in the Deployment Kit.

Summary
This document provided an understanding of how the WSSRA documentation can be used
to help design and implement IT services based on the use of Windows Server System
products within the context of a real-world enterprise scenario. Reference Blueprints are
provided to help ensure that consistent architectural principles are applied and the breadth
of design considerations is understood. The reference materials are proven through lab build
out and rigorous testing to ensure desired functionality as well as non-functional needs such
as availability, security and scalability.
Working with our hardware and software partners is vital to ensure that full consideration is
given to all aspects of IT infrastructure and the whole process leads to a rich documentation
set covering the full IT lifecycle.
Using the WSSRA documentation and benefiting from the processes used, best practice
incorporated, and the proving we went through, can help drastically reduce the risk, cost,
and development time of a major infrastructure rollout within your organization. The
various documents form a modular documentation set that can be customized to meet the
requirements of many different types of organizations.
References
The WSSRA documentation has been designed to conform to technical and process best
practices in the IT industry. To this end, the guidance uses and complies with a number of
existing standards. It would be beneficial for the reader to be familiar with the MSF and
MOF standards to understand overall approach of WSSRA. Information on MSF and MOF is
available at the following URLs, respectively:
 www.microsoft.com/msf/
 www.microsoft.com/mof/
The WSSRA builds on the work of previous guidance that was released as Microsoft Systems
Architecture (MSA), which included the MSA Internet Data Center (IDC) and the MSA
Enterprise Data Center (EDC). For more information on these releases, refer to the following
URLs:
 www.microsoft.com/technet/itsolutions/idc
 www.microsoft.com/technet/itsolutions/edc
The WSSRA material can be found at:
www.microsoft.com/wssra

Appendixes
This section provides appendix information that is relevant to the WSSRA lab buildout.
Appendix 1.1—Security Zone Communications
This appendix provides details of the zone and tier communication that were used for the
CDC scenario in the test lab.
The following table details the ports to be allowed between a source zone or tier and
destination zone or tier and shows only the traffic initiated by the source. For example, a
client in the Public tier will initiate specific traffic to the Client VPN tier and the allowed
ports are shown from the initiator’s (Public) point of view. VPN tier does not initiate the
traffic because there is no entry for those ports with client VPN as the source.
If a zone is listed as the source or destination, all tiers in that zone can be expected to comply
with the port filters. The assumption here is to use zones by default unless the filtering
applies to a single tier only.
Usually, it is desirable to restrict port traffic between defined security zones where possible,
and map each security zone to a logical VLAN. The following table lists the source and
destination zones or tiers, which are specifically identified as such. In the case of a tier, a
network adapter may also be specified (/n).
Source Zone Destinat Port Protocol TCP/UDP Purpose

ion #
Zone
Internet Client Access
Public Perimete 80 HTTP TCP To allow Internet clients to
r access the Contoso public
Informati application and Web server
on content over non-encrypted
Services HTTP.
Public Perimete 443 HTTPS TCP To allow Internet clients to
r access the Contoso public
Informati Application and Web server
on content over encrypted HTTPS.
Services
Public Perimete 53 DNS UDP To allow Internet clients to look
r Name up the IP address of the
Services Contoso public Web servers
tier/1 through DNS requests.
Public VPN 500 ISAKMP UDP To allow the ISAKMP to build the
tier/1 secure tunnel for IPSec VPNs.
Public VPN 1701 L2TP UDP To allow public client
tier/1 workstations to securely
connect to the Contoso internal
network remotely over a VPN
using L2TP.
Public VPN 1723 PPTP TCP To allow public client
tier/1 workstations to securely
through PPTP using protocol
type 47 (GRE).
Public VPN 4500 MS IPSec UDP To allow public client
tier/1 NAT-T workstations to securely

ion #
Zone
network remotely over IPSec
through NAT.
Perimeter Access
Perimeter Web Perimete All All TCP/UDP No restrictions on traffic
tier/1 r between these external
Applicati interfaces.
on tier/1
Perimeter Perimete All All TCP/UDP No restrictions on traffic
Application r Web between these external
tier/1 tier/1 interfaces.
Perimeter Public 53 DNS UDP To allow DNS queries to be
Information initiated from the perimeter
Services application and Web servers to
public DNS servers.
Perimeter Public 53 DNS UDP To allow DNS queries to be
Name initiated from the perimeter
Services DNS servers to public DNS
servers.
Perimeter DNS Perimete All All TCP/UDP No restrictions on traffic
tier/2, r between these interfaces
Perimeter Web Applicati because they share the same
tier/2, on tier/2 VLAN.
Perimeter
Information
Infrastructure
Perimeter DNS Perimete All All TCP/UDP No restrictions on traffic
tier/2, r Web between these interfaces
Perimeter tier/2 because they share the same
Application VLAN.
tier/2,
Perimeter
Information
Infrastructure
Perimeter Web Perimete All All TCP/UDP No restrictions on traffic
tier/2, r DNS between these interfaces
Perimeter tier/2 because they share the same
Application VLAN.
tier/2,
Perimeter
Information
Infrastructure
Perimeter SQL 1433 SQL TCP/UDP To allow SQL traffic between the
Information tier/1 -34 perimeter tiers and the SQL
Services, tier.
Perimeter Web
Services
Perimeter SQL 1810 DTC TCP Distributed Transaction
Information tier/1 - Coordinator (DTC) statically
Services, 1815 defined ports to allow transit
Perimeter Web through intermediate firewall.
ion #
Zone
Services
Perimeter SQL Com - TCP/UDP Refer to Table 12 in the
Information tier/1 mon Network Architecture Blueprint
Services, proto for a list of commonly allowed
Perimeter Web col protocols.
Services set
Perimeter Internal 80 HTTP TCP To allow traffic between the
Information Applicati Contoso public application or
Services, ons tier/1 Web server and the internal
Perimeter Web application server over non-
Services encrypted HTTP.
Perimeter Internal 443 HTTPS TCP To allow traffic between the
Information Applicati Contoso public application or
Services, ons tier/1 Web server and the internal
Perimeter Web application server over
Services encrypted HTTPS.
Perimeter Internal 8100 Remoter TCP .NET remoter connection
Information Applicati allowing simple object access
Services, ons tier/1 protocol (SOAP) and XML
Perimeter Web between the corporate
Services application servers and the
public application servers.
Perimeter Internal 1810 DTC TCP DTC statically defined ports to
Information Applicati - allow transit through
Services, ons tier/1 1815 intermediate firewall.
Perimeter Web
Services
Perimeter Internal 80 HTTP TCP To allow traffic between the
Information Web Contoso public Application or
Services, tier/1 Web server and the internal
Perimeter Web Web server over non-encrypted
Services HTTP.
Perimeter Internal 443 HTTPS TCP To allow traffic between the
Information Web Contoso public application or
Services, tier/1 Web server and the Internal
Perimeter Web Web server over encrypted
Services HTTPS.
Perimeter Internal 8100 Remoter TCP .NET remoter connection
Information Web allowing SOAP and XML
Services, tier/1 between the corporate Web
Perimeter Web servers and the public
Services application or Web servers.
Perimeter Internal 1810 DTC TCP DTC statically defined ports to
Information Web - allow transit through
Services, tier/1 1815 intermediate firewall.
Perimeter Web
Services
Perimeter Corporat 119 NTP UDP To allow network time protocol
Information e (NTP) to transit between the
Infrastructure Infrastru perimeter directory tier to the
cture domain controller servers in the

ion #
Zone
corporate infrastructure zone.
This will allow time
synchronization to occur.
Perimeter Corporat 464 KPSSWD TCP To allow Kerberos traffic
Information e between the perimeter
Infrastructure Infrastru directory tier to the domain
cture controller servers in the
corporate infrastructure zone
for authenticated updates.
Perimeter Corporat 3268 Msft-GC TCP To allow global catalog updates
Information e between the perimeter
Infrastructure Infrastru directory tier to the domain
cture controller servers in the
corporate infrastructure zone.
Perimeter Corporat 5790 RPC TCP Statically defined ports for RPC
Information e 1– traffic through the intermediate
Infrastructure Infrastru 5790 firewall.
cture 5
Perimeter Internal Com TCP/UDP Refer to Table 12 in the
Directory Directory mon Network Architecture Blueprint
tier/1 tier/1 proto for a list of commonly allowed
col protocols.
set
Perimeter Internal 1812 RADIUS UDP RADIUS authentication traffic
Remote Access -13 for verifying credentials for VPN
Access tier/2 tier/1 tunnel.
Perimeter Branch 1723 PPTP TCP To allow the site-to-site VPN to
Remote Office, initiate the VPN tunnel as
Access tier/1 Public required to allow remote
branch office client
workstations to securely
type 47 (GRE). Note that this
VPN tunnel may be initiated by
either the branch office or the
site-to-site VPN and the tunnel
will only be authorized if the
remote site has a valid
authentication certificate.
Perimeter Branch 1701 L2TP UDP To allow the site-to-site VPN to
Remote Office, initiate the VPN tunnel as
Access tier/1 Public required to allow remote
using L2TP. Note that this VPN
tunnel may be initiated by
ion #
Zone
Perimeter Branch 4500 MS IPSec UDP To allow the site-to-site VPN to
Remote Office, NAT-T initiate the VPN tunnel to allow
Access tier/1 Public remote branch office client
through a NAT. Note that this
Perimeter Branch 500 ISAKMP UDP To allow the site-to-site VPN to
Remote Office, use ISAKMP to build the secure
Access tier/1 Public tunnel for IPSec VPNs. Note that
this VPN tunnel may be
initiated by either the branch
office or the site-to-site VPN.
Perimeter Corporat 3389 RDP TCP To allow administrators to
Management e remotely administer the
tier/1 Manage perimeter management servers
ment through Terminal Services or
Remote Desktop Connection.
Once logged in using Terminal
Services, the administrator can
connect to other Perimeter
servers directly attached to the
CPB VLAN.
Perimeter Corporat 80 HTTP TCP To allow HTTP traffic to traverse
Management e between the perimeter and
tier/1 Manage internal management servers
ment for intercommunication, such
as SOAP (see also port 8100).
Perimeter Corporat 443 HTTPS TCP To allow encrypted HTTPS traffic
Management e to traverse between the
tier/1 Manage perimeter and internal
ment management servers for server
configuration access.
Perimeter Corporat 1036 Unassign UDP To allow specific traffic to
Management e ed transit between the internal
tier/1 Manage registere servers and the management
ment d port servers. This undefined high
port is used by the
management software.
Perimeter Corporat 8400 Unassign TCP To allow backup software traffic
Backup tier/1 e -03 ed to flow between the internal
Manage registere backup servers and the
ment d ports perimeter backup servers. The
backup uses high range ports
to accomplish the transfer. The

ion #
Zone
defined ports are exclusive to
the perimeter backup scheme.
Internal Corporate Access
SQL Perimete 1433 SQL TCP/UDP To allow SQL traffic to flow
r -34 between the read-only SQL
Applicati Server computers and the
on tier/2 perimeter application servers
for content.
SQL Perimete 80 HTTP TCP To allow HTTP traffic to traverse
r between the read-only SQL
Applicati Server computers for
on tier/2 intercommunication, such as
SOAP (see also port 8100).
SQL Perimete 443 HTTPS TCP To allow encrypted HTTPS traffic
r to traverse between the
Applicati internal and external proxies for
on tier/2 server configuration access.
SQL Perimete 1810 DTC TCP DTC statically defined ports to
r - allow transit through
Applicati 1815 intermediate firewall.
on tier/2
SQL Perimete 8100 Remoter TCP .NET remoter connection
r allowing SOAP and XML
Applicati between the internal SQL
on tier/2 Server computers and the
SQL Perimete Com - TCP/UDP Refer to Table 12 in the
r mon Network Architecture Blueprint
Applicati proto for a list of commonly allowed
on tier/2 col protocols.
set
Corporate Internal 80 HTTP TCP To allow HTTP traffic to traverse
Web Services Applicati between the corporate Web
on tier/1 server and the application
servers for intercommunication,
such as SOAP (see also port
8100).
Corporate Internal 443 HTTPS TCP To allow encrypted HTTPS traffic
Web Services Applicati to traverse between corporate
on tier/1 Web server and the application
server for intercommunication.
Corporate Internal 1810 DTC TCP DTC statically defined ports to
Web Services Applicati - allow transit through
on tier/1 1815 intermediate firewall.
Corporate Internal 8100 Remoter TCP .NET remoter connection
Web Services Applicati allowing SOAP and XML
on tier/1 between the internal Web
servers and the internal
application servers.
Database, Applicati between the corporate servers
ion #
Zone
Corporate on tier/2 and the application servers for
Management, intercommunication, such as
Corporate SOAP (see also port 8100).
Infrastructure
Database, Applicati to traverse between corporate
Corporate on tier/2 servers and the application
Management, server for intercommunication.
Corporate
Infrastructure
Database, Applicati - allow transit through
Corporate on tier/2 1815 intermediate firewall.
Management,
Corporate
Infrastructure
Database, Applicati allowing SOAP and XML
Corporate on tier/2 between the corporate servers
Management, and the internal application
Corporate servers.
Infrastructure
Corporate Internal Com - TCP/UDP Refer to Table 12 in the
Database, Applicati mon Network Architecture Blueprint
Corporate on tier/2 proto for a list of commonly allowed
Management, col protocols.
Corporate set
Infrastructure
Corporate Perimete Stati DCOM TCP To allow DCOM traffic through
Infrastructure r c the firewall, specific ports must
tier/1 Applicati ports be specified for CA traffic. For
on, 1820 more details, refer to the
External - following URL:
Proxies 1825 www.microsoft.com/com/wpape
tier/2 r/dcomfw.asp
Corporate External 80, HTTP TCP To allow HTTP traffic to traverse
Infrastructure Proxies 8080 between the internal and
tier/1 tier/2 external proxy servers for
intercommunication, such as
Corporate External 443 HTTPS TCP To allow encrypted HTTPS traffic
Infrastructure Proxies to traverse between the
tier/1 tier/2 internal and external proxies for
server configuration access.
Corporate External 20- FTP TCP Allow FTP traffic between the
Infrastructure Proxies 21 internal and external proxies.
tier/1 tier/2
Corporate External 1863 MSNP TCP/UDP Allow Windows Messenger
Infrastructure Proxies traffic between the internal and
tier/1 tier/2 external proxies.
Corporate External Com - TCP/UDP Refer to Table 12 in the

ion #
Zone
Infrastructure Proxies mon Network Architecture Blueprint
tier/1 tier/2 proto for a list of commonly allowed
col protocols.
set
Corporate Perimete Com - TCP/UDP Refer to Table 12 in the
Infrastructure r mon Network Architecture Blueprint
tier/1 Applicati proto for a list of commonly allowed
on col protocols.
set
Corporate Perimete 80 HTTP TCP To allow HTTP traffic to traverse
Database, r Web between the corporate SQL and
Corporate tier/2 management servers and the
Management Web servers for
Corporate Perimete 443 HTTPS TCP To allow encrypted HTTPS traffic
Database, r Web to traverse between the
Corporate tier/2 corporate SQL and
Management management servers and the
Web servers for
intercommunication.
Database, r Web mon Network Architecture Blueprint
Corporate tier/2 proto for a list of commonly allowed
Management col protocols.
set
Internal Web between the corporate
Applications tier/1 Application servers and the
Internal Web server for
Internal Web to traverse between corporate
Applications tier/1 application servers and the
internal Web servers for
intercommunication.
Internal Web - allow transit through
Applications tier/1 1815 intermediate firewall.
Internal Web allowing SOAP and XML
Applications tier/1 between the corporate
applications servers and the
SOAP is an open standards-
based interoperability protocol
that uses XML to provide a
common messaging format to
link together applications and
services anywhere on the
Internet.
ion #
Zone
Internal SQL Internal 1433 SQL TCP/UDP To allow SQL traffic to the back-
Web -34 end interface of the internal
tier/2 Web server. This specific LAN
segment is isolated for
database traffic only to offload
the traffic from the front-end
LAN segment.
Internal SQL Internal 1433 SQL TCP/UDP To allow SQL traffic to the back-
Applicati -34 end interface of the Internal
ons tier/2 applications server. This
specific LAN segment is
isolated for database traffic
only to offload the traffic from
the front-end LAN segment.
Database, Web between the corporate servers
Corporate tier/2 and the internal Web server for
Management, intercommunication, such as
Corporate SOAP (see also port 8100).
Infrastructure
Database, Web to traverse between the
Corporate tier/2 corporate servers and the
Management, internal Web servers for
Corporate intercommunication.
Infrastructure
Database, Web - allow transit through
Corporate tier/2 1815 intermediate firewall.
Management,
Corporate
Infrastructure
Database, Web allowing SOAP and XML
Corporate tier/2 between the corporate servers
Management, and the internal Web server.
Corporate
Infrastructure
Database, Web mon Network Architecture Blueprint
Corporate set
Infrastructure
Corporate Perimete 8400 Unassign TCP/UDP To allow backup software traffic
Management r Backup -03 ed to flow between the internal
tier/1 registere backup servers and the
d ports perimeter backup servers. The
backup uses high range ports
to accomplish the transfer. The
defined ports are exclusive to
the perimeter backup scheme.

ion #
Zone
Management r Backup mon Network Architecture Blueprint
tier/1 proto for a list of commonly allowed
col protocols.
set
Corporate Internal 8600 Unassign TCP/UDP To allow backup software traffic
Database, Backup -99 ed to flow between the Internal
Corporate tier/1 registere servers and the Internal Backup
Infrastructure, d ports servers. The backup uses high
Corporate range ports to accomplish the
Internal transfer. The defined ports are
Applications, exclusive to the internal backup
Corporate scheme.
Web Services
Database, Backup mon Network Architecture Blueprint
Infrastructure, col protocols.
Corporate set
Internal
Applications,
Corporate
Web Services
Corporate Internal Stati DCOM TCP To allow certificate issue traffic
Internal Proxy c to flow between the internal
Applications, tier/1 ports certificate server and the
Corporate 1820 internal applications and Web
Web Services - servers. To allow DCOM traffic
1825 through the firewall, specific
ports must be specified for CA
traffic as per the Knowledge
Base article available at:
www.microsoft.com/com/wpape
r/dcomfw.asp
Corporate Internal Com TCP/UDP Refer to Table 12 in the
Internal Proxy mon Network Architecture Blueprint
Applications, tier/1 proto for a list of commonly allowed
Corporate col protocols.
Web Services set
Corporate Internal 1433 SQL TCP/UDP To allow SQL traffic between the
Infrastructure, SQL -34 internal SQL Server computers
Corporate tier/1 and the internal corporate
Management, servers.
Corporate
Internal
Applications,
Corporate
Web Services
Infrastructure, SQL mon Network Architecture Blueprint
Corporate set
ion #
Zone
Internal
Applications,
Corporate
Web Services
Database, Manage between the corporate servers
Corporate ment and the internal management
Infrastructure, tier/1 servers for intercommunication,
Corporate such as SOAP (see also port
Internal 8100) and basic configuration.
Applications,
Corporate
Web Services
Database, Manage to traverse between corporate
Corporate ment servers and the internal
Infrastructure, tier/1 management servers for
Corporate intercommunication.
Internal
Applications,
Corporate
Web Services
Corporate Internal 1036 Unassign UDP To allow specific traffic to
Database, Manage ed transit between the internal
Corporate ment registere servers and the management
Infrastructure, tier/1 d port servers. This undefined high
Corporate port is used by the
Internal management software.
Applications,
Corporate
Web Services
Database, Manage mon Network Architecture Blueprint
Corporate ment proto for a list of commonly allowed
Infrastructure, tier/1 col protocols.
Corporate set
Internal
Applications,
Corporate
Web Services
Corporate File and 515 Print UDP To support print spool traffic to
Database, Print spooler the print servers.
Corporate tier/1
Management,
Corporate
Internal
Applications,
Corporate
Web Services
Corporate File and 1709 Unassign UDP To allow specific file and print
Database, Print ed traffic to transit between the
Corporate tier/1 registere internal servers and the file and
Management, d port print servers.

ion #
Zone
Corporate
Internal
Applications,
Corporate
Web Services
Corporate File and Com - TCP/UDP Refer to Table 12 in the
Database, Print mon Network Architecture Blueprint
Corporate set
Internal
Applications,
Corporate
Web Services
Corporate VPN 1812 RADIUS UDP Return RADIUS authentication
Access tier/2 -13 traffic for verifying credentials
for VPN tunnel.
Corporate VPN Com - TCP/UDP Refer to Table 12 in the
Access tier/2 mon Network Architecture Blueprint
proto for a list of commonly allowed
col protocols.
set
Corporate External 20- FTP TCP Allow FTP traffic through the
Infrastructure Proxies 21 external proxy server to the
tier/2 Internet only when initiated
from internal corporate servers.
Corporate External 53 DNS TCP To allow DNS queries from
Infrastructure Proxies internal Corp servers through
tier/2 the external proxy server
outbound to the Internet.
Corporate External 80 HTTP TCP To allow HTTP traffic to traverse
Infrastructure Proxies between the corporate servers
tier/2 and the external proxy servers
for intercommunication, such
as SOAP (see also port 8100)
and basic configuration.
Corporate External 443 HTTPS TCP To allow encrypted HTTPS traffic
Infrastructure Proxies to traverse between corporate
tier/2 servers and the Internal
management servers for
intercommunication.
Corporate External Com - TCP/UDP Refer to Table 12 in the
Infrastructure Proxies mon Network Architecture Blueprint
col protocols.
set
Internal Client Access
Client Internal 80 HTTP TCP To allow HTTP traffic to traverse
Applicati between the clients and the
on tier/1 Internal application servers for
intercommunication.
ion #
Zone
Client Internal 443 HTTPS TCP To allow encrypted HTTPS traffic
Applicati to traverse between clients and
on tier/1 the internal application servers
for intercommunication.
Client Internal 1810 DTC TCP DTC statically defined ports to
Applicati - allow transit through
on tier/1 1815 intermediate firewall.
Client Internal 8100 Remoter TCP .NET remoter connection
Applicati allowing SOAP and XML
on tier/1 between the clients and the
internal application servers.
Client Internal Com - TCP/UDP Refer to Table 12 in the
Applicati mon Network Architecture Blueprint
on tier/1 proto for a list of commonly allowed
col protocols.
set
Client Internal 80 HTTP TCP To allow non-encrypted HTTP
Web traffic to traverse between the
tier/1 clients and the internal
application servers for
intercommunication.
Web to traverse between clients and
tier/1 the internal application servers
for intercommunication.
Web - allow transit through
tier/1 1815 intermediate firewall.
Client Internal 8100 Remoter TCP .NET remoter connection
Web allowing SOAP and XML
tier/1 between the clients and the
internal application servers.
Web mon Network Architecture Blueprint
col protocols.
set
Client Internal 1433 SQL TCP/UDP To allow SQL traffic between the
SQL -34 internal SQL Server computers
tier/1 and the clients.
SQL - allow transit through
tier/1 1815 intermediate firewall.
SQL mon Network Architecture Blueprint
col protocols.
set
Client Internal 67- DHCP UDP To allow a client (local or
Directory 68 remote) to acquire a DHCP
tier/1 lease address.

ion #
Zone
Directory mon Network Architecture Blueprint
col protocols.
set
Client Perimete 80 HTTP TCP To allow HTTP traffic to traverse
r between the clients and the
Manage perimeter management servers
ment for intercommunication.
tier/1
Client Perimete 443 HTTPS TCP To allow encrypted HTTPS traffic
r to traverse between clients and
Manage the perimeter management
ment servers for intercommunication.
tier/1
Client Perimete 1036 Unassign UDP To allow specific traffic to
r ed transit between the clients and
Manage registere the management servers. This
ment d port undefined high port is used by
tier/1 the management software.
Client Perimete Com - TCP/UDP Refer to Table 12 in the
r mon Network Architecture Blueprint
Manage proto for a list of commonly allowed
ment col protocols.
tier/1 set
Manage between the clients and the
ment internal management servers
tier/1 for intercommunication.
Manage to traverse between clients and
ment the internal management
tier/1 servers for intercommunication.
Client Internal 1036 Unassign UDP To allow specific traffic to
Manage ed transit between the clients and
ment registere the management servers. This
tier/1 d port undefined high port is used by
the management software.
Manage mon Network Architecture Blueprint
ment proto for a list of commonly allowed
tier/1 col protocols.
set
Client File and 515 Print UDP To support print spool traffic to
Print spooler the print servers.
tier/1
Client File and 1709 Unassign UDP To allow specific file and print
Print ed traffic to transit between the
tier/1 registere clients and the file and print
d port servers.
Client File and Com - TCP/UDP Refer to Table 12 in the
ion #
Zone
Print mon Network Architecture Blueprint
col protocols.
set
Client Internal 20- FTP TCP Allow FTP traffic through the
Proxy 21 proxy server only when
tier/1 initiated from internal clients.
Proxy between the clients and the
tier/1 external proxy servers for
intercommunication.
Proxy to traverse between clients and
tier/1 the external proxy servers for
intercommunication.
Client Internal 1863 MSNP TCP/UDP Allow Windows Messenger
Proxy traffic between the clients and
tier/1 the internal proxies.
Client Internal Stati DCOM TCP To allow certificate issue traffic
Proxy c to flow between the internal
tier/1 ports certificate server and the
1820 clients. To allow DCOM traffic
- through the firewall, specific
1825 ports must be specified for CA
traffic as per the Knowledge
Base article available at:
www.microsoft.com/com/wpape
r/dcomfw.asp
Proxy mon Network Architecture Blueprint
col protocols.
set
Branch Office VPN 1723 TCP To allow the branch office to
tier/1 initiate the VPN tunnel as
required to allow remote
type 47 (GRE). Note that this
Branch Office VPN 1701 UDP To allow the branch office to

ion #
Zone
using L2TP. Note that this VPN
tunnel may be initiated by
through a NAT. Note that this
tier/1 use ISAKMP to build the secure
tunnel for IPSec VPNs. Note that
this VPN tunnel may be
initiated by either the branch
office or the site-to-site VPN.
Table 1. Zone and Tier Communications for the CDC Scenario
Note: Messaging services zone configurations are included in the Messaging Services
Planning Guide and the Messaging Services Build Guide.
Appendix 1.2—Network Architecture Tier
Definitions
This appendix provides the detailed information on the tier definitions that were used for
the CDC scenario in the test lab.
Tier Tier Services Member of Load- Load-Balancing

Description and Hosts Security Balancing Functional
It Contains Zone Technique Requirements
Firewall (un- External Firewall Border Determinis High availability
trusted) interface on servers Public tic
the Border
Firewall
between the
Public and
Border Public
zone
Firewall (un- Internal Firewall Border Round High availability
trusted) interface of servers Public Robin
the Border (internal)
Firewall
between the
Border Public
and
Perimeter
Information
Services and
Perimeter
Name
Services
zone
Firewall Border Firewall Border Determinis High availability
(Semi- Firewall services on Public tic
trusted) between the VPN servers
Public and
Perimeter
Remote
Access zone
Firewall Border Firewall Border N/A None
(Semi- Firewall services on Public
trusted) between the proxy
Public and servers
Perimeter
Proxy
Services
zone
Perimeter Application Application Perimeter Least Session persistence;
Application servers for servers Information connected High availability
public access Services
Perimeter Web services Web servers Perimeter Least Source IP/SS/URL
Web available to Web connected persistence, SSL
the public Services termination/offloadi
ng, downstream
service availability
awareness

Perimeter DNS services DNS servers Perimeter Least High availability
DNS available to Name connected
the public for Services
queries
Perimeter Domain Domain Perimeter Application None at network
Directory Controller Controller Information specific layer; Active
and Infrastructu Directory provides
Directory re inherent load
services balancing when
available for queried, as part of
the public the Active Directory
architecture
Perimeter Backup Backup Perimeter N/A None
Backup services servers Information
available for Infrastructu
the public re
Perimeter Management Managemen Perimeter N/A None
Management services t servers Information
available for Infrastructu
the public re
External Proxy and Proxy Perimeter Round High availability;
Proxies recursive services on Proxy Robin Session persistence
DNS services proxy Service
for outbound servers
client traffic
VPN VPN services VPN services Perimeter Determinis High availability
for client and on VPN Remote tic
site-to-site servers Services
connections
Internal SQL Microsoft Database Private SQL N/A None*
SQL Server servers
for internal
clients
SQL Microsoft Database Corporate Fastest High availability
SQL Server servers Database
for Perimeter
and Internal
access
Internal Active Domain Corporate N/A None at network
Directory Directory for controllers Infrastructu layer; Active
internal use re Directory provides
inherent load
balancing when
queried as part of
the Active Directory
architecture
Internal IAS services IAS servers Corporate N/A None
Access for RADIUS Access
authenticatio
n on VPN
clients
Internal Proxy Proxy/CA Corporate Round High availability;
Proxy services for servers Infrastructu Robin Session persistence
internal use re
File and Print File and Print File and Corporate N/A None *
services for Print servers Infrastructu
internal use re
Internal DNS and DNS/WINS Corporate Determinis High availability
Name WINS servers Infrastructu tic
Services services for re
internal
name
resolution
Internal Backup Backup Corporate N/A None*
Backup services for servers Manageme
internal use nt
Internal Management Network and Corporate N/A None
Management services for Applications Manageme
internal use Managemen nt
t servers;
Deployment
servers
Internal Application Application Corporate Least Session persistence;
Applications services for servers Internal connected High availability
internal use Application
s
Internal Web Web services Web servers Corporate Least Source IP/SS/URL
for internal Web connected persistence, SSL
use Services termination/offloadi
ng, downstream
service availability
awareness
Branch Corporate Desktops, Branch N/A None
Office remote laptops Office
offices
Client Client access Desktops, Client N/A None
devices laptops
Table 1. Tier Definitions for Contoso
*Note: These servers are clustered for failover and not for load balancing; therefore, they
have no impact on the network design. If multiple server hosts need to be clustered
together to present themselves as one host to the network, the service administrator should
specify the type of load balancing required.

Appendix 1.3—Network Segment Definitions for
the CDC
This appendix provides a detailed explanation of the segments created as part of the CDC
network architectural design process.
Segm Purpose Physical Destinatio Reason for Creation

ent ID or n
Logical Segments
S1 Connectivi Physical. S2, S8, and To make policy routing and multihomed ISP
ty This S9 connectivity flexible, a border router device is
connecti preferred in this location. Security between
on is the Public and Perimeter zones will be
from the enforced with a device that provides the
Internet Perimeter Firewall Services role and the
to a application-layer proxy firewall function and
Contoso that device also protects S2 from the Public
edge zone. Segments S8 and S9 are connected
device, directly to this border router but the host
so a services on these segments (proxy and VPN)
physical are hardened. This solution offered higher
segment performance and enabled the organization to
is plan for growth by adding more segments on
necessar the device performing the Border Routing role.
y.
S2 Connectivi Logical. S1 and S3 To allow traffic to flow from the device that
ty and The performs the Border Routing role to the device
Security connecti that performs the Perimeter Firewall Services
on is role. It is a highly secure device that protects
between the Perimeter zone from unauthorized traffic
two from the Public zone and blocks any outbound
devices connection initiated by the Perimeter hosts.
that The Contoso enterprise security policy
Contoso mandated that the physical device that
owns. It performed the Perimeter Firewall Services role
is also performs the function of application-layer
required proxy firewall to control traffic between the
to Public and Private security zones.
minimize
the
number
of
devices
to be
managed
in the
enterpris
e.
S3 Connectivi Logical S1 and S9 To allow traffic to flow from the device that
ty and performs the Border Routing role to the device
Security that performs the Perimeter Firewall Services
role for the external VPN and proxy servers.
This firewall service is a logical service
running on the VPN and proxy servers.
Inbound traffic is restricted to replies to
conversations initiated by the Perimeter or
ent ID or n
Logical Segments
Internal zones conversations, or to secure VPN
tunnel traffic from trusted authenticated
sources. Outbound traffic can be sourced from
Internal Client or Corporate zones.
S4 Connectivi Logical S2, S5, S6, To allow traffic to flow from the device
ty and and S7 performing the Perimeter Firewall Services
Security role to the Perimeter DNS, Perimeter
Application, and Perimeter Web tiers through
the device that performs the Perimeter
Switching role. The organization’s security
policy mandated that the device that performs
the Internal Switching role must be physically
separate from the device that performs the
Perimeter Switching role.
S5 Security Logical S4, S6, and To allow the flow of traffic between the device
S12 that performs the Perimeter Firewall Services
role and the Perimeter Application tier
(allowing public access to the tier).
To allow traffic to flow between the Perimeter
Web tier and the Perimeter Application tier.
To allow devices in the Perimeter Management
tier to connect to the servers in the Perimeter
Application tier to remotely administer them.
S6 Security Logical S4, S5, and To allow traffic to flow between the device
S12 that performs the Perimeter Firewall Services
role and the Perimeter Web tier (allowing
Public access to the tier).
To allow traffic to flow between the Perimeter
Web tier and the Perimeter Application tier.
Web tier to remotely administer them.
S7 Security Logical S4 and S12 To allow traffic to flow between the device
that performs the Perimeter Firewall Services
role and the Perimeter DNS tier (allowing a
Public access to the tier).
DNS tier to remotely administer them.
S8 Security Logical S12 and To allow traffic to flow between Perimeter
or S14 Information Infrastructure zone and the
Connectivi Internal Firewall device; the filters allow
ty specific traffic to flow to the Perimeter
Application, Web, and DNS tiers for directory
services, backups, and management.
Restricted communication is required between
the Perimeter Information Infrastructure zone
and specific devices in the Internal zone,
which are handled by the Internal Firewall
device.
S9 Security Logical S3, S10, To allow outbound traffic to flow from the

ent ID or n
Logical Segments
S11, and Client zone to the Public zone.
S13 To allow inbound traffic from the Public zone
(authorized by a certificate) for VPN tunnel
creation and initiate communication to the
Internal Access zone.
To provide for client and site-to-site VPN
connectivity.
To allow traffic initiated from the Internal
Proxy tier. No inbound initiated
communication is allowed from the Public
zone.
S10 Security Logical S9 and S13 To allow traffic to flow from internal Client
or zone to the Perimeter Proxy Services zone
Connectivi (outbound initiated only).
ty To allow traffic to flow between the internal
clients and the tiers in the Corporate
Database, Corporate Infrastructure, Corporate
Internal Applications, and Corporate Web
Services zones.
S11 Security Logical S9 and S13 To allow traffic to flow from Internal Branch
or Office zone (connected through a VPN secure
connectivi tunnel) to the Perimeter Proxy Services zone
ty (outbound initiated only).
To allow traffic to flow between the Internal
Clients and the tiers in the Corporate
Database, Corporate Infrastructure, Corporate
Internal Applications, and Corporate Web
Services zones. Note that this segment is a
virtual segment; the branch offices are
connected physically through the CDC WAN
but are connected logically through the VPN
tunnel as a semi-trusted client, which provides
for the most reasonable connection.
S12 Connectivi Logical S5, S6, S7, To allow traffic to flow between the device
ty S8, and that performs the Perimeter Public Switching
S14 role and the device that performs the Internal
Firewall Services role. All servers in the
Perimeter DNS and Perimeter Web tiers route
traffic through the device that performs the
Perimeter Routing and Switching role if they
need to communicate with systems in the
Corporate zone. This segment also allows
inter-zone traffic between the Perimeter
services through the Perimeter Switching role.
S13 Connectivi Logical S9, S10, To allow traffic to flow between the device
ty S11, and that performs the Perimeter semi-trusted
S14 Switching role and the device that performs
the Internal Firewall Services role. All client
and branch office traffic to corporate services
as well as corporate communication to the
Perimeter Proxy Services and Remote Access
zones will transit this segment.
ent ID or n
Logical Segments
The Contoso enterprise security policy
mandated that a device that performs at least
the function of stateful packet inspection
firewall control network traffic between the
Perimeter and Internal Zones. In addition, it
mandated that the device that performs the
Internal Firewall Services role be a dedicated
device for this purpose and is physically
Perimeter Firewall Services role.
ty S15, S16, performing the Internal Firewall Services role
S17, S18, and the device that performs the Internal
and S19 Switching role. This will include traffic
between the Perimeter and the Internal zones.
Note that the Contoso enterprise security
policy mandated that the device that performs
the Internal Switching role must be physically
Perimeter Switching function.
ty S18, and that performs the Internal Switching role and
S19 the tiers in the Corporate Database zone. This
segment services two zones - Corporate
Database and Private SQL. It is a single VLAN
that has services that require single host-
based security filters.
S16 Security Logical S14, S15, To allow traffic to flow between the device
or S17, S18, that performs the Internal Switching role and
Connectivi and S19 the Corporate Management zone.
ty
S17 Security Logical S14, S15, To allow traffic to flow between the device
or S16, S18, that performs the Internal Switching role and
Connectivi and S19 the Corporate Infrastructure zone. This
ty segment carries the typical client traffic to
this zone and carries the certification and
authentication traffic for the Perimeter
Remote Access zone. This segment services
two zones-Corporate Infrastructure and
Corporate Access. It is a single VLAN that has
services that require single host-based
security filters.
S18 Security Logical. S14, S15, To allow traffic to flow between the device
or The S16, S17, that performs the Internal Switching role and
Connectivi connecti and S19 the Corporate Internal Applications zone.
ty on is
between
two
devices
that
Contoso
owns. It
is

ent ID or n
Logical Segments
required
to
minimize
the
number
of
devices
to be
managed
in the
enterpris
e.
S19 Security Logical. S14, S15, To allow traffic to flow between the device
or The S16, S17, that performs the Internal Switching role and
Connectivi connecti and S18 the Corporate Web Services zone.
ty on is
between
two
devices
that
Contoso
owns. It
is
required
to
minimize
the
number
of
devices
to be
managed
in the
enterpris
e.
Table 1. Network Segmentation Information for the CDC Scenario
Appendix 1.4—Address Allocation Information
for the CDC
This appendix provides details of the segments created as part of the CDC network
architecture.
Network Public or Why Was the Choice Made?

Segment Private
#
S1 Public Border router needs to be accessible by a public address for
Internet connectivity.
S2 Public Border public firewall should be accessible by a public address
and attached to the border router.
S3 Public Border semi-trusted firewall needs to be accessible by a public
address and attached to the border router.
S4 Private No direct routing to the Internet was necessary for these devices
because they connect to the Internet through a NAT device
(firewall). Private addressing was sufficient.
S5 Private Private segment was needed without direct public addressability.
S9 Private No direct routing to the Internet was necessary for these devices
because they connect to the Internet through a NAT device
(firewall). Private addressing was sufficient.
S15 Private Private segment was needed with out direct public
addressability.
Table 1. Address Allocation Information for the CDC Scenario

Appendix 1.5— Build Sequence Details
This appendix provides the detailed task sequence that was used to build the CDC and SBO
scenarios in the test lab. To create the task sequence, the project team needed to achieve a
comprehensive understanding of all tasks involved in the process. Microsoft Project® was
used to organize this information, and the Project output file (BuildOrder.mpp) is included in
the Deployment Kit. Use this document file to graphically display the dependencies and show
which tasks can be done in parallel and which must be completed in a serial fashion. Use the
Network Diagram view in Project for the best visual display of the sequencing and to
quickly see the critical path.
*Note: The messaging services were built as a layered service using the WSSRA
architecture. The build sequence is detailed separately and specifically in the Messaging
Services Build Guide.
The table in this appendix was derived from the BuildOrder.mpp document and describes
textually the build sequence for the services. It is organized according to the build guide that
contains the tasks to be executed and in order. Document names are bolded to make them
easier to identify.
The Task column contains the task section titles from within each build guide. In some cases,
the Task element indicates a range of sections. For example, in the "DHCP" section in the
Network Services Build Guide, one Task element contains "Installing DHCP Services through
Activating Scopes." You should execute all task sections inclusive between "Installing DHCP
Services" and "Activating Scopes."
Some Task elements are a single section name, and it is possible that the task section contains
multiple subsections. For example, the "Build the Deployment Server" section in the
Deployment Services Build Guide contains several task subsections that describe how to build
the deployment server. You should execute all task subsections that are contained within a
main task section. This also applies to ranges of sections where the boundaries may have
task subsections.
The Predecessor and Successor columns contain the Task IDs that either precede or follow
the current task. Before executing a task, you must ensure that its entire list of Predecessor
task IDs has been completed. The Successor task IDs help identify the tasks that can be
performed after the current task. When there are multiple Successor task IDs, it indicates
that the successor tasks can be performed in parallel.
The first few tasks in the table are milestone tasks and have no build steps. They are there to
help define key points during the build process.
To get started, locate the "Start" task and then begin executing its Successor tasks in parallel.
ID Task Predecessor Successor

1 Start 7, 26, 4, 8, 11, 15, 20
2 Finish 99, 118
3 BLD Network Devices.doc
4 CDC Build - 1 5, 50
Configuring Cisco
Systems Equipment
5 SBO Build - Setting 4
Up and Configuring
the SBO Router
6 BLD Computing Devices.doc
7 Unpack and 1 29
Inventory the
Hardware
through
Configuring Remote
Insight Lights-Out
Edition (RILOE) Card
and Integrated
Lights-Out (iLO)
8 Unisys ES7000 1 31
Computer
Configuration
9 BLD Storage Devices.doc
10 Brocade SAN Devices
11 Cabling the SAN 1 12
Fabrics
through
Setting a Switch
Domain ID
12 Setting a Secure 11, 51 13, 16
Administrator
Password on the
SilkWorm 3800
through
Verifying ISL
Trunking is Available
13 Verifying the Devices 12, 38, 66, 70, 74,
are Attached 93
14 HP SAN Storage Devices
15 Obtaining Required 1 16
Information from
Configuration Matrix
through
Configuring the IP
Address on the SAN
Appliance
16 Configuring the HP 12, 15, 51 17
Enterprise Virtual
Array (EVA) Storage
System
through
Installing Business
Copy on the SAN
Appliance

17 Joining the SAN 16, 62 18
Appliance to the
Domain
18 Setting Up the 17 38, 66, 70, 74, 93
Secure Path Server
Profile on the SAN
Appliance
19 EMC SAN Storage Devices
20 Obtain Required 1 21
Information from
Configuration Matrix
through
Preparing a
Computer to Access
Navisphere Manager
21 Accessing 20, 51 22
Navisphere Manager
through
Assigning Clone
Private LUNs
22 Installing the HBA 21, 73 23, 74
Driver
through
Installing the
Navisphere Agent
and CLI
23 Assigning Storage to 22 24
Hosts
24 Ensuring Drives 23
Appear in Device
Manager
through
Preparing Shared
Storage for Clusters
25 BLD Deployment Services.doc
26 Collect Software 1 29
Materials
27 Prepare the Deployment Environment
28 Configure the 51 30
Network for
Deployment
29 Build the 7, 26 30
Deployment Server
through
Building the Boot
Media
30 Create the SysPrep 28, 29 31
Disk Images
31 Installing Base 8, 30 32
Operating System on
Servers
32 Post-Base Operating 31 46, 54, 62, 103
System Build
Procedures
33 BLD Network Services.doc
34 DNS
35 Configuring NIC 62 39, 97, 101, 117
Teaming
through
Moving Servers to
the Domain
Organizational Unit
36 DHCP
37 Configuring NIC 62 38
Teaming
through
Installing and
Configuring Cluster
Services
38 Configuring SAN 18, 37 13, 39
Connectivity
39 Installing DHCP 35, 38 40, 42, 97
Services
through
Activating Scopes
40 SBO: Configuring 39
Scopes for the
Satellite Branch
Office
through
Activating Scopes
41 WINS
Teaming
through
Building WINS
Clustered Resource
43 Building Member 42 97
WINS Servers
through
Moving Servers to
the Domain
Organizational Unit
44 BLD Firewall Services.doc
45 CDC Build Tasks-Perimeter Firewalls

46 Pre-installation 32 47
Configuration
47 Installing ISA Server 46 48
for Firewalls
48 ISA Server Post- 47
Installation
Configuration
49 CDC Build Tasks-Interior Firewalls
50 Setting the Firewall 4 51
Module to the
Default State
51 Setting the Primary 50 12, 16, 21, 28
and Secondary
Configuration
Commands
52 Proxy/Cache
53 CDC Build Tasks-External Proxy Servers
54 Preinstallation 32 55
Configuration
for External Proxy
Servers
Installation
Configuration
57 CDC Build Tasks-Internal Proxy Servers
58 Preinstallation 62 59
Configuration
for Internal Proxy
Servers
Installation
Configuration
61 BLD Directory Service.doc
62 Configuring NIC 32 17, 35, 37, 58, 65, 69,
Teaming 73, 82, 87, 92, 98, 101,
through 109, 114, 117, 120
Configuring
Delegation for
ContosoCorp
Organizational Units
63 BLD File & Print Services.doc
64 File Service
65 Verifying the 62 66
Network Cabling and
File System
Configuration
through
Joining the Computer
to the Domain
Connectivity
67 Installing and 66
Configuring Cluster
Services
through
Moving Servers to
the Domain
Organizational Unit
68 Print Service
69 Verifying the 62 70
Network Cabling and
File System
Configuration
through
to the Domain
Connectivity
71 Installing and 70 97
Configuring Cluster
Services
through
Moving Servers to
the Domain
Organizational Unit
72 BLD Data Services.doc
73 Configuring and 62 22, 74
Naming the Base
Network Connection
through
Creating Database
Services Groups and
Permissions
74 Configuring HBA 18, 22, 73 13, 75, 78
Cards
through
Configuring SAN
Drives
75 Configuring Service 74 76, 77, 79
Accounts in the
Organizational Unit
through
Configuring the
BackEnd VLAN
76 Installing SQL 75 80
Server 2000 failover

clustering
77 Installing Read Only 75 80
SQL Server 2000
Load Balanced
Cluster
78 Installing SQL 74 80, 94
Server 2000
Maintenance Servers
79 Installing SQL 75 80
Server 2000 on
Unisys ES7000
80 Moving Servers to 76,77,78,79
the Domain
Organizational Unit
81 BLD Web Application Services.doc
82 Active Directory 62 83
Tasks
83 System Tasks 82 84
84 Installing IIS 6 83 85
85 Additional 84 97, 101, 104, 107, 110,
Configuration Steps 115
86 BLD Infrastructure Management Services.doc
87 Configuring NIC 62 88, 89
Teaming
through
to the Domain
88 Internal Tools 87 97, 101, 104
Servers
through
Creating the
Definitive Software
Library (DSL)
89 Perimeter Tools 87 90
Servers
90 Moving Servers to 89
the Domain
Organizational Unit
91 BLD Backup & Recovery.doc
Teaming
through
to the Domain
93 Configuring 18, 92 13, 94
Connectivity to the
SAN
94 Verify Connectivity 78, 93 95
to the Tape Devices
through
Enabling Remote
Desktop to the
CommServe
Computer
95 Installing the 94 96
CommServe
Software
96 Installing the 95 97, 98
MediaAgent
Software
97 Installing the 35, 39, 43, 71, 85, 99
idataAgent Software 88, 96, 111, 122
98 Installing the Active 62, 96 99
Directory idataAgent
Software
99 Moving Servers to 97, 98 2
Domain
Organizational Unit
through
Verifying Firewall
Port Security
100 BLD Certificate Services.doc
101 General 35, 62, 88, 85 109, 112
102 Root CA
103 Root CA: Verifying 32 104, 106
Workgroup
Membership
through
Root CA: Copying
the CRL to
Removable Media
104 Root CA: Publishing 85, 88, 103
the CA Certificate
and CRL to An
Internal Facing Web
Server
through
Root CA: Publishing
a Root CA Certificate
in Active Directory
Manually
105 Intermediate CA
106 Intermediate CA: 103 107, 109
Verifying Workgroup
Membership
through
Intermediate CA:

Copying the CA CRL
to Removable Media
107 Intermediate CA: 85, 106
Publishing a CA
Certificate and CRL
to An Internal Facing
Web Server
through
Intermediate CA:
Publishing a CA
Certificate and CRL
to An External Facing
Web Server
108 Issuing CA
109 Issuing CA: 62, 101, 106 110
Configuring Network
Adapters and IP
Addresses
through
Issuing CA: Post
Configuration Tasks
110 Issuing CA: Verifying 85, 109 111
the CA Configuration
through
Issuing CA: Enforcing
Role Separation
111 Issuing CA: 110 97, 117, 125
Publishing the CA
Certificate
through
Issuing CA: Enabling
Certificate
Autoenrollment
112 Configuring 101
Certificate Authority
Service Permissions
113 SBO Build Tasks
114 General 62 115
115 CA for Router 85, 114
Certificates
116 BLD Remote Access Services.doc
117 Configuring NIC 35, 62, 111 118
Teaming
through
Applying the
Override Security
Template
118 SBO Build Tasks: 117 2
Create IPSEC policy
for Site-to-Site
Communications
through
Configuring the SBO
router for IPSEC
119 BLD Middleware Services.doc
120 Active Directory 62 121
Tasks
121 System Tasks 120 122
122 Configuring a Server 121 97, 124
to be an Application
Server
123 Additional Configuration Tasks
124 Verifying Network 122 125
DTC Access
through
Moving Servers to
the Domain
Organizational Unit
125 Certificate Tasks 111, 124
Table 1. WSSRA Build Sequence
*Note: The build sequence for the messaging services was conducted separately from the
foundational WSSRA services and is based on sequential tasks for the individual messaging
service components found throughout the Messaging Services Build Guide.

Lab Implementation

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Lab Implementation

Hochgeladen von

Copyright:

Verfügbare Formate

Windows Server System

Published: July 2005

Windows Server System™ Reference Architecture (WSSRA) delivers architectural guidance on

Who Should Read This Document

2Windows Server System Reference Architecture

4Windows Server System Reference Architecture

Table 1. WSSRA Services List

Figure 1. Network Design Overview Legend

6Windows Server System Reference Architecture

Code Meaning Description

Table 2. Naming Standards

Code Location Office Type Office Size

8Windows Server System Reference Architecture

Table 3. Location Codes and Offices

Table 4. Domain Codes

10Windows Server System Reference Architecture

Table 5. Function Codes

12Windows Server System Reference Architecture

Configure and Secure the Network

Configure the Devices

14Windows Server System Reference Architecture

Deploy the Operating System

Build the Foundational Infrastructure Services

Build the Remaining Services

16Windows Server System Reference Architecture

Building the Environment Sequentially

18Windows Server System Reference Architecture

20Windows Server System Reference Architecture

22Windows Server System Reference Architecture

24Windows Server System Reference Architecture

26Windows Server System Reference Architecture

Release Criteria for Testing

Pass/Fail Criteria for Test Cases

Bug Severity Scale

Table 6. Bug Severity Scale

Test Lab Configuration

28Windows Server System Reference Architecture

Integrated Environment Tests

30Windows Server System Reference Architecture

32Windows Server System Reference Architecture

Source Zone Destinat Port Protocol TCP/UDP Purpose

34Windows Server System Reference Architecture

36Windows Server System Reference Architecture

38Windows Server System Reference Architecture

40Windows Server System Reference Architecture

42Windows Server System Reference Architecture

44Windows Server System Reference Architecture

46Windows Server System Reference Architecture

48Windows Server System Reference Architecture

Table 1. Zone and Tier Communications for the CDC Scenario

Tier Tier Services Member of Load- Load-Balancing

50Windows Server System Reference Architecture

Table 1. Tier Definitions for Contoso

52Windows Server System Reference Architecture

Segm Purpose Physical Destinatio Reason for Creation

54Windows Server System Reference Architecture

56Windows Server System Reference Architecture

Table 1. Network Segmentation Information for the CDC Scenario

Network Public or Why Was the Choice Made?

Table 1. Address Allocation Information for the CDC Scenario

58Windows Server System Reference Architecture

ID Task Predecessor Successor

60Windows Server System Reference Architecture

62Windows Server System Reference Architecture