Suggérer une traduction
 
Suggestions d'autres utilisateurs :

progress indicator
Aucune autre suggestion.
TechNet Magazine > Accueil > Tous les numéros > 2009 > TechNet Magazine Août 2009 >  Microsoft Dynamics : Dépannage de Microsoft Dyn...
Affichage du contenu : côte à côteAffichage du contenu : côte à côte
Ce contenu traduit automatiquement peut être modifié par les membres de la communauté. Nous vous invitons à améliorer la traduction en cliquant sur le lien « Modifier » associé aux phrases ci-dessous.
Microsoft Dynamics
Troubleshooting Microsoft Dynamics CRM
Aaron Elder
 
At a Glance:
  • Illustrating a Solution Architecture
  • Fundamental troubleshooting principles
  • Tools for diagnosing server issues
  • Steps to resolving CRM errors

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.

1. A problem or error is identified and reproduced.
  • Have you identified the problem and have you read the error message?
  • Is the error message generic? If so, have you taken steps to find the "real error"? Hint: If the error says "Something happened, contact your System Administrator," remember that you are probably that System Administrator and therefore need to do more digging to find the real error. Before you move to Step 3, you must be sure you are dealing with the actual error.

2. The problem needs to be understood.
  • Did you read and comprehend what the error message is saying?
  • Do you have a consistent set of steps to reproduce the issue reliably?

3. The problem needs to be isolated.
  • What systems in your System Architecture can you rule out as a cause of or influence on the problem?
  • What components of the Solution Architecture can you rule out as a cause of or influence on the problem?

4. The fix needs to be identified and understood.
  • Are you able to find support articles, blog posts, or newsgroup postings that suggest fixes that apply to your exact problem?
  • Before applying a fix, do you understand why it will correct the problem?

5. The fix needs to be applied and verified.
  • Does the applied fix resolve the issue? You will need to be able to reproduce the issue (Step 2) in order to be sure. Because you understand the fix, have you re-tested other areas of the system that might be affected?

Troubleshooting Server Issues
With an understanding of the troubleshooting process, we can now move on to the tools needed for diagnosing problems within Microsoft CRM.
DevErrors—When Microsoft Dynamics CRM submits data to the server, information is passed to ASP.NET and processed. Any errors are handled by a global exception handler at the ASP.NET layer. For usability and sometimes security reasons, the real error is hidden from the caller (that's you or your user) and a "pretty error" is displayed instead. Typically this error says something like "You do not have sufficient privileges" or "The requested record was not found." Unfortunately, these pretty errors come from a "white list." Of the hundreds of thousands of errors that could be thrown by CRM or any related component (SQL, SRS, .NET, Windows, and so on), only error codes that the CRM team thought might happen have a pretty string associated with them. The rest get handled by the dreaded catchall "An error has occurred, please contact your System Administrator." This, of course, is not of much use to you, the System Administrator.
Since one of our ground rules is to get the real error, you need to be able to tell when CRM is lying or at least not telling you the whole truth. The truth serum is to enable DevErrors via the web.config. This is done by modifying the [CRMWEB]\web.config file like so: 
<add key="DevErrors" value="On"/>
Be sure to keep your System Architecture in mind when doing this. If you have two servers configured in a load-balanced environment, you will want to isolate the server where the error is happening or, alternatively, be sure to enable DevErrors on both servers. Once DevErrors is enabled, you will see errors that look something like the one in Figure 3.
Figure 3 A Microsoft CRM Error Report
Figure 3 shows several items on the left that provide different sets of information:
The Detailed Error—The first screen (the default) shows you the real error from Microsoft Dynamics CRM's point of view. This includes the Date, Time, and Server name where the error occurred, as well as the Error Description, Call Stack, Error Number (if available), the Source File and Line Number where the error occurred (if available), and the URL that was requested—all useful when trying to figure out what went wrong.
The ASP.NET Error—The next item is the real error from ASP.NET's perspective. This provides much the same information as the CRM error, but adds the options to "Show Detailed Compiler Output" and "Show Complete Complication Source."
Diagnostic Info—The third screen, shown in Figure 4, provides basic information about the server, where the error occurred and details about the client and user that made the request. This information includes server operating system, .NET runtime version, server name, and the path to where CRM is installed. Information on the specific CRM database used and settings in the web.config also is included. For the client, the screen shows the browser version, screen resolution, bit depth, and more. Information on the user making the request (at least from CRM's point of view) includes the user's domain and name, CRM user name, CRM User ID, Business Unit ID, and Organization ID.
Figure 4 The Diagnostic Info Screen
What the User Would Have Seen—The final item, shown in Figure 5, allows you to see from the perspective of the end user, as if DevErrors were turned off.
Figure 5 The Error Message the User Would Have Seen
Please note that DevErrors helps only with errors that happen during the processing of a Web application request and only those requests that involve a full page submit to the server. AJAX requests, such as with a publish of customizations, a workflow, or a grid action, do not support DevErrors. For these, you will have to use tracing.
TIP: If the information on the DevErrors page is cut off and you can't resize the window to see more, simply double-click anywhere on the page and a resizable window will open.
Tracing—If a CRM error happens anywhere other than from a direct Web request, the best way to get the real error is to use CRM tracing. Tracing can be enabled and configured by following the steps in the "How to enable tracing in Microsoft Dynamics CRM" article at support.microsoft.com/kb/907490. Or you can use a tool such as CrmDiagTool, available at box. net/shared/6oxfqi2ida.
TIP: In CRM 4.0, the "Trace Directory" is ignored.
Tracing can be scary for the novice, so don't get frustrated. In general, tracing should be used only when troubleshooting an issue. Depending on how you configure tracing, there can be a significant performance impact when it is running, and if you have verbose logging on, a heavily used system can easily create hundreds of megabytes of logs per hour. The article mentioned above provides a detailed explanation of all the ways to configure tracing and how to enable tracing for client and server.
TIP: When emailing out trace logs for help, be sure to compress them first. Log files are just text and usually compress by 90 percent or more.
Log File Structure—When tracing is enabled on the server, logs will be placed in the Trace folder, which is located where you installed CRM. Each service has its own log file and each file will by default grow to 10MB before a new file is started. Since the log files are actively being written to by the various CRM processes, you will not get the absolute latest trace information until the corresponding service (either IIS or Async Service) is stopped. When you open the folder you will see files such as
-CRMDEV-VPC-CrmAsyncService-bin-20090415-1.log
-CRMDEV-VPC-w3wp-CRMWeb-20090415-1.log
The naming convention is [MACHINE NAME] – [CRM PROCESS] – [YEAR MONTH DAY] – [SEQUENCE].LOG
The log file contains loads of information, with items written in chronological order. Note that the trace log writes the latest event at the bottom of the file, while within a call stack items are written in reverse chronological order (newest item first).
TIP: When looking for errors in the log, try searching for ": Error" (a colon followed by a space, then Error.
Event Log—The Windows Event Log is another place to look for errors that occur within Microsoft Dynamics CRM, its dependent components, or other areas of the system. Just like the Trace Log, the Event Log will generally provide more details about errors that occur within the system.
Microsoft CRM does not log all errors to the Event Log. For example, a disabled user trying to log in is logged while an attempt to update a record that no longer exists is not logged. Though this isn't documented, CRM logs errors to the Event Log from the following subsystems:
-MSCRMPerfCounters
-MSCRMPlatform
-MSCRMKeyArchiveManager
-MSCRMKeyGenerator
-MSCRMEmail
-MSCRMDeletionService
-MSCRMReporting
-MSCRMWebService
-MSCRMAsyncService
-ASP.NET 2.0
The ASP.NET 2.0 bucket acts as a "catch most" for Application layer errors. In addition, the Microsoft Dynamics CRM Email Router Service has its own Event Log (MSCRMEmailLog) that can be configured independently to log a wide range of information, warnings, and errors.
Since Event Logging does not need to be turned on, it is a good starting place to look for issues.
Reading a Call Stack—Call stacks come in all shapes and sizes and all too often are overlooked by nondeveloper troubleshooters. It is not uncommon for system engineers to simply "ignore the developer stuff" and research only the error message or code. I recommend that you not do this—even though the call stack looks like code, it is designed to be human readable and to tell what happened right up until the error occurred. Look at the following example: 
[ReportServerException: The Report Server Windows service 'ReportServer' is not running. 
   The service must be running to use Report Server. (rsReportServerServiceUnavailable)]
   at Microsoft.Reporting.WebForms.ServerReport.SetDataSourceCredentials(DataSourceCredentials[]credentials)
   at Microsoft.Crm.Web.Reporting.SrsReportViewer.SetExecutionCredentials(ServerReport report)

[CrmReportingException: The Report Server Windows service 'ReportServer' is not running. 
The service must be running to use Report Server. (rsReportServerServiceUnavailable)]
   at Microsoft.Crm.Web.Reporting.SrsReportViewer.SetExecutionCredentials(ServerReport report)
   at Microsoft.Crm.Web.Reporting.SrsReportViewer.ConfigurePage()
   at Microsoft.Crm.Application.Controls.AppUIPage.OnPreRender(EventArgs e)
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
What you see here is a list of all the things the system did (the calls) listed in reverse chronological order (the stack) up until the last thing it "tried" to do. In this case, the first thing that happened—the call at the bottom of the stack—was a call to System.Web.UI.Page.ProcessRequestMain().
When reading call stacks, it is important to read the name of each call. For each call listed, the words between the last period and the parenthesis are the method name. Words before the method name are the namespace, and the items within the parentheses, the parameters. In this case, the method ProcessRequestMain was called first; this method is in the System.Web.UI.Page namespace; and this method expects two Boolean (True/False) parameters. Right away, by the reading the namespace, we know that this call is not to any Microsoft Dynamics CRM code; this is actually calling code in the base .NET Framework (denoted by the System root namespace) and specifically to ASP.NET (denoted by the Web namespace). As we read "up" the stack, we see that ProcessRequestMain then called PreRenderRecursiveInternal, which then called OnPreRender. The OnPreRender method is the first method that is actually a part of the Microsoft Dynamics CRM code base, as denoted by the Microsoft.Crm namespace. As we continue up the call stack, we see that CRM actually makes a call into the SQL Reporting Services method SetDataSourceCredentials. This method then throws an exception of type ReportServerException with the error that the Report Server is not running. As you can see, by reading the call stack, you can tell that this error is not coming from CRM at all, but is instead coming from SQL Server Reporting Services (SSRS) and is then being "bubbled up" through CRM as a CrmReportingException. Based on your system architecture, you will have to determine where SSRS is running in order to know where to go start the service to resolve the issue.
Reading call stacks in this manner can help you isolate where an error is actually coming from. The final call in the stack might be something like YourCompany.Crm.Extensions.UpdateRecord(); this would tell you that the error appears to be coming from either code written by your developers or perhaps an ISV solution you purchased.
It is not uncommon for CRM errors to actually come from SQL Server in the case of referential integrity (RI) or other SQL level constraints, or from the .NET Framework itself.

Play at Home Example
Now let's give you a chance to play at home. Let's assume you have created a new user in CRM and that user is trying to use the system for the first time and is getting the error as shown in Figure 6.
Figure 6 A CRM Error Received By a First-Time User
What steps would you take to solve this problem? To resolve this issue, let's follow our basic troubleshooting workflow.

1. A problem or error is identified and reproduced.
You should ask the user what he was trying to do when he received the error, then attempt to reproduce the steps to see if you can recreate the error.

2. The problem needs to be understood.
Let's read the error message from the troubleshooter's point of view: "the logged-on user does not have the appropriate security permissions."
To understand the problem, you have to be able to answer two questions: Who is "the logged-on user"? What "security permission" does he "not have"?

3. The problem needs to be isolated.
In this case, you can answer both questions by using CRM tracing. You know that tracing is needed because this error page is in a dialog and does not provide the information that DevErrors would. CRM does not log privilege errors like this to the Event Log. Let's enable tracing and reproduce the issue using the same user. The Trace Log provides the following detailed error: 
MSCRM Error Report:
Error: Exception has been thrown by the target of an invocation.
Error Number: 0x80040220
Error Message: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: 
  e76c5f50-40b3-dc11-8797-0003ffb8057d and PrivilegeId: 7863e80f-0ab2-4d67-a641-37d9f342c7e3
Error Details: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: 
  e76c5f50-40b3-dc11-8797-0003ffb8057d and PrivilegeId: 7863e80f-0ab2-4d67-a641-37d9f342c7e3
Source File: Not available
Line Number: Not available
Request URL: http://localhost:5555/AscentiumCrmDev/sfa/accts/edit.aspx?id={906C2F37-8D28-DE11-8D9F-0003FFB23445}
Stack Trace Info: [CrmSecurityException: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: 
  e76c5f50-40b3-dc11-8797-0003ffb8057d and PrivilegeId: 7863e80f-0ab2-4d67-a641-37d9f342c7e3] at
  Microsoft.Crm.BusinessEntities.SecurityLibrary.CheckPrivilege(Guid user, Guid privilege, ExecutionContext context)
…
From this error and by reading the call stack details, you can see that the problem is caused by a CRM Check Privilege failure. You can see the GUID of the user who made the request as well as the GUID of the privilege he tried to use.
If you perform a Live Search on the Privilege 7863e80f-0ab2-4d67-a641-37d9f342c7e3, the first hit is to the Microsoft CRM SDK.
Following this link, you can see that the privilege the user needs is prvWriteAccount, which is the privilege that grants the user update rights on the Account entity. The same method would work for any of the hundreds of out-of-the-box privileges, as the GUIDs are all known. If you search for the Privilege ID and it was not found, the privilege might be on one of your custom entities, in which case you will need to query your local SQL Server to find out what privilege is being requested. The following script will yield the same information: 
SELECT PrivilegeId, Name
FROM PrivilegeBase
WHERE PrivilegeId = '7863e80f-0ab2-4d67-a641-37d9f342c7e3'
Now that you know what privilege is needed, you just need to verify which user is missing the privilege. While you can sometimes assume that the calling end user is the one, you can't always be sure, such as when actions are performed via code, plug-ins, or custom extensions. In such cases, you may want to do a query to find the name of the user CRM thought was trying to use the privilege. The following script will handle this: 
SELECT SystemUserId, DomainName
FROM SystemUserBase
WHERE SystemUserId = 'e76c5f50-40b3-dc11-8797-0003ffb8057d'
TIP: If the user GUID is all zeros (00000000-0000-0000-0000-000000000000), the user is probably the SYSTEM account and this means the calling user was probably an account such as Network Service. System accounts do not typically get CRM roles; instead they are granted elevated privileges via the PrivUserGroup in Active Directory.

4. The fix needs to be identified and understood.
You can now go into CRM and check to see what roles the user has, as shown in Figure 7.
Figure 7 User Roles in CRM
You can then drill down and see that the Salesperson role is indeed missing the Write on Account privilege as shown in Figure 8.
Figure 8 Core Records of the Salesperson Role shows it’s missing the Write privilege under Account.

5. The fix needs to be applied and verified.
To fix the issue, you simply need to grant the Write privilege to this role and save it. Be careful to make sure you understand which other users this will affect. Once you apply the fix, you can ask the user to try again to verify the problem has been resolved. You should then disable tracing and call the case closed.

Wrapping Up
Troubleshooting Microsoft Dynamics CRM means following basic ground rules and a methodology that includes identifying the real issue, narrowing scope, isolating the issue, and understanding the fix. You'll find the DevErrors, Event Logging, and Tracing tools in Microsoft Dynamics CRM critical in your troubleshooting efforts.

Aaron Elder (Microsoft Dynamics CRM MVP) works for Ascentium, a technology consulting and interactive marketing agency. Visit the Ascentium blog at ascentium.com/blog/crm.

Microsoft Dynamics
Dépannage de Microsoft Dynamics CRM
Aaron Elder
 
Vue d'ensemble :
  • Illustrant une architecture de solution
  • Principes de résolution des problèmes fondamentaux
  • Outils pour diagnostiquer les problèmes de serveur
  • Étapes de résolution des erreurs de CRM

Je ’m retour pour un article deuxième sur Microsoft Dynamics CRM (consultez l'article de la première «Deploying Microsoft Dynamics CRM 4.0 "), l'accent sur quelque chose que je suis passionné —, résolution des problèmes. Résolution des problèmes Microsoft CRM n'est pas très différent de résolution des problèmes n'importe quelle autre application Web à n niveaux basée sur la pile Microsoft. En tant que tel, cet article n'est pas un repère de procédure ou une collection de «101 conseils &Astuces." Au lieu de cela, j'aborderai les bases de Dynamics CRM composants et outils pour isoler, comprendre et résoudre les problèmes. Pour cet article, je me concentrerai uniquement sur les aspects côté serveur de Microsoft Dynamics CRM problèmes de dépannage.

La pile
Tout système complexe, il le corps humain ou une application Web à n niveaux qui tire parti des nombreuses aussi complexes sous-systèmes et des systèmes externes, il est important de comprendre» la pile système». La pile est en fait un plan d'un système qui permet de comprendre tous les composants de ce système et leur mode de génération et de la couche de l'autre. La pile peut également être appelée diagramme architecture de solution, comme il illustre les composants de la solution ; dans ce cas, Microsoft Dynamics CRM. Une fois que vous comprenez la solution, vous devez également comprendre comment la solution a été déployée. Pour ce faire, vous devez un schéma d'architecture système, qui illustre où chaque composant de la solution se trouve par rapport aux autres dans votre déploiement. Comprendre tout ceci est essentiel de pouvoir isoler le problème.
La figure 1 présente une solution architecture de tâches de Microsoft Dynamics CRM 4.0, montrant tous ses composants principaux et leurs interdépendances. Notez que chaque composant peut à son tour avoir son propre diagramme de complexité supérieure ou égale. Systèmes informatiques sont tout sur abstraction, le processus par lequel un composant système propose un ensemble de fonctionnalités de ce composant dépendant, un autre peut reposer sur, masquant la complexité interne de ce composant. Abstraction est la raison que vous devez isoler un problème lors de la résolution des problèmes.
Figure 1 Diagramme de paquetage illustrant une architecture de solution
Pour exprimer l'architecture de solution, j'ai utilisé un diagramme de paquetage. Flèches point dans le sens de la «dépendance». Par exemple, le routeur de messagerie CRM "dépend"un serveur SMTP et Web Services de plate-forme CRM. Un diagramme complet serait très complexe, mais cela fournit un modèle de base.
Maintenant vous pouvez considérer comment les composants de Microsoft Dynamics CRM sont déployés au sein de votre entreprise. Pour les besoins de cet article, nous allons utiliser une architecture de déploiement standard, comme dans figure 2. Comprendre comment l'architecture du système est lié à l'architecture de solution est essentielle pour isoler les problèmes. Sans savoir où les composants exécutent, vous pouvez passer des heures à essayer de trouver et résoudre un problème qui n'est pas encore qui se passe sur l'ordinateur que vous tentez de résoudre !
La figure 2 une architecture de déploiement standard

Règles de sol
Avant de commencer un dépannage avec Dynamics CRM, vous devez comprendre quelques principes de résolution des problèmes fondamentaux. Tout d'abord, nous allons via un flux de travail de résolution des problèmes et des instructions pour comment vous savez quand il est possible sans procéder à l'étape suivante.

1. Un problème ou une erreur est identifiée et reproduit.
  • Avez-vous identifié le problème et que vous lisez le message d'erreur ?
  • Est le message d'erreur générique ? Si tel est le cas, avoir prises étapes pour rechercher «erreur réel» ? Un indice : Si l'erreur indique «quelque chose s'est produite, contactez votre administrateur système»Souvenez-vous que vous trouvez sans doute qu'administrateur système et devez donc faire rentrer plus pour trouver l'erreur réelle. Avant de passer à l'étape 3, vous devez être sûr que vous traitez l'erreur réelle.

2. Le problème doit être compris.
  • A lire et comprendre ce que dit la message d'erreur ?
  • Vous avez un ensemble cohérent d'étapes pour reproduire le problème fiable ?

3. Le problème doit être isolé.
  • Les systèmes de votre architecture système pouvez vous éliminer une cause d'ou influence sur le problème ?
  • Quels composants de l'architecture de solution pouvez vous écarter comme une cause d'ou influence sur le problème ?

4. Le correctif doit être identifié et comprises.
  • Vous êtes capable de trouver prise en charge des articles, billets de blog ou publications de groupes de discussion suggèrent des corrections qui s'appliquent à votre problème exact ?
  • Avant d'appliquer un correctif, vous comprennent-ils pourquoi il va corriger le problème ?

5. Le correctif doit être appliquée et vérifiées.
  • Le correctif appliqué résout-il le problème ? Vous devez pouvoir reproduire le problème (étape 2) afin d'être sûr. Parce que vous comprenez le correctif, avez re-tested autres zones du système peut être affecté ?

Résolution des problèmes de serveur
Avec une compréhension du processus de dépannage, nous pouvez maintenant passer aux outils nécessaires pour diagnostiquer des problèmes dans Microsoft CRM.
DevErrors, lorsque Microsoft Dynamics CRM envoie des données sur le serveur, les informations sont transmises au ASP.NET et traité. Les erreurs sont gérées par un gestionnaire d'exceptions global à la ASP.NET couche. Pour facilité d'utilisation et parfois des raisons de sécurité, l'erreur réel est masquée à l'appelant (c'est vous ou votre utilisateur) et «erreur convivial»s'affiche. En général cette erreur disant quelque chose comme «Vous n'êtes pas des privilèges suffisants»ou «l'enregistrement demandé est introuvable.» Malheureusement, ces erreurs très proviennent d'une «liste de blanc». Des centaines de milliers d'erreurs qui pourraient être levées par CRM ou tout composant connexe (SQL, SRS, .NET, Windows et ainsi de suite), seule l'erreur codes la pensée d'équipe CRM peut se produire posséder une chaîne très associée. Le reste obtenir géré par catchall redouté "une erreur s'est produite, contactez votre administrateur système." Bien sûr, n'est pas de très utile pour vous, l'administrateur système.
Étant parmi nos règles à suivre pour obtenir l'erreur réelle, vous devez pouvoir indiquer lorsque CRM est à l'ou au moins ne pas vous indiquant la vérité ensemble. La vérité serum consiste à activer DevErrors via le fichier web.config. Pour cela, modifiez le [fichier CRMWEB]\web.config comme suit : 
<add key="DevErrors" value="On"/>
Veillez à conserver votre architecture système esprit lors de cette opération. Si vous avez deux serveurs configurés dans un environnement à charge équilibrée, vous devez isoler le serveur où l'erreur qui se passe ou, ou bien, veillez à activer DevErrors sur les deux serveurs. Une fois DevErrors est activé, vous verrez les erreurs ressembler à celui de figure 3.
La figure 3 A de rapport d'erreurs Microsoft CRM
La figure 3 présente plusieurs éléments sur la gauche qui fournissent différents ensembles d'informations :
L' erreur détaillée, le premier écran (par défaut) affiche l'erreur réelle à partir de point de vue du Microsoft Dynamics CRM. Cela inclut le nom date, Time et Server où l'erreur, ainsi que la description d'erreur, pile des appels, numéro d'erreur (si disponible), le fichier source et numéro de ligne où l'erreur s'est produite (si disponible) et l'URL a été demandé, tout utile lors de tenter de déterminer la cause du problème.
L' erreur ASP.NET, l'élément suivant est l'erreur réel point du ASP.NET de vue. Cela fournit beaucoup les mêmes informations que l'erreur CRM mais ajoute les options «Afficher la sortie du compilateur détaillé»et «Afficher Source Complication terminé».
Informations de diagnostic, le troisième écran, illustré à la figure 4, fournit des informations base sur le serveur, où l'erreur s'est produite et les détails sur le client et l'utilisateur qui a effectué la demande. Ces informations comprennent système d'exploitation serveur, version du runtime .NET, nom de serveur et le chemin vers lequel CRM est installé. Les informations sur les base de données CRM utilisée et les paramètres dans le fichier web.config spécifique sont également incluses. Pour le client, l'écran affiche la version du navigateur, résolution d'écran, la profondeur et plus. Informations sur l'utilisateur qui effectue la demande (au moins à partir de CRM point de vue) inclut l'utilisateur domaine et nom, nom d'utilisateur CRM, CRM UserID, Business Unit ID et ID d'organisation.
Figure 4 l' écran informations de diagnostic
Que l'utilisateur souhaitez-vous ont vu, l'élément final illustré à la figure 5, permet d'afficher du point de vue de l'utilisateur final, comme si DevErrors ont été désactivés.
La figure 5 le message d'erreur l'utilisateur souhaitez-vous ont vu
Notez que DevErrors aide uniquement des erreurs qui se produisent lors du traitement d'une demande d'application Web et n'aux requêtes qui impliquent une page entière envoyer au serveur. AJAX demande, comme avec une publication de personnalisations, un flux de travail, ou une action de la grille, ne prennent en charge DevErrors. Dans ce cas, vous devez utiliser le traçage.
CONSEIL : Si les informations sur la page DevErrors sont coupées et vous ne pouvez pas redimensionner la fenêtre pour en savoir plus, double-cliquez simplement sur n'importe où sur la page et une fenêtre redimensionnable s'ouvre.
Tracing—If a CRM error happens anywhere other than from a direct Web request, the best way to get the real error is to use CRM tracing. Le suivi peut être activé et configuré en suivant les étapes dans «Comment activer le suivi dans Microsoft Dynamics CRM»article à support.microsoft.com/kb/907490. Ou vous pouvez utiliser un outil tel que CrmDiagTool, disponible à la zone. NET/partagé/6oxfqi2ida.
CONSEIL : Dans CRM 4.0, le «Directory suivi"est ignoré.
Le suivi peut être pour l'utilisateur débutant, afin de ne pas obtenir frustrés. En règle générale, le traçage doit être uniquement utilisé lorsque résoudre un problème. Selon la configuration de suivi, il peut exister un impact notable des performances lorsqu'il est en cours d'exécution, et si vous avez l'enregistrement de commentaires sur, un système très utilisé pouvez facilement créer des centaines de mégaoctets de journaux par heure. L'article mentionné ci-dessus fournit une explication détaillée de toutes les façons de configurer le suivi et comment activer le suivi client et serveur.
CONSEIL : Lors de l'envoi des journaux de suivi pour obtenir de l'aide, veillez à les compresser tout d'abord. Les fichiers journaux sont uniquement du texte et généralement compresser à 90 pour cent ou plus.
Structure des fichiers la session, lorsque le traçage est activé sur le serveur, les journaux seront placés dans le dossier suivi, qui se trouve dans lequel vous avez installé CRM. Chaque service possède son propre fichier journal et chaque fichier par défaut jusqu'à 10 Mo avant de démarrer un nouveau fichier. Étant donné que les fichiers journaux sont activement écrits dans par les divers processus CRM, vous obtiendrez pas les dernières informations trace absolu jusqu'à ce que le service correspondant (services Internet (IIS) ou service asynchrone) est arrêté. Lorsque vous ouvrez le dossier vous verrez comme fichiers
-CRMDEV-VPC-CrmAsyncService-bin-20090415-1.log
-CRMDEV-VPC-w3wp-CRMWeb-20090415-1.log
La convention d'affectation de noms est [MACHINE NAME] – [PROCESS de le CRM] – [YEAR MONTH DAY] – [SEQUENCE] .log
Le fichier journal contient des charges d'informations, avec éléments écrits dans l'ordre chronologique. Notez que le journal de suivi écrit le dernier événement en bas du fichier, dans une pile d'appel éléments sont écrits dans inverser l'ordre chronologique (plus récent article première).
CONSEIL : Lorsque vous recherchez des erreurs dans le journal, recherchez ": Erreur"(un signe deux-points suivi d ' un espace, puis erreur.
Journal des événements, le journal des événements Windows est un autre emplacement pour rechercher les erreurs qui se produisent dans Microsoft Dynamics CRM, ses composants dépendants ou autres zones du système. Comme le journal de suivi, le journal des événements fournira généralement plus de détails sur erreurs qui se produisent au sein du système.
Microsoft CRM n'enregistre pas toutes les erreurs dans le journal des événements. Par exemple, un utilisateur désactivé qui tente de se connecter est consigné ouvert pas d'une tentative de mise à jour un enregistrement qui n'existe plus. Si ce n'est pas documenté, CRM enregistre les erreurs dans le journal des événements de sous-systèmes suivants :
-MSCRMPerfCounters
-MSCRMPlatform
-MSCRMKeyArchiveManager
-MSCRMKeyGenerator
-MSCRMEmail
-MSCRMDeletionService
-MSCRMReporting
-MSCRMWebService
-MSCRMAsyncService
-ASP.NET 2.0
Le ASP.NET 20 compartiment agit comme un "catch plus"les erreurs de couche application. En outre, le service routeur Microsoft Dynamics CRM messagerie possède son propre journal d'événements (MSCRMEmailLog) peuvent être configurés indépendamment pour enregistrer un large éventail de plus d'informations, avertissements et erreurs.
Étant donné que journal des événements n'a pas besoin être activée, il est de départ idéal pour rechercher des problèmes.
Lecture d'une pile des appels, piles d'appels sont fournis dans toutes les formes et tailles d'et sont bien trop souvent négligés par les utilitaires de résolution de problèmes nondeveloper. Il n'est pas rare pour les ingénieurs système de simplement "ignorer les éléments de développeur"et recherche uniquement le message d'erreur ou le code. Je recommande que vous le faites pas, même si la pile des appels ressemble de code, il est conçu pour être lisible et pour indiquer qu'est-il advenu de droite jusqu'à l'erreur s'est produite. Examinez l'exemple suivant : 
[ReportServerException: The Report Server Windows service 'ReportServer' is not running. 
   The service must be running to use Report Server. (rsReportServerServiceUnavailable)]
   at Microsoft.Reporting.WebForms.ServerReport.SetDataSourceCredentials(DataSourceCredentials[]credentials)
   at Microsoft.Crm.Web.Reporting.SrsReportViewer.SetExecutionCredentials(ServerReport report)

[CrmReportingException: The Report Server Windows service 'ReportServer' is not running. 
The service must be running to use Report Server. (rsReportServerServiceUnavailable)]
   at Microsoft.Crm.Web.Reporting.SrsReportViewer.SetExecutionCredentials(ServerReport report)
   at Microsoft.Crm.Web.Reporting.SrsReportViewer.ConfigurePage()
   at Microsoft.Crm.Application.Controls.AppUIPage.OnPreRender(EventArgs e)
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Ce que vous voyez ici est une liste de tout ce que le système n'a (les appels) répertoriés par ordre chronologique inversé (la pile) jusqu'à la dernière chose il a «tenté»Pour faire. Dans ce cas, la première chose qui s'est produite, l'appel au bas de la pile, un appel à System.Web.UI.Page.ProcessRequestMain() a.
Lorsque vous lisez des piles d'appels, il est important de lire le nom de chaque appel. Pour chaque appel de la liste, les mots entre la dernière période et les parenthèses sont le nom de méthode. Mots avant le nom de méthode sont l'espace de noms et les éléments dans les parenthèses, les paramètres. Dans ce cas, la méthode ProcessRequestMain a été appelée en premier ;Cette méthode est dans l'espace de noms System.Web.UI.page ;et cette méthode attend deux paramètres de valeur booléenne (true/false). Immédiatement, en le lisant l'espace de noms, nous savons que cet appel est non à tout code Microsoft Dynamics CRM ;Cela est en fait appeler du code dans la base .NET Framework (indiquée par l'espace de noms racine System) et en particulier à ASP.NET (indiquée par l'espace de noms Web). Comme nous avons lu "haut"la pile, nous voyons que ProcessRequestMain appelée puis PreRenderRecursiveInternal, puis appelé OnPreRender. La méthode OnPreRender est la première méthode est en fait une partie de la base, de code de Microsoft Dynamics CRM indiqué par l'espace de noms Microsoft.Crm. Que nous continuons dans la pile des appels, nous voyons que CRM effectue en fait un appel à la méthode SQL Reporting Services SetDataSourceCredentials. Ensuite, cette méthode lève une exception de type ReportServerException avec l'erreur que le serveur de rapports ne fonctionne pas. Comme vous pouvez le voir, en lisant la pile des appels, vous voyez que cette erreur pas provient CRM, mais provenance plutôt SQL Server Reporting Services (SSRS) et est puis en cours "propagée jusqu'à"par CRM comme une CrmReportingException. Selon l'architecture de votre système, vous devrez peut-être déterminer où SSRS s'exécute afin de savoir où aller démarrer le service pour résoudre le problème.
Lecture des piles d'appels de cette manière peut vous aider à isoler une erreur est réellement provenance. Le dernier appel de la pile peut être quelque chose comme YourCompany.Crm.Extensions.UpdateRecord() ;Ce serait indiquent que l'erreur s'affiche à provenant d'un code écrit par vos développeurs ou éventuellement une solution ISV que vous avez acheté.
Il n'est pas rare pour CRM erreurs proviennent réellement SQL Server dans le cas d'autres contraintes de niveau de SQL ou l'intégrité référentielle (RI) ou du .NET Framework lui-même.

Lire à la maison exemple
Maintenant nous allons vous donner une chance pour jouer à la maison. Supposons que vous avez créé un nouvel utilisateur dans CRM et que cet utilisateur essaie d'utiliser le système pour la première fois et reçoit l'erreur comme dans figure 6.
La figure 6 A CRM erreur reçu par un utilisateur au moment du premier
Quelles mesures peut prendre pour résoudre ce problème ? Pour résoudre ce problème, nous allons Suivez notre flux de résolution des problèmes.

1. Un problème ou une erreur est identifiée et reproduit.
Vous devez demander à l'utilisateur ce qu'il essayait de faire lorsqu'il a reçu l'erreur, puis essayez de reproduire les étapes pour voir si vous pouvez recréer l'erreur.

2. Le problème doit être compris.
Nous allons lire le message d'erreur à partir de point de vue de l'utilitaire de résolution des problèmes : «l'utilisateur connecté ne dispose pas les autorisations de sécurité appropriés.»
Pour comprendre le problème, vous devez pouvoir répondre aux deux questions : Qui est «utilisateur connecté» ? La «autorisation sécurité»n'il "avez pas" ?

3. Le problème doit être isolé.
Dans ce cas, vous pouvez répondre à la fois aux questions en utilisant le suivi de CRM. Vous savez que le traçage est nécessaire car cette page d'erreur est dans une boîte de dialogue et ne fournit pas les informations que DevErrors serait. CRM n'enregistre pas privilège erreurs comme suit dans le journal des événements. Nous allons activer le traçage et reproduire le problème en utilisant le même utilisateur. Le journal de suivi fournit l'erreur détaillée suivante : 
MSCRM Error Report:
Error: Exception has been thrown by the target of an invocation.
Error Number: 0x80040220
Error Message: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: 
  e76c5f50-40b3-dc11-8797-0003ffb8057d and PrivilegeId: 7863e80f-0ab2-4d67-a641-37d9f342c7e3
Error Details: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: 
  e76c5f50-40b3-dc11-8797-0003ffb8057d and PrivilegeId: 7863e80f-0ab2-4d67-a641-37d9f342c7e3
Source File: Not available
Line Number: Not available
Request URL: http://localhost:5555/AscentiumCrmDev/sfa/accts/edit.aspx?id={906C2F37-8D28-DE11-8D9F-0003FFB23445}
Stack Trace Info: [CrmSecurityException: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: 
  e76c5f50-40b3-dc11-8797-0003ffb8057d and PrivilegeId: 7863e80f-0ab2-4d67-a641-37d9f342c7e3] at
  Microsoft.Crm.BusinessEntities.SecurityLibrary.CheckPrivilege(Guid user, Guid privilege, ExecutionContext context)
…
Cette erreur et en lisant les détails de pile d'appel, vous pouvez voir que le problème est provoqué par une défaillance de CRM vérifier les privilèges. Vous pouvez voir le GUID de l'utilisateur qui a effectué la demande, ainsi que le GUID du privilège qu'il a tenté d'utiliser.
Si vous effectuez une recherche de Live sur le privilège 7863e80f-0ab2-4 d 67-a641-37d9f342c7e3, le premier accès consiste au Kit de développement (SDK) Microsoft CRM.
Après ce lien, vous pouvez voir que le privilège de l'utilisateur a besoin est prvWriteAccount, ce qui est le privilège qui accorde les droits de mise à jour de l'utilisateur sur l'entité compte. La même méthode serait fonctionne pour des centaines de-de-l'emploi des privilèges, comme les GUID sont connus. Si vous recherchez l'ID de privilèges et il est introuvable, que le privilège peut être sur un de vos entités personnalisées, auquel cas vous devez interroger votre serveur SQL local pour savoir quels privilèges est demandée. Le script suivant produira les mêmes informations : 
SELECT PrivilegeId, Name
FROM PrivilegeBase
WHERE PrivilegeId = '7863e80f-0ab2-4d67-a641-37d9f342c7e3'
Maintenant que vous connaissez le privilège est nécessaire, vous devez uniquement vérifier l'utilisateur qui manque le privilège. Pendant que vous pouvez parfois supposer que l'utilisateur final appel est celle, vous ne pouvez pas toujours être bien sûr, comme lorsque les actions sont effectuées via code, des composants logiciels enfichables ou extensions personnalisées. Dans ce cas, vous souhaiterez peut-être exécuter une requête pour rechercher le nom de l'utilisateur que CRM pensé a essayé d'utiliser le privilège. Le script suivant gérera ce : 
SELECT SystemUserId, DomainName
FROM SystemUserBase
WHERE SystemUserId = 'e76c5f50-40b3-dc11-8797-0003ffb8057d'
CONSEIL : Si l'utilisateur GUID est tous les zéros (00000000-0000-0000-0000-000000000000), l'utilisateur est probablement le compte système et cela signifie que l'utilisateur appelant n'a probablement un compte comme service réseau. Comptes système n'obtiennent pas généralement les rôles CRM ;au lieu de cela, ils bénéficient des privilèges élevés via PrivUserGroup dans Active Directory.

4. Le correctif doit être identifié et comprises.
Vous pouvez maintenant accéder à CRM et vérifiez quels rôles l'utilisateur a, comme illustré à la figure 7.
Figure 7 rôles des utilisateurs dans CRM
Vous pouvez alors descendre et voir que le rôle de vendeur est manquant en effet l'écriture sur les privilèges de compte comme dans figure 8.
La figure 8 enregistrements principaux du rôle de vendeur présente qu'elle pas le privilège d'écriture sous compte.

5. Le correctif doit être appliquée et vérifiées.
Pour résoudre ce problème, vous devez simplement accorder le droit écriture à ce rôle et l'enregistrer. Veillez à Assurez-vous de que comprendre quels utilisateurs cela affectera. Après avoir appliqué le correctif, vous pouvez demander l'utilisateur de réessayer de vérifier que le problème a été résolu. Vous devez ensuite désactiver le suivi et appelez l'incident fermé.

Conclusion
Dépannage de Microsoft Dynamics CRM signifie règles base et une méthodologie qui inclut identifiant le problème réel, restrictives étendue, isoler le problème et présentation du correctif. Vous trouverez les DevErrors, enregistrement des événements et outils de suivi dans Microsoft Dynamics CRM critique dans vos efforts de dépannage.

Aaron Elder (MVP Microsoft Dynamics CRM) fonctionne pour Ascentium, un conseil en technologie et interactif agence de marketing. Visitez le blog Ascentium à ascentium.com/blog/crm.

TechNet Features

Resources

TechNet Subscriptions

Vous n'êtes pas abonné à Technet ?

Évaluez les logiciels Microsoft et planifiez leurs déploiements en toute confiance grâce à un abonnement Microsoft TechNet.

      
Page view tracker