Cannot configure CRM for Outlook: Fix uninstall the Plug-In Profiler

We've been struggling with CRM for Outlook issues for weeks. Our problem seemed to appear with all of our users who have Outlook 2010. Suddenly, each of them experienced errors with CRM for Outlook that crashed Outlook, and forced them to disable the add-on. Then, we noticed that we weren't able to configure new instances of CRM for Outlook.

For any new attempt at configuring CRM for Outlook, we were met with two error messages. I'll insert the full downloaded text of the error at the end of this post, but the general messages were typical troubleshooting errors:

“There is a problem communicating with the Microsoft Dynamics CRM server. The server might be unavailable. Try again later. If the problem persists, contact your system administrator.”

“Cannot configure the organization for Microsoft Dynamics CRM for Outlook. Try to configure the organization again. If the problem persists, contact your system administrator.”

The problem was that the solutions I was able to find did nothing to fix the configuration errors, even though PowerObjects has provided a great troubleshooting list here, and Microsoft has their own CRM for Outlook Configuration Troubleshooting Wizard. It wasn't until I started searching other parts of the detailed error message that I was able to come across something that was useful to answering my problem. Specifically, I searched for "A duplicate value cannot be inserted into a unique index." I came across this detailed and seemingly complicated community post. The comments discuss several possibilities and fixes as this issue relates to sitemap issues for many, but the final two comments (as of the time of this blog) stated that uninstalling the plugin profiler fixed the issue.

After finding that the PluginProfiler, Plug-In Profiler, was a solution, I uninstalled the solution without any problems. Then, I tested configuring CRM for Outlook on my own machine and one of the troublesome Outlook 2010 machines. CRM for Outlook configured properly! Problem solved.

Note: after trying to post this with the full text of the error messages, I had some trouble publishing. The most important part seems to be:

10:23:28|  Error| Exception : Cannot configure the organization for Microsoft Dynamics CRM for Outlook. Try to configure the organization again. If the problem persists, contact your system administrator.    at Microsoft.Crm.Application.Outlook.Config.ConfigEngine.Execute(ActionCommand command, ServerInfo serverInfo)

   at Microsoft.Crm.Application.Outlook.Config.ServerForm.<InitializeBackgroundWorkers>b__4(Object sender, RunWorkerCompletedEventArgs e)

10:23:28|  Error| Exception : |NativeError:61b8 HResult 80040e2f Message: A duplicate value cannot be inserted into a unique index. [ Table name = MetadataSchema.EntityClientStatistics,Constraint name = PK__MetadataSchema.EntityClientStatistics__00000000000007A9 ]|    

Stop workflow with a status of Succeeded, not Canceled

I learned a valuable lesson when working with a workflow recently. There is a difference between Stop workflow with status of: Succeeded and Stop workflow with status of: Canceled. (scroll to the final paragraph if you just want a sentence-long description of each status)

Based on what I had seen elsewhere, the difference in these two workflow statuses was in name only.

In my scenario, I have a workflow set up to create some cases at the creation of an opportunity (or when certain fields change), unless the user who created the opportunity is a particular user. I thought by selecting a status of canceled, I would be able to easily distinguish between instances where the workflow went through all of the steps and instances where the workflow stopped itself on the first step. However, I had a misunderstanding of what changing the status of canceled would do.

Setting the status as canceled was causing business process errors when this users was trying to create opportunities, and it was causing errors for a plug in that we have installed. Changing the workflow to a status of canceled not only stopped the workflow, but it also stopped the event that triggered the workflow. For me, this was unintended behavior.
Essentially, using the status of canceled is a way to cause an error that can be tracked when a certain condition is met. Using the status of completed will stop the workflow from moving any further, but will not prohibit the event that triggered the workflow in the first place.