Microsoft Dynamics CRM Compatibility List

Ever wanted to know if a specific product version or service pack are considered to be compatible and supported with CRM 4.0 or 2011? Microsoft have now released a new "living" KB article that describes the current support stance for most of the products you would consider using with CRM.

This is especially useful for situations where you want for example to know what latest Exchange Server major and minor versions are supported etc.

The article is here: KB2669061

SyncEntry_ and SubscriptionStatistics_ tables

If you have a look at your database, you may notice several SyncEntry_ and SubscriptionStatistics_ tables.

Ever wondered what they are? These tables are for use with Outlook clients. You will have 2 of each table for each online client, and 3 of each table for each offline client. Additionally these tables are per user, per machine... so if a user changes computer then there will be more tables for that user.

On a related note, you can actually remove these tables in a supported fashion if you arent using them - the UK CRM team posted a topic on ow to do this here:

http://blogs.msdn.com/ukdynsupport/archive/2009/05/07/script-to-clean-up-syncentry-guid-and-subscriptionstatistics-guid-tables-in-the-sql-database.aspx

The code is reproduced below for your convenience...

Declare  @SyncEnt  char(60),
   @sql   nchar(100),
   @sqlSync        nchar(100),
   @DN             char(50)
                
Declare User_cursor CURSOR for
                
select DomainName from SystemUserBase
                
 OPEN User_cursor
 FETCH NEXT FROM User_cursor INTO @DN
                
WHILE @@Fetch_Status = 0
BEGIN
 DECLARE CRMSync_cursor CURSOR FOR
 select substring(SyncEntryTableName,11,42) as SyncEntryGUID from subscription where systemuserid in
    (select systemuserid from systemuserbase where domainname =@DN) 

 OPEN CRMSync_cursor 

 FETCH NEXT FROM CRMSync_cursor INTO @SyncEnt 

 WHILE @@Fetch_Status = 0
 BEGIN
  SELECT @sql = 'DROP TABLE SubscriptionStatistics_' +(@SyncEnt)
  SELECT @sqlSync = 'DROP TABLE SyncEntry_' +(@SyncEnt) 

  EXEC sp_executesql @sql
  EXEC sp_executesql @sqlSync
  FETCH NEXT FROM CRMSync_cursor INTO @SyncEnt
 END 

 CLOSE CRMSync_cursor
 DEALLOCATE CRMSync_cursor

 delete from subscriptionclients where subscriptionid in
    (select subscriptionid from subscription where systemuserid in 
    (select systemuserid from systemuserbase where domainname = @DN)) 

 delete from Subscriptionsyncinfo where subscriptionid in
 (select subscriptionid from subscription where systemuserid in
    (select systemuserid from systemuserbase  where domainname = @DN)) 

 -- Please Uncomment The 3 lines below if you are on UR7 or Higher
 -- delete from SubscriptionManuallyTrackedObject where subscriptionid in
 -- (select subscriptionid from subscription where systemuserid in
 -- (select systemuserid from systemuserbase where domainname = @DN)) 

 delete from subscription where systemuserid in
    (select systemuserid from systemuserbase where domainname = @DN) 

     FETCH NEXT FROM User_cursor INTO @DN
END 

CLOSE User_cursor
DEALLOCATE User_cursor

Keeping a hold on your database size

CRM databases have a tendency to grow very quickly. I've seen growth on smaller 50-ish user sites of easily more than 1GB per month. This gets bigger even quicker if you have a workflow and e-mail heavy solution.


I wont cover the e-mail issue in significant detail here other than to say some thought should always be given to the storage of e-mails in CRM and more specifically, attachments. This also applies to all other methods for saving attachments into the database. Some things to consider:

• What to set the CRM maximum file size to (this cant be bigger than 8192 kilobytes). Keeping it smaller will improve database size, but will mean that larger attachments will not be saved.
• When to promote an e-mail to CRM - do you really need every e-mail (and attachment) when a large amount of correspondence can often just be noise, with only certain elements of a conversation actually being relevant.

If you don't keep control of this, then you database can get very big very quickly.

The other area and the one I'm exploring in detail here is the asynchronous operation tables in CRM. With every system job and/or workflow, new records will get written in to these tables (specifically the Asyncoperationbase and Workflowbase tables) Over time as your system goes through the motions of your various business processes, match code updates, system expansion tasks and all the rest, these tables can get very, very big; sometimes containing millions of records, causing not only a storage problem but almost certainly giving us some performance headaches too.

Fortunately Microsoft have recognised this and given us a few ways of dealing with the issue as part of the Update Rollup process.

So first off we have 2 options, both enabled via the addition of new registry keys:

1. AsyncRemoveCompletedJobs (http://support.microsoft.com/kb/974896)
   
   This will remove all completed Async jobs in CRM of the following types:

   CollectSQMData

   PersistMatchCode

   FullTextCatalogIndex

   UpdateContractStates
2. AsyncRemoveCompletedWorkflows (http://support.microsoft.com/kb/974896)
   This will remove all completed workflow jobs from both the AsyncOperationBase and WorkflowBase tables.

And now to the downside - on of the strengths of CRM workflow is its persistent nature - meaning that because the workflow instances exist as data in the system we can report on them... so we are able to extract meaningful detail and manangmenet intelligence from our workflow data. Obviously this ability becomes a bit redundant if we dont keep any of this data.

My general answer to the above challenge is to enable the 'AsyncRemoveCompletedJobs ' registry key, but not the 'AsyncRemoveCompletedWorkflows' key. This means that we can reclaim some space from the other system jobs, while leaving the workflow history in place to support our MI requirements.

One last caveat; these registry cahnges are not restrospctive. In other words once the specific feature is enabled it will only remove jobs/workflows instanciated after the change, not historical data. To get around this the kind folks at Microsoft have provided us with some SQL swcripts that will remove historical data from the tables in question.

The article can be found here: http://support.microsoft.com/kb/968520/

A cautionary tale: The script provided by Microsoft deletes all completed jobs, workflow included. So if you intend to replicate the functionality of retaining completed workflow history as per the above registry keys, you will need to modify the script accordingly to not remove records where OperationType = '10'. If you dont do this you lose everything... and I'm talking from painful experience here :(.

Having been presented with a pick list containing 50 items that my customer wanted me to upload to CRM, I got to wondering if there is an easier way of doing this.


Of course, I can edit the XML of the record directly but that's still a lot of manual work.

Enter the Dynamics CRM Pick-list XML-Generator from Mario Raunig... an incredibly useful time saving tool.
 
Thanks Mario!!

How to get code in my blog?

I've often come across very useful information posted by other industry experts on blogs. Now that I'm doing it myself I was wondering how people managed to post good looking code on their sites - one example is Jim Wang over at http://jianwang.blogspot.com/.

Well, I've found the key - a very useful tool called SyntaxHighlighter.

And just so I can remember how to set it up next time I need it, there is a very useful wiki over at Carter Cole's Blog.

And just so you can see it working:

//Define and initialise our variables
var alertMsg;
alertMsg = "Hello World";
//Set up the alert window
if (alertMsg != "") {
    window.alert(alertMsg);
}