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 http://technet2.microsoft.com/windowsserver/WSS/en/library/700c3d60-f394-4ca9-a6d8-ab597fc3c31b1033.mspx?mfr=true.

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




Productivity on the go…

Of the many benefits of Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007, often overlooked is the native support of mobile devices through embedded mobile site URLs and mobile views.

Mobile views permit both viewing and updating Lists and Document Libraries from a mobile device. 

When considering leveraging mobile views, you should carefully consider the restrictions on length and size of some parts of a list or library. 


Rendering and performance are considered in mobile views, therefore it is important to understand the limitations imposed by these considerations when implementing Lists and/or Document Libraries, for instance many common fields should have a character limitation of no greater than 20 applied, these include List and Document Library titles and names, and List and column name titles.  When the 20 character limit is exceeded, mobile device users will be presented with an ellipses representing the additional characters.  In example, a List title ThisListHasOverCharacters will be rendered on the mobile device as ThisListHasOverChara… See below for a complete list of limitations to consider when designing Lists and Document Libraries settings for mobile views.

Item Limit
Characters in the Web title of a list or library 20
Characters in a list or library name 20
Number of mobile views 10
Number of items displayed in a view 100
Characters in a list item title 20
Characters in a column name 20
Single-line text field type 256
Multiple-line text field type 256
Each choice in a choice field type 10
Number of options in a choice field type 10
Characters in each item in a lookup field 20
Number of options in a lookup list 20
Characters in a hyperlink or picture field 20
Characters in an attachment file name 20
Number of attachments (to list items) displayed 3
Characters in a calculated field 20

NOTE Discussion Boards, the Currency, Yes/No, and Person or Group column types are not supported by mobile views.

Accessing Mobile Site URLs and Views

Mobile site URLs and views are native to Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007, to access a mobile site URL or view simply append the URL with /m.  In example, <A href="http://%3cserver%3e/%3Cpath%3E/%3Csite%3E's&quot; mce_href="http:/// /’s”>http://<server>/<path>/<site>’s mobile URL can be accessed through <A href="http://%3cserver%3e/%3Cpath%3E/%3Csite%3E/m&quot; mce_href="http:/// &#010://m”>http://<server>/<path>/<site>/m.

Standard Site URL View

Mobile Site URL View

Creating Mobile Views

In addition to the embedded mobile views you can also create mobile views for Lists and Document Libraries.

To create a mobile view, select the List or Document Library source and select Settings, and then select Document Library Settings or List Settings from the menu.

Select Create view and select Standard View under the Choose a view format section.

NOTE Calendar, Access, Datasheet, and Gannt views are not supported for mobile devices.

Using the table in the section labeled Limitations as a guide, complete the required fields on the Create View:  <List/Document Library> page.

Expand Mobile on the Create View:  <List/Document Library> page.

Select Make this a mobile view (Applies to pubic views only) and optionally Make this the default mobile view (Applies to public views only).

Click OK.

Now that you understand mobile site URLs and views in Windows SharePoint Services 3.0/Microsoft Office SharePoint Services 2007, go collaborate…on the go!


Microsoft Office SharePoint Server 2007 Receives U.S. Department of Defense 5015.2 Certification

Microsoft Office SharePoint Server 2007 has received U.S. Department of Defense 5015.2 certification. The 5015.2 standard on which the Department of Defense certification is based serves as the benchmark for government and corporate organizations that manage records and documents and is endorsed by the National Archives and Records Administration.  Read the entire article here.


Co-hosting Collaboration and Personal Site Collections within an Individual Web Application

One of the most common questions I receive is how to co-host traditional “team” and personal Site Collections (My Sites) within an individual Web Application in Microsoft Office SharePoint Server 2007. While possible, there are several important steps that you should be aware of.

The public profile page is a document specific to the SPSMSITEHOST site template (My Site Host); unless a My Site Host is defined in the server farm, public profile pages will not be available to users. A Web Application can have only one (1) root Site Collection, and as a result can host only one (1) site template. In a portal specific scenario, an Enterprise site template is generally applied to the root Site Collection, typically the Publishing or Collaboration portal. To ensure the public profile page is made available to the root Site Collection, it becomes necessary to establish a web under the root Site Collection that will host the My Site Host site template. In order to achieve this you will need to create a new web at http://<server>/<web&gt; that will host the My Site Host site template containing person.aspx. Person.aspx is hosted in the %commonprogramfiles%Microsoft SharedWeb Server Extensions12TEMPLATESiteTemplatesSPSMSITEHOST directory.

There are several considerations that apply to this scenario:

· The SPSMSITEHOST template must be applied to the web hosting the public profile page.

· The web hosting the My Site Host site template cannot use an existing managed path, e.g. /personal or /sites.

· The Shared Services Provider (SSP) should be configured to use the root Site Collection + My Site Host web as the My Site Host. This can be configured under Shared Services Administration | User Profiles and My Sites | My Site settings | Personal Site Services.

· The root web application should have the managed path /personal defined in Central Administration to maintain URL differentiation between traditional “team” and personal Site Collections.

This process will permit continuation of the typical SharePoint Portal Server 2003 configuration and Site Collection hosting model with one key difference:

· Personal Site Collections will be available to users through http://<server>/<user&gt;.

· Public profile pages will be rendered to users through http://<server>/<public&gt;?person.aspx?guid=<guid>.

The example scenario below illustrates a database migration approach upgrade where a root web application is selected as both the traditional “team” and personal Site Collection host:

Step 1 Upgrade the _SITE database using the database migration approach. See command line reference below:

STSADM -o -addcontentdb -url http://<rootwebapplication&gt; -databaserver <SQLServer> -databasename <portal>_SITE

Step 2 Upgrade the database hosting the personal site collections using the database migration approach. See command line reference below:

STSADM -o -addcontentdb -url http://<rootwebapplication>/personal databaserver <server> -databasename <personalsitesdb>

Step 3 Create a new web under the root Web Application (http://<rootwebapplication&gt;) using the My Site Host template. See command line reference below:

STSADM -o createweb -url http://<rootwebapplication>/public -template SPSMSITEHOST -title “Home” -description “Some Description”

Step 4 Introduce the managed path /personal to the root Web Application if it does not already exist.

Step 5 Upgrade the _PROF database using the database migration method. See command line reference below:

STSADM -o restoressp -title <ssptitle> -url http://<sspwebapplication&gt; -ssplogin <domainusername> -mysiteurl http://<rootwebapplication>/public -indexserver <indexserver> -indexlocation “D:Program FilesMicrosoft Office Servers12.0DataOffice ServerApplications” -keepindex -sspdatabaseserver <databaseserver> -sspdatabasename <sspdatabasename> -ssppassword <password>

This process is beneficial to the database migration upgrade approach in scenarios where you are upgrading the SharePoint Portal Server 2003 _SITE, profile and content databases or optionally select to establish a new SSP in your server farm. If selecting to establish a new SSP; the root web application can be created prior to creating the SSP allowing for the establishment of the new root Site Collection as the My Site Host during the SSP creation.


Securing SharePoint Products and Technologies for the Extranet

When preparing to deploy an Internet accessible Microsoft Office SharePoint Server 2007 web farm security is the forefront of discussion and planning. To provide a brief insight into securing SharePoint Products and Technologies, I’ve decided to finally consolidate, compile and make available some of my notes. Hopefully this will be of benefit in helping others understand the method by which SharePoint Products and Technologies communicate and a high-level security overview. Internet Information Services (IIS) is the obvious first candidate for preparation and discussion –we’ve concluded IIS will be configured to use both basic and Integrated Windows authentication methods, basic allows credentials to be transmitted unencrypted and secured by SSL. The benefit of this is twofold, one it can be easily used in the extranet environment and two; basic authentication is part of the HTTP 1.1 protocol, supported by virtually any browser. Integrated windows authentication is provided to our intranet users and implemented as NTLM. SSL/TLS Transport Layer Security secures a channel between the browser and web server and IPSEC secures the communication between the web servers and the SQL backend and an additional IPSEC policy configured and applied to handle Search – Index server relationships when indexes are propagated from the index management server to the search server. In SharePoint Portal Server/Windows SharePoint Services user authentication is based on Windows security accounts, ASP.NET is configured to use Windows authentication for SharePoint Site Collections meaning ASP.NET relies on IIS to perform the required authentication of client(s). IIS will then authenticate the user against Windows security accounts and pass the identity to ASP.NET.

Transaction Paths

Often overlooked is the communication which occurs inside the environment itself. Communication in SharePoint Products and Technologies occurs in several distinct manners to include changes to the configuration where a web front-end (WFE) will communicate with the configuration database to relay changes to the deployment, change requests which include typical user transactions occurring in the content database submitted by the WFE such as updating/adding/deleting List items, documents, etc. Another transaction occurring nearly as often; however, more complex in the nature of the transaction are search requests – the user submits the request, the WFE then communicates with the query server to generate the results at which point the WFE will provide the content based on the previous transaction through communication with the content databases/content database server. Indexing transactions and requests must occur to both provide search results and build indexes through a separate communication channel with the content database/content database server. A proper IPSEC implementation and policy definition and application can secure these transactions to provide a high level of communication security within the datacenter and remain transparent to the consumers of the technologies. Microsoft Office SharePoint Server 2007 now supports configuration of the Shared Service Provider to leverage Secure Sockets Layers to secure a channel between the server machine(s) hosting the SSP and the Shared Services database(s), providing an additional layer of security within the web farm. Joel Oleson has a great post on this topic (25 Tips to Lockdown Your SharePoint Environment), covering high-level ISA, Kerberos, and Firewall considerations.


Common Extranet Design


Site Collection and subsite Backup, Restore, and Migration

I received an inquiry this week asking how to migrate an existing Site Collection as a subsite of a new parent Site Collection without having the availability of SMIGRATE in Microsoft Office SharePoint Server 2007/Windows SharePoint Services 3.0. The answer are new STSADM parameters, import and export, which has been made available in STSADM. The import/export feature is based on the new Content Migration APIs; Recycle Bin state and alerts are not included in STSADM -o export – the requirement that the new Site Collection or subsite exists, remains as with previous versions of STSADM when using the restore parameters. A benefit of the export parameter is that security settings will be included if desired; whereas, in SMIGRATE WSSUserUtil was required to capture and import web security. Sample syntax of the new parameters follows:

stsadm -help export
  [stsadm -o export -url URL -f filename]
stsadm -help import
  [stsadm -o import -url URL -includesecurity]

For more information on Content and site migration visit http://technet2.microsoft.com/Office/en-us/library/16a7e571-3531-4a4e-baa7-f348a9f9d1d11033.mspx?mfr=true


Best Practices: Are your DIPs alive? Alternate Access Mapping may be the answer…

Historically alternate access settings provided a mechanism to identify the different ways in which users access portal sites; in MSIT we’ve taken that practice one step further and leverage alternate access mappings (AAM) as a means to identify problem web front-ends in a NLB cluster. As an example an NLB (network load balancing) cluster may be bound to a VIP (virtual IP address) with a mapping of foo, where the hosts are foo1 and foo2, by leveraging alternate access mappings we can DIP test foo1 and foo2 both independently and through the Microsoft Operations Manager (MOM) Web Sites and Services Management Pack. The basic rules of AAM are that every alternate access setting entry must have a default URL, at which point each can have additional alternate acccess methods for either intranet, extranet, or custom access. Each URL though must differ from all other URLs. These mappings are stored in the configuration database. Microsoft Office SharePoint Server 2007 uses the default URL for any requested URL that is not found in the mapping table.

For more information about Alternate Portal Access Settings in Microsoft Office SharePoint Portal Server 2003 visit http://office.microsoft.com/en-us/assistance/HA011603021033.aspx.