Microsoft Dynamics 365 Blog

CRM MVP Aaron Elder contributes this article at TechNet:

I’m back for a second article on Microsoft Dynamics CRM (see the first article, "Deploying Microsoft Dynamics CRM 4.0"), with a focus on something I am passionate about—that is, troubleshooting. Troubleshooting Microsoft CRM is not much different than troubleshooting any other n-tier Web application built on the Microsoft stack. As such, this article is not a how-to guide or a collection of "101 Tips & Tricks." Instead, I will discuss the basics of Dynamics CRM components and tools for isolating, understanding, and solving problems. For this article, I will focus only on troubleshooting the server-side aspects of Microsoft Dynamics CRM issues.

The Stack

With any complex system, be it the human body or an n-tiered Web application that leverages many equally complex subsystems and external systems, it is important to understand "the system stack." The stack is basically a blueprint of a system that allows you to understand all the components of that system and how they build and layer on each other. The stack could also be called the Solution Architecture Diagram, as it illustrates the components of the solution—in this case Microsoft Dynamics CRM. Once you understand the solution, you also need to understand how the solution has been deployed. For this, you need a System Architecture Diagram, which illustrates where each component of the solution sits in relation to the others in your deployment. Understanding all of this is critical to being able to isolate the problem.

Figure 1 shows a Solution Architecture Diagram of Microsoft Dynamics CRM 4.0, depicting all of its major components and their interdependencies. Note that each component could in turn have its own diagram of equal or greater complexity. Computer systems are all about abstraction, the process by which a system component makes available a set of features that another, dependent component can rely on, hiding the internal complexity of that component. Abstraction is the reason you need to isolate a problem when troubleshooting.

Figure 1 UML Package Diagram Depicting a Solution Architecture

To express the solution architecture, I have used a UML Package diagram. Arrows point in the direction of the "dependency." For example, the CRM Email Router "depends on" an SMTP Server and the CRM Platform’s Web Services. A full diagram would be very complex, but this provides a basic model.

Now you can think about how Microsoft Dynamics CRM components are deployed within your enterprise. For the purposes of this article, we’ll use a typical deployment architecture, as shown in Figure 2. Understanding how the system architecture relates to the solution architecture is vital when it comes to isolating problems. Without knowing where components are running, you could spend hours trying to find and fix a problem that isn’t even happening on the machine you are trying to fix!

Figure 2 A Typical Deployment Architecture

Ground Rules

Before you start troubleshooting a problem with Dynamics CRM, you need to understand a few fundamental troubleshooting principles. First, let’s walk through a basic workflow of troubleshooting and some guidelines for how you know when it is safe to proceed to the next step.

Read more…

CRM MVP Aaron Elder

We're always looking for feedback and would like to hear from you. Please head to the Dynamics 365 Community to start a discussion, ask questions, and tell us what you think!