Albuquerque

Definitely an advantage there. One thing I do miss is Ghost's multicast ability -- being able to image 100 machines simultaneously with essentially no speed loss is a nice thing to have.

I was able to put XIMAGE on my PE 2005 image and then make WIM images of my various software platforms. Worked like a champ, although it's still considerably slower than Ghost32 (but compresses far better than Ghost does)

Hey all, The BootCD I maintain for my corporation is based on ISOLinux, which is then used to launch either PE 2005, any number of Bios flash and firmware update disks, and a few diagnostic tools. I've not had any issues with it up to this point. However, I can't seem to link a Vista CD Bootsector to ISOLinux; it continually gives me "CDBOOT: Couldn't find BOOTMGR". I'm thinking it might be a CDFS filenaming issue (maybe it's looking for a JOLIET or ROCKRIDGE index or something??) but I tried too many times to be so certain. Anyone else have this working, or some other alternative option that they KNOW works? Edited: Wanted to specify the error exactly; my orginal post had the wrong verbiage...

I actually didn't follow those directions; I went the way of creating a "customized" PE image. I'm positive you're somehow not getting the WIM into bootable format with the commands they have you follow, so I suggest doing this instead: Make a C:\winpebuild\build directory Make sure you have a directory named C:\Winpe, with subfolders Sources\ and Boot\ Make sure bootmgr is in C:\Winpe Make sure the contents of the C:\Winpe\Boot folder match that of your bootable Vista CD Then do the two items below: ximage /apply C:\winpebuild\winpe.wim 1 C:\winpebuild\build (do NOT use boot.wim, use Winpe.wim) ximage /capture C:\winpebuild\build C:\Winpe\Sources\boot.wim "Description" /boot /compress max You'll now have a bootable boot.wim stored in the C:\winpe\Sources folder. Basically you can now do the OSCDIMG like you did before: oscdimg -n -b\\<CD path location>\etfsboot.com c:\winpe c:\winpe.iso

Come over to the Windows PE forum; we have the answer for you Ninja edit: Linked you to the wrong thread, oops! Fixed now, look for page three... Click!

I've yet to get XIMAGE 5308 to work right doing a /MOUNT or /MOUNTRW -- it never "sees" the files, although it never gives me any errors either. Bleh. I've come to the point where I just apply the damned thing and have it over with. I've also run into the problem with PEIMG telling you that the image was already prepped, and I've yet to be able to figure it out as it doesn't happen every time. I've found that if you do a few PEIMG /INF='s and /INSTALL's then it usually no longer bugs you about having already been through the /PREP mode. Usually. Sometimes. I guess this is why it's beta

Sammy, While he said it a bit quickly, Fizban has the answer. The problem is the last step of the Windows PE help file tells you to perform an XIMAGE /Export on the WIM file you created. Don't do that, because you lose it's bootable format. Just copy it straight into your Sources folder rather than doing the export. That'll fix your Winload issue.

Thought I'd offer a second alternative -- my company also has a few of the M200 units in our pile-of-stuff. We saw the pricetag on Toshiba's external cd/dvd rom and promptly gave them the finger. I thought I'd let you know that *any* USB cdrom seems to do the trick; I've booted it from several different USB cd/dvd roms I have laying around the office. But it's SLLLOOOOWWW to boot for some reason... I'm talking REALLY slow. A WinPE that's 90mb on SDI takes 3+ minutes to load into ramdisk, whereas it takes about 50 seconds on most any other piece of equipment in the office.

By ripping out almost every driver and INF file as well as a ton of unused DLL files, I was able to pare one down to about 67mb. This is of course without any networking support at all, no plug-n-play support, etc. This also includes compressing a multitude of files with UPX -- an inline file compressor that works on Windows DLL and EXE files. The bare minimum I've been able to get a "functional" PE image down to is about 90-ish megs. Basically it contains nic, video and storage drivers for all the devices my company supports, Ghost 8.2, a DOD-wipe utility that runs under Windows, a simple ghost file for making a machine DOS-bootable after DOD wipe, and a few mb of script files for the various functions our teams perform. I've also been using XPe's SDI compression methodology to squeeze a few more MB from files that are not compatible with UPX compression (such as NTLDR, the kernel files, HAL files, et al). I didn't really follow any online guides, I just started paring files out of the install and trying functions to see what I broke (or didn't break). It took me probably a few months to get it down to exactly the bare minimum...

Agreed. Perhaps you should make that suggestion to the Vista beta-testers so they can tell M$ about it. Being a Vista beta-tester, rest assured that I have mentioned it several times. Completely agreed. My folder structure isn't *that* crazy, it's simply by artist (or by compilation name if it's something like a soundtrack.) When my girlfriend's brother came up to ask me about that "Dance all night to this DJ" song he heard on the Coke commerical, it took me about ten seconds to go to My Music, Paul Oakenfold and then scroll through until I found Starry Eyed Surprise. Even though I knew the approximate size and almost the exact name of the file, it probably would've taken longer to allow Windows to search for it...

CONFIRMED! There is a HUGE (900mb) WINPE.CAB file on the root of the WAIK CD I just burned from the ISO. Unless Microsoft is a bunch of ruthless teasing bastards I'm pretty positive this DVD contains the PE 2.0 distro. I'm totally not sleeping tonight...

Downloading now; ~650kb/sec will take a short while.

I'm pretty sure the tirade you just launched could be turned right back around at yourself... I have several thousand files that are less than 100kb but are all quite important on their own. I don't want the granularity on my search to be "1mb or less" because I'd come back with far too many results. KB gives me the granularity I need for the files I deal with most often. In fact, just as a test, it took me six seconds to start calc, type in a file size in MB, then * 1024 and copy-paste that value directly into search. Is that too time consuming? If so, then I call tough s*** on you because it's your problem for being lazy. Arguably in the future, the best implementation would be to have a dropdown box that would allow specification of the major base-2 sizes: 2^10 (KB), 2^20 (MB) , 2^30 (GB) et al.

XIMAGE, the associated DLLs and the INF is on the February driver CTP disc here: \wdk automated deployment tools\i386\ You'll also need to copy xmlflt or something like that from the Vista install DVD under Sources. I threw it in my Windows\System32 folder just like the previous version.

Quick update/rant: what is it with Microsoft and their WIM versioning? The 5308 ximage is on the Feb CTP disc, but it's not able to mount the 5308 boot.wim or install.wim. What gives?? Grr... I'm stuck having to "apply" the entire package on a and burn up untold gigs of space. Why can't I just mount the damned thing? /rant

I'm not going the MININT route; I'm going the I386 route as to avoid having to fight with registry entries. Maybe I should go the other way? Dunno... You're getting a very similar error to what I ran into. Just today I finished downloading the 5308 ISO file; I'm trying again with the newest files from this release. I think my failures are coming from Winload.exe and/or Wininit.exe at this point, as it looks like these two replace the NTDetect.com when launching "older" operating systems with the new bootloader. The other issue is getting the WIM filter driver (fltmgr + wimfsf + fbwf) loaded as early as possible in the boot sequence as either a bus extender or boot bus extender. I'm hoping the 5308 file versions of WinInit / WinLoad and the WIM filter driver will have better support for the older OSes. I may also gain some additional help by way of the BCDEDIT utilty. I don't want to give up on this; I'll keep everyone posted.

If you're using IE as your default browser, we did this thru Group Policy... Create a "false proxy" in the internet settings. If you need your clients to access internal websites but not external ones, then enter your domain name into the exception list (do not use proxy for these addresses) Doesn't work if your client installs a 3rd party browser though. Depending on the email system you use, you could likely block port 80 by way of a software firewall.

Sweet! Time go to download it; maybe the answer will be in there... Thanks for the heads up! Edit: It's not on the MS Connect website; where did you see it? Also, I believe I've found the problem that GetWired2 was suggesting, but I'm running into a problem now with PE2005 complaining that specific SYS files are corrupt. I'm starting to get this whole "reading at different levels" concept, and I think I've fixed one layer and then run straight into another broken layer. I think...

Fizban2: The PE 2.0 ODK isn't out yet; it was delayed and does not yet have a release date (as of this last Friday when I checked with our Microsoft TAM). PE 2.0 is cool; but I'm going to stick with the "known good" PE 1.6 (2005) until Vista is really 100% final. That still doesn't stop me from working with the compressed WIM format to get my current PE discs booting faster. GetWired2: Aha, I think I know where you're going. Got me an idea... Thanks I think

Quite a bit of misinformation in here... Multiprocessor kernel detection Contrary to what seems to be popular belief in this thread, Windows XP can and will detect the presense of and install the proper ACPI Multiprocessor HAL for SMT and SMP capable processors during the install process. This is painfully simple to test: perform an XP install on any AMD or Intel dual-core processor (or an Intel hyperthreaded processor) and simply watch what happens. However, it is worth noting that if you already have built the operating system and upgraded to an SMT/SMP processor package without a reinstall, XP will not change the HAL by itself. Multiprocessor Affinity It's odd that someone would argue that affinity doesn't exist without a 3rd party tool. Maybe you should start task manager, click on Help, click on Task Manager Help Topics, and look at the index. The second entry is, oddly enough, affinity. And it says this: To assign a process to a processor On the Processes tab, right-click the process you want to assign, click Set Affinity, and then click one or more processors. Notes The Set Affinity command is available only on multiprocessor computers. Using the Set Affinity command limits the execution of the program or process to the selected processors and might decrease overall performance. As for your comments on "core affinity", there isn't such a thing. Affinity is defined in two ways: process affinity and thread affinity. A "process" would be the entire application, say Prime. You can control the process affinity by way of Task Manager and in some cases by way of the application. Thread affinity would be in the indivudal worker threads that are spawned by a process to make it all work. Applications that are not SMP/SMT aware may not use all the available processor resources; this is a limitation of the application and not the operating system. Windows NT5 and higher are all quite aware of the processors given to them and they are able to manage the threads and processes across all logical and physical processors in the system. Your contention that the OS doesn't spread it's own threads across all processors meaning it's less-performance is questionable at best. In reality, how much processing power does your OS consume at any given time? Hopefully very little; my CPU useage stays somewhere between 0 and 1% -- even when looking at kernel load. There's not much need for the OS to start throwing its threads all over the available processors; leave those resources for other applications that can use them. Hard drives are limited to 60mb/sec Sure they are, if you're talking about 7200RPM IDE drives. Might want to reconsider for 15,000 RPM SCSI drives, or even 10,000RPM IDE drives. SATA can go faster than IDE drives, to the tune of 150mb/sec versus 60mb/sec Not. The SATA interface has a higher maximum burst speed than IDE by 17mb/sec (150 vs 133) but the actual data transfer speed from the drive is dictated by the physical construction of the drive itself, not the interface. You cannot lay down any generalization that says a SATA harddrive is "faster" than an IDE disk. PCI is limited to ~60mb/sec Not. PCI is a 32-bit 33mhz bus, which gives you 133mb/sec of bandwidth. There are also PCI-X components, as well as PCI-E options too. RAMDRIVE will make you go so much faster when compositing video Doubtful. When transferring RAW video from a digital device to your computer, it is quite possible to get bottlenecked by the data streaming capacity of your hard drive. But when doing video editing, you're using a TON of CPU cycles. This isn't a drive bottleneck, this is a CPU bottleneck. It's better to let your video application use that ram for buffering versus trying to overcome a non-existant disk bottleneck. It's also much better for that CPU to have all the bandwidth it needs to ram for doing that buffering, and not having to contend with bandwidth being soaked up by an unneeded ramdisk storing all that information. Talk about a busy northbridge... As for the actual root of this thread: Opteron 170 is a dual core processor at 2.0ghz, but one-ups the X2 with the additional 512kb cache. Combined with the overclocking potential, I say you're right on track. Buy the 170, crank up the speed and enjoy the extra performance.

Nope, that's not it. We can 100% validate the WIM is being read, because we're able to satisfy the "I need to find a SYSTEM file in the Config directory" when we do the copy-and-rename function. If it couldn't read, then it would still complain about the file being missing. Actually, if you think about it, that's not even right. If it couldn't read the WIM file, then where are the "NTLDR missing" and/or "NTDETECT failed" error messages? If you go look at my ISO file creation steps, take notice that NTLDR / SETUPLDR.BIN and NTDETECT are not on the raw ISO file -- they are contained only within the WIM. You also forget that adding WINLOAD.EXE and WININIT.EXE made a noteable difference to the behavior of the "destination OS" in my testing, whicih completely invalidates your suggestion that the WIM cannot be read. It's most definitely reading the WIM; I say it's still not getting the MININT flag. Next theory?

To answer your first question: The bootloader I ripped from the DVD, the BOOTMGR file and XIMAGE are all from the 5112 build. I know, because I personally ripped them out of the 3-pack of DVD's that Microsoft sent me in the last two months. I can build WIM'ed PE images of Vista all day without issue. To answer your second speculation: I'm convinced the "destination" OS is not receiving the MININT switch like it should. Hope you like the long drawn-out explanation, because I'm going to give it to you to ensure you understand exactly what I'm talking about. My first several tests with bootable WIM's came out the same way that everyone else's did: "NTDETECT failed". After some playing, I then upgraded to the next error: "This machine is no longer supported" and verbiage about not having an ACPI-enabled BIOS. A bit more research on failed boot sectors after "upgrading" with Vista gave me the idea to try WINLOAD and WININIT. Now I get the error about being unable to find the system registry hive (cannot find I386\SYSTEM32\CONFIG\SYSTEM). Here's where we discover what's going wrong: MiniNT installations don't keep a system registry file there, because they basically in the "Setup state" forever. But maybe you discount that theory, because maybe it's something to do with the new bootloader? Fine. We make a copy of setupreg.hiv (the system registry hive), move it to the Config folder, and rename it appropriately. We reboot our WIM file, and we get another error: License Violation. Wanna know why? Because the product ID is missing from the system registry hive. Why is this important? Because an OS starting in MiniNT mode doesn't look for (or require) a product ID in the system registry. Oops. Our operating system isn't running in MiniNT mode. The newer versions of VISTA provide the BCDEDIT tool which has extended support and functionality for other operating systems and passing of command line switches. This is why I'm posting this thread -- to hopefully find someone who wants to spend an hour of their time tinkering with BCDEDIT to see if we can finally get this answered. In a seperate subject but along this same line of thought, it turns out that I'm finally getting my own copy of Build 5270 afterall. It's still gonna be a few days before it's here though...

Doesn't work; BCDEDIT works in GUIDs for the "destination" operating system. The GUID for Vista (and the associated Vista PE) are different than the GUID for Server 2003 (and the associated 2k3 PE). I'll need someone who can actually manipulate BCDEDIT to create / manipulate this file and get both the appropriate GUID and default OS switches put in. It likely needs to have this file put into a \Boot folder inside the WIM rather than put into the raw Boot folder on the ISO. I really wish I had access to 5270 so I could just make this work and post it 100% for you guys

Yeah yeah, I'm a n00b to your site, but I don't think I qualify as a n00b to WindowsPE. So here's what I've done up to this point, and I think I know the one last step to get it 100% working. First, I'm using a customized Windows PE 2005 image (Win2k3 SP1) from the real Microsoft Enterprise Agreement package. Not hard, we all know how to do this. I'm building it in "CD" mode, meaning the base folder is I386 and not MININT. Then, I copied WININIT.EXE and WINLOAD.EXE from the Vista \Windows\System32 folder into the I386\System32 folder on my PE 2005 image. Don't forget this step! Next, I used XIMAGE to grab my PE image development folder, so that I have the WINBOM.INI, all those WIN51 files and the I386 folder in the root of my WIM. Maximum compression is actually the default capture method, so no real need to specify that at the command line. My previous WinPE images have been from SDI images, so my development folders are named PE_SDI(x). Example: ximage /capture C:\PE_SDI2 winpe2k5.wim "20060215" I use a date as my description (20060215); it's a component of how I do BootCD version checking in my company (so I can network-invaliate old CD's that have been superceded). You can use whatever. Then you will need to make that WIM bootable by specifying ximage /boot winpe2k5.wim 1. Obviously your WIM might be differently named than mine. Next, I ripped the bootsector off my Vista 5112 x86/32 DVD. I think I used WinImage to do it; can't 100% remember. It wasn't hard, there's a ton of free software that can do it for you. Just grab the first four sectors at offset x07c0 just like any other bootable optical media, you should get a 2kb file in return. Then, I created a new folder structure to hold my Vista PE files. I named mine C:\PE_Vista to hold with my previous "naming standards" hehe... In that folder, I have the following files and folders: Bootmgr (from the Vista DVD) boot.ini (we'll customize this in a minute) Sources (a folder) Boot (a folder) Drop your WIM file into the Sources folder, and drop Boot.SDI into your new Boot folder from the Vista DVD Boot folder. You do not need NTLDR or NTDETECT in there! Edit your boot.ini to look like the following: [boot loader] timeout=0 default=ramdisk(0)\I386 [operating systems] ramdisk(0)\I386="Windows Preinstallation Environment" /noguiboot /fastdetect /minint /usenewloader /rdpath=multi(0)disk(0)cdrom(0)\sources\winpe2k5.wim /RDSDIHDRPATH=multi(0)disk(0)cdrom(0)\boot\boot.sdi Yes, you DO want to "usenewloader", hence the reason you dropped in the WINLOAD and WININIT files. To actually build your CD, you can use MKISOFS, Roxio or OSCDIMG to create your ISO file basically like any other PE image you've done before. Just make sure you're using the Vista bootimage that you grabbed off the DVD versus your normal PE one. So, here's the problem: This doesn't 100% work. The reason? Boot it, and you'll see that it cannot find I386\System32\Config\System -- it's referring to the system hive file for your registry. Ok, so maybe you tell yourself you can just rename setupreg.hiv to system, move it to the Config folder and get around this issue? Sure, and then watch it bomb with a license violation because the product descriptor doesn't exist in a PE system registry hive The real reason it doesn't work is the Vista bootloader isn't passing the "minint" switch to the underlying OS. I am almost positive this is linked to (and can be fixed by) creative use of BCDEDIT in the later builds of Vista. Unfortunately, I'm stuck with Vista 5112 for various political reasons in my company, and don't have direct (legal) access to 5270. So the challenge? Someone needs to create a boot file using BCDEDIT (not a Boot.ini, that's all gone now) that acknowledges this boot image as a MiniNT OS and passes the proper switch. It can't be that hard; I'd do it myself except I don't have access to the proper OS. Someone want to take that last step for us all? As I understand it, BCDEDIT will place (or update) a file in the \Boot folder once you're done editing. This should be able to fix the switch issue, in theory...