This tip was submitted to SearchWinSystems.com by contributor David Williams. Please let other users know how useful it is by rating it below.
As I discussed in part one, Microsoft has recently released the Microsoft Operations Manager 2005 Solution Accelerators (SAs) in an effort to further anchor MOM's position as a key application for the Service Monitoring and Control service management function (SMF). There are five SAs, each one showing how extensible MOM can be. They are Alert Tuning, Autoticketing, Service Continuity, Multiple Management Group Rollup and Notification Workflow.
In common with the other four tools, the Autoticketing SA is packaged as a single ".msi" that consists of a solution guide, but no additional software or documents. The solution can be downloaded at http://www.microsoft.com/technet/itsolutions/techguide/msm/smc/as05.mspx. With this particular SA, Microsoft aims to help organizations develop a solution to automate ticket generation in a fully automated fashion, interfacing the MOM Connector Framework (MCF) Web service with the existing incident management application used for service requests (SR) or trouble tickets (TT). The benefits of such a solution are:
- A reduction or prevention of service incidents through the use of proactive remedial action.
- Faster and more effective responses to service incidents.
- Improved overall availability of services.
- An increase in user satisfaction.
According to the solution guide, the goal is to increase operational efficiency, reduce the costs of IT operations, increase the effectiveness of service monitoring and control and use key information from other IT operations applications.
Microsoft further defines a successful implementation as one that achieves the following objectives:
- Reduced labor cost. Autoticketing reduces the labor overhead from operators who use the MOM Operator console to determine if a condition warrants specific action and from service-desk staff that process an incident into the TT system.
- Reduced error. When operators create a TT, the process is inherently error-prone because data is manually transposed from one system to another. Errors include misspellings, duplication, omissions, insufficient information and inaccuracies that can have dangerous ramifications when a privileged administrator acts upon them.
- Decreased time to repair. Autoticketing eliminates the need for manual entry of the ticket. This allows an immediate update to an administrator's or engineer's activity list to resolve the failure condition.
- Increased availability. Similar to repair, if a cascading failure is detected and a ticket is created sooner, staff may be able to prevent a total failure. In addition, when the labor overhead associated with the manual process is eliminated, staff is free to focus on more unique conditions, as well as proactive investigation.
- Maximized investment. Integrating the monitoring system, TT system and other IT applications has a mutually beneficial effect on functionality, data and workflow. This results in an improved overall delivery of IT services.
It should be noted that this SA could turn out to be one of the most complex and difficult to implement. Although in theory this should be something simple -- to receive the alert, break it down to fairly granular level and open a new ticket with the details contained in the alert -- there are three key challenges to a successful implementation. Microsoft has labeled these challenges in order of complexity -- data sufficiency, data-transfer enablement and data-transfer management.
Satisfying data sufficiency is the principal hurdle to overcome, but not impossible. The key is to make sure that all the information the ticketing application requires is given during the data exchange. Since TT/SR applications and MOM server have different roles in IT support, it is important that the quality and quantity of data be sufficient. If not, increased man-hours, added manual steps (and potential errors) and longer waiting periods may result, negating the value that Autoticketing provides.
Data-transfer enablement, on the other hand, should be fairly simple, as long as there are some development resources available. Thanks to Microsoft's MCF, which is a Web service-based framework for connecting to MOM, most TT/SR can talk natively with MOM 2005 via XML, COM, EAI/HTTP or its own Web service interface. Note that the MCF is meant to "pull" data from MOM, not to "push" data. So all data transfers must be initiated from the TT/SR system. Error management and asynchronous, non-blocking timing and sequencing are wrapped up in data-transfer management.
To overcome the three challenges, the Autoticketing SA has three layers -- the application layer, consisting of MOM, the TT application and any other third-party applications; event integration layer, where data exchange occurs; and the business logic layer, where rules and core intelligence reside. Designing a solution around these layers, the process workflow is derived. At a high-level, the workflow should consist of:
- Retrieve alerts from MOM. Using MCF, collect alerts with resolution state set to "AutoTicket."
- Apply filtering. Use this business logic to check if the alert meets specific criteria and matches other system conditions. This helps determine if the Autoticket workflow should continue to the next step.
- Update state to "Pending." Use MCF for setting the state to "Pending" instead of its default "New."
- Apply business logic. Use the predetermined business logic to resolve data issues, so that the ticket information is complete.
- Create ticket. Use the connection on the TT system to create a new ticket.
- Update attributes in MOM. On successful creation of the ticket, update the attributes in MOM.
- Call AckData method for all alerts retrieved. Acknowledge the alert after the workflow is completed.
The solution guide does a good job of reviewing the process of extracting alerts from MOM and gives several examples of scenarios interacting with Siebel as the TT/SR application. The guide also includes sample script for interfacing with the MCF methods that the Web service exposes. This aspect is so detailed and customized, that I won't go into it here, but I recommend that all interested parties review Chapter 4 in the guide for additional details.
Overall, the process can be summarized in the screenshot below. Image URL: http://myitforum.techtarget.com/img/arts/9952MOM2005AutoticketOverall.jpg.
With the Autoticketing SA, Microsoft has shown it has improved system integration, which has been built into MOM 2005 -- yet another reason for shops that are still running MOM 2000 to upgrade. But we're just getting started. The remaining three SAs continue to take MOM to new levels as an enterprise-class service monitoring tool.
Verifying the Agent Computer Can Contact the MOM Server
MOM FAQ: MOM 2005 Doesn't Display Operating System Type
MOM 2000/2005 Event Rule Types
Collecting and Alerting on Security Events with MOM
ABOUT THE AUTHOR: David Williams lives in Atlanta and is a Windows Services IT manager for the John H. Harland Company. He holds an MCSE, MCDBA and CCNA, and is currently working toward his CISSP. He can be contacted at email@example.com.
This article first appeared in myITforum, the premier online destination for IT professionals responsible for managing their corporations' Microsoft Windows systems. The centerpiece of myITforum.com is a collection of member forums where IT professionals actively exchange technical tips, share their expertise, and download utilities that help them better manage their Windows environments, specifically Microsoft Systems Management Server (SMS). It is part of the TechTarget network of Web sites. To register for the site and sign up for the myITforum daily newsletter, click here.
This was first published in October 2004