Brett's SharePoint Blog : MOSS

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.

Using custom scopes on multilanguage variation sites

bgeoffro — Sun, 24 May 2009 19:06:00 GMT

One of the great things about working on MOSS projects here in Europe is the prevalance of multilanguage requirements. You just don't encounter multilanguage requirements (at least on intranets & extranets) nearly as often in the US. I've had a lot of deep, hands-on experience with custom and variations-based multilanguage sites this year, and wanted to provide a heads-up regarding a problem and a novel solution when using variations and search.

The Problem

This is a pretty straightforward scenario you'd encounter if you are using variations to implement a multilanguage site. Assuming you've got the default shared scopes configured and are using a master page like default.master that uses the SmallSearchInputBox delegate control, here's the repro:

Create a new site collection in language X (English in this example).
Configure the site collection to use custom scopes (Site Actions > Modify All Site Settings > Site Settings > Search Settings > Use Custom Scopes).
Set the variation home ("/" in this example).
Create a variation label for language X (English in this example)
Create a variation label for language Y (Dutch in this example)
Create the variation hierarchies
Navigate to the welcome page for variation site in language X
Select the search dropdown control - "This Site:...", "All Sites", "People" appear in the list (these labels are different if language X is not English).
Navigate to the welcome page for variation site in language Y
Select the search dropdown control - "Deze Site:..." appears in the list (this label is different if language Y is not Dutch).

You'll find "All Sites" and "People" (and any other shared scopes) are missing for any variation site where the language is different from the root site. So where did they go?

The key question is, "why do items appear in the search dropdown control?" The dependency in question is a Search Display Group (Site Actions > Modify All Site Settings > Site Settings > Search Scopes). In single-language site collections, display groups and search scopes all use the same language, so no special configuration is necessary.

In Multilanguage site collections – such as those that use variations – there is an important difference in behaviors. As with single-language site collections, the search scopes and display groups are created in the top-level site’s language. However, some of the subsites are created in different languages. On each site, the search control will look for the scopes in the Search Dropdown display group (which is named differently for each language) to determine which scopes to show on the search control.

On the sites where the language is the SAME as the top-level site, all the scopes in the Search Dropdown display group will render – this is because the names of the Search Dropdown display group in the search settings and the search control match. For example, if the top-level site is English, the Search Dropdown display group is named “Search Dropdown”, and the search control on English sites will be looking for scopes in a display group named “Search Dropdown”.

On the sites where the language is DIFFERENT from the top level site, none of the scopes in the Search Dropdown display group will render – this is because the names of the Search Dropdown display group in the search settings and the search control do not match. For example, if the top-level site is English, the Search Dropdown display group is named “Search Dropdown”, and the search control on Dutch sites will be looking for scopes in a display group named “Vervolgkeuzelijst voor zoeken”, which does not exist.

The Design

Our solution was based on our requirements, which is to support the set of five languages required by our customer. The solution components are a single site collection-scoped feature with a feature receiver, which are manually activated as needed by site collection owners for sites that use variations. When the feature is activated, the feature receiver performs the following tasks:

Retrieves the list of five language-specific Search Dropdown display group names from the feature properties
Identifies the default scope in the existing Search Dropdown display group
Creates any of the Search Dropdown display group that do not exist
Ensures that all compiled shared search scopes are added to each search dropdown display group

The feature does NOT delete any of these display groups or their associated scopes upon deactivation, as it is not possible to determine which scopes were set manually. If additional language packs would be installed, we'd need to include the additional language-specific Search Dropdown display group names. Extending the feature to support additional languages simply requires adding a new property to the feature.xml <Properties/> element.

The Code

There are only two pieces to the solution - the feature manifest and the feature receiver. The example below just shows properties for two languages to keep things simple (and avoid problems handling unicode).

Feature.xml:

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

</Feature>

Feature receiver:

using System;

using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls;

using System.Web.UI.WebControls.WebParts;

using Microsoft.SharePoint;

using Microsoft.SharePoint.WebControls;

using Microsoft.SharePoint.WebPartPages;

using Microsoft.SharePoint.Navigation;

using Microsoft.SharePoint.Administration;

using Microsoft.Office.Server.Search.Administration;

namespace ScopeDisplayGroups {

public class FeatureReceiver : SPFeatureReceiver {

public override void FeatureActivated(SPFeatureReceiverProperties properties) {

SearchContext searchContext;

string currentGroupName = string.Empty;

using (SPSite currentSite = (SPSite)properties.Feature.Parent)

{

//retrieve current scope display groups from this site

searchContext = SearchContext.GetContext(currentSite);

Scopes scopes = new Scopes(searchContext);

ScopeDisplayGroupCollection scopeDisplayGroups = scopes.AllDisplayGroups;

Uri siteUri = new Uri(currentSite.Url);

ScopeDisplayGroup displayGroup = null;

Scope defaultScope = null;

//retrieve new scope display group labels from feature properties

//first, iterate through the scope display group labels to find the one that exists

//so we can identify the default scope

foreach (SPFeatureProperty featureProperty in properties.Feature.Properties)

{

currentGroupName = featureProperty.Value;

try

{

displayGroup = scopes.GetDisplayGroup(siteUri, currentGroupName);

defaultScope = displayGroup.Default;

}

catch (InvalidCastException ex)

{

//do nothing if group is not found

}

//retrieve new scope display group labels from feature properties

foreach (SPFeatureProperty featureProperty in properties.Feature.Properties)

{

currentGroupName = featureProperty.Value;

try

{

displayGroup = scopes.GetDisplayGroup(siteUri, currentGroupName);

//if display group exists, add any missing compiled shared scopes

//this is a "bonus feature", since API doesn't allow us to determine which scopes are OOTB

//normally only All Sites and People are added automatically to the search dropdown feature

foreach (Scope sharedScope in scopes.GetSharedScopes())

{

//only add shared scopes that are currently compiled AND are not part of display group

if (!displayGroup.Contains(sharedScope) &&

(sharedScope.CompilationState.Equals(ScopeCompilationState.Compiled)))

displayGroup.Add(sharedScope);

}

displayGroup.Update();

}

catch (InvalidCastException ex)

{

//if display group does not exist, create the new scope display group

ScopeDisplayGroup newDisplayGroup = scopeDisplayGroups.Create(currentGroupName, string.Empty, siteUri, true);

foreach (Scope sharedScope in scopes.GetSharedScopes())

{

//only add shared scopes that are currently compiled

if (sharedScope.CompilationState.Equals(ScopeCompilationState.Compiled))

newDisplayGroup.Add(sharedScope);

}

//if one was found, set the default scope to the same value for all new display groups

//AND move it to the first choice on the list

if (defaultScope != null)

{

newDisplayGroup.Remove(defaultScope);

newDisplayGroup.Insert(0, defaultScope);

newDisplayGroup.Default = defaultScope;

}

newDisplayGroup.Update();

}

scopes.Update();

}

public override void FeatureDeactivating(SPFeatureReceiverProperties properties) {

/* no op */

//do nothing - removing search scope display groups could be destructive

}

public override void FeatureInstalled(SPFeatureReceiverProperties properties) {

/* no op */

}

public override void FeatureUninstalling(SPFeatureReceiverProperties properties) {

/* no op */

}

Be sure to use paging in membership providers for the MOSS Profile Import Tool...

bgeoffro — Fri, 28 Mar 2008 01:14:00 GMT

Just a quick lesson learned on the MOSS Profile Import Tool to save you import time and resources.

The Profile Import Tool's current release has a hard-coded paging algorithm that attempts to page through any membership provider's GetAllUsers method by retrieving 1000 users at a time. If you DON'T support paging your GetAllUsers method - meaning you try to retrieve all users at once - then the import algorithm will retrieve and import all users N times, where N = (# users / 1000) . This becomes totally unmanageable - but a really good test for memory leaks in your provider - if you have many thousands of users... :)

The best practice is (if able) to add paging to your membership provider, since that will be useful in all calls to the GetAllUsers, FindUsersByName, and FindUsersByEmail methods, all of which will be used by SharePoint.

If you feel the need to alter this aspect of the Profile Import Tool's behavior - i.e. you have 100K users and don't want to take the time to build paging logic into your provider, or don't have access to the membership provider's source code - you'll find the paging logic in the ImportProvider.cs class. All you have to do is change the value of the pageSize constant to a sufficiently large value (i.e. 101000 if you have 100000 users), and you'll bypass the paging:

private const int pageSize = 1000;

If you choose to increase the pageSize value, make sure you have enough RAM to hold all those user records... and don't run the profile import application on a server that's hosting a RAM-intensive role like Query, Web App, or SQL.

Resolving Issues with Faulty Features and STSADM EXPORT

bgeoffro — Fri, 21 Mar 2008 17:29:00 GMT

If you're attempting an STSADM -o export (or, I'd assume, a content deployment) of a site and receive the following error:

FatalError: Failed to compare two elements in the array.

Check out the following KB article: http://support.microsoft.com/kb/948726/en-us .

The article indicates that the likely cause is one or more invalid feature references in the SPSite and/or SPWeb object. Fortunately, Steven Van de Craen authored a wonderful GUI tool for removing "faulty features" (which is of course unsupported and should be used with caution, but nonetheless very useful). See his article on the topic for more details.

Cases where you might encounter these errors:

Sites that were migrated from a MOSS Enterprise implementation (even if they're not USING Enterprise features) to a MOSS Standard implementation
Sites that were created in an beta version of MOSS/WSSv3
Sites which reference custom features that have since been removed from the filesystem but were not properly deactivated and uninstalled

List Attachments over 50MB need more than an increase in Maximum Upload Size...

bgeoffro — Wed, 19 Mar 2008 22:32:00 GMT

Chalk this down as the 1045th* time I've been reminded that you learn something new about SharePoint every day.

*The number of days I've been working with SharePoint... :)

Requirement:

Increase the maximum upload size for documents and attachments to 60MB for a web application

Apparent solution:

Connect to Central Admin
Navigate to Central Admin > Application Management > Web Application General Settings
Select your web application
Set the Maximum Upload Size value to 60 MB and hit OK.

Results:

Upload a 55MB document to a doclib - success.
Attach a 55MB file to a list item - receive the classic "An unknown error occurred" message, scratch head in puzzlement

Turns out there's a setting at the IIS level that will block list attachment uploads above 50MB. Below 50MB, any max upload size you pick (for example, 10MB) works fine for both list attachments and document uploads and is enforced directly through web app settings. Above 50MB, you need to make at least one minor tweak to your web.config to allow larger uploads.

Complete solution for max upload sizes over 50MB:

Connect to Central Admin
Navigate to Central Admin > Application Management > Web Application General Settings
Select your web application
Set the Maximum Upload Size value to "X" MB and hit OK.
Repeat steps 6-7 for all zones for your web application on all servers hosting the web application role
Open the web.config
Replace the following line:
<httpRuntime maxRequestLength="51200" />
with
<httpRuntime maxRequestLength="{X * 1024}" />

if you're using SQL storage for your SharePoint content, the maximum useful value for the maxRequestLength should be 2097152 (2GB in kilobytes = 2 * 1024 * 1024). Keep in mind that other limits may affect large uploads, most notably:

Site Collection Quota
Timeouts (you may need to adjust these in BOTH Web Application General Settings and the executionTimeout attribute of the <httpRuntime/> element)

Timeout settings will be influenced by network throughput limitations like latency and available bandwidth

Custom Storage Solution

External Blob Storage solution (see WSS SDK v1.3 for this feature that's new to WSS SP1) - whatever max BLOB size applies

Disk Space

If using SQL Storage, this is the disk containing your data files for your webapp's content DBs
If using an External Blob Storage solution, then this is wherever your blob store resides

For more on the httpRuntime web.config element, see http://msdn2.microsoft.com/en-us/library/e1f13641(VS.80).aspx .

MOSS User Profile Delete Tool

bgeoffro — Tue, 18 Mar 2008 17:01:00 GMT

For anyone using a custom authentication provider or non AD/LDAP* directory service, the Profile Import tool at http://www.codeplex.com/sptoolbox is an awesome tool for adding users. Just plug in your provider(s), tweak a few configuration settings, and go. I've used it to add 200,000+ user profiles from my customer's directory service (though I wouldn't recommend attempting to swallow all those records in one gulp - that requires more memory than we had on our import server) to our latest MOSS environment.

Getting the configuration "just right" resulted in my creating lots of extraneous user profiles in the environment. Not wanting to recreate the SSP or build up some serious callouses hitting the "delete" key hundreds of times, I spent quite a bit of time yesterday searching for a tool for doing mass deletes of user profiles, to no avail. I did, however, find a number of postings for other folks out there looking for a similar tool.

So I put together a quick-and-dirty command-line app for nuking your entire user profile DB or a portion thereof based on account name matches. You could modify this pretty easily to include more sophisticated filter criteria, like an existence check in your directory service of choice, but I didn't want to spend more than an hour on the script... :)

* You'd also need to use the Profile Import tool if you need to do an authenticated bind to your LDAP service using something other than Windows credentials.

Configuration File:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
  <add key="test" value="false"/>
  <add key="debug" value="true"/>
  <add key="filterPattern" value="qaldap:"/>
</appSettings>
</configuration>

Configuration Comments:

Here's how to use the config settings:

filterPattern

case-insensitive string used for a "starts with" match on user profile Account Names - i.e. "myprovider:" would be a match for all user profiles that use the provider "myprovider", or "mydomain\" would match all user profiles from the "mydomain" domain

test - used to control whether delete actions occur

true (default) - user profiles matching the filterPattern are reported as matches for deletion, but no delete actions occur
false - all user profiles matching the filterPattern are deleted

debug

true - application info/warning/error events are written to the console
false (default) - application events are written only to the event log

Source Code:

The code is pretty simple. Main is where the action is for retrieving/deleting user profiles and reading the config file; if you need to plug in a different algorithm for identifying profiles to be deleted (like an existence check in your directory service), you'd add it here. GetAnySiteUrl is copied directly from the Profile Import tool to save coding time in establishing a server context; if you have multiple SSPs, you might want to update the way you establish a context.

If you're using only 1 SSP and are OK with the simple "starts with" pattern match algorithm, just put the right references in your project, build it, and you're ready to go. Enjoy!

using System;
using System.Collections.Generic;
using System.Collections.Specialized;
using System.Text;
using System.Diagnostics;
using System.Configuration;

using Microsoft.Office.Server;
using Microsoft.Office.Server.UserProfiles;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;

namespace ProfileDelete
{
    class Program
    {
        static int logLevel = 1;
        static bool debug = false;
        static bool test = true;
        static string logSource = "ProfileDelete";
        static string logDestination = "Application";
        static string filterPattern = "";

        static void Main(string[] args)
        {
            int counter = 0;

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

                NameValueCollection appSettings = ConfigurationManager.AppSettings;
                logLevel = Convert.ToInt32(appSettings["loglevel"]);
                debug = Convert.ToBoolean(appSettings["debug"]);
                test = Convert.ToBoolean(appSettings["test"]);
                filterPattern = appSettings["filterPattern"];
            }
            catch (Exception e)
            {
                DoLog("Error reading configuration file:" + e.ToString(), EventLogEntryType.Error, 100);
            }

string currentAccountName = String.Empty;

using (SPSite site = new SPSite(GetAnySiteUrl()))
{

ServerContext context = ServerContext.GetContext(site);

UserProfileManager profileManager = new UserProfileManager(context);

                foreach (UserProfile profile in profileManager)
                {
                    currentAccountName = (String) profile[PropertyConstants.AccountName].Value;
                    currentAccountName = currentAccountName.ToLower();

                    if (currentAccountName.StartsWith(filterPattern.ToLower()))
                    {
                        counter++;
                        DoLog(currentAccountName + " matches delete criteria. Count: " + counter, EventLogEntryType.Information, 110);
                        if (!test)
                        {
                            DoLog("Deleting " + currentAccountName, EventLogEntryType.Information, 120);
                            profileManager.RemoveUserProfile(profile.ID);
                        }
                    }
                }
            }

}

        private static string GetAnySiteUrl()
        {
            //the purpose of this function is just to get any site Url so that
            //we can obtain a ServerContext for the UserProfileManager
            string ret = string.Empty;

SPWebServiceCollection wsc = null;

            try
            {
                wsc = new SPWebServiceCollection(SPFarm.Local);
                foreach (SPWebService sw in wsc)
                {
                    foreach (SPWebApplication wa in sw.WebApplications)
                    {
                        if (wa.Sites.Count > 0)
                        {
                            ret = wa.Sites[0].Url;
                            break;
                        }
                        if (!string.IsNullOrEmpty(ret))
                            break;
                    }
                    if (!string.IsNullOrEmpty(ret))
                        break;
                }
            }
            catch (Exception ex)
            {
                throw new Exception("Error getting a site Url: " + ex.Message);
            }
            finally
            {
                wsc = null;
            }

return ret;
}

        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);
            }
        }

}
}

SharePoint AcademyLive Recommended Readings

bgeoffro — Wed, 13 Feb 2008 00:50:00 GMT

This won't mean too much for those of you who aren't attending the AcademyLive courses, but here are some recommended readings on two topics we were discussiong today - Security & Information Architecture.

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