Lesson 1: Administer Service Applications

The Service Application Framework (SAF) is the architectural model by which important shared services—including search, metadata, business data connectivity, and user profiles—are deployed, managed, backed up, restored, and shared across farms. In this lesson, you will study the concepts, terminology, and skills required to master the administration of service applications in SharePoint 2010. In later lessons and chapters, you will explore, in depth, many of the specific service applications available in SharePoint Server 2010.

Service Instance

When you install SharePoint Server 2010, services are installed that provide functionality for search, taxonomy, user profiles, rendering of Excel worksheets, and more. Each service—more accurately referred to as a service instance—that is installed on a server consists of one or more of the following components:

• Binary files such as DLLs

• Configuration files

• Settings in the farm configuration database

• Registry-based configuration

• Windows services

• Timer jobs

• Web pages with which to manage the service

You can identify the service instances installed on a SharePoint server with Central Administration and with Windows PowerShell.

View Service Instances Using Central Administration

To view service instances using Central Administration, open the Services On Server page by performing the following steps:

1. In the Central Administration Quick Launch, click System Settings.

2. In the Servers section, click Manage Services On Server.

3. On the Services On Server page, click the Server list, and then click Change Server.

4. On the Select Server page, click the name of the server for which you want to view services.

   By default, only configurable services are displayed.

5. Click the View menu, and then click All.

View Service Instances Using Windows PowerShell

The following example shows the use of the Get-SPServiceInstance cmdlet to return all service instances on a server:

Get-SPServiceInstance -Server <Server Name>

Where:

• <Server Name> is the name of the server for which you want to list service instances. If the -Server parameter is omitted, the cmdlet returns all service instances in the farm.

Although services are installed on every server in the farm, most services are not started by default. Some services are started when you run the SharePoint 2010 Products Configuration Wizard, or when you use equivalent Windows PowerShell commands to create a farm or add a server to the farm. Remaining services must be started by using Central Administration or Windows PowerShell.

Start a Service Instance Using Central Administration

To start a service instance using Central Administration, perform the following steps:

1. In the Central Administration Quick Launch, click System Settings.

2. In the Servers section, click Manage Services On Server.

3. Click the Server menu, and then click Change Server.

4. On the Services On Server page, click the Server list, and then click Change Server.

5. On the Select Server page, click the name of the server on which you want to start the service.

   By default, only configurable services are displayed. To view all services, click the View menu, and then click All.

6. Click Start on the row of the service that you want to start.

You can stop a service instance by clicking Stop on the row of the started service instance.

Start a Service Using Windows PowerShell

The following example shows the use of the Start-SPServiceInstance cmdlet to start a service instance:

Start-SPServiceInstance -Identity <SPServiceInstancePipeBind>

Where:

• <SPServiceInstancePipeBind> is a service instance—for example, an object retrieved by using the Get-SPServiceInstance cmdlet—or a GUID of the service instance that you want to start.

You can use the Stop-SPServiceInstance cmdlet to stop a service.

Before you work with a service instance with Windows PowerShell, you must either bind to the specific service with which you want to work, or provide the GUID of the service instance. The following example assigns a service instance to a variable, and then uses the Start-SPServiceInstance cmdlet to start the service instance:

$ServerName = "SP2010-WFE1.contoso.com"
$ServiceName = "Managed Metadata Web Service"
$ServiceInstance = Get-SPServiceInstance -Server $ServerName |
    Where { $_.TypeName -eq $ServiceName }
Start-SPService $ServiceInstance

You can modify the first two lines of the script to specify the server and service name with which you want to work. The third line of the script uses the Get-SPServiceInstance cmdlet to retrieve all service instances on the specified server, and pipes the resulting collection to the Where-Object cmdlet, which filters the collection to the service instance that matches the specified service instance name.

The Status property of a service instance specifies whether the service is Disabled or Online. While the service is being started, the Status property will be Provisioning. While the service is being stopped, the Status property will be Unprovisioning.

Some service instances require additional configuration when you start the service. For example, you must provide the farm account’s user name and password when you start the User Profile Synchronization Service, as you will learn in Chapter 6.

Few services—the User Profile Synchronization Service is one—can be run only on one server in the farm. You can run most SharePoint services on more than one server. This allows you to provide redundancy for a service, so that if a service instance fails on one server, requests for the service can be handled by a service instance on another server. Multiple service machine instances also enable you to scale a service out—to service clients from a greater number of servers. Later in this lesson, you will learn how clients are directed, in round-robin format, to multiple online service instances.

A server running a service instance is often referred to as an application server, particularly if the server is not providing web applications to users.

Service Applications

The Service Application Framework (SAF) is an important architectural feature of SharePoint 2010. The SAF provides a model by which services can be deployed, provided, consumed, and managed. A service application represents a deployed–that is, an accessible—instance of a service. The service application framework provides a way for consumers in the farm to access the functionality of a centralized service, and the service application can manage the configuration and behavior of a service.

For example, the Search Service Application is the deployed instance of search services in the farm. The service application provides a management interface in Central Administration. You can use the management interface of the Search Service Application to specify the configuration of content crawling, indexing, and query behavior, and the configuration is propagated to the distributed service instances of the SharePoint Server Search service. When a user performs a search—for example, by using a query web part—the web part is connected to the Search Service Application and the request is redirected by a built-in round-robin algorithm to an available SharePoint Server Search service instance.

Examples of other service applications are:

• The Managed Metadata Service, which provides a centralized term store to support taxonomy and folksonomy, and syndicates content types across site collections. Any web application that connects to the Managed Metadata Service can contain a managed metadata column that exposes the terms in a term set, or an enterprise keywords column that allows the entry of multiple keywords from any term set or user-generated terms.

• The Business Connectivity Service, which enables SharePoint to connect to external data sources.

• The User Profile Service, which synchronizes user profile attributes from Active Directory and other sources.

• The Secure Token Service, which provides authentication services to applications and services that use claims-based authentication.

Service Application Endpoint

The SharePoint services we’ve discussed so far are web services, built upon Windows Communication Foundation (WCF). When you deploy a service application and start the associated service instance on a server, SharePoint provisions the web service and a corresponding virtual directory within the SharePoint Web Services IIS Web site on that server, as shown in Figure 5.1.

Each virtual directory is named with the GUID of the service. You can use the Get-SPServiceInstance cmdlet to determine the GUID of a service. If you explore the virtual directory, you will see that SharePoint services reside in the C:\Program Files\Microsoft Office Servers\14.0\WebServices folder. As shown in Figure 5.2, services are now WCF services (.svc files), rather than ASP.net web services (.asmx files).

The virtual directory and associated files comprise the service application endpoint. A web application will communicate with the service application endpoint to obtain the functionality of the service.

Some of the services listed on the Services On Server page are wrappers for Windows services. For example, the Microsoft SharePoint Foundation Timer service instance is a wrapper for the SharePoint 2010 Timer Windows service. Some services, including the Document Conversions service, are service instances that do not implement the SAF.

Service Scalability and Redundancy

SharePoint service instances can run on more than one server. When a web application interacts with a service application, the Application Discovery and Load Balancer Service Application service—also called the Topology service—distributes requests to a running instance of the service. The distribution uses a simple round-robin algorithm, although some services provide their own load balancing scheme—for example, Excel Services—and the request distribution can be extended by developers to include more nuanced rules.

Thus, by starting service instances for a service on more than one server in the farm, you provide reliability. If an instance of a service fails, the Topology service will detect the failure and will route requests to other running instances. Additionally, as you add service instances, you scale the performance of the service.

Create a Service Application

You can deploy a service application by using the Farm Configuration Wizard, Central Administration, or Windows PowerShell. You used the Farm Configuration Wizard to deploy service applications in Chapter 1. The following procedures illustrate the process of creating a service application, with the Managed Metadata Service service application as an example.

Create a Managed Metadata Service Application Using Central Administration

To create a Managed Metadata Service application, perform the following steps:

1. In the Central Administration Quick Launch, click Application Management.

2. In the Service Applications section, click Manage Service Applications.

3. In the ribbon, click New, and then click Managed Metadata Service.

   The Create New Managed Metadata Service page opens.

4. In the Name box, type a name for the service application.

5. In the Database Server box, type the name of the SQL server on which the database for the Managed Metadata Service application will be created.

6. In the Database Name box, type the name of the Managed Metadata Service application database to create.

7. In the Application Pool section, specify an existing application pool in which to run the service, or create a new application pool by specifying a name and a managed account for the application pool identity.

   To optimize performance of your farm, it is recommended to run all service applications in a single, shared application pool. If you have a significant business driver for process isolation, you can achieve physical isolation of a service application by choosing or creating a different application pool.

8. Click OK.

Each service application has a Windows PowerShell cmdlet with which you can create the service application.

Create a Managed Metadata Service Application Using Windows PowerShell

The following example shows the use of the New-SPMetadataServiceApplication cmdlet to create a new Managed Metadata Service service application:

New-SPMetadataServiceApplication -Name <Name> -DatabaseName <Database Name>
-ApplicationPool <Application Pool>

Where:

• <Name> is the name of the new Managed Metadata Service service application.

• <Database Name> is the name of the database for the new service application.

• <Application Pool> is the name of an application pool that will host the new service application.

Additional parameters are available to configure settings such as the content type hub. Use the Get-Help cmdlet with the –detailed parameter for more information.

For example, the following command creates a Managed Metadata Service service application for the Research and Development term store:

New-SPMetadataServiceApplication -Name "Managed Metadata Service - Research and
Development" -DatabaseName "SharePoint_Service_Metadata_Research" -ApplicationPool
"SharePoint Web Services Default"

You can delete service applications by using Central Administration or by using the Remove-SPServiceApplication cmdlet. Use the Get-Help cmdlet to learn more about Remove-SPServiceApplication. Some service applications have a specific Remove-SP* cmdlet. Type Get-Command Remove*SP*Application for a list of these service applications.

When you create a service application, the related service instance is not started on any server in the farm. You must, therefore, ensure that you have started the service instance on one or more servers. As you learned earlier in this lesson, you can start the service by using Central Administration or Windows PowerShell.

Service Application Connections (Proxies)

A service application’s application connection, also called its proxy, is a virtual entity that creates the connection point for the web application. If a web application needs functionality provided by a Managed Metadata service application, for example, the web application must be connected to the service application’s application connection. The application connection controls the interaction between the web application and the service application. The application connection can apply permissions or configuration that gives web applications a subset of functionality of the service application. For example, the application connection for the Managed Metadata Service determines whether web applications subscribe to content types published in the content type hub.

When you create a service application by using the Farm Configuration Wizard or Central Administration, a new application connection is created automatically. If you create a service application by using Windows PowerShell, you must also create an application connection. Each service application has a cmdlet that creates an application connection.

Create an Application Connection (Proxy) Using Windows PowerShell

The following example shows the use of the New-SPMetadataServiceApplicationProxy cmdlet to delete a site:

New-SPMetadataServiceApplicationProxy -Name <Name> -ServiceApplication <Service
Application Name>

Where:

• <Name> is the name for the new application connection.

• <Service Application Name> is the name of the Managed Metadata Service service application with which the new application connection will be associated.

Additional parameters are available to configure settings such as content type subscription and whether the new connection should be added to the farm’s default connection group. Use the Get-Help cmdlet with the –detailed parameter for more information.

For example, the following command adds an application connection to the service application that was created in the previous section:

New-SPMetadataServiceApplicationProxy -Name "Managed Metadata Service - Research and
Development" -ServiceApplication "Managed Metadata Service - Research and Development"

Service Application Connection Groups (Proxy Groups)

A web application uses the service application connection to communicate with the service application. You can configure a web application to connect to only the service application connections that it requires. Typically, a web application requires more than one service application, and several web applications require the same service applications. To make it easier for you to manage the associations between a web application and the service application connections it requires, you can create a logical grouping of service application connections (proxies) called an application connection group, or proxy group. You can then configure a web application to connect to the group. The other web applications that require the same services can connect to the same group.

When a web application connects to an application connection group, the application is connected to all of the application connections that are members of that group, and thereby to all of the services provided by those connections.

The Farm Configuration Wizard sets up all service applications and creates a single application connection group, named default, that is available and can be used by any web application in the farm. By default, all new web apps are connected to the default connection group. So, by default, all web applications in the farm are connected to all service applications in the farm.

This default provides maximum functionality and ease of setup. However, one of the most important features of SharePoint 2010’s service application model is that you are not limited to this “all apps connect to all services” topology. You can—and most likely should—modify the service applications that are in the default group, so that it includes only those service applications that you want consumed by all new web applications by default.

You can use the Service Application Associations page of Central Administration to edit application connection groups, including the default group.

Edit a Service Application Connection Group Using Central Administration

To add or remove service application connections in an application connection group, perform the following steps:

1. In the Central Administration Quick Launch, click Application Management.

2. In the Service Applications section, click Configure Service Application Associations.

3. On the Service Application Associations page, click the View menu, and then click Web Applications.

4. In the list of web applications, in the Application Proxy Group column, click the name of the service application connection group that you want to change.

5. To add a service connection to the group, select the check box next to the service application that you want to add to the connection group.

   To remove a service application connection from the connection group, clear the check box next to the service application that you want to remove from the connection group.

6. Click OK.

You can also create custom application connection groups that provide exactly the services required by web applications in the farm. Unfortunately, there is no place in the Central Administration user interface where you can create a new application connection group. You must do so by using Windows PowerShell.

Create a New Service Application Connection Group

The following example shows the use of the New-SPServiceApplicationProxyGroup cmdlet to create a new service application proxy group:

New-SPServiceApplicationProxyGroup -Name <Name>

Where:

• <Name> is the name of the new service application proxy group.

For example, the following command creates a proxy group named ResearchAndDevelopment:

New-SPServiceApplicationProxyGroup -Name ResearchAndDevelopment

After you create an application connection group, you can define the application connections that belong to the group. Again, this is not easy in the user interface. The new application connection group will not appear in the Service Application Associations page until after you have assigned a web application to the application connection group. The procedures for associating a web application with an application connection group are in the next section.

You can use Windows PowerShell to add application connections to the application connection group.

Add a Service Application Connection to an Application Connection Group

The following example shows the use of the Add-SPServiceApplicationProxyGroupMember cmdlet to create a new service application proxy group:

Add-SPServiceApplicationProxyGroupMember [-Identity] <Proxy Group Name> -Member <Proxy>

Where:

• <Proxy Group Name> is the name of a service application connection group.

• <Proxy> is the GUID of an application connection or a variable representing an application connection. <Proxy> can also be an array of connection objects or GUIDs.

For example, the following command adds the application connection named Managed Metadata Service – Research And Development to the application connection group named ResearchAndDevelopment:

$proxy = Get-SPMetadataServiceApplicationProxy "Managed Metadata Service - Research And
Development" Add-SPServiceApplicationProxyGroupMember "ResearchAndDevelopment" -Member
$proxy

To remove a service application connection from an application connection group, use the Remove-SPServiceApplicationProxyGroupMember cmdlet.

Connections for Multiple Instances of a Service Application

Some service applications, including Managed Metadata and Search, can support multiple instances within a single application connection group. Web applications associated with the connection group will consume services from all instances of these service applications. In Figure 5.3, you can see two instances of a Managed Metadata Service service application.

Most service applications, however, can only exist once in an application connection group. For these service applications, if you have connections to more than one instance in the connection group, you must mark one instance as the default. In Figure 5.3, you can see the Set As Default link. Web applications will not consume services from the other instances of that service application.

Application Associations

A web application is associated either with one application connection group, or with a custom collection of application connections. You specify the association when you create a web application. Figure 5.4 shows the Service Application Connections section of the Create New Web Application page.

If you choose an existing application connection group, the web application will connect to all service application connections in the group. If you choose [custom], you can select the specific application connections that the web application requires.

You can manage associations of existing web applications by using Central Administration or Windows PowerShell.

Configure Application Associations Using Central Administration

To configure application associations, perform the following steps:

1. In the Central Administration Quick Launch, click Application Management.

2. In the Service Applications section, click Configure Service Application Associations.

3. In the Web Application / Service Application column, click an application.

4. In the Edit The Following Group Of Connections list, select the application connection group with which you want to associate the application.

5. If you selected [custom] in the previous step, you can select or clear check boxes for each application connection.

6. Click OK.

You can also configure the custom service application connection group of a web application by selecting a web application, and then clicking Service Connections on the Web Application Management page. You cannot change service applications connection groups using this page.

Configure Application Associations Using Windows PowerShell

You must modify the ServiceApplicationProxyGroup property of a web application to associate the web application with a proxy group. The following example associates the web application http://research.contoso.com with the ResearchAndDevelopment proxy group.

$web = Get-SPWebApplication "http://research.contoso.com"
$web.ServiceApplicationProxyGroup = Get-SPServiceApplicationProxyGroup
("ResearchAndDevelopment")
$web.Update()

To set a web application back to using the [default] group, use the following commands:

$web = Get-SPWebApplication "http://research.contoso.com"
$web.ServiceApplicationProxyGroup = Get-SPServiceApplicationProxyGroup("")
$web.Update()

Assign Administrators of a Service Application

Farm administrators always have rights to manage all service applications. Those rights cannot be removed. SharePoint 2007 did not make it easy to delegate the administration and configuration of an individual service, but in SharePoint 2010 you can delegate the administration of service applications.

Service application administrators are delegated by members of the Farm Administrators group. The administrators of a service application can configure settings for a specific service application in a farm. However, these administrators cannot create service applications, access any other service applications in the farm, or perform any farm-level operations, including topology changes. For example, the service application administrator for a Search service application in a farm can configure settings for that Search service application only.

Assign Administrators of a Service Application Using Central Administration

To assign administrators of a service application, perform the following steps:

1. In the Central Administration Quick Launch, click Application Management, and then, in the Service Applications section, click Manage Service Applications.

2. Click the row of a service application.

   Do not click the name of a service application. Most service application names are links to the service application’s management application.

3. In the ribbon, click Administrators.

When you assign a service application administrator, and the user is not already a member of the Farm Administrators group, the user is added to the Delegated Administrators group in Central Administration. This gives the user the ability to access the Central Administration website. If for some reason a user cannot access Central Administration even though you have assigned the user an administrative role for a service application, verify that the user has been made a member of the Delegated Administrators group.

Manage Membership of the Delegated Administrators Group

To manage the membership of the Delegated Administrators group, perform the following steps:

1. In Central Administration, click Site Actions, and then click Site Permissions to open the Permissions page.

2. Click the Delegated Administrators link.

3. To add a user, click New.

   To remove a user, select the check box next to the user, click Actions, and then click Remove Users From Group.

Restrict Access to a Service Application

By default, a web application that is associated with a service application connection—either through an application connection group or through a custom set of application connections—has full access to the functionality provided by the service application. This is because the Local Farm identity has Full Control permission, by default, to a service application connection. The Local Farm identity is a special identity—like a group—that represents all service application and application pool accounts in the farm.

However, you can modify application connection permissions to restrict access to a service application, such that even if a web application is associated with the application connection, the web application has limited or no access to the service application. To restrict access to a service application, you must perform the following steps:

1. Add a specific service account to the service application.

2. Grant permissions to specific service or application pool accounts.

3. Remove the Full Control permission that is assigned to the Local Farm identity.

You can perform these tasks by using Central Administration or by using Windows PowerShell 2.0.

Restrict Access to a Service Application Using Central Administration

To restrict access to a service application by using Central Administration, you must perform the following steps:

1. Retrieve the web application service account.

2. Add the web application service account to the service application.

3. Remove the local farm ID from the service application.

Retrieve a Web Application Service Account Using Central Administration

To retrieve a web application service account by using Central Administration, perform the following steps:

1. In the Central Administration Quick Launch, click Security.

2. In the General Security section, click Configure Service Accounts.

3. On the Service Accounts page, select the web application name from the first drop-down list.

   The service account is shown in the Select An Account For This Component list. Record the service account name because you will use it in the next procedure.

4. Click Cancel to exit the Service Accounts page without making any changes.

Grant Permissions for a Service Application to a Web Application Using Central Administration

To grant permissions for service accounts to access a service application by using Central Administration, perform the following steps:

1. In the Central Administration Quick Launch, click Application Management.

2. In the Service Applications section, click Manage Service Applications.

3. On the Manage Service Applications page, click the row that contains the service application for which you want to assign permissions.

4. In the ribbon, click Permissions.

5. In the Connection Permissions dialog box, type the service account name that you retrieved in the previous procedure, and then click Add.

6. In the middle pane, click the newly added service account name.

7. Select the check box for the permission level that you want to assign to the service account.

   Because the Local Farm identity that represents all application pool and service accounts is assigned Full Control permission by default, you must remove the permission assigned to Local Farm.

8. In the middle pane, click Local Farm, and then click Remove.

9. Verify that the Connection Permissions page now lists only the service account that you want to access the service application, and that the service account has the required permissions on the service application. Click OK.

Restrict Access to a Service Application Using Windows PowerShell

The process to restrict access to a service application by using Windows PowerShell is more complex than performing the same task by using Central Administration. In Windows PowerShell 2.0, you must perform the following high-level procedures, some of which gather and store information for input into later procedures.

Restricting Access to a Service Application Using Windows PowerShell

To restrict access to a service application by using Windows PowerShell, perform the following steps:

1. Retrieve the local farm ID:

$farmID = Get-SPFarm | select id

2. Retrieve the web application service account:

$webapp = Get-SPWebApplication http://intranet.contoso.com
$username = $webApp.ApplicationPool.UserName

3. Create a new claims principal that contains the web application service account:

$principal = New-SPClaimsPrincipal $username -IdentityType WindowsSamAccountName

4. Retrieve the security object of the service application:

$serviceapplicationname = "Managed Metadata Service"
$spapp = Get-SPServiceApplication -Name $serviceapplicationname
$spguid = $spapp.id
$security = Get-SPServiceApplicationSecurity $spguid

In the preceding example, the service application is named “Managed Metadata Service.” Change this value to match the name of the service application for which you want to modify access permissions. The name assigned to the $serviceapplicationname variable must match the display name of the service application exactly, including capitalization.

5. Add the web application service account to the security object of the service application:

$rights = "Full Control"
Grant-SPObjectSecurity $security $principal -Rights $rights

The rights will generally be “Full Control,” but can vary based on the service application and your requirements. To determine what rights are available for a service application, run the following code:

$serviceapplicationname = "Managed Metadata Service"
$spapp = Get-SPServiceApplication -Name $serviceapplicationname
$rightslist = Get-SPServiceApplicationSecurity $spapp
$rightslist.NamedAccessRights

6. Remove the local farm ID from the security object of the service application:

Revoke-SPObjectSecurity $security $farmID

7. Assign the updated security object to the service application:

Set-SPServiceApplicationSecurity $spapp -ObjectSecurity $security

8. Display and review updated permissions:

(Get-SPServiceApplicationSecurity $spapp).AccessRules

Restore Farm-Wide Access to a Service Application Using Windows PowerShell

To restore access to a service application for all web and service applications in the farm, run the following script:

$serviceapplicationname = "Managed Metadata Service"
$farmID = Get-SPFarm | select id
$claimProvider = (Get-SPClaimProvider System).ClaimProvider
$principal = New-SPClaimsPrincipal -ClaimType `
   "http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid"
   -ClaimProvider $claimProvider -ClaimValue $farmid
$spapp = Get-SPServiceApplication -Name $serviceapplicationname
$spguid = $spapp.id
$security = Get-SPServiceApplicationSecurity $spguid
Grant-SPObjectSecurity -Identity $security -Principal $farmID -Rights "Full Control"
Set-SPServiceApplicationSecurity $spguid -ObjectSecurity $security

In the preceding example, the service application is named “Managed Metadata Service.” Change this value to match the name of the service application for which you want to modify access permissions. The name assigned to the $serviceapplicationname variable must match the display name of the service application exactly, including capitalization.

Restore Farm-Wide Access to a Service Application Using Central Administration

To restore access to a service application for all web and service applications in the farm, you must first run the following Windows PowerShell command:

$farmID = Get-SPFarm | select id

Copy the ID that the command displays to your clipboard. Then, perform the following steps:

1. In the Central Administration Quick Launch, click Application Management.

2. In the Service Applications section, click Manage Service Applications.

3. On the Manager Service Applications page, click the row that contains the service application for which you want to assign permissions.

4. In the ribbon, click Permissions.

5. In the Connection Permissions dialog box, paste the ID of the farm account you obtained by running the Windows PowerShell command, and then click Add.

6. In the middle pane, click the local farm account name.

7. Select the Full Control check box and then click OK.

Share Service Applications across Farms

Some service applications can be shared across SharePoint farms. Other service applications can be shared only within a single farm. The following out-of-box service applications can be shared across farms:

• User Profile

• Managed Metadata

• Search

• Business Connectivity Services

• Secure Store

• Web Analytics

Deploy Cross-Farm Service Applications

To share a service application between two farms, you must perform the following high-level steps:

1. Configure the trust between the two farms. This involves an exchange of certificates.

2. In one farm, publish one or more service applications. This creates a URL for the published service application.

3. In the other farm, connect to the published service applications. When you connect to a service application in the remote farm, you specify the URL of the service application.

If the publishing and consuming farms are in two different Active Directory domains, some service applications require a trust relationship between the two domains:

• User Profile The Active Directory domains of the publishing and consuming farms must trust each other.

• Business Data Connectivity and Secure Store The domain of the publishing farm must trust the domain of the consuming farm.

Configure Trust between Farms

Before a service application can be shared from a publishing farm to web applications in a consuming farm, an administrator of the consuming farm must provide two trust certificates to the administrator of the publishing farm: a root certificate and a Security Token Service (STS) certificate. Additionally, an administrator of the publishing farm must provide a root certificate to the administrator of the consuming farm. By exchanging certificates, each farm acknowledges that the other farm can be trusted.

The process of establishing trust consists of the following steps, which must be performed on both the consuming and publishing farms:

1. Export certificates.

1. On the consuming farm, export the root certificate.

2. On the consuming farm, export the STS certificate.

3. On the publishing farm, export the root certificate.

2. Transfer the exported certificate (*.cer) files to the other farm.

3. Import certificates and establish trust.

1. On the publishing farm, import the root certificate of the consuming farm and establish a trusted root authority.

2. On the publishing farm, import the STS certificate of the consuming farm and establish a trusted service token issuer.

3. On the consuming farm, import the root certificate of the publishing farm and establish a trusted root authority.

You can export certificates only by using Windows PowerShell. You can import certificates and establish trust by using either Central Administration or Windows PowerShell. The procedures for each step are described below.

Export the Root Certificate

The following example shows how to export the root certificate:

$rootCert = (Get-SPCertificateAuthority).RootCertificate
$rootCert.Export("Cert") | Set-Content <Path\Filename.cer> -Encoding byte

Where:

• <Path\Filename.cer> is the path and filename to which to export the root certificate.

Export the STS Certificate

The following example shows how to export the STS certificate from the consuming farm:

$stsCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate
$stsCert.Export("Cert") | Set-Content <Path\Filename.cer> -Encoding byte

Where:

• <Path\Filename.cer> is the path and filename to which to export the STS certificate.

The administrator of the consuming farm must perform both procedures, and must copy the resulting certificate (*.cer) files to the administrator of the publishing farm. The administrator of the publishing farm must export the root certificate of the publishing farm, and copy the resulting certificate (*.cer) file to the administrator of the consuming farm.

The administrators of the publishing and consuming farms then import each other’s root certificate, and use the certificate to establish a trust relationship. This can be done by using Central Administration or Windows PowerShell.

Establish Trust Using Central Administration

To establish trust by using Central Administration, perform the following procedure after exporting certificates and copying them to the farm.

1. In the Central Administration Quick Launch, click Security.

2. In the General Security section, click Manage Trust to open the Trust Relationship page.

3. Click New to open the Establish Trust Relationship page.

4. Enter a name that describes the purpose of the trust relationship.

5. Browse to and select the Root Authority Certificate for the trust relationship.

   This must be the Root Authority Certificate that was exported from the other farm by using Windows PowerShell.

6. If you are performing this task on the publishing farm, select the Provide Trust Relationship check box. Type in a descriptive name for the token issuer and browse to and select the STS certificate that was copied from the consuming farm. Click OK.

If you use Windows PowerShell to establish the trust relationship, you must import the root certificate to establish a trusted root authority. This must be done on both farms. Then you must import the STS certificate to establish a trusted service token issuer. This must be done on the publishing farm.

Import the Root Certificate and Create a Trusted Root Authority

The following example shows how to import the root certificate and create a trusted root authority:

$trustCert = Get-PfxCertificate <Path\Filename.cer>
New-SPTrustedRootAuthority <Farm Name> -Certificate $trustCert

Where:

• <Path\Filename.cer> is the path and filename of the root certificate to import.

• <Farm Name> is a descriptive name of the farm from which the root certificate was exported. This becomes the display name of the trusted farm.

The administrator of the publishing farm must also import the STS certificate that was copied from the consuming farm and use the imported certificate to create a trusted service token issuer.

Import the STS Certificate and Create a Trusted Service Token Issuer

The following example shows how to import the STS certificate and create a trusted service token issuer:

$stsCert = Get-PfxCertificate <Path\Filename.cer>
New-SPTrustedServiceTokenIssuer <Farm Name> -Certificate $stsCert

Where:

• <Path\Filename.cer> is the path and filename of the STS certificate to import.

• <Farm Name> is a descriptive name of the farm from which the STS certificate was exported. This becomes the display name of the trusted service token issuer.

Publish a Service Application

On the farm in which the service application is located, an administrator must explicitly publish the service application. Service applications that are not explicitly published are available to the local farm only.

An administrator must also give the consuming farm permission to the Application Discovery and Load Balancing Service Application on the publishing farm. After doing this, give the consuming farm permission to the published service applications that it will be consuming.

Publish a Service Application Using Central Administration

To publish a service application, perform the following steps:

1. In the Central Administration Quick Launch, click Application Management.

2. In the Service Applications section, click Manage Service Applications.

3. Click the row of the service application that you want to publish.

   Do not click the name of a service application. Most service application names are links to the service application’s management application.

4. On the ribbon, click Publish to open the Publish Service Application page.

5. In the Connection Type drop-down list, select the protocol for the connection—http or https.

6. Select the Publish This Service Application To Other Farms check box.

7. Copy the Published URL into your clipboard. This URL will be entered by an administrator of the consuming farm.

   The URL will be similar to the following: urn:schemas-microsoft-com:sharepoint:service:9c1870b7ee97445888d9e846519cfa27#authority=urn:uuid:02a493b92a5547828e21386e28056cba&authority=https://ua_powershell:32844/Topology/topology.svc.

8. Optionally, enter a description and a link to a web page that will be visible to administrators of remote farms.

9. Click OK.

Publish a Service Application Using Windows PowerShell

The following example shows the use of the Publish-SPServiceApplication cmdlet to publish a service application:

Publish-SPServiceApplication -Identity <ServiceApplicationGUID>

Where:

• <ServiceApplicationGUID> is the GUID of the service application that you want to publish. If you do not know the GUID of the service application, use the following example to publish a service application by name. Change the value assigned to the variable $spapp so that it matches the display name of the service application you want to publish exactly, including capitalization.

$serviceapplicationname = "Managed Metadata Service"
Get-SPServiceApplication -Name $serviceapplicationname |
   Publish-SPServiceApplication

After you publish the service application, you must retrieve the URL for the published service application.

Retrieve Information About Published Service Applications

The following example shows the use of the Get-SPTopologyServiceApplication cmdlet to retrieve the URL for the Topology service application:

Get-SPTopologyServiceApplication

You can also use the Uri property of a service application object to determine the published URL of the application.

Connect to Remote Service Applications

After the publishing farm has published the service application, an administrator of the consuming farm can connect to that service application from the consuming farm by specifying the published URL of the service application.

Connect to a Service Application on a Remote Farm Using Central Administration

To connect to a service application on a remote farm by using Central Administration, perform the following steps:

1. In the Central Administration Quick Launch, click Application Management.

2. In the Service Applications section, click Manage Service Applications.

3. On the ribbon, click the Connect button down arrow, and then click the type of service application to which you want to connect.

4. On the Connect To A Remote Service Application page, in the Farm Or Service Application Address box, type the URL.

   You can enter either the URL of the published service application or the URL of the remote farm’s topology service application.

   The Connect To A Remote Service Application page opens. It displays the service applications that match the URL that you typed in Step 4. If you entered the URL of a published service application, only the corresponding service application is listed. If you entered the URL of the remote farm’s topology service, all published service applications are listed.

5. Click the row of the service application to which you want to connect.

6. Optionally, select the check box to add the service application connection to the farm’s default application connection group.

7. Click OK.

8. You are prompted to change the connection name. Type a new name into the Connection Name text box or leave the default name, and then click OK.

9. Click OK to complete the procedure.

Connect to a Service Application on a Remote Farm Using Windows PowerShell

The following example shows the use of the New-SPMetadataServiceApplicationProxy cmdlet to connect to a service application on a remote farm:

New-SPMetadataServiceApplicationProxy -Name <Name> -URI <Service Application URL>

Where:

• <Name> is the name for the new application connection.

• <Service Application URL> is the published URL of the Managed Metadata Service service application with which the new application connection will be associated.

After you have used Central Administration or Windows PowerShell to connect to a published service application on a remote farm, you must add the service application connection to an application connection group on the consuming farm, or web applications must use a custom application connection group to connect directly to the application connection. The procedures for doing this are identical to the procedures used to add an application connection from a local service application to an application connection group. See the section Service Application Connection Groups (Proxy Groups) earlier in the chapter for details.

Service Application Design

Service application design is an art and a science. Keep in mind the following rules regarding the logical design of service applications:

• You can have more than one instance of most service applications in a farm.

• Each service application has one application connection.

• A service application’s connection can belong to more than one application connection group.

• An application connection group contains connections for one or more service applications.

• A web application is associated either with one application connection group or with a custom group of application connections for the services it requires.

• An application connection group can contain connections for more than one instance of a specific service application.

  For some service applications, such as Search and Managed Metadata, you can add connections for more than one instance to an application connection group, and associated web applications will consume the services of each instance. For most service applications, however, you can have only one instance—the instance configured as default—and web applications will consume the service from only the default instance.

• You can restrict access of a web application to a service application.

• Some service applications can be shared across farms.

You can use these rules to determine the logical design of your SharePoint services—that is, the relationships between web applications and the service applications they require. After you have determined the logical design of your service applications based on the services that are required by web applications in the farm, you can then determine the physical design of service instances to support performance and redundancy requirements.

• A service instance can run on one or more servers in the farm.

• A server can run service instances for multiple, different services, or can be dedicated to a single service.

Practice Administer Service Applications

Practices are designed to guide you through important procedures. The instructions in the Training Kit are high-level instructions that will challenge you to think carefully and to apply the procedures that are covered in this lesson, and elsewhere in the Training Kit. If you need assistance, consult the detailed, step-by-step instructions in the Practice Answers on the companion media.

In this practice, you will deploy a Managed Metadata Service service application. You will begin with a snapshot, created in Chapter 1, in which the Farm Configuration Wizard had not been run, and therefore only the default service applications had been deployed. You will now deploy the first new service application to the farm. In Lesson 2, you will use the Managed Metadata Service service application to manage taxonomy and content type publishing.

Prepare for the Practice

Before you perform this practice, you must ensure that your lab environment has been built according to the instructions found in the Introduction to this Training Kit.

1. Apply the snapshot SHAREPOINT INSTALLED AND CONFIGURED to CONTOSO-DC.

2. Apply the snapshot SHAREPOINT INSTALLED AND CONFIGURED to SP2010-WFE1.

3. Start CONTOSO-DC.

   Wait for the virtual machine to complete startup, at which time the Press Ctrl+Alt+Del prompt appears.

4. Start SP2010-WFE1.

5. Log on to SP2010-WFE1 as CONTOSO\SP_Admin with the password Pa$$w0rd.

6. Start SharePoint 2010 Management Shell using the Run As Administrator option.

7. Type the following command, and then press Enter:

   & 'C:\70667TK\Practice Files\05_01\05_00_Setup.ps1'

   A script will run that creates the web applications, content databases, and site collections necessary for the exercises in this chapter.

8. Close SharePoint 2010 Management Shell.

EXERCISE 1 Register a Managed Account for the Service Applications Application Pool

In this exercise, you register CONTOSO\SP_ServiceApps as a managed account so that it can be used to create an application pool for service applications.

• Register CONTOSO\SP_ServiceApps as a managed account. The password of the account is Pa$$w0rd.

EXERCISE 2 Create a Managed Metadata Service Application Using Central Administration

In this exercise, you create a Managed Metadata service application to support requirements for taxonomy, folksonomy, and centrally managed content types.

• Create a Managed Metadata service application. Use the following specifications and guidance:

  • Name: Managed Metadata Service – Enterprise.

  • Database server: SP2010-WFE1.contoso.com.

  • Database name: SharePoint_Service_Metadata_Enterprise.

  • Application pool: A new pool named SharePoint Service Applications that uses the managed account CONTOSO\SP_ServiceApps as its identity.

  • Report Syndication Import Errors: No.

  You will select this option in Lesson 2.

  • Add This Service Application To The Farm’s Default List: Yes.

EXERCISE 3 Start the Managed Metadata Web Service Service Instance

In this exercise, you start the service instance of the Managed Metadata Web Service on SP2010-WFE1.

• Start the Managed Metadata Web Service on SP2010-WFE1.

EXERCISE 4 Examine Service Application Connection Groups and Application Associations

In this exercise, you examine the farm’s default connection group and verify that web applications in the farm are associated with the connection group.

• Examine the members of the service application connection group named default.

• Examine the association of the Contoso Intranet web application. Observe that if you change the association to [Custom], you can specify the individual service application connection(s) with which the application is associated. Do not make any changes, however. Verify that the Contoso Intranet web application is associated with the application connection group named default.

Lesson Summary

• A service instance is a process that is added to servers in the farm. A service instance can run on one or more servers in the farm.

• A service application is a deployed instance of a service. A service application allows web applications in the farm to share a service. Some service applications can be shared across farms.

• An application connection, also called a proxy, provides the communication interface between a web application and a service application.

• An application connection group, also called a proxy group, contains the application connections of one or more service applications. SharePoint creates an application group named default, and you can define additional application connection groups. A service application connection can be a part of more than one application connection group. Some service applications can support connections to more than one instance of the service application within a single application connection group.

• Allows you to associate a web application with all the application connections that belong to the group. A web application is associated with one, and only one, application connection group, or the application has a custom group of associations with the application connections of the specific services that the application requires.

• The service application framework gives you granular control over which services are deployed and how they are shared:

  1. You can deploy only the service applications that are needed to a farm.

  2. Web applications can be configured to use only the service applications that are needed, instead of all the services that have been deployed.

  3. You can deploy multiple instances of the same service in a farm and assign unique names to the resulting service applications.

  4. You can share service applications across multiple web applications within the same farm.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 1: Administer Service Applications. The questions are also available on the companion media in a practice test if you prefer to review them in electronic form.

1. You want to deploy the first instance of Excel Services in your farm. What must you do? (Choose all that apply. Each correct answer is a part of the complete solution.)

1. Install Microsoft Office Excel 2010 on the SharePoint server.

2. Start the Excel Calculation Services service on at least one server.

3. Create an Excel Services Application.

4. Create a web application called Excel Services.

2. You want to share taxonomy managed in Farm A with web applications in Farm B. What must you do? (Choose all that apply. Each correct answer is a part of the complete solution.)

1. Publish the Managed Metadata Services application in Farm A.

2. Start the Managed Metadata Web Service on at least one server in Farm B.

3. Publish the Managed Metadata Web Service in Farm B.

4. Create a connection in Farm A.

5. Create a connection in Farm B.

6. Start the Managed Metadata Web Service on at least one server in Farm A.