Jump to content

[HOWTO] Using DriverPacks w/ Sysprep


Recommended Posts

I've also posted these instructions on the DriverPack Forum, but I'm reposting it here to bring it to a wider audience (I sometimes feel like sysprep users are 2nd class citizen around here ;) ).

NOTE: This HOW TO assumes you are proficient with sysprep. If not, I recommend you read through this first.

1) Download the latest version of DriverPack BASE (7.05.2 at time of writing) and whatever DriverPacks you need.

2) Extract BASE to a folder by running the .exe you downloaded (example: DPs_BASE_7052.exe)

3) In the folder you extracted BASE to, open the 'bin' folder. Copy DPsFnshr.ini and extract DPsFnshr.7Z to C:\ on the computer you'll be running Sysprep on.

4) Inside of the BASE 'bin' folder, open the 'wnt5_x86-32' folder. Copy ROE.exe to C:\sysprep, and extract DevPath.exe from M2.7z to C:\ on the computer you'll be running Sysprep on.

5) Extract your DriverPacks with either 7-zip or WinRAR. If you have WinRAR integrated into your shell you can just control-click the Packs you want to select them, then right-click on one and choose "Extract Here". Make sure that they are all merged into the same folder structure under the 'D' folder (D\C, D\G, etc). You should also have a set of files ending with wnt5_x86-32.ini. These contain the various exceptions that DPsFnshr.exe reads when it runs.

6) Move extracted DriverPacks ('D' folder) and wnt5_x86-32.ini files to C:\ on the computer you'll be running Sysprep on.

6a) If you are slipstreaming DP_Graphics_A, create a dummy (Notepad) file in C:\. Name it ATICCC.ins if you want the Catalyst Control Center or ATICCP.ins if you want the Catalyst Control Panel installed when Radeon hardware is detected. The file can be blank as DPsFnshr.exe just looks for the file name. DPsFnshr.exe deletes the .ins file when it is finished running.

6b) If you want, you can modify the extracted driver packs to remove hardware you don't need. If you do, remember to move the modified driver pack to D\3\ (i.e. D\3\C, D\3\CPU, etc). If you want DPsFnshr.exe to run as intended (do to paths in the wnt5_x86-32.ini files), though, I would leave things like the DriverPack Graphics A unmodified.

7) Open a Command Prompt and run

C:\DevPath.exe C:\D

NOTE: Since you are loading your DevicePath with DevPath.exe, you can leave out the OemPnPDriversPath entry (under the [unattended] section) in your sysprep.inf file. OemPnPDriversPath has a 512 characters limit, but DevPath.exe gets around this by writing directly to the registry entry that OemPnPDriversPath gets loaded into by sysprep.

8) Open C:\DPsFnshr.ini in Notepad or Wordpad. Since we aren't actually running BASE we have to change the configuration for the Finisher manually. Generally, you will only need to edit the KTD and KTDlocation variables at the very top. If you do not want KTD enabled set:

KTD = "false"

If you want to KTD, put 'paths:' and then a list of folders in D you want to keep. Even if you want to keep all the drivers, I would still recommend specifying them individually due to the "double D" and Desktop.ini bugs in Finisher. For example, in my configuration, I want to keep all of the drivers. I have a D\3 folder when I've put my 3rd party and modified driver packs, and a D\G folder that contains an unmodified Driver Pack Graphics A. So my KTD line looks like:

KTD = "paths:D\G;D\3"

KTDlocation tell Finisher where to move the D folder to if you have KTD enabled. For example, I move my drivers to C:\WINDOWS\Options\Drivers so my KTDlocation line is:

KTDlocation = "%SystemRoot%\Options\Drivers"

9) Edit c:\sysprep\sysprep.inf and add the following lines under the [unattended] section:

UpdateInstalledDrivers = Yes
DriverSigningPolicy = Ignore

10a) (optional) If you want the Mass Storage drivers that come with XP added to your sysprep.inf then add the line:


to the very end of your sysprep.inf. Then, run

c:\sysprep\sysprep.exe -bmsd

10b)If you want to include the drivers in DriverPack MassStorage, then you will have to added them to the [sysprepMassStorage] section manually by opening up the various mass storage drivers' inf files and copying the vendor and device codes with a path to the inf file. There is a script that can automate the process for you here, but it doesn't seem to be perfect yet.

For example, all of the machines I am deploying my image on are based on Intel chipsets (IBM/Lenovos, and HPs). So, I can get away with only adding the Intel mass storage drivers. As of DriverPack MassStorage 7.06.2, this is the section I add at the begining of [sysprepMassStorage] after running sysprep -bmsd

PCI\VEN_8086&DEV_2652&CC_0106 = C:\D\M\IN\1\iaahci.inf
PCI\VEN_8086&DEV_2653&CC_0106 = C:\D\M\IN\1\iaahci.inf
PCI\VEN_8086&DEV_27C1&CC_0106 = C:\D\M\IN\1\iaahci.inf
PCI\VEN_8086&DEV_27C5&CC_0106 = C:\D\M\IN\1\iaahci.inf
PCI\VEN_8086&DEV_27C3&CC_0104 = C:\D\M\IN\1\iastor.inf
PCI\VEN_8086&DEV_2652&CC_0104 = C:\D\M\IN\1\iastor.inf
PCI\VEN_8086&DEV_24DF&CC_0104 = C:\D\M\IN\1\iastor.inf
PCI\VEN_8086&DEV_25B0&CC_0104 = C:\D\M\IN\1\iastor.inf
PCI\VEN_8086&DEV_2681&CC_0106 = C:\D\M\IN\2\iaahci.inf
PCI\VEN_8086&DEV_2821&CC_0106 = C:\D\M\IN\2\iaahci.inf
PCI\VEN_8086&DEV_2822&CC_0104 = C:\D\M\IN\2\iastor.inf
PCI\VEN_8086&DEV_27C6&CC_0104 = C:\D\M\IN\2\iastor.inf
PCI\VEN_8086&DEV_2682&CC_0104 = C:\D\M\IN\2\iastor.inf
PCI\VEN_8086&DEV_2829&CC_0106 = C:\D\M\IN\3\iaahci.inf
PCI\VEN_8086&DEV_2922&CC_0106 = C:\D\M\IN\3\iaahci.inf
PCI\VEN_8086&DEV_282A&CC_0104 = C:\D\M\IN\3\iastor.inf
PCI\VEN_8086&DEV_2680 = C:\D\C\I\xp\ESB2ide.inf
PCI\VEN_8086&DEV_269E = C:\D\C\I\xp\ESB2ide.inf
PCI\VEN_8086&DEV_244B = C:\D\C\I\xp\ich2ide.inf
PCI\VEN_8086&DEV_244A = C:\D\C\I\xp\ich2idem.inf
PCI\VEN_8086&DEV_248B = C:\D\C\I\xp\ich3ide.inf
PCI\VEN_8086&DEV_248A = C:\D\C\I\xp\ich3idem.inf
PCI\VEN_8086&DEV_24CB&CC_0101 = C:\D\C\I\xp\ich4ide.inf
PCI\VEN_8086&DEV_24CA&CC_0101 = C:\D\C\I\xp\ich4ide.inf
PCI\VEN_8086&DEV_24C1&CC_0101 = C:\D\C\I\xp\ich4ide.inf
PCI\VEN_8086&DEV_24D1&CC_0101 = C:\D\C\I\xp\ich5ide.inf
PCI\VEN_8086&DEV_24DB&CC_0101 = C:\D\C\I\xp\ich5ide.inf
PCI\VEN_8086&DEV_25A2&CC_0101 = C:\D\C\I\xp\ich5ide.inf
PCI\VEN_8086&DEV_25A3&CC_0101 = C:\D\C\I\xp\ich5ide.inf
PCI\VEN_8086&DEV_2651&CC_0101 = C:\D\C\I\xp\ich6ide.inf
PCI\VEN_8086&DEV_2652&CC_0101 = C:\D\C\I\xp\ich6ide.inf
PCI\VEN_8086&DEV_2653&CC_0101 = C:\D\C\I\xp\ich6ide.inf
PCI\VEN_8086&DEV_266F = C:\D\C\I\xp\ich6ide.inf
PCI\VEN_8086&DEV_27C0 = C:\D\C\I\xp\ich7ide.inf
PCI\VEN_8086&DEV_27C4 = C:\D\C\I\xp\ich7ide.inf
PCI\VEN_8086&DEV_27DF = C:\D\C\I\xp\ich7ide.inf
PCI\VEN_8086&DEV_2820 = C:\D\C\I\xp\ich8ide.inf
PCI\VEN_8086&DEV_2825 = C:\D\C\I\xp\ich8ide.inf
PCI\VEN_8086&DEV_2828 = C:\D\C\I\xp\ich8ide.inf
PCI\VEN_8086&DEV_2850 = C:\D\C\I\xp\ich8ide.inf
PCI\VEN_8086&DEV_2922 = C:\D\C\I\xp\ich9ahci.inf
PCI\VEN_8086&DEV_2923 = C:\D\C\I\xp\ich9ahci.inf
PCI\VEN_8086&DEV_2920 = C:\D\C\I\xp\ich9ide.inf
PCI\VEN_8086&DEV_2921 = C:\D\C\I\xp\ich9ide.inf
PCI\VEN_8086&DEV_2926 = C:\D\C\I\xp\ich9ide.inf
PCI\VEN_8086&DEV_2928 = C:\D\C\I\xp\ich9ide.inf
PCI\VEN_8086&DEV_292D = C:\D\C\I\xp\ich9ide.inf
PCI\VEN_8086&DEV_292E = C:\D\C\I\xp\ich9ide.inf

11) Open a Command Prompt and run

C:\sysprep\ROE.exe 937

This tells Windows to run C:\DPsFnshr.exe on the next reboot. I found that using [GuiRunOnce] in sysprep.inf to run DPsFnshr.exe resulted in the dreaded desktop.ini bug. Using ROE.exe to create a RunOnceEx entry for DPsFnshr.exe does not have this issue. DO NOT REBOOT BEFORE THE NEXT STEP OR DPsFnshr.exe WILL RUN!

12) Run sysprep.exe and reseal

BONUS: If your image is to be deployed on both single and multicore systems, then I'd highly recommend you check out MySysprep. It can detect a multicore CPU and switch HALs during minisetup.

Note: I was able to eliminate a lot of my sysprep/imaging issues (including minisetup looking for hdaudbus.sys in the wrong place) by NOT using RyanVM's update packs. In fact, I recommend only using nlite to slipstream SP2 and setup the Unattended section when building a disc. Since you're creating an image anyways, it doesn't hurt to run Windows update manually, and be 100% sure everything is install 'the Microsoft way'.


Edited by skinlayers
Link to comment
Share on other sites

  • 4 weeks later...


I am having some great difficulties with the hdaudbus.sys file not being installed automatically. When the sysprep mini setup starts, it will stop and ask for the driver. I can find the file by navigating to windows\system32\drivers and it will install and continue with mini setup, but I don't want to have to do this. I am not using any driver pack files. I just used Windriver Ghost to copy all of the drivers to a directory on our Altiris Server and I told my sysprep.ini file to go to the directory on the server to copy the files. All of the other files get copied and installed correctly. It is just the hdaudbus one that does not install. What am I doing wrong? Thanks.


Link to comment
Share on other sites

did you instal kb888111 to your image before sysprep?

No. I didn't know that would be a factor. I installed it on the new computer, copied the new drivers to the server and reimaged it. The problem persisted though. I will try your suggestion and report back.

Here is what our sysprep file says. The password has been blanked out. A copy of all of the drivers has been placed in the Drivers folder at the root.






ConfigureAtLogon = 0
BitsPerPel = 32
XResolution = 1024
YResolution = 768
VRefresh = 60
AutoConfirm = 1











Edited by IcemanND
Link to comment
Share on other sites

I assume you do not have subfolders under c:\drivers. Otherwise they are not being looked at unless you have another process updating the INF or the registry with the subfolders.

OemPnPDriversPath=Drivers sysprep setting does not look recursively through the directory only at the folder(s) specified.

Link to comment
Share on other sites

Yes. We have no folders under c:\drivers. We did have other folders when we had OemPnPDriversPath looking for drivers under different folders, but we cut all of that out to narrow the problem down. Thanks.

Link to comment
Share on other sites

Note: I was able to eliminate a lot of my sysprep/imaging issues (including minisetup looking for hdaudbus.sys in the wrong place) by NOT using RyanVM's update packs. In fact, I recommend only using nlite to slipstream SP2 and setup the Unattended section when building a disc. Since you're creating an image anyways, it doesn't hurt to run Windows update manually, and be 100% sure everything is install 'the Microsoft way'.


How did you get around using the dreaded "c_20127.nls" during mini-setup?


Link to comment
Share on other sites

I only ever had the problem with the NLS files not being found when I used nLite. So I quit using nLite.

Right, it's a problem with the path settings being modified by nLite best I can tell. I'm wondering if skinlayers is still having this issue. Copying the i386 directory to my sysprep folder seems like a lousy fix.

Link to comment
Share on other sites

  • 3 months later...

Hello, I followed these instructions and it worked amazingly well, in fact there was not a single unknown device left in the device manager, I couldn't believe it!

However I don't understand HOW it works, e.g. what do devpath.exe and makePNF.exe do?

I have tried to find info about them but just seem to end up at bizarre chinese pages with lots of wierd characters in.

The reason I am asking is because I want to know how far back in the instructions you have to go if you update the driver packs, can you just extract new driverpacks into C:\D\ and then rerun the steps from makePNF?

Also, another question which I have asked elsewhere and noone really seems to have answered...If you set your IDE controller to 'Standard' in your universal image do you still need to do 'sysprep -bmsd'?

Link to comment
Share on other sites

  • 6 months later...


I have been trying to create a Universal Ghost, but Sysprep does nothing after it install Mass Storage drivers, It just says "sysprep is working" and thats about it really nothing else happens even left it running over weekend.

Deleting Mass Storage entries works but then I have no drivers?????

Edited by rojanu
Link to comment
Share on other sites

Usually this is because there is a driver that sysprep did not "like". And it is a paine to figure out which one(s). Try cutting the list in half, if it works with the half you left behind add in half of the remainder until it stops working. If it stops working then remove half of the last half added , repeat this process until you find your culprit.

Or if you know that your target systems primarily use just a handfull of controllers just add those. Foe instance 95% of the computers I work on have Intel MSD controllers, so I only add the Intel drivers and deal with the remaining 5% as I run into them.

Link to comment
Share on other sites

  • 7 months later...

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.

  • Create New...