Configure a Trust Relationship Between Two SharePoint 2013 Farms

If you have the resources available, it is a great idea to have multiple SharePoint environments. Using one environment for your production web applications, and having a different farm for your test and development web applications can really help to keep the work items that are being developed in the test farm from messing up what is already working in the prod farm.

But just because you have two separate farms doesn’t mean that you have to do everything twice. You can take advantage of publishing service applications from one farm and subscribing to them in another farm. By doing this, you can have only one instance of search, or only one instance of a user profile service, and both farms can use them.

However, before you can publish any service applications and get them presented in a different farm, there are some prerequisites that have to be done. This article shows you how to create trusts between two SharePoint 2013 farms so that the publishing and subscribing to service applications is possible.

Why Create Trusts Between SharePoint Farms?

When you’ve got multiple farms, it can be tempting to just take the fast route and create a User Profile Service for each farm. The problem is that when your users are using a site in the test farm, they will have a completely separate user profile. The sites they’ve followed won’t be in their “Sites,” and their files won’t be in the “SkyDrive Pro” section of their profile. Even worse, when they choose to follow a site in the test farm, only the profile that they see when they’re using the test farm site will show the site that they just followed.

There’s something to be said for having a total separation between the farms. But if you want a more consistent experience for you users, it’s really not too hard to share the service applications between the farms.

Once shared, your documents in your SkyDrive Pro are available to you no matter which farm you’re currently logged into, and you can follow sites in either your test or your prod farm, and quickly get back to all of them no matter what farm you’re currently in.

Sponsored

Getting the service applications shared from your prod farm to your test farm is impossible without the farms first trusting each other. These trusts can be done through PowerShell or Central Administration, but I think it’s easier to do it with PowerShell so I’ll talk you through those steps now.

Setup SharePoint 2013 Servers for Remote PowerShell Connections

First, go to the server in the test farm either through a remote session or by remote desktop services. If you haven’t enabled your SharePoint servers to use CredSSP, you need to enable CredSSP on each SharePoint server you’re going to remotely connect to before you can successfully administer SharePoint from a remote PowerShell connection on your workstation.

On each of your SharePoint servers, run this command from an elevated PowerShell session:

Enable-CredSSP –Role Server

And then, on your workstation, run this in an elevated PowerShell session:

Enable-CredSSP –Role Client

We’re that now configured we can create the remote connections from our workstation. Use the credential for a farm administrator for creating the remote sessions.

Sponsored

Export the Certificates From Each Farm

Next, we need to export the certificates from each farm and move them into the other farm.

Each farm will have a root certificate, which is used to verify the identity of the farm itself. Additionally, the test farm, which will be the consumer of the services, will also export a Security Token Signing certificate, so that the production farm can verify that the sessions of the users are valid.

As you may suspect, the certificates that are exported don’t have to go directly to the other server. If you have a network share, you can export to and import from the network location.

Now that we have the certificates off of each farm and staged them where the other farm can easily get to them, we can create the trusts.

How to Create a Farm Trust in SharePoint 2013

This can also be done within Central Administration, but PowerShell really takes a lot of clicking out of the process.

Creating the trusts is done with using the New-SPTrustedRootAuthority cmdlet (for the farm trusts) and the New-SPTrustedServiceTokenIssuer (for the Secure Token Service trust).

We’ll need to create the trust in both farms for the Root certificates, and only in the prod farm for the Secure Token Service. This is because the users will be coming from the test farm, and that’s where their security tokens will be created and assigned. Those tokens must be trusted by the production farm for those users to be granted permission to use the service applications.

PowerShell

1

2

3

4

5

6

7

8

9

10

11

Invoke-Command–Session$TEST–Scriptblock{

$ProdRootCert=Get-PfxCertificateC:\TEMP\ProdFarmRoot.cer

New-SPTrustedRootAuthorityPROD–Certificate$ProdRootCert

}

Invoke-Command–Session$PROD–Scriptblock{

$TestRootCert=Get-PfxCertificateC:\TEMP\TestFarmRoot.cer

$TestStsCert=Get-PfxCertificateC:\TEMP\TestFarmSts.cer

New-SPTrustedRootAuthorityTEST-Certificate$TestRootCert

New-SPTrustedServiceTokenIssuerTEST-Certificate$TestStsCert

}

Trust Is an Important Thing

Trust is an important thing in a relationship between two SharePoint 2013 farms. Now that the trusts are in place, each server knows that when a connection is made to a server in another farm, that the server has a certificate present that proves it’s who it says it is. Additionally, the users that are in the TEST farm are issued a token that has been signed, and are now trusted by the services in the PROD farm.

The actual configuration for the publishing and subscribing to the Service Applications still has to be done. That part is not very difficult, and PowerShell will help a lot in that configuration as well.