Video Screencast Help
Symantec Secure Login will be live on Connect starting February 25. Get the details here.

Give Your Company's Upper Management the VIP Helpdesk Status They Deserve

Created: 02 Apr 2008 | 6 comments
Language Translations
Tenacious Geo's picture
+4 4 Votes
Login to vote

Those executives and directors have worked hard their whole life to reach the upper echelons of management. Isn't it only fair we reward them with the promptest of Helpdesk service? Most certainly it is!

The VIP status in the Contacts section of Altiris Helpdesk is no mystery--just a friendly little checkbox that bestows ultimate Helpdesk notoriety on lofty employees. Not to mention a flashy VIP animated gif that only a CEO could love. Oh look, it appears that Steve Ballmer LOVES the VIP status!


Distasteful photographs and animated gifs (so 1990s!) aside, the VIP status in Altiris Helpdesk is very useful. With a flick of a checkmark we can identify an important contact in our system--one that we might promise faster service.


Does that mean for all our potentially hundreds of upper management folks we have to manually click that check-box and keep it up-to-date as staff comes and goes? *gasp* Yes and no. Yes, if you are somewhat of a sadist. No, if you plan on utilizing this article. *sigh of relief*

Automation FTW!

With a few easy components in place, let's make Altiris do this for us, shall we? I have better things to do than click check boxes.

(Note: a pre-requisite for this to work is for all of your corporate big-wig people to be in their own security group in AD. I would assume most organizations have this whether it's for permission-giving or an Exchange group.)

Part 1: Import Security Group User Data

Let's use the built-in AD Import tool at "View > Configuration > Server Settings > Notification Server Infrastructure > Microsoft Active Directory Import". You probably already have an import rule for User and Computer objects. The one for AD Users, if it was setup like mine, was importing users from OUs. Let's create a new import rule for Users that will be for Security Groups data.

Click the blue plus sign to add a new rule. It should look like this:

Click after "import" where it says "specified resource type". A window will open where you will provide the following information. Make sure to provide your own domain information.

Next, click next to where it says "from". A window will open where you will provide the AD security group you'd like to pull data from. For this example, I chose a group named "LEADERSHIP".

Next, click "specified schedule". A window will open where you can specify the full import and update schedules.

The defaults on the rest of the rule options should be fine. Now that the rule is configured, put a checkmark in the Enabled box to turn it on. To pull in the first batch of data, click "Run the selected rule now (Full Import)". All of that lovely data is headed to a table in the Altiris database called Inv_Security_Groups-- little does it know, that's right where we want it.

Part 2: Finding the Data a Cozy Home

In our example, we populated the Inv_Security_Groups table with only data from our desired OU. But, you may want to import data from more security groups in the future. So, let's round up the security groups data we are looking for this time into its own NS collection.

In the Resources section of your NS console, create a new collection. I created mine in Resource Management > Collections. Let's name it "LEADERSHIP AD Security Group". Let's enter the SQL query directly for this collection.

SELECT dbo.vUser.Guid 
    dbo.Inv_Security_Groups ON dbo.vUser.Guid =

To populate the collection, we need to fill it with User guids. We join vUser and Inv_Security_Groups and specify the Group Name we are looking for is the fully-qualified name of our AD security group. Make sure to put in your own domain information. It's best to get the right string by looking at your own Inv_Security_Groups table.

After completing the collection query, you will have a cozy collection of users that belong to your desired AD group.

Part 3: Notification Policy to Update the Contacts

We need a place to run a query at on a schedule that will look at our NS collection and the contacts table in the Altiris_Incidents database.

Let's create a new Notification Policy from View > Tasks > Incident Resolution > Incidents > Helpdesk > Notification Policies. Name the policy "Set Contact VIP" and set it up like this:

Use this update query that the notification policy will run. Make sure to use your own collection guid. A fast way to find it is the right click on your "LEADSERHIP AD Secruity Group" collection and go to Properties.

SET  vip_flag = 1  
    INNER JOIN dbo.hd_contact_view h  
    ON c.[id] = h.[contact_id]  
WHERE h.[contact_resource_guid] IN (SELECT ResourceGuid  
    FROM altiris.dbo.CollectionMembership 
    WHERE CollectionGuid = 'd461cabd-21fc-497d-a423-8e55e98f2e3c'

(Thanks to Mike Ainsworth for providing this query off of a forum question I posted. Both he and Bill Sullivan talked it out with me on the thread.)

I set the schedule to run once a day to make sure I get any new people identified relatively soon.

The policy wouldn't let me save it without an Automated Action, so I added an email action to make it happy. Since no results are returned, it never executes the automated actions anyway.

Part 4: Incident Rule to Modify the Priority

At last, we have the security group data, we've grouped it, and we have a way to update the contacts we want to be VIPs. All that's left is the Helpdesk rule that will modify our ticket based on the contact being a VIP.

Let's create a new Incident Rule called "Set ASAP Priority if VIP contact" with the following settings:

Make sure to position the rule in your list of Incident Rules so that it fires in the right order. I placed mine after the other rules I have that set the Priority field based on what the Urgency and Impact are.

For us, setting the ticket Priority to ASAP was one way to go. Another way would be to have the rule modify the Priority lookup id in a way that bumps the priority up one notch instead of all the way up to ASAP.


After a few tickets came through our Helpdesk that the executives were not so happy about waiting that long for, it became apparent we needed to start utilizing the VIP field. This process should work for us to keep our VIP contacts up-to-date and accurate. I hope it helps you too.

Best Regards,

Comments 6 CommentsJump to latest comment

Mike Ainsworth's picture

Good out-of-the-box thinking!

For the Notification Policy, a slightly different approach that would avoid the dummy e-mail action would be to have the query test to see if there are any members of the collection that are not vip status with something like this:
"Select TOP 1 'Alert' from HD_Contact_View Where Contact_VIP_flag = 0 and contact_resource_guid in (select resourceguid from collectionmembership where collectionguid = 'insert guid here')"

And then run the update through an OSQL command like this:
OSQL -E -d ALTIRIS -q "Update set vip_flag = 1 from c inner join hd_contact_view h on c.[id] = h.[contact_id] where h.[contact_resource_guid] in (select ResourceGuid from CollectionMembership where CollectionGuid ='insert guid here')"

This way an Update doesn't actually occur unless there is a member of "leadership" that is not "VIP".

In the end, either methods provide the same results and the number of sql transactions are about the same.

Nice Job!

Login to vote
gbromage's picture

It's a nice tip, but you need to tweak your query a little:

SET vip_flag = 1
INNER JOIN dbo.hd_contact_view h
ON c.[id] = h.[contact_id]
WHERE (h.[contact_resource_guid] IN (SELECT ResourceGuid
FROM altiris.dbo.CollectionMembership
WHERE CollectionGuid = 'd461cabd-21fc-497d-a423-8e55e98f2e3c') AND NOT (parked_in_my_car_space OR stole_the_last_tim_tam OR NOT (gave_me_payrise_last_year))

Login to vote
Tenacious Geo's picture

LOL! Yes, I like your query tweak.


Login to vote
DeborahKahmke's picture

We use this for all of our Executives! It helps the new Help Desk Technicians and others who may not know who certain people are when they call...they don't need an organizational chart to know who the BIG DOGS are.

We have this auto-update based upon their title in Active Directory.


Deborah Kahmke

Login to vote
Tenacious Geo's picture

Yea I started out with title... but unfortunately our AD data was not that consistent. Security Group for the win!


Login to vote
tmcquaig's picture

We use this and it has worked out well for us. We also include our exec's admin assistants since they usually are the ones creating incidents for the exec.

Login to vote