The preceding section is just
a simplified overview of how services work in SharePoint, of course.
Before you can effectively put service applications to work, it is
important to understand the connections and relationships of services
to web applications. The following sections explore the glue that binds
service applications. While conceptually it is easy to see that service
applications provide capabilities to the web applications, in reality
there is a lot going on to make those connections work. To effectively
troubleshoot and support the SharePoint farm going forward, you need to
learn those details.
TOMATO OR TAMAHTO?
There are some key pieces of service
applications that use different terminology depending if you are
looking at TechNet, Central Administration, or PowerShell. The key to
it is not to over think things. For the sake of this conversation
anything that refers to a group is the same thing, anything that refers
to a connection is just that. For example:
- Service application connection group = proxy group = group
- Service application connection = proxy = connection
The best plan is don’t think too hard; the obvious answer is the right answer.
1. The Connection Structure
Service applications are not offered
directly to web applications, as you might have assumed from the
preceding section. Instead, a series of connections and associations
determine how services are offered, as shown in Figure 1.
SharePoint web applications are associated with service application groups. These groups are composed of one or more service application connections.
Service application connections act as a bridge, admitting the service
applications into the service application groups. A service application
consumes one or more service application services,
some of which may have databases for storage. If this sounds confusing,
the following sections should help clarify how these components are
integrated.
Service Application Groups
You already know what a web application is at this point. The service application group
specifies how services are associated with a web application. When you
created the web application, you used
SharePoint’s default service application group (see Figure 2).
Notice that all the check boxes are grayed out when the default group
of connections is chosen. You cannot edit the default group in this
dialog as you create a web application.
The default group is automatically provisioned
for you. If you used the initial Farm Configuration Wizard, then all
the service applications are part of this group. When you manually
create a service application, you can choose to include it in the
default group or not by using the check box shown in Figure 3.
This group enables you to associate a web
application with a collection of service applications. If the default
group doesn’t meet your needs, you can you can use the [custom] option
to specify which service applications you want to use for the web
application. Keep in mind that although [custom] appears in the group
drop-down menu, you cannot reuse this “group.” When you create a web
application and specify [custom], you choose the service applications
available to that web application. If you then create a second web
application and select [custom], you will not see the service
applications you chose for the first web application selected. Each
usage of [custom] is a unique instance, and not reusable.
Proxy groups or application proxy groups
are other terms you may hear used for service application groups. This
is how they are referred to in the SharePoint 2013 Management Shell and
in the object model (OM).
NOTE To create a group you can reuse, you need to use the SharePoint 2013 Management Shell and run the New-SPServiceApplicationProxyGroup cmdlet.