ImageInvoker - A Menu-based Imaging Add-on for Deployment Server

If you are a LinuxPE automation user, today's article will help revolutionise how you image your computer estate with Deployment Server. Today I will show you can image both new and existing computers without ever having to touch the Deployment Console. By introducing a menu system into automation we kiss goodbye forever to the need to stage computers for initial deployment, and even remove that pesky need to set computer names up. By implementing the steps in today's article you'll extended Deployment Server's imaging capability, allowing you to initiate your day-to-day tasks directly from an automation-based client menu system. As such you'll be able to initiate Windows XP scripted installs, Hardware Independent Imaging deployments, or even a DoD Disk wipes within moments interrupting the automation boot process.

For those favouring the DOS and WinPE automation environments -watch this space. Once the LinuxPE version is ratified, work will begin to support the other automation environments too.

The version of ImageInvoker in today's article is one step in advance of what I have in production, so please consider this a beta product.

Client Initiated Imaging Introduction

Altiris Deployment Server is a great product, and in my opinion the flagship of the Altiris suite. It stands head and shoulders above any other single solution in the Altiris product line. One of its failings though is the inability to totally impress desktop administrators coming from a Microsoft RIS background. Altiris is streets ahead of RIS, so what's the problem? Well, it all comes down to the process required to invoke Altiris' day-to-day imaging functionality. You see, Microsoft administrators are used to simply PXE booting their computers into the Client Installation Wizard, selecting a task from a menu and then going for a coffee while their computer is deployed.

Figure 1: Screenshot of a Microsoft RIS Client Installation Wizard Screen

Deployment Server isn't great however at imaging computers soley from a PXE menu. "Ah ah!" you say -that's what Initial Deployment is for! We just stage some template computers in the console, drop on some jobs to them and then boot your new computer and select the destination computer from the menu.

OK -now read that last sentence again. We want to image a new computer, so what do we do? We find another computer to login to the console, ensure template machines are setup and jobs staged. Then we go back to the original computer, boot it into automation and then select the desired computer from the menu. This is incredibly cumbersome to those coming from a Microsoft RIS background -and they are not impressed. And although initial deployment scenarios can be managed more elegantly, re-imaging existing computers cannot. We must always log into the Altiris Console.

In an ideal world, a desktop monkey should be able to visit any unhappy desktop, boot it into automation and image the computer directly from a menu. He shouldn't have to log into the console, locate the computer, locate the rebuild job and then create the schedule. The Client Initiated imaging capability within RIS has other advantages too. First and foremost is that you don't need to train all your desktop staff in using the Deployment console. They need never know it exists for your day-to-day imaging tasks. With a menu system, you could train anyone to rebuild computers within 5 minutes. And as this is all client initiated, you've also just wiped out that nagging risk of re-imaging someone else's computer by mistake -and we've all been there right??!

Client Initiated Imaging Requirements

A couple of weeks ago, I came to the sad conclusion training our already overworked helpdesk staff in Deployment Server was going to be practically impossible. Having worked hard to get all the various images into our hardware independent imaging pool, I had to now find a way to give our Helpdesk staff the power to use Altiris Deployment Server without the overhead.

So I started thinking seriously about how to invoke imaging from a client's automation environment. My thinking was that this should be possible after all -the SQL eXpress database at the backend is tidy and transparent (pretty much everything Deployment Server is and does is there). On top of that, Deployment Server comes with utilities like AexSched which are just begging for 3rd party apps to leverage for deployments. So I started to build together some ideas and test some pieces. I chose Linux automation for prototyping purely because this is the basis of our HII process. -this seemed best automation OS for me to start creating the new client-side imaging system.

So, what were the problems that needed solving? Here was my shortlist,

1. As DS 6.9SP3 brings in a new Linux automation environment, I needed a menu system which would work within any Linux automation environment. This means statically building any required binaries, to avoid library dependancies.
2. I need the menu system to be driven and created by a server-side process. It's important for the menu items to be built without requiring an obvious use a third-party tool if the process is to be seemless.
3. For reliability, I need to be able to invoke jobs through the menu system which will clear any preceding jobs (allowing the instant scheduling of the selected imaging task)
4. I need to be able to image computers unknown to Deployment Server
5. I need to be able to see that the computer is (or will be) called in the console. I also need to be able to change the computer name directly from the menu system if required.
6. The client side process needs to be aware whether the jobs have been scheduled successfully, and whether any problems were encountered.
7. I need a lot of SQL. My thinking was that the menu system should be able to delivery folder hierarchies of jobs, as well as single jobs directly. I'll probably be bleeding from the ears before this job is done...
8. This probably won't work properly first time... So I need some versioning of the client-side and server-side code pieces to keep them in step. I need to learn to use Wise to neatly package the whole thing up, so that I can upgrade seemlessly.

So, using my many hours of commute time and my trusty laptop which with its new battery refit (it had a battery life of less than 15 minutes just before I started hacking away at a prototype) I started to code.

The download attached to this article is the culmination of that work. Grab a test server, and lets go through the installation process together.

Installing ImageInvoker

The install for ImageInvoker has been authored in Wise, and so is a pucker MSI. I've had to use custom actions for a few things for inserting SQL functions and locating the eXpress share, but otherwise its all nice and standard stuff. The process for installing is,

1. Execute the MSI on your Altiris Deployment Server. It takes about 10 seconds for the following screen to appear because of some custom actions and prerequisites firing off in the background. Be patient.

   

   Even though this is a very light-weight MSI, and the affect in installing on your server really is minimal, I do advise (as will all install and upgrades) to do a full backup of your Altiris installation before commencing. If you are using VMWare, then now would be a prudent time to take a snapshot!

   And yep -its BETA. Its essentially a prototype which i've moved into production as i'm so pleased with the functionality it provides. I haven't seen ImageInvoker ramp up the CPU or memory ( I spent two days revising the code to make it more memory/CPU efficient after the initial prototype), but its possible it might do something odd.

   Click Next to proceed

2. On the next screen you should be presented with the destination folder as being the express share. If the custom actions have got this all wrong, click browse to select the correct location.

   

   Click Next to proceed.

3. Now we have to enter the password you use for the Altiris Services. As this is a text box i'm running on, I've taken some shortcuts and am running Altiris under my local administrator account. After a thorough telling off for such bad practice I enter the password and click Next.

   

   And this is where I must grab your attention. If you implement DS Console security, the service account you use for Altiris must be entered in as an account in the console with administrator rights. If you do not, it is highly likely that the service won't have the necessary rights in the console to automate your imaging tasks.

4. Now, to the point of no return. If you're happy -click Next to proceed

   

5. And that should be it -ImageInvoker is now installed. Click Finish to exit.

   

Configuring Linux Automation to Load the ImageInvoker Client Menu

Now that the ImageInvoker service is ready on your server, its time to make a little amendment to Linux Automation so that we can initiate client imaging. The change we will implement below will simply force automation to load the client imaging menu should it exist. To make this change to the Linux option in our PXE server the process is as follows,

1. Open the PXE Configuration Utility
2. Select the Linux option you'd like to insert ImageInvover's client imaging menu option, and click Edit

   

3. Once your in the Edit Shared Menu Option window, Click Edit Boot Image button,

   

4. Once Altiris Bootdisk Creator opens, you'll be taken directly to step 8 where you can edit the configuration. Right-click the startup folder and create a new text file called menu.sh

   

5. In the text pane, copy and paste the following simple shell script,
   

   #!/bin/bash
   
   if [ -f "/mnt/ds/ImageInvoker/Linux/imaging_menu" ]; then
    /mnt/ds/ImageInvoker/Linux/imaging_menu
   fi
   

6. Click Next. When prompted to save your changes to menu.sh, click Yes.

   

7. You'll now be brought to the Create Boot Disk window. Click Next and wait for the new PXE image to build.
8. Click Finish on the completion screen
9. Back in the Edit Shared Menu Option window, click OK to close it.
10. You'll now once again see the PXE Configuration Utility. Click Save to commit your new PXE image to your PXE servers.

That's it. What we've done is tell Linux automation to load the client imaging program should it exist. At this stage the Client menu will silently drop out as we haven't configured a menu. Let's do this now.

Configuring Your Client Menu Items

Rather than write a separate utility to configure a menu, I decided to use a mechanism which was transparent to the Deployment Console. This was so that anyone modifying jobs in the console would be instantly aware if this jobs are public facing through the menu system. So, I decided on a simple rule -any job or folder of jobs including the string (MI) in the name will be pushed to the client menu (MI standing for Menu Item).

The figure below shows a before and after picture of this process.

Here I have, for illustration, targeted three objects for the Image Menu,

• The job DoD Disk Wipe
• The folder Deploy Public Access Computer
• The folder Deploy Staff Computer

To commit these jobs to the menu do the following,

1. In the Deployment Console, from the menu-bar select Tools -> Altiris Tools
2. Click "ImageInvoker: Create Automation Client Menu"
3. After a few seconds you should get a popup box, declaring the jobs added to the menu.

   

4. Click OK

Here I should point out that when you tag folders as menu items, not only all jobs within the folder are processed, but the subfolders are processed too. This means you don't need to change the way you organise your jobs in order to use the menu. Also, the tag (MI) can be anywhere in the folder or job name.

As the Menu Creator tool writes a refreshed menu file for your clients, remember to run this each time you want your job and folder name changes with the (MI) tag to sync down to your clients.

Using the ImageInvoker's Client Imaging Menu

Now, let's boot a computer into Linux Automation, and see what happens.

1. Five Second Countdown

   As you can see from the screen grab below, we have two changes to the normal boot sequence. First, we receive some friendly text letting us know that the Express share has been mapped. This is really to comfort the Helpdesk staff who'd like to see something human readable at this point rather than looking for "Child Returned 0" messages which indicate a successful mapping. The next change is a 5 second countdown. If we press 'i' within these 5 seconds, we will interrupt the normal automation loading sequence and load up the imaging menu.

   

   Press 'i' before the countdown has finished to invoke the client menu system

2. Client Menu Interface

   Now you'll find yourself presented with the Client menu Interface. All the menu items have been named as the folder and job names, but excluding the (MI) tags we used to mark them as menu items. I fancy making this computer a public access machine, so let me select that option and see what happens,

   

3. Computer Name Verification

   This stage of the interface provides the opportunity to change the computer's name. In my case it currently has the rather random name of 'llkk' in the console. I'm going to change this now to something more suitable -lets say 'staff-xp-001'

   

4. When you hit enter here, the jobs will now be scheduled. While the job scheduling is in progress you'll see the screen below,

   

5. After a few moments, if the job scheduling has been successful you'll be presented with the following screen,

   

6. If you take a look in the console you'll now find the jobs scheduled just as if you had dragged'n'dropped them on yourself,

   

Initial Deployment

New computers are handled quite simply with ImageInvoker. If you boot up a computer into the client menu which is unknown to DS, after selecting your menu choice you'll be presented with the slightly different Computer Name Override screen,

So, here the Deployment Console can't find the computer in the database, so ImageInvoker knows it must create a computer object for it. By default the serial number is used, but you can of course override this.

This is fabulous for deploying new machines.

Overriding Menu Item Names for Jobs

Sometimes, you don't want to present the exact job name as the menu item text in the client interface. Perhaps you have a very technical naming convention which you don't want to needlessly expose to your helpdesk staff. ImageInvoker has an menu text override system to cater for this.

If you don't want to use the job name as the menu text for a job, the override is to set a description for the job. Once you've set a description, run the ImageInvoker Menu Creator from the Altiris Tools menu to refresh the client menu file.

Figure showing how menu item names can be overridden using the job description field

Overriding Menu Item Names for Job Folders

As there is no description field which can be added to folders, the mechanism I've gone with for override job folder names is to create a dummy job.

• Create a job with the name (MI) and place it in the root of the menu item folder
• Put in the description field your menu item text
• Add to the currently empty job a single run script task
• In the Run This Script box, enter in the text REM MenuItem and ensure the job is configured to run in Windows
• In the Script Run Location inset, configure the script to run on the Deployment Server, and uncheck the box to Run when the Agent is Connected

This job therefore does absolutely nothing, and will not impact on your deployments. Its sole purpose is to provide this mechanism to give you a menu item name. Re-run the ImageInvoker Menu Creator from the Altiris Tools menu to refresh the client menu file.

Resource Overhead

I've tried to make the footprint of ImageInvoker very small. In my environment, the service rarely uses more the 10MB of RAM, and the CPU utilisation is negligible (it mostly sits at 0%, and occasionally will move to 1% when processing files). If you notice anything different, then something is probably wrong, and I'd appreciate a PM, or a post back to this article.

In the current version, ImageInvoker is single-threaded. It has not been tested under mass-deployment scenarios.

Limitations of the ImageInvoker

Currently ImageInvoker ONLY supports Linux automation. DOS and WinPE support will follow, but only once I'm sure the service is stable and any bugs found are ironed out. So, if you think this would be useful for you, but you use DOS and/or WinPE as your mainstream automation environment, please try out this Linux version. Yes, it might not be of much use to use in your production environment, but the more feedback I get, the faster I'll be able move on the DOS and WinPE menu programs.

At the moment, ImageInvoker has only been tested on Deployment Server 6.9 SP2. I hope to officially add support for other versions as time progresses, but it would be useful to know of any horror/success stories on other Deployment Server versions.

Things to be aware of....

In order for the imaging program to begin imaging client computers instantly, i've built into the server-side service a routine which clears out any currently scheduled tasks on this computer. This is important -you don't want to have your computer 'stuck' because there is a pending job to be executed within Windows which it might not ever get the chance to boot into (in cases for example where the computer OS is badly broken). So, when you see pending jobs being deleted -this is why.

This also means that if you schedule an incorrect job from the menu, that after a quick reboot with automation you can select the correct job. Any jobs previously scheduled from the previous menu choice will be automatically deleted before the new ones are scheduled.

I should add that the Linux code in this Beta expires in Feb 2010. This is purely to reduce the overhead on my time with people mailing in the future about bugs in an old version (which would have hopefully long since been resolved). The answer will always be to upgrade. Once the whole thing is stable,  I'll remove the  code expiration.

ImageInvoker Logs

ImageInvoker can be found in the eXpress share, in the ImageInvoker folder. There is a logs subfolder which can be useful if you hit any problems. There is also an imageinvoker.log in the root of the C: Drive which is written to for critical problems. if you hit have any problems, screenshots and these logs will be helpful.

Uninstalling ImageInvoker

ImageInvoker should uninstall from Add/Remove programs cleanly. uninstalling should remove the service, the files and ImageInvoker menu creation item from the Altiris Tools menu. The only items left on your system will be the logs, and two custom SQL functions in the eXpress database. I could amend the wise scripting to remove these functions and logs... a thought for a later release perhaps!

Summary

ImageInvoker is hopefully a very simple to install add-on for Deployment Server which gives you the capability to image your computer estate from an automation menu. What jobs (or job folders) your clients see as menu choices are dictated by introducing a special string tag of (MI) into your job (or folder).  By following a simple set of steps in the resulting automation  Client Menu Wizard, you'll be able to give your IT Staff the power to image computers locally without them needing to login to the Deployment Console. The Initial Deployment feature is especially useful for new computer deployment as you are free to choose your computer name live at deployment time.

The limitation of supporting only Linux automation I hope to rectify in time, once I'm sure the service foundation is stable.

Currently, I have only tested ImageInvoker on Deployment Solution 6.9SP2. It should work well with other Deployment Solution versions in the 6.9 branch where the Linux automation startup folder in the root of the Linux filesystem exists and it's contents honoured. This presence of the startup folder means we can call imageinvoker before the Deployment Agent is loaded, allowing us to schedule all the necessary jobs before the agent is called to initiate them.

Versions below DS6.9 sadly won't work because of the reduced functionality of axsched in these legacy versions. If there is demand, I might ammend the service to get this working with these older DS versions.

I hope some of you out there find this as useful as we have. I love it!

Kind Regards,
Ian./