Thursday, December 18, 2008

SQL Server 2005 SP3 Offers Performance Improvements for Reporting in SharePoint

SQL Server 2005 Service Pack 3 was recently released and it include performance enhancements for environment running SQL Reporting Services in SharePoint Integrated Mode.
Taken from the "What's New" Section of the SP3 Documentation:

In SharePoint integrated mode, reports typically run slower than the same reports run in native mode. The main cause of this latency can be attributed to SharePoint object model calls that are made. In SQL Server 2005 SP3, the number of SharePoint object model calls that SQL Server 2005 Reporting Services (SSRS) makes are optimized. This optimization reduces some of the latency when you compare report performance with native mode.

Tuesday, December 9, 2008

Keeping your Desktop Icons Ship Shape with Desktop Restore

I like to use Windows Desktop to launch shortcuts to my favorite and most used applications.  I have the icons arranged in a particular way so that I can find and launch them easily.  If you do this yourself or have tried to do this in the past you may have noticed that from time to time Windows will rearrange the desktop icons when the screen resolution is adjusted, certain applications are launched or if the shell restarts unexpectedly.  When this happens it is often a major inconvenience to readjust all of the icons only to have it happen again the next time you attach to a projector or launch a certain game.

Desktop Restore to the rescue.  Desktop Restore is a shell extension that was created by Jamie O'Connell and can be found on his company's web site at  This little beauty makes saving and restoring you desktop icon locations a snap by providing additional menu items when you right-click the desktop.


It supports multiple monitors and multiple layout configurations.  If you like using your desktop to launch your applications and like to have your icons in just the right place I strongly encourage you to checkout Desktop Restore.  I have been using it for a couple years now and think it is a great utility.

Monday, December 1, 2008

Speaking about SPAXO at the Cincinnati SharePoint User Group

I will be speaking at the Cincinnati SharePoint User Group this Thursday, December 4th. I will be giving the dirt on the ins and outs of the SPAXO Feature that Randy Drisgill and I created. If you are in the area and are able to make it, stop by and see how it works! You could also get yourself a copy of one of Shane Young's latest books like Inside SharePoint Administration or Professional Microsoft Search: SharePoint 2007 and Search Server 2008.

Wednesday, November 26, 2008

SharePoint ActiveX Override Module (SPAXO)

No more: "The Web site wants to run the following add-on: 'Name ActiveX Control' from 'Microsoft Corporation'. If you trust the Web site and the add-on and want to allow it to run, click here..."

SPAXO Feature

Today Randy Drisgill (a.k.a The Mossman) and I (along with the help of our fellow SharePoint911'ers) released a SharePoint Feature on CodePlex here that cures the issue that many public facing SharePoint sites have with the "The Web site wants to run the following add-on: 'Name ActiveX Control' from 'Microsoft Corporation'. If you trust the Web site and the add-on and want to allow it to run, click here..." message being displayed on pages rendered in IE.  The issue is described in the following Microsoft KB article and Randy created a solution a while back in the form of a JavaScript file that he originally blogged about here.  A few weeks ago Randy approached me about creating an Http Module that would inject the JavaScript into the response stream in order to alleviate the need to edit Master Pages and so that it could be deployed as a Feature.  As a result the SharePoint ActiveX Override Module or SPAXO for short was born.

SPAXO is a Feature that is scoped at the Web Application level and is implemented as an Http Module.  The Module will inject a script tag in one of two places depending on configuration (this is described in more detail below).  The script tag will look like the one below and by default can be found at the end of a page's source.

<script type="text/javascript" src="/_layouts/SharePoint911.SPAXO/ActiveXOverride.js"></script> 

When the Feature is activated it uses the SPWebConfigModification class (thanks to John Ross for pointing this class out) to add the Module to the httpModules section of the Web Application's web.config file.  While the SPWebConfigModification class is a little difficult to use at times and has a handful of limitations, modifying the web.config in this way ensures that all servers in the Farm are updated and that when new servers are provisioned they will have the latest configuration information available.  NOTE: The Web Application will restart automatically when the Feature is activated or deactivated because the web.config is being modified.  This should not be an issue but it is something to be aware of.

When the Feature is activated the httpModules section of the web.config file should look similar to the following:

Lines have been wrapped for readability
1  <
2    <system.web
3      <httpModules

4        <clear
<add name=
Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, Microsoft.SharePoint, 
7                     Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c
8          ...
9          <add name=
10              type="SharePoint911.SPAXO.ActiveXOverrideModule, SharePoint911.SPAXO, 
Version=, Culture=neutral, PublicKeyToken=c1d151edf9ff2fb3" /> 
12     </httpModules
13   </system.web

14 </configuration>

After the Feature is activated the Module will begin servicing requests immediately and will limit modifications to .aspx pages.  When the Http Module is initialized we register an event handler for the ReleaseRequestState event.  This event fires toward the end of the Http Pipeline and allows us to modify the response in one of two ways.  We can modify the response by appending data to the end of the stream or we can use a Filter Stream to manipulate the data as it is being written to the response.  SPAXO supports both methods and uses the append to the end method as the default.  The Filter Stream option should only be used if you notice problems with the append method or if your company's or client's policies do not allow for it. The Filter Stream option is available by making a manual configuration change (shown below) in the web.config file (we will make it configurable through Central Admin in the next release) and will inject the JavaScript tag into the HTML just before the </HEAD> tag.  If you choose to use the Filter Stream method I would encourage you to test the Feature toughly in a test environment before deploying to a production environment.  The only issue (that I am aware of) that could pose a problem is if you have pages in your environment that have the literal text </HEAD> before the true HTML end head tag.  This could happen if it is referred to in script or comments, so be aware and test before using.

In order to use the Filter Stream method mentioned above you will need to add the following configuration information into the web.config file under the appropriate nodes.  If you would like to switch back and forth between the two methods you can change the value under the setting name InjectJsToHeadSection (line 16) to False.

Lines have been wrapped for readability
1  <?
xml version=
"1.0" encoding="utf-8"?>
2  <configuration>
3    <configSections>
4      <sectionGroup name="applicationSettings" 
type="System.Configuration.ApplicationSettingsGroup, System,
6                          Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
7        <section name="SharePoint911.SPAXO.Properties.Settings"
System.Configuration.ClientSettingsSection, System,
9                       Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089

11     </sectionGroup>
12   </configSections>
13   <applicationSettings>
14     <SharePoint911.SPAXO.Properties.Settings>
15       <setting name="InjectJsToHeadSection" serializeAs="String">
16         <value>True</value>
17       </setting>
18     </SharePoint911.SPAXO.Properties.Settings>
19   </applicationSettings>
20 </configuration>

You may be asking yourself what impact the Module may have on server performance.  That is a great question and one you should ask.  At this point we have not compiled performance statistics but I very confident that the performance impact will be negligible when using the append method of injection (which is the default) and only slightly more than that when using the Filter Stream approach.  The reason the performance will be negligible on the append method is that Module is only making a few basic decisions before appending the data to the stream and in the case of the Filter Stream method it is only making a few more.  Both of these represent an extremely small percentage of what occurs during a typical SharePoint request.  I hope to have performance numbers soon that should back this up.

Let us know your feedback here or on CodePlex (Click Here)