MCT USE ONLY. STUDENT USE PROHIBITED Planning a Service Application Architecture 2-21 intranet site. Administrators can use the Service Applications page to change the protocol and port binding for each service application. Communication between service applications and Microsoft SQL Server® takes place over the standard SQL Server ports or the ports that you configure for SQL Server communication. For the following service applications, information is cached to improve performance: • Access Services • Excel Services • PerformancePoint Services • Word Automation Services The Visio Graphics Service uses a binary large object (BLOB) cache, which provides higher performance when it renders large drawings. Question: What is the default port number for service application communication over HTTPS? MCT USE ONLY. STUDENT USE PROHIBITED 2-22 Designing a Microsoft® SharePoint® 2010 Infrastructure Service Application Components Key Points A service application is made up of a number of components that work together to deliver service functionality to the end user. Service Application Connection (Proxy) When you deploy a service application, you create a service application connection. This connection is more commonly known as a proxy. The proxy manages the connection information so that the service application can communicate with service requests from service consumers, such as Web Parts. You can link and manage service applications against individual Web applications. This means that you have the flexibility to deploy multiple service application instances, which you can isolate to match performance or security requirements. You should remember that by default, service applications are associated with all of the Web applications on a farm, so you have to specifically associate service applications to Web applications. You can manage proxies through the SharePoint Central Administration site or by using Windows PowerShell. MCT USE ONLY. STUDENT USE PROHIBITED Planning a Service Application Architecture 2-23 Service Application Proxy Groups SharePoint 2010 groups service applications together for Web application consumption through proxy groups. These are simply groupings of service applications that you can deploy to different Web applications. This may seem trivial, but this is an important design mechanism for solution architects for grouping and isolating service applications. By default, all service applications are placed in the Default group. This means that all users in Web applications that consume services from the Default group have access to the group members. However, you can create custom groups, to which you can add services that you want to provide to a specific Web application. When you create a Web application and choose a custom group, only that Web application can consume the services. If you create a new service application through the Administration UI, it is added to the Default group. However, you can move service applications to other groups or change their association with Web applications. When you use Windows PowerShell to create a new service application by using the new-spserviceapplicationproxygroup cmdlet, the service does not automatically join the Default group—you must add the –default switch. A Web application does not have to consume all of the services in a proxy group; you can configure this through the Configure Service Application Associations page on the SharePoint Central Administration site. Databases One of the biggest surprises for designers and database administrators (DBAs) who are familiar with Office SharePoint Server 2007 is the large number of databases that are associated with service applications. If you upgrade an Office SharePoint Server 2007 farm to SharePoint 2010, these are automatically generated for each upgraded or new service. The system-generated names for these databases are not easy to relate to the service application. For easier management and recognition, you should define your own database names for your service application databases. In addition to naming, you should be aware of the potential size to which these databases can grow. For example, the Usage and Health Data Collection database can become very large if you use the out-of-the-box configuration. It will log approximately 2 gigabytes (GB) of data for 1 million HTTP requests. This database may grow to an enormous size if you do not reconfigure it to limit either the range of captured information or the length of time that you store this information. As a result of this potential for growth and the associated write activity, you should also consider putting this database on a separate disk. MCT USE ONLY. STUDENT USE PROHIBITED 2-24 Designing a Microsoft® SharePoint® 2010 Infrastructure Some service applications have multiple associated databases, such as the User Profile Service and the Search Service. MCT USE ONLY. STUDENT USE PROHIBITED Planning a Service Application Architecture 2-25 Logical Architecture of Service Applications Key Points The logical architecture of service applications is an important element of design. There are some service application–specific configuration or deployment options, but it is useful to understand how you can deploy services. The slide shows a series of nonspecific service applications in a sample SharePoint 2010 farm. This is a simple configuration with: • One farm. • One service application application pool. • Two Web application application pools. • Three Web applications. The service applications are all deployed in a single Internet Information Services (IIS) Web site, which is the default requirement for SharePoint 2010. The design of this solution has two proxy groups: the Default proxy group and the custom proxy group. Although the default action is to have service applications in MCT USE ONLY. STUDENT USE PROHIBITED 2-26 Designing a Microsoft® SharePoint® 2010 Infrastructure the Default proxy group, it is not mandatory. Some of the service applications are in a custom group, and one is not in the Default proxy group at all. Service applications can also be in more than one proxy group. This means that you can share services among Web applications without having to share all of them. In this case, service application X is isolated so that only users who are associated with Web application A can use it. It is possible to create separate application pools to separate the service applications at the process level. Notice that there are multiple instances of service application Y in the Default proxy group. This provides greater performance, because these instances are on separate physical servers and can therefore provide load balancing. This configuration will also ensure greater resilience, because the service application will still be available even if there is a single server failure. You may isolate service applications for security purposes and this isolation is done at the process level only. If performance is the reason for isolating this service application, you can include additional instances. MCT USE ONLY. STUDENT USE PROHIBITED Planning a Service Application Architecture 2-27 Cross-Farm Service Applications Key Points Although you can share all service applications across Web applications, there are only six that you can share across farms: • User Profiles Service • Managed Metadata Service • Business Connectivity Services • Search Service • Secure Store Service • Web Analytics Service The first four are most commonly shared across farms. In your design, you should assess the options for sharing one or more of these if you decide to deploy multiple farms. MCT USE ONLY. STUDENT USE PROHIBITED 2-28 Designing a Microsoft® SharePoint® 2010 Infrastructure Factors that may encourage you to share service applications between farms may include: • A requirement to minimize management overhead for popular services, such as search. • A decision to create a service farm to centralize resource management. • A requirement to share an organization-wide resource—such as a taxonomy— through the Managed Metadata Service. The cross-farm sharing process has a number of elements that you must plan and execute prior to deployment: • Configure trusted farms. Farms must exchange security certificates. • Publish the service applications. On the sharing farm, you must publish the service application so that external farms can consume it. You use the Application Management page to do this. • Connect to cross-farm service applications. On the consuming farm, you must create a connection to the published service. This uses the URI that is generated in the publishing process. • Set appropriate permissions. The consuming farm must have permission to the Application Discovery and Load Balancing Service Application on the publishing farm. It must also have permissions to the service that it will consume. An additional level of planning is necessary for farms that are located in different domains. You must ensure that the following conditions are in place to share these service applications: • User Profile Service. To share the User Profile Service, you must configure two- way trust between domains. • Business Data Connectivity Services. The publishing farm domain must trust the consuming farm domain for an administrative feature to function. • Secure Store Service. The publishing farm domain must trust the consuming farm domain for an administrative feature to function. MCT USE ONLY. STUDENT USE PROHIBITED Planning a Service Application Architecture 2-29 External Data Source Access Key Points It is common to implement delegated Windows identities when a service application must use an impersonated identity to access remote resources. The service applications that use delegated Windows identity are: • Excel Services • InfoPath Forms Services • PerformancePoint Services • Visio Services If the service application and the target external data are not in the same domain, you can configure these service applications to use the Secure Store Service to provide managed user or service credentials. Without the Secure Store Service configured, it is not possible for these services to successfully authenticate to gain access to the external data. MCT USE ONLY. STUDENT USE PROHIBITED 2-30 Designing a Microsoft® SharePoint® 2010 Infrastructure This does not affect other services that access external data, such as the Business Connectivity Services. . the large number of databases that are associated with service applications. If you upgrade an Office SharePoint Server 2007 farm to SharePoint 2 010 , these are automatically generated for each. that by default, service applications are associated with all of the Web applications on a farm, so you have to specifically associate service applications to Web applications. You can manage. this database on a separate disk. MCT USE ONLY. STUDENT USE PROHIBITED 2-24 Designing a Microsoft SharePoint 2 010 Infrastructure Some service applications have multiple associated databases,