Chapter 7: Support

  • Article

Overview

Services are perceived by the user through the lens of the desktop. At the same time, desktop operating systems and their related applications generate the largest number of support calls. Therefore, providing both a quality desktop experience and a high level of customer support is critical to maintaining IT's alignment to the business.

The IT manager and the Service Desk Manager should work together to ensure that the support desk is capable of meeting service level agreements (SLAs) and that customer expectations are satisfied. To accomplish this, the following actions need to occur:

  • Ensure support SLAs are in place.
  • Ensure proper escalation procedures and triggers are in place.
  • Identify training and awareness requirements for staff and users as a means to reduce call volume.
  • Conduct frequent reviews of support processes and call volumes to identify trends.

Scenario...

Now that the Windows Vista desktops have been successfully deployed, Gurinder Singh, the Service Desk manager at Woodgrove Bank, is aware that her team will need to focus on providing proactive and comprehensive support for the business.

Providing Effective Windows Vista Support

Scenario...

April Reagan is the first line support for end users at Woodgrove National Bank. Due to the excessive call volume, many service requests are forwarded to the desktop support manager in New York corporate headquarters. Insufficient call details result in having to contact customers repeatedly to collect more information. Moreover, VIP on-site support is an issue since there is a staff shortage. The service desk manager, Gurinder Singh, has received many customer complaints regarding the level of support and delays in fulfilling VIPs' requests. Gurinder has assigned April the task of improving the process of handling incidents and providing effective support by initiating a service improvement project to be completed by the next SLA Review.

To operate Windows Vista-based desktops as a service, processes should be in place to handle daily service requests and incident calls. This is taken care of by the Microsoft Operations Framework (MOF) Incident Management and Problem Management processes. Normal service operation is defined as a service operation within service level agreement (SLA) limits.

The objectives of Incident Management are to:

  • Restore service as quickly as possible, even if it requires a Windows Vista restart or desktop replacement.
  • Minimize the adverse impact of incidents on business operations.
  • Maintain the best possible levels of service quality and availability.
  • Ensure that all incidents and service requests are processed consistently.
  • Direct support resources where they are most needed.

Repeatedly occurring incidents should be analyzed and addressed using the MOF Problem Management service management function. The goal of problem management is to minimize the adverse impact on business operations due to incidents and problems caused by errors within infrastructure and to prevent the recurrence of these incidents. In order to achieve this goal, problem management seeks to establish the root cause of incidents and then initiate actions to improve or correct the situation.

The objectives of Problem Management are to:

  • Identify and take ownership of problems affecting the service.
  • Proactively take steps to reduce the impact of incidents and problems.
  • Identify the root cause of problems.
  • Initiate activity aimed at establishing workarounds or permanent solutions.
  • Perform trend analysis, using recorded problem and incident data:
    • To predict future problems.
    • To prioritize problem management activity.

Table 7.1. Summary of Incident and Problem Management Processes

Incident Management

Problem Management
  • Restore normal Windows Vista desktop service as quickly as possible.
  • Minimize the adverse impact of incidents on the business.
  • Proactively identify enhancements to services.
  • Check accuracy of configuration details.
  • Minimize the risk of lost incidents by capitalizing on Windows Vista features.
  • Monitor for SLA compliance.
  • Resolve problems quickly and effectively.
  • Prioritize problem solving according to business needs (business impact).
  • Reduce occurrence of incidents by correctly identifying problems and known errors.
  • Improve productivity of support staff.
  • Produce management information.
  • Minimize business impact of incidents and problems.
  • Enrich organizational knowledge base, which as a result helps to reduce the overall support cost and makes resolution faster for similar incidents.

Relationships Between Incident and Problem Management Processes

The following figure shows the relationships between Incident Management and Problem Management processes and how they interact with each other.

Figure 7.1. Relationship between Incident Management and Problem Management processes

The table below summarizes the inputs required to perform major tasks in Incident Management and Problem Management processes and their related outputs.

Table 7.2. Inputs and Outputs in Incident Management and Problem Management Processes

Inputs

Process

Outputs

  • Incident details reported by Service Desk
  • Configuration details from SMS Server 2003
  • Response from incident matching against problems and known errors
  • Resolution details
  • A central repository of desktops using Event Forwarding and Subscription features of Windows Vista
  • Completed changes on Windows Vista desktop service as a result of a Request for Change (RFC)
  • Service Level Agreement Details (SLA)
  • Incident Management

  • Updated Incident Record with the solution or workaround

  • Resolved and closed incidents

  • Communication to customers

  • Management information/reports

  • Possible Request for Change (RFC) to be processed by Problem Management

  • Incident details

  • Configuration details

  • Any defined workarounds (Incident Management)

  • Proactive known errors (KEs) from the Release Responsibility cluster

  • Problem Management

  • Known errors (knowledge base)
  • Request for Change
  • Updated Problem Record
  • Closed problem record for a resolved problem
  • Response from incident matching to problems and known errors
  • Management information
  • Needs identification (training, documentation, and so on)

Incident Management in Windows Vista

Typical incidents could include:

  • A desktop service being unavailable.
  • Software corruption.
  • A hardware failure.
  • The detection of a virus.
  • An update (patch) causing failures in the service operation.

Incident Management Resolution Process

Figure 7.2 illustrates the steps in the incident management resolution process.

Figure 7.2. Windows Vista Desktop incident management process

Detection, Self-Service, and Recording

This process deals with the initial detection of incidents through a variety of different methods. Windows Vista includes built-in diagnostics that can automatically detect and diagnose common support problems and then help users resolve the problems themselves. Some problems that Windows Vista diagnostics address are:

  • Failing disks
  • Degraded performance
  • Lack of network connectivity
  • Failure to shut down properly

Figure 7.3 is an example of a Windows Vista proactive alert to prevent information loss due to low memory status. For more information about Windows Vista built-in diagnostics, please refer to https://www.microsoft.com/windows/products/windowsvista/features/details/builtindiagnostics.mspx.

Figure 7.3. Resource exhaustion prevention

This alert will be logged in the Windows Vista Events repository, and the Events forwarding feature can be configured to forward them to a central server/repository. The problem manager in turn can proactively analyze the recurrence of such events and their related applications and produce an action plan for resolving them permanently.

Classification and Initial Support

The classification process categorizes the incident and uses information on impact and urgency to determine the priority of the incident.

Investigation and Diagnosis

This process deals with the investigation of the incident and the gathering of diagnostic data. The goals of the process are to identify how the incident can be resolved as quickly as possible, based on SLA targets. This is achieved by checking incidents against known errors, existing problems, and previous incidents in order to identify documented workarounds.

IT departments can add custom content to User Assistance—the Windows Vista version of help files—to provide answers to questions about custom applications and internal network resources. With good user assistance content, most reported incidents (or service requests) can be either resolved by users themselves or by first-tier of support, thereby eliminating escalation.

Examples include:

  • Tips and tricks on various Windows, Office, and LOB applications.
  • How to create an Outlook calendar meeting request.
  • How to add the closest printer to your location.
  • How to download hardware drivers for your desktop from internal resources.

User Assistance can also be customized to link users directly to an internal support center. For more information on how to customize help content to meet your needs, visit http://technet2.microsoft.com/Windows Vista/f/?en/library/bcffdbb6-82df-4a0f-b215-759a1ecfbdd61033.mspx.

Windows Vista Error Reporting is a feature that allows Microsoft to track and address errors relating to the operating system, Windows features, and applications. This feature gives users the opportunity to send data about errors to Microsoft and to receive information about solutions. Solution information can include the following:

  • A link to the Windows Update Web site.
  • A link to updated drivers and patches.
  • A link to Microsoft Knowledge Base articles.

Resolution and Recovery

This process deals with finding and applying the required fix to resolve the incident. Following successful resolution of an incident, such as replacement of a faulty hard disk, there may be recovery actions that need to be taken, such as the restoration of user data.

Closure

This process ensures that the customer is satisfied that the incident has been resolved prior to closing the incident record. This is also where the incident record is fully updated and assigned a closure category. Finally, to ensure customer satisfaction with the support experience, a follow-up survey should be sent to users to evaluate the overall experience.

Scenario...

Now that April understands how to apply Incident Management processes to the service improvement project, she works within her team to identify the responsibilities for each team member to align with MOF Incident Management best practices.

Principal roles and their associated responsibilities for Windows Vista incident management have been defined according to industry best practices. It is important to remember that these are roles rather than job descriptions.

The roles required within the incident management process are:

Incident manager. Responsible for the end-to-end ownership of the Windows Vista desktop incident management process. Usually, the Service Desk manager takes on this role.

Service desk analyst. Responsible for many tasks including (but not limited to) incident recording, initial support and classification, escalating, resolution and recovery of incidents, and closure. The call screeners normally take on this role.

Support technicians. Responsible for providing assistance to end users.

Problem Management in Windows Vista

A difficult area of Problem Management for most organizations is the root cause analysis of problems. Often, visual techniques are employed in assisting support personnel with their investigation.

Performing Root Cause Analysis for Windows Vista

To perform root cause analysis

  1. Define the problem (Effect).

  2. Gather data/evidence (Categorize).

  3. Identify issues that contributed to the problem (Primary/secondary causes).

  4. Find root cause (Process of elimination).

  5. Develop solution recommendation (Change Request).

  6. Implement solution (Change Implemented).

Fishbone Diagram

One tool that is useful in visually diagramming this process is the Ishikawa, or fishbone diagram, shown below.

Figure 7.4. Fishbone diagram

Example Problem: Display Flickering

Scenario...

A high call volume support issue has been identified. A number of Linda's users with CRT monitors have been complaining that their monitors have been flickering intermittently after upgrading to Windows Vista, and most often when waking up from Sleep or Hibernate modes. Linda suspects that it may be a video card issue, but since it is intermittent, she decides to dig deeper to ensure proper resolution.

After gathering additional data, Linda compiles a list of likely issues, listed below in no particular order:

  • Electrical interference from other devices
  • Monitor driver
  • Video card driver
  • Faulty cabling
  • Out-of-date video card driver
  • Dirtypower
  • Motherboard incompatibility
  • Faulty video card
  • Faulty monitor
  • Unsupported monitor resolution
  • Refresh rate mismatch

After evaluating the list, Linda concludes that these possible problems seem to fall into three separate categories.

Table 7.3. Problem Categories

Video Card

Monitor

Other

Resolution unsupported

"Dirty" power

Electrical interference

Refresh rate mismatch

Faulty cabling

Motherboard incompatibility

Driver faulty/out of date

Monitor drive faulty/out of date

Video card faulty

Monitor faulty

Finding Root Cause

Scenario...

Now that Linda has a pretty good idea of what may be contributing to the monitor flickering issue, she decides to start with the most plausible root cause, the Video Card category. She moves along the fishbone to research the following primary causes:

  • Refresh rate mismatch
  • Unsupported resolution
  • Driver
  • Faulty video card

Since the problem is intermittent, she decides to set up a Data Collector with the new Windows Vista Reliability Monitor and Performance Monitor tools.

To create a Data Collector Set from Performance Monitor

  1. Start Performance Monitor, and add counters to create a custom view you want to save as a Data Collector Set.

  2. Right-click anywhere in the Performance Monitor display pane, point to New, and click Data Collector Set. The Create New Data Collector Set Wizard starts. The Data Collector Set created will contain all of the data collectors selected in the current Performance Monitor view.

  3. Type a name for your Data Collector Set, and then click Next.

  4. The Root Directory will contain data collected by the Data Collector Set. Change this setting if you want to store your Data Collector Set data in a different location than the default. Browse to and select the directory, or type the directory name.

    Note If you enter the directory name manually, you must not enter a backslash at the end of the directory name.

  5. Click Next to define a user for the Data Collector Set to run as, or click Finish to save the current settings and exit

    Note If you are a member of the Performance Log Users group, you must configure Data Collector Sets that you create to run under your own credentials.

  6. Click Finish to return to Windows Vista Performance Monitor.

To view the properties of the Data Collector Set or make additional changes

Select Open properties for this data collector set. You can get more information about the properties of Data Collector Sets by clicking the Help button in the Properties page.

To start the Data Collector Set immediately (and begin saving data to the location specified in Step 4)

Click Start this data collector set now.

To save the Data Collector Set without starting collection

Click Save and close.

Scenario...

After taking a look at the Data Collector set she set up, Linda determines that both the refresh rate and resolution settings are in line with what the hardware supports. One thing she did notice while looking at the Reliability Monitor is that there were a number of failures in the Application Failures section.

Figure 7.5. Reliability Monitor report

Scenario...

Linda also notes from the graph that the errors are becoming more frequent and happen on days in which she received the most complaints from her users. The application failures showed that indeed there are recurring issues with the video card software not recognizing the card properly.

Since all the cards in question are an IT standard, she tests the latest driver and doesn't notice any problems on her test computer. She notes this and submits a change request to update the drivers on the affected computers.

In working through this problem, Linda has identified many steps of Incident Management and Problem Management in her new service improvement project and is now ready to incorporate these improvements at the next SLA Review.

Once marked as a known error pending resolution, a Request for Change (RFC), as driven by the Service Desk, is communicated to the affected users and they are told when to expect the problem to be resolved. When the RFC is approved and pushed to the desktops, the Service Desk follows up to make sure that the incidents have been resolved, and the tickets are closed.

Fault Tree Analysis

Fault Tree Analysis is another visual technique used to assist with root cause analysis. It is a top-down approach to identify all potential causes leading to a defect. In the final stage of diagnosis, the root cause is identified and the problem moved from unknown state to known. See the example shown in Figure 7.6.

Figure 7.6. FTA analysis for a problem

Proactive Analysis and Event Resolution

Proactive analysis activities are concerned with identifying and resolving problems and known errors before incidents occur, thus minimizing the adverse impact on the service and business as a whole. This can be accomplished by reviewing the following:

  • The current incident database.
  • All forwarded events stored in a central repository.
  • Corporate Error Report data.
  • Knowledge Base with unknown errorstate.

The basis for selecting which problems to attempt to proactively resolve is based on several factors including:

  • Cost to the business.
  • Customers affected.
  • Volume, duration, and cost of the incidents.
  • Cost of implementation.
  • Likelihood of success.

Figure 7.7. Targeting Preventative Action

Using these factors, an algorithm can be created and used to calculate the business impact of support events. This can be a useful, cost-effective way to determine which problems to address.

Exhibit 7.1. Sample Incident Business Impact

Access this content as part of theWVSLM download package.

Periodic Tasks

The most common tasks to be executed on a periodical basis in order to support the Windows Vista desktop service effectively and efficiently are listed in the table below.

Table 7.4. Common Periodic Tasks

Task

Frequency

Owner

Incident detection and recording in IT Service Management service desk tool

As needed (when an incident is open)

Service Desk Analyst

Classification and initial support

Use the Windows Vista Knowledge Base or User Assistance features to search for similar symptoms and offer possible solutions

Windows Vista Remote Desktop and User Assistance

As needed

Service Desk Analyst

Resolution and Recovery

Windows Vista help and support features

Use Virtual PC 2007 as a free download for enterprise customers to reproduce the issue

Windows Vista Hardware Development Center

Troubleshooting and Support

Patch Management Diagnostics and Recovery toolset available in the Desktop Optimization kit

As needed

Support Technician

Major incident manager (in high severity incidents)

Incident closure

As needed (after getting customer/user approval)

Service Desk Analyst

Incident ownership, monitoring, tracking, and communication

Daily

Bi-daily (for low severity incident)

Service Desk Analyst

OR

Desktop Support Technician

(depending on the Service Desk Model implemented)

Review to drive the efficiency and effectiveness of Incident Management process

Monthly

Incident Manager/Service Desk Manager (Doris Krieger)

Producing Service Management information

Quarterly for SLA Reviews

Incident Manager/Service Desk Manager

Managing escalations

As needed

Service lead

Problem recording

As needed

Monthly

Problem Manager

Problem control and root cause determination

Fault Tree Analysis (FTA) explained above

As needed

Problem Analyst (A second assistant is Support Specialist

Error control

As needed/scheduled

Quick Fix Engineering team (subset of Development team)

Proactive prevention of problems

Windows Vista Scripts to collect selective data

Windows Vista Corporate Error Reporting

Problem Reports and Solutions

Auto Event forwarding and subscription

Business Impact Calculation

Monthly: Proactive analysis for the Windows Vista Desktops Events forwarded or Corporate Windows Vista Error Reports

Calculates the pain value to narrow down the focus to top five problems

Problem Manager

Major Problem Reviews

As needed

Problem Manager

Essential Tasks of the Support Role

The following table illustrates some of the essential tasks required by this capability to drive higher customer satisfaction and ensure consensus between the IT service desk team and business. It also describes the objective, frequency, and responsible party for each task.

Table 7.5. Support Role Essential Tasks

Task

Description/Why

Frequency

Responsibility Role

Produce business-related metrics reports

These reports will be a great input during service review meetings and internal operational reviews. Most IT Service Management tools offer some reporting features that include the above mentioned ones.

Weekly

Service Desk lead

Internal support review meetings

Ensure clearing any outstanding issues from previous week.

Weekly

Service Desk Manager

Service Review Meeting with IT MGMT

Communicate any feedback or complaints from business side and explore ways to fix them.

Monthly

IT Manager

Service Desk Manager

Attend SLA Review

Review support SLA targets, discuss areas to be accountable for successful achievement and responsibility for any future service improvement opportunities

Quarterly (or at whatever was agreed on during SLA negotiations)

IT Manager

Service Desk Manager

Partner underpinning contracts (UC) review

Periodic review should be conducted with partners to ensure they are on track and meeting all targets.

Monthly

Partner Account Manager and Service Desk Manager

Critical Success Factors and Key Performance Indicators

Sample Scorecard

Use a scorecard such as the sample below to measure performance against KPIs and to track trends.

Table 7.6. Scorecard Sample

Exhibit 7.2. Sample Scorecard

Access this content as part of the WVSLM download package.

Exhibits

Exhibit 7.3. Sample Incident Survey

Sample customer survey to be used after closing out an incident.

Access this content as part of the WVSLM download package.

Exhibit 7.4. Sample Major Problem Review

It is a learning opportunity (instead of a blaming session) to discuss what went wrong, what went right, and what corrective and preventative actions shall be taken and by who and when.

Access this content as part of the WVSLM download package.

Technical Guidance