Schlagwort-Archive: Tracing

Why OptimizeOrgImport is not always an optimization

Update Rollup 8 introduced an improved organization import process which speeds up the organization import.

You have to enable the optimized import process by adding the DWORD key OptimizeOrgImport with value 1 to the registry hive of Dynamics CRM (see the detailed description

Recently, I had a problem during an import of an organization which failed with following error

Message: Exception during import of organization (Name=’‘, Id=3e58a0cc-c277-df11-b2c1-0050569473db):
System.Data.SqlClient.SqlException: A row with a duplicate key cannot be added to the object ‘dbo.SystemUserOrganizations’-object with unique index ‘SystemUserOrganizations_CrmUserId’

The organization which I tried to import was a backup of an organization which was created in the same deployment. The import runs successful on every other deployment. With help of the Microsoft Support, we identified the cause of the issue: the OptimizeOrgImport key.

The knowledgebase article for OptimizeOrgImport contains following passage:

When you use the registry entry OptimizeOrgImport and have the value of this entry set to 1, you cannot import the same organization database more than one time.
If you want to import the same organization database more than one time, you must do one of the following things:

  • Set OptimizeOrgImport = 0 and use the normal import process.
  • Delete the organization, and then import the organization again.

This passage is a little bit misleading, as the optimized import process fails already at the first time, if the organization was created in the same deployment. In order to import a backup of an organization into the originating deployment, you have to deactivate OptimizeOrgImport.

Common errors on organization import

When you import organizations into an existing environment, there is the possibility that the import could fail. This post should help you to solve the most common issues.

With large organizations, the most likely problem is that the import process runs into a timeout when it updates the user mapping. Update Rollup 8 contains a fix for this problem which has to be enabled manually. See

Another common issue is that the import fails with the following error

ExecuteNonQuery requires an open and available Connection. The connection’s current state is closed.

This error is likely caused by an issue in the .NET 2 Framework. See this article of the EMEA CRM Support team for a description

Another cause of this issue are reports which could not be published to the report server by any reason. For example, reports which are spiced up with custom assemblies cannot be published without the referenced assemblies. The import will fail when it tries to publish such a report. In this case enable the tracing, which generates a trace file for the mmc-console. With help of this file you can identify the report which is making problems. To solve the issue, you can either delete it directly from the database (unsupported) or you delete it prior to the backup of the originating system. After the successful import, you can import the problematic report again.

See this thread in the CRM Deployment forum for further description

CRM log file locations

Every part of a Microsoft Dynamics CRM implementation produces some log output. In addition to the standard logging, you could enable tracing for nearly every CRM component for debugging purposes.

This post shows where you can find these log and trace files. For enabling the generation of trace files see Please keep in mind that although the article says that you can configure the folder in which the trace files are generated via TraceDirectory, the location is hard coded in the applications. You can set a value, but it will be ignored.

Outlook Client

  • Standard log files %APPDATA%\Microsoft\MSCRM\Logs
  • Autoupdate log files %APPDATA%\Microsoft\MSCRM\AutoUpdate
  • Trace files %APPDATA%\Microsoft\MSCRM\Traces

Note: Since Update Rollup 7, these paths are switched to the %LOCALAPPDATA% folder in order to have a smaller roaming profile.

E-Mail Router

Data Migration Manager

  • Trace files %APPDATA%\Microsoft\MSCRM\Traces

CRM Server

  • Trace files {Install dir of application}\Trace
  • Setup log files, Deployment Manager, … %APPDATA%\Microsoft\MSCRM\Logs

Event log
In addition to the log files, there is also useful information in the application event log. With the installation of CRM you get following new event sources

  • MSCRMCallout
  • MSCRMDeletionService
  • MSCRMDeployment
  • MSCRMEmail
  • MSCRMKeyArchiveManager
  • MSCRMKeyGenerator
  • MSCRMKeyService
  • MSCRMLocatorService
  • MSCRMPerfCounters
  • MSCRMPlatform
  • MSCRMReporting
  • MSCRMTracing
  • MSCRMWebService

Added note for Outlook Client log paths for version Rollup 7 or higher

Howto: Debugging CRM errors

Today I had a service call with a customer who got an error on creating appointments. The error message was General Failure in Scheduling Engine

A quick search in the internet revealed that this error message is not an unknown one (at least for Dynamics CRM 3)

Because the description of the articles were not suitable for the customers environment and the CRM system is a newer one ( Dynamics CRM 4), we had to dig further.

We enabled the tracing on the crm application server and set the TraceCategories to *:Error which writes only the message with TraceLevel Error to the trace file.

The generated trace file contained following error
Crm Exception: Message: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: bcf9bb2e-6070-de11-a4a6-000c29abeb6c and PrivilegeId: b5f2ee06-d359-4495-bbda-312aae1c6b1e, ErrorCode: -2147220960
MessageProcessor fail to process message 'Book' for 'appointment'.

A quick search for the name of the denied privilege showed that the security role of the user doesn’t give him the right to share appointments. Apparently, this right is needed for creating an appointment. After adjusting the security role the error was gone and the customer was happy.