SharePoint Troubleshooting Guide: Part 2

What to do when an issue is reported

The success of pinning down an issue is in the mindset of the investigator. An investigator should be prepared to start with the right essence of data and use the right blend of tools and control the entire troubleshooting process. A professional approach at the start gives confidence to users and stakeholders expecting the resolution. This avoids beating around the bush in stakeholder meetings and also avoids the situation where stakeholders start suggesting troubleshooting tips and tricks.

Gather Information

Use the following to gather information:

Gather information about the application causing the issue.
Gather information about the current configuration of the application.
Gather information about all dependencies with the application.
Gather information about the teams directly related with the application.
What changed recently?
Understand the issue.
How the issue differs from normal behavior?
When did the issue first occur?
What are the monitoring tools used in the environment in scope?
What logs are best suited to help the investigation? Correlate with the monitoring tools identified above.
Do not start with ULS logs. Understand the problem area and start with the right genre of logs.

Most Important

Try to reduce the scope with numerous attributes.

Environments: Cloud, On-Premise, Acceptance and so on
Users: Global, limited, partner, external, application specific permission level and so on
Type of Clients: Browser version, office application version, web services, webdav, custom tool, sandbox solution, Infopath, SharePoint Designer and so on
Other attributes: operating system used, SharePoint CU, SharePoint security update and so on

Note: Keep an exhaustive list of attributes in various categories.

Reproduce the issue

Use the following to reproduce the issue:

Reproduce the issue in another representative environment.
This is the key to get deep into the investigation. Imagine the trouble we get into when an investigator must wait for log files every time the issue is reproduced in the environment in scope.
But there are situations where reproducing the issue in another environment takes a back seat, and focusing on the environment in scope to find more information leads to the root cause.
Decision to reproduce the issue in another environment or use the environment in scope is based on the issue identified and is not in scope of this document.

Identify the deviation

After diagnosis and laying out of all the factors, identify the deviation clearly from the normal behavior.

What is the deviation?
Classify the deviation: Bug, Design Behavior, Error and so on.
What needs to be done to fix the deviation?
Identify the ways to provide the fix to straighten the deviation. This could be a e-change or a published SharePoint CU and so on.

What's at the end of it?

The following to the intended results:

Prepare a consolidated report capturing the data points throughout the troubleshooting process.
Do not make the report exhaustive.
Structure it simple and straight.
Propagate the solution information to teams concerned to avoid similar issues in the future.
Propose best practices wherever necessary to avoid issues in the future.

Thinking within and beyond SharePoint Application level

SharePoint sits in such a landscape where there are many dependencies that need to be overlooked to get to the right direction. This makes troubleshooting SharePoint more complex if the investigator is not planning the troubleshooting properly. This is where the scope of issue identification is very important.

When an issue occurs, try to scope it to the right section of the entire architecture. It can be:

Web Front End server, application server, SQL Server
Farm, Web application, Site Collection, Site
Document library, list, list item, document
Permissions, authentication, custom solutions
Workflow, InfoPath, SharePoint Designer, Office Applications, Performance Point Dashboard
DNS, AD, FIM, ADFS
Service Accounts, User Profiles, AD Security Group
jQuery, HTML, CSS, Silverlight
WCF, JSON, Web Services, REST

The list is endless. But preparing an exhaustive list is always handy for a troubleshooting team.

References

Previous article: SharePoint Troubleshooting Guide: Part 1