Designing a Microsoft SharePoint 2010 Infrastructure Vol 1 part 11 pdf

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.