Tuesday, January 31, 2012

CRM 2011: Cannot attach a database with same name

We had a situation where we had to move the CRM database to another server. However whenever trying to re-attach the database on the new database server (I believe the same issue would have been experienced for a database restore action), I was presented with the following error message:

This was very odd because there was in fact no other database with the same name on the database server. The error message was clearly wrong. And after I clicked Ok on the above error message, a database was still  created on the server albeit a faulty one that needed to be removed before the attach/restore action could be tried again.

To troubleshoot I tried to attach the database using the command line as follows:

USE [master]
( FILENAME = N'E:\SqlData\XXX_MSCRM.mdf' ),
( FILENAME = N'E:\SqlLogs\XXX_MSCRM.ldf' )
And once I did so the following error message was displayed which revealed the real issue that SQL was having in trying to attach the database:

A little bit of research revealed that the issue had to do with the fact that the original database was installed on SQL Server Enterprise whereas the database I was trying to restore it on was SQL Server Standard. And the following KB article describes what the issue is and how to go about resolving:

In short:

  • Restore the database to another SQL Enterprise environment
  • Run the script in the above KB article
  • Backup the database and restore to a SQL Standard environment

Monday, January 30, 2012

Dynamics CRM 2011 Grid Editor

We have recently upgraded the Sentri CRM Grid Editor to work with CRM 2011. Now you can peruse and update your CRM records using an Excel-like interface. If you know how to use Excel you know how to use the CRM Grid Editor!

This release will work for all modes of CRM deployment including:

  • On Premise
  • Internet Facing Deployment (IFD)
  • Live

In addition, the CRM Grid Editor comes in 2 flavors (UPDATE the Grid Editor full version is now freely available):

  1. Limited Edition - This version is fully functional but can only be used against system entities (i.e. custom entities will not load) and is limited to system views. 
  2. Full Edition - This version does everything the Limited Edition version does but can also be configured to work against custom entities and system views

The Limited Edition license will not expire so if this very functional version meets your needs you can download and use to your hearts content. Alternatively if you're looking to "try before you buy" feel free to download the Limited Edition and when you're ready, request a license and upgrade to the full version.

Setup is very quick involving the following steps:
  • Download the product and use the wizard setup to deploy it to your CRM installation
  • Configure which entities you wish to be available in the Grid Editor
  • Run the Grid Editor client 

Tuesday, January 24, 2012

CRM 2011: Removing ISV Grid/Form Links

In the previous post I addressed how to go about removing the ISV links i.e. those shown in yellow in the screenshot below.

We will now review how to go about removing the ISV Grid/Form links that appear in green in the above screenshot.

Unlike the first scenario, these ISV links are contained within the entity forms definition themselves so to remove you will need to export the entity where you want to remove the link from. If the links are embedded in multiple forms/grids you may want to first create a solution to export all entities (just the entities) in your environment and once you've done so you can edit them all at once.

And once again - as mentioned in the first scenario - the easiest way delete the links such that the ISV tab will no longer appear at all, is to use the default XML snippet as a replacement with what is currently in place.

To do so perform a search on "RibbonDiffXml" which should return you something that looks as follows:

Replace the entire RibbonDiffXml node with the following default  RibbonDiffXml:

                  <CustomActions />
                        <RibbonTemplates Id="Mscrm.Templates"></RibbonTemplates>
                  <CommandDefinitions />
                        <TabDisplayRules />
                        <DisplayRules />
                        <EnableRules />
                  <LocLabels />

Repeat as necessary for each case, save, import and publish. The end result should be a clean looking grid and form view without the extraneous ISV links imported from your 4.0 environment.

Monday, January 23, 2012

CRM 2011: Removing ISV Links

If you upgraded from a 4.0 to CRM 2011 environment you might find a number of ISV links appearing in your form and grid views as shown below.

I am not entirely sure at this moment how the system differentiates between the the ISV tab (highlighted in yellow) and ISV Grid/Form (highlighted in green) in deciding to put links in the 2 distinct areas. Anyway, each of these is addressed in a different way and both should be removed in order to start in a nice and clean upgraded environment without bringing along unnecessary artifacts. We will first go about removing the ISV tab (yellow highlight).

Removing these links are done in pretty much the same way as you would go about removing ISV links in 4.0. That is export the ISV XML configuration which is known in CRM 2011 as the Application Ribbons. Then go ahead and remove the links and re-import the solution and publish. If you want to remove only a select group of links then you'll need to modify the following areas appropriately:

  • CustomActions
  • CommandDefinitions
  • RuleDefinitions

Alternatively, if you just want to revert to the default out of the box situation where there are no ISV links (which you would typically do as part of the upgrade project before installing any new 3rd party ISVs), you can simply replace the exported Application Ribbon with a default Application Ribbon (which you can export from a vanilla installation or use the one below).

Once you publish the customization you should no longer see the ISV tab highlighted in yellow above.

Next: Removing the ISV Grid/Form links.

<ImportExportXml xmlns:xsi="">
  <Templates />
    <CustomActions />
      <RibbonTemplates Id="Mscrm.Templates"></RibbonTemplates>
    <CommandDefinitions />
      <TabDisplayRules />
      <DisplayRules />
      <EnableRules />
    <LocLabels />
  <EntityMaps />
  <EntityRelationships />
  <OrganizationSettings />
  <optionsets />

Tuesday, January 17, 2012

CRM 2011: Cannot Export Solutions

We were experiencing an issue in one of our CRM 2011 upgrade environment where the Export Solution function was not working. We would go through the wizard export process but after clicking on the final export step nothing happened. There is always a little delay between clicking the final Export button and the prompt asking you whether you want to open or save the solution zip file but in this case the prompt never happened. It also did not matter what we attempted to export - creating a solution with just one entity or web resource etc. still did not allow for this function to work so there did not seem to be a way to isolate the issue.

We were seeing an exception in the Event Log as shown below but this did not reveal anything significant. This issue was not caused by plugins since we only had the system plugins in the environment.

Running a trace using the diagnostics tool while reproducing the issue similarly did not produce anything  particularly useful.

So we turned to Microsoft Support to help us with troubleshooting this issue. After a lot of back and forth and having them escalate the issue to their dev team, the issue was finally nailed down to something quite simple. There were some attribute maps on the contact to opportunity mapping (1:N) that seemed to be causing the problem. In our case, the following 2 were identified:

Therefore the resolution was to follow the steps outlined below

  1. Go into Settings -> Customizations -> Customize the System
  2. Under entities, select the Contact entity
  3. Go into 1:N relationships
  4. Open the Contact to Contributions relationship for type of Parental relationship
  5. Open mappings
  6. Delete the 2 accountiddsc and accountidname mappings
  7. Save and close
  8. Publish all customizations

I am not sure how these errant mappings came into being in the first place. They were present in the original CRM 4.0 environment and came along with the upgrade. But the export issue only affected the CRM 2011 environment. I would suspect that whatever introduced this issue it is probably not limited to just the contact to opportunity mapping. Therefore if you are encountering this error and you do not find a similar mapping issue in the contact to opportunity that you look for other entity mapping containing the "*iddsc" field mappings - that will be the smoking gun...

Thursday, January 12, 2012

CRM 2011: Distribute Workflow

A few months ago I extolled the virtues of the distribute workflow in CRM 4.0 and wondered when it might become available for CRM 2011. Well the good news is that I recently discovered that this has now become available for CRM 2011 and can be downloaded from codeplex.

To install into your environment, all you need to do is to import the managed solution from the codeplex downloads page into your environment and once you have done so it will start showing up in the Add Step menu of the Workflow and Dialog process editor.

The codeplex site also contains pretty good documentation for configuring this option. It walks through a use case scenario for setting all cases for a particular customer to high.

There are many other scenarios where this workflow plugin can come in handy. Previously you might have gone about solving a requirement such as that presented by the use case by developing a custom plugin solution. With the distribute workflow it can be done via configuration and it is flexible in that you can specify under which specific conditions you want it to run by employing the use of some simple check conditions in the body of the workflow.

I'll provide another use case example that can further sharpen this point. Let's say you wish to close all open Campaign Responses automatically once the parent Campaign is completed. The distribute workflow can easily be used to accomplish this via simple configuration.

First design a simple manual workflow against the Campaign Response that:
  1. Evaluates whether the Campaign Response is open
  2. Changes the status of the Campaign Response to Closed

Then design another simple workflow against the parent Campaign that is triggered when the status is changed that does the following:

  1. Evaulates whether the Status Reason has changed to Completed
  2. Executes the Distribute Workflow which will call the workflow above for each child Campaign Response

And that is all there is to do.

Wednesday, January 11, 2012

CRM 2011 Document Management Settings: Select Entities

Having reviewed the pros and cons of both the Account-centric and Individual Path approach we can now attempt to start drawing some conclusions.

In short, I'd venture to say that the Individual Path approach is considered to be the overall better approach as it’s less prone to “disorganization”. Which to me is the most important factor when it comes to organizing content in SharePoint. There might be exceptions to this on a case by case basis, as it will depend – as has been hopefully illustrated – on the nature of the entity for which the documentation is being stored.

Now that we've chosen the Individual Path, the question then becomes - at which entity levels should documentation be stored? That is, as has been illustrated, you can specify to have the "Documents" tab show up on virtually any CRM entity. So you could check off accounts, contacts, opportunities, orders, quotes etc. such that any documentation pertaining to the account will be stored at that level, and any documentation pertaining to the contact will be stored at that level, and any documentation pertaining to opportunities will be stored at that level, and so on and so forth.

The issue that now becomes apparent is that of "user discretion". Let's use a "Statement of Work" (SOW) document as example. User A might consider this to be opportunity related and therefore may decide to go into the opportunity to store this document. On ther other hand User B might consider this to be more of a company document and therefore may decide to store this against the parent account. User C might be just too lazy to navigate all the way down to the opportunity and may also store it against the account for no particular considered reasoning.

Then there is the reverse scenario where User D wants to go and review the document that was stored. And discovers after searching around a bit that it is stored in a different location than a previous SOW.

An SOW is obviously just one example of this issue - but hopefully illustrates that the issue with selecting too many entities for associating documentation is that it can lead to additional disorganization and lack of consistency/standards as far as content management is concerned. The more levels selected the more of an issue this is likely to be.

Both the storage and retrieval of documentation must be as intuitive and easy as possible. In short, users should know - without having too think about it too much - where to go and store a document or conversely where to go to find a particular document.

Therefore one of the conclusions to draw here is as follows:

Do not choose "select all" for the Select Entities settings. Give it careful consideration and make sure that the entities selected are distinct enough such that it keeps it simple and logical in terms of document storage and retrieval. If you do not do so, you are less likely to benefit from the CRM/SharePoint integration due to the fact that your documentation will become less organized and harder to find. The end result being that it will decrease the chances of having this feature successfully adopted within your organization.

SharePoint itself of course has a ton of features and functions designed to better organize content. Until now, we really have focused on the CRM side of the CRM/SharePoint integration equation. However I think that the most successful implementation of this integration incorporates taking advantage of some of the key SharePoint capabilities. We'll review this next.

Next: CRM 2011 Document Management Settings: SharePoint Best Practice

Tuesday, January 10, 2012

CRM 2011 Document Management Settings: Not Based on Entity

It's been quite a while but previously we were reviewing the pros/cons with the various document management settings in CRM 2011. In the referenced post, we reviewed the pros/cons of checking off the "Based on entity" option when setting up the Document Management setting. This time we will review the pros/cons of leaving this option unchecked.

In the original introduction to this topic we termed this option (i.e. leaving "Based on entity" unchecked) as the "Individual Path". This is because when I store documentation using this setting, the path to the stored document will go straight from the root location to the sub-location corresponding to the name of the entity it is stored under (account, contact, opportunity etc.). As opposed to the Account Path which is relative to the parent entity in which the document is being stored and therefore for child entities will involve an additional level of navigation.

The main benefit of this approach is that it is quite simple. To find or store contact documentation, you just need to navigate to the corresponding contact in SharePoint. And also... it avoids the downsides that were mentioned in the Account Path approach.

The main downside to this Individual Path approach is that there is no connection between this and the parent account from a SharePoint navigation perspective (i.e. when navigating from the SharePoint user interface). Other downsides include:

  • If the sub-contact moves to another account, then some manual steps would need to be taken to prevent the co-mingling of content from the former and current account.

  • The “oops factor” is also present but to a lesser extent than in the account centric approach. For example, if a contact, opportunity etc. is renamed the SharePoint location name will no longer correlate exactly with the corresponding CRM entity it is linked to (unless manually fixed).

It should be mentioned that both of the above downsides also are present for the Account Path approach. These should be addressed either via business process or by implementing business logic to prevent these issues from occurring. For example, you could use jscript to prevent the entity name from being updated in order to prevent the second scenario from occurring.

In the next post, we'll wrap up this topic by trying to pull it all together and arriving at some implementation recommendations.

Next: CRM 2011 Document Management Settings: Select Entities