Vagabond8

None of the Nforce 4 chipsets can do it, though. Microsoft has confirmed, that "the nvidia concept simply does not work with Pe loaded from ramdisk over pxe" and they will do nothing about it. So it all depends on if customers can put enough pressure on Nvidia to make them design a special driver for this sort of installation.

I'm not adding to the discussion, but confirming... The finish script hangs with cpu maxed out (together with csrss.exe system service) Rebuilding with the newest updates...

Sure. There are a few wims inside tha cab. I built my pe cd from there for i386 architecture and the procedure described in the docs sort of worked. Except for some missing device drivers as always. So.. read the docs.. it's all there. Step by step.

Me too. Though it boots just fine and it looks good. And of course already hit the driver problems. testing...testing:)

So anyone got the WAIK? So how is it? Is the PE included? Any first impressions?

I have a .Iso image of my custom Windows PE CD. Built with the /PnP switch to enable the PnP detection in Win PE. Now the .Iso image is read "as is" into the clients memory, mounted into ramdrive and then the Win Pe boots as usual (like from CD) The only diference is, that the source ( .iso) is not on a physical cd but in a virtual (ram)drive in the clients memory. It doesn't matter where i PXE-boot from, because, when the image (the .iso) gets loaded into the clients memory, it's on its own and i can unplug the net cable. It boots as if it was a CD-Rom. The Binl server does not get involved and is not needed. I boot from a linux TFTP server. Though, as the same .iso works with NF4 if booted from a CD and also with every other configuration i have, the problem is directly linked to the NF4 netbus not being accessible for Windows ONLY right after it has loaded the Iso from tftp with the generic drivers. So my guess is, that the generic driver stays half-loaded into the memory and therefore blocks the PnP from installing the right driver. Does anyone know how to clear the Win PE loaded driverinfo and then run the PnP detection again? Or some other trick i might try? If not, i give up.

I don't understand:( I'm using a Windows PE Image (a 150 mb .iso image). I load it into memory (ramdisk)first and then boot from it. All the same iso on CD and TFTP server. And the result is different... so... I'm still confused.

I have searched not only the forum, but most of the internet known to mankind:) (though might have missed the right article - if you know any good one i'm all ears) The PE boots all fine. Dhcp points the client to TFTP, from there the image is loaded and booted. And the shell comes up fine.. and then, when i try to map my network drive, there is no network card present. I have switched to PE 2005 with server 2003 sp1. All pure and with only the newest nvidia drivers. The funny thing is... if i: 1) make a ramdisk image 2) put it to a cd with the i386 dir and the needed files (described by MS) 3) Everythings boots and works 100%. Network comes up and all is fine!!! When i use the same image, the same bootfiles (Again like MS itself has suggested) - everything boots up but NO NETWORK CONTROLLER INSTALLED! It is soooo frustrating and i'm pretty hopeless. It might be an issue of the nvidia boot agent... well i have tried like 6 different NF4 MoBos and no go. All exactly the same. Its like the network driver the nvidia bootagent uses, stays in the memory and doesn't release the NIC.. OH.. i hope someone can just give a pointer...

I have a frustrating problem. I finally got the NF4 NIC drivers to install to Win PE. It just took the /PnP for source cration. Though it brought me to the next problem. The PnP only finds the necessary NF4 Network Bus (needed for the nic's driver) if booting from a burned CD. When i use the very same image from Ramdisk over Linux PXE it doesn't detect the NIC. The only thing, that is different from the original PE image, is the ramdisk.sys i have to overwrite it (with the one in server 2003) in the i386/drivers to make it boot from ramdisk. Could it really mess things up so much??? All othe NIC's i have work well and no problems. I use OPK from and with XP SP2 OEM pack and the bootfiles (startom, ntldr and ntdetect) from Server 2003 SP1. Please help

Updated the Microsofts msi installer and still no go. Trying the installshield update now. Edit Ok.. it's working now. As 5eraph suggested, the update of (in my setup) ISScript9.Msi through the runonceex worked. Though, it might be a good idea to include it to the actual driverpack, so taht it runs (and finishes) before the setup procedes to the actual ccpane.msi

I messed around with the thing a little bit. Fot first i had to add the .NET framework to my unattended setup. OK i can live with that. As the Catalyst panel's msi instller did not work with the default msiexec parameters, it needed the setup.exe from the official package. The setup.exe configures the msiexec to be able to run the AtiCCC.msi (or whatever its name was). No way round it... so i added the setup.exe to the packed SFX into the Graphics drivers A pack. So i made the finish script to first run the setup.exe from the original pack... then make sleep.exe to stop the script for 20 sec. so the setup.exe could configure the msiexec. Then, when the setup.exe is done, it hands the setup over to the .msi package of the actual cccpanel. And then the automatic script continues as in default and runs the msi package again and this time silently, leaving the first (manual) msi setup screen just open to the desktop, where i have to clse it manually when the setup is finished. A lot of work and the outcome is not too elegant, but at leat it sort of works now. As i'm writeing this, i started thinking.. maybe the problem is an older version of the msiexec in my windows source.... Maybe if i updated it, the problem would go away... Does anyone know, if there has been an update of the msiexec recently? Which version are those of us using, for whom the setup works? (I'm using a OEM version of XP home with SP2 already officially integrated) Any help would be very much appriciated:)

I do not have the .net frame and i sort of do not want/need it for my setups. And i understand that the control panel needs .net but then does the .msi installer also? Or is it part of the .net framework? And then.. does the notebook driver also require the .net frame? If this is confirmed i have no other option, but to return to the previous control panel and drivers version. (the ATI control panel does not support the catalyst drivers, does it?) PS. I think the need foe the .NET frame with the driverpacks is big enough news to put into the official homepage as a note and also, could it be possible to hold an official version without .net requirement up to date with nVidia drivers and panel?

Well i have got a problem. The Ati control panel does not get installed. Everything works fine until the script runs the ATICCC.msi... As the setup is qiuet, it dowsn't return an error, but if i try to install it manually, the error i get is: The installscript engine is missing from this machine. If available please run ISScript.msi or contact your support perssonell.... Now this is happening on both XP home and pro with SP2 and all the hotfixes manually slipstreamed... How can i fix it, except to roll back to an older driverpack?

Back again:) I have read a lot of material and sort of getting dizzy already but anyways, i've thought of a possible solution: What if the whole process was handeled exactly as a unattended networkinstall but instead of copyng the I386 from a network location where the installation point is located, the part of the setup-script is tricked to copy it from the CD instead. In that case there should be 2 CD's... 1 for home and 1 for XP, but that doesn't matter as they'd last longer if the drivers did not have to be updated that often. So the setup program would be tricked to copy the I386 from d: instead of the (usually) network mapped Z. Only the drivers directories would come from the Z. What do you think, could it be made to work this way? And if yes, where should i look for the script that is responsible for coppyng the files? (also, does a client system have a drive letter assigned for the CD-drive by default or could this be an obstacle?)

Hi I have got a difficult task for myself and i very much hope that someone here would be so kind to point me into the right direction. The problem: 10-25 XP installs (both home and pro) taking place at the same time(not synchronus), so the whole installation from a network server is too slow even over Gb network. So there could be a solution - that the XP setup files would be installed from a CD but the necessary GUI mode device drivers could be somehow included from the network server... But then how to make it happen? Even though the motherboard drivers are installed during the text mode, it often happens that the NIC is not functional at that time.. and even if it was, how to make windows installation scripts to wait and confirm that the drivers really are there when the installation moves to that point.... The drivers should be on a network, to for one, make all the client PC's similar and use the same (most current or reliable) driver versions, and for two, to have the possibility of fast updating the drivers without the need to replace all the CD's. I might sound newbish or overlook some very simple solution, but even though i'd really-really apprichiate if someone could give me some pointers to where to look for the solutions or maybe explain something i seem to be not knowing... Thank you in advance... Arthur