Microsoft Dynamics

Risoluzione dei problemi di Microsoft Dynamics CRM

Aaron Elder

 

Informazioni di riepilogo:

  • Che illustra un'architettura di soluzioni
  • Principi fondamentali di risoluzione dei problemi
  • Strumenti per la diagnosi dei problemi di server
  • Procedura per la risoluzione degli errori CRM

Contenuto

Nell'elenco
Regole di base
Risoluzione dei problemi del server
Riprodurre a casa di esempio
Ritorno a capo le

’M per un secondo articolo su Microsoft DynamicsCRM (vedere l'articolo prima" Distribuzione di Microsoft Dynamics CRM 4.0"), con particolare attenzione su qualcosa è appassionato, vale a dire risoluzione dei problemi. Risoluzione dei problemi di Microsoft CRM non è molto diverso dalla risoluzione dei problemi di qualsiasi altra applicazione Web di livelli basata su stack Microsoft. Di conseguenza, in questo articolo non è una Guida alle procedure o un insieme di "101 suggerimenti e idee." Al contrario, verranno illustrate informazioni di Dynamics CRM componenti e strumenti per isolare, comprensione e risoluzione dei problemi di base sulla. Per questo articolo, mi concentrerò solo sugli aspetti di lato server di Microsoft Dynamics CRM problemi di risoluzione dei problemi.

Nell'elenco

Con qualsiasi sistema complessa, sia essa il corpo umano o un'applicazione Web a n livelli che utilizza molte ugualmente di complessi sottosistemi e sistemi esterni, è importante comprendere "stack sistema." Lo stack è fondamentalmente un progetto di un sistema che consente di comprendere tutti i componenti di sistema e come creare e di livello uno di altro. Lo stack potrebbe anche essere denominato diagramma dell'architettura di soluzioni, come sono illustrati i componenti della soluzione, in questo caso Microsoft Dynamics CRM. Una volta compresa la soluzione, è inoltre necessario comprendere come è stata distribuita la soluzione. A tal fine, è necessario un diagramma di architettura di sistema, che illustra in cui ogni componente della soluzione si trova in relazione ad altri utenti nella distribuzione. La comprensione di tutto questo è fondamentale per poter isolare il problema.

la figura 1 Mostra una soluzione architettura diagramma di Microsoft Dynamics CRM 4.0, che rappresenta tutti i relativi componenti principali e le interdipendenze. Si noti che ogni componente a sua volta potrebbe avere un proprio diagramma di complessità maggiore o uguale. Sistemi di computer sono tutte le informazioni astrazione, il processo mediante il quale un componente di sistema disponibili una serie di funzionalità di tale componente dipendente, un altro possibile affidarsi, nascondere la complessità interna di tale componente. Astrazione è il motivo che è necessario isolare un problema durante la risoluzione dei problemi.

fig01.gif

Figura 1 diagramma di package UML che rappresenta un'architettura di soluzioni

Per esprimere l'architettura della soluzione, ho utilizzato un diagramma di package UML. Frecce puntano la direzione di "dipendenza". Ad esempio, il router di posta elettronica di CRM "dipende" an SMTP server e servizi Web della piattaforma di CRM. Un diagramma completo potrebbe essere molto complesso, ma questo fornisce un modello di base.

Ora è possibile considerare di come i componenti di Microsoft Dynamics CRM vengono distribuiti all'interno dell'organizzazione. Ai fini di questo articolo, verrà utilizzata un'architettura di distribuzione tipica, come illustrato nella Figura 2 . Quando si tratta di isolamento di problemi, è essenziale comprendere come l'architettura del sistema si riferisce l'architettura della soluzione. Senza conoscere in cui componenti sono in esecuzione, è possibile continuare ore tenta di individuare e risolvere un problema che non è in corso anche nel computer che si sta tentando di per correggere!

fig02.gif

Figura 2 architettura di distribuzione tipica

Regole di base

Prima di avviare risoluzione di un problema con Dynamics CRM, è necessario comprendere alcuni principi fondamentali di risoluzione dei problemi. In primo luogo, è opportuno esaminare un flusso di lavoro base di risoluzione dei problemi e alcune linee guida per come è noto quando sicuro continuare con il passaggio successivo.

1. Un problema o errore è individuato e riprodotto.

  • Dispone di leggere il messaggio di errore e sono stati identificati il problema?
  • È il messaggio di errore generico? Se in questo modo, è stata eseguita procedura per individuare l'errore"reale"? Suggerimento: Se l'errore è indicato "qualcosa non è disponibile, contattare l'amministratore del sistema," ricordare che si sono probabilmente tale amministratore di sistema e pertanto è necessario eseguire ulteriori digging per individuare l'errore reale. Prima di passare al passaggio 3, è necessario che si sta utilizzando l'errore effettivo.

2. Il problema deve essere compresa.

  • È stata leggere e comprendere il messaggio di errore è informare?
  • Si dispone di un insieme coerente di passaggi per riprodurre il problema in modo affidabile?

3. Il problema deve essere isolato.

  • Quali sistemi nell'architettura del sistema può è escludere come causa dell'o influire sul problema?
  • I componenti dell'architettura della soluzione possibile è escludere come causa dell'o influenzare il problema?

4. La correzione deve essere identificato e riconosciuto.

  • Si è in grado di trovare articoli di supporto, post di blog o i newsgroup suggeriscono correzioni applicabili al problema esatto?
  • Prima di applicare una correzione, è comprendere perché verrà correggere il problema?

5. La correzione deve essere applicato e verificata.

  • Consente della correzione applicata risolvere il problema? Sarà necessario per poter riprodurre il problema (passaggio 2) per essere certi. Perché è in grado di interpretare la correzione, sono si re-tested altre aree del sistema che potrebbero essere interessati?

Risoluzione dei problemi del server

Con una conoscenza del processo di risoluzione dei problemi, è possibile ora passare agli strumenti necessari per la diagnosi dei problemi in Microsoft CRM.

DevErrors , quando Microsoft Dynamics CRM invia i dati al server, le informazioni sono passate ad ASP.NET e viene elaborate. Gli eventuali errori vengono gestiti da un gestore di eccezioni globali a livello di ASP.NET. Per facilità di utilizzo talvolta ragioni e di protezione, l'errore reale è nascosto dal chiamante (che si o utente), e viene visualizzato un "errore piuttosto". In genere questo errore è simile a "non si dispone di privilegi sufficienti"o il record richiesto non trovato. Purtroppo, questi errori piuttosto si provenire da un "elenco di vuoto". Centinaia di migliaia di errori che possono essere generati da CRM o qualsiasi componente correlato (SQL, SRS, .NET, Windows e così via), errore solo i codici che potrebbe verificarsi il pensiero del team CRM hanno una stringa piuttosto associata. Il resto ottenere gestendo il temuto catchall "si è verificato un errore, contattare l'amministratore del sistema." Questo naturalmente, non è di molto utile per l'utente, l'amministratore del sistema.

Poiché uno dei nostre regole di base è visualizzato l'errore reale, è necessario in grado di indicare quando CRM è che o che almeno non indica la verità intera. Serum la verità consiste nell'attivare DevErrors tramite il file web.config. A tale scopo, modificare il [CRMWEB]\web.config file come segue:

<add key="DevErrors" value="On"/>

Assicurarsi di tenere presente l'architettura del sistema quando questa operazione. Se si dispone di due server configurati in un ambiente a carico bilanciato, sarà possibile isolare il server in cui avviene l'errore o, in alternativa, assicurarsi di attivare DevErrors su entrambi i server. Una volta DevErrors è attivato, verranno visualizzati errori che è simile a quello della Figura 3 .

fig03.gif

Nella figura 3 segnalazione di errori A Microsoft CRM

Nella figura 3 Mostra più elementi a sinistra che forniscono diversi set di dati:

L'errore dettagliato , la prima schermata (impostazione predefinita) viene illustrato l'errore reale di punto di vista del Microsoft Dynamics CRM. Questo include il nome di data, ora e server in cui la si è verificato errore, nonché la descrizione dell'errore, stack di chiamate, numero errore (se disponibile), il file di origine e numero di riga in cui l'errore si è verificata (se disponibile) e l'URL che è stato richiesto, tutti i utile quando si tenta di scoprire la causa dell'errore.

L'errore di ASP.NET , l'elemento successivo è l'errore reale dal punto di vista di ASP.NET. Questo consente di molto le stesse informazioni come l'errore CRM, ma aggiunge le opzioni "Mostra dettagli output del compilatore" e "Mostra origine di complicazione completata".

Informazioni di diagnostica , la terza schermata, illustrata nella Figura 4 , fornisce le informazioni di base relative al server, dove si è verificato l'errore e i dettagli sui client e utente che ha effettuato la richiesta. Queste informazioni includono sistema operativo server, .NET runtime versione, nome del server e il percorso in cui è installato CRM. Informazioni sui database CRM utilizzato e impostazioni nel file web.config specifico sono inclusi. Per il client, nella schermata verrà visualizzata la versione del browser, la risoluzione dello schermo, profondità in bit e altro ancora. Le informazioni sull'utente che effettua la richiesta (almeno da CRM punto di vista) include dell'utente dominio e nome, nome utente CRM, ID utente di CRM, ID di unità di business e ID di organizzazione.

fig04.gif

Nella figura 4 la schermata di informazioni diagnostica

Ciò che l'utente desidera con rilevamento L'elemento finale, illustrato nella Nella figura 5 , consente di visualizzare dal punto di vista dell'utente finale, come se DevErrors sono stati disattivati.

fig05.gif

Nella figura 5 il messaggio di errore l'utente desidera con rilevamento

Si noti che DevErrors consente solo con errori che si verificano durante l'elaborazione di una richiesta di applicazione Web e inviano solo le richieste che coinvolgono l'intera pagina al server. AJAX richiede, ad esempio con una pubblicazione di personalizzazioni, un flusso di lavoro o l'azione di una griglia, non supportano DevErrors. Per questi elementi, sarà necessario utilizzare l'analisi.

SUGGERIMENTO: È Impossibile ridimensionare la finestra per scoprire le informazioni nella pagina DevErrors viene troncate, semplicemente fare doppio clic in un punto qualsiasi sulla pagina e verrà aprire una finestra ridimensionabile.

l'analisi , se un errore CRM si verifica in qualsiasi posizione diversa da una richiesta Web diretta, il modo migliore per ottenere l'errore reale consiste di utilizzare CRM analisi. L'analisi può essere attivato e configurato seguendo la procedura descritta nell'articolo "How to attivare l'analisi in Microsoft Dynamics CRM" in support.microsoft.com/kb/907490. Oppure è possibile utilizzare uno strumento come CrmDiagTool, disponibile all'indirizzo casella. NET/condivisi/6oxfqi2ida.

SUGGERIMENTO: In CRM 4.0 viene ignorata "Directory di traccia".

È possibile con tema horror per il richiedente, in modo che non ottengono sempre l'analisi. Analisi di questo tipo dovrebbero in generale, essere utilizzato solo quando risoluzione dei problemi. Seconda di come si configura l'analisi, può essere presente un impatto significativo delle prestazioni quando è in esecuzione ed se sono presenti la registrazione dettagliata, in un sistema molto utilizzato è possibile creare facilmente centinaia di megabyte di registri per ogni ora. L'articolo menzionato in precedenza fornisce una spiegazione dettagliata di tutti i modi per configurare l'analisi e come attivare l'analisi per client e server.

TIP: Quando la posta elettronica da registri di traccia per la Guida in linea, assicurarsi di comprimerli prima. I file registro solo il testo e in genere comprimere da 90 % o più.

Struttura dei file registro , quando l'analisi è attivata sul server, i registri verranno inseriti nella cartella di analisi, che si trova in cui è installato CRM. Ogni servizio ha un proprio file registro e ogni file per impostazione predefinita fino a 10 MB prima un nuovo file di avvio. Poiché attivamente scrittura i file di log in da diversi processi CRM, non sarà possibile ottenere le informazioni di analisi più recenti assoluto fino a quando il servizio corrispondente (IIS o asincrone Service) viene arrestato. Quando si apre la cartella verranno visualizzati file, ad esempio

-CRMDEV-VPC-CrmAsyncService-bin-20090415-1.log

-CRMDEV-VPC-w3wp-CRMWeb-20090415-1.log

La convenzione di denominazione è [nome computer] – [PROCESS CRM] – [YEAR MONTH DAY] – [SEQUENCE] .log

Il file di registro contiene svariate informazioni, con gli elementi scritti in ordine cronologico. Si noti che il Registro di traccia scrive l'evento più recente nella parte inferiore del file, mentre all'interno di uno stack di chiamate vengono scritti gli elementi in inverso ordine cronologico (più recente articolo prima).

SUGGERIMENTO: Durante la ricerca di errori nel registro, cercare ": errore" (due punti (:) seguito da uno spazio, quindi un errore.

Registro eventi , il Windows Event Log è un'altra posizione per cercare errori che si verificano all'interno di Microsoft Dynamics CRM, i componenti dipendenti o altre aree del sistema. Come il Registro di traccia nel registro eventi forniscono in genere ulteriori dettagli sugli errori che si verificano all'interno del sistema.

Microsoft CRM non registra tutti gli errori nel registro eventi. Un utente disabilitato tentando di accedere viene registrato ad esempio, mentre non viene registrato un tentativo di aggiornare un record che non esiste più. Se questo non è documentato, CRM registra gli errori nel registro eventi da seguenti sottosistemi:

-MSCRMPerfCounters

-MSCRMPlatform

-MSCRMKeyArchiveManager

-MSCRMKeyGenerator

-MSCRMEmail

-MSCRMDeletionService

-MSCRMReporting

-MSCRMWebService

-MSCRMAsyncService

-ASP.NET 2.0

Il bucket di ASP.NET 2.0 agisce come un "catch la maggior parte" per errori di livello applicazione. Inoltre, il servizio router di posta elettronica di Microsoft Dynamics CRM dispone di un proprio registro eventi (MSCRMEmailLog) può essere configurato in modo indipendente per una vasta gamma di informazioni, avvisi ed errori di accesso.

Poiché la registrazione eventi non è necessario attivare, è un buon punto iniziale di ricerca di problemi.

lettura stack di chiamate , gli stack di chiamate sono disponibili in tutte le forme e dimensioni e troppo spesso vengono trascurati da nondeveloper procedure di risoluzione dei problemi. Non è raro che i tecnici di sistema "Ignora il materiale di sviluppatore" e ricerche solo il messaggio di errore o il codice. Consiglio di non eseguire tale operazione, anche se lo stack di chiamate è simile codice, è progettato per essere leggibile e per indicare dove si trova a destra fino all'errore si è verificato. Osservare nell'esempio seguente:

[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)

Qui What you see is un elenco di tutto ciò che il sistema ha (le chiamate) elencate in ordine cronologico inverso (stack) fino all'ultima cosa il "tentativo" si. In questo caso, la prima cosa che si è verificato, la chiamata nella parte inferiore dello stack, una chiamata System.Web.UI.Page.ProcessRequestMain().

Quando si leggono gli stack di chiamate, è importante leggere il nome di ogni chiamata. Per ogni chiamata elencato, le parole tra l'ultimo periodo e la parentesi sono il nome del metodo. Parole prima del nome del metodo sono lo spazio dei nomi e gli elementi tra parentesi, i parametri. In questo caso, il metodo ProcessRequestMain è stato chiamato prima, questo metodo è nello spazio dei nomi System.Web.UI.Page, e questo metodo prevede due parametri Boolean (true/false). Immediatamente, per la lettura lo spazio dei nomi, sappiamo che questa chiamata non è a qualsiasi codice di Microsoft Dynamics CRM, questo viene effettivamente chiamato codice in base .NET Framework (contrassegnato da spazio dei nomi radice System) e in particolare in ASP.NET (contrassegnato dallo spazio dei nomi Web). Leggiamo "up" lo stack è vedere che ProcessRequestMain chiamato quindi PreRenderRecursiveInternal denominato quindi OnPreRender. Il metodo di OnPreRender è il primo metodo, che fa effettivamente parte del codice di Microsoft Dynamics CRM di base, come indicato dallo spazio dei nomi Microsoft.Crm. Mentre si continua nello stack di chiamate, è possibile osservare che CRM rende effettivamente una chiamata al metodo di SQL Reporting Services SetDataSourceCredentials. Questo metodo genera quindi un'eccezione di tipo ReportServerException con l'errore che il server di report non è in esecuzione. Come può vedere, leggendo lo stack di chiamate, è possibile indicare che questo errore non proviene da CRM, ma invece proviene da SQL Server Reporting Services (SSRS) e viene quindi viene "passato" tramite CRM come un CrmReportingException. A seconda dell'architettura di sistema, sarà necessario determinare in cui è in esecuzione SSRS per stabilire dove avviare il servizio per risolvere il problema.

Lettura stack di chiamate in questo modo consente di individuare un errore effettivamente provenienza. La chiamata finale nello stack potrebbe essere simile YourCompany.Crm.Extensions.UpdateRecord(), questo dovrebbe conoscere è che l'errore sembra essere provenienti da un codice scritto per gli sviluppatori o forse una soluzione di ISV che è stato acquistato.

Non è raro che gli errori CRM provengano effettivamente da SQL Server in caso di integrità referenziale (RI) o altri vincoli di livelli SQL, o di .NET Framework.

Riprodurre a casa di esempio

Ora si consentono la possibilità di giocare a casa. Si supponga che si è creato un nuovo utente di CRM e tale utente sta tentando di utilizzare il sistema per la prima volta e ottiene l'errore come illustrato nella Figura 6 .

fig06.gif

Nella figura 6 A CRM errore ricevuto da un utente di runtime prima

Quali operazioni è necessario adottare per risolvere il problema? Per risolvere questo problema, è opportuno attenersi al flusso di lavoro base sulla risoluzione dei problemi.

1. Un problema o errore è individuato e riprodotto.

È necessario chiedere all'utente che cosa si stava cercando quando ha ricevuto l'errore, quindi tentare di riprodurre i passaggi per vedere se è possibile ricreare l'errore.

2. Il problema deve essere compresa.

È opportuno leggere il messaggio di errore dal punto di vista della sezione Risoluzione dei problemi: "utente connesso non dispone di autorizzazioni di protezione appropriati."

Per comprendere il problema, è necessario essere in grado di rispondere alle due domande: che è un "utente connesso"? Quali "autorizzazione di protezione" è "non è" ha?

3. Il problema deve essere isolato.

In questo caso, è possibile rispondere entrambi domande utilizzando l'analisi di CRM. Si sa che l'analisi è necessario perché questa pagina di errore è in una finestra di dialogo e non fornisce le informazioni che sarebbe DevErrors. CRM non registra gli errori di privilegi simile al seguente nel registro eventi. È opportuno attivare l'analisi e riprodurre il problema utilizzando lo stesso utente. Il Registro di traccia fornisce il seguente errore dettagliato:

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: https://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)
…

Questo errore e leggendo i dettagli dello stack di chiamata, è possibile visualizzare che il problema è causato da un errore di privilegi di controllo di CRM. È possibile visualizzare il GUID dell'utente che ha effettuato la richiesta, nonché il GUID del privilegio che ha tentato di utilizzare.

Il privilegio 7863e80f-0ab2-4 d 67-a641-37d9f342c7e3 eseguendo Live Search, l'inizio del primo consiste il SDK di Microsoft CRM.

Dopo questo collegamento, si noterà che il privilegio l'utente necessita è prvWriteAccount, ovvero il privilegio che concede i diritti di aggiornamento utente sull'entità account. Lo stesso metodo funzionerebbe per qualsiasi centinaia di privilegi di fuori della casella, come i GUID sono noti. Se si cerca l'ID di privilegi e non è stato trovato, che il privilegio potrebbe essere tra le entità personalizzate, nel qual caso sarà necessario eseguire una query di SQL Server locale per scoprire quali privilegi richiesto. Lo script seguente consente di ottenere le stesse informazioni:

SELECT PrivilegeId, Name
FROM PrivilegeBase
WHERE PrivilegeId = '7863e80f-0ab2-4d67-a641-37d9f342c7e3'

Ora che si conosce il privilegio è necessario, è sufficiente verificare che l'utente che non è presente il privilegio. Mentre è talvolta possibile ipotizzare che l'utente finale chiamante sia quella, sempre Impossibile che, ad esempio quando vengono eseguite operazioni tramite codice, il plug-in o le estensioni personalizzate. In questi casi, sarà necessario eseguire una query per trovare il nome dell'utente che CRM pensato ha tentato di utilizzare il privilegio. Lo script seguente consente di gestire questo:

SELECT SystemUserId, DomainName
FROM SystemUserBase
WHERE SystemUserId = 'e76c5f50-40b3-dc11-8797-0003ffb8057d'

TIP: Se l'utente GUID è tutti zero (00000000-0000-0000-0000-000000000000), l'utente è probabilmente l'account SYSTEM e ciò significa che l'utente chiamante è stato probabilmente di un account come servizio di rete. Gli account di sistema non si ottengono in genere i ruoli CRM; invece sono stati concessi privilegi elevati tramite il PrivUserGroup in Active Directory.

4. La correzione deve essere identificato e riconosciuto.

È ora possibile accedere in CRM e verificare i ruoli che l'utente dispone, come illustrato nella Nella figura 7 .

fig08.gif

Nella figura 7 ruoli utente in CRM

È possibile quindi eseguire il drill down e vedere che il ruolo Venditore manca effettivamente la scrittura su privilegi dell'account come illustrato nella Figura 8 .

fig09.gif

Figura 8 record principali del ruolo venditore viene illustrato che ’s mancante il privilegio di scrittura in account.

5. La correzione deve essere applicato e verificata.

Per risolvere il problema, è sufficiente concedere il privilegio di scrittura di questo ruolo e salvarlo. È importante assicurarsi di che sapere quali altri utenti potranno. Dopo avere applicato la correzione, è possibile richiedere l'utente può provare nuovamente a verificare che il problema è stato risolto. Quindi disattivare l'analisi e chiamare il caso di chiusura.

Ritorno a capo le

Risoluzione dei problemi di Microsoft Dynamics CRM significa seguendo le regole di base di base e una metodologia che include il reale problema di identificazione, restringere l'ambito, isolare il problema e comprendere la correzione. Troverete i DevErrors, registrazione eventi e gli strumenti di analisi in Microsoft Dynamics CRM essenziale per l'impegno di risoluzione dei problemi.

Aaron Elder (Microsoft Dynamics CRM MVP) funziona per Ascentium, una tecnologia di consulenza e interattivo agenzia di marketing. Visitare il blog di Ascentium all' Ascentium.com/blog/CRM.