Brett's SharePoint Blog : branding

Master Pages Revisited: References to master pages in SharePoint

bgeoffro — Mon, 22 Jun 2009 11:12:00 GMT

I'm still neck-deep in WCM planning, design, and development on my current project and also get lots of questions on branding topics, so a frequent point of discussion is various design patterns for the use of master pages. One of the topics that's come up a lot recently is "how do I assign master page X to page (or page layout) Y", so I've attempted to summarize my findings and recommendations on this topic in a handy table in this post.

First off, a refresher on key jargon used in the table...

Page Types - these include System Pages (i.e. web pages & web part pages that aren't based on page layouts and list view/display form pages), Page Layouts, and Application Pages.

There are five techniques described in the table for assigning a master page reference:

Hardcoded
This is a relative or absolute path to a master page. Relative locations are based on the page instance's location - i.e. "../_catalogs/masterpage/this.master" will find this.master in the current SPWeb's master page gallery, which may or may not be the top-level site's master page gallery.
Token-based References as described in this article

Static Token for Site-Relative Master Page
Note that the syntax for using this token is incorrect in the article - the correct syntax is ~site/_catalogs/masterpage/yourmasterpage.master.
Static Token for Site Collection-Relative Master Page
Note that the syntax for using this token is incorrect in the article - the correct syntax is ~sitecollection/_catalogs/masterpage/yourmasterpage.master.
Dynamic Token for SystemMaster Page
The ~masterurl/default.master token will use the current site's System Master Page.
Dynamic Token for Site Master Page
The ~masterurl/custom.master token will use the current site's Site Master Page.

Approach	Page Type	Result	Comments
Hardcode ../_catalogs/masterpage/XXX.master (or ../../_catalogs, etc., depending on how deep the page is located in the site hierarchy)	System	Works - desired master page is used
~masterurl/default.master	System	Works - System Master Page is used
~masterurl/custom.master	System	Works - Site Master Page is used
~site/_catalogs/masterpage/XXX.master	System	Works - desired master page is used
~sitecollection/_catalogs/masterpage/XXX.master	System	Works - desired master page is used
Hardcode ../_catalogs/masterpage/XXX.master	Page Layout	Error	Even if this did work, hardcoding a reference to a master page with this kind of relative path is a bad idea - remember that you may have subsites!
~masterurl/default.master	Page Layout	No effect	Simplest approach is based on information architecture - if a publishing page needs to use a different master page, put it in a different site. If this doesn't cut it, ask yourself why you really need two different looks & feels for a single site. Remember that you can override just about anything from the master page in the page layout. Did you think about designing your master page in such a way that you can override the undesirable behavior/appearance in the page layout?
~masterurl/custom.master	Page Layout	No effect	Same as above.
~site/_catalogs/masterpage/XXX.master	Page Layout	No effect	Same as above.
~sitecollection/_catalogs/masterpage/XXX.master	Page Layout	No effect	Same as above.
Hardcode ../catalogs/masterpage/XXX.master	Application	Error	Even if this did work, hardcoding a reference to a master page with this kind of relative path is a bad idea - remember that you may have subsites!
~masterurl/default.master	Application	Error	See my first big branding post for techniques applying to adjusting the look & feel of LAYOUTS pages - http://blogs.msdn.com/bgeoffro/archive/2007/11/12/branding-a-moss-corporate-intranet-portal-part-1b-branding-methods-by-scope-and-scenario.aspx . If you want to use a site or site collection-specific master page, the solution must involve an HttpModule. It'd be a different kind of branding module than I've described in my previous branding posts, as the module would need to read the Site Master Page or (more likely) the System Master Page from the current SPWeb based on the path, and then apply it to the page.
~masterurl/custom.master	Application	Error	Same as above.
~site/_catalogs/masterpage/XXX.master	Application	Error	Same as above.
~sitecollection/_catalogs/masterpage/XXX.master	Application	Error	Same as above.

Note that I didn't mention Site Pages (pages based on page layouts) anywhere in the table. You can't assign a master page to them using any of these techniques since they inherit from a page layout. Your only option in the unusual scenario of assigning a specific master page to a specific Site page would be to use a HttpModule that references the absolute path to that specific page and reassigns the master page. A better approach would be to use a page layout specifically designed for that page instance, and then override the master page as needed in the page layout.

New Advanced SharePoint Webcasts...

bgeoffro — Thu, 05 Jun 2008 20:12:00 GMT

Three of the SharePoint Academy and BPIO University courses I taught earlier this year are now available in webcast format. Many thanks to the sponsors on our product team, the Microsoft Information Worker community (global and local), content contributors, and MS Studios for making these possible. Now you can see what I look like when I'm reading from a teleprompter. :)

These webcasts contain a mix of standard material from the respective courses, as well as a number of my own contributions. Many of my contributions focus on material from areas of focus in my blog - customization, master pages, features, solutions, etc. - so thanks to all of you who've helped me enhance the content by sharing feedback, questions, and corrections to the original blogs.

I'm sure they'll end up on a landing page somewhere soon, but here are the public links:

Microsoft SharePoint Technologies Solution Architecture

http://www.microsoft.com/winme/0805/32847/mod4/index.html

Customizing and Extending Microsoft SharePoint Products and Technologies

http://www.microsoft.com/winme/0805/32847/mod9/index.html

Configuring the Business Data Catalog

http://www.microsoft.com/winme/0805/32847/mod10/index.html

Enjoy!

Branding Design using Solutions

bgeoffro — Fri, 11 Apr 2008 01:12:00 GMT

In a previous post, I extolled the virtues of deploying our branding code in a solution. While I still make that recommendation without any reservations, it's important to note that you may need TWO solutions to deploy your branding customizations.

History

First, let's do a quick review of some of the generic components I used in branding our MOSS environment (using the HTTP module approach for LAYOUTS customizations):

Customizations to the GAC

Feature Receiver DLL for the branding features
Some custom web part assemblies
Redirect Module DLL

Customizations to the "12" directory:

Custom application.master (applied via a redirect)
Custom simple.master (applied via a redirect)
Custom images
Custom Theme
A branding feature for Meeting Workspaces
A branding feature for all the other site templates
Branding feature stapler

Customizations to web.config:

SafeControls entries for the custom web parts
Redirect module configuration info

Everything except the redirect module configuration info (which we configured manually) is easily accomodated by the Solution framework, so that's exactly what I put in the original SINGLE branding solution file. So deploy all that stuff to your Web Front End servers, and you're good to go, right? Not entirely...

The Problem...

Two odd symptoms occurred in our regression testing. When we created sites/site collections from self-service site creation, STSADM on the WFE servers, or from the Create Page in a site, branding was applied. This is good. :) However, when we created site collections via STSADM from an app server or from Central Administration > Application Management > Create Site Collection, the branding was missing. This is bad. :)

Why? The Central Admin server - and all non-WFE servers - were missing the branding code. The feature stapler and everything referenced by it - the branding features, the feature receiver (since the features referenced it), and the custom theme (since the feature receiver attempted to set a new site's theme to the custom theme) - need to be on these servers in order for the site creation to complete with all branding applied.

The Solution...

In case you didn't know already (I didn't, which was the cause of this issue), there are two types of Solution deployments - Web Front End (which only pushes the changes to servers hosting the web application role) and Application Server (which pushes changes to ALL SharePoint servers in the farm). I don't remember the complete solution manifest spec, but one other restriction that's relevant to this scenario is that only the Web Front End deployment type supports creation of SafeControl entries.

Since I had a set of code that needed to be on ALL the servers as well as a couple of SafeControl entries, the simplest thing to do was to divide the customizations into two separate solutions - "core" branding and "web server" branding. The core solution holds all the components that are required on all servers, while the web server contains only the components that are needed to render the branded sites (like images, web parts, and LAYOUTS customizations).

Here's the breakdown:

"Core" Branding Solution

Customizations to the GAC

Feature Receiver DLL for the branding features
Redirect Module DLL

Customizations to the "12" directory:

Custom Theme
A branding feature for Meeting Workspaces
A branding feature for all the other site templates
Branding feature stapler

"Web Server" Branding Solution

Customizations to the GAC

Some custom web part assemblies

Customizations to the "12" directory:

Custom application.master (applied via a redirect)
Custom simple.master (applied via a redirect)
Custom images

Customizations to web.config:

SafeControls entries for the custom web parts

For ease of maintenance, I still used WSPBuilder for creating the manifests and .WSP files - this just required a minor tweak to the build script, which now looks something like this:

REM build core server customizations
wspbuilder.exe -solutionid 12345678-1234-1234-1234-1234567890ab -deploymentservertype ApplicationServer -wspname core-branding.wsp -excludefiles "a_list_of_all_the_wfe_files.txt"

REM build web server customizations
wspbuilder.exe -solutionid 12345678-1234-1234-1234-1234567890ac -deploymentservertype WebFrontEnd -wspname webserver-branding.wsp -excludefiles "a_list_of_all_the_core_files.txt"

Enjoy...

By Popular Demand... More HttpModule Sample Code

bgeoffro — Thu, 28 Feb 2008 05:22:00 GMT

Several folks have asked for this, so here it is... the two other pieces of the ResourceRedirect solution from my LAYOUTS branding post. They're also the least interesting, which is why I didn't post them before. :) Enjoy... review this post for the full context.

Redirect.cs

using System;

using System.Collections.Generic;

using System.Text;

namespace MOSS.Branding

{

public struct Redirect

{

public string pattern;

public string masterPageUrl;

public string originalMaster;

public string destinationPageUrl;

public Redirect(string _pattern, string _masterPageUrl, string _originalMaster, string _destinationPageUrl)

{

pattern = _pattern;

masterPageUrl = _masterPageUrl;

originalMaster = _originalMaster;

destinationPageUrl = _destinationPageUrl;

}

RedirectSectionHandler.cs

using System;

using System.Collections;

using System.Collections.Generic;

using System.Text;

using System.Configuration;

using System.Xml;

namespace MOSS.Branding

{

class RedirectSectionHandler : IConfigurationSectionHandler

{

#region IConfigurationSectionHandler Members

public object Create(object parent, object configContext, System.Xml.XmlNode section)

{

ArrayList coll = new ArrayList();

XmlElement root = (XmlElement)section;

string pattern = "";

string masterPageUrl = "";

string originalMaster = "";

string destinationPageUrl = "";

foreach (XmlNode parentNode in root.ChildNodes)

{

XmlNode patternNode = parentNode.Attributes.GetNamedItem("pattern");

if (patternNode != null) pattern = patternNode.InnerText.ToLower();

XmlNode originalMasterNode = parentNode.Attributes.GetNamedItem("originalMaster");

if (originalMasterNode != null) originalMaster = originalMasterNode.InnerText.ToLower();

XmlNode masterPageUrlNode = parentNode.Attributes.GetNamedItem("masterPageUrl");

if (masterPageUrlNode != null) masterPageUrl = masterPageUrlNode.InnerText.ToLower();

XmlNode destinationPageUrlNode = parentNode.Attributes.GetNamedItem("destinationPageUrl");

if (destinationPageUrlNode != null) destinationPageUrl = destinationPageUrlNode.InnerText.ToLower();

if ((masterPageUrl.Length == 0) && (destinationPageUrl.Length == 0)) throw new ConfigurationErrorsException("Redirects (masterPageUrl and destinationPageUrl) cannot both be blank.");

if ((pattern.Length == 0) && (originalMaster.Length == 0)) throw new ConfigurationErrorsException("Inputs (originalMaster and pattern) cannot both be blank.");

Redirect redirect = new Redirect(pattern, masterPageUrl, originalMaster, destinationPageUrl);

coll.Add(redirect);

}

return coll;

}

#endregion

}

Branding Mark II: Refining the HttpModule-based Approach

bgeoffro — Sat, 26 Jan 2008 20:40:00 GMT

So we've got another MOSS environment to brand for my customer. This time it's an extranet environment for partner collaboration that has some very minor changes from the Intranet branding implementation I've described in the initial series of posts. Changes are pretty superficial - swap the logo, remove certain components that are only applicable to the Intranet environment, and update the header and footer.

Implementing the actual branding tasks isn't anything new. What is new is that I've taken a different approach this time around to ease configuration management headaches - mostly due to having adequate time in the project schedule and complete ownership of the development tasks. The implementation design changes are based on two major changes:

Use of the ResourceRedirect module
Packaging of all branding components in the SharePoint Solution framework

I'll post the gory details in the next few weeks, once I've finished prepping for delivering SharePoint Academy classes, but below is a quick summary of the tactics and some lessons learned.

Using the ResourceRedirect Module

This is basically a revisit of the tactics described in part 3 of my initial series of branding posts. We used KB944105 method 1 (taking a backup copy of the LAYOUTS directory) for a handful of files that needed updating, like CORE.CSS, SPTHEMES.XML, some IMAGES files, and the various WEBTEMP*.xml files (there were a few sitedefs we wanted to hide from end users), but the branding of the LAYOUTS pages was accomplished via redirects.

We used the following set of redirects (read my previous posts and you'll see why these were selected):

</destinationRedirects>

</masterRedirects>

</Branding>

While unit-testing the ResourceRedirect, I found a couple of bugs and flaws in the approach:

The <destinationRedirect/> elements can only be used for ASPX pages. You can't use this for components that don't have a PreInit event, like CSS files, images, etc. You'll need something lower-level - like an ISAPI filter - for those. This revision to the approach has been noted in the original post.
The original code for ResourceRedirect.cs bombed when a page didn't have any master page. Forgot to check for nulls (DUH!), so pages like SiteManager.aspx caused ResourceRedirect to choke. The updated version of the code is now in the original post.
Templatepick.aspx and the ResourceRedirect don't play well together. The jury's out on how best to handle this issue for now. Try to use the ResourceRedirect module on templatepick.aspx, and although site provisioning seems to work fine, you'll get a "Vaule does not fall within the expected range" error upon site creation. The bug doesn't seem to be in the page itself, as following KB944105 method 1 with the updated page works fine. I'm hopeful that we can chase down the source of the issue, but the fallback is replacing the page and keeping the backup of LAYOUTS.

Deploying the Branding as a Solution

Important Update: Contrary to the contents of this post, you'll likely need to deploy your branding code as a combination of a Web Front End solution and an App Server solution. I'll have an updated post on this topic by late April.

I can't overstate how much easier this makes the deployment process, or how much I wish I would have had the time to implement this approach with the Intranet branding before handing off the prototype to the dev team... :( Anyways, I used WSPBuilder to prepare the solution, which saved many many hours of tweaking a solution manifest and reduced the activity of prepping a solution to copying a bunch of files to a temporary directory. It's my new hero.

You'll still need to perform a backup of any "12" directory files that you might customize. Beyond that, you've got several options for how you structure, deploy, and undeploy the solution. They differ in how you handle NEW components and REPLACEMENT components (overwriting OOTB files in the "12" directory):

Option 1: Only include NEW components in the solution. In this case, you'll have to create a backup of the "12" hive and update/restore the replacement components manually on each server.
Option 2: Include new AND replacement components in the solution. As with option 1, you'll have to create a backup of the "12" hive and update/restore the replacement components manually on each server. Here, you must create the backup before deploying the solution!!!
Option 3: Include new, replacement, AND backup components in the solution. To make this one work well, you perform two steps in structuring the solution to include the backups: add a ".bak" to each file's name AND store the backups in a new subdirectory (i.e. store a custom version of LAYOUTS\error.aspx as LAYOUTS\originals\error.aspx.bak. When it comes time to retract the solution, it's now a 3-phase process:

On all servers - Copy the *.bak files to their original locations (but don't change the names)
Retract the solution
On all servers - Rename the *.bak files to their original names

I'm sticking with Option 3 for now, since it puts the "12" hive originals in source control, spells out very clearly to the development team which components have been customized, and minimizes installation effort. Option 2 sounds a little dangerous, since you could destroy "12" hive files if you didn't capture the original backup.

Along with the solution, I wrote a simple batch file to install the solution and activate the feature stapler. There's still some manual effort involved in updating the web.config to include the ResourceRedirect configuraiton, but it's a very minimal amount of low-level configuration work. There's also an uninstall script that's step 2 from Option 3. Note that both include PAUSEs, since it's essential that you wait for the solution deployment/retraction to complete before the script executes all tasks. The install script also uses the BrandingUpdate application from my previous posts.

Install Script

The install script also uses the BrandingUpdate application from my previous posts. Note that you'll need to execute the IISRESET on ALL farm servers, so you might want to include another PAUSE there to allow admins to complete that step on all servers.

echo off

echo Adding solution to farm...

stsadm -o addsolution -filename customizations.wsp

echo Deploying solution...

stsadm -o deploysolution -name customizations.wsp -immediate -allowgacdeployment -allowcaspolicies -force -allcontenturls

echo Please navigate to "Central Administration > Operations > Solution Management" to confirm deployment.

echo Once Customizations.wsp indicates a status of 'Deployed', hit any key to proceed with the installation.

pause

echo Activating feature stapler...

stsadm -o activatefeature -name BrandingStapler -url http://sites.contoso.com

echo Resetting IIS...

iisreset /noforce

echo Updating branding on existing sites...

brandingupdate.exe

echo Branding installation complete. Please update web.config settings for branding redirects in all applicable web applications.

Uninstall Script

Note that you'll need to execute the IISRESET on ALL farm servers, so you'll need to perform that on any other WFEs after the script completes. You still need to manage the deployment of "12" directory replacements as described above, either manually or through other scripts.

echo off

echo Retracting solution...

stsadm -o retractsolution -name customizations.wsp -immediate -allcontenturls

echo Please navigate to "Central Administration > Operations > Solution Management" to confirm retraction.

echo Once Customizations.wsp indicates a status of 'Not Deployed', hit any key to proceed with the uninstall.

pause

echo Deleting solution...

stsadm -o deletesolution -name customizations.wsp

echo Resetting IIS...

iisreset /noforce

echo Branding uninstall complete.

echo Please update web.config on all applicable web applications to remove branding redirects.

echo Please restore all original "12" hive files from backup copies.

Branding Lessons Learned 2: Post-launch

bgeoffro — Thu, 20 Dec 2007 20:30:00 GMT

Yay. We launched a few days ago. Now it's time for another recap of lessons learned on the technology and process fronts:

Process Learnings (AKA battle scars):

Requirements & Design.

I won't go into the reasons why, but we had an exceedingly shallow requirements gathering effort for the branding effort, basically comprised of (a) a handful of review sessions of out-of-the-box MOSS with the customer's style guide gurus and (b) a handoff from them to our dev team of the generic (but very detailed) style guide that applied to all internal websites. No wireframes, no screenshots, no "clean slate" approach to designing the look and feel - just a half-dozen or so generic design guidelines for layout changes and the hundreds of specs for fonts and colors included in the style guide for guiding stylesheet changes.
Result: CSS updates were relatively straightforward - especially when using SharePoint Skinner or the IE Developer Toolbar to identify all the styles that needed updating - since we had a very detailed style guide and developers who knew it from working on other internal websites. Layout changes were the largest resource drain - since we were extending default.master, MWSdefault.master, etc., we often encountered vexing layout bugs relating to the complex nested tables in these pages. If you are compelled down a similar requirements/design path, plan for a long test/debug cycle, at least double that of one for a "clean slate" approach. You'll probably want to weigh the cost of investing time in wireframing everything out and building these pages from scratch using the minimal.master approach vs. an extended test/debug cycle. Don't forget to think about the cost per hour of the resources involved in each stage when weighing this decision.

Testing

MOSS is a huge product and good resources are in high demand. I'm subject to the availability bias here, but I suspect that very, very few of them are in dedicated QA roles. As a result, your test team is unlikely to have deep knowledge of the product, resulting in (1) test scripts that have enormous gaps in coverage (even those of us who are immersed in this product frequently "discover" existing features they didn't know about), and (2) innumerable misidentified "bugs" that are simply caused by ignorance of standard behavior. Mitigate both issues by sending your QA folks to deep SharePoint end user training OR tasking your high-cost MOSS expert with authoring test scripts. Run the numbers to figure out which is cheaper. Further mitigate issue 2 by having an OOTB MOSS environment availble to the QA team - a VM will do - to enable testers to confirm whether or not behavior in a customized environment is as expected. Again, run the numbers to figure out if it makes sense - how much a VM costs to setup and maintain vs. wasted developer/architect time chasing down nonissues.
There are LOTS of odds & ends to cover in testing! Use Heather Solomon's checklist of branding gotchas to increase your coverage in your test scripts.

Additional Technical Learnings:

Should you create a backup of the LAYOUTS directory and modify the original (KB944105 method 1) or create a copy of LAYOUTS for each custom-branded web application and point their respective IIS sites to it (KB944105 method 2)?

We adopted the simplest possible implementation of method 2. Central Admin and SSP admin continue to use the standard LAYOUTS directory (really, you've got to have lots of extra cash floating around if you're branding those sites); all user-facing web apps used a shared customized copy of the LAYOUTS directory. We initially had a distinct copy of the LAYOUTS directory for each user-facing webapp to allow for design flexibility (see the iterative design process above), but this made for an onerous deployment process that led to more than one perceived "bug" that was actualy a deployment error.
Method 1 works if (a) you want to brand (and troubleshoot the branding of) SSP admin, and (b) Central Admin is installed on a non-WFE server OR you want to brand (and troubleshoot the branding of) Central Admin.

Odds and ends.

RunReport.aspx (List Settings > Workflow Settings > View Workflow Reports) is another branding outlier with no master page. If you need to brand this page, you could take the same approach as for the sitemanager.aspx page (see lessons learned 1).
No load test data on the HTTP Module - it didn't make the cut in our aggressive delivery schedule. Watch for future blogs on this subject in the next month or so as we roll out another branded environment.

MOSS Intranet Portal Branding Lessons Learned 1: Omissions & Test Results

bgeoffro — Thu, 15 Nov 2007 05:41:00 GMT

We've spent the past four days doing user acceptance and regression testing on our branding, and I've found a couple of essential additions. Expect more as the testing wraps up over the next week or two:

Branding the "Operation in Progress" Page. Another GIF you may want to replace is GEARS_AN.GIF if you need to adhere to strict color/look & feel guidelines.
Templatepick.aspx. Users generally only see this one if they're creating meeting workspaces from calendar events. But if they do... it inherits from application.master, which seems a strange choice, since there's no site (and therefore no theme) yet when you're hitting this page. We haven't fixed this one yet, but I'm thinking the best way to go is to follow Heather Solomon's advice and embed the necessary styles directly in the page (following KB944105 or using an HttpModule redirect, of course), or re-master it with something a little more like simple.master
Site Content & Structure Page (LAYOUTS/sitemanager.aspx). This page doesn't use any master page... if you want to brand it, you'll have to do so by direct customization (using a supported method like the KB944105 methods or a redirect via an HttpModule). Interestingly, this page does NOT include the <SharePoint:CssLink/> like all the other pages accessed via the Site Settings page... haven't figured out why yet, but I'll let you know when I do...
HttpModule applicability. This should also work for the other virtual dirs like _controltemplates, not just _layouts. You'd definitely want to test this idea first - I've only used the KB944105 methods for customizing CONTROLTEMPLATES files in my sandbox, as we didn't need to make any changes in my customer's environment.
BrandingUpdate app gotchas. We ran into two issues when installing the branding on a number of existing test sites:

Site locks. Sites that are locked as no access or read-only can't be updated. Branding updates to these sites will fail, since you can't modify them. :)
"Apply Themes" permission. I thought it'd be clever to disallow users from changing themes in addition to applying the new custom theme (you do this through Central Admin > Application Management > Site Permissions for Web App). This is a disaster - it prevents BrandingUpdate from changing the theme on existing sites, AND it prevents site owners from firing off the theme change on the receiver assembly when they create new sites. New approach: leave this permission turned on, but hide all the OOTB themes in SPTHEMES.XML. Users can select from a grand total of exactly ONE theme. :)

More reasons to avoid use of ISAPI filters. Many thanks to my MCS coworker Suman for reminding me of my need to start studying IIS7... check out this article on how you can do a lot more with managed code to extend IIS7 than you could with IIS6: http://www.iis.net/articles/view.aspx/IIS7/Extending-IIS7/Developing-a-Module-using--NET/Developing-a-Module-using--NET .

Also, I wanted to emphasize the near-inevitability of the need to customize the LAYOUTS components. There is no escape... ;) Here's a far-from-complete list of a few high-visibility components in the LAYOUTS directory that the most common role used in collaboration sites (Members) will have access to:

Upload.aspx - Collaboration users have, on occasion, been known to upload a document or two. :)
Subnew.aspx & MySubs.aspx (AKA the New Alert page and the My Alerts page) - Extensively used, especially by teams led by productivity nuts.
Viewlsts.aspx - this is used for the "Documents", "Lists", etc. pages in sites.
Recyclebin.aspx - Perhaps the most requested enhancement from SPS2003/WSSv2.. A few folks might use it. :)
Userdisp.aspx - Used when somebody wants to see user details for themselves or another user (i.e. when clicking on a user name in a "Modified By" field).

Take a few minutes to see what Visitors have access to and you'll get a smaller list, but enough to cause a jarring user experience if you've done anything more than modify the theme. And don't forget this big one... If you're deploying personal sites - everybody's a site collection admin and sees all the LAYOUTS pages.

Branding a MOSS Corporate Intranet Portal, Part 3: LAYOUTS Pages

bgeoffro — Tue, 13 Nov 2007 03:51:00 GMT

Introduction

In order to get a consistent look and feel across all the pages, we had to brand the LAYOUTS pages as well. Since we needed webapp-specific branding and didn’t want to deal with the additional effort involved in branding & testing SSPAdmin pages, I started out following what eventually came to be known as Method 2 from KB944105. After a bit of prototyping, it looks like we’ll be going with the HttpModule-based approach, plus a few exceptions handled by Method 1 from KB944105. Performance testing is coming up in the next couple of weeks, so I’ll be sure to share how that shakes out (Method 2 is our fallback if performance is a big drag).

Thanks to Liam Cleary, whose code gave me a huge kickstart on this solution.

BrandingModule Project

The BrandingModule project consists of three components:

· ResourceRedirect Class – HTTPModule used to execute master page and other resource redirects

· RedirectSectionHandler Class – Configuration file section handler for processing ResourceRediect configuration settings

· Redirect Structure – Structure used to capture individual configuration setting elements for ResourceRedirect

Redirect Structure

The Redirect Structure is a simple structure for capturing configuration settings for all five types of redirects. Usage by type is detailed in the description.

Public Members

Member	Type	Inheritance	Description
pattern	Property	n/a	· pageRedirects -Captures the CONTAINS pattern-match filter · destinationRedirects - Captures the CONTAINS pattern-match filter · pathRedirects - Captures the STARTS WITH pattern-match filter · comboRedirects - Captures the STARTS WITH pattern-match filter · masterRedirects – not used
masterPageUrl	Property	n/a	· pageRedirects -identifies replacement master page · destinationRedirects – not used · pathRedirects - identifies replacement master page · comboRedirects - identifies replacement master page · masterRedirects – identifies replacement master page
originalMaster	Property	n/a	· pageRedirects - identifies original master page used to identify a class of pages · destinationRedirects – not used · pathRedirects - not used · comboRedirects - not used · masterRedirects – identifies original master page used to identify a class of pages
destinationPageUrl	Property	n/a	· pageRedirects - not used · destinationRedirects – identifies redirect page · pathRedirects - not used · comboRedirects - not used · masterRedirects – not used

RedirectSectionHandler class

The RedirectSectionHandler is a custom implementation of the System.Configuration.IConfigurationSectionHandler class.

Public Members

Member

Type

Inheritance

Description

Create

Object

IConfigurationSectionHandler

Returns a collection of Redirect objects and performs minimal validation on entries. Throws a ConfigurationErrorsException if either of the following conditions is true:

· masterPageUrl and destinationPageUrl are blank/missing

· pattern and originalMaster are blank/missing

ResourceRedirect Class

RecourceRedirect is a custom implementation of System.Web.IHttpModule.

Public Members

Member	Type	Inheritance	Description
Init	Method	IHttpModule	Adds the context_PreRequestHandlerExecute event handler to the PreRequestHandlerExecute event handler.
Dispose	Method	IHttpModule	Non-implemented stub.
context_PreRequestHandlerExecute	Method	n/a	Adds the page_PreInit event handler to the PreInit event handler if the current handler is a page.
page_PreInit	Method	n/a	Processes redirect instructions as specified in the configuration file. Redirects are processed in the following order: 1. Destination Redirects identified in the Branding/destinationRedirects configuration section. 2. Combination Redirects identified in the Branding/comboRedirects configuration section. 3. Path Redirects identified in the Branding/pathRedirects configuration section. 4. PageRedirects identified in the Branding/pageRedirects configuration section. 5. Master Page Redirects identified in the Branding/masterRedirects configuration section.

Private Members

Member	Type	Inheritance	Description
UpdateLog	Method	n/a	Writes event log entries. Not used – intended for diagnostic purposes only.

Configuration Settings

The ResourceRedirect requires three sets of configuration settings to be registered in a web application:

· SectionGroup configuration

· HttpModule configuration

· Branding configuration

SectionGroup Configuration

The custom section group and sections for the Branding configuration require registration in the web.config file. The <configSection/> element REQUIRES the following:

<section name="pageRedirects"

type="MOSS.Branding.RedirectSectionHandler,MOSS.Branding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bbbbccccddddeeee"/>

<section name="pathRedirects"

type="MOSS.Branding.RedirectSectionHandler,MOSS.Branding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bbbbccccddddeeee"/>

<section name="comboRedirects"

type="MOSS.Branding.RedirectSectionHandler,MOSS.Branding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bbbbccccddddeeee"/>

<section name="masterRedirects"

type="MOSS.Branding.RedirectSectionHandler,MOSS.Branding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bbbbccccddddeeee"/>

<section name="destinationRedirects"

type="MOSS.Branding.RedirectSectionHandler,MOSS.Branding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bbbbccccddddeeee"/>

</sectionGroup>

HttpModule Configuration

The ResourceRedirect module must be added to the <httpModules/> element to be registered with the web application. This element must contain the following entry:

Branding Configuration

The <Branding/> section group and all of its subsections are REQUIRED. Any or all of the subsections can be empty. A sample <Branding/> section group appears below:

</pageRedirects>

</destinationRedirects>

</pathRedirects>

</comboRedirects>

</masterRedirects>

</Branding>

“12” Customizations and Branding Redirects

We had three types of customizations to the “12” directory: modifications, new additions, and redirect additions.

Changes to the “12” Directory

The files listed below were actual customizations, subject to KB944105 Method 1.

Component	Description	Location	Modification Purpose
SPTHEMES.XML	Defines the manifest of themes installed with SharePoint.	TEMPLATE\LAYOUTS\1033	Added a custom theme to the themes manifest.
NAVSHAPE.GIF FORMTITLEGRAD.GIF PAGETITLEBKGD.GIF	Background images typically appearing in the left and header areas of SharePoint content pages.	TEMPLATE\IMAGES	Replaced with images adhering to the branding look & feel guidelines to impose branding on non-customizable pages (specifically the “Operation in Progress” page).

ADDITION to this list as of 26JAN2008:

CORE.CSS

Core stylesheet for WSS 3.0.

LAYOUTS\1033\STYLES

Includes customizations to the search control styles, which cannot be overridden by a theme.

Take special note on the middle three files – you can’t directly modify the “Gears” page, so the only way of customizing it is indirectly via styles and changes to the graphics files it uses.

NEW Additions to the “12” Directory

These are the all-new files that had no corresponding file in the OOTB “12” directory.

File name	Installed Location	Purpose	Notes
company.gif	IMAGES	Company standard logo (referenced in the custom default.master & MWSdefault.master).	Appears on all branded master pages.
themes.css	THEMES\CONTOSO	Defines the custom styles for the company theme.	Customized from the SharePoint standard “simple” theme.
mossExtension.css	THEMES\CONTOSO	???	Copied from the SharePoint standard “simple” theme.
CONTOSO.INF	THEMES\CONTOSO	Information file for the company standard theme.	Customized from the SharePoint standard “simple” theme.
navBullet_contoso.gif	THEMES\CONTOSO	Bullet icon for left navigation items.	Recolored version of navBullet_simple.gif from the SharePoint standard “simple” theme.
alldayOver_simple.gif allday_simple.gif ApplyFiltersActive.gif ApplyFiltersHoverOver.gif ApplyFiltersInactive.gif formtitlegrad_simple.gif linksectiongrad_simple.gif listheadergrad_simple.gif navBullet_simple.gif pageTitleBKGD_simple.gif partgrad_simple.gif portaltabhover.gif portaltabselected.gif portraitbackground.gif quickLaunchHeader_simple.gif toolgrad_simple.gif topnavhover_simple.gif topnavselected_simple.gif viewheadergrad_simple.gif weekbox_simple.gif	THEMES\CONTOSO	Icons for the company theme.	Copied from the SharePoint standard “simple” theme.

ADDITION to this list as of 26JAN2008:

theme.css

LAYOUTS\customizations

Duplicate of themes.css from THEMES\CONTOSO

Used to apply theme styles to pages that can't reference/access the theme.

Replacements/Redirects for the “12” Directory

These are all the files that required ResourceRedirect configurations.

Items in red font were added/updated 26JAN2008.

File name

Original Location

Redirect Location

Purpose

Notes

CORE.CSS

LAYOUTS\1033\STYLES

LAYOUTS\1033\STYLES\Customizations

Core stylesheet for WSS 3.0.

Includes customizations to the search control styles, which cannot be overridden by a theme.

NEW_application.master

LAYOUTS

LAYOUTS\Customizations

Master page for most non-dialog system pages.

NEW_simple.master

LAYOUTS

LAYOUTS\Customizations

Non-themed master page for all nonsecured system pages.

theme.css

LAYOUTS

LAYOUTS\Customizations

Used to apply styles of company standard theme to simple.master, which cannot retrieve site theme due to security restrictions.

Duplicate of themes.css from THEMES\CONTOSO .

templatepick.aspx

LAYOUTS

LAYOUTS\Customizations

Site Template selection page

Added reference to LAYOUTS\Customizations\theme.css

SiteManager.aspx

LAYOUTS

LAYOUTS\Customizations

Site Content & Structure page

Added custom header and footer

The associated <Branding/> configuration for applying the appropriate redirects for these files appears below. We installed the ResourceRedirect on all of our end user-facing web applications, thus leaving Central Admin and SSP Admin as-is. This also gives us the flexibility to have different branding for our webapps down the road if necessary, since both the feature stapling and the HttpModule are configured at the WebApp level.

</destinationRedirects>

</masterRedirects>

</Branding>

Code Snippets and Additional Comments

ResourceRedirect.cs

Updated 26JAN2006

The ResourceRedirect code appears below. Most of this is self-explanatory – especially if you read Liam Cleary’s article – but there are a few points worth calling out:

· The HttpContext.Current.Request.RawUrl is used for pattern matches. This is the only property that includes the relative site URL for LAYOUTS files (i.e. /sites/test/_layouts/settings.aspx instead of /_layouts/settings.aspx). Without this, site & site collection-specific LAYOUTS customizations would be impossible.

· The matchFound variable is essential for enforcing bailouts once a match is found, as per the “precedence” logic described earlier.

using System;

using System.Collections.Generic;

using System.Collections;

using System.Text;

using System.Web;

using System.Web.UI;

using System.Configuration;

using System.Diagnostics;

namespace MOSS.Branding

{

public class ResourceRedirect : IHttpModule

{

public void Init(HttpApplication context)

{

context.PreRequestHandlerExecute += new EventHandler(context_PreRequestHandlerExecute);

}

void context_PreRequestHandlerExecute(object sender, EventArgs e)

{

HttpApplication httpApp = sender as HttpApplication;

if (httpApp != null)

{

Page page = httpApp.Context.CurrentHandler as Page;

if (page != null)

{

page.PreInit += new EventHandler(page_PreInit);

}

void page_PreInit(object sender, EventArgs e)

{

Page page = sender as Page;

string currentMaster = String.Empty;

string currentPath = HttpContext.Current.Request.RawUrl.ToLower();

ArrayList masterRedirects = null;

ArrayList pageRedirects = null;

ArrayList pathRedirects = null;

ArrayList comboRedirects = null;

ArrayList destinationRedirects = null;

//retrieve remappings by type to enable enforcing precedence

masterRedirects = (ArrayList)ConfigurationManager.GetSection("Branding/masterRedirects");

pageRedirects = (ArrayList)ConfigurationManager.GetSection("Branding/pageRedirects");

pathRedirects = (ArrayList)ConfigurationManager.GetSection("Branding/pathRedirects");

comboRedirects = (ArrayList)ConfigurationManager.GetSection("Branding/comboRedirects");

destinationRedirects = (ArrayList)ConfigurationManager.GetSection("Branding/destinationRedirects");

bool matchFound = false;

IEnumerator redirectEnum = null;

if (page != null)

{

if (destinationRedirects.Count > 0) //check for full redirect

{

redirectEnum = destinationRedirects.GetEnumerator();

while (redirectEnum.MoveNext())

{

Redirect destinationRedirect = (Redirect)redirectEnum.Current;

if (currentPath.Contains(destinationRedirect.pattern))

{

HttpContext.Current.Response.Redirect(currentPath.Replace(destinationRedirect.pattern,

destinationRedirect.destinationPageUrl));

matchFound = true;

}

if (page.MasterPageFile != null)

{

currentMaster = page.MasterPageFile.ToLower();

if ((comboRedirects.Count > 0) && (!matchFound))//check for combo remaps first

{

redirectEnum = comboRedirects.GetEnumerator();

while (redirectEnum.MoveNext())

{

Redirect comboRedirect = (Redirect)redirectEnum.Current;

if ((currentPath.StartsWith(comboRedirect.pattern)) && (currentMaster.Contains(comboRedirect.originalMaster)))

{

page.MasterPageFile = comboRedirect.masterPageUrl;

matchFound = true;

}

if ((pathRedirects.Count > 0) && (!matchFound)) //check for path-based remaps second

{

redirectEnum = pathRedirects.GetEnumerator();

while (redirectEnum.MoveNext())

{

Redirect pathRedirect = (Redirect)redirectEnum.Current;

if (currentPath.StartsWith(pathRedirect.pattern))

{

page.MasterPageFile = pathRedirect.masterPageUrl;

matchFound = true;

}

if ((pageRedirects.Count > 0) && (!matchFound)) //check for page-based remaps third

{

redirectEnum = pageRedirects.GetEnumerator();

while (redirectEnum.MoveNext())

{

Redirect pageRedirect = (Redirect)redirectEnum.Current;

if (currentPath.Contains(pageRedirect.pattern))

{

page.MasterPageFile = pageRedirect.masterPageUrl;

matchFound = true;

}

if ((masterRedirects.Count > 0) && (!matchFound)) //check for master page remaps last

{

redirectEnum = masterRedirects.GetEnumerator();

while (redirectEnum.MoveNext())

{

Redirect masterRedirect = (Redirect)redirectEnum.Current;

if (currentMaster.Contains(masterRedirect.originalMaster))

{

page.MasterPageFile = masterRedirect.masterPageUrl;

}

private void UpdateLog(string Message, EventLogEntryType msgType)

{

try

{

System.Diagnostics.EventLog.WriteEntry("ResourceRedirect", Message, msgType);

}

catch

{

//ignore

}

public void Dispose()

{

}

Branding a MOSS Corporate Intranet Portal, Part 2: Site & System Pages

bgeoffro — Tue, 13 Nov 2007 03:46:00 GMT

Introduction

This post covers a sample technical design for the most common branding task you’ll encounter for site & system pages – adapting ALL site & system pages on ALL sites to your customer’s look-and-feel standards. We accomplish this with the following components, each of which are covered in detail:

· Branding “Staplee” Features – the Features that contain a custom master page and (optionally) custom pages, page manipulation specifications, and other SPWeb-level components to be applied to all sites created from one or more site definitions

· Branding ”Stapler” Feature – the Feature that staples all of the Branding Features to their respective site definitions

· MySiteCreate Receiver Assembly – the Feature receiver assembly used to set custom site & system master pages, a custom theme, and manage page manipulation execution

· PartCheck Web Part – the Page Manipulation web part that is used to alter the default home/welcome page for sites associated with a particular Branding Feature

· BrandingUpdate – a console application used to apply/reapply branding features to existing sites

Customizations to components found in the LAYOUTS directory are described in Part 3. The closing section of this article will reference specific dependencies between customizations to site/system pages and LAYOUTS components.

BrandingFeatures Project

The Branding Features project contains all SharePoint features relating to the custom intranet branding. This includes a number of “Staplee” features which are used to install master pages and a theme on sites, and a single “Stapler” feature that associates the Staplees with specific site definitions.

The branding features described below are intended to be deployed in a standard manner across ALL web applications. Should new requirements make separate branding schemes necessary for individual web applications, developers can create a unique Branding Stapler feature for each web application and (if necessary) additional Branding Staplee features.

File Manifest

File name	Project Location	Installation Scope	Purpose	Notes
BrandingStapler	BrandingStapler	Web App	Folder for BrandingStapler feature
GenericBrandingStaplee	GenericBrandingStaplee	Web	Folder for GenericBrandingStaplee feature
MeetingBrandingStaplee	MeetingBrandingStaplee	Web	Folder for MeetingBrandingStaplee feature
Custom_default.master	GenericBrandingStaplee	Web	Master page for all site pages for non-meeting workspace sites.	Common element file for all associated features.
Custom_MWSDefault.master	MeetingBrandingStaplee	Web	Master page for all site pages for meeting workspace sites.	Common element file for all associated features.
Feature.xml	BrandingStapler	Web App	Feature specification file
Elements.xml	BrandingStapler	Web App	Element manifest.	Defines Feature Site Template Associations for all Branding Staplee features.
Feature.xml	GenericBrandingStaplee	Web	Feature specification file	Includes properties for use by Feature Receiver (MySiteCreate).
Elements.xml	GenericBrandingStaplee	Web	Element manifest.	Defines installation location for master page and MySiteStaplee.xml.
Feature.xml	MeetingBrandingStaplee	Web	Feature specification file	Includes properties for use by Feature Receiver (MySiteCreate).
Elements.xml	MeetingBrandingStaplee	Web	Element manifest.	Defines installation location for master page and MySiteStaplee.xml.
MySiteStaplee.xml	GenericBrandingStaplee	Web	Defines web part deployment instructions for the home page for all site definitions associated with the GenericBrandingStaplee feature.	No web part deployment instructions for these site definitions.
MySiteStaplee.xml	MeetingBrandingStaplee	Web	Defines web part deployment instructions for the home page for all site definitions associated with the MeetingBrandingStaplee feature.	No web part deployment instructions for these site definitions.
MySiteCreate.cs	{root}	Farm	Feature receiver for all branding staplee features.

MySiteCreate.cs

Microsoft.IW.MySiteCreate is a modified version of the feature receiver from the MySite customization article described in the references section. This feature receiver executes the following actions for each site created from a site definition associated with the feature:

· Sets the master page and custom master page URL for the site to the value specified in the MasterName property.

· Sets the theme for the site to the value specified in the ThemeID property.

· Optionally sets a flag on the site for later processing by the PartCheck control to ignore web part deployment instructions based on the value of the CheckPart property.

Public Methods

Name	Type	Purpose	Notes
FeatureActivated	Void	Sets the master page and theme for the site. Optionally sets the web part check flag for the MySiteCreate control.
FeatureDeactivating	Void	Not implemented. See SPFeatureReceiver specification.
FeatureInstalled	Void	Not implemented. See SPFeatureReceiver specification.
FeatureUninstalling	Void	Not implemented. See SPFeatureReceiver specification.

Private Methods

Name	Type	Purpose	Notes
UpdateLog	Void	Writes entries to the Windows Application event log.

Custom_default.master

The Custom_default.master file is a customized version of the default.master SharePoint master page.

Sample customizations that could be found in Custom_default.master are described below:

· Header region

o Moved Welcome control from right side of header to left side of header

o Moved Search controls to same row as Welcome control

o Removed User-customizable Site Logo

o Added Contoso logo

· Footer region

o Added custom footer

§ Footer contains {WebPart X} and several hyperlinks to policies

· HIDDEN

o Added PartCheck control to page

Custom_MWSdefault.master

The Custom_MWSdefault.master file is a customized version of the MWSdefault.master SharePoint master page.

Sample customizations that could be found in Custom_MWSdefault.master are described below:

· Header region

o Moved Welcome control from right side of header to left side of header

o Moved Search controls to same row as Welcome control

o Removed User-customizable Site Logo

o Added Contoso logo

· Footer region

o Added custom footer

§ Footer contains {WebPart X} and several hyperlinks to policies

· HIDDEN

o Added PartCheck control to page

BrandingStapler Feature

The BrandingStapler feature associates each of the branding staplees with one or more site templates.

Refer to the webtemp*.xml files in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\XML to identify the common names for the site templates described in the feature site template associations.

BrandingStaplee Features

The branding staplees are hidden features – which cannot be disabled/enabled by site owners – that are activated whenever a web of the type associated with the feature is created. Each branding staple accomplishes the following tasks upon activation in a web:

· Installs the master page specified by the feature in the _catalogs/masterpages directory

· Installs the web part deployment instructions specified by the feature in the _catalogs/masterpages directory. This file must always be named MySiteCreate.xml.

· Calls the MySiteCreate feature receiver assembly.

Custom Properties

Name	Type	Purpose	Notes
CheckPart	Boolean	Specifies whether or not the PartCheck control needs to execute web part deployment instructions on the site’s home page.	Optional. PartCheck will log an error event if it processes a malformed MySiteStaplee.xml file or cannot access the default.aspx page.
MasterName	String	Used by MySiteCreate feature receiver. File name for master page to be set on the site.
ThemeID	String	Used by MySiteCreate feature receiver. Theme ID for the theme to be set on the site.
OriginalMasterName	String	Intended for future use by MySiteCreate feature receiver. NOT IMPLEMENTED

Comments: The branding stapler doesn’t include any deactivation methods. Depending on your scenario, you may or may not want to include deactivation logic, but that can get complicated. Do you restore the site to the original theme, site master page, system master page, and home page configuration? Do you restore the master pages to default.master & the theme to the “Default” theme and leave the page alone? What about changes that the user has made since the branding was applied? Regardless, lots of planning and design has to go into any branding updates and/or deactivation.

BrandingUpdate

The Branding Update application is used to apply branding features to existing sites. It can be used for both initial branding deployment and future updates to branding features, or even for installing other features unrelated to branding that are associated with webs via FeatureSiteTemplateAssociations.

File Manifest

File name	Project Location	Installation Scope	Purpose	Notes
Program.cs	{root}	n/a	Main application.
BrandMap.cs	{root}	n/a	Structure for storing the attributes of featuresitetemplate elements in the configuration file.
webAppSectionhandler.cs	{root}	n/a	Extension of IConfigurationSectionHandler for processing the custom <webAppSection/> configuration file element.
masterMapSectionHandler.cs	{root}	n/a	Extension of IConfigurationSectionHandler for processing the custom <mappingSection/> configuration file element.
App.config	{root}	n/a	Application configuration file.

Configuration Settings

The Branding Update application uses the configuration settings specified in the table below. Settings in bold red are required.

Name	Section	Domain	Purpose	Default Value
Loglevel	appSettings	Integer – 0 or greater	Describes application log verbosity. 0 = no event logging 1 = Error events only 2 = Error & Warning events 3 or more = All events	1
Debug	appSettings	Boolean – true or false	Determines whether log entries should be written to the console. True - write to console False - do not write to console	false
brandAll	appSettings	Boolean – true or false	Determines scope of branding feature activation. False - branding will only be applied to sites without branding features activated True – branding will be applied (or reapplied) to all sites	false
filterPattern	appSettings	Any string value (should match one or more site names)	Case-insensitive pattern for restricting the scope of sites against which the Branding Update application will run. This is a “starts with” filter pattern, not a substring match. An empty filter pattern is interpreted as a wildcard filter.	(none)
webApp (One or more entries)	webAppSectio	Any name for a web application in the farm	Case-insensitive name for a web application. Branding updates will be applied to any web applications listed in this section.	(none)
FeatureSiteTemplateAssociation (One or more entries)	mappingSection	Any FeatureSiteTemplateAssociation element from the BrandingStapler’s elements.xml file.	Branding updates will only be applied to sites created from templates with associations listed in this element.	(none)

Note that BrandingUpdate employs progressive filtering via the configuration file. The priority is effectively as follows:

1. WebApp determines the set of web applications

2. FilterPattern determines the applicable sites within those applications

3. BrandAll determines whether to apply branding to those sites without branding features activated or to all sites

Program.cs

Program.cs is the main application class for the BrandingUpdate application.

Protected Methods

Name	Type	Purpose	Notes
Main	Void	Main method.

Private Methods

Name	Type	Purpose	Notes
DoLog	Void	Writes entries to the Windows Application event log and/or the console.	Log entries appear with a source of “BrandingUpdate”

BrandingParts

The BrandingParts project contains web parts used in Contoso intranet branding.

Comment: This example only shows the PartCheck part, but you might also have other web parts that are used to deploy custom functionality as part of branding efforts.

File Manifest

File name	Project Location	Installation Scope	Purpose	Notes
PartCheck.cs	{root}	Farm	Manipulates the web parts deployed on the default.aspx page for a given site.

PartCheck.cs

PartCheck extends the System.Web.UI.WebControls.WebControl class. Refer to that specification for inherited members. This component is borrowed from the MySite branding blog entry described in the references section. Refer to that reference and code comments for full documentation.

LAYOUTS Customizations

The Customizations project contains a number of files that need to be installed in the IIS home directories of user-facing web applications and the “12” directory.

Some of the LAYOUTS components that your site & system page branding may depend on include:

· Images

· Theme Definitions

· Stylesheets

· CSS files

Code Snippets and Additional Comments

I’ll be posting most of the code shortly, once I have time to sanitize everything. Below are snippets of the key portions of the solution with a few comments. For the PartCheck code and explanation, see Steve Peschka’s post.

BrandingStapler

The stapler’s Feature.xml is very simple, just referencing the elements.xml. You could make this Farm scope instead of WebApp scope.

<Feature

Id="247385FE-AAAA-BBBB-980C-5517B7609D58"

Title="Branding Stapler"

Scope="WebApplication"

xmlns="http://schemas.microsoft.com/sharepoint/" >

</ElementManifests>

</Feature>

The elements.xml is where the action is. You’ll see the feature GUIDs for the meeting and generic branding staplees referenced in this file. Of course, you can have site definition-specific branding features if your requirements demand them. Note that the list below includes all the MOSS Enterprise templates – you won’t find all of them in WSSv3 or MOSS Standard.

</Elements>

GenericBrandingStaplee

The branding staplee features are essentially the same as Steve Peschka’s MySiteStaplee feature. Only significant differences are in the feature.xml file, which appears below:

<Feature

Id="6FA5083C-AAAA-BBBB-84E6-EDD5187DB798"

Title="Generic Site Branding Feature"

Scope="Web"

ReceiverAssembly="MySiteCreate, Version=1.0.0.0, Culture=neutral, PublicKeyToken=AAAABBBBCCCCDDDD"

ReceiverClass="Microsoft.IW.MySiteCreate"

Hidden="TRUE"

xmlns="http://schemas.microsoft.com/sharepoint/">

</ElementManifests>

</Properties>

</Feature>

You’ll see that my feature.xml also identifies the theme (we used a custom one) and, thinking ahead to potential deactivation logic which I ended up not using, the original master page for the site definition.

MySiteCreate Receiver Assembly

MySiteCreate.cs code:

using System;

using System.Collections.Generic;

using System.Text;

using Microsoft.SharePoint;

using Microsoft.SharePoint.WebPartPages;

using System.Diagnostics;

namespace Microsoft.IW

{

public class MySiteCreate : SPFeatureReceiver

{

const string KEY_CHK = "Microsoft.IW.PartCheck";

const string ORIGINALTHEME = "simple";

public override void FeatureActivated(SPFeatureReceiverProperties properties)

{

try

{

string newMaster = string.Empty;

string newTheme = string.Empty;

bool checkParts = false;

//look at the properties collection to get the new master page name

newMaster = properties.Feature.Properties["MasterName"].Value;

newTheme = properties.Feature.Properties["ThemeID"].Value;

checkParts = Convert.ToBoolean(properties.Feature.Properties["CheckParts"].Value);

if (!checkParts)

{

//no need to check the web parts - set the part check flag preemptively

using (SPWeb curWeb = (SPWeb)properties.Feature.Parent)

{

if (!curWeb.Properties.ContainsKey(KEY_CHK))

{

curWeb.Properties.Add(KEY_CHK, "true");

curWeb.Properties.Update();

}

if ((newMaster != null) && (newMaster != string.Empty) &&

(newTheme != null) && (newTheme != string.Empty))

{

using (SPWeb curWeb = (SPWeb)properties.Feature.Parent)

{

string curMaster = curWeb.MasterUrl;

string curCustomMaster = curWeb.CustomMasterUrl;

//got the current site and root web in site, now set the master Url

//to our master page that should have been uploaded as part

//of our feature

int masterPathEnd = curMaster.LastIndexOf('/');

int customMasterPathEnd = curCustomMaster.LastIndexOf('/');

UpdateLog("Preparing to update branding for web " + curWeb.Title +

". MasterUrl: " + curWeb.MasterUrl + "; CustomMasterUrl: " +

curWeb.CustomMasterUrl + "; Theme: " + curWeb.Theme + ".",

EventLogEntryType.Information);

curWeb.MasterUrl = curMaster.Substring(0, ++masterPathEnd) + newMaster;

curWeb.CustomMasterUrl = curCustomMaster.Substring(0, ++customMasterPathEnd) + newMaster;

curWeb.ApplyTheme(newTheme);

curWeb.Update();

UpdateLog("Updated branding for web " + curWeb.Title +

". MasterUrl: " + curWeb.MasterUrl + "; CustomMasterUrl: " +

curWeb.CustomMasterUrl + "; Theme: " + curWeb.Theme + ".",

EventLogEntryType.Information);

}

catch (Exception ex)

{

//try writing to event log

UpdateLog("Error in handler. Message: " + ex.Message + ". Full Exception: " + ex.ToString(), EventLogEntryType.Error);

}

private void UpdateLog(string Message, EventLogEntryType msgType)

{

try

{

System.Diagnostics.EventLog.WriteEntry("My Site Created Handler", Message, msgType);

}

catch

{

//ignore

}

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)

{

try

{

string originalMaster = string.Empty;

//look at the properties collection to get the new master page name

originalMaster = properties.Feature.Properties["OriginalMaster"].Value;

if ((originalMaster != null) && (originalMaster != string.Empty))

{

using (SPWeb curWeb = (SPWeb)properties.Feature.Parent)

{

string curMaster = curWeb.MasterUrl;

string curCustomMaster = curWeb.CustomMasterUrl;

//got the current site and root web in site, now set the master Url

//to our master page that should have been uploaded as part

//of our feature

int masterPathEnd = curMaster.LastIndexOf('/');

int customMasterPathEnd = curCustomMaster.LastIndexOf('/');

UpdateLog("Preparing to revert branding for web " + curWeb.Title +

". MasterUrl: " + curWeb.MasterUrl + "; CustomMasterUrl: " +

curWeb.CustomMasterUrl + "; Theme: " + curWeb.Theme + ".",

EventLogEntryType.Information);

curWeb.MasterUrl = curMaster.Substring(0, ++masterPathEnd) + originalMaster;

curWeb.CustomMasterUrl = curCustomMaster.Substring(0, ++customMasterPathEnd) + originalMaster;

curWeb.ApplyTheme(ORIGINALTHEME);

curWeb.Update();

UpdateLog("Reverted branding for web " + curWeb.Title +

". MasterUrl: " + curWeb.MasterUrl + "; CustomMasterUrl: " +

curWeb.CustomMasterUrl + "; Theme: " + curWeb.Theme + ".",

EventLogEntryType.Information);

}

catch (Exception ex)

{

//try writing to event log

UpdateLog("Error in handler. Message: " + ex.Message + ". Full Exception: " + ex.ToString(), EventLogEntryType.Error);

}

public override void FeatureInstalled(SPFeatureReceiverProperties properties)

{

//throw new Exception("The method or operation is not implemented.");

}

public override void FeatureUninstalling(SPFeatureReceiverProperties properties)

{

//throw new Exception("The method or operation is not implemented.");

}

Comments:

· This class is a novel extension of Steve Peschka’s code. Only differences are that I’m setting both master pages and the theme.

· Note that I started down the path of including a Deactivating event, but thought better of it due to the issues described earlier… J

BrandingUpdate

The behavior of Program.cs is described in detail above. Here’s the code:

using System;

using System.Collections.Generic;

using System.Collections.Specialized;

using System.Diagnostics;

using System.Text;

using System.Xml;

using System.Configuration;

using Microsoft.SharePoint;

using Microsoft.SharePoint.Administration;

using System.Collections;

namespace BrandingUpdate

{

class Program

{

static int logLevel = 1;

static bool debug = false;

static bool brandAll = false;

static bool upload = false;

static string logSource = "BrandingUpdate";

static string logDestination = "Application";

static string filterPattern = "";

static void Main(string[] args)

{

//Retrieve Configuration Settings

ArrayList webApps = null;

ArrayList brandMaps = null;

StringDictionary staples = new StringDictionary();

try

{

Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);

ConfigurationSectionGroupCollection webApp = config.SectionGroups;

NameValueCollection appSettings = ConfigurationManager.AppSettings;

logLevel = Convert.ToInt32(appSettings["loglevel"]);

debug = Convert.ToBoolean(appSettings["debug"]);

brandAll = Convert.ToBoolean(appSettings["brandAll"]);

filterPattern = appSettings["filterPattern"];

webApps = (ArrayList)ConfigurationManager.GetSection("brandingSectionGroup/webAppSection");

brandMaps = (ArrayList)ConfigurationManager.GetSection("brandingSectionGroup/mappingSection");

if (webApps == null || brandMaps == null) throw new ConfigurationException("Missing required arguments.");

foreach (BrandMap map in brandMaps)

{

staples.Add(map.templateName, map.id);

}

catch (Exception e)

{

DoLog("Error reading configuration file:" + e.ToString(), EventLogEntryType.Error, 100);

}

try

{

//Retrieve list of web apps

SPFarm mySPFarm = SPWebService.ContentService.Farm;

SPWebApplicationCollection mySPWebAppCollection = SPWebService.ContentService.WebApplications;

if (mySPWebAppCollection != null)

{

//Iterate through web applications

foreach (SPWebApplication mySPWebApp in mySPWebAppCollection)

{

DoLog("WebApp: " + mySPWebApp.Name, EventLogEntryType.Information, 250);

if (webApps.Contains(mySPWebApp.Name.ToUpper()))

{

//Iterate through site collections

foreach (SPSite site in mySPWebApp.Sites)

{

//Iterate through webs

foreach (SPWeb web in site.AllWebs)

{

//check to see if web matches filter pattern

if (filterPattern.Equals("") || web.Url.StartsWith(filterPattern, true, null))

{

string configurationID = web.WebTemplate + "#" + web.Configuration;

string featureStaple = staples[configurationID];

if (featureStaple != null)

{

bool brandingActivated = false;

Guid featureGuid = new Guid(featureStaple);

//see if branding feature is activated on this web

foreach (SPFeature feature in web.Features)

{

if (feature.DefinitionId.Equals(featureGuid))

{

brandingActivated = true;

}

//apply branding to everything if branding feature is not activated

if (brandAll || !brandingActivated)

{

try

{

DoLog("Activating branding feature " + featureGuid.ToString() + " for web " + web.Url , EventLogEntryType.Information, 500);

if (brandingActivated) web.Features.Remove(featureGuid);

web.Features.Add(featureGuid);

}

catch (Exception ex)

{

DoLog("Error activating branding feature " + featureGuid.ToString() + " for web " + web.Url + ". Exception: " + ex.ToString(), EventLogEntryType.Error, 500);

}

web.Close();

}//close web loop

site.Close();

} //Close site collection loop

}

}//Close webapp loop

}

catch (Exception e)

{

DoLog("Error examining site collections:" + e.ToString(), EventLogEntryType.Error, 400);

}

private static void DoLog(string msg, EventLogEntryType eventType, int code)

{

bool writeEntry = true;

if (debug) Console.WriteLine("Event Type: {0}; ID: {1}; Message: {2}", eventType.ToString(), code, msg);

if (logLevel > 0)

{

if (!EventLog.SourceExists(logSource))

EventLog.CreateEventSource(logSource, logDestination);

if (eventType.Equals(EventLogEntryType.Warning) && (logLevel < 2))

writeEntry = false;

if (eventType.Equals(EventLogEntryType.Information) && (logLevel < 3))

writeEntry = false;

if (writeEntry) EventLog.WriteEntry(logSource, msg, eventType, code);

}

App.config is also described above. Only comment-worthy feature is that the masterMapSectionHandler implements the same structure for a FeatureSiteTemplateAssociation as you have in the elements.xml, which makes adding all this configuration info very easy:

<?xml version="1.0" encoding="utf-8" ?>

<section name="webAppSection"

type="BrandingUpdate.webAppSectionHandler,BrandingUpdate"/>

<section name="mappingSection"

type="BrandingUpdate.masterMapSectionHandler,BrandingUpdate"/>

</sectionGroup>

</configSections>

<webApp>MOSS.LITWAREINC.COM</webApp>

<webApp>SharedServices1</webApp>

</webAppSection>

</mappingSection>

</brandingSectionGroup>

</appSettings>

</configuration>

Branding a MOSS Corporate Intranet Portal, Part 1b: Branding Methods by Scope and Scenario

bgeoffro — Tue, 13 Nov 2007 03:43:00 GMT

Branding Methods by Scope and Scenario

The methods matrices referred to in Part 1a appear below. Refer to that post for context, or you won’t find this very useful...

Scope: Farm

	Single Site Definition Site Page	Single Site Definition System Page	All Site Pages	All System Pages	Single SIMPLE LAYOUTS Page	Single non-SIMPLE LAYOUTS Page	All SIMPLE LAYOUTS Page	All non-SIMPLE LAYOUTS Pages	All LAYOUTS Pages
Non-structural look & feel	OOTB Site Definition Copy with custom page	OOTB Site/List Definition Copy with custom page	Theme/Site Properties Feature Stapling (Farm Scope) AND Custom Theme Install (optional) Staple to all applicable SiteDefs	Theme/Site Properties Feature Stapling (Farm Scope) AND Custom Theme Install (optional) Staple to all applicable SiteDefs	Custom Master Page Install AND Page-filtered HttpModule redirect Install HttpModule on all WebApps	Custom Master Page Install AND Page-filtered HttpModule redirect Install HttpModule on all WebApps	Custom Master Page Install AND MasterPage-specific HttpModule redirect Install HttpModule on all WebApps	Theme/Site Properties Feature Stapling (Farm Scope) AND Custom Theme Install (optional)	Custom Master Page Install AND MasterPage-specific HttpModule redirect AND Theme Feature Stapling AND Custom Theme Install (optional) Install HttpModule on all WebApps
Inherited Layout	OOTB Site Definition Copy with custom page	OOTB Site/List Definition Copy with custom page	Custom Site Master Page Feature Stapling (Farm Scope) Staple to all applicable SiteDefs	Custom System Master Page Feature Stapling (Farm Scope) Staple to all applicable SiteDefs	Custom Master Page Install with Page-filtered HttpModule redirect Install HttpModule on all WebApps	Custom Master Page Install with Page-filtered HttpModule redirect Install HttpModule on all WebApps	Custom Master Page Install with MasterPage-specific HttpModule redirect Install HttpModule on all WebApps	Multiple Custom Master Page Installs with MasterPage-specific HttpModule redirects Install HttpModule on all WebApps	Multiple Custom Master Page Installs with MasterPage-specific HttpModule redirects Install HttpModule on all WebApps
Inherited Embedded Functionality (add/remove OOTB)	OOTB Site Definition Copy with custom page	OOTB Site/List Definition Copy with custom page	Custom Site Master Page Feature Stapling (Farm Scope) Staple to all applicable SiteDefs	Custom System Master Page Feature Stapling (Farm Scope) Staple to all applicable SiteDefs	Custom Master Page Install with Page-filtered HttpModule redirect Install HttpModule on all WebApps	Custom Master Page Install with Page-filtered HttpModule redirect Install HttpModule on all WebApps	Custom Master Page Install with MasterPage-specific HttpModule redirect Install HttpModule on all WebApps	Multiple Custom Master Page Installs with MasterPage-specific HttpModule redirects Install HttpModule on all WebApps	Multiple Custom Master Page Installs with MasterPage-specific HttpModule redirects Install HttpModule on all WebApps
Inherited Embedded Functionality (change OOTB)	OOTB Site Definition Copy with custom page	OOTB Site/List Definition Copy with custom page	OOTB Component Copy Install with Custom Site Master Page Feature Stapling (Farm Scope) Staple to all applicable SiteDefs	OOTB Component Copy Install with Custom System Master Page Feature Stapling (Farm Scope) Staple to all applicable SiteDefs	OOTB Component Copy Install AND Custom Master Page Install AND Page-filtered HttpModule redirect Install HttpModule on all WebApps	OOTB Component Copy Install AND Custom Master Page Install AND Page-filtered HttpModule redirect Install HttpModule on all WebApps	OOTB Component Copy Install AND Custom Master Page Install AND MasterPage-specific HttpModule redirect Install HttpModule on all WebApps	OOTB Component Copy Install AND Multiple Custom Master Page Installs AND MasterPage-specific HttpModule redirects Install HttpModule on all WebApps	OOTB Component Copy Install AND Multiple Custom Master Page Installs AND MasterPage-specific HttpModule redirects Install HttpModule on all WebApps
Inherited Embedded Functionality (add new)	OOTB Site Definition Copy with custom page	OOTB Site/List Definition Copy with custom page	New Component Install with Custom Site Master Page Feature Stapling (Farm Scope) Staple to all applicable SiteDefs	New Component Install with Custom System Master Page Feature Stapling (Farm Scope) Staple to all applicable SiteDefs	New Component Install AND Custom Master Page Install AND Page-filtered HttpModule redirect Install HttpModule on all WebApps	New Component Install AND Custom Master Page Install AND Page-filtered HttpModule redirect Install HttpModule on all WebApps	New Component Install AND Custom Master Page Install AND MasterPage-specific HttpModule redirect Install HttpModule on all WebApps	New Component Install AND Multiple Custom Master Page Installs AND MasterPage-specific HttpModule redirects Install HttpModule on all WebApps	New Component Install AND Multiple Custom Master Page Installs AND MasterPage-specific HttpModule redirects Install HttpModule on all WebApps
Explicit Layout	OOTB Site Definition Copy with custom page	OOTB Site/List Definition Copy with custom page	n/a	n/a	KB944105 Method 1 OR OOTB Page Copy Install with Destination HttpModule redirect	KB944105 Method 1 OR OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Explicit Embedded Functionality (add/remove OOTB)	OOTB Site Definition Copy with custom page	OOTB Site/List Definition Copy with custom page	n/a	n/a	KB944105 Method 1 OR OOTB Page Copy Install with Destination HttpModule redirect	KB944105 Method 1 OR OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Explicit Embedded Functionality (change OOTB)	OOTB Site Definition Copy with custom page	OOTB Site/List Definition Copy with custom page	n/a	n/a	KB944105 Method 1 OR OOTB Page Copy Install with Destination HttpModule redirect	KB944105 Method 1 OR OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Explicit Embedded Functionality (add new)	OOTB Site Definition Copy with custom page	OOTB Site/List Definition Copy with custom page	n/a	n/a	KB944105 Method 1 OR OOTB Page Copy Install with Destination HttpModule redirect	KB944105 Method 1 OR OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Default Page Content	Feature with Page Manipulation Web Part AND Custom Master Page (Farm Scope) with Feature Stapling OR OOTB Site Definition Copy with custom page	n/a	n/a	n/a	n/a	n/a	n/a	n/a	n/a

Scope: Single Web Application

	Single Site Definition Site Page	Single Site Definition System Page	All Site Pages	All System Pages	Single SIMPLE LAYOUTS Page	Single non-SIMPLE LAYOUTS Page	All SIMPLE LAYOUTS Page	All non-SIMPLE LAYOUTS Pages	All LAYOUTS Pages
Non-structural look & feel	Custom Page Feature Install with Feature Stapling	Custom Page Feature Install with Feature Stapling	Theme/Site Properties Feature Stapling (WebApp Scope) AND Custom Theme Install (optional) Staple to all applicable SiteDefs	Theme/Site Properties Feature Stapling (WebApp Scope) AND Custom Theme Install (optional) Staple to all applicable SiteDefs	Custom Master Page Install AND Page-filtered HttpModule redirect	Custom Master Page Install AND Page-filtered HttpModule redirect	Custom Master Page Install AND MasterPage-specific HttpModule redirect	Theme/Site Properties Feature Stapling (WebApp Scope) AND Custom Theme Install (optional)	Custom Master Page Install AND MasterPage-specific HttpModule redirect AND Theme Feature Stapling AND Custom Theme Install (optional)
Inherited Layout	Custom Page Feature Install with Feature Stapling	Custom Page Feature Install with Feature Stapling	Custom Site Master Page Feature Stapling (WebApp Scope) Staple to all applicable SiteDefs	Custom System Master Page Feature Stapling (WebApp Scope) Staple to all applicable SiteDefs	Custom Master Page Install with Page-filtered HttpModule redirect	Custom Master Page Install with Page-filtered HttpModule redirect	Custom Master Page Install with MasterPage-specific HttpModule redirect	Multiple Custom Master Page Installs with MasterPage-specific HttpModule redirects	Multiple Custom Master Page Installs with MasterPage-specific HttpModule redirects
Inherited Embedded Functionality (add/remove OOTB)	Custom Page Feature Install with Feature Stapling	Custom Page Feature Install with Feature Stapling	Custom Site Master Page Feature Stapling (WebApp Scope) Staple to all applicable SiteDefs	Custom System Master Page Feature Stapling (WebApp Scope) Staple to all applicable SiteDefs	Custom Master Page Install with Page-filtered HttpModule redirect	Custom Master Page Install with Page-filtered HttpModule redirect	Custom Master Page Install with MasterPage-specific HttpModule redirect	Multiple Custom Master Page Installs with MasterPage-specific HttpModule redirects	Multiple Custom Master Page Installs with MasterPage-specific HttpModule redirects
Inherited Embedded Functionality (change OOTB)	Custom Page Feature Install with Feature Stapling	Custom Page Feature Install with Feature Stapling	OOTB Component Copy Install with Custom Site Master Page Feature Stapling (WebApp Scope) Staple to all applicable SiteDefs	OOTB Component Copy Install with Custom System Master Page Feature Stapling (WebApp Scope) Staple to all applicable SiteDefs	OOTB Component Copy Install AND Custom Master Page Install AND Page-filtered HttpModule redirect	OOTB Component Copy Install AND Custom Master Page Install AND Page-filtered HttpModule redirect	OOTB Component Copy Install AND Custom Master Page Install AND MasterPage-specific HttpModule redirect	OOTB Component Copy Install AND Multiple Custom Master Page Installs AND MasterPage-specific HttpModule redirects	OOTB Component Copy Install AND Multiple Custom Master Page Installs AND MasterPage-specific HttpModule redirects
Inherited Embedded Functionality (add new)	Custom Page Feature Install with Feature Stapling	Custom Page Feature Install with Feature Stapling	New Component Install with Custom Site Master Page Feature Stapling (WebApp Scope) Staple to all applicable SiteDefs	New Component Install with Custom System Master Page Feature Stapling (WebApp Scope) Staple to all applicable SiteDefs	New Component Install AND Custom Master Page Install AND Page-filtered HttpModule redirect	New Component Install AND Custom Master Page Install AND Page-filtered HttpModule redirect	New Component Install AND Custom Master Page Install AND MasterPage-specific HttpModule redirect	New Component Install AND Multiple Custom Master Page Installs AND MasterPage-specific HttpModule redirects	New Component Install AND Multiple Custom Master Page Installs AND MasterPage-specific HttpModule redirects
Explicit Layout	Custom Page Feature Install with Feature Stapling	Custom Page Feature Install with Feature Stapling	n/a	n/a	KB944105 Method 2 OR OOTB Page Copy Install with Destination HttpModule redirect	KB944105 Method 2 OR OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Explicit Embedded Functionality (add/remove OOTB)	Custom Page Feature Install with Feature Stapling	Custom Page Feature Install with Feature Stapling	n/a	n/a	KB944105 Method 2 OR OOTB Page Copy Install with Destination HttpModule redirect	KB944105 Method 2 OR OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Explicit Embedded Functionality (change OOTB)	Custom Page Feature Install with Feature Stapling	Custom Page Feature Install with Feature Stapling	n/a	n/a	KB944105 Method 2 OR OOTB Page Copy Install with Destination HttpModule redirect	KB944105 Method 2 OR OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Explicit Embedded Functionality (add new)	Custom Page Feature Install with Feature Stapling	Custom Page Feature Install with Feature Stapling	n/a	n/a	KB944105 Method 2 OR OOTB Page Copy Install with Destination HttpModule redirect	KB944105 Method 2 OR OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Default Page Content	Feature with Page Manipulation Web Part AND Custom Master Page (Farm Scope) with Feature Stapling OR Custom Page Feature Install with Feature Stapling	n/a	n/a	n/a	n/a	n/a	n/a	n/a	n/a

Scope: Site/Site Collection

	Single Site Page	Single System Page	All Site Pages	All System Pages	Single SIMPLE LAYOUTS Page	Single non-SIMPLE LAYOUTS Page	All SIMPLE LAYOUTS Page	All non-SIMPLE LAYOUTS Pages	All LAYOUTS Pages
Non-structural look & feel	Page Settings, Customize Page via SP Designer	Customize Page via SP Designer	Site Settings, Site Theme, Stylesheet	Site Settings, Site Theme, Stylesheet	Custom Master Page Install AND Path -Specific HttpModule redirect	Custom Master Page Install AND Path -Specific HttpModule redirect	Custom Master Page Install AND Path+MasterPage-specific HttpModule redirect	Site Theme, Stylesheet	Site Theme/Stylesheet AND Custom Master Page Install AND Path+MasterPage-specific HttpModule redirect
Inherited Layout	Customize Page via SP Designer	Customize Page via SP Designer	Select new System Master Page OR Customize Master Page via SP Designer	Select new System Master Page OR Customize Master Page via SP Designer	Custom Master Page Install with Path -Specific HttpModule redirect	Custom Master Page Install with Path -Specific HttpModule redirect	Custom Master Page Install with Path+MasterPage-specific HttpModule redirect	Multiple Custom Master Page Installs with Path+MasterPage-specific HttpModule redirects	Multiple Custom Master Page Installs with Path+MasterPage-specific HttpModule redirects
Inherited Embedded Functionality (add/remove OOTB)	Customize Page via SP Designer	Customize Page via SP Designer	Select new System Master Page OR Customize Master Page via SP Designer	Select new System Master Page OR Customize Master Page via SP Designer	Custom Master Page Install with Path -Specific HttpModule redirect	Custom Master Page Install with Path -Specific HttpModule redirect	Custom Master Page Install with Path+MasterPage-specific HttpModule redirect	Multiple Custom Master Page Installs with Path+MasterPage-specific HttpModule redirects	Multiple Custom Master Page Installs with Path+MasterPage-specific HttpModule redirects
Inherited Embedded Functionality (change OOTB)	OOTB Component Copy Install with SPDesigner customization	OOTB Component Copy Install with SPDesigner customization	OOTB Component Copy Install with Custom Master Page	OOTB Component Copy Install with Custom Master Page	OOTB Component Copy Install AND Custom Master Page Install AND Path -Specific HttpModule redirect	OOTB Component Copy Install AND Custom Master Page Install AND Path -Specific HttpModule redirect	OOTB Component Copy Install AND Custom Master Page Install AND Path+MasterPage-specific HttpModule redirect	OOTB Component Copy Install AND Multiple Custom Master Page Installs AND Path+MasterPage-specific HttpModule redirects	OOTB Component Copy Install AND Multiple Custom Master Page Installs AND Path+MasterPage-specific HttpModule redirects
Inherited Embedded Functionality (add new)	New Component Install with SPDesigner customization	New Component Install with SPDesigner customization	New Component Install with Custom Master Page	New Component Install with Custom Master Page	New Component Install AND Custom Master Page Install AND Path -Specific HttpModule redirect	New Component Install AND Custom Master Page Install AND Path -Specific HttpModule redirect	New Component Install AND Custom Master Page Install AND Path+MasterPage-specific HttpModule redirect	New Component Install AND Multiple Custom Master Page Installs AND Path+MasterPage-specific HttpModule redirects	New Component Install AND Multiple Custom Master Page Installs AND Path+MasterPage-specific HttpModule redirects
Explicit Layout	Customize Page via SP Designer	Customize Page via SP Designer	n/a	n/a	OOTB Page Copy Install with Destination HttpModule redirect	OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Explicit Embedded Functionality (add/remove OOTB)	Customize Page via SP Designer	Customize Page via SP Designer	n/a	n/a	OOTB Page Copy Install with Destination HttpModule redirect	OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Explicit Embedded Functionality (change OOTB)	OOTB Component Copy Install with SPDesigner customization	OOTB Component Copy Install with SPDesigner customization	n/a	n/a	OOTB Page Copy Install with Destination HttpModule redirect	OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Explicit Embedded Functionality (add new)	New Component Install with SPDesigner customization	New Component Install with SPDesigner customization	n/a	n/a	OOTB Page Copy Install with Destination HttpModule redirect	OOTB Page Copy Install with Destination HttpModule redirect	n/a	n/a	n/a
Default Page Content	Browser-based Customization	n/a	n/a	n/a	n/a	n/a	n/a	n/a	n/a

Branding a MOSS Corporate Intranet Portal, Introduction

bgeoffro — Tue, 13 Nov 2007 03:09:00 GMT

We’re finally starting to tie a little bow around the branding effort for my customer’s MOSS intranet collaboration environment, so I’m finally taking the time to gather all the planning and design materials from the past month or two into something I hope the community finds useful. That, and the musical on the overhead screens is a less-than-compelling in-flight movie for my tastes, so I’ve got time to kill… J

Although this won’t be covered in bite-size tidbits, I’ll break this meal into three courses:

· Hearty Appetizer: High-level overview, terminology, and approach

· Entree: Branding Site & System Pages

o Covers a sample design of using a theme, custom master pages, features, and feature stapling to brand site & system pages at the webapp scope

· Dessert: Branding LAYOUTS Pages

o Covers a sample design of using an HttpModule and limited, supported means from KB944105 of customizing the LAYOUTS directory to brand LAYOUTS pages at the webapp scope

I hope my initial set of blog posts make your branding design, development, and implementation go a bit easier – it’s certainly made ours very manageable – and if it doesn’t, don’t be shy about telling me why not! Enjoy!

File name	Original Location	Redirect Location	Purpose	Notes
~~CORE.CSS~~	~~LAYOUTS\1033\STYLES~~	~~LAYOUTS\1033\STYLES\Customizations~~	~~Core stylesheet for WSS 3.0.~~	~~Includes customizations to the search control styles, which cannot be overridden by a theme.~~
NEW_application.master	LAYOUTS	LAYOUTS\Customizations	Master page for most non-dialog system pages.
NEW_simple.master	LAYOUTS	LAYOUTS\Customizations	Non-themed master page for all nonsecured system pages.
~~theme.css~~	~~LAYOUTS~~	~~LAYOUTS\Customizations~~	~~Used to apply styles of company standard theme to simple.master, which cannot retrieve site theme due to security restrictions.~~	~~Duplicate of themes.css from THEMES\CONTOSO .~~
templatepick.aspx	LAYOUTS	LAYOUTS\Customizations	Site Template selection page	Added reference to LAYOUTS\Customizations\theme.css
SiteManager.aspx	LAYOUTS	LAYOUTS\Customizations	Site Content & Structure page	Added custom header and footer