• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
Sign in to follow this  
Followers 0
X-Ecutioner

Smallest Possible PE Size?

13 posts in this topic

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.

Edited by X-Ecutioner
0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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 =)

0

Share this post


Link to post
Share on other sites

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

:lol:

0

Share this post


Link to post
Share on other sites

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"

0

Share this post


Link to post
Share on other sites
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.100free.com/filematcher.html and download FileMatcher - this will surely help you to create a fast script to replicate your results with windows PE.. :)

0

Share this post


Link to post
Share on other sites

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

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 :P
  • 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? :)

Edited by Albuquerque
0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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 :P

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 :)

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.