Home > Blogs > Eric Shupps | The SharePoint Cowboy > Posts > Tilting at Knowledge Base Windmills
Eric Shupps eshupps The SharePoint Cowboy is the founder and President of BinaryWave, a leading provider of operational intelligence solutions for Microsoft SharePoint. Eric Shupps eshupps The SharePoint Cowboy has worked with SharePoint Products and Technologies since 2001 as a consultant, administrator, architect, developer and trainer. he is an advisory committee member of the Dallas/Ft. Worth SharePoint Community group and participating member of user groups throughout the United Kingdom. Eric Shupps eshupps The SharePoint Cowboy has authored numerous articles on SharePoint, speaks at user group meetings and conferences around the world, and publishes a popular SharePoint blog at http://www.sharepointcowboy.com. Presentations by Eric Shupps eshupps The SharePoint Cowboy Webinar - Migrating Legacy On Premise Solutions to SharePoint Online and Windows Azure featuring Eric Shupps Who are you and what do you want - Working with OAuth in SharePoint 2013 SharePoint is Talking Are You Listening? Eric Shupps SharePoint 2013 Performance Enhancements Taking Advantage of the SharePoint 2013 REST API Eric Shupps on Improving Performance with New Features in SharePoint 2013 SharePoint 2013 New and Improved Migrating Legacy On Premise Solutions to SharePoint Online and Windows Azure Eric Shupps Presents SharePoint 2013 Real World Help Desk App End to End Windows Azure Apps for SharePoint 2013 Eric Shupps Demonstrates Customizing the Visual Studio 2010 SharePoint Deployment Process Introduction to SharePoint Development SharePoint 2010 Unit and Integration Testing with Eric Shupps Building Enterprise Records Management Solutions for SharePoint 2010 Taming Information Chaos in SharePoint 2010 SharePoint 2010 Performance and Capacity Planning Best Practices Building Dynamic Applications with the SharePoint Client Object Model Articles by Eric Shupps eshupps The SharePoint Cowboy Eric Shupps' Ten Steps to Optimize SharePoint Performance Webcasts by Eric Shupps eshupps The SharePoint Cowboy Secrets of SharePoint Part 5: Configuring Microsoft Office SharePoint Server 2007 for Optimal Performance Creating End User SharePoint Solutions for Performance and Scalability SharePoint 2010 Performance Enhancements for Administrators by Eric Shupps Microsoft SharePoint Server 2010 for the ASP.NET Developer Eric Shupps on Following Best Practices and Avoiding Common Errors with Microsoft Office SharePoint Server 2007 Development Eric Shupps - SharePoint Performance and Capacity Planning Essentials Troubleshooting Common Performance Problems in SharePoint 2010 Videos by Eric Shupps eshupps The SharePoint Cowboy Channel 9 Interview with Eric Shupps SharePoint TechTalk with Eric Shupps - Different Views on Social Computing SharePoint Post-Deployment Planning and Management with Eric Shupps SmartTrack for SharePoint Feature Overview SmartTrack for SharePoint Podcasts by Eric Shupps eshupps The SharePoint Cowboy SharePoint Pod Show - Design for Performance (Eric Shupps) SharePoint Pod Show - Test Driven Development with Andrew Woodward and Eric Shupps eshupps The SharePoint Cowboy Run As Radio - Eric Shupps Improves SharePoint Performance
SmartTrack for SharePoint

​The SharePoint Cowboy

photo of  Eric Shupps
611 S. Main St., Suite 400
Grapevine , TX , 76051 USA
October 27
Tilting at Knowledge Base Windmills
I'm probably going to take some flak for this but sometimes you've just gotta stand up and shout when you see officially sanctioned advice that appears to have come right out of left field.  I'm referring to KB944105 - How to customize application pages in the Layouts folder in SharePoint Server 2007 and in Windows SharePoint Services 3.0.  This is a subject that has long been an Achille's Heel for serious branding efforts so when I saw the title I was hoping to finally get some good guidance on how to handle it.  Instead, I find myself shaking my head and wondering just what to make of what I'm reading.
For those of you not familiar with the issue, when you deploy a custom master page in MOSS/WSS v3, the master page is not inherited by the globally-accessible pages in the '_layouts' folder, known collectively as 'Application Pages'.  These pages provide UI elements necessary for the performance of tasks common to every site collection - viewing and creating lists, setting permissions, modifying list settings, adding content types, browsing for users, etc. The reason for this is simple - these pages are used by all site collections and thus cannot be tied to any single site definition style and branding.
The problem, of course, is that here in the real world customers want these pages to look like the site they are accessed from and not the default SharePoint chrome.  And it's not a 'want' it's a resounding 'need' - a must have that is non-negotiable.  An understandable request but one for which we have no effective answer because the master page inheritance model is specifically truncated for application pages.  This leaves us with few options - modify each page individually with code to handle multiple master pages or add our own handler mechanism via HTTPModules to do the work for us.
Naturally, neither method is supported by Microsoft.  In the first case, we are told never to modify existing files for compatibility, upgrade and supportability purposes.  Okay, I get that.  In the second case, we are told that custom HTTPModules should not be used although I have never received a clear answer as to why this is so.  I can only assume, because people in the know have told me as much, that there is concern over custom code interacting with the existing HTTPModules that MOSS uses (although this is an obvious straw man argument as the same could be said for event handlers, server controls and web parts). 
Um, okay, well, that leaves us in a bind then, doesn't it?  Don't mess with the existing code and don't circumvent it either.  So I'm already confused when along comes KB944105 that tells me the recommended method for solving this problem is - are you ready for it? - modify the existing code!  Huh?  Did I just step off a ledge into a parallel dimension or what???
First and foremost, the "recommended" solution (make a backup of the existing 12\Template\Layouts directory then customize all the existing pages) is no solution at all.  Have you ever counted how many pages are in that directory?  Well over a hundred.  Touching each one individually would be an exercise in futility.  Putting that small issue aside, the even bigger problem is that the recommended solution is only valid for a single site-collection.  Have two site collections on the same farm with different branding?  Sorry, pal, you're out of luck.  Finally, and this is what really gets me, we have been told all along that this is the WRONG way to modify anything in SharePoint.  And most of us support this methodology because we agree in principle with the idea that changing up what comes in the box is just plain B-A-D.
So on to solution number two which, recognizing that solution number one simply won't scale, suggests that we instead change the default virtual directory mappings in IIS and create multiple layout folder instances.  Well, okay, I suppose that solves the one farm/multiple brands issue, but then you end up with numerous copies of the same files to manage (did I mention that there are more than a hundred of them?) AND you violate another principle of SharePoint customization which is to keep your hands off the IIS configuration and manage everything through Central Administration.  To make matters worse, the article actually warns that taking this approach may break existing functionality that relies on a hard-coded path to the layouts folder.  Ignoring the fact that such hard-coded values ought not to exist in the first place, this means we're breaking yet another rule against interfering with OOTB functionality.
I don't know about you but my head is starting to hurt from the implications of this article.  First, we're told not to do something (several somethings, actually).  Then we're given advice that had to be vetted by someone on the product team that says no, go ahead and do the things we told you not to do.  And still no mention of the one thing that actually does work in all scenarios without breaking any rules or hosing your server farm - custom HTTPModules. 
I swear there must be people in Redmond with stock in Glenfiddich who do these things to me when they notice my whisky consumption has dropped below distellery-sustaining levels.  If anyone can shed the light of common-sense on KB944105 to those of us stumbling about in the dark, you can find me on the back porch crying my way through a bottle of Ancient Reserve...



I agree that whatever method you use will be a pain in the ...

But can MS word this to be anymore confusing?

"Modifying the files that are installed by SharePoint is not supported." 

and a little later...

"Product support will provide commercially reasonable support for help with modifications."

So they will help you do the mods, but once you are done they say: "sorry I can't help you"?
System Account on 10/29/2007 8:02 PM

Must do better

Eric, I'm with you - the KB article is nonsense! Neither of the suggested approaches have the flexibility of a custom HTTP module. The reference to hardcoded bits of the product which may refer to 'layouts' isn't what I wanted to hear either.

I'll be sure to test thoroughly, but at the moment it's HTTP modules for me I think. I'd like to see MS do some testing and offer some better guidance on this.

System Account on 11/6/2007 4:59 AM

Why did they not make it configurable in the UI!

I have been wondering why the option in the site settings - under look and feel -> masterpages -- where you get to specify which "system page" masterpage to use - doesn't handle this. It seems to me like that was what that was intended for

Do you think there would be a way to get the _layouts pages to think of themselves as systems pages?

I think I will go for the http handler technique - although I have not tried it yet
System Account on 1/18/2008 6:55 PM

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.


Body *

Comment Date *

Select a date from the calendar.
Enter the current date to prevent automated spambot comments.

Spam Prevention *

How many letters, not including spaces, does it take to spell "SharePoint Cowboy"?


photo of Eric Shupps
611 S. Main St., Suite 400
Grapevine , TX , 76051 USA


Eric Shupps LinkedIn Eric Shupps Twitter Eric Shupps Facebook Eric Shupps Google+



BinaryWave Eric Shupps eshupps The SharePoint Cowboy SharePoint monitoring SharePoint monitoring tool SharePoint metrics SharePoint administratrion SharePoint monitoring best practices SharePoint management SharePoint management tool SharePoint operations SharePoint operationsmanagement SharePoint administration SharePoint administration tool SharePoint SLA SharePoint service level agreement SharePoint operational intelligence SharePoint performance SharePoint performance monitoring SharePoint analytics SharePoint real-time SharePoint intelligence SharePoint ITIL SharePoint service operations SharePoint uptime SharePoint alerts SharePoint health SharePoint tools SharePoint metrics SharePoint diagnostics SharePoint SmartTrack SmartTrack Operational Intelligence

Copyright © 2013 BinaryWave, Inc. All rights reserved.