SharePoint Best Practices: Creating and Configuring Service Applications With (and Without) PowerShell – Part 1

This article is mainly devoted to the topic of how to create and configure one of the most intriguing service applications available in SharePoint 2010—the Managed Metadata service application. However, I consider it my duty to first provide a brief overview of the general service applications architecture, focusing particularly on its flexibility and scalability.

Service Applications Architecture Overview

One of the most significant enhancements you’ll find in the SharePoint 2010 platform has surely been the new services architecture. Unlike Microsoft Office SharePoint Server 2007 (MOSS 2007), where the main services were available only in the Standard and Enterprise levels of licensing, the new services architecture is available in the SharePoint 2010 Foundation level.

In MOSS 2007, you could meet a curious and mysterious thing named Shared Services Provider (SSP). It was the way SharePoint Server provided a pool of services to the web applications deployed in a farm. It was an interesting dressing that allowed some sort of distribution and centralization of these services. It was distributed because it was possible to configure as many instances of SSPs as needed to provide isolation to the served web applications. It was centralized because the administration and configuration of the four available services were delegated to a specific Administration Site (i.e., Shared Services Provider administration). The four supplied services were the Search Service, Excel Services, Business Data Catalog service, and Profile Service. The only limitation of this architecture was that you had to make all four services available when you wanted to use only one or two of them.

SharePoint 2010’s new services architecture is based on a single-service granularity level, allowing full flexibility and scalability of the farm in terms of topology and features availability. Each service is deployable and configurable by itself and can be instantiated one or more times to satisfy each specific requirement.
Figure 1 shows the service applications architecture in SharePoint 2010.

To better explain the fundamentals of this architecture, let me define some of the terms used in Figure 1:

• Service: Program bits deployed to some of the servers in the farm to provide various kinds of functionality.
• Service machine instance: An instance of the service bits running on an application server in the farm.
• Service application: A specific configuration of the service in the farm.
• Service application proxy: A reference point to a service application existing on the web front end of the farm.

Note that the service application proxy is also referred to as the service application connection. This double definition is probably due to the fact that the proxy acts effectively as a connector between an asking consumer (a Web part, a Web page, a PowerShell cmdlet, and so on) and the responding service application. Recapitulating, the action requested by the consumer is effectively performed by the service application by means of the brokerage of the corresponding service application proxy.

This architecture becomes progressively more efficient at scaling out a farm when more than one instance of a service application is deployed. SharePoint 2010 has a built-in load-balance mechanism that allows the consumer’s requests to continue to be served even when a redundant application server becomes unavailable (if and only if the requested service application has been redundant, too).
There is some additional information you should know about service applications:

• Out of the box, SharePoint 2010 provides a number of new service applications along with reengineered versions of the old applications.
• Many service applications are shareable between farms, so you can deploy a service application on one farm and use it from a second farm.
• Many service applications use one or more databases to store their specific data and metadata.
• Service application proxies are grouped in each web application. You can use the default proxy group, which enumerates all the proxies available in the farm, or you can define a custom proxy group that enumerates a specific pool of proxies. This way, each web application can be configured to use exactly the service applications it needs. Figure 2 shows some sample proxy groupings. You can see more examples in the TechNet article “Services architecture planning (SharePoint Server 2010)”.

Figure 2 clearly highlights two concepts:

1. A custom proxy group can include some of the proxies in a default group as well as proxies in a different application pool, which are referred to as “isolated” proxies.
2. Each service application (and the related proxy) can be instantiated more than one time. In this example, there are two different instances of Excel Calculation Services.

Another example of the flexibility of this architecture is shown in Figure 3, where the shareable service applications are deployed in a dedicated farm and consumed by web applications in other farms.

As previously mentioned, many but not all the service applications can be shared between farms (Cross-Farm) and not all of them use some database to store their data. Figure 4 illustrates whether the available service applications can be shared across applications and whether they need to store data. The service applications that incude the disk icon are those that need one or more databases.

A number of the service applications that need the support of a data layer use more than just one database. For example, the Search service application uses at least three databases, as I discussed in “SharePoint Installation Best Practices: More Control with PowerShell” in the December 2010 issue of The SolidQ Journal. Similarly, the User Profile service application is based on three databases. Planning the deployment of such service applications requires additional considerations about the location and the size of each database and about the way you set up the single service application (using the Central Administration site versus using a PowerShell script).

Understanding the Managed Metadata Service

If you’re searching for an official definition of the Managed Metadata service, you’ll nearly always find assertions like “…Managed Metadata services will provide enterprise management of metadata terms and content types for SharePoint 2010…”. Nice, but not sufficient. The Managed Metadata service allows the definition of a number of consolidated “terms” (namely, words and phrases) well organized into hierarchies to create an enterprise taxonomy. When a hierarchy refers to terms related to people and social tags, the name folksonomy is used instead of taxonomy.

The most important feature of the Managed Metadata service is that it allows the sharing of taxonomies and folksonomies across multiple SharePoint web sites and site collections. Moreover, this service application allows content types to be shared in the same way.

Another important feature is that it can consolidate and standardize a number of attribute definitions for the lists, the libraries and, above all, the content types of the web sites and site collections in farms. Notice the use of the plural “farms”—the Managed Metadata service is a cross-farm service, so one instance of this service application can be consumed by web applications in more than one farm. To better appreciate this novelty, consider the behavior of MOSS 2007, where you had to manually build the lookup drop-down lists for each attribute, with no way to reuse the lists.

Microsoft allows organizations to create one or more Managed Metadata services. In addition, a SharePoint web application can connect to multiple Managed Metadata services and the connection can be local or remote. For example, Figure 5 shows an organization that has created three Managed Metadata services: one global for the whole organization, one specific to the product development organization, and one specific to the legal department. Each department has its own SharePoint web site with multiple site collections. (For more information, see the TechNet article “Managed metadata service application overview (SharePoint Server 2010)”

The Managed Metadata service application stores its entities (terms) in a hierarchical store (a dedicated database) that includes the actual hierarchy of terms and a flat repository for a collection of keywords. To better understand the way these collections are managed, consider the following glossary:

• Managed term: A word or a phrase that can be associated to an item in SharePoint 2010. Managed terms can be organized into hierarchies to allow users an easy way to select them as a “managed metadata” column type.
• Term store: The database containing all the managed terms.
• Term set: A collection of related managed terms.
• Managed keyword: A word or phrase that has been added to a SharePoint2010 item. Managed keywords can’t be organized into hierarchies, and many content types include, by default, a managed keyword column, which is usually exploited to tag such an item.

The following sections examine how to create and configure the Managed Metadata service application. There are two ways to configure it: using the Central Administration site and using a PowerShell script. Before configuring it, though, the Managed Metadata service database should be created.

Creating the Managed Metadata Service DatabaseBefore creating and configuring the Managed Metadata service application, I recommend that you ask your DBA to create a database in the farm’s SQL Server instance. This database will be used to store the application’s metadata.
According to the TechNet article “Storage and SQL Server capacity planning and configuration (SharePoint Server 2010)”, “The Managed Metadata service application has one database. The size of the database is affected by the number of content types and keywords used in the system. Many environments will include multiple instances of the Managed Metadata service application.” Therefore, you have to autonomously decide how large to make the database and let the DBA decide the best location to put it. Figure 6 shows a sample Managed Metadata service database and the code that created it.

Because this database will be created outside of a SharePoint procedure, you need to make sure that at least two accounts will be included as database users (dbowners). As shown in Figure 7, these users will be the Farm account and the Managed Metadata service account (which will be used as the application pool identity for the service application).

Creating and Configuring the Managed Metadata Service Application in Central Administration

Once the database is created, you can start the creation and configuration process. As Figure 8 illustrates, go to the Central Administration site, choose Application Management, and select Manage Service Application in the Service Applications section.

This brings you to the page on which the current service applications are listed. Note that you could find one or more Managed Metadata service applications in this list because this service application can be configured on a number of different instances to better serve the isolation and customization requirements of web applications.

To create and configure the Managed Metadata Service, click the New icon on the Service Applications ribbon and select the Managed Metadata Service option, as Figure 9 shows.

In the form that pops up, you need to enter the information that SharePoint needs to create the service application. Figure 10 shows the pop-up form used to create the Managed Metadata service application for this example.

Here are several tips to help you fill out this form:

• You are free to name your service application whatever you want. You don’t have to worry about the name’s length, so a best practice is to use a self-explanatory name.
• The database name has to be the exact name of the database created earlier. Otherwise, the underlying process will create a new database using the default size and location of the SQL Server instance you indicated as the database server (namely, the size of the model database and the default location configured for the SQL Server instance itself).
• You can specify a failover database server if you need to mirror the database to meet availability requirements.
• You can create a new application pool or use an existing one. Either way, the application pool identity should be a managed account. The application pool is a process isolation element, but each application pool involves an overhead of the server resources.
• You can use the content type hub to configure a site collection as a content types repository so that the Managed Metadata service will use it to share the same content types in this farm (and eventually in other farms in the enterprise).
• If you want to associate the service application connection (aka proxy) with the default group, select the Add this service application to the farm’s default list check box.

Although Figure 10 doesn’t show it, there are two buttons at the bottom of the pop-up form: OK and Cancel. When you click the OK button, the service application is created in less than a minute. The service application seems ready to use, as shown in Figure 11.

However, to complete its configuration, you need to navigate to the Manage services on server page of the System Setting section of the Central Administration site (see Figure 12).

The last step of the configuration process is to start the service corresponding to the service application, which is the Managed Metadata Web Service, as you can see in Figure 13.

By selecting your service application and clicking the Manage icon on the ribbon you can start the Term Store Management Tool shown in Figure 14. You’re now ready to build your term hierarchies and create your taxonomy, but that’s another story.

Creating and Configuring the Managed Metadata Service Application with PowerShell

As I previously mentioned, you can create and configure the Managed Metadata service application using a PowerShell script. The starting point is the same: Your DBA has just created the needed database (see the “Creating the Managed Metadata Service Database” section). You’re now ready to load and execute the script shown in Listing 1. This script is mainly derived from an interesting blog post by Patrick Lamber at http://patricklamber.blogspot.com/2010/12/how-do-i-create-new-managed-metadata.html.

The first part of the script (between the comments “Begin PART 1” and “End PART 1”) sets some variables needed in the succeeding parts.

In the second part of the script (between the comments “Begin PART 2” and “End PART 2”), at least one instance of the Managed Metadata Web Service is provisioned if no running instances are found. Note that in the “Configuring the Managed Metadata Service Application in Central Administration” section, this step was executed at the end of the service application creation process. So, as these two implementations demonstrate, you can choose when to start the Managed Metadata Web Service. The only important thing is that it be running when you configure the term store.

In the third part of the script (between the comments “Begin PART 3” and “End PART 3”), the application pool and the related identity are defined. in the example we choose to create a specific Application Pool for this service, but the script lets the way open for the cases in which we intend to use an existing Application Pool: the starting point is indeed “…Verify if some-application-pool exists…”.

The fourth part of the script (between the comments “Begin PART 4” and “End PART 4”) creates and initially configures the Managed Metadata service application. Notice that the New-SPMetadataServiceApplication cmdlet includes references to the pre-created database and the hosting SQL Server instance.

The PowerShell cmdlet that creates the service application doesn’t implicitly create the related connection (aka proxy), so the fifth and final part of the script (between the comments “Begin PART 5” and “End PART 5”) creates it. (When you use the Central Administration site to create a new service application, the proxy is generated automatically.) The New-SPMetadataServiceApplicationProxy cmdlet used in the script doesn’t include any reference to the default or custom proxy group. This means that the proxy is created but the corresponding connection isn’t associated with the web application.

If you navigate to the Manage Service Applications page of the Central Administration site after the script finishes executing, you’ll see your Managed Metadata service application and its related proxy, as shown in Figure 15:

But if you try to manage the service application by selecting it and clicking the Manage icon in the ribbon or by double clicking its name, the site returns an error message like the one you see in Figure 16.

This “error” can be ascribed to human oversight (forgot to include the [-DefaultProxyGroup] cmdlet parameter), but it can also be intended, which is the case in this example. This instance of the Managed Metadata service application needs to be used by one or more web applications, where it will be included in the custom proxy group.

You can provide the missing association with a simple operation: Navigate to the Application Management page of the Central Administration site. In the Service Applications section, select the Configure service application associations option, as Figure 17 shows.

Then, in the Service Application Associations page, select the default application proxy group. You can see it together with the currently associated service applications in Figure 18.

When you click default, the Configure Service Application Associations pop-up form appears. In the list of available service application connections, select the Managed Metadata Proxy check box and click the OK button. The pop-up form closes, and you’ll be back to the Service Applications management page. This time, if you try to manage the Managed Metadata service application, the Term Store Management Tool starts, as Figure 19 shows. You’re once again ready to define your taxonomy, but as I previously mentioned, that’s another story.

Conclusion

As you’ve seen in this article, creating and configuring a Managed Metadata service application is a relatively simple task, and you can decide between the two available ways to do it. In my next article, I’ll show you how to create and configure the User Profile service application.