Not so long Microsoft has released Update Rollup 2. Some fixes were just too tempting to pass on so we duly deployed the rollup on the server. Some strange message about failure to update a report (which it did not actually try to update) aside, it all went well and, thanks to AutoUpdate feature, deploying update to the Outlook client was going to be a snap, according to the Implementation Guide and Eric Newell.

We followed this instructions and, indeed, Outlook prompted and successfully updated itself, as advertised. Just to make sure, we tried CRM->Check for Updates command and, to our surprise, Outlook decided to download and install the update again. In fact, it decided to prompt us every time it started. Which turned out to be not only extremely annoying but made it plain impossible to run Outlook client on Terminal Server as normal users do not have administrative privileges to run any update.

To cut the long story short, PatchID {9EA7FDEB-9D7E-4278-8CD1-94ACEFA40D3F} mentioned in the instructions turned out to be incorrect and the correct ID is {84EBD2D4-7530-47DA-B7C5-72E4F4FA5AE5}. However, simply changing patch ID after the fact would not work as we still need to remove erroneous ID first using <Delete> “instruction”. The correct configuration XML is as following:

Tried both default Url (to download update from Microsoft site using numeric LinkId) and custom AutoUpdateUrl (to download update from the custom location using file name as LinkId), both work fine.

Note: unlike Rollup 1, files in Update Rollup 2 are language-specific meaning that PatchId and LinkId would need to be changed for languages other than English. PatchId for Spanish version, for example, is  {A090EBC0-F3EC-414F-9E0A-02DABFB07618}. At this point in time I have no idea how to find correct LinkId, the workaround is to use custom download URL as documented here.

By the way, Groundhog Day and Update Rollup 2 release are both in February. Coincidence? I don’t think so.

My biggest grievance about client-side development in CRM is that it mandates this vicious  "write some script-paste to form-publish-receive a bomb-review-sprinkle alerts-tweak the code-publish-receive an error-write some script-..." cycle. Verbose, lengthy, difficult to develop, difficult to debug. I do not like developing in Javascript.

Correction.

I did not like developing in Javascript until I discovered jQuery. There is certainly a number of Javascript libraries available with Prototype and jQuery leading the pack. Choosing between the two is not unlike C# vs. VB or Peach vs. Grapefruit. I see the main distinctive feature of either library not so much as a neat and concise code but as the ability to express Programmer Intent extremely well (incidentally, this post uses Ruby as an example; combined with the fact that Ruby on Rails is a driving force behind Prototype, it all starts to make sense). And while Prototype does a fantastic job in encouraging OOP and has a spectacular Script.aculo.us effects library, jQuery won me over with its size, documentation, elegant syntax and method chaining.

What can it do? Well, how about planets revolving around the Sun. Convinced? Read good introduction to jQuery for Javascript programmers and let's move on. More...

Associated views have always been a sore subject in CRM. When CRM 3 was released, they did not include inactive records and, despite the ever present Activate menu item, there was no any way to actually show all associated records not just active ones. People complained. Then rollup 2 changed the behaviour. People complained. Then there was a hotfix for custom entities. People complained that it should be available for system entities as well. CRM 4 is released and hotfix no longer works. People complain.

Plug-ins to the rescue

The good news is that CRM 4 plug-in model is flexible enough to solve this problem once and for all. The idea is to intercept RetrieveMultiple message and modify its query so that all associated records are returned. And the code is surprisingly simple:

Installation

1. Compile the code and sign the assembly.
2. Using Plug-in Registration Tool register the plug-in.
3. Register execution step for the entity that you'd like to show all records in associated views. Note that we use PreStage (a.k.a. BeforeMainOperationOutsideTransaction) and Synchronous execution mode. For example, to always show inactive contacts in associated view:
   
4. Optionally add Status column to the associated view for the entity not to confuse users.
5. Rinse and repeat 3-4 for other entities.

The result for the Contacts associated view inside account entity:

At long last Activate menu command makes sense.

Note: this code is a sample only and is included "AS IS" without any warranties whatsoever. In Real Life™ more stringent tests would have to be performed to ensure that RetrieveMultiple message indeed originated from the associated view and was not sent by your poor fellow co-worker complaining (or, worse still, raising support request with Microsoft) about filtering state code not working.

Everyone agrees that Microsoft CRM integration with maps is very attractive. And there are ways to do it with either Live Maps or MapPoint or Google maps. However, as John O'Donnell mentioned in comments:

Virtual Earth is free for development purposes but will require licensing for production systems.

While the statement is not, strictly speaking, correct (production system != commercial), both Microsoft and Google place non-commercial use restriction on their free services.

From Virtual Earth™ Platform API Terms of Use, non-commercial use section:

Your Application and content in your Application must be available publicly without restriction (for example, login or password must not be required).

Google Maps API Terms of Service is a bit more vague but still:

The API may be used only for services that are generally accessible to consumers without charge. Accordingly, You may not use the API for any service that requires a subscription or other restricted access, or for which a fee is charged.

User access to Microsoft CRM is restricted and does require a login so using either mapping service in your CRM deployment without appropriate licensing is in violation of respective terms and conditions. Commercial licensing is available from both Virtual Earth and Google Maps but, as with any product where pricing information is not publicly available, do not expect it to be cheap. Do the right thing and advise your customers that, while there may be a plethora of free lunches available, commercial use of mapping services ain't one of them.

Yesterday I was working on some plug-in code which was working fine earlier. I changed pipeline to synchronous and started to get consistent "404 - Not Found" error from calls to CrmService. I reduced the problem to something like this:

And it just was not working. We all know about very "informative" SoapException which would have been fine but I was getting simple http-level 404. Something was pointing somewhere it shouldn't have... More...

You spent years polishing your algorithm, moving bytes around, replacing strings with StringBuilders, extracting every last bit of performance from your code. The assembly Acme.CoolTools.dll is into its' 3rd major version, competitors are begging for mercy. Life is good. Then Microsoft CRM 4 comes along with its' beastly architecture wanting plug-ins to be deployed in a database. And offline CRM clients, clutching a copy of Reflector all want your dazzling assembly as well.

Perhaps you simply wanted to avoid GAC, which Chris Sells knew to be evil back in 2004. Or may be you just felt that instead of being sucked into assembly hell you would rather distribute one and only one assembly.

Whatever the real reason might be, today's challenge is to write a Microsoft CRM 4 plug-in that uses classes and methods from other assemblies; then package it all into one blob that can be deployed and distributed as required. In fact, it was the challenge from one of our customers as well as from the newsgroups (speaking of good timing!). More...

Now we all know that when Microsoft says "unsupported" they always sometimes mean business. Take, for example, popular CRM 3 customisation to filter lookup field data that used to work well. Until version 4, that is. Not all is lost, however, because no thanks to me but to Adi Katz, now there is new unsupported way to make it work in CRM 4 as well.

For example, to make primary contact lookup for an account record to show contacts from this account only, the following customizations are required:

More...

"I want to be able to open a record in CRM, push the button and import the information as a contact into Outlook. Then, after synchronising with my PDA, I'll have this contact card available while on the road."

That was, in a nutshell, the requirement from one of the CRM users.  This particular CRM deployment contained over 10,000 account and contact records imported from the industry database and taking them all offline would have been a challenge not to mention impractical. After some brainstorming the following alternatives emerged:

• Offline CRM client synchronising a subset of records. Apart from the fact that user did not have a laptop with them all the time, process of adding a selected individual account/contact would have become quite complicated. We could have built a view selecting accounts/contacts based on some criteria, e.g. custom flag  and then ask user to check this flag for the selected record and then go offline. Cumbersome and would not work that well when user was on the road.
• CRM 3.0 Mobile. Same issues as above. In addition user wanted the records to be on both laptop and PDA.
• CRM Mobile Express. Perhaps that would have worked if user had a reliable phone reception everywhere they went. Unfortunately, due to the nature of their business quite often they ended up in places which fall into unlucky 2% of Australian population without reliable mobile coverage. If anyone thinks that satellite phone is an option, just wait until your first bill.
• Export/import facility. Outlook has ability to import contact information from vCards so all we have to do is to export CRM information as a vCard. Now we were cooking...

More...

Microsoft has just made Microsoft Dynamics CRM 4.0 Deployment SDK available for download. As the case with all other CRM SDKs, it only contains documentation for the deployment web service but most certainly covers the gaps left by SDK in the provisioning department.

The Deployment SDK presents information to help you write code using the Deployment Web service (Deployment Service).

You can create solutions to do the following:

• Manipulate the Microsoft Dynamics CRM Organization entity to create and manage organizations.
• Retrieve and view Microsoft Dynamics CRM license type information for a deployment.

Microsoft Dynamics CRM 4.0 can host multiple organizations on a single CRM server. The Deployment SDK provides a way to programmatically manage these organizations using the Microsoft Dynamics CRM Deployment Manager and the Microsoft Management Console (MMC) snap-in.

Limitations:

There are two types of Microsoft Dynamics CRM deployment entities: Organization and Server. The Deployment SDK provides programmatic access for manipulating the Organization entity. It does not currently enable you to write code against the Server entity for actions such as enabling and disabling a Microsoft Dynamics CRM server.

Also, the Deployment SDK also does not provide methods for creating users or teams. For information about manipulating User and Team entities, refer to the Microsoft Dynamics CRM 4.0 SDK.

Source: Microsoft Dynamics CRM 4.0 Deployment SDK

Some CRM projects are small and people, small business owners in particular,  are very cautious about the costs. In one of our CRM 3 projects, all the customer wanted was customised quote and order documents, nothing more nothing less. While installed templates are available for customisation, the most common complaint in the newsgroups is inability to add new attributes to the data. With GST legislation in place in Australia, we had to have additional attributes for the quotes and orders to look professional and be legitimate documents at the same time.

CRM 4 seems to resolve the issue, however, there is no simple alternative for CRM 3. If you need a full blown custom mail merge system, look no further than mscrm-addon.com WordMailMerge product. If you're already running Office 2007, Michael Höhne, the unofficial Microsoft CRM "da man", is offering soon-to-be-released document generator based on OpenXML format.

We could not help but wonder how come that Microsoft Excel could consume all possible permutations of filtered views while Microsoft Word remained confined to brain-damaged out-of-the box templates. The plan was simple: control Word through the javascript, create mail merge object, connect it to the data source, run some select statement based on filtered views then merge the data using a template. I knew there were some obstacles to overcome I just did not realise that there will be so many. More...