• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    Functional Description of Windows Server 2003 Architecture

    Let's start with a peek behind the curtain to see how Windows Server 2003 is built. This topic focuses on areas of the Windows Server 2003 architecture that affect stability and performance, including memory allocation, legacy application support, memory protection, process protection, I/O handling, and Plug and Play. Each section includes the differences between the IA32 and IA64 versions of Windows Server 2003.

    IA32 Memory Management

    The IA32 versions of Windows Server 2003 can directly address 232 bytes of memory, or about 4GB. Enterprise and Datacenter Editions can extend this address space. We'll see how that works in a moment.

    The 4GB address space is divvied into two 2GB parcels. The upper 2GB is given to the operating system and is called kernel memory. The lower 2GB is given to applications and is called user memory. This separation of memory prevents badly behaved applications from crashing the system.

    Most servers don't have a full 4GB of physical memory, but that doesn't stop Windows Server 2003 from using the entire 4GB address space. An Executive process called the Virtual Memory Manager (VMM) makes use of special features in the x86 CPU to map virtual addresses to physical addresses.

    VMM acts like a shady real estate dealer who sells the same plot of land several times. It gives each thread its own 4GB of virtual memory, each with the same half-for-the-kernel/half-for-you split. VMM is able to cook the books in this way by shuffling memory into and out of RAM so that processes are completely ignorant of each other.

    If VMM had to handle memory in 1-byte chunks, it would be much too slow and require too much overhead. For this reason, it shuffles memory around in 4K pages. In addition, Windows Server 2003 supports large memory pages for applications and device drivers that work with large memory images. The size of a large memory page can be set in the Registry, and the default is 4MB.

    When a running process needs space in physical memory, VMM looks at the pages owned by other processes and decides which ones have not been used in a while. It moves these pages out of memory and onto disk into one or more paging files. Windows Server 2003 can have up to 16 paging files, each of which must reside on a different logical drive.

    The maximum paging file size in Windows Server 2003 is 16TB (that's terabytes). The default paging file size is 150 percent of installed RAM. The paging file size is calculated during Setup and is not resized dynamically if you add memory later. You may want to increase the paging file size if you bump up the memory on a serverif you want to capture the entire contents of memory following a blue screen stop error (bugcheck). See Chapter 21, "Recovering from System Failures," for details.

    IA64 Memory Management

    The 64-bit (IA64) version of Windows Server 2003 has a theoretical address space of 264 bytes, or 16 exabytes (16 million terabytes). However, the Itanium and McKinley processors use a 44-bit address bus, yielding a 16TB virtual memory limit, if you want to call that a limit.

    Physical memory on an Itanium platform is further constrained to 16GB per processor because of limitations in the 460GX chipset. The McKinley processor and its accompanying 870 chipset are much more capable. Along with support for more memory, McKinley has a 400MHz bus that is 128 bits wide, compared to the 266MHz, 64-bit bus in Itanium. Also, the L3 cache in McKinley is integrated into the chip package rather than connected as an add-on, yielding a 32Gbps processing bandwidth compared to the 12Gbps bandwidth in Itanium.

    Like the IA32 version of Windows Server 2003, the 16TB addressable memory space in an IA64 system is also divided in half, with 8TB given to user applications and 8TB given to the operating system. This seems generous now, but I'm sure in five or six years we'll be grumbling about how you can't get any real computing done with only 8TB of user memory.

    The Virtual Memory Manager in the IA64 version of Windows Server 2003 has the same job as the IA32 version; it maps the 16TB virtual address space offered to each process into physical RAM. The pipelined design of the IA64 processor is capable of handling a large number of instructions at each clock tick, so the capability to do memory gymnastics is even more important than in IA32. For this reason, Windows Server 2003 uses 8K memory pages in the IA64 version. IA64 also supports large memory pages.

    Windows Server 2003 always requires a paging file, even if you have gigabytes upon gigabytes of RAM. The limit on the total number of paging files is 16, the same as IA32, but the maximum size of the paging file is 512TB. The default paging file size is 150 percent of RAM.

    IA32 Legacy Application Support

    DOS applications running in a 16-bit memory space are supported on IA32 versions of Windows Server 2003 by a special application called the NT Virtual DOS Machine, or Ntvdm.exe. NTVDM is a 32-bit application that builds a virtual, 16-bit environment that emulates the BIOS function calls and memory handling of a standard DOS machine. It also provides a 16-bit command interpreter, COMMAND, that complements the 32-bit interpreter, CMD.

    16-bit Windows applications are supported by a Windows16-on-Windows32 (WOW) subsystem, Wowexe.exe, running inside the virtual DOS machine erected by NTVDM. The WOW subsystem intercepts Win16 function calls and converts them to their Win32 counterparts then passes the result to the Windows subsystem, where the function calls are processed and passed back to Wowexe.

    By default, individual 16-bit DOS applications run in separate instances of NTVDM, giving them each a separate memory space. Keep this in mind if you have batch files that launch related DOS applications.

    Individual 16-bit Windows applications, on the other hand, all run under a single instance of Wowexec by default. You can elect to run a 16-bit Windows application in its own memory space by modifying the properties of a shortcut to the application. Open the Properties for the shortcut, select the Shortcut tab, and click Advanced to open the Advanced Properties window (see Figure 3.1). Select the Run In Separate Memory Space option.

    Figure 3.1. Advanced Properties window of a 16-bit application shortcut showing the Run In Separate Memory Space option.


    If you elect to run a 16-bit application in its own memory space, then a new instance of NTVDM and Wowexec will be generated for each instance of the application. This consumes resources. Also, if you have 16-bit applications that expect to communicate with each other via a shared memory space, you must run these applications in the same instance of Wowexec.

    IA64 Legacy Application Support

    The IA64 version of Windows Server 2003 does not support running 16-bit applications, either DOS apps or 16-bit Windows apps. There is no exception to the "no 16-bit code" rule, but Windows Server 2003 does include a workaround for two setup programs: Microsoft's own Acme installer and the Installshield installer. These setup programs use 16-bit stub code to query for the operating system version. The IA64 version of Windows substitutes a patched 32-bit version of Setup16 for Acme and Setup for Installshield that are called when the installer makes this check. The patch files are located under \Windows\SysWOW64.


    The IA64 version of Windows Server 2003 is happy to support 32-bit applications. A Windows32-on-Windows64 (WOW64) emulator creates a memory environment that simulates the 32-bit addresses and 4K memory pages used by IA32 Windows. WOW64 also intercepts 32-bit function calls and converts them to their 64-bit equivalent for processing by the Windows subsystem.

    Unlike the NTVDM/Wowexec pair on an IA32 system, you won't see WOW64 exposed in Task Manager as a separate process. It is implemented as a series of DLLs. The primary work of emulating the operating environment is done by Wow64.dll with Wow64cpu.dll translating the instruction set and Wow64win.dll providing a thunking layer to the kernel side of the Windows subsystem, Win32k.sys. A thunk is a function-call conversion. In addition, to aid in troubleshooting, a set of debugging extensions are loaded in Wow64exts.dll.

    The chore of providing a full Win32 environment in what is essentially a completely different operating system requires many support services. This means that 32-bit applications running inside the WOW64 emulator consume more than their share of memory and CPU time. For example, consider the two Help and Support Center applications in Windows Server 2003, HelpCtr.exe and HelpSvs.exe. These are among the few applications in the shrink-wrap that have not been ported to native 64-bit versions.

    On an IA32 machine, these two applications, taken together, consume about 10MB of memory. On an IA64 system, they combine to take 60MB of actual memory with an overall 82MB virtual memory footprint.

    Similar differences exist for all 32-bit applications. In addition, if you run four instances of the same application, the same overhead is added to each instance, making an IA64 server a poor choice for running production terminal services unless the applications run 64-bit code. (The games in the IA64 version have been recompiled as 64-bit code, so you can tell your boss that you are using them for testing.)

    Registry Reflection

    WOW64 also deals with Registry differences between 32-bit and 64-bit applications. For instance, message queuing and distributed transaction tracking is supported on an IA64 system only for 64-bit applications, so 32-bit applications must not see the associated Registry entries.

    To accomplish this and other Registry modifications, IA64 Windows uses a trick stolen from Snow White and the Seven Dwarves. It creates a magic mirror that always tells the truth, but only that portion of the truth the viewer wants to hear. Here's how it works.

    The Registry on an IA64 machine contains a special key under HKLM | Software called Wow6432Node. This key contains a replica of the HKLM | Software hive with special nips and tucks to accommodate 32-bit applications. WOW64 implements a Registry reflector that copies information back and forth between the HKLM | Software key and the HKLM | Software | Wow6432Node key.

    File System Redirection

    The folder that holds the operating system files on an IA64 system is named System32, just as it is on IA32 systems. Also, most of the operating system files retain the same names even though they have been recompiled as 64-bit applications.

    This leaves a 32-bit application with something of a conundrum. If it tries to link to one of the core DLLs in the operating system, it will fail. 32-bit applications cannot use 64-bit DLLs, and vice versa. The system provides a full suite of 32-bit operating system libraries under \Windows\SysWOW64, and an application running under WOW64 is redirected to this folder when it makes API calls for support files.

    Time will tell how this emulation method fares in production. Microsoft will be forced to implement IA64 service packs that patch both the IA64 code and the IA32 code used by the emulator. Security holes may be found in IA64 applications that cannot be fixed without patching the complementary IA32 files, further complicating hotfixes.

    The 32-bit operating system files are stored on the Windows Server 2003 CD in the I386 folder. The 64-bit files are stored in an IA64 folder. The 32-bit files start with W to differentiate them from their 64-bit counterparts. The W is removed when the files are copied to the \Windows\SysWOW64 folder.

    Unsupported Features and Unshipped Applications

    A few applications and features are not included in the IA64 versions of Windows Server 2003 that you will find in the IA32 versions. These include the following:

    • Windows Product Activation. Microsoft feels that the product is not as likely to be pirated.

    • Remote Assistance. Remote control is available via Remote Desktop, but a user on an IA64 system cannot send an "invitation" for remote assistance.

    • 32-bit ActiveX controls. The 64-bit version of Internet Explorer cannot run 32-bit DLLs and add-ons.

    • Desktop-oriented features. These include CD burning, Windows Media Player (WMP), Windows Messenger, integrated Zip file handling, and user state migration. You can load WMP and Windows Messenger after initial setup by downloading the latest 32-bit versions from Microsoft's download site.

    • Networking features. This includes the Network Bridge, support for infrared modems, Internet Connection Sharing, the Home Networking Wizard.

    • Edlin. A moment of silence, please, for the final passing of this application.

    Memory Pools

    To prevent user applications from starving the operating system of physical memory, a certain amount of physical memory is set aside for the exclusive use of kernel processes. This memory is allocated in the form of two pools, paged and non-paged:

    • Paged pool memory. Memory in the paged pool can be swapped to the paging file. The paged pool limit on IA32 systems is 470MB. The limit for IA64 is 128GB. This additional paged pool memory capability helps avoid situations where the system becomes unstable and reports Out Of Resource and Remote Procedure Call (RPC) errors when the page pool reaches its limit. Historically, the most common cause of paged pool memory exhaustion has been an overly large Registry, but in both flavors of Windows Server 2003, this is not a problem because the Registry does not consume paged pool memory.

    • Non-paged pool memory. Memory in the non-paged pool must stay resident in RAM. The system assigns physical memory to the non-paged pool based on the size of the paged pool. The maximum size is 256MB for IA32 versions and 128GB for IA64 versions. Non-paged pool memory is a precious commodity, and developers are encouraged to limit their use of it, but some situations call for keeping memory pages out of the paging file. For instance, the Encrypting File System stores file encryption keys in non-paged pool memory.

    You can see the actual and virtual memory used by a process, along with its kernel memory pool allocations, in Task Manager. Select the Processes tab then, using VIEW | SELECT COLUMNS from the menu, select the memory elements you want to view. Figure 3.2 shows an example from an IA32 system and Figure 3.3 shows one from an IA64 system.

    Figure 3.2. Task Manager showing memory allocation for running processes.


    Figure 3.3. Task Manager Processes list showing IA64 memory footprint.


    It is possible for an application or device driver to crash a system by overallocating paged or non-paged pool memory. This can happen in one fell swoop but it is more likely to occur over a period of time as part of a memory leak. Windows Server 2003 improves the resiliency of the operating system against these types of problems by monitoring for inappropriate memory allocations.

    Special IA32 Memory Handling Features

    The flat 16TB memory space of IA64 Windows, and its capability to directly address many gigabytes of physical memory, makes it an attractive platform for applications that use large datasets. To take advantage of the additional memory, though, the application must be compiled in native 64-bit code. A 32-bit application running on an IA64 machine is constrained to 2GB. So, until popular applications are released in 64-bit versions, we need ways to extend the memory space available in IA32 systems. This can be done in several ways.

    4GB Memory Tuning (4GT)

    The 2GB dividing line between user memory and kernel memory is completely arbitrary. The line was drawn at the halfway point to permit the use of a simple "signed bit" algorithm to designate pages as belonging to user space or kernel space.

    Although at one time it was unusual to have more than 2GB of physical memory in a server, as of this writing Pricewatch (www.pricewatch.com) shows the going price for 512MB DDR DIMMS to be $70, making it a relatively trivial expense to put 4GB of memory in a server. The real limitation nowadays is not the cost of the RAM but the number of DIMM slots on the motherboard and the capacity of the chipset.

    If you put 4GB of physical RAM in a server, the operating system does not use more than 1GB of the 2GB set aside for it. If you run an application capable of using more than 2GB of physical memory, the IA32 version of Windows Server 2003 has an option called 4GB Memory Tuning (4GT) that takes 1GB of virtual memory from the operating system and gives it to user space. This is accomplished by implementing a different page tagging method.

    To implement 4GT memory tuning, put a /3GB switch on the Advanced RISC Computing (ARC) path that launches the operating system from Boot.ini. The simplest way to do this is to edit the file directly. The BOOTCFG utility does not include an option for installing the /3GB switch. Here is a listing that shows the syntax:

    [boot loader]
    [operating systems]
    multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Standard Edition" /fastdetect /3GB

    In Windows 2000, the 4GT option is only supported on Advanced Edition and Datacenter Edition. In Windows Server 2003, it is supported on all IA32 server packages but not on IA64 versions.

    There are a few caveats when using 4GT Tuning. For instance, if you run Datacenter Edition and have more than 16GB of physical RAM, you should not use the /3GB switch. Also, the 3GB switch reduces the amount of physical RAM set aside for paged pool memory, and this can cause problems for terminal servers. If you run Exchange 2000, though, you should set the /3GB switch even if you have only 1GB of RAM to take advantage of the larger memory images available to files.

    Address Windowing Extensions (AWE)

    At the end of the Wizard of Oz, Dorothy found out that the ruby slippers could have taken her back to Kansas at any time; she just needed to know the trick. You may get the same feeling when I tell you that the Pentium family of processors, starting with Pentium Pro, has always had the capability to access more than 4GB of physical memory. The processor has a 36-bit address range, giving it the capability to access 236 bytes, or 64GB, of physical memory.

    Intel has supported this 36-bit addressing capability in a variety of ways. The most current iteration is an Extended Server Memory Architecture that exposes a set of Page Size Extensions using the PSE36 mode of the processor. Windows Server 2003 Advanced and Datacenter Editions make use of this 36-bit memory addressing with an API called Address Windowing Extensions (AWE).

    Using the AWE API, an application can transfer memory pages above the 4GB limit into the addressable memory area where it can make changes to the pages. This permits applications such as SQL Server that use large datasets to manage them in RAM rather than a slow paging file.

    The application must be AWE-aware and capable of making suitable API calls. You should not add more than 4GB of memory to a server unless you are running an AWE-capable application and a version of Windows Server 2003 that can make use of the Physical Address Extensions (PAEs).

    Windows Server 2003, Standard Edition, does not support PAE and therefore does not support more than 4GB of physical memory. Windows Server 2003, Enterprise Edition, supports PAE but artificially constrains total memory to 32GB. Windows Server 2003, Datacenter Edition, supports PAE to the full 64GB limit. PAE is not applicable to IA64 systems.

    To implement PAE, put a /pae switch on the ARC path entry in Boot.ini that launches the operating system. The BOOTCFG utility does not include an option for installing this switch, so edit the file directly. If the server fails to start, the platform does not support PAE. Restart in Safe mode and change the Boot.ini entry back to its original form.

    Process Protection

    Windows Server 2003 takes advantage of hardware protection elements built into the Intel IA32 and IA64 architecture. Highly privileged operations, those that access physical structures in the computer, can only be initiated by code running in the Windows Executive (see Figure 3.4).

    Figure 3.4. Diagram of the Windows Executive.


    The Executive consists of a kernel driver, Ntoskrnl.exe, that links to a function library called the Hardware Abstraction Layer (HAL), or Hal.dll, that acts in concert with a long list of system services and drivers. An additional kernel driver in IA32 versions, Ntkrnlpa.exe, supports PAE addressing.

    The kernel version loaded by Setup depends on the nature of the underlying hardware. If the motherboard uses ACPI (Advanced Configuration and Power Interface), Setup loads the ACPI version of the kernel. If the motherboard has no ACPI support, Setup loads a Standard PC kernel. An Itanium server always gets an ACPI kernel. The specification does not permit an IA64 system to operate independently of ACPI.

    Setup always uses a multiprocessor kernel during the initial system configuration. If it senses that you have a single processor machine, it will load a uniprocessor version of the kernel for permanent use.

    Windows Executive Structure

    With the kernel and HAL in place, the remaining Executive services are grouped together based on the processes or data structures they control or use. With a couple of exceptions, these groupings are called Managers.

    All Executive services run in kernel mode where they exchange data freely. The IA64 version uses the same Executive structure as the IA32 version. Here is a list of the managers and other service providers in the Windows Server 2003 Executive:

    • Executive Support. Services that provide pool memory allocation and special queue and thread handling not provided by the kernel driver.

    • Plug and Play (PnP) Manager. Services that enumerate and define the capabilities of hardware devices.

    • Power Manager. Services that define hibernate/sleep/wakeup policies for devices.

    • I/O Manager. Services that control data flows to external storage and network devices. This includes device drivers that communicate directly to hardware without using the kernel or HAL.

    • Object Manager. Services that control symbolic links and data structures in the object's namespace.

    • Security Reference Monitor. Services that control access to Windows Server 2003 objects.

    • Process Manager. Services that provide structured handling for device threads.

    • Configuration Manager. This service is responsible for the structure and content of the Registry.

    • Local Procedure Call Facility. A high-level client/server interface between user processes and system services.

    • Virtual Memory Manager. Services that map virtual memory to physical memory and control contiguous memory allocation.

    • Win32K. Services that control graphics and window handling. This includes drivers that communicate directly to video and printer hardware without using Ntoskrnl or the HAL.

    Windows Server 2003 no longer contains an OS/2 subsystem or a POSIX subsystem. POSIX support comes in a separate Microsoft product called Interix. The cost is somewhere around $80 U.S. For more information, see www.microsoft.com/windows2000/interix. (Interix runs on both Windows 2000 and Windows Server 2003.)

    Process Separation

    Applications are not permitted to make direct use of system services in the Executive. Instead, applications make API calls that are handled by the Windows subsystem. (The Windows subsystem used to be called the Win32 subsystem. Now that there is an IA64 version of Windows, Microsoft chose a more generic term.)

    The Windows subsystem consists of a kernel-side component contained in Win32k.sys and a set of user-side components, the Client/Server Runtime Subsystem (CSRSS) and Dynamic Link Libraries (DLLs) that translate user-side API calls into kernel-side service calls. Applications in user space are not permitted to run in the privileged memory space of the Executive, or even to talk directly to the Executive services. Unlike political institutions, this separation of executives and workers makes the system highly resistant to crashes and instabilities.

    Online Error Reporting

    If an application causes a protection fault, the stack and process information is captured by a utility called DrWatson. There are two flavors of DrWatson: Drwatson.exe for 16-bit applications and Drwtsn32.exe for 32-bit applications.

    DrWatson saves the failure information in log files under the All Users profile in \Application Data\Microsoft\DrWatson. (On IA64 systems, there is a space between Dr and Watson in the folder name: Dr Watson.)

    Additionally, after DrWatson finishes up, an application called Dwwin launches and builds report files in the user's Temp directory. This feature uses the Error Reporting Service (ERSvc) to collect information about the state of the machine just prior to the crash, then asks permission to send this information to Microsoft

    The information collected by the Error Reporting Service takes the form of XML database files that are packaged up and sent to Microsoft via a secure HTTP connection (Secure Sockets Layer, or SSL). A great deal of information is included in online error reporting, such as the name of every application and driver loaded on the system at the time of the crash. If you have reason for not wanting this information sent outside your company, you should disable error reporting. This can be done in one of several ways:

    • Stop error reporting using the Properties window of the Computer icon on the desktop. Select the Advanced tab, click Error Reporting, and then select the Disable Error Reporting radio button. Figure 3.5 shows the options.

      Figure 3.5. Error Reporting options displayed as part of System Properties for a server.


    • Disable the ERSvc service using the Services snap-in under Computer Management.

    • Enable the Disable Error Reporting group policy for a GPO linked to an Organizational Unit (OU) or container holding the servers you want to configure.

    Device Drivers

    For the most part, the operating system is protected from hapless user-mode applications, but the same is not true for device drivers. Drivers are capable of running in kernel mode where they have access to all the privileged processes in the Executive. If the driver consumes too much memory or attempts to access memory used by other processes or insists on getting the CPU's attention when it is busy doing something more important, the driver can cause the server to freeze or to throw an exception error, causing a bugcheck, otherwise known as a blue screen of death. Chapter 21 has more information about the cause of bugchecks and how to diagnose them.

    Hopefully, the number of unexpected crashes caused by inadequately designed device drivers should decline in Windows Server 2003 thanks to a new feature called Windows Driver Protection. This feature consists of a database that identifies drivers with known compatibility issues. If you attempt to load one of these drivers, the system will notify you of the compatibility issues and point you at a page of information stored in the Help and Support Center that defines the nature of the incompatibility. The list is refreshed regularly by Microsoft and is downloaded as part of Windows Update.

    You might imagine that a vendor would not appreciate having one of its drivers included on a "bad-boy" list from Microsoft. I expect the Driver Protection program to have a side benefit of making vendors take extra care when coding their drivers. A list of the drivers on the list is available at www.microsoft.com/hwdev.

    Windows Server 2003 also does a better job of sorting through multiple drivers for the same device as it searches the INF directory, the CD, floppies, and the Windows Update downloads. If multiple drivers are found, they are sorted using the following guidelines:

    • Signed drivers are installed ahead of unsigned drivers, even if the signed driver is "compatible," whereas the unsigned driver exactly matches the device.

    • Unsigned drivers with NT-specific sections in the INF script are installed ahead of unsigned drivers without NT-specific sections.

    I/O Handling

    Windows Server 2003 is a multitasking operating system, but not even Bill Gates and Andy Groves can overcome one fundamental limitation of computing: a single CPU can only do one thing at a time. Windows Server 2003 gives the impression of doing many things simultaneously in the same way that a motion picture gives the impression of continuous movement, by running through a series of discrete events very, very quickly.

    Windows Server 2003 uses preemptive multitasking to share CPU cycles between running process threads. Each thread is given the attention of the CPU in its turn, with the amount of time allotted to the thread based on a quantum timeslice. This timeslice is short for workstations and long for servers.

    You can adjust the time quantum from the UI, but the adjustment is fairly coarse. The setting is in the Advanced tab of the System Properties window, which you can open either from the Control Panel or by right-clicking the My Computer icon and selecting PROPERTIES from the flyout menu. Figure 3.6 shows an example. The quantum timeslice (also called Processor Scheduling) can be set to favor Applications or Background Services. The Application option sets a shorter time quantum; Background sets it longer. You can also set the system to favor system cache or programs when allocating memory.

    Figure 3.6. System Properties window, Advanced tab, showing Processor Scheduling and Memory Usage options.


    The Windows Executive uses a trap handler to coordinate activities. The trap handler fields interrupts from two sources: software and hardware. Hardware interrupts are issued by devices that need the attention of the CPU. Software interrupts are issued by applications that have put a placeholder with the CPU to get attention after some other event has occurred.

    A thread runs at a certain interrupt request level, or IRQL. For instance, a particular thread might request an IRQL of 7 when it starts. (There are 32 levels of IRQL, with larger numbers having higher priority.) During its quantum timeslice, this thread can only be interrupted by threads having interrupt levels of 8 or higher.

    For the most part, software interrupt prioritization lies outside the control of an administrator. However, it is possible to request a certain priority with the START command. There are four priority classesLow, Normal, High, Realtimeand two prioritization levelsAbovenormal and Belownormal. Power users who want a particular application to run at a high priority can launch the application as follows:

    Start /High /Abovenormal APP.EXE

    Frankly, I have done lots of fiddling with various IRQL priorities using START and I have rarely found it a worthwhile exercise. The performance boost only comes into play when the thread dispatcher is starved of CPU cycles and must begin triage. Not many users let their personal workstations get near this point. Generally, users start closing down other applications instead of figuring out ways to launch apps that hog all the available cycles.

    Hardware Interrupts

    Devices use hardware interrupts (IRQs) to divert the attention of the CPU when they want something done. Without hardware interrupts, the CPU would be oblivious to the system clock, network adapter, mouse, keyboard, and other peripherals.

    Hardware interrupts summon the CPU in the same way that butlers are summoned in an English mansion. A rope in the corner of each room loops through the walls of the mansion and ends up in the pantry, where it is connected to one of many little bells dangling from springs. When someone in the billiard room pulls the rope, the butler hears the bell and looks up to see which spring is shaking. The butler then takes out a 3x5 card labeled Billiard Room and finds instructions on it that say, "Deliver Scotch and cigars to the billiard room." The butler interrupts whatever he was doing (polishing the silver, watching Masterpiece Theatre, whatever) and carries out these instructions.

    There is a possibility that the interrupt service routines, the instructions associated with an interrupt, could run at an appropriate time if more than one device tries to lay claim to an interrupt. ACPI avoids this problem by building an IRQ routing table that permits multiplexing different devices into the same IRQ. For a nifty little tool that lets you view ACPI elements such as the IRQ routing table, download PCIScope from APSoft at www.tssc.de. Figure 3.7 shows a sample of the information displayed by this utility.

    Figure 3.7. PCIScope utility can display the ACPI routing table, BIOS routing table, and PCI header information from each device.


    The Device Manager console, Devmgmt.msc, can display devices and the resources they have been assigned. This makes it easy to see shared IRQs. From the menu, select VIEW | RESOURCES BY TYPE. Figure 3.8 shows the IRQ resource list. Note the large number of devices multiplexed through IRQ 9.

    Figure 3.8. IRQ resources assigned in a computer that does not support extended interrupts above 15.


    On machines with chipsets that support use of the Advanced Programmable Interrupt Controller (APIC) installed on all modern PCs, Windows Server 2003 can assign IRQs above 15. Figure 3.9 shows the device list on a machine running a Pentium 4 processor with the Intel 850 chipset.

    Figure 3.9. IRQ resource assignments on a machine with a chipset that supports IRQs above 15.


    IA64 machines are even more generous with IRQs, forgoing shared IRQs entirely. Figure 3.10 shows the resource list from an HP I2000 workstation.

    Figure 3.10. Itanium devices sorted by IRQ.


    A potential cause of erratic server behavior is improper prioritization of the IRQs assigned to the devices. The CPU is constantly bombarded with hardware interrupt requests, and ACPI is responsible for prioritizing them. One of the considerations that ACPI uses when making its IRQ assignments is the PCI slot that contains the device. For this reason, if you have a device that acts erratically, or does not work at all, put it in another PCI slot. For more information on the PCI specification, see the PCI SIG web site at www.pcisig.com/tech/index.shtml.

    Direct Memory Access (DMA)

    Ordinary data transfers to and from a device and main memory require separate hardware interrupts for each buffer of data. This is called Programmed I/O, or PIO, and it is very inefficient. More advanced devices use Direct Memory Access (DMA) along with bus mastering to transfer data with very little intervention required by the CPU.

    Each DMA device is assigned a channel, which is essentially an ID used for handling data transfer transactions. DMA channels are negotiated through ACPI. Advanced ATA/IDE controllers use DMA to achieve high data transfer rates with low CPU utilization. Several different DMA versions exist, each with a different transfer rate. Windows Server 2003 uses ACPI plus its own negotiation routines to determine which DMA mode to assign to a device.

    Some machines do not support DMA on PCI slots far away from the CPU. If you place a controller card in a server and it does not function, or functions very slowly, you might want to move it to a slot closer to the CPU.

    Figure 3.11 shows the DMA assignments to devices on the primary IDE controller bus. Devices can use different DMA versions and a mix of DMA and PIO. These settings are available in the Device Manager console in the Properties window of the IDE controller (primary or secondary).

    Figure 3.11. DMA assignments to devices on IDE bus.


    On IA64 systems, DMA has an even more dramatic impact on performance because of the wider data paths. IA64 machines use a 64-bit PCI bus. In some cases, a device driver might be coded to use 32-bit addresses. Windows Server 2003 responds by double-buffering I/O to the device. This hurts performance. Verify with the vendor that the device meets Microsoft criteria for 64-bit addressing and single-buffer operation.

    DMA is enabled by default for DVD and CD-RW drives. The Properties page in Device Manager shows the actual DMA mode.

      Previous Section Next Section