Microsoft CRM "du jour"

I had an issue some time ago where a major implementation went haywire (I won't go in too much details, but let's say that when the database cluster start doing ping-pong failover together with the SAN you are in trouble)
While the IT Ops teams were busy trying recovering the cluster, I got a query from the support team who asked if we could put a temporary 'Ouf of Order - Maintenance' web page on the CRM web site so that users could stop hammering the first line support.

As the applications servers were still up and running it seemed to be just a matter to redirect the default MSCRM page to a new page.
The fastest way I knew to do this in asp.net is to create a file called app_offline.htm (containing your Maintenance message) at the root of the web site and all calls will be directed to that web page; unfortunately when trying this method I got a 404 message.
I was a bit puzzled and was thinking an HTTP module was involved but I quickly found the explanation in this blog post.
I didn't want to go the HTTP Module way or changing anything to the existing MSCRM web site files as I wanted to be able to reverse the solution as fast as possible and be sure of the system stability afterwards.
After a quick thought, I decided to create a new clean web site called Offline with a single default page in it on the default port, then changed the Dynamics CRM web site port to another port.
There's some advantages to this solution :

- You can just stop site, change port with IIS manager; so no need to have console access to the application servers
- The CRM Web site is still accessible (on the new port), so you can test that everything is ok before reverting to normal operations
- the 'Offline' web site can be defined beforehand just for this kind of thing.
- If a planified maintenance needs that no user interactions/access is enforced, is quite easy to achieve.

Here's how the configuration now looks like in IIS

I followed a presentation the other day where the Plug-In profiler was mentionned; I remembered having heard briefly about it but never grasped the full significance and usefullness of it.
What this profiler allows you to do is to debug a plug-in in an after the fact fashion, which means Plug-Ins deployed in a online environment can be debugged as well; and this is a lot better than trying to emulate what is happening in a test sandboxed environment on premise.
There's also a limitation in that you need to trigger an exception to catch the log and replay it afterwards, but you could always end normal execution with a throw if you need to.

Basically, what the profiler allows is to simulate a context and run a specic plugin code onto it; this leads to a bunch of other benefits:
- You can iterate very fast codes changes and tests as you don't need to re-deploy,resimulate interaction in Mscrm; you can just replay the saved context on the new code.
- In support, you can capture the context at a customer site (on premise or online) and replay it at will without impact on the customer data (it's the major difference between debugging and replaying)
- You could design unit test validating against a given context.

The MSDN article about the profiler can be found here and a nice step by step blog post by Guru Prasad can be found here.

I got an issue yesterday related to sharing and the Append To right.
Usually, it takes always an extra time to remember exactly what the difference is between Append and Append to, the trick part being to remember that you Append something and you Append it To something else, here's a link to a nice chart about it.

But the issue is that we wanted to use the Append To right in a sharing situation; nothing complex at first sight but see the following screenshot

There's an Append right but no Append To.
My first idea was that Append to right on sharing was not supported but a quick look in the SDK shown that the GrantAccessRequest uses the standard AccessMask and thus supports the AppendTo Right. Here's a code snippet directly from the SDK.

GrantAccessRequest grantAccessRequest = new GrantAccessRequest
{
PrincipalAccess = new PrincipalAccess
{
Principal = new EntityReference(Team.EntityLogicalName, _teamId),
AccessMask = AccessRights.ReadAccess | AccessRights.AppendToAccess
},
Target = new EntityReference(Queue.EntityLogicalName, _queueId)
};

So, why not display it in the sharing window abut only display the Append right ?

Being a bit curious, as always, I went to the Dlg_ aspx page serving the window and from its Javascript you can infer that the window handles Append and Append To in a joined way. In short, when you select Append in the sharing window, both Append and AppendTo rights are given to the record and only when both rights are present, will it show the 'Sharing Append' has flagged. It's really confusing as you can perfectly share only the AppendTo or Append right onto an object with code in a supported way but this shared right will not be displayed in the sharing window...

It is definitely a 'By Design' feature but quite a bit misleading as the cumulative right is only named 'Append' in the window. If anyone would point me on the business reason for this, it would be most helpfull.

Anyway, for this particular issue the solution was to implement a custom workflow activity to handle the sharing of only the AppendTo right, the drawback being that it's not displayed in the standard sharing window; we may end up custom coding a specific screen or report just for this.

Following last week release of the CRM 2011 R7, the SDK has been updated to version 5.0.10.

You can access it directly on MSDN , or downlad the full package.
The list of additions can be found in both places in the Release History section.