All posts by David Wise

One .Master to Rule Them All (Two, actually)

One of the biggest annoyances with Sharepoint 2007 is the quirky things you have to do in order to customize a site.  This is especially true when it comes to custom master pages.  You create a stunning master page in Designer, configure the site to use it, then load the page and wait to bask in the glory. Lo and Behold!  It worked!  Job done, go grab a beer … but you better drink it fast because Sharepoint has a nasty surprise in store for you.  That master page only works on the content pages in your site.  System pages  (i.e. viewlists.aspx) will refuse to use your amazing Master page.  All that work is wasted on a half complete user experience.  Or is it?

Why is it not doing what I tell it to do?
This is because those system pages are hard-wired to use a different master page (application.master) .  To make matters worse, you only get one application.master for everywhere.  You could go modify this file, but be careful: changes to this will affect ALL pages based on that master, everywhere.   It’s not something that can be customized on a site-by-site basis.  To make matters still worse, Microsoft *will* update this file in upcoming patches, so odds are good that it will break on you sometime in the future, and likely with little warning.

Ok, so what’s the skinny?
Create a custom httpModule and install it on your Sharepoint site that remaps which .Master pages your pages use.  If you aren’t familiar with httpModules, fear not, they are extremely simple.

The httpModule sits in the middle of the http request processing stream and can intercept page events when they initialize.  The pages load up and say “I’m going to use application.master”, to which your module replies “not on my watch, buddy” and not so gently forces the page to use the Master page of your choice.

The Gory Details
(this assumes that you already have the aforementioned Nifty Master Page created.  If not, please search Google for any of the hundreds of tutorials on how to do this)

Prepare your Master Pages
You will need two .Master pages.  One to replace default.master and the other to replace application.master.  It is very important that when you are creating these pages that you include all of the ContentPlaceHolders that exist in the .Master page you are replacing.    Throw any ContentPlaceHolders that you are not using in a hidden DIV at the bottom of the page – but before the closing FORM tag (the only exception to this seems to be “PlaceHolderUtilityContent” which goes in after the closing form tag).  Once in place, you can use the normal Master Page options in the UI to select the default.master replacement.

Second, be sure to remove the Search Control from your Application.Master replacement.  The reason for this is that the search box does not normally appear on system pages and will cause an error during rendering.

You can probably simplify this a bit by using nested master pages, but I haven’t had a chance to look into that yet.

Step 1 – Create the httpModule
Create a new Class Library project in Visual Studio and start with the code below.  So simple, even a manager could do it (maybe).  Obviously, you will have to change the path to match your environment.  Oh, and sign the assembly as well.

using System;
using System.Web;
using System.Web.UI;
using System.IO;
public class MasterPageModule : IHttpModule
public void Init(HttpApplication context)
context.PreRequestHandlerExecute += new EventHandler(context_PreRequestHandlerExecute);
void context_PreRequestHandlerExecute(object sender, EventArgs e)
Page page = HttpContext.Current.CurrentHandler as Page;
if (page != null)
page.PreInit += new EventHandler(page_PreInit);
void page_PreInit(object sender, EventArgs e)
Page page = sender as Page;
if (page != null)
// Is there a master page defined?
if (page.MasterPageFile != null)
// only change the application.master files as those are the offenders
if (page.MasterPageFile.Contains(“application.master”))
page.MasterPageFile =/_catalogs/masterpage/MyCustom.master”;
public void Dispose()

Note the path above: that is required so that all pages can find the Master page as not all pages are running from the site context

This is a simplified example but you can see the potential here.  With this in place, YOU control the horizontal and YOU control the vertical.  Or, for a more modern reference, YOU decide who gets the red pill and who gets the blue pill.

Build it and then throw the DLL in the /bin folder in your SharePoint site root (usually something like InetpubwwwrootwssVirtualDirectories80in).  You may have to create the in folder if one is not there.  Once you have it working the way you want, you will need to sign it and move it to the GAC, but this works for getting started.

Step 2 – Register the httpModule
Another easy step – throw in the bolded line below in your web.config file at the bottom of the httpModules section.  This section should already be there.

… stuff you dont care about …
<addname=“MyHandlerTest“type=“MasterPageModule, MasterPageHandlerModule, Version=, Culture=neutral, PublicKeyToken=6bdb1331dfc11306“/>

Step 3 – Load the Page
Navigate to the home page of your site.  That should work normal as it is using the normal Sharepoint Master page logic.  Now go to a System page, like ‘Documents’ , ‘Lists’ or ‘Pictures’.  These should now be using your Master page

If you’ve followed the this tip you will actually be able to see the real error, if any, when you load the page.

Step 4 – Go get that beer
Do you really need instructions for this?

Special  thanks to K. Scott Allen for his post showing how to change the .Master page using an httpModule.  You will notice that the code above bears an amazing resemblance to his.

3/1/2007 – UPDATE!
In response to comments, I have updated these instructions, in particular, I have added the “Prepare your Master Pages” section that addresses most of the issues encountered in the comments.

Also, do not use this method if your SharePoint install has the shared Service Provider (SSP) installed on the same web application as your main SharePoint environment.  The system pages used by the SSP do not work properly when their master page is replaced like this.  I’m sure there is a logical reason why, I simply haven’t had the time to dive into it.

HowTo: Filter a View based on Workflow Status

One of the known issues with SharePoint 2007 is the inability/quirkiness of filtering a view based on the status of a workflow field. While this is a pain, there is an easy workaround. Simply create the filter and tell it to look for the integer representation of the status value you are looking for, like this:

This will create a filter that returns all “Approved” items. The codes are:

Status Value
Not Started 0
Failed on Start 1
In Progress 2
Error Occurred 3
Canceled 4
Completed 5
Failed on Start (retrying) 6
Error Occurred (retrying) 7
Canceled 15 * This is defined but I don’t think this value is used
Approved 16
Rejected 17


12/19/2007 Update: Filled in list of values using the actual values found in the field definition itself.

5/28/2008 Update: Hit by a flash of the blindingly obvious. If you put the status fields on a view, then view that in the Datasheet mode, it shows you the integer values. I don’t know why I hadn’t seen this before ….

How to update a single status column when using multiple workflows

The canned workflows are powerful enough as is, but what happens if you really need to use them, but are in a situation that is just a little beyond their ability?  There are ways to augment them slightly without having to re-create the whole workflow from scratch.  Below is just one example.

This overall situation is pretty unique, but parts of it should be familiar to anyone who has done very much with the canned workflows.  Hopefully this may provide another option for those of you beating your heads against similar issues.

Here’s my scenario:

The main problem:  A single list item can be subject to dozens of different workflows, which are all variations on the canned Approval flow but with different lists of approvers.  Reports need to be generated so that a single report will show all items that are in a given state regardless of which flow it is in. Views like this are almost impossible out of the box with this many possible workflows.

The second problem: The current status needs to be visible in lists.  However, the text of the status needed by the client is different than that defined in the workflow.

The third problem:  The same workflow needs to run multiple times on the same item, but will result in a different status upon completion.  The reason is that there is often a gap of weeks or months between the completion o the first workflow (feasibility) and that of the second (manufacture).  During this time, things may have changed that make the product no longer feasible, so it has to go through the same people again to make sure that it can still be done.  If so, the completed status becomes “Authorized”.

The solutions
At first glance, it looks like you could take the hardline approach and create dozens, if not hundreds, of custom views, each tailored to the workflow needed.  While this is doable, it doesn’t address the second and third problems.  It also sets up a maintenance nightmare.

The first problem was solved by the fact that all workflows in my situation are started by my WebPart rather than using the Automatic or Manual options.  When the WebPart starts a workflow, the code determines the prope workflow to launch based on form data.  It then copies that workflow’s EventData and starts a single workflow using that data. 

The second problem proved much more difficult to conquer, but this solution manages to not only take case of the second one, but the third problem as well

EventHandlers to the rescue!
The solution was to create an EventHandler and attach it to the ItemAdded event of the list that the workflows put their history into.  In my case, all history goes into a single list so that part was simplified.

Create the handler
A basic EventHandler is one of the simplest things to create.  I’ve attached the code for my handler at the bottom of this post that illustrates getting the workflow status and updating the proper Item

Binding the Handler
In order for the handler to be called, it has to be registered in SharePoint in some way.  There are actually two ways to do this, but I found this to be easiest Please note that if you do use this method to bind your handler, it only needs to be run once.  There is no need to rerun it after you rebuild the EventHandler.

The other way is listed in the second link above and involves creating it as a feature.  This just seemed like overkill for such a simple thing.

Wave Magic Wand
Determining the state of the workflow actually requires checking two places.  The first place is the InternalState property of the workflow to determine if it running or errored out but it will not tell you if the item was Approved or Rejected, only that the workflow completed.  That’s a good start, but how do I find out Approved/Rejected?

Fear not!  With a little searching, you can get hold of the Workflow which has a handy Xml property that holds all sorts of juicy nuggets of information.  The one of interest here is the Status1 attribute as that is the keeper of the desired status.   A Status1 of 17 is Rejected, 16 is Approved.   (I’m sure that there are constants or an enum somewhere that maps to this, but I was unable to find it)

With this tidbit of Information, I can now immediately update my single Status field with the text that the customer needs to see.  With this field now populated according to the proper workflow, I can create one set of views that all key off of the one single field.  Nice and easy.

What’s that you say?  Why not just look for the status in the field associated with the workflow in the ListItem?  This is a fine question indeed and one to which the only proper answer is 8.  The only value that is ever in that field is 8, regardless of Approve/Rejected status.  I’m assuming that 8 means Workflow Completed which, while informative and accurate, is of almost no use whatsoever.

The code that is attached demonstrates how to get to the actual status.

How to conditionally start different workflows yet retain a single status field

I have a situation where a single item in a list can have any one of literally dozens of possible workflows running against it.  Creating views against this is next to impossible as you have to account for all the various status fields that can be involved.  Even the simplest request becomes a nightmare.

Let me explain by example: let’s say a particular list item can have three possible workflows: Approve Lease, Approve Purchase, and Approve Loan.  These flows need to go to completely different groups of people in order to get approved so I naturally create three instances of the Approval workflow with the proper people assigned to each.

A user then enters a new request into the system using my custom WebPart.  In that request is a dropdown with three options: “Buy, Borrow, Lease”.  Based on this value, my WebPart determines the proper workflow and starts it.  Sort of – more on this in a bit.

With no customization, I would have to create a view for each workflow: Rejected Purchases, Rejected Loans, Rejected Leases and would have to create three more for In Process as well as three more for Approved.  Nine views and we haven’t even gotten started yet!  As I mentioned, in my real-world problem, an item can have dozens of possible workflows, so this list of views becomes overwhelming quickly.  In addition, it is unnecessarily complex to determine the answer to a simple request : display all rejected items.  In the above example, I would have to create yet another view and filter it where each workflow status field is Rejected.

What I actually end up doing is much simpler.  I have a special purpose workflow created based on the Approval Template called “Current Workflow”.  The WebPart grabs the proper workflow based on the dropdown value, copies the EventData (this is the stuff that differs between workflows based on the same template) and uses it when starting the “Current Workflow”.  Thus, all workflow activity limits its updates to the one status field for Current Workflow.

The net result is that now I can initiate the proper workflow and all of my views can use the status in the “Current Workflow” field to make their determination for approval / rejected.  Going back to the example, I’ve cut the number of views from the initial 10 to 3.  I can add any number of additional workflows and I will still only have three views needed.

Workflow Errors: Getting to the Real Message

Troubleshooting SharePoint workflow errors can be a real pain because the extent of your feedback is "Error in Workflow".  That's it.  Nothing in the event log, nothing in the page source and nothing useful in the Workflow history.  However, there is a way to get more detailed information about exactly what happened.

To get the real dirt on the error, you need to enable Diagnostic Logging so that it will write all the details about the error to a log in 12/LOGS.  Go to Central Admin -> Operations -> Diagnostic logging -> Event Throttling.  There you will be able to set how much information you want logged.  There is a tiny catch here though in that you can only change one setting at a time, so set the "Workflow Features" category as shown below and click OK

Now go back in and set the values for "Workflow Infrastructure" and click OK

Then run whatever process allows you to replicate the error.  Quickly jump into the 12/LOGS folder on the SharePoint server, and open the most recent log file.  The actual workflow error should now be visible towards the bottom of the log.