Br4tt3

Search the forum for this.... U dont want the .exe file to run the installation of a device normally. This is because the Win32 PnP functionality will only be able to scan .inf and .sys and map them to a device. So what u need to do is to extract the .exe installer and u will get the .sys & .inf eventually, once u have them, u can reference them from the $OEM$\... structure and list them in ur .sif. The missing link in evolution is the NIC drivers. U also need to place them in the root of i386 folder as well as in the $OEM$ ( just like Rouge is stating.. ) structure if they are míssing... good luck to u...

hmm... dunno, but just for pure joy, I just reinstalled a box using RIS, when the install passed the reboot from the 16-bit phase, i shutdown my RIS server which was servicing the machine, and the installation still finished correctly.... however, that machine was set to join the domain.

Dont u have a local copy when running the normal install? deafult for a flat risetup install, the .sif file is copyied down to the local machine. The Win32 setup only reads inital info from .sif during the blue screens, then the .sif is located in the and named c:\windows\system32\$winnt$.inf. (removes the password and stuff... or atleast, so they are on mine RIS installations - Win2003 RIS & WinXP Clients) to answer ur question, I am convienced u must be utilizing some kind of intermediate boot OS. Once u have copied the .sif down locally, u will have to kick the installation from within that boot OS (WinPE or BartPE) or I dont know how u would link the install to a "new" answer file..

You can either download setup ur own cert server infrastructure (which is a mess..) and sign the drivers internally and have the machines trust that CA or... install a kernel debugger and have dpinst.exe install for you (which is alot easier, IMO)

Some things to check for: 1. The actual driver files, .inf, .sys, .cat are most certainly always available when extracting the driver(s) 2. The application that supports the device.. .exe, .dll, .ini and so on are often bundled when downloading a new driver. Normally u just download a driver and have it extracted to a temp dir from which can scoop the drivers later on. Normally acchieved using a switch on the .exe (mydriver.exe -x c:\my_temp_dir) something like that... or having winzip or winrar installed would give u the opportunity to extract them as well. Or just run the .exe file normally, and the files will be present within c:\windows\temp or ur profile temp dir.

Yes it can... i've installed it in a unattendly fashio hundreds of times... download the .exe or .msi from nvidia.com and then extract the .exe or .msi to a temp dir. Find the .inf and .cat and place them in ur $OEM$ folder structure and list them in ur unattend file. So much for machines being reinstalled... on already installed machines, I use the dpinst.exe tools from MS that is free of charge which can update existing installations..

Cheers m8...

1. Intergrate the driver prior to the application installation point.. 2. If the application does not support unattended mode or quiet switches, I would recommend that u "snap" the appliction using a .msi build application. That is not always a good thing, but for home usage, it's all fine.. in this way u will the whole application installed, or placed a the drive, however, u can use the msiexec switches to have it run quietly... with no user interface at all..

Dunno for sure how ur batch looks but here are some features/trix; 1. Batch files can be launched using Start /Wait and accepts /minimize to not hide it but to run it minimized... 2. If the driver is installed from an .msi file u can supply switches to the msiexec.exe that will run in quiet mode 3. If it is an .exe file... then check if the .exe accepts the correct quiet, unattend switches... 4. Batching sux..... vbscript would solve it directly for u... Here is an exemple for u.... Set WshShell = WScript.CreateObject("WScript.Shell") Function SilentExecApp(pstrCommand) WshShell.Run pstrCommand, 0, True End Function When u wanna use it from within the .vbs file u just write something like: SilentExecApp("msiexe /i c:\App\MyMSIApp.msi /quiet") and it's all good.... Best Regards Tha Sausage Eater... Or the easier way out as stated by the previous forum member.. intergrate the driver into ur $OEM$ prior to the installation....

love those slow days....

From what i can see the $OEM$ folder is at correct level (same as i386) and u have right structure as well... on thing NOT listed in ur entry is the OEMPreinstall = Yes of the whatever.sif file. If u dont supply the OEMPreinstall = Yes value, then Windows setup will not search for the $OEM$ structure.... hope it solves ur problems... oh... and dont have the pending "\" in front of the Drivers folder..... i run Drv\Nic\MyNic;\Drv\Nic\MyNic2; and so on... not sure if that will screw things up for u. Best Regards Tha Sausage Eater...

Is that .exe free to use then? All I can find on google is something about the embedded XP which I dont have... or is included with the SA agreement aswell? Tha Sausage Eater...

In my case, I boot from an (WinPe2005) .iso file placed on the local c: into RAM of the machine... the c: drive is formated with NTFS. Easier if u have access to boot of a PXE server while playing with it...

Summary: The only way to get this working is to: 1. Install a machine using unattend.txt for example 2. Run sysprep.inf 3. Capture to .wim format from a WinPE 4. Apply .wim image to local machine from WinPE 5. From within WinPE, run a script that will mount the c:\windows\system32\config\software file to a TempHive using reg load. 6. Write the new paths to the key (for the external added paths to be included) 7. Unmount the TempHive 8. Exit WinPE and mini setup will process and include the new paths.... Cu...

Oki, if one reads the deploy.chm file: for OEMPnPDriversPath entry "If there is already a path in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\ CurrentVersion\DevicePath, Sysprep does not append the path to the registry key a second time." I will never learn the term: RTFM

Spoke with MS about it... they encourage you to actually read the registry key (rather than to have WMI query the same key) and then base your decision from the return. So far, tried it on 3 diffrent HAL's where as the decision always seem to work based on the WinPE key. For example, using Mats & Jazkal's suggestion: (assuming devcon.exe is on ur WinPE image) or u could do a normal regread.. Option Explicit Dim objFSO, objFile, strHALVal, strLine, WshShell, Command Set WshShell = WScript.CreateObject("WScript.Shell") 'Syntax for the Devcon.exe command from .vbs - "Devcon hwids find " & """@root\*hal*""" Command = "cmd /c Devcon hwids find " & """@root\*hal*""" & " > c:\HAL.txt" WshShell.Run Command, 0, True Set objFSO = CreateObject("Scripting.FileSystemObject") Set objFile = objFSO.OpenTextFile("c:\HAL.txt", 1) Do WHile Not objFile.AtEndOfStream strLine = objFile.ReadLine() If Left( trim (strLine), 5) = "Name:" Then strHALVal = Mid(strLine, 10) End If Loop

Hi folks... I run a unattended install where the unatten.txt contains references to the OEMPnPDriversPath entry. For example; OEMPnPDriversPath = "Drv\Vid\Video1;Drv\Vid\Video2" When checking the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion - DevicePath entry, it contains references to the above mentioned OEM drivers supplied. Once the unattended installation reaches the end of the install sequence, it will shutdown using sysprep.exe. The machine is then booted up on capture image from RIS, and saves the machine state to a .wim format on a UNC path from WinPE. So far so good.. When I want to deploy the .wim image, I boot into WinPE, apply the image to the machine, manually or by a .hta interface edit the sysprep.inf file to reference some new cool drivers, for example Drv\Vid\Video3 from the OEMPnPDriversPath entry. I then copy over the drivers locally so the entry and files/dirs correspond. Once the machine has been installed, when checking the DevicePath entry in the registry it does NOT hold a reference to the Drv\Vid\Video3 driver added at the sysprep.inf "stage". My question: 1. Is this correct? When adding entries in the OEMPnPDriversPath of the sysprep.inf file that was NOT a part of the unattend.txt OEMPnPDriversPath entry, should those not be visible from the DevicePath entry once the machine has been deployed???? If YES (they should), where am I going wrong? Also, in my sysprep.inf file, I am using the UpdateInstalledDrivers = Yes to force a PnP enum. However, I am not running the -pnp switch when using sysprep.exe. Best Regards Tha Sausage Eater...

hmm... so, the 256 RAM in the machine, the graphics memory is shared with the normal memory --> not 256 RAM dedicated to the RAM drive. Solved.

Hi guys! Oki, need some troubbleshooting tips and trix. I've got a WinPE2005 (Win2003 SP1) based .iso file which I use for booting into RAM. When booting client(s) with 256 MB of RAM and using this .iso file, almost all models work, except a Dell GX260 model... on this model, as soon as PE has been fully loaded and the terrible background (mountain) is seen the machine reboots and keeps on rebooting from the .iso on the hard drive.... If I place the .iso on a RIS box and PXE boot the client from the same .iso (just placed it on a RIS server) everything is working smoothly The only thing that actually looks diffrent between the diffrent models is that PE is having problems loading a VGA driver for the 260's and not the other machines, any thoughts on how to move along? Summary: works on like 10 other models but not when booting the .iso from the harddrive on a GX 260 while the same machine works nicely when using the same .iso from a RIS server. Best Regards Tha Sausage Eater

Lo... Works great, thanks alot Mats!

Try moving the command & import from cmdlines.txt to GuiRunOnce section if possible.... Best Regards Tha Sausage Eater...

WDS GUI question! Using the Boot.wim file from the Vista CTP (February) release, one can place it within WDS as a valid boot image. Once u boot up, u will eventually be prompted for proceeding (Next) and then to authenticate. After this step, WDS will present u with a GUI that allows u to choose from the existing installation images placed on servicing WDS box. My question: Has anyone figured out which file that actually holds this GUI? I really wanna edit it if possible so that I can move my previous .osc functionality into this part of the WDS GUI. Best Regards Tha Sausage Eater

Sounds like the drive onto which you are installing is not activated through diskpart... that way, even if the installation has been performed once (files copied to the drive) the installation will kick back onto the PE CD again as their is no other valid boot devices! Have u run a diskpart script from within your PE installation? Does it include a "active" command aswell? Check out the diskpart /s <scriptfile/textfile> command - to fix ur drive prior to the installation of the Win32 setup. There is loads of info in the winpe.chm on ur PE CD media. Best Regards Tha Sausage Eater..

I will definitly look into it.... would be nice to pick the HAL externally to the setup. MS and their SMS OSD picks it from a database (I think), and they just run a ADO connection to that DB to fetch the correct HAL from an audit or something. But that is cheating! Best Regards Tha Sausage Eater...

Hi folks.. So, here it is: I want to be able to run a query against machine(s) when running in WinPE mode to obtain the correct HAL to use when I later on the process have to pick an image to apply. I written a WMI query which succesfully works in a full Windows XP environment, which features the full WMI repository. However, running the same script from within WinPE mode, it just returns jack ****. And Yes, I have enabled / added WMI to my WinPE image as I can run wbemtest and so on... So, if WMI doesnt work correctly for picking the HAL, then maby u guys know of some CLI tool that will do the trick for me? or maby have suggestion to the WMI code used to obtain the HAL? Here is the actual WMI query: Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") Set colOSes = objWMIService.ExecQuery("Select * from Win32_OperatingSystem") Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_PnPEntity where ClassGuid = '{4D36E966-E325-11CE-BFC1-08002BE10318}'",,48) For Each objItem in colItems strHALname = objItem.Name Next Best Regards Tha Sausage Eater... now eating chorizzos.