Tips for Working with Product Support RRS feed

  • General discussion

  •   FIM Experts Corner Article

    One of the best, or most frustrating, experiences we can have when working with computer software is when we contact product support.
    Based on my experience in various support organizations for the past 15 years, I would like to share with you some tips that will help your support experience go more smoothly.
    Ultimately, the best support experiences I believe are built with good communication and teamwork between the Microsoft support engineer and you.

    Pause in our Daily Programming to bring you these Definitions

    It was recently brought to my attention that I may be jumping the gun with some of the topics I have below, and that this discussion may benefit from some basic definitions and explanations.
    So, let’s begin.
    The first question we need to answer, I suppose, concerns this elusive acronym “PSS.”


    As with many of the acronyms used in the technology sector, PSS can probably have several meanings.
    In this case, PSS stands for Product Support Services.
    PSS is the official route customers can take to receive help with Microsoft products.
    What does PSS Do?
    We help people with problems they encounter in Microsoft software.
    If we determine the problem is in the product itself, the request could result in a hotfix being developed.


    What if I find a Problem I think is a “Bug” in the product?
    First, what is a “bug”?
    This is a term that is used to describe a problem where the product does not perform as intended.
    How do I know if I have run into a bug in the product?
    There is no way to actually know for certain that a problem you are experiencing is an actual bug in the system without Microsoft investigating the issue.
    There are some clues that I would consider triggers for when to contact Support to discuss the issue:

    • One of the monitors in the forum indicates they think something may be a bug, and ask you to contact PSS so they can investigate the issue.
    • The product is “crashing”. In effect, it throws an unexpected error, or application error, and exits memory.
    • The product is throwing “Bail” errors in the Application Event Log.


    What should I do before contacting Support about a bug?

    I would check the knowledgebase articles by searching keywords on http://support.microsoft.com to see if the problem you are experiencing has already been reported and has a hotfix available.

    What information should I include when asking for help concerning what I believe to be a bug?

    All error messages:

    • All event log entries created by ILM around the time the problem happens.
    • Exception information from areas like the run history in the Operations tab of the FIM Synchronization Service Manager (formerly the Identity Manager).
    • Steps that can be used to reproduce the problem in your environment.
    • Any other pieces of information you think may be helpful in diagnosing the problem happening on your system.


    How should I report a possible bug to Microsoft?

    The best way is by creating a support case with PSS.

    Where do I go to create a “Support Case” with Microsoft?

    For Forefront Identity Manager 2010, we have listed your support options at the following link: Support Options for Forefront Identity Manager 2010 General Support Options Page

    Resuming our Daily Programming

    Now that we have provided some initial details, let’s go into some detail concerning product support at Microsoft.

    Beginning your Support Experience

    The first thing that you experience when contacting product support at Microsoft, is either a webform or person asking several things:

    1. What product are you using
    2. Please provide a description of the problem
    3. Help us to rate the severity of request through the answering of questions

    Based on this interaction, we try to route the support case to the appropriate support group team, applying the proper severity to the support incident.

    Common Problems Encountered in the Support Process

    Much as I would like to say that there are no problems encountered in the support process and every support experience is magical, this would not reflect reality.
    Reality tells us that there are support experiences where cases are misrouted, basic problem explanations need to be repeated, and support wait times are longer than expected .
    The tips presented below are designed to help navigate around the common problems experienced in the support process.

    The Tips (sirloin and others)

    Tip 1 – Provide Detailed Information

    When beginning the investigation of a problem, there are certain things we will look for from the start:

    1. Environment Description:
      • What version are you using?
      • What version of the database?
      • What operating system?
    2. Problem Description - In effect, what is happening that is unexpected, or what is not happening that we you do expect? When did the problem start? Has this ever worked as expected?
    3. Steps to Reproduce - What actions can be taken to reproduce the behavior?
    4. Other Symptoms -  Other things that you have observed in the system that may or may not be related to this issue but seem strange.
    5. Error messages, Event log entries - There is no substitute for information returned by error messages.
      If possible, please make sure to copy the whole error message or event log entry rather than just the numeric ID.
    6. Changes - Did anything change in the system that could have contributed to the problem? – You are working with the system on a daily basis and will be able to provide system health information. While changes to the system do not cause all problems, it is helpful to know of all changes that are made on the system around the time the problem was.
    7. Business Impact - What impact is this having in your business – All problems we encounter have an impact on our business. This can range from “I have to work on a different area of the product until this is figured out” to “our server is down.” Having a clear statement of this impact up front can help communicate the urgency to the support engineer.
    8. Problem Discussion - Be ready to discuss the underlying design and functionality where the problem is happening.


    Tip 2 – Configure to allow for Live Meeting (a.k.a. ‘EasyAssist’)

    Because each solution implemented in ILM is unique, it is often helpful for our support engineers to be able to look at your system directly.
    If your network is configured to allow Live Meeting sessions between machines internal to your network and machines outside your organization, this will allow us to use a custom Live Meeting wrapper called “EasyAssist” to view the problem on your machine .
    To further enhance the experience in EasyAssist and LiveMeeting, there is an option where you may allow the support engineer to “take control” of the session.
    This can be used at your discretion. If there is a special remote viewing application that is used internally by your company that would be more convenient to use, please let the support professional know.

    Tip 3 – Have a single technical contact for the support case

    Having multiple people in a support call is not necessarily a problem, but there are cases times where this can cause a problem. I wish to address two that are usually easily solved with clear communication.

    1. Trying to do technical troubleshooting on a conference call that includes a large number of people.
    2. Having a different person as the technical contact with each troubleshooting session.

    Large Group - There are two types of people that usually attend these meetings:

    • Those who will be doing the technical troubleshooting
      • This should be a person who is familiar with both ILM and the solution being examined.
      • If the available technician is not familiar with ILM, this can greatly reduce the effectiveness of the troubleshooting session and increase the amount of time required to resolve the issue
    • Those who have a stake in the problem resolution, but will not be doing the troubleshooting.

    Based on this observation, I generally like to separate the meetings into two types:

    • Technical Troubleshooting troubleshooting meetings
    • Status Update update meetings

    Technical Meetings - Technical meetings should be attended by a small number (usually one or two) people who are directly involved with troubleshooting the immediate problem. The people attending these meetings should be the same through the troubleshooting cycle.

    Status Meetings - I look at this meeting as an “Executive executive level meeting” to report status to stakeholders who need to understand and communicateknow problem status rather than technical details. This meeting is usually short and simply communicates the points below.

    • What have we done
    • Problems identified
    • Next steps in the troubleshooting process

    Many times the Status meetings are not scheduled in favor of an email providing these details.


    Providing the list of stake-holders who should be included on any status update email at the beginning of the process helps avoid "fire-drills" by stake-holders that are not actively involved in the day-to-day troubleshooting.


    Tip 4 - Your Participation

    You As the ILM expert contacting support, you are an essential member of the team troubleshooting the problem being experienced in ILM.
    Without your knowledge of your implementation and your contacts with others in your organization, such as SQL Administrators, the troubleshooting of the problem becomes much more difficult and time consuming .
    In the case where a consultant designed and implemented the ILM solution, scheduling conference calls with the support engineer and consultant to troubleshoot the problem is essential for a timely resolution.


    While we try to anticipate all of the things you may experience with the product and document them, periodically you may run into a problem where you need additional help.
    If you get into a situation where you need additional help, please do not hesitate to contact Microsoft Support.

    About the Author

    Steve Klem is a 15 year veteran of Microsoft Support and has supported several different products and technologies during that time.
    Steve is currently assigned to the Forefront Identity Manager 2010 product group as a support liaison to prepare the support team for the FIM 2010 release.

      Go to the FIM Experts Corner
    Tuesday, March 16, 2010 2:07 AM