• 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 Overview of Windows Server 2003 Setup

    This topic covers the details of what happens during an installation of Windows Server 2003. It examines the major milestones that occur during Setup to give you a basis for making configuration decisions. Step-by-step instructions are listed in the "Installing Windows Server 2003" section in this chapter.

    Windows Server 2003 Setup works like an able seaman docking a ship to a pier. The seaman tosses a light line to shore and uses it to pull over a heavier line. He wraps the heavier line around a winch and uses it to pull across a much heavier line, and then he uses the heavier line to the secure the ship to the pier.

    Setup docks Windows Server 2003 to a computer with three separate rounds of file copies performed in two phases, with a third phase for final system configuration:

    • Text phase. This phase starts with booting from the Windows Server 2003 CD. This phase uses a small set of files to build a miniature session of Windows Server 2003. This session partitions and formats a mass storage device, creates the system folders, mounts a CD, and copies the necessary files to support the next setup phase. Unlike its predecessors, if you elect to format the operating system volume using NTFS, Setup actually formats it using NTFS rather than starting with FAT/FAT32 then converting later on. The system restarts after this phase.

    • Graphic phase. In this phase, Setup discovers and enumerates the system hardware, obtains configuration information from the user, then copies a final set of files from the CD to get the drivers it needs to finish installing the operating system and configure the services. The system restarts after this phase.

    • Configuration phase. This phase starts when a user logs on for the first time. A final round of PnP discovery commences that looks for any devices that did not get enumerated during the graphic phase of Setup. The user may be prompted to provide drivers if they are not present. The system also launches a Server Configuration Wizard to walk through any additional settings and the Windows Product Activation Wizard to obtain an activation key. Depending on the nature of the added components and their resource allocations, the system may need to be restarted one final time. Following this third phase, the system is ready for production.

    The following sections look at each Setup phase in detail.

    Text Setup Phase

    This phase begins by booting from the Windows Server 2003 CD. You can also connect to an installation share point and run one of the setup programs: Winnt will start Setup from DOS; Winnt32 will start Setup from NT or Windows 2000. See Chapter 2, "Performing Upgrades and Automated Installations," for details on running Setup from network drives.

    Setup Executable Loads

    The IA32 Setup CD has a bootable image that conforms to the El Torito non-emulation standards. This image contains the files necessary to create a miniature Windows Server 2003 session that acts as a starting point for the main Setup program. Executable code in the boot image looks for Setupldr.bin, the Windows Server 2003 Setup loader. Setupldr.bin is actually just a copy of the standard Windows Server 2003 secondary bootstrap loader, Ntldr, with a few changes to support installation.

    Setupldr.bin orchestrates the text-mode portion of Setup using a script called Txtsetup.sif. This script tells Setup the following:

    • Where to find the boot files

    • What directories to put on the boot partition

    • What files to copy to the system and boot partitions

    • What drivers to load initially

    • What to do with existing files

    • What keys to put in a skeleton Registry built to support the graphic phase of Setup

    Initial Hardware Recognition

    IA32 machines do not have a hardware recognizer in firmware like an IA64 machine, so Setupldr.bin loads a software-based hardware recognizer called Ntdetect.com. At this point, you see the message Setup is inspecting your computer's hardware configuration.

    Ntdetect.com finds the hardware information needed by the Windows Server 2003 setup kernel, Ntkrnlmp.exe, and its Hardware Abstraction Layer library, Hal.dll. Setup always uses a multiprocessor kernel and HAL. If it detects that the system has a single processor, it installs a uniprocessor version of the kernel. You can add a second processor later, if the motherboard supports it. Windows Server 2003 will automatically load the multiprocessor kernel files when it detects the additional processor.

    ACPI Compatibility Checks

    ACPI evolved for a few years before version 2 of the standard was approved in 1999. This means that machines built prior to 1999 used a variety of ACPI features. Windows Server 2003 expects to find ACPI version 2 support on a system, but rather than leave legacy machines behind, Microsoft collected operational information from a variety of platforms and used that information to make corrections in the ACPI feature set.

    Now that ACPI has matured, the older Advanced Power Management (APM) standard has been more or less abandoned. Again, because of backward compatibility issues, Microsoft maintained support for legacy APM, but only if ACPI is not detected.

    Chapter 3, "Adding Hardware," discusses the way that Windows Server 2003 supports legacy ACPI systems. If you have a system that appears to experience ACPI-related problems (inexplicable hangs, crashes, erratic behavior), you can elect to install a Standard PC kernel. Do this at the very beginning of the text mode portion of Setup, when you are prompted to press F6 to install alternate mass storage device driver. Press F7 to skip the ACPI kernel and install the Standard PC kernel. You cannot shift to the ACPI kernel without re-installing the operating system.

    Special Setup Function Keys

    A variety of special setup options are available during the first few seconds of the text-mode portion of Setup. You can access the options using these function keys:

    • F2. When pressed at the Welcome to Setup window, this launches Automatic System Recovery (ASR), a quick way to recover the operating system from tape. See Chapter 21, "Recovering from System Failures," for details.

    • F5. Permits selecting an alternative kernel type. Options include ACPI, Standard PC, I486 C-stepping, and SGI MP.

    • F6. Permits loading a third-party mass storage device driver that is not on the Windows Server 2003 CD.

    • F7. Bypasses ACPI to load a standard PC kernel.

    • F10. When pressed at the Welcome to Setup window, this launches the Recovery Console. See Chapter 21, "Recovering from System Failures," for details.

    If you press F5 or F6, it takes a while for the system to respond. Wait a few minutes for the menus to appear.

    If you want to do an unattended installation, you can change the Txtsetup.inf file to disable ACPI. Here is a standard Txtsetup.inf listing:

    [ACPIOptions]
    ACPIEnable = 2
    ACPIBiosDate = 01,01,1999
    

    Change the ACPIEnable entry from 2 to 0 and reinstall Windows Server 2003.

    Drive Letter Assignments

    Long, long ago, in a galaxy far, far away, Microsoft decided to use drive letters rather than UNIX-style file system specifiers to identify drive partitions. The intent was to put friendly names on the file system interfaces. There is no doubt that drive letters made file systems easier for users to interact with, but they have become a never-ending source of irritation to system administrators.

    The Mount Manager service, MountMgr, is responsible for enumerating drives and assigning drive letters. This enumeration process varies depending on whether you do a fresh install of Windows Server 2003 or an upgrade. Upgrades are covered in Chapter 2, "Performing Upgrades and Automated Installations."

    When you do a fresh install of Windows Server 2003, there might already be partitions on the drives that you want to retain, so Setup scans the drives and assigns drive letters to existing partitions. The partitions need not hold recognized file systems. Drive letters can be assigned to HPFS and Linux partitions.

    Setup first scans for dynamic disks and uses the drive letters assigned in the LDM database. This assists applications that might reference those drive letters. It separates the partitions into two categories:

    • Hard-linked partitions. If a disk has been upgraded from a basic to a dynamic disk, the legacy partition table is left in place so the system BIOS can read the table, find the active partition, and load the boot sector from this partition. This is called a hard-linked partition because there is no need for the bootstrap code in the MBR to read the LDM database to find the boot partition.

    • Soft-linked partition table. If a disk has never been partitioned as a basic disk, it has no legacy partition table. Partitions are only defined in the LDM database and are therefore called soft-linked partitions.

    During the dynamic disk scan, Setup uses the following criteria to assign drive letters:

    • Dynamic disks with hard-linked partitions. Setup first queries the LDM database to find drive letters assigned to hard-linked partitions. If no letters are assigned, Setup assigns the next available letter.

    • Dynamic disks with soft-linked partitions. After hard-linked partitions have been given drive letters, Setup queries the LDM database for letters assigned to volumes in soft-link partitions. It assigns these letters if they do not conflict with hard-linked drive letters. If there is a conflict, or if no drive letters are assigned, it assigns the next available letter.

    If logical drive letters must be changed on dynamic disks, Setup writes the new letters to the LDM database. After dynamic disks have been scanned and assigned, Setup turns its attention to basic disks.

    Figure 1.1 shows a diagram of drive letter assignments for a system with two drives, one IDE and one SCSI, both configured as basic disks. During the drive scan, the on-board IDE interfaces are scanned before the SCSI interfaces. Ultra-DMA ATA controllers are treated as SCSI interfaces, so they are scanned after the on-board controllers. Drive letters are assigned as follows:

    • Active partitions. Setup scans the drives looking for primary partitions marked as Active. Assuming that there are no pre-existing dynamic disks, it assigns drive letter C to the first active partition on the first drive in the scan sequence. If a drive does not have an active partition, Setup assigns the next drive letter to the first primary partition on the drive.

    • Extended partitions and removable media drives. Setup scans the drives again, this time looking for logical drives in extended partitions and removable media drives such as Jaz or Orb drives. It assigns drive letters starting with the next available letter.

    • Primary partitions. Setup scans the drives again, this time looking for any remaining primary partitions. It assigns drive letters in sequence starting with the next available letter.

    • CD-ROM and DVD drives. Finally, Setup assigns drive letters to CD-ROM and DVD drives. It assigns letters in sequence so that a CD-ROM drive on IDE controller 0 will get a letter before a CD-ROM drive on IDE controller 1, which itself comes before a CD-ROM drive on a SCSI controller.

    Figure 1.1. Diagram of drive letter assignments for a system with a single IDE drive and SCSI drive. Primary partitions marked A are active.

    graphics/01fig01.gif

    These drive letter assignments are written to the Registry so they persist between restarts. This makes drive letters "sticky," an important factor when installing applications and creating shortcuts or other OLE connections.

    After Setup has completed, you can change drive letters assigned to any of the partitions except for the boot partition and the system partition. This avoids potential conflicts when hard-coded Registry entries expect to see system files at a certain drive letter. Do not attempt to change drive letters using Registry modifications. This works for Windows 2000, but in Windows Server 2003 it causes Windows Product Activation to fail so that it refuses to permit access, forcing you to reinstall the operating system.

    Setup Files

    Setupldr.bin uses installation files from the boot image to create a miniature version of Windows Server 2003. These files contain video drivers, keyboard drivers, mass storage drivers, and file system drivers. Here are the important drivers and their functions:

    • Atapi.sys. This is the IDE/EIDE driver. The older Atdisk.sys driver is no longer used. Support for ESDI/WD1003 drives has been dropped.

    • Disk.sys, Class2.sys, and Classpnp.sys. These are mass storage interface drivers and their PnP enumerator.

    • Dmboot.sys, Dmio.sys, and Dmload.sys. This set of drivers supports Logical Disk Manager (LDM).

    • Floppy.sys. The floppy disk miniport driver.

    • Hardware Abstraction Layer (HAL). There are several HAL drivers. Setup chooses one based on the type of hardware.

    • I/O extenders. These are WDM bus drivers that work with the PnP Manager to define data paths in the system. There are extenders for PCMCIA, PCI IDE, Toshiba IDE, VIA IDE, IBM Thinkpad IDE, Intel IDE, and the floppy disk controllers.

    • I2Omp.sys and I2Omgmt.sys. This set of drivers supports the I2O subsystem. This enables the system to boot from Intelligent Input/Output controllers.

    • I8042prt.sys. The keyboard driver. This driver virtualizes the 8042 controller BIOS and also controls PS/2 bus mice. If you get garbage onscreen when you type, or experience odd results when using your mouse, this driver might not be compatible with your keyboard, mouse, or PS/2 motherboard interface.

    • Isapnp.sys. The PnP enumerator for the ISA bus. You may recognize this driver from NT4. It came in the \Support directory on the NT4 CD. Multimedia vendors such as Creative Labs used this driver to provide a simpler way to install their ISA sound cards and game boards.

    • Kbdclass.sys and Kbdus.dll. These are the keyboard class driver and the keyboard mapping driver. These two drivers can sometimes cause trouble with cheap components. If you keep having problems with the Caps Lock key not working properly or the repeat rate being unstable, you may need to upgrade your equipment. The boot image contains a full suite of international keyboard layout DLLs.

    • Ksecdd.sys. This is the kernel security driver. It works with the I/O drivers to open and read security descriptors on objects.

    • Mountmgr.sys, Ftdisk.sys, and Partmgr.sys. This set of drivers supports basic disk configurations and classic fault tolerant disk sets.

    • National Language Support (NLS). These files contain locale information for character sets, punctuation, and so forth. For American English installations, Setup loads code pages C_1252.NLS and C_437.NLS. It also loads a primary language file, L_INTL.NLS.

    • Ntdll.dll. The Windows Server 2003 API function library.

    • Ntfs.sys, Fastfat.sys, and Cdfs.sys. The NT file system driver, FAT file system driver, and CD file system driver. FASTFAT.SYS supports both FAT16 and FAT32. The Windows Server 2003 CD contains other file system drivers, but Setup does not need them at this point.

    • Openhci.sys, Uhcd.sys, Usbd.sys, Usbhub.sys, and Hidusb.sys. The Universal Serial Bus (USB) drivers. These work with a set of Human Interface Device (HID) drivers to support USB components.

    • Scsiport.sys. This is the SCSI bus driver. It is accompanied by a slew of miniport drivers for various SCSI boards.

    • Serial.sys and Serenum.sys. The serial bus controller and PnP enumerator. These two drivers work together to find PnP and legacy devices connected to RS232 ports. This search can be a tedious process because the RS232 interface is so slow. For this reason, the standard Boot.ini entry includes a /fastdetect switch that delays the serial bus enumeration until after the system has loaded.

    • Setupreg.hiv. This is a small Registry file with keys to initialize the Windows Server 2003 kernel-mode driver, SETUPDD.SYS. SETUPDD.SYS is the mother driver that loads the other device drivers. You can view the contents of SETUPREG.HIV after installation by loading it into the Registry Editor.

    • Smss.exe. The Session Manager Subsystem driver. The Session Manager is responsible for loading and initializing system drivers.

    • Vga.sys, Videoprt.sys, and Vgaoem.fon. These are the standard VGA video drivers and one display font.

    Choosing a Disk Format

    After Setupldr.bin has loaded drivers into memory, it initializes the kernel driver manager, Ntkrlmp.exe. This manager works with the Session Manager, Ssms.exe, to initialize the operating system.

    At this point, Setup prompts you to partition the mass storage device and select a format, either NTFS or FAT. You have the option to use a standard format or a quick format. The only difference is that quick format removes the existing file system and creates a new one but does not perform a sector scan. You should only use quick format on a disk that you have already checked using another utility.

    Unlike NT and Windows 2000, if you elect to format the operating system partition as NTFS, Setup actually formats it as NTFS rather than formatting it as FAT/FAT32 then converting it later. This avoids MFT fragmentation. If you elect to format as FAT or FAT32 then convert later, the new NTFS conversion retains the same cluster size. In Windows 2000 and NT, conversion always reverts to a 512-byte cluster.

    If you specify FAT on a partition that is larger than 2GB (the limit for DOS partitions with 32KB clusters), Setup automatically formats the partition as FAT32. Windows Server 2003 and Windows 2000 will not format a FAT32 partition that is larger than 32GB. If you want to have a boot partition larger than 32GB formatted as FAT32, format the partition with another utility prior to starting Setup. Large boot partitions, especially those formatted using FAT32, are not recommended.

    After the boot and system partitions are formatted, the files necessary to support the graphic phase of startup are copied from the CD. The system restarts automatically after the file copy has completed. An entry in Boot.ini tells Ntldr where to find the kernel files so the graphic phase of Setup can commence.

    Graphical Setup Phase

    Setup reloads when the machine restarts. Like Dorothy leaving drab, old Kansas for colorful Oz, the character-based screens are left behind and the system shifts to Graphic mode.

    Quite a bit more happens during this phase of Setup than the character phase, but you get a lot more information onscreen, so it requires less explanation. There are several critical decision points. These concern licensing, naming servers, setting the Administrator password, configuring workgroups and domains, and setting the system time.

    Definition of Boot Partition and System Partition

    When I use the terms boot partition and system partition, I try to stay faithful to the way Microsoft uses the terms. You may find their usage to be a little cross-eyed:

    • System partition. This is the partition that contains the files required to boot Windows. For an Intel platform, these files are Ntldr, Boot.ini, Ntdetect.com, Bootsect.dos, and Ntbootdd.sys (if a SCSI device has no onboard BIOS). The system partition must be flagged as Active (or bootable) in the Master Boot Record. The files must be at the root of the boot drive. Setup assumes that the first IDE drive on the primary IDE controller is the boot drive. If a partition on this drive is not marked Active, Setup will mark it as Active.

    • Boot partition. This is the partition that contains the files requires to run the operating system. By default in Windows Server 2003, Setup puts these files in a directory called \Windows. (In Windows 2000 and NT, the boot files are put in the \WINNT folder.) The boot partition can be on any drive. If you put the boot partition somewhere other than the boot drive, Setup prompts you to create a small system partition on the boot drive. This partition can be less than 1MB, just big enough to hold Ntldr, Ntdetect.com, Boot.ini, and Ntbootdd.sys.

    Licensing

    When you purchase a license for Windows Server 2003, you do not necessarily purchase the license to connect any clients to that server. For this, you need a Client Access License (CAL). A CAL is a piece of paper costing between $15 and $40, depending on volume and reseller markup, that gives you legal authorization to connect a client to a Windows Server.

    The purchase price of a Windows Server typically includes a pack of five or more CALs, but there are Stock Keeping Units (SKUs) that do not include any CALs at all, so you need to read the catalog carefully when you order. Keep those CAL certificates in a safe place. You'll need them if you ever get audited by the Software Publishers Association (SPA) or by your corporate auditors.

    When you upgrade from Windows 2000 to Windows Server 2003, you must buy CAL upgrades. The license agreement clearly states that the version number of the CAL must match the version number of the server to which the client connects. Here is where you experience the real expense of an upgrade. You might pay only $400 or $500 for the upgrade SKU of a Windows Server 2003, Standard Edition, but the CAL upgrade may cost you $10 to $20 per license.

    Windows Server 2003 has two forms of client access licensing: Per Device or Per User and Per Server. Both forms require purchasing a CAL, but the number of CALs you need to buy and how you track them differs.

    Per Server Licensing

    This licensing method resembles traditional licensing that you might recognize from NetWare or Banyan. Per Server licensing is a concurrent connection license. If you buy a copy of Windows Server 2003 with 25 CALs, for example, you must set the Per Server license value to 25 during Setup. The 26th concurrent user will then be denied access. If you get more than 25 users who need to access the server simultaneously, you must purchase additional CALs, then use the License Manager utility to increase the allowable number of licensed connections. Run the utility from the START menu via START | PROGRAMS | ADMINISTRATIVE TOOLS | LICENSE MANAGER.

    CALs and Application Servers

    It is not necessary to purchase Windows Server 2003 CAL if you are using a server as a platform for a client/server application. If you have a Lotus Notes service running on Windows Server 2003, for example, you do not need a CAL to connect a Notes client to that Notes service. If the user maps a drive to a Windows Server 2003 to run the Notes client executable across the network, however, you do need a CAL. If the application takes advantage of the Windows Server 2003 security subsystem for authenticating connections, you need a CAL as well.

    Recovering from a License Lockout

    Sometimes users stay connected to a server even though they are no longer using any resources on it. This chews up licensed connections and can cause a license lockout, where no further connections are accepted. A user with administrative privileges is permitted to log on during a license lockout to reset the license value or to disconnect users.

    If you install a second Windows Server 2003 with Per Server licensing, you must purchase another set of CALs for the same users who connect to the first server to legally connect to the second. Per Server licensing can get to be expensive if you have many servers.

    For the most part, Per Server licensing makes sense only when your servers have separate user populations, or at least very little overlap. Otherwise, it is much cheaper to use Per Seat licensing.

    Per Device/Per User Licensing

    Windows Server 2003 uses a different licensing scheme from any previous version of Windows or NT. Instead of a Per Seat license, the system has a Per Device or Per User license. In classic Per Seat licensing, every device required a Client Access License (CAL). If a developer had five computers in her cubicle, she would need five CALs to stay legal with the licensing agreement.

    In Per Device or Per User licensing, the developer with 5 machines would only require a single User CAL. By the same token, if a shift has 10 factory floor workers using handheld PCs to access the network, and workers on each shift use the same handheld PCs, then only 10 Device CALs would need to be purchased.

    So, if you have hundreds of PCs and a dozen users, you need to purchase 12 User CALs. If you have hundreds of users and a dozen PCs, you need to purchase 12 Device CALs. If a factory floor worker uses both a handheld PC to take inventory and another walkup workstation to file a time card, then you'll need either two Device CALs or a Device CAL and a User CAL. Granted that keeping track of these CALs can become quite an exercise, but you can save a lot of money if you have many occasional network users.

    Any connection that involves a network service, with the exception of anonymous web connections used by nonemployees, requires either a User or Device CAL. This includes using third-party products such as NFS redirectors or ftp services.

    You can change from Per Server to Per Device or Per User licensing, but this is a one-time conversion. You cannot go back to Per Server licensing for that particular server. The conversion only makes sense if your organization has grown to the point where purchasing individual licenses for multiple servers doesn't make sense.

    Terminal Server Licenses

    Unlike NT4, Windows Server 2003 comes with terminal services built right into the operating system. It is exposed by default via the Remote Desktop service. Only administrators can connect to a server via Remote Desktop, though, with a two-connection limit. If you want to allow non-administrative users to access a server using terminal services sessions, you must install Terminal Services to enable the Application Services mode.

    Licensing these terminal server sessions can get expensive and time-consuming. In addition to the CAL for the network connection, you must either pay for a Terminal Services CAL or a license of Windows XP Professional. This is because the terminal server session is considered to be just like running a copy of XP. You can get volume discounts for these Terminal Services CALs that can dramatically reduce their cost.

    There is an additional subtlety you need to keep in mind when managing TS (Terminal Server) licenses. Licenses are issued to client hardware, not users. When a client makes a remote desktop connection to a Terminal Server, the client is issued a TS CAL that it embeds in its Registry or NVRAM. If you reinstall the operating system, the client will obtain another CAL. When a TS CAL has not been accessed for 120 days, it is returned to the license pool where it can be reused. Windows 2000/XP clients do not consume a license when connecting to a Windows Server 2003 Terminal Server.

    Many administrators prefer to use the Citrix MetaFrame product, a multiuser interface that layers on top of Terminal Services. MetaFrame supports a wide variety of features that are not in standard Terminal Services, such as connecting from non-Windows clients, individual application publication, and more manageable server farms. If you plan on deploying MetaFrame on top of Windows Server 2003, you must still pay for the Microsoft Terminal Services CAL in addition to the Citrix server and client licenses.

    Tracking Per Seat Licenses

    A Licensing Manager service on each server keeps track of everyone who accesses the server in a licensable manner. This includes file services, print services, network authentication, and so forth.

    If the License Manager service says that 5,000 different clients have connected at one time or another, you'll need to show an auditor 5,000 CALs. If you have multiple users who access the same computer (in a lab, for example, or a kiosk machine used to file time cards), License Manager will only report the need for a single CAL for the computer.

    The License Manager service maintains three files:

    • Cpl.cfg. This file contains purchase history information. It is located in \Windows\System32.

    • Llsuser.lls. This file contains connection and user information. It is located in \Windows\System32\Lls.

    • Llsmap.lls. This file contains License group information. License groups are used to identify users who access the same machines and do not need independent CALs. The file is located in \Windows\System32\Lls.

    Keeping track of CALs for Per Seat users at individual servers in a big network can absorb a lot of energy. Windows Server 2003 simplifies this by providing a License Server option. Each site would have a central license server to collect licensing information. The server is primarily intended for tracking Terminal Server licenses, but can collect other license information as well.

    Server Naming

    One of the decisions you have to make during Setup is what to name the server or desktop. The naming rules come from old NetBIOS standards that go back to the dark ages of the middle 1980s. This is when Microsoft and IBM worked together with other companies to develop PC networking standards. Windows Server 2003 does not use NetBIOS, but the naming restrictions remain. Here they are:

    • Name length. A computer or username can be no more than 15 characters long. The actual limit is 16, but the operating system inserts a final character, not ordinarily visible from the user interface, that identifies the NetBIOS service using the name. For example, the Workstation service running on a computer named RUMPLESTILTSKIN would have a full NetBIOS name of RUMPLESTILTSKIN[03], where [03] is the hex ID for the Workstation service. Shorter names are padded to 15 characters.

    • Flat namespace. A NetBIOS name must be unique on a network. Two Windows machines in the same broadcast domain and the same IP subnet, or registered with the same WINS server, cannot have the same name. Active Directory also imposes a flat namespace on computer names within a domain. Even though you can build an Active Directory hierarchy with different domain names, you should still implement a naming convention that ensures unique computer names throughout your organization.

    • Special characters. NetBIOS permits special characters such as spaces, pound signs, percent signs, and so forth. Because Windows Server 2003 also relies on DNS, you should not use any special character not supported by DNS. You may want to avoid underscores if you are concerned about full DNS compatibility, although recent changes to the DNS RFCs permit using an underscore. SQL servers should also avoid underscores due to problems they cause with SQL queries.

    Changing Computer Names

    You can change the name of a standalone server or a domain member server using the System Properties window in Explorer. In Windows Server 2003, you can change the name of a domain controller using a new NETDOM option called RENAMECOMPUTER. This requires that the domain be running in full Windows Server 2003 functionality level. See Chapter 9, "Deploying Windows Server 2003 Domains," for more information.

    Renaming a server requires users to remap their network drives and recreate shortcuts that include the server's name. This is generally a painful experience, for them and for you. You can avoid some of this pain by putting an alias in WINS and DNS.

    You can also use the Distributed File System (Dfs) to represent your server-based resources as elements in a virtual directory tree. Dfs enables you to rename servers and shares without disturbing user mappings. See Chapter 16, "Managing Shared Resources," for more information.

    Managing Administrator Passwords

    All Windows Servers have a default account called Administrator. The Administrator account has full privileges on the machine. During Setup, you assign a password to the Administrator account. The password is saved in the local Security Account Manager (SAM) database.

    When assigning the local Administrator password, make it long, unique, and cryptographically strong. Don't lose the password. If the server is a domain member, you can log on using a domain account, but the Administrator account in the SAM may be your only way to log on locally. If you do forget the Administrator password, or you inherit a server without finding out the password, you can use a utility called ERD Commander from www.sysinternals.com to change any password in the SAM. There are two versions of this utility, shareware and for-fee. Only the for-fee version has the capability of changing passwords.

    Domains and Workgroups

    Windows Server 2003 and classic NT use two terms that are not actually related to each other but often get confused: domains and workgroups. Here is a definition of each:

    • A domain is a security entity. Domain members obtain their authentications from special servers called domain controllers.

    • A workgroup is a resource-location entity. Workgroup members locate each other using special servers called browsers.

    If you lived through the Cold War as I did, you'll appreciate the source of the confusion of these two terms. Do you recall Khrushchev or Breshnev? Each man wielded ultimate power in the USSR because he held two positions, the head of the Supreme Soviet and the chairman of the Communist Party. In the same way, a primary domain controller (PDC) makes domains and workgroups appear to be the same thing because it holds both the security database and the browsing database.

    Using Workgroups

    If you install a server that has no need for security affiliations with other machines, you can make it a standalone server that is a member of a workgroup. Clients in the same workgroup on the same IP subnet share the same browser, so they can find the server. Users will be authenticated via the local SAM on the server when they make network connections.

    Even if you have a domain, it sometimes makes sense to install standalone servers. For instance, you may have servers in a DMZ that you do not want to communicate secure logon information back through the firewall.

    Joining Domains

    To avoid relying on a separate authentication database at the server, you need to join it to a domain. It then becomes a member server of the domain.

    Member servers in an Active Directory domain authenticate users via Kerberos. This provides a highly secure and fast authentication mechanism and one that also contains the authorization information necessary to build a local security context for the user.

    Member servers in a classic NT domain authenticate users via NT LanMan Challenge-Response. This requires the server to have a direct line of communication with a backup domain controller.

    In classic NT, it was necessary to provide Administrator credentials to join a computer to a domain. In Windows Server 2003 (and Windows 2000), any authenticated user can join a computer to a domain. This is determined by a group policy linked to the Domain Controllers Organizational Unit (OU) in Active Directory. You can change this group policy to restrict who can join computers to a domain.

    Dates and Times

    One of the final steps taken by Setup is configuring the date and time at the machine. This seemingly trivial operation turns out to be critical for a couple of reasons.

    File Timestamps

    When you create, modify, or access a file, the file system changes a timestamp attribute in the file record. The timestamp comes from the server clock, not the client clock. The timestamp uses a universal time code. When a client views the timestamp, the time is corrected for the client's time zone. If clients are not synchronized with server times, users will have difficulty sorting through similar files on different servers to see which are the most recent.

    Limitation on Authenticated Users Joining Computers to Domains

    In Windows Server 2003, members of the Authenticated Users group have the privilege of joining a computer to a domain. There is a limit on this privilege, though. An attribute called ms-DS-MachineAccountQuotain the Active Directory Domain object sets the total number of times a non-administrative user can join a computer to a domain. By default, the value for this attribute is set at 10.

    When an Authenticated User who is not a Domain Admin joins a computer to the domain, the Computer object in Active Directory is given an additional attribute called ms-DS-CreatorSID. When the user tries to join additional computers to the domain, the system counts the number of Computer objects that have the user's SID in the ms-DS-CreatorSID attribute. When the user exceeds the ms-DS-MachineAccountQuota limit of 10, he gets an "access denied" error. You can use the ADSI Editor in the Resource Kit to change the value for ms-DS-AccountQuota. You can also delete the Authenticated Users group from the Add Computer to a Domain group policy.

    Kerberos Timestamps

    Windows Server 2003 uses tickets issued by the Kerberos service to control access to the domain and to member servers. Kerberos tickets contain timestamps to thwart bad guys who might copy the tickets and use them later to impersonate a user. If the clock on the client were to get out of synchronization with the domain controllers, the client's Kerberos tickets would be perpetually invalid.

    Time Synchronization

    Windows Server 2003 keeps time synchronized between domain controllers and domain members using the Windows Time Service (WTS). The actual service name is W32Time.

    Every Windows 2000, XP, and Windows Server 2003 desktop and server has the W32Time service loaded by default. When a desktop or server joins a Windows Server 2003 domain, the service is enabled so the client can synchronize clocks with its logon server.

    W32Time uses RFC-compliant Simple Network Time Protocol (SNTP). The time standard for a Windows Server 2003 domain is the PDC Emulator, normally the first domain controller promoted in the domain. The time standard for a Windows Server 2003 forest is the PDC Emulator in the first domain in the forest, also called the forest root.

    Configuration Phase

    Following the completion of the graphical setup phase, the machine restarts. This marks the official end of Setup as a distinct process running on the server. However, from a practical standpoint, a few final nips and tucks need to be done. A user must log on at the console of the server and configure the machine before it can be considered ready for production.

    Initial User Logon

    After the machine restarts following the graphical installation phase, a Welcome to Windows screen appears prompting the user to press Ctrl+Alt+Del to log on. This is known as the Secure Attention Sequence (SAS). The SAS reduces the possibility that a Trojan Horse program could impersonate the logon window and capture the user credentials.

    Winlogon

    The console logon process is controlled by a service called Winlogon.exe. Winlogon works in concert with the Local Security Authority (LSA) to authenticate the user via a set of authentication providers. Kerberos is the primary provider in a Windows Server 2003 domain. An NTLM (NT LanMan Challenge Response) provider and an LM (LanMan Challenge Response) provider are also present for backward compatibility with NT and Windows 9x and for use in standalone machines.

    The window that collects the logon credentials comes from the Graphical Identification and Authentication library, Msgina.dll. This is commonly called the GINA. Third-party vendors can replace this library with their own GINA. For example, Novell replaces the GINA window with one that collects NDS, bindery, and scripting options along with the standard Windows logon information.

    If the computer was joined to a domain during Setup, the logon window has a drop-down box listing available domain names along with the local computer name. This gives the user the option of logging on to a domain or just to the local SAM.

    Final PnP Enumeration

    Plug and Play takes advantage of the initial user logon to discover and report any devices that were missed or skipped during Setup. If PnP cannot find drivers, the user is prompted to provide them. Depending on the nature of the devices, the kind of drivers they use, and the resource allocations required to get the devices working, the user may be required to restart the machine.

    For example, PnP may not have found drivers for the video adapter so the system installed default VGA drivers. At the first user logon, the user will be prompted to replace the drivers. The system can be told to look at the Windows Update site for replacement drivers. This requires that the machine have an Internet connection, either through dial-up or over a LAN.

    This completes the installation overview. It's time to do some real work. Proceed to the next section in this chapter for step-by-step instructions for installing Windows Server 2003 on a new machine.

    IA64 Setup Differences

    As mentioned earlier, the Extended Firmware Interface (EFI) in an IA64 system boots using a boot menu stored in firmware rather than in a Boot.ini file on the hard drive. Also, the boot drive must contain certain special partitions to hold bootstrap code and special Microsoft data structures.

    Windows Server 2003 Setup automatically makes the necessary changes to the firmware boot menu and the drive partitioning if you choose to let it. If you have a drive that came from the vendor with partitioning already in place, you should verify that the drive has the following partitions:

    • EFI System Partition (ESP)

    • Microsoft Reserved Partition (MSR)

    • OEM partition (optional)

    • One or more data partitions (optional)

    You can use the EFI Shell to verify the partitioning.

    EFI Shell

    The EFI Shell is one of the options presented in the boot menu. Here is an example boot menu listing:

    EFI Boot Manager ver 1.02 [12.36A]
    
    Please select a boot option:
    
    Microsoft Windows Server 2003, Standard Edition
    Acpi(PNP0A03,0)/Pci(5|0)/Mac(0003478991556)
    EFI Shell [Built-in]
    Boot option maintenance menu
    

    When you select the EFI Shell option, the system launches an operating environment with full access to FAT and FAT32 partitions and a short set of commands for manipulating files and configuring the system.

    When the EFI Shell first loads, it lists the available partitions on the drives. You can repeat this list using the MAP command from the shell prompt. Here is an example MAP listing for a machine with several partitions:

    Device mapping table
    
      fs0  : VenHw(Unknown Device:80)/HD(Part1,SigBD1C1A20-685C-01C1-507B-9E5F8078F531)
      fs1  : VenHw(Unknown Device:80)/HD(Part5,Sig1FD4472C-D516-11D5-8473-806D6172696F)
      fs2  : VenHw(Unknown Device:FF)/CDROM(Entry1)
      blk0 : VenHw(Unknown Device:00)
      blk1 : VenHw(Unknown Device:80)
      blk2 : VenHw(Unknown Device:80)/HD(Part1,SigBD1C1A20-685C-01C1-507B-9E5F8078F531)
      blk3 : VenHw(Unknown Device:80)/HD(Part2,Sig1FD44720-D516-11D5-8473-806D6172696F)
      blk4 : VenHw(Unknown Device:FF)
      blk5 : VenHw(Unknown Device:FF)/CDROM(Entry1)
    

    The long number in each entry is the GUID assigned to the partition. Each partition is identified with a blk# sequence number. Partitions with readable file systems (FAT, FAT32, and Joliet CD-ROM) are also assigned an fs# alias.

    You can access partition blocks in the EFI shell by entering the block name followed by a colon, such as blk3:. This is the same way you would change logical drives at the command prompt of an operating system. You can list the files and folders in each readable partition by running dir or ls at the prompt.

    You can get a partial list of the commands available in the EFI shell by typing ? at the shell prompt. If you want a full list of the commands, visit the Intel web site at cedar.intel.com.

    You may notice that you are not prompted for a password prior to entering the EFI Shell. Physical security is the only option for protecting the firmware settings in an IA64 server.

    EFI Boot Maintenance Manager

    The EFI boot menu has a Boot Maintenance Manager that permits making modifications to the entries in the boot menu. It is not necessary to use this utility to manage Windows Server 2003 boot entries. All Windows Server 2003 boot entries are managed from within the operating system using either System Properties or the BOOTCFG command.

    You may, however, encounter instances when you want to change the boot order using the Boot Maintenance Manager if you have multiple operating systems. Here are the options:

    • Boot from a file. This option permits you to navigate to a partition, including a CD-ROM or floppy, and launch a boot loader. You can use this option to initiate Setupldr.efi on the Windows Server 2003 CD in preparation for running the Recovery Console. Chapter 21, "Recovering from System Failures," has details.

    • Add a Boot Option; Delete Boot Option(s). This option permits you to change the boot menu itself. Each boot menu item is associated with a partition and a boot loader.

    • Manage BootNext Setting. This option permits you to select which of the Boot Manager options will be launched automatically at boot time.

    • Set Auto Boot Timeout. This option sets the Boot Manager delay interval before launching the option selected by the BootNext option. The default timeout is 30 seconds. Using System Properties in Windows Server 2003 to change the boot menu selection timeout also changes this setting in NVRAM.

    • Console Devices. These options define the standard console output, input, and error devices. You can use these options to redirect the console to one of the serial ports. This is similar to the Emergency Management Services (EMS) option in the IA32 version where you can define a serial port in Boot.ini to receive console output.

    • Cold Reset. This restarts the machine using the same POST as if the power switch had been cycled.

    Booting Windows Server 2003 Setup Using the EFI Shell

    IA32 systems will boot to an El Torito CD-ROM automatically if the boot sequence in CMOS is set to permit this action. An IA64 system does not recognize an El Torito disk. You must initiate Setup manually using the EFI Shell.

    Do this by selecting the EFI Shell from the boot menu then changing to the fs# alias that represents the CD-ROM. Ordinarily, this would be fs0 unless there are other operating systems already installed. Launch the setup boot loader, Setupldr.efi, from the root of the CD. Files with an .efi extension contain executable code compatible with the EFI Shell.

    The only portion of Windows Server 2003 Setup that looks different on an IA64 machine is the partitioning method for the boot drive. If the boot drive already has an EFI System Partition (ESP), Setup will prompt you of the necessity for a Microsoft Reserved Partition (MSR) and will create one automatically. If the drive has no pre-existing partitions, Setup will create the ESP and MSR partitions, format them, and prompt you to create a partition for the operating system files.

      Previous Section Next Section