CHunky Universe of Vigourous Astonishing SHarepoint :)

Tag Archives: SPFeature

Add global navigation links in Powershell and Feature Receiver

I think, powershell is the best way to do configurations you have to do once. Adding some links to global (top) navigation is one of them:

asnp microsoft.sharepoint.powershell
$w = get-spweb http://takana
$l = New-Object Microsoft.SharePoint.Navigation.SPNavigationNode("Smells like team spirit", "/pages/teamspirit.aspx")
Feature receiver

The alternative is to create a web scoped feature and provide properties:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
    var web = properties.Feature.Parent as SPWeb;
    var prop = properties.Feature.Properties["MyGlobalLinks"];
    var links = prop.Value.Split(new[] { ";#" },
    foreach (var item in links)
        var newLink = item.Split(new[] { ";" },
        var newMenuItem =
                new SPNavigationNode(newLink[0], newLink[1]);

This feature can be prefereably hidden. The properties are passed in onet:

<!--Meglerfront: Page Navigation-->
<Feature ID="7829235a-ffb3-4ddf-0b5b-2a1d79668aa5">
  <Properties xmlns="">
    <Property Key="MyGlobalLinks"
     Value="Salam;/$Resources:cmscore,List_Pages_UrlName;/salam.aspx;#Ciper;/$Resources:cmscore,List_Pages_UrlName;/ciper.aspx" />

In the example no error handling is provided for the sake of brevity.


I found even a third way to add links to global navigation: NavBarLink

<NavBar Name="$Resources:core,category_Top;"
    Body="&lt;a ID='onettopnavbar#LABEL_ID#' href='#URL#' accesskey='J'&gt;#LABEL#&lt;/a&gt;"
  <NavBarLink Name="Hello" Url="/sider/Hello.aspx"/>
  <NavBarLink Name="Hello2" Url="javascript:SayHello();"/>

It is much simpler, as simple as unbelievable :). Are there some problems with NavBarLinks?

Edit: I found one shortcoming with NavBarLink: you can’t use resources from cmscore like $Resources:cmscore,List_Pages_UrlName;. To solve we can create a copy of this string in our custom resource file: $Resources:Takana,List_Pages_UrlName;.

Retention policies

Ziegler provides a cool intro, implementation sample and much more.

When deployed we can apply this policy to a contenttype in the UI, or in code.

To create our own expiration logic we have to implement IExpirationFormula and its ComputeExpireDate:

public class TaskExpiration : IExpirationFormula
	public DateTime? ComputeExpireDate(SPListItem item,
						XmlNode parametersData)
		if (!item["Status"].Equals("Completed"))
			return null;
		var dt = (DateTime) item["Modified"];
		return dt.AddDays(30);

In order to see IExpirationFormula, add a reference to Microsoft.Office.Policy (and maybe Microsoft.Office.DocumentManagement):

To see our custom retention policy, we have to register it in xml, we can do it in Feature Receiver like Yaroslav:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
    const string xmlManifest =
       "<PolicyResource xmlns='urn:schemas-microsoft-com:office:server:policy'" +
       " id = 'Takana.TaskRetentionPolicy'" +
       " featureId='Microsoft.Office.RecordsManagement.PolicyFeatures.Expiration'" +
       " type = 'DateCalculator'>" +
       " <Name>Takana Task Retention Policy</Name>" +
       "<Description>Tasks expire 30 days after they have been completed</Description>" +
       "<AssemblyName>Takana.SharePoint, Version=, Culture=neutral, " +
       "PublicKeyToken=920c0327f8b01d97</AssemblyName>" +
       "<ClassName>Takana.SharePoint.Policies.TaskExpiration</ClassName>" +

The feature has to be Webapplication scoped, otherwise you get “No access” (“Ingen tillgang” i nb-NO) when you try to add this xmlManifest.

Or in Powershell, like it is described by Microsoft. Create an xml like this:

<PolicyResource xmlns="urn:schemas-microsoft-com:office:server:policy" 
    id = "Takana.TaskRetentionPolicy" 
    type = "DateCalculator">
    <Name>Takana Task Retention Policy</Name>
    <Description>Tasks expire 30 days after they have been completed</Description>
    <AssemblyName>Takana.SharePoint, Version=, Culture=neutral, PublicKeyToken=920c0327f8b01d97</AssemblyName>

Then access the xml file and add it to policy resource collection:

$policyResource = Get-Content .\takan.taskretentionpolicy.xml

If you want to remove your policy resource, just run delete with your resource id:


The items are collected by the “Expiration policy” timer job:

Expiration Policy
Enumerates list items and looks for those with an expiration date that has already occurred. For those items, runs disposition processing. Disposition processing most often results in deleting items, but it can perform other actions, such as processing disposition workflows.

If you want to see the changes directly when developing, you can change the interval of timer job.

Expiration Policy timer job and SP1

If the timer job doesn’t run, re-activate RecordsManagement feature:

Install-SPFeature RecordsManagement -force
stsadm -o setpolicyschedule -schedule "daily at 00:10:00"

This solved the problem why the items are not deleted. But my custom policy resource had to be re-published, too.

Expiration Policy is the timer job which removes the items. What does the Information Management Policy timer job?

To associate a policy to a content type is easy in UI, but not so straight forward in code. Here is some beginning:

$web = get-spweb http://takana
$list = $web.Lists["Tasks"]
$ctype = $list.ContentTypes["Task"]
[Microsoft.Office.RecordsManagement.InformationPolicy.Policy]::CreatePolicy($ctype, $null)
$p = [Microsoft.Office.RecordsManagement.InformationPolicy.Policy]::GetPolicy($c)
$data = Get-Content .\takana.taskretentionpolicy.schedule.xml
$p.Items.Add("Microsoft.Office.RecordsManagement.PolicyFeatures.Expiration", $data)
$site = get-spsite http://dev

This code loads the xml from the same folder:

<Schedules nextStageId="2">
    <Schedule type="Default">
            <data stageId="1" stageDeleted="true" />
                <formula id="Takana.TaskRetentionPolicy" />" +
                <action type="action" id="Microsoft.Office.RecordsManagement.PolicyFeatures.Expiration.Action.Delete" />

Or add to a list:

$web = get-spweb http://takana
$list = $web.Lists["Tasks"]
$policySettings = new-object Microsoft.Office.RecordsManagement.InformationPolicy.ListPolicySettings($list)

if ($policySettings.ListHasPolicy -neq $false)
	#make the list use a custom list policy
	$policySettings.UseListPolicy = true;

The code to add policy to a c ontent type has not been tested yet.

Update 20120831: A nice description and code samples on Yaroslav Pentsarsky’s blog: Help users manage SharePoint content by setting expiration policies with PowerShell

Uninstall custom features in a batch

A funny powershell command I came upon today together with my colleague. Remove all your custom features (which start with something, say contoso):

       | Where { $_.DisplayName.StartsWith("Contoso.") } 
       | ForEach { Uninstall-SPFeature $_.Id -confirm:0 -force }
Have fun!
Вула Чăвашла

VulaCV - Чăвашла вулаттаракан сайт

Discovering SharePoint

And going crazy doing it

Bram de Jager - Coder, Speaker, Author

Office 365, SharePoint and Azure

SharePoint Dragons

Nikander & Margriet on SharePoint

Cameron Dwyer

Office 365, SharePoint, Azure, OnePlace Solutions & Life's Other Little Wonders


Me and My doings!

Share SharePoint Points !

By Mohit Vashishtha

Jimmy Janlén "Den Scrummande Konsulten"

Erfarenheter, synpunkter och raljerande om Scrum från Jimmy Janlén

Aryan Nava

DevOps, Cloud and Blockchain Consultant


SharePoint for everyone


Ryan Dennis is a SharePoint Solution Architect with a passion for SharePoint and PowerShell

SharePoint 2020

The Vision for a Future of Clarity

Aharoni in Unicode

Treacle tarts for great justice

... And All That JS

JavaScript, Web Apps and SharePoint


Mostly what I know about SharePoint - CommunicoCuspis


SharePoint på ren svenska