Search is easily the "hot" Shared Service and drives many customers to purchase SharePoint Server 2007. SharePoint Server 2007 Search services provides the standard indexing and basic querying one would expect from any vendor, but adds many services such as search scopes, managed properties, and advanced search capabilities. These services are provided to any site collection that is hosted in a Web application that is associated with a specific SSP. While this association may sound complicated, it really isn’t. Figure 16-2 shows how the Search service is consumed by a site.

Figure 16-2. Sites consume Search Shared Services from the hosting Web application’s association with an SSP.

Search design best practices are detailed in Chapter 15, so we will only discuss Search in this chapter as it applies to a Shared Services design best practices. It is important to understand the difference in this context: We need to design an SSP using best practices that in turn hosts a Search provider. It is a best practice to implement a single SSP and therefore a single Search provider. Because an SSP can host only a single Search provider, the requirement of multiple Search providers greatly complicates your SSP design. If you are not sure if you should create a second SSP to support a second Search provider, don’t! If you decide not to heed this advice, let us give you an example of what the outcome could be.

Let’s assume you created a second SSP to support another Search provider. Let’s also assume you had a robust default SSP implementation that included Search, audiences, personalization site links, and My Sites. After creating your second SSP and Search provider, you realize you cannot consume that provider unless you change the hosting Web application’s association with the default SSP (see Figure 16-2), so you change the association and can now consume your new SSP provider. But you quickly realize all of your audience targeted Web parts fail, My Sites cease to work, user profiles (think People Search) doesn’t work, and the next day Microsoft Office 2007 applications start losing their custom "Save To" locations! Because you re-associated with a new SSP, you have lost all of the functionality of the previous SSP. Now you have a mess to clean up that will not be an easy task. So we will restate the best practice of carefully planning for multiple SSPs.

User profiles are a strong selling point in SharePoint Server 2007. User profiles are not used for authentication; they are used for exposing descriptive information about people. Many times we are looking for someone who possesses knowledge about a subject, and not simply a keyword search for documents. This is the first benefit of user profiles in your environment—finding people who possess tacit knowledge about a subject by using the information that describes them.

This profile information is gained through either importing the content from an LDAP (Lightweight Directory Access Protocol), or through direct input from the users themselves. While the best practice is usually to obtain this information from an LDAP import, there are times when gathering this information directly from the user is beneficial. First, let’s look at information imported from an LDAP. You can import metadata about a user directly from any LDAP, such as Active Directory, but that content is limited to what is stored in that LDAP. For example, SharePoint Server 2007 can leverage the hierarchal management structure in your organization for audiences and search scopes. For that information to be valid and applicable, you must have populated the "reports to" field correctly in your Active Directory. In general, your imported information is only as good as the source. SharePoint Server 2007 doesn’t magically find information about people in your environment; it would cost substantially more if it did! The second method we have for populating properties about a user is directly from the users themselves. This input is gathered through personal feature pages, as shown in Figure 16-3, or My Site User details shown in Figure 16-4. Notice the URL is the same in both of the following figures, but the entry point is different.

Figure 16-3. Users who do not have a My Site can edit profile details in a personalization page.

Figure 16-4. My Site users can edit their profile details from within their respective My Site.

Through both of the personal details pages, we can collect user information such as technical skill set, likes and dislikes, and any other discriminating information about that person. These properties can then be used to define audiences for targeting content or to create custom search scopes. Think about the possibility of searching the content of all users whose specialty is database design, circuit design, or any specific technology about which they are experts. This allows your organization to identify who knows what in your organization. Consider it a best practice to immediately start using personal details pages, even if you will not implement My Sites. You can always leverage the same content in their My Sites later. Users will quickly begin using People Search against these profiles if the correct metadata exists.

Published Links to Office Applications assists you in the arena of relevance. Remember, two of your primary goals with SharePoint Server 2007 are timeliness and relevance. Publishing links to Office applications such as Word, Excel, or PowerPoint allows you to populate the "Save As" locations in Office 2007 applications based on who a user is. For example, you could have the public document library in the accounting site collection be available in the Office client for every person in the Accounting Active Directory group. This is very powerful and tailors SharePoint Server 2007 functionality for groups within your organization. Figure 16-5 shows where this link will appear in your Office 2007 client.

Figure 16-5. You must have Office 2007 or higher to see the "Save As" locations correctly.

The best practices here are rather simple. Do not publish numerous links to the same person. Too many links usually get ignored, thus negating their functionality. Ten to twenty links would be a good maximum target number, unless you have specific requirements to do otherwise.

By default, the Office client gets these links updates via its association with an SSP. When a client first visits his or her My Site, they are asked if they want to make it their default, or they can select the link in their My Site home page, as demonstrated in the following images.

By choosing this My Site to be their default, they will now pull information from the SSP that hosts the My Site Provider every 24 hours. Figure 16-6 shows a logical diagram of how a client gets information from published links.

Figure 16-6. A Windows client gets published links via its My Site Provider information.

In most implementations, it is a best practice to leave the scheduling defaults alone for this setting. Changing the defaults to a more frequent schedule can substantially increase the traffic to your SSPs and decrease performance. The more clients you have pulling these updates, the more apparent the performance decrease will be.

Personalization Site Links are very different than Published Links, but are often confused. Personalization Site Links allows you to target content to My Site Global navigation, also called top link bars, en masse or by targeting users and groups. For example, let’s assume you have Active Directory groups that are organized by Building Number. You can then target information based on the building a user is located in. Figure 16-7 shows an example of targeting an activity only to users in a specific building using Site Links.

Figure 16-7. You can target information on top link bars to specific users, based on the Active Directory group.

Once again, the best practice is that fewer links are better. The fewer links a user has on their top link bars, the more likely they are to use them.

Exposing Publishing Portal Sites in the My Site Global Navigation

An often overlooked option of personalization site links is the ability to view Publishing site links in the My Site. When configured, the My Site navigation is retained even after browsing to the Publishing site. Figure 16-8 shows how a link to the Sites directory of a collaboration portal would appear when targeted to a My Site. Figure 16-9 shows the navigation structure after browsing to the Sites directory.

Figure 16-8. You can expose Publishing site navigation to your My Sites.

Figure 16-9. After browsing to the Publishing site, you will still see the My Site global navigation.

If you want your users to start with a combined view of their environment—both personal and corporate—then have them start with their own My Site and expose the key corporate sites they need to visit on their My Site tab structure using this Personalization Sites Link feature.

As was discussed in the previous two sections, audiences are a very powerful piece of functionality in your SharePoint Server 2007 design. Audiences allow you to target information to users based on their Active Directory groups, SharePoint groups (when synchronized with Directory Management Services), or user profile information.

From a big picture point of view, think about audiences as increasing relevance. Let’s look at the following scenario. You are a SharePoint Server 2007 administrator at a university. Your users are university staff and students, and everyone visits the same portal URL. You want to provide a relevant portal experience so that students see student news, and the staff sees staff news. You would first create two audiences, one for staff members, and one for students. Then, place two News Web parts on your portal home page. In the Web part properties, target the audiences in the advanced settings. Now, students will see student news, and staff will see staff news. What if a user is in both groups? They will see both Web parts. Audiences can be used on individual objects in a list also, but only the default content type can be targeted. Audiences can also be used to tweak your Search configuration. For example, you could have several search Web parts in your Search center, each with different functionality, targeted to groups in your organization. A problem audiences do not solve easily, however, is the ability to have users choose their audience "on the fly."

My Site functionality is detailed in Microsoft Press books and TechNet extensively. Therefore, the following section is an overview of the implementation best practices. First, My Sites provide a personal portal, or a one-to-many collaboration site. Besides the advantages of providing an easily accessible and portable personal workspace for your users, we can collect user profile information, surface critical information in the global navigation, and provide further integration with Microsoft Outlook through Meeting Workspaces.

For most organizations, a single My Site provider is sufficient. A key to Shared Services implementation is that simpler is better. Unless you are geographically dispersed or have some other specific requirement, you only need a single provider. A My Site provider is simply a Web application that will host My Sites. The first best practice is to always create a My Host site collection in the root managed path of a Web application dedicated to hosting My Sites. Figure 16-10 shows the configuration screen in Central Administration to create this site collection.

Figure 16-10. Create a My Site Host site collection in the provider’s root managed path.

This My Site Host provides two primary functions. First, users can simply browse to the root of this Web application and be redirected to their individual My Site automatically. For our example scenario we will use http://MY as the My Site provider, which is simply a Web application. Second, it provides the entry point to crawl user profile information. Using the sps3:// protocol handler in Search content sources, you can index user profile information to make it available to queries. Be sure to name the My Site Host site collection something meaningful because the name will be seen by users without My Sites.

When creating an SSP, you are asked to select a My Site location. This location is referred to as a Provider, Web application, and location. The naming convention in SharePoint Server 2007 is fairly inconsistent in regard to My Site providers. Just remember that all three define the same object. Unless you have a specific requirement, always create a dedicated Web application to host My Sites. Why, you ask?

While this location can be overridden by configuring Trusted My Site Locations, it is best to get it right the first time. Another interesting note about the creation of a My Site location is the relative URL. This is simply a managed path that is named personal by default. You can create a managed path named anything you want and use it. A common My Site managed path is site. If your My Site provider was created as http://MY, then the complete path will be http://my/site/username. This is user friendly and makes it easy to do bulk maintenance on My Sites. The globalization of My Sites is covered later in this chapter for large deployments.

Excel Services provide many functions, such as in-browser viewing of workbooks and worksheets, centralized processing and caching, and abstraction of spreadsheets without exposing proprietary formulas. Excel Services best practices are covered in-depth in Chapter 18. This section is merely for your implementation and design best practices.

First, Excel services can be consumed only by the local SharePoint Server 2007 farm. That is, you cannot share Excel Services between farms. Second, Excel Services self load-balances when the service is started on multiple machines. If you require configuration information, you should reference the Microsoft Press administrator guides and companions, or MSDN and TechNet.

When planning and designing for the Business Data Catalog, it’s all about entities and methods. The Business Data Catalog relies on an application definition file to connect to almost any structured content. When generating your application definition file, you are going to be creating things called entities. For programmers who are used to object-orientated programming, entities will make sense. You need to think of the entities that you define as being real-world objects that people want to display data about, for example customers, products, or orders. If you are lucky, these entities will be unique tables from your database; however, in more complex scenarios, you may be constructing joins across tables with SQL statements.

Once you have decided upon your entities, you need to create methods for them. Which methods you define depends on what you want to do with your Line-of-Business data in SharePoint. If you want to display the information in the BDC List Web Part, you need to create a finder method. For using Business Data Columns in your lists or document libraries, you need a Finder and SpecificFinder method. For MOSS to be able to crawl your entity so you can search the data, you’ll need to create an IdEnumerator and SpecificFinder method. Also, for searching make sure your default content access account has the necessary permissions to execute Business Data Catalog applications and entities.

If you are looking to make use of your Line-of-Business data through Web services, you need to ensure your Web services are presenting data in a way in which MOSS 2007 can use it. As our entities have Finder, SpecificFinder and IdEnumerator methods, we must have Web services for each entity that presents data for these methods. For example, if we want to create a Product entity that we will access through Web services, we would create Web methods:

Quite often, it is easier to wrap third-party Web services with your own custom Web service methods to present the data in a way that the Business Data Catalog can use.