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
Share

Department Of Defense SharePoint Architecture Guide (DSAG) Part 3 Global Principles, Rules and Priorities

The Department of Defense has resources that are designed to be operational in an attempt to successfully manage the missions that they have set as goals within the department. The ability for these various solutions to work across all of the different operations of the department. This type of goal is one that is very strategic in nature.

In order for it to work, the information has to be accessible and it has to follow the rules of the net centric sharing for the data. Then the services can be shared all across the entire enterprise. The Department of Defense infrastructure allows for the standards to be enforced in regards to the interface of the profiles offered for guidance.

All of the data assets as well as the services and the applications have to be both visible and accessible. They also have to be easily understood by the users that have been authorized to benefit from them. The Defense Information Enterprise services offers legal agreements that keep tabs on the performances. They also strive to continue making sure they operate in a way that meets all of the agreements that are in place.

There is a secure environment in place that offers a collaborative effort for sharing of information to take place. This is very important for the information and policies to be correctly shared with the external partners that the Department of Defense has in place. This includes many Federal agencies as well as various communities. The Department of Homeland Security and the Intelligence Community are here too.

There are quite a few state and local government agencies that also fall into this same category. Some of these external partners are also not government related in any way. Instead they are contracted to private businesses. Many of them are partners for academics or for research too.

Through the DIEA there is a set of core principles that are limited. These are where the rules come from. This determination is based on the collective policies and guidance of the Department of Defense. The guidelines used here are in place to offer net centric information sharing abilities. The result of this is a highly effective and efficient process throughout the different segments of the entire department.

The fact that everything is on the same universal level reduces problems within the department. This should be considered a very huge part of the applied process for the IT department and the series of decisions they are responsible for making. There are various rules that have to be introduced so that the priorities of the Defense Information Enterprise can be successfully implemented.

As this type of architecture is being created, there are several things that need to be evaluated as top priorities. That means more attention has to be invested in these areas so that the process you are looking for can be achieved without any problems. You don’t want glitches to arise in regards to the net centric information sharing process. This type of priority though isn’t focused on particular parts of the organization or even particular functions. Instead they offer a realistic way for the focus to be for the cross functioning areas of the department.

These priorities help with the transformation of the enterprise. That is accomplished by focusing on the major needs of the target state. The priorities are the fundamentals that the organization needs to have in place for the DIEA to be a success. The architecture can also be aligned with the investments of the various principles for the net centric roles. Here are several of the priorities that have to be addressed:

Data & Service Deployment (DSD) This takes the data and the services offered by the applications and systems. This allows them to become visible as well as accessible. They are also trusted and simple to understand. The DSD is responsible for guiding the overall delivery as well as the creating of the data and services. They are going to meet the needs that have been defined by the IT manager. At the same time they are able to adapt to the needs of users that may not have been anticipated initially. The foundation is put in place here for the Department of Defense to offer a structure that is completely service oriented.

Secured Availability (SA) This makes sure that the data is and services are able to be secured as well as trusted throughout the Department of Defense. Even though security is provided it won’t stop the users from being able to access various forms of information. Users are able to use the services to find data. However, they can only access those that are within the realm of their authorization. No matter which network that a user is on, they will have the same permission for authorization with all of them.

Computing Infrastructure Readiness (CIR) This makes sure the elements necessary for computing the infrastructure is there. It also allows the Department of Defense to have services for operating the net centric principles that have been established. This allows for the processing, storage, and various services of the infrastructure to be in place where they should be. The dynamics of the program will respond to the loads across there in a balanced way.

Communications Readiness (CR) It is important that the transport has an infrastructure that allows it to provide enough bandwidth. The functioning of the transport allows it to be from end to end without any problems. There is a seamless line for the net centric communications to occur throughout the department.

NetOps Agility (NOA) This allows for the ability of the easy access to be continuous in terms of sharing and managing the information. It can be done from any of the locations within the department at any time. The NOA allows for policies to be put into place that give priorities the accessible ability to operate within the system.

Next >> Department Of Defense SharePoint Architecture Guide (DSAG) Part 4 Applying Principles and Rules

Share