Video Screencast Help

Servicing Hidden Bootworks WinPE 2.1 Partitions

Created: 29 Oct 2012 • Updated: 29 Oct 2012 | 1 comment
Language Translations
ianatkin's picture
+1 1 Vote
Login to vote

When it comes to imaging, Deployment Server 6.x's Hidden bootworks partitions are impressive. They provide an astoundingly efficient zero-touch mechanism to re-deploy computers at disk-to-disk speeds that bypass LAN bottlenecks. The only downside I have found over the years with these partitions is that Altiris' lifecycle management philosophies do not extend to these fabulous entities. Should you wish to make even the most minor of changes to your hidden automation environments, the standard process is to attend each computer personally to upgrade the partition from CD. Once the upgrade is complete, you will also need to rebuild your local image store as this is wiped in the upgrade.

Hidden partition upgrade projects are therefore not undertaken lightly; they are generally only initiated when they can no longer perform the duties expected of them. Over the last few years, I have only come across two scenarios which were critical enough to force such upgrade pain,

  • Deployment Server migration to new hostname/IP
  • Hidden Partition size insufficient to hold next image(s) iteration

After a few of these upgrades however, I realised that this process could be drastically simplified. You can actually create a zero-touch process for maintaining your hidden WinPE 2 partitions which is fast and can be executed without compromising any pre-existing image stores. The resulting process will enable you to make on-the-fly changes to your hidden environments in a stress-free way, allowing you once again to sun yourself in the whimsical nirvana that is IT Management... ;-) 


Bootworks partitions are on-disk automation boot options which come in two flavours -embedded and hidden. Embedded partitions are boot partitions which are tucked away inside an existing partition, whereas hidden partitions are boot partitions in their own right. The main attraction of hidden partitions over embedded is that their size is not limited; this enables them to also function as a storage space for image files. These local image stores, as they are known,  act in a similar fashion to OEM Recovery Partitions by allowing you to rapidly return a machine to a previous known state without impacting the local network.

Use case scenarios for hidden partitions include,

  • Public Access Computers (where regular re-imaging is required )
  • Training Computers (where multiple images may need to be rapidly switched to between classes)
  • Remote Users (to enable fast recovery to a known state) 

The only frustration with going down the hidden automation path is that maintenance is not easy. Should you want to do something as trivial as changing automation agent settings, the process is to re-install the partition. And this is NOT a zero-touch process. You need to;

  1. Create a new Hidden Partition Install Disk with the settings you want
  2. Burn the CD
  3. Manually boot the computer with your new hidden partition install CD
  4. Reboot
  5. Boot into Automation and recreate the local image store

Hidden automation upgrades therefore end up therefore being quite a heavy-touch process. The Install CDs (created with BootDisk Creator) only know how to Install and Uninstall your hidden partitions -there is no option to upgrade. If you install a hidden partition over a pre-existing one, the existing partition is uninstalled which has that undesired effect of wiping the local image store. Many hours must subsequently be spend reprovisioning your image store after upgrade.  

This upgrade pain can be avoided though as there is a more lightweight method of rebuilding your hidden automation environments. The advantages of the method I detail here is that your upgrades can be executed remotely, are zero-touch and be completed without compromising your image store. Let's begin.

The Windows Image File (WIM) and Embedded Bootworks

When we boot into a WinPE2 based automation environment, what we are actually doing is bootstrapping into the automation OS from a Windows Image File (WIM).

If we were to examine the contents of a WinPE bootwork partition we'd see simply this,

In short, we have a striking lack of files compared to the previous generation of WinPE automation images based on WinPE 1.6. 

The important files here are,

  1. bootmgr.exe -the Windows Boot ManagerIts job here is to load the filesystem and mount the system's image file (boot.wim) within it
  2. boot.sdi -this file (only 3MB) is a bare NTFS formatted system partition which bootmgr can mount as WinPE's RAM disk
  3. /sources/boot.wim -this is our Windows image file. It is this file which contains our Automation operating system.

 The most common reasons for updating an embedded automation image are,

  • Update Drive mappings
  • Update credentials
  • Update Altiris Agent settings (in aclient.inp)
  • Review startup files (in startup folder)

The important thing to understand is that all these changes are made in a single file -the WIM file. Therefore, all we need to do to upgrade our hidden bootworks partitions is to upgrade the WIM file and have an automation task copy replace the existing file with the new one.

 It really is that easy. To perform such a WIM image update we can either,

  1. Create a new one from scratch (using BootDisk Creator)
  2. Edit an existing one (Using Microsoft's ImageX). 

The important thing is that this is where the hard work is -once we have this updated image file, we can simply use Altiris's native automation scripting capability to distribute it. 

Updating your WIM File using BootDisk Creator

As just mentioned, one option for creating a new WIM is to use BootDisk creator. Just make the changes you want and create a new boot image using the 'Files' option in the 'Boot Disk Media Type' Screen.

Even if you generate an ISO, you can of course use an ISO reader (7-zip will do) or a ISO mounter (like Virtual Clone drive) to extract the all important BOOT.WIM embedded within.

Updating your WIM File Using Microsoft's ImageX

Sometimes, using Bootdisk Creator to create a new hidden partition WIM isn't an option.DS6.9 SP4 introduced a UI bug (TECHNOTE 136455) which prevented Altiris Administrators from recreating the media which rebuilds their hidden partitions. There is no official workaround. Therefore when we had to upgrade our hidden automation partitions to reflect a major environment change our only option was to dig into the WIM and edit it manually.

To get hold of your boot.wim file, I find the simplest way is put the hidden WinPE automation into a wait state (drop a "Default Automation" wait task on to a machine with hidden bootworks) and then copy the file to the automation share from the command line,

copy c:\sources\boot.wim f:\boot.wim

I've assumed here that your eXpress share is mapped to the F:\ as this is the default configuration. Many of you will have moved this up a few drive letters to prevent drive conflicts, so be sure to use the correct drive letter for your environment.

To illustrate how you can edit your WIM images, I'll be going through the motions now of how your can change the background wallpaper in your bootworks environment. The steps are as follows,

  • Install Microsoft Windows AIK
    Even though WinPE2.1 is based in Windows Vista, I suggest you download the AIK for Windows 7. This is important if you want to do WIM edits -I've seen a lot of problems committing changes to mounted WIMs with the Vista version (like the one that installs with Altiris).  It's a big ISO that you'll need to mount with the likes of  Demon Tools or Virtual Clone Drive.
  • Mount your WIM
    ImageX has the capability to mount WIM files as a directory. This is brilliant for viewing the contents. The commands below illustrate how to mount a WIM in read/write mode,

    NET USE P: \\ALTIRIS-DS\eXpress

    "C:\Program Files\Windows AIK\x86\imagex.exe" /mountrw C:\TEMP\BOOT.WIM 1 C:\MNT

    Note: imageX has been compiled for the three different OS architecture flavours, each living in either the x86, ia64, or amd64 folders. Choose the right one above for your host OS. So if you're running the WIM editing on a an x64 machine, you'll need to change the imagex path accordingly.

  • Make Changes in the Mounted Filesystem
    Using Windows explorer, take a look around your mounted WIM under C:\MNT. Here we're just going to change the background wall paper, which is set by the file Windows\System32\winpe.bmp

    Replace this bitmap with the one of your choosing. Make sure it's still called winpe.bmp.


  • Commit Changes to your WIM
    Now you're finished with the changes, close down the explorer window (and any files you might have open from the mount point). It's important to close all this down as locked files will prevent your WIM being committed.

    On the command line now run the following,

    "C:\Program Files\Windows AIK\x86\imagex.exe" /unmount /commit C:\MNT

    This will save the changes to your WIM file.

  • Distribute Your New WIM file
    In the Deployment Console, create a new job to copy your new WIM over the old one. This needs to contain just a single task that executes within hidden bootworks to perform the file copy,

    Here I've put in a little pause at the end of the script just so you can see in testing what's happend on your target machine when you are sitting in front of it. Note I've assumed the new WIM file has been placed on the express share in the temp folder.

    And remember, this needs to run in the "Default" automation environment as this refers to the automation partition if present,


  • Run Automation Upgrade Task on your clients
    This is the easy step -just drag and drop you upgrade job onto a test client. It should reboot into automation and the upgrade it's own WIM file. The next automation boot should show your changes,

    And presto -We're done! And importantly, all of your local images are quite safe.


What I've shown today is how you can make your hidden Bootworks upgrades easy. To give you an idea of the time savings here, in a public areas suite of 100 machines executing this upgrade took just 30 minutes. Most of that time was reading log files to ensure the upgrade had taken. This was a huge  change compared with previous years where  Bootworks migrations took the public areas out of service for an entire day

Hope this brain dump helps anyone considering an upgrade in the near future!

Kind Regards,

Comments 1 CommentJump to latest comment

ManelR's picture

Hi Ian,

Thanks for this very interesting post ... I'll bookmark and read carefully to try the use of hidden partitions for classrooms ;-)

IT Systems Manager
LCFIB - Computing Lab
Barcelona School of Informatics
Universitat Politècnica de Catalunya - Barcelona Tech
Login to vote