Software Deployment

Your right, autoit is a very dirty (and possible unreliable) solution. I managed to overcome this issue in the middle of last year when silently installing the IBM iSeries client.

When you switch off the driver signing warning using the GUI you will see that the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PrivateHash value changes and changes back when you re-enable the warning.

If your organisation has used a base image build then a quick audit will confirm that you have a very small number of PrivateHash values (& therefore base builds). Now all you need to do is switch off driver signing on each build & collect your PrivateHash pairs. Now write an install to check for the "on" value, change the value to the relevant "off" value install the drivers & change it back - et voila!

If you don't have a limited number of PrivateHash values then I'm afraid your screwed unless someone can come up with the algorithm that generates these pairs!

Steve Woolrich

steve AT micramaze DOT com-NOSPAM

I regret to inform you that what you are asking is not possible.
We are a Locked Down W2K AD environment here. And made a number of attempts at this very thing.

The problem is many fold dependent on if PNP is involved or not.
But basically even if you turn off the security points generally machine policy sets it back on next reboot.
You have to reboot for the changes to be effective.

The only answer is "get the drivers signed", sorry.

Regards,

For the curious posterity:

I ended up scripting a work-around with AutoIt. Not very pretty, but it does the trick... More info and a link to download my example at http://www.ewall.org/displayarticle95.html

Maybe I don't understand what you are asking for but then again, maybe I do and this is your answer:

Under Properties of "My Computer"
-Go to "Hardware" tab
-Click the "Driver Signing" button under the "Device Manger" section
-Set it to "Ignore - Install the software anyway and don't ask for approval"
-Check the "Make this action the system default" under the "Administrator options" section

Good tip, Steve! I'm passing it on to own Image Build Master, as he's lately been frustrated with some unsigned driver warnings during the automated build process, and this might work well for that situation. I haven't had any packages with this problem lately or I'd try it myself...

hi ewall.
i tried downloading ur killwindowslogowarning.exe but the link is invalid,
can u plz send me the s/w to my id : mahikool@yahoo.co.in ?

Alternative solution:
I had a similar problem recently but I approached it differently. The initial reason for getting such a warning is that something went wrong when verifying the digital signature provided with the setup software. The simple reason for this is that the signature file is missing. While creating silent driver installation, you should attach to the xxxx.inf file folder, a parallel xxxx.cat file holding the signature.
If this does not help, this could mean that the validated content of the signed files differs from the original content. To me this happened because I modified the xxxx.inf file a little bit. When making sure I was using the original file, signature verification succeeded and this stopped this "windows logo testing" error from popping up

Thanks...

As I explained in the link in the first post, setting this via the GUI or via GPO should fix the problem (according to all descriptions of what that setting does), but it doesn't always work. This is apparently a "known issue" that Micro$oft hasn't really paid any attention to, as plenty of people in other places have seen the same unpredictable behavior. My experience plus hearsay seem to suggest that this setting works on a stand-alone home computer, but not in a 2000/2003 domain; and/or with legacy SETUP.EXE and .INF installs but not Windows Installer-based distributions... but who knows?

Here's to hoping M$ will include this fix in XP Service Pack 2!

One reason why this may appear to be a solution on a stand-alone workstation, but not on a domain would be if your network security policy is overriding your change. This is assuming you are operating in an Active Directory environment.

Nope... This is with the domain-wide Group Policy having the correct setting for "Devices: Unsigned driver installation behavior." (I even verified that the GPO was applied to the local machine using the MMC plug-in "Resultant Set of Policies".) I've seen it at several companies myself, and heard about it at many more.

Again, this was all described with pretty pictures and everything at the link in my first post: http://www.ewall.org/displayarticle93.html

Thanks for trying, all--

Sorry about that, Mahesh... I just fixed the download links on my website... and emailed you the file as well. Hope it helps!