Twitter Image

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.

Manually Reindexing a MSCRM Database

Wednesday, 07 August 2013 09:52

We recently faced an issue where the automatic reindexing job was failing with a timeout 
<MSCRMAsyncService$maintenance. Job Scheduler has executed tasktype=30, organizationid=, starttime=6/08/2013 22:29:22, endtime=6/08/2012 22:40:22 PM, resultcode=1, errormessage=System.Data.SqlClient.SqlException (0x80131904):Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

This timeout at 600sec seems to be hardcoded in the async maintenance service both in the oledb connection and in the stored procedure (the actual statement being executed is p_reindexall 1,600 with 600 the max seconds). After reading this blog article from the Microsoft Dynamics CRM PFE team, it seems the preferred option is to handle this job in an Sql maintenance plan. As this procedure was not yet documented, I thought it would be useful to do it here.

First, start the SQL Server Management Studio and Connect it to the SQL Server instance hosting the Mscrm database you want to Manually Reindex, then Go the SQL Server Agent/Jobs and Right Click to get New Job

Then in the General Tab, Specify the Name of the Job and the Owner (usually the same service account which runs the MSCRMAsync Maintenance Service)

Then Click on Steps..

and specify a name, the actual MSCRM database you want to reindex and enter the following command : exec p_reindexall 1,<Number of seconds for timeout>.
Nb: here's the full list of parameters you can use in this stored procedure

  • AllIndexTypes, Default=0; 0=Clustered Index only, 1=Clustered and Non Clustered indexes
  • MaxRunTime, NO Default;  Maximum allowed running time (in seconds)
  • FragRebuildPct, Default=30;  Percentage of fragmentation at which indexes are rebuilt
  • MinPages, Default=25; Avoid tables less than MinPages amount of pages  
  • Verbose, Default=0; 1=Print progress messages and detailed results

 

Then click on schedules and specify the running times

Go back to the General Tab, verify that the Job is enabled and click OK.

The Last point is that you need to disable the job in the normal MSCRM Async Service Maintenance. To do this, download the CRM 2011 Maintenance Job Editor, install it in your \Program Files\Microsoft Dynamics CRM\Tools directory and start CRM2011JobEditor (note that there's a post UR12 and pre UR12 version). Then select the Organization for which you enabled the manual reindexing, select the "Reindex All" Job and Change the next Run date to something far in the future (ie: 2099)

MSCRM 2011 Critical Update for UR11

Tuesday, 30 July 2013 07:30

On July 27th, Microsoft released the Critical Update for UR11.
What this update contains is all COD updates part of UR12, UR13, UR14 and some fixes from the CRM2013 branch and is intended to be installed when you don't want to install UR12 for compatibility reasons (UR12 being more a minor release than an update)

There're some differences in upgrade paths between server and clients:

For Server 
If you did not install UR11 beforehand, you just need to install the Critical Update as it contains all changes part of UR11. you need to install UR11 beforehand (which itself needs the UR6 codebase) and then apply the CUR11
You can afterward upgrade to the newer rollups (12+),  note that you only need to apply the last rollup, not all intermediates.

For Client
The client needs to be at UR11 level before the Critical Update is applied; so you need to downgrade existing clients that are past UR11; or upgrade existing clients that are pre UR11.
Afterward, the following update to apply would be UR15+, not UR12, UR13 or UR14.

The KB Article can be found here, the direct downlad link here and a very detailled article by the Microsoft Dynamics CRM PFE team can be found here.

Getting the CRM Server Time

Wednesday, 19 June 2013 14:31

I got the query on how to get the current MSCRM server time in order to synchronize some security tokens between applications.
Unfortunately, I couldn't find any API from MSCRM to get this time (ie: Whoami only returns credentials information and the ...LocalTime.. functions only translate a given time from/to UTC), furthermore the solution had to work for CRM online which forbid deploying custom .svc or .asmx endpoints.
As the proposed pattern could be used for other information, I thought it could be useful to explain it here.

We start by creating a new entity "GetSystemInformation" with a datetime attribute

Then we create a plugin registered on the Post Retrieve event of that entity; the purpose of that plugin is to inject the current server time on the fly 

We create a record and when opening it, we can validate the current server time is fetched.

 

Then, we can call the organization web service with the Retrieve Method on that record to get the server time.

 

Note: The Server time depends on where the code actually runs; on CRM Online; you will get the Sandbox server time; not the Organization Server time.

<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
Page 1 of 21