Hardware Development Kit

When designing and building server appliance hardware and target operating systems for commercial release, follow the guidelines in the Microsoft Windows Server Appliance hardware reference specification in your Microsoft Server Appliance Kit documentation. The server appliance hardware requirements include the following hardware:

  • Advanced Configuration and Power Interface (ACPI)-compliant power button
  • Server appliance icons on your hardware

The following additional hardware is recommended to improve the user experience:

  • Local display
  • Keypad
  • Nonvolatile RAM (NVRAM)
  • Watchdog timer

Copyright© 2000-2003 Microsoft Corporation. All rights reserved.


Developing a Compliant Hardware Platform

If you are developing hardware that is compliant with the Microsoft Server Appliance Kit hardware reference specification, you will be most interested in the hardware development kit sections of the Help documentation. The following instructions will lead you through the development of a compliant hardware platform.

Prerequisites

  • Development system with Windows Server 2003 installed on standard computer hardware
  • Server Appliance Kit 3.0 CD

To develop a compliant hardware platform

  1. Install the Server Appliance Kit from a CD onto your development system. In the Setup Wizard, choose one of the two configurations: Windows Storage Server 2003 or custom. Accept the default components.
  2. Read the Hardware Development Kit to view the recommended hardware extensions for server appliances.
  3. Design your hardware components.
  4. Develop the following hardware components:
    • Keypad hardware
    • Local display hardware
    • NVRAM hardware
    • Operating system failover mechanism – This is the capability to allow the system to failover to a different partition or different drive when the primary operating system fails n times. This can be done through BIOS modification together with NVRAM and watchdog.
    • Watchdog timer hardware
  5. Read the Microsoft Windows Server 2003 Driver Development Kit (DDK) to see the required drivers for any server appliance hardware extensions. The DDK can be found in the latest edition of the Microsoft Developer Network (MSDN) library.
  6. Design your driver software components.
  7. Develop any of the following driver software components:
    • Keypad device driver
    • Local display driver
    • NVRAM driver
    • Watchdog timer driver
  8. Package your driver components so that your customers can easily install them. This will typically be done using either a .bat or .msi file.
  9. Build your hardware.
  10. Install Microsoft Windows Server 2003.
  11. Install your drivers.
  12. Install the Server Appliance Kit from CD onto your newly-created hardware.
  13. Test your hardware, drivers, and BIOS to verify that they work correctly with the Server Appliance Kit.

Once you have verified the quality of your hardware, drivers, and BIOS, you are ready to distribute them to your customers.


Keypad Hardware

The driver implementation described in this document is intended to be as general as possible, and is based on assumptions made about the keypad hardware. The keypad hardware must consist of at least six keys.

The hardware may be implemented so that it is polled by the driver to see if a key has been pressed. In this case, the hardware must have a memory of the last key pressed so that the driver will detect that a keystroke has occurred on the next polling interval. The driver must reset the keystroke memory so that additional keystrokes can be detected on future polls of the hardware. For this case, no interrupt service routine (ISR) is required.

Alternatively, the hardware may be implemented so that it generates an interrupt when a key is pressed. In this case, an ISR is required. This documentation does not discuss this case in detail.

The keypad device will not use direct memory access (DMA) or shared buffers to transfer data, but will use programmed I/O instead.


Local Display Hardware

The driver implementation described here is intended to be as general as possible. Microsoft recommends hardware implementations that simplify the software interface and lower hardware costs. These recommendations are intended as a guide. They are not binding requirements for the hardware developer.

The local display hardware can be a simple bank of LEDs, or it can be as complex as a small bitmapped LCD with a minimum size of 64 bits high and 128 bits wide. The local display driver implementation described here can support this range of display hardware.

Microsoft recommends that the local display hardware provide memory-mapped registers to communicate with the device driver. However, this is not a requirement and the driver implementation described here can support communicating through either memory-mapped registers or I/O ports. The start address of the register or port memory must be able to be set by the driver when it allocates the hardware.

The display hardware will use programmed I/O to transfer display data from memory to the display. It will not use direct memory access (DMA) or shared buffers.

Microsoft recommends that the display hardware be implemented to accept an entire display update in one operation. If this is not possible, there are two options. The display hardware can generate interrupts to signal the driver when it is ready for more data, or the driver may be required to poll the device to see when it is ready for more data. The hardware polling approach is discussed here.


NVRAM Hardware

The NVRAM must be able to hold two DWORD data types with data from the operating system and boot count information. The reliability framework component in the Microsoft Server Appliance Kit does not read or write to any additional NVRAM blocks available in the hardware.

Microsoft recommends that the NVRAM provide memory-mapped registers to communicate with the driver. If it does not provide memory-mapped registers, replace references to reading and setting registers with reading and writing to I/O ports.

The NVRAM uses programmed I/O to transfer persistent state data between the operating system and the hardware through the NVRAM driver.

Microsoft strongly recommends that the NVRAM hardware be implemented to accept an entire state update in one I/O operation. This eliminates the need for interrupt service routine (ISR) or hardware polling in the driver. The rest of this documentation assumes that the NVRAM hardware can handle reads and writes as atomic operations. If the hardware cannot receive an entire state update in one I/O operation, it may generate interrupts to signal the driver when it is ready for more data, or the driver may be required to poll the NVRAM device to see when it is ready.

Either flash Electrically Erasable Programmable Read Only Memory (EEPROM) or battery-backed complementary metal oxide semiconductor (CMOS) are recommended for the NVRAM. These memory locations must only be written at major state changes–for example, shutdown or software update–and therefore are not likely to wear out flash memory in the expected lifetime of the product.


Adding Failover Capability

If the primary operating system fails to start, you can use a failover algorithm to make the server appliance failover to another operating system in a variety of ways. The algorithm must detect a start failure, and then start the server appliance from another partition/volume.

The following example process–consisting of a list of requirements along with a process flow chart–illustrates how to add a failover algorithm to the BIOS. Because adding a failover algorithm to the BIOS is a complex process, Microsoft recommends that you print this topic for reference before you begin designing the failover BIOS. In the event you are using another means of providing failover support, you may use the following process as a guide in your efforts.

Requirements

If a failover algorithm is implemented in the BIOS, the system must also include NVRAM and watchdog timer hardware and drivers. The failover algorithm implemented in the BIOS must comply with the following requirements.

  1. The BIOS must initialize all start counters to 0 if, and only if, a restart operation is triggered by an external source, such as a power cycle or a reset button press.
  2. If an internal hard disk is found, the BIOS must search for up to four bootable partitions on a maximum of four disks, searching first by disk, based on the standard disk enumeration order for SCSI or ATA, and then searching by partition, based on the order in the partition table on each disk's master boot record. Any partition that has a system ID in the partition table equal to 0x07 or 0x87 and that has a boot counter value less than 3, is considered bootable. If no hard drive is found, the BIOS should attempt to boot from a floppy disk drive, CD-ROM drive, or the network.
  3. The BIOS must assign a different boot counter in NVRAM to each bootable partition discovered.
  4. The BIOS must read the boot counter value in the NVRAM that is associated with the next bootable partition.
  5. The BIOS must compare the boot counter value to 3 and take one of the following actions.
    • If the boot counter is less than 3, the BIOS must increment the boot counter in the NVRAM, set the drive number to 0x80, and then attempt to start from the partition.

      Note that if the operating system fails to start, the watchdog timer will restart the computer, the boot counter will not be cleared, and the BIOS algorithm continues. If the operating system successfully starts, the watchdog timer will not start and the BIOS will clear the boot counter associated with the partition.

    • If the boot counter is greater than or equal to 3, the BIOS must repeat steps 1-5 searching for the next bootable partition.

      Note that the operating system will use the value of the boot counters to determine that a failover has occurred and which operating system partition is currently being used.

The following flow chart, used in conjunction with the preceding list of requirements, illustrates how to create the failover algorithm.

Failover process flow


Watchdog Timer Hardware

The driver implementation described in this document is intended to be as general as possible, but is based on some assumptions about the properties and behavior of timer hardware.

The watchdog timer starts counting down from some settable initial value. When the timer reaches zero, it can either force the operating system to restart, or can simply shut down the system. The mechanism used to restart the system is at the discretion of the OEM configuring the server appliance. The watchdog timer operates under the assumption that as long as the operating system is running, it continually resets the timer before it can reach zero and fire. The timer device must allow the operating system to set the countdown time interval. The timer must support time intervals from 1 to 511 seconds. The timer might support smaller or larger intervals. Such additional support is not required.

The mechanism for restarting the operating system is not defined in this documentation.

Microsoft suggests that the watchdog timer hardware provide memory-mapped registers to communicate with the driver. The driver can set the start address of the I/O port or register memory when it allocates the hardware.

For more information, see Watchdog Timer Hardware Requirements for Windows Server 2003 on the Microsoft Web site.(http://www.microsoft.com/)


Installing Microsoft Windows Server 2003

Install a version of the Microsoft® Windows® Server 2003. Use the following table as a guide for the Windows components you should enable and disable – depending on the type of server appliance you are building – during the installation process.

Component | Subcomponent | Windows Storage Server 2003 suggested setting | Custom server appliance suggested setting | Notes
Accessories and utilities | Accessibility wizard | N | N |
 | Accessories | N | N |
 | Communication | Y | N |
 | Games | N | N |
 | Multimedia | N | N |
Certificate services | Certification Authority (CA) | N | N |
 | Certificate services Web enrollment support | N | N |
Cluster services |  | See Note | N | If clustering of multiple appliances is supported then select this component.
Indexing services |  | Y | Y |
Internet Information Services (IIS) | Common files | Y | Y |
 | Documentation | Y | Y |
 | File Transfer Protocol (FTP) server | Y | Y |
 | Microsoft® FrontPage® 2000 extensions | N | Y |
 | IIS plug-in | Y | Y |
 | Internet Services Manager | Y | N |
 | NNTP service | N | N |
 | SMTP service | Y | Y | Required for the e-mail alert feature.
 | Visual RAD InterDev Remote Deployment Support | N | Y |
 | World Wide Web server | Y | Y |
Management monitoring tool | Connection manager components | N | N |
 | Network monitor tools | N | N |
 | SMNP | N | N |
Message Queuing services |  | N | N |
Networking services | Com Internet proxy | N | N |
 | Domain Name System (DNS) | N | N |
 | Dynamic Host Configuration Protocol (DHCP) | N | N |
 | Simple TCP/IP services | N | N |
 | Site server Internet Locator Service (ILS) services | N | N |
 | Windows Internet Name Service (WINS) | N | N |
Other network and file services | File services for Macintosh–only if sharing to Macintosh clients | Y | N |
 | Print services for Macintosh | N | N |
 | Print services for UNIX | N | N |
Remote installation services |  | N | N |
Remote storage |  | N | N |
Script debugger |  | N | N |
Terminal services | Client creator files | N | N |
 | Enable terminal services | Y | Y | When prompted to select either Administration Mode or Application Mode when enabling this feature, select Administration Mode.
Terminal services licensing |  | N | N |
Windows media services |  | N | N |
Internet Explorer 5.5 SP1 |  | Y | Y | Recommended for optimum performance of local UI.

For information about installing the support tools, see the sreadme.doc in the \support\tools directory of the Windows Server 2003 CD. The Support Tools Deployment Planning Guide has information about the installation options for Windows Server 2003.

For development, the server appliance hardware can include a CD drive, keyboard, mouse, and display. This hardware allows the operating system to be installed by booting the appliance with the operating system in the CD drive, and following the Setup Wizard.

To change one or more of the settings, modify the unattend.txt. Refer to the samples found under \support\tools\deploy.cab.


Optional OEM Hardware

Depending on the purpose of the server appliance, you may include additional hardware components such as tape or CD drives, PCI cards, and so on.

Some components must be included during development of the server appliance and then can be removed before a final master image is created. These components include video adapter, keyboard, mouse, and monitor. To make installing software on the target system easier, a CD-ROM drive may also be useful during development.


Using Icons on the Server Appliance

Icons that appear on your server appliance hardware–whether as decals affixed to the case, or as images that appear on the local display–must be consistent with the icons on the Microsoft Server Appliance Kit user interface (UI).

The requirements for using icons on your server appliance are enumerated in the following list:

  • Place the appropriate symbol label on your hardware next to the main and backup disk drives.
  • Place the wide area network (WAN) symbol on the server appliance next to each Internet adapter, including the following:
    • Modem adapter
    • ISDN adapter
    • Second network adapter for xDSL
  • If you include an LED local display, place the appropriate icons next to the LED to indicate STARTING, LAN ERROR, READY, and SHUTTING DOWN.

Microsoft recommends that you place appropriate icons next to all other cable jacks on your server appliance.

Server Appliance Icons

The following table identifies standard icons used in the server appliances.

Storage | Network | Other
Disk icon Disk | CD-ROM drive active CD-ROM drive active | Local area network (LAN) icon Local area network (LAN) | Starting icon Starting
Disk activity icon Disk activity | CD-ROM drive error icon CD-ROM drive error | LAN activity icon LAN activity | Booting error icon Booting error
Disk error icon Disk error | Tape drive icon Tape drive | LAN error icon LAN error | Running additional tasks icon Running additional tasks
Main disk icon Main disk | Tape drive active icon Tape drive active | Wide area network (WAN) icon Wide area network (WAN) | Ready icon Ready
Backup disk icon Backup disk | Tape drive error icon Tape drive error | WAN activity WAN activity | Halted icon Halted
CD-ROM drive icon CD-ROM drive |  | WAN error icon WAN error | Shutting down icon Shutting down
 |  |  | Printer icon Printer
 |  |  | Tasks icon Tasks


BIOS Overview

The Microsoft Server Appliance Kit requires that the basic input/output system (BIOS) performs the following functions:

  • Boot the server appliance without use of a keyboard, mouse, or video adapter.
  • Comply with the latest ACPI standards.

In addition, if the server appliance is to support failover to backup partitions, the BIOS must implement a failover algorithm.

Related Topics


Partitioning, Formatting, and Installing the Main Disk

In general the Server Appliance Kit does not require a special disk layout. However, to support the failover feature that is usually within the BIOS, we recommend that the primary operating system be installed in the first primary partition and the backup operating system to be installed in the second primary partition or the active partition in another disk.

Microsoft recommends the primary and backup operating system partitions be 2 GB or larger. Both primary and backup partitions must use the NTFS file system. It is recommended that any other partitions also use the NTFS file system.

Primary partition Backup partition Optional partitions
Primary operating system
  • Marked as Active
  • ntldr
  • ntdetect.com
  • boot.ini
  • Microsoft Windows Server 2003 directory primary operating system
  • ≥ 2 GB
 Backup operating system
  • ntldr
  • ntdetect.com
  • boot.ini
  • Microsoft Windows Server 2003 directory backup operating system
  • ≥ 2 GB
 OEM partitions. Permissible but not required.


Server Appliance Attribute Requirements for Microsoft Windows Server 2003

Reference Documentation for Server Appliance Hardware Running the Microsoft® Windows® Server 2003 Operating System

November 12, 2002
Microsoft Corporation

Contents

Chapter 1 Welcome

How to Use This Specification

Conventions Used in This Specification

Required, Recommended, and Optional Features

References and Resources

Chapter 2 - System Component Requirements

General Component Requirements

System Microprocessor Requirements

Memory Requirements

ACPI and Power Management Requirements

Startup Support Requirements

Plug and Play Requirements

"Headless Server" Requirements

Chapter 3 - Bus and Device Requirements

I/O Bus Requirements

USB Requirements

Device Requirements

Chapter 4 - Networking and Communications Requirements

Network Adapter Requirements

Modem Requirements

ATM Adapter Requirements

ADSL Device Requirements

Cable Modem Requirements

ISDN Requirements

IrDA Communications Requirements

Wireless Networking Requirements

Chapter 5 - Storage Device Requirements

SCSI Controllers and Peripherals

ATA Controllers and Peripherals

Fibre Channel Controllers and Peripherals

Backup Devices

Media Changers

Chapter 6 - Physical Design and Hardware Security Requirements

Physical Design Requirements

Hardware Security Requirements

Chapter 7 - Reliability, Availability, and Serviceability Requirements

Backup Hardware

Power Supply

Fault-Tolerant Hardware

Serviceability Requirements

High Availability Requirements

Local Display

Local Keypad

Watchdog Timer

Additional BIOS and NVRAM Requirements

Manageability Baseline Requirements

Glossary

This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted. Complying with all applicable copyright laws is the responsibility of the user. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation.

Portions of this document specify and accompany software that is still in development. Some of the information in this documentation may be inaccurate or may not be an accurate representation of the functionality of final documentation or software. Microsoft assumes no responsibility for any damages that might occur directly or indirectly from these inaccuracies.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Microsoft, MSDN, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

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

© 2000-2003 Microsoft Corporation. All rights reserved.

Chapter 1 Welcome

Server Appliance Attribute Requirements for Microsoft Windows Server 2003 is for engineers who are designing server appliance hardware that will run the Microsoft® Windows® Server 2003 operating system.

Microsoft will provide OEMs with the Microsoft Server Appliance Kit, which provides tools to create server appliances based on Microsoft Windows Server 2003. The Server Appliance Kit also lists Windows drivers to be used by the operating system and the Server Appliance Kit to interface with the appliance hardware. Information about obtaining this kit is provided in "References and Resources" at the end of this chapter.

This document refers to Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server for many basic requirements. For information about how to obtain Hardware Design Guide Version 3.0, see the Hardware Design Guide for Windows Server at the Microsoft Web site (http://www.microsoft.com/).

This hardware reference specification describes differences between general-purpose Windows Server platform design and Windows Server 2003 appliance design. A Windows Server 2003 appliance is a subset of general Windows-based server hardware. The following hardware and firmware components are exceptions to this rule:

  • Simple local user interface, such as an LCD and keypad
  • Watchdog timer
  • Headless, fail-over BIOS
  • Operating-system-accessible NVRAM

How to Use This Specification

This specification is divided into several chapters that describe design issues related to system, device, and other topics.

Chapter | Contents
1, "Welcome" | Introduction to Microsoft Windows Server 2003 appliances
2, "System Component Requirements" | General system requirements for Windows Server 2003 appliances
3, "Bus and Device Requirements" | Specific requirements for buses and devices in Windows Server 2003 appliances
4, "Networking and Communications Requirements" | Specific requirements for networking and communications devices in Windows Server 2003 appliances
5, "Storage Device Requirements" | Specific requirements for storage devices in Windows Server 2003 appliances
6, "Physical Design and Hardware Security Requirements" | Specific requirements for physical design and security in Windows Server 2003 appliances
7, "Reliability, Availability, and Serviceability Requirements" | Specific reliability, availability, and serviceability requirements for Windows Server 2003 appliances
Glossary | Acronyms and technical terms related to hardware and Windows Server operating systems

Conventions Used in This Specification

The following conventional terms are used throughout this specification.

Hardware Design Guide 3.0

Refers to Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server as published on the Hardware Design Guide for Windows Server at the Microsoft Web site (http://www.microsoft.com/), and any addenda or clarifications published for that document.

Windows 2000

Refers to the Microsoft Windows 2000 Server operating system, the version of Windows Server operating system immediately preceding Windows Server 2003.

Windows Server 2003

Refers to the Microsoft Windows Server 2003 family of operating systems, including any add-on capabilities and any later versions of the operating system.

Windows Server 2003 appliance

Refers to fixed-function, remotely-administered server devices that run Windows Server 2003.

Microsoft Server Appliance Kit

Refers to the OEM kit for building server appliances that run Windows Server 2003.

x86-based system

Refers to a 32-bit microprocessor system based on the Intel Architecture instruction set, capable of running a 32-bit version of Windows Server 2003.

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

Required, Recommended, and Optional Features

This document defines the specifications for designing server appliances based on the Microsoft Server Appliance Kit and Windows Server 2003. These design requirements are not the basic system requirements for Windows Server 2003 appliances running Windows Server 2003.

In this specification, features are described as Required, Recommended, or Optional as follows:

Required. These basic hardware features must be implemented to comply with this hardware reference specification.

Recommended. These features add functionality supported by the Microsoft Server Appliance Kit but are not required for compliance with this hardware reference specification.

Optional. These features are neither required nor recommended, but if the feature is implemented in a server appliance, it must meet the defined requirements to comply with this specification. These features are not likely to become requirements in the future.

References and Resources

The following lists some of the information resources, services, and tools available to help build hardware that meets the requirements defined in this specification. This section also lists references for documents referred to in this specification.

Information Resources from Microsoft

Microsoft Developer Network (MSDN™) Professional subscription at the Microsoft Web site (http://msdn.microsoft.com/)

Microsoft hardware developer information at the Microsoft Web site (http://www.microsoft.com/)

Microsoft Server Appliance Kit at the Microsoft Web site (http://www.microsoft.com/)

Microsoft Windows Hardware Quality Labs (WHQL) at the Microsoft Web site (http://www.microsoft.com/)

OEM server appliance developer support from Microsoft, phone: (877) 247-9900

Technical References

Advanced Configuration and Power Interface

Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server at the Microsoft Web site (http://www.microsoft.com/)

Microsoft Platform SDK and Windows DDK

Provided by CD through MSDN Professional membership
Download online at:
MSDN Downloads (http://msdn.microsoft.com/)
Microsoft Windows Driver Development Kits (http://www.microsoft.com/)

Microsoft Windows Catalog at the Microsoft Web site (http://www.microsoft.com/)

Chapter 2 - System Component Requirements

Back to top

This chapter presents requirements and recommendations that apply to the whole Windows Server 2003 appliance.

General Component Requirements

1. All operating system-controlled hardware complies with this specification

Required

All operating system-controlled hardware must comply with the requirements defined in Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server and must be listed in the Windows Catalog, except where differences are specifically defined in this document.

In any area where the requirements in this document conflict with Hardware Design Guide Version 3.0, this document takes precedence in defining requirements for Windows Server 2003 appliances.

System Microprocessor Requirements

2. System processor capabilities meet minimum requirements

Required

The Microsoft Server Appliance Kit supports only x86-based microprocessors.

For low-cost and lower-performance Windows Server 2003 appliances, the minimum processor required is a 300 MHz Intel Celeron processor with 128 KB Level 2 cache, or a processor with equivalent performance.

Memory Requirements

3. Installed system memory meets minimum guidelines

Required

Low-cost, lower-performance, fixed-function Windows Server 2003 appliances must have a minimum of 128 MB RAM. It is recommended that systems provide at least 256 MB of RAM. Depending on the appliance functionality, more RAM may be needed to ensure reliable operation.

4. Low-cost appliances are exempt from minimum memory capacity requirements defined in Hardware Design Guide Version 3.0

Optional

In many cases, low-cost, fixed-function Windows Server 2003 appliances will not provide a mechanism for upgrading memory. Consequently, minimum capacity requirements defined in Hardware Design Guide Version 3.0 do not apply for Windows Server 2003 appliances.

5. Low-cost appliances optionally use non-ECC memory

Optional

Windows Server 2003 appliances designed for low-cost applications can use non-ECC memory. For mission-critical appliances, ECC memory is recommended.

ACPI and Power Management Requirements

6. System design meets requirements for ACPI and OnNow in Hardware Design Guide Version 3.0

Required

Windows Server 2003 appliances must implement the features defined in the "ACPI and Power Management Requirements" section of Chapter 2 in Hardware Design Guide Version 3.0.

Startup Support Requirements

7. System BIOS supports "headless" operation

Required

The system BIOS must assume the absence of a keyboard, mouse, floppy drive, and graphics display hardware during the boot process.

Plug and Play Requirements

8. System design provides Plug and Play capabilities

Required

Windows Server 2003 appliances and any peripheral devices must implement the features defined in the "Plug and Play Requirements" section of Chapter 2 in Hardware Design Guide Version 3.0.

"Headless Server" Requirements

9. System optionally includes a serial port or management service processor

Optional

A Windows Server 2003 appliance can implement the features defined in the "Headless Server Requirements" section of Chapter 2 in Hardware Design Guide Version 3.0.

It is expected that most server appliances will provide local area network (LAN) based remote management.

Chapter 3 - Bus and Device Requirements

Back to top

This chapter defines specific requirements for buses and devices provided in a Windows Server 2003 appliance.

I/O Bus Requirements

10. No graphics display hardware is present in the production system

Recommended

To reduce complexity and power consumption, graphics display devices and related drivers should be eliminated from the hardware and software before shipping Windows Server 2003 appliance products to end customers.

11. VGA-capable graphics display hardware and drivers are available for use during system development

Recommended

For ease of development, designers can choose to use standard VGA graphics display hardware and drivers for debugging and testing purposes. The operating system will support this capability for development purposes.

12. System does not include multimedia audio devices

Recommended

To reduce complexity, sound cards and speakers should not be included in the product. Server appliances have no need for multimedia audio, because they are designed for unattended operation.

13. System includes simple audio capabilities

Recommended

If an error condition occurs that prevents client computers from communicating with the Microsoft Windows Server 2003 appliance, an audible alarm might be the only way for the server to notify the user that there is an error condition.

14. System does not allow end-user access to expansion bus slots

Recommended

Windows Server 2003 appliance systems are intended to have minimal maintenance requirements for the end user. Consequently, the product should not allow the end user to have access to installed adapters on any expansion bus architectures.

USB Requirements

15. System with USB support meets requirements in Hardware Design Guide Version 3.0

Required

Any USB system support and any USB devices in a Windows Server 2003 appliance must implement the features defined in the "USB Requirements" section of Chapter 3 in Hardware Design Guide Version 3.0.

Device Requirements

16. Production system does not include keyboard or mouse hardware

Recommended

Windows Server 2003 appliances should not support a keyboard or mouse except for debugging purposes during system development and testing.

Chapter 4 - Networking and Communications Requirements

Back to top

This chapter defines specific requirements for networking and communications devices provided in a Windows Server 2003 appliance.

Network Adapter Requirements

17. System includes an Ethernet LAN port

Required

A Windows Server 2003 appliance must include an Ethernet LAN port to allow client connections and remote access for server management.

18. Network adapters meet requirements in Hardware Design Guide Version 3.0

Required

Network adapters must implement the features defined in the "Network Adapter Requirements" section of Chapter 4 in Hardware Design Guide Version 3.0.

19. System incorporates integrated Ethernet LAN port

Recommended

To simplify manufacturing and matching of network hardware to specific system images, it is recommended that a Windows Server 2003 appliance incorporate an "on board" or integrated Ethernet LAN port.

20. SOHO system includes an Ethernet hub adapter

Recommended

For a Windows Server 2003 appliance designed for the small office/home office (SOHO) market, a 4-port, 8-port, or 16-port Ethernet hub on a PCI adapter is recommended. Hubs should be wired internally to the server appliance LAN connection. Providing a hub adapter simplifies the network wiring installation and reduces complexity for the end user.

Modem Requirements

21. Modems meet requirements in Hardware Design Guide Version 3.0

Required

Any modems that might be included in a Windows Server 2003 appliance must implement the features defined in the "Modem Requirements" section of Chapter 4 of Hardware Design Guide Version 3.0.

ATM Adapter Requirements

22. ATM adapters meet requirements in Hardware Design Guide Version 3.0

Required

Any ATM adapter that might be included in a Windows Server 2003 appliance must implement the features defined in the "ATM Adapter Requirements" section of Chapter 4 in Hardware Design Guide Version 3.0.

ADSL Device Requirements

23. ADSL devices meet requirements in Hardware Design Guide Version 3.0

Required

Any ADSL device that might be included in a Windows Server 2003 appliance must implement the features defined in the "ADSL Device Requirements" section of Chapter 4 in Hardware Design Guide Version 3.0.

Cable Modem Requirements

24. Internal cable modems meet requirements in Hardware Design Guide Version 3.0

Required

Any cable modem that might be included in a Windows Server 2003 appliance must implement the features defined in the "Cable Modem Requirements" section of Chapter 4 in Hardware Design Guide Version 3.0.

ISDN Requirements

25. ISDN devices meet requirements in Hardware Design Guide Version 3.0

Required

Any ISDN device that might be included in a Windows Server 2003 appliance must implement the features defined in the "ISDN Requirements" section of Chapter 4 in Hardware Design Guide Version 3.0.

26. Configuring ISDN device does not require reboot

Required

For any ISDN device that might be included in a Windows .Server 2003 appliance, the ISDN device and driver must not require a reboot after changing any parameter, including switch type, SPID, and directory number.

IrDA Communications Requirements

27. IrDA devices meet requirements in Hardware Design Guide Version 3.0

Required

Any IrDA device that might be included in a Windows Server 2003 appliance must implement the features defined in the "IrDA Communications Requirements" section of Chapter 4 in Hardware Design Guide Version 3.0.

Wireless Networking Requirements

28. Wireless network media adapters meet requirements in Hardware Design Guide Version 3.0

Required

Any wireless network media adapter that might be included in a Windows Server 2003 appliance must implement the features defined in the "Wireless Networking Requirements" section of Chapter 4 in Hardware Design Guide Version 3.0.

Chapter 5 - Storage Device Requirements

Back to top

This chapter defines specific requirements for storage devices provided in a Windows Server 2003 appliance.

SCSI Controllers and Peripherals

29. SCSI controllers and peripherals meet requirements in Hardware Design Guide Version 3.0

Required

Any SCSI controller or SCSI peripherals that might be included in a Windows Server 2003 appliance must implement the features defined in the "SCSI Controllers and Peripherals" section of Chapter 5 in Hardware Design Guide Version 3.0.

ATA Controllers and Peripherals

30. ATA controllers and peripherals meet requirements in Hardware Design Guide Version 3.0

Required

Any ATA controller or ATA peripherals that might be included in a Windows Server 2003 appliance must implement the features defined in the "ATA Controllers and Peripherals" section of Chapter 5 in Hardware Design Guide Version 3.0.

Fibre Channel Controllers and Peripherals

31. Fibre Channel controllers and peripherals meet requirements in Hardware Design Guide Version 3.0

Required

Any Fibre Channel controller or Fibre Channel peripherals that might be included in a Windows Server 2003 appliance must implement the features defined in the "Fibre Channel Controllers and Peripherals" section of Chapter 5 in Hardware Design Guide Version 3.0.

Backup Devices

32. Backup devices meet requirements in Hardware Design Guide Version 3.0

Required

Any backup device that might be included in a Windows Server 2003 appliance must implement the features defined in the "Backup Devices" section of Chapter 5 in Hardware Design Guide Version 3.0.

Media Changers

33. Media changers meet requirements in Hardware Design Guide Version 3.0

Required

Any media changer that might be included in a Windows Server 2003 appliance must implement the features defined in the "Backup Devices" section of Chapter 5 of Hardware Design Guide Version 3.0.

Chapter 6 - Physical Design and Hardware Security Requirements

Back to top

This chapter defines specific requirements for physical design and security requirements in a Windows Server 2003 appliance.

Physical Design Requirements

34. System meets physical design requirements in Hardware Design Guide Version 3.0

Required

Windows Server 2003 appliances must meet the requirements defined in the "Physical Design Requirements" section of Chapter 6 in Hardware Design Guide Version 3.0. Exceptions for server appliances are defined in the following two items.

35. System is designed as a "sealed case"

Recommended

Windows Server 2003 appliance enclosures are not intended to allow easy customer access to any PCI or other system expansion card slots.

36. System is physically small

Recommended

Windows Server 2003 appliance enclosures should be small. A tower-style chassis should have a height less than or equal to 14 inches, width less than or equal to 8 inches, and depth less than or equal to 13 inches. A 19-inch rack-style chassis should have a standard 1 U (1.75"/44.45mm) or smaller footprint. No "reset" button should be exposed outside of the box.

Hardware Security Requirements

37. System meets hardware security requirements in Hardware Design Guide 3.0

Required

Windows Server 2003 appliances must meet all the requirements defined in the "Hardware Security Requirements" section of Chapter 6 in Hardware Design Guide Version 3.0.

Chapter 7 - Reliability, Availability, and Serviceability Requirements

Back to top

This chapter defines specific requirements for reliability, availability, and serviceability capabilities provided in a Windows Server 2003 appliance.

Backup Hardware

38. System meets backup hardware requirements in Hardware Design Guide Version 3.0

Required

Windows Server 2003 appliances must meet all the requirements defined in the "Backup Hardware" section of Chapter 7 in Hardware Design Guide Version 3.0.

Power Supply

39. System meets power supply requirements in Hardware Design Guide Version 3.0

Required

Windows Server 2003 appliances must meet all the requirements defined in the "Power Supply" section of Chapter 7 in Hardware Design Guide Version 3.0.

Fault-Tolerant Hardware

40. System meets fault-tolerant requirements in Hardware Design Guide Version 3.0

Required

Windows Server 2003 appliances must meet all the requirements defined in the "Fault-Tolerant Hardware" section of Chapter 7 in the Hardware Design Guide Version 3.0.

Serviceability Requirements

41. System meets serviceability requirements in Hardware Design Guide Version 3.0

Required

Windows Server 2003 appliances must meet all the requirements defined in the "Serviceability Requirements" section of Chapter 7 in Hardware Design Guide Version 3.0

High Availability Requirements

Local Display

42. System provides state and error event indicators

Required

Windows Server 2003 appliances, which do not support a standard graphics display, should provide a local display to give the user some indication of the status of the server appliance. In particular, the local display must be visible and accessible to the operating system such that errors that stop a client from communicating with the server appliance over the LAN can be displayed. If the appliance is running and the LAN connection is operating correctly, then the end user will be able to determine more detailed state and event information from the user interface provided on a client, for example, using a web browser.

State and error event notification can be implemented on a Windows Server 2003 appliance either using LEDs or using a small bit-mapped LCD so that a local user interface can be displayed in form of icons and text to provide more details. A bit-mapped LCD allows the text to be localized to any language.

If a bit-mapped LCD is not provided, then at a minimum, a Windows Server 2003 appliance must provide the following indicators for state and error event notification:

  • Three state indicators: Starting, Ready, and Shutting Down
  • One error message indicator: Networking Error

Additional LED indicators are allowed.

43. Bit-mapped LCD and driver meet requirements

Required

  • If a bit-mapped LCD is provided in a Windows Server 2003 appliance, it must be 64 pixels high and 128 pixels wide. Additionally, the driver for the bit-mapped LCD must comply with the guidelines in the Microsoft Server Appliance Kit.
  • LED indicators can be provided in addition to a bit-mapped LCD.

44. State and error event indicators that implement icons use recommended icons

Recommended

If indicators are provided either using LEDs or icons on an LCD, these should follow the guidelines for icons for specific state and error conditions as provided in the Microsoft Server Appliance Kit.

Local Keypad

45. System provides local keypad

Recommended

Windows Server 2003 appliances that implement a bit-mapped LCD (but do not support a standard graphics display and keyboard) should provide a keypad to allow the user to navigate through the local user interface and to perform certain configuration tasks on the appliance device.

46. Local keypad and driver meet requirements

Required

If implemented, a local keypad must consist of six buttons to represent Left, Right, Up, and Down direction keys and the Enter key and Esc (Cancel) key. A driver must be provided that complies with the guidelines in the Microsoft Server Appliance Kit. Additionally, the keypad hardware and driver must provide the following capabilities.

  • The keypad must interrupt the operating system when a button is pressed.
  • Each button must have an associated latch to store button press information.
  • The latches must be cleared only by the operating system using the associated keypad driver.
  • The latches must power on in the cleared state.

Watchdog Timer

47. System includes hardware watchdog timer and driver

Required

It is recommended that Windows Server 2003 appliances provide a hardware watchdog timer and associated driver. The watchdog hardware will count down from a configurable value and reset or shut down the system if the count reaches zero. Operating system services will periodically restart the timer so that if the operating system, drivers, or services stop functioning, the system will be automatically restarted or shut down.

48. Watchdog timer hardware meet requirements

Required

If a hardware watchdog timer is implemented in a Windows Server 2003 appliance, it must comply with the requirements specified in the document, Watchdog Timer Hardware Requirements for Microsoft Windows Server 2003.

Additional BIOS and NVRAM Requirements

49. System BIOS implements capabilities to fail over to an alternate operating system partition

Required

The system BIOS used in Windows Server 2003 appliances must provide a mechanism to allow determination of whether the main operating system is capable of booting. If the main operating system cannot boot, the BIOS must attempt to boot from 1 or more backup operating system partitions.

50. BIOS fail-over algorithm meets requirements

Required

If a fail-over algorithm is implemented in the BIOS, the system must also include NVRAM and watchdog timer hardware and drivers that comply with the requirements in this document. The fail-over algorithm implemented in the BIOS must comply with the following requirements.

  1. If a boot is not caused by the watchdog timer, the BIOS initializes all boot counter arc paths and count values in NVRAM to zero. If the boot was caused by the watchdog timer firing, the boot counters are not modified.
  2. If the next boot device is not an internal hard disk drive with a valid active partition, the BIOS boots that device and the algorithm ends. If the next boot device is an internal disk drive with a valid active partition, the algorithm continues at step 3.
  3. If a boot is not caused by the watchdog timer, the BIOS takes the following actions to configure the boot counters for internal disk fail over.
    • The BIOS searches the internal disks in boot order, as defined in BIOS setup, and uses the first valid active partition as the main partition of the operating system. The main partition is assigned the first boot counter in NVRAM, the arc path of the main partition is written to the boot counter, and the count value is set to zero. (See boot counter format below.)
      NOTE: The arc path is defined in MSDN knowledge base article Q102873. Note that the arc path value stored in NVRAM represents the physical disk configuration before a failover occurs. This may not correspond exactly to the arc paths in the boot.ini files on the boot disks.
    • The BIOS then searches for up to three bootable backup partitions. It searches first by disk, based on the disk enumeration order for SCSI or ATA, and then searches by partition, based on the order in the partition table on each disk’s master boot record. The first three partitions that have a system ID in the partition table equal to 0x07 (primary NTFS partition) or 0x87 (primary NTFS RAID 1 partition) are considered to be bootable backup partitions. Each backup partition is assigned the next available boot counter in NVRAM, the arc path of the partition is written to the boot counter, and the count value is set to zero.
    • If there are fewer than three bootable backup partitions, the arc path for the unused boot counters is set to all ones.
    Note

    If the boot is caused by the watchdog timer, the boot counter assignments are not modified. This allows the operating system to determine that a fail-over has occurred when a disk fails and is no longer visible to the BIOS.

    1. The BIOS reads the arc paths for all boot counters and validates that the disks and partitions are still present in the system. For all invalid arc paths, the count value is set to 0xF for that partition.
    2. The BIOS determines the partition to boot next by searching for the next available boot counter that has a valid arc path and a counter value less than 3.
    3. Immediately before turning control over to the operating system loader, the BIOS sets the disk ID to 0x80 and increments the count value associated with the partition that will be booted.
    4. If all valid partitions have count values greater than or equal to 3, the watchdog timer is stopped, the boot failure icon is displayed on the local display, and the BIOS stops until someone cycles power on the device.

This algorithm is shown in the diagram below.

51. NVRAM hardware and driver meet requirements

Required

If non-volatile random access memory (NVRAM) is implemented to provide the BIOS and operating system a method of determining whether the operating system is capable of booting, a NVRAM driver must be provided that complies with the guidelines in the Microsoft Server Appliance Kit.

The NVRAM hardware must provide a minimum of 128 bytes of NVRAM. The first 88 bytes of non-volatile memory are for the operating system to use to store state information. This memory must be modified only by the operating system using the associated NVRAM driver. The last 16 bytes of NVRAM memory are for storing four boot counters. The following shows the layout of the NVRAM.

NVRAM Layout (128 bytes total):

Bytes | Description
88 | Non-volatile storage available for the operating system to maintain system state across boots.
24 | Reserved.
4 | Boot counter #1
4 | Boot counter #2
4 | Boot counter #3
4 | Boot counter #4

If a fail-over algorithm is implemented in the BIOS, then the NVRAM hardware must also provide four boot counters, one for each partition that will be used to boot the operating system. Each 4-byte boot counter will be formatted as shown in the diagram below.

Boot Counter Format (4 bytes per boot counter):

4 bits | 4 bits | 4 bits | 4 bits | 12 bits | 4 bits
X | Y | Z | W | Undefined | Count value

X, Y, Z, and W are the values for the arc path as defined in MSDN and KB article Q102873 although the value of X can take values other than 0 for the purposes of this algorithm.

The BIOS must be able to read and write to each boot counter during boot. The operating system must be able to read and write to each boot counter using the associated NVRAM driver. The operating system will read these boot counters and determine the state of the fail-over based on their values as defined in the table below.

Example Count Values (hexadecimal):

Boot Counter X,Y,Z,W count |  |  |  | Operating System Interpretation
#1 | #2 | #3 | #4 |
0,0,0,1 1 | 0,0,1,1 0 | 0,0,1,2 0 | F,F,F,F 0 | Normal boot of main operating system from ATA disk 0, partition 1. First partition on ATA disk 1 is first backup operating system. Second partition on ATA disk 1 is second backup partition.
0,0,0,1 2 or 3 | 0,0,1,1 0 | 0,0,1,2 0 | F,F,F,F 0 | Retry of main operating system after failed boot attempt.
0,0,0,1 3 | 0,0,1,1 1 | 0,0,1,2 0 | F,F,F,F 0 | First boot attempt of first backup operating system.
0,0,0,1 3 | 0,0,1,1 2 or 3 | 0,0,1,2 0 | F,F,F,F 0 | Retry of first backup operating system after failed boot attempt.
0,0,0,1 3 | 0,0,1,1 3 | 0,0,1,2 1 | F,F,F,F 0 | First boot attempt of second backup operating system.
0,0,0,1 3 | 0,0,1,1 3 | 0,0,1,2 2 or 3 | F,F,F,F 0 | Retry of second backup operating system after failed boot attempt.
0,0,0,1 F | 0,0,1,1 1 | 0,0,1,2 0 | F,F,F,F 0 | First boot attempt of first backup operating system after main disk has failed and is not longer visible to the system.
0,0,0,1 1 | 0,1,0,1 0 | 0,1,0,2 0 | F,F,F,F 0 | Normal boot of main operating system from SCSI disk 0, partition 1. First partition on SCSI disk 1 is first backup operating system. Second partition on SCSI disk 1 is second backup partition.
0,0,0,0 0 | 0,0,0,0 0 | 0,0,0,0 0 | 0,0,0,0 0 | Normal boot of non-internal hard disk drive boot device, e.g. floppy disk, CD, network.

52. BIOS displays boot icons on systems with LCD

Recommended

  • If a bit-mapped LCD is provided in a Windows Server 2003 appliance, the BIOS should present a 16x16 pixel icon in the lower left hand corner of the display to indicate that the system is booting. This icon will be an arrow pointing upwards. If the primary operating system fails to boot, the BIOS will indicate which backup operating system partition is being booted by adding 1, 2, or 3 horizontal lines at the base of the arrow to indicate the first, second, and third backup partitions, respectively. If all operating system partitions fail to boot, then the BIOS will display the arrow with a circled "X" overlapping the arrow. These are shown in the diagrams below.
LUI icons indicating which failover OS is booting

Manageability Baseline Requirements

53. System meets manageability requirements in Hardware Design Guide 3.0

Required

Windows Server 2003 appliances must meet all the requirements defined in the "Manageability Baseline Requirements" section of Chapter 7 in Hardware Design Guide Version 3.0.

Glossary

Back to top

See also the Hardware Glossary at the Microsoft Web site (http://www.microsoft.com/)

ACPI Advanced Configuration and Power Interface

ADSL Asymmetric Digital Subscriber Line

ATA AT Attachment

ATM Asynchronous Transfer Mode

BIOS basic I/O system

DDK driver development kit

GB gigabyte

HCT Hardware Compatibility Tests

Headless server system operation without a local display, keyboard, or pointing device

IHV independent hardware vendor

IrDA Infrared Data Association

ISDN Integrated Service Digital Network

LAN local area network

LCD liquid crystal display

LED light-emitting diode

low cost, lower performance system designed to meet price-point demands, perhaps at the sacrifice of optimal performance

MB megabyte

MSDN Microsoft Developer Network

NVRAM non-volatile random access memory

OEM original equipment manufacturer

PCI Peripheral Component Interconnect

RAM random access memory

ROM read-only memory

SCSI small computer system interface

SDK software development kit

server appliance fixed function, headless server device

SOHO small office/home office

WHQL Windows Hardware Quality Laboratory


Glossary

A

access control list (ACL)
A list associated with an object that contains information about users or groups who have permissions to use or modify the object.
ACL
See access control list.
ACPI
See Advanced Configuration and Power Interface.
Advanced Configuration and Power Interface (ACPI)
A specification that defines a new interface to the system board. This interface enables the operating system to implement operating system-directed power management and system configuration.
action message
A message displayed when an alert is raised.
Active Directory
The directory service included with Windows 2000 Server that stores information about objects on a network and makes this information available to users and network administrators.
Active Server Pages (ASP)
An open application environment in which HTML pages, scripts, and ActiveX components are combined to create Web-based applications.
agent
A computer running Simple Network Management Protocol (SNMP) agent software. See also Simple Network Management Protocol.
alert ID
The code used to identify and raise an alert. The combination of AlertID and AlertLog are unique for each alert.
AlertLog
The code used to uniquely identify the area of the alert, such as disk and Internet. The combination of AlertID and AlertLog are unique for each alert.
alerts
Actions to be taken when specific events occur, such as a specific error, errors of certain severities, or a database reaching a defined limit of free space available. The alert can be defined to take such actions as sending an e-mail, paging an operator, or running a job to address the problem.
API
See application programming interface.
appliance initialization task
The appliance initialization task is executed on every boot. Add the appliance task object to the list of task executables in the appliance initialization task under the following registry key and value: HKLM\Software\Microsoft\ServerAppliance\ApplianceManager\ObjectManagers\Microsoft_SA_Task\ApplianceInitializationTask
application programming interface (API)
A standard set of documented and supported routines that expose operating system programming interfaces and services to applications.
application wizard
A wizard that automatically creates a set of starter files for a new component.
ASP
See Active Server Pages.
ASSP
See Application Specific Standard Product.
asynchronous operation
1. A process in a multitasking system whose execution can proceed independently or in the background. Other processes may be started before the asynchronous process has finished. 2. A data transmission method that allows characters to be sent at irregular intervals over a line by preceding each character with a start bit and following it with a stop bit. Compare synchronous operation.
atomic operations
Indicates that either all actions occur or none of them will.

B

boot
The process a computer performs to load its operating system.
boot loader
An application that is automatically run when a computer is switched on (booted). After first performing a few basic hardware tests, the boot loader loads and passes control to a larger loader application, which then typically loads the operating system.
bootable
Contains the system files necessary for booting a device and running it.
bootstrap loader
See boot loader.
branding
OEM identification.
buffered I/O
Stored data that is buffered in anticipation of another sequential read request.
build dependency
The functional relationship between two components that controls the order in which components are built into an embedded run-time image. A build dependency does not cause the automatic inclusion of a component in an embedded run-time image.
build process
The process of using the information in a configuration to construct an embedded run-time image. The output of the build process is defined by script contained in individual component object definitions, which are sometimes inherited from a prototype.

C

category group
Used to collect components into functionally related categories as an organizational convenience. Category groups are used to organize components in the Windows XP Embedded user interface. See also group.
COM
See Component Object Model.
COM class
The definition of an object in code. In the Component Object Model, class refers to the general object definition, whereas in C++, the class of an object is a data type.
COM object
A programming structure that includes both data and functionality. A COM object is defined and allocated as a single unit.
component
The smallest individually selectable piece of functionality that can be included or excluded from an embedded run-time image, comprised of files, registry entries, and dependency information. It is the most basic element in a configuration.
Component Designer
A development tool that enables you to create a custom component to add to the Windows XP Embedded component database.
component instance
A specific instance of a component that is included within a configuration. A component instance is configured entirely by dynamic HTML. Each component instance consists of multiple components in an ordered chain of prototypes.
Component Object Model (COM)
An open architecture for cross-platform development of client/server applications. COM is based on object-oriented technology as agreed upon by Digital Equipment Corporation and Microsoft Corporation. COM defines the interface, similar to an abstract base class, IUnknown, from which all COM-compatible classes are derived.
component prototype
A component from which others are directly or indirectly derived. Windows XP Embedded uses an ordered chain of prototypes in component instances.
configuration
A set of data that contains all the information necessary to build a Windows-based embedded run-time image, including which components to include. A configuration is contained in a file that has the .slx file extension.
configuration file
A file that contains a configuration. See source code configuration file, configuration, and image configuration file.
configuration page
Can be an HTML page on the Web user interface where the feature or component is set up.
configure
The process of the user setting properties of a tool or device so that it operates correctly and according to user specifications.
conflict
An incompatibility between components or capabilities, or when the same system resource has been allocated to multiple devices. Conflicts are defined in a component definition.
control
A standardized child window on the screen that can be manipulated by the user to perform an action or display information. The most common controls are buttons that allow the user to select options and scroll bars that allow the user to move through a document or position text in a window.
control code
One or more nonprinting characters used by a computer program to control the actions of a device.

D

data type
A class of registry entry, which includes REG_BINARY, REG_DWORD, REG_EXPAND_SZ, REG_MULTI_SZ, and REG_NONE. See also DWORD.
Database Manager
The tool that enables you to manage the component database and the repositories.
DDK
See driver development kit.
de-bounce algorithm
A set of instructions that makes an assumption about how fast a user can press and release a switch and then ensures that only one press is registered in the time specified.
delayed procedure call (DPC)
A routine that checks specific parameters.
dependency
A directed relationship between two objects, typically components or objects. For example, if resource A depends on resource B, then B is a dependency of A.
dependency group
A type of dependency that allows a component to express a dependency on all components that belong to the group. See also group.
direct memory access (DMA)
Memory access that does not involve the microprocessor and is frequently used for data transfer directly between memory and an "intelligent" peripheral device, such as a disk drive.
DLL
See dynamic-link library.
DMA
See direct memory access.
DPC
See delayed procedure call.
driver development kit (DDK)
A set of tools and libraries that enable programmers to write Windows-based software used to run hardware devices, such as printers.
DWORD
A data type composed of hexadecimal data with a maximum allotted space of 4 bytes.
dynamic-link library (DLL)
A set of autonomous functions that any application can use. DLLs are a set of object code modules with each module containing a set of functions.

E

embedded
Broadly, software code or commands built into a device, as opposed to software that is added. In a narrower sense, code that is typically stored in ROM and dedicated to either controlling a device or providing a specific functionality.
embedded run-time image
The final output of the Windows XP Embedded authoring tools, which is the combination of operating system binaries, drivers, applications, services, and configuration data (typically in the system registry).
event viewer
A tool that displays a log that reports critical and noncritical events.
extension key
An entry in the registry, corresponding to the extension of a given file, that specifies which file filter will handle conversions for that file type.

F

focus
1. A temporary property of a user interface object, such as a window, view, dialog box, or button, that permits the object to receive keyboard input from the user. 2. One of the two points that determine the shape of an ellipse. The sum of the distances between any point on the ellipse and each of the foci is constant.
form
An ActiveX control container that you customize to create a user interface for your application. A form contains a collection of controls, such as speech controls, power list boxes, audio controls, and tabber controls. A form displays information on a screen.

G

gateway
The address of a local IP router residing on the same network as the server appliance and that is used to forward traffic to destinations beyond the local network.
global variable
A variable whose value can be accessed and modified by any statement in an application and not merely within a single routine in which it is defined.
globally unique identifier (GUID)
A unique 128-bit value used to identify objects. See also universally unique identifier.
group
A collection of components that are grouped to express dependencies between components, to express user interface categories, or to bulk upgrade instances or component deletions. Groups include dependency, package, and category. See also category group, dependency group, and package group.

H

hardware abstraction layer (HAL)
Consists of hardware and device driver mechanisms that insulate applications from device-specific implementation details. If a capability requested by an application is not implemented by the current hardware, the capability will be emulated by the software.

For Windows CE, see also OAL.

headless
A system that does not have a keyboard, mouse, or video monitor during normal operation, also known as remote administration.
hive
A section of the registry that is stored in a file on a computer's hard disk. Hives are located on a specified volume or in the user profiles.
host system
The computer system that hosts the Windows XP Embedded development environment and authoring tools. This is the system on which the embedded run-time image is constructed.

I

IDE
See integrated development environment and Integrated Device Electronics.
IIS
See Internet Information Services and Internet Information Servers.
image
See embedded run-time image.
image configuration file
A file that Makeimg.exe uses to create an operating system image. Image configuration files include .bib, .dat, .reg, .db, and .str files. See also configuration file.
image file
A file that is generated by Romimage.exe that makes up the bits of the operating system image. An image file can be one of the following three formats: Windows CE binary image data format (.bin), Motorola 32-bit binary data format (.sre), or absolute binary data format (.abx).
implementation
In Platform Builder, an implementation contains the functionality necessary to implement the features contained in a type. There can be more than one implementation for a given type. You use the Platform Builder Catalog and Component view to view implementations and to add them to a platform.
instantiate
The process of creating a specific instance of a component within a configuration.
integrated development environment (IDE)
In Microsoft Visual Studio, an integrated set of Windows-based tools for building, testing, and refining an application. The IDE includes a variety of editors, project build facilities, compilers, an incremental linker (for C++), a class viewer, and an integrated debugger. The IDE enables you to create, test, and refine your applications and Web sites all in one place.
Integrated Device Electronics (IDE)
A type of disk-drive interface in which the controller electronics reside on the drive itself, eliminating the need for a separate adapter card.
Internet Information Servers (IIS)
Software services that support Web site creation, configuration, and management, along with other Internet functions. Internet Information Servers include the Network News Transfer Protocol (NNTP), File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP).
Internet Information Services (IIS)
Microsoft’s brand of Web server software, using HTTP to deliver World Wide Web documents. IIS incorporates various functions for security, allows for CGI applications, and provides for FTP servers. In versions 4.0 and earlier, IIS was named Internet Information Server.
interrupt priority
One of three thread priority groups. Interrupt priority is reserved for operating system threads. See also idle priority and main priority.
interrupt service routine (ISR)
A small subroutine that resides in the OEM adaptation layer (OAL). The ISR executes in kernel mode and has direct access to the hardware registers. Its sole job is to determine what interrupt identifier to return to the interrupt support handler. Essentially, ISRs map physical interrupts onto logical interrupts.
interrupt service thread (IST)
A thread created by a device driver to wait on an event.
interrupt support handler
A routine that registers a driver so that it can handle a particular interrupt and deregister it later. It also enables communication between the interrupt service routine, the interrupt service thread, and subroutines within the OEM adaptation layer (OAL) in Windows CE and the hardware abstraction layer (HAL) in Windows XP Embedded.
ISR
See interrupt service routine.

J

There are no glossary terms that begin with this letter.

K

key
1. A field or expression used to identify a record; often used as the index field for a database table. 2. The complete registry subkey path of a registry value.

L

LANGID
See language identifier.
language identifier (LANGID)
A standard international numeric abbreviation for a country or geographical region. An LANGID is a 16-bit value that consists of a primary language identifier and a secondary language identifier. A LANGID is constructed using the MAKELANGID macro. See also locale identifier.
locale identifier (LCID)
A 32-bit value that consists of a language identifier and a sort identifier. In code, an LCID identifies the primary language and any secondary language of a specific locale. An LCID is constructed using the MAKELCID macro. See also language identifier.
localization
The process of adapting an application for a specific international market, which includes translating the user interface, resizing dialog boxes, customizing features if necessary, and testing results to ensure that the application still functions properly.

M

message handler
A Component Object Model (COM) object that implements the ITranslate interface in an in-process COM object.
message sink
A callback function that receives messages for a form or a control. Forms or controls that need to be notified of messages implement a message sink.

N

There are no glossary terms that begin with this letter.

O

object definition
Data that defines a discrete packets of functionality, called components, that can be included in the final run-time image. The functionality is expressed as a set of resources (files, registry entries, and dependency information), properties, and optional script.
object definition file
A file that contains object definitions, including components. The component object definition file has the .sld file extension. In Windows NT Embedded 4.0, the file has the .kdf extension.
object type
A name for a particular group of objects that are contained in a folder.
operating system image
The executable file that contains the operating system. See also run-time image.

P

package
A set of one or more components that are treated as a unit when they are either imported or exported to or from the Windows XP Embedded component database. See also group and package group.
package group
Used to collect components together for administrative purposes, allowing a set of components to be managed as a single unit. Examples include upgrading all component instances to a new service pack or deleting all components in the group. See also group.
packet
A unit of information transmitted as a whole from one device to another. A packet includes data and a header containing an identification number, source and destination addresses, and error-control data.
page file
A file on the hard disk that holds parts of applications and data files that do not fit in memory. Data is moved from the page file to memory as needed and moved back to the page file to make room for new data. The paging file and physical memory, or RAM, comprise virtual memory. Also called a swap file.
partition
A portion of a disk that functions as though it were physically separate.
persistent image
A copy at a given instant of the information stored on a selected volume or volumes. The persistent image can later be restored to the server appliance to replace lost data.
physical repository
A location from which files are copied when building a run-time image.
platform
Defines the type of target embedded run-time image being constructed. A platform defines a target operating system, CPU, and locale and is bound to one component database. When a configuration is created, the user selects a specific platform. For example, one platform might be Windows (x86)–US English.
Point-to-Point Tunneling Protocol (PPTP)
A networking technology that supports multiprotocol virtual private networks (VPNs), enabling remote users to access corporate networks securely across the Internet. Using PPTP users can remotely run applications that are dependent on particular network protocols. See also packet.
PPTP
See Point-to-Point Tunneling Protocol.
process
A running application that consists of a private virtual address space, code, data, and other operating system resources, such as files, pipes, and synchronization objects that are visible to the process. A process also contains one or more threads that run in the context of the process.
property
With respect to the Windows XP Embedded component database, a property consists of component or object properties, including lists of resources and dependencies, group membership, version, and so on.
With respect to the database API, a property refers to a data item that consists of a property identifier, data type, and value.
prototype
See component prototype.

Q

There are no glossary terms that begin with this letter.

R

Remote Access Service (RAS) server
Any Windows-based server configured to run the Remote Access Service. See also Remote Access Service.
repository
A storage area used as the source for all embedded run-time image files required during the build process. There may be multiple repositories for a single installation. Repositories may exist as folders (directories) or .cab files.
repository file source
The location of repository files before import has taken place.
repository files
The actual files stored in a repository.
repository object
The database object in the component definition that logically defines a repository.
repository search path
The path that specifies one or more repository servers or share locations where physical repositories are located.
resource
An object that is used within an application but that is defined outside of the application.
run-time image (embedded)
The final output of the Windows XP Embedded authoring tools, which is the combination of operating system binaries, drivers, applications, services, and configuration data (typically in the system registry).

S

script
A set of instructions to an application or utility program. A script typically uses the rules and syntax of the application or utility. A script can also be called a macro. Common scripting languages are JavaScript and VBScript.
SDK
See software development kit.
server appliance
Fixed-function servers that are easier to install than general-purpose servers and eliminate post-purchase upgrade problems.
signature
The operating system identification. For example, "$Windows NT$".
Simple Network Management Protocol (SNMP)
The network management protocol for TCP/IP.
SNMP
See Simple Network Management Protocol.
software development kit
A set of library, header, and Help files that you use to write applications for a specific platform.
source code configuration file
A file that Build.exe uses to generate source code. A source code configuration file can be a dirs file, a sources file, or a makefile file.
symbol
A name that represents a register, an absolute value, or a memory address (relative or absolute).
synchronous operation
1. Two or more processes that depend on the occurrences of specific events such as common timing signals. 2. A data transmission method in which there is constant time between successive bits, characters, or events. The timing is achieved by the sharing of a single clock. Each end of the transmission synchronizes itself with the use of clocks and information sent along with the transmitted data. Characters are spaced by time and not by start and stop bits. 3. A function call that blocks execution of a process until it returns. See also asynchronous operation.

T

Target Analyzer
The analysis tool you use with Target Designer to ensure that your run-time image supports the hardware on your embedded device. This tool has two parts: a probe that identifies the hardware information on your target device and an engine that constructs a configuration based on the information identified by the probe.
Target Designer
The primary authoring tool that allows you to create, customize, and build a bootable run-time image.
target directory
The path for installing a target system.
target drive
The drive and path to which the target system loads.
target path
See target directory.
target system
The computer system on which the embedded run-time image executes.
Telephony API (TAPI)
A set of functions in the Win32 API set that lets a computer communicate directly with telephone systems.
thread local storage (TLS)
A Win32 mechanism that allows multiple threads of a process to store data that is unique for each thread. For example, a spreadsheet application can create a new instance of the same thread each time the user opens a new spreadsheet.
thread synchronization
The method used to coordinate the execution of two or more threads. There are two states in synchronization: signaled and nonsignaled. Threads can either modify the state of the synchronization object or wait for the object to reach a signaled state.
Time to Live
A header field for a packet sent over the Internet indicating how long the packet should be held.

U

Uniform Resource Locator (URL)
The address of a resource on the Internet. URL syntax is in the form protocol://host/localinfo, where protocol specifies the means of returning the object, such as HTTP or FTP. Host specifies the remote location where the object resides and localinfo is a string, often a file name, passed to the protocol handler at the remote location. Also called a Uniform Resource Identifier.
URL
See Uniform Resource Locator.

V

Value
A data string in the registry.
VIGUID
A version independent globally unique identifier (GUID). An identifier for a set of objects that represent different versions of the same principal. For example, VIGUID identifies the component as a specific DLL. The VIGUID remains constant for a component. See also globally unique identifier.
VSGUID
A version specific globally unique identifier (GUID). An identifier of a specific version of an object. The VSGUID for a component changes each time the component is upgraded to a newer version after the component definition is released. See also globally unique identifier.

W

wait function
A function that allows a thread to block its own execution. Wait functions do not return until the specified criteria have been met.
Win32
The API in Windows that enables applications to use the 32-bit instructions available on 80386 and higher processors.
Windows Management Instrumentation (WMI)
A management infrastructure that supports managing and controlling system resources through a common set of interfaces and provides a logically organized consistent model of Windows operation, configuration, and status. WMI was formerly WBEM (Web-Based Enterprise Management).
WMI
See Windows Management Interface.
write filter
A device that redirects write requests to a cache kept in RAM, enabling the embedded run-time image to run from any read-only media that emulates a disk drive or to write-protect any single disk partition. The write filter satisfies the read requests from either the underlying disk device or from the cache.

X

There are no glossary terms that begin with this letter.

Y

There are no glossary terms that begin with this letter.

Z

There are no glossary terms that begin with this letter.


SAK 3.0 - Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z


Copyright

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, people, and events depicted herein are fictitious and no association with any real company, organization, product, person, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means–electronic, mechanical, photocopying, recording, or otherwise–or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Copyright © 2000-2003 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Sample Code Rights and Restrictions

See the End User License Agreement for specific information regarding the rights and restrictions that apply to your use of the code samples provided.