Use a troubleshooting methodology
Most large organizations structure their technical support into different tiers. The following table provides an overview of a typical technical support structure, with focus on Teams. As a Teams specialist, you perform the Tier 3, engineer role. You’ll typically interact with the other tiers on a frequent basis.
| Tier | Role | Description |
|---|---|---|
| Tier 1, helpdesk | Support | Supports and troubleshoots day-to-day client operating systems, applications, and hardware. Follows prescriptive guidelines, and provides end-user phone support. |
| Tier 2, Teams administrator | Operational | Provides day-to-day Teams troubleshooting. Manages and supports the organization’s Teams environment. Responds to helpdesk requests when problems are escalated. |
| Tier 3, engineer | Tactical | Analyzes and designs within a single technology, in this instance, Teams. Responsible for complex troubleshooting, including escalations from administrators. |
| Tier 4, architect | Strategic | Analyzes and designs enterprises technology solutions. |
As part of your role, you’ll be expected to troubleshoot Teams issues. In order to fulfill this role, you should approach problems in a logical way by using a prescribed methodology.
Stages of a troubleshooting methodology
Although each organization creates their own methodology for troubleshooting, the stages used are broadly similar. These stages are described in the following table.
| Stage | Description |
|---|---|
| Classification | When the helpdesk or Teams administrator reports a problem, you must attempt to define its nature. During this stage, you’ll review gathered information and attempt to determine possible causes. You’ll also determine the scope and impact of the problem. |
| Testing | After you’ve successfully classified and scoped the impact of the problem, you can attempt to determine which of your possible causes is the probable cause. This stage involves testing along a dividable line: infrastructure or Teams, client or service. |
| Escalation | If you’re able to identify the problem, you can attempt resolution. Otherwise, you might escalate to another team member, or to Microsoft. |
| Reporting | Throughout the process, you’ll report your progress. If you successfully resolve the problem, you should document it carefully for future reference. |
Implement your troubleshooting methodology
When you begin to troubleshoot a problem, you should define the steps that you need to take to resolve the problem clearly and concisely. Your troubleshooting methodology should consist of:
- Problem reporting
- Information gathering
- Development and implementation of an action plan
- Documentation of the resolution
Report the problem
The reporting process begins when the helpdesk or Teams administrator reports a problem to you. When they report a problem, ask pertinent questions to determine the problem’s scope. You can then prioritize the problem by using the answers to these questions.
Important
Support staff should keep the end-user informed of progress throughout the entire troubleshooting process.
Gather information
You might be able immediately resolve the problem, especially if it’s fairly straightforward. But if not, you might need to gather more information to help identify possible causes. You can use monitoring tools, examine event logs, or ask more questions of the Teams administrator, helpdesk staff, or even end-user.
Develop an action plan
After you’ve gathered enough information, you can try to determine the problem’s cause. There are two possible approaches, described in the following table.
| Approach | Description |
|---|---|
| Linear | Proceed through a logical series of steps. Start with the problem statement, and then proceed in a methodical manner until you uncover the problem’s source. |
| Subtractive | Form a mental picture of the system components. Separate the components into two halves along a testable line. For example, you might ask yourself whether a service component or a network component is causing the problem. You then would perform tests to determine on which side of the line the problem falls, and then continue in the same manner until you isolate the problem component. |
Whatever approach you take, your aim is to isolate the problem’s cause. After your tests prove the problem’s cause, you must plan your course of action.
Important
If you think you’ve determined the cause, you should test your assumptions. If the tests are inconclusive, you must continue testing.
Implement an action plan
After planning your course of action, you must implement the plan. There are two important considerations, discussed in the following table.
| Consideration | Description |
|---|---|
| Service availability | If you are implementing a plan of action to resolve serious problems, you must consider the impact on service availability that your proposed changes might have. |
| Change management | Larger organizations implement change-management procedures, and you must adhere to these procedures. |
Document corrections
After you’ve resolved a problem successfully, you must document the resolution. This documentation involves several processes, depending upon your technical support infrastructure. At the very least, you must inform the Teams administrator and helpdesk that you resolved the problem.
Important
If a logging system is in use, you must close the incident in the log.