Brett's SharePoint Blog

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.

Adventures in Regional Settings with Content Query Web Parts & RSS Viewer Web Parts

bgeoffro — Sun, 21 Jun 2009 19:32:00 GMT

Here's another interesting one I encountered with multilanguage WCM sites while living here in Europe. Seems simple enough, but as always with multilanguage sites, appearances can be deceiving...

The Requirement

This one's pretty basic. We've got a couple of big lines of business for my customer, and they each have large intranet portals that use CQWPs to aggregate intra-site content and RSS Viewers to aggregate content from outside the site collection. In the course of building their portals, the site owners came up with the fairly common requirement of developing site collection-specific styles for presenting content in these CQWPs and RSS Viewers - special formatting for titles, descriptions/content, and authors, images, etc. Rules of engagement for this environment forbade customizations without a strong business case, so we were limited to OOTB web parts, browser-based customizations, and SPD-based customizations.

The Initial Solution

The RSS Viewer solution was a simple design pattern. Develop the custom XSL, embed it in the .webpart configuration info, and install the .webpart in the Web Part Gallery for the site.

The CQWP solution was only slightly more complicated. Develop the custom XSL, install it in the Style Library, update the .webpart configuration info to reference the custom style sheet instead of ItemStyle.xsl, and install the .webpart in the Web Part Gallery for the site.

The Complication

The site collections involved here had sites in more than one language in each site collection, as they were using variations. This means that the formatting of dates in the RSS Web Parts and CQWPs could be an issue - using a static date format as per the customer's original specifications would be a problem. For example, sites with the English-US region would use the M/D/YYYY date format, while sites with the Dutch-NL region would use D-M-YYYY format for all standard fields. If we hardcoded one of these formats in the RSS Viewers or CQWPs, we could potentially have dates appearing in multiple formats on any given page. Ugly.

Fortunately, there's a handy XSL function in the ddwrt namespace called "FormatDate" for addressing this issue - it takes a string, LCID, and format type as arguments to adjust the date format, as described here. Unfortunately, there are two major problems in getting the right LCID unless you can extend these webparts:

The RSS Viewer Web Part has a hardcoded parameter in its XSL that sets the LCID to 1033. It has nothing to do with the Regional Settings for the site.
With CQWPs, there is no LCID parameter at all that is accessible to the XSL.

What to do?

The Solution (Browser/SPD Customizations Only)

For the CQWPs, we're fortunate enough to be able to select from the multiple styles at our disposal via the XSL file in the Styles Library. For each item style that includes a date, we can simply create a separate template for each language - the same template, with a different LCID argument and a different name. For example, we could have "Date and Title (Dutch-NL)" and "Date and Title (English-US)" as separate item styles. Train the users to select the appropriate style for that site. Slightly ugly implementation, but user-friendly if you have a limited number of languages, and it sticks to the rules of keeping the customizations within the site collection. Solution architecture remains unchanged - we just have slighly more elaborate XSL.

For the RSS Viewer, things get uglier. The only way of selecting the XSL is by specifying a URL to an external XSL file in the "XSL Link" field. So you have one of two options:

Store a version of the RSS XSL for each language and train users to select the right one
Store a version of the RSS Viewer for each language and train users to select the right one. I prefer this option since it's simpler from a training perspective.

The Real Solution

Both of the workarounds above are only practical if you have a very small number of languages and can absorb the training costs for a small pool of content authors. For an enterprise-level deployment of this kind of functionality, you need to implement custom versions of the CQWP and RSS Viewer that can pull the LCID out of the SPWeb.RegionalSettings and pass it to the XSLT (or find third-party versions that do the same).

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 */

}

Addressing Vanity URLs in a Content Migration

bgeoffro — Thu, 21 May 2009 11:20:00 GMT

It's been a blistering few months prepping for MCM, going through the MCM program, and getting caught up on the massive backlog of work and life that occurs when you tell coworkers, friends, and family that you'll be dropping off the face of the earth for three weeks. :) Now that I finally have a breather to start assimilating some of the novel and interesting lessons learned on my recent projects, here goes item #1...

The Problem

We've been migrating a large corporate intranet from Lotus Notes to MOSS. As you may have surmised from my previous post about maintaining link integrity, one of the many problems we needed to address was updating existing Lotus Notes URLs in the content to their new MOSS-based URLs.

At a high level, the migration tools executed a two-stage process - convert content from Notes to SharePoint, then update any Notes links in the content to reference their new SharePoint links. However, there was one class of heavily utilized links that weren't in the content, and therefore couldn't be updated by any tool - these were hundreds of "vanity URLs" that were referenced in thousands of users' bookmarks and in unknown numbers of non-Notes systems and files. For example, these were URLs like http://vacation (redirecting to http:/{notes server address for the vacation policy page in an HR intranet site}) or http://someeventname (redirecting to the announcement page for some big annual company event).

Before the migration, this is the way these vanity URLs worked:

DNS mapped the vanity URL to the VIP for the Notes servers
(black box, but you get the idea) The Notes server contained a mapping of a particular host header to a deep URL.

Since these aliases weren't content, there was no way to convert them. Also, since there were hundreds of vanity URLs, we needed a way to implement the redirects in such a way that the migration tool would be able to update the redirect links in an automated fashion. As a secondary goal, many of these vanity URLs had been around for ages and were due for a cleanup, so a convenient means of tracking their usage would aid in retiring the unused ones, which incurred additional configuration overhead.

The Solution

We already had a tool for updating Notes links in SharePoint content to the new format/location, so the simplest solution was to transform the redirects into SharePoint content. Here are the basic requirements and approaches we took to address them:

Requirement: Map host headers to SharePoint content with a minimum of overhead

Approach: Use host header site collections as the basis for this solution. One host header site collection per vanity URL.

Requirement: Minimize configuration effort for creating the content

Approach: Script the creation of the host header site collections via STSADM.

Requirement: Implement a standard way of configuring redirects

Approach: Implement a standard "redirect control" on the host header site collection home pages that used configurable settings to execute a redirect to an arbitrary URL.

Requirement: Minimize configuration effort for implementing the redirects

Approach: Enable script-based configuration of the redirect settings via STSADM.

Requirement: Minimize configuration effort for permissioning the redirect sites for all intranet users (anonymous and authenticated)

Approach: Enable script-based configuration of anonymous authentication settings via STSADM.

Requirement: Minimize the payload of redirect pages

Approach: Apply a master page to the host header site collections that renders an absolute minimum of content.

Requirement: Enable vanity URL owners to track their usage

Approach: Having one host header site collection per vanity URL provides standard SharePoint usage tracking info that is available to each site owner.

Requirement: Keep it simple

Approach: Create a new "redirect site" site definition that is based largely on the Blank Site site definition.

So to summarize, we would create a new site definition based on the Blank Site site definition with a lean, mean master page, and a built-in redirect control on the default page. We'd create these sites as host header site collections via STSADM and extend STSADM to enable us to script their creation and the configuration of the redirect links. There's a little more to this on the infrastructure side (DNS and IIS configuration are the most notable), but to keep the focus on the SharePoint part of the solution, the key thing to note is that once the new SharePoint sites were in production, the key cutover task was to change the DNS records for the alias sites from the Notes VIP to the SharePoint farm VIP.

The Design

There are two sets of components to the design - the UI components and the management features.

UI Components

The Redirect Site solution consists of a site definition, a feature, and a web control.

The site definition is a copy of the Blank Site site definition, with the following change:

· Default.aspx

o The SimpleRedirect.ascx control was registered with the page.

o A reference to the SimpleRedirect control was added to the PlaceHolderAdditionalPageHead placeholder.

o The master page was changed to empty.master.

· ONET.xml

o Elements that are not relevant to the Blank Site site definition (i.e. Team Site and Document Workspace-only elements) were removed

o A <Feature/> element for the Redirect Site Master Page Feature was added.

The Redirect Site Master Page Feature installs the empty.master master page in the master page library for the Redirect Site. All placeholders on the master page are set with Visible=”false”.

The SimpleRedirect.ascx web control renders a simple META REFRESH tag (http://msdn.microsoft.com/en-us/library/bb159711.aspx ), using the following property bag values:

· REDIRECT_URL – The URL to be loaded.

· REDIRECT_TIME – The delay in seconds to be applied before loading the REDIRECT_URL.

When users navigate to the base URL for a redirect site, the default page loads, using the very streamlined empty.master page, and rendering the SimpleRedirect web control, causing them to be redirected to the REDIRECT_URL within REDIRECT_TIME seconds.

Both the site definition and the feature are hidden, as they are never intended for use by end users.

Management Components

The management functionality required two new commands - setbagproperty and setanonymousaccess - and a third was added for convenience (getbagproperty).

The setbagproperty command has the following syntax:

stsadm -o setbagproperty -url <url> -propertykey <keyname> -propertyvalue <value>

Where the placeholders above have the following usage:

· url – the URL to the SPWeb to be updated

· keyname – the property key to be created (if it does not exist) or updated (if It does exist)

· value – the value to be set for the specified property key

Example – setting the value of the “test” property to “thisvalue” for the web http://intranet.example.com/sites/testsite :

stsadm -o setbagproperty -url http://intranet.example.com/sites/testsite -propertykey test -propertyvalue thisvalue

The getbagproperty command has the following syntax:

stsadm -o setbagproperty -url <url> -propertykey <keyname>

Where the placeholders above have the following usage:

· url – the URL to the SPWeb to be updated

· keyname – the property key whose value is to be retrieved

Example – retrieving the value of the “test” property for the web http://intranet.example.com/sites/testsite :

stsadm -o setbagproperty -url http://intranet.example.com/sites/testsite -propertykey test

The setanonymousaccess command has the following syntax:

stsadm -o setanonymousaccess -url <url> -state <state>

Where the placeholders above have the following usage:

· url – the URL to the SPWeb whose anonymous access settings are to be configured

· state – anonymous access state, which should be one of the following:

o 0 – Disabled: Specifies that anonymous users have no access to a Web site.

o 1 – Enabled: Specifies that anonymous users can access lists and libraries if the lists and libraries allow anonymous access.

o 2 – On: Specifies that anonymous users can access the entire Web site. This setting means that the value of the AnonymousPermMask64 property depends on the permission mask for the Limited Access role.

Example – enabling anonymous users to access lists and libraries if the lists and libraries allow anonymous access for the web http://intranet.example.com/sites/testsite :

stsadm -o setanonymousaccess -url http://intranet.example.com/sites/testsite -state 1

The Code

Here are a few of the novel components of the solution in case you find them useful - STSADM extensions and the redirect control.

SimpleRedirect.ascx

<%@ Control Language="C#" compilationMode="Always" %>

<%@ Import Namespace="Microsoft.SharePoint" %>

<%@ Import Namespace="Microsoft.SharePoint.WebControls" %>

<%@ Import Namespace="Microsoft.SharePoint.Utilities" %>

SPWeb web = SPControl.GetContextWeb(Context);

string strRedirectMetaTag = string.Empty;

if ((web.Properties.ContainsKey("REDIRECT_URL")) && (web.Properties.ContainsKey("REDIRECT_TIME")) )

{

strRedirectMetaTag = "<META http-equiv=\"REFRESH\" content=\"" + web.Properties["REDIRECT_TIME"] + ";url=" + SPHttpUtility.HtmlEncode(web.Properties["REDIRECT_URL"]) + "\">";

}

<%=strRedirectMetaTag%>

GetBagProperty.cs:

using System;

using System.Collections.Generic;

using System.Text;

using Microsoft.SharePoint.StsAdmin;

using Microsoft.SharePoint;

namespace SharePoint.StsAdmin

{

public class GetBagProperty : ISPStsadmCommand

{

#region ISPStsadmCommand Members

const string USAGE_SYNTAX = "stsadm -o getbagproperty -url <url> -propertykey <keyname>";

public string GetHelpMessage(string command)

{

return USAGE_SYNTAX;

}

public int Run(string command, System.Collections.Specialized.StringDictionary keyValues, out string output)

{

output = string.Empty;

string strWebUrl = string.Empty;

string strPropKey = string.Empty;

//read in the arguments

if (keyValues.ContainsKey("url"))

{

strWebUrl = keyValues["url"];

}

if (keyValues.ContainsKey("propertykey"))

{

strPropKey = keyValues["propertykey"];

}

//confirm that all required arguments are present

if ((strPropKey.Length > 0) && (strWebUrl.Length > 0))

{

try

{

using (SPSite siteCol = new SPSite(strWebUrl))

{

//use the utility to obtain the actual web's url

string webUrl = Utility.GetWebUrl(strWebUrl, siteCol.ServerRelativeUrl);

using (SPWeb web = siteCol.OpenWeb(webUrl))

{

if (web.Properties.ContainsKey(strPropKey))

output += string.Format("Property found. Value: {0}", web.Properties[strPropKey]);

else

output += "Property does not exist.";

}

catch (Exception ex)

{

output += ex.Message;

}

else

{

output += "Missing argument.\r\n" + USAGE_SYNTAX;

}

return 0;

}

#endregion

}

SetBagProperty.cs:

using System;

using System.Collections.Generic;

using System.Text;

using Microsoft.SharePoint.StsAdmin;

using Microsoft.SharePoint;

namespace SharePoint.StsAdmin

{

public class SetBagProperty : ISPStsadmCommand

{

#region ISPStsadmCommand Members

const string USAGE_SYNTAX = "stsadm -o setbagproperty -url <url> -propertykey <keyname> -propertyvalue <value>";

public string GetHelpMessage(string command)

{

return USAGE_SYNTAX;

}

public int Run(string command, System.Collections.Specialized.StringDictionary keyValues, out string output)

{

output = string.Empty;

string strWebUrl = string.Empty;

string strPropKey = string.Empty;

string strPropValue = string.Empty;

//read in the arguments

if (keyValues.ContainsKey("url"))

{

strWebUrl = keyValues["url"];

}

if (keyValues.ContainsKey("propertykey"))

{

strPropKey = keyValues["propertykey"];

}

if (keyValues.ContainsKey("propertyvalue"))

{

strPropValue = keyValues["propertyvalue"];

}

//confirm that all required arguments are present

if ((strPropValue.Length > 0) && (strPropKey.Length > 0) && (strWebUrl.Length > 0))

{

try

{

using (SPSite siteCol = new SPSite(strWebUrl))

{

//use the utility to obtain the actual web's url

string webUrl = Utility.GetWebUrl(strWebUrl, siteCol.ServerRelativeUrl);

using (SPWeb web = siteCol.OpenWeb(webUrl))

{

if (web.Properties.ContainsKey(strPropKey))

{

output += "Key exists - updating.\r\n";

web.Properties[strPropKey] = strPropValue;

}

else

{

output += "Key does not exist - adding.\r\n";

web.Properties.Add(strPropKey, strPropValue);

}

web.Properties.Update();

}

output += "Property set.";

}

catch (Exception ex)

{

output += ex.Message;

}

else

{

output += "Missing argument.\r\n" + USAGE_SYNTAX;

}

return 0;

}

#endregion

}

SetAnonymousAccess.cs:

using System;

using System.Collections.Generic;

using System.Text;

using Microsoft.SharePoint.StsAdmin;

using Microsoft.SharePoint;

namespace SharePoint.StsAdmin

{

public class SetAnonymousAccess : ISPStsadmCommand

{

#region ISPStsadmCommand Members

const string USAGE_SYNTAX = "stsadm -o setanonymousaccess -url <url> -state <state>"

+ "\r\n\r\n\tState Values:" + "\r\n\t0: Disabled" + "\r\n\t1: Enabled" + "\r\n\t2: On";

public string GetHelpMessage(string command)

{

return USAGE_SYNTAX;

}

public int Run(string command, System.Collections.Specialized.StringDictionary keyValues, out string output)

{

output = string.Empty;

string strWebUrl = string.Empty;

string strState = string.Empty;

string strNewState = string.Empty;

int state = -1;

//read in the arguments

if (keyValues.ContainsKey("url"))

{

strWebUrl = keyValues["url"];

}

if (keyValues.ContainsKey("state"))

{

strState = keyValues["state"];

try

{

state = Convert.ToInt32(strState);

}

catch (FormatException fex)

{

output += "Invalid argument for state parameter.";

return 0;

}

catch (OverflowException oex)

{

output += "Invalid argument for state parameter.";

return 0;

}

//confirm that all required arguments are present and valid

if ((state > -1) && (state < 3) && (strWebUrl.Length > 0))

{

try

{

using (SPSite siteCol = new SPSite(strWebUrl))

{

//use the utility to obtain the actual web's url

string webUrl = Utility.GetWebUrl(strWebUrl, siteCol.ServerRelativeUrl);

using (SPWeb web = siteCol.OpenWeb(webUrl))

{

if (state == 0)

web.AnonymousState = SPWeb.WebAnonymousState.Disabled;

else if (state == 1)

web.AnonymousState = SPWeb.WebAnonymousState.Enabled;

else if (state == 2)

web.AnonymousState = SPWeb.WebAnonymousState.On;

strNewState = web.AnonymousState.ToString();

}

output += "Anonymous access state set to " + strNewState;

}

catch (Exception ex)

{

output += ex.Message;

}

else

{

output += "Missing or invalid argument.\r\n" + USAGE_SYNTAX;

}

return 0;

}

#endregion

}

Preventing and Managing Broken Links in SharePoint

bgeoffro — Wed, 22 Oct 2008 23:19:00 GMT

Link Integrity Management: Processes, Tactics, and Solutions

One lengthy and complex topic I recently discussed with a customer is link integrity management – how to keep links from breaking when you move and rename things. Turns out there are several dimensions to this problem and a wide array of tactics for addressing the many scenarios that can lead to broken links. I did a bit of research around the web and found quite a few processes, tactics, and a couple of technical solutions to mitigate these issues. We’re using a combination of all of them for this intranet publishing & collaboration deployment, so I thought I’d share the generic recommendations we came up with. Here goes…

The solutions for addressing link integrity issues typically include one or more of the following types of components:

· Training to prevent and reduce the occurrence of link integrity issues

· Proactive business processes to prevent link integrity issues

· Reactive business processes to correct link integrity issues

· Tools to identify link integrity issues reactively or proactively

· Tools to avoid or mitigate the impact of link integrity issues

Evaluating Effectiveness

When you’re comparing these options, you need to examine two aspects of their effectiveness: link sources and link destinations.

Link sources are the container for a link, and I decomposed these into the following four types:

· Intra-Site Collection

· Intra-SharePoint

· External Web Sites

· Bookmarks/Files

The link source matters because certain solutions rely on detecting a broken link and fixing it at the source – i.e. changing http://old to http://new – and certain solutions can only affect specific sources.

Link destinations are the endpoint of the link – I decomposed these into the following eight groups of SharePoint objects:

· Site Collections

· Sites

· Libraries & Lists

· Folders

· Content Pages (AKA Publishing Pages)

· Web Part & Basic Pages

· Files

· Items

As with link sources, certain solutions can only affect specific endpoints, as they rely on applying some type of redirection to reroute traffic from http://old to http://new .

Of course, effectiveness is the “benefits” side of the equation, so you also need to factor in the “costs” side as well, which range from free to hugely expensive (which isn’t always obvious). Now onto the solutions and my thoughts on each…

Site Design Practices

Site design practices should be part of standard SharePoint training for content authors and site owners. Renaming and moving content can often be avoided by using standard SharePoint navigation controls and features for organizing and viewing content. When moving and renaming content is required, a number of built-in tools for updating links, implementing redirects and analyzing the impact of these changes can mitigate the scope of link integrity issues.

Example practices for avoiding/mitigating link integrity issues include:

· Avoid renaming documents & files. Use the Title field – don’t rename the file.

· Avoid restructuring libraries & lists

o Avoid folders or keep folder structures SIMPLE so that they are less likely to change

o Use views and metadata to organize contents instead

o Don’t use document libraries simply to categorize documents – different libraries should be created to support different metadata, permissions, policies, workflows etc.

· Always implement a Redirect Page when moving Content Pages. The redirect page is a standard page layout that content authors can use to quickly implement a redirect.

· Always implement a Content Editor Web Part-based redirect when moving Web Part Pages or Basic Pages. Savvy users can insert an HTML snippet in Content Editor Web Parts to implement a redirect to another page.

· Always have a communications plan for your site – notify users well in advance of any major restructuring

· Use the site usage reports PROACTIVELY to notify users who may be impacted by site restructuring

· Review Redirect Page traffic in usage reports to determine if they are still needed

· Review 404 reports to identify users and sites with broken links. This requires a 404 reporting solution as described later.

· Review 404 reports to identify needed redirect pages. This requires a 404 reporting solution as described later.

Solution Scope

Site Design Practices mitigate broken link issues across all link sources: intra site collection, intra-SharePoint, other web sites, and bookmarks/files. They don’t eliminate issues because they are largely dependent on people and processes, but the adherance to those processes is what counts.

Site Design Practices are effective for all major link destinations: Site Collections, Sites, Libraries & Lists, Folders, Content Pages, Web Part & Basic Pages, Files, and Items

Analysis

Good site design practices reduce the occurrence of link integrity issues on all scopes and components. Good site management practices – in the form of communication plans and usage report analysis – reduce the impact of all link integrity issues whenever they occur. These best practices have negligible additional cost in relation to generally recommended training deliveries for site owners and content authors.

For more information

http://technet.microsoft.com/en-us/library/cc261852.aspx

404 Reporting and Fixing – Broken Link Crawler

A broken link crawler is a tool that crawls one or more web sites, checks for 404 errors on all accessible pages in the site, and produces a report of the source and destination URLs for those 404 errors. They also typically produce a list of all links crawled and have mechanisms for seeking particular URL patterns.

Popular broken link crawler tools include:

· Xenu Link Sleuth

· LinkScan

Some of these tools can be used proactively to crawl content for a base URL in preparation for a move. These reports enable the content owners with links to content that is going to be moved/renamed to update their links in advance or otherwise time the update of their links to coincide with the move of the external site.

All of these tools can be used reactively to identify broken links in these sites. These reports enable the content owners with broken links to identify content in need of updating.

Solution Scope

Broken link crawlers can eliminate broken link issues across three link sources: intra site collection, intra-SharePoint, and KNOWN web sites. They are ineffective for dealing with links in user bookmarks/files, and they may encounter problems parsing some file formats and working within some security frameworks.

Broken link crawlers are effective for all major link destinations: Site Collections, Sites, Libraries & Lists, Folders, Content Pages, Web Part & Basic Pages, Files, and Items

Analysis

Proactive use of these broken link crawlers is appropriate in advance of a major site collection or site restructuring, or major structural change to a very large document library. Site owners must be trained in advance to plan to request these reports. These reports are computationally expensive to produce since they add traffic to all systems examined by the tool, so they are not for casual use.

Reactive use of broken link crawlers should be conducted on a regular basis – i.e. weekly, monthly, quarterly reports that are submitted to all site owners of the source content site. This empowers site owners to better manage their site content.

Broken link crawlers cannot affect change for unreported sites and systems, nor can they scan user bookmarks – they can only produce reports for web sites that are accessible to the crawler.

Some of these tools are free, but the resources required to use them and integrate them into administration processes are not. Custom solutions are typically required to direct these reports to the appropriate site owners. They offer the most benefits for large migrations or restructuring efforts for sites that primarily render HTML content.

404 Reporting and Fixing – 404 Report Analysis

“404 reports” can be obtained directly from the IIS logs of MOSS servers. These logs show what broken links are receiving traffic and also importantly, who is attempting to access these URLs. Reports created from this data can easily identify the most frequently accessed 404 pages.

Solution Scope

404 reporting & fixing can mitigate broken link issues across all link sources: intra site collection, intra-SharePoint, web sites, and user bookmarks/files.

404 reporting & fixing is effective for all major link destinations: Site Collections, Sites, Libraries & Lists, Folders, Content Pages, Web Part & Basic Pages, Files, and Items

Analysis

Using 404 reports to address broken links is purely reactive measure, but it works for all logical architecture components. For existing sites, site owners can review the 404 reports and contact the user(s) who hit the broken links or, in the case of pages, implement a redirect. For sites that have moved, farm administrators can stake the same actions, since there would be no clear owner to a site that no longer exists at a given URL.

404 reports are not readily available to site owners, and are not easily compiled by farm administrators (especially in environments with more than one web front end server). Delivering 404 reports to both sets of users would require a custom solution which could also leverage a tool like LogParser or WebTrends to compile the reports.

For more information

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ab7e4070-e185-4110-b2b1-1bcac4b168e0.mspx?mfr=true

http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en

“Smart” 404 Page

The standard 404 page simply presents a “404-page not found” message to the user. A “smart” 404 page would improve the user experience by providing richer features for finding the content the user is seeking, although not address the root cause of the missing object.

Solution Scope

A Smart 404 Page can mitigate broken link issues across all link sources: intra site collection, intra-SharePoint, web sites, and user bookmarks/files.

A Smart 404 Page is effective for all major link destinations except Site Collections: Sites, Libraries & Lists, Folders, Content Pages, Web Part & Basic Pages, Files, and Items. Attempts to access a moved/missing site collection root will result in an ordinary 404 page.

Analysis

A smart 404 page would, at a minimum, include SharePoint search results based on the terms in the URL that produced the 404 error. It could also include basic information, such as whether the site, list, or other container object currently exists or has been moved; or contact information for an existing site. Further, a smart 404 page could be used to trigger events for reactive measures, like notifying site owners or farm administrators.

A smart 404 page is a relatively simple customization to implement, as it could be based on an existing Codeplex project (http://www.codeplex.com/sharepointsmart404 ). Each component added to the Smart 404 page beyond the search results may require additional work.

For more information

http://www.codeplex.com/sharepointsmart404

http://www.sharepointbrainfreeze.com/archive/2008/09/29/creating-a-enhanced-moss-404-feature-part-1.aspx

http://blogs.msdn.com/jingmeili/archive/2007/04/08/how-to-create-your-own-custom-404-error-page-and-handle-redirect-in-sharepoint-2007-moss.aspx

Content Page Redirects

The Redirect Page is a standard page layout included in the MOSS Publishing Features that content authors can use to quickly implement a redirect. Authors use it to capture the new URL for a content page, whereupon the redirect mechanism on the page causes the user’s request to be redirected to the new URL if they hit the Redirect Page.

Though they can be implemented manually, one customization that could simplify the task of moving a single content page would be offering a new custom action that collapses the tasks of moving a content page and constructing a Redirect Page into a single step.

Solution Scope

Content Page Redirects can eliminate broken link issues across all link sources: intra site collection, intra-SharePoint, web sites, and user bookmarks/files.

Content Page Redirects are only effective for Content Page objects.

Analysis

Content Page Redirects can always be created manually. A “move and create redirect page” custom action would be an alternative available to content authors in addition to the standard tools they could use for moving content pages in SharePoint, such as Explorer View and SharePoint Designer. This action would provide link integrity across any scope for any content page moved in this manner.

Generation of redirect pages for content page moves should NOT be automated, as that could generate massive numbers of redirect pages, thereby slowing down requests, increasing storage requirements, and greatly increasing content complexity. Nearly all redirects are intended to be used for a limited period of time until communications have caught up with restructuring actions, so automated generation should be optional, not automatic.

Content authors on publishing sites must be trained in the use of Redirect Pages. Developing a custom action to simplify the process of cross site-collection moves of content pages would require a relatively simple customization – adding a custom Page Editing Menu item and a custom action associated with it.

For more information

http://office.microsoft.com/en-us/sharepointserver/HA101575641033.aspx

http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?List=56f96349%2D3bb6%2D4087%2D94f4%2D7f95ff4ca81f&ID=48

Web Part Page Redirects

Web part pages and basic pages don’t have an equivalent to the Redirect page layout, but users can insert an HTML snippet in Content Editor Web Parts on web part pages to implement a redirect to another page. Content authors of content pages that contain web part zones can use the same approach for implementing a redirect.

Implementing this type of redirect requires some HTML knowledge, though a relatively simple custom “Redirect” web part could simplify this task and make it readily available for all users.

Solution Scope

Web Part Page Redirects can eliminate broken link issues across all link sources: intra site collection, intra-SharePoint, web sites, and user bookmarks/files.

Web Part Page redirects are only effective for Content Pages, Web Part Pages, and Basic Pages.

Analysis

These types of redirects work for all scopes for all content pages, web part pages, and basic pages to which they are applied. A custom redirect web part would include, at a minimum, a redirect message, a redirect URL, and a time period for pausing before the redirect action occurs. These parameters would be simple configuration settings for the web part.

Implementing a custom web part with these specifications would be a simple customization that would be considerably more cost-effective than supporting training issues relating to authoring HTML redirects or correcting issues with HTML redirects.

For more information

http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?List=56f96349%2D3bb6%2D4087%2D94f4%2D7f95ff4ca81f&ID=48

Site Collection/Site Redirects – IIS-based

An IIS-based redirect is an IIS virtual directory that uses a pattern match of arbitrary complexity to redirect URLs matching that pattern to other URL– for example, redirecting all traffic to http://sharepoint.ing.com/sites/oldsite to http://sharepoint.ing.com/sites/newsite for all URLs in oldsite.

Solution Scope

IIS-based redirects initially eliminate broken link issues across all link sources: intra site collection, intra-SharePoint, web sites, and user bookmarks/files, but their quality may degrade over time.

IIS-based redirects areeffective for all major link destinations within their associated container (a site collection or site): Site Collections, Sites, Libraries & Lists, Folders, Content Pages, Web Part & Basic Pages, Files, and Items.

Analysis

IIS-based redirects work for all scopes and object types for the base URL used in the redirect, whether that is a site collection, site, or lower logical architecture component. This is an incomplete solution - if any of the contents in the redirect destination are moved or been renamed after the redirect is imposed, those contents may result in broken links.

Since IIS-based redirects require creating a new virtual directories on each MOSS server to implement the redirect, this approach does not scale to large numbers of redirects. It should only be implemented for critical sites or for very limited periods of time for other sites, and should only be used at the site or site collection level.

This approach requires no customizations, but does require training and operations documentation for server administrators.

For more information

http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=48

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/41c238b2-1188-488f-bf2d-464383b1bb08.mspx?mfr=true

Hope these help… happy content authoring!

Managing Web.Config Customizations

bgeoffro — Mon, 06 Oct 2008 14:55:00 GMT

I'm back after a long hiatus - international relocations tend to consume a lot of your free time - so it's time to start dusting off some of the many learnings I've had over the past few months...

One important topic I've encountered with my current and previous customers is how to manage web.config updates when deploying customizations. If you've been playing around with the Solutions framework, you're probably familiar with the ease of adding SafeControls entries to your web.config via your solution definition file, but what about all those other configuration settings that inevitably come up with SharePoint customizations?

In my research, I found three tactics for implementing generic web.config customizations programmatically:

Install customizations in the \12\CONFIG directory as specified in the WSS SDK: http://msdn.microsoft.com/en-us/library/ms439965.aspx
Use the SPWebConfigModification class

As described in the WSS SDK: http://msdn.microsoft.com/en-us/library/bb861909.aspx
As implemented in the SharePointDebugger solution: http://tedpattison.net/downloads.aspx

Manipulate the web.config file directly as an XML file (yuck!)

Based on the respective capabilities and level of effort associated with each tactic, I assembled the following matrix of tactics to customization scenarios - hope this helps!

Customization Scope	Method	Example
All zones for all Web Applications (Content web apps and Central Administration)	Create a solution with a webconfig.customizationname.xml file in the \12\CONFIG directory. See http://msdn.microsoft.com/en-us/library/ms439965.aspx for details. Deploy this solution using an *ApplicationServer* deploymentservertype. Execute the stsadm –o copyappbincontent command on all web application hosts (and the Central Admin host, if applicable) to apply retroactively to all existing content web application zones. Notes: · Do not execute the copyappbincontent command multiple times on the same server, as this can create duplicate entries of the customizations. · You do not need to execute the copyappbincontent command to propagate the customization new zones/web apps.	A generic SPSite or SPWeb-scoped feature that is activated via a FeatureSiteTemplateAssociation.
All zones for all Web Applications (Content web apps only)	Create a solution with a webconfig.customizationname.xml file in the \12\CONFIG directory. See http://msdn.microsoft.com/en-us/library/ms439965.aspx for details. Deploy this solution using a *WebFrontEnd* deploymentservertype. Execute the stsadm –o copyappbincontent command on all web application hosts to apply retroactively to all existing content web application zones. Notes: · Do not execute the copyappbincontent command multiple times on the same server, as this can create duplicate entries of the customizations. · You do not need to execute the copyappbincontent command to propagate the customization new zones/web apps.	A generic SPSite or SPWeb-scoped feature that is activated manually by a site owner/administrator.
All zones for selected Content Web Application(s)	Create a solution with a feature based on the SharePointDebugger feature. See http://blog.tedpattison.net/default.aspx for a detailed overview and http://tedpattison.net/downloads.aspx to download. · FeatureReceiver.cs - Update the modification.Owner property as appropriate · FeatureReceiver.cs - Update the Entries property to capture all required modifications. Be sure to use the correct SPWebConfigModificationType for each entry. · Feature.xml –update the ID, Title, Description, ImageUrl, ReceiverAssembly, and ReceiverClass as appropriate Deploy this solution using a *WebFrontEnd* deploymentservertype. Activate this feature on the appropriate web application(s) via the stsadm –o activatefeature command.	An SPSite or SPWeb-scoped feature for personal sites (you did remember to put these on a separate web application, right?) that is activated manually by a personal site owner.
Selected zone(s) for selected Web Application(s)	A manual update is the best practice unless automation is absolutely required. It is *possible* to update the web.config for a specific zone on all servers through code, but this essentially requires direct manipulation of the web.config files as XML documents.	Configuration settings for forms authentication providers.

New Advanced SharePoint Webcasts...

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

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

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

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

Microsoft SharePoint Technologies Solution Architecture

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

Customizing and Extending Microsoft SharePoint Products and Technologies

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

Configuring the Business Data Catalog

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

Enjoy!

Branding Design using Solutions

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

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

History

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

Customizations to the GAC

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

Customizations to the "12" directory:

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

Customizations to web.config:

SafeControls entries for the custom web parts
Redirect module configuration info

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

The Problem...

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

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

The Solution...

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

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

Here's the breakdown:

"Core" Branding Solution

Customizations to the GAC

Feature Receiver DLL for the branding features
Redirect Module DLL

Customizations to the "12" directory:

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

"Web Server" Branding Solution

Customizations to the GAC

Some custom web part assemblies

Customizations to the "12" directory:

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

Customizations to web.config:

SafeControls entries for the custom web parts

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

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

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

Enjoy...

Adding An "All Authenticated Users" Feature to Forms-Based Authentication

bgeoffro — Wed, 09 Apr 2008 23:30:00 GMT

Preamble...

One of the frequenly cited shortcomings of Forms-Based Authentication when compared to Windows Integrated Authentication is its lack of built-in support for an "All Authenticated Users" group similar to NT AUTHORITY\Authenticated Users.

This type of role comes in handy in a number of situations, most notably for provisioning public (but not anonymous) sites and public SSP permissions like "Create Personal Site". The most common workaround I've encountered has been a custom solution that ties in with user provisioning - create a role in the directory service, add all existing users to it, add any new users to it, and remove any users from it as they're deleted. For very large-scale directories, it's not practical to store many thousands of users in a single group, so the actual implementation might be one involving nested groups or a denormalized structure where group memberships are enumerated in the user object, but the same idea applies.

Problem...

My present customer's extranet MOSS implementation uses a very large LDAP directory with hundreds of thousands of potential users. To deal with their problems of scale, they long ago adopted the "list groups in the user object" approach. This made us unable to use the out-of-the-box MOSS Role Manager, which expects to find users enumerated in group objects, rather than groups enumerated in user objects. This led to a need for a custom LDAP Role Manager.

Like most MOSS implementations, they have a need for an "all authenticated users" role, but modifying user provisioning processes in their LDAP (of which there are many, but that's another story) wasn't a realistic option in terms of cost or schedule. Fortunately, the custom Role Manager opened the door to an elegant solution to the "All Authenticated Users" requirement.

Solution...

Once you've written your own role manager, it's pretty straightforward to embed your own "All Authenticated Users" feature into the component. I found it easiest to make this a configurable group name, but you could just as easily hard-code the value. Here's the walkthrough:

1. Create a private class variable (_LDAPAuthUsersGroup in the example below) for storing the group name.

2. Populate the group name variable in the Initialize method via a configuration setting.

3. In the GetRolesForUser method, append the "All Auth Users" group name to the roles list every time, thereby making every user a member of the group.

4. In the RoleExists method, always return true for the "All Auth Users" group name, thereby confirming its existence.

That's all there is to it. Snippets from relevant sections of the RoleProvider appear below.

namespace Company.MOSS.Auth
{
    public class CustomRoleProvider : RoleProvider
    {
        /*
        TO DO: put your other class variables here
         */

private bool _LDAPEnableAuthUsersGroup;
private string _LDAPAuthUsersGroup;

        public CustomRoleProvider()
        {
            /*
            TO DO: set other defaults here
             */

            this._LDAPEnableAuthUsersGroup = false;
            this._LDAPAuthUsersGroup = string.Empty;
        }

        public override void Initialize(string name, NameValueCollection config)
        {
            this._Name = name;
            if (config != null)
            {
                try
                {
                    /*
                    TO DO: initialize your other configuration variables here
                     */

                    //check for the presence of the auth users group configuration setting
                    if (config["authUsersGroup"] != null)
                    {
                        //Extra validation to prevent blank auth users group
                        if (config["authUsersGroup"].Length > 0)
                        {
                            //making this case-insensitive - this might not apply to your directory service
                            this._LDAPAuthUsersGroup = config["authUsersGroup"].ToUpper();
                            //turning on a boolean flag indicating that we're using this feature
                            this._LDAPEnableAuthUsersGroup = true;
                        }
                    }

                    return;
                }
                catch (Exception ex)
                {
                    throw new LdapProviderException(SPResource.GetString("LDAPProviderGeneralFailure",
                        new object[0]));
                }
            }
            throw new ArgumentNullException("config");
        }

        public override string[] GetRolesForUser(string username)
        {
            //this group list length works for me - might need to be different for you
            List<string> rolesList = new List<string>(10);

            /*
            TO DO: do whatever else you need to do to retrieve the "real" roles first
             */

            //if you're using the feature, then add the all auth users group to the roles list
            if (_LDAPEnableAuthUsersGroup)
            {
                rolesList.Add(_LDAPAuthUsersGroup);
            }

return rolesList.ToArray();
}

        public override bool RoleExists(string roleName)
        {
            //if authenticated users functionality is enabled, check to see if this is that special group
            if (_LDAPEnableAuthUsersGroup)
            {
                //making this case-insensitive - this might not apply to your directory service
                string role = roleName.ToUpper();

if (role.Equals(_LDAPAuthUsersGroup)) return true;
}

            /*
            TO DO: do whatever else you need to do to check if "real" roles exist
             */
        }

}
}

Special Concerns:

REALLY, REALLY IMPORTANT: Make sure that the "All Auth Users" group name doesn't intersect with current or possible user/group names. That would be a horrible security hole - if someone created a user or group with the same name as the All Auth Users group (whatever you choose to call it) and provisioned permissions to it on their site, all of a sudden EVERYONE would have that permission level. Very, very, very bad, potentially with legal/compliance consequences. There are three tactics I recommend for preventing this outcome:

Simple, fast solution #1: Create a placeholder group (and user) in the directory service with the same name as the All Auth Users group that YOU own. Never do anything with them other than ensuring that they don't get deleted. You're just putting them there to prevent anybody else from creating a group with the same name, assuming that the directory service enforces uniqueness. :)
Simple, fast solution #2: Give the All Auth Users group a name that falls outside the allowable domain of values for group names in your directory service - i.e. include special characters like # or \ if those are disallowed in group names; create an group name 100 characters long if group names are restricted to 50 characters in the directory service; etc.
Slow, fallback solution: This could also be used in combination with method #2, but adds a bit of overhead. Instead of the mindless algorithms for checking if the role exists and the list of roles for the user, add a check to see if that role name exists in the directory service. If so, go the safe route and use the "real" non-All Auth users group instead AND throw a warning to the event log.

A secondary concern... what if you only want to make this feature available to selected users/sites? This is one of the reasons we went with a configurable setting for the group name - we didn't want your everyday user provisioning permissions to all authenticated users in their site. The design pattern for this is simple - go with an elaborate group name (like a GUID) and change it on a regular basis.

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

}
}

MOSS+ECM Supplemental Material, Week 3

bgeoffro — Fri, 14 Mar 2008 23:35:00 GMT

Various Topics:

Virtualization:

Platform choice:

Virtual Server 2005 R2 x86 or x64 is supported
Recommended against running production environments on VPC
3rd Party: See KB article 897615

Architecture considerations:

Recommended NOT to virtualize SQL
Restricted to 32-bit SharePoint, so this reduces addressable memory
No hard-and-fast rules as to how performance changes when you go from physical to virtual

SharePoint 2003-2007 migration webcast - http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032330523&CountryCode=US
Infopath integration with the BDC - Other than using BDC data in list/library columns in InfoPath forms, you can write a web service to make use of the BDC’s Runtime Object Model:
The Runtime object model is designed for use by the Business Data Catalog clients and applications. The Runtime object model has two major functions:

It offers an intuitive, object-oriented interface that abstracts the underlying data sources. The Runtime object model insulates the client from learning application-specific coding paradigms, and allows clients to access all business applications in a single, simplified way. Because of the Runtime object model, calling a method on an SAP application is very similar to calling a method on Siebel or executing a query in SQL.
It allows you to read the metadata objects from the metadata database and execute the business logic described there. The runtime object model is cached and fast, so clients that just need to query the metadata database for metadata information use the Runtime object model.

ECM Supplemental Material, Week 2

bgeoffro — Thu, 28 Feb 2008 21:30:00 GMT

IRM/RMS Implementation

General Deployment Resources: http://technet2.microsoft.com/windowsserver/en/technologies/featured/rms/default.mspx
Extranet planning considerations: http://technet2.microsoft.com/windowsserver/en/library/107e1338-4dcf-4ed5-a49d-e875cc883db11033.mspx?mfr=true

Load Balancing & Session State Management Links

How State Management Works in SharePoint: http://technet2.microsoft.com/Office/en-us/library/ffa4a256-6885-4295-a712-537ce82b9a0c1033.mspx?mfr=true
JoelO's LB Troubleshooting & Configuration Tips: http://blogs.msdn.com/joelo/archive/2007/01/05/nlb-network-load-balancing-and-sharepoint-troubleshooting-and-configuration-tips.aspx

Various topics:

How to change the behavior of the "!NEW" icon: http://support.microsoft.com/kb/825510
PDF document converters:

User Management Solution Accelerator (for permissions management): http://store.bamboosolutions.com/ps-46-5-user-management-accelerator-available-july-2007.aspx
InfoPath development reference: http://www.amazon.com/Designing-Microsoft-InfoPath-Services-Development/dp/0321410599/ref=pd_bbs_sr_1/103-2811446-2506209?ie=UTF8&s=books&qid=1179182561&sr=8-1

By Popular Demand... More HttpModule Sample Code

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

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

Redirect.cs

using System;

using System.Collections.Generic;

using System.Text;

namespace MOSS.Branding

{

public struct Redirect

{

public string pattern;

public string masterPageUrl;

public string originalMaster;

public string destinationPageUrl;

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

{

pattern = _pattern;

masterPageUrl = _masterPageUrl;

originalMaster = _originalMaster;

destinationPageUrl = _destinationPageUrl;

}

RedirectSectionHandler.cs

using System;

using System.Collections;

using System.Collections.Generic;

using System.Text;

using System.Configuration;

using System.Xml;

namespace MOSS.Branding

{

class RedirectSectionHandler : IConfigurationSectionHandler

{

#region IConfigurationSectionHandler Members

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

{

ArrayList coll = new ArrayList();

XmlElement root = (XmlElement)section;

string pattern = "";

string masterPageUrl = "";

string originalMaster = "";

string destinationPageUrl = "";

foreach (XmlNode parentNode in root.ChildNodes)

{

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

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

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

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

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

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

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

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

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

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

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

coll.Add(redirect);

}

return coll;

}

#endregion

}

MOSS+ECM Training Supplemental Material

bgeoffro — Thu, 21 Feb 2008 22:02:00 GMT

Recommended Readings/Resources on ITPro Topics:

Case Study for DPM 2007 for SharePoint: http://technet.microsoft.com/en-us/library/bb897855.aspx
How to increase the size of a Site Template beyond 10MB: http://blogs.msdn.com/joelo/archive/2007/03/15/you-learn-something-new-every-day-site-template-limit.aspx
Multilanguage Implementation References:

Plan variations: http://technet2.microsoft.com/Office/f/?en-us/library/45264de9-6859-45c1-9d6d-70035c471a2a1033.mspx
Plan for multilingual sites: http://technet2.microsoft.com/Office/f/?en-us/library/22d5dc9c-66bd-40d7-8c60-2a2a066db2241033.mspx

Extranet Toplogies for SharePoint 2007: http://office.microsoft.com/search/redir.aspx?AssetID=AM101638961033&CTT=5&Origin=HA101639821033

Also review ISA 2006 configurations for SharePoint in the MOSS Administrator's Companion, Chapter 19

STSADM Command Reference: http://technet2.microsoft.com/Office/en-us/library/e5134b97-b629-4fc0-8733-f2a49126daee1033.mspx?mfr=true
Search product comparison: http://www.microsoft.com/enterprisesearch/products.aspx#compare
Everything you wanted to know about the recycle bin: http://blogs.technet.com/wbaer/archive/2007/11/13/planning-for-additional-storage-with-microsoft-sharepoint-products-and-technologies-recycle-bin.aspx
SharePoint Product Comparison - http://office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx
NEW TechNet WebCasts on ITPro Topics (many will be familar): http://blogs.msdn.com/sharepoint/archive/2008/02/18/advanced-sharepoint-videos-and-whitepapers.aspx

Be sure to check out the SEARCH and PERFORMANCE OPTIONS webcasts

Recommended Reading/Resources on ECM/DM topics:

Go here for the full MOSS Capacity Planning briefing: http://www.microsoft.com/winme/0712/31729/Module4/Local/index.html
Tons o' SharePoint Technical & Functional Visio Diagrams: http://technet.microsoft.com/en-us/office/bb310619.aspx

Office Server Topology Diagram

Records Management Planning on TechNet:http://technet2.microsoft.com/Office/en-us/library/271017e8-7f23-4166-9501-140ad2fc555d1033.mspx
Document Management Planning on TechNet:http://technet2.microsoft.com/Office/en-us/library/cb57d4f7-8353-420b-8a10-d05c9bdf1b561033.mspx
Document Conversion is AKA "Smart Client Authoring" - search on that term for more info, or get a start from this article: http://technet2.microsoft.com/Office/en-us/library/e028f0a7-f9cf-45c1-a8b9-bfb2051352e41033.mspx?mfr=true
Team Foundation Server Architecture (includes relationship to WSSv2): http://msdn2.microsoft.com/en-us/library/ms364062.aspx
JoelO on what NOT to store or do in sharepoint (keep in mind that the new External Blob Storage API adds some new twists to these practices): http://blogs.msdn.com/joelo/archive/2007/11/08/what-not-to-store-in-sharepoint.aspx
Resolving the "The column name that you entered is already in use or reserved" issue that occurs when you rename an OOTB site column like "Title" - http://support.microsoft.com/kb/923589/en-us
How to increase the max document size for indexing - change this value: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Global\Gathering Manager
More to come...

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.

Adding Kerberos & SSL to Central Administration

bgeoffro — Tue, 12 Feb 2008 00:24:00 GMT

This came up during the SharePoint AcademyLive Search class today, and isn't the first time I've been asked how to do this, so I figured it was time to write a post. :)

When you're first configuring your farm, it's often easier to configure Kerberos & SSL later, once you've completed all the other farm deployment tasks and made sure everything else is working. Doing this for Central Admin requires a couple of minor tricks... the complete procedure listed is listed below.

Assumptions:

CA was originally installed on the desired server
you don't have any web.config or other customizations applied to the CA webapp
all your Kerberos configuration (SPNs, delegation, etc.) is already configured
CA was originally installed with NTLM & HTTP.

Central Admin Web Application (Kerberos+SSL)

1. Remove Existing CA site

a. Navigate to Start Menu > All Programs > Microsoft Office Server > SharePoint Products & Technologies Configuration Wizard

b. Click Next

c. Click Yes

d. Leave “Do NOT disconnect from this server farm” selected and click Next.

e. Select “Yes, I want to remove the web site from this machine” and click Next.

f. Click Next

g. Click Finish

2. Recreate CA site w/Kerberos auth

a. Navigate to Start Menu > All Programs > Microsoft Office Server > SharePoint Products & Technologies Configuration Wizard

b. Click Next

c. Click Yes

d. Leave “Do NOT disconnect from this server farm” selected and click Next.

e. If asked, indicate that this server should host the central administration web application and click Next.

f. Check the checkbox next to “Specify port number” and enter a port number of 12345.

g. Select the Negotiate (Kerberos) authentication provider.

h. Click Next

i. Click Yes

j. Click Next

k. Click Finish

3. Enable SSL for CA site

a. Navigate to Start Menu > All Programs > Administrative Tools > IIS Manager

b. Navigate to {Computer Name } > Web Sites

c. Right-click SharePoint Central Administration V3 and select Properties

d. Enter 12345 in the SSL port field.

e. Enter 80 in the TCP Port field.

f. Click Apply.

g. Navigate to the Directory Security Tab

h. In the Server Communications region of the tab, select Edit.

i. Select Require Secure Channel and click OK.

j. Navigate to the Directory Security Tab

k. Select Server Certificate

l. Click Next

m. Select Import a certificate from a .pfx file and click Next

n. Browse to the file

o. Click Next

p. Enter the password (if necessary) and click Next

q. Confirm that 12345 is in the SSL port field and click Next

r. Click Next

s. Click Finish

t. Click OK

4. Execute an IISRESET on the central administration host server

5. Update AAM for CA site

a. Open the OPERATIONS PAGE of the central administration site in a web browser (i.e. https://contoso86:12345/_admin/operations.aspx - if a specific page is not indicated in the address, it will fail to open since the AAM requires updating).

b. If warned, ignore any certificate errors and continue browsing to the page.

c. Select Alternate Access Mappings from the Global Configuration subheader.

d. Click on the link for http://contoso86:12345

e. Set the value in the URL protocol, host, and port field to https://contoso86.contoso.com:12345

f. Click OK.

Branding Mark II: Refining the HttpModule-based Approach

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

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

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

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

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

Using the ResourceRedirect Module

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

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

</destinationRedirects>

</masterRedirects>

</Branding>

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

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

Deploying the Branding as a Solution

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

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

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

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

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

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

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

Install Script

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

echo off

echo Adding solution to farm...

stsadm -o addsolution -filename customizations.wsp

echo Deploying solution...

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

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

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

pause

echo Activating feature stapler...

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

echo Resetting IIS...

iisreset /noforce

echo Updating branding on existing sites...

brandingupdate.exe

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

Uninstall Script

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

echo off

echo Retracting solution...

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

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

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

pause

echo Deleting solution...

stsadm -o deletesolution -name customizations.wsp

echo Resetting IIS...

iisreset /noforce

echo Branding uninstall complete.

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

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

Branding Lessons Learned 2: Post-launch

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

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

Process Learnings (AKA battle scars):

Requirements & Design.

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

Testing

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

Additional Technical Learnings:

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

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

Odds and ends.

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

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

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

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

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

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

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

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

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

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

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

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

Introduction

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

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

BrandingModule Project

The BrandingModule project consists of three components:

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

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

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

Redirect Structure

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

Public Members

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

RedirectSectionHandler class

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

Public Members

Member

Type

Inheritance

Description

Create

Object

IConfigurationSectionHandler

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

· masterPageUrl and destinationPageUrl are blank/missing

· pattern and originalMaster are blank/missing

ResourceRedirect Class

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

Public Members

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

Private Members

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

Configuration Settings

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

· SectionGroup configuration

· HttpModule configuration

· Branding configuration

SectionGroup Configuration

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

<section name="pageRedirects"

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

<section name="pathRedirects"

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

<section name="comboRedirects"

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

<section name="masterRedirects"

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

<section name="destinationRedirects"

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

</sectionGroup>

HttpModule Configuration

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

Branding Configuration

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

</pageRedirects>

</destinationRedirects>

</pathRedirects>

</comboRedirects>

</masterRedirects>

</Branding>

“12” Customizations and Branding Redirects

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

Changes to the “12” Directory

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

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

ADDITION to this list as of 26JAN2008:

CORE.CSS

Core stylesheet for WSS 3.0.

LAYOUTS\1033\STYLES

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

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

NEW Additions to the “12” Directory

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

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

ADDITION to this list as of 26JAN2008:

theme.css

LAYOUTS\customizations

Duplicate of themes.css from THEMES\CONTOSO

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

Replacements/Redirects for the “12” Directory

These are all the files that required ResourceRedirect configurations.

Items in red font were added/updated 26JAN2008.

File name

Original Location

Redirect Location

Purpose

Notes

CORE.CSS

LAYOUTS\1033\STYLES

LAYOUTS\1033\STYLES\Customizations

Core stylesheet for WSS 3.0.

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

NEW_application.master

LAYOUTS

LAYOUTS\Customizations

Master page for most non-dialog system pages.

NEW_simple.master

LAYOUTS

LAYOUTS\Customizations

Non-themed master page for all nonsecured system pages.

theme.css

LAYOUTS

LAYOUTS\Customizations

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

Duplicate of themes.css from THEMES\CONTOSO .

templatepick.aspx

LAYOUTS

LAYOUTS\Customizations

Site Template selection page

Added reference to LAYOUTS\Customizations\theme.css

SiteManager.aspx

LAYOUTS

LAYOUTS\Customizations

Site Content & Structure page

Added custom header and footer

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

</destinationRedirects>

</masterRedirects>

</Branding>

Code Snippets and Additional Comments

ResourceRedirect.cs

Updated 26JAN2006

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

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

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

using System;

using System.Collections.Generic;

using System.Collections;

using System.Text;

using System.Web;

using System.Web.UI;

using System.Configuration;

using System.Diagnostics;

namespace MOSS.Branding

{

public class ResourceRedirect : IHttpModule

{

public void Init(HttpApplication context)

{

context.PreRequestHandlerExecute += new EventHandler(context_PreRequestHandlerExecute);

}

void context_PreRequestHandlerExecute(object sender, EventArgs e)

{

HttpApplication httpApp = sender as HttpApplication;

if (httpApp != null)

{

Page page = httpApp.Context.CurrentHandler as Page;

if (page != null)

{

page.PreInit += new EventHandler(page_PreInit);

}

void page_PreInit(object sender, EventArgs e)

{

Page page = sender as Page;

string currentMaster = String.Empty;

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

ArrayList masterRedirects = null;

ArrayList pageRedirects = null;

ArrayList pathRedirects = null;

ArrayList comboRedirects = null;

ArrayList destinationRedirects = null;

//retrieve remappings by type to enable enforcing precedence

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

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

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

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

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

bool matchFound = false;

IEnumerator redirectEnum = null;

if (page != null)

{

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

{

redirectEnum = destinationRedirects.GetEnumerator();

while (redirectEnum.MoveNext())

{

Redirect destinationRedirect = (Redirect)redirectEnum.Current;

if (currentPath.Contains(destinationRedirect.pattern))

{

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

destinationRedirect.destinationPageUrl));

matchFound = true;

}

if (page.MasterPageFile != null)

{

currentMaster = page.MasterPageFile.ToLower();

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

{

redirectEnum = comboRedirects.GetEnumerator();

while (redirectEnum.MoveNext())

{

Redirect comboRedirect = (Redirect)redirectEnum.Current;

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

{

page.MasterPageFile = comboRedirect.masterPageUrl;

matchFound = true;

}

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

{

redirectEnum = pathRedirects.GetEnumerator();

while (redirectEnum.MoveNext())

{

Redirect pathRedirect = (Redirect)redirectEnum.Current;

if (currentPath.StartsWith(pathRedirect.pattern))

{

page.MasterPageFile = pathRedirect.masterPageUrl;

matchFound = true;

}

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

{

redirectEnum = pageRedirects.GetEnumerator();

while (redirectEnum.MoveNext())

{

Redirect pageRedirect = (Redirect)redirectEnum.Current;

if (currentPath.Contains(pageRedirect.pattern))

{

page.MasterPageFile = pageRedirect.masterPageUrl;

matchFound = true;

}

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

{

redirectEnum = masterRedirects.GetEnumerator();

while (redirectEnum.MoveNext())

{

Redirect masterRedirect = (Redirect)redirectEnum.Current;

if (currentMaster.Contains(masterRedirect.originalMaster))

{

page.MasterPageFile = masterRedirect.masterPageUrl;

}

private void UpdateLog(string Message, EventLogEntryType msgType)

{

try

{

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

}

catch

{

//ignore

}

public void Dispose()

{

}

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

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

Introduction

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

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

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

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

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

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

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

BrandingFeatures Project

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

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

File Manifest

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

MySiteCreate.cs

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

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

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

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

Public Methods

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

Private Methods

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

Custom_default.master

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

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

· Header region

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

o Moved Search controls to same row as Welcome control

o Removed User-customizable Site Logo

o Added Contoso logo

· Footer region

o Added custom footer

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

· HIDDEN

o Added PartCheck control to page

Custom_MWSdefault.master

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

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

· Header region

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

o Moved Search controls to same row as Welcome control

o Removed User-customizable Site Logo

o Added Contoso logo

· Footer region

o Added custom footer

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

· HIDDEN

o Added PartCheck control to page

BrandingStapler Feature

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

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

BrandingStaplee Features

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

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

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

· Calls the MySiteCreate feature receiver assembly.

Custom Properties

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

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

BrandingUpdate

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

File Manifest

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

Configuration Settings

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

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

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

1. WebApp determines the set of web applications

2. FilterPattern determines the applicable sites within those applications

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

Program.cs

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

Protected Methods

Name	Type	Purpose	Notes
Main	Void	Main method.

Private Methods

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

BrandingParts

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

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

File Manifest

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

PartCheck.cs

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

LAYOUTS Customizations

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

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

· Images

· Theme Definitions

· Stylesheets

· CSS files

Code Snippets and Additional Comments

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

BrandingStapler

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

<Feature

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

Title="Branding Stapler"

Scope="WebApplication"

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

</ElementManifests>

</Feature>

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

</Elements>

GenericBrandingStaplee

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

<Feature

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

Title="Generic Site Branding Feature"

Scope="Web"

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

ReceiverClass="Microsoft.IW.MySiteCreate"

Hidden="TRUE"

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

</ElementManifests>

</Properties>

</Feature>

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

MySiteCreate Receiver Assembly

MySiteCreate.cs code:

using System;

using System.Collections.Generic;

using System.Text;

using Microsoft.SharePoint;

using Microsoft.SharePoint.WebPartPages;

using System.Diagnostics;

namespace Microsoft.IW

{

public class MySiteCreate : SPFeatureReceiver

{

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

const string ORIGINALTHEME = "simple";

public override void FeatureActivated(SPFeatureReceiverProperties properties)

{

try

{

string newMaster = string.Empty;

string newTheme = string.Empty;

bool checkParts = false;

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

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

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

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

if (!checkParts)

{

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

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

{

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

{

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

curWeb.Properties.Update();

}

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

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

{

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

{

string curMaster = curWeb.MasterUrl;

string curCustomMaster = curWeb.CustomMasterUrl;

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

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

//of our feature

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

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

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

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

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

EventLogEntryType.Information);

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

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

curWeb.ApplyTheme(newTheme);

curWeb.Update();

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

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

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

EventLogEntryType.Information);

}

catch (Exception ex)

{

//try writing to event log

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

}

private void UpdateLog(string Message, EventLogEntryType msgType)

{

try

{

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

}

catch

{

//ignore

}

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)

{

try

{

string originalMaster = string.Empty;

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

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

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

{

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

{

string curMaster = curWeb.MasterUrl;

string curCustomMaster = curWeb.CustomMasterUrl;

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

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

//of our feature

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

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

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

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

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

EventLogEntryType.Information);

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

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

curWeb.ApplyTheme(ORIGINALTHEME);

curWeb.Update();

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

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

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

EventLogEntryType.Information);

}

catch (Exception ex)

{

//try writing to event log

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

}

public override void FeatureInstalled(SPFeatureReceiverProperties properties)

{

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

}

public override void FeatureUninstalling(SPFeatureReceiverProperties properties)

{

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

}

Comments:

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

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

BrandingUpdate

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

using System;

using System.Collections.Generic;

using System.Collections.Specialized;

using System.Diagnostics;

using System.Text;

using System.Xml;

using System.Configuration;

using Microsoft.SharePoint;

using Microsoft.SharePoint.Administration;

using System.Collections;

namespace BrandingUpdate

{

class Program

{

static int logLevel = 1;

static bool debug = false;

static bool brandAll = false;

static bool upload = false;

static string logSource = "BrandingUpdate";

static string logDestination = "Application";

static string filterPattern = "";

static void Main(string[] args)

{

//Retrieve Configuration Settings

ArrayList webApps = null;

ArrayList brandMaps = null;

StringDictionary staples = new StringDictionary();

try

{

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

ConfigurationSectionGroupCollection webApp = config.SectionGroups;

NameValueCollection appSettings = ConfigurationManager.AppSettings;

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

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

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

filterPattern = appSettings["filterPattern"];

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

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

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

foreach (BrandMap map in brandMaps)

{

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

}

catch (Exception e)

{

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

}

try

{

//Retrieve list of web apps

SPFarm mySPFarm = SPWebService.ContentService.Farm;

SPWebApplicationCollection mySPWebAppCollection = SPWebService.ContentService.WebApplications;

if (mySPWebAppCollection != null)

{

//Iterate through web applications

foreach (SPWebApplication mySPWebApp in mySPWebAppCollection)

{

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

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

{

//Iterate through site collections

foreach (SPSite site in mySPWebApp.Sites)

{

//Iterate through webs

foreach (SPWeb web in site.AllWebs)

{

//check to see if web matches filter pattern

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

{

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

string featureStaple = staples[configurationID];

if (featureStaple != null)

{

bool brandingActivated = false;

Guid featureGuid = new Guid(featureStaple);

//see if branding feature is activated on this web

foreach (SPFeature feature in web.Features)

{

if (feature.DefinitionId.Equals(featureGuid))

{

brandingActivated = true;

}

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

if (brandAll || !brandingActivated)

{

try

{

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

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

web.Features.Add(featureGuid);

}

catch (Exception ex)

{

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

}

web.Close();

}//close web loop

site.Close();

} //Close site collection loop

}

}//Close webapp loop

}

catch (Exception e)

{

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

}

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

{

bool writeEntry = true;

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

if (logLevel > 0)

{

if (!EventLog.SourceExists(logSource))

EventLog.CreateEventSource(logSource, logDestination);

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

writeEntry = false;

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

writeEntry = false;

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

}

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

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

<section name="webAppSection"

type="BrandingUpdate.webAppSectionHandler,BrandingUpdate"/>

<section name="mappingSection"

type="BrandingUpdate.masterMapSectionHandler,BrandingUpdate"/>

</sectionGroup>

</configSections>

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

<webApp>SharedServices1</webApp>

</webAppSection>

</mappingSection>

</brandingSectionGroup>

</appSettings>

</configuration>

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

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

Branding Methods by Scope and Scenario

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

Scope: Farm

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

Scope: Single Web Application

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

Scope: Site/Site Collection

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

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