- The right HAL
- The right kernel
- One or more boot-time drivers needed to support the storage underlying the boot volume
- An HKLM\SYSTEM\ControlSet00X\Control\CriticalDeviceDatabase\ entry to associate needed boot-time device(s) with service(s). This is an alternative to the usual Device Manager or Add New Hardware wizard, which both require the system to be booted, thus performed before the image is captured
- An HKLM\SYSTEM\ControlSet00X\Services\ entry with Start set to 0 to inform NTLDR to load the driver at boot-time
- Any needed .SYS and .DLL files that the above-mentioned service(s) require, so NTLDR can load them all.
In fact, it is my understanding that this is mostly what SysPrep's MassStorageDevices section is for... It injects the above sub-points into the Registry before shut-down. If you already have the hardware installed, then you don't need to include device ID-to-driver association in SysPrep.
The above-mentioned information can be performed on a captured image ("offline") in order to allow the image to boot on the target platform. You can use RegEdit's File -> Load Hive... to load the \Windows\System32\Config\SYSTEM hive and gain access to such things as the CriticalDeviceDatabase. File -> Unload Hive, possibly copy the SYSTEM Registry hive back into the image, and that part is done.
Any non-boot-critical devices can be installed either via Mini-Setup (which people call "SysPrep" far too often, by the way) or via a batched or automated process. If you have networking available or some other available file repository for drivers, you needn't include non-boot-critical devices in your image.
To identify files needed by a driver, you can look in Device Manager, to the device's Properties..., on the Driver tab, in the Driver Files... Additionally, you often need to know which .INF file is used to install the device. You can find this by looking in the Registry, finding the device under HKLM\SYSTEM\CurrentControlSet\Enum\, checking its Driver value, then looking under the corresponding key under HKLM\SYSTEM\CurrentControlSet\Control\Class\. You will often find an OEMXX.INF file staring back at you, for hardware not supported out-of-the-box by Windows' installation media. You can also determine the .INF file and other driver files by using DEVCON.EXE, I believe with its driverfiles option.
If your different hardware platforms require different HAL & kernel combinations, you could:
- Include all combinations in BOOT.INI and have all files available in \Windows\System32\ and you will need to manually select the correct choice
- Have a post re-imaging step which can access the freshly re-imaged filesystem and replace the HAL and kernel (NTFS users will need some kind of access, which is part of what makes a PE environment so popular for system deployment)
Populating an image with storage controller drivers and CriticalDeviceDatabase entries using somebody's online "latest, greatest" set of known hardware can be nice, but it will have to keep up with new hardware, and you will have to keep up with keeping your "universal" image up-to-date. Additionally, you also wind up with a lot of boot-start drivers and files in the \Windows\System32\Drivers\ directory, though some of them will not be used.
If the trojan-accused package in this thread's tutorial takes care of a lot of this business, I ask: Would the package's author be kind enough to provide their device ID-to-driver association database? For people who don't wish to risk getting a trojan, this might be handier for them. Obviously this is just asking out loud, since the package's author might not be a Boot-Land reader. Even a batch file to download needed files from online sources as well as populate the CriticalDeviceDatabase and needed Services might be nice.
How does SPAT know about future hardware that hasn't been developed yet? Is that hardware included in "image working on all computers?"