Symantec Connect
  • Login
  • Register
  • Endpoint Management & Virtualization
    • All of Connect
    • Backup and Archiving
    • Endpoint Management & Virtualization
    • Storage and Clustering
    • Security
    • Inside Symantec
    • Vision User Conference
    • Partners
    • Developers
    •  
  • Overview
  • Forums
  • Articles
  • Blogs
  • Downloads
  • Events
  • Videos
  • Groups
  • Ideas
Login to participate
Endpoint Management & Virtualization Community BlogRSS

Closing Resolved Status Incidents after a Defined Period of Inactivity

EFMagnuson's picture
EFMagnuson
August 2nd, 2007
Filed under: Altiris Notification Server, Helpdesk Solution, Configuring, Endpoint Management & Virtualization Community Blog, Endpoint Management and Virtualization

To close, or not to close, that is the question many of us face while staring at an aging list of help desk tickets. Here's the process one Juice reader recently implemented to save his staff a couple hours a week and (you're way ahead of me) get some closure. :)

The Eminent Problem

When an Incident is resolved our Helpdesk workers place the Incident into "Resolved" status (in our previous system this was "Resolved: Pending Follow-up"). All of our reporting metrics and notifications have been altered to count "Resolved" status Incidents in much the same way as "Closed" status. However, due to the intrinsic differences between the two statuses we still have need for the "Closed" status and to pull separate metrics on Closed verses Resolved Incidents. When an Incident is placed in Resolved status the requestor (contact_name/contact_email) receives an e-mail letting them know that the Incident has been resolved and to let the Incident Worker (assigned_to_worker_name/assigned_to_worker_email) know if there are any further challenges related to the Incident. Keeping it in "Resolved" status for a time allows the Requestor to re-open the Incident for continued work if required. If no follow-up or further work is required after five days, the worker(s) can then go and fully close the Incident. Unfortunately, because of low staffing levels our workers cannot always perform the proper follow-up or go back through their Resolved Incidents for closure on a daily basis.

The New and Improved Process

We decided to automate the transition from Incident Resolution to Incident Closure. We wanted the system to automatically scan for Incidents in "Resolved" status for more than 10 days without change (this gives both Worker and Contact a grace period to confirm Incident Resolution and perform in person follow-up, if possible) and change the status of the selected Incidents from "Resolved" to "Closed." We achieved this through an automated notification task in the Notification Server.

The Payoff

By automating Incident Closure and follow-up after a period of inactivity our Helpdesk workers have been able to focus on current and upcoming tasks rather than having to worry about past and Resolved tasks. It is a recent change in our system but we are estimating that it will save each worker about 4-6 hours per week in follow-up time.

0 votes
  • EFMagnuson's blog
  • Login or register to post comments
  • Comments RSS Feed
lokisson's picture
lokisson
2 years 32 weeks ago

ITIL opinion

ITIL says that you may close resolved incident after 21 days of inactivity from user. In some cases you better call-back to user that issued incident and make sure you resolved an incident.

0 votes
  • Login or register to post comments
riva11's picture
riva11
2 years 32 weeks ago

During the past IT Audits

During the past IT Audits (according to Sox/Cobit process) , internal and external auditors requested that all HD tickets remains open witing a user feedback. After 30 days before for any closure we have to contact user for the feedback input on HD systems, only in this case we can force the closere.

0 votes
  • Login or register to post comments
xmoreland's picture
xmoreland
2 years 28 weeks ago

Good Practice

I think it is great to automate this. I think it is just simply the way it should be. Being able to set the number of days is a bonus and should just be the way it is!

0 votes
  • Login or register to post comments
karanmalhotra's picture
karanmalhotra
2 years 16 weeks ago

Need Help with the Steps

Hello

Could you help me with the steps i would require to set this up?

0 votes
  • Login or register to post comments
djalbert's picture
djalbert
2 years 7 weeks ago

Need Help with the Steps

What are the steps?

0 votes
  • Login or register to post comments
cjerogel's picture
cjerogel
2 years 3 weeks ago

Need Help with the Steps

Can you post the steps?

0 votes
  • Login or register to post comments
EFMagnuson's picture
EFMagnuson
1 year 44 weeks ago

Sorry for the delay

I haven't been on the Juice Forums for a while.
Here are the steps I took to enable this automation:

  1. In the Altiris Web console go to "View" > "Tasks";
  2. Expand the directory tree to the location where you would like to create the Task (in our case we placed it in "Tasks\Incident Resolution\Incidents\Helpdesk\Notification Policies");
  3. Right-Click the Folder and select "New" > "Notification Policy";
  4. In the "Name" field, type the name of your new Notification Policy (e.g. "Close Resolved after 10 days");
  5. If desired, type a brief description of the rule in the "Description" field;
  6. First, we need to create the Query that will select the proper Incidents:
    1. In the "Source" dropdown, select "Query";
    2. Click "--Edit Query--";
    3. Click "Edit SQL Directly";
    4. Copy and Paste the following SQL args into the input box:
    5. SELECT DISTINCT hd1.[workitem_number]
      FROM dbo.HD_workitem_current_view hd1
      WHERE hd1.[workitem_status_lookup_id] IN (400)
      AND datediff(d, hd1.[workitem_modified_on], getdate()) >= 10

      NOTE: By changing the "10" at the end of the argument, you will change the the required period of inactivity for the rule to work.

  7. Click "Run" to confirm the query works;
  • Since we required this to be fully automated, we want to create a schedule for it:
    1. In the "Enable Schedule" dropdown, select "Custom Schedule";
    2. Click on the link to the custom schedule;
    3. In our case we want to run the task every day at 9:00 AM so our system will stay on top of Incident Closure, but you can select any schedule that suits your needs;
    4. Click "OK";
  • Now to add the Automated Action that will actually change the Incident Status:
    1. From the "Add action type" dropdown, select "Edit Incident Automated Action";
    2. Click "Add";
    3. Enter the action Name and Description as desired;
    4. Click the "Enabled" check box;
    5. In the "Execute" section, click the "Once per row" radio button;
    6. In the "Incident" input box, type:

      %DSworkitem_number%

    7. In the "Comment" field, type a comment that will let any reviewer know that the Incident was closed by automation (e.g. "This Resolved Incident has been automatically Closed due to 10 days of inactivity after Resolution.");
    8. From the "Status" dropdown, select "Closed";
    9. Click "OK";
  • Enable the Task by clicking the "Enable" checkbox at the top of the page;
  • Click "Apply".
  • 0 votes
    • Login or register to post comments
    karanmalhotra's picture
    karanmalhotra
    1 year 43 weeks ago

    Thank you

    Appreciate The Steps Provided...

    0 votes
    • Login or register to post comments

    Would you like to reply?

    Login or Register to post your comment.

    About Endpoint Management and Virtualization Community Blog

    The Endpoint Management & Virtualization Community Blog is the perfect place to share short, timely insights including product tips, news and other information relevant to the Endpoint Management & Virtualization community. Any authenticated Connect member can contribute to this blog.
    Filter by:

    Recent Blog Posts

    • USB Swiss Army Knife: 7 Quick Fix
      riva11 - March 12, 2010
    • Cebit is over. What will be our next big show?
      erikw - March 12, 2010
    • Will Intel AMT and Intel vPro Technology appear on servers?
      Terry Cutler - March 10, 2010
    • How to force the Altiris client to point to a new Deployment Server
      mark76 - March 10, 2010
    • Veeam and VirtualStorm. SWV Apps in Action
      erikw - March 10, 2010

    Blog Tags

    7.1 Agents Altiris Client Management Suite Altiris Deployment Solution Altiris IT Asset Management Altiris Notification Server Altiris Recovery Solution Altiris Server Management Suite Asset Management Suite Backup Exec Backup Exec System Recovery Basics Best Practice Beta CIO Digest Case Study Compatibility Configuring Customer Preview Customer Reference Database Dell Dell Management Products Demonstration Documentation Downloads Drivers Emerging Threats Endpoint Management and Virtualization Endpoint Protection (AntiVirus) Enterprise Vault Error messages Evaluating Features General Symantec Ghost Solution Suite HP Management Products Helpdesk Solution How to ITMS Industry Event Inside Symantec Installing Licensing Linux Local DS GURU Email group Mac OS ManageFusion Mobile & Wireless NetBackup New Release News News Performance Platforms & Hardware Problem Management Recovering Reporting Restore SP2 SecurityExpressions Service Pack 2 ServiceDesk Storage Foundation Symantec Connect Symantec Event TMS TechTips Tip/How to Tips/How To Training Troubleshooting Upgrade User Group VDI VMware Virtualization Virtualization Vision Vulnerabilities & Exploits Windows Windows Wise Application Packaging Wise Installation Development Wise Virtual Composer Workflow Solution Workspace Corporate Workspace Profiles Workspace Remote Workspace Streaming Workspace Virtualization XPF baltimore deployment hugo known_issue pcAnywhere solution webcast
    © 2010
    • Symantec Corporation
    • Contact Us
    • Get RSS
    • Privacy Policy
    • Symantec.com