Twitter Image

Dynamics CRM Outlook Client Thresholds files for Performance Analysis of Logs (PAL) Tool

Thursday, 03 July 2014 13:13

After the release of the Dynamics CRM Threshold files a short while ago, someone asked me to do the same for the Outlook client, so here it is.

You can download the Threshold files from here; it contains all performance counters for the outlook client and alerts for failed transactions.
I couldn't find Microsoft recommendations for transactions performance so you would have to run it on some workstations first to have a good baseline for performance alerting.

For installation and usage; please read the CRM server threshold files article.


CRM 2013 versions and branches

Tuesday, 10 June 2014 09:28
In the recent days, I heard quite a bit of confusion about the current CRM 2013 versions; so I will try to clarify it in the easiest way.
There's currently two branches of CRM 2013, the RTM and the SP1; both with their rollup plans as per the following schema  
We don't know how much time the RTM branch will be maintained, but I presume not very long. 
nb: If you want more information on the different rollup versions, here's the link to the PFE Team article.
ps: Thanks to Gunther Pieters, our Services Account Manager who chased some of that information for us 

Dynamics CRM 2013, Thresholds files for Performance Analysis of Log (PAL) Tool

Tuesday, 29 April 2014 10:27

Last week, while following a Performance training at Microsoft by Gonçalo Antunes; we had some hands on using the Performance Analysis of Logs (PAL) Tool.
It's a very nice tool but unfortunately, no template existed for Dynamics CRM.

This was a bit disappointing, so based on some knowledge built for the CRM Extreme Monitoring session I presented some months ago in Barcelona, I went to implement a first draft of the threshold files.
Those are basic thresholds, more oriented towards health than performance; but you still get quite a few of thresholds as MSDx CRM is more than generous in failure counters.

I first thought of making a file for every CRM server roles; but that would leads to a lot of files and furthermore; the counters are not that easy to split per role.
There're currently 3 files; one for front-end, one for back-end and a full server role (which inherits from the other two); you will also need to add the sql server threshold file if needed (IIS,, etc.. are already inherited) as it depends on the SQL Server version.
I would be more than happy to get feedback when some of you use PAL in real world audits; so it can be extended and improved over time.

So, how does it works ?
First, download and install the PAL Tool from codeplex.
Then, download the following file; unzip it and copy it into the PAL directory (ie: c:\program files\pal)
You can then start the PALWizard; and you should be able to see the Dynamics CRM threshold files in the selection list.

 From then, you can use the PAL tool the usual way.
In short: 

  • Select the Threshold files
  • Click "export to perfmon template file" and save the template
  • Start Perfmon
  • Go to Data Collector Set, Create New Data Collector Set, Create from a Template and select the template
  • Schedule the collection or start it directly
  • When the collection is complete, you should get a blg file
  • Restart the PALWizard
  • Select the collection file
  • Re-select the Threshold file; answers some questions and next...
  • This would generate the report.

There's a lot more options but I would refer you to the PAL codeplex site for more information.
Below is a sample of the charts generated, and here're some samples reports : Report 1Report 2.

The Lobster experience or the danger of the bulk delete

Thursday, 13 March 2014 10:53

One of my customer got a daunting experience the other day; similar to the way a lobster may feel the sudden drop in boiling water.

Bulk delete right is usually very restricted, but the culprit was a full power user with all rights and was confused by the way the interface displays the bulk delete options.

Let's look at an example, here's the view of contacts associated with a given account; as you can see (the orange circle), there's no contact record associated with that account. 

Now let's click on the Bulk Delete button, you may believe this would only applies on the associated contacts of that account (even if the criteria does not displays it)

Now Let's click on Preview Records; this will actually delete all active contacts (not only the one of that account)


In that particular case, the user had some hundreds of associated records and thought he found a nice way to 'bulk delete' them but he actually triggered a system wide delete including the cascading records. It took him a couple minutes to realize it and get the sudden "lobster experience". We ended up restoring a database backup as thousands and thousands of records where already gone (bulk delete is quite efficient). 

Even if  I think the associated view bulk delete button behavior is quite misleading in terms of user experience, the moral of the story is beware of the bulk delete rights; be sure the users understand the true implications of it (or face the lobster effect..)

On Implicit sharing, team ownership and reparenting

Friday, 20 December 2013 08:42
MSCRM 2011 introduced the notion of team ownership and it's more and more used as the base paradigm for implementing the security model 
However, there's a not well known hidden effect of using team ownership which is called implicit sharing.

When a record is linked to another via a cascading relationship, if the reparenting option is set and if the owner of the parent record is not the owner of the child record, an automatic sharing record will be created.
A typical case is activities linked via the regarding field as the OOB default relationship is parental, so with a full cascade.

Let's take an example where we have an account which is team owned and create a task which is user owned (a quite typical scenario)

If now we look in the PrincipalObjectAccess table, you can see a new record is created which shares the Task record with the Team owning the account.
This happens even if the owner is member of the owning team.

Note that the AccessRightMask field is 0, which is the reason why the sharing window of the task don't show you any sharing, the actual rights are to be found in the field InheritedAccessRightsMask

This behavior may be what you want, but in lot of cases it just add extra records in the POA table and we all know this impact performance in a (very) bad way.
The good news, it's quite easy to remove that behavior, just change the cascading relationship between the involved entities.
In that case, we adapt the parental relationship from account to task by changing the reparenting cascade setting.

If we now remake the same test, no record is created in the POA table.
Here's the results of a test where test1 and test 3 had cascading reparenting ans test 2 add none.

The conclusion is that the OOB default relationship cascade setting, especially relating to activities, should not be taken as granted and should be always reviewed at design time.
nb:There's also a Post CRM2011 UR11 organization setting called  DisableImplicitSharingOfCommunicationActivities which could be helpful in that situation.
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
Page 1 of 21