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:
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.
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.
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.
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:
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.
Permits selecting an alternative kernel type. Options include ACPI, Standard PC, I486 C-stepping, and SGI MP.
Permits loading a third-party mass storage device driver that is not on the Windows Server 2003 CD.
Bypasses ACPI to load a standard PC kernel.
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:
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:
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:
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.
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.
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.
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:
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).
The floppy disk miniport driver.
Hardware Abstraction Layer (HAL).
There are several HAL drivers. Setup chooses one based on the type of hardware.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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:
This file contains purchase history information. It is located in \Windows\System32.
This file contains connection and user information. It is located in \Windows\System32\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.
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:
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, where  is the hex ID for the Workstation service. Shorter names are padded to 15 characters.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.