Sometimes on the first boot of Windows, the New Hardware Wizard will appear and wait for me to click next before continuing to install drivers automatically.

It appears to be related to driver signing. I tried setting driver signing to ignore, but it seemed to have no effect.

The next issue is related to the one above.

Certain machines do not have PS/2 ports. Often USB keyboards and mice do not work on the first boot after imaging. I can't click next on the new hardware wizard so it just hangs the entire process at that point.

A solution I'm considering is using sysprep with the pnp option to re-detect all the hardware on the first boot.

Any advice would be appreciated.

I'd like to provide my version of this process here. This has not been rolled out into production yet, so please point out any errors or potential issues that we may encounter. I'm still working on fully testing this process.

I chose to build my base image in a virtual machine. We are running XP SP3.

After downloading all the XP driver packs and a few third party ones, I extracted them all into a single D folder which I placed on a network share.

Acronis Universal Restore can automatically search a network location for drivers. I found that UR is very effective when given such a large library of drivers to pull from. As stated earlier in this thread, UR can't access cab compressed drivers.

By using the network share, and uncompressed drivers, I found that Phyxx's method of manually referencing a Vendor and Device ID table was completely unnecessary. UR found all the drivers it needed automatically.

This eliminated the problem of machines that BSOD on first boot after being imaged. UR replaces the HAL, Mass Storage, and other files that are critical for boot.

Unfortunately, this only solves half the problem. AR is very good at getting systems to boot successfully, but after that, there is still a large number of drivers missing.

I placed a copy of the D folder on the C:\ drive of my image. I used Phyxx's InfLocator tool to scan the folder tree and create the appropriate registry key.

The combination of these two things allows me to create nearly universal images.  AR gets the system booting, and Windows handles the remaining drivers thanks to the driver packs.

You gave me an easiest method.
No need to read 100 topics.
No knownledge.

--------------------

It's good if you program can move files to  "Save Folder Driver Map" too.

OR you could use the SAD feature of DriverPacks BASE to install them and then look to see what they are

I just want to thank Phyxx for their work in creating this thread and associated applications. This is a godsend for me as I've looked to create a way to dynamically provide the required drivers for Acronis True Image w/ Universal Restore however I got nowhere. I had never thought of doing it their way.

To wmor, to my knowledge, there's no way for you to slipstream it with the Boot/Rescue media. Universal Restore's aim is to provide the ability to restore an image to a PC in which most/all components are the same on the PC backed up, excluding the motherboard. AFAIK, the DP Mass Storage drivers will be the only drivers useful for use with ATI w/ UR.

wmor, you can use apps such as SIW (free for personal use) to determine what devices are in your system. Other similar applications also exist.

Also, what program do you use to find out what the unknown device's are in the device manager?

Thanks again.

Acronis UR (I believe) does not scan for drivers outside of %windir%/inf,

If drivers are already located in '%windir%/inf', that would suggest they have already been integrated into the image. It's been a while since I've used UR, but from memory, you are presented the option of optionally selecting a path to scan for additional mass storage drivers.

Regards,
Galapo.

i still feel detards work will be of assistance to what you are trying to do.

We are always willing to listen. It is never a waste of time to share ideas. I just failed to see the logic.

PS much of what you stated in your first post is well known and documented here already.
I suppose it doesn't hurt to review the basics... but it makes for a lengthy post. especially without code tags

PSS Cabbed drivers are natively supported by windows it should work (obviously other methods of compression will fail)
(check your windows\I386 folder and tell me how many files end in .??_ (the ones that are cabbed) )

Also if you had familiarized yourself a little more you woluld have realized there is yet an easier method to use.
That post is in the forum i am going to move this post to (yes you put it in the wrong place also)
please see skinlayers and DeTards posts and see what others are doing with sysprep.

PS we are not noobs...

You misunderstand my intentions. I had two specific goals with the information above: use the driverpacks as a "driver database" while using Acronis UR, and to easily update many systems with missing drivers without modifying or copying the drives across (although for convenience I have included the extracted drivers in base images).

Acronis UR (I believe) does not scan for drivers outside of %windir%/inf, and it certainly doesn't have the ability to extract drivers from compressed archives. By dumping the device and vendor id's you can easily match a fairly obscure string like PCI\VEN_8086\DEV_2A04 to a specific driver folder. If there is some way to do a similar match using KTD then I apoligise for wasting eveyones time...

I also find myself having to hunt down drivers on random PC's. By modifying the DevicePath registry setting (yes, I realise it is a huge string, but the registry type REG_EXPAND_SZ is for all intents and purposes unlimited in size, it is a temporary modification, and to be honest I don't have time to manualy modify the folder structure every time an update comes out) I can stick in a USB key, modify the registry, scan for hardware changes in device manager, reset the registry back to %windir%/inf and have most of the essential dirvers installed without doing any major modifations the host system or copying acorss large amounts of data (important when you are working on an old system with USB1). It is also convenient to have the drivers in an extracted form in a base image so when windows boots for the first time it can pull out what divers it's needs, after which you simply reset the registry and delete the drivers. Again if there is an easy way to do this using KTD then please disregard this post.

so i don't belive the extra work is required...
SysPrep is not my favorite method so i may have missed something...

and when I get back to this I see Jeff mentioned method 1.

Well, here is something for you.
C:\DriverPack\D\C\A\1;C:\DriverPack\D\C\A\2; is TWO folders weighing in at 44 characters for two folders..
I bet that with your method you still have a problem with path longer than 4096 characters, so why should I not tell you what I did a mont or so back..
Here goes.
------------
How can you have a

SUPER SHORT PATH FOR METHOD 1
_____________________________

1: Benefits;
a) You can stay well under 4096 path lenght with all main packs and several third party included.
b) Method 1 can be used to UPGRADE CDROMs.
c) A Disc built with Method 1 has a searchable driver repository. (the Soem$ folder )
d) The driver repository and path built in WINNT.SIF can be used in an ACRONIS image.
in your example, everything in C:\D\... so your path would look like
%SystemRoot%\inf;C:\D\C\A1;C:\D\C\A2;etcetera etcetera
which you can easily accomplish by a little edit and then search replace on ;D\ to ;C:\D\
(which, incidentally, still sees me under 3400)

2: Disadvantage
a) It will take you a couple hours to do this.
b) You cannot do KTD (but, surprisingly, KTD is not needed because the drivers were copied and path is referenced anyhow.)

- HOW -

Copy the DriverPacks and DriverPacks BASE to a project folder.
I extracted DriverPacks BASE 805 in the "special" project folder called SUPERshort.
In there, I created two subs for the SHORT3rdparty and SHORTmain
Then I extracted the DriverPacks and 3rd party in there.
--------

WLAN has well over two hundred folders, and has NO INI.
Copy the foldername, and make a new folder where you add SHORT (or S) after the version number.
make a D folder in there, and then make seventeen folders in the D folder.
wa, wb, wc, wd, we, etcetera.

You can perhaps use DUPEFINDER to see which folders contain duplicate filenames...
Move the files from the official WLAN into one of the 17, and take care.. You do not want to overwrite a single file.
When you are done, your fingers hurt, but because you moved files from 200 folders into 17 folders you have a MUCH shorter path.

Copy the DP_WLAN_xxxSHORT foldername to clipboard and 7zip the D folder in that supershort folder, giving it the name from clipboard.
--------

LAN is another one with a high number of folders.
This one has an INI.
Copy the foldername, and make a new folder where you add SHORT (or S) after the version number.
Make a D folder in there, then make an L folder, and then make eight folders in the D folder.
1, 2, 3, 4 etcetera

Move the NV3 folder and INI to the "short" pack. (because it gets referenced in INI)
Then move content of the other hundred thirty odd folders to one of the nine folders in there, WITHOUT OVERWRITING a single file.

let zip do its magic and get a coffee.
--------

Sound B has over a hundred folders, and only six are referenced in the INI.
You may think I will suggest you move the referenced folders and INI over to the short pack and then move files.
Well, it sure looks almost every folder has duplicate filenames in it.. (I see 178 dupes.)
I can tell you that getting this to 70 folders is NO fun at all..

I know D\S\CR8 is longer than D\SCR8
So, I changed the INI

[DriverPack]
platform    = "wnt5_x86-32"
name        = "Sound B"
; version 804
rootDir        = "D"
( instead of "D\S" )

And wrote an S into the folder reference in INI
[CR8] became [SCR8]
I then used bulkrename, added an S before each foldername, and was going to move the lot to the shortpack.
hey.. it has 117 folders, so I would get 117 characters less..

But? NOTHING says you CANNOT move files.
So, I started by moving the edited INI and the six referenced folders to short, and then combined some folders..
When I was done, I had 70 folders left.
47 times (example) D\S12; was approx another 300 characters less.

----------

I knew I was under 4096 by now.. (by doing WLAN and LAN I had already shortened path a great deal)

I looked a third party, and saw path hogs.
I really mean path hogs.
I got the third party packs I use from over 2000 chars to a LOT less.

My total path with all the mains and the four third party I use is under 2300..

I applied the rootDir = "D" INI edit I used for sound B in LAN, Graphics A and B.

For the third party files the path looks like
D\3MoA;D\3MoB;D\3MoC; (monitors combined to less than five folders)
D\3MA;D\3MB;D\3MC; (modems combined into 31 short folders. From around 80 nested.)
D\3xA;D\3xAO; (Misc was combined into these two folders. From around 36 nested.)

hmmm.. chipsets is another special..
Chipsets will probably not have triplicated folders for intel in a next release.
(the content in those three intel folders is exactly same folks.)
If you are doing this for XP, you can pretty much put everything what says XP in the intel folder..
If you want to play it safe, keep the triplicated intel, and copy the rest to all three, but don't put folders what say 2k3 (for server) to an XP folder. If it says server, it goes to server.. some Nvidia and some Via have different catalog files for XP/2000/server.. and that's it.

"============================="
"Attention folks, heed this warning."
"You cannot do this to mass storage."
"============================="

Mass storage uses almost thousand characters in path, but you should not touch that.
It used to add over 1500..:)
There was a reason behind the change of folder structures we started months ago.

well it seems to me you burned a lot of time re-inventing the wheel.
if you were more familiar with DriverPacks you would realize all this functionality is already built into the base program.

We call it KTD (Keep The Driver) it has been a feature for years
and is a Heck of a lot easier than to even think about useing all that garbage you posted.
And does the exact same thing...

So i have to ask myself "why would any one want to do it your way?" {confused}

now obviously mass storage requires a little work to get into sysprep, but the rest of teh packs work fine.

Also if you had familiarized yourself a little more you woluld have realized there is yet an easier method to use.
That post is in the forum i am going to move this post to (yes you put it in the wrong place also)
please see skinlayers and DeTards posts and see what others are doing with sysprep.

PS we are not noobs...

Most people steer away from this method because of the 1.5 gig the packs burn on the local HDD when you do it this way.
If you insist on KTD then i recomend that you use method 1 with KTD and QSC=on
this will yield a folder in the 500 meg range. (a 1 Gig Savings)
windows can use cabbed drivers without extracting them so this saves space and is accessable at the same time.
The cabbing process can take a long time the first time
on subsequent runs QSC will have a copy of the cabbed files ready to copy and save a lot of time

the finisher will not only populate the registry keys to find the drivers
but it also creates cache files of the infs for fast searching by windows.
 

have a nice day.