I will be curious about the responses as well.  This is something we've thought about and even tried.  We've also wanted to setup a separate partition and keep an image on that partition but then we realized we have too many script jobs after the fact so that wasn't an option either.  So.....I'm going to watch if there are any responses here.

I wouldn't be opposed to it.. Sort of like a software portal but for images.

 Hi Spazzen,

I'm now working something similar to the above, but my menu system is designed to call DS jobs, rather than images. We can't use a simple rdeploy call, as our HII process requires lots of tasks in addition to the imaging to produce a bootable system. On top of that we also have a post-deployment software installs like the Altiris Agent, Antivirus etc....

But, for anyone reading this who only needs images to be called (not DS jobs) then give spazzen a prod!!

So, progress at my end so far... Got a prototype system up and runnning...

Client Automation

1. Have statically compiled a Linux menu program (my automation of choice is Linux) so that it works across all Linux environments as it no longer has any shared library dependencies
2. Ammended Linux automation to fire up (on keypress with timeout) a menu driven from a text file on the express share
3. Have the linux menu script dump a text file in /express/temp  
    

Server

1. Created a vbscript to search the menu temp files. Use Axsched to schedule the specified job (or folder of jobs) instantly. Lots of SQL to locate computer and jobs uniquely.

ToDo 

There is still a ways to go.

1. I'm not happy yet with the file format parsing i've used for driving the menu program. Each line has the syntax,

   Display Text, Menu Index, Job Folder Name, Job Name

   Currently if the jobname is ALL, then all jobs in that folder are scheduled. The parsing program splits these options into an array (delimeted by the commas). I think regex is perhaps a better way to go.
    

2. The vbscript also needs more error checking/logging at the moment.
    
3. I also need to ammend the SQL so that when using the ALL option, subfolders are parsed for jobs too. Currently only jobs in the specificed folder are scheduled.
    
4. For robustness, I need to slam in some SQL to delete any existing scheduled jobs before scheduling the ones selected.

The current prototype script has been active for a few days now and seems stable. Will fire back an update onces i've ironed out the outstanding regex and SQL work.

Kind Regards,
Ian./  

This is just to let you know where I'm at.

SQL
I've now finished the SQL side of the house. Now any existing scheduled jobs will be cleared from the client prior scheduling a job (or folder of jobs)  from the imaging menu.

Logging
I've increased the logging, and moved the ini files to good and bad subfolders once they've been processed.

Initial Deployment
I've also resolved an issue which popped up today with computers which aren't in the database. Menu driven ini files referring to computers not currently in the database will no longer be instantly moved to the bad folder. Instead they will modified with an iteration number. Only when a such 'initial deployment' type files have been through the grinder 60 times will they be moved into a bad folder.

Whats left
This leaves to do some work with regular expressions, and perhaps packaging up the code properly. I can only spend a little time each day on it, but with luck I should have something in the connect downloads this time next week.
 
Kind Regards,
Ian./

This is turning out to be a blog, so apologies for that.

The last couple of days i've spent creating a little client-server exchange in the menu interface to allow a verification of scheduling for imaging computers not already in the database. As all this has to be done before the agent is loaded, I've had to create some simple comms which allow the client computer to tell the server the destined computer name, MAC Address, SMBIOS UUID and Serial Number.

This has been a little complicated, but it removes the initial deployment problem where computers not in the database have to wait until the agent is loaded in order to get there. Now the client-server exchange built into the menu takes care of that transparently with instant feedback.

I'm going to leave the regex string matching for a later version.

I need to now add some error feedback from the server into client menu, so that if there are problems scheduling the jobs the client gets notified. This should be simple, as I can piggy-back in the client-server exchange I've just implemented.

After that, it time for the laborious Windows and Linux code tidy-up.

Here's some screenshots of where its at. First, here's the screen of the menu a new computer sees after activating the imaging menu after booting into Linux automation,

This 'job' selected above, actually refers to a folder of jobs in the console. Once this is selected, the menu program checks with the server to see if the computer already exists. If not, the following screen is presented,

  And here i've set the computer name to be test2. Now the menu program contacts the server with the computers identity data and the jobs it was scheduled,

After a couple of seconds, the following screen appears if all the data recieved by the server is sane and the job has been scheduled,

 At this point the menu program exists, and the Altiris Agent loads. When the agent contacts the server, it sees a computer object with a bunch of preloaded jobs so off it goes,

And all this without touching the console. The improvement over initial deploy is the setting of the computer names on the fly and a menu selection which allows folders of jobs to be scheduled.

For machines already in the database, they can now be re-imaged without using the initial deploy force switch which pushes the computer out of your nice groups hierahy into the root (as if it were a new computer).

After making a few more improvements, I put this into production onto one of our subnets today, so can now sit back and relax. ;-)

I'll start writing the juice download for this next week, but will hold off posting it until I am sure the IT dudes have worked it through its paces enough to be sure its stable.

Kind Regards,
Ian./