Microsoft SharePoint 2010: Configure Cross-Farm Services

You can configure SharePoint to communicate across farm boundaries, sharing and consuming services from other server farms.

Shannon Bray

Microsoft has made a number of improvements to how SharePoint provides and consumes services. In SharePoint 2007, you had services available to you in what was known as the Shared Service Provider (SSP). While the SSP was a great step forward from what we had in SharePoint 2003, there were several challenges.

The primary issue with the architecture of SharePoint 2007 was that it was an all-or-nothing sort of configuration. Web apps were tied to a specific SSP and couldn’t consume services selectively. For example, if the SSP had both Search and Excel Service configured, any SharePoint Web application that consumed Enterprise Search also had to access Excel Services.

The SSP architecture wasn’t extensible, either. You couldn’t create your own services using the same SSP infrastructure. Finally—and most importantly—it was difficult to configure services cross-farm in SharePoint 2007. The new service architecture in SharePoint 2010 addresses all of these issues.

Understand the Service Application Architecture

Before diving into how to get services to communicate across SharePoint farm boundaries, it’s important to understand the components and services that make this possible. Here are some of the key characteristics of the Service Application architecture:

  • You can consume services “a la carte”
  • The service architecture is extensible
  • Services are supported on SharePoint Foundation
  • You can scale out services
  • Services can be resilient/redundant
  • ·You can federate services

Unlike services in SharePoint 2007, you now can decide which SharePoint Web applications consume your services. You’re no longer tied to the boxed-in SSP. You can pick and choose appropriate architectures.

The Service Application architecture is now extensible, meaning you can build your own custom services. This can save a tremendous amount of time, money and resources because you can deploy custom solutions that can operate across Site Collections or even SharePoint Web applications.

SharePoint 2010 doesn’t provide any services out of the box with SharePoint Foundation, but the infrastructure is there to support them. You can build your own services and use them in SharePoint Foundation. The new Service Application architecture lets you spread the load among several servers, allowing your designs to handle the appropriate load.

One of the most revamped services is Enterprise Search. In SharePoint 2007, the Index Server was a single point of failure. In SharePoint 2010, you can have your Search Crawl services span several servers. If one fails, you have redundancy and your system continues to operate as expected.

You can also now share services across farm boundaries. This lets you consolidate the services you want to share into a single farm, while still providing services to a number of consumers.

Understand 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 what’s happening behind the scenes, it’s 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.

Service Application: A logical component that contains the service configuration and management, like the service application 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, so the consumer knows which server to contact and how to consume the actual service. It’s 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.

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 shouldn’t use this for production environments. 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 your environment, but it can be tricky setting up many of the Service Applications. For a detailed understanding of how to provision the various SharePoint Services using Windows PowerShell, refer to “Automating SharePoint 2010 with Windows PowerShell 2.0” (Wiley, 2011) by Shannon Bray and Gary Lapointe.

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 their communications take place over HTTPS. It’s also important to know that Service Applications communicate over TCP ports 32843 and 32844. Custom Service Applications typically use port 32845.

Understand How Service Federation Works

Now that you have a good understanding of how services are federated, let’s take a look at the ones that support federation:

  • Search
  • User Profiles
  • Managed Metadata
  • Business Connectivity Services (BCS)
  • Secure Store
  • Web Analytics

There are a number of other services supported across a WAN. These include Search, Managed Metadata, Business Data Connectivity, User Profile and Secure Store. While they’re supported, only Search and Managed Metadata are recommended for use.

In a WAN environment, Search will have an increase in latency while crawling. BCS will experience slow first-time hits before the data is cached. The User Profile service has the User Profile Replication Engine, so working across a WAN is not recommended. When applications use Secure Store, it introduces latency.

Example Farms

For this example, we’ll be creating two farms. One will host the enterprise services; the other the Content Web applications. We’ll create both from scratch and outline each step so you know how to federate services in any environment.

The two farms will both be within the same domain, but can easily be built across domains as well. Because we’ll be using the same domain for these examples, you can build the demo with four servers: TechED-AD, TechED-SQL, TechEd-Services and TechEd-SP.

Begin by creating the appropriate accounts in Active Directory. The accounts are as follows: spFarm, spServices, spContent, spCrawl, spUPS and spC2WTS. To expedite the process, you can add accounts using Windows PowerShell from one of our SharePoint farms (see Figure 1 for more details). It’s important to note that we’ll create these accounts in the Managed Service Accounts Organizational Unit (OU), so if you aren’t starting off with Windows Server 2008 R2, you’ll need to change the CN location in the scripts in Figure1.

Figure 1 Adding SharePoint accounts 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("pass@word1") $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("pass@word1") $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("pass@word1") $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("pass@word1") $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("pass@word1") $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("pass@word1") $objUser.setinfo()

Now that we’ve set up the accounts, we’ll focus on the Enterprises Services environment. For the sake of this example, we’ll configure our Farm to include only services that support federation and can be quickly provisioned (Managed Metadata, BCS and Secure Store). To create the Enterprise Services environment, we’ll rely on Windows PowerShell to help with the heavy lifting. This is important because it ensures consistency and should leave you in a known state. Figure 2 will build the farm. We’ll provision the services shortly.

The script for setting up the Consumer Farm will be similar to the one shown in Figure 3.

Figure 2 Build the Enterprise Farm.

Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0 # Settings $databaseServer = "TECHED-SQL" $configDatabase = "Enterprise_Farm_Config" $adminContentDB = "Enterprise_Farm_Content_Admin" $passphrase = "pass@word1" $farmAccountName = "TECHED\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 2010 -WindowsAuthProvider NTLM Write-Host "Installing Help..." Install-SPHelpCollection -All Write-Host "Installing Application Content..." Install-SPApplicationContent Write-Host "Enterprise Farm Creation Complete!"

Figure3 Build the Consumer Farm.

Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0 # Settings $databaseServer = "TECHED-SQL" $configDatabase = "Consumer_Farm_Config" $adminContentDB = "Consumer_Farm_Content_Admin" $passphrase = "pass@word1" $farmAccountName = "TECHED\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 2010 -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

You can now create a number of services you intend to share with another farm. As mentioned earlier, you can federate six services. Build a couple of those here so you have something to build, as shown in Figure 4.

Figure 4 Provision Enterprise Services.

Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0 # App Pools $saAppPoolName = "SharePoint Web Services Default" $saAppPoolUserName = "TECHED\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 = "TECHED\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 = "TechED-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} | Start-SPServiceInstance Write-Host "Enterprise SSS Complete!"

Provision a Consuming Environment

All of the heavy lifting for the Publishing Farm is complete. Now we’ll focus on the farm that will use the Enterprise Services. You can create any services here. The most important thing to understand is that you can consume services from another farm and rely on that farm to provide those resources.

In the Consumer Farm, you’ll also be provisioning a SharePoint Content Web application that can be used to demonstrate Enterprise Services, as shown in Figure 5.

Figure 5 Provision SharePoint content.

# App Pools $saAppPoolName = "SharePoint Web Services Default" $saAppPoolUserName = "TECHED\spservices" $waAppPoolName = "SharePoint Content" $waAppPoolUserName = "TECHED\spcontent" # Web App details $mainURL = "http://teched-sp" $webAppName = "TechED Consumer" $contentDBName = "Consumer_Farm_Content_Web_Application" # Root Site Collection details $ownerEmail = "administrator@teched.com" $ownerAlias = "TECHED\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 -MaxSiteCount 50 -WarningSiteCount 30 <# Create Site Collection at root #> New-SPSite -Url $mainURL -owneralias $ownerAlias -ownerEmail $ownerEmail Write-Host "WebApp Complete!"

Configure the Certificates

Now the farms are complete. Next, we’ll publish the Enterprise Services we want to share with the Consumer. This can be done in a number of steps:

  • Create certificates on the Enterprise Farm
  • Create certificates on the Consumer Farm
  • Swap the certificates
  • Import the certificates on the Enterprise Farm
  • Import the certificates on the Consumer Farm

First you need to export the Root certificate from the Enterprise Farm. To do this, create a path to export the certificate (see Figure 6). After confirming the path, use the Get-SPCertificateAuthority cmdlet to export the certificate for your farm.

Figure 6 Create a path for a certificate.

# 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, not only does the Root certificate need to be exported, but also an STS certificate (see Figure 7). The latter is exported by using the Get-SPSecurityTokenServiceConfig cmdlet.

To ease this process, you’ll also get the Farm ID for your Consumer Farm and create a text file. Add the Farm ID to the Publishing permissions on the Enterprise Farm so you can access your services.

Figure 7 Export the STS certificate.

# Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0 $publisher = "TECHED-Services" $consumer = "TECHED-SP" $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 = (Get-SPSecurityTokenServiceConfig).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" #On the consumer farm, run the following command to copy the IntranetConsumerFarmID.txt to the publisher farm Copy-Item \\$consumer\c$\Certs\IntranetConsumerFarmID.txt \\$publisher\c$\Certs

Swap the Certs

Now you have the certificates you need from both farms. Use the Copy-Item cmdlet to take the EnterpriseServicesRootCert.cer and copy it to the Consumer Farm, then copy the IntranetRootCert and IntranetSTSCert certificates to the Enterprise Farm, as shown here:

$publisher = "TECHED-Services" $cconsumer = "TECHED-SP" # 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

Publisher Cert Import

Now you want to import the two intranet certificates on the Enterprise Farm and establish a trust. You have to use the Farm ID to set up permissions. Use the text file you created a few steps back so the process will be seamless and run the commands shown in Figure 8 on the Publisher Farm to set up the trust relationship with the Consumer Farm.

Figure 8 Establish a 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

There’s one final step concerning certificates. On the Consumer Farm, you need to execute the following script to import the EnterpriseServicesRootCert and 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

We’ve created the two farms, imported the Root certificate from the Enterprise Farm on the Consumer Farm, imported the Root and STS certificates from the Consumer Farm to the Enterprise Farm, and used the Consumer Farm ID to establish a trust between the two farms. Now we’ll explore Central Administration and publish the services.

The next step is to review the Service Applications. Find one of the six services you want to share, highlight it and then click the Publish button in the Ribbon. You’ll see a dialog box that lets you select how you wish to provide your service. Change the Connection Type to HTTPS, and check Publish this Service Application to other farms. Take note of the Publisher URL. There are a number of ways to use it.

Consuming the Services

SharePoint gives you a couple of different paths to consumer services. First, highlight the Connect button in the Ribbon. When clicking the Connect button in the Ribbon, you’ll see Connect to a Remote Service Application dialog box. Grab the complete URL from the previous section and paste it into the textbox. Click OK and you’ll see a specific service. This is due to the service being specifically identified. You can also see all the services published by simply using the HTTPS address.

This will help confirm that your certificates are set up correctly. Finally, specify the type of connection you want to establish. This is useful if the publisher is sharing several of the same type of Service Applications. It’s important to note that you’re only using the HTTPS path. The final result is that you only see Services Applications of the originally specified type.

Troubleshoot the Federated Service Solution

A number of things can affect your federated services. Networking, firewalls and infrastructure impediments are several things to consider. 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, you also need to verify the following:

  • Ensure domain trust
  • Ensure the consumer has permission to Topology Service
  • Check the ACL
  • FQDN
  • Certificates

As a further example, try to access one of the services from the Consumer Farm. Notice the error is “The Web site declined to show this Web page.” You can correct this issue by visiting your Enterprise Farm and allowing the Consumer Farm to use that particular service.

To configure Consumer Farm permissions, highlight the service application you wish to configure and click Permissions. You’ll get the Farm ID of your Consumer Farm. If you recall, you created a text file that had the Consumer Farm ID. You transferred it to the Publishing Farm. Locate this file at c:\certs. Paste the Farm ID into the textbox and click Add. Then check the appropriate permissions. Now you’re ready to test your service.

Test the Federated Service Solution

From the Consumer Farm, you should be able to interact with services. For this lab environment, you’ll be using four Hyper-V images. Two of the images will be for the hosting environment and two for the consuming environment. You can easily expand the number of servers, but due to hardware restrictions on demo environments, it’s easiest to use one server for Active Directory and share the SQL Server and SharePoint 2010 roles on the other.

While it isn’t critical to follow each of these steps exactly, it’s recommended to ensure a consistent result. The network configuration is outside the scope of this document, but you can find it on my blog.

Each of the servers has been configured with the following settings:

Server Name: TechED-AD IP Address 192.168.110.1

Domain: TechED.local Forest Functional Level Windows Server 2008 R2

Administration Password: pass@word1

 

Server Name: TechED-SQL IP Address 192.168.110.2

Domain:  TechED.local Forest Functional Level Windows Server 2008 R2

Administration Password: pass@word1

 

Server Name: TechED-Serives IP Address 192.168.110.11

Domain: TechED.local Forest Functional Level Windows Server 2008 R2

Administration Password: pass@word1

 

Server Name: TechED-SP IP Address 192.168.110.12

Domain: TechED.local Forest Functional Level Windows Server 2008 R2

Administration Password: pass@word1

Once you’ve built the four machines, create a new domain forest on the Domain Controller (DC). The domain for this example will be TechED.local. In order to promote the servers to DCs, use the DCPromo utility. Use the previously noted settings to assign the appropriate IP Addresses to the network cards and rename the computers as appropriate.

Once you’ve established the DCs and configured their IP addresses, you can now join the servers that will be hosting SQL Server and SharePoint 2010. Enable the Windows PowerShell Integrated Scripting Environment, or ISE, feature on each of the servers hosting SQL Server and SharePoint. This makes managing Windows PowerShell much easier.

Now install SQL Server 2008 R2 on the TechED-SQL server (see Figure 9). You should have the proper .iso downloaded on your host machine so you can attach it to the virtual machine using Media | DVD Drive | Insert Disk.

Figure 9 Install SQL Server.

# Set Exec Policy Set-ExecutionPolicy -executionPolicy Unrestricted # Add SQL Service Account to AD $domainName = $env:USERDOMAIN $LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local" $objCN = [ADSI]$LDAP $objUser = $objCN.Create("user","CN=SQL Service") $objUser.Put("sAMAccountName","sqlService") $objUser.Setinfo() $objUser.psbase.invokeset("AccountDisabled", "False") $objUser.SetPassword("pass@word1") $objUser.setinfo() # Install SQL Server with the following settings # Disable Firewall # # SQL Server Feature Installation # Check … # Database Engine Services, SQL Server Replication, Full-Text Search # Business Intelligence Development Studio # Management Tools - Complete # Microsoft Sync Framework # ----------------------------- # Default Instance # Use account above for all services # Select Windows Authentication Mode and click Add Current User # Complete Wizard

Once you’ve installed TechED-SQL, install only the SharePoint prerequisites and the binaries. Do not run the wizard. And before doing anything else, you should take a snapshot of all four machines. Better safe than sorry.

Shannon Bray

Shannon Bray is a SharePoint evangelist and Microsoft Certified Trainer. He is currently employed with Planet Technologies as a technical architect and works exclusively with Microsoft SharePoint. Bray specializes in architecture design and solution development using Microsoft technologies. He’s the President of the Colorado SharePoint User Group and has presented SharePoint topics at Microsoft TechReady and Tech·Ed. Bray has authored several SharePoint video training series and is currently coauthoring “Automating Microsoft SharePoint 2010 Administration with Windows PowerShell 2.0.” (Wiley, 2011)