The CRM 2013 Quick Start is a first look at Microsoft Dynamics CRM 2013 and all the new features that have been included. In the CRM 2013 Quick Start you will find details that can help … Get the book
After performing the basic installation of MS CRM, you will have a system that contains the default entities with all their fields, forms and so on. The next step will be to modify the entity customizations to suit the business needs of the organization. Typically there will be a development and/or test environment where the customizations are first performed, before being imported into the production server. This should be an easy operation through the Import Customizations menu, but sometimes you may end up with a nasty error like this:
“This attribute map is invalid. The selected attributes should be of the same type. The length of the target attribute should be equal to or greater than the length of the source attribute and the formats should match. The target attribute should not be used in another mapping.”
This can happen when the source customization has some default attributes mapped in a different way than what they are by default. As pointed out by Will Willson in this blog post, CRM only adds new mappings between entity attributes during the import. It will not delete any existing mappings, so you may end with the source entity having two mappings pointing to the same field in the target attribute.
If you have a hunch on what entity and which attribute might be causing the problem, the quick solution is to go and remove the existing mapping prior to importing the new customizations. If you’ve got no idea on where the conflict is, you can try enabling CRM Platform Trace, reproducing the error, then opening the resulting trace file that begins with “w3wp-MSCRMServices” and searching for the tag “FAILURE”.
(This issue is described in the confidential Microsoft KB article 921977, available through Customer Source.)
One of the integrations implemented for our CRM environment includes a feature that writes entries to a dedicated Error Log entity. This can be a convenient way to provide the end users access to error notifications, when the process itself is asynchronous and does not provide a way to prompt the user.
During the development project of this integration, frequent updates were made to this callout dll file and I received new versions to be deployed from the developers almost on a daily basis. After one particular update, we were surprised to notice that the callout was still writing an error messge into the custom entity, which was not supposed to be there. In fact, the whole message string no longer existed in the dll file. Where did his ghost messages appear from?
It turned out that merely stopping and starting IIS does not guarantee that the previous version of a callout would not remain in the cache. If there are any workflows associated with the entities that the callout references, these can keep the old version of the dll loaded up in memory, thus creating the “haunting” effect described.
As a lesson learned, whenever I need to update a callout dll file, I now go through the following steps:
- Stop the CRM Workflow Service (net stop mscrmworkflowservice)
- Stop IIS (iisreset /stop)
- Replace the callout dll
- Start IIS (iisreset /start)
- Start the CRM Workflow Service (net start mscrmworkflowservice)
As promised in my earlier post, here are some notes I wrote down during Convergence 2008 EMEA. In my opinion, the best session was “Enterprise Scalability and Performance with Microsoft Dynamics CRM 4.0” held by Amir Jafri. Not so much because of the original agenda and slides, but mostly thanks to all the questions and comments from the audience. Here goes:
- SQL Server is where performance tuning gives the most “bang for the buck”
- Creating custom indexes is supported and encouraged
- Custom search attributes for entity Quick Find view do not automatically get indexes
- Database index should be moved to a different disk system
- Old customization versions are stored in the database
- Performing many customization changes will slow the system down over time
- Data is not and cannot be utilized in the UI, so what’s the purpose?
- There are workarounds for cleaning the old data
- Performance comparison of out-of-the-box setups between v3.0 and v4.0 on identical hardware show 50% reduction in CPU utilization and disk queue length
- SQL Server 2008 will provide performance improvements for CRM out of the box
- Disabling authentication from static content has been done in v4.0, heavily recommended for also v3.0
- 401 error page size has been reduced, should be done manually for v3.0
- v4.0 uses content compression to reduce the amount of data transferred
- Compression can create an overhead on the client when rendering content
- Image Strips(?) are used in v4.0 to reduce round trips
- CRM default home page (my activities) round trips have been reduced by 50% between v3.0 and v4.0
- Common client for Windows Workflow Foundation is being developed
- May ship with CRM v.Next
- Workflows are still a heavy operation even in v4.0
- Workflow performance measurement is almost impossible, due to the unlimited number of variations how workflows can be built
- Workflow queue database table is not automatically purged of old data or indexed, should be done manually
- Table size can grow to become so big that maintenance cannot be run, hotfix is available
Performance general notes
- Tests done using Cisco WAAS application accelerator in WAN environment have proved to improve performance by up to 50%
- Official toolkits for measuring the performance of an existing CRM implementation do not exist
- Performance measurement toolkit can be used only with test data, prior to live environment deployment
- New MOM (a.k.a. Systems Center) pack for CRM v4.0 will include CRM specific performance analysis tools
- Outlook client improvements in v4.0:
- Reduced memory footprint, but still quite resource intensive, also due to new requirements from Vista and Office 2007
- CRM client start-up should no longer slow down the email data transfer upon Outlook start-up, client loads in the background