1. 04 | Planning and Provisioning Service Applications
Jason Lee | Chief Technologist at Content Master
Christina Singletary | Senior Content Developer at Microsoft

2. Module Overview Service application fundamentals
Planning a service application topology
Provisioning service applications
Managing proxy groups
Configuring service application federation

3. Service Application Fundamentals
Let’s look at some of the concepts behind service applications in SharePoint 2013.

4. What Are Service Applications?
Flexible way of delivering services to web applications
Search
Managed metadata
User profiles
Within a farm or between farms
Logical concept that encompasses
Service instances
WCF endpoints
Databases and caches
Keep this brief – subsequent slides go into more detail

5. SharePoint 2013 Service Applications
Access Services
Access Services 2010
Excel Services
Performance-Point
Visio Graphics Service
Enterprise Edition
Machine Translation Service
PowerPoint Conversion
Secure Store Service
Word Automation Services
Standard Edition
Managed Metadata Service
Search
State Service
User Profile
Work Management
Click 1 – SharePoint Foundation 2013 provides…
Click 2 – four service applications. (Talk through them briefly). (NB – Subscription Settings Service manages tenancies, and it’s important for SharePoint apps and various other features)
Click 3 – SharePoint Server 2013, Standard Edition provides…
Click 4 – a further nine service applications. (Talk through a few examples – e.g. Managed Metadata, Search, User Profile)
Click 5 – SharePoint Server 2013, Enterprise Edition adds…
Click 6 – a further five service applications. These provide the Business Intelligence functionality that the enterprise edition adds.
Talk briefly about some of the dependencies between service applications. Draw on screen if you can. For example:
The State Service stores temporary data between web requests for various other service applications. For example, MMS, Search, User Profiles and most of the BI service applications all rely on the state service.
Business Data Connectivity service application and App Management Service application both rely on the Subscription Settings Service.
Business Data Connectivity service application and the BI service applications rely on the Secure Store Service if you want to use alternative credentials to access data sources.
Business Data Connectivity
Subscription Settings
Service
App Management Service
Usage and Health Data Collection
Foundation

6. Service Application Architecture
Service Instance
Service Instance
Application Pool
WCF Endpoint
WCF Endpoint
Start – we’ve got a service application, which is a logical concept rather than a physical entity.
Click 1 – a service application includes at least one service instance. A service instance runs on a specific server, and provides the functionality of the service application.
A service instance includes [Click 2] a WCF endpoint that allows other components to sent requests to and communicate with the service application.
You can provide scalability and high availability for a service application by [Click 3] starting the underlying service instance on additional servers. SharePoint automatically [Click 4] load balances requests across service instances.
The WCF services provisioned by service applications run within [Click 5] an IIS application pool. The standard approach is to run all your service applications within the same application pool, although you can use additional application pools if you require process isolation.
Service applications also typically include one or more [Click 6] databases, and some of them also use [Click 7] disk-based caches.
Every service application also provisions an [Click 7] administration page that enables you to manage the service application from the Central Administration website.
Databases
Cache
Administration Pages

7. Consuming Service Applications
Service Application Proxy
Proxy Group
Let’s look at how we consume service applications from web applications.
To use the services provided by a service application, you first need to create [Click 1] a local Service Application Proxy – also known as a Service Application Connection. The idea of a service application proxy is that you consume the service in a consistent way, regardless of whether the service application itself is on the local farm or on a remote farm somewhere. (When you create a service application through the Central Administration website, SharePoint will automatically create a local proxy for you. If you create a service application in PowerShell, you have to create the proxy yourself).
The next thing you need to do is create [Click 2] a proxy group. A proxy group is just a collection of service application proxies. Each proxy group can contain multiple service application proxies, and each proxy can belong to multiple proxy groups.
Finally, in your web application settings, you choose which proxy group you want to associate [Click 4] with the web application. Each web application is associated with one proxy group, and that determines which services are available to sites within the web application.
When you create service applications through Central Administration, the proxies are automatically added to a default proxy group (named “default”). Web applications automatically use the default proxy group unless you tell them otherwise. A bit later on we’ll look at the reasons why you might want to create more than one proxy group.
Service Application
Web Application

8. Planning a Service Application Topology
Now let’s take a look at some of the planning and design considerations when you roll out service applications.

9. Single Farm, Single Proxy Group
Service Application 1
Service Application 2
Service Application 3
Service Application Proxy 1
Service Application Proxy 2
Service Application Proxy 3
Suppose you’ve got a set of local service applications, each with a local proxy, and various web applications.
The simplest configuration is to create a single proxy group [Click 1] (or use the default proxy group) and connect all of your web applications to it [Click 2].
Discussion points – advantages and disadvantages:
The main advantage of this approach is simplicity. It’s easy to set up and easy to manage. You also retain some degree of control – when you associate a proxy group with a web application, you can choose which of the proxy group members you want to make available to the web application. In other words, just because a service application is in a proxy group doesn’t mean that you have to make it available to every web application that’s associated with the proxy group.
One possible disadvantage of this approach is scalability. There is no separation of services according to the requirements of different areas of the business. For example, a European division might want their user profiles configured differently to the North American division, and this approach doesn’t allow you to do that. This approach also makes it harder to provide isolation – for example, you might not want a public-facing web application to share services with a secure internal web application.
Web Application
Web Application
Web Application

10. Single Farm, Multiple Proxy Groups
Service Application 1
Service Application 2
Service Application 3
Service Application Proxy 1
Service Application Proxy 2
Service Application Proxy 3
Another approach is to create more than one proxy group [Click 1] [Click 2] for your local service proxies. You can then choose which proxy group to associate with each web application [Click 3].
Discussion points – advantages and disadvantages:
This approach gives you more flexibility. For example, suppose you’ve got two Managed Metadata service applications – one that provides general term sets for use across the organization, and one that provides specialized term sets for use within, say, a research division. You can use proxy groups to control which term stores are made available to which web applications. This approach allows you to provide greater isolation of services, and might allow you to delegate administration for specialized service applications to specific business units.
On the downside, your service application topology is more complex, and if you’re providing multiple instances of service applications you’ll require more hardware resources.
Web Application
Web Application
Web Application

11. Multiple Farms Farm A Farm B Service Application A1
Service Application B3
Service Application Proxy A1
Service Application Proxy A2
Service Application Proxy A2
Service Application Proxy B3
The third scenario involves sharing services between multiple farms. In this example, Farm A contains two service applications with local proxies, and Farm B contains one service application with a local proxy.
If we configure a trust relationship between the farms, we can create a proxy on Farm B [Click 1] that connects to a service application on Farm A [Click 2]. You can then create proxy groups in the usual way [Click 3] and connect them up to your web applications [Click 4].
Not all service applications support this kind of federation across farm boundaries, and we’ll take a closer look at this later on. For now, it’s worth just being aware of the possibilities. For example, if you have a set of geographically-dispersed SharePoint farms, you could use a single farm to provide a universal search service to SharePoint users regardless of their location.
Web Application
Web Application
Web Application
Web Application

12. Application Pools for Service Applications
One application pool for all service applications is standard approach
Use additional application pools only where process isolation is required
Application pool identity must be a managed account
A few brief points on planning application pools for service applications:
The standard approach is to use one application pool for all your service applications.
You can use different application pools for different service applications if you require process isolation – but bear in mind that IIS supports a maximum of 10 application pools on each server.
Finally, note that the application pool identity for service applications must be a managed account. You’ll remember from earlier modules that a managed account is simply a domain account whose credentials are owned by SharePoint.

13. Key Planning Considerations
Required applications
Isolated services
Multiple instances
Performance
Multiple farms/centralized services
So the key things you want to think about when you’re planning a service application topology are:
Which service applications you require. Don’t just provision them all. Analyze your business requirements and map those requirements to functionality provided by services applications.
Do you need isolated instances of any of these service applications, such as specialized term stores or specialized user profiles.
Do you need to provide scalability or high availability by provisioning multiple service instances for specific service applications.
How will you deliver an acceptable level of performance – this might involve provisioning dedicated servers to host resource-intensive service instances such as Excel Services or the Visio Graphics Service.
Are you deploying multiple farms, and do you need to share services between farms.

14. Provisioning Service Applications
Now let’s take a look at how we actually get these service applications up and running.

15. Provisioning Service Applications
Central Administration
Manage Service Applications > New
Start services on additional servers as required
PowerShell
Provision any required databases
Provision the service application
Provision a service application proxy
Application-specific guidance
Configure services and service applications in SharePoint 2013
Mention that the precise steps to provision a service application vary according to which service application you’re provisioning, but the basic process is as follows.
[Click 1] You can use the Central Administration website – on the Manage Service Applications page, you click New and then choose which type of service application you want. SharePoint will prompt you for all the required information and then get everything set up – the service application, any required databases, and a local proxy. You can then scale out your service by starting the service instance that corresponds to your service application on additional servers.
[Click 2] If you use PowerShell, you have to do a little more work but you have a lot more control. Typically you need to run cmdlets to create any required databases, provision the service application itself, and then create a local proxy for the service application.
[Click 3] While the basic process is the same for most service applications, the precise configuration steps do vary slightly from application to application. For more information on specifics, see this page on TechNet – it has links to individual procedural walkthroughs for each service application.

16. Provisioning Service Applications
Part I – Provisioning Service Applications using Windows PowerShell
Prerecorded demo: DeployingSharePoint2013_M4_D1_Part1.mp4
In this demo we’ll use PowerShell to configure a State service application.
Why State service application?
You can’t provision it in Central Administration – either it gets created by the farm configuration wizard when you first run Central Administration, or you use PowerShell.
In most cases it’s the first service application you should create. Many other service applications – Search, Managed Metadata, all the Business Intelligence service applications – all depend on the state service.
Steps:
Run PowerShell ISE as administrator, then:
Add-PSSnapin Microsoft.SHarePoint.PowerShell
$database = New-SPStateServiceDatabase –Name “SharePoint_ContosoStateServiceDB”
$sa = New-SPStateServiceApplication –Name “Contoso State Service” –Database $database
New-SPStateServiceApplicationProxy –Name “Contoso State Service” –ServiceApplication $sa
Point out that the state service application is a special case – there’s no service instances, no application pool – it’s basically a container for one or more state service databases. The SharePoint farm account uses it to store data relating to web requests on a temporary basis.
Part II – Provisioning Service Applications using Central Admininstration
Prerecorded demo: DeployingSharePoint2013_M4_D1_Part2.mp4
In this demo we’ll use Central Administration to configure a Managed Metadata service application.
Create the service application using the wizard
Management options:
Manage. This opens the term store.
Administrators. This allows you to assign people to manage settings. Add a user, e.g. Anthony Frizzell.
Properties. Allows you to reconfigure various properties of the service application.
Publish and Permissions. These are used for sharing services between farms, which we’ll come onto a bit later.
Browse to Services on Server page, and point out that you can provide high availability by starting the service instance on another server. SharePoint does the rest.
Provisioning Service Applications

17. Managing Proxy Groups
Now let’s take a look at how we can manage our proxy groups.

18. Managing Proxy Groups Create and delete proxy groups
New-SPServiceApplicationProxyGroup
Remove-SPServiceApplicationProxyGroup
Add or remove proxies to or from a proxy group
Add-SPServiceApplicationProxyGroupMember
Remove-SPServiceApplicationProxyGroupMember
Options for managing proxy groups in the Central Administration website are pretty limited, so you will end up using PowerShell.
For creating and deleting proxy groups, you can use the New-SPServiceApplicationProxyGroup and the Remove-SPServiceApplicationProxyGroup cmdlets.
Once you’ve created a proxy group, you can add or remove proxies using the Add-SPServiceApplicationProxyGroupMember and Remove-SPServiceApplicationProxyGroupMember cmdlets.

19. Prerecorded demo DeployingSharePoint2013_M4_D2.mp4
Open Central Admin. Show lots of service applications.
Open PowerShell ISE as admin
Show contents of the default proxy group:
$defaultProxyGroup = Get-SPServiceApplicationProxyGroup | ?{$_.FriendlyName –eq “[default]”}
$defaultProxyGroup.DefaultProxies | Format-Table -Wrap
Open the script at C:\Scripts\ProxyGroups.ps1 and step through it
Browse to Central Administration > Web Application settings > Service Application Associations
Associate the Intranet web application with the Intranet Services proxy group
Point out that you can edit which proxies you use from the group
Managing Proxy Groups

20. Configuring Service Application Federation
Now let’s take a look at service application federation – in other words, how we share service applications between SharePoint farms.

21. Which Service Applications Can I Federate?
Business Data Connectivity
Machine Translation
Managed Metadata
User Profile
Search
Secure Store
Keep this brief.
You can federate the following service applications between SharePoint farms: [list]
Discussion points, if required: For the service applications that don’t support federation, there’s usually a fairly obvious reason why federation would be a bad idea. E.g. the business intelligence service applications tend to rely on disk-based caching of large amounts of data, and you don’t want to be transferring that between farms. Other service applications- app management, subscription settings, usage and health data collection – enable very specific functionality on a farm and there would be no point in federating.

22. Why and When to Federate Services
Why federate service applications?
Use resources efficiently
Centralize service management
Avoid duplicating functionality on multiple farms
WAN environments
Suitable: Search, Managed Metadata, Machine Translation Services
Variable: Business Data Connectivity
Unsuitable: User Profile, Secure Store
Reasons for federating service applications:
In some scenarios it’s the most efficient way to use hardware resources
In larger organizations you may want to centralize management of service applications
Avoid duplicating functionality on multiple farms. This doesn’t just apply to hardware – for example, you might have managed metadata term sets that apply to your whole organization. You wouldn’t want to have to maintain these term sets in two different places.
Service federation isn’t always a good idea over for deployments that are distributed over Wide Area Networks. This is due to request latency.
Generally, Search, Managed Metadata, and Machine Translation Services work well over a WAN.
Business Data Connectivity can be problematic, and that largely depends on where your line-of-business data sources are located on the network.
Best practice is to avoid federating the User Profile Service Application or the Secure Store Service over a WAN.

23. Configuring Service Application Federation
Configure trust relationships
Publish the service application on the provider farm
Set permissions on the service application on the provider farm
Connect to the published service application on the consumer farm
Add the proxy for the published service application to a proxy group on the consumer farm
Once you’ve identified the need to federate service applications between farms, there’s a few high-level tasks you need to complete.
First, you need to configure trust relationships between the two farms. Basically, the farm that’s providing services needs to trust the farm that’s consuming services as a security principal.
Next, you need to publish the service application on the provider farm, so that it’s available to other farms.
On the provider farm, you need to grant permissions on the published service application to the security principal that represents the consumer farm.
You can then connect to the remote service application from the consumer farm
And add the proxy for the remote service application to a local proxy group.
Let’s take a look at these steps in a little more detail.

24. Configuring Trust Relationships
Provider farm must trust consumer farm
On the consumer farm:
Register the provider farm as a trusted root authority
On the provider farm:
Register the consumer farm as a trusted root authority
Register the consumer farm as a trusted service token issuer
Certificate exchange
Manually export certificates and copy between farms
Use metadata endpoints
[Click 1] Trust relationships are essentially one way. To configure a trust relationship for service application federation, the farm that’s providing services must trust the farm that’s consuming services. By trust, we mean that the provider farm recognizes the consumer farm as a security principal and can grant permissions to it. To make this happen:
[Click 2] On the consumer farm, you need to register the provider farm as a trusted root authority.
[Click 3] On the provider farm, you need to register the consumer farm as a trusted root authority and as a trusted service token issuer. A service token is what the consumer farm will send when it’s requesting information from a service application.
[Click 4] To make this happen, you need to exchange various certificates between the two farms. You can do this in two ways. The 2010 way was to manually export the certificates and copy them between the farms. In SharePoint 2013, there is a better alternative. SharePoint web applications publish metadata endpoints. These are essentially URLs that provide serialized versions of the certificates you need in JSON format – so instead of manually exporting and copying certificates, you can just point the relevant PowerShell cmdlets to the remote metadata endpoints.

25. Configuring Trust Relationships
Provider Farm
Consumer Farm
SharePoint Root Certificate
> New-SPTrustedRootAuthority
SharePoint STS Certificate
> New-SPTrustedServiceTokenIssuer
And this is how it works.
You use the [Click 1] SharePoint Root certificate from the consumer farm to register a new trusted root authority on the provider farm, using the New-SPTrustedRootAuthority cmdlet.
You use the [Click 2] SharePoint Security Token Signing certificate from the consumer farm to register a new trusted service token issuer on the provider farm, using the New-SPTrustedServiceTokenIssuer cmdlet.
You use the [Click 3] SharePoint Root certificate from the provider farm to register a new trusted root authority on the consumer farm, using the New-SPTrustedRootAuthority cmdlet.
As we mentioned on the previous slide, for all these cmdlets, you can either provide them with a physical certificate that you’ve exported and copied over from the remote farm, or you can provide them with a metadata endpoint URL on the remote farm.
SharePoint Root Certificate
> New-SPTrustedRootAuthority

26. Configuring Trust Relationships
On the consumer farm:
New-SPTrustedRootAuthority
–Name “Provider Farm Name”
–MetadataEndpoint “
On the provider farm:
New-SPTrustedRootAuthority
–Name “Consumer Farm Name”
–MetadataEndpoint “
New-SPTrustedServiceTokenIssuer
–Name “Consumer Farm Token Issuer”
–MetadataEndpoint “
I just wanted to briefly highlight what these metadata endpoint URLs look like.
You’ll find the SharePoint root certificate at the following relative URL (draw on screen if possible) - /_layouts/15/metadata/json/1/rootcertificate.
The token-signing certificate is at the following relative URL (draw on screen if possible) - /_layouts/15/metadata/json/1 – same URL, but without “rootcertificate” on the end.
A couple of warnings at this point:
These URLs are exposed on each web application. As such, they’re only available if you’ve got at least one web application on the farm.
If you’re using http rather than https, you will need to perform some additional steps to configure the SharePoint Security Token Signing service to allow OAuth over HTTP. That’s all well-documented on TechNet, so for the demo coming up we’re going to assume you’re using https.

27. Publishing Service Applications
Central Administration
Manage Service Applications > Publish
PowerShell
Publish-SPServiceApplication –Identity <ServiceApplicationGUID>
Briefly
Publishing a service application is very straightforward – you can either publish it by clicking a button on the Manage Service Applications page in Central Admin, or you can use the Publish-SPServiceApplication cmdlet in PowerShell.

28. Configuring Permissions
The consumer farm must have:
Relevant permissions on the service applications you are publishing on the provider farm
Full Control permissions on the Application Discovery and Load Balancer service application on the provider farm
Retrieve the GUID-based farm ID of the consumer farm
Use the farm ID to grant permissions on the provider farm
You also need to configure some permissions on the farm that’s providing services. You need to grant the consumer farm relevant permissions on any service applications you are publishing, AND you need to grant it Full Control permissions on the Application Discovery and Load Balancer service application. Basically, when your consumer farm connects to the provider farm, the Application Discovery and Load Balancer service application tells it which services are available.
To grant these permissions, you need to retrieve the farm ID of the consumer farm, which is a GUID
You can then use this GUID to grant permissions on the provider farm – basically, if you’ve configured the trust relationship between the farms, the GUID ID of the consumer farm will resolve to a claims-based identity on the provider farm and allow you to assign permissions. You’ll see all of this in the demo shortly.

29. Consuming Published Service Applications
Use the Service Application URI to connect a service application proxy on the consumer farm
For this to work:
Trust relationship must be configured
Service application must be published
Permissions must be configured
Finally – to consume a published service application, you need to create a local service application proxy on the consumer farm. To do this, you need the URI of the published service application (you’ll see how to get this in a second).
This final step will only work properly if:
-you’ve configured the trust relationship between the two farms correctly
-you’ve published the remote service application
-you’ve granted the necessary permissions on the remote service application

30. Configuring Service Application Federation
So now let’s take a look at the end-to-end process for sharing a service application between two SharePoint farms.
Part 1 – Configure trust on the consumer farm
Prerecorded demo DeployingSharePoint2013_M4_D3_Part1.mp4
On the consuming SharePoint farm, register the provider farm as a trusted SharePoint root authority
Part 2 – Configure trust on the provider farm
Prerecorded demo DeployingSharePoint2013_M4_D3_Part2.mp4
On the provider farm, register the consumer farm as a trusted SharePoint root authority and a trusted service token issuer
Part 3 – Publish service applications
Prerecorded demo DeployingSharePoint2013_M4_D3_Part3.mp4
On the provider farm, publish the MMS service application. Save the service URI in a text file in a file share
Part 4 – Configure permissions
Prerecorded demo DeployingSharePoint2013_M4_D3_Part4.mp4
On the consumer farm, use PowerShell to get the farm ID and write it to a text file on a file share
On the provider farm, open the text file and copy the GUID
Browse to Central Admin
Grant permissions on the Application Discovery and Load Balancer service application
Grant permissions on the Contoso Global MMS service application
Part 5 – Connect to the published service
Prerecorded demo DeployingSharePoint2013_M4_D3_Part5.mp4
On the consumer farm, open the text file and copy the service URI
Connect to the Contoso Global MMS service
Demonstrate that you can browse the term store
Configuring Service Application Federation

31. Module Review Service application fundamentals
Planning a service application topology
Provisioning service applications
Managing proxy groups
Configuring service application federation