Blog Archives

Harness SharePoint Library and Folder Default Views to build more appealing solutions

Article Index

1. Introduction

Why use different default views based on navigation hierarchy?

What are the different levels that a default view can be set?

Caution: Per-location view defaults

2. Library default views

3. Folder default views

4. Custom Folder default views

5. Document Set (and Custom Document Set) default views

1. Introduction

This article describes the different methods and techniques available for configuring default views at different hierarchy levels (folder levels) within a SharePoint library. This article presents the options and how to implement them in SharePoint 2013. All options/settings discussed also apply to SharePoint 2010.

Why use different default views based on navigation hierarchy?

People use libraries for many different purposes. If you are storing different types of documents in a library (especially if you are using different content types) the properties (or columns) of information may be specific to the different types of items in your library. Allowing the default view to be set at different levels in the navigation hierarchy means that you can show the user views that are specifically customized for showing the data in that location.

This is really where all the action is at. We’re talking about what happens when the user navigates either from the root level of a library into a folder, or from a folder into a lower level folder. Usually we group items in folders for some logical reason, and based on that logic it is reasonable to expect that we might want to show a different view of the items in that folder.

We actually have a few options available to us at this level depending on the types of folders that have been implemented. Let me bore you with some details about folders that may assist with some of the terminology used through the rest of this article.

Folders are a content type in SharePoint. Through the SharePoint UI you can create your own custom content types that are based on the folder content type (I’ll refer to these as custom folder content types, or just Custom Folders). Then there’s Document Sets which are based on the folder content type (just like a custom folder content type) but contain a lot of extra intelligence that SharePoint gives you out of the box. In the same way you can create custom folders by extending the base Folder content type, you can also create your own Custom Document Set content types by extending the standard Document Set content type.

The techniques for applying a default view to a folder is different for Folders, Custom Folders, and Document Sets, so we will discuss them one at a time.

What are the different levels that a default view can be set?

Library (top level)


Custom Folder

Document Set

Custom Document Set

This article will go through each of these different navigation hierarchy levels and explain with examples how default views can be applied and what it looks like.

Caution: Per-location view defaults

SharePoint also has the concept of “per-location view defaults” which is part of the Metadata Navigation and Filtering feature. On the surface it seems that there is a big overlap between setting default at the different hierarchy levels (as I will discuss in this article) and the per-location view defaults (which claim to let you specify a default view to use at any level in the hierarchy). In reality the per-location defaults do not affect the default views used as a user navigates between folders. These per-location view default only apply if you select to open the location via the Metadata Navigation tree. This method has some fairly major caveats and I’d advise caution when using it to implement folder level view defaults. If you want to know more about this option please read SharePoint per-location view settings (capabilities, limitations & pitfalls)

2. Library default views

This one is as simple as it gets. Every list or library in SharePoint contains one or more views. One of those views can be set as the default. You do this directly on the view settings page.

Open the library and select Library Settings


Scroll down to the Views section, where you can see all views for the library and also which view is currently set as the default.


To change the default view, click the name of the view you want set as the new default. This will open the view settings page. Now tick the ‘Make this the default view’ checkbox.


Save the changes and now navigate to the library in SharePoint and this time your selected view is displayed by default.


3. Folder default views

When to use it

Use this method when you want to show one view in the root of the library (when not in any folder), and a different view when inside any folder within the library.

What it looks like

In this example I’ve added 3 columns to a standard Document Library (Project, Project Manager, Document Type)


In my library I have only folders at the root level of my library (no documents stored at this level) so I just want columns for the title of the folder.


When I go into any of the folders I want to see a different default view which shows me documents grouped by Project and also shows the Project Manager and Document Type.


How to implement it

Ensure content type management is enabled for the library. This is under Library Settings | Advanced Settings.


Create a view to use at the root (top-level) of the library, selecting the desired columns, sort order, etc. I’ve called mine ‘Library View’. The important steps here are to:

1 – Set this view as the default view


2 – Expand the Folders setting option and select ‘Show in this view: In the top-level folder’. Note: these options only become available once you have enabled management of content types in the library.


Now save the view and the library view settings should look similar to this:


Notice that Library View is designated to only show in Top-level and is set as the default view for the library.

Now create another view that you want to use to display documents when inside folders. Again create the view and setup the desired column, grouping, sort order etc. I’ve called mine ‘By Project’. Important steps here are:

1 – Set this view as the default view. Yes I agree this doesn’t seem right. You would expect this to replace the ‘Library View’ as the default view – but in combination with the ‘Folders: Show in’ option some unexpected magic happens! Read on.


2 – Expand the Folders setting option and select ‘Show in this view: In folders of content type [Folder]’


Now save the view and take a look at the view settings for the library.


SharePoint has allowed us to have 2 default views! The show in column tells us that the ‘Library View’ view is the default for the Top-level (or root) of the library and the ‘By Project’ view is the default when in any Folder.

That’s it – when you now navigate to the library you will see the ‘Library View’ and then clicking to navigate inside a folder will automatically switch to the ‘By Project View’.

I was interested to see what would happen if I created another view at the “Show in folder” level and tried to set it as the default. I created a view called ‘By Manager’ and set it as default.


As you can see SharePoint is enforcing that I can only have 1 default view at the folder level and this is independent of the default view at the Top-level.

4. Custom Folder default views

When to use it

Use this method when you want to be able to specify a default view at the root level of the library, and a different default view for each type of custom folder. Your intended design might not use custom folders, but consider using them so that you can use the different custom folder types to assign different default views.

What it looks like

I have created a library to hold employee timesheets and expense claims. Timesheets and Expenses are two separate content types that I have created. I want to create a folder per project in the library, and within each project I’ll create an Expenses folder and a Timesheet folder to store the actual documents. Since Expenses and Timesheets contain different columns I want a specific default view when browsing inside Expense folders and a different default view when browsing in Timesheet folders.


With the use of custom folder content types I can have a default view at the library level showing detailed folder information (as shown below)


Then the default view is changed when browsing into any of the Timesheet folders to present Timesheet specific information (such as Week Start Date, Employee Name and Total Hours) in a nice friendly format.


A different default view is used when browsing into any of the Expense folders so you can quickly see Expense specific information such as the Total Amount of the expense.


How to implement it

Ensure content type management is enabled for the library. This is under Library Settings | Advanced Settings.


Before configuring the library we need to create some custom folder content types that we will use in the library. Management of content types is done at the site level (Site settings | Site Content types)


Create a new content type for the custom Timesheet Folder, setting the parent content type to ‘Folder’.


Save the new content type, then add the existing Comments site column to this content type


Select the Comments column so that our content type now has these columns


Create a second custom folder content type for the Expenses Folder, setting the parent content type to ‘Folder’.


As with the Timesheets Folder content type, go ahead and add the Comments column


Now in the library settings we need to add the two new custom folder content types


Select the Timesheet Folder content type and the Expenses Folder content type


Your library setting should look similar to this


Now we need to create the view we want to use as default when browsing in Timesheet folders


Similarly we need a default view to use for showing Expenses


To get the default view applying to folders based on the custom content type of the folder, we go into the view settings for the view you want to make a default. So let’s start with the Timesheets by Week view.

Check the ‘Make this the default view’ checkbox


Expand the Folders setting option and select ‘Show in this view: In folders of content type: Timesheets Folder’


Then edit the Expenses by Project view. Check the ‘Make this the default view’ checkbox


Expand the Folders setting option and select ‘Show in this view: In folders of content type: Expenses Folder’


After making these changes the Views section of the library settings should be similar to this


Notice the All Documents view is set to Show In All. In this state you will find that the All Documents view will be the default (even within Timesheet and Expenses folders). We need to change the All Documents view so that it only used as the default at the top level.

Edit the All Documents view, expand the Folders setting option and select ‘Show in this view: In the top-level folder’. The View settings should now look like this.


Enough configuration, let’s start populating the library now. First we will setup the folder structure.

At the top level of the library we create Project folders using the regular Folder content type



Within each of these project folders, we create one Timesheets folder (using the Timesheet Folder content type) and one Expenses folder (using the Expenses Folder content type)


Inside the Project ABC folder, I now have these 2 folders.


Browsing to these folders now you should find that the default view is changing automatically as you navigate.

Library root/project subfolders (use All Documents view)


Expense Folders (use Expenses by Project view)


Timesheet Folders (use Timesheets by Week view)


5. Document Set (and Custom Document Set) default views

When to use it

Use this method when you are using Document Sets in your library and you want one view at the root level of the library and a different view when you are viewing the contents of a Document Set. The same default view will be used for all instances of the Document Set within the library. If you have multiple different Custom Document Set content types in the library, you can specify a different default view for each of the different Custom Document Sets.

What it looks like

When browsing the root level (top level) of the library the All Documents view is used by default


Navigating into any document set switches the default view so that we can present the document properties in a better way.


In the case of multiple Document Set content types you can have a default view at the top-level (customized for showing information about the document sets) then have a different default view for each of the different document set content types. In the following example I have a library with 2 custom document sets (Small Project Document Set and Large Project Document Set).

The default library view shows a list of all document sets (includes both Small Project and Large Projects) and exposes specific document set properties as columns and groups by Project Status


When navigating into the first project (which is an instance of the Small Project Document Set) I get a default view customized for small projects


When navigating into the second project (which is an instance of the Large Project Document Set) I get a default view customized for large projects


How to implement it

Ensure content type management is enabled for the library. This is under Library Settings | Advanced Settings.


From Library Settings click Add from existing site content types


Add the Document Set content type


Once you’ve created your document sets (at least a few to start with), configure the All Documents view to display document set information that you want to see.

Next create a new view to use when showing the content of a document set (I called mine Document Set View)


Select Library Settings | Content Types | Document Set


Then select Document Set settings


Now use the Welcome Page View option to select your new view to show content within Document Sets


We are done, navigating into a document set should now use this view by default.

If you are using multiple custom document set content type, simply repeat the steps to assign Welcome Page View to each of the content types.

Further Reading

Integrating Outlook Web Access (OWA) and SharePoint 2013

SharePoint 2007 and SharePoint 2010 had a series of Web Parts dedicated to surfacing and interacting with an Exchange mail account directly from a page in SharePoint.

Overview of the Outlook Web Access Web Parts (for SharePoint 2007 and 2010)

If you are not familiar with the functionality here’s a quick overview (this info is taken from the official Microsoft help documentation

There are five Outlook Web Access Web Parts. These can be used with Microsoft Exchange Server version 2003 to 2007:

  • My Calendar
  • My Contacts
  • My Tasks
  • My Inbox
  • My Mail Folder

These Web Parts are most useful for your My Site, because only you (or someone who can log into your Exchange e-mail account) will be able to see the information from your folders. If you put one of these Web Parts on a shared site, other users will see the Outlook Web Access logon screen in the Web Part.

My Inbox Web Part on My Site

Each Web Part displays the information from a folder in your email account, so you can choose the information you want to show on your site. The Web Parts make it easy to show specific information, such as tasks, without showing all of your Outlook information. If you want to have full Outlook functionality on your SharePoint site, you can use a Page View Web Part linked to the URL for your Outlook Web Access server.

All of the Outlook Web Access Web Parts provide two-way communication with your Exchange Server e-mail account: Changes you make in a Web Part appear in Outlook.

What’s the Story with OWA integration in SharePoint 2013?

I was somewhat surprised when SharePoint 2013 arrived and all the Outlook Web Access web parts were missing. Had this been an oversight by Microsoft and they would reappear again in a cumulative update for SharePoint? It appears not.

On further digging Microsoft actually dropped support for the OWA web parts (in SharePoint 2010) if your mail was hosted in Exchange Online (Office 365). From the Exchange Online Service Description document:

Exchange Online supports Outlook Web App Web Parts via the PageViewer control in Microsoft SharePoint Online and Microsoft SharePoint Server, or via manually configured URLs. Built-in SharePoint OWA Web Part controls will not work against Exchange Online

The statement above alludes to an alternate method using the Page Viewer control (which to be honest I’d prefer to the OWA web parts which didn’t have the full functionality of the OWA interface). The idea behind using the Page Viewer web part is that OWA is just a web interface to your Exchange account served up at known URLs. So just wrap these in a iframe (Page Viewer web part) and you will have your full OWA interface embedded inside a SharePoint page. For a step by step guide of how to setup the Page View control to connect to Exchange Online (OWA) take a look at this article by Jesper_Osgaard.

So fast forward to SharePoint 2013, can we still use the Page Viewer web part technique? My experience so far has yielded mixed results.

More often than not the Page Viewer technique gets tripped up with security issues. I think the underlying issue is that an Internet Explorer session cannot handle authenticating with multiple domains at the same time and it just so happens SharePoint Online and Exchange Online reside in different domains.

This isn’t to say it flat out doesn’t work. Here’s a screenshot to prove it (no smoke and mirrors or Photoshop involved I promise). But I just didn’t find it stable enough to recommend it as a viable solution.



On reflection it would seem that Microsoft wasn’t able to iron out the complexities of integrating OWA content and SharePoint content in the same Internet Explorer session. If they could, then surely that would have provided better integration for the native SharePoint Site Mailboxes that were introduced in SharePoint 2013 (Exchange 2013). When a SharePoint Site Mailbox is provisioned, a mailbox is created in Exchange (for the SharePoint site) and a link is placed on the left navigation of the SharePoint site. When you click on the link you don’t get the mailbox content embedded in the SharePoint page (as you might expect and have hoped for!). Instead it launches a new Internet Explorer window (new IE session that can authenticate with a different domain) and opens the OWA URL directly to the mailbox. There’s essential no integration with the SharePoint UI other than a URL link.


SharePoint Client Browser 1.0 released, bye bye preview!

Very handy tool that developers and admins can add to their toolbag. Similar to the SharePoint Manager 2010/2013 tool that has been a great resource for many years now. SharePoint Client Browser has the added benefit of supporting different credentials modes, remote SharePoint Sites and handy PowerShell integration.

Bram de Jager - Coder, Speaker, Author

Finally after 2 months I decided to build the 1.0 version of SharePoint Client Browser and released it to the community! Although the preview (beta) status did not prevent people from downloading it. The counter is currently set at 555 downloads since start of the project on the 2nd of July (only 2 months ago).

CodePlex project and download at

So what got changed? I guess almost everything changed from authentication support for default (username and password), SharePoint Online, anonymous and forms based all the way to almost complete coverage of the Client Side Object Model (CSOM). That’s a bit over the top, but the basics for Foundation are in the tool. New capabilities for future releases will focus on Server components like taxonomy.

Remote PowerShell for SharePoint Online and on-premise

A hidden gem is the PowerShell support. It’s very easy to start a PowerShell session and use…

View original post 167 more words

How to create a custom SharePoint list definition using Visual Studio 2012

In this article you will learn how to create a custom list definition (not a list instance) using the Visual Studio 2012 visual designer with step-by-step with screenshots.

In Visual Studio 2012 select File | New Project

Select Templates | Visual C# | Office/SharePoint | SharePoint 2013 – Empty Project


If you don’t see this type of project available then you may need to download and install the Microsoft Office Developer Tools for Visual Studio 2012

Provide a name and location for the project/solution and OK

In the SharePoint Customization Wizard Prompt, configure the server to use for developing/debugging. If possible you will want to try and achieve a Sandboxed solution over a Farm Solution due to it’s ability to be able to be reused in more scenarios requiring less permission is the SharePoint environment.


Once the new solution has been created, we can use the new Visual Designer to create the List Definition. Right click the project in the solution explorer and select Add | New Item


Select Visual C# Items | Office/SharePoint | List, provide a name and click OK


Provide a display name for the list. We just want to create a list definition, not an instance of the list; This isn’t an option so what we do instead is go with the “Create a customizable list template and a list instance of it” and we will make some mods to the generated project files to remove the list instance so we are just left with the definition.


You should now see the list instance and definition files in solution explorer.


If you select the SettingsProfile in the solution explorer you will get the new List Visual Designer. Notice the “List” tab, this represents the instance of the list.


Since we only want the list definition, we are going to delete the list instance files from solution explorer. Select SettingProfileInstance, right-click and Delete.


You should now be left with just the list definition, the “List” tab will now be greyed out.


We can now get on with creating the list definition and there are plenty of articles out there on the finer points of doing this. Here are some for reference:


Just for completeness if you are following this through I’ve added a couple of columns to my definition.


Now lets deploy it to SharePoint to make sure it works

Double click the Feature in solution explorer to bring up the feature visual designer and package explorer

Here you can set options such as how the feature appears and it’s scope. For our purposes just confirm the items in the feature include just the list definition files.


Now select the project, right-click and Deploy


Once the solution has been deployed I’m going to navigate to my site in a browser and verify that the new solution has been deployed and the feature activated (by default the solution is deployed and activated, and the feature is scoped at a web level and activated). You should see messages in the Visual Studio status bar to this effect during the deployment.





Everything is now is place for us to create an instance of the list from the definition, so I’ll create a new app and select our Widget Settings Profile app (list definition).


Provide a name for the new list instance based on our custom list definition.


We can now create items in the list and we see our columns coming through that were defined in the custom list definition.


Job complete, in this article we went through creating a list definition using the Visual Studio 2012 SharePoint 2013 List project template. We manually deleted the default list instance files so that we were just left with the list definition in our solution.

SharePoint Site Mailbox integration with Outlook – A new way to get email into SharePoint

What are SharePoint Site Mailboxes?

The SharePoint Site Mailbox concept is aimed at bringing Exchange emails and SharePoint documents together. So how does it do this?

The SharePoint Interface

A site mailbox can be created at a site level (maximum of 1 mailbox per site). From a navigation point of view the mailbox appears just as though it is another list or library in the SharePoint site.


When you click on the Mailbox link things aren’t as nice and integrated as you would hope. Instead of showing the content of the mailbox within the SharePoint site, as you would the content from a Document Library or List, rather the link simply opens the Site Mailbox in Outlook Web Access. You are taken away from SharePoint to see the content of the Site Mailbox.



This now starts to give you an understanding of what’s happening under the covers. When you add a Site Mailbox to a SharePoint site, you are effectively creating a mailbox on the Exchange server and then your site gets a link placed on it.

What is nice, is that the security of the mailbox is tied to the security permissions of your SharePoint site. So if you add or remove a user from your SharePoint site, the appropriate permissions are granted/revoked from the mailbox in Exchange as well.

Unfortunately this is about the extent of the integration of email and documents that you get through the SharePoint user interface, fortunately things will get a lot nicer when we look at things from the Outlook client…

The Outlook Interface

Outlook 2013 has been enhanced to support SharePoint Site Mailboxes. A really nice integration point is the automated rollout of Site Mailboxes directly to your Outlook profile based on your permissions to the SharePoint site. What this means is that if you are an owner or member of a SharePoint site and a Site Mailbox is created, that Site Mailbox will automatically get added to Outlook (even while Outlook is running). If your membership to the site is removed then the mailbox is automatically removed from Outlook as well. The Site Mailbox is represented in Outlook as a new store per site. All this talk of Site Mailboxes is a bit misleading though, because what you are actually getting in Outlook is the Document Libraries from the SharePoint site, not just the mailbox. What do I mean? lets have a look graphically at what you are getting:


When viewing the content of a Site Mailbox, the view presented is the same format and appearance as any other mail folder as shown below:


When viewing SharePoint Document Libraries you see an Outlook view of all the items in the document library as shown below:


This is pretty cool. Exchange and SharePoint perform a synchronization to make this possible and stubs (not the actual file content) is stored in Exchange to make this view possible. Clicking on these items in the Outlook view to open them up then communicates directly to SharePoint to download and open the file.

Subfolders, both within the mailbox and within document libraries are supported.

Read more about what Microsoft has to say on SharePoint Site Mailboxes.


Pros and Cons

So now you have a basic grounding in what this integration looks like, what are the benefits and limitations of Site Mailboxes.


  • Site Mailboxes provide a consolidated view of site content stored within SharePoint and Exchange from within Microsoft Outlook
  • Minimal change with a familiar drag & drop process to the left navigation of Outlook. Allowing the capture of emails or email attachments into SharePoint and Exchange
  • Convenient access to SharePoint content from within Microsoft Outlook using a familiar metaphor of folders on the left navigation of Outlook.
  • Ability to include a Site Mailbox as an email recipient (e.g. cc’d) for saving emails into a Site Mailbox – Inbox
  • Ability to ‘Forward’ a link to a document within a Site Mailbox or drag/drop multiple documents into an email message.
  • Lifecycle Retention policies can be applied at a Site Mailbox level behind the scenes
    Management and Compliance: Site Mailboxes can be part of eDiscovery Search Scopes.
  • Minimal change for the end users and therefore greater user adoption and promotion of enterprise content management best practices
  • Less reliance on the IT Department once the SharePoint and Exchange environment have been configured for Site Mailboxes
  • More efficient means to support the business with records management initiatives
  • Streamlined provisioning and deployment of Site Mailboxes to end users based on security permissions within a SharePoint Site
  • Email content is retained within Microsoft Exchange while documents are retained within SharePoint


  • Setting up the environment to support Site Mailboxes involves installing and configuring software on both the Exchange and SharePoint servers and setting up trust relationships and having all communication over SSL.
  • Probably the biggest drawback is that you are not actually getting email into SharePoint. The email is stored in Exchange. This means you can’t treat it as a SharePoint object and include it as part of a business process. E.g. include it a part of a workflow, add metadata columns to email and build a SharePoint business process around it. I will add quickly that you can drag/drop email directly to a Document Library and this will get the email into SharePoint as an msg file.
  • You must be running SharePoint 2013, Exchange 2013 and Outlook 2013 to get access to Site Mailbox functionality
  • Very limited features on drag/drop of attachments to SharePoint document libraries – basically no support for metadata of any kind (no content type selection, no columns to complete, no validation of mandatory column, can’t rename files on upload, no support for versioning)
  • Viewing of SharePoint content is very limited. You are provided more with a file type view of content rather than a SharePoint view. You can’t show SharePoint columns in the Outlook view, you just get the filename, last modified, size, and checkout status.
  • Maximum of 10 Site Mailboxes can be added to Outlook


Further Reading

For a more in-depth look at SharePoint Site Mailboxes, and how to overcome some of the limitations I suggest reading the article White Paper – SharePoint 2013 Site Mailboxes


Site Mailboxes Aren’t for You – Need a Different Option?

For alternate methods of getting email into SharePoint please refer to my article (written based on SharePoint 2010 options) Five out-of-the-box ways to get Email into SharePoint.

White Paper – SharePoint 2013 Site Mailboxes

pdf-download-whitepaperMicrosoft SharePoint 2013 has introduced a new concept called Site Mailboxes to help bring together Microsoft SharePoint and Exchange content within Microsoft Outlook 2013.

SharePoint Site Mailboxes provide many benefits and also have their limitations. This White Paper: SharePoint 2013 Site Mailboxes – Overcome their Limitations looks at Site Mailboxes and how they can be extended to implement broader solutions on the SharePoint platform.

The White Paper addresses how to enhance Site Mailboxes to:

  • Capture email attributes when saving to Site Mailboxes
  • Tag Content with custom metadata
  • Save to Site Mailboxes from Windows Explorer & Office applications
  • Access SharePoint capabilities from Site Mailboxes
  • Manage email attachments with Site Mailboxes



SharePoint Conference 2012 (Las Vegas) – Just 3 more sleeps

imageThe worldwide SharePoint Conference for 2012 (SPC12) is almost upon us. We are expecting this years conference to be massive with the new Wave 15 of technology having now having been release to manufacture by Microsoft. So we go into this conference with SharePoint 2013, Office 2013, Exchange 2013, Windows 8 all ready for production. Expect plenty of awesome sessions showcasing the power and opportunities that the new wave of technology brings with it.


The OnePlaceMail Team have been incredibly busy in preparation for this event with the new OnePlaceMail product ready to go straight into SharePoint 2013 / Office 2013 / Exchange 2013 production environments. This is welcome news to our early adoptors, those of you who have been using OnePlaceMail against the Preview software and in TAP environments, and are looking to go straight into production with 2013.

You will find the OnePlaceMail Team at booth #1046 in the Exhibition Hall where we will be running live demos of OnePlaceMail on the new technology. Of course we will have giveaways and competitions so you don’t leave the conference empty handed.


I look forward to meeting new friends, talking SharePoint and enjoying a SharePint or two.

Hope to see you there.

image          image

Fix Memory Leak in SharePoint 2013 Preview (Microsoft Office 2013 Component / NodeRunner.exe)

I’ve recently run into performance issues with my new SharePoint 2013 Preview development environment. A quick investigation in Task Manager highlight Memory usage as my issue. The culprit processes are Microsoft Office 2013 component. I see SharePoint 2013 is somehow behind my issue.


What are these Microsoft Office 2013 components and why are they consuming so much memory?

Switching to the details tab, these Microsoft Office 2013 components show up as noderunner.exe


Now having a bit more to search on I quickly uncovered the TechNet article SharePoint 2013 Preview – Hungry search service

This article attributes the issue to a memory leak in the SharePoint 2013 Preview Search Service.

To apply the fix from this article on the SharePoint 2013 server start the SharePoint 2013 Management Shell and and enter the following command:

Set-SPEnterpriseSearchService –PerformanceLevel Reduced


To ensure the setting has been changed enter the following command:



Then you need to edit the noderunner.exe.config file located at:

C:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0\noderunner.exe.config


Edit this file (I used Notepad), and locate the line <nodeRunnerSettings memoryLimitMegabytes=”0” />


Provide a memory limit for the noderunner process, I set the limit at 250 as shown below.


After making these changes I recommend you restart your server. Although I have had no problem with just killing the noderunner.exe processes in Task Manager; SharePoint creates them again almost immediately.

Keep in mind this fix is suggested for SharePoint 2013 Preview only, I’m hoping the bug will be fixed for RTM.

%d bloggers like this: