Set SharePoint default compatibility range after migration

SharePoint 2013 supports a great level of backward compatibility, where it allows us to run sites either in 2010 or 2013 mode. You can get more information on SharePoint 2010 and 2013 modes by referring to this article.
This feature comes in very handy for a migrated environment which has following requirements.

• Need to create new sites, but they should have SharePoint 2010 look and feel
• Site collection administrators should not be able to upgrade there sites to SharePoint 2013 until they feel it's 100% ready to do so

You may think above requirements are absurd. Why do we migrate an entire environment, and still keep the older look and feel. But they have some valid points.

• Users are not still ready for the new look and feel, and migrated environment should not cause any confusion for end users
• End user, super user, site administrator training is not complete yet.
• Policy where sites need to be upgraded gradually. (e.g.: home site upgraded first, and department site collections each week)

So how do we achieve the goal ?
We can modify the compatibility range web application property to arrive at a solution. We can use following Powershell commands to see current compatibility range

   1: $wa=Get-SPWebApplication "http://sp2013"

   2: $wa.CompatibilityRange

This provides us following information



The meaning of the above is that, if we create a site collection with default settings, the farm will create a site in SharePoint 2013 mode as the DefaultCompatibilityLevel is set to 15. Since the MinCompatibilityLevel is 14, it is possible to create sites with 2010 compatibility mode as well as 2013 mode with default settings (As shown in below image).



Apart from that, site administrators are notified that their SharePoint 2010 sites can be upgraded to SharePoint 2013 mode as the MaxCompatibilityLevel is set to 15.



Solution

We need to modify the compatibility range to suit our requirement. To do that we will execute following Powershell commands

   1: $wa=Get-SPWebApplication "http://sp2013"

   2: $range = New-Object Microsoft.SharePoint.SPCompatibilityRange(14,14)

   3: $wa.CompatibilityRange = $range

   4: $wa.Update()

   5: $wa.CompatibilityRange

The New-Object Microsoft.SharePoint.SPCompatibilityRange(14,14) instructs that both MinCompatibilityLevel and MaxCompatibilityLevel is set to 14 (SharePoint 2010 mode). So if we create new site collections, they will be in 2010 mode. (You can’t see the SharePoint 2013 option)



Furthermore site administrators are not notified about possible upgrade options.
If we need to revoke the setting later to allow SharePoint 2013 to be the default we need to execute following Powershell commands

   1: $wa=Get-SPWebApplication "http://sp2013"

   2: $range = New-Object Microsoft.SharePoint.SPCompatibilityRange(14,15)

   3: $wa.CompatibilityRange = $range

   4: $wa.Update()

   5: $wa.CompatibilityRange

In this scenario, MinCompatibilityLevel is set to 14 and MaxCompatibilityLevel is set to 15. The DefaultCompatibilityLevel is set to 15 which is as same as MaxCompatibilityLevel.

In a SharePoint migration scenario with strict policies and guidelines, CompatibilityRange property can be a lifesaver.

SharePoint 2010 mode in SharePoint 2013

If you’ve done a migration from SharePoint 2007 to SharePoint 2010, You may remember the visual upgrade features features of SharePoint 2010.

It was a cool feature. If the environment is still not ready for the drastically different SharePoint 2010 UI, They can still live with old SharePoint 2007 style UI.

But it had some drawbacks which makes it less usable. For an instance let’s assume we had web parts and some elements which we used in our SharePoint 2007 environment. Most of the time we get errors or they me not render properly in our new migrated environment.

SharePoint 2013 has improved a lot in the visual upgrade process and it provides us some additional benefits as well.

When we do a fresh installation, it’ll create both 14 and 15 folders in “Web Server Extensions” folder. (So we can say both 14 hive and 15 hive exists in SharePoint 2013 environment).

Why do we need both 14 and 15 hives in our SharePoint environment and what are the improvements in visual upgrade process ?

As far as I see, there are 2 main benefits

• Since it has Features, Layouts and Assemblies related to SharePoint 2010 solutions(WebParts and other elements) in 14 hive solutions will run seamlessly in a migrated environment.
• Apart from that when we deploy new SharePoint solutions (WSPs) we can target a specific compatibility level (SharePoint 2010 and 2013) as well by using the CompatibilityLevel Switch.
• We can scope site collections or entire web applications to SharePoint 2010 mode. If it is scoped in that way newly created site(s) will contain SharePoint 2010 UI and features. Simply say we can create sites in SharePoint 2010 compatibility mode as well as SharePoint 2013 compatibility mode.

In a separate post I’ll show some additional benefits of SharePoint 2013 compatibility modes.

Unprovision duplicate service instances in SharePoint 2013

Recently when I checked one of our SharePoint farms (3 server farm with one WFE server, one Application server and one database server), I noticed that service application instances are not provisioned as we planned.
For an example the “SharePoint Server Search” service instance was running on both WFE and Application servers which should be enabled only in the Application server.
So how can we stop that service instance in the WFE server ? can we do it from the central administration itself ?
Unfortunately we can’t. If we try that way we get the following error


Instead of using the central administration, we can use PowerShell. We need to get the correct guid of the service application instance.(in this case we need to unprovision the search service instance of WFE server) . As I explained in this post we can get the id of relevant service application instance

   1: Get-SPServiceInstance | where {$_.Status -eq "online" -and $_.TypeName -eq "SharePoint Server Search" } | Sort TypeName | Format-Table TypeName,Id,Server

I got two results for above query as below.


To unprovision the SharePoint server search instance from WFE server, I execute the following command

   1: $sh = Get-SPServiceInstance -Identity "7fbdf7a3-c471-4cd7-ba26-4432236b3bd7"

   2: $sh.Unprovision()

That will disable the Search service instance from WFE server.

Why do I get multiple results for each service instance in Get-SPServiceInstance?

Let’s assume that we have a multi-server SharePoint 2013 farm with one or more WFE servers and one or more Application servers.
If we need to do something with service application instances, we normally use the PowerShell  “Get-SPServiceInstance” command. For a certain task I needed to do some modifications to “Search Host Controller Service”. So I executed following command.

   1: $sh = Get-SPServiceInstance | ? {$_.TypeName -eq "Search Host Controller Service"}

To verify the result I got, I executed following command to get the id of service application instance.

   1: $sh.id

But surprisingly I got 2 ids.



Does that mean that I have 2 active Search Host Controller Service service instances running?. and what is the relevant Guid for my next commands?

To clarify doubts let’s think how service applications/service application instances are kept in SharePoint. When we install SharePoint in a server new service application instances are created. But they may not be in active state. We can easily see that from the services on this server section in central administration.



But how can I get other information like their guids. We can use PowerShell to easily get that info. We can start with a script like below.

   1: Get-SPServiceInstance | Sort TypeName | Format-Table TypeName,Id,Server

You can see following results



As you can see I have 2 copies of each service application instances. That is because I have 2 SharePoint servers in my farm. So how can I know which service application instance(s) are running at the moment. We need to modify our script a little bit.

   1: Get-SPServiceInstance | Sort TypeName | Format-Table TypeName,Id,Status,Server

Now we can see service instances with their status as below



As you can see not all service application instances are in Online state. In our next modification to the script we will filter all Online services

   1: Get-SPServiceInstance | where {$_.Status -eq "online" } | Sort TypeName | Format-Table TypeName,Id,Status,Server

The result will be as below



As I needed the guid of online “Search Host Controller Service” instance I can easily get from above or I can modify the where clause to input the TypeName to return only the specific service application instance.

Presentation–Getting to know SharePoint

Presentation at Microsoft Student Champs on Introduction to SharePoint

Getting to know SharePoint 2013 from Dinusha Kumarasiri

Timeline Feature in SharePoint 2013

In SharePoint 2013 we are given a great new feature, which is the ability to display tasks in a timeline. This is somewhat similar to what we have in MS Project Server. This feature is very helpful to track our tasks as they are visually organized with their staring and end dates. In this post I will discuss where and how we can use timelines in SharePoint.
We can have SharePoint timelines in 2 places.
1. Tasks List
When we create a new task list, an empty timeline is created by default.

Let’s add few tasks

Quite surprisingly, tasks are not displayed in the timeline. It took sometime to figure out that those tasks need to be added manually. I think it would’ve been better if it’s automatically added when we create a new task. Anyway this is what we have out of the box. In a next blog post I’ll explain a workaround to automatically add tasks to the timeline.
To add tasks to timeline, we need to either go to open menu (…) and click on “Add to Timeline” or go to ribbon and click on “Add to Timeline” button.
Once we add task(s) to timeline it will display as below

But that is not all. If you check carefully you would notice that there is a new “Timeline” tab in the ribbon. Using the options in that tab we can do various modifications to the presentation of timeline.

Let me give an effective scenario of using the timeline tab to enhance the experience. Let’s say that there is a large task and few other tasks scheduled in same time frame. Then it would be better if I just have labels for smaller tasks rather than displaying them as new bars. To do that select the task, go to the timeline tab and click on “Display as Callout”.
That looks more organized. Isn’t it.
2. Timeline WebPart
Tasks list is not the only place where we can use timeline feature. There is a separate timeline webpart. We can provide a tasks list which reside either in same site or a different sub site as the data source. Timeline webpart resides in the Content Rollup category.

After adding the webpart, we need fill required parameters to set the data source. The Type and Source dropdowns are populated according to the url provided. Since I’m having a few tasks lists in the given url, It populates the type as “List” and it gives me a list of Task Lists in source dropdown. I’ll select one tasks list from that.

This is what I’ll finally get after I complete all those configurations.

As you can see, I have the timeline tab in the ribbon here as well. So I can do various modifications to the presentation.
I believe that this will be a must have feature for a project site.

Perform eDiscovery exercise in SharePoint 2013

In a previous post we discussed what eDiscovery is and what is its place within SharePoint 2013. I will explain how to exercise an eDiscovery task using features provided by SharePoint. Before we begin, let’s break the features in to 4 components.

1. eDiscovery site Templates

If we take a scenario of an organization, which can have multiple litigation related cases, audit exercises, etc.. it can have a site collection created from the template “eDiscovery Center” to manage all. You need to keep in mind that the eDiscovery Center template is available for Enterprise license only. After you create a site collection based on eDiscovery Center template, you can centrally manage all your eDiscovery related cases.

To create individual cases, We have another template called “eDiscovery Case”. If we create a case using this template it will be created as a sub web.

Each case is equipped with sections called eDiscovery sets,Queries, Exports. Furthermore record managers and others in legal team (site users) can use normal collaboration features from document libraries, calendars, task lists etc..

2. In-Place hold (In-Place preservation)

As we discussed in earlier post in-place hold is a mechanism to preserve content for litigation. Using eDiscovery features in SharePoint 2013 we can preserve content in SharePoint itself, Exchange mailboxes and Lync content. Hold can be placed either at the site or mailbox level, or can use query-based preservation.

Once you create a eDiscovery case, you can create eDiscovery sets to discover (find) and hold specific content. To preserve content, first we need to click on new item in eDiscovery sets.

It allows us to add multiple sources (SharePoint 2013 sites or Exchange mail boxes)

After selecting the source, we can click on Enable In-Place Hold radio  button to preserve the content.

Lets assume you have thousands or millions of records in the site collection, It’ll be very difficult and expensive to process all of those content by the legal team. Gartner mentioned that, discovering right content accounts 35% of total litigation costs in USA. It sums up to billions. So to make our lives easier we can filter contents using queries.

We can filter content in 2 ways.

a) Apply filter from eDiscovery set

We can do that while we create the eDiscovery set or by editing an existing eDiscovery set. Let’s assume I have a large set of documents, and I need only content within a specific time frame and content that relate to “Research”. So I would apply a filter as below

 

b) Add queries to the content from Query and Export section/

Lets assume that I' have multiple data sources, so I create multiple eDiscovery sets to easily manage the eDiscovery process. Then I figure out the content is still too large for the litigation process.  eDiscovery query section comes very handy at that point as I can apply filters to a specific eDiscovery set, all or multople discovery sets.

3. eDiscovery Export

Once we discover the content by above means we need to download the content so we can produce them to legal team for review. To do that there is an export tool.

To export the content we need to go to search and export section and click on export button

We can either download content or download the content.

The export tool download documents and lists items as well. Furthermore it generates a manifest file with metadata which complies Electronic Discovery Reference Model (EDRM). This itself is a very important feature. Let’s assume the litigation team has a 3rd party tool which they use to proof read the discovered content and it can input EDRM compliant content. Then we can directly input the exported package to that system. So as you can see there can be various interactions with other systems.

4. eDiscovery API

We can use the eDiscovery API to extend default features using components of Microsoft,Office.Server.Discovery namespace.

Above is a brief intro on how to use eDiscovery features in SharePoint. You can find further info by referring following resources

• Good article from MVP blog
• MSDN