joakim

So you suggest the difference may come from the fact that the combination xp/tftpd32/dhcp/pxe is not at natively supported feature on the server side? I understand that it would decrease the performance in an absolute and overall level. However in these tests all other variables are held constant, only changing the version of bootmgr.exe. The results are from repeated tests changing back and forth the version changes. And performance on each version are always the same, with rather large predictable differences on those mentioned versions. The combination of a chained grub.exe/iso was always the fastest, and beating all versions of a standard booted winpe. Maybe I'll create a dummy wds environment and look into this, if I get the time.. Joakim

Actually all that is on a windows xp host giving dhcp with tftpd32. The chainloader (pxelinux.0) is just there to produce a multi menu (menu.c32) as base for whatever to be tested and optionally further chained. Just like pxelinux.0 -> pxeboot.0 instead of serving pxeboot.X (or similar) directly over dhcp as the bootfile. Which makes it easier when you want to have other chainloaded solutions in the same menu. If you are using wds (which I'm not that familiar with), you will likely have some of the bootfiles (x.n12 or x.com) served on dhcp, which in turn loads bootmgr.exe for the actual network transfer and mounting of the wim. Since these bootfiles are not version-tied they can boot whatever version of bootmgr.exe, at least on my machine. Don't you notice any difference in performance when changing the version of bootmgr.exe? Particularly with the older versions mentioned.. As far as I know, bootmgr.exe don't care about what OS is inside the wim, as long as it is an nt6.x. Btw, how big are those winpe2.1/winpe3.0 images? Joakim

It is not supported and will not be possible to nativeboot in vhd with xp unless you come up with a brilliant patch for numerous xp binaries (also including the kernel). Joakim

If you trick the OS into believing the disk is unpartitioned, then nt6.x have nothing to lock and thus vmware will have complete control of the disk including the mbr. Did you read the thread? Joakim

I just noticed that newish bootmgr.exe now is significantly slower than previous versions when pxe booting. What I have come to conclude is that vista sp0 and longhorn performs much better than say server 2008 (sp1) and windows 7 rc1. Taking account for other things too, I would say the longhorn version (6.0.5259.0 in this case) is by far the best out of the 4 versions tested. Is this something others can verify as well? One thing is that other solutions boot winpe3 much faster than bootmgr.exe/wim over the same protocol (pxe/tftp). Another thing is that the newer bootmgr.exe performs much worse than previous versions. More details can be found at the later replies of this thread; http://sanbarrow.com/phpBB2/viewtopic.php?t=1705 Btw, the pxeboot.x can be from any version as they all boot all versions of bootmgr.exe. I may have missed something obvious and important, but I must say the results are rather strange.. Joakim

You could try to download the installer from microsoft.com. I am rather sure they have it there available for no charge. Joakim

Could this work better perhaps: initrd mcmcd/pxe.img kernel memdisk raw Joakim

For those still wondering about physical disks and nt6: http://communities.vmware.com/docs/DOC-10455 You can still use formatted physical disks as on nt5, but you will need a hack that in worst case may destroy your partition table unless you do it correct. Cannot say about latest version 7.1 though.. Joakim

Chainloading grub4dos over pxe, would require something like this in your default when using (g)pxelinux.0; LABEL some description MENU some description LINUX grub.exe INITRD win7pe.iso APPEND --config-file="map (rd)+1 (hd32); map --hook; root (hd32); chainloader (hd32)" You should then be able to easily boot your nt6 based recovery iso. You don't need to include any special ramdisk driver (only necessary for nt5), as the "wim" takes care of protected mode. But for simplicity's sake, if only regular pxe is wanted, then probably chainloading pxeboot.* -> bootmgr.exe -> boot.wim would be the least complicated to set up. Joakim

Memdisk is indeed handy for network booting certain stuff, as it can emulate iso. However chainloading grub.exe might give more reliable results for nt6 based iso recovery consoles. That said, it would be a lot easier to directly or through chainloading, boot pxeboot.0 and thus eliminating the whole iso emulating issue, as bootmgr.exe transfer and mounts the wim fine over tftp. Joakim

What is the OS of the recovery console? What kind of image is it put on? What is your initial bootfile (startrom, pxeboot, pxelinux, etc ..)? Joakim

The enhanced write filter (ewf) could give you a complete read-only system drive, but then again not even the LocalSystem would be able to write anything (unless committing changes when configured in disk mode). So maybe not.. Joakim

It seems like your're attempting to circumvent some corporate security policy.. Are you even allowed to execute the exe in your environment? What are you goint to do with the exe? Install something? Execute something on that work computer, or somewhere else? Don't forget you might be logged.. Joakim

Rumours have it that booting over HTTP outperforms TFTP in terms of transfer speed over network, but I've not yet seen comprehensive and detailed test results/measurements for this.. Joakim

A wim packed with maximum compression is rather hard to beat. I doubt you will find anything better.. Joakim

Could it possibly be easier to install an ssh server on the home machine. Then establish the tunnel and configure the application to use socks proxy (assuming it is a configurable option). Tip: port 443 sometimes works better in certain environments.. Joakim

The framework can be added to your running winpe without integrating it in the build; http://www.boot-land.net/forums/index.php?showtopic=8329 Depending on the type of ramdisk used and nt version, you must have some varying mb's of free space (in X:\) to make it work. Integrating it in the build, would require adding the files and the registry patch used (but these packages was made for the opposite reason). Joakim

Milli-seconds before forcibly shutdown (500 is maybe a bit low). Test it. Joakim

Try to merge this to your registry; Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control] "WaitToKillServiceTimeout"="500" Joakim

The path to your BCD store is hardcoded in bootmgr. Hexediting bootmgr is necessary to change this. Modification to a BCD in alternative location can, as already mentioned, be done with "bcdedit /store path_to_bcd". Joakim

I remember having read that vss was changed with server 2008 and later, so it must have all partitions ntfs formatted. Cannot find the source though, but believe no partition can be FAT*. Linux fs should be ok as it is seen as unallocated to windows. If it works fine when booting directly to bootmgr, why not install an nt6 bootsector in your mbr and chainload grub with a pointer to a bootsector in your BCD? Joakim

I made a LODR package that will let you run EASEUS Partition Master 4.1.1 Pro from PE's based on XP, 2003, Vista, 2008, Windows 7. No need to rebuild the bootcd. Just hotplug it and launch the loader. There's also a preparation tool included to prepare the necessary files. http://www.mediafire.com/file/wzgijzmdnjw/...Pro411_LODR.zip Joakim

Just want to share something I found yesterday. It may be an obvious thing that is widely known, but I have not seen it described anywhere. It is possible to boot bootmgr/ntldr/setupldr.bin with grldr.mbr. That would mean it is possible to chain between ntldr and bootmgr, without any third party bootloader. Here is a patched grldr.mbr that will search for and boot bootmgr; http://sanbarrow.com/phpBB2/viewtopic.php?t=1696 Joakim

It can also be useful to run procmon inside PE to trace missing stuff. Joakim

For those that do not know; winload.exe of version up to and including current Vista will automatically detect nt5.x (meaning you don't need ntldr and ntdetect.com). Which means BCD entries for nt6.x also works for nt5.x (not requiring {ntldr} or {legacy}). That is for non-PE though. Joakim