Building Secure SharePoint Service Oriented Farms

There are several types of SharePoint 2010 server deployments that have to be considered before implementation occurs. In this post I will go through the common designs so better, more informed decisions to be made.

There can be a single service and single farm application in place. This default is used for web applications within a given farm. All sites will have access to all of the service applications deployed within that farm. There are pros and cons to this type of scenario that need to be explored. In this type of design, all of the service applications are available for all of the web applications and all of the service applications are centrally managed. The farm resources are used efficiently and the architecture is simple to deploy.

However, the service application data can’t be isolated and departments or teams aren’t able to manage service applications independently. A single service application and a single farm is a pretty common configuration. That should be the initial set up and it works well when you want to host a variety of sites on the same farm for a given company.

This type of configuration can help you to meet goals of Optimizing resources that allow you to operate service applications on a farm and sharing content and profile data across multiple sites. They would otherwise require a process to isolate their performance so that security can be in place.

When you have a team in need of a dedicated service application, you can build an architecture that uses one or more customized groups of service applications. There are specific steps that you must take in order for this to function properly. They include:

  • Deploying specific service applications for dedicated use. This can be for one or more teams of the organization.
  • Make sure that the dedicated service applications aren’t part of the default group settings.
  • Create at least one web application that uses a custom group of service applications. The SharePoint Administrator can choose the service applications that will be included in any customized group.

It is possible to create more than one custom service application group. Those that are deployed to be used for a specific purpose can also share the same application pool. You do have the option of deploying a separate application for each of them if you would like to do so.

It is possible for a service application group to have multiple Managed Metadata Service applications. The sites found within the web application are able to display social tagging and taxonomy. There are also other features available that come from Managed Metadata Service applications. Under this architecture, service data can be isolated and the ability to accommodate many organizational goals in the same farm. The configuration of sites for the use of a subset of service applications and teams can manage the service applications that are dedicated for their use. However, this environment is complex when it comes to configuration and management and can take a great deal of farm resources to support multiple instances of service applications and that can reduce overall performance.

An architecture that includes multiple service application groups works very well for any company that has several times that can use specific data. It is also a format that works well for partnerships. When you have multiple groups of service applications configured, it allows for teams to be able to have control over those that are isolated for their use.

Under this type of design, there are several service applications that can be deployed for dedicated use by a team. They include:

  • Excel Services Allows for the optimization of performance for a given team. It allows for sensitive data to be isolated.
  • Business Data Connectivity Teams are able to customize their own line of business data systems. They can isolate that data from the other aspects within the organization.
  • Managed Metadata Allows a team to manage their keywords, hierarchies, and taxonomy. With SharePoint 2010 the results of multiple Managed Metadata service applications are combined. They can be shared across many areas of a given organization.

It is also possible for a committed server to be leveraged, you have a server that is dedicated to being a host for service applications within an organization. There are several types of farms that can use these services from the enterprise services farm that has been implemented. When all of the service applications are remote, you will have a published content only farm. This can be deployed without any local service applications in place. All of the service applications are being consumed from a separate farm. This type of configuring works very well for published content. This reduces the efforts from administration that are required to host a farm for published content. This also allows the organization to benefit from centrally managed service applications. This is a good type of configuration to follow if your organization has profiles, search, metadata, and centrally managed resources you want to integrate. The resources within the farm for hosting the content need to be optimized. This is in place of running service applications. /p>

Extended on this concept, a combination of local and remote service applications can be used. They are optimized so the service applications can’t be shared across all of the locally hosted farms. This pertains to the client related service applications as well. All of the cross farm service applications are consumed from an enterprise service farm. Such farms are able to consume services from more than one remote farm. The Managed Metadata service comes from a specialized department farm. It is integrated with the automated management of social tagging and taxonomy for that department. When there are multiple Managed Metadata service applications in place, one of them has to be designated as the primary service application. This is what will be used for hosting the corporate taxonomy. All of the other uses of the service application are considered as secondary. They have to provide additional data to the primary service application data. When you have web parts by default then the data comes from the multiple Managed Metadata service applications.

The configuration that is recommended when optimizing the administrative and farm resources on the enterprise level for hosting services and optimizing resources on the farm level to host collaborative sites. Also, when integrating organizational wide metadata, search, profiles, and resources that are centrally managed and integrating along with the metadata that is created by a specialized team

A mix of local and remote service applications can be used for organizations that have specialized departments. This allows an architect to ensure the ability to manage service applications through automation and Ensure data is isolated. Furthermore, it also allows centralized management of the service applications and the team is able to manage its metadata from the rest of the organization. This is a best practice design when the requirements mandate ensuring that specific service data is isolated and able to be managed separately from the rest of the organization and allowing a specialized team to manage their own metadata.

There are times when you may want to deploy specialized service farms. They help to optimize farm resources for specific types of service applications. This can make it possible to scale up hardware for optimizing performance as it relates to the specific service application.

There is a primary service application that may require a dedicated farm to be used for search. This is because search has a unique performance as well as requirements for capacity. When the search service application is offloaded to a dedicated farm, those resources have to be optimized for all of the other cross farm service applications.

The service applications can be shared across any farm with cross organization farms. They aren’t limited to only the entries service farms. There are some scenarios where you may want to consider doing so. They include:

  • Providing enterprise wide service applications but you won’t need a dedicated enterprise service farm
  • In order to share resources across farms while avoiding duplication of service applications that have been previously deployed

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