Review of Microsoft’s Windows Server System Reference Architecture

In late April of this year the Windows Server System Reference Architecture (WSSRA) became available for download from the Microsoft Download Center. This set of documentation and tools however has been under development for over a year however, and evolved from the earlier Microsoft Systems Architecture for Windows 2000 Server. What is WSSRA about and is it useful in the enterprise? That’s what this review is about.

Overview of WSSRA

WSSRA is basically a collection of documents and some tools that are designed to provide enterprises with what they need to quickly and easily plan, deploy, and manage enterprise IT networks. The expectation of WSSRA is that these networks will mainly be Microsoft-centric, for example having Active Directory on the back end and a preponderance of Windows clients on the desktop. However, WSSRA realistically acknowledge that such networks will be heterogeneous in nature and also include UNIX/Linux servers or mainframes on the server end and UNIX or Macintosh computers on some desktops.

What exactly is in the WSSRA? If you download the full 40 MB package from the Microsoft Download Center (as opposed to individual components, which is another option) then you end up after you unzip the package with the following:

  • Some overview documents describing what WSSRA is about, why it was developed, who it’s targeted at, and how it was developed.
  • Some architecture blueprints, which provide general planning and deployment recommendations in the areas of designing network, storage, management, security, and application infrastructures for your enterprise.
  • A set of implementation guides with planning and deployment recommendations on specific aspects of your IT infrastructure including computing devices, network devices, storage devices network services, directory services, file and print services, data services, web application services, firewall services, certificate services, remote access services, backup and recovery, infrastructure management, and middleware.
  • Miscellaneous tools described further below under Deployment Kit.

Sounds like a lot, so let’s look at the various pieces more closely.

Architecture Blueprints

The idea behind these blueprints is that they cover design issues that affect multiple services on your network, and that you should therefore address these issues before you plan how to implement specific network services. For example, before you design an implementation for data (database) services, you need to plan how your network will support such services, what storage requirements are needed and how they will be implemented, how your data will be secured and managed, and so on.

I read through a couple of these architecture blueprints and while I was basically satisfied with the amount of information provided and the level of depth covered, I was right away struck by the fact that these blueprints are not really prescriptive in nature. This becomes clear when you consider how many different options are discussed for addressing specific network issues. For example, in the Network Architecture blueprint, two options are presented for designing the segmentation of your network: physical segments and VLANs. Each of these two options is briefly described and then the advantages and disadvantages of each approach is described. That’s it, the rest (decision-making, design details and how to implement) is left up to you, the network architect. Although this approach is reasonable because of the different security needs, management resources, and budget of different companies, I find it hard to really consider this a “blueprint” for network design.

As another example of this, the Management Architecture blueprint lists four different approaches to ensuring high availability for your enterprise:

  • Design Option 1: Not Fully Redundant Services
  • Design Option 2: Fully Redundant Services
  • Design Option 3: Redundant Operations Centers
  • Design Option 4: Redundant Services and Operations Centers

Again, each option is briefly described and its pros and cons are weighed. And of course, the best solution for a particular company will depend on a number of factors including cost, resources, and business model. At best however, these blueprints are merely providing you with information that can help you begin thinking about the issues and problems involved in each approach, and you’ll still have to do the remaining 90% of your homework if you really want to make the best design decision for your company.

Implementation Guides

I really expected the meat of WSSRA to be found in the dozen or so implementation guides, and while this is so, there’s often more bones than meat. Take the guide for implementing file and print services for example. This guide (like the others) consists of five documents:

  • Introduction to File and Print Services, 8 pages of overview material. This can pretty much be skipped or skimmed through quickly.
  • File and Print Services Blueprint, 96 pages covering different DFS design options, different file storage server options, and background information. This is perhaps the most useful part of the guide as it gives you information to think about. But you’ve still got to do a lot of reading about DFS and testing also before you even begin to think about performing your DFS deployment.
  • File and Print Services Planning Guide, 36 pages of file and print services scenarios based on fictitious companies like Comtoso and Wingtip Toys, two fictitious companies that Microsoft often uses in its training kits. This information is useful but somewhat limited in scope.
  • File and Print Services Build Guide, 114 pages describing the exact steps used to create the file and print services scenarios discussed previously. While this might seem useful at first, the procedures are often covered in so much detail that it becomes easy to miss the forest because of the trees. And remember, the procedures describe the tasks needed to implement file and print services for a fictitious company, not your own.
  • File and Print Services Operations Guide. This was the biggest disappointment because it doesn’t seem to exist yet! After telling us that the File and Print Services Operations Guide is in four sections and providing us with a link to where we can obtain it, a small note in fine print (missed on my first reading) indicates “At the time of publishing, this operations guide has not been released. When available, details will be available at the above URL.” Not really much help.

Deployment Kit

This zipped package contains Visio network diagrams, scripts, registry files, Excel worksheets and other job aids, router config files, security templates (.inf files), IPSec policy files in Netsh syntax, load testing tools, and a Bill of Materials spreadsheet describing all the equipment (routers, servers, SANs, software, etc.) used in creating the test environment that formed the basis of the scenarios described in WSSRA. Most of this stuff is specific to the scenarios used and may not be easy to customize to meet the needs of your own enterprise. But it does underline the basic meaning of what WSSRA really means when it talks about “blueprints” and that is that WSSRA gives you a detailed blueprint on how to create a fictitious enterprise called Comtoso that has 50 locations worldwide, 30 sites outside the USA, and 30,000 employees with one third of them spread across 14 different countries. Comtoso also has extranet and Internet connectivity needs to partners and customers respectively, and while it mainly uses Windows Server 2003 it does also have some UNIX servers and IBM mainframes, but naturally the company is “learning towards replacing UNIX serves with Windows operating system servers in a drive for standardization providing cost reduction and the opportunity to consolidate servers and services” (quoted from one of the overview documents in WSSRA). 


WSSRA is really nothing more than a big (several thousand page) training kit that demonstrates how to design and implement various kinds of large-scale enterprise-level networks. There’s nothing wrong with that of course, and in reading through parts of WSSRA I did learn lots of valuable things including how to design an enterprise-level naming scheme for network devices and services, how to segment an enterprise network into different security zones during the planning stage and why this is important, some different ways of using DFS for deploying file services in a globe-spanning environment, and so on. And if you’re an enterprise network architect then WSSRA does a nice job of showing you how to design an enterprise network from the ground up, though I doubt if many could afford the hardware needed to recreate Comtoso themselves and follow along the steps outlined in the different Build Guides. Still, it’s worth taking a look at WSSRA if you haven’t done so—I’m certainly going to continue plowing through it—especially if you’re company is considering growth or expansion and wants to do it in a way that ensures availability, supports scalability, maintains security, and is easy to manage and use. Finally, be sure to keep an eye on my blog as I’ll be blogging different tidbits of information gleaned from WSSRA in it over the next while, saving you time in case you don’t have the opportunity to read through WSSRA yourself.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top