Service Application Fundamentals ❘ 175 Connecting across Farms Once you understand the service applications and all of their connections in your farm, the next log- ical step is to add more connections. Some of the service applications are capable of being published and then consumed across different SharePoint farms. Even more impressive is the fact that all of the service applications except the User Profile service application don’t even require the two SharePoint farms to be in trusted Active Directory domains. Before you can publish or consume the service applications between two farms, you have to establish a farm trust. This is done by using the SharePoint 2010 Management Shell to create and register cer- tificates between the two farms. This is covered in greater detail in the section “Service Application Administration” later in the chapter. After the farm trust is configured, you can go to the publishing farm and select the service application you want to publish. Once it is published, you will get a URL for accessing the published service. From the consuming farm, you simply connect to the published service by providing the URL. Then the connected service application can be added to a service application group, and will provide services just as if the service application had been part of the farm. Figure 7-7 shows an example of four farms at work. Farm 1 introduces a new concept, an enterprise services farm. This is something typically seen only in large companies. The idea is that a farm is created and maintained exclusively to provide services to other SharePoint farms throughout the organization. This way, the services farm can be optimized for hosting services and can be maintained in the same manner. For example, a Search index might contain several million items, requiring several days to do a full crawl, and hours to do an incremental crawl. In order to do this efficiently, you need to optimize your hardware for Search. If you have three SharePoint farms and each maintains its own Search service application, it would be very expensive to do a lot of repetitive crawling of content. Instead, a much better solution would be to maintain the index in one farm and just consume the service from the other farms. Farm 2 is a simple farm for publishing content, maybe hosting just informational websites or similar content. In this farm, the demand for service applications is low, and all of the service applications it does require are provided by the enterprise farm. Therefore, this farm actually has no local service applications and is just optimized for displaying SharePoint content. Farm 3 is a collaboration farm and is a busy place. This farm has demands for all types of service applications — some are consumed from farm 1, and others are hosted locally. The locally hosted service applications are those that are not capable of being published across farms, so they must reside in the farm where they are needed. Note that the Managed Metadata service application from farm 4 is being consumed. Other than that, there is nothing special about this scenario other than the flexibility of consuming service applications from multiple farms. Farm 4 is very similar to the collaboration farm in nature. It is hosting its own web applications and is consuming local and remote service applications. Additionally, it has published the Managed Metadata service application for consumption by farm 3. Although all three farms are using the default group in this example, this isn’t a requirement. You very well could have configured the [custom] group in any of the farms to consume the cross-farm service applications. 176 ❘ CHAPTER 7 UNderstaNdiNg the service aPPlicatioN architectUre Managed Metadata BDC Farm 1 Search User Profiles Http://url Farm 2 Default Visio Default Http://url Farm 3 Acess Services Excel Services Metadata Http://url Farm 4 PowerPoint Excel Services Default FIGURE 77 Service Applications As a Framework You have probably noticed by now that all of the service applications act slightly different. This is because service applications are really a bunch of individual services built to plug into a framework. Service Application Administration ❘ 177 The great thing about this framework is that anyone can plug into it. It is hoped that as third-party vendors and developers start writing code for SharePoint 2010, they will take advantage of the frame- work and use it to add their functionality. That way, instead of needing to create a custom third-party application to administer their added SharePoint functionality, they will just plug right into Central Administration. If they need a service to run, they can just add it to services on the server, giving administrators a consistent experience. There are already two instances of this today. The Microsoft Office Web Applications and Project Server 2010 are not strictly parts of SharePoint 2010. But when they were developed, their respective groups at Microsoft chose to add their functionality through the service application framework. That way, when you need to administer either tool, you can simply select Central Administration ➪➤Manage service applications. For example, after you install the Office Web Applications you will see both a ser- vice application and a service on the server named Word Viewing Service, along with a few others. From an administrator’s perspective, there is no difference between these service applications and one provided out of the box with SharePoint 2010. SERVICE APPLICATION ADMINISTRATION Now that you have a working knowledge of the fundamentals, it is time to put that knowledge to work. In this section, you will learn how to operate all the knobs and switches that enable you, as a SharePoint administrator, to do your job. Creating a New Instance of a Service Application In Chapter 4, you took advantage of the Farm Configuration Wizard to create several default service applications. That was a great way to quickly get up and running with SharePoint 2010.But now you are ready for prime time, and HR is screaming for its own instance of the Managed Metadata service application. They would like to name it HR Only Metadata. The following steps describe how you would create it for them: 1. Open Central Administration. 2. In the Application Management section of the home page, click the link to Manage service applications. 3. Here you can see all of the service applications currently avail- able in your farm. In the Ribbon, click the New button and select Managed Metadata Service, as shown in Figure 7-8. 4. For Name, enter HR Only Metadata. 5. Confirm you have the correct Database Server listed. FIGURE 78 178 ❘ CHAPTER 7 UNderstaNdiNg the service aPPlicatioN architectUre WHAT IF EVERYONE WANTS THEIR OWN MANAGED METADATA SERVICE? If there are other divisions in the company that feel they need to have their own Managed Metadata service, there is an additional way to solve this. By using what Microsoft terms a partitioned service application, data and processing can be kept separate despite being in a single process and database. This is discussed in greater detail later in this chapter. If you want to host this database, or any other database, on a different SQL Server, you merely need to ensure that permissions are set up. Once that is done, you can just enter the new server’s name. Typically, the permissions you need are found in your farm administrator account. This is the account you specifi ed when you ran the SharePoint Products and Technologies Confi guration Wizard (the gray one) when the farm was fi rst confi gured. The SQL rights this account needs include dbcreator and securityadmin on the existing or new SQL Server that you are trying to use. Also, the SQL Server will need to meet the minimum SharePoint requirements for SQL. 6. Most of the time you will choose Use existing application pool for Application Pool. Then, in the drop-down menu, select SharePoint Web Services Default, as shown in Figure 7-9. FIGURE 79 For optimal performance, the current best practice is to keep all of your service applications in one application pool. This may change as the product evolves, but it makes the most sense for now. Application pools consume a great deal of resources, and performance testing has shown that you will get the best results if all of your service applications are in one application pool. 7. At the bottom of the window you will see some stuff about Content Type hub and Report syndication errors. Leave these two fi elds alone for now (and check out Chapter 16 for more information on their use). Service Application Administration ❘ 179 8. The last checkbox, Add this service application to the farm’s default list, is checked by default. Leave it as is. Later in the chapter you will learn how to change this setting after the fact if necessary. 9. Leave all other settings at their default and click OK. After the service application is created, you will be returned to the Manage service applications page. Using the Ribbon to Manage Service Applications Service applications are built and then bolted into SharePoint through the framework. Part of that framework allows developers to utilize the Ribbon to manage their service applications. But because there is no hard set of rules about what they do with the buttons on the Ribbon, you will see a vari- ety of behaviors. In this section you will learn the primary uses of the various Ribbon commands. When looking at the various management screens and options you will see that some service applica- tions use all of the buttons on the Ribbon, while others use almost none. This flexibility is the power at work. As an administrator you will just have to apply the knowledge learned here to each service application and figure out exactly how it works. The Manage and Properties Buttons Now that you have your HR Only Metadata service application, you need to be able to administer it. The first thing to take a look at is the properties. You do this by clicking once to the right of the service application. This will highlight the service application, enabling the available options on the Ribbon, as shown in Figure 7-10. (If you are taken to the Manage service application screen after clicking, then you accidently clicked the name of the service application. Press the Back button in your browser and try again.) FIGURE 710 180 ❘ CHAPTER 7 UNderstaNdiNg the service aPPlicatioN architectUre Now click the Properties button on the Ribbon. That pops up a window showing the same settings you specified when you created the service application. Most of the service applications allow you to access this screen. Here, you can check information (such as what database name you used) or adjust settings if you change your mind about something (such as the application pool). After you are done looking around, click Cancel to return to the Manage service application screen. Now click the Manage button on the Ribbon. This will take you to the page for managing the actual service application. In the case of HR Only Metadata, you are now taken to the screen for defining terms and all of those other fun things you can do with managed metadata. All of the service appli- cations that have something to manage have their own manage interface. This is just another piece of the framework. In short, use Properties to look at or change settings you configured when creating a service applica- tion. Use Manage to access the service application and do whatever it is your service application was meant to do. Setting Up a Delegated Administrator Now that you have found this awesome manage screen for managing the managed metadata terms, wouldn’t it be great if you could give someone in HR access to add all of the terms? Well, you are in luck. You can add someone from Human Resources as a delegated administrator quite easily: 1. Ensure that you are still at the Manage service applications screen in Central Administration. 2. Click to the right of HR Only Metadata. 3. Click Administrators from the Ribbon. 4. Enter the name of the HR user and click Add (for example, Contoso\JenniferH). 5. You will now see the user’s name in the middle section. Make sure the name is highlighted. 6. In the bottom section, click the box to the right of Full Control and click OK. Figure 7-11 shows an example. Now the HR user is a delegated administrator who can access Central Administration, but will only see those service applications to which they have been granted permissions. If Contoso\JenniferH logs into Central Administration, she will see something very similar to Figure 7-12. That’s a lot of white space. Security trimming has removed everything to which she doesn’t have access, which is pretty much everything. If she clicks on the Manage service applications link, she will see what is shown in Figure 7-13. She can see only the one service application she has access to, and when she clicks on it she only has the option of Manage. This is a delegated administrator at work. This level of trimming enables you to delegate the management of specific components without worrying about compromising security. If you were to log back in as the real administrator and check the permissions, you would see the user has been added to a special group called Delegated Administrators. This makes it simple to find everyone who has been granted access. Note, however, that even if you remove users from manag- ing all of the service applications, they still will not be removed from this Delegated Administrators group. Therefore, be sure to do a little cleanup from time to time if you often change delegated administrators. Service Application Administration ❘ 181 FIGURE 711 FIGURE 712 FIGURE 713 182 ❘ CHAPTER 7 UNderstaNdiNg the service aPPlicatioN architectUre Managing Service Application Groups After all that very exciting information about how great these groups are, it is time you learned how to use and consume them. After a brief walk through the GUI tools, we’ll take a look at some of the hardcore things you can do with the SharePoint 2010 Management Shell. Using Your Mouse to Manage Groups Put that fancy mouse you have on your desk to work and follow these steps: 1. Open Central Administration. 2. Click Application Management. 3. In the Service Application section, click Configure service application associations. From this screen you will see a list of all of your service applications and the Application Proxy Group with which each one is associated. This is where all that terminology you studied comes in handy. You already know that “application proxy group” means service application group, and that “application proxies” really means service application connections, right? The nice thing about this screen is you can now click on one of the proxy groups to change its connections if necessary. For example, if you wanted to remove HR Only Metadata from the default group, this is how you would do it: 1. Click on the proxy group Default. 2. Deselect HR Only Metadata. 3. Scroll down the page and click OK. Now all of the web applications that are associated with the default service application group will no longer have access to the HR Only Metadata group. When you first got to the Configure Service Application Associations screen, you may have noticed that because you have multiple Managed Metadata service applications in your farm, one appears as [default] and the other(s) as [set as default], as shown in Figure 7-14. FIGURE 714 This is because you can associate multiple Managed Metadata services with one service application group, so you need to specify which one should be the default. Both are equally accessible; one of . instances of this today. The Microsoft Office Web Applications and Project Server 2010 are not strictly parts of SharePoint 2010. But when they were developed, their respective groups at Microsoft chose. framework is that anyone can plug into it. It is hoped that as third-party vendors and developers start writing code for SharePoint 2010, they will take advantage of the frame- work and use it to. across different SharePoint farms. Even more impressive is the fact that all of the service applications except the User Profile service application don’t even require the two SharePoint farms