Friday, August 19, 2011

The CRM 2011 SDK is wrong (ish)

So that might be a slight exaggeration, but I just hate it when documentation is incorrect. In this situation, the culprit is the javascript to assign a value to a lookup field. According to the SDK, there are 3 properties you must set on your array to set the value on a lookup:
  • id
  • name
  • entityType
Unfortunately, if you try to set these three properties and then use the setValue() method to assign it to a lookup, you will either get nothing or an error stating that the "object does not support this property or method". That's because "entityType" doesn't actually exist.

Instead, you must create your array, same as before, but set the id, name, and type. Just "type". Set this to the object type code for the entity (1 for account, 2 for contact, 8 for user, etc.) and suddenly the setValue() actually sets something.

So it seems I am only half correct. Upon reading the SDK more closely, it seems you CAN set entityType, but it should be a string for the entity instead of the type code. Got so used to the type codes in 4.0.... Anyway, if you set entityType to something like "account" or "systemuser" then it works.

Tuesday, February 15, 2011

CRM 2011 Outlook client x64

One of the great new features with CRM 2011 is support for 64-bit environments. With CRM 4.0, the Outlook client was x86 only, meaning that you had to install 32-bit Office (regardless of your operating system being x86 or x64) in order to install the CRM Outlook client. With CRM 2011, now x64 Office is supported, which is fantastic.

Except that the installation doesn't work. Well, it works, but you can't connect to an organization. Here is what I discovered, and how I fixed it.

  1. The installation of the client runs just fine. The new installer is like other Office 2010 installs - you get a big button for "Install Now" and then another smaller one if you want options, which are essentially where to install and do you want to enable Offline access. No problems so far.
  2. I ran the configuration wizard, selected CRM Online to connect to my organization, and entered my Live ID information. The wizard found all of the Online organizations my Live ID is associated with, and I picked the one I wanted and clicked OK.
  3. The wizard did some initialization tasks, sat for a while, and then failed with an error: "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".
  4. Since that error isn't terribly helpful, I did more research. In the log (which is buried in Windows 7 under C:\Users\user\AppData\Local\Microsoft\MSCRM\Logs\Crm50ClientConfig.txt), I found this error:
    Exception : Unable to load the native components of SQL Server Compact corresponding to the ADO.NET provider of version 8082. Install the correct version of SQL Server Compact. Refer to KB article 974247 for more details

  5. Naturally, I checked out that article. The KB states that you might get this error if, on a 64-bit computer, you haven't installed BOTH the x86 and x64 versions of SQL Compact 3.5. Upon examination, this was true - the CRM client installation had only installed the 32-bit version. Fortunately, the KB article contained a link to the installers for SQL Compact 3.5 SP2.
  6. I installed the x64 version, and retried the configuration wizard. Still no dice, and the same error in the log. I revisited the KB article and noticed that you can get this error if the versions don't match between x86 and x64. SP2 is the most recent, BUT looking under Programs and Features, the x86 version installed by CRM is 3.5.8082.0 and stock SP2, which I had installed for x64, is 3.5.8080.0.
  7. Searching for the version number, I discovered a hotfix for SQL Compact 3.5 SP2 which brings it up to .8082. Downloaded and installed the hotfix to get both versions to the exact same release. (I also tried downgrading the x86 version to .8080 and got the same ADO error in the log.)
  8. Re-ran the configuration wizard, and after one stumble with actual network problems, it finally connected and works!

Long story shortened:
  • The x64 installer for the CRM 2011 Outlook client does not include everything necessary for the client to work.
  • You must download the x64 installer for SQL Compact 3.5.
  • You must upgrade the x64 version of SQL Compact 3.5 to version 3.5.8082.0 with the hotfix.
  • At this point the Outlook client should be able to connect to your CRM 2011 organization.

Monday, June 21, 2010

Improved LinkedIn CRM integration

So some of you may have the original style LinkedIn integration in CRM - it displays in an iframe somewhere on your account/contact/lead and displays any people at a given company that are members on LinkedIn. However, I was recently directed to find (and subsequently found) a better integration (at least it looks cooler and seems to be pretty slick) posted here:

The code he lists here is for accounts - copy and paste and you have a new cute little icon next to the account name field! If I modify this to work with contacts or leads I will post it here as well.

Wednesday, May 19, 2010

Error when reactivating a case

This same sort of error might occur when reactivating any record, but the specific instance was an error when attempting to reactivate a case in CRM. The error returned in a trace is: The object cannot be updated because it is read-only. This error message doesn't help much, because of course the object is read-only. However, this message is actually being returned by an attribute on the case, and the problem at hand is some javascript.

Thanks to the conversation here, I was able to determine that the problem is in the OnLoad() script, where I was setting a few attributes to ForceSubmit = true. This script is actually firing when I open the read-only record, which normally has no effect because the record cannot be saved. However, upon trying to reactivate, the system is performing a save operation, but the ForceSubmit is trying to submit the value in the attribute before the record becomes read/write again. Hence the above error.

The solution here is to simply wrap the ForceSubmit statements in an IF statement to make sure that they only fire on create or update forms and not on read-only forms.

Tuesday, February 9, 2010

Server 2008 and the Email router with IFD

Today I encountered an interesting issue with Server 2008 and the email router. The email router is running on the same server as CRM, and I had just configured CRM to run in IFD mode. This somehow broke the email router. When browsing the CRM URL from the server, I received the IFD login page. Thinking I had missed a subnet, I confirmed that all appropriate subnets (including the server subnet) were included in the IFD tool, and verified it was working by testing from another server. Everything checked out.

And yet somehow, the request for CRM was coming from another IP not included in the subnet, but only when browsing from the CRM server itself. It turns out that the CRM server, when making the request to itself, was making that request using IPv6 instead of IPv4. The IP address was indeed different and was not in one of the included subnets. To resolve this issue, I disabled IPv6 on the ethernet connection (in the properties, I simply unchecked the IPv6 box) and tested again. Everything worked fine, and the router was fixed.

So if you are using an IFD, keep in mind that Server 2008 may try to make requests in IPv6 to itself, and the CRM server will think these are external requests.

Monday, February 8, 2010

Server 2008 and the IFD tool

Just a quick note today - if you try to run the IFD tool for CRM on a 2008 server, it might not work. You will get no error, no warnings, but the settings will not be applied... unless you run the tool explicitly as an Administrator. UAC strikes again!

Wednesday, December 2, 2009

Rollup 7 breaking workflow publishing?

I can't be certain, but I think Update Rollup 7 for CRM is breaking my ability to publish workflows that contain email steps. So far I have encountered this twice, for two different customers, and it is really annoying. Fortunately, I have found the solution!

The error that appears in the trace file (if you do a trace while attempting to publish the workflow) comes up something like this:
>Crm Exception: Message: Workflow compilation failed:
WF1399: Activity 'SendEmailStep5_policy' validation failed: Property "RuleSetReference" has an invalid value. Rule set is invalid. Rule "main" validation failed. Type System.Globalization.CultureInfo is not marked as authorized in the application configuration file.
WF1399: Activity 'SendEmailStep7_policy' validation failed: Property "RuleSetReference" has an invalid value. Rule set is invalid. Rule "main" validation failed. Type System.Globalization.CultureInfo is not marked as authorized in the application configuration file., ErrorCode: -2147201023

The error actually provides a clue as to the problem, but it wasn't entirely obvious to me. There is a line missing from the web.config file which, when added back, resolves the issue. The line is:
<authorizedtype assembly="mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" namespace="System.Globalization" typename="CultureInfo" authorized="True"></authorizedtype>

I've just been adding it to the end of the list of authorized types for mscorlib. You don't even have to restart IIS - it just begins working as soon as you save the file.

UPDATE: I had to put in the HTML escape characters for the brackets to show up in here - my apologies for the line not appearing before!