Re-running DPInst.exe
Hi,
Currently we have deployed RIM's Desktop Manager v 4.2 SP1 in our enterprise. I scripted this with a custom action to run DPInst.exe in the USB Drivers folder in C:\Program Files\Common Files....Now the business is purchasing newer devices and I need to update the driver files.
I plan to overwrite the existing files with the newer driver files but my question is how to handle the DPinst legacy file that is on the machine. If someone replaces their Blackberry device, will the newer device pickup the new driver files via the existing DPInst.exe thats already on the machine? I have never tried to re-run DPInst before
Thanks for any and all input
"Don't worry Danny, if you miss this one....we Lose!"
Currently we have deployed RIM's Desktop Manager v 4.2 SP1 in our enterprise. I scripted this with a custom action to run DPInst.exe in the USB Drivers folder in C:\Program Files\Common Files....Now the business is purchasing newer devices and I need to update the driver files.
I plan to overwrite the existing files with the newer driver files but my question is how to handle the DPinst legacy file that is on the machine. If someone replaces their Blackberry device, will the newer device pickup the new driver files via the existing DPInst.exe thats already on the machine? I have never tried to re-run DPInst before
Thanks for any and all input
"Don't worry Danny, if you miss this one....we Lose!"
0 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
WayneB
15 years ago
Gidday,
You could run a DPinst uninstall unless you want to support the legacy hardware as well as the newer stuff. I usually create 2 CA's, one for install and one for uninstall of the hardware in the msi package.
You shouldn't have any trouble runnig DPInst.exe if you've got it in the .inf file folder and running it from there, as it just chugs through each .inf file and installs the relavent system files, as I understand it.
You could put the DPInst CA just after, or relying on a condition of the Launch Condition sequence, to uninstall the existing drivers, I guess.
Another thought would be to run a custom script as an Active Setup, but make sure the user profile has rights to the relevent folders the DPInst AS wants to write to.
Someone may have other thoughts on this.
Regards
Wayne
You could run a DPinst uninstall unless you want to support the legacy hardware as well as the newer stuff. I usually create 2 CA's, one for install and one for uninstall of the hardware in the msi package.
You shouldn't have any trouble runnig DPInst.exe if you've got it in the .inf file folder and running it from there, as it just chugs through each .inf file and installs the relavent system files, as I understand it.
You could put the DPInst CA just after, or relying on a condition of the Launch Condition sequence, to uninstall the existing drivers, I guess.
Another thought would be to run a custom script as an Active Setup, but make sure the user profile has rights to the relevent folders the DPInst AS wants to write to.
Someone may have other thoughts on this.
Regards
Wayne
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.