In this article, you'll learn,

• How to add WinPE as one of the pre-boot options to the PXE Server
• How to speed up WinPE downloads by tweaking the TFTP block size
• How to speed up WinPE downloads by compressing the download image from ~150MB to ~100MB
• That there is an OEM system builder in East Africa ;-)

When WinPE and I first met...

My first introduction to the Windows Preinstallation Environment (WinPE) was way back at the start of 2002. I was working as an OEM builder in an IT outfit owned by my brother in Uganda, and Microsoft was not flavour of the month for two reasons - it looked like Windows Millenium was never going to be fixed, and Windows 2000 Professional OEM was becoming increasingly difficult to source as the distributors were pushing Windows XP. The result of this was that despite our reservations, we had no choice but to supply our next batch of office PCs with Windows XP. We weren't best pleased to be honest - stability and application support was a concern (this was prior to SP1). Further, to provide a system whose response was on par with Windows 2000 we had to upgrade our current PC stock with more memory and faster graphics cards.

So, it was with reluctance we accepted the delivery of XP OEM media from our charismatic and endlessly cheerful Microsoft Distributor, Jules. Why he kept making personal visits to the office to endure my brother and myself I'll never understand. We were Operating System tarts - we'd install anything going if it did the job we wanted of it (an attitude not popular with Microsoft evangelicals). And we surely made the poor man suffer. As entertainment, we'd hotfix a server for him and watch it blue-screen and ask him to explain the meaningless error messages. Then perhaps, we'd move to a random unresponsive Windows Millenium PC (not particularly hard to find) and mention in passing that perhaps a service pack would be nice. To put salt on Jules' wounds, we'd then wax lyrical on how utterly stable and fast our new line of Linux servers were, and gosh, how cheaply we could sell them as we didn't have to throw the MS license fee on top. Thus prepared, we would sit back with a Coke and vent our frustrations on the latest issues. And in those days with Microsoft, we were never short on ammo there.

I so miss the good old days... ;-)

WinPE 1.0

At the end of such visits, myself and my brother would usually feel rather chirpy, so it was in this refreshed frame of mind we opened our box of XP media and investigated the contents. It included a nice OEM Windows Preinstallation CD, all shiny in silver. Being so shiny we opted not to 'file' it, and instead tried reading the documentation and booting off the media (probably not in that order). I remember being impressed - booting the CD produced a live Windows environment - something we were already familiar with in the Linux world with Knoppix, but had never imagined possible with Windows. It wasn't a fully featured however, because in order to shrink a live Windows XP environment to the size of a CD, WinPE had to offer an XP variant which was drastically reduced in functionality.

Whilst Microsoft could have gone the extra mile to make the CD more functional, there was actually little incentive. This was simply a tool created by a few motivated Microsoft engineers who saw DOS has having an increasingly limited lifespan in the system builder environment. WinPE's purpose was to release OEMs from DOS's limited driver support, providing a better way forward by which OEMs could install and deploy XP. And for that it certainly was effective.

The Rise of BartPE and WinPE 2

It didn't take long though for Windows Admins to get wind of this tool and a most public-spirited individual, Bart Lagerweij, dumped his fine work on DOS bootdisks and began work on his own variation on the WinPE CD - dubbed BartPE. Despite the rather dubious licensing issues of the first releases, a community quickly built up around Bart's Live Windows environment. Plugins were written and before long it became a great system recovery and diagnostic tool.

The reason for BartPE's popularity was largely down WinPE's elusiveness. You see, the only way you could legally possess WinPE was through your Microsoft Distributor as an OEM Partner. Later, this was also made available to the Microsoft customers through Software Assurance when WinPE was making inroads as an alterative imaging environment. The availability crisis with WinPE was finally resolved in the final quarter of 2006 with the publicly available Windows 2008 Server build of WinPE (WinPE 2.1).

Whether Microsoft's decision to make WinPE 2 publicly available was influenced by BartPE's popularity we'll likely never know. I strongly suspect though that WinPE is where it is in the mainstream today thanks to Bart's fabulous work on the Windows live environment.

Altiris and WinPE Support

In the Altiris world, WinPE first became available as an automation option in 2005 with the release of DS6.5. The only supported version of WinPE back then was WinPE 2005 (WinPE 1.6), and this was based on the code for Windows 2003 Server rather than Windows XP.

The table below shows the automation support options in various DS releases through the years. The long awaited support for WinPE 2 officially came in with DS6.9, and heralded the start of mainstream usage of WinPE for most Altiris customers (DS6.8SP2 could be made to work with WinPE 2005, but this was not public knowledge).

Adding WinPE as an PXE Boot Option

In the last chapter, I covered in detail how to add DOS as a PXE automation option. The process is very similar for WinPE,

1. Open up the PXE configuration Tool, and click 'New' to open up a New Shared Menu Item
2. Click 'Add Pre-boot' to add our final automation environment, WinPE.
   

   Click to view.

3. 'Install Pre-boot operating Systems' dialog. Click 'Install' opposite the WinPE x86 option.
   

   Click to view.

4. An Altiris BootDisk creator dialog will appear prompting you to enter the locations of your WinPE 2005 and Windows 2003 SP1 files. Click the 'Browse' buttons to locate your source locations, and then click 'Next'. There is an needless 'Please insert disk' prompt when you change your source destinations from the default drive letters - just click 'Cancel' to open the browse window.
   

   Click to view.

5. Wait a couple of minutes, while the files are copied.
   

   Click to view.

6. Installation completed. Click 'Finish'.
7. On returning to the Install Pre-boot Operating System dialog, notice now that the 32bit version of WinPE has successfully installed. Click 'Close'.
   

   Click to view.

8. New Shared Menu Option. On returning to the menu item configuration page, we can see we now have WinPE as a pre-boot option. Enter 'WinPE (unlocked)' as the name for the menu item, and select the WinPE radio button. Click 'Create Boot Image' to continue.
   

   Click to view.

   Please note: most of the Boot Disk Creator dialog windows for WinPE are similar to the DOS options covered in detail in the previous chapter. As such, i'll be skipping detailed comments unless I feel there is something which specifically needs mentioning.
   • Step 1: Configuration Name
     Enter in the description 'WinPE -default configuration'. Click 'Next' to continue.
     

     Click to view.

   • Step 2: Network Adapters
     When WinPE boots, it will by default auto-detect the adapter from the list on this page. You might find that for recent hardware WinPE goes into a DHCP loop -this is due to the failure of any of the pre-installed NIC drivers to bind to the card. To support newer NICs, on this page you can load NIC drivers which are not supported in the standard WinPE build. I advise that you leave the auto-detection feature turned on and click 'Next' to continue (when you become more comfortable with WinPE feel free to uncheck the auto-detection feature and start tuning the drivers more efficiently).
     

     Click to view.

   • Step 3: TCP/IP Protocol Settings
     Leave this at the default so that WinPE gets its IP address from a DHCP server. Click 'Next' to continue.
   • Step 4: Altiris Deployment Server Communication
     Leave this at the default so that,
     • WinPE gets its IP address from a DHCP server
     • The automation agent runs from the eXpress share, rather than being embedded within the image (preferred to ensure you always have latest agent without requiring a WinPE rebuild)
     • Keyboard is unlocked. For WinPE this also means the mouse is unlocked too.

     Click 'Next' to continue.

   • Step 5: Network Connection
     Leave this with the defaults where the altservice account is used to access the express share.
   • Step 6: Network Drive Mappings
     This is one screen where I do recommend a change, and that is to push the F:\ drive mapping higher up the alphabet to avoid conflicts. You see, in todays world of USB pen drives and smart card readers, WinPE can be greeted on startup with a multitude of removable drives. This presents a problem -the first thing windows will do is assign each a drive letter. To avoid conflicts I suggest moving the default network drive mapping all the way up to T:\.

     To do this simply.

     1. Delete the UNC path from the F:/ drive mapping
     2. Select the T:\ drive letter from the drop down combo box
     3. Reinstate the UNC path to the express share in the path text box for the T:\ Drive.

     This process deletes the F:\ Drive mapping, and re-instates it to the T:\ instead. If you neglect to delete the UNC share text from the F:\ (the first step above) beware: you'll end up trying to map an F:\ Drive and a T:\ to the express share.

     Note that once again we allow an LMHOSTS entry to be created to prevent a WINS lookup or network broadcast to locate the Deployment Server. Click 'Next' to continue.

     

     Click to view.

   • Step 7: Boot Option Settings
     Despite the fact we are going to leave this screen set to the defaults, it's still worth a special mention.

     The boot model changes the way drivers are detected as WinPE boots. The fastest boot method is to use Plug and Play with "Factory - minint". I've not yet found a reason to move from this default to the more thorough method of "Factory -winpe" which utilises the Winbom.ini (Windows 'bill-of-materials' file) to bring up the network.

     Below the Boot Model section, we find the Optional Components section. This section allows you to significantly enhance WinPE's functionality, allowing you to use it for more than just imaging. You can run VBScripts, HTML applications and even connect to SQL databases using ActiveX. The default option, to include the WSH support only, is sensible as few organisations have the time to invest in writing custom applications for use in automation. Therefore to save space, the dialog will not include the SQL ActiveX and HTML application support by default.

     'Next' to continue.

     

     Click to view.

   • Step 8: Configuration Summary
     This screen gives you a summary of the configuration setup in the previous steps. Double check that you're only mapping the T:\ drive to the express share, and that you network settings look sensible. Click 'Next' to continue.

      

   • Step 9: Edit Configuration
     If you wish to add or edit files within the WinPE environment, this is the place to do it. Lets leave this be for now. Click 'Next' to continue.
     

     Click to view.

   • Step 10: Create PXE Boot Image Files
     There is only one option selectable here -that being to create an automation WinPE PXE image. The other option (which is unavailable) allows you to create a network boot WinPE image without the automation agent installed. Click 'Next' to continue.
   • Step 11: Creating PXE Image
     Unlike the process for creating DOS automation, its unlikely you'll blink and miss this one! Click 'Next' to begin the file copy process which will finally result in your WinPE ISO image being built.
   • Step 12: PXE Boot Image Creation Complete
     At this point an ISO image should be now be in a temporary holding area on the PXE Server. If you open up windows explorer and navigate to your eXpress share, you should find it in a MenuOption staging folder with a .tmp extension under .\PXE\MasterImages

     Click 'Finish' to return to the New Shared Menu Option window.

9. New Shared Menu Option
   Notice at the bottom of the dialog is shows you where the PXE option files are going to be stored on the PXE Server. When you click 'OK', the .tmp staging folder above will be renamed to .wrk to represent this is ready to be saved to the PXE Server. Click 'OK' to continue

 

10. PXE Configuration utility
    Click 'Save' to finally save your new WinPE option to the PXE Server. This will configure the PXE server to use the files in the Menu Option folder (which now has the .wrk extension removed).

    Click 'OK' to exit the PXE Configuration, and return to the Deployment Solution Console

Configuring Image Upload/Download Tasks to use WinPE

In the last article, we used the DOS PXE option to upload and deploy our XP image. We did this by specifying which automation environment should be downloaded from the PXE server in the image task. We will now build on this, by creating image tasks to upload and download images using our newly created WinPE automation option.

1. In the Image Tasks folder created in the last article, create a job called 'Upload XPSP2 Image (WinPE)'. Add a 'Create Disk Image' task, entering the path for the image file as .\Images\Windows\XP.img. Now lets specifically set the automation OS we want to use. Set the last option on the window, the dropdown which allows us to select the Automation pre-boot environment, as 'WinPE (unlocked) (auto-select)'.
2. In the 'Image Tasks' folder create a job called 'Deploy XPSP2 Image (WinPE)'. Add a 'Distribute Disk Image' task, entering the path for the image file as .\Images\Windows\XP.img. Now set the automation OS we want to use again as 'WinPE (Unlocked) (auto-select)'

The picture left shows the Jobs which you should now have in your 'Image Tasks' folder. If you've been following through these articles, you should have jobs now for each of the three automation options -DOS, Linux and WinPE.

Now try some image uploads and downloads using WinPE.

The problem with WinPE and PXE...

When you run your image job, one of the first things you'll probably notice is how long it takes to download WinPE. In some scenarios in fact, it can take longer to download and boot into WinPE than it does to actually image the client! Below is a picture you'd best start getting used to if you're going to regularly image with WinPE downloaded from the PXE Server. Its a screenshot of the tftp process.

Click to view.

Comparing DOS, Linux & WinPE

Let's look at a breakdown of image download sessions with each of our three automation environments - it's quite illuminating.

Click to view.

Above is an image summarising the results of the imaging sessions from the last article, combined with my WinPE results. The hardware used throughout is the same.

The key points can be summarised as follows,

1. Overall, WinPE took the longest time to image a computer.
2. The process of downloading and booting into both DOS & Linux automation is fairly fast - typically in the region of 30 seconds. The time taken to download and boot into WinPE is staggering at nearly 5 minutes. This is largely due to the TFTP download time
3. WinPE offers great image download performance, superior to both DOS and Linux.

And remember that the above is for a single imaging session - we are talking about a single computer being imaged here. The WinPE tftp download time increases as you increase the numbers of machines being imaged. For a dozen computers, I've seen the collective tftp download time exceed 30 minutes.

So, how do we make the TFTP download time faster? Well, the first thing we can do is try and ease the overhead used by the TFTP protocol. The last chapter's introduction in tweaking DOS has thankfully broken a lot of ground already - tweaking TFTP is a piece of cake by comparison!

Making your TFTP downloads faster

The TFTP stands for Trivial File Transfer Protocol, and is a much simplified form of its big brother, the FTP protocol. The TFTP protocol has become over the years the standard for netbooting devices. This is because it's a simple protocol with minimal memory overhead. This simplicity is also its downfall when delivering WinPE images - it was simply not designed for heavy weight traffic.

Broadly speaking the protocol works as follows,

1. The client requests file from server
2. The server acknowledges request, and sends a data packet to the client containing the first block of data from the requested file. The size of this block is determined by the server's block-size parameter.
3. The client sends an acknowledgement that it has recived the data packet
4. The server sends the next block of data to the client which contains the next small fraction of the requested file
5. The client sends acknowledgement that it has recieved the data packet
6. The process (steps 4 & 5) repeats until the full file is transmitted.

Whilst such lock-step algorithms are very robust, they can be very inefficient when it comes to utilising network bandwidth. You see, at any one time on the network there can be only one TFTP data packet in flight. The server cannot send the next data packet until the client acknowledges the previous one. The result is that the protocol's data transfer rate is crippled by the round-trip time (RTT) between the client and server.

Lets do some simple maths to see what the impact of this lock-step feature of the TFTP protocol. The default block-size used by the Altiris TFTP server is 768 bytes - so what can we expect from this on a network which has a round-trip time of say 1ms?

Well, a restriction of being able to send only 768 bytes every 1ms scales up to being able to send 768K every second. For a 150MB WinPE download this equates to a download time of about three and a half minutes! This is in good agreement with the time recorded earlier of 4min 55secs for WinPE automation -this was the time taken not only to download WinPE from the TFTP server, but to boot into the OS, start the network stack and load the automation agent.

To improve the TFTP download times we can increase the server's block-size paramter. The maximum size of the block is however limited by the ethernet frame's Maximum Transmission Unit (MTU) - the maximum number of bytes that can be transmitted in one go on an ethernet network. The Ethernet MTU is 1500bytes, and taking into account the protocol headers we are left with a maximum block size of 1456 bytes for our TFTP block size. If we exceed this block size, there is a good chance our data will have to be split over two ethernet frames, i.e. it will become fragmented. General wisdom is to avoid fragmentation as the clients must understand how to piece the packets back together, and in general they don't.

To increase the TFTP server block size do the following,

1. Open up the PXE configuration utility
2. Select the Multicast tab
3. In the Packet Size text box, change the value from 768 to 1456
   

   Click to view.

4. Click 'Save' to push these settings to the TFTP server
5. Click 'OK' to exit the PXE configuration Utility

Try imaging with PXE now -your TFTP transfer time of the PXE image should now be twice as fast! Not bad for a minutes work at the console.

Compressing the PXE Image

The next way to speed up the TFTP download time of your PXE image is to reduce its size. This can be achieved by compressing it -a tip which came from Mike Gibson, an Altiris Consultant, at the UK Altiris Forum meeting last year. The KB article however suffers from a lack in background information which makes it very difficult to troubleshoot in the event that your image compression doesn't work. So, consider that follows as KB22971 on steriods... and my hope is that this extra information will provide you a better starting point that I had. ;-)

The procedure for compressing the ISO image in broad terms is as follows,

1. Install the Windows Embedded development Tools. This will give us the capability of using SDI technology (System Deployment Image) to convert our WinPE ISO image to the SDI format. This format is a portable XP Embedded file format, and it natively supports NTFS compression. It is this compression feature which we will make use of to bring our WinPE download size down.
2. Convert the ISO image to an SDI file using the script attached to this article called called MakeSDI.bat. This is a modified version of the one downloadable directly from the Altiris KB.

    

Substitute the existing WinPE boot option ISO image with the SDI file on the PXE server, adjusting the boot files accordingly.
3. Give the PXE server a kick to resync

Sounds easy huh? Hmm... Lets give it a go...

Install the Windows XP SP1 Embedded Tools from Microsoft

1. Download the web installer here.
2. Run the Web Install program (XPEDDI.exe) and deselect all the products in the GUI with the exception of the topmost item, the Windows XP Embedded SP1 tools, and click 'Download Now'.
   

   Click to view.

3. Once the tools are downloaded, click 'OK' to exit (you may receive a warning that disk 2 of setup cannot be found. I clicked 'OK' here, and everything seemed to work fine!)
4. On the Windows Embedded setup screen, select Tools Setup to start installing the XP Embedded Studio tools. This suite of tools include the SDI utilities needed to create our compressed WinPE virtual disk image.
   

   Click to view.

5. Click through the InstallShield wizard, leaving the defaults as is. The product key you'll find located in the text file C:\Program Files\Windows Embedded\Installer\DISK1\productkey.txt.

Create your WinPE source folder

Copy the contents of your WinPE ISO image to c:\WinPESrc. To remind yourself where the ISO is, open up the PXE Configuration utility and take a look at the WinPE boot options properties. The location of the ISO image is declared in the 'Final Location on PXE Server' text box, and should look similar to ..\PXE\Images\MenuOption131.

The WinPE files can be grabbed from this ISO image in several ways,

• Burn the ISO image to a CD, and then copy the contents to the folder
• Use a Virtual CD-ROM application like Deamon Tools or Microsoft's XP Virtual CDROM Control Panel Applet to mount the ISO image.
• Use a vitualisation product like VMWare Player or Workstation to mount the ISO image as a virtual CDROM Drive (yes, its overkill but if you already have VMWare installed and use if for development then this might actually be the fastest way!)
• Use a disk imaging suite which supports ISO images like WinImage to explore and copy the contents off the ISO image.

Download and Run MakeSDI.bat

Download MakeSDI.bat from this article. Don't use the Altiris KB article download as it has a bug in the defrag commands and mine allows for a slightly bigger SDI file of 102MB rather than 94MB (I found the 94MB default to be a touch too small for my WinPE image).

The purpose of the MakeSDI batch file is to copy our WinPE source files onto a virtual disk represented by our SDI file. The syntax of MakeSDI.bat is as follows,

MakeSDI.bat WinPE-SOURCE TARGET-SDI UNUSED-DRV-LETTER

On my system, the X:\ is unused so I'm going to run this as

MakeSDI.bat C:\WinPESrc C:\WinPE.SDI X:

This script is does not (sadly) completely automate the process of creating your SDI file. There are three stages,

1. Create the target SDI file, WinPE.SDI
   When the script runs, it will first use the SDI tools to create your SDI image file C:\WinPE.SDI. This process creates a virtual disk, and sets its size to 103MB.

    

2. Load the SDI Image as a virtual disk
   After the SDI file is created, the script pauses. In order to copy files to the SDI virtual disk image, we have to mount the image using the SDI Loader application. This is a manual process, and after pressing any key, the application loads. Click 'Add Disk' to browse to C:\WinPE.SDI. Once selected, click 'Done' to finish.
   

   Click to view.

3. Clean, partition and mount the SDI Image
   After loading the SDI image as a virtual disk, we need to execute the following commands in DiskPart when it loads,
   1. list disk
      In order to point DiskPart to the correct disk for our disk operations, we must select the correct disk to operate on. This command reveals the currently attached disks. Our disk is the one listed as being 102MB, and should have the highest index (as it was the most recent disk to be attached to the system).
   2. select disk #
      Where # is the disk index discovered in the previous step. In most cases, the SDI disk will be disk 1, with disk 0 being your actual system harddisk.
   3. clean
      After selecting our SDI disk, we should ensure its completely blank. The clean command ensures the selected disk's partition table is wiped and ready for our next operation.
   4. create partition primary
      This command is quite remarkable in its clarity - this will create a primary partition on the disk. By default it will occupy the entire virtual space (minus a small overhead for the MBR, hence why I create the disk image 1MB more than the partition I want to write to it).
   5. assign letter=X
      This command assigns our newly made partition the drive letter X. At this point you should be able to view it in My Computer as an unformatted RAW filesystem.
4. Format and File Copy
   Once you've completed the DiskPart, the X:\ drive is formatted with the NTFS filesystem (compression enabled) and the WinPE files are copied across. Viewing the X:\ drive in explorer should show this drive letter now as blue -reflecting the fact its been formatted as a compressed NTFS drive.
5. Detach Virtual Disk
   After the files are copied across, the Storage Device Image Loader will be called again, this time to allow you to detach the virtual disk. Select your SDI file in the window, and click 'Remove Disk'.

   Notice this file is 102MB - nearly 50MB smaller than the original ISO image.

Replacing the WinPE.iso PXE Image with WinPE.SDI

Now that your virtual disk has been detached, your SDI file is safe to copy over to the PXE server to be used in your WinPE boot option. This process is actually rather tricky as syncing the PXE server with your new image file isn't directly supported by the PXE Configuration Utility interface. This means some manipulation behind the scenes is required.

In order for the following manual changes to make sense, it's wise to spend another minute or two re-iterating what happens when images are built and edited.

• First, the PXE Server stores the configuration for each PXE boot menu in a Master folder called ..\PXE\MasterImages\MenuOption###, where ### is a MenuOption number.

• When images are edited in the PXE Configurator, an equivalent folder with the .tmp extension is created as a temporary working area for the new master.

• When you've finished your edits and the option is saved in the interface, the temporary MenuOption folder replaces the live version. That is to say, the MenuOption### folder in MasterImages is deleted, and the MenuOption###.tmp folder is renamed to MenuOption###. Once this is complete, this folder is synced down to the PXE Server's live distribution folder under ..\PXE\Images.

With the above in mind, the steps load up our new PXE MenuOption with our SDI file are as follows,

1. Delete the WinPE ISO Image from the MasterImage\MenuOption### folder
   As we'll not be booting off the WinPE.iso anymore, lets remove it from the Master folder. This will prevent the PXE server sync process being delayed by the copying of a now unused 150MB ISO image each time the Image folder gets synced with the MasterImage folder.

   On my server, the WinPE ISO image was stored under ..\PXE\MasterImage\MenuOption131 (as revealed by looking at the properties of the PXE Boot option in the PXE Configuration Utility). So, the ISO I need to delete is in here, within the x86PC subfolder. Double check your particular MenuOption index, and delete the corresponding WinPE.ISO in the MasterImage folder now.

2. Copy WinPE.SDI to the MasterImage\MenuOption folder
   In the folder you've just deleted the ISO image from, copy over into it the WinPE.SDI file. This is the file we are going to be downloading by TFTP instead of that previous bulky occupant, the ISO image.
3. Modify Winnt.sif
   Winnt.sif currently expects to boot the WinPE ISO image. We need to modify this now so that it will accept the SDI image instead.

   The default Winnt.sif will look like (remember, in what follows ### is your MenuOption number),

   [SetupData]
   BootDevice = "ramdisk(0)"
   BootPath = "\i386\system32\"
   OsLoadOptions = "/noguiboot /fastdetect /minint /rdexportascd /rdpath=MenuOption###\X86PC\winpe.iso /PXE_SERVER:**PXE_NAME** /PXE_IP:**PXE_IP** /PXE_PATH:MenuOption###\X86PC"
   
   

   and to make this load the SDI file we need to ammend the OsLoadOptions line as follows,

   OsLoadOptions = "/noguiboot /fastdetect /minint /rdimageoffset=36352 /rdpath=MenuOption###\X86PC\winpe.sdi /PXE_SERVER:**PXE_NAME** /PXE_IP:**PXE_IP** /PXE_PATH:MenuOption###\X86PC"
   
   

4. Resync the PXE Server
   This is where it gets tricky, as the syncing the master folder requires us to do a little fudging.
   1. Open up the PXE Configuration Utility
   2. Select the WinPE option, and click 'Edit'.
   3. In the Edit Shared Menu Option window, select the Image Creation Method of User Supplied, and click 'Manual Boot Image'
   4. In the PXE Boot Files box that pops up, browse to any small folder on your C:\ Drive which has some .exe files (I typically choose my DOS files folder) and click OK. This step gears puts the PXE configurator into the stage where it creates the .tmp Master folder. Don't worry about the fact you've just put some random small files in here -the in the next step we will delete them!
   5. Delete the ..\PXE\MasterImages\MenuOption###.tmp folder which was created by the last step. We'll be fooling the PXE Configuration Utility into using our own .tmp folder in the next step.
   6. Rename the ..\PXE\MasterImages\MenuOption### folder to ..\PXE\MasterImages\MenuOption###.tmp folder. Remember, the .tmp folder is a staging area for the PXE Configurator, and this now contains our SDI WinPE build
   7. Close the Edit Shared Menu Option window by clicking 'OK'. Our .tmp master folder is now moved to the last staging point in the PXE Server as a .wrk folder
   8. In the PXE Configuration Utility, click 'OK' and when prompted save your work. This process moves the .wrkfolder to the master folder, and resyncs with the files in the ..\PXE\Images\MenuOption### folder

And that's it - your PXE server should be loaded up with a nice new trip WinPE Image. Try downloading now, and you should see a further drop in the WinPE TFTP download time, of about one third.

Final Tip -Disable TFTP Multicast

One of the oddest settings which is by default turned on in the PXE Server is multicast. The reason why this is odd is that only DOS supports being downloaded by multicast, and its so tiny its hardly worth the effort. Linux and WinPE do not support being download via multicast - the overhead and delays introduced by trying to use MFTP is therefore wasted. I recommend turning this feature off.

Click to view.

Summary

Well, that's it for today. Hopefully, having followed through this article you'll not only have tripled your WinPE download times you'll have understood why.

The process of creating and uploading the SDI image to the PXE server (to be frank) utterly appalling. But until TFTP client and server recognise TFTP protocol extensions to allow multiple TFTP data blocks on the wire simulteously, this step remains important to those trying to reduce those TFTP download times.

Kind Regards,
Ian./

References

Revised MakeSDI.bat