In this seventh article on Deployment Solution, I will introduce Altiris' rather clever Bootworks partitions. These automation environments provide an excellent mechanism for imaging computers, especially when the preferred automation OS is WinPE.

This article builds upon the imaging foundations laid out in the previous chapters, so please consider these prerequisite reading.

Introduction

In Chapter 4 of these training notes, we learned that there are several mechanisms for booting computers into the imaging environment we refer to as automation,

1. A PXE Server
2. Removable Media -CD/DVD, USB Pen etc..
3. A Floppy Disk (DOS only)
4. Client disk partition

In the previous couple of articles, we focused entirely on the first method -delivering automation by a PXE server. PXE automation delivery is neat because it provides a 'Zero-Touch' deployment mechanism (you don't have to physically be in contact with a computer in order to image it). In the above list however, there is a another 'Zero Touch' mechanism tucked away. This is the client disk partition option.

Deployment Solution provides two special types of partition to allow automation to load from the hard disk. These two special partition types are known as the Bootworks partitions, and there are two flavours available; hidden Bootworks & embedded Bootworks. It's a shame that more has been written on this subject in legal circles than can be found in any Deployment Solution manual, and today I'll try to explain as best I can how the first of these, the hidden partition, works.

This article will be divided into the following sections,

• Overview of the Bootstrap Process
  In order to understand how the bootworks partitions function, it is first useful to see how disks are partitioned and how the Master Boot Record, Volume Boot Record and Partition tables are used to help boot each machine's operating system
• Installing XP -a harddisk's perspective
  This section covers what your typical XP installation does to a harddisk to provide a bootable operating system. This allows us to build on the ideas presented in the previous section, helping us understand move about normal partitions before moving onto using Bootworks
• Preparing your computer for Hidden Bootworks
  Creating an additional partition on Windows machines for Bootworks is problematic -the default behaviour of Windows is to consume the entire disk for the Windows partition. Here I'll discuss how to make space for the hidden Bootworks partition on your image master PC by resizing the production partition. To do this, we'll add additional parameters to the rdeploy imaging program to deploy a resized production partition.
• Installing the Hidden Bootworks Partition
  Here we will cover how to install hidden Bootworks on your master image computer by creating a bootable CD using the Altiris Bootdisk Creator. Here the focus is on Linux automation purely because I feel i've neglected it to date in these notes.
• How does Bootworks work?
  Here I'll tell you how I believe the Bootworks MBR and the production agent's direct disk access capability together provide a robust mechanism for automation boot.
• Imaging With Bootworks Here I'll illustrate how to use the hidden partition as a local image store, and further introduce the concept of Deployment Solution Tokens.

Overview of the Bootstrap Process

When a computer boots up, it undergoes a sequence a baby-steps from the initial power-on to reach the stage where it can boot the operating system installed on the harddisk. In order for Bootworks to load from the harddisk, the normal boot process must be somehow interrupted and diverted. So that we can understand how Bootworks modifies the standard boot process, lets look at what normally happens when a computer boots.

1. The POST Sequence
   
   

   When any IBM-compatible computer starts, the first program to load is the BIOS (Basic Input Output System). The function of the BIOS is to initialise the computer's hardware, provide a small library of I/O functions (providing basic access to disks, graphics etc), and to boot the computers Operating System. As part of the hardware initialisation stage, the BIOS initiates the POST (Power-On Self-Test) sequence. This self-test sequence comprises of a set of mini-diagnostics routines which return the status of the system's critical components. On some systems, you'll see memory, processor and disk checks displayed, on other you might simply see a progress bar or a sequence of hex codes being displayed neatly in a corner. In most factories, if a computer passes this stage without incident, the Quality Assurance dude will lovingly place his 'OK' sticker on the box. Hmm....
2. Bootstrap to Master Boot Record
   
   

   On successfull completion of the POST sequence, the number one objective for the BIOS firmare is to boot the computer's Operating System. It does this by blindly loading the first physical sector (512bytes) of the boot device and transferring control to it by executing it. This process, whereby one program gives up control of the processor by loading another so that a computer can boot, is called bootstrapping. As we will see, this is used heavily throughout the boot process to finally reach the stage where the OS is booted.

   The code occupying the first sector of the harddisk is the Master Boot Record (MBR), and it consumes the entire sector (that is the first 512 bytes of the disk). The MBR can be divided into four parts,

   • Executable code (the first 300 Bytes for Windows XP)
   • Error Messages (the next 80 Bytes for Windows XP)
   • Zero-byte padding (this padding ensures the partition table entries that follow occupy the last 66bytes of the 512byte MBR)
   • The partition table (the last 66 bytes)

   The job of the MBR is to check the partition table and to transfer execution to the harddisk's bootable partition, i.e. another bootstrap. The steps here are,

   1. The MBR program locates the partition table at the end of the MBR in memory and checks for partition marked as bootable (if the partition table cannot be found or appears to be corrupt, the error message "Invalid Partition Table" is displayed)
   2. If a bootable partition is found, the MBR code proceeds by loading and transferring execution to the active partition's partition boot record -this being the first 512bytes of the bootable partition, i.e. the Partition Boot Record is bootstrapped.
3. Bootstrap to Partition Boot Record
   The XP Partition Boot Record is a much more complex beast that the MBR. In fact it loads a further 15 sectors into memory in order to achieve its final objective of bootstrapping to NT's boot loader -the infamous NTLDR.
4. BootStrap to NTLDR
   When NTLDR runs on the average XP computer, its job is to offer a simple boot menu (using boot.ini), undergo some basic hardware detection using ntdetect.com, and thereafter to bootstrap to the NT kernel, NToskrnl.exe. It is at this point the bootstrap process ends, and the XP startup sequence is initiated.

This bootstrap leapfrog is is summarised by the picture below.

Click to view.

Now that we covered the basic bootstrap process, we've got an idea of hoops a PC must jump through in order to boot an operating system. Let's go over this ground again, now from the point of view of an operating system installation. This is useful, as afterall Bootworks is just another OS to install on the harddisk.

Installing XP - A Harddisk's Perspective

So, let's start with the basics. Let's imagine you have just ordered a new kit PC for your home, and want to install XP on it. What stages must the trusty XP installation pass through in order to give you that lusted after XP eXperience?

In broad terms, we already know the installation process must configure the MBR, write the OS boot sector, and deliver the OS system files to the disk. Lets now look at this in a little more detail,

1. Create a partition in the Partition Table
   
   

   In order to begin the installation of the OS, XP's installer must reserve a distinct area on the harddisk for the Windows system files. It does this by partitioning the disk, and the area the installer reserves for Windows is commonly referred to as the Windows partition. To create this partition, the MBR is written and a partition entry is entered into the disk's partition table located at the end of the MBR.

   At this point, i'm going to introduce an analogy -a harddisk is in many ways similar to its pre-historic cousin, the book. If you think of a harddisk as being like a book, the process of creating this partition entry in the MBR can be considered akin to writing the details of the book's first chapter in the contents page (the task of actually writing the chapter comes later).

   When creating a partition table entry, there are a couple of partition attributes which need to be set,

   • Where the partition starts and ends on the disk
     In our book analogy, this is a bit like specifying the page numbers taken up by each chapter exactly before we've even begun writing the book. So, if you only reserve pages 9 to 109 for chapter 1, and find out later you need more than 100 pages afterall, your going to be stuck. This is the overriding reason why most of us use a single partition on our disks -analogous to reserving the whole book for chapter 1!
   • The partition's filesystem type
     In our book analogy, this is like having a multi-lingual book, specifying each chapter's language in the contents page. In most Windows deployment scenarios, this will be set to rather catchy hex code 0x07 the type used by NTFS filesystems.
2. Format the partition
   So that we can copy files to our our partition, XP's installer must format the newly created partition with a filesystem compatible with XP, namely the NT File System (NTFS). When Formatting a partition, the process typically starts with a disk scan, to check for errors, after which it proceeds by setting up the data structures according to the filesystem's specific file and directory structure rules. In our book analogy, think of this step as a checking and numbering of each page in our chapter so we're sure they're suitable for writing in. Note that the thorough check of the disk for errors is a somewhat lengthy process which can often be bypassed if desired with a quick format.
3. Installing the Operating System
   Having reached this point, the harddisk has been partitioned and formatted. We're finally ready to write the operating system files. The XP installation CD therefore copies the base XP files to the disk partition, writes the partition's boot sector to ensure that the XP setup is loaded when the disk is next booted, and makes the partition active by setting a flag in the partition table. This flag indicates to the MBR executable code that this partition is the boot partition, and thus that the MBR code should load this partition's boot sector.

On reboot the Windows Setup begins, and within about 30 minutes you're system will be ready with Windows XP.

Every time this XP box boots, the following chain of bootstraps is now traversed,

1. BIOS loads
2. MBR Bootstrap
   The BIOS first loads an image of the now present MBR into memory, and transfers control to the MBR code
3. Bootsector Bootstrap
   The MBR code locates the partition table (and the active boot partition within it), enabling it to locate the first sector (the bootsector) of the XP partition. It loads an image of the bootsector into memory, and transfers control to the bootsector code.
4. NTLDR Bootstrap
   The XP partition's bootsector code is programmed to locate and load the executable file NTLDR, the official bootstrap loader for Windows XP.
5. NToskrnl Bootstrap
   NTLDR now attempts to locate NTdetect.com and Boot.ini so that it can collect basic hardware information and offer XP boot options to the user. Once the boot option is selected control will be passed to NToskrnl.exe -the XP kernel. XP now loads.

In order to interrupt and divert the normal boot process, Bootworks should intervene somewhere between the BIOS and the partition boot record. This leaves one option really, Bootworks must write its own custom MBR. The function of this new MBR will be to boot the automation partition on demand.

The graphic (left) illustrates how the Bootworks MBR customisation allows automation boot from the harddisk (the automation bootstrap process details are omitted, as automation could be either DOS, WinPE or Linux!)

Preparing Your Computer for Hidden Bootworks

Now we've completed our initiation into bootstrapping, let's take a look at how Altiris employs disk partitions to boot into automation. The first case i'd like to take a look at is the hidden Bootworks partition (embedded Bootworks will be discussed in the next chapter).

The hidden Bootworks partition is a separate partition containing your chosen automation operating system. This is usually hidden beside the production partition, and it has a separate entry in the MBR's partition table. In a similar vein to products like Partition Magic or the HP,Dell & IBM OEM diagnostic partitions, boot control is handled by a customised MBR. The Altiris MBR customisation however differs in that is does not offer a boot menu to the user -boot control is handled instead behind the scenes by the interplay of the Altiris agents (both in production and automation) and the customised Altiris MBR.

Shrinking your Windows Partition to make room for Hidden Bootworks

To deploy a hidden bootworks partition, you first have to find some unused space on the harddisk. If you recall, from our previous discussion on Windows partitioning this might not be a trivial task - your typical Windows installation will utilise the entire disk for the windows partition. This sadly leaves us no space to create another partition for Bootworks automation.

So, to proceed, we need to shrink the Windows partition a touch, making some free space available for the Bootworks partition. We could use partition shrinkers such as Partition Magic or GParted, but this can of course be done by Deployment solution itself with a 'Fire-and-Forget' method - simply upload an image of the computer, and re-deploy with a resize.

The steps to create this resize job in the Deployment Solution console are as follows,

1. Create a new job called to resize the production partition
   In the jobs pane, make a new folder called 'Hidden Bootworks'. In this folder, create a new job. Give it the title "Resize production partition to 75%"
   
2. Create task to upload the image to Deployment Server
   Add a task to 'Create Disk Image' and configure it to upload the image to .\Images\Windows\TEMP.IMG
   
3. Create task to distribute the disk image
   Add a task now to 'Distribute Disk Image', configuring it with the image file location of .\Images\Windows\TEMP.IMG, as above. Tick the 'Disable Image Path Validation' validation, otherwise you'll get error popup as this image does not yet exist. Here now is the trick, in the 'Addition Parameters' section, enter -sz1:75p - this will deploy the image with the first partition resized to 75% of the target computer's disk capacity.
   
4. Create task to Delete Temp.img
   As there is no need to keep this image, let's do some housekeeping and delete it -this is afterall why I've called it TEMP.IMG. Add a task to 'Run Script' and in the 'Run this Script' section paste in the following,

   REM Delete Temporary Image
   del "C:\Program Files\Altiris\eXpress\Deployment Server\Images\Windows\TEMP.IMG"
   
   

   This script should be run in Windows, and locally on the Deployment Server (this option is configured on the second screen of the script Wizard). For those following this course from the beginning, this is the first time we've used DS to run tasks on the server itself.

   

The picture below summarises the process, where the process of resizing a computers 8GB Windows C:\ drive to 6GB is depicted.

By using the the DS job 'Resize Production Partition to 75%', the computer's disk image is uploaded to the server and then redeloyed with its new size. Having had it's production partition resized to 6GB, the computer is left with 2GB, more than ample for a simple hidden Bootworks partition.

So, give this a go. Create the job, and drop it onto your client. I advise getting a coffee and a few biscuits at this point. When you get back, you're XP client machine should now have its production partition nicely resized for you.

Installing the Hidden Bootworks Partition

To install a Hidden Bootworks partition we need to boot the computer with a CD generated from the Altiris Bootdisk Creator. The steps for this process are,

1. Create New Automation Configuration
2. Create Automation Partition Install CD
3. Deploy Hidden Partition using Boot CD

Let's looks at each of these steps in a little more detail. I'll be focusing on Linux automation here just becuase this has seen very little attention so far on this course.

1. Create a new Automation Configuration
   To create an automation configuration for our hidden Bootworks partition we need to return to the BootDisk Creator,
   • Open Bootdisk Creator (BDC)
     You can do this from the Tools menu bar in the Deployment Console, or by clicking on its quick-launch icon
   • Create a New Configuration
     

     By default, this will be the option first presented to you when BDC opens (if you've disabled this screen at start-up though, you can still access it by selecting File -> 'New Configuration')
   • Step 1: Configuration Name
     Here we get to choose the automation operating system we'd like to use for Bootworks. Lets choose Linux (you can later duplicate these steps for DOS and WinPE to try out these Bootworks OS options too!)
     

     So, enter in 'Linux' as the configuration name, and select Linux as the pre-boot operating system. Click 'Next'.
   • Step 2: Linux Network Adapters
     
     

     Here we can load extra drviers and/or tune Linux automation to load a subset of adapters first before doing its auto-detect. I generally leave this be. Click 'Next'.
   • Step 3: TCP/IP Protocol Settings
     
     

     Here we get to choose whether we'd like our automation's IP to be hard-wired as a static IP address, or whether it should request an IP from a DHCP server. I recommend, as always, having automation get its IP from a DHCP server to simplify your management of the automation environment. Therefore, leave the settings as the default where the IP address will be obtained from a DHCP Server and click 'Next'
   • Step 4: Altiris Deployment Server Communication
     
     

     As i've mentioned in previous chapters, the defaults here are good. Using TCP/IP to connect directly rather than use multicast helps avoid rogue DS servers grabbing clients. Further, having the automation agent location being set as being remote means that as you upgrade the server your automation clients will automatically upgrade too. If your automation environment is intended for a live environment, I also recommend checking the tick-box to lock the keyboard and mouse whilst in automation. Click 'Next' to proceed.
   • Step 5: Network Configuration
     
     

     Here we can configure the credentials employed in automation to connect to the deployment share. By default, the application credentials are used. Notice that domain credentials can be used here. In a later chapter we will tune this in the interests of security, but for now click 'Next' to proceed.
   • Step 6: Linux Network Mount Points
     

     This screen is similar to the network drive mapping screens you see when configuring the DOS or WinPE automation options. Linux, rather than using drive letters for mappings, uses mount points on its filesystem. Notice that the directory /mnt/ds is mapped to the eXpress share. We've no need to configure anything more for our simple training environment, so Click 'Next' to proceed.
   • Step 7: Configuration Summary

     This is just an informational screen. Double-check the details are sane, and click 'Finish' to continue.

2. Create Automation Partition Install CD
   1. Boot Disk Type
      Here we get to choose what type of automation disk we'd like to create. We can choose from,
      • Create an automated partition install package
      • Create an automation boot disk
      • Create a network boot disk
      

      The option we want here is the first one, to create an automation partition install package.

      The other two options are still however worth a quick mention. The automation boot disk option allows you to deliver automation using a bootable floppy or CD ISO image. These options can not only be useful for development and testing, but also in the enterprise as part of the floor-walkers' arsenal during mass-deployments.

      The option to create a network bootdisk is very similar to the automation bootdisk option above with the exception that the agent will not load. Instead you'll be presented with a command window -useful for troubleshooting.

      Click 'Next' to continue.

   2. Installer Operating System
      
      

      Now, here is a screen which often causes confusion! Having decided that we want to install a hidden Linux automation partition, we're now presented with another screen asking us essentially to select an Operating System. This is because Deployment Solution has the flexibility of creating automation partition installers which can be executed from either DOS, Linux or Windows.

      The only viable options for creating a hidden automation partition is to execute this from either a DOS or Linux bootdisk (if you select a Windows setup package here, the option to create a hidden automation partition will no longer be available on the screens that follow).

      Select the option to run this package from a Linux bootable disk. Click 'Next' to continue after you've satisfied yourself that the target CPU architecture is correct.

      (Note: It's actually useful to repeat this process, creating both DOS and Linux boot CDs for installating hidden automation partitions - where one might fail to load on some specific hardware, the other might well succeed.)

   3. Automation Partition Options
      
      

      On this screen are offered the choice of creating either an embedded partition, or a hidden partition. For now, we want to proceed by creating a hidden partition, so select this radio button. Notice that automatically the automation partition size will increase from a recommended 34MB to 2000MB. This order of magnitude leap in the recommended partition size reflects the difference in the intended function of each partition type. Hidden Bootworks partitions are excellent for storing images on.

      Click 'Next' to continue.

   4. Installer Media Type
      
      

      On this screen we can choose the target media for our automation partition installer. The default option is to create a bootable ISO CD image, but you can also write the bootable image to a removable device like a flash drive.

      For now we'll stick with making a bootable CD image, so click 'Next' to continue.

   5. ISO CD Image Path
      
      

      Here we are provided with the path and filename to our soon to be created ISO image. Take note of this as you'll need it to burn to a CD later.

      Click 'Next' to procceed. If you are presented with the informational dialog shown in the picture, click 'Yes'to verify that Boot Disk Creator should create a directory structure according to the above path.

   6. Creating Boot Disk
      
      

      Sit back and relax now, as Boot Disk Creator creates your Bootable CD ISO image
   7. Boot Disk Creation Complete
      This last screen exists to confirm the process has completed, and to remind you of the path to your ISO image.

      Click 'Close' to finish.

3. Deploy Hidden Partition using Boot CD
   Burn the ISO image created above onto a CD -its only about 20MB so this should take no time at all. Put this in the CD drive of the machine you've just made 2GB free space on for your hidden bootworks partition. Now boot off it.

   This is what happens,

   1. The ISOLinux OS loads
      
      

      ISOLinux is a Linux boot loader for CD-ROMs. It loads a 32MB initial ramdisk from the compressed root filesystem file rootfs.gz (this contains the Altiris Linux environment).
   2. The Altiris Bootworks installer
      
      

      The bootworks installer, bwinst now executes, and prompts you to warn that you are about to install a hidden Bootworks partition. Type 'Y' and hit the enter key to proceed.

      Note: the harddisks original MBR code is saved to file during the Bootworks installation - this is so that it can be put back should you ever need to uninstall Bootworks
   3. Automation File Copy
      
      

      Once the hidden partition is ready, the linux files for booting automation from a harddisk are copied across to the partition. These files, which you can find in the Altiris image file EBW.FRM on the ISO, are altrsboot, freeldr.ini, freeldr.sys, linux, rootfs.gz.

      Now remove the CDROM from the drive, and reboot the machine.

   When the machine reboots, the Altiris Master Boot Record is in place and as with all first time Bootworks installations it does an initial automation boot. If your quick, you might just notice the MBR printing to the screen a notification that its about to boot into automation: Booting Altiris Partition...

   

   Opposite you see the FreeLoader screen which appears momentarily as the automation root filesystem (rootfs.gz) is uncompressed into RAM. After this screen Linux gets dull and all plain text... ;-)

The beauty of Bootworks is that the user never sees it. It only comes into play when the computer is required to boot into automation. If you reboot your XP machine a few times, you'll notice that it always boots into XP. In fact, if your quick, you might notice the MBR displaying the following message; Booting Production Partition....

How Does Bootworks Work?

So how does Bootworks know when it should boot into automation? It turns out it's all done through a little flag in the Altiris customised MBR. Here's then what I think happens when a PC with Bootworks installed boots up.

As the PC boots, the BIOS bootstraps the harddisk MBR. The Altiris MBR executable code checks the status an indicator flag in the partition table, and......

If the flag is set,

• the customised MBR Code resets the flag
• The message "Booting Altiris Partition..." is displayed
• control is passed to automation by loading and executing the automation bootsector
• Automation is loaded

If the flag is not set,

• the customised MBR Code sets the flag
• The message "Booting Production Partition..." is displayed
• control is passed to production by the loading the production bootsector.
• Production is loaded

If seems that with the above logic, the computer would constantly be booting between the production and automation operating systems. This is obviously not the case, so what are we missing? Well, once booted into production or automation, the Deployment Solution agents have direct disk access. This allows them to toggle the MBR flag as need be.

For instance, when a computer boots into production the MBR flag is set to put in place a failsafe -if the flag is unchanged, on the next reboot the machine will be boot into automation. One in production however, a gracefull reboot will prompt the AClient to reset the flag in the MBR. The result is therefore that on the next reboot it once again returns into production.

In instances where a machine needs to be imaged, the agent simply reboots the computer without changing the flag state -the flag afterall is already set at this stage anyway to force an automation boot.

The advantage of the logic above is that should the production OS ever corrupt, the next reboot is always configured for automation. This failsafe is great -it provides the mechanism for you to initiate a computer rebuild from the console.

You can think of changing this flag's state as being similar in function to setting the active partition (which we discussed at the top of this article).

Imaging With Bootworks

Imaging with Bootworks is very simple, but as we've got plenty of imaging job already configured in the console we need to be wary.

For instance, previously on this training course we have created jobs to use the DOS, Linux and WinPE environments by hardwiring our automation choice into the Deployment Job. As we've made Linux our embedded automation choice, any imaging job which does not specify this automation OS will fail.

Opposite is an example of such a failure to load the correct automation environment expected by Deployment Solution. Here, I have re-applied one of the WinPE Upload jobs created in the last article. It rebooted the machine into the hidden Bootworks partition, but when the Linux agent here contacted the server it caused a great deal of confusion -the server was expecting communication from a WinPE Windows agent. As a result, the Console throws the error "Unable to boot to Windows automation".

To get around this you need to change the job to either load Linux or to use Default Automation. Default automation means what ever is configured as the default on the PXE server, or what ever Bootworks OS is installed.

I advise to configure imaging jobs where ever possible to use default automation -this actually allows you the greatest flexibility as they can be executed easily from PXE and Bootworks as desired. The automation job in which you need to define precisely the automation OS should be few and far between.

Try a few imaging jobs now to see how easy it is to upload and download images. Try to think whilst you are doing this about the MBR manipulations which are taking place during the process to toggle the booting between production and automation.

Why Use Hidden Bootworks

Now, this is the crunch of the article really. Why use Hidden Bootworks at all? Well, you can use it of course as a direct replacement of PXE -and this works very well. Hidden Bootworks has an added advantage though. Because it exists as a separate disk partition you can pretty much allocate as much space to it as you like. This space can be used as a local image store, and I regularly use this to save time and bandwidth on machines which require regular re-imaging.

Consider for instance the example of 20 public access machines in a web cafe, or computer lab. These require imaging on a regular basis, and an occasional imaging as and when problems arise.

Neglecting other solutions like Microsoft's Steady State or Faronics Deep Freeze, what we'd typically do is employ multicast imaging to deploy the master image to the computer group. This is fine, but there are some issues,

• Multicast is slower than unicast
• Even with hardware independent images, you might need to invoke several mulicast sessions to reflect OS and software variations across the machines. This can impact the network, affecting other network services like IP Telephony
• Some machines may require extra software whose licensing conditions forbid inclusion in a centrally distributed image. These post-deployment software installs can extend the deployment time consideraby.

The hidden Bootworks partition tackles the above issues by providing a space for you to store images locally on the client. Once an image has been transferred to the hidden partition, you can then re-deploy that image to the client rapidly and without network load. Further, this method allows each computer (which may vastly different in hardware, OS and software configuration) to have it's image refreshed with the same job.

Let's see how this is done.

Saving an Image to the Bootworks Partition

In the console, create a new job called 'Save Image to hidden partition' and,

1. Add a 'Create Disk Image Task'
2. In the Name text box, enter auto:%ID%.img, as shown in the graphic below.
   

   So, what does this cryptic image file path mean? Well, we are using something here Altiris refer to as tokens. These tokens give you a way to reference parameters which may vary from machine to machine in a convienient shorthand.

   Above I've used the following tokens to make my task as generic,

   • auto: to reference the Automation Partiton
   • %ID% to reference the computers unique identifier in the eXpress database

   Most tokens are easy to recognise as they take the form, %token%, and because tokens are so useful, we'll be using them quite a lot in future chapters.

   In my task above then, I've named the image file after the computer's unique identifier. The image file in my scenario will therefore have the name 5000008.img, as the ID from the graphic above shows the machine to have an ID of 5000008.

   Notice that I've left the automation environment as 'Default Automation', which will boot nicely into Bootworks (whatever the OS).

   Click 'Next' to continue.

3. On the 'Return Codes' window, just click 'Finish'.

Now run this job on you computer, and watch it save to the automation partition. Notice how the token %ID% has been translated on-the-fly to the computer's actual ID in the database.

More on Deployment Solution tokens can be found in the KB27468, Deployment Solution 6.8 Database Tokens.

Restoring an Image from the Hidden Partition

This is exactly as above, but now instead of adding a task to create and image, the task should now distribute the image. Note you should check the box to Disable Image Path Validation -Deployment Solution will not be able to find this image directly, and will throw up an error if it tries to validate the image location.

If you test this idea of a local image store on a lab of computers, you'll probably see now why I used tokens to name each image. You see, if you gave the image a static name like C:\XP.img the job to restore this image on the lab of workstations would actually result in a mulitcast session. DS would find a mulitcast master, and image this computer's local image over the network to the rest of the machines! Using tokens ensures that the images are uniquely named thereby ensuring a unicast session running directly off each client's disk every time.

Extra Credit

With a hidden partition used in this way, one thing which may leap at you is that the reconfiguration time after the image deployment is unnecessary. There is no need to strip a computer of its identity prior to saving the image locally - it will just have to replace it after deployment resulting in a 5 minute delay as it puts it back.

See if you can write your own tasks to save and restore the image using automation scripts to call rdeploy directly. This will allow you restore your hidden partition images without those pesky reconfigurations delaying the process.

To this end, you might want to give the following guide a read for the rdeploy command-line switches,

Summary

This introduction into Bootworks has been long, and does not yet cover the whole story (Embedded Bootworks is for the next chapter).

Hopefully you'll now have the confidence to identify which machines in your environment can benefit from such a setup. I've seen computer labs which took hours to rebuild (due to special software requirements and variations) having their deployment times cut to just 15 minutes by utilising this method. And all this without touching the network with those bulky image transfers and post imaging software deployments.

The important concepts which you should take away from this chapter are,

1. How the Bootstrap process takes you from the BIOS POST to your production OS
2. How Bootworks modifies the Master Boot Record to allow on-demand automation boots
3. How Hidden Bootworks can be deployed for rapid automation booting (harddisk booting is a lot faster than PXE -just try WinPE and watch it fly!)
4. How Hidden Bootworks partitions can be used as local image stores
5. How Tokens can be used to reference machine-specific parameters

Kind Regards,
Ian./

Chapter 6: WinPE as a PXE Automation Option