Creating Helpdesk Tasks with Local Security Solution

Helpdesk Solution has a wonderful array of options to help cut back on some of the grief that your helpdesk staff might have. I've quickly learned that one of the fastest ways to get buy-in for a new product is by maximizing ease of use. Tasks are a great way to improve ease of use for your Helpdesk workers, especially when you are using new solutions.

In this article I'll show you how to access console resources for Local Security Solution by creating a new Helpdesk Solution task. With some additional research, some of these techniques can be used to generate tasks for other Altiris products.

Local Security Solution, I feel, is one of those underappreciated products that can be used in a variety of different ways. Part of its power comes from balancing that level of service and level of security that many organizations struggle with so much. However, it's a change in process that many helpdesk staff members may not like. Again, following the theme of maximizing ease of use there's not much easier than taking your workers directly to a list of users with managed passwords.

Articles have already been posted on forwarding your Local Security Solution information via Inventory Forwarding. This is a great idea and may be an essential step if you have a multiple Notification Server environment where your clients don't report information directly to your Helpdesk Notification Server. You can find that article here.

Let's start making a new task. (Again this information will be applicable for other Altiris tasks, I'm just using Local Security Solution as an example.) When you first open the helpdesk to your default worker page you should see a list of commands on the left hand side. You'll want to make sure you have Admin rights for the Altiris Helpdesk module before continuing. Follow the dropdowns to Admin > Tasks > New Task.

Click to view.

When you create a new task you'll have a few items you'll need to decide we'll go over each of these as we scroll down the page.

1. Name – this will be the displayed text on our incident. For our example I've chosen text to make certain that other workers that may notice the task it is still in development. Once finalized you can and should rename it to something meaningful that your workers will recognize immediately for what it is.
2. Consumer ID – The existing tasks from Helpdesk Solution have their respective solution listed here either Helpdesk or Real Time System Manager. I'm going to continue that by entering Local Security Solution.
3. Comment – This field is up to you. Many organizations may have standard items that must be included here such as who created it, when it was first created and possibly dates it was modified, which admin entered the modifications, and a short description of those modifications. We try to follow good programming practices by entering those remarks here. This however is not required.
4. Rank – Simply the order in which tasks are displayed. I'm leaving this at default.
5. Log to Incident – Not used for this example, but if you're using your task to "Create or edit an incident" instead of "Invoke a URL" you may want to select this option or its sub option as is applicable to your situation.
6. Active – will people see it?
7. Visible to guests – Should others see this task when using the winuser Console?
   
   

   Click to view.

8. Task is available – here are the parameters when a task is shown on an incident. Here you'll have to decide what fits into your task. Lists of fields that are associated with the worktitem table are shown. Some good items to key from here would be Title, Comment, Category, and possibly Type.
   
   

   Click to view.

9. When criteria are true – There are two options available that will define this section. This is essentially what you want to do with your task. You can "Create or edit an incident" or "Invoke a URL".
   • Create or edit an incident – this section has several options that are similar to Quick incident settings. Since we're focusing on Invoking a URL I'll encourage you to explore this section yourself. If you set the availability to something very specific such as "owned by worker" as your name then you can test without fear that others will let their curiosity cause you heartburn.
10. Invoke a URL – This option can give us several items that can be overwhelming. Often time we just don't know what those parameters will be if we haven't done a lot of in depth work with Notification Server. But have not fear you can always go to the item you're looking for and try taking apart its URL. Find what makes a difference for your items and replace those things with variables or as URL Parameters.
    
    

    Click to view.

    In the case of Local Security Solution I did the following URL:

    http://NSSERVERNAMEHERE/Altiris/NS/Console.aspx?ContentFrame=content5ce1ab02722b4c2f9e4080de346a122b&ConsoleGuid={4729B918-B345-420C-9DD7-F435B31B0C66}&ItemGuid=0c09cc91-82ce-430f-a9a7-6cb0189974c0&ResourceGuid=WORKITEM(managed_object_resource_guid)
    
    

    Notice the last item in the string is the ResourceGuid with a query attached to it. This is an example of a URL Parameter. Depending onyour preference you may put this information directly into the Base URL or you may enter it into the URL Parameters where ResourceGuid is the name and the value is WORKITEM(managed_object_resource_guid). I'll reiterate your other items will need to be changed, but in general a good practice to follow is using the console guid information for the item you're looking for similar to the information detailed in this Juice tech tip.

    Another item to notice is the NSSERVERNAMEHERE section. This can be set to any web server not just your Helpdesk NS. I've set it up to go to my Notification Server that manages the client machines directly. You of course could get really fancy and even have this information directed to a web service that isn't even Altiris related. I'd love to see some examples of that if anyone uses it please do share what you're doing.

    If you enter this information I've provided with the goal of making a Local Security Solution based task you may notice that I'm not going directly to the show managed user page. There are a couple of reasons for this. First of all I don't want to have a large number of accidental password disclosures. I'm re-randomizing passwords after they've been disclosed and an increase in accidental disclosures would increase workload on my Notification Servers. Secondly some environments may have multiple local users managed. Maybe there are other backdoor type accounts that more correctly reflect a user's privileges on a workstation. It's better to provide a list for these circumstances to provide just one more step so you know the choice was intentional.

The rest of our information will again be determined by your choice of tasks. For this instance I'm leaving everything the default way. If you're tying into another system make sure you're using the correct credentials. It could mean the difference between success and failure.

Finally save your task and test it out. Here's what I got once I finished.

Click to view.

Give your task a test run it through several different scenarios. Make sure it shows up when it's supposed to and only when it's supposed to show. In my example I also wanted to test against several different assets. Those credentials could be a sticking point so make sure you're using the right ones and be aware that in this example if you use application credentials it will show the password being disclosed to your application user, removing some security tracking features.

It's important to note for those of us that don't use many tasks (and for those workers that are often used to just editing incidents) that you will see those tasks when viewing the incident not when in the edit screen.

After certifying the task works as you expected make sure to go back to your existing tasks and rename it to something meaningful that will help workers recognize the function by glancing at its title.

Another step left out by many people, but I feel still heeds mention is training. Make sure your workers know when to use this new task. What will cause it to show up and what exactly does it do? Several times when creating new things we often expect people to just know what to do with it, especially if it was requested. Often that is not the case; workers still need some direction and guidance. Maybe there are important business processes or policies behind your task that may not be apparent at first glance. Always be cautious to explain this information to those who are affected. Our end goal here is to get buy-in for new or existing products. Ease of use is just one way we can accomplish that goal. However, without proper education of workers we are running the risk of causing additional grief instead of making it easier.

I hope you've found this useful. I have always found it is easiest to learn a new feature or product when you have a real life problem to solve. Find a goal that you think this will address, start small, and just experiment. If you've got a dev environment that's the place to start your tests, else you can always be discrete with these by getting very specific on rules of when a task is available.