Windows 7 / Getting Started

---

Hardware Considerations

Sometimes hardware differences between references systems cause problems. If you create the image properly, it can truly be hardware-agnostic. This task may be more difficult in Windows XP than Windows 7 because of HAL issues and mass storage drivers, but it is not impossible. To implement OSD successfully, you should derive a full inventory of all hardware used in the targeted environment. From this inventory, determine if any anomalies exist, if all the drivers are still available from the manufacturer, and if all the systems meet the minimum requirements for the OS you deploy.

As OSD includes the ability to inject drivers into the deployment process, you do not have to include all possible drivers from all systems in your organization, bloating your images with files not used on every system. Driver injection is discussed in the "Driver Management" section of this tutorial.

When deploying Windows XP, different HAL types are potentially the biggest obstacle to creating a hardware agnostic image. Here are the six HAL types supported by XP:

• ACPI Multiprocessor PC
• ACPI Uniprocessor PC
• Advanced Configuration and Power Interface (ACPI) PC
• MPS Multiprocessor PC
• MPS Uniprocessor PC
• Standard PC

The non-ACPI HALs in this list are legacy types and normally needed only for old hardware. Based on your hardware inventory, you probably can rule out their use.

TIP:
The Microsoft TechNet article "Identifying Hardware That Impacts Image-based Installations" (http://technet2.microsoft.com/windowsserver/en/library/942aaa8c-016f-4724-9a0f- 04871abadd1a1033.mspx?mfr=true ) describes how to identify what HAL a running system uses. Briefly, you must inspect the properties of the hal.dll file located in % systemroot %\ system32 and compare the file details to the chart in the article.
You can identify the exact HAL in a captured image by right-clicking the image in ConfigMgr and choosing Properties . In the resulting dialog box, choose the Images tab at the top.

Eliminating legacy hardware typically leaves the following three ACPI HAL types three rules for imaging:

• Images created with ACPI Uniprocessor PC HAL: You can deploy these images to hardware requiring either ACPI Uniprocessor or ACPI Multiprocessor HALs.
• Images created with ACPI Multiprocessor PC HAL: You can deploy these images to hardware requiring either ACPI Uniprocessor or ACPI Multiprocessor HALs.
• Images created using the Advanced Configuration and Power Interface (ACPI) PC HAL type: You cannot use these images on systems requiring either of the other two HAL types. Fortunately, hardware requiring this HAL type is outdated and no longer common.

This means you have to create only one image to support all your systems because they all require either ACPI Uniprocessor or ACPI Multiprocessor HALs. If through trial and error or through your hardware inventory you discover that another HAL type is in use, the only supported method of deploying images is to create multiple images, each containing a different HAL.

Mass storage drivers present a similar challenge; because they are essential to booting a system, they are referred to as boot critical . Windows XP does not include a huge variety of the modern boot critical drivers; this includes a lack of SATA drivers. You add bootcritical drivers to Windows XP in a different way than all other hardware drivers; you see this when manually installing a system requiring a boot-critical driver because you need to push F6 to install the driver during the blue screen pre-installation phase. OSD gracefully handles this situation with little overhead or extra work as discussed in the "Drivers Category" section.

Windows 7 includes the most popular SATA drivers out-of-the-box. If you do encounter a drive controller requiring a driver not included out-of-the-box, you can load the driver the same way as other hardware drivers-this is due to an architectural change made by Microsoft in the boot process and the handling of boot critical drivers starting in Windows Vista.

Although creating multiple images initially sounds like a bother, it should not be. If you have properly automated your image build process using a Build and Capture task sequence (discussed in the "Task Sequences" section), creating multiple images is as simple as running that sequence on a system supporting each type of HAL in your inventory. The task sequence is automated, so the images will be identical except for the HAL type that they contain. That's not to say that having multiple images of the same OS edition is a good thing, but in this case, there is no supported, practical alternative.

In addition, using the magic that is ImageX, these images can be merged into a single file using the /append option: imagex /append < image_path > < image_file > <" image_name "> [<" description ">]. Because of the single instancing of WIM images, the resulting WIM file contains only one copy of each file in common between the images (which will be every file except one, the hal.dll). The result is that the WIM file will be only slightly larger than maintaining separate WIM files for each version.

The only real pain point with this solution is finding a reference system for each type of HAL. Because most of these HALs are legacy and used only on aging or outdated hardware, chances are that you do not have any in your lab and will have to procure one from an active user.