How is the managed metadata term store organized?

In the last two posts of the post series “SharePoint 2010: exploring the managed metadata service application” we saw how to setup a managed metadata service application and how to assign one or more managed metadata service applications to our web applications. In this post we are going to see how the managed metadata term store is organized and which roles can be used for managing this store. We are going to use a sample taxonomy for this purpose. The steps for creating this sample taxonomy are described in the post that will follow in this post series.

Overview

Users working in an organization tend to use different synonyms for the same organizational term. It may happen that the terms used are misspelled or even wrong. These facts make the usage of a standardized term set in the organization difficult. Take as an example the name of a department “Information & Technology” that can be described by the users in several ways: IT, I&T, Information and Technology. And, we are not counting all the different combinations for a misspelled term.

The basic idea of the managed metadata term store is to mitigate this problem by standardizing these terms in a centralized location. These terms can be used by the users when associating it with other items in the system (tagging). In this post we are taking as a simple example of the definition of an organization’s department names and structure.

The next section is going to explain better the structure and elements used in this sample and the roles that can be assigned to the different elements to manage this structure.

structure and roles of the taxonomy term store

This section illustrates the basic elements and roles in a taxonomy term store. The management of this taxonomy term store is accomplished by using the taxonomy store management tool that can either be found in the central administration (when clicking on the managed metadata service application in the central admin) or in the site collection (under site settings) that consumes the managed metadata service application. The term store management tool for our example is shown in the next figure:

The term store management tool is subdivided into two different sections:

• term store navigation (left hand side): this navigation pane is used to navigate through the different elements in our term store. At the same time, we have the ability to modify the structure and contribute with new content (if you have the right permissions).
• properties (right hand side): this is the property section of the element currently chosen in the navigation pane. In this section you are able to make the changes to your element depending to your needs

The term store uses different types of elements to structure the taxonomy. With the help of the example of the first figure we are going to see the different types of elements used in such a term store:

• taxonomy term store (e.g., Demo Managed Metadata): this is the name of our term store and container of none or more groups containing term sets. In this section you are able to define the administrators of the term store and the languages that are going to be used in this store.
• groups (e.g., Organization): the groups in the term store are used to group none or more term sets and define the overall security for those term sets by defining the managers and the contributors for them.
• term set (e.g., Departments): a term set is used to have terms that can be nested in a hierarchical manner. This term set is used to define a contact e-mail address for suggestions, the stakeholders, and the submission policy.
• term (e.g., Information & Technology): terms are the hearth of this system containing our information that we are going to provide. You can group these terms in a hierarchical manner if you want (you see the sub-departments of the IT department for example). In addition, you can specify synonyms for the terms that are going to be used.

The management of the term store can be configured in several ways. You are able to delegate certain actions and permissions to other users by using roles. The roles that can be used to control the access on the term store are:

• term store administrator: the term store administrator can make structural changes to the whole term store and manage the permissions. The term store administrator can assign the term store administrator role to other people under the taxonomy term store element’s properties (e.g., Demo Managed Metadata). The farm administrator can define one or many term store administrators. 
• group managers: group managers can manage terms and term sets under a specific group (e.g, Organization). They can also specify users with contribute rights under the group element’s properties
• contributors: contributors can manage terms and term sets under a specific group but are not able to assign contributor rights to other users.

The term set has two additional fields that can be assigned to people or groups of the organization. These fields, however, are only for documentation purposes and are not used to grant any permissions to other users:

• term set owner: this is the owner of the term set (e.g., Department)
• stakeholders: stakeholders are people that are going to be notified if major changes in a term set (e.g., Departments) should take place. These stakeholders do not have contribute rights on the term set.

Summary

In this blog post we explored the different types of elements used in a term store to organize a taxonomy. In addition, we saw the roles that can be assigned to users for delegating permissions for the store management. With this knowledge we are able to start now creating our term store in the next blog post of this post series.

 

So stay tuned,

Patrick

Setting up a managed metadata service application to server one or more web applications

The service application infrastructure of SharePoint 2010 gives you the ability to create multiple service applications of the same type. At the same time, you are also able to connect most of these service applications to one or more web applications in your farm or even with external farms. This brings you more flexibility with respect to the old shared service provider architecture of SharePoint 2007, however, this also brings more complexity to your overall system architecture.

In this post of the post series “SharePoint 2010: exploring the managed metadata service application” we are going to see how to assign the managed metadata service application to serve one or more web applications contemporarily. In the second part of this post we are going to see what you have to consider when assigning two different managed metadata service applications to the same web application. If you want to know how to create a single managed metadata service application with the central admin or PowerShell, then visit my last post.

Scenario 1: assigning the same managed metadata service application to one or more web applications

The managed metadata service application is typically assigned via a service application proxy and a service application proxy group. Each application proxy group can then be assigned to multiple web applications depending on your needs. You can assign a service application proxy to a web application in different moments of the web application life cycle:

First, an administrator has the ability to define a service application connection during the creation of a new web application. In the configuration wizard of the web application creation you have a section that gives you the possibility to define which proxy group to use for your web application. If you want, you are also able to specify a custom selection of service applications. The next figure shows how this might look like by choosing an already existing proxy group:

The next figure shows what you can do when you are defining a custom binding for this web application with the service applications present in the farm:

On the other side, you can also change the proxy group settings after a web application was already created. You can change these settings by using the central administration:

• Open the central administration
• Application Management –> Configure service application associations
• select the web application that you want to configure (a window pops up similar to the next figure)
• make your changes

Scenario 2: assigning two or more managed metadata service applications to a single web application

In the previous scenario we saw how to assign a service application to multiple web applications. Similarly, you are also able to assign multiple service applications to a single web application. When doing so with a managed metadata service application, however, you have to consider some settings before proceeding.

Imagine that you have to maintain two separate managed metadata service applications for two different departmental projects. You can do this by creating two separate managed metadata service applications and assign them to the corresponding web applications. After a while, you need to combine both service applications for a single web application. You can do this by following the same steps as seen in the previous scenario. Choose the service applications that you want to consume in your web application by selecting a proxy group or defining your custom selections.

You can do this, however, you have to consider following when assigning multiple managed metadata service applications to a single web application:

1. both term stores (service applications) with managed terms are available for your web application
2. both term stores can provide content-type hub syndication
3. the already stored enterprise keywords of both term stores are served to your web application, however, only one term store of both can be your default storage location for your keywords
4. the already stored column specific term sets of both term stores are served to your web application, however, only one term store of both can be your default storage location of your column specific term sets

Everything except the storage of enterprise keywords and column specific term sets function properly. This happens if both managed metadata service applications are configured to be the default term stores. You might encounter following error message when inserting a new enterprise keyword:

“The site does not contain a default keywords termstore”

Therefore, plan carefully before separating managed metadata service applications. You have to ensure that only one of both term stores is the default term store for the web application. You can make the changes in the managed metadata service connection settings:

• open the central administration
• Application management –> Manage service applications
• select the row of type Managed Metadata service Connection of your metadata service application
• press Properties in the ribbon bar
• choose This service application is the default storage location for Keywords and This service application is the default storage location for column specific term sets

If you already have a default term store in the farm you will get this error message:

“Warning: Another service application on this farm is already configured as the default. This feature will be disabled if multiple defaults are associated with  a single web application.”

Now, it is up to you to ensure that you do not use two default term stores on the same web application. Please note that disabling these settings is a farm wide setting.

Summary

With the service application infrastructure of SharePoint 2010 you are able to manage multiple service applications on your farm and assign them to one or more web applications without any problems. This post showed you how to configure one single service application to serve multiple web applications and how to configure multiple managed metadata service applications to a single web application.

 

Hope this helps,

Patrick

How do I create a new managed metadata service application?

Hi,

in this blog post of my “SharePoint 2010: exploring the managed metadata service application” post series we are going to see how a new managed metadata service application is created manually and programmatically with PowerShell.

Overview

A SharePoint farm that has managed metadata available can organize the managed metadata in several managed metadata service applications. Each managed metadata service application can serve with a proxy connection none or multiple web applications. This gives you the possibility to manage your metadata in a flexible way.

Each managed metadata service application has an service application pool assigned to it and usually also a managed account as application pool identity (check this blog post if you don’t know what managed accounts are). Last but not least, the “Managed Metadata Web Service” must run on at least one front-end to ensure that the managed metadata service is working properly.

In this post we are going to see how to create such a managed metadata service application. The content is organized as follows:

• Part 1: Creating a managed metadata service application with the central admin
• Part 2: Creating a managed metadata service application with PowerShell

 

Part 1: Creating a managed metadata service application with the central admin

Creating a managed metadata service application with the central admin is simple. Before starting we have to ensure that we have a managed account registered that we will use as a service application pool identity for our managed metadata service application (check this blog post if you don’t know what managed accounts are). In addition, we have to start the “Managed Metadata Web Service” service on at least one front-end server of our farm. You can do this by following these steps:

• open the central admin
• go to “Application Management” –> “Manage services on server”
• start the “Managed Metadata Web Service” on any front-end server of your farm

Now, that all requirements are met, we can start creating our managed metadata service application. Follow these steps:

• open the central admin
• go to “Application Management” –> “Manage Service Applications”
• press the “New” button on the ribbon and choose “Managed Metadata Service”

• a new window will popup configure it to your needs (see next pictures) and then press “OK”:
• Name: define the name for your managed metadata. This name will be shown on the “Manage Service Applications” overview page
• Database Server: specify the database server to store your managed metadata service database
• Application Pool: define a new application pool that will be used as service application pool identity for your managed metadata service application. Also define the managed account that you will use as application pool identity for this application pool
• Content Type hub: you can specify here the URL of the content type hub of your managed metadata service application. We will see this functionality later on in our post series. Just leave it empty for now.

• you should see something like in the next picture in the “Manage Service Applications” overview

With these small steps you created a managed metadata service application and the proxy. If you click on the name of the newly created service application, you are automatically redirected to the term store tool needed to manage your metadata in this store.

Please note that you are able to create multiple managed metadata service applications like that. On most cases these steps are enough to create a new managed metadata service application. However, we will see in the next part how to create the same stuff in a more automated way. Let us jump directly into the PowerShell script.

Part 2: Creating a managed metadata service application with PowerShell

The creation of the managed metadata service application with PowerShell is pretty straightforward. Now, we should know the different prerequisites needed to create the new service application. Because of that, it should not be difficult to understand the steps that are scripted in the PowerShell script that I prepared for you. Before we are going to see the whole script, I would like to summarize the steps that are execute in it:

• check if there is an service application pool with a specified name. If not, then create a new service application pool and assign the required managed account to it
• check if there is a managed metadata service application with a specified name. If not, then create it and assign it to the previously selected service application pool.
• check if there is a managed metadata service application proxy with a specified name. if not, then create it and assign it to the previously selected managed metadata service application.

You can execute this script more than once without breaking the previously created entities. The script always looks before if the item that we are going to create was already created. It uses the object if it finds something already defined. The complete script is shown in the next code snippet. The paragraphs after explain the different parts more in detail.

# start script configuration section

# service application and service application proxy names
$metadataServiceApplicationName = "Demo Managed Metadata"
$metadataServiceApplicationNameProxy = "Demo Managed Metadata Proxy"

# service application pool identity for the service application
$serviceApplicationPoolManagedAccountName = "LAMBER\spman_app"
# service application pool name
$metadataApplicationPoolName = "managed_demo_appl"

# end script configuration section

$snapinName = "Microsoft.SharePoint.PowerShell"
if ((Get-PSSnapin | Where-Object {$_.Name -eq $snapinName }) -eq $NULL) {
  write-host "SharePoint SnapIn not loaded. Loading..."
  Add-PSSnapin $snapinName
}

write-host "Starting managed application creation..."
write-host

write-host "Verifying running instances..."
$metadataServiceInstanceName = "Managed Metadata Web Service"
$onlineServiceInstances = Get-SPServiceInstance | where {$_.TypeName -eq $metadataServiceInstanceName -and $_.Status -eq "Online"}
if ($onlineServiceInstances -eq $NULL) {
  write-host "No running instances found. Starting all service instances now..."
  $disabledServiceInstances = Get-SPServiceInstance | where {$_.TypeName -eq $metadataServiceInstanceName -and $_.Status -eq "Disabled" }
  $disabledServiceInstances | Start-SPServiceInstance
  
  while (-not ($disabledServiceInstances -eq $NULL)) {
    write-host "Waiting that all service instances are provisioned. Going to sleep for 10 seconds..."
    sleep 10;
    $disabledServiceInstances = Get-SPServiceInstance | where {$_.TypeName -eq $metadataServiceInstanceName -and $_.Status -eq "Disabled" }
  }
  write-host "All service instances provisioned successfully."
}
else {
  write-host "At least one instance is running in the farm."
}
write-host

write-host "Verifying if '$metadataApplicationPoolName' service application pool exists..."
$serviceApplicationPool = Get-SPServiceApplicationPool $metadataApplicationPoolName -ea SilentlyContinue
if ($serviceApplicationPool -eq $NULL) {
  write-host "No service application pool found. Starting the creation process..."
  
  write-host "Verifying if '$serviceApplicationPoolManagedAccountName' is registered as managed account..."
  $managedAccountEntry = Get-SPManagedAccount $serviceApplicationPoolManagedAccountName -ea SilentlyContinue
  if ($managedAccountEntry -eq $NULL) {
    write-host "No managed account found. Starting the registering process..."
    $manCredentials = Get-Credential $serviceApplicationPoolManagedAccountName  
    $managedAccountEntry = New-SPManagedAccount $manCredentials
  }
  else {
    write-host "Account already registered."
  }
  
  $serviceApplicationPool = New-SPServiceApplicationPool $metadataApplicationPoolName -Account $managedAccountEntry
}
else {
  write-host "Service application pool already exists."
}
write-host

$ServiceApplication = Get-SPMetadataServiceApplication $metadataServiceApplicationName
write-host "Verifying if '$metadataServiceApplicationName' already exists..."
if ($ServiceApplication -eq $NULL) {
  write-host "No service application found. Starting the creation process..."
  $ServiceApplication = New-SPMetadataServiceApplication -Name $metadataServiceApplicationName -ApplicationPool $serviceApplicationPool
  write-host "Service application created successfully."
}
else {
  write-host "Service application already exists."
}
write-host

$ServiceApplicationProxy = Get-SPMetadataServiceApplicationProxy $metadataServiceApplicationNameProxy
write-host "Verifying if '$metadataServiceApplicationNameProxy' service application proxy already exists..."
if ($ServiceApplicationProxy -eq $NULL) {
  write-host "No service application proxy found. Starting the creation process..."
  $ServiceApplicationProxy = New-SPMetadataServiceApplicationProxy -Name $metadataServiceApplicationNameProxy -ServiceApplication $ServiceApplication
  write-host "Service application proxy created successfully."
}
else {
  write-host "Service application proxy already exists"
}
write-host

write-host "Managed application creation finished."

 

Now, let us analyze the different parts of this script and explain those better. The next code snippet shows the first part of the script. This part is self-explanatory and is used to configure the creation of the managed metadata service application. Change these values to your needs before starting the script.

# start script configuration section

# service application and service application proxy names
$metadataServiceApplicationName = "Demo Managed Metadata"
$metadataServiceApplicationNameProxy = "Demo Managed Metadata Proxy"

# service application pool identity for the service application
$serviceApplicationPoolManagedAccountName = "LAMBER\spman_app"
# service application pool name
$metadataApplicationPoolName = "managed_demo_appl"

# end script configuration section

The next code snippet checks if the “Managed Metadata Web Service” runs on at least one front-end server. If this is not the case, all “Managed Metadata Web Service” instances are taken and started on all servers. The while loop checks every 10 seconds if all services already run. If not, it waits for other 10 seconds.

write-host "Verifying running instances..."
$metadataServiceInstanceName = "Managed Metadata Web Service"
$onlineServiceInstances = Get-SPServiceInstance | where {$_.TypeName -eq $metadataServiceInstanceName -and $_.Status -eq "Online"}
if ($onlineServiceInstances -eq $NULL) {
  write-host "No running instances found. Starting all service instances now..."
  $disabledServiceInstances = Get-SPServiceInstance | where {$_.TypeName -eq $metadataServiceInstanceName -and $_.Status -eq "Disabled" }
  $disabledServiceInstances | Start-SPServiceInstance
  
  while (-not ($disabledServiceInstances -eq $NULL)) {
    write-host "Waiting that all service instances are provisioned. Going to sleep for 10 seconds..."
    sleep 10;
    $disabledServiceInstances = Get-SPServiceInstance | where {$_.TypeName -eq $metadataServiceInstanceName -and $_.Status -eq "Disabled" }
  }
  write-host "All service instances provisioned successfully."
}
else {
  write-host "At least one instance is running in the farm."
}
write-host

The next code snippet shows that the script continues by verifying if there is already a service application pool with the name specified in the configuration section of the script. If this is the case, the service application pool is used for the next steps. Otherwise, a new service application pool is created.

The creation of the service application pool first verifies if a managed account with the name specified in the configuration section already exists. If this is not the case, the managed account is registered. Please note that you will be prompted for credentials if a new managed account is going to be registered. After this step, the managed account is assigned as application pool identity for the newly created service application pool.

write-host "Verifying if '$metadataApplicationPoolName' service application pool exists..."
$serviceApplicationPool = Get-SPServiceApplicationPool $metadataApplicationPoolName -ea SilentlyContinue
if ($serviceApplicationPool -eq $NULL) {
  write-host "No service application pool found. Starting the creation process..."
  
  write-host "Verifying if '$serviceApplicationPoolManagedAccountName' is registered as managed account..."
  $managedAccountEntry = Get-SPManagedAccount $serviceApplicationPoolManagedAccountName -ea SilentlyContinue
  if ($managedAccountEntry -eq $NULL) {
    write-host "No managed account found. Starting the registering process..."
    $manCredentials = Get-Credential $serviceApplicationPoolManagedAccountName  
    $managedAccountEntry = New-SPManagedAccount $manCredentials
  }
  else {
    write-host "Account already registered."
  }
  
  $serviceApplicationPool = New-SPServiceApplicationPool $metadataApplicationPoolName -Account $managedAccountEntry
}
else {
  write-host "Service application pool already exists."
}
write-host

In the next code snippet the script is going to create the managed metadata service application (if it does not already exist) and assigns the service application pool that was defined before.

$ServiceApplication = Get-SPMetadataServiceApplication $metadataServiceApplicationName
write-host "Verifying if '$metadataServiceApplicationName' already exists..."
if ($ServiceApplication -eq $NULL) {
  write-host "No service application found. Starting the creation process..."
  $ServiceApplication = New-SPMetadataServiceApplication -Name $metadataServiceApplicationName -ApplicationPool $serviceApplicationPool
  write-host "Service application created successfully."
}
else {
  write-host "Service application already exists."
}
write-host

In the last code snippet the script creates the managed metadata service application proxy (if it does not already exist) and assigns it to the managed metadata service application that we created before.

$ServiceApplicationProxy = Get-SPMetadataServiceApplicationProxy $metadataServiceApplicationNameProxy
write-host "Verifying if '$metadataServiceApplicationNameProxy' service application proxy already exists..."
if ($ServiceApplicationProxy -eq $NULL) {
  write-host "No service application proxy found. Starting the creation process..."
  $ServiceApplicationProxy = New-SPMetadataServiceApplicationProxy -Name $metadataServiceApplicationNameProxy -ServiceApplication $ServiceApplication
  write-host "Service application proxy created successfully."
}
else {
  write-host "Service application proxy already exists"
}
write-host

Summary

Creating a new managed metadata service application for a SharePoint farm is an easy task manually and programmatically. In this blog post we saw how it is done in both ways and what are the requirements needed before executing these steps. In the next blog posts of this post series we are going to see better how to use the managed metadata service application.

 

Hope this helps,

Patrick