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:
http://marcoamoedo.com/blog/adding-linkedin-to-dynamics-crm/

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.

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.

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.

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!