getwired

Why?

I'm not aware of any such changes. Network Neighborhood is functionally identical to Server 2003, which is functionally unchanged from XP, which, well, to be honest, hardly changed from Windows 2000.

There are still tons of new machines shipping without USB Flash Drive boot support. Unfortunately. And even those that ARE shipping with it are all too frequently shipping with 1.1 support in the BIOS, resulting in a really unpleasant - and unusable - experience. Given that the slowdown occurs over time, and isn't consistent, I would hesitate to blame the drive (optical or HDD) as that would be a straight-line performance hit, not a gradual decrease (usually a sign of growing memory usage).

The memory utilization of WinPE will be the RAMDisk size plus the size of the WinPE working set (~64-96 MB). How big is your RAMDisk ISO, and how much RAM do you have on the system(s)? What does the RAM utilization of Ghost look like over time? If it gradually grows, if the system has 256MB, you could be seriously straining the capabilities of the system... One other thing, I can't remember if that version is based off of PowerQuest technology or not - if not, you might want to take a look - PQDI always way outperformed Ghost in my experience. If that's the version based off of PQDI, well then you can disregard this. :-)

Duh. My bad. The ISO is at the root of the CD, and is called winpe2005.iso? Have you done any file removal, and was Server 2003 SP1 your source? So at the root of your ISO, you should have an I386 directory with the three boot files, and then winnt.sif and winpe2005.iso. Is that what you have? One other thing - in the example I have working, there is also one more line under [setupData] - Architecture = "I386" Do you have that as well?

I didn't see the step there where you build the ISO that goes inside - the one that becomes the RAMDisk? Did you do that? Does your winnt.sif point to it?

it's bootwim.sys Google searches will turn up little, since the WIM infrastructure isn't documented (nor is the ability to boot from them) - yet.

Not possible to have one app for all - not unless every BIOS vendor agreed on a format - doubtful. More and more BIOS vendors already provide the ability to update their BIOS's from within Windows - it's not hard to do. My Motion Computing Tablet more than two years ago, had support for that.

Not possible to have one app for all - not unless every BIOS vendor agreed on a format - doubtful. More and more BIOS vendors already provide the ability to update their BIOS's from within Windows - it's not hard to do. My Motion Computing Tablet more than two years ago, had support for that.

Um, need more info. Version of Windows? a CD you recorded? An original retail copy? What steps are you repeatedly doing that is resulting in this?

BTW, someone mentioned that it was okay to keep on a laptop if you have on your desktop. No - that only applies to Office. Windows = 1 system per licensed copy, no exceptions exist.

Alas, it cannot work like a CD in that manner, because of the way in which USB Flash Drives are enumerated at boot time (as a hard drive) - even in the 1.6 release of WinPE...

If you mean is there a way to hide textmode setup after restarting from WinPE, no - it has to happen when you are doing a full install, and there is no way to make it "prettier". Sky's the limit - you can create your own HTA, C/C++ or VB based UI for use under WinPE to do disk partitioning...

Not possible.

Not sure what backing you have for point 1. Updating a BIOS from Windows, if done right, can be as reliable if not moreso than DOS.

You may want to investigate WMI - documented on Microsoft.com. If you use the 1.5 or 1.6 versions of WinPE, you should be able to include WMI and discern whether a drive is there or not - and generate a custom GUIRunOnce dependent upon that.

Note that every version of WinPE released through the OEM channel had the mountain and the moon background. The only releases that didn't were the ones that went to ISV's and earlier versions of WinPE for enterprise customers. 1.6 is the latest, and should be used if you are building from Server SP1, and can be used if you are building from XPSP2 (though can't do it's RAMDisk tricks then). 1.5 should be used if you are building from XPSP2 or the original release of Server 2003. What are you using as your source media for mkimg? Usually when binaries won't run, there is a problem with the side-by-side assemblies in WinPE - most often caused by a mismatch of build tools to OS. But can be caused by other things...

It is also much faster to install from WinPE than from DOS, and platforms other than X86 (Itanium and X64) cannot be installed from DOS, only via WinPE.

Just as an aside, Mamba - the ADO support that buildoptionalcomponents adds is just for SQL - since that's all that natively comes with Windows. To add MDB (Jet) support has been done, but requires manually hacking in MDAC. Not fun.

You cannot build WinPE from Windows 2000. Not possible. Only XP Pro or Windows Server 2003 Standard or Enterprise.

All 64-bit versions of Windows are based on the Server codebase, not on the XP codebase, so Service Packs for all of them will arrive with Server 2003 Service Packs - not XP. A bad timing thing, but not a bad naming thing. XP is Microsoft's client OS, Server 2003 is it's server... Calling it 2003 Professional would completely confuse people more than just calling it XP 64...

As I understood it, FormatUFD is only going to be a part of the OPK - not a part of WinPE as most customers who aren't OEM's get...

You should always use the version of Sysprep that is released with the Service Pack or version of Windows you are using. That is the reason they are released, and that is the version that is tested with it.

Unfortunately I'm not aware of a digital version available from MS Press... :-( It is linked off of the MS Press website, and is called the "Microsoft Desktop Deployment Resource Kit".

That's why they have filtering... filter out the av. spysweeper, etc...