driver signing behavior

[meister]

Anyone know why with my sysprep.inf file having driversigning=ignore (I don't have access to it right now, the syntax here might be wrong but i know it's right in the file), why on earth would I still be getting prompted for "continue anyway" or "stop installation" when my runonceex is installing some programs after mini-setup?

Thank you.

[zorphnog]

I've had this problem too. As far as I know, there is no workaround for the issue other than finding a logo tested driver. I found a M$ article about how replacement of system protected files will cause the driver signing policy to be automatically elevated - Driver Signing Policy Is Automatically Elevated for Unsigned Drivers

[VCC]

Use Bashrat the Sneaky's Driverpacks. He has a workaround implemented in there.

Drove me NUTS for awhile until he implemented a workaround, I rest easy now, thanks to him.

- Rereading your topic: Are you talking about the Hardware Wizard prompting for a driver? There is a Microsoft fix for that, there was a topic not long ago in here with a couple of links to fixes associated with the HardWare Wizard prompting for drivers when using an image. Though the driver was available, it does not install it automatically, typically Intel Chipset.

Edited October 25, 2007 by VCC

[meister]

Well not the hardware wizard per se, I'm not in windows adding a driver when it happens. I sysprep my image and shutdown. When I bring it back up my runonceex.cmd runs a bunch of installations, one of which is it tests for the model PC and installs the appropriate driver pack. I have 6 different models in my environment and a packaged set of drivers for each. Apparently one of Dell's drivers (audio) have not been signed so I get this pop up and you have to hit continue anyway. But it just manifested itself all of a sudden - which makes me think the private hash somehow got tampered.

When it was shutdown I did boot into BartPE and edit a text file in the root a C:\, and I know if you run Regedit from within BartPE the default behavior is Warn but allow...maybe it somehow caused the private hash mixmatch...???

ANd I'm probably misunderstanding how WatchDriverSigningPolicy.exe works, but I'm running that in the initial stage of the driver installation, still no luck.