Stuff I Wouldn’t Want to Live Without – Joel Made me do it…

It appears Joel invited me to participate in a chain-letter of sorts with the context being stuff I wouldn’t want to live without.  After thinking about the question for a moment, I found it much easier to compile a list of things I could live without, but to keep with the intent of the invitation – I’ve derived the following list:

  1. My wife and son; without their support I likely would not be where I am in life today.
  2. SharePoint – when I looked around me I found that nowhere do I have a machine that has no less than Windows SharePoint Services 3.0 (WSS) installed and where I do not or can’t install WSS or Microsoft Office SharePoint Server 2007 (MOSS) – I have access to a number of public facing WSS/MOSS resources available or alternatively use Mobile Views when without a PC.  It’s obvious I am a dedicated supporter of the platform having come from a Web development/CMS background and completed my Six Sigma project using SharePoint Products an Technologies as means to increase productivity and remove collaborative barriers resulting in noticeable gains in ROI and efficiency…at the time STS was the platform that served as the basis of this project.
  3. Technology – I have always been drawn to emerging technologies, having worked for Apple Computer Corporation, First Data Corporation, Digital Equipment Corporation, Compaq Computer Corporation, and Hewlett-Packard (see profile), the latter three through acquisitions; I have had the opportunity to experience a broad range of technological advancements and innovations come to realization from concept.
  4. History – I am fascinated with history – having been raised in Europe I had the opportunity to experience history first hand, medieval discussions were not only relegated to text books, but were also envisioned in their true form.  This approach inspired thought and interest – it is always easier to touch and feel something firsthand and draw your own conclusions based on what you have seen and experienced.
  5. Geography – Geography has always been an interest and compliments my passion for history.  I’ve always been curious to understand why people settled in a particular area, what resources drew them there, what resources did they previously lack prompting the move to this location and what was the state of the land when they arrived – I guess that would be both a combination of history and anthropology, but nonetheless something that keeps me interested. 
  6. Travel – I enjoy traveling, pleasure more than business, but traveling nonetheless – I’ve visited just about every country in Europe west of the Czech Republic and the contiguous 48 U.S. States and Canada.  Time and resources permitting I would enjoy the opportunity to explore Africa and the Middle East.
  7. The ability to read – comes in useful at times 😉

Programmatically Modifying Portal Site Connection Properties

I recently received a request asking 1) if a site collections portal site connection can be programmatically replaced or modified and 2) can this be accomplished on a schedule without implementing a provisioning intercept or callback based on Site Directory metadata.

First let’s examine the first question:

1) Can a site collections portal site connection be programmatically replaced or modified…the simple answer is yes.  Using the Sites property of the Microsoft.SharePoint.Administration.WebApplication class to return a SPSiteCollection object representing a collection of site collections on a Web application.  Using the Sites property you can use an indexer to return a single site collection from the collection or alternately return all site collections in the collection.

In the latter you can use a local variable siteUrl to get the requested Web application or optionally specify a Url using System.Uri uri = new System.Uri(http://contoso);.  The sample code below uses a siteUrl local variable that can be passed as an argument in a console application.

            SPFarm GlobalAdministration = new SPFarm();
System.Uri uri = new System.Uri(;
SPWebApplication WebApplication = SPWebApplication.Lookup(uri);
SPSiteCollection SiteCollections = WebApplication.Sites;

Now that you’ve associated a Web application with the request you can iterate through the site collections in the collection:

foreach (SPSite SiteCollection in SiteCollections)

To update the portal site connection you can:

SiteCollection.PortalName = “Contoso Home”;
SiteCollection.PortalUrl =;

Putting it all together:

            SPFarm GlobalAdministration = new SPFarm();
System.Uri uri = new System.Uri(;
SPWebApplication WebApplication = SPWebApplication.Lookup(uri);
SPSiteCollection SiteCollections = WebApplication.Sites;
Console.WriteLine(“Web Application: “ + WebApplication.DisplayName.ToString());
foreach (SPSite SiteCollection in SiteCollections)
SiteCollection.PortalName = “Contoso Home”;
SiteCollection.PortalUrl = “”;

This code snippet is provided under the Microsoft Permissive License.

Now that we understand how to manipulate the portal site connection for a site collection we need to set the portal site Url based on a value in the existing Site Directory taxonomy.  You can use the SPListIemCollection Class (Microsoft.SharePoint) to return the collection of items for a List (Site Directory) using the Items property or one of the GetItems methods of the SPList class.  To return a single list item from the collection such as a taxonomy component use an indexer, in example the Site Directory uses a List (Sites) to host the List items – so the collection is assigned to a variable named Sites, use Sites[index] in C# or Sites(index) in VB 2005 where index would be the display name of a List field such as Division.  With the SiteDirectory metadata a portal site connection can be correlated using C#

If <condition> Then


Windows SharePoint Services SDK Documentation

For additional information on using the SPListItemCollection Class see

Happy coding…

Understanding Hierarchy and Basic Concepts of Navigation in Microsoft Office SharePoint Server 2007/Windows SharePoint Services

Web applications are the foundation of a SharePoint Products and Technologies server farm and host the root site collection, root and subordinate webs.  SharePoint Portal Server 2003 and Windows SharePoint Services 2.0 used the term Virtual Server to designate a Web application also known as a Web site in Internet Information Services.

A root site [collection] is the term commonly applied to the what is the uppermost site collection within a server farm or otherwise referred to as the top-level site collection or alternatively portal site collection.  The root site [collection] can host any number of subordinate webs or root webs, each serving any number of subsequent webs.  A root site [collection] in Microsoft Office SharePoint Server 2007 hosts the Site Directory and Search Center webs and serves as an aggregation mechanism and provides search results through the native Search Center. 

Path-based site [collections] were traditionally known as ‘team’ sites, a term coined in SharePoint Team Services.  Each site can host any number of webs and subsequent webs.  Breadcrumb navigation is available in two contexts for both site [collections] and webs provided both inter and intra-site.  Intra-site breadcrumb navigation provides hierarchical navigation substance when within a site and/or web; whereas inter-site breadcrumb navigation provides hierarchical navigation relational to each site collection within a tier and can establish a connection to the root site [collection] where portal site mappings are applied and is referenced by using the ‘Title’ of a site [collection], web, List or Document Library.

This concept is also known as the relationship chain where each object has a parent, where a parent is not available to an object, an orphan exists and can include, site [collections], webs, Lists and Document Libraries.  So to put it into context, breadcrumb navigation can be equated to a family tree of sorts, where site [collections] reside within the same level of the relationship chain there is no genealogy or navigational reference between the two.

The image above shows both inter-site and intra-site breadcrumb navigation respectively.

Another method of structuring site [collections] within a SharePoint Products and Technologies deployments is to use managed paths as a designator to represent a logical navigation structure, as an example, a managed path ‘HR’ may be implement to host site [collections] and subsequent webs related to Human Resources.  Managed paths define which pieces of the URL namespace are controlled by Microsoft Windows SharePoint Services.  In Windows SharePoint Services 2.0 there were several possible options when using managed paths:

  • Explicit Inclusions:  Used if you want Windows SharePoint Services to manage a specific path, I.e. /path/, but not any paths beneath it, I.e. /path/anotherpath.

  • Explicit Exclusions:  Indicated to Include any site [collections] below the path.

  • Top-level Web site explicit inclusion:  Indicates only the root site [collection] should be handled by Windows SharePoint Services.

  • Top-level Web site wildcard inclusion:  Indicates every directory under the specified path is a Windows SharePoint Services root site [collection].

  • Exclusion:  Exclusion paths indicate a path that should not be handled by Windows SharePoint Services, in example if a Virtual Directory with the alias ‘FabrikamApp’ is created within a Web application through Internet Information Services, it’s contents will not be managed by Windows SharePoint Services.

In Windows SharePoint Services 3.0 the implementation of managed paths has changed in comparison to previous versions, prior to implementing managed paths you should consult the Windows SharePoint Services 3.0 Technical Library at

When using managed paths as a navigation provider it is also important to understand that users requesting <A href="http://%3cserver%3e/%3Cpath%3E/&quot; mce_href="http:////”>http://<server>/<path>/ will be presented with a 404 since no content can reside at a managed path reference.  To mitigate the server standard 404, you can develop and present a user friendly 404 using Jingmei Li’s instructions at How to create your own custom 404 error page and handle redirect in SharePoint 2007 (MOSS)-.



Requests Per Second Required for SharePoint Products and Technologies

One of the most common questions making its way to my Inbox as of recently is how to determine the required requests per second (RPS) to support a SharePoint Products and Technologies deployment.  While many IT Pros opt to use the recommend values associated with RPS and Internet Information Services (IIS) the transactions are considerably different between a light-weight .NET application or common IIS Web site.  To establish a general requirement for requests per second for a SharePoint Products and Technologies deployment you will need answers to the following questions:

  1. What is the total or anticipated number of users that will potentially access the server farm?  It is usually best to consider all seats in this figure, overestimating in this case is preferable to underestimating.

  2. What is the estimated percentage of users that would potential access the server farm concurrently on a given day?  Again, overestimating is preferable to underestimating.  Generally we would assume at least 35% of users would access the server farm concurrently on a given day, though, depending on the nature of the users, the purpose of the deployment and any competing technologies, e.g. file shares, this number can fluctuate significantly.

  3. What is the average number of common requests per user on a given day?  Common requests include basic operations such as updating an item in a List or Document Library.

  4. What is the anticipated ratio by which peak usage will exceed average usage on a given day?  As a general rule, your users will be more active at certain periods throughout a business day, such as early in the morning or later in the afternoon.  Considering you’ve profiled your users utilization of the server farm, by how much does peak usage exceed the average usage.  2x is generally a safe estimate for most deployments, but again may vary depending on the nature and overall purpose of the deployment.

  5. How many hours are in a business day?  A business day can generally be considered the operating hours of the business; however, for extranet deployments, centralized or regional deployments, a business day may stretch beyond 8:00 A.M. and 5:00 P.M.  Consider this when determine business hours.

Now that questions 1 through 5 have an answer associated with them, simple mathematics can be applied to determine the required requests per second to support your user base.

Step 1

Take the sum of 1 * 2 * 3 * 4

Step 2

Take the sum of 5 * 360000 where 360000 is the number of seconds per hour

Step 3

Divide the sum of 1 * 2 * 3 * 4 by the sum of 5 * 360000 to determine the required requests per second to support your user base.

For example, let’s assume Contoso has 95,000 total users, where 50% are assumed to access the server farm concurrently, each averaging 248 requests per day and peak usage is 2x the average usage.

95000 * 50% * 248 * 2 = 23560000

Using the result above anticipating Contoso will have users accessing the server farm 24 hours a day gives us the result of 8640000 seconds.

Now we divide 23560000 by 8640000 to determine the required requests per second to support the potential Contoso user base giving the result 2.726. 

Now we round 2.726 and move the decimal for a final result of 273 required requests per second.


Capacity Planning for Windows SharePoint Services

Estimate Performance and Capacity Requirements for Search Environments

Nothing SharePoint

It’s nothing SharePoint related, but a rare treat to catch a glimpse of an unobscured Mt. Rainier – these were taken over on a semi-clear afternoon around 6:00 P.M. from the Puyallup-Graham area about 30 miles south of Seattle.  You’re looking south/southeast in these photographs, in the distance beyond the Evergreens is the Puyallup Valley and the town of Orting along the banks of the Carbon River.  (more info…)

<IMG class=sopretty src="; original-url="; P

Mt. Rainier is an active stratovolcano in the Cascade range; at an elevation of 14, 410 feet (4,392 meters) it is also the tallest mountain in the range.  It appears throughout the year as it does in these photographs encased in over 35 square miles (~91 square kilometers) of snow and glacial ice.  It is this runoff that feeds the Carbon, Cowlitz, and Puyallup Rivers.  Mount Rainier’s size places it on the list of most volumous stratovolcanoes in the world and its’ prominence greater than that of K2.