WreX

I configure my BCD to boot a WIM into RAM from C: and NTLDR from D:, but I was able to add lines to my BCD creation script to add another entry for booting a separate WIM on C: into RAM and it worked no problem. Here's my script: bcdedit -createstore C:\TEMP\BCD bcdedit -store C:\TEMP\BCD -create {bootmgr} /d "Boot Manager" bcdedit -store C:\TEMP\BCD -set {bootmgr} device boot bcdedit -store C:\TEMP\BCD -create {ramdiskoptions} /d "RAM Disk" bcdedit -import C:\TEMP\BCD bcdedit -set {ramdiskoptions} ramdisksdidevice partition=C: bcdedit -set {ramdiskoptions} ramdisksdipath \BOOT\BOOT.sdi for /f "tokens=3" %%a in ('bcdedit -create /d "First WIM" -application osloader') do set guid=%%a bcdedit -set %guid% device ramdisk=[C:]\BOOT\BOOT.WIM,{ramdiskoptions} bcdedit -set %guid% path \WINDOWS\SYSTEM32\BOOT\WINLOAD.EXE bcdedit -set %guid% osdevice ramdisk=[C:]\BOOT\BOOT.WIM,{ramdiskoptions} bcdedit -set %guid% systemroot \WINDOWS bcdedit -set %guid% winpe yes bcdedit -set %guid% detecthal yes bcdedit -displayorder %guid% -addlast for /f "tokens=3" %%a in ('bcdedit -create /d "Second WIM" -application osloader') do set guid=%%a bcdedit -set %guid% device ramdisk=[C:]\BOOT\BOOT2.WIM,{ramdiskoptions} bcdedit -set %guid% path \WINDOWS\SYSTEM32\BOOT\WINLOAD.EXE bcdedit -set %guid% osdevice ramdisk=[C:]\BOOT\BOOT2.WIM,{ramdiskoptions} bcdedit -set %guid% systemroot \WINDOWS bcdedit -set %guid% winpe yes bcdedit -set %guid% detecthal yes bcdedit -displayorder %guid% -addlast bcdedit -create {ntldr} /d "Microsoft Windows XP Professional" bcdedit -set {ntldr} device boot bcdedit -set {ntldr} path \ntldr bcdedit -displayorder {ntldr} -addfirst bcdedit -default {ntldr} bcdedit -timeout 5 bootsect /nt60 C: IF EXIST C:\TEMP\BCD DEL C:\TEMP\BCD Some key things I have that you don't: bcdedit -set {bootmgr} device boot bcdedit -set {ramdiskoptions} ramdisksdidevice partition=C: And reference the C: partition instead of BOOT Hope this helps.

I think your problem is your Run commands and the ()'s. I think it should be: objWShell.Run "%comspec% /c imagex /apply " & ColDrv & "\Sources\WinXP.wim # c:",0, True

You could experiment with what shows up in WMI in the Win32_NetworkAdapter class and see if the adapters that are listed with the lower DeviceID or Index values correspond to how Windows Server 2003 detects them. You might luck out and find that the lower-numbered adapter actually gets the first "Local Area Connection" title.

Our base image is the standard single CPU HAL, but I use a separate WIM file (or any format of your choosing) for the HAL.DLL and NTOSKRNL.EXE for multi-CPU devices and install those files after applying the base image but before rebooting to Sysprep.

My first comment is to be sure you have the NTLDR files (NTLDR, NTDETECT.COM, and boot.ini) in the root of the primary active partition (probably C:). My second is that you have "{ntldr} device partition=" and I think it should be "{ntldr} device boot". Here's my batch file for booting a PE WIM on C: into RAM and NTLDR: xcopy %CDROM%\BOOT\*.* /e /f /y C:\BOOT\ copy %CDROM%\BOOTMGR C:\ copy %CDROM%\SOURCES\BOOT.WIM C:\BOOT\BOOT.WIM IF EXIST C:\BOOT\BCD DEL C:\BOOT\BCD IF NOT EXIST C:\TEMP MD C:\TEMP IF EXIST C:\TEMP\BCD DEL C:\TEMP\BCD bcdedit -createstore C:\TEMP\BCD bcdedit -store C:\TEMP\BCD -create {bootmgr} /d "Boot Manager" bcdedit -store C:\TEMP\BCD -set {bootmgr} device boot bcdedit -store C:\TEMP\BCD -create {ramdiskoptions} /d "WinPE" bcdedit -import C:\TEMP\BCD bcdedit -set {ramdiskoptions} ramdisksdidevice partition=C: bcdedit -set {ramdiskoptions} ramdisksdipath \BOOT\BOOT.sdi for /f "tokens=3" %%a in ('bcdedit -create /d "WinPE" -application osloader') do set guid=%%a bcdedit -set %guid% device ramdisk=[C:]\BOOT\BOOT.WIM,{ramdiskoptions} bcdedit -set %guid% path \WINDOWS\SYSTEM32\BOOT\WINLOAD.EXE bcdedit -set %guid% osdevice ramdisk=[C:]\BOOT\BOOT.WIM,{ramdiskoptions} bcdedit -set %guid% systemroot \WINDOWS bcdedit -set %guid% winpe yes bcdedit -set %guid% detecthal yes bcdedit -displayorder %guid% -addlast bcdedit -create {ntldr} /d "Microsoft Windows XP" bcdedit -set {ntldr} device boot bcdedit -set {ntldr} path \ntldr bcdedit -displayorder {ntldr} -addfirst bcdedit -default {ntldr} bcdedit -timeout 5 bootsect /nt60 C:

You can even use WMI in VBScript if you want to over-complicate things. Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate,(Shutdown)}!\\.\root\cimv2") Set colWinVers = objWMIService.ExecQuery("Select * from Win32_OperatingSystem") For Each objWinVer in colWinVers objWinVer.Reboot() Next

I highly doubt it stands a chance. PE doesn't include a printing subsystem, so even if you were somehow able to get drivers installed for it, the only way I think it would work is if the vendor wrote a specific printing application for PE. In fact, I had to write special code into my HTAs to prevent CTRL+P from being pressed as it would crash my script execution and allow the user to get out of my locked down GUI.

I use my batch code in a .bat file called by \Windows\System32\startnet.cmd so it runs at start up and before any of my other routines are launched.

Yes, they were DLLs needed by the specific applications. Things like COMDLG32.OCX and MSVBVM60.DLL. As far as bloating the CD with files, I have yet to really notice any difference in load time as it relates to the size of the WIM.

If you added Scripting to your PE image, see what kind of message you get back using VBScript to map the drive. Set objNetwork = CreateObject("Wscript.Network") objNetwork.MapNetworkDrive "O:", "\\SERVER_NAME\SHARE_NAME",,"USER_NAME","PASSWORD" If you want to use variables for anything, don't use the double quotes.

I had to add and register (with regsvr32) a collection of common VB6 DLLs in my PE image to get some of our VB applications to run. You can download a set from M$.

I'll assume you're using NTFS, so the first place to start is NTFS permissions. Another thing to keep in mind is to maintain a "pure NTFS" environment when working with your WIM. Capture to an NTFS partition, only mount and unmount to NTFS partitions, and only deploy to NTFS partitions.

I'm still focused on getting an answer / resolution to this that doesn't require a script to be run after the boot loader is busted. I've been struggling the last few days to get setup for M$ phone support, but I should be able to find out what they have to say in the next few days. On a related note, I've noticed some interesting behavior around this whole scenario: Boot PC to PE, partition and format hard disk with the following diskpart script and allow the load to complete: select disk 0 clean create partition primary size=#### active assign letter=C: format fs=NTFS label="NAME" quick create partition extended create partition logical assign letter=D: format fs=NTFS label="NAME" quick After Sysprep runs on the PC, the option to boot the WIM on C: into RAM is broke. However, if I run my same routine again, but exclude partitioning the drive and simply format D: with diskpart, my boot loader works every time, even after sysprep! select disk 0 select volume d format fs=NTFS label="NAME" quick So for whatever reason, it looks like after Sysprep has initially left its mark on C: and C: isn't subsequently touched, my bcdedit commands seem to stick. Hopefully this gives the M$ folks something to work with.

After you have a base WIM file (probably the winpe.wim file the WAIK walkthrough says to copy to boot.wim) after steps 1-5, you can just mount it with "imagex /mountrw PATH_TO_WIM PATH_TO_MOUNT", make any necessary changes, unmount it with "imagex /unmount PATH_TO_MOUNT /commit", re-copy it to the boot.wim location, and repeat the oscdimg command to re-build the ISO. No, I haven't tried my suggested method of editing that reg file and importing it to a mounted hive, I was just throwing it out there for experimentation.

Seems like after you have all the appropriate hives mounted you could just modify your reg file to compensate for their mounted location (just use replace in Notepad to replace something like HKEY_LOCAL_MACHINE with HKEY_LOCAL_MACHINE\MountedLocation\HKEY_LOCAL_MACHINE), import the reg, unmount and commit, and be done.

HTML Applications HTML Applications (HTAs) are full-fledged applications. These applications are trusted and display only the menus, icons, toolbars, and title information that the Web developer creates. In short, HTAs pack all the power of Microsoft Internet Explorer—its object model, performance, rendering power, protocol support, and channel–download technology—without enforcing the strict security model and user interface of the browser. HTAs can be created using the HTML and Dynamic HTML (DHTML) that you already know.

Yeah, I had to download fixntfs.exe since I'm not running Vista and it's not included with PE 2.0. It did nothing to the contents of my BCD. If I did "fixntfs -xp" I got the legacy loader, if I did "fixntfs -lh" I got my Vista loader configured as before. Basically, it's the same thing as doing "bootsect /nt52 c:" for legacy and "bootsect /nt60 c:" for Vista.

Unfortunately, fixntfs is for repairing the Boot Sector, which I have no problem with. That procedure is for when you run a legacy Windows text setup and it overwrites the Boot Sector to use the legacy boot loader. My Vista boot loader works fine, the problem is that one of its entries gets cleared of everything but its GUID after Sysprep runs.

Original boot.ini: [boot loader] timeout=5 default=multi(0)disk(0)rdisk(0)partition(2)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows XP Professional" /fastdetect After Sysprep: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows XP Professional" /fastdetect Windows is installed in D:\WINNT. I've tried removing the timeout line from the original but that hasn't made a difference. Keep in mind that boot.ini isn't my issue, the problem is that Sysprep is clobbering one entry in my BCD, but not the boot loader itself. The NTLDR stuff continues to function as expected.

I'm not well versed in Flash or XML, but if you build a PE image with the XML and Scripting add-in components you could probably accomplish what you need with a single HTA. HTAs give you the ability to display HTML code, but also to run VBScript or JScript routines within. It sounds like you don't really need all the fancy XML stuff at first, you just need to identify the file you want to retrieve from a server. You should be able to write an HTA that prompts for a serial number, finds a file with that name on a server, copies the file to the RAM drive, then calls your Flash App that uses that XML file as input.

For what it's worth, I can't even export / import my BCD. Here's what I've tried: 1) Boot PE from CD, partition, format, extract WIMs, reboot 2) Boot PE from C:\ via the boot loader, export the BCD via "bcdedit /export FILE_NAME", reboot 3) Boot Sysprep via the boot loader, let it do its reboot 4) Boot to PE from C:\ fails via the boot loader, so boot PE from CD, attempt a BCD import via "bcdedit /import FILE_NAME", but the boot PE from C:\ option remains bad 5) Boot XP via the boot loader and let it complete its imaging Perhaps this is a clue about what the problem is. Maybe the import fails because after Sysprep runs some data on C: doesn't match up with what's in the exported BCD and it refuses to acknowledge my past entry. I may have to enlist the big guns from M$ to figure this bad boy out.

I just use a batch file and diskpart to change the drive letter during my startup process because it was using a letter I wanted my hard drive partitions to use, but you can use the Win32_CDROMDrive.Drive instance as well. Batch to change the CD drive letter echo list volume > X:\ListCD.txt FOR /F "tokens=2,4" %%i IN ('diskpart /s X:\ListCD.txt') DO @IF /I %%j == CD_ROM SET CDROMVOL=%%i IF DEFINED CDROMVOL echo select volume %CDROMVOL% > X:\ChangeCD.txt IF DEFINED CDROMVOL echo assign letter=K: >> X:\ChangeCD.txt IF DEFINED CDROMVOL diskpart /s X:\ChangeCD.txt VBScript to find CD drive letters Set objWMIService = GetObject("winmgmts:\\.\root\cimv2") Set colCD = objWMIService.ExecQuery("Select * from Win32_CDROMDrive") For Each objCD In colCD ' If there are multiple CD drives, this loop will only set the variable for the last one listed strCDLetter = objCD.Drive Next

You can find posts listing what files can be removed from PE, but everything I've read about reducing the image size has not gained much in the way of load time. The way I figure it, it's completely dependent on the speed of the PC being able to stream the files or WIM into RAM. If you boot it from CD, it depends on how fast the CD drive can stream and the PC can process the loading of the files into RAM. Same with a USB stick. You would think that reducing the size of data being loaded would reduce the load time, but that doesn't seem to be the case. However, if loading into RAM from a hard disk, it's lightning quick, presumably due to the speed of the drive. I have a "preload" option in my system where the user can boot up the CD without a network connection, set whatever options necessary, then have the hard drive partitioned, formatted, and loaded with the bootable WIM copied to C: from the CD drive. The boot menu is then configured to load the WIM into RAM, so it's like booting the CD, but much faster. I did this because my automated process could potentially hit snags if required data can't be found through WMI and the user has to be prompted for it. This way, the boot time to the possible prompt is nowhere near what it would be from CD.

No problem. I've been up to my eyeballs in this stuff for weeks so I know what it can be like if you hit a wall. Lots of trial and error and visits with my good friend Google and MSFN.

You don't need to check for IPs starting with 0 as a Network Adapter without an IP will have a Null value for objItem.IPAddress. Also, you wouldn't display any IP information if the address was not in the specified subnets, so why not just display it no matter what? Other than that, everything works fine.