Br4tt3

Hi! This is just a qualified guess (so I am not willing to put life on it): But when using this method, I never got around of booting of a controller that was NOT listed in the [Defaults] section of the txtsetup.oem file. Try changing this to the actual controller that u wanna boot off... Even if not requested, I recommend u to move into using the TXTSETUP.SIF method of adding controllers cause it is more flexible even though somewhat cryptic. Good luck to u...

Well, I dunno why ur are having problems when running the appz from RAM of the RIS box, cause i am using two vb applications in my WinPE build that works just great and just like u said, it is the same as any CD/DVD WinPE boot (in regards to the runtime).

Still hmmm, dont get it... These are 3 diffrent physical controller adapters ( that I am sure off ) that are all covered within one driver file (percsas.sys). If I were to keep only one of the strings, for example, "DELL PERC 5/E Adapter RAID Controller", the installation would always present it as a PERC 5/E even if it was not the external controller but the internal one... I did a test on it and kept just the string listed above, and even if I didn't have the external one plugged in, the driver would present & detect the internal one as a "DELL PERC 5/E Adapter RAID Controller" which is not the case.. @ brainstane - as u said, did it and they (Dell) are using the unattend.sif method to perform the installation [MassStorageDrivers], and the Dell setup does not make any references for the driver to the txtsetup.sif file. Worth a try though!

Hi! I am also using the mraid35x.sys file for Windows 2003 SP1 (version 6.41.2.32) which I have copied to my i386 (not compressed) and this is what I have in my txtsetup.sif. It's all working smoothly: [SourceDisksFiles] mraid35x.sys = 1,,,,,,_x,2,0,0 [HardwareIdsDatabase] PCI\VEN_1028&DEV_000F&SUBSYS_014D1028 = "mraid35x" PCI\VEN_1028&DEV_000F&SUBSYS_014C1028 = "mraid35x" PCI\VEN_1028&DEV_000F&SUBSYS_014A1028 = "mraid35x" PCI\VEN_1028&DEV_000F&SUBSYS_013B1028 = "mraid35x" PCI\VEN_101E&DEV_9010 = "mraid35x" PCI\VEN_101E&DEV_9060 = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_0438101E = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_0466101E = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_0467101E = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_0490101E = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_04671028 = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_11111028 = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_10C6103C = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_10C7103C = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_10CC103C = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_10CD103C = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_11111111 = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_11121111 = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_03A2113C = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_0471101E = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_0471101E = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_0493101E = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_0493101E = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_0475101E = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_0475101E = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_04751028 = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_04711028 = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_04711028 = "mraid35x" PCI\VEN_8086&DEV_1960&SUBSYS_04931028 = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_04931028 = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_60E7103C = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_60E8103C = "mraid35x" PCI\VEN_101E&DEV_1960&SUBSYS_60E3103C = "mraid35x" PCI\VEN_1028&DEV_000E&SUBSYS_01231028 = "mraid35x" PCI\VEN_1000&DEV_1960&SUBSYS_05201028 = "mraid35x" PCI\VEN_1000&DEV_1960&SUBSYS_05181028 = "mraid35x" PCI\VEN_1000&DEV_1960&SUBSYS_05181000 = "mraid35x" PCI\VEN_1000&DEV_1960&SUBSYS_05201000 = "mraid35x" PCI\VEN_1000&DEV_1960&SUBSYS_A5201000 = "mraid35x" PCI\VEN_1000&DEV_0407&SUBSYS_05301000 = "mraid35x" PCI\VEN_1000&DEV_0407&SUBSYS_05311000 = "mraid35x" PCI\VEN_1000&DEV_0407&SUBSYS_05321000 = "mraid35x" PCI\VEN_1000&DEV_1960&SUBSYS_45231000 = "mraid35x" PCI\VEN_1000&DEV_1960&SUBSYS_05231000 = "mraid35x" PCI\VEN_1028&DEV_0013&SUBSYS_016C1028 = "mraid35x" PCI\VEN_1028&DEV_0013&SUBSYS_016D1028 = "mraid35x" PCI\VEN_1028&DEV_0013&SUBSYS_016E1028 = "mraid35x" PCI\VEN_1028&DEV_0013&SUBSYS_016F1028 = "mraid35x" PCI\VEN_1028&DEV_0013&SUBSYS_01701028 = "mraid35x" PCI\VEN_1000&DEV_0408&SUBSYS_00021028 = "mraid35x" [SCSI.Load] mraid35x = mraid35x.sys,4 [SCSI] mraid35x = "AMI MegaRaid RAID Controller" mraid35x = "DELL PERC 4/Di RAID On Motherboard Driver" mraid35x = "DELL PERC 4e/Di RAID Controller Driver" mraid35x = "DELL PERC 4e/Si RAID Controller Driver" mraid35x = "DELL PERC 4/DC RAID Controller Driver" And yeah, I know, my driver is located in the Windows\System32 dir... Hope it helps!

Hi! You might wanna check out the TXTSETUP.SIF file method of adding SCSI/RAID/SATA drivers to your installation which is nice, even though I am having problems with it right now. However, if you run a normal installation and invoke F6 and insert none edited drivers (downloaded from manufacturer) and the installation halts because of some error refereced to the supplied driver, I would say there is something messed up with the driver.

Hi! Maby this one will get u started: How Windows Setup works: http://technet2.microsoft.com/WindowsServe...3.mspx?mfr=true Even though it is MS boxes and drawings...

Hi! Thanks for the input, I will give it a try..... just one thing! About the three entries in the [sCSI] section, why not? My guess was that there were 3 unique "strings" to match 3 unique PnP values? or am I off track here?

Read Gosh's maunal on how to add the file using dosnet.inf ( http://gosh.msfnhosting.com/txtsetup.htm ) and it turns out that the file contains 2 sections, both named [Files], so I put my reference driver (percsas.sys) next to the old driver (mraid35x.sys) which is also referenced in the sections. This will place the percsas.sys file in the $WIN_NT$.~BT folder during text mode, and the inital error is removed and setup continues about 2 more minutes, before it halts with the following error: "Setup cannot copy the file: percsas.sys" But I guess, one thing solved, next to go...

Hi! Looking at ur winnt.sif file, u invoke the [GuiRunOnce] section and immediately run "Command9"? What happend to the 8 others? also, the Recovery Console can be added from just the [GuiRunOnce] section by running the Winnt32.exe /cmdcons command which will install it onto the comp. Either that or add into the WPI thing u got going in there! Cheers.

Hi and thanks for the input! However, I already have a build environment that I am satisfied with so I dont think I will change that part. All I wanna know, if there is something missing in the information stated above, on how to intergrate a new device driver.

Oki, first problem that I faced was that the older driver (mraid35x.sys) is an existing driver while this one is a new driver not listed within layout.inf and dosnet.inf. I followed Gosh's TXTSETUP.SIF walkthrough to my best, that is I added the following into my dosnet.inf file, [Files] section; d1,percsas.sys once the Winnt32.exe setup kicks off and the machine reboots into text mode phase, I can now verify that the driver file (percsas.sys) is located in the C:\$WIN_NT$.~LS\i386 folder (meaning the file is copied down to installation source I guess). So far so good, one thing less to handle... but still, I get the same error message when booting into the text mode portion of the Win32 setup! Any thoughts on this one?

Hi! So we just got our new Dell PowerEdge x9xx series delievered with the Perc 5/I controller. I am currently trying to add support for them and I am having some problems as well as some progress. Here is what I have done so far. I have added the following into the txtsetup.sif file for the Windows 2003 installation source (on RIS): *********************************************************************************** [sourceDisksFiles] percsas.sys = 1,,,,,,_x,2,0,0 [HardwareIdsDatabase] PCI\VEN_1028&DEV_0015&SUBSYS_1F011028 = "percsas" PCI\VEN_1028&DEV_0015&SUBSYS_1F021028 = "percsas" PCI\VEN_1028&DEV_0015&SUBSYS_1F031028 = "percsas" [sCSI.Load] percsas = percsas.sys,4 [sCSI] percsas = "DELL PERC 5/E Adapter RAID Controller" percsas = "DELL PERC 5/I Adapter RAID Controller" percsas = "DELL PERC 5/i Integrated RAID Controller" ************************************************************************************ The information has been extracted from the driver .inf files. When using this on the RIS server, the requesting installing client/server works smoothly with no errors. However, we also use CD/DVD based installations and when trying to add the same info as above into source, the installation will halt at the text mode phase with the following error: "The file percsas.sys could not be found. Press any key to continue" - Of course, the percsas.sys file (main driver) has been added to the i386 directory and is present but still, on the RIS it works, but not from the CD/DVD based installations ? I have used the same tactic to add the "old" DELL RAID drivers called mardi35x.sys to the installations with the same parameters as specified above, with no problem, either on RIS or on from an unattended CD/DVD based installation. Any clues?

Hi! I am not sure I am following u exactly. I am confident up to the point where u deploy XP (using Altiris) to the client computer recieving the XP installation. My questions are: Are u deploying WinXP images that have been syspreped to the client? As I understand it, Yes u are... from this point, are u refering on how to "insert" the model specific driver path into the "offline" registry of the syspreped machine from within WinPE? In case the above goes with ur plan, I have the same solution in place, also using WinPE 2.0 to load an WinXP .wim image that has been syspreped onto a client, a script will then insert the model specific drivers into the offline registry of the client. Once this is done, the WinPE mode is exited and WinXP mini setup starts which will scan the DevicePath entry of the registry and scan any drivers found. It goes something like this: (Logic of script ) 1. Mount the offline registry of the newly deployed client to the WinPE 2.0 registry using < reg load > 2. Do a regread from within the .vbs script to read the DevicePath entry value. Save the value to an variable within the script from the clients temp hive. 3. Read my custom model specific .inf entries (the actual driver structure) to be included on top of the other into another variable. 4. Copy the drivers (model specific) to the client 5. Regwrite the combined value of the two previous variables back to the temphive. 6. Unmount the temphive and write back the value to the newly deployed client using < reg unmount or sumthing > 7. Done. Next time the machine boots mini setup will scan the newly added driver directories. Oups... the DevicePath value uses: %value% to locate the directories... had a problem writing the "%" signs back and get it working so I also changed the use of the variables to hardcode it to the C: drive of the clients which suits me good. Kind of cool to as this would let u update the driver structure/versions seperatly from the main base image. Let me know if this works out for u or if u need some sample code from the script.

Hi! I wanna get your input on a good piece of software that will perform benchmarking on server hardware! I have not been able to find something that actually benchmarks the hardware for a server (not to good at googling I guess) while there are millions of softwares that perform 3Dfx checks and web server meassurements.... Anyone stumbled onto something like this? or any software that u can recommend for this purpose? I wanna meassure the following: Computing capacity - CPU/RAM, Disk throughput & Network throughput Of course, I dont want to buy a piece of software that is locked to the manufacturer of the hardware, as DELL or HP! Thanks in advance!

hmmm.... dunno, in the old version (WinPE 2004) documentations it was mentioned within "limitations". checked the winpe.chm (2005) but could not find it... now that we are talking about it, I am not sure that limitation is still in there as I have never tried to keep WinPE running for MORE than 24 hours. Maby some other dudes in here knowns about it.. I remember that it was the 24 hour limitation and there were limitations to not accept incoming requests, services (server service).. good luck to u... Nope, it is still in there.... open winpe.chm and within the section "Introduction to Windows PE" u have the section: "Limitations of Windows PE". "To prevent its use as a pirated operating system, Windows PE automatically stops running the shell and reboots after 24 hours of continuous use." - of course there is ways around it even though one would brake the support agreement with MS.

to be honest, no idea... however, WinPE is primarly desgined for deployment scenarios and no uptime OS. WinPE shell will auto reboot within 24 hours unless haxxed and files have been replaced. Best Regards Tha Sausage Eater...

I am almost sure that u r able to extract the InstallShield package, either using the setup.exe or the .msi file that normally comes along with the download by using a command switch. What u what to do is to perform an administrative .msi installation and extract the files to a temp dir. From that spot, u will be able to run the drvinst.exe command on the .inf file(s). If there is no switch for the InstallShield .exe then download a free trial of the InstallShield AdminStudio software (think it is named like that, I use Wise) and extract the files from that app. Best of luck to u...

To sum it up: YES! The .sif file goes into the templates directory for each image... I encourage u to google a little or read some threads in this forum as it will provide u with extensive information on how to move along and to try to out the RIS component.

Yupp.... Gadget is right on... WDS will be able to deploy the .wim format, while the structure of the .iso can only be deployed from a CD/DVD (when using WinPE 2.0) cause of the new boot files featured in WinPE 2.0...

I would recommend u to add WinPE to the RIS box in the form of a .iso file instead of a flat file structure and boot it into RAM, even though it does not solve ur main issue. If u have the same problem in ur virtual machine as well or when booting from a CD/DVD I would recommend u to: 1. Rebuild ur WinPE base image. It has happend to me that sometimes (for no specific reason) the WinPE image does not work as intended. When redoing the whole thing again, it worked for me.... with no insurrance that it will though.... 2. Add the NIC driver to ur WinPE image (tie into the image) using drvinst.exe (i think it is...) and try again. That all I can think of..

Try to described it more in detail and it will easier for the guyz to help out.... I assume u r refering to PXE (as in remote) and that u r using MS RIS as the PXE server. Are u booting the client into WinPE using PXE? using which version of WinPE? 2004 / 2005 or WinPE 2.0? Are u booting WinPE from a flat file structure or are u booting WinPE in the form of an .iso file on the server? Normally when u get the "Please Wait" message it normally means that u lack some kind of driver, as the NIC or the masstorage driver... try to run the same .iso in a VPC/VM-Ware session and see if it works in there before running it from the PXE server. That way u will know if there is a general problem or an issue cause by the fact the u r booting the client from a PXE server... normally u can choose to either emulate or use the physical NIC of the machine from within the virtual machine software, that way u can also try your driver for ur NIC from within WinPE. Try using the netcfg command or PENetCfg.exe (download) to detect that WinPE can address ur NIC correctly. hope it helps...

Credit goes to Johan Arwidmark - Microsoft MVP - Windows Server - Setup/Deployment: -----------------Install WAIK on a machine (server)---------------------- - Copy the folder "boot" from C:\Program Files\Windows AIK\Tools\PETools\x86 on the server to the client c: root - Create a folder named C:\Sources on the client - Copy the file winpe.wim from C:\Program Files\Windows AIK\Tools\PETools\x86 on the server to the directory C:\Sources on the client (change the name of the file to boot.wim) - Copy the file bootmgr from C:\Program Files\Windows AIK\Tools\PETools\x86 on the server to the root of the C: drive of the client - Install Windows Vista Boot loader by running command: bootsect.exe /nt60 c: - Reboot the client and it will now boot WinPE 2.0 into RAM of the client Note: Bootsect.exe can be found in the C:\Program Files\Windows AIK\Tools\PETools\x86 directory.

Thats true... the way to point/mount the .iso (described above) that worked with WinPE2005 just doesnt do it with WinPE 2.0 and when speaking with MS they say that it should not work either... it is just that it is wiered that they removed such a power feature as it enables you to automatically/schedule reinstall a computer without a user having to insert a CD/DVD or pressing F12. In other words, the same way they use their own SMS/OSD kit to perform ZTI (Zero Touch Installations).... and I have tried the way to copy the content as described by Jungle_Warrior, but then again, manual labour sux.

Hi there... try the http://unattended.msfn.org site or even better - http://unattended.msfn.org/unattended.xp/view/web/24/ shows u how to intergrate the KB's into the source of the installation. I hope I understood ur problem correctly... or download SUS if that is what u mean.. (Software Update Server) which u can obtain from MS web site..

Hi guys! When using the "old" WinPE 2005, one can create an .iso file, place it in the root of the c: driver, change the ntldr (for WinPE setupldr.bin) and ntdetect.com (for WinPE ntdetct.com) and then create a .sif file which contained: [setupData] BootDevice = "ramdisk(0)" BootPath = "\i386\System32\" OsLoadOptions = "/noguiboot /fastdetect /INRAM /minint /rdexportascd /rdpath=winpe2005.iso" Architecture = "i386" and then of u go... However, WinPE 2.0 I cant get to work. If I create a WinPE 2.0 .iso file (which contains a .wim inside) I cant seem to map the entries correctly to the new image. I have tried to change the BootPath entry to "\Boot" and "\Sources" and lastly "" but no luck... also tried to change the Architecture entry to "x86" and a combination of them but it wont work. If I take the same WinPE 2.0 .iso file and use it in a virtuell machine and try to boot of it as an ordinary CD (.iso image) it works just fine. So there is nothing wrong with the .iso file, just how to point out how to boot of it when booting from the harddrive.. the winpe.chm for WinPE 2.0 is not exactly a 100% perfect right now. Any suggestions or clues? P.S 1 more day until .se are getting owned in the global fussball tournament