K2000 pushing out unsigned drivers
I've been playing around with the scripted installs and deployment of system drivers, and have happened upon some odd behavior.
When I manually install drivers on a target model, harvest those drivers, and then redeploy to test it out, the drivers end up appearing as unsigned in the Device Manager and won't function until I manually install them again.
We want out system deployments to be as hands-off as possible, so I'm hoping to avoid the post-installation task route, as HP doesn't seem to offer any means of silently installing their driver executables.
Has anyone a cure for what ails me? [:(]
When I manually install drivers on a target model, harvest those drivers, and then redeploy to test it out, the drivers end up appearing as unsigned in the Device Manager and won't function until I manually install them again.
We want out system deployments to be as hands-off as possible, so I'm hoping to avoid the post-installation task route, as HP doesn't seem to offer any means of silently installing their driver executables.
Has anyone a cure for what ails me? [:(]
0 Comments
[ + ] Show comments
Answers (7)
Please log in to answer
Posted by:
dyehardfan
13 years ago
Quite possibly, but it depends on what type of system drivers you are speaking of and what model HP computers you are referencing. Can you provide more specific information? Also, what Operating System are we dealing with in this situation as that can have an effect on the method to resolve your problems. HP's are notoriously rough driver installation and I have had to go the post-install route with several model HP Laptops, but it's really not that difficult. If one find's creating post-installation tasks too hands-on then they are in a world of hurt with this type of work.
Give us some follow-up info and I bet someone in here can get this figured out.
Give us some follow-up info and I bet someone in here can get this figured out.
ORIGINAL: mroloff
I've been playing around with the scripted installs and deployment of system drivers, and have happened upon some odd behavior.
When I manually install drivers on a target model, harvest those drivers, and then redeploy to test it out, the drivers end up appearing as unsigned in the Device Manager and won't function until I manually install them again.
We want out system deployments to be as hands-off as possible, so I'm hoping to avoid the post-installation task route, as HP doesn't seem to offer any means of silently installing their driver executables.
Has anyone a cure for what ails me? [:(]
Posted by:
mroloff
13 years ago
Hey, dyehardfan. Thanks for the quick reply.
The particular model that I'm currently working on is the Compaq 6910p. Win 7 Pro x64 is our flavor of the week, and some of the drivers in question are for the ATI Radeon X2300, Fingerprint Reader, and RICOH Host Controller. I'm holding off on going much further until I can get these working.
I probably wasn't clear with the post-install comment. My bad. It's not the process of creating post-install tasks that we're hoping to avoid, but the fact that we'd have to physically be at the system during install to click through menus and options. We'd prefer that all drivers successfully deploy from the driver share, but are willing to make post-installs if they can be deployed silently.
Our goal is to get as close to a seamless install as possible: PXE the system, pick a scripted install, walk away for an hour or two and come back to a fully loaded system that can be handed to the end-user. Getting the drivers to install properly is about the only obstacle to this so far. [&o]
The particular model that I'm currently working on is the Compaq 6910p. Win 7 Pro x64 is our flavor of the week, and some of the drivers in question are for the ATI Radeon X2300, Fingerprint Reader, and RICOH Host Controller. I'm holding off on going much further until I can get these working.
I probably wasn't clear with the post-install comment. My bad. It's not the process of creating post-install tasks that we're hoping to avoid, but the fact that we'd have to physically be at the system during install to click through menus and options. We'd prefer that all drivers successfully deploy from the driver share, but are willing to make post-installs if they can be deployed silently.
Our goal is to get as close to a seamless install as possible: PXE the system, pick a scripted install, walk away for an hour or two and come back to a fully loaded system that can be handed to the end-user. Getting the drivers to install properly is about the only obstacle to this so far. [&o]
Posted by:
cblake
13 years ago
HP's drivers generally support silent switches. Try adding those to your postinstalls and they'll be hands off. They offer their drivers in the form of .EXE-based files called SoftPaqs. They tend to be named something like ""SPxxxxx.exe". Here's the [usually] supported command syntax:
Using the SSM tool from HP, coupled with the K1000 scripting tool is a neat way to automate this as well.
- "SPxxxxx.exe is the SoftPaq to unpack
- "-pdf" is a runtime switch that overrides the build parameters
- "-f" is a runtime switch that overrides the default path set at build time
- "-s" instructs the package to unpack in silent mode, skipping the Welcome, License, and Directory screens
- "-e" instructs the package to extract only, that is, do not run the component installation program.
- -s -a -silent -reboot (Good for silent installs.)
Using the SSM tool from HP, coupled with the K1000 scripting tool is a neat way to automate this as well.
Posted by:
dyehardfan
13 years ago
If your shop runs a lot of HP machines you might want to look into at the very least the HP SoftPaq Download Manager: http://h20331.www2.hp.com/hpsub/cache/509658-0-0-225-121.html for easy access to the latest drivers.
The SSM that Chris referred to is pretty cool as well. I was looking into it before we decided to move away from HP's to Dells. Here's some good info on it:
http://h20331.www2.hp.com/Hpsub/downloads/system_software_mgr.pdf
http://h20331.www2.hp.com/hpsub/cache/284133-0-0-225-121.html
One word of advice, make sure you use /noreboot (or the equivalent) switches where applicable in post-installation tasks for Win7. Reboot during post-install tasks stops the process. If it's absolutely necessary to perform a reboot (such as join domain scripts or sp install) you can insert simple reg keys to kick off another script to handle followup tasks.
Chris, what exactly is the -pdf switch used for?
The SSM that Chris referred to is pretty cool as well. I was looking into it before we decided to move away from HP's to Dells. Here's some good info on it:
http://h20331.www2.hp.com/Hpsub/downloads/system_software_mgr.pdf
http://h20331.www2.hp.com/hpsub/cache/284133-0-0-225-121.html
One word of advice, make sure you use /noreboot (or the equivalent) switches where applicable in post-installation tasks for Win7. Reboot during post-install tasks stops the process. If it's absolutely necessary to perform a reboot (such as join domain scripts or sp install) you can insert simple reg keys to kick off another script to handle followup tasks.
Chris, what exactly is the -pdf switch used for?
ORIGINAL: cblake
HP's drivers generally support silent switches. Try adding those to your postinstalls and they'll be hands off. They offer their drivers in the form of .EXE-based files called SoftPaqs. They tend to be named something like ""SPxxxxx.exe". Here's the [usually] supported command syntax:
-  "SPxxxxx.exe is the SoftPaq to unpack
- "-pdf" is a runtime switch that overrides the build parameters
- "-f" is a runtime switch that overrides the default path set at build time
- "-s" instructs the package to unpack in silent mode, skipping the Welcome, License, and Directory screens
- "-e" instructs the package to extract only, that is, do not run the component installation program.
- -s -a -silent -reboot (Good for silent installs.)
Using the SSM tool from HP, coupled with the K1000 scripting tool is a neat way to automate this as well.
Posted by:
dyehardfan
13 years ago
Posted by:
mroloff
13 years ago
Posted by:
mroloff
13 years ago
Revisiting this due to the arrival of an oddity that I can't quite put my finger on.
I'm adding multiple drivers into a ZIP archive that has a batch in it's root which starts up the extracted executables with their silent switches. I've tested this out manually on the target system and everything works perfectly. So, I upload the archive as an application post install task, Windows runtime, and a command line set to call install.bat
Running through the scripted install, everything works fine until the post install task starts up. The -s switch on one of the drivers no longer works, but the rest of the batch works as intended. The Ricoh Media Driver is the problem child here.
The install.bat is as such...
I'm adding multiple drivers into a ZIP archive that has a batch in it's root which starts up the extracted executables with their silent switches. I've tested this out manually on the target system and everything works perfectly. So, I upload the archive as an application post install task, Windows runtime, and a command line set to call install.bat
Running through the scripted install, everything works fine until the post install task starts up. The -s switch on one of the drivers no longer works, but the rest of the batch works as intended. The Ricoh Media Driver is the problem child here.
The install.bat is as such...
@echo off
echo Installing Ricoh Media Driver...
.\"Ricoh Media Driver"\setup.exe -s
echo Installing ATI Radeon X2300...
.\"ATI Radeon X2300"\setup.exe -INSTALL
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.