Monthly Archives: March 2013

Managed metadata navigation is a new feature in SharePoint 2013 that allows the user to configure the navigation on a site collection based on a term set in the term store. This brings a lot of benefits for the site administrators, as they can define SEO-friendly URL’s, and they can update the navigation anytime using the term store management tool. There are several blog posts out there that show how it can be configured, so I will skip this part.

Although it is a very powerful feature, it still has some limitations. They can be seen especially when you have an Information Architecture that spans across a lot of site collections and maybe across web applications, and you would like to use the same navigation in all places. When you try to bind the same navigation term set to a new site, you will get a message that says the term set is already bound to a different site, and if you choose to proceed, the navigation settings for the other site will be broken.


Considering you have proceeded, on the initial site, the navigation will not work anymore, and you will receive an error message.


I have searched for different resolutions on this topic and  I have found two solutions on how to overcome it:

  • Create a new term set, and pin it to the source term set. The new term set is a copy of the source term set, and it can be used in a new site collection. This technique is explained in more detail here. However, if you have a lot of site collections, this can lead to a very large number of term groups and term sets in the term store.
  • Create a custom control (server-side), or a script (client-side JavaScript) that reads from a term set in the term store, and renders the navigation as you want it. You can find a sample for this here, and it also includes source code and explanation for it. if you are using this, you will have to recreate the Html and JavaScript for the navigation, that is by default rendered by the AspMenu control (this might become tricky if there are multiple dynamic levels for the navigation).

Another solution would be to create a custom navigation provider that retrieves the navigation nodes from a managed metadata navigation term set. I find this solution an easy way to overcome the limitation because you only have to retrieve the navigation nodes, and you can leave the rendering to the default AspMenu control. It is a highly reusable solution, which requires no change when it is used in different projects for different customers. The drawback – you need a farm solution to be able to create a custom navigation provider.

I will not post the entire code for this here, but I will only highlight the main ideas that are needed for this:

  •  Create the custom navigation provider. You will have to create a class that inherits from PortalSiteMapProvider or from SiteMapProvider. Code sample for this can be found on msdn.
  • Register the navigation provider with a web application feature, and by making changes to web.config file. Code sample for this can be found on msdn.
  • Change the master page to use your navigation control, or deploy an elements file with a control element that enables the use of your navigation provider. Code sample for this can be found on msdn.
  • I recommend using the cache for the navigation data, once you retrieve it from the term store. You can use the web application cache, or the distributed cache service. I prefer the later one, as  it works the same way across multiple front-ends.
  • When you retrieve the data from the navigation term set, the key method is NavigationTermSet.GetAsResolvedByWeb , as it returns the navigation term set object, as if it would be attached to that web.
  • Once you have the NavigationTermSet object, you can find all its children NavigationTerm . From there, you can work with everything that you can define in the term store management tool for that term.

I would have liked SharePoint 2013 to ship with such a navigation provider OOB, but, if not, the effort to implement it is not really large, and I believe it is definitely worth it.


In many scenarios where you have to build up a complex Information Architecture in SharePoint, you will also have to set the Search Settings for each site or site collection to point to your search center and your custom results page.

Search Settings Page

Search Settings for a site in SharePoint 2013 UI

These settings are stored in the property bag of the site. For SharePoint 2010, this blog post shows the property names, and how they can be set using Powershell. In SharePoint 2013 the search settings have become a little bit more complex, therefore we need a new script to set them. Below you will find two powershell functions: one that sets the search settings for the entire site collection and one just for a specific web.

function SetSearchSettingsSite($siteUrl,$searchCenterUrl,$resultPagesUrl)
 $site = Get-SPSite $siteUrl
 $site.AllWebs | ForEach-Object {
 $web = $_
 $web.AllProperties["SRCH_SB_SET_WEB"] = '{"Inherit":false,"ResultsPageAddress":"'+$resultPagesUrl+'","ShowNavigation":false}'
 $web.AllProperties["SRCH_ENH_FTR_URL_WEB"] = $searchCenterUrl
function SetSearchSettingsWeb($siteUrl,$searchCenterUrl,$resultPagesUrl)
 $web = Get-SPWeb $siteUrl
 $web.AllProperties["SRCH_SB_SET_WEB"] = '{"Inherit":false,"ResultsPageAddress":"'+$resultPagesUrl+'","ShowNavigation":false}'
 $web.AllProperties["SRCH_ENH_FTR_URL_WEB"] = $searchCenterUrl

The second part of the search settings has been integrated in a single web property – “SRCH_SB_SET_WEB”, as a representation of a SharedSearchBoxSettings object. This script only sets the search settings at site-level. If you want to configure the search settings at site-collection level or at farm-level, it would be slightly different. At site-collection level, you would need to set the root web property “SRCH_SB_SET_SITE”, and for farm-level, you would need to set the SharedSearchBoxSettings and SearchCenterUrl properties of the Search Service Application. For more details, please see this post.

In a different blog post I have explained the basics of working with publishing navigation in SharePoint 2013. The OOB navigation offers two options: “structural navigation” and “managed metadata navigation”.

Managed metadata navigation is bound to a term set, that provides the navigation nodes for your site (more details on how to configure it here). If you want to change this, or you are simply looking for a script that will set this up in new environments, here it is:

Add-PSSnapIn Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

$assembly = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Publishing")

function UpdateNavigation($url,$termStoreName,$termGroupName,$termSetName){
 $web= Get-SPWeb $url
 $site = $web.Site
 $navSettings = New-Object Microsoft.SharePoint.Publishing.Navigation.WebNavigationSettings($web)
 $taxSession = Get-SPTaxonomySession -Site $site
 $termStore = $taxSession.TermStores[$termStoreName]
 $termGroup = $termStore.Groups[$termGroupName]
 $termSet = $termGroup.TermSets[$termSetName]
 #Quick Launch
 $navSettings.CurrentNavigation.Source = 2
 $navSettings.CurrentNavigation.TermStoreId = $termStore.Id
 $navSettings.CurrentNavigation.TermSetId = $termSet.Id
 #Global Navigation
 $navSettings.GlobalNavigation.Source = 2
 $navSettings.GlobalNavigation.TermStoreId = $termStore.Id
 $navSettings.GlobalNavigation.TermSetId = $termSet.Id

$navSettings.AddNewPagesToNavigation = $false
 $navSettings.CreateFriendlyUrlsForNewPages = $false
 Write-Host "Navigation updated succesfully for site $url"
#Sample usage: UpdateNavigation "Managed Metadata Service" "My Navigation Group" "Navigation"

An important limitation of this managed metadata navigation is the fact that a term set can only be bound to a single site. You can find more on this topic post.