getwired

Unfortunately I don't. HTA never seemed to catch on the way MS probably thought it would... Though I use it regularly...

Both versions provide that error? You cannot use Server SP1 with PE 1.5 - it requires the 1.6 version of the build tools.

You should not choose option 3 - multibooting, unless you have more than one partition - or you will wind up with your Program Files and Documents and Settings directories stomping on each other.

Tweaking Windows to build it into a version of the product which you do not physically have is at best a EULA violation - regardless of whether you have the warmest of intentions. You have been chastizing everyone on the board for their reactions, which are the right reactions to have if they are not keen on getting themselves (or you) across a legal line with Microsoft... Let it go.

RIS does not use WinPE today, regardless of what architecture you are installing (though you can bootstrap WinPE from RIS, but it is generally much less efficient than the newly available PXE/RAMDisk functionality) - neither does ADS (which does not currently support booting WinPE) - and RIS supports X86, AMD64, and IA64 with RISetup, and X86 and AMD64 with RIPrep. As the SMS OSD does not support PXE booting clients (or even CD booting them), using the SP1 RAMDisk feature would be a totally new feature area for it, and as of yet I've heard no announcements of such.

Ah - depending on what you want, you may want to actually convert to HTA when/if you can - you can whip up a decent wizard under WinPE and ask the user for info from a relatively decent HTML UI.

THX - forgot about oformat...

I imagine it would be possible, I haven't used AutoIT much myself - but the infrastructure seems pretty simple. I'm not sure it would be terribly useful under WinPE, since most of the UI you will use under WinPE for deployment (in any automated way) is Windows setup or an imaging tool - most of which are scriptable anyway, and don't have much in the way of UI. Regarding BartPE, you are lucky to have a legal department with that much insight - given that BartPE basically has no license agreement, and puts you in a hazy legal place with the world's largest software company...

AMD64 can also install via RIS - so no, installation over the network doesn't require WinPE.

Note that there is also a Windows Server 2003 Deployment book (methods also apply to XP) from MS Press, with sections on WinPE, Sysprep, and RIS. You may also find that of some help.

Sorry chief. I'll be good. :-)

It should behave the same as Windows XP would. If that works, X64 with it should.

1: There are a handful of "handhelds" that run XP Embedded. It's utility in that size of device is limited in that it only supports X86-based processors (and only Pentium and newer at that) - a class of processors rarely (but sometimes) utilized in small devices. 2: "Then why doesn't MS make a gui tool to add features like Bart does? Because they don't want it to be easy to modify." No, there was no GUI made because there was no time, nor was it critical to do so for the audience for which WinPE was intended. Had nothing to do with obfuscating WinPE's ease of use. 3: "I showed you in MS's own words that it was to make sure WinPE was not used as a pirated OS. That was my point on this matter." Correct - it is intended to be used for preinstallation. Nothing more. Adding limitations to enforce that is perfectly in line with the rest of Windows XP/2003 where Activation became the norm. 4: "It is feature-less. It has no features except the recovery console in a Win32 enviroment. If you want Windows Scripting support, or HTA support you have to add it seperately, thus making WinPE feature-less... unless you add the features manually. (The way it was meant to be, I do not disupte this)." It has the features it needs for it's role. No, WSH, HTA, and ADO (the first of which should have been in PE to begin with) have to be hacked in - but they were added specifically to meet the needs of deployment scenarios - as was DFS, WMI, and several other features. A blank piece of paper is feature-less. WinPE has the majority of the features needed to do deployment. And was specifically designed to do so. 5: "It is by design too cryptic for the common customer..." That, is technically, correct. It is also by design that it is perfectly usable by the intended WinPE consumer. The point of my posts was to highlight the fact that nobody spent any amount of time trying to make WinPE hard to use. That didn't happen during WinPE's development.

That is correct - noreboot has existed since before WinPE - so thus only exists to "not reboot" the OS you are installing with.

Not possible.

No - it unfortunately cannot skip that phase of setup. Note that it's technically also not a "DOS part", the only part of Windows setup that can work with DOS is winnt.exe. The part you are talking about is called "text mode" and is running the Windows Kernel.

1: Windows XP Embedded is not used for handhelds. That is Windows CE .NET. Windows XP Embedded also isn't usually used for NAS devices, there are versions of Windows 2000 and Windows Server 2003 designed specifically for that. 2: The thought that WinPE was intentionally made "to be cryptic... for advanced users and MCSEs..." is, as I said, silly. Making something easy to use for consumers, and something easy to use for people who actually do deployments day in and day out are two totally different things. WinPE does a very good job for the latter case. That is by design. Mkimg.cmd is the only tool because for deployment, that's all you need. Something to build WinPE. From the command prompt then you can script any tool you need for deployment. You don't need a shell. You don't need sound. You don't need an RDP client... you need a 32-bit, simple user interface that can handle scripting. That's it. 3: Again, since WinPE was designed for deployment, and there is no deployment task on the planet that takes more than 24 hours, and no need for you to connect to WinPE, since it can connect to UNC's already, and it's a deployment client, not a server, it has limitations built into it. That doesn't speak to your point about it being arbitrary. It's not a server. It's a deployment environment, Windows Preinstallation Environment. Not Windows "Perfect for Everything" 4: It's not feature-less. It has the features - and has grown in each version to add more features - needed for deployment and recovery. WinPE comes with documentation. It's not huge. Most of it isn't rocket science for anyone to figure out if they've ever written a script of any kind before. I think the point I'm trying to make is that WinPE was not "intentionally made confusing" as you keep alluding to. Ease of use was intentionally "not driven down to a consumer level" because there is, was, and will be no need to do so. Consumers don't build scripted deployment or recovery solutions. They take their systems to a technician (who does), or buy consumer-focused recovery applications.

WinPE's shell IS the command prompt, so, yes. Shift + F10 always works during setup.

Re-read my post. It's not hard to use. If you are using it for it's intended purposes (deployment, recovery, and troubleshooting). No, it's not as easy as Paint, or even Word for that matter. And it wasn't designed to be hard to use - you're being just a little bit silly. It was designed to serve a limited role. If you want a Swiss Army knife that can do 1,001 things, depending on how you build it, again see my post above - That's what Windows XP Embedded was (is) for.

Uh - aside from winnt not being there, it works the same. Use a winnt.sif file and the CD. Yes, the best story is with WinPE.

Two things: 1: also add /makelocalsource /tempdrive:C: /syspart:C: to your winnt32 command to ensure it works properly. 2: Adding EXIT as the last command in startnet.cmd (right after winnt32) should just work, as it will exit the cmdprompt and cause a reboot. That's not working for you?

Not only does it extend the build time, but it results in a system that is not as efficient as if you had formatted it NTFS to begin with.

Longhorn's normal setup won't accept a traditional unattend file. Let me rephrase - There are no WIM dumpers or editors currently available that are reliable, or that work with the most recent builds of Longhorn.

you have to feed it to setup via the command line. No, there are no tools released today for editing a Longhorn WIM file.

Then all you need to do is the format step, omit all the diskpart stuff. And it's FORMAT C: /Q /Y /FS:NTFS You have to feed it a drive letter. :-)