No Comments Written by Anders on February 29, 2008 – 6:25 am

Remote Installation Services allows Windows XP deployment from a network server, such as Windows 2000 (or 2002) Server, Advanced Server, or Datacenter, using a setup wizard. This guide will assume you have access to Windows 2000 Server; however Windows 2002 Server will have mostly similar prompts and dialogs. Before you enable RIS on a Windows Server machine, it is wise to install the RIS update Microsoft has provided on their Web site if you have not already installed Service Pack 1 (SP1).

You must install RIS on either a member server or a domain controller. It does not matter which. The Windows Server must have DNS, DHCP, and Active Directory, as RIS relies heavily on these services to function. The client computers must have either a PXE boot ROM enabled network adapter or a network adapter supported by the boot floppy that can be created by a remote boot floppy generator (RBFG.exe). The Windows XP images must be stored on a shared volume other than the volume that Windows Server is installed on, and has to be formatted with NTFS 5.

To enable RIS, you must log on to the Windows Server with Administrator privileges and navigate to the Control Panel > Add/Remove Programs. Choose Add/Remove Windows components, and be sure that you have access to either an i386 folder or the Windows 2000 Server CD-ROM. At the Add/Remove Windows components screen, you will check mark Remote Installation Services. This will automatically install RIS on the server. If the i386 files cannot be located, you will be prompted for them. Unfortunately, the server must be restarted after RIS is finished installing.

To begin RIS configuration, you may either navigate back to Add/Remove Windows components, or run RIS Setup from a command prompt, such via the Run command found under the Start menu. When you begin, you are prompted for the destination of the RIS files and Windows installation images. Again, this location cannot be a system drive (i.e., the C: drive), it must be formatted with NTFS 5, and it must have enough hard drive space to hold multiple installation images. RIS installations are quite in-depth.

Aside from the standard power-on self-test performed during the initial start-up of a PC, Windows XP has a much more complicated boot process than its sister operating system family, Windows 9.x. Ntldr, located in the root of the C: drive, performs several tasks critical to start-up:

1. The x86-based processors always start out in Real Mode. Real Mode disables certain processor features to enable backward compatibility with software designed for 8-bit and 16-bit processors. Ntldr switches the processor to 32-bit Protected Mode, enabling access to large amounts of RAM and all extended processor functions.

2. Ntldr also contains code to enable read and write access to file systems such as NTFS or FAT16/FAT32. Once this is parsed and loaded, Ntldr reads the BOOT.INI, also located in the root of the C: drive, to determine the location of the operating system.

3a. For dual-booting systems, your old master boot record sector was saved to a file in the root of the C: drive during initial installation of Windows XP, and that file is called BOOTSECT.DOS. When BOOT.INI detects multiple operating systems, you are prompted with a menu that will enable you to choose your operating system. If you choose an operating system other than Windows XP/2000/NT, then Ntldr executes BOOTSECT.DOS as if it were read from the actual master boot record sector, loading that operating system. The hidden file C:\BOOTSECT.DOS contains the boot sector to your old operating system, which was backed up during Windows XP installation. The file system boot sector is the first sector of a logical volume or partition, and is not to be confused with a master boot record, which begins with the first physical sector on a hard drive itself.

3b. If your system is single-booting or you chose Windows XP/2000/NT through a multiboot menu, then Ntdetect.com loads and performs basic device detection. Ntdetect.com detects hardware profile information, as well as Advanced Power Management Interface (ACPI) tables. Once that has completed, Ntldr passes BOOT.INI, Registry information, and hardware detection information obtained from Ntdetect.com on to Ntoskrnl.exe.

4. For non-ACPI systems, your hardware’s firmware and your BIOS provide the resources such as Interrupt Requests (IRQs) to Windows XP. For ACPI-compliant systems, Windows XP is able to assign and manage all necessary resources. After Ntldr launches Ntoskrnl.exe, the Hardware Abstraction Layer (HAL) is loaded into memory, providing secured access to hardware and their associated resources. A hardware abstraction layer catches all requests to hardware made by software and ensures security by preventing unauthorized direct access to hardware. All hardware interaction must be done via kernel-level system calls and Application Programming Interfaces (API). Depending on your type of computer, Windows XP setup installs a custom HAL. To see which HAL your system will have.

5. The kernel and HAL initiate a group of software components known as the Windows Executive. The Executive processes Registry configuration data, and starts services and hardware drivers. The Registry information parsed by the Executive contains the common control sets, such as the Last Known Good control set. The CurrentControlSet entry in the Registry is a clone of the control set created upon every boot of Windows XP. Ntldr searches the Services subkey of the Registry to find drivers and services with a Start key value of 0, such as hard disk controllers. Ntoskrnl.exe searches for and starts drivers with a Start key value of 1, such as network protocols. After all of the drivers and services have been loaded in memory, started, or both, the kernel starts Session Manager (known as Smss.exe).

6. Smss.exe performs the following functions, in this order:

Creates system environment variables.

Starts Win2k.sys, the kernel-mode portion of Windows, which switches Windows XP from text to graphics mode.

Starts the user-mode portion, Csrss.exe.

Starts the Logon Manager (Winlogon.exe).

Creates virtual memory swap files.

Replaces pending files that were in use during the last boot (such as when you are requested to restart Windows after installing a driver).

7. After Winlogon.exe executes, it launches several subsystems that provide security and functionality for services. The first thing that Winlogon launches is Services.exe, also known as the Service Control Manager (SCM). Next, the Local Security Authority (LSA, or Lsass.exe) is executed. Finally, Winlogon waits for and parses the CTRL+ALT+DEL key combination at the logon prompt. The Local Security Authority is responsible for validating local credentials, such as the user name and password, using the appropriate security protocol (e.g., Kerberos V5).

8. The control sets mentioned in step 5, above, are updated during the next phase of Winlogon.exe. Group Policy settings take effect after logging on, and then the user’s local start-up items, login scripts, and services are executed.

Plug-and-play detection runs asynchronously with the logon phases, and Windows XP extracts necessary drivers for new hardware from Driver.cab. If the drivers are not found, Windows XP prompts you to provide them. The logon and plug-and-play processes are the final steps in the start-up process.