SharePoint 2010 Cross-Farm Services And External Data Sources

There are several steps involved in the process of deploying cross farm services. Each step is very important to gain the overall results you are after.

Configuration of trusted farms ensures all of the farms that use exchanges can trust each other. Certificates have to be exported to a file. Make sure you back up that file before you connect to any of the cross farm services. Publishing service applications must be done before you will be able to successfully share it across farms. Connecting cross farm service applications provides a connection must be made to a service that is published by a remote farm. This will require the URL to be entered of the published service. This is going to be displayed when you publish it. The connection on the local farm has to be created so that it can be connected successfully to a service application for a remote farm.

Should there be two domains where the server farms are located, the User profile service application will require both of them to trust each other. With the Business Data Connectivity and Secure Store Service the domain of the publishing farm has to trust that of the consuming farm. None of the cross farm service applications are going to work if there isn’t a trust requirement in place for the two domains.

It is possible for certain service applications to access external data sources. This occurs through the access of a delegated Windows identity that will place some additional requirements on a given environment. These types of service applications have to be in the same domain as the SharePoint Server 2010 farm. This is where the service applications are housed. The other option is for the service application to be configured using the Secure Store Service.There are plenty of different service applications that can be found across the external data. They use a delegated Window identity. This includes:

  • Excel Services
  • InfoPath Forms Services
  • PerformancePoint Services
  • Visio Services

The service applications used to access external data sources must have a delegated Windows identity. Otherwise it has to be configured for the use of the Secure Store Service. This will store and maintain the credentials of a user or a service. When service applications are used to store credentials, they have to be authenticated before the data can be accessed.

If the external data sources aren’t within the same domain then authentication for the external data sources will fail unless you use the Secure Store Service. Farm servers can be split between two different domains but the application servers have to be found in the same domain as the external data sources.

There are several service applications and products that don’t have those requirements. They include:

  • Access Services
  • Business Data connectivity Services
  • Microsoft Business Connectivity Services
  • Microsoft Project Server 2010
  • Microsoft SQL Server PowerPivot for Microsoft SharePoint
  • Microsoft SQL Server Reporting Services
Share

SharePoint 2010 Service Application Design Best Practices

Through SharePoint 2010, there is an improvement of the services infrastructure that was previously introduced in an earlier version. This infrastructure also hosts services for the SharePoint Foundation 2010. The configuration of services offered is very flexible. This allows the individual services to be configured independent of each other. It also makes it possible for 3rd party companies to be able to add services to that platform. The configuration of services aren’t exclusive to SharePoint Server. The services aren’t restricted to Shared Services Providers.

When service applications are deployed from a farm there are a couple of different methods that can be used.
They include the use of Windows PowerShell, adding services one at a time through the Manage Service Applications page, and choosing services for running the SharePoint Products Configuration Wizard.

The infrastructure of the services has been updated so that there is more control over the types of services that have been deployed. There is also control over the types of service applications that have been shared. Only the service applications that are necessary for a farm can be deployed. The various web applications can be configured so that they only use certain service applications. This is better than them using all of the various services that have been deployed. Service applications can be shared across various web applications that are within the same farm. All of the service applications that are included in a default group will remain unless you change them. There are settings for service applications that can be created. You can add or remove service applications in that default group any time you want to.

The creation of web applications allow you to select the default group you want or to create one that is customized. If you want to customize your service applications you can do by selecting those that you want to be part of the web application. When custom groups are created in Central Administration, they can’t be used for all of your web applications. When you select custom to create a web application you will limit them to only that specific web application you happen to be using. Each of the service applications has a single Internet Information Services website. This is the default setting and you won’t be able to change it. However, you do have the option of customizing how it is configured for various application groups.

There are several characteristics of a farm that you need to be familiar with. Web applications will connect to the default group or a custom group of service applications. All of the service applications will be found within the same Internet Information Services website. Service applications are in a group as defaults or customized. However, not all of the service applications have to be placed into one of those groups. They can be used by a single web application if you wish.

It is possible for service applications to be deployed to different applications pools. This results in process isolation occurring. If you want to optimize how your farm performs then it is recommended that you deploy service applications to only one application pool. In order for that isolation to occur with a service application, you need to create a new application for the pool service application.

While creating a service application there is a connection for the service application that is being created at the same time. There is a connection that is a virtual entity for connecting to web applications. With Windows PowerShell these connections are known as proxies. A proxy will be at the end of the type description for a connection which is through the Manage Service Application in Central Administration. Some of these connections may include settings that you can modify. This includes the Managed Metadata service application, Term Store Administrators, and Default Language.

When you directly manage service applications in Central Administration you can manage and monitor them from a remote location. They can also be managed and scripted through Windows PowerShell. There are some service applications that are shared among many farms. Others though can only be shared in a singular fashion with a given farm server.

Computing intense service applications that operate within a central farm. This is done to minimize the overhead costs relating to administration. This is also to help keep everything operating efficiently, even as the requirements of the farm grow. If you use service applications to support sharing across farms, they should be controlled by a central farm. Then they can be consumed from that core location. For each of the web applications that will be configured, use service applications from different farms.

Share