Wednesday, December 28, 2011

CRM 2011: The server address is not valid

I recently encountered another issue with being able to connect to the CRM server using the CRM Outlook Client. While specifying the connection information I was being presented with a "server address is not valid" message.

But this message was clearly off because the Server URL and organization were clearly correct.

To troubleshoot, I enabled the Troubleshooting using the CRM Outlook client Diagnostics tool (the way to go about this is described here). Reviewing the trace file I was able to identify the cause of the error i.e. the following text appeared indicating an authentication issue:

Error| Exception : The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Negotiate,NTLM'.

The resolution was simply to enable "Anonymous Authentication" to the CRM web site i.e.:

After performing the above steps, the client was able to connect to the CRM installation.

Wednesday, December 21, 2011

CRM 4.0: Cannot delete or export an entity

We were recently confronted with a situation where we were trying to export customizations in our 4.0 environment but the export kept on failing. We narrowed it down to one troublesome entity. We even tried deleting this entity. But no matter what operation we tried (export, delete, publish), we kept on receiving the following unhelpful error message:

We ran a trace and various other standard troubleshooting operations but nothing pointed us in the direction of the error. I've seen this error in the past where an attribute that was deleted is still referenced from the form and the solution is to open the form and remove this artifact and then publish. This wasn't the case here. So were a little bit stuck.

We turned to Microsoft support who indicated that the issue was indeed related to a missing attribute. However we still were unable to locate the missing attribute even after performing a thorough check against each relationship and verifying that the lookup field was present in the list of attributes.

We were able to finally resolve this by installing an XML comparison tool that allows you to pick an entity that runs a comparison between what is found in the database and what is found in the list of attributes on the form. The tool found the missing field. And to resolve we added that field again to the entity at which point we were able to publish and perform all the usual actions associated with entity customization.

Microsoft have been a little cryptic about this tool that they used claiming that it is still "being developed" and therefore uninstalled it after performing the above troubleshooting.

However I was able to find the following post that seems to reference a similar tool (and includes a download option to boot). I guess we will only know for sure if/when we are faced with this issue again at another client installation.

Tuesday, December 20, 2011

CRM 2011: Plugin Registration Tool Compiled Version

The Plugin Registration Tool for CRM 2011 can of course be downloaded from CodePlex:

However the download from CodePlex contains the source code and needs to be compiled in Visual Studio before it can be used. In case you want to circumvent this compilation step, you can download the executable from the location below:

Friday, December 9, 2011

CRM 2011 Upgraded Report not working

I am not sure if this is something specific in the environment that I am working but I had some custom reports that were not working post upgrade. To troubleshoot I opened up in SSRS and when I tried to run the preview, I received an error message indicating that one of the fields on the report was not in the dataset scope.

This was a "form" report (rather than grid output) and it seems the form elements were no longer associated with the parent "list" in which they were embedded. It could be that this was because this report was developed in SSRS 2005 and it was now being edited in SRS 2008 - I'm not sure.

To resolve I needed to add the "list" back into the report. The following are the steps taken to do so:

  • Highlight all report elements (ctrl+A)

  • Insert new List (tablix) into the report and drag to the size of the report body

  • Click into the list/tablix (ensure outline of tablix is showing) and paste and your report should now look something like this:

  • Update the dataset for the tablix that you just inserted

  • Try the preview again and if the report runs or you are presented with something similar to the screenshot below you should be all set

Thursday, December 8, 2011

CRM 2011: Cannot unregister workflow PlugIn

In a previous post I covered an issue I faced with regards to being unable to unregister a regular plugin. I subsequently had some additional difficulty in unregistering some other plugins that were also carried over from the upgraded 4.0 installation.

In this case, the plugins turned out to be workflow plugins. That is, plugins that are used to extend the workflow (or Process in CRM 2011 speak) functionality.

The error message that was shown contained some text that looked like this:
>Crm Exception: Message: The PluginType(a222ddda-c78e-45c8-91f9-fa06359ac29d) component cannot be deleted because it is referenced by 1 other components. For a list of referenced components, use the RetrieveDependenciesForDeleteRequest., ErrorCode: -2147160033
[2011-12-06 12:03:51.118] Process: w3wp |Organization:9dd6ac5e-4be6-46f9-af58-7caed1001d66 |Thread:   31 |Category: Platform |User: 6b51be4f-7308-dc11-9e28-00188be6f91e |Level: Info | MiniDump.CreateDumpInternal
The key phrase of course being the "reference" issue which I have highlighted.

The only dependencies that I could think of for a workflow plugin are in fact the Process definitions and Process instances. 

I first started out by cancelling all Processes that were in a "Wait" state using Advanced Find as they could be referencing the said plugins.

However after this step, the plugin could still not be unregistered. So my next step was to disable the active Process definitions. 

That still did not bring along the desired results. Only once the calls to the plugin were removed from the Process definitions was I able to finally unregister the plugin.

Although it would be nicer if a better error message were issued highlighting the specific dependency issues (in plain English preferably), I cannot complain too much about the fact that Microsoft is in fact enforcing this dependency logic. Although it took a while to go through the above steps, it is still preferable to having to deal with the fallout of broken Process definitions and instances down the line. And of course being in an upgrade environment, this also helps ensure that certain plugins may require tweaking as part of the upgrade process. 

The only remaining step is of course to note all the above steps as far as cut over planning is concerned.

Wednesday, December 7, 2011

CRM 2011: Java Script Reference

I found the following article to be quite useful so I thought I would re-post it:

It has lots of useful examples of how to perform various form manipulations in CRM 2011.

CRM 2011: Cannot unregister PlugIn

After having upgraded a CRM 4.0 installation to CRM 2011 I was attempting to unregister some of the plugins that were carried over from the 4.0 installation as part of the upgrade process. Yet whenever I tried to do so, I encountered an error telling me that the plugin could not be unregistered. The Error Message received was similar to the one shown below:

After a little bit of research, I discovered that the said plugin was actually a plugin that was developed way back using the CRM 3.0 plugin architecture and therefore had DLLs etc. in the "server\bin\assembly" sub-folder of the existing 4.0 environment being upgraded.

Once the files had been copied over to the corresponding sub-folder in the CRM 2011 upgrade environment, I was able to unregister the plugin successfully.

Not entirely sure that it makes sense in CRM 2011 to have to copy these DLLs present in order to unregister the plugin, but then again, I'm not sure it's worth spending any more time thinking about either.

Monday, December 5, 2011

Microsoft CRM Email Resolution Issues

My previous post discussed promoting Outlook activities (email, appointments, activities) to CRM using Track and Set Regarding, the subtleties between these two options, and when it might be appropriate to use one vs. the other approach.

As mentioned both approaches will attempt to auto-resolve the email distribution list to User and Contact records in CRM. So if you just used Track for an email that has a corresponding contact in the CRM database (matched on email address), it will auto-resolve to that contact and appear in the Closed Activity list. If on the other hand you decided to use Set Regarding to track that same email to a say a case in CRM, then this email will  appear in both the Closed Activities for the case as well as for the contact it was auto-resolved to (the same would be true if you were using Set Regarding to an entity that has no relation to contacts).

It therefore goes without saying that if the "auto-resolution" functionality was somehow broken then you would get none of the above mentioned benefits. Or perhaps even worse - if you elected to "auto-create" contacts as part of the tracking functionality (see screenshot below) - if the "auto-resolution" functionality was broken, it could result in duplicate contacts entering your CRM system as the system fails to match it to an existing contact, and therefore decides to create a new contact record.

The above scenario is not only theory but something that actually was occurring in one of our installations. It is not exactly clear when the problem was introduced into the environment as the client was not using the email tracking features. Until recently that is...

After further analysis and discussions with Microsoft support it turned out that the reason the auto-tracking feature was not working was because the EmailSearch view in the CRM database was not getting updated. Probing a little deeper it turned out that the root cause of this issue was due to the fact that the "Format" on the email attributes of the contact record was text rather than email. This is not a setting that can be changed from the front end, so it's not clear how it came to be but it originated in the 4.0 environment and remained that way through the conversion to CRM 2011.

The steps for resolving this are twofold:

  1. Revert the field back to the Email format. 
  2. Update the EmailSearch view for existing records

Steps for reverting the field back to Email Format:

1.      Open CRM web client as an administrator and create a new Solution; open IE, browse to CRM, click Settings, click Solutions and then click the new button under Solutions.
2.      Within the new Solution window fill out the form as below and click the Save button. Display Name: Contact Name: Contact Publisher: Default Publisher for CRM2011. Version:
3.      Now click on Entities within the Solution and then click the Add Existing button.
4.      Check the Contact entity and then click OK.
5.      When prompted about the missing components select “No, do not include required components” and then click OK.
6.      Click the Save button.
7.      Now click the Export Solution button.
a.      Click Next unless you have not published customizations. Click Publish Customizations first and then click Next.
b.      You will be prompted about other missing components. Just click Next to ignore these as we will be importing this Solution right back into the same organization.
8.      At the next window do not select any Settings and just click next.
9.      Since this will be an unmanaged package so just leave the current option “Unmanaged” selected and click Export button.
a.      You will now be prompted to save the file. Just save it to the desktop of the CRM server.
10.   Go to the desktop of the CRM server and open the newly created zip file titled
a.      Extract the file customizations.xml.
b.      Open the customization.xml file with an XML editor.
11.   Press Ctrl+F and search for the string EmailAddress1.
a.      Under EmailAddress1 locate the element “<Format>text</Format>”.
b.      Within in the element change the word text to email. Save and close the file.
12.   Now place the modified customization.xml file back into the zipped solution
13.   Back in CRM Solutions click the Import button.
14.   Browse to the location of the Solution file and then click next.
15.   Click Next to import the Solution.
Update the EmailSearch view:

One way to go about updating this view is to "touch" the email for all contact records. For example, you could do this by creating a workflow that copies the email to a temporary field and then in a subsequent step copies it back. You could then apply this workflow to all your contact records.

If your contact database is large the above approach might not be practical and you may want to use a script instead. Below is a script that can be used to update emailaddress1 on the contact record. This script is not supported so please use and update at your own discretion.

DECLARE @id              uniqueidentifier
DECLARE @email         nvarchar(100)
DECLARE @entitycode    int = 2   -- Contact
DECLARE @columnnumber  int = 42  -- Email Address 1 (45 for emailaddress2, 47 for emailaddress3)


        declare DetailCursor cursor for
                  select contactid, EMailAddress1
                  from Contact
                  where emailaddress1 is not null
                  and ContactId not in (
                  select ParentObjectId
                  from EmailSearchbase
                  where ParentObjectTypeCode = @entitycode

        open DetailCursor
        fetch DetailCursor into @id, @email

        while @@fetch_status = 0

              insert into EmailSearchBase (EmailSearchId, EmailAddress, ParentObjectId, ParentObjectTypeCode, EmailColumnNumber)
              values (newid(), @email, @id, @entitycode, @columnnumber)

          fetch DetailCursor into @id, @email

        end --while
        close DetailCursor
        deallocate DetailCursor


Friday, November 25, 2011

Microsoft CRM 2011 Track vs. Set Regarding

The question often arises in product demonstrations and when engaging with new clients as to the distinction between the "Track" vs. "Set Regarding" options for promoting emails to CRM (or any other type of activity for that matter i.e. appointments and tasks).

The short and obvious answer is of course that "Track" is a quick way to just promote the email into CRM without further classification (it can of course be classified later); whereas "Set Regarding" not only promotes the email to CRM but also classifies it to the appropriate account, contact, opportunity, case etc. at the same time.

As it is unlikely (in the real world that is) that an individual would later go and reclassify something that was promoted earlier, it is generally best practice to use the "Set Regarding" option to classify immediately so as to satisfy the "if-not-now, when?" dictum. And given that the CRM 2011 Outlook Client has now made it that much easier to use the "Set Regarding" option by maintaining a "recent" list of associated entities (see screenshot above) chances are that the time required to click Set Regarding vs. the single-click Track option is going to be anyway minimal, thereby reinforcing the aforementioned general best practice.

However what if I just want to promote and classify an email to the contact that sent me the email? It seems kind of silly to have classify the email to the contact that sent me the email by using "Set Regarding" since the email already is implicitly classified by the "From" email address that it was sent from (or "To", "Cc", "Bcc"). Shouldn't it auto-classify and not require me to reclassify again by using the "Set Regarding"? That would just seem like common sense, wouldn't it?

And fortunately the answer is that this is not only common sense but also how CRM will actually handle it. To understand, let's first analyze how CRM handles the email distribution list. It is important to note that the handling of the email distribution list is the same regardless of whether you use the "Track" or "Set Regarding" option so the next paragraph applies to both techniques.

In a nutshell, CRM will try and auto-resolve all the contacts on the email distribution list to a CRM contact, or user record. This is best illustrated by viewing it in the Microsoft Dynamics CRM panel below the email and also in the CRM email record itself after having click "View in CRM"

Microsoft Dynamics CRM Panel

View in CRM

If CRM, cannot resolve a contact from the distribution list, it will show as unresolved - but that is a topic for another time.

If CRM is able to successfully resolve the email to a contact record, the email will then appear in all the resolved contacts "Closed Activities".

Not only that, the email will also appear in parent "related regarding" roll-up views.

To re-iterate, all the above is performed as part of email resolution process regardless of whether you elected to use "Track" or "Set Regarding". Which therefore means that had you just used the "Track" option for the email, you still are able to have it be associated with the appropriate contact and parent account.

Therefore for emails (appointments and tasks) if your only requirement is to track the email to the corresponding contact record in CRM then selecting "Track" should be sufficient (assuming the contact exists - there are also options for auto-creating the contact if not, but that again is a topic for another discussion). In this scenario, using the "Set Regarding" is arguably redundant. However if you wanted to related the email to some other "less obvious" entity (case, opportunity, etc.), then you obviously would need to make use of the "Set Regarding" feature as per the aforementioned best practice.

Wednesday, November 16, 2011

CRM 2011 Update Rollup 5 form issues

As mentioned previously, CRM 2011 Update Rollup 5 in particular introduces some nice new improvements/enhancements. But also as mentioned this rollup cannot be uninstalled. Or technically it can be uninstalled by essentially uninstalling CRM 2011, restoring a database backup and re-installing CRM 2011 again along with the previous rollups to get back to where you started...

So knowing that this is the case, I came across a perplexing issue which appears to have been introduced by Update Rollup 5 that caused a form to no longer render correctly. The end result was that I was receiving the fairly generic "Error on page" message and as indicated in a former post on the topic, the error seemed to occur even when jscript was disabled. And so - using the same process of elimination technique described in that post - I went about removing snippets of jscript until the root cause of the issue was discovered.

The issue came down to the application ribbon EnableRules in the particular case where the EnableRule references a custom function within the form jscript (as described here).This didn't really seem to make any sense but it was evidently the case as every time the function was removed, the form error went away and vice versa. Delving a little deeper it was determined that if the function was left in but one of the form global variables that was referenced was commented out, the form would once again render properly.

So the conclusion that was reached was as follows:

  • Before rollup 5 it appears the form onload script was executed prior to executing the custom EnableRules functions defined in the application ribbon. This allowed for global form variables to be declared that a custom EnableRule jscript function could then reference.
  • Post rollup 5 it appears that the load order was altered such that the form onload script no longer executes prior to the execution of application ribbon EnableRules functions. This means that any global variables referenced in a custom EnableRule jscript function are undefined and will result in the form error described above.

That's at least what I deduced from the behavior that I observed. This issue was reported to Microsoft but rather than waiting for a resolution (which could take a while) or trying to painstakingly revert to a previous rollup, I implemented a workaround solution which was to essentially do away with the form global variable and rather recalculate the value in the EnableRule custom function itself. Once implemented in this way, the form was happy again.

Needless to say the above issue was perplexing indeed - you know the feeling - where you start second guessing your own sanity... So if you encounter such behavior after installing the above rollup, you may want to look into this as one of the potential reasons for the strange form behavior.

Tuesday, November 15, 2011

CRM 2011 Document Management Settings: Based on Entity Pros/Cons

It's been a little while but in a former post we were discussing the various configuration options that we have available when configuring the out of the box SharePoint integration with CRM 2011. And in particular, we were reviewing the impact that the "based on entity" setting has on how the content is physically stored in  SharePoint. Or as I termed it - "the centricity of storage".

I had also mentioned that we'd review the pros and cons of these configuration options and in this post I'd like to make good on that promise. In particular, I'd like to focus on the pros/cons of setting the "based on entity" to  Account or Contact. For the sake of discussion, we'll assume the Account-centric setting.

The benefit of this approach is that the content is a little bit more organized. That is, the structure of the content mirrors the structure of the customer organization and therefore it seems more logically organized to a certain extent. For example, if you had a customer portal that exposes customer documentation, it would be sufficient to link it at the account level and the remaining levels would just “follow suit”.

The main downside of this approach is that it can become more disorganized over time. Some of the contributing factors to this might be:

  • Documents can be stored in different paths depending on the “characteristics” of the entity in question. For example, a contact with an account will be stored in the “..\account\SolarTech\Joe Bloggs” location, whereas a contact without a parent account will be stored in the “..\account\Joe Bloggs” location (as there is no account reference). This is perhaps the most unsettling factor as you want order to your data so that you can follow a logical predefined path for storing and retrieving data rather than having two different navigation systems depending on the nature of your data. This issue might be mitigated if the nature of the entity is such that it would always have a parent. For example, contacts in CRM could very well be parented or un-parented leading to the issue described. However opportunities should always have a parent and therefore is less prone to this type of disorganization.

  • The relationship structure can change. For example (using the illustration provided in my former post), Joe Bloggs might at some point leave SolarTech and join ABC Corp. This is ok, but CRM is not yet smart enough to detect this change in relationship structure and it will be up to a diligent user (which is wishful thinking at best) to change the location under the contact rather than continuing to add content which will inevitably lead to the wrong documentation appearing under SolarTech.

  • The “oops factor”. This is a variation of the above. That is, what happens if I create a contact, click on the Documents link to create the SharePoint location and then “remember” to associate a parent account to a contact? The result is that I now have the SharePoint location for this contact stored in the wrong path and as a user I need to remember to move this around. It is possible to mitigate this by creating some client side script. For example, we could hide the Documents link until an account is added but there are other scenarios that would be impossible to cover (e.g. initially parenting a contact with the wrong account). 

  • Too many levels. It can also quite easily be argued that the account-centric approach introduces too many levels into the document storage structure, involving too much required navigation etc.

Next: We will need to review the pros/cons of the "individual" path approach and see if we can perhaps bring it all together by driving towards a best practice recommendation.

Friday, November 11, 2011

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
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).

Thursday, November 10, 2011

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.

Wednesday, November 9, 2011

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.

Tuesday, November 8, 2011

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.

Monday, November 7, 2011

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.

Friday, November 4, 2011

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...

Wednesday, August 24, 2011

CRM 2011 Document Management Settings

In my previous post I provided an overview of the CRM/SharePoint integration capability. For a good reference of the detailed steps that are involved with setting the basic integration up, you should refer to this walk through.

In this post, I want to focus on the primary configuration options that are available.When configuring the SharePoint integration in CRM, you have the option to define both of the following (as part of one time set up):

Level of integration

Here you can define for which CRM entities the integration will be set up. For example, you can set it up so that accounts, opportunity and contacts have a link to CRM. As shown in the screenshot below, when I store documentation for the SolarTech account, the documents are stored in the SolarTech account library in SharePoint. If I defined it to also tie in at the contact level, then we would similarly see that documentation can be stored for the Joe Bloggs contact, and would corresponding appear under the Joe Bloggs contact in SharePoint. And so on.

 “Centricity” of storage

The "centricity" can either be centered around account or contact. If you wanted to configure this option, then in a b2b world, you would most likely want to base it off "account"; whereas in a b2c world, it would be based off of "contact". We'll assume b2b for the remainder of this discussion.

Using the account and contact mentioned above as an example and assuming Joe Bloggs is a contact for the SolarTech account. I can either set it up so that whenever I store documentation it will follow the account path or the individual path

At the account level nothing changes, but at the contact level, if I store a document for Joe Blogg, using the account path, the document will be stored in a SharePoint location that looks like:
..\account\SolarTech\contact\Joe Bloggs\Doc2.doc
..\account\SolarTech\contact\Joe Bloggs\Doc3.doc
..\account\SolarTech\contact\Ed Rogers\Doc4.doc

Conversely, if I store a document using the individual path, the document will be stored in a SharePoint location that looks like:

..\contact\Joe Bloggs\Doc2.doc
..\contact\Joe Bloggs\Doc3.doc
..\contact\Ed Rogers\Doc4.doc

In summary, the former approach centralizes the path around the parent account whereas the latter has no correlation to the parent whatsoever. The same would be true for any other entity related to an account (e.g. quotes, opportunities etc.)

In my next posts I will be reviewing the pros and cons of these configuration options that you will want to take into account before making your design decision.

Next: CRM 2011 Document Management Settings: Based on Entity Pros/Cons

CRM 2011/SharePoint Integration Overview

One of the most compelling features for upgrading to CRM 2011 is the tight "out of the box" integration that CRM has with SharePoint 2010. While it was possible to integrate CRM with SharePoint in previous versions, that involved developing a custom solution. Whereas in CRM 2011 the built in integration capabilities offers a nice, clean way of integrating these two applications and provides a great alternative for document management directly through the CRM user interface.

To some extent this integration is the one of the "holy grail" enhancements that we have been eagerly awaiting... for a very long time. The problem has generally been that while CRM has the ability to store documentation in attachments, it is by no means a "document management solution". And trying to leverage CRM as a document management solution is trying to fit a square peg into a round hole. On the flip side, we have this other great technology solution called SharePoint which among multiple other capabilities is a very strong platform for content and document management. So in 4.0 while there were various creative ways of handling the document management conundrum within CRM, they were just that - workarounds...

CRM 2011 is only part of the requirement for this integration solution. You will of course need to have or upgrade to SharePoint 2010 in order to be able to leverage this out of the box capability. SharePoint Foundation 2010 is available freely with the purchase of Windows Server 2008 which should make this option very feasible. Of course, if for whatever reason your organization does not want to use SharePoint 2010 or is not ready to upgrade to that environment, you will need to fall back to one of the creative solutions.

It should also be mentioned that the CRM/SharePoint out of the box integration only offers integration between CRM entities and SharePoint libraries in it's current incarnation. Meaning - it does not currently offer integration between a CRM entity and a SharePoint site. The good thing about integrating at the library level versus the site level is that it does tend to keep things nice and simple. But I can understand that there may be some situations where it would be preferable to connect at the site level and if that's your requirement... well, for now, you're fresh out of luck. At least using the out of the box option that is... As the CRM and SharePoint are in my opinion strategically aligned solutions, I would expect to see the level of this integration to deepen in future versions/upgrades of these products and wouldn't at all be surprised to see an integration at the SharePoint site level at some point. But that is purely based on my subjective view of the world. Time will tell if that prediction pans out.

While the integration between these two solutions is out of the box, there are various options in terms of configuring how this integration can be set up. I will outline these options in follow up posts and suggest some best practice considerations for configuring them.

Next: CRM 2011 Document Management Settings

CRM 4.0 Explorer View

Ever faced the dilemma of knowing where to store/find your documentation? For more advanced document management features, we would recommend a Sharepoint integration methodology (in CRM 2011 it is a no brainer to use the SharePoint integration as that comes out of the box, but if for some reason you do not have SharePoint 2010 - SharePoint Foundation is free so there really should be no reason - you can follow this approach in CRM 2011 too although it will need some adaptation). But for those who have simple needs or have a smaller budget for solving such problems, the Explorer view provides a very simple straight forward solution to this problem. The screenshot below illustrates this concept. Users can navigate and update documentation right from CRM just as they would with Windows Explorer (identical user experience).

The following will step through configuration of the option (you can download referenced files from here):

ASPX Configuration

Create a shared folder root on one of the servers (e.g. \\<server>\CRMFiles). Make sure you grant the necessary access permissions. It is recommended that the root share location be a folder without spaces in the name.

Create a subfolder called "Test" under the root folder:

Open default.aspx and make the following changes (pay close attention to the number and placement of the “\” character):
  • On line 20 update the “src” tag to point to the correct share location (src=\\<server>\CRMFiles\)
  • On line 21 update the “ddf_src” tag to point to the correct share location (ddf_src="\\\server\CRMFiles">)
Copy the modified file from above to the \crmweb\ISV\Sentri\Explorer location on the CRM server:

Test the above by trying to connecting to your test folder:
If you do not get an explorer view returned similar to the above, you have made a mistake in the deployment steps – please review the steps until you get a successful explorer view returned.

CRM Entity Configuration

On the CRM entity where you wish to configure the Explorer to appear you will need to make the following changes.

Add an IFrame to the form with a name of IFRAME_DOCS (note this name can be anything but it must match the jscript code – see later in this document).  The recommended settings are shown in the screenshots below.

Open onload.js and make the following changes:
  • On line 5 update the logic for setting the folder name as necessary (see configuration section for more about this)
  • On line 6 update the share location (var netshare = "\\\\server\\CRMFiles\\";)
  • On line 7 ensure the url points to the correct path (should be if you followed the deployment instructions above)
Copy the onload.js into the form load event – you will need to ensure that the “fileshare()” function is called from somewhere in the onload jscript.


In above implementation, there will need to be folder names under the share root matching the account name (assuming the jscript in  loaded in the account form). This of course can be modified as necessary to suit implementation requirements.

Thursday, August 11, 2011

Reassigning personal views for disabled CRM users

The ability to share personal views in CRM with other users in CRM is a powerful tool. It allows for a central admin users to create or assist other users with creating views and thereafter they can be assigned to individual users or to a group of users. When sharing these views the user has the ability to limit the permissions on the shared views. For example, you may want to share a view but prevent the users who this view has been shared with from deleting the view. That can make sense especially in cases where the shared view is shared amongst a group of users and you do not want to give any individual user the arbitrary opportunity to accidentally or intentionally delete that view and inadvertently have that action ripple across the organization.

This all works very nicely... until the power user who has assigned all his/her views to other users leaves the organization and you want to manipulate these shared views in cases where that manipulation (write, delete, share to others) has been limited. One obvious solution is to have the IT admin temporarily update the AD credentials for this user so you can log into CRM as this user and re-assign the views to a new power user.

But the above action is not always an option. And fortunately there is another better option. Enter the Microsoft CRM 4.0 Administration Console. This console has a number of useful functions including tools for managing security roles but we are just going to focus on the ability to copy personal views for the specific scenario mentioned in this write up.

Below are the steps to copy the personal views:

  • Download the console from codeplex
  • Launch and enter the credentials and select the "Manage Views" utility

  • In the ensuing form, first select "Get Users/Clear Cache". You can click just click Ok to select all users in the organization or you can filter by Business Unit

  • Then perform the following steps to assign views from one user to another user
    • In View Types ensure only "Main Application View (MAV)" view and "- Filter Active Views" are selected
    • Right Column: Select the user you wish to assign from
    • Middle Column: Select the view or views you wish to assign (use Ctrl and Shift for multi-select)
    • Right Column: Select the user or users you wish to assign the views to (use Ctrl and Shift for multi-select)
    • Click "Activate Views for Selected Users" and Confirm

Thursday, August 4, 2011

CRM 2011 Double Click Event

In a former post I provided a function for adding "onclick" events using jscript. You may however ask: "What about double click events?". Well if you did, the answer is a slight variation of the function provided for the "onclick" event. That is:

function RegisterOnDoubleClickEvent(attr, fn) {
    var e = document.getElementById(attr);
    var f = "var doubleclick=function() { " +
              fn + "(); " +
                  " };";


    // Attach to double click event 
    e.attachEvent("ondblclick", doubleclick, false);

Thereafter all you need to do to register an OnDoubleClick event is to pass the following function call:

RegisterOnDoubleClickEvent("attribname", "functionname");

CRM 2011 Contact Image alternative approach

In light of my former post about options for embedding a contact image (or for that matter embedding any other type of image into a CRM form), I thought I'd highlight another, perhaps better, approach.

The former approach is a more centralized/controlled way of adding images and it dictates that the image file being added adhere to a certain given format (e.g. in order to point to the Bob Jones image when opening the Bob Jones form, I need to ensure that I have a "BobJones.gif" file on the server or perhaps "" or some other derivation from the contact record so that I can link to the file when the form loads). Therefore adding images using this approach would presumably be given to an administrator user rather than being "democratized".

The other approach is to utilize the SilverLight control that can be found in codeplex. Kudos is also obviously due to the creator of this little add on.

Using this utility, any user can add an image to the contact form and the image is simply stored as an image in the Notes of the contact. A more decentralized approach and indeed a very slick alternative!

CRM 2011 Check if URL/file exists

We had a requirement to display a contact image along with the contact record in CRM. There are ample examples of how to go about doing this by either using a file on the server or a web resource. The following is a jscript snippet of how to go about adding an image referencing a file on the server (in this case the file should be placed in a ContactPics folder under the ISV folder. This could very easily be adapted to point to an image added as a web resource which is probably a better approach for CRM 2011.

function ContactPic(filename) {
    var picIframe = Xrm.Page.getControl("IFRAME_Pic");
    var src = picIframe.getSrc();
    var url = server + "/isv/ContactPics/" + filename;

The result should be something like this:

But what happens if the file does not exist neither as a web resource nor as a file on the server? In that case, it would be preferable to present a "No Image" default image or perhaps to hide the image altogether rather than showing a broken link. The challenge though is how do you detect that the link is broken in order to do so? Jscript does not allow you to interact with files on the server (due to security considerations) so performing a simple "file exists" check is not as simple as it might first seem.

The solution that I found to this issue was to detect a 404 error via a http request of the URL. As follows:

function UrlExists(url) {
    var http = new XMLHttpRequest();"HEAD", url, false);
    return http.status != 404;

And now the ContactPic function can be updated to first test the URL and if it is broken to replace it with a default NoPic.gif image.

function ContactPic(filename) {
    var picIframe = Xrm.Page.getControl("IFRAME_Pic");
    var src = picIframe.getSrc();
    var url = server + "/isv/ContactPics/" + filename;
    if (!(UrlExists(url)))
        url = server + "/isv/ContactPics/NoPic.gif";