SharePoint Portal Integration

SharePoint Portal Server (SPS) is Microsoft's enterprise-class portal solution. It facilitates collaboration, document management, enterprise consolidation, content targeting, and search across WSS sites, file shares, and intranet sites. SPS technology is built on WSS but gives you some important features not available in WSS, such as aggregated search, categorizing information into topics, personalization, and My Site. This section reviews some of the important integration points between SPS and the EPM solution.

NOTE

As a convention in this section, the term project workspace refers to a WSS site that has been automatically created for a project when the project is published to Project Server.

Connecting EPM to SharePoint Portal Server

Connecting EPM to SPS is a simple process that is easy and quick but gives you limited integration functionality. It creates a link to SPS search in your project workspace search result pages and a link to the portal prominently appearing on all your project workspace sites. Finally it gives you the ability to elevate content, such as annoucements, document libraries, risks, and issues from project workspaces to SPS areas. To set up the connection between SPS and Project Server, follow these steps:

1.	In PWA, click the Admin tab.
2.	From the Actions list on the side panel, click Manage Windows SharePoint Services.
3.	When the browser refreshes, from the Actions list on the side panel, click Connect to SharePoint Portal Server.
4.	On the Connect to SharePoint Portal Site screen, enter the URL and a name for the portal that is descriptive enough that users will know where this link will take them (see Figure 29.3). Figure 29.3. Input a user-friendly name in the PWA Connect to SharePoint Portal Site screen.

When you complete the process to connect your project workspaces to SPS, one of the changes to your project workspace sites is a link that appears on the upper-right corner of all the pages in the project workspace sites, which gives an impression that SPS and the project workspace have tight integration. Additionally, when you execute a search on a project workspace, the search results screen has a convenient link to perform the search with your search terms on SPS. You can also create visibility in specified projects by elevating project workspace content to the portal by following these steps:

1.	Open the project workspace content area (for example: Risks, Issues, Document Library, or Annoucements) that you want to see in the portal.
2.	From the Actions list on the side panel, click Modify Settings and Columns.
3.	When the browser refreshes, click the Select a Portal Area for this List link.
4.	Change any of the settings on the Add Listing screen if you are not satisifed with the default values and click the Change Location link in the Location section to tell SPS where to put the new listing.
5.	Click OK to accept your changes and have the new listing added to SPS.

There are several things that you might expect to happen when you set up SPS in PWA. Unfortunately, the integration is not tight. Following is a short list of integration items that you might assume would happen but that do not happen:

• Automatic indexing of project workspaces is not set up.

• Project workspaces don't appear in the site catalog, which would give you a way to navigate to them directlyyou could work around this limitation with a web part.

• Project workspaces don't automatically get added to Topics in SPS.

TIP

One way to set up search integration between SPS search and project workspaces is to create a stored procedure that returns a URL as a link to all your WSS sites to a hidden web page and then set up this hidden page as a content source for the SPS Indexer to index. Finally, you can set up a Project Workspaces scope that appears in the search sources drop-down list on the home page in SPS, giving users the option to narrow their SPS search to just project workspaces.

This approach to indexing/searching project workspaces might seem a little kludgy at first, but some conditions exist that make this the best approach. First, SPS, for performance reasons, should really reside on a separate computer from the EPM solution. Following are additional arguments for setting up SPS/WSS and Project Server/WSS separately:

• A separate server configuration allows clean division between project workspaces and WSS sites in the portal's site collection for archiving purposes.

• Cuts down on potential SPS clutterold Project Workspaces don't have to be managed under the portal.

• When Project Server requests that WSS create a project workspace, it's going to get a number, not a name, which can't be changed. Thus, if you attempt to integrate WSS implementations, you'll end up with a bunch of ugly-named sites in your SPS catalog.

• SPS WSS sites are not static but can be easily reorganized on a corporate whim. This is not really the intention for project workspaces. If you separate the WSS implementations, there will be less breakage, and your user training will be easier and more consistent, with potential EPM users probably needing to be trained on only one application rather than two.

• If your organization is large, your system administrators will want to have the division of responsibility between the SPS team and the Project Server team. These teams can share knowledge but don't have to share the responsibility for both applications at once.

• Microsoft does not recommend installing SPS, WSS, and Project Server on the same computer for a production implementation, and doing so may have the following consequences: excessive memory usage, excessive paging to the hard disk drive, service performance degradation, and services delaying the start of other services.