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

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

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

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

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

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

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

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.

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

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

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

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.

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.

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

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 https://technet.microsoft.com/library/ee794878.aspx 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.

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

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

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.

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

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.

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.

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.

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.

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.

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

Configuring Trust Relationships On the consumer farm: New-SPTrustedRootAuthority –Name “Provider Farm Name” –MetadataEndpoint “https://provider.contoso.com/_layouts/15/metadata/json/1/rootcertificate” On the provider farm: New-SPTrustedRootAuthority –Name “Consumer Farm Name” –MetadataEndpoint “https://consumer.contoso.com/_layouts/15/metadata/json/1/rootcertificate” New-SPTrustedServiceTokenIssuer –Name “Consumer Farm Token Issuer” –MetadataEndpoint “https://consumer.contoso.com/_layouts/15/metadata/json/1” 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.

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.

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.

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

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

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