Br4tt3

I have no idea what the intention of the CD's and it's usage but, unless the file is not referenced from dosnet.inf, the files will not be copied, placed, to the correct temp directory when u run winnt32.exe..

Have u placed the corresponding driver files (*.inf and *.sys) in the image i386 directory? 99 of 100 times, there is something with the *.inf file that u have placed in the i386 directory. Check for an error in the Event Viewer, BINLSVC source, stating something like: "BINLSVC found an error parsing an .inf file" Check if the manufacturer has supplíed a custom *.inf file to the driver download for RIS installs...

Hi! Of course, I cannot be sure, but I would say that I am almost 100% sure that this error is not originating from using the /makelocalsource param. Normally, when getting this error, the file requested is not in place in the ~ folders, as expected. U would have to solve it through dosnet.inf.... have u tried running the same installation without the /makelocalsource param? I think u will get the same error even without it...

And the supporting driver has been referenced from the OEMPnPDriversPath entry correctly? Can u verify that the directory that contains the driver once the installation is done contains a INFCACHE.1 file.. meaning the directory has been added to the DevicePath key?

I dont use riprep, but I have noticed sometimes, that on some machines, when installing them and they come to the "Network installation" phase, each minute takes 2 minutes... when chaging the machine to be connected to another switch port, using the same installation media, with the same drivers, it just took a moment when redoing the same installation at the same phase. In my case it was, that the switch was not configured with PortFast/SpanningTree.... enabling that, and it went away! Maby the same for u?

This is a wild guess but anyway.... Check if u can extract the package, so u get the .msi file. Once there, try to run it without the .exe. In case you must envoke the .msi thorugh the usage of the supplied .exe file, my guess it is a InstallShield wrapper... if it is, then the .exe is enabling or disablíng properties in the .msi package! Only way to get around it is to download InstallShield's Studio (whatever it is called..) and modd the package from within there.. unless, the .exe supports input parameters: like <myapp.exe /?> where u can tweak the installation from!

First of all - this thread is in the wrong forum, should move it into the RIS forum! Second, the .sif file looks pretty screwed p according to me..... ur problem comes from the fact that u have not supplied the needed .sys and the .inf files for the NIC to ur RIS image's i386 folder or the .inf file u have supplied must be edited to support booting from an RIS environment. Most manufacters release drivers for there NIC's that have a specific .inf file that supports RIS booting...

Hi again! The two files, nvraidco.dll and nvraid.sys, are these the files that setup cannot seem to find when booting back into the text mode portion of the setup? In case Yes, then peform the following: 1. Check if the files are existing within a "normal", not a Dell XP CD! Prolly not.... then check if they are referenced from the dosnet.inf file.... 2. As stated above, when envoking winnt32.exe from within WinPE, the setup engine (dosnet.inf) is parsed to inform on which files that are to be copied, and where to copy them. As troubbleshooting, once the setup fails due "setup cannot find file xyz.xxx", then boot into PE again, copy the two files to the ~BT folder, restart into XP setup mode again, and check if the setup is working now... in case NOT, then boot back into PE again, copy the files into the ~LS directory and try the XP setup once more.. in case it works now, guess what; dosnet.inf needs to be edited to reference the files listed above! trial & error....

I am not certain but I think it is supposed to be in the ~LS directory... then again, Winnt32.exe reads dosnet.inf which informs setup on where to copy the files to (either ~LS or ~BT). If u added custom files, for example when using TXTSETUP.SIF to integrate masstorage drivers, u also need to supply the file references to the DOSNET.INF file. If NOT, then the text mode portion of the setup will fail due to the errors described by u... In my case, I often have to integrate drivers into my Windows setup source, if it is a new driver (not native to Windows setup) here is what I have to do (in terms of DOSNET.inf): Find section [FloppyFiles.2] and insert; d1, mydriver.sys Find section [Files] and insert the same value; d1, mydriver.sys So check for some specific files and check where they are referenced from dosnet.inf and then check to which directory the files are place once the installation goes into the text mode portion (~LS or ~BT). Hope it helps.. Also, this is why u dont have to edit same files when integrating stuff into the setup into the same files (dosnet.inf)... when for example running a RIS install, winnt32.exe is not used, kicking off a WinXP install from within WinPE, winnt32.exe is the only option which again, requires dosnet.inf to work... and a last advice, never mess with layout.inf or it will haunt u forever!

reg dll's - regsvr32.exe /s <my-dll.dll> from startnet.cmd maby would work?

msiexec /a c:\temp\<my-msi-module.msi> to extract the file perhaps? I do that alot, I then use the "pure" driver files (.sys - .inf - .cat) to get the install running with either dpinst.exe or rundll32.exe... if the driver package is packaged with InstallShield, u prolly cannot open the .msi directly without running the .exe installer. Hope it helps..

I know there is a hex haxXxx for it, just dont have it on me... seen it in here before. Also, MS features a script free of charge which u can grab that will do it for u with BDD 2.5. However, it is a dirty and uggly script that uses send keys.. If u want i done before the actual first logon (default user) u prolly have to kick it from cmdlines.txt which is a good place to start of with.

welcome then.... hope u like ur staying here!

Hi! I have a request to delegate control to none server admins (helpdesk) so they can be able to read the Event Viewer entries in the System and the Application logs from their local computer mmc's... anyone know a tool or CLI that will perform this for u?

Do they reference the same OS's? Normally, SCSI/RAID and SATA drivers uses the same driver file for the same OS - independent of run from boot disks based on the same OS version or from the full blown OS. This is not the case when comparing it to NIC's which often are delievered with one .inf for 16-bit setups common to for example RIS installs and one that can be used for within the full 32-bit OS.

Is anyone up for summarizing the entire website's info into one giant .pdf?

I would recommend u to start fooling around with something like BartPe or WinPE and once familiar with it, launch a .vbs script that searches for the marker files.... use diskpart to assign and create the partitions/drives for u, and also the drive letters! However, dunno if PE works with ZenWorks (Novell right?)... I would assume the script will have to search for a predetermined filename. Once it finds it, it can either read the inside of the file for the drive letter or the filename which could be the drive letter... If u r gonna use script logic, then u are far better of using WinPE/BartPE then for example DOS or the Win32 setup engine as they are to restricted. BartPE is freeware/shareware while WinPE is Microsoft money well spend...

? - Please elaborate without winsock (API's) pretty much everything in Windows networking stops working at all, then u r running a very basic internet connectivity....

dont we just luv the sound of modifying txtsetup.sif......

Networking in RIS: I assumes that u r using a flat image (dunno how it works in riprep...): 1. Check if the manufacturer has some edited version of the associated .inf file that comes with the installation disks, if YES, then use it otherwise use the default .inf file... 2. Copy the driver .sys & the .inf file to the d:\RemoteInstall\Setup\English\Images\<image-name>\i386 directory. This will take care of the 16-bit installation phase, text mode portion 3. Copy the whole driver (all files) to a custom created directory in ur $OEM$\$1\Drv\Nic\<NIC1> structure... this will enable the Windows 32 PnP to be able to scan this directory for the driver in conjuction with the last action... 4. Find ur answer file for the installation (*.sif) and find the entry OEMPnPDriversPath! Add a pending value to this file in the format of: Drv\Nic\<Nic1>;Drv\Nic\<Nic2>;Drv\Nic\<Nic3>. This will point out a valid directory for the setup to scan (#4 & #5 goes together). Hope it helps...

1. U place ur $OEM$ folder structure at the same level as the i386 folder for the image.. so far so good! 2. The NIC drivers (*.inf and *.sys) needs to be copied to two places, the i386 folder, and the whole driver (normally *.inf, *.cat, *.sys) copied to the $OEM$\$1\Drv\Nic\MyNIC folder.... 3. There are multiple ways of adding masstorage drivers to the installation image, I recommend u to use the TXTSETUP.SIF way of adding the SATA/RAID & SCSI to your installation. Basically, integrate *.inf information into the TXTSETUP.SIF file and the copy the required *.sys to the i386 folder! 4. There are loads of info within this forum on these topics...... spend ur time wise! This might be something (to start with): http://unattended.msfn.org/unattended.xp/

check ur Event Viewer if there is a parser error (BINLSVC source) refering to the .inf files of the RIS image... in case there is, it's prolly a bad .inf file u gotten that needs to be edited.. also, if the .inf file name was: E1000325.INF u should find a file named: E1000325.PNF in ur image i386 directory once the installation has been succesfull! I use the same driver file as u r refering to and this is what I had to: 1. Edit the E1000325.INF file in the i386 directory (leave the corresponding .inf file in the $OEM$ structure be) and find the section that reads (create a backup of the old one, .old) [Intel.NTx86.5.1] 2. Replace this section so that it reads; [Intel] Restart the BINLSVC service and the press F12 on the client again... if i am not mistaken, this happend when I applied SP1 to Win2003... hope it helps!

Trial and error....

Yupp, thats the one... if using another .wim for the boot OS within WDS, the WDS client software will not be working (I guess it is included within that specific boot.wim)! Once u have added that boot.wim to your boot OS category, add atleast one install OS within ur WDS UI and it will turn up in the WDS client software once the WinPE has been fully loaded...

Or perhaps the even more logic solution to maintain a working development environment with a wide range of OS's and applications: 1. VM-Ware 2. Virtual PC 3. Virtual Server