XP video driver installation, unattended

XOR != OR

[H]F Junkie
Joined
Jun 17, 2003
Messages
11,547
I am attempting to automate the installation of a video driver, but it has come to my attention that windows won't let a video driver install if it's not done on the local session.

Has anybody come up against this, and is there a way to disable this behavior?
 
Is this in a corporate environment or home? If your joined to a domain you could push the install through a GPO upon start up.
 
Is this in a corporate environment or home? If your joined to a domain you could push the install through a GPO upon start up.
That's actually why I ask; I am trying exactly that. The problem is the startup scripts run in a different session than the local screen, and thus I am unable to install the video driver.
 
The more I think about it, you might need to right a startup script when the/a user signs into the local, which runs the install package. To create the unattended settings you could always start the setup.exe with the /r switch choose your settings and copy the *.iss file over to the directory where the driver installer is.

Then of course you could run into the probelm where the current user doesn't have admin/power user credentials to install.
 
Hmm, your using a .msi file, right?
No actually. I'm writing an unattended install for ultravnc 1.0.6.4. And it's a fucked up unattended install, let me tell you. However, I have a script which installs everything but the video driver. I tried putting it in a start up script, but those run in the back ground and thus, the driver won't install. Now if I run those visible, it works. However, the purpose of this exercise is to make it as seemless as possible for my end users.

Giving them administrative access to their local workstations isn't an option, unfortunately.
 
any way to do a runas /user:administrator install.msi via a batch file? that way it will be running as an authenticated user and not a system account?
 
any way to do a runas /user:administrator install.msi via a batch file? that way it will be running as an authenticated user and not a system account?
Not likely. I'd have to include at least a power user's username/password in a batch file, and because it has to be session 0, it would be visible to the end user. No good.
 
If you're doing an unattended install, you don't need to run the setup of any driver.

Create a folder structure like this:
C:\Drivers
C:\Drivers\Video
C:\Drivers\Audio
C:\Drivers\Chipset
C:\Drivers\Network
<etc, etc>

Now copy the drivers to the apropriate directory, making sure the INF file is in the root. Sometimes you have to pick through the directory to find the right one. I use this method:

With the device not installed, open device manager. Right click on the device and update the driver. Now browse to the driver files. The directory you can enter here is the directory you need to copy to C:\Drivers\<hardware>.

Once you have your drivers directory populated, you need to point windows at it. Open your unattend.txt and find/make an [Unattended] section. Add the following:

Code:
[Unattended]
OemPnPDriversPath = C:\Drivers\Vide;C:\Drivers\Audio;C:\Drivers\Chipset;C:\Drivers\Network

This will tell windows that, when it's installing hardware during setup, look in these directories for additional drivers to install. This way -- no script is required to run setup, the machine just builds itself with the hardware installed.

This nice part about doing it this way: if you want one image for all platforms you can just change what drivers get copied to C:\Drivers and it will build with that hardware.

I used to have a very elaborate script that asked what model of machine it was going to build. It would then extract a zip file from the network to C:\Drivers. It would do quite a bit more, but when it finished running through setup, regardless of the model, the hardware was always installed. It worked very, very well.



[edit]
After re-reading, it sounds like you're installing a driver on a machine that has already been built? If thats the case, you're going to need to use a GPO to run the setup. Most video drivers come in an MSI wrapped in an EXE. Start the EXE and find where it extracted the MSI to. Copy this location to new location and close your install. Now double click on the MSI and you should start the install. If that works, then this is what you want to push via GPO.

Or -- you could do a command line if the user had enough privledges:

msiexe.exe /i <path to msi> -qb1
 
After re-reading, it sounds like you're installing a driver on a machine that has already been built? If thats the case, you're going to need to use a GPO to run the setup. Most video drivers come in an MSI wrapped in an EXE. Start the EXE and find where it extracted the MSI to. Copy this location to new location and close your install. Now double click on the MSI and you should start the install. If that works, then this is what you want to push via GPO.
Which doesn't work with a video driver install, I'm led to believe. From what I've been told, video drivers can not be installed in any session except the local one. Running the setup in a GPO would run it hidden, effectively in a different session. The video driver fails when I do this. what I'd like to do is find a way to disable this windows behavior, but i"m not sure I'm going to get that lucky.

And I can't bring myself to give my users anything other than limited user rights. I'd have a network full of crap within a week if I did that.
 
I've never heard that video drivers need to be installed in the console sesison. I've RDPed into servers before and updated video drivers, so my guess is that it actually depends on the driver.

If you were to extract the driver from the installation packages and wrap your own installer around it... you might be able to get it to work.

Curious: why do you need to update the video drivers on so many machines? Seems to me that you've got them in the field, so they must be working. Is there a feature missing that you need in this new version?
 
Curious: why do you need to update the video drivers on so many machines? Seems to me that you've got them in the field, so they must be working. Is there a feature missing that you need in this new version?
Originally, it started off as me wanting to install ultravnc. The video driver needs to be updated with the installation. However, given as much trouble as I'm having with this I'm leaning towards running without it.

I'm still interested in learning how to get this working though.
 
**Did you look at FASTPUSH? It's supposed to be the tool used to silently install the product.
***Shame on the developers for not creating a proper installer for UltraVNC.

If your script installs the driver unattended when in a desktop session, try enabling visible startup scripts.

Open up your computer policy and then under Computer Configuration\Administrative Templates\System\Logon, enable "Run startup scripts visible". Reboot your test machine using "GPUPDATE /sync". See if that helps.
 
Last edited:
**Did you look at FASTPUSH? It's supposed to be the tool used to silently install the product.
***Shame on the developers for not creating a proper installer for UltraVNC.

If your script installs the driver unattended when in a desktop session, try enabling visible startup scripts.

Open up your computer policy and then under Computer Configuration\Administrative Templates\System\Logon, enable "Run startup scripts visible". Reboot your test machine using "GPUPDATE /sync". See if that helps.
It does, but...the situation is a bit more complex than I've gone in to here. I'm not actually using Startup scripts to install ultravnc, I'm using WPKG. And the package mostly works, with the exception of the video driver install.

Honestly, at this point I'm inclined to just say fuck it and run without the video driver. If it's this big of a pain in the arse, I'd hate to see what it's like to upgrade the thing.
 
Back
Top