Technical White Paper

Published: January 25, 2008

Contents

Executive Summary

Introduction to MSW

Organization

Business Benefits

MSW Portal Design

MSW Portal Development

MSW Portal Deployment

MSW Portal Operations

Conclusion

Executive Summary

Knowledge portals are more important to organizations today than ever before. The more than 120,000 employees, contractors, and vendors at Microsoft create an increasing amount of digital information that pertains to their job responsibilities. Employees access much of this information through the Microsoft primary knowledge portal, MSWeb (MSW for short).

The Microsoft intranet contains a number of information sources, of which MSW is one of the primary access points to the hundreds of intranet sites at Microsoft. MSW helps employees find information, stay informed, and make productive use of the company intranet. Employees can find everything from the latest editorially selected news to accessing the campus map for their region. Users gain access to information on MSW through browsing, through navigation, and through the enterprise search capabilities in Microsoft® Office SharePoint® Server 2007.

Maintaining the previous version of the portal involved extensive manual work, including creating daily home pages and copying news stories to category specific pages and archive pages. Publishing some of the content was also a manual process, often managed via e-mail requests. This manual process made following MSW styles and guidelines difficult, which resulted in an inconsistent site design. Microsoft wanted to improve portal administration and site design, simplify navigation and publishing workflows, and enhance search capabilities to deliver an even more valuable resource to employees.

Microsoft took advantage of the powerful new features in Office SharePoint Server 2007 to improve the MSW portal. Rather than upgrading the existing solution, Microsoft took the opportunity to redesign MSW so that it could move away from many custom solutions, site definitions, and layouts that existed in the previous versions. MSW was one of the first sites migrated to Office SharePoint Server 2007 and was deployed in production while the product was still in the beta stages.

The resulting efforts transformed MSW into an award-winning portal that improves employee satisfaction, streamlines and automates the content publishing process and workflow, improves the ability to find content and people, and provides tighter integration with line-of-business applications. At the same time, Microsoft was able to reduce dependency on custom-written code and reduce the effort to administer and support the solution.

Note: The reason MSW won the award was the quality of user experience on the portal, not the fact that the portal is based on Office SharePoint Server 2007. However, the goal of this paper is to illustrate how companies can build effective, usable, and maintainable sites based on Office SharePoint Server 2007 instead of a fully custom-developed solution.

The purpose of this white paper is to:

• Describe the business benefits realized by creating the improved version of the MSW portal solution.
• Document the experiences and lessons learned during the design and deployment process of the solution.
• Highlight the instances in which Office SharePoint Server 2007 features were customized to create the solution.
• Highlight the instances in which customized code was developed to create the solution.

This white paper focuses on the business decision makers (BDMs) and technical decision makers (TDMs) who want to know how Microsoft developed the MSW portal. This paper can help these decision makers learn from the experience that Microsoft gained in its design, development, deployment, and operations processes.

Although both types of decision makers can benefit from reading the entire white paper, specific sections were written with a specific decision-maker audience in mind. Table 1 lists each major section in this white paper and the decision maker who will most benefit from the content of that section.

Table 1. Decision Makers Targeted for Each Section

This paper assumes that readers are familiar with SharePoint technologies. Many of the principles and techniques that this paper describes can be employed to manage risk within any organization, and design considerations can likewise be applied to most enterprise-scale IT environments through Microsoft products. However, this paper is based on the experience and recommendations of Microsoft as an early adopter. It is not intended to serve as a procedural guide. Each enterprise environment has unique circumstances; therefore, each organization should adapt the plans and lessons learned described in this paper to meet its specific needs.

Introduction to MSW

Each day, Microsoft employees around the world are inundated with information from e-mail, instant messenger, intranet sites, scheduled meetings, and even conversations in the hallways. These users need a trustworthy source of daily information to be more productive and informed in their jobs. MSW helps these users perform many of their daily tasks.

According to the MSW Spring 2007 Annual Satisfaction Survey at Microsoft, more than 70 percent of respondents keep MSW as their Windows® Internet Explorer® home page. According to Web traffic data, more than 75 percent of all employees visit MSW each month, with an average of 14 visits. This data confirms that MSW is the primary information and knowledge portal for Microsoft employees.

MSW is also the site where employees start their search for information within the company. The MSW home page typically includes the following information:

• Global top and local navigation that helps users locate information about common tasks, products, and services
• Current news stories about Microsoft, the IT industry, and the world
• Locations of buildings on the Microsoft campus
• Self-help about employee benefits and services, and about technical issues
• Information for new employees
• Frequently used links to other resources
• Commonly visited portals
• Popular search terms
• Community elements (such as blogs)

Figure 1 illustrates the MSW home page.

Figure 1. Typical information on the MSW home page

MSW is a publishing portal. A publishing portal is very similar to a webzine or a magazine. Microsoft publishes articles, columns, features, and other content through MSW. Publishing portals include publishing elements such as content authoring, content moderation, workflow, layout page, page rendering, content aggregation, and search features. One of the essential requirements for a publishing portal is the ability to complete the publishing workflow efficiently and quickly. One of the design goals for the new MSW is to reduce the complexity of the publishing process and to automate the process as much as possible.

MSW includes content created by:

• MSW-specific editors. These editors are similar to the editorial team for a magazine or newspaper. Although business groups create some of the content for MSW across the company and external news sources, the MSW editorial team also creates a significant amount of original content.
• Other service owners. MSW hosts content—as sites or individual pages—on behalf of other business units. This content is specific to the services that the business unit provides, and the service owners create it. For example, content from the Real Estate business unit provides campus maps for users.

In addition to this content, MSW provides the primary search services for thousands of other sites and resources on the Microsoft intranet.

Organization

The Microsoft teams that were involved in the design, development, deployment, and operations of MSW include Microsoft Information Technology (Microsoft IT), the MSW team, and the Office SharePoint Server 2007 product team.

Microsoft IT

Microsoft IT is different from most other IT organizations because its first priority is being the first and best customer of Microsoft. Microsoft IT adopts this priority to help ensure that Microsoft products are thoroughly tested in a production environment prior to their delivery to customers. This priority enables Microsoft IT to provide feedback to the product groups on technologies, features, processes, and procedures that are required to run Microsoft products in a large enterprise environment. For example, from an operational perspective, this priority means that Microsoft IT may leave a server offline longer than another organization might if the team believes it can get valuable data from the server that will help the development teams improve Microsoft products.

Microsoft IT deployed the MSW search service internally starting with Beta 1 of Office SharePoint Server 2007, and it deployed the remainder of the portal with Beta 2 of Office SharePoint Server 2007. A major consideration for early deployment of Office SharePoint Server 2007 was to provide feedback to the product team.

Microsoft IT's second priority is providing excellent service to employees. Microsoft IT must ensure that its services meet or exceed the business and technical requirements of the various internal business groups that use the services.

The team's third priority is sharing best-practice information with Microsoft customers. Because Microsoft IT runs software prior to release, it can transfer as much knowledge about its experiences to customers (such as this white paper and other documents).

The following teams within Microsoft IT have specific responsibilities in managing MSW:

• Information Services team
• Operations team
• Engineering team

These teams are shared resources that manage other sites and services within Microsoft in addition to managing MSW. As such, these teams do not devote 100 percent of their efforts to managing MSW.

Information Services Team

The Information Services team is responsible for information dissemination, portal strategies, and collaboration platform strategies within Microsoft IT. The Information Services team plans and implements all SharePoint customizations, creating and testing proof of concepts, changes to the production environment, changes to production code, and sustained engineering for all solutions.

This team consists of nine members who manage projects for custom portals, including MSW and all shared services.

Operations Team

The Operations team maintains the server infrastructure, incident management, end-user technical support, Helpdesk training, monitoring, upgrades, patch management, hotfix management, and backup and restore services.

This team supports shared services, custom portals, and collaboration service hosting. It contains 14 team members, including one member dedicated to Shared Services Provider (SSP) management.

Engineering Team

The Engineering team is responsible for designing new deployments or infrastructure changes, testing, and publishing documentation and guidance. It also provides detailed guidance, operations, and configuration documents to the Operations team.

MSW Team

The MSW Team is responsible for Microsoft's employee portal, MSW, a key communications channel connecting employees with information, their co-workers as well as company executives, business groups and service providers. Working with their partners in Microsoft's Corporate Communications, the team designs, updates and sustains the site for optimal user experience, including information architecture, navigation, branding, content management and programming, publishing and hosted services. Based on traffic data, user feedback and industry trends, the MSW Team develops and prioritizes business requirements for site features and functionalities, working with the Information Services Team through technical implementation and deployment.

Office SharePoint Server 2007 Product Team

The Office SharePoint Server 2007 product team provides guidance on the features and configuration settings to Microsoft IT. In return, Microsoft IT provides feedback on the use of Office SharePoint Server 2007 in the Microsoft production environment and feedback on end-user experience. Much of the feedback that Microsoft IT provides results in new features or enhancements to the deployment, administration, and monitoring of the product.

Business Benefits

Like any other organization, Microsoft needs to realize a bottom-line benefit of a solution to the day-to-day business functions. Some of these benefits are objective, such as the financial savings in the effort required to support the solution and the improvements in employee efficiency in locating information. Other benefits are subjective, such as employee satisfaction with the solution.

Microsoft gained the following benefits when it created the new MSW portal:

• Improved employee satisfaction with the solution
• Streamlined and automated content publishing processes and workflow
• Improved ability to find employees and subject matter contacts
• Improved ability to locate relevant content
• Tighter integration with line-of-business applications
• Improved availability
• Reduced dependency on custom-written code
• Reduced effort to administer and support the solution

Improved Employee Satisfaction with the Solution

The revised MSW solution has improved the user experience and overall employee satisfaction by:

• Providing consistent site branding. Regardless of the content that users view, all content looks consistent. This consistency entails not only having common cascading style sheets, but also defining set layouts, breadcrumb trains, or image standards. Consistent site branding enables users to focus on the content and not on locating the content. Office SharePoint Server 2007 includes many new features (such as master pages and layout pages) that made this consistent site branding possible.
• Improving site navigation. The MSW team invested extensive effort in creating an intuitive site navigation hierarchy. This effort resulted in the ability of users to find relevant content faster than in the previous solution. The new Office SharePoint Server product features (such as the global navigation control, current navigation control, breadcrumb navigation control, and Content-by-Query Web Part) and the implementation of those features on MSW supported this business effort.

Streamlined and Automated Content Publishing Processes and Workflow

One of the more complex parts of the previous solution was the process and workflow for publishing content. One of the design goals for this version of MSW was to simplify the workflow by providing more automation of the process.

Microsoft improved the processes and workflow for publishing content by:

• Centralizing content management. Centralization of content management enables the MSW team to publish a larger amount of content with fewer people, without sacrificing the consistency of the content and user experience. Centralizing the content management made it easier to automate the publishing process and to reuse content by using the new features in Office SharePoint Server 2007 (such as workflows and integration with the Microsoft Office InfoPath® 2007 information-gathering program).
• Automating more of the content publishing process. Automation helps reduce the effort required to publish content and helps eliminate errors introduced by manual steps in the process. Automating steps also helps enable fewer people to publish a larger amount of content.
• Simplifying content authoring. Centralizing and automating the content publishing process helps simplify the content authoring process. This simplification of the process enables individuals who are closest to content make decisions about content relevancy and what content to publish.

Improved Ability to Find Employees and Subject Matter Contacts

Office SharePoint Server 2007 includes the ability to search for employees by using the People tab in Search Center. In an organization the size of Microsoft, collaboration between teams is very important. For example, at Microsoft, someone on the Windows Vista® team who is working on authentication may need to locate someone on the Windows Server® team who is working on the Active Directory® directory service.

Employees are located based on any of the typical employee attributes (such as name, office, department, or job title) in addition to expertise (such as developer, technical writer, or government sales). The ability to locate other employees quickly and based on meaningful criteria makes collaboration on a project more efficient. Employee information is imported from other sources into the profiles in Office SharePoint Server 2007. Then, the search services index the information and make it available.

Improved Ability to Locate Relevant Content

Locating relevant content is essential to enterprise portal solutions. An effective search solution returns a small number of highly relevant results. Search solutions that return a large number of irrelevant results:

• Frustrate users.
• Decrease user efficiency.
• Increase overall employee costs.
• Negate the reason for deploying enterprise search.

Microsoft improved the ability to locate relevant content by:

• Tagging content by using keywords and descriptive text. The content stored on Web sites, SharePoint sites, and other content sources can be crawled and added to the search index. Office SharePoint Server 2007 includes improved algorithms for taking advantage of metadata to help improve the relevance of search results.
• Returning specific results based on a combination of keywords. For a specific combination of keywords, Office SharePoint Server 2007 can identify specific results also known as Best Bets. The Best Bets feature enables the Information Services team to identify the best possible results for a combination of keywords. In addition, Best Bets results can even include content that is not indexed. Best Bets keywords are editorially managed as a manual process, not an automated process.
• Identifying keywords by using synonyms of the keywords. Microsoft SharePoint Portal Server 2003 and Office SharePoint Server 2007 support the identification of keywords by using synonyms of the keywords (also known as keyword synonyms). In SharePoint Portal Server 2003, new synonyms are not immediately queried in the search results. In Office SharePoint Server 2007, new synonyms are immediately queried in the search results.
• Centralized indexing of all content. Providing a centralized index of content on the Microsoft intranet provides one authoritative source for finding content. In prior solutions, employees searched content by using a variety of methods (such as looking up employees in the Microsoft Exchange global address list [GAL] or using search facilities within each site).
• Searching of structured data sources. Office SharePoint Server 2007 supports the ability to index and search information stored in any relational database or information store. This feature allows content stored in these structured data sources to be returned in the same search results as other types of content. Office SharePoint Server 2007 supports any information store supported by:
  • Microsoft ADO.NET.
  • Any Web service that returns structured data.

Tighter Integration with Line-Of-Business Applications

Not only do Microsoft employees need to locate information on Web sites, in document libraries, or in shared folders, but they also need to locate information managed by line-of-business applications. Office SharePoint Server 2007 Enterprise Edition includes the ability to access data managed by line-of-business applications, such as a customer relationship management (CRM) system. Employees can access this data:

• Directly from structured data sources.
• Through applications registered in the Business Data Catalog.

This ability encourages employees to use the Enterprise Search feature in Office SharePoint Server 2007 as the centralized, single point for locating information on the Microsoft intranet. For example, Microsoft integrates customer information stored in an internal CRM system with book data from the internal Microsoft library catalog.

Improved Availability

Because multiple sites use the shared services, Microsoft designed an architecture that lends itself to higher availability and end-user uptime. The following features of the solution help improve overall availability:

• Centralized architecture of all mission-critical products and technologies. The user interface and business logic components run on Office SharePoint Server 2007 and Internet Information Services (IIS) version 6.0. The solution stores the content and search indexes in a database managed by Microsoft SQL Server® 2005 database software. All of these products and technologies run on centralized server farms that are easier to monitor and manage. That helps eliminate problems before they occur, which increases availability.
• Clustering technologies for mission-critical products and technologies. Both of the mission-critical products (SQL Server 2005 and Office SharePoint Server 2007) run in clusters to improve availability. SQL Server 2005 runs in a cluster that is running the Cluster service with an active/active cluster node configuration. SharePoint Server 2007 runs in a cluster that is running Network Load Balancing. These configurations provide fault tolerance (which helps improve availability) and better scaling (which helps improve performance).

Reduced Dependency on Custom-Written Code

The previous version of MSW contained custom-written code that extended the out-of-the-box features in SharePoint Portal Server 2003. One of the primary goals of re-architecting MSW was to dramatically reduce the amount of custom-written code. Instead, Microsoft wanted to configure out-of-the-box features in Office SharePoint Server 2007.

Reduced Effort to Administer and Support the Solution

Deploying Office SharePoint Server 2007 reduces the effort required for administration and support in the following ways:

• Improvements in monitoring. Usage reporting is also new in Office SharePoint Server 2007. A number of reports are available to view search-related statistics. These reports can be Microsoft Office Excel® or Adobe Portable Document Format (PDF) documents. The reports available provide information about:
  • Popular searches.
  • Searches with zero results.
  • Queries where users did not navigate to any results (also known as low click-through rates).
  Administrators can use these reports to adjust relevancy so that the appropriate keywords return the right content.
• Role-based security. Administrators can create user roles based on the types of users that access the enterprise shared services. These roles are used to determine the kind of information that users can view. Administrators can assign roles to users and assign access control permissions to the roles.

MSW Portal Design

MSW is a publishing portal, so Microsoft optimized the design for use as a publishing portal. Other portal types may not follow the same design process that this paper describes.

Examples of other types of portal sites include:

• Authoring and collaboration portal site. This type of portal site supports users who work together to produce content. Often, this type of portal site includes collaborative content that is not published but is only used internally, along with content intended for publication to an outside audience.
• Application portal site. This type of portal site provides a Web-based view of business applications. Examples of these types of sites include:
  • Microsoft Office Project Server 2007 portal site. This portal site supports the schedules and processes tracked in Office Project Server 2007.
  • Microsoft Office Excel Web Access portal site. This portal site makes shared spreadsheets available to site users. Those spreadsheets often include other business data made available via the data connection library and the Business Data Catalog.

For more information about these other types of portal sites, refer to "Plan Web Site Structure and Publishing (Office SharePoint Server)" at http://technet2.microsoft.com/Office/en-us/library/6a4b0ec4-8802-40f9-87ac-6a6691b544a41033.mspx

Deciding to Create a New Portal

One of the first decisions that Microsoft made was whether to create a new MSW portal or upgrade the existing MSW portal (based on SharePoint Portal Server 2003). Although both options have advantages and disadvantages, Microsoft elected to create a new portal because it wanted to:

• Make dramatic changes to the information architecture so that users can locate information more easily than in the previous portal.
• Make dramatic changes to the site branding and overall appearance of the new portal.
• Incorporate the new out-of-the-box features in Office SharePoint Server 2007 to replace custom-developed features and workflows in the previous portal.
• Make dramatic changes to the publishing process that existed in the previous portal.
• Reduce the dependency on customized code that existed in the SharePoint Portal Server 2003 solution.

Deciding to Use Existing Features

Another decision that Microsoft made early in the design process was to use as many of the new out-of-the-box features in Office SharePoint Server 2007 as possible instead of creating new features by developing custom code. The reason for this decision is that Microsoft wanted to:

• Reduce the amount of effort and time required to develop the new portal.
• Minimize the amount of custom code that had to be supported long term.
• Illustrate how to create an effective enterprise portal by predominantly using Office SharePoint Server 2007 features.

However, when custom code was necessary, developing it required less effort because of the improvements in the Office SharePoint Server 2007 architecture (such as the improvements to the object model, publishing features, and other features).

Determining the Branding Strategy

The goal of the branding strategy is to provide a consistent voice, tone, and character to all content on the site. The MSW team created early iterations of the branding strategy in graphics design programs (such as Adobe Photoshop).

These first iterations enabled the MSW team to design the early versions of the master pages and layout pages. Later in the design process, the Information Services team implemented the graphical versions of these pages in Office SharePoint Server 2007 by using Microsoft Office SharePoint Designer 2007. In some instances, modifications were required to the branding strategy to accommodate how pages are rendered in Office SharePoint Server 2007.

In the later stages of the design process, the MSW team included actual content instead of fictitious content (such as repeating words in Latin). The reason the team included actual content is that it was certain of the layout page and how live content would fit within the master pages and layout pages.

For more information about how to customize and branding sites, refer to "Customizing and Branding Web Content Management-Enabled SharePoint Sites" at http://msdn2.microsoft.com/en-us/library/aa830818.aspx.

Creating Information Architecture Design

A portal's information architecture determines how the information in that site—its pages, documents, lists, and data—is organized and presented to the site's users. Information architecture is often recorded as a hierarchical list of site content, search keywords, data types, and other concepts. The final output of the information architecture design is the site navigation.

The MSW team performed an information architecture analysis to determine the structure of the MSW portal. By dividing the information architecture into business processes, projects, or large content groupings, and by using those divisions to sketch out a hierarchy of subsites and content within each site, the MSW team was able to plan where information belongs within that hierarchy. For more information about planning the structure of Internet and intranet sites based on Office SharePoint Server 2007, refer to:

• "Determine the Information Architecture of Your Site" at http://technet2.microsoft.com/Office/en-us/library/7a74c8bf-83a2-4ee1-82e7-c2e9dee789361033.mspx?mfr=true.
• "Determine Sites and Subsites" at http://technet2.microsoft.com/Office/en-us/library/462e12d6-1a5d-4b7c-a0d5-14c551262be11033.mspx.

As part of the data collection phase in the information architecture design, Microsoft identified and analyzed the content in the previous version of MSW by:

• Reviewing the business goals. MSW's business goals had expanded significantly since the design of the previous MSW portal. The information architecture of the new MSW portal design reflected the additional content offering and programming. Achieving these goals was essential for the success of the new portal design and for satisfying the business sponsors for the new portal.
• Creating a content map. A content map contains all the new and existing content to be published through the portal. The MSW team created the content map for MSW as an Office Excel spreadsheet. The first draft of this content map contained all content—the navigation configuration information for approximately 1,700 pages. Duplicate or outdated content was eliminated from the content map later in the design process. The MSW team used the content map to:
  • Plan the site structure. By analyzing the content in the content map, Microsoft ultimately created the site hierarchy.
  • Identify the pages that use the same layout pages and content types. This information helped Microsoft determine the number of master and layout pages that would be required in the new MSW portal.
  • Determine how to display pages on the navigation bars and breadcrumb controls. The navigation model in Office SharePoint Server 2007 reflects the folder structure stored in the database back end.
  • Determine when to create separate sites or libraries. Because the navigation bars and breadcrumb controls reflect the database back end, the content map helped Microsoft identify when to create separate sites or libraries instead of creating folders within existing sites or libraries. Pages libraries cannot contain nested folders, so all content exists at the same level.
  • Identify content that was no longer needed. The content map also helped the MSW team eliminate content that was duplicated on other portals, no longer needed, out of date, or no longer applicable to the current business goals.
• Using an iterative process to create the final design. Microsoft created many iterations of the information architecture design before completing the design. Although the first iterations were rough, Microsoft refined its design with each iteration. Also, team review and feedback of the portal design introduced iterations in the process of creating the final design.

Creating Site Hierarchy Design

The site hierarchy design relies heavily on the content map that Microsoft created earlier in the design process. As mentioned earlier in this paper, Microsoft optimized the site hierarchy design for use as a publishing portal. Other portal types may not follow the same design process that this paper describes.

The purpose of the site hierarchy design is to specify the navigation flow of the site. The decisions made during this step in the information architecture design included determining:

• When creating site folders is more appropriate than creating new sites. Creating a separate site or library dramatically affects the navigation bars and breadcrumb controls because it affects the navigation bars and breadcrumb controls at a higher level in the site hierarchy. Creating folders within existing sites or libraries has less of an effect on the navigation because the changes occur at a lower level in the site hierarchy.
• How to manage pages in the Pages library. On a publishing site, Web pages are stored centrally in the Pages library. There is only one Pages library per site. A check-in and check-out system ensures that only one person at a time edits the pages, and the versioning feature helps track the changes. In instances where Microsoft needed more than one Pages library, it created additional sites. For example, if a different publishing workflow was required for the pages in a Pages library, a separate Pages library was necessary for each publishing workflow.

Creating Site Navigation Design

Site navigation provides the primary interface for site users to move about the sites, subsites, and pages that compose a portal site. Office SharePoint Server 2007 includes a set of customizable and extensible navigation features that help orient users.

Navigation links in Office SharePoint Server 2007 are security sensitive. If a site user does not have permissions to a site or page that is linked from the site navigation, the user will not see the link. Also, pages and subsites can be configured to be available only to members of an audience. Users who are not members of that audience will not see links to sites and pages targeted at that audience.

Office SharePoint Server 2007 includes navigation controls that can be displayed on master pages, on layout pages, and directly in a page's content in Web Part zones. The out-of-the-box navigation controls in Office SharePoint Server 2007 include:

• Global navigation across the portal.
• Current, or local, navigation within the current site.
• Breadcrumb navigation to represent current location within the site hierarchy.
• Navigation controls on the various pages.

Each of these navigation controls can be customized via Office SharePoint Designer or the Microsoft Visual Studio® development system. For more information about creating site navigation design, refer to "Plan Site Navigation (Office SharePoint Server)" at http://technet2.microsoft.com/Office/en-us/library/89bc3f15-d823-445f-9bea-27d5abf3b4881033.mspx?mfr=true.

Figure 2 illustrates the use of global and current navigation on the MSW home page.

Figure 2. Navigation controls on MSW home page

The navigation model in Office SharePoint Server 2007 reflects the folder structure stored in the database back end. For example, the breadcrumb controls natively recognize folders and subfolders. The navigation controls can be configured through the administration interface, the Web.config file, or using the layout page interface to display or suppress items.

As with the rest of the design process, Microsoft used an iterative process for creating the site hierarchy design. Therefore, the early iterations of their design were rough, but later iterations of their design became increasingly refined.

Global Navigation

The global navigation control appears as top link bars in default site templates and typically links to the primary sites in a portal site. It is common for the global navigation to appear at the top of each page in a portal site. This control gives users the flexibility to switch from one primary site to another from anywhere within the portal site.

Microsoft ensured that the global navigation stayed consistent and contained a limited number of top nodes in all of the portal's sites and subsites (MSW contains only five top nodes in addition to the home page).

Current, or Local, Navigation

The current navigation control (also known as the local navigation control) is included in the default site templates and typically highlights the important content in the current site and links to related sites. This navigation control commonly appears on the left of each page in a portal site.

The current navigation controls on MSW are configured to display the navigation items for the current site, sibling sites, or subsites beneath the current site or sibling sites. On many sites, navigation is configured to show only subsites, and the site administrator manually manages sorting via the pages for site navigation settings.

Microsoft customized the current navigation control to highlight certain elements so that all pages were displaying the correct navigation for that site. For example, one subsite might be configured to show only sites at the same level in the site hierarchy, whereas another subsite might show all the sites beneath the subsite.

Breadcrumb Navigation

The breadcrumb navigation control gives users a representation of their current location within the site hierarchy. This control displays a dynamically generated set of links at the top of Web pages. Most of the out-of-the-box master pages include a single breadcrumb navigation control.

Navigation Controls on Layout Pages

In addition to the navigation methods already discussed, navigation controls can be added to a layout page to support navigation links on Web pages. When a navigation control is inserted on a layout page, Web pages that use that layout page will display the control along with the page's contents. For example, a layout page can include a Summary Links navigation control so that a set of links to relevant pages and sites always appears when a page is displayed.

The out-of-the-box navigation controls in Office SharePoint Server 2007 include:

• Summary Links Web Part and Summary Links field control
• Table of Contents Web Part
• Content Query Web Part

Summary Links Web Part and Summary Links Field Control

The Summary Links navigation control provides an easy way to build a page of links to various resources, both inside and outside a site. The Summary Links navigation control can be configured to change the appearance, organization, and presentation of the links.

Summary Links can be implemented either as a Web Part (via the Summary Links Web Part) or as a field control (via the Summary Links field control). The primary advantage of using the Summary Links Web Part is that it can take advantage of the shared styles managed in the central Extensible Stylesheet Language for Transformations (XSLT). The primary advantage of implementing the Summary Links field control is that version control can be performed on the links within the page instance. For more information about which implementation to use, refer to "Use and Configure a Summary Link Web Part or a Summary Link Field Control" at http://office.microsoft.com/en-us/sharepointserver/HA101551681033.aspx?pid=CH101782981033.

As a long-term strategy to provide users with sites related to the content that they are currently viewing, Microsoft decided to incorporate Summary Links Web Parts instead of rich text editor controls into the MSW pages. This enables the service providers to update and modify the content displayed in the Summary Links Web Parts while maintaining the MSW styles and branding guidelines.

Table of Contents Web Part

The Table of Contents Web Part provides a way to add a table of contents of all or part of a portal site to a layout page, so that pages that use that layout include the table of contents. It uses the same navigation provider as the global and current navigation in the site's master pages. The Table of Contents Web Part is configured to specify which part of the site collection the control should expose, how the links are presented, and how the links are organized.

The Table of Contents Web Part can include only three levels in the hierarchy (the starting location in the site hierarchy and two levels beneath). The Web Part is primarily used as a navigation aid for links that are deep in the site hierarchy, and the most effective type of navigation would be like the navigation provided by the current navigation control.

Microsoft used the Table of Contents Web Part in MSW Help navigation as shown in Figure 3. Each of the links in the Web Part represents a section beneath the current path in the site hierarchy. In the case of MSW, Microsoft used the Table of Contents Web Part for levels four through six. The starting (or parent) node of the Table of Contents Web part can be configured to start at any level.

Figure 3. Table of Contents Web Part used in MSW Help navigation

For more information about the Table of Contents Web Part, refer to "Use the Table of Contents Web Part to Display Navigation on a Web Page" at http://office.microsoft.com/en-us/sharepointserver/HA101674191033.aspx?pid=CH101782981033.

Content Query Web Part

The Content Query Web Part can be used to display a dynamic view of content from a site on a Web page. The Web Part can be configured to retrieve items from a single list, a single site and subsites, or the entire site collection. The Content Query Web Part builds a Collaborative Application Markup Language (CAML) query and uses the new Microsoft.SharePoint.SPSiteDataQuery class to query the server. Filtering, sorting, ordering, and grouping can all be configured in the Web Part properties.

Choosing one of the default item layout styles displays the results in the Content Query Web Part. The default item layout styles cover basic formatting with bullets, images, and font size. If the default item styles are too basic, the ItemStyle.xsl file of the site collection can be customized to provide the appropriate styles. It is also possible to add extra fields to the CAML query and display additional information about the item, like author, date, or other custom fields.

Figure 4 shows the use of the Content Query Web Part on the MSW home page. A member of the MSW editorial team decides which stories appear in the various instances of the Content Query Web Part.

Figure 4. Content Query Web Part in MSW navigation

For more information about the Content Query Web Part, refer to "Add Dynamic Content to a Page" at http://office.microsoft.com/en-us/sharepointserver/HA101540001033.aspx?pid=CH101782981033.

Creating Web Page Design

When a user opens a Web page in an Office SharePoint Server 2007 portal site, the page is rendered based on a set of elements that have each been planned and designed separately on the Web site. These elements include master page, content page, layout page, and field controls.

Separating elements of a page in this way enables site planners and designers to treat different elements of the site in unique ways. For example, a site's branding and navigation can be planned and designed separately from the design of the site's content pages, so that the branding can be applied across all site content and can be updated in one place. Similarly, layout of pages can be designed separately from page content so that the same content can be displayed in different ways, as appropriate.

The new MSW portal layout page is based on the new page model in Office SharePoint Server 2007. This page model helps site administrators to manage and customize Web page design. The SharePoint pages viewed in the browser are constructed primarily through the control templates of master pages and Microsoft ASP.NET version 2.0 user control (.ascx) files. Users can create custom templates that override the default templates, or they can use types and members of the Microsoft.SharePoint.Navigation namespace to programmatically modify the menus, tree views, and navigational areas that appear on the pages.

A layout page is an ASP.NET 2.0 (aspx) file, which functions as a template and enables users to create similar-looking pages that dictate where fields are defined in a page record and where they appear on that page. A user might have a content type with 10 fields associated with it—one layout page associated with that content type might display only fields 1–5; another, fields 1–10. Having many options for layout pages associated with the content types gives Microsoft tremendous flexibility for displaying content on MSW.

For more information about creating Web page designs, refer to "Plan Web Pages" at http://technet2.microsoft.com/Office/en-us/library/a8a67b0e-2223-4493-b18d-1a72c529d5691033.mspx.

Create Master Page Design

Master pages supply the shared framing elements of the page, including the branding of the site, its navigation features, and other common elements such as search fields and Help commands. Because the site master page supplies the context of the pages on the site, it should remain consistent as the user interacts with a site.

An organization should keep the number of site master pages to a minimum to ensure consistent branding and user interface on a site. On simpler sites, an organization should use the same site master page across all sites in a site collection.

Master pages make sharing elements between page definitions easy, enabling designers to make changes in one place and then propagate the changes to all the pages linked to that master page. Microsoft used master pages to help maintain consistency across the site collection design of MSW.

Microsoft created the following master pages for the entire MSW portal:

• Branded with navigation. Includes the global navigation control at the top, current navigation control on the left, and search control. Microsoft used this master page for the majority of the pages on the site. Microsoft created this master page based on the Blueband.master page that ships with Office SharePoint Server 2007.
• Branded without navigation. Includes no navigation or search controls. Microsoft used this master page for pages that are embedded in other portals or for applications that did not have the same appearance as the rest of the MSW portal.
• Unbranded without navigation. Has no navigation or search controls. Microsoft used this master page for other applications or sites that are hosted or framed on MSW to provide a consistent appearance. For example, Microsoft used this master page to publish news from another application.

The cascading style sheets that the master pages use provide the same function as they do in any Web-based application. Microsoft did not modify the style sheets that ship with Office SharePoint Server 2007. Instead, Microsoft overrode the existing style sheets by creating new custom style sheets from one or more custom cascading style sheets stored in the root styles library. These custom style sheets were referenced in the master page or in the CSS URL property of the master page setting. Specifically, Microsoft used the CSS Link Control URL of the master page or the Alternate CSS URL settings of the site. The Alternate CSS URL setting can be configured in the root site and inherited by subsites.

Create Content Page Design

A content page contains the content that appears on a single Web page. Each content page in Office SharePoint Server 2007 consists of text, images, and other content stored as an entry (a Web page) in the Pages library. Because the Pages library is a SharePoint library, the Web pages that it contains have all the features of documents in Office SharePoint Server 2007, such as versioning. Creating a content page design includes:

• Determining the page content type that meets content needs.
• For each page content type, determining the columns to use for storing content.

Microsoft created custom page content types based on the out-of-the-box page content types. It used these customized page content types throughout various portals to create dynamic page display. Microsoft defined common column types for targeting and workflow management. It derived several child content types that inherit from the content types that ship with Office SharePoint Server 2007.

Determine Page Content Types

Table 2 lists the page content types that Office SharePoint Server 2007 provides. These page content types are typically used as is or are the starting point for customized page content types.

Table 2. Page Content Types Provided in Office SharePoint Server 2007

Determine Columns Used for Storing Content

The Welcome Page and Article Page content types have been designed to be generally useful and to apply across a wide range of contexts. The primary content column in both content types is the Page Content column, which is capable of holding any HTML content.

Site designers can control the appearance of their content by using HTML and the cascading style sheets framework. By so doing, they may not need to design other content types. Also, by carefully choosing which layout to use for each type of content based on Article Page or Welcome Page, site designers can introduce more variety in their content presentation without requiring the introduction of additional content types.

To customize a page content type, the MSW team:

1. Created a new content type from the content type gallery (_layouts/ctypenew.aspx).
2. Selected the parent content type for the new content type (so that the new content type can inherit fields from the parent content type).
3. Added columns that will contain the new HTML, image, or other type of content (created columns in the Site Column Gallery to use them on multiple page types).

For example, to add an About the Author field (which includes biographical information about page authors) to certain article pages, Microsoft added a Publishing HTML column type to the Site Column Gallery (so that it can be used in other content types), and then added that column to the Article Page content type.

After modifying the page content type, the MSW team modified the associated layout pages by adding field controls to display the additional columns of content. For example, after adding an About the Author column to the Article Page content type, the MSW team added an About the Author field control to associated layout pages to display the contents of that column.

Create Layout Page Design

A layout page acts as a template for content pages by providing field controls into which the contents of the content page appear. Each layout page is associated with a particular content type. Multiple layout pages are often available for a single content type (for example, to provide alternate layouts for localized versions of content or to add or remove the display of certain fields and features from a layout page).

Office SharePoint Server 2007 includes a set of layout pages for the Welcome Page and Article Page content types. Layout pages can be created or customized, including adding new controls to display page content along with additional controls such as Web Parts and server controls, via Office SharePoint Designer 2007 or Visual Studio.

Depending on the publishing goals, layout pages can restrict how much freedom authors have to format their Web page content or to add items such as images and hyperlinks to pages on a site (in a process known as increasing the page layout rigidity). For example, on a highly controlled Internet presence site (like MSW), all formatting is typically defined in cascading style sheets associated with the layout pages, and writers are blocked from overriding style definitions by using inline formatting. In contrast, in a collaborative site, such as an intranet portal, authors may have full freedom to format their pages and add other page items, such as Web Parts that provide views of data.

While creating the layout pages for MSW, Microsoft found that the default layout pages that ship with Office SharePoint Server 2007 did not strongly enforce the MSW style guides. To help enforce the MSW style guides, Microsoft created approximately 20 restricted layout pages for the MSW portal. Microsoft found that the best practice was to consider layout page rigidity as early as possible in the design process so that the team could work within the constraints of the more stringent layout page rigidity.

Microsoft restricted the layout pages in the following ways:

• Set properties on field controls in layout pages that restrict the tasks that authors, editors, or other content providers can perform.
• Removed Web Part zones from layout pages to restrict authors from inserting and configuring Web Parts on the pages, or set restrictions on Web Part zones to limit how authors can use them.

In the future, Microsoft plans reduce the number of layout pages available. These restrictions will make it easier for service providers to create pages or modify content while staying in compliance with MSW guidelines.

Create Field Control Design

The improved page layout model in Office SharePoint Server 2007 – based on ASP.NET 2.0 – supports different methods of displaying content that appears on a page. Field controls are one mechanism used to deliver the content in a publishing page. Field controls are tightly coupled with the columns defined by the associated content type and are referenced in the page layout to render field contents on a page. Examples of how rendering content within field controls can be done include text boxes (for single lines of text) and the rich text editor (RTE) control (for full HTML insertion).

Determining their use depends on the content being displayed and the need for its re-use. For content specific to a page, controls provide a flexible approach to the editing and rendering of that content. The content can be edited directly on the page in design mode or via the Edit properties pane of the Pages library. Authors can also take advantage of the inherent page versioning as this content gets stored directly with the page item.

When content needs to be aggregated or rolled-up from multiple data sources, Microsoft displayed the content through customizable web parts like the Content Query web part. Since the data is coming from elsewhere, this method doesn't store the content in the page; only the web part and its properties are stored with the page. Nevertheless, this approach provides a flexible approach to centralizing content and distributing it to multiple page targets. If the Web Part is stored in a Web Part zone, content authors or editors can modify the properties of the Web Part. If the Web Part is stored directly on a layout page, the Web Part properties are defined in the layout page and are unavailable to content authors or editors.

Creating Content Authoring and Publishing Process Design

Microsoft realized many benefits from deploying Office SharePoint Server 2007, but one of the most important benefits was the improvements in the authoring and publishing process. The previous authoring and publishing processes for MSW relied more heavily on customized code, provided fewer features than the current version, required more manual steps, and provided less flexibility.

Select Content Authoring Method

Office SharePoint Server 2007 supports two methods of Web page authoring:

• Browser-based authoring. Content creators work directly in the Web browser by using Office SharePoint Server 2007 browser-based features such as the Page Editing toolbar and the HTML Editor toolbar.
• Smart-client authoring. Content creators work in an authoring application and use the Office SharePoint Server 2007 document conversions feature to convert from the document's native format to Web page (that is, HTML) format.

Determining whether to use browser-based authoring or smart-client authoring and conversions depends on how an organization produces content, along with other factors. All content authoring work for MSW is browser based and occurs directly in the production environment. In some instances, authors might write drafts of the content in a smart client or send drafts via e-mail, but the actual publishing cycle is done with list and library content directly in the portal environment via the Office SharePoint Server 2007 publishing feature.

The reasons why Microsoft selected browser-based authoring include:

• Authors like to preview the content in place on the portal (contextual publishing), rather than publish content from a smart client (such as Microsoft Office Word) and hope that the content appears the same on the site as it did in the smart client.
• Browser-based authoring reduces the client/server dependencies that are inherent in a smart-client model. This reduces the effort required for managing and supporting the authoring and publishing process.
• Only a limited number of business-driven scenarios could benefit from smart-client authoring. Very few of the content authors, contributors, or editors needed offline authoring capabilities.

Determine Content Publishing and Approval Process

Because all sites in the MSW site collection are publishing sites, all the publishing features are enabled and available. The publishing and approval process was one of the big improvements in the Office SharePoint Server 2007 version of MSW. Office SharePoint Server 2007 integrates many of the content publishing, approval, and workflow processes that were available in Microsoft Content Management Server 2002. These improvements in publishing enabled the MSW team to publish more content on MSW with the same number of authors and editors.

The publishing features that Microsoft specifically used include:

• Content approval. Microsoft enables content approval (also called moderation) in all page libraries on the MSW portal.
• Version history. All page libraries in the MSW site collection have version history enabled. Each version of the pages in the page libraries is retained so that a page can be quickly reverted to a previous version (if necessary).
• Content type. Microsoft associates content types with libraries to help ensure that the appropriate layouts are available when new pages are created. These content types are included in the custom layout pages that Microsoft created. Any pages in the page libraries are created based on these custom layout pages, which are in turn associated with the custom content types.
• Approval workflow. Approval workflows are used to manage the approval process of pages within the Pages library of each site collection. Although Office SharePoint Server 2007 supports multiple workflows for each library, Microsoft primarily uses a parallel approval workflow model. A content approval workflow starts automatically when authors submit a minor version for approval, or authors (or editors) with specific permissions can start the content approval workflow manually. The workflow notifies the publishing team to review and approve (or reject) the update to the page.
• Information management policies. Microsoft uses the expiration policies to determine how long to retain content. After content expires, the content is reviewed and then deleted or renewed for another fixed period. Microsoft uses the expiration policy feature to automatically remove out-of-date content and reduce the effort for publishing.

Integrating Other Content and Systems

In addition to the content that is typical in a publishing portal, MSW includes other types of content and content that is stored in other systems. The goal of integrating the content and other systems is to provide a seamless interface for the user. Or, phrased another way, a user cannot discern where MSW ends and the other content and systems begin.

Integrate Blogs

Blogs are unique types of content in the MSW portal. Blogs are templates in Windows SharePoint Services 3.0, not Office SharePoint Server 2007 (and as such, do not participate in the Office SharePoint Server 2007 page model). Blogs are not part of a typical publishing portal because they are designed for collaboration, not for pushing one set of content to many.

Because of their collaborative nature, blogs do not have many of the publishing features enabled. However, publishing features can be activated if necessary. After the initial deployment, Microsoft activated publishing features to provide a Pages library wrapper for blog sites.

To integrate blog pages into MSW, Microsoft:

• Spent more time manually modifying the page design. These pages could not inherit from the existing master pages and layout pages, so Microsoft did extensive manual layout page customization to maintain the branding strategy.
• Simplified the page design for blogs. By adopting as simple as a design as possible, Microsoft reduced the amount of manual effort required for layout page customization. Microsoft kept the designs for blog pages much simpler than the rest of the portal.

Microsoft included blogs in the same site collection with other content. However, Microsoft later discovered that creating a separate site collection for blogs provides some advantages. Because blogs do not participate in the Office SharePoint Server 2007 page model, managing them in their own site collection is easier. Creating a separate site collection is also advantageous because a unique set of permissions must be in place to allow all users to contribute comments to published posts.

Integrate Other Systems

Microsoft has a number of systems that users need to access for information that is essential to their day-to-day activities. One of the goals for MSW was to integrate the information stored in these mission-critical systems seamlessly with MSW. To make this content appear like other MSW content, Microsoft used the Business Data Catalog feature in Office SharePoint Server 2007.

Business Data Catalog is a shared service that enables Office SharePoint Server 2007 to surface business data from back-end server applications without any coding. Business Data Catalog bridges the gap between a portal site and business applications, and it enabled Microsoft to bring in key data from various business applications to Office SharePoint Server 2007 lists, Web Parts, search, user profiles, and custom applications.

Each system requires a unique Business Data Catalog connection. The MSW solution includes server Business Data Catalog connections. Each of these connections includes a Structured Query Language (SQL) query that defines the information to be returned through the connection. Microsoft optimized these SQL queries to improve performance and to return only the necessary information in the query results.

For more information about the Business Data Catalog feature, refer to "Business Data Catalog" at http://msdn2.microsoft.com/en-us/library/ms563661.aspx.

Creating Site Security Design

Security is a key element in the MSW design. Microsoft wanted to ensure that only authorized users could modify the content published through the site, change the layout pages or master pages, or administer the site.

The security-related design decisions that Microsoft made include:

• Minimize the number of SharePoint groups. Using fewer groups reduces the complexity of the effort required to administer them. Using fewer groups also simplifies permissions, which reduces the risk of granting someone more permissions than are required to perform a job function.
• Grant the Manage Hierarchy permission to users who approve content. Approvers need only the Manage Hierarchy permission to approve content. This prevents users who are only approvers from having more permissions than are typically assigned to that role.
• Create alternate accounts for performing different categories of tasks. For the users who perform multiple roles, Microsoft created a unique account for each role. For example, a user may perform site administrative tasks and may perform publishing tasks. Therefore, Microsoft created an account for site administrative tasks and another account for publishing tasks. This means that some users have two accounts, one with elevated permissions and another with typical user permissions.
• Restrict the membership of the Site Administrators group. Microsoft limited the membership of the Site Administrators group to the users responsible for operations management, Best Bet search administrators, and SharePoint report viewers.
• Set general permissions higher in the site hierarchy. Microsoft heavily uses Active Directory security groups. These security groups are added directly to the SharePoint groups in the root of the site collection. The majority of the site hierarchy inherits these settings. This technique reduces the security-related administration of the MSW portal.
• Limit the number of sites that do not inherit permissions from the parent sites. These types of sites are also known as break-away sites. After a site is configured to not inherit permissions from the parent site, the site permissions become unique and must be administered individually. Microsoft had to create a few break-away sites for a few special administration sites and for the Blogs site. Otherwise, the site permissions were inherited from higher levels in the site hierarchy.

MSW Portal Development

The MSW portal development included the customization of existing Office SharePoint Server 2007 functionality and creating additional functionality through custom solutions. Some of the custom solutions required only customized Web Parts, whereas other custom solutions required more extensive coding.

Using Existing Features

Again, one of the design criteria for MSW was to use as many of the out-of-the-box features in Office SharePoint Server 2007 as possible. Microsoft created customized solutions only when necessary.

From a development perspective, customizing existing features instead of creating custom solutions has the following advantages:

• Enables faster portal development time
• Reduces the effort required to create, deploy, and support the portal
• Reduces the effort for ongoing support for any custom code
• Makes upgrades to future products easier because less custom code is used

Even in instances where Microsoft needed to create custom code, it often minimized that code. For example, if Microsoft needed to extend the function of an existing Web Part, it wrote wrapper code for an existing Web Part rather than creating a new Web Part.

Creating Custom Solutions

During the MSW portal development process, Microsoft created several custom solutions. Whenever possible, Microsoft developed these custom solutions as platform solutions. A platform solution is intended to be extensible and flexible enough for it to be applied to business needs of additional portal solutions. This reusability of custom solutions enables Microsoft to extend functionality of Office SharePoint Server 2007 as a platform for other portals throughout Microsoft.

The custom solutions that Microsoft created to extend Office SharePoint Server 2007 include:

• Site Permission Enumerator
• Publishing Services
• Broken Link Catcher
• Advanced Search
• News Workbench
• Feedback Services
• Content-by-Query Override Web Part

Site Permission Enumerator

Site Permissions Enumerator enumerates all the sites, pages, lists, and other objects in a site collection (for a particular user or security group) and builds a log file that contains the permissions of each object. Microsoft uses this tool to troubleshoot security-related problems with MSW and other portals.

Publishing Services

One of the big advantages to Office SharePoint Server 2007 is the improvements in content publishing. Office SharePoint Server 2007 supports fully customizable publishing processes by using workflows. These workflows can be used to create fully customized publishing processes that can integrate with e-mail or Web Parts. Microsoft created custom publishing services to make the content publishing process highly automated and more efficient than the previous solution. It includes the following components:

• Publishing workflows. The publishing workflows that Microsoft created are based on the Enterprise Content Management (ECM) starter kit in the Office SharePoint Server 2007 software development kit (SDK). Microsoft used Microsoft Visual Studio 2005 to customize the approval workflow to provide a globally available template.
• Custom e-mail template. This template provides additional information to the editor and approver in the workflow process (such as who submitted the change, the page title, the date of the change, the version, and the due date of the publication).
• Customized Content-by-Query Web Part. This Web Part enables users to track publishing status across site areas. This Web Part creates a report that is based on the status of all the pending approvals for all the site areas of MSW. This is the standard Content-by-Query Web Part with a customized style that is designed to show a summary (roll-up) of pages' states across the site.
• Workflow configuration enumeration script. This script automates the configuration of workflow settings in the Pages libraries across the site collection. Microsoft developed this script because it has a large number of sites to manage (more than 1,000 sites).

Broken Link Catcher

Office SharePoint Server 2007 automatically maintains internal links when content is moved. However, links that are manually added are not automatically updated and become "broken." Microsoft developed the Broken Link Catcher tool to identify when links are broken after site administrators or editors move content. To catch broken links, the tool uses the event trapping and redirection features in Office SharePoint Server 2007.

Event trapping is the first half of the solution. Event trapping monitors site and page movements and records the original and new URL of the content. With event trapping, the custom code is notified when an Item Added, Item Deleted, or Web Moved event occurs. When a site is moved or renamed, the Web Moved event notifies the custom code. When a page is moved under the pages collection of a site, the Item Added and Item Deleted events notify the custom code. The custom code records the original and new URL of the content in a SharePoint list.

When a user browses to the old URL, IIS is unable to find the page and returns a 404 error ("File Not Found"). This is where the redirection portion of the solution takes control. Instead of the typical "File Not Found" page, a custom page is invoked and determines whether the URL exists in the SharePoint list. If the URL is in the list, the user is automatically redirected to the new URL. If the URL is not in the list, the user can be redirected to a specific page (such as the home page).

Advanced Search

Office SharePoint Server 2007 includes a user interface for Advanced Search. However, the Advanced Search Web Part had some limitations, so Microsoft created a custom Advanced Search Web Part that includes the following improvements:

• Sorts the search results on relevance ranking, last-modified date, and custom properties
• Performs nested subqueries
• Includes a drop-down list for property values of items being searched
• Performs searches on property values by using a like operator in addition to the standard contains operator

The Advanced Search solution includes the following components:

• Connected Web Parts. These Web Parts are used to collect the information to build the search query, run the query, and display the search results. The Web Parts are connected via the standard Web Part connection interface.
• Advanced Search user interface. The Web Parts are placed in this customizable user interface and are customized via an XML file.
• XML configuration file. This file is used to define the Web Parts that are used and how the content in the Web Parts are mapped to the query.

For more information about the search features on MSW and at Microsoft in general, refer to "Deploying and Supporting Enterprise Search" at http://technet.microsoft.com/en-us/library/bb735129.aspx.

News Workbench

The News Workbench solution enabled Microsoft to review relevant news stories and then publish the stories to the appropriate places. The news stores can be published to the MSW home page, a specific news page within the MSW portal, or in a daily newswire that is sent via e-mail to employees who subscribe to the service. Although the News Workbench solution is a custom solution, the majority of the solution is based on the Office SharePoint Server 2007 publishing model and page model.

The News Workbench solution includes the following components:

• Custom code that downloads news content. This code pulls the news from various news sources and stores the news stories in a custom SharePoint list.
• SharePoint custom lists. In addition to the SharePoint custom list where all incoming news stores are stored, SharePoint custom lists are created for different categories of news stories so that the stories can be targeted correctly.
• Custom form. This form enables editors to select new items in the SharePoint custom lists with tagged values. Editors can therefore categorize data and help ensure that the news stories appear in the right location on the site.
• Indexing and search services. The indexing and search services are responsible for indexing the news stories and providing faster searching of stories within the SharePoint custom lists.
• Custom views. Custom views of the SharePoint custom lists enable editors to perform day-to-day tasks such as creating news summaries, identifying content that has been recently published, or identifying where the news was published.
• Custom code that publishes to a page. This code formats the published news stories by using a predefined HTML template and then creates the page that contains the full news story.
• Custom version of Content-by-Query Web Part. This Web Part queries the various SharePoint custom lists and displays summaries of the news stories on the MSW home page and other pages. When users click the story in the Web Part, they are directed to the page that contains the full story. Microsoft used custom styles to format the content in the Content-by-Query Web Part.
• Custom e-mail management Web Part. This Web Part retrieves news stories stored in a SharePoint custom list, creates an e-mail body in HTML based on those news stories, and then sends the e-mail to a specified list of subscribers.

The News Workbench solution works as follows:

1. The custom code retrieves news stories from various services and stores the stories in a SharePoint custom list.
2. The MSW shared search services index the SharePoint custom list so that MSW editors can easily locate relevant news stories.
3. MSW editors search the news stories and identify news stories to publish by using custom-developed code.
4. MSW editors place the news stories into specific SharePoint custom lists based on the category of the news stories by using custom-developed code.
5. MSW editors perform editing tasks on the selected news stories in preparation for publishing to MSW, including:
   • Creating summaries of the stories.
   • Editing the titles of the stories.
   • Tagging content within the stories so that queries can select and display the stories on the right location on a specific page.
   • Designating stories as "top stories" so that they appear in a specific Web Part on the home page.
   • Setting priority so that highlighted stories appear before other stories in Web Parts.
6. MSW editors release the stories for publication to the MSW site, as a part of a newswire e-mail message, or as a Really Simple Syndication (RSS) feed.
7. MSW editors can remove a news story after the story becomes obsolete or no longer needs to be published.

Feedback Services

A custom solution enables users to provide feedback to the MSW team through the MSW portal. Users can also submit ideas for articles or submit events to the MSW team (including text and graphics). Figure 5 illustrates the use of the Feedback Services solution to submit an event to the MSW Events Calendar.

Figure 5. Submitting an event to the MSW Events Calendar by using Feedback Services

The Feedback Services solution includes the following components:

• InfoPath forms. InfoPath forms are created in InfoPath Designer and then are published through a custom Web Part container on a page. Users interact with the Feedback Services solution through this interface. Any changes to the InfoPath forms require making changes in InfoPath Designer and then republishing the form.
• Custom Web Part. A custom Web Part container displays the published InfoPath forms.
• Form libraries. The data entered in the InfoPath forms is stored in form libraries.
• Custom workflows. Each form library has custom workflows that send acknowledgements to feedback submitters and notify the appropriate MSW personnel that feedback was submitted in a form library.

Content-by-Query Override Web Part

The Content-by-Query Web Part that ships with Office SharePoint Server 2007 is based on a static query. This Web Part uses CAML to query for data and Extensible Stylesheet Language (XSL) to display the results. Even though the result set returned by the CAML query is dynamic based on the content, the query parameters are statically defined in the Web Part properties.

Microsoft wanted the ability to pass query parameters at run time. The solution was to override the default CAML query with a query that accepts parameters. The parameter replacement occurs through a textual replacement of the parameter name with the parameter value. The parameter name in the CAML query is enclosed in braces ({ }).

The effort required to implement this functionality was minimal. Microsoft modified the source code for the out-of-the-box Content-by-Query Web Part to override the base class and methods (specifically the CreateChildControls method). The customized code scans the CAML query (specified in the Web Part properties) and replaces the parameter with a value provided as a run-time value. The following code illustrates the level of complexity for the customization.

foreach (string key in Context.Request.QueryString.Keys) temp = temp.Replace('{' + key + '}', HttpUtility.HtmlEncode(Context.Request.QueryString[key]));

Although the amount of customized code developed was minimal, Microsoft realized a dramatic increase in flexibility compared to the out-of-the-box Content-by-Query Web Part.

Creating Custom Web Parts

As part of creating custom solutions, Microsoft had to create some custom Web Parts. In some instances, Microsoft developed wrapper code for existing Web Parts. In other instances, Microsoft created Web Parts without using any existing code.

During the development of custom Web Parts, Microsoft discovered lessons that helped it develop Web Parts faster and create Web Parts that are easier to maintain and support. These lessons include:

• Place strings and labels in resource or language files. This prevents the need to recompile and redeploy Web Parts for different languages and makes localizing the Web part easier. Adding a Web Part property for language would make the localization process even easier. Include any of the resource or language files in the SharePoint solution package file.
• Include resource files in SharePoint solution packages (such as images, cascading style sheets, and code). By including resource files in SharePoint solution packages, only the solution package file is necessary to install the Web Part. This reduces the complexity of managing separate resource files and helps reduce deployment errors.
• Add caching expiration time as a property. For any Web Parts that perform caching of information, expose caching expiration time as a configurable property of the Web Part. A developer can then adjust the caching without recompiling and redeploying the Web Part.
• Add an XSLT property to format results sets for the appropriate Web Parts (such as Web Parts that return search results). Adding an XSLT property separates the presentation of the information from the data and the code. A developer can then adjust the formatting and layout without recompiling and redeploying the Web Part.
• Store custom Web Part configuration in SharePoint lists. In some scenarios, some Web Part configuration properties may need to be modified by users who cannot normally modify Web Part properties. To restrict which properties a specific set of users can update, store the Web Part configuration in a SharePoint list and then grant the appropriate users the ability to change values in the list.
• Specify the minimal security access that the Web Part requires. Include a Code Access Security policy in the SharePoint solution file and (if necessary) include the Web Part in the Safe Controls list for the solution. Use this method of assigning the appropriate security rather than deploying the Web Part to the Global Assembly Catalog (GAC) and granting full access to the Web Parts.
• Pass information between Web Parts by using the Web Part connection feature. Web Parts include a standard connection interface that enables information to be exchanged between two or more Web Parts. Using this standardized method enables other Web Parts to consume information from the new Web Part and enables the new Web Part to consume information from existing Web Parts.
• Ensure that all Web Parts dispose of objects properly. Web Parts that do not dispose of objects properly will create memory leaks and will eventually cause performance problems. Avoid memory leaks by referencing objects (such as the SPWeb or SPSite objects) in a using statement or by explicitly calling the Dispose method for objects.
• Encapsulate the user interface for server controls in user controls. An ASP.NET user control is a group of one or more server controls (or static HTML elements) that encapsulate a piece of functionality. A user control can simply be an extension to the functionality in existing server controls, or it can be a grouping of server controls that can be treated as a single object. The appearance of the server controls (within the user control) is exposed as properties of the user control. The appearance of all the embedded server controls can then be consistent and can be modified through one property.
• Use the Delegate Control instead of using an explicit Web Part. The Delegate Control provides an alternative to adding user controls and server controls to an .aspx page. Instead of adding the user control or server control directly to the .aspx page, a designer can add the Delegate Control to the page and then delegate to another control referenced by the Delegate Control. The developer can then change which controls are used on a page without having to directly modify and redeploy master pages or layout pages. Also, because no Web Part is deployed, using the Delegate Control avoids the overhead of managing the various Web Part galleries.
• Perform error handling by using PortalLog and SPSException classes. Using these classes provides a method for handling errors that is consistent with Office SharePoint Server 2007. These classes also provide a single integrated log for troubleshooting problems.

Storing Information for Solutions

An integral part of every solution that Microsoft creates is the storage of the information that the solution manages. Each of the out-of-the-box and custom MSW solution accesses information in:

• SharePoint lists.
• SQL databases.
• Other data repositories accessed through the Business Data Connector.

When information to be stored was static and could not be represented as columnar data, Microsoft stored the information in fields on a page in the Pages library. Otherwise, it stored the information by using one of the methods listed previously.

Images used in a portal can be viewed as a specialized type of information. Microsoft stored all the images for its solution in the images library for the root site and in the root styles. Storing the images in the root made the images easier to locate and manage.

SharePoint Lists

Many of the MSW solutions store information in SharePoint lists (such as the News Workbench, Feedback Services, and Broken Link Catcher solutions). SharePoint lists are the best storage method when the information is:

• Relationally flat and can be stored in a spreadsheet or a comma-separated file.
• Primarily consumed by SharePoint services and components.

Table 3 lists the advantages and disadvantages of storing information in SharePoint lists.

Table 3. Advantages and Disadvantages of Storing Information in SharePoint Lists

When working with larger SharePoint lists, an organization should consider implementing one or more of the following recommendations:

• Manage display of large lists by using custom views or code. Custom views and code can be used to filter the number of items that a user views in a list, and they enable the user to locate relevant information faster.
• Organize large lists into folders for easier navigation and indexing. Dividing lists into folders is the same concept as storing a large number of files in folders. If the folders have meaningful names, users can to find relevant information faster. Ensure that folders contain fewer than 2,000 items (where an item is a list item or a subfolder).
• Search lists by using SharePoint search rather than CAML. SharePoint search is more efficient at searching than CAML-based queries. Search results can appear in a Web Part or another control.

SQL Databases

Solutions can also store information in SQL databases. Unlike SharePoint lists, information in SQL databases can only be accessed in SharePoint via the Business Data Connector or Web Parts that use ADO.NET. SQL databases are the best storage method when the information:

• Is relationally connected with other information.
• Is primarily consumed by services and components outside SharePoint.
• Contains a large number of records (items).

Table 4 lists the advantages and disadvantages of storing information in SQL databases.

Table 4. Advantages and Disadvantages of Storing Information in SQL Databases

Business Data Connector

The Business Data Connector can provide access to stored information in certain situations. The Business Data Connector typically requires minimal development effort.

Accessing information by using the Business Data Connector is the best method when the information is stored in a system that:

• Is not supported by ADO.NET.
• Prohibits direct access to the information via ADO.NET (such as for security-related reasons).
• Cannot be duplicated or synchronized with a SharePoint list.

Table 5 lists the advantages and disadvantages of accessing information by using the Business Data Connector.

Table 5. Advantages and Disadvantages of Accessing Information by Using the Business Data Connector

MSW has four Business Data Connectors in use (three connections that are used for profile import and one for customer index and search via the Customer tab in search services). While developing and supporting these connections, Microsoft discovered the following recommendations:

• Optimize any SQL statements within the application definition file for the Business Data Connector to help reduce overhead on the target system. An example of optimizing the SQL statements is to restrict the number of columns or rows returned in the query. This optimization reduces the amount of data returned and reduces the impact on system resources for the target system.
• Perform only full index crawls of content (instead of other index crawl types, such as incremental index crawls) to:
  • Help ensure that indexes perform optimally.
  • Capture any changes after the application definition file is changed for a Business Data Connector.

Developing Office SharePoint Server 2007 Solutions

Developing Office SharePoint Server 2007 solutions is different from developing most traditional applications because SharePoint solutions are deployed into an existing SharePoint environment. All installations, updates, removal of components must be done through methods that work within the SharePoint architecture and environment.

As Microsoft developed the MSW portal, it discovered methods of improving the development process. These methods include:

• Avoid deploying dynamic-link libraries (DLLs) to the GAC. The GAC exists to maintain a relationship between strongly named assemblies and a file system subdirectory. Typically, there is no reason for adding a DLL to the GAC. Unless a DLL is strongly named, the DLL cannot be added to the GAC.
• Develop by using production data. Without production data, developers typically develop and do preliminary testing based on fictitious data. Fictitious data tends to:
  • Hide run-time errors that are discovered with production data.
  • Be smaller than production data, so it provides inaccurate performance results.
• Develop in simple configurations of Office SharePoint Server 2007. Avoid duplicating the production environment in the development environment because it can unintentionally introduce site-specific code dependencies. Configuring the development and production environments differently avoids these types of dependencies. However, unlike the development environment, the test environment should closely mirror the production environment.
• Create SharePoint solution packages for deployment. As early in the development process as possible, hand off the solution to test as SharePoint solution packages. SharePoint solution packages are the best method for installing SharePoint-based solutions into a SharePoint environment. The same packages created for the test environment will eventually be used for deploying in the production environment.
• Create SharePoint solution packages that have the .cab file name extension instead of the .wsp file name extension. The .cab file name extension is registered with Windows operating systems, and cabinet files can be opened in Windows Explorer. The ability to easily access the contents of the package increases the likelihood of finding problems before deployment.
• Automate the creation of the .cab and .ddf files that are used to create the SharePoint Solution packages. Create scripts that automate the creation of the .cab and .ddf files. Microsoft automated this process to reduce the possibility of introducing errors by performing manual steps. In addition, Microsoft plans to automate the validation of the feature.xml and manifest.xml files.
• Create deployment automation scripts. Deliver deployment automation scripts along with SharePoint solution packages. Deployment automation scripts help ensure consistency of the configuration for the solution, reduce the effort to deploy the solution, and help reduce human-introduced errors.
• Include installation documentation as an output of the build process. The documentation for running the deployment automation scripts should be included as an output of the build process. The configuration steps that publishers perform are not included in the installation document, but are covered in the configuration document.
• Include configuration documentation as a part of the SharePoint solution package. The configuration document contains the steps that the publishers will perform. Including this documentation in the SharePoint solution package helps ensure that the publishers can easily locate and follow the documentation (typically installed as a custom SharePoint list).
• Divide solutions into manageable components. Portal solutions like MSW consist of many smaller solutions. Microsoft divided MSW into manageable solutions within the overall MSW portal. Aggregate solution features that rely on each other in the same solution.
• Ensure that solutions are autonomous. If a solution requires specific sites or lists for proper deployment, the deployment package and scripts should create any dependencies. If a solution depends on another solution, any base solutions should be installed as a part of the dependent solution. Try to make a default installation of Office SharePoint Server 2007 the only dependency. Avoid requiring any site-specific layouts or code that is not included in the solution package.
• Create one installation script that can handle the installation of all features and embedded solutions within a solution. A common installation script eliminates the need to maintain multiple installation scripts for each feature of an embedded solution. Running multiple installation scripts can introduce configuration errors and installation dependency problems.

Testing Office SharePoint Server 2007 Solutions

Testing is an essential part of any development process. Prior to deploying the new MSW portal in the Microsoft production network, Microsoft performed many hours of testing. As with the design process, testing is an iterative process. Microsoft performed early testing at a component level, but as MSW neared deployment in the production network, Microsoft performed full functional testing of all features.

As it tested the MSW portal, Microsoft discovered methods of improving the testing process. These methods include:

• Ensure that the test environment closely mirrors the production environment. Unlike the development environment, the test environment needs to be as close to the production environment as possible, including the same:
  • Number of front-end servers with same load-balancing technology.
  • Configuration of page output caching.
  • Security configuration (including users and groups) and access to SharePoint lists.
  • Production network external dependencies (Internet-based resources) connected directly to the test environment.
  • Production data that is currently in use.
• Deploy solutions to the test environment by using SharePoint solution packages and automation scripts. These are the same packages and scripts that the development team created earlier in the process. Avoid copying files and manual configuration when moving from the development environment to the test environment and from the test environment to the production environment.
• Include installation verification logic in automated installation scripts. As a part of the verification that the solution was installed correctly, ensure that the:
  • Correct versions of solution components are installed because versioning in SharePoint-based solutions is not easily identified.
  • Solution does not reference specific names or computers (these types of issues tend to arise from code that consumes data from Web services or external databases or from external dependencies).
• Create one installation script that can handle the installation of all features and embedded solutions within a solution. A common installation script eliminates the need to maintain multiple installation scripts for each feature of an embedded solution. Running multiple installation scripts can introduce configuration errors and installation dependency problems.
• Ensure that features that are implemented only once create their instances and dependencies. For example, if a feature requires its own SharePoint list that no other feature uses, the SharePoint solution package should create the list along with the other dependencies for that feature.
• Retain all versions of deployed solutions. Retaining previous versions of deployed solutions enables easy restoration of the environment to a previous configuration and provides rollback functionality.

MSW Portal Deployment

After extensive testing in its test environment, Microsoft began deploying MSW into the Microsoft production network. As a part of the deployment process, Microsoft had to configure the caching settings for MSW.

Deploying MSW Portal in the Production Environment

The deployment of MSW in the production environment followed the same processes and procedures that Microsoft used in deploying MSW in the test environment. Microsoft used the same automated installation scripts and SharePoint solution packages that it had used in the test environment.

Microsoft deployed the baseline functionality of MSW in the initial production deployment. Microsoft continues to add more features and content with ongoing deployments in the production environment. All new features go through the same stringent level of testing to help minimize problems when they are deployed in the production network.

Configuring the Appropriate Caching Configuration

Office SharePoint Server 2007 uses output caching technology native to ASP.NET 2.0 to manage when and how page content is served. Output caching in Office SharePoint Server 2007 behaves similarly to output caching technology in ASP.NET 2.0.

On a heavily accessed Office SharePoint Server 2007 site, caching frequently accessed pages for even a minute at a time can result in substantial throughput gains. While a page is cached by the output cache, subsequent requests for that page are served from the output page without executing the code that created it for the specified duration of the cache.

Output caching may not be appropriate for all situations. Table 6 lists the advantages and disadvantages of output caching.

Table 6. Advantages and Disadvantages of Output Caching

Office SharePoint Server 2007 adds a more precise mechanism for customizing output caching than the mechanisms available natively in ASP.NET 2.0. Office SharePoint Server 2007 includes cache profiles, which are list-style cache settings that administrators can name and apply to pages, page items, content types, and levels of scale in site deployments.

By using cache profiles, administrators can:

• Control the level of granularity applied to output caching.
• Allow or disallow site owners and administrators to choose their own cache profiles and apply them flexibly to layout pages.
• Target output caching at the site collection, site, and layout page levels.

Configuring Output Caching

MSW is configured via settings that are optimized for an intranet portal that only authenticated users can access. These configuration settings would need to be adjusted for external-facing portals or portals that support anonymous access.

The MSW output cache configuration settings are as follows:

• Site collection output cache is enabled.
• Authenticated cache profile is set to intranet.
• Page output cache policy supports modifying the global configuration at the site level.
• The Debug Cache feature is enabled (this enables viewing the source code of a rendered page to verify cache settings in a comment written to the output).
• Site collection object cache is set to a maximum cache size of 350 megabytes (MB). (This is the amount of memory that can be used in the object cache for storing properties of sites and pages.)

Identifying the Effect of Break-Away Sites on Output Caching

Administrators can organize caching behavior based on a user's permissions to a site. For example, an administrator may have three groups defined: one with full control, one with read and write permissions, and one with read-only permissions. Output caching renders the page the same way for users with the same permissions, so the administrator can use cache profiles to target caching to specific audience groups.

In the cache profiles that Office SharePoint Server 2007 delivers by default, the caching system renders the page once per group of permissions and then caches the resulting HTML stream. The next user with the same permissions gets the stream from the cache.

A break-away site will have a unique set of permissions, so they will effectively be cached by using their own set of groups. This can adversely affect performance for users with elevated permissions (such as editors) because they do not access the sites often.

Configuring the Appropriate Web Part Caching

Web Part authors can choose to cache data in several ways, but ultimately the administrator decides the type of caching that a Web Part uses. These changes are made in the WebPartCache element in the web.config file for the portal. For each Web Part, administrators can select one of the following configuration options:

• None. This option disables caching completely and requires the Web Parts to retrieve the content from the respective content sources. This option ensures that the Web Parts always display current content.
• Database. This option caches the data on the SQL Server–based server that manages the content database. The advantage to this option is that when front-end servers are deployed on a server farm, all of them will return consistent values. However, this method is slower than caching the data on the front-end servers.
• CacheObject. This option caches the data by using the ASP.NET Cache object. The advantage to this option is that the data is cached in memory on the local front-end server. The disadvantage to this method is that multiple front-end servers can return inconsistent values for the data.

For more information, refer to " Techniques to Improve Web Part Performance " in "Best Practices for Developing Web Parts for SharePoint Products and Technologies" at http://msdn2.microsoft.com/en-us/library/ms916817.aspx.

MSW Portal Operations

After the deployment of MSW in the production environment, the MSW portal entered the operational phase of the IT life cycle. This phase includes the day-to-day operations, administration, and support of the MSW portal and the services on which MSW depends.

Performing Shared Services Administration

Microsoft added the Shared Services Provider feature to Office SharePoint Server 2007 so that organizations can manage enterprise search services. The SSP feature creates groups of shared services and related shared resources that are managed in a central administrative console.

Administrators create and configure an SSP so that shared services are available to multiple sites within the farm. An administrator assigns each Web application in a farm to an SSP. Although an administrator can create multiple SSPs for a farm, an individual Web application or site can be associated with only one SSP.

Microsoft IT has data centers that provide enterprise shared services in Redmond (Washington State ), Dublin , and Singapore . The SSP feature enables Microsoft IT to centrally manage shared services in each of these three major regional data centers. Microsoft has three full time employees (including one from the Operations team) dedicated to managing the SSPs.

Shared services include the following:

• Search services. These services enable sites to access a common index and search database. To completely configure search services for an SSP, an administrator needs to perform SSP-level, farm-level, server-level, and site collection–level configuration settings. For more information about:
  • Configuring shared search services for an SSP, refer to "Configure the Office SharePoint Server Search Service (Office SharePoint Server)" at http://technet2.microsoft.com/Office/en-us/library/61b7ae94-dff5-4b01-88b5-0a016a9c36c31033.mspx.
  • How Microsoft configured MSW shared services that MSW consumes, refer to "Deploying and Supporting Enterprise Search" at http://technet.microsoft.com/en-us/library/bb735129.aspx.
• Personalization services. The personalization service uses information about users in an organization that is stored in Active Directory. That information can be supplemented with information about users from line-of-business applications. Personalization information can then be displayed in user profiles, and the properties in user profiles can be used to target content. For more information about configuring personalization services, refer to "Configure Personalization" at http://technet2.microsoft.com/Office/en-us/library/d43df82b-84bd-42bb-84f6-5ff5b4eb8a751033.mspx.
• Business Intelligence services. These services provide access to business data by using the Business Data Catalog. For each line-of-business application, a Business Data Catalog connection needs to be defined for the SSP. For more information about configuring business intelligence services, refer to "Configure Business Intelligence Features" at http://technet2.microsoft.com/Office/en-us/library/96f9fa0f-5215-4e94-ac76-d0256d6e56491033.mspx.
• Excel Services. Excel Services enables users to view Excel spreadsheets and graphs without installing Excel on their computers. Excel Services renders the Excel spreadsheets and graphs as HTML. For more information about configuring Excel Services, refer to "Configuring Excel Services" at http://technet2.microsoft.com/Office/en-us/library/cc1ba5e8-0908-49ca-8cac-01bc20793e141033.mspx.
• InfoPath Forms Services. InfoPath Forms Services enables users to enter information into InfoPath forms without installing InfoPath on their computers. InfoPath Forms Services renders the InfoPath forms as HTML and then stores the information collected in the forms as any other InfoPath form. For more information about configuring InfoPath Forms Services, refer to "Configure InfoPath Forms Services (Office SharePoint Server)" at http://technet2.microsoft.com/Office/en-us/library/90aa8e29-21da-4e57-ab4b-76cd742111271033.mspx.
• Office Project Services. Office Project Services enables users to enter project data into a project created in Microsoft Office Project 2007 and stored in Microsoft Office Project Server 2007 without installing Office Project 2007 on their computers. For more information about configuring Office Project Services, refer to "Configure Office Project Server" at http://technet2.microsoft.com/Office/en-us/library/64f7e4cf-4cb6-448c-82b5-edb815e3473d1033.mspx.

Currently, MSW is consuming only the following services from the North America SSP in Redmond, Washington :

• Search services.
• Personalization services.
• InfoPath Forms Services.

Optimizing Portal Performance

Microsoft optimizes the performance of the MSW portal through the following tasks:

• Change the Content-by-Query Web Part defaults on large sites. By default, the Content-by-Query Web Part runs a query against every list in the site collection (specifically excluding lists from the query or opt-out). The Web Part configuration was changed to include only specific lists in the query or opt-in.
• Index fields in lists that are used in CAML queries. An administrator can improve CAML query performance by indexing fields that are included in the criteria in CAML queries.
• Configure item expiration in large lists when possible. In lists where items can expire, Microsoft configures automatic expiration dates for the items. Configuring expiration dates reduces the number of items in large lists and improves query performance for the lists.
• Perform regular maintenance of content databases. The content databases are the most highly used databases in a portal site. The databases are regularly defragmented, and heavily used tables in the databases are reindexed regularly.
• Invest in high-performance disk subsystems. High-performance disk subsystems on the computers running SQL Server that host the content databases will improve overall portal performance.
• Monitor virtual memory usage. Increases in virtual memory usage can be an indicator that a portal site has a memory leak. In sites that have a steady increase in virtual memory usage, Microsoft recycles application pools.
• Dedicate a Web front-end server for indexing. For heavily accessed portals, Microsoft dedicates one Web front-end server as a crawl target server. A crawl target server is a server in a Web farm that is removed from the pool of Web front-end servers that handle service requests so that the index services can crawl the content without adversely affecting user response time.
• Monitor portal performance by using Microsoft System Center Operations Manager 2007. Manually monitoring all the characteristics and performance metrics for MSW would be virtually impossible. Microsoft monitors MSW performances metrics and trends by using Operations Manager 2007. Operations Manager 2007 proactively notifies the operations team when any performance metrics vary from established baselines.

Optimizing Portal Uptime and Recovery

Because the MSW portal is an essential resource for users to perform their day-to-day job functions, users expect MSW to have high uptime. Microsoft optimizes the uptime and recovery of the MSW portal by performing the following tasks:

• Implement the Cluster service for SQL databases. Two or more computers that are running the Cluster service can form a cluster. By running SQL Server on a cluster, any computer in the cluster can provide an automatic failover for SQL database services that Office SharePoint Server 2007 needs.
• Implement Network Load Balancing for Web front-end computers. Network Load Balancing provides automatic failover in a Web farm. If one computer in the Web farm fails, the other computers in the farm can provide Web services and continued support of Office SharePoint Server 2007.
• Monitor portal uptime by using Operations Manager 2007. In addition to monitoring portal performance by using Operations Manager 2007, Microsoft monitors portal uptime. To perform end-to-end monitoring of uptime, Microsoft monitors not only Office SharePoint Server 2007, but also any dependent services, such as IIS, Active Directory, or Domain Name System (DNS). Operations Manager 2007 has integrated management packs that can provide end-to-end monitoring of the entire solution.

Conclusion

MSW is an example of how Microsoft created an effective enterprise portal by using Office SharePoint Server 2007. Office SharePoint Server 2007 provides the essential features and the configuration flexibility for creating portal solutions that rival custom-developed portals that are created via ASP.NET pages. However, a portal solution based on Office SharePoint Server 2007 can be created in a fraction of the time and represents a lower total cost of ownership (TCO) in comparison to a custom-developed ASP.NET-based portal solution.

The lessons that Microsoft has learned in creating an award-winning portal by using Office SharePoint Server 2007 include:

• Thoroughly analyze existing content and potential new content. This analysis is the basis for creating an information architecture. Omitting this analysis can result in a flawed information architecture.
• Create an intuitive information architecture. The site hierarchy and navigation controls in the information architecture need to create an intuitive approach to locating content. Although search can ultimately find content in the sites, a well-designed information architecture should enable users to navigate to the same content intuitively.
• Configure features instead of creating custom solutions. An organization should explore configuring out-of-the-box features before creating a custom solution. When an organization must create a custom solution, it should consider extending existing features (such as creating a wrapper for an existing Web Part) before creating the solution from nothing.
• Perform extensive testing. Thorough testing of a portal is the pathway to successful deployment. An organization should perform component and full functional testing in a lab environment and in a pilot deployment prior to deployment in production networks. The organization should ensure that its test environment closely mirrors its production environment to help reduce any problems when deploying in the production environment.
• Automate build and deployment processes. Automated build and deployment processes help reduce errors introduced through manual processes. Automated processes also help create consistent and repeatable results in deployment. SharePoint solution packages are an essential part of any automated build and deployment process.

Many Microsoft business units have asked the Information Services and MSW teams for advice on creating their own portal solutions and have received this same guidance. A portal solution based on Office SharePoint Server 2007 can minimize design, development, deployment, and operations efforts while improving overall user satisfaction.

For More Information

For more information about Office SharePoint Server 2007 design, development, deployment, and operations, refer to:

Customizing and Branding Web Content Management-Enabled SharePoint Sites (Part 2 of 3): Extending WCM

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 through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase