Windows Enterprise Desktop

Sep 10 2011   2:40PM GMT

Interesting Windows 7 Driver Signing Issue

Ed Tittel Ed Tittel Profile: Ed Tittel

Apexwm is an active but anonymous IT professional who posts all over UK forums, and who also blogs prolifically for ZDNet in the UK. He recently posted a fascinating item entitled “Windows 7 driver signing conundrum” wherein he recounts a vexacious “chicken-and-egg” problem. The issue has to do with trying to slipstream a driver for a particular device into a Windows 7 image — in this case, an integrated wireless network adapter from RALink Technology — when the manufacturer only makes an Installshield program available to install the driver, but which must be installed manually after Windows itself is installed.

In attempting to automate the install, the author used a test machine to get the list of necessary files from Driver Details in Device Manager, and also grabbed the related oem*.inf file from the C:\Windows\inf folder to complete the collection of items to attempt an automated and unattended install. Imagine his frustration when this effort produces the following error message:

Windows cannot verify the digital signatures for the drivers required by this device. Error Code 52.

The drivers are in fact signed, and the problem is apparently well-documented all over the Internet for drivers of all kinds. But alas, no easy fix is available, without turning to 3rd party software products to remedy this known Windows defect. I’m sure apexwm isn’t the only Windows admin who would voice his sentiments on this approach “No thanks. I’m not about to start installing a bunch of unknown 3rd party products to try and help with a Windows problem.”

If I were in those shoes, however, I would try to take advantage of Windows’ ability to run post-install scripts after the initial installation process completes (which is how additional common applications such as Office, 7-Zip, FileZilla, and so forth, often occur at the tail end of automated installation processes). It seems to me that if the driver uses an InstallShield .exe file, there should be some way to script or automate its installation as a post-install task.

I do get apexwm’s complaint that Linux/Unix does a much better job of integrating drivers into its kernel directly, and that compilation into the kernel is an option for those few odd drivers that aren’t already included under this umbrella. But I’m a member of the “where there’s a will, there’s also a way” club of Windows-heads and suggest that he needn’t have given up in defeat.

2  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Apexwm
    Hi Ed and thanks for the reference to my blog article. I do agree with you that post-installation tasks could be set up to handle this. In this case, we ended up looking at using a post-installation task to handle this issue. But, I've found mixed results going with this method; some items install fine with post-installation tasks, and others do not and must be included in the regular Windows unattended installation steps. In the end the installations end up being a little cobbled because we are using scripts to perform tasks that should work out of the box. And, scripting items for post-installation is always a challenge to figure out what the silent switches are so that no technician intervention is needed. We've found a few that are undocumented. And, we've also found that when trying to install a number of these post-installation items at once, that problems come up where they completely fail because they desire a reboot from something that was installed previously since the last reboot (sometimes mixing around the order seems to help). Again, GNU/Linux excels over Windows in regards to all of this, due to the kernel design of drivers and modules being compiled directly or as modules to the kernel itself, along with the superior packaging system that most distributions have now (I like Red Hat's RPM system).
    0 pointsBadges:
    report
  • Ed Tittel
    Dear ApexWm: Thanks for a great follow-up, and some terrific comments and suggestions. Drivers are particularly sticky and do pose interesting problems. You might want to talk to the people at Prowess Software (I'd suggest starting with Aaron Suzuki, the CEO of the company who seems pretty technically astute to me). They've come up with some interesting way to merge drivers with Windows images that you should find particuarly compelling, given the circumstances you recount in your posting here. Best wishes, and happy holidays to you and your family. --Ed--
    4,465 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: