The Tivoli Endpoint Manager is a fantastic way of controlling your infrastructure from one central location. One of the most basic skills is activating a task and direct it to do something on an endpoint. Here is a step-by-step for activating a task to perform an action on an endpoint.
First find the task you wish to activate, in my example I will be installing a service onto one of my root servers. Select the task to be activated and click the Take Action button…
Here is our targeting screen… Since I’ll only be installing this service onto one endpoint, I’ll simply select it out of the right side computer list. I could just as easily choose the second radio button called “All computers with the property…” which allows me to target based on endpoint properties, or even “The computers specified in the list…” which allows me to type endpoint hostnames in one line per endpoint. Note that the third option should be limited to <100 endpoints. If you need to target more than that you should utilize the computer groups feature.
I’m very happy with the defaults on this particular task, however the Execution tab will allow me to start a task at a particular time, have it run between certain hours and even control the failure/retry activities of this task. Try not to restrict these options to much… for example, you wouldn’t want to limit the run between to 10min since the larger your infrastructure the more difficult or impossible that will be to happen.
In some cases your action will interact with end users and you may need to prevent the action from running if no user is logged in. The following Users tab allows you to constrain the task to only run with certain users…
Other cases you’ll want to present messaging to the end user or even allow the user to control the processing of this particular action. Maybe you’ll allow the user to determine when the most convenient time for them to have a particular action occur. This screen is used for that purpose…
Here we have the screen to Offer the user this optional action…
What if your action requires a restart, and you want to allow the end user delay the restart till it’s convenient for them.
Rarely will you need to change the Applicability tab. Occasionally I find it necessary to alter the default behavior of an action on a one time basis. This tab allows me to force the installation of something ignoring the default applicability relevance of the original task.
If I’ve modified the applicability relevance, I’ll need to modify the success relevance as well…
Lastly we have the ability to modify the default Action Script of this task. 
Once you’re all done modifying the action… click the OK button at the bottom and you’ll be asked for your credentials. (FYI: This is no longer the case in v8.2 unless you upgraded from a previous version or you enabled this validation step)
Our task is now activated and the action status window appears. Here we can monitor the progression of our action to each of the endpoints… on the Computers tab we can see status details on individual computers.
If you have any questions or comments, please leave them below!
danielheth 
I was thinking of putting together a video to do this very thing… anybody interested?
So glad I came across you blog Daniel and perhaps you can answer a question or two…
Q1 If i wanted to deploy adobe reader and want to control settings such as turning off the auto update in adobe reader, can I do that using scripts in the action scripts tab?
Q3 assuming you can do the above, are these action scrips reusable, as in save it with a meaningful name and then use it when you deploy a later version of Adobe?
cheers
Bryan
Deploying adobe reader shouldn’t be a problem. I’ve built a task that did that, unfortunately my lab crashed and I don’t have any examples to provide right now.
Once built, you can save it as a task or fixlet.
Actually this leads me to send you over to another one of my sites. Since the crash of my lab, I was frustrated at finding tasks I’ve built and didn’t know where to look. So I build a Content database which acts as my bag-o-tricks for situations just like this.
I’m putting any/all of my fixlets/tasks, analyses, and relevance (BigFix language). It’s open to the public to help everyone… http://BigFix.me
Its being built as a community so anyone can contribute. If someone builds such an adobe distro task, it’d end up there.
Bryan, I did a tiny bit of research into my lab console (in my lab i’ve got nearly every feature of our product activated).
Within a site called “Updates for Windows Applications” are a multitude of Adobe configuration and update tasks. There are no deploy tasks because, from what i remember, BF corp doesn’t accept EULA’s on behalf of customers. IE: adobe updates don’t have EULA’s other than use at your own risk. But an install/deploy task requires the acceptance of a EULA.
That said, it doesn’t mean that an install/deploy task can’t easily be created using either the “Windows Software Distribution Wizard” or writing a task from scratch.
I plugged my bigfix.me content database because I’ve built alot of fixlets/tasks that go beyond what is provided OOB. Things like deploying “Baretail” and “Notepad++”. Since I’m a big fan of PowerShell, i’ve even written various PowerShell content and even a PS Module.
Hi Daniel, do you know any way when you create the software packaged to specify “RUN AS ADMINISTRATOR”…. I have some installation script that I am NOT supposed to modify and even if I am admin of the machine… won’t install if I don’t “Right click / run as administrator”… I won’t install with bigfix because of that..
Thank you
I am not sure it is that fantastic. You cannot run an IEM task under an AD account. That restricts IEM’s capabilities to only things that can be done locally.