The MSCRM 2011 Update Rollup 8 has been released (warning, this is not the Q2 service update, scheduled for a bit later)
The KB Article can be found here : http://support.microsoft.com/default.aspx?kbid=2600644
and the direct download link here : http://www.microsoft.com/en-us/download/details.aspx?id=29692.
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.
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 ?
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.