Technical White Paper

Published: February 3, 2004

Deploying Enterprise Search, Notification, Audience Targeting and User Profile Services Using Microsoft Office SharePoint Portal Server 2003

Executive Summary

This white paper is for Microsoft customers who are deploying or evaluating Microsoft® Office SharePoint™ Portal Server 2003 for their intranet portal infrastructure and need to support multiple portal sites. The Microsoft experience documented in this white paper is also relevant to medium and large sized organizations considering the deployment of SharePoint Portal Server 2003 portal sites in a server farm configuration.

SharePoint Portal Server 2003 Shared Services is a set of centrally managed, highly scalable, core portal services designed to be re-used across multiple portal sites and multi-server farm configurations. A Shared Services environment provides the following portal services to portal sites within a server farm:

• Enterprise indexing, search and retrieval services
• Self-service, centrally managed notifications services
• Audience definition services to support content targeting
• User profile creation and management services
• Single sign-on services

The Microsoft Knowledge Network Group (KNG) worked in conjunction with the Microsoft information technology group (Microsoft IT) to deploy Shared Services to address the following needs:

• Support a large, world-wide intranet portal infrastructure consisting of a central intranet portal site and hundreds of business division, product group, regional and subsidiary portal sites.
• Help Microsoft employees to find and retrieve relevant information and knowledge more efficiently regardless of where they begin their search on the intranet.

The key business benefits gained by Microsoft with this deployment of Shared Services included:

• Ability to avoid costs by deploying and managing a set of common portal services for hundreds of intranet portal sites in three regional data centers.
• Improved employee productivity by making it easier for them to find and retrieve task-relevant knowledge and information.

Introduction

Customers frequently ask Microsoft about the methods employed and lessons learned when its own products and technologies are deployed and used in the company.

This white paper is for Microsoft customers who are deploying or evaluating the deployment of SharePoint Portal Server 2003 for their intranet portal infrastructure. Further, it is for customers with a need to support multiple internal portal sites. The experiences documented in this white paper are most relevant to medium and large sized organizations.

The Microsoft Knowledge Network Group (KNG) started working with pre-release versions of SharePoint Portal Server 2003 to a deploy Shared Services, a set of centrally managed, highly scalable, core portal services designed for use across multiple portal sites and a variety of server farm configurations.

Core portal services in Shared Services include:

• Enterprise indexing, search and retrieval
• Self-serve, centrally managed notifications
• Audience definition services to support content targeting
• User profile creation and management
• Single sign-on

Note   Because virtually all Microsoft line-of-business applications support Windows authentication, Microsoft uses Active Directory® directory services so that users do not require separate user accounts and passwords. For this reason, Microsoft does not use single sign-on services.

The goals of the project were to (i) create an integrated infrastructure that would significantly reduce the costs associated with the deployment and management of core portal services across the large and growing number of local and international portal sites at Microsoft and (ii) improve employee productivity by making it easier for them to find and retrieve task-relevant knowledge and information.

The needs that Microsoft addressed with Shared Services were:

• Technical requirements of a large, world-wide intranet portal infrastructure consisting of a central intranet portal site and hundreds of business division, product group, regional and subsidiary portal sites.
• Desire to help Microsoft employees work efficiently and productively by providing them with an intranet portal experience that is consistent around the world.

This document explores these requirements and problem areas, describes the way the Microsoft team organized the project and deployed the solution, and relates the business benefits gained and lessons learned from this project.

A shared services infrastructure can be deployed in a single central location or, in a multi-national organization like Microsoft, multiple shared services farms can be deployed globally. Figure 1 shows three shared services farms that that include central, division, and group portals.

Figure 1   Shared Services Deployed on Global Scale

Shared Services is one part of the overall Microsoft world-wide intranet solution. The Microsoft internal intranet solution includes the following components: Shared Services, the centrally hosted collaboration platform, Microsoft Windows® Server 2003, Microsoft SQL Server™ 2000, Windows SharePoint Services, and Microsoft Office SharePoint Portal Server 2003. Figure 2 illustrates how these components comprise the intranet solution.

Figure 2   Microsoft Internal Intranet Solution

Related white papers document the experiences in planning, implementing and deploying additional components of the Microsoft intranet. The series of related white papers, available at http://www.microsoft.com/technet/itsolutions/msit/default.mspx, includes:

• Deploying SharePoint Products and Technologies for Enterprise Collaboration
• Team and Enterprise Collaboration Platform
• Deploying SharePoint Portal Server 2003 Shared Services at Microsoft

It is not necessary to read the series in order to understand this white paper. The reader requires basic familiarity with the SharePoint Products and Technologies family of products.

Although this white paper provides recommendations based on the Microsoft experience as an early adopter, it is not intended to serve as a procedural guide. Each enterprise environment is unique. The plans and lessons described in this white paper need to be adapted to the specific needs and requirements of an organization.

Additional information on planning, deploying, testing and managing an intranet solution based on Microsoft SharePoint Products and Technologies can be found in the Microsoft Solution Accelerator for Intranets available at http://www.microsoft.com/downloads/search.aspx?displaylang=en. The Solution Accelerator for Intranets is a collection of documents that present a prescriptive and tested approach that is supported by Microsoft, for designing, deploying, operating, and growing an effective intranet solution. For the development of an intranet solution based on SharePoint Products and Technologies, the Accelerator resources address issues that are not discussed in the product documentation, such as planning for service readiness, resource requirements and capacity. Also covered are topics such as systems monitoring, backup and restore processes, planning for growth and disaster recovery.

Situation

Microsoft had deployed several hundred intranet portal sites to support the worldwide needs of its business divisions, product groups, geographic regions and subsidiaries; and expected this number to grow.

Site-by-site deployment and management of portal services to a large number of portal sites can be difficult and expensive. Deployment of portal services on a site-by-site basis can increase hardware requirements for each site in terms of processing, memory and storage capacity. Additional effort is also required to individually configure and manage server hardware and software components. Last, costs are further compounded by network bandwidth and remote processing needed to support portal services such as content indexing.

At Microsoft, many groups had deployed their own SharePoint Portal Server 2001 servers to host portal sites, team collaboration sites and document management libraries. In addition, SharePoint Portal Server 2001 enabled a personal dashboard site to be created for each workspace user – potentially one in every SharePoint Portal Server 2001 workspace the user had access to. There was neither organization of nor connection between the sites; they were simply additional Web sites on the Microsoft intranet. This resulted in duplicated deployment and management efforts, inefficient use of server processing and storage resources, excessive network traffic as each server indexed its own set of intranet sites.

In addition, Microsoft found in a survey of intranet users that productivity was hindered for employees because they lacked a common means to organize, search and navigate the many intranet sites in use in the company. Specific problems included:

• Difficulties employees experienced in finding and retrieving the "right" information
• Challenges for intranet users to locate people and understand what they know
• Inability to easily navigate the intranet and develop a familiar sense of "place"

SharePoint Portal Server 2003 Shared Services provided the Microsoft information technology group (Microsoft IT) with a more cost effective means to deploy portal services and provided Microsoft employees with a better quality of intranet experience, world-wide.

Project Team Members

The deployment of Shared Services at Microsoft involved a number of different groups. The Microsoft Knowledge Network Group (KNG) led the requirements analysis, best practices development and design of Shared Services. They worked closely with Microsoft IT to deploy Shared Services on the centrally hosted collaboration platform and to integrate these systems with Microsoft Web, the company enterprise intranet portal.

Knowledge Network Group

The mission of the Knowledge Network Group (KNG) is to help employees work more efficiently and effectively by providing them with the means for easy access, exchange and use of relevant information and knowledge. The group adopted a three-prong strategy involving architecture, prescriptive guidance and leadership.

KNG is responsible for delivering a knowledge architecture and intranet architecture based on core schemas, vocabularies and categories. Their goal is to enable a seamless experience for employees who are looking for information and knowledge on the intranet. KNG is also responsible for providing a corporate taxonomy and managing it on a collaborative basis by working through the Microsoft internal Taxonomy Board.

Microsoft Information Technology Group

Microsoft Information Technology Group (Microsoft IT) is responsible for driving global operations and delivering information technology services to the entire Microsoft organization. The group directs all activities related to running and maintaining Microsoft information systems world-wide: technology infrastructure, corporate and marketing information systems including production, distribution, and other key internal systems. Microsoft IT works to provide a world-class utility and excellence in business operations through leadership in the design and integration of company strategies, processes and architecture.

Microsoft IT provides a full range of services including server and end-user support, telecommunications management, network operations and information security. This role includes managing connectivity for more than 300,000 personal computers worldwide. Microsoft IT ensures that more than 55,000 employees, 20,000 contractors and vendors in more than 400 Microsoft locations are able to access corporate network services and resources twenty four hours a day, seven days a week from around the world.

Because the primary business of Microsoft is software design, Microsoft IT has a second responsibility that is unique among global providers. In addition to running the IT utility for Microsoft, Microsoft IT is an early adopter of company technologies, responsible for testing and deploying Microsoft products such as SharePoint Products and Technologies, Windows Server™ 2003, and Exchange Server 2003, before the products are released to customers. This process is known by those within Microsoft as "eating our own dog food."

Project Team Roles and Resources

Members of the project team that deployed Shared Services included:

• One manager with responsibility for the whole team and its budget
• One lead program manager who reported to the overall manager and carried responsibility for coordinating the program management and development teams
• Three program managers with individual responsibility for each of:
  • Search services
  • People, audience, user profile and taxonomy considerations
  • My Site personal sites

A small development team included five full-time employees plus $100,000 US for outsourced development work over a three month period. This team focused on integrating existing tools with Shared Services, including the Best Bets database, Best Bets management, the Universal Resource Locator (URL) Cataloging Service (UCS), people profile attributes, and Sites Directory.

Additional Partners and Stakeholders

In addition to KNG and Microsoft IT, stakeholders in the design, development and operation of Shared Services included:

• Managers responsible for strategic and fiscal results
• Process owners responsible for efficient and effective delivery of business results
• Internal portal owners and administrators
• Microsoft product groups that design and develop enterprise communications and collaboration software products

Centrally Hosted Collaboration Platform

To meet Microsoft requirements, Microsoft IT created a collaboration platform for portal and team sites based on Windows Server 2003, Microsoft SQL Server, Windows SharePoint Services and SharePoint Portal Server 2003. The platform was made available for rapid creation of team collaboration sites and, when there was business justification, new portal sites. The centrally hosted collaboration platform was designed to enable site administrators to create and manage large numbers of team and portal sites as individual Web sites.

KNG and Microsoft IT designed the platform with three types of server configurations: a team site server farm, a portal site server farm, and a third server farm configuration that hosted the Microsoft Web portal site and provided Shared Services to the other portal sites. The portal site farm provided front-end servers for SharePoint Portal Server 2003 portal sites. For data storage, the portal and team site farms each hosted their own a storage area network (SAN). The Shared Services farm was hosted in the Redmond, Washington data center and provided a set of centrally managed, highly scalable, core portal services designed for re-use across multiple portal sites and multiple server farms. The core portal services included search, notifications, audience targeting and user profiles. Two additional Shared Services farms were deployed in remote data centers: one in each of the European and Asian-Pacific regions.

Figure 3   Centrally Hosted Collaboration Platform Design

Figure 3 shows a logical representation of the centrally hosted collaboration platform. The architecture was designed to support hundreds of division and group portal sites along with tens of thousands of team sites organized in a hierarchy of business divisions and product groups. Personal sites and team sites were hosted by an appropriate regional server farm.

The detailed design, implementation and deployment of the platform by Microsoft IT is described in the Microsoft IT Showcase white paper "Deploying SharePoint Products and Technologies for Enterprise Collaboration" available at http://www.microsoft.com/technet/itsolutions/msit/default.mspx.

Understanding Shared Services

To fully understand the Microsoft deployment of SharePoint Portal Server 2003 Shared Services, it is important to understand SharePoint Portal Server's server farm and Shared Services design and configuration options. Readers already familiar with this technology may choose can skip to the Solution section which specifically addresses the Microsoft internal deployment of shared services.

SharePoint Portal Server 2003 is the scalable portal server platform that connects people, teams and information across business processes. SharePoint Portal Server solutions facilitate end-to-end collaboration by enabling aggregation and organization of information, and the ability to search for it.

SharePoint Portal Server 2003 Shared Services includes a key set of portal services:

• Enterprise indexing, search and retrieval
• Self-service, centrally managed notifications
• Audience definition services to support content targeting
• User profile creation and management
• Single sign-on

SharePoint Portal Server 2003 Shared Services are an important consideration for medium and large sized organizations with multiple portal sites who want to reduce deployment, management, network and server costs.

To understand how Shared Services can be used, it is important to understand how SharePoint Portal Server 2003 can be deployed in a server farm configuration.

SharePoint Portal Server 2003 Server Farms

Earlier versions of SharePoint Portal Server supported a limited number of portal sites (workspaces) per server. In addition, each server was capable of supporting a relatively small number of users.

To address these issues, SharePoint Portal Server 2003 takes advantage of the substantially increased scalability, performance, stability and security offered by Windows Server 2003 and the Microsoft .NET Framework. More specifically, SharePoint Portal Server 2003 was designed to scale from a single server up to a data center supporting numerous large server farms capable of supporting up to one million user accounts and several million documents. Table 1 depicts three of the most common server configurations.

Table 1   Common SharePoint Portal Server Server Farm Deployments

The maximum number of portal sites that can be deployed in a single server farm depends on the number and type of servers deployed and whether the servers have been configured to use Shared Services. If the server farm is not part of a Shared Services environment, then the server farm supports up to 15 portal sites. If the server farm supports Shared Services, then it can support up to 100 portal sites.

To support hundreds of portal sites distributed across three regional data centers, Microsoft needed to configure and deploy one larger server farm in each data center.

General Recommendations for Deployment of Server Farms

SharePoint Portal Server 2003 can be deployed in several different configurations to address the performance, scalability and availability requirements of very large organizations. According to the SharePoint Portal Server documentation, servers that are part of a SharePoint Portal Server 2003 server farm should meet or exceed the specifications described in Table 2.

Table 2   SharePoint Portal Server 2003 Hardware Recommendations

The minimum recommended SharePoint Portal Server 2003 high-availability server farm configuration is the smallest server farm that remains operational after a single server failure. It requires: (i) two Web servers that support search requests, (ii) two computers in a cluster running SQL Server and (iii) a dedicated index server. Table 3 lists the recommended hardware configuration.

Table 3   Minimum High-Availability Server Hardware Recommendations

This configuration offers the capacity to meet or exceed the following requirements for availability and performance:

• Processes 80 Web pages per second including 10 search queries per second
• Indexes 10 documents per second
• Stores 1 million documents
• Includes 5 million documents in its indexes
• Hosts up to 25 portal sites using Shared Services (10 portal sites if Shared Services is not used)
• Hosts up to 50,000 team and personal sites

It is possible to significantly increase the scalability, availability and performance beyond those achievable with the minimum high-availability solution, by adding server sources as follows:

• CPUs on existing servers
• Additional servers to an existing single server or multiple server farm configuration
• Dedicated server farms for:
  • Portal and team sites
  • Central Shared Services
  • My Site personal sites

More information on configuring SharePoint Portal Server 2003 for high availability and scalability can be found in the Microsoft Solution Accelerator for Intranets, available at http://www.microsoft.com/downloads/search.aspx?displaylang=en.

Additional design recommendations can be found in Appendix A – SharePoint Portal Server 2003 Server Farm Design Recommendations.

SharePoint Portal Server Shared Services

By default, each portal site in a server farm can be configured with its own settings for search, notification, audience and user profile services. Deployment of Shared Services is optional in a server farm using SharePoint Portal Server 2003. When configured to provide Shared Services, a server farm includes one portal site defined as the parent portal site from which services are provided to child portal sites. Individual services cannot be shared. All of the core services must be deployed together in a Shared Services environment:

Parent Portal Site

The portal site that provides the services is the parent portal site. Only one portal site in a server farm can provide Shared Services.

Child Portal Site

The server farm that uses Shared Services is the child server farm. Each portal site on that server farm is a child portal site. A child portal site is any portal site that uses Shared Services from a parent portal site.

When a portal site is configured to provide Shared Services, all other portal sites on the server farm become child portal sites. Any additional portal sites that created in the server farm automatically become child portal sites.

• Search: The search component consists of indexing and search services, databases or related files that provide search functionality. The parent portal site provides search services to other (child) portal sites in that server farm. In addition, the parent portal site can provide search services to portal sites in other portal farms. A portal search scope is created to include the portal and all associated portals plus associated team sites. This helps provide more relevant search results than searching the entire corporate intranet. For example, a tester looking for a test plan for a particular product can search on that product group's portal and avoid being inundated with test plans from all past releases and other product group's test plans.
• Notifications: Notification services help users track changes to content that is relevant to their everyday work. Users can choose to receive alerts for the following types of items: search queries, portal areas, files, lists, document libraries, and individual's user profiles. Shared services in each region alert users about changes in a site or document to which they had subscribed for such services. These subscriptions are listed within a user's personal site so that they can manage their content and related alerts within their region and by location.
• Audience targeting: An audience is a custom-defined group of people to whom content is targeted based on their membership in that group. Parent portal site administrators define audiences based on data in user profiles and other Active Directory information such as the security or distribution group to which a user belongs. The content displayed on a site can change for a user browsing through it, based on their inclusion in an audience. For example, an audience could be created for the product development group in a company based on the Title property in a user profile. The audience definition can then be applied to a portal area. This would enable one set of area listings to be displayed for software developers and a different set for the rest of the users.
• User profiles: A user profile organizes and displays properties related to an individual. The specific properties are selected by the administrator of a parent portal site. When user profiles are shared, a parent portal site shares information from its profile database with child portal sites. SharePoint Portal Server 2003 offers the capacity to import and synchronize information about people from Active Directory into a profile that provides three views: a personal view that only the user who owns it can see; an edit view for that owner to update optional items; and a public view that can be seen by all users. User profile information appears by default in the public view of a user's My Site personal site. A key benefit is that all references to a particular person point to a single place regardless of the portal site or team sites they use.
• Single sign-on service: Single sign-on is an authentication process that permits a person to enter one name and password to use a variety of applications.

In additional to the core portal services, the following services can also be deployed in conjunction with a Shared Services environment:

• My Site personal sites: My Site provides a personal Web site for a portal user. My Site provides quick access to information a person needs to do their work. This may include links to documents, individual profiles or Web sites, as well as alert results noting content changes in the employee's portal site or any content within the portal's content sources. From their personal site, a user can also update their public profile and share their collection of links with other portal site users. Personal sites can be hosted on a non-parent portal site or another server farm.

Benefits of Deploying Shared Services

In a typical organization, there may be multiple deployments of SharePoint Portal Server 2003. Each portal site can store user profiles, conduct search and indexing, and provide notifications. When an organization has multiple portal servers deployed, it becomes expensive to deploy each portal site with all of the services, because many of the services are common to all portal sites. The cost of managing portal services on each individual portal site increases as the number of portal sites increase. To consolidate resources and reduce server and network resources, the common indexing and search, notifications, audience targeting and user profile services can be provided and managed from a single parent portal site. Child portal sites use the Shared Services provided by the parent portal site.

Shared Services Configuration Overview

To configure a portal site as a parent site and provide Shared Services to other portal sites, use the SharePoint Portal Server Central Administration Manage shared services for the farm page to enable the Provide Shared Services function.

To make a portal site a child site that uses Shared Servers provided by a parent portal site, use the SharePoint Portal Server Central Administration Manage Shared Services page to specify the Shared Services parent portal site database server name and database name.

For more information on this, refer to the "Providing Shared Services" and "Using Shared Services" topics in the SharePoint Portal Server 2003 Administration Guide.

The remainder of this white paper describes how the Microsoft Knowledge Network Group customized, configured and deployed Shared Services as part of its intranet infrastructure architecture.

Solution

At Microsoft, Shared Services are deployed on top of the centrally hosted collaboration platform hosted by Microsoft IT. The primary role of the platform is to provision and manage Windows SharePoint Services team sites, personal sites, document and meeting workspaces and portal sites based on SharePoint Portal Server 2003. Shared Services are provided by a parent portal site in a Shared Services server farm and consumed by child portal sites in the farm. In a Shared Services design, the parent portal site must be configured specifically to provide Shared Services while the child portal sites must be configured to use them.

Microsoft aimed to provide an intranet portal experience that enabled employees to find information relevant to their work, regardless of their location in the company. Initially, the project team focused its planning on developing a deeper understanding of features than might otherwise be required. The Microsoft team explored the features supported by each service, technical dependencies and strategies for integrating the existing taxonomy database and URL cataloging service.

In the design phase, the project team paid particular attention to two services that offered the greatest potential for configurability: search and user profile services. In the configuration and deployment phase, efforts focused on the physical server and server farm as well as their installation in Microsoft regional data centers.

The Microsoft Shared Services Farm

Shared services were offered within regions and based on the following criteria:

• Team sites were linked with the appropriate group division portal, or Microsoft Web central portal site.
• Within a region, portals consumed services from the regional Shared Services parent portal site. The hierarchy of portal sites defined the search scopes within a region.

Single sign-on is a SharePoint Point Portal Server 2003 shared service for which Microsoft does not have a requirement. The single sign-on feature is used for integrating back office systems and line-of-business applications that require a separate credentials database. Because most line-of-business applications at Microsoft support Windows authentication, the company makes use of Active Directory services that have no requirement for separate user accounts and passwords. As a result, Microsoft does not use the single sign-on services offered in Shared Services.

Shared Services Features Used by Microsoft

Search Service

The Shared Services infrastructure provides a robust capability for users to conduct broad searches of the organization for information, and people in addition to targeted searches within a particular portal site or team site.

The first step in deployment for this service was the design of a content indexing strategy, as well as creation and configuration of content sources, source groups and search scopes in SharePoint Portal Server 2003.

The second step was integration of the existing internal Best Bets database, management tools and URL cataloging service (UCS). Originally developed to support earlier versions of Microsoft Web, these tools are used to manage Best Bets based through a workflow process and to import these Best Bet keywords and URLs into SharePoint Portal Server using Web services.

Microsoft IT deployed a central Shared Services server farm which provided search capabilities across the entire intranet for the organization. The Shared Services farm hosts one set of index servers. The full-text and keyword indices created on the central index servers support searches initiated from the central portal site, Microsoft Web and any other site that consumes search services offered by the Microsoft Web central portal site. Figure 4 illustrates that the index servers in the Shared Services farm crawl the content in each of the portal farms, as well as other sources of information available through the Microsoft intranet.

Figure 4   Shared Services Farm Indexing Strategy

In addition, the parent portal in each regional portal farm creates an independent index that is used to answer queries that originate from each farm. This allows portals in each farm to produce search results that exclude results from other portal farms and content sources.

Because results from searches of both the parent portal site (Microsoft Web) and child portal sites are provided by SharePoint Portal Server, Microsoft employees experienced a common and consistent search interface regardless of their location within Microsoft or their need to search for information on the Microsoft intranet.

By combining the search capabilities of SharePoint Portal Server and Windows SharePoint Services, Microsoft employees were able to control the range of their search:

• Enterprise. Users visit the search page for the central portal to conduct an enterprise-wide search for information from across all content and team sites. The central farm for Shared Services regularly crawls both the central and regional content to create comprehensive indexes that include content, user profiles and information for a site directory. In addition, these servers index other content for inclusion in the results of an enterprise-wide search. Enterprise search is based on categories and subjects internal or specific to the company.
• Division and group. Portal administrators can associate group portals located in one region with a division portal located in the central Redmond data facility. Search within a single group portal provides results for that portal, other portals associated with it, and any team site associated with those portals.
• Site. Users can conduct searches of team site content.

Figure 5 describes the way in which search relates to the design of the hosted collaboration platform and to other content sources on the intranet.

Figure 5   Search Ranges Available Within Microsoft

By default, team sites and personal sites that are associated with a portal site are automatically included in search indices and site directories. Even if the owner of a team site decides not to have it indexed for searching, the name of the site appears on the site directory.

As an alternative, KNG encourages site administrators to tag the key attributes of content, such as title, author and related description. Tags significantly increase the accuracy of search efforts because the attributes correspond with the title, author and description properties in Office documents as well as the HTML META tags in Web pages. For example:

<html>
<head>
<title>my document title</title>
<META name="author" content="John Doe">
<META name="description" content="my document description">
<META name="keywords" content="SharePoint, portals, shared">
</head>
<body>
...
</body>
</html>

When the author property is set, items returned in search results will trace back to particular authors through links to the author's My Site personal site. This makes it easy for users of an intranet to discover potentially relevant knowledge available on the author's Web site in addition to more obvious search results.

Web sites are automatically considered for indexing when they are created using the site creation or site registration forms and are added to the appropriate search source group.

To maintain the quality of search results, Microsoft uses the following criteria when reviewing the list of sites included in search:

• The business purpose and relevance of a site
• Timeliness of content: ideally, the content of a site is less than one year old. Sites with older content are considered on a case-by-case basis with inclusion depending on the subject area, product or initiative for which the site was originally targeted

Shared Services Search provides efficiency benefits to Microsoft both in terms of resources saved during deployment, ongoing operations and the improved employee search experience. Historically, many Web sites at Microsoft have created their own search solutions. By adopting Shared Services Search, these sites have seen efficiency gains by not having to configure, deploy and manage their own search solutions. At the same time, the corporate network load has been reduced by not having many servers crawling and indexing the same content sources multiple times.

To use Shared Services Search, portal site administrators need to ensure a number of conditions exist:

• A Shared Services content indexing account must be able to index all of the content on the portal site.
• The name and descriptive information for the portal site should be current before the site is configured to use Shared Services so that the information appears correctly in the parent portal Site Directory.
• The SharePoint Portal Server administration page is used to create local search scopes. These enhance the capacity by Shared Services to use centrally managed source groups, index catalogs and content sources.

Administrators of portal sites that use Shared Services Search benefit from the following:

• Barriers-to-deployment are lowered because each site does not need to configure and deploy its own search catalogs.
• Reduced duplication of effort saves resources for SharePoint site teams in terms of time, money, network bandwidth, storage and computing capacity.
• Easy deployment, management and upgrading of systems when using a single centralized solution.

Shared Services Search is currently used by over 250 portal sites including more than 16 Microsoft intranet portal sites that are not part of the central collaboration platform. These sites include: Human Resources, Sales Information, the Business Productivity Group and Product Support Services.

Notification Service

Notifications in Microsoft Office SharePoint Portal Server 2003 build on the concept of subscriptions in Microsoft SharePoint Portal Server 2001. Microsoft deployed this shared service "out of the box" without any custom development.

Users can request an alert about content changes on any site so that they are immediately aware of updates without actively searching for them.

Note   In a multiple portal farm configuration, users can view and manage alerts generated within their local portal farm from their My Alerts page available in their personal sites.

The portal site sends an alert to individuals whenever changes are made to the content for which they requested notification. Users can view their alerts on the portal site or receive them in e-mail messages. Furthermore, users can specify the frequency of e-mail alerts: immediate, daily or weekly.

In addition, Microsoft Office Outlook® 2003 users can view all of their portal and team site alerts from one place: the Outlook Rules and Notifications dialog box.

Audience Targeting Service

Rule-based definitions of an audience allow portal administrators to target content to users based on the values of properties that are contained in user profiles, the reporting structure of the organization, and Active Directory groups to which users belong. Administrators can publish both Web Parts, reusable components of a site that contain Web-based information, as well as content appropriate for one or more specific audiences.

This service makes it easy for Microsoft portal site administrators to use Active Directory to create audiences from existing distribution lists. Shared services in each region provide the audience feature to group and division portals. One example is the portal site for the Xbox® video game system product team. The site uses Shared Services and the audience targeting service to make distinct content available to different employees depending on whether the person works for the Xbox product group or not.

User Profile Service

When someone searches for employees within their organization, user profiles are used by search services to provide results that include employee names, phone numbers, office locations, record of documents with they have worked (honoring content permissions), and a link to their personal Web site. Data in a profile is updated on a weekly basis with fresh data imported from the Active Directory. The resulting benefit is that users do not have to manually update their user profiles. The user profile information is up-to-date and when searching for people, the results are more accurate.

Table 4 lists the properties employed by Microsoft in user profiles. All but three of the properties are standard for SharePoint Portal Server user profiles. Standard properties are imported automatically either from Active Directory or from the properties updated by a user through their My Site personal Web site.

Table 4   SharePoint User Profile Properties Used at Microsoft

Three user profile properties added by Microsoft were: MS Region, MS Role and MS Organization. These properties make it easy and fast for employees to search for and locate people within a particular geographic region, role or part of the organization. The vocabulary used to populate the custom properties of MS Region and MS Organization was based on the Microsoft corporate taxonomy. The values for MS Role are based on the title taxonomy used by Microsoft Human Resources.

Although not technically part of the Microsoft Shared Services deployment, Microsoft Web has two features that make special use of user profiles. First, the People Finder Web Part on the portal home page makes it easy for employees to quickly locate people in the company. It has a single field for entering search terms and returns a list of people whose user profiles match the search terms. Clicking on one of the search results displays the public view of My Site for that person. This Web Part was developed with Microsoft Visual Studio® .Net, ASP.NET and SharePoint Portal Server Search service.

The second notable feature is the Upload Picture Wizard which enables a user to obtain their picture from the identification card photo library on a secure basis and upload it as the picture displayed in the public view of their user profile. This photograph makes it easy for people visiting a personal site to learn or visually confirm the appearance of the site owner.

Finally, the SharePoint Portal Server Search function automatically includes user profiles in the portal site search scope. If the search term is a name or e-mail address, any exact matches are displayed at the top of the list of search results and marked with a star.

Configuration and Deployment

Microsoft IT staff paid particular attention to the configuration and deployment of server farms on which Shared Services were to be used. Figure 3 shows a logical representation of the centrally hosted collaboration platform. The full architecture includes a number of division portals and additional group portals associated with each of the division portals.

The centrally hosted collaboration platform hosts team sites and portals in a central content repository that is built on top of a Storage Area Network (SAN). The SAN provides up to 3.6 terabytes of database capacity in each farm. The portal and Shared Services farm in each region is an independent SharePoint Portal Server installation.

The three data centers described in Table 5 support the platform because they offer the best regional connectivity, high bandwidth, and capacity to support the SAN hardware. These regions are closely aligned with the management hierarchy within Microsoft.

Table 5   Centrally Hosted Collaboration Platform: Shared Services Farms

Redmond Central Data Center

Microsoft invested in advanced SAN technology to manage storage for the collaboration platform. This decision affected many other decisions including, in particular, the design of SQL Server 2000 installations that attach to the SAN.

Figure 6 shows the server farm architecture of the Redmond data center. This architecture supports the needs of Microsoft Web as the central portal site at Microsoft, in addition to serving as a Shared Services parent portal site.

Figure 6   Redmond Central Data Center: Logical Architecture

The data center infrastructure was designed as a clustered, high capacity and scalable system. Windows Network Load Balancing service was used on front-end servers to handle a high volume of traffic and to make further additions of servers straightforward.

The front-end Web servers store the ASP.NET Web Part assemblies and server logs, as well as ASP.NET code and application program interfaces (APIs) for Windows SharePoint Services. Front-end servers retrieve information from the configuration and content databases through SQL Server clusters that store data in the SAN. There is no interaction between the index servers and the front-end Web servers in this configuration.

Each region stores content databases on an Enterprise Virtual Array (EVA) storage area network (SAN) with mirror database drives to provide a maximum usable database capacity of 3.6 terabytes. The SAN uses a redundant gigabit Ethernet to connect with the Web front-end servers. And with the exception of the SAN hardware, all of the servers use configurations approved for Microsoft data centers. The regional data center IT staff had installed and managed the hardware. Server specifications for hardware deployed in the main data center are detailed in Table 6.

Table 6   Redmond Shared Services Farm: Server Configurations

Regional Data Centers

Each data center has a Shared Services farm to provide services within each region and, through association with the central Shared Services, provide these services on a global basis. Because the demand for Shared Services in the Dublin and Chofu regions is lower than in Redmond, the front-end servers are included in the Shared Services farm at Redmond. Figure 7 illustrates the servers deployed in the regional data centers in Chofu and Dublin.

Figure 7   Logical architecture for regional data centers

Because there's a relatively small number of users located outside of Redmond, the project team configured the Dublin and Chofu data centers with two-node SQL Active/Active Passive clusters smaller than the one found in Redmond. A primary node was set up to host all content and configuration databases. The passive node was configured to take over the load in case of failure. SQL Server 2000 was installed on each node with storage in the fiber-attached EVA SAN enclosure.

Table 7 lists the regional server requirements for Dublin and Chofu. The requirements are identical one region to the next, except that the SAN storage is larger for Dublin than for Chofu.

Table 7   Regional Shared Services Farm: Server Configurations

* Includes team site storage.

Microsoft IT Server Requirements and Considerations

During the design phase of the project, the team decided that is was important to balance the load on front-end servers. The front-end servers did not contain user data. The team used them specifically to handle the HTTP traffic and interface rendering functions for the data stored in the back-end SQL Server 2000 database. Windows Network Load Balancing was used to direct incoming HTTP requests to the available front-end servers.

The central Shared Services farm and team site farm is built as a three-node SQL Server Active/Active Passive cluster to support high availability on a global basis. Two active nodes with resources primary to each of them is configured with half the content databases load-balanced, based on database size across the two active nodes. The third node is passive and set to pick up the load if either node fails. The databases are set up on the same node for data consistency. Because projected storage requirements for the team and portal farm in Redmond exceed the 3.6 TB storage capacity of a single SAN, an EVA SAN with 412 GB shared storage is used for the portal and shared services farms. This SAN can be expanded with additional storage as required.

The hard disk drives are configured to provide optimum disk I/O performance with half the databases on one drive and half the databases on another, in two separate storage groups. For easy troubleshooting and maintenance, the project team minimizes complexity by keeping the number of resource and storage groups low.

The amount of disk space initially configured in the SAN was determined by calculating the existing SharePoint Team Services content in the region and adding 25 percent for growth. Unused disk space was left unformatted so that it would remain available for growth. In addition, Microsoft planned to purchase more disks when necessary to take advantage of decreases in disk cost over time.

The team estimated server requirements based on the size of the index for the Microsoft Web portal plus the anticipated index for new SharePoint sites. This sum was multiplied by three to accommodate growth and to include a margin of safety for future growth. This calculation suggested that the two index servers needed to support 100 GB of disk space each while the search servers required 200 GB (search servers aggregate the results produced by each of the index servers).

The search servers were deployed in pairs in the central services farm, to ensure that content would be available if one server was unavailable. Microsoft needed neither Windows Network Load Balancing services nor a hardware load-balancing solution because SharePoint Portal Server Search maintains the necessary table of available search servers.

Index servers crawl all content across the team site farms, as well as files stored in the site directory of the portals. The SharePoint Portal Server Job service runs on one of the index servers to keep track of content alerts and scheduled processes. The second index server provides additional resources for monitoring disparate sources of content, such as portals, site directories and custom configurations. Every night, these servers propagate the indexes to search servers to update information available for search.

The SQL Servers are deployed in two different configurations for storage. The central team site farm uses three SQL Server computers. The Shared Services farms for Redmond, Chofu, and Dublin each require two SQL Server computers.

The world-wide deployment of SharePoint Products and Technologies and the Shared Services infrastructure provide a platform for delivering additional valued-added services.

Groups that want to extend this platform and build add-on services for their customers work with the appropriate internal groups for consultation, custom development, and support. As of this writing, two additional groups, the Sales and Support group and the Finance group operate custom portals configured to consume Shared Services. The ability to consume enterprise Shared Services enables these groups to quickly build and maintain solution portals with custom Web Parts, while taking advantage of the economies of scale provided by centrally hosted back-end servers.

Operations

Provisioning Portal Sites

A key factor in the broad adoption of the centrally hosted collaboration platform is the ease with which users can create sites and initiate use of the platform.

Business groups inside Microsoft with a need to organize and highlight content can create SharePoint Portal Server 2003 portals that aggregate related team sites and provide search across those sites. With the collaboration solution infrastructure in place, IT needs only to approve an online portal request form that details the business reason for the portal, owner and co-owner, and provides meta-data about the purpose of the portal for association with other portals. All portals used English templates, because SharePoint Portal Server 2003 supports one language per server farm.

Server and Help Desk Support

Microsoft IT provides server support as well as backup/restore and disaster recovery services as a managed Windows server and a centrally hosted collaboration platform service.

The Microsoft IT Help Desk provides first level response to employees and escalates their response as required to appropriate internal and external support groups.

Maintaining Shared Services

While a majority of the Shared Services management functions are automated or available on a self-serve basis, KNG provides the resources for day-to-day selection of new sites for inclusion in source groups, Best Bets and the enterprise Site Directory.

Conclusions

"Before shared services we provided search to one portal at a time—a one-to-one relationship. Now with shared services the KNG team has a one-to-many relationship. We can deploy services to hundreds of portals by deploying the service just once."

Mary Lee Kennedy, Director
Knowledge Network Group
Microsoft Corporation

SharePoint Portal Server 2003 Shared Services is an effective and low cost way to deploy common search, notifications, audience targeting and user profile services across a large number of portal sites. Shared Services are standard features of SharePoint Portal Server 2003 that can be configured and managed centrally so that portal administrators need not worry about maintaining these services themselves.

Business Benefits

The key business benefits gained by Microsoft through the deployment of SharePoint Portal Server 2003 Shared Services included:

• Employees experienced improved productivity when they received a convenient and consistent intranet portal experience that made it easier for them to find and retrieve task-relevant knowledge and information.
• Systems administrators gained the ability to effectively and easily support a large world-wide intranet portal infrastructure consisting of a central intranet portal site and hundreds of business division, product group, regional and subsidiary portal sites deployed in three regional data centers

Group and Division Portals

Administrators of portal sites can take advantage of Shared Services that are common across a company. In general, use of services across an enterprise can reduce training costs and help desk calls. Furthermore, a Shared Services infrastructure avoids duplication of services for each portal. Network traffic created by a centralized indexing service is less than traffic created by numerous SharePoint Portal Server installations that independently crawl content.

One example of the way in which Shared Services solve a business problem relates to the definition of search scopes for the collaboration platform. For example, if a group with content in one regional data center wants content and a portal hosted in that region, but also need it included in the search scope of a division portal hosted in a central data server, then they can associate it with a parent division portal and still include it in both the regional search and the divisional search for the organization.

Enterprise Services

The advantage of a deploying a common set of core portal services across Microsoft includes:

• Better decisions are made across the company when relevant information is easy for employees to find using enterprise search capabilities.
• Information workers are able to focus on business issues while Microsoft IT reduces costs for common portal services.
• Economies of scale are created for KNG and Microsoft IT because Shared Services enable them to implement shared best practices from a single central location and offer common high volume services across the global enterprise.

IT Benefits

Microsoft IT benefited from the deployment of SharePoint Portal Server 2003 Shared Services by:

• Deploying fewer servers to support shared services on a central platform than would otherwise be required with a distributed approach. Fewer central servers results in lower hardware costs, lower deployment costs, increased server processor and storage utilization, reduced server management costs and improved service level agreements.
• Maintaining fewer index servers supporting fewer search servers avoids increased network load and provides more consistent service levels.
• Centralizing search configuration including content sources and search scopes so that they are less costly to administer from the central parent portal site.

Lessons Learned

Portal Hierarchy

At Microsoft, one team is responsible for managing the central portal site, Microsoft Web, while Microsoft IT provides the management and support for Windows servers and the centrally hosted collaboration platform. Only selected information from group and division level portals appears on Microsoft Web. While the strategy for Microsoft is to roll up division level portals directly into Microsoft Web, other models may be appropriate depending on an organization's approach or objectives. Based on Microsoft experience, it is important to involve business leaders in the process of designing the relationship between enterprise portals. It results in faster decisions and encourages greater company-wide acceptance.

The portal hierarchy also affects search scope. Because groups and divisions are important for organizing Microsoft, it makes sense that users can search all sites pertinent to a division from the division portal.

Differentiating the Need for a Team Site Versus a Portal

Because groups at Microsoft previously needed a SharePoint Portal Server 2001 portal to get certain collaboration features, they assumed they also needed a portal in SharePoint Portal Server 2003. However, because document collaboration features were present for team sites using Windows SharePoint Services, many teams were successful using team sites without full portal functionality. Portals were allocated instead to larger groups and divisions that required search across related sites, audience targeting, topics, and Site Directory.

Operational Considerations

Organizations should consider the following before providing or using Shared Services:

• Farms providing and using Shared Services must be running the same version of SharePoint Portal Server using the same language.
• A firewall cannot be used between server farms providing and using Shared Services. Both server farms must be on the intranet, on the extranet, or in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet).
• Back up the server farm before configuring it to provide or use Shared Services. After the server farm has been configured for Shared Services, the operation cannot be undone.
• Some services and scheduled tasks in a server farm need to be turned off before the server farm is set up to use Shared Services. These services and tasks include the Microsoft SharePoint Portal Server Search service (SharePointPSSearch), search schedules, profile import, and the audience compilation schedule.
• After configuring a server farm to provide Shared Services, all other portal sites on that server farm become child portal sites.
• Server farms providing and using Shared Services must belong to the same domain or trusted domain.
• Services are shared at the server farm level. All portal sites on a server farm that uses Shared Services will, therefore, be child portal sites.
• A child portal site can never be changed into a parent portal site.
• When the server farm is configured to use Shared Services, services that are no longer required on the server farm using Shared Services are disabled.
• Backup the server farm immediately after configuring it to use Shared Services in order to preserve the initial state and configuration of the farm.

Security Considerations

• The portal site application pool for the server farm using Shared Services is, by default, a member of the "db_owner database role" in SQL Server on the profile, component settings, and content databases for the parent portal site.
• The configuration database administration account for the server farm using Shared Services is a member of the db_owner database role in SQL Server on the configuration database for the server farm providing Shared Services.

Summary

SharePoint Portal Server 2003 Shared Services is a set of centrally managed, highly scalable, core portal services designed to be re-used across multiple portal sites and multiple-server server farm configurations. Core portal services used by Microsoft include:

• Enterprise indexing, search and retrieval services
• Self-service, centrally managed notification services
• Audience-based content targeting capabilities
• User profile creation and management

With a large and growing number of stand-alone intranet portal sites, Microsoft wanted to provide a consistent intranet experience that would help Microsoft employees, world-wide, to work efficiently and productively.

The Microsoft Knowledge Network Group worked in conjunction with the Microsoft Information Technology group to deploy Shared Services on a central basis to address the problems found when operating hundreds of portal sites in Microsoft:

• Need to support a large, world-wide intranet portal infrastructure consisting of a central intranet portal site and hundreds of business division, product group, regional and subsidiary portal sites. The central deployment and management of Shared Services enabled the initial configuration and subsequent changes to be made once and re-used across the shared services environment.
• Desire to help Microsoft employees find and retrieve relevant information and knowledge more efficiently regardless of where they began their search on the intranet.

The key business benefits gained by Microsoft through the deployment of SharePoint Portal Server 2003 Shared Services included an enhanced quality of experience for employees and improved productivity for both intranet users and systems administrators.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itsolutions/msit/default.mspx

http://www.microsoft.com/sharepoint/

For any questions, comments, or suggestions on this document, or to obtain additional information about Microsoft IT Showcase, please send e-mail to:

showcase@microsoft.com

Appendix A – SharePoint Portal Server 2003 Server Farm Design Recommendations 

The following two tables provide organizations with guidance with respect to which SharePoint Portal Server configuration they should deploy in terms of:

• Single portal servers
• Small, medium and large server farms
• Multiple server configurations including farms deployed with SharePoint Portal Server 2003 Shared Services

Table 8   Design Recommendations, Part 1: Single Server and Small Server Farm

Table 9   Design Recommendations, Part 2: Medium and Large Farms and Shared Services

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Microsoft grants you the right to reproduce this White Paper, in whole or in part, specifically and solely for the purpose of personal education.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.

© 2004 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Outlook, SharePoint, Visual Studio, Windows and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.