Lync Presence in CRM Outlook Client

My previous post highlighted some of the enhancements that Update Rollup 5 has brought to the table.


The last one on that list - CRM Outlook Client enhancements - includes fixing a pet peeve that was noticeably absent until now. Which was the lack of an integrated Lync presence on the CRM Outlook Client. This seemed to be a glaring oversight as it did work in CRM 4.0. We had logged this as a support ticket to Microsoft and the response we received was none too encouraging and I quote:

Thank you for your patience, I wanted to give an update on this.  Our Escalation Engineers have determined that this is functioning by design and will not get fixed in the current release of CRM.  This functionality worked within CRM 4.0 client because CRM data was display on web pages which allowed presence data to be displayed.  In CRM 2011, our development team opted to give CRM more of an integrated look and feel with Office, so standard Outlook controls were used.  As a result, the control in which CRM uses to display data does not support the usage of presence data.   

To implement functionality to include presence data within Outlook would require a redesign of how the CRM client displays data.  Such a redesign will not come in the middle of a product lifecycle but it certainly is possible for a future release of CRM.  Please feel free to submit this as a product suggestion to our developers at https://connect.microsoft.com/dynamicssuggestions/

Let me know if you have any remaining questions on this issue.  If you do not, I will go ahead and archive this support incident.

Anyway, this story of course has a happy ending. The support rep indicated that the enhancements would be possible in a future release of CRM. When he said that I assumed that it would be pushed out, at a minimum, to the next major release of CRM. But I guess it depends on how you define "release" and in this case it seems to be that Update Rollup is classified as a release. Either that or Microsoft development changed their mind but either way I'm not complaining.

Below is a screenshot illustrating the user experience (I couldn't get anyone else to pose so you'll have to settle for an image of moi).

CRM 2011 Update Rollup 4 and Update Rollup 5 cannot be uninstalled

In case you miss the small print that accompany both Update Rollup 4 and Update Rollup 5 you should note that neither of these updates can be uninstalled due to the significant changes they make to the database. So you definitely want to perform a database backup before installing and perform the necessary testing in a test environment before applying to production.

So what are the significant enhancements/improvements that prevent uninstalling? While Update Rollup 4 seemed to mainly focus on some performance improvements, Update Rollup 5 has a slew of improvements including:

• Chart Design Enhancements
• Dialog/Workflow Enhancements
• Enhanced Data Management
• CRM Outlook Client enhancements 

Not too shabby indeed.

Microsoft Dynamics CRM 2011 Downloads

It might be my imagination but it seems that Microsoft has moved the download locations for the Microsoft Dynamics CRM server products. It used to be that if I needed to download these products I'd just do a Bing or Google search for "Download Microsoft Dynamics CRM 2011" or thereabouts and the link for the the CRM downloads would appear at the top of the list.

Well I thought that perhaps I was going crazy but I could no longer find the download page. I tried a number of search criteria variations in the various search engines but I'd get results of all things Dynamics CRM (not to mention several broken links) except the blessed server downloads that I was looking for...

I'm sure the search engines will catch up with this re-org (you would think that Bing would have been automatic...) but in the meantime you can use the links below (I eventually found these by searching directly on Microsoft's download site):

• CRM Server
• Email Router
• Report Extensions - Install using the SrsDataConnector folder under the CRM Server server download

Where did my Outlook reminders go?

If like me you've suddenly noticed that Outlook reminders for tasks, appointments etc. are no longer appearing (hopefully not as a result of having missed an important meeting or such like), then you may want to read on.

 

This issue occurs for Outlook 2010 and it appears to have not been fixed in the Outlook Rollups. But you may want to install the latest rollup (UR5 as of this writing) before going any further.

The cause of the issue is highlighted in KB article 2584053.

You can download the hotfix from here. It goes without saying that you should select the correct version (if using IE it should auto detect that for you), and then follow the instructions to have the fix emailed to you.

After installing, create a test reminder that is in the past to ensure that it comes up as soon as you have entered it to ensure that this has indeed fixed your issue.

Uploading files from the file server using Scribe

The Challenge
You need to upload files from a file server into CRM. A good example of this requirement might be if you're migrating from another CRM system where attachments to CRM entities are stored directly on the file system and referenced from the CRM records rather than being stored as a blob directly in the database as is the case with Microsoft Dynamics CRM. When a file is already stored as a blob in the database, the conversion is fairly straight forward. But how do you about uploading files that are stored on the file server as attachments to MSCRM records?



The Solution
Fortunately the solution is also pretty straight forward if you have the option of using Scribe for migration. As a picture is worth a thousand words, I will illustrate it with a screenshot:

In short, all you need to do is to map to the "annotation" entity and ensure that:

• isdocument = 1
• vfAttachmentFileName = path of the file on the file server

And that should pretty much do the trick.

There is a problem communicating with the Microsoft Dynamics CRM Server

We received this error while trying to configure the CRM Outlook Client for CRM 2011:

This was from a machine where we were able to connect to CRM 2011 using Internet Explorer so it was a little perplexing why we should be receiving a communication error as indicated in the error message issued above.

In order to resolve, the following steps were taken:

1. Enabled Tracing by going to Start | Microsoft Dynamics CRM | Troubleshooting tab and enabled tracing
2. After reproducing the error retrieve the trace files from %Userprofile% \Local Settings\Application Data\Microsoft\MSCRM\Traces
3. Analyzed the trace file to find the source of the error

It turns out that in our case there was an errant plugin that was causing the error as indicated in the logs:

In this case, we had upgraded from CRM 4.0 and although the plugin above still worked (using IE navigation), it apparently was troubling the CRM Outlook Client for reasons that are not entirely understood. Anyway, disabling/removing the plugin resolved the CRM connection error that we were experiencing.

In conclusion, it turns out of course that the error message itself was a little misleading because as we discovered - the issue was related to a wayward plugin rather than connectivity.

What happened to DeletionStateCode?

DeletionStateCode is no longer in CRM 2011. The following post provides a good history and reasons for deleting the DeletionStateCode field.

Obviously the implication of removing this field is that now when a delete operation is performed it is a lot more permanent. You can no longer quickly go behind the scenes and run a script to retrieve the deleted entry (or entries as cascading rules might take effect). Not that you ever should have taken the action of deleting lightly, but now you will want to be that much more sure when you are faced with the "Are you sure you want to delete the [entity], including all records under the [entity]" prompt...

If you have auditing enabled for the entity in question, you will be able to see the entity with all its attributes along with any audited sub-entities and all their attributes so information in this case is not lost and you could painstakingly recreate the entity from this log. However there's a big caveat in the above i.e. the assumption that the entity in question and all sub-entities are being audited (which is quite a big assumption especially on the sub entities which can vary per delete operation). The image below shows the Audit Summary View of a deleted account entity along with the child contact entity - as illustrated, the details could be reconstructed.

If the entity is not being audited then the only way to retrieve the deleted record(s) would be via a database restore operation and some SQL queries to retrieve the data (assuming you didn't want to restore the entire database on top of the production version).

In spite of this, I view the removal of the DeletionStateCode in a positive light. The question arises - how many layers of protection is required to prevent the user from deleting something that should not be deleted? Here is what we already have:

• Warning - The "Are you sure" prompt making users think twice before confirming the action they wish to perform
• Record Status - We already have the active vs. deactivated record status. A deactivated record is in a sense a deleted record i.e. it is removed from all active views. When in doubt users should deactivate rather than delete.
• Permissions - The availability of the delete action is controlled via permissions. Best practice recommendations are generally not to provide end users with delete permissions for sensitive data. 
• Audit - As mentioned above, the audit tool provides another line of defense for something that has already happened.

The Audit feature is new in CRM 2011 and perhaps this additional measure is what pushed Microsoft over the edge in terms of removing the DeletionStateCode. Whatever the underlying reasons might be - the benefits of the removing this field (as mentioned in the referenced post above) far outweigh the pitfalls.

As a last point, the impact to reports in a CRM deployment should be low. That is because CRM reports are meant to adhere to the CRM SDK, and such reports referenced the Filtered Views which anyway did not have this field in their definitions. If you are finding that your reports are failing as a result of this change, then that might be an indicator that your reports were not written adhering to the SDK standard which is something you may want to look into...