How To Add Usb 3.0 Driver In Windows 7 Iso Image

0 views

Skip to first unread message

Dorthea Seate

unread,

Aug 3, 2024, 10:26:57 AM8/3/24

to oledthehe

You can use DISM to install or remove driver packages in an offline Windows or Windows PE image. You can either add or remove the driver packages directly by using the command prompt, or apply an unattended answer file to a mounted .wim, .ffu, .vhd, or .vhdx file.

When you use DISM to install a driver package to an offline image, the driver package is added to the driver store. When the image boots, Plug and Play (PnP) runs and associates the driver packages in the store to the corresponding devices on the computer.

To add driver packages to an offline image, you must use a technician computer running Windows 10 or later, Windows Server 2016 or later, or Windows PE for Windows 10 or later. Driver signature verification may fail when you add a driver to an offline image from a technician computer running any other operating system.

If you're adding driver packages to a Windows PE image, you can add them to the Windows PE image in the output folder you specified when you ran copype, for example: C:\WinPE_amd64\media\sources\boot.wim. This ensures that driver packages will be included in Windows PE each time you build Windows PE media from that folder.

Using /Recurse can be handy, but it's easy to bloat your image with it. Some driver packages include multiple .inf driver packages, which often share payload files from the same folder. During installation, each .inf driver package is expanded into a separate folder. Each individual folder has a copy of the payload files.

Check to see if the driver package was added. Driver packages added to the Windows image are named Oem*.inf. This guarantees unique naming for newly added driver packages. For example, the files MyDriver1.inf and MyDriver2.inf are renamed Oem0.inf and Oem1.inf.

All driver packages in the directory and subdirectories that are referenced in the answer file are added to the image. You should manage the answer file and these directories carefully to address concerns about increasing the size of the image with unnecessary driver packages.

If you need driver packages for Windows PE to see the local hard disk drive or a network, you must use the windowsPE configuration pass of an answer file to add driver packages to the Windows PE driver store. For more information, see Add Device Driver packages to Windows During Windows Setup.

Check to see if the driver package was added. Driver packages added to the Windows image are named Oem.inf. This guarantees unique naming for newly added driver packages. For example, the files MyDriver1.inf and MyDriver2.inf are renamed Oem0.inf and Oem1.inf.

To save time during installation and to speed up the out-of-box experience (OOBE) for end users, you can instruct Windows Setup to maintain the driver configurations from the reference computer as part of the Windows image. You should do this only when the hardware on the reference computer and the hardware on the destination computers are identical. When you do this, Windows Setup maintains driver configurations during image capture and deployment.

If the computer has undetectable hardware, include the Microsoft-Windows-PnpSysprep/DoNotCleanUpNonPresentDevices setting. For more information, see the Undetectable hardware section in this topic.

The Windows in-box driver packages include device drivers that support a wide variety of popular hardware. If your specific hardware requires additional device drivers to boot, you can preinstall additional device drivers on your Windows image. Independent Hardware Vendors (IHVs) often supply these additional device drivers together with their device hardware. For more information about how to add device drivers, see Add a Driver Online in Audit Mode.

To prepare a Windows image for deployment to multiple computers, you must use the System Preparation (Sysprep) tool to generalize the Windows image. Generalizing a Windows image removes the computer-specific information and prepares the device drivers for first boot. This preparation includes these steps:

When you generalize the computer, use an answer file that has the Microsoft-Windows-PnpSysPrep\PersistAllDeviceInstalls setting to save time. This setting prevents Windows Setup from removing and reconfiguring the device state for identical hardware. On first boot, the detected device drivers are already preconfigured, potentially enabling a quicker first-boot experience.

Important Avoid using the PersistAllDeviceInstalls setting when the hardware and the hardware configuration on the reference computer are not identical to those of the destination computers. Even seemingly minor differences in hardware or hardware configuration can cause severe or easily overlooked problems. For more information, see the Troubleshooting Hardware Configuration Differences section of this topic.

It's a good practice not to use the PersistAllDeviceInstalls setting on your primary reference image. Instead, for each group of computers that have a different hardware configuration, first load your primary reference image onto a new reference computer that has the planned hardware configuration. Next, capture a new image of this setup and use the PersistAllDeviceInstalls setting.

Normally, when Windows Setup boots a computer and multiple versions of a driver package exist on that computer, Setup determines which driver to install by using driver ranking. But when you use the PersistAllDeviceInstalls setting, the normal driver-ranking processes don't occur. So, devices that use outdated drivers may remain installed. For more information about driver ranking, see How Windows Ranks Drivers on MSDN.

For the PersistAllDeviceInstalls setting to work correctly, the hardware configuration must be identical on the reference computer and on the destination computers. Hardware configuration includes the following components:

Firmware. Updates, revisions, and configuration differences can cause some devices to report different criteria for matching device drivers or to use different resources. For example:

BIOS revisions can change the Advanced Configuration and Power Interface (ACPI) namespace. This causes Windows Setup to report existing devices differently or to introduce existing devices as new devices.

When the boot-critical hardware is not identical on the reference computer and destination computers, using the PersistAllDeviceInstalls setting can cause severe system problems that can leave the computer in a non-bootable state.

When you deploy a new computer to an end user, some hardware, like a removable device or a device that has an on/off switch, may not be present or detected during first boot. By default, on first boot, Windows Setup removes the preconfigured device state for undetected hardware.

To deploy hardware that may not be present or detected on first boot, add any applicable device drivers to the reference image, connect or turn on the applicable devices so that Windows can install them, and use the Microsoft-Windows-PnpSysprep/DoNotCleanUpNonPresentDevices setting when you capture the image.

In the following example, a fictitious IHV named Fabrikam produces two types of storage controllers: StandardController and ExtremeController. Fabrikam assumes that only one type of storage controller is installed at a time on a particular computer.

The driver package defines the StandardController and ExtremeController configurations to use the same driver service name, storctrl. The storctrl driver service uses different service settings that change depending on which hardware (StandardController or ExtremeController) is installed. Because both StandardController and ExtremeController use the same service, they cannot coexist.

If StandardController is on the reference computer and its settings are maintained during image capture, the storctrl driver service is preconfigured. If ExtremeController is on the destination computer, Windows may use the preconfigured settings and files that are intended for StandardController. This can cause unexpected results.

I have created a generalized Windows 10 image in Hyper-v. I now want to apply this image to a physical machine. Is there a best practice of installing drivers (Dell) to a generalized machine? Do I really have to install everything manually?

You could create a network share driver store. Then, imaged computers would just need to access the share to pull down drivers. Obviously, this requires that your image have a usable network adapter driver.

I too was going to suggest WDS. If you inject the drivers for a Dell, or any other manufacturer PC, it will always be in that image. Using WDS allows you to pick and choose the drivers required for the model PC.

That is indeed the way to go. Either that or MDT. Both are free with Windows Server (MDT can be used for free on a PC as well). You really only need to update drivers once or twice a year. But that just gives you another reason to standardize on hardware.

So in essence - If I spun up a WDS server and imported my image and added the drivers in WDS. I could deploy this image and upon logging - all the drivers would be installed or start installing automatically? Correct? If so, I will try this today!

Ohh, and how is your network set up? Is the WDS server going to be installed on the DHCP server? If not, are they on the same subnet? Are both of these servers on the same subnet as the target computers?

I'm trying to install an image to a machine. I keep getting storage driver errors where it can't find the hard drives. That's fine, so I went and got the drivers and added them. I regenerated the boot image completely. Do I need to do another sysprep or should I be able to get by with just injecting the drivers into the boot image (i.e., regenerating the boot image)?