In this fourth article taken from my Deployment Solution Training notes, we will take a peek at imaging. We'll begin by covering some imaging basics with PXE, highlighting how the Deployment Solution agents work in partnership in both the imaging and user's environment to provide a seamless deployment mechanism.

As the Altiris PXE server often works straight out-the-box without tweaking, we'll examine image upload/download scenarios utilizing Altiris' PXE server which is available as part of the 'Simple Install' path in the Deployment Solution installation wizard.

To finish the article I'll go under the bonnet a little and take a look at how PXE works, highlighting the pain points.

The Production and Automation Environments

A core concept in Deployment Solution is the idea that we should consider two Operating Systems (OS) when imaging. The first OS is the one our computers boots up into, so that we can catch up on our email and generally do the stuff that earns our daily bread. Altiris calls this the Production OS. For most of us, the Production OS will be XP or Vista, this being the OS that ships from our PC suppliers.

Taking this terminology a step further, Altiris calls the partition the production OS resides in (generally the first and only partition on the disk) the Production Partition.

The second OS Altiris defines is less obvious -it's the one we use for performing tasks outside the production OS, like imaging.

To explain, consider the common desktop jockey scenario where a PC has been badly infested by malware. IT policy says malware infested systems should be re-imaged, so we go to the user's PC, give them our bottled sermon on web surfing habits, insert our trusty DOS Ghost boot floppy and reboot. This DOS floppy, the OS into which we pre-boot our desktops into for imaging, Altiris calls Automation.

The Deployment Solution Agents

In order for the production and automation environments to work as team in the Altiris framework, both environments must have the facility to communicate to the server. Only through reliable communication can the server issue the correct sequence of tasks appropriate to the currently booted environment.

So that both the production and automation environments can 'see' the server they need to load a small piece of code to open up a line of communications to the deployment solution server. This program is commonly referred to as an agent.

What is an Agent

The first time I heard of programs being referred to as agents, I couldn't help but imagine a program hiding in the shadows wearing a groovy hat. As it happens, this is not far from the truth.

In the slide opposite I give a rough guide to the characteristics a program should have before it can be called an agent. In essence it's a piece of code with a small footprint which typically starts as a service (therefore hiding itself from the user), typically has system rights (so it can access and even manipulate machine level information) and typically sends off tasty info to a remote server.

The above characteristics are general, and of course there will be subtle variations depending on the agent's function.

Introduction to Automation Deployment

Because agent communication in automation is so critical to low-level tasks like imaging, we have the flexibility with Altiris to store our automation environments on various media;

• A PXE Server
• A Floppy Disk
• Removable Media -CD/DVD, USB Pen etc..
• Client disk partition

This allows you to choose an automation delivery mechanism which best suites your environment. For instance, if you prefer to enforce a policy of manual intervention before imaging a PC, you can decide to use automation floppies or CDs which forces local presence (this being akin to the old Ghost boot floppy/CD the many battle-hardened IT veterans have used in the past).

If you'd rather a completely automated delivery mechanism (I know I do!) then automation delivery by a PXE server or harddisk partition are the options for you. In these scenarios, just dropping an imaging job onto a computer in the console is sufficient to start the automated sequence of events which will re-image your selected desktop.

In Chapter 2 we installed Deployment Solution using the Simple Install wizard, and we checked the tickbox for installing a PXE Server. Lets now use PXE automation to image a computer running Windows XP.

Uploading a Disk Image with PXE

In this section we're going to look at how we take an image of a computer using the PXE booting mechanism. If you recall way back when we installed Deployment Solution we selected Linux as the automation environment. The choice of Linux and PXE was not accidental -they are in fact a great combination. Linux is lightweight and therefore great for deploying over the network with PXE, and further it's 32bit and has good driver support (which should in most cases be sufficient to allow imaging untweaked).

Let's start by creating an image of an XP computer. To do this you should,

1. Ensure the computer you wish to image has its BIOS configured to boot off its NIC first ;-)
2. Right-click the computer in the console and select "Quick Disk Image".
3. Confirm the job schedule

Your XP machine should in a matter of seconds begin to shutdown in preparation for a reboot. Just before the reboot though the AClient does couple of things,

• It disabled Windows networking
• It striped itself of it's identity

These rather brutal actions by the AClient are so that when the machine boots into automation for imaging, the resulting image is suitable for deploying to other computers.

Let's now look at the broad strokes of the image upload process using the graphic (left) illustrating the four parts of the PXE imaging process.

The first part shows the computer booting off its NIC and contacting the Altiris PXE server. This bit is rather neat -normally the PXE Server would auto-select for the client the 'Local Boot' option which would boot the computer off its harddisk. However in this instance, the Altiris PXE server has been informed by the console that the client must boot into automation. Consequently, the client is instead provided the download location of the Linux automation image.

The second part shows the client booted into the Linux environment. The blue strip with the progress bar belongs to the Altiris RapidDeploy imaging program. It's imaging in create mode, and the progress bar indicates its about 9% uploaded. Those from a Symantec/Norton background can consider RapidDeploy as the Altiris equivalent to Ghost.

The third part shows the ubiquitous Altiris 'Reconfiguring' window which appears after the image upload has completed and the computer is booted back into windows. This reconfiguration is essential to restore the network stack and the AClient's identity. And because the network stack is disabled, all the information to restore the AClient's settings must already be present on the system. These settings are stored in a file called AClient.cfg at the root of the system drive.

Once the AClient settings are restored, your machine is usable once again (after a reboot, naturally).

The final part shows a segment from the jobs pane in the DS Console -it confirms the image upload to the server has been successfully completed.

The Image File

If you browse the images folder on the express share, note that the quick disk image task has created an image file using the computer's name in the root of the windows folder (if it were a Linux machine, it would have filed it in the Linux folder). If you ever do find yourself frequently using the quick disk image console function, get into the habit of filing these files away to prevent image clutter.

As the images are divided into 2GB chunks you might find the image file has several parts. The first 2GB segment can be found in the .img file, the second in the .002 file, the third in the .003 file, etc...

Process Flow for Image Upload thru PXE

Having covered the broad strokes of uploading an image using PXE, let's now look at the details, step-by-step, using the graphic (left) help illustrate the process flow. The graphic depicts 9 imaging milestones, with a timeline below. The Linux penguin beside the timeline is just a reminder that in our scenario the automation environment is Linux.

Let's now take a look at each step in the imaging process, beginning from the moment you dropped the image upload task onto the client the Deployment Solution console.

1. Shutdown in preparation for imaging
   The AClient in the Windows production environment receives the task to reboot the computer for imaging. It disables the networking services, strips the AClient service of any machine specific information, and then issues a command to the OS to reboot the system.
2. The PXE boot
   The computer then reboots. Assuming the BIOS is configured to boot off the NIC before the Harddisk, the computer should bootstrap into the NICs PXE environment. On start-up the PXE Client will obtain an IP address and attempt to locate a PXE Server.

   When the PXE client contacts the Altiris PXE Server, it responds by offering the PXE Client just one boot option only -this being to download Linux automation. The PXE client downloads and bootstraps into the offered Linux automation image.

3. Disk Image Upload
   When Linux loads, the Linux deployment solution agent (ADLAgent) starts and establishes contact with the Deployment Solution server. This is quite quick -about half a minute. The server then sends to the agent the imaging task command-line which contains the image location and a configuration file to assist the AClient reconfiguration phase.

   The RapidDeploy imaging program then loads, and begins uploading the client's disk image to the server using a mapped drive. In the graphic, the imaging time is shown as being just over 6 minutes.

4. Client Configuration File
   When the image upload is complete, the AClient configuration file aclient.cfg is copied to the root of the system drive. This must be done just after imaging (rather than on the next boot into production) because the network stack in production will initially be disabled. The configuration file is trivial in this image upload scenario, as Windows itself will not need its identity altered.
5. Server issues Automation re-boot
   Once imaging is complete and the configuration file downloaded, the x agent is issued by DS reboot task to force the client into production where it will reconfigure.
6. The Second PXE boot
   On reboot, the PXE environment loads again, but this time the PXE Server offers the 'Local Boot' menu item as the default so that the client boots into production. This is because there is no more work scheduled for execution in automation.
7. Windows Reconfigures
   In order to ensure the image was suitable for cloning, the network stack was nuked and the AClient sanisanitizede reconfiguration phase allows re-enables Windows networking and restores the AClient's identity. It may take between 3-5 minutes for the reconfiguration window to appear as the state of the network stack delays the startup of the Windows services which must fire up before the AClient service can start and do its work. In the timeline shown in the above graphic, it took about 4 minutes from the boot Windows started to boot until the configuration was complete.
8. The Third PXE boot
   This final reboot once again has the PXE server issuing the 'Local Boot' option to the client as there is no work to be done in automation.
9. Production OS now Ready
   Ten minutes after the whole process began, Windows has finally booted back up with a fully functioning network stack. At this point you can safely login to a fully usable system.

Deploying an Image with PXE

Now that we've saved an image, let's see if we can deploy it. For this we need to create a task to distribute our image.

1. In the console jobs pane, right-click and create a new Job called "Deploy XPSP2 Image"
2. Add a "Distribute Disk Image" task
3. Enter .\Images\Windows\ImageName.img in the image file path, where ImageName is the name of the image you previously uploaded. Click 'Next'
4. On the Return Codes screen, click 'Finish'
5. Drag this job onto your computer, and confirm the ASAP schedule

As shown by the graphic (left) the image restoration process proceeds in a similar fashion to the image deployment. The computer reboots, loads Linux from te PXE server and then one in automation the local harddisk is imaged. One aspect which has changed significantly for the image download scenario is the function of the configuration file, aclient.cfg. This is copied to the root of the system drive after imaging (just as in the image upload scenario), but now this file isn't trivial -it now contains all the information need to reconfigure Windows.

To explain, imagine that this image is being deployed not to a single machine, but to a lab of twenty computers. Each computer before imaging had a unique computer name, and IP address. This unique information, which is stored in the eXpress database, must be restored to each machine after they've been imaged to ensure conflicts don't occur once the networking stack has been restored.

And, as we've all done it at least once, remember that if you can't access network services on a computer and an ipconfig reveals an IP address of 0.0.0.0 -don't panic, you computer has likely just been imaged and is waiting for the AClient service to start. Once the service starts, you'll see the reconfiguring window, and a reboot will follow...

A Deeper Look At Automation Delivery Using PXE

Having now used PXE successfully to deploy images, let's now take a slightly deeper look at PXE.

First, PXE stands for Pre-eXecution Environment and was created by intel as part of their "Wired for Management" initiative back in 1997. This environment, which is integrated in most Network Interface Card (NIC) firmware or embeembeddedPC motherboards, can only be accessed by booting off the NIC as part of the computer boot process. The aims of the PXE boot environment is as follows,

1. Locate Proxy DHCP Servers
   These Proxy DHCP servers are so called because they mimic the DHCP protocol to deliver the following information to the PXE client,
   • The IP addresses of the available PXE boot servers, and how to contact them (broadcast, multicast or unicast)
   • A PXE boot menu. This menu contains a list of all the possible bootstrap programs which can be downloaded from the bootservers.
   • A boot prompt text with timeout. Only by pressing F8 before the timeout can the user observer the full PXE boot menu options.
2. Obtain an IP address
   In order to download the bootstrap images of the PXE boot server, the PXE client must have an IP address. This was not essential when communicating to the Proxy DHCP server as all communications with the Proxy DHCP box are broadcast, but it is essential for what comes next.
3. Download the selected bootstrap
   The user selected (or default) bootstrap code needs to be downloaded from the appropriate PXE server. This is done using TFTP (Trivial FTP protocol) -hence the requirement at this point that the PXE client has its IP address.

What the PXE protocol offers Deployment Solution is a means to deploy automation boot images as bootstrap programs. In the simplest form, these bootstrap programs can be DOS floppy images, although we can also choose from Linux and WinPE images too. This is quite powerful, especially when you understand that Deployment Solution allows your to specify which automation option the PXE server should offer when executing automation tasks.

To see why this is so neat, consider a Windows 2000/XP scripted installation. For this, you need to boot your computer off a DOS boot floppy so that WINNT.EXE can be executed with the appropriate switches. For this, your PXE server should be configured in your Scripted OS installation task to load the "DOS Automation" option. For general imaging however, you probably don't want to be held up by the DOS's 16bit limitations. You might therefore prefer Linux as the general imaging automation option. With PXE, this is totally acceptable -its just another boot option which can be specified through your Deployment Solution tasks.

PXE Watchpoints

Automation delivery by PXE is fabulously flexible, but before deploying PXE in your environment, you should consider if any of the following are going to be show stoppers,

1. All clients must have their BIOS order set to boot first of NIC
   This can be a major project in itself, often requrequiringS upgrades to get like models uptoup to same BIOS version before a common BIOS configuration file can be deployed. And the more models you have to support in your computer estate, the more complex this project becomes. If you're a Dell or HP shop, Dell Client Manager /HP Client Manager can help out here.
2. The Proxy DHCP Service becomes a critical service
   In normal every day operations, you can turn Altiris off at a whim and your clients are unaffected. This changes as soon as your configure your clients to PXE boot. Taking DS offline in a simple configuration means your PXE clients will be unable to locate a proxy DHCP service. Your clients will therefore wait for a lengthy timeout before producing an error -this is awfully scary for users.
3. PXE with WinPE not suited to large-scale image deployments
   PXE booting a DOS image is super-fast as the DOS image is typically 1.44MB image. Upgrading to Linux is a big step -pushing the download to 15MB, but this can still be considered nippy. WinPE is however sits at a whopping 150MB (or 100MB with compression), and downloading this is slow. Add to this that WinPE cannot be downloaded through multicast, and you have an immediate and significant overhead for deployments greater than a dozen or so machines.
4. PXE requires router configuration changes on larger networks
   By design, the proxy DHCP service communicates to the PXE Clients through network broadcasts. This poses a problem for PXE Clients booting up on subnets different to the one in which the DHCP Proxy server is installed. To get around this subnet limitation, you'll need to talk to your networks team who will likely implement IP Helpers on the router subnet interfaces (to effectively recorecognizer DS box as a site DHCP server).

Summary

Well, that's it for now. Hopefully this article has left you a little wiser to Deployment Solution's imaging process.

The important aspects to take away from this chapter are,

1. What the Automation and Production environments are
2. Why computers need to be re-configured after imaging
3. A rough understanding of how PXE works

If I've done a good job here, you should feel confident at having a good stab at each of these answers!

Next, we'll take a look at imaging with Bootworks.

Kind Regards,
Ian./

Chapter 3: Introducing the DS Console

Chapter 5: MS-DOS as a PXE Automation Option