One important thing that is often forgotten during/after the installation of Dynamics CRM is to properly set the SPNs for your service accounts (if necessary 😉 ).
Here are three links which I often take as reference when we plan new deployments:
If you have ever tried to enter a duration of more than 10 days for a service activity you would have seen that the system won’t accept this value.
The duration of the appointment is invalid
If you need to change the maximum value you are able to do this directly in the database (which is officially supported – quote of a support ticket below).
- There is no way to modify the limit for service duration via UI. We will read this value from a SQL table and there we can change the default setting.
Default value: 10
- If you overwrite this value with the needed one (for example 20) and after that perform an IISReset, the known error message („The duration of the appointment is invalid“) will no longer occur.
This change is the recommended solution from Microsoft CRM Support and will be supported.
- Background: This field does come originally from CRM 3.0, where customer already provided feedback that the maximum duration of 10 days does not meet their need. The solution for CRM 3.0 was a solution implementation via registry key: Navigate to the following registry hive: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM. Create a registry key of type DWORD and name it „SchedulingEngine.MaxAppointmentDurationDays“. Provide a reasonable digit greater than 10 representing the number of days the service activity would be kept open and insure that the value is set to Decimal and not Hexadecimal. Now you can schedule an appointment with a duration value of more than 10 days.
- For CRM 4.0 you will need a manual change of the according OrganisationBase entry. Exception: If you upgrade your CRM installation from CRM 3.0 to CRM4.0, the value will be automatically carried over
Another possibility to adjust this setting is to change the organization.maxappointmentdurationdays Property via the sdk.
This week I’ve installed the E-Mail-Router for a customer. During the setup an error came up
Action Microsoft.Crm.Setup.Exchange.GenerateEncryptionKeyAction failed.
Method not found: ‚Boolean Microsoft.Crm.ApplicationConfig.IsFederalInformationProcessingCompliant()‘.
The cause of this error was a pending restart which was requested by Windows Update. I have no clue if a specific update was the cause of the problem, or the system state itself.
However, after rebooting the machine, the error went away and the setup was successful.
So keep in mind, if the pre-checks warns you about a pending reboot, it is sometimes better not to ignore this hint 😉
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 http://support.microsoft.com/kb/977867)
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.