Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server

A Reference for Designing Servers and Peripherals for the
Microsoft® Windows® 2000 Server Family of Operating Systems

Intel Corporation and Microsoft Corporation
Publication Date—June 30, 2000

The information contained in this document represents the current view of Intel Corporation and Microsoft Corporation on the issues discussed as of the date of publication. Because Intel and Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Intel and Microsoft, and Intel and Microsoft cannot guarantee the accuracy of any information presented. This document is for informational purposes only. INTEL AND MICROSOFT MAKE NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Intel Corporation and Microsoft Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property rights.

Intel and Microsoft do not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Intel and Microsoft disclaim all express and implied warranties, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, and freedom from infringement. Without limiting the generality of the foregoing, Intel and Microsoft do not make any warranty of any kind that any item developed based on these specifications, or any portion of a specification, will not infringe any copyright, patent, trade secret, or other intellectual property right of any person or entity in any country. It is your responsibility to seek licenses for such intellectual property rights where appropriate. Intel and Microsoft shall not be liable for any damages arising out of or in connection with the use of these specifications, including liability for lost profit, business interruption, or any other damages whatsoever.

BackOffice, DirectShow, DirectX, Microsoft, MS-DOS, NetShow, Win32, Win64, Windows, Windows NT, and the Windows logo are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Intel and Pentium are registered trademarks, and Intel486, Itanium, MMX, and Xeon are trademarks of Intel Corporation.

Other product and company names herein may be the trademarks of their respective owners.

© 1997–2000 Intel Corporation and Microsoft Corporation. All rights reserved.

This document is not for sale.
Review copies are provided to individuals who register by completing the reviewer request form at http://www.microsoft.com/hwdev/serverdg.htm.
To obtain additional copies of this final version of this document, please download the source files from the web sites at http://developer.intel.com/design/servers/desguide/index.htm or http://www.microsoft.com/hwdev/serverdg.htm.


Welcome

Hardware Design Guide Version 3.0 for Windows 2000 Server is for engineers who build server systems, expansion cards, and peripheral devices that use the Microsoft® Windows® 2000 Server (and later) operating system.

This guide is co-authored by Intel Corporation and Microsoft Corporation. The requirements and recommendations in this guide indicate features that the hardware industry should consider in designing servers and peripherals for various price levels and performance levels.

This guide includes design guidelines for servers that will run any version of the Windows 2000 Server or later operating systems, including the next release of Windows, code-named Windows "Whistler." These guidelines address the following design issues:

  • Features for basic commodity server design alternatives for small office/home office (SOHO) and Enterprise servers.
  • Requirements for implementing the OnNow design initiative, including those related to the Advanced Configuration and Power Interface (ACPI) specification, Plug and Play device configuration, and power management in server systems.
  • Implementation of devices supported under Windows 2000 Server.
  • Manageability features that help to reduce total cost of ownership (TCO) under Windows 2000 Server by providing support for maximum automation of administrative tasks with centralized control and maximum flexibility.

Important: Implementing these guidelines results in servers that deliver an enhanced user experience with the Windows 2000 Server or later family of operating systems. These requirements are not related to the minimum, most-optimal, or best system requirements for running any version of the Windows 2000 Server operating systems. For information about the minimum system requirements for running Windows 2000 Server, see http://www.microsoft.com/windows2000/guide/server/sysreq/.

Back to top Back to top


Broadening of Coverage for Large Systems

In previous versions of Hardware Design Guide for Microsoft Windows NT Server, the guide encompassed the "standard high volume" server with up to and including four processors in a symmetric multiprocessing configuration. However, systems with up to eight processors are now shipping from many vendors. Due to this broadening of the "standard high volume" server market, systems with up to eight processors are now included in the servers that are covered by the Hardware Design Guide Version 3.0.

As previously stated, there is no "one to one" mapping of the number of processors in a server to a specific server "class" or "usage model" (for example, one could certainly have a "SOHO Server" with more than one processor); however, in general, it is anticipated that most servers with four or more processors will be most likely viewed as designed to the "Enterprise Server" system considerations.


Future Technology Directions

The "standard high volume" server is evolving rapidly to meet the pace of customer expectations for ever-increasing reliability, availability, serviceability, scalability, usability, and manageability. These increasing customer expectations for the "-abilities" on industry-standard servers mean that future versions of the Hardware Design Guide for servers must address ever more complex topics.

This section of the document is meant to provide some vision into what those future directions might be and to invite feedback from the industry on these topics. Feedback is also requested for any other issues and topics that should be addressed in the quest for servers that can achieve the highest possible levels of uptime and functionality for any particular segment of server usage. (It is recognized that the balance of cost against features is also an important part of this analysis.)

Some of topic areas that are seen as future work areas for the Hardware Design Guide for servers include:

  • ACPI 2.0 and its facilitation of capabilities such as "hot plug" of processors, memory, and I/O subsystems, as well as system partitioning.
  • System capabilities to isolate failing components at boot time. The concept of "fault domains," both at system startup and, where possible, at run time.
  • Future advancements in I/O bus technologies and architectures. Much exciting work is ongoing in the realm of I/O bus technologies. Future design guides will undoubtedly provide specific requirements and recommendations for each technology area. However, early implementers and adopters of all new bus technologies must comply with all relevant bus specifications, including bus and device power management specifications, for each specific technology as they become available. Additionally, for servers running a Windows 2000 Server family operating system, new bus technologies and devices must comply with the relevant general-case guidelines for devices and drivers as articulated in the Hardware Design Guide for servers.
  • Enhancements to support for Fibre Channel in Windows operating systems. As Fibre Channel adoption continues to grow, Microsoft is seeking feedback and input from the industry on the enhancements needed to best support this storage channel in Windows 2000 operating systems. Guidelines relating to use of any enhanced Fibre Channel capabilities in Windows operating systems will appear in future versions of the Hardware Design Guide for servers.
  • Use of flash memory as an "emergency boot/recovery" file system. With the advent of the Windows 2000 Recovery Console, system designers may want to consider providing an area of flash memory as an alternate boot device for use with the Recovery Console as an emergency recovery aid. The Recovery Console provides secure local access to Windows 2000 installations on a specific system, and is NTFS-aware, eliminating the need for Microsoft MS-DOS® as a system maintenance or recovery tool.
  • "Multi-pathing" for storage and network connections. As part of the efforts to increase platform reliability and availability, eliminating single points of failure wherever possible is extremely valuable. Two areas of future opportunity are allowing "multiple paths" to storage and network connections from servers. Future versions of the Hardware Design Guide for servers will provide guidelines on how to implement these capabilities with future Windows operating systems.
  • Advanced usage and support of the Windows 2000 "NMI crash dump capture" capability. A clarification to guideline "#222. IA-32 system includes protected forced dump switch or other mechanism for system diagnosis" provides some detailed information on the Windows 2000 capabilities to capture crash dump information on nonmaskable interrupts (NMI).

One way to take advantage of this feature is in "hung system" debugging where a crash capture is triggered via a switch that produces an NMI signal—the technique called out in the guideline previously cited. However, this capability can also be tied to other platform health monitoring capabilities as well.

Some possible areas where this feature could be further leveraged would be in the case where a platform health "watchdog" timer was present. If a watchdog circuit and associated platform management determine that the host platform was in a hung state, the watchdog circuit could, as part of the recovery process, ensure that an NMI was asserted to cause a system dump prior to resetting or restarting the system. This process would be a part of root cause analysis support.

Increasingly sophisticated uses of this feature with various forms of remote platform management can also be envisioned; one example might be allowing this feature to be available to system administrators monitoring platform health via remote out-of-band management connections.

Other future areas of growth include support for a similar type of capability on 64-bit platforms.

  • Enhanced platform health monitoring capabilities. Customers also have increasing expectations in the area of platform health monitoring—both in terms of monitoring the status of the platform and of its physical "health," such as internal temperatures, chassis intrusion, fan status, predictive failure analysis, and so on. With the Windows Management Instrumentation (WMI) infrastructure in the Windows family of operating systems, providing such enhanced platform health and monitoring capabilities is made simpler. Future versions of the design guide will continue to enhance requirements and recommendations in these areas.
  • Run-time diagnostics capabilities. Another core WMI capability is the ability to flag data as "expensive" to collect, which provides a simple mechanism to allow run-time diagnostic capabilities. Future versions of the Hardware Design Guide for servers may have additional requirements and recommendations as to the use of these capabilities for enhanced platform self-diagnosis and system health monitoring.
  • Enhancements to "remote management" capabilities. As industry standard servers running Windows family of operating systems increase their penetration to many more environments with high reliability and availability requirements, customer demands and expectations are increasing for remote management and manageability of these systems.

Certain key capabilities that are being addressed in this version of the Hardware Design Guide for servers, and that will likely be enhanced in future versions, include requirements for "headless" (that is, without a local display, keyboard, or pointing device) operations. Some of the concerns that will need to be addressed to fully support headless operation include:

  • Remote "power on" and reboot capabilities
  • Redirection of pre-operating system firmware displays, such as a pre-operating system BIOS boot or setup screen
  • Remoteable screen displays for system startup, normal operation, and crash/error recovery
  • Fully-remoteable access to platform management data while the operating system is running, as well as while it is not

As with all of these technology areas, feedback and input from the industry on directions in these areas are actively requested for future Hardware Design Guides for servers.

Other future areas of growth include support for a similar type of capability on Intel Architecture (IA)-64 platforms.

  • EFI on IA-32 systems. Extensible Firmware Interface (EFI) is a requirement for IA-64 systems, but there is interest from many in the server industry in using EFI as a choice for the firmware model on IA-32 platforms as well. Future versions of the Hardware Design Guide are likely to address requirements for IA-32 systems that wish to use EFI with Windows.
  • Emergence of new server segments. As servers based on industry-standard technologies continue to be deployed more broadly and in support of new tasks, new server designs are emerging. Some of the considerations for these new segments include form factor, consolidation of field-replaceable units, and general physical design issues. Some of these new segments may diverge in some of their serviceability/availability requirements from the standard high volume servers currently addressed by the Hardware Design Guide. Intel and Microsoft welcome and invite input from the industry on the new server segments, and on issues that are pertinent for their design and may need to be considered in future versions of the Hardware Design Guide.


Legacy Reduction and Removal

The PC platform that is part of the heritage of today’s server systems has evolved by adding and retaining technologies. As a result, the evolution and "history" cycle for many technologies imposes a burden that impacts cost, performance, and support—particularly in the server marketplace where PC legacy items reduce the advantages brought by newer technologies. These legacy technologies are present in hardware, firmware, BIOS code, and operating systems.

The Hardware Design Guide for Windows 2000 Server continues to address the transition to newer technologies with the introduction of alternatives to serial port based debug for IA-32 platforms, Universal Serial Bus (USB), and other technologies.. In the future, more guidelines will be published to facilitate the continuing migration of older technologies out of the server platform. Intel and Microsoft welcome and invite input from the industry on legacy reduction in servers, and on issues that may need to be considered in future versions of the Hardware Design Guide.


How to Use This Guide

Read the first chapter for an overview, and read Chapters 2 and 3 to gain an understanding of the overall system requirements. Study the other chapters to understand details about specific device classes and issues for server hardware.

Chapter | Contents
Chapter 1: Overview of Server Design Issues | Presents overview of server classes and design issues.
Chapter 2: System Component Requirements | Presents general system requirements.
Chapter 3: Bus and Device Requirements | Presents general bus and device requirements for server systems.
Chapter 4: Networking and Communications Requirements | Defines basic feature requirements for network adapters and other related communications hardware.
Chapter 5: Storage Device Requirements | Defines requirements for controllers, hard drives, tape drives, CD drives, and related devices.
Chapter 6: Physical Design and Hardware Security Requirements | Defines requirements for physical design and hardware security, such as requirements for connectors, case and component locks, and so on.
Chapter 7: Reliability, Availability, and Serviceability Requirements | Provides design guidelines related to ease of use and ease of maintenance issues.
Appendix A: Server Requirements Checklist | Provides a summary checklist of requirements defined in these guidelines.
Glossary | Defines technical terms and acronyms related to hardware and Windows operating systems.

As co-authors of this design guide, Intel and Microsoft provide clarification and interpretation of the requirements and recommendations in this document. Please send questions or requests for clarification by e-mail to:

designguide@intel.com
serverdg@microsoft.com


Conventions Used in This Guide

The following conventional terms, symbols, abbreviations, and acronyms are used throughout this guide. In addition, see the Glossary later in this guide.

Conventional Terms

Add-on devices

Devices that are traditionally added to the base server system to increase functionality, such as audio, networking, graphics, and so on. Add-on devices fall into two categories: devices built onto the system board set and devices on expansion cards added to the system through a system-board connector such as Peripheral Component Interconnect (PCI).

Intel Architecture, IA-64, and IA-32

Refers to computers based on 64-bit and 32-bit microprocessors that use the Intel Architecture instruction set, such as Intel Pentium, Intel Pentium with MMX technology, Pentium Pro, Pentium II, Pentium II Xeon, Pentium III, Pentium III Xeon, Itanium, or compatible processors.

System devices

Also on-board devices. Refers to devices on the system board set such as interrupt controllers, keyboard controller, real-time clock, direct memory access (DMA) page registers, DMA controllers, memory controllers, floppy disk controller (FDC), AT-Attachment (ATA) ports, serial and parallel ports, PCI bridges, and so on. In today’s servers, these devices are typically integrated with the supporting chipset.

Windows 2000 or Windows 2000 Server

Refers to the Microsoft Windows 2000 Server, Windows 2000 Advanced Server, and Windows 2000 Datacenter operating system, including any add-on capabilities and any later versions of these operating systems.

The following describes the product name changes for operating systems based on Windows NT® technology offered after Windows NT 4.0.

Old | New
Windows NT | Windows 2000
Windows NT Server | Windows 2000 Server
Windows NT Server, Enterprise Edition | Windows 2000 Advanced Server
(no equivalent) | Windows 2000 Datacenter Server

For a list of acronyms and definitions of technical terms, see the Glossary later in this guide.


Required vs. Recommended Features in This Guide

The system requirements defined in this publication provide guidelines for design.ing servers that deliver an enhanced user experience when implemented with Windows 2000 Server. These design requirements are not the basic system requirements for running the Windows 2000 Server operating system. In this guide, hardware features are described as Required, Recommended, or Optional as follows:

  • Required. These basic hardware features must be implemented in order for hardware to qualify as being in compliance with Hardware Design Guide Version 3.0 for Windows 2000 Server requirements.
  • Recommended. These features add functionality supported by the Windows 2000 operating system. Recommended features take advantage of the native capabilities of hardware device drivers included with the operating system, usually without imposing major cost increases.

Notice that for compliance testing, if a recommended feature is implemented, it must meet the requirements for that feature that are defined in this guide. Some recommended features could become requirements in the future.

  • Optional. These features are neither required nor recommended, but if the feature is implemented in a system, it must meet the specified requirements to be in compliance with these guidelines. These features are not likely to become requirements in the future.

In this guide, the following terms are used in regard to the requirements:

  • Must: Required
  • Should: Recommended

Note: It is recognized that original equipment manufacturers (OEMs) supply systems with specific feature requirements to corporations, where customers integrate the desired solution on site. For example, a customer could specify a minimum configuration without disk drives.

Systems designed for specific corporate customers are exempt from related minimum requirements defined in this guide. Such exemptions are noted in this document. However, for compliance testing of these requirements, the system must include at least the minimum required components.


Requirements by Server Class and Operating System Product

Requirements for four different Windows 2000 operating system products and three server classes are designated in these guidelines. The operating system products include:

  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server and Microsoft Windows 2000 Datacenter Server
  • Microsoft Small Business Server (formerly known as Microsoft BackOffice® Small Business Server)

The server classes in this guide are the same as in Hardware Design Guide Version 2.0: Basic Server, Enterprise Server, and SOHO Server. (For more information, see Chapter 1, "Overview of Server Design Issues.") For ease of use in this guide, Basic, SOHO, and Enterprise class requirements are all defined together in the main body of the document, rather than in separate chapters.

Any class of server can run any server operating system product. Furthermore, there are no direct relationships that define which operating system product can or should run on each specific class of server. However, server platforms might need to meet additional requirements to meet the goals of a specific server class or to be a good target platform for a specific operating system.

The following examples show the format for differentiating server class-specific or operating system-specific requirements in this guideline. The first example is the simplest, where the requirement (or recommendation) applies to all classes of servers and all operating systems.

Ex.1. System and components support dates beyond 2000
Required
The BIOS, real time clock, CMOS, and the system as a whole must work correctly for dates from now to past the year 2000.

The second, more complex example presents specific requirements for different server classes and operating system products. The server types are defined in the left column, and the column headings designate specific operating system products.

Ex. 2. System includes intelligent RAID controller
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
SOHO: | Optional | Required | Optional
Enterprise: | Required | Required | Required
An intelligent Redundant Array of Independent Disks (RAID) controller provides the benefit of reduced demands on the host processor or processors….


References and Resources

The following represents some of the information resources, services, and tools available to help build hardware optimized to meet the requirements defined in this guide. This section also lists technical references for the specifications cited in this guide.

Hardware Design Guide Compliance and Testing Programs

A specific hardware model is compatible with Windows 2000 if it has a Windows 2000 device driver designed to interact with that hardware model, and if Windows 2000 and that driver interoperate with the hardware in a stable manner.

Hardware Compatibility Tests (HCTs). Microsoft evaluates hardware compatibility using the Windows 2000 HCTs, which are run to test the interaction between device drivers and hardware. These tests issue the full range of commands available to applications and operating system software, and they stress hardware beyond the level of most real-world situations. The Windows 2000 HCT team runs the tests and reports results to the manufacturer. You can obtain a Windows 2000 HCT kit from the Windows Hardware Quality Labs (WHQL) web site at http://www.microsoft.com/hwtest/testkits/

Hardware Compatibility List (HCL). Hardware that passes the HCTs is eligible to be included on the Windows 2000 HCL, available to customers by way of the World Wide Web and other sources. The HCL helps interested parties identify hardware and software that has been verified to run on Windows 2000 Server.

WHQL administers the hardware compliance testing programs at Microsoft. Hardware developers whose products pass the WHQL testing program receive a detailed report about how the system runs Windows 2000 Server based on the results of the testing. Hardware that passes testing is included on the Windows HCL at http://www.microsoft.com/hcl/.

Compliance Dates. Typically, these hardware design requirements go into effect on July 1, 2001, and are applicable to servers that are designed and built after this document’s initial publication date. Compliance testing for some requirements may begin later because of the time required for technology changes to become widely available. For information about actual compliance testing dates for specific requirements, or about any of the hardware testing programs at Microsoft, contact WHQL:

Windows Hardware Quality Labs Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399 USA

http://www.microsoft.com/hwtest/
E-mail: whqlinfo@microsoft.com
Fax: (425) 703-3872


Information Resources and Technical References

Server Design Information from Intel and Microsoft

Information from Intel. Additional information relating to server hardware design is available from Intel Corporation at:

http://www.intel.com/ebusiness/server/resources/index.htm
http://developer.intel.com/platforms/enterprise/
E-mail: designguide@intel.com

Information from Microsoft. Additional information about related hardware design guide issues and Windows 2000 Server hardware is available from the Microsoft web sites at:

http://www.microsoft.com/hwdev/
http://www.microsoft.com/Windows2000/guide/server/
E-mail: serverdg@microsoft.com

Information Resources

Common Information Model (CIM)

http://www.dmtf.org/work/cim.html

Distributed Management Task Force (DMTF)

http://www.dmtf.org

Intel developer information

http://developer.intel.com

Microsoft hardware developer information

http://www.microsoft.com/hwdev/

Microsoft Developer Network (MSDN) Professional membership

http://msdn.microsoft.com/subscriptions/

Microsoft Windows Hardware Quality Labs

http://www.microsoft.com/hwtest/

Technical References

1394 Open Host Controller Interface Specification, Release 1.1

http://www.microsoft.com/hwdev/1394/download/ohci_11.zip
http://developer.intel.com/technology/1394/download/ohci_11.htm

1999 Version of National ISDN Basic Rate Interface Terminal Equipment Generic Guidelines, Document Number SR-4620

http://www.telcordia.com/

Advanced Configuration and Power Interface Specification, Version 1.0b

http://www.teleport.com/~acpi/
Version 2.0 will also be published here when released

ANSI NCITS T10 Multi-Media Command Set-2
ATA/ATAPI-5 Standard
ATA Packet Interface for CD-ROM, SFF 8020i
Other SFF publications

Global Engineering Documents
http://global.ihs.com/

ATAPI Removable Media BIOS Specification (ARMD)

http://www.ptltd.com/techs/specs.html

ATM User-Network Interface Specification, Version 3.1

Prentice Hall, 1995; ISBN 0-13-393828-X
http://www.atmforum.com/atmforum/specs/approved.html

Boot Integrity Services (BIS) API, Version 1.0

http://developer.intel.com/ial/wfm/wfmspecs.htm

Compaq, Intel, Phoenix BIOS Boot Specification, Version 1.01
(CIP BIOS Boot 1.01)

http://www.ptltd.com/techs/specs.html

Data-Over-Cable Service Interface Specification (DOCSIS)

http://livelink.cablelabs.com/Livelink/livelink.exe?func=ll&objId=49623&objAction=browse&sort=name
http://www.cablelabs.com/

Debug Port Specification

http://www.microsoft.com/hwdev/NewPC/debugspec.htm

Desktop Management Interface Specification, Version 2.0
DMI Compliance Guidelines, Version 1.0

http://www.dmtf.org/tech/specs.html

Device Class Power Management Specifications

http://www.microsoft.com/hwdev/specs/PMref/

DSL Architecture: An Interoperable End-to-End Broadband Service Architecture over ADSL System

http://www.microsoft.com/hwdev/network/dsl/

DVD Specification, Version 1.0, Toshiba Corporation.

http://global.ihs.com

El Torito — Bootable CD-ROM Format Specification, Version 1.0

http://www.ptltd.com/techs/specs.html

EPS Power Supply: A Server System Infrastructure (SSI) Specification for Entry Chassis Power Supplies

http://www.ssiforum.org/docs/entrylevelpowersupply.pdf

European Telecommunications Standards Institute (ETSI) or Global System for Mobile (GSM) standards

Phone: +33-92 94 42 00
FAX: +33-93 65 47 16
E-mail: secretariat@etsi.fr

Extensible Firmware Interface Specifications

http://developer.intel.com/technology/efi/download.htm
http://www.microsoft.com/hwdev/efi/

Extensions to VT100 Terminal Definition

To be published at http://www.microsoft.com/hwdev/headless/

Fibre Channel Physical (FC-PH), Revision 4.3

http://www.fibrechannel.com

I2O (Intelligent I/O) Architecture Specification, Version 1.5

http://www.intel.com/design/iio/i2osig.htm
http://www.i2osig.org (special interest group)

IBM Personal System/2 Common Interfaces, Part No. S84F-9809
IBM Personal System/2 Mouse Technical Reference, Part No. S68X-2229

International Business Machines Corporation
IBM Customer Publications Support: (800) 879-2755
Or contact an IBM sales representative

IEEE 1394 Standards

http://standards.ieee.org/catalog/

InfiniBand Trade Association

http://www.sysio.org

Interoperability Specification for ICCs and Personal Computer Systems

http://www.pcscworkgroup.com/

ITU Communications Standards

Phone: (41) (22) 730-6141
Fax: (41) (22) 730-5194
E-mail: sales@itu.ch
http://www.itu.ch

Legacy Plug and Play Guidelines

http://www.pcdesguide.org/legacypnp/

MCNS Documents

http://www.cablemodem.org

Media Status Support Notification, Version 1.03

http://www.microsoft.com/hwdev/respec/storspec.htm

Microsoft Extensible Firmware Interface FAT32 File System Specification,
Microsoft Extensible Firmware Interface Long File Name Specification,
Microsoft Portable Executable and Common Object File Format Specification,
plus other EFI-related specifications and guidelines

http://www.microsoft.com/hwdev/efi/

Microsoft Platform SDK, including Win32® and Win64™ APIs

http://msdn.microsoft.com/downloads/sdks/platform/platform.asp
Also provided through MSDN Professional subscription

Microsoft Windows 2000 Driver Development Kit (DDK)

http://www.microsoft.com/ddk/
Also provided through MSDN Professional subscription

Microsoft Windows Hardware Compatibility List (HCL)

http://www.microsoft.com/hcl/

MMC-2 Multi-Media Command Set-2 standard

ftp://ftp.t10.org/t10/drafts/mmc2/mmc2r11a.pdf

MultiProcessor Specification, Version 1.4

http://developer.intel.com/design/intarch/MANUALS/242016.htm

NCITS Reduced Block Commands Standard

http://www.ncits.org/standards/standards.htm

OnNow and ACPI implementation guidelines under Windows operating systems

http://www.microsoft.com/hwdev/onnow/

Open Host Controller Interface (OpenHCI) Specification for USB, published by Compaq, Microsoft, and National Semiconductor

http://www.microsoft.com/hwdev/respec/busspecs.htm

OSTA MultiRead Specification for CD-ROM, CD-R, CD-R/RW, and DVD-ROM Devices, Version 1.11

http://www.osta.org/html/mrspec.html

PCI Bus Power Management Interface Specification, Revision 1.1
PCI Hot-Plug Specification, Revision 1.0
PCI Local Bus Specification, Revision 2.2 (PCI 2.2)
PCI to PCI Bridge Specification, Revision 1.1
PCI-X Addendum to the PCI Local Bus Specification, Revision 1.0

http://www.pcisig.com/members/
http://www.pcisig.com/tech/availspecs.html

Plug and Play specifications

http://www.microsoft.com/hwdev/respec/pnpspecs.htm

Preboot Execution Environment (PXE) Specification, Version 2.1

http://developer.intel.com/ial/wfm/wfmspecs.htm

RS-IA-64 System Abstraction Layer (SAL) Specification, Revision 2.7

http://developer.intel.com/design/ia-64/downloads/245359.htm

Serial Port Console Redirection Table

To be published at http://www.microsoft.com/hwdev/headless/

Simple Boot Flag Specification, Version 1.0

http://www.microsoft.com/hwdev/desinit/simp_bios.htm

System Management BIOS Reference Specification, Version 2.3

http://www.phoenix.com/products/specs-smbios.pdf

Unimodem Diagnostics Command Reference Specification—Draft

http://www.microsoft.com/hwdev/respec/commspec.htm

Universal HCI (UHCI) Specification, published by Intel

http://developer.intel.com/design/usb/

Universal Serial Bus, Version 1.1 or later
Universal Serial Bus PC Legacy Compatibility Specification, Version 0.9
USB Device Class Definition for Mass Storage Devices and other USB device class specifications

http://www.usb.org/developers/docs.html

Universal Disk Format Specification, Version 1.5 and 2.0

http://www.osta.org

Web-Based Enterprise Management (WBEM) information

http://www.dmtf.org/

Windows Hardware Instrumentation Implementation Guidelines, Version 1.0

http://www.pcdesguide.org/whiig.htm

Windows Management Instrumentation (WMI) and Win32 Extensions schema

http://msdn.microsoft.com/downloads/sdks/wmi/
http://www.microsoft.com/hwdev/wmi/

Windows NT Removable Storage Manager Programming Documentation

http://msdn.microsoft.com/library/psdk/zaw/proguide_912q.htm

Wired for Management Baseline Specification
Version 2.0

http://developer.intel.com/ial/wfm/


Acknowledgments

Microsoft and Intel would like to acknowledge the special contributions of the following companies to this document:

Compaq Computer Corporation
Dell Computer Corporation
Fujitsu Siemens Computers
Hewlett-Packard Company
International Business Machines Corporation
NEC Corporation


Chapter 1 Overview of Server Design Issues

This chapter is an introduction to the system classes and issues related to server hardware guidelines for systems designed to work with the Microsoft Windows 2000 Server family of operating systems. This document addresses design issues for commodity servers; in general, these servers contain up to eight microprocessors and use a variety of industry-standard technologies.

Introduction to Design Issues

The intent of this guide is to provide information about designing servers, hardware, and software that take best advantage of the Windows 2000 Server operating system.

This guide represents a collection of system definitions and requirements for bus and device design. The requirements and recommendations emphasize features and attributes of a system that can perform extremely well under Windows 2000 Server. These guidelines emphasize the following areas:

  • Performance. The ideal way to specify performance capabilities would be to specify performance against specific benchmark tests. However, the available benchmark tests do not allow directly comparing systems unless tests are conducted with identical client setup and software configurations, which are not currently defined. Wherever possible, requirements in this guide are defined according to the benchmark performance goals. When reliable benchmark tests are not available, specific hardware configurations are defined for servers so they achieve the performance capabilities necessary to meet the requirements defined in this guide.
  • Reliability. To fulfill its function, the server system must run all the time, with fault-tolerance capabilities and features that smoothly replace a failed drive. High availability is an extremely important feature for all servers, although this feature can be manifested differently according to how the server is used. However, certain baseline goals are desirable for each class of server, so various elements of these requirements address reliability and high-availability needs for servers.
  • Robustness and capacity. For many server applications, good scalability and serviceability become extremely important. This guide specifies some requirements related to components, such as RAM expansion capabilities, to address robustness issues. Additional requirements or recommendations provide for expansion capabilities in the server system.
  • Ease of use and ease of maintenance. Various requirements seek to address issues related to ease of use and ease of maintenance — two factors that strongly affect the TCO for servers.
  • Security. Some requirements ensure security of user data or access to system components.

When working to meet these requirements and when choosing to support additional hardware design recommendations, the designer must continually weigh cost versus performance. In defining these guidelines, extra attention has been given to this concern.

Intel and Microsoft are dedicated to strategic industry relationships that deepen and strengthen support for evolving the platform. Both companies work with industry groups to define standards for new technologies. In support of this evolution of server platforms, Microsoft has become involved in the following efforts:

  • Designing operating system support for new bus and device classes to ensure that new technologies can quickly reach a broad market.
  • Enhancing the Windows 2000 Server and later operating systems to make it easy for both hardware and software developers to exploit operating system capabilities.
  • Offering the HCL and other programs to help customers identify hardware and software designs that take advantage of the Windows 2000 Server operating system.

The system design requirements defined in this guide support a synergy among server hardware, the Microsoft Windows 2000 Server operating system, and Win32-based and Win64-based software. These requirements for systems and components are based on the following goals:

  • System platforms, buses, and devices meet industry standards and specifications for each bus type and device class.
  • Systems and devices meet minimum performance requirements.
  • Systems and devices meet ease-of-use and physical design guidelines.
  • Systems and devices are supported by device drivers that follow guidelines defined in the Windows 2000 DDK for behavior, installation, and removal.
  • Systems and devices support Plug and Play configuration and OnNow power management for configuring and managing all system components under the Windows 2000 Server operating system.


Server Classes and Operating System Editions

Servers perform a huge variety of tasks and combinations of tasks, resulting in many configurations. To specify requirements in a meaningful way, this guide first defines a basic set of requirements for a generic (or basic) server platform. This guide then provides additional recommendations and requirements for the server usage models described here:

  • Basic server. This server can be used in any environment. This server is described by a set of requirements and recommendations that seek to define a well-rounded, general-purpose server platform used solely as a server. Such a server can be used in small businesses or for a variety of uses in larger businesses, ranging from departmental use to clustered applications in the enterprise. Administration can be local or remote.

This server’s baseline capabilities include high availability, serviceability, scalability, ease of use, and ease of administration. This platform and its requirements are used as a basis for other types of servers defined by this guideline.

  • Small office/home office (SOHO) server. Although it can be used in any environment, this server platform has features that increase its ease of use and deployment in small businesses, which usually do not have great experience using and deploying server systems. This general-purpose platform handles file, print, and client-server application requirements. This server must have a broad set of attributes to handle all typical server tasks in a limited environment. Quick recovery is required, because downtime will immediately impact the small office’s ability to conduct business.

The system must be easy to set up and manage from a remote location, such as the headquarters for a value-added retailer (VAR), or directly by the server owner, who may have little or no computer knowledge. To increase ease of use and availability, the system should be capable of exploiting the reliability features of Windows 2000, such as disk mirroring and clustering. The system should have low entry costs and low recurring costs, because cost is often a driving issue in SOHO environments.

The SOHO server has additional requirements driven by the usage and deployment model for this platform. The SOHO server could also serve as a client workstation, while simultaneously performing its normal role as a server. This dual usage imposes additional requirements for power management and configuration.

  • Enterprise server. This server can also be used in any environment, but is frequently deployed as the building block for a large organization where it often performs special-purpose tasks, such as handling and routing e-mail, or storing financial data. Because this server is an indispensable part of the organization, it must be highly available. Therefore, software and hardware mechanisms must be in place to eliminate unplanned downtime.

The Microsoft Windows 2000 Server operating system is available in four editions:

  • Windows 2000 Server: The successor to Windows NT Server 4.0, it is a multipurpose network operating system for businesses of all sizes.
  • Windows 2000 Advanced Server: The successor to Windows NT Server 4.0, Enterprise Edition, it is the operating system for e-commerce and line-of-business applications, providing load balancing and clustering services as well as enhanced symmetric multiprocessing (SMP) capabilities.
  • Windows 2000 Datacenter Server: The newest member of the Windows Server family, it is the operating system for business solutions that demand the highest degree of scalability, availability, and reliability.
  • Microsoft Small Business Server: Provides small businesses with essential tools, including file and printer sharing, business-critical applications, e-mail and scheduling, and support for Internet and communications services such as Internet, remote access, and fax.


Designing Systems for Windows 2000 Server

The requirements and recommendations in this guide are defined in relation to classes of server systems and components used with the Microsoft Windows 2000 Server operating system.

Windows 2000 Server is a preemptive, multitasking operating system that includes security and networking services as fundamental components of the base operating system. Windows 2000 Server also supports high-performance computing by providing kernel support for computers that have symmetric multiprocessor configurations.

Under Windows 2000 Server, Plug and Play and power management capabilities are made available for ACPI-compliant server systems. Other major hardware initiatives for Windows 2000 include the following:

  • Support for bus and device classes such as USB, IEEE 1394, Human Interface Device (HID) class, and Fibre Channel.
  • Support for Microsoft Cluster Server and up to four nodes in a Microsoft Cluster Server (MSCS) cluster in Windows 2000 Datacenter Server.
  • Online volume management, hierarchical storage management (HSM), Removable Storage Manager, and improvements in backup and recovery support.
  • Support for Web-Based Enterprise Management (WBEM) and WMI as part of the Zero Administration initiative for Windows, reducing hardware ownership costs.
  • Support for I2O architecture.
  • Support for System Area Networking.
  • Support for large physical memory (more than 4 GB).
  • Support for Windows 2000 Server running on IA-64 systems. Note that only the 64-bit version of Windows 2000 and later versions will be supported by Microsoft on IA-64 systems. In other words, 32-bit versions of Windows will not be supported on IA-64 systems by Microsoft.

For information about Windows 2000 Server features and capabilities, see http://www.microsoft.com/Windows2000/guide/server/.


ACPI and OnNow Design

Windows 2000 Server includes support for ACPI, which supports operating system-based power management and Plug and Play system-configuration capabilities. This guide summarizes some of the system and device capabilities for hardware used with Windows 2000.

The goal of the OnNow design initiative is to ensure that all system components work together to enable robust and reliable system configuration and power management. The operating system and applications work together intelligently to deliver effective power management. All devices connected to the system or added by the user participate in the device power-management scheme.

The OnNow design initiative includes requirements for the operating system, applications, device drivers, and hardware in order to deliver transparent power management and improve integration of components. The changes include:

  • Enhanced core operating system functionality for power management.
  • A system interface for operating system-directed power management and Plug and Play. The ACPI design also provides future extensibility and improved system integration.
  • Windows Driver Model (WDM), which supports power management and Plug and Play, and provides a common set of I/O services and binary-compatible device drivers among Windows 98 and Windows 2000 for targeted device classes (audio, input, video, and still imaging) and bus classes (for example, USB and IEEE 1394).
  • Device and bus hardware power management interfaces and state definitions.
  • An application architecture that allows applications to integrate into power management of the system.

The ACPI specification defines a flexible and abstract hardware interface that enables a wide variety of server systems to implement power and thermal management functions while meeting the cost and feature requirements of the target market. ACPI also provides device configuration and generic system-event mechanisms for Plug and Play, unifying the power management interface with the Plug and Play interface.

The ACPI implementation is independent of the processor architecture and enables the operating system to direct power management throughout the system.

For more information about ACPI and the OnNow design initiative, see the OnNow web site at http://www.microsoft.com/hwdev/onnow.htm.


IA-32 vs. IA-64 Design

Windows 2000 is designed to run on platforms with processors that use the Intel Architecture instruction set, including:

  • IA-32 platforms, such as Intel Pentium, Intel Pentium with MMX technology, Pentium Pro, Pentium II, Pentium III, Pentium II Xeon and Pentium III Xeon, or compatible processors.
  • IA-64 platforms, such as Intel Itanium or compatible processors.

This section summarizes design issues for IA-32 versus IA-64 systems that meet the requirements in this guide.

ACPI 1.0b vs. ACPI 2.0

In this version of the Hardware Design Guide, ACPI version 1.0b is the version of the ACPI specification that addresses related requirements for IA-32 systems. It also serves as a key component of PCI hot plug implementations in all systems that can be natively supported by Windows.

ACPI version 2.0 will address requirements for both IA-32 and IA-64 systems. In this version of the Hardware Design Guide, ACPI Version 2.0 is required for all IA-64 systems, because it is the first version of the ACPI specification that addresses the specific requirements for IA-64 systems with regard to ACPI firmware, hardware, and motherboard support. In particular, the ACPI 2.0 specification defines expanded interfaces to support IA-64, with extended Table definitions and new ACPI Source Language (ASL) and ACPI Machine Language (AML) 64-bit functions.

Boot and Firmware Support: BIOS vs. EFI

Firmware issues. In this design guide, firmware boot support for IA-32 is assumed to be BIOS based (as Windows EFI support for IA-32 systems has not yet been defined).

Firmware support for IA-64 systems must comply with the Extensible Firmware Interface Specification, Version 1.0 (EFI 1.0) or later. BIOS-based boot is not supported and will not work with 64-bit Windows.

In addition, in this guideline, PXE_BC (remote/network boot), SERIAL_IO, and SIMPLE_NETWORK protocols as defined in the EFI specification are required for EFI systems.

Other boot support. IA-32 systems must support standard BIOS mechanisms for determining the boot drive and must support Int 13h. IA-64 systems provide a globally unique identifier (GUID) Partition Table (GPT) partitioned hard drive for boot, compliant with the EFI specification.

IA-32 vs. IA-64 Miscellaneous Design Issues

Memory. In this guide, IA-32 systems must support minimum memory capacity of 2 GB (for systems that provide support for fewer than 4 processors) or 8 GB (for systems with 4 or more processors). IA-64 systems must support a minimum RAM expansion capacity of 16 GB (for systems that provide support for fewer than 4 processors) or 32 GB (for systems with 4 or more processors).

APIC support. In this guide, IA-32 systems must include Advanced Programmable Interrupt Controller (APIC) support that complies with ACPI 1.0b. IA-64 systems must include Streamlined APIC (SAPIC) support that complies with the 64-bit extensions defined in ACPI 2.0

Headless servers. In this design guide, Enterprise class IA-32 systems are required to support capabilities for "headless" server functionality; this is a recommendation for basic and SOHO class servers in this version of the design guide. Headless support is likely to become a requirement for all IA-32 systems in future versions of these guidelines. IA-64 systems are not required to support this capability. However, headless support is expected to become a requirement for IA-64 systems in future versions of these guidelines, when related support is provided in a future version of 64-bit Windows.

Manageability. IA-32 systems must support manageability as defined in this document and in Windows Hardware Instrumentation Implementation Guide. In addition to this, IA-64 systems must implement hardware and firmware support for IA-64 Machine Check Architecture.

Devices. IA-64 systems must not include legacy parallel ports and must provide a legacy serial port for use as a debug port.


Chapter 2 System Component Requirements

This chapter presents requirements and recommendations that apply to the whole server system, including key components such as memory and power management. They apply to standard, high volume (or commodity) servers that run the Microsoft Windows 2000 Server operating system.

Tips for selecting high-performance system components. For manufacturers who want to select high-performance components for server systems, the following are design features to look for when selecting components to improve memory performance:

  • Implement PCI controllers as peer bridges to improve I/O bandwidth.
  • Support fast, large, expandable memory.
  • Support the largest possible caches.

Note: The system requirements defined in this publication provide guidelines for designing servers and peripherals that deliver an enhanced user experience when implemented with Windows 2000 Server. These requirements are not the basic system requirements for running any versions of the Windows 2000 Server operating system.


General Component Requirements

This section lists requirements and recommendations for system components such as memory and power management.

1. System and components properly support all dates

Required

The firmware, real-time clock, system clocks, and the system as a whole must work correctly for all dates.


System Microprocessor Requirements

This section summarizes processor requirements for server systems.

Note: It is recognized that OEMs supply systems with specific feature requirements to corporations, which can include providing servers that do not include any processors pre-installed before shipping.

2. Multiprocessor-capable system meets Windows requirements and minimum expansion requirements

Required

2.1 Enterprise class server system supports expansion to at least four processors

2.2 IA-32 multiprocessor-capable system supports ACPI 1.0b

For systems in which more than one processor can be installed, the system must employ those processors symmetrically; that is, all processors must be able to access all I/O buses and system memory, and cache coherency must be maintained. The system must also comply with the ACPI 1.0b specification.

In addition, Advanced Programmable Interrupt Controller (APIC) support must comply with ACPI 1.0b by including the Multiple APIC Description Table defined in Section 5.2.8.

Note that Windows 2000 and later versions of Windows use ACPI on all ACPI-based systems, and therefore compliance with MultiProcessor Specification, Version 1.4 (MPS 1.4) is no longer required.

For information about the requirements for PCI IRQ routing on a multiprocessor ACPI system, see http://www.microsoft.com/hwdev/onnow/acpi-mp.htm.

Note on Multiprocessor Wake-up: A problem has been uncovered with certain multiprocessor systems that will prevent them from properly waking up from a Sleep state under Windows 2000. This pertains to dual-processor or multi-processor systems that transition all processors from an active state to a STPCLK state, and more specifically to systems where all processors receive their STPCLK# request from one source.

Prior to transitioning from a STPCLK state to a Sleep state or lower power state, all processors must generate a Stop Grant Bus cycle. It is essential that all processors have transitioned into the STPGNT state before it is safe to: 1) transition to a lower power state such as Sleep, or 2) externally shut off the processor clocks to allow for flushing buffers, cache maintenance, and other internal activities.

For dual-processor and multiprocessor systems using a single STPCLK to all processors and a single SLP pin to all processors, the transition to the Sleep state should not be used. Behavior of the system during removal of the processor clock-such as transitions from STPCLK to Sleep state-cannot be guaranteed unless all STPGNT bus cycles are received.

For example, Intel Xeon II Specification, "Section 4.2.5 Sleep State-State 5," specifies that for a multiprocessor system, all processors are required to complete the Stop Grant bus cycle before the subsequent 100 BCLK waiting period and before the assertion of SLP# can occur. When multiple processors are serviced by a single STPCLK# request to all processors and a single SLP#, there is no provision to guarantee that all Stop Grant bus cycles are received before the assertion of SLP#.

As another example, in 450NX-based platforms from Intel, the STPCLK# from PIIX4E is connected to all processors, and SLP# from PIIX4E is connected to all processors. The following sequence occurs:

t0. Operating system writes PMCNTRL register.
t1. PIIX4E asserts STPCLK#, then waits for Stop Grant acknowledgment.
t3. The processor acknowledges with Stop Grant ACK cycle.
t4. PIIX4E asserts SLP# after receiving this.

This sequence works for uniprocessor systems (which is what the PIIX4E was originally designed for). However, in multiprocessor systems, SLP# might be asserted to a processor that is not in Processor Sleep State 3 (that is, not yet acknowledged). This premature SLP# assertion might result in a wake-up problem.

Intel provides additional information about this issue through the Intel Technical Support Hotline at 1-800-628-8686 or 916-377-7000.

2.3 IA-64 multiprocessor-capable system complies with ACPI 2.0

For an IA-64 system in which more than one processor can be installed, the system must employ those processors symmetrically; that is, all processors must be able to access all I/O buses and system memory, and cache coherency must be maintained. The system must also comply with the ACPI 2.0 specification.

In addition, an IA-64 system must include a Multiple SAPIC Description Table that complies with ACPI 2.0.

Note that MPS 1.4 support is not a requirement for systems with 64-bit processors and will not be used by any version of the 64-bit Windows operating system.


Memory Requirements

This section defines minimum memory requirements for server systems.

Note: It is recognized that OEMs supply systems with specific feature requirements to corporations, which can include providing servers that do not include any memory pre-installed before shipping or otherwise fulfill specific customer requirements for installed memory.

3. For IA-32 system, installed memory meets minimum requirements

Windows 2000 Server, Small Business Server | Windows 2000 Advanced Server, Windows 2000 Datacenter Server
For 1–2 installed processors, 512 MB Required | For 1–4 installed processors, 1 GB Required
For more than 2 installed processors, 256 MB per installed processor Required | For more than 4 installed processors, 256 MB per installed processor, Required

Memory requirements are defined in relation to the installed operating system. There are no requirements defined in relation to the server type.

All memory visible to the operating system as system memory must be cacheable. All system memory except for 4 MB must be completely available for the system to use at boot time and cannot be locked from use by the operating system. This minimum requirement for memory available to the operating system does not preclude applications that use dynamically-allocated memory for temporary uses.

Recommended: Larger installed memory configurations, which will increase performance.

4. For IA-64 system installed memory meets minimum requirements

Required

The minimum installed memory requirement for IA-64 systems is 1 GB of system memory.

All memory visible to the operating system as system memory must be cacheable. All system memory except for 4 MB must be completely available for the system to use at boot time and cannot be locked from use by the operating system. This minimum requirement for memory available to the operating system does not preclude applications that use dynamically allocated memory for temporary uses.

Recommendation

Recommended: Larger installed memory configurations, which will increase performance.

5. For IA-32 system, memory capacity meets minimum requirements

Systems that provide support for <4 processors: 2 GB Required

Systems that provide support for 4 or more processors: 8 GB Required

This requirement defines minimum RAM expansion capabilities for an IA-32 system. All memory visible to the operating system as system memory must be cacheable.

6. For IA-64 system, memory capacity meets minimum requirements

Systems that provide support for <4 processors: 16 GB Required

Systems that provide support for 4 or more processors: 32 GB Required

This requirement defines minimum RAM expansion capabilities for an IA-64 system. All memory visible to the operating system as system memory must be cacheable.

7. System memory includes ECC memory protection

Required

The system memory and cache must be protected with Error Correction Code (ECC) memory protection. All ECC RAM visible to the operating system must be cacheable. The ECC hardware must have the ability to detect at least a double-bit error in one word and to correct a single-bit error in one word, where "word" means the width in bits of the memory subsystem. A detected error that cannot be corrected must result in a system fault.

8. NUMA and NUMA-"lite" system design maintains near:far memory access time ratios of 1:3 or less

Recommended

For optimal performance with Windows 2000 and later operating systems, it is recommended that system designers building platforms that present memories with different access times keep the ratio for access to "near" versus "far" memories relative to a given microprocessor at a 1:3 ratio or less as seen by the operating system.


ACPI and Power Management Requirements

This section defines the system and BIOS requirements for ACPI and power management.

9. System design meets ACPI and related requirements

Required for all server types, with additional requirements for SOHO servers

IA-64 system board sets must support ACPI 2.0 or later.

IA-32 system board sets must support ACPI 1.0b or later.

This requirement ensures that the system correctly supports the Plug and Play and power management functionality described in this guide.

9.1 Server system implements basic ACPI and power management capabilities

ACPI support for all server systems must include the following required capabilities:

  • Power management timer. System control interrupt and necessary Status and Enable (STS/EN) bits must be provided.
  • Support for a description table that defines the complete hierarchy for system-board devices, including host PCI bridges. The description table must include all non-Plug and Play devices to be enumerated and all other devices for which power management or removal capabilities have been added by the system-board design.
  • Each bus and device enumerated using ACPI includes the ACPI control methods necessary to configure these devices. This includes requirements defined in these guidelines for automatic device configuration, resource allocation, and dynamic disable capabilities.

For information about Plug and Play support under Windows 2000, see "Setup, Plug & Play, Power Management" in the Windows 2000 DDK. Standard system devices are excluded from related requirements, as described in guideline "#16. System and device configuration meet Plug and Play requirements."

  • Thermal model and fan control, if implemented, comply with ACPI. IA-64 systems must comply with Section 12 of ACPI 2.0. IA-32 systems must comply with Section 12 of ACPI 1.0b. Notice also that a server that supports thermal controls must have active thermal control such as a fan and cannot use passive thermal control under normal operating circumstances.

This requirement, however, does allow proprietary value-added features that cannot be implemented using ACPI. For example, systems are permitted to use out-of-band methods to provide cooling when the operating system is not booted.

  • Support for at least one processor power state. This can be either C1, C2, or C3.
  • No capabilities for the end user to disable system ACPI support using CMOS or other means. Disabling ACPI will cause boot failures because Windows 2000 relies on ACPI to identify and initialize system devices.

This requirement, however, does allow proprietary value-added features that cannot be implemented using ACPI.

9.2 SOHO server implements additional ACPI and power management capabilities

The following ACPI support is required for SOHO servers and recommended for other server types:

  • Power button complies with ACPI. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b. This is described in guideline "#10. Hardware design supports OnNow initiative."

Note: Very large, or rack-mountable, or partitionable systems may face challenges with actual "physical" ACPI power buttons. A possible alternative for server systems is a "virtual" ACPI power button which acts as an ACPI power button but which is "activated" via a service processor action or other form of remote management (instead of via an actual administrator pressing a button physically located on the server).

  • Real-time clock alarm that supports wake-up based on a scheduled time and day of the month. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b. If this feature is implemented, the day-of-month feature is required under these guidelines, although it is an optional feature in the ACPI specification. Also, if this feature is implemented, system control interrupt and necessary STS/EN bits must be provided.
  • ACPI-compliant support for the S5 soft-off state. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b. If a soft-off feature is supported, it must meet the requirements for the S5 state defined in the ACPI specification.
  • Support for either the S1, S2, or S3 sleep state. Support for at least one of the S1, S2 or S3 sleep states must be provided by SOHO servers.

Support for the S3 state (Suspend to RAM), which provides the optimal user experience and power savings, is likely to become a requirement in a future version of this design guide.

  • USB host controller can wake the system. If a USB host controller is present in the system, it must support wake-up capabilities in one of the following system states: S1 or S2. If the system contains multiple USB host controllers, all host controllers integrated on the system board (that is, not add-on cards) must meet this requirement. USB devices and USB client software and drivers must not fail over system suspend and resume cycles.

Recommendation

Recommended: Support wake-up from the S3 state.

Notice that if wake-up from the S2 or S3 state is supported, wake-up must be supported for all higher power sleep states. For example, if the controller supports wake-up from the S2 state, it must also support wake-up from the S1 state.

Note: For IA-64 systems, a server system implementing system-board power management or configuration features that are defined in the ACPI 2.0 specification must comply with ACPI 2.0, even if those features are not specific requirements or recommendations in these guidelines. This requirement, however, does allow proprietary value-added features that cannot be implemented using ACPI.

For IA-32 systems, a server system implementing system-board power management or configuration features that are defined in the ACPI 1.0b specification must comply with ACPI 1.0b, even if those features are not specific requirements or recommen.dations in these guidelines. This requirement also allows proprietary value-added features that cannot be implemented using ACPI.

10. Hardware design supports OnNow initiative

Required for all server types, with additional requirements for SOHO servers

Elements of the OnNow design initiative ensure that the operating system and device drivers control the state of individual devices and the system board set.

10.1 Buses on system that supports S1–S3 meet bus power management requirements

SOHO servers and any Basic or Enterprise server that supports any one of the S1, S2, and S3 sleep states must—and all servers should—provide PCI, USB, and IEEE 1394 buses that support power management requirements, as defined in the related bus standards.

10.2 All devices and drivers support D0 and D3 power states

All devices and drivers must support the D0 and D3 power states consistent with the definitions in the Default Device Class Power Management Specification and the relevant device class power management reference specification. This requirement must be implemented so that each device can successfully survive a system sleep/wake transition (device D3 to D0 transition) without requiring user intervention to restore functionality.

This requirement applies whether or not system power is removed while the computer is in an S1–S4 state. The operating system supports the S4 state without system-board support, so all devices and drivers must meet this requirement.

It should be noted that when PAE mode is used to allow access to more than 4 GB of physical memory on servers running either Windows 2000 Advanced Server or Windows 2000 Datacenter Server, S4 hibernation will not be supported by the operating system. This is because the time and disk space needed to save and restore the system image for a system with 4 GB or more of system memory will typically greatly exceed the amount of time needed to reboot such a system. However, all systems, devices, and drivers must still meet the requirements within this guideline as it is always possible that even a large system may have less than 4 GB of physical memory or not be running in PAE mode.

Notice that there is no power consumption requirement for devices in the D3 state. It is recommended, however, that devices implement the D3 state so that device power consumption is reduced to near zero, with the recognition that there is no requirement to retain any device context because it will be preserved or restored by the driver when returning to the D0 state.

Recommendation

Recommended: Devices and drivers should support the D1, D2, or both low-power states, and they should support the defined wake events as designated in the relevant device class power management reference specification.

10.3 System provides software-controlled, ACPI-based power switch

For SOHO servers, the system must provide an easily accessible power switch that can be controlled by software.

Recommendation

Recommendation: This is a recommendation for Basic and Enterprise servers.

The following provides implementation guidelines for the power switch. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b.

  • A single ACPI button design is preferred. This button must be the user’s primary switch interface, and must be implemented as a power button as defined by the ACPI specification.
  • If a two ACPI button design is used, the sleep button must be the user’s primary switch interface, and be easily distinguishable from the power button. The preferred implementation in a two-button design is to hide the power button behind a door or on the rear of the system.

The function of these buttons is determined by the operating system.

  • In case of a hardware or software failure that prevents normal operation of the software-controlled buttons, the switch capabilities must include an override mechanism for turning off the server.

Recommendation

Recommended: A 4-second override mechanism as described in Section 4.7.2.2.1 of ACPI 1.0b and in Section 4..7.2.12.1.3 of ACPI 2.0. The override must be associated with the user’s primary switch interface, in order to establish an industry-standard implementation.

Notice that the override mechanism is not an alternative way for the user to turn off the server in normal operation; it is only a fail-safe function for fault conditions.

  • If the power switch is provided on the keyboard, the key must be clearly labeled and must consist of a single keystroke for turning on the server, to ensure accessibility for persons with disabilities. (Two keystrokes can be used to turn off the server.)

For information about scan codes for keyboard power switches, see http://www.microsoft.com/hwdev/desinit/scancode.htm.

10.4 System that support S1–S3 provides one or more indicators to show whether the system is in the working or sleep state

This capability is required for all SOHO servers and any other server systems that support S1, S2, and S3.

Recommendation

Recommended: A non-flashing, light-emitting diode (LED) sleep indicator that is a different color than the wake indicator. A slowly blinking LED indicator (less than 1 Hz) is also an acceptable implementation. This applies for S1, S2, and S3 system states.

The nonvolatile sleep state, S4, should appear to the user as the off state (S5); therefore, both of these states should have the same indicator.

10.5 For SOHO server and any other server that supports S3, the system power supply provides "standby" power for wake-up events

The system must supply adequate standby power to support wake-up events. The system must provide, at a minimum, power for the core chipset including memory and all integrated wake devices, wake-up from the keyboard, a pointing device, and a single network device such as a local area network (LAN) or wide area network (WAN) adapter connected via an external bus or open PCI slot when the system is in the S3 or S4 state.

Additional information about this requirement can be found in EPS Power Supply: A Server System Infrastructure (SSI) Specification for Entry Chassis Power Supplies, at http://www.ssiforum.org/docs/entrylevelpowersupply.pdf.

This capability is required for SOHO servers. If a Basic or Enterprise server supports the S3 sleep state, this capability is required, otherwise, it is optional.

11. System startup meets requirements for OnNow support

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Optional | Optional | Optional
Enterprise: | Optional | Optional | Optional
SOHO: | Required | Required | Required

The intention of this recommendation is to ensure that the end user is not presented with unnecessary visual displays and to ensure that access to error information remains available using a hot key.

The following is required for SOHO servers. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b.

  • System firmware supports fast POST. The system should be available to the user as quickly as possible. Although a specific time limit is not established, the basic recommendation is that power on to the boot.strap loader should occur within 5 seconds, plus hard-disk ready time, option ROMs, and time required for memory subsystem initialization and ECC.

The following are recommended ways to reduce processing overhead to make system boot time as fast as possible:

  • No video memory test and limited test for dynamic RAM (DRAM) size
  • No tests for serial or parallel ports
  • No floppy disk test or media check (boot from hard disk only)
  • No tests for hard disk controller or drive type (if the system does not include swappable drives)

Fast Power-On Self Test (POST) mode for system firmware can be disabled by the user for troubleshooting.

  • Resume from sleep state (S1–S3) to operating system handoff should occur within 500 ms. This recommendation does not apply to the S4 state. For all other sleep states, the time to operating system handoff means when the processor starts running (first instruction) until the system firmware jumps to the Waking Vector in the ACPI firmware con.trol structure table, as described in Section 5.2.6 in ACPI 1.0b or in Section 5.6.2.1 in ACPI 2.0.
  • Minimal startup display. System startup should draw the end user’s attention only when errors occur or when user action is needed.

The default configuration should allow a beep during the boot process only in case of an error, and the only screen display should be the OEM splash screen, which can include information such as copyright notices. By default, the system should be configured so the screen display does not show memory counts, device status, and so on. The display should present a "clean" system firmware startup so that the end user is not presented with cryptic and unnecessary information.

However, the system start-up process can include the following:

  • A blank start-up screen.
  • A hot-key override to display screen messages for troubleshooting or to display user-definable CMOS settings.
  • Text-based, end-user action messages. Examples are: messages to display the setup hot key, the system help hot key, password entry, network log-on for remote booting, and so on.
  • Manufacturer branding messages.
  • A CMOS option to turn the clean start-up screen off and on.

Recommendation

Recommended for SOHO servers: Compliance with Simple Boot Flag Specification, Version 1.0 or later. This enables the BIOS to boot quickly when the last boot was successful and to perform diagnostics only if a problem occurred on the previous boot.


Startup Support Requirements

This section defines the firmware and other requirements to support system startup.

12. System firmware meets general boot support requirements

Required

Notice that the Extended System Configuration Data (ESCD) calling interface is not supported by Windows 2000.

The requirements for boot support are summarized in the following items.

12.1 System firmware supports SMBIOS 2.3

This mechanism is required to provide platform specific information at boot time, including the server’s Universally Unique Identifier (UUID). System Management BIOS Reference Specification, Version 2.3, is available at http://www.phoenix.com/products/specs-smbios.pdf.

In addition, the UUID must be provided to the user in printed form, for assistance in environments where it could be used as part of pre-staging systems. This mechanism is left up to the system manufacturer, but suggested means include posting the UUID on the system chassis or case, or printing it the shipping carton.

12.2 Firmware implements security, such as a preboot password

This is provided to protect enable and disable capabilities for hardware components before the operating system boots. At a minimum, User and Administrator levels of password protection must be provided in the system firmware. This capability prevents end users from accidentally or purposefully circumventing operating system-level security and control as applied by an administrator.

12.3 Firmware supports BIS

For systems that include integrity or authentication services for downloaded remote boot images, the system’s firmware must provide these capabilities as defined in Boot Integrity Services (BIS), Version 1.0, available at http://developer.intel.com/ial/wfm/wfmspecs.htm.

In addition to the management data required by SMBIOS 2.3, BIS requires inclusion of Type 31 (BIS Entry Point) in the table of exported SMBIOS structures.

12.4 Firmware provides boot support for CD and DVD drives

The system firmware or option ROM must support the No Emulation mode in El Torito, Version 1.0.

For related information for IA-64 systems, see guideline "#14.5 EFI IA-64 system firmware provides boot support for CD and DVD drives."

12.5 System supports firmware update mechanism

System administrators must be able to upgrade system firmware to a new image. The following methods can be used to meet this requirement:

  • Remote new-system setup mechanism based on PXE capabilities allowing programs to be downloaded and executed at boot time.
  • Normal file access and execution methods when the system is fully booted into the normal operating system environment.

Recommendation

Recommended for all system types:

  • If option ROMs are provided, they should also be capable of being updated.
  • Implement a mechanism to authenticate the requester of the update programming. Implement a mechanism to validate that the program arrived intact after download.

See also the BIOS requirements and recommendations for ATA support in guideline "#177. ATA controller and peripherals comply with ATA/ATAPI-5 standard commands for features implemented and support Ultra-DMA (ATA/33, minimum)."

13. IA-32 BIOS boot system supports remote/network boot, USB boot devices, and firmware update

Required

13.1 IA-32 BIOS boot system supports PXE 2.1

If a server provides support for network adapters that provide remote boot capabilities using Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP), the server must also provide support for the preboot execution environment. For IA-32 BIOS boot systems, this is described in PXE 2.1, available at http://developer.intel.com/ial/wfm/wfmspecs.htm.

13.2 IA-32 BIOS boot system supports CIP BIOS Boot 1.01 for network-based boot

BIOS supports booting the system from the network, with a mechanism for setting the order of precedence for boot devices. If a server provides support for BIOS boot from a network adapter, the system BIOS must comply with the requirements defined in Sections 3 and 4 (as they apply to Plug and Play devices) of CIP BIOS Boot 1.1, which describes the requirements for Initial Program Load (IPL) devices.

The BIOS must allow all boot devices to be configured according to order of precedence for boot. This mechanism must clearly show how the system will order boot devices when end users are making configuration choices. For example, in a system that permits booting from floppy drive, hard drive, CD or DVD drive, and network adapter, it must be clear to the end user how to set a boot order that favors a specific device, such as the CD drive.

In addition, for any system that includes a network adapter capable of PXE-based remote boot, a key sequence must be provided to allow the user to force a boot initiated from the network adapter, either directly or via a pop-up screen. This key sequence must be enabled by default. Configuration of this feature may be provided through a CMOS configuration setting. When this feature is enabled, the boot display must indicate the key sequence that will invoke the pop-up screen allowing a network boot.

This display must appear for a duration sufficient to be read by users, but must not lengthen the overall time needed to boot the machine. This feature must be implemented in accordance with Appendix C of CIP BIOS Boot 1.01. Note that this feature is a requirement in this Hardware Design Guide, although it is optional in CIP BIOS Boot 1.01.

For consistent user experience across all system brands and types, it is suggested that system and BIOS manufacturers standardize on the F12 key to perform this action. It is expected that F12 or another standard key sequence will become a requirement in a future version of this design guide.

13.3 IA-32 BIOS boot system supports USB keyboards, pointing devices, and hubs as boot devices

For a server that includes a USB keyboard as the only keyboard in the system, the system BIOS must provide support during the bootstrap process for USB keyboards, pointing devices, and hubs. This BIOS support is defined in the USB Device Class Definitions for Human Interface Devices, Version 1.1 (HID 1.1), with particular attention to the Keyboard Boot Protocol. This BIOS support must provide the ability for the user to enter the BIOS setup utility; it must also provide enough functionality to install and boot an operating system that recognizes USB peripherals. USB keyboards built as standalone devices, part of a composite device, or part of a compound device must be recognized and usable. The BIOS is required to support keyboards behind at least one level of external hub.

For systems with multiple USB host controllers, BIOS support for USB keyboards and hubs is required for all host controllers that are integrated on the system board (that is, not add-on cards).

Keyboard and pointing devices must be functional for all modes of the operating system, including the bootstrap process, loading, recovery console, and operating system installation.

USB external connectors and USB input device support must be enabled by default in the BIOS, and the BIOS must make USB input devices such as keyboards and pointing devices available at boot time.

13.4 IA-32 BIOS boot system firmware supports console redirection to a serial port, if serial headless server support is implemented in the system

If serial port based headless server support is provided by the system, the system must provide support for redirection of all BIOS driven console I/O to the serial port. The driver for the serial console must be capable of supporting the capabilities documented in Extensions to the VT100 Terminal Definition, available at http://www.microsoft.com/hwdev/headless/.

An IA-32 BIOS boot system must provide information about the location and configuration of this serial port via ACPI and the methods described in Serial Port Console Redirection Table available at http://www.microsoft.com/hwdev/headless/. The BIOS must release the serial port as soon as the Windows loader is called.

Additionally, if the system BIOS supports localization, it must meet the requirements specified in Extensions to the VT100 Terminal Definition.

Recommendation

Recommended: IA-32 BIOS boot system support should include the following, where appropriate:

  • An IA-32 BIOS boot system should use the E820 interface to report memory. The E820 interface allows systems to report (and test) memory, and also allows memory to be reclaimed. Information about this interface can be found in Paragraph 2 of Section 9.3.2, "BIOS Initialization of Memory," in ACPI 1.0b, which states that the E820 specification has been updated and lists the new memory range types.
  • System BIOS on an IA-32 BIOS boot system or option ROM provides ARMD-compliant boot support for ATAPI bootable floppy disk drive. Complying with the ATAPI Removable Media BIOS Specification (ARMD), Version 1.0 or later specification provides Int 13h and Int 40h support for bootable floppy drives as the primary or secondary floppy device.

14. IA-64 system complies with EFI 1.0 or later, with support for USB boot devices, firmware update, and PXE_BC, SERIAL_IO, and SIMPLE_NETWORK protocols

Required

The only boot mechanism supported for platforms running 64-bit Windows is defined in EFI 1.0 or later. BIOS-based boot is not supported and will not work with 64-bit Windows.

Note: Although the PXE_BC (remote/network boot), SERIAL_IO, and SIMPLE_NETWORK protocols are defined as optional implementation elements in the EFI specification, in this guideline they are requirements for EFI systems.

14.1. EFI IA-64 system supports network-based boot via EFI boot manager

EFI systems must provide support for booting systems from the network as defined in EFI 1.0 or later. This support includes the capability, via the EFI boot manager, to configure boot devices in order of preference by the administrator of the server, plus a method for forcing a network-based boot. These mechanisms must be available to the administrator in the pre-boot state of the system.

14.2. EFI IA-64 system provides boot support for USB keyboard and bus

The system firmware must provide EFI boot support for USB keyboards, pointing devices, and hubs.

The system firmware must also support the keyboard behind at least one level of external hub. This support must provide the ability for the user to enter the system’s firmware-based configuration utilities and provide sufficient functionality to get EFI-aware versions of Windows installed and booted. USB keyboards built as standalone devices, part of a composite device, or part of a compound device must be recognized and usable.

For systems with multiple USB host controllers, firmware support for USB keyboards, pointing devices, and hubs is required for all host controllers that are integrated on the system board (that is, firmware support is not required for add-on cards).

Keyboard and pointing devices must be functional for all modes of the operating system, including booting, loading, recovery console, and operating system installation.

USB external connectors and USB input device support must be enabled by default in the firmware, and the firmware must make USB input devices such as keyboards and pointing devices available at boot time.

14.3. EFI IA-64 system implements SAL, including firmware update method

The System Abstraction Layer (SAL) is a firmware layer provided by OEMs. The implementation of this layer must conform to RS-IA-64 System Abstraction Layer (SAL) Specification, Revision 2.7 or later, including implementation of a call that will allow the firmware to be updated.

SAL abstracts platform uniqueness by providing a consistent interface to a higher level of the software stack to discover and control an IA-64 system. It exports components and their associated access details to the operating system through EFI using the SAL System Table.

14.4. EFI IA-64 system firmware supports console redirection to a serial port

The system must provide support for redirection of all console I/O to the serial port. The driver for the serial console must be capable of supporting the capabilities documented in Extensions to the VT100 Terminal Definition. Note that unlike BIOS, EFI firmware must indicate which serial port is used for console I/O and the configuration of that serial port through the console device path for the serial port as specified in EFI 1.0.

14.5. EFI IA-64 system firmware provides boot support for CD and DVD drives

The system firmware must support the No Emulation mode in El Torito, Version 1.0, and the additional requirements for EFI as defined in Section 16.2.2, "ISO-9660 and El Torito," in EFI 1.0.

14.6. EFI IA-64 system provides minimum required boot list variable storage

The minimum required non-volatile storage for boot list variables (used by the EFI boot manager) is 4 K. Note that this is storage reserved solely for use by boot list variables and may not be used for any other variables or purposes.

14.7. EFI IA-64 system provides a minimum, firmware-based driver set sufficient to allow boot, installation, and recovery operations without the presence of loadable media-based EFI drivers

The minimum set of capabilities required under this guideline include EFI console capabilities and sufficient other EFI drivers to permit access to devices needed for boot, installation, and recovery operations.

Note: An example of a specific problem that this guideline addresses is the possible case of a system that, in order to reach a given disk drive, must load a driver off that particular disk drive. It can readily be seen that such cases would result in an uninstallable system.

15. System provides a debug port solution

Required

All systems are required to provide a debug port solution, including the necessary hardware and system firmware to fully implement the solution. This capability provides support for debugging and troubleshooting activities.

15.1. IA-32 system meets debug port and configuration requirements

IA-32 system designers may choose to support one or more of the following debug port technologies:

  • Legacy serial port. The system firmware must configure at least one serial port to use either 2F8h or 3F8h. This allows the port to be treated as a boot device by the firmware and to be used by components as a diagnostic port if system debugging is required by either the firmware or the operating system.

Note that systems designed to implement a legacy serial port for debug purpose must not share this function with a serial port utilizing the Windows native serial port "headless server" functionality; in such a case, two serial ports are required.

  • Non-legacy debug ports. A system designed to implement an alternative Windows-compatible debug port must implement a debug solution that complies with the Debug Port Specification, available at http://www.microsoft.com/hwdev/NewPC/debugspec.htm.

15.2. IA-64 system meets debug port and configuration requirements

IA-64 system designers must provide a legacy serial port for use as a debug port. The platform firmware must configure at least one serial port to use either 2F8h or 3F8h. This allows the port to be treated as a boot device by the firmware and to be used by components as a diagnostic port if system debugging is required by either the firmware or the operating system.


Plug and Play Requirements

This section defines the specific requirements for Plug and Play.

16. System and device configuration meet Plug and Play requirements

Required

Windows 2000 Server implements complete support for Plug and Play configuration. Each bus and device provided in a server system must meet the current Plug and Play specifications related to its class, including:

  • Requirements defined in Section 6 of ACPI 2.0 (for IA-64 systems) or Section 6 of ACPI 1.0b (for IA-32 systems).
  • Bus class specifications, such as PCI Local Bus Specification, Revision 2.2 (PCI 2.2), USB 1.1 or later, and so on.
  • Requirements and clarifications for automatic device configuration, resource allocation, and dynamic disable capabilities for legacy components such as serial and parallel ports, as defined in Legacy Plug and Play Guidelines, available at http://www.pcdesguide.org/legacypnp/.

Note: Standard system devices are excluded from the Plug and Play requirement. The system can reserve static resources for devices such as programmable interrupt controllers (PICs) 1 and 2, timer (8254-2), keyboard controller (8042), real-time clock, DMA page registers, and DMA controllers 1 and 2. For IA-32 systems, these fixed resources are located at I/O addresses under 100h and can also include a NMI.

Also, this requirement does not apply to devices that are completely invisible to the operating system, such as out-of-band systems management devices or I2O hidden devices; however, these devices still must properly reserve resources using ACPI methods to avoid potential conflicts.

17. Unique Plug and Play ID is provided for each system device and add-on device

Required

Each device connected to an expansion bus must be able to supply its own unique identifier, as defined in the current Plug and Play specification for the bus that it uses. The following defines the specific requirements for Plug and Play device IDs:

  • Each separate function or device on the system board set must be separately enumerated. Therefore, each must provide a device identifier in the manner required for the bus it uses.
  • If a device on an expansion card is enumerated by the system firmware, it must have a unique ID and its own resources according to the device-ID requirements for the bus to which the card is connected. This includes devices that are separately enumerated on multifunction cards or multifunction chips.

The following are exceptions to the requirements for a unique Plug and Play ID:

  • Legacy devices attached to the Industry Standard Architecture (ISA) bus on the system board set do not have unique Plug and Play IDs—for example, serial ports, parallel ports, or PS/2-compatible port devices. The method for device identification is defined in Plug and Play ISA Specification, Version 1.0a, and the ACPI specification. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b.
  • Some multifunction devices (such as Super I/O) might include devices that do not have unique Plug and Play IDs or unique PCI Subsystem IDs, but that are supported by drivers provided with the Windows 2000 operating system.
  • A device such as a multifunction PCI device that supports a number of functions but uses only a single set of relocatable resources does not have to provide separate identifiers for each function included on the device.
  • Some devices are completely invisible to or are not managed by the operating system, such as out-of-band systems management devices or I2O system and I2O hidden devices. Such devices are exempt from this requirement, but these devices still must properly reserve resources using ACPI methods to avoid potential conflicts.

In addition, if an OEM uses a proprietary mechanism to assign asset or serial numbers to hardware, this information must be available to the operating system using Windows hardware instrumentation technology.

18. "PNP" vendor code is used only to define a legacy device’s Compatible ID

Required

All legacy devices not enumerated by the system board set interface must not use "PNP" in their vendor and device codes. The PNP vendor code is reserved for Microsoft and vendors whose hardware is specifically assigned a particular ID. Other hardware can use a PNP code only when defining a device’s Compatible ID (CID) and only after first indicating the device’s Hardware ID in the Plug and Play header.

Recommendation

Recommended: Use CIDs for devices that use device drivers provided with the Windows 2000 operating system, such as a standard COM port (PNP0500).


“Headless Server” Requirements

"Headless Server" Requirements

Windows Whistler provides native support for "headless server" operation on IA-32 platforms. Support for full headless server operation for IA-64 platforms will be available in a future version of Windows after Windows Whistler. The following guidelines describe requirements for hardware leveraging these capabilities.

19. IA-32 system provides headless server capabilities meeting Hardware Design Guide requirements

Required for Enterprise class systems

Recommended for Basic and SOHO class systems

To permit remote management of a system, it is required that all Enterprise class IA-32 servers provide headless server capabilities complying with at least one of the solutions described in guidelines #20, 21, and 22. This is recommended for Basic and SOHO class systems, and is expected to become a requirement for these classes in a future version of this guide.

The three cases that these guidelines describe are, respectively:

  1. The case where headless out-of-band remote management is provided by serial port hardware only.
  2. The case where such capabilities are provided by a management service processor that provides external serial support, either as a sole connection or in addition to other types of connections.
  3. The case where such capabilities are provided by a management service processor that provides no external serial connection capabilities.

20. IA-32 system that implements headless capabilities without management service processor provides serial headless support

Required if system implements headless support without a management service processor

This guideline addresses the minimum capabilities needed for serial headless server support if a system implements a solution for headless support but does not include a management service processor. This requirement is an optional solution to the basic requirement stated in "#19, IA-32 system provides headless server capabilities meeting Hardware Design Guide requirements."

20.1. IA-32 system without management service processor supports BIOS redirection of console output to the headless serial port

IA-32 systems must provide the redirection capabilities documented in "#13.4 IA-32 BIOS boot system firmware supports console redirection to a serial port, if serial headless server support is implemented in the system."

Recommendation

Recommended: Use COM1 as the headless serial port.

20.2. IA-32 system without management service processor provides properly configured legacy serial port

For use with the headless server capabilities of Windows Whistler, IA-32 systems must provide a legacy serial port that is addressable at either COM1 (03F8h) or COM2 (02F8h), configured to the default settings of 9600 bps, 8 bits, no parity, and 1 stop bit. This port must also comply with the requirements for legacy serial ports elsewhere in this document.

Note: Future versions of Windows will provide additional physical connection choices for headless servers.

20.3. IA-32 system headless connections are null modem cables that support Carrier Detect signal

Cables used for connection to a Windows Whistler headless server on a serial port must be null modem cables that provide support for the Carrier Detect signal. Carrier Detect is required because Windows will not provide console I/O if Carrier Detect is not active.

21. IA-32 system that implements management service processor and external serial headless capability supports required external serial port and remote system reset

Required if the service processor exposes a UART interface via hardware to the operating system or if the serial port is the only full-time management connection

This guideline addresses the minimum capabilities needed for headless server support with service processors that provide external serial capabilities. This requirement is an optional solution to the basic requirement stated in "#19, IA-32 system provides headless server capabilities meeting Hardware Design Guide requirements."

Management service processors that provide both serial and LAN-based full-time management connections but do not provide an internal 16550 UART hardware interface (i.e. Service Processor does not provide a serial port interface or the serial port interface is provided by a Windows driver and is not available before Windows is loaded) must provide at least the capabilities in this guideline for the serial connection (except 21.2), or must provide the capabilities outlined in #22 "IA-32 system that implements a management service processor but no external serial connection meets reset and display redirection requirements" for the alternate LAN-based management connection. It is recommended that service processors with both types of the above ports provide both sets of capabilities.

21.1. IA-32 system with management service processor and external serial headless capability supports BIOS redirection of console output, plus serial port and serial headless cabling requirements

Systems with service processors that provide external serial support must meet the requirements in guideline "#20. IA-32 system that implements headless capabilities without management service processor provides serial headless support," plus the additional requirements listed in this guideline.

21.2. IA-32 system with management service processor and external serial headless capability supports sharing of the service processor serial port with Windows

If a management service processor provides a serial port interface externally, this port must allow unconstrained communication between an external device (such as a management platform) and Windows. This communication path must be available as soon as the loader is called. The shared serial port must be locatable via the mechanism described in Serial Port Console Redirection Table.

Additionally, the service processor must comply with the requirements of Extensions to the VT100 Terminal Definition. The service processor may interrupt Windows’ use of the shared port per the mechanisms required in Extensions to the VT100 Terminal Definition. The serial port must not appear altered in any fashion from the perspective of Windows when the port is in use by the service processor. Also, the service processor’s output to the serial port must comply with Extensions to the VT100 Terminal Definition.

21.3. IA-32 system with management service processor and external serial headless capability supports remote system reset capabilities

The management service processor must support a remote system reset capability as described in Extensions to the VT100 Terminal Definition.

22. IA-32 system that implements a management service processor but no external serial connection meets reset and display redirection requirements

Required if system implements headless support with a management service processor

This requirement is an optional solution to the basic requirement stated in "#19, IA-32 system provides headless server capabilities meeting Hardware Design Guide requirements."

For enhanced out-of-band management capabilities, systems can provide a management service processor. This processor can enable such advanced capabilities as remote system reset and assistance with disaster recovery.

Note that an IA-32 system is not required to provide a management service processor. This guideline addresses the minimum capabilities needed for headless server support with service processors but no external serial connection capabilities.

The management service processor must support a remote system reset capability. This capability may be provided through OEM-specific mechanisms.

Recommendation

Recommended: Systems with service processors provide display redirection capabilities for both text and graphics modes.

23. Uninterruptible power supply that has pass-through legacy serial port supports sharing of pass-through serial port with Windows headless capabilities

Recommended

If an uninterruptible power supply (UPS) uses an external pass-through serial port interface, this port should allow unconstrained communication among the system for which the UPS provides backup power, a management platform, and Windows. The UPS may interrupt Windows’ use of the pass-through port per the mechanisms required in Extensions to the VT100 Terminal Definition.

Additionally, the UPS should comply with the requirements of Extensions to the VT100 Terminal Definition. The entire end-to-end pass-through serial path should present the serial signals from the platform under management to the management console as though from a serial port through a null modem cable as described in "#20.3 IA-32 system headless connections are null modem cables that support Carrier Detect signal."


Other Requirements

24. IA-32 system includes APIC support

Required

IA-32 servers must include Advanced Programmable Interrupt Controller (APIC) support that complies with ACPI 1.0b, implemented by including the Multiple APIC Description Table defined in Section 5.2.8 of ACPI 1.0b. Features such as targeted interrupts, broadcast interrupts, and prior-owner interrupts must be supported. The local APIC in a processor must be hardware enabled, all hardware interrupts must be connected to an IOAPIC, and the IOAPIC must be connected to local APIC in the processor (or processors). If multiple APICS, processors, or IOAPICs are present, then all components must meet this requirement.

Implementation of APIC support on server systems provides a greater number of IRQ resources, even within traditional server architectures.

25. IA-64 system includes SAPIC support

Required

An IA-64 system must include SAPIC support that complies with the 64-bit extensions to ACPI, implemented by including the Multiple SAPIC Description Table as defined in ACPI 2.0, Section 5.2.10.4.

25.1. IA-64 core chipset interrupt delivery mechanisms use SAPIC-compatible programming model

IA-64 interrupt delivery mechanisms must use a SAPIC-compatible programming model.

25.2. IA-64 system uses SAPIC-compatible programming model

Regardless of the hardware interrupt delivery mechanism, interrupt controllers in IA-64 servers must use a programming model compatible with the SAPIC extension for IA-64 processors defined in ACPI 2.0, Section 5.2.10.4.

26. IA-64 system supports message-signaled interrupts

Recommended

As the I/O subsystems in servers become more complex, the requirement to provide each PCI slot and device access to a nonshared interrupt line becomes increasingly more difficult and expensive to implement on the system board. Thus, providing support for message-signaled interrupts (MSI) as specified in PCI 2.2 provides an infrastructure to help alleviate this burden.

It is expected that the physical (non-MSI) interrupt mechanism will be supported in the system, but that the MSI will be present to facilitate enhanced expandability.

This recommendation will become a requirement in a future version of this guide.

27. System with no 8042 or other port 60h and port 64h based keyboard controller meets Hardware Design Guide requirements

Required

System designs that remove legacy (port 60h/port 64h) keyboard controllers, typically implemented using 8042 or similar controllers, must meet these requirements to function with Windows. Specifically, these systems must properly set Fixed ACPI Description Table Boot Architecture Flags as described in the ACPI specification and "Proposed ACPI Specification Changes for Legacy Free," available at http://www.microsoft.com/hwdev/onnow/download/LFreeACPI.doc. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b.

28. IA-32 system provides necessary ISR support

Required

IA-32 system designs that reduce the amount of legacy ISR support in conjunction with other legacy removal efforts (such as 8042 removal) must still provide the necessary ISRs required to boot IA-32 systems using BIOS. The minimum requirements include support for ISR 8h, 13h, and 19h (all functions), and ISR 15h, function E820h.


Chapter 3 Bus and Device Requirements

This chapter defines specific requirements for buses and devices provided in a Basic server system.

Tips for selecting I/O performance components. For manufacturers who want to select high-performance components for server systems, the following are design features to look for in I/O components:

  • The system has minimal or no reliance on embedded ISA or low pin count (LPC) and no ISA or LPC slots.
  • Adapter supports bus mastering.
  • PCI adapter properly supports higher-level PCI commands for efficient data transfer.
  • Drivers are tuned for 32-bit performance on an IA-32 system, and tuned for 64-bit performance on an IA-64 system. For example, 32-bit alignments on the adapter do not interface with 16-bit alignments on odd addresses, nor do 64-bit alignments interface with 32-bit alignments.
  • All devices and controllers must be capable of being identified and configured by software through the defined bus mechanisms.


I/O Bus Requirements

This section summarizes requirements for the I/O bus, with emphasis on requirements related to the PCI bus.

29. System provides an I/O bus based on industry standard specification

Required

Currently, for most systems, this requirement is met with PCI.

30. All PCI adapters function properly on system supporting more than 4 GB memory

Required

On IA-32 and IA-64 systems that provide support for more than 4 GB of system memory, all 32-bit and 64-bit PCI adapters in the system must be able to function properly. In addition, certain classes of adapters—such as those on the primary data path where the majority of network and storage I/O occurs—must also be able to address the full physical address space of the platform.

For 32-bit PCI adapters that will be used on the primary data path, this means that the adapter must be able to support the PCI Dual Address Cycle (DAC) command. Note that 10/100 Ethernet adapters and embedded 10/100 Ethernet devices do not need to support DAC; however, such devices must still function properly in these systems even if they do not implement DAC support. Any other 32-bit devices that do not support DAC and are configured on the same 32-bit PCI bus must not interfere with the ability of the devices that support DAC to address all of memory.

Additionally, all 32-bit PCI buses, host bridges, and PCI-to-PCI bridges must support DAC.

There are special considerations that system designers must address when using legacy devices, adapters, and bridges in systems that provide support for more than 4 GB of memory. For information about how Windows 2000 Advanced Server and Windows 2000 Datacenter Server behave in the case where a non-DAC capable bus is detected on a system that supports more than 4 GB of memory, please see the white paper at http://www.microsoft.com/hwdev/newPC/PAEdrv.htm.

31. All PCI bridges in an IA-64 system support DAC

Required

For IA-64 systems, all PCI bridges on the motherboard must support DAC for inbound access, and DAC-capable devices must not be connected below non-DAC-capable bridges, for example, on adapter cards.

New 64-bit adapters must be DAC capable.

This DAC requirement does not apply to outbound accesses to PCI devices. However, for systems where DAC is not supported on outbound accesses to PCI devices, the system firmware must not claim that the bus aperture can be placed above the 4-GB boundary.

32. System supports a 64-bit PCI bus architecture

Required for all IA-64 systems

Required for all IA-32 systems that support more than 4 GB of system memory

All 64-bit PCI adapters must be able to address any location in the address space supported by the platform.

The server system must support a 64-bit PCI bus if the server has 64-bit processors or has the capability to support more than 4 GB of physical memory.

Recommendation

Recommended: Support for a 66 MHz PCI bus.

33. PCI bus and devices comply with PCI 2.2 and other requirements

Required

If PCI is present in the system, the PCI bus and PCI expansion connectors must meet the requirements defined in the PCI 2.2 specification, plus any additional PCI requirements in this guide. The system must also support the addition of PCI bridge cards, and all PCI connectors on the system board set must be able to allow any PCI expansion card to have bus master privileges.

All server systems also must meet the PCI requirements defined in this section, which include requirements to ensure effective Plug and Play support. In particular, see the required implementation for PCI 2.2 Subsystem Vendor IDs in guideline "#45. Device IDs include PCI Subsystem IDs."

Servers that provide support for more than 4 GB of physical memory and that provide 32-bit PCI bus capabilities must provide support for the PCI DAC command on 32-bit PCI buses, host bridges, and PCI to PCI bridges, and specific classes of PCI adapters as described in guideline "#30. All PCI adapters function properly on system supporting more than 4 GB memory."

Recommendation

Recommended: PCI controllers should be implemented as peer bridges to provide more effective bus bandwidth.

Note on PCI to PCI bridge configuration: The system firmware must correctly configure PCI-to-PCI bridges if the system has a VGA device behind a bridge. Specifically, the system firmware must correctly set the VGA Enable and ISA Enable bits on the bridges, to prevent the bridges from conflicting with each other.

Additional details with illustrated examples of correct configurations of PCI-to-PCI bridge devices are provided in the white paper, "Configuring PCI-to-PCI Bridges with VGA Cards," available on the web at http://www.microsoft.com/hwdev/pci/vgacard.htm.

34. PCI devices in an IA-64 system support message-signaled interrupts

Recommended

As the I/O subsystems in servers become more complex, the requirement to provide each PCI slot and device access to a nonshared interrupt line becomes increasingly more difficult and expensive to implement on the system board. Thus, requiring the PCI devices in IA-64 systems to provide support for MSI as specified in PCI 2.2 will provide an infrastructure to help alleviate this burden.

This recommendation will become a requirement in the next version of this guide.

35. System makes a best effort to provide each PCI slot and device type access to a non-shared interrupt line

Required

System designers must make a best effort to provide access to non-shared interrupt lines by meeting these conditions:

  • The system design enables all PCI slots and PCI device types to obtain exclusive use of an interrupt line when exclusive access increases performance.
  • Dedicated PCI interrupts must not use vectors from ISA bus interrupts.

The high-end and low-end commodity server platforms present certain design challenges. For high-end servers, PCI 2.2 taken by itself imposes a limitation for Intel Architecture-based systems because the values written to the Interrupt Line register in configuration space must correspond to IRQ numbers 0-15 of the standard dual 8259 configuration, or to the value 255 which means "unknown" or "no connection." The values between 15 and 255 are reserved. This fixed connection legacy dual 8259 configuration, if examined alone, constrains Intel Architecture-based systems, even when they use sophisticated interrupt-routing hardware and APIC support. For low-end servers, some core logic offerings provide little or no interrupt-routing support, and designers implement rotating access to interrupt resources using simple wire-OR techniques, such as those illustrated in the implementation note in Section 2.2.6 of PCI 2.2.

Windows 2000, with its support for both MPS 1.4 and ACPI on 32-bit platforms and ACPI on IA-64 systems, uses mechanisms beyond the legacy methods of routing all PCI interrupts through the legacy cascaded 8259 interrupt controllers to determine proper allocation and routing of PCI bus IRQs. This Windows 2000 capability allows use of interrupts beyond the 0-15 range permitted by the strict reading of the current PCI 2.2 specification language for Intel Architecture systems. System designers should include sufficient interrupt resources in their systems to provide at least one dedicated interrupt per PCI function for embedded devices and one interrupt per PCI INTA# - INTD# line on a PCI slot. This will become a requirement for all servers in a future version of this guideline.

When system designers cannot provide a non-shared interrupt line to a particular PCI device or slot because of the situations cited, the server system’s documentation must explain clearly to the end user of the system how interrupt resources are allocated on the platform and which devices cannot avoid sharing interrupts. System designers may provide this documentation or information as they deem most appropriate for their product. Some possible mechanisms include:

  • Documenting slots according to the order in which cards should be inserted to prevent interrupt sharing for as long as possible
  • Providing information on interrupt routing and sharing via system setup programs

Some instances need additional clarification to fit within the context of this guideline. At the system designer’s discretion, PCI devices can share an interrupt line under the following conditions:

  • One system interrupt line can be shared by all PCI devices on an expansion card. In other words, PCI INTA# - INTD# may share the use of a single system interrupt directed to a given PCI expansion slot. This instance of line sharing applies to both expansion card designs based on PCI multifunction devices and to expansion card designs using PCI-to-PCI bridges.
  • Devices can share an interrupt in a design where a system-board set has multiple instances of a given PCI device performing a specific function.

For example, two embedded PCI small computer system interface (SCSI) controllers on a system board can share a single system interrupt line. A single line can be shared when the functions of the devices are very similar, such as a case where one embedded SCSI controller may be dedicated to "narrow" (8-bit wide) SCSI devices and the other is dedicated to "wide" (16-bit wide) SCSI devices.

On the other hand, an embedded SCSI controller may not share an interrupt with an embedded network adapter on a system board, because they perform two different functions within the system and could contend for the shared interrupt in ways that will reduce overall system performance.

36. System does not contain ghost devices

Required

A computer must not include any ghost devices, which are devices that do not correctly decode the Type 1/Type 0 indicator. Such a device will appear on multiple PCI buses.

A PCI card should be visible through hardware configuration access at only one bus/device/function coordinate.

37. PCI-to-PCI bridges comply with PCI to PCI Bridge Specification 1.1

Required

PCI-to-PCI bridges must comply with PCI to PCI Bridge Specification, Revision 1.1.

38. System uses standard method to close BAR windows on nonsubtractive decode PCI bridges

Required

Setting the base address register (BAR) to its maximum value and the limit register to zeroes must effectively close the I/O or memory window references in that bridge BAR.

39. PCI devices do not use the <1 MB BAR type

Required

Devices must take any 32-bit BAR address.

Recommendation

Recommended for Enterprise class servers: Devices on a 64-bit PCI bus must take any 64-bit BAR address.

40. PCI devices decode only their own cycles

Required

PCI devices must not decode cycles that are not their own to avoid contention on the PCI bus. Notice that this requirement does not in any way prohibit the standard interfaces provided for by the PCI cache support option discussed in PCI 2.2, which allows the use of a snooping cache coherency mechanism. Auxiliary hardware that is used to provide non-local console support is permitted within the scope of this requirement.

41. VGA-compatible devices do not use non-video I/O ports

Required

A VGA-compatible device must not use any legacy I/O ports that are not set aside for video in the PCI 2.2 specification.

Recommendation

Recommended: Device includes a mode that does not require ISA VGA ports to function.

42. PCI chipsets support Ultra DMA (ATA/33, minimum)

Required

For servers that implement PCI ATA connectivity, PCI chipsets must implement DMA as defined in ATA/ATAPI-5, and implement Ultra DMA (also known as Ultra-ATA) as defined in the ATA-5 standard.

43. Functions in a multifunction PCI device do not share writable PCI configuration space bits

Required

The operating system treats each function of a multifunction PCI device as an independent device. As such, there can be no sharing between functions of writable PCI configuration space bits (such as the Command register).

44. Devices use the PCI configuration space for their Plug and Play IDs

Required

PCI 2.2 describes the configuration space used by the system to identify and configure each device attached to the bus. The configuration space is made up of a 256-byte address space for each device, and it contains sufficient information for the system to identify the capabilities of the device. Configuration of the device is also controlled from this address space.

The configuration space is made up of a header region and a device-dependent region. Each configuration space must have a 64-byte header at offset 0. All the device registers that the device circuit uses for initialization, configuration, and catastrophic error handling must fit within the space between byte 64 and byte 255.

All other registers that the device uses during normal operation must be located in normal I/O or memory space. Unimplemented registers or reads to reserved registers must complete normally and return zero. Writes to reserved registers must complete normally, and the data must be discarded.

All registers required by the device at interrupt time must be in I/O or memory space.

45. Device IDs include PCI Subsystem IDs

Required

The Subsystem ID (SID) and Subsystem Vendor ID (SVID) fields are required to comply with PCI 2.2.

The device designer is responsible for ensuring that the SID and SVID registers are implemented. The adapter designer or system-board designer who uses this device is responsible for ensuring that these registers are loaded with valid non-zero values before the operating system accesses this device.

  • To be valid, the SVID must be provided by the PCI SIG.
  • Values in the SID field are vendor-specific, but to be valid must be unique to a subsystem configuration. For example, if two system boards have the same graphics chipset, but one supports an internal expansion connector while the other has added functionality such as a TV output function, then each must load the SID field with a different, unique value.

For implementation details, see "PCI Device Subsystem IDs and Windows" at http://www.microsoft.com/hwdev/devdes/pciids.htm.

46. Interrupt routing is supported using ACPI

Required

The system must provide interrupt routing information using a _PRT object, as defined in Section 6.2.3 of ACPI 1.0b (for IA-32 systems) and Section 6.2.8 of ACPI 2.0 (for IA-64 systems). It is important to note that the _PRT object is the only method available for interrupt routing on IA-64 systems.

47. System that supports hot swapping or hot plugging for any PCI device uses ACPI-based methods

Required

Windows Whistler supports dynamic enumeration, installation, and removal of PCI devices if the implementation strictly complies with the hardware insert/remove notification mechanism as defined in Section 5.6.3 of ACPI 1.0b.

Other hot-plug implementations will work under Windows 2000 only if there is a supported hardware insert/remove notification mechanism, such as a bus standard. An example of an implementation based on an appropriate standards-based notification mechanism is a CardBus bus controller.

Note that systems implementing hot-pluggable PCI capabilities compliant with the PCI Hot-Plug Specification, Revision 1.0 must still provide the hardware insert/remove notification mechanism as defined in Section 5.6.3 of ACPI 1.0b.

For more information about Windows 2000 and PCI Hot Plug, see http://www.microsoft.com/hwdev/pci/hotplugpci.htm.

48. All 66-MHz and 64-bit PCI buses in a server system comply with PCI 2.2 and other requirements

Required

If PCI buses that are 66 MHz, 64-bit, or both are present in a server system, all devices connected to these buses must meet the requirements defined in PCI 2.2 or later.

Recommendation

Recommended: 33-MHz/32-bit PCI devices and 66-MHz/64-bit PCI devices should be placed on separate PCI buses to allow the best use of I/O bandwidth in a server system.

49. All PCI devices complete memory write transaction (as a target) within specified times

Required

All devices must comply with the PCI 2.2 Maximum Completion Time requirement. Complying with this requirement ensures shorter transaction latencies on PCI, allowing more robust handling of isochronous streams in the system.

50. All PCI components comply with PCI Bus Power Management Interface specification

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
Enterprise: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
SOHO: | Required | Required | Required

The PCI bus, any PCI-to-PCI bridges on the bus, and all add-on capable devices on the PCI bus must comply with PCI Bus Power Management Interface Specification, Revision 1.1 or later. This includes correct implementation of the PCI configuration space registers used by power management operations, and the appropriate device state (Dx) definitions for the PCI bus, any PCI-to-PCI bridges on the bus, and all add-on-capable devices on the PCI bus. ACPI is not an acceptable alternative.

51. System that supports S3 or S4 state provides support for 3.3Vaux

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Recommended | Recommended
SOHO: | Required | Required | Required

System support for delivery of 3.3Vaux to a PCI bus segment must be capable of powering a single PCI slot on that bus segment with 375 mA at 3.3V and it must also be capable of powering each of the other PCI slots on the segment with 20 mA at 3.3V whenever the PCI bus is in the B3 state.

In the case of systems with multiple PCI bus segments, delivering 3.3Vaux to one PCI bus segment does not mean that all PCI bus segments will be required to implement delivery of 3.3Vaux. However, if a system with multiple PCI bus segments provides 3.3Vaux to one or more segments and not to all segments in the system, these capabilities must be clearly marked and documented so that the end user can determine which slots support this capability. Examples of methods for indicating which slots support 3.3Vaux include icons silk-screened on system board sets, slot color-coding, and chassis icons.

Systems must be capable of delivering 375 mA at 3.3V to all PCI slots on a power-managed bus segment whenever the PCI bus is in any "bus powered" state: B0, B1, or B2.

52. PCI bus power states are correctly implemented

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
Enterprise: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
SOHO: | Required | Required | Required

The PCI bus must be in a bus state (Bx) no higher than the system sleeping state (Sx). This means that if the system enters S1, the bus must be in B1, B2, or B3. If the system enters S2, the bus must be in B2 or B3, and if the system enters S3, the bus must be in B3. Of course, in S4 and S5, the system power is removed, so the bus state is B3. A PCI bus segment must not transition to the B3 state until all downstream devices have transitioned to D3.

Control of a PCI bus segment’s power is managed using the originating bus bridge for that PCI bus segment.

  • For CPU-to-PCI bridges, these controls must be implemented using ACPI or the PCI Power Management Interface Specification, Revision 1.1 (PCI-PM 1.1) or later.
  • For PCI-to-PCI bridges, these controls must be implemented in compliance with PCI-PM 1.1 or later.

53. Software PCI configuration space accesses on an IA-64 system use SAL procedures

Required

In particular, access to PCI configuration space must use mechanisms that do not directly reference PCI configuration space but that instead use the services provided by the SAL or other services which in turn call SAL services.

54. PCI-X buses and devices, if present, meet requirements for device and driver support

Required

Systems are not required to provide PCI-X capabilities. However, a system that implements PCI-X must comply with the PCI-X Addendum, Revision 1.0 or later specification, plus other relevant PCI device and driver requirements defined in this guide.

Recommendation

Recommended: PCI-X devices should not be mixed with PCI devices on a PCI-X bus in order to ensure optimum use of system I/O bandwidth.

55. InfiniBand fabric connections, fabrics, and devices, if present, meet requirements for device and driver support

Required

Systems are not required to provide InfiniBand capabilities. However, a system that implements InfiniBand must comply with the requirements defined in the version 1.0 or later specification, plus other relevant InfiniBand device and driver requirements as defined by this guide.


USB Requirements

This section summarizes requirements for Universal Serial Bus.

56. System includes USB controller with at least one USB port

Required

To facilitate the eventual migration away from legacy connections for keyboards, pointing devices, serial devices, and parallel devices, server designers must integrate USB functionality into their server platforms with the minimum support being one USB controller with at least one available USB port. USB ports must comply with the related USB requirements in this guide.

57. All USB hardware complies with USB 1.1

Required

All USB hardware present on a server system and USB devices, including hubs, must comply with USB 1.1 or later.

When a system has more than one host controller, each host controller must provide full bandwidth and isochronous support. Host controllers should be located on PCI to meet this requirement. The host controller providing USB 1.1 functionality must comply with the specifications for either Open Host Controller Interface (OpenHCI), published by Compaq, Microsoft, and National Semiconductor, or Universal HCI (UHCI), published by Intel. Hardware manufacturers who design to one of these specifications are not required to provide an additional Windows 2000 device driver for their host controller.

Multiple OpenHCI and UHCI USB controllers are supported concurrently by the operating system.

58. USB devices and drivers support maximum flexibility of hardware interface options

Required

Device and driver designs must provide maximum flexibility for interface options to allow user-preference coordination by the operating system or other resource managers. This flexibility allows graceful use of multiple simultaneous devices and applications in a dynamic environment.

Minimum requirements consist of the following:

  • Must provide multiple alternate settings for each interface where any alternate setting consumes isochronous bandwidth.
  • Must not use isochronous bandwidth for alternate setting 0. Devices must consume bandwidth only when they are in use.

59. System and devices comply with USB power management requirements

Required

The server system must comply with the power management requirements in USB 1.1 or later. In addition, USB devices must comply with the Interface Power Management feature in the USB Common Class Specification, Revision 1.1 or later.

60. USB devices comply with their related USB device class specifications

Required

A USB peripheral that fits into one of the USB device class definitions must comply with the related USB device class specification. USB class drivers in the operating system are implemented to support compliant devices in each particular class. Class driver extensions and WDM allow hardware manufacturers to innovate and differentiate their products while still complying with class specifications in their base operational modes.

61. USB hubs are self-powered

Required

This requirement does not apply for hubs integrated into keyboards. To minimize USB power consumption requirements, bus-powered hubs must provide ports that can be individually power switched. This contributes to the goal of reducing overall system power consumption.

62. USB devices install without pre-loading software

Required

A user must not be required to install software before hot-plugging a USB device. Instead, the user must be able to hot-plug the USB device, and then load any software in response to the operating system detection of the newly-attached device.


Other Bus Requirements

This section summarizes requirements related to other buses.

63. Any subsystems implementing I2O comply with standards and other requirements

Required

If I2O is implemented in a system, it must meet the requirements defined in this guide and in the I2O Architecture Specification, Version 1.5 or later, available at http://www.i2osig.org.

If I2O is implemented on a system, the system firmware must support I2O devices for the following configurations:

  • An I2O-capable system that includes no I2O-intelligent devices, whether provided on the system board set or as add-on devices. The system can have an installed adapter that is I2O-ready or I2O-compliant, and the system firmware must initialize the device as a multifunction device. The system cannot boot from this I2O device, because the system firmware does not support initialization of I2O bootable device.
  • An I2O-ready system that has some sort of intelligence on the system board set or on an add-on adapter that enables sending and receiving messages, as defined in the I2O specification. This intelligence can be an off-the-shelf processor, an application-specific integrated circuit (ASIC) when it is on the system board set, or it can be included as an add-on adapter. In these cases, the system firmware must support initializing and configuring the device, including support for multifunction PCI. Initialization and configuration of a PCI device does not imply that the system firmware supports compliant I2O initialization of boot devices or that the system can boot from an I2O device.
  • An I2O-compliant system that includes support for initializing and booting from I2O devices, whether provided on the system board set or as add-on devices. The system as a whole must be able to pass I2O compliance testing with Windows 2000.

64. System does not include ISA or LPC expansion slots

Required

No ISA or LPC expansion slots are allowed in servers designed to comply with these guidelines. The benefits of an ISA-free system include improved performance, easier and more stable system configuration, and lower support costs. There are no permitted exemption cases.

65. System does not include embedded ISA or LPC network adapters, storage controllers, or graphics adapters

Required

The benefits of an ISA-free system include improved performance, easier and more stable system configuration, and lower support costs.

66. System does not include ISA or LPC expansion devices

Required

An ISA or LPC expansion device in this context is defined as being an expansion adapter or device installed in an ISA or LPC slot.

No ISA or LPC expansion devices are allowed. There are no permitted exemptions to this requirement.

67. System that supports Winsock Direct connectivity meets requirements for device and driver support

Required

Systems are not required to provide Winsock Direct (WSD) connectivity capabilities. However, those systems that do must meet the following guidelines:

  • Provide a reliable transport through the combination of WSD hardware and software.

The Winsock Direct Specification is provided in the Windows 2000 DDK, and is available online at
http://www.microsoft.com/DDK/DDKdocs/Win2k/wsdpspec_1h66.htm.

Provide the necessary hardware, software, and driver support to facilitate access via the fast alternate paths. This would include the "normal" Network Driver Interface Specification (NDIS) 5.0-compliant miniport, plus a System Area Network Windows Sockets (Winsock) provider and a System Area Network Management driver. Installers for these components and any needed network management software components must also be provided.

Hardware characteristics and provider guidelines are defined in the Windows 2000 DDK, and are available online at http://www.microsoft.com/DDK/DDKdocs/Win2k/wsd_hw_0aur.htm.

Additionally, hardware must have page tables to translate user addresses to physical addresses. This allows direct user-mode access to the hardware, permitting endpoint resources to be mapped directly into the address space of a user-mode process. This permits application processes to post messaging requests directly to the hardware, with no system calls and no intermediate data copying.

Notes:
1. Winsock Direct and associated hardware are targeted for use in physically secure computer systems and environments, such as those associated with "back end" or "glass house" computing environments.

2. Vendors who are sizing their page table hardware should take into account the number of simultaneous connections expected to be supported by the hardware in conjunction with the applications using this connection. The number of simultaneous connections may range widely (from thousands to hundreds). In addition to the number of simultaneous connections, designers need to take into account the page size (specific to the host computer system) and whether the connection is registering memory for RDMA operations in addition to memory registered for messages. Cards that support thousands of simultaneous connections will need to map tens of thousands of page table entries.


Device Requirements

This section summarizes requirements for the system devices and peripherals provided with server systems.

Note: It is recognized that administrators might not want a keyboard, mouse, or monitor attached directly as a local console to working servers. However, these devices, headless server capabilities, or ability to install the operating system using the Windows Remote Install Server are minimum requirements for installation of the operating system. Additionally, local console, headless server, or both capabilities are necessary to provide maintenance, diagnostic, and troubleshooting capabilities throughout the life of a server.

68. Device driver and installation meet Hardware Design Guide requirements

Required

Each device must have drivers for the Windows 2000 operating system. The manufacturer does not need to supply a driver if the device functions fully and correctly using a driver provided with the operating system.

If the manufacturer supplies drivers, the device drivers and installation requirements include the following.

68.1 All devices and drivers meet requirements defined in the guide.

Each device included in a server system must comply with the requirements defined in this section and must have supporting 32-bit (for IA-32 systems) or 64-bit (for IA-64 systems) device drivers. The installation and loading of a driver must not reduce or eliminate functionality of other devices installed on the system. The following are also required:

  • Every driver (or minidriver) must support Plug and Play and power management I/O request packets (IRPs).
  • Real-mode or 16-bit protected-mode components must not be provided to operate under Windows 2000. Only 32-bit protected-mode components are installed on IA-32 systems. All devices in IA-64 systems must have 64-bit Windows 2000-compatible drivers.
  • Any device with WDM-based operating system support must have a manufacturer-supplied WDM minidriver or use the driver support provided with the operating system.

68.2 All configuration settings are stored in the registry.

The driver must not use INI files for configuration settings. The driver must also include correct provider, version, and copyright entries. This information is displayed in the user interface.

68.3 Files have correct identifiers and are stored in the correct locations.

The correct minidriver and any other manufacturer-supplied files specified in the device’s INF must be installed in the correct location.

For manufacturer-provided files, the vendor must not be identified as Microsoft; all other copyright and version information must be correct for the manufacturer.

Driver files provided by the vendor must not use the same file names used by files included in Microsoft operating systems and provided as either retail or OEM products, unless specifically agreed upon with Microsoft.

68.4 Driver installation and removal use methods defined in the Windows 2000 DDK.

The device driver must be removable using Windows-based software by using either the Windows Control Panel option for removing devices or its own remove utility. For information, see "Setup, Plug & Play, Power Management" in the Windows 2000 DDK.

However, any software applications included with the device can be installed using an alternate Windows-based installation method as defined in the Microsoft Platform Software Development Kit (SDK). Also, any software components and registry entries installed during driver installation must be removed during driver removal.

68.5 Driver supports unattended installation.

It must be possible for a user to install a device’s driver without being present. This unattended installation can be done using a mechanism such as a script or special software for supplying the required parameters.

68.6 Windows Help file is provided if special driver parameters are used.

This requirement ensures that the user can correctly change settings. The device’s installation routine must install the Help file as part of the setup program. The user interface for the device’s dialog boxes must display the correct Help file; the Help file must contain relevant information to assist the user. The guidelines for implementing Help are defined in the Microsoft Platform SDK.

69. Keyboard and mouse connections meet requirements for bus and device classes

Required

These requirements, which depend on the type of connection designed into the system, ensure that all Plug and Play requirements are met and that Microsoft drivers support this device.

If a PS/2-style keyboard port is used, the following requirements must be met:

  • Comply in full with requirements in the IBM Personal System/2 specifications
  • Use IRQ 1 (via PIC or APIC) to interrupt the processor
  • Map the I/O address ports to 60h and 64h.
  • Return expected scan codes, including send ID (0F2h) and response ACK (0FAh), plus 2-byte ID.

If a PS/2-style mouse port is used, the following requirements must be met:

  • Comply in full with requirements in the IBM Personal System/2 specifications.
  • Use a device with an 8042-compatible interface to the keyboard controller function to ensure compatibility with Windows 2000. In most cases, the existing 8042 keyboard port is sufficient.
  • The mouse port must assert an interrupt that is distinct from the keyboard interrupt.
  • Return expected codes, including send ID (0F2h) and response ACK (0FAh) + 1-byte ID.

If a USB connection is used, the following requirements must be met:

  • Comply with USB 1.1 or later.
  • Comply with USB Human Interface Device Class Specifications, Version 1.1 or later.
  • Implement minidriver support based on WDM HID class support in the operating system, as defined in "Drivers for Input Devices" the Windows 2000 DDK.

If a USB keyboard is the sole keyboard implementation, the system must provide boot support as specified in "Startup Support Requirements" of Chapter 2, "System Component Requirements," and as defined in Universal Serial Bus PC Legacy Compatibility Specification, Version 0.9 or later. This support must provide the ability for the user to enter the system’s firmware-based setup program and provide enough functionality to get a USB-aware operating system installed and booted.

70. Serial port adapter meets device class specifications for its bus

Required

A serial port implementation that uses a non-legacy bus must meet the specific device class requirements for that bus. For example, a USB to serial adapter must comply with all related USB specifications, including:

  • USB 1.1 or later.
  • USB Class Definition for Communication Devices, Version 1.0 (CDC 1.0)or later.

The "Standard Serial Interface Circuit Emulation" appendix in USB CDC 1.0 specifically addresses serial-port compatibility.

If a legacy serial port is implemented in a server system, it must meet the following requirements:

  • A 16550A buffered Universal Asynchronous Receiver/Transmitter (UART) or equivalent buffered legacy serial port is required to support high-speed communications while reducing the CPU requirements for servicing the device. The device must be able to support 115.2K baud.
  • A legacy serial port must provide flexible resource configuration and complete dynamic disable capabilities as defined in Plug and Play External COM Device Specification, Version 1.0. Two IRQs are required for each port implemented.
  • In the event of an irreconcilable conflict with other serial ports on the system, a legacy serial port must be capable of being disabled by Plug and Play software. This capability allows at least one of the two conflicting serial ports to operate correctly.
  • The firmware must configure at least one serial port to use either 2F8h or 3F8h. This requirement allows the port to be treated as a boot device by the firmware so that components can use the port for diagnostic purposes in the event that system debugging is required by either the BIOS or the operating system.

Recommendation

The following are the recommended resource settings for non-PCI devices:

  • Four I/O locations for each port (standard ISA I/O addresses are 3F8h, 2F8h, 3E8h, and 2E8h). Using the standard addresses ensures the proper functioning of software that directly addresses these locations.
  • Two IRQ signals (standard is PIC-based IRQ 3, IRQ 4). Support of the standard IRQ signals ensures the proper functioning of software written for systems that use standard IRQ signals.
  • If two serial ports are implemented in the system, the following IRQ assignments are recommended:
  • For serial port A: selection between PIC-based IRQ 4 and IRQ 11.
  • For serial port B: selection between PIC-based IRQ 3 and IRQ 10.

71. IA-64 system does not include parallel port

Required

64-bit Windows does not provide native legacy parallel port support. Parallel ports must not be present in IA-64 systems.

72. If present on IA-32 system, legacy parallel port meets requirements for bus and device classes

Required for all IA-32 server types, with ECP support Required for SOHO servers

This requirement presents information that is useful for system designers who want to incorporate parallel port support in their server designs. There is no requirement that a parallel port be present on a server; designers are strongly discouraged from incorporating parallel ports based on legacy parallel port technologies. However, if a parallel port is present on a server, then it must meet the applicable requirements in this guideline.

In addition to other capabilities listed here, the parallel port on a SOHO system must support the ECP protocol as defined by the IEEE 1284-1994 specification. This capability allows connections with higher-speed parallel peripherals.

If implemented in a server system, a legacy parallel port must provide flexible resource configuration following the Plug and Play Parallel Port Device Specification, Version 1.0b. Resource requirements must be met for each device of this type on the system. The requirements cannot be split between two ports on the system.

For non-PCI devices, the minimum resource requirements for each parallel port on the system are as follows:

  • The parallel port must support ISA I/O addresses of 378h and 278h, plus 3BC or a vendor-assigned I/O address. Using these standard I/O addresses ensures proper functioning of software written for operating systems that directly address these locations.

Recommendation

Recommended: Map the base I/O address to four additional locations.

  • The parallel port must support PIC-based IRQ 5 and IRQ 7. Using these standard IRQs ensures proper functioning of software written for operating systems that use standard IRQ signals.

Recommendation

Recommended: Support five additional IRQ signals.

  • The parallel port must support two unique DMA channel selections if its design supports block data transfers to memory using DMA controllers. Notice also that the DMA function will not work on a parallel port without an IRQ because the end of a DMA transfer is signaled by an interrupt.
  • To ensure Plug and Play support for resolution of resource conflicts, a full list of options for all possible configuration combinations must be enumerated, including:
  • Options for both extended capabilities port (ECP) mode, which requires an I/O address, an IRQ, and a DMA selection, and standard LPT mode, which requires only an I/O address.
  • Options that specify only the I/O address, which allows Windows 2000 to assign the IRQ and DMA channel.

On all ACPI-based systems, Windows 2000 obtains information on the parallel port base addresses through the ACPI tree (for parallel ports implemented on the system board set rather than on an expansion card on an expansion bus).

A legacy parallel port implemented in a server system must also meet the following requirements:

  • Enhanced parallel port (EPP) support does not use restricted I/O addresses. Some EPP implementations require eight contiguous I/O ports. If EPP support is implemented, the hardware cannot use the ISA I/O address 3BCh as a base I/O address because VGA devices require use of port 3C0h.
  • Compatibility, nibble mode, and ECP protocols meet IEEE 1284-1994 specifications. Support for a parallel port must include the compatibility mode and nibble mode protocols required by the IEEE 1284-1994 specification for minimum compliance. This support allows other IEEE 1284-compliant devices to be connected without problems.

Recommendation

Recommended: Legacy parallel port supports the ECP protocol as defined by IEEE 1284, allowing connections with higher-speed parallel peripherals. However, if the port can support the compatibility and nibble mode protocols as described earlier, it complies with the Basic and Enterprise class guidelines that allow connection of other IEEE 1284-compliant devices.

  • Port connectors meet the minimum requirements defined in the IEEE 1284-I specifications. IEEE 1284-I–compliant ports must use a standard DB25 connector found on existing system parallel port designs. This connector is called an IEEE 1284-A connector in the specification.

IEEE 1284-II–compliant ports must use an IEEE 1284-C connector. This connector is used on both the port and the peripheral device.

  • IEEE 1284 peripherals have Plug and Play device IDs. The device ID is described fully in the IEEE 1284 specification. All characters in the device identification string must consist only of ASCII values 20h–7Fh. The device identification string consists of a leading zero, a hexadecimal value that represents the length of the string, and then a set of fields, in ASCII, with a unique identification string.

In addition to the requirements specified in the Plug and Play Parallel Port Device Specification, Version 1.0b, the device ID string must contain the following keys, at a minimum. The keys are case sensitive and can be abbreviated in INF files as indicated.

Required key | Abbreviated string
MANUFACTURER | MFG
MODEL | MDL
CLASS | CLS
DESCRIPTION | DES

All MANUFACTURER and MODEL key values must remain unique for each manufacturer. All MANUFACTURER, MODEL, CLASS, and DESCRIPTION key values must remain static for a specific unit; ID values do not change for different hardware configurations. For example, a user adding a memory module to a printer should not change the MODEL key value reported as part of the device identifier. However, if the user adds memory by installing an upgrade kit that requires a different driver or requires the existing driver to behave differently, then changing the MODEL value is acceptable as part of the upgrade installation process.

The CLASS key describes the type of parallel device. The CLASS key can contain the values PRINTER, MODEM, NET, HDC, PCMCIA, MEDIA, FDC, PORTS, SCANNER, or DIGCAM. HDC refers to hard disk controller. MEDIA refers to any multimedia device. FDC refers to floppy disk controller.

The DESCRIPTION key is an ASCII string of up to 128 characters that contains a description of the device that the manufacturer wants to have presented if a device driver is not found for the peripheral.

For information, see "How Does Setup Select a Driver For a Device?" in the Windows 2000 DDK.

Recommendation

Recommended: The CID key can provide a value that exactly matches a peripheral name supported by a device driver shipped with Windows 2000 Server. The value must match a value listed in the device’s INF file.

73. USB-to-printer port adapters comply with USB specifications

Required

A USB to printer port (IEEE 1284, or "parallel") adapter must comply with all related USB specifications, including:

  • USB 1.1 or later.
  • Universal Serial Bus Class Definition for Printing Devices, Version 1.0 or later.

74. System includes emergency repair support

Required

If an OEM does not provide a floppy disk drive for this purpose, an alternate emergency repair method must be provided.

Recommendation

Recommended: Floppy disk support is recommended for emergency repair disk purposes. If a floppy disk drive is provided, the recommended support should be a solution based on an external bus, supporting migration away from legacy devices. If implemented as an ATA floppy drive, the drive must comply with ARMD 1.0 or later.

75. Primary graphics adapter on IA-64 system meets minimum requirements

Required

At a minimum, the adapter must support 800 × 600 × 256 color, following the VESA monitor timing standards and guidelines for this mode.

The adapter must also work normally with the default VGA mode driver, which is required for installing the operating system, so the primary adapter must support 4-bit planar VGA mode.

76. Primary graphics adapter on IA-32 system, if present, meets minimum requirements

Required

Server systems which meet the requirements in this design guide for 32-bit Windows "headless server" capabilities are not required to supply a local console primary graphics adapter. However, if a primary graphics adapter is present in the system, at a minimum, the adapter must support 800 × 600 × 256 color, following the VESA monitor timing standards and guidelines for this mode.

The adapter must also work normally with the default VGA mode driver, which is required for installing the operating system, so the primary adapter must support 4-bit planar VGA mode.


Chapter 4 Networking and Communications Requirements

This chapter defines basic feature requirements for network adapters and other communications hardware. See also the related requirements for remote new system setup and service boot support using DHCP and TFTP as defined in "Manageability Requirements" of Chapter 7, "Reliability, Availability, and Serviceability Requirements."

In this guide, all network communications devices are based on the same NDIS 5.0 requirements, which includes requirements for power management and Plug and Play capabilities. NDIS 5.0 represents a number of extensions to the interface described in NDIS 3.0 and 4.0. The basic requirements, services, terminology, and architecture of these earlier versions also apply to NDIS 5.0.

The NDIS architecture is included in Windows 2000 and is documented in "Network Drivers" in the Windows 2000 DDK. For additional background information about NDIS 5.0, see the web site at http://www.microsoft.com/hwdev/network/.

Notes:

1. References to adapters, network interfaces, and so on in this chapter should be taken to apply to add-on network adapter cards, network implementations on the system board, and external network interfaces equally and without preference for any of these types of implementation, unless otherwise noted.

2. This design guide does not contain requirements for Bluetooth devices. However, future versions of Windows operating systems will use Bluetooth technology as a wireless external bus, rather than as a wireless networking technology. Therefore, Bluetooth devices are not subject to the requirements contained in this chapter; in particular, they do not require NDIS drivers.


Network Adapter Requirements

This section describes the requirements for network adapters. Many of these requirements also apply to other network communications devices such as Integrated Service Digital Network (ISDN), cable modem, and Asymmetric Digital Subscriber Line (ADSL), as indicated later in this guide.

Note: It is recognized that OEMs supply server systems to customers in situations where the customer will insert network adapters at the end-user site. Systems designed for specific customers are exempt from including a network adapter. However, if a network adapter is included in the system, it must meet these requirements.

Also, references in this chapter to adapters, network interfaces and so on should be taken to apply equally to add-in network adapter cards, network implementations on the system motherboard, and external network interfaces, without preference for any of these types of implementation unless otherwise noted.

77. System includes non-ISA/non-LPC NDIS 5.0 network adapter

Required

An ISA or LPC-based network adapter solution is not allowed for a server system.

78. Network adapter uses NDIS 5.0 miniport driver

Required

A network adapter must use an NDIS 5.0 miniport driver and meet the following requirements.

78.1 The network adapter driver must be based on and comply with NDIS 5.0 in order to take advantage of Windows 2000 operating system capabilities.

The driver must follow the NDIS miniport driver model defined in "Network Drivers" in the Windows 2000 DDK.

Important: The development of full MAC drivers is no longer supported. Support for full MAC drivers will be removed in future versions of Windows.

78.2 If the network device is for connection-oriented media, it must meet connection-oriented miniport driver and call manager driver requirements.

This is required for connection-oriented media such as Asynchronous Transfer Mode (ATM), ISDN, Frame Relay, or X.25. Drivers for such devices must follow the guidelines in "Connection-Oriented NDIS" in the Windows 2000 DDK.

In some cases, such as ATM, the call manager driver is included in the operating system and the vendor needs to provide only an NDIS 5.0 connection-oriented miniport driver. For other connection-oriented media, such as ISDN or X.25, the call manager is not included in the operating system and must be provided with the hardware. The call manager support can be integrated in the connection-oriented miniport driver or implemented as a separate NDIS 5.0 call manager driver. The documentation for both integrated or separated call manager driver is included in "Connection-Oriented NDIS" in the Windows 2000 DDK.

78.3 An intermediate NDIS 5.0 miniport driver is required for network adapters that connect to the system using IEEE 1394 or USB buses.

This driver exposes its media type to NDIS at its upper edge and interfaces with the appropriate bus driver, IEEE 1394 or USB, at its lower edge.

The NDIS 5.0 miniport driver must also meet these requirements:

78.4 Driver works correctly with Microsoft network clients and protocols

This includes the 32-bit Microsoft client and NetWare-compatible clients provided with Windows, whether connected to a Windows 2000-based server, a Novell NetWare 3.x, 4.x, or 5.x server, or a Windows-based peer server. In all cases, this includes connections using Microsoft Transmission Control Protocol/ Internet Protocol (TCP/IP), IPX/SPX-compatible protocol, and NetBIOS Extended User Interface (NetBEUI) in LANs. In WANs, connections must work correctly using TCP/IP.

78.5 Driver makes only NDIS library calls or WDM system calls

NDIS conformance must be validated over single and multiple network connections. For Windows 2000, this must be validated on a multiprocessor system as part of the testing process.

78.6 Driver uses Windows 2000 INF format

All network components must use the Windows 2000 INF format. For information, see "Creating an INF File" in the Windows 2000 DDK.

For Windows 2000, there is no legacy INF support.

78.7 Driver is deserialized

NDIS 5.0 introduces support for deserialized miniports, enabling performance improvements and scalability on Windows 2000 multiprocessor systems.

79. NDIS 5.0 miniport driver supports high-performance send and receive calls

Required

NDIS drivers for server-side network adapters must support the higher performance send (NdisSendPackets) and receive (NdisMIndicateReceivePacket) calls as documented in the Windows 2000 DDK.

80. Full-duplex adapter automatically detects and switches to full-duplex mode

Required

The network adapter must negotiate full duplex operation by default when both the network adapter and switch port in a link pair support full duplex and the networking technology provides a standard way for each to detect and/or negotiate the duplex mode. Half duplex can be used if that is the only mode supported by one or both link partners or if it can be configured manually when warranted by special conditions. The goal is to configure this setting automatically without end-user intervention.

81. Network adapter automatically senses presence of functional network connection

Required

Where the network media allows it, the network adapter must be capable of dynamically determining whether it is connected to a functional link partner such as a hub, switch, or router. The device must indicate the link state in the following cases:

  • At boot time
  • After returning to D0 power state

When the link state changes while in the D0 power state (no time limit is specified for the required detection or status indication)

If the adapter is on an expansion card not used as a boot device, then the device drivers can determine the presence of the functional link. If the device is not connected to a functional link partner, the miniport driver must provide appropriate NDIS status indication, using support for cable sense in NDIS 5.0.

For information about NDIS status codes and indication mechanisms, see "Reporting Hardware Status" in the Windows 2000 DDK.

82. Network adapter automatically senses transceiver type

Required

Network adapters that support multiple transceivers must be capable of automatically detecting which transceiver type is connected to the network unless this is not possible with the network media at hand. The network adapter then must automatically drive the correct connection. In all cases, the user must not be required to set jumpers or manually enter information to inform the operating system of the transceiver type.

83. Network adapter can transmit packets from buffers aligned on any boundary

Required

Buffer alignment refers to whether a buffer begins on an odd-byte, word, double word, or other boundary. Adapters must be able to transmit packets any of whose fragments are on an odd-byte boundary.

For performance reasons, packets should be received into contiguous buffers on a double word boundary.

84. Network adapter communicates with driver across any bridge

Required

If the adapter uses a bridge, all communications must be free of errors across any bridge, such as a PCI bridge adapter.

85. Network adapter supports configuration capabilities and registry settings for performance tuning

Required

Some network adapters and drivers might support additional configuration capabilities for performance tuning when used in special environments or applications. Any tuning parameters that are set by the user, an application, or the operating system must be controlled through registry variables.

An example of such performance optimizations might be adjustment of interrupt moderation or the number of receive buffers for systems used as dedicated routers.

In addition to Dynamic Interrupt Moderation, there are other techniques that can be implemented on network adapters to maximize system performance for special environments or applications.

User-tunable parameters must be set through registry variables as parameters for network adapters and must not be set in .INI files, configuration files, or in other locations. These parameters can be accessed using the Advanced Page in the Device Manager. The variables should be set through standard user interfaces provided in Windows.

86. PCI network adapter properly supports higher-level PCI commands

Required

Specifically, network adapters must properly support the Memory Read Multiple (MRM), Memory Read Line (MRL), and Memory Write and Invalidate (MWI) commands. PCI commands are defined in the PCI 2.2 specification. This requirement ensures efficient data transfer.

87. PCI network adapters are bus masters

Required

To improve the system performance by decreasing the load on the system processor, the PCI network adapters must be bus masters.

88. USB or IEEE 1394 network device complies with related device class specifications

Required

External networking devices attached using a serial bus (USB, USB 2.0, or IEEE 1394) must support standard control interface specifications where applicable.

All external USB networking devices must support USB CDC 1.1 and must support one of the following:

  • Ethernet connection model (CDC 1.1)
  • Remote NDIS over CDC 1.1
  • Communications API (CAPI) over CDC 1.1 (ISDN modems)

External IEEE 1394 networking adapters must support Remote NDIS over SBP-2.

89. Network device and driver meet Plug and Play and power management requirements.

Required

The additional Plug and Play and power management requirements for network communications devices include the following:

  • Plug and Play capabilities support multiple adapters. For network communications devices, the Plug and Play IDs and resource support must be sufficient to automatically support the addition of multiple network communications devices to the system. This is true for the same and different types of network communications devices.
  • All resource settings are reported in the user interface. All resource settings must be viewable in the Device Manager and in adapter properties dialog boxes. All resource settings that can be changed by the user must be changed using the standard Windows user interface and not by way of INI files or other setting files.

This implies that all device resources must be set and read through the device’s standard bus interfaces. For PCI devices, this interface is the PCI configuration space. Further, device parameter settings must be stored in the registry.

90. Network communications device supports wake-up events

Recommended

This recommendation applies specifically to the following network communications devices and their associated NDIS 5.0 miniport drivers:

  • Ethernet and Token Ring network adapters
  • Integrated Data-Over-Cable Service Interface Specification (DOCSIS) cable modems
  • Other or future devices that transfer 802.3/DIX Ethernet framed packets

Note: The Network Device Class Power Management Reference Specification, Version 1.0 or later, does not yet define wake-up mechanisms for ISDN adapters or any network communications adapter that uses ATM signaling.

The system must be capable of being awakened from a lower power state based on network events specified by the local networking software. This capability yields the result that any standard Windows network access—such as connections to shared drives and Winsock connections, plus service and management applications—can awaken a system from lower power states transparently.

As defined in Network Device Class Power Management Reference Specification, a network adapter and its driver must support wake-up on receipt of a network wake-up frame. Support for wake-up on detection of a change in the network link state or on receipt of a Magic Packet event is optional. Implementation details are described in the "Network Wake-up Frames" and "Network Wake-up Frame Details" sections of Network Device Class Power Management Reference Specification, Version 1.0a and in the Windows 2000 DDK. See also the implementation notes at http://www.microsoft.com/hwdev/devdes/netpm.htm.

The packet patterns that define the wake-up frames are provided to the NDIS 5.0 miniport driver by the operating system. To enable Wake-On-LAN capability for basic networking scenarios, the network interface card must be capable of storing information describing a minimum of four wake-up packet patterns, and it must be able to recognize wake-up packets based on pattern matches anywhere in the first 128 bytes of the packet. The network adapters should be capable of storing information describing at least eight wake-up packet patterns to enable more advanced applications such as Wake-On-LAN capability on multi-homed systems or on receipt of multicast packets, in addition to the basic scenarios described here.

PCI-based network adapters must support the generation of a power management event (PME# assertion) from the D3 cold device state if the physical layer technology is generally capable of operating under the voltage and current constraints of the D3 cold device state. For example, 100Base-TX adapters can meet this requirement based on the state of the art in mid-1988. 1000Base-SX, 1000Base-LX, or 1000Base-TX (gigabit Ethernet using optical fiber or copper media) cannot meet this requirement because of the power required to operate the optical physical layer.


Connectionless Networking Requirements

This section lists the design guidelines that apply to all connectionless networking media, such as IEEE 802 LAN adapters (except for wireless) and Fiber Distributed Data Interface (FDDI) adapters.

91. Network adapter offloads TCP/IP checksum, IP Security encryption, and TCP message segmentation

Recommended

Server-side network adapters should support task-offload mechanisms to offload TCP/IP checksum calculation, IP Security encryption, and TCP message segmentation to intelligent hardware. This provides better utilization of computing resources on the server system. Mechanisms for off-loading these tasks are documented in the "Task Offload" topic in the Windows 2000 DDK.

92. Network adapter supports filtering for at least 32 multicast addresses

Required

This requirement applies to those networking technologies that support multicast, such as Ethernet, but it does not apply to those which do not support multicast, such as Token Ring, which distributes IP multicast traffic using the functional address as specified in RFC 1469.

This capability is needed to support "push" technology applications such as Microsoft NetShow®, Active Desktop, and Internet Explorer 5.0 and later. The minimum required capability is for filtering 32 multicast addresses (also known as channels).

93. Server network adapter supports Load Balancing and Failover capabilities

Recommended

Server network adapters should support the bundling of multiple physical network links into a single logical link for the purpose of bandwidth aggregation and physical link failure protection. This capability is dependent on the features of the network switching elements and should support commonly implemented network switches and their respective link aggregation and fail-over techniques.

94. Server network adapter supports remote system setup capabilities

Recommended

It is strongly recommended that server network adapters support remote new system setup capabilities as defined in PXE 2.1.

95. Network connections used for remote boot meet PXE requirements

Required

On server systems that support remote new system setup, network connections used for remote boot must comply with remote new system setup capabilities as described in PXE 2.1 or later (for IA-32 systems), or EFI 1.0 (for IA-64 systems). It must be possible to enable and disable the remote boot (remote new system setup) capabilities through administrative control in order to maintain server security.

Note: Multiport network adapters can supply remote system setup capabilities on none, any, or all ports.

96. Network adapter and driver support promiscuous mode

Required

This ensures that the adapter can be used with Microsoft Network Monitor Agent. This requirement applies only to LAN (non-switched) media.

Notice that, by default, promiscuous mode is not turned on. Enabling promiscuous mode should be possible only by using the Microsoft Network Monitor Agent or another similar administrative application.

97. Network adapter and driver support multicast promiscuous mode

Required

By supporting this feature, the adapter and the driver enable performance improvements for special-purpose servers and applications, such as multicast routers. This requirement applies to those networking technologies that support multicast, such as Ethernet, and not to those that do not support multicast, such as Token Ring.

Notice that, by default, multicast promiscuous mode is not turned on.

98. Network adapter and driver support priority for IEEE 802-style networks

Required

Windows Quality of Service (QoS) components provide link layer priority information to NDIS 5.0 miniport drivers in each transmitted packet’s NDIS_PER_PACKET_INFO structure. Priority values are derived by mapping Internet Engineering Task Force (IETF) Integrated Services (intserv) service types to 802.1p priority values (referred to as the "user priority" object in http://search.ietf.org/internet-drafts/draft-ietf-issll-is802-svc-mapping-01.txt, which is likely to be superceded by a later draft or final specification). The intserv service type used for the mapping is determined by QoS-aware applications or on behalf of the application, by QoS-aware operating system components.

802.1p/q-capable Ethernet drivers are expected to use the priority level indicated in the NDIS_PER_PACKET_INFO structure to generate the corresponding field in the 802.1p/q MAC headers of transmitted packets. Similarly, these drivers are expected to extract the appropriate information from the MAC headers of received packets and to copy the priority to the NDIS_PER_PACKET_INFO structure before indicating the packet to higher protocol layers.

Note that any link layer driver may interpret the priority information in the NDIS_PER_PACKET_INFO structure and use it as appropriate for the particular media.

For more information, see "Packet Support for 802.1p Priority" in the Windows 2000 DDK. See also "QoS: Assigning Priority in IEEE 802-style Networks," available at http://www.microsoft.com/devdes/qos802.htm.


Modem Requirements

This section presents general requirements for modems. There are two types of modems to consider.

  • Traditional serial modems

These modems, originally designed for PCs, are connected to the server system by a serial port, or are implemented as a driver that emulates a traditional modem. The fundamental design principle for compatibility with Windows 2000 is for a serial modem to be supported by the Universal Modem Driver (Unimodem), which uses INF files to characterize device operation. Unimodem INF design is described in the Modem Developer’s Kit (MDK), included in the Windows 2000 DDK.

  • Networking modems (Public Switched Telephone Network (PSTN) modem configured as networking devices, ADSL modems, cable modems)

These modems are designed for large servers and connected to the system using networking drivers—for example, NDIS 5.0 miniports. The fundamental design principle for compatibility with Windows 2000 is for a networking modem to be supported by NDIS 5.0, as defined in "Network Drivers" in the Windows 2000 DDK.

Server Types and PSTN Modem Usage. SOHO servers typically have a small number of serial modems, used for Remote Access (in or out), shared ISP access, fax (in or out) and interactive voice response (IVR). The modems used are traditional serial modems. These modems are typically connected by individual PSTN phone lines or by ISDN BRI lines.

In an enterprise, the modem servers may support hundreds of modems, used primarily for inbound remote data access such as for an ISP or corporate network. The modems are typically connected to public networks on high-speed digital lines (T1, ISDN, or PRI). Different servers may be used for dedicated incoming fax reception or IVR. Note that Windows 2000 Unimodem and Telephony Application Program Interface (TAPI) can be used to support hundreds of modems for each server.

Design Issues for Server PSTN Modems. The following are the design issues to consider, based on server types:

  • For modems designed for Basic servers, the most important additional design issues are:
  • Support for V.90, as host side modems where possible, which requires an ISDN BRI or other digital network connection.
  • Do not migrate the modem signaling function, for example, V.90 or V.34, into the system.
  • For SOHO Server modems, the most important design issues are:
  • Adaptive answering features: V.8, V.8bis, V.251.
  • Full duplex voice strongly recommended, using V.253, to support small scale Interactive Voice Response.
  • For Enterprise Server modems, the most important design issues are:
  • The NDIS 5.0 miniport interface is preferred.
  • Fax is optional, not mandatory, because the most common solutions use separate hardware and drivers, on separate public network connections.

99. System includes WAN communications device

Recommended

The following device options, as defined later in this chapter, can meet this requirement:

  • Serial modem with V.34 and V.90 capabilities, supporting server fax capabilities (two or more ports recommended)
  • ISDN adapter (NDIS driver) or ISDN modem (Unimodem driver)
  • ATM adapter (NDIS driver)
  • ADSL adapter (NDIS driver)
  • Cable modem (NDIS driver)

Note: It is recognized that OEMs supply systems to customers in situations where the customer will insert modem devices at the end-user site or where the customer has particular feature demands. Server systems designed for specific customers are exempt from these requirements.


Unimodem-supported Modem Requirements

The following requirements apply to modems connected as logically serial modems, using Unimodem as the TAPI service provider.

100. Modem controller meets minimum requirements

Required

The following are minimum requirements for the modem controller, in addition to supporting V.250:

  • Unimodem Diagnostics command, AT#UD
  • Software-upgradeable modem controller (upgradable ROM or Windows modem)
  • AT command buffer of at least 60 characters
  • Semicolon (;) character dial string modifier, unless prohibited by national regulations

101. PSTN modem supports ITU-T V.250 command set

Required

ITU V.250 (formerly V.25 ter) is a superset of TIA-602. TIA-602 codifies the most common data modem commands and responses.

If the AT command for a particular function is implemented, the corresponding V250 AT command must be supported.

The essential V.250 commands are the following:

  • All basic modem commands from TIA-602 (no + prefix)
  • Identification: +GMI, +GMM, +GMR, +GCI
  • Port control: +IPR, +IFC, +ILRR
  • Modulation: +MS, +MR
  • Error control: +ES, +ER
  • Data compression: +DS, +DR

102. Device complies with device class power management

Required

The Communications Device Class Power Management Reference Specification, Version 1.0 or later, provides definitions for the OnNow device power states (D0–D3) for modems. The specification also covers the device functionality expected in each power state and the possible wake-up event definitions for the class. Power states D0 and D3 cold, including wake-on-ring support, are required for modems on power managed buses, including PCI and USB. Modem adapters that use the PCI bus must be capable of generating a power management event (PME# assertion) from the D3 cold device state.

Recommendation

Recommended: Modem adapters should also support capture of Caller ID with hardware support for the AT+VRID "resend caller ID" voice modem command.

103. Device supports wake-up events

Required

A modem must be able to cause a wake-up event on an incoming ring as defined in Communications Device Class Power Management Reference Specification. This applies for modems on all power-managed buses, including PCI and USB. PCI devices are required to support D3 cold on a PCI 2.2-based system with auxiliary power. On all other power-managed buses (such as USB), support for either D2 or D3 is acceptable.

104. Data modem supports v.90 and v.34 modulation and other requirements

Required

The requirements for a data modem include the following:

  • V.90 modulation
  • V.34 modulation
  • V.42 LAPM error control
  • V.42bis data compression
  • V.80 synchronous data access protocol

105. Data modem supports digital connection to support host-side V.90 operation

 | Windows2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Required | Required | Required
SOHO: | Recommended | Required | Recommended

V.90 depends on a digital connection for the host-side modem to the public telephone network, typically using T1 or ISDN. Server modems should be designed for digital connection, to support host side V.90, where digital connections are available.

106. Fax modem supports 14.4 Kbps (V.17) with Class 1 (T.31) command set

Required for PSTN connected modems, Recommended for ISDN connected modems

If fax modem capabilities are implemented, the fax modem must support 14.4 Kbps (V.17) with the Class 1 (ITU T.31) command set.

If fax modems include fax/data media detection (for example, T.32 +FAA command), the INF must include the necessary registry keys, as defined in the MDK in the Windows 2000 DDK.

Recommendation

The following are recommended:

  • Class 1.0 (ITU T.31) +FAR support, which allows the hardware to perform adaptive carrier detection
  • Class 2.0 (ITU T.32 or TIA-592) for server modems, which offloads the T.30 session protocol to the modem

107. Modem supports call control signaling, controlled using V.251 modem commands

Required

Modems must support the ITU V.251 standard for PC-controlled call control, including:

  • Support Data Communications Equipment (DCE) controlled V.8 operation with DTE notification
  • Support DTE-controlled V.8 operation (<a8a> values of 2, 3 and 4)
  • Support DTE-controlled V.8bis operation
  • Support backward compatibility for media detection with terminals using V.25 signaling, for example, data calling tone and fax calling tone
  • Support backward compatibility for media detection with older modems, for example, V.32 and V.32 bis
  • Provide a means for turning on the V.8 Calling Indicator (CI) signal for originating calls

108. Modem supports blacklisted and delayed number clearing

Required where applicable

During certain international Post, Telephone, and Telegraph (PTT) certification processes, modems must support the blacklisted and delayed numbers feature. That means that when the modem fails to connect to a specific number for a certain number of times, the dialed number is stored in an internal list. Any subsequent automated dialing operation to this number is then either delayed for a time (delayed) or forbidden until some form of manual intervention occurs (blacklisted). The international certification processes specify that manual intervention using an external device is required in order to clear these numbers.

Recommendation

Recommended: The modem should clear its blacklisted and delayed number tables if the associated handset goes off hook.

109. Voice modem support is provided

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Optional | Optional | Optional
Enterprise: | Optional | Optional | Optional
SOHO: | Recommended | Recommended | Recommended

Voice capability is recommended for SOHO server modems to support Interactive Voice Response and 3-way DATA/FAX/Voice call classification on the same phone lines. This support, if implemented, must meet the requirements documented in guideline "#110. Voice modem supports ITU V.253 (AT+V)."

110. Voice modem supports ITU V.253 (AT+V)

Required for PSTN connected modems; Recommended for ISDN or T1 connected modems

Voice capability is not mandatory, but if support for voice modem is implemented in a server system, it must meet the following requirements:

  • V.253 compliance
  • Voice recording and playback (+VTX, +VRX, +VTR)
  • DTMF generation and detection during voice I/O
  • Voice I/O support of 8-bit, 8-kHz pulse coded modulation (PCM) formats: unsigned linear, G.711 (A-law and u-law)
  • Programmable gain control for all audio channels
  • Caller ID Detection and Reporting (+VCID)


ATM Adapter Requirements

This section summarizes requirements for ATM hardware.

The NDIS 5.0 extensions provide kernel-mode NDIS 5.0 client drivers with direct access to connection-oriented media such as ATM. The architecture for Windows 2000 extends native ATM support to Winsock 2.0, TAPI, and applications based on Microsoft DirectShow® by providing system-level components that map the applicable Winsock, TAPI, and DirectShow APIs to NDIS 5.0, extending direct ATM access to user-mode applications.

ATM is not required for any of the server classes. If an ATM adapter is designed for operation under Windows 2000 in the server system, it must meet the requirements defined in this section. For more details about the following requirements, see "ATM Layer Specification" in ATM User-Network Interface Specification, Version 3.1. This specification also includes references to other relevant specifications.

111. ATM adapter meets network adapter requirements

Required

ATM adapters must meet all requirements listed in "Network Adapter Requirements" earlier in this guide.

112. ATM adapter supports a minimum number of simultaneous connections

Required

The Virtual Path Identifier (VPI) and Virtual Channel Identifier (VCI) ranges supported by the adapter affect the maximum number of simultaneous connections supported on a system.

This affects the applicability of the adapter to ATM applications such as LAN Emulation, where at least one dedicated virtual channel is created between each pair of communicating ATM hosts.

System type | Simultaneous connections
Client (ATM adapter) | 64 or more
Client (Integrated ATM/ADSL-adapter) | 16 or more
Server | 2048 or more

A sample driver is provided in the Windows 2000 DDK to guide developers in properly supporting resources to meet this requirement.

113. ATM adapter supports all service types defined by the ATM Forum

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

The ATM adapter should support the constant bit rate (CBR), variable bit rate (VBR), available bit rate (ABR), and unspecified bit rate (UBR) service types as defined by the ATM Forum.

114. ATM adapter supports UBR service type

Required

UBR is used by default for standard ATM services such as LAN Emulation and IP over ATM. In addition, Point-to-Point Protocol (PPP) is a widely used model for residential network access and UBR is used by default for PPP over ATM virtual circuits. Therefore, it is required that ATM adapters support the UBR service type.

115. ATM adapter supports a minimum number of simultaneously active VBR or CBR connections

Required

Support for at least two simultaneously active VBR or CBR connections is required for basic ATM signaling and management.

Support for additional VBR/CBR connections is needed for ATM adapters that support multimedia or other traffic that demands QoS. These are listed in the following table.

System type | Simultaneous active VBR/CBR connections
Client | 6
Server | 500

116. ATM adapter supports traffic shaping

Required

The ATM adapter must support and enforce all the traffic-shaping rules specified for each service type it supports, including CBR, VBR, ABR, and UBR.

Note: This includes enforcement of peak cell rate on UBR virtual circuits.

117. ATM adapter enforces PCR on UBR virtual circuits

Required

ATM adapters will be used to connect router, remote access, and content servers to the public ATM network. High-speed residential broadband access networks such as ADSL and cable modem will use an ATM virtual circuit from home or small office computers to connect directly to these servers. When the Windows Dial-Up Networking UI is used to connect from a home or small business computer to a remote router or server, a PPP link is established over an ATM virtual circuit.

The service type used on this PPP-over-ATM virtual circuit is UBR. When creating the UBR virtual circuit, Windows requests upstream and downstream line rates, or Peak Cell Rates (PCR), equal to the upstream and downstream line rates provisioned for the user. Windows uses the ATM Interim Local Management Interface (ILMI) protocol to obtain information, such as getting the user’s provisioned line rates from the public network.

To avoid packet loss and ensure efficient network utilization, it is critical that all ATM, integrated ATM/ADSL adapters, and ATM/cable modem adapters enforce requested PCR on UBR virtual circuits.

Because any ATM adapter might be installed in a server to which clients connect through the public network, this requirement applies to all ATM adapters.

118. ATM adapter and driver support dynamic link speed configuration

Required

When connected to a residential broadband network, ATM adapters must restrict the aggregate transmission rate across all active virtual circuits so that it does not exceed the provisioned upstream bandwidth of the residential broadband network.

All integrated ATM/ADSL and ATM/cable modem adapters must support aggregate shaping of upstream bandwidth according to the provisioned upstream bandwidth or the trained bandwidth, whichever is lower. Some implementations can support rate adaptation, and lower-than-provisioned rates may be negotiated due to poor line conditions. All 25-Mbps ATM adapters must support this as well, because any 25-Mbps ATM adapter could be used to connect by way of an external ADSL modem to an ADSL network. This support is optional for ATM adapters with line rates higher than 25 Mbps.

The Windows ATM Call Manager uses ILMI to query the public network to discover the provisioned maximum line rates for incoming and outgoing traffic. The Call Manager then uses the OID_GEN_CO_LINK_SPEED NDIS request (in SET mode) to set the line rate for both incoming and outgoing traffic. The adapter must shape the aggregate of ATM traffic within these incoming and outgoing rates.

119. ATM adapter supports OAM

Required

Operation and maintenance (OAM) is needed for diagnostics. This capability is required for a server system. At minimum, the ATM adapter must respond to received F4 and F5 loopback OAM cells. Support for other layers, F1–F3 is optional.

120. ATM adapter supports buffer chaining (Tx + Rx)

Required

This feature is needed for large packets. This capability is required for server systems, but is recommended for client systems.


ADSL Device Requirements

This section summarizes requirements for ADSL hardware.

Support is provided in the Windows 2000 Server operating system for ADSL adapters and external ADSL modems, such as those using USB, which provide a faster method for moving data over regular phone lines. ADSL adapters are not required for any server type, but if an adapter is included in a server, it must meet the requirements in this section. ADSL is not required in a server system, but if present, it must comply with these requirements.

Please review the white paper, An Interoperable End-to-End Broadband Service Architecture over ADSL Systems, Version 3.0, which discusses end-to-end service interoperability over ADSL. This paper, which is available from the web site at http://www.microsoft.com/hwdev/publicnet/, was jointly developed by over 30 leading ADSL vendors. The core idea of this white paper (PPP-over-ATM over ADSL) has been adopted by the ADSL Forum.

121. ADSL device is implemented as an integrated ADSL modem

Recommended

System designers should integrate the ADSL modem and higher-layer transmission and media access functions on a single network device. A typical implementation integrates an ADSL modem and ATM interface on a single PCI network adapter. Another example is a device that connects to the server using the USB or IEEE 1394 bus.

If external ADSL modems are provided (other than IEEE 1394 or USB), they should have an ATM interface for the ADSL modem to server connection. In addition, an Ethernet interface can also be included.

122. Integrated ADSL modem meets network adapter requirements

Required

Integrated ADSL modems must meet all requirements listed in "Network Adapter Requirements" earlier in this guide.

An integrated ADSL modem exposing an Ethernet interface must also meet the requirements in guideline "#92. Network adapter supports filtering for at least 32 multicast addresses."

123. ATM/ADSL solution is implemented for integrated ADSL modems

Recommended

An integrated ADSL modem should expose ATM to the operating system. For ATM-specific requirements when an ATM/ADSL solution is implemented, see the requirements in "ATM Adapter Requirements" earlier in this chapter. This should comply with the PPP over ATM architecture discussed earlier.

Note: ATM/ADSL is a requirement for Universal ADSL implementations. Currently there are both ATM/ADSL-based and Ethernet/ADSL-based implementations to provide full rate ADSL services in the market. For compatibility with the Universal ADSL-based services that will be rolled out within the next couple of years, PPP/ATM/ADSL is the required implementation.

124. ADSL modem supports DMT line encoding

Recommended

The ADSL modem must support discrete multi-tone (DMT) line encoding, which is recognized as the industry standard for ADSL by American National Standards Institute (ANSI) as the T1.413 Issue 2 specification and also by the Universal ADSL Working Group.

Note: DMT is a requirement for Universal ADSL implementations. The Universal ADSL Working Group has adopted DMT specified by T1.413, with modifications being made to work in a splitterless environment.

125. ADSL modem supports rate adaptation

Recommended

On a rate adaptive digital subscriber line (RA-ADSL), the downstream and upstream data rates are independently set either by an automatic adaptive algorithm or by manual selection.

RA-ADSL provides the capability to optimize the transmission speed and per.formance over a wide range of telephone-line loop distances. Adaptive channel equalization ensures more robust performance in the presence of channel impairments and narrow-band interference.

This also helps telephone companies to provision RA-ADSL access on their existing networks. RA-ADSL products can be provisioned on many telephone lines without costly and time-consuming network upgrades.


Cable Modem Requirements

Cable modems are not required on servers. If they are implemented, they must meet the requirements in this section.

Cable modem provides two-way services: Data flows downstream from the cable operator’s head end and upstream from the customer’s PC. At the head end, the cable data system is terminated by the cable modem termination system (CMTS), which terminates the upstream and downstream radio frequency (RF), MAC layer, and possibly Layer 3 protocols from the cable side. CMTS provides the internetwork connection between the cable system and the rest of the network at the head end. CMTS can be implemented on a proprietary hardware platform or a PC platform running Windows 2000 to provide different networking functions such as routing, QoS support, such as Resource Reservation Setup Protocol (RSVP), and so on.

Some implementations transmit upstream using narrow-band networks such as ISDN or analog modem, but as cable companies upgrade their networks, an increasing number of RF return modems, for example, two-way modems, are being deployed. Two-way modems are preferred, because they are always connected, perform better, and do not tie up phone lines or require modem banks.

The three current cable modem specifications are:

  • DOCSIS, developed by the Multimedia Cable Network System (MCNS) consortium.
  • IEEE 802.14, developed by IEEE.
  • Digital Video Broadcasting/Digital Audio-Visual Council (DVB/DAVIC), developed by DAVIC and DVB and adopted by European Telecommunication Standards Institute (ETSI) and International Telecommunication Union (ITU).

Industry support for DOCSIS is growing rapidly in North America. In present form, its upper layers fully describe IP traffic encapsulated by 802.3/DIX Ethernet framing. ATM is left for future study.

External Ethernet DOCSIS cable modems provide IEEE 802.1d bridging for one or more Customer Premises Equipment (CPE); a system attaches to the cable modem indirectly through its 10Base-T network adapter. Integrated cable modems attach directly to the system over buses such as USB, PCI, and IEEE 1394, and require a vendor-supplied NDIS 5.0 miniport driver. This driver exposes an 802.3/DIX Ethernet adapter interface to the operating system and it interfaces to the cable modem hardware using the appropriate bus (PCI) or bus interface driver (USB or IEEE 1394) at its bottom edge.

In contrast to DOCSIS, both the 802.14 and the DVB/DAVIC efforts are focused on using ATM, typically implementing an ATM adapter interface and using an NDIS 5.0 ATM miniport driver.

126. Device is implemented as an integrated cable modem

Recommended

An integrated cable modem should be used for servers. This recommendation means integrating everything from the cable modem’s physical interface layer, such as an RF coax connector, up through a standard PC 802.3/DIX Ethernet or ATM adapter MAC interface onto a single device. In other words, the software perceives the integrated cable modem as a standard Ethernet or ATM network adapter.

An example of this is a USB-attached DOCSIS implementation that integrates cable modem Physical Media Dependent, downstream convergence, cable MAC, link security, 802.3/DIX MAC "adapter" filtering, and USB device interface functions in the same box. Similar devices can be implemented that are attached using PCI or IEEE 1394 buses.

127. Integrated cable modem meets network adapter requirements

Required

  • Integrated cable modems must meet all requirements listed earlier in "Network Adapter Requirements."

Integrated cable modems exposing an Ethernet interface must also meet the requirements in guideline "#92. Network adapter supports filtering for at least 32 multicast addresses."

128. Integrated cable modem exposes an ATM or Ethernet interface

Required

Refer to ATM Adapter requirements for ATM-specific requirements if an ATM/cable modem solution is implemented.


ISDN Requirements

This section summarizes requirements for ISDN hardware.

ISDN is recommended, but not required, for high-speed connections under these guidelines. If implemented in a server system, ISDN must meet the requirements defined in this section.

There are two classes of ISDN adapters:

  • Serial port devices, supported by Unimodem with INFs
  • Parallel bus devices, supported by NDIS WAN drivers

In this section, "internal ISDN device" refers to the ISDN terminal adapter, which exposes raw access to its B channels using NDIS miniports. WDM-supported bus classes, such as USB or IEEE 1394, can also be used to attach external devices using NDIS miniports.

"ISDN modem" refers to an internal or external ISDN device that exposes itself as a modem controlled by the AT command set. To the operating system, these devices look like and can be used as modems, provided that the hardware manufacturer has done the work needed to ensure that these devices have the following capabilities:

  • Interpretation of the standard modem AT command set, either in the ISDN device itself or in a serial port driver. For more information, see the TIA-602 specification, which is a subset of ITU V.250.
  • A modem INF file for installing the device and for telling Unimodem which commands to use to control the ISDN device.

Serial ISDN Modem Requirements

The requirements in this section apply for a serial ISDN modem designed for or included with a server system that complies with Hardware Design Guide.

ISDN modems share the following features:

  • ISDN Basic Rate interface (2B+D)
  • Serial AT command language, with proprietary ISDN extensions

ISDN modems also share the following differences from wireline PSTN modems:

  • User (or device) must configure for switch type and service profile ID (SPID)
  • Data only, in increments of one or two 64,000 bps B channels
  • Fax not available
  • V.42 and V.42bis usually not available

129. ISDN modem supports required command set

Required

An ISDN modem must support basic AT commands as defined in TIA-602, which is a subset of ITU V.250. The ISDN modem shall support commands to select the end-to-end protocol used over the ISDN; synchronous PPP, V.110, V.120, and so on. Also, commands must be included to set the switch type, subscriber numbers or directory numbers (where applicable), and service profile identifier (SPID) or EAZ (where applicable), to allow user selection if auto-detection fails. These can be implemented in the device or in the communications driver.

130. ISDN modem exposes both B channels

Recommended

ISDN modems should expose both B channels so that they can leverage the multilink PPP support included in the operating system.

Multilink PPP, as defined in RFC 1717, combines several ISDN B channels to increase the bandwidth of PPP links.

When using ISDN modems connected to the server using a single serial port, the capabilities included in the operating system cannot be leveraged and the users may not be able to fully benefit from the features in the ISDN device, such as supporting two B-channels and combining them into one fast link.

This is because Windows 2000 cannot see both B channels of the ISDN connection unless each B channel is exposed to the operating system, either as a COM port, or by way of NDIS.

External ISDN modems should be on a port fast enough to expose the full bandwidth of both B channels, such as USB. Providing two separate COM-port cables is not an acceptable solution.

131. ISDN modem supports asynchronous-to-synchronous conversion

Required

These types of ISDN devices are treated as modems, not as internal ISDN devices supported using NDIS WAN miniports. In the external case, the primary implication is that the operating system will send byte-level PPP, also known as asynchronous PPP. In the NDIS WAN case, the implication is that the operating system will send bit-level PPP, also known as synchronous PPP.

Because ISDN is a synchronous service and an ISDN modem connects to an asynchronous port on the system, the device must provide some means of converting asynchronous data to synchronous data.

132. ISDN modem uses high-speed port

Recommended

Because of speed limitations inherent in a server’s COM ports, the connection for ISDN modems should be high speed, such as USB or IEEE 1394. A specification for controlling an ISDN TA over USB is in development by the USB Communications Device Class working group.

133. ISDN modem driver supports unattended installation, with limitations

Required

Configuration of the dependent parameters, such as SPIDs and switch-type IDs, must be done using the ISDN Configuration Wizard included in the operating system.

Parallel ISDN Device Requirements

This section defines general requirements for ISDN and specific requirements for ISDN terminal adapters.

134. Internal ISDN device meets network adapter requirements

Required

Internal parallel ISDN devices must meet all requirements listed earlier in "Network Adapter Requirements."

135. Internal ISDN device supports synchronous HDLC framing

Required

High-level data link control (HDLC) framing is a standard for sending synchronous data. Other framing methods are allowed if the miniport driver provides simple HDLC framed synchronous PPP packets to NDIS.

136. Internal ISDN device and driver support raw unframed synchronous B channel I/O

Required

The internal ISDN device and the driver must support raw unframed (non-HDLC) synchronous B channel I/O at 64 Kbps for each B channel, with each B channel individually accessible. This will enable H.320 and voice calls over ISDN without audio breakup.

For these raw interfaces, the direct path to each B channel must support synchronous transmission and reception of H.221 frames, which are of 20 ms duration. To achieve this without additional latency to H.221, there must be support for overlapped I/O buffers at intervals of less than or equal to 20 ms in each direction. As underruns or overruns cause degraded audio, hardware buffering must be adequate to prevent B channel underruns and overruns. For Windows 2000, 20 ms is adequate.

This can be achieved by making buffering software configurable with adequate range to handle foreseeable real-world conditions. The miniport driver should make I/O completion callbacks to NDIS for each I/O buffer as soon as the I/O for that buffer is complete and should not coalesce or delay callbacks.

137. Driver for ISDN internal device supports unattended installation, with limitations

Required

Configuration of the dependent parameters, such as SPIDs and switch-type IDs, must be done using the ISDN Configuration Wizard included in the operating system.

138. ISDN device with U-interface includes built-in NT-1 capability

Recommended

Note: This recommendation applies only in the United States.

A network terminator (NT-1) splits the duplexed transmit and receive signals from the ISDN line into separate transmit and receive components. An ISDN device with a built-in NT-1 can connect directly to the ISDN line. However, doing so prevents other devices from being attached to the ISDN line because only one NT-1 can be connected to an ISDN line. If the ISDN device has a built-in NT-1, it also should have a connector for either analog phone or another ISDN device (S/T-interface), such as an ISDN phone.

Adding an analog (POTS) port or S/T-interface to the ISDN device delivers convenience to the SOHO market, allowing customers to use one ISDN line to meet all their telecommuting needs at minimal cost. Many customers do not want a separate analog or digital phone line for their fax machines, modems, or phone when ISDN can do this with a device that has a POTS port or S/T-interface.

139. Internal ISDN device has software-selectable terminating resistors

Required

If the ISDN device has an S/T-interface for connecting additional ISDN devices and has configurable terminating resistors, they must be software configurable. The software selectable resistors can be selected on or off. The default value of termination is on in North America, but off in all countries where phone companies unconditionally provide the termination.


IrDA Communications Requirements

Infrared capabilities are neither required nor recommended on servers. If they are implemented, they must meet the requirements in this section.

The interface between Infrared Data Association (IrDA) hardware (framers) and the Windows IrDA stack is through NDIS 5.0 miniport drivers, as described "IrDA Miniport NIC Drivers" in the Windows 2000 DDK. The Windows 2000 IrDA stack expects that the hardware and NDIS drivers deal with framing, transparency, and error detection, and also support media sense and speed change commands. Miniport drivers are responsible for discarding incoming frames with bad cyclic redundancy checks. These frames must never be forwarded to the protocol.

140. Infrared network adapter meets network adapter requirements

Required

IrDA network adapters must meet all requirements listed in "Network Adapter Requirements" earlier in this design guide.

141. Infrared device supports both FIR and SIR

Required

All infrared devices must comply with approved IrDA specifications, including support for serial IR (SIR) and fast IR (FIR) data devices.

142. IrDA hardware reports a unique Plug and Play ID sufficient to support unattended driver installation

Required

FIR Plug and Play hardware must report a unique Plug and Play ID that matches the combination of the chipset, transceiver, and any other system-specific parameters, in order for the operating system to find and install the correct INF, and the associated driver for the IrDA hardware.

In the best case, the IrDA hardware has only one Plug and Play ID, associated INF file, and a miniport driver that can auto detect the transceiver type and other system-specific parameters. This enables the installation and configuration of the hardware and the driver without any user intervention.

In other cases, for example, where the driver can not autodetect the transceiver type, or any other system specific parameters, a unique Plug and Play ID for each combination of the chipset and the transceiver type must be reported, and an associated driver and INF file describing the configuration parameters must be provided by the vendor for each combination.


Wireless Networking Requirements

Wireless networking media types enable WAN, LAN and personal area network (PAN) connectivity. This section lists additional requirements for wireless media. Servers are not required to have wireless LAN connectivity.

Note: This design guide does not contain requirements for Bluetooth devices. However, future versions of Windows operating systems will use Bluetooth technology as a wireless external bus, rather than as a wireless networking technology. Therefore, Bluetooth devices are not subject to the requirements contained in this chapter; in particular, they do not require NDIS drivers.

143. Wireless networking media adapters meets network adapter requirements

Required

Wireless network media adapters must meet all requirements for network adapters defined earlier in "Network Adapter Requirements."

144. Wireless networking media adapters support wireless extensions to NDIS

Required

Wireless extensions to NDIS are documented in "Network-Dependent Wireless Objects" in the Windows 2000 DDK. These extensions are based on the work of the Portable Computer and Communications Association, published in PCCA-STD-201.

145. Wireless networking adapters support industry specifications

Required

IEEE 802.11 wireless networking adapters must support the following specifications:

  • 11Mb/s signaling using Direct Sequence Spread Spectrum (DSSS)
  • Wired Equivalent Privacy (WEP) for security.


Chapter 5 Storage Device Requirements

This section summarizes the requirements for storage devices used with servers.

Tips for selecting high-performance storage components: For manufacturers who want to select high-performance components for server systems, the following are the design features to look for in storage components:

  • System relies on the SCSI or Fibre Channel controller for primary storage.
  • Controller supports bus mastering, which is a requirement in these guidelines.
  • Disks support reduced latency and fast rotational speeds.
  • Drivers are tuned for 32-bit performance on an IA-32 platform, and tuned for 64-bit performance on an IA-64 system. For example, 32-bit alignments on the adapter do not interface with 16-bit alignments on odd addresses, nor do 64-bit alignments interface with 32-bit alignments.
  • Components do not use ISA or LPC.
  • SCSI High-Voltage Differential (HVD) differential devices must support DIFFSENS as described in SPI-3.
  • PCI burst mode reduces disk controller time spent on the PCI bus.


Storage Device General Requirements

This section presents general requirements for controllers and peripherals.

Note: It is recognized that OEMs supply systems with specific feature requirements to corporations, which can include providing servers that do not include any disks installed before shipping to a particular corporate client.

146. Host controllers and devices support bus mastering

Required

Bus master capabilities must meet the related specification for the particular controller. The host controller must not use the ISA or LPC bus.

Note: This requirement does not apply to legacy FDCs and will not become a requirement for the FDC in the future.

147. System and Option ROMs support Int 13h Extensions on IA-32 BIOS boot system

Required

On IA-32 BIOS boot systems, BIOS and option ROMs must support Int 13h Extensions as defined in "Int 13h Extension APIs" of the Windows 98 DDK. This support is needed during the Windows 2000 boot process on BIOS-based systems.

148. Block rewritable optical ATAPI device complies with SFF 8070i

Required

The SFF 8070i standard defines the requirements for block rewritable ATAPI devices (optical storage devices), including specifications for logical unit number (LUN) implementation, media status notification, and device write protection. This definition includes required support for the Read Format Capacities command.

149. Controller and peripherals support media status notification

Required

The following list shows the required specifications for implementing media status notification, depending on device type.

Device Type | Media Status Notification Implementation
CD or DVD devices | Comply with ANSI NCITS T10 Multi-Media Command Set-2 (MMC-2) standard for Media Status Event Notification.
ATAPI floppy/optical direct access drives | Comply with either MMC-2 standard or SFF 8070i Version 1.1.
IEEE 1394 storage devices | Comply with NCITS Reduced Block Commands standard (RBC; T10/97-260r0) standard.
ATA and non-ATAPI storage devices | Comply with Media Status Notification Support, Version 1.03.
Other ATA/ATAPI devices, including tape drives | If implemented, comply with Media Status Notification Support Specification, Version 1.03, or SFF 8070i.
Other types of SCSI removable devices | If implemented, support based on NCITS Reduced Block Commands standard.

150. Operating system recognizes the boot drive in a multiple-drive system

Required

150.1 IA-32 BIOS boot system uses CIP BIOS Boot 1.01 method to determine boot drive

The implementation of boot-drive determination in multiple-drive systems is defined in Section 5.0 of the CIP BIOS Boot 1.01. This is the format that Windows 2000 uses for determining the boot drive when new bootable devices are introduced for servers.

150.2 EFI IA-64 system complies with EFI 1.0 or later for detection of boot devices, plus Hardware Design Guide requirements

The requirements for management of the EFI boot process are documented in EFI 1.0 or later. In addition, EFI-based systems must meet other EFI requirements in these guidelines.

151. IA-64 system provides GPT-partitioned hard drive for boot

Required

64-bit Windows requires bootable hard drives to be partitioned using the GPT mechanism defined in EFI 1.0. This is also the 64-bit Windows default partitioning scheme for all non-removable storage media. At least one locally-attached hard drive must be available for booting an installed operating system image.

152. IA-64 system with GPT-partitioned bootable hard disks provide one ESP of correct size

Required

64-bit Windows requires bootable hard drives to contain a single EFI System Partition (ESP) of size Max(100MB, min (1% of the physical disk size, 1GB)) as defined in EFI 1.0. This formula is to be read, in words, as "the size of the ESP must be the larger of these two numbers, 100MB or 1% of the physical disk size (up to 1GB)." The physical disk size is measured at the time of disk partitioning.

153. IA-64 system with ESP contains only components needed for system boot, installation, or recovery

Required

The ESP may only be used for components required for system boot, installation, or recovery. Examples of such components include operating system loaders, EFI drivers, firmware utilities, configuration tools, and diagnostics.

154. EFI IA-64 system provides restoration tool for recovery of critical ESP and OEM special partition contents

Required

An EFI system must provide a tool that will permit the user to restore the critical EFI System Partition contents and any OEM special partition contents in the event of a catastrophic failure. This tool does not need to restore any operating system or other non-OEM–supplied ESP contents.

155. For EFI IA-64 system, MSR partition of correct size is present on every physical or virtual hard disk manifested to the operating system when such disks are otherwise being partitioned by the provider of the system

Required

All entities that represent themselves as a hard disk to an EFI system—whether single drives, or collections of drives behind an intelligent controller that represents the assembly as a whole as a single "disk"—must contain an Microsoft Reserved (MSR) partition of correct size.

This guideline applies only to disks shipped with systems being partitioned by the provider of the system, such as disks that contain system utilities or are otherwise preinstalled with software for use by or with Windows. It is not required for disks that are "blank"—in other words, those disks that have no partitions present on them when installed by the manufacturer and that will be configured by the user.

The formula for calculation of the size of an MSR is as follows:

if (disksize < 16 GB) {
    MSR = 32 MB;
} else {
    MSR = 128 MB;
}

The GUID for such partitions is defined as follows:

DEFINE_GUID(PARTITION_MSFT_RESERVED_GUID, 0xE3C9E316L, 0x0B5C, 0x4DB8, 0x81, 0x7D, 0xF9, 0x2D, 0xF0, 0x02, 0x15, 0xAE);

156. For IA-64 system, non-ESP partitions do not contain software required for boot

Required

No software required for system boot can be stored in an OEM-specific, non-ESP partition. Instead, such software must reside in an ESP or in system firmware.

157. For IA-64 system, ESP resides only on a device that can be reached through firmware-resident EFI drivers

Required

To prevent problems that can occur if a driver needs to reach a disk containing an ESP that is actually contained on that disk (resulting in a non-bootable system), ESPs must be placed only on devices that can be reached using firmware-resident EFI drivers. The system must also comply with "#14.7 "EFI systems provide a minimum, firmware-based driver set sufficient to allow boot, installation, and recovery operations without the presence of loadable media-based EFI drivers."

158. USB-based mass storage device complies with USB specifications

Required

If a USB-based mass-storage device—including tape, UHD floppy drive, and CD drive—is implemented in a server system, it must meet the requirements in this design guide and the requirements defined in Universal Serial Bus Mass Storage Class Specification Overview 1.0 or later.

159. IEEE 1394-based mass storage complies with 1394 OpenHCI 1.1

Required

If an IEEE 1394 storage device is implemented in a server system, it must meet all IEEE 1394 requirements in this design guide and comply with OpenHCI 1.1.

A removable IEEE 1394 mass storage device must not be the primary boot device.

160. Drivers for devices that use SBP-2 command protocols follow Windows 2000 guidelines

Required

Drivers for devices using the SBP-2 protocol must conform to the guidelines in "SBP-2 Support and Windows 2000" at http://www.microsoft.com/hwdev/print/sbp2_w2000.htm.


SCSI Controllers and Peripherals

SCSI is a flexible I/O bus that is used in the design of a variety of peripherals, including disk drives, CD drives, tape drives, magneto-optical drives, and scanners. This section presents the requirements for SCSI hardware that is compatible with Windows 2000, including adapters, peripherals, and any device that uses a SCSI controller.

161. System includes SCSI host controller and SCSI peripherals

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

The SCSI host adapter is the circuitry that serves as an interface between the system and one or more SCSI peripherals. A host adapter can be a card that plugs into the system’s expansion bus, such as a PCI card, or it can be designed directly into the system board set.

The host controller must support PCI bus mastering, with bus mastering enabled by default.

Recommendation

Recommended: Fibre Channel, especially for servers running Windows 2000 Advanced Server or Datacenter Server.

Note: Servers that implement Fibre Channel as the storage connection are not required to also provide SCSI capabilities.

162. SCSI controllers with external connectors that can function as cluster nodes provide multi-initiator support

Required

Multi-initiator support allows two SCSI controllers—each installed in a separate computer system—to coexist on a shared SCSI bus with a set of shared devices.

For use in a system intended as a node in a cluster using shared SCSI, the SCSI IDs must be changeable from the default SCSI controller ID of 7, and the boot-time SCSI bus reset operation must be able to be disabled on each controller attached to a shared bus.

For any SCSI controller with external connectors that can be used as a node in a cluster, as described previously, the connector must be clearly labeled as available for cluster connections. This labeling must be positioned so that it is clearly visible to a user when attaching external devices to the affected external connector.

163. Bus type is clearly indicated on connectors for all adapters, peripherals, cables, and terminators

Required

Connectors for each Fibre Channel or SCSI adapter, peripheral, cable, and terminator must be clearly labeled to show the bus type. All external SCSI connectors must display the appropriate SCSI icon defined in SCSI-3 Parallel Interface (SPI) specification, Annex F, plus any clarifying abbreviations or acronyms. The following shows the related acronyms and their definitions:

  • Single-ended (SGL or SE). The most commonly used signal type, such as found in home PCs and high-end workstations.
  • Low voltage differential (LVD). A signaling method similar to Differential (DIFF) but with lower signaling voltages supporting higher transfer rates.
  • High voltage differential (HVD). A signaling method similar to DIFF but with higher signaling voltages.
  • Differential (DIFF). A signaling method that employs differential drivers and receivers to improve signal-to-noise rations and increase maximum cable lengths. This method includes both LVD and HVD types.

164. Differential devices support DIFFSENS as defined in SPI-3 standard

Required

Without DIFFSENS, the differential bus drivers or a single-ended device will suffer fatal thermal damage if a single-ended device is put on a differential bus.

The specification for DIFFSENS is defined in Section 5.4.2 of the SPI-3 standard.

165. Automatic termination circuit and SCSI terminators comply with SCSI-3

Required

Parallel SCSI add-on adapters and on-board controllers must use automatic termination that allows a user to add external devices without removing the server case. Terminators used in the SCSI host adapter must be regulated terminators, which are also known as active, SCSI-3 SPI, SCSI-2 alternative-2, or Boulay terminators. SCSI termination built onto internal cables must meet the SCSI-3 specification.

166. Terminator power is supplied to the SCSI bus, with over-current protection

Required

The host adapter must supply terminator power (TERMPWR) to the SCSI bus for system-board implementations using PCI or another expansion bus. All terminators on the external SCSI bus must be powered from the TERMPWR lines in the SCSI bus.

In addition, the circuit that supplies TERMPWR must have overcurrent protection built into it. Devices that provide TERMPWR must also provide some means of limiting the current through use of a self-resetting device. For example, a positive-temperature coefficient device or circuit breaker can be designed into the circuit. These devices open during an over-current condition and close after the condition ends.

167. External connector complies with SCSI-2 or later

Required

If an external connector is implemented, it must meet the requirements defined in SCSI-2 or a later specification.

168. Controller and peripherals implement SCSI data protection signal

Required

All SCSI peripherals and the SCSI host adapter must implement the SCSI bus data protection signal defined in the SPI standard, and data protection must be enabled by default.

169. SCSI connections use keyed and shrouded connectors

Required

For internal and external configurations, the SCSI bus cable must be plugged into shrouded and keyed connectors on the host adapter and devices. This ensures that the cable is properly positioned so the user cannot plug in cables incorrectly. For internal configurations, pin 1 orientation must be designated on one edge of the ribbon cable and also on the keyed connector for the SCSI peripheral device.

For an external configuration, the SCSI connector must not use the same connector type as any other non-SCSI connector on the system.

170. External devices provide SCSI-3-compliant termination

Required

External SCSI devices must provide termination compliant with the SCSI-3 specifications per the requirements in guideline "#165. Automatic termination circuit and SCSI terminators comply with SCSI-3."

171. SCAM support is not present

Required

SCSI Configured AutoMatically (SCAM) capabilities must not be present on server systems or peripherals. SCAM is not supported by the Windows 2000 operating system; enabling SCAM can cause the system to become unstable or inoperable.

172. Hardware supports the STOP/START UNIT command as defined in SBC specification

Required

The hardware in SCSI peripherals must be able to fully recover from a software-initiated spin down without rebooting the system or cycling power. To properly support power management on SCSI drives and to ensure that the operating system responds to appropriate driver calls, be sure to correctly implement the STOP/START UNIT command as defined in the SCSI Block Commands specification.

173. STOP/START UNIT command can be used to decrease power consumption

Recommended

Wherever appropriate, for example, for storage disks, the STOP UNIT command can be used to decrease power consumption of the base platform.

174. SCSI devices that support hot-plugging comply with Annex D of SPI-3

Required

Annex D of SPI-3 addresses SCSI device insertion and removal, with and without command activity.


ATA Controllers and Peripherals

This section presents requirements for ATA hardware that is compatible with Windows 2000, including adapters, peripherals, and any device that uses an ATA controller.

175. System does not use ATA host controller or peripherals

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

ATA disks should not be present in a server. If ATA is implemented in a system, the ATA host controller and peripherals must meet all related requirements for devices and drivers, and they must meet the requirements defined in this section.

ATA devices may not be used as the primary storage channel on a server running Windows 2000 Advanced Server or Datacenter Server. For these operating systems, the server can use an ATA device only as a boot or installation device. An exemption is allowed for Basic and SOHO class servers that are not designed for deployment with MSCS clustering.

176. Dual ATA adapters use single FIFO with asynchronous access or dual FIFOs and channels

Required

PCI dual ATA adapters must be designed so that either channel can be used at any time; the operating system must not have to serialize access between the primary and secondary channel. Therefore, either the two channels are totally independent or a hardware arbitrator protects anything shared, such as a programmed I/O (PIO) read pre-fetch buffer.

A design implementing a single first in/first out (FIFO) with a hardware solution to synchronize access to both channels meets this requirement if the design does not require that a request on one channel be completed before another can be started. A software-based solution is not acceptable.

ATA-based systems must be tested with ATA DMA enabled; the system must not have an embedded single-FIFO dual-channel ATA controller.

EFI Note

Section 5.0 of the CIP BIOS Boot 1.01 defines the implementation for dual asynchronous channels. Note that this particular issue is also relevant for EFI systems, and designers of these systems will also use this specification for clarification of this particular implementation issue even though the rest of this specification is superseded by EFI.

Dual-channel controllers that require special software to serialize channel I/O for a single prefetch FIFO do not meet these requirements. Such designs require serial access to one of four devices, defeating the primary advantage of asynchronous dual-channel controllers. Furthermore, such devices are non-standard and require custom driver support.

177. ATA controller and peripherals comply with ATA/ATAPI-5 standard commands for features implemented and support Ultra-DMA (ATA/33, minimum)

Required

All controllers and ATA peripherals must support Ultra DMA (also known as Ultra-ATA) at transfer rates up to 33 MB per second as defined in ATA/ATAPI-5. In addition to improved transfer rates, Ultra DMA also provides error checking for improved robustness over previous ATA implementations. PCI chipsets must implement DMA as defined in SFF 8038i.

ATA drives must comply with ATA-5, which defines the programming register set for PCI ATA bus master DMA, to ensure fully featured hardware and Windows-compatible device driver support.

Support for ATA Bus Master DMA:

  • Required for ATA controllers
  • Required for ATA devices and ATAPI peripherals, including CD and DVD devices
  • Recommended for ATA/ATAPI tape drives
  • Recommended for ATAPI removable media drives

Recommendation

Recommended support includes:

  • For all systems: Controller and peripherals support Ultra-DMA/66.
  • For IA-32 BIOS boot systems: The system BIOS should configure the drive and host controller, optimized for Ultra DMA operation if possible, though the PIO mode must continue to work. The ACPI software should also support the restoration of these settings in ACPI control methods _GTM, _STM, and _GTF. There are no standard registers for these ACPI control methods if the controller loses timing context across a suspend and resume cycle. The BIOS pre-operating system boot disk services, INT13h read and write, need not actually use Ultra DMA for access to the drive prior to operating system boot. Definitions for these ACPI control methods can be found in Section 10 of ACPI 1.0b.
  • For EFI systems: The system firmware should configure the drive and host controller, optimized for Ultra DMA operation if possible, though the PIO mode must continue to work. The ACPI software should also support the restoration of these settings in ACPI control methods _GTM, _STM, and _GTF. There are no standard registers for these ACPI control methods if the controller loses timing context across a suspend and resume cycle. These ACPI control methods are defined in Section 10.8 of ACPI 2.0.

See also the BIOS recommendations in guideline "#12. System firmware meets general boot support requirements."

178. ATA controller and peripheral connections include Pin 1 cable designation with keyed and shrouded connectors

Required

Pin 1 orientation must be designated by one edge of the ribbon cable and also on the keyed connector of the ATA or ATAPI controller and peripheral device. Designation of the keyed connector must be clearly indicated on or near the connector.

179. ATAPI peripherals comply with ATA/ATAPI-5 standard commands for features implemented

Required

The ATA/ATAPI-5 standard defines the fundamental hardware and software design guidelines for ATAPI devices. See also guideline "# 147. System and Option ROMs support Int 13h Extensions on IA-32 BIOS boot systems."

180. ATAPI devices support DEVICE RESET command

Required

ATAPI devices must respond to the DEVICE RESET command regardless of their internal state, as defined in the ATA/ATAPI-5 standard. The controller can be reset by going into a power-on state (requests cleared, signature present), but any non-default mode values must be left in their current state with the DRV bit unchanged.

Devices that do not implement the PACKET command feature set, such as hard disk drives, must not implement the DEVICE RESET command.

181. ATA/ATAPI device supports ATA STANDBY command

Required

The ATA drive must implement the ATA STANDBY command according to the ATA standard. This command is defined in ATA/ATAPI-5.

The hard disk drive should spin up and be able to complete a Read operation within 10 seconds of applying power or leaving ATA STANDBY mode and transitioning to ATA ACTIVE, as specified in the Storage Device Class Power Management Reference Specification, Version 1.0 or later.


Fibre Channel Controllers and Peripherals

This section presents requirements for Windows 2000–compatible adapters, peripherals, and any devices that use Fibre Channel technology.

182. System includes Fibre Channel controller and peripherals

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Recommended | Recommended
SOHO: | Optional | Optional | Optional

Fibre Channel is a technology for 1 gigabit per second or greater data transfer that maps common transport protocols such as SCSI and IP, merging networking and high-speed I/O in a single connectivity technology. It is an open standard, defined by ANSI and Open System Interface (OSI) standards, that operates over copper and fiber-optic cabling at distances of up to 10 km.

If implemented on a server system, Fibre Channel must use the X3T11 Private Loop Direct Attach (PLDA) profile as the storage base to use the native Windows 2000 support. The Physical Layers implementation must comply with Fibre Channel Physical (FC-PH), Revision 4.3 or later. For more information from the Fibre Channel Association, see http://www.fibrechannel.com.


Erasable Disk Drives

This section presents the requirements for erasable disk drives provided with a server system or designed for use with Windows 2000 Server. This category includes 3.5-inch, 5.25-inch, and 12-inch magneto-optical or phase-change drives and media. It does not include CD, CD-R, CD-RW, and DVD drives or media.

183. SCSI erasable drives support SCSI commands

Required

The following commands or features must be supported by the device’s driver:

  • Erase (2C): full side and selected block erase
  • Format requirements reported with Format command
  • Mode Select: write cache disable
  • Mode Sense: total spare blocks available, write protect status
  • Prevent/Allow Medium Removal, Start/Stop Unit
  • Read (28), Verify (2F)
  • Reassign Blocks, Read Defect Data
  • Reserve, Release
  • Seek (SCSI CDB Opcode – 2B)
  • Test Unit Ready, Request Sense, Read Capacity, Inquiry
  • Write (2A), Write and Verify (2E)
  • Write without pre-erase, for erasable optical only

Recommendation

Recommended: Inquiry with support for reporting serial number or other unique unit ID should be supported by the device’s driver.


CD and DVD Drives

This section presents the requirements for CD and DVD drives.

184. System includes CD or DVD drive or other method for installing the operating system

Required

The server system must include either CD or DVD drive support or another method to enable the installation (or reinstallation) of the operating system.

CD Drive Requirements

This section summarizes requirements for CD drives. A CD drive is not required if another method is provided to support operating system installation. However, if a CD drive is present, it must comply with these requirements.

185. CD drive provides 8x or higher performance

Required

This requirement is intended to set the minimum speed needed for production-level CD reading on Windows platforms. This requirement applies to the minimum read speed (8x) on any production level CD media, such as application software, at any location on the disc. This requirement does not apply to end-user recorded CD data discs, or discs being read in error-correcting, defect management mode.

186. CD drive is CD-Enhanced compatible

Required

The CD drive must be able to mount multisession CD-ROM discs, even if track 1 is Red Book audio.

CD-Enhanced support must comply with Blue Book standards, as defined in the MMC-2 standard.

Recommendation

Recommended: Use of the Sony ReadTOC method for SCSI-2 multisession support, as noted in the MMC-2 standard.

187. CD drive supports specified logical and physical CD formats

Required

At a minimum, the CD device must be compatible with the following formats to ensure cross-media compatibility, based on compliance with the Optical Storage Technology Association (OSTA) MultiRead Specification for CD-ROM, CD-R, CD-R/RW, and DVD-ROM Devices, Version 1.11:

  • Logical formats: CD Red Book (CD-Audio), Yellow Book (CD-ROM), Orange Book parts II and III (packet writing if recordable), White Book, Blue Book, and Universal Disk Format Specification, Version 1.5 and 2.0
  • Physical formats: ROM (stamped), and Orange Book part II (CD-R) and part II (CD-RW)

Note: Any ATAPI CD drive designed to play back CD-I content must return a minimum of two track entries for the READ-TOC (0x43) command. These two track entries must be a track 01 entry and a track 0xAA entry for the lead-out address. Drives that do not comply with this minimum requirement cannot play back CD-I movies.

188. ATA/ATAPI CD drive complies with MMC-2

Required

CD drives attached to the system using the ATA interface must support MMC-2.

189. CD drive supports multisession and compatibility forms of the READ_TOC command

Required

Both multisession forms (01b and 10b), as well as the compatibility form (00b) of the READ_TOC command, must be implemented. This requirement ensures complete support for CD multisession capabilities.

190. ATA/ATAPI CD changer meets MMC-2 standard

Required

If an ATAPI-compatible CD changer is present that has a capacity for seven or fewer discs, the device must comply with MMC-2 standard.


DVD Drive Requirements

This section summarizes requirements for supporting DVD drives. A DVD drive is not required in a server system, but if present, it must comply with these requirements. Systems targeted for use with Windows 2000 Advanced Server or Datacenter Server should provide DVD drive capabilities.

For more information about DVD support under Windows 2000, see the articles at http://www.microsoft.com/hwdev/dvd/.

191. DVD device provides 2 MB minimum transfer rate or better performance anywhere on the disk

Required

This requirement is intended to set the minimum speed needed for DVD-Video playback during MPEG-2 decoding on Windows platforms. This requirement applies to the minimum read speed (2 MB/s) on any production-level DVD-Video media, at any location on the disc. This requirement does not apply to end-user recorded DVD data discs, or discs being read in error-correcting, defect management mode.

192. DVD drive meets minimum compatibility requirements

Required

DVD drives must support all the functionality of CD drives as outlined in this document. The DVD drive must also be compatible with the following formats to ensure that the DVD drive can read earlier media:

  • Physical formats: ROM (stamped), Orange Book part II (CD-R) and part III (CD-RW), and ECMA-267 and ECMA-268 (DVD-ROM).

Conforming to OSTA MultiRead Specification, Version 1.11, indicates compliance with all of these CD compatibility requirements.

193. DVD drive supports defect management

Required

The drive must support the defect management that is transparent to the operating system, according to industry standards. Defect management for DVD-RAM media is defined in DVD Specifications for Rewritable Disc, Part 1: Physical Specifications, published by Toshiba Corporation. Defect management for DVD+RW is defined in ECMA-274.

194. DVD-Video playback, if present, meets DVD-Video playback requirements

Required

Servers that provide DVD drives only as storage devices do not have to include the additional capabilities required for DVD-Video playback on a local display device. Only servers that provide the specific feature of DVD-Video playback to the local server display must meet the DVD-Video playback requirements specified in these guidelines.

The following capabilities are required for DVD drives that support DVD-Video playback:

  • DVD decoder driver correctly handles media types, time discontinuity, and decode-rate adjustment. This requirement specifies that the vendor-supplied minidrivers for DVD, MPEG-2, and AC-3 decoders have the following capabilities:
  • Use correct media types. This includes validating all format block fields on connection and on every IPin::QueryAccept message.
  • Query for IMediaSample2 on every received media sample to test for a time discontinuity bit. It is also acceptable to query on every video/audio frame to reduce CPU overhead.
  • Adjust decode rate in response to IPin::NewSegment() calls for video and subpicture.
  • DVD decoder supports subpicture compositing and closed captioning. The system must be capable of displaying subpicture data as well as providing closed-captioning support for all such data stored on the disc. This requires YUV offscreen surface support, as defined later in this list.

Subpicture streams must be supported as defined in the DVD Specification, Version 1.0, from Toshiba Corporation. Alpha blending, or a simulation implemented in the driver, is required for static menus.

  • Subpicture decoder correctly handles subpicture properties and other functions. The minidriver for the subpicture decoder must be able to correctly handle the following:
  • Set the subpicture property
  • Turn subpicture compositing on and off
  • Set the highlight rect parameters

For information, see the Microsoft DirectX® SDK (provided in the Microsoft Platform SDK) and the DirectX information in Windows 2000 DDK.

  • System supports seamless DVD-Video 1.0 navigation. This requirement includes menu navigation and video selection, and language and subpicture track selection to support the user’s ability to navigate DVD-Video discs. Test sources include, but are not limited to, the following:
  • Matsushita Electronics Incorporated (MEI) test disc
  • Joe Kane Productions Video Essentials disc
  • Microsoft test disc
  • MPEG-2 playback provides high-quality video output. MPEG-2 solutions must provide high-quality video display output, as defined by the following:
  • Smooth frame delivery, with all video fields and frames from the MPEG source decoded.
  • Audio and video synchronized to within one and a half video frames, with synchronization not allowed to drift out over time.
  • No tearing—provide proper video buffering, such as double buffering.
  • Correct display of multiple-aspect ratio content. The material should be displayed according to the aspect ratio information in the MPEG header.

This requires support for YUV offscreen surface and up/down interpolated scaling, as defined in the following requirement.

  • Graphics adapter supports DVD movie playback features. Any system with a DVD drive that includes the ability to play back MPEG-2 data streams must meet the requirements listed here. However, this requirement does not apply for systems that include DVD drive for storage purposes but do not include DVD-Video playback software. The following capabilities are required for solutions that use either hardware or software MPEG-2 decoders:
  • Up and down scaling with bilinear interpolation

Recommendation

Recommended: 5 taps, both vertically and horizontally

  • YUV 4:2:2 and 4:2:0 planar offscreen surface support
  • VGA destination color keying for video rectangle
  • AGP or PCI bus mastering


Backup Devices

Backup devices are an important part of guaranteeing data availability at a corporate site. Windows 2000 Server includes a graphical tool named Backup that supports backup of Windows 2000 Server-based data.

If a backup device is provided in a server system, it must comply with the requirements and recommendations in this section.

195. System includes device for local backup

Recommended

System administrators will commonly want offline backup capabilities to be available. If a backup device is provided with a server system, either as a built-in or peripheral add-on device, it must meet the minimum requirements defined in this section.

196. Single-backup device meets minimum capacity requirements

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | 10 GB Required | 10 GB Required | 10 GB Required
Enterprise: | 20 GB Required | 20 GB Required | 20 GB Required
SOHO: | 10 GB Required | 10 GB Required | 10 GB Required

Minimum uncompressed, formatted storage capacity is required for any backup device designed to comply with these guidelines.

Recommendation

Recommended: 20 GB minimum capacity for Basic and SOHO servers.

197. Backup device meets industry standards

Required

A SCSI tape or SCSI backup peripheral must comply with the appropriate SCSI command set and with the requirements defined in "SCSI Controllers and Peripherals" earlier in this chapter.

ATA is not recommended for servers, but if an ATA backup peripheral is implemented, it must comply with the appropriate ATA/ATAPI 5 standard sections covering that device’s operation.

198. Driver integrated with Removable Storage Manager

Required

For a backup device designed for Windows 2000 Server, the manufacturer must provide a Windows 2000 driver that integrates with Removable Storage Manager (RSM), formerly Windows NT Media Services. This ensures that applications which are RSM-aware (such as the native Windows 2000 backup and hierarchical storage management applications) will be properly able to utilize the backup device.

RSM is intended to allow software that accesses backup devices to be independent of the specific device. A hardware vendor can also choose to include a backup application. However, such software should also be integrated with and use the RSM infrastructure.


Media Changers

This section defines requirements for media changers.

CD Changers

This section provides requirements for CD changers.

There is no requirement or recommendation for providing a CD changer with a server system, but if present or designed to be compatible with Windows 2000, it must comply with these requirements.

199. If present, CD changer for seven or fewer discs meets MMC-2 standard

Required

If an ATAPI-compatible CD changer is present that has a capacity for seven or fewer discs, the device must comply with MMC-2 standard.

Tape and Optical Disk Changers

This section provides requirements for tape and optical disk changers. There is no requirement or recommendation for providing a tape or optical disk changer, but if a device is present or is designed to be compatible with Windows 2000, it must meet the requirements defined in this section.

This includes changers that support the following drive/media types:

  • 3.5-inch, 5.25-inch, and 12-inch magneto-optical or phase-change drives and media
  • All magnetic tape drives and media

It does not include changers that support CD-ROM, CD-R, CD-RW, or DVD drive/media types.

200. SCSI changer and drive support auto-configuration

Required

To meet requirements for auto-configuration of changers and their associated drives, the following changer requirements and configuration restrictions are defined:

  • For changers where autoconfiguration under RSM control is a targeted feature, all changer tape or optical disk drives must be connected to the same SCSI bus as the changer.

Changer systems that are not configured this way will not be autoconfigurable under RSM in Windows 2000 and must provide documentation that describes the appropriate manual configuration process for use with RSM. Examples of proper documentation are available in Appendix A of Windows NT Removable Storage Manager Programming Documentation, at http://www.highground.com/developer/documents/ntmsdocu.htm.

The Removable Storage Manager functions are documented in the Microsoft Platform SDK at http://msdn.microsoft.com/library/psdk/zaw/ntms_api_5nz9.htm.

  • The changer’s Read Element Status–Data Transfer Element Descriptor must support the reporting of the SCSI Bus Address and LUN of each drive in the library unit.
  • If drive cleaning is required and can be automated, a specific slot that is accessible by way of a Move Medium command must be designated in the Operator’s Guide.
  • The changer must be able to report if a bar-code reader is installed in the unit.
  • The changer must be able to report on the current of (magazine) slots and drives by using the Read Element Status command.

Recommendation

Recommended for changers: SCSI changers should avoid behaviors as a side effect of SCSI bus reset which unduly delay operations of the changer and availability of media via the changer. An example would be a lengthy auto-inventory process which delays media loading.

201. SCSI tape and optical disk changers support SCSI commands

Required

The following commands or features must be supported by the changer:

  • Initialize Element Status (with/without bar-code reading)
  • Mode Sense—Pages 1D, 1E, 1F
  • Move Medium
  • Prevent/Allow Media Removal (door access and IEPORT locking)
  • Read Element Status
  • Reserve, Release
  • Send Volume Tag, Request Volume Element Address
  • Test Unit Ready, Request Sense, Inquiry

Recommendation

Recommended: Inquiry with support for reporting serial number or other unique unit ID should be supported by the changer.


Chapter 6 Physical Design and Hardware Security Requirements

This chapter summarizes physical design and hardware security requirements and recommendations.

Physical Design Requirements

This section presents the requirements related to the physical design of servers.

202. Icons are provided for all external connectors

Required

This requirement helps ensure that the end user can correctly make the physical connections required for adding a device to a system. This requirement includes the following:

  • Wherever possible, keyed or shrouded connectors or other configurations should be used to prevent misconnection. The physical design of the connector must ensure that the user cannot mistakenly insert the connector into the wrong port.
  • Icons are provided for all external connectors. The icons can be molded, printed, or affixed as permanent stickers, which can include text. Icons can be based on existing vendor designs or on the examples shown at http://www.pcdesguide.com/documents/icons.htm.
  • Systems and peripherals must use a color-coding scheme for connectors and ports.

Recommendation

The following list displays the recommendation for standard color-coding of connectors and ports. The selection of these specific colors was done using criteria established by Human Factors and Industrial Design professionals from multiple companies who are involved in the design of computer hardware.

Connector | Recommended color | Pantone
Analog VGA | Blue | 661C
Audio line in | Light blue | 284C
Audio line out | Lime | 577C
Digital monitor/flat panel | White |
IEEE 1394 | Grey | 424C
Microphone | Pink | 701C
MIDI/game | Gold | 131C
Parallel | Burgundy | 235C
PS/2-compatible keyboard | Purple | 2715C
PS/2-compatible mouse | Green | 3395C
Serial | Teal or Turquoise | 322C
Speaker out/subwoofer | Orange | 157C
Right-to-left speaker | Brown | 4645C
USB | Black | 426C
Video out | Yellow | 123C
SCSI, network, telephone, modem, and so on | None | —

It is recommended that retail peripherals also implement color-coding, and those that do are required to use the colors in order to correspond with servers that adopt this scheme.

Note: It is recognized that the design for legacy ports, such as the PS/2-compatible mouse and keyboard ports, analog audio and video jacks, and the microphone and speaker jacks, will not change and therefore cannot fully meet this requirement. However, icons and labels must be provided wherever possible to help the user make the correct connections.

Color coding is required for server systems, but the color codes listed earlier are only recommended. The intent is to standardize the industry on a single color-coding scheme; these specific colors will become a requirement for systems in future versions of the design guidelines.

For the following classes of retail peripherals, color-coding is required and must follow the color codes listed earlier. These classes are:

  • Audio peripherals
  • Display peripherals
  • USB peripherals
  • IEEE 1394 peripherals

203. All expansion slots in the system are accessible for users to insert cards

Required

The space for expansion cards that will reside in associated expansion slots cannot be physically blocked by components or devices provided with the system. However, this requirement does not exclude configurations that provide half-height cards for some slots, passive back planes for connectors, and so on. It is understood that in order to install expansion cards in some expansion slot implementations, users might have to temporarily move other system components to gain access to the slot. In general, designers should minimize this juggling as much as possible.

204. System and device design include protected switches

Recommended

Switches can be covered with a hood or other protection to prevent inadvertent switching. Locks can also be provided to prevent unauthorized access.

205. System design includes locking case

Recommended

The computer case can be protected with key locks to prevent unauthorized access. Other recommended features include:

  • Key lock removes the computer case without additional tools—if this can be done while maintaining compliance with other safety standards.
  • Software management of physical components as documented in WHIIG 1.0, which also defines the Windows-specific requirements of the Wired for Management Baseline Specification, Version 2.0, for hardware instrumentation.

206. System and device design include positive retention connectors

Recommended

Positive retention mechanisms should be implemented to ensure connections. The retention mechanism should be operated by hand, requiring no tools for mating and breaking the connection. It is recognized that certain legacy connector implementations, such as PS/2-compatible pointing devices and keyboards, will not generally allow this. However, locking cable connections provide a valuable feature for end users.

207. If present on an IA-32 system, parallel port design provides sufficient space for connector assembly

Required

The parallel port design must provide enough space between the connectors and the surrounding enclosure to allow for a mating connector, connector shell, and latch assembly.

Recommendation

The IEEE 1284 specification recommends an IEEE 1284-C connector for all new ports and devices.

Note: Parallel ports must not be present on IA-64 systems.


Hardware Security Requirements

This section summarizes the system hardware security requirements and recommendations.

208. C2 evaluation for hardware

Recommended

C2-evaluated hardware meets requirements defined in the Orange Book.

For hardware designed for customers outside the U.S., equivalent evaluation might be defined in local standards, such as F-C2/E3 ratings in Europe.

209. Peripherals follow hardware security recommendations

Recommended

OEM-specific solutions can be implemented to meet these recommendations. The following hardware security features are recommended:

  • External drive devices should have locking capabilities. Each removable media device on a server system should be capable of being locked to prevent unauthorized access to data. A single locked door covering the drives is sufficient. The locking mechanism must render the device useless, whether locking is done electronically or mechanically.
  • Computer case and switches should have locking capabilities to prevent unauthorized internal access. An OEM-specific method can be implemented, either electronically or mechanically.
  • Remote software management should be supported for physical components.
  • Controls and remote alerts should be provided for chassis-open intrusion.

For servers running either Windows 2000 Server or Windows 2000 Advanced Server or Datacenter Server, smart card readers and cards should be provided. If provided with a server system, smart card devices must be compatible with Interoperability Specification for ICCs and Personal Computer Systems, available at http://www.pcscworkgroup.com/.

In addition, smart card readers and device drivers must be Plug and Play-compliant and must be implemented as described in "Smart Card Drivers" in the Windows 2000 DDK. Smart card applications and service-provider dynamic link libraries (DLLs) must adhere to the Microsoft Smart Card SDK that is part of the Microsoft Platform SDK.


Chapter 7 Reliability, Availability, and Serviceability Requirements

These requirements and recommendations relate to ease of use, ease of maintenance, manageability, and failure tolerance. Design guidelines that make server configuration, management, and servicing easier for end users and administrators are defined to help reduce the total cost of ownership for servers.

Reducing the total cost of ownership is an important goal for servers; a key priority in this effort for servers is minimizing downtime. This goal is achieved through mechanisms for backup and reliability, remote management, and emergency and preboot management.


Backup and Reliability Requirements

This section summarizes the backup and reliability requirements and recommendations for servers.

Backup Hardware

This section defines the requirements for backup hardware for servers.

210. System includes integrated backup solution

Recommended

An integrated tape drive or other device should be included in the system. Although the recommended method to back up files on a server is to use a backup service under Windows 2000 Server, system administrators will commonly want offline backup capabilities to be available.

For information about hardware requirements related to backup capabilities, such as tape drives and so on, see Chapter 5, "Storage Device Requirements."


Power Supply

This section defines the guaranteed power requirements for servers.

211. System includes UPS provided with system

Recommended

For servers deployed in many corporate environments, the more common choice will be to provide guaranteed power for the server room.

212. System includes power supply protection using N+1 (extra unit)

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Recommended | Recommended

The system overvoltage/undervoltage protection and power supply switch-over circuitry should have the capability to regulate according to the system load. For each voltage used in the system, the output voltages of the redundant power supplies should be within the range of values that can guarantee the proper operation of the system, no matter which supply is active. Power-supply switch-over should occur swiftly enough to maintain normal server system operation.

213. System supports replacement of power supplies

Required

Systems are required to allow for the replacement of the module (or modules) constituting their source of power by a qualified individual in the field. The minimum requirement is that this capability be provided when the system is powered off, that is, when the server is in a "down" condition.

Recommendation

Recommended: Hot-swapping capabilities for power supply replacement and power supply redundancy.

214. System supports replacement of fans

Required

Systems are required to allow for the replacement of the fan (or fans) by a qualified individual in the field. The minimum requirement is that this capability be provided when the system is powered off, that is, when the server is in a "down" condition.

Recommendation

Recommended: Hot-swap fans should be implemented to maximize server up time.

215. System includes local hot-swap power supply replacement indicators

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

Any system that provides hot-swap power supply replacement and power supply redundancy should have local indicators that unambiguously indicate the supplies that must be replaced. These indicators guide service personnel to replace the correct power supply. Automatic retention mechanisms that prevent incorrect supply removal also satisfy this guideline.


Fault-Tolerant Hardware

This section provides design guidelines for fault-tolerance features and capabilities.

216. System supports multiple hard drives

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

Bus mastering is required for the drive controllers. Use of multiple hard drives and controllers in a server system provides both performance and reliability benefits. It is not a requirement that the drives all be physically housed in the server system chassis.

Recommendation

Recommended: Hot-swappable drives.

217. System includes intelligent RAID controller with adequate storage capacity

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

An intelligent RAID controller—where the controller itself has the capability to run the array management software locally rather than simply executing disk accesses for host-based array software—provides the benefit of reduced demands on the host processor or processors, thereby freeing those computing resources and allowing their use by other tasks. The intelligent RAID controller may be internal to the server chassis, or within an external drive enclosure.

If an intelligent RAID controller is provided in a system, it should be capable of handling sufficient amounts of disk storage to fulfill the needs of the targeted usage model for that server. These needs will vary based on the storage-intensive nature of the server’s tasks.

218. System supports at least one of RAID 1, 5, or 1/0

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

RAID 1 and RAID 1/0 are recommended. RAID 5 is also acceptable. RAID 0 (for enhanced performance but no added reliability) is optional.

219. RAID support includes notification of failed drive

Required

If RAID support is implemented, notification of a failed drive must be provided by the disk subsystem, with notification sent to the system administrator.

220. RAID subsystem supports automatic replacement of failed drive

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

The RAID subsystem must provide automatic replacement of a failed drive by a standby disk and must rebuild lost data without interfering with system operations.

221. RAID subsystem supports manual replacement of failed drive

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

The RAID subsystem must provide for manual replacement of a failed drive without shutting down or halting the system. The subsystem must also allow lost data to be rebuilt without interfering with system operations beyond some decreased performance of drive array access.


Serviceability Requirements

This section provides design guidelines for serviceability features and capabilities.

222. IA-32 system includes protected forced dump switch or other mechanism for system diagnosis

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Required | Required | Required
SOHO: | Recommended | Required | Recommended

The system should include a protected switch or other mechanism to force an NMI on a stalled system. This device permits the system to perform a memory dump that can then be used for diagnosis of system failures. If implemented, this device must be protected in such a way that only an authorized administrator can perform this action.

For additional information on the "dump switch" support in Windows 2000, which may be helpful for designers of IA-32 systems, please see http://www.microsoft.com/hwdev/debugging/dmpsw.htm. Note that this white paper presents only concept suggestions for designers and is not intended to provide precise implementation detail.


High Availability Requirements

This section summarizes the requirements for high availability.

Through ACPI and OnNow power management capabilities, Windows 2000 allows more control of dynamic configuration changes and power state changes. These features help implementers in handling event-based issues such as lights that are keyed to system failures, pending failures, or system power states.

223. System includes alert indicators for occurrence of failure

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

Alert indicators should be provided that indicate hard failure. In addition to visual alerting mechanisms, a design can also provide software alerts such as paging, fax, or e-mail notifications.

The following are required sources of alert indicators for hard failures for systems running Windows 2000 Advanced Server and Datacenter Server. These indicators are recommended for servers running other server versions of Windows 2000.

  • Cooling fan malfunction, including system fans and power supply fans
  • System and processor over-temperature
  • Power supply over-temperature (if implemented)
  • Disk drive error
  • N+1 power module (if implemented) failure

Recommendation

Recommended: These sources of alert indicators for hard failures are recommended for all servers:

  • Chassis cover open (intrusion)
  • NMI, processor internal error, and time-out of watchdog timer
  • Processor power failure

224. Hot-swappable drive includes a local disk drive replacement indicator

Required

A hot-swappable drive must have a local indicator that shows which drive or drives are ready for replacement, facilitating the servicing process and improving reliability by reducing possible errors.

This indicator should be on the drive chassis, not on the screen. The Device Bay "eject" signal can be used to activate a replacement indicator. Designers can choose to use existing LEDs for dual purposes to fulfill this requirement, but the LED display should clearly show when a drive is ready for removal, as opposed to other information the display would normally provide.

For systems with multiple drives, an individual replacement indicator should be physically associated with each hot-swappable drive slot.

225. System includes alert indicators for imminence of failure

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

Alert indicators that indicate informative failure are required for servers running Advanced Server or Datacenter Server and should be provided for all servers. The hard failure and informative failure indicators cannot be on simultaneously. In addition to visual alerting mechanisms, a design can also provide software alerts such as paging, fax, or e-mail notifications.

The following are required sources of alert indicators for imminent failures for systems running Windows 2000 Advanced Server and Datacenter Server. These are recommended for servers running other server versions of Windows 2000:

  • Abnormal temperature of processor or inside chassis
  • AC power line failure (operated by UPS if present)

226. IA-64 system supports monitoring for power and down conditions

Required

The following monitoring capabilities are required for the hardware, SAL and firmware on IA-64 systems.

  • Platform supports platform-down monitoring. Platform-down detection is a hardware mechanism in the platform that supports the detection of system software or processor hangs. A hardware watchdog timer is one way to implement this capability. For example, a common hardware watchdog implementation would allow system software to periodically access the timer in order to keep it from expiring. Upon expiration, the timer would typically provide a selectable set of actions, such as system power down, hard reset, power cycle, priority interrupt, and so on.
  • Platform supports power supply fault monitoring. The platform must monitor the status of the primary power source. This includes redundant (for example, distributed) power supplies.


Manageability Baseline Requirements

This section presents server requirements related to the Wired for Management (WfM) initiative and the Zero Administration initiative for Windows. The WfM initiative seeks to raise the level of management capabilities on mobile, desktop, and server platforms. The Zero Administration initiative seeks to ensure a controlled, highly manageable enterprise.

The baseline for these requirements is WHIIG 1.0, which also defines the Windows 2000-specific requirements of the WfM 2.0 specification for hardware instrumentation.

Collectively, the items in this section represent the "Manageability Baseline" requirements.

Tips for implementing management capabilities. For manufacturers who want to implement management capabilities for server systems and components, these are the design steps to pursue:

  • Implement the recommended component instrumentation features defined for servers in WHIIG.
  • For those components that require WMI, ensure that WMI is enabled in device minidrivers as defined in "Supporting WMI" in the Windows 2000 DDK.
  • Refer to WHIIG for other driver requirements and design tips.
  • For all instrumented components, test against the baseline features required in WHIIG.
  • For each component, extend the WBEM and CIM schemas to expose the device’s custom features in any CIM-ready management browser.


General Manageability Baseline Requirements

This section defines requirements related to centralized control and configurability and BIOS support for system manageability.

227. Remote new system setup and service boot support use DHCP and TFTP

Recommended

The complete mechanism for remote new system setup is defined in PXE 2.1 or later.

If remote new system setup capabilities are implemented, there must be a way for this capability to be enabled or disabled by way of administrative control to maintain server security.

See also the requirement for the preboot execution environment in guideline "#13. IA-32 BIOS boot system supports remote/network boot, USB boot devices, and firmware update," and guideline "#14 IA-64 system complies with EFI 1.0 or later, with support for USB boot devices, firmware update, and PXE_BC, SERIAL_IO, and SIMPLE_NETWORK protocols."

228. Expansion devices can be remotely managed

Recommended

Devices provided as expansion devices should be capable of being remotely managed, ensuring that control and TCO policies can be realized. The requirements for remote management capabilities are defined in "Manageability Component Instrumentation Requirements" later in this chapter.

For example, for any implementation of a floppy drive, the floppy drive should be capable of being remotely disabled as a boot selection and should be able to be locked.

Certain devices are not required to have remote disabling capabilities, including the primary hard disk drive, the network adapter, and any standard devices that use legacy connections, such as a keyboard or pointing device that uses a PS/2 connection. However, it must be possible to use permissions, policies, or other methods to remotely manage capabilities such as hard disk access or to control certain users’ ability to change the MAC address or configuration settings for the network adapter.

If implemented, there must be a way to enable and disable this capability by way of administrative control to maintain server security.

See also the requirement for the firmware to ensure secure preboot access to hardware components in guideline "#12. System firmware meets general boot support requirements."


Manageability Component Instrumentation Requirements

Platform management information requirements are defined for two key areas:

  • Component instrumentation: Interfaces through which information is supplied by platform management components.
  • Management information providers: Interfaces used by applications to access platform management information.

229. System supports Windows Hardware Instrumentation Implementation Guidelines

Required

These guidelines are defined in WHIIG 1.0.

230. IA-64 hardware and firmware support IA-64 Machine Check Architecture

Required

Many features of 64-bit Windows depend on platform support for IA-64 Machine Check Architecture. IA-64 systems must implement hardware and firmware that support IA-64 Machine Check Architecture.

230.1. IA-64 system uses Machine Check Architecture for error reporting and logging

The IA-64 Machine Check Architecture has a complete method for reporting processor errors and many system errors. System designers must use the Machine Check Architecture for system-wide error reporting and logging. The Machine Check Architecture must be used to report platform errors, including errors within the system processors, memory, internal buses, and expansion buses.

Note: Certain established interfaces, such as TCP/IP in the networking space and SCSI in the storage space, have extensive error reporting and recovery mechanisms in their protocol stacks. Some interfaces (for example, serial ports, LPC, and so on) may have limited or no hardware support for reporting errors. Subsystems such as this are excluded from this requirement.

230.2. IA-64 firmware implements support for Machine Check Architecture

IA-64 system firmware must implement the IA-64 Machine Check Architecture. Using Machine Check Architecture, every firmware layer in the system may check for recoverable errors and log errors, and perform error recovery where possible. All machine check recovery code must use Machine Check Architecture firmware hooks.

Discontinue use of Platform Management Interrupt (PMI) for doing machine check and recovery.

230.3. IA-64 Machine Check Architecture supports code resources

All IA-64 Machine Check recovery code must use Machine Check Architecture firmware hooks as specified in SAL 2.7 or later. Platform machine check hardware must provide relevant status bits for all sources of hardware errors that need to be handled in Machine Check Abort code.

Discontinue use of PMI and NMI for performing machine check and error recovery.

231. IA-64 system supports event logging for critical events

Required

The hardware, SAL, and firmware on IA-64 systems must provide the capability to log all critical events. It is required that an event log be made available that can be accessed by management software.


Appendix A Server Requirements Checklist

This appendix summarizes all the requirements listed for server systems in this guide. If a recommended feature is implemented, it must meet the requirements defined in this guide for that feature.

IA-32 Server Requirements Checklist

IA-32 General Component Requirements

1. System and components properly support all dates

Required

IA-32 System Microprocessor Requirements

2. Multiprocessor-capable system meets Windows requirements and minimum expansion requirements

Required

IA-32 Memory Requirements

3. For IA-32 system, installed memory meets minimum requirements

Windows 2000 Server, Small Business Server | Windows 2000 Advanced Server, Windows 2000 Datacenter Server
For 1–2 installed processors, 512 MB Required | For 1–4 installed processors, 1 GB Required
For more than 2 installed processors, 256 MB per installed processor Required | For more than 4 installed processors, 256 MB per installed processor, Required

5. For IA-32 system, memory capacity meets minimum requirements

Systems that provide support for <4 processors: 2GB Required
Systems that provide support for 4 or more processors: 8 GB Required

7. System memory includes ECC memory protection

Required

8. NUMA and NUMA-"lite" system design maintains near:far memory access time ratios of 1:3 or less

Recommended

IA-32 ACPI and Power Management Requirements

9. System design meets ACPI and related requirements

Required for all server types, with additional requirements for SOHO servers

10. Hardware design supports OnNow initiative

Required for all server types, with additional requirements for SOHO servers

11. System startup meets requirements for OnNow support

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Optional | Optional | Optional
Enterprise: | Optional | Optional | Optional
SOHO: | Required | Required | Required

IA-32 Startup Support Requirements

12. System firmware meets general boot support requirements

Required

13. IA-32 BIOS boot system supports remote/network boot, USB boot devices, and firmware update

Required

15. System provides a debug port solution

Required

IA-32 Plug and Play Requirements

16. System and device configuration meet Plug and Play requirements

Required

17. Unique Plug and Play ID is provided for each system device and add-on device

Required

18. "PNP" vendor code is used only to define a legacy device’s Compatible ID

Required

IA-32 "Headless Server" Requirements

19. IA-32 system provides headless server capabilities meeting Hardware Design Guide requirements

Required for Enterprise class systems
Recommended for Basic and SOHO class systems

20. IA-32 system that implements headless capabilities without management service processor provides serial headless support

Required if system implements headless support without a management service processor

21. IA-32 system that implements management service processor and external serial headless capability supports required external serial port and remote system reset

Required if the service processor exposes a UART interface via hardware to the operating system or if the serial port is the only full-time management connection

22. IA-32 system that implements a management service processor but no external serial connection meets reset and display redirection requirements

Required if system implements headless support with a management service processor

23. Uninterruptible power supply that has pass-through legacy serial port supports sharing of pass-through serial port with Windows headless capabilities

Recommended

IA-32 Other Requirements

24. IA-32 system includes APIC support

Required

27. System with no 8042 or other port 60h and port 64h based keyboard controller meets Hardware Design Guide requirements

Required

28. IA-32 system provides necessary ISR support

Required

IA-32 I/O Bus Requirements

29. System provides an I/O bus based on industry standard specification

Required

30. All PCI adapters function properly on system supporting more than 4 GB memory

Required

32. System supports a 64-bit PCI bus architecture

Required for all IA-64 systems
Required for all IA-32 systems that support more than 4 GB of system memory

33. PCI bus and devices comply with PCI 2.2 and other requirements

Required

35. System makes a best effort to provide each PCI slot and device type access to a non-shared interrupt line

Required

36. System does not contain ghost devices

Required

37. PCI-to-PCI bridges comply with PCI to PCI Bridge Specification 1.1

Required

38. System uses standard method to close BAR windows on nonsubtractive decode PCI bridges

Required

39. PCI devices do not use the <1 MB BAR type

Required

40. PCI devices decode only their own cycles

Required

41. VGA-compatible devices do not use non-video I/O ports

Required

42. PCI chipsets support Ultra DMA (ATA/33, minimum)

Required

43. Functions in a multifunction PCI device do not share writable PCI configuration space bits

Required

44. Devices use the PCI configuration space for their Plug and Play IDs

Required

45. Device IDs include PCI Subsystem IDs

Required

46. Interrupt routing is supported using ACPI

Required

47. System that supports hot swapping or hot plugging for any PCI device uses ACPI-based methods

Required

48. All 66-MHz and 64-bit PCI buses in a server system comply with PCI 2.2 and other requirements

Required

49. All PCI devices complete memory write transaction (as a target) within specified times

Required

50. All PCI components comply with PCI Bus Power Management Interface specification

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
Enterprise: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
SOHO: | Required | Required | Required

51. System that supports S3 or S4 state provides support for 3.3Vaux

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Recommended | Recommended
SOHO: | Required | Required | Required

52. PCI bus power states are correctly implemented

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
Enterprise: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
SOHO: | Required | Required | Required

54. PCI-X buses and devices, if present, meet requirements for device and driver support

Required

55. InfiniBand fabric connections, fabrics, and devices, if present, meet requirements for device and driver support

Required

IA-32 USB Requirements

56. System includes USB controller with at least one USB port

Required

57. All USB hardware complies with USB 1.1

Required

58. USB devices and drivers support maximum flexibility of hardware interface options

Required

59. System and devices comply with USB power management requirements

Required

60. USB devices comply with their related USB device class specifications

Required

61. USB hubs are self-powered

Required

62. USB devices install without pre-loading software

Required

IA-32 Other Bus Requirements

63. Any subsystems implementing I2O comply with standards and other requirements

Required

64. System does not include ISA or LPC expansion slots

Required

65. System does not include embedded ISA or LPC network adapters, storage controllers, or graphics adapters

Required

66. System does not include ISA or LPC expansion devices

Required

67. System that supports Winsock Direct connectivity meets requirements for device and driver support

Required

IA-32 Device Requirements

68. Device driver and installation meet Hardware Design Guide requirements

Required

69. Keyboard and mouse connections meet requirements for bus and device classes

Required

70. Serial port adapter meets device class specifications for its bus

Required

72. If present on IA-32 system, legacy parallel port meets requirements for bus and device classes

Required for all IA-32 server types, with ECP support Required for SOHO servers

73. USB-to-printer port adapters comply with USB specifications

Required

74. System includes emergency repair support

Required

76. Primary graphics adapter on IA-32 system, if present, meets minimum requirements

Required

IA-32 Network Adapter Requirements

77. System includes non-ISA/non-LPC NDIS 5.0 network adapter

Required

78. Network adapter uses NDIS 5.0 miniport driver

Required

79. NDIS 5.0 miniport driver supports high-performance send and receive calls

Required

80. Full-duplex adapter automatically detects and switches to full-duplex mode

Required

81. Network adapter automatically senses presence of functional network connection

Required

82. Network adapter automatically senses transceiver type

Required

83. Network adapter can transmit packets from buffers aligned on any boundary

Required

84. Network adapter communicates with driver across any bridge

Required

85. Network adapter supports configuration capabilities and registry settings for performance tuning

Required

86. PCI network adapter properly supports higher-level PCI commands

Required

87. PCI network adapters are bus masters

Required

88. USB or IEEE 1394 network device complies with related device class specifications

Required

89. Network device and driver meet Plug and Play and power management requirements.

Required

90. Network communications device supports wake-up events

Recommended

IA-32 Connectionless Networking Requirements

91. Network adapter offloads TCP/IP checksum, IP Security encryption, and TCP message segmentation

Recommended

92. Network adapter supports filtering for at least 32 multicast addresses

Required

93. Server network adapter supports Load Balancing and Failover capabilities

Recommended

94. Server network adapter supports remote system setup capabilities

Recommended

95. Network connections used for remote boot meet PXE requirements

Required

96. Network adapter and driver support promiscuous mode

Required

97. Network adapter and driver support multicast promiscuous mode

Required

98. Network adapter and driver support priority for IEEE 802-style networks

Required

IA-32 Modem Requirements

99. System includes WAN communications device

Recommended

IA-32 Unimodem-supported Modem Requirements

100. Modem controller meets minimum requirements

Required

101. PSTN modem supports ITU-T V.250 command set

Required

102. Device complies with device class power management

Required

103. Device supports wake-up events

Required

104. Data modem supports v.90 and v.34 modulation and other requirements

Required

105. Data modem supports digital connection to support host-side V.90 operation

 | Windows2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Required | Required | Required
SOHO: | Recommended | Required | Recommended

106. Fax modem supports 14.4 Kbps (V.17) with Class 1 (T.31) command set

Required for PSTN connected modems, Recommended for ISDN connected modems

107. Modem supports call control signaling, controlled using V.251 modem commands

Required

108. Modem supports blacklisted and delayed number clearing

Required where applicable

109. Voice modem support is provided

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Optional | Optional | Optional
Enterprise: | Optional | Optional | Optional
SOHO: | Recommended | Recommended | Recommended

110. Voice modem supports ITU V.253 (AT+V)

Required for PSTN connected modems; Recommended for ISDN or T1 connected modems

IA-32 ATM Adapter Requirements

111. ATM adapter meets network adapter requirements

Required

112. ATM adapter supports a minimum number of simultaneous connections

Required

113. ATM adapter supports all service types defined by the ATM Forum

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

114. ATM adapter supports UBR service type

Required

115. ATM adapter supports a minimum number of simultaneously active VBR or CBR connections

Required

116. ATM adapter supports traffic shaping

Required

117. ATM adapter enforces PCR on UBR virtual circuits

Required

118. ATM adapter and driver support dynamic link speed configuration

Required

119. ATM adapter supports OAM

Required

120. ATM adapter supports buffer chaining (Tx + Rx)

Required

IA-32 ADSL Device Requirements

121. ADSL device is implemented as an integrated ADSL modem

Recommended

122. Integrated ADSL modem meets network adapter requirements

Required

123. ATM/ADSL solution is implemented for integrated ADSL modems

Recommended

124. ADSL modem supports DMT line encoding

Recommended

125. ADSL modem supports rate adaptation

Recommended

IA-32 Cable Modem Requirements

126. Device is implemented as an integrated cable modem

Recommended

127. Integrated cable modem meets network adapter requirements

Required

128. Integrated cable modem exposes an ATM or Ethernet interface

Required

IA-32 Serial ISDN Modem Requirements

129. ISDN modem supports required command set

Required

130. ISDN modem exposes both B channels

Recommended

131. ISDN modem supports asynchronous-to-synchronous conversion

Required

132. ISDN modem uses high-speed port

Recommended

133. ISDN modem driver supports unattended installation, with limitations

Required

IA-32 Parallel ISDN Device Requirements

134. Internal ISDN device meets network adapter requirements

Required

135. Internal ISDN device supports synchronous HDLC framing

Required

136. Internal ISDN device and driver support raw unframed synchronous B channel I/O

Required

137. Driver for ISDN internal device supports unattended installation, with limitations

Required

138. ISDN device with U-interface includes built-in NT-1 capability

Recommended

139. Internal ISDN device has software-selectable terminating resistors

Required

IA-32 IrDA Communications Requirements

140. Infrared network adapter meets network adapter requirements

Required

141. Infrared device supports both FIR and SIR

Required

142. IrDA hardware reports a unique Plug and Play ID sufficient to support unattended driver installation

Required

IA-32 Wireless Networking Requirements

143. Wireless networking media adapters meets network adapter requirements

Required

144. Wireless networking media adapters support wireless extensions to NDIS

Required

145. Wireless networking adapters support industry specifications

Required

IA-32 Storage Device General Requirements

146. Host controllers and devices support bus mastering

Required

147. System and Option ROMs support Int 13h Extensions on IA-32 BIOS boot system

Required

148. Block rewritable optical ATAPI device complies with SFF 8070i

Required

149. Controller and peripherals support media status notification

Required

150. Operating system recognizes the boot drive in a multiple-drive system

Required

158. USB-based mass storage device complies with USB specifications

Required

159. IEEE 1394-based mass storage complies with 1394 OpenHCI 1.1

Required

160. Drivers for devices that use SBP-2 command protocols follow Windows 2000 guidelines

Required

IA-32 SCSI Controllers and Peripherals

161. System includes SCSI host controller and SCSI peripherals

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

162. SCSI controllers with external connectors that can function as cluster nodes provide multi-initiator support

Required

163. Bus type is clearly indicated on connectors for all adapters, peripherals, cables, and terminators

Required

164. Differential devices support DIFFSENS as defined in SPI-3 standard

Required

165. Automatic termination circuit and SCSI terminators comply with SCSI-3

Required

166. Terminator power is supplied to the SCSI bus, with over-current protection

Required

167. External connector complies with SCSI-2 or later

Required

168. Controller and peripherals implement SCSI data protection signal

Required

169. SCSI connections use keyed and shrouded connectors

Required

170. External devices provide SCSI-3-compliant termination

Required

171. SCAM support is not present

Required

172. Hardware supports the STOP/START UNIT command as defined in SBC specification

Required

173. STOP/START UNIT command can be used to decrease power consumption

Recommended

174. SCSI devices that support hot-plugging comply with Annex D of SPI-3

Required

IA-32 ATA Controllers and Peripherals

175. System does not use ATA host controller or peripherals

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

176. Dual ATA adapters use single FIFO with asynchronous access or dual FIFOs and channels

Required

177. ATA controller and peripherals comply with ATA/ATAPI-5 standard commands for features implemented and support Ultra-DMA (ATA/33, minimum)

Required

178. ATA controller and peripheral connections include Pin 1 cable designation with keyed and shrouded connectors

Required

179. ATAPI peripherals comply with ATA/ATAPI-5 standard commands for features implemented

Required

180. ATAPI devices support DEVICE RESET command

Required

181. ATA/ATAPI device supports ATA STANDBY command

Required

IA-32 Fibre Channel Controllers and Peripherals

182. System includes Fibre Channel controller and peripherals

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Recommended | Recommended
SOHO: | Optional | Optional | Optional

IA-32 Erasable Disk Drives

183. SCSI erasable drives support SCSI commands

Required

IA-32 CD and DVD Drives

184. System includes CD or DVD drive or other method for installing the operating system

Required

IA-32 CD Drive Requirements

185. CD drive provides 8x or higher performance

Required

186. CD drive is CD-Enhanced compatible

Required

187. CD drive supports specified logical and physical CD formats

Required

188. ATA/ATAPI CD drive complies with MMC-2

Required

189. CD drive supports multisession and compatibility forms of the READ_TOC command

Required

190. ATA/ATAPI CD changer meets MMC-2 standard

Required

IA-32 DVD Drive Requirements

191. DVD device provides 2 MB minimum transfer rate or better performance anywhere on the disk

Required

192. DVD drive meets minimum compatibility requirements

Required

193. DVD drive supports defect management

Required

194. DVD-Video playback, if present, meets DVD-Video playback requirements

Required

IA-32 Backup Devices

195. System includes device for local backup

Recommended

196. Single-backup device meets minimum capacity requirements

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | 10 GB Required | 10 GB Required | 10 GB Required
Enterprise: | 20 GB Required | 20 GB Required | 20 GB Required
SOHO: | 10 GB Required | 10 GB Required | 10 GB Required

197. Backup device meets industry standards

Required

198. Driver integrated with Removable Storage Manager

Required

IA-32 CD Changers

199. If present, CD changer for seven or fewer discs meets MMC-2 standard

Required

IA-32 Tape and Optical Disk Changers

200. SCSI changer and drive support auto-configuration

Required

201. SCSI tape and optical disk changers support SCSI commands

Required

IA-32 Physical Design Requirements

202. Icons are provided for all external connectors

Required

203. All expansion slots in the system are accessible for users to insert cards

Required

204. System and device design include protected switches

Recommended

205. System design includes locking case

Recommended

206. System and device design include positive retention connectors

Recommended

207. If present on an IA-32 system, parallel port design provides sufficient space for connector assembly

Required

IA-32 Hardware Security Requirements

208. C2 evaluation for hardware

Recommended

209. Peripherals follow hardware security recommendations

Recommended

IA-32 Backup Hardware

210. System includes integrated backup solution

Recommended

IA-32 Power Supply

211. System includes UPS provided with system

Recommended

212. System includes power supply protection using N+1 (extra unit)

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Recommended | Recommended

213. System supports replacement of power supplies

Required

214. System supports replacement of fans

Required

215. System includes local hot-swap power supply replacement indicators

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

IA-32 Fault-Tolerant Hardware

216. System supports multiple hard drives

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

217. System includes intelligent RAID controller with adequate storage capacity

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

218. System supports at least one of RAID 1, 5, or 1/0

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

219. RAID support includes notification of failed drive

Required

220. RAID subsystem supports automatic replacement of failed drive

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

221. RAID subsystem supports manual replacement of failed drive

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

IA-32 Serviceability Requirements

222. IA-32 system includes protected forced dump switch or other mechanism for system diagnosis

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Required | Required | Required
SOHO: | Recommended | Required | Recommended

IA-32 High Availability Requirements

223. System includes alert indicators for occurrence of failure

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

224. Hot-swappable drive includes a local disk drive replacement indicator

Required

225. System includes alert indicators for imminence of failure

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

IA-32 General Manageability Baseline Requirements

227. Remote new system setup and service boot support use DHCP and TFTP

Recommended

228. Expansion devices can be remotely managed

Recommended

IA-32 Manageability Component Instrumentation Requirements

229. System supports Windows Hardware Instrumentation Implementation Guidelines

Required


IA-64 Server Requirements Checklist

IA-64 General Component Requirements

1. System and components properly support all dates

Required

System Microprocessor Requirements

2. Multiprocessor-capable system meets Windows requirements and minimum expansion requirements

Required

IA-64 Memory Requirements

4. For IA-64 system installed memory meets minimum requirements

Required

6. For IA-64 system, memory capacity meets minimum requirements

Systems that provide support for <4 processors: 16 GB Required
Systems that provide support for 4 or more processors: 32 GB Required

7. System memory includes ECC memory protection

Required

8. NUMA and NUMA-"lite" system design maintains near:far memory access time ratios of 1:3 or less

Recommended

IA-64 ACPI and Power Management Requirements

9. System design meets ACPI and related requirements

Required for all server types, with additional requirements for SOHO servers

10. Hardware design supports OnNow initiative

Required for all server types, with additional requirements for SOHO servers

11. System startup meets requirements for OnNow support

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Optional | Optional | Optional
Enterprise: | Optional | Optional | Optional
SOHO: | Required | Required | Required

IA-64 Startup Support Requirements

12. System firmware meets general boot support requirements

Required

14. IA-64 system complies with EFI 1.0 or later, with support for USB boot devices, firmware update, and PXE_BC, SERIAL_IO, and SIMPLE_NETWORK protocols

Required

15. System provides a debug port solution

Required

IA-64 Plug and Play Requirements

16. System and device configuration meet Plug and Play requirements

Required

17. Unique Plug and Play ID is provided for each system device and add-on device

Required

18. "PNP" vendor code is used only to define a legacy device’s Compatible ID

Required

IA-64 Other Requirements

25. IA-64 system includes SAPIC support

Required

26. IA-64 system supports message-signaled interrupts

Recommended

27. System with no 8042 or other port 60h and port 64h based keyboard controller meets Hardware Design Guide requirements

Required

IA-64 I/O Bus Requirements

29. System provides an I/O bus based on industry standard specification

Required

30. All PCI adapters function properly on system supporting more than 4 GB memory

Required

31. All PCI bridges in an IA-64 system support DAC

Required

32. System supports a 64-bit PCI bus architecture

Required for all IA-64 systems
Required for all IA-32 systems that support more than 4 GB of system memory

33. PCI bus and devices comply with PCI 2.2 and other requirements

Required

34. PCI devices in an IA-64 system support message-signaled interrupts

Recommended

35. System makes a best effort to provide each PCI slot and device type access to a non-shared interrupt line

Required

36. System does not contain ghost devices

Required

37. PCI-to-PCI bridges comply with PCI to PCI Bridge Specification 1.1

Required

38. System uses standard method to close BAR windows on nonsubtractive decode PCI bridges

Required

39. PCI devices do not use the <1 MB BAR type

Required

40. PCI devices decode only their own cycles

Required

41. VGA-compatible devices do not use non-video I/O ports

Required

42. PCI chipsets support Ultra DMA (ATA/33, minimum)

Required

43. Functions in a multifunction PCI device do not share writable PCI configuration space bits

Required

44. Devices use the PCI configuration space for their Plug and Play IDs

Required

45. Device IDs include PCI Subsystem IDs

Required

46. Interrupt routing is supported using ACPI

Required

47. System that supports hot swapping or hot plugging for any PCI device uses ACPI-based methods

Required

48. All 66-MHz and 64-bit PCI buses in a server system comply with PCI 2.2 and other requirements

Required

49. All PCI devices complete memory write transaction (as a target) within specified times

Required

50. All PCI components comply with PCI Bus Power Management Interface specification

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
Enterprise: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
SOHO: | Required | Required | Required

51. System that supports S3 or S4 state provides support for 3.3Vaux

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Recommended | Recommended
SOHO: | Required | Required | Required

52. PCI bus power states are correctly implemented

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
Enterprise: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
SOHO: | Required | Required | Required

53. Software PCI configuration space accesses on an IA-64 system use SAL procedures

Required

54. PCI-X buses and devices, if present, meet requirements for device and driver support

Required

55. InfiniBand fabric connections, fabrics, and devices, if present, meet requirements for device and driver support

Required

IA-64 USB Requirements

56. System includes USB controller with at least one USB port

Required

57. All USB hardware complies with USB 1.1

Required

58. USB devices and drivers support maximum flexibility of hardware interface options

Required

59. System and devices comply with USB power management requirements

Required

60. USB devices comply with their related USB device class specifications

Required

61. USB hubs are self-powered

Required

62. USB devices install without pre-loading software

Required

IA-64 Other Bus Requirements

63. Any subsystems implementing I2O comply with standards and other requirements

Required

64. System does not include ISA or LPC expansion slots

Required

65. System does not include embedded ISA or LPC network adapters, storage controllers, or graphics adapters

Required

66. System does not include ISA or LPC expansion devices

Required

67. System that supports Winsock Direct connectivity meets requirements for device and driver support

Required

IA-64 Device Requirements

68. Device driver and installation meet Hardware Design Guide requirements

Required

69. Keyboard and mouse connections meet requirements for bus and device classes

Required

70. Serial port adapter meets device class specifications for its bus

Required

71. IA-64 system does not include parallel port

Required

73. USB-to-printer port adapters comply with USB specifications

Required

74. System includes emergency repair support

Required

75. Primary graphics adapter on IA-64 system meets minimum requirements

Required

IA-64 Network Adapter Requirements

77. System includes non-ISA/non-LPC NDIS 5.0 network adapter

Required

78. Network adapter uses NDIS 5.0 miniport driver

Required

79. NDIS 5.0 miniport driver supports high-performance send and receive calls

Required

80. Full-duplex adapter automatically detects and switches to full-duplex mode

Required

81. Network adapter automatically senses presence of functional network connection

Required

82. Network adapter automatically senses transceiver type

Required

83. Network adapter can transmit packets from buffers aligned on any boundary

Required

84. Network adapter communicates with driver across any bridge

Required

85. Network adapter supports configuration capabilities and registry settings for performance tuning

Required

86. PCI network adapter properly supports higher-level PCI commands

Required

87. PCI network adapters are bus masters

Required

88. USB or IEEE 1394 network device complies with related device class specifications

Required

89. Network device and driver meet Plug and Play and power management requirements.

Required

90. Network communications device supports wake-up events

Recommended

IA-64 Connectionless Networking Requirements

91. Network adapter offloads TCP/IP checksum, IP Security encryption, and TCP message segmentation

Recommended

92. Network adapter supports filtering for at least 32 multicast addresses

Required

93. Server network adapter supports Load Balancing and Failover capabilities

Recommended

94. Server network adapter supports remote system setup capabilities

Recommended

95. Network connections used for remote boot meet PXE requirements

Required

96. Network adapter and driver support promiscuous mode

Required

97. Network adapter and driver support multicast promiscuous mode

Required

98. Network adapter and driver support priority for IEEE 802-style networks

Required

IA-64 Modem Requirements

99. System includes WAN communications device

Recommended

IA-64 Unimodem-supported Modem Requirements

100. Modem controller meets minimum requirements

Required

101. PSTN modem supports ITU-T V.250 command set

Required

102. Device complies with device class power management

Required

103. Device supports wake-up events

Required

104. Data modem supports v.90 and v.34 modulation and other requirements

Required

105. Data modem supports digital connection to support host-side V.90 operation

 | Windows2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Required | Required | Required
SOHO: | Recommended | Required | Recommended

106. Fax modem supports 14.4 Kbps (V.17) with Class 1 (T.31) command set

Required for PSTN connected modems, Recommended for ISDN connected modems

107. Modem supports call control signaling, controlled using V.251 modem commands

Required

108. Modem supports blacklisted and delayed number clearing

Required where applicable

109. Voice modem support is provided

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Optional | Optional | Optional
Enterprise: | Optional | Optional | Optional
SOHO: | Recommended | Recommended | Recommended

110. Voice modem supports ITU V.253 (AT+V)

Required for PSTN connected modems; Recommended for ISDN or T1 connected modems

IA-64 ATM Adapter Requirements

111. ATM adapter meets network adapter requirements

Required

112. ATM adapter supports a minimum number of simultaneous connections

Required

113. ATM adapter supports all service types defined by the ATM Forum

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

114. ATM adapter supports UBR service type

Required

115. ATM adapter supports a minimum number of simultaneously active VBR or CBR connections

Required

116. ATM adapter supports traffic shaping

Required

117. ATM adapter enforces PCR on UBR virtual circuits

Required

118. ATM adapter and driver support dynamic link speed configuration

Required

119. ATM adapter supports OAM

Required

120. ATM adapter supports buffer chaining (Tx + Rx)

Required

IA-64 ADSL Device Requirements

121. ADSL device is implemented as an integrated ADSL modem

Recommended

122. Integrated ADSL modem meets network adapter requirements

Required

123. ATM/ADSL solution is implemented for integrated ADSL modems

Recommended

124. ADSL modem supports DMT line encoding

Recommended

125. ADSL modem supports rate adaptation

Recommended

IA-64 Cable Modem Requirements

126. Device is implemented as an integrated cable modem

Recommended

127. Integrated cable modem meets network adapter requirements

Required

128. Integrated cable modem exposes an ATM or Ethernet interface

Required

IA-64 Serial ISDN Modem Requirements

129. ISDN modem supports required command set

Required

130. ISDN modem exposes both B channels

Recommended

131. ISDN modem supports asynchronous-to-synchronous conversion

Required

132. ISDN modem uses high-speed port

Recommended

133. ISDN modem driver supports unattended installation, with limitations

Required

IA-64 Parallel ISDN Device Requirements

134. Internal ISDN device meets network adapter requirements

Required

135. Internal ISDN device supports synchronous HDLC framing

Required

136. Internal ISDN device and driver support raw unframed synchronous B channel I/O

Required

137. Driver for ISDN internal device supports unattended installation, with limitations

Required

138. ISDN device with U-interface includes built-in NT-1 capability

Recommended

139. Internal ISDN device has software-selectable terminating resistors

Required

IA-64 IrDA Communications Requirements

140. Infrared network adapter meets network adapter requirements

Required

141. Infrared device supports both FIR and SIR

Required

142. IrDA hardware reports a unique Plug and Play ID sufficient to support unattended driver installation

Required

IA-64 Wireless Networking Requirements

143. Wireless networking media adapters meets network adapter requirements

Required

144. Wireless networking media adapters support wireless extensions to NDIS

Required

145. Wireless networking adapters support industry specifications

Required

IA-64 Storage Device General Requirements

146. Host controllers and devices support bus mastering

Required

148. Block rewritable optical ATAPI device complies with SFF 8070i

Required

149. Controller and peripherals support media status notification

Required

150. Operating system recognizes the boot drive in a multiple-drive system

Required

151. IA-64 system provides GPT-partitioned hard drive for boot

Required

152. IA-64 system with GPT-partitioned bootable hard disks provide one ESP of correct size

Required

153. IA-64 system with ESP contains only components needed for system boot, installation, or recovery

Required

154. EFI IA-64 system provides restoration tool for recovery of critical ESP and OEM special partition contents

Required

155. For EFI IA-64 system, MSR partition of correct size is present on every physical or virtual hard disk manifested to the operating system when such disks are otherwise being partitioned by the provider of the system

Required

156. For IA-64 system, non-ESP partitions do not contain software required for boot

Required

157. For IA-64 system, ESP resides only on a device that can be reached through firmware-resident EFI drivers

Required

158. USB-based mass storage device complies with USB specifications

Required

159. IEEE 1394-based mass storage complies with 1394 OpenHCI 1.1

Required

160. Drivers for devices that use SBP-2 command protocols follow Windows 2000 guidelines

Required

IA-64 SCSI Controllers and Peripherals

161. System includes SCSI host controller and SCSI peripherals

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

162. SCSI controllers with external connectors that can function as cluster nodes provide multi-initiator support

Required

163. Bus type is clearly indicated on connectors for all adapters, peripherals, cables, and terminators

Required

164. Differential devices support DIFFSENS as defined in SPI-3 standard

Required

165. Automatic termination circuit and SCSI terminators comply with SCSI-3

Required

166. Terminator power is supplied to the SCSI bus, with over-current protection

Required

167. External connector complies with SCSI-2 or later

Required

168. Controller and peripherals implement SCSI data protection signal

Required

169. SCSI connections use keyed and shrouded connectors

Required

170. External devices provide SCSI-3-compliant termination

Required

171. SCAM support is not present

Required

172. Hardware supports the STOP/START UNIT command as defined in SBC specification

Required

173. STOP/START UNIT command can be used to decrease power consumption

Recommended

174. SCSI devices that support hot-plugging comply with Annex D of SPI-3

Required

IA-64 ATA Controllers and Peripherals

175. System does not use ATA host controller or peripherals

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

176. Dual ATA adapters use single FIFO with asynchronous access or dual FIFOs and channels

Required

177. ATA controller and peripherals comply with ATA/ATAPI-5 standard commands for features implemented and support Ultra-DMA (ATA/33, minimum)

Required

178. ATA controller and peripheral connections include Pin 1 cable designation with keyed and shrouded connectors

Required

179. ATAPI peripherals comply with ATA/ATAPI-5 standard commands for features implemented

Required

180. ATAPI devices support DEVICE RESET command

Required

181. ATA/ATAPI device supports ATA STANDBY command

Required

IA-64 Fibre Channel Controllers and Peripherals

182. System includes Fibre Channel controller and peripherals

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Recommended | Recommended
SOHO: | Optional | Optional | Optional

IA-64 Erasable Disk Drives

183. SCSI erasable drives support SCSI commands

Required

IA-64 CD and DVD Drives

184. System includes CD or DVD drive or other method for installing the operating system

Required

IA-64 CD Drive Requirements

185. CD drive provides 8x or higher performance

Required

186. CD drive is CD-Enhanced compatible

Required

187. CD drive supports specified logical and physical CD formats

Required

188. ATA/ATAPI CD drive complies with MMC-2

Required

189. CD drive supports multisession and compatibility forms of the READ_TOC command

Required

190. ATA/ATAPI CD changer meets MMC-2 standard

Required

IA-64 DVD Drive Requirements

191. DVD device provides 2 MB minimum transfer rate or better performance anywhere on the disk

Required

192. DVD drive meets minimum compatibility requirements

Required

193. DVD drive supports defect management

Required

194. DVD-Video playback, if present, meets DVD-Video playback requirements

Required

IA-64 Backup Devices

195. System includes device for local backup

Recommended

196. Single-backup device meets minimum capacity requirements

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | 10 GB Required | 10 GB Required | 10 GB Required
Enterprise: | 20 GB Required | 20 GB Required | 20 GB Required
SOHO: | 10 GB Required | 10 GB Required | 10 GB Required

197. Backup device meets industry standards

Required

198. Driver integrated with Removable Storage Manager

Required

IA-64 CD Changers

199. If present, CD changer for seven or fewer discs meets MMC-2 standard

Required

IA-64 Tape and Optical Disk Changers

200. SCSI changer and drive support auto-configuration

Required

201. SCSI tape and optical disk changers support SCSI commands

Required

IA-64 Physical Design Requirements

202. Icons are provided for all external connectors

Required

203. All expansion slots in the system are accessible for users to insert cards

Required

204. System and device design include protected switches

Recommended

205. System design includes locking case

Recommended

206. System and device design include positive retention connectors

Recommended

IA-64 Hardware Security Requirements

208. C2 evaluation for hardware

Recommended

209. Peripherals follow hardware security recommendations

Recommended

IA-64 Backup Hardware

210. System includes integrated backup solution

Recommended

IA-64 Power Supply

211. System includes UPS provided with system

Recommended

212. System includes power supply protection using N+1 (extra unit)

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Recommended | Recommended

213. System supports replacement of power supplies

Required

214. System supports replacement of fans

Required

215. System includes local hot-swap power supply replacement indicators

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

IA-64 Fault-Tolerant Hardware

216. System supports multiple hard drives

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

217. System includes intelligent RAID controller with adequate storage capacity

Required for all Enterprise class systems
Required for Basic and SOHO class systems deploying MSCS clustering

218. System supports at least one of RAID 1, 5, or 1/0

Required for all Enterprise class systems
Required for Basic and SOHO class systems deploying MSCS clustering

219. RAID support includes notification of failed drive

Required

220. RAID subsystem supports automatic replacement of failed drive

Required for all Enterprise class systems
Required for Basic and SOHO class systems deploying MSCS clustering

221. RAID subsystem supports manual replacement of failed drive

Required for all Enterprise class systems
Required for Basic and SOHO class systems deploying MSCS clustering

IA-64 High Availability Requirements

223. System includes alert indicators for occurrence of failure

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

224. Hot-swappable drive includes a local disk drive replacement indicator

Required

225. System includes alert indicators for imminence of failure

 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

226. IA-64 system supports monitoring for power and down conditions

Required

IA-64 General Manageability Baseline Requirements

227. Remote new system setup and service boot support use DHCP and TFTP

Recommended

228. Expansion devices can be remotely managed

Recommended

IA-64 Manageability Component Instrumentation Requirements

229. System supports Windows Hardware Instrumentation Implementation Guidelines

Required

230. IA-64 hardware and firmware support IA-64 Machine Check Architecture

Required

231. IA-64 system supports event logging for critical events

Required


Glossary

See also the Hardware Glossary available on http://www.microsoft.com/hwdev/glossary.htm.

Acronyms and Abbreviations

ABR available bit rate

ACPI Advanced Configuration and Power Interface

ADSL Asymmetric Digital Subscriber Line

AML ACPI Machine Language

ANSI American National Standards Institute

ARMD ATAPI Removable Media BIOS Specification

API application programming interface

APIC Advanced Programmable Interrupt Controller

ASCII American Standard Code for Information Interchange

ASIC application-specific integrated circuit

ASL ACPI Source Language

AT IBM registered trademark for PC/AT

ATA AT Attachment

ATAPI ATA Packet Interface

ATM asynchronous transfer mode

BAR base address register

BIOS basic I/O system

BIS Boot Integrity Services

bps bits per second

Bx bus state

CAPI Communications API

CBR constant bit rate

CD-R compact disc, read only

CD-RW compact disc, rewritable

CDC USB Class Definition for Communications Devices

CI Calling Indicator

CID Compatible ID

CIM Common Information Model

CIP Compaq, Intel, Phoenix

CMOS complementary metal-oxide semiconductor

CMTS cable modem termination system

COM 1. Component Object Model; 2. legacy serial port.

CPE Customer Premises Equipment

DAC digital-to-analog converter

DCE Data Communications Equipment

DDK driver development kit

DHCP Dynamic Host Configuration Protocol

DIFF Differential

DLL dynamic link library

DMA direct memory access

DMI Desktop Management Interface

DMT discrete multi-tone

DMTF Distributed Management Task Force

DOCSIS Data-Over-Cable Service Interface Specification

DRAM Dynamic RAM

DSSS Direct Sequence Spread Spectrum

DVB/DAVIC Digital Video Broadcasting/Digital Audio-Visual Council

Dx device state

ECC error correction code

ECP extended capabilities port

EFI Extensible Firmware Interface

EPP enhanced parallel port

ESCD Extended System Configuration Data

ESP EFI System Partition

ETSI European Telecommunications Standards Institute

FCD floppy disk controller

FC-PH Fibre Channel Physical, Revision 4.3

FDDI Fiber Distributed Data Interface

FIFO first in/first out

FIR fast IR

GB gigabyte

GPT GUID Partition Table

GSM global system for mobile communications

GUID globally unique identifier

HCL Hardware Compatibility List

HCT Hardware Compatibility Tests

HDLC high-level data link control

HID Human Interface Device

HSM hierarchical storage management

HVD High-Voltage Differential

Hz Hertz

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

ILMI Interim Local Management Interface

I/O input/output

IA Intel Architecture

IP Internet Protocol

IPL Initial Program Load

IPX/SPX Internetwork Packet Exchange/Sequenced Packet Exchange protocol

IrDA Infrared Data Association

IRP I/O request packet

IRQ interrupt request

ISA Industry Standard Architecture

ISDN Integrated Service Digital Network

I2O Intelligent I/O

ITU International Telecommunications Union

IVR interactive voice response

LAN local area network

LED light-emitting diode

LPC low pin count

LPT line printer

LUN logical unit number

LVD Low voltage differential

MB megabyte

Mb/s megabits per second

MCNS Multimedia Cable Network System

MDK Modem Developers Kit

MEI Matsushita Electronics Incorporated

MPS MultiProcessor Specification

MRL Memory Read Line

MRM Memory Read Multiple

ms millisecond

MSCS Microsoft Cluster Server

MSI message-signaled interrupts

MWI Memory Write and Invalidate

MSDN Microsoft Developer Network

NDIS Network Driver Interface Specification

NetBEUI NetBIOS Extended User Interface

NMI Nonmaskable Interrupt

NUMA Non-Uniform Memory Access

OAM operation and maintenance

OEM original equipment manufacturer

OpenHCI Open Host Controller Interface

OSI Open System Interface

PAN Personal Area Network

PCI Peripheral Component Interconnect

PCM pulse coded modulation

PCR Peak Cell Rates

PIO programmed I/O

PLDA Private Loop Direct Attach

PMI Platform Management Interrupt

POST power-on self-test

PPP Point-to-Point Protocol

PS/2 Personal System/2

PSTN Public Switched Telephone Network

PTT Post, Telephone, and Telegraph

PXE Preboot Execution Environment

QoS Quality of Service

RA-ADSL rate adaptive digital subscriber line

RAID Redundant Array of Independent Disks

RAM random access memory

RF radio frequency

RFC Request for Comments

ROM read-only memory

RSM Removable Storage Manager

RSVP Resource Reservation Setup Protocol

SAL System Abstraction Layer

SAPIC Streamlined APIC

SCAM SCSI Configured AutoMatically

SCSI small computer system interface

SDK software development kit

SFF Small Form Factor

SGL single-ended

SID Subsystem ID

SIG Special Interest Group

SIR serial IR

SMP symmetric multiprocessing

SOHO small office/home office

SPI service profile ID

SPID service profile identifier

SSI Server System Infrastructure

STS/EN Status and Enable bits (ACPI)

SVID Subsystem Vendor ID

Sx system state

TA Trade Association

TAPI Telephony Application Program Interface

TCO total cost of ownership

TCP/IP Transmission Control Protocol/ Internet Protocol

TFTP Trivial File Transfer Protocol

UADSL Universal ADSL

UART Universal Asynchronous Receiver/Transmitter

UAWG Universal ADSL Working Group

UBR unspecified bit rate

UHCI Universal Host Controller Interface

Unimodem Universal Modem Driver

UPS uninterruptible power supply

USB Universal Serial Bus

UUID Universally Unique Identifier

VAR value-added retailer

VBR variable bit rate

VCI virtual channel identifier

VPI virtual path identifier

WAN wide area network

WBEM Web-Based Enterprise Management

WDM Windows Driver Model

WEP Wired Equivalent Privacy

WfM Wired for Management

WHIIG Windows Hardware Instrumentation Implementation Guidelines

WHQL Windows Hardware Quality Laboratory

Winsock Windows Sockets

WMI Windows Management Instrumentation

WSD Winsock Direct

Hardware Glossary

A

ACPI Advanced Configuration and Power Interface. A specification that defines an interface to the system board that enables the operating system to implement operating system–directed power management and system configuration. Following the ACPI allows system manufacturers to build systems consistent with the OnNow design initiative for instantly available PCs.

ACPI hardware Computer hardware with the features necessary to support operating system power management and with the interfaces to those features described using the Description Tables as specified in Advanced Configuration and Power Interface Specification.

add-on devices Devices that are traditionally added to the base system to increase functionality, such as audio, networking, graphics, SCSI controller, and so on. Add-on devices fall into two categories: devices built onto the system board and devices on expansion cards added to the system through a system board connector such as PCI.

ADSL Asymmetric Digital Subscriber Line. A method for moving data over regular phone lines. An ADSL circuit is much faster than a regular phone connection, and the wires coming into the subscriber’s premises are the same (copper) wires used for regular phone service.

API Application programming interface. A set of routines that an applications program uses to request and carry out lower-level services performed by a computer operating system.

architecture A general term referring to the structure of all or part of a computer system. Also covers the design of system software, such as the operating system, as well as referring to the combination of hardware and basic software that links machines on a computer network.

ATA AT Attachment. An integrated bus usually used between host processors and disk drives.

ATAPI ATA Packet Interface. A hardware and software specification that documents the interface between a host computer and CD-ROM drives using the ATA bus.

ATM Asynchronous transfer mode. A transmission protocol that segments user traffic into small, fixed-size units called cells, which are transmitted to their destination, where they are reassembled into the original traffic. During transmission, cells from different users may be intermixed asynchronously to maximize utilization of network resources.

B

bandwidth Usually used in reference to the amount of data per unit of time that must move from one point to another, such as from CD-ROM to processor.

BIOS Basic I/O system. A set of routines that works closely with the hardware to support the transfer of information between elements of the system, such as memory, disks, and the monitor. Although critical to performance, the BIOS is usually invisible to the end user; however, programmers can access it.

bps Bits per second. The number of bits transferred per second in a data communications system. A measure of speed.

bus enumerator In a Plug and Play system, a bus device driver that detects devices located on a specific bus and loads information about devices into the hardware tree.

C

cache A special memory subsystem in which frequently used data values are duplicated for quick access.

CD-ROM Compact disc read-only memory. A 4.75-inch laser-encoded optical memory storage medium (developed by NV Philips and Sony Corporation) with the same constant linear velocity (CLV) spiral format as compact audio discs and some video discs. CD-ROM discs can hold about 550 MB of data.

CI Component Instrumentation. A specification for DMI related to the service layer.

class For hardware, the manner in which devices and buses are grouped for purposes of installing and managing device drivers and allocating resources.

class driver A driver that provides system-required, hardware-independent support for a given class of physical devices. Such a driver communicates with a corresponding hardware-dependent port driver, using a set of system-defined device control requests, possibly with additional driver-defined device control requests. Under WDM, the class driver is responsible for multiprocessor and interrupt synchronization.

COM 1. Component Object Model; the core of OLE. Defines how OLE objects and their clients interact within processes or across process boundaries. 2. Legacy serial port.

connectionless networking Networking based on media such as IEEE 802 LAN adapters and Fiber Distributed Data Interface (FDDI) adapters.

CPU Central processing unit. A computational and control unit of a computer; the device that interprets and executes instructions. By definition, the CPU is the chip that functions as the "brain" of the computer.

D

data rate The speed of a data transfer process, normally expressed in bits per second or bytes per second.

DDC Display data channel. The Plug and Play baseline for monitors. The communications channel between a monitor and the display adapter to which it is connected. This channel provides a method for the monitor to convey its identity to the display adapter.

device Any circuit that performs a specific function, such as a parallel port.

device ID A unique ASCII string for a device created by enumerators to identify a hardware device and used to cross-reference data about the device stored in the registry. Distinguishes each logical device and bus from all others on the system.

disk I/O controller Also HDC. A special-purpose chip and circuitry that directs and controls reading from and writing to a computer’s disk drive.

DLL Dynamic link library. API routines that User-mode applications access through ordinary procedure calls. The code for the API routine is not included in the user’s executable image. Instead, the operating system automatically points the executable image to the DLL procedures at run time.

DMA Direct memory access. A method of moving data from a device to memory (or vice versa) without the help of the microprocessor. The system board uses a DMA controller to handle a fixed number of channels, each of which can be used by only one device at a time.

DMI Desktop Management Interface. A framework created by the DMTF. DMTF specifications define industry-standard interfaces for instrumentation providers and management applications.

driver Kernel-mode code used either to control or emulate a hardware device.

driver stack Device objects that forward IRPs to other device objects. Stacking always occurs from the bottom up and is torn down from the top.

DVD Optical disk storage that encompasses audio, video, and computer data.

E

ECP Extended capabilities port. An asynchronous, 8-bit–wide parallel channel defined by IEEE 1284–1944 that provides PC-to-peripheral and peripheral-to-PC data transfers.

enumerator A Plug and Play device driver that detects devices below its own device node, creates unique device IDs, and reports to Configuration Manager during startup. For example, a SCSI adapter provides a SCSI enumerator that detects devices on the SCSI bus.

expansion bus A group of control lines that provide a buffered interface to devices located either on the system board or on cards that are plugged into expansion connectors. Common expansion buses included on the system board are USB, PC Card, and PCI.

expansion card A card that connects to an expansion bus and contains one or more devices.

expansion ROM See option ROM.

F

FDC Floppy disk controller. A chip and associated circuitry that directs and controls reading from and writing to a computer’s disk drive.

FIFO First in/first out. A method for processing a queue in which items are removed in the same order they were added.

full duplex In terms of data flow, indicates
bi-directional data flow.

H

HCI Host controller interface, such as the system-level interface supporting USB.

I

INF file Information file. A file created for a particular adapter that provides the operating system with information required to set up a device, such as a list of valid logical configurations for the device, the names of driver files associated with the device, and so on. An INF file is typically provided by the device manufacturer on a disk with an adapter.

INI file Initialization file. Commonly used under Windows 3.x and earlier, INI files have been used by both the operating system and individual applications to store persistent settings related to an application, driver, or piece of hardware. In Windows 2000 and Windows 95/98, INI files are supported for backward compatibility, but the registry is the preferred location for storing such settings.

input class The class of filters that provides an interface for HID hardware, including USB and legacy devices, plus proprietary and other HID hardware, under the WDM HID architecture.

instrumentation A mechanism for reporting information about the state of hardware and software to enable management applications to ascertain and change the state of a system and to be notified of state changes.

integrated device Any device—such as a parallel port or graphics adapter—that is designed on the system board rather than on an expansion card.

I/O Input/output. Two of the three activities that characterize a computer (input, processing, and output). Refers to the complementary tasks of gathering data for the microprocessor to work with and make the results available to the user through a device such as the display, disk drive, or printer.

IPL Initial program load. A device used by the system during the boot process to load an operating system into memory.

IRP I/O request packet. Data structures that drivers use to communicate with each other. The basic method of communication between kernel-mode devices. An IRP is a key data structure for WDM, which features multiple layered drivers. In WDM, every I/O request is represented by an IRP that is passed from one driver layer to another until the request is complete. When a driver receives an IRP, it performs the operation the IRP specifies, and then either passes the IRP back to the I/O Manager for disposal or onto an adjacent driver layer. An IRP packet consists of two parts: a header and the I/O stack locations.

IRQ Interrupt request. A method by which a device can request to be serviced by the device’s software driver. The system board uses a PIC to monitor the priority of the requests from all devices. When a request occurs, a microprocessor suspends the current operation and gives control to the device driver associated with the interrupt number issued. The lower the number—for example, IRQ3—the higher the priority of the interrupt. Many devices only support raising requests of specific numbers.

ISA Industry Standard Architecture. An 8-bit (and later, a 16-bit) expansion bus that provides a buffered interface from devices on expansion cards to the internal bus.

isochronous Refers to a communication protocol based on time slices rather than handshaking. For example, a process might have 20 percent of total bus bandwidth. During its time slice, the process can stream data.

K

kernel The core of the layered architecture that manages the most basic operations of the operating system, such as sharing the processor between different blocks of executing code, handling hardware exceptions, and other hardware-dependent functions.

kernel mode The processor mode that allows full, unprotected access to the system. A driver or thread running in kernel mode has access to system memory and hardware.

L

legacy Any feature in the system based on older technology for which compatibility continues to be maintained in other system components.

M

minidriver A hardware-specific DLL that uses a Microsoft-provided class driver to accomplish most actions through functions call and provides only device-specific controls. Under WDM, the minidriver uses the class driver’s device object to make system calls.

miniport driver A device-specific kernel-mode driver linked to a Windows 2000 or WDM port driver, usually implemented as a DLL that provides an interface between the port driver and the system.

motherboard See system board.

multifunction device A piece of hardware that supports multiple, discrete functions, such as audio, mixer, and music, on a single adapter.

N

NDIS Network Driver Interface Specification. The interface for network drivers used in Windows 2000 and Windows. NDIS provides transport independence for network vendors because all transport drivers call the NDIS interface to access the network.

nibble mode An asynchronous, peripheral-to-host channel defined in the IEEE 1284-1944 standard. Provides a channel for the peripheral to send data to the host, which is commonly used as a means of identifying the peripheral.

NMI Nonmaskable Interrupt. An interrupt that cannot be overruled by another service request. A hardware interrupt is called nonmaskable if it cannot be masked by the processor’s interrupt enable flag.

NTFS Windows NT file system. An advanced file system designed for use specifically with the Windows NT/Windows 2000 operating system. NTFS supports file system recovery and extremely large storage media, in addition to other advantages.

O

OnNow A design initiative that seeks to create all the components required for a comprehensive, system-wide approach to system and device power control. OnNow is a term for a system that is always on but appears off and that responds immediately to user or other requests.

option ROM Optional read-only memory found on an expansion card. Option ROMs usually contain additional firmware required to properly boot the peripheral connected to the expansion card, for example, a hard drive.

P

PCI Peripheral Component Interconnect. A 32-bit or 64-bit bus designed to be used with devices that have high bandwidth requirements, such as the display subsystem.

planar See system board.

Plug and Play A design philosophy and set of specifications that describe hardware and software changes to the system and its peripherals that automatically identify and arbitrate resource requirements among all devices and buses on the system. Plug and Play specifies a set of device driver interface elements that are used in addition to, not in place of, existing driver architectures.

port A connection or socket used to connect a device—such as a printer, monitor, or modem— to the computer. Information is sent from the computer to the device through a cable.

port driver A low-level driver that responds to a set of system-defined device control requests and possibly to an additional set of driver-defined (private) device control requests sent down by a corresponding class driver. A port driver insulates class drivers from the specifics of host bus adapters and synchronizes operations for all its class drivers.

POST Power-on self-test. A procedure of the system BIOS that identifies, tests, and configures the system in preparation for loading the operating system.

power management Mechanisms in software and hardware to minimize system power consumption, manage system thermal limits, and maximize system battery life. Power management involves trade-offs among system speed, noise, battery life, processing speed, and power consumption.

Q

QIC Quarter-Inch Cartridge Drive Standards, Inc. An international trade association dedicated to promoting use of quarter-inch tape technology and products.

R

RAM Random access memory. Semiconductor-based memory that can be read and written by the microprocessor or other hardware devices. Refers to volatile memory, which can be written as well as read.

registry In Windows 2000 and Windows, the tree-structured hierarchical database where general system hardware and software settings are stored. The registry supersedes the use of separate INI files for all system components and applications that know how to store values in the registry.

resource 1. A set from which a subset can be allocated for use by a client, such as memory or bus bandwidth. This is not the same as resources that are allocated by Plug and Play. 2. A general term that refers to IRQ signals, DMA channels, I/O port addresses, and memory addresses for Plug and Play.

S

scalability 1. Ability of a system to take advantage of multiple processors. 2. The ability to vary the information content of a program by changing the amount of data that is stored, transmitted, or displayed. 3. In a video image, this translates to creating larger or smaller windows of video on screen (shrinking effect).

SCSI Small computer system interface. Pronounced "scuzzy." An I/O bus designed as a method for connecting several classes of peripherals to a host system without requiring modifications to generic hardware and software.

smart card A small electronic device about the size of a credit card that contains an embedded integrated circuit. Smart cards are used for a variety of purposes, including storing medical records, storing digital cash, and generating network IDs.

software device A filter in kernel streaming and ActiveMovie that has no underlying hardware associated with it.

static resources Device resources, such as IRQ signals, DMA channels, I/O port addresses, and memory addresses, that cannot be configured or relocated.

system board Also motherboard or planar. The primary circuit board in a system that contains most of the basic components of the system.

system devices Devices on the system board, such as interrupt controllers, keyboard controller, real-time clock, DMA page registers, DMA controllers, memory controllers, FDC, ATA ports, serial and parallel ports, PCI bridges, and so on. In today’s systems, these devices are typically integrated in the supporting chipset.

T

TAPI Telephony Application Program Interface. A set of Win32-based calls that applications use to control modems and telephones by routing application function calls to the appropriate service provider DLL for a modem.

TCP/IP Transport control protocol/interface program. A software protocol developed by the Department of Defense for communications between computers.

telephony Telephone technology.

U

UART Universal Asynchronous Receiver/ Transmitter. A module composed of a circuit that contains both the receiving and transmitting circuits required for asynchronous serial communication.

Unimodem Universal modem driver. A driver-level component that uses modem description files to control its interaction with the communications driver, VCOMM.

UPS Uninterruptible power supply. A device connected between a computer and a power source that ensures that electrical flow to the computer is not interrupted because of a blackout and, in most cases, protects the computer against potentially damaging events such as power surges and brownouts.

USB Universal Serial Bus. A bi-directional, isochronous, dynamically attachable serial interface for adding peripheral devices such as game controllers, serial and parallel ports, and input devices on a single bus.

user mode The nonprivileged processor mode in which application code executes, including protected subsystem code in Windows 2000.

V

VESA Video Electronics Standards Association. A governing body that establishes standards for the video and graphics portions of the electronics industry.

W

WBEM Web-based Enterprise Management. A DMTF initiative to provide a standards-based mechanism to specify information exchange between management applications and managed components. This work was recently transferred to the DMTF by BMC Software, Inc., Cisco Systems, Inc., Compaq Computer Corporation, Intel Corporation, and Microsoft Corporation.

WDM Windows Driver Model. A driver model based on the Windows 2000 driver model that is designed to provide a common architecture of I/O services and binary-compatible device drivers for both Windows 2ooo and Windows operating systems for specific classes of drivers. These driver classes include USB and IEEE 1394 buses, audio, still-image capture, video capture, and HID-compliant devices such as USB mice, keyboards, and joysticks. Provides a model for writing kernel-mode drivers and minidrivers, and provides extensions for Plug and Play and power management.

WHQL Windows Hardware Quality Labs. Provides testing services for hardware and drivers for Windows and Windows 2000. Administers testing for the "Designed for Microsoft Windows" logo programs. See http://www.microsoft.com/hwtest/.

Win32 API A 32-bit application programming interface for both Windows and Windows 2000 that includes sophisticated operating system capabilities, security, and API routines for Windows-based applications.

Windows Management Instrumentation Extensions to WDM developed for Windows 2000 and Windows to provide an operating system interface through which instrumented components can provide information and notifications.

Windows 2000 The Microsoft Windows 2000 operating system, including any add-on capabilities and later versions of the operating system.