Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Developing ImageInvoker for DS6.9, Part 1

Created: 14 Dec 2010 • Updated: 14 Feb 2011 | 16 comments
Language Translations
ianatkin's picture
+4 4 Votes
Login to vote

Now that Christmas approaches, its time to get back into the swing of ImageInvoker. Normally I'd just get on with it, and throw out a couple of blogs and comments as I progress. This time however, I thought I'd try a different approach and write some articles as I go. The idea being that this approach might,

 
  1. Provide others the opportunity to provide input into the development cycle. 
  2. Generally enlighten as to how DS and ImageInvoker works. 
 
Despite previously saying that ImageInvoker will no longer be developed for the 6.x branch, this series of articles represents a bit of a u-turn -the focus is entirely on improving ImageInvoker for the 6.x platform. Whilst there are some niggles with version 7, there are admittedly no technical reasons why ImageInvoker could not be ported. What's holding me back to be honest is that I don't yet have enough familiarity with DS7 to be sure of the best approach. My hope is that by the time DS7.1 SP1 is released with Hampton next year, I'll have a good idea of the direction I'll need to take.
 

Background

In order to explain the direction ImageInvoker will be taking, it's useful first to provide some background for the changes I'm going to be introducing. The Deployment Server implementation we have here with our ICT Support Team is based on a federated model. In the center we have a library DS which is our a package and image factory. Packages and images are here made to specific standards, are tested, and are then ratified for departmental consumption. Once these jobs and images are ratified, they are syncronised across to the departmental Deployment Servers.
 
This syncronisation is a little smarter than a bare job export/import,
 
1) It preserves job history
2) Provides each department with it's own specific job and image feed.
 
This scoped syncronisation enables ImageInvoker on each departmental server to contain jobs specific to that department only.
 
The primary reason for introducing a federated setup back in 2006 was performance. We found that when security was enabled on a Deployment server with 2500 computers, console performance plummeted to a frustrating level. At that time, the console was the primary entry point for delivery images (ImageInvoker hadn't been invented yet), so the immediate solution was to divide the computer estate across several servers -one for each department in fact.
 
Now let's move forward one year. The federated setup was working well, but we had a problem. Getting IT staff trained in Deployment Server just so they could image computers was just not feasible. As a result, more and more of my time over the last year had been spent hand-holding rollouts, staging computers and general troubleshooting. This was the fertile ground that nurtured the development of the ImageInvoker engine.
 
Skip forward another year. The introduction of ImageInvoker onto the departmental servers had resulted in a dramatic shift in working practices.  The DS console is now the secondary entrypoint for computer provisioning.
 
As 2011 approaches, CMS7 is beginning to show promise. So it's time to take stock,
  1. Going forward, DS7 isn't really suited to the federated library model that exists in the DS6 branch.
  2. Our primary entry point for provisioning computers is no longer the console
  3. Significant console performance improvements with respect to security have been made in the 6.9 branch

All this means governing our estate from a single Deployment Server on the DS6 branch becomes feasible, and if ImageInvoker changes too it might even become practical. This should hopefully put us in good stead for the eventual move to DS7.
 

Where ImageInvoker needs to go

In order to begin this work, ImageInvoker needs to change. The current incarnation does not implement permissioning, and is cumbersome to use when more than a dozen jobs are introduced into the client menu.
 
The following improvements are therefore on the cards.
 

Authentication

Currently the only authentication I implement in ImageInvoker is an optional password menu-lock. This uses MD5 checksum comparisons to decide whether a client computer can access the menu. This needs a huge overhall. I want the future authentication options to be,
 
1) AD Authentication
2) Local server authentication
3) Single Password
4) No authentication
 
This is a big change, and one which fills me with dread...
 
 

Menu Generation

At the moment the client menu which is generated by ImageInvoker is flat, has no security scoping, and requires a manual process to ensure it's up-to-date. This has to change as follows,
 
1) Menu generated on-the-fly and according to permissions
2) Menu tree for logical navigation through to target jobs
 
 
The whole thrust of this is to make ImageInvoker more suitable for the enterprise environment, which shockingly is one we are about to adopt... ;-)
 
These changes nicely fit into some of the most common enhancement requests I've had for ImageInvoker, so with luck the final result will be to everyones gain. 
 
 

First Step -Moving away from the Flat Menu Structure

I've been mulling over the job logic over the past month whilst on the Hampton Beta program, and I've got a direction in mind now. Currently, if I had on my Deployment Server the following Menu-Item tagged job folders,

  • Deploy Server 2003 x64 (MI)
  • Deploy Server 2003 x86 (MI)
  • Deploy Win7 Public Access Computer (MI)
  • Deploy Win7 Staff Computer (MI)
  • Deploy XP Public Access Computer (MI)
  • Deploy XP Staff Computer (MI)

No matter how buried these are in folder and sub-folder hierachies, they might as well be flat as the resulting menu is flat,

This is fine when you don't have many Menu-Item tagged jobs and job folders. It gets to be a bit of a pain though when you have a fair few of these. An obvious way to create a navigable menu within the ImageInvoker client is to have this mirror how the client jobs prepared in a tree on the server.

However, it might not make much sense though to navigate the entire console job tree when locating your jobs in the client. Further, the filing structure used by your image gurus may not mean very much to the helpdesk crew on the ground. So, to give the flexibility of a human-readable navigation structure then, we need to create a root. Let's call that root folder ImageInvoker.

In that case, we rearrange the above Windows OS deployment folders as follows, which would give (with artistic license) a Client menu as follows,

 

For those that  prefer a flat structure, you could always throw the Menu Item tagged jobs directly into the ImageInvoker folder, without the subfolder divisions.

Next, we'll need some SQL to enumerate this folder structure. Thinking out load, I need to,

  1. Enumerate first all jobs under the ImageInvoker folder, storing the job id and the parent folder id (where MI in string)
  2. Enumerate all folders under the ImageInvoker folder, storing all folder ids and parent_folder id (where MI in string or not)

First port of call is to identify the Folder ID of the ImageInvoker folder. This is satisfied by the following T-SQL,

 

 Declare @RootFolderID int

set @RootFolderID = (select top 1 folder_id 
from event_folder 
where name ='ImageInvoker' and parent_id Is Null)

select @RootFolderID 
 
So in order to find our jobs and folders which exist in this structure we can use the following T-SQL,
 
 Declare @RootFolderID int

set @RootFolderID = (select top 1 folder_id from event_folder where name ='ImageInvoker' and parent_id Is Null)

select @RootFolderID


/* Find (MI) tagged jobs under ImageInvoker folder */
select name, event_id,folder_id from event 
where dbo.Custom_IsEventWithinFolder(event_id,@RootFolderID)=1
and name like '%(MI)%'


/* Find all folders under ImageInvoker folder */
select name, folder_id,parent_id from event_folder 
where dbo.Custom_IsFolderWithinFolder(folder_id,@RootFolderID)=1 
 
Where I've used my handy functions dbo.Custom_IsFolderWithinFolder and dbo.Custom_IsEventWithinFolder which are always installed with ImageInvoker.
 
Each level of the menu can therefore be identified by the folder ID of it's parent -the first level containing,
  1. All menu tagged jobs with a folder ID of @RootFolderID
  2. All menu tagged folders with a folder ID of @RootFolderID (these being 'executable')
  3. All folders not menu tagged with a folder ID of @RootFolderID (these being 'navigable') 

And the T-SQL for that will be something like,

 

 Declare @RootFolderID int

set @RootFolderID = (select top 1 folder_id from event_folder where name ='ImageInvoker' and parent_id Is Null)

select @RootFolderID


/* Find tagged jobs in ImageInvoker folder */
select name, event_id,folder_id from event 
where folder_id=@RootFolderID
and name like '%(MI)%'


/* Find tagged folders in ImageInvoker folder */
select name, folder_id,parent_id from event_folder 
where parent_id=@RootFolderID
and name like '%(MI)%'


/* Find navigable folders in ImageInvoker folder */
select name, folder_id,parent_id from event_folder 
where parent_id=@RootFolderID
and name not like '%(MI)%' 
 
So here we've got a good start. We can now enumerate all jobs and folders within the entire tree structure under the ImageInvoker folder, or under any specific folder. At runtime, as the client connects, we should be able to provide any or all of this data as required.
 
I'm pretty happy with that as a foundation for generating the menu. The next step is scoping for the cases where console security is enabled...
 
Return to Index
 

Comments 16 CommentsJump to latest comment

murmansk's picture

We have a simple development that shows a corporative image with tasks and an unblock button with inmediate, semanal and per computer unblock codes. The user selects the task, and call our phone center for the required unblock code.

When the user has unblocked the task, a .bat file is launched for the selected task to deploy the image (just an rdeployt).

This is a simple development, that lacks the power of using complex tasks from the Deployment Server.

We have tested your ImageInvoker, and it works really well. It gives us a lot of flexibility while using all the Deployment Server functionality. But we would like to use our previous corporative image and menus. So:

¿there is any command line we could use to consult (IM) tasks and program one for a computer?

+1
Login to vote
ianatkin's picture

Hi murmansk,

If you take a look in the ImageInvoker log files, I show the axscheduler command lines which schedule these (MI) tagged jobs on computers. So, when the user selects their target job (or folder of jobs) this gets sent to the server where it's translated into an axsched task.

This might help you in the direction you need to go?

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

0
Login to vote
Gibson99's picture

Good to see further movement on this project, as I'm sure you remember I'm one of the ones wanting AD integration/security in ImageInvoker.  The menu item navigation would be nice, and I can certainly picture an environment where that would be useful. 

I'm looking forward to the version compatible with Hampton so that I don't have to use initial deployment.  I've never been real fond of init.deploy, but i have a feeling i'm going to be forced into using it, at least for a while, since it's currently being used with our ds 6.8 setup.

If a Connect post helped you out, be sure to click "Mark As Solution" or the "Thumbs Up" button to let other users know about it.

0
Login to vote
ianatkin's picture

Hi Jason -Yeah, I remember!! I've always been fearful of the AD integration side -never implemented this before. The authentication side is easy, but authorisation of what they can see and do I've always seen as being a tad tricky.... ;-)

I've pushed the use case scenarios to several Altiris/Symantec guys for enhancing initial deployment, and it has been captured. But, my feeling is this functionality is on a wish list rather than being imperative for implementation. And they see the 7.x implementation as being a tad tricky too... 

Will be sure to keep you updated!

Kind Regards,
Ian./

 

 

 

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

0
Login to vote
cnpalmer75's picture

Have you ever thought of moving this process design and integrating it into a Workflow for 7.1 compatibility?

You'd get a lot of the AD integration and SMP/CMS integration immediately using WF components to manage the processes.

Benjamin Palmer
Specialist | Client Design
Director | Symantec CT User Group

If you find this post helpful please give it a thumbs up!
If you find that this solves your problem please mark it as the solu

0
Login to vote
ianatkin's picture

It might be possible for the engine to move to Workflow. When the time comes for the 7.1 version I'll indeed be looking at workflow as a possible option. Instinctively, I'd be surprised if all I require were available through workflow however.

One thing at a time though... ;-)

Kind Regards,
Ian./

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

0
Login to vote
ciscoman's picture

Ian,

 

I am getting the following error when winpe_client.exe in menu.bat is run in Winpe automation mode-

 

"Run-time error 429 "

Activex component can't create object"

 

Any help kindly appreciated

 

Thanks

 

JD

0
Login to vote
ianatkin's picture

Hi JD,

Try uninstalling imageinvoker, and then reinstalling it. If that still doesn't work, give me a PM and I'll get the logs off you.

Kind Regards,
Ian./

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

0
Login to vote
ciscoman's picture

Ian,

The first step was to uninstall and reinstall the imageinvoker.That did not help, so I guessed it

must be the Winpe image.Deleted and created a new winpe image, works like a charm now!!

Thanks for getting back so soon and for creating the product.

Cheers

 

JD

 

 

0
Login to vote
Phyrant's picture

Ian, all of a sudden I'm getting the ActiveX runtime error mentioned above. Nothing has changed on my server. I'm uninstalled and reinstalled ImageInvoker and rebuild my boot images. Any help would be greatly appreciated.

Thanks

0
Login to vote
ianatkin's picture

Could you zip up the ImageInvoker folder for me and PM me with the location of where to get to it? 

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

0
Login to vote
ianatkin's picture

Hi Phyrant,

Everything here looks good to me. Could you try,

  1. Putting your x86 WinPE into a wait state (dump a wait job on)
  2. In the WinPE  command shell, cd into the folder Imageinvoker/WinPE
  3. Execute WinPE_Client.exe

This is just to see if you still get the activeX error.

Kind Regards,
Ian./

 

 

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

0
Login to vote
Phyrant's picture

Still got the activeX error but I think my problem may be bigger than ImageInvoker. When I try to image a computer it will boot to PXE but then just sit at Client Record Updated and the job doesn't ever start. In the DAgent service within PE on the client I never get a computer name or MAC address. Not sure what is going on since I haven't changed anything on the server in a long long time.

Also when running rdeploy manually within PE I can only run it on one computer at a time. The second computer says the file is in use. Never had that happen before. 

Now I have techs on me cause they need to image computers and imaging isn't working.

 

0
Login to vote
Gibson99's picture

i recently had to completely uninstall pxe and reinstall it on my DS for a different issue from what you're having (winPE, my only boot option besides "next device" would completely disappear from the boot config/menu any time the pxe manager service was restarted - such as when you reboot for patches).  

thankfully, the entire process only took about 45 minutes, including the time it took to rebuild my winpe environment. i did not have to reinstall imageinvoker - it was there already once i rebuilt winpe.  maybe worth trying in your environment too.  

look up articles on doing this - there's a VERY important step that's easy to miss, having to do with retaining the MMACCESSKEY setting from your old pxe.ini and putting it into your new one, so that your pxe servers will continue to talk to this new pxe instalation, without having to reinstall pxe on all your pxe servers (assuming you have pxe servers outside of the DS itself).

If a Connect post helped you out, be sure to click "Mark As Solution" or the "Thumbs Up" button to let other users know about it.

0
Login to vote
Phyrant's picture

I actually had our backup guy restore the PXE and Bootwiz folders on the server from the beginning of May when everything was working and all is back to normal. Still doesn't explain what happened but I'm just glad its working again.

0
Login to vote