Change application pool of an existing service application

This is the 4^th 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

As I mentioned in a previous post, If we create a new service application an application in IIS is also created. That allows us to isolate service applications by providing different application pools. In this article I will show how to assign a new application pool to an existing service application.

Can we manually create an application pool with a proper identity in IIS and assign it to the service application ? It is the wrong way of assigning the application pool

The wrong way

To demonstrate above fact I created a new Managed Metadata Service application and associated it with an existing application pool named MMS2 using central administration.

Then I’ll go to IIS Manager and create a new application pool manually and associate it with our service application as below

Although IIS allows us to associate application with new application pool, SharePoint does not know the change. To show that we will use following PowerShell commands.

1. $app = Get-SPMetadataServiceApplication -Identity 796cb0d5-b8cf-4e0c-a03b-1d8cc285efe3
2. $app.ApplicationPool

Following is the result I got

To stress the point further, I will stop the “Managed Metadata Web Service” in services on this server section. Then all Managed Metadata Service related applications in IIS will be deleted. Once I start the service again those applications will be recreated in IIS. As you can see the application pool of the service application is reverted back to MMS12 (with it’s Guid) and no longer “MMS2AppPool”

The correct way

The first thing to not is that, service applications need to be associated with an instance of SPServiceApplicationPool. Following is the way to do that.

1. #Create new application pool
2. $managedAccount = Get-SPManagedAccount -Identity "dev\spserviceapp"
3. $servicePppPool = New-SPServiceApplicationPool -Name MetadataApplicationPool -Account $managedAccount
4.  
5. #Assign application pool to service application
6. $app = Get-SPMetadataServiceApplication -Identity 796cb0d5-b8cf-4e0c-a03b-1d8cc285efe3
7. $app.ApplicationPool = $servicePppPool
8. $app.Update()

Following is the result I got

Now it doesn’t matter if I stop and start the service instance, the application pool remains the same.

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