The request uses too many resources

I currently work in a project where the solution is hosted in SharePoint Online and Azure. All communication between the web applications in Azure and SharePoint Online is done with the client object model. Before the summer vacation everything was working just fine. When we came back a couple of weeks later nothing worked. Our applications got a lot of "Ther request uses too many resources" responses from SharePoint Online. After getting past the first line support at Microsoft we eventually got to speak to someone who actually knew what they were talking about. We found out that Microsoft lowered the limit for operations in an execute query call during the summer without notifying anyone. The limit is controlled by the property ClientCallableSettings, see http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.clientcallablesettings.aspx. Since that kind of properties are untouchable in SharePoint Online we had to add several execute query calls on strategic places throughout our code.

Yet another day in SharePoint paradise...

Thumbnail view does not work with jQuery

I started using the thumnail view on a site that I was building for a customer. All of a sudden my jQuery script stopped working, but just on the thumbnail view page. After some digging I found that the thumbnail view resets the meaning of $, which is essential in writing jQuery scripts. Thanks a lot Microsoft!

The solution is to wrap all your jQuery scripts with the following function definition:

(function ($) {

    // Your custom jQuery code

})(jQuery);

This will work for your own scripts, but if you have imported third party script libraries that does not wrap their code properly, they will fail.

Yet another day in SharePoint paradise...

RichTextField require RichImageField

Usually when you create page layouts you always have image fields on your page. Recently I created a page with just one RichTextField. The problem was that the RichTextField did not render properly. It rendered just as an ordinary FieldValue in a ms-formfieldvaluecontainer. After some extensive trial and error I found out that RichTextField required at least one RichImageField somewhere in the page layout to work properly. Apparently the RichImageField adds stuff that also is needed for RichTextField. So my solution was just to add a RichImageField for the PublishingRollupImage field, which is a field inherited from the Page content type that you never use anyway, in an empty div with display none and the RichTextField was working just fine.

<div style="display:none">
    <PublishingWebControls:RichImageField
        id="ImageFieldSharePointBugFix"
        FieldName="PublishingRollupImage"
        runat="server"/>
</div>

Yet another day in SharePoint paradise...

Overriding application pages

Previously when you wanted to override an application page you deployed your new application page to the Layouts folder, and created a http-module which redirected any requests for the old application page to the new one. This method still works in 2010, but now we also have the method UpdateMappedPage on the SPWebApplication object. This method creates a redirection without the use of a http-module. You simply define which application page you want to override and provide a new url. Sounds sweet, doesn't it? But keep your pants on. You define which application page you want to override with the enum SPCustomPage. This enum has the following values: None, AccessDenied, Confirmation, Error, Login, RequestAccess, Signout and WebDeleted. Thats it. This means that if you want to override any other application page you still have to create a http-module.

Yet another day in SharePoint paradise...

Using SPWebConfigModification

Sometimes you need to add changes to web.config during SharePoint development. This is done by using SPWebConfigModification, see http://msdn.microsoft.com/en-us/library/bb861909.aspx. But there is one very big problem with the functionality of SPWebConfigModification, and that is the ApplyWebConfigModifications method.

If you use Microsoft's example in a feature receiver, which you probably would want to do, the method ApplyWebConfigModifications will, as the comment clearly describes, reapply all the configuration modifications each time it is called. Yes, ladies and gentlemen, lets read the sentence "Reapply all the configuration modifications" again. This means that if you have configuration modifications in different features and added one, all the other configuration modifications will be written once again to the web.config file. The method ApplyWebConfigModifications does not take in to account that the configuration modifications already exist in the web.config file.

The best solution I have found is not to use SPWebConfigModification at all. Manually changing your web.config files seems to be the best way.

If you still want to use SPWebConfigModification, do not try to be fancy and remove your configuration modifications because that does not work either. It is a bug in SharePoint 2010 and will never be fixed according to this thread http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/a77a3524-775c-4d04-9920-5bc831e5607a/.

Yet another day in SharePoint paradise...

Force an update of Web Analytics

With the service Web Analytics in SharePoint 2010 you can either see statistics reports in Central Administration or retreive information from it to display on your pages. There is one big drawback. The statistics are updated only once a day, and this cannot be changed anywhere in Central Administration. To check what the current settings of your Web Analytics service application, use the following Power Shell command:

PS> Get-SpWebAnalyticsServiceApplication -identity "web analytics service application"

By default the start time of the report consolidation is "Daily at 02:00". It is possible to change the time when the update is made with the following Power Shell command:

PS> Set-SpWebAnalyticsServiceApplication -identity "web analytics service application" -ReportConsolidationStartTime 12

This will change the start time of the report consolidation to "Daily at 12:00". Note that the number, 12 in my example, must be an integer value between 1 and 23. I haven't tried this myself yet, but this should mean that in theory you could write a Power Shell script, or something, that runs every half hour and pushes the start time forward one hour. This should force the report consolidation to run every hour instead of once each day. But to get up to one hour old statistics is usually not good enough, but it's the best you can do with the Web Analytics service. Too bad.

Yet another day in SharePoint paradise...

Profile import in 2010 cannot filter on AD-groups

The other day I was doing some configuring on a brand new SharePoint 2010 farm at a customer. My task was to configure the profile import just as their old SharePoint 2007 farm was configured. Easy peasy...not.

I started the user profile synchronization service, created a new connection to their AD, made the first synchronization and got no profiles at all. Then I remembered that the profile synchronization service account  must have replication directory changes permission. This sounds worse than it actually is and is fixed by following this TechNet article, http://technet.microsoft.com/en-us/library/hh296982.aspx#RDCdomain. After that the profile database was populated correctly.

Then I just had to create a filter for a handful of AD-groups. In SharePoint 2007 this was done by adding a LDAP-filter to the connection. In the filter you define what should be included/excluded in the synchronization. In SharePoint 2010 this is no longer a valid option. Instead you define one or more exclusion filters. First of all, to limit the filter to just being an exclusion filter is really stupid. The other setback is that it's not possible to filter on AD-groups any more, just AD-parameters! I found this official blog post to confirm this, http://blogs.msdn.com/b/spses/archive/2011/05/31/sharepoint-2010-profile-sync-inability-to-import-users-based-on-group-membership.aspx.

The story ends with a custom profile database clean-up job, which is a story in itself, and a slightly unhappy customer. I find some comfort in the fact that I'm not alone, http://donalconlon.wordpress.com/2011/04/26/fun-with-filters-user-profile-synchronization-somebody-shoot-me-now/.

Yet another day in SharePoint paradise...