Albuquerque

Indeed, but phase has quite a few drawbacks including size, fitment restrictions and certainly cost. With the 6x00 Core 2 chips having a thermal design power of under 75W stock, a 225W pelt on water could give you some pretty decent temps and wouldn't be hard or expensive to rig -- especially considering the price of 12V switching power supplies these days. Not to say that pelted units don't have drawbacks either, but I'm thinking "on the cheap" and something I could do myself without having to teach myself about heat exchangers, gas pressures and proper pipe welding and soldering skills for high pressure containment.

Fortunately the Core 2 Duo processors are pretty cool running even on air. Still, cooler temperatures will net you faster speeds with better stability, less heat and potentially less power required. I'd love to see a water+pelt combo on a Core Duo setup.

Just for future posterity, I am going to echo the "Buy an IBM" response. If you've got the money, you almost can't go wrong with any one of their lineup. I had an IBM Thinkpad 600E from when it was brand new almost 10 years ago. It has been an excellent machine for everything; the battery finally died when it was about 8 1/2 years old. I bought a new battery online, upgraded the processor from a P2/333 to a P3/866, picked up 512mb of ram and a 60gb 7200 RPM harddrive and it's just like brand new again. My company also deploys nothing but IBM laptops; we have more than three thousand of them in circulation right now. I'm typing on an R50 with 2GB of ram and a 1.7ghz Banias processor; we've sinced moved on to T42's, T43's and now T60's with the Core Duo, 1GB of DDR2 ram, 128mb X300 video, 100gb hd, DVDRW, SXGA, 802.11abg, etc. Great boxes and actually not as expensive as I thought.

Glad to hear it It brings a bunch of new options to the table; I really don't know what I'd do without it.

This is exactly why I started my thread earlier -- so many people don't know this exists, but I see them fighting daily with "aftermarket" ramdisks that aren't always stable or can't be sized correctly without batch processes or other items. SDI is freakin' awesome; the only limit is a size restriction to 512mb of physical space or less. Still, if you have a ~500mb PE image after NTFS compression then maybe it's time to pare it down a little

Also a note -- when you build your SDI disk, leave plenty of extra room. Any empty space on your SDI image later becomes writeable room on your X:\ ramdisk. And if you're using compression (as you should) then anything written to that writeable space will also be compressed, effectively giving you even more space to use. This has helped me do so many things on my CD; one such example was "patching in" fixes from a network script. When I forgot to add a few pieces to make ADO work, I just updated the System32 folder and re-registered the DLL's on the fly.

I believe you need the ramdisk.dll file from a Server 2003 install; moving to a Server 2003 SP1 base OS would probably solve that problem and also give you several other cool upgraded options as well. Thing such as the Microsoft Scalable Network pack and other neat things The SDI file should be in the same ISO file that the rest of your completed PE files and folder structure are in. I'm not sure it can work any other way...

What version of the PE ODK are you using, and what base OS are you building this with? Example: I'm using the PE 1.6 ODK (July 2005) with a base OS of Server 2003 R2. Oh, and try renaming WINPE2005.SDI to something that fits an 8.3 naming standard -- such as PE2005.SDI

The only thing I can think of would be to make sure you're using the proper WINNT.SIF boot entry to load your SDI file with. It should read exactly this: [SetupData] BootDevice = "ramdisk(0)" BootPath = "\i386\System32\" OsLoadOptions = "/noguiboot /fastdetect /minint /rdimageoffset=36352 /rdpath=\I386\<yourfile.sdi>" Architecture = "i386" Notice the need for an I386 subfolder, and make sure NTDETECT and SETUPLDR.BIN are both in that I386 folder too.

As has been mentioned several times, it obviously needs repeating for the poster above who mentioned "Sata is faster..." A SATA drive is not faster than an equal IDE drive under any circumstances. You can purchase identical Western Digital 250GB 8mb cache 7200RPM drives in both SATA and IDE form. And when benchmarked, they perform identically. The only reason that a SATA drive would be faster than an IDE drive is if the internal mechanicals are faster on the SATA drive. And since SATA is a new standard, you find it only on new drives -- newer drives obviously will be employing newer spindle speeds, platter densities and drive head technologies versus drives that are older. That doesn't mean SATA is faster, it means the underlying technology that actually enables the drive to read and write data is faster.

I keep seeing more and more posts about retrofitting ramdisk functionality into PE , both Bart and Microsoft OPK builds. And I see these questions about getting a writeable ramdisk jammed in there too, along side the read-only PE ramdisk that you're forced to endure using the "normal" methods. Why aren't more people using the SDI method? Maybe you just don't know about it? Instead of loading an ISO of your PE image into ram, load an SDI image of PE into ram. This gives you the ability to have a writeable ramdisk as your X: drive with the rest of your PE system. The SDI file also supports NTFS compression on all files contained, so my 189mb PE image squishes down into a 140mb SDI file -- with 8mb of free space still available! And it boots just that much faster too... SDI is a file storage method used by Windows XP Embedded. You can download the XP Embedded toolkit freely from Microsoft, and since you're not going to use any of the actual OS components, then you don't have to worry about the license issues. The SDI tools are in the Windows Embedded AIK under the Utilities folder. All the rest of the details can be found HERE which is where I started. I'd love to hear some feedback from folks who are using this, or aren't using this and are thinking of making the switch, or folks who just hate it and wouldn't touch it with a 10-foot pole.

You can still rip out the QoS component to bypass that reservation, but it still doesn't support a lot of the hardware offload capabilities of modern network cards. The best I've been able to sustain on a tweaked and scrubbed XP Pro image is around ~800mbit on a gig connection, gig Intel Pro/1000MT network cards on a CSA bus and 9000-byte frames. I think the second time I tried a land-speed record with PE I was able to sustain 930mbit, and just didn't try any further. Using a Server 2003 base for your PE image also helps, as you can take advantage of several additional features that XP just doesn't come with. Great examples: NDIS 5.2, NetDMA, TCP Chimney, Selective ACK, among a ton of others.

Other than support for IPv6, I don't feel the network connection is the big enhancement for Winpe 2.0. The current version of WinPE 1.6 has quite sufficient network capabilities; I have been able to maintain consistently faster transfer speeds within WinPE than I could in any other full operating system. I have used a pair of Dell GX620's both loaded with WinPE to sustain more than 930mbit continuous network transmit speed between the two devices. I can't do that under XP under any circumstances...

I'm not really sure if the above poster was just trying to be funny, or what... I don't think it was a very good answer either way, as it was neither funny nor factual. In a nutshell, Microsoft has only provided a single method for people to boot a machine on an inexpensive non-PXE network and load an operating system from a server. This way was DOS, using old hokey floppies or bootable CD's. Dos is slow, it has a massive list of limitations, and a lot of recent tools just don't work on it any more. But since this was essentially the only way to get a machine on the network (again, in a non-PXE environment) it means that Microsoft had to support it, and any NIC hardware manufacturer had to build dos-based network card drivers to support it too. This sucks, and Microsoft finally relented. Windows PE is essentially their replacement for all DOS boot disk needs -- it can get your machine on the network and provide a 32-bit Windows compatible base for your various tools. It also provides a solid and much faster bsae for deploying other modern Windows OS'es. When I first moved our company from DOS-based boot disks to Windows PE, I received a lot of negative response about the boot times. Common complaints were: "Dos took like 10 seconds to boot my R50 to the network; PE takes like two minutes! Why are we going backwards?" and "DOS did everything I needed to do, why aren't you using it anymore -- Windows sucks cause I can't do stuff that I usually do" The reality was quite different, and it didn't take long for the technicians to see it. Pulling down our standard 2GB sysprepped XP image within DOS took about 15 minutes on a Thinkpad R50 with the gigabit network adapter, a gigabit network and only one logical (and gigabit-connected) network hop from the workstation to the hosting server (an HP DL380 with five 15,000 RPM U320 SCSI drives). Average speeds under DOS were ~230mb/min. Windows PE on the exact same piece of equipment would pull down that image in two and a half minutes. Average download speeds under PE? About 1400mb/min. It doesn't take a genius to realize that a two minute boot time is more than forgivable with a 600+% increase in download speed. Upload speeds were also improved, on the order of 250% and more depending on hardware config. It also paved the way for far more automation than was available in DOS, great examples: WMI queries for automatically detecting what HAL files to swap out on our XP sysprepped image, HTA application for launching our "build-o-matic" process that lays down our base application packages, far enhanced featuresets for automated ghosting to/from DVD/CD drives, offline defrag and checkdisk of NTFS volumes, you name it. Preinstallation Environment is only getting better in Version 2.0, which is what you're using if you DVD-boot your Vista CD.

Explorer is not an "easy thing" to add, to say the least. I'd suggest you get comfortable with a lot more of PE before going down that road.

You said you changed motherboards -- did you install the needed chipset drivers for that motherboard?

WinPE 1.6 (based on Server 2003SP1) works fine on my 7900GT without loading NVIDIA drivers, so I'm at a loss to tell you what to look for... Where is your WINBOM.INI file located exactly? Is it in the root of the X:\ drive, or is it in X:\i386? Edit: I had a thought... I know what you're probably missing: the drivers for your chipset. All the machines I support are based on Intel chipsets, and as such I've installed (via the DRVINST utility) every chipset driver that I'll ever need. Installing the chipset drivers also allowed several of my USB ports to start working, and also allowed access to Intel RAID devices too. I bet that's your real issue right there...

Vista does indeed calculate your CPU score based on all available physical and logical processors in your system. Hyperthreading helps, dual core helps more, quad core and beyond would help even further. So to answer your question: yes, that score does include your 2nd core.

You can most certainly add video drivers, in the exact same way you would install other standard drivers -- with the DRVINST utility while building your PE image. Current video drivers can be a pain because of all the "supplimentary" stuff that they also load, such as advanced control panels and whatnot. You may want to go looking for a driver snapin for BartPE or something, and then slightly modify it to fit your standard PE image.

Vista already has drivers for the Intel Pro/100 and Pro/1000 cards for 260/270's, and also has drivers for the Broadcom B57 nics found in the 280's and 620's. Sounds like maybe it's a different issue; how are you booting this PE image? Over PXE, with a cdrom, from the harddrive, from a USB device?

Do you have the Intel AHCI driver loaded on your WinPE image? I'm just throwing out guesses, but maybe that has something to do with it?

I've got a half-terabyte raid at home on a promise controller and I have no issues with booting. Maybe a BIOS issue on your motherboard?

I'm going to ask a "silly" question... Instead of making the client wait, why don't you instead start the session first? I ask because the GhostSrv executable will wait indefinitely until either a certain number of clients connects that you specify, or until a timeout period that you provide, or until you manually tell it to stop waiting. Starting the multicast server first would make far more sense than starting the clients first. And it would solve your issue too. So far as I know, there is no settable timeout period at the client side.

Yes, sorely against the rules. Asking for a product key that isn't yours = bad. I'd suggest you edit your post and just say "delete please"

LOL! Tell your mom it's probably a good idea, red-heads have attitude problems I think this all circles back around to making sure expectations are properly set. XP is a fine operating system to be sure; I use it on every production box in my household; to include my primary gaming rig and both my laptops. But one of those laptops dual-boots to Vista (current version: 5472) and one of my older workstations (dual P3/733, 512mb of ram, 120gb drive) uses it exclusively. Just as I replied earlier, I'm not going to buy Vista the day it comes out. I'm not going to try to convince anyone to be an early adopter; I would much rather buy the OS after it's had a year or so to mature. But I figure by the end of next year, it's going to be as ready as I want it to be. I'm sure Vista isn't for everyone, but eventually support for XP is going to stop. And when it does, you'll have a few options: Live with an "unsupported" OS, upgrade to the newest MS offering, or just bail out and go entirely in a different direction. Maybe by then *nix operating systems will be better?