SharePoint Server 2007 does not support geo-replication of content. There are third-party products that support parts of SharePoint Server 2007, but none replicate all of it. Additionally, Shared Services over a WAN is not supported. A farm in Chicago cannot consume Shared Services from a farm in New York. What is supported, however, is the ability to localize My Sites for users in a geographic region. Additionally, you can create a centralized Search center that is consumed via Federated Location Definitions with Microsoft Search Server 2008.
You have the ability to create multiple My Site Providers (Web applications) and assign users to a particular Web application based on their inclusion in an Active Directory group or Global audience. While this can be done in a LAN environment, this section specifically discusses options for geographically dispersed locations. Regional My Site providers are sometimes referred to as Global My Site Providers. This is primarily based on the setting in SSP Administration, My Site Settings, Multiple Deployments, as seen in Figure 16-17. The recommendation in the Note on this page cannot be implemented as the "profile replication solution" tool has not been released as of the date this book was published. The intention is to replicate profiles among multiple SSPs, therefore removing the need for every SSP in an enterprise to perform an individual import.
Note
If you allow users to choose the language of their My Site, as seen in Figure 16-17, you must load the language pack on the WFE Servers that host the My Site Provider for those users.
You can enable personal features across multiple My Site providers. To enable the usage of personal features across multiple My Site providers, you must enable support for global deployments, as seen in Figure 16-17, on every SSP that manages a My Site provider that is listed in Trusted My Site Locations, as seen in Figure 16-18 on the next page.
To add a Trusted My Site Host Location, select New, New Item from the list menu shown in Figure 16-18. You should list the Web application’s root managed path site collection, or wherever the My Site Host template was applied for the Web address field. When selecting the select here to test hyperlink, you should be redirected to your My Site on that Web application.
Note
Once you define a Trusted My Site Host Location, the default My Site settings are ignored. For this reason, always add your default My Site host location to the list of Trusted My Site Hosts first with no target audience. Then, define each additional My Site provider and target that provider with an audience.
If you want to have a default My Site provider, do not select an audience for the first provider in the list. If a user is in multiple audiences associated with My Site Providers, that user will be directed to the first in the list. To change the order of the My Site Providers, select Actions, then Change Order, as shown in Figure 16-19. The exception to this rule is when a user is in more than one group, but the first Web application isn’t available. The user will be created in the first available My Site Provider in the list.
In geographically dispersed environments, there is often a need to have a single index that is referenced across the enterprise so that users in each geographic location can find all of the documentation and all of the right people they need to successfully perform their job. Unfortunately, what is not in this version of SharePoint Server 2007 is the ability to build portions of the overall index at each regional center, then aggregate those indexes into a common index and then distribute the full, enterprise index back to each regional center.
Upon closer examination, what we have found in working with clients who are geographically dispersed is that the users in one geographic location often do not need to find information in the other locations simply because most of the information they need to be successful is hosted locally within their own location. Sometimes, a user’s lack of need to see information that is hosted in other locations is due to language differences or dissimilar job foci or perhaps as a result of the different roles each location performs for the company, such as different product lines being produced at different geographic locations.
The need for an overall enterprise index is really built on the assumption that if a company has a single index, then all of its information will be quickly findable. Indeed, the reason most companies desire to implement a taxonomy coupled with a robust search and indexing topology is due to the (sometimes mistaken) assumption that if their information is organized and indexed, then it will be easy to find it. The market is quickly learning that findability is not solved simply because a solid search engine is implemented into one’s environment. In fact, if the result sets are not meaningful to the end-users, then the chances are good that the search implementation will fail due to lack of popularity.
Search Server 2008 helps resolve this problem through its Federated Location Definition feature. The ability to send the query to remote indexes and receive back results from multiple, dissimilar indexes simultaneously gives you the ability to receive results back from a remote index without having to crawl its content. Because Search Server 2008 can federate its query to multiple SharePoint indexes, Search Server 2008 now gives you the prospect of enjoying the experience of an enterprise index across geographically dispersed environments without the necessity of having to re-crawl that information at the enterprise level to create the enterprise index. Instead, you get the best of both worlds: you don’t create an enterprise index and your users get to enjoy a result set that has enterprise breadth and depth. When you consider that Search Server 2008 Express is free without any document limitation, the prospect of using Search Server 2008 becomes even more compelling.