Troubleshooting Microsoft Dynamics CRM

[アーティクル]
08/25/2016

Microsoft Dynamics

Microsoft Dynamics CRM のトラブルシューティング

Aaron Elder

概要。

ソリューションアーキテクチャを示す
基本的なトラブルシューティングの原則
サーバーの問題を診断するためのツール
CRM のエラーを解決する手順

内容

スタック
地上の規則
サーバーに関する問題のトラブルシューティング
再生では、ホームの例
まとめ

Microsoft DynamicsCRM で 2 つ目のアーティクルを戻すが ’m (最初、記事を参照して" Microsoft Dynamics CRM 4. 0 を展開します。")、いますに関する情熱的なもので、フォーカスを持つ-は、トラブルシューティングします。 Microsoft CRM のトラブルシューティングでは、トラブルシューティング他 N 層の Web アプリケーションを Microsoft スタック上に構築はるか異なりますされません。ここではない方法のガイドまたは「101 のヒントと秘訣:」のコレクション代わりに、Dynamics CRM コンポーネントと分離する、理解、および問題を解決するためのツールの基礎はについて説明します。、この資料の、サーバー側側面を Microsoft Dynamics CRM の問題のトラブルシューティングにのみフォーカス設定がされます。

スタック

すべて複雑なシステムには、人間の本文または n 層 Web アプリケーションは多くの複雑なサブシステム同等と外部システムを活用する、「システムのスタック」を理解する必要は。スタックは基本的に、すべてのコンポーネント、そのシステムおよびビルドし、相互にレイヤーが方法を理解するためのシステムの青写真です。スタックが呼び出すことも、ソリューションのアーキテクチャダイアグラムとして、ソリューションのコンポーネントを示しています-この場合 Microsoft Dynamics CRM。ソリューションを理解するともするソリューションが展開されて方法を理解します。これには、については、システム用のアーキテクチャダイアグラム、展開で、他に関連ソリューションの各コンポーネントに配置される場所を示します必要があります。についてのすべては、問題を特定することが重要です。

図 1 は 4.、ソリューションのアーキテクチャダイアグラムの Microsoft Dynamics CRM 0、すべての主要なコンポーネントとその依存関係を表すを示しています。メモが以上の複雑さの独自の図は、各コンポーネントこと順番ができます。抽象化に関するすべてのコンピューターシステムは、プロセスをシステムコンポーネント利用一連の機能別、依存コンポーネントできます依存、そのコンポーネントの内部複雑さを非表示します。抽象化のためにトラブルシューティングを行うには、問題を特定する必要があるです。

[UML パッケージ図は、ソリューションのアーキテクチャを表す 1 の図します。

ソリューションアーキテクチャを表す、UML パッケージ図を使用するしました。ポイント「依存:」の方向の矢印たとえば、CRM 電子メールルーター「異なります」、SMTP サーバーと、CRM プラットフォームの Web サービス。完全な図は、非常に複雑ながこれは基本的なモデルを提供します。

今すぐ、エンタープライズ内での Microsoft Dynamics CRM コンポーネントの展開方法考慮することができます。この資料のためには、使用、一般的な展開アーキテクチャ 図 2 に示すようにします。ソリューションアーキテクチャに、システムアーキテクチャの関連方法を理解が問題を特定する際不可欠です。コンポーネントが実行されている知らせずを見つけて修正しようとしているコンピューター上でも起こっていないという問題を修正しようとする時間を費やすでした!

図 2 の 、標準的な展開アーキテクチャ

地上の規則

Dynamics CRM で問題のトラブルシューティングを開始する前に、いくつかの基本的なトラブルシューティングの原則を理解する必要があります。まず、トラブルシューティングの基本的なワークフローとするどの安全に、次の手順に進みますなったときのガイドラインについて説明について説明します。

1。問題またはエラーが識別され、再現します。

問題を特定したし、エラーメッセージする既でしょうか。
エラーメッセージがジェネリックか。場合、「実際のエラー」を検索する手順を実行がのでしょうか。ヒント: エラーという場合は、おそらくそのシステム管理者したがってならない複数掘りの実際のエラーを検索することを保存する「システム、管理者に問い合わせて要素が発生しました」です。手順 3 に移動すると、前に、実際のエラーを扱うを必ず必要があります。

2。問題が理解される必要です。

参照し、というは、エラーメッセージを把握しますか。
一貫性のある一連の問題を確実に再現する手順がありますですか?

3。問題の分離なければなりません。

どのシステム、システムのアーキテクチャでするの原因として除外したり、問題の影響を与えるでしょうか。
ソリューションアーキテクチャのコンポーネントの原因として除外したり問題の影響を与えるでしょうか。

4。修正プログラムを適用し必要があります識別を理解します。

サポート記事、ブログ、または正確な問題に適用される修正プログラムを提案するニュースグループの投稿を検索したいよろしいですか。
理解、修正プログラムを適用する前にして問題を解決は、なぜですか。

5. 修正プログラムを適用し必要があります適用を確認します。

適用されている修正プログラムが問題を解決しますか。必ずのために (手順 2) の問題を再現できるようにする必要があります。修正プログラムを理解するため受ける可能性のあるのシステムの他の領域を re-tested いるのでしょうか。

サーバーに関する問題のトラブルシューティング

トラブルシューティングプロセスの理解を今すぐ上移動できますには、Microsoft CRM 内での問題を診断するためのツール。

DevErrors -と Microsoft Dynamics CRM がサーバーにデータを送信、情報は ASP.NET に渡され、処理します。すべてのエラーは層の ASP.NET には、グローバル例外ハンドラーによって処理されます。使いやすさともセキュリティ上の理由は、(または、ユーザーの) を呼び出し元から、実際のエラーは非表示され、おもしろくエラー"が代わりに表示されます。このエラーを示す「ための十分な特権がありません」または「、要求されたレコードが見つかりませんでした:」よう通常これら本当のエラー残念ながら、「ホワイトリスト」と元します。数千の CRM によってスローされる可能性のあるエラーまたは関連コンポーネント (SQL、SRS、.NET、ウィンドウ、およびなど)、エラーだけの数百の CRM チーム配慮が行われるコードに関連付けられたすばらしい文字列を持ってください。残りの部分を取得によって処理、恐怖の catchall「エラーが発生しました、管理者に問い合わせてくださいシステム:」、もちろん、は、システム管理者に立ちません。

我々の基本原則の 1 つ、実際のエラーです、ため CRM がばらまいてまたは少なくともいない知らせる全体、真実を通知できるようにする必要があります。実を言うと、serum は、web.config を通じて DevErrors を有効にします。変更することによってこれは、[ように CRMWEB]\web.config ファイル。

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

必ず、システムのアーキテクチャとき点に留意こうしてください。負荷分散環境で構成されている 2 つのサーバーを持っている場合、エラーはどこサーバーを分離または、または、両方のサーバーで DevErrors を有効に必ずをします。 DevErrors を有効にすると、エラー次の 図 3 のようなものが表示されます。

図 3 、Microsoft CRM のエラー報告

図 3 さまざまな情報を提供する左側には、いくつかの項目を示します。

詳細なエラー -(既定値) を使用して、最初の画面には、Microsoft Dynamics CRM の視点から実際のエラーです。ここでは、日付、時刻、およびサーバーの名前が、エラーの説明、呼び出し履歴、エラー番号 (使用可能な場合)、ソースファイルと行番号が、エラーが発生 (利用可能な場合)、および要求された URL と同様、エラーが発生-すべて原因を解明しようとしたときに便利です。

ASP.NET エラー -次アイテムは ASP.NET の観点から、実際のエラーです。ずっと、CRM エラーとして同じ情報を提供が「コンパイラの出力を表示する詳細な」を「表示完了複雑ソース:」のオプションの追加この

診断情報 ( 図 4 、3 番目、画面で、エラーが発生したサーバーについての基本の情報およびクライアントおよび要求を作成したユーザーの詳細についてを提供します。この情報には、サーバーオペレーティングシステム、.NET ランタイムのバージョン、サーバー名と CRM がインストールされているへのパスが含まれます。特定の CRM データベースの使用と、web.config の設定については含まれているです。クライアントの画面、ブラウザーのバージョン、画面の解像度、ビット深度、および表示されます。については、要求を行ったユーザー (少なくともから CRM の点の表示) は、ユーザーのドメインと名前と CRM ユーザー名、CRM ユーザー ID、事業単位の ID、および組織 ID です。

図 4 、診断情報] 画面

どのようなユーザー実行が Seen ようになど、最終的なアイテム図 5 、DevErrors がオフの場合、により、エンドユーザーの視点からを表示できます。

図 5 のエラーメッセージ、ユーザーが Seen ください。

DevErrors により、Web アプリケーションの要求の処理中に発生するエラーでだけをページ全体を含む要求のみ送信サーバーに注意してください。 AJAX を要求するなどのカスタマイズ、発行すると、ワークフロー、または、グリッドの操作をサポートしていません DevErrors。そのような場合は、トレースを使用する必要があります。

ヒント: DevErrors ページの情報が省略されると、ウィンドウを広くサイズを変更することはできません、ページ上には、任意の場所をダブルクリックだけされ、サイズ変更可能なウィンドウが開きます。

トレースのかどうか、CRM エラー発生、実際のエラーを取得する最適な方法は CRM トレースを使用するには、直接、Web 要求からよりもの任意の場所。トレースが有効にでき、support.microsoft.com/kb/907490 で、Microsoft Dynamics CRM でトレースを有効にする方法」の資料の手順で構成できます。または、CrmDiagTool、ボックスに利用できるなどのツールを使用できます。ネット/共有/6oxfqi2ida。

ヒント: CRM 4. 0 では、トレースディレクトリは無視されます。

トレースは不満が得られないため、初心者の怖いできます。一般に、問題をトラブルシューティングする場合にのみなるトレースを使用する必要があります。トレースを構成する方法に応じてが重大なパフォーマンスに影響は、実行時にでき、使用頻度の高いシステムで詳細ログ場合、できます数百 MB の 1 時間あたりのログの作成簡単に。上記紹介はトレースおよびトレースクライアントとサーバーを有効にする方法を構成するすべての方法の詳細な説明します。

ヒント: 電子メールのヘルプについては、トレースログ出力を場合は、まず圧縮してください。ログファイルは単なるテキストと、通常 90% 以上圧縮します。

ログファイルの構造 (ログをある、トレースのフォルダーに置かれるサーバー上でトレースが有効なとき CRM をインストールします。各サービスは、独自のログファイルを持ち各ファイルは既定では拡大 10 MB に新しいファイルが開始する前に、。ログファイルが、さまざまな CRM プロセスによってを積極的に書き込まれる、ためするは受け取りません、絶対の最新のトレース情報、対応するサービス (IIS または非同期サービス) が停止するまで。フォルダーを開くとファイルがわかりますなど

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

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

名前付け規則が [コンピューター名]-[CRM の PROCESS] – [YEAR MONTH 日]-[シーケンス].LOG

ログファイルが順で記述された項目の負荷、情報の含まれています。トレースログ、ファイルの末尾に最新のイベントを書き込むことを確認、コールスタック内のアイテムが書き込み中に [順序順 (最新最初の項目)。

ヒント: ログでエラーを探すときに、検索してください]: エラー"(スペースを 1 つからエラーがコロン後に続きます。

イベントログなど、Windows イベントログは別の場所を Microsoft Dynamics CRM、その依存コンポーネント、または、システムの他の領域内で発生したエラーを探します。同様に、トレースログ、イベントログは、システム内で発生したエラーの詳細を提供して通常します。

Microsoft CRM は、すべてのエラーイベントログに記録しません。たとえば、無効なユーザーでログオンしようとしましたが存在しないレコードを更新する試みがログインしていない間を記録します。このいない記述されています、イベントログにエラーが、次のサブシステムからログオン CRM:

-MSCRMPerfCounters

-MSCRMPlatform

-MSCRMKeyArchiveManager

-MSCRMKeyGenerator

-MSCRMEmail

-MSCRMDeletionService

-MSCRMReporting

-MSCRMWebService

-MSCRMAsyncService

-ASP.NET 2. 0

ASP.NET 2. 0 バケットは、"catch ほとんど"のアプリケーション層のエラーを果たします。さらに、Microsoft Dynamics CRM 電子メールルーターサービスは、さまざまな情報、警告、およびエラーのログを個別に構成できる独自イベントログ (MSCRMEmailLog) がします。

イベントログがオンになっている必要はありません、ので問題を検索する適切な開始場所が。

[呼び出し履歴を読み取り -コールスタックすべての形やサイズおよび nondeveloper のトラブルシューティングでは見過ごされるあまりすべて。開発者、内容を無視する"して、エラーメッセージやコードのみを調査だけでシステムエンジニアのことも珍しくはありません。ないこれを行うお勧めします) 場合でも、コールスタックの状態にコードのようになったら、それはように設計されています人間読み発生したエラーまで右どうしたを確認します。次の使用例を見てください。

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

表示内容ここでは、システムがすべての事項の一覧 (呼び出し) 逆引き時系列順 (スタック)、最後まで「試み」を行うに一覧表示します。この場合は、まず発生したことなど、呼び出しスタックの末尾に-System.Web.UI.Page.ProcessRequestMain() への呼び出しがします。

コールスタックを読み取り、お勧め呼び出しごとの名前を読み込めません。表示されている各呼び出し、最後の期間と、かっこの間での単語はメソッド名です。メソッド名の前に単語は、名前空間、および、パラメーター、かっこ内のアイテムです。メソッド ProcessRequestMain が呼び出された最初する、このメソッドは System.Web.UI.Page 名前空間、2 つのブール値 (True または False) パラメーターを受け取るこのメソッドをここでは、します。すぐ、読み取りでこの呼び出しが Microsoft Dynamics CRM のコードからでいないある、名前空間おこと、実際に (システムルート名前空間によって表示されています)、基本の .NET Framework と具体的にはコードの呼び出しこれは ASP.NET (Web の名前空間で示しています) にします。 "up"、スタック読んだと ProcessRequestMain が [し OnPreRender と呼ばれ、PreRenderRecursiveInternal を呼び出すことがわかります。 OnPreRender メソッドは、最初のメソッド Microsoft.Crm 名前空間で示されるように、実際に、Microsoft Dynamics CRM のコードベースに含まれる。呼び出し履歴をいくよう CRM SQL レポートサービスメソッド SetDataSourceCredentials に呼び出しを実際にによりことがわかります。このメソッドはエラーをレポートサーバーが実行されていない型 ReportServerException の例外をスローします。ように、呼び出し履歴を読み取ることによってこのエラーがない由来 CRM まったくは、代わりに SQL Server レポートサービス (SSRS) から送られてくるはしされている「バブルを」を CrmReportingException として CRM を通じて指示できます。システムアーキテクチャに基づきは SSRS がどこから問題を解決するサービスを開始を移動するために実行されている場所を確認します。

この方法で呼び出し履歴を閲覧できます isolate エラーが実際に由来の場所。スタック内の最終呼び出しが YourCompany.Crm.Extensions.UpdateRecord() のようなものするか、開発者が記述されたコードに由来するのにはエラーが表示されるまたは購入した ISV ソリューションおそらくこれはかわかります。

実際には、参照整合性 (RI) の場合、SQL Server やその他 SQL レベル制約、または、.NET Framework 自体から送られている CRM エラーのことも珍しくはありません。

再生では、ホームの例

今すぐ自宅で再生する機会を提供してみましょう。仮定 CRM で、新しいユーザーを作成した、そのユーザーが最初に、システムを使用しようが 図 6 に示すように、エラーを取得します。

図 6 時にユーザーを受信した、CRM のエラー

この問題を解決をどのような操作を実行してはでしょうか。問題を解決するこのには以下みましょうに従って、基本的なトラブルシューティングワークフロー。

1。問題またはエラーが識別され、再現します。

彼がしよう、エラーを受信した彼は、ユーザーに確認し、かどうかは、エラーで再作成することができますが表示する手順を再現しよう必要があります。

2。問題が理解される必要です。

みましょう、トラブルシューティングの観点から、エラーメッセージの読み取り:「、ログオンしたユーザーがありません、適切なセキュリティアクセス許可」。

問題を理解するのには 2 つの質問に回答することできません:「、ログオン - ユーザー」がユーザーでしょうか。どのような「セキュリティ権限」彼「がありません」がでしょうか。

3。問題の分離なければなりません。

ここでは、CRM のトレースを使用して両方質問に答えることができます。このエラーページがダイアログボックスを DevErrors ことは、情報を提供しませんのでトレースは必要することがわかります。 CRM は、このような特権のエラーイベントログに記録しません。トレースを有効にするし、同じユーザーを使用して、問題を再現しましょう。トレースログは、次の詳細なエラーを示します。

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

このエラーから、呼び出しスタック詳細を参照して、問題が、CRM 確認特権障害に起因することを確認できます。使用しようとして彼の特権の GUID と同様に、要求を行ったユーザーの GUID を確認できます。

特権 7863e80f-0ab2-4 d 67-a641-37d9f342c7e3 で、Live 検索を実行する場合、最初のヒットは、Microsoft CRM SDK です。

このリンクでは、次は、特権ユーザーニーズがある prvWriteAccount、アカウントエンティティに、ユーザーの更新権限を付与する特権が確認できます。 GUID はすべて既知として同じメソッドの数百、既定の特権のいずれかの動作します。特権 ID を検索する、見つからなかったが、ユーザー定義エンティティの 1 つに、特権可能性があるクエリをローカルの SQL Server をどのような特権を調べる必要がありますがケースではされる要求されます。次のスクリプトは同じ情報を生成します。

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

これでどのような特権が必要ですねどのユーザーには、特権がありませんを確認するだけ。仮定できます、呼び出し元のエンドユーザーが、か、中にするを確認して、コード、プラグイン、またはカスタム拡張機能を使用してアクションが実行されるときのような必ずことはできません。このような場合は、CRM が、特権を使用しようと考えるユーザーの名前を検索するクエリを実行することがあります。次のスクリプトは、これを処理します。

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

ヒント: ユーザー GUID がすべてゼロ (00000000-0000-0000-0000-000000000000) 場合、ユーザーがいる可能性があります、SYSTEM アカウントであり、つまり、呼び出し元のユーザーがネットワークサービスのようなアカウントで可能性があります。システムアカウント CRM ロールは、通常に得られない; 許可が代わりに、Active Directory 内で PrivUserGroup を使用して権限を昇格します。

4。修正プログラムを適用し必要があります識別を理解します。

今すぐ CRM とチェックは、ユーザーが、どのような役割を表示するに移動できますように、図 7 .

図 7 の CRM でのユーザーの役割

[ドリルダウンしたりように、販売員の役割がアカウント特権の付与をありません実際を参照してください。図 8 .

図 8 に 、販売員の役割のコアレコードの書き込み特権アカウント: [不足しているを表示します。

5. 修正プログラムを適用し必要があります適用を確認します。

問題を解決するには、だけでこのロールに書き込み特権を与えるを保存する必要があります。これに影響する他のユーザーを理解することを確認注意してください。修正プログラムを適用すると、ユーザーの問題は解決されましたを確認する再試行を要求できます。トレースを無効にし、閉じた場合を呼び出して必要があります。、

まとめ

次の基本的な基本原則と実際の問題を識別する、スコープを縮小する、問題を特定および修正プログラムを理解を含むの手法を意味 Microsoft Dynamics CRM をトラブルシューティングします。わかります DevErrors、イベントログ、およびトレースツール Microsoft Dynamics CRM で、トラブルシューティング作業で重要です。

Aaron Elder (Microsoft Dynamics CRM MVP) は Ascentium、技術コンサルティングおよび対話型のマーケティングエージェンシーに対して機能します。 Ascentium ブログにアクセスしてください。 ascentium.com/blog/crm.

その他のリソース