Wednesday, December 28, 2011

CRM 2011: The server address is not valid

I recently encountered another issue with being able to connect to the CRM server using the CRM Outlook Client. While specifying the connection information I was being presented with a "server address is not valid" message.

But this message was clearly off because the Server URL and organization were clearly correct.

To troubleshoot, I enabled the Troubleshooting using the CRM Outlook client Diagnostics tool (the way to go about this is described here). Reviewing the trace file I was able to identify the cause of the error i.e. the following text appeared indicating an authentication issue:

Error| Exception : The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Negotiate,NTLM'.

The resolution was simply to enable "Anonymous Authentication" to the CRM web site i.e.:

After performing the above steps, the client was able to connect to the CRM installation.

Wednesday, December 21, 2011

CRM 4.0: Cannot delete or export an entity

We were recently confronted with a situation where we were trying to export customizations in our 4.0 environment but the export kept on failing. We narrowed it down to one troublesome entity. We even tried deleting this entity. But no matter what operation we tried (export, delete, publish), we kept on receiving the following unhelpful error message:

We ran a trace and various other standard troubleshooting operations but nothing pointed us in the direction of the error. I've seen this error in the past where an attribute that was deleted is still referenced from the form and the solution is to open the form and remove this artifact and then publish. This wasn't the case here. So were a little bit stuck.

We turned to Microsoft support who indicated that the issue was indeed related to a missing attribute. However we still were unable to locate the missing attribute even after performing a thorough check against each relationship and verifying that the lookup field was present in the list of attributes.

We were able to finally resolve this by installing an XML comparison tool that allows you to pick an entity that runs a comparison between what is found in the database and what is found in the list of attributes on the form. The tool found the missing field. And to resolve we added that field again to the entity at which point we were able to publish and perform all the usual actions associated with entity customization.

Microsoft have been a little cryptic about this tool that they used claiming that it is still "being developed" and therefore uninstalled it after performing the above troubleshooting.

However I was able to find the following post that seems to reference a similar tool (and includes a download option to boot). I guess we will only know for sure if/when we are faced with this issue again at another client installation.

Tuesday, December 20, 2011

CRM 2011: Plugin Registration Tool Compiled Version

The Plugin Registration Tool for CRM 2011 can of course be downloaded from CodePlex:

However the download from CodePlex contains the source code and needs to be compiled in Visual Studio before it can be used. In case you want to circumvent this compilation step, you can download the executable from the location below:

Friday, December 9, 2011

CRM 2011 Upgraded Report not working

I am not sure if this is something specific in the environment that I am working but I had some custom reports that were not working post upgrade. To troubleshoot I opened up in SSRS and when I tried to run the preview, I received an error message indicating that one of the fields on the report was not in the dataset scope.

This was a "form" report (rather than grid output) and it seems the form elements were no longer associated with the parent "list" in which they were embedded. It could be that this was because this report was developed in SSRS 2005 and it was now being edited in SRS 2008 - I'm not sure.

To resolve I needed to add the "list" back into the report. The following are the steps taken to do so:

  • Highlight all report elements (ctrl+A)

  • Insert new List (tablix) into the report and drag to the size of the report body

  • Click into the list/tablix (ensure outline of tablix is showing) and paste and your report should now look something like this:

  • Update the dataset for the tablix that you just inserted

  • Try the preview again and if the report runs or you are presented with something similar to the screenshot below you should be all set

Thursday, December 8, 2011

CRM 2011: Cannot unregister workflow PlugIn

In a previous post I covered an issue I faced with regards to being unable to unregister a regular plugin. I subsequently had some additional difficulty in unregistering some other plugins that were also carried over from the upgraded 4.0 installation.

In this case, the plugins turned out to be workflow plugins. That is, plugins that are used to extend the workflow (or Process in CRM 2011 speak) functionality.

The error message that was shown contained some text that looked like this:
>Crm Exception: Message: The PluginType(a222ddda-c78e-45c8-91f9-fa06359ac29d) component cannot be deleted because it is referenced by 1 other components. For a list of referenced components, use the RetrieveDependenciesForDeleteRequest., ErrorCode: -2147160033
[2011-12-06 12:03:51.118] Process: w3wp |Organization:9dd6ac5e-4be6-46f9-af58-7caed1001d66 |Thread:   31 |Category: Platform |User: 6b51be4f-7308-dc11-9e28-00188be6f91e |Level: Info | MiniDump.CreateDumpInternal
The key phrase of course being the "reference" issue which I have highlighted.

The only dependencies that I could think of for a workflow plugin are in fact the Process definitions and Process instances. 

I first started out by cancelling all Processes that were in a "Wait" state using Advanced Find as they could be referencing the said plugins.

However after this step, the plugin could still not be unregistered. So my next step was to disable the active Process definitions. 

That still did not bring along the desired results. Only once the calls to the plugin were removed from the Process definitions was I able to finally unregister the plugin.

Although it would be nicer if a better error message were issued highlighting the specific dependency issues (in plain English preferably), I cannot complain too much about the fact that Microsoft is in fact enforcing this dependency logic. Although it took a while to go through the above steps, it is still preferable to having to deal with the fallout of broken Process definitions and instances down the line. And of course being in an upgrade environment, this also helps ensure that certain plugins may require tweaking as part of the upgrade process. 

The only remaining step is of course to note all the above steps as far as cut over planning is concerned.

Wednesday, December 7, 2011

CRM 2011: Java Script Reference

I found the following article to be quite useful so I thought I would re-post it:

It has lots of useful examples of how to perform various form manipulations in CRM 2011.

CRM 2011: Cannot unregister PlugIn

After having upgraded a CRM 4.0 installation to CRM 2011 I was attempting to unregister some of the plugins that were carried over from the 4.0 installation as part of the upgrade process. Yet whenever I tried to do so, I encountered an error telling me that the plugin could not be unregistered. The Error Message received was similar to the one shown below:

After a little bit of research, I discovered that the said plugin was actually a plugin that was developed way back using the CRM 3.0 plugin architecture and therefore had DLLs etc. in the "server\bin\assembly" sub-folder of the existing 4.0 environment being upgraded.

Once the files had been copied over to the corresponding sub-folder in the CRM 2011 upgrade environment, I was able to unregister the plugin successfully.

Not entirely sure that it makes sense in CRM 2011 to have to copy these DLLs present in order to unregister the plugin, but then again, I'm not sure it's worth spending any more time thinking about either.

Monday, December 5, 2011

Microsoft CRM Email Resolution Issues

My previous post discussed promoting Outlook activities (email, appointments, activities) to CRM using Track and Set Regarding, the subtleties between these two options, and when it might be appropriate to use one vs. the other approach.

As mentioned both approaches will attempt to auto-resolve the email distribution list to User and Contact records in CRM. So if you just used Track for an email that has a corresponding contact in the CRM database (matched on email address), it will auto-resolve to that contact and appear in the Closed Activity list. If on the other hand you decided to use Set Regarding to track that same email to a say a case in CRM, then this email will  appear in both the Closed Activities for the case as well as for the contact it was auto-resolved to (the same would be true if you were using Set Regarding to an entity that has no relation to contacts).

It therefore goes without saying that if the "auto-resolution" functionality was somehow broken then you would get none of the above mentioned benefits. Or perhaps even worse - if you elected to "auto-create" contacts as part of the tracking functionality (see screenshot below) - if the "auto-resolution" functionality was broken, it could result in duplicate contacts entering your CRM system as the system fails to match it to an existing contact, and therefore decides to create a new contact record.

The above scenario is not only theory but something that actually was occurring in one of our installations. It is not exactly clear when the problem was introduced into the environment as the client was not using the email tracking features. Until recently that is...

After further analysis and discussions with Microsoft support it turned out that the reason the auto-tracking feature was not working was because the EmailSearch view in the CRM database was not getting updated. Probing a little deeper it turned out that the root cause of this issue was due to the fact that the "Format" on the email attributes of the contact record was text rather than email. This is not a setting that can be changed from the front end, so it's not clear how it came to be but it originated in the 4.0 environment and remained that way through the conversion to CRM 2011.

The steps for resolving this are twofold:

  1. Revert the field back to the Email format. 
  2. Update the EmailSearch view for existing records

Steps for reverting the field back to Email Format:

1.      Open CRM web client as an administrator and create a new Solution; open IE, browse to CRM, click Settings, click Solutions and then click the new button under Solutions.
2.      Within the new Solution window fill out the form as below and click the Save button. Display Name: Contact Name: Contact Publisher: Default Publisher for CRM2011. Version:
3.      Now click on Entities within the Solution and then click the Add Existing button.
4.      Check the Contact entity and then click OK.
5.      When prompted about the missing components select “No, do not include required components” and then click OK.
6.      Click the Save button.
7.      Now click the Export Solution button.
a.      Click Next unless you have not published customizations. Click Publish Customizations first and then click Next.
b.      You will be prompted about other missing components. Just click Next to ignore these as we will be importing this Solution right back into the same organization.
8.      At the next window do not select any Settings and just click next.
9.      Since this will be an unmanaged package so just leave the current option “Unmanaged” selected and click Export button.
a.      You will now be prompted to save the file. Just save it to the desktop of the CRM server.
10.   Go to the desktop of the CRM server and open the newly created zip file titled
a.      Extract the file customizations.xml.
b.      Open the customization.xml file with an XML editor.
11.   Press Ctrl+F and search for the string EmailAddress1.
a.      Under EmailAddress1 locate the element “<Format>text</Format>”.
b.      Within in the element change the word text to email. Save and close the file.
12.   Now place the modified customization.xml file back into the zipped solution
13.   Back in CRM Solutions click the Import button.
14.   Browse to the location of the Solution file and then click next.
15.   Click Next to import the Solution.
Update the EmailSearch view:

One way to go about updating this view is to "touch" the email for all contact records. For example, you could do this by creating a workflow that copies the email to a temporary field and then in a subsequent step copies it back. You could then apply this workflow to all your contact records.

If your contact database is large the above approach might not be practical and you may want to use a script instead. Below is a script that can be used to update emailaddress1 on the contact record. This script is not supported so please use and update at your own discretion.

DECLARE @id              uniqueidentifier
DECLARE @email         nvarchar(100)
DECLARE @entitycode    int = 2   -- Contact
DECLARE @columnnumber  int = 42  -- Email Address 1 (45 for emailaddress2, 47 for emailaddress3)


        declare DetailCursor cursor for
                  select contactid, EMailAddress1
                  from Contact
                  where emailaddress1 is not null
                  and ContactId not in (
                  select ParentObjectId
                  from EmailSearchbase
                  where ParentObjectTypeCode = @entitycode

        open DetailCursor
        fetch DetailCursor into @id, @email

        while @@fetch_status = 0

              insert into EmailSearchBase (EmailSearchId, EmailAddress, ParentObjectId, ParentObjectTypeCode, EmailColumnNumber)
              values (newid(), @email, @id, @entitycode, @columnnumber)

          fetch DetailCursor into @id, @email

        end --while
        close DetailCursor
        deallocate DetailCursor