indy_dba

Yes exactly the the two Dell PC's I have tried it on; an Optiplex GX520 and Precision Workstation 380 will not PXE boot BartPE; however, from CD-ROM with the exact same BartPE build the network driver works fine. Whats even stranger is using the same driver an HP DL140 server PXE boots the same BartPE build just fine. Very odd indeed, huh?

You should definately install and run the Windows Defender BetaII most Antivirus programs by McAfee and Symantec (Norton) do not catch nearly as many Spyware programs as a dedicated Antispyware program does.

Thanks cluberti, didn't know that. I actually work for a M$ Gold Certified Partner and have WinPE 2004 & 2005 laying on my desk... I opted for BartPE initially because it seemed simpler to install and get going with, I liked all the plugin support and the GUI, but have things so well setup with it I may try WinPE just for fun and WMI support!

I dealt with a particularly nasty virus/worm/monster thing on a co-workers computer that sounds similar. He told me about strange things his computer would do and asked if I could look at it while I was setting up his broadband connection. (I figured it was just user confusion, but was I ever wrong! ) It was the scariest piece of malware I had ever seen (so I dubbed it a "monster" piece of malware), here is what it was doing: 1.) Random pop-ups from Internet Explorer 2.) Home page in IE constantly changed, no matter what we set it too 3.) Sometimes mysterious high CPU usage 4.) Couldn't open Task Manger (the sneaky thing disabled this somehow, so no way to find the offending process) 5.)a) Regedit and RegEdt32 would open, but closed immediately when the mouse moved over any are of the Regedit window 5.)B) MSCONFIG would not run... *** Darn, no way to get to the registry to disabled this thing from auto-starting on reboot *** 6.) Sometimes the PC would reboot itself (totally unexplained, no crash dump, probably some hacker controlling the PC and installing software that required reboot after all this PC was definately a part of a "bot" network) 7.) Every AntiVirus web site I could think of that had an online or free scanner would be automatically redirected in IE (Symantec, McAfee, Trend, AVG, etc.) I would get redirected to a porn site or dead link. (I couldn't even enjoy the porn sites because this monster malware had me sooo p***ed off ) Now I didn't have all my PE tools with me that day, in fact I didn't have much of any recovery disk in my Bat belt, so I gave one last ditch effort. I had been using Microsoft Antispyware Beta1 for a while and was recommending it to everyone and gave one last chance hoping this malware wouldn't redirect my link to download it....and wa laaaa I was able to find and remove a couple of "highest threat" malwares and many more "medium" and "low" threat buggers and after reboot the system was fine. This tool is now in Beta2 and has been renamed Windows Defender get it by clicking this link. Also check the Control Panel / System applet / Advanced tab / Startup & Recovery section / Advanced button and look for the "Automatically restart" box. You can uncheck this to prevent the auto-restart; however, if you have a virus or real hardware problem the Windows kernel may still freeze up and the only difference will be that you have to restart the PC manually with the power button. Good luck!

That's true, but using WMIC after the initial plain install of Windows could be very useful for querying system information and making decisions which apps and drivers to install. I keep reading hints that say the XPE plug-in for BartPE enables WMI, but I haven't had a chance to see if this supports the WMIC command-line utility. If it did, that would be very sweet, because one could query SMBIOS information before choosing which image to install from the PE environment. I wonder if WMIC is available when CMDLINES.TXT is run (before the reboot) since this is when many unattended installs perform custom actions? If no one knows for sure, I suspect a test is in order...

I found another way for you to determine the make and model of the computer to facilitate driver and application installation based on BIOS data like Manufacturer and Model.It's called WMIC for Windows Management Information Command (aka command-line utility) that runs from a .CMD or .BAT file to query EVERYTHING under the sun from SMBIOS info, Windows info, Hardware, User Accounts, Startup programs, just about anything you ever wanted to know about a Windows system via a command-line utiltiy! The best part is it's included in XP/2003 and I didn't have to install anything special to use it! Go to a CMD prompt and type WMIC, it will install and then you will be inside a WMIC prompt (if it fails to install from the CMD window just do a Start/Run WMIC and press enter). Type /? to find the w-i-d-e array or commands. Read more on WMIC at http://www.microsoft.com/technet/prodtechn...y/wmic.mspx#ECD Here's an example of some information you can retrieve, but there is LOTS more you can get at: U:\>wmic wmic:root\cli>csproduct get Name Name Precision WorkStation 380 wmic:root\cli>cpu get AddressWidth, CurrentClockSpeed, DeviceID, Name AddressWidth CurrentClockSpeed DeviceID Name 32 2992 CPU0 Intel(R) Pentium(R) D CPU 3.00GHz 32 2992 CPU1 Intel(R) Pentium(R) D CPU 3.00GHz wmic:root\cli>exit Version Here's an example of how to use it in a .CMD file: U:\>wmic csproduct get Name, Vendor > whatami.txt U:\>type whatami.txt Name Vendor Precision WorkStation 380 Dell Inc. Hope this helps some trying to perform unattended installations out... I am addicted to query the WMI now!

Correct these files come from the I386 directory from the source disk/directory and PEBuilder grabs them from there.

Do the choice and shutdown files have to be added to BartPE somehow, or are they called up on a remote share? Also, what is the reason for "=2" ? If you want these files available for use in a .BAT or .CMD script then you need to tell PEBuilder to include them when you make a BartPE build. The =2 tells PEBuilder to put them in the System32 directory if I remember correctly. See the "directories ID table" in the online help for BartPE at http://www.nu2.nu/pebuilder/help/english/p...inntDirectories

I can't get an IPCONFIG to work from BartPE when I boot if from PXE client from Microsoft Windows Server 2003+SP1 RIS server. I am using PEBuilder 3.1.10a, server has Intel PRO1000PM & MT cards but drivers seems to work fine, using a Server 2003+SP1 as source for the build. The basic functions of the networking seem fine, BartPE loads off the PXE server maps network drive, Ghost images to the network share fine, etc. However the new Firefox plugin is out and it would be nice to have DNS working. If I manually run PE Network Configurator and enter a DNS Server entry manually DNS appears to work fine. However, IPCONFIG /ALL still fails. The error from IPCONFIG /ALL is: Of course IPCONFIG.EXE is located in the System32 directory like it's supposed to be. Are there any known issues where the DNS entry will not get set automatically when BartPE boots up? Does anyone know why IPCONFIG fails when basic networking functions succeed?

Good work again guys! I am so used to my BartPE being in RAM drive from the PXE boot that I forget when running from CD-ROM you need to run commands from it so it's like duhhhhhh on why Shutdown wouldn't work from the CD... I am a little about not remembering this... I like the syntax of peshuteject.exe better anyway. Very cool stuff! B)

Can you be more descriptive, what exactly didn't work? Can you post the part of your .BAT file that didn't work? Remember when running .EXE's from the network share you must specify the full path to them like so: Z:\SHUTDOWN.EXE -R -F (where Z: is mapped to the directory the .BAT file is in) TIP: The other alternative is to modify the PATH variable like so: SET PATH=%PATH%;Z:\ (I haven't tried this yet in BartPE I don't know for sure if BartPE supports the SET command) This method would allow you to run the SHUTDOWN command without specifiying the full path to it.

You can do either or both let me say this another way... If you modify the Custom.inf and rebuild your BartPE CD then Shutdown.exe will be available via the System32 directory OR you can copy the Shutdown.exe file to the directory you have the .BAT file in OR you can do both! It won't hurt if Shutdown.exe is in both places (but it's probably cleaner to add it through PEBuilder via Custom.inf) but maybe much faster to test with by just copying it to the network directory the .BAT file is in. Either method will work and should get you the same result a workings SHUTDOWN -R -F command line utility!

If you modify the Custom plug-in in PEBuilder, as shown below, then the Shutdown.exe command will be automatically included in the BartPE System32 directory which is in the PATH environment variable so your .BAT file will find it correctly. Or you can just copy Shutdown.exe from an existing XP/2003 system to the network share directory where you run the .BAT file from. Either method should work. Also take a look at DJe's post #28 in this same thread. Step 1) Edit the Custom.inf file in the pebuilder3110a\plugin\!custom directory adding the following section and line to the end of the file: [SourceDisksFiles] shutdown.exe=2 Thanks for testing this out, I was sure you could make these techniques work. I feel we have advanced unattended installs up another notch (maybe to the insane level) with these steps... Great work guys! GREAT JOB! Big thanks for finding the PE Shut & Eject Utility! I will have to play with this some day. (though it's hard to find the time to make shiny round coasters when you've set up PXE/RIS... ) You never know when this technique will come in handy! Anyone buying me beer & pizza for this help? Just kidding...

Shutdown is an .EXE and yes it's normally found in the System32 directory; however, it should work fine no matter where you call it from because DOS looks for apps in the following order; current directory and if not found it searchs the locations in the PATH environment variable which includes System32 usually. Type SET PATH at a command prompt to see the list of directories DOS looks in to run programs. So there is no reason this technique shouldn't work for you. The only possible gotcha would be if the PC automatically closes the CD tray during reboot. In that case call the ejectcd.exe from the RunOnceEX registry key and this should bypass this problem. Of course you original Ghost image needs to have this RunOnceEX key already included.

I just want to make sure you understand my thought on this, DON'T use Ghost to perform the reboot... instead let Ghost finish and return to the .BAT file you ran it from and then run the ejectcd.exe followed by shutdown.exe -r -f. An example section of the .BAT file you use might look like: ghost32.exe -fx -sure -quiet -clone (add syntax for your image) ejectcd.exe shutdown -r -f Note: We did NOT use the -RB option in Ghost, so Ghost will run and gracefully exit and return control to the next line in our .BAT file which ejects the CD-ROM and finally restarts the system (using XP shutdown cmd). Have you tried this? The only problem I can forsee is if the user has walked away and the BIOS sucks the CD-ROM tray closed then BartPE is going to boot again, so perhaps the Bootfix "Press any key to boot CD" option is the best after all. However, the option menioned above is fine for admins & helpdesk that must wait on the image before leaving the PC being rebuilt, when the CD ejects they know they are done.

It does look like someone once had written a couple utilities to EjectCD while BartPE was running or perform a Shutdown & Eject combo; however, I cannot read the language the downloads for this plug-in are on. Can anyone tell me if the actual files are on these web pages? http://www.bootcd.us/BartPE_Plugins_Author/dicht/

Sorry I didn't realize you had tried this technique out. Did the ejectcd.exe force the CD out of the tray while running BartPE? I mean before you issue the restart, something like: Ghost32.exe blah blah restore image automatically blah blah ejectcd.exe shutdown -r -f Did the CD tray actually eject? Would the idea to include the "Press any key to boot from CD" be easy enough for your users? I just suggested this Bootfix plug-in in post #19 in this same thread. I think you haven't seen it yet. With this technique the user would only have to press any key to boot from CD initially (not a special key like F3000 or something), they could then walk away, and when the computer reboots after image creation no one will be in front of the PC to answer the boot from CD question the second time so Windows will run from the hard drive, calling the ejectcd.exe option from the RunOnceEX registry key, and if the CD tray opening by itself doesn't cause a user to jump out of their chair or call the help desk saying (this machine is possessed) then it will serve as a visual clue the machine has been completely rebuilt and is ready for the user to take the CD out of the open tray and login for the first time. What do you think are we getting close on this solution?

A gentleman named Tom Speirs is where I got my first tips for this. He has two web pages dedicated to setting up BartPE to run off a Windows Server 2003 server running Remote Install Service (RIS). Tom has very recently posted a new page where he outlines how to integrate those Sneaky Driver Packs and some other major BartPE plug-ins to make an UPBE (Ultimate PXE BartPE Environment), that's my name for it anyway. Tom has a new site for this stuff: http://tomspeirs.co.uk/bartpeonris.htm and Tom has also been nice enough to leave up the original posted site that people like I used originally to get RIS+BartPE to work together: http://tomspeirs.co.uk/bartpeonris-old.htm Microsoft also offers lots of documentation on getting WinPE (Windows PE) to run from an RIS server also; however, the original intent of RIS was for just remote installs not necesarily to launch PE environments. I think the guys at Microsoft really missed the boat on this one because running from a PE environment I can do regular RIS unattended installs, RIPREP installs, Ghost image installs, system diagnostics and troubleshooting, etc. where from plain RIS all I get is an unattended install that I have to keep a different RIS image for many different types of hardware (at least different mass storage controllers) which seems much more of a hassle than setting up a PXE boot PE environment. This is an opinion and I know somwhere there are probably a dozen RIS junky admins cussing this statement. So all I can say is na na naaa na naaa na (cause I prefer to use Ghost and Sysprep and restore images in under 10 minutes). Requirements for this include: 1.) Client PC's that have a NIC and BIOS that supports PXE or Network boot option. (CHECK THIS FIRST) 2.) Full Administrator rights to a Windows Server 2003 server so you can install Remote Install Service (RIS) 3.) A good working knowledge of DHCP and domain admin permissions to be able to Authorize your DHCP server for RIS. 4.) If you will be trying to PXE boot across routers or subnets you'll need a working knowledge of putting "Helper" or "Hints" entries in your routers or some other clever technique to allow the PXE broadcast to find your RIS server across the WAN/Subnets/Routers etc. 5.) The Server 2003 CD-ROM or I386 files so you can install RIS. or you can trade some of these requirements for... 1.) A private test domain controller (to run RIS and DHCP and have full domain admin rights too) 1.) A LOT OF PATIENCE 2.) AN INCREDIBLE DESIRE TO LEARN 3.) A LOT OF FREE TIME TO EXPERIMENT 4.) A strong set of Google skills (this is really the ultimate I.T. skill)

Depends on the BIOS, most of the bootable CD-ROM's I have used over the last 10 years post a question like "Press any key to boot from CD..." if the BIOS has been directed to boot off CD first. I used to think this was a BIOS enabled feature, but I recently realized it's controlled by one of the startup files on the CD-ROM. In PEBuilder there is a plug-in for this called "Boot Fix (Enabling "Press any key to boot from CD")" If you enable this plug-in then when the PC boots from the BartPE CD you will see the "Press any key to boot from CD" message for like 3 seconds and if you don't press a key the PC will go one looking to boot from the next device according to the BIOS boot order. So this would be a good requirement of the RunOnceEX-EjectCD technique so BartPE would not automatically startup on the reboot after the mini-setup is complete. I do agree it would be absolutely the best solution if BartPE had a shutdown option that ejected the CD as it's last command before restarting the PC and I may look into this further, but this is probably a long shot at best. I am just wondering if anyone has tried to use the original suggestion to just call the ejectcd.exe from a BartPE enabled CD to see if this works? If it does this .EXE could be run before issuing the shutdown -r -f command, and then the RunOnceEX-EjectCD technique would not be needed. The real question is anyone willing to do some testing on this???

I don't use CDs at my shop, we PXE/RIS boot instead, so my copy of BartPE runs over a gigabit network which is sooo sweet. The best part is I don't have to make a new CD every time I want to try a new build of BartPE I can just copy the files to the Windows Server 2003 server that's running RIS. Of course it takes some effort to get it working but it's very cool once it's setup. I know this isn't practile for everyone as many PC's don't have NICs & BIOS that support PXE booting; although I bet your Dells do press F12 while booting one up and check the boot menu option for "Network" or "PXE" boot (if not check the BIOS and see if boot from network is enabled). At any rate we need to find a solution for those admins that are still making shiny plastic coasters to boot from (aka bootable CD-ROMs). Did you try the .EXE I mentioned in this post earlier in our thread? http://www.msfn.org/board/index.php?s=&sho...ndpost&p=498574 I know you can add the SHUTDOWN.EXE command to the BartPE environment; however, this doesn't seem any better than telling Ghost to reboot when done because there is no Eject CD and Reboot option. I just had a fresh thought on this subject (keep the laughter down), who says the CD has to be ejected immediately after Ghost/BartPE is done? Can't we just add a registry entry to eject the CD when Windows starts up the first time? The solution I am thinking of would go like this: 1.) When you Sysprep before making the original Ghost image file include the ejectcd.exe file in the Sysprep directory. Get this .exe from: http://www.alexnolan.net/software/commandline.htm 2.) Make a registry entry that calls the ejectcd.exe when the system first boots or use the cmdlines.txt file to run it. You can add this registry entry from the CMD script you use to run Sysprep like so: reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx" /v "EjectCD" /t REG_SZ /d "C: \Sysprep\ejectcd.exe" /f If you are familiar with cmdlines.txt with Sysprep this file would look like: [Commands] C:\Sysprep\ejectcd.exe 3.) Boot from BartPE CD 4.) Menu.bat runs from network share and allows user to choose the image to restore (or maybe automate this using the SMBIOSD trick) 5.) Let Ghost reboot the computer when imaging is complete or have Ghost exit and then issue a SHUTDOWN -R -F 6.) The newly imaged PC reboots and runs through mini-setup (I hope your using Sysprep before making your Ghost images to eliminate the duplicate side issue). According to this article it's even possible to make this entry in an .inf file used by unattended installs (I forgot about that) but for Ghost you will want to add the RunOnceEX registry key during the Sysprep process as previously discussed. TIP: The RunOnceEX commands are processed before the user logs and are automatically deleted after they run. This should be perfect to automatically eject the CD-ROM! So at this point the computer has been imaged with Ghost and the CD should eject right before the first reboot after mini-setup completes. Now I can't do anything if the BIOS trys to close the CD tray drawer during the shutdown or boot process (I know some BIOS do that, so tell your users to be fast to snatch the CD) Of course, yet again I have done the brain work so it's up to those of you that still boot from the shiny, round coasters to test this out... Either I'm on a technical role or none of this cr*p I have suggested will work outside the wonderful world of theory...

I cover your questions in detail in the following post: http://www.msfn.org/board/index.php?s=&sho...ndpost&p=495302 Farther down the same post we have started to discuss the automatic CD eject: http://www.msfn.org/board/index.php?s=&sho...ndpost&p=498574 thesimpsons and I are working on the auto CD Eject technique using an .EXE file I found; however, BartPE may have the CD door closed until it's completely out of memory which may stop the .EXE file I found from working. I may look for a registry hook to see if we can run any the CD eject.exe after BartPE releases it's death grip on the CD tray! If not it may be time for an enhancement request to the man himself Mr. Bart Lagerweij... Hope this helps.

Haven't used WinPE (yet) even though my company is a Microsoft Gold Certified partner and I have both the 2004 & 2005 copies of WinPE on my desk. I opted for PEBuilder to create the BartPE environment instead. http://www.nu2.nu/pebuilder/ You pretty much have to be a Microsoft partner, have a Windows Software Assurance contract, or be a Microsoft powered University to get a copy of WinPE legally. (well at least last time I checked) Which is why Bart created PE Builder (his company didn't meet any of these criteria which is true for most of the world's users of Windows I suspect). It's interesting to see the mega sized corporations that have choosen BartPE (when you know they could afford to buy any PE solution they wanted) Check the Donated Hardware list on this page http://www.nu2.nu/thanks/bart/#hardware I realize from your original post you cannot rely on non-commercial free-ware type software solutions so I would say give WinPE a go. There are plenty of others on the MSFN forum with tons of WinPE experience. Remember the trick to making this work relies on if the SMBIOSD.EXE can successfully read the Type 1 BIOS information to display the model name of the computer. So a first step would be to run SMBIOSD or SMBIOSW on your target models to make sure they display the model name. I have already found one Intel server that SMBIOS won't read the model name from. But have had good luck on the PC's I have tried this on. Update on 4/27/2006> I found this was because Intel doesn't build "systems" only "parts" so they don't publish Type 1 BIOS data that says the name of the system, instead look at Type 2 BIOS data (Base Board Information) and use the Product Name of the mother board...check the image below! With the board name D875PBZ I can still determine the chipset driver that needs to be installed. For boards that have built-in video, sound, nic, etc knowing the mobo name is enough to automate the install of all drivers and apps.

I was thinking he could make more of a single image that installs the correct drivers and applications based on the computer model info from a GUIRUNONCE after the RIS screens. It is also possible to boot a PE environment like WinPE or BartPE and run the biochoice.cmd script from there. In this scenario the correct Windows image could be launched for install from the PE environment instead of by the RIS screens. I currently do something similar by PXE/RIS booting BartPE and having a simple menu of options available that runs from a menu.bat script from a network share.

thesimpsons wrote> What is the best way to script if I have different type of Dell workstations and want to get the disired images based on the type of workstation? Thanks again. Ok I saw another user post the same question about how to determine the model of computer from the command line so as to be able to automate driver and application installation so I decided to put some effort into it and here is what I came up with... Your going to love this it's too cool! B) Check my post here http://www.msfn.org/board/index.php?showto...9entry498859]

Drakhan wrote> I would prefere a simple script that would do what I originally wrote. A similar question was asked by another forum member in a dicussion thread I have been participating in and he suggested using a tool called PCI Scan from Bart's Utilities page; http://www.nu2.nu/utils/ Only one problem, it only runs from DOS (old DOS 6.x I think) so I don't think it can be used from the CMD window (new DOS) in XP. However, I have also on occasion wanted to be able to identify the model of hardware to run particular scripts so I decided to expend a few mouse clicks and neurons on Google and found a utility that is able to run from the command line and will return the BIOS identification information. This would seem to make it possible to write a .CMD or .BAT script that would compare the BIOS id with an IF statement to branch and then call the appropriate driver and application install scripts. Download the SMBIOS tools here: http://desktopengineer.com/story_20050215082742328 Looks like it's the SMBIOSD link (D = DOS) that we are interested in using in our XP .CMD script; however, the SMBIOSW (W = Windows) version is fun to play with to learn what can be read from the BIOS of a particular system (if Windows is already installed). So this windows version will give us a way to find the BIOS id computer model information to use in the .CMD script. Here's an example of the information I got when I run SMBIOSW and clicked on the "Type 1: System Information" link of the lower left window pane: Ok I got a little geeked out and played with the DOS version and got this far with it... Look for the line (near the bottom) in the bios.txt output file that says "Product Name:" I think that's what your looking for! D:\>smbiosd /T:1 > bios.txt D:\>type bios.txt SMBIOSD -- Version 3.10 (C) Copyright 2000-2004 Qualitas, Inc. All rights reserved. ======================== SMBIOS Header ======================================== SMBIOS header is present at segment F043h. SMBIOS Signature: '_SM_' SMBIOS Checksum: 8Ah. SMBIOS Struc Table Length: 31. SMBIOS Revision #: 2.3. SMBIOS Maximum Struc Size: 244. SMBIOS Entry Point Revision: 0. SMBIOS Reserved: 0000000000. ========================== DMI Header ========================================= DMI header is present at segment F044h. DMI Signature: '_DMI_' DMI Checksum: E8h. DMI Struc Table Length: 2473. DMI Struc Table Address: 000F0450h. DMI # Strucs: 72. DMI Revision #: 2.3. ══> Type 1: System Information Struc length is 25 bytes. Struc handle is 0100h. Manufacturer: Dell Inc. Product Name: Precision WorkStation 380 Version: (none) Serial Number: 6CJWT91 Universal Unique ID #: 44454C4C4300104A8057B6C04F543931 Wake-Up Type: APM Timer Ok at this point I got real geeked out because I realized this was now easy to do (so in MSFN.org style I just had to make a fancy example of how to do it) The biochoice.cmd script I created below runs silent without any visual output, but does pipe relevant output to the biochoice.log file. Just make sure the SMBIOSD.EXE command-line program is in the same directory as this .CMD script or edit the path to call SMBIOSD.EXE from whever it's at on your PC. I haven't tested the SMBIOSD.EXE with many systems yet (you will all have to help) but if it works on a wide enough variety of PC's then this may become a new option for unattended installs! @ECHO OFF REM *** Delete old biochoice.log file if one already exists... IF EXIST biochoice.log DEL /Q biochoice.log ECHO.********************************************************** >> biochoice.log ECHO.BIOCHOICE.CMD >> biochoice.log ECHO. >> biochoice.log ECHO.Used to identify a computers model name from the BIOS >> biochoice.log ECHO.via the command line to make application and driver >> biochoice.log ECHO.installation by model possible for unattended OS installs. >> biochoice.log ECHO. >> biochoice.log ECHO.Example script by Indy_DBA posted to MSFN Forums, >> biochoice.log ECHO. www.msfn.org on April 26, 2006. >> biochoice.log ECHO.********************************************************** >> biochoice.log ECHO. >> biochoice.log REM *** Dump BIOS Type 1 information into a file, this should include the "Product Name:" line REM *** which should be the model of your computer, for example: REM *** Product Name: Precision Workstation 380 ECHO.Extracting computer model information with SMBIOSD.EXE... >> biochoice.log smbiosd /T:1 > bios.txt REM *** Lookup the model of computer in the bios.txt file, then check the errorlevel REM *** of the FIND command to determine if this model is contained in this bios.txt file ECHO.Looking for a known computer model... >> biochoice.log find "ACME GameBlaster 3000" bios.txt if not errorlevel 1 goto Install-GB3000 find "Precision WorkStation 380" bios.txt >> biochoice.log if not errorlevel 1 goto Install-Precision380 REM *** Write out an error file if no computer model found and then end program echo.ERROR: No drivers or apps installed! Computer model not found by the biochoice.cmd script. >> biochoice.log GOTO End-of-Program :Install-Precision380 ECHO.Model Found: Executing install for Precision Workstation 380... >> biochoice.log REM *** Call scripts to install Driver & Apps for the Precision Workstation 380 GOTO Common-Block :Install-GB3000 ECHO.Model Found: Executing install for GameBlaster 3000... >> biochoice.log REM *** Call scripts to install Driver & Apps for the GameBlaster 3000 PC GOTO Common-Block :Common-Block ECHO.Executing Common install block... >> biochoice.log REM *** Use this section to perform any tasks common to all computers GOTO End-of-Program :End-of-Program ECHO.END of program reached... Have a nice day! >> biochoice.log EXIT /B Here you can see running the BIOCHOICE.CMD script isn't very exciting until you dump out the BIOCHOICE.LOG file... In this example the computer model name matched a known model and called the appropriate sub-routine to begin driver and app installation. Note the script skipped over the GameBlaster 3000 model because it didn't match the information in the BIOS.TXT file. D:\>biochoice.cmd D:\>type biochoice.log ***************************************************************************************** BIOCHOICE.CMD Used to identify a computers model name from the BIOS via the command line to make application and driver installation by model possible for unattended OS installs. Example script by Indy_DBA posted to MSFN Forums, www.msfn.org on April 26, 2006. ***************************************************************************************** Extracting computer model information with SMBIOSD.EXE... Looking for a known computer model... ---------- BIOS.TXT Product Name: Precision WorkStation 380 Model Found: Executing install for Precision Workstation 380... Executing Common install block... END of program reached... Have a nice day! In this example the computer model was not found so an error was reported and the script aborted. D:\CRS\Temp\smbiosd>biochoice.cmd ---------- BIOS.TXT D:\CRS\Temp\smbiosd>type biochoice.log ***************************************************************************************** BIOCHOICE.CMD Used to identify a computers model name from the BIOS via the command line to make application and driver installation by model possible for unattended OS installs. Example script by Indy_DBA posted to MSFN Forums, www.msfn.org on April 26, 2006. ***************************************************************************************** Extracting computer model information with SMBIOSD.EXE... Looking for a known computer model... How do you like them apples?