Configuring Cross Farm (Federated) Services in

Microsoft SharePoint 2013

Written By:
Shannon Bray and Patrick Curran
Presented By:
Shannon Bray
Microsoft Certified Master: SharePoint
Chief Architect
[email protected]
Planet Technologies, Inc.
http://www.go-planet.com

Overview
SharePoint 2013 has a number of services that support cross-farm or federated architectures. In this session,
we will introduce you to these services, discuss when to implement them, and share with you best practices on
configuring them in your environment. We will examine the following:

Basics of a Service Application Architecture

Terms and concepts of services applications

Concepts of federation

Steps to configure federated services

Steps to troubleshoot and test the configuration

Basics of cross version support

Contents
Overview ..................................................................................................................................................... 1
Exploring the service application architecture ............................................................................................ 3
Key concepts ........................................................................................................................................... 3
Exploring service federation ....................................................................................................................... 4
Federated service applications across farms connected by WAN links ................................................... 7
Build an Enterprise and Consumer Farm ................................................................................................ 8
Build an Enterprise Services Farm ...................................................................................................................................................... 9
Build a Consumer Farm ...................................................................................................................................................................... 10
Provision an Enterprise Services Environment ............................................................................................................................ 11
Provision a Consuming Environment ............................................................................................................................................. 13
Configuring the Certificates .............................................................................................................................................................. 14

Publishing the Services ......................................................................................................................... 17

Consuming the Services ........................................................................................................................ 19
Troubleshoot the Federated Service Solution ....................................................................................... 22
Test the Federated Service Solution ..................................................................................................... 24

Microsoft introduced the existing service application architecture with the SharePoint 2010 product. It solved
many of the key issues that were present with the SharePoint Service Providers (SSPs) from the Microsoft Office
SharePoint Server 2007 product. Those of you who are familiar with how it worked in 2010 will find that the
architecture has remained intact. With the release of SharePoint 2013, some of the services have changed, but
the overall plumbing works just as it did both the good and the bad. While this presentation is focused on
federated (cross farm) services in SharePoint 2013, it is important to understand how the SharePoint service
application model works and you will need to understand the core components of the services. While many of
the services remain unchanged, some have been rebuilt from the ground up and others are completely new. As
you review the service applications that are available in SharePoint 2013, you will gain an understanding of what
these services do and some design considerations for each. With the architectures of SharePoint broadening
out into multiple farms, some organizations will find it useful to have services farms that support a number of
SharePoint implementations.

Exploring the service application architecture

The service application architecture plumbing is basically the same as in SharePoint 2010. Microsoft did
introduce some new service applications, and even managed to remove several, but with SharePoint 2013 the
service application models are relatively unchanged from SharePoint 2010. Microsoft removed the Web
Analytics, Work Viewing, and the PowerPoint Viewing services.

Key concepts
The term service application has been overused. This makes it difficult for people to understand where the
components live and how they function. To really get a handle on whats happening behind the scenes, its
important to know these terms:

Service The application binaries deployed to the servers in the farm.

Service Machine Instance The actual instance of the service running on the server. The service
instance also has a Log On As account associated with the instance.

Service Application The logical component that contains the service configuration and management
such as the service application configuration information and the database connection string.

Service Application Proxy The interface used by the service consumers for communicating with the
service and the load balancer. The proxy is required so the consumer knows which server to contact and
how to consume the actual service. Its important to note that the service application proxy is not a web
service or Windows Communication Foundation (WCF) proxy.

Service Consumer Any application or service that consumes the service. If you are using the service
application, you are a service consumer.

Service Proxy Groups

Groups of service applications associated to specific web applications.

You can deploy services in a number of ways, including the Configuration Wizard, Central Administration, or
Windows PowerShell. The Configuration Wizard will configure many of the services with their default values.
You shouldnt use this for production environments, as there are many services that should be manually
configured to ensure success.
In Central Administration, you can configure several services by populating fields associated with them.
While you have a little more control than with the Farm Configuration Wizard, most SharePoint professionals
will opt to use Windows PowerShell.

Windows PowerShell gives you the most control over the deployment of your service applications into your
environment. The provisioning of some of the service applications can be very tricky, but you can still provision
them all through Windows PowerShell.
When you configure your SharePoint farms, you get two services created automatically. These are key
components for how the services work. These services include:

Application Discovery and Load Balancer service application

Security Token service (STS) application

Service applications must expose a web endpoint because all of their communications take place over
HTTPS. Its also important to know that service applications communicate over TCP ports 32843 (HTTP) and
32844 (HTTPS).
Service applications are consumed by web applications, and each web application can have a specific set of
proxy groups assigned to it. In the Figure below, you can see that the default proxy group and the secondary
proxy group are getting consumed by different web applications and are sharing four service applications.

FIGURE 1

Having the ability to pick and choose which proxy groups are assigned to which web application allows you
to easily create a services architecture as complicated as required.

Exploring service federation

During the architectural design phase of your environment, you should have reviewed the consolidation of
existing farms. However, what if you cannot consolidate all of your farms? You do not want to waste server
resources by replicating out the same Search service on all of your farms when you could provision a Search

service farm to handle search for all of your farms. The primary reason for creating a services farm is to
consolidate services into one farm and share the resources across your organization. Another reason to
implement a services farm would be for the delegation of service management to different departments or
groups or even an entirely different organization. If you are going to set up a services farm that is going to be
accessing other Active Directory domains, a two way trust is required for UPAMMS does not require a trust
and the rest of the services will work with a one-way trust. Federating your services will also give you the ability
to scale out your services as your farm(s) grow. If you are thinking that you should create a services farm,
remember that you need to let the business requirements dictate your decision, not the technology. Just
because you can federate your services, does not mean that you need to create a services farm.
In SharePoint 2013, there are six services that will federate:

Business Data Connectivity

Machine Translation

Managed Metadata

Search

Secure Store

User Profile

There were six services that federated in SharePoint 2010 as well, however, the SharePoint 2010 Web
Analytics service was consumed by the new Search service. The Machine Translation service is new to service
federation with SharePoint 2013.
One advantage of using SharePoint 2013 for your cross-farm services is the ability of the service applications
to be consumed by SharePoint 2010. The SharePoint 2013 services that can be consumed by SharePoint 2010
are:

Business Data Connectivity

Managed Metadata

Search

Secure Store

User Profile

The way to create the consumption of a federated service application is the same in SharePoint 2013 as it
was in SharePoint 2010. The ability to have a SharePoint 2013 services farm consumed by another farm is
started by creating a trust between the two farms. While a lot of work has been done to create S2S trusts within
the new SharePoint app model, creating your trust between farms is still certificate based. There are three
certificates that must be used to create the trust. The SharePoint Root certificate, which signs the STS
certificates; the STS certificate, which signs the claims tokens; and a Secure Sockets Layer (SSL) certificate to
keep the service requests encrypted over HTTPS. The way to establish the trust between the two farms is to
exchange the Root certificate between servers, and to have the publisher trust the consumers STS certificate, as
illustrated in Figure 2.

FIGURE 2 Trust is created by exchanging certificates between farms.

Once you have set up your services farm, you can assign your default and custom application proxy groups,
as shown in Figure 3.

FIGURE 3

A design of how to utilize a federated services farm.

Federated service applications across farms connected by WAN links

There are a number of services that are supported across a WAN. They include: Search, Managed Metadata,
Business Data Connectivity, Machine Translation Service and Secure Store; the user profile service is not
supported. In a WAN environment, Search will have an increase in latency while crawling. Content can be
crawled over WAN connections. Or, you can configure search to retrieve results from remote result sources
(indexes at remote farms). For more information on Search over a WAN link, see:
http://technet.microsoft.com/en-us/library/gg441255.aspx
User entry fields that the Managed Metadata service application provides might not be available if a WAN
connection is not online (such as an intermittent satellite link).
After the data model is cached on the web server of the remote farm (the farm that consumes the Business
Data Connectivity service from a central farm), the remote farm connects directly to the data source over the
WAN to query the data (instead of reconnecting to the farm that is hosting the Business Data Connectivity
service). Therefore, the remote farm requires permission to access the data source. Also, performance between
the remote farm and the data source depends on the performance of the WAN connection.
Using the User Profile service application across WAN links is not supported. This service requires direct
database access.

Build an Enterprise and Consumer

Farm
We will be creating two farms. One will host our enterprise services; the other will
host our Content Web applications. We will be creating both of these farms from scratch
and each step will be outlined so that you are armed with the necessary knowledge to
federate services in any environment. Our two farms will both be within the same
domain, but can easily be built across domains as well. We will discuss this in more
detail later in the presentation. Since we will be using the same domain, we can build our
demo with five servers: DEMOAD, DEMOSP, DEMOSP1, DEMOSP2 and DEMOSQL.
We will first begin by creating the appropriate accounts in Active Directory. The
accounts we care about are as follows: spFarm, spServices, spContent, spCrawl, spUPS,
and spC2WTS. To expedite the process, we will add accounts using PowerShell from one
of our SharePoint farms; see Code Listing 1 for more details. It is important to note that
these accounts will be created in the Managed Service Accounts OU, so if you are not
starting off with Windows Server 2008 R2 or higher, you will need to change the CN
location in the scripts below.
Code Listing 1 - Add SharePoint Account to Active Directory
$domainName = $env:USERDOMAIN
$LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local"
$objCN = [ADSI]$LDAP
$objUser = $objCN.Create("user","CN=SharePoint Services")
$objUser.Put("sAMAccountName","spServices")
$objUser.Setinfo()
$objUser.psbase.invokeset("AccountDisabled", "False")
$objUser.SetPassword("Passw0rd1")
$objUser.setinfo()
$domainName = $env:USERDOMAIN
$LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local"
$objCN = [ADSI]$LDAP
$objUser = $objCN.Create("user","CN=SharePoint Content")
$objUser.Put("sAMAccountName","spContent")
$objUser.Setinfo()
$objUser.psbase.invokeset("AccountDisabled", "False")
$objUser.SetPassword("Passw0rd1")
$objUser.setinfo()
$domainName = $env:USERDOMAIN
$LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local"
$objCN = [ADSI]$LDAP
$objUser = $objCN.Create("user","CN=SharePoint Search Crawl")
$objUser.Put("sAMAccountName","spCrawl")
$objUser.Setinfo()
$objUser.psbase.invokeset("AccountDisabled", "False")
$objUser.SetPassword("Passw0rd1")

$objUser.setinfo()
$domainName = $env:USERDOMAIN
$LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local"
$objCN = [ADSI]$LDAP
$objUser = $objCN.Create("user","CN=SharePoint User Profile Services
Sync")
$objUser.Put("sAMAccountName","spUPS")
$objUser.Setinfo()
$objUser.psbase.invokeset("AccountDisabled", "False")
$objUser.SetPassword("Passw0rd1")
$objUser.setinfo()
$domainName = $env:USERDOMAIN
$LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local"
$objCN = [ADSI]$LDAP
$objUser = $objCN.Create("user","CN=SharePoint C2WTS")
$objUser.Put("sAMAccountName","spC2WTS")
$objUser.Setinfo()
$objUser.psbase.invokeset("AccountDisabled", "False")
$objUser.SetPassword("Passw0rd1")
$objUser.setinfo()
$domainName = $env:USERDOMAIN
$LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local"
$objCN = [ADSI]$LDAP
$objUser = $objCN.Create("user","CN=SharePoint Farm")
$objUser.Put("sAMAccountName","spFarm")
$objUser.Setinfo()
$objUser.psbase.invokeset("AccountDisabled", "False")
$objUser.SetPassword("Passw0rd1")
$objUser.setinfo()

Build an Enterprise Services Farm

Now that we have the accounts set up, we will focus our attention to the
Enterprises Services environment. For the sake of this demonstration, we will configure
our Farm to include only the services that support federation and that can be quickly
provisioned (Managed Metadata, BCS, Secure Store). To create our Enterprise Services
environment, we will rely on PowerShell to help with the heavy lifting. This is important
because it ensures consistency and should leave us in a known state. Code listing 2 will
build the farm; we will provision the services shortly.
Code Listing 2 - Build the Enterprise Farm
Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0
# Settings
$databaseServer = "SPSQL" # alias name
$configDatabase = "Enterprise_Farm_Config"
$adminContentDB = "Enterprise_Farm_Content_Admin"
$passphrase = "Passw0rd1"

$farmAccountName = "Demo\spfarm"
$farmAccount = Get-Credential $farmAccountName
$passphrase = (ConvertTo-SecureString $passphrase -AsPlainText -force)
#will error, but fix the regkey...
psconfig.exe -cmd upgrade
Write-Host "Creating Configuration Database and Central Admin Content
Database..."
New-SPConfigurationDatabase -DatabaseServer $databaseServer DatabaseName $configDatabase `
-AdministrationContentDatabaseName $adminContentDB `
-Passphrase $passphrase -FarmCredentials $farmAccount
$spfarm = Get-SPFarm -ErrorAction SilentlyContinue -ErrorVariable err
if ($spfarm -eq $null -or $err) {
throw "Unable to verify farm creation."
}
Write-Host "ACLing SharePoint Resources..."
Initialize-SPResourceSecurity
Write-Host "Installing Services ..."
Install-SPService
Write-Host "Installing Features..."
Install-SPFeature -AllExistingFeatures
Write-Host "Creating Central Administration..."
New-SPCentralAdministration -Port 2013 -WindowsAuthProvider NTLM
Write-Host "Installing Help..."
Install-SPHelpCollection -All
Write-Host "Installing Application Content..."
Install-SPApplicationContent
Write-Host "Enterprise Farm Creation Complete!"

Build a Consumer Farm

The script for the consumer farm will be similar to the previous section.
Code Listing 3 - Build the Consumer Farm.
Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0
# Settings
$databaseServer = "SPSQL" # alias name
$configDatabase = "Consumer_Farm_Config"
$adminContentDB = "Consumer_Farm_Content_Admin"
$passphrase = "Passw0rd1"
$farmAccountName = "Demo\spfarm"
$farmAccount = Get-Credential $farmAccountName
$passphrase = (ConvertTo-SecureString $passphrase -AsPlainText -force)

#will error, but fix the regkey...

psconfig.exe -cmd upgrade
Write-Host "Creating Configuration Database and Central Admin Content
Database..."
New-SPConfigurationDatabase -DatabaseServer $databaseServer DatabaseName $configDatabase `
-AdministrationContentDatabaseName $adminContentDB `
-Passphrase $passphrase -FarmCredentials $farmAccount
$spfarm = Get-SPFarm -ErrorAction SilentlyContinue -ErrorVariable err
if ($spfarm -eq $null -or $err) {
throw "Unable to verify farm creation."
}
Write-Host "ACLing SharePoint Resources..."
Initialize-SPResourceSecurity
Write-Host "Installing Services ..."
Install-SPService
Write-Host "Installing Features..."
Install-SPFeature -AllExistingFeatures
Write-Host "Creating Central Administration..."
New-SPCentralAdministration -Port 2013 -WindowsAuthProvider NTLM
Write-Host "Installing Help..."
Install-SPHelpCollection -All
Write-Host "Installing Application Content..."
Install-SPApplicationContent
Write-Host "Consumer Farm Creation Complete!"

Provision an Enterprise Services Environment

We will now create a number of services that we intend to share with
another farm. As mentioned earlier, there are six services that can be federated; we
will build a couple of these here so that we have something to build.
Code Listing 4 - Provision Enterprise Services.
Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0
# App Pools
$saAppPoolName = "SharePoint Web Services Default"
$saAppPoolUserName = "Demo\spservices"
# Service Application and DB names
$stateName = "Enterprise Farm State Service"
$stateDBName = "Enterprise_Farm_StateService"
$usageName = "Enterprise Farm Usage and Health Data Collection Service"
$usageDBName = "Enterprise_Farm_Usage"

# Create Managed Accounts and Application Pools

# Service Apps
Write-Host "Please supply the password for the $saAppPoolUserName
Account..."
$appPoolCred = Get-Credential $saAppPoolUserName
$saAppPoolAccount = New-SPManagedAccount -Credential $appPoolCred
$saAppPool = New-SPServiceApplicationPool -Name $saAppPoolName -Account
$saAppPoolAccount
# Create State Service Application and Proxy, and add to default proxy
group
Write-Host "Creating $stateName Application and Proxy..."
$stateDB = New-SPStateServiceDatabase -Name $stateDBName
$state = New-SPStateServiceApplication -Name $stateName -Database
$stateDB
New-SPStateServiceApplicationProxy -Name "$stateName Proxy" ServiceApplication $state -DefaultProxyGroup
# Setup the Usage Service App
Write-Host "Creating $usageName Application and Proxy..."
$serviceInstance = Get-SPUsageService
New-SPUsageApplication -Name $usageName -DatabaseName $usageDBName UsageService $serviceInstance
# app pool
$saAppPoolName = "SharePoint Web Services Default"
$appPoolUserName = "Demo\spServices"
# Gets app pool or quits
Write-Host "Getting Application Pool..."
$saAppPool = Get-SPServiceApplicationPool -Identity $saAppPoolName -EA 0
if($saAppPool -eq $null)
{
Write-Host "Cannot find the Application Pool $appPoolName, please
ensure it exists before continuing."
Exit -1
}
# MMS specifics
$mmsInstanceName = "MetadataWebServiceInstance"
$mmsName = "Enterprise Farm Managed Metadata Service"
$mmsDBName = "Enterprise_Farm_Managed_Metadata"
# Sets up Managed Metadata service instance & service app and proxy
Write-Host "Creating $mmsName Application & proxy..."
$mms = New-SPMetadataServiceApplication -Name $mmsName -ApplicationPool
$saAppPoolName -DatabaseName $mmsDBName
$proxy = New-SPMetadataServiceApplicationProxy -Name "$mmsName Proxy" ServiceApplication $mms -DefaultProxyGroup
Write-Host "Starting the $mmsInstanceName..."
Get-SPServiceInstance | where{$_.GetType().Name -eq $mmsInstanceName} |
Start-SPServiceInstance
Write-Host "Enterprise MMS Complete!"

# BDC specifics
$bdcInstanceName = "Business Data Connectivity Service"
$bdcName = "Enterprise Farm Business Data Connectivity Service"
$bdcDBName = "Enterprise_Farm_BDC"
# Sets up Business Data Connectivity Service Application and Proxy and
Service Instance
Write-Host "Creating $bdcInstanceName Application and Proxy..."
$bdc = New-SPBusinessDataCatalogServiceApplication -Name $bdcName ApplicationPool $saAppPoolName -DatabaseName $bdcDBName
Write-Host "Starting the $bdcInstanceName Instance..."
Get-SPServiceInstance | where-object {$_.TypeName -eq $bdcInstanceName}
| Start-SPServiceInstance
Write-Host "Enterprise BDC Complete!"
# SSS Specifics
$sssInstanceName = "Secure Store Service"
$serverName = "SPC-Services"
$sssName = "Enterprise Farm Secure Store Service"
$sssDBName = "Enterprise_Farm_SecureStore"
# Sets up Secure Store Service Application & Proxy and Service Instance
Write-Host "Creating $sssName Application & Proxy..."
$sss = New-SPSecureStoreServiceApplication -Name $sssName ApplicationPool $saAppPoolName -DatabaseName $sssDBName auditingEnabled:$true -auditlogmaxsize 30 -Sharing:$false
$proxy = New-SPSecureStoreServiceApplicationProxy -Name "$sssName Proxy"
-ServiceApplication $sss -DefaultProxyGroup
Write-Host "Starting the $sssInstanceName Instance..."
$sssInstance = Get-SPServiceInstance | where-object{$_.TypeName -eq
"Secure Store Service" -and $_.Server.Address -eq $serverName} | StartSPServiceInstance
Write-Host "Enterprise SSS Complete!"

Provision a Consuming Environment

All of the heavy lifting for the Publishing Farm is complete and now its
time to focus on the farm that will use the Enterprise Services. We can create any
services here that we wish, the most important piece to understand is that we can
consume services from another farm and rely on that farm to provide those
resources.
In our Consumer Farm, we will also be provisioning a SharePoint Content
Web application that can be used to demonstrate the use of our Enterprise
Services.
# App Pools
$saAppPoolName = "SharePoint Web Services Default"
$saAppPoolUserName = "Demo\spservices"
$waAppPoolName = "SharePoint Content"
$waAppPoolUserName = "Demo\spcontent"

# Web App details

$mainURL = "http://DEMOSP2"
$webAppName = "SPC Consumer"
$contentDBName = "Consumer_Farm_Content_Web_Application"
# Root Site Collection details
$ownerEmail = "[email protected]"
$ownerAlias = "Demo\administrator"
# Web app
Write-Host "Please supply the password for the $waAppPoolUserName
Account..."
$appPoolCred = Get-Credential $waAppPoolUserName
$waAppPoolAccount = New-SPManagedAccount -Credential $appPoolCred
<# Create a new Web App using Claims (Windows (NTLM))
#>
$authProvider = New-SPAuthenticationProvider
$webApp = New-SPWebApplication -ApplicationPool $waAppPoolName ApplicationPoolAccount $waAppPoolAccount -Name $webAppName -Port 80 AuthenticationProvider $authProvider -DatabaseName $contentDBName
# Set sensible content db limits
Set-SPContentDatabase $contentDBName
30

-MaxSiteCount 50 -WarningSiteCount

<# Create Site Collection at root

#>
New-SPSite -Url $mainURL -owneralias $ownerAlias -ownerEmail $ownerEmail
Write-Host "WebApp Complete!"

Configuring the Certificates

Our Farms are complete. Its now time to publish the Enterprise Services we wish
to share with our Consumer. This will be done in a number of steps:
Create a certificate on the Enterprise Farm
Create certificates on the Consumer Farm
Swap the Certificates
Import the Certificates on the Enterprise Farm
Import the Certificate on the Consumer Farm

Create a Certificate on the Enterprise Farm

We will first need to export our Root certificate from the Enterprise Farm.
To do this we will first create a path where we want to export our certificate to.
After our path has been confirmed, we will use the Get-SPCertificateAuthority
cmdlet to export the certificate for our farm.
# Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0
$path = "C:\Certs"
# Test and Create Path
If ((test-path $path) -eq $false)
{
[IO.Directory]::CreateDirectory("$path")
}
# Export Cert
$rootCert = (Get-SPCertificateAuthority).RootCertificate
$rootCert.Export("Cert") | Set-Content
"C:\Certs\EnterpriseServicesRootCert.cer" -Encoding byte

Create a Certificate on the Consumer Farm

On the Consumer Farm, we not only need to export the Root certificate, but
also a Secure Token Service (STS) certificate as well. The later can be exported by
using the Get-SPSecurityTokenServiceConfig cmdlet.
To ease this process, we will also get the Farm ID for our Consumer Farm
and create a text file with it. The Farm ID will need to be added to the Publishing
permissions on the Enterprise Farm so that we can access our services. To see
how this works, review the Testing and Troubleshooting portion of this document.
This demonstration is specifically designed to omit this part so that we can discuss
common issues.
# Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0
$publisher = "DEMOSP1"
$consumer = "DEMOSP2"
$path = "C:\Certs"
# Test and Create Path
If ((test-path $path) -eq $false)
{
[IO.Directory]::CreateDirectory("$path")
}
# Run the following to export the necessary certificates on the consumer
farm to c:\temp on the server:
$rootCert = (Get-SPCertificateAuthority).RootCertificate

$rootCert.Export("Cert") | Set-Content "C:\Certs\IntranetRootCert.cer" Encoding byte

$stsCert = (GetSPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate
$stsCert.Export("Cert") | Set-Content "C:\Certs\IntranetSTSCert.cer" Encoding byte
#On the consumer farm, run the following command to get the id of the
consumer farm:
$farmID = (Get-SPFarm).Id
New-Item C:\Certs\IntranetConsumerFarmID.txt -type file -force -value
"$farmID"
Copy-Item \\$consumer\c$\Certs\IntranetConsumerFarmID.txt
\\$publisher\c$\Certs

Swap the certs

We now have the certificates we need from both farms. We will now use
the Copy-Item cmdlet to take the EnterpriseServicesRootCert.cer and copy it to
the Consumer Farm. We then will need to copy the IntranetRootCert and
IntranetSTSCert certificates to the Enterprise Farm.
$publisher = "DEMOSP1"
$cconsumer = "DEMOSP2"
# Copy to Consumer
Copy-Item \\$publisher\c$\Certs\EnterpriseServicesRootCert.cer
\\$cconsumer\c$\Certs
Copy-Item \\$cconsumer\c$\Certs\IntranetRootCert.cer
\\$publisher\c$\Certs
Copy-Item \\$cconsumer\c$\Certs\IntranetSTSCert.cer
\\$publisher\c$\Certs

Enterprise (Publisher) Cert Import

We now want to import the two Intranet certificates on the Enterprise Farm
and establish a trust. We are required to use the Farm ID to set up our permissions.
We will rely on the text file we created a few steps back so that it is seamless.
#Run the following commands on the publisher farm to set up the trust
relationship with the consumer farm:
$trustCert = Get-PfxCertificate "C:\certs\IntranetRootCert.cer"
New-SPTrustedRootAuthority Intranet -Certificate $trustCert
$stsCert = Get-PfxCertificate "c:\certs\IntranetSTSCert.cer"
New-SPTrustedServiceTokenIssuer Intranet -Certificate $stsCert
$farmID = Get-Content C:\Certs\IntranetConsumerFarmID.txt
$security = Get-SPTopologyServiceApplication | Get-

SPServiceApplicationSecurity
$claimProvider = (Get-SPClaimProvider System).ClaimProvider
$principal = New-SPClaimsPrincipal -ClaimType
"http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" ClaimProvider $claimProvider -ClaimValue $farmID
Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights
"Full Control"
Get-SPTopologyServiceApplication | Set-SPServiceApplicationSecurity ObjectSecurity $security

Consumer Cert Import

We have one final step to wrap up concerning our certificates. On the
Consumer Farm, we will need to execute the following script to import the
EnterpriseServicesRootCert.
#Finally, run these commands on the consumer farm to set up the trust
relationship with the publisher farm:
$trustCert = Get-PfxCertificate
"C:\Certs\EnterpriseServicesRootCert.cer"
New-SPTrustedRootAuthority EnterpriseServices -Certificate $trustCert

Publishing the Services

Our two farms have been created, the Root certificate from our Enterprise
Farm has been imported on our Consumer Farm, the Root and STS certificates
from our Consumer Farm have been imported to our Enterprise Farm, and we have
used the Consumer Farm ID to establish a trust between the two farms. We are
now going to explore Central Administration and demonstrate how to publish our
services.
Our next step is to review our Service Applications. In this list, we should
find one of the six services that we wish to share. Highlight the service and then
click the Publish button in the Ribbon.

Figure 3 - Publishing Service Applications

We should now see a dialog box that allows us to select how we wish to
provide our service. Change the Connection Type to https and check the Publish
this Service Application to other farms.

Figure 4 - Publish Service Application Settings

Take note of the Publisher URL. There are a number of way we can use it;
each will be discussed when we configure the service from the Consumer Farm in
the next section.
urn:schemas-microsoftcom:sharepoint:service:1794d63150094e058fd73fb2a5c132b5#authority=urn:uuid:d5882dda1c0a
4f1291671dc4e847b1c7&authority=https://demosp1:32844/Topology/topology.svc

Consuming the Services

SharePoint offers us a couple of different paths to consumer services. We
will first highlight the Connect button in the Ribbon.

Figure 5 - Connect Service Applications

When clicking the Connect button in the Ribbon, we are presented a
Connect to a Remote Service Application dialog box. For our first demonstration,
we will grab the complete urn from the previous section and paste it into the Text
Box.

Figure 6 - Connect to a Remote Service Application

urn:schemas-microsoftcom:sharepoint:service:3884c36dcbaa4d76a864cc829594ec48
#authority=urn:uuid:b71719e7a4b448708535bfc8776e00c8&au
thority=https://DEMOSP1:32844/Topology/topology.svc
We will then hit OK and we will be presented with a specific service. This
is due to the service being specifically identified.

Figure 7 - Connect to a Single Service

We also have the opportunity to see all of the services that have been
published by simply using the https address.
https://DEMOSP1:32844/Topology/topology.svc

Figure 8 - Connect Using HTTPS Path

This is your certificates are set up correctly. We will visit this again in our
Troubleshooting section.

Figure 9 - Multiple Services

Finally, we can specify the type of connection we want to establish. This is
useful if the publisher has several Service Applications of the same typed being
shared and we only wish to review those.

Figure 10 - Explicit Connection

It is important to note here that we are using only the https path
https://DEMOSP1:32844/Topology/topology.svc
.

Figure 11 - Connect Explicit

The final result is that we only see Services Applications of the originally
specified type, as indicated below.

Figure 12 - Add Explicit Connection

Troubleshoot the Federated Service

Solution
There are a number of things that may impact our federated services. If the
server farms are located in different domains, the User Profile service application
requires both domains to trust one another. For the Business Data Connectivity
and Secure Store service application administration features to work from the
consuming farm, the domain of the publishing farm must trust the domain of the
consuming farm. Other cross-farm service applications work without a trust
requirement between domains.
Besides checking the domain trusts, we will also need to verify the
following:
Ensure Domain Trust
Consumer has permission to Topology Service
Check the ACL
FQDN
Certificates
Our demonstration has purposely left out configuring permissions to the
actual farm so that we can highlight a common issue we may see. Try to access
one of the services from the Consumer Farm.

Figure 13 - Troubleshooting
Notice that the error we see is The website declined to show this
webpage. We can correct this issue by visiting our Enterprise Farm and allowing
the Consumer Farm to use a particular service.

Figure 14 - Permissions
To configure the Consumer Farm permissions, highlight the service
application that you wish to configure and click Permissions. We will then get the
Farm ID of our Consumer Farm. If you recall from our PowerShell examples
discussed earlier, we created a text file that had the Consumer Farm ID and we
transferred it to the Publishing Farm. We can locate this file at c:\certs. Paste the

Farm ID into the Text Box and click Add. Then check the appropriate
permissions.

Figure 15 - Add Farm ID

We are now ready to test our service.

Test the Federated Service Solution

From the Consumer Farm, we are now able to interact with services. An
example of what you should see for the Managed Metadata Service is shown
below.

Figure 16 - Managed Metadata

The Term Store Management tool should appear as follows.

Figure 17 - Terms Store Management

Service application federation is a valuable tool when it comes to scalability and flexibility in a growing
SharePoint 2013 environment. If the need dictates for you to deploy a services farm, you should now have all the
tools to succeed in your deployment.