About this Troubleshooting Series
This series will describe the best way to troubleshoot a SharePoint concern. In spite of having the best technology and the best performing infrastructure possible, the need to get more out of what exists, is inevitable. SharePoint as a platform fits well into the legacy infrastructure landscape and therefore troubleshooting will need to overlook beyond SharePoint. The scope of this whitepaper is to cover the best ways to troubleshoot and ensure that an investigator is led in the right path. Personal experience and knowledge gathered from published articles is the base of this paper. The vision of this series is to sketch the activities in the right sequence. The content is kept simple and straight.
What it takes to be an Investigator
Being a pivotal part of a support team for most of my SharePoint career has helped me in getting to understand and feel the pulse of troubleshooting, handling user concerns, setting stakeholder expectations, finding workarounds, coordinating with various relevant teams, finding root causes, contacting premier support of the vendor, communicating back to the customer, preparing a root cause analysis document, updating the knowledgebase, updating all relevant teams and it goes on like that.
Chasing an issue and resolving it requires a diagnostic mind. Following a methodical approach in the process of troubleshooting an issue is an important skill.
Start looking into an issue with a fresh mind. Don't jump to conclusion at the start! This is the most common mistake. Be slow, be steady. Allocate a good amount of time to understand the problem and sketch the activities necessary to be performed to eliminate a possible source and trace the issue.
Discussions with Subject matter experts and co-workers are an essential part of investigation. One key thing to note here is that you need to ask the right questions when gathering the information. If discussions tend to extend and sway in the wrong direction, be cautious and pull back. Take notes, and consider additional information when it's useful during the execution of the sketched activities.
What a debugging process is
The most common term used in the process of identifying the issue causing a concern is debugging. Based on the type of software used and underlying infrastructure, debugging tools and techniques vary vastly. One cannot use the same tool for another technology. Still there exists some tools that can cross over technology or better that can be used for the same purpose.
Trying to reproduce the issue is one key activity within the debugging process. The task can vary its complexity based on the systems used for it.
What changes happened recently?
Find a representative environment first to reproduce the issue. If the issue is not reproduced then the question arises, what changed recently? Was there a software or hardware change that happened recently?
Think about preparing the representative environment. Then reproduce the issue. Make things simple and zero in on that piece of activity that causes the issue. Now begin the troubleshooting.
Getting a good representative environment often is a problem in itself. Bigger organizations do have the sequence of Development, Integration and Testing, Acceptance and Production environments. This helps a lot in finding the representative environment to start troubleshooting. Complexity increases from Production to Development.
References
Next article: SharePoint Troubleshooting Guide: Part 2