Jazkal

You could run a hardware detection scan, and when on that hardware, have your script dismount the unwanted drive using mountvol.exe or some such. Not sure that will work, but I don't see why not.

because i want to install win2008 x64 using winpe You can do that from the x86 version of winPE. Doesn't require that you use x64. EDIT (I looked up the actual command for you): V:\x86\Std\sources\setup.exe /m:C:\OEM\$oem$ /tempdrive:C: /unattend:C:\unattend.xml /installfrom:V:\x64\Std\sources\install.wim /noreboot This is the command line I use. You use the x86 version of setup.exe, and use the /installfrom: switch to point to the x64 wim file.

Can I ask why you need to load x64 WinPE?

Personally, I use Autoit v3+ to write my applications for WinPE use. You can also use HTA, although it is a major PIA for anything other than small apps. If you have done any application development work on the Windows platform, you'll be able to pick up Autoit quickly. You need the main app and the scite editor from the downloads page here: http://www.autoitscript.com/autoit3/downloads.shtml The Autoit forums are very helpful, and you can find most things you need just using the search feature.

yes, you would need to mount the reg hive before you finish the winpe wim image.

Did you reboot the system after installing updates, and before running sysprep?

Are you adding the ghost image file to the WinPE WIM file or the DVD ISO file?

you have to register the vb6 dll's before running the app. Here is the list that I used to register before I switched to something better. regsvr32 %SystemRoot%\System32\asycfilt.dll /S regsvr32 %SystemRoot%\System32\comcat.dll /S regsvr32 %SystemRoot%\System32\msvbvm60.dll /S regsvr32 %SystemRoot%\System32\msvcrt.dll /S regsvr32 %SystemRoot%\System32\oleaut32.dll /S regsvr32 %SystemRoot%\System32\olepro32.dll /S regsvr32 %SystemRoot%\System32\scrrun.dll /S regsvr32 %SystemRoot%\System32\VB6STKIT.DLL /S regsvr32 %SystemRoot%\System32\msinet.ocx /S

Yes, you would need VB6 or earlier.

"and made sure to add the packages" What packages did you add, exactly?

Post should be in the "Windows NT4/2000/2003" forum. I can say this though. Win2k3 is much more sensitive to RAM issues than WinXP. Why that is, I couldn't say. But I have seen servers that will run/install fine with Win2k, XP, Linux, but if you put Win2k3 on it, it BSOD. And in all those cases, it was 95% of the time a RAM issue.

If you figure this one out, please let us know. Currently those of us using pxelinux to boot our winpe images, have to use a HTA or AutoIt3 GUI once it is loaded. Would be nice to be able to use other options via pxelinux.

HFSLIP.org You can do hotfixes and drivers, and winnt32 works

I switched to HFSLIP for my integration needs that involve winnt32.exe Still like nlite for cd/dvd installs though

Radimus, I'd bet 10 to 1 that it is a problem with your nlite source. They have always had issues doing winnt32.exe installs. Most of the user base for nlite does CD\DVD installs, so they don't get a lot of testing from the other side. I could be wrong, but like I said, I'd give you 10 to 1 odds that I'm not. ;-)

I suppose that could be possible. I have tried a multi image onto a uni box, but not a uni image on a multibox. I will give it a try. You create your image on a multi, and in your sysprep.inf file, there are settings that allow sysprep to switch between uni and multi as long as the box is the same HAL.

Your WinXp images don't need to be uni and multi, you can have one that will work on both. The WinXP image limitation is based on the HAL, and there is no easy way around it. The benefits of only having a single image isn't a function of WDS, it is a 'feature' of Vista\Win2k8.

The problem isn't with WIM, imagex will work fine on bartsPE or WinPE. I'll look around for the needed command to fix you problem. Edit: Try this program out: http://www.sysint.no/Nedlasting/MbrFix.htm MbrFix /drive <num> fixmbr {/vista}

I have this environment (10 DC's, HP's, Dell's and Wb's). A single image is possible, I know because I have one image per OS that works on all those platforms. But there are a couple of gotchas. 1) They have to all use the same HAL (If they don't, it is still possible, but not likely that you are going to be able to get that to work at your current level of knowledge), but most server grade hardware from the last 3 years or so all use the same HAL (I know that isn't universal, just what I've seen ussing mainline branded hardware from HP and Dell). 2) You can either have a single sysprep.inf with all your Mass Storage Devices (MSD) populated and rebuild your images every time you get a new MSD. 3) Or, you can use a tool called MSDInst.exe from the Microsoft Win2k3 OPK (You have to sign up as an OEM to get this). This will allow you to have a generic image (I create mine on VMWare with no extra MSD drivers), which you can do a hardware scan on the hardware, and then use the tool to inject the needed MSD Drivers into the laid down syspreped image. Once you have your images figured out, then you get to create your WinPE Image that will work on all your hardware. It would be possible to create a GUI that works in WinPE that would come up and allow you to input all the info you want, map a network share, lay down the image and then modify the local sysprep.inf file with the info from the input fields. Personaly, I use Autoit3 for my WinPE/Win2k3/Win2k8 scripting/GUI needs. My system is completely automated, and WinPE is loaded via PXE Good luck, you have laid out a large undertaking

That is probably your problem. diskpart/format on BartsPE isn't Vista\Win2k8 bootloader compatible (I could be wrong, but I'm pretty sure I remember reading about this problem on this forum before.)

Sorry, not much I can help you with. I use Winpev2.1 not BartsPE, and of the three ways to get this to work under "Cross-Platform Deployment", I used the last one on "Use an answer file for unattended installations." EDIT: Come to think of it, how are you preping the drives?

if you are using the setup.exe file from the x64 media, that won't work, as that EXE file is a x64 file, and won't run on Barts/WinPE (x86). I would think you would need the setup.exe from the x86 SP1 Vista disc. See what that does. EDIT: The instructions for doing this are in the docs for the WAIK v2.1 User's guide.

This may be a stupid question, but... What Vista Media are you using?

FYI: The AutoIt3 scripting language is easy to use and has great built in functions to do search and replace. I use it exactly for what you are describing here. The scripts can be compiled into native x86 or x64 EXE files, so they will work in any WinPE environment. EDIT: I put this Autoit script togeather to show you how you can load the hive, grab the computername, and edit your sysprep.inf file with the wanted computername. Of course there would be a number of steps between these, just showing you how it can be done. #Region;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_icon=C:\Program Files\AutoIt3\Icons\filetype2.ico #AutoIt3Wrapper_outfile=.\GrabComputerName.exe #AutoIt3Wrapper_Compression=4 #AutoIt3Wrapper_Res_Comment=Grab Computer Name #AutoIt3Wrapper_Res_Description=Grab Computer Name #AutoIt3Wrapper_Res_Fileversion=1.0.0.0 #AutoIt3Wrapper_Res_Fileversion_AutoIncrement=y #AutoIt3Wrapper_Res_LegalCopyright=© 2008 #AutoIt3Wrapper_Res_Language=1033 #EndRegion;**** Directives created by AutoIt3Wrapper_GUI **** #cs ---------------------------------------------------------------------------- AutoIt Version: 3.2.10.0 Author: Jazkal Date: 05/06/2008 Script Function: Grab Computer Name #ce ---------------------------------------------------------------------------- RunWait(@ComSpec&" /c reg load HKLM\PE-SYS C:\Windows\system32\config\system", "", @SW_HIDE) Sleep(500) $thisComputersName = RegRead("HKLM\PE-SYS\ControlSet001\Control\ComputerName\ComputerName", "ComputerName") RunWait(@ComSpec&" /c reg unload HKLM\PE-SYS", "", @SW_HIDE) IniWrite("C:\Sysprep\sysprep.inf", "UserData", "ComputerName", $thisComputersName)

I have not heard of this being done yet. They would need to get explorer working first, and then IE. I would think integrating a stand alone version of Firefox or other browser would be MUCH easier.