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.

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.

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:

1. Create a new site collection in language X (English in this example).
2. Configure the site collection to use custom scopes (Site Actions > Modify All Site Settings > Site Settings > Search Settings > Use Custom Scopes).
3. Set the variation home ("/" in this example).
4. Create a variation label for language X (English in this example)
5. Create a variation label for language Y (Dutch in this example)
6. Create the variation hierarchies
7. Navigate to the welcome page for variation site in language X
8. Select the search dropdown control - "This Site:...", "All Sites", "People" appear in the list (these labels are different if language X is not English).
9. Navigate to the welcome page for variation site in language Y
10. 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
Id="12345678-1234-1234-1234-1234567890AB"
Title="ScopeDisplayGroups"
Description="This feature is used to create the search scope display groups needed to enable enhanced search on multilanguage sites."
Version="1.0.0.0"
Scope="Site"
Hidden="false"
ReceiverAssembly="ScopeDisplayGroups, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1234123412341234"
ReceiverClass="ScopeDisplayGroups.FeatureReceiver" xmlns="http://schemas.microsoft.com/sharepoint/">

<Properties>
<Property Key="en" Value="Search Dropdown"/>
<Property Key="nl" Value="Vervolgkeuzelijst voor zoeken"/>
</Properties>

</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) {

string currentGroupName = string.Empty;

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

//retrieve current scope display groups from this site

Scopes scopes = new Scopes(searchContext);

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)

try

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)

try

//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) &&

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

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

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

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!

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!

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.

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

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

    }
}

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:
• From Bamboo Solutions: http://store.bamboosolutions.com/pc-16-3-office-to-pdf-conversion-solution-accelerator-release-12.aspx
• From Aspose: http://www.aspose.com/documentation/file-format-components/aspose.words-for-.net-and-java/add-doc-to-pdf-and-other-conversions-to-microsoft-office-sharepoint-server-2007-with-aspose-components.html
• 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