ImageInvoker is a handy Deployment Server (DS 6.9) add-on designed to reduce the TCO of using DS in your environment. It provides a self-service imaging interface in automation, a deployment portal if you will, so that desk-side IT staff can schedule the immediate deployment of images without requiring the assistance of a DS administrator.
If you find ImageInvoker useful,
All this is critical in providing use case scenarios to Symantec so that they can see how useful this functionality is. Only if you make yourself heard will there be a chance for Initial Deployment to be enhanced to encompass this functionality in DS7.
Version 0.4 of ImageInvoker resolves the following issues raised with the 0.3 release,
As this release does not include new functionality, please read the notes on the 0.3 Release Notes for instructions on installing and configuring ImageInvoker..
That was my initial thought, as well. However, we only use the serial number as the primary lookup and the problem still exists.
Ahh... I suspect the only way to get around this at the moment is to have a server-side task at the end of your imaging sessions to delete the computer object from the database.
This will stop you from getting what ImageInvoker sees as a potential hardware conflict. As a failsafe you see, ImageInvoker will not deploy a machine if it thinks there is potential for conflict (and therefore introducing the possibility of deploying to an incorrect machine).
Can you PM me so I can get a zip of your ImageInvoker folder? I might not get back to you for two weeks though as I'm out-of-office just now.
Kind Regards, Ian./
We have the same problem here with some IBM X1 Carbon Ultrabooks - they use an external USB 2 Ethernet dongle, so if they try to use the same dongle to image multiple machines, this happens. I've not done much trouble-shooting except to enforce ordering a dongle with each of these machines and imploring them to keep that dongle with each ultrabook. (deleting the errent duplicate ent ry when necessary).
This also may be the way that your DS is setup? I think the default primary lookup is serial number + MAC address. Wonder if it would help to change to just serial number?
I was able to get an extra tablet and recreate the issue. Here were my steps...
1. Use Invoker to image tablet named CORP-G-YA41468
2. In same docking station, try to use Invoker to image tablet named CORP-G-YA41530
3. Invoker asks me to choose the imaging job
4. Invoker pops up error (see attached screenshot)
At this point Invoker does not present me with the option to rename the computer. My only option is to delete CORP-G-YA41468 from the database and try again.
Hi Ian,
Thanks for the response. I can't remember the exact outcome and I don't currently have the right hardware available to me to test it again, but I don't think it will let us continue the imaging process. I believe that it errors out, or it replaces the previously imaged PC in the console with the PC that is being imaged. Either way it doesn't work for us.
I'll see if I can find some extra tablets laying around to find the exact problem.
Hi Derek,
You are correct, ImageInvoker does look machine's up by MAC address. The laptop doc scenario is not one I'd considered.
However.. as you can only image on computer from a doc at anyone time, does it matter that ImageInvoker already believes that the computer object already exists? In short... Is there a reason why you can't rename through the ImageInvoker interface and just plough on?
Hello,
I believe I have an issue with the way Invoker is looking up machines in the database, and I am wondering if somebody can help or offer an alternative method.
We have several thousand Panasonic Toughbook devices that do not have their own internal NIC card, and in order for these machines to be imaged they have to be plugged in to a docking station. So, at any given remote site, they might have 50 of these machines and only a few docking stations.
I might be wrong, but I believe Invoker uses the NIC's MAC address to look for existing machines in the database. So, when we use a single docking station (having its own MAC address) for multiple machines, Invoker does not like this and says that the machine already exists.
Is there a way to have Invoker use the serial number for lookup instead of the MAC address?
Thanks
Hey Guys,
For anyone wondering how this awesome application behaves on Deployment Solution 6.9 SP6 with WinPE 4.0. I can verify that it works 100% with DS6.9 SP6 WinPE 4.0 (x86)!
Our setup is as follows:
-----------------------------------------------------------------
Operating System: Windows Server 2012 R2
SQL Instance: SQL Server 2012 Express
Deployment Solution: 6.9 SP6
Preboot Enviornment: WinPE 4.0 (x86)
The only adjustment we had to make over the original configuration was to use domain account credentials for the Image Invoker service instead of the local administrators account. For whatever reason it did not want to schedule the job when the service was running with the local administrator credentials.
Hope this helps anyone thinking about upgrading. Enjoy!
Unfortunately not. Symantec tied down a lot in the way that automation communicated with SMP with regards to DS in 7 which made porting the code quite a challenge.
Hi, Do your tool can run on DS 7.1?
I've been keeping an eye on this project for a couple years now and finally took the plunge!
We were using a DOS boot image with the forcenew switch to provide an image selection menu and WinPE to do all the work. This has been getting harder to maintain with newer devices that don't provide DOS NDIS drivers, so the switch to WinPE was inevitable.
So far, loving the product - local support doesn't like waiting the minute or 2 for PE to load before they can select an image, but in the long run it'll save time on DOS DHCP and memory issues.
Only problem I'm having so far is that I'm getting an Error 75 occasionally after selecting the job from the menu. This seems to indicate an issue writing to the logs, but i can see the logs being created - possibly a contention between multiple devices being built? If we try the same machine, it usually goes thru fine on the 2nd try.
What they are talking about is just the 'Initial Deployment' mechanism. In DS7.2 (just in beta) this is now been enhanced so you can 'Re-Deploy' existing machines, as well as the classic 'Initial Deploy' of new ones. It's a step in the right direction, but at the moment it lacks the password protection and a computer rename facility.
Single line? Do tell :)
It won't cover all of them due to our rather lax practice of not always moving computers to their correct DS groups (as we use name or IP filtering to pick out our target PCs), but it'll cover a good chunk of them.
I can also use AutoIt to do some SQL extracting, so I can - in theory - get a note of the workstation name and (presumably?) its IP, the unique DS ID etc.. So I can probably get it to compile the BAT job mentioned in your article...
In terms of 7.1..
A while back when our company was being shown 7.1 with a view to moving to it, I did see a comment on the notes (possibly for SP1?) that one of the features which may be available is the ability to schedule jobs from F8 prompt. Or words to that effect.
That - to me - sounded rather like ImageInvoker, but I didn't get the chance to ask exactly what that line on the notes actually meant or how it'd work.
If your computer's in DS are organised into folders suitable for to drop a job to set the package server (normally this is the case as admins tend to create DS groups to reflect geographical structure), you can accomplish this with a script of a single line.
On ImageInvoker for 7.1, I am wildly hoping that Symantec sort this out. Just a little password lock, a computer rename screen, and a little Linux support is all that's now needed to make Initial Deployment entirely client driven.
(Odd - no email notification of a reply - anyway)..
Thanks for the SITE suggestion.. I'll investigate adding that to our deployment jobs.. If nothing else, it perhaps gives me an idea on how to bulk populate the existing ones by some exporting of SQL to a TAB delimited file and some cribby AutoIT scripting to generate the script which is run on the DS...
Just rambling to myself :)
Your new version of ImageInvoker sounds good.. I'm also very interested to read you're looking at 7.1 since we're also looking at moving to it and the thought of losing ImageInvoker doesn't sit well (suck up! Ed).
Hi Gerard,
Hi, Ian..
I ran into a small issue today that had me scratching my head - mostly due to lack of coffee, I suspect.
I renamed a job I'd created a while back to include (MI)
Ran the menu regenerate
Ran ImageInvoker on the client
Selected the job
It looped on Job being scheduled.
ImageInvoker-2012-2-27.log started growing with loops of:
27/02/2012 10:48:29 - START: Located Ini file F0DEF1BC585B.ini for processing... 27/02/2012 10:48:29 - INFO: Processing Ini file F0DEF1BC585B.ini, 27/02/2012 10:48:29 - INFO: MAC :F0DEF1BC585B 27/02/2012 10:48:29 - INFO: UUID :EF4B6681-51CE-11CB-A766-B0E63EBEF69C 27/02/2012 10:48:29 - INFO: S/N :R9L1HPV 27/02/2012 10:48:29 - INFO: NewHostName :LTEREX220-01 27/02/2012 10:48:29 - INFO: Name Request:no 27/02/2012 10:48:29 - INFO: Folder :Windows 7 27/02/2012 10:48:29 - INFO: Job :Deploy image of Sysprep'd 7 PC (MI) 27/02/2012 10:48:29 - INFO: Computer LTEREX220-01 found as match for MAC F0DEF1BC585B 27/02/2012 10:48:29 - INFO: Checking that intended Computer Name is unique... 27/02/2012 10:48:29 - INFO: Indended Computer name of LTEREX220-01 will not clash 27/02/2012 10:48:29 - Single Job Mode: Executing query to find job 27/02/2012 10:48:29 - ERROR: Error in STAGE10 (Create job list) in Module1{Process_IniFile}.
You've probably already twigged from the above what was causing it, but it required a cup of coffee and some testing of other jobs on different PCs for me :)
After some head scratching and basic troubleshooting, I realised it was the job name which was causing the grief. Removed the "'" and all was well.
If it isn't possible to fix the invalid character parsing, is it possible to update the regenerate menu so that it warns you if invalid characters are found in the job name?
Cheers,
Gerard
PS.. I realise we still haven't chatted about the SITE population - things have been a touch manic since.. Ooh, round about forever.
I tried a guide here:
http://reboot.pro/11852/page__st__231
Which is how to apparently get BEEP working with PE3.
I got as far as having the beep.sys be part of PE's Windows\System32\Drivers folder.
I couldn't figure out where within Altiris you add the reg file they refer to here (which is - as near as I can tell - just a grab of the two reg keys from an XP workstation).
I tried exporting them from XP, importing them to my PE with regedit /s [reg file] and they did import but nothing much happened.
I tried "Net Start beep" after importing them, but it doesn't see beep as being a service - so I assume I need some way of including these registry modifications as part of the PE disk when it boots, but I can't see how to do that within PE's boot disk creator?
@Jessicah -Good use case. Will look into providing an option to omit the computer rename screen.
Hi Tommy,
I have plans and ideas for implementing, but this work hasn't been timetabled yet as I have other projects here taking priority.
I hope to get started on this before the end of the year.... which means a protoype by Easter given my current workload...
Hi Ian!
Thank you for a great product!
Do you have any plans to make this available for DS 7.1?
i downloaded a couple beep.exe's from the net in different forms, but none of them worked in winpe for me. maybe winpe doesn't support system beep. If you get it working, please share how you did it!
hey that's not a bad idea. and it ought to be easy to add too since i think it's just BEEP.EXE. if you can find and call that from menu.bat right before the II exe starts, this should acomplish what you want! and i think it's a great idea since it'll make it harder to miss that prompt. winpe sure can be slow to boot sometimes!
I just realised that I hadn't posted here to say THANK YOU for the update. My Summer reimaging was made a GOOD bit less painful thanks to ImageInvoker. Just not having to create predefined computers made it worth it alone!!! So my dept owes you a pint, good Sir!
I have one other possible request - and please feel free to tell me I'm being stupid :)
Is it possible to have an option whereby ImageInvoker Client makes a BEEP when it starts? This is a purely selfish request based on my experience of launching it on groups of PCs at a time in a suite while doing cable tidying at the same time. I missed the timeout a few times and had to reboot.
I know I could fudge my PXE boot disk to run a beep utility before running the Client, but I figured it might be a feature others would like?
Just a thought :)
Thanks again, and keep up the excellent work.
Regards,
i wasn't being that granular in my testing. it makes sense that it'd only need to write to express\temp and express\imageinvoker\logs but i didn't bother testing that thoroughly. in our next wave of security review, i'll try to remember to touch this, but at the moment it's still better than it was before... "everyone" no longer has "full control" of the entire express share as it did by default, so that's always good. :)
Hmmm... It should be just the .\eXpress\ImageInvoker\logs folder, and .\temp as with the previous version?
Edit: from a quick scan of the 0.3 notes, I can't actually see any documentation of permissions. Oops. But, as I said the write access is only required for log comm files.
We recently started stripping excess permissions from all of our shares and in the process discovered that ImageInvoker needs to be able to write to the express share. So whatever account your WinPE uses, make sure that account has at minumum "change" rights to the express share. Read only isn't enough. With it in just read only, you will get Runtime error 75 when trying to select a job from the ImageInvoker GUI in WinPE.
I don't know how this affects II in linux over PXE, as we don't use it here, but i suspect it'll have the same or similar issue.
In my environment, it would be preferrable to be able to completely omit the computer naming steps.
The DS jobs I have created for imaging includes using ReplaceTokens to query one of the databases containing asset information to match a mac address to a hostname, and injecting that into the sysprep files at the completion of imaging.
So being able to omit all the prompting for computer names would make this tool useful for distributing to workshop technicians to allow them to re-image stuff themselves in a very self-service kind of way.
ImageInvoker seems to work just fine on DS 6.9 sp5, running on server 2008r2 enterprise (x64 of course). Granted, I've only imaged 2 machines with it so far, but it works! Wahoo!! The techs are gonna love this!
I'll echo Ian's comments. No reason ImageInvoker shouldn't work with your setup. As far as I see it, if you can boot to automation and schedule the job via ImageInvoker, that's it. Beyond that ImageInvoker is out of the equation and any failure to actually launch the job is most likely a different issue.
I'm not sure what TCs you are using but we've got a good number of HP t5740e clients that work just fine with ImageInvoker.
Best of luck to you getting that stalling figured out!
plaincoIT -I can't see a reason why ImageInvoker would stumble on thin-clients. In essence, it's just proxying requests from the client to schedule jobs server-side. It is interesting that you can schedule a job, but the client isn't running it.
Is the client registered in the console as connecting? If you reboot the client and enter automation again (without entering ImageInvoker) does the job execute then?
As for how ImageInvoker works -see the Developing ImageInvoker articles. And you're right -it's a heck of a lot of work!!
Ian,
Love the concept behind this utility! I've been running just a simple bash script that auto detects what thin client its on and prompts our technicians for the images that are only for the thin client they've currently booted up and once selected it launches rdeploy from the ds share.
When I came across this tool which basically mimics what mine does my stomach nearly fell to the floor! I'm assuming you invoke rdeployt just as I do from my bash script but the GUI and custom naming "pre-image" really bring the whole thing together.
My question is do you or anyone else know if this works well with thin clients? We use CE.net and XPe based HP thin clients and upon my first try of ImageInvoker it boots up and I can see the MIs I've designated in DS Console, and I can change the name but once its done it seems to exit ImageInvoker and just sit there at the command line. However I do notice that a job gets created in the DS under the name I just specified but it appears like nothing happens.
Thank you for this amazingly polished tool and your obvious hardwork involved in creating it!
Thansk for this new version ;) Great !
Take a look at Part 6 of Developing ImageInvoker -although this covers how it's done in new version with AD Auth (currently under test) should help clarify how the scheduling is done.
Great Work!!
I dont know if this was ever answered but how do you handle the scheduling, straight sql? I was using a similiar method with the scheduling agent.
Good to hear you're pleased....
Let me know how it works out -this version has had as much testing as I would have liked. I've updated the description above as some use cases might prove useful getting something like this rolling into a future DS7 release.
Thanks Ian!!! You Rock!!