[X-Ecutioner]

Okay, I just bought that linksys network storage link which is bacially a NAS. It has 2 usb2 ports for 2 usb drives. I have migrated all my unattended stuff onto my 120gig (now nas) harddrive. I have seen that u can install from a network share with a bootdisk but that disk doesnt support ntfs. I have made a few winpe disks, but they take at least 5min to start up.

Basically, I want to create the smallest possible winpe disc that takes no time at all to boot into and allows me to run my unattended install from my network share.

Can anyone point me to a site that tells you how to create the smallest possible winpe image??

Thanks

-Matt


EDIT:--> The Linksys NSLU2 is a piece of crap. It literally took almost an hr to do the file copy phase for xp setup. It is good for large files but for small files it is horrible. The transfer rate is maxed @ 4.1mbps and small file rate....who knows. I recommend no one buys one of these.

This post has been edited by X-Ecutioner: 07 March 2006 - 09:50 AM

[mats]

Tried the docs?

There is a section about reducing the size in the pe2005 docs. I think you will get down to about 90 megs but you will have to re-add your nic driver

[fizban2]

95 meg is the best i was able to get the size down to. not sure if you can go smaller then that

[Albuquerque]

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...

[Xsss4hell]

Hi

The PE image you're talking about seems to be very awesome..


Can you make your PE image publicly available?? (you can remove sensible corporate data)
Or please tell us how you did all the stuff.
(I can host it if you want.)

THANKS =)

[Dumpy Dooby]

Dude! The NSLU2 is AWESOME!

http://www.google.com/search?q=NSLU2

You can hack that bad-boy and so many cool things with it. Print server, advanced firewall, web server, etc ... for only $80. Man, those things are so rad.

[Nuno Brito]

The smallest possible PE size at the moment is a 16Mb build based on bartPE - this project is named microPE and uses batcher (a program that runs script files)


You can easily build a microPE project around 40Mb - wich includes a bblean shell, network support and some other freeware applications like A43 file manager and a CD writer.


If you use Windows 2003 SP1/SP2 as the source for your bartPE - you can select the option to make your build RAM bootable.



The minimum size can be decreased much further - but you only get a command console window - with virtually no support for any other program - a simple winXP 32bit cmd.exe window that can still acess NTFS partitions


The scripts use a combination of UPX, MakeCAB and selective file removal to achieve better results, there's a forum at http://BootLand.pt.vu that just started up, where anyone can post questions on how to get this working..



I hope this helps you..

[twalk482]

Since there are many that have to use Windows PE, the microPE may not be an option. Although the microPE looks like a great tool.

If anyone has built some scripts to reduce the size of Windows PE a code cut & paste would be appreciated.

I am looking at the Bart/microPE output files to see if I can do a translation to get a resultant version of "microWinPE"

[Nuno Brito]

twalk482, on May 11 2006, 02:38 PM, said:

Since there are many that have to use Windows PE, the microPE may not be an option. Although the microPE looks like a great tool.

If anyone has built some scripts to reduce the size of Windows PE a code cut & paste would be appreciated.

I am looking at the Bart/microPE output files to see if I can do a translation to get a resultant version of "microWinPE"

I'm not using windows PE for my testings, but there is a tool I've used to cross compare files and folders to automatically create a script file from reduced PE versions.

Try going to http://nunobrito.100...ilematcher.html and download FileMatcher - this will surely help you to create a fast script to replicate your results with windows PE..

[twalk482]

Thanks for that ... checking into it now

[Albuquerque]

First: For anyone who wants to see what I do to knock my PE size down, visit my reply to another thread.

Xsss4hell, on Mar 7 2006, 08:06 AM, said:

Hi

The PE image you're talking about seems to be very awesome..


Can you make your PE image publicly available?? (you can remove sensible corporate data)
Or please tell us how you did all the stuff.
(I can host it if you want.)

THANKS =)

Legally, Microsoft doesn't allow distribution of 1.x PE images as you likely already know. Even outside of that, the PE image I develop also contains licensed and copyrighted software, and several components of the scripting contain sensitive corporate data such as service account passwords and information about our network topology. While the information is "encoded" to keep the general user populace out, it wouldn't be hard to disassemble As such, I'm sure you understand, I cannot host a file for your perusal.

However, I can give you the general gist of what I do:

I first use ISOLinux for the underlying structure of the CD. This of course allows me to put all the BIOS flash utilities, OEM standalone diagnostic software, WinPE and other items into a simple boot menu. I like ISOLinux because it's VERY straight forward and works on nearly everything I need.

Within PE, I've developed two "tiers" of scripting -- one part on the CD, one part that resides on multiple servers in our environment. The CD portion does the following:

• Boot to Ramdisk from SDI, Enumerate PnP, start networking
  
• If the CD is still in the drive, it's ejected so the tech doesn't forget
  
• Query for available NIC cards, then query for link, then query for IP address and connection speed
  
• If a NIC is not available, it flips to "CD Only" mode (see further below)
  
• It correlates the local IP against an INF file that identifies "parent" servers for scripting (supports definition of class A, B or C subnets, references a domain to authenticate against, parent server name, upload directory for imaging, download directory for script files, among a few other items
  
• It performs a version check -- all my SDI images are named with a unique ID that correlates to that CD release. If that unique ID is not "allowed" on that parent server (outdated, only for testing use, whatever) then it disconnects the network, stops the workstation service and deletes from ramdisk some fundamental files needed for network functionality. Long story, but this became a requirement a few years ago and has worked well
  
• Once the CD version checks out, it copies the network script files to a temp directory in the ramdrive and then starts the primary network script from that temp location (I do not run them directly from the server; this gives me the ability to perform network script updates without "killing" a CD that may be currently using said scripts)

The "CD-only" scripting provides an easy interface for three levels of physical disk wipe + make DOS bootable, ghost physical disk to/from CD/DVD, offline checkdisk of a HDD volume, offline checkdisk of a HDD volume, and a few other items such as dropping to a command prompt.

The "network" code does some further items, such as the following:

• Detect hardware type. This allows me to spawn seperate core menus for working with servers versus workstations. Also allows other scripting branches later for devices that may need it (VMWare machines for enabling acceleration, tablet PC's, IBM Thinkpads that need our special "bios fix", et al)
  
• Ghost options (upload to parent server if available, download standard 2K or XP image, download a previously uploaded image, join a multicast session)
  
• It also allows access to the "CD Only" menu, and access to a few other little utilities such as hosting a GhostCast server, ghost explorer, regedit, notepad, et al.

That gives you the REALLY high level version of what my CD does. Since I'm using the legitemate Microsoft PE tool, I don't have the luxury of "snapping in" a bunch of cool tools that are already provided. However, with only a small bit of work, you can "convert" essentially any BartPE snapin to work with the real PE. And why not, since they're the same damned OS anyway?

This post has been edited by Albuquerque: 12 May 2006 - 08:19 AM

[JuMz]

Wow. Absolutely awesome. You should write a guide...*hint* *hint*

[Albuquerque]

I'm not very sure that a guide would help; most of this stuff isn't something you can just "snap in" and go. The massive quantity of scripting I've generated has simply evolved to this point from many previous years of combined DOS and recently WinPE bootable CD work.

And in fact, I'd rather give a person the big picture and let their brain figure out the best way to do it in their environment. Some of the complexity I have built into my scripting is simply because of the complexity of my environment. Someone who doesn't need the entire scope of my scripting functionality would have way too much to look at; someone who needs even more would probably get a headache looking at my code

Our environment is up for a pretty large change in how we build workstations; we're still utterly dependant on Ghost images and we've got some ugly machine dependancies going on. It's time to move to dynamically created unattend.txt files generated from XML pages, WMI queries and voodoo magic