Microsoft Project Server and SharePoint Team Services

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
On This Page

Introduction
Overview of Integration between Microsoft Project Server and SharePoint Team Services
Pre-Deployment Considerations
Installing SharePoint Team Services
Security and User Authentication
Administration
Collaborate on Documents and Issues
Extensibility on STS/Project Server Integration

Introduction

This article describes how SharePoint™ Team Services from Microsoft® can be used with Microsoft Project Server. It provides an integration overview and information about deployment, document and issue management, and feature administration.

By integrating SharePoint Team Services with Microsoft Project Server, Microsoft Project can leverage the document library and list management technology of SharePoint Team Services, and provide system that's easy to set up and use for sharing project-related documents and issues with team members and other stakeholders. Because SharePoint Team Services is fully integrated with Microsoft Office XP, it's especially useful for storing Office XP documents.

Taking full advantage of the Web-based team collaboration features of Microsoft Project, SharePoint Team Services allows you to integrate documents and issues with the project management process.

Overview of Integration between Microsoft Project Server and SharePoint Team Services

SharePoint Team Services, a superset of Microsoft FrontPage® Server Extensions 2002, can be integrated with Microsoft Project Server to provide both Web publishing and collaboration features to make communicating and sharing project information easier. When integrating SharePoint Team Services with Microsoft Project Server, SharePoint Team Services is treated as a component of the server, rather than as a standalone program. Microsoft Project Server Setup automatically configures SharePoint Team Services, but some manual configuration and administration may also be required. For SharePoint Team Services to work with Microsoft Project Server, Microsoft Windows NT® accounts (both domain and local) must be used.

When SharePoint Team Services is configured for Microsoft Project Server, it enables you to use the Documents and Issues centers in Microsoft Project Web Access to view and submit project-related documents and issues.

Features of SharePoint Team Services

SharePoint Team Services Web sites include unique features that enhance collaboration on project-related activities, such as managing project documents and tracking project issues. Using SharePoint Team Services, you can:

  • Create project document libraries to submit project documents, and view documents quickly.
  • Track issues in the predefined issue list, and customize the issues template per project.
  • Allow authorized users to create custom views with additional fields for document libraries and issue tracking lists.
  • Secure documents and issues at the team Web site level to prevent unauthorized users from viewing and editing documents and issues.
  • Secure remote administration from both the command line and the HTML Administration pages to enable Microsoft Project Server to programmatically and remotely administer SharePoint Team Services subwebs.
  • Add users and perform other Web administration tasks by using an easy HTML interface.

For additional information about SharePoint Team Services, see the SharePoint Team Services Administrator's Guide on TechNet.

SharePoint Team Services Architecture

The architecture of SharePoint Team Services is based on the architecture of FrontPage Server Extensions 2002 and uses the Internet Server Application Programming Interface (ISAPI). Like FrontPage Server Extensions, SharePoint Team Services works with Microsoft Internet Information Services (IIS) on the Windows® platform and relies on a database, such as SQL™ Server or MSDE Database, to provide additional functionality. SharePoint Team Services however, does not follow the same Web creation and Web publishing model you may be used to with FrontPage Server Extensions—when created, a SharePoint Team Services Web site is immediately live on the server.

When SharePoint Team Services is installed on a Web server, SharePoint team Web site authoring and administering functionality is available from any computer that has Microsoft Internet Explorer 5.0 or later. Authoring and administration are also available from a SharePoint Team Services-compatible client program, such as the Office 2000 client or the Office XP client, whether the computer is on the Internet or on an intranet.

The following diagram illustrates typical SharePoint Team Services architecture.

Cc750953.depl_psshrpt01(en-us,TechNet.10).gif

Figure 1. Typical SharePoint Team Services architecture

Communication between a client computer and a Web server running SharePoint Team Services uses the same open HTTP-based protocol that Web browsers on a client computer use to interact with a Web server. No file sharing access on the Web server computer is needed, and neither FTP nor telnet access is required. No proprietary file system sharing calls are necessary to use SharePoint Team Services. Some features (such as exporting to a spreadsheet) use ActiveX® components and require Microsoft Internet Explorer, but most content is returned to the client computer in HTML format.

Because SharePoint Team Services relies on both the file system and a database to track information about the Web site, these systems must be synchronized. For example, a list in a SharePoint Team Services Web site is a combination of data from the database and from the HTML files. SharePoint Team Services provides tools for backing up the database, but uses the usual operating system tools to back up the file system. Be sure to back up the file system whenever you back up the database. Keeping file system and database backups synchronized will help simplify the process, if you ever need to restore your Web site.

Integration Architecture

When Microsoft Project Server integrates with SharePoint Team Services to enable document library and issue tracking features, it uses the following integration architecture:

Cc750953.depl_psshrpt02(en-us,TechNet.10).gif

Figure 2. Microsoft Project Server and SharePoint Team Services integration architecture

Document Libraries and the Issue List

A default SharePoint Team Services Web site allows you to create multiple document libraries and to upload multiple documents into each document library. SharePoint Team Services provides server-side schema template files used to define fields and view schemas for storing or displaying list data, such as document properties and document library details. SharePoint Team Services schema files are modified for Microsoft Project to add specific document properties that are useful in the project management context.

An issue list is a customized SharePoint Team Services list. When modifying SharePoint Team Services server side template files for Microsoft Project, a default issue list is created for each team Web site that provides specific fields for issue tracking in the project management context.

After the Microsoft Project Server administrator has run the custom SharePoint Team Services Setup and configuration program for Microsoft Project (Stswiz.exe), the SharePoint Team Services server side template is automatically replaced with a specific template for Microsoft Project.

After a team Web site is provisioned on the Web server with the modified SharePoint Team Services template, document libraries and the issue list with the extended and modified fields are created for the site. Microsoft Project Server displays the interface for interacting with project document libraries and the issue list through Microsoft Project Web Access, and stores information about links between documents or issues and projects or tasks in the Microsoft Project Server database.

Communication Between Microsoft Project Server and a Web Server Running SharePoint Team Services

Microsoft Project Server uses multiple methods (based on variations of HTTP protocol) to communicate with Web servers running SharePoint Team Services.

  • XMLHTTP   Microsoft Project Server requests and receives data from SharePoint Team Services by using XMLHTTP. Microsoft Project Server then parses the XML results returned by SharePoint Team Services, and renders the data in Microsoft Project Web Access. For example, it displays data in custom view lists for documents and issues in the left navigation pane of Microsoft Project Web Access, or on the Linked Documents or Issues page that is displayed when you click Link Documents or Link Issues.
  • HTTP   Microsoft Project Web Access pages display a portion of the SharePoint Team Services user interface in IFRAMES by passing the URL of the SharePoint Team Services form to the IFRAME. For example, this occurs when a user opens a document library and sees the document list, or when a user drills down to project issues and sees the Issues list in Microsoft Project Web Access pages.
  • HTTP Based Administrative Protocol   Microsoft Project Server remotely administers SharePoint Team Services Web sites using an HTTP-based protocol. Microsoft Project Server implements the protocol within custom forms to pose requests to the ISAPI file Fpadmdll.dll in Windows (in the Program Files\Common Files\Microsoft Shared\web server extensions\50\isapi\_vti_adm folder). Microsoft Project Server uses this protocol to perform remote administrative tasks on the SharePoint Team Services computer, such as remotely creating a subweb when a project is published to Microsoft Project Server, adding users to appropriate roles in the subweb, and deleting project subwebs.
Middle Layer:

The object link provider object (ProjObjProv.dll) resides in the middle layer of Microsoft Project Server. It exposes interface methods for linking documents and issues to projects and tasks. The link information is stored in the Microsoft Project Server database. The objects related to tasks and projects are not limited to SharePoint Team Services documents and issue items. As long as the unique identifier of an object can be expressed in URL, XML or table IDs, an external object can be easily associated with projects and tasks, or with other external objects by using the object link provider.

Front End: Project Web Access

Microsoft Project Web Access is the single access point for project-related documents and issues. A user should always upload a project document or create a project issue by using Microsoft Project Web Access.

How Project Teams Collaborate on Documents and Issues

Cc750953.depl_psshrpt03(en-us,TechNet.10).gif

Figure 3. How project teams collaborate on documents and issues

A SharePoint Team Services subweb is provisioned for each project published to the Microsoft Web Server database. When a project is published to Microsoft Project Web Server for the first time, the SharePoint Team Services server programmatically provisions the subweb. In enterprise mode, a project could have multiple versions. A subweb is created only for the published version of the project.

When a project subweb is provisioned, the following actions occur:

  • The project subweb does not inherit security from its parent subweb. Therefore, users must be added into roles on each subweb to access project documents and issues in Microsoft Project Web Access.
  • A Windows account that has been specified during setup is the default administrator for each project subweb.

Four Microsoft Project Server custom roles are created on the subweb:

  • Administrator   A replica of the default Administrator role.
  • Project Manager   A replica of the default Advanced Author role.
  • Team Member   The Project Manager role, minus the Design List right.
  • Browser   A replica of the default Browser role.

Microsoft Project Server users are added into respective roles on the subweb, based on their access to a project specified in Microsoft Project Server. Microsoft Project Server users who have the global Manage SharePoint Team Services permission are added into the Microsoft Project Server Administrator role of the subweb.

Project managers who have published the project are added into the Project Manager (Microsoft Project Server) role of the subweb. Users who have Save Project permission to save their work on the project are added into the Project Manager (Microsoft Project Server) role of the subweb.

Team members who have task assignments in a project are added into the Team Member (Microsoft Project Server) role of the subweb. Users who have Open Project permission on the project are added into the Browser (Microsoft Project Server) role of the subweb.

The automatic subweb provisioning works seamlessly for an end user. A project manager creates a project plan, assigns tasks to resources, and publishes the project to Microsoft Project Server. When the plan is published successfully, the project manager can immediately browse to the project document libraries and create project issues, because the SharePoint Team Services subweb has already been provisioned, and the project manager has been given the appropriate rights to interact with the document and issues.

This implies that document and issue security is set on the project level, not on the list level or list item level. Document and issue lists share the same security settings. A project manager can create document libraries, upload documents, create and modify issues, and add new fields to a document or issue list in the project subweb. A team member can create, upload, and modify documents and issues, but does not have permission to add new fields to document or issue lists. A reviewer can only view the documents and issues, but cannot edit document properties or the content of documents and issues.

Public Documents

When you use Microsoft Project Server Setup to install and configure a Web server running SharePoint Team Services, the Setup program creates a default subweb called MS_ProjectServer_PublicDocuments. Document libraries in this subweb serve as an organization's public document depository, as defined in Microsoft Project Server.

The following Project Server custom roles are created for this subweb: Administrator (Microsoft Project Server), and Project Manager (Microsoft Project Server). Users are added to Microsoft Project Server into appropriate roles, either by using the Microsoft Project Web Access Admin center or by publishing a project from Microsoft Project.

Users with permission to manage SharePoint Team Services in Microsoft Project Server are automatically added as Microsoft Project Server Administrators. All other Microsoft Project Server users are added in the Microsoft Project Server Project Manager role so that every Microsoft Project Server user can create document libraries, extend document properties, and upload documents into the Public Documents subwebs. Like project documents, public documents are accessible in the Documents center of Microsoft Project Web Access.

Other List Items in the SharePoint Subweb

In addition to documents and issues, a SharePoint Team Services subweb, once created, contains events, announcement, discussions, and other custom lists. Other SharePoint Team Services lists are not exposed through the Microsoft Project Web Access user interface. Users can access other lists for a specific subweb by navigating to the subweb directly, by using their Internet browser. A URL can be exposed in the Microsoft Project Web Access home page (by customizing the Microsoft Project Web Access home page) that refers to the subweb link.

However, a user should always use Microsoft Project Web Access to submit documents or issues for a project.

Pre-Deployment Considerations

System Requirements and Prerequisites

For detailed hardware, system, and features requirements sections of Microsoft Project Server 2002, see The Server Platform resource kit article.

Intranet vs. Internet Deployment

Microsoft Project Server is targeted at intranet deployment only.

Using an Existing SharePoint Team Services Installation

Microsoft Project Server Setup will install SharePoint Team Services on a designated Windows server if SharePoint Team Services is not already installed.

SharePoint Team Services also ships in the following Microsoft products:

  • Office XP with FrontPage
  • FrontPage 2002

You may already have SharePoint Team Services installed on a server. In this case, STSWiz.exe, part of the Microsoft Project Server Setup program, will configure the SharePoint Team Services server for Microsoft Project Server.

Single Server or Multiple Servers Configuration

Both Microsoft Project Server and Web servers running SharePoint Team Services must reside in the same Windows domain tree.

Small workgroup (10 - 20 people)

A single server computer for Microsoft Project Server, SharePoint Team Services, and Microsoft Desktop Engine (MSDE).

Departmental deployment (100 people)
  • One server computer for Microsoft Project Server
  • One server computer for SharePoint Team Services
  • One server computer for SQL Server
Enterprise Deployment (500 people, and many projects)
  • One server computer for Microsoft Project Server
  • Multiple server computers for SharePoint Team Services
  • One server computer for SQL Server

See Also

For more information about server deployment, see the Microsoft Project Server 2002 Configuration Guidelines white paper on TechNet.

User Accounts

Although Microsoft Project Server (installed without SharePoint Team Services) supports Microsoft Project Server accounts, SharePoint Team Services and Microsoft Project Server integration features require the use of Windows accounts (these can be domain and local Windows accounts).

Installing SharePoint Team Services

Running the SharePoint Configuration Wizard

Microsoft Project Server Setup includes a separate SharePoint Configuration Wizard program. This wizard installs and configures SharePoint Team Services if it has not already been installed. If SharePoint Team Services is already installed, this wizard configures SharePoint Team Services by copying modified server-side template files, creating the public documents subweb, and creating custom roles for Microsoft Project Server.

The SharePoint Configuration Wizard is accessible from Microsoft Project Server Setup.

The suggested running sequence is:

  1. Install and configure SharePoint Team Services.
  1. Install Microsoft Project Server.
  1. Connect to SharePoint Team Services during the custom install of Microsoft Project Server by running STSWiz.exe and SetupSVR.exe.

If you install Microsoft Project Server first, you can still run the SharePoint Configuration Wizard. However, you will need to manually connect Microsoft Project Server to the configured SharePoint Team Services server.

The components that you install and the sequence in which you install them are very important. For best results, plan your deployment prior to installing SharePoint Team Services. There are many articles about planning your Microsoft Project Server deployment on the Microsoft Project Technology Center on TechNet.

See Also

The Microsoft Project Server Installation Guide, Pjsvr10.chm, is included on the Microsoft Project Server Setup CD, or you may download a copy from the General Reference Tools section of the resource kit toolbox.

Establishing a Connection to a SharePoint Team Services Server

There are two ways to establish a connection to a SharePoint Team Services server. You can enter SharePoint Team Services server information during Setup, or enter it later, from the Manage Share Point Team Services Administration page in Microsoft Project Web Access.

Microsoft Project Server communicates with SharePoint Team Services by using the XMLHTTP protocol. In order for Microsoft Project Server to communicate with the SharePoint Team Services computer successfully, the Microsoft Project Server computer must be configured to connect through the proxy server, if your organization uses one. (This requirement is true even when Microsoft Project Server and SharePoint Team Services are installed on the same computer.)

To configure Microsoft Project Server for a proxy server, run the WinHTTP proxy configuration utility by typing proxycfg -d -p proxy-server-list optional-bypass-list at a command prompt, where proxy-server-list is a space-delimited list of one or more proxy servers, and optional-bypass-list is a space-delimited list of servers that should be accessed directly. For example:

Proxycfg -d -p  "proxyserver:80"  "<local>"

If a proxy server is not specified for the given protocol, the -d option specifies that the server should be accessed directly. After running Proxycfg.exe, restart Internet Information Services by typing iisreset at a command prompt. Proxycfg.exe can be found in the Program Files\Microsoft Project Server\Bin folder on the Microsoft Project Server computer.

For more information about Proxycfg.exe, including details about the proxy-server-list and optional-bypass-list parameters, search for "Using the WinHTTP Proxy Configuration Utility" on MSDN.

See Also

The Microsoft Project Server Installation Guide, Pjsvr10.chm, is included on the Microsoft Project Server Setup CD, or you may download a copy from the General Reference Tools section of the resource kit toolbox.

Changing Account Information

There are two Windows accounts that are required by Microsoft Project Server to connect to SharePoint Team Services. One is an administrator account on the server computer for SharePoint Team Services. The other account has at least Read-only access to the SQL Server database on the SharePoint Team Services computer.

To change the Windows account information after you have set up Microsoft Project Server with SharePoint Team Services, run PSCOMPlus.exe, found in the \Microsoft Project Server\Bin\1033 folder of the Microsoft Project Server computer (this folder, 1033, contains the files for the U.S. English version. Files for other languages can be found in the folder that corresponds to the locale ID [LCID] for that language).

PSCOMPlus.exe is used to provide the name of user accounts (in the format domain\account) that should be impersonated by a COM+ application to allow Microsoft Project Server to connect to the SharePoint Team Services and SharePoint Team Services database computers.

Anonymous Access to Web Sites Running SharePoint Team Services

It is recommended that you turn off anonymous access for the project subwebs, so that only authorized users can access documents and issues. You can turn off anonymous access in the Site Administration page for the subweb. You can also turn off anonymous access for each directory in the Internet Information Services Manager.

See Also

For more information on managing anonymous access, see the SharePoint Team Services Administrator's Guide on TechNet.

Security and User Authentication

Windows Security Model

Microsoft Project Server and SharePoint Team Services rely on the security features of Windows 2000 to provide security for Web site content. There are three elements in Windows security:

  • User authentication   The process used to validate the user account that is attempting to gain access to a Web site or network resource.
  • File system security   The ability to control which users gain access to which files or folders in the file system. This security setting applies to project documents and document libraries.
  • Server to server authentication   The process used to validate Microsoft Project Server actions by using a predefined user account that is attempting to gain xmlhttp responses from procedures in SharePoint Team Services, whether SharePoint Team Services is installed on the same server computer or not.

In addition to these elements, Microsoft Project Server includes its own application security module. Permission to access Microsoft Project and Microsoft Project Web Access data (not document and issues) is managed through the Microsoft Project Server administrative features. Security for Microsoft Project Server is supported per user per project at both the application and database layers.

SharePoint Team Services includes a security feature called user roles. By using user roles, you do not have to control file and folder permissions separately, or worry about keeping your local groups synchronized with your list of Web users. You use roles to give users permissions on your Web site, and use SharePoint Team Services administration tools to add new users directly. For more information about user roles, see the SharePoint Team Services Administrators' Guide on TechNet.

User Authentication

User authentication is the process used to validate a user account that is attempting to gain access to a Web site or network resource. When you use Microsoft Project Server with SharePoint Team Services, user authentication is based on Internet Information Services (IIS) authentication methods. IIS provides five forms of user authentication:

  • Anonymous authentication
  • Basic authentication
  • Integrated Windows authentication
  • Digest Access authentication
  • Certificate authentication

Whether you set up Microsoft Project Server on the same computer with SharePoint Team Services or not, Microsoft Project Server and SharePoint Team Services must use the same User Authentication form under IIS version 5.0.

Anonymous authentication

Anonymous authentication provides access to users who do not have Windows NT server accounts on the server computer (for example, Web site visitors). IIS creates the anonymous account for Web services, IUSR_computername. When IIS receives an anonymous request, it impersonates the anonymous account.

You can turn off the anonymous access of a SharePoint Team Services subweb (also known as the project subweb) by changing the anonymous access settings in the Users and Roles section of the subweb's Site Administration page, or by using the Web site properties dialog in IIS.

Basic authentication

Basic authentication is an authentication protocol supported by most Web servers and browsers. Although Basic authentication transmits user names and passwords in easily decoded clear text, it has some advantages over more secure authentication methods, because it works through a proxy server firewall and ensures that a Web site is accessible by almost any Web browser. If you use Basic authentication in combination with Secure Sockets Layer (SSL) security, you can add a layer of protection to the user names and passwords, making your user information more secure.

In your organization, if multiple users share the same desktop, you should enable Basic Authentication only, in combination with SSL. In this case, a user can be authenticated to their SharePoint subweb, regardless of the current logged-on Windows account.

Integrated Windows authentication (also known as Windows NT Challenge Response) encrypts user names and passwords in a multiple transaction interaction between client and server, thus making this method more secure than Basic authentication. The disadvantages of using this method are that it cannot be performed through a proxy server firewall, and that some Web browsers (most notably, Netscape Navigator) do not support it. You can, however, enable both Integrated Windows authentication and Basic authentication at the same time.

Digest Access authentication

Digest Access authentication is similar to Basic authentication, except that a user's account name and password are transmitted in a more secure format. This method requires IIS version 5.0 or later on the server computer, and Internet Explorer version 5.0 or later on the client computer. Digest Access authentication works with domain accounts only; you cannot use Digest Access authentication with local user accounts.

Certificate authentication

Certificate authentication (also known as Secure Sockets Layer [SSL] security) provides communications privacy, authentication, and message integrity for a TCP/IP connection. By using the SSL protocol, clients and server connections (Microsoft Project Web Access and Microsoft Project Server) and server-to-server connections (Microsoft Project Server to SharePoint Team Services) can communicate in a way that prevents eavesdropping, tampering, or message forgery. Using SSL with both Microsoft Project Server and SharePoint Team Services ensures secure authoring across firewalls, and also ensures security during remote administration of SharePoint Team Services or FrontPage Server Extensions 2002.

If you want to enable SSL support, you must ensure that both Microsoft Project Server and SharePoint Team Services are set up to support this.

You can choose the authentication method you want to use when you set up your Web server. You cannot change the authentication method by using the Microsoft Project Server and SharePoint Team Services administration tools; you must use the IIS administration tool for your server computer. However, it is important to keep in mind that Microsoft Project Server and SharePoint Team Services must be configured to use the same User Authentication method.

File System Security

This section addresses how project documents in SharePoint Team Services are secured. SharePoint Team Services relies on the Windows operating system to secure the file system for your project documents. Windows NT, Windows 2000, and Windows XP support access control lists (ACLs) to secure files and folders.

Notes

  • ACLs are supported only by the Windows NT File System (NTFS). Because SharePoint Team Services security is in part based on ACLs, you must use the NTFS file system on the server computer that hosts IIS and SharePoint Team Services or FrontPage Server Extensions 2002.
  • For more information about ACLs, see the topics "File permissions" and "Folder permissions" in Windows 2000 Help, or the "Access control" topic in Windows XP Help.

Server-to-server Authentication

Microsoft Project Server communicates with the Web server running SharePoint Team Services by using xmlhttp. The xmlhttp request coming from Microsoft Project Server must be validated with the administrator privilege on the server computer running SharePoint Team Services. This authentication information is required, even if SharePoint Team Services runs on the same computer as Microsoft Project Server.

As with the installation of Microsoft Project Server and SharePoint Team Services, the administrator needs to provide Microsoft Project Server a Windows account that has administrative privileges on the server computer running SharePoint Team Services.

First, the administrator obtains a domain Windows account or creates a local Windows account on the computer running SharePoint Team Services. She then adds the Windows account to the Administrator NT group of that computer. Finally, she enters the Windows account name and password during the custom installation of Microsoft Project Server, or later, by running PSCOMPlus.exe in the %program files%\Microsoft Project Server\1033\bin directory. If you run PSCOMPlus.exe, you will need to enter the Windows account information in the SharePoint Team Services Administration Identity box of the dialog box, and click Create/Update COM+ Apps.

Administration

Specifying the Current Server

If a Microsoft Project Server is connected to multiple SharePoint Team Services computers, only one SharePoint Team Services session can be active at a time

Provisioning Project Subwebs

As the Microsoft Project Server administrator, you can decide whether Microsoft Project Server provisions project subwebs programmatically. This option resides on the SharePoint Team Services subweb provisioning settings page of the Manage SharePoint Team Services section in the Admin center of Microsoft Project Web Access.

It is recommended that you use the automatic subweb creation option.

Microsoft Project Server programmatically creates the subweb when a project is first published to Microsoft Project Server. A project manager publishes a project to Microsoft Project Server by using Microsoft Project Standard or Microsoft Project Professional. The following two user actions lead to automatic subweb creation:

  • Publish New and Changed Assignments (the first time a project is published)
  • Publish Project Plan (the first time a project is published)
Manually create a project subweb

To create a project subweb manually, you can create the subweb on the Manage SharePoint Team Services subwebs page of the Manage SharePoint Team Services section in the Admin center of Microsoft Project Web Access.

To create a subweb
  1. Publish a project to Microsoft Project Server.
  1. Select a project from the Provision a subweb for drop-down list box, and click Create Subweb.
  1. Wait for the subweb creation process to complete before you navigate away from the page.
Granting project user access to subwebs

You can decide whether Microsoft Project Server automatically creates roles in the project subweb and adds Microsoft Project Servers into the custom SharePoint Team Services subweb roles. The recommended option is automatic, so that when the subweb is created, project managers, team members, and project stakeholders who can view the project are granted access to documents and issues in that project's subweb and in the Public Documents subweb.

You may manually add users to the correct roles in subwebs by using the SharePoint Team Services Administrative Pages.

Synchronizing Users

Project teams are constantly changing. Team members join or leave the team, project managers take on additional responsibilities, and new resource managers or executives come on board. All of these changes lead to changes in Microsoft Project Server user permissions. When you make security changes in Microsoft Project Server, user roles are not automatically updated in the respective project subwebs. Instead, the Microsoft Project Server administrator needs to update user security settings manually, by synchronizing users in the Manage SharePoint Team Services section of the Admin center in Microsoft Project Web Access.

The following sequence of actions takes place when users are synchronized:

  • First, all users are removed from the four Microsoft Project Server custom roles (Administrator, Project Manager, Team Member, and Browser).
  • Next, based on their current access permissions to the project, users are re-entered into the four roles of the respective project subweb.

Synchronizing Administrator Accounts

When new users are given the Manage SharePoint Team Services permission in Microsoft Project Server or when this permission is denied to existing users, the respective roles in SharePoint Team Services are not automatically updated. In this case, the Microsoft Project Server administrator needs to update user security settings manually, by synchronizing administrators in the Manage SharePoint Team Services section of the Admin center in Microsoft Project Web Access.

The following sequence of actions takes place when administrators are synchronized:

  • First, all users are removed from the custom Administrator (Microsoft Project Server) roles in all project subwebs and from the MS_ProjectServer_PublicDocuments subweb.
  • Next, a query is performed to pull out all Microsoft Project users with Manage SharePoint Team Services permission. All of these users are then re-entered into the custom administrator role for all project subwebs and for the MS_ProjectServer_PublicDocuments subweb.

Managing SharePoint Subwebs and the Web Server

Project subweb administration

For project subweb management tasks (such as monitoring server health, site statistics, and user access), it is recommended that you use SharePoint Team Services site administrative pages directly.

In the Manage SharePoint Team Services Subwebs page in the Manage SharePoint Team Services section of the Admin center in Microsoft Project Web Access, you can easily navigate to the HTML administration page of each subweb by selecting the project and clicking Go to Web site administration.

You can use the Site Administration pages to:

  • Manage users and roles. You can add or remove users, edit roles, and change which role a user is a member of.
  • Manage Web document discussion and Web subscription settings. For SharePoint Team Services, you can turn Web document discussions and Web subscriptions on or off for a site, or change settings, such as when subscription notifications are sent by default.
  • Perform usage analysis tasks. For example, you can turn usage analysis log processing on or off and specify usage analysis settings, such as log data expiration times or other scheduling details.
  • Manage server health features. You can detect potential problems on your Web site and repair them with the server health tools. You can also schedule the server health check to be performed automatically.

For more information on administering SharePoint Team Services, see the SharePoint Team Services Administrator's Guide on TechNet.

Server Administration

The Server Administration pages allow you to administer settings for your Web server. You must be a member of the local administrators group for the server computer to view the Server Administration pages. You can use the Server Administration pages to:

  • View the list of virtual servers on your server and find information about each one. For example, you can upgrade your virtual servers to SharePoint Team Services or FrontPage Server Extensions 2002.
  • Specify default settings for the virtual servers and Web sites on the server. You can specify default database, Web document discussion, Web subscription, usage analysis, server health, and security settings.
  • Specify which permissions are available to be assigned to roles and users. You can turn off specific user rights if you do not want them to be available for the Web sites on your server.
  • Reset user passwords. This is for the local Windows NT accounts only. If a user forgets his or her password, you can reset it from the Server Administration pages.

For more information on administering SharePoint Team Services, see the SharePoint Team Services Administrator's Guide on TechNet.

Virtual Server Administration

The Virtual Server Administration pages help control settings for any extended virtual server on your server computer. By default, a newly created virtual server inherits settings from defaults set on the Server Administration pages. You use the Virtual Server Administration pages to change these default settings, and to specify what settings to use for project subwebs of the virtual server. You must be a member of the local Administrators group for the server computer to view the Virtual Server Administration pages.

You can use the Virtual Server Administration pages to:

  • Change configuration settings. You can change performance tuning settings and other settings for your virtual server.
  • Change database settings. For SharePoint Team Services, you can back up and restore the database, schedule automatic backups, or change the database connection settings for a virtual server.
  • Set user account limits. You can set quotas for how many users can be added to a virtual server.

You can only get to the Virtual Server Administration pages from the Server Administration pages. To open the Virtual Server Administration page for a particular virtual server, on the Server Administration page, next to the virtual server you want to administer, click Administration.

For more information on administer SharePoint Team Services, see the SharePoint Team Services Administrator's Guide on TechNet.

Collaborate on Documents and Issues

When SharePoint Team Services is integrated with Microsoft Project, and the Documents and Issues centers have been enabled on Microsoft Project Server, you can create document libraries and issue lists to provide easy access to project-related documents and issues. As soon as a project is published on Microsoft Project Server, a SharePoint Team Services subweb is created for that project as a space for document libraries and issue lists. An administrator can also manually provide a SharePoint Team Services subweb for this purpose. Each project has its own subweb. The Public Documents subweb also serves as a depository of documents that are public to the organization.

Document Libraries

Document libraries store a collection of documents that is analogous to a file folder. These documents can be created based on templates that are associated with document libraries. An authorized user (typically the project manager) defines document library properties, the default document template it uses, and access permissions to the documents published to a document library.

There are two types of document depositories in Microsoft Project Web Access:

  • Project document library   This document library stores documents that are related to a specific project. Each project can have multiple document libraries. Authorized users can create additional document libraries for the project. Project managers, who by default have design list permission on SharePoint Team Services, can make changes to specific document libraries.
  • Public document library   Multiple document libraries are available, any one of which store documents that are accessible to all users in the organization. The server administrator defines who has access to documents in this document library. By default, all Microsoft Project Server users can create document libraries and contribute documents.

When creating a document library, an authorized user, such as a project manager, can use default document library properties defined during Setup, or specify new document library properties. A user may want to define a property that helps track documents in the project.

To simplify document creation, an authorized user can define a template to be used for the document library.

For ease of use, authorized users can create multiple views for a document library.

Document libraries can be searched for specific information. To find a document, the Search tool searches through all document libraries on the server and returns only documents that you have permission to view.

E-mail notifications can alert you when a document is added to a document library or when a document has changed in your project.

Documents in a document library are, by default, associated with a project. A project manager or a team member can associate documents with specific project tasks that have been published to Microsoft Project Server as new or changed assignments.

Documents are clearly marked by a document indicator, and appear in the timesheet, Tasks center, and Projects center of Microsoft Project Web Access. For example, you can access documents submitted into a project lists in the Projects center.

Tracking Issues

Issue tracking improves the efficiency and effectiveness of project management because it allows you to communicate about problems and related action items with team members and stakeholders. Issue tracking provides rich reporting, status indications, e-mail notifications, and alerts to help ensure that issues that come up during the completion of a project get attention and are resolved.

By using SharePoint Team Services to track issues, each issue is treated as a documented collaborative discussion that typically has a process controlling its lifetime. Typically, someone starts the issue process by opening a new issue. Others can then add information to the discussion field of this issue. Eventually, helpful information can be entered in the resolution field and, depending on the type of solution, the issue can be marked as closed or postponed.

SharePoint Team Services provides three levels of security on issues for a project. Read-only permission for stakeholders who need to review issues, edit permission for authorized users such as team members who can create and edit issues, and edit and customization permission for project managers who can customize the specific fields (such as the priority, discussion, or resolution fields) and views (such as the issue list view) used for issues.

By default, an administrator and a project manager can also define additional views for issues in a project. You define a new view by specifying the visible fields in the issue list, the order of issues in the list, the filters applied, and the number of items displayed on a page.

Issues can be associated with projects, tasks, documents, and other issues. When an issue is linked to a task, it can impact the task directly, have the task as a work item, or be related to the task.

Issues are clearly marked by an issue indicator, and appear in the timesheet, Tasks center, and Projects center of Microsoft Project Web Access. For example, newly assigned issues appear in the Home center, and you can access issue lists of projects in the Projects center.

E-mail notifications can alert you when issues have been opened, assigned, or updated, and you can keep track of the status of issues. Depending on the actions taken to resolve them, issues appear as active, closed, or postponed.

Default customization document and issue property lists can be customized to better meet your needs. By default, a Microsoft Project Server administrator or a project manager can extend the properties of the document libraries and add additional tracking fields for issues.

For the document library, an authorized user can change the name of the lists, its security settings, its columns, and its views. Authorized users can also add new columns and change the order of the fields in a column.

For the issue list, an authorized user can add new columns, change the order the fields in a column, and add additional issue views.

For default document columns, you can change the title, status, and ownership settings.

For default issue columns, you can change the title, status, priority, assignment, ownership, and due date settings.

When creating or updating views, you can specify the columns you want to display, the order in which you want the columns displayed, the criteria by which you want to filter information displayed in the columns, and the number of items you want displayed.

Extensibility on STS/Project Server Integration

Microsoft Project 2002 ships default document library and issue tracking features by integrating with SharePoint Team Services. However, SharePoint Team Services may not meet the enterprise user demand for a sophisticated document management or issue tracking process.

As an alterative, Microsoft Project Server is presented as a platform where solution providers can integrate third party document management or issue tracking applications with Microsoft Project Server. The Object Link Provider (OLP) object provides application programmable interfaces for linking projects and tasks to generic external objects, such as documents that reside in a third- party document management system, and issues that reside in a third-party issue tracking application.

The following are some scenarios for developing solutions by leveraging the Object Link Provider object:

  • Integration with an existing Microsoft product store (SharePoint Portal Server or Microsoft Exchange) for collaboration objects.
  • Replacement of the default document library solution, and integration of Microsoft Project Server with a third-party document store, for example Documentum, DocShare, Lotus Notes, and so on.
  • Replacement of the default issue tracking application, and integration with a third-party issue tracking application.
  • Customization on top of the default integration of Microsoft Project Server and SharePoint Team Services.

The Object Link Provider (OLP) object is a server-side object that provides programmability interfaces on linking tasks and projects to external objects. OLP works as follows:

  • First, the solution needs to register the objects, for example, a project, a task, a document, or an issue with Microsoft Project Server. The object can be described using XML or a unique ID, in the simplest case.
  • Next, the solution creates links between any two registered objects based on the feedback from the user interface.
  • Finally, the solution queries for all linked objects, given a specific object ID and display information in the user interface. The architecture diagram is shown below:

Cc750953.depl_psshrpt04(en-us,TechNet.10).gif

Figure 4. Architecture of OLP and Microsoft Project Server interaction. 

The OLP adds, deletes, or updates rows in the following two tables in Microsoft Project database:

MSP_WEB_OBJECTS

FakePre-b7ecc0e3f4f74c63bfa966f9820d7d48-d7350f28d2ac4b949488c753ea28e683

It also exposes application programmable interfaces that allow a solution provider to:

  • Create, delete, or update objects in the Objects table.
  • Create and delete object relationship in the Object Links table.
  • Link or unlink generic objects to projects.
  • Link or unlink generic objects to tasks.

As a result, you can expect to associate tasks and projects stored in Microsoft Project Server to external objects. The objects can be documents stored in Lotus Notes, issues stored in a custom issue tracking application, discussions stored in SharePoint Team Services subwebs, or risks stored in a custom risk tracking application.

You can also expect to associate one object external to Microsoft Project Server to other objects external to Microsoft Project Server. The default features of Microsoft Project 2002 demonstrate that an issue stored in the SharePoint Team Services database can be linked to multiple documents that are stored in the same database. Similarly, an issue can be linked to discussion items, and a document can be linked to a risk.

See Also

SharePoint Team Services Administrator's Guide on TechNet.

SharePoint Team Services Technology Center on TechNet.