How to plan Service Applications in SharePoint 2013

This is the 3^rd post of the article series regarding service applications

• Part 1 : Service application architecture – Basic Concepts
• Part 2 : How logical components of service applications map to physical components
• Part 3 : How to plan Service Applications in SharePoint 2013
• Part 4 : Change application pool of an existing service application

When we setup a new SharePoint environment, we should plan service applications properly. There are certain factors and best practices to consider before we configure any service application. In this article I will provide few points which will be important to consider when we do service application provisioning.

1. What are the service applications I need?

If we use configuration wizard to setup the SharePoint farm, it’ll setup all selected service applications with default settings. By default all service applications except “Lotus Notes Connector” are selected.

Although this will setup almost all service applications, we may not need most of them. On the other hand we may need to specify different settings when configuring (e.g.: different managed accounts).

To overcome above limitations, the best practice is to use a scripted installation which will setup and configure service applications those are required.

Let’s assume that we need only Search, Managed metadata and User profile service applications for an environment. In that scenario we may not configure other service applications like Excel services, Access services, PerformancePoint services, etc..

By provisioning only relevant service applications, we can reserve resources like processing power, memory etc.. as well as we can focus on maintenance and administrative activities of those applications only

2. What is the service application topology which suits the business requirement?

There are two main types of topologies to consider

1. Single farm service application topologies
   • Single farm with single application proxy group

   This is the most basic topology where all web applications use the same service applications 

   • Single farm with multiple application proxy groups

   In this topology we do have unique service application requirement for certain web applications (e.g.: departments). In that case we will create new proxy groups probably with new service applications

   • Single farm with multiple application proxy groups and multiple application pools

   In this topology we are focusing on isolating certain service applications from others. As we mentioned in an earlier post that when we create a new service application, an application in IIS also created. So we can specify different application pools with probably different identities as execution accounts,

2. Cross farm service application topologies
   • We can share following service applications across farms
     • Business data connectivity
     • Managed metadata
     • User profile
     • Search
     • Machine translation
     • Secure store

3. What are the resources I need?

When provision a service application we need to allocate resources for that application in forms of processing power, memory, disk space as well as separate servers. There are some resource-intensive service applications like Search service, Excel services, Visio services, etc..

Some service applications require databases to store its data. For an example user profile service require 3 databases to store it’s content. Namely Profile, Social and Sync databases. Apart from that, creation of My Sites will also create content databases. This will definitely increase the storage requirement. Following are the types and storage requirement for service application databases

On the other hand Search service require storage space to physically store it’s index files. This can be very large depending on the searchable content. Roughly it’s between 5% to 20% of the searchable content that is being crawled. If the percentage of text is larger on those searchable content, the index space will also be increased.

It’s generally a best practice to utilize separate servers to resource-intensive applications like Search index. This is because Search service constantly crawl the content which require high amount of memory and processing power.

4. Do we need to consider high availability?

If we have multiple servers in the farm, we can start multiple instances of same service application on those servers. We don’t need to worry about load balancing as it’s handled by SharePoint itself.

In order to implement high availability on Search service, we need to modify the search topology to include search index replica and partitions. We need to increase partitions and replicas based on items that are being indexed by the search service.

How logical components of service applications map to physical components

This is the 2^nd article of a series of articles regarding service applications. If you missed the first post you can visit it before proceeding with this.

• Part 1 : Service application architecture – Basic Concepts
• Part 2 : How logical components of service applications map to physical components
• Part 3 : How to plan Service Applications in SharePoint 2013
• Part 4 : Change application pool of an existing service application

It’ll be very helpful to know how each logical component of a service application (e.g: service application, service application instance etc..) are mapped to physical entities in the farm. In this article I’ll explain the relationship which will help you to understand the service application architecture properly

I’ll take Managed Metadata Service application to explain the relationship with physical components in the farm

1. Service application instance

When we setup SharePoint in a server, certain libraries and some resources are copied to the ISAPI folder in 15 hive (C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI). Microsoft.SharePoint.Taxonomy.dll is also available in the same path which contains the application logic related to Managed Metadata Service.

Furthermore MetadataWebService.svc file which is used to host the service logic is located in WebServices folder in 15 hive (C:\Program Files\Microsoft Office Servers\15.0\WebServices).

Since we need to host the MetadataWebService.svc in IIS we need to start “Managed Metadata Web Service” from the services on this server section. If the service is started, we can say the Managed Metadata service application instance is running on that server.

2. Service application

If the service application instance is started in the server, when we create a service application from “Manage Service Application” section a new application will be created in IIS.

If we create multiple service applications, there will be multiple applications exist in IIS.

Lets assume that we’ve created two Managed Metadata service applications, then we can expect 2 applications in IIS which hosts the same MetadataWebService.svc service.

Following are the service applications I have

Following are the respective service applications created in IIS

3. Service application connection and proxy group

They are logical components but entries are kept in the database

Fix : Pagination not working properly in XsltListViewWebPart with custom view

Let’s assume that we need to create a XsltListViewWebPart programmatically with a custom view.We can use a feature receiver to do that. Following is a sample code to add the web part to the page

1. var web = properties.Feature.Parent as SPWeb;
2. web.AllowUnsafeUpdates = true;
3. //Get the list
4. var sharedDocuments = web.Lists.TryGetList("Shared Documents");
5. //create a custom view to limit rows
6. var viewCollection = sharedDocuments.Views;
7. const string viewName = "HomeWebPartView";
8. var homeWpView =
9.     viewCollection.Cast<SPView>().FirstOrDefault(c => c.Title.Equals(viewName));
10. if (homeWpView == null)
11. {
12.     var viewFields = new StringCollection
13.                         { "Type", "LinkFilename", "Modified", "Editor" };
14.     homeWpView =
15.         viewCollection.Add(viewName, viewFields, string.Empty, 5, true, false);
16.     sharedDocuments.Update();
17. }
18. //create the webpart
19. var sharedDocsWebPart = new XsltListViewWebPart
20.                           {
21.                              ListId = sharedDocuments.ID,
22.                              ViewGuid = homeWpView.ID.ToString("B").ToUpper(),
23.                              Title = "Shared Documents",
24.                              ChromeType = PartChromeType.TitleOnly,
25.                              ID = Guid.NewGuid().ToString()
26.                           };
27. //add webpart to page
28. var homePage = web.GetFile("SitePages/Home.aspx");
29. using (var webPartManager = homePage.GetLimitedWebPartManager(PersonalizationScope.Shared))
30. {
31.     webPartManager.AddWebPart(sharedDocsWebPart, "Left", 0);
32.     homePage.Update();
33. }
34. web.Update();

But the added web part showed an unexpected behavior. for an example, the pagination does not work for other pages other than the first page. As you can see from the below image, pagination is missing from the second page.

To fix the issue we need to modify the code like below. The change I’ve done is to remove all view fields and add them again.

1. var web = properties.Feature.Parent as SPWeb;
2. web.AllowUnsafeUpdates = true;
3. //Get the list
4. var sharedDocuments = web.Lists.TryGetList("Shared Documents");
5. //create a custom view to limit rows
6. var viewCollection = sharedDocuments.Views;
7. const string viewName = "HomeWebPartView";
8. var homeWpView =
9.     viewCollection.Cast<SPView>().FirstOrDefault(c => c.Title.Equals(viewName));
10. if (homeWpView == null)
11. {
12.     var viewFields = new StringCollection
13.                         { "Type", "LinkFilename", "Modified", "Editor" };
14.     homeWpView =
15.         viewCollection.Add(viewName, viewFields, string.Empty, 5, true, false);
16.     sharedDocuments.Update();
17. }
18. //create the webpart
19. var sharedDocsWebPart = new XsltListViewWebPart
20.                           {
21.                              ListId = sharedDocuments.ID,
22.                              ViewGuid = homeWpView.ID.ToString("B").ToUpper(),
23.                              Title = "Shared Documents",
24.                              ChromeType = PartChromeType.TitleOnly,
25.                              ID = Guid.NewGuid().ToString()
26.                           };
27. //add webpart to page
28. var homePage = web.GetFile("SitePages/Home.aspx");
29. using (var webPartManager = homePage.GetLimitedWebPartManager(PersonalizationScope.Shared))
30. {
31.     webPartManager.AddWebPart(sharedDocsWebPart, "Left", 0);
32.     homePage.Update();
33.  
34.     //get the webpart again from the webpart manager
35.     var sharedDocsWp =
36.         webPartManager.WebParts.Cast<WebPart>().FirstOrDefault
37.         (wp => wp.Title.Equals("Shared Documents"))
38.         as XsltListViewWebPart;
39.     //modify the current view
40.     homeWpView.ViewFields.DeleteAll();
41.     homeWpView.ViewFields.Add("Type");
42.     homeWpView.ViewFields.Add("LinkFilename");
43.     homeWpView.ViewFields.Add("Modified");
44.     homeWpView.ViewFields.Add("Editor");
45.     homeWpView.Update();
46.  
47.     webPartManager.SaveChanges(sharedDocsWp);
48.     homePage.Update();
49. }
50. web.Update();

After deploying the code, pagination of the web part work as expected.

Resolving error “Sorry, something went wrong An update conflict has occurred, and you must re-try this action” in SharePoint 2013

Recently I came across the following error message when trying to modify diagnostic logging categories in central administration.

This has occurred because of the file system cache (config cache) in SharePoint server is corrupted (having newer version than the source, which is the configuration database).

What is the file system cache (config cache)?

Config cache is where the objects from config db like timer job descriptions, features etc,, are cached locally so SharePoint does not need to query the configuration db every time. The cache is updated by a timer job.

The cache is located in “%SystemDrive%\ProgramData\Microsoft\SharePoint\Config\<GUID>” folder. You can see a set of xml files for purposes like

• Timer job descriptions to be executed by the local SharePoint server using the timer service.
• Descriptions on farm features.

How to resolve the error

To resolve error we need to clear and build the config cache manually. follow the steps given below to do that.

1. Stop the SharePoint Tmer service in every server that runs SharePoint in the farm
2. Go to the cache location and take a backup of the folder (folder with the Guuid)
3. Delete all xml files inside the folder and do not delete the cache.ini (This is a hidden file. So you may need to edit folder options to see the file)
4. Open the cache.ini file . remove existing value and enter the value 1 
5. Save cache.ini file
6. Do this process for all servers running SharePoint.
7. Start timer service in all servers running SharePoint.

If the cache clearing task is successful, new set of xml files should be generated automatically and the value of the cache.ini file should be modified (no longer 1)

That’s all. Now your cache should be consistent with the configuration db

Service application architecture – Basic concepts

This is the beginning of a series of articles on service applications in SharePoint.

• Part 1 : Service application architecture – Basic Concepts
• Part 2 : How logical components of service applications map to physical components
• Part 3 : How to plan Service Applications in SharePoint 2013
• Part 4 : Change application pool of an existing service application

In this post I will cover some basic concepts about service applications. Although some topics like history and differences between old SSP model and service application model are omitted as there are enough resources available.

Following are the important keywords we should know

• Service application instance : Actual instance of the service (binaries) running on the server
• Service application : Logical component that contains the service configuration and management (e.g.: service application configuration info)
• Service application connection : Interface used by the service consumers for communicating with the service and the load balancer
• Service application proxy group : Group of service application connections associated with web applications

In this post I will present some scenarios where we can use above concepts differently.

1. One service application instance, one service application, one service application connection, one service application proxy group and one or more web applications

2. Multiple service applications with one service application instance and one service application connection for each, one service application proxy group and one or more web applications

3. Multiple service applications with one service application instance a for each, multiple service application proxy group and one or more web applications

4. Service applications with multiple service application instances

Fix Content Type Publishing : The compatibility level 14 of the content type hub site is different from the compatibility level of this site 15.

After we migrate from SharePoint 2010 environment to a SharePoint 2013 environment, we need to follow few post upgrade steps.

Let’s assume we had a content type hub site collection where other sites subscribe to consume content types. You can learn more on Content Types and Content Type publishing through a content type hub by referring this article

After we migrate, our content type hub site collection is still in the 14 compatibility mode (SharePoint 2010 mode). Since it in the old compatibility level, newly created site collections (SharePoint 2013 mode) can’t subscribe to the content type hub.

To fix the issue we need to either create a new Content Type Hub site collection or upgrade the existing site collection. Following are the steps required to upgrade/create content type hub site collection

1. Upgrade the content type hub site collection

You can either do it manually or by PowerShell statements

1. Upgrade-SPSite "http://sp13/sites/hub" -VersionUpgrade -QueueOnly

2. Check/ Change the content type hub Url.

This step is not mandatory. But let’s assume we need to keep the existing content type hub site collection in 14 mode, and need to create a new site collection for the new environment. In that case we will skip the 1st step.

• Create new site collection
• Create content types as available in the old content type hub site collection
• Enable the “Content Type Syndication Hub” site collection feature
• Use following PowerShell statement to make the new site collection as the

1. $newContentHub = "http://sp13/sites/hub15"
2. $mms = Get-SPServiceApplication -Name "Managed Metadata Service"
3. Set-SPMetadataServiceApplication -Identity $mms -HubURI $newContentHub

3. Publish/ Republish Content Type Hub.

Since we changed the content type hub site collection, we need to publish or republish content types those need to be published to other sites.

4. Run required timer jobs

We need to run two timer jobs to make the changes reflect in subscribed sites. In central administration go to Monitoring > Review Job Definitions to select timer jobs.

• Select the timer job “Content Type Hub” and click Run Now
• Select the timer job “Content Type Subscriber” for the web application and cluck Run Now. If you have multiple web applications those are subscribed to content type hub, you have to run the Content Type Subscriber jobs for all of them

Reusing SharePoint custom service application proxy groups

When we create a new web application, we need to associate it with a service application proxy group. Either we can associate it with default proxy group or a custom group

Let’s say we need to create 2 web applications those require only Managed Metadata Service as a service application. In that case we need to go for a custom proxy group.
If we create those web applications using custom proxy group we can see 2 separate “Custom” proxy groups created.
Although they contain same service application proxies, We can’t reuse the groups by default. In that case if we need to associate a new service application proxy, we need to add it to each and every “Custom” group.

Is there any way to create named proxy groups where we can reuse for our web applications ?
We can use PowerShell cmdlets to create named proxy groups and add member service application proxies. Let’s say we create a proxy group named “Contoso” and we need only “Managed Metadata Service” for that group. Then we’ll need to provide following PowerShell commands.

New-SPServiceApplicationProxyGroup "Contoso"

$mmsproxy = Get-SPServiceApplicationProxy | where { $_.Name -eq “Managed Metadata Service” }
Add-SPServiceApplicationProxyGroupMember "Contoso" -Member $mmsproxy

Then we can see our group listed when we create a new web application (or changing the Service Application Association setting)

We can associate our existing sites using the Service Application Association section.


Now it looks very organized. If we need to associate new proxies we can add/remove them from our named proxy group which will be reflected for all associated web applications.