Project Server 2010
See Also

Published: September 16, 2010

Explore these links to find out more about implementing Microsoft Project Server 2010.

Microsoft Project Server 2010 provides project management, work management, and portfolio management capabilities for the enterprise. With Project Server 2010, organizations can effectively initiate, select, plan and deliver projects while tracking time and budget. Project Server 2010 also provides extensive reporting capabilities through Excel Services in Microsoft SharePoint Server 2010 for reporting on all aspects of the project lifecycle. Project Server 2010 is built on Microsoft SharePoint Server 2010.

This file, ProjectServer2010.chm, is updated periodically and made available for download, but the information in it may not be as up-to-date as the online version of the content located on Microsoft TechNet (http://technet.microsoft.com/en-us/library/cc303399(v=office.14).aspx).

SharePoint logo

Newly Published Content

See the following pages for new or updated content about Project Server 2010:

  • Newly published content for Project Server 2010

SharePoint logo

Documentation

The TechNet library contains articles that describe how to plan for, deploy, and use all the features of Project Server 2010.

  • Downloadable content for Project Server 2010

  • Product evaluation for Project Server 2010

  • Planning and architecture for Project Server 2010

  • Development for Project Server 2010

  • Deployment for Project Server 2010

  • Operations for Project Server 2010

  • Security and protection for Project Server 2010

  • Technical reference for Project Server 2010

  • Video demos and training for Project Server 2010

Related products:

  • SharePoint Server 2010

Legacy content:

  • Project Server 2007

TechNet logo

TechNet TechCenter

Visit the following site to access videos, community sites, documentation, and more.

  • Project Server 2010

Blogs

Blogs

Check out the latest posts from the Project Server 2010 documentation team and other experts.

  • Microsoft Enterprise Project Management Content Publishing News

Forums

Forums & Newsgroups

Got questions? Talk to your peers, MVPs, and the product team.

  • General Questions and Answers

  • Project Server - Setup, Upgrade, Administration and Operation

Videos, Webcasts

Videos

Watch subject matter experts and TechNet writers walk through tasks and dynamically explain Project Server-related concepts.

  • Video demos and training for Project Server 2010

Stay Connected

Keep connected with the latest happenings with Project Server 2010.

  • Follow us on Twitter

  • RSS feed for Project Server 2010

Chat

Provide Feedback

Provide feedback about the documentation for Project Server 2010 depending on the TechNet view, as follows:

  • Classic View. Use the Click to Rate and Give Feedback link at the top of the article in the TechNet Library. This delivers your feedback directly to the documentation team.

  • Lightweight View. Click the Feedback link at the bottom of the page. This delivers your feedback directly to the documentation team.

  • Scriptfree View. Click the Feedback link at the top of the article in the TechNet Library. This enables you to provide feedback about the scriptfree view to a forum.

To suggest content or request more documentation (or report an error), please contact us at PROJDOCS@microsoft.com.

See Also

Other Resources

Project 2010 and Project Server 2010 (MSDN)
Project Server (Office)
Project 2010 Help and How-to (Office)


Newly published content for Project Server 2010

Published: January 21, 2010

Applies to: Project Server 2010

This article contains a list of new or updated content for Microsoft Project Server 2010. This article is updated regularly.

In this article:

August 12, 2013 | April 30, 2013 | February 4, 2013 | January 14, 2013 | November 26, 2012 | September 17, 2012 | July 30, 2012 | June 4, 2012 | April 23, 2012 |April 2, 2012 | March 26, 2012 | March 19, 2012 | March 12, 2012 | March 5, 2012 | February 27, 2012 | February 20, 2012 | February 13, 2012 | February 6, 2012 | January 23, 2012 | January 16, 2012 | January 9, 2012 | January 2, 2012 | December 12, 2011 | December 5, 2011 | November 28, 2011 | November 14, 2011 | October 24, 2011 | October 10, 2011 | September 26, 2011 | August 22, 2011 | July 11, 2011 │ June 27, 2011 │ June 13, 2011 │ June 6, 2011 │ May 23, 2011 │ May 9, 2011 │ May 2, 2011 │ April 25, 2011 │ April 18, 2011 │ April 11, 2011 │ April 4, 2011 │ March 28, 2011 │ March 21, 2011 │ March 14, 2011 | March 7, 2011 │ February 28, 2011 │ February 21, 2011 │ February 14, 2011 │ February 7, 2011 │ January 24, 2011 │ January 17, 2011 | January 10, 2011 │

Published the week of August 12, 2013

New article

Deploy Service Pack 2 for Project Server 2010 Deploy the Service Pack 2 update for Project Server 2010.

Published the week of April 30, 2013

New article

Cancelling a project without cancelling your career: white paper (Project Server 2010) Describes best practices for recognizing when a project should be stopped, the benefits of doing so, and considerations you need to take into account when cancelling the project.

Published the week of February 4, 2013

Updated article

Plan browser support (Project Server 2010) Updated to include required browser security settings.

Published the week of January 14, 2013

New article

Charging Ahead on Charge Codes: white paper (Project Server 2010) This white paper describes best practices for defining your organization's charge code structure for the project management system or timesheet system.

Published the week of November 26, 2012

Updated article

Plan for using Project Server 2010 in a Hyper-V virtual environment Updated to include information about Project Server 2010 support for Windows Azure.

Published the week of September 17, 2012

New articles

Aligning projects with strategic drivers: white paper (Project Server 2010) This white paper discusses using strategic drivers in Portfolio Management to effectively create a standard approach for making important project decisions.

Would you like some EPM with that?: white paper (Project Server 2010) This white paper discusses the evolution of project management systems, describes the use of Enterprise Project Management, and discusses the importance of understanding which project management solution is best for you.

Published the week of July 30, 2012

Deploy cumulative updates (Project Server 2010) Updated with information about the June 2012 cumulative update for Project Server.

Published the week of June 4, 2012

New article

Microsoft Project Server 2010 SuperFlow Describes and links to the Microsoft Project Server 2010 Upgrade SuperFlow. This SuperFlow is a self-contained interactive Help file that provides a collection of technical content about upgrading to Project Server 2010.

Published the week of April 23, 2012

Updated article

Deploy cumulative updates (Project Server 2010)

Updated article

Database-attach full upgrade to Project Server 2010 Updated to describe how to use the "Bulk Update Project Sites" server settings to relink upgraded project sites to their upgraded projects.

Published the week of April 2, 2012

Updated article

Deploy Service Pack 1 for Project Server 2010 Updated for SQL Server 2012 support.

Published the week of March 26, 2012

New article

Top-down or bottom-up: white paper (Project Server 2010) Discusses project management, portfolio management, and task management, and it compares the top-down and bottom-up management practices related to them.

Published the week of March 19, 2012

Updated articles

Hardware and software requirements (Project Server 2010) and What's new for IT pros in Project Server 2010 Updated to include information about SQL Server 2012 support.

Run Migration Script 7 to compare Project Server 2003 and Project Server 2007 data validation snapshots Updated to include information that the script can provide a false mismatch of task identifiers between Project Server 2010 and Project Server 2007 tasks.

Published the week of March 12, 2012

Updated articles

Create a PWA site (Project Server 2010) Added information about how to resolve slow page loads on servers that are not connected to the Internet.

Deploy cumulative updates (Project Server 2010) Added links that point to the February 2012 Cumulative Update.

Published the week of March 5, 2012

Updated articles

Active Directory Resource Pool Synchronization (Project Server 2010 settings) Updated with requirements for synchronizing the Enterprise Resource Pool with Active Directory users in a different domain.

Manage security group synchronization with Active Directory in Project Server 2010 Updated with requirements for synchronizing Project Server 2010 security groups with Active Directory users in a different domain.

Published the week of February 27, 2012

New article

Set project-level permissions in Project Web App Describes how to set permissions for an individual project, and it explains the differences between project-level permissions and security groups and categories.

Updated articles

Create a PWA site (Project Server 2010) Updated to clarify content database content lockdown procedures for PWA sites deployed to dedicated Web applications.

Managing task updates in Project Web App Updated to include information about previewing the effects of approving a task change.

Microsoft Project Server 2010 Project Manager's Guide for Project Web App Added a table that compares feature availability in Project Web App and Project Professional 2010.

Published the week of February 20, 2012

Updated article

Deactivate a user account in Project Server 2010 Added information about reassigning project ownership and removing user delegations before deactivating an account.

Published the week of February 13, 2012

New article

Project management comparison: Project Professional 2010 and Project Web App Compares the availability of project management features in Microsoft Project Professional 2010 with those in Project Server 2010 Project Web App.

Published the week of February 6, 2012

New article

Project management comparison: Project Professional 2010 and Project Web App Compares the availability of project management features in Project Professional 2010 with those in Project Server 2010 Project Web App.

Published the week of January 23, 2012

Updated article

Best practices for submitting and reporting on actual work (Project Server 2010) Updated to include additional guidance on deleting and changing assignments while in single entry mode.

Published the week of January 16, 2012

New article

Microsoft Project Server 2010 integration with SAP (white paper) Describes the benefits of and scenarios for integrating Microsoft Project Server 2010 with SAP's ERP.

Published the week of January 9, 2012

Updated articles

Microsoft Project Server 2010 Project Manager's Guide for Project Web App Updated with new articles that describe how to work with Microsoft Project Server 2010 data and how to perform project management-related tasks by using Project Web App. New articles include the following:

  • Navigating Project Web App

  • Managing projects in Project Web App

  • Managing resources in Project Web App

  • Managing task updates in Project Web App

  • Managing issues, risks, and documents in Project Web App

  • Managing status reports in Project Web App

  • Configuring e-mail notifications and reminders in Project Web App

Published the week of January 2, 2012

New article

Microsoft Project Server 2010 Project Manager's Guide for Project Web App Describes how project managers can use Project Web App (PWA) to work with Project Server 2010 data and to perform project management-related tasks. The guide can be downloaded in Microsoft Word, PDF, and XPS formats.

Published the week of December 12, 2011

New article

They say they want a resolution: white paper (Project Server 2010) Describes some common challenges when scheduling projects and how to decide the best approach when you want to determine how long tasks should be and how many tasks would optimize a project schedule.

Updated article

Best practices for managing a large number of resources in Project Server 2010 Updated the values for the UserSyncSettings enumeration.

Published the week of December 5, 2011

Updated article

Configure Project Server 2010 to work with Exchange Server 2010 Updated to clarify shell command use of farm administrator and application pool accounts and to clarify that those accounts must have permissions for the Project Server Queue services.

Published the week of November 28, 2011

New articles

Best practices for managing a large number of resources in Project Server 2010 Describes best practices when you are managing project site access in a Project Server 2010 environment in which projects have many users assigned to them.

Testing Project Server 2010 deployments Includes nine new related topics that walk through testing a Project Server 2010 deployment.

Published the week of November 14, 2011

Updated articles

Plan browser support (Project Server 2010) Updated with information about issues resolved by Project Server 2010 Service Pack 1 and Internet Explorer 9 updates.

Review system requirements for upgrade (Project Server 2010) Updated with information about support for Internet Explorer 9.

Published the week of October 24, 2011

Updated articles

Configure Exchange Server 2010 Impersonation and Deploy Project Server 2010 with Exchange Server Revised for Project Server 2010 SP1.

Configure Project Server 2010 to work with Exchange Server 2007 SP2 and Configure Project Server 2010 to work with Exchange Server 2010 Revised for Project Server 2010 SP1. Added a new section that provides information about exporting and importing SSL certificates from Exchange Server to Project Server 2010.

Plan for Exchange integration (Project Server 2010) Updated with new information for Project Server 2010 SP1.

Published the week of October 10, 2011

Updated article

Plan for authentication in Project Server 2010 Updated to reflect that changing the authentication mode in IIS to certificate authentication is unsupported.

Published the week of September 26, 2011

New article

Dashboard directions: white paper (Project Server 2010) Describes considerations and best practices for dashboards in an Enterprise Project Management environment. The article is the newest written by MVP Chris Vandersluis of HMS Software for the "From the Trenches" column in the Project Server 2010 Tech Center.

Published the week of August 22, 2011

Updated article

Deploy Service Pack 1 for Project Server 2010 Updated to include information about the June 2011 cumulative updates for both Project Server 2010 and SharePoint Server 2010.

Published the week of July 11, 2011

Updated article

Deploy cumulative updates (Project Server 2010) Updated with information about the June 2011 Cumulative Update.

Published the week of June 27, 2011

New articles for Project Server 2010 SP1

Deploy Service Pack 1 for Project Server 2010 Describes how to deploy Microsoft Project Server 2010 with Service Pack 1 (SP1). This article provides an overview of key enhancements, deployment instructions, considerations, known issues, and links to related resources.

Updated for Project Server 2010 SP1

Hardware and software requirements (Project Server 2010), Plan browser support (Project Server 2010), and Project Server 2010 with SharePoint Server 2010 architecture (overview) Updated to include information about additional supported Web browsers for Microsoft Project Web App Team Member pages in Project Server 2010 with SP1.

New articles

Database maintenance plans for Project Server 2010 Describes database maintenance recommendations for Project Server 2010.

Updated articles

Install and configure Project Server 2010 and Plan for deployment (Project Server 2010) Updated to specify that Project Server 2010 is not compatible with multi-tenant environments.

Run Migration Script 7 to compare Project Server 2003 and Project Server 2007 data validation snapshots Updated to include information about the script's possibly reporting a false mismatch of task identifiers between Microsoft Office Project Server 2003 and Microsoft Office Project Server 2007 tasks.

Published the week of June 13, 2011

New articles

Plan hardware architecture in Project Server 2010 Discusses the recommended hardware configurations for various Project Server 2010 dataset sizes.

Upgrade from a trial version of Project Server 2010 Describes how to upgrade your Project Server 2010 trial version to the fully licensed version.

Published the week of June 6, 2011

New resource center

Enterprise Project Management (EPM) Content Pivot Viewer Use the pivot viewer to browse a complete collection of articles, white papers, training videos, and models for EPM in Project Server 2010. Pivot on content by lifecycle, solution area, or content type.

Updated article

In-place upgrade to Project Server 2010 Updated to include information about "Missing server side dependencies" errors that are displayed on the Health Analyzer Page after upgrading to Project Server 2010 by using the in-place upgrade method.

Published the week of May 23, 2011

New resource center

New resource center: Server Settings in Project Server 2010 Use this page to find help for the configuration options that are on the Project Server 2010 Server Settings page in Microsoft Project Web App.

New article

Enterprise system best practices: white paper (Project Server 2010) Describes operational best practices that increase the chance for success for enterprise systems such as Project Server 2010. It was written by Chris Vandersluis of HMS Software for the "From the Trenches" column in the Project Server 2010 Tech Center (http://go.microsoft.com/fwlink/p/?LinkId=208599).

Published the week of May 9, 2011

Updated article

Database-attach core upgrade to Project Server 2010 Added five videos about executing a database-attach core upgrade to Project Server 2010.

Published the week of May 2, 2011

Updated articles

Deploy cumulative updates (Project Server 2010) Updated with information about the April 2010 Cumulative Update.

Install and configure Project Server 2010 Added a note that uninstalling Project Server 2010 from a farm is not supported.

Published the week of April 25, 2011

New resource center

Time and Task Management in Project Server 2010 Visit this new resource center to get started with time and task progress tracking in Project Server 2010. Learn how to use Project Web App to submit time spent and progress on tasks.

New article

Accessing Project Web App and Project Professional from a Macintosh-based computer Describes two options for those who want to access a Project Web App site or use the Microsoft Project Professional 2010 client application from a Macintosh-based computer.

Published the week of April 18, 2011

New articles

Project Server 2010: A financial management solution for projects, programs and portfolios (white paper) Describes how Microsoft Project Server 2010 can be used by finance professionals as a financial management solution for their organizations' projects, programs, and portfolios. The paper was written by Arbutus Solutions.

Queue (Project Server 2010 settings) This section includes the following new articles:

  • Manage Queue Jobs (Project Server 2010 settings) Describes how to use the Manage Queue Jobs settings on the Project Web App Server Settings page.

  • Queue Settings (Project Server 2010 settings) Describes the Queue Settings that are available on the Project Web App Server Settings page.

Updated article

Run Migration Script 3 to capture a Project Server 2003 data snapshot Updated to include an important note about pre-creating a blank SQL database to which the script will write results.

Published the week of April 11, 2011

New blog post

Creating an EPM deployment plan and Creating an EPM Deployment Plan: white paper (Project Server 2010) This white paper describes how to deploy the Enterprise Project Management solution in phases, and it includes key issues and estimated durations for each phase. The paper was written by Chris Vandersluis for the "From the Trenches" column in the Project Server 2010 Tech Center (http://go.microsoft.com/fwlink/p/?LinkId=208599).

New articles

Manage delegates (Project Server 2010 settings) This section includes the following new articles:

  • Set up who can act as a delegate (Project Server 2010 settings) Describes how to set up user-level or group-level permissions that enable you to determine which users or groups can act as delegates for other people.

  • Set up who can have delegates assigned to them (Project Server 2010 settings) Describes how to use categories in Project Web App to determine which users or groups can have delegates do work on their behalf.

Workflow and Project Detail Pages (Project Server 2010 settings) This section includes the following new articles:

  • Change or Restart Workflows (Project Server 2010 settings) Describes the Change or Restart Workflow section in Project Web App, which enables you to change a project's in-progress workflow or change a project's current stage in a workflow.

  • Project Detail Pages (Project Server 2010 settings) Describes how to create a Project Detail Page (PDP), which represents a single Web Part Page in Project Web App.

  • Project Workflow Settings (Project Server 2010 settings) Describes the Project Workflow Settings page, which designates the Workflow Proxy User account so that the Project Server Interface (PSI) calls in a workflow can be performed.

Enterprise Data (Project Server 2010 settings) This section includes the following new articles:

  • Enterprise Global (Project Server 2010 settings) Describes the Enterprise Global file and how you can make changes to it.

  • Resource Center (Project Server 2010 settings) Links to articles that describe how to use the Resource Center in Project Web App.

Edit an existing calendar (Project Server 2010 settings) Describes how you can modify the default standard enterprise calendar to account for the working and nonworking times observed by your organization.

Updated articles

Deploy language packs (Project Server 2010) Updated to include additional languages that are supported in Microsoft SharePoint Server 2010 language packs but not in Microsoft Project Server 2010 language packs. This article also describes how the June 2010 Cumulative Update can prevent Project Server 2010 upgrade issues if your SharePoint Server 2010 farm is using a language pack that is not available in Project Server 2010.

Hardware and software requirements (Project Server 2010) Updated with a link to the SQL Server 2008 Analysis Management Objects (AMO) that are needed for reporting. Additionally, this article has been updated with information about Internet Explorer 9 compatibility with Project Web App.

Published the week of April 4, 2011

New articles

Reporting with Microsoft Project Server 2010 (white paper) Describes the various tools available for Project Server 2010 Reporting and how to use them.

Workflow Stages (Project Server 2010 settings) Describes how to create a new workflow stage, which is one step in a project life cycle in Project Web App.

Manage Views (Project Server 2010 settings) The articles in this section describe the different kinds of views in Project Web App and provide information about how to create, modify, copy, and delete these views.

Fiscal periods (Project Server 2010 settings) The articles in this section describe how to define and delete fiscal periods.

Time Reporting Periods (Project Server 2010 settings) The articles in this section describe how to set up and delete time reporting periods in Project Web App.

Updated articles

Plan browser support (Project Server 2010) Updated to describe Internet Explorer 9 support in Project Web App for Project Server 2010

Published the week of March 28, 2011

New articles

Plan for disaster recovery in Project Server 2010 Describes disaster recovery practices for Project Server 2010 using SQL Server tools.

Operational Policies (Project Server 2010 settings) This section includes the following new articles:

  • Alerts and Reminders (Project Server 2010 settings) Describes how to generate e-mail notifications and reminders for each user whenever new, overdue, rejected, or forthcoming events occur in Project Server 2010.

  • Server Side Event Handlers (Project Server 2010 settings) Describes how Project Server 2010 provides public events that enable development of custom processes such as adding and enforcing business rules, validation, data processing, notification services, and workflow.

  • Active Directory Resource Pool Synchronization (Project Server 2010 settings) Describes how Active Directory Enterprise Resource Pool synchronization is used to create or update multiple Project Server enterprise resources at the same time.

  • Project Sites (Project Server 2010 settings) Describes how to manage project sites in Project Server 2010.

  • Project Site Provisioning Settings (Project Server 2010 settings) Describes how to configure settings for project sites.

  • Bulk Update Project Sites (Project Server 2010 settings) Describes how to change site path information for project sites in one Web application to a different one (for example, when migrating).

Additional Server Settings (Project Server 2010 settings) This section includes the following new articles:

  • Project 2007 Compatibility Mode (Project Server 2010 settings) Describes how Microsoft Office Project 2007 compatibility mode allows an upgraded Project Server 2010 instance to accept client connections from Office Project Professional 2007 with Service Pack 2 (SP2) and also from Microsoft Project Professional 2010.

  • Project Professional Versions (Project Server 2010 settings) Describes how you can specify which versions (build numbers) of the Microsoft Project Professional client application will be able to connect to your Project Server 2010 environment.

  • Enterprise Settings (Project Server 2010 settings) Describes how you can determine whether projects will have certain capabilities, such as master projects and local base calendars.

  • Currency Settings (Project Server 2010 settings) Describes how to select the default currency setting for projects that are published to the server.

  • Resource Capacity Settings (Project Server 2010 settings) Describes how to calculate your resources' availability for work over a specified time range.

  • Resource Plan Work Day (Project Server 2010 settings) Describes how you can specify the length of a work day for all resources in your resource plan.

  • Exchange Server Details (Project Server 2010 settings) Describes how Exchange Server can be integrated with Project Server 2010 to provide task synchronization with Microsoft Office Outlook 2007 or Microsoft Outlook 2010.

  • Task Mode Settings (Project Server 2010 settings) Describes how Task Mode Settings let you select the default mode in which tasks will be scheduled: manually or automatically.

Time and Task Management (Project Server 2010 settings) This section includes the following new articles:

  • Timesheet Adjustment (Project Server 2010 settings) Describes how people who have appropriate permissions can adjust timesheet data after a timesheet has been submitted and approved.

  • Timesheet Settings and Defaults (Project Server 2010 settings) Describes options to control how resources enter time on their timesheets and whose approval is required. Also describes how to turn Single Entry Mode on or off.

  • Administrative Time (Project Server 2010 settings) Describes how site administrators can set up different categories for administrative time.

  • Task Settings and Display (Project Server 2010 settings) Describes how site administrators can change how resources report task progress, how actual work can be updated, and other task settings.

Quick Launch (Project Server 2010 settings) The articles in this section describe how to configure the Quick Launch (the left navigation list) in Project Web App. They include information about adding, deleting, and modifying Quick Launch links; changing Quick Launch behavior; and reordering items on the Quick Launch.

Enterprise Calendars (Project Server 2010 settings) The articles in this section describe how you can use enterprise calendars in Project Web App to capture the predefined working hours, holidays, and other schedule details in an organization. They include information about copying or deleting an existing calendar, and modifying working and nonworking times.

Published the week of March 21, 2011

New article

Manage security group synchronization with Active Directory in Project Server 2010 Describes how to configure security group synchronization with Active Directory in Project Server 2010.

Updated article

Configure reporting for Project Server 2010 Added a note clarifying the different database access methods used by Microsoft Excel 2010 and Excel Services in SharePoint.

Published the week of March 14, 2011

New articles

Delete enterprise objects (Project Server 2010) This section contains the following new articles:

  • Delete projects (Project Server 2010)

  • Delete resources and users (Project Server 2010)

  • Delete status report responses (Project Server 2010)

  • Delete timesheets (Project Server 2010)

  • Delete user delegates (Project Server 2010)

Portfolio Analysis with Microsoft Project Server 2010 (white paper) Points to a comprehensive user guide for the Portfolio Analysis module of Project Server 2010. The intended audience is an experienced non-technical user or PMO administrator charged with analyzing portfolios of projects withinProject Server 2010.

Project Server 2010 performance counters Defines performance counter information for Web server, database server, and the project application server.

Visual Studio Team Foundation Server 2010 and Project Server Integration Feature Pack Discusses the Visual Studio Team Foundation Server 2010 and Project Server 2010 Integration Feature Pack and links to various resources in MSDN and the Microsoft Download Center.

Updated article

Deploy cumulative updates (Project Server 2010) Updated with information about the February 2010 Cumulative Update.

Published the week of March 7, 2011

New articles

Enterprise Custom Fields and Lookup Tables (Project Server 2010) Describes enterprise custom fields and lookup tables in Microsoft Project Server 2010 and explains how they are used. This section includes the following articles:

  • Add or edit an Enterprise Custom Field (Project Server 2010)

  • Add or edit an Enterprise Custom Lookup Table (Project Server 2010)

Updated article

SharePoint 2010 Products administration by using Windows PowerShell Added a section about scripts and execution policies.

Published the week of February 28, 2011

New article

Project Server 2010 Administrator's Guide Describes how to help your organization manage the tasks involved in administering Project Server 2010. The guide can be downloaded in Microsoft Word, PDF, and XPS formats.

Updated articles

Microsoft Project Server 2010 default categories Deleted the reference to the "My Personal Projects" category.

Add a user account in Project Server 2010 Clarified the procedure for adding a user account and reorganized the article for greater usability.

Create a category in Project Server 2010 Clarified the procedure for adding a custom security category and reorganized the article for greater usability.

Published the week of February 21, 2011

New articles

Videos: Time and task progress workflow overview (Project Server 2010) These videos illustrate the workflow for entering, submitting, and approving time and task progress by using a single view (single entry mode), separate views, or through a delegate. Videos also address what to do after a time reporting period has closed or after a task has been locked from being updated.

About the Quick Launch in Project Web App Describes the Quick Launch in Project Web App. You can use the Quick Launch to access Project Web App features such as tasks and timesheets.

Published the week of February 14, 2011

New article

SQL script for known Project Server 2010 upgrade issues Provides a SQL script you can use to detect known issues that might cause the upgrade process to fail when you attempt to upgrade from Microsoft Office Project Server 2007 to Project Server 2010.

Published the week of February 7, 2011

Updated article

Project Server 2010 global permissions Added the Manage Drivers global permission.

Published the week of January 24, 2011

New articles

Use Project Web App (Project Server 2010) Describes how to configure and use Microsoft Project Web App. This content is designed for team members, project managers, portfolio managers, and site administrators.

Deploy cumulative updates (Project Server 2010) Describes how to install cumulative updates for Microsoft Project Server 2010.

TechNet Webcast: Information About Microsoft Project and Project Server Cumulative December 2010 Update (Level 200) Provides a brief overview of the recently released Project 2010 and Project Server 2010 Cumulative Update for December 2010. This article also provides a link to the slide presentation used for this Webcast.

Published the week of January 17, 2011

New article

Accessing Project Web App and Project Professional from a Macintosh-based computer Describes two options for those who want to access a Project Web App site or use the Microsoft Project Professional client application from a Macintosh-based computer.

Published the week of January 10, 2011

Updated articles

Set up SQL Server for a Project Server 2010 test environment Added a procedure to confirm that TCP/IP connections are enabled.

Plan for Exchange integration (Project Server 2010) Updated with information about supported protocols.


Downloadable content for Project Server 2010

Updated: June 11, 2013

Some of the content in the Microsoft Project Server 2010 technical library is available in downloadable and printable file formats (.doc, .pdf, or .xps). To download this content, see Guide for IT Pros for Microsoft Project Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=196217). The most current content is in this technical library on the Web.

The content in this technical library is augmented by content available for download. You can download a copy of the entire Microsoft Project Server 2010 TechNet library as a compiled help (.chm) file, or review the following table for a list of downloadable books, posters, and white papers.

If you are interested in using any of the available .doc or .pdf files on an e-reader, visit this To The SharePoint blog post to let us know, and to get some information about using currently available files on e-readers.

Planning

Type | Title | Description | Updated date | URL | Size (MB)
Downloadable Book | Microsoft Project 2010 Ignite training slide presentation | This set of Microsoft PowerPoint slide presentations is used in conjunction with Microsoft Project 2010 "Ignite" training. | 2/1/2010 | http://go.microsoft.com/fwlink/p/?LinkId=182373 | 31
Downloadable Book | Time and task progress workflow diagrams | These diagrams illustrate the workflow for entering, submitting, and approving time and task progress. These operations can be done by using a single view or separate views, through a delegate, after a time reporting period has closed, or after a task has been locked from updating. | 12/9/2010 | http://go.microsoft.com/fwlink/p/?LinkId=207021 | .4
 | ProjectServer2010.chm | This is a downloadable compiled Help format (CHM) version of the Project Server 2010 technical library content on TechNet. | 6/6/2013 | http://go.microsoft.com/fwlink/p/?LinkId=208323 | 3.3
 | Downloadable book: Guide for IT Pros for Microsoft Project Server 2010 | This is a downloadable and printable version (available in .doc, .pdf, and .xps file formats) of the Project Server 2010 technical library content on TechNet. | 1/7/20211 | http://go.microsoft.com/fwlink/p/?LinkID=207623 | 5
 | Project Server 2010 Administrator's Guide | This guide (available in .doc, .pdf, and .xps file formats) helps your organization understand the tasks that are involved with administering Project Server 2010. It includes many step-by-step procedures and accompanying user-interface screen shots of Project Web App. The format of this guide resembles the Microsoft Office Project Server 2003 role guides. | 2/25/2011 | Project Server 2010 Administrator's Guide | 6 MB
 | Technical diagrams | Two diagrams related to upgrade and migration are available | 2/12/2010 | Technical diagrams (Project Server 2010) | 4 MB

Change History

Date | Description
June 11, 2013 | Updated version of ProjectServer2010.chm.
May 12, 2010 | Initial publication


Project 2010 Ignite training slide presentation

Published: May 12, 2010

This set of Microsoft PowerPoint slide presentations is used in conjunction with Microsoft Project 2010 "Ignite" training.

Download the Project 2010 "Ignite" training slide presentation file (http://go.microsoft.com/fwlink/p/?LinkId=182373).

The downloadable file contains the following eleven presentations that are used in the three-day training course:

  • Project 2010 Ignite Introduction

  • Project 2010 Overview

  • Project 2010 Planning, Design, and Deployment

  • Project 2010 Upgrade and Migration

  • Project 2010 Demand Management

  • Project 2010 Portfolio Strategy

  • Project 2010 Timesheets and Statusing

  • Project 2010 Reporting

  • Project 2010 Administration

  • Project 2010 Operations

  • Project 2010 Developer

Project 2010 Ignite training series presentations and demos are available for you to view on-demand. See Project 2010 Ignite on-demand training videos for more information.

What is the Project 2010 "Ignite" program?

The Project 2010 "Ignite" program is a three-day, instructor-led training course for Enterprise Project Management 2007 partners and the Microsoft field staff in technical roles. The goal for the Project 2010 "Ignite" program is to prepare EPM professionals for deployment, operations, and customization of Project Server 2010, hence to build skilled EPM partners by RTM.

The "Ignite" curriculum is targeted towards EPM consultants, IT professionals, admin professionals, and developers that have experience deploying, operating, and customizing Microsoft Office Project Server 2007. Content is technical and ranges from 300 to 400 levels (Experienced to Advanced/Expert). With this in mind, the "Ignite" content is not designed to cover all Project Server functionality. Only the new functionality of Project Server 2010 is presented. In other words, the goal is to help better understand the differences and new features. The content is a combination of instructor-led training, product demonstrations, and hands-on labs. The Project 2010 "Ignite" training is delivered in English by EPM experts from Microsoft.


Time and task progress workflow diagrams (Project Server 2010)

Published: December 2, 2010

Microsoft Project Web App enables you to easily track the time you spend on a project's tasks, and the progress of those tasks toward completion. In the version of Project Web App that is included with Microsoft Project Server 2010, you can enter time and task progress using the same view, or using separate views. You can also assign someone else to enter and submit your time and task progress information on your behalf. This person is called a "delegate."

The following set of diagrams illustrates the workflow for entering, submitting, and approving time and task progress using a single view, separate views, through a delegate, after a time reporting period has closed, or after a task has been locked from updating.

These diagrams are available in three formats. Click a link to download the file:

  • Time and task progress workflow diagrams in a Visio file (345 KB) (http://go.microsoft.com/fwlink/p/?LinkId=207021)

  • Time and task progress workflow diagrams in an XPS file (232 KB) (http://go.microsoft.com/fwlink/p/?LinkId=207022)

  • Time and task progress workflow diagrams in a PDF file (211 KB) (http://go.microsoft.com/fwlink/p/?LinkId=207020)


Product evaluation for Project Server 2010

Published: May 12, 2010

Summary: This article provides links to articles about product evaluation.

In this section:

  • What's new for IT pros in Project Server 2010

    This article provides a brief overview of the new main features and capabilities that are included in Microsoft Project Server 2010.

  • Project Server 2010 with SharePoint Server 2010 architecture (overview)

    This article discusses planning considerations that a SharePoint farm administrator should make when planning to deploy Microsoft Project Server 2010.

  • Project 2010 Ignite on-demand training videos

    The Microsoft Project 2010 Ignite Online Recordings let you view eight-and-a-half hours of presentations and product demonstrations from the Project 2010 Ignite Training Series.

  • Project Server 2010 IT-Professional TechNet Webcasts

    The Microsoft Project Server 2010 IT-Professional TechNet Webcast series is composed of seven downloadable Webcasts that are meant to provide Project Server 2010 deployment guidance and best practices for IT professionals.

  • Project 2010 MVP Webcast Series

    The Microsoft Project Server 2010 MVP TechNet Webcast Series is composed of ten downloadable Webcasts that provide guidance and best practices to end users, IT professionals, and developers.

  • Project Server 2010 Demand Management Webcast series

    The Microsoft Project Server 2010 Demand Management Webcast Series is composed of four on-demand webcasts targeted at end users. These webcasts introduce the concepts of Demand Management.

  • Project management comparison: Project Professional 2010 and Project Web App

    This article compares the Web-based project management capabilities of Project Web App in Project Server 2010 with those same capabilities in Project Professional 2010.

  • "From the Trenches" white papers

    This article summarizes the EPM white papers written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.


What's new for IT pros in Project Server 2010
See Also

Published: May 12, 2010

This article provides a brief overview of the new main features and capabilities that are included in Microsoft Project Server 2010. These include the following:

  • Performance enhancements with 64-bit architecture

  • Integration with SharePoint Server

  • Unified project and portfolio management

  • Demand management

  • Project Detail Pages (PDPs)

  • Workflow integration

  • Business intelligence

  • Departmental custom fields

  • User delegation

  • Support for multiple OLAP cubes

  • New grid control in PWA

  • Ribbon user interface in Project Web App

  • Timesheet single entry mode

  • Integration with Exchange Server

  • Claims-based authentication

  • Backwards Compatibility Mode (BCM) for upgrade

  • Virtual Migration Environment (VME) for migrating Project Server 2003 data

  • Windows PowerShell

Performance enhancements with 64-bit architecture

Project Server 2010 is available in a 64-bit version, similar to Microsoft SharePoint Server 2010 (which is an installation requirement). The move by Project Server 2010 toward 64-bit architecture requires the following:

  • Project Server 2010 must be installed on either 64-bit Windows Server 2008 SP2 or Windows Server 2008 R2.

  • Your database servers for a Project Server 2010 farm deployment must be the 64-bit version of SQL Server 2005, SQL Server 2008, or SQL Server 2012.

    Important:

    The SharePoint Server 2010 Service Pack 1 and Project Server 2010 Service Pack 1 updates must be installed to your Project Server 2010 installations in your farm in order to use SQL Server 2012 to host your farm databases.

Having 64-bit architecture on both the server and the database server provides for increased performance and scalability. Also, 64-bit architecture provides for increased memory addressability because it is not limited to the 4-GB address space limitation that 32-bit architecture is limited to.

Note:

For more information about requirements, see Hardware and software requirements (Project Server 2010).

Note:

Microsoft Project Professional 2010 and Microsoft Project Standard 2010 are available in both 32-bit and 64-bit versions.

Integration with SharePoint Server

Project Server 2010 is built on Microsoft SharePoint Server 2010, the successor to Microsoft Office SharePoint Server 2007. New features in Microsoft Project Web App require SharePoint Server 2010, such as pages that use the SharePoint Server Report Center for storing and viewing reports, workflows required for demand management, and business intelligence features for reporting. Portfolio analysis also extensively integrates with the SharePoint Server workflow architecture. Before you can install Project Server 2010, you must install SharePoint Server 2010 Enterprise edition. For information about Project Server 2010 architecture, see Project Server 2010 architecture.

For more information about SharePoint Server 2010 features, see the What's New in Microsoft SharePoint Server 2010 Resource Center (http://go.microsoft.com/fwlink/p/?LinkID=189569) on TechNet.

Unified project and portfolio management

The essential functionality of Microsoft Office Project Portfolio Server 2007 is now integrated and extended within Project Server 2010. The PSI Web services are extended to include portfolio analysis, workflows, and business drivers. The benefits of having portfolio analysis capabilities in Project Server 2010 include the following:

  • Project Web App provides both project and portfolio management capabilities in one application, with a consistent and extensible SharePoint Server user interface.

  • A common data store eliminates the need for the Project Server Gateway.

  • Administration is centralized.

  • Duplicate functionality, such as a module for capturing project requests, is eliminated.

  • The common object model enables much better extensibility and integration with other applications.

  • Reporting and OLAP cubes can easily provide integrated views.

The core feature of Office Project Portfolio Server 2007 is the Optimizer. Integration with Project Server 2010 does the following:

  • Analyzes a set of project proposals based on business driver priorities.

  • Improves Optimizer usability and provides integrated security with Project Server permissions, international reach, and ease of deployment.

  • Eliminates the duplication of functionality and data in the separate Project Server and Portfolio Server products.

  • Provides access to business driver libraries, cost constraints, and related project entities through Web Parts and SharePoint Server 2010 lists.

Demand management

Demand management is about capturing all work proposals in one single place, taking these proposals through a multi-stage governance process, making decisions on which proposals to approve, and tracking progress on their execution until the work is completed. A key component within demand management is the Workflow governance model we have now implemented within Project Server.

The Proposals feature in Office Project Server 2007 helps capture demand in one place, but it is not flexible enough and does not have a full-fledged governance workflow behind it. The "Builder" module in Office Project Portfolio Server 2007 is a flexible demand management paradigm, but it does not have the familiar look and feel of Office Project Server and Office SharePoint Server, and it also has some usability and scalability problems. The demand management functionality in Project Server 2010 is designed to be both flexible and usable.

For more information about demand management, see Workflow and Demand Management.

Project Detail Pages (PDPs)

Demand management for project proposals and the portfolio planning processes in Project Web App use project detail pages (PDPs) that can be integrated with workflows. PDPs are Web Part pages; they are built with the SharePoint Server infrastructure to show or edit details of entities for project planning such as project information, resources, schedule, or strategic impact. Additional infrastructure for PDPs in Project Server 2010 incorporates the business case capability of the Builder component in Office Project Portfolio Server 2007.

PDPs can be used in many different ways in Project Web App and other applications in the SharePoint Server farm where Project Server resides. You can create three kinds of PDPs in the Project Detail Pages page of Project Web App (http://ServerName/ProjectServerName/Project%20Detail%20Pages/Forms/AllItems.aspx). Use the Documents tab of the page to create a PDP.

  • Project Used for editing project details in a non-workflow enterprise project template, or in other applications.

  • New Project Used for creating a project. This type of PDP is required with an enterprise project template that has a workflow for portfolio analysis.

  • Workflow Status Shows the current stage and status for a project proposal.

You can customize PDPs by using Web Parts and a ribbon interface. Project Server 2010 includes the following new Web Parts for PDPs:

  • Buttons Web Part Enables users to edit, save, publish, or close a project detail page, or to move to the next stage in a workflow. A long page can include multiple Buttons Web Parts.

  • Workflow Status Web Part Enables users to check the status of Project Server workflows.

  • Project Fields Web Part Enables users to select or edit project custom fields for the PDP. Project summary task fields such as cost and actual work are read-only. Custom fields such as the project name, department, workflow management, start date, and owner are read/write.

  • Strategic Impact Web Part Includes all business driver definitions filtered by one or more departments. This Web Part enables users to rate the project impact on each driver.

  • Dependencies Web Part Enables users to define dependencies between projects.

PDPs offer a project management experience that is improved from the project proposal feature in Office Project Server 2007. Office Project Web Access in Office Project Server 2007 has only two pages for project proposals that cannot be customized: a page for an alphabetical list of all project custom fields and a page for tasks in the proposed project. Project Server 2010 enables users to create an unlimited number of pages and to control exactly what project data is available on each page.

For example, users can create workflow-controlled pages by using the Project Fields Web Part to capture detailed project and business case information. The pages can include rich text and can access the Project Timeline Web Part and Schedule Web Part by using the PDP infrastructure. PDPs can include simple Web Parts, such as the Content Editor Web Part that displays rich text and images, or custom Web Parts that capture or display data from an external line-of-business (LOB) system.

PDPs provide a highly customizable project-creation experience. They can integrate with the Ribbon user interface in Project Web App, provide Quick Launch navigation elements specific to individual pieces of project data, and dynamically filter custom fields by departmental association.

PDPs can integrate Project Web App with many different project management scenarios, such as the following:

  • Assessing the project impact of strategic objectives.

  • Providing workflow-driven capture of details in project proposals.

  • Providing workflow-driven strategic alignment; for example, getting executive buy-in before proceeding to a certain stage.

  • Performing portfolio analyses based on cost and resource-capacity constraints.

  • Performing project cost budgeting.

  • Performing customized resource planning.

  • Providing step-by-step detailed task scheduling.

Many of these scenarios are involved with demand management. For more information, see Workflow and Demand Management (http://go.microsoft.com/fwlink/p/?LinkId=189587) in the MSDN Library online. For more information, you can also see Workflow and Project Detail Pages (Project Server 2010 settings).

Workflow integration

Workflows are a core feature of project portfolio management. A project life cycle can include long-running processes that span many phases. Governance phases include project proposals, analysis of business impact, selection, creation, planning, managing, and tracking.

Although Office Project Portfolio Server 2007 includes workflows, Project Portfolio Server itself is not extensible and the workflows are difficult to build. The integration in Project Server 2010 of portfolio and project management provides a rich and extensible platform for building workflows that are based on the SharePoint Server 2010 workflow platform.

Project Server 2010 workflows extend the SharePoint Server workflow security model to allow installation across a SharePoint Server farm and access by multiple users who have the appropriate Project Server permissions. Workflows are run by impersonation of a special Project Server user. Impersonation and the use of proxy assemblies enable users of Project Server workflows to call the Project Server Interface (PSI) on the application server, instead of calling the PSI through the front-end Web server (Project Web App).

In addition to portfolio management, Project Server 2010 also enables the creation of workflows for resource, task, and timesheet management. For more information, see Workflow and Demand Management (http://go.microsoft.com/fwlink/p/?LinkID=189587). For a series of how-to articles, see Developing Project Server workflows (http://go.microsoft.com/fwlink/p/?LinkId=189598). For more information about workflow integration, see Workflow and Project Detail Pages (Project Server 2010 settings).

Business intelligence

Business intelligence features enable you to visualize the amalgamated data as answers to customer questions. In Project Server 2010, Excel Services is integrated with Project Server to make it easier to create custom reports. As part of this integration, blank data-connected spreadsheets and predefined reports are provided. Additionally, the data available for reporting has been expanded to include timesheet custom fields, project properties, and portfolio planner and optimizer data. The predefined cubes can now be customized by using PWA to only include data for a given department.

For more information about Business Intelligence in Office Project Server 2007, see the blog post Project 2010: Business Intelligence Overview (http://go.microsoft.com/fwlink/p/?LinkId=189600). For additional resources, see the Business Intelligence in Project Server 2010 Resource Center on TechNet.

Departmental custom fields

Many enterprise customers manage projects for multiple departments on one instance of Project Web App. An important issue is how to deal with different requirements for enterprise custom fields in different departments. In Office Project Server 2007, all users can see all enterprise custom fields, even though a subset of the custom fields might apply to only one of the departments. Some customers have created workarounds to the problem by using local custom fields with additional custom programming, but that is a poor long-term solution.

Project Server 2010 introduces departmental custom fields. Each department can use its own set of enterprise project, task, and resource custom fields, and departments can also share specified custom fields. Project Server can filter out custom fields that are not assigned to a department, so users see only relevant custom fields.

Project Server 2010 can restrict users who have permission to edit custom fields in one department from using Project Web App to edit the custom fields of another department where they do not have permission. Project Professional enables access to all custom fields, although it can filter lists based on the department for a project. If you are not a member of a department, then you only have to fill in the global required fields, not other departmental fields.

The PSI is extended to specify departments and includes setting custom fields and permissions by department. The PSI can also create departmental collections; associate projects, resources, lookup tables, and custom fields within a collection; and define which custom fields are required in a departmental collection. Collections are defined in the default Collections lookup table. The Collections lookup table can be modified, but it cannot be deleted. The PSI enables users to edit custom fields in collections owned by other departments.

User delegation

In Office Project Server 2007, the timesheet surrogate feature allows one timesheet user to give the management of the timesheet to another user (for example, to send updates). However, there are many other parts of Project Web App where you may want to delegate your duties to another user, if possible. In Project Server 2010, the delegation feature was introduced as a response to this need. The delegation feature allows one user to act as another user, no matter the permission-level difference between the two. As an example, a team member can be a delegate for an administrator, which means that when the team member becomes the delegate, that person has all privileges that the administrator has.

For more information about using delegation, see Turn user delegation on or off (Project Server 2010 settings).

Support for multiple OLAP cubes

The Cube Building Service (CBS) in Project Server 2010 supports building departmental and multiple data-sliced cubes. Site collection administrators for Enterprise Project Management (EPM) can build multiple customized cubes, such as the following:

  • Cubes that contain only data for project and resources that they administer.

  • Cubes that contain only the facts and dimensions that they select.

"Multicubes" enable you to slice the data in cubes by picking groups of data and adding fields from each group. Administrators can constrain access to cubes by department. Project Server 2010 also supports localized data in cubes, with the use of translators. All data can have localized field name aliases, so you can build PDPs that show field names in the language of the locale where they are deployed. Cubes support "manually scheduled task" data, with tasks shown as properties instead of in a task dimension. Manually scheduled tasks are a new feature in Microsoft Project Professional 2010. Project Professional allows you to choose the task mode — either automatically scheduled (the traditional mode) or manually scheduled. Cubes exclude inactive tasks by default, but they can include a dimension for task assignments and show active or inactive tasks.

The CBS in Project Server 2010 also reduces blocking of RDB updates when a cube build begins. One of the problems with OLAP cubes for large deployments of Office Project Server 2007 has to do with delays caused by rebuilds: project reports that use the RDB can be delayed by waiting for the central cube to be rebuilt before new data can be seen. Project Server users who have the relevant administrative permissions can build smaller custom cubes at a time they select. Project Server administrators can push the administrative load of building new custom fields and cubes down to departmental teams, thereby helping to reduce the conflicts about data in the cubes and timing of reports.

OLAP multicubes do not support Microsoft SQL Server Analysis Services 2000 or Decision Support Objects (DSO). The minimum requirement is 64-bit Microsoft SQL Server 2005 SP2 and the Analysis Management Objects (AMO) managed code API. AMO is also a 64-bit implementation in the 64-bit versions of SQL Server and reduces version configuration issues for upgrades.

New grid control in PWA

Project Web App users will now use the new Project Server 2010 AJAX Grid control to view their pages. It is a JavaScript grid control that supports both read and write operations. It is faster than the previous control, has cell validation, a rich color palette, and an interactive field chooser. Unlike the ActiveX controls previously used in Office Project Server 2007, the AJAX Grid does not require local installation and avoids security concerns about downloading unsigned controls.

To access Project Server 2010, Project Web App users are required to use Internet Explorer 7, Internet Explorer 8, or Internet Explorer 9. Additionally, the Service Pack 1 update for Project Server 2010 provides support for specific versions of additional browsers (Firefox, Google Chrome, and Apple Safari) to access Project Web App pages that are frequently used by team members. For more information about browsers, see Plan browser support (Project Server 2010).

Ribbon user interface in Project Web App

SharePoint Foundation 2010, SharePoint Server 2010, and Project Web App in Project Server 2010 are adopting the ribbon user interface component. The Project Web App experience will be more consistent with the Project Professional 2010 user experience, so project managers can work in similar ways within both client applications. The ribbon interface also makes it easier for users familiar with other SharePoint Server applications to move to Project Web App.

Pages in Project Web App that are frequently used by the Project Management Office (PMO), project managers, resource managers, and team members use the Server Ribbon interface. Other pages that are infrequently used, such as administrative pages in Server Settings and some pages in Personal Settings, do not need the Ribbon.

The ribbon is customizable and extensible. In Office Project Server 2007, it was difficult or impossible for third-party developers to customize many pages in Project Web App. Project Server 2010 makes it easier to customize and extend the non-administrative pages. For more information, see the "Customize the Project Web App Ribbon" section in Scenarios for Project Server development (http://go.microsoft.com/fwlink/p/?LinkId=189618).

Timesheet single entry mode

Project Server 2010 introduces a new time-tracking mode that unifies the data entered by using the timesheet and status pages in Project Web App. The timesheet single entry mode is implemented through the Timesheet methods in the PSI to provide integrated access to Administrative time. The single entry mode is augmented with additional data that is required to transfer items not previously available in the Timesheet schema.

For more information about timesheet single entry mode, see Overview: Enter time and task progress in one view (Project Server 2010).

Integration with Exchange Server

Office Project Server 2007 integrates with the Microsoft Office Outlook 2007 client application, which enables team members to see and report time on assignments via an Outlook add-in. In contrast, Project Server 2010 integrates directly with Exchange Server 2007 SP1 (or later), not with Outlook, so team members anywhere with access to Exchange Server can interact with assignment data in Outlook or Microsoft Outlook Web App.

Project Server sends updated task and assignment information to Exchange Server, which handles all client interaction with Outlook and Outlook Web App. Exchange Server notifies Project Server when an Outlook client changes the assignment data. Project Server spawns a queue job that gets the data from Exchange Server, and then uses the public Statusing API to update the information in Project Web App.

For more information about Project Server 2010 integration with Exchange Server, see Deploy Project Server 2010 with Exchange Server.

Claims-based authentication

Claims based authentication is a new authentication method available to Project Server 2010 through SharePoint Foundation 2010 and SharePoint Server 2010.

Claims-based authentication systems provide for federated authentication services such as Active Directory Federation Services (ADSF), single sign-on mechanisms and so forth. In a claims-based authentication system a security token exists and is made up of a set of identity assertions about an authenticated user. Assertions are attributes that are associated with a user's identity. Assertions can include a user name, a role, an employee ID, and a variety of other attributes that can be used to determine authorization. A Security Token Service (STS) responds to authentication requests and creates the token based on account information in various attribute stores. The token is then used to authenticate actions. In essence, claims-based authentication provides flexibility beyond the traditional Windows NTLM/Kerberos authentication method.

For more information about claims based authentication as well as STS, see the following articles:

  • Plan authentication methods (SharePoint Foundation 2010)

  • Plan for authentication in Project Server 2010

  • Brokered authentication: Security Token Service (STS) (http://go.microsoft.com/fwlink/p/?LinkId=189619)

Backwards Compatibility Mode (BCM) for upgrade

After upgrading to Project Server 2010, the Backwards Compatibility Mode (BCM) feature allows Microsoft Office Project Professional 2007 with Service Pack 2 users to connect to the server. This feature provides network administrators some flexibility in planning to upgrade their Office Project Professional 2007 clients to Project Professional 2010, because it does not need to happen immediately. When BCM is enabled, Project Professional 2010 users are able to connect to Project Server 2010, although some of the new features are not enabled. After you have upgraded all your Project Professional clients to Project Professional 2010, BCM can be disabled. This allows for full feature use by your Project Professional 2010 users. For more information about BCM, see Backward compatibility mode (BCM) (Project Server 2010).

Important:

When BCM is disabled, it cannot be re-enabled again. Verify that you are truly ready to disable BCM prior to doing it.

Important:

Office Project Professional 2003 users cannot connect to Project Server 2010, even when BCM is enabled.

Virtual Migration Environment (VME) for migrating Project Server 2003 data

If you are in a Project Server 2003 environment, you must migrate your data to Office Project Server 2007 prior to upgrading to Project Server 2010. The Virtual Migration Environment (VME) is a Office Project Server 2007 environment in a Hyper-V image that serves as a temporary pass through environment to migrate your data to Office Project Server 2007. It can be installed as a stand-alone environment and does not need to be connected to your network, and Project Server 2003 data can be made accessible to it from an external hard drive. It does not require any additional licensing, as long as you only use it for the intended purpose of migrating your data. For more information about the VME, see Virtual migration environment (VME) guide for Project Server 2010.

Windows PowerShell

Windows PowerShell support is available in Project Server 2010 to make deploying and managing much easier. Windows PowerShell is a relatively new interactive command-line shell and scripting language for Windows. Windows PowerShell provides Information Technology (IT) administrators powerful task automation and scripting capabilities for managing Windows operating systems and applications. It was released in 2006 and is currently available for Windows XP SP2/SP3, Windows Server 2003, Windows Vista, and is included in Windows Server 2008 as an optional feature. Windows PowerShell is included in Windows 7.

SharePoint Server 2010 is the first version of SharePoint Server to integrate with Windows PowerShell as an administrative and management interface. IT administrators can use Windows PowerShell to create batch files (scripts) that automate routine tasks and solve complex problems. Scripts offer increased functionality and ensure consistency, especially when distributed to other administrators in the organization.

One of the prerequisites for installing SharePoint Server 2010 is that Windows PowerShell be installed either as a feature or part of the operating system. SharePoint cmdlets are written for Windows PowerShell 1.0 but should run in Windows PowerShell 2.0 by default. SharePoint Server does not create its own shell, rather it builds upon the functionality provided by Windows PowerShell. It does this by registering a SharePoint-specific snap-in and providers. This extended shell is referred to as the SharePoint Management Console (SMC).

Note:

For more information about Windows PowerShell, see Windows PowerShell for Project Server 2010. You can also find more information in the following guide: Running Windows PowerShell Scripts (http://go.microsoft.com/fwlink/p/?LinkId=189628).

See Also

Other Resources

Microsoft Project Server 2010 Product Overview (http://go.microsoft.com/fwlink/p/?LinkId=189568)
What's New in Microsoft SharePoint Server 2010 Resource Center (http://go.microsoft.com/fwlink/p/?LinkId=189569)
What's New for Developers in Project 2010 (http://go.microsoft.com/fwlink/p/?LinkId=189570)


Project Server 2010 with SharePoint Server 2010 architecture (overview)

Published: May 12, 2010

This article discusses planning considerations that a SharePoint farm administrator should make when planning to deploy Microsoft Project Server 2010. Project Server 2010 is built on Microsoft SharePoint Server 2010 architecture and has a big dependency on SharePoint Server 2010 features and services. This article describes the following considerations:

  • Microsoft EPM 2010 Overview

  • Project Server 2010 compatibility with SharePoint Server versions

  • Deployment

  • Upgrade from Project Server 2007

  • Installation considerations

  • Service Application requirements for Project Server 2010

  • Database considerations

  • Microsoft SQL Server Analysis Services (SSAS) considerations

  • Project Server 2010 language packs

  • Web browser considerations

Microsoft EPM 2010 Overview

The Microsoft Enterprise Project Management (EPM) 2010 Solution is a flexible, end-to-end Project Portfolio Management platform, used by organizations across many industries to automate primary PPM processes. The EPM Solution helps organizations achieve the following business imperatives:

  • Intuitively capture all requests in a central repository, and manage them using governance workflow: Demand Management

  • Objectively prioritize, optimize, and select project portfolios that best align with the organization's business strategy: Portfolio Selection and Analytics

  • Proactively and reactively manage resources throughout the project life cycle: Resource Management

  • Easily create and communicate both simple and complex project schedules:Schedule Management

  • Control and measure project and portfolio financial performance:Financial Management

  • Simplify the collection of time and task status updates from team members: Time and Task Management

  • Better connect different teams to share information and drive collaboration:Team Collaboration

  • Identify, reduce, and communicate issues and risks that could adversely affect project success:Issues and Risk Management

  • Effectively measure project performance and gain visibility and control across all portfolios:Business Intelligence and Reporting

  • Initiate, plan, and deliver strategic programs: Program Management

The Microsoft EPM Solution includes the following products from the Microsoft Project 2010 family, to provide a comprehensive computer- and Web-based PPM solution

  • Microsoft Project Server 2010: Project Server 2010 brings together the business collaboration platform services of SharePoint Server 2010 with structured execution capabilities to provide flexible work management solutions. Project Server 2010 unifies project and portfolio management to help organizations align resources and investments with business priorities, gain control across all kinds of work, and visualize performance using powerful dashboards. Project Server 2010 incorporates the best-in-class portfolio management techniques of Microsoft Office Project Portfolio Server 2007. This eliminates the need for Project Server Gateway (which was required to push data between Office Project Portfolio Server 2007 and Microsoft Office Project Server 2007), and providing a consistent SharePoint Server user interface across the solution.

  • Microsoft Project Professional 2010: Microsoft Project Professional 2010 delivers powerful, visually improved ways to simplify planning, collaboration, and resource management so managers can successfully tackle all kinds of projects. Connecting Project Professional 2010 with Project Server 2010 ensures that organizations can achieve the added business benefits of unified Project Portfolio Management.

Note:

For more information about new features in Project Server 2010, see What's new for IT pros in Project Server 2010.

Project Server 2010 is built on SharePoint Server 2010 to provide true multi-tier architecture by using the new Service Application model. The Project Server architecture includes Project Professional 2010 and Microsoft Project Web App clients in the front-end tier. The front-end applications communicate with the middle tier only through the Project Server Interface (PSI) Web Services, which in turn communicate with the business object layer. Business objects use the databases through the data access layer. Client applications do not directly access the primary databases; Project Server hides business objects and the DAL from clients. For more information about Project Server 2010 architecture, see Project Server 2010 architecture.

Project Server 2010 compatibility with SharePoint Server versions

SharePoint Server 2010 Enterprise version is an installation requirement for Project Server 2010. See the following table for Project Server /SharePoint Server compatibility.

 | Installation Requirement | Will coexist on the same farm with | Will not work with
Project Server 2010: | SharePoint Server 2010 Enterprise | SharePoint Server 2010 Enterprise | Office SharePoint Server 2007
Project Server 2007: | Windows SharePoint Services 3.0 | Office SharePoint Server 2007 | SharePoint Server 2010

For more information about Project Server 2010 requirements, see Hardware and software requirements (Project Server 2010).

Deployment

Similar to SharePoint Server, a Project Server farm deployment can vary in complexity and size, depending on your business requirements. As a three-tier application, Project Server 2010 supports all farm topologies (small, medium and large). Similar to Office Project Server 2007, Project Server 2010 can be deployed on physical servers or virtual servers (Hyper-V) depending on IT requirements. In addition, Project Server 2010 can be configured for extranet access if resources outside your organization have to collaborate on projects. Similar to SharePoint Server, Project Server 2010 supports Windows PowerShell. For more information, see Windows PowerShell for Project Server 2010. For more information about Project Server 2010 capacity planning, see Plan for performance and capacity (Project Server 2010).

Upgrade from Project Server 2007

Microsoft is aware that its customers have made significant investments in deploying Office Project Server 2007 across their organizations. Microsoft has invested in upgrade processes and strategies to ensure customers can smoothly migrate from Office Project Server 2007 to Project Server 2010. For more information about Project Server 2010 upgrade and migration, see the Upgrade and Migration Resource Center for Project Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=191607).

Installation considerations

Project Server 2010 installed to all servers in the farm: When you install Project Server 2010 to a farm, Project Server 2010 has to be installed to every application server and Web server in the farm. Therefore Project Server 2010 licenses are required for each server in the farm. When you apply updates to Project Server 2010, it is important to apply the same update to every application server and Web server in the farm to ensure that all servers in the farm are in a consistent state.

For more information about how to install Project Server 2010, see Deploy Project Server 2010 to a server farm environment.

For more information about licensing and pricing, see Microsoft Volume Licensing (http://go.microsoft.com/fwlink/p/?LinkID=155897).

Application server fault tolerance: Project Server 2010 application servers in a farm have fault tolerance through round-robin load balancing. A non-functioning server will be skipped and the request will be serviced by the remaining application servers in the farm. This feature may negate the need for applying a hardware-based fault tolerance solution.

Cross-farm services not supported: Sharing services across farms (cross-farm services) is not supported with Project Server 2010. Therefore careful planning must be done if Project Server 2010 is installed in a separate farm from the main content management farm. Additionally, Project Server 2010 does not have a mechanism to synchronize data between multiple instances of Project Web App.

Service Application requirements for Project Server 2010

In Project Server 2010/SharePoint Server 2010, services are no longer contained in a Shared Services Provider (SSP) like they were in Office Project Server 2007/Office SharePoint Server 2007. You can deploy only the services that are needed to a farm (known as service applications). Web applications can then be configured to use only the services that are needed, instead of the complete set of services that are deployed.

Note:

For more information about the SharePoint Server 2010 services architecture, see Logical architecture components (SharePoint Server 2010). Also see the Service in SharePoint 2010 Products Technical Diagram (in Microsoft Visio).

The following five services must be enabled to operate a Project Server 2010 server farm:

  • Project Service Application (used to host Project Web App instances)

  • Excel Services (used for Reporting)

  • PerformancePoint Service (used for Reporting

  • Secure Store Service (used for Reporting)

  • State Service (used for Charting)

Note:

For performance considerations, it is a best practice to only enable the services necessary to fulfill requirements.

Database considerations

Installing and configuring Project Server 2010 creates the following databases:

  • Draft database: Contains tables for saving unpublished projects from Microsoft Project Professional 2010. Project data in the Draft database cannot be accessed by using Microsoft Project Web App.

  • Published database: Contains all of the published projects. Published projects are visible in Project Web App. The Published database also contains tables that are specific to Project Web App (timesheets, models, views, and so on), and global data tables (outline codes, security, and metadata).

  • Archive database: Saves backed-up and older versions of projects.

  • Reporting database: Serves as the staging area for generating reports and online analytical processing (OLAP) cubes. Data in the Reporting database is updated almost in real-time, is comprehensive, and is optimized for read-only report generation. For more information, see Plan reporting and business intelligence (Project Server 2010).

  • Content database: We recommend a dedicated content database to store the Project Web App content and all project workspace data (such as Issues/Risks/Deliverables and project documents).

For more information about Project Server 2010 databases, see Plan the database tier (Project Server 2010).

Additionally, if the State Service (required by Project Server 2010) is started for the first time on the application server, a database will be created for the server.

For more information about the installation process, see Deploy Project Server 2010 to a server farm environment.

Microsoft SQL Server Analysis Services (SSAS) considerations

Similar to Office Project Server 2007, Project Server 2010 uses SQL Server Analysis Services to generate online analytical processing (OLAP) cubes that are used to build reports on projects, timesheets, and resources.

In this version, Project Server is integrated with Excel Services in Microsoft SharePoint Server 2010 to make it easier to create custom reports. As part of this integration, blank data-connected worksheets and sample reports are provided. For more information about reporting, see the Business Intelligence in Project Server 2010 TechNet Resource Center (http://go.microsoft.com/fwlink/p/?LinkId=191609).

Using reports in Project Server 2010 requires you to install SQL Server 2008 Analysis Management Objects (AMO) to each application server in your farm.

Note:

Use the Microsoft SQL Server 2008 version of AMO regardless of which version of SQL Server you are using to host your databases.

Additionally, after you install the AMO objects, you have to restart the Project Application Service on each application server in the farm where it is running. This service is configured in the SharePoint Central Administration Web site on the System Settings page in the Manage services on server page.

For more information about SQL Server Analysis Services requirements for Project Server 2010, see Configure reporting for Project Server 2010.

Project Server 2010 language packs

Project Server 2010 language packs enable your Project Web App users to view the site in multiple languages. SharePoint Server 2010 also has language packs, although their purpose differs from that of Project Server 2010 language packs because they enable you to create sites in different languages. Note the following about Project Server 2010 language packs:

  • When you install a Project Server 2010 language pack, the installation files for the language pack should be installed to all application and Web servers in the farm before you run the SharePoint Products Configuration Wizard.

  • If you are installing multiple language packs, the installation files for all language packs should be installed to all application and Web servers in the farm before you run the SharePoint Products Configuration Wizard.

  • Project Server 2010 language packs are available for the following languages:

    • Arabic

    • Chinese (SC)

    • Chinese (TC)

    • Czech

    • Danish

    • Dutch

    • English

    • Finnish

    • French

    • German

    • Greek

    • Hebrew

    • Hungarian

    • Italian

    • Japanese

    • Korean

    • Norwegian (Bokmal)

    • Polish

    • Portuguese (Brazilian)

    • Russian

    • Slovak

    • Slovenian

    • Spanish

    • Swedish

    • Turkish

    • Ukrainian

  • Project Server 2010 does not support all the languages that SharePoint Server 2010 supports. The following languages are supported by SharePoint Server 2010, but are not available in Project Server 2010 language packs.

    • Basque

    • Bulgarian

    • Catalan

    • Croatian

    • Estonian

    • Galician

    • Hindi

    • Kazakh

    • Latvian

    • Lithuanian

    • Romanian

    • Serbian (Latin)

    • Thai

Important:

Prior to the Project Server 2010 Cumulative Update (June 2010), installing a SharePoint Server 2010 language pack in a language not supported in Project Server 2010 would potentially cause issues if you then had to upgrade Microsoft Office Project Server 2007 data to the Project Server 2010 farm. If you are using Project Server 2010 and will be loading SharePoint Server 2010 language packs that are not available for Project Server 2010, you should consider the June 2010 Cumulative Update to be the minimum release level that you should be at. For more information about the Project Server 2010 Cumulative Update for June 2010, see Description of the Project Server 2010 hotfix package (Pjsrvwfe-x-none.msp): June 29, 2010.

For more information about Project Server 2010 language packs, see Deploy language packs (Project Server 2010).

For more information about SharePoint Server 2010 language packs, see Deploy language packs (SharePoint Server 2010).

Web browser considerations

Project Server 2010 access through Project Web App requires Internet Explorer 7, Internet Explorer 8, or Internet Explorer 9 as your Web browser. It is important to note because SharePoint Server 2010 supports not only these Web browsers, but also Web browsers that are not supported for Project Web App (and in some cases, explicitly blocked). It can also be an issue if your organization is currently using applications that are explicitly used for Internet Explorer 6. For more information about workarounds and other planning topics, see Plan browser support (Project Server 2010).

Note:

The Service Pack 1 update for Project Server 2010 provides support for specific versions of additional browsers (Firefox, Google Chrome, and Apple Safari) to access Project Web App pages that are frequently used by team members. These browser versions are listed here:

  • Firefox 3.6.8+ on Mac OS X v10.6, Windows 7 (32-bit/64-bit), Windows Vista SP2, Windows XP SP3, Windows Server 2003 and UNIX/Linux

  • Google Chrome 6.0 on Windows 7

  • Apple Safari 5 on Mac OS X v10.6

Following are the team member pages that are supported with these additional browsers:

  • Project Web App (PWA) main default page (default.aspx)

  • All pages in the "My Work" section in the Quick Launch. This includes the following:

    • Tasks

    • Timesheets

    • Issues and Risks

For more information about the Project Server 2010 Service Pack 1 update, see Deploy Service Pack 1 for Project Server 2010.

For more information about Web browsers supported for use with SharePoint Server 2010, see Plan browser support (SharePoint Server 2010).


Project 2010 Ignite on-demand training videos

Published: May 29, 2010

The Microsoft Project 2010 Ignite Recordings let you view eight-and-a-half hours of presentations and product demonstrations from the Project 2010 Ignite Training Series. Each module is delivered by using a Microsoft Silverlight player, which enables you to view the presenter and the slides at the same time. It also gives you a chapter outline and a full transcript of the presentation.

The Project 2010 Ignite Training Series focuses primarily on new features and functionality with Microsoft Project Server 2010 and Project 2010 with regard to Office Project 2007. It was delivered to 900 attendees in 9 different cities just before product release. The recordings are delivered by these people:

  • Christophe Fiessinger: Senior Technical Product Manager, Microsoft Corporation

  • Jan Kalis: Senior Technical Product Manager, Microsoft Corporation

The Microsoft Project 2010 Ignite Recordings are divided into the following modules with their corresponding run times. Click the module name to download the module. You can also see a complete list of the Microsoft Project 2010 Ignite Recording modules for download on the Microsoft Project 2010 "Ignite" (a.k.a. "Quick Start 2010 Training") Download Center page.

Note:

You may be prompted to install the Microsoft Silverlight Plug-in for Microsoft Internet Explorer in order to view the videos if it is not already installed on your computer. Note that Microsoft Silverlight cannot be used in Microsoft Internet Explorer browsers running in 64-bit mode.

Module | Description | Presentation run-time | Demo run-time
Introduction (http://go.microsoft.com/fwlink/p/?LinkId=193941) | In this introductory module we discuss the Project 2010 Ignite training delivered worldwide between September 2009 and March 2010; introduce the four key investments of Microsoft Project 2010 (Unified Project and Portfolio Management, Simple and Intuitive User Experience, Enhanced Collaboration and Reporting, Scalable and Connected Platform), and conclude with a summary of key Microsoft Project resources that will help you deploy this new release. | 12:51 | 00:00
Planning, Design, and Deployment (http://go.microsoft.com/fwlink/p/?LinkId=193942) | In this module we introduce Project Server 2010 architectural changes and typical farm topologies. We discuss scenarios and best practices to deploy in a SharePoint farm, and we present hardware and software requirements and deployment procedures. | 40:01 | 05:14
Upgrade and Migration (http://go.microsoft.com/fwlink/p/?LinkId=193943) | We have significantly improved the upgrade process to Project 2010. It's now easier and more reliable. Upgrading from Office Project 2007 is as easy as backing up the databases and attaching them to the newly installed instance of Project Server 2010. Being well prepared is a key requirement. This session discusses the process and outlines key resources and tools. | 30:31 | 11:04
Demand Management (http://go.microsoft.com/fwlink/p/?LinkId=193944) | The Demand Management module introduces the new capability of Project Server 2010 around Demand Management, also known as Project Lifecycle Management. We discuss the key components that enable the Demand Management functionality: Enterprise Project Types, Project workflows (Stages and Phases), Project Detail Pages, Approvals, and steps to implement your own governance process. | 35:22 | 24:29
Portfolio Strategy (http://go.microsoft.com/fwlink/p/?LinkId=193945) | Nearly every organization has to justify its investments and make sure its decisions are aligned with strategic goals. Project Server 2010 offers integrated tools for rich Demand Management and first class portfolio selection functionality that assists executives in their decisions. In this module we cover the process of setting up Business Drivers, aligning projects to Business Drivers, Project Prioritization, and the selection process. We also point to other resources relevant to portfolio strategy. | 34:30 | 25:55
Timesheet and Statusing (http://go.microsoft.com/fwlink/p/?LinkId=193946) | In this module we discuss some new features that enable customers to provide task status and do time entry. We present the new user experience, the new single-entry mode to unify timesheet entry and task statusing. We also discuss reporting improvements for timesheet and statusing and the ability to integrate Project Server with Microsoft Exchange Server. | 30:02 | 19:39
Reporting Part I (http://go.microsoft.com/fwlink/p/?LinkId=193947) | Every organization from small to large requires insight into business data, including project and portfolio information. Project Server 2010, benefiting from the rich Business Intelligence platform of SharePoint Server 2010, offers powerful dashboarding capabilities. This module discusses reporting capabilities and infrastructure improvements. | 27:25 | 26:21
Reporting Part II (http://go.microsoft.com/fwlink/p/?LinkId=193948) | This module shows other powerful services available with every deployment of Project Server 2010, Visio Services, and PerformancePoint Services. | 09:50 | 29:58
Administration (http://go.microsoft.com/fwlink/p/?LinkId=193949) | The Administration module discusses key improvements that will make the life of project managers, and administrators easier and more flexible. Specifically we present Departments, Delegation, Project Manager Provisioned Permissions, Active Directory Synchronization and Bulk Update Project Sites. | 26:12 | 14:21
Operations (http://go.microsoft.com/fwlink/p/?LinkID=193950) | This module discusses key investments that all administrators can benefit from because Project Server 2010 is built on SharePoint Server 2010. This module provides deep operational insights into farm performance, health and usage, and the rich set of tools to increase administrator productivity. Topics discussed include Unified Logging Service (ULS), Usage Logging, Health Reports, SharePoint Health Analyzer, Developer Dashboard, Password Management, Windows PowerShell. | 22:51 | 20:27
Development/Extensibility (http://go.microsoft.com/fwlink/p/?LinkId=193952) | Each organization has different business processes and requirements. Project 2010 is built with extensibility and rich customization options in mind. Because Project Server 2010 is built on the SharePoint Server 2010 platform, you can build processes that seamlessly integrate collaboration, document management, reporting, project management, line of the business integration and much more. Both Project 2010 and Project Server 2010 may be extended by using Object Model API to extent the core functionality. This session does not go very deep into the code, but helps you get started at the right point. | 21:59 | 06:12
Conclusion (http://go.microsoft.com/fwlink/p/?LinkId=193954) | In this module we answer frequently asked questions (FAQ) on each of the four key improvements of Project 2010 (Unified Project and Portfolio Management, Simple and Intuitive User Experience, Enhanced Collaboration and Reporting, Scalable and Connected Platform). We also answer frequently asked questions for IT Professionals and Developers based on feedback we heard while delivering the Project 2010 Ignite training sessions worldwide. We conclude with a very thorough Project 2010 resource slide. | 35:31 | 00:00


Project Server 2010 IT-Professional TechNet Webcasts
See Also

Published: May 12, 2010

The Microsoft Project Server 2010 IT-Professional TechNet Webcast series is composed of seven downloadable Webcasts that are meant to provide Project Server 2010 deployment guidance and best practices for IT professionals. You can also download the Microsoft PowerPoint slide presentations for the Webcasts from the Project Server 2010 IT-Professional Webcast Series slide presentations page on the Microsoft Download Center.

You can view these Webcasts by clicking the following links to the Microsoft Events and Webcasts site:

  • TechNet Webcast: Project Server 2010 - Performance Part 1: Setup, Execution, and Results This Microsoft TechNet Webcast discusses Project Server 2010 performance characteristics and farm architecture planning. It shares the results of Project Server 2010 performance lab tests conducted on targeted reference hardware architecture in the Microsoft Technology Center (MTC) by Microsoft Consulting Services (MCS) in partnership with the Microsoft Product Group. The test results were used to discover performance bottlenecks and determine better design and implementation practices for Project Server 2010 infrastructures. This Webcast shows you how the testing lab was set up, how the tests were executed, and which test tools were used.

  • TechNet Webcast: Project Server 2010 - Performance Part 2: Architecture, Sizing, and Capacity This Microsoft TechNet Webcast also discusses Project Server 2010 performance characteristics and farm architecture planning. It shares the results of Project Server 2010 performance lab tests conducted on targeted reference hardware architecture in the Microsoft Technology Center (MTC) by Microsoft Consulting Services (MCS) in partnership with the Microsoft Product Group. The test results were used to discover performance bottlenecks and determine better design and implementation practices for Project Server 2010 infrastructures. This Webcast shows you the test results, architecture, data flow, and sizing guidelines and best practices for your Project Server 2010 implementation.

  • TechNet Webcast: Project Server 2010 Upgrade and Migration This Microsoft TechNet Webcast discusses Project Server 2010 features, requirements, and deployment considerations that IT professionals have to know about. Topics discussed include upgrade options from both Microsoft Office Project Server 2003 and Microsoft Office Project Server 2007 to Microsoft Project Server 2010. Topics also include tools, processes, scenarios, best practices for upgrade and migration, the effect on Project Server of coexisting with SharePoint 2010 Products, and full-farm versus split-farm upgrades.

  • TechNet Webcast: Project Server 2010 - Backwards Compatibility Mode This Microsoft TechNet Webcast discusses the Microsoft Project Server 2010 Backwards Compatibility Mode (BCM) feature, which helps you speed up deployment of Microsoft Project 2010. With BCM, various desktop and server versions of Microsoft Project can seamlessly coexist and exchange data. BCM exists on Project 2010 desktop applications and Microsoft Project Server 2010, and in certain scenarios BCM makes it possible for Microsoft Office Project Professional 2007 to access Project Server 2010.

  • TechNet Webcast: Project Server 2010 - Coexisting with SharePoint Server 2010 This Microsoft TechNet Webcast discusses Microsoft Project Server 2010 coexistence with Microsoft SharePoint Server 2010. SharePoint Server 2010 is required for running Project Server 2010. It discusses two scenarios: (1) Deploying a new EPM-focused farm, and (2) Deploying Project Server 2010 into an existing SharePoint Server 2010 farm.

  • TechNet Webcast: Project Server 2010 - Backup and Restore This Microsoft TechNet Webcast explains the process for performing backup and recovery in Project Server 2010. The supported scenarios covered include mirroring (with and without witness), restoring over an existing farm, and restoring into a new farm. For farm-level, instance-level (there are five database-attach scenarios), and site-level collections, this Webcast demonstrates tools available at the command-line, in the SharePoint Central Administration Web site, in Windows PowerShell, and in Microsoft SQL Server. It also discusses Playbooks, the metadata backup and restore tool in Project Server 2010.

  • TechNet Webcast: Project Server 2010 - Operations This Microsoft TechNet Webcast discusses managing and maintaining a Project Server 2010 implementation. It also demonstrates Project Server 2010 diagnostics and monitoring, provides troubleshooting tips, and shares health check best practices.

See Also

Concepts

Project 2010 MVP Webcast Series
Project Server 2010 Demand Management Webcast series
Project 2010 Ignite on-demand training videos


TechNet Webcast: Overview of Microsoft Project Server 2010 for IT professionals

Published: May 12, 2010

This Microsoft TechNet Webcast discusses Microsoft Project Server 2010 features, requirements, and deployment considerations that IT professionals need to know about the product. Topics discussed include system requirements, deployment scenarios, installation procedures, upgrade options, and administration and operations improvements that help IT professionals.

The presenter is Christophe Fiessinger, Senior Technical Product Manager, Microsoft Corporation

TechNet Webcast: Overview of Microsoft Project Server 2010 for IT Professionals (Level 200) (http://go.microsoft.com/fwlink/p/?LinkId=188099)


TechNet Webcast: Managing the project life cycle with demand management

Published: May 12, 2010

This Microsoft TechNet Webcast discusses demand management, a new feature in Microsoft Project Server 2010 that captures work proposals in one place and takes them through a multi-stage governance process using a Microsoft SharePoint Server 2010 workflow model. This presentation provides an overview of demand management and its importance in managing project life cycles, and we explain how to configure demand management and the required components.

The presenter in this Webcast is Rolly Perreaux, Senior EPM Consultant / Instructor, PMO Logistics Inc.

TechNet Webcast: Managing the Project Life Cycle with Demand Management (http://go.microsoft.com/fwlink/p/?LinkId=190241)

Note:

This Webcast is one of seven available in a Series. For a complete list of all available Webcasts from this series, see Project Server 2010 IT-Professional TechNet Webcasts.


TechNet Webcast: Project Server 2010 -- Coexisting with SharePoint Server 2010

Published: May 12, 2010

This Microsoft TechNet Webcast discusses Microsoft Project Server 2010 coexistence with Microsoft SharePoint Server 2010. SharePoint Server 2010 is required for running Project Server 2010. This Webcast discusses the following two scenarios:

  1. Deploying a new Enterprise Project Management (EPM)-focused farm with Project Server 2010 and SharePoint Server 2010

  2. Deploying Project Server 2010 into an existing SharePoint Server 2010 farm. In this scenario, the original capacity planning and design assumptions should be reviewed to determine whether changes to the existing SharePoint Server 2010 farm architecture are needed before adding Project Server 2010 to the farm.

The presenter in this Webcast is Jean-Francois Lesaux (EPM Senior Consultant, Microsoft Corporation).

TechNet Webcast: Project Server 2010 - Coexisting with SharePoint Server 2010

Note:

This Webcast is one of seven in a series. For a complete list of all available Webcasts from this series, see Project Server 2010 IT-Professional TechNet Webcasts.


Project 2010 MVP Webcast Series
See Also

Published: May 29, 2010

The Microsoft Project 2010 MVP TechNet Webcast Series is composed of downloadable Webcasts that provide guidance and best practices to end users, IT professionals, and developers. You can also download and view the corresponding Microsoft PowerPoint slide presentations for each Webcast by downloading them from Project the 2010 MVP Webcast Series slide presentations page (http://go.microsoft.com/fwlink/p/?LinkId=193407) in the Microsoft Download Center.

You can view these Webcasts by clicking the following links to the Microsoft Events and Webcasts site:

  • TechNet Webcast: Managing the Project Life Cycle with Demand Management (Level 200)(http://go.microsoft.com/fwlink/p/?LinkID=190241): Demand Management, a new feature in Microsoft Project Server 2010, captures work proposals in one place and takes them through a multi-stage governance process using a SharePoint workflow model. In this presentation, we discuss Demand Management and its importance in managing project life cycles, and we explain how to configure Demand Management and the required components.

  • TechNet Webcast: Microsoft Project 2010 Portfolio Analysis (Level 200)(http://go.microsoft.com/fwlink/p/?LinkId=242594): In this webcast, we discuss the purpose of portfolio management, detail the portfolio management process according to Project Management Institute (PMI) standards, and explain the benefits of portfolio management and the challenges for the senior management. We describe portfolio management-related concepts and techniques, such as pair-wise comparison, prioritization matrix, and efficient frontier, and understand the benefits of these techniques in project prioritization, portfolio balancing, and optimization. Using Microsoft Project 2010 and applying the portfolio management techniques, we demonstrate typical portfolio management process scenarios.

  • TechNet Webcast: Resource Management in Microsoft Project 2010 (Level 200)(http://go.microsoft.com/fwlink/p/?LinkId=242595): In this webcast, we examine resource management from the perspective of the new and improved features in Project 2010. Topics we discuss include Team Planner, use of Status Indicator for overallocation, Team Builder, Issue Log, and Status using Task Updates. Join us to learn more.

  • TechNet Webcast: Project Server 2010 and SharePoint Server 2010: Focus on Collaboration(http://go.microsoft.com/fwlink/p/?LinkId=242598): In this webcast, we introduce the integration of collaboration strategies and features of Microsoft Project Server 2010 for participants in a project management office (PMO)/project portfolio management (PPM) environment. Join us to learn what Microsoft SharePoint Server 2010 has to offer with features such as Project Sites and Workspaces, version control, task synchronization between Project Server 2010 and SharePoint Server 2010, governance workflows, tagging, wikis, discussion boards, integration of connectivity with remote team members via the web and mobile devices, and business intelligence for dynamic reporting.

  • TechNet Webcast: Project Server 2010 and SharePoint Server 2010: Focus on Project Management (Level 200)(http://go.microsoft.com/fwlink/p/?LinkId=242599): In this webcast, we introduce project management methodologies for people who are familiar with collaboration platforms. Discover how Microsoft Project Server 2010 and Microsoft SharePoint Server 2010 are better together. Topics we cover include risk management, issue management, resource constraint management, project alignment with strategic business objectives, demand management, cost analysis, and business intelligence for dashboards and status reporting.

  • TechNet Webcast: User-Controlled Scheduling in Microsoft Project 2010 (Level 200)(http://go.microsoft.com/fwlink/p/?LinkId=242602): There are situations when user-controlled scheduling offers an advantage, and sometimes you should turn off user-controlled scheduling. In this webcast, we demonstrate user-controlled scheduling in Project 2010 to show the benefits and drawbacks of user-controlled scheduling.

See Also

Concepts

Project Server 2010 IT-Professional TechNet Webcasts
Project 2010 Ignite on-demand training videos
Project Server 2010 Demand Management Webcast series


Project Server 2010 Demand Management Webcast series
See Also

Published: May 29, 2010

The Microsoft Project Server 2010 Demand Management Webcast Series is composed of four on-demand webcasts targeted at end users. These webcasts introduce the concepts of Demand Management by doing the following:

  • Explaining the framework for the project/program phases of Create, Select, Plan, Manage, and Close

  • Explaining how to integrate information paths and strategic objectives

  • Providing use-case examples that showcase the enterprise-wide benefits of the Demand Management feature in Project Server 2010

Note:

For additional information about Demand Management, see the white paper Microsoft Project Server 2010 - A look at Demand Management, A whitepaper for stakeholders in a program ecosystem (http://go.microsoft.com/fwlink/p/?LinkId=191854).

The Project Server 2010 Demand Management Webcast Series includes the following four on-demand video presentations:

  • TechNet Webcast: Project Server 2010 Demand Management (Part 1 of 4): Overview (Level 200) This Webcast highlights the new Demand Management feature in Project Server 2010. The topics covered in this Webcast include how Demand Management in Project Server 2010 does the following things:

    • Offers positive business impacts for multiple departments

    • Enhances strategic visibility into portfolios, programs, and projects across the enterprise

    • Benefits governance control processes by allowing for multiple lifecycle styles, creation of a central repository for project/program documents and data, and more streamlined capabilities for collecting project data

  • Project Server 2010 Demand Management (Part 2 of 4): Create and Select Phases This Webcast outlines the framework for the project/program phases of "Create" and "Select". It explains how to integrate information paths and strategic objectives within the Demand Management feature in Project Server 2010. The topics covered in this Webcast include:

    • Costs

    • Corporate benefit and strategic impact

    • Organizational approach

    • Utilization of necessary resources

    • Risk assessment

    • Defining conditions leading to project/program selection by outlining the business drivers

    • Strategic priorities

    • Scenarios

    • Risk assessment

    • Impact standards

    • Assumption/constraint analysis

  • Project Server 2010 Demand Management (Part 3 of 4): Plan, Manage, and Close Phases This Webcast outlines the framework for the project/program phases of Plan, Manage, and Close. It also explains how to integrate information paths and strategic objectives within the Demand Management feature in Project Server 2010. The topics covered in this Webcast include:

    • Defining project structure of phases

    • Identifying milestones and dependencies

    • Developing resource management policies

    • Monitoring actual values in comparison with planned values and forecasts

    • Integrated change control processes

    • Status reporting

    • Issue/risk management progress

    • Obtaining appropriate sign-offs

    • Completing and archiving of project documents forming organization assets

  • Project Server 2010 Demand Management (Part 4 of 4): Test the Theory and Review This Webcast provides use-case examples that showcase the enterprise-wide benefits of the Demand Management feature in Project Server 2010. It also covers best practices for integration, implementation, and execution of demand management.

Note:

You can download the Microsoft PowerPoint slide presentations used for each of the Webcasts in the Project Server 2010 Demand Management Webcast Series from the Microsoft Project Server 2010 Demand Management Webcast Series slide presentations page (http://go.microsoft.com/fwlink/?LinkId=193409) in the Microsoft Download Center.

See Also

Concepts

Project 2010 MVP Webcast Series
Project 2010 Ignite on-demand training videos
Project Server 2010 IT-Professional TechNet Webcasts


Project management comparison: Project Professional 2010 and Project Web App
See Also

Published: February 7, 2012

In Microsoft Project Server 2010, Microsoft Project Web App (PWA) has new functionality that previously had only been available in Project Professional. This table compares the Web-based project management capabilities of Project Web App in Project Server 2010 with those same capabilities in Project Professional 2010.

Project Web App (2010) Project Professional 2010

Multi-resource assignments: Assign more than one resource for a particular task.

Available

Available

Status change updates: Receive updates on status changes that reschedule the project plan.

Available

Available

Keyboard shortcuts: Use keyboard shortcuts for common operations such as indent/insert.

Available

Available

Task hierarchy: Display and render tasks with hierarchical information.

Available

Available

Indent/Outdent: Apply full indenting/outdenting of tasks in a project plan.

Available

Available

Change highlighting: Easily view project changes and all parts of the schedule affected by the change (successor tasks, summary costs, and so on) with change highlighting.

Available

Available

Multi-level undo: Perform what-if analysis and fully understand the effect of changes by reversing and reapplying a whole set of operations, including views, data, and option changes.

Available

Available

Cut/Copy/Paste: Collaborate on schedule development by copying/pasting schedule details between applications.

Available

Available

Flexible views: Move columns to define a specific view.

Available

Available

High fidelity Gantt charts: Create vivid, colorful Gantt charts; customizable Gantt chart styles.

Available

Available

Grouping: Apply multiple grouping rows to a project plan.

Available

Available

Sorting: Sort project plan data by end-users.

Available

Available

Filtering: Ability to filter project plans by any value in the plan.

Available

Available

Automatically scheduled tasks: Indicate tasks (mode) to be scheduled automatically by using the Project scheduling engine.

Available

Available

Manually scheduled tasks: Indicate tasks (mode) to be scheduled manually.

Available

Available

Linking: Create, edit, and delete task dependency relationships.

Available

Available

Zoom in/zoom out: Use zoom controls on the status bar to quickly change the timeline perspective of your project schedules.

Available

Available

Scroll to task: Select a task and then move the task into view on the Gantt chart.

Available

Available

View and edit custom fields: View and edit project metadata by using custom fields.

Available

Available

Project Information: Edit project-level fields and properties.

Available

Available

Edit large projects: No limit to the size of plans that are editable.

Note:

Larger projects may have performance limitations, but no limits are built in.

Available

Available

Import from SharePoint task list: Import data from a SharePoint project task list into a project plan.

Available

Available

Connect to Project Server 2010: Connect to Project Server 2010.

Available

Available

Microsoft Office Fluent™ User Interface: Increase productivity with the ribbon, a tab interface to quickly find and use Project features and controls.

Available

Available

Real-time validation: Mark cell data as invalid while you edit, instead of after you save and validate.

Available

Available

Error handling: Handle invalid data and present data in an easy-to-use interface that helps resolve issues.

Available

Available

Fill down: Drag the bottom-right corner of a cell to repeat data in the cells below.

Available

Available

Percent complete: Mark task progress as a percentage of the assigned work that is completed.

Available

Available

Cost and material resource assignments: Assign Cost Resources or Material Resources to tasks

Note:

Assignments cannot be made through PWA, but previous assignments from Project Professional 2010 are available as Read-Only.

Limited or Read-Only

Available

Inactive tasks: Mark a task as inactive.

Note:

In PWA, tasks marked as inactive in Project Professional 2010 are Read-Only.

Limited or Read-Only

Available

Edit master projects: Edit master projects.

Note:

In PWA, master projects are Read-Only.

Limited or Read-Only

Available

Cross-project links: Create, edit, and delete a dependency relationship with a task in another project.

Note:

In PWA, editing cross-project links is not supported; cross-project links created in Project Professional 2010 are Read-Only.

Limited or Read-Only

Available

Summary task assignment: Create a resource assignment on a summary task.

Note:

In PWA, creating summary task assignments is not supported. Summary task assignments created in Project Professional 2010 are Read-Only in PWA.

Limited or Read-Only

Available

Task calendars: Define a custom calendar associated with a task.

Note:

In PWA, task calendars cannot be used, and project plans created in Project Professional 2010 that contain task calendars are available as Read-Only.

Limited or Read-Only

Available

SharePoint 2010 Project Task Lists: Accept status updates for SharePoint 2010 project task lists.

Note:

In Project Professional 2010, project task list status updates are synchronized/bi-directional with SharePoint Server 2010 after the plan is published. In PWA, project task list status updates are one-way and only occur from the SharePoint project task list to PWA.

Limited or Read-Only

Available

Edit sub-projects: Edit sub-projects inside a master project.

Note:

In PWA, sub-projects cannot be added to a project, and master projects are Read-Only. Sub-projects can be edited separately from a master project.

Limited or Read-Only

Available

Task deadlines: Create deadlines for a task

Note:

In PWA, deadlines are displayed but cannot be created.

Limited or Read-Only

Available

Edit task type: Edit a task type.

Note:

In PWA, task type is not an editable field.

Limited or Read-Only

Available

WBS codes: Define custom Work Breakdown Structure codes.

Note:

In PWA, viewing custom codes is supported, but changing the code definition is not.

Limited or Read-Only

Available

Create baselines: Create a snapshot baseline of the current project plan.

Note:

Baselines created in Project Professional 2010 can be viewed in PWA as Read-Only.

Limited or Read-Only

Available

Time-phased editing: Edit plans and work on a day-by-day basis.

Note:

Time-phased data in manually scheduled tasks can be viewed in PWA as Read-Only.

Limited or Read-Only

Note:

Project Server 2010 Service Pack 1 allows you to edit time-phased values for manually scheduled tasks in PWA.

Available

Fixed work tasks: Define the type of a task as fixed work.

Note:

In PWA, tasks cannot be created as fixed work, and project plans created in Project Professional 2010 that contain fixed work tasks are Read-Only in PWA.

Limited or Read-Only

Note:

Project Server 2010 Service Pack 1 allows you to edit a project plan with fixed work tasks in PWA.

Available

Effort-driven tasks: Edit projects that contain effort-driven tasks.

Note:

In PWA, you cannot edit the effort-driven field. However, a task whose effort-driven field was set in Project Professional will calculate correctly when edited in PWA.

Limited or Read-Only

Note:

Project Server 2010 Service Pack 1 allows you to edit effort-driven tasks in PWA.

Available

Timeline: Build and customize the timeline view to visualize schedule details and communicate with stakeholders.

Available

Team planner: Drag and drop resources in an interactive resource view to simplify complex resource scenarios.

Available

Resource leveling: Recognize and correct resource over-allocation scenarios by using various automatic resource-leveling techniques.

Available

Edit assignment fields: Edit assignment views.

Available

Paste with task hierarchy: Paste hierarchical information that is included, such as indentations.

Available

Network diagram view: View, edit, create, and delete tasks in a network diagramming view.

Available

Task Form View: View, edit, create, and delete tasks in a form view.

Available

Task Information dialog box: See task details by using a dialog interface.

Available

Blank (null) Tasks: Create blank rows (blank, or null, tasks) in a project plan.

Available

Automatic calculation: Schedule the whole project plan, instead of only the current task, without pressing Calculate or F9.

Available

Text formatting: Modify text formatting by using colors and styles.

Available

Edit calendars: Edit calendars for your projects.

Available

Define local custom fields: Define local custom fields by users.

Note:

In PWA, only users who have administrator permissions can define local custom fields.

Available

Split tasks: Split tasks and show them as split in the Gantt chart.

Available

Backstage view: Quickly access Project tools, templates, and program options by using the new Microsoft Office Backstage view.

Available

Assignment units: Change the percentage units for each resource.

Available

Task Inspector: Get analysis and intuitive guidance to resolve scheduling conflicts, which you can choose whether to act upon.

Available

Offline editing: Edit project plans when you are not connected to Project Server 2010.

Available

For information about PWA functionality improvements in Project Server 2010 Service Pack 1, see the Microsoft Project 2010 blog post, Announcing Service Pack 1 for Microsoft Project and Project Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=241595).

For information about how to apply Project Server 2010 Service Pack 1, see Deploy Service Pack 1 for Project Server 2010.

See Also

Concepts

Use Project Web App (Project Server 2010)


"From the Trenches" white papers

Updated: April 30, 2013

The "From the Trenches" column on the Project Server 2010 TechCenter and the Project Server 2013 TechCenter contains white papers that can be used to help in planning for your Enterprise Project Management (EPM) deployment. The papers are written by Chris Vandersluis, founder of HMS Software and a Microsoft Certified Gold Partner, or Project MVP Bill Raymond of Pcubed.com.

The articles currently available are:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

Change History

Date | Description
April 30, 2013 | Added a new article to the list.
January 13, 2011 | Initial publication


Cancelling a project without cancelling your career: white paper (Project Server 2010)

Published: April 30, 2013

This white paper describes best practices for recognizing when a project should be stopped, the benefits of doing so, and considerations you need to take into account when cancelling the project.

This white paper is written by Chris Vandersluis of HMS Software.

To download this white paper, click Cancelling a project (without cancelling your career): white paper (Project Server 2010) (http://go.microsoft.com/fwlink/p/?LinkId=298960) (file size: approximately 29 KB).

The following "From the Trenches" white papers are also available for download:

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

The "From the Trenches" column is located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


Charging Ahead on Charge Codes: white paper (Project Server 2010)

Published: January 15, 2013

This white paper describes best practices for defining your organization's charge code structure for the project management system or timesheet system.

This white paper is written by Chris Vandersluis of HMS Software.

To download this white paper, click Charging Ahead on Charge Codes: white paper (Project Server 2010) (http://go.microsoft.com/fwlink/p/?LinkId=276786) (file size: approximately 25 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

The "From the Trenches" column is located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


Would you like some EPM with that?: white paper (Project Server 2010)

Published: September 18, 2012

This white paper discusses the evolution of project management systems, describes the use of Enterprise Project Management, and discusses the importance of understanding which project management solution is best for you.

This white paper is written by Chris Vandersluis of HMS Software.

To download this white paper, click Would you like some EPM with that?: white paper (Project Server 2010) (http://go.microsoft.com/fwlink/p/?LinkId=263938) (file size: approximately 32 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

The "From the Trenches" column is located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


Aligning projects with strategic drivers: white paper (Project Server 2010)

Published: September 11, 2012

This white paper discusses using strategic drivers in Portfolio Management to effectively create a standard approach for making important project decisions.

This white paper is written by Project MVP Bill Raymond of Pcubed.com.

To download this white paper, click Aligning Projects with Strategic Drivers (http://go.microsoft.com/fwlink/p/?LinkId=259663) (file size: approximately 510 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

The "From the Trenches" column is located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


Top-down or bottom-up: white paper (Project Server 2010)

Published: March 27, 2012

This white paper discusses project management, portfolio management, and task management, and it compares the top-down and bottom-up management practices related to them.

This white paper is written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click Top-down or bottom-up: white paper (Project Server 2010) (http://go.microsoft.com/fwlink/?LinkID=246608) (file size: approximately 694 KB).

The following white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


They say they want a resolution: white paper (Project Server 2010)

Published: December 13, 2011

This white paper describes some common challenges you may face when scheduling projects. It describes coming up with the best approach when you try to determine how long tasks should be and how many tasks there should be to optimize a project schedule. It discusses how different industries typically require different types of schedules (for example, software development, EPM (engineering, procurement, and construction), and plant shutdown). It also discusses several factors in choosing project resolution (for example, length of project, resources involved, management or division of resources, speed and effort required in collecting data, and data update schedule).

This white paper is written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click They say they want a resolution: white paper (Project Server 2010) (http://go.microsoft.com/fwlink/p/?LinkId=236030) (file size: approximately 148 KB).

The following white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


Dashboard directions: white paper (Project Server 2010)

Published: September 27, 2011

This white paper describes some of the common challenges you may face when deciding to use dashboards in your EPM environment. It describes how the prettiness of a professional-looking dashboard might sometimes hide the need for users to look into the quality of the data — "pedigree" and updated data, for example. It mentions how data for dashboards should go through an approval process to ensure high data quality and completeness. It includes a few techniques to prevent people from skewing data under their control to misrepresent the data that is displayed in the dashboard. And finally, it states some basic rules you should take into consideration when you create dashboards for EPM. This white paper is written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click Dashboard directions: white paper (Project Server 2010) (http://go.microsoft.com/fwlink/p/?LinkID=220320) (file size: approximately 511 KB).

The following white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


Enterprise system best practices: white paper (Project Server 2010)

Published: May 26, 2011

This latest white paper describes operational best practices for enterprise systems generally (including Microsoft Project Server). It notes how, although enterprise systems strive to provide an easy-to-use interface at the user level, the technology and infrastructure required to provide it is often very complex. This white paper then describes how this complexity requires you to use some basic best practices that give you the best chance of maintaining a high degree of reliability in your enterprise system. This white paper was written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click Enterprise Management Best Practices: white paper (http://go.microsoft.com/fwlink/p/?LinkID=218145) (file size: approximately 137 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


Creating an EPM Deployment Plan: white paper (Project Server 2010)

Published: April 14, 2011

This white paper describes how to create an Enterprise Project Management (EPM) deployment plan. It identifies phases and major points in an EPM Deployment plan, and it estimates times for each, based on a mid-sized organization with several hundred EPM system users. It also identifies factors that can affect the estimated duration times for each phase. This white paper was written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click Creating an EPM Deployment Plan: white paper (http://go.microsoft.com/fwlink/p/?LinkId=215445) (file size: approximately 113 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


EPM: Centralized or decentralized?: white paper (Project Server 2010)

Published: January 13, 2011

This white paper describes how organizations need to understand the problems they are trying to solve when deciding on implementing a project management system. Sometimes deploying a centralized project management system may not be the best answer. This white paper was written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click EPM-Centralized or Decentalized?: white paper (http://go.microsoft.com/fwlink/p/?LinkId=207890) (file size: approximately 223 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


The Bat phone: white paper (Project Server 2010)

Published: January 13, 2011

The title of this white paper refers to Commissioner Gordon's liberal use of the Bat Phone whenever the City of Gotham was in dire straits (from the 1970s "Batman" TV series). Author Chris Vandersluis relates that fictional story to how, during an EPM implementation, we at some time might wish we had access to a Bat Phone when we are in trouble. Vandersluis then discusses many ways to avoid getting into trouble during the implementation. Chris Vandersluis is the president and founder of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click The Bat Phone: white paper (http://go.microsoft.com/fwlink/p/?LinkId=198411) (file size: approximately 223 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


The executive connection: white paper (Project Server 2010)

Published: January 13, 2011

This white paper describes the importance of having executive involvement for a successful Enterprise Project Management (EPM) deployment. It describes reasons why a company might choose to not involve an executive in the deployment, how executives should be involved in the deployment, and tips on how to effectively involve an executive in the deployment. This white paper was written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click The Executive Connection: white paper (http://go.microsoft.com/fwlink/p/?LinkId=188300) (file size: approximately 223 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


Balancing the matrix: white paper (Project Server 2010)

Published: January 13, 2011

This white paper describes the challenges facing someone who implements Enterprise Project Management (EPM) in an organization that uses a matrix project management environment. This white paper is one in a series that is written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click Balancing the Matrix: white paper (http://go.microsoft.com/fwlink/p/?LinkId=188300).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


The project management system maturity model: white paper (Project Server 2010)

Published: January 13, 2011

This white paper describes how as organizations mature, they can be more effective in the use of their project management systems. It describes how it might be more effective for companies to elect to use only certain aspects of a new project management system to a level with which they are comfortable, even though they are tempted to use every feature that is available to them. As the company continues to mature, it can become more advanced in its use of the features that it needs to use. This white paper was written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click The Project Management System Maturity Model: white paper (http://go.microsoft.com/fwlink/?LinkId=157926) (file size: approximately 110 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


The challenges of selecting enterprise software: white paper (Project Server 2010)

Published: January 13, 2011

This white paper describes problems in the traditional "Request for Proposal" (RFP) method that companies use to select enterprise software. It also describes problems that can occur if the "Proof of Concept" or "Pilot" method is used improperly. Finally, it provides some suggestions for creating your own effective enterprise selection process. It was written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click The Challenges of Selecting Enterprise Software: white paper (http://go.microsoft.com/fwlink/p/?LinkId=208380) (file size: approximately 863 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


Resource management: white paper (Project Server 2010)

Published: January 13, 2011

This white paper describes challenges in different aspects of resource management and provides suggestions on creating a resource management system. It was written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click Resource Management: white paper (http://go.microsoft.com/fwlink/p/?LinkId=134077&clcid=0x409) (file size: approximately 916 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

Published: January 13, 2011

This white paper describes how to make an Enterprise Project Management deployment "roadmap" when you plan to implement EPM. It uniquely describes factors to consider when you plan your deployment path. It was written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click GPS Assistance in Roadmapping an EPM Deployment: white paper (http://go.microsoft.com/fwlink/p/?LinkId=128865&clcid=0x409) (file size: approximately 782 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


A phased approach to deploying enterprise project management: white paper (Project Server 2010)

Published: January 13, 2011

This white paper describes various challenges you can face when planning to deploy the Enterprise Project Management solution in your environment. It also describes several different deployment scenarios that can be used, as well as important prerequisites that need to be considered. It was written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click A Phased Approach to Deploying Enterprise Project Management: white paper (http://go.microsoft.com/fwlink/p/?LinkId=120877) (file size: approximately 256 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • Being a solutions buyer: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


Being a solutions buyer: white paper (Project Server 2010)

Published: January 13, 2011

This white paper describes how prospective software purchasers can make interactions with software vendors more effective by applying easily understood business analysis methods. It walks you through an exercise that can help create software evaluation criteria by effectively determining what problems need to be addressed by the software solution. This article was written by Chris Vandersluis of HMS Software, a Microsoft Gold Certified Partner.

To download this white paper, click Being a Solutions Buyer: white paper (http://go.microsoft.com/fwlink/p/?LinkId=120852) (file size: approximately 163 KB).

The following "From the Trenches" white papers are also available for download:

  • Cancelling a project without cancelling your career: white paper (Project Server 2010)

  • Charging Ahead on Charge Codes: white paper (Project Server 2010)

  • Would you like some EPM with that?: white paper (Project Server 2010)

  • Aligning projects with strategic drivers: white paper (Project Server 2010)

  • Top-down or bottom-up: white paper (Project Server 2010)

  • They say they want a resolution: white paper (Project Server 2010)

  • Dashboard directions: white paper (Project Server 2010)

  • Enterprise system best practices: white paper (Project Server 2010)

  • Creating an EPM Deployment Plan: white paper (Project Server 2010)

  • EPM: Centralized or decentralized?: white paper (Project Server 2010)

  • The Bat phone: white paper (Project Server 2010)

  • The executive connection: white paper (Project Server 2010)

  • Balancing the matrix: white paper (Project Server 2010)

  • The project management system maturity model: white paper (Project Server 2010)

  • The challenges of selecting enterprise software: white paper (Project Server 2010)

  • Resource management: white paper (Project Server 2010)

  • GPS assistance in roadmapping an EPM deployment: white paper (Project Server 2010)

  • A phased approach to deploying enterprise project management: white paper (Project Server 2010)

For more information about Chris Vandersluis, see the "From the Trenches" column located on the Project Server 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=208599) on Microsoft TechNet.


Planning and architecture for Project Server 2010

Published: May 12, 2010

IT professionals can use the content in this planning and architecture guide to develop conceptual, logical, and physical designs for configuring Microsoft Project Server 2010 features, servers, and topologies. This section also provides recommendations for system designs based on customer scenarios and includes information to help IT Pros design a highly reliable, consistently available, and scalable system.

In this section:

  • Plan hardware architecture in Project Server 2010

    This article describes the tested performance and capacity limits of Microsoft Project Server 2010, provides information about the test environment, and test results, and offers guidelines for acceptable performance.

  • Plan for deployment (Project Server 2010)

    This article provides links to articles about deployment planning. Before installing Microsoft Project Server 2010, be sure you have reviewed this information.

  • Plan for authentication in Project Server 2010

    This article describes planning for security in a Microsoft Project Server 2010 Enterprise Project Management (EPM) Solution. This material is useful for Project Management Organizations (PMOs) and system administrators who are responsible for planning the deployment of a Project Server 2010EPM Solution.

  • Project Server and SharePoint Server security

    Microsoft Project Server 2010 is completely dependent on Microsoft SharePoint Server 2010 to support its user interface and farm topology. Security at the authentication level is tightly integrated between Project Server 2010 and SharePoint Server 2010, whereas user and group authorization is handled separately by Project Server 2010.

  • Plan for performance and capacity (Project Server 2010)

    This set of articles covers capacity planning for Microsoft Project Server 2010.

  • Plan groups, categories, and RBS in Project Server 2010

    Microsoft Project Server 2010 security is based on users, groups, and categories. This article addresses planning for groups and categories in a Project Server deployment.

  • Project Server 2010 upgrade overview

    This article provides an overview of how to upgrade to Microsoft Project Server 2010 from a previous version of Project Server.

  • Plan for upgrade to Project Server 2010

    This section contains articles that help you plan and prepare for upgrading from to Microsoft Project Server 2010.

  • Hardware and software requirements (Project Server 2010)

    Microsoft Project Server 2010 provides for a number of installation scenarios. Currently, these installations include single server with built-in database installations and single server or multiple server farm installations.

  • Project Server 2010 architecture

    This article describes the multi-tiered system in Microsoft Project Server 2010.

  • Plan browser support (Project Server 2010)

    This article describes supported Web browsers for connecting to Microsoft Project Server 2010 and other considerations that have to be made in planning for them.

  • Plan for Project Server 2010 Web Parts

    This article describes the 18 Web Parts that are installed with Project Server 2010 that provide Project Server 2010 functionality.

  • TechNet Webcast: Project Server 2010: Performance, part 1: setup, test, execution, and results

    This Microsoft TechNet Webcast is one of two parts that discuss Microsoft Project Server 2010 performance characteristics and farm architecture planning. This Webcast shows how the testing lab was set up, how the tests were executed, and which test tools were used.

  • TechNet Webcast: Project Server 2010: Performance, part 2: architecture, sizing, and capacity

    This Microsoft TechNet Webcast is one of two parts that discuss Microsoft Project Server 2010 performance characteristics and farm architecture planning. This Webcast shows the test results, architecture, data flow, and sizing guidelines and best practices for a Project Server 2010 implementation.

  • Technical diagrams (Project Server 2010)

    This article contains models (posters) that detail a specific technical area, such as upgrade paths for Project Server 2010 or the various methods available for migrating from Microsoft Office Project Portfolio Server 2007 to Project Server 2010.


Plan hardware architecture in Project Server 2010

Published: June 16, 2011

Many factors can have a major effect on throughput in Microsoft Project Server 2010. These factors include the number of users; the type, complexity, and frequency of user operations; the number of post-backs in an operation; and the performance of data connections. You should carefully consider the factors discussed in this section when you plan your hardware architecture. Project Server can be deployed and configured in a wide variety of ways. As a result, there is no simple way to estimate how many users can be supported by a given number of servers. Therefore, make sure that you conduct testing in your own environment before you deploy Project Server 2010 in a production environment.

This article describes the tested performance and capacity limits of Microsoft Project Server 2010, provides information about the test environment and test results, and offers guidelines for acceptable performance. Use the information in this article to estimate throughput targets for Project Server.

When you undertake capacity planning for Microsoft Project Server 2010, be aware of the variables that can affect the performance of a Project Server deployment.

Because of the rich functionality set that Project Server provides, deployments that seem similar when described at a high level can differ significantly in their actual performance characteristics. It is not enough to characterize your demands by just the number of projects, or the number of users that you will have in the system. Thinking about the performance of your Project Server deployment requires a more nuanced and holistic approach. For example, workloads, and subsequently your hardware needs, will differ in relation to the following variables:

Factor Characteristics

Projects

  • Number of projects

  • Typical project sizes with regard to tasks

  • Number of project-level custom fields

  • Level of linking (dependencies) between tasks

Users

  • Concurrency of users. How many users will be hitting the system at the same time? What is the average load, what are the spikes in traffic?

  • What security permissions do users have? This affects both the amount of data the server needs to present to the user at a given time, along with the complexity of the security checks the server has to do.

  • Geographic distribution of users. When users are spread over large geographical areas there can be detrimental performance effects caused by network latency. This also impacts usage patterns insofar as users are likely to hit servers at different times during the day that make it harder to find low-traffic periods in which to run maintenance tasks such as backups, reporting, or Active Directory sync.

Usage Patterns

  • Workload conditions. Which set of features are being commonly utilized? For example, a deployment that uses time-sheeting heavily will have different characteristics than one that does not use time-sheeting.

  • Average time between page requests

  • Average session time

  • Payload of Pages. How many Web Parts do you have on a given page? How much data do they contain?

There are many more variables that can affect performance in a given environment, and each of these variables can affect performance in different areas. Some of the test results and recommendations in this article might be related to features or user operations that do not exist in your environment, and therefore do not apply to your solution. Only thorough testing can provide you with exact data related to your own environment.

Other variables to consider:

  • Concurrency of Users: Concurrent user load is often a significant factor in setting capacity requirements. You may have fewer users in the system, but they may all transact with the server simultaneously during your "peak" traffic periods. For example, an organization that has its users all submit status/timesheet updates at the same time of the week will likely notice a substantial decrease in performance during those periods. If you have heavy peak usage periods, plan to add additional resources to the topology recommended for your dataset.

  • Split of User Roles: The distribution of your users between Administrators, Portfolio Administrators, Project Managers, and Team Members will affect the performance of your deployment insofar as each type of user has access to a different amount of data. Users in different security categories may vary with regard to how many projects and resources that they are able to see. Administrators, for example, are able to see all projects on the server when they load Project Center, and all resources when they load Resource Center. In comparison, a Project Manager will only see his own projects. The result is that these users are subject to a diminished perceived performance. Where possible, we suggest you limit the number of projects, tasks, or resources shown in a given view by defining appropriate filters in the views that you define in Server Settings>Manage Views.

  • Global Distribution of Users

  • Issues, Risks and Deliverables: Having larger numbers of these entities may place additional load on your SQL Server. In particular, it is the act of viewing and interacting with these entities in the Project site that is likely to create the additional load. If you use these features heavily, you may want to allocate additional resources to your deployment of SQL Server to maintain a high level of performance. Given that these artifacts and the Project site functionality are SharePoint sites and lists, consult documentation around scaling SharePoint sites and lists.

  • Calendars: Custom calendars can be defined for projects, tasks and resources. These largely affect the scheduling engine, exerting higher CPU usage on the application and database servers.

Typical datasets

The datasets described in this section are characterized by the variables listed and explained in the table below. These variables may not capture all of the factors that affect the performance of Project Server (that is, they do not capture the mix of features that you tend to use in your deployment). However, they do capture much of the information that is significant in determining appropriate capacity.

 | Entity | Description/Notes | Small | Medium | Large
1 | Projects |  | 100 | 5000 | 20000
1 | Tasks |  | 17125 | 856250 | 3425000
1 | Average Tasks Per Project |  | 171.25 | 171.25 | 171.25
2 | Task Transaction History | The number of times status tends to be submitted and approved for any given task | 10 | 100 | 1000
1 | Assignments |  | 22263 | 1113125 | 4500000
1 | Average Assignments Per Task |  | 1.3 | 1.3 | 1.3
2/3 | Approvals | Pending Updates Per Manager | 50 | 600 | 3000
 | Users |  | 1000 | 10000 | 50000
Custom Fields | Project (Formula) |  | 3 | 20 | 25
Custom Fields | Project (Manual) |  | 2 | 40 | 50
Custom Fields | Task (Formula) | Task formula fields tend to take the largest toll on performance because they need to be computed for each task. | 6 | 12 | 15
Custom Fields | Task (Manual) |  | 4 | 8 | 10
Custom Fields | Assignment Rolldown |  | 50% | 50% | 50%
Custom Fields | Resource |  | 10 | 20 | 25
Custom Fields | Look up Table Custom Fields |  | 2 | 15 | 100
1 | Timesheets (per year) | The more you utilize Timesheets the more resource demands that are placed on the SQL Server | 52000 | 780000 | 8,320,000
1 | Timesheet Lines |  | 5 | 10 | 10

Hardware recommendations

The following sections provide general performance and capacity recommendations. Use these recommendations to identify a suitable starting topology for your requirements, and to decide whether you have to scale out or scale up the starting topology.

Throughout this article we refer to the three different roles that are set up in Windows Server: the Web Front End Server Role, Application Server Role, and Database (SQL) Server Role. These are all components of a complete Project Server 2010 deployment. The Web Front End Servers act as the interface for users accessing Project Server. The Application Server handles the requests to the data tier of Project Server and implements the business logic of Project Server 2010. Lastly, the database tier is the data source, housing the Project Server 2010 databases. For small deployments, the Web Front End Server, Application Server and Database Server roles may be combined on the same physical computer. For larger deployments it may be necessary to separate these onto separate computer, even having multiple physical computers acting in the same role.

Small dataset hardware recommendations

This section suggests a recommended topology for each of the small, medium, and large dataset sizes characterized earlier in the "Typical datasets" section. The recommended topologies for each dataset should be sufficient for obtaining reasonable performance with most usage patterns on those dataset sizes. However, we encourage you to take into account the specific recommendations given throughout the rest of this article for determining whether you need to expand beyond the topology that is recommended for your approximate dataset. In general, you should monitor the performance metrics of your topology and scale it accordingly if you are unsatisfied with the performance characteristics.

Note that because Project Server 2010 coexists with SharePoint Server 2010, it uses additional resources (Processor, RAM, and Hard Disk). The guideline requirements for SharePoint Server 2010 are also valid for a Project Server 2010 installation with a small data set and light usage. However, for more substantial data sets and usage patterns, additional hardware resources are required. For deployment on a stand-alone computer, with a small data set, 16 GB of RAM is advised to assure a high level of perceived performance. Beyond this, if possible, we recommend that you separate your Database Server from the Application and Web Front End tiers by placing your databases on a dedicated computer that is running SQL Server.

The following table lists the specifications for a single server with built-in database installations and server farm installations that include a single server or multiple servers in the farm.

Front-end Web/Application server

Component | Recommended
Processor | 64-bit, four-core, 2.5 gigahertz (GHz) minimum per core
RAM | 4 GB for developer or evaluation use, 8 GB for single-server and multiple-server farm installation for production use
Hard Disk | 80 GB

SQL Server

Component | Recommended
Processor | 64-bit, four-core, 2.5 GHz minimum per core. (If your dataset size is considerably larger than the medium dataset, eight cores is recommended.)
RAM | 4 GB for developer or evaluation use, 8 GB for single-server and multiple-server farm installation for production use
Hard Disk | 80 GB

Medium dataset hardware recommendations

The minimum requirements specified for medium sets can be scaled out and scaled up to handle additional load. The scaled-up and scaled-out topologies discuss considerations about how to handle increased user load and increased data load.

As a general prescription, you should prepare to handle additional user load and data load by having sufficient computers to add Web Front End servers and Application Servers to your topology. The hardware specifications of your Web Front End servers and Application servers can remain largely the same. A 4 × 2 × 1 topology should be sufficient for handling the needs of most medium data sets and usage patterns. Scaling out your Application and Web Front End servers will add additional load on your deployment of SQL Server, which you should compensate for by adding more memory and CPU resources. The following SQL Server specification should be able to handle the performance needs of most medium datasets. The best way to identify whether the topology you have designed satisfies your performance needs is to set up a staging environment to test your topology and monitor the performance characteristics.

Front-end Web server

Component | Recommended
Processor | 64-bit, four-core, 2.5 GHz minimum per core
RAM | 4 GB for developer or evaluation use, 8 GB for single-server and multiple-server farm installation for production use
Hard Disk | 80 GB

Application server

Component | Recommended
Processor | 64-bit, four-core, 2.5 GHz minimum per core
RAM | 4 GB for developer or evaluation use, 8 GB for single-server and multiple-server farm installation for production use
Hard Disk | 80 GB

SQL Server

Component | Recommended
Processor | 64-bit, eight-core, 2.5 GHz minimum per core (If your dataset size is considerably larger than the medium dataset, eight cores is recommended.)
RAM | 32 GB
Hard Disk | 160 GB

Large dataset hardware recommendations

For large datasets, the data load is the most substantial performance bottleneck.

Generally, at a minimum for large datasets, you will want a 4 × 2 × 1 topology. The hardware characteristics of the Web Front End and Application Servers can generally remain the same as those recommended for the small and medium datasets. However, given that the SQL Server installation will be the bottleneck, you may find that this constrains your ability to scale out to additional Web Front End and Application Servers. If you find that data load is your bottleneck, you may find that additional Web Front End and Application severs do not produce an improvement in throughput.

For large datasets, if the SharePoint Server 2010 instance which Project Server 2010 is coexisting with is also getting heavy usage (that is, you are not using that SharePoint Server 2010 deployment specifically for Project Server 2010 functionality), then we recommend to separate the four Project Server 2010 databases from the SharePoint Server 2010 content databases, placing them on their own dedicated instance of SQL Server.

Given that data throughput will be the bottleneck, you should invest in additional resources on the SQL Server tier of your topology. You can "scale-up" your installation of SQL Server by adding RAM, CPU, and hard disk resources. In the following sections we list the minimum and recommended specifications for the SQL Server tier of a large dataset topology.

Minimum SQL Server requirements

Component | Recommended
Processor | 64-bit, eight-core, 2.5 GHz minimum per core. (If your dataset size is considerably larger than the medium dataset, eight cores is recommended.)
RAM | 32 GB
Hard Disk | 250 GB

Recommended SQL Server requirements

Component | Recommended
Processor | 64-bit, eight-core, 2.5 GHz minimum per core. (If your dataset size is considerably larger than the medium dataset, eight cores is recommended.)
RAM | 64 GB
Hard Disk | 300 GB or more. Put your reporting database on a separate database server. Ideally, you should separate and prioritize data among disks. Place your data files and your SQL Server 2008 transaction logs on separate physical hard disks. RAID 5 should provide a good compromise between reliability and throughput.

Virtualization recommendations

Project Server 2010 does support running on virtualized machines. Most of the advice given for virtualization of SharePoint Server 2010 also applies to Project Server 2010. For documentation on virtualization in SharePoint Server 2010, see Virtualization planning (SharePoint Server 2010). You may also refer to the Project Server 2007 Virtualization guide for additional information on virtualization and Project Server 2010, as most of that guidance is still applicable. However, as in any situation where virtualization is employed, it is important to consider contention for physical computer's resources between virtualized machines running on the same physical instance.

Note:

We do not recommend running SQL Server on a virtualized machine. The competition for resources on a virtualized machine can substantially decrease the performance of the server. If you must run SQL Server in a virtualized environment, we recommend that you use the following settings:

  1. Network Adaptor:

    • If you are using Hyper-V virtualization, you should utilize the virtual network adapter rather than the legacy network adapter.

  2. Virtual Disk:

    • For the virtual machine that you are running SQL Server on, we recommend that you select the "pass through" option for the disk type (rather than dynamic or fixed). If this is not an option, you should use a fixed disk size rather than a dynamically sized virtual disk.

    • We recommend that you select IDE over SCSI for your boot drive

    • Allocate sufficient hard disk space to handle the expected maximum size of your dataset and ULS logging demands.

  3. Memory:

    • You should allocate as much memory to the virtual machine that is running SQL Server as can feasibly be allocated. This should be comparable to the amount of memory required/recommended for physical servers serving the same function.

    • At least 2 GB of memory should be reserved for the Host Operating System.

Running the Web Front End or Application Servers in virtualized environments tends to not be as detrimental to the performance of running SQL Server in a virtualized environment.

Network requirements

For most Project Server deployments, network bandwidth tends not to be the bottleneck on performance. The table below lists the recommended specifications of network components. A general aim should be to maintain low latency between the Application and SQL Server tiers.

Component | Small and Medium Dataset | Large Dataset
Number of NICs | 1 | 2
#NIC Speed (Network) | Any speed greater than 100mbps should be fine | 1 GB/s
Load Balancer Type | NLB or hardware; both are acceptable | NLB or hardware; both are acceptable


Plan for deployment (Project Server 2010)
See Also

Published: May 12, 2010

This article provides links to articles about deployment planning. Before installing Microsoft Project Server 2010, be sure you have reviewed the information in these articles.

Important:

Project Server 2010 does not support multi-tenant environments. Do not install Project Server 2010 on a multi-tenant SharePoint Server 2010 farm. If you have Project Server 2010 installed on a farm, do not configure multi-tenancy on that farm.

In this section:

  • Determine project management requirements (Project Server 2010)

    It is important to determine the project management needs and requirements for your organization. Your configuration will vary according to the kind of work that your organization performs and whether you use Project Server 2010 for time tracking, collaboration, or portfolio management.

  • Determine the number and types of users (Project Server 2010)

    The number and types of users in your organization who use Project Server features have a direct effect on the scalability and performance needs of your organization.

  • Plan EPM Solution architecture (Project Server 2010)

    This chapter describes the components of a Microsoft Enterprise Project Management (EPM) Solution. This material is written for executives, managers, and system administrators who are responsible for planning the deployment of an EPM Solution.

  • Plan the project life cycle (Project Server 2010)

    This article alerts those who are responsible for planning the deployment and configuration of Project Server 2010 that some choices will have to be made that relate to the features described in this chapter.

  • Plan reporting and business intelligence (Project Server 2010)

    In Project Server 2010, Project Server has been integrated with Excel Services in Microsoft SharePoint Server 2010 to make it easier to create custom reports.

  • Plan for administrative and service accounts (Project Server 2010)

    Use this article to plan for the account requirements and recommendations for accounts that are required to install, configure, and use Microsoft Project Server 2010.

  • Podcast: Project Server planning (Project Server 2010)

    In this podcast, Microsoft Program Manager Treb Gatte and consultant, author, and Microsoft MVP Gary Chefetz discuss planning considerations for Microsoft Project Server 2010.

  • Plan for Exchange integration (Project Server 2010)

    This article discusses integration with Microsoft Exchange Server 2007 SP2, which enables Microsoft Project Server 2010 users to view Project Server tasks in Microsoft Exchange client software.

  • Demand Management in Project Server 2010 (white paper)

    This white paper is written from an end user's perspective to discuss the Demand Management capability in Microsoft Project Server 2010.

  • Portfolio Server migration guide (white paper)

    This document is intended for both IT Professionals and business users who use Microsoft Office Project Portfolio Server 2007 today and are considering an upgrade to Project Server 2010. This document outlines the various approaches and points out the useful resources in this area.

  • Portfolio strategy with Project Server 2010 (white paper)

    This white paper is written from an end user's perspective to discuss the extensive Project Portfolio Management (PPM) capability in Microsoft Project Server 2010.

  • Project and SharePoint Server 2010 — Better Together (white paper)

    This white paper is written for end users. It highlights the new features in Project Server 2010.

  • Hitchhiker's Guide to Demand Management (white paper)

    This white paper is written from a Project Management Office perspective to discuss implementing the Demand Management capability in Microsoft Project Server 2010.

See Also

Other Resources

Project Server 2010 Ignite Training: Planning, Design, and Deployment
Project Server 2010 Ignite Training: Upgrade and Migration


Determine project management requirements (Project Server 2010)

Published: May 12, 2010

It is important to determine the project management needs and requirements for your organization. Your configuration will vary according to the kind of work that your organization performs and whether you use Project Server 2010 for time tracking, collaboration, or portfolio management. After you characterize the typical projects for your organization, determine which Project Server scenarios that you have to support.

Once you have completed determining your project management requirements, see Plan for performance and capacity (Project Server 2010) to determine the hardware requirements for your Project Server infrastructure.

Characterize your projects

Understanding the characteristics of the projects in your organization enables you to plan your Project Server 2010 configuration. The following characteristics have a significant effect on your configuration:

  • The number of projects that your organization is working on at a particular time.

  • The size of your projects, which varies with the number of tasks and assignments that your projects include.

  • The length of time that is required to complete a project.

  • The number of team members that are assigned tasks in projects.

Most organizations manage projects that vary in size and duration, but the degree to which they vary is a function of the size of the organization and the kind of work that it performs. For example, a large consulting company might manage several thousand projects that range from small, 10-task projects that last two weeks to large projects that include 1,500 tasks and last for over a year.

Organizations typically have many projects that range in size from small to medium to large. For planning, make sure that you can adequately support the kind of project that your organization works on most frequently.

Determine your Project Server 2010 scenario

Your project management needs and requirements vary according to the kind of work that your organization performs. As part of your configuration planning process, determine which scenario that you need to support. For example, you can use Project Server 2010 to support the following kinds of scenarios:

  • Enterprise Project Management

  • Time tracking

  • Demand management

Using Project Server 2010 for Enterprise Project Management

The Project Server 2010 scenario for EPM applies to a large organization whose area of focus is top-down planning driven through the Project Management Office (PMO). This scenario is more frequently seen in the product development and manufacturing markets. It has the following characteristics:

  • A small number of large projects that are often related

  • Focus on the PMO

  • Extensive use of Microsoft Project Professional 2010

  • Work Tracker usage

Critical considerations for this kind of deployment include the following:

  • The level of detail to track

  • Using leveling as a process

  • How to prioritize capacity

  • How to use skill tracking

In this scenario, client usage is as follows:

Client application | Rate of usage
Project Professional 2010 | High
Project Web App | High

In this scenario, server usage is as follows:

Project Web App feature | Rate of usage
Work Tracker | High
Programs | High
Timesheets | Medium
Portfolio management | Medium
Master projects | High
Project workspaces | Low
Risk management | Medium
Issues management | High
Document management | Medium
Resource management | Medium
Task management | Medium

Using Project Server 2010 for time tracking

The Project Server 2010 scenario for professional services/timesheet deployment can apply to a large organization that wants to use Project Server 2010 mainly to capture and report time. In this scenario, employees and contractors use Project Server 2010 timesheet functionality to submit hours worked on tasks during specific time periods. This scenario has the following characteristics:

  • Minimal use of Project Professional 2010

  • Time and material billing

  • A large number of projects that have fairly few tasks

  • A predictable peak period of usage that corresponds to scheduled timesheet entry in Project Web App

Organizations that support this scenario typically use a limited set of Project Professional 2010 features to track time and costs by using timesheets to capture information. This scenario presents scalability issues, because, when many timesheets are submitted in a short period of time, system resources can become severely strained.

Critical considerations for this kind of deployment include the following:

  • What time classifications to use

  • What time periods to use

  • Calendars and overtime setup

  • What fiscal periods to use

  • Source of cost data

  • Custom field configuration — process control custom fields vs. reporting custom fields

  • Currency configuration

  • Auditing

There are additional factors that can be affected by the processes that are used within your organization, including the following:

  • Types of usage

  • What the project update cycle is

  • What the reporting cycle is

In this scenario, client usage is as follows:

Client application | Rate of usage
Project Professional 2010 | Medium
Project Web App | High

In this scenario, server usage is as follows:

Project Web App feature | Rate of usage
Work Tracker | High
Programs | Low
Timesheets | High
Portfolio management | Low
Master projects | Low
Project workspaces | Low
Risk management | Low
Issues management | Low
Document management | Low
Resource management | High
Task management | Medium

Using Project Server 2010 for Demand Management

The Project Server 2010 scenario for Demand Management deployment can apply to any medium-to-large organization that wants to use Project Server 2010 to manage project portfolios. These organizations typically have the following characteristics:

  • A large number of projects that have many assignments

  • A high percentage of project managers

  • Frequent use of Project Professional 2010

Organizations that support this scenario typically use the breadth of Project Server 2010 features that include timesheets, document libraries, issues, risks, the Enterprise Global Template, and the Enterprise Resource Pool.

The organization to which this scenario can apply can be as small as a medium-size organization (or a department in a larger organization) whose users all share the same physical location on the same LAN, or it can be a large organization whose users work in several different physical locations.

These organizations use Project Professional 2010 and Project Web App daily to publish or update projects to the Project Server 2010 database, and they use Project Web App to view assignments; report actuals; and access documents, issues, and risks. Additionally, these organizations generate online analytical processing (OLAP) cubes weekly.

Critical considerations for this kind of deployment include the following:

  • Level of resource data to track

  • What project nomination process to use

  • What kind of review process to use

  • What the report cycle will be

  • Workflow requirements

  • What kind of work to track

  • Who manages the process

  • What demand is captured

In this scenario, client usage is as follows:

Client application | Rate of usage
Project Professional 2010 | Medium
Project Web App | High

In this scenario, server usage is as follows:

Project Web App feature | Rate of usage
Work Tracker | Low
Timesheets | Medium
Portfolio management | High
Programs | Low
Administrative projects | Low
Collaboration | Medium
Document management | Medium
Risk management | Medium
Issues management | Medium
Resource management | Medium
Project workspace sites | Medium


Determine the number and types of users (Project Server 2010)
See Also

Published: May 12, 2010

The number and types of users in your organization who use Project Server features have a direct effect on the scalability and performance needs of your organization.

Number of users

When you determine the number of Project Server users that your organization needs to support, also consider the maximum number of concurrent users. This is especially critical if your organization plans to support the time tracking scenario.

It is helpful to categorize users to determine the different types of them that you need to support, as well as how many of each type. For example, project managers who use Project Professional create the greatest load on the system; viewers create the smallest amount of load.

Types of users

The types of users that you need to support, and the percentage of each compared to the total number, affects the configuration decisions that you make during your planning process. Each user type places a load on the system. The most common user types are as follows:

  • Project managers

  • Resource managers

  • Team members

  • Executives

  • Administrators

Project managers

Project managers are responsible for overseeing and completing projects, sometimes coordinating with other project managers and resource managers in the organization. Project managers use Microsoft Project Professional 2010 to do the following:

  • Create and publish projects to the Project Server database

  • Modify projects based on feedback

  • Assign team members to project tasks

  • Track progress by incorporating task updates from team members

  • Determine target and actual project timelines and costs

Resource managers

Resource managers are responsible for managing resources and defining skills based on capabilities. They work with project managers and other resource managers to ensure that qualified resources are assigned to tasks in projects. Resource managers use Microsoft Project Web App (PWA) to do the following:

  • View workload and availability by project over time

  • View workload and availability by resource over time

  • Add team members to project teams

  • Post issues and upload documents

  • Use Portfolio Modeler to determine resource availability

  • Modify resource skills and other codes

Team members

Team members are resources who are assigned to tasks in projects. A team member typically works on multiple projects at any given time and is responsible for completing tasks according to a schedule. Team members can use both Project Web App and Microsoft Outlook 2007 or 2010. (Exchange Server integration with Project Server enables team members to integrate Project Server data with Outlook.) Team members use PWA to do the following:

  • Meet deadlines by identifying current and upcoming tasks to prioritize daily work

  • Report time spent working on tasks by entering progress in timesheets

  • Delegate and add tasks

  • Record and respond to project-related issues and risks

  • Link issues to tasks

  • Submit status reports

  • Work collaboratively with other team members on project-related documents

Team members use Outlook to do the following:

  • View assigned tasks

  • Report on assigned tasks

Executives

An executive is a user who uses PWA to view status or reporting on a project or multiple projects. For example, an executive can oversee several different projects that are managed by different project managers to gain an overall perspective on schedule and budget. Executives use PWA to do the following:

  • View project and resource reports in Portfolio Analyzer

  • Submit issues to project and resource managers

Administrators

Administrators deploy and manage Project Server 2010 and related applications. These users manage access to the server and the server database. PWA provides access to the Project Server administrative tools. Administrative tools are also provided with Microsoft Windows Server and SQL Server. Administrators use PWA to do the following:

  • Define timesheet views

  • Lock reporting periods and actuals in timesheets

  • Create standardized reports for Portfolio Analyzer views

  • Add team members to, and delete team members from, the Enterprise Resource Pool

See Also

Concepts

Manage users in Project Server 2010


Plan EPM Solution architecture (Project Server 2010)
See Also

Published: May 12, 2010

This chapter describes the components of a Microsoft Enterprise Project Management (EPM) Solution. This material is written for executives, managers, and system administrators who are responsible for planning the deployment of an EPM Solution.

An EPM Solution that is based on Microsoft Project Server 2010 is deployed across multiple tiers: a client tier, a Web tier, an application tier, and a database tier. Applications and services in each tier provide for availability and scalability, which enables any size organizations to manage projects of a range of sizes and levels of complexity. You can configure the application and database tiers of your EPM Solution to best meet the needs and requirements of your organization.

Microsoft SharePoint Server 2010 is a necessary part of the EPM Solution for Project Server 2010. It is important that you include planning for SharePoint Server 2010 as part of your EPM Solution deployment plans. For more information, see Planning and architecture for SharePoint Server 2010.

In this chapter:

  • Plan the client tier (Project Server 2010)

    This article identifies the key components of the client tier and helps you distinguish from the parts of the other tiers in the Microsoft Enterprise Project Management (EPM) Solution.

  • Plan the application tier (Project Server 2010)

    This article discusses the components included in the application tier in an EPM Solution.

  • Plan the database tier (Project Server 2010)

    This article identifies the key components of the database tier and helps you to distinguish from the parts of the other tiers in the EPM Solution.

See Also

Concepts

Project Server 2010 architecture


Plan the client tier (Project Server 2010)
See Also

Published: May 12, 2010

This article identifies the key components of the client tier and helps you distinguish from the parts of the other tiers in the Microsoft Enterprise Project Management (EPM) Solution.

The client tier of the EPM Solution includes Microsoft-based applications and any custom applications that are specific to your organization.

Microsoft Project Professional 2010

Microsoft Project Professional 2010 is a desktop application that enables project managers to create, publish, and manage projects. In addition to scheduling and tracking tools, Project Professional 2010 provides project managers with enterprise resource and portfolio management capabilities.

For information about deploying Project Professional 2010 in an enterprise environment, see Office 2010 Resource Kit.

Microsoft Outlook

Microsoft Project Server 2010 provides integration with Microsoft Exchange, which lets users access Project Server tasks from within Outlook. Users can also receive e-mail reminder notifications for tasks that they are assigned in projects that are stored in the Project Server 2010 database.

Internet Explorer

Microsoft Project Web App is a rich Web-based client that is designed for users who are not project managers, such as resource managers, viewers, and team members. These users access project information in Project Web App by using Windows Internet Explorer. Project Web App provides access to timesheets, project views, status reports, document libraries, and risks.

Project Web App requires Internet Explorer 7.0 or 8.0. If your organization is still using previous versions of Internet Explorer, you can consider using Windows Terminal Services to provide users access to Internet Explorer 7.0 or 8.0 without deploying it to the desktop. For more information about Terminal Services, see the following references:

Windows Server 2003:

  1. Terminal Server (http://go.microsoft.com/fwlink/p/?LinkId=187190)

  2. Terminal Server Licensing (http://go.microsoft.com/fwlink/p/?LinkId=187192)

Windows Server 2008:

  1. Terminal Services Overview (http://go.microsoft.com/fwlink/p/?LinkId=187191)

  2. Terminal Services RemoteApp (http://go.microsoft.com/fwlink/p/?LinkId=187194)

  3. Terminal Services Licensing (http://go.microsoft.com/fwlink/p/?LinkId=187193)

  4. Plan for Remote Desktop Services (Terminal Services)

Third-party and line of business applications

Many organizations use line-of-business client applications or develop business-specific applications. These applications call Project Server 2010 by using the Project Server Interface — an extensible set of Web services — and must also be integrated with a Microsoft Windows-based platform.

Project Server 2010 provides a complete Software Development Kit (SDK). For more information, see Project 2010 SDK Documentation (http://go.microsoft.com/fwlink/p/?LinkId=187195).

See Also

Other Resources

Plan for volume activation of Office 2010


Plan the application tier (Project Server 2010)

Published: May 12, 2010

The application tier in a Microsoft Enterprise Project Management (EPM) Solution includes the following components:

  • SharePoint Server 2010

  • Project Server 2010

  • Project Server Interface

  • Project Server 2010 Events service

  • Project Server 2010 Queue service

  • Exchange Server

  • Other applications (described in this article)

SharePoint Server 2010

The Enterprise edition of Microsoft SharePoint Server 2010 is required for Microsoft Project Server 2010. SharePoint Server 2010 has many features in its own right, and deployment of SharePoint Server 2010 should be carefully planned. For information about how to plan your SharePoint Server 2010 deployment, see Planning and architecture for SharePoint Server 2010.

Project Server 2010

Microsoft Project Server 2010 is the central component of a Microsoft Enterprise Project Management (EPM) Solution. Project Server 2010 is a robust and highly scalable Web-based server application that is integrated with several client applications, the Microsoft Windows Server platform, and Microsoft SQL Server 2005 or 2008.

You can run the Project Server 2010 service on one or more application servers in a SharePoint Server 2010 farm. Project Server 2010 is supported on a computer that is running Windows Server 2008 or Windows Server 2008 R2 with the Enterprise edition of SharePoint Server 2010 installed.

Project Server Interface

The Project Server Interface is the application programming interface (API) of Project Server 2010. The Project Server Interface object model exposes Project Server 2010 functionality to all external applications. Microsoft Project Professional 2010, Microsoft Project Web App, and line-of-business and other third-party applications use the Project Server Interface (PSI) to access Project Server 2010 data that is stored in the Draft, Published, and Archive databases. The PSI is available through Web service calls by back-end line-of-business applications, or through a Project Server Interface proxy for client applications having a user interface.

Project Server 2010 Events service

The system-level Project Server 2010 Events service manages the Project Server 2010 events. Other applications can subscribe to Project Server 2010 pre-events and post-events, and register event handler methods through Project Web App. Event handlers can check business rules and cancel an operation through a pre-event, or extend Project Server 2010 with additional processing such as workflow by using a post-event (for example, ProjectPublished).

Project Server 2010 Queue service

There are two Project Server 2010 queues that operate in the system-level Microsoft Project Server 2010 Queue service:

  • To manage heavy peak loads, the Timesheet queue handles submission and updates of timesheet and status reports.

  • The Save and Publish queue manages new and incremental saves of working projects to the Draft database and also manages publishing a project — that is, moving the project from the Draft to the Published database.

Exchange Server

Exchange Server integration allows for Project Server 2010 users to view Project Server tasks in Microsoft Office Outlook. This functionality replaces the Outlook Add-in task statusing functionality for non-time-phased tasks that was available in previous versions of Project Server.

To configure Exchange integration, the Project Server administrator must grant access to the instance of Exchange Server and the Exchange administrator must grant Exchange access to the Project Server farm administrator account.

Other applications

Third-party and line-of-business applications can be used with Project Server 2010. By using the Project Server Interface, you can address many project management needs with these applications. The following are some sample scenarios:

  • Project proposals Create placeholder projects during project initiation and use project custom fields to tag the project with information needed for the initiation and approval process. Add tasks to identify project phases for key milestones or deliverables. When approved, project proposals can evolve into full-scale projects that are managed by using Project Professional 2010.

  • Maintenance projects Create placeholder projects to use with resource plans. Reserve or book time against resources for maintenance work or base business. Maintenance projects generally do not have tasks.

  • Financial projects Create projects for time capture through the timesheet for integration with a financial system. Create tasks for a hierarchy of financial codes that reflect the cost breakdown structure of the financial system. These projects do not require scheduling or status updates.

  • Integration with project accounting systems Capture the resource costs and expenses associated with projects to feed financial and billing systems and for budget comparison purposes. Synchronize tasks, resources, and assignments between the systems. Capture timesheet data in one system to feed the other (which timesheet is used depends on the needs of the organization or of individual projects).

  • Integration with work or task management systems Synchronize tasks and assignments between Project Server 2010 and systems such as Microsoft Visual Studio Team System. Microsoft Visual Studio Team System is integrated with Microsoft Project Standard 2010 and Project Professional 2010, but integration with Project Server 2010 requires developing components by using the PSI.

  • Process updates from team members For projects that are not actively managed, automatically update them on the server by using information from team members about progress and other changes. Projects can be updated and republished without a project manager reviewing the results or making adjustments to the plan.


Plan the database tier (Project Server 2010)

Published: May 12, 2010

This article identifies the key components of the database tier and helps you to distinguish from the parts of the other tiers in the Microsoft Enterprise Project Management (EPM) Solution.

The data access layer is internal to Project Server 2010 and is not exposed to external applications. The data access layer translates between the logical business entity representation of the data and the physical database tables. Each logical entity is stored in a number of different tables. The data access layer encapsulates the work required to manage connections, execute queries, and begin, commit, and roll back transactions. Project Server 2010 data is partitioned into four databases in Microsoft SQL Server:

  • The Draft database contains tables for saving unpublished projects from Microsoft Project Professional 2010. Project data in the Draft database is not accessible by using Microsoft Project Web App.

  • The Published database contains all of the published projects. Published projects are visible in Project Web App. The Published database also contains tables that are specific to Project Web App (timesheets, models, views, and so on), and global data tables (outline codes, security, and metadata).

  • The Archive database saves backed-up and older versions of projects.

  • The Reporting database is the staging area for generating reports and online analytical processing (OLAP) cubes. Data in the Reporting database is updated nearly in real-time, is comprehensive, and is optimized for read-only report generation.

Only the Reporting database schema is documented. You should access the Drafts, Published, and Archive databases only through the Project Server Interface. You can add data tables, fields (properties), and entities that are not defined in the Project Server 2010 database schema. If you do, you must also provide the full stack of a custom assembly, Web service, business objects, and data access.


Plan for virtual environments for Project Server 2010

Published: September 9, 2010

This chapter discusses planning for using Microsoft Project Server 2010 in a virtual environment. A virtual server running Project Server 2010 has the same minimum, and fundamental, requirements as a physical server running Project Server 2010. Virtualization provides many benefits; however, it does not eliminate or circumvent the existing requirements and best practices that relate to deploying, configuring, and maintaining a Project Server 2010 environment.

In this section:

  • Plan for using Project Server 2010 in a Hyper-V virtual environment

    This article provides preliminary guidance for using Microsoft Project Server 2010 with the Windows Server 2008 Hyper-V virtualization technology. The scope of this guidance covers Project Server 2010 and Microsoft SharePoint Server 2010.


Plan for using Project Server 2010 in a Hyper-V virtual environment

Published: September 9, 2010

This article contains preliminary guidance for using Microsoft Project Server 2010 with the Windows Server 2008 Hyper-V virtualization technology. The scope of this guidance covers Microsoft Project Server 2010 and Microsoft SharePoint Server 2010.

Support statement

Microsoft Project Server 2010 is supported in a Hyper-V environment. An official support statement for virtualization can be found listed at Microsoft server software and supported virtualization environments (http://go.microsoft.com/fwlink/p/?LinkID=126635).

Hardware and software requirements

In order to run Project Server 2010 in a Hyper-V environment, you must meet the Hyper-V prerequisites and follow the recommendations documented here and in Other resources later in this article.

Project Server 2010 recommendations for Hyper-V

The following are recommendations for setting up Project Server 2010 in a Hyper-V environment.

  • Review the documents described in Other resources, later in this article, as a prerequisite to deploying Project Server 2010 and SharePoint Server 2010 in a virtual environment.

  • Any Hyper-V virtual server must meet the requirements of the physical server (for example, CPUs, memory, and disk I/O) that you will run as a Hyper-V guest. As with all virtual technologies, there is an overhead cost on the host computer for each virtual machine.

  • Do not use the Hyper-V snapshot feature on virtual servers that are connected to Project Server 2010. This is because the timer services and the search applications might become unsynchronized during the snapshot process, and after the snapshot is finished, errors or inconsistencies can occur.

  • Do not use more virtual CPUs than there are physical CPUs on the Hyper-V host computer. Although Hyper-V lets you allocate more virtual CPUs than the number of physical CPUs, this causes performance issues because the hypervisor software has to swap out CPU contexts.

  • Leverage virtual networks. Hyper-V enables you to configure the following kinds of virtual networks:

    • Private: The virtual machines on the private network can communicate with one another.

    • Internal: The virtual machines can communicate with one another and with the host computer.

    • External: The virtual machines can communicate with one another, the host computer, and computers on the physical network.

    Private networks and internal networks do not use the physical network adapter or cable. Therefore, communications are faster and network congestion is minimized. You can take advantage of this network performance gain by creating an external network for the front-end Web servers and by creating a private or internal network for the application and SQL Server database servers.

Other resources

The following table provides important information about resources for Hyper-V, Project Server 2010, SharePoint Server 2010, and SQL Server 2008.

Title Description URL

SharePoint 2010 Virtualization Resource Center

Provides information about Hyper-V for learning about virtualization, plus articles and models for planning and deploying Microsoft SharePoint Server 2010 in a virtual environment.

http://technet.microsoft.com/en-us/sharepoint/ff602849.aspx

SharePoint 2010 Virtual Machine Guidance

Guidance designed to help you plan and implement a server virtualization solution for Microsoft SharePoint Server 2010 server.

http://technet.microsoft.com/en-us/library/ff621103.aspx

Microsoft Assessment and Planning Toolkit (MAP)

Used to determine whether your servers can be virtualized.

http://go.microsoft.com/fwlink/p/?LinkId=117991

Hyper-V Planning and Deployment Guide

Includes information about hardware requirements and limits, supported guest operating systems, and instructions for installing the role and management tools.

http://go.microsoft.com/fwlink/p/?LinkID=124368

Step-by-Step Guide to Getting Started with Hyper-V

Provides a full walk-through of how to create and configure virtual machines in a Hyper-V environment.

http://go.microsoft.com/fwlink/p/?LinkId=122588

Hyper-V Step-by-Step Guide: Testing Hyper-V and Failover Clustering

Shows you how to make a virtual machine highly available by creating a simple two-node cluster.

http://go.microsoft.com/fwlink/p/?LinkID=120666

Performance Tuning Guidelines for Windows Server 2008 R2

Provides details on tuning Windows Server 2008 R2 and includes a section specifically focused on Hyper-V.

http://go.microsoft.com/fwlink/p/?LinkId=121171

All Topics Performance Blog

Written by Tony Voellm and dedicated to performance topics. Tony is currently the lead of the Hyper-V Performance Team. Of particular interest is the four-part series that Tony wrote about Hyper-V performance counters.

  • Hyper-V Performance Counters - Part one of many - The overview (http://go.microsoft.com/fwlink/p/?LinkId=125651)

  • Hyper-V Performance Counters - Part two of many - "Hyper-V Hypervisor" counter set (http://go.microsoft.com/fwlink/p/?LinkId=125652)

  • Hyper-V Performance Counters - Part three of many - "Hyper-V Hypervisor Logical Processors" counter set (http://go.microsoft.com/fwlink/p/?LinkId=125653)

  • Hyper-V Performance Counters - Part four of many - "Hyper-V Hypervisor Virtual Processor" and "Hyper-V Hypervisor Root Virtual Processor" counter set (http://go.microsoft.com/fwlink/p/?LinkId=125655)

Windows Server 2008 R2 TechCenter

Information on Windows Server 2008 R2, including documentation, downloads, and community resources

http://go.microsoft.com/fwlink/p/?LinkId=126642

Virtualization Solution Center

Information on Hyper-V, Application Virtualization, Virtual Machine Manager, and Virtualization on Windows Server.

http://go.microsoft.com/fwlink/p/?LinkId=126643

TechNet Hyper-V landing page

Direct link to Hyper-V documentation on TechNet.

http://go.microsoft.com/fwlink/p/?LinkId=126647

Planning and architecture for Project Server 2010

Provides information and guidance for planning the architecture of a Project Server 2010 installation.

http://go.microsoft.com/fwlink/p/?LinkID=92795

Windows Azure Support

Project Server 2010 supports deploying a farm on the Windows Azure platform. You can deploy Project Server 2010 on virtual machines running on Hyper-V virtualization host servers on-premises or as a hosted solution running on Windows Azure Virtual Machines.

Note:

SharePoint Server 2010 is also supported on the Windows Azure platform, and it is an installation requirement for Project Server 2010. For information about support and licensing information about SharePoint Server 2010 on the Windows Azure platform, see Support and licensing for Windows Azure (SharePoint Server 2010).

For an overview of Windows Azure and information about deploying SharePoint Server 2010 on Windows Azure Virtual Machines, see the white paper SharePoint Deployment on Windows Azure Virtual Machines.

For more information about Windows Azure licensing and costs, see the Windows Azure site.

Conclusion

In any scenario, a virtual server that is running Project Server 2010 has the same minimum, and fundamental, requirements as a physical server that is running Project Server 2010. Virtualization provides many benefits. However, it does not eliminate or circumvent the existing requirements and best practices that relate to deploying, configuring, and maintaining a Project Server 2010 environment.


Plan the project life cycle (Project Server 2010)

Published: May 12, 2010

There are many methodologies and systems that effectively manage a project life cycle. This chapter does not advocate for any one of these over another. The chapter is written for Project Server administrators, and it provides a list of project creation, maintenance, and archival activities. These tasks are general and will be the same, or at least similar, regardless of the methodology being used by your organization. Planning these activities can help ensure that projects are being managed in a way that is consistent with the purpose of your organization and can foster a satisfactory experience for the end user. The various options and processes available with the features described in this chapter are discussed in greater detail in Operations for Project Server 2010. This article alerts those who are responsible for planning the deployment and configuration of Project Server 2010 that some choices will have to be made that relate to these features.

Create projects

Projects have many ways of moving from concept to reality. Sometimes the process is informal and may be the result of a brainstorm on a whiteboard that happened in under an hour. Other times a project is created after years of study and careful analysis. If it is not planned and managed, this creation process can become chaotic. This chaos can cost your organization in many ways: reduced efficiency, misallocated resources, misaligned priorities, duplication of effort, conflicting approaches, and missed opportunities, to name a few. What follows are some key things to consider when you are using Microsoft Project 2010 to create projects for your organization.

Plan proposals

The project proposal feature provides a mechanism for controlling the entry of projects into Project Server. It provides added value for business decision makers by storing proposal data together with project data. This feature provides better reporting, modeling, and pipeline analysis and helps automate proposal management business processes.

Proposals are limited projects. They are limited because all of the features that are available when you are using Microsoft Project Professional 2010 are not available when you are using proposals. Project proposals are not enterprise projects. This limited or lighter kind of project is helpful and useful to many users. The proposal lets users submit project proposals (aided with simple project and resource planning features) — and provides a simple gating mechanism for projects to be added to Project Server. Project proposals are subject to a review before they can be transformed into enterprise projects. Project proposals contain basic information that allows a business decision-maker to approve or reject the proposal. The proposal may contain information such as the following:

  • Project name

  • Project description

  • Proposed start date and end date

  • Proposed cost

  • Resource requirements

Proposals are created in Microsoft Project Web App (PWA). Anyone who has access to PWA can view proposals. To create project proposals, you must be assigned the Create New Maintenance Project permission.

Proposals can be configured to work with workflows that are available in Microsoft SharePoint Server 2010.

When the proposal feature is configured for a workflow, the workflow automatically does much of the work. When a proposal is created, the workflow generates task assignments for proposal reviewers and the proposal creator as the proposal makes its way through the proposal process. These tasks are shown to their owners through the Web Part for Proposal Workflow Tasks.

Plan resources

Enterprise resources are the people, equipment, and materials that are used to complete tasks in an enterprise project. Enterprise resources are part of your organization's pool of resources and are stored centrally in the Project Server 2010 databases. You can create the Enterprise Resource Pool that project managers will use when assigning resources to tasks in projects by adding resources to the Enterprise Resource Pool or by importing resources. You should define the contents of the Enterprise Global Template before you add resources to the Enterprise Resource Pool.

Before you can properly create and maintain the Enterprise Resource Pool for your organization, you must carefully define and document your Enterprise Resource custom fields and create them. In addition, for large organizations, initially populating the Enterprise Resource Pool is just as important as the process of keeping the Enterprise Resource Pool accurate and up-to-date. Tracking significant changes to the resource information that is stored and managed in the Enterprise Resource Pool can be a full-time activity

Before you create your Enterprise Resource Pool for Project Server 2010, you must determine your starting point. The process of adding resources to the Enterprise Resource Pool varies according to whether you are:

  • Starting with new projects — Minimal preparation is necessary for this scenario. The process is simplified if you can gather all required resource information in a single document. You could make a list on paper. Then you would import your identified resources from Active Directory, or from a membership store if you were using forms authentication. Alternatively, you can gather this information by using Microsoft Excel. Then you would import the resulting spreadsheet into Project Professional 2010 and save it to the Project Server database.

  • Creating the enterprise resource pool — In this scenario, you are creating the Enterprise Resource Pool in Project Professional 2010. Using Project Professional 2010, connect to Project Server 2010 and check out the Enterprise Resource Pool. Enter the resources and save the Enterprise Resource Pool.

Plan custom fields

Project Server 2010 includes lookup tables and fields that you can customize. A custom field can contain information about a task, resource, or assignment. In Project Server 2010, fields that can contain customized data are text, flags, numbers, dates, cost, start and finish dates, and durations. You can customize these fields to obtain the information you want using formulas, specific value calculations, or graphical indicators.

You can write your own formulas, including references to other fields, to be calculated in a custom field. You can create a list of values for a custom field to ensure fast and accurate data entry. You can display a graphical indicator in a custom field instead of the actual data. That way, you can quickly see when the data in that field meets certain criteria, such as when the data exceeds a specified range or when resources are over-allocated. You can also create a hierarchical structure of custom fields for information in your project. For instance, you might want to associate your company's cost codes with your project data. After you create this structure and apply these custom fields to your data, you can easily use them to filter, sort, and group project data.

In Project Server 2010 there are two types of custom fields — local and enterprise. Local custom fields are used by the project manager within the scope of a particular project. Enterprise custom fields are used by the Project Management Office (PMO) to collect data for rollup reporting across the organization. For enterprise task and project custom fields, Project Server 2010 supports the notion of scoping to a specific program (collection of projects). In this way, an enterprise custom field can be defined that applies to a subset of projects.

Retire projects

There are certain activities that you should consider when retiring projects. Doing some basic clean-up when a project is retired can help to improve Project Server performance. Also, you can secure projects to ensure that only those who need the information — for example, for historical purposes — can see the projects. Deleting other enterprise objects that are not being used, such as resources and assignments, can help to prevent degradation of server performance.

Plan archiving

A number of enterprise objects can be backed up in PWA:

  • Projects

  • Enterprise Resource Pool and Calendars

  • Enterprise Custom Fields

  • Enterprise Global

  • View Definitions

  • System Settings

  • Category and Group Settings

Backing up these objects allows you to selectively restore specific items, and you can retain multiple versions of these items.

Backups are done on the Server Settings page under Database Administration. There are two methods available:

  • Schedule Backup

  • Administrative Backup

Administrative Backup allows you to back up enterprise objects at any time. Schedule Backup, as the name implies, allows you to back up enterprise objects daily at a scheduled time. We recommend that you back up your enterprise objects regularly and, if scheduled, at a time when server utilization is low. You should also have a plan for backing up your databases.

When an object is backed up, it is saved to the Project Server 2010 Archive database.

When a project is complete, there are a few options available for retiring the project.

  • Delete the enterprise objects from the Project Server 2010 Published and Draft databases, and retain copies in the Archive database.

  • Delete enterprise objects from all Project Server 2010 databases and rely upon database backups for archival.

  • Place the project in a special Project Server category that denies access to all but a few users.

Placing projects in a special Project Server category

To allow only certain users to view a retired project, you can create a special Project Server category for that purpose. Add the project and all users whom you do not want to have access to the project and set all of their permissions to deny. For more information about Users, Groups, and Categories, see Plan groups, categories, and RBS in Project Server 2010.

Plan cleanup

Deleting unused enterprise objects when a project is completed can help to prevent degradation of server performance. It is particularly beneficial for long term server performance to delete assignments. It is also a good idea to delete resources if they are no longer being used in the enterprise. Deleting unused enterprise objects when a project is completed also saves disk space on your database server.


Plan reporting and business intelligence (Project Server 2010)
See Also

Published: May 12, 2010

In Microsoft Project Server 2010, Project Server has been integrated with Excel Services in Microsoft SharePoint Server 2010 to make it easier to create custom reports. As part of this integration, blank data-connected spreadsheets and sample reports are provided. The data available for reporting includes timesheet custom fields, project properties, and portfolio planner and optimizer data. The default online analytical processing (OLAP) cubes can now be customized to only include data for a given department.

Reports using Office Excel 2007 or Excel 2010

Excel Reports are data-connected spreadsheets that you use to visualize the data retrieved from the Reporting Database or the OLAP databases. In Microsoft Excel 2010, you can present data in Tables, Pivot Tables, or Pivot Charts, and have access to additional visualization features. In Microsoft Office Excel 2007, you can only use Pivot Tables or Pivot Charts. Excel Reports use Office Data Connections to access and retrieve data from the Reporting database and OLAP databases.

Dashboards

Dashboards are enabled by using the SharePoint Server 2010 infrastructure and Excel Services integration.

Business Intelligence Center Dashboard pages are pages that can host Web Parts. Together with Web Parts, you can present Project Server data by using several different options:

  • Excel Services

  • Microsoft PowerPivot

  • Microsoft SQL Server Reporting Services (SSRS) 2005 or 2008

  • PerformancePoint Services in Microsoft SharePoint Server 2010

  • SharePoint Server 2010 Business Connectivity Services functionality

  • Microsoft Search Server 2010

Each of the six methods listed can be added to a dashboard page by using the relevant Web Part for the reporting function. For example, in order to put an Excel Report on a dashboard page, you would add an Excel Web Access Web Part to the dashboard page and link the Web Part to the specific Excel .xlsx file to show in the Web Part.

Dashboard pages have built in page filters which can be linked to Report Web Parts to filter the contents by user other information. Reporting Web Parts can also be linked to one another so that when you select a value in one report, the other connected reports are filtered by the current selection.

Security and access

The only user that has access to the Business Intelligence Center after you install Project Server is the account that was used for installation. You must grant access to other users before they can use reporting content.

Business Intelligence Center does not use Project Server 2010 security mechanisms. It uses SharePoint Server 2010 security for site access and the Secure Store Service for data access. This enables you to delegate Business Intelligence Center administrative duties to a non-Project Server user.

The Business Intelligence Center is a subsite of the Microsoft Project Web App (PWA) site. Although a subsite usually inherits its security permissions from the parent site, security inheritance can be disconnected to enable separate site security management. This allows the Business Intelligence Center to include Project Server 2010 users and other information users in the enterprise who need Project Server 2010 data but do not need access to the Project Server transaction system.

Three SharePoint Server 2010 site permission levels are required for enabling basic usage of the site:

  • Web Administrators Group — for Business Intelligence Center site administrators

  • Team members — for report viewers

  • Project managers — for report authors

These roles give the user access permissions to a set of items within the site. These items can be Reports, Report Templates, and Office Data Connections. For items that are Office Data Connections, the Secure Store credentials that are used for a given ODC provide access to data within the Reporting and OLAP databases.

If you must secure access to specific items within the site, such as restricting access to report folders, specific reports or Office Data Connections, you can customize security permissions on an exception basis by either creating a specific security group that helps secure these items or by editing the security permissions for each item. All of this is accomplished by using SharePoint Server 2010 security.

If you have implemented the Business Intelligence Center, we recommend that you do not rename or delete the default content or its containing folders. When patches and service packs are released in the future, the default content may be recreated.

Office Data Connections

Office Data Connections are external files that can be used by multiple Excel Reports. These files contain:

  1. The connection information that is needed to connect and access the correct target database.

  2. The security credentials needed to read data from the target database.

  3. The specific description of what data will be retrieved from the target database. This can include a Structured Query Language (SQL) select query.

Access to these files can be secured by using SharePoint Server 2010 security. You can also secure access to reporting data by creating separate Secure Store application definitions for each account.

Data Analysis with Microsoft SQL Server

Data Analysis requires Analysis Services, which is part of SQL Server 2005 and SQL Server 2008.

Data Analysis users

Users can use PWA to create and work with Data Analysis views and can use Microsoft Project Professional 2010 to work with Data Analysis views. In order for users to create and work with Data Analysis views, the following must be true:

  • Users must be assigned permission to access the Data Analysis pages in PWA that allow for interaction with Data Analysis, and they must have permissions to access the data that will be part of the Data Analysis view.

  • Users must be assigned permission to view Data Analysis from the Business Intelligence site in PWA or from Project Professional 2010.

In order to use the Data Analysis feature, users must be assigned the following permissions:

  • View Data Analysis This is a global permission that allows a user to view the Data Analysis by using PWA or Project Professional 2010.

  • Manage Project Web App Views This is a global permission that allows a user to create new views in PWA.

Enterprise Settings

Settings in the Project Server 2010 Enterprise Global Template and Enterprise Resource Pool can have a significant effect on the way that data is handled when users are using Data Analysis. Before you use Data Analysis, consider the following questions:

  • Has your organization defined Enterprise Project custom fields and Enterprise Resource custom fields?

  • Have you added all required resources to the Enterprise Resource Pool?

  • Have values been assigned to any of the Enterprise custom fields?

  • Have you assigned resources in the Enterprise Resource Pool to the correct Project Server security categories to allow for access to Data Analysis views? (If you import resources or synchronize the Enterprise Resource Pool with the Active Directory directory service, all resources are added to the Team Members security category.)

See Also

Other Resources

Excel Services overview (SharePoint Server 2010)


Plan for administrative and service accounts (Project Server 2010)

Published: May 12, 2010

Use this article to plan for the account requirements and recommendations for accounts that are required to install, configure, and use Microsoft Project Server 2010.

You must provide credentials for these accounts during Setup and configuration. This article does not discuss accounts that you do not have to configure or provide credentials for.

Administrative and service accounts

This section lists and describes the accounts that are required by Project Server 2010. The accounts are grouped according to scope. If an account has a limited scope, you might have to plan multiple accounts for this category.

Note:

All Project Server 2010 and Microsoft SharePoint Server 2010 service accounts must be granted interactive logon permissions for the computer where the service is running. By default, such permissions are normally granted when a new account is set up. However, you may have to make manual adjustments if your organization normally denies interactive logon permissions for service accounts.

The following table describes the standard account requirements for Project Server 2010.

Account Purpose Required permissions

Farm Administrator

This account is also known as:

  • Server farm account

  • Database access account

This account servers as the following:

  • The application pool account for the SharePoint Central Administration Web site

  • The process account for the SharePoint 2010 Timer (SPTimerV4) service

Log in with this account when you install SharePoint Server 2010 and Project Server 2010.

Important:

This account may already exist if you are deploying Project Server 2010 to an existing SharePoint Server 2010 farm. Project Server 2010 has additional requirements for this account. If you have already created a Farm Administrator account, make sure it has the required permission listed in this table.

This account must be a member of the local Administrators group on each application server in the farm.

Additional permissions are automatically granted for this account when Project Server 2010 is installed and when additional application servers are added to the farm.

A logon is automatically created for this account in SQL Server, and that logon is automatically added to the following SQL Server Server Roles:

  • dbcreator

  • public

  • securityadmin

  • sysadmin

Application Pool

Runs the application pools associated with each SharePoint Server 2010 service application. (This account may already exist if you are deploying Project Server 2010 to an existing SharePoint Server 2010 farm.)

The following SQL Server roles and permissions are automatically assigned to this account:

  • Database owner role for content databases associated with the Web application

  • Read/write access to the associated Service Application database

  • Read from the configuration database

Additional permissions for this account on front-end Web servers and application servers are automatically granted by Project Server 2010.

Workflow Proxy

Runs Project Server workflow activities. This account makes the Project Server Interface (PSI) calls associated with each workflow.

This domain account must also be configured as a Project Server user account that has the following permissions:

Global permissions:

  1. Log On

  2. Manage Users and Groups

  3. Manage Workflow and Project Detail Pages

Category permissions:

  • Open Project

  • Save Project to Project Server

Accounts and groups for business intelligence

In addition to the accounts listed earlier in this article, the following accounts and Active Directory directory service groups are required when you configure reporting for Project Server 2010.

Account | Purpose | Required permissions
Report Authors Group | Active Directory security group to which you add users who will create reports. | This group requires db_datareader permissions on the Project Server 2010 Reporting database.
Report Viewers Group | Active Directory security group to which you add users who will view reports. | None. (This group is used as part of Secure Store configuration.)
External Report Viewers Group | (Optional.) Active Directory security group for users who do not have a PWA user account but require access to the Project Server 2010 Business Intelligence Center to view reports. | This group requires read permissions to the Business Intelligence Center site.
Secure Store Target Application account | This account provides the credentials necessary for report viewers to view reports generated from data in the Project Server 2010 reporting database. This account is used as part of Secure Store configuration. | This account must have db_datareader permissions on the Project Server 2010 reporting database. We recommend that you add this account to the Report Authors Active Directory group described earlier in this section to give it the necessary permissions.


Podcast: Project Server planning (Project Server 2010)

Published: May 12, 2010

In this podcast, planning considerations for Microsoft Project Server 2010 are discussed by Microsoft Program Manager Treb Gatte and consultant, author, and Microsoft MVP Gary Chefetz. This is a high-level discussion that includes the following subjects:

  • Organizational readiness

  • Management commitment

  • Managing organizational culture shift

  • Defining business goals

  • Identifying and working with stakeholders

  • User training considerations

Download the podcast from the Microsoft Download Center (http://go.microsoft.com/fwlink/p/?LinkId=190420).

This podcast is 45 minutes long.

The presenters

Treb Gatte photo Treb Gatte, MBA

Treb Gatte is a Program Manager on the Microsoft Project Server product team. He is responsible for the Setup, Upgrade, and Business Intelligence features for Microsoft Project Server 2010. Previously, he was the Project Manager for Wachovia Bank's Information Technology implementation of Microsoft Office Project Server 2003. Treb has over 19 years of experience in project management, business process development, and software development management. He has a Bachelor of Science in Management from Louisiana State University and a Masters of Business Administration from Wake Forest University.

Gary Chefetz photo Gary L. Chefetz , MCTIP, MCT, MCTS

Gary Chefetz is the founder of MSProjectExperts, a Microsoft EPM Solution consultancy. He is co-author of the popular MSProjectExperts series covering Microsoft Office Project and Microsoft Office Project Server 2007 and author of Implementing Enterprise Portfolio Management with Microsoft Project Server 2002. He is co-author of the EPM Learning Series books Managing Enterprise Projects with Microsoft Office Project Server 2003 and Administering an Enterprise PMO using Microsoft Office Project Server 2003. Gary is active in the Project Server groups in the Microsoft communities.


Plan for Exchange integration (Project Server 2010)
See Also

Published: May 12, 2010

This article discusses integration with Microsoft Exchange Server, which enables Microsoft Project Server 2010 users to view Project Server tasks in Microsoft Exchange client software. This functionality replaces the Outlook add-in task status reporting functionality for non-time-phased tasks that is available in previous versions of Project Server.

Important:

Only assignment information is available in the Exchange client (Outlook, OWA, and so on). The only actions that a user can take in the Exchange client are viewing, updating, and deleting Project tasks. Creating or reassigning a new project task has to be done in Microsoft Project Web App (PWA).

Important:

SMTP and MAPI protocols are not supported. The Exchange Server functionality in Project Server 2010 uses Exchange Web Services.

Important:

Exchange Synchronization to Project Server does not work on a Project Server 2010 deployment configured to use claims authentication.

Planning Exchange integration with Project Server

Here is how Exchange integration with Project Server 2010 is achieved: Project Server uses the SSL protocol to communicate with a computer that is running Exchange Server. Project Server uses Exchange Impersonation on behalf of specific users to make calls between computers that are running Exchange and Project Server.

Tip:

For more information about Exchange Impersonation, see Configuring Exchange Impersonation (Exchange Web Services) (http://go.microsoft.com/fwlink/p/?LinkId=191025).

Exchange integration does not support viewing or updating of tasks that are tracked by time-phased time periods. However, users can still update their status by updating the % Work complete or Actual Work/Total Work. The Statusing class in the Project Server Interface (PSI) handles the distribution of work.

When PWA is in Single Entry Mode (SEM), the application continues to sync tasks to Exchange and accept updates on task changes from Exchange by using the Tasks page in PWA. The information is immediately available on the timesheet when in SEM. This is one reason why, when in Single Entry Mode, it appears that you can still update assignment on the Tasks page. It is due to the way Outlook functionality is implemented.

For Actual Work/Total Work and % Work complete, the following rules should apply:

Columns modified | Processing logic
% Work complete only | Apply % Work complete
Actual Work only | Apply Actual Work
Total Work only | Apply Total Work
% Work complete and Actual Work | Apply % Work complete
% Work complete and Total Work | Apply Total Work and then % Work complete
Actual Work and Total Work | Apply Total Work and then Actual Work
% Work complete, Actual Work, and Total Work | Apply Total Work and then % Work complete. Drop Actual Work.
Start Date and Finish Date alone | Update Total Work and let Project Server calculate % Work complete and Actual Work
Start Date and Finish Date together with the work and % Work complete columns | Update Total Work and then % Work complete

A mapping of Exchange client and Exchange Server Task fields to Project Task fields

The following table maps Exchange Task fields to Project Task fields. This will allow the default Outlook form to display these fields without installing the Project Task form:

Outlook task | Exchange Server | Project Server
Subject | itemSubject | PROJ_UID to PROJ_NAME: TASK_NAME
Actual Work | taskActualWork | ASSN_ACT_WORK
Due Date | taskDueDate | ASSN_FINISH_DATE
 | taskOwner Read Only in Exchange |
% Work complete | taskPercentComplete | MSP_ASSIGNMENTS to ASSN_PCT_WORK_COMPLETE
Start Date | taskStartDate | ASSN_START_DATE
Total Work | taskTotalWork | ASSN_WORK

Synchronizing Project Server data to Exchange Server

When project task information is updated through Project Publish or through a status update, a low priority queue job, "Syncing Tasks to Exchange," is created. This job updates or creates a task for the assigned resource's mailbox if the resource has been set up to synchronize their Project Tasks with the Exchange mailboxes. This job has lower priority than Project Publish jobs and Status Update jobs to allow all changes in the queue for a given task to be processed before Exchange Server is updated. When the job executes, it retrieves the latest changes to the task and the log and puts them into the mailbox for each resource that is assigned to the task. It also updates the task details. The Tasks will appear in folders that are named for the project that the task belongs to.

Note:

There are two queue jobs, one for Publish and one for Statusing:

  1. ExchangeStatusingSyncMessage — LowPriority

  2. ExchangeSyncPublishingMessage — This job is sent with the rest of the publishing group, which has a standard priority

See Also

Concepts

Deployment for Project Server 2010
Configure Project Server 2010 to work with Exchange Server 2007 SP2
Configure Project Server 2010 to work with Exchange Server 2010


Demand Management in Project Server 2010 (white paper)

Published: May 12, 2010

This white paper is written from an end user's perspective to discuss the Demand Management capability in Microsoft Project Server 2010. Demand Management is also known as Project Lifecycle Management (PLM). Demand Management represents a deliberate attempt to reconcile and combine multiple lifecycle management tasks within a single, unified approach. The specifications, assumptions, delivery, and costs dictate the project demand curves. The project demand curves will take a variety of shapes depending on the traceability path of related projects within any given portfolio.

The intended audience of this white paper is Department Managers, Division Directors, Program/Portfolio Directors and all who are responsible for overseeing multiple initiatives that involve diverse stakeholders and are tied to cost or corporate measurements. It is for Project Management Offices (PMOs), Project Managers (PMs), Product Managers and Domain Experts, Auditors, Line Managers, Project Sponsors, and Functional Managers who would like to do the following:

  1. Build, prioritize, and complete new projects for their business

  2. Align project selection with business objectives

  3. Operate with existing resources and use them effectively, efficiently, and in a secure environment

  4. Ensure timely completion for projects by passing them through stringent phase-wise approvals

Download as a .pdf file (http://go.microsoft.com/fwlink/p/?LinkId=191854)


Portfolio Server migration guide (white paper)

Published: August 5, 2010

The Microsoft Enterprise Project Management (EPM) Solution 2007 solution consisted of two server products: Microsoft Office Project Server 2007 and Microsoft Office Project Portfolio Server 2007.

The primary goal of Office Project Server 2007 is to enable day-to-day project management, and therefore most Office Project Server 2007 users are project managers and their project resources (Team Members, etc.). Microsoft Office Project Portfolio Server 2007 allows for Portfolio Strategy, Prioritization, and Optimization, and therefore the typical Portfolio Server users are project-management officers and company executives. Office Project Server 2007 and Office Project Portfolio Server 2007 are able to exchange data by using the Project Server Gateway.

In Microsoft Project 2010, the best-in-class portfolio management techniques from Microsoft Office Project Portfolio Server 2007 are incorporated into Project Server 2010. Together, they provide a single-server platform with end-to-end Project Portfolio Management capabilities to support strategic planning and project execution. The unified solution helps organizations achieve the following business goals:

  • Simplify Project Initiation and Business Case Development Project Server 2010 streamlines and centralizes project capture and initiation with a new Demand Management module, and it provides customizable governance workflows to ensure that projects are guided by the appropriate controls throughout their life cycles.

  • Select Project Portfolios That Align with Strategic Priorities Project Server 2010 helps organizations select projects that align with their business priorities by providing techniques to objectively prioritize business strategy, score competing projects, and run what-if analyses under diverse budgetary constraints.

  • Maximize Resource Utilization and Control The new capacity-planning module in Project Server 2010 helps analysts effectively manage resources by proactively identifying surpluses and deficits and rescheduling proposed projects to maximize available resources.

This document is intended for both IT Professionals and business users who use Microsoft Office Project Portfolio Server 2007 today and are considering an upgrade to Project Server 2010. This document outlines the various approaches and points out the useful resources in this area.

Download as a PDF file (.pdf) file http://go.microsoft.com/fwlink/p/?LinkId=197180 (1.5 MB)


Portfolio strategy with Project Server 2010 (white paper)
See Also

Published: June 10, 2010

This white paper is written from an end user's perspective to discuss the extensive Project Portfolio Management (PPM) capability in Microsoft Project Server 2010. It is not enough to complete individual projects, or even related programs on time, within scope, and on budget. Today's business environment requires that the work executed by an organization supports the organization's strategic business objectives and goals. This paper explores the topic of PPM from the top down in identifying the importance of pertinent business drivers and how those form vision, goals, objectives, and the eventual roadmap to project selection. And from the bottom-up perspective, the white paper shows the powerful features now within Project Server 2010 that are indispensible in matching these drivers to the appropriate projects and programs.

Microsoft Project 2010 was built for the business user. It uses advanced technology that lets end users and project stakeholders do the following:

  1. Identify and map key business drivers that encourage the concise definition of strategic goals and objectives for an organization

  2. Ensure that project and program selection is an objective, data-driven process

  3. Select, execute, and manage the appropriate initiatives

  4. Illustrate the value of PPM regardless of what type or size of organization

Download as a .pdf file (http://go.microsoft.com/fwlink/p/?LinkId=194203)

See Also

Other Resources

Demand Management in Project Server 2010 (white paper)


Project and SharePoint Server 2010 — Better Together (white paper)

Published: August 5, 2010

This white paper highlights the new features in Microsoft Project Server 2010. It is written for end users.

Managing projects is more than merely checking task status, schedules, and the critical path. It is a multi-faceted discipline. Projects succeed and thrive with effective collaboration and control over knowledge assets to deliver top and bottom-line business results. Keeping the Project Team and stakeholders up to date on all aspects of a project's status is important to managing stakeholders and completing a project successfully. Project Server 2010 brings together robust project, program, and portfolio management together with extensive collaboration features.

Microsoft SharePoint Server is a collaboration platform with a powerful set of capabilities and features. Enterprise Project Management (EPM) helps organizations select and deliver projects, reduce costs, and drive efficiencies. In most organizations, these activities contribute to a shared overall objective but will exist separate from one another.

The new feature set in Project Server 2010 creates a tool that provides multiple capabilities to include successful project management, program management and portfolio management. Now, Project Server 2010 can help guide an organization in selecting, planning, executing and managing its initiatives with the specific goals of meeting project success metrics, aligning with strategic objectives, and driving the organization toward its goals.

Download as a Microsoft Word (.doc) file http://go.microsoft.com/fwlink/p/?LinkID=197213 (5.3 MB)


Hitchhiker's Guide to Demand Management (white paper)

Published: September 9, 2010

This white paper is written from a Project Management Office perspective to discuss implementing the Demand Management capability in Microsoft Project Server 2010. It contains all the required technical information to get started implementing a full Demand Management solution with a Microsoft Enterprise Project Management deployment.

The intended audience of this white paper is IT professionals, Developers, the Project Management Office (PMO), and business users such as Project Managers (PMs), Product Managers and Domain Experts, Auditors, Line Managers, Project Sponsors, and Functional Managers that engage in the following:

  1. Build, prioritize, and complete new projects for their business

  2. Align project selection with business objectives

  3. Operate with existing resources and use them effectively, efficiently, and in a secure environment

  4. Ensure timely completion for projects by passing them through strict phase-wise approvals

Download as a .pdf file (http://go.microsoft.com/fwlink/p/?LinkId=200608)


Plan for authentication in Project Server 2010
See Also

Published: May 12, 2010

In this article:

  • Claims authentication and token issuance

  • Forms-based authentication

This article describes planning for security in a Microsoft Project Server 2010 Enterprise Project Management (EPM) Solution. This material is useful for Project Management Organizations (PMOs) and system administrators who are responsible for planning the deployment of a Project Server 2010EPM Solution.

The Project Server 2010 security model is largely inherited from the Microsoft SharePoint Server security model, by which users and groups (security principals) are granted permission to access security objects. The Project Server 2010 security model allows you to control and manage access to projects, resources, and reports stored in the Project Server 2010 content database; Project Web App pages; and features that are available in Project Server 2010 and Project Web App. In addition, the security architecture enables you to manage many users and projects easily by assigning permissions to groups of users and unique categories. This reduces the number of times that you need to update permissions in Project Web App.

Users can connect to Project Server in several ways:

  • Project Web App client

  • Microsoft Project Professional 2010 client

  • Third-party applications

  • Microsoft Outlook 2010 though Exchange Server integration

When accessing Project Server 2010 by any one of these methods, a user can be authenticated to Project Server 2010 though either Windows authentication, Claims authentication, or forms-based authentication.

Claims authentication and token issuance

Claims authentication is an authentication mechanism provided in Project Server 2010 by SharePoint Server 2010 that uses a security token that contains a set of identity assertions about an authenticated user. These assertions are attributes that are associated with a user's identity and can include a user name, a role, an employee ID, and various other custom attributes that can be used to determine authorization and permission levels for access to Project Server 2010 resources and data. Assertions are made up of a list of types and values. A type can be an employee name, for example, and a value can be a text string. Security tokens are issued and managed by a Security Token Service (STS). An STS encapsulates a collection of assertions, based on attributes specified by a policy, into a security token that can be used to authenticate and authorize a user.

The Security Token Service (STS) is a Web service that responds to authentication requests by issuing security tokens made up of identity claims that are based on user account information in attribute stores. An attribute store can be contained within Active Directory Domain Services, a SQL Server database, or an LDAP store. The content of each security token is determined by the attribute type requirements of the authentication requests that are agreed upon for an STS and the Project Server farm. An agreed-upon collection of claims and claim rules is known as a policy. Policies are available in a policy store and are accessed by an STS, based on the requirements of the calling Web application.

Caution:

Changing the authentication mode in IIS to certificate authentication is unsupported and results in a failure for any calls to projectserver.svc. For more information, see Configure Client Certificate Authentication in SharePoint 2010.

Forms-based authentication

Forms-based authentication is a term that is used to encapsulate any authentication model whereby a user enters a user name and password on a form that is then posted to an authentication server to process and verify the information. Project Server 2010 uses SharePoint Server 2010 for the extensions necessary to take advantage of ASP.NET in forms-based authentication. One important difference in Project Server 2010 from Microsoft Office Project Server 2007 is that forms-based authentication in Project Server 2010 uses the claims authentication infrastructure and requires that a claims mode Web application be set up in the SharePoint Central Administration Web site. There are two authentication store options available when using forms-based authentication with Project Server 2010:

  • SQL Server-based forms authentication requires creating an authentication store in SQL Server.

  • AD-LDAP-based forms authentication uses the Active Directory directory service as an authentication store and requires no additional configuration.

See Also

Concepts

Configure forms-based authentication in Project Server 2010

Other Resources

Plan authentication methods [SharePoint Server 2010]
Implementing Claims-Based Authentication with SharePoint Server 2010 (whitepaper)
Configure Claims Authentication [SharePoint Server 2010]


Configure forms-based authentication in Project Server 2010

Published: May 12, 2010

In this chapter:

  • Configure AD-LDAP-based forms authentication in Project Server 2010

    This article describes how to configure Microsoft Project Server 2010 forms-based authentication using Active Directory - Lightweight Directory Access Protocol (AD-LDAP). This procedure uses Claims authentication and an Active Directory server on the domain in which your Microsoft Project Server 2010 deployment is installed.

  • Configure SQL Server-based forms authentication in Project Server 2010

    This article describes how to configure Microsoft Project Server 2010 forms-based authentication using SQL-based forms authentication. This procedure uses Claims authentication and SQL Server on the domain in which your Microsoft Project Server 2010 deployment is installed.


Configure AD-LDAP-based forms authentication in Project Server 2010
See Also

Published: May 12, 2010

This article describes how to configure Microsoft Project Server 2010 forms-based authentication using Active Directory - Lightweight Directory Access Protocol (AD-LDAP). This procedure uses Claims authentication and an Active Directory server on the domain in which your Microsoft Project Server 2010 deployment is installed.

In order to perform these procedures, you must be member of the Project Server and SharePoint Server administrator groups on the local computer.

Configure AD-LDAP-based forms authentication in Project Server 2010

To configure SharePoint Server for forms-based authentication

  1. Create a new Web application in Claims mode.

    Note:

    A Web application that already exists in Windows Classic mode cannot be used.

  2. Go to the SharePoint Central Administration Web site.

  3. Click Application Management.

  4. On the ribbon, click New. A pop-up window appears.

  5. In the pop-up window, select the Claims Based Authentication option.

  6. In the pop-up window, in the IIS Web Site section, select a unique name and port number.

  7. In the pop-up window, in the Security Configuration section, set Allow Anonymous = No and set User SSL to Yes or No, depending on whether the site you are extending will be SSL-enabled.

  8. In the pop-up window, in the Identity Providers section, select the Enable Windows Authentication option and specify NTLM if Integrated Windows authentication will be used. Also select Enable ASP.NET Membership and Role Provider and specify a provider name and role manager.

  9. In the pop-up window, keep the default setting for Public URL.

    Note:

    This setting can be changed later if necessary.

  10. In the pop-up window, in the Application Pool section, choose to create a new pool with a pool name and the account that will be used.

  11. In the pop-up window, in the Database Name section, set the value for the SQL Server and database names for the content database.

  12. Click OK to close the window. A new IIS Web site will be created.

  13. Once you have received confirmation that the IIS Web application is created, you must create a new site collection at the root: Click Application Management in Central Administration, click Create Site Collections, and in the Web Application drop-down list, select the newly created claims-mode Web application.

  14. In the URL section, enter the root "/".

  15. Select the Blank Site template and specify a Windows user account in the Site Admin box.

  16. Click OK.

To configure the provider for forms-based authentication

  • Edit the connection strings to the AD-LDAP membership store. This data is provided in the .config files that are used by the application at every request.

    Note:

    The three Web configuration files to modify to connect to the AD-LDAP membership store are the .congif files for: Central Admin, Security Token Service, and the content Web application.

See Also

Concepts

Plan for authentication in Project Server 2010
Back up and restore the Project Server 2010 farm


Configure SQL Server-based forms authentication in Project Server 2010
See Also

Published: May 12, 2010

This article describes how to configure Microsoft Project Server 2010 forms-based authentication using SQL-based forms authentication. This procedure uses Claims authentication and SQL Server on the domain in which your Microsoft Project Server 2010 deployment is installed.

In order to perform these procedures, you must be member of the Project Server, Microsoft SQL Server, and Microsoft SharePoint Server administrator groups on the local computer.

Configure SQL Server-based forms authentication in Project Server 2010

To create the SQL authentication store

  1. Log on to any Windows Server on the farm running ASP.NET as a user with the DBCreate and SecurityAdmin permissions for the computer running SQL Server that will be used.

  2. At a command prompt, run %WINDIR%\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe -S<InsertSQLServerName>-d<InsertDBName>-E -A mr to create the authentication store database on the computer running SQL Server.

  3. Add all farm accounts to the DBO role for this newly created database.

To configure SharePoint Server for SQL authentication

  1. Create a new Web application in Claims mode.

    Note:

    A Web application that is already in Windows Classic mode cannot be used.

  2. Go to the SharePoint Central Administration Web site.

  3. Click Application Management.

  4. On the ribbon, click New. A pop-up window appears.

  5. In the pop-up window, select the Claims Based Authentication option.

  6. In the pop-up window, in the IIS Web Site section, select a unique name and port number.

  7. In the pop-up window, in the Security Configuration section, set Allow Anonymous = No and set User SSL to Yes or No, depending on whether the site you are extending will be SSL-enabled.

  8. In the pop-up window, in the Identity Providers section, check Enable Windows Authentication and select NTLM if Integrated Windows authentication will be used. Also select Enable ASP.NET Membership and Role Provider and specify a provider name and role manager.

  9. In the pop-up window, keep the default setting for Public URL.

    Note:

    This setting can be changed later if necessary.

  10. In the pop-up window, in the Application Pool section, choose to create a new pool with a pool name and the account that will be used.

  11. In the pop-up window, after Database Name set the value for the SQL server and database names for the content database.

  12. Click OK to close the window. A new IIS Web site will be created.

  13. Once you have received confirmation that the IIS Web application is created, you must create a new site collection at the root: Click Application Management in Central Administration, click Create Site Collections, and in the Web Application drop-down list, select the newly created claims-mode Web application.

  14. In the URL section, enter the root "/".

  15. Select the Blank Site template and specify a Windows user account in the Site Admin box.

  16. Click OK.

To configure the SQL authentication provider

  1. Edit the connection strings to the SQL Server database membership store. This data is provided in the .config files that are used by the application at every request.

    Note:

    The three Web configuration files to modify to connect to the AD-LDAP membership store are the .config files for the following: Central Admin, Security Token Service, and the content Web Application.

See Also

Concepts

Plan for authentication in Project Server 2010
Back up and restore the Project Server 2010 farm


Project Server and SharePoint Server security
See Also

Published: May 12, 2010

Microsoft Project Server 2010 is completely dependent on Microsoft SharePoint Server 2010 to support its user interface and farm topology. Security at the authentication level is tightly integrated between Project Server 2010 and SharePoint Server 2010, whereas user and group authorization is handled separately by Project Server 2010. When a project is published, if the server was configured to enable it, a project workspace site is created. You can configure Project Server 2010 to automatically synchronize Microsoft Project Web App (PWA) users with Project sites when they are created, when projects are published, and when user permissions change in PWA.

When you do this, users who have been added to the project or who have been granted Manage SharePoint Foundation permission in Project Server 2010 are added to at least one of four SharePoint Server 2010 groups:

  • Web Administrator (Microsoft Project Server) Users who have Manage SharePoint Foundation permission in Project Web App and are contributors to the project workspace site, meaning that they can create and edit documents, issues, and risks.

  • Project Managers (Microsoft Project Server) Users who have published this project or who have Save Project permission in Project Web App and are contributors to the project workspace site, meaning that they can create and edit documents, issues, and risks.

  • Team members (Microsoft Project Server) Users who have assignments in this project in Project Server 2010 and are contributors to the project workspace site, meaning that they can create and edit documents, issues, and risks.

  • Readers (Microsoft Project Server) Users who have been added to this project in Project Server 2010, but not assigned to tasks.

Project Server 2010 groups and SharePoint Server 2010 are synchronized when a project is published (assuming that the auto synchronize option is enabled) or the administrator selects a project workspace site on the Project Workspaces page and then clicks Synchronize.

Additional Project Server permissions that govern SharePoint Server 2010 access are as follows:

  • Log on Denies or allows user access to the Project Web App site and to project workspace sites.

  • View Project Workspaces Category permission that denies or allows user access to projects in the category.

  • Create object links Category permission that denies or allows user ability to create links between SharePoint Server 2010 objects and tasks.

There might be a circumstance where you want to grant people who are not members of the project access to the project workspace site. Anyone assigned to the Web Administrator group can create new users for a project workspace site. In addition to the four groups that were mentioned earlier, there are four default SharePoint Server 2010 groups. They are as follows:

  • Full Control Has all personal, site, and list permissions.

  • Design Can edit lists, document libraries, and pages in the Web site.

  • Contribute Can view pages and edit list items and documents.

  • Read Can view pages, list items, and documents.

Project workspace security groups are equal to the SharePoint Server 2010 security groups.

  • Web Administrator equals Full Control

  • Project Managers equals Design

  • Team members equals Contribute

  • Readers equals Read

See Also

Concepts

Security (Project Server 2010 settings)


Plan for performance and capacity (Project Server 2010)

Published: May 12, 2010

This is a newly published article set. We would like your feedback so that we can provide you with the best possible technical documentation. Please send any comments, questions, or concerns about the documentation to epmdocfeedback@microsoft.com.

This section covers capacity planning for Microsoft Project Server 2010.

  • About performance and capacity planning

    This chapter is about how to determine the hardware requirements for a single Microsoft Project Server 2010 farm.

  • Capacity planning in Project Server 2010 (white paper)

    This document provides guidance on the footprint that usage of Project Server 2010 has on topologies running Microsoft SharePoint Server 2010.

  • Run a Project Server 2010 performance test lab

    This section is a general guide for creating and running a performance test lab.


About performance and capacity planning
See Also

Published: May 12, 2010

This chapter is about how to determine the hardware requirements for a single Microsoft Project Server 2010 farm. It identifies the characteristics that will affect your capacity requirements and provides recommendations for the following:

  • Number of server computers in the server farm

  • Configuration of application server roles in the server farm

  • Hardware requirements for specific server roles in the server farm

Planning for capacity vs. availability

This chapter assumes that you have already planned for availability requirements by using the Plan for deployment (Project Server 2010) articles. As a result of using those articles, you will start the capacity planning exercise with a topology that meets your organization's minimum availability requirements. Given the topology you have selected, this chapter helps you determine the following:

  • Whether you have to add more servers to meet your goals for capacity and performance

  • Whether you have to adjust the configuration of application server roles to optimize capacity and performance of the server farm

  • Whether you have to plan for more than one server farm based on your capacity requirements

In some cases, an organization's requirements for availability can result in a server farm size that provides much larger capacity or performance than is otherwise required. If this is the case, capacity planning can focus on sizing the server hardware economically, instead of on adding additional server computers or scaling up with higher-performing hardware.

In many cases, the topology that meets an organization's minimum availability requirements is used as a starting point and server computers are added or scaled up to meet capacity and performance goals.

Capacity planning approach

There are many variables that affect capacity planning. For this reason, it can be difficult to receive a crisp answer to a straightforward question. Consequently, the most common answer to a capacity-related question is, "It depends …".

The capacity planning exercise provided in this chapter is designed to reduce the number of variables in consideration so that straightforward answers can be provided based on common scenarios. However, this chapter also includes the guidance for calculating your capacity and performance requirements based on your individual solution characteristics. This chapter includes two kinds of capacity planning guidance:

  • Recommendations for estimating capacity requirements A series of articles is provided, based on targeted scenarios. Each article defines a typical usage profile and identifies the key characteristics that will affect capacity and performance for the scenario. Based on the profile and key characteristics, predefined data lets you estimate capacity requirements for your solution.

  • Formulas and guidance for calculating specific capacity requirements Using this guidance, you can develop your own usage profile (or modify one of the scenario profiles) and calculate all of the variables that affect the capacity and performance of your solution.

Capacity planning process

Capacity planning focuses on three aspects of sizing your solution:

  • Capacity boundaries of the software Each of the features that can be implemented and the objects that can be created have scale limitations. Planning for capacity boundaries ensures that your solution design fits within the scale recommendations of the software.

  • Throughput targets Each kind of action that is performed by a server farm introduces a performance load on the server hardware. Primary actions include user operations, indexing of content, and operations tasks (such as backing up the databases). The use of specific features, such as Excel Calculation Services, although necessary for cube building, also adds a performance load. Developing throughput targets involves estimating or calculating the number of operations per second that a server farm must process in order to support the expected throughput load.

  • Data capacity Data capacity includes the expected volume of content databases and the configuration database. Each server role also has unique data requirements based on the solution, such as disk space for content indexes or for cached content.

See Also

Concepts

Plan for performance and capacity (Project Server 2010)
Run a Project Server 2010 performance test lab

Other Resources

Capacity planning in Project Server 2010 (white paper)


Capacity planning in Project Server 2010 (white paper)

Published: May 12, 2010

This performance and capacity planning document provides guidance on the footprint that usage of Microsoft Project Server 2010 has on topologies running Microsoft SharePoint Server 2010. For general information about how to plan and run your capacity planning for Microsoft SharePoint Server 2010, see Performance and Capacity Management (SharePoint Server 2010).

This document is intended as a starting point to help people who plan to deploy Project Server 2010. It helps you determine requirements and then design an appropriate hardware and software topology to match those requirements.

The document assumes that you have knowledge about the basic structure and functionality of a Project Server 2010 deployment. The Project Server 2010 SDK is an excellent starting point for learning more about the basic architecture of Project Server 2010.

Download as a Microsoft Word (.doc) file (http://go.microsoft.com/fwlink/p/?LinkId=191853) (403 KB)


Run a Project Server 2010 performance test lab
See Also

Published: May 12, 2010

Running a performance test lab against a Microsoft Project Server 2010 solution can be a very complex task, due to the various user interactions and system behaviors involved. This section of articles is designed as a general guide for creating and running such a performance test lab.

Types of load

The following are the main types of load that we typically have to reproduce in a performance test environment.

  1. User-initiated operations involving Microsoft Project Web App

  2. User-initiated operations involving Microsoft Project Professional

  3. Background operations

Testing strategies

Testing strategies can include independent loads or mixed loads composed of different operations. Measuring how the systems react to the load produced by a single specific operation by many simulated users at the same time can help determine a reference measure for peak periods of that specific operation. But mixed load strategies are more realistic and can be used to simulate how the systems react to several possible usage patterns. For example, if you are concerned about the timesheet submission load, which according to your specific scenario has a peak period on Friday afternoon for all users. You can then test the system by simulating timesheet submissions only, without any other simulated load. These results will provide a reference baseline as measured by maximum throughput (for example, how many timesheets can be submitted/processed per hour) of the system for the particular operation under investigation.

You may also want to test the system under a wider set of different operations at the same time. You could use usage profiles as similar as possible to your real scenario, ideally using historical logs coming from the production system, as a data source to determine the usage profiles to be tested.

Regardless of the overall testing strategies you want to adopt, the related articles listed in the "See Also" section describe in more detail how to plan and simulate the load types that belong to the three categories that were discussed earlier. Visual Studio Team System 2008 Test Edition provides the foundation for all the scenarios. By using Visual Studio Team System 2008 Test Edition, you can easily balance multiple load types in one single load test to run for a given period of time.

Please send any comments, questions, or concerns about the documentation to epmdocfeedback@microsoft.com.

See Also

Concepts

Plan a Project Server 2010 performance test lab
Key performance metrics for Project Server 2010
Set up the test environment Project Server 2010
Test user-initiated write operations involving Project Web App (Project Server 2010)
Test user-initiated operations involving Project Professional (Project Server 2010)
Test background operations (Project Server 2010)
Extract and analyze test data (Project Server 2010)


Plan a Project Server 2010 performance test lab
See Also

Published: May 12, 2010

Planning is the first and most important phase of every complex task, and performance testing is no exception to this rule. For specific information about how to plan your Microsoft Project Server 2010 installation, see Planning and architecture for Project Server 2010.

Before setting up the environment and running tests, you should thoroughly plan for all the aspects of what you will do. The following table summarizes some key points that you have to plan for.

Area Description

Hardware

Your lab configuration should be as close as possible to your existing or target production environment. For future reference, ensure that you keep track of the details of your hardware configuration before completing the lab.

Software

Plan for installing the latest fixes available for every software component in your lab. If you plan to run the lab for a long time (one month or more), you should also plan to update the systems when it is necessary with the latest security fixes. If you do not strictly have to change the software configuration of your systems, you should avoid changes during the lab timeframe, in order to maintain data comparability across different test runs performed at different times.

Storage

Your lab should have enough storage space to store:

  • Live data

    • Project Server databases

    • SharePoint Server databases

  • Backups

    • One backup set right after the lab setup

    • One backup set of Project Server and relevant SharePoint Server databases for every different data profile that you have to use

  • Test results

    The storage size required for every test run depends on the set of data that you collect, the sampling rate, and the test length

Network

Your lab environment should be put on an isolated network, in order to minimize the effect of extraneous network activities on your tests. One computer in the lab is usually configured as a bridge for remote access to the lab from the corporate network.

Directory Services

Because you have to simulate users who are accessing your lab environment, and you have to know the passwords for each simulated user, you must plan for the Directory Services to be used. You should plan for a dedicated organizational unit (OU) in an existing Active Directory directory service domain for managing the test user accounts, or for a dedicated Active Directory domain for your lab environment.

Test scenarios

Based on your overall goals for the performance lab, your test scenarios must be planned carefully. Consider the following elements for every test scenario:

  • Operations to be simulated (either a single operation or a mixed set of operations with different percentages)

  • Users and roles that have to be simulated for every operation (that is, how many users for every role involved, and so on)

  • Data profile to be created at the beginning of the test (that is, how many projects, tasks per project, assignments per resource, assignments per project, and so on)

  • Test duration and load pattern (that is, warm-up time, step load, and so on)

  • Data to be collected (that is, which counters from which servers, sampling rate, and so on)

  • Acceptance criteria and thresholds (that is, less than x% errors, average CPU usage < 60%, and so on)

Data profiles

Putting together all the test scenarios that you will perform, plan for your overall data population strategy by identifying the minimum number of data profiles that you will need for your tests. Data profiles typically include the following elements:

  • Users

    • User accounts

    • Resource Breakdown Structure (RBS)

    • Enterprise Resource Pool

    • Project managers and other roles

    • Security (authentication mode, groups, categories)

  • Enterprise Custom Fields

  • Projects

    • Tasks

    • Task dependencies

    • Team

    • Assignments

You should plan for an appropriate naming convention for all the test entities (users, projects, tasks, and so on).

Please send any comments, questions, or concerns about the documentation to epmdocfeedback@microsoft.com.

See Also

Concepts

Run a Project Server 2010 performance test lab
Key performance metrics for Project Server 2010
Set up the test environment Project Server 2010
Test user-initiated write operations involving Project Web App (Project Server 2010)
Test user-initiated operations involving Project Professional (Project Server 2010)
Test background operations (Project Server 2010)
Extract and analyze test data (Project Server 2010)


Key performance metrics for Project Server 2010
See Also

Published: May 12, 2010

Throughput and response time are two common metrics for measuring required, expected, or actual performance of a system. This article defines these two metrics, because they are important factors for measuring performance in Microsoft Project Server 2010.

Throughput

Throughput is a measure of the number of operations that the system can handle in a unit of time. Throughput is typically expressed in operations per second. However, you have to clearly determine what an "operation" is in every specific context. For example, take a Web page: You can think of the serving of a whole page as one operation, or you can think of all the individual HTTP requests that the server receives to serve the page as separate operations. (A Web page can contain images and other resources that are requested independently). These two definitions should clarify why you have to be clear about what an "operation" is when you deal with a throughput measure.

Estimating the required throughput for a system is a challenge that requires a deep and thorough understanding of the usage patterns of the users. An industry average suggests that one operation per second maps to 1,000 users, based on the following calculation:

  1. 1,000 users work on average at 10 percent concurrency.

  2. Therefore, on average there are 100 concurrent users on a 1,000-user system.

  3. For each of the 100 concurrent users, there are 100 seconds per operation per each user (the user "think time").

  4. If an active user pauses 100 seconds between operations, the user will generate 36 operations per hour (3,600 seconds in an hour divided by 100 seconds between user requests equals 36 operations generated by the user).

  5. If users average 36 operations per hour, and there are 100 concurrent users, the concurrent users will request on average a total of 3,600 operations per hour. Because there are 3,600 seconds in an hour, users will require a solution that can provide one operation per second (3,600 seconds per hour / 3,600 user operations per hour).

Of course, the assumptions of the previous calculation should be adapted to your specific scenario with regard to user concurrency, peak factors, and usage patterns. Be aware that a throughput of 10 operations per second does not mean that every operation is fully processed in 0.1 second, but only that the system is handling 10 operations in that second. That's why the "response time" is a separate metric, as important as throughput with regard to performance.

Response time

Independent of how many operations the system can manage at the same time, another measure of performance that is even more important to users is absolute response time. Response-time degradation can be a good indicator of capacity issues. There are a range of potential response-time bottlenecks, such as disk access, network I/O, memory, and processor problems. Response times depend significantly on several factors such as operation types, data profiles, systems configuration, and so on. It is also important that you define in detail the acceptance thresholds in response times for all the different operations that you are considering.

Please send any comments, questions, or concerns about the documentation to epmdocfeedback@microsoft.com.

See Also

Concepts

Run a Project Server 2010 performance test lab
Plan a Project Server 2010 performance test lab
Set up the test environment Project Server 2010
Test user-initiated write operations involving Project Web App (Project Server 2010)
Test user-initiated operations involving Project Professional (Project Server 2010)
Test background operations (Project Server 2010)
Extract and analyze test data (Project Server 2010)


Set up the test environment Project Server 2010
See Also

Published: May 12, 2010

This article describes the configuration and metrics involved in setting up a Microsoft Project Professional test environment.

Required software and configuration

In addition to the servers composing the Microsoft Project Server 2010 farm and the needed infrastructure services such as domain controllers, you should set up a Visual Studio Team System 2008 Test Edition controller agent topology. For more information about Visual Studio Team System 2008 Test Edition, see Controllers, Agents, and Rigs in the MSDN Library Online. We strongly recommend that you use dedicated hardware for the controller, the agent(s), and the database that stores test results in order to minimize the effect on systems being tested.

Similarly, in order to test operations involving Microsoft Project Professional, you should set up a test infrastructure that can automate client operations across multiple Terminal Services sessions and control test scenarios in a centralized manner. An example of such a test solution is the community-based project named Test Framework, which is available at Project 2010 Thick Client Test Framework (http://go.microsoft.com/fwlink/p/?LinkId=190449).

Directly after the setup is finished in your test environment, we recommend that you perform a full backup. Save the backup set so that you will always be able to revert to the baseline state if it is necessary.

Data profiles

When your Project Server 2010 farm is up and running, you can start to generate the data profiles that you planned for. A tool that you can use to help in this process is the community-based solution called EPM 2007 Test Data Population Tool, which is available at Project Server 2010 Test Data Population Tool (http://go.microsoft.com/fwlink/p/?LinkID=190449).

After you generate one specific data profile, perform a full backup of the Microsoft Project Server databases (and the Microsoft SharePoint Server content database if you include Project Workspaces in your test scenarios). Then save the backup set so that it will be available for recovery every time that you need to start a test run with that data profile. It's important that every time that you start a new test run you perform a recovery of the backup set that contains the appropriate data profile. By doing this you can ensure the same initial conditions of multiple test runs for the same scenario.

Data for simulating reality

Load tests must impersonate several different users in order to provide the most accurate simulation of reality. This can be achieved by using the data binding feature in Visual Studio Team System 2008 Test Edition so that every test instance will randomly select one user from the whole list. The same approach can be taken for binding other data to your coded tests, such as for example project names, resource UIDs, and so on.

The "Data Population Tool," "Thick Client Test Framework," and "PWA Web Tests" tools are part of the Microsoft Project 2010: Project Server Stress Testing Toolkit (http://go.microsoft.com/fwlink/p/?LinkID=190449), which can be downloaded from the MSDN Code Gallery. This toolkit provides samples that can be used to enumerate all the resources from the Enterprise Resource Pool and to generate XML files that contain key information that will be made available to the tests.

Please send any comments, questions, or concerns about the documentation to epmdocfeedback@microsoft.com.

See Also

Concepts

Run a Project Server 2010 performance test lab
Plan a Project Server 2010 performance test lab
Key performance metrics for Project Server 2010
Test user-initiated write operations involving Project Web App (Project Server 2010)
Test user-initiated operations involving Project Professional (Project Server 2010)
Test background operations (Project Server 2010)
Extract and analyze test data (Project Server 2010)


Test user-initiated write operations involving Project Web App (Project Server 2010)
See Also

Published: May 12, 2010

This article is about write operations that users can initiate by using only Microsoft Project Web App (PWA), without the involvement of Microsoft Project Professional on the client computer. Some of the most frequent operations in this category that you may want to test include the following:

  • Update status information on My Tasks

  • Submit a timesheet

  • Approve task updates

  • Approve timesheets

While Web tests alone are enough for read-only operations, for write operations some custom code that takes advantage of the Project Server Interface (PSI) is required.

When defining the test mixes, you should always plan one read-only test corresponding to every write test. For example, in order to submit timesheets, a user will always need to access the My Timesheets page.

Submit task updates

The "EPM Stress Test" Visual Studio solution provides a sample test method ("SubmitTaskUpdates") to implement the Submit Task Updates test. This solution is part of the "Project Server 2010 Performance Lab Kit" (discussed previously in Plan a Project Server 2010 performance test lab). The sample code picks a random assignment from a list of all the assignments in the system (pre-generated in an XML file). Then it impersonates the resource assigned to that assignment and submits a change of the progress (percent complete).

In order to test task-update submission operations realistically, however, you also have to add a Web test to hit the My Tasks page. You can set such a test by using the Web Test Recorder in Visual Studio (discussed previously in Set up the test environment Project Server 2010. The test mix between the Web test (page hit) and the unit test (actual task update submission) should be two page hits for every test submission.

Submit timesheets

The "EPM Stress Test" Visual Studio solution provides a sample test method ("CreateAndSubmitTimeSheet") to implement the Submit Timesheets test. This solution is part of the "Project Server 2010 Performance Lab Kit" (discussed previously in Plan a Project Server 2010 performance test lab). The sample code picks a random resource and a random period, and then creates the timesheet.

In order to test timesheet-submission operations realistically, however, you have to add a Web test to hit the My Timesheets page. You can set up such a test by using the Web Test Recorder in Visual Studio, (discussed previously in Set up the test environment Project Server 2010. The test mix between the Web test (page hit) and the unit test (actual timesheet submission) should be two page hits for every test submission.

Approve task updates

The "EPM Stress Test" Visual Studio solution provides a sample test method ("ApproveTaskUpdates") to implement the Approve Task Updates test. This solution is part of the "Project Server 2010 Performance Lab Kit" (discussed previously in Plan a Project Server 2010 performance test lab). The sample code picks a random project manager, gets the first pending task update from the list of task updates pending approval, and approves it. Then it submits the approval and finally republishes the affected project.

In order to test task-update approval operations realistically, however, you also have to add a Web test to hit the approvals page. You can set up such a test by using the Web Test Recorder in Visual Studio, (discussed previously in Set up the test environment Project Server 2010. The test mix between the Web test (page hit) and the unit test (actual task update approval) should be two page hits for every test submission.

Approve timesheets

The "EPM Stress Test" Visual Studio solution provides a sample test method ("ApproveTimesheets") to implement the Approve Timesheets test. This solution is part of the "Project Server 2010 Performance Lab Kit" (discussed previously in Plan a Project Server 2010 performance test lab). The sample code picks a random timesheet approver, gets a random timesheet from the list of timesheets pending approval, and finally approves it.

In order to test timesheet approval operations realistically, however, you also have to add a Web test to hit the approvals page. You can set up such a test by using the Web Test Recorder in Visual Studio, (discussed previously in Set up the test environment Project Server 2010). The test mix between the Web test (page hit) and the unit test (actual timesheet approval) should be two page hits for every test submission.

Please send any comments, questions, or concerns about the documentation to epmdocfeedback@microsoft.com.

See Also

Concepts

Run a Project Server 2010 performance test lab
Plan a Project Server 2010 performance test lab
Key performance metrics for Project Server 2010
Set up the test environment Project Server 2010
Test user-initiated write operations involving Project Web App (Project Server 2010)
Test user-initiated operations involving Project Professional (Project Server 2010)
Test background operations (Project Server 2010)
Extract and analyze test data (Project Server 2010)


Test user-initiated operations involving Project Professional (Project Server 2010)
See Also

Published: May 12, 2010

This article is about operations involving Microsoft Project Professional as the main user interface. The most frequent operations belonging to this category include the following:

  • Open a project

  • Save a project

  • Publish a project

Microsoft Project Server 2010 does not support multiple instances executing in the same user session. Therefore, in order to test many concurrent users, the use of Terminal Services is required unless you have dozens of servers. On the other end, the Visual Studio 2008 Test Agent cannot be instantiated in multiple sessions on the same user session. This would make it quite difficult to integrate Project Professional tests in Visual Studio Team System 2008 Test Edition. However a community-based tool capable of automating Project Professional tests inside multiple Terminal Services sessions has been developed and is available at Microsoft Project 2010: Project Server Stress Testing (http://go.microsoft.com/fwlink/p/?LinkId=190625) in the MSDN Code Gallery. The Thick Client Test Framework tool implements a controller-agent architecture that is conceptually similar to the Visual Studio 2008 Test Edition architecture. In all, the controller pushes information on a SQL Server database, while agents pull job information and update status information regarding their jobs from the same database. Every job is composed of one or more operations, implemented by using custom .NET components and taking advantage of the Project Professional client object model.

The three Project Professional tests described in the following paragraphs are implemented by using the Test Framework tool. Data collection is still performed with Visual Studio Team System 2008 Test Edition running at the same time.

Access the Project Web App home page

You can use the Web Test Recorder tool available with Visual Studio 2008 to record all the HTTP requests occurring when a user accesses the PWA home page. Once you have recorded the Web test, set up the credentials in order to simulate different users in the load scenario. Then let Visual Studio randomly select a user from a list for every test run. You can bind user credentials to a data source, which can read data from a database, an XML or CSV file, or any other data source that is convenient for you. As an example, you can use the Resources.xml file described above as the data source for user credentials. The same approach can be used for all the other tests as well.

Open projects

The sample code included in the "Thick Client Test Framework" in the "Project Server 2010 Stress Testing" solution shows how the opening of a project from Microsoft Project Professional can be automated. The code is dynamically loaded and run by the Test Framework agent. The Open function gets two parameters in input. The first parameter is the file name of the project to be opened. (Using '*' as the file name causes the function to automatically select a Project from the server-side list, in sequence order.) The second parameter is a Boolean to indicate whether the project should be open in read-only or in read-write mode. The function returns the number of milliseconds elapsed for the operation, or zero in case of error. The two parameters can be set through the controller UI.

Save projects

The Resource Center test is very similar to the Project Center test, because it also contains the JavaScript Grid control.

Access the My Tasks page

Microsoft Project Professional only sends the actual changes to the server when it saves. Therefore, in order to perform a meaningful save test you have to apply some changes to an opened project before you save it back. One's imagination is the only limit to what can be done for generating meaningful changes before you save. One simple example is to change the start date of the project, which typically affects all of the tasks in the project, thus generating a significant change set to be saved.

The sample code included in the Test Framework CodePlex solution shows several sample functions, which can be set to be run in sequence by defining a workflow in the controller application. Two examples are as follows:

  1. A ChangeStartDate function, which picks a random date in the [today ± 30 days] range and changes the project start date to the randomly selected date

  2. A Save function, which saves back the active project; the function gets one Boolean parameter as input that can be used to skip the save operation if the active project is opened in read-only mode.

Both of the functions return the number of milliseconds elapsed for the operation, or zero in case of error.

Publish projects

The sample code included in the "Thick Client Test Framework" in the "Project Server 2010 Stress Testing" solution shows how to automate the publishing of a project. The Publish function gets three parameters as input. The first parameter is a Boolean indicating whether the entire project (true) or only the changes (false) will be published. The second parameter indicates the URL for the optional URL for the project workspace to be provisioned. The third parameter is a Boolean indicating whether the publish operation needs to be skipped in case the opened project is in read-only mode. The function returns the number of milliseconds elapsed for the operation, or zero in case of error.

Please send any comments, questions, or concerns about the documentation to epmdocfeedback@microsoft.com.

See Also

Concepts

Run a Project Server 2010 performance test lab
Plan a Project Server 2010 performance test lab
Key performance metrics for Project Server 2010
Set up the test environment Project Server 2010
Test user-initiated write operations involving Project Web App (Project Server 2010)
Test user-initiated operations involving Project Professional (Project Server 2010)
Test background operations (Project Server 2010)
Extract and analyze test data (Project Server 2010)


Test background operations (Project Server 2010)
See Also

Published: May 12, 2010

This article is about operations that are not the direct result of any user action, but instead are running in the background as scheduled jobs. Some of the most frequent operations that belong to this category include the following:

  • Cube building

  • Active Directory synchronization

  • Project archiving

Normally, testing strategies for these operations only consist in the following things:

  1. Controlling when the operation under test starts

  2. Running a dummy test on Visual Studio Team System 2008 Test Edition at the same time in order to capture relevant data from the affected servers, and without any other load

A dummy test has to be run in order to start the collection of performance counter data and continue for the whole duration of the cube building process. An example of a dummy test that can be used for the purpose is included in the "EPM Stress Test" Visual Studio solution ("DoNothing" class), which is part of the "Project Server 2010 Performance Lab Kit."

The following sections provide more specific details for testing each of the above operations.

Cube building

In order to trigger a start of the cube building process, you can access the Cube Build Status page under Server Settings and use the Build Now button at the bottom of the page. This will cause activity on the computer that is running SQL Server, the Project Server application server and the SQL Server Analysis Services server.

Active Directory synchronization

The Active Directory synchronization feature in Microsoft Project Server 2010 can synchronize resource data in the Enterprise Resource Pool or user data in security groups. Management settings for the two types of synchronization targets are different.

To configure and start a synchronization targeted to the Enterprise Resource Pool, you can simply access the Active Directory Enterprise Resource Pool Synchronization page from Server Settings. Click the Save and Synchronize now button at the bottom of the page.

To configure and start a synchronization targeted to a security group, you must perform two steps. First, set the Active Directory group for every Project Server group that you want to synchronize. You begin this step by accessing the Manage Groups page from Server Settings. Then you click on a group name to enter the Add or Edit Group page, and then you click Find Group in the Active Directory Group to Synchronize section. The second step consists in configuring the synchronization parameters and scheduling. You can do this by clicking the Active Directory Synch Options button on the toolbar of the Manage Groups page; a dialog window opens. This allows you to set the options for group synchronization. You can use the Save and Synchronize now button at the bottom of this dialog window to start the synchronization task immediately.

Project archiving

Project archiving (or backup) can be triggered by accessing the Administrative Backup page from Server Settings (select Projects and then clicking Backup). Entities other than projects can also be archived and tested. The backup operation is en-queued and then processed by a Project Server application server. You can also expect significant activity on the computer that is running SQL Server.

See the Retire Projects article for more information about Project archiving in Project Server.

Identify different queue behaviors

When performing background operation testing it is important to understand and be able to identify different queue behaviors during your tests. The two key performance counters that should be monitored for this objective are as follows:

  1. QueueGeneral | Current Unprocessed Jobs (Current number of unprocessed jobs in the queue)

  2. QueueJobs | Jobs Processed / Minute (Number of jobs processed per minute)

Please send any comments, questions, or concerns about the documentation to epmdocfeedback@microsoft.com.

See Also

Concepts

Run a Project Server 2010 performance test lab
Plan a Project Server 2010 performance test lab
Key performance metrics for Project Server 2010
Set up the test environment Project Server 2010
Test user-initiated write operations involving Project Web App (Project Server 2010)
Test user-initiated operations involving Project Professional (Project Server 2010)
Test background operations (Project Server 2010)
Extract and analyze test data (Project Server 2010)
Manage security group synchronization with Active Directory in Project Server 2010
Active Directory Resource Pool Synchronization (Project Server 2010 settings)


Extract and analyze test data (Project Server 2010)
See Also

Published: May 12, 2010

Please send any comments, questions, or concerns about the documentation to epmdocfeedback@microsoft.com.

In addition to using Visual Studio Team System 2008 Test Edition itself to open and analyze data from past test runs, you should also analyze test data with more powerful tools such as Microsoft Excel.

Moving data from the lab to the test analysis database

Deploying the lab environment in an isolated network is a best practice. This approach affects a Microsoft SQL Server database that contains test data that is collected through Visual Studio Team System 2008 Test Edition. It will typically be in a separate network from the one that you are connected to when you perform most of the data analysis work. For this reason, it is common to have a process to move test data from the lab environment to a test analysis environment. This can be done with a SQL Server backup and recovery operation of the LoadTest database from one environment to another.

Extracting relevant data from the test database

The first thing to know when you are dealing with the LoadTest database is the test run IDs for the test runs stored in the database. The GetTestRunIDs.sql file in the "Project Server 2010 Performance Lab Kit" contains a Transact-SQL query that can be used to get the list of test run IDs from the database, together with other information useful to identify the test runs.

Once you have the test run ID of a test that you want to analyze, you then have to extract relevant information from the database. The main table for that purpose is LoadTestComputedCounterSample, which contains all the data samples for performance-counter data and key performance indicators from all the test runs. A sample Transact-SQL query that can be used to extract relevant data is included in the ExtractData.sql file in the "Project Server 2010 Performance Lab Kit." This query returns several result sets that can be easily copied and then pasted into an Excel worksheet.

Please send any comments, questions, or concerns about the documentation to epmdocfeedback@microsoft.com.

See Also

Concepts

Run a Project Server 2010 performance test lab
Plan a Project Server 2010 performance test lab
Key performance metrics for Project Server 2010
Set up the test environment Project Server 2010
Test user-initiated write operations involving Project Web App (Project Server 2010)
Test user-initiated operations involving Project Professional (Project Server 2010)
Test background operations (Project Server 2010)
Extract and analyze test data (Project Server 2010)


Project Server 2010 performance counters

Published: March 17, 2011

To help you determine when you have to scale up or scale out your Microsoft Project Server farm, use performance counters to monitor the health of the system. Use the information in the following tables to determine which performance counters to monitor, and to which process the performance counters should be applied:

  • Web servers

  • Database servers

  • Project Application Server performance counters

Web servers

The following table shows performance counters and processes to monitor for Web servers in your Project Server farm.

Performance counter | Apply to object | Notes
Processor Time | Total | Shows the percentage of elapsed time that this thread used the processor to execute instructions.
Memory Utilization | Application Pool | Shows the average utilization of system memory for the application pool. You must specify the correct application pool to monitor. The basic guideline is to determine peak memory utilization for a given Web application, and assign that number plus 10MB to the associated application pool.

Database servers

The following table shows performance counters and processes to monitor for database servers in your farm.

Performance counter | Apply to object | Notes
Average disk queue length | Hard disk that contains SharedServices.mdf | Average values larger than 1.5 per spindle indicate that the write times for that hard disk are insufficient.
Processor time | SQL Server process | Average values larger than 80 percent indicate that processor capacity on the database server is insufficient.
Processor time | Total | Shows the percentage of elapsed time that this thread used the processor to execute instructions.
Memory utilization | Total | Shows the average utilization of system memory.

Project Application Server performance counters

The following table shows performance counters and processes to monitor for your Application Server.

Performance counter | Apply to object
% Sql Retries / Day | ProjectServer:QueueGeneral
Active Job Processing Threads | ProjectServer:QueueGeneral
Active Job Processing Threads | ProjectServer:QueueGeneral
Average Unprocessed Jobs / Day | ProjectServer:QueueGeneral
Current Unprocessed Jobs | ProjectServer:QueueGeneral
New Jobs / Minute | ProjectServer:QueueGeneral
Sql Calls / Hour/Day | ProjectServer:QueueGeneral
Sql Calls / Minute | ProjectServer:QueueGeneral
Sql Retries / Minute | ProjectServer:QueueGeneral
% Jobs Failed / Day | ProjectServer:QueueJobs
% Jobs Failed / Hour | ProjectServer:QueueJobs
% Jobs Retried / Day | ProjectServer:QueueJobs
% Jobs Retried / Hour | ProjectServer:QueueJobs
Average Processing Time / Day | ProjectServer:QueueJobs
Average Processing Time / Minute | ProjectServer:QueueJobs
Average Wait Time / Day | ProjectServer:QueueJobs
Average Wait Time / Minute | ProjectServer:QueueJobs
Jobs Failed / Minute | ProjectServer:QueueJobs
Jobs Processed / Hour/Day | ProjectServer:QueueJobs
Jobs Processed / Minute | ProjectServer:QueueJobs
Jobs Retried / Minute | ProjectServer:QueueJobs
Average time taken for Project Open | ProjectServer:Winproj
Percentage of incremental save to full save | ProjectServer:Winproj
Winproj full open count in the last hour | ProjectServer:Winproj
Winproj full save count in the last hour | ProjectServer:Winproj
Winproj incremental open count in the last hour | ProjectServer:Winproj
Winproj incremental save count in the last hour | ProjectServer:Winproj


Plan groups, categories, and RBS in Project Server 2010
See Also

Published: May 12, 2010

Microsoft Project Server 2010 security is based on users, groups, and categories. This article addresses planning for groups and categories in your Project Server deployment.

In this article:

  • Permissions

  • Groups

  • Categories

  • Security templates

  • Resource Breakdown Structure

Included within this article is a series of video demonstrations illustrating and further describing the concepts associated with permissions, groups, categories, and RBS. Links to the videos are included in each section below. We recommend that you view the videos in the order of presentation in this article, as each video builds on the concepts discussed in previous videos.

Note:

These videos were created using Microsoft Office Project Server 2007. Though there have been some changes in Project Server 2010, the basic functionality around how Project Server security works remains the same.

Permissions

This video demonstrates how permissions work.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkID=168549). To download a copy of the file, right-click the link, and then click Save Target As.

A permission is the authority to perform a specific action within the context of Project Server. You can Allow, Deny, or not configure each permission in Project Server. For example, the Change Password permission can be allowed or denied for any given user or group. There are two types of permissions in Project Server:

  • Global Permissions grant users and groups the ability to perform actions throughout an instance of Microsoft Project Web App (PWA). Global Permissions are assigned on a user or group level.

  • Category Permissions grant users and groups the ability to perform actions on specific projects and resources. Category Permissions are assigned on a category level.

Permissions can be set in a number of different places within the Project Server 2010 administration menu. You can allow or deny permissions by selecting the check boxes in the Allow and Deny columns. If neither the Allow nor the Deny check boxes are selected, the default state is Not Allow. The Not Allow state does not prevent users from accessing the feature associated with the permission if they are granted permission in some other way. For example, a user might belong to one group for which permission is not configured (Not Allowed), but might be granted permission by means of membership in a group for which the permission is allowed. However, if the permission is explicitly denied anywhere, permission is denied everywhere for a particular user or group.

You can configure all Project Server 2010 permissions from the Project Web App Server Settings page. Permissions can be configured in the following ways:

  • Allow Enables users or group members to perform the actions associated with the permission.

  • Deny Prevents a user or group from performing the actions associated with the permission. Use caution when denying permissions. Note that if a user is denied a specific permission, the deny setting supersedes any Allow settings that might apply to other groups to which the user belongs. No permissions are set to Deny by default.

  • Not Allow If you select neither Allow nor Deny for a permission, the default state is Not Allow. If a user belongs to more than one group, and a permission is set to Not Allow for one group and is set to Allow (but not Deny) for another group, then the user is allowed to perform the actions associated with the permission.

It is important to consider when you are configuring a permission to Deny that the Deny setting supersedes any Allow settings that apply to the user for that permission by means of other group memberships. Limiting your use of the Deny setting can simplify permissions management for large groups of users.

Note:

The Deny setting enables you to deny access to functionality, because this setting overrides the Allow setting. Therefore, use caution when selecting the Deny check box. Select the Deny check box to prevent a user from outside the organization from accessing Project Server security objects or to deny functionality to a user or group).

For organizations that include a large number of users, assigning and administering permissions on an individual basis can be an overwhelming task. You can use groups to assign permissions to multiple users with a single action. Create the groups and define the set of permissions to associate with the groups as part of your initial Project Server 2010 deployment planning process, before you assign users to groups and groups to categories. After you define groups, the permissions associated with the groups, and group memberships, the day-to-day administration of users, groups, and categories involves adding users to or removing users from security groups. This helps to reduce the volume of day-to-day administrative tasks required, and can simplify troubleshooting permissions issues.

Note:

For a complete list of Project Web App global permissions, see Project Server 2010 global permissions, and for category permissions, see Project Server 2010 category permissions.

Groups

This video demonstrates how groups work.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkID=168587). To download a copy of the file, right-click the link, and then click Save Target As.

Groups contain sets of users who have similar functionality needs. For example, every project manager in a particular division within your organization may need the same set of Project Server permissions, while executives or resource managers might have different needs.

Define your groups by identifying common needs based on the areas of Project Server 2010 to which users in your organization need access. After you define your groups, you can add users to the groups and grant permissions to the groups; permissions assigned to groups apply to all of the users that the group contains. Using groups to control Project Server 2010 permissions simplifies security administration in Project Server. Group memberships can change frequently, but the access requirements for groups change infrequently.

Note:

Group membership consists of users only. Groups cannot contain other groups.

Users can belong to multiple groups according to their role in the organization and their access requirements. The following groups are created by default when Project Server 2010 is installed, each of which is assigned a set of predefined categories and permissions:

Group | Description
Administrators | Users have all global permissions as well as all category permissions via the My Organization category. This allows them complete access to everything on Project Server.
Executives | Users have permissions to view project and Project Server data. This group is intended for high-level users who need visibility into projects but are not themselves assigned project tasks.
Portfolio Managers | Users have assorted project-creation and team-building permissions. This group is intended for high-level managers of groups of projects.
Project Managers | Users have most global and category-level project permissions and limited resource permissions. This group is intended for users who maintain project schedules on a daily basis.
Resource Managers | Users have most global and category-level resource permissions. This group is intended for users who manage and assign resources and edit resource data.
Team Leads | Users have limited permissions around task creation and status reports. This group is intended for people in a lead capacity who do not have regular assignments on a project.
Team Members | Users have general permissions for using PWA, but limited project-level permissions. This group is intended to give everyone basic access to PWA. All new users are added to the Team Members group automatically.

Administrators usually assign permissions by adding a user account to one of the built-in groups or by creating a new group and assigning specific permissions to that group.

Note:

For a complete list of Project Web App global permissions, see Project Server 2010 global permissions, and for category permissions, see Project Server 2010 category permissions.

Categories

This video demonstrates of how categories work.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkID=168588). To download a copy of the file, right-click the link, and then click Save Target As.

Categories are collections of projects, resources, and views. Categories define the scope of the information accessible to a given user. A category is similar to a group in that it provides permissions to users. Unlike Global Permissions, Category Permissions are related to specific projects and resources. Additionally, categories include project and resource filters that can be used to determine which projects and resources the specified permissions apply to.

Groups and Categories are associated with each other to provide a complete set of permissions for each user. Each Group can be associated with one or more Categories and each Category can provide a different set of project- and resource-level permissions for the members of that group.

Each Project Web App instance includes the following default categories:

Category | Description
My Direct Reports | Allows users permission to approve timesheets for their direct descendants in RBS. This category is intended for managers who need the ability to approve timesheets.
My Organization | Contains all projects and resources and allows various levels of category permissions depending on associated group management. It also provides full access to all views. This category is intended to allow users to have visibility into everything on the Project Web App instance.
My Projects | Filtered to allow category permissions to users who own projects or are status managers on a project, are assigned as a resource to a project, or whose descendants in RBS are assigned to a project. This category is intended to allow users to have visibility into all project with which they or their descendants in RBS are associated.
My Resources | Allows most resource-level category permissions, filtered on resources who are descendants of the user in RBS. This category is intended to allow users to manage their resources as delineated in the RBS structure.
My Tasks | Allows users to see projects to which they are assigned. This category is associated with the Team Members group and is intended for everyone to have visibility into the projects to which they are assigned.

You can create custom categories to provide new ways to access data for projects, resources, and views. A large number of categories can be complex to administer. We recommend that you use categories sparingly.

Security templates

Security templates are predefined sets of permissions. Use security templates to simplify the process of granting permissions to groups of users who need access to the same data. Each Project Web App instance includes the following default security templates:

  • Administrator

  • Executive

  • Portfolio manager

  • Project manager

  • Proposal reviewer

  • Resource manager

  • Team lead

  • Team member

Security templates provide a means for you to quickly apply or reset predefined permission profiles to new or existing users, groups, and categories. By applying security templates, you can easily standardize the permissions that you assign according to users' role in the organization. Several predefined security templates are created by default when Project Server is installed. These align with the predefined groups. You can customize these security templates and create new security templates according to your needs.

Note:

When you change the settings for a security template, the changes are not automatically applied to the users and groups that the template was applied to.

Creating custom security templates requires planning. You must first identify the common Project Server 2010 usage patterns in your organization that are not reflected in the default Project Server 2010 security templates. This helps you to identify your requirements for custom security templates. Then, determine the permissions that the users who share the common Project Server 2010 usage patterns require. This defines the security template. Next, determine the set of projects, resources, views, and so on, that the users and groups require access to; this defines the security category. Create the custom security template and apply it to the group of users that share common usage patterns.

Resource Breakdown Structure

This video demonstrates of how RBS works.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkID=168589). To download a copy of the file, right-click the link, and then click Save Target As.

The Resource Breakdown Structure (RBS) is a hierarchical security structure typically based on the management reporting structure of your organization, although it can also be structured in other ways. The RBS can be an important element in your Project Server security model when it is used to define the reporting relationships among users and projects in your organization. When you specify an RBS value for each Project Server user, you can take advantage of the dynamic security options that can be defined for each security category.

The RBS structure is defined by adding values to the RBS custom lookup table that is built in to Project Server 2010. Once you define the structure, you can assign RBS values to individual users by setting the RBS property in the user's account settings page.

Once the RBS is configured, Categories can use RBS codes to dynamically determine which projects and resources particular users can view or access. The following tables list the security options that use RBS that are available in each Category.

Project options

Option | Description
The user is the Project Owner or the User is the Status Manager on assignments within that project | Users with permissions in the category where this option is selected can see projects on which they are a Project Owner or a Status Manager
The user is on that project's Project Team | Users with permissions in the category where this option is selected can see projects on which they are a resource
The Project Owner is a descendant of the User via RBS | Users with permissions in the category where this option is selected can see projects owned by their descendants in the RBS
A resource on the project's Project Team is a descendant of the User via RBS | Users with permissions in the category where this option is selected can see projects on which their descendants in the RBS are a resource
The Project Owner has the same RBS value as the User | Users with permissions in the category where this option is selected can see projects owned by other users with the same RBS value
Note:

The first two options (The user is the Project Owner or the User is the Status Manager on assignments within that project and The User is on that project's Project Team) are not related to the RBS, but they do offer a similar method of filtering which projects are visible to a user.

Resource options

Option | Description
The User is the resource | Users with permissions in the category where this option is selected can see themselves as a resource
They are members of a Project Team on a project owned by the User | Users with permissions in the category where this option is selected can see resources assigned to projects that they own
They are descendants of the User via RBS | Users with permissions in the category where this option is selected can see their descendants in the RBS
They are direct descendants of the User via RBS | Users with permissions in the category where this option is selected can see their direct descendants in the RBS
They have the same RBS value as the user | Users with permissions in the category where this option is selected can see other users with the same RBS value
Note:

The first two options (The User is the resource and They are members of a Project Team on a project owned by the User) are not related to the RBS, but they do offer a similar method of filtering which resources are visible to a user.

The options in the tables above can be configured when you create or modify a Category. For more information, see Manage categories in Project Server 2010.

See Also

Concepts

Manage security templates in Project Server 2010
Manage security groups in Project Server 2010
Manage Project Web App permissions in Project Server 2010

Other Resources

Using Project Server Security (http://go.microsoft.com/fwlink/p/?LinkId=205398)


Project Server 2010 upgrade overview

Published: May 12, 2010

This article contains an overview of how to upgrade to Microsoft Project Server 2010 from an earlier version of Project Server.

Important:

Upgrading from the Project Server 2010 public Beta to the Project Server 2010 release version is explicitly blocked and not supported. This restriction applies to both the in-place and database-attach upgrade methods.

Note:

Migrating Microsoft Office Project Portfolio Server 2007 data to Project Server 2010 is not covered in this document. For more information, see the model titled "Project Portfolio Server to Project Server 2010 Paths and Considerations" (PPS to PS2010 Migration Model.vsd).

Upgrade methods

You can upgrade to Project Server 2010 through two basic methods:

  • Database-attach upgrade

  • In-place upgrade

Database-attach upgrade

A database attach upgrade lets you "attach" restored copies of your Office Project Server 2007 databases to a new Project Server 2010 installation. Office Project Server 2007 farm databases are backed up and restored on Microsoft SQL Server, and the new Project Server 2010 farm points to these restored databases when the Microsoft Project Web App instance is created. When you connect to the databases from the new Project Server 2010 instance, the databases are upgraded to Project Server 2010.

There are two variations of the database attach upgrade:

  • Database attach full: Upgrades the four Office Project Server 2007 databases and the content database that contains the Project Web App site data.

  • Database attach core: Upgrades the four Office Project Server 2007 databases only.

A database-attach upgrade is required in two scenarios:

  • When you are migrating from a Office Project Server 2007 farm installed in a Windows Server 32-bit environment.

  • When you are migrating from a Office Project Server 2007 farm installed on a Virtual Migration Environment (VME).

    Note:

    For more information about the VME, see The Virtual Migration Environment (VME) in this article.

The advantage of doing a database attach upgrade is minimal downtime, because your Office Project Server 2007 farm can remain functional during the upgrade.

The disadvantages of doing a database-attach upgrade are as follows:

  • Server and farm settings are not upgraded and must be manually transferred if you want to preserve them from your old farm to your new one.

  • Any customizations must also be transferred and upgraded manually. Any missing customizations may cause unintended loss of functionality or problems for users.

  • You must budget for additional hardware on which to install Project Server 2010 and the required 64-bit Windows Server 2008 operating system.

For detailed instructions that describe how to use the database-attach methods to migrate from Office Project Server 2007 to Project Server 2010 see:

  • Database-attach full upgrade to Project Server 2010

  • Database-attach core upgrade to Project Server 2010

In-place upgrade

An in-place upgrade lets you install Project Server 2010 on the same hardware as your Office Project Server 2007 installation, and then migrate the content and settings in your server farm as part of a single process.

Important:

The Office Project Server 2007 installation that you are upgrading from must be running on a Windows Server 2008 64-bit operating system for you to do an in-place upgrade. Project Server 2010 is a 64-bit application, and it must be installed on a Windows Server 2008 64-bit operating system (Windows Server 2008 R2 or Windows Server 2008 with SP2).

The advantages of doing an in-place upgrade are as follows:

  • The upgrade can occur on the same computer.

  • Farm-wide settings are preserved and migrated.

  • Customizations are available in the environment after the upgrade process, although manual steps may be necessary to upgrade or rework them.

The disadvantages of doing an in place upgrade are as follows:

  • It can only be performed if Office Project Server 2007 is installed on a Windows Server 2008 64-bit operating system.

  • Project Server will be inactive during the upgrade, unlike a database attach upgrade, in which Office Project Server 2007 will be active during the upgrade because you are upgrading a copy of the Office Project Server 2007 farm databases.

    Important:

    An in place upgrade makes your Office Project Server 2007 installation permanently inoperative. You must make sure that you have a valid recovery plan in case the upgrade fails.

The scenario where an in-place upgrade would be most useful is one in which you are already running Office Project Server 2007 in a Windows Server 2008 64-bit environment.

For detailed instructions on how to use the in-place upgrade method to upgrade from Office Project Server 2007 to Project Server 2010 see In-place upgrade to Project Server 2010.

Migrating from Project Server 2003 to Project Server 2010

An additional migration path to Project Server 2010 is available from Microsoft Office Project Server 2003. The migration process can migrate your project data and, if it is required, your Project Workspace data. Migrating your data from Project Server 2003 is a two-step process:

  1. Migrate from Project Server 2003 to Office Project Server 2007

  2. Migrate from Office Project Server 2007 to Project Server 2010

Note that when we refer to upgrading from Project Server 2003, it is known as a "migration" process. In the traditional sense, upgrading from an earlier version is often thought of as an "in-place" process in which the application's binaries and data are upgraded from the earlier version to a newer version. For example, upgrading from Office Project Server 2007 to Project Server 2010 can be done through an in-place process. In contrast, upgrading from Project Server 2003 is a data migration process. In this process, Office Project Server 2007 is installed first (on the same computer as the earlier version of Project Server or on a different one). Then the Project Server 2003 data is migrated. There is no actual upgrade of the binaries when you are "upgrading" from Project Server 2003.

For more information about how to migrate from Project Server 2003, see Upgrade to Project Server 2010 from Project Server 2003.

Step 1: Migrating your data to Project Server 2007

When migrating from Project Server 2003 to Office Project Server 2007, there are two methods that you can use:

  1. Standard migration: Install the Office Project Server 2007 environment manually and then migrate your data from Project Server 2003 to the new environment.

  2. Virtual Migration Environment: Install the Virtual Migration Environment (VME) Hyper-V image (that contains your Office Project Server 2007 environment) to a Windows Server 2008 computer that is running Hyper-V, and migrate your data to the VME.

Both methods will produce the Office Project Server 2007 databases that contain your upgraded data, and optionally your project workspace data that is contained in a SharePoint Server content database. These will be required for the second step in the process: upgrading to Project Server 2010.

Step 2: Migrating your data from Project Server 2007 to Project Server 2010

The second half of this process requires you to migrate your data to Project Server 2010. There are three options, all mentioned previously:

  • Database-attach full upgrade: This option migrates your project data and your project workspace data. We recommend this option when you have to upgrade both.

  • Database-attach core upgrade: This option only migrates your project data. We recommend this option if you do not have to migrate your project workspace data.

  • In-place upgrade to Project Server 2010: This option upgrades your data and Office Project Server 2007 settings on the existing server. This option is available only to you if you migrated your data to a Office Project Server 2007 deployment on a Windows Server 2008 64-bit platform. You cannot use an in-place upgrade when you are using the VME.

For more information about how to migrate from Project Server 2003 to Project Server 2010, see Upgrade to Project Server 2010 from Project Server 2003.

The Virtual Migration Environment (VME)

The Virtual Migration Environment (VME) is a fully configured Office Project Server 2007 with SP2 environment packaged as a Hyper-V image. The VME can be run as a stand-alone environment for the sole purpose of migrating Microsoft Office Project Server 2003 data to the Office Project Server 2007 data format.

The VME was built to enable Project Server 2003 customers with a way to migrate to Project Server 2010 without having to set up an intermediate Office Project Server 2007 environment. The VME does not have to be added to your existing network, and the Project Server 2003 data can be added to the VME by using an external hard disk drive.

The VME image contains the following:

  • Office Project Server 2007 with SP2

  • Windows SharePoint Services 3.0 with Service Pack 2 (SP2)

  • Microsoft Office Project Professional 2007 with Service Pack 2

  • SQL scripts that have been developed to find potential upgrade issues.

  • Windows Server 2003 Release 2

  • Microsoft SQL Server 2005 Enterprise Edition

  • Office Project Server 2007 with SP2

The VME will be available for download on the Upgrade and Migration Resource Center for Microsoft Project Server 2010 around the product release date.

Backwards Compatibility Mode (BCM)

Backwards Compatibility Mode (BCM) is a feature in Project Server 2010 that assists in the upgrade of your Enterprise Project Management environment. Project Server 2010 accepts connections from the Microsoft Project Professional 2010 client, but it can also accept connections from Microsoft Office Project Professional 2007 with Service Pack 2 (SP2) if BCM is enabled in Project Server 2010. BCM is enabled automatically after you upgrade to Project Server 2010. By enabling BCM after you upgrade from Office Project Server 2007 to Project Server 2010, you avoid having to upgrade your Office Project Professional 2007 client computers at the same time. Because Project Server 2010 accepts connections from both Office Project Professional 2007 SP2 and Project Professional 2010 clients when BCM is enabled, you can decide to upgrade your clients later, and in batches (running in a mixed environment), if you want. When you have finished upgrading the clients to Project Professional 2010, you can turn off BCM in Project Server 2010 server settings, which will then allow for only Project Professional 2010 connections.

Important:

Once BCM is disabled, it cannot be re-enabled. Verify that you want to disable BCM if you are going to make the change.

Important:

Before you disable BCM, verify that all projects are checked in. If any projects are checked out when BCM is disabled, mismatched projects may exist (for example, the checked out projects will remain in compatibility mode). Projects in this condition can lead to problems with edits and data loss, and can cause Project Professional 2010 to stop responding.

Note:

Microsoft Office Project Professional 2003 cannot connect to Project Server 2010, even if BCM is enabled.

To disable Backward Compatibility Mode

  1. On the Project Server 2010 home page, click Server Settings.

  2. On the Server Settings page, in the Operational Policies section, click Additional Settings.

  3. On the Additional Settings page, in the Project 2007 Compatibility Mode section, clear the Enable Project 2007 Compatibility Mode check box.

  4. Click OK.

  5. After making the change, you must check out and open the Enterprise Global file in Microsoft Project Professional 2010. In the Enterprise Global file, make a very minor change (for example, dragging the splitter bar on the screen), save the file, and then check it back in. This is required to upgrade the Enterprise Global file to the newer version of the Microsoft Project Professional client.

Important:

The Enterprise Global file must be upgraded to the Project Professional 2010 client after BCM is disabled. This ensures that all new projects will be in native mode with all Project Professional 2010 features enabled. (All new projects are based on the Enterprise Global file). This also ensures that workflow will function correctly.

We recommend that BCM only be enabled as a temporary measure to help in the upgrade process. When Project Server 2010 is configured in Backwards Compatibility Mode, Project Professional 2010 clients that connect with Project Server 2010 have certain features that are disabled. These include the following:

  • Manually scheduled tasks are not available on the server or client.

  • Tasks cannot be set to inactive.

  • Font strikethrough is not available.

  • All departmental custom fields are enforced in Office Project Professional 2007.

  • Workflow-controlled custom fields are available as read-only.

All new features that are available in Project Professional 2010 (for example, Timeline, Team Planner, 32-bit colors) are available to Project Professional 2010 users, but not to Office Project Professional 2007 SP2 users.

Office Project Professional 2007 SP2 connecting to Project Server 2010 in BCM mode is blocked from providing functionality that requires loading a Project Web App page in the client. This includes doing approvals and opening enterprise resources. As a workaround, you can use Project Web App on a Web browser to do these functions until you are ready to upgrade to Project Professional 2010.

Additionally, workflow-controlled custom fields are not available in Office Project Professional 2007 SP2.

Note:

Project Web App access to Project Server 2010 requires that you use either Windows Internet Explorer 7 or Windows Internet Explorer 8 as your Web browser. For more information, see Plan browser support (Project Server 2010).


Plan for upgrade to Project Server 2010

Published: May 12, 2010

Now that you have learned how the upgrade process works by reading the article titled Project Server 2010 upgrade overview, you can start to plan an upgrade. This section contains articles that help you plan and prepare for upgrading from to Microsoft Project Server 2010.

In this section:

  • Review system requirements for upgrade (Project Server 2010)

    Review the requirements to help ensure that your environment can be upgraded to Project Server 2010.

  • Create an upgrade communications plan (Project Server 2010)

    Create a plan to coordinate and communicate with the upgrade team, users, and stakeholders.


Review system requirements for upgrade (Project Server 2010)

Published: May 12, 2010

Before you can upgrade your environment from Microsoft Office Project Server 2007 to Microsoft Project Server 2010, your servers must meet the following minimum requirements:

  • The hardware and software must meet or exceed the minimum system requirements to run the new version.

    This includes the requirement for 64-bit hardware and 64-bit versions of the operating system and Microsoft SQL Server. Before you start the upgrade process, make sure that the system meets or exceeds the minimum requirements in Hardware and software requirements (Project Server 2010). Before upgrading, determine how much production capacity that you must have in your upgraded environment and determine the hardware that you must have for an upgrade based on that information.

  • Office Project Server 2007 must be updated to Service Pack 2 and the October 2009 cumulative update.

    Your environment must be updated to at least Service Pack 2 of Office Project Server 2007 to run the upgrade process, either for an in-place or a database-attach upgrade. We recommend that you install the October 2009 Cumulative Update also. For more information about how to install service packs and updates, see Deploy Project Server 2007 updates (http://go.microsoft.com/fwlink/p/?LinkId=189218).

    Note:

    If you are also using Microsoft Office SharePoint Server 2007, you are also required to update it with Service Pack 2 and October 2009 Cumulative update.

  • Internet Explorer 7, 8, or 9 must be used for Microsoft Project Web App access to Project Server 2010.

    In order to access Project Server 2010 through Project Web App, users must have Internet Explorer 7, 8, or 9. If you attempt to use browsers such as Firefox and Safari to browse to Project Web App, the page will not load because these browsers are explicitly blocked. It is important to note this, especially if you are using other applications that are designed specifically to work with other browsers or versions of Internet Explorer.

    If your company plans to implement Windows 7 on the desktop and you have internal applications that require Internet Explorer 6, you may want to consider the XP mode feature of Windows 7 for Internet Explorer 6 support. You can then keep Internet Explorer 7 or 8 on the native desktop for Project Web App access to Project Server 2010.

    Another option is for users to access Project Server 2010 through a Terminal Server connection on which the host computer uses Internet Explorer 7, 8, or 9.

    Important:

    The Project Server 2010 Service Pack 1 update provides support for additional Web browsers to access Project Web App pages that are most frequently used by team members. The following are additional supported Web browsers:

    • Firefox 3.6.8+ on Macintosh OS X v10.6, Windows 7 (32-bit/64-bit), Windows Vista SP2, Windows XP SP3, Windows Server 2003 and UNIX/Linux

    • Google Chrome 6.0 on Windows 7

    • Apple Safari 5 on Mac OS X v10.6

    The following are team member pages that are supported with these additional browsers:

    • Project Web App (PWA) main default page (default.aspx)

    • All pages in the "My Work" section in the Quick Launch. This includes the following:

      • Tasks

      • Timesheets

      • Issues and Risks

    For more information about the Project Server 2010 Service Pack 1 update, see Deploy Service Pack 1 for Project Server 2010.

    Note:

    If you are using Internet Explorer 9 for PWA, you may encounter a small issue with editing grids on certain pages. On these specific pages, when the complete contents of an editable cell are deleted, data cannot be added to the cell until the page is refreshed. To resolve this issue, apply Project Server 2010 Service Pack 1 and make sure that you have the latest updates for Internet Explorer 9. For more information, see Plan browser support (Project Server 2010).

  • Prepare to upgrade or update your Project Professional client users for the upgrade to Project Server 2010.

    Project Server 2010 supports client connectivity from Microsoft Project Professional 2010. It also supports client connectivity from Microsoft Office Project Professional 2007 with Service Pack 2 (SP2), but only when backward compatibility mode (BCM) is enabled on Project Server 2010. If you have not upgraded your Office Project Professional 2007 users to Project Professional 2010, plan to give them the SP2 update so that they will be able to connect to Project Server 2010 after the upgrade from Office Project Server 2007. By default, BCM is enabled after upgrade, and it allows you to conveniently plan to upgrade your Office Project Professional 2007 SP2 clients to Project Professional 2010 over time. Note that when backward compatibility mode is enabled, some new Project Professional 2010 features are unavailable to these users. For more information about BCM, see the "backward compatibility mode" section of Project Server 2010 upgrade overview.

    Note:

    Project Server 2010 does not support client connectivity through Microsoft Office Project Professional 2003, even when BCM is enabled.

About these requirements

It is important that your hardware meet at least the minimum requirements that are listed in Hardware and software requirements (Project Server 2010); otherwise, you might encounter issues during the upgrade process. For example, if your database server has insufficient memory or processor power, it may be unable to keep up with the number of transactions that occur during the upgrade process, and the upgrade may fail.

We recommend that you use a trial upgrade in a test environment to determine exactly what hardware capacity you must have for an acceptable upgrade experience. If you experience capacity problems with your hardware during the trial upgrade, you can increase the capacity and repeat the upgrade until you are satisfied that you have found the optimal level of upgrade performance.

Important:

It is important to track the following three resource components for a server that is running SQL Server: CPU, memory, and I/O subsystem. When one or more of these components seems to have reached capacity, analyze the appropriate strategy based on the current and projected work load, and determine whether to add more resources or to scale out to a new server that is running SQL Server. In general, we recommend that you consider scaling out, in addition to adding more resources.


Create an upgrade communications plan (Project Server 2010)

Published: May 12, 2010

It is important that you communicate with users during the upgrade process to Microsoft Project Server 2010. Microsoft Project Web App users need to know what to expect when they visit the site again after upgrade, and Project client (Project Web App and Microsoft Project Professional) users need to know how they can help prepare for upgrade and what they will have to do after upgrade. All users who access Project Server need to know when the upgrade will occur. As part of the planning process, determine the following:

  • Who are the members of the upgrade team, what other stakeholders are involved, and who will be affected by the upgrade?

  • What information must the upgrade team have, and when?

  • What information must users and other stakeholders have, and when?

This article describes how to create your communication plan so that the upgrade team, the stakeholders, and the users know what to expect before, during, and after the upgrade.

In this article:

  • Who is on the upgrade team?

  • When and what to communicate to the upgrade team

  • When and what to communicate to site users

  • Gold Certified Partners

Who is on the upgrade team?

For small deployments, the upgrade team might consist of only one person. For larger deployments, on the other hand, several people with different roles can be required, as described in the following list:

  • Server administrators The server administrator performs most of the upgrade tasks. There must be at least one server administrator on the upgrade team because running the Setup wizard requires someone who is a member of the local Administrators group on each front-end Web server.

    Note:

    Farm administrators might not be local administrators for the server.

  • Project Server administrators Project Server administrators are trained to use the various Project Web App configuration and control features. They are responsible for modifying and maintaining general settings of the EPM application such as enterprise global codes, Project Web App views, Microsoft Project Professional global settings, and so on.

  • Database administrators If you have a separate database administration team, you must coordinate with it to schedule the upgrade and perform the upgrade, especially if you plan to use the database-attach upgrade method.

  • Server security teams You must coordinate with your security teams, such as the Active Directory directory services team, to verify accounts and permissions or to take advantage of the new policy settings that you can apply for Project Server 2010.

  • Client deployment team Communicate with client deployment teams to coordinate deployments of the new Project Professional 2010 client and server applications. The client deployment team also has to verify that all Project Web App users support the new browser requirements (Internet Explorer 7.0 or newer). Backwards compatibility mode (BCM) allows you some flexibility in scheduling your Project Professional 2010 client upgrade. This team should also contain a representative for the Project Management Office (PMO).

  • Developer staff If you have custom templates, Web Parts, Web services, or other custom elements associated with your Project Web App sites, you must work with the people responsible for developing or customizing those elements to ensure that you can create new versions of these custom elements or verify that these elements have been upgraded correctly. You must also ensure that custom applications developed to work with Project Server are still functional. This is especially true when you are doing a database-attach upgrade where many of the customizations will have to be redeployed manually to the new environment..

  • Project Server users This group can include general Project Web App users, team members, Project Managers, Timesheet managers, and all other people who access data in Project Server. You must communicate to both Microsoft Project Professional and Project Web App users about when the upgrade will occur and what they should expect with regard to changes. If you have existing Project Professional 2010 users, you must notify them about features that will be enabled when you disable backward compatibility mode in Project Server 2010. Prior to the upgrade process, you must inform users of tasks that they should do to ensure that the project data that they work with is in an upgradeable state. Communicating pre-upgrade tasks to end-users (for example, "ensure that all projects are checked in") helps prevent problems during the upgrade

  • Network engineers Network engineers must work with server administrator to do tasks such as creating new DNS entries, and so on.

  • Sponsors and other stakeholders You might have other people in your organization involved in the upgrade planning process. Make sure that you include them in your communication plan appropriately.

    Note:

    An upgrade team can include one or more members in each role, depending on your organization.

When and what to communicate to the upgrade team

In general, the server administrators and shared services administrators set the timeline for upgrade, and site owners are notified only when the process is about to begin. However, because team members have their own tasks to perform at particular points in the overall upgrade process, make sure that you have a solid plan to communicate the progress of the upgrade to all team members so that everyone knows when it is time to perform their particular tasks.

The whole upgrade team must work together to determine the following:

  • The upgrade approach to use The "Determine upgrade approach (Project Server 2010)" article contains information to help you decide which kind of upgrade to perform. The report generated by the pre-upgrade checker is also important to consider when you make this decision.

  • Dates and times to perform the upgrade We recommend (especially for an in-place upgrade) that you upgrade when site usage is low. For small single-server deployments, upgrade may be completed in less than a day. For larger deployments, such as server farms with large amounts of data, it can take much longer. There is no way to determine the precise length of time that will be required to upgrade. Because of this, it is very important to communicate with other team members involved in the upgrade process in addition to end-users. The day or days that you choose for upgrading should be far enough in the future that the upgrade team has enough time to complete all of the preliminary steps. When you plan the timeline, make sure that you schedule time to validate the upgraded Project Web App site and project data and also schedule time to implement any changes.

It is important to communicate with site owners, designers, and developers at the following points during the upgrade process:

  • Before the process starts, so that they know the general timeline and what their roles in the process will be.

  • After the upgrade, so that they can validate their upgraded data and the Project Web App site, and can make any changes that are needed.

When and what to communicate to site users

It is equally important to communicate with the Project Server users about the following issues:

  • When their sites will be upgraded In the case of an in-place upgrade, users must be informed that they will be unable to access data during the upgrade. You must also inform users to leave the data in a state that is ready for migration. (For example, they should check in all projects before the upgrade.) This helps eliminate problems that might occur during the migration.

  • When to expect Project Server 2010 to be ready to access "Ready to access" means that the upgrade team has not only upgraded but also verified the functionality after the upgrade. You must also prepare information that is required for users to connect to the upgraded version such as the new Project Web App URL for an upgrade performed by the database-attach method).

  • How the upgrade might affect them and what they should know about the new environment For example, the Project Web App site will look different and function slightly differently in the new user interface. You can prepare training materials, such as quick reference sheets, to prepare users for any changes that might have occurred in the processes they do in Project Server. You can also point them to available content, such as "What's New" articles, to learn about the new version.

  • How to get help If users find an issue with the data after the upgrade, where can they go for information or help?

Gold Certified Partners

Microsoft has certified several partner companies as experts for EPM deployments and system migrations. You can find partners on the Microsoft Web site by searching for EPM solution providers at Microsoft Solution Marketplace (http://go.microsoft.com/fwlink/p/?LinkId=187521).


Hardware and software requirements (Project Server 2010)

Published: May 12, 2010

This article describes in detail hardware and software requirements for Project Server 2010.

At a high-level, the key requirements for Project Server 2010 are as follows:

  • The 64-bit version of Windows Server 2008 Service Pack 2 or Windows Server 2008 R2

  • Microsoft SharePoint Server 2010 Enterprise version

  • For a farm deployment, database servers must be the 64-bit version of Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, Microsoft SQL Server 2008 R2, or Microsoft SQL Server 2005 with Service Pack 3 (SP3)

  • Microsoft Internet Explorer 7, Microsoft Internet Explorer 8, or Microsoft Internet Explorer 9 for Microsoft Project Web App user access

    Note:

    The Project Server 2010 Service Pack 1 update provides additional browser support for certain Project Web App team member pages. For more information, see the Software requirements section in this article.

This article describes more information about these key requirements and all additional hardware and software requirements for installing Project Server 2010.

In this article:

  • Overview

  • Hardware requirements—Web servers, application servers, and single server installations

  • Hardware requirements—Database servers

  • Software requirements

  • Access to applicable software

Overview

Microsoft Project Server 2010 provides for several installation scenarios. Currently, these installations include single server that uses built-in database installations and single server or multiple server farm installations.

Hardware requirements—Web servers, application servers, and single server installations

The requirements in the following table apply both to installations on a single server that has a built-in database and to servers that are running Project Server 2010 in a multiple server farm installation. For more information about recommended requirements for each Project Server 2010 server role (Web Front End Server, Application Server, Database Server) over different dataset scenarios, see Capacity planning in Project Server 2010 (white paper).

Important:

The minimum hardware requirements in the following table are recommended in which only the required services to run Project Server 2010 are enabled. Be aware that enabling additional SharePoint Server features (for example, search) in the farm may require more resources.

Component | Minimum requirement
Processor | 64-bit, four cores
RAM | 4 GB for developer or evaluation installation 8 GB for production use in a single server or multiple-server farm
Hard disk | 80 GB for installation You must have sufficient space for the base installation and sufficient space for diagnostics such as logging, debugging, creating memory dumps, and so on. For production use, you also need additional free disk space for day-to-day operations. Maintain twice as much free space as you have RAM for production environments.
Hyper-V Virtualization | Supported
Other | DVD drive

Hardware requirements—Database servers

The requirements in the following table apply to database servers in production environments that have multiple servers in the farm.

For more information about database server recommendations over various Project Server 2010 dataset scenarios, see the "Hardware and Recommendations" section of Capacity planning in Project Server 2010 (white paper).

Note:

Our definitions of small and medium deployments are those that are described in the "Reference Architectures" section in Capacity management and sizing for SharePoint Server 2010.

Component Minimum requirement

Processor

  • 64-bit, four cores for small deployments

  • 64-bit, eight cores for medium deployments

RAM

  • 8 GB for small deployments

  • 16 GB for medium deployments

For large deployments, see the "Estimate memory requirements" section in Storage and SQL Server capacity planning and configuration (SharePoint Server 2010).

Note:

These values are higher than those recommended as the minimum values for SQL Server because of the distribution of data required for a Microsoft SharePoint 2010 Products environment. For more information about SQL Server system requirements, see Hardware and Software Requirements for Installing SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=129377).

Hard disk

80 GB for system drive

Hard disk space depends on the size of the SharePoint content. For information about how to estimate the size of content and other databases for your deployment, see Storage and SQL Server capacity planning and configuration (SharePoint Server 2010).

Software requirements

The requirements in the following table apply to installations that have a single server that has a built-in database and to server farm installations that include a single server and multiple servers in the farm. This article also provides client connectivity requirements for Microsoft Project Web App and client/server compatibility with Microsoft Project Professional client versions.

Environment Minimum requirement

Database server in a farm

One of the following:

  • The 64-bit edition of Microsoft SQL Server 2012.

    Important:

    The SharePoint Server 2010 Service Pack 1 and Project Server 2010 Service Pack 1 updates must be installed to your Project Server 2010 installations in your farm in order to use SQL Server 2012 to host your farm databases.

    For more information about installing these updates, see Deploy Service Pack 1 for Project Server 2010.

    For more information about SQL Server 2012, see the SQL Server 2012 Microsoft TechNet home page.

  • The 64-bit edition of Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2. On the Cumulative update package 2 for SQL Server 2008 Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=165962) page, click the View and request hotfix downloads link and follow the instructions. On the Hotfix Request page, download the SQL_Server_2008_SP1_Cumulative_Update_2 file. When you install Microsoft SQL Server 2008 SP1 on Windows Server 2008 R2, you might receive a compatibility warning. You can ignore this warning and continue with your installation.

    Note:

    We do not recommend that you use CU3 or CU4, but instead CU2, CU5, or a later one than CU5.

  • The 64-bit edition of Microsoft SQL Server 2008 R2. This version includes updates in SQL Server 2008 Reporting Services (SSRS) and the PowerPivot for Excel feature. For more information about SQL Server 2008 R2, see Microsoft SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkID=179611). For more information about using SQL Server 2008 R2 with SharePoint 2010 products, see SQL Server 2008 R2 and SharePoint 2010 Products: Better Together (SharePoint Server 2010): white paper.

  • The 64-bit edition of Microsoft SQL Server 2005 with Service Pack 3 (SP3). On the Cumulative update package 3 for SQL Server 2005 Service Pack 3 (http://go.microsoft.com/fwlink/p/?LinkId=165748) page, click the View and request hotfix downloads link and follow the instructions. On the Hotfix Request page, download the SQL_Server_2005_SP3_Cumulative_Update_3 file.

Single server that uses built-in database

  • The 64-bit edition of Windows Server 2008 Standard, Enterprise, Data Center, or Web Server with SP2; or the 64-bit edition of Windows Server 2008 R2 Standard, Enterprise, Data Center, or Web Server. If you are running Windows Server 2008 without SP2, the Microsoft SharePoint Products Preparation Tool installs Windows Server 2008 SP2 automatically.

    You must download an update for Windows Server 2008 and Windows Server 2008 R2 before you run Setup, or Setup will not run. The update is a hotfix for.NET Framework 3.5 SP1 that is installed by the Preparation tool. It provides a method to support token authentication without transport security or message encryption in WCF. For more information and links, see the "Access to Applicable Software" section later in this article.

    Note:

    Project Server 2010 is supported for installation on computers running the Windows Server 2012 operating system. This requires installation of the Project Server 2010 Service Pack 2 (SP2) package, which contains updates to both Project Server 2010 and SharePoint Server 2010. For more information about the Service Pack 2 update, see Deploy Service Pack 2 for Project Server 2010.

  • KB979917 - QFE for SharePoint issues - Perf Counter fix & User Impersonation (http://go.microsoft.com/fwlink/p/?LinkId=192577)

    • For Windows Server 2008 SP2, download the Windows6.0-KB979917-x64.msu (Windows Vista) file.

    • For Windows Server 2008 R2, download the Windows6.1-KB979917-x64.msu (Windows 7) file.

    For information, see the related KB article Two issues occur when you deploy an ASP.NET 2.0-based application on a server that is running IIS 7.0 or IIS 7.5 in Integrated mode (http://go.microsoft.com/fwlink/p/?LinkId=192578).

  • Microsoft SharePoint Server 2010 Enterprise CAL Edition

    Note:

    SharePoint Server 2010 requires the following software installation components. These software prerequisites can be installed through the Microsoft SharePoint Products and Technologies 2010 Preparation Tool before the installation of SharePoint Server 2010 Enterprise CAL Edition. The Microsoft SharePoint Products and Technologies 2010 Preparation Tool can be accessed from the SharePoint Server 2010 Start page.

    The preparation tool installs the following prerequisites:

    • Web Server (IIS) role

    • Application Server role

    • Microsoft .NET Framework version 3.5 SP1

    • Microsoft SQL Server 2008 Express with SP1

    • Microsoft Sync Framework Runtime v1.0 (x64)

    • Microsoft Filter Pack 2.0

    • Microsoft Chart Controls for the Microsoft .NET Framework 3.5

    • Windows PowerShell 2.0

    • SQL Server 2008 Native Client

    • Microsoft SQL Server 2008 Analysis Services ADOMD.NET

    • ADO.NET Data Services Update for .NET Framework 3.5 SP1

    • A hotfix for the .NET Framework 3.5 SP1 that provides a method to support token authentication without transport security or message encryption in WCF.

    • Windows Identity Foundation (WIF)

      Note:

      If you have Microsoft "Geneva" Framework installed, you must uninstall it before you install the Windows Identity Foundation (WIF).

Note:

To install the prerequisites through the Microsoft SharePoint Products and Technologies 2010 Preparation Tool, ensure that you have an Internet connection, because some of these prerequisites are installed from the Internet. If the server does not have access to the Internet, see the Access to applicable software section for links to where you can download these updates to media.

Front-end Web servers and application servers in a farm

  • The 64-bit edition of Windows Server 2008 Standard, Enterprise, Data Center, or Web Server with SP2; or the 64-bit edition of Windows Server 2008 R2 Standard, Enterprise, Data Center, or Web Server. If you are running Windows Server 2008 with SP1, the Microsoft SharePoint Products Preparation Tool installs Windows Server 2008 SP2 automatically.

    You must download an update for Windows Server 2008 and Windows Server 2008 R2 before you run Setup, or Setup will not run. The update is a hotfix for.NET Framework 3.5 SP1 that is installed by the Preparation tool. It provides a method to support token authentication without transport security or message encryption in WCF. For more information and links, see the Access to applicable software section later in this article.

    Note:

    Project Server 2010 is supported for installation on computers running the Windows Server 2012 operating system. This requires installation of the Project Server 2010 Service Pack 2 (SP2) package, which contains updates to both Project Server 2010 and SharePoint Server 2010. For more information about the Service Pack 2 update, see Deploy Service Pack 2 for Project Server 2010.

  • KB979917 - QFE for SharePoint issues - Perf Counter fix & User Impersonation (http://go.microsoft.com/fwlink/p/?LinkId=192577)

    • For Windows Server 2008 SP2, download the Windows6.0-KB979917-x64.msu (Windows Vista) file.

    • For Windows Server 2008 R2, download the Windows6.1-KB979917-x64.msu (Windows 7) file.

    For information, see the related KB article Two issues occur when you deploy an ASP.NET 2.0-based application on a server that is running IIS 7.0 or IIS 7.5 in Integrated mode (http://go.microsoft.com/fwlink/p/?LinkId=192578).

  • Internet Information Services (IIS) 7.0

    Note:

    IIS 6.0 Management Compatibility must be enabled.

  • Microsoft SharePoint Server 2010 Enterprise CAL Edition

    Note:

    SharePoint Server 2010 will require the following software installation requirements. These software prerequisites can be installed through the Microsoft SharePoint Products Preparation Tool before the installation of SharePoint Server 2010 Enterprise CAL Edition. The Microsoft SharePoint Products Preparation Tool can be accessed from the SharePoint Server 2010 Start page.

    • Web Server (IIS) role

    • Application Server role

    • Microsoft .NET Framework version 3.5 SP1

    • Microsoft Sync Framework Runtime v1.0 (x64)

    • Microsoft Filter Pack 2.0

    • Microsoft Chart Controls for the Microsoft .NET Framework 3.5

    • Windows PowerShell 2.0

    • SQL Server 2008 Native Client

    • Microsoft SQL Server 2008 Analysis Services ADOMD.NET

    • ADO.NET Data Services Update for .NET Framework 3.5 SP1

    • A hotfix for .NET Framework 3.5 SP1 that provides a method to support token authentication without transport security or message encryption in WCF.

    • Windows Identity Foundation (WIF)

      Note:

      If you have Microsoft "Geneva" Framework installed, you must uninstall it before you install the Windows Identity Foundation (WIF).

    Note:

    To install the prerequisites through the Microsoft SharePoint Products Preparation Tool, ensure that you have an Internet connection, because some of these prerequisites are installed from the Internet. If the server does not have access to the Internet, see the Access to applicable software section for links to where you can download these updates to media.

  • SQL Server 2005 Management Object Collection

  • Microsoft SQL Server 2008 Management Objects

  • Microsoft Exchange Server 2007 with SP 2

    Note:

    Optional: Only required with Exchange integration.

Project Web App

  • Microsoft Internet Explorer 7, Windows Internet Explorer 8, or Windows Internet Explorer 9.

    For more information, including caveats about using Internet Explorer 9, see Plan browser support (Project Server 2010).

  • The Project Server 2010 Service Pack 1 update also supports the use of the following Web browsers for the My Work pages in Project Web App:

    • Firefox 3.6.8+ on Mac OS X v10.6, Windows 7 (32-bit/64-bit), Windows Vista SP2, Windows XP SP3, Windows Server 2003, and UNIX/Linux

    • Google Chrome 6.0 on Windows 7

    • Apple Safari 5 on Mac OS X v10.6

    The team member pages that are supported with these additional browsers include:

    • Project Web App (PWA) main default page (default.aspx)

    • All pages in the "My Work" section in the Quick Launch. This includes the following:

      • Tasks

      • Timesheets

      • Issues and Risks

    For more information about the Project Server 2010 Service Pack 1 update, see Deploy Service Pack 1 for Project Server 2010.

Project Professional client connectivity to Project Server 2010

  • Microsoft Office Project Professional 2007 with Service Pack 2 (SP2)

    Note:

    Office Project Professional 2007 (SP2) will connect to Project Server 2010 only when backward compatibility mode (BCM) is enabled on the server. For more information about BCM, see Project Server 2010 upgrade overview.

  • Microsoft Project Professional 2010

Important:

Microsoft Office Project Professional 2003 connectivity to Project Server 2010 is not supported, even when BCM is enabled on the server.

Microsoft Project Professional 2010 requirements

  • 700 megahertz (MHz) processor or higher

  • 512 megabyte (MB) RAM or higher

  • 1.5 gigabyte (GB) free disk space on hard disk

    Note:

    A part of this disk space will be freed after installation if the original download package is removed from the hard disk.

  • CD-ROM or DVD drive

  • Minimum 1024x768 or higher resolution monitor

  • Microsoft Windows XP with Service Pack (SP) 3 or later version, or Windows Server 2003 with SP1 or a later version

Reporting

Microsoft Office Excel 2007 or Microsoft Excel 2010 is required for report authoring. Project Web App users do not require Microsoft Excel to view reports because the reports are rendered in HTML through Excel Services in Microsoft SharePoint Server 2010.

To use reporting in Project Server 2010, you must install the SQL Server 2008 Analysis Management Objects (AMO) on each application server in the farm

Click to download the SQL Server 2008 Analysis Management Objects (http://go.microsoft.com/fwlink/p/?LinkId=130655)

Note:

Use the SQL Server 2008 version of AMO regardless of which version of SQL Server you are using to host your databases.

Note:

For more information about reporting in Project Server 2010, see Configure reporting for Project Server 2010. For more information about Excel Services, see Excel Services overview (SharePoint Server 2010).

Access to applicable software

To install Windows Server 2008 or Microsoft SQL Server, you can go to the Web sites listed in this section. You can install all other software prerequisites through the SharePoint Server Start page when you install SharePoint Server 2010 (which is required for the Project Server 2010 installation). The software prerequisites are also available from Web sites listed in this section. The Web Server (IIS) role and the Application Server role can be enabled manually in Server Manager.

In scenarios where installing prerequisites directly from the Internet is not possible or not feasible, you can install the prerequisites from a network share. For more information, see Install prerequisites from a network share (SharePoint Server 2010).

  • SharePoint Server 2010 Enterprise Trial (http://go.microsoft.com/fwlink/p/?LinkId=197414)

  • 2010 Server Language Packs for SharePoint Server 2010, Project Server 2010, Search Server 2010, and Office Web Apps 2010 (http://go.microsoft.com/fwlink/p/?LinkId=197415)

  • Windows Server 2008 R2 and SharePoint Server 2010: Better Together (white paper)

  • Windows Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=197426)

  • Windows Server 2008 R2 (http://go.microsoft.com/fwlink/p/?LinkId=197428)

  • SQL Server 2008 R2 (http://go.microsoft.com/fwlink/p/?LinkId=197429)

  • SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkID=179611)

  • SQL Server 2005 (http://go.microsoft.com/fwlink/p/?LinkId=197431)

  • Microsoft SQL Server 2008 SP1 (http://go.microsoft.com/fwlink/p/?LinkId=166490)

  • Cumulative update package 2 for SQL Server 2008 Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=165962).

  • Cumulative update package 5 for SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=197434). Download the SQL_Server_2008_RTM_CU5_SNAC file.

  • Microsoft SQL Server 2005 SP3 (http://go.microsoft.com/fwlink/p/?LinkId=166496)

  • Cumulative update package 3 for SQL Server 2005 Service Pack 3 (http://go.microsoft.com/fwlink/p/?LinkId=165748).

  • Microsoft Windows Server 2008 Standard SP2 (http://go.microsoft.com/fwlink/p/?LinkId=166500)

  • Windows Server 2008 with SP 2 FIX: A hotfix that provides a method to support the token authentication without transport security or message encryption in WCF is available for the .NET Framework 3.5 SP1 (http://go.microsoft.com/fwlink/p/?LinkID=160770)

  • Windows Server 2008 R2 FIX: A hotfix that provides a method to support the token authentication without transport security or message encryption in WCF is available for the .NET Framework 3.5 SP1 (http://go.microsoft.com/fwlink/p/?LinkID=166231).

  • Microsoft .NET Framework 3.5 Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=131037)

  • Microsoft SQL Server 2008 Express Edition Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=166503)

  • Windows Identity Framework for Windows Server 2008 (http://go.microsoft.com/fwlink/p/?LinkID=160381)

  • Windows Identity Framework for Windows Server 2008 R2 (http://go.microsoft.com/fwlink/p/?LinkID=166363)

  • Microsoft Sync Framework v1.0 (http://go.microsoft.com/fwlink/p/?LinkID=141237&clcid=0x409)

  • Microsoft Filter Pack 2.0 (http://go.microsoft.com/fwlink/p/?LinkId=166504)

  • Microsoft Chart Controls for Microsoft .NET Framework 3.5 (http://go.microsoft.com/fwlink/p/?LinkID=141512)

  • Windows PowerShell 2.0 (http://go.microsoft.com/fwlink/p/?LinkId=161023)

  • Microsoft SQL Server 2008 Native Client (http://go.microsoft.com/fwlink/p/?LinkId=166505)

  • Microsoft SQL Server 2008 Analysis Services ADOMD.NET (http://go.microsoft.com/fwlink/p/?linkid=160390)

  • KB979917 - QFE for SharePoint issues - Perf Counter fix & User Impersonation (http://go.microsoft.com/fwlink/p/?LinkId=192577)

    • For Windows Server 2008 SP2, download the Windows6.0-KB979917-x64.msu (Windows Vista) file.

    • For Windows Server 2008 R2, download the Windows6.1-KB979917-x64.msu (Windows 7) file.

  • ADO.NET Data Services Update for .NET Framework 3.5 SP1 (http://go.microsoft.com/fwlink/p/?LinkId=163519) for Windows Server 2008 SP2

  • ADO.NET Data Services Update for .NET Framework 3.5 SP1 (http://go.microsoft.com/fwlink/p/?LinkId=163524) for Windows Server 2008 R2 or Windows 7

  • Microsoft Silverlight 3.0 (http://go.microsoft.com/fwlink/p/?LinkId=166506)

  • SQL Server 2008 R2 Reporting Services Add-in for Microsoft SharePoint Technologies 2010 (http://go.microsoft.com/fwlink/p/?LinkId=192588)

Note:

For more information about SharePoint Server 2010 requirements, see Hardware and software requirements (SharePoint Server 2010).


Project Server 2010 architecture
See Also

Published: May 12, 2010

Microsoft Project Server 2010 is a true multi-tiered system that extends the architecture introduced in Microsoft Office Project Server 2007. The Project Server architecture includes Microsoft Project Professional 2010 and Microsoft Project Web App clients in the front-end tier. The front-end applications communicate with the middle tier only through the Project Server Interface (PSI) Web services, which in turn communicate with the business object layer. Business objects use the databases through the data access layer (DAL). Client applications do not directly access the primary databases; Project Server hides business objects and the DAL from clients.

This article contains the following sections:

  • General architecture

  • Web servers

  • Project Server Interface (PSI)

  • Business objects

  • Data Access Layer and databases

  • Publishing and server-side scheduling

General architecture

The main differences in general architecture between Project Server 2010 and Office Project Server 2007 are as follows:

  • Project Server 2010 requires Microsoft SharePoint Server 2010 Enterprise as an installation requirement. Similar to Microsoft Office Project Server 2007 farm deployment, when you are deploying Project Server 2010 to a farm, Project Server 2010 has to be installed on all application servers and all Web servers within the farm.

  • The PSI includes both the Windows Communication Foundation (WCF) interface and the ASMX interface for Web services.

  • The Project Server workflow platform is integrated in the PSI, business object layer, and DAL, and built on Windows Workflow Foundation (WF) in the SharePoint platform.

  • Project Server task, assignment, and assignment status data is integrated with Microsoft Exchange Server, instead of with a Microsoft Outlook add-in.

The figure that follows shows a generalized view of the Project Server 2010 architecture. It includes a Web server and a Project Web App instance on Project Server. As in Office Project Server 2007, there can be multiple instances of Project Web App running on one server.

Project Server 2010 Architecture
Note:

  • In Project Server 2010, you can use the WCF or the ASMX interface of the PSI. The Project Web App and Project Professional 2010 clients both use the WCF interface.

  • The PSI Forwarder in the architecture graphic consists of two components, a WCF Forwarder and a Web Service Forwarder. Clients that use the ASMX interface call the PSI through the Web Service Forwarder. Clients that use the WCF interface call the PSI through the WCF Forwarder.

  • The architecture graphic does not show that the Web server can be isolated by an additional firewall in a perimeter network (also known as a "demilitarized zone" or DMZ).

  • The SharePoint Web services site is part of SharePoint Server 2010 (not shown in the architecture graphic). The SharePoint Web services site includes the Project Service Application with the PSI virtual directory for the ASMX and WCF services. The Project Service Application in Project Server 2010 replaces the Shared Services Application in Office Project Server 2007.

The front-end tier includes third-party applications, Microsoft Project Professional, and Project Web App. Project Web App uses Internet Explorer to display Microsoft ASP.NET 3.5 pages. The Project Web App pages use Project Server Web Parts that communicate with the PSI and also use standard SharePoint Server 2010 Web Parts.

Client applications on separate computers call the PSI through service proxies. External clients that use the WCF interface access the PSI through http://ServerName/ProjectServerName/_vti_bin/psi/ProjectServer.svc. Clients that use the ASMX Web service interface use one of the Project Web App URLs, such as http://server1/pwa/_vti_bin/psi/project.asmx. If applications do not have intranet access to Project Server, they can use a Project Web App server in a perimeter network (not shown in the architecture graphic).

If they can directly access the Project Server computer, client applications and back-end components of line-of-business (LOB) Web applications can use PSI proxies that use the SharePoint shared service URL to the PSI Web services, such as http://server1:32843/ProjectServiceApplication/project.asmx. Port 32843 is the default port for the SharePoint Web services application in SharePoint Server 2010. Direct access to the Project Service Application virtual directory should be used only when an application has to use impersonation or run with elevated permissions.

The middle tier includes the PSI and the business logic layer, which consists of logical business objects that represent Project Server business entities. Business objects include Project, Task, Resource, Assignment, and so on. The PSI and the business logic tier are tightly coupled and are located on the same server. A client application calls the PSI Web services, and the PSI invokes business objects in the business logic tier.

The DAL provides communication between the middle tier and the database. All Project Server data is stored in Microsoft SQL Server databases. The Project Server databases are factored into the following stores: Draft, Published, Archive, and Reporting. Client applications can read the Reporting database for project data. Clients should use only the PSI to access the Draft, Published, or Archive databases. The Reporting Data Service (RDS, which is not shown in Figure 1) updates the Reporting database from published data in almost real time. In Project Server 2010, all of the Project Server databases can be located on separate servers.

The Project Web App components of Project Server also use the Microsoft SharePoint Foundation 2010 configuration database for project site setup and the content database for project site content such as custom pages, workflows, management settings, documents, and lists of issues, risks, and commitments. The SharePoint configuration and content databases support additional features for project management, such as project templates and workspaces, custom lists for team collaboration, and reports.

Web servers

You can install one or more Web servers within a corporate intranet to allow load distribution for intranet clients. When a client application uses a separate Web server, PSI calls are routed through a PSI Forwarder to the PSI Web services on the Project Server computer. The PSI Forwarder (either the WCF Forwarder or the Web Service Forwarder) performs the following functions:

  • Optimizes calls to the PSI from remote clients

  • Includes a server-based cache that works with the client-side active cache in Microsoft Project Professional to reduce round-trip calls to Project Server

After a user receives an authentication cookie from Project Server, the PSI Forwarder transparently sends requests to the PSI Web services on the Project Server computer. The PSI Forwarder improves performance and reliability over both the LAN and a WAN.

Project Web App is developed with ASP.NET 3.5. The visual elements in .aspx files (HTML, server controls, and static text) are separate from the programming logic in code-behind classes that are in compiled assemblies (.dll files). Site pages in Project Web App, such as the top-level page, Project Center, and Report Center, can be customized by using Web Parts. Application pages that do not have an Edit Page option in the Site Actions menu cannot be edited, such as the Server Settings page and Review Timesheet page.

Project Server Interface (PSI)

The PSI is the API of Project Server. The PSI object model exposes Project Server functionality to all external applications. Project Professional 2010, Project Web App, LOB, and other third-party applications use the PSI to access Project Server data in the Draft, Published, and Archive databases. The PSI is available through WCF services and through ASMX Web service calls by back-end LOB applications, or through a PSI proxy.

Web methods in the PSI typically produce or consume typed DataSet objects as the way to exchange information with the business objects. The PSI reference includes DataSet documentation.

Business objects

The internal object model of Project Server includes the business objects. Client applications access business objects only through the PSI, and only business objects can call the DAL.

Business objects are logical entities that can be classified into three types:

  • Core entities are objects such as projects, tasks, assignments, resources, and calendars. The core entities include basic business logic such as permissions and naming rules.

  • Business entities are objects such as timesheets, portfolios, and models. Business entities include additional business logic and usually are built from a combination of the core entities.

  • Support entities are objects such as security and validation.

The PSI handles mapping of the API to business objects.

Data Access Layer and databases

The DAL is internal to Project Server and is not exposed to external applications. The DAL translates between the logical business entity representation of the data and the physical database tables. Each logical entity is stored in several different tables. The DAL encapsulates the work that is required to manage connections, execute queries, and begin/commit/roll back transactions.

Project Server data is partitioned into four databases in SQL Server.

  • The Draft database contains tables for saving unpublished projects from Microsoft Project Professional and other applications. Project Web App does not show project data in the Draft database.

  • The Published database contains all of the published projects and enterprise resources, the enterprise global template, and other project templates. Published projects are visible in Project Web App. The Published database also contains tables that are specific to Project Web App (timesheets, models, views, and so on), and global data tables (custom fields, lookup tables, security, and metadata).

  • The Archive database saves backup versions of projects and other data.

  • The Reporting database (RDB) is the staging area for generating reports and OLAP cubes. Data in the Reporting database is comprehensive and is updated almost in real time. The tables and views are optimized for read-only report generation; for example, the RDB tables are de-normalized to provide redundant data and reduce the number of relational tables.

Entities such as Resource or Project can span multiple tables, and all tables for a particular entity have the same primary key. The primary key is a single column that uniquely identifies one instance of a particular entity. Unique identifiers are GUIDs.

Only the Reporting database schema is documented. You should access the Draft, Published, and Archive databases only through the PSI. You can add data tables, fields (properties), and entities that are not defined in the Project Server 2010 database schema to the Reporting database. If you add tables to the core databases, you must also provide the full stack of a custom assembly, Web service, business objects, and data access. You can easily modify the Reporting database; we recommend that you do not modify the core Project Server databases.

Publishing and server-side scheduling

Project Server 2010 supports both manual and automated project schedule updates. The default process is to update projects manually. That is, the project manager opens the project in Microsoft Project Professional, applies the changes, and then saves and publishes the project to make the changes available to everyone. The scheduling engine in Microsoft Project Professional calculates scheduling changes for manual updates.

The scheduling engine in Project Server enables automated project updates by using the PSI. Project Server allows the published version of a project to be updated while a project manager is using the draft version, by using the following steps:

  1. Project Server applies updates and reschedules the published version automatically.

  2. Project Server saves the update to apply to the draft version when either of the following events occurs:

    1. Microsoft Project Professional opens the project.

    2. Microsoft Project Professional tries to publish the project.

  3. If there is a conflict, the project manager must resolve it before the draft version can be published.

Warning:

There are some limitations and differences between the Project Server scheduling engine and the Microsoft Project Professional scheduling engine. For example, Project Server does not schedule subprojects or links to other projects, and does not calculate earned value fields. For more information, see the Project Scheduling on the Server section in Project Server Programmability (http://go.microsoft.com/fwlink/p/?LinkId=191606) in the MSDN Library Online.

See Also

Concepts

Hardware and software requirements (Project Server 2010)
What's new for IT pros in Project Server 2010


Plan browser support (Project Server 2010)

Published: May 12, 2010

This article describes supported Web browsers for connecting to Microsoft Project Server 2010 and other considerations that have to be made in planning for them.

Supported browsers

Microsoft Project Web App access to Project Server 2010 is only supported for the following Web browsers:

  • Windows Internet Explorer 9

  • Windows Internet Explorer 8

  • Windows Internet Explorer 7

In order to access Project Server 2010 through Project Web App, users must have Internet Explorer 7, Internet Explorer 8, or Internet Explorer 9. If you attempt to use other browsers such as Firefox and Safari for Project Web App access to Project Server 2010, the page will not load because these browsers are explicitly blocked. This is important to know, especially if you are using other applications that are designed specifically to work with other browsers or earlier versions of Internet Explorer.

Important:

The Project Server 2010 Service Pack 1 update provides support for additional Web browsers to access Project Web App pages that are most frequently used by team members. Following are the additional supported Web browsers:

  • Firefox 3.6.8+ on Mac OS X v10.6, Windows 7 (32-bit/64-bit), Windows Vista SP2, Windows XP SP3, Windows Server 2003 and UNIX/Linux

  • Google Chrome 6.0 on Windows 7

  • Apple Safari 5 on Mac OS X v10.6

Following are the team member pages that are supported with these additional browsers:

  • Project Web App (PWA) main default page (default.aspx)

  • All pages in the "My Work" section in the Quick Launch. This includes the following:

    • Tasks

    • Timesheets

    • Issues and Risks

For more information about the Project Server 2010 Service Pack 1 update, see Deploy Service Pack 1 for Project Server 2010.

Note:

For information about Web browsers supported for Microsoft SharePoint Server 2010, see Plan browser support (SharePoint Server 2010).

If your organization plans to implement Windows 7 on the desktop and you have internal applications that require Internet Explorer 6, you may want to consider the XP Mode feature of Windows 7 for Internet Explorer 6 support while keeping Internet Explorer 7 or Internet Explorer 8 on the native desktop for other applications, such as Project Server. For more information about the XP Mode feature of Windows 7, see Configuring and using Windows XP Mode (http://go.microsoft.com/fwlink/p/?LinkId=189565).

Another option is for your Project Web App users to access Project Server 2010 through a Terminal Server connection on which the host computer uses Internet Explorer 7 or Internet Explorer 8. For more information about Terminal Server connections, see Terminal Services in Windows Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=189566).

If you are upgrading from an earlier version of Project Server, you may have to upgrade your Project Web App users to newer versions of Internet Explorer, because previous versions of Project Server had different Web browser requirements:

Project Server version Supported Web browsers

Project Server 2010 with Service Pack 1

  • Internet Explorer 9

  • Internet Explorer 8

  • Internet Explorer 7

The My Work pages in Project Web App are also accessible through the following Web browsers:

  • Firefox 3.6.8+ on Mac OS X v10.6, Windows 7 (32-bit/64-bit), Windows Vista SP2, Windows XP SP3, Windows Server 2003 and UNIX/Linux

  • Google Chrome 6.0 on Windows 7

  • Apple Safari 5 on Mac OS X v10.6

Project Server 2010

  • Internet Explorer 9

  • Internet Explorer 8

  • Internet Explorer 7

Office Project Server 2007

  • Internet Explorer 9

  • Internet Explorer 8

  • Internet Explorer 7

  • Internet Explorer 6

Editing grids in Project Web App with Internet Explorer 9

If you use Internet Explorer 9 to access either Office Project Server 2007 or Project Server 2010, you may encounter a small issue with editing grids on certain pages. On these specific pages, when the entire contents of an editable cell are deleted, data cannot be added to the cell until the page is refreshed. If you modify the content of a cell on these pages, you must ensure that all the content of the cell is not completely removed. To completely replace the contents of the cell, select all the text contained within the cell and replace that with the new string. This issue affects the grid on the following pages:

Microsoft Office Project Server 2007 Microsoft Project Server 2010

  • My Tasks

  • My Timesheet

  • Proposals and Activities > New Activity

  • Status Report Request > Sections group

  • Server Settings > Enterprise Custom Fields and Lookup Tables > Edit Lookup Table > Lookup table group

  • Server Settings > Line Classifications

  • Server Settings > Time Reporting Periods à Create Periods

  • Server Settings > Cube Configuration > Calculated Measures group

  • Server Settings > Administrative Time

  • Status Report Request > Sections group

  • Server Settings > Enterprise Custom Fields and Lookup Tables > Edit Lookup Table > Lookup table group

  • Server Settings > Line Classifications

  • Server Settings > Time Reporting Periods > Create Periods

  • Server Settings > OLAP Database Management > Configuration > Calculated Measures group

  • Server Settings > Administrative Time

You can resolve this issue in Project Server 2010 by doing both of the following:

  • Apply Project Server 2010 Service Pack 1 to your Project Server 2010 deployment. For information about Project Server 2010 Service Pack 1, see Deploy Service Pack 1 for Project Server 2010.

  • Apply the latest updates for Internet Explorer 9 on your workstations that are using PWA.

Browser Security Settings

Project Web App must be added to your Trusted Sites list. Additionally, PWA requires the following browser security settings permissions:

  • Active Scripting

  • Binary and script behaviors Enables Gantt Bars to be drawn and enables the New button functionality in the Project Center.

  • Script ActiveX controls marked safe for scripting This feature is used when you edit the Enterprise Global template or calendars to invoke the update within Project Professional, or it is used when you choose to open resources or projects in Project Professional.

  • Run ActiveX controls and plug-ins This feature is used in conjunction with the "Binary and script behaviors" permission for the New and Open menus in the Project Center, the Open menu in the Resource Center, and in the process of opening the Enterprise Global Template and calendars.

Depending on your settings, you may be prompted to run "DB Query Support" from Microsoft, which is safe for you to allow. DB Query Support is beneficial when you invoke Project Professional and send data to it. IT is also beneficial when you invoke the New menu in the Project Center.

Editing Project owners in Project Web App by using Internet Explorer 9

If you are using Internet Explorer 9 in Project Web App, you cannot edit the Project Owner field on the Project Information page. In Project Server 2010, you can resolve this issue by applying Project Server 2010 Service Pack 1, and also by applying the latest updates for Internet Explorer 9 to your workstations that are using PWA.

The AJAX grid controls

Project Web App users who access Project Server 2010 will now view their pages by using the new AJAX grid controls. These are JavaScript grid controls that supports both read and write operations. They are faster than the previous controls, have cell validation, a rich color palette, and an interactive field chooser. Unlike the ActiveX controls previously used in Microsoft Office Project Server 2007, the AJAX grid does not require local installation and avoids security concerns about downloading unsigned controls.


Plan for Project Server 2010 Web Parts
See Also

Published: October 21, 2010

Microsoft Project Server 2010 is built on SharePoint Products architecture. Users who access Project Server 2010 through the Web interface (Microsoft Project Web App) are using pages that are composed of Web Parts, which are modular elements that present information on SharePoint pages.

A Web Parts page is an ASP.NET Web page that includes Web Parts controls that let users personalize the page, such as selecting the information to display. In SharePoint Products 2010, a Web Parts page can be used to combine data, such as lists and charts, and Web content, such as text and images, into a dynamic information portal. Web Parts are server-side controls that provide functionality to a site page. For example, the default Project Web App home page is a Web Parts page that contains the PWA Reminders Web Part and also contains room for additional Web Parts to be added.

Project Server 2010 includes a set of Web Parts that users can add to farm Web site pages after the product is installed. If an organization needs custom Web Parts, a developer can write custom ASP.NET Web Parts and ask you to install them to a deployment of Project Server 2010. This process should include testing and approval of code before the Web Parts are deployed.

For more information about how to develop Web Parts for Project Server 2010, see Developing Project Server 2010 Web Parts (http://go.microsoft.com/fwlink/p/?LinkId=204589) in the Project 2010 SDK in the MSDN Library Online.

For more information about how to manage Web Parts pages in SharePoint Server 2010, see Manage Web Part pages (SharePoint Server 2010).

This article contains the following sections:

  • Project Server 2010 pre-installed Web Parts

  • Scenarios for integration of Project Web App Web Parts

  • Using the SimpleUI parameter for viewing PWA pages using the Page Viewer Web Part

For more information about Project Web App Web parts in Project Server 2010, see the following articles:

  • Add or remove Project Web App Web Parts for a site in the Project Web App site collection (Project Server 2010)

  • Add Project Web App Web Parts to a site not within the Project Web App site collection (Project Server 2010)

  • Upgrade considerations for Project Web App Web Parts

Project Server 2010 pre-installed Web Parts

There are 18 Web Parts that are installed with Project Server 2010 that provide Project Server 2010 functionality. They are available in the Web Parts Gallery in the Project Web App category folder. The following table describes the 18 predefined Web Parts that are available with your Project Server 2010 installation.

Web Part name | Description
Approval Center | Displays task updates for approval and rejection submitted to you by team members.
Issues | Displays active issues that are assigned to you.
My Queued Jobs | Displays queue status for jobs generated by you.
My Schedule | Displays a calendar view of tasks assigned to you.
My Tasks | Displays tasks assigned to you.
My Timesheet | Displays your timesheet information.
Project Center | Displays a list of projects on the server.
Project Details | Displays more information about specific projects on the server.
Project Fields | Displays a list that may consist of project custom fields, project summary fields, and project inherent fields such as project name, description, or owner. The list is editable. This Web Part can only be used within the Project Detail Pages infrastructure.
Project Fields (Backwards Compatible) | Displays all enterprise custom fields except fields whose behavior is controlled by workflow. Use this Web Part to emulate the "Edit Project Properties" page used in Microsoft Office Project Server 2007. This Web Part can only be used within the Project Detail Pages infrastructure.
Project Sites | Displays a list of project sites that are available to each user. This Web Part can only be used within the Project Detail Pages infrastructure.
Project Strategic Impact | Displays the business driver ratings information for a project. This Web Part can only be used within the Project Detail Pages infrastructure.
Reminders | Displays a list of user item reminders.
Resource Assignments | Displays assignment information where the resources have been assigned.
Resource Center | Displays a list of resources on the server.
Risks | Displays active risks that are assigned to you.
Team Tasks | Displays team assignments.
Workflow Status | Displays workflow status information for a project. This Web Part can only be used within the Project Detail Pages infrastructure.
Note:

As noted in this table, some Project Web App Web Parts can only be used within Project Details Pages (PDPs). Project Detail Pages are Web Parts pages in Project Server 2010 that can be used to display or collect information from the user. They are used in different stages of the Demand Management feature in Project Server 2010. For more information about Demand Management, see the Demand Management in Project Server 2010 Resource Center (http://go.microsoft.com/fwlink/p/?LinkId=204588).

Scenarios for integration of Project Web App Web Parts

Project Web App Web Parts can be integrated into Web Parts pages in several scenarios. The following table specifies which scenarios are supported and not supported for the integration of PWA Web Parts.

Note:

For the purposes of this example, http://contoso/PWA is considered the PWA root site.

Scenario | Supported | Not supported
Non-Project site in the Project Web App site collection. (For example, http://contoso/PWA/Proj1TeamBuilder.) | X |
Project site in the Project Web App site collection. (For example, http://contoso/PWA/Project1ProjectWorkSpace.) | X |
Site that is not in the Project Web App site collection. (For example, http://contoso/SharePointSite1.) | X |
Site that is located on a different Project Web App instance. (For example, http://contoso/PWA1 using a PWA Web Part to view data in http://contoso/PWA.) | X |
Site on a different SharePoint farm. (For example, http://liteware/PWA trying to use a PWA Web Part to view PWA data in http://contoso/PWA.) |  | X

You cannot use Web Parts to view Project Server 2010 data from a different farm. For example, you cannot use a Project Center Web Part from Farm A on a Web site that is located on Farm B.

Note:

For information about resolving Project Web App Web Parts issues that can occur in Web Part integration scenarios after you upgrade to Project Server 2010, see Upgrade considerations for Project Web App Web Parts.

Using the SimpleUI parameter for viewing PWA pages using the Page Viewer Web Part

The SimpleUI parameter is a URL option that can be used to hide or show parts of pages in Project Web App. URL options can reduce the amount of screen space that Project Web Access uses or simplify the page view for different user tasks. The SimpleUI parameter enables you to remove common elements in Project Web App pages so that the page display matches your user requirements. For example, changing the Project Web App home page URL from http://contoso/pwa/default.aspx? to http://contoso/pwa/default/aspx?simpleUI=31 removes six common elements from the page and enables you to only view the Notifications Web Part and part of the server ribbon. Other SimpleUI= parameter values (ranging from 0-30) remove other common elements from the Project Web App page, although use of these values is unsupported (with the exception of SimpleUI=16, which returns your pages to the default view.).

Important:

The only SimpleUI parameter that is supported is SimpleUI=31. When you use SimpleUI=31 in the Page Viewer Web Part to view Project Web App sites, part of the server ribbon (the status bar) will appear within the display in the IFrame.

Important:

The SimpleUI=31 value, once set, will persist across all PWA pages in the site collection. This also applies to the SimpleUI=16 value.

For more information about the SimpleUI parameter, see the MSDN article URL Options: Modifying the Query String Parameters (http://go.microsoft.com/fwlink/p/?LinkId=204590).

See Also

Concepts

Upgrade considerations for Project Web App Web Parts
Add Project Web App Web Parts to a site not within the Project Web App site collection (Project Server 2010)
Add or remove Project Web App Web Parts for a site in the Project Web App site collection (Project Server 2010)

Other Resources

Manage Web part pages (SharePoint Server 2010)
Developing Project Server 2010 Web Parts (http://go.microsoft.com/fwlink/p/?LinkID=204589)
Scenarios for Custom Web Parts


Plan for disaster recovery in Project Server 2010

Published: March 31, 2011

There are two methods of backing up your Microsoft Project Server 2010 data:

  • Using Microsoft SharePoint Server 2010 tools

  • Using Microsoft SQL Server tools

Important:

Choose the option that best fits the needs of your organization. We do not recommend combining the two options.

Backing up by using SharePoint Server 2010 tools

The backup and restore tools that are provided as part of SharePoint Server 2010 can perform basic backup and restore functionality for Project Server 2010 databases.

The SharePoint Server 2010 backup and recovery tools have the following advantages:

  • The SharePoint Central Administration Web site provides a simple user interface from which backup and recovery operations can be performed.

  • Windows PowerShell can be used together with the Windows Task Scheduler to easily schedule backup operations during times when the system is not being used.

The SharePoint Server 2010 backup and recovery tools have the following limitations:

  • They cannot synchronize the Project Server 2010 databases. Because of this, backups should be done when the system is not being used, to avoid cross-database inconsistencies.

  • They do not use SQL Server transaction-log-level backups. In the event of database loss, there is no allowance for recovery to the point of failure.

Backing up by using SQL Server tools

SQL Server backup and recovery tools allow for the greatest versatility in recovering your Project Server 2010 deployment after a failure. SQL Server tools have the following advantages:

  • Using the Full Recovery model for SQL Server databases allows for recovery to the point of failure in the event of a database loss.

  • Project Server 2010 and related databases can be synchronized by using transaction log marking. This allows for database consistency during database recovery.

SQL Server tools have the following disadvantage:

  • SQL Server procedures can be complex and require a good knowledge of SQL Server itself and SQL Server databases. We recommend a trained SQL Server database administrator be responsible for these procedures.

Which should I use?

Which backup method to use depends on the requirements of your organization and the availability of trained resources to manage the process. SQL Server tools offer the most versatile options for recovery, but they are more complex to use. SharePoint Server 2010 tools are easy to use, but only allow recovery to the last full or differential backup, which means that there will generally be some data loss. SharePoint Server 2010 tools also require the system to be backed up during a period of inactivity to ensure data consistency across databases.

Use SharePoint Server 2010 tools if:

  • You have a deployment that is not being used for several hours, usually at night, when backups can be performed.

  • You can tolerate data loss of up to twenty-four hours (the time since the last daily backup).

  • Your organization does not have trained SQL Server database administrators or IT personnel who can manage the processes of using SQL Server tools.

Note:

If you use SharePoint Server 2010 tools, make sure that you back up all Project Server 2010 databases and the associated content database.

Use SQL Server tools if:

  • You have a large enterprise deployment that may be in use at any time of the day or night.

  • You have a data loss tolerance (Recovery Point Objective) of less than twenty-four hours.

  • You want to be able to recover to the point of failure in the event of a hardware failure such as the loss of a disk.

The remainder of this section covers the use of SQL Server tools for backing up and restoring Project Server 2010 databases. Detailed instructions for using SharePoint Server 2010 backup and recovery tools to back up Project Server 2010 databases are covered in Back up a Project Server 2010 farm by using built-in tools. For information about how to back up the rest of your SharePoint Server 2010 farm, see Back up a farm (SharePoint Server 2010).

Enterprise disaster recovery using SQL Server tools

Project Server 2010 data and SharePoint Server 2010 data is stored in SQL Server databases. To protect your data against loss, you can create database backups by using the tools that are provided with SQL Server. Database backups contain a complete record of all the data in your database at the time that the backup finishes. Database backups can be used in combination with transaction-log backups to restore your Project Server 2010 and SharePoint Server 2010 data to the point of failure or to an earlier point in time.

Because Project Server 2010 data is stored in multiple related databases, we recommend that you use marked transactions in the transaction logs of each database to help synchronize the databases during recovery.

Setting the recovery model

Set the recovery model for each database in your deployment as follows:

  • Project Server 2010 databases: Full Recovery Both point-of-failure recovery and recovery to earlier points in time require full backups and transaction-log backups of your Project Server 2010 databases.

    Note:

    We recommend that you move your Project Server 2010 databases to fault-tolerant storage.

  • Project Server 2010 content database(s): Full Recovery These databases contain the project workspaces for your Project Server 2010 deployment. Both point-of-failure recovery and recovery to earlier points in time require full backups and transaction log backups of the SharePoint Server 2010 content databases associated with your Project Server 2010 deployment.

    Note:

    We recommend that you move your content databases to fault-tolerant storage.

  • Msdb: Simple Recovery This database contains the backup and recovery history and also the log marking history for all the databases. You need this information when you are recovering your Project Server 2010 deployment. We recommend a daily backup of the Msdb database.

    Note:

    We recommend that you move the Msdb database to fault-tolerant storage.

  • Master: Simple Recovery This database contains SQL Server security and configuration information. We recommend a daily backup of the Master database.

If you are backing up a non-critical Project Server 2010 deployment, you can set all databases to Simple recovery if you are able to tolerate the loss of all data between backups.

Important:

If you use Simple recovery, you should back up your deployment when the system is not being used (that is, when no database transactions are occurring). This ensures database consistency after recovery.

For more information about SQL Server recovery models, see Backing Up and Restoring Databases in SQL Server (http://go.microsoft.com/fwlink/p/?LinkID=102629) in SQL Server Books Online.

Database synchronization

SQL Server backup functionality backs up individual databases independently of one another. Because of this, if you have multiple databases that interact with one another and you use standard SQL Server full or differential backups, related databases can be left in an inconsistent state when restoring.

The backup features in both the SharePoint Central Administration Web site and Windows PowerShell command-line tools start standard SQL Server full or differential backups. Therefore, these tools can also leave related databases in an inconsistent state when restoring.

Project Server 2010 has four dedicated databases for each instance of Microsoft Project Web App. To avoid data inconsistencies and minimize the possibility of orphaned records, these databases should be synchronized during recovery operations. There are two primary methods of achieving this:

  • Use the full recovery model for each database and restore each database to the point of failure

  • Use the full recovery model for each database and restore each database to a marked transaction

If the active transaction log is still available after a hardware failure, then recovery to the point of failure is the preferred method. This ensures minimal or no data loss and is the best option for recovering the databases to a consistent state.

If the active transaction log is damaged or unavailable for one or more related databases, we recommend that you recover to a named mark in the transaction log. This synchronizes the databases from a SQL transaction perspective and minimizes the risk of related databases being recovered to an inconsistent state.

Logical transactions

Both Project Server 2010 and SharePoint Server 2010 use logical transactions that require multiple SQL transactions in order to complete. Creating a site in SharePoint Server, for example, initiates several SQL Server stored procedures and requires multiple transactions in SQL Server to accomplish. Such logical transactions include but are not limited to:

  • Creating a Web application or site collection

  • Provisioning a Project Web App site

Logical transactions are usually the result of manually initiated administrative functions as opposed to regular functions done by users such as working with documents or lists, or entering time on a project.

If a database is restored to a point in time in the middle of a logical transaction, the Project Server 2010 databases may have orphaned records and the application may not function correctly.

When restoring one or more databases, we recommend not restoring to a point in time where a logical transaction was taking place.

Marking the transaction logs

A marked transaction is a transaction that is given a name, such as a time/date stamp. By applying marked transactions to all the databases in your deployment simultaneously, you create a consistent point in all databases to which you can recover.

Related database recovery does not allow recovery to an arbitrary point in time. Recovery of related databases to any time earlier than the point of failure can only be accomplished by recovering to a marked transaction or to a point in time when the system was not in use.

To mark transactions across related databases, place distributed marks across all databases before backing up the log in any database. This ensures that all log backups have a mark that appears in all databases and allows synchronization during recovery.

To recover related databases to a point in time prior to the point of failure, you must have the following:

  • A full database backup of each database

  • Subsequent transaction log backups of each database containing a distributed named mark

Important:

The transaction-log backup for each database must contain identical distributed named marks.

Because recovering to a named mark requires restoring at least one transaction-log backup, we recommend that you use the following procedure when backing up databases that use log marking:

  1. Back up each database.

  2. Mark the transaction logs.

  3. Back up the transaction logs.

  4. Store the database and transaction log backups together.

For more information about transaction log marking, see Using Marked Transactions (Full Recovery Model) (http://go.microsoft.com/fwlink/p/?LinkID=214293) in SQL Server Books Online.

Recovering databases

When recovering from a failure or disaster, it is necessary to recover related databases to a point of consistency with each other to maintain data integrity and avoid orphaned records and possible system problems. Specifically, the following databases must be synchronized with each other:

  • Project Server 2010 Draft database

  • Project Server 2010 Published database

  • Project Server 2010 Reporting database

  • SharePoint Server 2010 Content database associated with the given Project Web App instance

The Project Server 2010 Archive database is only accessed when archiving data by using the Project Web App Administrative Backup functionality. Because of this, the Archive database does not require synchronization with other Project Server 2010 databases and can be recovered to any point in time.

Note:

As a best practice, do not recover the Archive database to a point in time when an Administrative Backup was in process.

Normally, if the active transaction log is available on each database that you are restoring, you can recover to the point of failure and the databases will be consistent. If the active transaction log is not available for one or more databases that you are recovering, then you must recover to an earlier point in time. In this case, you should recover to a named mark in the transaction log to help assure data integrity.

The following table provides recovery guidance for the different types of databases associated with Project Server 2010 deployments.

Database | Recovery procedure
Project Server 2010 Archive database | Recover to the point of failure, if possible. If you are recovering to an earlier point in time, recover to a point in time when no administrative backup operation was in progress.
Project Server 2010 Draft database | Recover to the point of failure, if possible. If you are recovering to an earlier point in time, synchronize with the Project Server 2010 Published and Reporting databases and the SharePoint Server 2010 Content database associated with the Project Web App instance.
Project Server 2010 Published database | Recover to the point of failure, if possible. If you are recovering to an earlier point in time, synchronize with the Project Server 2010 Draft and Reporting databases and the SharePoint Server 2010 database associated with the Project Web App instance.
Project Server 2010 Reporting database | Recover to the point of failure, if possible. If you are recovering to an earlier point in time, synchronize with the Project Server 2010 Published and Draft databases and the SharePoint Server 2010 Content database associated with the Project Web App instance.
SharePoint Server 2010 content databases | Recover to the point of failure, if possible. Synchronize with Project Server 2010 databases if recovering to an earlier point in time.

When recovering your databases, keep in mind the following best practices:

  • If a SharePoint Server 2010 content database failed during a major business transaction (such as creating a site or a Web application), recover that database to a point in time before the business transaction began.

  • If one or more Project Server 2010 databases failed, recover them to the point of failure, if possible. If point-of-failure recovery is not possible, then recover the Published, Draft, and Reporting databases and the SharePoint Server 2010 content database associated with your Project Server 2010 deployment to a marked transaction.

After restoring your databases, we recommend that you review current unprocessed and recent processed queue jobs to check for anomalies.


TechNet Webcast: Project Server 2010: Performance, part 1: setup, test, execution, and results

Published: May 12, 2010

This Microsoft TechNet Webcast is one of two parts that discuss Microsoft Project Server 2010 performance characteristics and farm architecture planning. This Webcast, Part 1, shows you how the testing lab was set up, how the tests were executed, and which test tools were used. The two Webcasts together share the results of Microsoft Project Server 2010 performance lab tests conducted on targeted reference hardware architecture in the Microsoft Technology Center (MTC) by Microsoft Consulting Services (MCS) in partnership with the Microsoft Product Group. The test results were used to identify performance bottlenecks and identify better design and implementation practices for Project Server 2010 infrastructures.

The presenters for this Webcast are:

  • Mike Shughrue, Principal Consultant, Microsoft Corporation

  • Michael Jordan, Lead Architect (EPM), Microsoft Corporation

TechNet Webcast: Project Server 2010 - Performance Part 1: Setup, Execution, and Results (http://go.microsoft.com/fwlink/p/?LinkId=190243)

Note:

The results, architecture, data flow deep dive, and sizing guidelines to use for your Project Server implementation are shown in a second Webcast, TechNet Webcast: Project Server 2010 - Performance Part 2: Architecture, Sizing, and Capacity (http://go.microsoft.com/fwlink/p/?LinkId=190244).

Note:

This Webcast is one of seven available in a series. For a complete list of all available Webcasts from this series, see Project Server 2010 IT-Professional TechNet Webcasts.


TechNet Webcast: Project Server 2010: Performance, part 2: architecture, sizing, and capacity

Published: May 12, 2010

This Microsoft TechNet Webcast is one of two parts that discuss Microsoft Project Server 2010 performance characteristics and farm architecture planning. This Webcast, Part 2, shows you the test results, architecture, data flow, and sizing guidelines and best practices for your Project Server 2010 implementation. The two Webcasts together share the results of Project Server 2010 performance lab tests conducted on targeted reference hardware architecture in the Microsoft Technology Center (MTC) by Microsoft Consulting Services (MCS) in partnership with the Microsoft Product Group. The test results were used to identify performance bottlenecks and identify better design and implementation practices for Project Server 2010 infrastructures.

The presenters for this Webcast are:

  • Mike Shughrue, Principal Consultant, Microsoft Corporation

  • Michael Jordan, Lead Architect (EPM), Microsoft Corporation

TechNet Webcast: Project Server 2010 - Performance Part 2: Architecture, Sizing, and Capacity (http://go.microsoft.com/fwlink/p/?LinkId=190244)

Note:

Information about how the testing lab was set up, how the tests were executed, and which test tools were used is shown in previous Webcast: TechNet Webcast: Project Server 2010 - Performance Part 1: Setup, Execution, and Results (http://go.microsoft.com/fwlink/p/?LinkId=190243).

Note:

This Webcast is one of seven available in a series. For a complete list of all available Webcasts from this series, see Project Server 2010 IT-Professional TechNet Webcasts.


Project Server 2010: A financial management solution for projects, programs and portfolios (white paper)

Published: April 21, 2011

This white paper outlines how Microsoft Project Server 2010 can provide the tools necessary as part of a good, practice-driven finance function, with regard to project appraisal and capital allocation. This paper also reviews key things to consider during the implementation of a solution. Finally, for readers who are looking for more detail and have additional requirements, the paper outlines additional technologies available from Microsoft and other companies to further extend the base functionality of Project Server 2010. The intended audience for this paper is finance professionals who are responsible for budgeting, corporate strategy, or project accounting. As the processes of project financial management and budgeting affect varying levels and areas within many organizations, this white paper may also benefit those who have a role within, or responsibility for, financial management processes that relate to projects.

This white paper was written by Arbutus Solutions.

Download as a PDF file (http://go.microsoft.com/fwlink/p/?LinkId=216201)

Download as an XPS file (http://go.microsoft.com/fwlink/p/?LinkId=216204)


Technical diagrams (Project Server 2010)

Published: May 12, 2010

Many of these resources are visual representations of recommended solutions. They include poster-sized documents available in formats including Microsoft Office Visio 2007 files (.vsd), PDF files, and XPS files. You might need extra software to view these files. See the following table for information about opening these files.

File type | Software
.vsd | Office Visio 2007, or the free Visio viewer (http://go.microsoft.com/fwlink/p/?LinkId=118761) If you use the Visio viewer, right-click the VSD link, click Save Target As, save the file to your computer, and then open the file from your computer.
.pdf | Any PDF viewer, such as Adobe Reader (http://go.microsoft.com/fwlink/p/?LinkId=134751)
.xps | Windows Vista, Windows XP with .NET Framework 3.0, or XPS Essentials Pack (http://go.microsoft.com/fwlink/p/?LinkId=134750)

Models

Models are 34-by-44-inch posters that detail a specific technical area. These models are intended to be used with corresponding articles on TechNet. These models are created by using Office Visio 2007. You can modify the Visio files to illustrate how you plan to incorporate Microsoft SharePoint 2010 Products in your own environment.

Title | Description
Project Server 2010 Upgrade Paths Project Server 2010 upgrade paths Visio (http://go.microsoft.com/fwlink/p/?LinkId=168785) PDF (http://go.microsoft.com/fwlink/p/?LinkId=168784) XPS (http://go.microsoft.com/fwlink/p/?LinkId=168787) | This poster provides a graphical overview of the methods available for upgrading to Microsoft Project Server 2010. This includes information about both the database-attach and in-place methods for upgrading from Microsoft Office Project Server 2007, and an overview of the process for data migration from Microsoft Office Project Server 2003.
Project Portfolio Server 2007 to Project Server 2010 Paths and Considerations Migration considerations, Portfolio Server 2007 Visio (http://go.microsoft.com/fwlink/p/?LinkId=168789) PDF (http://go.microsoft.com/fwlink/p/?LinkId=168788) XPS (http://go.microsoft.com/fwlink/p/?LinkId=168790) | This poster provides a graphical overview of the various methods available for migrating from Microsoft Office Project Portfolio Server 2007 to Project Server 2010.

If you want to create posters that use the same symbols as these posters, you can download Visio stencils for posters (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=88e03d22-8f42-4c9d-94ef-d8e48322d677).


Development for Project Server 2010

Published: May 12, 2010

This section points you to developer-related information for Microsoft Project Server 2010.

  • The Microsoft Project Developer Center on MSDN: Project Developer Center (http://go.microsoft.com/fwlink/p/?LinkId=186370).

  • Visual Studio Team Foundation Server 2010 and Project Server Integration Feature Pack


Visual Studio Team Foundation Server 2010 and Project Server Integration Feature Pack

Published: March 17, 2011

This article details resources for the Visual Studio Team Foundation Server 2010 and Project Server Integration Feature Pack which strengthens the Microsoft Application Lifecycle Management (ALM) Solution. The integration between Project Server and Team Foundation Server is an improvement for organizations that want to bridge the collaboration gap between the Project Management Office and software development teams. The Feature Pack enables teams to work together more effectively by doing the following things:

  • It provides up-to-date insight into portfolio execution, alignment with strategic objectives, and resource utilization of software development projects by using the quantitative data that is stored in different systems.

  • It automates the exchange and sharing of project information across teams and improves coordination between teams that are using different methodologies, such as waterfall and agile. The Feature Pack uses common data and agreed upon metrics to achieve this automation.

  • Enables development and project management teams to collaborate and communicate project timeline and progress information by using familiar tools such as Microsoft Visual Studio, Project, and SharePoint Server.

Resources

The Team Foundation Server 2010 and Project Server Integration Feature Pack can be downloaded from the MSDN Download Center. Here are some key resources currently available:

  • Solutions for Application Lifecycle Management http://www.microsoft.com/visualstudio/en-us/solutions/management

  • WHITE PAPER: Reconciling the Agile Team with Enterprise Project Management in PDF and XPS formats.

  • WHITE PAPER: Project and Work Management with Project Server 2010 and Team Foundation Server 2010 in PDF and XPS formats.

  • MSDN Product documentation (scenarios, installation, configuration): http://msdn.microsoft.com/en-us/library/gg455680.aspx

  • MSDN Public Forums: Team Foundation Server and Project Server Integration: http://social.msdn.microsoft.com/Forums/en-US/tfsprojectsrvint


Deployment for Project Server 2010

Published: May 12, 2010

This article provides links to articles about deployment.

Before installing Microsoft Project Server 2010, be sure you have reviewed the information in Planning and architecture for Project Server 2010. The Deployment section includes information about deployment scenarios, step-by-step installation instructions, and post-installation configuration steps. This section also covers information about upgrading to Project Server 2010.

In this section:

  • Deploy Project Server 2010 to a server farm environment

    This series of articles describes the steps necessary to install Microsoft Project Server 2010 in a server farm environment. This includes installing and configuring Project Server, creating a Microsoft Project Web App site, and configuring reporting.

  • Testing Project Server 2010 deployments

    This page links to a downloadable white paper about testing a newly deployed Project Server 2010 instance.

  • Deploy Project Server 2010 to a test environment

    This series of articles describes deploying a test installation of Microsoft Project Server 2010 in a virtual environment. The purpose of this series is as follows:

  • Install Project Server 2010 to a stand-alone computer

    Microsoft Project Server 2010 can be installed in a stand-alone configuration that uses Microsoft SQL Server 2008 Express. This configuration is useful for demonstration, but should not be used for a production environment.

  • Deploy language packs (Project Server 2010)

    Microsoft Project Server 2010 language packs enable Project Server 2010 users to view Microsoft Project Web App and project sites in multiple languages without requiring separate installations of Project Server 2010.

  • Deploy Project Server 2010 with Exchange Server

    These articles describe how to configure integration with Exchange Server, enabling Microsoft Project Server 2010 users to view Project Server tasks in Microsoft Outlook.

  • Book excerpt: Post-installation configuration (Project Server 2010)

    This book excerpt is from Implementing and Administering Microsoft Project Server 2010, published in 2010 by MSProjectExperts, a Microsoft EPM solution consultancy.

  • Upgrade to Project Server 2010

    This section of the Microsoft Project Server documentation covers the process of upgrading to Project Server 2010.


Deploy Project Server 2010 to a server farm environment
See Also

Published: May 12, 2010

This series of articles describes the steps necessary to install Microsoft Project Server 2010 in a server farm environment. This includes installing and configuring Project Server, creating a Microsoft Project Web App site, and configuring reporting.

Before deploying Project Server 2010, we highly recommend that you review the articles under Plan for deployment (Project Server 2010).

In this section:

  • Overview of the deployment process (Project Server 2010)

  • Prepare for deployment (Project Server 2010)

  • Configure SQL Server and Analysis Services (Project Server 2010)

  • Install SharePoint Server 2010 (Project Server 2010)

  • Install and configure Project Server 2010

  • Create a PWA site (Project Server 2010)

  • Configure reporting for Project Server 2010

  • Add an application server to a farm (Project Server 2010)

See Also

Concepts

Recommended performance enhancements (Project Server 2010)


Overview of the deployment process (Project Server 2010)
See Also

Published: May 12, 2010

This series of articles describes the steps necessary to install Microsoft Project Server 2010 in a server farm environment. These steps include:

  • Configuring Microsoft SQL Server and Analysis Services

  • Installing Microsoft SharePoint Server 2010

  • Installing Project Server 2010

  • Creating a Microsoft Project Web App site

Configure SQL Server and Analysis Services

Configuring SQL Server and Analysis Services includes the following steps:

  • Configure SQL Server network settings

  • Add a login for the Farm Administrator account

  • Enable the common language runtime

  • Configure Analysis Services

Additionally, depending on your needs, you may want to implement some recommended performance enhancements by configuring AUTO_CLOSE and AUTO_UPDATE_STATISTICS_ASYNC. Additionally, you may want to create the Project Web App databases.

Install SharePoint Server 2010

Project Server 2010 requires SharePoint Server 2010 Enterprise Edition. Before you can install and configure Project Server 2010, you must install SharePoint Server 2010 and create a server farm. This article guides you to the proper SharePoint Server 2010 resources to configure your server farm.

Install and configure Project Server 2010

Once you have set up a SharePoint Server 2010 server farm, you can install Project Server 2010. The Project Server 2010 software must be installed on each application server and front-end Web in the farm. Once the Project Server 2010 software is installed and configured, you must configure several service applications in SharePoint Server 2010 before you can create a Project Web App site.

Create a Project Web App site

Once the initial Project Server 2010 configuration within SharePoint Server 2010 is completed, you can create a Project Web App site. When the Project Web App site has been completed, you can proceed with further configuration, including setting up reporting and configuring Exchange Server integration.

Getting started

The first step, prior to installation, is to make sure you have the needed permissions to accomplish the required tasks. For more information, see Prepare for deployment (Project Server 2010).

See Also

Other Resources

Project Server 2010 Ignite Training: Planning, Design, and Deployment (http://go.microsoft.com/fwlink/p/?LinkId=192093)


Prepare for deployment (Project Server 2010)

Published: May 12, 2010

To successfully complete a deployment of Microsoft Project Server 2010, the following permissions are required:

  • Domain Administrator — Required to set up two domain groups for report authors and report viewers.

  • SQL Server Administrator — Required for various Microsoft SQL Server and Microsoft SQL Server Analysis Services (SSAS) configuration tasks as denoted in Configure SQL Server and Analysis Services (Project Server 2010).

  • Exchange Administrator — Required to configure Microsoft Exchange Server for Exchange integration.

  • Farm Administrator — Required to install Microsoft Project Server 2010 and configure a Microsoft Project Web App site.

    Note:

    The Farm Administrator account is created when you install Microsoft SharePoint Server 2010.

Creating users and groups in the Active Directory directory service

Deploying Microsoft Project Server 2010 requires that you have certain Active Directory users and groups available. The deployment instructions assume that the necessary groups already exist. If you have not yet created the necessary users and groups, do so now before deploying Project Server. For detailed information about the users and groups required for Project Server deployment, see Plan for administrative and service accounts (Project Server 2010).

Configuring SQL Server and Analysis Services

Before deploying your farm, you must configure SQL Server and SQL Server Analysis Services.

If you are deploying Project Server to an existing SharePoint Server 2010 farm, some of these steps may already have been done when the server farm was deployed. We recommend that you confirm these settings before installing Project Server.

To configure SQL Server and Analysis Services, follow the procedures in Configure SQL Server and Analysis Services (Project Server 2010).


Configure SQL Server and Analysis Services (Project Server 2010)
See Also

Published: May 12, 2010

Before installing Microsoft SharePoint Server 2010 and Microsoft Project Server 2010, you must first configure Microsoft SQL Server and Analysis Services.

Note:

If you are installing Project Server 2010 to an existing SharePoint Server farm, some of these steps may already be completed.

Complete the procedures in each section below:

  • Configure SQL Server network settings

  • Add a login for the Farm Administrator account

  • Enable the common language runtime

  • Configure Analysis Services

Additionally, depending on the needs of your organization, you may want to do the following:

  • Create the Project Server databases

  • Create additional TempDB files

We also recommend that you start the SQLSERVERAGENT service on the instance of SQL Server where your SharePoint Server databases are located. SharePoint Server and Project Server 2010 use the SQL Server Agent service to perform various database cleanup activities.

When you have finished configuring SQL Server and Analysis Services, go to the next article, Install SharePoint Server 2010 (Project Server 2010).

Configure SQL Server network settings

For Microsoft Project Server 2010 to work correctly, the associated instance of SQL Server must be configured to enable remote connections using TCP/IP. This is the default configuration for SQL Server, but we recommend confirming that the configuration is correct before you install Project Server 2010.

Use one of the next two procedures, depending on your version of SQL Server.

To configure SQL Server 2005 network settings

  1. Click Start, click All Programs, click Microsoft SQL Server 2005, click Configuration Tools, and then click SQL Server Surface Area Configuration.

  2. In the SQL Server 2005 Surface Area Configuration dialog box, click Surface Area Configuration for Services and Connections.

  3. In the tree view, expand the node for your instance of SQL Server, expand the Database Engine node, and then click Remote Connections.

  4. Select Local and Remote Connections, select Using TCP/IP only.

    Note:

    The Using both TCP/IP and names pipes option will also work. If your instance of SQL Server is already configured to use both TCP/IP and named pipes, you can keep that setting.

  5. Click OK.

To configure SQL Server 2008 network settings

  1. Click Start, click All Programs, click Microsoft SQL Server 2008, click Configuration Tools, and then click SQL Server Configuration Manager.

  2. In the left pane, expand SQL Server Network Configuration, and then select the instance of SQL Server where you will be installing Project Server 2010 databases.

  3. In the right pane, ensure the Status for TCP/IP is Enabled.

Add a login for the Farm Administrator account

In order for Project Server 2010 setup and configuration to function, you must create a SQL Server login for the Farm Administrator domain account and give it the required server roles.

To create a SQL Server login

  1. Open SQL Server Management Studio.

  2. Connect to the database engine of the instance of SQL Server that you will be using with Project Server 2010.

  3. Expand the Security node.

  4. Right-click Logins and then click New Login.

  5. On the New page, in the Login name text box, type the domain account that you created for the Farm Administrator.

  6. In the Select a page list, click Server Roles.

  7. In the Server roles list, select the dbcreator, public, securityadmin, and sysadmin check boxes.

  8. Click OK.

Enable the common language runtime

The common language runtime will improve the performance of your Project Server 2010 deployment. To enable the common language runtime, execute the following query:

Copy Code
sp_configure 'clr enabled', 1
go
reconfigure
go

Enabling the common language runtime provides a significant improvement in performance for custom field operations.

Configure Analysis Services

Project Server 2010 can build OLAP cubes in Microsoft SQL Server Analysis Services (SSAS) for use in reporting. If you plan to use the Project Server 2010 cube building feature, you must configure the Farm Administrator account to have administrative permissions in SQL Server Analysis Services for the instance of Analysis Services that you will be using with Project Server 2010.

To add the Farm Administrator as an Analysis Services server administrator

  1. Open SQL Server Management Studio. In the Connect to Server window, connect to the instance of SQL Server 2005 Analysis Services that you are using with Project Server 2010.

  2. In Microsoft SQL Server Management Studio, in Object Explorer, right-click your SQL Server 2005 Analysis Services instance name, and then click Properties.

  3. On the Analysis Services Properties page, in the Select a page pane, click Security.

  4. Click Add.

  5. On the Select Users, Computers, or Groups page, type the name of the Farm Administrator account.

  6. Click OK. The Farm Administrator account appears in the Members list.

  7. Click OK.

Note:

For information about using OLAP databases in Project Server 2010, see OLAP database management (Project Server 2010).

Creating the Project Server databases

When you create a Microsoft Project Web App (PWA) site, Project Server databases are created automatically. You can also create these databases manually before creating the PWA site. Doing so may be desirable if you want to place the databases in a particular location (for example, on a specific LUN) or if the Administrator creating the PWA site has insufficient permissions to create databases in SQL Server.

When creating Project Server databases in SQL Server, create an empty database for the Draft, Published, Archive, and Reporting databases using the SQL_Latin1_General_CP1_CI_AS collation. Create a full set of databases for each instance of PWA that will be created.

Create additional TempDB files

Both Project Server 2010 and Microsoft SharePoint Server 2010 make extensive use of TempDB during SQL transactions. To optimize performance, create additional TempDB files.

As a rule, create an additional TempDB file for each processor (core) in the computer that is running SQL Server. Create the files on a separate partition from other database files.

See Also

Concepts

Install SharePoint Server 2010 (Project Server 2010)


Install SharePoint Server 2010 (Project Server 2010)
See Also

Published: May 12, 2010

Before you can install Microsoft Project Server 2010, you must install Microsoft SharePoint Server 2010 and create a SharePoint Server 2010 farm.

Important:

Project Server 2010 requires the Enterprise edition of SharePoint Server 2010. Prior versions of SharePoint Server and Microsoft SharePoint Foundation 2010 are not supported.

If you have a SharePoint Server 2010 farm configured and you are ready to install Project Server 2010, proceed to the next article, Install and configure Project Server 2010.

If you have not yet installed SharePoint Server 2010, it is important to carefully plan your SharePoint Server 2010 farm before installing SharePoint Server 2010. For detailed information about planning your SharePoint Server 2010 farm, see Plan for server farms and environments (SharePoint Server 2010).

If you have completed the planning phase of your SharePoint Server 2010 deployment, see Multiple servers for a three-tier farm (SharePoint Server 2010) for detailed information about deploying SharePoint Server 2010.

When you have completed SharePoint Server 2010 deployment, proceed to Install and configure Project Server 2010.

See Also

Concepts

Hardware and software requirements (Project Server 2010)

Other Resources

Deployment Overview (SharePoint Server 2010)
Install SharePoint Server 2010 by using Windows PowerShell
Determine hardware and software requirements (SharePoint Server 2010)


Install and configure Project Server 2010

Published: May 12, 2010

Microsoft Project Server 2010 runs as a service application under Microsoft SharePoint Server 2010. The full functionality of Project Server 2010 is provided by several SharePoint Server 2010 service applications:

  • Project Server Service Application

  • Excel Services Application

  • Secure Store Service

This article describes installing and configuring Project Server 2010, including provisioning the Project Server Service Application. Deploying and configuring the Excel Services Application and Secure Store Service are covered in Configure reporting for Project Server 2010.

Use the procedures that follow to install Project Server 2010. The Project Server 2010 software must be installed on each application server in the farm before you can run the SharePoint Products Configuration Wizard to integrate Project Server with SharePoint Server 2010.

Before you install Project Server 2010, make sure that you have reviewed the articles under Plan for deployment (Project Server 2010) and have the necessary service accounts created as described in Plan for administrative and service accounts (Project Server 2010).

Important:

Once you install Project Server 2010, it cannot be uninstalled from the farm. If you want to remove Project Server 2010 functionality, you can turn off the Project Application Service and delete the Project Server 2010 Service Application.

Important:

Upgrading from the Project Server 2010 Beta to the Project Server 2010 release version is explicitly blocked and not supported. This restriction applies to both in-place and db-attach upgrade methods.

Important:

Project Server 2010 does not support multi-tenant environments. Do not install Project Server 2010 on a multi-tenant SharePoint Server 2010 farm. If you have Project Server 2010 installed on a farm, do not configure multi-tenancy on that farm.

Video demonstrations

To view a video demonstration of the installation and configuration process, click one of the following links:

For a single application server farm:

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=169126). To download a copy of the file, right-click the link, and then click Save Target As.

For a multi-application server farm:

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=169128). To download a copy of the file, right-click the link, and then click Save Target As.

Install and configure Project Server 2010

This section describes how to install Project Server 2010. The basic procedure is as follows:

  • Install Project Server 2010 on each application server and Web server in the farm

  • Run the SharePoint Products Configuration Wizard

  • Refresh the installed products on the farm

Note:

If you encounter an error during the installation process, check the log files that are located at \Program Files\Common Files\Microsoft shared\Web server extensions\14\logs and consult the Project Server 2010 forum (http://go.microsoft.com/fwlink/p/?LinkId=169001).

Complete the following procedure on each application server in the farm.

To install Project Server 2010

  1. On the Project Server 2010 DVD, run default.hta. The Setup menu opens.

    Note:

    Default.hta may run automatically when you insert the disk.

  2. On the Start page, click Install Project Server.

  3. On the Enter your Product Key page, type your product key, and then click Continue.

  4. In the End User License Agreement page, review the terms of the agreement. To accept the agreement, select the I accept the terms of this agreement check box.

  5. Click Continue.

  6. On the Choose a file location page, click Install Now.

  7. When the installation is complete, clear the Run the SharePoint Products and Technologies Configuration Wizard now check box.

  8. Click Close.

Once the Project Server 2010 software has been installed on each application server in the farm, you must run the SharePoint Products Configuration Wizard to integrate Project Server with SharePoint Server 2010. You must run this wizard on each application server in the farm before you can start using Project Server.

Complete the following procedure on each application server in the farm.

Note:

Run the SharePoint Products Configuration Wizard on one application server at a time. Do not run it on multiple servers at the same time.

To run the SharePoint Products and Technologies Configuration Wizard

  1. Click Start, All Programs, Microsoft SharePoint 2010 Products, SharePoint 2010 Products Configuration Wizard.

  2. At the Welcome to SharePoint Products and Technologies page, click Next.

  3. A confirmation dialog message appears that displays a list of services that may have to be restarted. Click Yes.

  4. On the Modify server farm Settings page, select the Do not disconnect from this server farm option, and then click Next.

    Note:

    Depending on your configuration, this option may not appear.

  5. If the server is hosting the Central Administration web site, the Modify SharePoint Central Administration Web Application Settings page will be displayed. Select the No, this machine will continue to host the web site option, and then click Next.

    Note:

    Depending on your configuration, this option may not appear.

  6. On the Completing the SharePoint Products Configuration Wizard page, click Next.

  7. On the Configuration Successful page, click Finish.

Configure document library files

In order to be able to save documents to Project Server 2010 sites in SharePoint Server 2010, you must manually copy several files to the appropriate directory. Perform the following procedure on each application server in the farm.

To copy document library files

  1. Open Windows Explorer.

  2. Navigate to the following folder:

    Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Template\Features\DocumentLibrary\DocLib

  3. Copy FileDlg.htm and EditDlg.htm.

  4. Navigate to the following folder:

    Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Template\Features\pwsdoclibs\pwsdoclib

  5. Paste FileDlg.htm and EditDlg.htm.

Configure services

Once Project Server 2010 is installed, the following configuration steps are required before creating a Microsoft Project Web App site and using Project Server:

  • Start the Project Application Service

  • Create a Project Server service application

  • Create a top level Web site

  • Set Read permissions on the top-level Web site

Before you create a Project Server service application, confirm that the Project Application Service is running.

To start the Project Application Service

  1. On the SharePoint Central Administration home page, in the System Settings section, click Manage services on server.

  2. On the Services on Server page, select the server where you want to run the Project Application Service from the Server drop-down list.

  3. If the Project Application Service is not running, on the Service list, click Start next to Project Application Service.

Once you have started the Project Server service on the desired computers in the farm, you must create a Project Server service application.

Note:

While you can create more than one Project Server service application, doing so consumes additional system resources. We recommend that you create only one Project Server service application. A single service application supports multiple Project Web App sites.

To create a Project Server service application

  1. On the Central Administration home page, in the Application Management section, click Manage service applications.

  2. On the Manage Service Applications page, on the ribbon, click New, and then click Project Server Service Application.

  3. On the Create Project Web App service application page:

    1. Type a name for the service application in the Project Web App service application name box.

    2. In the Application Pool section, choose an existing application pool or type the name of the application pool you want to create in the Application pool name box.

    3. Select the Configurable option, and choose the managed account that you want to use to run the application pool.

    4. Click OK.

The next step is to create a top-level Web site if one does not yet exist, and give users read permission to that site. If there is not yet a top level Web site, create one using the following procedure.

To create a top-level Web site

  1. In Central Administration, in the Application Management section, click Create site collections.

  2. Choose a Web application from the Web Application drop-down menu.

    Note:

    If no Web application is available, you must create one. For more information, see Create a Web application (SharePoint Server 2010).

  3. Type a title for the site collection in the Title box.

  4. In the Template Selection section, choose a template for the site.

    Note:

    Project Server 2010 does not require a specific template. You can choose one appropriate for your organization.

  5. In the Primary Site Collection Administrator section, type the name of the account that you want to use for the site administrator.

  6. Click OK.

To set Read permissions on the top-level Web site

  1. Navigate to the root site (that is, http://<servername>).

  2. Click Site Actions.

  3. Click Site Permissions.

  4. Click Grant Permissions.

  5. In the Users/Groups box, type NT AUTHORITY\Authenticated Users.

  6. Under Grant Permissions, select the Add users to a SharePoint group (recommended) option, and then select <SiteName> Visitors [Read] from the dropdown list.

  7. Click OK.

The next step is to create a Project Web App site. Go to the next article, Create a PWA site (Project Server 2010).


Create a PWA site (Project Server 2010)
See Also

Published: May 12, 2010

Creating a Microsoft Project Web App (PWA) site creates the four Microsoft Project Server 2010 databases on the specified instance of Microsoft SQL Server.

Note:

If your organization requires databases to be created manually by a database administrator, have your database administrator see Manually create Project Server databases and create the four Project Server databases and the Microsoft SharePoint Server 2010 content database before you proceed with the procedures in this article.

Note:

If the servers in your farm are not connected to the Internet, some PWA and SharePoint Server pages may load slowly. This occurs because the SharePoint Server certificates attempt to contact Microsoft download servers to obtain the latest root chain. You can work around this issue by configuring the Certificate Path validation settings Group Policy setting on the servers in your SharePoint Server farm so that the servers do not attempt to automatically update certificates. For more information, see Project Server 2010: Slow load times of PWA and SharePoint pages (http://blogs.msdn.com/b/brismith/archive/2012/03/05/project-server-2010-slow-load-times-of-pwa-and-sharepoint-pages.aspx).

If, in the future, you connect the servers in your farm to the Internet, we recommend that you reconfigure the Certificate Path validation settings Group Policy setting on the servers in your SharePoint Server farm to automatically update certificates.

Video demonstration

This video shows the sequence of events involved in creating a PWA site and configuring time reporting periods and the workflow proxy account.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=169130). To download a copy of the file, right-click the link, and then click Save Target As.

Create a PWA site

The Project Web App site requires a Web application to host it. You can use an existing Web application or create a new one for PWA. For more information about how to create a Web application, see Create a Web application (SharePoint Server 2010).

Important:

We highly recommend that you use a separate SharePoint Server 2010 content database for each PWA site and its associated project workspaces. To correctly isolate the PWA site in its own content database, you must deploy PWA at a time when other administrators are not creating new sites on the Web application where you are deploying PWA.

By putting PWA and its associated project workspaces in a separate content database, you greatly simplify site migration and backup and restore procedures.

Creating a PWA site takes five basic steps:

  1. Create a content database to host the PWA site and its associated project workspaces.

  2. Temporarily lock down existing content databases.

  3. Create the PWA site itself.

  4. Lock down the PWA content database to prevent additional site collections being added.

  5. Unlock existing content databases.

SharePoint Server 2010 uses a round-robin algorithm to determine the distribution of site collections across content databases. In order to deploy the PWA site to a specific content database, you have to lock down any existing content databases in the web application where you plan to deploy PWA. The process does not affect user access; it only affects the distribution of new site collections.

Note:

If you are deploying PWA to a new web application that will be dedicated to PWA, you can use the default content database created with that web application for PWA. In this case, there is no need to follow the following lockdown procedures. However, we do recommend that you set the Maximum number of sites that can be created in this database setting to 1 for that content database after you deploy PWA. This will help avoid additional site collections beyond PWA being created in that database in the future.

To lock down your content databases, follow these steps for each content database associated with the Web application where you plan to deploy your PWA site.

Important:

Ensure that no other administrators are adding site collections to the Web application where you plan to deploy PWA while you are performing the procedures in this section.

To lock down a content database

  1. In SharePoint Central Administration, in the Application Management section, click Manage content databases.

  2. In the Current Number of Site Collections column, note the number of site collections for the database that you plan to lock down.

  3. In the Database Name column, click the link for the content database that you want to lock down.

  4. In the Database Capacity Settings section:

    1. In the Maximum number of sites that can be created in this database box, type the existing number of site collection for this database (as noted in the Current Number of Site Collections column, earlier in this procedure).

      Note:

      Take note of the current value for this parameter; you will have to change it back to this value after the PWA site has been created.

    2. In the Number of sites before a Warning event is generated box, type a lower number than the value that is used for Maximum number of sites that can be created in this database.

      Note:

      Take note of the current value for this parameter; you will have to change it back to this value after the PWA site has been created.

  5. Click OK.

To create a content database

  1. In SharePoint Central Administration, in the Application Management section, click Manage content databases.

  2. Click Add a content database.

  3. In the Web Application section, choose the Web application where you plan to deploy the PWA site.

  4. In the Database Name and Authentication section, type the database server name where you plan to deploy your PWA databases, and type a name for the database.

  5. Click OK.

Once the content database has been created and configured, the next step is to create the PWA site itself.

To create a PWA site

  1. In SharePoint Central Administration, in the Application Management section, click Manage service applications.

  2. On the Manage Service Applications page, click the Project Server Service Application.

  3. On the Manage Project Web App Sites page, click Create Project Web App Site.

  4. Complete the Create Project Web App Site page as designated in the following table:

    Option Description

    SharePoint Web Application to Host Project Web App

    The Web application for the PWA site.

    Project Web App path

    The path from the root site for this PWA site.

    Select a language

    The user interface language for this PWA site.

    Use Project Web App path as host header

    Use this option if you want to host PWA on a root URL (for example, https://www.contoso.com).

    Administrator Account

    The user account that will be added to the Project Server Administrators security group in this instance of PWA. You must use this account the first time that you access PWA.

    Primary database server

    The instance of SQL Server where you want to host the Project Server databases. If your database administrator has already created Project Web App databases, specify the names of those databases in the appropriate text boxes. If the databases were not previously created, they will be created automatically.

    Published database name

    The name of the Project Server Published database for this instance of PWA.

    Draft database name

    The name of the Project Server Draft database for this instance of PWA.

    Archive database name

    The name of the Project Server Archive database for this instance of PWA.

    Reporting database server

    The instance of SQL Server where you want to deploy the Reporting database (if different from the primary database server).

    Use primary database server

    Select the check box to deploy the Reporting database to the primary database server specified earlier. Clear the check box to deploy the Reporting database to a different database server, and specify the instance of SQL Server that you want to use in the Reporting database server box.

    Reporting database name

    The name of the Project Server Reporting database for this instance of PWA.

    Quota for SharePoint content in this site

    The maximum site storage, in megabytes, for the PWA site.

    Quota Warning for SharePoint content in this site

    The site storage level, in megabytes, at which a warning e-mail message will be sent to the site administrator.

  5. Click OK.

Project Server starts the PWA site creation process. This may take some time. When the site creation process is complete, the status shown on the PWA site list is Provisioned.

Once the PWA site has been provisioned, verify that it was created in the content database that you created. Use the Get-SPSite Windows PowerShell command, passing the new content database as a parameter:

To verify the PWA site location

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. From the Windows PowerShell command prompt (that is, PS C:\>), type the following command and then press ENTER:

    Get-SPSite -ContentDatabase <ContentDatabaseName>

    The command should return the URL for your PWA site and no other URLs.

    Note:

    If additional URLs beyond that of the PWA site are listed in the content database, delete the PWA site and restart the procedure with a new content database.

Once the PWA site is in the desired content database, you must lock down the database to prevent SharePoint Server 2010 from adding additional site collections to the database. This is performed by configuring the maximum number of sites for the content database to one.

Note:

Configuring this setting does not prevent new project workspace sites from being created.

To lock down the content database

  1. In SharePoint Central Administration, in the Application Management section, click Manage content databases.

  2. In the Database Name column, click the link for the content database that you created.

  3. In the Database Capacity Settings section:

    1. In the Number of sites before a Warning event is generated box, type 0.

    2. In the Maximum number of sites that can be created in this database box, type 1.

  4. Click OK.

Once you have locked down your PWA content database, you can return any other content databases to their original values for Maximum number of sites that can be created in this database and Number of sites before a Warning event is generated.

You can now access the new PWA site.

Note:

The first invocation of the Internet Information Services (IIS) application pool that contains the Project Web App application can be slow because the .NET Framework application is being compiled and loaded.

Configure time reporting periods

Configuring time reporting periods is required for Team Member use of Time Tracking and Task Statusing within Project Server 2010. We recommend that you create at least a year of time reporting periods. Use the following procedure to create time reporting periods.

To create time reporting periods

  1. In PWA, click Server Settings.

  2. In the Time and Task Management section, click Time Reporting Periods.

  3. On the Time Reporting Periods page:

    1. Click the calendar button next to Date the first period starts and select a start date for the first time reporting period.

      Important:

      If you choose a length of seven days for a standard reporting period, all periods will begin on the day of the week you select for the first period start date. Choose a day of the week that conforms with the needs of your organization.

      Important:

      If you want to create variable-length periods, for example when you use a period per calendar month, you must do these individually on the Time Reporting Periods page or programmatically through custom code.

    2. Click Create Bulk.

    3. Click Save.

Configure the workflow proxy account

The final step before you start to use the PWA site is to set the workflow proxy user account. By default, this account is set to the account that you used to create the PWA site. Although you can keep the default, we recommend that you create an Active Directory account for this purpose.

Important:

You must change the account before you start any workflows or else in-progress workflows will break.

There are two steps that you must follow to set up the workflow proxy account:

  • Create a Project Server 2010 user account for the workflow proxy Active Directory account.

  • Configure this account as the workflow proxy user.

Perform the following procedure to create a Project Server 2010 for the workflow proxy account.

To create a user

  1. In Project Web App, click Server Settings.

  2. In the Security section, click Manage Users.

  3. On the Manage Users page, click New User.

  4. On the New User page:

    1. Clear the User can be assigned as a resource check box.

    2. In the Display Name box, type the name that you want to use for the user account (for example, Workflow Proxy User).

    3. In the User Authentication section, type the Active Directory account that you created for the workflow proxy user in the User logon account box.

    4. Select the Prevent Active Directory synchronization for this user check box.

    5. In the Security Categories area, select My Organization in Available Categories, and then click Add.

    6. Under Permissions for My Organization, select Allow for the following permissions:

      • Open Project

      • Save Project to Project Server

      • View Enterprise Resource Data

    7. Under Global Permissions, select Allow for the following permissions:

      • Log On

      • Manage Users and Groups

      • Manage Workflow and Project Detail Pages

  5. Click Save.

Once the user account is created, you can set the workflow proxy user account. Perform the following procedure to configure the workflow proxy user account.

To set the workflow proxy user account

  1. In PWA, click Server Settings.

  2. On the Server Settings page, in the Workflow and Project Detail Pages section, click Project Workflow Settings.

  3. On the Project Workflow Settings page, in the Workflow Proxy User account box, type the Active Directory account that you created for the workflow proxy user, and then click Save.

You are now ready to start using the Project Web App site. The next step is to configure reporting to enable the Project Server reporting and business intelligence features. Proceed to the next article, Configure reporting for Project Server 2010.

See Also

Concepts

Recommended performance enhancements (Project Server 2010)


Manually create Project Server databases
See Also

Published: July 8, 2010

When you create a Microsoft Project Web App (PWA) site, the required databases are created automatically on the instance of Microsoft SQL Server that you specify. However, some organizations require that databases be created manually by a database administrator. This article contains the information that is required to manually create databases for Microsoft Project Server 2010.

The table that follows describes the collations required for each database used by an instance of PWA.

Database | Collation
Project Server Archive | SQL_Latin1_General_CP1_CI_AS
Project Server Draft | SQL_Latin1_General_CP1_CI_AS
Project Server Published | SQL_Latin1_General_CP1_CI_AS
Project Server Reporting | SQL_Latin1_General_CP1_CI_AS
SharePoint Server Content | Latin1_General_CI_AS_KS_WS

Have your database administrator create a set of databases, as described in the table, for each PWA site that you plan to deploy. Once the databases have been created, specify the names of these databases when you create the PWA site or the content database.

For information about how to create a database in SQL Server, see How to: Create a Database (SQL Server Management Studio) (http://go.microsoft.com/fwlink/p/?LinkId=195945).

See Also

Concepts

Create a PWA site (Project Server 2010)


Recommended performance enhancements (Project Server 2010)

Published: May 12, 2010

There are two Microsoft SQL Server settings that we recommend that you implement to help achieve optimal performance for your deployment:

  • SET AUTO_CLOSE OFF

  • SET AUTO_UPDATE_STATISTICS_ASYNC ON

We recommend that you configure these settings for the four Microsoft Project Server 2010 databases (Draft, Published, Archive, and Reporting) for each Microsoft Project Web App site that you create.

These are not required settings. You should evaluate them based on the needs of your organization and any other applications that might be using the same instance of SQL Server where the Microsoft Project Server 2010 databases reside.

When you have completed this section, go to the next article, Configure reporting for Project Server 2010.

AUTO_CLOSE

By default, this option is set to ON for all databases when you are using SQL Server Desktop Engine (also known as MSDE 2000), and OFF for all other editions, regardless of operating system. The AUTO_CLOSE option should not be used for databases accessed by an application that repeatedly makes and breaks connections to SQL Server, such as Project Server. For this reason, we recommend that you set AUTO_CLOSE to OFF for the Project Server databases.

AUTO_UPDATE_STATISTICS_ASYNC

Statistics updates can be either synchronous (the default) or asynchronous. In synchronous statistics updates, queries always compile and execute with up-to-date statistics; when statistics are out-of-date, the query optimizer waits for updated statistics before it compiles and executes the query. For Project Server 2010, we recommend that you set AUTO_UPDATE_STATISTICS_ASYNC to ON for optimal query performance. This lets queries execute immediately without waiting for the statistics to update.


Configure reporting for Project Server 2010
See Also

Published: May 12, 2010

Microsoft Project Server 2010 integrates the Microsoft SharePoint Server 2010 Business Intelligence Center Web application, which provides a central point for hosting the reports, dashboards, and report connections that can be auto-created or manually authored to provide access to reporting data in Project Server for your users. The Business Intelligence Center can be used to host content created with Excel Services in Microsoft SharePoint Server 2010, Visio Services in SharePoint, PerformancePoint Services in SharePoint, PowerPivot and SQL Server Reporting Services.

To configure reporting, you must do the following steps:

  • Add a login for the report authors group in SQL Server

  • Install SQL Server 2008 Analysis Management Objects

  • Start Excel Services

  • Configure Excel Services settings

  • Start the Secure Store Service

  • Configure Secure Store Service settings

  • Populate the Report Authors and Report Viewers Active Directory groups

  • Configure Business Intelligence Center access

Additionally, you will need two Active Directory groups, one for report authors and one for report viewers, as well as an Active Directory account for the Secure Store target application.

How it works

In this video, Microsoft Program Manager Treb Gatte provides an overview chalk talk about how Project Server 2010 reporting works, and how it makes use of SharePoint Server 2010 services.

Treb Gatte Screenshot

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=191600). Right-click the link, and then click Save Target As to download a copy.

This video provides a tour of a functional Project Server 2010 Business Intelligence Center, including a look which SharePoint Server 2010 services are used and how the various services interact with each other.

Reporting Tour Screenshot

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=191601). Right-click the link, and then click Save Target As to download a copy.

Video demonstration

This video shows the sequence of events for configuring reporting in Project Server 2010.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=169132). Right-click the link, and then click Save Target As to download a copy.

Accounts and security groups

The following table describes the accounts and security groups that you will need for the various procedures in this article.

Account Description

Report Authors group

Active Directory security group to which you add users who will create reports, or any other users who need to access reports in Microsoft Excel. This group is given read permissions to the Project Server 2010 Reporting database. Have your domain administrator create this group before proceeding with the procedures below.

Report Viewers group

Active Directory security group to which you add users who will view reports. Have your domain administrator create this group before proceeding with the procedures below.

External Report Viewers group

Active Directory security group for users who do not have a PWA user account but require access to the Project Server 2010 Business Intelligence Center to view reports.

If you have such users in your organization, have your domain administrator create this group and add it to the Report Viewers group described above.

Application Pool account

Active Directory account that is used to run the application pools for the Excel Services Application and the Secure Store Service. This account must be configured as a managed account in SharePoint Server 2010. (Required if you do not yet have Excel Services or the Secure Store Service deployed.)

Note:

You can use the same account that you used for to run the application pool for the Project Server Service Application.

Secure Store Target Application account

This account provides the credentials necessary for report viewers to view reports generated from data in the Project Server reporting database. This account must have db_datareader permissions on the Project Server 2010 reporting database.

Tip:

We recommend that you add this account to the Report Authors Active Directory group described above to give it the necessary permissions.

Add a login for the report authors group

In order for a report author to be able to access the Project Server 2010 Reporting database from Excel, it is necessary to configure Microsoft SQL Server access and add a SQL Server login. The login must allow specific access to the Project Server 2010 Reporting database to get schema information and data. Use the domain group you created for report authors.

Important:

Microsoft Excel does not use the Secure Store Service for data access. Only Excel Services in Microsoft SharePoint Server 2010 uses Secure Store. Users working with reports in Excel require direct database access.

Perform the following procedure on the computer where your Project Server 2010 reporting database is located.

Note:

Alternatively, you can connect to the database engine remotely using SQL Server Management Studio.

To add a login for the report authors group

  1. Click Start, All Programs, Microsoft SQL Server 2008, SQL Server Management Studio.

  2. Select the instance of the SQL Server database engine where your Project Server 2010 reporting database resides, and then click Connect.

  3. Expand Security, right-click Logins, and then click New Login.

  4. On the General page, click Search.

  5. Click Object Types, and select the Groups check box.

  6. Click OK.

  7. Type the name of the group you created for report authors.

  8. Click Check Names.

  9. Click OK.

  10. Select the User Mapping page.

  11. In the Users mapped to this login list box, select the row containing the Project Server 2010 Reporting database.

  12. Select the Map check box for the Project Server 2010 Reporting database.

  13. Select the db_datareader database role membership check box.

  14. Click OK.

Install SQL Server 2008 Analysis Management Objects

If you do not already have the SQL Server 2008 Analysis Management Objects (AMO) installed, you must install them on each application server in the farm.

Note:

Use the SQL Server 2008 version of AMO regardless of which version of SQL Server you are using to host your databases.

Click to download the SQL Server 2008 Analysis Management Objects (http://go.microsoft.com/fwlink/p/?LinkId=130655)

Note:

After installing the AMO objects, restart the Project Application Service on each application server in the farm where it is running. This service is configured in SharePoint Central Administration under System Settings, Manage services on server.

Start Excel Services

If Excel Services is not running on the farm, you must first configure an Excel Services service application.

Important:

If you are planning to use Excel Services for purposes beyond reporting for Project Server 2010, we highly recommend that you review the planning and operations articles for Excel Services to assist with your deployment of Excel Services on your SharePoint Server farm. For more information, see Excel Services overview (SharePoint Server 2010) and Manage Excel Services (SharePoint Server 2010).

If Excel Services is already running on your farm, proceed to Configure Excel Services settings; otherwise, follow the procedures below to start Excel Services.

Important:

The account that is running the Excel Services application pool must have access to the content database where the PWA site resides. The account that is running the application pool for the Project Server Service application has the necessary access, so you can use that account if you want to. If you chose to use a different account for the Excel Services application pool, you can grant the required access by using the following Windows PowerShell script:

$w = Get-SPWebApplication -identity <PWA web application>

$w.GrantAccessToProcessIdentity("<service account>")

Be aware that this action grants db_owner access to the content database.

Starting Excel Services involves two steps:

  • Turning on the Excel Calculation Services service

  • Creating an Excel Services service application

To start the Excel Calculation Services service

  1. On the SharePoint Central Administration Web site, in the System Settings section, click Manage services on server.

  2. If you have more than one application server on the farm, choose the application server where you want to run the Excel Calculation Services service from the Server list.

  3. In the Service list, click Start next to Excel Calculation Services.

To create an Excel Services service application

  1. On the SharePoint Central Administration Web site, in the Application Management section, click Manage service applications.

  2. On the Service Applications tab, click New, and then click Excel Services Application.

  3. In the Name box, type a name for the service application.

  4. In the Application pool name box, type a name for the application pool.

  5. Choose the managed account that you created for application pools from the Configurable list.

  6. Click OK.

Configure Excel Services settings

When Excel Services has been started, you must configure trusted file locations for the Project Server 2010 Sample Reports and Templates libraries.

Follow this procedure twice: once for each library.

To configure a trusted file location

  1. In Central Administration, in the Application Management section, click Manage service applications.

  2. Click the Excel Services service application.

  3. On the Manage Excel Services page, click Trusted File Locations.

  4. Click Add Trusted File Location.

  5. In the Address box, type:

    For the Templates library:

    http://<servername>/<projectsitename>/ProjectBICenter/Templates/

    or

    For the Sample Reports library:

    http://<servername>/<projectsitename>/ProjectBICenter/Sample%20Reports/

  6. Under Trust Children, confirm that the Children trusted check box is selected.

  7. In the External Data section:

    1. Under Allow External Data, select the Trusted data connection libraries and embedded option.

    2. Under Warn on Refresh, clear the Refresh warning enabled check box.

  8. Leave the remaining options at their default value and click OK.

You must configure trusted data connection libraries in order to give users access to the connectors that link the report spreadsheets to the data in the Project Server Reporting database and OLAP databases. As part of this process, you will need the URL of the data connection library in Microsoft Project Web App (PWA).

Use the following procedure to determine the URL of the data connection library in PWA.

To determine the URL for the data connection library

  1. In PWA, in the left navigation pane, click Business Intelligence.

  2. In the left pane, click Data Connections.

  3. On the Data Connections page, select the English (United States) option (or the appropriate language for your locale).

  4. On the toolbar, click View Properties.

  5. On the Data Connections properties page, right-click the English (United States) (or the appropriate language for your locale) link, and then choose Properties.

  6. On the Properties dialog box, select the Address (URL) value.

  7. Right-click the selected text, and then click Copy.

    This is the URL for the data connection library, which you will need when you set up a trusted data connection library in the next procedure.

  8. Click Cancel.

  9. On the Data Connections properties page, click Close.

To set up trusted data connection libraries

  1. In Central Administration, in the Application Management, click Manage Service Applications.

  2. Click the Excel Services service application.

  3. Click Trusted Data Connection Libraries.

  4. Click Add Trusted Data Connection Library.

  5. In the Address box, paste the URL for the data connection library that you copied in the previous procedure. It should be in the following format:

    http://<ServerName>/<ProjectSiteName>/ProjectBICenter/Data%20Connections%20for%20PerformancePoint/English%20(United%20States)

  6. Click OK.

Start the Secure Store Service

In SharePoint Server, the Secure Store Service enables users to access multiple system resources without having to provide authentication credentials more than once. SharePoint Server implements Secure Store Service authentication by including a Windows service and a secure credentials database.

To authenticate a data connection in a workbook against an external data source, you can configure Excel Calculation Services to retrieve authentication credentials from the Secure Store Service. To enable Secure Store functionality for SharePoint Server, you need to start the Microsoft Single Secure Store service and then manage Secure Store settings in Central Administration.

Important:

If you are planning to use the Secure Store Service for purposes beyond reporting for Project Server, we highly recommend that you review the planning and operations articles for the Secure Store Service to assist with your deployment of the Secure Store Service on your SharePoint Server farm. For more information, see Plan the Secure Store service (SharePoint Server 2010) and Configure the Secure Store Service (SharePoint Server 2010).

If the Secure Store is already running on your farm, proceed to Configure Secure Store Service settings.

If you do not already have the Secure Store Service configured in your farm, you must do that first. This involves three steps:

  • Turning on the Secure Store Service

  • Creating a Secure Store Service service application

  • Generating a Secure Store Service key

To turn on the Secure Store Service

  1. On the SharePoint Central Administration Web site, in the System Settings section, click Manage services on server.

  2. If you have more than one application server on the farm, choose the application server where you want to run the Secure Store Service from the Server list.

  3. In the Service list, click Start next to Secure Store Service.

To create a Secure Store Service service application

  1. On the SharePoint Central Administration Web site, in the Application Management section, click Manage service applications.

  2. On the Service Applications tab, click New, and then click Secure Store Service.

  3. In the Name box, type a name for the service application.

  4. In the Application pool name box, type a name for the application pool.

  5. Choose the managed account that you created for application pools from the Configurable list.

  6. Click OK.

  7. When the service application has been successfully created, click OK.

To generate a Secure Store Service key

  1. On the SharePoint Central Administration Web site, in the Application Management section, click Manage service applications.

  2. Click the Secure Store service application.

  3. On the Edit tab, click Generate New Key.

  4. Type and confirm a Pass Phrase, and then click OK.

Configure Secure Store Service settings

Once the Secure Store Service Application has been created, you must create a Secure Store target application.

To create a Secure Store target application

  1. On the SharePoint Central Administration Home page, in the Application Management section, click Manage Services Applications.

  2. Click the Secure Store Service.

  3. On the Secure Store Service page, select the Edit tab.

  4. Click New.

  5. On the Create New Secure Store Target Application page:

    1. In the Target Application ID box, type ProjectServerApplication.

    2. In the Display Name box, type a name for the Secure Store Target Application.

    3. In the Contact Email box, type an e-mail address.

    4. From the Target Application Type drop-down list, select Group.

    5. Click Next.

  6. On the Specify the credential fields for your Secure Store Target Application page, click Next.

  7. On the Specify the membership settings page:

    1. In the Target Application Administrators box, type the user name of the farm administrator.

    2. In the Members box, type the name of the domain group you created for report viewers.

    3. Click OK.

Once the target application has been created, you must set the credentials that you want to associate with it. These are the credentials that will be used by Excel Services will use to access the reporting database when a user refreshes the data in a report.

Note:

If you ever need to reset the credentials to use a new account or to update the password associated with the credentials, you can use this same procedure.

Use the following procedure to set the credentials for the ProjectServerApplication target application.

To set the credentials for a target application

  1. On the Secure Store Service Application page, select the check box for the target application that you just created.

  2. On the ribbon, click Set Credentials.

  3. On the Set Credentials for Secure Store Target Application (Group) dialog box, type the user name and password of the account you created for the secure store target application.

    Important:

    This account must have db_datareader permissions on the Project Server Reporting database. We recommend that you add this account to the Report Authors Active Directory group to give it the required permissions.

  4. Click OK.

Populate the Report Authors and Report Viewers Active Directory groups

To provide your users with the needed access to the Business Intelligence Center in PWA and the reports within, you must populate the Report Authors and Report Viewers Active Directory groups as follows:

  • Report Authors group: Add the Active Directory accounts of users who will be creating reports using Excel.

  • Report Viewers: Add the Active Directory accounts of PWA users who will be viewing reports in the Business Intelligence Center.

    Note:

    If your report authors will also be viewing reports, you can add the Report Authors group to the Report Viewers group in Active Directory.

  • External Report Viewers (optional): If you have users who do not have a PWA account but require access to the Business Intelligence Center to view reports, add their Active Directory accounts to this group and follow the procedure for granting this group access to the Business Intelligence Center in Configure Business Intelligence Center access, below.

Configure Business Intelligence Center access

Users who have accounts in PWA are automatically granted access to the Business Intelligence Center as follows:

  • Team Members: Members of the Team Members group in PWA are automatically added to the Team members group (Microsoft Project Server) SharePoint Group in the Business Intelligence Center.

  • Project Managers: Members of the Project Managers group in PWA are automatically added to the Project Managers Group (Microsoft Project Server) SharePoint Group in the Business Intelligence Center.

If you have users who do not have PWA accounts but need to access reports in the Business Intelligence Center, you must grant them access separately. You can do this by adding those users to an Active Directory group for external report users (as noted in the Accounts and security groups section above) and then granting permissions to the Active Directory group in the Business Intelligence Center.

Use the following procedure to grant permissions to external report viewers.

To grant permissions to external report viewers

  1. In PWA, in the left pane, click Business Intelligence.

  2. In the Business Intelligence Center, click Site Actions, and then click Site Permissions.

  3. On the Edit tab, click Create Group.

  4. On the Create Group page:

    1. In the Name box, type a name for the group (for example, External Report Viewers).

    2. In the Give Group Permissions to this Site area, select the Read check box.

    3. Leave the other options at their default values and click OK.

  5. On the People and Groups page, click New.

  6. On the Grant Permissions dialog box, type the name of the Active Directory group that you created for external report viewers, and then click OK.

Troubleshooting

If you get error messages when trying to view reports, see Project Server 2010: Business Intelligence Center-Common Errors (http://go.microsoft.com/fwlink/p/?LinkId=202437), and the Excel Services data refresh flowchart for troubleshooting information.

See Also

Other Resources

About the BI Center (http://go.microsoft.com/fwlink/p/?LinkId=206333)
Secure Store for Business Intelligence service applications
Project Server 2010 Ignite Training: Reporting Part 1
Project Server 2010 Ignite Training: Reporting Part 2


Add an application server to a farm (Project Server 2010)

Published: May 12, 2010

To add a Microsoft Project Server 2010 application server to an existing farm, you must do the following:

  • Install Microsoft SharePoint Server 2010 prerequisites

  • Install SharePoint Server 2010

  • Install Project Server 2010

  • Install required updates

  • Add the server to the farm by running the SharePoint Products and Technologies Configuration Wizard

Video demonstration

This video shows the steps involved in adding an application server to the farm.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=169134). To download a copy of the file, right-click the link, and then click Save Target As.

Configure the application server

Use the following procedures to configure the application server and add it to the farm.

To install SharePoint Server 2010 prerequisites

  1. On the SharePoint Server DVD, run default.hta.

  2. Click Install software prerequisites.

    Note:

    You must be connected to the Internet to perform this step. If you are not connected to the Internet, you must install the prerequisites manually.

  3. On the Welcome page, click Next.

  4. Read the license agreement, and if you accept, then select the I accept the terms of the License Agreement(s) check box.

  5. Click Next.

    Note:

    Depending on your configuration, you may be required to restart the server during this process.

To install SharePoint Server 2010

  1. On the SharePoint Server DVD, run default.hta.

  2. Click Install SharePoint Server.

  3. On the Enter your Product Key page, type your product key, and then click Continue.

  4. Read the license agreement, and if you accept, then select the I accept the terms of this agreement check box, and then click Continue.

  5. On the Choose the installation you want page, click Server Farm.

  6. On the Server type page, click Complete.

  7. If desired, select the File Location tab and change the installation location.

  8. Click Install Now.

  9. When installation has finished, clear the Run the SharePoint Products and Technologies Configuration Wizard now check box, and then click Close.

To install Project Server 2010

  1. On the Project Server DVD, run default.hta.

  2. Click Install Project Server.

  3. On the Enter your Product Key page, type your product key, and then click Continue.

  4. Read the license agreement, and if you accept, then select the I accept the terms of this agreement check box.

  5. Click Continue.

  6. On the Choose a file location page, click Install Now.

  7. When installation has finished, clear the Run the SharePoint Products and Technologies Configuration Wizard now check box, and then click Close.

Once SharePoint Server 2010 and Project Server 2010 are installed on the computer, you must install any required updates so that the updates on the new application server match those currently on the farm. Note that this includes Project Server 2010 and SharePoint Server 2010 updates, but does not include updates for other products, such as Windows Server or Microsoft SQL Server.

To add the server to the farm

  1. Click Start, All Programs, Microsoft SharePoint 2010 Products, SharePoint 2010 Products Configuration Wizard.

  2. On the Welcome page, click Next.

  3. On the warning dialog box, click Yes.

  4. On the Connect to a server farm page, select the Connect to an existing server farm option.

  5. Click Next.

  6. On the Specify Configuration Database Settings page, type the name of the instance of SQL Server where the SharePoint Server 2010 configuration database is located, and then click Retrieve Database Names.

  7. Select the configuration database for the farm you want to join from the Database name drop-down box, and then click Next.

  8. On the Specify Farm Security Settings page, type the farm pass phrase, and then click Next.

  9. On the Completing the SharePoint Products Configuration Wizard page, click Next.

  10. When the wizard has finished, click Finish.

Configure document library files

In order to be able to save documents to Project Server 2010 sites in SharePoint Server 2010, you must manually copy several files to the appropriate directory. Perform the following procedure on the new application server.

To copy document library files

  1. Open Windows Explorer.

  2. Navigate to the following folder:

    Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Template\Features\DocumentLibrary\DocLib

  3. Copy FileDlg.htm and EditDlg.htm.

  4. Navigate to the following folder:

    Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Template\Features\pwsdoclibs\pwsdoclib

  5. Paste FileDlg.htm and EditDlg.htm.


Create a PWA site in backward compatibility mode (Project Server 2010)

Published: December 2, 2010

Backward Compatibility Mode (BCM) is a feature in Microsoft Project Server 2010 that assists in the upgrade of your Enterprise Project Management environment. While BCM is turned on, Project Server 2010 accepts connections from Microsoft Office Project Professional 2007 with Service Pack 2 (SP2) and Microsoft Project Professional 2010.

BCM is enabled automatically after you upgrade to Project Server 2010 from a previous version, but you can also create a new Microsoft Project Web App (PWA) site with BCM turned on by using a set of empty Office Project Server 2007 databases. This allows you to continue to use Office Project Professional 2007 in your organization.

Note:

Some new features in Project Server 2010, such as manually scheduled tasks, are not available while BCM is turned on. Other features, such as departmental and workflow-controlled custom fields, have limited functionality.

Creating a new PWA site with BCM turned on consists of the following steps:

  1. Download the empty Office Project Server 2007 databases

  2. Restore the empty Office Project Server 2007 databases to an instance of Microsoft SQL Server

  3. Create a PWA site that uses the restored databases

Download the databases

A set of empty Office Project Server 2007 databases is available from the Microsoft Download Center. This includes the four Project Server databases — Draft, Published, Archive, and Reporting. These are supported for production use.

These databases are English databases but they can be used to create PWA sites in other languages as long as both languages (English and the language of the PWA site) are installed on Project Server. For more information about installing language packs on Project Server, see Deploy language packs (Project Server 2010).

You can download the databases from the Microsoft Download Center (http://go.microsoft.com/fwlink/p/?LinkId=207026).

The database backup files are provided in a compressed folder. Unzip the database backup files to a file share that you can access from the instance of SQL Server where you want to restore the backups.

Restore the databases

Each of the four databases must be restored to an instance of SQL Server. The Draft, Published, and Archive databases must all reside on the same instance of SQL Server. The Reporting database can be restored to a different instance of SQL Server if you want.

Use the following procedure to restore each database backup.

To restore a database

  1. Open SQL Server Management Studio and connect to the database engine.

  2. Right-click Databases and click Restore Database.

  3. Select the From device option and click the browse button.

  4. Click Add, select the backup that you want to restore, and then click OK.

  5. Click OK.

  6. In the Restore column of the Select the backup sets to restore list, select the check box for the backup that you want to restore.

  7. In the To database text box, type a name for the restored database.

  8. Click OK.

Create a PWA site that uses the restored databases

Creating a PWA site that uses the restored databases involves creating a new PWA site in the Project Service Application and specifying the names of the restored databases.

To create a PWA site that uses the existing databases

  1. In the SharePoint Central Administration Web site under Application Management, click Manage service applications.

  2. Click the Project Server service application.

  3. Click Create Project Web App Site.

  4. Complete the Create Project Web App Site page as designated in the following table:

    Option Description

    SharePoint Web Application to Host Project Web App

    The Web application for the PWA site.

    Project Web App path

    The path from the root site for this PWA site.

    Select a language

    The user interface language for this PWA site.

    Use Project Web App path as host header

    Use this option if you want to host PWA on a root URL (for example, https://www.contoso.com).

    Administrator Account

    The user account that will be added to the Project Server Administrators security group in this instance of PWA. You must use this account the first time that you access PWA.

    Primary database server

    The instance of SQL Server where you restored the Office Project Server 2007 empty databases.

    Published database name

    The name of the Office Project Server 2007 Published database that you restored.

    Draft database name

    The name of the Office Project Server 2007 Draft database that you restored.

    Archive database name

    The name of the Office Project Server 2007 Archive database that you restored.

    Reporting database server

    The instance of SQL Server where you restored the Office Project Server 2007 Reporting database.

    Use primary database server

    Select the check box if you restored the Reporting database to the primary database server specified earlier. Clear the check box if you restored the Reporting database to a different database server, and specify the instance of SQL Server that you want to use in the Reporting database server box.

    Reporting database name

    The name of the Project Server Reporting database for this instance of PWA.

    Quota for SharePoint content in this site

    The maximum site storage, in megabytes, for the PWA site.

    Quota Warning for SharePoint content in this site

    The site storage level, in megabytes, at which a warning e-mail message will be sent to the site administrator.

  5. Click OK.

Turning off BCM

You can use the PWA site with BCM for as long as required. When you no longer need to be able to access the PWA site from Office Project Professional 2007, you can turn off BCM, and the new features available in Project Server 2010 will become available.

Before you disable BCM, verify that all projects are checked in. If any projects are checked out when BCM is disabled, mismatched projects may exist (for example, the checked out projects will remain in Backward Compatibility Mode). Projects in this condition can lead to problems with edits and data loss, and can cause Project Professional 2010 to stop responding.

Important:

Turning off BCM upgrades the database schemas of the Project Server databases to the standard Project Server 2010 schema. Once BCM has been turned off, it cannot be turned on again.

For more information about turning off BCM, see Project Server 2010 backward compatibility mode (BCM).


Testing Project Server 2010 deployments

Published: December 2, 2010

Summary: The first article in a series of nine articles about how to test a Microsoft Project Server 2010 deployment as an enterprise project management system administrator or solution tester. Use the series as a guide to test the functionality of a newly deployed Project Server 2010 instance. The articles in this series discuss the functionalities that are on the Server Settings page, and some initial tests that you can run to connect and check server communications by using the Project Professional 2010 client application.

Before you read these articles, you should understand the basic structure and functionality of a Project Server 2010 deployment. In addition, you should have the following documentation available:

  • Planning and architecture for Project Server 2010

  • Deployment for Project Server 2010

Organization of this series of articles

This first article discusses Initial use setup, which consists of a series of procedures to check access, connectivity, and some other basics functions that must work correctly before you can continue.

After you complete those checks, you proceed to the following series of tests:

  • Test security settings in Project Server 2010

  • Test enterprise data settings in Project Server 2010

  • Test database administration settings in Project Server 2010

  • Test look and feel settings in Project Server 2010

  • Test time and task management settings in Project Server 2010

  • Test queue settings in Project Server 2010

  • Test operational policy settings in Project Server 2010

  • Test workflow and project detail pages in Project Server 2010

Initial use setup

Check access to Project Web App 2010

This test scenario checks whether you can open Microsoft Project Web App (PWA) in your browser.

Important:

Ask the Enterprise Project Manager administrator whether you have permissions to access the Project Server.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Internet Explorer 7 or 8. |  |
2. Specify http://<ServerName>/PWA/. | Project Web App loads. |
3. Click the OK button. | Project Web App opens and displays the PWA web pages that you can access. |
4. Add the URL to your list of trusted sites in Internet Explorer. | The PWA URL is added to the list of trusted sites. |

Check connectivity between Project Web App and Project Professional 2010

To work with Project Server 2010 from Microsoft Project Professional 2010, you have to configure your Project Server accounts.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Microsoft Project Professional 2010. |  |
2. Click File / Info, and then Manage Accounts. | The Project Server accounts pane opens. |
3. Click Add. | The Accounts Properties page loads. |
4. Specify your account name. |  |
5. Specify the Project Web Server URL. (It is the same as the PWA URL. | http://ServerName/PWA/ |
6. Select use Windows account. |  |
7. Click Set as default account. |  |
8. Click OK. |  |
9. Click OK. | New account is added. |
10. Close Project Professional 2010. |  |
11. Re-open Project Professional 2010. | Project Professional 2010 should log on to Project Server by using the new account that you configured. |
12. To confirm the connection: Click File Open. | A list of projects on the server appears. |

Check that you can create a new project schedule, save the project to the server, and publish it to Project Server

Creating new projects, saving the projects to the server, and publishing the projects to the server is basic to the test scenarios in this article. This test ensures that you can perform some core actions.

Important:

You must have Security permissions in Project Server to save new projects.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Professional 2010.

2. Click File, New and then Project Server Templates.

The Templates pane appears.

3. Select a template (for example, Infrastructure Deployment) and then click OK.

The template that you select loads in Project Professional 2010.

4. Click File, Save As.

The Save to Project Server dialog box appears.

Important:

When you name the project in the next step, prefix the name of the project with your name. For example, RobHoo_Engineering_01

5. Specify the name of your project and then click Save.

Project is saved to the server

OR

The system might prompt you with the Enterprise Standard Calendar dialog box. Click Yes if you accept the changes. The system saves the project to the server.

Important:

Project Professional 2010 saves the project to a local cache. The cache then synchronizes with Project Server after the change.

6. To view the cache status, do the following:

Click Tools, local Project Cache, View Status.

The Cache Status dialog box displays a list of projects.

7. Click File Publish to do the following:

Send the request to publish, and sync the Published and Reporting databases.

Note:

You can add a new column, Publish that governs (at the task level) whether team members who are assigned to the task see it under their statusing area.

The project is published to the server. You might be asked to create a new PWA site for this project.

Check that your e-mail address is completed so that you can get notifications

When the Enterprise resource pool was migrated, all the e-mail addresses were cleared to ensure that every team member did not receive a notification every time that a project published.

Updating the e-mail address also enables you to see where the administrator configures these settings.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Manage Users. | A list of users appears. |
4. Specify your name in the Search box and then click the Search button. | A list of users who meet the search criteria appears. |
5. Click your user name. | A page displays details about you in edit mode. |
6. Complete the identification information: E-mail address. | Identification information is completed. |
7. Click the Save button. | E-mail address and other fields that have changed are updated. |
8. Assign yourself to a project task. | You should get the notification. |

Next steps

The following are the remaining articles in this series:

  • Test security settings in Project Server 2010

  • Test enterprise data settings in Project Server 2010

  • Test database administration settings in Project Server 2010

  • Test look and feel settings in Project Server 2010

  • Test time and task management settings in Project Server 2010

  • Test queue settings in Project Server 2010

  • Test operational policy settings in Project Server 2010

  • Test workflow and project detail pages in Project Server 2010


Test security settings in Project Server 2010

Published: November 29, 2011

Summary: The second article in a series of nine articles about how to test a Microsoft Project Server 2010 deployment as an enterprise project management system administrator or solution tester. Use the series as a guide to test the functionality of a newly deployed Project Server 2010 instance. The articles in this series discuss the functionalities that are on the Server Settings page, and some initial tests that you can run to connect and check server communications by using the Project Professional 2010 client application.

Contents

  • Configure users

  • Configure groups

  • Configure categories

  • Configure security templates

  • Configure Project Web App permissions

  • Next steps

Configure users

If a user does not exist in the system, you can create the account.

The following test scenario describes the steps that you must take to create new resources or users in Project Server 2010.

Important:

You must have security permissions to create a new resource.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Microsoft Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears

3. Click Manage users.

The list of users is displayed.

4. Click the new user button.

The new user page is displayed.

5. Important:

Select the User can be assigned as a resource check box.

This setting ensures that the resource account is created when the user account is created.

6. Complete the identification information:

  • Display name (required field)

  • E-mail address

  • RBS (Resource Breakdown Structure)

  • Initials

  • Hyperlink name

  • Hyperlink URL

The identification information is completed.

7. Complete the user authentication information.

The authentication information is completed.

8. Complete the assignment attribute information:

  • Check/Uncheck resource can be leveled.

  • Base Calendar

  • Default booking type (example: Can set all resources to default to the proposed booking type.)

  • Timesheet manager; that is, the person who approves timesheets.

The assignment attribute information is completed.

9. Check/Uncheck Synchronize Tasks in Exchange Server Details information.

Synchronizes the project tasks with the resource's tasks in the Microsoft Exchange Server mailbox.

10. Select the Department. Click the button to select the resource department.

The selected Resource Department appears in the text box.

11. Enter Resource Custom Fields. Select Yes/No on used for placeholder capacity.

The selected custom field appears in the text box.

12. Complete the security groups.

The selected groups appear in the right-hand box.

13. Complete the security categories.

Make sure that you complete the user permissions for the specific category.

The categories are added to the Categories box together with the related permissions.

14. Complete the Group fields:

  • Group

  • Code

  • Cost Center

  • Cost Type

The group fields are completed.

15. Complete the team details:

  • Team Assignment Pool

  • Team Name

The team details are completed.

Configure groups

When the data is migrated, the existing Project Server groups are created in Project Server 2010.

This test scenario enables the administrator to do the following important tasks:

  • Check that the existing groups are created. (All groups must be checked.)

  • Check what new features have been added to the groups. (Example: New security features.)

Important:

You must have security permissions to administer Project Server groups.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears

3. Click Manage groups.

The list of groups is displayed.

4. Click a group.

Details about the group display.

5. Check that all the fields for the group are populated.

Confirm that the group information is correct.

6. Check that Group information is correct.

Confirm that the group information is correct.

7. Check that the correct users belong to the group.

Confirm that the users are correct.

8. Check that the correct security categories belong to the group.

Confirm that the security categories are correct.

9. Check that the Global Permissions are correct.

Important:

Take note of all the new permissions.

Example: New Section on Time & Task Management.

Confirm that the Global Permissions are correct.

10. Click the Save button.

Changes to the group should be updated to the server. Open the group again to confirm that you are satisfied with the changes.

Configure categories

When the data is migrated, the existing Project Server groups are created in Project Server 2010.

This test scenario enables the administrator to do the following important tasks:

  • Check that the existing categories are created. (All categories must be checked.)

  • Check what new features have been added to the categories. (Example: New security features.)

Note:

You must have security permissions to administer project categories.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears

3. Click Manage categories.

The list of categories is displayed.

4. Click a category.

Details about the category display.

5. Check that the name and description are correct.

Confirm that the name and description are correct.

6. Check that the users and groups that belong to the category are correct.

Note:

'*' indicates that it is a group.

Confirm that the users and groups that belong to this category are correct.

7. Check the projects that belong to the group.

Take note of any changes in the security permissions for the project.

Confirm that the projects that belong to the category are correct.

8. Check that the resources that belong to the group are correct.

Confirm that the resources that belong to the group are correct.

9. Check the resource security permissions.

Take note of the new security permissions.

Confirm that the resource security permissions are correct.

10. Check the views that belong to the category.

Confirm on the screen that the PWA Views that belong to the category are correct.

Configure security templates

Use security templates to allocate permission to groups or users. Use the dropdown displays to assign permissions.

Note:

You must have security permissions to administer Project Server security templates.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears |
3. Click Manage security templates. | The list of security templates is displayed. |
4. Click a security template. |  |
5. Check that the name and description of the template are correct. | Confirm that the name and description are correct. |
6. Check the category permissions. Take note of the new permissions. Example: Approve Timesheets | Confirm that the category permissions for the security template are correct. |
7. Check the global permissions. Take note of the new permissions. Example: Manage Timesheet and Financial Periods. | Confirm that the global permissions for the security template are correct. |
8. Click Save. | Changes are saved to the server. |

Configure Project Web App permissions

Project Web App permissions control which global and category permissions are enabled on Project Server. An administrator can use Project Web App permissions to deny service to all Project Server users for a particular feature in Project Professional 2010 or Project Web App. If a Project Web App permission is enabled, the equivalent global or category permission is enabled for users who have those permissions.

For example, if you deny the Delete Project Web App permission, users cannot delete projects, regardless of whether they have the Delete Project category permission.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears |
3. Click Project Web App Permissions. | The Project Web App Permissions page appears. |
4. Confirm that the PWA permissions migrated correctly. Take note of the new permissions in the server. |  |
5. Click Save. | Changes are saved to the server. |

Next steps

The following are the remaining articles in this series:

  • Testing Project Server 2010 deployments

  • Test enterprise data settings in Project Server 2010

  • Test database administration settings in Project Server 2010

  • Test look and feel settings in Project Server 2010

  • Test time and task management settings in Project Server 2010

  • Test queue settings in Project Server 2010

  • Test operational policy settings in Project Server 2010

  • Test workflow and project detail pages in Project Server 2010


Test enterprise data settings in Project Server 2010

Published: November 29, 2011

Summary: The third article in a series of nine articles about how to test a Microsoft Project Server 2010 deployment as an enterprise project management system administrator or solution tester. Use the series as a guide to test the functionality of a newly deployed Project Server 2010 instance. The articles in this series discuss the functionalities that are on the Server Settings page, and some initial tests that you can run to connect and check server communications by using the Project Professional 2010 client application.

Contents

  • Configure Enterprise Custom Field definition

  • Configure Enterprise Global

  • Configure Enterprise Calendars

  • View the Resource Center

  • View "About Project Server"

  • Next steps

Configure Enterprise Custom Field definition

The following standard custom fields cannot be deleted or renamed:

  • Cost Type

  • Health

  • RBS

  • State

  • Team Name

This scenario walks through the creation of a new custom field.

Important:

You must have security permissions to administer Custom Field Definitions.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Microsoft Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Enterprise Custom Field Definition. (Located in the Enterprise Data section.) | The Enterprise Custom Field Definition page appears. |
4. Click the New Field button. Located in the Enterprise Custom Fields Section. | The New Field Web Page appears. |
5. Specify the name of the field. Example: Project Sponsor |  |
6. Specify the Entity or Type. Example: It is a project field of type text. |  |
7. Specify the Custom attributes. Example: You can link the field to a lookup table, which simulates a tree-view/drop-down of the data. In this example, you create a text field only. | None. The radio button is selected. |
8. Select Department to assign the custom field to a specific set of users in the selected department. | The department is displayed in the text box. |
9. Specify the values to display. Example: To display a graphical indicator in the field, select the graphical indicator option. Select the Data option only. | The Data option selected. |
10. Specify whether the behavior is controlled by workflow, and whether this field must have information. | The check box is selected or cleared. The radio button for Yes or No is selected. |
11. Click Save. | The field is created. |

Configure Enterprise Global

Certain enterprise customizations are made in the Project Professional 2010 desktop client by checking out the Enterprise Global template. Settings made in this manner affect all users who connect to this server.

You can customize the following items in Project Professional 2010:

  • Grouping

  • Maps

  • Tables

  • Filters

  • Views

  • Reports

  • Modules

When you click the Configure Project Professional button, Project Professional 2010 opens, and the enterprise global is automatically checked out.

You cannot check whether your enterprise global configurations are correct.

Important:

Permissions to modify the enterprise global.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Enterprise Global. (Located in the Enterprise Data section.) |  |
4. Click the Configure Project Professional button. | Project Professional 2010 opens, and enterprise global is automatically checked out. |
5. Check that the specific enterprise global configurations are correct. | Confirm that the Specific Configurations are correct. |

Configure Enterprise Calendars

You can create Enterprise Calendars to track when resources are working and when they are not.

This scenario creates an IT Department Calendar that specifies that there are 24x7 working times. You can create fifteen exceptions per calendar.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Enterprise Calendars.

(Located in the Enterprise Data section.)

The Enterprise Calendars page appears.

4. Click New Calendar.

Project Professional 2010 opens, and displays the Change Working Time pane.

5. Specify a name for the new enterprise calendar.

6. Click the Exceptions tab.

Important:

If you define and mark an exception, it is displayed as a non-working day.

Example: a Public Holiday

Type a name for the exception.

Example: National Public Holiday

7. Specify the start date and end date of the exception.

8. Click the Work Weeks tab.

Click the Details tab.

Note:

You can use this feature to set the working and non-working time defaults.

The details for the default appear.

9. Select the days; Sunday to Saturday.

The days are selected.

10. Click Set days to these specific working times.

Input the from and to times.

11. Click OK.

The dialog box closes.

12. Click OK.

The Working Times dialog box closes.

13. Click Save in Project Professional 2010 to save the details to the server.

The calendar details are saved to the server.

View the Resource Center

The Resource Center contains all resources for enterprise projects.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Resource Center. (Located in the Enterprise Data section.) | The Resource Center page appears. |
4. Verify that the expected resources are displayed. | Confirm that the number of resources is correct. |

View "About Project Server"

This web page is for information purposes. It enables you to view the number of active Project Server users and the number of Project Professional 2010 users.

The number of Project Server users is calculated by counting the number of active Project Server user accounts that have permissions to log on. The number of Project Professional 2010 users is calculated by counting the number of active Project Server user accounts that have permissions to log on and also have the permission to 'Log on to Project Server from Project Professional'.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click About Project Server. (Located in the Enterprise Data section.) | The About Project Server dialog box appears. |
4. Check that the number of Project Server and Project Professional 2010 users is correct. | Confirm that the number of Project Server and Project Professional 2010 users is correct. |

Next steps

The following are the remaining articles in this series:

  • Testing Project Server 2010 deployments

  • Test security settings in Project Server 2010

  • Test database administration settings in Project Server 2010

  • Test look and feel settings in Project Server 2010

  • Test time and task management settings in Project Server 2010

  • Test queue settings in Project Server 2010

  • Test operational policy settings in Project Server 2010

  • Test workflow and project detail pages in Project Server 2010


Test database administration settings in Project Server 2010

Published: November 29, 2011

Summary: The fourth article in a series of nine articles about how to test a Microsoft Project Server 2010 deployment as an enterprise project management system administrator or solution tester. Use the series as a guide to test the functionality of a newly deployed Project Server 2010 instance. The articles in this series discuss the functionalities that are on the Server Settings page, and some initial tests that you can run to connect and check server communications by using the Project Professional 2010 client application.

Contents

  • Delete Enterprise Objects

  • Force check-in Enterprise Objects

  • Daily backup schedule

  • Administrative backup

  • Administrative Restore

  • OLAP database build settings

  • Next steps

Delete Enterprise Objects

This page enables the administrator to delete the following items:

  • Projects, proposals, and activities

  • Resources and users

  • Status Report responses

  • Timesheets

Project Server 2010 has the following databases:

  • Draft. You open and save projects from Project Professional 2010 to and from the Draft database.

  • Published. When you select the publish option in Project Professional 2010, the data is saved in the Published database.

  • Reporting. When you publish data, a copy of the data is stored in the Reporting database. All reports run from the Reporting database.

  • Archive. When you archive projects, they are stored in the Archive database.

In this scenario, you delete a project From the Draft database and its associated SharePoint site.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Microsoft Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Delete enterprise objects. (Located in the Database Administration section.) | The Delete Enterprise Objects page appears. |
4. Click Projects. | A list of projects appears in the grid. |
5. Check: Delete the associated SharePoint Foundation Sites option. |  |
6. Select the projects to delete from the grid. Note that you can select multiple projects to delete. |  |
7. Click the Delete button. | The list of projects is deleted. |

Force check-in Enterprise Objects

Sometimes enterprise objects do not get checked back into the system. This feature enables administrators to perform a force check-in operation on the object.

You can check in the following objects:

  • Enterprise Projects

  • Enterprise Resources

  • Enterprise Custom Fields

  • Enterprise Calendars

  • Lookup Tables for Enterprise Custom Fields

  • Resource plans

Important:

You must have Security App to use Check-in Enterprise Objects.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Force Check-in Enterprise Objects. (Located in the Database Administration section.) | The Force Check-in Enterprise Objects page appears. |
4. Select the kind of object that you want to check in. | A list of the selected kind of object appears. |
5. Click the Check-in button. | The object is checked back in to Project Server. |

Daily backup schedule

Use this page to define your daily backup schedule to support item-level restoration. Increasing the project retention policy affects your archive database. The more versions that you keep, the more space is required. Item-level backup is designed to work with, not instead of, SQL Server database backups.

You can back up the following items:

  • Projects

  • Enterprise Resource Pool and Calendars

  • Enterprise Custom Fields

  • Enterprise Global

  • View Definitions

  • System Settings

  • Category and Group Settings

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Schedule Backup. (Located in the Database Administration section.) | The Schedule Backup web page appears. |
4. Set the Project Retention Policy (versions). |  |
5. Next to the projects item, set the option drop-down to Schedule. |  |
6. Specify a time. |  |
7. Click Save. | Project Server creates a backup of the selected item at the specified time. |

Administrative backup

Item-level backup is designed to work with, not instead of, SQL Server database backups.

You can back up the following items:

  • Projects

  • Enterprise Resource Pool and Calendars

  • Enterprise Custom Fields

  • Enterprise Global

  • View Definitions

  • System Settings

  • Category and Group Settings

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Administrative Backup. (Located in the Database Administration section.) | The Backup web page appears. |
4. Select the object to back up. For this example, select Projects. |  |
5. Click Backup. | The request is sent to the queue for processing. |
6. Open the queue: Server settings/queue. | The queue displays details about the backup request. |

Administrative Restore

Use this page to restore individual item-level objects that are stored in your archive database.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Administrative Restore. (Located in the Database Administration section.) | The Restore Web Page appears. |
4. Select the item type that you want to restore. | The list of objects refreshes based on the item type that you select. |
5. Click the item and then click Restore. | The system sends the item to the queue to be restored. |

OLAP database build settings

The cube build setting page enables the administrator to schedule when to build the cube and what date ranges to use when building. The date ranges are important because they affect the following:

  • The time that the cube takes to build.

  • The amount of data that can be analyzed. For example, you might only want to build a cube for 2009 data only. By using the data range options, you can select to run it from 1/1/2009 to 12/31/2009.

In this scenario, you create a new build.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click OLAP Database Build Settings. (Located in the Database Administration section.) | The OLAP Database Management page appears. |
4. Click New. | The OLAP Database Build Settings page appears. |
5. Specify the Analysis Services Server and the Analysis Services database to be created. |  |
6. Specify the Project Department for the OLAP database. |  |
7. Specify the Resource Department to use for the OLAP database. |  |
8. In Database Date Range settings select the Use the fixed date range specified below. Specify 1/1/2009 as the start date. Specify 12/31/2009 as the end date. |  |
9. In the OLAP Database Update Frequency section, do not choose update periodically. Because you want to build the 2009 OLAP database only one time for this example, you do not have to rebuild it periodically because it is in the past. Immediately retry the cube update if scheduled time fails because of queue downtime. |  |
10. Click Save. | You return to the OLAP Database Management page that has the newly created OLAP Database name. |
11. Click Build Now. | The OLAP database is built. |

Next steps

The following are the remaining articles in this series:

  • Testing Project Server 2010 deployments

  • Test security settings in Project Server 2010

  • Test enterprise data settings in Project Server 2010

  • Test look and feel settings in Project Server 2010

  • Test time and task management settings in Project Server 2010

  • Test queue settings in Project Server 2010

  • Test operational policy settings in Project Server 2010

  • Test workflow and project detail pages in Project Server 2010


Test look and feel settings in Project Server 2010

Published: November 29, 2011

Summary: The fifth article in a series of nine articles about how to test a Microsoft Project Server 2010 deployment as an enterprise project management system administrator or solution tester. Use the series as a guide to test the functionality of a newly deployed Project Server 2010 instance. The articles in this series discuss the functionalities that are on the Server Settings page, and some initial tests that you can run to connect and check server communications by using the Project Professional 2010 client application.

Contents

  • Manage views

  • Grouping formats

  • Gantt chart formats

  • Quick Launch

  • Next steps

Manage views

You can create or modify the following different kinds of views:

  • Project

  • Project Center

  • Resource Assignments

  • Resource Center

  • My Work

  • Resource Plans

  • Team Tasks

  • Team Builder

  • Timesheet

  • Portfolio Analysis

  • Portfolio Analysis Project Selection

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Microsoft Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Manage Views. (Located in the Look and Feel section.) | The Manage Views web page appears. |
4. Click the New View button. |  |
5. Select the Project view type. |  |
6. Select Task. |  |
7. Select the fields that you want to add. Example: Task Name, Start Date. |  |
8. Set the width of each field by typing the width value. | The width of the field changes according to the width that you specify. |
9. Specify the format settings for the view. Example: Gantt Chart View Grouping: Group 1 then by group 2 Sorting: Task Name: Ascending |  |
10. Click the Filter button to build filter criteria for the view. | Use the dialog box that is displayed to build filter criteria for the view. |
11. Select the security categories that can see the view. |  |
12. Click Save. |  |
13. Open Project Center, select the new view that you created. Check that the view is built according to the specified criteria. |  |

Grouping formats

You can select a grouping format for the Tasks section and up to 10 grouping formats for views. The grouping formats for views apply to the following views:

  • Project Center

  • Resource Center

  • Project

  • Assignment

Important:

When you are creating a view, you can link it to the grouping format.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Grouping Formats. (Located in the Look and Feel section.) | The Grouping Formats web page appears. |
4. Select Grouping 1. | The page displays levels 1-4 for the selected view. |
5. Change the colors of the groupings. Example: Level 1 - Yellow Level 2 - Blue Level 3 - Green Level 4 - Purple |  |
6. Click Save. |  |
7. Open a view in Project Center and select Grouping 1. Note that the selected view has to be linked to Grouping 1. |  |

Gantt chart formats

Project Web App can display a Personal Gantt Chart on the Tasks page and can display up to 19 different kinds of Gantt Chart views in the Views section.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Gantt Chart Formats. (Located in the Look and Feel section.) | The Gantt Chart Formats web page appears. |
4. Select Gantt 1 from the Gantt Chart drop-down list. | Gantt Chart 1 items appear in the grid. |
5. Change the color of the summary task from black to green. |  |
6. Click Save. |  |
7. Open Project Center in Project Web App. | A list of projects appears. |
8. Click a project that you know has summary tasks. | The project details appear; the summary tasks are now green. |

Quick Launch

The left-hand menu in Project Web App is built dynamically when it is loaded. The Quick Launch admin feature makes it easy for administrators to add links to the page. In addition, you can create a parent menu and a child menu.

In this scenario, you add a link for the PMO FAQ.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Quick Launch. (Located in the Look and Feel section.) | The Quick Launch web page appears. |
4. Select the expand menu items for all sections option. |  |
5. Click new link. |  |
6. Select the new heading option, which enables you to create a parent level menu. |  |
7. Specify the name of the new parent menu. |  |
8. Specify the URL of the heading. If you do not have one, paste your PWA web page home page in the URL. This ensures that the page always navigates back to itself. |  |
9. Select yes to display the menu in the Quick Launch. |  |
10. Click the new link button again so that you can create the child menu option. |  |
11. Specify the name of the child menu. Example: FAQ |  |
12. Specify the URL of the SharePoint list where the PMO FAQs are stored. |  |
13. Select the heading PMO; that is, the parent menu previously created. |  |
14. Select yes to display the link. |  |
15. Click OK to save. |  |
16. You should see the new parent & child menus in the left-hand menu bar. Click the FAQ link. | A new web page is loaded with the FAQ SharePoint list. |

Next steps

The following are the remaining articles in this series:

  • Testing Project Server 2010 deployments

  • Test security settings in Project Server 2010

  • Test enterprise data settings in Project Server 2010

  • Test database administration settings in Project Server 2010

  • Test time and task management settings in Project Server 2010

  • Test queue settings in Project Server 2010

  • Test operational policy settings in Project Server 2010

  • Test workflow and project detail pages in Project Server 2010


Test time and task management settings in Project Server 2010

Published: November 29, 2011

Summary: The sixth article in a series of nine articles about how to test a Microsoft Project Server 2010 deployment as an enterprise project management system administrator or solution tester. Use the series as a guide to test the functionality of a newly deployed Project Server 2010 instance. The articles in this series discuss the functionalities that are on the Server Settings page, and some initial tests that you can run to connect and check server communications by using the Project Professional 2010 client application.

Contents

  • Configure fiscal periods

  • Configure time reporting periods

  • Timesheet adjustment

  • Configure line classifications

  • Timesheet settings and defaults (complex)

  • Configure administrative time

  • Task settings and display

  • Close tasks to update

  • Next steps

Configure fiscal periods

Fiscal periods are primarily used in timesheet adjustments and enterprise reporting. You can create, modify, and delete financial period definitions in this section.

Important:

You must have Manage Timesheet and Financial Periods permissions to configure fiscal periods.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Microsoft Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Financial Periods.

(Located in the Time and Task Management section.)

The Financial Periods web page appears.

4. Select an undefined fiscal period to manage; for example, 2012.

5. Click Define.

The page refreshes with detailed sections.

6. Select a Fiscal Year Creation model.

Example: 4, 5, 4 method.

7. Define Period Naming conventions; for example:

  • Enter the Prefix: FY

  • Enter Numbering Sequence: 01

  • Enter Suffix: FP

8. Optional: To change the end date for a specific month, click the end-date cell for that month.

The date picker is available for you to select a specific date.

9. Click the save to create button.

The page refreshes with the list of fiscal periods in the system.

Note:

To delete the defined fiscal period, click the Delete button.

Configure time reporting periods

You can create timesheet periods in bulk, which saves the administrator time.

It is important that you define the timesheet periods correctly at the outset because they affect many aspects of the solution. When the data is migrated, the existing Project Server groups are created in Project Server 2010.

Important:

You must have Manage Timesheet and Financial Periods permissions to configure fiscal periods.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Time Reporting Periods.

(Located in the Time and Task Management section.)

The Timesheet Periods web page appears.

4. Define Bulk Period Parameters.

Example: Create 52 periods.

  • Specify the start date as 1/1/2010 so that you create periods for a full year.

  • Define the period length: 7 Days. Or, if no one in the organization works or reports time on Saturdays or Sundays, you can set it to 5 days.

After you click Save, the changes are saved to the server.

5. Define Batch Naming Convention.

For multiple reporting periods, you can set a unique name for each period.

After you click Save, the changes are saved to the server.

Timesheet adjustment

To view approved timesheets, available timesheets, and unsubmitted timesheets, follow these steps.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Timesheet Adjustment. (Located in the Time and Task Management section.) | The Timesheet Approval page appears. Use it to view approved timesheets, available timesheets, and unsubmitted timesheets. |

Configure line classifications

You can duplicate timesheet lines by defining timesheet line classifications, which become unique identifiers for a timesheet line.

By default, the system creates a standard classification.

In this example, you create timesheet classifications to help identify timesheet line items.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Line Classifications. (Located in the Time and Task Management section.) | The Line Classifications web page appears. |
4. Click the new classification button. | A new row appears. |
5. Specify a name and description for each line classification. |  |
6. Click Save. | New timesheet classifications are created. |

Timesheet settings and defaults (complex)

Because of the complexity of this admin setting, the information in this section is divided into sub-test scenarios.

How timesheets are displayed in Project Web App

Timesheets can display planned work, overtime, and non-billable time. To disable the overtime and non-billable timesheet types, clear the check box to the right.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Timesheet Settings and defaults.

(Located in the Time and Task Management section.)

The Settings and defaults page loads.

4. Open another Internet Explorer PWA session, and then click the My Timesheet menu.

The My Timesheet view opens.

5. Click Create to create a new timesheet.

A new timesheet page appears.

Note:

The overtime and non-Billable time tracking sections appear if the check box is selected.

6. Toggle the setting on the admin page and then refresh the timesheet view.

Important:

If you don't see the toggle occurring, check the actions bar on the My Timesheet page and see whether that the user has not chosen to hide this as a personal setting.

7. Click the actions bar, select the show billable work.

If the menu is greyed out, the admin has cleared the display setting.

Default timesheet creation mode

Users can enter data on their timesheets against projects or current assignments. Use this setting to enable site-level consistency for the kind of default timesheet that users see.

Example 1: When you create a new timesheet, it defaults to using the current task assignments. This way, users do not have to select the current task assignments when they create a new timesheet.

Example: 2: Users start with a blank timesheet because that is what they prefer.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Timesheet Settings and Defaults.

(Located in the Time and Task Management section.)

The Settings and defaults page loads.

4. Locate the Default timesheet creation mode section.

Select the No - Population option.

5. Click Save.

6. Open another instance of Project Web App.

7. Click the My Timesheets menu.

8. Click Create.

The system creates a new timesheet.

9. If no pre-population is selected, non-project task assignments appear on the timesheet.

Important:

Administrative Time still shows as default line items if the administrator has set them to show.

This feature is for project-related items.

Timesheet grid column units

Timesheets support weekly or daily tracking. When you specify Weekly, each column in the timesheet represents seven days, and the date in the column displays the first day of the week.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Timesheet Settings and Defaults. (Located in the Time and Task Management section.) | The Settings and Defaults page loads. |
4. Go to the Timesheet Grid Column Units. |  |
5. Change the units to weeks. |  |
6. Click Save. |  |
7. Open the My Timesheet page. |  |
8. Look at the date ranges; they are in weeks, not days. |  |
9. Change the setting back to days and then click Save. |  |
10. Open the My Timesheet page. |  |
11. Look at the date ranges; they are in days, not weeks. |  |

Default reporting units

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Timesheet Settings and Defaults. (Located in the Time and Task Management section.) | The Settings and Defaults page loads. |
4. Go to the Default Reporting Units page. |  |
5. Set the following: Standard timesheet day = 8 Number of hours in a standard work week = 40 |  |
6. Click Save. |  |
7. Open the My Timesheet page. |  |
8. Try to specify values outside the ranges specified and submit them. | The system prevents you from submitting a timesheet that has values outside the settings. |

Hourly reporting units

Accounting systems, customers, or internal business policies might restrict how you can enter time. If you use team resources, make sure that you consider such restrictions when you set these values.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Timesheet Settings and Defaults. (Located in the Time and Task Management section.) | The Settings and Defaults page loads. |
4. Go to the Default Reporting Units page. |  |
5. Set the following: Maximum Hours per Timesheet: 50 Minimum Hours per Timesheet: 40 Maximum hours per day: 15 |  |
6. Click Save. |  |
7. Open the My Timesheet page. |  |
8. Try to specify values outside the ranges specified and submit them. | The system prevents you from submitting a timesheet that has values outside the settings. |

Timesheet policies

The administrator can use settings in this section to help you comply with accounting and regulatory policies.

You can restrict users from submitting hours in pay periods that are in the future.

You can also restrict users from specifying line items on the timesheet that cannot be verified against Project Server.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Timesheet Settings and Defaults. (Located in the Time and Task Management section.) | The Settings and Defaults page loads. |
4. Go to the Timesheet Policies page. |  |
5. Clear the Allow Future Time Reporting check box. Clear the Unverified line items check box. |  |
6. Click Save. |  |
7. Open the My Timesheet page. |  |
8. Try to save time in a future pay period. | The system prevents the action. |
9. Try to add line items by clicking the Add Lines button. | The system prevents you from submitting unverified line items. |

Auditing

You can use timesheet auditing to record changes that are saved to timesheets during creation, approval, and modifications or adjustments.

We recommend that you turn on auditing from the beginning of the implementation so that you have a full history.

Important:

Auditing data can consume a lot of space in SQL Server. Therefore, work with IT to ensure that you have allocated sufficient disk space.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Timesheet Settings and defaults.

(Located in the Time and Task Management section.)

The Settings and Defaults page loads.

4. Go to the Auditing section.

5. Select Enable Timesheet auditing.

6. Click Save.

The system logs creation, approval, and adjustments to timesheets.

7. Use the purge log feature with utmost caution.

Important:

Purge is permanent.

Approval routing

Fixed Approval routing disables the ability to change the next approval during timesheet submission. Because the transaction comment is also disabled during submission, users should comment in the timesheet header instead.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Timesheet Settings and defaults. (Located in the Time and Task Management section.) | The Settings and Defaults page loads. |
4. Go to the Approval Routing section. |  |
5. Clear the fixed approval routing check box. |  |
6. Click Save. | The system prevents the timesheet App rover from being changed. |

Configure administrative time

Administrative time enables you to track exception time and any other categorized non-project time that employees spend and that your company tracks. You can set each category to require managerial approval before employees commit time.

Additionally, you can set each category to display by default on each user's timesheet. To specify this setting, select the Always Display option.

By default, the following administrative time options are made available. If you do not want the options to always be displayed on the timesheet, clear the Always Display option.

  • Administrative

  • Jury Duty

  • Sick Time

  • Vacation

In this example, you create new categories.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Administrative Time. (Located in the Look and Feel section.) | The Administrative Time web page appears. |
4. Click the New Category option. |  |
5. Specify the name of the new category. Example: Maintenance Work_DoNot Always Display Training_Always Display |  |
6. Click Save. | The new time categories are created, and are now available on the My Timesheets page. |

Task settings and display

This is a global configuration for the instance of Project Server that you are configuring.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Administrative Time.

(Located in the Look and Feel section.)

The Administrative Time web page appears.

4. Examine the tracking method options:

  • Percentage of work complete. Resources report the percentage of work that they have completed, from 0 through 100%.

  • Actual work done and work remaining. Resources report the actual work done and the work that remains to be done on each task.

  • Hours of work done per period. Resources report the hours worked on each task per period.

5. Of those options, choose the following for this example:

Select Percentage of work complete.

Check the form project managers to use the progress reporting method for all Projects.

6. For Reporting Display, choose Hours worked each day.

7. Select the Time entry by Timesheet only check box if you want to ensure that the users always report the same timesheet hours as task progress. Users must then import from a timesheet to update task progress and submit.

8. In the Near Future Planning Window on the Tasks page, specify the number of reporting periods to include.

In this example, set it to 5 days.

9. Click Save.

The changes are saved to the server.

Close tasks to update

Use the "Close tasks to update" feature to select the project for which you want to lock down tasks. These changes do not take effect until the next time that you publish this project.

Publishing a project publishes all applied task updates and any other changes that were made to the plan. To preview all pending changes, open the project in Microsoft Project Professional 2010 before you publish.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Assign yourself to all the tasks on the schedule.

4. Save the project.

The project is saved to the server.

5. Publish the project.

The project is published. The Task assignments are available on your My Work page.

6. Open Project Web App.

7. Click My Tasks in the left menu.

A list of task assignments appears.

8. Update some of the fields.

The system enables you to edit the fields.

Next, you CLOSE the task to updates, which prevents future updates to the task.

Note:

The task still appears on the timesheet view. However, it is in a read-only state.

9. Open Project Web App.

Project Web App loads.

10. Click Server Settings.

The Server Settings page appears.

11. Click Close tasks to update.

(Located in the Look and Feel section)

The Close Tasks to Update web page appears.

12. Select a project from the list.

Lists of tasks for the project appear.

13. Select the tasks that you want to close.

14. Click the update/save button.

15. The selected tasks are now closed to updates.

Important:

Take note of the rules that are described in the summary of this test scenario.

16. Open the My Work / Tasks Page.

Try to edit some values for the tasks that are closed to updates.

The system prevents you from capturing time against a closed task - the task is read-only.

Important:

The task will still appear on the timesheet.

Next steps

The following are the remaining articles in this series:

  • Testing Project Server 2010 deployments

  • Test security settings in Project Server 2010

  • Test enterprise data settings in Project Server 2010

  • Test database administration settings in Project Server 2010

  • Test look and feel settings in Project Server 2010

  • Test queue settings in Project Server 2010

  • Test operational policy settings in Project Server 2010

  • Test workflow and project detail pages in Project Server 2010


Test queue settings in Project Server 2010

Published: November 29, 2011

Summary: The seventh article in a series of nine articles about how to test a Microsoft Project Server 2010 deployment as an enterprise project management system administrator or solution tester. Use the series as a guide to test the functionality of a newly deployed Project Server 2010 instance. The articles in this series discuss the functionalities that are on the Server Settings page, and some initial tests that you can run to connect and check server communications by using the Project Professional 2010 client application.

Contents

  • Manage queue

  • Queue settings

  • Next steps

Manage queue

See Plan the application tier (Project Server 2010) for detailed information about how the queue works from a technical perspective.

The following are some examples:

  • When you perform a save transaction, the request is sent to the queue and the client-side cache and the queue then ensures that the transaction is completed.

  • When you create a new resource, the request is sent to the queue, and the queue creates the resource.

  • When you publish, the queue manages the synchronization transactions between the Draft database, Published database, and Reporting database.

The queue is read-only. Only applications such as Project Professional 2010 and Microsoft Project Web App can make entries into the queue.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Manage Queue.

(Located in the Queue section.)

The Manage Views web page appears.

4. Open Project Professional 2010 and publish a project.

5. Refresh the queue page.

The page displays the list of items in the queue, including the project publish transaction.

6. Open the Delete Enterprise Objects page and then delete a timesheet.

7. Open the queue page again after issuing the timesheet delete transaction.

The page displays the timesheet delete transaction.

Note:

Take note of the following:

  • Progress of the queue - % complete is shown for each transaction in the queue.

  • Job State - example if the queue transaction fails it will provide the details of why.

  • If an error occurs, click the link in the error column - this loads a web page that contains detailed information about the error.

The width of the field changes according to the width that you specify.

Queue settings

Project Server 2010 has the following queues:

  • A Timesheet queue that contains processed transactions related to Timesheets.

  • A Project queue that contains processed transactions related to Projects/Resources.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Queue Settings. (Located in the Queue section.) | The Queue Settings page appears. |

Queue settings values

Value Description

Queue Type

Choose the Queue to which the settings apply. The options are the Project Queue, which processes job types such as Project Save and Publish, or the Timesheet Queue, which processes job types such as Timesheet Save and Notifications. Note that all the Queue Settings are per PWA site, and per Queue Type.

Maximum Number Of Job Processor Threads

The Queue is multi-threaded, which enables multiple jobs to be processed at the same time. If the number of current job processor threads equals the limit, no more threads are created. Note that this setting is per PWA site, and per Queue Type.

  • Minimum: 1

  • Maximum: 20

  • Default: 4

Polling Interval (in milliseconds)

The time interval at which the Queue polls the database for new jobs.

  • Minimum: 500 (.5 second)

  • Maximum: 300000 (5 minutes)

  • Default: 1000 (1 second)

Retry Interval (in milliseconds)

If job processing fails because of transient issues (like a SQL Deadlock), instead of failing the job, the Queue will wait for the Retry Interval to elapse and then retry the job.

  • Minimum: 0 (immediately retry)

  • Maximum: 300000 (5 minutes)

  • Default: 1000 (1 second)

Retry limit

If job processing fails because of transient issues (like a SQL Deadlock), instead of failing the job, the Queue will retry the job. The number of retries is bound by the Retry Limit.

  • Minimum: 0 (no retries)

  • Maximum: 100

  • Default: 5

SQL retry interval (in milliseconds)

The Queue polls the database at set intervals to retrieve jobs that need processing. If this query fails due to a transient SQL problem (like a SQL Deadlock), the Queue will wait for the SQL Retry Interval to elapse and then retry the query.

  • Minimum: 0 (immediately retry)

  • Maximum: 60000 (1 minute)

  • Default: 1000 (1 second)

SQL retry limit

The Queue polls the database at set intervals to retrieve jobs that need processing. If this query fails due to a transient SQL problem (like a SQL Deadlock), the Queue will retry the query after the SQL Retry Interval has elapsed. The number of retries is bound by the SQL Retry Limit.

  • Minimum: 0 (no retries)

  • Maximum: 100

  • Default: 5

SQL Timeout (in seconds)

The Queue makes SQL calls for retrieving and executing jobs. This setting controls the time-out value for all such calls. If any job fails due to a SQL Timeout error, administrators can increase this setting and retry the job.

  • Minimum: 30

  • Maximum: 86400 (1 day)

  • Default: 300 (5 minutes)

Clean-up Interval (in hours)

This setting determines the frequency with which the Queue Clean-up job runs. The time of day at which the Queue Clean-up job runs is determined by the Clean-up Interval Offset setting.

  • Minimum: 1

  • Maximum: 100000

  • Default: 24 (1 day) Clean-up Interval (in hours)

Clean-up Interval (in hours)

This setting determines the frequency with which the Queue Cleanup job runs. The time of day at which the Queue Cleanup job runs is determined by the Cleanup Interval Offset setting.

  • Minimum: 1

  • Maximum: 100000

  • Default: 24 (1 day)

Clean-up Interval Offset (in minutes)

This setting is the number of minutes after 12:00 a.m. (midnight) at which the Queue Cleanup job will run. The frequency with which the Queue Cleanup job runs is determined by the Cleanup Interval setting.

  • Minimum: 0 (cleanup 12:00 a.m.)

  • Maximum: 1439 (cleanup at 11:59 p.m.)

  • Default: 0 (cleanup at 12:00 a.m.)

Clean-up Age Limit for Successful Jobs (in hours)

This setting determines the age threshold at which successful jobs can be purged when the Queue Cleanup job runs. The age of each job is determined by the completed date and time. For example: If a job succeeded at 2/1/2007 10:41 p.m. and the Queue Cleanup job runs at 2/2/2007 11:55 p.m., then the job will be purged (assuming the Cleanup Age Limit For Successful Jobs was 1 day). Because the number of successful jobs is usually high, the Cleanup Age Limit For Successful Jobs setting is usually set to a low value of 24 (1 day).

  • Minimum: 1

  • Maximum: 100000

  • Default: 24 (1 day)

Clean-up Age Limit for Non-Successful Jobs (in hours)

This setting determines the age threshold at which any job in a completed, non-successful state (example: Failed But Not Blocking Correlation) can be purged when the Queue Cleanup job runs. The age of each job is determined by the completed date and time. For example: If a job was canceled at 2/1/2007 10:41 p.m. and the Queue Cleanup job runs at 2/2/2007 11:55 p.m., then the job will not be purged (assuming the Cleanup Age Limit For Non-successful Jobs was 7 days). Because the number of completed, non-successful jobs is usually not high, the Cleanup Age Limit for Non-successful Jobs setting is usually set to a high value of 168 (7 days).

  • Minimum: 1

  • Maximum: 100000

  • Default: 168 (7 days)

Bookkeeping Interval (in milliseconds)

There are several Bookkeeping tasks that the Queue System executes. Some examples are as follows: awakening jobs in 'Sleeping' state, updating the heartbeat time stamp, checking whether Queue Cleanup needs to be executed, and so on. This setting controls the time interval at which these tasks run.

  • Minimum: 500 (1/2 second)

  • Maximum: 300000 (5 minutes)

  • Default: 10000 (10 second)

Queue Timeout (in minutes)

The Queue System has a failover recovery feature: if the farm contains multiple servers that are running the Project Application Service, and the Queue Service fails on one server, jobs are automatically redistributed to other servers on which the Queue Service is online. A Queue Service is considered to have timed out if it has not updated its heartbeat for more than the 'Queue Timeout' interval. The heartbeat is updated by the Queue in all the PWA databases that it handles.

  • Minimum: 2

  • Maximum: 20

  • Default: 3

Note:

The Queue Timeout cannot be less than 4 times the Bookkeeping Interval at any time. For example, if the Queue Timeout is 3 minutes and the Bookkeeping Interval is changed to 60000 (60 seconds), then the Queue Timeout will automatically be changed to 4 minutes.

Fast Polling

By default, this setting is enabled and the queue processes all 'waiting to be processed' jobs as soon as possible. But if this fast processing overwhelms the server and you want the queue to slow down, administrators can turn off Fast Polling. If the setting is off, the queue does the following: Check if there are any free threads to process jobs and if there are, load all the free threads with the 'waiting to be processed' jobs, wait for the polling interval and repeat the process again. If the setting is on, the queue does not wait for the polling interval if there are pending jobs. As jobs get processed, the pending jobs are processed immediately.

Next steps

The following are the remaining articles in this series:

  • Testing Project Server 2010 deployments

  • Test security settings in Project Server 2010

  • Test enterprise data settings in Project Server 2010

  • Test database administration settings in Project Server 2010

  • Test look and feel settings in Project Server 2010

  • Test time and task management settings in Project Server 2010

  • Test operational policy settings in Project Server 2010

  • Test workflow and project detail pages in Project Server 2010


Test operational policy settings in Project Server 2010

Published: November 29, 2011

Summary: The eighth article in a series of nine articles about how to test a Microsoft Project Server 2010 deployment as an enterprise project management system administrator or solution tester. Use the series as a guide to test the functionality of a newly deployed Project Server 2010 instance. The articles in this series discuss the functionalities that are on the Server Settings page, and some initial tests that you can run to connect and check server communications by using the Project Professional 2010 client application.

Contents

  • Alerts and Reminders

  • Additional server settings

  • Server-side event handler configuration

  • Active Directory Resource Pool synchronization (Part 1)

  • Active Directory Resource Pool synchronization (Part 2)

  • Project sites

  • Project site provisioning settings

  • Bulk update project sites

  • Next steps

Alerts and Reminders

Alerts and Reminders enable you to define notification-email settings and to schedule the email reminder service.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Microsoft Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Alerts and Reminders.

(Located in the Operational Policies section.)

The Alerts and Reminders page appears.

4. Specify the name of the SMTP Server.

5. Specify the From Address.

6. Specify the company domain name.

7. Specify the email footer.

Example:

  • Please contact the PMO for questions regarding the Project Server Settings.

8. Schedule e-mail reminder service.

Specify 11am.

The e-mail reminder service scans the Project Server database at the scheduled time each day, and sends e-mail messages to remind users about their upcoming or overdue tasks and status reports.

9. Publish a project.

Add yourself as one of the team members.

10. Open Microsoft Outlook and check for new mail.

Project Server has sent you a notification regarding the new assignment.

Additional server settings

This page enables the administrator to set additional global settings for the server instance. For example, the administrator could allow master projects to be published.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Additional Server Settings. (Located in the Operational Policies section.) | The Additional Server Settings page appears. |

Server-side event handler configuration

Use this page to manage custom server-side events. The following are examples:

  • Once a developer has written a server-side event, the EPM administrator can view summary details of the event handler on the server.

    There are several standard events that occur on the server already.

  • Project: Create - the event is triggered each time that a project is created on the server.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Server-Side event handler configuration. (Located in the Operational Policies section.) | The Server-Side event handler configuration page appears. |
4. Click the event sender. (Located in the Time and Task Management section.) | Event handlers refresh at the bottom of the page, based on the event sender that you select. |
5. Click new event handler. (Located in the Time and Task Management section.) | You can use the page that is displayed to specify the event handler. |
6. Specify the Display and System information about the event and then click Save. (Located in the Time and Task Management section.) | Event details are saved to the server. |
Important:

This is only used when a developer has created custom event handlers that should be registered with Project Server.

Active Directory Resource Pool synchronization (Part 1)

The Active Directory resource pool synchronization enables you to add or remove resources in the Enterprise Resource Pool (ERP) based on who is added or removed from a single Active Directory Group. For example:

  1. A new employee joins Contoso.

  2. A process is in place to add new users to the Microsoft Project 2010 Active Directory group.

  3. The system synchronizes on a nightly basis with the Active Directory group.

  4. If new users have been added to the group, they are added to the Project 2010 ERP.

  5. If users have been removed from the group they are flagged as inactive.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Active Directory Resource Pool Synchronization.

(Located in the Operational Policies section.)

The Active Directory Resource Pool Synchronization page appears.

4. Click the Find Group button.

A dialog box appears that enables you to select a group from Active Directory.

5. Select a Valid Active Directory Group.

6. Set the scheduling option.

Set it to update every night at 10 PM.

7. Set the resource options.

Set the group to automatically reactivate inactive users.

8. Click Save and synchronize now.

Project Server group should synchronise with the Active Directory group.

9. Do the following:

  • Add new people to the Active Directory group who are not in the EPM resource pool.

  • Run the sync.

  • Check whether they are resources in the enterprise resource pool.

Users added to the Active Directory Group are added to the Project Server ERP.

Active Directory Resource Pool synchronization (Part 2)

The Active Directory ERP synchronization only adds the resource to the ERP and the Team Member Security Group.

This test scenario explains how you can use Active Directory groups to grant users additional permissions to project data. For example, Contoso might want to grant Project Managers create-project permissions as soon as they start or it might want to grant executives automatic authentication in Project Web App for certain management reports in Project Server by default.

Important:

Active Directory ERP Sync must have the same users as the groups indicated in the custom groups in this section.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Contact the Active Directory administration.

  • Request that they create a new group such as PMOProjectManagers or PMOExecutives.

  • Request that they add some users to the groups so that you can test. For example, try using the same user names that you used in the previous test scenario.

2. Open Project Web App.

The Project Web App opens.

3. Click Server Settings.

The Server Settings page appears.

4. Click Manage Group.

A list of groups appears.

5. Click the group to put it in edit mode.

6. Click find group.

Locate the new Active Directory test group.

7. Click Save.

The Active Directory column has the group name in it that you selected.

Note:

In steps 8 - 10, you run the sync.

You can schedule the synchronization to run at night; however, you want to test whether it is working in this test scenario.

8. Hover over the group.

Click the Active Directory Sync Options button.

A dialog box that has several options appears.

9. Click Save and synchronize now.

The Active Directory Sync runs; wait several minutes.

10. After the Sync runs, check the Project Server groups details.

The same users that were added to the Active Directory group are now added to the Project 2010 group.

Project sites

This page enables the administrator to perform the following functions:

  • Create a SharePoint site for a Project

  • Edit the SharePoint site address

  • Synchronize the security between the sites

  • Delete a site

  • Open the project's SharePoint site

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Project Sites.

(Located in the Operational Policies section.)

The Project Site page appears.

Create a site for the project

1. Click a project.

2. Click the Create site button.

Edit the site address

If a site already exists and the URL is incorrect, the administrator can edit the URL.

1. Click a project.

2. Click the Edit Site Address button.

The Edit Site Address dialog box appears.

3. Select the Web Application and specify the desired site URL.

4. Click the TestURL button.

The site opens.

5. Click the OK button.

The changes are saved to the server.

Synchronize the security between the sites

Each site that is created has custom security permission levels that synchronize with security groups in Project Server.

For example, each site has the following security permission levels:

  • Web Administrators (Microsoft Project Server)

  • Project Managers (Microsoft Project Server)

  • Team Members (Microsoft Project Server)

  • Readers (Microsoft Project Server)

1. Click a project.

The toolbar is enabled.

2. Click the Synchronize button.

A dialog box appears.

3. Open the site as the administrator.

4. Click Site setting.

The site opens.

5. Click the advanced permissions menu.

(Located in the users and permissions section)

A list of users and groups appears.

6. Important:

Click the settings/permission levels sub menu to view the permission levels that exist.

After the synchronization is complete, the users are added, together with their related security permissions.

7. Try Again.

Delete all the users from the Project site.

Click the synchronize button again.

Refresh the list of users.

The users are displayed in the relevant Project site.

Delete a site

Important:

Deleting a site is permanent; use with caution.

1. Click a project.

2. Click the Synchronize button.

A dialog box appears.

3. Click the Delete button.

The system prompts you to confirm that you want to delete the site.

4. Click the TestURL button.

The site opens.

5. Click the OK button.

The site is deleted.

Open the projects site

1. Click a project.

2. Click the Go to Project Workspace site settings button.

The site opens.

Project site provisioning settings

Administrators use this page to define the configuration settings to use for new sites. For example, they might consider the following:

  • Should the site be automatically provisioned when a project is published by project managers?

  • Which instance of Microsoft SharePoint Server will be used when doing the provisioning?

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Project Site provisioning settings. (Located in the Operational Policies section.) | The Project Site provisioning settings page appears. |
4. Select the default Web Application. http://ServerName/ Specify the site URL. Example: To provision all the sites under the Project Server, specify Project Server. Thus, when sites are created, their URLs resemble the following: http://ServerName/PWA/Site1 http://ServerName/PWA/Site2 http://ServerName/PWA/Site3 |  |
5. Select the automatic provisioning setting. This way, PMs do not have to decide whether to create a SharePoint site. |  |
6. Select the automatically synchronize option. This way, team members/project managers can service the project's SharePoint site. |  |
7. Click Save. | Configuration settings are saved to the server. When new sites are created, they use the settings in this page. |

Bulk update project sites

Use this page to update the URL path of one or more project sites. You might have to run this tool after you restore or migrate a site or content database that contains project sites.

Test Step | Expected / Desired Results | Actual Results (if deviation)
1. Open Project Web App. | The Project Web App loads. |
2. Click Server Settings. | The Server Settings page appears. |
3. Click Bulk Update Project Sites. (Located in the Operational Policies section.) | The Bulk Update Project Sites page appears. |
4. Select the previous site path and URL and set the new set path and URL. Select or clear Update Content Types. Select or clear Synchronize site permissions. |  |
5. Click Save. | Configuration settings are saved to the server; the site paths change according to your specifications. |

Next steps

The following are the remaining articles in this series:

  • Testing Project Server 2010 deployments

  • Test security settings in Project Server 2010

  • Test enterprise data settings in Project Server 2010

  • Test database administration settings in Project Server 2010

  • Test look and feel settings in Project Server 2010

  • Test time and task management settings in Project Server 2010

  • Test queue settings in Project Server 2010

  • Test workflow and project detail pages in Project Server 2010


Test workflow and project detail pages in Project Server 2010

Published: November 29, 2011

Summary: The ninth article in a series of nine articles about how to test a Microsoft Project Server 2010 deployment as an enterprise project management system administrator or solution tester. Use the series as a guide to test the functionality of a newly deployed Project Server 2010 instance. The articles in this series discuss the functionalities that are on the Server Settings page, and some initial tests that you can run to connect and check server communications by using the Project Professional 2010 client application.

Contents

  • Enterprise Project Types

  • Next steps

Enterprise Project Types

Enterprise Project Types are a way to group phases, stages, a single workflow, business drivers, and project detail pages. Before project managers can use Enterprise Project Types when they create a project or proposal, a site administrator must define them in Microsoft Project Web App.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Enterprise Project Types.

(Located in the Workflow and Project Detail Pages section.)

The Enterprise Project Types appear.

4. Select New Enterprise Project Type.

Navigates to the Add Enterprise Project Type page.

5. In the Name, specify a name for the Enterprise Project Type.

6. In the Description field, type a description for the Enterprise Project Type.

7. In the Site Workflow Association field, choose a site workflow association for this Project Workflow.

For a 'Site Workflow' to appear in the list, you must install and configure it on the Microsoft Project Server computer.

Important:

Once you select an association it cannot be changed.

8. Choose the New Project Page for this enterprise project type.

  • This is the first Project Detail Page that users see after you create new projects in the Project Center.

  • If the 'No Workflow' option is selected as the Site Workflow Association, choose the Project Detail Pages that users see after the project is created.

  • The 'New Project Page' might also be visible after project creation. If any other option is selected as the Site Workflow Association, the Project Detail Pages are determined dynamically by the associated workflow.

9. Select the check box to choose whether this is the default Enterprise Project Type for Project creation.

The default Enterprise Project Type is used if no type is specified during Project Creation.

Important:

Making this default automatically clears all the departments. The default Enterprise Project Type cannot have a Project Plan Template associated with it.

10. Choose the Department association for this Enterprise Project Type.

Note:

This department association is used only for filtering the Enterprise Project Types on the Project Center and not for security.

Click the button with the ellipsis (…) on it to display a list of departments.

11. Specify an image for the Enterprise Project Type.

Note:

If you want to use an image that is located on your computer, you must first upload the image to an online document library such as the Shared Documents library in Project Web App, and then specify the image URL from there.

12. Select Order to determine the position that Enterprise Project Types display in the New button in the Project Center.

13. Choose a template to use when you create projects with this Enterprise Project Type.

If the drop-down list shows None only, there are no templates available.

To create project plan templates, use Project Professional 2010 connected to the server.

Note:

  • Avoid non-generic assignments in the project plan template; all assigned tasks are published when a project is being created.

  • The default Enterprise Project Type cannot have a Project Plan Template associated with it.

  • This template list is not filtered by department.

14. Choose a Project Site Template to use to create the project site.

15. Click Save.

The page navigates back to the Enterprise Project Types list. The newly saved Enterprise Project Type appears in the list.

Next steps

The following are the remaining articles in this series:

  • Testing Project Server 2010 deployments

  • Test security settings in Project Server 2010

  • Test enterprise data settings in Project Server 2010

  • Test database administration settings in Project Server 2010

  • Test look and feel settings in Project Server 2010

  • Test time and task management settings in Project Server 2010

  • Test queue settings in Project Server 2010

  • Test operational policy settings in Project Server 2010


Deploy Project Server 2010 to a test environment

Published: May 12, 2010

This series of articles describes deploying a test installation of Microsoft Project Server 2010 in a virtual environment. The purpose of this series is as follows:

  • Allows you to gain experience in the processes and procedures involved in deploying Project Server 2010

  • Provides you with an isolated test environment where you can gain experience with the features in Project Server 2010

This series of articles describes a test installation only. If you are deploying Project Server 2010 in a production environment, see Deploy Project Server 2010 to a server farm environment. If you are deploying Project Server 2010 to Hyper-V for production, see Virtualizing Project Server 2010.

The infrastructure described in this series of articles includes the following servers:

  • A domain controller for the virtual domain

  • A server that is running Microsoft SQL Server 2008 and Analysis Services 2008

  • A server that is running Microsoft SharePoint Server 2010 and Project Server 2010

Although you can install all of the described components on a single virtual or physical machine, we recommend that you create the individual virtual machines as described in these articles, as this provides a more realistic look at what a production installation looks like.

For the purposes of software installation, we assume that you have the given software on a CD or DVD, or that you have an ISO file that contains the software. If you have the software on a file or network share, we recommend that you create an ISO file for the purposes of installation in the virtual environment. There are many third-party applications that are available for creating ISO files, and ISO files can easily be mounted to the virtual DVD drive on Hyper-V virtual machines and those from other virtualization vendors.

To successfully create the environment described, you will need a computer that has 8GB of RAM and approximately 60GB of available disk space. The computer must be running Windows Server 2008 or Windows Server 2008 R2 with Hyper-V or another virtualization solution able to run 64-bit Windows Server 2008 virtual machines.

This series includes the following articles:

  • Hyper-V quick start for creating a Project Server 2010 test environment — Provides an overview of how to configure and use Hyper-V, how to create a virtual machine, and how to load an operating system on the virtual machine

  • Set up a domain controller for a Project Server 2010 test environment — Describes how to create a domain controller for the virtual domain

  • Add a virtual machine to the virtual domain in a Project Server 2010 test environment — Describes how to add a virtual machine to the domain

  • Set up accounts for a Project Server 2010 test environment — Lists the accounts that you will need to deploy Project Server 2010 and describes how to create them at the domain level

  • Set up SQL Server for a Project Server 2010 test environment — Describes how to install and configure SQL Server 2008 and the required updates for compatibility with Project Server 2010

  • Install SharePoint Server 2010 on a Project Server 2010 test environment — Describes how to install SharePoint Server 2010

  • Install and configure Project Server 2010 in a test environment — Describes how to install Project Server 2010

  • Create a PWA site in a Project Server 2010 test environment — Describes how to create a Project Web App site

  • Configure reporting for a Project Server 2010 test environment — Describes the steps that you must follow to configure the reporting and business intelligence features in Project Server 2010

These sections should be read sequentially, as the procedures in each build on those in the last. However, if you are already familiar with Hyper-V or if you are using a different virtualization solution or if you are using physical hardware, you can skip the "Hyper-V Quick Start" article.


Hyper-V quick start for creating a Project Server 2010 test environment

Published: May 12, 2010

(This article is part 1 of the Microsoft Project Server 2010 test environment deployment series. The articles in this series should be read sequentially, starting with this article, as the procedures in each build on those in the last.)

Hyper-V is the Microsoft virtualization solution. It is built into most versions of Windows Server 2008 and Windows Server 2008 R2. It offers an ideal platform to deploy a full-scale Microsoft Project Server 2010 test environment without the need to purchase multiple servers.

This article describes the steps that you must follow to enable Hyper-V and create virtual machines. If you are already familiar with Hyper-V, you can proceed to the next article, Set up a domain controller for a Project Server 2010 test environment.

Video demonstration

This demonstration shows the steps for enabling Hyper-V on Windows Server 2008.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=196700). To download the video file, right-click the link, and then click Save Target As.

Enable Hyper-V

The first step is to enable Hyper-V. Hyper-V is a server role on Windows Server 2008. To enable it, log on to the computer as an administrator and perform the following procedure.

To enable Hyper-V

  1. Click Start, click Administrative Tools, and then click Server Manager.

  2. In the left pane, click Roles.

  3. In the right pane, click Add Roles.

  4. If the Before You Begin page is displayed, click Next.

  5. On the Select Server Roles page, select the Hyper-V check box, and then click Next.

  6. On the Hyper-V page, click Next.

  7. On the Create Virtual Networks page, leave the network adapter check boxes cleared, and then click Next.

  8. On the Confirm Installation Selections page, click Install.

  9. On the Installation Results page, click Close.

  10. Restart the server.

Configure a virtual network

Once Hyper-V is enabled, you must create a virtual network within Hyper-V so that the virtual machines can communicate with one another. Two virtual networks are required:

  • An internal virtual network that allows the virtual machines to communicate with one another

  • An external virtual network that allows the virtual machines to communicate with your corporate network and the Internet. (This is required specifically during installation of Microsoft SharePoint Server 2010 to download the prerequisites.)

To configure an internal network, perform the following procedure.

To configure an internal virtual network

  1. Click Start, click Administrative Tools, and then click Hyper-V Manager.

  2. In the left pane, click the node of the local computer.

  3. In the right pane, click Virtual Network Manager.

  4. Click Internal, and then click Add.

  5. In the Name text box, type Internal Network.

  6. Ensure that the Internal only option is selected, and then click OK.

Once the internal network is created, create an external network by using the following procedure.

To configure an external virtual network

  1. Click Start, click Administrative Tools, and then click Hyper-V Manager.

  2. In the left pane, click the node of the local computer.

  3. In the right pane, click Virtual Network Manager.

  4. Click External, and then click Add.

  5. In the Name text box, type External Network.

  6. Select the External option, and select a network adapter from the drop-down list.

  7. Select the Allow management operating system to share this network adapter check box.

  8. Click OK.

  9. On the Apply Network Changes dialog box, click Yes.

Create virtual machines

When you have completed network configuration, you can start adding virtual machines to Hyper-V. To complete all the steps in this series of articles, you need the following virtual machines:

  • Litware-DC — domain controller

  • Litware-SQL — SQL Server 2008

  • Litware-Proj — SharePoint Server 2010 and Project Server 2010

Perform the following procedure for each virtual machine that you want to create.

To create a virtual machine

  1. Click Start, click Administrative Tools, and then click Hyper-V Manager.

  2. In the left pane, click the node of the local computer.

  3. In the right pane, click New, and then click Virtual Machine.

  4. On the Before You Begin page, click Next.

  5. In the Name text box, type the name that you want to use for the virtual machine, and then click Next.

  6. On the Assign Memory page, type a memory value appropriate for the virtual machine that you are creating.

  7. On the Configure Networking page, select External Network from the drop-down list, and then click Next.

  8. On the Connect Virtual Hard Disk page, leave the default values, and then click Next.

  9. On the Installation Options page, leave the Install an operating system later option selected and then click Next.

  10. Click Finish.

Loading an operating system

Once a virtual machine is created that has an empty hard disk, the next step is to install an operating system. Project Server 2010 requires Windows Server 2008 or Windows Server 2008 R2. We recommend that you use Windows Server 2008 or Windows Server 2008 R2 for each server virtual machine that you create. Perform the following procedure to install an operating system on a virtual machine.

To load an operating system on a virtual machine

  1. In Hyper-V Manager, right-click the virtual machine on which you want to load an operating system, and then click Settings.

  2. In the left pane, click DVD Drive.

  3. In the right pane, select the Image file option.

  4. Click Browse, and locate the ISO file that contains the operating system.

  5. Click OK.

  6. In Hyper-V Manager, double-click the virtual machine on which you want to load the operating system.

  7. In the Virtual Machine Connection window, click the Start icon on the toolbar.

  8. Install the operating system.

When you have created all of the virtual machines that you need and installed operating systems on each, the next step is to set up a domain controller. Proceed to the next article, Set up a domain controller for a Project Server 2010 test environment.


Set up a domain controller for a Project Server 2010 test environment
See Also

Published: May 12, 2010

(This article is part 2 of the Microsoft Project Server 2010 test environment deployment series. The procedures in this article assume that you have read the series in sequence starting with Hyper-V quick start for creating a Project Server 2010 test environment.)

This article describes how to set up a domain controller on a virtual machine that is running Windows Server 2008. This article and the remaining articles in this series assume that you have created the following infrastructure of virtual machines:

Virtual machine | Operating system
Litware-DC | Windows Server 2008
Litware-SQL | Windows Server 2008
Litware-Proj | Windows Server 2008

To perform the procedures in this article, log on to the Litware-DC virtual machine as an administrator.

Video demonstration

This video shows the steps involved in configuring a domain controller.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=196701). To download a copy, right-click the link, and then click Save Target As.

Configure the domain controller

The first step in setting up a domain controller is to set a static IP address. Domain controllers require static IP addresses to function correctly. Before you start, ensure that the network connection on the Litware-DC virtual machine is set to Internal Network.

In this series of articles, we are using the 10.0.0.0 - 10.255.255.255 IP address range that is reserved for private networks. This address range is used on the internal network for the virtual domain. In situations where the External Network is used (such as for downloading Microsoft SharePoint Server 2010 prerequisites from the Internet), we assume that your existing corporate network will assign an appropriate IP address to the network adapter by using dhcp.

Depending on the network configuration, you may be able to use the 10.0.0.0 - 10.255.255.255 IP address range on a network adapter connected to your corporate network. This would enable you to span the virtual machines across multiple physical host computers. However, you should beware of potential IP address conflicts when you use static IP addresses of any kind on a shared network.

Perform the following procedure to configure a static IP address.

To configure a static IP address

  1. Click Start, and then click Control Panel.

  2. Click Network and Internet.

  3. Click Network and Sharing Center.

  4. Click Change Adapter Settings.

  5. Right click the local area connection, and then click Properties.

  6. On the Local Area Connection Properties dialog box, clear the Internet Protocol Version 6 (TCP/IPv6) check box.

  7. Select Internet Protocol Version 4 (TCP/IPv4) and then click Properties.

  8. On the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, select the Use the following IP address option, and then type 10.0.0.1 in the IP address box.

  9. In the Subnet mask box, type 255.0.0.0.

  10. Select the Use the following DNS server addresses option, and then type 10.0.0.1 in the Preferred DNS server box.

  11. Click OK.

  12. Click Close.

Once you have set the static IP address, you are ready to promote the virtual machine to a domain controller. This is performed from the command line using the dcpromo command.

Note:

The password that you chose for the local administrator account for this virtual machine will become the domain administrator password as soon as the domain controller has been configured.

Perform the following procedure to configure the domain controller.

To configure the domain controller

  1. Click Start, click Run, type dcpromo, and then click OK.

  2. On the Welcome to the Active Directory Domain Services Installation Services page, click Next.

  3. On the Operating System Compatibility page, click Next.

  4. On the Choose a Deployment Configuration page, select the Create a new domain in a new forest option, and then click Next.

  5. In the Name the Forest Root Domain page, type litware.local in the FQDN of the forest root domain box, and then click Next.

  6. On the Set Forest Functional Level page, click Next.

  7. On the Set Domain Functional Level page, click Next.

  8. On the Additional Domain Controller Options page, ensure that the DNS server check box is selected, and then click Next.

  9. On the warning dialog box, click Yes.

  10. On the Location for Database, Log Files, and SYSVOL page, keep the default values, and then click Next.

  11. On the Directory Services Restore Mode Administrator Password page, type and confirm a password, and then click Next.

  12. On the Summary page, click Next.

  13. When the wizard has finished running, click Finish.

  14. Restart the virtual machine.

Once the domain controller setup is complete, you can add the other virtual machines to the domain. Proceed to the next article, Add a virtual machine to the virtual domain in a Project Server 2010 test environment.

See Also

Concepts

Deploy Project Server 2010 to a test environment


Add a virtual machine to the virtual domain in a Project Server 2010 test environment
See Also

Published: May 12, 2010

(This article is part 3 of the Microsoft Project Server 2010 test environment deployment series. The procedures in this article assume that you have read the series in sequence starting with Hyper-V quick start for creating a Project Server 2010 test environment.)

This article describes adding virtual machines to the litware.local domain. For Project Server 2010 to function correctly, you must add the remaining virtual machines to the domain before you install Microsoft SQL Server, Microsoft SharePoint Server 2010, and Project Server 2010.

For this series of articles, we assume the following IP address and minimum memory configuration for the domain:

Virtual machine | IP Address | RAM
Litware-DC | 10.0.0.1 | 512 MB
Litware-SQL | 10.0.0.2 | 2 GB
Litware-Proj | 10.0.0.3 | 2 GB
Note:

The memory configurations in this table are the minimum recommended for this configuration. If you experience performance issues, try adding memory, especially to the Litware-Proj virtual machine.

Video demonstration

This video shows the steps involved in configuring the virtual machine and joining it to the domain.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=196721). To download a copy, right-click the link, and then click Save Target As.

Configuring the virtual machine

As with the domain controller, each virtual machine must have the virtual network adapter set to Internal Network before you configure the static IP address.

Perform the following procedure for the Litware-SQL and Litware-Proj virtual machines. Use the IP addresses listed in the table.

To configure a static IP address

  1. Click Start, and then click Control Panel.

  2. Click Network and Internet.

  3. Click Network and Sharing Center.

  4. Click Change Adapter Settings.

  5. Right-click local area connection, and then click Properties.

  6. On the Local Area Connection Properties dialog box, clear the Internet Protocol Version 6 (TCP/IPv6) check box.

  7. Select Internet Protocol Version 4 (TCP/IPv4), and then click Properties.

  8. On the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, select the Use the following IP address option, and then type the IP address for the virtual machine that you are configuring in the IP address box.

  9. In the Subnet mask box, type 255.0.0.0.

  10. Select the Use the following DNS server addresses option, and then type 10.0.0.1 in the Preferred DNS server box.

  11. Click OK.

  12. Click Close.

Once the static IP address has been configured for each virtual machine, you can join the virtual machine to the litware.local domain. Perform the following procedure on the Litware-SQL and Litware-Proj virtual machines.

Note:

The default Windows Server 2008 firewall settings can interfere with the ability to join the computer to a domain. If you have problems joining the virtual machines to the domain, contact a network administrator for help. Because this is a private network that is not connected to the corporate network or the Internet, you can also consider turning off Windows Firewall.

To connect to the domain

  1. Click Start, right-click Computer, and then click Properties.

  2. Under Computer, name, domain, and workgroup settings, click Change settings.

  3. On the Computer Name tab, click Change.

  4. Select the Domain option, and then type litware.local.

  5. Click OK.

  6. In the Windows Security dialog box, type the user name and password of a domain account that has permissions to join the domain. (You can use the domain administrator account for this.)

  7. Click OK.

  8. On the Welcome to the domain dialog box, click OK.

  9. On the Computer Name/Domain Changes dialog box, click OK.

  10. Click Close.

  11. Restart the virtual machine.

Once the virtual machines have been joined to the litware.local domain, the next step is to set up the domain accounts that you will need for Project Server 2010 and its associated applications. Proceed to the next article, Set up accounts for a Project Server 2010 test environment.

See Also

Concepts

Deploy Project Server 2010 to a test environment


Set up accounts for a Project Server 2010 test environment
See Also

Published: May 12, 2010

(This article is part 4 of the Microsoft Project Server 2010 test environment deployment series. The procedures in this article assume that you have read the series in sequence starting with Hyper-V quick start for creating a Project Server 2010 test environment.)

To configure Project Server 2010 in a server farm environment, there are several domain accounts needed to provide the most optimal and secure configuration. This article describes how to create accounts and groups at the domain level for use in the remaining configuration steps in this series of articles.

Although you can use a single account for everything, we highly recommend that you create the accounts listed in the following table and use them as described in the remaining articles in this series to provide the recommended Project Server 2010 setup.

Account | Domain account | Description
SQL Server Administrator | Litware\SQLAdmin | Administrator account for SQL Server 2008. Local Administrator on Litware-SQL.
Farm Administrator | Litware\FarmAdmin | Farm Administrator for the Project Server 2010 farm. Local Administrator on Litware-Proj.
Service application account | Litware\SVCApp | Domain account for running SharePoint Server 2010 service applications.
Workflow proxy account | Litware\WFProxy | Domain account for running Project Server 2010 workflows.
Reporting data access account | Litware\ProjDataAccess | Domain account that has access to the reporting database for use with Secure Store as part of Project Server 2010 reporting.

To create these accounts, you must be logged on to Litware-DC as the domain administrator (litware\administrator).

Perform the following procedure for each account listed in the table.

To create an Active Directory service account

  1. Click Start, click Administrative Tools, and then click Active Directory Users and Computers.

  2. Expand the domain node.

  3. Right-click Users, click New, and then click User.

  4. In the Full name box, type the name of the account (for example, FarmAdmin).

  5. In the User logon name box, type the logon name for the account. (This can be the same as Full name.)

  6. Click Next.

  7. Type and confirm a password for the account.

  8. Clear the User must change password at next logon check box.

  9. Select the Password never expires check box.

  10. Click Next.

  11. Click Finish.

Configuring reporting and business intelligence in Project Server 2010 requires two Active Directory directory service groups — one for report authors and one for report viewers. These groups are given different permissions when you configure reporting.

Group | Domain group | Description
Report Authors | Litware\ProjReportAuthors | Active Directory group for report authors.
Report Viewers | Litware\ProjReportViewers | Active Directory group for report viewers.

Use the following procedure to create the two groups listed in this table.

To create an Active Directory group

  1. Click Start, click Administrative Tools, and then click Active Directory Users and Computers.

  2. Expand the domain node.

  3. Right-click Users, click New, and then click Group.

  4. Type a name for the group (for example, Report Authors) in the Group name box.

  5. Click OK.

After you have created the groups, add the Litware\ProjDataAccess account to the Litware\ProjReportAuthors group. This will give it the needed database access for use with Secure Store.

After you have created the required user accounts and groups in Active Directory, you can start to install software. The first step is to install SQL Server 2008. Proceed to the next article, Set up SQL Server for a Project Server 2010 test environment.

See Also

Concepts

Deploy Project Server 2010 to a test environment


Set up SQL Server for a Project Server 2010 test environment

Published: May 12, 2010

(This article is part 5 of the Microsoft Project Server 2010 test environment deployment series. The procedures in this article assume that you have read the series in sequence starting with Hyper-V quick start for creating a Project Server 2010 test environment.)

This article describes how to install and configure Microsoft SQL Server 2008 for use with Project Server 2010. Project Server 2010 requires one of the following versions of SQL Server:

  • Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2

  • Microsoft SQL Server 2005 SP3 with Cumulative update package 3 for SQL Server 2005 Service Pack 3

This article describes installing and configuring SQL Server 2008 SP1 with Cumulative update package 2 for SQL Server 2008 Service Pack 1.

Video demonstration

This video shows the steps involved in setting up SQL Server 2008 for use with Project Server 2010.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=196722). To download the video file, right-click the link, and then click Save Target As.

Configure a local administrator

We recommend that you install SQL Server 2008 while logged on with the SQL Server administrator domain account (Litware\SQLAdmin). Prior to doing this, you must add this account to the local Administrators group on the Litware-SQL virtual machine.

Log on to the Litware-SQL virtual machine with the domain administrator account (Litware\administrator) and perform the following procedure to add the Litware\SQLAdmin account to the local Administrators group.

To add a local administrator

  1. Log on to the virtual machine where you want to install SQL Server as a domain administrator.

  2. Click Start, click Administrative tools, and then click Computer Management.

  3. Expand Local Users and Groups, and then click Groups.

  4. In the right pane, right-click Administrators, and then click Properties.

  5. Click Add.

  6. Type the name of the SQL Server administrator account (Litware\SQLAdmin), and then click OK.

  7. Click OK.

  8. Log off the virtual machine.

To perform the remaining procedures in this article, log on to the Litware-SQL virtual machine with the Litware\SQLAdmin account.

Install SQL Server 2008

The first step is to install SQL Server 2008. SQL Server 2008 requires the .NET Framework version 3.5. If the .NET Framework 3.5 is currently not installed, you must install it or enable it as a feature in Windows Server 2008 before you continue.

Perform the following procedure to install SQL Server 2008 on Litware-SQL.

To install SQL Server 2008

  1. Attach the SQL Server 2008 DVD to the virtual machine DVD drive.

  2. Log on to the virtual machine where you want to install SQL Server as the SQL Server administrator.

  3. On the SQL Server DVD, double-click setup.exe.

  4. If a compatibility warning is displayed, click Run program.

  5. In the SQL Server Installation Center, in the left pane, click Installation.

  6. In the right pane, click New SQL Server stand-alone installation or add features to an existing installation.

  7. If a compatibility warning is displayed, click Run program.

  8. On the Setup Support Rules page, click OK.

  9. On the Product Key page, type your product key, and then click Next.

  10. On the License Terms page, review the license agreement and, if you agree, select the I accept the license terms check box, and then click Next.

  11. On the Setup Support Files page, click Install.

  12. On the Setup Support Rules page, click Next.

  13. On the Feature Selection page, select the following check boxes:

    • Database Engine Services

    • Analysis Services

    • Reporting Services

    • Management Tools - Complete

    Note:

    We also recommend that you install SQL Server Books Online.

  14. Click Next.

  15. On the Instance Configuration page, leave the Default instance option selected, and then click Next.

  16. On the Disk Space Requirements page, click Next.

  17. On the Server Configuration page, set an Account Name and Password for each service listed. We recommend that you use the SQL Server administrator account for this.

  18. Set the Startup Type for the SQL Server Agent service to Automatic.

  19. Click Next.

  20. On the Database Engine Configuration page, select the Mixed Mode option, and type and confirm a password for the built-in SQL Server administrator account.

  21. Click Add Current User to add the current user account as a SQL Server administrator.

  22. Click Next.

  23. On the Analysis Services Configuration page, click Add Current User to add the current user account as an Analysis Services administrator.

  24. Click Next.

  25. On the Reporting Services Configuration page, select the Install the native mode default configuration option, and then click Next.

  26. On the Error and Usage Reporting page, leave the default values and then click Next.

  27. On the Installation Rules page, click Next.

  28. On the Ready to Install page, click Install.

  29. When the setup process is complete, click Next.

  30. On the Complete page, click Close.

Install SQL Server 2008 updates

Windows Server 2008 requires Service Pack 1 for SQL Server 2008. If the version of SQL Server 2008 that you installed did not include Service Pack 1, then you must install Service Pack 1 next. Perform the following procedure to install Service Pack 1 for SQL Server 2008.

To install SQL Server 2008 SP1

  1. Attach the DVD that contains SQL Server 2008 SP1 to the virtual DVD drive.

  2. On the DVD drive, double-click the KB968369 executable file.

  3. On the Welcome page, click Next.

  4. On the License Terms page, review the license agreement and if you agree, select the I accept the license terms check box, and then click Next.

  5. On the Select Features page, click Select All, and then click Next.

  6. On the Check Files in Use page, click Next.

  7. On the Ready to Update page, click Update.

  8. On the Update Progress page, click Next.

  9. On the Complete page, click Close.

Microsoft SharePoint Server 2010 and Microsoft Project Server 2010 require Cumulative update package 2 for SQL Server 2008 Service Pack 1. Download the cumulative update at the following location:

http://support.microsoft.com/kb/970315 (http://go.microsoft.com/fwlink/p/?LinkID=165962)

Perform the following procedure to install Cumulative update package 2 for SQL Server 2008 Service Pack 1.

To install SQL Server 2008 SP1 CU2

  1. Attach the DVD that contains SQL Server 2008 SP1 CU2 to the virtual DVD drive.

  2. On the DVD drive, double-click the KB970315 executable file.

  3. On the Welcome page, click Next.

  4. On the License Terms page, review the license agreement and, if you agree, select the I accept the license terms check box, and then click Next.

  5. On the Select Features page, click Select All, and then click Next.

  6. On the Check Files in Use page, click Next.

  7. On the Ready to Update page, click Update.

  8. On the Update Progress page, click Next.

  9. On the Complete page, click Close.

  10. Restart the virtual machine.

When SQL Server 2008 and the required updates have been installed, the next step is to create a login for the Farm Administrator account (Litware\FarmAdmin) to provide the necessary permissions for SharePoint Server 2010 and Project Server 2010 installation and configuration.

Perform the following procedure to create a login for the Farm Administrator account.

To create a login for the Farm Admin

  1. In SQL Server Management Studio, expand Security, right-click Logins, and then click New Login.

  2. In the Login name box, type Litware\FarmAdmin.

  3. In the left pane, click Server Roles.

  4. Select the sysadmin and dbcreator server roles.

  5. Click OK.

Once the Farm Administrator account has been configured on SQL Server 2008, the next step is to install SharePoint Server 2010 on the Litware-Proj virtual machine. Proceed to the next article, Install SharePoint Server 2010 on a Project Server 2010 test environment.

Configure SQL Server network protocols

SharePoint Server 2010 requires that SQL Server 2008 allow connections over TCP/IP. Depending on your SQL Server configuration, this may or may not be enabled by default. Use the following procedure to confirm that TCP/IP access is enabled.

To enable connections over TCP/IP

  1. On the computer that is running SQL Server, click Start, click All Programs, click Microsoft SQL Server 2008, click Configuration Tools, and then click SQL Server Configuration Manager.

  2. Expand the SQL Server Network Configuration node.

  3. Click Protocols for MSSQLSERVER.

  4. In the Protocol Name list, confirm that TCP/IP is Enabled. If it is not, right-click TCP/IP, and then click Enable.

  5. If TCP/IP was disabled, restart the SQL Server service for the new setting to take effect.


Install SharePoint Server 2010 on a Project Server 2010 test environment

Published: May 12, 2010

(This article is part 6 of the Microsoft Project Server 2010 test environment deployment series. The procedures in this article assume that you have read the series in sequence starting with Hyper-V quick start for creating a Project Server 2010 test environment.)

This article describes how to install Microsoft SharePoint Server 2010 on the Litware-Proj virtual machine.

Video demonstration

This video shows the steps involved in setting up SharePoint Server 2010.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=196723). To download the video file, right-click the link, and then click Save Target As.

Install SharePoint Server

The first step in installing SharePoint Server 2010 is to install the SharePoint Server 2010 prerequisites. These can be automatically downloaded from the Internet and installed by the SharePoint Server 2010 prerequisite installer tool that is built into SharePoint Server 2010 setup.

Important:

The Enterprise edition of SharePoint Server 2010 is required for a Project Server 2010 deployment.

For the Litware-Proj virtual machine to be able to download the necessary updates, you must add a second virtual network connection to the Litware-Proj virtual machine and connect it to the External Network connection.

Note:

To add a network connection, the virtual machine must be turned off. When the virtual machine is off, right-click the virtual machine in Virtual Machine Manager, and then click Settings. On the Settings page, select Network Adapter in the Add Hardware section, and connect it to External Network.

Note:

If you cannot create an internet connection from the virtual machine, you can download the prerequisites from the Internet and create an ISO file that you can attach to the virtual machine DVD drive. For more information about what prerequisites are required, see Determine hardware and software requirements (SharePoint Server 2010).

For installation of SharePoint Server 2010 and its prerequisites, use the Litware\FarmAdmin account. This account must be a local administrator on the Litware-Proj virtual machine.

Log into the Litware-Proj virtual machine with the domain administrator account (Litware\administrator) and perform the following procedure to add the Litware\FarmAdmin account to the local Administrators group.

To add a local administrator

  1. Log into the virtual machine where you want to install SharePoint Server 2010 as a domain administrator.

  2. Click Start, click Administrative tools, and then click Computer Management.

  3. Expand Local Users and Groups, and then click Groups.

  4. In the right pane, right-click Administrators, and then click Properties.

  5. Click Add.

  6. Type the name of the SQL Server administrator account (Litware\FarmAdmin), and then click OK.

  7. Click OK.

  8. Log off the virtual machine.

To perform the remaining procedures in this article, log on to the Litware-Proj virtual machine with the Litware\FarmAdmin account.

To install the SharePoint Server 2010 prerequisites, perform the following procedure.

To install SharePoint Server 2010 prerequisites

  1. On the SharePoint Server 2010 DVD, run default.hta.

  2. On the SharePoint Server 2010 opening page, click Install software prerequisites.

  3. Follow the wizard to complete installation of all prerequisites.

    Note:

    Depending on your configuration, you may have to restart your computer during this process.

  4. When the wizard has finished, click Finish.

Once the prerequisites have been installed, you can install SharePoint Server 2010 itself. Perform the following procedure to install SharePoint Server 2010 on Litware-Proj.

To install SharePoint Server 2010

  1. On the SharePoint Server 2010 DVD, run default.hta.

  2. On the SharePoint Server 2010 opening page, click Install SharePoint Server.

  3. On the Enter your Product Key page, type your product key, and then click Continue.

  4. On the Read the Microsoft Software License Terms page, read the license agreement and accept the terms by selecting the I accept the terms of this agreement check box.

  5. Click Continue.

  6. On the Choose the installation you want page, click Server Farm.

  7. On the Server Type page, select the Complete - Install all components option.

  8. Click Install Now.

  9. On the Run Configuration Wizard page, leave the Run the SharePoint Products and Technologies Configuration Wizard now check box selected, and then click Close.

  10. On the Welcome to SharePoint Products page, click Next.

  11. On the warning dialog box, click Yes.

  12. On the Connect to a server farm page, select the Create a new server farm option, and then click Next.

  13. On the Specify Configuration Database Settings page:

    1. In the Database server box, type the name of the database server where you want to host the SharePoint Server 2010 databases (Litware-SQL).

    2. Type the user name and password of the database access account (litware\FarmAdmin).

    3. Click Next.

  14. On the Specify Farm Security Settings page, type and confirm a pass phrase for the farm, and then click Next.

  15. On the Configure SharePoint Central Administration Web Application page, select a port number for the SharePoint Central Administration Web site, and then click Next.

  16. On the Completing the SharePoint Products Configuration Wizard page, click Next.

  17. On the Configuration Successful page, click Finish.

Once SharePoint Server 2010 configuration has been completed, SharePoint Central Administration will open. There is no SharePoint Server 2010 configuration that is required before installing Project Server 2010. Therefore, you can close Central Administration.

Before continuing with the next article, Install and configure Project Server 2010 in a test environment, restart the Litware-Proj virtual machine.


Install and configure Project Server 2010 in a test environment
See Also

Published: May 12, 2010

(This article is part 7 of the Microsoft Project Server 2010 test environment deployment series. The procedures in this article assume that you have read the series in sequence starting with Hyper-V quick start for creating a Project Server 2010 test environment.)

This article describes installing Project Server 2010 and configuring the various Microsoft SharePoint Server 2010 and Project Server 2010 services that are required for running Project Server 2010. To do the steps in this article, log on to Litware-Proj using the Litware\FarmAdmin account.

Video demonstration

This video shows the steps involved in installing Project Server 2010 in the Hyper-V based test environment.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=196724). To download the video file, right-click the link, and then click Save Target As.

Install Project Server

The first step is to install Project Server 2010 on the Litware-Proj virtual machine. Perform the following procedure to install Project Server.

To install Project Server

  1. On the Project Server 2010 DVD, run default.hta. The Setup menu opens.

    Note:

    Default.hta may run automatically when you insert the disk.

  2. On the Start page, click Install Project Server.

  3. On the Enter your Product Key page, type your product key, and then click Continue.

  4. On the End User License Agreement page, review the terms of the agreement. To accept the agreement, select the I accept the terms of this agreement check box.

  5. Click Continue.

  6. On the Choose a file location page, click Install Now.

  7. When the installation is complete, select the Run the SharePoint Products and Technologies Configuration Wizard now check box.

  8. Click Close.

  9. On the Welcome to SharePoint Products page, click Next.

  10. On the warning dialog box, click Yes.

  11. On the Completing the SharePoint Products Configuration Wizard page, click Next.

  12. When the wizard is finished, click Finish.

Once Project Server 2010 is installed, the following configuration steps are required before creating a Microsoft Project Web App site and using Project Server 2010:

  • Register a managed account

  • Start the Project Application Service

  • Start the PerformancePoint Service

  • Create a Project Server service application

  • Create a PerformancePoint service application

  • Create a top-level Web site

  • Set Read permissions on the top-level Web site

  • Install SQL Server 2008 Analysis Management Objects

The procedures to complete these tasks are described in this article. Each of these procedures is completed by using the SharePoint Central Administration Web site.

Configure a managed account

Before you can use a domain account within SharePoint Server 2010, you must register it as a managed account.

The Litware\SVCApp account will be used to run the various service applications in this Project Server 2010. Perform the following procedure to register the Litware\SVCApp account as a managed account.

To register a managed account

  1. In SharePoint Central Administration, click Security.

  2. Under General Security, click Configure managed accounts.

  3. On the Managed Accounts page, click Register Managed Accounts.

  4. On the Register Managed Account page:

    1. In the User name box, type Litware\SVCApp.

    2. In the Password box, type the password for the Litware\SVCApp account.

    3. Click OK.

Configure services and service applications

The first step is to start the Project Application Service and the PerformancePoint Service on Litware-Proj.

To start the Project Application Service

  1. On the SharePoint Central Administration home page, in the System Settings section, click Manage services on server.

  2. On the Service list, click Start next to Project Application Service.

To start the PerformancePoint Service

  1. On the Central Administration home page, in the System Settings section, click Manage services on server.

  2. On the Service list, click Start next to PerformancePoint Service.

Once you have started the Project Application Service and PerformancePoint Service, you must create a service application for each service.

To create a Project Server service application

  1. On the Central Administration home page, in the Application Management section, click Manage service applications.

  2. On the Manage Service Applications page, on the ribbon, click New, and then click Project Server Service Application.

  3. On the Create Project Web App service application page:

    1. In the Project Web App service application name box, type Project Server Service App.

    2. In the Application Pool section, select the Create new application pool option, and in the Application pool name box, type ProjectAppPool.

    3. Select the Configurable option, and select the Litware\SVCApp account from the drop-down list.

    4. Click OK.

To create a PerformancePoint service application

  1. On the Central Administration home page, in the Application Management section, click Manage service applications.

  2. On the Manage Service Applications page, on the ribbon, click New, and then click PerformancePoint Service Application.

  3. On the New PerformancePoint Service Application page:

    1. In the Name box, type PerformancePoint Service Application.

    2. Select the Add this service application's proxy to the farm's default proxy list check box.

    3. In the Application Pool area, select the Create new application pool option, and in the Application pool name box, type PerformancePointAppPool.

    4. Select the Configurable option, and select the Litware\SVCApp account from the drop-down list.

    5. Click Create.

  4. When the service application has been successfully created, click OK.

Configure the top-level Web site

A Web application is required to host the Project Web App web site and the associated project sites. Perform the following procedure to create a Web application.

To create a Web application

  1. In Central Administration, in the Application Management section, click Manage Web applications.

  2. On the toolbar, click New.

  3. On the Create New Web Application page, keep the default values, and then click OK.

  4. When the Web application has been created, click OK.

The next step is to create a top-level Web site and give users read permission to that site.

To create a top-level Web site

  1. In Central Administration, in the Application Management section, click Create site collections.

  2. Type Litware in the Title box.

  3. In the Primary Site Collection Administrator section, type FarmAdmin.

  4. Click OK.

To set Read permissions on the top-level Web site

  1. Navigate to the root site (http://litware-proj).

  2. Click Site Actions.

  3. Click Site Permissions.

  4. Click Grant Permissions.

  5. In the Users/Groups box, type NT AUTHORITY\Authenticated Users.

  6. Under Give Permission, select Litware Visitors [Read].

  7. Click OK.

In order to use the reporting and business intelligence features of Project Server 2010, you must install the SQL Server 2008 Analysis Management Objects on the Litware-Proj virtual machine. Click the following link to download the Analysis Management Objects, and then install the package:

Analysis Management Objects (http://go.microsoft.com/fwlink/p/?LinkId=130655&clcid=0x409)

Once the Analysis Management Objects have been installed, proceed to the next article, Create a PWA site in a Project Server 2010 test environment.

See Also

Other Resources

Project Server 2010 Ignite Training: Planning, Design, and Deployment


Create a PWA site in a Project Server 2010 test environment

Published: May 12, 2010

(This article is part 8 of the Microsoft Project Server 2010 test environment deployment series. The procedures in this article assume that you have read the series in sequence starting with Hyper-V quick start for creating a Project Server 2010 test environment.)

In order to use Project Server 2010, you must create a Microsoft Project Web App (PWA) site. Log on to Litware-Proj using the Litware\FarmAdmin account, and perform the following procedures to create a PWA site.

Creating a PWA site takes five basic steps:

  1. Temporarily lock down existing content databases.

  2. Create a content database to host the PWA site and its associated project workspaces.

  3. Create the PWA site itself.

  4. Lock down the PWA content database to prevent additional site collections being added.

  5. Unlock existing content databases.

Video demonstration

This video shows the steps involved in creating a PWA site and configuring time reporting periods and the workflow proxy account.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=196725). To download the video file, right-click the link, and then click Save Target As.

Create a PWA site

SharePoint Server 2010 uses a round-robin algorithm to determine the distribution of site collections across content databases. In order to deploy the PWA site to a specific content database, you must lock down any existing content databases in the farm. The process does not affect user access; it only affects the distribution of new site collections.

To lock down your content databases, follow these steps.

Important:

Ensure that no other administrators are adding site collections to the Web application where you plan to deploy PWA while you are performing the procedures in this section.

To lock down a content database

  1. In the SharePoint Central Administration Web site, in the Application Management section, click Manage content databases.

  2. In the Current Number of Site Collections column, note the number of site collections for the WSS_Content database (this should be 1).

  3. In the Database Name column, click the link for the WSS_Content database.

  4. In the Database Capacity Settings section:

    1. In the Maximum number of sites that can be created in this database box, type the existing number of site collections for this database (as noted in the Current Number of Site Collections column, earlier in this procedure).

    2. In the Number of sites before a Warning event is generated box, type a lower number than the value that is used for Maximum number of sites that can be created in this database.

  5. Click OK.

To create a content database

  1. In SharePoint Central Administration, in the Application Management section, click Manage content databases.

  2. Click Add a content database.

  3. In the Database Name section, type PWA_Content.

  4. Click OK.

Once the content database has been created and configured, the next step is to create the PWA site itself.

To create a PWA site

  1. In the SharePoint Central Administration Web site, in the Application Management section, click Manage service applications.

  2. On the Manage Service Applications page, click the Project Server Service Application.

  3. On the Manage Project Web App Sites page, click Create Project Web App Site.

  4. Keep the default values, and then click OK.

Project Server 2010 starts the PWA site creation process. This may take some time. When the site creation process is complete, the status shown on the PWA site list is Provisioned.

Once the PWA site is provisioned, you can access it using the URL http://litware-proj/pwa.

Once the PWA site has been provisioned, verify that it was created in the PWA_Content database. Use the Get-SPSite Windows PowerShell command, passing the new content database as a parameter:

To verify the PWA site location

  1. On the Start menu, click All Programs.

  2. Click Microsoft SharePoint 2010 Products.

  3. Click SharePoint 2010 Management Shell.

  4. From the Windows PowerShell command prompt (that is, PS C:\>), type the following command and then press ENTER:

    Get-SPSite -ContentDatabase <ContentDatabaseName>

    The command should return the URL for your PWA site and no other URLs.

Once the PWA site is in the PWA_Content database, you must lock down the database to prevent SharePoint Server 2010 from adding additional site collections to the database. This is performed by configuring the maximum number of sites for the content database to one.

Note:

Configuring this setting does not prevent new project workspace sites from being created.

To lock down the content database

  1. In SharePoint Central Administration, in the Application Management section, click Manage content databases.

  2. In the Database Name column, click the link for the PWA_Content database.

  3. In the Database Capacity Settings section:

    1. In the Number of sites before a Warning event is generated box, type 0.

    2. In the Maximum number of sites that can be created in this database box, type 1.

  4. Click OK.

Once you have locked down your PWA content database, you can return the WSS_Content database to its original values for Maximum number of sites that can be created in this database (15000) and Number of sites before a Warning event is generated (9000).

You can now access the new PWA site.

Configuring server settings

Each time that you create a PWA site, there are two additional configuration steps that you must take before you start to use Project Server 2010:

  • Create time reporting periods

  • Set the workflow proxy user account

Configuring time reporting periods is required for Team Member use of Time Tracking and Task Statusing within Project Server 2010. Use the following procedure to create time reporting periods.

To create time reporting periods

  1. On the Project Web App site, click Server Settings.

  2. In the Time and Task Management section, click Time Reporting Periods.

  3. On the Time Reporting Periods page:

    1. Click the calendar button next to Date the first period starts and select a start date for the first time reporting period.

      Important:

      If you choose a length of seven days for a standard reporting period, all periods will begin on the day of the week you select for the first period start date. Choose a day of the week that conforms with the needs of your organization.

      Important:

      If you want to create variable-length periods, for example when you are using a period per calendar month, you must do these individually on the Time Reporting Periods page or programmatically through custom code.

    2. Click Create Bulk.

    3. Click Save.

The final step before you start to use the Project Web App site is to set the workflow proxy user account. By default, this account is set to the account that you used to create the PWA site. Although you can keep the default, we recommend that you use an account that was created for that purpose. In this case, we will use the Litware\WFProxy account. Note that you must change the account before you start any workflows or else in-progress workflows will break.

There are two steps that you must follow to set up the workflow proxy account:

  • Create a Project Server 2010 user account for the Litware\WFProxy account

  • Configure the Litware\WFProxy account as the workflow proxy user

Perform the following procedure to create a Project Server 2010 for the Litware\WFProxy account.

To create a user

  1. In Project Web App, click Server Settings.

  2. In the Security section, click Manage Users.

  3. On the Manage Users page, click New User.

  4. On the New User page:

    1. Clear the User can be assigned as a resource check box.

    2. In the Display Name box, type Workflow Proxy User.

    3. In the User Authentication section, type Litware\WFProxy in the User logon account box.

    4. Select the Prevent Active Directory synchronization for this user check box.

    5. In the Security Categories area, select My Organization in Available Categories, and then click Add.

    6. Under Permissions for My Organization, select Allow for the following permissions:

      • Open Project

      • Save Project to Project Server

      • View Enterprise Resource Data

    7. Under Global Permissions, select Allow for the following permissions:

      • Log On

      • Manage Users and Groups

      • Manage Workflow and Project Detail Pages

  5. Click Save.

Once the user account is created, you can set the workflow proxy user account. Perform the following procedure to configure the workflow proxy user account.

To set the workflow proxy user account

  1. In PWA, click Server Settings.

  2. On the Server Settings page, under Workflow and Project Detail Pages, click Project Workflow Settings.

  3. On the Project Workflow Settings page, in the Workflow Proxy User account box, type Litware\WFProxy, and then click Save.

You are now ready to start using the Project Web App site. The next step is to configure reporting to enable the Project Server reporting and business intelligence features. Proceed to the next article, Configure reporting for a Project Server 2010 test environment.


Configure reporting for a Project Server 2010 test environment
See Also

Published: May 12, 2010

(This article is part 9 of the Microsoft Project Server 2010 test environment deployment series. The procedures in this article assume that you have read the series in sequence starting with Hyper-V quick start for creating a Project Server 2010 test environment.)

This article describes the steps that you must follow to configure reporting for the Microsoft Project Web App (PWA) site. To configure reporting, you must follow these steps:

  • Add a login for a report author in SQL Server

  • Configure Excel Services

  • Configure Secure Store Service

Video demonstration

This video shows the steps involved in configuring reporting for Project Server 2010.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=196726). To download the video file, right-click the link, and then click Save Target As.

Configure SQL Server

In order for the report author to be able to access the Project Server 2010 Reporting database from Microsoft Excel, you must configure Microsoft SQL Server access and add a SQL Server login. The login must enable specific access to the Project Server 2010 Reporting database to gain access to schema information and data. Use the domain group that you created for report viewers (Litware\ProjReportAuthors).

To add a login for a report author

  1. Log on to Litware-SQL using the Litware\SQLAdmin account.

  2. Click Start, All Programs, Microsoft SQL Server 2008, SQL Server Management Studio.

  3. On the Connect to Server dialog box, type localhost in the Server name box, and then click Connect.

  4. Expand Security, right-click Logins, and then click New Login.

  5. On the General page, click Search.

  6. Click Object Types, and select the Groups check box.

  7. Click OK.

  8. Type Litware\ProjReportAuthors.

  9. Click Check Names.

  10. Click OK.

  11. Select the User Mapping page.

  12. In the Users mapped to this login list, select the row that contains the Project Server 2010 Reporting database (ProjectServer_Reporting).

  13. Select the Map check box for the Project Server 2010 Reporting database.

  14. Select the db_datareader database role membership check box.

  15. Click OK.

The remaining steps in this article are performed from the SharePoint Central Administration Web site. Log on to Litware-Proj using the Litware\FarmAdmin account.

Configure Excel Services

Project Server 2010 requires Excel Services in Microsoft SharePoint Server 2010. The first step to configuring Excel Services is to turn on the Excel Calculation Services service.

To turn on the Excel Calculation Services service

  1. On the SharePoint Central Administration Web site, in the System Settings section, click Manage services on server.

  2. In the Service list, click Start next to Excel Calculation Services.

Once the Excel Services service is running, the next step is to create an Excel Services service application.

To create an Excel Services service application

  1. On the SharePoint Central Administration Web site, in the Application Management section, click Manage service applications.

  2. On the Service Applications tab, click New, and then click Excel Services.

  3. In the Name box, type Excel Services Service App.

  4. In the Application pool name box, type ExcelServicesAppPool.

  5. Choose Liware\SVCApp from the Configurable list.

  6. Click OK.

Once Excel Services has been configured, you must configure trusted file locations for the Project Server 2010 Sample Reports and Templates libraries.

Follow this procedure two times: one time for each library.

To configure a trusted file location

  1. In Central Administration, in the Application Management section, click Manage service applications.

  2. Click the Excel Services service application.

  3. On the Manage Excel Services page, click Trusted File Locations.

  4. Click Add Trusted File Location.

  5. In the Address box, type:

    For the Templates library:

    http://litware-proj/pwa/ProjectBICenter/Templates/

    or

    For the Sample Reports library:

    http://litware-proj/pwa/ProjectBICenter/Sample%20Reports/

  6. Under Trust Children, confirm that the Children trusted check box is selected.

  7. In the External Data section:

    1. Under Allow External Data, select the Trusted data connection libraries and embedded option.

    2. Under Warn on Refresh, clear the Refresh warning enabled check box.

  8. Click OK.

You must configure trusted data connection libraries in order to give users access to the connectors that link the report spreadsheets to the data in the Project Server 2010 Reporting database and OLAP databases. Perform the following procedure to set up the trusted data connection libraries.

To set up trusted data connection libraries

  1. In Central Administration, in the Application Management section, click Manage Service Applications.

  2. Click the Excel Services service application.

  3. Click Trusted Data Connection Libraries.

  4. Click Add Trusted Data Connection Library.

  5. In the Address box, type:

    http://litware-proj/pwa/ProjectBICenter/Data%20Connections%20for%20PerformancePoint/English%20(United%20States)

  6. Click OK.

Configure Secure Store

In SharePoint Server 2010, the Secure Store Service enables users to access multiple system resources without having to provide authentication credentials multiple times. SharePoint Server 2010 implements Secure Store Service authentication by including a Windows service and a secure credentials database.

The next step is to configure Secure Store by turning on the Secure Store Service and creating a Secure Store Service service application. Perform the following procedure to turn on the Secure Store Service.

To turn on the Secure Store Service

  1. On the SharePoint Central Administration Web site, in the System Settings section, click Manage services on server.

  2. In the Service list, click Start next to Secure Store Service.

Once the Secure Store service is running, you must create a Secure Store Service Application. Use the following procedure.

To create a Secure Store Service service application

  1. On the SharePoint Central Administration Web site, in the Application Management section, click Manage service applications.

  2. On the Service Applications tab, click New, and then click Secure Store Service.

  3. In the Name box, type Secure Store Service Application.

  4. In the Application pool name box, type SecureStoreAppPool.

  5. Choose a managed account from the Configurable list.

  6. Click OK.

  7. When the service application has been successfully created, click OK.

When the Secure Store Service Application has been created, you must generate a Secure Store Service key before the Secure Store service can be used. Perform the following procedure to generate a key.

To generate a Secure Store Service key

  1. On the SharePoint Central Administration Web site, in the Application Management section, click Manage service applications.

  2. Click the Secure Store service application.

  3. On the Edit tab, click Generate New Key.

  4. Type and confirm a Pass Phrase, and then click OK.

Once Secure Store is configured, you must create a Secure Store target application.

To create a Secure Store target application

  1. On the SharePoint Central Administration Home page, in the Application Management section, click Manage Services Applications.

  2. Click the Secure Store Service.

  3. On the Secure Store Service page, select the Edit tab.

  4. Click New.

  5. On the Create New Secure Store Target Application page:

    1. In the Target Application ID box, type ProjectServerApplication.

      Note:

      This value is case-sensitive.

    2. In the Display Name box, type ProjectServerApplication.

    3. In the Contact Email box, type an e-mail address.

    4. From the Target Application Type drop-down list, select Group.

    5. Click Next.

  6. On the Specify the credential fields for your Secure Store Target Application page, click Next.

  7. On the Specify the membership settings page:

    1. In the Target Application Administrators box, type Litware\FarmAdmin.

    2. In the Members box, type Litware\ProjReportViewers.

    3. Click OK.

  8. On the Secure Store Service Application page, select the check box for the target application that you just created.

  9. On the ribbon, click Set Credentials.

  10. On the Set Credentials for Secure Store Target Application (Group) dialog box, type the user name and password of the Litware\ProjDataAccess account.

    Important:

    This account must have db_datareader permissions on the Project Server Reporting database. This can be achieved by adding the Litware\ProjDataAccess account to the Litware\ProjReportAuthors group.

  11. Click OK.

The Project Server 2010 reporting and business intelligence functionality is now configured and ready for use.

See Also

Other Resources

Project Server 2010 Ignite Training: Reporting Part 1
Project Server 2010 Ignite Training: Reporting Part 2


Install Project Server 2010 to a stand-alone computer
See Also

Published: May 12, 2010

Microsoft Project Server 2010 can be installed in a stand-alone configuration that uses Microsoft SQL Server 2008 Express. This configuration is useful for demonstration, but should not be used for a production environment.

The stand-alone configuration has fewer features than a full farm installation. Microsoft SQL Server Analysis Services (SSAS) and OLAP are not present in the stand-alone configurations. (Analysis Services and OLAP functionality can be configured to use a different instance of Microsoft SQL Server if you want.)

To install Project Server 2010 in stand-alone mode, you must first install Microsoft SharePoint Server 2010 in stand-alone mode. This includes installing the prerequisites for SharePoint Server 2010.

To install SharePoint Server 2010 prerequisites

  1. On the SharePoint Server 2010 DVD, run default.hta.

  2. On the SharePoint Server 2010 first page, click Install software prerequisites.

  3. Follow the wizard to complete installation of all prerequisites.

    Note:

    Depending on your configuration, you may have to restart your computer during this process.

  4. When the wizard has finished, click Finish.

Once the software prerequisites have been installed, you can install SharePoint Server 2010. Use the following procedure to install SharePoint Server 2010 in stand-alone mode.

To install SharePoint Server 2010

  1. On the SharePoint Server 2010 DVD, run default.hta.

  2. On the SharePoint Server 2010 first page, click Install SharePoint Server.

  3. On the Enter your Product Key page, type your product key, and then click Continue.

  4. On the Read the Microsoft Software License Terms page, read the license agreement and accept the terms by selecting the I accept the terms of this agreement check box.

  5. Click Continue.

  6. On the Choose the installation you want page, click Standalone.

    SharePoint Server 2010 will install.

  7. When the installation is complete, Click Close.

    The SharePoint Products Configuration Wizard starts.

  8. On the Welcome to SharePoint Products page, click Next.

  9. On the warning dialog box, click Yes.

  10. On the Configuration Successful page, click Finish.

Once SharePoint Server 2010 is installed, the next step is to install Project Server 2010 and run the SharePoint Products Configuration Wizard.

To install Project Server 2010

  1. On the Project Server 2010 DVD, run default.hta. The Setup menu opens.

    Note:

    default.hta may run automatically when you insert the disk.

  2. On the Start page, click Install Project Server.

  3. On the Enter your Product Key page, type your product key, and then click Continue.

  4. In the End User License Agreement page, review the terms of the agreement. To accept the agreement, select the I accept the terms of this agreement check box.

  5. Click Continue.

  6. On the Choose a file location page, click Install Now.

  7. When the installation is complete, click Close.

    The SharePoint Products Configuration Wizard starts.

  8. On the Welcome to SharePoint Products page, click Next.

  9. On the warning dialog box, click Yes.

  10. On the Configuration Successful page, click Finish.

When the SharePoint Products Configuration Wizard finishes, the system will automatically create a PWA site. This may take several minutes. When the site has been created, it can be accessed at http://<servername>/pwa.

Note:

The account that you used to install Project Server is automatically added to the Project Server Administrators group.

See Also

Concepts

Deploy Project Server 2010 to a server farm environment
Hardware and software requirements (Project Server 2010)


Deploy language packs (Project Server 2010)

Published: May 15, 2010

Microsoft Project Server 2010 language packs enable Project Server 2010 users to view Microsoft Project Web App and project sites in multiple languages without requiring separate installations of Project Server 2010. You can add language support for additional languages to Project Server 2010 by installing the language pack for the language that you want to add. Language packs are typically used in multinational deployments where one server farm supports people in different locations and users want to see Project Web App displayed in their preferred language.

Language packs are not bundled into multilingual installation packages. You must install a specific language pack for each language that you want to support.

In this article:

  • Available languages for Project Server 2010 language packs

  • Compatibility with SharePoint Server 2010 language packs

  • Deploy a Project Server 2010 language pack

  • Project site provisioning behavior when applying language packs

  • Uninstall language packs

Available languages for Project Server 2010 language packs

Project Server 2010 language packs are available for the following languages:

  • Arabic

  • Chinese (SC)

  • Chinese (TC)

  • Czech

  • Danish

  • Dutch

  • English

  • Finnish

  • French

  • German

  • Greek

  • Hebrew

  • Hungarian

  • Italian

  • Japanese

  • Korean

  • Norwegian (Bokmal)

  • Polish

  • Portuguese (Brazilian)

  • Russian

  • Slovak (New for Project Server 2010)

  • Slovenian (New for Project Server 2010)

  • Spanish

  • Swedish

  • Turkish

  • Ukrainian (New for Project Server 2010)

Compatibility with SharePoint Server 2010 language packs

Project Server 2010 language packs are bundled with language packs for several other Office Server products. When you download a 2010 Server Language Pack, it will contain the language pack for SharePoint Server 2010, Project Server 2010, Microsoft Search Server 2010, and Microsoft Office Web Apps.

SharePoint Server 2010 language packs differ from Project Server 2010 language packs in the functionality that they provide. SharePoint Server 2010 language packs allow site administrators to create sites in different languages, which requires the installation of language files on the computer. Project Server 2010 language files allow Microsoft Project Web App (PWA) and other project sites to be displayed in a different language.

Important:

Project Server 2010 does not support all of the languages that SharePoint Server 2010 supports.

The following languages are supported by SharePoint Server 2010, but are not available in Project Server 2010 language packs:

  • Basque

  • Bulgarian

  • Catalan

  • Croatian

  • Estonian

  • Galician

  • Hindi

  • Kazakh

  • Latvian

  • Lithuanian

  • Romanian

  • Serbian (Latin)

  • Thai

Therefore, the 2010 Server language pack for Romanian contains the SharePoint Server 2010 language pack, but does not contain a language pack for Project Server 2010.

Important:

Prior to the Project Server 2010 Cumulative Update (June 2010), installing a SharePoint Server 2010 language pack in a language not supported in Project Server 2010 would potentially cause issues if you then had to upgrade Microsoft Office Project Server 2007 data to the Project Server 2010 farm. If you are using Project Server 2010 and will be loading SharePoint Server 2010 language packs that are not available for Project Server 2010, you should consider the June 2010 Cumulative Update to be the minimum release level that you should be at. For more information about the Project Server 2010 Cumulative Update for June 2010, see Description of the Project Server 2010 hotfix package (Pjsrvwfe-x-none.msp): June 29, 2010.

For more information about SharePoint Server 2010 language packs, see Deploy language packs (SharePoint Server 2010).

Deploy a Project Server 2010 language pack

The steps for deploying a Project Server 2010 language pack and making the language available to users are as follows:

  1. Download the language pack

  2. Install the language pack

  3. Make the language available for the Project Web App site

  4. Specify the display language for the site

Download the language pack

You must perform the following steps for each language that you want to support. If you decide to download more than one language, be aware that a unique file that has a common name is downloaded for each language. Therefore, make sure that you download each language pack to a separate folder on the hard disk so that you do not overwrite a language pack of a different language.

To download the language pack

  1. In your Web browser, go to the 2010 Server Language Packs for SharePoint Server 2010, Project Server 2010, Search Server 2010, and Office Web Apps 2010 download page.

  2. On the 2010 Server Language Packs download page for SharePoint Server 2010, Project Server 2010, Search Server 2010, and Office Web Apps, select the language that you want from the Change Language list, and then click Change.

  3. The language displayed on the site now corresponds to the language selected in the previous step. Click Download on the Web page.

    Note:

    If the language on the page has not changed prior to clicking the Download command, verify that the language that you selected in step 2 is displayed in the Change Language field.

  4. In the dialog box that appears, click Save to download a copy of the file to the local computer.

    Note:

    If you are adding multiple language packs, you should rename the language pack file (ServerLangaugePack.exe) to a more descriptive name (for example, FrenchServerLangaugePack.exe). Because the default name for all language pack files is the same, renaming the file will help to prevent confusion when you are installing the language packs.

Install the language pack

If you have a server farm environment and you are installing language packs to support multiple languages, you must install each language pack on all application servers and Web servers in your farm.

If you are installing the Project Server 2010 language pack on a single-server farm, use the following procedure:

To install a Project Server 2010 language pack for a single-server farm deployment

  1. In Windows Explorer, double-click the ServerLanguagePack.exe file to start the installation.

  2. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  3. The Setup wizard runs and installs the language pack.

  4. Run the SharePoint Products Configuration Wizard, using the default settings.

If you are installing Project Server 2010 language packs for a multi-server farm deployment, use the following procedure:

To install a Project Server 2010 language pack for a multi-server farm deployment

  1. On a Web or application server in your farm, double-click the ServerLanguagePack.exe file to start the installation.

  2. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  3. The Setup wizard runs and installs the language pack.

  4. The Run Configuration Wizard page appears when the language pack installation is complete. Clear the Run the SharePoint Products Configuration Wizard now check box, and then click Close.

    Warning:

    Do not run the SharePoint Products Configuration Wizard at this time.

  5. On each Web and application server in the farm, install the language pack by using steps 1-4. Make sure not to run the SharePoint Products Configuration Wizard after you install the language pack.

    Note:

    If you are installing multiple language packs, install each one to all Web and application servers in the farm by using steps 1-5. Make sure not to run the SharePoint Products Configuration Wizard after installing the language pack.

  6. After installing the Project Server 2010 language pack to all Web and application servers in the farm, return to your original server and run the SharePoint Products Configuration Wizard. Use the following steps to run the wizard:

    1. Click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint 2010 Products Configuration Wizard.

    2. On the Welcome to SharePoint Products page, click Next.

    3. Click Yes in the dialog box that alerts you that some services might have to be restarted during configuration.

    4. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click Next.

    5. On the Configuration Successful page, click Finish.

  7. Run the SharePoint Products Configuration Wizard on all Web and application servers on the farm to complete the installation.

Make the language available for the Project Web App site

After installing the language pack, you now have to make the language available for the site. When you make the language available, you are making the language available on a site-by-site basis. For example, making the French language available for Project Web App only allows French to be available for Project Web App and project sites. The language must be made available for the Business Intelligence Center or for the SharePoint Central Administration Web site for it to be possible to display the site in that language.

Use the following procedure to select the language that you want to make available for the site.

To select a language for the site

  1. On the site, click Site Actions, and then click Site Settings.

  2. On the Site Settings page, in the Site Administration section, click Language Settings.

  3. On the Language Settings page, in the Alternate Language(s) section, click the check box next to the language that you want to make available for the site. If you have installed the Project Server 2010 language pack, the language for that language pack will be listed as an option for you to select.

    Note:

    You can select multiple languages if the site has to be available in more than one language.

  4. Click OK.

Specify the display language for the site

After you have specified the languages that are available for the site, users can then specify the language they want to display for that site. A site user can use the following procedure to display the site in an available language:

To select a display language

  1. On the site page, on the right side of the status bar, click the user account name to display the drop-down list, and then click Select Display Language.

  2. Available display languages for site will appear. Select the language in which you want the site to appear.

Project site provisioning behavior when applying language packs

Project Server 2010 project sites that are provisioned before a Project Server 2010 language pack is applied will still be viewable in the new language, if two conditions are met. Those conditions are as follows:

  1. The language is made available to Project Web App

  2. The user selects the new language to display

Once a language pack is applied, you can then choose which one should be the default language for the new site. It can either be the base language or any applied language pack. This choice is specified through the Project Site Provisioning settings on the Server Settings page.

To select a new default language for project sites

  1. On the Project Web App home page, click Server Settings.

  2. On the Server Settings page, in the Operational Policies section, click Project Site Provisioning Settings.

  3. On the Project Site Provisioning page, in the Default Site Properties section, click the Default site template language drop-down list to display the available languages.

  4. From the drop down list, select the language that you want as the default language for all newly provisioned project sites.

  5. Click OK.

If a project site is provisioned after a Project Server 2010 language pack is applied, the only slight difference is that the project site Web Part will display the Welcome to your site! heading in the new default language. Other wording on the site will follow any language made available and chosen by the user. The base language of the server will always be automatically selected as an alternate language if a default other than the base language is used for provisioning a site.

Uninstall language packs

Uninstalling Project Server 2010 language packs is not supported. Changes that have been made to the Project Server 2010 databases by the installation of language packs cannot be rolled back.

If you no longer want to make a language available for a site, clear the language from the list on the Language Settings page for the site.

To remove a language for the site

  1. On the Web site, click Site Actions, and then click Site Settings.

  2. On the Site Settings page, in the Site Administration section, click Language Settings.

  3. On the Language Settings page, in the Alternate Language(s) section, clear the check box next to the language that you want to make unavailable for the site.

  4. Click OK.


Deploy Project Server 2010 with Exchange Server

Published: June 24, 2010

These articles describe how to configure integration with Exchange Server, enabling Microsoft Project Server 2010 users to view Project Server tasks in Microsoft Outlook.

In order to perform these procedures, you must be member of the Project Server and Exchange Server administrator groups on the local computer.

In this section:

Important:

Exchange Synchronization to Project Server does not work on a Project Server 2010 deployment configured to use claims authentication.

  • Configure Project Server 2010 to work with Exchange Server 2007 SP2

  • Configure Project Server 2010 to work with Exchange Server 2010

  • Configure Exchange Server 2010 Impersonation


Configure Project Server 2010 to work with Exchange Server 2007 SP2
See Also

Published: May 12, 2010

This article describes how to configure integration with Exchange Server 2007 SP2, which enables Project Server 2010 users to view Project Server tasks in Microsoft Office Outlook. This functionality replaces the Outlook Add-in task status reporting functionality for non-time-phased tasks that is available in earlier versions of Project Server and enables task assignment updates that use percent complete or total work remaining. These task assignment updates are then auto-submitted to the Task Status Manager when the tasks are updated in the Exchange client.

In order to perform these procedures, you must be member of the Project Server and Exchange Server administrator groups on the local computer.

Note:

The procedures and Windows PowerShell commands in this article assume that you are using Exchange Server 2007.

Important:

Exchange Synchronization to Project Server will not work on a Project Server 2010 deployment configured to use Claims Authentication.

Configure Project Web App settings

To configure Exchange integration, the Project Server administrator must grant access to the instance of Exchange Server and the Exchange administrator must grant Exchange access to the Project Server farm administrator account.

To activate Exchange Server synchronization

  1. In Microsoft Project Web App (PWA), click Server Settings.

  2. In the Operational Policies section, click Additional Server Settings.

  3. On the Additional Server Settings page, in the Exchange Server Details section, select the Synchronize tasks check box and then click Save.

Each Exchange Client Access server in an Exchange farm needs a user account in PWA. This account allows Exchange to call the Project Server Exchange Web service when there are task updates that need to be synchronized. Perform the following procedure for each Exchange Client Access server.

To create a user account for an Exchange Client Access server

  1. In Project Web App, click Server Settings.

  2. In the Security section, click Manage Users.

  3. On the Manage Users page, click New User.

  4. On the New User page, clear the check box stating User can be assigned as a resource and type the name of the Exchange Client Access server in the Display Name box.

  5. In the User Authentication section, select the Windows Authentication, using the Windows account option, and type the name of the Exchange Client Access server computer account in the User logon account box.

  6. In the Security Groups section, in the Available Groups list, select Administrators and then click Add.

  7. Click Save.

Synchronization must set up for each individual Project Server user for whom you want to synchronize tasks. Perform the following procedure for each user.

To configure a user account for Exchange Server synchronization

  1. In Project Web App, click Server Settings.

  2. Under Security click Manage Users.

  3. In the users list click the name of the user that you want to configure.

  4. On the Edit User page, select the Synchronize Tasks check box

  5. Click Save.

When configuring Exchange, you have to know the application pool identity that is associated with your PWA site. Use the following procedure to determine the identity.

To determine the application pool identity for the Project Web App site

  1. On the SharePoint Central Administration Web site, in the Application Management section, click Manage Service Applications.

  2. On the Application Management page, click Manage Service Applications.

  3. On the Application Management page, highlight Project Service Application, and on the ribbon click Properties.

  4. In the properties window on the Manage Project Web App Service Application page, note the account configured to run the application pool. This account is required to configure Exchange Server settings in the next procedure.

Synchronization must be set up for each individual Project Server user for whom you want to synchronize tasks.

SSL Certificates

Project Server uses Secure Sockets Layer (SSL) to access Exchange Server 2007 and must trust the SSL certificate that was used by the Exchange farm. If you have a certificate issued by a trusted authority such as VeriSign, Project Server will trust the certificate. If your SSL certificate has not been issued by a trusted authority, you should export the certificate from the Exchange farm and import it as a trusted certificate on the computer that is running Project Server.

Exchange Server 2007 lets you use Internet Information Services (IIS) to save a copy of the certificate. Although IIS will still let you save a copy of the certificate in Exchange Server 2007, we don't recommend that you do this. Use the Export-ExchangeCertificate cmdlet to generate a copy of the certificate for importing to Project Server. After you've exported the SSL certificate in the form of a PKCS #12 file, the file can then be imported by using either the Import-ExchangeCertificate cmdlet or by using the Certificate Import wizard in the Exchange Management Console.

Configure Exchange Server settings

The next step is to configure Exchange Server. Use the following procedure to grant impersonation permission to the PWA application pool account. Perform this procedure on each Exchange Client Access server in an Exchange farm.

To grant farm administrator impersonation permissions

  1. Log on to the computer that is running Exchange Server as an administrator.

    Warning:

    If your farm uses a different account to run the Project Server Queue Service you may need to use that one in place of the farm administrator account.

  2. Click Start, All Programs, Microsoft Exchange Server 2007 SP2, Exchange Management Shell.

  3. At the prompt, type the following command:

    Add-ADPermission -Identity (get-exchangeserver).DistinguishedName -User (Get-User -Identity <AppPoolAccount>| select-object).identity -extendedRights ms-Exch-EPI-Impersonation

    Note:

    Enter the above where <AppPoolAccount> is the application pool account for the Project Server service application noted in the previous procedure.

Perform the following procedure for each Project Server user for whom you want to synchronize tasks with Exchange.

To configure an Exchange user

  1. Log on to the computer that is running Exchange Server as an administrator.

  2. Click Start, All Programs, Microsoft Exchange Server 2007 SP2, Exchange Management Shell.

  3. At the prompt, type the following command: Add-ADPermission -Identity"<ProjUser>"-User<FarmAdministrator>-extendedRights ms-Exch-EPI-May-Impersonate.

    Note:

    Enter the above where <ProjUser> is the name of the Project Server user that you are configuring and <FarmAdministrator> is the SharePoint Server farm administrator account.

See Also

Concepts

Deployment for Project Server 2010


Configure Project Server 2010 to work with Exchange Server 2010
See Also

Published: May 12, 2010

This article describes how to configure integration with Microsoft Exchange Server 2010, which enables Microsoft Project Server 2010 users to view Project Server tasks in Microsoft Outlook. This functionality replaces the Outlook Add-in task status reporting functionality for non-time-phased tasks that is available in previous versions of Project Server and enables task assignment updates that use percent complete or total work remaining. These task assignment updates are then auto-submitted to the Task Status Manager when the tasks are updated in the Exchange client.

Note:

Exchange integration is not supported on Project Server standalone installations.

In order to perform these procedures, you must be a member of the Project Server and Exchange Server administrator groups on the local computer.

Note:

The procedures and Windows PowerShell commands in this article assume that you are using Exchange Server 2010.

Important:

Exchange Synchronization to Project Server will not work on a Project Server 2010 deployment configured to use Claims Authentication.

Video demonstration

This video shows the steps involved in configuring integration with Exchange Server.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=202797). To download the video file, right-click the link, and then click Save Target As.

Configure Project Web App settings

To configure Exchange integration, the Project Server administrator must grant access to the instance of Exchange Server and the Exchange administrator must grant Exchange access to the Project Server farm administrator account.

To start Exchange Server synchronization

  1. In Microsoft Project Web App (PWA), click Server Settings.

  2. In the Operational Policies section, click Additional Server Settings.

  3. On the Additional Server Settings page, in the Exchange Server Details section, select the Synchronize tasks check box and then click Save.

Each Exchange Client Access server in an Exchange farm needs a user account in PWA. This account allows for Exchange to call the Project Server Exchange Web service when there are task updates that have to be synchronized. Perform the following procedure for each Exchange Client Access server.

To create a user account for an Exchange Client Access server

  1. In Project Web App, click Server Settings.

  2. In the Security section, click Manage Users.

  3. On the Manage Users page, click New User.

  4. On the New User page, clear the check box stating User can be assigned as a resource and type the name of the Exchange Client Access server in the Display Name box.

  5. In the User Authentication section, select the Windows Authentication, using the Windows account option, and type the name of the Exchange Client Access server computer account in the User logon account box.

  6. In the Security Groups section, in the Available Groups list, select Administrators, and then click Add.

  7. Click Save.

Synchronization must be set up for each Project Server user for whom you want to synchronize tasks. Perform the following procedure for each user.

To configure a user account for an Exchange Server synchronization

  1. In Project Web App, click Server Settings.

  2. In the Security section, click Manage Users.

  3. In the Users list, click the name of the user whom you want to configure.

  4. On the Edit User page, select the Synchronize Tasks check box.

  5. Click Save.

When configuring Exchange, you have to know the application pool identity that is associated with your PWA site. Use the following procedure to determine the identity.

To determine the application pool identity for the Project Web App site

  1. On the SharePoint Central Administration Web site, in the Application Management section, click Manage Service Applications.

  2. On the Application Management page, click Manage Service Applications.

  3. On the Application Management page, highlight Project Service Application, and on the ribbon click Properties.

  4. In the properties window on the Manage Project Web App Service Application page, note the account configured to run the application pool. This account is required to configure Exchange Server settings in the next procedure.

Synchronization must be set up for each Project Server user for whom you want to synchronize tasks.

SSL Certificates

Project Server uses Secure Sockets Layer (SSL) to access Exchange Server and must trust the SSL certificate that was used by the Exchange farm. If you have a certificate issued by a trusted authority such as VeriSign, Project Server will trust the certificate. If your SSL certificate has not been issued by a trusted authority, you should export the certificate from the Exchange farm and import it as a trusted certificate on the computer that is running Project Server.

Previous versions of Microsoft Exchange Server 2010 let you use Internet Information Services (IIS) to save a copy of the certificate. Although IIS will still let you save a copy of the certificate in Exchange Server 2010, we don't recommend that you do this. Use the Export-ExchangeCertificate cmdlet to generate a copy of the certificate for importing to Project Server. After you've exported the SSL certificate in the form of a PKCS #12 file, the file can then be imported by using either the Import-ExchangeCertificate cmdlet or by using the Certificate Import wizard in the Exchange Management Console.

Configure Exchange Server settings

The next step is to configure Exchange Server. Use the following procedure to grant impersonation permission to the PWA application pool account. Perform this procedure on each Exchange Client Access server in an Exchange farm.

To grant farm administrator impersonation permissions

  1. Log on as an administrator to the computer that is running Exchange Server.

    Warning:

    If your farm uses a different account to run the Project Server Queue Service you may need to use that one in place of the farm administrator or application pool accounts.

  2. Click Start, then click All Programs, then click Microsoft Exchange Server 2010, and then click Exchange Management Shell.

  3. At the prompt, type the following command:

    Add-ADPermission -Identity (get-exchangeserver).DistinguishedName -User (Get-User -Identity <AppPoolAccount>| select-object).identity -extendedRights ms-Exch-EPI-Impersonation

    <AppPoolAccount> is the application pool account for the Project Server service application noted in the above procedure.

Note:

The <FarmAdministrator> account may also be used in the above procedure.

Perform the following procedure for each Project Server user for whom you want to synchronize tasks with Exchange.

To configure an Exchange user

  1. Log on to the computer that is running Exchange Server as an administrator.

  2. Click Start, All Programs, Microsoft Exchange Server 2010, Exchange Management Shell.

  3. At the prompt, type the following command:

    Add-ADPermission -Identity"<ProjUser>"-User<FarmAdministrator>-extendedRights ms-Exch-EPI-May-Impersonate

    <ProjUser> is the name of the Project Server user whom you are configuring, and <FarmAdministrator> is the SharePoint Server farm administrator account.

See Also

Concepts

Deployment for Project Server 2010


Configure Exchange Server 2010 Impersonation
See Also

Published: June 24, 2010

This article describes how to configure Exchange Server Impersonation when you configure the integration of Microsoft Project Server 2010 in a Microsoft Exchange Server 2010 environment that has more than one computer that is running Exchange Server.

Configuring Exchange Impersonation is a resolution to the event log error PSError: GeneralExchangeSyncError (40500) System.Web.Services.Protocols.SoapException: The account does not have permission to impersonate the requested user.

In order to perform these procedures, you must be a member of the Project Server and Exchange Server administrator groups on the local computer.

Note:

The procedures and Windows PowerShell commands in this article assume that you are using Exchange Server 2010.

Important:

Exchange Synchronization to Project Server does not work on a Project Server 2010 deployment configured to use claims authentication.

Configure Exchange Impersonation for all users in an organization

Because Microsoft Exchange Server 2010 uses the Role Based Access Control permissions model, you must first assign the ApplicationImpersonation role to Project Server users in the organization by using the New-ManagementRoleAssignment command in the Exchange Management Shell.

To configure Exchange Impersonation for all users in an organization

  1. Open the Exchange Management Shell.

  2. Run the New-ManagementRoleAssignment command to add the permission to impersonate the specified user. The following example details how to configure Exchange Impersonation to enable a service account to impersonate all other users in an organization.

    Copy Code
    New-ManagementRoleAssignment -Name <impersonationAssigmentName> -Role applicationImpersonation -User <serviceAccount>

Each Exchange Client Access Server (CAS) role in an Exchange Server farm needs a user account in Microsoft Project Web App (PWA). This account allows for Exchange to call the Project Server Exchange Web service when there are task updates that have to be synchronized. Perform the following procedure for each Exchange Client Access server.

Configure Exchange Impersonation for specific users or groups of users

Whether for policy or even size of the Exchange Server deployment, you might have to configure Exchange Server impersonation only for specific users or groups. This can be achieved by creating a new management scope for the Exchange Role Based Access Control permissions.

To configure Exchange Impersonation for specific users or groups of users

  1. Open the Exchange Management Shell.

  2. Run the New-ManagementScope command to create a scope to which the impersonation role can be assigned.

    The following example shows how to create a management scope for a specific group.

    Copy Code
    New-ManagementScope -Name <scopeName> -RecipientRestrictionFilter <recipientFilter>

  3. Run the New-ManagementRoleAssignment command to add the permission to impersonate the members of the specified scope. The following example shows how to configure Exchange Impersonation to enable a service account to impersonate all users in a scope.

    Copy Code
    New-ManagementRoleAssignment -Name <impersonationAssignmentName> -Role <ApplicationImpersonation> -User <serviceAccount> -CustomRecipientWriteScope <scopeName>

The RecipientRestrictionFilter parameter of the New-ManagementScope command defines the members of the scope. You can use properties of the identity object to create the filter.

After impersonation permissions have been established, the user who has impersonation permissions can make calls against the other user's account. For information about how to use Exchange Impersonation in an Exchange Web Services request, see Configuring Exchange Impersonation (http://go.microsoft.com/fwlink/p/?LinkId=195376) in the MSDN Library Online.

See Also

Concepts

Deployment for Project Server 2010
Configure Project Server 2010 to work with Exchange Server 2010


Upgrade to Project Server 2010

Published: December 2, 2010

This section of the Microsoft Project Server documentation covers the process of upgrading to Project Server 2010.

  • Microsoft Project Server 2010 SuperFlow

    Describes and links to the SuperFlow, a self-contained interactive Help file that provides a collection of technical content for upgrading to Project Server 2010.

  • TechNet Webcast: Project Server 2010 upgrade and migration

    This Microsoft TechNet Webcast discusses Microsoft Project Server 2010 features, requirements, and deployment considerations that IT professionals need to know about.

  • Backward compatibility mode (Project Server 2010 TechNet Webcast)

    This Microsoft TechNet Webcast discusses the Microsoft Project Server 2010 Backwards Compatibility Mode (BCM) feature, which helps you to accelerate deployment of Microsoft Project 2010.

  • Backward compatibility mode (BCM) (Project Server 2010)

    These articles discuss backward compatibility mode (BCM) and how to create a Microsoft Project Web App in BCM.

  • SQL script for known Project Server 2010 upgrade issues

    This article describes how to run a data validation check on your Office Project Server 2007 databases to look for known conditions that may cause an upgrade failure.

  • Upgrade from a trial version of Project Server 2010

    This article contains information and a procedure on how to upgrade from a trial version of Microsoft Project Server 2010 to a full product edition.

  • Upgrade from a trial version of Project Server 2010

    This article describes how to upgrade from the Project Server 2010 Trial version to the fully licensed version of Project Server 2010.

  • In-place upgrade to Project Server 2010

    This article describes the process of doing an in-place upgrade from Microsoft Office Project Server 2007 to Project Server 2010.

  • Upgrade considerations for Project Web App Web Parts

    This article describes the corrective actions that are necessary for PWA Web Parts when you upgrade from Microsoft Office Project Server 2007 to Microsoft Project Server 2010.

  • Database-attach full upgrade to Project Server 2010

    This article describes how to do a database-attach full upgrade to Project Server 2010, in which you back up the required databases in the old farm and then restore them in the new farm.

  • Database-attach core upgrade to Project Server 2010

    This article describes how to do a database-attach core upgrade to Project Server 2010, in which you are basically using backup copies of your Office Project Server 2007 databases that contain your project data.

  • Virtual migration environment (VME) guide for Project Server 2010

    The Project Server VME is a virtualized Office Project Server 2007 environment that contains all the necessary applications and utilities required to migrate Microsoft Office Project Server 2003 data to Office Project Server 2007. To migrate from Project Server 2003 to Project Server 2010, first you must migrate your data to Office Project Server 2007 format.

  • Upgrade to Project Server 2010 from Project Server 2003

    This series of articles provides information and procedures about how to migrate from Microsoft Office Project Server 2003 to Project Server 2010.


Microsoft Project Server 2010 SuperFlow

Published: June 5, 2012

The Microsoft Project Server 2010 Upgrade SuperFlow is a self-contained guide that resembles and interactive Help file. It can be downloaded and installed to your local computer, and can then be used even if you are not connected to the Internet. This specific SuperFlow gives you information that you need to upgrade to Project Server 2010. It provides information that is common to each upgrade path—planning, preparation, and specific procedures for each supported upgrade method. This guide also gives you information about how to download and use the Project Server 2010 virtual migration environment—the recommended method for upgrading Microsoft Office Project Server 2003 data to Office Project Server 2007 (which you can then upgrade to Project Server 2010).

Note:

To install the SuperFlow, you must have Microsoft .NET Framework 3.5 on your local computer.

To install the Microsoft Project Server 2010 Upgrade SuperFlow

  1. Download the SF_ProjectServer201Upgrade.msi file from the SuperFlow for Microsoft Project Server 2010 Upgrade page in the TechNet Gallery (http://go.microsoft.com/fwlink/p/?LinkId=253657).

  2. Run the SF_ProjectServer201Upgrade.msi file and follow the installation instructions in the wizard.

The Project Server 2010 Upgrade SuperFlow is installed in a Start menu group that is named Microsoft SuperFlows.


TechNet Webcast: Project Server 2010 upgrade and migration

Published: May 12, 2010

This Microsoft TechNet Webcast discusses Microsoft Project Server 2010 features, requirements, and deployment considerations that IT professionals need to know about. Topics discussed in this Webcast include upgrade options from both Microsoft Office Project Server 2003 and Microsoft Office Project Server 2007 to Microsoft Project Server 2010. Topics also include tools, processes, scenarios, best practices for upgrade and migration, the effect on Project Server of coexisting with SharePoint 2010 Products, and full-farm versus split-farm upgrades.

The presenters in this Webcast are:

  • Jean-Francois LeSaux, EPM Lead Architect, Microsoft Corporation

  • Steven Haden, Senior Consultant, Microsoft Corporation

TechNet Webcast: Project Server 2010 Upgrade and Migration

Note:

This Webcast is one of seven available in a series. For a complete list of all available Webcasts from this series, see Project Server 2010 IT-Professional TechNet Webcasts.


Backward compatibility mode (Project Server 2010 TechNet Webcast)

Published: May 12, 2010

This Microsoft TechNet Webcast discusses the Microsoft Project Server 2010 Backwards Compatibility Mode (BCM) feature, which helps you to accelerate deployment of Microsoft Project 2010. With BCM, various desktop and server versions of Microsoft Project can seamlessly coexist and exchange data. BCM exists on Project 2010 desktop applications and Microsoft Project Server 2010, and in certain scenarios BCM makes it possible for Microsoft Office Project Professional 2007 to access Project Server 2010. We advise you to view TechNet Webcast: Project Server 2010 Upgrade and Migration (http://go.microsoft.com/fwlink/p/?LinkId=190247) prior to attending this Webcast.

The presenter in this Webcast is Jan Kalis (Senior Technical Product Manager, Microsoft Corporation).

TechNet WebCast: Project Server 2010 - Backwards Compatibility Mode

Note:

This Webcast is one of seven in a series. For a complete list of all available Webcasts from this series, see Project Server 2010 IT-Professional TechNet Webcasts.


Backward compatibility mode (BCM) (Project Server 2010)

Published: December 2, 2010

Backward compatibility mode (BCM) is a feature in upgraded Microsoft Project Server 2010 environments that allows for connectivity from both Project Professional 2010 and Project Professional 2007 SP2 clients. This feature allows you the convenience of upgrade your Project Professional clients (it does not have to be done the same time as the server upgrade). It is also possible to create a new Project Server 2010 Project Web App site in backward compatibility mode if you create the site with empty Office Project Server 2007 databases.

For more information about BCM, see the following articles:

  • Project Server 2010 backward compatibility mode (BCM)

  • Create a PWA site in backward compatibility mode (Project Server 2010)


Project Server 2010 backward compatibility mode (BCM)
See Also

Published: December 2, 2010

Backward compatibility mode (BCM) is a feature in Project Server 2010 that assists in the upgrade of your Enterprise Project Management environment. Project Server 2010 accepts connections from the Microsoft Project Professional 2010 client, but it can also accept connections from Microsoft Office Project Professional 2007 with Service Pack 2 (SP2) if BCM is enabled in Project Server 2010. BCM is enabled automatically after you upgrade to Project Server 2010. After you upgrade to Project Server 2010 (by either the in-place or database-attach upgrade method), BCM allows you to avoid having to upgrade your Office Project Professional 2007 client computers at the same time. Because Project Server 2010 accepts connections from both Office Project Professional 2007 SP2 and Project Professional 2010 clients when BCM is enabled, you can decide to upgrade your clients later, and in batches (running in a mixed environment), if you want. When you have finished upgrading the clients to Project Professional 2010, you can turn off BCM in Project Server 2010 server settings, which then allows for only Project Professional 2010 connections.

Note:

Microsoft Office Project Professional 2003 cannot connect to Project Server 2010, even if BCM is enabled.

For more information about BCM, you can also view the training video TechNet WebCast: Project Server 2010 - Backward Compatibility Mode.

Disabling backward compatibility mode

When BCM is disabled in Project Server 2010, Project Server is running in Native mode. In Native mode, only Project Professional 2010 clients are able to connect to Project Server 2010. However, Project Professional 2010 features that were not available in BCM (such as manually scheduled tasks), become available in Native mode.

Important:

Once BCM is disabled, it cannot be re-enabled. Verify that you want to disable BCM if you are going to make the change.

Note:

Microsoft Office Project Professional 2003 cannot connect to Project Server 2010, even if BCM is enabled.

To disable Backward Compatibility Mode

  1. On the Project Server 2010 home page, click Server Settings.

  2. On the Server Settings page, in the Operational Policies section, click Additional Settings.

  3. On the Additional Settings page, in the Project 2007 Compatibility Mode section, clear the Enable Project 2007 Compatibility Mode check box.

  4. Click OK.

  5. After making the change, you must check out and open the Enterprise Global file in Microsoft Project Professional 2010. In the Enterprise Global file, make a very minor change (for example, dragging the splitter bar on the screen), save the file, and then check it back in. This is required to upgrade the Enterprise Global file to the newer version of the Microsoft Project Professional client.

Important:

The Enterprise Global file must be upgraded to the Project Professional 2010 client after BCM is disabled (step 5 in this procedure). This step ensures that all new projects are in native mode with all Project Professional 2010 features enabled. (All new projects are based on the Enterprise Global file). Neglecting to upgrade the Enterprise Global file with the Microsoft Project Professional client can lead to serious problems. Objects in the file (for example, views, tables, filters) will remain in Office Project 2007 format and they will be expected to be in Project 2010 format when new projects are created.

We recommend that BCM be enabled only as a temporary measure to help in the upgrade process. When Project Server 2010 is configured in backward compatibility mode, Project Professional 2010 clients that connect with Project Server 2010 have certain features that are disabled. These include the following:

  • Manually scheduled tasks are not available on the server or client.

  • Tasks cannot be set to inactive.

  • Font strikethrough is not available.

  • All departmental custom fields are enforced in Office Project Professional 2007.

All new features that are available in Project Professional 2010 (for example, Timeline, Team Planner, 32-bit colors) are available to Project Professional 2010 users, but not to Office Project Professional 2007 SP2 users.

Office Project Professional 2007 SP2 connecting to Project Server 2010 in BCM mode is blocked from providing functionality that requires loading a Microsoft Project Web App page in the client. This includes doing approvals and opening enterprise resources. As a workaround, you can use Project Web App on a Web browser to do these functions until you are ready to upgrade to Project Professional 2010.

Additionally, workflow-controlled custom fields are not available in Office Project Professional 2007 SP2.

Note:

Project Web App access to Project Server 2010 requires that you use either Windows Internet Explorer 7 or Windows Internet Explorer 8 as your Web browser. For more information, see Plan browser support (Project Server 2010).

Projects with cross-project links

Project Server 2010 prevents you from creating cross-project type links (resource sharing, cross-project dependencies, and master/subproject) on mixed Project file versions. For example, you cannot create a cross-project link from a project that is in Compatibility mode (Office Project 2007 format) with one that is in the Native mode (Project 2010 format). What this means is that after you disable backward compatibility mode, as you open and save projects, they are converted to Native mode. However, projects that have not been opened and saved remain in Compatibility mode. Project Server 2010 does not allow you to create or even connect projects that are in different modes. Therefore, your cross-project links do not fully function until all of the related projects are opened and saved so that they are all in Project 2010 format.

Enabling backward compatibility mode on a new instance of Project Server 2010

By default, in non-upgrade installations of Project Server 2010, the BCM option is not available (the option is not available within the Server Settings page). However, it is possible to use BCM with a new instance of Project Web App by deploying PWA with a set of empty Office Project Server 2007 SP2 or SP3 databases. This would enable the new Project Server 2010 instance to accept connections from both Office Project Professional 2007 with Service Pack 2 (with the BCM client limitations listed above) and Project Professional 2010.

For information about using Office Project Server 2007 empty databases to enable BCM on a new installation of Project Server 2010, see Create a PWA site in backward compatibility mode (Project Server 2010). This article also references the Project Server 2007 empty databases for use with Project Server 2010 Backward Compatibility Mode page in the Microsoft Download Center.

See Also

Concepts

Project Server 2010 upgrade overview
In-place upgrade to Project Server 2010
Database-attach full upgrade to Project Server 2010
Database-attach core upgrade to Project Server 2010
TechNet Webcast: Project Server 2010 upgrade and migration
Backward compatibility mode (Project Server 2010 TechNet Webcast)


SQL script for known Project Server 2010 upgrade issues

Published: February 17, 2011

The SQL script for Known Upgrade Issues runs a data validation check on your Office Project Server 2007 databases to look for known conditions that may cause an upgrade to Project Server 2010 to fail. This script is run on Microsoft Office Project Server 2007 databases (Draft, Archive, Published, and Reporting) that you plan to upgrade to Project Server 2010. Running the script is optional, but it is highly recommended to detect issues that may prevent a successful upgrade of your data.

This script checks for the following conditions:

  • Office Project Server 2007 not updated to Service Pack 2 or a later version

  • Projects not saved and published since the installation of Office Project Server 2007 Service Pack 2

  • Lookup tables that are using names that are reserved in Project Server 2010

  • Custom field names that are reserved in Project Server 2010

  • Office Web Components (OWC) views in Office Project Server 2007 that have to be migrated to Excel Services for use in Project Server 2010

  • User accounts that use forms-authenticated logon names

  • Team names that have no associated lookup table or value

Note:

Although this script does not make any changes to your Office Project Server 2007 databases, we recommend that you run it on a restored copy of your Office Project Server 2007 databases. Another option is to have the script run by a SQL Server account that only has read permissions to the databases.

To run the Known Upgrade Issues script

  1. On the computer that contains the Office Project Server 2007 databases, open the SQL Server Management Studio Database Engine.

  2. In Management Studio, click New Query.

  3. Copy and paste the script text into the Query Editor window in Management Studio.

    Note:

    You can copy the script file directly from this article to your clipboard by clicking the Copy Code link located at the top of the script.

  4. After pasting the script text in the Query Editor, you must make the following changes to it:

    • Edit the USE <ProjectServer_Draft> line to specify the name of your Office Project Server 2007 Draft database. (For example, USE Litware_Draft)

    • Edit the two lines that read USE <ProjectServer_Published> to specify the name of your Office Project Server 2007 Published database. (For example, USE Litware_Published)

  5. Click Execute to run the script.

After you have run the script, you can make necessary changes to your Office Project Server 2007 data before you try to upgrade:

  • If the results show that Office Project Server 2007 is not updated to Service Pack 2 or a later version, update your Office Project Server 2007 environment with the latest updates. For more information, see Deploy Project Server 2007 updates.

  • If the results display projects that have not been saved and published since the installation of Office Project Server 2007 SP2, verify that Service Pack 2 is installed, and then open and republish the projects to Office Project Server 2007.

  • If the results include lookup table names that are reserved in Project Server 2010, rename the lookup tables. For a complete list of lookup table names reserved in Project Server 2010, see Project Server 2010 upgrade overview.

  • If the results include custom field names that are reserved in Project Server 2010, rename the custom fields. For a complete list of custom field names reserved in Project Server 2010, see the Project Server 2010 upgrade overview.

  • If the results include views that use Office Web Components that you want to keep in Project Server 2010, re-create these views in Excel Services (OWC is not used in Project Server 2010).

  • If the results include team names that have no lookup table, create a lookup table for these teams.

After making changes, create new backup copies of your Office Project Server 2007 databases, and then re-run the script on these databases to verify that the changes have been corrected.

Script

Copy Code
------------------------------------------------------------------------------
/* Pre-Migration Steps from Project 2007 SP2 to Project 2010

-----------------------------------------------------------------------------*/

------------------------------------------------------------------------------
/* Check Project 2007 Version: Must be SP2 or higher
-----------------------------------------------------------------------------*/
USE <ProjectServer_Draft>
select Version
as 'Project Server 2007 SP2 Version Must Be 12.0.6422.1000 or Higher. If not, upgrade to SP2'
, timestamp
from dbo.Versions
go
----------------------------------------------------------------------------------------------
/* Display the projects not saved or published since the installation of SP2
----------------------------------------------------------------------------------------------*/
select Distinct PROJ_NAME AS 'List of Projects Not Saved and Published Since the Installation of Service Pack2'
,PROJ_PROP_AUTHOR, PROJ_LAST_SAVED, WPROJ_LAST_PUB
from dbo.MSP_PROJECTS
where PROJ_TYPE = 0
and ((dbo.MSP_PROJECTS.PROJ_LAST_SAVED < (SELECT MAX(TimeStamp) FROM dbo.Versions))
OR (dbo.MSP_PROJECTS.WPROJ_LAST_PUB < (SELECT MAX(TimeStamp) FROM dbo.Versions)))
GROUP BY PROJ_NAME,PROJ_PROP_AUTHOR, PROJ_LAST_SAVED, WPROJ_LAST_PUB
Order by PROJ_NAME
go
------------------------------------------------------------------------------
/* Display the Lookup tables using reserved names in 2010
This query is to be run against the Published database of Project Server 2007
-----------------------------------------------------------------------------*/
USE <ProjectServer_Published>
select LT_NAME
AS 'List of Lookup Table names with Reserved Names. These names must be changed before proceeding with the Upgrade'
from dbo.MSP_LOOKUP_TABLES
WHERE LT_NAME IN
('Department',
'Project Impact',
'Relative Importance',
'Sample Areas Impacted',
'Sample Primary Objective')
-- Cost Type, Health, RBS and State are standard in 2007
go
------------------------------------------------------------------------------
/* Display the Custom Fields using reserved names in 2010
This query is to be run against the Published database of Project Server 2007
-----------------------------------------------------------------------------*/
USE <ProjectServer_Published>
select MD_PROP_NAME
AS 'List of Custom Fields names with Reserved Names. These names must be changed before proceeding with the Upgrade'
from dbo.MSP_CUSTOM_FIELDS
WHERE MD_PROP_NAME IN
('Flag Status',
'Project Departments',
'Project Impact',
'Relative Importance',
'Resource Departments',
'Sample Approved Finish Date',
'Sample Approved Start Date',
'Sample Areas Impacted',
'Sample Assumptions',
'Sample Business Need',
'Sample Compliance Proposal',
'Sample Goals',
'Sample Post Implementation Review Date',
'Sample Post Implementation Review Notes',
'Sample Primary Objectives',
'Sample Proposal Cost',
'Sample Proposed Finish Date',
'Sample Proposed Start Date')
go
---------------------------------------------------------------------------------------------------------
/* Displays Existing OWC Views in 2007 that need to be migrated to Excel Services in Project Server 2010
--------------------------------------------------------------------------------------------------------*/
select WVIEW_NAME AS 'List of PWA Data Analysis OWC Views to Migrate to Excel Services in Project Server 2010'
FROM dbo.MSP_WEB_VIEW_REPORTS
WHERE WVIEW_OWC_PIVOT_XML is not null
OR WVIEW_OWC_CHART_XML is not null

------------------------------------------------------------------------------
/* Displays User Accounts with Forms Auth Login Names > 249 Ch. -- on 2007
-----------------------------------------------------------------------------*/
select RES_NAME AS 'List of FBA accounts with Names > 249 Ch. Shorten the Resource Names below'
FROM dbo.MSP_RESOURCES
WHERE RES_IS_WINDOWS_USER = 0
AND (Select LEN(RES_NAME)) > 249
go
------------------------------------------------------------------------------
/* Display Team Names with no Lookup Tables and a Value -- on 2007
-----------------------------------------------------------------------------*/
select TEXT_VALUE AS 'List of Team Names with values and NO Lookup Tables. Create a LT for these Teams'
FROM dbo.MSP_RES_CUSTOM_FIELD_VALUES, dbo.MSP_CUSTOM_FIELDS, dbo.MSP_LOOKUP_TABLES
WHERE dbo.MSP_RES_CUSTOM_FIELD_VALUES.CUSTOM_FIELD_UID = dbo.MSP_CUSTOM_FIELDS.MD_PROP_UID
AND MD_PROP_NAME = 'Team Name'
AND dbo.MSP_CUSTOM_FIELDS. MD_LOOKUP_TABLE_UID IS NULL
go


Upgrade from a trial version of Project Server 2010
See Also

Published: June 16, 2011

This article contains information and a procedure on how to upgrade from a trial version of Microsoft Project Server 2010 to a full product edition.

In this article:

  • Process overview

  • Upgrade from a trial version of Project Server 2010

Process overview

If you are using a trial version of Microsoft Project Server 2010 and want to upgrade to a licensed product edition, you must purchase valid licenses for your farm and perform the upgrade on the SharePoint Central Administration Web site. For more information about licensing Project Server 2010, see the "Buy Project Server 2010 Today" section of the Microsoft Project site.

Note:

Your installation of Project Server 2010 Trial requires the installation of Microsoft SharePoint Server 2010 (Enterprise with Client Access Licenses) as a prerequisite. Be aware that when you purchase your Project Server 2010 license, you must also make sure that all components of your farm are licensed correctly.

Before you upgrade your Project Server 2010 Trial to the fully licensed version, make sure that you plan carefully when incorporating it into your environment. If your trial was a minimal installation and pilot, you should review your infrastructure and plan how your production system should be configured, instead of merely moving your trial system into production. You should plan for performance and capacity if you intend to make the system available to more users or more use scenarios after you upgrade. For information about performance and capacity considerations, see Capacity planning in Project Server 2010 (white paper) and view the "Estimate Performance and Capacity Requirements for Microsoft Project Server 2010" white paper.

Upgrade from a trial version of Project Server 2010

After you have purchased a license to upgrade to the licensed edition of Project Server 2010, you can use the Convert License Type page on the Central Administration Web site to enter the new product key. Make sure all components of your farm, including SharePoint Server 2010, are licensed correctly.

To convert a license type and enter the product key

  1. Verify that you have the following administrative credentials:

    • To convert a license type, you must be a member of the Farm Administrators SharePoint group on the computer that is running Central Administration.

  2. On the Central Administration Web site, in the Upgrade and Migration section, click Convert farm license type.

  3. On the Convert License Type page, verify that Project Server 2010 Trial is the product listed for Current License. In the Enter the Product Key box, type the new product key and then click OK.

  4. When the upgrade is complete, a dialog box displays "Your License Conversion operation was successfully completed".

You can verify that you have the licensed product edition of Project Server 2010 by going back to the Convert License Type page and making sure that the Current License has changed.

Important:

In the previous procedure, the Project Server 2010 key upgrades both the SharePoint Server 2010 Trial and Project Server 2010 Trial to the licensed editions. You will not be required to use the same procedure to convert the SharePoint Server 2010 Trial version to the license, because this has already occurred through your Project Server 2010 key. It is important to realize that you are still required to own a SharePoint Server 2010 (Enterprise with CAL) license for this installation.

See Also

Other Resources

Download Microsoft Project Server 2010 Trial


In-place upgrade to Project Server 2010

Published: May 12, 2010

Important:

Upgrading from the Project Server 2010 public Beta to the Project Server 2010 released version is explicitly blocked and not supported. This restriction applies to both the in-place and database-attach upgrade methods.

When you run an in-place upgrade from Microsoft Office Project Server 2007 to Microsoft Project Server 2010, the configuration data for the farm and all the content in the farm is upgraded on the existing hardware, in a fixed order. When you start the in-place upgrade process, Setup takes the entire farm offline and the Web sites and Microsoft Project Web App sites are unavailable until the upgrade is finished, and then Setup restarts the server. After you begin an in-place upgrade, you cannot pause the upgrade or roll back to the previous version.

You can also choose to upgrade only your project data and optionally your Project Web App site data to another server, which would be required if the in-place upgrade requirements mentioned later in this article are not met. For more information about other Project Server 2010 upgrade methods, see Project Server 2010 upgrade overview.

Important:

You must be running Office Project Server 2007 with SP2 with the October 2009 Cumulative Update in a 64-bit Windows Server 2008 environment to perform an in-place upgrade to Project Server 2010. You must also be running a 64-bit version of Microsoft SQL Server 2008 Service Pack 1 with Cumulative Update 2, or the 64-bit version of Microsoft SQL Server 2005 Service Pack 3 with Cumulative Update 3.

In this article:

  • Process overview

  • Before you begin

  • Install prerequisites

  • Run SharePoint Server 2010 Setup on all servers

  • Run Project Server 2010 Setup on all servers

  • Run the SharePoint Products and Technologies Configuration Wizard

  • Verification

  • "Missing server side dependencies" error in Health Analyzer

Process overview

By using the procedures in this article, you install Project Server 2010 and upgrade Project Web App and all the project data in the environment. Microsoft SharePoint Server 2010 Enterprise version is a prerequisite for Project Server 2010 and must be installed on all servers in the farm also. We recommend that you try out the upgrade process on a test environment before you attempt to upgrade your production environment.

When upgrading a server farm, install and configure the new version to the servers in the following order:

  1. Install SharePoint Server 2010 on all servers in the server farm.

  2. Install Project Server 2010 on all servers in the server farm.

  3. Run the SharePoint Products and Technologies Configuration Wizard on the server that contains the SharePoint Central Administration Web site.

    To determine which server is running SharePoint Central Administration, open the Servers in Farm page (http://server_name:adminport/_admin/farmservers.aspx) and note which server or servers have Central Administration services running. Perform this step before you install SharePoint Server 2010, while SharePoint Central Administration for Office Project Server 2007 is still available.

    Note:

    If you have multiple servers running SharePoint Central Administration, pick one and use that as the initial server on which to run upgrade. After you have completed the process on that one, you can continue with any other servers running SharePoint Central Administration.

  4. Run the configuration wizard on the remaining front-end Web servers and application servers in the farm in any order.

Note:

It is important that you only run the SharePoint Products Configuration Wizard after the installation files for both SharePoint Server 2010 and Project Server 2010 are on all servers in the farm. Running it prior to this can cause data inconsistencies on the farm.

Before you begin

It is recommended that you back up your environment before you begin the upgrade process. For more information, see Back up and restore a Project Server 2007 farm.

Review required permissions

To deploy Project Server 2010 on a server farm, you must provide credentials for several different accounts.

The following table describes the accounts that are used to install and configure Project Server 2010.

Important:

Although it is a good practice to install Project Server 2010 by using the least-privileged administration method, you cannot perform an in-place upgrade by using this method. To run Setup and the SharePoint Products Configuration Wizard, you must have administrator access to the local computer and to Microsoft SQL Server.

Account Purpose Requirements

SQL Server service account

The SQL Server service account is used to run SQL Server. It is the service account for the following SQL Server services:

  • MSSQLSERVER

  • SQLSERVERAGENT

If you do not use the default SQL Server instance, these services will be shown as the following:

  • MSSQL$InstanceName

  • SQLAgent$InstanceName

Use either a Local System account or a domain user account.

If you plan to back up to or restore from an external resource, permissions to the external resource must be granted to the appropriate account. If you use a domain user account for the SQL Server service account, grant permissions to that domain user account. However, if you use the Network Service or the Local System account, grant permissions to the external resource to the machine account (domain_name\SQL_hostname$).

Setup user account

The Setup user account is used to run the following:

  • Setup

  • The SharePoint Products Configuration Wizard

  • Domain user account.

  • Member of the Administrators group on each server on which Setup is run.

  • SQL Server login on the computer that runs SQL Server.

  • Member of the following SQL Server security roles:

    • securityadmin fixed server role

    • dbcreator fixed server role

If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database.

Server farm account or database access account

The server farm account is used to perform the following tasks:

  • Configure and manage the server farm.

  • Act as the application pool identity for the SharePoint Central Administration Web site.

  • Run the Windows SharePoint Services Timer service.

  • Domain user account.

Additional permissions are automatically granted for the server farm account on Web servers and application servers that are joined to a server farm.

The server farm account is automatically added as a SQL Server login on the computer that runs SQL Server. The account is added to the following SQL Server security roles:

  • dbcreator fixed server role

  • securityadmin fixed server role

  • db_owner fixed database role for all databases in the server farm

Review required hardware and software

You must have the following software and hardware installed and configured to perform the steps in this article.

Requirement Details

Operating System

Windows Server 2008 R2 and Windows Server 2008 with Service Pack 2 (SP2) (64-bit)

For more information about migrating to a 64-bit operating system, see Migrate an existing server farm to a 64-bit environment (Project Server 2007).

Project Server

Project Server 2007 Service Pack 2 with the October 2009 Cumulative Update applied

Important:

You must apply both Service Pack 2 and the October 2009 Cumulative update. If you attempt to execute and in-place upgrade without these updates, it can result in an unrecoverable state.

For information about installing Office Project Server 2007 SP2, see Deploy Service Pack 2 for Office Project Server 2007.

For more information about installing cumulative updates, see Deploy cumulative updates (Project Server 2007).

SQL Server

64-bit version of SQL Server 2005 Service Pack 2 with Cumulative Update 3, OR

64-bit version of SQL Server 2008 Service Pack 1 with Cumulative Update 2

Your databases must be hosted on either of these two 64-bit versions of SQL Server. SQL Server 2000 and non-64-bit versions are not supported for Project Server 2010.

For more information about moving databases to a 64-bit version of SQL Server, see Migrate an existing server farm to a 64-bit environment a 64-bit environment (Project Server 2007).

Windows SharePoint Services

Windows SharePoint Services 3.0 with SP2

Although not a requirement, as a best practice, you may want to match the cumulative update level of Office Server 2007 applications.

If you are using the in place upgrade method to upgrade a Office Project Server 2007 farm that is integrated with Office SharePoint Server 2007, then Office SharePoint Server 2007 has this additional requirement:

 | Requirement | Details
Service Pack Level | Office SharePoint Server 2007 with SP2 | For information about installing Office SharePoint Server 2007 SP2, see Deploy software updates for Office SharePoint Server 2007.

Install prerequisites

Before you can upgrade, you must run the prerequisite installer successfully on each server that has Office Project Server 2007 installed. A prerequisite installer is available to install software needed to support Project Server 2010.

To run the prerequisite installer

  1. From the product disc, open the installation folder and run splash.hta to open the Start page. On the Start page, click Install software prerequisites to run Prerequisite Installer.

    The SharePoint Products and Technologies 2010 Preparation tool opens.

  2. Click Next.

  3. On the License Terms page, select the I accept the terms of the License Agreement(s) check box, and then click Next.

    The tool runs, installing and configuring required software.

  4. Click Next.

  5. On the Installation Complete screen, verify that each prerequisite is listed as successfully installed or already installed.

  6. Click Finish to close the wizard.

Run SharePoint Server 2010 Setup on all servers

After all of the prerequisites are installed, you can run the SharePoint Server 2010 Setup.exe on all servers in your server farm.

Important:

If you are running an in-place upgrade on a server farm, disconnect all the users from the server farm by stopping the World Wide Web Publishing Service (W3SVC) on all front-end Web servers. If you allow users in a server farm to connect after the files and databases have been updated on one Web server, but before the other Web servers have been updated, users will not be able to browse the Web sites. You should also stop the Project Queuing service on all application servers. This action ensures that nothing will be processed by Project Server 2007 while the upgrade is happening.

To install the new version of SharePoint Server 2010

  1. Run Splash.hta to open the Start page. On the Start page, click Install SharePoint Server.

  2. On the Enter your Product Key page, type your product key for SharePoint Server 2010 Enterprise edition, and then click Continue.

  3. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  4. On the Upgrade earlier versions page, click Install Now.

  5. Setup runs and installs SharePoint Server 2010.

    On the completion page, clear the Run the SharePoint Products and Technologies Configuration Wizard now check box, and then click Close.

    Important:

    Do not run the SharePoint Products Configuration Wizard at this time. You will be directed to run it later when all installation files for both applications are installed on all Web and application servers in the server farm.

If you require any language template packs for SharePoint Server 2010, install them now. For more information, see Install available language template packs (SharePoint Server 2010).

Run Project Server 2010 Setup on all servers

After SharePoint Server 2010 is installed to all servers in the farm, you can run the Project Server 2010 Setup.exe on all servers in your server farm.

To install the new version of Project Server 2010

  1. Run Splash.hta to open the menu page. Click Install Project Server.

  2. On the Enter your Product Key page, type your product key for Project Server 2010, and then click Continue.

  3. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  4. On the Upgrade earlier versions page, click Install Now.

  5. Setup runs and installs Project Server 2010.

    On the completion page, clear the Run the SharePoint Products and Technologies Configuration Wizard now check box, and then click Close.

Run the SharePoint Products and Technologies Configuration Wizard

If you are upgrading a single server, you can run the SharePoint Products and Technologies Configuration Wizard on only that server and start upgrading content. If you are upgrading a server farm, first run the SharePoint Products and Technologies Configuration Wizard on the server running SharePoint Central Administration. Then go to each server in the farm and run the wizard. It is important to upgrade SharePoint Central Administration before you attempt to upgrade any other content in the farm, and completing the wizard on the server running SharePoint Central Administration allows you to do so.

Be sure that you have installed any language template packs before you run the SharePoint Products and Technologies Configuration Wizard.

Caution:

After you run the configuration wizard, Office Project Server 2007 will no longer be available. You cannot pause or roll back the setup and upgrade process. Be sure that you have a current and valid backup of your environment before you proceed with installing Project Server 2010.

Important:

When you run the SharePoint Products and Technologies Configuration Wizard, make sure that the wizard completely finishes running before you attempt to run it on another server. The wizard will also start the Upgrade Timer job, and this must completely finish running as well. You should inspect the upgrade logs for completion of the upgrade session on the server before attempting to run the wizard on another server.

To run the SharePoint Products and Technologies Configuration Wizard

  1. Click Start, point to All Programs, click SharePoint Products, and then click SharePoint 2010 Products Configuration Wizard.

  2. In the SharePoint Products Configuration Wizard, on the Welcome to SharePoint Products and Technologies page, click Next.

    A message appears, notifying you that Internet Information Services (IIS), the SharePoint Administration Services v4, and the SharePoint Timer Service v4 may need to be restarted or reset during configuration.

  3. Click Yes to continue with the wizard.

  4. On the Specify Farm Settings page, in the Passphrase box, type a passphrase and in the Confirm passphrase box, type the same passphrase.

    The passphrase should be at least 8 characters and should contain at least three of the following four character groups:

    • English uppercase characters (from A through Z)

    • English lowercase characters (from a through z)

    • Numerals (from 0 through 9)

    • Non-alphabetic characters (such as !, $, #, %)

  5. On the Completing the SharePoint Products and Technologies Configuration Wizard page, verify the settings, and then click Next.

    The configuration wizard runs and configures the configuration database and SharePoint Central Administration for Project Server 2010.

  6. A message appears, notifying you that if you have a server farm with multiple servers, you must run Setup on each server to install new binary files before continuing the configuration wizard.

    • If this is the only server in your farm, or if you have already run Setup on all of the servers in your farm, click OK to continue with the wizard.

    • If you have not yet run Setup on all of the servers in your farm, run Setup on the remaining servers now, and then return to this server and click OK to continue with the wizard.

    The configuration wizard continues the upgrade process by setting up the configuration database and installing SharePoint Central Administration.

  7. On the Configuration Successful, Upgrade in Progress page, review the settings that have been configured, and then click Finish.

    The SharePoint Products and Technologies Configuration Wizard closes and the Upgrade Status page opens. You might be prompted to enter your user name and password before the Upgrade Status page will open. The upgrade process might take a while to complete, depending on how much data is in your farm.

  8. If you are upgrading a server farm, you can now complete the SharePoint Products and Technologies Configuration Wizard on the other servers in the farm.

  9. After upgrade is completed successfully for all sites, if you stopped the World Wide Web Publishing Service (W3SVC) on all front-end Web servers before the upgrade, manually start the World Wide Web Publishing Service on the front-end Web servers to make the Web servers available to users. Also verify that the Project Queuing service has restarted on all Project application servers in the farm. If it has not, restart it.

If you are upgrading a Office Project Server 2007 farm that is integrated with Office SharePoint Server 2007, you can monitor the upgrade process for each site from the Upgrade Status page in SharePoint Central Administration or by using the localupgradestatus operation in Stsadm.exe. For more information, see Verify upgrade and review upgraded sites (SharePoint Server 2010).

Verification

If upgrade fails or reports issues, you can refer to the log and error files for more information. Upgrade logs files are generated to the following default location: C: \Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Logs

Each upgrade log file will be stamped with the date and time that it was generated.

There are two types of possible failures that you might find in the log:

  • Failures in the psconfig portion of the upgrade: You can restart the SharePoint Products and Technologies Configuration Wizard to restart the upgrade.

  • Failures in the SPTimer portion of the upgrade: You can restart upgrade by running the following command in a Command Prompt window:

    Psconfig -cmd -upgrade -inplace v2v -force -wait

"Missing server side dependencies" error in Health Analyzer

After you upgrade to Project Server 2010 by using the in-place upgrade method, you may see the following error if you check for missing server-side dependencies when you run the Health Analyzer tool. The following entry would appear in the Review Problems and Solutions Page of Central Administration Monitoring:

Category | Title | Failing Service
Configuration | Missing server side dependencies. | SPTimerService(SPTimerV4)

You can click the error to display more details:

Severity:

1 - Error

Explanation:

MissingSetupFile] File [SiteTemplates\PWA\dwp\OWCViewPart.webpart] is referenced [1] times in the database [WSS_Content], but exists only under Windows SharePoint Services 3.0 setup folder. Consider upgrading the feature/solution which contains this file to the latest version. One or more setup files are referenced in the database [WSS_Content], but are not installed on the current farm. Please install any feature or solution which contains these files.

[MissingSetupFile] File [SiteTemplates\PWA\OWCView.aspx] is referenced [1] times in the database [WSS_Content], but exists only under Windows SharePoint Services 3.0 setup folder. Consider upgrading the feature/solution which contains this file to the latest version. One or more setup files are referenced in the database [WSS_Content], but are not installed on the current farm. Please install any feature or solution which contains these files.

[MissingWebPart] WebPart class [94b5bae7-436c-dcc2-5869-d491181c283b] is referenced [1] times in the database [WSS_Content], but is not installed on the current farm. Please install any feature/solution which contains this web part. One or more web parts are referenced in the database [WSS_Content], but are not installed on the current farm. Please install any feature or solution which contains these web parts.

This error is inconsequential. It appears because the upgraded Content database contains pages and Web Parts that use Office Web Components (OWC), which have been deprecated in Project Server 2010. The presence of OWC Web Parts and pages on the upgraded Content database causes the error message to occur, but it does not prevent your upgrade from completing successfully. Note that most of the OWC features can be found in both the Microsoft Excel client and Excel Services.

For more information about Health Analyzer, see Health Monitoring (SharePoint Server 2010).


Upgrade considerations for Project Web App Web Parts
See Also

Published: October 21, 2010

When you upgrade from Microsoft Office Project Server 2007 to Microsoft Project Server 2010, the Project Web Access Web Parts used in Office Project Server 2007 are upgraded to Project Server 2010 and may present certain problems and may require corrective action. The actions that you have to take include the following:

  • Verify that the visual upgrade feature is configured to use the SharePoint Server 2010 user interface

  • Fix the upgraded Project Web App Web Parts on sites in the same site collection as Project Web App

  • Fix the upgraded Project Web App Web Parts on sites not in the same site collection as Project Web App

  • Remove the upgraded Data Analysis Web Part

Important:

It is especially important to be aware of Project Web Access Web Part upgrade issues if you are upgrading both your Office Project Server 2007 and the Microsoft Office SharePoint Server 2007 environment on which it resides.

For more information about Project Web App Web Parts in Project Server 2010, see the following articles:

  • Plan for Project Server 2010 Web Parts

  • Add or remove Project Web App Web Parts for a site in the Project Web App site collection (Project Server 2010)

  • Add Project Web App Web Parts to a site not within the Project Web App site collection (Project Server 2010)

Verify that the visual upgrade feature is configured to use the SharePoint Server 2010 user interface

Project Web App Web Parts do not appear correctly with the Office SharePoint Server 2007 user interface that is available through the SharePoint Server 2010 visual upgrade feature. By default, the SharePoint Server 2010 visual upgrade feature preserves the Office SharePoint Server 2007 user interface of upgraded sites. However, there is also an option during upgrade setup that enables you to upgrade all sites to the SharePoint Server 2010 user interface.

For sites that have the Office SharePoint Server 2007 user interface after the upgrade process, a switch to the SharePoint Server 2010 user interface is still possible. Site owners and site collection owners can change to the new user interface in the Site Settings section by selecting the Update the User Interface option. Site owners and site collection owners can also see how the site will look in SharePoint Server 2010 by using the Preview User Interface option.

For more information about the SharePoint Server 2010 visual upgrade feature, see Plan visual upgrade (SharePoint Server 2010).

To change the visual upgrade feature to the SharePoint Server 2010 user interface

  1. On the site, click Site Actions, and then click Site Settings.

  2. On the Site Settings page, in the Look and Feel section, click Title, Description, and Icon.

  3. On the Title, Description, and Icon page, in the Visual Upgrade section, click Preview the New User Interface to temporarily view the site in the SharePoint Server 2010 user interface. This lets you see how the Web Parts appear on the site in the SharePoint Server 2010 user interface.

  4. To permanently change the site user interface from Office SharePoint Server 2007 to SharePoint Server 2010, return to the Title, Description, and Icon page and click Update the User Interface, and then click OK.

Important:

Once you decide to update the user interface, you cannot revert to the Office SharePoint Server 2007 user interface.

Fix the upgraded Project Web App Web Parts on sites in the same site collection as Project Web App

After you upgrade to Project Server 2010, all Project Web App Web Parts on sites in the same site collection as Project Web App require an update to their PSIURL property. The PSIURL property is a URL that points to the target Project Web App you are referencing. The format should be http://<server>/<pwa>.

For example, after you upgrade, you have a Project site (http://contoso/PWA/sites/Projectsite1) that contains a Project Center Web Part. You would have to edit the Project Center Web Part and update the PSIURL to point to the PWA site that you want the Web Part to connect to and display data from (http://contoso/pwa).

To change the PSIURL property of a Project Web App Web Part

  1. On the site, click the Site Actions menu, and then click Site Settings.

  2. On the Site Settings page, in the Galleries section, click Web Parts.

  3. In the Web Parts Gallery, select the check box next to the Web Part that you want to edit.

  4. Click the Documents tab to ensure that the Documents server ribbon appears. In the Documents server ribbon, click Download a Copy.

  5. In the File Download dialog box, click Save.

  6. In the Save As dialog box, select a location on your computer in which to save the file. Click Save.

  7. Open the Web Part in Notepad. In Notepad, in the <properties> section, add the following property:

    PSIURL <property name="PsiUrl" type="string"> http://server/PWA</property>

    For the PSIURL value, verify that the URL you enter is for the PWA site that the Project Web App Web Part is using as a data source. For example: For example: PSIURL <property name="PsiUrl" type="string"> http://Contoso/PWA</property>

    If the PSIURL property already exists, edit the entry to point to the correct URL. If you edit the entry, verify that you remove a null="true" parameter that may exist in the PSIURL property. Ensure that the PSIURL property that you edit contains only the name and type parameters and the URL (as shown in the examples earlier).

  8. Click File, and then click Save to save your changes. Close Notepad.

  9. In the Web Parts Gallery page, on the Documents server ribbon, click Upload Document, and then click Upload Document - Upload a document from your computer to the library.

  10. In the Upload Web Part dialog box, make sure Overwrite existing files is selected, and then click Browse. In the Choose File to Upload dialog box, locate and select the Web Part file that you edited, and then click Open.

  11. In the Upload Web Part dialog box, click Open.

  12. In the Web Part Gallery property page for the Web Part, click Save.

Important:

After updating all the Project Web App Web Parts on the site, make sure that you refresh the site to verify that the Project Web App Web Parts appear correctly.

Fix the upgraded Project Web App Web Parts on sites not in the same site collection as Project Web App

After you upgrade from Office Project Server 2007 to Project Server 2010, Project Web App Web Parts that are on sites that are not in the Project Web App site collection must be manually removed and replaced. This is required because the upgrade process replaces the Project Web App Web Parts on these sites with invalid Web Parts (also known as "error Web Parts").

The following are the steps that are required to replace the invalid Project Web App Web Parts to make them functional on the site page:

  1. Remove the Project Web App Web Parts from the site.

  2. Import valid Project Web App Web Parts from a site in the Project Web App site collection.

  3. Change the PSIURL for the imported Project Web App Web Parts.

  4. Upload the Project Web App Web Parts to the Web Parts Gallery for the site.

  5. Add the Project Web App Web Parts to the site.

Remove the Project Web App Web Parts from site

Use the following procedure to delete the invalid Project Web App Web Parts from the Web Parts page for the site.

To remove a Project Web App Web Part from a page

  1. On the site, click the Site Actions menu, and then click Edit Page.

  2. The page will appear in Edit mode. Select the Web Part that you want to remove, click the Web Part menu (next to the check box in the upper-right corner of the Web Part), and then click Delete.

  3. In the Message from Web Part dialog box, click OK to confirm that you want to delete the Web Part.

  4. The page will appear with the Web Part removed. Click the Page tab to display the Page server ribbon, and then click Stop Editing.

Import valid Project Web App Web Parts from a site in the Project Web App site collection

After you have removed all the invalid Project Web App Web Parts from the site, you import valid Project Web App Web Parts into the Web Parts Gallery. You can import them from a site that is already in the Project Web App site collection. This makes them available when you have to re-add them to the site.

To import Project Web App Web Parts from a site in the Project Web App site collection

  1. Open a site in the Project Web App site collection.

  2. Click the Site Actions menu, and then click Site Settings. On the Site Setting page, in the Galleries section, click Web Parts.

  3. On the All Web Parts page, from the Web Parts list, select the check box next to all of the Project Web App Web Parts that you want to import to the other site.

  4. Click the Documents tab to display the Documents server ribbon. Click Download a Copy. In the File Download dialog box, click Save. In the Save As dialog box, select a location on your desktop to save the Web Part to and then click Save.

Update the PSIURL property for each Project Web App Web Part

After you download the Project Web App Web Parts to your desktop, you must add or update the PSIURL property for each Web Part file.

To change the PSIURL property for a Web Part file

  1. Open the Web Part in Notepad. In Notepad, in the <properties> section, add the following property:

    PSIURL <property name="PsiUrl" type="string"> http://server/PWA</property>

    For the PSIURL value, verify that the URL you enter is for the PWA site that the Project Web App Web Part is using to display its data. For example: PSIURL <property name="PsiUrl" type="string"> http://Contoso/PWA</property>

    It the PSIURL property already exists, edit the entry to point to the correct URL.

  2. Click File, and then click Save to save your changes to the Web Part file.

  3. Repeat the procedure for all Project Web App Web Parts that you are importing.

Add the Project Web App Web Part to the Web Part Gallery for the site

After you edit the PSIURL for each Project Web App Web Part, you must upload the Web Parts to the Web Part Gallery for the site to make them available to add to the Web Parts page.

To add the Project Web App Web Parts to the Web Part Gallery

  1. Open the site to which you want to import the Project Web App Web Parts. On this site, click Site Actions, and then click Site Settings. On the Site Settings page, in the Galleries section, click Web Parts.

  2. Click the Documents tab to display the Documents server ribbon. Click Upload Document.

  3. Select the Web Parts you want to import from your desktop and upload them to the Web Parts Gallery.

Add the Project Web App Web Parts to the site

After you import valid Project Web App Web Parts into the site's Web Part Gallery, you must add the valid Project Web App Web Parts to the site. You might also have to enable the Project Web Access server ribbon on the site, if the Project Web App Web Part you are adding to the site has a dependency on the ribbon.

To add the valid Project Web Access Web Parts to the site

  1. On the site page, click the Site Actions menu, and then click Edit Page. The page will appear in Edit mode.

  2. Click Add a Web Part in the location in which you want to add the Project Web App Web Part.

  3. On the Browse server ribbon, in the Category list, select Project Web App, and then click the Project Web App Web Part that you want to add to the location on the page. Click Add. Repeat steps 2 and 3 to add any remaining Project Web App Web Parts that you want to add to the page.

    The page then appears with the added Project Web App Web Parts, but it is still in Edit mode.

  4. When you are finished adding the Project Web App Web Parts to the page, click the Page tab to display the Page server ribbon, and then click Stop Editing.

  5. Refresh the site to verify that the Project Web App Web Parts appear correctly.

Some Project Web App Web Parts have a ribbon dependency and must have the Project Web App server ribbon enabled on the site in order to appear correctly. You must enable the Project Web App ribbon on the site before adding any Project Web App Web Parts that require the ribbon.

The PWA Web Parts that have a ribbon dependency are as follows:

  • Project Details

  • Project Center

  • Resource Assignments

  • Resource Center

  • My Tasks

  • Approval Center

  • Team Tasks

  • My Schedule

  • My Timesheet

Use the following procedure to enable the Project Web App server ribbon feature on a site if the PWA Web Part that you are adding has a dependency on it:

To enable the ribbon feature on a site

  1. On the site on which you want to enable the ribbon, click the Site Actions menu, and then click Site Settings.

  2. On the Site Settings page, in the Site Collection Administration section, click Site Collection Features.

  3. On the Site Collection Administration-Features page, find Project Web App Ribbon and then click the Activate button to the right of it.

Remove the upgraded Data Analysis Web Part

The Data Analysis Web Part is not available in Project Server 2010. Upgrading from Office Project Server 2007 to Project Server 2010 replaces the Data Analysis Web Part with an error Web Part. After you upgrade from Office Project Server 2007, the Data Analysis Web Part should be removed from the Web Part Gallery. Removing it from the Web Part Gallery makes it unavailable for all users.

To remove the Project Web App Data Analysis Web Part from the Web Part Gallery

  1. Open a site in the Project Web App site collection.

  2. On the site page, click the Site Actions menu, and then click Site Settings.

  3. On the Site Settings page, in the Galleries section, click Web Parts.

  4. In the All Web Parts page, click the check box next to the Data Analysis Web Part.

  5. Click the Documents tab to display the Documents server ribbon. On the Documents ribbon, click Delete Document.

  6. On the confirmation dialog box that asks you to confirm, click OK to delete the Web Part from the Gallery.

See Also

Concepts

Add or remove Project Web App Web Parts for a site in the Project Web App site collection (Project Server 2010)
Plan for Project Server 2010 Web Parts
Add Project Web App Web Parts to a site not within the Project Web App site collection (Project Server 2010)

Other Resources

Manage Web Part pages (SharePoint Server 2010)
Developing Project Server 2010 Web Parts (http://go.microsoft.com/fwlink/p/?LinkID=204589)


Database-attach full upgrade to Project Server 2010
See Also

Published: May 12, 2010

Important:

Upgrading from the Project Server 2010 public Beta to the Project Server 2010 released version is explicitly blocked and not supported. This restriction applies to both the in-place and database-attach upgrade methods.

When you upgrade from Microsoft Office Project Server 2007 to Microsoft Project Server 2010 by using the database attach upgrade process, you upgrade only the content for your environment, and not the configuration settings. Using a database attach upgrade process is useful when you are changing hardware or want to reconfigure your server farm topology as part of the upgrade process. It is also required if you are upgrading from Office Project Server 2007 deployed on a hardware that only supports a 32-bit server operating system.

Database-attach upgrade to Project Server 2010 can be done in either of two ways:

  • Database-attach full upgrade: Migrates the project data stored in the Office Project Server 2007 databases, plus the Microsoft Project Web App (PWA) site data stored in a SharePoint content database.

  • Database-attach core upgrade: Migrates only the project data stored in the Office Project Server 2007 databases.

This article provides the procedures required to perform a database attach full upgrade. For information about different types of methods for upgrading to Project Server 2010, see Project Server 2010 upgrade overview.

Process overview

When you perform a database attach full upgrade, you will back up the required databases in the old farm and then restore them in the new farm. When you restore the SharePoint content database that contains your Project Web App site data and add it to the new farm, the upgrade process runs and upgrades the database. After you restore the Office Project Server 2007 databases, they are upgraded to Project Server 2010 when they are used to provision a Project Web App instance in Project Server 2010. While both the database attach upgrade process and the in-place upgrade process are similar in functionality, the database attach upgrade keeps the original Office Project Server 2007 environment intact because you are using backup copies of the databases for the upgrade processes.

Note:

The featured called "Project Web Access" in Office Project Server 2007 is now called "Project Web App" in Project Server 2010.

Before you begin

Before you begin the database attach full upgrade to Office Project Server 2007, review the following information about permissions, hardware requirements, and software requirements. Follow the specified steps to install or configure prerequisite software or to modify settings.

Review required permissions

You must have at least the following permissions to complete the procedures in this article:

  • On the database server from which the databases are being detached you must be a member of the following roles:

    • The db_owner fixed database role.

    • The db_backupoperator fixed database role.

  • On the server farm to which the databases are being attached, you must be a member of the local Administrators group, and you must be a member of the following roles on the database server:

    • The dbcreator fixed server role.

    • The db_owner fixed database role.

  • In some environments, you must coordinate the move procedures with the database administrator. Be sure to follow any applicable policies and guidelines for handling databases.

Review required hardware and software

You must be running one of the following products on the database servers to perform these procedures:

  • On your Office Project Server 2007 environment: the Microsoft SQL Server Client tools for SQL Server 2000, SQL Server 2005, or SQL Server 2008. These are required to back up your required databases.

  • On your Project Server 2010 environment: a 64-bit version of one of the following products:

    • SQL Server 2008 Service Pack 1 with Cumulative Update 2

    • SQL Server 2005 Service Pack 3 with Cumulative Update 3

Note:

Project Server 2010 databases can only be hosted on 64-bit versions of these two versions of SQL Server.

Perform prerequisite steps

Before you back up the databases, you must prepare for the upgrade by following these steps:

  1. Create a new server farm environment. For information about creating the new environment, see Deploy Project Server 2010 to a server farm environment.

  2. If you have custom site definitions in the old environment, create new site definitions and upgrade definition files for these site definitions and deploy them to the new environment.

Database attach full upgrade overview

A database attach full upgrade will upgrade your Office Project Server 2007 databases and will also restore the Project Web Access site's content database to your Project Server 2010 farm. The following databases are upgraded in a database attach full upgrade:

  • Draft

  • Archive

  • Publish

  • Reporting

  • SharePoint content database (containing your Project Web Access site data)

A database attach full upgrade differs from a database attach core upgrade in the fact that the core upgrade will only upgrade your Office Project Server 2007 databases, migrating only your Office Project Server 2007 project data. If you only want to upgrade your Office Project Server 2007 project data, see Database-attach core upgrade to Project Server 2010.

To perform a database attach full upgrade, you must follow these general steps:

  1. Verify your Project Server 2007 data

  2. Extract your Project Web Access site from a content database to a new content database (Optional)

    Note:

    This extraction is only required if your Project Web Access site data is not contained in its own site collection (and therefore, its own content database). Doing this step extracts your Project Web Access site data from an existing content database and then puts it in its own content database.

  3. Back up the databases in SQL Server

  4. Restore the backup copies to the new farm

  5. Add the restored content database to the Project Server 2010 farm

  6. Provision a new Project Server 2010 PWA instance using the restored databases

  7. Diagnose failures

  8. Configure for post-installation

  9. Verify whether the migration has been successful

These steps require that you have Project Server 2010 installed in your environment. You do not need to configure a Project Web App site prior to doing this procedure. You also do not need to do post-installation configuration such as configuring for Exchange Server integration or reporting, which can be done after upgrading. For more information about installing Project Server 2010, please see Deploy Project Server 2010 to a server farm environment.

Verify your Project Server 2007 data

You must verify that your Office Project Server 2007 data is in a valid state to help ensure that your upgrade will be successful. You must verify the following:

  • All projects should be checked-in.

  • The Project Web App site name of "ProjectBICenter" is reserved in Project Server 2010. Verify that Office Project Server 2007 does not use this as a Project Web App site name.

  • The list name of "Project Detail Page" is reserved in Project Server 2010. Verify that Office Project Server 2007 Project Web Access does not contain a list with this same name.

  • Resolve all custom field and lookup table name conflicts with names that are reserved in Project Server 2010. See the Custom field and lookup table name conflicts section for more information.

Custom field and lookup table name conflicts

There are certain custom fields and lookup tables name that are reserved in both Office Project Server 2007 and Project Server 2010. If you are upgrading from Office Project Server 2007, verify that you do not have custom field names that are in conflict with the names reserved for Project Server 2010. If any of these names are used in the current Office Project Server 2007 database, the custom fields and outline codes must be changed in Office Project Server 2007 before proceeding further with the migration. Use Microsoft Office Project Professional 2007 connected to a Office Project Server 2007 instance to validate and take corrective action.

Reserved outline code names

Outline code name | Type | Office Project Server 2007 | Project Server 2010
Cost Type | Resource | X | X
Health | Task | X | X
State | Project | X | X
Team Name | Resource | X | X
Department |  |  | X
Flag Status |  |  | X

Reserved custom field names

Custom field name | Type | Office Project Server 2007 | Project Server 2010
Cost Type | Resource | X | X
Health | Task | X | X
State | Project | X | X
Team Name | Resource | X | X
Sample Approved Finish Date | Project |  | X
Sample Approved Start Data | Project |  | X
Sample Areas Impacted | Project |  | X
Sample Assumptions | Project |  | X
Sample Business Need | Project |  | X
Sample Compliance Proposal | Project |  | X
Flag Status | Task |  | X
Sample Goals | Project |  | X
Sample Post-Implementation Review Date | Project |  | X
Sample Post-Implementation Review Notes | Project |  | X
Sample Primary Objectives | Project |  | X
Project Departments | Project |  | X
Project Impact | Project |  | X
Sample Proposal Cost | Project |  | X
Sample Proposed Finish Date | Project |  | X
Sample Proposed Start Date | Project |  | X
Relative Importance | Project |  | X
Resource Departments | Resource |  | X

Extract your Project Web Access site from a content database to a new content database (Optional)

Note:

Only use this procedure if you do not have a separate content database for your Project Web Access site data.

If you do not have a separate content database for your Project Web App site, your Project Web App site data may share its content database with data from other sites. In this situation, we recommend that you extract the Windows SharePoint Services site collection for PWA into a new content database.

Using this procedure has the following requirements.

  • You must have a fully functional Office Project Server 2007 farm.

  • You must have administrative access to the computer in which the farm is running.

  • In your Office Project Server 2007 farm, you must have at least one Web application (other than the Web application where your Project Web App site exists). A new Web application on http://server:82 is an example of such an application.

  • You know where your Stsadm command-line tool exists. The default location is: %PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\12\BIN.

To extract Project Web Access site content from a content database to a new content database:

  1. Identify the URL of the site collection you want to back up (for example, http://server/PWA).

  2. Use the following Stsadm command to back up the site collection:

    Stsadm -o backup -url<SiteURL>-filename<FullPathToBackupFile>

    For example: Stsadm -o backup -url http://server/pwa -filename c:\temp\backup.bak

  3. Use the following Stsadm command to create a new content database in your second Web application.

    Stsadm.exe -o addcontentDB -url<NewWebAppURL>-ds<SQLServerName>-dn<NewContentDBName>

    For example: Stsadm.exe -o addcontentDB -url http://server:82 -ds CorpSQL1 -dn PWAContentDB

  4. Use the following Stsadm command to restore the site collection to the second Web application.

    Stsadm -o restore -url<SiteURL>-filename<FullPathToBackupFile>

    For example: Stsadm -o restore -url http://server:82/NewPWA -filename c:\temp\backup.bak

    Make sure the site URL that you intend to use while restoring does not already exist in the new Web application (or else this procedure will fail). You are not required to use the same name you used during backup.

    The name you use to restore should be the name you intend to use when you upgrade the data to Project Server 2010.

Back up the databases in SQL Server

Follow the appropriate procedure to back up your Office Project Server 2007 databases and your Project Web Access site content database in SQL Server 2000, SQL Server 2005, or SQL Server 2008 (depending on which you are using to host the databases). Repeat the procedure for each of the following databases in the original server farm:

  • Content

  • Project Server_Draft

  • Project Server_Archived

  • Project Server_Published

  • Project Server_Reporting

At the end of this procedure, you will have created duplicates of each database.

To back up a database in SQL Server 2000

  1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager.

  2. In SQL Server Enterprise Manager, expand Microsoft SQL Servers.

  3. Expand SQL Server Group.

  4. Expand (local) (Windows NT).

  5. Expand Databases.

  6. Right-click the database that you want to back up, point to All Tasks, and then click Backup Database.

  7. In the SQL Server Backup dialog box, in the Name box, specify a name for the backup, and then, in the Backup area, select Database - complete.

  8. In the Destination area, either select an existing destination or do the following:

    1. Click Add.

    2. In the Select Backup Destination box, select File Name, and then, next to the File Name box, click Browse.

    3. In the Backup Device Location - (local) dialog box, in the File name box, type a file name, and then click OK.

    4. Click OK again to close the Select Backup Destination dialog box.

  9. Click OK to start the backup process.

  10. Click OK to acknowledge that the backup process is complete.

Repeat the previous procedure to back up the remaining required databases.

To back up a database in SQL Server 2005

  1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio.

  2. In the Connect to Server box, fill in the connection information, and then click Connect.

  3. After you connect to the appropriate instance of the SQL Server 2005 Database Engine, in Object Explorer, expand the server tree by expanding the server name.

  4. Expand Databases, right-click the database that you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.

  5. In the Source area, in the Database box, verify the database name.

  6. In the Backup type box, select Full.

  7. Under Backup component, select Database.

  8. In the Backup set area, in the Name text box, either accept the default backup set name that is suggested or type a different name for the backup set.

  9. In the Destination area, specify the type of backup destination by selecting Disk or Tape, and then specify a destination. To create a different destination, click Add.

  10. Click OK to start the backup process.

Repeat the previous procedure to back up the remaining required databases.

To back up a database in SQL Server 2008

  1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server 2008, and then click SQL Server Management Studio.

  2. In the Connect to Server box, fill in the connection information, and then click Connect.

  3. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer, expand the server name.

  4. Expand Databases, right-click the database that you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.

  5. In the Source area, in the Database box, verify the database name.

  6. In the Backup type box, select Full.

  7. Under Backup component, select Database.

  8. In the Backup set area, in the Name box, either accept the default backup set name or type a new name.

  9. In the Destination section, specify the type of backup destination by selecting Disk or Tape, and then specify a destination. To create a different destination, click Add.

  10. Click OK to start the backup process.

If you need more information about backing up databases in SQL Server, see the following articles:

  • SQL Server 2008 Books Online: Backing up and restoring databases in SQL Server

  • SQL Server 2005 Books Online: Backing up and restoring databases in SQL Server

  • SQL Server 2000 Books Online: Backup and restore operations

Restore the backup copies to the new farm

After you have configured the new Project Server 2010 server farm, you can restore the backup copies of the databases on the SQL Server instance that you are using to host your Project Server 2010 databases. Note that you must restore to a 64-bit version of SQL Server 2008 SP1 with CU2, or 64-bit SQL Server 2005 SP3 with CU3. Start with one database, and then verify that the recovery has worked before you restore the other databases.

The following section provides procedures for restoring the backups.

To restore a backup copy of a database in SQL Server 2005 Enterprise Edition

  1. In SQL Server Management Studio, right-click Databases, and then click Restore Database. The Restore Database dialog box appears.

  2. In the Restore Database dialog box, on the General page, in the To database box, type the name of the database you are restoring.

  3. In the To a point in time box, keep the default (Most recent possible).

  4. To specify the source and location of the backup sets to restore, click From device, and then click Browse to select the backup file.

  5. In the Specify Backup dialog box, in the Backup media box, be sure that File is selected.

  6. In the Backup location area, click Add.

  7. In the Locate Backup File dialog box, select the file that you want to restore, and then click OK.

  8. In the Select the backup sets to restore grid, select the Restore check box next to the most recent full backup.

  9. In the Restore Database dialog box, on the Options page, under Restore options, select the Overwrite the existing database check box.

  10. Click OK to start the recovery process.

Repeat the previous procedure to restore the remaining required databases.

To restore a backup copy of a database in SQL Server 2008 Enterprise

  1. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer, expand the server name.

  2. Right-click Databases, and then click Restore Database. The Restore Database dialog box appears.

  3. In the Restore Database dialog box, on the General page, type the name of the database to be restored in the To database list.

  4. In the To a point in time box, retain the default (Most recent possible).

  5. To specify the source and location of the backup sets to restore, click From device, and then click Browse to select the backup file.

  6. In the Specify Backup dialog box, in the Backup media box, be sure that File is selected.

  7. In the Backup location area, click Add.

  8. In the Locate Backup File dialog box, select the file that you want to restore, click OK, and then, in the Specify Backup dialog box, click OK.

  9. In the Restore Database dialog box, under Select the backup sets to restore grid, select the Restore check box next to the most recent full backup.

  10. In the Restore Database dialog box, on the Options page, under Restore options, select the Overwrite the existing database check box.

  11. Click OK to start the recovery process.

Repeat the previous procedure to restore the remaining required databases.

For more information about restoring databases in SQL Server, see the following articles:

  • SQL Server 2008 Books Online: Backing up and restoring databases in SQL Server

  • SQL Server 2005 Books Online: Backing up and restoring databases in SQL Server

Add the restored content database to the Project Server 2010 farm

After restoring the Windows SharePoint Services Content database, you need to add it to the Project Server 2010 farm.

Note:

Ensure that the Web application in your Project Server 2010 farm does not contain a site with the same name as the one you are upgrading.

Add the content database to the Project Server 2010 farm

  1. Open a Command Prompt window as Administrator, and navigate to:

    %PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\14\BIN

  2. Run the following:

    STSADM.EXE -o addcontentDB -url<WebAppURL>-databaseserver<SQLServerName>-databasename<WSSContentDBName>

    For example: STSADM.EXE -o addcontentDB -url http://contoso -ds Contoso1 -dn WSS_Content

    The database name should be the exact name of the content database you restored to SQL Server in the previous procedure. When the command prompt returns, the step has been completed.

  3. Monitor the upgrade logs for failure. The Upgrade logs are located at: %PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\14\Logs

  4. If there are any reported failures, navigate to the PWA site—http://<server>/<instance>/_layouts/settings.aspx (for example, http://contoso/pwa/_layouts/settings.aspx). If this page loads successfully, proceed to the next procedure.

Provision a new Project Server 2010 PWA instance using the restored databases

In Project Server 2010, you can now create a Project Web App instance using the Office Project Server 2007 databases you restored to SQL Server in the previous step. When the instance is created, the restored databases will be upgraded to Project Server 2010.

Create a Project Server 2010 Project Web App instance using the restored Project Server 2007 databases

  1. On SharePoint Central Administration Web site, in the Application Management section, click Manage service applications.

  2. On the Manage Service Applications page, click Project Server PSI Service Application.

  3. On the toolbar, click Manage.

  4. On the Manage Project Web App Sites page, click Create Project Web App Site.

  5. On the Create Project Web App Site page:

    1. In the Project Web App Site Location, select the SharePoint Web application that you are using to host Project Web App. Also specify the appropriate Project Web App path.

    2. In the Administrator Account fields, keep the default values.

    3. In the Primary Database field, type the name of the database server where your restored Office Project Server 2007 databases are located.

    4. Verify that the names of the Project Server databases match the names of the restored Office Project Server 2007 databases that you will use. If they do not, change them so that they match.

      Important:

      The databases names must be exact matches with the restored Office Project Server 2007 database names in SQL Server. If the names do not match, a new Project Server 2010 database will be created and the restored Office Project Server 2007 database will not be upgraded.

    5. Click OK.

Project Server will start the PWA site creation process. Click Refresh occasionally to view the status of the instance provisioning. Be patient as this occurs, as it may take a while to finish. When the site creation process has finished, the status shown on the PWA site list is Provisioned.

The URL can now be used to connect Internet Explorer, the Project client, and custom-code based clients to Project Web App.

Note:

The first invocation of the Internet Information Services (IIS) application pool that contains the Project Web App application can be slow as the .NET Framework application is loaded and compiled.

Diagnose failures

If your Project Web App instance does not provision successfully, the provision process will return a status of Failed, at which point you can check the upgrade logs for additional details about the failure.

The upgrade log is located in the following default location: %PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\14\Logs

Each upgrade attempt creates a new log, so view the most current logs. You can view the correct log file by noting the Date/Time stamp that is embedded in the log file name (for example, Upgrade<DateTime>.LOG). Open the log files in Microsoft Excel and search for "Failure" to find more information about the why the upgrade failed. For example, the log file may describe the failure occurring because of an invalid custom field name in the data. You would then need to return to Office Project Server 2007 and fix the issue (possibly by renaming the custom field). You would then need to run through the steps in this procedure again (back up and restore the databases, and then create a new instance in Project Server 2010).

If the upgrade log does not give you any insight in correcting the problem, contact Microsoft Support Services.

Configure for post-installation

After you create the Project Web App instance to upgrade your Office Project Server 2007 databases to Project Server 2010, you can do additional post-installation steps to make the deployment more functional. For example, additional post-installation configuration steps include the following:

  • Configure bulk update for project sites

  • Configure reporting for Project Server 2010

  • Configure Excel Services in Microsoft Office SharePoint Server 2007

  • Configure single sign-on

  • Configure the cube building service

  • Configure Time Reporting periods

  • Configure Exchange integration

The first item in the list, "configure bulk update for project sites," is always necessary in a full database-attach upgrade, and it is described in this article. The other items may be necessary, depending on the features you are using in your environment. For more information about these steps, see Install and configure Project Server 2010.

Configure bulk update for project sites

Because full upgrade includes upgrading project sites from Office Project Server 2007 to Project Server 2010, you have to update the upgraded project site URLs for the new Web application in the Project Server 2010 environment. After you upgrade, the upgraded project sites have invalid URLs that have to be changed to reflect the Project Server 2010 Web application in the new environment. You can use the Bulk Update Project Sites configuration settings on the Project Server 2010 Server settings page (Operation Policies section) to make bulk changes to your project sites' site path information from one Web application to a different one. The change allows you to re-link the upgraded project sites to their upgraded projects.

To configure the bulk update for project sites

  1. On the Project Server 2010 Server Settings page, in the Operational Policies section, click Bulk Update Project Sites.

  2. On the Bulk Update Project Sites page, in the Update Site Paths section, for the Previous Site Path section, in the Web Application field, select the previous site application (default value). In the Previous Site section, in the Path Site URL field, enter the previous site URL.

  3. In the New Site Path section, in the Web Application field, select the Project Server 2010 Web application. In the New Site Path section, in the Site URL field, enter the new Site URL.

  4. In the Update Content Types section, verify that Update Content Types is selected (default). This setting makes sure that Project Issues, Risks, and Document content types are updated in their new environment so that object links are functional.

  5. In the Project Site Permissions section, verify that Synchronize site permissions is selected (default). This makes sure that upgraded users who previously had access to the Project site in the old environment are now able to access the upgraded project site in Project Server 2010.

  6. Click Update.

After you have updated, you can verify that your upgraded projects are now linked to their corresponding project sites. You can verify this on the Project Sites page in the Operational Policies section of Project Server 2010 Server Settings. If relinking was successful, URLs appear in the Site Address column.

Verify whether the migration has been successful

Open Project Web App and check whether your data has migrated correctly. Run your regular testing on this server. If you notice any differences from normal behavior, document them and contact Project Server 2010 Support Services.

See Also

Concepts

Hardware and software requirements (Project Server 2010)


Database-attach core upgrade to Project Server 2010

Published: May 12, 2010

Important:

Upgrading from the Project Server 2010 public Beta to the Project Server 2010 released version is explicitly blocked and not supported. This restriction applies to both the in-place and database-attach upgrade methods.

When you upgrade from Microsoft Office Project Server 2007 to Project Server 2010 by using the database attach upgrade process, you upgrade only the content for your environment, and not the configuration settings. Using the database attach upgrade process is useful when you are changing hardware or want to reconfigure your server farm topology as part of the upgrade process. It is also required if you are upgrading from Office Project Server 2007 deployed on a hardware that only supports a 32-bit server operating system.

Database-attach upgrade to Project Server 2010 can be done either one of two ways:

  • Database Attach full upgrade: Migrates the project data stored in the Office Project Server 2007 databases, plus the Microsoft Project Web App (PWA) site data stored in a SharePoint content database.

  • Database Attach core upgrade: Migrates only the project data stored in the Office Project Server 2007 databases.

This article provides the procedures required to perform a database attach core upgrade. For information about different types of methods for upgrading to Project Server 2010, see Project Server 2010 upgrade overview.

Process overview

When you perform a database attach core upgrade, you are basically using backup copies of your Office Project Server 2007 databases that contain your project data. You restore them on the Microsoft SQL Server instance that you are using for Project Server 2010, and then you upgrade the databases by creating a Microsoft Project Web App instance in Project Server 2010 that points to them. While both the database attach upgrade process and the in-place upgrade process are similar in functionality, the database attach upgrade keeps the original Office Project Server 2007 environment intact because you are using backup copies of the databases for the upgrade process.

Before you begin

Before you begin the database attach full upgrade to Office Project Server 2007, review the following information about permissions, hardware requirements, and software requirements. Follow the specified steps to install or configure prerequisite software or to modify settings.

Review required permissions

You must have at least the following permissions to complete the procedures in this article:

  • On the database server from which the databases are being detached you must be a member of the following roles:

    • The db_owner fixed database role.

    • The db_backupoperator fixed database role.

  • On the server farm to which the databases are being attached, you must be a member of the local Administrators group, and you must be a member of the following roles on the database server:

    • The dbcreator fixed server role.

    • The db_owner fixed database role.

  • In some environments, you must coordinate the move procedures with the database administrator. Be sure to follow any applicable policies and guidelines for handling databases.

Review required hardware and software

You must be running one of the following products on the database servers to perform these procedures:

  • On your Office Project Server 2007 environment: the Microsoft SQL Server Client tools for SQL Server 2000, SQL Server 2005, or SQL Server 2008. These are required to back up your required databases.

  • On your Project Server 2010 environment: a 64-bit version of one of the following products:

    • SQL Server 2008 Service Pack 1 with Cumulative Update 2

    • SQL Server 2005 Service Pack 3 with Cumulative Update 3

Note:

Project Server 2010 databases can only be hosted on 64-bit versions of these two versions of SQL Server.

Perform prerequisite steps

Before you back up the databases, you must prepare for the upgrade by following these steps:

  1. Create a new server farm environment. For information about creating the new environment, see Deploy Project Server 2010 to a server farm environment.

  2. If you have custom site definitions in the old environment, create new site definitions and upgrade definition files for these site definitions and deploy them to the new environment.

Database attach core upgrade overview

A database attach core upgrade will upgrade your Office Project Server 2007 databases:

  • Draft

  • Archive

  • Publish

  • Reporting

The difference between a database attach core upgrade and a database attach full upgrade is that a full upgrade will upgrade not only your Office Project Server 2007 databases, but also your Project Web Access site data contained in a SharePoint content database. If you only want to upgrade your Project Web Access site data plus your Office Project Server 2007 project data, see Database-attach core upgrade to Project Server 2010.

To perform a database attach core upgrade, you must follow these general steps:

  1. Verify your Project Server 2007 data

  2. Back up the databases in SQL Server

  3. Restore the backup copies to the new farm

  4. Provision a new Project Server 2010 PWA instance using the restored databases

  5. Diagnose failures

  6. Configure for post-installation

  7. Verify whether the migration has been successful

These steps require that you have Project Server 2010 installed in your environment. You will not need to configure a Project Web App site prior to doing this procedure. You also do not need to do post-installation configuration such as configuring for Exchange Server integration or reporting, which can be done after upgrading. For more information about installing Project Server 2010, please see Deploy Project Server 2010 to a server farm environment.

Video demonstration

This video provides you an overview of how to use the database-attach core upgrade method to upgrade to Project Server 2010.

DB Attach Core Upgrade - Overview

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=217938). To download the video file, right-click the link, and then click Save Target As.

Verify your Project Server 2007 data

You must verify that your Office Project Server 2007 data is in a valid state to help ensure that your upgrade will be successful. You must verify the following:

  • All projects should be checked-in.

  • The Project Web App site name of "ProjectBICenter" is reserved in Project Server 2010. Verify that Office Project Server 2007 does not use this as a Project Web App site name.

  • The list name of "Project Detail Page" is reserved in Project Server 2010. Verify that Office Project Server 2007Project Web App does not contain a list with this same name.

  • Resolve all custom field and lookup table name conflicts with names that are reserved in Project Server 2010. See the Custom field and lookup table name conflicts section for more information.

Custom field and lookup table name conflicts

There are certain custom fields and lookup tables name that are reserved in both Office Project Server 2007 and Project Server 2010. If you are upgrading from Office Project Server 2007, verify that you do not have custom field names that are in conflict with the names reserved for Project Server 2010. If any of these names are used in the current Office Project Server 2007 database, the custom fields and outline codes must be changed in Office Project Server 2007 before proceeding further with the migration. Use Microsoft Office Project Professional 2007 connected to a Office Project Server 2007 instance to validate and take corrective action.

Reserved outline code names

Outline code name | Type | Office Project Server 2007 | Project Server 2010
Cost Type | Resource | X | X
Health | Task | X | X
State | Project | X | X
Team Name | Resource | X | X
Department |  |  | X
Flag Status |  |  | X

Reserved custom field names

Custom field name | Type | Office Project Server 2007 | Project Server 2010
Cost Type | Resource | X | X
Health | Task | X | X
State | Project | X | X
Team Name | Resource | X | X
Sample Approved Finish Date | Project |  | X
Sample Approved Start Data | Project |  | X
Sample Areas Impacted | Project |  | X
Sample Assumptions | Project |  | X
Sample Business Need | Project |  | X
Sample Compliance Proposal | Project |  | X
Flag Status | Task |  | X
Sample Goals | Project |  | X
Sample Post-Implementation Review Date | Project |  | X
Sample Post-Implementation Review Notes | Project |  | X
Sample Primary Objectives | Project |  | X
Project Departments | Project |  | X
Project Impact | Project |  | X
Sample Proposal Cost | Project |  | X
Sample Proposed Finish Date | Project |  | X
Sample Proposed Start Date | Project |  | X
Relative Importance | Project |  | X
Resource Departments | Resource |  | X

Video demonstration

This video provides you an overview of how to prepare your Office Project Server 2007 data for upgrade when you are using the database-attach core upgrade method to upgrade to Project Server 2010.

DB Attach Core Upgrade - Prepare for Upgrade

Watch this video (http://go.microsoft.com/fwlink/p/?LinkId=217939). To download the video file, right-click the link, and then click Save Target As.

Back up the databases in SQL Server

Follow the appropriate procedure to back up your Office Project Server 2007 databases in SQL Server 2000, SQL Server 2005, or SQL Server 2008 (depending on which you are using to host the databases). Repeat the procedure for each of the following databases in the original server farm:

  • Project Server_Draft

  • Project Server_Archived

  • Project Server_Published

  • Project Server_Reporting

At the end of this procedure, you will have created duplicates of each database.

To back up a database in SQL Server 2000

  1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager.

  2. In SQL Server Enterprise Manager, expand Microsoft SQL Servers.

  3. Expand SQL Server Group.

  4. Expand (local) (Windows NT).

  5. Expand Databases.

  6. Right-click the database that you want to back up, point to All Tasks, and then click Backup Database.

  7. In the SQL Server Backup dialog box, in the Name box, specify a name for the backup, and then, in the Backup area, select Database - complete.

  8. In the Destination area, either select an existing destination or do the following:

    1. Click Add.

    2. In the Select Backup Destination box, select File Name, and then, next to the File Name box, click Browse.

    3. In the Backup Device Location - (local) dialog box, in the File name box, type a file name, and then click OK.

    4. Click OK again to close the Select Backup Destination dialog box.

  9. Click OK to start the backup process.

  10. Click OK to acknowledge that the backup process is complete.

Repeat the previous procedure to back up the remaining required databases.

To back up a database in SQL Server 2005

  1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio.

  2. In the Connect to Server box, fill in the connection information, and then click Connect.

  3. After you connect to the appropriate instance of the SQL Server 2005 Database Engine, in Object Explorer, expand the server tree by expanding the server name.

  4. Expand Databases, right-click the database that you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.

  5. In the Source area, in the Database box, verify the database name.

  6. In the Backup type box, select Full.

  7. Under Backup component, select Database.

  8. In the Backup set area, in the Name text box, either accept the default backup set name that is suggested or type a different name for the backup set.

  9. In the Destination area, specify the type of backup destination by selecting Disk or Tape, and then specify a destination. To create a different destination, click Add.

  10. Click OK to start the backup process.

Repeat the previous procedure to back up the remaining required databases.

To back up a database in SQL Server 2008

  1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server 2008, and then click SQL Server Management Studio.

  2. In the Connect to Server box, fill in the connection information, and then click Connect.

  3. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer, expand the server name.

  4. Expand Databases, right-click the database that you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.

  5. In the Source area, in the Database box, verify the database name.

  6. In the Backup type box, select Full.

  7. Under Backup component, select Database.

  8. In the Backup set area, in the Name box, either accept the default backup set name or type a new name.

  9. In the Destination section, specify the type of backup destination by selecting Disk or Tape, and then specify a destination. To create a different destination, click Add.

  10. Click OK to start the backup process.

If you need more information about backing up databases in SQL Server, see the following articles:

  • SQL Server 2008 Books Online: Backing up and restoring databases in SQL Server

  • SQL Server 2005 Books Online: Backing up and restoring databases in SQL Server

  • SQL Server 2000 Books Online: Backup and restore operations

Video demonstration

This video describes how to create backup files of Office Project Server 2007 databases when you are using the database-attach core upgrade method to upgrade to Project Server 2010.

DB Attach Core Upgrade - Backup databases

Watch this video (http://go.microsoft.com/fwlink/p/?LinkId=217940). To download the video file, right-click the link, and then click Save Target As.

Restore the backup copies to the new farm

After you have configured the new Project Server 2010 server farm, you can restore the backup copies of the databases on the SQL Server instance that you are using to host your Project Server 2010 databases. Note that you must restore to a 64-bit version of SQL Server 2008 SP1 with CU2, or 64-bit SQL Server 2005 SP3 with CU3. Start with one database, and then verify that the recovery has worked before you restore the other databases.

The following section provides procedures for restoring the backups.

To restore a backup copy of a database in SQL Server 2005 Enterprise Edition

  1. In SQL Server Management Studio, right-click Databases, and then click Restore Database. The Restore Database dialog box appears.

  2. In the Restore Database dialog box, on the General page, in the To database box, type the name of the database you are restoring.

  3. In the To a point in time box, keep the default (Most recent possible).

  4. To specify the source and location of the backup sets to restore, click From device, and then click Browse to select the backup file.

  5. In the Specify Backup dialog box, in the Backup media box, be sure that File is selected.

  6. In the Backup location area, click Add.

  7. In the Locate Backup File dialog box, select the file that you want to restore, and then click OK.

  8. In the Select the backup sets to restore grid, select the Restore check box next to the most recent full backup.

  9. In the Restore Database dialog box, on the Options page, under Restore options, select the Overwrite the existing database check box.

  10. Click OK to start the recovery process.

Repeat the previous procedure to restore the remaining required databases.

To restore a backup copy of a database in SQL Server 2008 Enterprise

  1. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer, expand the server name.

  2. Right-click Databases, and then click Restore Database. The Restore Database dialog box appears.

  3. In the Restore Database dialog box, on the General page, type the name of the database to be restored in the To database list.

  4. In the To a point in time box, retain the default (Most recent possible).

  5. To specify the source and location of the backup sets to restore, click From device, and then click Browse to select the backup file.

  6. In the Specify Backup dialog box, in the Backup media box, be sure that File is selected.

  7. In the Backup location area, click Add.

  8. In the Locate Backup File dialog box, select the file that you want to restore, click OK, and then, in the Specify Backup dialog box, click OK.

  9. In the Restore Database dialog box, under Select the backup sets to restore grid, select the Restore check box next to the most recent full backup.

  10. In the Restore Database dialog box, on the Options page, under Restore options, select the Overwrite the existing database check box.

  11. Click OK to start the recovery process.

Repeat the previous procedure to restore the remaining required databases.

For more information about restoring databases in SQL Server, see the following articles:

  • SQL Server 2008 Books Online: Backing up and restoring databases in SQL Server

  • SQL Server 2005 Books Online: Backing up and restoring databases in SQL Server

Video demonstration

This video describes how to restore Office Project Server 2007 databases on the database server that is hosting the Project Server 2010 installation when you are using the database-attach core upgrade method to upgrade to Project Server 2010.

DB Attach Core Upgrade - Restore Databases

Watch this video (http://go.microsoft.com/fwlink/p/?LinkId=217941). To download the video file, right-click the link, and then click Save Target As.

Provision a new Project Server 2010 PWA instance using the restored databases

In Project Server 2010, you can now create a Project Web App instance using the Office Project Server 2007 databases you restored to SQL Server in the previous step. When the instance is created, the restored databases will be upgraded to Project Server 2010.

Create a Project Server 2010 PWA instance using the restored Office Project Server 2007 databases

  1. On the SharePoint Central Administration Web site, in the Application Management section, click Manage service applications.

  2. On the Manage Service Applications page, click Project Server Service Application.

  3. On the toolbar, click Manage.

  4. On the Manage Project Web App Sites page, click Create Project Web App Site.

  5. On the Create Project Web App Site page:

    1. In the Project Web App Site Location and Administrator Account fields, keep the default values.

    2. In the Primary Database field, type the name of the database server where your restored Office Project Server 2007 databases are located.

    3. Verify that the names of the Project Server databases match the names of the restored Office Project Server 2007 databases that you will use. If they do not, change them so that they match.

      Important:

      The databases names must be exact matches with the restored Office Project Server 2007 database names in SQL Server. If the names do not match, a new Project Server 2010 database will be created and the restored Office Project Server 2007 database will not be upgraded.

    4. Click OK.

Project Server will start the PWA site creation process. Click Refresh occasionally to view the status of the instance provisioning. Be patient as this occurs, as it may take a while to finish. When the site creation process has finished, the status shown on the PWA site list is Provisioned.

The URL can now be used to connect Internet Explorer, the Project client, and custom-code based clients to Project Web App.

Note:

The first invocation of the Internet Information Services (IIS) application pool that contains the Project Web App application can be slow as the .NET Framework application is loaded and compiled.

Video demonstration

This video describes how to provision a new Project Web App instance that uses your restored Office Project Server 2007 databases when you are using the database-attach core upgrade method to upgrade to Project Server 2010.

DB Attach Core Upgrade - Provision Instance

Watch this video (http://go.microsoft.com/fwlink/p/?LinkId=217943). To download the video file, right-click the link, and then click Save Target As.

Diagnose failures

If your Project Web App instance does not provision successfully, the provision process will return a status of Failed, at which point you can check the upgrade logs for additional details about the failure.

The upgrade log is located in the following default location: %PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\14\Logs

Each upgrade attempt creates a new log, so view the most current logs. You can view the correct log file by noting the Date/Time stamp that is embedded in the log file name (for example, Upgrade<DateTime>.LOG). Open the log files in Microsoft Excel and search for "Failure" to find more information about the why the upgrade failed. For example, the log file may describe the failure occurring because of an invalid custom field name in the data. You would then need to return to Office Project Server 2007 and fix the issue (possibly by renaming the custom field). You would then need to run through the steps in this procedure again (back up and restore the databases, and then create a new instance in Project Server 2010).

If the upgrade log does not give you any insight in correcting the problem, contact Microsoft Support Services.

Configure for post-installation

After creating the Project Web App instance to upgrade your Office Project Server 2007 databases to Project Server 2010, you can do additional post-installation steps to make the deployment more functional. For example, additional post-installation configuration steps include:

  • Configure reporting for Project Server 2010

  • Configure Excel Services in Microsoft Office SharePoint Server 2007

  • Configure single sign-on

  • Configure the cube building service

  • Configure Time Reporting periods

  • Configure Exchange integration

For more information about these steps, see Install and configure Project Server 2010.

Verify whether the migration has been successful

Open Project Web App and check whether your data has migrated properly. Run your regular testing on this server. If you notice any differences from normal behavior, document this and contact Project Server 2010 Support Services.


Virtual migration environment (VME) guide for Project Server 2010

Published: May 15, 2010

The Project Server VME is a virtualized Office Project Server 2007 environment that contains all the necessary applications and utilities required to migrate Project Server 2003 data to Office Project Server 2007.

Chapters in this guide:

  • Overview of the VME for Project Server 2010

  • Configure the Hyper-V environment for the Project Server VME

  • Project Server VME: Pre-migration phase

  • Project Server VME: Migration phase

  • Project Server VME: Post-migration phase

  • Project Server VME: Plan to upgrade data to Project Server 2010


Overview of the VME for Project Server 2010

Published: May 15, 2010

This article discusses the Microsoft Project Server virtual migration environment (VME).

In this article:

  • About the Project Server virtual migration environment

  • Requirements for the virtual migration environment

  • What the VME contains

  • Phases of migration with the VME

The Project Server VME can be downloaded from the Project Server VME download page (http://go.microsoft.com/?linkid=9729345) located in the Microsoft Download Center.

About the Project Server virtual migration environment

The Project Server VME is a virtualized Office Project Server 2007 environment that contains all the necessary applications and utilities required to migrate Project Server 2003 data to Office Project Server 2007. To migrate from Microsoft Office Project Server 2003 to Microsoft Project Server 2010, first you must migrate your data to Microsoft Office Project Server 2007 format. If you do not have an Office Project Server 2007 deployment readily available, you can choose to use the Project Server virtual migration environment (VME) to migrate your data to Office Project Server 2007 format.

The VME is a fully configured Microsoft Office Project Server 2007 with Service Pack 2 (SP2) environment packaged as a Hyper-V image. The VME should be run as a stand-alone environment for the sole purpose of migrating Project Server 2003 data to the Office Project Server 2007 data format. (The VME does not have to be connected to the network or require network access).

The process of migrating Project Server 2003 data by using the VME provides the following advantages:

  • It can run in a stand-alone environment and does not require network access

  • It requires minimal hardware investment

  • It provides a fully functional environment that requires little intervention to use

  • It provides the ability to run migrations iteratively so that issues can be resolves resolved and retested

Warning:

Do not use the VME for production use. It is intended to be used only as a pass-through environment to migrate your Project Server 2003 data to Office Project Server 2007.

Requirements for the virtual migration environment

The VME environment configuration requires the following:

  • The Hyper-V feature on Windows Server 2008 R2

  • 3096 MB or more of allocated memory for the image

  • Two virtual processors for the image (recommended)

Important:

The VME is only supported on Windows Server 2008 R2 with its Hyper-V Manager feature. The VME does not run on Windows Server 2008.

Because the VME runs in a stand-alone environment, an internal network must still exist between the virtual machine that is running the VME and the Virtual Host Machine. This internal network must exist in order to transfer your Project Server 2003 databases to the virtual machine that is hosting the VME. (For example, the database might be attached to the Virtual Host Machine through an external hard drive.) After the Project Server 2003 data has been migrated to Office Project Server 2007 through the VME, the Office Project Server 2007 databases can then be transferred back to the external hard drive.

What the VME contains

When the Project Server 2010 VME image is restored to a virtual machine on a Hyper-V Server, the virtual machine will have the following two hard drives:

  • Virtual Hard Drive 1: Contains all system software. This virtual hard drive will have an expiration limit of 180 days. The expiration limit is intended to make sure that the applications are not used for production use, for which it is not supported.

  • Virtual Hard Drive 2 (E drive): Contains all VME content (SQL scripts, migration configuration files, and commands needed to run the migration).

Operating system and installed applications

The VME contains the following operating system and installed software applications:

  • Windows Server 2008 R2 operating system

  • Office Project Server 2007 with SP2 with the October 2009 Cumulative Update

  • Microsoft Office SharePoint Server 2007 with Service Pack 2 (SP2) with the October 2009 Cumulative Update

  • Windows SharePoint Services 3.0 with Service Pack 2 (SP2) with the October 2009 Cumulative Update

  • Microsoft Office Project Professional 2007 with Service Pack 2 October 2009 Cumulative Update and the Project Migration Tool installed

  • Microsoft SQL Server 2005 with Service Pack 3 and Cumulative Update 17

Note:

The Windows Server 2008 Release 2 operating system must be activated within 10 days. You can use the Activate-by-telephone option if the VME virtual machine is not on the network.

Overview of the migration scripts

The SQL scripts on Virtual Hard Drive 2 were created to help in the migration process. Use of these scripts is optional, but highly recommended. These scripts include the following:

Script name | Purpose
VME Script 1.sql | Checks your Project Server 2003 data for conditions that may prevent the data from upgrading successfully.
VME Script 2.sql | Provides statistics about the Project Server 2003 data that you are migrating (for example, number of projects, tasks, assignments, and so on).
VME Script 3.sql | Provides a data validation snapshot of your pre-migration Project Server 2003 data and stores it to a database. This data can be compared to a post migration data snapshot (from VME Script 5.sql) to determine differences between the pre-migration and migrated data.
VME Script 4.sql | Lists all projects with associated project workspace sites from the Project Server 2003 database.
VME Script 5.sql | Provides a data validation snapshot of migrated Office Project Server 2007 data and stores it to a database.
VME Script 6.sql | Lists all projects with associated project workspace sites from the migrated Office Project Server 2007 database.
VME Script 7.sql | Compares data validation snapshots (pre-migration Project Server 2003 and post-migration Office Project Server 2007) and lists the differences between them. This can help determine whether specific data was not migrated.
VME Script 8.sql | Compares projects with associated workspaces from pre-migration (Project Server 2003) and post-migration (Office Project Server 2007), and then shows the projects with workspaces that have not been re-linked or converted in the Office Project Server 2007 environment after migration.
VME Script 9.sql | Does a pre-migration check on the Office Project Server 2007 database to check for known data issues that can cause upgrade to fail when you upgrade to Project Server 2010.
VME Script 10.sql | Checks your Office Project Server 2007 data for a known issue in which multi-language lookup tables are not updated correctly after migration. This script will make corrective action to your Office Project Server 2007 data.

Phases of migration with the VME

The process of running the VME to migrate your Project Server 2003 data consists of the following five phases:

  • Configure the Hyper-V environment for the Project Server VME

  • Project Server VME: Pre-migration phase

  • Project Server VME: Migration phase

  • Project Server VME: Post-migration phase

  • Project Server VME: Plan to upgrade data to Project Server 2010

Click the link to each chapter for more information about the procedures needed for that phase.


Configure the Hyper-V environment for the Project Server VME

Published: May 15, 2010

Important:

The Project Server virtual migration environment (VME) is only supported on Windows Server 2008 R2 using the Hyper-V Manager feature. The VME does not run on Windows Server 2008.

This chapter describes the procedures required to set up the Project Server VME and move your Microsoft Office Project Server 2003 data to the VME. Restoring the VME image to a virtual machine requires you to have a working host computer that is running Windows Server 2008 R2 Hyper-V Manager. The host computer must also have at least 4 GB of RAM total and 3 GB of RAM available for the virtual migration environment. There should be a minimum of four times the size of your Project and SharePoint databases available to the VME for the upgrade. The host computer can be either stand-alone or connected to the network. The VME uses local accounts for all actions.

After the VME is restored, a snapshot of the virtual machine is available in Hyper-V Manager so that you are able to reset the VM to its original state. This enables you to easily restore the original image if you have to rerun the migration.

This chapter includes the following articles:

  • Project Server VME: Create a backup of the existing Project Server 2003 database

  • Project Server VME: Import the virtual migration environment

  • Project Server VME: Set up data exchange between the host computer and VME virtual machine

  • Load data to the Project Server VME

  • Project Server VME: Restore your project workspace data

For more information about the Project Server virtual migration environment, see Migrate your Project Server 2003 data by using the VME. For more information about how to upgrade to Microsoft Project Server 2010, see Project Server 2010 upgrade overview.


Project Server VME: Create a backup of the existing Project Server 2003 database

Published: May 15, 2010

This article describes how to create backups of your Microsoft Office Project Server 2003 databases in your Project Server 2003 environment. You can then move them to the Project Server virtual migration environment (VME) to migrate your data to Microsoft Office Project Server 2007.

  • If the Project Server 2003 data is contained in a single database, create a backup of your Project Server database.

  • If your Project Server 2003 data is split into two databases, create a backup copy of both your Project Server database and your Project Web database.

  • Optionally, if you are migrating your project workspace data, you have to make a backup of the Windows SharePoint Services 2.0 content database that contains your project workspace data.

You may want to make the Project Server 2003 database backup files accessible to the virtual migration environment virtual machine by copying them to an external hard drive. This allows you to attach the external hard drive to the virtual machine host to make them accessible to the VME. After you have migrated your Project Server 2003 data to Office Project Server 2007 on the VME, you can then copy the migrated data to the external hard drive in order to upgrade in Project Server 2010.

Important:

Project Server 2003 Service Pack 3 is a requirement for migrating your data to Office Project Server 2007. Prior to creating database backups, verify that Project Server 2003 Service Pack 3 is installed in your Project Server 2003 environment. Additionally, if you have project workspace data that you plan to migrate, you should also verify that Windows SharePoint Services 2.0 is updated to Service Pack 3.

This article describes one of several tasks that is required to configure your Hyper-V environment for the Project Server virtual migration environment. For more information about other tasks required to configure your Hyper-V, see Configure the Hyper-V environment for the Project Server VME. For more information about the VME, see Overview of the VME for Project Server 2010.

Create a backup of existing Project Server 2003 databases

Use either of the following procedures to create a backup of the Project Server 2003 databases that you need for the VME.

  • To back up a database in SQL Server 2000

  • To back up a database in SQL Server 2005

To back up a database in SQL Server 2000

  1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager.

  2. In SQL Server Enterprise Manager, expand Microsoft SQL Servers.

  3. Expand SQL Server Group.

  4. Expand (local) (Windows NT).

  5. Expand Databases.

  6. Right-click the database that you want to back up, point to All Tasks, and then click Backup Database.

  7. In the SQL Server Backup dialog box, in the Name box, specify a name for the backup, and then, in the Backup area, select Database - complete.

  8. In the Destination area, either select an existing destination or do the following:

    1. Click Add.

    2. In the Select Backup Destination box, select File Name, and then, next to the File Name box, click Browse.

    3. In the Backup Device Location - (local) dialog box, in the File name box, type a file name, and then click OK.

    4. Click OK again to close the Select Backup Destination dialog box.

  9. Click OK to start the backup process.

  10. Click OK to acknowledge that the backup process is complete.

To back up a database in SQL Server 2005

  1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio.

  2. In the Connect to Server box, specify the connection information, and then click Connect.

  3. After you connect to the appropriate instance of the SQL Server 2005 Database Engine, in Object Explorer, expand the server tree by expanding the server name.

  4. Expand Databases, right-click the database that you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.

  5. In the Source area, in the Database box, verify the database name.

  6. In the Backup type box, select Full.

  7. In the Backup component section, select Database.

  8. In the Backup set area, in the Name box, either accept the default backup set name that is suggested or type a different name for the backup set.

  9. In the Destination area, specify the type of backup destination by selecting Disk, and then specify a destination. To create a different destination, click Add.

  10. Click OK to start the backup process.


Project Server VME: Import the virtual migration environment

Published: May 15, 2010

The Project Server virtual migration environment (VME) must be imported from the Project Server Virtual Migration Environment download package (http://go.microsoft.com/?linkid=9729345) in the Microsoft Download Center. The following procedure is used to import the VME and restore it in a virtual machine on a Windows Server 2008 R2 computer by using Hyper-V Manager.

Important:

The VME is only supported on Windows Server 2008 R2 using the Hyper-V Manager feature. The VME does not run on Windows Server 2008.

This article describes one of several tasks required to configure your Hyper-V environment for the Project Server virtual migration environment. For more information about other tasks required to configure your Hyper-V environment, see Configure the Hyper-V environment for the Project Server VME. For more information about the VME, see Overview of the VME for Project Server 2010.

To import the virtual migration environment

  1. Create a directory on the Hyper-V host to contain the VME files. The zip file is approximately 3.5 GB and when unzipped the files occupy approximately 7 GB. Plan appropriately for hard disk space.

  2. Download the "Project Server VME.ZIP" file. Unzip the contents of the file to the directory created above. After unzipping is complete, you will see a subdirectory called "ProjectVME".

  3. Start the Hyper-V manager on the Hyper-V host computer.

  4. From the Actions pane, select Import Virtual Machine.

  5. In the Import Virtual Machine dialog box, click Browse. In the Select Folder dialog box, select the ProjectVME directory created in step 2, and then click Select Folder. This contains a config.xml file.

  6. In the Import Virtual Machine dialog box, click Import.

    Note:

    After the import process is completed, do not start the VME virtual machine yet.

After the import has completed, see the Project Server VME: Set up data exchange between the host computer and VME virtual machine to configure data exchange between the VME virtual machine and VM host computer.


Project Server VME: Set up data exchange between the host computer and VME virtual machine

Published: May 15, 2010

This article describes how to set up communication between the Project Server virtual migration environment (VME) host computer and the VME virtual machine. This allows you to transfer the Microsoft Office Project Server 2003 databases to the VME virtual machine for upgrading, and to transfer the upgraded Microsoft Office Project Server 2007 databases from the VME. If you have added the VME to you network, you will not have to do this procedure because you can simply create a shared folder in which you can copy and paste your databases. If the VME is not on your network, you have to run through the procedures in this article to create a virtual network in Hyper-V manager. This process establishes communication between the Windows Server 2008 R2 computer that is hosting the Project Server Virtual Migration virtual machine and the VME virtual machine. After establishing communication, see Load data to the Project Server VME for information about setting up the shared folder and transferring data to the VME virtual machine.

Important:

The VME is only supported on Windows Server 2008 R2 by using the Hyper-V Manager feature. The VME does not run on Windows Server 2008.

This article describes one of several tasks required to configure your Hyper-V environment for the Project Server virtual migration environment. For more information about other tasks required to configure your Hyper-V environment, see Configure the Hyper-V environment for the Project Server VME. For more information about the VME, see Overview of the VME for Project Server 2010.

Create a virtual network

You can create a virtual network on the server running Hyper-V to provide communication between the virtualization server and virtual machines by creating an Internal Virtual Network. An Internal Virtual Network allows for communications between the virtual machines and the physical computer. After creating the Internal Virtual Network, you have to add a network adapter to the VME virtual machine.

The following procedures provide the basic instructions to create a virtual network in Hyper-V Manager.

To create an Internal Virtual Network

  1. On the VM host computer, click Start, click Administrative Tools, and then click Hyper-V Manager.

  2. On the Hyper-V Manager page, in the Actions pane, click Virtual Network Manager.

  3. On the Virtual Network Manager page, in the Create virtual network section, in the What type of network you want to create? list, select Internal. Then click Add.

  4. In the New Virtual Networks page, in the Name field, type a name for the new network. Review the other properties and modify them as necessary. Click OK to create the virtual network and close the Virtual Network Manager.

To add a network adapter to a virtual machine

  1. Click Start, click Administrative Tools, and then click Hyper-V Manager.

  2. On the Hyper-V Manager page, in the Virtual Machines list, select the virtual machine that you want to configure (ProjectVME).

    Note:

    The virtual machine you select must not be in a Running state.

  3. In the Actions pane, in the menu for the virtual machine that you selected, click Settings.

  4. On the Settings page, in the Add Hardware section, choose a network adapter or a legacy network adapter. Network adapters can only be added to a virtual machine when the machine is turned off. (For more information about each type of adapter, see the Additional considerations section below.) Click Add.

  5. In the Network Adapter section, from the Network drop-down list select the virtual network that you want to connect to.

  6. In the MAC Address section, if you want to configure a static MAC address or virtual LAN identifier, specify the address or identifier that you want to use.

  7. Click OK.

For more information, see the following blog post: Exchanging files between Parent and Child Partitions in Hyper-V (http://go.microsoft.com/fwlink/p/?LinkId=192759).

Additional considerations

By default, membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. However, an administrator can use Authorization Manager to modify the authorization policy so that a user or group of users can complete this procedure.

A legacy network adapter works without installing a virtual machine driver because the driver is already available on most operating systems. The legacy network adapter emulates a physical network adapter, multiport DEC 21140 10/100TX 100 MB. A legacy network adapter also supports network-based installations because it includes the ability to boot to the Pre-Boot Execution Environment (PXE). The legacy network adapter is not supported in the 64-bit edition of Windows Server 2003 or the Windows XP Professional x64 Edition.

Important:

Make sure to reboot your VME virtual machine after initial start. The reason you have to do this is that the operating system determines that the hardware you are running is different from the hardware on which the VME was created and last run, which requires a reboot.


Load data to the Project Server VME

Published: May 15, 2010

This article describes how to move the Microsoft Office Project Server 2003 data from the virtual machine host to the Project Server virtual migration environment (VME) virtual machine. Before doing procedures in this article you must have created a backup copy of your Project Server 2003 databases and established data exchange between the host computer and the VME virtual machine. These procedures are described in the following two articles:

  • Project Server VME: Create a backup of the existing Project Server 2003 database

  • Project Server VME: Set up data exchange between the host computer and VME virtual machine

This article describes:

  • Move Project Server 2003 database backups to the VME virtual machine

  • Restore your database to the VME virtual machine

This article is one of several tasks required to configure your Hyper-V environment for the Project Server virtual migration environment (VME). For more information about other tasks required to configure the Hyper-V environment, see Configure the Hyper-V environment for the Project Server VME. For more information about the VME, see Overview of the VME for Project Server 2010.

Move Project Server 2003 database backups to the VME virtual machine

Use the following procedure to create a share on the Project Server VME and to move the backup copies of your Project Server 2003 databases from the virtual machine host to the VME virtual machine.

Note:

If the following procedure requires you to enter credentials for the VME virtual machine, the domain and User ID are "VME\Administrator", and the password is "pass@word1".

Move Project Server 2003 database backups to the VME

  1. On the VME virtual machine, open a Command Prompt window and run the command IPConfig. Notice the Autoconfiguration IPv4 Address specified there.

  2. On the Hyper-V host machine, click Start, and then click Run. In the Open field, type \\<IP Address of the VME virtual machine>\E$. For "IP Address of the VME virtual machine", use the Autoconfiguration IPv4 Address that you noted in the previous step. If you are prompted for your credentials, enter the credentials for the VME virtual machine listed earlier. (The Domain\Username is "VME\Administrator", and the password is "pass@word1".)

  3. In Windows Explorer, click New folder and create a folder in the root of the E drive of the VME virtual machine and give it a name (for example, "ProjectServerData").

  4. In Windows Explorer, copy the backup copies of your Project Server 2003 database or databases from the location they are stored at. Paste them to the folder you have just created on the E drive of the VME virtual machine in the previous step. If you are migrating the project workspace data, also copy your backup of the Windows SharePoint Services 2.0 databases that contain your project workspace data to the folder.

Restore your database to the VME virtual machine

After copying backups of the Project Server 2003 database (or databases) to the VME virtual machine, use the following procedure to restore the database or databases to Microsoft SQL Server 2005 on the VME virtual machine.

Restore the database to the VME

  1. In Hyper-V Manager, switch to the VME virtual machine.

  2. Click Start, click All Programs, click Microsoft SQL Server 2005, and then click SQL Server Management Studio.

  3. On the Connect to Server dialog box, click Connect.

  4. On the Microsoft SQL Server Management Studio page, in the Object Explorer section, right-click Databases, and then click Restore Database.

  5. On the Restore Database page, in the Destination to restore section, in the To database field, type Project2003SourceDB.

    Important:

    When restoring your databases, verify that you are renaming them to the exact name specified in the procedures. The migration tool configuration file and the optional migration scripts need the database names to be accurate to function correctly.

  6. In the Source for restore section, to the right of the From device option button, click the ellipsis (…) button.

  7. In the Specify Backup dialog box, click Add.

  8. Select the folder on the E drive to which you copied the database backups and select the Project Server 2003 database backup file. Click OK. On the Specify Backup page, click OK again.

  9. In the Select the backup sets to restore list, click the check box in the Restore column.

  10. Click OK. Your database will be restored.

If the Project Server 2003 database is partitioned into two separate databases, you also must restore the Project Web database (default name "Project2003WebTablesDB"). Run through the step again to restore this database. Make sure to restore this database to the name Project2003SourceWebDB. Again note that it is important to restore the Project Web database to this exact name.

Note:

If you are migrating the Project Server 2003 workspace data, read the directions first. See Project Server VME: Restore your project workspace data for more information before attempting to restore the Windows SharePoint Services 2.0 content database that contains your project workspace data.


Project Server VME: Restore your project workspace data

Published: May 15, 2010

Warning:

This step is optional and is only required if you are migrating the Microsoft Office Project Server 2003 project workspace data.

The Project Server 2003 project workspace data is contained in a Windows SharePoint Services 2.0 content database on the computer that is running Microsoft SQL Server and that is hosting your Project Server 2003 farm environment. Windows SharePoint Services 2.0 was an optional application that you could install with Project Server 2003. It allowed for the creation of project workspaces in Project Server 2003. All data (issues, risks, and documents stored in the project workspaces, as well as associations between the Project items and Windows SharePoint Services 2.0 items) are stored to a Windows SharePoint Services 2.0 content database. If you want to migrate your project workspace data to Microsoft Project Server 2010, this database must be restored and migrated to Windows SharePoint Services 3.0. The Project Server virtual migration environment (VME) allows you to do this.

This article describes the two steps in restoring your project workspace content database to the VME virtual machine:

  • Run the Pre-Upgrade Pre-scan tool on your Windows SharePoint Services 2.0 content database

  • Move the Windows SharePoint Services 2.0 content database to the VME

This article describes one of several tasks required to configure your Hyper-V environment for the Project Server virtual migration environment. For more information about other tasks required to configure your Hyper-V environment, see Configure the Hyper-V environment for the Project Server VME. For more information about the VME, see Overview of the VME for Project Server 2010.

Run the Pre-scan tool on your Windows SharePoint Services 2.0 content database

Prior to migrating the project workspace sites and their content to Windows SharePoint Services 3.0, we recommend that you use the Pre-scan tool to validate the Windows SharePoint Services 2.0 content database that contains the project workspaces.

In addition, if customization has been applied to site templates or objects, the Pre-scan utility validates whether they are compatible with Windows SharePoint Services 3.0.

Important:

This must be done in the Project Server 2003 environment. It should not be done in the VME.

To run Pre-scan

  1. Download the Pre-Scan utility from the SharePoint Products and Technologies Utility: Upgrade Pre-scan Tool page on the Microsoft Download Center. Download the file named Prescan.exe to the server running Windows SharePoint Services 2.0.

  2. Open a Command Prompt window and run the following command: Prescan.exe /all

  3. When the process is complete, "Operation Completed Successfully" appears.

For more information about running the Pre-scan utility, see the "Prescan.exe ReadMe" document available from the same download page. (The file name is Prescan.doc.)

View the following articles if you encounter any problems when running the Pre-Scan tool:

  • Your Friend Prescan.exe - How to Get it & What it Does - Part 2

  • Understanding Pre-Scan errors

Move the Windows SharePoint Service 2.0 content database to the VME

After running Pre-scan, make a backup copy of the content database containing your project workspace data. You can use the procedures in Project Server VME: Create a backup of the existing Project Server 2003 database to create a backup of the Windows SharePoint Services 2.0 content database. After making the backup copy of the database, move the backup copy of the database to the VME virtual machine, and then restore the database in Microsoft SQL Server 2005. Use the procedures described in Load data to the Project Server VME to move the database to the VME virtual machine, and to restore the database in SQL Server 2005. Make sure to restore the content database to a unique database name.

For more information about migrating your Windows SharePoint Services 2.0 content database to Windows SharePoint Services 3.0 in the virtual migration environment, see the "Full Migration from Windows SharePoint Services 2.0 (to a different computer)" section of Upgrade project workspaces from Project Server 2003.

For additional documentation about Microsoft SharePoint Server migration and upgrade, see the \SharePoint folder on the E drive of the VME. To view the content, you must first click Click I Accept at bottom to start - MigrationEULA (located in the "Migrate SharePoint" folder) to accept the licensing agreement.


Project Server VME: Pre-migration phase

Published: May 15, 2010

This chapter describes the tasks required in the pre-migration phase when you are using the Project Server Virtual Migration Environment (VME) to migrate your Microsoft Office Project Server 2003 data to Microsoft Office Project Server 2007. Run these tasks after you have completed the tasks listed in Configure the Hyper-V environment for the Project Server VME and before you try to run the migration.

Articles in this chapter are as follows:

  • Check for reserved custom field, lookup table, or outline code name conflicts (Project Server)

  • Disable Dynamic Content Compression in IIS Manager

  • Project Server VME: Run pre-migration scripts (optional)

After completing the tasks required in the pre-migration phase, see Project Server VME: Migration phase.

The Project Server virtual migration environment is a Office Project Server 2007 virtual environment used to migrate Project Server 2003 data to Microsoft Project Server 2010. There is no direct migration path from Office Project Server 2007 to Project Server 2010. However, the Project Server VME can be used as a pass-through environment to upgrade your Project Server 2003 data to Office Project Server 2007 before upgrading the data to Project Server 2010. For more information about the Project Server virtual migration environment, see Migrate your Project Server 2003 data by using the VME. For more information about how to upgrade to Microsoft Project Server 2010, see Project Server 2010 upgrade overview.


Check for reserved custom field, lookup table, or outline code name conflicts (Project Server)

Published: May 15, 2010

The first pre-migration task that you have to do in the Project Server virtual migration environment (VME) is to check your Microsoft Office Project Server 2003 data for reserved custom field, lookup table, and outline code names that may cause the migration to fail. There are certain of these names that are reserved in both Microsoft Office Project Server 2007 and Microsoft Project Server 2010. Verify that your Project Server 2003 data does not have custom field, lookup table, or outline code names that conflict with the names reserved for Office Project Server 2007 and Project Server 2010. If any of these names are used in the current Project Server 2003 database, the names must be changed before you continue with the migration.

You have to correct the Project Server 2003 database through Microsoft Office Project Professional 2003 in your Project Server 2003 environment. After making corrections, make a backup copy of the Project Server 2003 database, and use the procedures in Load data to the Project Server VME to restore the updated database to the VME virtual machine.

For more information about the Project Server VME, see Overview of the VME for Project Server 2010.

Reserved outline code/lookup table names

Outline code name | Type | Office Project Server 2007 | Project Server 2010
Cost Type | Resource | X | X
Health | Task | X | X
State | Project | X | X
Team Name | Resource | X | X
Department |  |  | X
Flag Status |  |  | X

Reserved custom field names

Custom field name | Type | Office Project Server 2007 | Project Server 2010
Cost Type | Resource | X | X
Health | Task | X | X
State | Project | X | X
Team Name | Resource | X | X
Sample Approved Finish Date | Project |  | X
Sample Approved Start Data | Project |  | X
Sample Areas Impacted | Project |  | X
Sample Assumptions | Project |  | X
Sample Business Need | Project |  | X
Sample Compliance Proposal | Project |  | X
Flag Status | Task |  | X
Sample Goals | Project |  | X
Sample Post-Implementation Review Date | Project |  | X
Sample Post-Implementation Review Notes | Project |  | X
Sample Primary Objectives | Project |  | X
Project Departments | Project |  | X
Project Impact | Project |  | X
Sample Proposal Cost | Project |  | X
Sample Proposed Finish Date | Project |  | X
Sample Proposed Start Date | Project |  | X
Relative Importance | Project |  | X
Resource Departments | Resource |  | X


Disable Dynamic Content Compression in IIS Manager

Published: June 10, 2010

The second pre-migration task that you have to do in the Project Server virtual migration environment (VME) is to disable Dynamic Content Compression in Internet Information Services (IIS) Manager. By default, Dynamic Content Compression is turned on in Windows Server 2008 R2, which is the server operating system on which the Project Server VME is running. Having Dynamic Content Compression enabled can cause issues if you have to make corrective changes to your Microsoft Office Project Server 2007 data in the VME. (Specifically, it may cause issues with editing custom fields and resources).

For more information about other pre-migration tasks required for the Project Server VME, see Project Server VME: Pre-migration phase. For more information about the Project Server VME, see Overview of the VME for Project Server 2010.

To disable Dynamic Content Compression

  1. On the Project Server VME, click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  2. In Internet Information Services (IIS) Manager, in the Connection pane, select VME (VME\Administrator).

  3. In the VME Home pane, in the IIS section, click Compression.

  4. In the Compression section, clear the Enable dynamic content compression check box to disable this feature.

  5. In the Actions pane, click Apply to save the change. The alert The changes have been successfully saved appears if the change is applied successfully.

  6. Close Internet Information Services (IIS) Manager.

Note:

For more information about Dynamic Content Compression in Windows Server 2008 R2, see Internet Information Services (IIS) 7.5.


Project Server VME: Run pre-migration scripts (optional)

Published: May 15, 2010

After checking for reserved custom field, lookup table, and outline code names in your Microsoft Office Project Server 2003 data in the Project Server Virtual Migration Environment (VME), you have the option to run the following migration scripts. The migration scripts are optional, but are highly recommended to help find issues that might prevent you from migrating your data correctly.

  • Run Migration Script 1 to check the Project Server 2003 data

  • Run Migration Script 2 to capture statistics about the data

  • Run Migration Script 3 to capture a Project Server 2003 data snapshot

  • Run Migration Script 4 to capture all Project Server 2003 projects with associated project workspaces

The Project Server virtual migration environment is a Microsoft Office Project Server 2007 virtual environment used to migrate Project Server 2003 data to Microsoft Project Server 2010. There is no direct migration path from Office Project Server 2007 to Project Server 2010. However, the Project Server VME can be used as a pass-through environment to upgrade your Project Server 2003 data to Office Project Server 2007 before upgrading the data to Project Server 2010. For more information about the Project Server virtual migration environment, see Migrate your Project Server 2003 data by using the VME. For more information about how to upgrade to Microsoft Project Server 2010, see Project Server 2010 upgrade overview.


Run Migration Script 1 to check the Project Server 2003 data

Published: May 15, 2010

Migration Script 1 is one of several migration scripts included in the Project Server virtual migration environment (VME) to assist in migrating Microsoft Office Project Server 2003 data. Running this script against the Project Server 2003 database identifies possible errors that will prevent the migration process from completing successfully. This SQL Server script only reads from your Project Server 2003 database. (it will not write to the Project Server 2003 database.)

Warning:

This script is one of several pre-migration scripts included in the Project Server virtual migration environment (VME). Running the scripts is optional, but highly recommended for helping to detect issues that may prevent a successful migration of your data. For more information about the pre-migration scripts that are available, see Project Server VME: Run pre-migration scripts (optional).

This script identifies the following problems:

  • Version of Project Server 2003 database (which must be SP3 before the migration)

  • Projects are checked out

  • Projects have been externally edited

  • Projects have status updates pending

  • Duplicate enterprise resources exist

  • Duplicate enterprise resources exist in projects

  • Enterprise Global template have been externally edited

  • Enterprise Global template is checked out

  • Enterprise Global template is locked

  • Default language is different between the Project tables and the Web tables

  • Resource has a comma in its name

  • Required enterprise resource custom fields have no values

  • Required enterprise resource custom fields have values which are not in the lookup table definition

  • Enterprise resources have been externally edited

  • Enterprise resource duration custom fields have value lists

  • Enterprise resource duration custom fields have invalid values

To run Script 1

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project Server 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 databases, open Migrate_Proj_2003_Split_DB.

  3. Open the Verification Scripts folder, and then click VME Script 1.sql. This opens SQL Server Management Studio and displays Script 1.

  4. Click Execute to run the script.

  5. Check the results of the script. Take corrective action as necessary.

Note:

For additional information about Project Server 2003 data validation steps and corrective actions, see Fix data issues identified in pre-migration script A1 (Project Server 2010).

You have to make corrections to the Project Server 2003 database through Microsoft Office Project Professional 2003 in your Project Server 2003 environment. After making corrections, make a backup copy of the Project Server 2003 database, and then use the procedures in Load data to the Project Server VME to restore the updated database to the VME virtual machine. You can then re-run Script 1 on the updated database to verify that all issues have been fixed.

Script 1

Script 1 contains the following code:

Copy Code
------------------------------------------------------------------------------
/* Pre-Migration Steps from Project 2003 SP3 to Project 2007 SP2
-----------------------------------------------------------------------------*/
USE Project2003SourceDB

------------------------------------------------------------------------------
/* Check Project 2003 Version: Must be SP3 = 11.3
-----------------------------------------------------------------------------*/
select replace(str(WADMIN_VERSION_MAJOR)+'.'+str(WADMIN_VERSION_MINOR),' ','')
as 'Project Server Version SP3 Must Be 11.3 or Higher. If not, upgrade your 2003 database to SP3'
from dbo.MSP_WEB_ADMIN
go
------------------------------------------------------------------------------
/* Display the projects checked out?
-----------------------------------------------------------------------------*/
select PROJ_NAME AS 'List of Projects Checked-out: Must be Fixed'
from dbo.MSP_PROJECTS where PROJ_CHECKEDOUT = 1 and PROJ_TYPE in (0, 1)
go
------------------------------------------------------------------------------
/* Display the projects Externally Edited?
-----------------------------------------------------------------------------*/
select PROJ_NAME AS 'List of Projects Externally Edited: Must be Fixed'
from dbo.MSP_PROJECTS where (PROJ_EXT_EDITED = 1 or RESERVED_BINARY_DATA is null) and PROJ_TYPE in (0, 1)
go
------------------------------------------------------------------------------
/* Determining whether projects have status updates pending
-----------------------------------------------------------------------------*/
select distinct PROJ_NAME AS 'List of Projects with Status Updates Pending: Must be Fixed'
from dbo.MSP_WEB_ASSIGNMENTS wa, dbo.MSP_WEB_TRANSACTIONS trans,
dbo.MSP_WEB_PROJECTS wp where wa.WPROJ_ID = wp.WPROJ_ID
and trans.WASSN_ID = wa.WASSN_ID and trans.WTRANS_STATE in (0, 1, 2)
go
------------------------------------------------------------------------------
/* Determining whether there are duplicate Enterprise Resources
-----------------------------------------------------------------------------*/
select res_uid, res_name AS 'Duplicate Enterprise Resources: Must be Fixed' from msp_resources
where res_name in (select distinct r1.RES_NAME from dbo.MSP_RESOURCES r1
inner join dbo.MSP_RESOURCES r2 on (r1.RES_NAME = r2.RES_NAME and r1.PROJ_ID = r2.PROJ_ID)
where r1.PROJ_ID = 1
and r1.RES_UID != r2.RES_UID) and proj_id = 1 order by res_name asc

go
------------------------------------------------------------------------------
/* Determining whether there are duplicate Enterprise Resources
Check for duplicate enterprise resources used in your projects
-----------------------------------------------------------------------------*/
select  distinct res_name AS 'Duplicate Enterprise Resources Used in Projects: Must be Fixed', res_euid
from msp_resources
where res_name in (select distinct r1.RES_NAME from dbo.MSP_RESOURCES r1
inner join dbo.MSP_RESOURCES r2 on (r1.RES_NAME = r2.RES_NAME
and r1.PROJ_ID = r2.PROJ_ID) where r1.PROJ_ID = 1
and r1.RES_UID != r2.RES_UID) and proj_id <> 1 and res_euid is not null
order by res_name, res_euid asc
go

------------------------------------------------------------------------------
/* Enterprise Global template should not be externally edited
-----------------------------------------------------------------------------*/
select PROJ_NAME 'Enterprise Global Template Externally Edited: Must be Fixed' from dbo.MSP_PROJECTS
where (PROJ_EXT_EDITED = 1 or RESERVED_BINARY_DATA is null)
and PROJ_TYPE = 2

go
------------------------------------------------------------------------------
/* Determining whether the Enterprise Global template is checked out
-----------------------------------------------------------------------------*/
select count(*) AS 'Enterprise Global Template Checked Out: Must be Fixed' from dbo.MSP_PROJECTS
where PROJ_CHECKEDOUT = 1 and PROJ_TYPE = 2

go
------------------------------------------------------------------------------
/* Determining whether the Enterprise Global template is locked
-----------------------------------------------------------------------------*/
select cast(isnull(PROJ_LOCKED, '0') as int) AS 'Enterprise Global Template Is Locked: Must be Fixed'
 from dbo.MSP_PROJECTS where PROJ_TYPE = 2

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether the default language on the Web tables database and Project tables database should match
--------------------------------------------------------------------------------------------------------------*/
select WADMIN_DEFAULT_LANGUAGE As 'The Deafault Language on Web and Project Tables should Match: Must be Fixed'
from dbo.MSP_WEB_ADMIN

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether a resource has a comma in its name
--------------------------------------------------------------------------------------------------------------*/
select RES_NAME 'List of Resources With a Comma in the Name: Not Allowed: Must be Fixed'
from MSP_RESOURCES where RES_NAME is not null and charindex(',', RES_NAME) > 0

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether required enterprise resource custom fields do not have values
--------------------------------------------------------------------------------------------------------------*/
declare @eglobal_proj_id int
set @eglobal_proj_id = (select PROJ_ID from dbo.MSP_PROJECTS where PROJ_TYPE = 2)

select
   r1.RES_NAME as 'Resource Name',
   ast1.AS_VALUE as 'Custom Field Name with NO VALUE: Must be Fixed'
from
   dbo.MSP_RESOURCES r1
   inner join dbo.MSP_CODE_FIELDS cf1 on (r1.RES_UID = cf1.CODE_REF_UID)
   inner join dbo.MSP_FIELD_ATTRIBUTES fa1 on (cf1.CODE_FIELD_ID = fa1.ATTRIB_FIELD_ID)
   inner join dbo.MSP_ATTRIBUTE_STRINGS ast1 on (fa1.AS_ID = ast1.AS_ID)
   inner join dbo.MSP_OUTLINE_CODES oc3 on (cf1.CODE_UID = oc3.CODE_UID
   and oc3.PROJ_ID = @eglobal_proj_id)
   left join dbo.MSP_OUTLINE_CODES oc1 on (oc1.CODE_UID = cf1.CODE_UID
   and cf1.CODE_FIELD_ID = oc1.OC_FIELD_ID and oc1.PROJ_ID = @eglobal_proj_id)
   left join (
      select
         oc.CODE_UID,
         fa.ATTRIB_FIELD_ID as OC_FIELD_ID,
         @eglobal_proj_id as PROJ_ID
      from
         dbo.MSP_OUTLINE_CODES oc
         inner join dbo.MSP_FIELD_ATTRIBUTES fa on (fa.PROJ_ID = oc.PROJ_ID
         and fa.ATTRIB_VALUE = oc.OC_FIELD_ID and fa.ATTRIB_ID = 212)
      where
         oc.PROJ_ID = @eglobal_proj_id
         and fa.PROJ_ID = @eglobal_proj_id
         and fa.ATTRIB_ID = 212
   ) as oc2 on (oc2.CODE_UID = cf1.CODE_UID and cf1.CODE_FIELD_ID = oc2.OC_FIELD_ID
   and oc2.PROJ_ID = @eglobal_proj_id)
where
   r1.PROJ_ID = 1
   and cf1.proj_id = 1
   and fa1.PROJ_ID = @eglobal_proj_id
   and fa1.ATTRIB_ID = 206
   and ast1.PROJ_ID = @eglobal_proj_id
   and oc3.PROJ_ID = @eglobal_proj_id
   and oc1.CODE_UID is null
   and oc2.CODE_UID is null
order by
   r1.RES_NAME,
   ast1.AS_VALUE

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether a resource custom field has a value which is not in the lookup table definition
--------------------------------------------------------------------------------------------------------------*/
declare @eglobal_proj_id int
set @eglobal_proj_id = (select PROJ_ID from dbo.MSP_PROJECTS where PROJ_TYPE = 2)

select
   r1.RES_NAME AS 'Resource Name',
   ast1.AS_VALUE AS 'Custom Field Name with Invalid Value: Must be Fixed'
from
   dbo.MSP_RESOURCES r1
   inner join dbo.MSP_CODE_FIELDS cf1 on (r1.RES_UID = cf1.CODE_REF_UID)
   inner join dbo.MSP_FIELD_ATTRIBUTES fa1 on (cf1.CODE_FIELD_ID = fa1.ATTRIB_FIELD_ID)
   inner join dbo.MSP_ATTRIBUTE_STRINGS ast1 on (fa1.AS_ID = ast1.AS_ID)
   left join dbo.MSP_OUTLINE_CODES oc1 on (oc1.CODE_UID = cf1.CODE_UID
   and cf1.CODE_FIELD_ID = oc1.OC_FIELD_ID and oc1.PROJ_ID = @eglobal_proj_id)
   left join (
      select
         oc.CODE_UID,
         fa.ATTRIB_FIELD_ID as OC_FIELD_ID,
         @eglobal_proj_id as PROJ_ID
      from
         dbo.MSP_OUTLINE_CODES oc
         inner join dbo.MSP_FIELD_ATTRIBUTES fa on (fa.PROJ_ID = oc.PROJ_ID
         and fa.ATTRIB_VALUE = oc.OC_FIELD_ID and fa.ATTRIB_ID = 212)
      where
         oc.PROJ_ID = @eglobal_proj_id
         and fa.PROJ_ID = @eglobal_proj_id
         and fa.ATTRIB_ID = 212
   ) as oc2 on (oc2.CODE_UID = cf1.CODE_UID and cf1.CODE_FIELD_ID = oc2.OC_FIELD_ID
   and oc2.PROJ_ID = @eglobal_proj_id)
where
   r1.PROJ_ID = 1
   and cf1.proj_id = 1
   and cf1.code_uid is not null
   and fa1.PROJ_ID = @eglobal_proj_id
   and fa1.ATTRIB_ID = 206
   and ast1.PROJ_ID = @eglobal_proj_id
   and oc1.CODE_UID is null
   and oc2.CODE_UID is null
union
select
   r1.RES_NAME,
   ast1.AS_VALUE
from
   dbo.MSP_RESOURCES r1
   inner join dbo.MSP_MV_FIELDS cf1 on (r1.RES_UID = cf1.CODE_REF_UID)
   inner join dbo.MSP_FIELD_ATTRIBUTES fa1 on (cf1.CODE_FIELD_ID = fa1.ATTRIB_FIELD_ID)
   inner join dbo.MSP_ATTRIBUTE_STRINGS ast1 on (fa1.AS_ID = ast1.AS_ID)
   left join dbo.MSP_OUTLINE_CODES oc1 on (oc1.CODE_UID = cf1.CODE_UID
   and (cf1.CODE_FIELD_ID - 76) = oc1.OC_FIELD_ID and oc1.PROJ_ID = @eglobal_proj_id)
   left join (
      select
         oc.CODE_UID,
         fa.ATTRIB_FIELD_ID as OC_FIELD_ID,
         @eglobal_proj_id as PROJ_ID
      from
         dbo.MSP_OUTLINE_CODES oc
         inner join dbo.MSP_FIELD_ATTRIBUTES fa on (fa.PROJ_ID = oc.PROJ_ID
         and fa.ATTRIB_VALUE = oc.OC_FIELD_ID and fa.ATTRIB_ID = 212)
      where
         oc.PROJ_ID = @eglobal_proj_id
         and fa.PROJ_ID = @eglobal_proj_id
         and fa.ATTRIB_ID = 212
   ) as oc2 on (oc2.CODE_UID = cf1.CODE_UID and (cf1.CODE_FIELD_ID - 76) = oc2.OC_FIELD_ID
   and oc2.PROJ_ID = @eglobal_proj_id)
where
   r1.PROJ_ID = 1
   and cf1.proj_id = 1
   and cf1.code_uid is not null
   and fa1.PROJ_ID = @eglobal_proj_id
   and fa1.ATTRIB_ID = 206
   and ast1.PROJ_ID = @eglobal_proj_id
   and oc1.CODE_UID is null
   and oc2.CODE_UID is null
order by
   r1.RES_NAME,
   ast1.AS_VALUE

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether Enterprise resources are externally edited
--------------------------------------------------------------------------------------------------------------*/
select count(*) AS 'Number of Enterprise Resources Externally Edited: Must be Fixed'
from dbo.MSP_RESOURCES
where PROJ_ID = 1 and  cast(EXT_EDIT_REF_DATA as varchar(1)) = '1'

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether There are Enterprise Resource Duration Custom Fields with Value Lists
--------------------------------------------------------------------------------------------------------------*/
declare @proj_id int
set @proj_id = (select proj_id from msp_projects where proj_type = 2)
select ats.as_value as 'Enterprise Resource Duration Custom Field with Value Lists: Must be Fixed'
from msp_attribute_strings ats
inner join msp_field_attributes fa on (fa.proj_id = ats.proj_id and fa.as_id = ats.as_id)
where fa.attrib_id = 206 and fa.proj_id = @proj_id
and fa.attrib_field_id >= 205521382 and fa.attrib_field_id <= 205521391
and exists (select * from msp_field_attributes fa2
where fa2.proj_id = fa.proj_id and fa2.attrib_field_id = fa.attrib_field_id
and fa2.attrib_id = 210)

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether Enterprise Resource Duration custom fields contain valid values
--------------------------------------------------------------------------------------------------------------*/
select r.res_name AS 'Resource Name'
, mas.as_value AS 'Enterprise Resource Duration Custom Field with Invalid Value: Must be Fixed'
 from msp_resources r
inner join msp_duration_fields df on (df.dur_ref_uid = r.res_euid and df.proj_id = r.proj_id)
inner join msp_projects p on (p.proj_type = 2)
inner join msp_field_attributes fa on (fa.proj_id = p.proj_id and fa.attrib_field_id = df.dur_field_id)
inner join msp_attribute_strings mas on (mas.proj_id = p.proj_id and fa.as_id = mas.as_id)
where (dur_value < 0 or dur_value > 34689600) and df.proj_id = 1 and p.proj_type = 2
and fa.attrib_id = 206

go


Run Migration Script 2 to capture statistics about the data

Published: May 15, 2010

Migration Script 2 is one of several migration scripts included in the Project Server virtual migration environment (VME) to assist in migrating your Microsoft Office Project Server 2003 data. Run Script 2 to capture statistics about the project data contained in your Project Server 2003 database that you plan to migrate.

Warning:

This script is one of several pre-migration scripts included in the Microsoft Office Project Server 2003 virtual migration environment (VME). Running the scripts is optional, but highly recommended for helping to detect issues that may prevent a successful migration of your data. For more information about the pre-migration scripts that are available, see Project Server VME: Run pre-migration scripts (optional).

This script's output provides information about the following:

  • Size of the databases (the Project Tables and Web Tables databases)

  • Number of projects

  • Number of inserted projects

  • Number of cross-project links

  • Number of tasks

  • Number of assignments

  • Number of Enterprise resources

  • Number of custom fields in use

  • Number of Project-authenticated users

  • Number of Windows-authenticated users

  • Number of security groups

  • Number of security categories

  • Whether there is Windows SharePoint Services integration

  • Number of linked issues

  • Number of linked risks

  • Number of linked documents

  • Number of custom Office Project Web Access views

This script's output provides information about the Project Server 2003 data that you are migrating. You can make a general estimate of how long the migration process will take from some of this data. Generally, the migration process will take about 30 seconds to one minute for each project that you are migrating, varying by a number of factors, such as number of assignments, tasks, computer speed, and so on. Therefore, if your Project Server 2003 database contained 600 projects, it would take about 10 hours to migrate, based on the one minute per project estimate.

To run Script 2

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project Server 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 databases, open Migrate_Proj_2003_Split_DB.

  3. Open the Verification Scripts folder, and then click VME Script 2.sql. This opens SQL Server Management Studio and displays Script 2.

  4. Click Execute to run the script.

  5. Check the results of the script for information about your data.

Script 2

Script 2 contains the following code:

Copy Code
/*-----------------------------------------------------------------------------------------------------------
Script A2: Project Server 2003 Database Profile
This script reads the Project Server 2003 database (Project Tables and View Tables may be in the same or separate database)
-------------------------------------------------------------------------------------------------------------*/
use <Enter "Project Tables" database name>

--Total size of DB
exec sp_spaceused

--Number of projects in the database
select count(*) as 'Total Number of Projects in 2003' from msp_projects

--Number of inserted projects
select count(*) as 'Number of Inserted Projects in 2003'
  from MSP_TEXT_FIELDS where TEXT_FIELD_ID = 188743706

--Number of cross-project links
select count(*) as 'Number of cross-project links in 2003'
  from MSP_TEXT_FIELDS
  where TEXT_FIELD_ID = 239075346 or TEXT_FIELD_ID = 239075347

--Number of total tasks, assignments in the system
select count(*) as 'Number of tasks in 2003' from msp_tasks
select count(*) as 'Number of assignments in 2003' from msp_assignments

--Number of Enterprise resources (in ResGlobal)
select count(*) as 'Number of Enterprise Resources in 2003'
  from msp_resources where proj_id = 1 and res_name is not null

--Number of custom fields in use
select count(*) as 'Number of Custom Fields in use in 2003'
  from msp_field_attributes
  where attrib_id = 206 and proj_id in (select proj_id
  from msp_projects where proj_type =2 )

/*-----------------------------------------------------------------------------------------------------------
This script reads the Project Server 2003 database (Project Tables and View Tables may be in the same or separate database)
-------------------------------------------------------------------------------------------------------------*/

use <Enter "Web Tables" database name>

--Total size of DB
exec sp_spaceused

--Number of Project Authenticated users, Windows authenticated users
select count(*) as 'Number of Project Authenticated users in 2003'
  from MSP_WEB_RESOURCES
  where WRES_USE_NT_LOGON = 0
  and WRES_CAN_LOGIN <>0 and WRES_COUNT_LICENSE <> 0
select count(*) as 'Number of Windows Authenticated users in 2003'
  from MSP_WEB_RESOURCES
  where WRES_USE_NT_LOGON <> 0
  and WRES_CAN_LOGIN <>0 and WRES_COUNT_LICENSE <> 0

--Number of security groups,security categories
select count(*) as 'Number of Security Groups in 2003'
  from MSP_WEB_SECURITY_GROUPS
select count(*) as 'Number of Security Categories in 2003'
  from MSP_WEB_SECURITY_CATEGORIES

--Is there any Windows SharePoint Services integration ?
select count(*)  as 'Is there any Windows SharePoint Services Integration in 2003?'
  from msp_web_admin where WADMIN_CURRENT_STS_SERVER_ID <> -1

--Number of linked issues, risks, documents
-- (indicates how much Windows SharePoint Services integration is used)
select count(*) as
  'Number of linked Windows SharePoint Services issues/risks/documents in 2003'
  from MSP_WEB_OBJECT_LINKS

--Number of custom Project Web Access views
select count(*) as 'Number of customer Projet Web Access views in 2003'
  from MSP_WEB_VIEW_REPORTS where WVIEW_ID > 100


Run Migration Script 3 to capture a Project Server 2003 data snapshot

Published: May 15, 2010

Migration Script 3 is one of several migration scripts included in the Microsoft Office Project Server 2003 virtual migration environment (VME) to assist in migrating your Microsoft Office Project Server 2003 data. Run Script 3 to take a data snapshot of the Project Server 2003 database that you plan to migrate. The script takes a data snapshot of the Projects and Tasks tables and then stores the information in a table created dynamically within the script. The stored results from this script can be compared later to a post-migration data snapshot to verify whether all data has migrated successfully.

Warning:

This script is one of several pre-migration scripts included in the Microsoft Office Project Server 2003 virtual migration environment (VME). Running the scripts is optional, but highly recommended for helping to detect issues that may prevent a successful migration of your data. For more information about the pre-migration scripts that are available, see Project Server VME: Run pre-migration scripts (optional).

Important:

This script requires a blank database to which results are saved. Prior to running this script, have your SQL Server database administrator create a blank database named "ProjectServer_Migration_Data_Validation". Verify that the database is named correctly to ensure that the script will be able to use it.

To run Script 3

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project Server 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 databases, open Migrate_Proj_2003_Split_DB.

  3. Open the Verification Scripts folder, and then click VME Script 3.sql. This opens Microsoft Office Project Server 2003 and displays Script 3.

  4. Click Execute to run the script.

  5. The results from the script are saved to the ProjectServer_Migration_Data_Validation database in the table named dbo.Migration_PS2003_Data_Validation_Snapshot.

Script 3

Script 3 contains the following code:

Copy Code
/*---------------------------------------------------------------------------------------
-- Script A3: Capture Data Validation Snapshot for Project Server 2003 ---- Updated Jan 12, 2010
-- This script:
-- 1. drops the PS2003 Validation Snapshot table if it exists from the Migration Validation
      Database previously created
   2. Reads the Project Server 2003 SP2a database to extract Projects and Tasks information
   3. Stores the output dataset into a new table created in the Migration Validation
      Database
   This script requires to set the database names of the Migration Validation Database and the
   Project Server 2003 database in the USE statements
 ----------------------------------------------------------------------------------------------*/
USE ProjectServer_Migration_Data_Validation
IF EXISTS (SELECT id FROM dbo.sysobjects WHERE id = OBJECT_ID(N'MIgration_PS2003_Data_Validation_Snapshot')
AND OBJECTPROPERTY(id, N'IsUserTable') = 1)
DROP TABLE dbo.Migration_PS2003_Data_Validation_Snapshot
GO
USE [Project2003SourceDB]
GO
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO
SELECT p11p.proj_name as N'Project Name',
        p11p.proj_id as 'Project ID',
        p11p.proj_version as N'Project Version',
        p11p.proj_info_start_date as N'Proj Start Date',
        p11p.proj_info_finish_date as N'Proj Finish Date',
        p11p.proj_info_status_date as N'Proj Status Date',
        p11p.proj_info_cal_name as N'Proj Calendar Name',
        p11p.proj_type as N'Proj Type',
        p11t.task_name as N'Task Name',
        p11t.task_uid as N'Task UID',
        p11t.task_type as N'Task Type',
        p11t.task_start_date as N'Task Start Date',
        p11t.task_finish_date as N'Task Finish Date',
        p11t.task_act_start as N'Task Act Start',
        p11t.task_act_finish as N'Task Act Finish',
        p11t.task_constraint_date as N'Task Constraint Date',
        p11t.task_deadline as N'Task Deadline',
        p11t.task_work as N'Task Work',
        p11t.task_act_work as N'Task Actual Work',
        p11t.task_rem_work as N'Task Rem Work',
        p11t.task_ovt_work as N'Task Ovt Work',
        p11t.task_act_ovt_work as N'Task Actual Ovt Work',
        p11t.task_rem_ovt_work as N'Task Rem Ovt Work',
        p11t.task_pct_comp as N'Task %Complete',
        p11t.task_pct_work_comp as N'Task %Work Complete',
        p11t.task_phy_pct_comp as N'Task % Phys Work Complete',
        p11t.task_dur as N'Task Duration',
        p11t.task_rem_dur as N'Task Rem Duration',
        p11t.task_act_dur as N'Task Actual Duration',
        p11t.task_is_milestone as N'Task Milestone',
        p11t.task_cost as N'Task Cost',
        p11t.task_fixed_cost as N'Task Fixed Cost',
        p11t.task_act_cost as N'Task Actual Cost',
        p11t.task_rem_cost as N'Task Rem Cost',
        p11t.task_ovt_cost as N'Task Ovt Cost',
        p11t.task_act_ovt_cost as N'Task Actual Ovt Cost',
        p11t.task_rem_ovt_cost as N'Task Rem Ovt Cost'
INTO ProjectServer_Migration_Data_Validation.dbo.Migration_PS2003_Data_Validation_Snapshot

FROM msp_projects AS p11p,
msp_tasks AS p11t
WHERE (p11p.proj_id = p11t.proj_id)

ORDER BY 1,5


Run Migration Script 4 to capture all Project Server 2003 projects with associated project workspaces

Published: May 15, 2010

Migration Script 4 is one of several migration scripts included in the Project Server virtual migration environment (VME) to assist in migrating your Microsoft Office Project Server 2003 data. Run Script 4 to take a data snapshot of the Project Server 2003 database from the Project table and then store the data in a table created dynamically within the script. Script 4 lists all projects in the Project Server 2003 database that have an associated project workspace site. This data is saved to a table in the ProjectServer_Migration_Data_Validation database and can be compared to post-migration results to verify whether all Project Server 2003 projects with associated workspaces have been migrated and relinked.

Warning:

This script is one of several pre-migration scripts included in the Project Server virtual migration environment (VME). Running the scripts is optional, but highly recommended for helping to detect issues that may prevent a successful migration of your data. For more information about the pre-migration scripts that are available, see Project Server VME: Run pre-migration scripts (optional).

To run Script 4

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project Server 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 databases, open Migrate_Proj_2003_Split_DB.

  3. Open the Verification Scripts folder, and then click VME Script 4.sql. This opens SQL Server Management Studio and displays Script 4.

  4. Click Execute to run the script.

  5. The results from the script are saved to the ProjectServer_Migration_Data_Validation database in the table named dbo.Migration_PS2003_ProjectWorkspaces.

Script 4

Script 4 contains the following code:

Copy Code
/*------------------------------------------------------------------------
-- Script A4: Capture WSS2 Project Workspaces Data Snapshot
-- List all Projects 2003 with Associated WSS workspace sites
-- Updated the USE statement to point to the Project Server 2003 database
--------------------------------------------------------------------------*/
USE ProjectServer_Migration_Data_Validation
IF EXISTS (SELECT id FROM dbo.sysobjects WHERE id = OBJECT_ID(N'Migration_PS2003_ProjectWorkspaces')
AND OBJECTPROPERTY(id, N'IsUserTable') = 1)
DROP TABLE dbo.Migration_PS2003_ProjectWorkspaces
GO
USE ProjectServer_2003

SELECT [PROJ_NAME]
,[WPROJ_ID]
      ,[WPROJ_STS_SUBWEB_NAME]
      ,[WPROJ_ISSUE_LIST_NAME]
      ,[WPROJ_RISK_LIST_NAME]
      INTO ProjectServer_Migration_Data_Validation.dbo.Migration_PS2003_ProjectWorkspaces
   FROM [MSP_WEB_PROJECTS] P, dbo.MSP_WEB_STS_SERVERS W
  where [WPROJ_STS_SUBWEB_NAME] IS NOT NULL
  and p.[WSTS_SERVER_ID] = w.[WSTS_SERVER_ID]


Project Server VME: Migration phase

Published: May 15, 2010

This chapter describes the tasks required during the migration phase when you are using the Project Server virtual migration environment (VME) to migrate your Microsoft Office Project Server 2003 data to Microsoft Office Project Server 2007. Run these tasks after you have completed the tasks listed in Project Server VME: Pre-migration phase.

In this chapter:

  • Project Server VME: Run verification

  • Project Server VME: Migrate the Enterprise Global data

  • Project Server VME: Migrate the Project Server 2003 project data

  • Project Server VME: Attach the Windows SharePoint Services 2.0 content database to the farm (optional)

  • Project Server VME: Relink project workspace sites (optional)

Note:

The last two items in the list are optional migration steps. They are only necessary if you plan to migrate your Project Server 2003 project workspace data.

After completing the tasks required in the migration phase, see Project Server VME: Post-migration phase.

The Project Server virtual migration environment is a Office Project Server 2007 virtual environment used to migrate Project Server 2003 data to Microsoft Project Server 2010. There is no direct migration path from Office Project Server 2007 to Project Server 2010. However, the Project Server VME can be used as a pass-through environment to upgrade your Project Server 2003 data to Office Project Server 2007 before upgrading the data to Project Server 2010. For more information about the Project Server virtual migration environment (VME) see Migrate your Project Server 2003 data by using the VME. For more information about how to upgrade to Microsoft Project Server 2010, see Project Server 2010 upgrade overview.


Project Server VME: Run verification

Published: May 15, 2010

The first thing you must do in the Project Server virtual migration environment (VME) migration phase is to run the migration verification check on your Microsoft Office Project Server 2003 data. The verification process runs a minimum of data validation checks and writes this information to the migration log file. It specifically checks for the following conditions in your data, which would cause your migration to fail:

  • There are projects that are checked out

  • There are projects that have been modified externally

  • There are projects with pending status updates

  • There are duplicate enterprise resources

The Run Verification step is the first step in the VME migration phase. For additional steps, see Project Server VME: Migration phase.

Run migration verification

When you run the migration verification, a status screen will display the progress. If no potential problems are found, the status screen will end with "Project Migration Successful". If your migration fails, check the migration log for more information about the error. The migration log file and its location will be displayed in the first few lines of the status screen. Note that the migration verification process will not write to or fix issues in the Microsoft Office Project Server 2007 database.

Note:

For additional information about Project Server 2003 data validation steps and corrective actions, see Fix data issues identified in pre-migration script A1 (Project Server 2010).

To run migration verification

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project Server 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 databases, open Migrate_Proj_2003_Split_DB.

  3. Click 1-Run Verification to start the migration tool. This command opens a Command Prompt window that displays the status of the verification checks as they occur.

  4. When the verification checks complete successfully, the End Summary displays Project Migration successful.

If you encounter an error, check the migration log file for more information about the problem. The specific migration log file for your migration is displayed in the first few lines (for example, "Using log file: E:\MigrationLogs\Batch1-20100503-1704.log"). You can view the log in a text editor such as Notepad.

Important:

Although this "Run Verification" step makes several key data validation checks on your Project Server 2003 data, we recommend that you also run SQL Script 1. Script 1 looks for many additional data validation errors that could cause your migration to fail.


Project Server VME: Migrate the Enterprise Global data

Published: May 15, 2010

After running the migration verification in the Project Server virtual migration environment (VME), you must migrate the Microsoft Office Project Server 2003 Enterprise Global data to Microsoft Office Project Server 2007 before you migrate the project data. The virtual migration environment uses the migration tool and calls on a pre-configured configuration file to migrate the Enterprise Global data. The VME automates this process for you.

Single database migration uses the P12SingleMigrationEG.ini configuration file when you run the migration tool to migrate your Enterprise Global file. Split database migration uses P12SplitMigrationEG.ini.

Note:

If you need to change the default settings in the migration configuration file, see Configure the migration tool (Project Server).

Migrating your Enterprise Global data is the second step in the VME migration phase. For additional steps, see Project Server VME: Migration phase.

To migrate your Enterprise Global data

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project Server 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 database, open Migrate_Proj_2003_Split_DB.

  3. Click 2-Run EntGlobal-ResPool Migation to start the migration tool. This opens a Command Prompt window that displays the status of the Enterprise Global data migration as it occurs.

  4. When the Enterprise Global migration is completed successfully, the End Summary displays Project Migration successful.

If you encounter an error, check the migration log file for more information about the problem. The specific migration log file for this migration is displayed in the first few lines (for example, "Using log file: E:\MigrationLogs\Batch1-20100503-1704.log"). You can view the log in a text editor such as Notepad.


Project Server VME: Migrate the Project Server 2003 project data

Published: May 15, 2010

After you have migrated the Microsoft Office Project Server 2003 Enterprise Global data to Microsoft Office Project Server 2007, you are ready to migrate your Project Server 2003 project data. For project data migration, the virtual migration environment (VME) again uses the migration tool and calls on a different configuration file specifically set to migrate only your project data. The VME automates this process for you.

Single database migration uses the P12SingleMigration.ini configuration file when you run the migration tool to migrate the project data. Split database migration uses P12SplitMigration.ini.

Note:

If you need to change the default settings in the migration configuration file, see Configure the migration tool (Project Server).

Migrating project data is the third step in the VME migration phase. For additional steps, see Project Server VME: Migration phase.

To run migration verification

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project Server 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 database, open Migrate_Proj_2003_Split_DB.

  3. Click 3-Migrate Projects to start the migration tool. This opens a Command Prompt window that displays the status of the project data migration as it occurs.

  4. When the project data migration is completed successfully, the End Summary displays Project Migration successful.

If you encounter an error, check the migration log file for more information about the problem. The specific migration log file for this migration is displayed in the first few lines (for example, "Using log file: E:\MigrationLogs\Batch1-20100503-1704.log"). You can view the log in a text editor such as Notepad.


Project Server VME: Attach the Windows SharePoint Services 2.0 content database to the farm

Published: May 15, 2010

Important:

This step is optional and is only required if you are migrating Microsoft Office Project Server 2003 project workspace data.

Use the following procedure to attach the copy of the Windows SharePoint Services 2.0 content database to the Microsoft Office Project Server 2007 farm in the VME. Perform this procedure after you have restored the content database containing your project workspace data to the Project Server virtual migration environment (VME) virtual machine in Microsoft SQL Server 2005. Once attached, the project workspaces are migrated to Windows SharePoint Services 3.0.

Attaching your Windows SharePoint Services 2.0 content database to the farm in the VME is a step in the VME migration phase. For additional steps, see Project Server VME: Migration phase.

To attach the Windows SharePoint Services 2.0 content database to the VME farm

  1. Open a Command Prompt window and navigate to the location of Stsadm.exe. (The default location is <Drive>:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin.)

  2. Run the following Stsadm command to attach a copy of your Windows SharePoint Services 2.0 content database to Windows SharePoint Services 3.0 and upgrade it.

    stsadm.exe -o addcontentdb -url http://<server>:<port> -databasename <WSS v2.0 content database> -databaseserver <DB Server name>

    For example:

    stsadm.exe -o addcontentdb -url http://VME -databasename YourContentDBName databaseserver VME

  3. After running Stsadm.exe, you can track the progress of the upgrade by looking at upgrade.log in the ULS log directory. (The default location is C:\program files\common files\Microsoft shared\Web server extensions\12\logs\upgrade.log.) Upgrade has finished on a given content database when the following line is included in the log:

    [SPManager] [DEBUG] [<Date> <Time>]: Using cached [SPContentDatabase Name=<DB NAME> Parent=SPDatabaseServiceInstance] NeedsUpgrade value: False.

  4. If the upgrade process fails for any reason (as indicated in the log), the Windows SharePoint Services upgrade process can be restarted. To restart the upgrade process, run the command Stsadm.exe -o upgrade and look at the logs to view the progress. Upgrade has finished when the command prompt returns Operation completed successfully.

Note:

For more information about how to migrate a content database to Windows SharePoint Services 3.0, see Attach databases and upgrade to SharePoint Foundation 2010.


Project Server VME: Relink project workspace sites

Published: May 15, 2010

Important:

This step is optional and is only required if you are migrating your Microsoft Office Project Server 2003 project workspace data.

After you attach the Windows SharePoint Services 2.0 content database to the farm to upgrade your project workspace sites to Windows SharePoint Services 3.0, you must relink the project workspace sites to their associated projects. You can do this by using the Project Workspace Site Relinker Tool, which is located on the root of drive E in the virtual migration environment (VME).

Relinking project workspace sites in the VME is a step in the VME migration phase. For additional steps, see Project Server VME: Migration phase.

Run the tool at a command prompt with the following syntax:

RelinkAllWSSSites WSSServerURL ProjectServerURL [Silent] [QuitOnError]

Option | Description
RelinkAllWSSSites | Calls the executable file.
WSSServerURL | The Windows SharePoint Services Web application that contains project workspaces. This is a required parameter and must be entered in the form http://<server>:<port>. Example: http://myWSSserver:80
ProjectServerURL | The Project Web Access URL that contains the reference to the project workspaces to which you are relinking. This is a required parameter and must be entered in the form http://<server>/pwa. Example: http://myProjectserver/pwa
Silent | (Optional.) Progress information for each project is not displayed.
QuitOnError | (Optional.) The application stops if an error is encountered.

For example:

RelinkAllWSSSites http://myWSSserver:80 http://myProjectserver/pwaSilent

You may be required run the Project Workspace Site Relinker tool multiple times to relink all the sites referenced within your Project Server instance. For example, you may have two Windows SharePoint Services Web applications (http://myWSSServer:80 and http://myWSSServer2:80) that contain project workspaces. In such a case you would run the tool twice — once for each Web application.

For more information about the tool, see Project Workspace Site Relinker Tool.


Project Server VME: Post-migration phase

Published: May 15, 2010

This chapter describes the post-migration tasks required when you are using the Project Server virtual migration environment (VME) to migrate your Microsoft Office Project Server 2003 data to Microsoft Office Project Server 2007. These tasks are performed after you have completed the tasks listed in the Project Server VME Project Server VME: Migration phase.

In this chapter:

  • Project Server VME: Do post-migration tasks

  • Project Server VME: Run post-migration scripts (optional)

After you complete the post-migration tasks, see Project Server VME: Plan to upgrade data to Project Server 2010 to migrate your Office Project Server 2007 data to Microsoft Project Server 2010.

The Project Server virtual migration environment is a Office Project Server 2007 virtual environment that is used to migrate Project Server 2003 data to Microsoft Project Server 2010. There is no direct migration path from Project Server 2003 to Project Server 2010. However, the Project Server VME can be used as a pass-through environment to upgrade your Project Server 2003 data to Office Project Server 2007 before upgrading the data to Project Server 2010. For more information about the Project Server virtual migration environment (VME), see Migrate your Project Server 2003 data by using the VME. For more information about how to upgrade to Microsoft Project Server 2010, see Project Server 2010 upgrade overview.


Project Server VME: Do post-migration tasks

Published: May 15, 2010

After you have finished migrating your data from Microsoft Office Project Server 2003 to Microsoft Office Project Server 2007 in the Project Server virtual migration environment (VME), there are subsequent tasks that have to be completed. If these post-migration tasks are not performed, the data may not upgrade correctly to Microsoft Project Server 2010. These tasks include the following:

  • Verify that the migration was successful

  • Update migrated server settings

  • Synchronize the migrated forms-authenticated users by using the Project Server 2007 forms-based authentication store

  • Verify the project workspace provisioning settings

  • Delete migrated inactive users (optional)

  • Fix project currency settings

  • Change local Windows accounts that were migrated

  • Update multi-language lookup tables

  • Address user and permission issues

  • Address authentication issues

  • Address master-project issues

For information about other things that are required in the post-migration phase, see Project Server VME: Post-migration phase.

For more information about the Project Server virtual migration environment (VME), see Migrate your Project Server 2003 data by using the VME.

Verify that the migration was successful

During each of the three instances that the migration tool was run in the Migration phase (verification, enterprise global data migration, project migration), verify from the migration tool command line display or from the migration logs that the migration was successful. If the migration tool failed at any point, view the contents of the migration log file for more information about the error. Make corrections, import the updated data to the VME, and then re-run the migration tool.

If there is an irrecoverable problem, restore the VME virtual machine image to the original configuration, import and restore your Project Server 2003 databases, and then retry migration. Hyper-V manager automatically takes a snapshot of the VME virtual machine when the image is first restored. You can reapply the snapshot (titled "As Shipped") to restore the VME to its original state.

If the migration process appears to have been successful, ensure that the data migrated correctly to Office Project Server 2007 by doing the following tests:

  • Verify project data: Open the migrated projects in Project Professional 2007, change them, add enterprise resources, publish them, accept status updates, and so on. The VME includes Microsoft Office Project Professional 2007.

  • Verify Project Web Access data: Open Office Project Web Access to connect to your data. Verify that you can fill timesheets, create proposals, and so on.

We highly recommend that you have a migration checklist specific to your needs and that you test those items after migration.

Update migrated server settings

Not all kinds of data can be migrated from Project Server 2003 to Office Project Server 2007. (See Data that cannot be migrated to Project Server 2007.) Therefore we recommend that you review all the Office Project Server 2007 server settings and make sure that they are as you want them to be. Some specific areas are listed here:

  • Security settings: There are some security permissions (global and category) that are new in Office Project Server 2007. These permissions may not get migrated. You may want to review each one and decide on whether to give users that permission. For more information, see Security and protection for Office Project Server 2007.

  • Project Web Access view definitions: The "Filter by" and "Group by" clauses are not migrated from Project Server 2003. You may have to re-create these clauses. Also, some Office Project Web Access view fields do not migrate. You may want to make sure that all the fields important to you are available in the migrated views.

  • Merge and rename similar security groups, categories, and templates and Project Web Access view definitions: If there is a naming conflict during migration that involves security templates, view definitions, or security groups or categories, the migration tool attaches a prefix or suffix to the conflicting names. This action is taken to preserve both Office Project Server 2007 entities and Project Server 2003 entities in one system. Then you can select which one to keep or else decide to merge them, as appropriate. We recommend that you resolve them so that end users do not become confused.

Synchronize the migrated forms-authenticated users by using the Project Server 2007 forms-based authentication store

This is a required step to make sure that the migrated forms-authenticated users work in Office Project Server 2007. For more information, see Configure SQL Membership Provider forms authentication for Project Server 2007.

Verify the project workspace provisioning settings

In Office Project Server 2007, the migration tool resets the Automatically Provision option in the Project Workspace Provisioning Settings page of Server Settings to Manually Create a workspace for each project. This setting ensures that the migration process does not provision duplicate workspaces for projects that may already have workspaces that are yet to be migrated.

After running the migration tool, check the Project Workspace Provisioning settings located in the Operational Policies section of Office Project Web Access Server Settings. Verify that the Site URL and the Automatic Provisioning options are configured correctly per your needs. In Office Project Server 2007, after the migration tool is run, you may want to reset the Automatically Provision option to Automatically create a workspace for the project when a project is published.

Delete migrated inactive users (optional)

By default, the Manage Groups page in Project Server 2003 does not display inactive users. But in Office Project Server 2007, by default, inactive users are displayed. Therefore, after the migration process (which migrates the inactive users also), you may see additional users in the Manage Groups Project Web Access page in Office Project Server 2007.

You can permanently delete the inactive users, if you need to.

To permanently delete the inactive users

  1. In Office Project Web Access, click Server Settings.

  2. In the Database Administration section, click Delete Enterprise Objects.

  3. On the Delete Enterprise Objects page, in the What do you want to delete from Project Server section, select Resources and Users.

  4. In the list of users that appears, select the users that you want to permanently delete, and then click Delete.

Fix project currency settings

It is a known issue that project currencies are not migrated correctly. Run the following query on the Project Server 2003 Project Tables database to get a list of projects and their currencies. This information can be used to manually correct the currency settings after migration.

select PROJ_NAME, PROJ_OPT_CURRENCY_SYMBOL from dbo.MSP_PROJECTS where PROJ_TYPE in (0, 1, 2)

Change local Windows accounts that were migrated

Local Windows accounts (for example, ComputerName\Brad Joseph), for computer names that are no longer valid should be removed. Go to Office Project Web Access Server Settings and use the Manage Users options to edit those accounts so that they are valid.

Update multi-language lookup tables

Multilanguage lookup tables are not updated correctly after migration. Run the following SQL statements on the Office Project Server 2007 Published database to resolve this problem.

Copy Code
DELETE FROM dbo.MSP_LOOKUP_TABLE_LANGUAGES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)
DELETE FROM dbo.MSP_LOOKUP_TABLE_MASK_VALUES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)
DELETE FROM dbo.MSP_LOOKUP_TABLE_MASK_STRUCTURES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)
DELETE FROM dbo.MSP_LOOKUP_TABLE_VALUES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)
DELETE FROM dbo.MSP_LOOKUP_TABLE_STRUCTURES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)
Note:

This script (Script 10) is included in the VME in the Verification Scripts folder. Note that this script takes corrective action on the Office Project Server 2007 data.

If you are using Microsoft Office Project Portfolio Server 2007 with Office Project Server 2007, it is especially important to run these SQL statements to update the tables. If the statements are not run, you may encounter a "GeneralUnhandledException" error when you perform an export from Office Project Portfolio Server 2007 to Office Project Server 2007. The error would resemble this and would appear in the ULS logs:

PSI: LookupTable.ReadLookupTablesMultiLang Undefined Attibutes: PSError: GeneralUnhandledException Underined attributes list: System.Data.ConstraintException: Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints….

Address user and permission issues

After migration (especially in localized builds), the users may not have certain expected permissions in the migrated Office Project Server 2007 installation. For example, imagine that you were assigned your permissions through the administrator template, but you cannot view timesheets. There are several reasons that such a situation might occur:

  1. In Project Server 2003, a permission is denied at the organization level. You can verify this by checking your Office Project Web Access permissions to see whether any are disabled and whether they are the cause of your problem. To check your Office Project Web Access permissions:

    1. In the Office Project Web Access home page, in the left pane, click Server Settings.

    2. In Server Settings, in the Security section, click Project Web Access Permissions.

  2. There are some permissions that are new in Office Project Server 2007. These permissions may not be mapped correctly during migration. You can check the Security documentation for a list of these permissions to determine whether they are the cause of your problem. For more information about Office Project Server 2007 permissions, see Security and protection for Office Project Server 2007.

  3. If a Project Server 2003 user or resource exists in Office Project Server 2007 (by name or Windows NT account), then that user or resource's security permissions are not migrated. For example, if you had done an Active Directory synchronization before migration (and if most of those users exist in Project Server 2003), those user permissions would not have been migrated. This problem should not be encountered in the VME, because the Office Project Server 2007 environment you are migrating to should not have any users in it before the migration process.

Address authentication issues

Project Server authentication is used in Project Server 2003, but it is not supported in Office Project Server 2007. When you migrate Project Server authenticated users to Office Project Server 2007, the user accounts are reset, because the forms-based authentication mechanism in Office Project Server 2007 is architecturally different from the Project Server authentication that is used in Project Server 2003. You do not see these users listed in the Office Project Web Access Server Settings Manage Users page, or the User Authentication section for the user does not appear. However, you can still edit these migrated users in the Project Web Access Resource Center.

Address master-project issues

When you migrate master projects and their associated subprojects from Project Server 2003 to Office Project Server 2007, the following two scenarios cause the project migration to fail:

  • A subproject that is migrated after its master project. (You can correct the order of migration in the migration configuration file.)

    Important:

    For more information about the migration configuration file, see Configure the migration tool (Project Server).

  • A project that is a subproject to two master projects. (Such an arrangement is allowed in Project Server 2003, but not in Office Project Server 2007). The migration for this project will fail when you attempt to publish the project.


Project Server VME: Run post-migration scripts (optional)

Published: May 15, 2010

After doing post-migration tasks to your migrated Microsoft Office Project Server 2007 data in the Project Server virtual migration environment (VME), you have the option to run the following migration scripts. The migration scripts are optional, but are highly recommended in helping to find issues that might prevent you from migrating your data properly.

  • Run Migration Script 5 to capture a post-migration Project Server 2007 data snapshot

  • Run Migration Script 6 to capture all Project Server 2007 projects with associated project workspaces

  • Run Migration Script 7 to compare Project Server 2003 and Project Server 2007 data validation snapshots

  • Run Migration Script 8 to list projects with unlinked workspaces

  • Run Migration Script 9 to test your Project Server 2007 data for known migration issues

  • Run Migration Script 10 to correct multilanguage lookup table upgrade issues

The Project Server virtual migration environment is a Office Project Server 2007 virtual environment used to migrate Project Server 2003 data to Microsoft Project Server 2010. There is no direct migration path from Office Project Server 2007 to Project Server 2010. However, the Project Server VME can be used as a pass-through environment to upgrade the Project Server 2003 data to Office Project Server 2007 before you upgrade the data to Project Server 2010. For more information about the Project Server virtual migration environment (VME), see Migrate your Project Server 2003 data by using the VME. For more information about upgrading to Microsoft Project Server 2010, see Project Server 2010 upgrade overview.


Run Migration Script 5 to capture a post-migration Project Server 2007 data snapshot

Published: May 15, 2010

Run Migration Script 5 to take a data snapshot of the Microsoft Office Project Server 2007 database that contains your migrated Microsoft Office Project Server 2003 data. The script takes a data snapshot of the Projects and Tasks tables and then stores the information in a table that is created dynamically within the script. The stored results from this script can be compared later to the results from the pre-migration snapshot taken of your Project Server 2003 data to verify whether all data has migrated successfully.

Warning:

This script is one of several post-migration scripts included in the Project Server virtual migration environment (VME). Running the scripts is optional, but highly recommended for helping to detect issues that may prevent a successful migration of your data. For more information about the post-migration scripts that are available, see Project Server VME: Run post-migration scripts (optional).

To run Script 5

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 databases, open Migrate_Proj_2003_Split_DB.

  3. Open the Verification Scripts folder, and then click VME Script 5.sql. This opens SQL Server Management Studio and displays Script 5.

  4. Click Execute to run the script.

  5. The results from the script are saved to the ProjectServer_Migration_Data_Validation database in the table named dbo.Migration_PS2007_Data_Validation_Snapshot.

Script 5

Script 5 contains the following code:

Copy Code
/*---------------------------------------------------------------------------------------
-- Script A5: Capture Data Validation Snapshot for Project Server 2007 after migration---- Updated Jan 10,2010
-- This script:
-- 1. drops the PS2007 Validation Snapshot table if it exists from the Migration Validation
      Database previously created
   2. Reads the Project Server 2007 SP2 Draft database to extract Projects and Tasks information
   3. Stores the output dataset into a new table created in the Migration Validation
      Database
   This script requires to set the database names of the Migration Validation Database and the
   Project Server 2007 database in the USE statements
 ----------------------------------------------------------------------------------------------*/

USE ProjectServer_Migration_Data_Validation
IF EXISTS (SELECT id FROM dbo.sysobjects WHERE id = OBJECT_ID(N'MIgration_PS2007_Data_Validation_Snapshot')
AND OBJECTPROPERTY(id, N'IsUserTable') = 1)
DROP TABLE dbo.MIgration_PS2007_Data_Validation_Snapshot
GO
USE [ProjectServer_Draft]
GO
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO
SELECT p12p.proj_name as N'Project Name',
   p12p.proj_uid as 'Project UID',
   p12p.proj_info_start_date as N'Proj Start Date',
   p12p.proj_info_finish_date as N'Proj Finish Date',
   p12p.proj_info_status_date as N'Proj Status Date',
   p12p.CAL_UID as N'Proj Calendar UID',
   p12t.task_name as N'Task Name',
   p12t.TASK_ID AS N'Task ID',
       p12t.task_type as N'Task Type',
       p12t.task_start_date as N'Task Start Date',
       p12t.task_finish_date as N'Task Finish Date',
p12t.task_act_start as N'Task Act Start',
p12t.task_act_finish as N'Task Act Finish',
p12t.task_constraint_date as N'Task Constraint Date',
p12t.task_deadline as N'Task Deadline',
p12t.task_work as N'Task Work',
p12t.task_act_work as N'Task Actual Work',
p12t.task_rem_work as N'Task Rem Work',
p12t.task_ovt_work as N'Task Ovt Work',
p12t.task_act_ovt_work as N'Task Actual Ovt Work',
p12t.task_rem_ovt_work as N'Task Rem Ovt Work',
p12t.task_pct_comp as N'Task %Complete',
p12t.task_pct_work_comp as N'Task % Work Complete',
p12t.task_phy_pct_comp as N'Task % Phys Work Complete',
p12t.task_dur as N'Task Duration',
p12t.task_rem_dur as N'Task Rem Duration',
p12t.task_act_dur as N'Task Actual Duration',
p12t.task_is_milestone as N'Task Milestone',
p12t.task_cost as N'Task Cost',
p12t.task_fixed_cost as N'Task Fixed Cost',
p12t.task_act_cost as N'Task Actual Cost',
p12t.task_rem_cost as N'Task Rem Cost',
p12t.task_ovt_cost as N'Task Ovt Cost',
p12t.task_act_ovt_cost as N'Task Actual Ovt Cost',
p12t.task_rem_ovt_cost as N'Task Rem Ovt Cost'
INTO ProjectServer_Migration_Data_Validation.dbo.MIgration_PS2007_Data_Validation_Snapshot
FROM dbo.msp_projects AS p12p,
dbo.msp_tasks AS p12t
WHERE (p12p.proj_uid = p12t.proj_uid)

ORDER BY 1,4
/*---------------------------------------------------------------------------------------
-- Script A5: Capture Data Validation Snapshot for Project Server 2007 after migration---- Updated Jan 10,2010
-- This script:
-- 1. drops the PS2007 Validation Snapshot table if it exists from the Migration Validation
      Database previously created
   2. Reads the Project Server 2007 SP2 Draft database to extract Projects and Tasks information
   3. Stores the output dataset into a new table created in the Migration Validation
      Database
   This script requires to set the database names of the Migration Validation Database and the
   Project Server 2007 database in the USE statements
 ----------------------------------------------------------------------------------------------*/

USE ProjectServer_Migration_Data_Validation
IF EXISTS (SELECT id FROM dbo.sysobjects WHERE id = OBJECT_ID(N'MIgration_PS2007_Data_Validation_Snapshot')
AND OBJECTPROPERTY(id, N'IsUserTable') = 1)
DROP TABLE dbo.MIgration_PS2007_Data_Validation_Snapshot
GO
USE [ProjectServer_Draft_Migrated]
GO
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO
SELECT p12p.proj_name as N'Project Name',
   p12p.proj_uid as 'Project UID',
   p12p.proj_info_start_date as N'Proj Start Date',
   p12p.proj_info_finish_date as N'Proj Finish Date',
   p12p.proj_info_status_date as N'Proj Status Date',
   p12p.CAL_UID as N'Proj Calendar UID',
   p12t.task_name as N'Task Name',
   p12t.TASK_ID AS N'Task ID',
       p12t.task_type as N'Task Type',
       p12t.task_start_date as N'Task Start Date',
       p12t.task_finish_date as N'Task Finish Date',
p12t.task_act_start as N'Task Act Start',
p12t.task_act_finish as N'Task Act Finish',
p12t.task_constraint_date as N'Task Constraint Date',
p12t.task_deadline as N'Task Deadline',
p12t.task_work as N'Task Work',
p12t.task_act_work as N'Task Actual Work',
p12t.task_rem_work as N'Task Rem Work',
p12t.task_ovt_work as N'Task Ovt Work',
p12t.task_act_ovt_work as N'Task Actual Ovt Work',
p12t.task_rem_ovt_work as N'Task Rem Ovt Work',
p12t.task_pct_comp as N'Task %Complete',
p12t.task_pct_work_comp as N'Task % Work Complete',
p12t.task_phy_pct_comp as N'Task % Phys Work Complete',
p12t.task_dur as N'Task Duration',
p12t.task_rem_dur as N'Task Rem Duration',
p12t.task_act_dur as N'Task Actual Duration',
p12t.task_is_milestone as N'Task Milestone',
p12t.task_cost as N'Task Cost',
p12t.task_fixed_cost as N'Task Fixed Cost',
p12t.task_act_cost as N'Task Actual Cost',
p12t.task_rem_cost as N'Task Rem Cost',
p12t.task_ovt_cost as N'Task Ovt Cost',
p12t.task_act_ovt_cost as N'Task Actual Ovt Cost',
p12t.task_rem_ovt_cost as N'Task Rem Ovt Cost'
INTO ProjectServer_Migration_Data_Validation.dbo.MIgration_PS2007_Data_Validation_Snapshot
FROM dbo.msp_projects AS p12p,
dbo.msp_tasks AS p12t
WHERE (p12p.proj_uid = p12t.proj_uid)

ORDER BY 1,4


Run Migration Script 6 to capture all Project Server 2007 projects with associated project workspaces

Published: May 15, 2010

Run Script 6 to list all projects in the Microsoft Office Project Server 2007 Published database that have an associated project workspace site. This data is saved to a table in the ProjectServer_Migration_Data_Validation database. The data can be compared to pre-migration results from Script 4 to check whether all Microsoft Office Project Server 2003 projects with associated workspaces have been migrated and relinked.

Note:

This script is one of several post-migration scripts included in the Project Server virtual migration environment (VME). Running the scripts is optional, but highly recommended for helping to detect issues that may prevent a successful migration of your data. For more information about the post-migration scripts that are available, see Project Server VME: Run post-migration scripts (optional).

To run Script 6

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 databases, open Migrate_Proj_2003_Split_DB.

  3. Open the Verification Scripts folder, and then click VME Script 6.sql. This opens SQL Server Management Studio and displays Script 6.

  4. Click Execute to run the script.

  5. The results from the script are saved to the ProjectServer_Migration_Data_Validation database in the table named dbo.Migration_PS2007_ProjectWorkspaces.

Script 6

Copy Code
/*------------------------------------------------------------
-- Script A6
-- Project2007_Projects_With_WSS_Sites.sql
-- List all Projects with Associated WSS workspace sites
Run this query against the Project Server 2007 Published database
--------------------------------------------------------------*/
USE ProjectServer_Migration_Data_Validation
IF EXISTS (SELECT id FROM dbo.sysobjects WHERE id = OBJECT_ID(N'Migration_PS2007_ProjectWorkspaces')
AND OBJECTPROPERTY(id, N'IsUserTable') = 1)
DROP TABLE dbo.Migration_PS2007_ProjectWorkspaces
go
USE ProjectServer_Published
SELECT [PROJ_NAME]
,[PROJ_UID]
      ,[WPROJ_STS_SUBWEB_NAME]
      ,[WPROJ_ISSUE_LIST_NAME]
      ,[WPROJ_RISK_LIST_NAME]
      INTO ProjectServer_Migration_Data_Validation.dbo.Migration_PS2007_ProjectWorkspaces
       FROM [MSP_PROJECTS] P
where [WPROJ_STS_SUBWEB_NAME] IS NOT NULL
order by proj_name


Run Migration Script 7 to compare Project Server 2003 and Project Server 2007 data validation snapshots

Published: May 15, 2010

Migration Script 7 compares the pre-migration Microsoft Office Project Server 2003 data snapshot (created by Script 3) with the post-migration Microsoft Office Project Server 2007 data snapshot (created by Script 5). Script 7 does the following:

  1. Lists the projects not migrated to the draft database (existing projects in Project Server 2003 but not in the Office Project Server 2007 Published database)

  2. Lists the distinct project names with differences in specific fields

  3. Lists the distinct project names and tasks with differences in specific fields

This script sets variables for the Work, Duration, and Cost fields of the projects and tasks. The variables are used to determine the differences on various fields that are either greater than the positive margin of error or smaller than the negative margin of error, measure in terms of percentage. This feature allows the user to ignore the differences that are within the margin of error and to focus on the significant differences.

Important:

The results from the script can report a false mismatch of task identifiers between Project Server 2003 and Office Project Server 2007 tasks. For example, when you compare a task that has been migrated from Project Server 2003 to Office Project Server 2007, the Project Server 2003 TASK_UID may not match the Office Project Server 2007 TASK_ID. This occurs because tasks can get mismatched UIDs and IDs in Project Server 2003 when they are inserted, deleted, and moved throughout a project. If the results of Script 7 show these types of mismatches, you can verify that the migrated values are correct by comparing the values in Microsoft Project Professional from your source environment to your migration environment. These values should match.

Warning:

This script is one of several post-migration scripts included in the Project Server virtual migration environment (VME). Running the scripts is optional, but highly recommended for helping to detect issues that may prevent a successful migration of your data. For more information about the post-migration scripts that are available, see Project Server VME: Run post-migration scripts (optional).

To run Script 7

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 databases, open Migrate_Proj_2003_Split_DB.

  3. Open the Verification Scripts folder, and then click VME Script 7.sql. This opens SQL Server Management Studio and displays Script 7.

  4. Click Execute to run the script.

  5. View the results.

Important:

The results from the script can report a false mismatch of task identifiers between Project Server 2003 and Office Project Server 2007 tasks. For example, when you compare a task that has been migrated from Project Server 2003 to Office Project Server 2007, the Project Server 2003 TASK_UID may not match the Project Server 2003 TASK_ID. This occurs because tasks can get mismatched UIDs and IDs in Project Server 2003 when tasks are inserted, deleted, and moved within a project. If the results of Script 7 show these types of mismatches, you can verify whether the migrated values are correct by comparing the values shown in Microsoft Project Professional 2010 from your source environment to your migrated environment. If these values match, then the mismatches reported by Script 7 are false and you can ignore them.

Script 7

Script 7 contains the following code:

Copy Code
/*---------------------------------------------------------------------------------------
-- Script A7: Compares data validation snapshot between Pre-Migration (2003) and Post-Migration (2007) databases ----
-- This script:
-- 1. Compares the project data before and after the migration from Project Server 2003 SP3 to Project Server 2003 SP2
-- 2. List the projects not migrated to the draft database (existing in Project Server 2003 but missing in 2007)
   3. List the distinct project names with differences on specific fields
   4. List the distinct project names and tasks with differences on specific fields
   5. Adjust to parameters by using variables containing the % of difference between the Project 2003 and 2007 data

   This script requires you to set the database names of the Migration Validation Database.
   By default we have: USE ProjectServer_Migration_Data_Validation

   This script allows you to set variables for the Work, Duration and Cost fields of the projects and tasks. The variables are used
   to expose the differences on various fields which are either greater to the positive margin of error (in %) or smaller than
   the negative margin of error (in %). This feature allows the user to ignore the differences which are within the margin of error,
   and focus on the significant differences.

-- ************************************************ BEGIN DECLARE VARIABLES ************************************************ --
*/
DECLARE @Work_Ratio decimal(18,4);-- Variable to set the Work Ratio differences in % (+ or -) which are tolerable
DECLARE @Duration_Ratio decimal(18,4);-- Variable to set the Duration Ratio differences in % (+ or -) which are tolerable
DECLARE @Cost_Ratio decimal(18,4);-- Variable to set the Cost Ratio differences in % (+ or -) which are tolerable

--------------------------------------------  END DECLARE VARIABLES  ---------------------------------------------

-- *********************************************** BEGIN SET VARIABLE VALUES *********************************************** --

SET @Work_Ratio = 0.005;-- Set the Work Ratio to a % to ignore differences (+ or -) which are tolerable
SET @Duration_Ratio = 0.005;-- Set local variable to a % to ignore differences (+ or -) which are tolerable
SET @Cost_Ratio = 0.005;-- Set local variable to a % to ignore differences (+ or -) which are tolerable

------------------------------------------  END SET VARIABLE VALUES  -----------------------------------------------

 ----------------------------------------------------------------------------------------------*/

USE ProjectServer_Migration_Data_Validation

--------------------------------------------------
-- List of Projects not migrated to the Project Server 2007 Draft database
--------------------------------------------------
select distinct [Project Name] AS 'List of Projects not migrated to the Project Server 2007 Draft database'
from Migration_PS2003_Data_Validation_Snapshot
where replace([Project Name], '.Published', '_Published') not in
(select [Project Name] from Migration_PS2007_Data_Validation_Snapshot)
and Migration_PS2003_Data_Validation_Snapshot.[proj type] in (0,1,100)

--------------------------------------------------
-- Projects with different start date
--------------------------------------------------
select
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Start Dates not Matching After Migration',
datediff(day,
Migration_PS2003_Data_Validation_Snapshot.[Proj Start Date],
Migration_PS2007_Data_Validation_Snapshot.[Proj Start Date])
as Difference_in_Days
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot WITH (NOLOCK)
where
REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name] and
Migration_PS2003_Data_Validation_Snapshot.[Proj Start Date]
<> Migration_PS2007_Data_Validation_Snapshot.[Proj Start Date]
order by Difference_in_Days

--------------------------------------------------
-- Projects with different finish date
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Finish Dates not Matching After Migration',
Migration_PS2003_Data_Validation_Snapshot.[Proj Finish Date],
Migration_PS2007_Data_Validation_Snapshot.[Proj Finish Date],
datediff(day,
Migration_PS2003_Data_Validation_Snapshot.[Proj Finish Date],Migration_PS2007_Data_Validation_Snapshot.[Proj Finish Date])
as Difference_in_Days
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where
REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name] and
Migration_PS2003_Data_Validation_Snapshot.[Proj Finish Date] <> Migration_PS2007_Data_Validation_Snapshot.[Proj Finish Date]
order by Difference_in_Days

--------------------------------------------------
-- Projects with different Project Work
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Work not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task Work] AS 'Project 2003 Work'
, Migration_PS2007_Data_Validation_Snapshot.[Task Work] AS 'Project 2007 Work',
(Migration_PS2003_Data_Validation_Snapshot.[Task Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Work]) as 'Work Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task Work] <> Migration_PS2007_Data_Validation_Snapshot.[Task Work]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Work])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Work])/100)
or
((Migration_PS2003_Data_Validation_Snapshot.[Task Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Work])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Work])/100))
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by 'Work Difference'

--------------------------------------------------
-- Projects with different Actual Work
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Actual Work not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work] AS 'Project 2003 Actual Work'
, Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work] AS 'Project 2007 Actual Work',
(Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work]) as 'Actual Work Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work]
<> Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work])/100)
or
((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work])/100))
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by 'Actual Work Difference'

--------------------------------------------------
-- Projects with different Remaining Work
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Remaining Work not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work] AS 'Project 2003 Rem Work'
, Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work] AS 'Project 2007 Rem Work',
(Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work]) as 'Rem Work Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work]
<> Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work])/100)
or
((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work])/100))
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by 'Rem Work Difference'

--------------------------------------------------
-- Projects with different Project % Complete
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Task % Complete not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task %Complete] AS 'Project 2003 %Complete'
, Migration_PS2007_Data_Validation_Snapshot.[Task %Complete] AS 'Project 2007 %Complete',
(Migration_PS2003_Data_Validation_Snapshot.[Task %Complete]
- Migration_PS2007_Data_Validation_Snapshot.[Task %Complete]) as '%Complete Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task %Complete]
<> Migration_PS2007_Data_Validation_Snapshot.[Task %Complete]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by '%Complete Difference'

--------------------------------------------------
-- Projects with different Project %Work Complete
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Task %Work Complete not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task %Work Complete] AS 'Project 2003 %Work Complete'
, Migration_PS2007_Data_Validation_Snapshot.[Task % Work Complete] AS 'Project 2007 %Work Complete',
(Migration_PS2003_Data_Validation_Snapshot.[Task %Work Complete]
- Migration_PS2007_Data_Validation_Snapshot.[Task % Work Complete]) as '%Work Complete Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task %Work Complete]
<> Migration_PS2007_Data_Validation_Snapshot.[Task % Work Complete]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by '%Work Complete Difference'

----------------------------------------------------
-- Projects with different Task % Phys Work Complete
----------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Task % Phys Work Complete not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task % Phys Work Complete] AS 'Project 2003 % Phys Work Complete'
, Migration_PS2007_Data_Validation_Snapshot.[Task % Phys Work Complete] AS 'Project 2007 % Phys Work Complete',
(Migration_PS2003_Data_Validation_Snapshot.[Task % Phys Work Complete]
- Migration_PS2007_Data_Validation_Snapshot.[Task % Phys Work Complete]) as '% Phys Work Complete Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task % Phys Work Complete]
<> Migration_PS2007_Data_Validation_Snapshot.[Task % Phys Work Complete]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by '% Phys Work Complete Difference'

--------------------------------------------------
-- Projects with different Duration
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Duration not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task Duration] AS 'Project 2003 Duration'
, Migration_PS2007_Data_Validation_Snapshot.[Task Duration] AS 'Project 2007 Duration',
(Migration_PS2003_Data_Validation_Snapshot.[Task Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Duration]) as 'Duration Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task Duration]
<> Migration_PS2007_Data_Validation_Snapshot.[Task Duration]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Duration])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Duration])/100)
or
((Migration_PS2003_Data_Validation_Snapshot.[Task Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Duration])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Duration])/100))
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by 'Duration Difference'

--------------------------------------------------
-- Projects with different Remaining Duration
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Remaining Duration not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration]  AS 'Project 2003 Rem Duration'
, Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration] AS 'Project 2007 Rem Duration',
(Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration]) as 'Rem Duration Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration]
<> Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration])/100)
or
((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration])/100))
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by 'Rem Duration Difference'

--------------------------------------------------
-- Projects with different Actual Duration
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Actual Duration not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration]  AS 'Project 2003 Actual Duration'
, Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration] AS 'Project 2007 Actual Duration',
(Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration]) as 'Actual Duration Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration]
<> Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration])/100)
or
((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration])/100))
and (Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration]) != -1
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by 'Actual Duration Difference'

--------------------------------------------------
-- Projects with different Cost
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Cost not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task Cost]  AS 'Project 2003 Cost'
, Migration_PS2007_Data_Validation_Snapshot.[Task Cost] AS 'Project 2007 Cost',
(Migration_PS2003_Data_Validation_Snapshot.[Task Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Cost]) as 'Cost Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task Cost]
<> Migration_PS2007_Data_Validation_Snapshot.[Task Cost]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Cost])/100)
or
((Migration_PS2003_Data_Validation_Snapshot.[Task Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Cost])/100))
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by 'Cost Difference'

--------------------------------------------------
-- Projects with different Fixed Cost
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Fixed Cost not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost]  AS 'Project 2003 Fixed Cost'
, Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost] AS 'Project 2007 Fixed Cost',
(Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost]) as 'Fixed Cost Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost]
<> Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost])/100)
or
((Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost])/100))
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by 'Fixed Cost Difference'

--------------------------------------------------
-- Projects with different Actual Cost
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Actual Cost not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost]  AS 'Project 2003 Actual Cost'
, Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost] AS 'Project 2007 Actual Cost',
(Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost]) as 'Actual Cost Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost]
<> Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost])/100)
or
((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost])/100))
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by 'Actual Cost Difference'

--------------------------------------------------
-- Projects with different Remaining Cost
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Remaining Cost not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost]  AS 'Project 2003 Rem Cost'
, Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost] AS 'Project 2007 Rem Cost',
(Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost]) as 'Rem Cost Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot --WITH (NOLOCK)
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost]
<> Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost])/100)
or
((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost])/100))
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by 'Rem Cost Difference'

--------------------------------------------------
-- Projects with different Overtime Cost
--------------------------------------------------
select distinct
Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with Project Overtime Cost not Matching After Migration'
, Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost]  AS 'Project 2003 Ovt Cost'
, Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost] AS 'Project 2007 Ovt Cost',
(Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost]) as 'Ovt Cost Difference'
from
Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot
where

REPLACE(Migration_PS2003_Data_Validation_Snapshot.[Project Name],'.Published','_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name]
and Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost]
<> Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost])/100)
or
((Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost])/100))
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1
order by 'Ovt Cost Difference'

----------------------------------------------------------------------
/* Distinct Projects with one or more mismatch
---------------------------------------------------------------------*/
select Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects with at least one mismatch After Migration',
datediff(day,
Migration_PS2003_Data_Validation_Snapshot.[Proj Start Date],
Migration_PS2007_Data_Validation_Snapshot.[Proj Start Date]) as Start_Date_Diff_in_Days,
datediff(day,
Migration_PS2003_Data_Validation_Snapshot.[Proj Finish Date],
Migration_PS2007_Data_Validation_Snapshot.[Proj Finish Date]) as Finish_Date_Diff_in_Days,
(Migration_PS2003_Data_Validation_Snapshot.[Task Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Work]) as 'Work Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work]) as 'Actual Work Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work]) as 'Rem Work Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task %Complete]
- Migration_PS2007_Data_Validation_Snapshot.[Task %Complete]) as '%Complete Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task %Work Complete]
- Migration_PS2007_Data_Validation_Snapshot.[Task % Work Complete]) as '%Work Complete Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task % Phys Work Complete]
- Migration_PS2007_Data_Validation_Snapshot.[Task % Phys Work Complete]) as '% Phys Work Complete Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Duration]) as 'Duration Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration]) as 'Rem Duration Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration]) as 'Actual Duration Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Cost]) as 'Cost Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost]) as 'Fixed Cost Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost]) as 'Actual Cost Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost]) as 'Rem Cost Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost]) as 'Ovt Cost Diff'

from Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot
where
replace(Migration_PS2003_Data_Validation_Snapshot.[Project Name], '.Published', '_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name] and
(
Migration_PS2003_Data_Validation_Snapshot.[Proj Start Date] <> Migration_PS2007_Data_Validation_Snapshot.[Proj Start Date] or
Migration_PS2003_Data_Validation_Snapshot.[Proj Finish Date] <> Migration_PS2007_Data_Validation_Snapshot.[Proj Finish Date]
or (Migration_PS2003_Data_Validation_Snapshot.[Task Work] <> Migration_PS2007_Data_Validation_Snapshot.[Task Work]
   and ((Migration_PS2003_Data_Validation_Snapshot.[Task Work]- Migration_PS2007_Data_Validation_Snapshot.[Task Work])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Work])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Work] - Migration_PS2007_Data_Validation_Snapshot.[Task Work])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Work])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work] <> Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work]- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work] - Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work] <> Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work]- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work] - Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work])/100)))
or Migration_PS2003_Data_Validation_Snapshot.[Task %Complete] <> Migration_PS2007_Data_Validation_Snapshot.[Task %Complete]
or Migration_PS2003_Data_Validation_Snapshot.[Task %Work Complete]<> Migration_PS2007_Data_Validation_Snapshot.[Task % Work Complete]
or Migration_PS2003_Data_Validation_Snapshot.[Task % Phys Work Complete] <> Migration_PS2007_Data_Validation_Snapshot.[Task % Phys Work Complete]
or (Migration_PS2003_Data_Validation_Snapshot.[Task Duration] <> Migration_PS2007_Data_Validation_Snapshot.[Task Duration]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Duration]- Migration_PS2007_Data_Validation_Snapshot.[Task Duration])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Duration])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Duration] - Migration_PS2007_Data_Validation_Snapshot.[Task Duration])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Duration])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration] <> Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration]- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration] - Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration] <> Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration]- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration] - Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Cost] <> Migration_PS2007_Data_Validation_Snapshot.[Task Cost]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Cost]- Migration_PS2007_Data_Validation_Snapshot.[Task Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Cost])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Cost] - Migration_PS2007_Data_Validation_Snapshot.[Task Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Cost])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost]<> Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost]- Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost] - Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost] <> Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost]- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost] - Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost] <> Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost]- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost] - Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost] <> Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost]- Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost] - Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost])/100)))
)
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]= 0
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
and Migration_PS2007_Data_Validation_Snapshot.[Task Type] = 1

----------------------------------------------------------------------
/* Distinct Projects and Tasks with one or more mismatch
---------------------------------------------------------------------*/
select distinct Migration_PS2003_Data_Validation_Snapshot.[Project Name]
AS 'List of Projects and tasks with at least one mismatch after Migration',
Migration_PS2007_Data_Validation_Snapshot.[Task Name],
Migration_PS2007_Data_Validation_Snapshot.[Task ID],
Migration_PS2007_Data_Validation_Snapshot.[Task Type],
datediff(day,
Migration_PS2003_Data_Validation_Snapshot.[Proj Start Date],
Migration_PS2007_Data_Validation_Snapshot.[Proj Start Date]) as Start_Date_Diff_in_Days,
datediff(day,
Migration_PS2003_Data_Validation_Snapshot.[Proj Finish Date],
Migration_PS2007_Data_Validation_Snapshot.[Proj Finish Date]) as Finish_Date_Diff_in_Days,
(Migration_PS2003_Data_Validation_Snapshot.[Task Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Work]) as 'Work Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work]) as 'Actual Work Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work]) as 'Rem Work Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task %Complete]
- Migration_PS2007_Data_Validation_Snapshot.[Task %Complete]) as '%Complete Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task %Work Complete]
- Migration_PS2007_Data_Validation_Snapshot.[Task % Work Complete]) as '%Work Complete Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task % Phys Work Complete]
- Migration_PS2007_Data_Validation_Snapshot.[Task % Phys Work Complete]) as '% Phys Work Complete Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Duration]) as 'Duration Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration]) as 'Rem Duration Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration]) as 'Actual Duration Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Cost]) as 'Cost Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost]) as 'Fixed Cost Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost]) as 'Actual Cost Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost]) as 'Rem Cost Diff',
(Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost]
- Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost]) as 'Ovt Cost Diff'

from Migration_PS2003_Data_Validation_Snapshot, Migration_PS2007_Data_Validation_Snapshot
where
replace(Migration_PS2003_Data_Validation_Snapshot.[Project Name], '.Published', '_Published')
= Migration_PS2007_Data_Validation_Snapshot.[Project Name] and
(
Migration_PS2003_Data_Validation_Snapshot.[Proj Start Date] <> Migration_PS2007_Data_Validation_Snapshot.[Proj Start Date] or
Migration_PS2003_Data_Validation_Snapshot.[Proj Finish Date] <> Migration_PS2007_Data_Validation_Snapshot.[Proj Finish Date]
or (Migration_PS2003_Data_Validation_Snapshot.[Task Work] <> Migration_PS2007_Data_Validation_Snapshot.[Task Work]
   and ((Migration_PS2003_Data_Validation_Snapshot.[Task Work]- Migration_PS2007_Data_Validation_Snapshot.[Task Work])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Work])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Work] - Migration_PS2007_Data_Validation_Snapshot.[Task Work])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Work])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work] <> Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work]- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work] - Migration_PS2007_Data_Validation_Snapshot.[Task Actual Work])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Actual Work])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work] <> Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work]- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work] - Migration_PS2007_Data_Validation_Snapshot.[Task Rem Work])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Rem Work])/100)))
or Migration_PS2003_Data_Validation_Snapshot.[Task %Complete] <> Migration_PS2007_Data_Validation_Snapshot.[Task %Complete]
or Migration_PS2003_Data_Validation_Snapshot.[Task %Work Complete]<> Migration_PS2007_Data_Validation_Snapshot.[Task % Work Complete]
or Migration_PS2003_Data_Validation_Snapshot.[Task % Phys Work Complete] <> Migration_PS2007_Data_Validation_Snapshot.[Task % Phys Work Complete]
or (Migration_PS2003_Data_Validation_Snapshot.[Task Duration] <> Migration_PS2007_Data_Validation_Snapshot.[Task Duration]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Duration]- Migration_PS2007_Data_Validation_Snapshot.[Task Duration])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Duration])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Duration] - Migration_PS2007_Data_Validation_Snapshot.[Task Duration])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Duration])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration] <> Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration]- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration] - Migration_PS2007_Data_Validation_Snapshot.[Task Rem Duration])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Rem Duration])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration] <> Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration]- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration] - Migration_PS2007_Data_Validation_Snapshot.[Task Actual Duration])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Actual Duration])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Cost] <> Migration_PS2007_Data_Validation_Snapshot.[Task Cost]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Cost]- Migration_PS2007_Data_Validation_Snapshot.[Task Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Cost])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Cost] - Migration_PS2007_Data_Validation_Snapshot.[Task Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Cost])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost]<> Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost]- Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost] - Migration_PS2007_Data_Validation_Snapshot.[Task Fixed Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Fixed Cost])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost] <> Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost]- Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost] - Migration_PS2007_Data_Validation_Snapshot.[Task Actual Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Actual Cost])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost] <> Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost]
    and ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost]- Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost] - Migration_PS2007_Data_Validation_Snapshot.[Task Rem Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Rem Cost])/100)))
or (Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost] <> Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost]
and ((Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost]- Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost])
> ((@Work_Ratio * Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost])/100)
or ((Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost] - Migration_PS2007_Data_Validation_Snapshot.[Task Ovt Cost])
 < ((@Work_Ratio*-1)* Migration_PS2003_Data_Validation_Snapshot.[Task Ovt Cost])/100)))
)
and Migration_PS2003_Data_Validation_Snapshot.[Task UID]
= Migration_PS2007_Data_Validation_Snapshot.[Task ID]
and Migration_PS2003_Data_Validation_Snapshot.[Task Type] =
    Migration_PS2007_Data_Validation_Snapshot.[Task Type]
order by Migration_PS2003_Data_Validation_Snapshot.[Project Name],
Migration_PS2007_Data_Validation_Snapshot.[Task ID]


Run Migration Script 8 to list projects with unlinked workspaces

Published: May 15, 2010

Run Script 8 to list Microsoft Office Project Server 2007 projects that have to be relinked to their project workspaces. This script compares the result from Script 4 (pre-migration Microsoft Office Project Server 2003 projects with associated workspaces) and Script 6 (post-migration Office Project Server 2007 projects with associated workspaces). The data for both are stored in the dbo.Migration_PS2003_ProjectWorkspaces and dbo.Migration_PS2007_ProjectWorkspaces tables in the ProjectServer_Migration_Data_Validation database.

Warning:

This script is one of several post-migration scripts included in the Project Server virtual migration environment (VME). Running the scripts is optional, but highly recommended for helping to detect issues that may prevent a successful migration of your data. For more information about the post-migration scripts that are available, see Project Server VME: Run post-migration scripts (optional).

To run Script 8

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 databases, open Migrate_Proj_2003_Split_DB.

  3. Open the Verification Scripts folder, and then click VME Script 8.sql. This opens SQL Server Management Studio and displays Script 8.

  4. Click Execute to run the script.

  5. The results shown are the projects that have to be relinked to their project workspaces.

Script 8

Script 8 contains the following code:

Copy Code
/*---------------------------------------------------------------------------------------
-- Script A8: Compares workspaces associated with projects pre-migration (2003) and Post-Migration (2007) ----
-- This script shows the workspaces that have not been re-linked and/or converted in the 2007 environment after migration
-- ******************************************************************************************************** --
*/
USE ProjectServer_Migration_Data_Validation
-----------------------------------------------------------------
-- List of projects with workspaces missing in 2007
-- These workspaces should be re-linked manually after migration
-----------------------------------------------------------------
select distinct [PROJ_NAME] AS 'List of Projects with Missing Workspaces in the Project Server 2007 Published database. Re-Link them manually'
from  dbo.Migration_PS2003_ProjectWorkspaces
where replace([PROJ_NAME], '_Published', '') not in
(select [PROJ_NAME] from dbo.Migration_PS2007_ProjectWorkspaces)


Run Migration Script 9 to test your Project Server 2007 data for known migration issues

Published: May 15, 2010

Run Script 9 to run a data validation check on your Microsoft Office Project Server 2007 databases to look for known conditions that may cause an upgrade to Microsoft Project Server 2010 to fail. Script 9 checks for the following conditions:

  1. Office Project Server 2007 is updated to Service Pack 2 and the October 2009 Cumulative Update

  2. Projects not saved and published since the installation to Office Project Server 2007 of both Service Pack 2 and the October 2009 Cumulative Update

  3. Lookup tables that are using names that are reserved in Project Server 2010

  4. Custom field names that are reserved in Project Server 2010

  5. Office Web Components (OWC) views in Office Project Server 2007 that need to be migrated to Excel Services for use in Project Server 2010

  6. User accounts with forms-authenticated login names

  7. Team names that have no associated lookup table or a value

  8. Office Project Web Access Portfolio Analyzer OWC views in Project Server 2003 that may need to be migrated to Office Project Server 2007

Note:

This script is one of several post-migration scripts included in the Project Server virtual migration environment (VME). Running the scripts is optional, but highly recommended for helping to detect issues that may prevent a successful migration of your data. For more information about the post-migration scripts that are available, see Project Server VME: Run post-migration scripts (optional).

To run Script 9

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 databases, open Migrate_Proj_2003_Split_DB.

  3. Open the Verification Scripts folder, and then click VME Script 9.sql. This opens SQL Server Management Studio and displays Script 9.

  4. Click Execute to run the script.

  5. The results will appear. Try to resolve any issues that are found before migrating your data to Project Server 2010.

You can use Microsoft Office Project Professional 2007 (included in the VME) to try to resolve some of data issues that are detected in this script.

Script 9

Script 9 includes the following code:

Copy Code
------------------------------------------------------------------------------
/* Pre-Migration Steps from Project 2007 SP2 to Project 2010
VME Script 12
-----------------------------------------------------------------------------*/

------------------------------------------------------------------------------
/* Check Project 2007 Version: Must be SP2 + October CU = ??
-----------------------------------------------------------------------------*/
USE ProjectServer_Draft
select Version
as 'Project Server 2007 SP2 + Oct09CU Version Must Be 12.0.6520.5000 or Higher. If not, upgrade to SP2 + Oct2009 CU'
, timestamp
from dbo.Versions
go
----------------------------------------------------------------------------------------------
/* Display the projects not saved or published since the installation of SP2 + December 09 CU?
----------------------------------------------------------------------------------------------*/
select Distinct PROJ_NAME AS 'List of Projects Not Saved and Published Since the Installation of Service Pack2'
,PROJ_PROP_AUTHOR, PROJ_LAST_SAVED, WPROJ_LAST_PUB
from dbo.MSP_PROJECTS
where PROJ_TYPE = 0
and ((dbo.MSP_PROJECTS.PROJ_LAST_SAVED < (SELECT MAX(TimeStamp) FROM dbo.Versions))
OR (dbo.MSP_PROJECTS.WPROJ_LAST_PUB < (SELECT MAX(TimeStamp) FROM dbo.Versions)))
GROUP BY PROJ_NAME,PROJ_PROP_AUTHOR, PROJ_LAST_SAVED, WPROJ_LAST_PUB
Order by PROJ_NAME
go
------------------------------------------------------------------------------
/* Display the Lookup tables using reserved names in 2010
This query is to be run against the Published database of Project Server 2007
-----------------------------------------------------------------------------*/
USE ProjectServer_Published
select LT_NAME
AS 'List of Lookup Table names with Reserved Names. These names must be changed before proceeding with the Upgrade'
from dbo.MSP_LOOKUP_TABLES
WHERE LT_NAME IN
('Department',
'Project Impact',
'Relative Importance',
'Sample Areas Impacted',
'Sample Primary Objective')
-- Cost Type, Health, RBS and State are standard in 2007
go
------------------------------------------------------------------------------
/* Display the Custom Fields using reserved names in 2010
This query is to be run against the Published database of Project Server 2007
-----------------------------------------------------------------------------*/
USE ProjectServer_Published
select MD_PROP_NAME
AS 'List of Custom Fields names with Reserved Names. These names must be changed before proceeding with the Upgrade'
from dbo.MSP_CUSTOM_FIELDS
WHERE MD_PROP_NAME IN
('Flag Status',
'Project Departments',
'Project Impact',
'Relative Importance',
'Resource Departments',
'Sample Approved Finish Date',
'Sample Approved Start Date',
'Sample Areas Impacted',
'Sample Assumptions',
'Sample Business Need',
'Sample Compliance Proposal',
'Sample Goals',
'Sample Post Implementation Review Date',
'Sample Post Implementation Review Notes',
'Sample Primary Objectives',
'Sample Proposal Cost',
'Sample Proposed Finish Date',
'Sample Proposed Start Date')
go
---------------------------------------------------------------------------------------------------------
/* Displays Existing OWC Views in 2007 that need to be migrated to Excel Services in Project Server 2010
--------------------------------------------------------------------------------------------------------*/
select WVIEW_NAME AS 'List of PWA Data Analysis OWC Views to Migrate to Excel Services in Project Server 2010'
FROM dbo.MSP_WEB_VIEW_REPORTS
WHERE WVIEW_OWC_PIVOT_XML is not null
OR WVIEW_OWC_CHART_XML is not null

------------------------------------------------------------------------------
/* Displays User Accounts with Forms Auth Login Names > 249 Ch. -- on 2007
-----------------------------------------------------------------------------*/
select RES_NAME AS 'List of FBA accounts with Names > 249 Ch. Shorten the Resource Names below'
FROM dbo.MSP_RESOURCES
WHERE RES_IS_WINDOWS_USER = 0
AND (Select LEN(RES_NAME)) > 249
go
------------------------------------------------------------------------------
/* Display Team Names with no Lookup Tables and a Value -- on 2007
-----------------------------------------------------------------------------*/
select TEXT_VALUE AS 'List of Team Names with values and NO Lookup Tables. Create a LT for these Teams'
FROM dbo.MSP_RES_CUSTOM_FIELD_VALUES, dbo.MSP_CUSTOM_FIELDS, dbo.MSP_LOOKUP_TABLES
WHERE dbo.MSP_RES_CUSTOM_FIELD_VALUES.CUSTOM_FIELD_UID = dbo.MSP_CUSTOM_FIELDS.MD_PROP_UID
AND MD_PROP_NAME = 'Team Name'
AND dbo.MSP_CUSTOM_FIELDS. MD_LOOKUP_TABLE_UID IS NULL
go

------------------------------------------------------------------------------------------------------------------
/* Displays Existing PWA Portfolio Analyzer OWC Views in 2003 that may need to be migrated to Project Server 2007
-----------------------------------------------------------------------------------------------------------------*/
USE Project2003SourceDB
select WVIEW_NAME AS 'List of PWA Portfolio Analyzer OWC Views to Migrate to Project Server 2007'
FROM dbo.MSP_WEB_VIEW_REPORTS
WHERE WVIEW_OWC_PIVOT_XML is not null
OR WVIEW_OWC_CHART_XML is not null


Run Migration Script 10 to correct multilanguage lookup table upgrade issues

Published: May 15, 2010

Run Script 10 to check your Microsoft Office Project Server 2007 data for a known issue in which multi-language lookup tables are not updated correctly after migration from Microsoft Office Project Server 2003 to Office Project Server 2007. This script corrects and updates the Office Project Server 2007 Published database if the issue is detected.

Warning:

This script is one of several post-migration scripts included in the Project Server virtual migration environment (VME). Running the scripts is optional, but highly recommended for helping to detect issues that may prevent a successful migration of your data. For more information about the post-migration scripts that are available, see Project Server VME: Run post-migration scripts (optional).

To run Script 10

  1. On the VME desktop, click Start Migration Process. This opens a Windows Explorer window that displays the contents of drive E.

  2. In Windows Explorer, double-click the following folder:

    • If you have one Project 2003 database, open the Migrate_Proj_2003_Single_DB folder.

    • If you have split Project Server 2003 databases, open Migrate_Proj_2003_Split_DB.

  3. Open the Verification Scripts folder, and then click VME Script 10.sql. This opens SQL Server Management Studio and displays Script 10.

  4. Click Execute to run the script.

Script 10

Script 10 contains the following code:

Copy Code
Use ProjectServer_Published

DELETE FROM dbo.MSP_LOOKUP_TABLE_LANGUAGES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)

DELETE FROM dbo.MSP_LOOKUP_TABLE_MASK_VALUES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)

DELETE FROM dbo.MSP_LOOKUP_TABLE_MASK_STRUCTURES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)

DELETE FROM dbo.MSP_LOOKUP_TABLE_VALUES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)

DELETE FROM dbo.MSP_LOOKUP_TABLE_STRUCTURES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)


Project Server VME: Plan to upgrade data to Project Server 2010

Published: May 15, 2010

After you have completed the Project Server virtual migration environment (VME) post-migration phase, you will have successfully migrated your Microsoft Office Project Server 2003 data to Office Project Server 2007 with SP2. You can now move your Office Project Server 2007 databases to your Microsoft Project Server 2010 environment to upgrade your data to Project Server 2010.

Migrating from Project Server 2003 to Project Server 2010 through the VME is a three-step process:

  • Migrate the data from Project Server 2003 to Office Project Server 2007 with SP2. (This step occurs in the virtual migration environment.)

  • Move the data from the VME to the Project Server 2010 farm database server.

  • Upgrade the data from Office Project Server 2007 to Project Server 2010.

The virtual migration environment only migrates the data from Project Server 2003 to Office Project Server 2007 with SP2. To complete the upgrade to Project Server 2010, you must use the database-attach upgrade method to upgrade the Office Project Server 2007 with SP2 databases to Project Server 2010. This requires that you have an installation of Project Server 2010 in your organization.

For more information about installing Project Server 2010, see Deploy Project Server 2010 to a server farm environment.

In this article:

  • Database-attach upgrade

  • Create database backups

  • Migrate to Project Server 2010

Note:

For more information about the Project Server virtual migration environment (VME), see Migrate your Project Server 2003 data by using the VME. For more information about upgrading to Project Server 2010, see Project Server 2010 upgrade overview.

Database-attach upgrade

Migrating your data from the VME to Project Server 2010 requires you to use the database-attach upgrade method. A database-attach upgrade lets you "attach" restored copies of your Office Project Server 2007 databases to a new Project Server 2010 installation. Office Project Server 2007 farm databases are backed up and then restored on the computer that is running Microsoft SQL Server that is hosting the Project Server 2010 databases. The new Project Server 2010 farm points to these restored databases when the Microsoft Project Web App instance is created. When you connect to the databases from the new Project Server 2010 instance, the databases are upgraded to Project Server 2010.

There are two variations of the database-attach upgrade:

  • Database attach full: Upgrades the four Office Project Server 2007 databases and the content database that contains the Project Web App site data. Use this method if you also want to migrate your project workspace data.

  • Database attach core: Upgrades only the four Office Project Server 2007 databases. Use this method if you do not want to migrate your project workspace data.

A database-attach full upgrade requires the following databases from the Office Project Server 2007 farm:

  • ProjectServer_Archive

  • ProjectServer_Draft

  • ProjectServer_Published

  • ProjectServer_Reporting

  • Windows SharePoint Services 3.0 content database containing the project workspace data

A database-attach core upgrade requires the following Office Project Server 2007 databases from the farm:

  • ProjectServer_Archive

  • ProjectServer_Draft

  • ProjectServer_Published

  • ProjectServer_Reporting

Note:

For more information about database-attach upgrades, see Project Server 2010 upgrade overview.

Create database backups

You have to create database backups of the required databases in SQL Server 2005 on the VME, as described in the following procedure:

To back up a database in SQL Server 2005

  1. On the VME virtual machine, open SQL Server Management Studio.

  2. In the Connect to Server dialog box, click Connect.

  3. In SQL Server Management Studio, in Object Explorer, expand Databases. Right-click the database that you want to back up, click Tasks, and then click Back Up. The Back Up Database dialog box appears.

  4. In the Back Up Database dialog box, in the Source section, in the Database field, verify that the database name is the one for which you want to create a backup.

  5. In the Backup type field, select Full.

  6. In the Backup component field, select Database.

  7. In the Backup set section, in the Name field, either accept the default backup set name that is suggested or type a different name for the backup set.

  8. In the Destination section, select Disk, and then specify a destination to which you want to save the backup file.

  9. Click OK to start the backup process.

Repeat the procedure to back up the remaining required databases.

Migrate to Project Server 2010

After you have created database backups of your required databases, move the copies from the VME to the computer that is running SQL Server that is hosting the Project Server 2010 databases. If the VME virtual machine is not on the network, you can transfer the files through an internal virtual network between the VME and the computer that hosts the VME virtual machine. This was established previously when you transferred Project Server 2003 data from the virtual machine host to the VME virtual machine. For more information, see Load data to the Project Server VME).

The following articles describe how to migrate your Office Project Server 2007 databases to Project Server 2010 to complete your migration from Project Server 2003. Choose the right method for you and follow the procedures in that article:

  • Database-attach full upgrade to Project Server 2010

  • Database-attach core upgrade to Project Server 2010


Upgrade to Project Server 2010 from Project Server 2003

Published: May 12, 2010

This chapter provides information and procedures about how to migrate from Microsoft Office Project Server 2003 to Microsoft Project Server 2010 .

  • Migration overview and considerations (Project Server 2010)

  • Prepare your environments for migrating from Project Server 2003

  • Pre-migration tasks for migrating your Project Server 2003 data

  • Migration tasks for migrating to Project Server 2007

  • Post-migration tasks after migrating your Project Server 2003 data

  • Complete your upgrade from Project Server 2003 to Project Server 2010

  • Migrate your Project Server 2003 data by using the VME

Additionally, Microsoft provides a Microsoft Office Project Server 2007 virtual migration environment as an option for migrating your Project Server 2003 data to Project Server 2010. This option is an alternative to installing your Office Project Server 2007 environment manually, or it can be used if you do not have Office Project Server 2007 readily available.

Note:

You must migrate your Project Server 2003 data first to Office Project Server 2007, before migrating it to Project Server 2010. There is no way to migrate directly to Project Server 2010 from Project Server 2003.

For more information about the Office Project Server 2007 virtual migration environment, see: Migrate your Project Server 2003 data by using the VME.


Migration overview and considerations (Project Server 2010)

Published: May 12, 2010

Summary: Read about migration from Project Server 2003 to Project Server 2010, including server requirements and client-compatibility requirements.

Important:

Upgrading from the Project Server 2010 public Beta to the Project Server 2010 released version is explicitly blocked and not supported. This restriction applies to both the in-place and database-attach upgrade methods.

Migration from Microsoft Office Project Server 2003 to Microsoft Project Server 2010 is a two-step process:

  1. Migrate from Project Server 2003 to Microsoft Office Project Server 2007

  2. Migrate from Office Project Server 2007 to Project Server 2010

Migrating from Project Server 2003 to Project Server 2007

Migration from Project Server 2003 to Office Project Server 2007 can be done in one of two ways:

  • Standard migration: A standard migration requires you to install Office Project Server 2007 and then migrate your data from Project Server 2003 through a utility known as the Migration tool.

  • Virtual Migration Environment (VME): A fully configurable environment that has Office Project Server 2007 with SP2 and that is packaged in a Hyper-V image. It can be run as a stand-alone environment for the sole purpose of migrating Project Server 2003 data to the Office Project Server 2007 data format. The VME provides Project Server 2003 you a way to migrate to Project Server 2010 without having to set up an intermediate Office Project Server 2007 environment.

Migrating data from Project Server 2003 to Office Project Server 2007 is done by the "migration tool" (which can be installed from the Microsoft Office Project Professional 2007 installation disk). This is a command-line tool.

Migration architecture diagram

The migration tool reads data from the Project Server 2003 database, cleanses and reformats the data and saves it to Office Project Server 2007. Some data, including projects and enterprise resources, is saved to the computer running Office Project Server 2007 through the Project Server Interface (PSI). Other data, including all Office Project Web Access data and upgrade metadata, is directly written to the Office Project Server 2007 database.

If Project Server 2003 is integrated with Windows SharePoint Services 2.0, you must upgrade Windows SharePoint Services 2.0 to Service Pack 2 (SP2) and then upgrade it to Windows SharePoint Services 3.0. Both the data (issues, risks, documents) and the links between Project items and Windows SharePoint Services items are upgraded at the end of the migration process.

You can only migrate data to Office Project Server 2007 from a Project Server 2003 database with Service Pack 2a (SP2a) or a subsequent service pack applied. The most current service pack for Project Server 2003 is Service Pack 3.

Note:

Windows SharePoint Services 2.0 was an optional component for Project Server 2003 (Office Project Web Access did not depend on Windows SharePoint Services 2.0). But Windows SharePoint Services 3.0 is a required component for Office Project Server 2007 (Office Project Web Access for Office Project Server 2007 is built on top of Windows SharePoint Services 3.0, and Office Project Server 2007 deployment is based on the Windows SharePoint Services farm infrastructure). That is the reason that Office Project Server 2007 and Windows SharePoint Services 3.0 are represented on the same server in the diagram above.

Note:

The command-line migration tool can be thought of as a specialized version of Office Project Professional 2007 without any user interface — so Microsoft Project Professional and the migration tool cannot be running on the same computer at the same time.

For detailed documentation for migrating from Project Server 2003 to Office Project Server 2007, see Upgrade to Project Server 2010 from Project Server 2003.

Migrating from Project Server 2007 to Project Server 2010

Migrating from Office Project Server 2007 to Project Server 2010 can be done through two methods:

  • In-place: The Office Project Server 2007 installation is upgraded to Project Server 2010 on the same computer on which it is installed.

  • Database attach: The Office Project Server 2007 databases are backed up and then restored on the computer that is running SQL Server that will host the Project Server 2010 databases. Office Project Server 2007, installed on another computer, then upgrades the databases by provisioning a Microsoft Project Web App instance using the restored Office Project Server 2007 databases.

When migrating from Project Server 2003 to Office Project Server 2007 in order to upgrade to Project Server 2010, you can use either method described above.

If you plan to use the database attach method of upgrading:

  • Use the database attach full upgrade method if you need to migrate your Office Project Web Access site data plus your project data. For more information about this method, see Database-attach full upgrade to Project Server 2010.

  • Use the database attach core upgrade method if you only need to migrate your Office Project Server 2007 project data. For more information about this method, see Database-attach core upgrade to Project Server 2010.

Important:

If you intend to do an in-place upgrade of Project Server 2010, your Office Project Server 2007 installation must be on a Windows Server 2008 64-bit platform. For more information about requirements, see the Server requirements section in this article. For more information about in-place upgrade, see In-place upgrade to Project Server 2010.

Note:

If you are planning to upgrade through the Virtual Migration Environment when it becomes available, note that after using it to migrate from Project Server 2003 to Office Project Server 2007, you will only be able to upgrade to Project Server 2010 using the database attach method.

For more information about Project Server 2010 upgrade methods, see Project Server 2010 upgrade overview.

Server requirements

When you are planning to upgrade from Project Server 2003 to Project Server 2010, it is important to plan for server requirements needed for Project Server 2003 and Office Project Server 2007.

A major difference between Project Server 2003 and Office Project Server 2007 is the availability of 32-bit and 64-bit versions of the application software. For Office Project Server 2007, we already recommend that you deploy 64-bit versions of the application, both on the front-end Web server and on the application server roles. In Project Server 2010, only a 64-bit version of the application is available.

A 64-bit version of Microsoft SQL Server is highly recommended for Office Project Server 2007, and it is mandatory for Project Server 2010. The 64-bit applications benefit from a much larger addressable memory space, which improves the performance under medium to heavy workloads.

It is also important to note that Microsoft SharePoint Server 2010 Enterprise edition is a requirement for installing Project Server 2010.

The official support of virtualized environments is also a new benefit of Office Project Server 2007 and Project Server 2010.

 | Project Server 2003 | Office Project Server 2007 | Project Server 2010
Operating System | Windows Server 2000 SP3 32-bit Windows Server 2003 32-bit | Windows Server 2003 SP1 32-bit or 64-bit Windows Server 2008 32-bit or 64-bit | Windows Server 2008 64-bit Windows Server 2008 R2 64-bit
SharePoint Products and Technologies | Windows SharePoint Services 2.0 (optional) | Windows SharePoint Services 3.0 32-bit or 64-bit | SharePoint Server 2010 Enterprise Edition 64-bit
SQL Server | SQL Server 2000 SP3 | SQL Server 2000 SP3 SQL Server 2005 SP3 with CU6 SQL Server 2008 | SQL Server 2005 SP3 CU3 64-bit SQL Server 2008 SP1 CCU2 64-bit
Virtualization | Not supported. | Supported | Supported

Using the Virtual Migration Environment (VME) to upgrade from Project Server 2003 to Office Project Server 2007 requires you to have the Hyper-V feature on Windows Server 2008 or Hyper-V Server 2008.

Cross-version compatibility between client and server products

When migrating to Project Server 2010, you must also plan for client compatibility requirements. The following table shows cross-version capability between Microsoft Project Professional client versions to Project Server versions. You will need to verify that all Microsoft Project Professional users have the proper version to access Project Server after the upgrade.

This client version Only connects to this server version

Office Project Professional 2003

Project Server 2002, Project Server 2003

Office Project Professional 2007

Office Project Server 2007, Project Server 2010

Note:

Office Project Professional 2007 only connects to Project Server 2010 when Backwards Compatibility Mode (BCM) is enabled on the server. For more information about BCM, see Project Server 2010 upgrade overview.

Microsoft Project Professional 2010

Project Server 2010

The following table describes supported browsers required for Project Web App for each version of Project Server. If you are upgrading from Project Server 2003 to Project Server 2010, verify that your Project Web App users have the required browser to access their data after the upgrade.

Project Web App version | Required browser
Project Server 2003 | Internet Explorer 5.5, 6.0, 7.0, and 8.0
Office Project Server 2007 | Internet Explorer 6.0, 7.0, 8.0, and 9.0
Project Server 2010 | Internet Explorer 7.0, 8.0, and 9.0

Custom field and lookup table name conflicts

There are certain custom fields and lookup tables name that are reserved in both Office Project Server 2007 and Project Server 2010. If any of these names are used in the current Project Server 2003 database, the custom fields and outline codes must be changed in Project Server 2003 before proceeding further with the migration. Use Microsoft Office Project Professional 2003 connected to a Project Server 2003 instance to validate and take corrective action.

Outline code or custom-field name that is reserved | Type | Office Project Server 2007 | Project Server 2010
Cost Type | Resource | X | X
Health | Task | X | X
State | Project | X | X
Team Name | Resource | X | X
Approved Finish Date | Project |  | X
Approved Start Date | Project |  | X
Areas affected | Project |  | X
Assumptions | Project |  | X
Business Need | Project |  | X
Compliance Proposal | Project |  | X
Flag Status | Task |  | X
Goals | Project |  | X
Post-Implementation Review Date | Project |  | X
Post-Implementation Review Notes | Project |  | X
Primary Objectives | Project |  | X
Project Departments | Project |  | X
Proposal Cost | Project |  | X
Proposed Finish Date | Project |  | X
Proposed Start Date | Project |  | X
Resource Department | Resource |  | X

Additionally, make sure to see Verify your Project Server 2003 data for additional things you can check for before migrating your Project Server 2003 data.


Prepare your environments for migrating from Project Server 2003

Published: May 12, 2010

Before migrating your Microsoft Office Project Server 2003 data to Microsoft Project Server 2010, you must prepare each of your environments to help to ensure that your migration is successful. This includes:

  • Prepare your Project Server 2003 environment Provides information about installing required updates for your Project Server 2003 environment.

  • Prepare your Project Server 2007 environment Provides information about installing Microsoft Office Project Server 2007, applying required updates, backing up your environment, and installing the migration tool.

  • Prepare your Project Server 2010 environment Provides information about installing your Project Server 2010 environment.


Prepare your Project Server 2003 environment

Published: May 12, 2010

You must prepare your Microsoft Office Project Server 2003 environment for migration to Microsoft Office Project Server 2007 in order to migrate to Microsoft Project Server 2010. To prepare your Project Server 2003 environment, you must do the following:

  • Update your Project Server 2003 installation to Project Server 2003 Service Pack 3 (only required if your Project Server 2003 deployment does not have a service pack that supports upgrade (Service Pack 2a or Service Pack 3)).

  • If you are using Windows SharePoint Services 2.0 for project workspaces, you must update to Windows SharePoint Services 2.0 Service Pack 3 (only required if your Windows SharePoint Services 2.0 deployment is not updated with a service pack that supports upgrade (Service Pack 2 or Service Pack 3).

    Important:

    If you do not want to upgrade your project workspace sites, you do not need to apply the update to Windows SharePoint Services 2.0.

Update Project Server 2003 with Service Pack 3

Project Server 2003 SP3 is composed of three parts, each of which can be downloaded and installed separately, as needed:

  1. An upgrade for the Project Server 2003 database

  2. An update for the Project Server application binaries

  3. An update for the Project Server template files on Windows SharePoint Services

Depending on your migration deployment strategy, you may need one or more of the parts listed above.

  • To upgrade your existing installation to the latest service pack, you must use all three parts and upgrade your existing Project Server 2003 and Windows SharePoint Services 2.0 installation to SP3. This is the simplest way to upgrade.

  • To keep your existing Project Server 2003 installation (without applying SP3), you must do the following:

    1. Create a backup of your Project Server 2003 database. Restore it, optionally using a different name. Apply SP3 part 1 to the restored database.

    2. Apply SP3 part 3 to the Windows SharePoint Services 2.0 installation.

    Note:

    More information about the service pack can be found in the Knowledge Base article named Description of Project Server 2003 Service Pack 3 (http://go.microsoft.com/fwlink/p/?LinkId=188720).

Update Windows SharePoint Services 2.0 with Service Pack 3

Note:

As mentioned previously, if you do not want to migrate your project workspace sites from Project Server 2003, you do not need to apply this update.

For information about Windows SharePoint Services 2.0 Service Pack 3, see Description of Windows SharePoint Services 2.0 Service Pack 3 (http://go.microsoft.com/fwlink/p/?LinkID=101608).


Prepare your Project Server 2007 environment

Published: May 12, 2010

In order to migrate to Microsoft Project Server 2010, you must prepare your Microsoft Office Project Server 2007 environment when you migrate from Microsoft Office Project Server 2003 to Office Project Server 2007. Things that you need to do to prepare your environment include the following:

  • Install Office Project Server 2007

  • Apply updates to Office Project Server 2007 and Windows SharePoint Services 3.0

  • Set up forms-based authentication (optional)

  • Back up all Project Server 2003 and Office Project Server 2007 databases

  • Determine the number of workstations where the migration tool must be installed

  • Install the migration tool

  • Apply updates to Microsoft Office Project Professional 2007 for the migration tool

If you do not have the Office Project Server 2007 installation media available to you within your company, you can download the evaluation version of Office Project Server 2007 from the Microsoft TechNet Office Project Professional 2007 and Office Project Server 2007 Evaluation Download Page. If you do not have Office Project Professional 2007, you should also download the evaluation version of it from that page, because you have to run the Migration Tool that is included with it.

Note:

Microsoft also provides a Office Project Server 2007 virtual migration environment (VME) that can be used for migrating your Microsoft Office Project Server 2003 data to Office Project Server 2007. Office Project Server 2007 VME is a stand-alone environment that can be used only for migration purposes. It can be downloaded from the Microsoft Download Center and can be run on a virtual machine on a Windows Server 2008 R2Hyper-V Server. It also includes many helpful migration scripts that can make the migration process easier. For more information, see Migrate your Project Server 2003 data by using the VME.

Install Project Server 2007

Which computer you install Office Project Server 2007 on is important — read IT deployment options for migration to Project Server 2007 (http://go.microsoft.com/fwlink/p/?LinkId=188765) closely and select an option that is right for you. For more information about how to install, see Deploy Project Server 2007 to a server farm environment (http://go.microsoft.com/fwlink/p/?LinkId=188762). Follow the instructions, install Project Server 2010, and provision a Microsoft Project Web App site to migrate to. For the purposes of this article, we will call that site the "target Project Web Access site."

Important:

This Project Web Access site should be empty —that is, it should not have any projects, users, resources, or other global data.

Note:

Office Project Server 2007 can be installed on the same computer as Project Server 2003. If you want Windows SharePoint Services to take over the Internet Information Services (IIS) virtual server that was hosting Project Server 2003, you have to create several "managed paths" to exclude the Project Web Access virtual directories. For more information, see the Knowledge Base article named How to enable an ASP.NET application to run on a SharePoint virtual server (http://go.microsoft.com/fwlink/p/?LinkID=25292).

When this step is completed, you should have an empty, working Project Web Access site into which you can migrate (the target Project Web Access site alluded to earlier).

Apply updates to Project Server 2007 and Windows SharePoint Services 3.0

When migrating your Project Server 2003 data to Office Project Server 2007, you must apply the following updates to your Office Project Server 2007 environment:

  • Office Project Server 2007 Service Pack 2

  • Windows SharePoint Services 3.0 Service Pack 2

For information about how to apply both service packs, see Deploy Service Pack 2 for Office Project Server 2007 (http://go.microsoft.com/fwlink/p/?LinkId=188768).

We also recommend that you also apply the latest cumulative updates to Office Project Server 2007. For more information about how to apply cumulative updates, see Deploy cumulative updates (Project Server 2007) (http://go.microsoft.com/fwlink/p/?LinkId=188772).

Set up forms-based authentication, if necessary

If you are using Project Server authenticated users (non-Windows users) in Project Server 2003, you will not be immediately able to log on to Office Project Server 2007 with those accounts after migration. Office Project Server 2007 relies on Windows SharePoint Services and ASP.NET forms authentication infrastructure. Therefore, you need to set up forms-based authentication on the Office Project Server 2007 installation — and this is a separate step. For more information, see Plan Project Server 2007 authentication method (http://go.microsoft.com/fwlink/p/?LinkId=188779).

When this step is completed, you should have forms-based authentication enabled and working on the target Project Web Access site.

Back up and restore the Project Server 2003 and Project Server 2007 databases

We recommend that you back up all Project Server 2003 and Office Project Server 2007 databases that are involved in the data migration.

The following databases should be backed up:

  • Project Server 2003 database

  • Office Project Server 2007 databases:

    • Published

    • Reporting

    • Draft

    • Versions

  • Windows SharePoint Services 3.0 configuration and content databases

Once you have created backup copies of the databases that are involved with data migration, you can quickly restart the migration if any non-recoverable problems occur during the migration process. For example, if an error occurs during migration due to a data problem in Project Server 2003, it might corrupt the Office Project Server 2007 database. If the problem is corrected in Project Server 2003, you will have to create a new Office Project Server 2007 Project Web Access site before retrying migration. However, if an Office Project Server 2007 backup is already available, it will not be necessary to recreate a new Project Web Access site. You can simply restore the Office Project Server 2007 databases and retry the migration.

The Office Project Server 2007 configuration and content databases can be backed up in case a non-recoverable problem occurs when you migrate Windows SharePoint Services workspace data to Office Project Server 2007. A pre-migration database backup will assist you in quickly starting over again.

Next, you must decide where to restore the Project Server 2003 database(s).

  • Keep the Project Server 2003 database(s) on a separate computer from the Office Project Server 2007 databases: This is a good idea if the database is large enough that backing up or restoring will take a long time. In this case, you have to manually set up a "linked server" on the Office Project Server 2007 computer that points to the Project Server 2003 computer. For more information, look at the Project2003LinkedSQLServer parameter in the migration configuration file. For more information, see Configure a linked server in SQL Server (Project Server 2010).

  • Restore Project Server 2003 database(s) to the same computer that is hosting the Office Project Server 2007 databases: This is a good idea for optimizing performance — the migration process is faster if the Project Server 2003 database and the Office Project Server 2007 databases are on the same computer.

When this step is completed, you should have all the relevant databases backed up so that you can restore them and quickly restart migration as needed.

Install the migration tool

The migration tool is available on the Microsoft Office Project Professional 2007 installation media. (By default, it is not installed.) The migration tool does not have to be installed on the Project Server computers that are involved in the migration; it only must be able to connect to them over the network. Use the following procedures to install the migration tool.

To install the migration tool (if Office Project Professional 2007 is not installed)

  1. Run Setup on the Office Project Professional 2007 installation CD.

  2. Select the Customize option. (Do not select Install Now).

  3. On the Installation Options tab, expand the feature tree for Microsoft Office Project 2007.

  4. Right-click Migration tool and change its state from Not Available to Run from My Computer.

  5. Click Install Now. The migration tool executable file (P12migrationtool.exe) file is installed to the location that you specify. The default location is as follows: C:\Program Files\Microsoft Office\OFFICE12.

To install the migration tool (if Office Project Professional 2007 is already installed)

  1. In Windows XP, click the Start button, and then click Control Panel.

  2. In Control Panel, double-click Add or Remove Programs.

  3. From the Currently installed programs list, select Office Project Professional 2007, and then click Change.

  4. In the Change your installation of Microsoft Office window that appears, select Add or Remove Features, and then click Continue.

  5. On the Installation Options tab, expand Microsoft Office Project and right-click Microsoft Office Project Upgrader tool. Change the status from Not Available to Run from My Computer.

  6. Click Continue. This action starts the installation of the migration tool, which adds the migration tool executable file (P12migrationtool.exe) to the same location as the Office Project Professional 2007 executable file (WinProj.exe). The default location is as follows: C:\Program Files\Microsoft Office\OFFICE12.

  7. When installation successfully finishes, click Close on the next window that appears.

Apply updates to Project Professional 2007 for the migration tool

You must apply updates to the Office Project Professional 2007 installation on which the migration tool is used. You should apply the following:

  • Office Project Professional 2007 Service Pack 2

  • The latest cumulative update for Office Project Professional 2007 (this should match the date of the cumulative update applied to Office Project Server 2007).


Prepare your Project Server 2010 environment

Published: May 12, 2010

When upgrading data from Microsoft Office Project Server 2003, you must prepare your Microsoft Project Server 2010 environment.

Prepare your Project Server 2010 64-bit environment

If you have installed Microsoft Office Project Server 2007 in a Windows Server 2008 64-bit environment after successfully migrating your data from Project Server 2003, then you simply need to run an in-place upgrade to Project Server 2010. An in place upgrade to Project Server 2010 requires the following:

  • The Windows Server operating system must be Windows Server 2008 R2 (64-bit) or Windows Server 2008 with Service Pack 2 (SP2) (64-bit)

  • The computer running SQL Server used to host the Project Server 2010 data must be either:

    • 64-bit version of SQL Server 2005 Service Pack 2 with Cumulative Update 3

    • 64-bit version of SQL Server 2008 Service Pack 1 with Cumulative Update 2

Prepare your Project Server 2010 environment when migrating from a 32-bit environment

When migrating to Project Server 2010 from an Office Project Server 2007 32-bit environment, you are required to migrate your data by using the database attach method. The database attach method requires a Project Server 2010 installation that the data can be migrated to. (The databases cannot be upgraded in place as the bits are upgraded.) This requires you to install Project Server 2010. For instructions on installing Project Server 2010, see Deploy Project Server 2010 to a server farm environment.

Note:

For more information about Project Server 2010 upgrade methods, see Project Server 2010 upgrade overview.


Pre-migration tasks for migrating your Project Server 2003 data

Published: May 12, 2010

The following articles describe the pre-migration tasks that should be completed before you migrate your Microsoft Office Project Server 2003 data to Microsoft Office Project Server 2007.

  • Data that cannot be migrated to Project Server 2007

  • Migration best practices (Project Server 2010)

  • Configure the migration administrator account (Project Server 2010)

  • Configure a linked server in SQL Server (Project Server 2010)

  • Verify your Project Server 2003 data

  • List the Project Server 2003 database profile

  • Capture a Project Server 2003 data snapshot before migration

  • Validate the Windows SharePoint Services 2.0 Content database

  • Capture the Windows SharePoint Services 2.0 workspaces linked to projects


Data that cannot be migrated to Project Server 2007

Published: May 12, 2010

This article describes data in Microsoft Office Project Server 2003 that is not migrated at all or that requires attention when being migrated to Microsoft Office Project Server 2007.

Project Server 2003 data that is not migrated

Project Server 2003 item not migrated Comment

Outstanding status updates

Outstanding status updates are not migrated if the StopProjectUpdatesIfUpdatesPending setting in the migration configuration file is set to Yes (which is the default option). It is a best practice to make project managers accept or reject project status updates before running the migration tool.

Timesheet history

Timesheet history data is not migrated. Timesheet data in the following tables is not migrated:

  • MSP_WEB_WORK

  • MSP_WEB_ADJUSTED

  • MSP_WEB_TRANSACTIONS

However, timesheet periods are migrated. Also, all status data entered by team members (for example, Tom worked eight hours on assignment X), does get migrated. If you have a reporting system based on timesheet history, then your reports will be affected and will need to be redone.

Status reports

Status report definitions and responses are not migrated.

To-do lists

The related feature in Office Project Server 2007 is called project proposals. Project proposal assignments affect resource availability, whereas to-do list assignments in Project Server 2003 do not. If you are manually shifting from to-do lists to project proposals, you need to take this situation into account.

View filters

Each filter in each view that is not upgraded is noted in a log file. These log entries can help the administrator to recreate the filters manually in Office Project Server 2007.

Project versions

Office Project Server 2007 does not have the concept of project versions. The version name from Project Server 2003 is appended to the project name as part of migration. For example, Project1, version 'target', becomes Project1_target after migration. Project2, version 'published', becomes Project2_published after migration.

Status update rules

Not migrated.

Extra tables or fields added to the database

Any extra tables or fields added to the database file by customers or partners are not migrated. They must be manually migrated to Project Server 2010.

Project Web Access links and Saved Links

You must manually create your links to Project Web Access after migration. This includes the Saved Links feature in Project Server 2003.

Project Server 2003 data that is migrated with caveats

Project Server 2003 data Comment

Non-project time

Project Server 2003 administrative projects are migrated as Office Project Server 2007 administrative projects. They are not migrated into the new non-project time infrastructure in Office Project Server 2007.

Security

Security settings are migrated all at once, but the project-to-category mappings are migrated gradually. When projects are gradually migrated, they become part of the migrated categories with which they are associated, and this behavior can be controlled by the FixUpSecurityCategories configuration parameter in the migration configuration file.

For more information on this parameter, see Configure the migration tool (Project Server).

Value lists (for both local and enterprise custom fields)

Migrated as lookup tables

Project Server 2003 users with assignments (not part of the enterprise resource pool)

Migrated as Office Project Server 2007 enterprise resources.

Note:

In Project Server 2003, you can publish projects without saving them as enterprise projects. A non-enterprise mode does not exist in Office Project Server 2007, and users can have assignments only if it is an enterprise resource. Therefore, users with assignments in Project Server 2003 are converted to enterprise resources in Office Project Server 2007, so that the assignment information is not lost.

Alert preferences

Migrated to notifications.

Enterprise resources

Enterprise resource migration is a very important part of migration. Following are examples of conflicts that may occur during enterprise resource migration:

  • Case 1: When a Project 2003 enterprise resource matches with a Project 2007 enterprise resource (by name or Windows NT account):

    1. The Project 2003 enterprise resource is not migrated.

    2. The resource is replaced by the Project 2007 enterprise resource.

  • Case 2: When a Project 2003 enterprise resource matches with a Project 2007 enterprise user (by name or Windows NT account):

    1. The Project 2003 enterprise resource is not migrated.

    2. The resource is converted to a local resource in Project 2007.

  • Case 3: When a Project 2003 local resource matches with a Project 2007 enterprise resource (by name)

    • The local resource is not converted to an enterprise resource.

  • Case 4: When a Project 2003 enterprise resource of type X (say, generic resource) matches with a Project 2007 enterprise resource of type Y (say, a material resource) (by name)

    1. The Project 2003 enterprise resource is not migrated.

    2. The resource is converted to a local resource.

Enterprise resource pool Active Directory group mappings

Mappings from Project Server 2003 security groups to enterprise resource pool Active Directory groups are not migrated to Office Project Server 2007. However, users and resources added by using Project Server 2003 Active Directory synchronization are migrated. After migration, use the migration log file to assist in manually setting up the mappings for Active Directory groups to the enterprise resource pool and Project Server security groups in Office Project Server 2007.

Note:

Synchronizing to an organization unit — while supported in Project Server 2003 — is not supported in Office Project Server 2007. In Office Project Server 2007, you should synchronize with an Active Directory group because there is not a group-member size limitation as there is in Project Server 2003.

Project Server users

If there is a Project Server user in Office Project Server 2007 either with the same name or Windows NT account as a Project Server 2003 user, then the Project Server 2003 user's details (for example, name, e-mail address, security settings) are not migrated. (In other words, the Office Project Server 2007 data prevails in the case of a conflict).


Migration best practices (Project Server 2010)

Published: May 12, 2010

Review this list of best practices to observe when migrating from Microsoft Office Project Server 2003 to Microsoft Office Project Server 2007.

  • Do a pilot migration with a small department. It is sensible to experiment with the process by starting with a small migration rather than a large one.

  • Back up your Project Server 2003 database before migration. This action enables you to easily restart the migration process if an error should occur.

  • Make sure no users are editing project data during migration. The edited data would not be migrated properly.

  • Upgrade Microsoft Windows SharePoint Services data first, and then the projects. If you do not follow this sequence, after migration you will need to republish the projects to get them all linked to their SharePoint sites in Office Project Server 2007.

  • If you have projects that contain subprojects, ensure in the migration configuration file that the subprojects are migrated before the master projects.

  • Set your database recovery model to Simple in Microsoft SQL Server before starting migration. Otherwise, you may run into a situation where the database transaction logs of the Published and Draft databases reach their size limits (because so many projects are being added to the database at once).

  • Migrate and publish all relevant administrative projects first. This ensures that the non-project time is reflected in the Office Project Server 2007 resource availability.

  • Do not delete any migrated Project Server 2007 enterprise resource for the duration of the migration. To illustrate, imagine that such a resource were deleted, and you then migrate a Project Server 2003 project that uses this enterprise resource. The enterprise resource in the migrated project would become a local resource after migration. However, the enterprise resource could be recovered: If you were to add the deleted resource back again (with the same name or Windows NT account) and resave the project, then the project manager would be prompted to replace the local resource with the enterprise resource.

  • Keep the number of projects to migrate below 1000 in each configuration file. Each migration configuration file should not exceed 1000 projects to be migrated at one time.

  • During the migration of projects, publish only the projects with a Published version. Because a given project can have multiple versions but at least one which is called .published, be sure that a project with a version different than .Published is not automatically published during the migration process.


Configure the migration administrator account (Project Server 2010)

Published: May 12, 2010

This article describes how to configure the Migration Administrator account when migrating your Microsoft Office Project Server 2003 data to Microsoft Office Project Server 2007. Configuring the migration administrator account is one of the pre-migration tasks that are required before performing the migration.

When you configure the Migration Administrator account, you must do the following:

  • Give the appropriate permissions to the migration administrator account.

  • Verify that the Migration Administrator account has proper access.

Give appropriate permissions to the Migration Administrator account

The Migration Administrator account is the account with which the migration is run. In other words, the P12migrationtool.exe command-line tool is run under this account. The account needs the following permissions:

  • Database reader permissions on the Project Server 2003 database(s).

  • Administrator permissions on the target Project Web Access site.

    Adding the Migration Administrator account to the default (unaltered) "Administrators" security group should give all relevant permissions. If an enterprise resource with the same name or Windows account exists in Project Server 2003, the Migration Administrator account has to be made an enterprise resource as well.

  • System administrator privileges on the Office Project Server 2007 databases.

    Adding the Migration Administrator account to the "SysAdmin" SQL Server group gives this permission. If the Migration Administrator account is the farm administrator on the Office Project Server 2007 farm, then this permission will already be available.

Verify that the Migration Administrator account has proper access

After installing Office Project Server 2007, you need to verify that your installation is functional before proceeding to migrate data to it. You can do this by performing the following tasks.

To verify that the migration administrator account has proper access

  1. Using the Migration Administrator account, log on to the computer on which you have installed the migration tool.

  2. Navigate to the Office Project Server 2007 version of Microsoft Office Project Web Access. Log on by using the Migration Administrator account and make sure that you can access any page in Office Project Web Access Server Settings. This ensures that when the migration tool tries to add data to Office Project Server 2007 by using the Migration Administrator account, it will succeed.

  3. Start Microsoft Office Project Professional 2007, create a profile with the Migration Administrator account, and then connect to Office Project Server 2007 with that profile.

  4. Create, save, and publish a project. Verify that you do not encounter any errors during this process. Delete the project when you are done.

  5. Open SQL Query Analyzer, connect to the computer running SQL Server that is hosting the Project Server 2003 database(s), and log on using the Migration Administrator account. Verify that you can access data in each Project Server 2003 database.

  6. Open SQL Query Analyzer, connect to the computer running SQL Server that is hosting the Office Project Server 2007 database(s), and log in using the Migration Administrator account. Verify that you have system administrator privileges.


Configure a linked server in SQL Server (Project Server 2010)

Published: May 12, 2010

Configuring a linked server connection in Microsoft SQL Server is done in conjunction with using the Project2003LinkedSQLServer= setting in the migration configuration file. You only need to use this setting and configure the linked server connection when you are migrating a Microsoft Office Project Server 2003 database that cannot be copied and restored on the Microsoft Office Project Server 2007 database server and it must be connected to remotely.

Configure a Linked Server connection using SQL Server 2000

If you are migrating a Project Server 2003 database in SQL Server 2000 to Office Project Server 2007 on another computer, and the database tier for Office Project Server 2007 is SQL Server 2000 as well, use the following procedure to configure a linked server connection.

Configure the connection

  1. Connect to the SQL Server hosting the Office Project Server 2007 databases by using Enterprise Manager.

  2. In the tree structure, click to expand the Security folder.

  3. Right-click Linked Servers, and then click New Linked Server.

  4. Refer to SQL Server documentation for more information on how to create a linked server (search for the term "linked servers"). Make sure you click the Security tab and select the correct security option. (For example, select be made using the login's current security context option button. If this option does not work in your environment, select be made using this security context and give a valid user name and password that works on the computer running SQL Server that is hosting the Project Server 2003 database.)

  5. Verify that the linked server you created functions properly before proceeding with the migration. You should see the linked server you just created under the Linked Servers node. Once you expand the linked server, you should see the Tables and Views nodes. If you click Tables or Views, you should see some entries

  6. Use the name of the linked server as the value for the Project2003LinkedSQLServer= parameter in the migration configuration file.

Note:

In some IT environments, specific ports related to Microsoft Distributed Transaction Coordinator (MSDTC) might need to be opened for the linked server configuration to work. For more information, see the SQL Server documentation about linked servers or contact your system administrator.

Configure a linked server connection from SQL Server 2000 to SQL Server 2005

If you are migrating a Project Server 2003 database in SQL Server 2000 to Office Project Server 2007 on another computer, but the database server being used by Office Project Server 2007 is SQL Server 2005, use the following procedures to configure a linked server connection.

First, in both SQL Server 2000 and SQL Server 2005, set the authentication mode to mixed, so that SQL Server logins are accepted along with Windows logins.

Configure SQL Server 2005 authentication to mixed mode

  1. Open SQL Server 2005 Management Studio.

  2. In the Object Explorer pane, right-clicking the SQL 2005 server name, then click Properties.

  3. In the Select a Page list, click Security.

  4. In the Server Authentication section, select SQL Server and Windows Authentication Mode.

  5. Click OK.

Configure SQL Server 2000 authentication to mixed mode

  1. Open SQL Server Enterprise Manager.

  2. Expand the server group that contains the database server that you will use with Project Server 2003.

  3. Right-click the server, and then click Properties.

  4. Click the Security tab.

  5. Under Authentication, click SQL Server and Windows.

  6. Click OK.

Configure the connection

  1. On the computers running SQL Server 2000 and SQL Server 2005, create an identical SQL authenticated user account to run the linked server connection. Make sure that the password is the same for the accounts on both servers. Ensure that the accounts have read/write access to the databases you intend to access using the linked server system.

  2. In SQL Server 2000, open Query Analyzer and on your master database run a file called instcat.sql. It should be located under your SQL folders in Program Files.

  3. In SQL Server 2005 Management Studio, select your computer running SQL Server 2005, expand Server Objects, right-click Linked Servers, and click New Linked Server.

    1. Enter the server name of your computer running SQL Server 2000.

    2. Select the SQL Server option.

    3. Click the Security tab in the side pane.

    4. Select the Be made using this security context option.

    5. Enter the SQL account and password needed to access the Project Server 2003 databases and Office Project Server 2007 databases (created in step 1).

    6. Click OK.

  4. In SQL Server 2005 Management Studio, launch a query against the linked server to verify that it worked:

    1. SELECT * from <P200Server>.<P11DBName>.dbo.msp_web_admin

    2. Replace the server and database name with appropriate values.

    3. If this query returns successfully, your connection is successful.

Note:

When you run the migration, make sure the user account with which you are running the migration tool has read access to both your Project Server 2003 and Office Project Server 2007 databases.

Configure a linked server connection from SQL Server 2000 to SQL Server 2008

If you are migrating a Project Server 2003 database in SQL Server 2000 to Office Project Server 2007 on another computer, but the database server being used by Office Project Server 2007 is SQL Server 2008, use the following procedures to configure a linked server connection.

First, in both SQL Server 2000 and SQL Server 2008, set the authentication mode to mixed, so that SQL Server logins are accepted along with Windows logins.

Configure SQL Server 2008 authentication to mixed mode

  1. Open SQL Server 2008 Management Studio.

  2. In the Object Explorer pane, right-clicking the SQL 2008 server name, then click Properties.

  3. In the Select a Page list, click Security.

  4. In the Server Authentication section, select SQL Server and Windows Authentication Mode.

  5. Click OK.

Configure SQL Server 2000 authentication to mixed mode

  1. Open SQL Server Enterprise Manager.

  2. Expand the server group that contains the database server that you will use with Project Server 2003.

  3. Right-click the server, and then click Properties.

  4. Click the Security tab.

  5. Under Authentication, click SQL Server and Windows.

  6. Click OK.

Configure the connection

  1. On the computers running SQL Server 2000 and SQL Server 2008, create an identical SQL authenticated user account to run the linked server connection. Make sure that the password is the same for the accounts on both servers. Ensure that the accounts have read/write access to the databases you intend to access using the linked server system.

  2. In SQL Server 2000, open Query Analyzer and on your master database run a file called instcat.sql. It should be located under your SQL folders in Program Files.

  3. In SQL Server 2008 Management Studio, select your computer running SQL Server 2008, expand Server Objects, right-click Linked Servers, and click New Linked Server.

    1. Enter the server name of your computer running SQL Server 2000.

    2. Select the SQL Server option.

    3. Click the Security tab in the side pane.

    4. Select the Be made using this security context option.

    5. Enter the SQL account and password needed to access the Project Server 2003 databases and Office Project Server 2007 databases (created in step 1).

    6. Click OK.

  4. In SQL Server 2008 Management Studio, launch a query against the linked server to verify that it worked:

    1. SELECT * from <P2003Server>.<P11DBName>.dbo.msp_web_admin

    2. Replace the server and database name with appropriate values.

    3. If this query returns successfully, your connection is successful.

Note:

When you run the migration, make sure the user account with which you are running the migration tool has read access to both your Project Server 2003 and Office Project Server 2007 databases.


Verify your Project Server 2003 data
See Also

Published: May 12, 2010

The articles in this section describe how to verify that the Microsoft Office Project Server 2003 source data that you plan to migrate is in a valid state to migrate to Microsoft Office Project Server 2007. They describe useful tools for verifying that the data you plan to migrate is not invalid or corrupt. These include SQL queries included in the pre-migration script A1 to run on your Project Server 2003 databases. It also describes general checks you should do in your Project Server 2003 environment prior to migrating.

To verify your Project Server 2003 data, you must do the following:

  • Run the Office Project Server 2007 pre-migration script A1 on your Project Server 2003 data

  • Fix data issues identified by running the script on your Project Server 2003 data

  • Identify and fix Enterprise Custom fields and Outline Codes with name conflicts

See Also

Concepts

Run the pre-migration script A1 (Project Server 2010)
Fix data issues identified in pre-migration script A1 (Project Server 2010)
Identify and fix Enterprise Custom fields and Outline Codes with name conflicts (Project Server 2010)


Run the pre-migration script A1 (Project Server 2010)

Published: May 12, 2010

Running this script against the Microsoft Office Project Server 2003 database identifies possible errors that will prevent the migration process from completing. This SQL script only reads a database from Project Server 2003 Service Pack 3.

This script identifies the following problems:

  1. Version of Project Server 2003 database (which must be SP3 before the migration)

  2. Projects are checked out

  3. Projects have been externally edited

  4. Projects have status updates pending

  5. Duplicate enterprise resources

  6. Duplicate enterprise resources in projects

  7. Enterprise Global template externally edited

  8. Enterprise Global template checked out

  9. Enterprise Global template locked

  10. Default language is different between the Project tables and the Web tables

  11. Resource has a comma in its name

  12. Required enterprise resource custom fields have no values

  13. Required enterprise resource custom fields have values which are not in the lookup table definition

  14. Enterprise resources externally edited

  15. Enterprise resource duration custom fields have value lists

  16. Enterprise resource duration custom fields have invalid values

Project Server 2007 Pre-Migration Script 1

Copy Code
------------------------------------------------------------------------------
/* Pre-Migration Steps from Project 2003 SP3 to Project 2007 SP2
-----------------------------------------------------------------------------*/
USE Proj2003SourceDB

------------------------------------------------------------------------------
/* Check Project 2003 Version: Must be SP3 = 11.3
-----------------------------------------------------------------------------*/
select replace(str(WADMIN_VERSION_MAJOR)+'.'+str(WADMIN_VERSION_MINOR),' ','')
as 'Project Server Version SP3 Must Be 11.3 or Higher. If not, upgrade your 2003 database to SP3'
from dbo.MSP_WEB_ADMIN
go
------------------------------------------------------------------------------
/* Display the projects checked out?
-----------------------------------------------------------------------------*/
select PROJ_NAME AS 'List of Projects Checked-out: Must be Fixed'
from dbo.MSP_PROJECTS where PROJ_CHECKEDOUT = 1 and PROJ_TYPE in (0, 1)
go
------------------------------------------------------------------------------
/* Display the projects Externally Edited?
-----------------------------------------------------------------------------*/
select PROJ_NAME AS 'List of Projects Externally Edited: Must be Fixed'
from dbo.MSP_PROJECTS where (PROJ_EXT_EDITED = 1 or RESERVED_BINARY_DATA is null) and PROJ_TYPE in (0, 1)
go
------------------------------------------------------------------------------
/* Determining whether projects have status updates pending
-----------------------------------------------------------------------------*/
select distinct PROJ_NAME AS 'List of Projects with Status Updates Pending: Must be Fixed'
from dbo.MSP_WEB_ASSIGNMENTS wa, dbo.MSP_WEB_TRANSACTIONS trans,
dbo.MSP_WEB_PROJECTS wp where wa.WPROJ_ID = wp.WPROJ_ID
and trans.WASSN_ID = wa.WASSN_ID and trans.WTRANS_STATE in (0, 1, 2)
go
------------------------------------------------------------------------------
/* Determining whether there are duplicate Enterprise Resources
-----------------------------------------------------------------------------*/
select res_uid, res_name AS 'Duplicate Enterprise Resources: Must be Fixed' from msp_resources
where res_name in (select distinct r1.RES_NAME from dbo.MSP_RESOURCES r1
inner join dbo.MSP_RESOURCES r2 on (r1.RES_NAME = r2.RES_NAME and r1.PROJ_ID = r2.PROJ_ID)
where r1.PROJ_ID = 1
and r1.RES_UID != r2.RES_UID) and proj_id = 1 order by res_name asc

go
------------------------------------------------------------------------------
/* Determining whether there are duplicate Enterprise Resources
Check for duplicate enterprise resources used in your projects
-----------------------------------------------------------------------------*/
select  distinct res_name AS 'Duplicate Enterprise Resources Used in Projects: Must be Fixed', res_euid
from msp_resources
where res_name in (select distinct r1.RES_NAME from dbo.MSP_RESOURCES r1
inner join dbo.MSP_RESOURCES r2 on (r1.RES_NAME = r2.RES_NAME
and r1.PROJ_ID = r2.PROJ_ID) where r1.PROJ_ID = 1
and r1.RES_UID != r2.RES_UID) and proj_id <> 1 and res_euid is not null
order by res_name, res_euid asc
go

------------------------------------------------------------------------------
/* Enterprise Global template should not be externally edited
-----------------------------------------------------------------------------*/
select PROJ_NAME 'Enterprise Global Template Externally Edited: Must be Fixed' from dbo.MSP_PROJECTS
where (PROJ_EXT_EDITED = 1 or RESERVED_BINARY_DATA is null)
and PROJ_TYPE = 2

go
------------------------------------------------------------------------------
/* Determining whether the Enterprise Global template is checked out
-----------------------------------------------------------------------------*/
select count(*) AS 'Enterprise Global Template Checked Out: Must be Fixed' from dbo.MSP_PROJECTS
where PROJ_CHECKEDOUT = 1 and PROJ_TYPE = 2

go
------------------------------------------------------------------------------
/* Determining whether the Enterprise Global template is locked
-----------------------------------------------------------------------------*/
select cast(isnull(PROJ_LOCKED, '0') as int) AS 'Enterprise Global Template Is Locked: Must be Fixed'
 from dbo.MSP_PROJECTS where PROJ_TYPE = 2

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether the default language on the Web tables database and Project tables database should match
--------------------------------------------------------------------------------------------------------------*/
select WADMIN_DEFAULT_LANGUAGE As 'The Deafault Language on Web and Project Tables should Match: Must be Fixed'
from dbo.MSP_WEB_ADMIN

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether a resource has a comma in its name
--------------------------------------------------------------------------------------------------------------*/
select RES_NAME 'List of Resources With a Comma in the Name: Not Allowed: Must be Fixed'
from MSP_RESOURCES where RES_NAME is not null and charindex(',', RES_NAME) > 0

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether required enterprise resource custom fields do not have values
--------------------------------------------------------------------------------------------------------------*/
declare @eglobal_proj_id int
set @eglobal_proj_id = (select PROJ_ID from dbo.MSP_PROJECTS where PROJ_TYPE = 2)

select
   r1.RES_NAME as 'Resource Name',
   ast1.AS_VALUE as 'Custom Field Name with NO VALUE: Must be Fixed'
from
   dbo.MSP_RESOURCES r1
   inner join dbo.MSP_CODE_FIELDS cf1 on (r1.RES_UID = cf1.CODE_REF_UID)
   inner join dbo.MSP_FIELD_ATTRIBUTES fa1 on (cf1.CODE_FIELD_ID = fa1.ATTRIB_FIELD_ID)
   inner join dbo.MSP_ATTRIBUTE_STRINGS ast1 on (fa1.AS_ID = ast1.AS_ID)
   inner join dbo.MSP_OUTLINE_CODES oc3 on (cf1.CODE_UID = oc3.CODE_UID
   and oc3.PROJ_ID = @eglobal_proj_id)
   left join dbo.MSP_OUTLINE_CODES oc1 on (oc1.CODE_UID = cf1.CODE_UID
   and cf1.CODE_FIELD_ID = oc1.OC_FIELD_ID and oc1.PROJ_ID = @eglobal_proj_id)
   left join (
      select
         oc.CODE_UID,
         fa.ATTRIB_FIELD_ID as OC_FIELD_ID,
         @eglobal_proj_id as PROJ_ID
      from
         dbo.MSP_OUTLINE_CODES oc
         inner join dbo.MSP_FIELD_ATTRIBUTES fa on (fa.PROJ_ID = oc.PROJ_ID
         and fa.ATTRIB_VALUE = oc.OC_FIELD_ID and fa.ATTRIB_ID = 212)
      where
         oc.PROJ_ID = @eglobal_proj_id
         and fa.PROJ_ID = @eglobal_proj_id
         and fa.ATTRIB_ID = 212
   ) as oc2 on (oc2.CODE_UID = cf1.CODE_UID and cf1.CODE_FIELD_ID = oc2.OC_FIELD_ID
   and oc2.PROJ_ID = @eglobal_proj_id)
where
   r1.PROJ_ID = 1
   and cf1.proj_id = 1
   and fa1.PROJ_ID = @eglobal_proj_id
   and fa1.ATTRIB_ID = 206
   and ast1.PROJ_ID = @eglobal_proj_id
   and oc3.PROJ_ID = @eglobal_proj_id
   and oc1.CODE_UID is null
   and oc2.CODE_UID is null
order by
   r1.RES_NAME,
   ast1.AS_VALUE

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether a resource custom field has a value which is not in the lookup table definition
--------------------------------------------------------------------------------------------------------------*/
declare @eglobal_proj_id int
set @eglobal_proj_id = (select PROJ_ID from dbo.MSP_PROJECTS where PROJ_TYPE = 2)

select
   r1.RES_NAME AS 'Resource Name',
   ast1.AS_VALUE AS 'Custom Field Name with Invalid Value: Must be Fixed'
from
   dbo.MSP_RESOURCES r1
   inner join dbo.MSP_CODE_FIELDS cf1 on (r1.RES_UID = cf1.CODE_REF_UID)
   inner join dbo.MSP_FIELD_ATTRIBUTES fa1 on (cf1.CODE_FIELD_ID = fa1.ATTRIB_FIELD_ID)
   inner join dbo.MSP_ATTRIBUTE_STRINGS ast1 on (fa1.AS_ID = ast1.AS_ID)
   left join dbo.MSP_OUTLINE_CODES oc1 on (oc1.CODE_UID = cf1.CODE_UID
   and cf1.CODE_FIELD_ID = oc1.OC_FIELD_ID and oc1.PROJ_ID = @eglobal_proj_id)
   left join (
      select
         oc.CODE_UID,
         fa.ATTRIB_FIELD_ID as OC_FIELD_ID,
         @eglobal_proj_id as PROJ_ID
      from
         dbo.MSP_OUTLINE_CODES oc
         inner join dbo.MSP_FIELD_ATTRIBUTES fa on (fa.PROJ_ID = oc.PROJ_ID
         and fa.ATTRIB_VALUE = oc.OC_FIELD_ID and fa.ATTRIB_ID = 212)
      where
         oc.PROJ_ID = @eglobal_proj_id
         and fa.PROJ_ID = @eglobal_proj_id
         and fa.ATTRIB_ID = 212
   ) as oc2 on (oc2.CODE_UID = cf1.CODE_UID and cf1.CODE_FIELD_ID = oc2.OC_FIELD_ID
   and oc2.PROJ_ID = @eglobal_proj_id)
where
   r1.PROJ_ID = 1
   and cf1.proj_id = 1
   and cf1.code_uid is not null
   and fa1.PROJ_ID = @eglobal_proj_id
   and fa1.ATTRIB_ID = 206
   and ast1.PROJ_ID = @eglobal_proj_id
   and oc1.CODE_UID is null
   and oc2.CODE_UID is null
union
select
   r1.RES_NAME,
   ast1.AS_VALUE
from
   dbo.MSP_RESOURCES r1
   inner join dbo.MSP_MV_FIELDS cf1 on (r1.RES_UID = cf1.CODE_REF_UID)
   inner join dbo.MSP_FIELD_ATTRIBUTES fa1 on (cf1.CODE_FIELD_ID = fa1.ATTRIB_FIELD_ID)
   inner join dbo.MSP_ATTRIBUTE_STRINGS ast1 on (fa1.AS_ID = ast1.AS_ID)
   left join dbo.MSP_OUTLINE_CODES oc1 on (oc1.CODE_UID = cf1.CODE_UID
   and (cf1.CODE_FIELD_ID - 76) = oc1.OC_FIELD_ID and oc1.PROJ_ID = @eglobal_proj_id)
   left join (
      select
         oc.CODE_UID,
         fa.ATTRIB_FIELD_ID as OC_FIELD_ID,
         @eglobal_proj_id as PROJ_ID
      from
         dbo.MSP_OUTLINE_CODES oc
         inner join dbo.MSP_FIELD_ATTRIBUTES fa on (fa.PROJ_ID = oc.PROJ_ID
         and fa.ATTRIB_VALUE = oc.OC_FIELD_ID and fa.ATTRIB_ID = 212)
      where
         oc.PROJ_ID = @eglobal_proj_id
         and fa.PROJ_ID = @eglobal_proj_id
         and fa.ATTRIB_ID = 212
   ) as oc2 on (oc2.CODE_UID = cf1.CODE_UID and (cf1.CODE_FIELD_ID - 76) = oc2.OC_FIELD_ID
   and oc2.PROJ_ID = @eglobal_proj_id)
where
   r1.PROJ_ID = 1
   and cf1.proj_id = 1
   and cf1.code_uid is not null
   and fa1.PROJ_ID = @eglobal_proj_id
   and fa1.ATTRIB_ID = 206
   and ast1.PROJ_ID = @eglobal_proj_id
   and oc1.CODE_UID is null
   and oc2.CODE_UID is null
order by
   r1.RES_NAME,
   ast1.AS_VALUE

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether Enterprise resources are externally edited
--------------------------------------------------------------------------------------------------------------*/
select count(*) AS 'Number of Enterprise Resources Externally Edited: Must be Fixed'
from dbo.MSP_RESOURCES
where PROJ_ID = 1 and  cast(EXT_EDIT_REF_DATA as varchar(1)) = '1'

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether There are Enterprise Resource Duration Custom Fields with Value Lists
--------------------------------------------------------------------------------------------------------------*/
declare @proj_id int
set @proj_id = (select proj_id from msp_projects where proj_type = 2)
select ats.as_value as 'Enterprise Resource Duration Custom Field with Value Lists: Must be Fixed'
from msp_attribute_strings ats
inner join msp_field_attributes fa on (fa.proj_id = ats.proj_id and fa.as_id = ats.as_id)
where fa.attrib_id = 206 and fa.proj_id = @proj_id
and fa.attrib_field_id >= 205521382 and fa.attrib_field_id <= 205521391
and exists (select * from msp_field_attributes fa2
where fa2.proj_id = fa.proj_id and fa2.attrib_field_id = fa.attrib_field_id
and fa2.attrib_id = 210)

go
---------------------------------------------------------------------------------------------------------------
/* Determining whether Enterprise Resource Duration custom fields contain valid values
--------------------------------------------------------------------------------------------------------------*/
select r.res_name AS 'Resource Name'
, mas.as_value AS 'Enterprise Resource Duration Custom Field with Invalid Value: Must be Fixed'
 from msp_resources r
inner join msp_duration_fields df on (df.dur_ref_uid = r.res_euid and df.proj_id = r.proj_id)
inner join msp_projects p on (p.proj_type = 2)
inner join msp_field_attributes fa on (fa.proj_id = p.proj_id and fa.attrib_field_id = df.dur_field_id)
inner join msp_attribute_strings mas on (mas.proj_id = p.proj_id and fa.as_id = mas.as_id)
where (dur_value < 0 or dur_value > 34689600) and df.proj_id = 1 and p.proj_type = 2
and fa.attrib_id = 206

go


Fix data issues identified in pre-migration script A1 (Project Server 2010)

Published: May 12, 2010

After you run the pre-migration script A1 on your Microsoft Office Project Server 2003 data, check the output of the script for problems that might exist. This article describes methods of resolving issue with the data that are identified in the output. This includes:

  • Projects that are checked out

  • Project that have been edited externally

  • Projects that have status updates pending

  • Duplicate enterprise resources

  • Product version of Project Server 2003 should be at least Service Pack 2a

  • Duplicate enterprise resources in projects

  • The Enterprise Global template has been externally edited

  • The Enterprise Global template has been checked out

  • The Enterprise Global template is locked

  • The default language of the Web tables database and Project tables database should match

  • Enterprise resources should not have commas in their names

  • Required enterprise resource custom fields do not have values

  • Required enterprise resource custom fields have values which are not in the lookup table definition

  • Enterprise Resources have been externally edited

  • Enterprise resource duration custom fields have value lists

  • Enterprise resource duration custom fields have invalid values

After resolving data issues as prescribed in this section, rerun the pre-migration script A1 to verify that the data issues have been resolved.

Project that are checked out

A project cannot be migrated if it is checked-out. It is a best practice before any migration to get the source data to a stable state—consciously checking in projects ensures that a project is in a stable state for being migrated. Migration coordinators could set a deadline for Project Managers to check in their projects by a certain date, and beyond that date can force a check-in of all projects.

How to fix the problem

Check in all projects that are checked out.

Check in projects that are checked out in Project Server 2003

  1. In Microsoft Office Project Server 2003 Project Web Access, click Admin.

  2. Click Manage Enterprise Features.

  3. Click Check in Enterprise Projects and see which projects are checked out. Coordinate its check-in or do a forced check-in operation from Project Web Access.

Note:

You can also test for checked-out projects by running the following SQL query in the "Project Server 2003 Project tables" and "Project Server 2003 Web Tables" databases.

select PROJ_NAME from dbo.MSP_PROJECTS where PROJ_CHECKEDOUT = 1 and PROJ_TYPE in (0, 1)

If any results are returned, then the projects referred to are checked out.

Projects that have been edited externally

A project cannot be migrated if it has been externally edited.

How to fix the problem

Open the externally edited project in Project Professional 2003, save it, and check it back in to the server. This action should set the Externally edited flag to false.

Project that have status updates pending

By default, if Project Server 2003 projects have pending updates, they will not migrate to Project Server 2007. Before you migrate, we recommend that your users accept or reject status updates to ensure that projects are in a stable state to migrate.

How to fix the problem

The StopProjectMigrationIfStatusUpdatesPending parameter in the migration configuration file can be configured to allow the migration of projects with pending updates. For more information about this parameter, see Configure the migration tool (Project Server).

As a pre-migration best practice, you could set a deadline for project managers to accept or reject pending status updates by a certain date. Beyond that date you could then force-migrate all projects (even if status updates are not up-to-date).

Duplicate enterprise resources

Having multiple resources in the enterprise resource pool with the same name is not supported in Project Server 2003 or Project Server 2007. If this situation occurs, it might be the result of direct database edits. Note that the duplicate names may not appear in Project Professional when you are editing the Enterprise Resource Pool. This occurs because there might be just one entry in the MSP_WEB_RESOURCES table for an enterprise resource with this name. There is no simple way to resolve this situation. Work with your Project Server expert to resolve it. Following are some guidelines to help you check for and fix issues that occur with duplicate enterprise resources.

Identifying duplicate enterprise resources

The pre-migration script A1 identifies duplicate enterprise resources if they are contained in your data. If the script finds any duplicate enterprise resources, the data will be displayed similarly to the following example of two duplicate resources:

RES_UID | RES_NAME | RES_EUID
123 | Peter Krebbs | 123
124 | Peter Krebbs | 123
125 | Brad Sutton | 125
126 | Brad Sutton | 126

Identify duplicate enterprise resources used in your projects

The pre-migration script A1 identifies duplicate enterprise resources if they are contained in your data. If the script finds any duplicate enterprise resources, the data will be displayed similarly to the following example of two duplicate resources:

RES_NAME | RES_EUID
Peter Krebbs | 123
Brad Sutton | 125
Brad Sutton | 126

Fix projects that use duplicate enterprise resources

Running the following query (query 1) returns project IDs that are associated with duplicate enterprise resources. You need to eliminate this kind of duplication such that only one "res_name, res_euid" combination is ever used in your projects. If duplicates exist, you must designate one of the duplicates as the "correct" resource and make sure all projects use this resource. (Update the MSP_RESOURCES.RES_EUID column for that project to point it to the enterprise resource you have designated as the correct one.) After doing this, run script A1 to repeat your verification test for duplicate enterprise resources used in projects.

Query 1:

select res_name,  res_euid, proj_id from msp_resources where res_name in (select distinct r1.RES_NAME from dbo.MSP_RESOURCES r1 inner join dbo.MSP_RESOURCES r2 on (r1.RES_NAME = r2.RES_NAME and r1.PROJ_ID = r2.PROJ_ID) where r1.PROJ_ID = 1 and r1.RES_UID != r2.RES_UID) and proj_id <> 1 and res_euid is not null order by res_name, res_euid asc

For example, let's say that running Query 1 returns the following results:

RES_NAME | RES_EUID | PROJ_ID
Brad Sutton | 125 | 12
Brad Sutton | 126 | 13
Brad Sutton | 125 | 14

To fix the situation, you could choose 'Brad Sutton' with RES_EUID=125 as the "correct" enterprise resource and fix the rows as follows:

RES_NAME | RES_EUID | PROJ_ID
Brad Sutton | 125 | 12
Brad Sutton | 125 | 13
Brad Sutton | 125 | 14

Fix the duplicate enterprise resources to point to the correct one

In the previous section you designated a correct resource among the duplicates and fixed the projects to point to it. Now, you must change the MSP_RESOURCES table in accordance with the resource you have designated. Run Query 4 (which is the same as Query 1) to get a list of the duplicate enterprise resources. Then update the RES_EUID column for the duplicate resource to point it to the resource you have designated as the correct one.

Query 4:

select res_uid, res_name, res_euid from msp_resources where res_name in (select distinct r1.RES_NAME from dbo.MSP_RESOURCES r1 inner join dbo.MSP_RESOURCES r2 on (r1.RES_NAME = r2.RES_NAME and r1.PROJ_ID = r2.PROJ_ID) where r1.PROJ_ID = 1 and r1.RES_UID != r2.RES_UID) and proj_id = 1 order by res_name asc

For example, let's say that running Query 4 returns the following results. The 'Peter Krebbs' row is correct. 'Brad Sutton' needs to be corrected.

RES_UID | RES_NAME | RES_EUID
123 | Peter Krebbs | 123
124 | Peter Krebbs | 123
125 | Brad Sutton | 125
126 | Brad Sutton | 126

To fix the situation, you could choose 'Brad Sutton' with RES_UID=125 as the "correct" resource and update the other row to point to that item. For example:

RES_UID | RES_NAME | RES_EUID
123 | Peter Krebbs | 123
124 | Peter Krebbs | 123
125 | Brad Sutton | 125
126 | Brad Sutton | 125

Remove the duplicate resource from the Enterprise Resource Pool

You can remove a duplicate resource from the Enterprise Resource Pool by pointing the duplicate resource to a bogus project (PROJ_ID = maximum integer value). In addition, we also need to clean up the related enterprise calendars. Run Query 5 to do this.

Query 5:

update msp_resources set proj_id=2147483647 WHERE res_uid != res_euid and res_euid is not null and res_uid > 0 and proj_id = 1

update msp_calendars set proj_id=2147483647 WHERE res_uid not in (select res_uid from msp_resources where proj_id=1) and proj_id = 1 and cal_uid > 0 and res_uid is not null

After completing the preceding steps, attempt to run the migration tool with the -verify option again to verify that the duplicate resource problem is resolved.

Project version should be at least 'Project Server 2003 SP2a'

Microsoft supports migration from Project Server 2003 SP2a or SP3. If you do not have at least service pack 2a installed, you will need to apply one of them (we recommend the latest, Service Pack 3).

How to fix the problem

Apply Project Server 2003 SP3 to your Project Server 2003 installation. For more information about Project Server 2003 SP3, see the knowledge base article Description of Project Server 2003 Service Pack 3 (http://go.microsoft.com/fwlink/p/?LinkId=188720).

The Enterprise Global template has been externally edited

The 'Externally Edited' flag is set to true when the Enterprise Global template is edited outside of Project (for example, by a third-party application). Project Professional will check for this flag: If it is set to true, Project Professional recalculates all data in the Enterprise Global template to ensure consistency. Set this flag to false to enable migration.

How to fix the problem

Open the Enterprise Global in Project Professional and save it back to the server.

The Enterprise Global template is checked out

The Enterprise Global template should not be checked out when you are migrating your projects.

How to fix the problem

Make sure that the Enterprise Global is checked in.

  1. In Project Server 2003 Project Web Access, click Admin.

  2. Click Manage Enterprise Features.

  3. Click Check in Enterprise Projects, and see who has checked out the Enterprise Global. Coordinate its check-in or do a forced check-in operation from Project Web Access.

Determining whether the Enterprise Global template is locked

A project becomes locked if the computer shuts down abnormally, or if Project Professional exits abnormally. If the Enterprise Global template is locked, the migration tool cannot run.

How to fix the problem

The following SQL query unlocks the Enterprise Global Template. Run the following SQL query in the "Project Server 2003 Project tables" database .

Update MSP_PROJECTS set PROJ_LOCKED = 1 where PROJ_TYPE = 2

Determining whether the default language on the Web tables database and Project tables database should match

The default language on the Project Server 2003 Web Tables database and the Project Server 2003 Project tables database must match prior to migration.

How to fix the problem

Work with your administrator to correct the inconsistent state between the two databases.

Determining whether a resource has a comma in its name

It is a limitation of Project Server 2007 that an Enterprise Resource (of any language) cannot have a comma character (,) in its name. The character must be replaced with a valid character.

How to fix the problem

Run the following SQL query in the "Project Server 2003 Project tables" and the "Project Server 2003 Web tables" databases. It replaces the comma character with an underscore character. If you want to use a different valid character, you can edit the query.

-- run this against the project tables db

declare @replacement_char char

declare @char_to_replace char

set @replacement_char = '_'

set @char_to_replace = ','

update dbo.MSP_RESOURCES set RES_NAME = replace(RES_NAME, @char_to_replace, @replacement_char)

where RES_NAME is not null and charindex(@char_to_replace, RES_NAME) > 0

-- run this against the web tables db

declare @replacement_char char

declare @char_to_replace char

set @replacement_char = '_'

set @char_to_replace = ','

update dbo.MSP_WEB_RESOURCES set RES_NAME = replace(RES_NAME, @char_to_replace, @replacement_char)

where RES_NAME is not null and charindex(@char_to_replace, RES_NAME) > 0

Required enterprise resource custom fields do not have values

Any enterprise resource that does not have a value for a required enterprise custom field (like the RBS), will fail to migrate. It will post an error in the migration log during migration. We recommend that you check for this scenario before migration. If your enterprise resources are very old (created before the custom field was made 'Required') or inactive, they might not have values for the required custom field.

How to fix the problem

In Project Server 2003, open the enterprise resource pool and set values for the required custom fields or set the affected custom fields as 'Not Required'. You can then change them back manually in Office Project Server 2007 after they are migrated.

Resource custom field has a value which is not in the lookup table definition

A resource custom field's values must all be in the lookup definition table.

How to fix the problem

The following SQL query sets invalid resource custom field values to null. Run the following SQL query in the "Project Server 2003 Project tables" databases.

declare @eglobal_proj_id int

set @eglobal_proj_id = (select PROJ_ID from dbo.MSP_PROJECTS where PROJ_TYPE = 2)

update dbo.MSP_MV_FIELDS

set

   CODE_UID = NULL

from dbo.MSP_MV_FIELDS cf1

   left join dbo.MSP_OUTLINE_CODES oc1 on (oc1.CODE_UID = cf1.CODE_UID and (cf1.CODE_FIELD_ID - 76) = oc1.OC_FIELD_ID and oc1.PROJ_ID = @eglobal_proj_id)

   left join (

      select

         oc.CODE_UID,

         fa.ATTRIB_FIELD_ID as OC_FIELD_ID,

         @eglobal_proj_id as PROJ_ID

      from

         dbo.MSP_OUTLINE_CODES oc

         inner join dbo.MSP_FIELD_ATTRIBUTES fa on (fa.PROJ_ID = oc.PROJ_ID and fa.ATTRIB_VALUE = oc.OC_FIELD_ID and fa.ATTRIB_ID = 212)

      where

         oc.PROJ_ID = @eglobal_proj_id

         and fa.PROJ_ID = @eglobal_proj_id

         and fa.ATTRIB_ID = 212

   ) as oc2 on (oc2.CODE_UID = cf1.CODE_UID and (cf1.CODE_FIELD_ID - 76) = oc2.OC_FIELD_ID and oc2.PROJ_ID = @eglobal_proj_id)

where

   cf1.proj_id = 1

   and oc1.CODE_UID is null

   and oc2.CODE_UID is null

update dbo.MSP_CODE_FIELDS

set

   CODE_UID = NULL

from dbo.MSP_CODE_FIELDS cf1

   left join dbo.MSP_OUTLINE_CODES oc1 on (oc1.CODE_UID = cf1.CODE_UID and cf1.CODE_FIELD_ID = oc1.OC_FIELD_ID and oc1.PROJ_ID = @eglobal_proj_id)

   left join (

      select

         oc.CODE_UID,

         fa.ATTRIB_FIELD_ID as OC_FIELD_ID,

         @eglobal_proj_id as PROJ_ID

         from

         dbo.MSP_OUTLINE_CODES oc

         inner join dbo.MSP_FIELD_ATTRIBUTES fa on (fa.PROJ_ID = oc.PROJ_ID and fa.ATTRIB_VALUE = oc.OC_FIELD_ID and fa.ATTRIB_ID = 212)

      where

         oc.PROJ_ID = @eglobal_proj_id

         and fa.PROJ_ID = @eglobal_proj_id

         and fa.ATTRIB_ID = 212

   ) as oc2 on (oc2.CODE_UID = cf1.CODE_UID and cf1.CODE_FIELD_ID = oc2.OC_FIELD_ID and oc2.PROJ_ID = @eglobal_proj_id)

where

   cf1.proj_id = 1

   and oc1.CODE_UID is null

   and oc2.CODE_UID is null

update dbo.MSP_PROJECTS set PROJ_EXT_EDITED = 1, PROJ_EXT_EDITED_CODE = 1 where PROJ_ID = 1

Enterprise resources have been externally edited

In order for enterprise resources to be migrated from Project Server 2003 to Project Server 2007, they must not be externally edited.

How to fix the problem

To fix the problem, you need to first set all the Enterprise Resources as externally edited. This can be done through an SQL query. You can then make a change to each Enterprise Resource so that all relevant refreshes are done by Project Professional when the Enterprise Resource Pool is saved. This action removes the "externally edited" flag for each Enterprise resource. If an enterprise resource is not changed, no recalculations are done by Project Professional to that resource. That specific enterprise resource continues to be flagged as externally edited, and the Enterprise Resource Pool will not migrate.

Note:

After the Enterprise Resource Pool is migrated, the changes you made to each Enterprise Resource can be removed.

You can use the following general workaround to remove all externally edited flags from your Enterprise Resources.

  1. Set all enterprise resources to be externally edited. You can do this by running the following SQL query in the "Project Server 2003 Project tables" databases.

    Update dbo.MSP_RESOURCES set EXT_EDIT_REF_DATA = 1 where PROJ_ID = 1

    Update dbo.MSP_PROJECTS set PROJ_EXT_EDITED = 1, PROJ_EXT_EDITED_DATE = 1, PROJ_EXT_EDITED_DUR = 1, PROJ_EXT_EDITED_NUM = 1, PROJ_EXT_EDITED_FLAG = 1, PROJ_EXT_EDITED_CODE = 1, PROJ_EXT_EDITED_TEXT = 1 where PROJ_ID = 1

  2. Temporarily add an inconsequential resource custom field to each Enterprise Resource to force recalculations to be done by Project Professional 2003. The forced recalculations will mark each Enterprise Resource as no longer externally edited. As an example, in Project Professional 2003 you can create a 'test' resource custom field that will be added to each Enterprise Resource. You can use any custom field type. For example, you can use a Resource Duration custom field, which is seldom used.

    Note:

    If you use an Enterprise Resource Duration custom field, do not create a value list for it. Enterprise Resource Duration custom fields with value lists will not migrate. When creating this temporary custom field, use a numeric value.

    You can name the new custom field "Test Resource CF". After creating the "Test Resource CF" custom field, open the Enterprise Resource Pool and add the "Test Resource CF" column. Set a valid value for this custom field for all resources. Save the Enterprise Resource Pool and perform the migration. After migration, remove the "Test Resource CF" custom field in Microsoft Office Project Professional 2007.

Enterprise Resource Duration custom fields with value lists

Enterprise Resource Duration custom fields with associated value lists will cause migration to fail.

How to fix the problem

To fix the problem, you must manually remove all values lists from each Enterprise Resource Duration custom field found in the SQL query. You can do this using the following procedure.

  1. Open Project Professional 2003 connected to the Project Server 2003 server.

  2. On the Tools menu, point to Enterprise Options, and then click Open Enterprise Global.

  3. On the Microsoft Project - Checked-out Enterprise Global page, on the Tools menu, point to Customize, and then click Enterprise Fields.

  4. On the Custom Enterprise Fields page, in the Custom Fields tab, in the Fields section, click Resource.

  5. In the Type drop-down list, click Duration. All Enterprise Duration custom fields will appear in the Field list.

  6. In the Field list, select the first Enterprise Resource Duration custom field that matches the ones returned by the SQL query you ran previously. In the Custom Attributes section, click the Value List button. In the value list for the specific Enterprise Duration custom field, delete any values in the Value column, and then click OK. On the Microsoft Office Project dialog box that appears, click OK.

  7. On the Customize Enterprise Fields page, in the Custom Attributes section, verify that Value List is not selected for the Enterprise Resource Duration custom field selected in the Field list. If Value List is selected, select None.

  8. In the Field list, select all remaining Enterprise Resource Duration custom fields that correspond to the SQL query and repeat steps 6 and 7.

  9. Click OK.

Enterprise Resource Duration custom fields contain valid values

Project Server 2010 does not allow negative duration values or duration values greater than 34689600. If you attempt to migrate Project Server 2003 Enterprise Resource Duration custom fields which contain either, your migration will fail.

How to fix the problem

To fix the problem, you must manually edit the Enterprise Resource Duration custom field value for each of the custom fields identified. You need to ensure that the field values are valid (between 0 and 34689600).

If the field identified by the query is a simple custom field (not a formula field), you can change the field value to fall within the allowed range. If the field identified by the query is a formula field, you will have to alter the formula to make sure that the results fall within the valid range.


Identify and fix Enterprise Custom fields and Outline Codes with name conflicts (Project Server 2010)

Published: May 12, 2010

There are certain custom fields and lookup tables name that are reserved in both Microsoft Office Project Server 2007 and Microsoft Project Server 2010. If any of these names are used in the current Project Server 2003 database, the custom fields and outline codes must be changed in Project Server 2003 before proceeding further with the migration. Use Microsoft Office Project Professional 2003 connected to a Project Server 2003 instance to look for reserved names, and take corrective action if necessary.

Reserved outline code names

Outline Code Name | Type | Office Project Server 2007 | Project Server 2010
Cost Type | Resource | X | X
Health | Task | X | X
State | Project | X | X
Team Name | Resource | X | X
Department |  |  | X
Flag Status |  |  | X

Reserved custom field names

Custom field name | Type | Office Project Server 2007 | Project Server 2010
Cost Type | Resource | X | X
Health | Task | X | X
State | Project | X | X
Team Name | Resource | X | X
Sample Approved Finish Date | Project |  | X
Sample Approved Start Data | Project |  | X
Sample Areas Impacted | Project |  | X
Sample Assumptions | Project |  | X
Sample Business Need | Project |  | X
Sample Compliance Proposal | Project |  | X
Flag Status | Task |  | X
Sample Goals | Project |  | X
Sample Post-Implementation Review Date | Project |  | X
Sample Post-Implementation Review Notes | Project |  | X
Sample Primary Objectives | Project |  | X
Project Departments | Project |  | X
Project Impact | Project |  | X
Sample Proposal Cost | Project |  | X
Sample Proposed Finish Date | Project |  | X
Sample Proposed Start Date | Project |  | X
Relative Importance | Project |  | X
Resource Departments | Resource |  | X


List the Project Server 2003 database profile

Published: May 12, 2010

You can run the Microsoft Office Project Server 2003 profile script A2 to capture statistics about the database that you plan on migrating. This script's output will provide information about:

  • Size of the databases (Project Tables and Web Tables databases)

  • Number of projects

  • Number of inserted projects

  • Number of cross-project links

  • Number of tasks

  • Number of assignments

  • Number of Enterprise resources

  • Number of custom fields in use

  • Number of Project-authenticated users

  • Number of Windows-authenticated users

  • Number of security groups

  • Number of security categories

  • If there is Windows SharePoint Services integration

  • Number of linked issues

  • Number of linked risks

  • Number of linked documents

  • Number of custom Project Web Access views

You must enter the name of your Project Tables database and of your Web Tables database in the USE statements in the script.

Project Server 2003 profile script A2

Copy Code
/*-----------------------------------------------------------------------------------------------------------
Script A2: Project Server 2003 Database Profile
This script reads the Project Server 2003 database (Project Tables and View Tables may be in the same or separate database)
-------------------------------------------------------------------------------------------------------------*/
use <Enter "Project Tables" database name>

--Total size of DB
exec sp_spaceused

--Number of projects in the database
select count(*) as 'Total Number of Projects in 2003' from msp_projects

--Number of inserted projects
select count(*) as 'Number of Inserted Projects in 2003'
  from MSP_TEXT_FIELDS where TEXT_FIELD_ID = 188743706

--Number of cross-project links
select count(*) as 'Number of cross-project links in 2003'
  from MSP_TEXT_FIELDS
  where TEXT_FIELD_ID = 239075346 or TEXT_FIELD_ID = 239075347

--Number of total tasks, assignments in the system
select count(*) as 'Number of tasks in 2003' from msp_tasks
select count(*) as 'Number of assignments in 2003' from msp_assignments

--Number of Enterprise resources (in ResGlobal)
select count(*) as 'Number of Enterprise Resources in 2003'
  from msp_resources where proj_id = 1 and res_name is not null

--Number of custom fields in use
select count(*) as 'Number of Custom Fields in use in 2003'
  from msp_field_attributes
  where attrib_id = 206 and proj_id in (select proj_id
  from msp_projects where proj_type =2 )

/*-----------------------------------------------------------------------------------------------------------
This script reads the Project Server 2003 database (Project Tables and View Tables may be in the same or separate database)
-------------------------------------------------------------------------------------------------------------*/

use <Enter "Web Tables" database name>

--Total size of DB
exec sp_spaceused

--Number of Project Authenticated users, Windows authenticated users
select count(*) as 'Number of Project Authenticated users in 2003'
  from MSP_WEB_RESOURCES
  where WRES_USE_NT_LOGON = 0
  and WRES_CAN_LOGIN <>0 and WRES_COUNT_LICENSE <> 0
select count(*) as 'Number of Windows Authenticated users in 2003'
  from MSP_WEB_RESOURCES
  where WRES_USE_NT_LOGON <> 0
  and WRES_CAN_LOGIN <>0 and WRES_COUNT_LICENSE <> 0

--Number of security groups, security categories
select count(*) as 'Number of Security Groups in 2003'
  from MSP_WEB_SECURITY_GROUPS
select count(*) as 'Number of Security Categories in 2003'
  from MSP_WEB_SECURITY_CATEGORIES

--Is there any Windows SharePoint Services integration?
select count(*)  as 'Is there any Windows SharePoint Services Integration in 2003?'
  from msp_web_admin where WADMIN_CURRENT_STS_SERVER_ID <> -1

--Number of linked issues, risks, documents
-- (indicates how much Windows SharePoint Services integration is used)
select count(*) as
  'Number of linked Windows SharePoint Services issues/risks/documents in 2003'
  from MSP_WEB_OBJECT_LINKS

--Number of custom Project Web Access views
select count(*) as 'Number of customer Project Web Access views in 2003'
  from MSP_WEB_VIEW_REPORTS where WVIEW_ID > 100


Capture a Project Server 2003 data snapshot before migration

Published: May 12, 2010

In this step, run Script 3 to take a data snapshot of the Microsoft Office Project Server 2003 database from the Projects and Tasks tables and then stored in a table created dynamically within the script. Prior to running the script, instruct your SQL DBA to create a database that will be used to store several data validation tables and content used to validate the success of the migration downstream.

  1. Have the SQL DBA create a database and provide its name.

  2. Run the script after updating the two USE statements to point to the database created in step 1 and the database name of the Project Server 2003 database that is ready for migration.

Script 3

Copy Code
/*---------------------------------------------------------------------------------------
-- Script A3: Capture Data Validation Snapshot for Project Server 2003 ---- Updated Jan 10, 2010
-- This script:
-- 1. drops the PS2003 Validation Snapshot table if it exists from the Migration Validation
      Database previously created
   2. Reads the Project Server 2003 SP2a database to extract Projects and Tasks information
   3. Stores the output dataset into a new table created in the Migration Validation
      Database
   This script requires to set the database names of the Migration Validation Database and the
   Project Server 2003 database in the USE statements
 ----------------------------------------------------------------------------------------------*/
USE ProjectServer_Migration_Data_Validation
IF EXISTS (SELECT id FROM dbo.sysobjects WHERE id = OBJECT_ID(N'MIgration_PS2003_Data_Validation_Snapshot')
AND OBJECTPROPERTY(id, N'IsUserTable') = 1)
DROP TABLE dbo.Migration_PS2003_Data_Validation_Snapshot
GO
USE [Proj2003SourceDB]
GO
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO
SELECT p11p.proj_name as N'Project Name',
   p11p.proj_id as 'Project ID',
   p11p.proj_version as N'Project Version',
   p11p.proj_info_start_date as N'Proj Start Date',
   p11p.proj_info_finish_date as N'Proj Finish Date',
   p11p.proj_info_status_date as N'Proj Status Date',
   p11p.proj_info_cal_name as N'Proj Calendar Name',
       p11t.task_name as N'Task Name',
       p11t.task_uid as N'Task UID',
       p11t.task_type as N'Task Type',
       p11t.task_start_date as N'Task Start Date',
       p11t.task_finish_date as N'Task Finish Date',
p11t.task_act_start as N'Task Act Start',
p11t.task_act_finish as N'Task Act Finish',
p11t.task_constraint_date as N'Task Constraint Date',
p11t.task_deadline as N'Task Deadline',
p11t.task_work as N'Task Work',
p11t.task_act_work as N'Task Actual Work',
p11t.task_rem_work as N'Task Rem Work',
p11t.task_ovt_work as N'Task Ovt Work',
p11t.task_act_ovt_work as N'Task Actual Ovt Work',
p11t.task_rem_ovt_work as N'Task Rem Ovt Work',
p11t.task_pct_comp as N'Task %Complete',
p11t.task_pct_work_comp as N'Task %Work Complete',
p11t.task_phy_pct_comp as N'Task % Phys Work Complete',
p11t.task_dur as N'Task Duration',
p11t.task_rem_dur as N'Task Rem Duration',
p11t.task_act_dur as N'Task Actual Duration',
p11t.task_is_milestone as N'Task Milestone',
p11t.task_cost as N'Task Cost',
p11t.task_fixed_cost as N'Task Fixed Cost',
p11t.task_act_cost as N'Task Actual Cost',
p11t.task_rem_cost as N'Task Rem Cost',
p11t.task_ovt_cost as N'Task Ovt Cost',
p11t.task_act_ovt_cost as N'Task Actual Ovt Cost',
p11t.task_rem_ovt_cost as N'Task Rem Ovt Cost'
INTO ProjectServer_Migration_Data_Validation.dbo.Migration_PS2003_Data_Validation_Snapshot

FROM msp_projects AS p11p,
msp_tasks AS p11t
WHERE (p11p.proj_id = p11t.proj_id)

ORDER BY 1,5


Validate the Windows SharePoint Services 2.0 Content database

Published: May 12, 2010

Important:

This procedure is optional and only needs to be done if you plan to migrate your project workspace site and content that is saved in Windows SharePoint Services 2.0.

Prior to migrating the Project workspace sites and their content from Windows SharePoint Services 2.0 to Windows SharePoint Services 3.0, we recommend that you use the Upgrade Pre-Scan tool to validate the SharePoint content database containing the workspaces. In addition, if customization has been applied to site templates or objects, the PreScan Tool will validate whether they are compatible with Windows SharePoint Services 3.0.

The PreScan tool can be downloaded from the following site: SharePoint Products and Technologies Utility: Upgrade Pre-scan Tool (http://go.microsoft.com/fwlink/p/?LinkID=92383)

Extract the utility onto the server running Windows SharePoint Services 2.0 and run the utility with the command: Prescan.exe /all

For more information about running the Pre-scan tool, see Run the pre-upgrade scan tool

You can also refer to the following articles for more information about running the Pre-Scan tool:

  1. Joel Oleson's blog: Your Friend Prescan.exe - How to Get it & What it Does - Part 2 (http://go.microsoft.com/fwlink/p/?LinkId=186362)

  2. Bill Baer blog: Understanding PRESCAN.EXE Errors (http://go.microsoft.com/fwlink/p/?LinkId=186366)


Capture the Windows SharePoint Services 2.0 workspaces linked to projects

Published: May 12, 2010

Important:

This procedure is optional and only needs to be performed if you want to migrate your Windows SharePoint Services 2.0 project workspace sites and content.

Script A4 takes a data snapshot of the Microsoft Office Project Server 2003 database from the Projects table and then stores the data in a table created dynamically within the script. Script A4 lists all projects in the Project Server 2003 database that have an associated project workspace site.

Run Script A4 after updating the two USE statements to point to the validation database created above and the database name of the Microsoft Office Project Server 2003 database that you plan to migrate.

Script A4

Copy Code
/*------------------------------------------------------------
-- Script A4: Capture WSS2 Project Workspaces Data Snapshot
-- Project2003_Projects_With_WSS_Sites.sql
-- List all Projects with Associated WSS workspace sites
------------------------------------------------------------------*/
USE ProjectServer_Migration_Data_Validation
IF EXISTS (SELECT id FROM dbo.sysobjects WHERE id = OBJECT_ID(N'Migration_PS2003_ProjectWorkspaces')
AND OBJECTPROPERTY(id, N'IsUserTable') = 1)
DROP TABLE dbo.Migration_PS2003_ProjectWorkspaces
GO
USE ProjectServer_2003

SELECT [PROJ_NAME]
,[WPROJ_ID]
      ,[WPROJ_STS_SUBWEB_NAME]
      ,[WPROJ_ISSUE_LIST_NAME]
      ,[WPROJ_RISK_LIST_NAME]
      INTO ProjectServer_Migration_Data_Validation.dbo.Migration_PS2003_ProjectWorkspaces
   FROM [MSP_WEB_PROJECTS] P, dbo.MSP_WEB_STS_SERVERS W
  where [WPROJ_STS_SUBWEB_NAME] IS NOT NULL
  and p.[WSTS_SERVER_ID] = w.[WSTS_SERVER_ID]


Migration tasks for migrating to Project Server 2007

Published: May 12, 2010

After you have completed all of the pre-migration tasks for migrating your Microsoft Office Project Server 2003 data, you can begin with the migration itself. The migration tasks that you must do include:

  • Upgrade project workspace data from Project Server 2003: This task is optional and is not required if you only want to migrate your project data.

  • Configure the migration tool (Project Server): The migration tool is the utility used to perform the migration, and it must be installed to your environment. It also uses an initialization (.ini) file that requires your configuration.

  • Run the migration tool (Project Server): The migration tool can migrate projects in batches or all at one time.

  • Troubleshoot migration to Project Server 2007: Use the migration log files to help troubleshoot migration issues.


Upgrade project workspace data from Project Server 2003

Published: May 12, 2010

Important:

This procedure is optional and only needs to be performed if you want to migrate your Windows SharePoint Services 2.0 project workspace sites and content.

This article describes how to migrate your Windows SharePoint Services 2.0 project workspace data to Windows SharePoint Services 3.0. This part of the data migration process from Project Server 2003 to Project Server 2007 is only necessary if you want to migrate your project workspace data. There are two ways that this can be done:

  • If you do an in-place upgrade from Windows SharePoint Services 2.0 to Windows SharePoint Services 3.0, you can run an Stsadm command to make your workspaces active.

  • If you are migrating to a different computer, you can back up your Windows SharePoint Services 2.0 database to restore them to the Windows SharePoint Services 3.0 computer to upgrade it.

Migrating Windows SharePoint Services 2.0 project workspace data to Windows SharePoint Services 3.0 by doing an in-place upgrade

In this case, all the Windows SharePoint Services 2.0 workspaces would have already been upgraded to Windows SharePoint Services 3.0 when you chose the in-place upgrade option when installing Windows SharePoint Services 3.0. But the upgraded project workspaces may not be active. Do the following to make them active.

  1. Open a Command Prompt window and navigate to the location of Stsadm.exe. (The default location is <drive>:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin.)

  2. Run the following Stsadm command to force an upgrade.

    stsadm -o upgrade

    To check progress, you can look at the upgrade.log file: <drive:>:\program files\common files\Microsoft shared\Web server extensions\12\logs\upgrade.log

    The upgrade process will be complete when the command prompt returns Operation completed successfully.

  3. Browse to the upgraded project workspaces and ensure that they work correctly.

Migrating Windows SharePoint Services 2.0 project workspace data to Windows SharePoint Services 3.0 by using a backup and restore approach

If you installed Office Project Server 2007 on a clean computer and if you want to migrate Windows SharePoint Services data, you will be using the content database backup-and-restore approach. It involves the following steps:

Full migration with Windows SharePoint Services

  1. Run the Windows SharePoint Services pre-upgrade scanning tool on the Windows SharePoint Services 2.0 SP2 farm. if it has not already been done (as noted in the pre-migration tasks). This process prepares the Windows SharePoint Services 2.0 content database for upgrade to Windows SharePoint Services 3.0.

  2. Attach a copy of all the Windows SharePoint Services 2.0 content databases to the Office Project Server 2007 farm: Once attached, the Windows SharePoint Services 2.0 sites in the content database are upgraded to Windows SharePoint Services 3.0. We strongly recommend that a copy of the Windows SharePoint Services 2.0 content database be upgraded — not the original content database. At the end of this step, all the Project Server 2003 workspaces will have been upgraded to Windows SharePoint Services 3.0, but they will not yet be linked to the projects.

    1. Open a Command Prompt window and navigate to the location of Stsadm.exe. (The default location is <drive>:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin.)

    2. Run the following Stsadm command to attach a copy of your Windows SharePoint Services 2.0 content database to Windows SharePoint Services 3.0 and upgrade it.

      stsadm.exe -o addcontentdb -url http://<server>:<port> -databasename <WSS v2.0 content database> -databaseserver <DB Server name>

      For example:

      stsadm.exe -o addcontentdb -url http://MyServer:80 -databasename WSS_V2_ContentDB -databaseserver Sample

    3. After running Stsadm.exe, you can track the progress of the upgrade by looking at upgrade.log in the ULS log directory. (The default location is c:\program files\common files\Microsoft shared\Web server extensions\12\logs\upgrade.log.) The upgrade process has finished on a given content database when the following line is included in the log:

      [SPManager] [DEBUG] [<Date> <Time>]: Using cached [SPContentDatabase Name=<DB NAME> Parent=SPDatabaseServiceInstance] NeedsUpgrade value: False.

    4. Navigate to the upgraded project workspaces to verify that upgrade has succeeded.

    5. If upgrade fails for any reason (as indicated in the log), the Windows SharePoint Services upgrade process can be restarted. To restart the upgrade process, run the command Stsadm.exe -o upgrade and look at the logs to view the progress. The upgrade process has finished when the command prompt returns Operation completed successfully.

When the migration tool saves and publishes projects later in the migration process, the links between projects, tasks, and assignments and the SharePoint Foundation items will be fixed.


Configure the migration tool (Project Server)

Published: May 12, 2010

This article provides information on how to configure the initialization (.ini) file used by the migration tool to migrate Microsoft Office Project Server 2003 data to Microsoft Office Project Server 2007. This article also provides several SQL queries used to search the Project Server 2003 database for projects in certain states to include in the migration configuration file.

In this article:

  • Migration configuration file overview

  • Migration configuration parameters

  • Migration configuration file example

  • Querying the Project Server 2003 database for projects

Migration configuration file overview

Typically the migration tool is invoked using a command line that looks similar to this:

D:\Program Files\Microsoft Office\OFFICE12>P12MigrationTool.exe -c d:\migration\ProjectServer2007Migrate.ini

Before you run the migration tool, you must manually edit the migration configuration file in a text editor. This file configures the parameters that specify the location of the upgrade log file, which projects to migrate, the location of the computer running Microsoft SQL Server on which the Office Project Server 2007 databases will exist, and so forth.

A sample migration configuration file (named ProjectServer2007Migrate.ini.sample) is installed in the same directory as the migration tool. You can update this sample file with the correct configuration parameters and then point to it when you run the migration tool. The sample file includes comments that describe configuration options that are available for each parameter.

The following sections provide more details about the migration configuration file.

Migration configuration parameters

Following are the parameters that you can configure in the migration configuration file.

Parameter Description

[General]

General configuration section. The parameters for this section are listed next.

BatchName=

You can run the migration tool multiple times (for example, to migrate projects in batches). Therefore, specify a unique name for each run of the migration tool. The log file that is generated from each run of the migration tool is named according to the specified BatchName parameter. If a unique name is not specified, the log file that is generated will write over the previous log file.

LogFileNamePrefix=

Identifies the prefix of the migration log file. The log file name is a combination of LogFileNamePrefix and a timestamp specifying when the migration started. For example, if you have a log file name of batch1-20060314-1542.log:

  • LogFileNamePrefix=batch1

  • The migration run for this log was started on 3/14/2006 at 3:42 pm

Being able to apply a prefix to the log file name can be useful when you are migrating multiple times, such as in a gradual migration approach.

LogFilePath=

Identifies the path to the log files that are generated by the migration tool. The migration tool writes verbose information to the log file. The log file is your main source of troubleshooting information for the migration tool. If the migration tool cannot write to the log file, it stops running, so you can be sure that you can always refer to the log file for more information about the migration run.

MigrateAll=

Save: All projects in Project Server 2003 are migrated to Office Project Server 2007 and none of them are published.

Publish: All projects in Project Server 2003 are migrated to Office Project Server 2007 and the published projects in Project Server 2003 are automatically published in Office Project Server 2007.

If you want the MigrateAll parameter to be ignored, comment out the MigrateAll line with a semicolon. If this is done, no projects will be migrated when running the migration tool.

Note:

Comment out the MigrateAll parameter if you choose to follow the best practice of running the migration tool to migrate non-project data (enterprise global template, enterprise resources, and Project Web Access data) prior to migrating any projects. You must also verify that no projects are specified in the [Project Names to Save and Publish] and [Project Names to Publish] sections.

Important:

The MigrateAll= setting is ignored if you have specified any project names in the [Project Names to Save and Publish] or [Project Names to Publish] section.

FixUpSecurityCategories=

If FixUpSecurityCategories is set to Yes, projects are automatically added to security categories after they are migrated. If it is set to No, projects are not added to any security category after migration. Typically, you would set this policy to No if the categories in Office Project Server 2007 will be significantly different from the categories you have in Project Server 2003 and you want to add your projects to security categories manually.

StopProjectMigrationIfStatusUpdatesPending=

By default, the value of StopProjectMigrationIfStatusUpdatesPending is Yes. If it is set to Yes, any projects that have pending updates are not migrated. If this setting is set to No, any projects that have pending updates are migrated. The No option is useful if customers want to migrate projects even though they have pending updates. An example of this situation is when there are old projects that need to be migrated, but there are no active project managers for these projects to process pending updates.

NeverPublishMasterProjects=

By default, the value for NeverPublishMasterProjects is set to Yes. This setting ensures that master projects do not get published by mistake. This is useful for customers who have set the Never Publish Master Projects option in Project Server 2003.

If you want any master projects published after migration, set NeverPublishMasterProjects to No. Even if you specify this setting, you need to manually include the master project in the [Project Names to Save and Publish] section.

Note:

Publishing a master project in Office Project Server 2007 does not double-count availability.

[Project Names to Save]

Type the names of the projects you want to save after migration. Projects specified in this section are not published.

Note:

You must specify the complete name (as stored in the PROJ_NAME column in the MSP_PROJECTS table).

[Project Names to Save and Publish]

Type the names of the projects that you want to save and publish after migration.

Note:

Only published projects (with .PUBLISHED extensions) in Project Server 2003 can be published to Office Project Server 2007. If you specify a versioned project, then it will only be saved and not published.

Note:

You must specify the complete name of the project (as stored in the PROJ_NAME column in the MSP_PROJECTS table).

Note:

If you specify a master project and set neverPublishMasterProjects=false, then the subprojects (if they are already migrated or are being migrated as part of this migration run) will also get published automatically. Also note that publishing a master project in Project Server 2010 does not double-count availability.

[Excluded Project Names]

Specify any project that you want explicitly excluded during migration. This option is typically used with the MigrateAll setting when you want to migrate most, but not all, of your projects.

Note:

You must specify the complete name of the project (as stored in the PROJ_NAME column in the MSP_PROJECTS table).

[Project Server 2007]

The Office Project Server 2007 configuration section. The parameters for this section are listed next.

Project2007PWAServer=

Type the Microsoft Project Web App URL. For example, Project2007PWAServer=http://Project2007PWAServer/pwa

Project2007SQLServer=

Type the name of the instance of SQL Server that hosts the Office Project Server 2007 databases.

Important:

By default, the Project Server 2003 databases also should be part of the same instance of SQL Server as Office Project Server 2007. To do this, back up and restore the Project Server 2003 databases into the instance of SQL Server that hosts the Office Project Server 2007 databases. If this is a major restriction for you, refer to the Project2003LinkedSQLServer property in the [Project Server 2003] section.

DraftDB =

Type the name of the Office Project Server 2007 draft database.

PublishedDB =

Type the name of the Office Project Server 2007 published database.

[Project Server 2003]

The Project Server 2003 configuration section. The parameters for this section are listed next.

Project2003ProjectTablesDB =

If you have a single database configuration for the Project Server 2003 database (as opposed to a split database configuration), then type the name of the database in this configuration setting as well as the Project2003WebTablesDB= setting that follows.

Note:

The migration tool does not migrate SQL Server Analysis Services cube tables. You will have to rebuild cubes after migration.

Project2003WebTablesDB=

If the Project Server 2003 database is in a split database configuration, type the name of the Web Tables database. As noted above, if Project Server 2003 is in a single database configuration, enter the database name here as well as in the Project2003ProjectTablesDB= setting.

Project2003LinkedSQLServer=SQLServerName

By default, this setting is not enabled (the Project2003LinkedSQLServer= setting is commented out). If this parameter is not specified, the migration tool assumes that the Project 2003 databases reside in the computer hosting the Office Project Server 2007 SQL Server. If the SQL Server computer in which the Project 2003 databases reside cannot reside on the computer that hosts the Office Project Server 2007 databases, you can use this setting to specify the computer on which the Project Server 2003 database resides. However, for this to work you must add the Project Server 2003 database as a linked server to the Office Project Server 2007 SQL Server. To configure an SQL linked server connection, see the pre-migration task article Configure a linked server in SQL Server (Project Server 2010).

Migration configuration file example

The following is an example of a configured migration configuration file.

Copy Code
[General]
LogFilePath=C:\ProjectServer2007Migration
LogFileNamePrefix=Batch1
MigrateAll=Publish
FixUpSecurityCategories=yes
StopProjectMigrationIfStatusUpdatesPending=yes
NeverPublishMasterProjects=yes
[Project Names to Save]
Project1.published
Project2.Target
[Project Names to Save and Publish]
Project3.Published
Project4.Published
[Excluded Project Names]
Project5.Published
Project6.Target
[Project Server 2007]
Project2007PWAServer=http://Project2007pwaserver/pwa
Project2007SQLServer=Project2007sqlserver
DraftDB=Project2007ProjectServerDraft
PublishedDB=Project2007ProjectServerPublished
[Project Server 2003]
Project2003ProjectTablesDB=Project2003ProjDB
Project2003WebTablesDB=Project2003WebDB
;Project2003LinkedSQLServer=LinkedSQLServerName
Note:

The migration configuration file that is installed with the migration tool contains comments that describe the configuration options that are available. The comments can help you correctly configure the file. You can leave the comments in the file after you configure it.

Querying the Project Server 2003 database for projects

The SQL Server scripts shown in this section can be very useful for searching your Project Server 2003 database for projects that need to be included in any of the following sections of the migration configuration file:

  • [Project Names to Save]

  • [Project Names to Save and Publish]

  • [Excluded Project Names]

  • The project names resulting from the queries can then be copied into the appropriate sections of the migration configuration file as needed.

Projects not yet started

SELECT p.PROJ_NAME FROM dbo.MSP_PROJECTS p

INNER JOIN dbo.MSP_TASKS t ON (t.PROJ_ID = p.PROJ_ID AND t.TASK_UID = 0)

WHERE p.PROJ_TYPE = 0 AND t.TASK_PCT_COMP = 0 AND t.TASK_PCT_WORK_COMP = 0

Projects that are finished

SELECT p.PROJ_NAME FROM dbo.MSP_PROJECTS p

INNER JOIN dbo.MSP_TASKS t ON (t.PROJ_ID = p.PROJ_ID AND t.TASK_UID = 0)

WHERE p.PROJ_TYPE = 0 AND t.TASK_PCT_COMP = 100 AND t.TASK_PCT_WORK_COMP = 100

Projects not yet finished

SELECT p.PROJ_NAME FROM dbo.MSP_PROJECTS p

INNER JOIN dbo.MSP_TASKS t ON (t.PROJ_ID = p.PROJ_ID AND t.TASK_UID = 0)

WHERE p.PROJ_TYPE = 0 AND (t.TASK_PCT_COMP != 100 OR t.TASK_PCT_WORK_COMP != 100)

Project that are in progress

SELECT p.PROJ_NAME FROM dbo.MSP_PROJECTS p

INNER JOIN dbo.MSP_TASKS t ON (t.PROJ_ID = p.PROJ_ID AND t.TASK_UID = 0)

WHERE p.PROJ_TYPE = 0 AND (t.TASK_PCT_COMP > 0 OR (t.TASK_STOP_DATE > t.TASK_START_DATE AND t.TASK_DUR > 0))

Projects with the project outline code 'Project Status' equal to 'Opportunity'

For the following query, substitute the outline code and value you want to query with the "Project Status" and "Opportunity" values used for this example.

SELECT p1.PROJ_NAME

FROM dbo.MSP_FIELD_ATTRIBUTES fa

INNER JOIN dbo.MSP_ATTRIBUTE_STRINGS ats ON (fa.PROJ_ID = ats.PROJ_ID AND fa.AS_ID = ats.AS_ID AND fa.ATTRIB_ID = 206)

INNER JOIN dbo.MSP_PROJECTS p ON (p.PROJ_ID = fa.PROJ_ID AND p.PROJ_TYPE = 2)

INNER JOIN dbo.MSP_OUTLINE_CODES oc ON (p.PROJ_ID = oc.PROJ_ID AND oc.OC_FIELD_ID = fa.ATTRIB_FIELD_ID)

INNER JOIN dbo.MSP_CODE_FIELDS cf ON (cf.CODE_FIELD_ID = oc.OC_FIELD_ID AND cf.CODE_UID = oc.CODE_UID)

INNER JOIN dbo.MSP_PROJECTS p1 ON (p1.PROJ_ID = cf.PROJ_ID)

WHERE ats.AS_VALUE like '%Project Status%' AND oc.OC_CACHED_FULL_NAME like 'Opportunity'

Project templates

SELECT p.PROJ_NAME FROM dbo.MSP_PROJECTS p WHERE PROJ_TYPE = 1


Run the migration tool (Project Server)

Published: May 12, 2010

In this article:

  • Migrate global data

  • Migrate projects (full migration)

  • Migrate projects (gradual migration)

This article describes the steps involved in running the migration tool to migrate global data or projects from Microsoft Office Project Server 2003 to Microsoft Office Project Server 2007.

Migrate global data

Before migrating projects either through a full migration or a batch of gradual migrations, we recommend as a best practice that you make an initial run of the migration tool to migrate global data such as the enterprise global template, enterprise resources, and Project Web Access data. Once you verify that the data has migrated correctly, you can then migrate projects.

In order to migrate only global data, the migration configuration file must have the following parameters set correctly:

  • MigrateAll= Leave this value empty.

  • [Project Names to Save] Do not enter any project names in this section.

  • [Project names to Save and Publish] Do not enter any project names in this section.

    Note:

    After initially running the migration tool to migrate global data, subsequent attempts to migrate global data will not overwrite or update the data in Office Project Server 2007. Global data migration can only occur once. If there are any incremental changes to the Project Server 2003 global data, they must be applied manually to Office Project Server 2007.

    Important:

    If the global data migration process stops in the middle, it needs to be run again from the beginning. The migration tool may stop in the middle because of an error in Project Server 2003 data (for example, a particular resource does not have a valid value for a resource outline code). The way to fix this problem is to open ResGlobal in Project Professional 2003, fix the issue, and retry migration. Repeat this process until the global migration process proceeds to completion. Once it finishes successfully, you know that the Project Server 2003 data is clean. Next, you need to clean up the Office Project Server 2007 data (restore the Office Project Server 2007 databases to a clean state) and re-migrate the global data again from scratch. You should re-migrate the global data to a new Office Project Server 2007 instance.

    For information about restoring Office Project Server 2007 databases, see Troubleshoot migration to Project Server 2007.

    Important:

    Once you have upgraded Project Server 2003 workspaces, then you need to configure the Project Workspace provisioning settings. Once global data migration finishes successfully:

    1. In the migrated Project Web Access site, click Server Settings.

    2. On the Server Settings page, in the Operational Policies section, click Project Workspace Provisioning Settings.

    3. In the Site URL section, make sure that Default Web Application and Site URL points to the SharePoint site with the upgraded workspaces. If this value is not set, the link from projects, tasks, and assignments to issues, risks, and documents will not be fixed correctly when projects are migrated and published.

Migrate projects (full migration)

When running the migration tool to migrate all projects at one time (full migration), the migration configuration file's MigrateAll= parameter must be configured with one of the following two options:

  • MigrateAll=Save All projects in Project Server 2003 are migrated to Office Project Server 2007 and none of them are published.

  • MigrateAll=Publish All projects in Project Server 2003 are migrated to Office Project Server 2007 and the published projects in Project Server 2003 are automatically published in Office Project Server 2007.

You can also enter all the project names manually in the [Project Names to Save] or [Project Names to Save and Publish] sections.

Note:

It is a best practice to migrate and save projects first (by adding them to the [Project Names to Save] section), verifying that the migration worked correctly, and then publishing the projects (by adding them to the [Project Names to Save and Publish] section). If a project is added to the [Project Names to Save and Publish] section and the project already exists in Office Project Server 2007, then it is only published.

Note:

When entering project names in both of these sections of the migration configuration file, you must specify the complete name (as stored in the PROJ_NAME column of the MSP_PROJECTS table of the Project Server 2003 database). For example, do not simply specify "Project1." Instead, specify "Project1.Published."

Migrate projects (gradual migration)

When migrating Project Server 2003 data to Office Project Server 2007 with the purpose of migrating to Microsoft Project Server 2010, in some cases you might want to migrate your projects in batches (gradual migration) as opposed to all at one time (full migration). For example, you might have several thousand projects, and as a best practice you want to migrate them in batches of 1,000. Another example is if you want to migrate all subprojects first before migrating a master project.

When running the migration tool to migrate subsets of projects in a series of batches (gradual migration), the MigrateAll= parameter is left empty. The migration tool is run once for each batch of projects you wish to migrate. The names of the projects you want to migrate for each batch must be entered into the migration configuration file in either of the following sections:

  • [Project Names to Save] Type the project names of the projects you want saved after migrating them to Office Project Server 2007.

  • [Project Names to Save and Publish] Type the project names of the projects you want saved and published after migrating them to Office Project Server 2007. Only published projects (with the ".published" extension) in Project Server 2003 can be published to Office Project Server 2007. Versioned projects specified in this section are saved but not published.


Troubleshoot migration to Project Server 2007

Published: May 12, 2010

This article describes options that are available to you if you encounter problems during the migration process to Microsoft Office Project Server 2007.

In this article:

  • Before you troubleshoot: Verify functionality in Project Server 2007

  • Error logging

  • Restoring the Project Server 2007 database

  • Migrated user and permission issues

  • Authentication issues

  • Migration flowchart

Before you troubleshoot: Verify functionality in Project Server 2007

Before going further with troubleshooting, first check whether Office Project Server 2007 itself is working correctly. Identifying whether the problem is with migration or Office Project Server 2007 configuration can save you time.

  • Create a new Project Web Access instance on the Project Server computer. Make sure that this instance is not used for migration. You can delete this instance after you are done troubleshooting.

  • On the computer running Office Project Server 2007, create, save, and publish a project on the newly created instance of Project Web Access. Verify that you can open the project in the Project Center. If you cannot do this, it is possible that the problem you are having may pertain to the Office Project Server 2007 configuration.

  • Verify that the Queuing service and the Eventing service are running on the application server.

Error logging

When you are troubleshooting migration, it is important to know where to look for any pertinent error logging information. This section describes several mechanisms that have error-logging information.

  • View the Queue Management page to verify whether there are any jobs in a failed state. View the Error column of these entries to see if it provides any clues to the problem.

  • View the upgrade log file. It is available in the path specified in the migration configuration file. It provides a detailed description of failures that occurred during the migration.

  • Look at the server's event log and trace log.

  • To open and view the event log, on the server computer click Start, then Run, type Eventvwr, and then click OK. Then click the Application node. This action displays a list of application events raised on the server.

  • To open and view the trace log, on the server computer go to the following folder: <drive>:\program files\common files\Microsoft Shared\web server extensions\12\LOGS. The ULS trace logs are named in the following format: <servername>-yyyymmdd-time.log (for example, contoso-20060720-1506.log).

  • If you cannot determine the cause of the failure from the log file, and you plan on contacting Microsoft Product Support Services for assistance, have the following information available:

    1. Upgrade logs (which are available in the path you specified in the migration configuration file)

      Note:

      Make sure the server writes verbose logs, which ensures that as much information as possible is logged for debugging. You can set this parameter in the SharePoint Central Administration Web site in the Operations tab on the Diagnostic Logging page. In the Event Throttling section of this page, set the following parameters:

      Least critical event to report in the event log: Success

      Least critical event to report in the trace log: Verbose

      Click OK to save the settings. You may want to verify that the settings have been saved. To do this, in the same section select an individual category from the Update Single Category list and verify that the settings are the same.

    2. A copy of the event log file: To do this, open the event log, right-click the Application node and select Save Log File As. This allows you to save the event log to a file so that you can send it to Microsoft Product Support Services.

      Note:

      Make sure to reproduce the problem to ensure that the problem is recorded to the event and trace logs.

    3. A copy of the latest trace log files: If you are sending trace information for debugging, reproduce the problem on the server and send the latest two or three trace log files. You can identify the log files by the date-and-time stamp used to name each file.

    4. A copy of the Project Server 2003 database file

  • If the migration tool stops responding, a Microsoft Office Project dialog box appears that allows you to further troubleshoot the issue with Microsoft Product Support Services. In the dialog box, select Send Error Report in order for this issue to be sent to Product Support Services. Once the error report is sent, go to the Event viewer, look for an event with event ID = 1001, copy the contents in the description field to a text editor and send it to your Product Support Services contact.

  • Restore Office Project Server 2007 to a clean state and retry migration. Instead of provisioning the Office Project Server 2007 instance again, you can restore the backed-up, clean Office Project Server 2007 database and the Project Server 2003 database, and then run the upgrade process again. For information about how to restore the backed-up, clean Office Project Server 2007 database, read the Restoring the Project Server 2007 database section.

Finding errors, warnings, and failures in an upgrade log file

You can run the following commands at the command prompt to find and compile warnings, errors, and failures from your upgrade log file.

  • To find all lines denoting warnings in the upgrade log file, run the following command:

    Find /I "warning" <source log files> >> <output file>

    For example:

    Find /I "warning" c:\myupgradelog.log >> c:\errors.log

  • To find all lines denoting errors in the upgrade log file, run the following command:

    Find /I "error" <source log files> >> <output file>

    For example:

    Find /I "error" c:\myupgradelog.log >> c:\errors.log

  • To find all lines denoting failures in the upgrade log file, run the following command:

    Find /I "fail" <source log files> >> <output file>

    For example:

    Find /I "fail" c:\myupgradelog.log >> c:\errors.log

Restoring the Project Server 2007 database

If you encounter non-recoverable problems during the data migration, you can restore your Office Project Server 2007 database and then run the upgrade process again. The following is a sample script used to restore your Office Project Server 2007 database. This is not a prescriptive script; modify it as necessary to meet your needs. You must run this script on a computer where OSQL is available.

Copy Code
Rem Note that if you have any open connections to the database,
Rem   the Restore operation will fail. You can view open connections in
Rem   Enterprise Manager:
Rem   under <Server> - Management - Current Activity
Rem   (hit F5 to refresh) - Process Info.
Rem You can stop a process by right-clicking, and choosing Kill Process.
echo off

set P12SQLServerName=<SQL Server Name>

Set publishedDB=<DB Name>
Set draftDB=<DB Name>
Set archiveDB=<DB Name>
Set ReportingDB=<DB Name>

Set RestorePublishedDB='<Full path of the backup>'
Set RestoreWorkingDB= '<Full path of the backup>'
Set RestorearchiveDB= '<Full path of the backup>'
Set RestoreReportingDB= '<Full path of the backup>'

Rem The following commands ensure that there are no open connections to
Rem  the databases that we are restoring to. You can also do this manually.

Set SqlCmd="USE master ALTER DATABASE %publishedDB% SET SINGLE_USER WITH ROLLBACK IMMEDIATE"
osql -E -S %P12SQLServerName% -Q %SqlCmd%

Set SqlCmd="USE master ALTER DATABASE %draftDB% SET SINGLE_USER WITH ROLLBACK IMMEDIATE"
osql -E -S %P12SQLServerName% -Q %SqlCmd%

Set SqlCmd="USE master ALTER DATABASE %archiveDB% SET SINGLE_USER WITH ROLLBACK IMMEDIATE"
osql -E -S %P12SQLServerName% -Q %SqlCmd%

Set SqlCmd="USE master ALTER DATABASE %ReportingDB% SET SINGLE_USER WITH ROLLBACK IMMEDIATE"
osql -E -S %P12SQLServerName% -Q %SqlCmd%

Rem Restoring the database
set SqlCmd= "RESTORE DATABASE %publisheddb%
  From disk = %RestorePublishedDB%
  with replace RESTORE DATABASE %draftdb% From disk = %RestoreWorkingDB%
  with replace RESTORE DATABASE %archivedb%
  From disk = %RestorearchiveDB%
  with replace RESTORE DATABASE %reportingdb%
  From disk = %RestoreReportingDB% with replace"

osql -E -S %P12SQLServerName% -Q %SqlCmd%

Set SqlCmd="USE master ALTER DATABASE %publishedDB% SET MULTI_USER"
osql -E -S %P12SQLServerName% -Q %SqlCmd%

Set SqlCmd="USE master ALTER DATABASE %draftDB% SET MULTI_USER"
osql -E -S %P12SQLServerName% -Q %SqlCmd%

Set SqlCmd="USE master ALTER DATABASE %archiveDB% SET MULTI_USER"
osql -E -S %P12SQLServerName% -Q %SqlCmd%

Set SqlCmd="USE master ALTER DATABASE %ReportingDB% SET MULTI_USER"
osql -E -S %P12SQLServerName% -Q %SqlCmd%

Rem Clearing the cache
rd /s /q "%APPDATA%\Microsoft\MS Project\cache"

goto :Clean

:Clean

Rem To clean up the environment variables created
set P12SQLServerName=
Set RestorePublishedDB=
Set RestoreWorkingDB=
Set RestorearchiveDB=
Set RestoreReportingDB=

set SqlCmd=

Set publishedDB=
Set draftDB=
Set archiveDB=
Set ReportingDB=

Migrated user and permission issues

After migration (especially in localized builds), your users may not have certain expected permissions in the migrated Office Project Server 2007 installation. For example, imagine that you were assigned your permissions through the administrator template, but you cannot view timesheets. There are several reasons that such a situation might occur:

  • In Project Server 2003, a permission is denied at the organization level. You can verify this by checking your Project Web Access permissions to see whether any permissions are disabled and whether they are the cause of your problem.

    To check your Project Web Access Permissions

    1. In the Project Web Access home page, in the left pane click Server Settings.

    2. In Server settings, in the Security section, click Project Web Access Permissions.

  • There are some permissions that are new in Office Project Server 2007. These permissions may not be mapped correctly during migration. You can check the Security documentation for a list of these permissions to see whether they are the cause of your problem. For more information about Office Project Server 2007 permissions, see Introduction to permissions in Microsoft Office Project Server 2007 (http://go.microsoft.com/fwlink/p/?LinkId=188797).

  • If a Project Server 2003 user or resource exists in Office Project Server 2007 (by name or Windows NT account), that user or resource's security permissions will not be migrated. For example, if you had done an "AD Sync" prior to migration (and if most of those users exist in Project Server 2003), none of those user permissions would have been migrated. If you encounter this problem, set the target Project Web Access to "Empty" and start the migration process again.

Authentication issues

Project authentication is used in Project Server 2003, but it is not supported in Office Project Server 2007. When you migrate Project authenticated users to Office Project Server 2007, the user accounts are reset, because the forms authentication mechanism in Office Project Server 2007 is architecturally different from the Project authentication used in Project Server 2003. You will not see these users listed in the Project Web Access Server Settings Manage Users page, or the User Authentication section for the user will not appear. However, you can still edit these migrated users in the Project Web Access Resource Center.

Migrated resources in the resource database may end up out of sync with the published database.

Issues when migrating master projects

When you are migrating master projects and their associated subprojects from Project Server 2003 to Office Project Server 2007, the following two scenarios will cause the project migration to fail:

  • A subproject migrated after its master project. (You can correct the order of migration in the migration configuration file.)

  • A project that is a subproject to two different master projects. (Such an arrangement is allowed in Project Server 2003, but not in Office Project Server 2007). The migration for this project will fail when it attempts to publish the project.

Migration flowchart

The following flowchart provides a graphic representation of how data is migrated from Project Server 2003 to Office Project Server 2007. It can be used in troubleshooting issues that might occur in migration.

The upgrade from Project Server 2003 to Office Project Server 2007 involves both Windows client-based and SQL Server 2000-based upgrade steps.

There are three phases of the upgrade process:

  1. Global data upgrade phase: Upgrading of global and Project Web Access data to Project Server 2010.

  2. Project data upgrade phase: Upgrading of project data to Project Server 2010.

  3. Windows SharePoint Services data upgrade phase: Needed only if you have Windows SharePoint Services data for projects in Project Server 2003. This phase occurs separately from the running of the migration tool and therefore is not included in this flowchart.

The following flow charts illustrate the first two phases of the upgrade process, respectively.

Project Server 2007 troubleshoot migration Project Server 2007 upgrade project data chart


Post-migration tasks after migrating your Project Server 2003 data

Published: May 12, 2010

After you have run the migration tool to migrate Microsoft Office Project Server 2003 data to Microsoft Office Project Server 2007, there are several post-migration tasks that need to be addressed. These tasks include:

  • Verify whether the migration worked

  • Update migrated server settings

  • Synchronize the migrated forms-authenticated users with the Project Server 2007 forms-based authentication store

  • Verify the project workspace provisioning settings

  • Delete migrated inactive users (optional)

  • Fix project currency settings

  • Change migrated local Windows accounts

  • Update multilanguage lookup tables

This article also includes information about how to Roll back migration.

Verify whether the migration worked

Look at the migration tool command line or the migration log to verify that the migration was successful. If it was not successful, make corrections and re-run the migration tool. If there is an irrecoverable problem, make changes in Project Server 2003, restore the clean Office Project Server 2007 databases, and retry the migration. If the migration process appears to have been successful, ensure that the data migrated correctly to Office Project Server 2007 by doing the following kinds of tests:

  • Verify project data: Open the migrated projects, make changes to them, add enterprise resources, publish them, accept status updates, and so on

  • Verify Project Web Access data: Fill in timesheets, create proposals, build a cube, and so on

We highly recommend that you have a migration checklist specific to your needs and that you test those items after migration.

Update migrated server settings

As explained in Data that cannot be migrated to Project Server 2007, all data from Project Server 2003 may not be migrated to Office Project Server 2007. Therefore we highly recommend that you go over all the Office Project Server 2007 server settings and make sure that they are as you want them to be. Some specific areas are listed below:

  1. Security settings: There are some security permissions (global and category) that are new in Office Project Server 2007. These permissions may not get migrated. You may want to review each one and make a decision on whether to give users that permission. For more information, see Introduction to permissions in Microsoft Office Project Server 2007 (http://technet.microsoft.com/en-us/library/cc197530(office.12).aspx).

  2. Project Web Access view definitions: The "Filter by" and "Group by" clauses are not migrated from Project Server 2003. You may need to re-create these. Also, some Project Web Access view fields do not migrate. You may want to make sure that all the fields of interest to you are available in the migrated views.

  3. Merge and rename similar security groups, categories, and templates and Project Web Access view definitions: If there is a name clash during migration of security templates, view definitions, and security groups and categories, the migration tool attaches a prefix or suffix to the clashing names. This action is taken to preserve both Project 2007 entities and Project 2003 entities in one system. Then you can select which one to keep or elect to merge them, as appropriate. We recommend that you resolve them so that end users do not become confused.

Synchronize the migrated forms-authenticated users with the Project Server 2007 forms-based authentication store

This is a required step to make sure that the migrated forms-authenticated users work in Office Project Server 2007. For more information, see Configure SQL Membership Provider forms authentication for Project Server 2007 (http://go.microsoft.com/fwlink/p/?LinkId=188757).

Verify the project workspace provisioning settings

The migration tool resets the Automatically Provision option in the Project Workspace Provisioning Settings page of Server Settings to Manually Create a workspace for each project in Office Project Server 2007. This setting ensures that the migration process does not provision duplicate workspaces for projects that may already have workspaces that are yet to be migrated.

After running the migration tool, check the Project Workspace Provisioning settings located in the Operational Policies section of Project Web Access Server Settings. Verify that the Site URL and the Automatic Provisioning options are configured correctly per your needs. If you want Office Project Server 2007 to automatically create a workspace when a project is published, reset the Automatically Provision option to Automatically create a workspace for the project when a project is published in Office Project Server 2007 after the migration tool is run.

Delete migrated inactive users (optional)

The Manage Groups page in Project Server 2003 does not display inactive users by default. But in Office Project Server 2007, inactive users are displayed by default. Therefore, after the migration process (which migrates the inactive users as well), you may see extra users in the Manage Groups Project Web Access page in Office Project Server 2007.

You can permanently delete the inactive users if needed.

To permanently delete the inactive users:

  1. In Project Web Access, click Server Settings.

  2. In the Database Administration section, click Delete Enterprise Objects.

  3. In the Delete Enterprise Objects page, in the What do you want to delete from Project Server section, select Resources and Users.

  4. In the list of users that displays, select the users you want to permanently delete, and then click Delete.

Fix project currency settings

It is a known issue that project currencies are not migrated correctly. Run the following SQL query on the Project Server 2003 Project Tables database to get a list of projects and their currencies. This information can be used to manually correct the currency settings post migration.

Copy Code
select PROJ_NAME, PROJ_OPT_CURRENCY_SYMBOL
  from dbo.MSP_PROJECTS where PROJ_TYPE in (0, 1, 2)

Change migrated local Windows accounts

If you had any local Windows accounts (for example, ComputerName\Brad Joseph), and the computer names are no longer valid, make sure you go to Project Web Access Server Settings and use the Manage Users options to edit those accounts so that they are valid.

Update multilanguage lookup tables

Multilanguage lookup tables are not updated correctly after migration. Run the following SQL statements on the Office Project Server 2007 Published database to correct this problem.

DELETE FROM dbo.MSP_LOOKUP_TABLE_LANGUAGES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)

DELETE FROM dbo.MSP_LOOKUP_TABLE_MASK_VALUES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)

DELETE FROM dbo.MSP_LOOKUP_TABLE_MASK_STRUCTURES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)

DELETE FROM dbo.MSP_LOOKUP_TABLE_VALUES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)

DELETE FROM dbo.MSP_LOOKUP_TABLE_STRUCTURES WHERE LT_UID NOT IN (SELECT LT_UID FROM dbo.MSP_LOOKUP_TABLES)

If you are using Microsoft Office Project Portfolio Server 2007 with Office Project Server 2007, it is especially important to run these SQL statements to update the tables. If the statements are not run, you may encounter a "GeneralUnhandledException" error when performing an export from Office Project Portfolio Server 2007 to Office Project Server 2007. The error would look like this and would appear in the ULS logs:

PSI: LookupTable.ReadLookupTablesMultiLang Undefined Attibutes: PSError: GeneralUnhandledException Underined attributes list: System.Data.ConstraintException: Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints….

Roll back migration

You may want to roll back if one of the following situations occurs:

  • Migration fails in the middle of the process

  • A lot of data changes in Project Server 2003 after migration. If so, the migration process should be done again from scratch.

Because migrating to Office Project Server 2007 is not an in-place upgrade, no Project Server 2003 data is modified during the process. Therefore, a rollback is equivalent to restoring a clean instance of Office Project Server 2007 Project Web Access. (It may be from a backup.) You can then run the migration again.

If you want to re-migrate a few projects (perhaps because they changed in Project Server 2003), the roll-back method is to delete the projects in Office Project Server 2007 and re-migrate them.

Important:

If the global data migration process stops in the middle, it needs to be run again from the beginning. The migration tool may stop in the middle because of an error in Project Server 2003 data (for example, a particular resource does not have a valid value for a resource outline code). The way to fix this problem is to open ResGlobal in Project Professional 2003, fix the issue, and retry migration. Repeat this process until the global migration process proceeds to completion. Once it finishes successfully, you know that the Project Server 2003 data is clean. Next, you need to clean up the Office Project Server 2007 data and re-migrate the global data again from scratch.


Complete your upgrade from Project Server 2003 to Project Server 2010

Published: May 12, 2010

After you have successfully migrated your Microsoft Office Project Server 2003 data to Microsoft Office Project Server 2007, you can upgrade to Microsoft Project Server 2010 to complete the upgrade process. You can upgrade from Office Project Server 2007 to Project Server 2010 by using either the in-place upgrade method, or the database-attach upgrade method. The following table addresses the method available to you, depending on your Office Project Server 2007 installation environment:

Note:

For more information about Project Server 2010 upgrade methods and their requirements, see Project Server 2010 upgrade overview.

Use the table below to see the suggested upgrade method for your Office Project Server 2007 environment. The documentation links will provide procedures for upgrading to Project Server 2010 for the suggested upgrade method.

Project Server 2007 environment Upgrade method For more information about the upgrade method

Project Server 2007 on 64-bit Windows Server 2008

In-place upgrade

Note:

Although the in-place upgrade method is recommended, you can use the database attach method if required.

In-place upgrade to Project Server 2010

Project Server 2007 on 32-bit Windows Server 2008

Database-attach upgrade only

Database-attach full upgrade to Project Server 2010

Database-attach core upgrade to Project Server 2010

Project Server 2007 on 64-bit Windows Server 2003

Database-attach upgrade

Note:

It is also possible to upgrade the server operating system to 64-bit Windows Server 2008, and then use the in-place upgrade method.

Database-attach full upgrade to Project Server 2010

Database-attach core upgrade to Project Server 2010

Project Server 2007 on 32-bit Windows Server 2003

Database-attach upgrade only

Database-attach full upgrade to Project Server 2010

Database-attach core upgrade to Project Server 2010

Project Server 2007 Virtual Migration Environment (VME)

Database-attach upgrade only

Database-attach full upgrade to Project Server 2010

Database-attach core upgrade to Project Server 2010

The differences between the database-attach methods are:

  • Database attach full method: Upgrades the four Office Project Server 2007 databases and the content database that contains the Project Web Access site data.

  • Database attach core method: Upgrades the four Office Project Server 2007 databases only. Use this method if you do not want to migrate any of your Project Web Access site data.

Note:

For more information about the Project Server 2007 Virtual Migration Environment (VME), see Migrate your Project Server 2003 data by using the VME.


Migrate your Project Server 2003 data by using the VME

Published: May 12, 2010

To migrate from Microsoft Office Project Server 2003 to Microsoft Project Server 2010, first you must migrate your data to Office Project Server 2007 format. If you do not have Office Project Server 2007 readily available, you can choose to use the virtual migration environment (VME) to migrate your data to Office Project Server 2007 format. The VME is a fully configured Office Project Server 2007 Service Pack 2 (SP2) environment that is packaged as a Hyper-V image. The VME should be run as a stand-alone environment for the sole purpose of migrating Microsoft Office Project Server 2003 data to the Office Project Server 2007 data format (it does not have to be connected to the network).

Warning:

Do not use the VME for production use. It is intended to be used only as a pass-through environment to migrate your Project Server 2003 data to Office Project Server 2007.

The VME image contains the following:

  • Office Project Server 2007 with SP2 with the October 2009 Cumulative Update

  • Microsoft Office SharePoint Server 2007 with Service Pack 2 (SP2) with the October 2009 Cumulative Update

  • Windows SharePoint Services 3.0 with Service Pack 2 (SP2) with the October 2009 Cumulative Update

  • Microsoft Office Project Professional 2007 with Service Pack 2 with the Migration Tool installed.

  • SQL scripts that were developed to find potential upgrade issues

  • Windows Server 2008 R2

  • Microsoft SQL Server 2005 with Service Pack 3 and Cumulative Update 17

See the Virtual Migration Environment (VME) home page in the Microsoft Download Center to download the VME virtual machine image and the VME guide. For detailed documentation about using the Project Server VME, see Virtual migration environment (VME) guide for Project Server 2010.


Deploy Project Server 2010 updates

Published: January 27, 2011

This section describes how to deploy a cumulative update for Microsoft Project Server 2010 and it also discusses specific cumulative updates.

In this section:

  • Deploy cumulative updates (Project Server 2010)

  • TechNet Webcast: Information About Microsoft Project and Project Server Cumulative December 2010 Update (Level 200)

  • Deploy Service Pack 1 for Project Server 2010

  • Deploy Service Pack 2 for Project Server 2010


Deploy cumulative updates (Project Server 2010)
See Also

Published: May 16, 2012

Get cumulative updates for a Project Server 2010 deployment.

The most recent available cumulative update is the Project Server 2010 cumulative update package for June 2013. The full list of Microsoft Project Server 2010 cumulative updates can be found in the Available cumulative updates section in this article.

What are cumulative updates?

Cumulative updates are a method of providing hotfix releases on a scheduled delivery basis. Through this model, hotfixes are released every two months in the form of a downloadable package of current and previous hotfixes. The primary goal is to deliver high-quality fixes on a predictable schedule. The updated releases are accompanied by a Knowledge Base article describing the contents of the update.

The hotfixes found in a cumulative update include the following:

  • Fixes for issues that meet hotfix acceptance criteria. These criteria include workaround availability, customer impact, reproducibility, the complexity of the code that must be changed, and other criteria.

  • Any critical on-demand hotfixes released to date.

  • Any critical security or non-security updates released publicly to date.

Cumulative updates apply to all versions of Project Server 2010 that are currently in mainstream support. For general information about Microsoft product support, visit the Microsoft Support Lifecycle Web site (http://go.microsoft.com/fwlink/p/?LinkID=147498).

Plan to install Project Server cumulative updates

We recommend that you review Project Server cumulative updates as they are released to determine whether any of the issues that are fixed are affecting your environment. Note that Project Server cumulative updates contain fixes from any previous cumulative update packages. Therefore, if you install the latest cumulative update to fix a problem that you are currently experiencing, then you are also applying hotfixes from previously released cumulative updates. Always refer to the cumulative update's Knowledge Base (KB) article for more information about what it contains.

Some Project Server 2010 updates depend on Microsoft SharePoint Server 2010 updates. Install the associated SharePoint Server 2010 cumulative updates at the same time that you install the Project Server cumulative updates. (You only need to run the SharePoint Products Configuration Wizard once per server after you install both updates. For more information, see Installation steps.)

Before you start

Before you install a cumulative update to your Project Server deployment, take these recommended actions:

  • Back up the farm before you start the installation. Cumulative updates cannot be uninstalled, so if you have to return to your previous deployment, you will have to restore the farm backup.

    Note:

    For more information about how to perform backups, read Back up and restore databases (Project Server 2010).

  • Stop the World Wide Web Publishing Service (w3svc) on all the Web servers to disconnect all the users from the server farm. In server farms with multiple front-end Web servers, end-users will be unable to browse the Web sites when files and databases have been updated on the first front-end Web server while the other Web servers still contain previous files and databases.

  • As a best practice, stop the Project Queue service before installing a cumulative update. This ensures that nothing processes while the update is being installed.

Important:

You cannot use Automatic Updates to install any cumulative updates on Project Server 2010.

Update a basic installation

To install a Project Server cumulative update on a basic installation of Project Server 2010 (that is, the single-server installation that has Microsoft SQL Server 2008 Express), do the following:

  1. Disconnect users from the server by stopping the World Wide Web Publishing service (w3svc) on the server.

  2. Download the Project Server cumulative update file. Run the file. On the Microsoft Software License Terms page, read the terms and then click Click here to accept the Microsoft Software License Terms. Click Continue to install the update files.

  3. When installation of the files is finished, on the confirmation page, click OK.

  4. Run the SharePoint Products Configuration Wizard to complete the installation. To do so, click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint Products Configuration Wizard and complete the steps in the wizard.

  5. On the Configuration Successful page, click Finish.

  6. Make the server available to users by manually starting the World Wide Web Publishing Service (w3svc).

Update a farm deployment

For Project Server 2010 farm deployments, use the following procedures to install the update on each server in your farm.

Installation steps

To update a Project Server 2010 farm deployment with a cumulative update, you must follow these steps:

  1. On all servers in the farm, install the Project Server Cumulative Update files, but do not run the SharePoint Products Configuration Wizard.

  2. On one server in the farm (preferably the one hosting the SharePoint Central Administration Web site), run the SharePoint Products Configuration Wizard to complete the installation on that server.

  3. Run the SharePoint Products Configuration Wizard on each remaining server on the farm, one at a time.

We recommend that you use the farm administrator account to install the update and run the SharePoint Products Configuration Wizard. If you use a different account to install the update, that account must be a domain account that has the following rights and permissions:

  • Member of the Administrators group on the Web server computer

  • Member of the Administrators group on the Microsoft SQL Server computer

You can install the update by logging on to the server directly or by connecting through a terminal services console session.

Install a cumulative update for Project Server in a farm deployment

  1. Disconnect users from the server farm by stopping the World Wide Web Publishing service (w3svc) on all Web servers.

  2. Download the Project Server cumulative update file. You have to install the files on each server in your Project Server farm.

  3. On a server in the farm, run the file. At the Microsoft Software License Terms page, read the terms and then click Click here to accept the Microsoft Software License Terms. Click Continue to install the update files.

  4. When installation of the files finishes, on the confirmation page, click OK.

  5. You must run setup to install new update files for every server in your server farm. If you have multiple servers in your server farm, go to each server in your Project Server farm and repeat steps 2-4 to install the files.

    Note:

    If you are also installing cumulative updates for SharePoint Server, you can install the files now to all servers on the farm. However, do not run the SharePoint Products Configuration Wizard on any of the servers at this point.

  6. After installing the update files on each server in the farm, go to each application server and stop the Microsoft Project Server Queue service (if available).

  7. Use the server that hosts the Central Administration Web site to finish the installation.

    Note:

    We recommend that you finish the software update installation first on the application server that is hosting the Central Administration Web site, then on the other application servers, and then on the front-end Web servers.

    If you host your Central Administration Web site on a front-end Web server, finish the software update installation instead on that front-end Web server, then the application servers, and finally on the remaining front-end Web servers.

  8. On the server that you selected in the previous step, run the SharePoint Products Configuration Wizard to complete the installation. To run the SharePoint Products Configuration Wizard, click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint Products Configuration Wizard and complete the steps in the wizard.

    Important:

    All cumulative update installation files should be installed to all servers in the farm before running the SharePoint Products Configuration Wizard.

  9. On the Configuration Successful page, click Finish.

    Important:

    It is important that the SharePoint Products Configuration Wizard perform its configuration procedures on only one computer at a time. The only exception is if you have detached your content databases and upgraded them before you reattach them to the server farm.

  10. When the cumulative update installation and configuration is complete on all the servers in the server farm, make the farm available to users by manually starting the World Wide Web Publishing Service (w3svc) and Microsoft Project Server Queue service on each server on which you manually stopped those services.

Verify the installation

To verify the success of the installation, do the following after you install the cumulative update:

  • View the currently installed updates in Control Panel. In Control Panel, click Programs, and then click View installed updates. Look under Microsoft Project Server 2010 for hotfixes from the Project Server cumulative update. The hotfix files should be identified with a KB number that corresponds to the specific cumulative update (for example Hotfix for Microsoft Office (KB2394322) corresponds to the October 2010 Project Server cumulative update).

  • Check the upgrade status in SharePoint Central Administration. In Central Administration, click Upgrade and Migration, and then click Check upgrade status. Look for a Status of Succeeded at the time when the update was installed.

  • Review the upgrade log file and verify that the updates to the Web applications were successful. The location of the upgrade log file is shown on the Upgrade Status page in the Selected upgrade session details section.

Note:

Checking the database version is not a reliable method of determining if a Cumulative Update was correctly installed. If no database updates are included in a Cumulative Update, the database version will not change.

Uninstalling cumulative updates

Project Server cumulative updates cannot be uninstalled. Therefore make sure that you back up your farm before applying any cumulative updates.

Important:

As mentioned at the beginning of this article, when you plan to install a cumulative update, be prepared to back up and restore your farm in case a problem should occur during the installation.

Available cumulative updates

This section contains links to the currently available Project Server 2010 cumulative updates. Click a "KB" link in the following list to get a download page for a Project Server 2010 cumulative update. For a list of associated SharePoint Server cumulative updates, see Updates for SharePoint 2010 Products.

June 2013 Project Server 2010 cumulative update

  • 2817530

February 2013 Project Server 2010 cumulative update

  • KB 2767794

December 2012 Project Server 2010 cumulative update

  • KB 2596956

September 2012 Project Server 2010 cumulative update

  • KB 2687354

July 2012 Project Server 2010 cumulative update

  • KB 2598355

April 2012 Project Server 2010 cumulative update

  • KB 2598152

For more information, see TechNet Webcast: Information about Microsoft Project and Project Server April 2012 Software Update (Level 200).

February 2012 Project Server 2010 cumulative update

  • KB 2597152

For more information, see TechNet Webcast: Information about Microsoft Project and Project Server February 2012 Software Update (Level 200).

December 2011 Project Server 2010 cumulative update

  • KB 2597015

For more information, see TechNet Webcast: Information about Microsoft Project and Project Server December 2011 Software Update (Level 200).

October 2011 Project Server 2010 cumulative update

  • KB 2596506

For more information, see TechNet Webcast: Information about Microsoft Project and Project Server October 2011 Software Update (Level 200).

August 2011 Project Server 2010 cumulative update

  • KB 2553049

For more information, see TechNet Webcast: Information about Microsoft Project and Project Server August 2011 Software Update (Level 200).

June 2011 Project Server 2010 cumulative update

  • KB 2536600

April 2011 Project Server 2010 cumulative update

  • KB 2512801

For more information, see TechNet Webcast: Information About Microsoft Project and Project Server May 2011 Software Update (Level 200).

February 2011 Project Server 2010 cumulative update

  • KB 2475879

For more information, see TechNet webcast: Information about Microsoft Project and Project Server Cumulative February Update (Level 200).

December 2010 Project Server 2010 cumulative update

  • KB 2459258

For more information, see TechNet webcast: Information about Microsoft Project and Project Server Cumulative December Update (Level 200).

October 2010 Project Server 2010 cumulative update

  • KB 2394322

For more information, see TechNet webcast: Information about Microsoft Project and Project Server Cumulative October Update (Level 200).

August 2010 Project Server 2010 cumulative update

  • KB 2352345

For more information, see TechNet webcast: Information about Microsoft Project and Project Server Cumulative August Update (Level 200).

June 2010 Project Server 2010 cumulative update

  • KB 2075990

For more information, see TechNet webcast: Information about Microsoft Project and Project Server Cumulative June Update (Level 200).

See Also

Concepts

Deploy Service Pack 1 for Project Server 2010

Other Resources

Updates for Project Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=209620)
Update Center for Microsoft Office, Office Servers, and Related Products
Support for Microsoft Project


TechNet Webcast: Information About Microsoft Project and Project Server Cumulative December 2010 Update (Level 200)

Published: January 27, 2011

This TechNet Webcast provides a brief overview of the recently released Microsoft Project and Project Server Cumulative Update (CU) for December 2010. The Webcast first discusses the updates for the Microsoft Project Server 2010 and Microsoft Office Project Server 2007 server products and the Microsoft Project 2010 and Office Project 2007 desktop products. It then addresses related questions that you might have about these product updates. It also describes the latest content to help you deploy the Microsoft Enterprise Project Management (EPM) Solution.

The presenters for this Webcast are Adrian Jenkins (Program Manager, Microsoft Corporation) and Brian Smith (Senior Support Escalation Engineer, Microsoft Corporation).

TechNet Webcast: Information About Microsoft Project and Project Server Cumulative December 2010 Update (Level 200)

To download the Microsoft PowerPoint presentation used in this Webcast, see the Slide Presentation for "TechNet Webcast: Information About Microsoft Project and Project Server Cumulative December 2010 Update (Level 200) " page on the Microsoft Download Center.

For more information about the Cumulative Update for Project Server 2010, see the Microsoft Knowledge Base article, Description of the Project Server 2010 Cumulative Update Server Hotfix Package (Project server-package): December 31, 2010.

For more information about all Office 2010 December 2010 Cumulative Updates, see the Knowledge Base article, Office 2010 Cumulative Update for December 2010.


Deploy Service Pack 1 for Project Server 2010
See Also

Published: June 28, 2011

This article contains guidance for IT professionals managing the deployment of the Microsoft Project Server 2010 Service Pack 1 (SP1) update to a Project Server 2010 deployment.

In this article:

  • Overview of Microsoft Project Server 2010 Service Pack 1

  • Key Project Server 2010 fixes and improvements for Microsoft Project Server 2010 Service Pack 1

  • Before you begin

  • Install Service Pack 1 on a Project Server 2010 basic installation

  • Update a Project Server 2010 farm installation with Service Pack 1

  • Considerations when you are updating a Project Server 2010 farm deployment to Service Pack 1

  • Update Project Server 2010 Language Packs with Service Pack 1

  • Verify the Service Pack installation

  • Known Issue: Page cannot load when you attempt to edit an existing rule

Overview of Microsoft Project Server 2010 Service Pack 1

The Microsoft Project Server 2010 Service Pack 1 (SP1) package contains updates that are specific to Project Server 2010 and also SP1 updates for Microsoft SharePoint Server 2010 (which is an installation requirement for Project Server 2010).

The Microsoft Project Server 2010 SP1 package contains the following:

  • Previously unreleased SharePoint Server 2010 fixes that were made specifically for this service pack. In addition to general product fixes, these fixes include improvements in stability, performance, and security.

  • Previously unreleased Project Server 2010 fixes that were made specifically for this service pack. In addition to general product fixes, these fixes include improvements in stability, performance, and security.

  • All the SharePoint Server 2010 cumulative updates that have been released through April 2011.

  • All the Project Server 2010 cumulative updates that have been released through April 2011.

To download the Microsoft Project Server 2010 SP1 package, see Description of Project Server 2010 Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=220028).

For detailed information about the Windows Installer .MSP files that are available in the Microsoft Project Server 2010 SP1 package, see the "Microsoft SharePoint and Project Server 2010 SP1" section of Technical details about the SharePoint 2010 and Office Server 2010 SP1 releases. This KB article also includes information about each SharePoint Server 2010 and Office Server 2010 SP1 package.

For a detailed overview of the Service Pack 1 updates for Project Server 2010 and Microsoft Project 2010, see the TechNet Webcast: Information about Project 2010 and Project Server 2010 Service Pack 1 on the Microsoft World Wide Events site.

For detailed information about features and fixes that are available in SharePoint Server 2010, see the white paper Service Pack 1 for SharePoint Foundation 2010 and SharePoint Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=221773).

Note:

The June 2011 Project Server Cumulative Update was released the same date as the Project Server 2010 Service Pack 1 update. We recommend that you install both. The June 2011 Project Server Cumulative Update contains several fixes and improvements that are not contained in the Project Server 2010 Service Pack 1 update. You can install the June 2011 CU before or after you install the Service Pack 1 Update. For more information about the June 2011 Cumulative Update, see Description of the Project Server 2010 cumulative update refresh package (Project server-package): June 30, 2011 (http://support.microsoft.com/kb/2536600). For more information about other Project Server 2010 cumulative updates, see the Updates for Project Server 2010 Resource Center (http://go.microsoft.com/fwlink/p/?LinkID=209620).

Important:

If you installed a version of the Project Server 2010 June 2011 cumulative update that you downloaded prior to June 30, 2011, you must download and install the June 30, 2011 version of this cumulative update. The build number of the Project Server 2010 June 30, 2011 cumulative update package is 14.0.6106.5002. See Description of the Project Server 2010 cumulative update refresh package (Project server-package): June 30, 2011 (http://support.microsoft.com/kb/2536600) to download this cumulative update. After installing the cumulative update, ensure that you run the SharePoint Products Configuration Wizard as you typically would when installing a cumulative update. For more information about installing Project Server 2010 cumulative updates, see Deploy cumulative updates (Project Server 2010).

Note:

Because SharePoint Server 2010 Service Pack 1 is installed with the Project Server 2010 Service Pack 1 package, we also recommend that you install the SharePoint Server 2010 June 30, 2011 cumulative update. For a download and for more information, see Description of the SharePoint Server 2010 cumulative update refresh package (SharePoint server-package): June 30, 2011. For more information about SharePoint Server 2010 updates, see the Updates for SharePoint 2010 Products Resource Center.

Update Project 2010 desktop clients to Service Pack 1

For information about how to update Microsoft Project Professional 2010 and Project 2010 desktop clients to Service Pack 1, see the Office Resource Kit TechNet article, Apply Office 2010 Service Pack 1 (SP1). For a description of Project 2010 Service Pack 1, see the knowledge base article, Description of Project 2010 SP1.

Key Project Server 2010 fixes and improvements for Microsoft Project Server 2010 Service Pack 1

In total, over 200 issues are fixed in the Service Pack 1 updates for both Project 2010 and Project Server 2010. Additionally, the Service Pack 1 updates contain a rollup of all fixes that were shipped in all previous cumulative updates. The following are four frequently requested improvements that were included with the Service Pack 1 updates for Project Server 2010 and Project Professional 2010.

  • Additional supported browsers for Project Web App team member pages

  • Improvements to project scheduling in Project Web App

  • Time-phased support for manually scheduled tasks

  • Enhancements for synchronizing Project tasks to SharePoint task lists

  • Support for the use of Microsoft SQL Server 2012 to host farm databases

To see a complete list of all fixes that are included in Microsoft Project Server 2010 Service Pack 1, see the Microsoft SharePoint 2010 and Office Servers Service Pack 1 Changes.xlsx package.

Additional supported browsers for Project Web App team member pages

An important improvement included in Microsoft Project Server 2010 Service Pack 1 is the support of additional browsers for team member pages in Project Web App. This improvement enables team members to view the tasks to which they are assigned, submit their status, and submit timesheets not only through the supported Internet Explorer browsers, but also through Firefox, Apple Safari, and Google Chrome browsers. After you apply Microsoft Project Server 2010 Service Pack 1, team members' pages will be supported in all of the following browser environments:

  • Internet Explorer 9 (32-bit) on Windows 7, Windows Vista, and Windows Server 2008

  • Internet Explorer 8 (32-bit) on Windows 7, Windows Vista, and Windows Server 2008

  • Internet Explorer 7 (32-bit) on Windows Vista, Windows XP, and Windows Server 2003

  • Firefox 3.6.8+ on Mac OS X v10.6, Windows 7 (32-bit/64-bit), Windows Vista SP2, Windows XP SP3, Windows Server 2003 and UNIX/Linux

  • Google Chrome 6.0 on Windows 7

  • Apple Safari 5 on Mac OS X v10.6

The team member pages that are supported with these additional browsers include the following:

  • Project Web App (PWA) main default page (default.aspx)

  • All pages in the "My Work" section in the Quick Launch. This includes the following:

    • Tasks

    • Timesheets

    • Issues and Risks

Note:

Additional pages in Project Web App (for example, Project Center, Portfolio Analysis) are only accessed through the Internet Explorer browsers listed earlier. If you are using a Macintosh-based computer, see Accessing Project Web App and Project Professional from a Macintosh-based computer for more information about how to access these Project Web App pages.

For more information, see the Microsoft Project Team blog post, Project 2010 SP1 - Multi-Browser Support.

Improvements to project scheduling in Project Web App

Applying Microsoft Project Server 2010 Service Pack 1 enables Project Web App users to edit projects that contain Fixed Work or Effort Driven tasks. In the original release of Project Server 2010, Project Web App users are able to create and edit project plans. However, one limitation with this new capability was that projects that contained Fixed Work or Effort Driven tasks could not be edited through Project Web App. Projects that contained these kinds of tasks could only be edited through Project Professional 2010. Service Pack 1 removes this limitation.

For more information, see the Microsoft Project Team blog post, Project 2010 SP1 - Improvements to Project Scheduling in Project Web App.

Time-phased support for manually scheduled tasks

Applying Microsoft Project Server 2010 Service Pack 1 lets users edit time-phased data for manually scheduled tasks in Project Web App. Manually scheduled tasks are part of the new "User-Controlled Scheduling" feature that was introduced in Project Server 2010 to provide users more control over how tasks are scheduled. Manually scheduled tasks are not affected by the scheduling engine and only move if you manually update them, providing you more control over you schedule. However, until now, users were unable to edit time-phased data within manually scheduled tasks. For example, in manually scheduled tasks, you could not edit work values in the Task Usage View in Project Web App, or report time-phased data in task statusing. Unlike Auto Scheduled tasks, the fields are read-only for manually scheduled tasks. In Project Server 2010, the SP1 update enables all tasks (Auto and manually scheduled) to use time-phased tracking (hours of work done per period) in My Work or Single Entry Mode.

Note:

This functionality is also available in Project 2010 clients through the Office 2010 Service Pack 1 update.

For more information, see the Microsoft Project Team blog post, Project 2010 SP1 - Time-phased Support for Manually Scheduled Tasks.

Enhancements for synchronizing Project tasks to SharePoint task lists

Updating Project Professional 2010 to Service Pack 1 enables client users to synchronize automatically scheduled tasks when they are using the Synchronize to SharePoint feature. The Sync to SharePoint feature lets you synchronize tasks from a project file with a SharePoint task list in Project Professional 2010. One of the caveats of the feature has been that you are limited to synchronizing only with manually scheduled tasks. When you apply the Service Pack 1 update to Project Professional 2010, you are able to synchronize both manually scheduled and automatically scheduled tasks.

For more information, see the Microsoft Project Team blog post, Project 2010 SP1 - Enhancements to Synch to SharePoint Task List.

Note:

Note that this feature is available to Project Professional 2010, and will only be enabled if you apply the Service Pack 1 update to the Project Professional 2010 desktop client. For more information about how to update Project Professional 2010 with the Service Pack 1 update, see the Office Resource Kit TechNet article, Apply Office 2010 Service Pack 1 (SP1).

SQL Server 2012 support

Applying both the Project Server 2010 Service Pack 1 and the SharePoint Server 2010 Service Pack 1 updates to the Project Server 2010 installations in your farm allows you to use the 64-bit version of SQL Server 2012 to host your Project Server 2010 databases. Without the updates, only the 64-bit versions of SQL Server 2005 and SQL Server 2008 are supported.

Note:

For more information about SQL Server 2012, see the SQL Server 2012 home page on Microsoft TechNet.

Before you begin

Before you install Microsoft Project Server 2010 Service Pack 1, take these recommended actions:

  • Back up the farm before you start the installation. Microsoft Project Server 2010 Service Pack 1 cannot be uninstalled, so if you have to return to your previous deployment, you will have to restore the farm backup. For more information about how to perform backups, see Back up and restore databases (Project Server 2010).

    Important:

    The Project Server 2010 Service Pack 1 update cannot be uninstalled.

  • Stop the World Wide Web Publishing Service on all the Web servers to disconnect all the users from the server farm. In server farms with multiple front-end Web servers, end-users will be unable to browse the Web sites when files and databases have been updated on the first front-end Web server while the other Web servers still contain previous files and databases.

  • As a best practice, stop the Microsoft Project Server Queue Service 2010 before you install an update. This ensures that nothing processes while the update is being installed.

Install Service Pack 1 on a Project Server 2010 basic installation

To install Microsoft Project Server 2010 Service Pack 1 on a basic installation of Project Server 2010 (that is, the single-server installation that has Microsoft SQL Server 2008 Express), do the following:

  1. Disconnect users from the server by stopping the World Wide Web Publishing service on the server.

  2. Stop the Microsoft Project Server Queue Service 2010.

  3. Download the Microsoft Project Server 2010 Service Pack 1 update file. Run the file. On the Microsoft Software License Terms page, read the terms and then click Click here to accept the Microsoft Software License Terms. Click Continue to install the update files.

  4. When installation of the files is finished, on the confirmation page, click OK.

  5. Run the SharePoint Products Configuration Wizard to complete the installation. To do so, click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint Products Configuration Wizard and complete the steps in the wizard.

  6. On the Configuration Successful page, click Finish.

  7. Make the server available to users by manually starting the World Wide Web Publishing Service.

Update a Project Server 2010 farm installation with Service Pack 1

For Project Server 2010 farm deployments, use the following procedures to install Microsoft Project Server 2010 Service Pack 1 on each server in your farm.

Installation steps

To update a Project Server 2010 farm deployment with Microsoft Project Server 2010 Service Pack 1, you must follow these general steps:

  1. On each server in the farm, install the Microsoft Project Server 2010 Service Pack 1 files.

  2. After installation of the Service Pack 1 update files is completed on all servers on the farm, on one server in the farm (preferably the one hosting the SharePoint Central Administration Web site), run the SharePoint Products Configuration Wizard to complete the installation on that server.

  3. Run the SharePoint Products Configuration Wizard on each remaining server on the farm, one at a time.

We recommend that you use the farm administrator account to install the update and run the SharePoint Products Configuration Wizard. If you use a different account to install the update, that account must be a domain account that has the following rights and permissions:

  • Member of the Administrators group on the Web server computer

  • Member of the Administrators group on the Microsoft SQL Server computer

You can install the update by logging on to the server directly or by connecting through a terminal services console session.

Install Microsoft Project Server 2010 Service Pack 1 in a farm deployment

  1. Disconnect users from the server farm by stopping the World Wide Web Publishing Service on all Web servers.

  2. Go to each application server and stop the Microsoft Project Server Queue service 2010 (if available).

  3. Download Microsoft Project Server 2010 Service Pack 1.

  4. On a server in the farm, run the Microsoft Project Server 2010 Service Pack 1 update file. At the Microsoft Software License Terms page, read the terms and then click Click here to accept the Microsoft Software License Terms. Click Continue to search for files that have to be updated, and to install the update files.

  5. When installation of Microsoft Project Server 2010 Service Pack 1 finishes, on the "The installation is complete" message box, click OK.

  6. You must run setup to install new Microsoft Project Server 2010 Service Pack 1 update files for every server in your server farm. If you have multiple servers in your server farm, move to each server in your Project Server farm and repeat steps 2-5 to install the files.

    Note:

    Do not run the SharePoint Products Configuration Wizard on any of the servers at this point.

  7. After installing the Project Server 2010 Service Pack 1 binary files on all servers on the farm, you will have to run the SharePoint Products Configuration Wizard on each server on the farm to complete the installation.

    Note:

    We recommend that you complete the Microsoft Project Server 2010 Service Pack 1 installation first on the application server that is hosting the Central Administration Web site, then on the other application servers, and then on the front-end Web servers.

    If you host your Central Administration Web site on a front-end Web server, finish the Microsoft Project Server 2010 Service Pack 1 update installation instead on that front-end Web server, then the application servers, and finally on the remaining front-end Web servers.

    On the server that you selected in the previous step, run the SharePoint Products Configuration Wizard to complete the installation. To run the SharePoint Products Configuration Wizard, click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint Products Configuration Wizard and complete the steps in the wizard.

    Important:

    All Microsoft Project Server 2010 Service Pack 1 installation files should be installed to all servers in the farm before you run the SharePoint Products Configuration Wizard.

  8. On the Configuration Successful page, click Finish.

    Important:

    It is important that the SharePoint Products Configuration Wizard perform its configuration procedures on only one computer at a time. The only exception is if you have detached your content databases and upgraded them before you reattach them to the server farm.

  9. When the Microsoft Project Server 2010 Service Pack 1 installation and configuration is complete on all the servers in the server farm, make the Web servers available to users by manually starting the World Wide Web Publishing Service on each server on which you manually stopped the service.

Considerations when you are updating a Project Server 2010 farm deployment to Service Pack 1

It is important to remember that Project Server 2010 Service Pack 1 also contains Service Pack 1 updates for SharePoint Server 2010, and both are applied automatically during the installation process. For Project Server 2010 Service Pack 1 to be applied successfully, the following two processes have to occur:

  • Patching process: This process updates the SharePoint Server 2010 and Project Server 2010 binary files on the server.

  • Upgrade process: This process upgrades the SharePoint Server 2010 and Project Server 2010 databases. The upgrade process is executed only when you run the SharePoint Products Configuration Wizard.

    Important:

    The Project Server 2010 Service Pack 1 update does not prompt you to run the SharePoint Products Configuration Wizard after the patching process. After the patching process (installation of the Service Pack 1 binary files) has completed on all servers in your farm, you can then run the SharePoint Products Configuration Wizard on each server.

However, a scenario may exist where administrators want to first have the Project Server 2010 Service Pack 1 features and fixes available in their environment, and temporarily bypass updating SharePoint Server 2010. For example, this can occur if the administrator has to schedule a longer down-time period to upgrade the SharePoint Server 2010 databases (which can be very large) to SP1.

This scenario can be achieved if you install Project Server 2010 Service Pack 1 binary files and upgrade only the Project Server 2010 databases. This can be done through the following steps.

  1. On the server, in the Administrative Tools Services page, stop all of the following services:

    • SharePoint 2010 Timer

    • SharePoint 2010 Administration

    • SharePoint 2010 Tracing

    • Microsoft Project Server Queue Service 2010

    • Microsoft Project Server Events Service 2010

  2. Stop Internet Information Services (IIS) on the server.

  3. On the server, run the Project Server 2010 Service Pack 1 update to install the Project Server 2010 and SharePoint Server 2010 Service Pack 1 binary files.

    Important:

    Do not run the SharePoint Products Configuration Wizard. Running the wizard at this point upgrades both the SharePoint Server 2010 and Project Server 2010 databases.

  4. Restart the services on the server:

    • SharePoint 2010 Timer

    • SharePoint 2010 Administration

    • SharePoint 2010 Tracing

    • Microsoft Project Server Queue Service 2010

    • Microsoft Project Server Events Service 2010

  5. Restart IIS on the server.

  6. On the remaining servers in your farm, repeat steps 1-5.

  7. Now that you have installed the Project Server 2010 Service Pack 1 binary files on all servers in the farm, you have to upgrade the Project Server 2010 databases by using a Windows PowerShell cmdlet. On an application server on the farm, open Windows PowerShell and run the following cmdlet: Upgrade-SPProjectWebInstance. This cmdlet creates upgrade changes to the specified Project Web App site in a Microsoft SharePoint Server 2010 farm. You can use the required -URL option to specify the location of the Project Web App instance that performs the database upgrade. For example, Upgrade-SPProjectWebInstance -URL http://Contoso/pwa. After running the cmdlet, wait for the confirmation message "Upgrade of single project site complete". For more information about this Windows PowerShell cmdlet, see Upgrade-SPProjectWebInstance.

    Note:

    The Upgrade-SPProjectWebInstance Windows PowerShell cmdlet is only required to be run on a single application server in your farm. You are not required to run this command on any additional servers in your farm.

  8. On the application server on which you ran the Windows PowerShell cmdlet, in a Command Prompt window, run IISreset /noforce to restart IIS.

Note that, although the SharePoint Server 2010 binary files are updated to SP1, the farm will still function even if the SharePoint Server 2010 databases are not upgraded to SP1 (running in "compatibility mode"). SharePoint Server 2010 features and fixes that are available in SP1 are not available until the SharePoint Server 2010 databases are upgraded to Service Pack 1 (by running the SharePoint Products Configuration Wizard).

You can verify that SharePoint Server 2010 is running in backward compatibility mode by looking at the Manage Database Upgrade Status page. This page shows you the status of databases used in your server farm. If the SharePoint Server 2010 environment is running in backward compatibility mode, the SharePoint Configuration database, and additional content databases, shows a status of "Database is in compatibility range and upgrade is recommended". Once the SharePoint Server 2010 databases are upgraded to match the SharePoint Server 2010 binaries, the status for these databases should be "No action required".

Note:

Running an environment in backward compatibility mode is only intended to be a temporary convenience to help administrators when they deploy the Service Pack 1 update. We suggest that you not run in backward compatibility mode for a long time.

For more information about updates and Backwards Compatibility mode, see Install a software update (SharePoint Server 2010).

Update Project Server 2010 Language Packs with Service Pack 1

The Microsoft 2010 Office Servers Language Pack Service Pack 1 package contains SP1 updates for Office Server 2010 language packs, including SharePoint Server 2010 and Project Server 2010 language packs.

Running the Microsoft 2010 Office Servers Language Pack SP1 package detects any language packs (Project Server 2010 or SharePoint Server 2010) on the server and installs them as needed. For example, your Project Server 2010 English-US installation on the server contains the SharePoint Server 2010 French-France Language Pack, and the Project Server 2010 French-France Language Pack. You will have to install the Microsoft 2010 Office Servers Language Pack SP1 package to update the SharePoint Server 2010 French-France Language Pack and the Project Server 2010 French-France Language Pack.

To download the Microsoft 2010 Office Servers Language Pack SP1 package, see Description of Microsoft 2010 Server Language Pack Service Pack 1 (SP 1) (http://go.microsoft.com/fwlink/p/?LinkId=220137).

The following is the recommended order for installing the Service Pack 1 updates (the Microsoft Project Server 2010 SP1 package and the Microsoft 2010 Office Servers Language Pack SP1 package) on a Project Server 2010 farm with language packs.

  1. On all servers in the farm, install the Microsoft Project Server 2010 SP1 package, but do not run the SharePoint Products Configuration Wizard.

  2. On all servers in the farm, install the Microsoft 2010 Office Servers Language Pack SP1 package, but do not run the SharePoint Products Configuration Wizard.

  3. On one server on the farm (preferably the server hosting the Central Administration site), run the SharePoint Products Configuration Wizard to complete the installation on that server.

  4. Run the SharePoint Products Configuration Wizard on all remaining servers on the farm.

Verify the Service Pack installation

To verify the success of the installation, you can use any of the following methods after you install the service pack update:

  • View the currently installed updates in Control Panel In Control Panel, click Programs, and then click View installed updates. Look under Microsoft Project Server 2010 for "Microsoft SharePoint and Project Server 2010 Service Pack 1 (SP 1)" to verify that the update has been installed. The same update information should be listed under Microsoft SharePoint Server 2010.

    Note:

    If you are running SharePoint Server 2010 in backward compatibility mode and your SharePoint Server 2010 databases are not upgraded to Service Pack 1, the View Installed Updates page still shows "Microsoft SharePoint and Project Server 2010 Service Pack 1 (SP 1)" as an installed update. You can determine whether the SharePoint Server 2010 databases are running in compatibility mode by checking the Manage Database Upgrade Status page on the Central Administration Web site.

  • Check the upgrade status in SharePoint Central Administration In Central Administration, click Upgrade and Migration, and then click Check upgrade status. Look for a Status of Succeeded at the time when the update was installed.

  • Review the upgrade log file and verify that the updates to the Web applications were successful. The location of the upgrade log file is shown on the Upgrade Status page in the Selected upgrade session details section.

Note:

Checking the database version is not a reliable method of determining whether an update was installed correctly. If no database updates are included in the update, the database version does not change.

Known Issue: Page cannot load when you attempt to edit an existing rule

After you apply the Project Server 2010 SP1 update, a known issue may occur in your environment if you have defined approval rules. After you apply the SP 1 update, if you attempt to edit an existing rule, the page cannot load, and a message box displays a general error message: Error - An unexpected error has occurred.

If you view the ULS logs, a corresponding error message appears: 'RULE_AUTOMATIC_PUBLISH' in table 'Rules' is DBNull.

This error occurs because the Project Server 2010 Service Pack 1 update adds a new column, RULE_AUTOMATIC_PUBLISH, to the MSP_Rules table, and all existing rows are left with a null value.

New rules created after you apply the Project Server 2010 Service Pack 1 update are not affected. (They can be edited.)

This error is fixed in the June 2011 Cumulative Update for Project Server 2010. This update is currently available for download and installation. For more information about Project Server 2010 Cumulative Updates, see the Updates for Project Server 2010 Resource Center (http://go.microsoft.com/fwlink/p/?LinkID=209620).

Note:

We recommend that you install the June 2011 Project Server 2010 cumulative update. It will be available the same date as the Project Server 2010 Service Pack 1 update.

As a workaround for this issue, you can delete and then re-create the approval rule.

Another workaround is to resolve the issue by making an update directly to the MSP_RULES table in the Project Server 2010 Published database that holds the rules definitions. Running the following SQL query on the Project Server 2010 Published database changes the null values in the column to false.

Copy Code
Update MSP_Rules
Set RULE_AUTOMATIC_PUBLISH='False'

For more information about additional known issues that you may encounter when you install the Project Server 2010 Service Pack 1 package, see the Knowledge Base article, #2532126 Known issues that you may experience when you install the Microsoft Office 2010 Service Pack 1 and Microsoft SharePoint 2010 Service Pack 1 (http://support.microsoft.com/kb/2532126).

See Also

Other Resources

Description of the Project Server 2010 cumulative update refresh package (Project server-package): June 30, 2011
Apply Office 2010 Service Pack 1 (SP1)
Description of Project 2010 Service Pack 1
TechNet Webcast: Information about Project 2010 and Project Server 2010 Service Pack 1


Deploy Service Pack 2 for Project Server 2010

Published: August 13, 2013

Summary: Deploy the Project Server 2010 SP2 update to an existing Project Server 2010 deployment. This package includes cumulative updates and previous unreleased fixes since June 2011.

In this article:

  • Overview of Microsoft Project Server 2010 Service Pack 2

  • Fixes and improvements in Project Server 2010 Service Pack 2

  • Before you begin

  • Install Service Pack 2 on a Project Server 2010 basic installation

  • Update a Project Server 2010 farm installation with Service Pack 2

  • Considerations when you are updating a Project Server 2010 farm deployment to Service Pack 2

  • Known issues with installing Project Server 2010 Service Pack 2

  • Update Project Server 2010 language packs with Service Pack 2

  • Verify the Service Pack installation

Overview of Microsoft Project Server 2010 Service Pack 2

The Microsoft Project Server 2010 Service Pack 2 (SP2) package contains updates that are specific to Project Server 2010 and also SP2 updates for Microsoft SharePoint Server 2010 (SharePoint Server 2010 is an installation requirement for Project Server 2010).

The Project Server 2010 SP2 package contains the following:

  • All cumulative fixes for Project Server 2010 and SharePoint Server 2010 since Service Pack 1, starting with the June 2011 Cumulative Update (CU) and the July 2011 Public Update (PU) all the way through the corresponding April 2013 CU and May 2013 PU.

    Important:

    See the "Known Issues with installing Project Server 2010 Service Pack 2" section of this article if you currently have the June 2013 Cumulative Update deployed in your environment.

  • Previously unreleased fixes. In addition to general product fixes, these fixes include improvements in stability, performance, and security.

The Project Server 2010 Service Pack 2 package can be downloaded from the Service Pack 2 for Microsoft SharePoint and Project Server 2010 (KB2687452) page in the Microsoft Download Center.

Update Project 2010 desktop clients to Service Pack 2

To view a description of Project 2010 Service Pack 2, see the knowledge base article: Description of Project 2010 SP2. The article also provides you links from which you can download the 32-bit or 64-bit versions of the Project 2010 SP2 update.

Fixes and improvements in Project Server 2010 Service Pack 2

The major enhancement provided through the Project Server 2010 Service Pack 2 package is Windows Server 2012 support for SharePoint Server 2010 and Project Server 2010. Without this service pack, Project Server 2010 was supported only on the Windows Server 2008 and Windows Server 2008 R2 server operating systems.

Important:

Due to required changes to the SharePoint Prerequisite Installer, Service Pack 2 cannot be slipstreamed into installation media for use with installation on Windows Server 2012 systems. Installation of SharePoint Server 2010 with Service Pack 2 on Windows Server 2012 systems requires integrated Service Pack 2 installation media, which will be available after Service Pack 2 is released.

The following are key fixes that are included for Project Server 2010 through the Service Pack 2 update:

  • When tasks are inserted in the middle of the tasks list, renumbering of the work breakdown structure (WBS) codes doesn't update the WBS correctly.

  • Project Professional may crash when copying and pasting in master project.

  • If the "Actual costs are always calculated by Project" option is disabled in Project 2010, remaining cost data at the task level can behave unexpectedly when the task is partially complete.

  • Custom fields not totaling correctly.

  • In the resource usage view, the timephased section of the grid doesn't always change color correctly to indicate when a resource is over-allocated.

  • If you have a server project and on the server you have the "Restrict updates to Project Web Access" option enabled, if you reduce work on a task such that it makes a milestone task and then if you set the task to 100% complete and save the project, the task's Start Date is set to NA and work is added to the task. This will also impact correctly publishing the project to the server.

  • When used in Russian language, Project Enterprise Custom Fields of type Text don't show the value properly in Project Professional.

  • The locally defined custom fields values appear in the enterprise custom fields.

  • If any assignment in the project plan has actual exceptions where the start date and the finish date are the same, publishing the project plan may get stuck indefinitely stuck at "93% completed" state.

  • The number of overdue status report items is incorrect if the system time changes.

  • Time-phased views of cost resources not displaying correctly.

  • Pending task updates are not shown on the Task Updates page.

  • Using the PSI call "QueueAddtoProject" to programmatically add a task to a project can fail if the project plan contains has empty task rows.

  • If there is a cross-project link between two projects, then custom field values for those tasks are not shown correctly.

  • When a user attempts to import timesheet data, the import will fail due to an exception which occurs when trying to apply the timephased data.

  • If you select the option to 'Disable all macros except digitally signed macros' and then restart Project Client, the registry options are set incorrectly, and users are unable to enter task names or update task details.

  • Late Tasks in Project Professional will not appear correctly in the print preview and in the printed output.

  • Actual Costs may not be updated correctly in certain situations.

  • Milestone tasks with non-zero duration can lose their % complete data when other tasks have their % complete changed and the project plan is published.

  • When editing an assignment with a long contour using the PSI or in Project Web App, the project data could become corrupted, preventing future edits to the project plan.

  • A user submits actual overtime work through statusing and subsequently the PM approves it. However when the project is opened in WinProj the remaining work is converted to actual work.

  • The option to create timesheets with "Current Projects" includes all projects, regardless of status. All Completed, Current and Future plans that a user was ever the owner of or had an assignment in, are added to the timesheet.

  • Using the My Tasks page, a user provides actual work updates for a material resource. However after being applied to the project plan, the actual work value for the assignment is incorrect.

  • Booting Project 2010 when connected to a Project 2013 server generates a confusing error message.

  • For months with five Fridays, creating a recurring calendar exception on the last Friday of every month can select the fourth Friday instead of the fifth Friday.

  • If the report contains a custom field with a look up table and the look up table has values which contain the single quote character " ' " then if the user generates a visual report containing this custom field, Project may crash.

  • When you build the Earned value Over Time report in Project Client, the AC values (which should be the same as ACWP) are not correct.

  • Applying updates causes assignments to lose work and tasks to lose duration.

  • When status updates are accepted, the status update job will show that the job completed successfully; however, the update apply process failed and the submitted actuals do not show up in the project plan and subsequent downstream reports.

  • If the "Actual costs are always calculated by Project" option is disabled in Project 2010, for tasks with their finish date before the status date of the project and with resources that have associated cost, the actual cost data can be incorrect.

  • When using Project 2010 to open a file with a timeline from Project 2013, the timeline doesn't display correctly (background timeline bar doesn't show up, and default task color is too light).

  • Time-phased views of cost resources not displaying correctly.

  • When attempting to create yearly recurring calendar exceptions in Project 2010, creation may fail if multiple exceptions occur after the 28th day of the month.

  • When changing the constraint on a milestone task in Project 2010, baseline cost data that had previously been set for that task may be lost.

  • If a user self-assigns a team task and subsequently PM rejects the pending updates when opening the affected plan into Project Professional, any subsequent edits to the plan tasks and assignments will cause publishing of that plan to fail.

  • After accepting status updates into a project plan in Project 2010, tasks linked from external projects can lose their start date data.

  • Costs are not calculated correctly if there are multiple cost rate tables and if actual work entered exceeds the work that was scheduled.

  • When editing a project using the PSI or in Project Web App with greater than 1000 calendar exceptions, scheduling tasks could fail with an InvalidOperationException error.

    Note:

    For a complete listing of issues fixed by Service Pack 2, see Issues Fixed by Service Pack 2 (SP2) in Office and SharePoint 2010.

Before you begin

Before you install Microsoft Project Server 2010 Service Pack 2, take these recommended actions:

  • Back up the farm before you start the installation. Microsoft Project Server 2010 Service Pack 2cannot be uninstalled, so if you have to return to your previous deployment, you will have to restore the farm backup. For more information about how to perform backups, see Back up and restore databases (Project Server 2010).

    Important:

    The Project Server 2010 Service Pack 2 update cannot be uninstalled.

  • Stop the World Wide Web Publishing Service on all the Web servers to disconnect all the users from the server farm. In server farms with multiple front-end Web servers, end-users will be unable to browse the Web sites when files and databases have been updated on the first front-end Web server while the other Web servers still contain previous files and databases.

  • As a best practice, stop the Microsoft Project Server Queue Service 2010 before you install an update. This ensures that nothing processes while the update is being installed.

Install Service Pack 2 on a Project Server 2010 basic installation

To install Microsoft Project Server 2010 Service Pack 2 on a basic installation of Project Server 2010 (that is, the single-server installation that has Microsoft SQL Server 2008 Express), do the following:

  1. Disconnect users from the server by stopping the World Wide Web Publishing service on the server.

  2. Stop the Microsoft Project Server Queue Service 2010.

  3. Download the Microsoft Project Server 2010 Service Pack 2 update file. Run the file. On the Microsoft Software License Terms page, read the terms and then click Click here to accept the Microsoft Software License Terms. Click Continue to install the update files.

  4. When installation of the files is finished, on the confirmation page, click OK.

  5. Run the SharePoint Products Configuration Wizard to complete the installation. To do so, click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint Products Configuration Wizard and complete the steps in the wizard.

  6. On the Configuration Successful page, click Finish.

  7. Make the server available to users by manually starting the World Wide Web Publishing Service.

Update a Project Server 2010 farm installation with Service Pack 2

For Project Server 2010 farm deployments, use the following procedures to install Microsoft Project Server 2010 Service Pack 2 on each server in your farm.

Installation steps

To update a Project Server 2010 farm deployment with Microsoft Project Server 2010 Service Pack 2, you must follow these general steps:

  1. On each server in the farm, install the Microsoft Project Server 2010 Service Pack 2 files.

  2. After installation of the Service Pack 2 update files is completed on all servers on the farm, on one server in the farm (preferably the one hosting the SharePoint Central Administration Web site), run the SharePoint Products Configuration Wizard to complete the installation on that server.

  3. Run the SharePoint Products Configuration Wizard on each remaining server on the farm, one at a time.

We recommend that you use the farm administrator account to install the update and run the SharePoint Products Configuration Wizard. If you use a different account to install the update, that account must be a domain account that has the following rights and permissions:

  • Member of the Administrators group on the Web server computer

  • Member of the Administrators group on the Microsoft SQL Server computer

You can install the update by logging on to the server directly or by connecting through a terminal services console session.

Install Microsoft Project Server 2010 Service Pack 2 in a farm deployment

  1. Disconnect users from the server farm by stopping the World Wide Web Publishing Service on all Web servers.

  2. Go to each application server and stop the Microsoft Project Server Queue service 2010 (if available).

  3. Download Microsoft Project Server 2010 Service Pack 2.

  4. On a server in the farm, run the Microsoft Project Server 2010 Service Pack 2 update file. At the Microsoft Software License Terms page, read the terms and then click Click here to accept the Microsoft Software License Terms. Click Continue to search for files that have to be updated, and to install the update files.

  5. When installation of Microsoft Project Server 2010 Service Pack 2 finishes, on the "The installation is complete" message box, click OK.

  6. You must run setup to install new Microsoft Project Server 2010 Service Pack 2 update files for every server in your server farm. If you have multiple servers in your server farm, move to each server in your Project Server farm and repeat steps 2-5 to install the files.

    Note:

    Do not run the SharePoint Products Configuration Wizard on any of the servers at this point.

  7. After installing the Project Server 2010 Service Pack 2 binary files on all servers on the farm, you will have to run the SharePoint Products Configuration Wizard on each server on the farm to complete the installation.

    Note:

    We recommend that you complete the Microsoft Project Server 2010 Service Pack 2 installation first on the application server that is hosting the Central Administration Web site, then on the other application servers, and then on the front-end Web servers.

    If you host your Central Administration Web site on a front-end Web server, finish the Microsoft Project Server 2010 Service Pack 2 update installation instead on that front-end Web server, then the application servers, and finally on the remaining front-end Web servers.

    On the server that you selected in the previous step, run the SharePoint Products Configuration Wizard to complete the installation. To run the SharePoint Products Configuration Wizard, click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint Products Configuration Wizard and complete the steps in the wizard.

    Important:

    All Microsoft Project Server 2010 Service Pack 2 installation files should be installed to all servers in the farm before you run the SharePoint Products Configuration Wizard.

  8. On the Configuration Successful page, click Finish.

    Important:

    It is important that the SharePoint Products Configuration Wizard perform its configuration procedures on only one computer at a time. The only exception is if you have detached your content databases and upgraded them before you reattach them to the server farm.

  9. When the Microsoft Project Server 2010 Service Pack 2 installation and configuration is complete on all the servers in the server farm, make the Web servers available to users by manually starting the World Wide Web Publishing Service on each server on which you manually stopped the service.

Considerations when you are updating a Project Server 2010 farm deployment to Service Pack 2

It is important to remember that Project Server 2010 Service Pack 2 also contains Service Pack 2 updates for SharePoint Server 2010, and both are applied automatically during the installation process. For Project Server 2010 Service Pack 2 to be applied successfully, the following two processes have to occur:

  • Patching process: This process updates the SharePoint Server 2010 and Project Server 2010 binary files on the server.

  • Upgrade process: This process upgrades the SharePoint Server 2010 and Project Server 2010 databases. The upgrade process is executed only when you run the SharePoint Products Configuration Wizard.

    Important:

    The Project Server 2010 Service Pack 2 update does not prompt you to run the SharePoint Products Configuration Wizard after the patching process. After the patching process (installation of the Service Pack 2 binary files) has completed on all servers in your farm, you can then run the SharePoint Products Configuration Wizard on each server.

However, a scenario may exist where administrators want to first have the Project Server 2010 Service Pack 2 features and fixes available in their environment, and temporarily bypass updating SharePoint Server 2010. For example, this can occur if the administrator has to schedule a longer down-time period to upgrade the SharePoint Server 2010 databases (which can be very large) to SP2.

This scenario can be achieved if you install Project Server 2010 Service Pack 2 binary files and upgrade only the Project Server 2010 databases. This can be done through the following steps.

  1. On the server, in the Administrative Tools Services page, stop all of the following services:

    • SharePoint 2010 Timer

    • SharePoint 2010 Administration

    • SharePoint 2010 Tracing

    • Microsoft Project Server Queue Service 2010

    • Microsoft Project Server Events Service 2010

  2. Stop Internet Information Services (IIS) on the server.

  3. On the server, run the Project Server 2010 Service Pack 2 update to install the Project Server 2010 and SharePoint Server 2010 Service Pack 2 binary files.

    Important:

    Do not run the SharePoint Products Configuration Wizard. Running the wizard at this point upgrades both the SharePoint Server 2010 and Project Server 2010 databases.

  4. Restart the services on the server:

    • SharePoint 2010 Timer

    • SharePoint 2010 Administration

    • SharePoint 2010 Tracing

    • Microsoft Project Server Queue Service 2010

    • Microsoft Project Server Events Service 2010

  5. Restart IIS on the server.

  6. On the remaining servers in your farm, repeat steps 1-5.

  7. Now that you have installed the Project Server 2010 Service Pack 2 binary files on all servers in the farm, you have to upgrade the Project Server 2010 databases by using a Windows PowerShell cmdlet. On an application server on the farm, open Windows PowerShell and run the following cmdlet: Upgrade-SPProjectWebInstance. This cmdlet creates upgrade changes to the specified Project Web App site in a Microsoft SharePoint Server 2010 farm. You can use the required -URL option to specify the location of the Project Web App instance that performs the database upgrade. For example, Upgrade-SPProjectWebInstance -URL http://Contoso/pwa. After running the cmdlet, wait for the confirmation message "Upgrade of single project site complete". For more information about this Windows PowerShell cmdlet, see Upgrade-SPProjectWebInstance.

    Note:

    The Upgrade-SPProjectWebInstance Windows PowerShell cmdlet is only required to be run on a single application server in your farm. You are not required to run this command on any additional servers in your farm.

  8. On the application server on which you ran the Windows PowerShell cmdlet, in a Command Prompt window, run IISreset /noforce to restart IIS.

Note that, although the SharePoint Server 2010 binary files are updated to SP2, the farm will still function even if the SharePoint Server 2010 databases are not upgraded to SP2 (running in "compatibility mode"). SharePoint Server 2010 features and fixes that are available in SP2 are not available until the SharePoint Server 2010 databases are upgraded to Service Pack 2 (by running the SharePoint Products Configuration Wizard).

You can verify that SharePoint Server 2010 is running in backward compatibility mode by looking at the Manage Database Upgrade Status page. This page shows you the status of databases used in your server farm. If the SharePoint Server 2010 environment is running in backward compatibility mode, the SharePoint Configuration database, and additional content databases, shows a status of "Database is in compatibility range and upgrade is recommended". Once the SharePoint Server 2010 databases are upgraded to match the SharePoint Server 2010 binaries, the status for these databases should be "No action required".

Note:

Running an environment in backward compatibility mode is only intended to be a temporary convenience to help administrators when they deploy the Service Pack 2 update. We suggest that you not run in backward compatibility mode for an extended time.

For more information about updates and Backwards Compatibility mode, see Install a software update (SharePoint Server 2010).

Known issues with installing Project Server 2010 Service Pack 2

The updates from the June 2013 Cumulative Update (KB 2855357) will not install on Project Server 2010 Service Pack 2. You will be able to install the August 2013 Cumulative Update to Project Server 2010 SP2. Note that the June 2013 Cumulative Update includes some changes that are not available in Project Server 2010 SP2. If you need those changes, and Project Server 2010 SP2 is already deployed, you will need to wait until the August 2013 Cumulative Update is released and install it to obtain the changes from the June 2013 Cumulative Update. If the June 2013 Cumulative Update is already deployed but Project Server 2010 Service Pack 2 is not, you should wait until the August 2013 Cumulative Update is available and then install the updates from it and Project Server 2013 SP2, in any order.

Update Project Server 2010 language packs with Service Pack 2

The Microsoft 2010 Office Servers Language Pack Service Pack 2 package contains SP2 updates for Office Server 2010 language packs, including SharePoint Server 2010 and Project Server 2010 language packs.

Running the Microsoft 2010 Office Servers Language Pack SP2 package detects any language packs (Project Server 2010 or SharePoint Server 2010) on the server and installs them as needed. For example, your Project Server 2010 English-US installation on the server contains the SharePoint Server 2010 French-France Language Pack, and the Project Server 2010 French-France Language Pack. You will have to install the Microsoft 2010 Office Servers Language Pack SP2 package to update the SharePoint Server 2010 French-France Language Pack and the Project Server 2010 French-France Language Pack.

To more information about the Microsoft 2010 Office Server Language Pack Service Pack 2, see Description of Office Servers 2010 Language Pack SP2. To download the Microsoft 2010 Office Servers Language Pack SP2 package, see the knowledge base article: Service Pack 2 for Microsoft 2010 Server Language Pack (KB2687462).

The following is the recommended order for installing the Service Pack 2 updates (the Microsoft Project Server 2010 SP2 package and the Microsoft 2010 Office Servers Language Pack SP2 package) on a Project Server 2010 farm with language packs.

  1. On all servers in the farm, install the Microsoft Project Server 2010 SP2 package, but do not run the SharePoint Products Configuration Wizard.

  2. On all servers in the farm, install the Microsoft 2010 Office Servers Language Pack SP2 package, but do not run the SharePoint Products Configuration Wizard.

  3. On one server on the farm (preferably the server hosting the Central Administration site), run the SharePoint Products Configuration Wizard to complete the installation on that server.

  4. Run the SharePoint Products Configuration Wizard on all remaining servers on the farm.

Verify the Service Pack installation

To verify the success of the installation, you can use any of the following methods after you install the service pack update:

  • View the currently installed updates in Control Panel In Control Panel, click Programs, and then click View installed updates. Look under Microsoft Project Server 2010 for "Microsoft SharePoint and Project Server 2010 Service Pack 2 (SP 2)" to verify that the update has been installed. The same update information should be listed under Microsoft SharePoint Server 2010.

    Note:

    If you are running SharePoint Server 2010 in backward compatibility mode and your SharePoint Server 2010 databases are not upgraded to Service Pack 2, the View Installed Updates page still shows "Microsoft SharePoint and Project Server 2010 Service Pack 2 (SP 2)" as an installed update. You can determine whether the SharePoint Server 2010 databases are running in compatibility mode by checking the Manage Database Upgrade Status page on the Central Administration Web site.

  • Check the upgrade status in SharePoint Central Administration In Central Administration, click Upgrade and Migration, and then click Check upgrade status. Look for a Status of Succeeded at the time when the update was installed.

  • Review the upgrade log file and verify that the updates to the Web applications were successful. The location of the upgrade log file is shown on the Upgrade Status page in the Selected upgrade session details section.

Note:

Checking the database version is not a reliable method of determining whether an update was installed correctly. If no database updates are included in the update, the database version does not change.


Book excerpt: Post-installation configuration (Project Server 2010)

Published: October 7, 2010

This book excerpt is from Implementing and Administering Microsoft Project Server 2010, published in 2010 by MSProjectExperts, a Microsoft EPM solution consultancy.

Buy this book

Implementing and Administering Microsoft Project Server 2010 is your essential reference guide for installing, configuring and deploying Project Server 2010 to your enterprise. This book begins with the organizational strategies you need to succeed with an EPM deployment and follows through with an implementation plan and step-by-step instructions for installing, configuring and deploying the Project Server 2010 platform to your organization. Loaded with best practices, warnings and tips from Project Sever gurus Gary Chefetz, Dale Howard and Tony Zink, this book sets the gold standard for Project Server implementation.

Authors

Gary L. Chefetz

Dale A. Howard

Tony Zink

Book excerpt: Module Number 05, Post-Installation Configuration

Learning Objectives

After completing this module, you will be able to:

  • Configure Excel Services and PerformancePoint Services for your new Project Server site

  • Configure Secure Store Services for Reporting

  • Install the SQL Server Native Client and Analysis Management Objects

  • Tune SQL Server for best performance

  • Verify Project Server Functionality

Configure SharePoint Service Applications

Now that you have completed the installation procedure in Module 4, you have all the software parts in place where you need them. The next step is to wire them all together so that they can interact with one another as a complete system. For instance, you created a Global Group for Report Authors during the server preparation steps in the previous module, but you now need to connect that global group to the Reporting Database in Project Server, something you couldn't do until you created a Project Server 2010 site on your system. Much of your work in this module involves making that type of connection between the various software components.

Configure Excel Services for Your Project Server Site

You now have a provisioned, but not completely configured, Project Server application and site. You can click the link on the Manage Project Web App Sites page and your new PWA site will launch. After you verify that your site exists, the next step is to configure your system for reporting. Project Server 2010 uses the SharePoint Server 2010 Report Center Web application to provide a central point for hosting reports, dashboards, and report connections. You can create a variety of reports automatically or manually author additional reports as your users require them. The Report Center is driven by Excel Services in SharePoint Server 2010.

Prepare to Configure Excel Services

For report authors to access the Project Server 2010 Reporting database from Excel 2010, they must be a member of the domain global group you created for Report Authors at the beginning of Module 4, and the global group must have db_datareader rights on the reporting database. The login must allow explicit access to the Project Server 2010 Reporting database to get schema information and data. Follow these steps to create the login:

  1. On the computer running SQL Server or another computer with SQL Server Management Studio installed, launch Microsoft SQL Server 2008 SQL Server Management Studio and select the instance of SQL Server containing your Project Server 2010 reporting database and click the Connect button. Expand the Security folder and right-click Logins, and then select New Login from the popup menu as shown in the following figure.

    Figure 5 - 1: SQL Server Management Studio

  2. The system displays the Login-New page shown in CNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFIAZQBmADIANAA4ADAAMwA1ADMANgAxAAAA REF _Ref248035361 \h Figure 5 - 2. Enter the name of the global group as domainname\groupname in the Login name field and click the OK button. If you do not remember the name, you can search for it using the Search button. In the search window, click on the Object Types button and select groups in the resulting window. Type the name of the group in the Enter the object name to select field and click the Check Names button to search. Click the OK button to select the located group.

    Figure 5 - 2: SQL Management Studio Login - New Window

    Project Server Image

  3. Select the User Mapping page. In the Users mapped to this login section, select the checkbox to map your Project Server Reporting database, and in the Database role membership for: section select the checkbox for db_datareader and leave the db_public role selected as shown in the following figure.

    Figure 5 - 3: User Mapping page for SQL Server login

    Project Server Image

  4. Click the OK button to complete the new login, and exit from SQL Management Studio if you like.

Configure Excel Services

Excel Services for SharePoint Server 2010 provides the reporting foundation for Project Server. In a simple sense, Excel Services provides a platform for sharing spreadsheets on the web. Excel Services not only provides a fully interactive presentation layer for Excel Spreadsheets on the web with a similar experience to the Excel client, it also provides a rich security framework within which report authors and administrators can control user access. This functionality includes the ability to secure spreadsheet elements at a granular level; you can secure parts of a spreadsheet while exposing others. For instance, you can show certain users only Summary task information displayed on one sheet in the workbook while preventing them from seeing the detailed task information driving the summary tasks and contained in a different sheet in the workbook.

Microsoft Excel 2010 provides lush new data visualization features and conditional formatting capabilities that allow you to create visually stunning reports. You can then drop these into SharePoint web pages as web parts to create executive and team dashboards to drive decision making and collaboration. Users can interact with spreadsheets on the web using a familiar interface presented through the web using the new Microsoft Office Web Applications. By integrating Project Server with Excel Services, Microsoft has taken the Project Web App interface from offering a paucity of reporting capacity to now providing a limitless data mining experience.

Note:

Project Server 2010 is also compatible with Excel 2007.

Tip:

Discussing Excel Services and focusing only on the way Project Server leverages Excel Services by default is barely scratching the surface of its capabilities within and way beyond your EPM implementation. To be effective as a Project Server administrator, you should learn as much as possible about Excel Services and the business intelligence capabilities that ship with Microsoft SharePoint Server Enterprise Edition.

You build Project Server reports by using Excel Spreadsheets connected to data sources such as the Project Server Reporting database and the Project Server OLAP cubes. Excel connects to data sources by using trusted connections that are defined and stored in a SharePoint document library. To determine the URL for your connection library launch your new Project Web App site and select Business Intelligence from the Quick Launch menu as shown in the following figure.

Figure 5 - 4: Select Business Intelligence from the Quick Launch menu

Project Server Image

The system displays the Business Intelligence Center home page as shown in the following figure.

Figure 5 - 5: Business Intelligence Center Home Page

Project Server Image

Welcome to your new Business Intelligence Center: you have arrived. By this I mean that the Business Intelligence Center is the most important value center Project Server 2010 inherits from the SharePoint Server Enterprise platform. It may take you a while to comprehend the enormity of the opportunity this provides for you to mine and analyze your Project Server data. The new platform allows you to mash-up your project and portfolio data with line of business systems and a vast array of disparate data sources, especially if you select to deploy the Business Data Connectivityservice, also included with SharePoint Enterprise. The tool capabilities presented through combining Excel Services 2010 and PerformancePoint Services 2010, along with all of other conveniences of the SharePoint environment, make business intelligence more accessible to the average business user than ever before.

This becomes the single source of all serious reporting information for your Project Server 2010 environment. The only business analysis that has its own special home resides within the Portfolio Analysis area that supports project portfolio decision making. This specialized feature, previously provided by Microsoft Portfolio Server 2007, is generally not for the average business user. Project Server ships with sample reports and dashboards to form a basic reporting framework upon which you can build your own organization-specific content. You learn more about building Reports and Dashboards in Module 10.

To proceed with your implementation, select the Data Connections link from the Quick Launch menu. On the Data Connections page, select the English (United States) Project Server Data Connections check box. The system displays the Data Connections page shown in the following figure. Hover your mouse pointer to the left of the folder icon for English (United States) or your specific locale and select the check box that appears. Selecting the checkbox automatically selects the Library Tools menu displaying the options on this menu.

Figure 5 - 6: Data Connections Page

Project Server Image

On the Menu, click the View Properties button. The system displays the Data Connections dialog shown in the following figure.

Figure 5 - 7: Data Connections Properties dialog

Project Server Image

On the Data Connections Properties page, right-click the English (United States) Project Server Data Connections link, and then select Properties. The system displays the Properties dialog shown in the following figure.

Figure 5 - 8: Properties dialog

Project Server Image

Notice that the system displays the URL for your Data Connections library, which you need in order to setup a trusted data connection for the library in the steps that follow. On the Properties dialog box, select the Address (URL) value and press Ctrl + C, or right-click the selected text, and then click Copy to harvest the URL. Note that the entire URL is not displayed in the dialog window and you must capture all the text by scrolling if you are using a mouse or click into the URL and press Ctrl + A to select all. Click the Cancel button after you copy the URL to your clipboard. Save the URL to a handy place, such as a new Notepad document, for later use. Then click the Close button on the Data ConnectionsProperties dialog.

With the correct URL of the Data Connections library saved in a handy place, navigate to your SharePoint Central Administration site to setup the trusted connection for Excel Services. From the Central Administration home page, select the Manage service applications link from the Application Management section. The system displays the Service Applications page shown in the following figure.

Figure 5 - 9: Service Applications Page

Project Server Image

Select the Excel Services row by clicking on the non-hyperlink portion of the row. (Note that clicking on the Excel Services hyperlink navigates you off the current page.) With the row selected, click the Manage button on the menu or click the Excel Services link. The system displays the Manage Excel Services Application page shown in the following figure.

Figure 5 - 10: Manage Excel Services Application Page

Manage Excel Services Application

On the Manage Excel Services Application page, click the Global Settings link. Scroll to the bottom of the page, and in the External Data section enter ProjectServerApplication in the Application ID text box as shown in Figure 5-11.

Warning:

You must use "ProjectServerApplication" without the quotes and maintaining the case-sensitivity, as the Secure Store Service application expects this value, and it is embedded in your connection documents, sample reports and templates.

Figure 5 - 11: Enter Application ID

After completing your entry, click the OK button to save your data and return to the Manage Excel Services Application page shown previously in Figure 5-10. On the Manage Excel Services Application page, click the Trusted File Locations link. The system displays the Excel Services Application Trusted File Locations page shown in the following figure.

Figure 5 - 12: Excel Services Application Trusted File Locations Page

Trusted File Locations

Click the Add Trusted File Location link. The system displays the Excel Services Application Add Trusted File Location page shown in the following figure.

Figure 5 - 13: Excel Services Application Add Trusted File Location details page

Project Server Image

Figure 5 - 13: Continued

Project Server Image

In the Address field at the top of the page, enter the URL that you copied for your Business Intelligence Center

http://< servername>/<projectsitename>/ProjectBICenter/Data%20Connections%20for%20PerformancePoint/English%20(United%20States)

substituting your server name for <servername> and your Project Web App site name for <projectsitename>.

  • In the Trust Children section, select the Children trusted check box.

  • In the Allow External Data section underneath External Data, select the Trusted data connection libraries and embedded option.

In the Warn on Refresh section, clear the Refresh warning enabled check box.

Click the OK button to save your entries. The system redisplays the Excel Services Application Trusted File Locations page, with your new trusted location, shown previously in Figure 5 - 12. Click the Central Administration link at the top of the Quick Launch menu to return to the SharePoint Central Administration home page.

From the SharePoint Central Administration home page, click on the Manage service applications link in the Application Management section. The system displays the Manage service applications page shown previously in Figure 5-9. As you did previously, select the Excel Services row without clicking on a link portion of the row, and then click the Manage button on the menu. The system displays the Manage Excel Services Application page shown previously in Figure 5-10. Click the Trusted Data Connection Libraries link. The system displays the Excel Services Application Trusted Data Connection Libraries page shown in the following figure.

Figure 5 - 14: Excel Services Application Trusted Data Connection Libraries Page

Project Server Image

Click the Add Trusted Data Connection Library link. The system displays the Excel Services Application Add Trusted Data Connections Library page shown in the following figure.

Figure 5 - 15: Excel Services Application Add Trusted Data Connection Library Page

Project Server Image

In the Address field, type the URL for the data connection library that you harvested previously. It should be in the following format:

http://<ServerName>/<ProjectSiteName>/ProjectBICenter/Data%20Connections%20for%20PerformancePoint/English%20(United%20States)

Click the OK button to save your new trusted connection.

Configure the Secure Store Service Application

Configure the Secure Store Service Application

The Secure Store Service, formerly known by its code name "Geneva," provides claims-based authentication to the SharePoint environment. The Secure Store Service is the marriage of three Microsoft technologies: 1) Active Directory Federation Services, 2) Windows CardSpace, and 3) Windows Identity Foundation working together to provide a flexible standards-based authentication service that can interact with any business identity system including Active Directory, LDAP-based directories, application-specific identity systems as well as user-centric systems like Microsoft's LiveID.

The Secure Store Service stores information about users connecting from various systems in its own metadata store. The system accepts and issues security tokens, more commonly referred to simply as "tokens," that contain information about the rights of, or "assertions" about, various users to access system objects and data. These "assertions" are collectively referred to as "claims." The Secure Store Service acts as a common security broker that provides a bridge between identity systems, external data stores and service applications running within the SharePoint envelope.

Tip:

Microsoft's best-practice recommendation is to isolate your Secure Store Service deployment as much as possible. If you are deploying within a larger SharePoint farm, you probably planned your architecture by following Microsoft's best practices for deploying SharePoint Server farms. If you haven't already read this guidance, you should review the available SharePoint Server 2010 deployment documentation on TechNet. Microsoft's best-practice recommendations are as follows:

  • Run the secure store service in its own isolated application pool.

  • Run the secure store service on its own application server.

  • Create the secure store database on a different SQL Server than the one hosting your SharePoint Server 2010 databases.

If you are building a small farm to house your Project Server environment on its own server island, then you may not be able to follow these best-practice guidelines, and you may not have the luxury of using multiple SQL Server boxes, but you can isolate these using SQL Server instances. Of course there are licensing impacts to extending your SharePoint Server farm and SQL Server deployments onto additional processors.

Generate a New Encryption Key

The next step is to generate an encryption key for the Secure Store. Because this is the key the system uses to encrypt and decrypt user credentials data housed in the secure store, it deserves careful handling. Be certain to read the following best-practice note before proceeding with this part of the configuration process.

Tip:

Before generating a new encryption key, you should always back up the secure store database. In addition, you should back up the Secure Store database immediately after you create it in the previous steps. Now would be the time to do this.

Tip:

After completing the initial setup of the Secure Store Service, back up your encryption key, and back it up each time you regenerate it.

Tip:

Store the database backup and Encryption Key backup on separate physical backup media. A malicious user must have access to both to compromise the data store.

Warning:

When you regenerate a key, the system re-encrypts the database with the new key. If the key refresh fails, you cannot return to the previous state without both a backup of both the Secure Store Service database and its corresponding key backup.

From the SharePoint Central Administration home page, select the Manage service applications link in the Application Management section. From the Manage Service Applications page, select either link for the Secure Store Service application. The system displays the Secure Store Service Application: SecureStoreService page shown in the following figure.

Figure 5 - 16: Secure Store Service Page

Project Server Image

Notice that the system alerts you that you must generate a key before you can create a new Secure Store Target Application. To generate a new key, click the Generate New Key button in the Key Management section of the menu. The system displays the Generate New Key page shown in the following figure.

Figure 5 - 17: Generate New Key Page

Project Server Image

Enter a passphrase for the encryption key in the Pass Phrase field and confirm it in the Confirm Pass Phrase field. Your pass phrase should consist of upper case and lower case letters as well as one or more numbers and special characters. Click the OK button to submit your pass phrase. After processing momentarily, the system redisplays the Secure Store Service Target Applications page without the stop warning as shown in Figure 5-16. Remain on this page to complete the next procedure.

Create a Secure Store Target Application

In this step, create the Secure Store Target Application. Click the New button in the Manage Target Applications section of the menu. The system displays the Create New Secure Store Target Application page shown in the following figure.

Figure 5 - 18: Create New Secure Store Target Application Page

Project Server Image

In the Target Application ID box, type "ProjectServerApplication" and type a display name for your new Target Application. Enter a valid email address in the Contact E-mail field, and select Group from the Target Application Type pick list. The system automatically selects the None option in the Target Application Page URLsection. Click the Next button to confirm your entries. The system displays the Specify the credential fields for your Secure Store Target Application page shown in the following figure.

Figure 5 - 19: Specify Credentials … Page

Project Server Image

The page defaults to the fields necessary to authenticate with Windows credentials, which include the Windows User Name and Windows Password fields. Notice that you can determine the display name for the fields that you can select from the Field Type pick lists and that you can select the Masked option or delete the default fields. You might use a different set of fields when creating a Target Application for a different application, but for the Project Server Target Application, you will use the defaults. Click the Next button to continue. The system displays the Specify the membership settings page shown in the following figure.

Figure 5 - 20: Specify the membership settings page

Project Server Image

On the Specify the membership settings page, type the username for the Farm Administrator role in the Target Application Administrators field. In the Members field, enter the name of the domain group you created for report viewers. Verify that you entered the correct names by clicking the people icon with the check mark. Click the OK button to continue. The system proceeds to create the Secure Store Target Application. This may take several minutes. When the process completes, the system displays the Target Application page for the Secure Store Service shown in the following figure.

Figure 5 - 21: Target Application page for Secure Store Service

Project Server Image

Select the Secure Store Target application that you just created and click the Set: Credentials button on the ribbon. The system displays the Set Credentials for Secure Store Target Application (Group) page shown in the following figure.

Figure 5 - 22: Set Credentials for Secure Store Target Application

Project Server Image

Enter the service account identity you want to use for the Secure Store application as well as the password for the account in the appropriate entry fields. Click the OK button to set the credentials for your new target application.

Configure the Cube Building Service

The first step in setting up Analysis services for Project Server is to verify that you have the necessary SQL components installed on each server in your configuration. If you installed to an environment with more than one server, you must install SQL client components on servers running the Project Server service application on your farm. If you installed to a single server or if you used the SharePoint Technologies preparation tool, you may already have these components installed on your system. You must install the SQL Server 2008 Native Client and the SQL Server 2008 Analysis Management Objects (AMO) on the server running Project Server 2010, regardless of whether you are using SQL Server 2005 or SQL Server 2008. Project Server 2010 uses the Analysis Management Objects, a departure from the Project Server 2007 approach which used the SQL Server Analysis Services Decision Support Objects (DSO). You must also install the SQL Server 2008 Native Client on the computer running Analysis Services if this is located on a separate machine.

Obtain the Necessary Software Files

Your first objective is to obtain the necessary components for Microsoft downloads. Go to the primary download site at http://www.microsoft.com/downloads and search for "SQL Server feature pack." As Microsoft download locations can change, it is always best to begin with a search, which also allows you to obtain the latest available version.

You can download the SQL Server 2008 Native Client here:

http://go.microsoft.com/fwlink/p/?LinkId=123718&clcid=0x409

You can download the SQL Server 2008 Analysis Management Objects (AMO) here:

http://go.microsoft.com/fwlink/p/?LinkId=130655&clcid=0x409

Note:

If the above links do not work, remember that the Feature Pack for SQL is available for both standard 32-bit (X86) systems and for 64-bit systems (X64). Select the appropriate X64 files for your server.

Install the SQL Server Native Client

To install the SQL Server Native Client components, follow the directions below:

  1. Double-click the MSI Package that you downloaded for the Microsoft SQL Server Native Client (sqlnclix64.msi). The system displays the SQL Server Native Client Setup screen shown in the following figure.

    Figure 5 - 23: SQL Server Native Client

    Project Server Image

  2. Click the Next button. The system displays the SQL Server Native Client End User License Agreement shown in the following figure.

    Figure 5 - 24: SQL Server Native Client EULA page

    Project Server Image

  3. Read the license agreement. In order to continue you must accept the terms; to accept select the I accept the terms in the license agreement radio button and click the Next button to continue the installation. The system displays the Registration Information page shown in the following figure.

    Figure 5 - 25: Registration Information

    Project Server Image

  4. Complete the information on the Registration Information page and click the Next button to continue. The system displays the Feature Selection page shown in the following figure.

    Figure 5 - 26: Feature Selection Page

    Project Server Image

  5. Select the Client Components and, optionally, the Software Developers Kit (SDK) as well. Note that you can view the Disk space requirements for the selected components by clicking on the Disk Cost button. Click the Next button to continue and the system displays the Ready to Install the Program page shown in the following figure.

    Figure 5 - 27: Ready to Install the Program

    Project Server Image

  6. Click the Install button to continue with the installation. The system displays the Installing Microsoft SQL Server Native Client progress dialog shown in the following.

    Figure 5 - 28: Installing Microsoft SQL Server Native Client

    Project Server Image

  7. The system displays the progress dialog until the installation is complete. When it is complete, the system displays the Completing the Microsoft SQL Server Native Client Setup dialog shown in the following figure.

    Figure 5 - 29: Completing the Microsoft SQL Server Native Client

    Project Server Image

  8. Click the Finish button to close the installation window.

Install the SQL Server Management Objects Collection

Complete the following steps to install the Microsoft SQL Server 2008 Management Objects Collection:

  1. Double click on the MSI file that you downloaded to start the installation. After a brief loading period, the system displays the Welcome to the Microsoft SQL Server Management Objects Collection Setup page shown in the following figure.

    Note:

    The screens and steps for installing SQL components may change slightly with each new release from Microsoft. Most steps remain the same from version to version.

    Figure 5 - 30: Object Collections Setup Welcome page

    Project Server Image

  2. On the Welcome to the Microsoft SQL Server Management Objects Collection Setup page, click the Next button to continue the installation. The system displays the License Agreement page shown in the following figure.

    Figure 5 - 31: License Agreement Page

    Project Server Image

  3. On the License Agreement page, read the license agreement. In order to continue you must accept the terms; to accept select the I accept the terms of this license agreement option and then click the Next button. The system displays the Registration Information page shown in the following figure.

    Figure 5 - 32: Registration Information Page

    Project Server Image

  4. On the Registration Information page, enter your name and company. Click the Next button to continue. The system displays the Ready to Install the Program page shown in the following figure.

    Figure 5 - 33: Ready to Install the Program Page

    Project Server Image

  5. On the Ready to Install the Program page, click the Install button to continue the installation. The system displays the Installing Microsoft SQL Server Management Objects Collection installation progress page shown in the following figure.

    Figure 5 - 34: Installation Progress page

    Project Server Image

  6. After the installation completes, the system displays the Completing the Microsoft SQL Server Management Objects Collection Setup page shown in the following figure. Click the Finish button to complete the installation.

    Figure 5 - 35: Completion page

    Project Server Image

Create a SQL Login for the Service Account Running Analysis Services

The cube building service runs under the OLAP Services account. Therefore, the OLAP Services account also needs datareader rights on the Project Server 2010 reporting database. This process is similar to the steps you followed to create a login for the Report Authors global group earlier in this module. If you are using the Farm Administrator account for all services, this step in not necessary as the Farm Administrator account is already the dbo for the databases. If you do need to create a login and assign the necessary rights, complete the following steps:

  1. Using SQL Server Management Studio, connect to the SQL Server instance containing your Project Server reporting database. Expand the Security folder and right click on the Logins folder and select the New Login menu item as shown in the following figure.

    Figure 5 - 36: SQL Server Management Studio New Login

    Project Server Image

  2. The system displays the Login - New page shown in the following figure.

    Figure 5 - 37: SQL Server Login - New Page

    Project Server Image

  3. Enter the service OLAP service account information in the Login name field and then select the User Mapping page in the Select a page section of the window. The system displays the User Mapping page shown in the following figure.

    Figure 5 - 38: User Mapping Page

    Project Server Image

  4. In the Users mapped to this login section of the upper window, select the checkbox for your Project Server Reporting database. In the Database role membership for <databasename> section of the lower window, select the checkbox for db_datareader and leave the public role selected. Click the OK button to complete your entry.

Implement Optional SQL Server Performance Enhancements

There are two SQL Server database settings that are set to OFF by default, but can cause performance issues in your environment if they are turned ON: 1) AUTO_CLOSE and 2) AUTO_SHRINK.

AUTO_CLOSE

This option is set to OFF by default for both SQL Server 2005 and SQL Server 2008, and in all likelihood you will not have to change it. With the AUTO_CLOSE option set to ON, the database engine closes and shuts down when all processes in the database complete and the last user exits the database. Project Server makes and breaks connections to SQL Server repeatedly, so using the AUTO_CLOSE option forces the system to use a lot of system overhead to repeatedly reopen the databases and should not be used for Project Server databases.

AUTO_SHRINK

This option is set to OFF by default for both SQL Server 2005 and SQL Server 2008. When this option is set to ON, the system marks all of the database's files for shrinking, which causes SQL Server to initiate a shrink process automatically when more than 25 percent of the file contains unused space. With the option set to ON your production system will suddenly suffer a performance decline when SQL Server decides it is shrink-time.

To verify the status of these settings for your databases, you can use the following queries respectively:

Copy Code
SELECT DATABASEPROPERTYEX('DatabaseName','IsAutoClose')
GO
SELECT DATABASEPROPERTYEX('DatabaseName','IsAutoShrink')
GO

The system returns a value of 0 for OFF or 1 for ON. To view these properties for all of your databases, use the following query:

Copy Code
SET NOCOUNT ON
SELECT [name] AS DatabaseName
 , CONVERT(varchar(10),DATABASEPROPERTYEX([Name] , 'IsAutoClose')) AS AutoClose
 , CONVERT(varchar(10),DATABASEPROPERTYEX([Name] , 'IsAutoShrink')) AS AutoShrink
FROM master.dbo.sysdatabases
Order By DatabaseName

AUTO UPDATE STATISTICS and AUTO_UPDATE_STATISTICS_ASYNC

By default, the system sets SQL Server databases to enable AUTO UPDATE STATISTICS. This command can run during core business hours when activity on the server is high, affecting performance. With the introduction of SQL Server 2005, Microsoft introduced a new database property, AUTO_UPDATE_STATISTICS_ASYNC, which configures a database to update statistics asynchronously vs. synchronously. Updating statistics synchronously is the default behavior in both SQL Server 2005 and 2008. In synchronous mode, if a query request triggers an AUTO UPDATE STATISTICS event, the query must wait for the system to update the statistics. Once the system completes updating the statistics, the system executes the query. However, if you enable the AUTO_UPDATE_STATISTICS_ASYNC property, the query executes immediately against the existing statistics. At the same time a background request tells the database engine to update the statistics automatically as soon as possible, without preventing any query requests. When the background operation completes, new query requests begin using the new statistics information. This option affects only AUTO UPDATE STATISTICS events, not manually requested statistic updates or statistic updates scheduled through a SQL maintenance plan. To set these property values using SQL Query Manager use the following queries respectively:

Copy Code
ALTER DATABASE DatabaseName SET AUTO_UPDATE_STATISTICS ON
GO
ALTER DATABASE DatabaseName SET AUTO_UPDATE_STATISTICS_ASYNC ON
GO

To change the status of these settings using SQL Server Management Studio, expand the tree in Object Explorer, locate your database, and right click on the database name and select Properties from the popup menu. The system displays the Database Properties page. In the Select a Page pane on the left, select Options. Your Database Properties window should appear similar to the following figure.

Figure 5 - 39: Database Properties Window Options Page Displayed with Default Settings

Project Server Image

In the Automatic options section, set your desired values by clicking into the value column and selecting your value from the dropdown list.

Create Additional TempDB Files

Both Project Server 2010 and Microsoft SharePoint Server 2010 make extensive use of TempDB during SQL transactions. To improve performance, create additional TempDB files. To optimize performance, create an additional TempDB file for each processor (core) in the computer running SQL Server. Create the files on a separate partition from other database files.

Verify Project Server Functionality

Now that the installation and initial configuration process is complete, you should verify system functionality and connectivity. If you have not already done so, you must install the Project Professional 2010 client on at least one workstation to complete the work in this module. Make sure that you apply the same Service Pack level to both the client and the server.

Verifying Project Web App Connectivity

Log in to your workstation using the account that you designated as the Project Server Administrator, which is the only account that has access to your Project Web App site at this time. Enter the URL for your new Project Server installation in your browser to verify that your new Project Web App site loads from a system on your network other than the server where it is installed. The system displays your home page as shown in the following figure. Note that the system welcomes you by login name at the top right of the page.

Figure 5 - 40: Project Web App Home page for an administrator

Project Server Image

You should see a page that has nothing to report in the Reminders section. Figure 5 - 40 reflects a first-time login to a Project Server instance without any data.

Creating a Login Account in Project Professional 2010

During the installation process, Project Server 2010 creates a single Project Server user, which is an administrator-level account. It uses the Windows account that you specified during the installation process in Module 04; typically this is the Farm Service Account or the installation account that you are using. Because your administrator toolkit includes both Project Professional 2010 and Project Web App, you must be able to connect to Project Server using Project Professional 2010. Before you can use Project Professional 2010 in your Project Server environment, you must create a login account for the Project client application on your local machine.

Note:

If you did not specify your own login account during the installation process, you should log in to your workstation using the account you specified as the Project Server Administrator, or first create an account for yourself on the Project Server instance. I cover creating resources and users in Module XX.

You have two options available to you for creating a Project Server login account. You can do this by launching the Microsoft Project Server 2010 Accounts tool under the Office Tools folder in the Office folder from your start menu, or you can launch Project Professional 2010 and complete the following steps:

  1. From Project Professional 2010, click the new File tab and select the Info selection on the left hand navigation menu, and then select the Manage Accounts button in the Project Server Accounts section of the page shown in the following figure.

    Figure 5 - 41: Project 2010 Information Page

    Project Server Image
    Note:

    Notice that the Information Page carries two types of content: 1) Navigation tools for accessing Project Server accounts and the organizer, and 2) Summary information about the current project. If you close the default Project 1 file, the system displays only the navigation buttons and the title becomes simply "Information."

  2. After you click the Manage Accounts button, the system displays the Project Server Accounts dialog shown in the following figure.

    Figure 5 - 42: Project Server Accounts dialog

    Project Server Image

  3. Project Server 2007 users will notice that Microsoft updated this dialog for Project 2010. Click the Add button and the system displays the Account Properties dialog shown in the following figure.

    Figure 5 - 43: Account Properties dialog

    Project Server Image

  4. Enter a friendly name for your new account in the Account Name field and enter a valid URL in the Project Server URL field. You must enter the URL with the http:// or https:// prefix. Select the Set as default account option. Figure 5-43 shows the completed Account Properties dialog for the new account that connects to my organization's Production Project Server instance.

  5. Click the OK button. If you enter a URL using the http:// protocol rather than the secure https:// protocol, the system displays the warning dialog shown in Figure 5 - 44. Ignore the warning unless your server requires a secure URL. Click the Yes button to continue if you see this warning.

    Figure 5 - 44: Security warning dialog

    Project Server Image

  6. The system redisplays the Project Server Accounts dialog with your new account, as shown in the following figure.

    Figure 5 - 45: Project Server Accounts dialog with new account

    Project Server Image

  7. In the Project Server Accounts dialog, select the Choose an account option. This is particularly important if you connect to multiple Project Server instances and if you want to completely control the connection state.

    Tip:

    MSProjectExperts recommends that you always select the Choose an account option. This provides better control for users who connect to multiple instances and allows for better control of off-line feature use.

  8. Create an additional Project Server login account for each instance of your Project Server 2010 system, such as for test or training Project Server instances, and then click the OK button.

After you create your Project Server login account profiles in Project Professional 2010, exit and then re-launch the software. This is a necessary step because creating your login accounts does not connect you to a Project Server instance. The system displays the Login dialog shown in Figure 5 - 46. Because you selected the Choose an account option in the Project Server Accounts dialog, the system allows you to select the Project Server instance for connection. Had you not chosen this option, the system automatically connects to the instance you set as default.

Figure 5 - 46: Login dialog

Project Server Image

The Login dialog pre-selects the account you set as the Default account in the Project Server Accounts dialog. If you wish to connect using a different login account, click the Profile pick list and select a different account as shown in the following figure. Note that the first time you connect to a Project Server instance, the Work Offline option is not available.

Figure 5 - 47: Select a different Profile

Project Server Image
Note:

You can select the Computer profile to use Project Professional 2010 without connecting to a Project Server instance. This causes the software to function in "desktop only" mode and disables all enterprise features.

Click the OK button to connect to your desired Project Server instance. If the system cannot connect to the selected Project Server instance, it displays the Could not connect to Server dialog shown in the following figure.

Figure 5 - 48: Could not connect to Server warning

Project Server Image

If you see the dialog shown in Figure 5-48, click the Cancel button to return to the Login dialog and then click the Cancel button in the Login dialog. At this point, you must troubleshoot the cause of the login problem, which is likely one of the four possible reasons previously shown in the Could not connect to Server warning.

Performing Basic Functional Tests

Now that you have verified basic Project Server connectivity in Project Professional 2010, it is time to confirm that you can exercise basic system input, such as creating, saving, and publishing a project. To verify that you can create and save a project, launch Project Professional 2010 and select the login account that you created in the previous section of this module. Use the Project 1 file that Project opens automatically, or click on the File tab and select the New link from the side menu as shown in the following figure.

Figure 5 - 49: Project Professional with New Project options displayed

Project Server Image

In the Available Templates section, click the Blank project link. The system opens the blank project as shown in the following figure.

Figure 5 - 50: New Project

Project Server Image

Add a few tasks to your new project. Click File, Save and the system displays the Save to Project Server dialog shown in the following figure.

Note:

Note that unless you have selected otherwise, the system defaults all new tasks to "Manually Scheduled," which is a new feature in Project Server 2010. To learn about Manually Scheduled tasks and the other new features in Microsoft Project Professional 2010, refer to the Ultimate Learning Guide to Microsoft Project 2010: Foundations, ISBN: 978-1-934240-13-7.

Figure 5 - 51: Save to Project Server

Project Server Image

Enter a name for your test project in the Name field and then click the Save button. Watch the message in the lower tray of the application frame where the system reports the save status as shown in the following figure. Wait until you see the message "Save completed successfully."

Figure 5 - 52: Save completed successfully

Project Server Image

Next, build a team using enterprise resources in the Enterprise Resource Pool. Select the Resource tab and click the Add Resources button and select the option to Build Team from Enterprise on the menu as shown in the following figure.

Figure 5 - 53: Add resources to project

Project Server Image

The system opens the Build Team dialog shown in the following figure.

Figure 5 - 54: Build Team dialog

Project Server Image

The dialog should contain only one resource, which is your current login. Select the account representing your current logon on the left, and click the Add button in the center of the dialog to add this resource to the team. Click the OK button to complete the action. In your new project schedule, add the current resource to the test tasks you entered in your project using the Resource Names field as shown in Figure 5 - 55. Note that assigning resources using this method is not a best practice for your users, but it is adequate for testing purposes.

Figure 5 - 55: Tasks with Resources Assigned

Project Server Image

Next, click on the Project tab and then click the Project Information button to display the Project Information dialog shown in the following figure.

Figure 5 - 56: Project Information dialog

Project Server Image

In the Start field, set the project start date to today, if it is not the default, using the date picker and then click the OK button. Note that you want to use a current start date so that your new task assignments appear in the current period in PWA.

Next, click on the File tab and select the Publish link to publish the project. The system displays the Publish Project dialog shown in the following figure.

Note:

Project Professional initiates a save job if you haven't saved changes to your project plan immediately prior to publishing. You see this in the status tray at the bottom of the Project Professional window in the same place where the system reports the publish job status.

Figure 5 - 57: Publish Project dialog

Project Server Image

Accept the defaults in the dialog and click the Publish button to continue. The system announces the publish status and percentage in the Status bar at the bottom of the application window. When the system indicates that the Publish job completed successfully, click File, Close. The system displays the dialog shown in the following figure.

Figure 5 - 58: Check-in dialog

Project Server Image

Click the Yes button to check in the project schedule. Launch your Internet Explorer application, if necessary, and navigate to your Project Server home page or refresh this page if you already have it displayed. The page should now look something like the page shown in the following figure. Notice that you now have one or more new tasks assigned to you as highlighted in the figure.

Figure 5 - 59: Project Web App home page after publishing a test project

Project Server Image

Click the Tasks link in the My Work section to go to the Tasks page shown in the following figure. You should see the new assignment(s) in the Tasks page.

Figure 5 - 60: Tasks page showing new task assignments

Project Server Image

Click the Project Center link from the Quick Launch menu. The system opens the Project Center page shown in the following figure. You should see your test project in this view.

Figure 5 - 61: Project Center Page

Project Server Image

On the Project Center page, make sure that your test project is selected in the grid, or select the project by clicking on the row header. You can also select any cell in the row that does not contain a hyperlink. (If you click a cell with a hyperlink, you will navigate away from the page.) In the Navigate section in the menu, click the Project Site button to navigate to your new Project site. The system spawns a new window and displays your new site in the window as shown in the following figure.

Figure 5 - 62: New Project Site

Project Server Image

Once you verify that the Project site displays properly, close the Project Site window and return to the Project Web App home page. You have now verified basic Project Server functionality by proving that you can create, save, and publish a project, and that the data is flowing through the system correctly and that the system is creating Project Sites correctly.

Verify Cube Building Capability

Now that you have verified basic functionality for Project Server 2010, you should also verify your ability to build OLAP cubes by configuring your analysis services connection and initiating the first build. To set up the OLAP cube building parameters in the system, navigate to your Project Web App home page and click the Server Settings link in the Quick Launch menu. The system displays the Server Settings page shown in the following figure.

Figure 5 - 63: Server Settings Page

Project Server Image

In the Database Administration section of the Server Settings page, click the OLAP Database Management link. The system displays the OLAP Database Management page shown in the following figure.

Figure 5 - 64: OLAP Database Management Page

Project Server Image

Notice that Project Server 2010 now supports multiple cubes, which means that you can create cubes for specific audiences, such as departments. You can manage all of your cubes from this page. By default, the system creates a single cube configuration entry with generic names. You must configure this entry to actually build a cube. To configure the build settings for a cube for the first time, click the DatabaseName link below the OLAP Database Name header column. The system displays the OLAP Database Build Settings page shown in the following figure.

Figure 5 - 65: OLAP Database Build Settings

Project Server Image

Enter your Analysis Services machine name in the Analysis Services Server field. In the Analysis Services Database to be created field, enter a name for the cube database you want to create (example: <PWAInstanceName>). Note that there are two new sections on this page, Project Department and Resource Department. These allow filtering by department, a new feature in Project Server 2010 that I cover in depth in Module 07. For now ignore these selections, as you must configure your system to use department filtering correctly. Accept the default selection of Use the earliest project start date and the latest project finish date option in the Database Date Range section. For now you can either accept the default selections in the OLAP Database Update Frequency section or deselect the Update Periodically check box, as there is no sense in wasting server resources until you have actual data in the system. Click the Save button to save your cube build settings. The system re-displays the OLAP Database Management page reflecting your changes, as shown in the following figure.

Figure 5 - 66: OLAP Database Management page with saved settings

Project Server Image

On the OLAP Database Management page, select the Cube configuration that you just created and click the Build Now button. Notice that the Status column changes to Processing. If you would like to follow the build progress, click the Processing link to open the Build Status window shown in the following figure.

Figure 5 - 67: OLAP Cube Build Status

Project Server Image

When the cube build completes successfully, your Build Status page should look something like the following figure.

Figure 5 - 68: Build Status window displaying successful cube build completion

Project Server Image

When your initial cube build succeeds, your system is ready to deliver analysis on the portfolio of projects you will soon add to the server. The initial cube build takes practically no time at all because you have only one resource and one project in your database. Expect this process to take much longer as you build up your database of projects and resources. You should revisit the cube settings options after you determine the best time to run the cube building routine, when it does not conflict with other service windows on the server such as daily backups. For now, you have accomplished what you need to verify your configuration; however, you will return to the cube configuration later in the configuration process, after you have configured your system with the custom taxonomic information that makes the information in the cubes interesting and applicable to your users.

Verify Reporting Capability in the BI Center

The final verification step that I suggest you take before proceeding with your Project Server configuration is to verify that your Business Intelligence Center is functioning correctly and you are able to make connections to the sample reports. From Project Web App, select the Business Intelligence link from the My Work section of the Quick Launch menu. The system displays the Business Intelligence Center home page shown in the following figure.

Figure 5 - 69: Business Intelligence Center home page

Project Server Image

From the menu on the left, click on the Sample Reports link. The system displays the Sample Reports page shown in the following figure.

Figure 5 - 70: Sample Reports home page

Project Server Image

Click the link named English (United States) or the appropriate sample reports link for your installation language. The system displays the sample reports page for the language you choose, in my case English as shown in the following figure.

Figure 5 - 71: Sample Reports for English

Project Server Image

Select the SimpleProjectList link to load the Simple Projects List report shown in the following figure. When the system prompts to refresh external data connections, click the Yes button to proceed with displaying the report.

Figure 5 - 72: Simple Projects List report

Project Server Image

You should see the test project that you created earlier in this module showing in the report. You can also test the Resource Capacity report which will contain only one resource at this time. All of the other reports will show no results, as no data exists in the system meeting the selection criteria for the other reports. The main point of this exercise is to verify that you configured Excel Services and the Secure Store Service correctly for normal operations.

Congratulations, you now have a fully functioning SharePoint Server 2010 and Project Server 2010 installation. Next, you take on the more difficult and time-consuming task of configuring your Project Server for your organization's specific requirements. The modules that follow walk you through this process.

Creating Additional Project Server Instances

Creating additional Project Server instances on your farm is quite simple once you have learned how to perform the post installation configuration steps that are the primary subject of this module. Before you create your new Project Server instance, you must consider whether your new instance targets the same audience as your first site, or whether it will serve a different user community. Review this entire topical section before creating an additional instance, to properly prepare yourself and your security environment based on its target audience.

To begin the process of creating an additional Project Server instance, open your SharePoint Central Administration site and click on the Manage service applications link in the Application Management section. The system displays the Manage Service Applications page. Select the Project Server Service Application link and the system displays the Manage Project Web App Sites page shown in the following figure.

Figure 5 - 73: Manage Project Web App Sites

Project Server Image

Click the Create Project Web App Site link, just as you did previously on this page to create your first PWA site in Module 4. The system displays the Create Project Web App Site page shown in the following figure.

Figure 5 - 74: Create Project Web App Site page

Project Server Image

Notice that I gave the site a new name in the Project Web App Path field. Likewise, you must choose a unique value for this field and then change the database names from the default names to a unique and identifiable name for your system. In this case, I chose to prefix the database names with the server and instance name because my SQL Server instance hosts databases from multiple Project Server farms. These identifiable labels display nicely in SQL Server Management Studio. Click the OK button to create your new site. The system returns to the Manage Project Web App Sites page shown in the following figure. Notice that a line item now shows for your new site and the Status field changes as the site provisioning walks through the following steps:

  • Waiting for resources

  • Creating Project Web App Site

  • Provisioning Databases

  • Configuring the new Project Web App Site

  • Provisioned

Figure 5 - 75: Manage Project Web App Sites while provisioning a new site

Project Server Image

Configuring Your New Project Server Instance

Once the system completes the new site provisioning, you must repeat the post-configuration steps you completed for your first PWA site, for your new site. To view the specific steps for each of the following, refer back to the detailed instructions earlier in this module.

  • Add login to Project Server Reporting Database for Domain Global Groups: If you create new domain global groups for a Project Server instance, you must add a login for these groups in SQL Server, repeating the steps you took for your first instance.

  • Add login to Project Server Reporting Database for Secure Store Account: If your new site is intended for a separate audience, you will want to create a new Secure Store Target Application for the new instance. If your new Target Application will use unique credentials, then you must also create a SQL Login for this account following the same steps you used to do this for the first instance.

  • Add a Trusted Data Connection Library to Excel Services: You must now add the URL for your new site's Trusted Data Connection library on the Excel Services Trusted Data Connection Libraries page. The easiest way to accomplish this is to open the existing record, copy the URL and paste it into the Add Trusted Data Connection Library page. Change the portion of the URL that represents the instance name to your new site before saving the record.

  • Add Trusted File locations to Excel Services: As you did with your first site, you must add the two trusted data connection records to your Excel Services Trusted File Locations library. The easiest way to accomplish this is to harvest the URLs from your first two entries and duplicate the entries, changing the portion of the URL that points to the specific instance.

  • Create a SQL Login for the OLAP Services account for the new instance reporting database: Just as for your first instance, the account running OLAP services requires access to the reporting database for the new instance in order to generate the OLAP cube.

  • Implement SQL Server performance settings: Use the same rules you applied to your first instance to your new instance.

    Warning:

    Creating a new instance of Project Server provisions all built-in trusted data connections, templates, and sample reports with the same Secure Store Service ID value "ProjectServerApplication," resulting in all new Project Server instances pointing to the first Secure Store Service Application you created above. In order to segregate Report Readers and Report Authors of various instances, each instance requires its own set of domain global groups and each requires its own Secure Store Target Application; otherwise users automatically gain access to the reporting databases of other instances.

  • Optionally create new domain global groups for report authors and report viewers: I call this an optional step because you must first determine whether you are accommodating a separate security audience in your new site. If your new site serves a distinctly different audience than your first site, you must create new domain global groups to segregate the reporting user authorities for your instances.

  • Optionally create a new Secure Store Target Application for the instance: When your new instance serves a separate audience than your first site, you should create a new Secure Store Target Application for your new site following the steps in the Create Secure Store Target Application earlier in this module. You can use any Application ID you want, but you must alter the connection strings for your Data Connections Library and the documents in the Sample Reports and Templates libraries to point to this Application ID using the following procedure.

Point Data Connections to the new Secure Store Target Application

When you elect to create a separate Secure Store Target Application with a distinct Secure Store Service ID value, you must update the existing SSS ID values for all of the Connection Workbooks, Templates and Sample Reports, which always point to the Application ID "ProjectServerApplication." If you created a new Secure Store Target Application for your new Project Server instance, then you must point your Project Server reporting artifacts at your new Target Application. Before executing the following steps, copy your new Target Application ID to your clipboard to avoid typos, keeping in mind that this data is case-sensitive.

  1. From the Project Web App home page for your new instance, click on the Business Intelligence link on the Quick Launch menu. Click the Data Connections link from the menu on the left and click the English (United States) link or the appropriate link for your system and locale. The system displays the Data Connections page shown in the following figure.

    Figure 5 - 76: BI Center Data Connections page (partial)

    Project Server Image

  2. From the Data Connections page, select the first data connection document link, or hover over the link and select the Checkout option. Once the system completes the checkout operation, select Edit in Microsoft Excel from the same menu. The system launches Excel. Enter your logon credentials if the system prompts. Click the Enable button if you see the warning shown in the following figure.

    Figure 5 - 77: Excel Security Warning

    Project Server Image

  3. After you click the Enable button, the system displays the selected workbook in Excel as shown in the following figure.

    ProjServerPostInstallConfig78

    Project Server Image
    Warning:

    If you do not checkout the document first, it opens in Read-Only mode. To edit the document, click the Edit Workbook button in the warning band below the ribbon menu. You must checkout the document before you can complete the final steps in this procedure.

  4. Select the Data tab and select Connections from the Connections section of the ribbon. The system displays the Workbook Connections dialog shown in the following figure.

    Figure 5 - 79: Workbook Connections Dialog

    Project Server Image

  5. In the Workbook Connections dialog, click the Properties button. The system displays the Connection Properties page. Select the Definition tab to display the connection details as shown in the following figure.

    Figure 5 - 80: Connection Properties Page Definition Tab

    Project Server Image

  6. Click the Authentication Settings button in the Excel Services section of the page. The system displays the Excel Services Authentication Settings dialog shown in the following figure.

    Figure 5 - 81: Excel Services Authentication Settings dialog

    Project Server Image

  7. In the SSS ID field, change the Application ID to the one that you assigned to your new Secure Store Target Application for your new instance. Click the OK button to return to the Connection Properties page shown previously in Figure 5-80. On the Connection Properties page, click the Export Connection File button. The system opens the Excel File Save dialog shown in the following figure.

    Figure 5 - 82: Excel File Save dialog

    Project Server Image

  8. Click the Save button to save the new .odc file to a directory on your local machine. Click the OK button to close the Connection Properties dialog and then click the Close button on the Workbook Connections dialog. Close the workbook, and the system prompts you to save as shown in the following figure.

    Figure 5 - 83: Excel Save Prompt

    Project Server Image

  9. Click the Don't Save button and the system prompts you to check-in the file as shown in the following figure.

    Figure 5 - 84: Prompt to Check-in

    Project Server Image

  10. Click the No button to leave the connection document checked out. Complete the preceding steps for each of the connection documents in the Data Connections Library until you have created new .odc files containing the new Secure Store Target Application pointer for each connection in the library. After you complete the new file set, use the Upload Document button on the Document tab of the ribbon in the Connections Library to upload your new versions of the connection files and check them in after uploading.

Point Reports and Templates to the new Secure Store Target Application

The process for pointing the Sample Reports and Templates to your new Secure Store Target Application is almost identical to the process you follow to re-point the data connection documents, but does not require the export actions described in the final steps required to save and upload new .odc files. Instead, after you check-out and edit the connection authentication value, you can save the document directly back to the SharePoint document library, making this process slightly less complex.

  1. From the Project Web App home page for your new instance, click on the Business Intelligence link in the Quick Launch menu. Click the Sample Reports link from the menu on the left and click the English (United States) link or the appropriate link for your system and locale. The system displays the Sample Reports page shown in the following figure.

    Figure 5 - 85: Sample Reports Page

    Project Server Image

  2. Hover over the link to the first report, Deliverables and select Check Out from the drop down menu as shown in the following figure.

    Figure 5 - 86: Check Out Report

    Project Server Image

  3. The system displays the dialog shown in the following figure.

    Figure 5 - 87: Internet Explorer Prompt

    Project Server Image

  4. Click the OK button to continue.

  5. Once again, hover over the link to reveal the menu and select the Edit in Microsoft Excel link from the menu. The system opens the sample report in Excel as shown in the following figure.

    Figure 5 - 88: Sample Report Open in Excel

    Project Server Image

  6. Notice the Security Warning above the data grid. Click the Enable Editing button in the warning band to continue. The display changes as shown in the following figure.

    Figure 5 - 89: Sample Report after Enabling Editing

    Project Server Image

  7. Notice that the Security Warning changes. You do not have to refresh the data connection by clicking the Enable Content button for this workbook at this time, as you are about to make a slight change to the connection properties. Click on the Data tab and then click in the Connections link from the Connections section of the Data ribbon. The system displays the Workbook Connections dialog shown in the following figure. Note that this is the same dialog shown in Figure 5 - 79and that the next three steps are identical to changing the properties for the Data Connection documents, but repeated here for your convenience.

    Figure 5 - 90: Workbook Connections dialog

    Workbook Connections dialog

  8. Click the Properties button and the system displays the Connection Properties page shown in the following figure. Select the Definition tab in the center of the page.

    Figure 5 - 91: Connection Properties for Deliverables Sample Report

    Connection Properties for Deliverables Sample Rept

  9. Click the Authentication Settings button in the Excel Services section of the page. The system displays the Excel Services Authentication Settings dialog shown in the following figure.

    Figure 5 - 92: Excel Services Authentication Settings dialog

    Excel Services Authentication Settings dialog

  10. In the SSS ID field, change the Application ID to the one that you assigned to your new Secure Store Target Application for your new instance. Click the OK button to return to the Connection Properties page shown previously in Figure 5-91. Click the OK button on the Connections Properties page. If the system displays the Microsoft Excel Security Notice shown in the following figure, click the OK button to ignore the warning.

    Figure 5 - 93: Excel Security Notice

    Excel Security Notice

  11. The system then displays the Microsoft Excel notice shown in the following figure, to warn you that you are changing the data connection. As you want to do this, click the Yes button to accept the change.

    Figure 5 - 94: Connection Change Warning

    Connection Change Warning

  12. The system returns you to the Workbook Connections dialog shown previously in Figure 5-90, click the Close button to close the page. In the Workbook, click File, Save, to save the workbook. Then use File, Close to close the workbook. Click the Yes button when the system prompts you to check-in the file and add version comments if you desire. You must repeat this process for every Sample Report and Report Template in both the Sample Reports and Templates libraries. Once you have pointed your reporting artifacts to use your new Secure Store Target Application, you can segregate reporting authorities between instances.

You can not only use this technique to segregate authentication authorities between instances, you can also use this technique to segregate authentication authorities within a Project Web App instance. This is a very powerful construct that provides you with enormous flexibility in targeting your reports and available data connections to specific audiences using Excel Services and the Secure Store Service in SharePoint Server 2010.


Operations for Project Server 2010
See Also

Published: May 12, 2010

This article provides links to articles about operations.

In this section:

  • Project Server 2010 Administrator's Guide

    Microsoft Project Server 2010 administrators must manage many tasks in the Microsoft Project Web App (PWA) Server Settings page for users to access and interact effectively with data. The Microsoft Project Server 2010 Administrator's Guide helps your organization understand these tasks that are involved with administering Microsoft Project Server 2010.

  • Server Settings (Project Server 2010)

    This section helps your organization understand the tasks involved with administering Project Server 2010.

  • Back up and restore databases (Project Server 2010)

    This chapter covers backing up and restoring databases, including the prerequisites for performing these tasks.

  • Project backup and recovery (Project Server 2010)

    This chapter covers backup and recovery operations for Project Server 2010, including migrating a Project Web App instance and backing up and restoring a Project Server farm.

  • Database maintenance plans for Project Server 2010

    This chapter contains information and guidelines for maintaining the databases that host Project Server 2010. It describes and provides examples of the database maintenance tasks that we recommend when you are using Project Server 2010.

  • Database management (Project Server 2010)

    This section covers database maintenance procedures.

  • Use Project Web App (Project Server 2010)

    This section describes how to configure and use Project Web App. Content is designed for team members, project managers, portfolio managers, and site administrators.

  • Add or remove Project Web App Web Parts for a site in the Project Web App site collection (Project Server 2010)

    This article describes how to add or remove a Microsoft Project Web App Web Part from a Web site that resides in the same site collection as the Project Web App (PWA) instance.

  • Add Project Web App Web Parts to a site not within the Project Web App site collection (Project Server 2010)

    This article describes how to add Microsoft Project Web App Web Parts to a site that is not in a Project Web App (PWA) site collection.

  • Best practices for managing a large number of resources in Project Server 2010

    This article describes best practices for managing users in a Microsoft Project Server 2010 environment when you have projects that have a large number of users.

See Also

Concepts

Migrate a Project Web App instance in Project Server 2010


Project Server 2010 Administrator's Guide

Published: March 3, 2011

Microsoft Project Server 2010 administrators must manage many tasks in the Microsoft Project Web App (PWA) Server Settings page for users to access and interact effectively with data. The Microsoft Project Server 2010 Administrator's Guide helps your organization understand these tasks that are involved with administering Microsoft Project Server 2010. It includes many step-by-step procedures and accompanying user-interface screen shots of Project Web App. The format of this guide resembles the Project Server 2003 role guides.

File size: approximately 6 MB

  • Download the guide as a .docx file

  • Download the guide as a .pdf file

  • Download the guide as an .xps file

Book structure

The Microsoft Project Server 2010 Administrator's Guide has eight chapters and four appendixes. You can review these chapters in any order that you want; they are organized in the same manner in this book as they are organized in PWA. Appendix data is primarily reference data and lists.

The Microsoft Project Server 2010 Administrator's Guide contains the following chapters and appendixes:

  • Introduction

  • Chapter 1, "Security"

  • Chapter 2, "Enterprise Data"

  • Chapter 3, "Database Administration"

  • Chapter 4, "Look and Feel"

  • Chapter 5, "Time and Task Management"

  • Chapter 6, "Queue Management"

  • Chapter 7, "Operational Policies"

  • Chapter 8, "Workflow and Project Detail Pages"

  • Appendix A, "Project Server 2010 Category Permissions"

  • Appendix B, "Project Server 2010 Global Permissions"

  • Appendix C, "Project Server 2010 Default Security Groups"

  • Appendix D, "Project Server 2010 Default Categories"


Microsoft Project Server 2010 Project Manager's Guide for Project Web App

Published: January 4, 2012

Summary: The first article in a series of eight articles about how to use Microsoft Project Web App to work with Microsoft Project Server 2010 data and to perform project management-related tasks.

Applies to: Microsoft Project Server 2010 | Microsoft Project Web App

The content of this guide is available two ways:

  1. As a single, downloadable file (in .docx, .pdf, or .xps format). This version includes many screen shots that accompany the procedures in the book. (File size: approximately 3 MB) The .docx version is editable, for allowing you to customize the book for your own needs.

    • Download the guide as a .docx file

    • Download the guide as a .pdf file

    • Download the guide as an .xps file

  2. As a series of eight articles, starting with this one. This version does not include the screen shots that are included in the downloadable file.

Organization of this guide

  • Introduction

  • Chapter 1: Navigating Project Web App

  • Chapter 2: Managing projects in Project Web App

  • Chapter 3: Managing resources in Project Web App

  • Chapter 4: Managing task updates in Project Web App

  • Chapter 5: Managing issues, risks, and documents in Project Web App

  • Chapter 6: Managing status reports in Project Web App

  • Chapter 7: Configuring e-mail notifications and reminders in Project Web App

Send your feedback (projdocs@microsoft.com). Please say what you think about the quality of this content. If this does not meet your needs, let us know how to we can improve it. If this text was helpful, let us know how it helped.

Introduction

This guide helps project managers in your organization to better understand elements of project management in Microsoft Project Web App (PWA), such as the following:

  • Projects

  • Resources

  • Status updates and approvals

  • Project issues, risks, and documents

  • Notifications and alerts sent to project members

Important:

Although Microsoft Project Professional 2010 can be used with Project Server 2010 to perform many project management tasks, this guide only covers procedures done through Project Web App.

In Microsoft Project Server 2010, PWA has new functionality that previously had only been available in Microsoft Project Professional. This table compares the Web-based project management capabilities of Project Web App in Project Server 2010 with those same capabilities in Project Professional 2010.

Project Web App (2010) Project Professional 2010

Multi-resource assignments: Assign more than one resource for a particular task.

Available

Available

Status change updates: Receive updates on status changes that reschedule the project plan.

Available

Available

Keyboard shortcuts: Use keyboard shortcuts for common operations such as indent/insert.

Available

Available

Task hierarchy: Display and render tasks with hierarchical information.

Available

Available

Indent/Outdent: Apply full indenting/outdenting of tasks in a project plan.

Available

Available

Change highlighting: Easily view project changes and all parts of the schedule affected by the change (successor tasks, summary costs, and so on) with change highlighting.

Available

Available

Multi-level undo: Perform what-if analysis and fully understand the effect of changes by reversing and reapplying a whole set of operations, including views, data, and option changes.

Available

Available

Cut/Copy/Paste: Collaborate on schedule development by copying/pasting schedule details between applications.

Available

Available

Flexible views: Move columns to define a specific view.

Available

Available

High fidelity Gantt charts: Create vivid, colorful Gantt charts; customizable Gantt chart styles.

Available

Available

Grouping: Apply multiple grouping rows to a project plan.

Available

Available

Sorting: Sort project plan data by end-users.

Available

Available

Filtering: Ability to filter project plans by any value in the plan.

Available

Available

Automatically scheduled tasks: Indicate tasks (mode) to be scheduled automatically by using the Project scheduling engine.

Available

Available

Manually scheduled tasks: Indicate tasks (mode) to be scheduled manually.

Available

Available

Linking: Create, edit, and delete task dependency relationships.

Available

Available

Zoom in/zoom out: Use zoom controls on the status bar to quickly change the timeline perspective of your project schedules.

Available

Available

Scroll to task: Select a task and then move the task into view on the Gantt chart.

Available

Available

View and edit custom fields: View and edit project metadata by using custom fields.

Available

Available

Project Information: Edit project-level fields and properties.

Available

Available

Edit large projects: No limit to the size of plans that are editable.

Note:

Larger projects may have performance limitations, but no limits are built in.

Available

Available

Import from SharePoint task list: Import data from a SharePoint project task list into a project plan.

Available

Available

Connect to Project Server 2010: Connect to Project Server 2010.

Available

Available

Microsoft Office Fluent™ User Interface: Increase productivity with the ribbon, a tab interface to quickly find and use Project features and controls.

Available

Available

Real-time validation: Mark cell data as invalid while you edit, instead of after you save and validate.

Available

Available

Error handling: Handle invalid data and present data in an easy-to-use interface that helps resolve issues.

Available

Available

Fill down: Drag the bottom-right corner of a cell to repeat data in the cells below.

Available

Available

Percent complete: Mark task progress as a percentage of the assigned work that is completed.

Available

Available

Cost and material resource assignments: Assign Cost Resources or Material Resources to tasks

Note:

Assignments cannot be made through PWA, but previous assignments from Project Professional 2010 are available as Read-Only.

Limited or Read-Only

Available

Inactive tasks: Mark a task as inactive.

Note:

In PWA, tasks marked as inactive in Project Professional 2010 are Read-Only.

Limited or Read-Only

Available

Edit master projects: Edit master projects.

Note:

In PWA, master projects are Read-Only.

Limited or Read-Only

Available

Cross-project links: Create, edit, and delete a dependency relationship with a task in another project.

Note:

In PWA, editing cross-project links is not supported; cross-project links created in Project Professional 2010 are Read-Only.

Limited or Read-Only

Available

Summary task assignment: Create a resource assignment on a summary task.

Note:

In PWA, creating summary task assignments is not supported. Summary task assignments created in Project Professional 2010 are Read-Only in PWA.

Limited or Read-Only

Available

Task calendars: Define a custom calendar associated with a task.

Note:

In PWA, task calendars cannot be used, and project plans created in Project Professional 2010 that contain task calendars are available as Read-Only.

Limited or Read-Only

Available

SharePoint 2010 Project Task Lists: Accept status updates for SharePoint 2010 project task lists.

Note:

In Project Professional 2010, project task list status updates are synchronized/bi-directional with SharePoint Server 2010 after the plan is published. In PWA, project task list status updates are one-way and only occur from the SharePoint project task list to PWA.

Limited or Read-Only

Available

Edit sub-projects: Edit sub-projects inside a master project.

Note:

In PWA, sub-projects cannot be added to a project, and master projects are Read-Only. Sub-projects can be edited separately from a master project.

Limited or Read-Only

Available

Task deadlines: Create deadlines for a task

Note:

In PWA, deadlines are displayed but cannot be created.

Limited or Read-Only

Available

Edit task type: Edit a task type.

Note:

In PWA, task type is not an editable field.

Limited or Read-Only

Available

WBS codes: Define custom Work Breakdown Structure codes.

Note:

In PWA, viewing custom codes is supported, but changing the code definition is not.

Limited or Read-Only

Available

Create baselines: Create a snapshot baseline of the current project plan.

Note:

Baselines created in Project Professional 2010 can be viewed in PWA as Read-Only.

Limited or Read-Only

Available

Time-phased editing: Edit plans and work on a day-by-day basis.

Note:

Time-phased data in manually scheduled tasks can be viewed in PWA as Read-Only.

Limited or Read-Only

Note:

Project Server 2010 Service Pack 1 allows you to edit time-phased values for manually scheduled tasks in PWA.

Available

Fixed work tasks: Define the type of a task as fixed work.

Note:

In PWA, tasks cannot be created as fixed work, and project plans created in Project Professional 2010 that contain fixed work tasks are Read-Only in PWA.

Limited or Read-Only

Note:

Project Server 2010 Service Pack 1 allows you to edit a project plan with fixed work tasks in PWA.

Available

Effort-driven tasks: Edit projects that contain effort-driven tasks.

Note:

In PWA, you cannot edit the effort-driven field. However, a task whose effort-driven field was set in Project Professional will calculate correctly when edited in PWA.

Limited or Read-Only

Note:

Project Server 2010 Service Pack 1 allows you to edit effort-driven tasks in PWA.

Available

Timeline: Build and customize the timeline view to visualize schedule details and communicate with stakeholders.

Available

Team planner: Drag and drop resources in an interactive resource view to simplify complex resource scenarios.

Available

Resource leveling: Recognize and correct resource over-allocation scenarios by using various automatic resource-leveling techniques.

Available

Edit assignment fields: Edit assignment views.

Available

Paste with task hierarchy: Paste hierarchical information that is included, such as indentations.

Available

Network diagram view: View, edit, create, and delete tasks in a network diagramming view.

Available

Task Form View: View, edit, create, and delete tasks in a form view.

Available

Task Information dialog box: See task details by using a dialog interface.

Available

Blank (null) Tasks: Create blank rows (blank, or null, tasks) in a project plan.

Available

Automatic calculation: Schedule the whole project plan, instead of only the current task, without pressing Calculate or F9.

Available

Text formatting: Modify text formatting by using colors and styles.

Available

Edit calendars: Edit calendars for your projects.

Available

Define local custom fields: Define local custom fields by users.

Note:

In PWA, only users who have administrator permissions can define local custom fields.

Available

Split tasks: Split tasks and show them as split in the Gantt chart.

Available

Backstage view: Quickly access Project tools, templates, and program options by using the new Microsoft Office Backstage view.

Available

Assignment units: Change the percentage units for each resource.

Available

Task Inspector: Get analysis and intuitive guidance to resolve scheduling conflicts, which you can choose whether to act upon.

Available

Offline editing: Edit project plans when you are not connected to Project Server 2010.

Available

For information about PWA functionality improvements in Project Server 2010 Service Pack 1, see the Microsoft Project 2010 blog post, Announcing Service Pack 1 for Microsoft Project and Project Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=241595).

For information about how to apply Project Server 2010 Service Pack 1, see Deploy Service Pack 1 for Project Server 2010.

Who should read this book?

This book provides maximum benefits for the following professionals:

  • Project Managers. Those people in your organization who create and maintain projects and tasks, assign resources to tasks, manage approvals for task status and timesheet updates, and configure notifications for project team members.

  • Project Management Office (PMO). Those people who help define and maintain project management standards and practices throughout the organization.

Microsoft Project Server 2010 Administrator's Guide

If you are looking for Project Server 2010 administrative guidance in a role-guide format that resembles this guide, we also have available the Microsoft Project Server 2010 Administrator's Guide. That guide describes tasks that are involved with administering Project Server 2010. It provides many step-by-step procedures (and accompanying user-interface screen shots) about how to manage Project Server 2010 through the Project Web App Server Settings page.

You can download the Microsoft Project Server 2010 Administrator's Guide in .docx, .pdf, or .xps format from the Project Server 2010 Administrator's Guide article in this Microsoft TechNet library.


Navigating Project Web App
See Also

Published: January 10, 2012

Summary: The second article in a series of eight articles about how to use Microsoft Project Web App to work with Microsoft Project Server 2010 data and to perform project management-related tasks.

Applies to: Project Server 2010 | Project Web App

In this article:

  • Introduction to navigating Project Web App

  • Get oriented

  • Key areas

Introduction to navigating Project Web App

Microsoft Project Web App (PWA) is a web-based application that together with Microsoft Project Professional 2010 enables collaborative planning, task updates, issue tracking, risk tracking, and document sharing among workgroup members, project managers, and other stakeholders. It is important that project managers first understand the options available to both themselves and to PWA users.

When you log on to Microsoft Project Web App, you first see your personalized Project Web App home page. This page provides summary information about items assigned to you, plus links to help you navigate throughout the PWA web site.

The home page provides a Quick Launch that you can use to browse to information such as My Work, Projects, Resources, and others. Access to these system features depends on the security model and the role that you are assigned to. Contact the Project Server administrator if there is a function, such as Project Center, that you should see but do not.

The Project Center provides a convenient way for project managers, team members, and other project stakeholders to view detailed information about individual projects and to view summary information about portfolios of projects. Users who have permission to access the Project Center in Project Web App or Project Professional 2010 can use the Project Center to work with any project or portfolio of projects to which they are assigned. Only projects that are published to the Project Server 2010 database are available in the Project Center.

The following table lists the Project Server 2010 permissions that are required for Project Professional 2010 and Project Web App users to work with the Project Center.

Table 1. Required Permissions

Permission Type | Permission | Description
Category | Save Project | Enables users to save projects to the Project Server database from Project Professional 2010
Category | Open Project | Enables users to open and edit their project in the project schedule view in Project Web App
Category | Publish Project | Enables the user to publish the project plan
Category | Save Project to Project Server | Enables the user to save the project schedule to the Project Server
Category | View Projects Summary in Project Center | Enables a user to view projects and project data that is stored in Project Center
Category | View Projects Schedule in Project Web App | Determines the list of projects (and corresponding project details) that are available in the Project Center
Global | Log on to Project Server from Project Professional 2010 | Enables a user to load the Enterprise Global Template when they connect Project Professional 2010 to Project Server
Global | New Project | Enables a user to add a new project to Project Server by using Project Professional 2010, Project Web App or the Project Server Interface (PSI)
Global | View Approvals | Enables a user to view the Approval center in Project Web App
Global | View Project Center | Enables a user to access the Project Center from Project Web App or Project Professional 2010
Global | View Project Schedule View | Enables a user to access and view project details in the Project Center
Global | Manage Check-Ins | Allows a user to check in projects by using the Check in my projects link in the Project Center

Get oriented

The Project Web App interface has three main areas:

  • Quick Launch

  • Ribbon

  • Content display area

The Quick Launch area

The Quick Launch, on the left side of the window, lists the main views and pages that you can access. You can click these links to browse to different areas of the program. Some pages in Project Web App do not include the Quick Launch. For example, when you work on form, you must complete and save the form or cancel out of it in order to return to the Quick Launch.

The ribbon area

Project Server 2010 uses the ribbon interface, which provides a familiar and consistent navigation experience. The ribbon is the toolbar that you use to perform actions on the project information in the content display area. The ribbon replaces the previous navigation design that consisted of menus and toolbar drop-down lists. This is the same navigation ribbon approach used in all Microsoft Office 2010 applications. There may be multiple tabs on the ribbon, to change between different sets of actions. Each tab contains groups of related buttons that you can use to interact with the page content.

For example, the Project Center enables viewing and actions to the summary level project plan. It uses multiple ribbon tabs, based on the actions that you are taking within the Project Center.

The Projects details tab on the ribbon has multiple parts depending on whether the action involves viewing or modifying project information or the project plan schedule.

The Task tab, under Schedule Tools on the ribbon, enables project managers to edit the project schedule in PWA.

The Options tab, under Schedule Tools on the ribbon, has additional functionality for viewing the project schedule details and linking information to the project site.

The content display area

The content display area contains information about your portfolios, projects, and tasks. This is the main focus of each page, and it is where you enter and review data.

Key areas

Project Web App is highly customizable, so your organization can have a unique starting page. By default, the main page that appears when you open Project Web App is a great starting point. It shows information about tasks, timesheets, approvals, status reports, issues, and risks.

There are other useful places to start in Project Web App, depending on what you intend to do while you are logged on. From a project manager perspective, the following are the key areas.

Create projects and schedule tasks

In Project Web App, you can create projects and schedule tasks in the Project Center. On the Quick Launch, under Projects, click Project Center. On the ribbon, click the Projects tab to access the tools that you can use in the Project Center. Here, you can create new projects by using templates or by importing SharePoint lists. On the Projects tab of the ribbon, click the arrow on the New button. Use the list that is displayed to choose which method you want to use to create a new project.

Once you have created a project, you can use the tools on the Project, Task, and Options tabs of the ribbon to work with the project's tasks.

Work with resources

With a project and its tasks created, the next step is to assign the resources that will complete the tasks. In some organizations, a resource manager may be responsible for assigning resources to tasks, but typically this falls on the project manager's plate. In Project Web App, you can add resources and manage your enterprise resource pool in the Resource Center. On the Quick Launch, under Resources, click Resource Center.

Once the resources that you need for the tasks in your project are added to the Resource Center, you can assign them to tasks by using the Project Center. On the Quick Launch, under Projects, click Project Center. Click the name of your project in the list to open it for viewing, check the project out for editing, and then build your team. Pick resources from your team to assign to tasks in your project

Track time and task progress

Some project managers may find time and task progress tracking very important for monitoring project status. As a project progresses, team members assigned to project tasks report how much time they spend on tasks and how much work is left. As the manager of the project where this data is being reported, it is your responsibility to review and approve or reject this time and task progress as it is reported.

The Approval Center provides a central location for approving both time and task progress. On the Quick Launch, under Projects, click Approval Center. Here, you can review the data that has been reported by team members, and then either approve the data, submitting it to the project, or reject it, with notes to help communicate the reason for the rejection.

Other chapters

For more information, see the other chapters in this guide:

  • Managing projects in Project Web App

  • Managing resources in Project Web App

  • Managing task updates in Project Web App

  • Managing issues, risks, and documents in Project Web App

  • Managing status reports in Project Web App

  • Configuring e-mail notifications and reminders in Project Web App

See Also

Concepts

Microsoft Project Server 2010 Project Manager's Guide for Project Web App


Managing projects in Project Web App
See Also

Published: January 10, 2012

Summary: The third article in a series of eight articles about how to use Microsoft Project Web App to work with Microsoft Project Server 2010 data and to perform project management-related tasks.

Applies to: Project Server 2010 | Project Web App

In this article:

  • Introduction to managing projects in Project Web App

  • Using the ribbon to manage projects

  • About the Project Center

  • Creating new projects in PWA

  • Viewing and opening projects

Introduction to managing projects in Project Web App

Managing projects through Project Web App (PWA) is a key responsibility of a project manager. This article describes procedures that a project manager does when she or he manages projects through PWA, including the following:

  • Creating a new project

  • Viewing and opening a project

  • Checking in a project by using the Forced Check-in feature

  • Setting up permissions to project

  • Editing custom fields

  • Changing ownership of a project

  • Exporting Project Center data to Microsoft Excel

  • Modifying a project plan

Using the ribbon to manage projects

The Project Center enables viewing and actions to the summary level project plan. It uses multiple ribbon tabs, based on the actions that you are taking within the Project Center.

The Projects details tab on the ribbon has multiple parts depending on whether the action involves viewing or modifying project information or the project plan schedule.

The Task tab, under Schedule Tools on the ribbon, enables project managers to edit the project schedule in PWA.

The Options tab, under Schedule Tools on the ribbon, has additional functionality for viewing the project schedule details and linking information to the project site.

The Project tab on the ribbon shows different options when the project is in edit mode. It allows project information to be changed.

The Permissions tab on the ribbon is available when a project in the Project Center is selected and the Project Permissions button is clicked. This allows a user who has the necessary project permissions, generally the project manager, to assign rights for the project and project site to individual users or groups not on the project team.

About the Project Center

The Project Center lists all of the projects that are saved and published to the Project Server database that the current user has permission to view. The default view, Summary, lists basic data about the projects. Other views of project data are also available and custom views can also be created.

In the Project Center, you can do the following:

  • View a portfolio of projects or individual projects. You can see summary information about multiple projects or detailed information about individual projects.

  • Project information can be viewed in a detailed or high-level timescale with the ability to apply filters and grouping to different views.

  • Open a project plan in edit or read-only mode in Project Professional or PWA.

  • Update the project with a SharePoint task list.

  • Build a project team from the enterprise resource pool based on the skill levels required for your project and resource availability.

  • Establish a resource plan associated with a project. A resource plan allows you to plan for resource allocation without requiring you to have specific assignments.

  • Set project permissions for individual resources or groups to view or edit your project.

  • Check in checked-out projects.

  • Close specific tasks in a project to no longer allow updates by team members.

  • Project summary and detail information visible in the Project Center view to the left of the Gantt chart can be exported to Microsoft Excel or printed.

  • Access the project site for your individual project, including creating a discussion board, creating a list of related files and documents, creating and updating issues and risks, and setting up a document library.

  • Show or hide subprojects.

  • Update the enterprise project type associated with the project.

You can group and sort the list of Projects to view various types of rolled-up data about any project that you can view, or you can view detailed information about a particular project without opening Project Professional 2010. You can create, modify and assign resources to a project schedule in the Project Center. Additionally, specific functions for particular projects can also be performed. For example, a project manager can check in a project that was not checked in correctly or an executive can view information about a group of projects.

Creating new projects in PWA

You can initiate new project schedules in PWA. You can now begin your project with a blank project plan or an enterprise template that uses project types in Project Server.

Note:

It is important to understand that creating a project from a template in PWA includes not only the project schedule template but also the project workspace template. So if your organization uses different project workspace templates, you should create your project schedule in PWA to make sure that you have the correct project schedule template and workspace template.

To create a new project schedule

  1. In PWA, select Project Center in the Quick Launch.

  2. In the Project Center, on the Projects tab of the ribbon, select New, and then select the appropriate project plan.

  3. A Project Details or Project Information web page appears with project fields to be completed. Specify the related project information in the fields, and then select Save.

    Note:

    Any field name that has a red asterisk (*) next to it is a REQUIRED field and must completed before the project can be saved.

    The project information is saved and PWA opens the Schedule web page. To move between the Project Information/Project Details page and Schedule page, click the link in the left navigation column.

  4. With the Schedule page open, select the Save button on the ribbon.

    A yellow message box appears in the upper-right corner of the project schedule. The box indicates the status of the save operation. After the project is saved to the database, this message will appear: Save completed successfully.

  5. It is important to notice that at this point the project plan is saved in the Project Server draft/working database. It is not visible to others in the PWA Project Center until the project plan has been published. If others must see the plan immediately, select the Publish button in the Schedule Tools tab of the ribbon.

    After the project has been published, a verification message in yellow appears in the upper-right corner of the project schedule: Publish completed successfully.

  6. When you are finished setting up the project plan and have successfully saved and published it, it is time to check in the project plan. Select the Project tab, and then click the Close button. This makes sure that you can modify the project plan in either PWA or Project Professional 2010.

    The Close window appears. Select Yes to check in the project plan.

Viewing and opening projects

You can manage your projects from the Project Center, including tracking associated risks, issues, and documents; linking to the Project Workspace; analyzing and modeling projects; creating to-do lists; and managing Administrative Projects. In addition, you can open projects in Project Professional directly from the Project Center in Project Web App.

Note:

Information and access to specific features is controlled by a set of permissions that a Project Server administrator manages in Project Web App.

Viewing projects

You can view project data that is published to the Project Server database by using the Project Center in Project Web App.

To view project data

  1. Log on to Project Web App. On the Project Web App home page, click Project Center in Quick Launch. The Project Center displays all of the projects that you have permission to view.

  2. A number of viewing options are available on this page. To change the current view, use the View drop-down list to select a view.

  3. To open the detail view for any project, click the project name. You might have to select the Schedule link in the left navigation column to see the project plan.

    This view resembles the view in Project Professional 2010, and the project tasks can be edited in Project Web App by selecting the Edit button in the Schedule Tools, Task tab. This reflects the most recent publication of the project to the Project Server.

    A number of different views at the task level are available in Project Web App. To switch views, use the View drop-down list on the Data tab of the ribbon to select a view. For example, you can select a Resources Work view.

    The views that are available in the View list are customizable. A Project Server administrator can create custom task, resource, and project views by using the Manage Views section of the Server Settings page in Project Web App.

Using the Filter and Group By options in the Project Center

You can use the Filter and Group By drop-down lists to customize how you want to sort and group projects. The Filter and Group By features are useful when the Project Center includes lots of projects. This feature includes the following options:

  • Filter Enables you to filter projects by using a custom filter.

    You can use a custom filter by selecting Custom filter from the Filter drop-down list and defining the custom filter to be used.

    You can also choose to auto-filter tasks by selecting the down arrow to the right of the column heading.

  • Group By Enables you to group projects by specified values. In the Group By drop-down list, either select a single grouping from the available list, which is all of the columns active in the view, or create a custom grouping parameter in the Group by drop-down list. When you create a custom grouping, you can set an additional grouping parameter from the Then by drop-down list. The second parameter filters data within the data that is filtered by first parameter. To remove grouping, select the No Group option in the Group By drop-down list.

Opening projects

You can open projects directly in Project Professional 2010 from the Project Center in PWA as long as all projects that you open from PWA are of the same type (either enterprise or non-enterprise). If you select ten or more projects, you have the option to open them all as either read-only or read/write.

In PWA, click the Project Center link in the Quick Launch to open the Project Center. Select the project plan that you want to open. Select the way that you want to open the project from the Open drop-down list.

Note:

If you open multiple projects, the projects open in Project Professional 2010 as a consolidated master project.

The project opens in Project Professional 2010.

Opening projects as master projects

Use the Open feature in PWA to open two or more projects in Project Professional 2010 from the Project Center in Project Web App as a master (consolidated) project. You can select projects individually in the Project Center or select them as a group by using the group header in the Project Center. If ten or more projects are to be consolidated into a master project in Project Professional 2010, you have the option to open them in a consolidated master project as read-only or as read/write.

When you are working with master projects by opening them from the Project Center, note the following:

  • You can open any number of projects as a master project. But if you attempt to open ten or more projects, you have to select whether you want to open them all as Read/Write or Read Only. Depending on the size of the selected projects, this action can take significant time. If you select Read/Write, you can change the projects and the projects are checked out to you. If you select Read Only, you can view the projects and associated reports, but cannot make changes, and the projects are not checked out.

  • You can save a master project if you want to refer to it frequently. If you save a master project to the Project Server database, give the project a name that other project managers, resource managers, and team members can clearly identify. By clicking the master plan name in the Project Center, you can view the subproject details in Project Web App.

  • To show subprojects in the list of projects visible in the Project Center, in the Projects ribbon, select the check box for Subprojects.

Note:

Only enterprise or non-enterprise projects can be consolidated into Project Professional 2010 as a master project by using the Open Project feature. You cannot create master projects that consist of both enterprise and non-enterprise projects.

Open a master project in Project Professional 2010

In the Project Center in Project Web App, select the projects that you want to open in a master schedule. You can select how you want to open them in the Open drop-down list.

Select two or more projects in the Project Center. You can also select a group of projects by using an Enterprise Project Outline Code heading in the Project Center.

The projects open in Project Professional 2010 as a consolidated project. If any of the projects are checked out to another project manager at the time that you attempt to open the consolidated project, those projects will only be available as read-only projects in Project Professional 2010.

Forced check-in of a project

You might have to force a check-in of a project if a project has been left checked out. For example, this could occur if your connection to Project Server 2010 is interrupted while a project is open or if Project Professional 2010 is closed abruptly before you can check in a project. If a project is left checked out, it is displayed as checked out in the Open from Microsoft Project Server dialog box. You can force a check-in of your own projects by using the Check in my projects link in the Project Center.

You must be granted the Manage Check-Ins permission to access the Force Check-in Enterprise Objects page in Project Web App Server Settings in order to force a check-in of a project in Project Web App. You can use this feature only to check in projects that you checked out; you cannot check in a project that is checked-out to any other user. (Only a Project Server administrator can check in a project that is checked out to any user.)

To force a check-in of a project that you have checked out

  1. In the Project Center in Project Web App, in the Projects tab, click Check in my projects.

  2. Select the project that you want to check in, and then click Check-In.

Note:

If the project is still open in Project Professional 2010, an alert is displayed that indicates the project is no longer checked out and that asks you to either close the project (click OK) or save the project locally (click Cancel, then save locally).

Set up project permissions in PWA

This is a feature in PWA that enables a project manager with access to a specific project to grant groups or individual users access to a plan or project site. This access is generally granted to users/groups that are not a part of the project team, unless it is granted to allow the team member to act as a backup who updates the project plan for the project manager.

After setting up the project plan, return to the Project Center to make sure that stakeholders and management can see the project information.

To set up permissions to a project

  1. Select Project Center quick link, click the cell to the right of the project plan name, and then select the Project Permissions button.

  2. Click the New button to add a user or group to the project permissions.

    The resource pool is too large for the application to return all resources in a list. Specify the name (first or last) in the Name field, and then click the Filter button

    Select the permissions that you want the user or group to have for the project plan and then select Save.

    Note:

    We recommend that a minimum of the last three permissions be granted to Stakeholders and Management for the project.

  3. The user/group and permissions granted for the project are listed. Review the information to make sure that it is correct, and then select the Close button. If additional users who are not part of the project team need access, the project manager can define the level of access that he or she gives to the individual user or group.

Editing custom fields

You can edit or modify your project's information in the Enterprise Project Custom Fields by opening the project details view in the Project Center in Project Web App. The enterprise custom fields can also be modified directly in Project Professional 2010.

To edit a custom field

  1. In the Project Center in Project Web App, click the name of the project plan you want to open. Select the Project Details view in the Quick Launch.

  2. Click the Edit button.

  3. Modify the information in the custom fields that have to be update or changed. Select Save and then Close to check in the project. Closing the project returns you to the Project Center.

Changing ownership of a project

The member of your organization who first saves and publishes a project to the Project Server database is assigned as the owner of that project. You can later change the owner of a project by using Project Web App.

To change ownership of a project

  1. As the current owner, navigate to the Project Center in Project Web App, open the Project Details view by clicking the project plan name.

  2. In the Quick Launch, select Project Details.

  3. On the Project Details page, select the Edit button. In the Owner field, click the Browse button and find the user to whom you want to transfer ownership of the project.

    When you are finished editing project details, click the Save button and then the Close button, and confirm that you want to Check In the project.

  4. The new owner has to open and publish the project.

Exporting Project Center data to Excel

You can export project data to Microsoft Excel 2010 from Project Web App by using the Export to Excel button. Project Web App also enables you to copy data that is displayed in the Project Web App Grid Control and paste it into applications such as Microsoft Excel, Microsoft Word, or Microsoft Access.

Note:

The Project Web App project view has two sections: Project Web App grid data on the left and timesheet data on the right. You have to copy and paste both sections and then align them in the application in which you have pasted the data.

To export Project Center data to Microsoft Excel

  1. In the Project Center in Project Web App, below the grid control, click the Export to Excel button.

  2. A File Download dialog box appears. Select Open.

  3. The Project Center view opens in Excel.

  4. If an Excel message box opens, click Yes to verify the file name extension.

  5. Click Save As on the File menu from Excel if you want to save the data as it is currently presented. You can save the data in any supported Excel format.

    Note:

    You can also export grid data to Excel by using the Print Grid feature.

Modifying project plans in PWA

Project Server 2010 enables the creation and modification of complex schedules online and assigning multiple resources to each task. The ribbon interface provides a familiar and consistent navigation experience regardless of whether the project manager builds the schedule on a desktop or on the web.

To modify a project schedule in PWA

  1. Open Internet Explorer, and then specify the URL.

  2. The Project Web App (PWA) home page opens. Select Project Center in the Quick Launch.

  3. Locate the project plan, and then click the hyperlink that is the project plan name. The project plan details open.

    Select the Schedule link in the Quick Launch. The project plan schedule details appear.

  4. Click the Edit button to modify the project plan.

  5. Click in the bottom Task Name cell in the row to add more rows to the project plan. Click the Mode drop-down arrow to select Auto Schedule or Manually Schedule for the task mode. Specify the task information. Press the Enter key again to create another new task row.

    Note:

    You can change the information that is shown with the task name by using the View drop-down list in the Schedule Tools Task tab.

  6. Select the Save button on the ribbon.

    A yellow message box appears in the upper-right corner of the project schedule, indicating the status of the save operation.

    After the project has been saved to the database, you receive the following message, Save completed successfully.

    At this point the project plan is saved in the Project Server 2010 draft/working database. It is not visible to others in the PWA Project Center until the project plan has been Published. If others must see the plan immediately, select the Publish button on the Schedule Tools tab on the ribbon.

    After the project has been published, a verification message in yellow appears in the upper-right corner of the project schedule, Publish completed successfully.

Adding resources to a project plan

To assign resources to tasks in the project, you must create a project team. You can add enterprise resources to a project team through both PWA and Project Professional by using the Build Team from Enterprise feature.

To add resources to a project plan

  1. After publishing the project plan, select the Project tab, and then click the Build Team button.

  2. A large number of resources are shown when Build Team feature opens. To quickly locate the resources that are needed, apply a Custom Filter. Select the Filter drop-down list, and then click Custom Filter. Apply a filter.

  3. When the filter is applied, select the resource that you want, and then click the Add button. The resource name is added to the project team list in the right column. Click the Save & Close button to save the changes and return to edit mode in Project Center.

  4. In the Project Center edit mode, assign resources to tasks, update task-level custom field information and set up the duration and start date. Note that it is now possible in PWA to assign multiple resources to a single task. However, the unit assignment for the resources is 100% on the task.

    Note:

    After you modify duration, percent complete, link/unlink tasks, and start or finish dates, you must click the Calculate button for many of the changes to be reflected.

  5. You can set up tasks and create project logic by establishing dependencies, insert new tasks, delete tasks, mark percent complete on tasks, and adjust the indentation level of tasks by using the icons in the Schedule Tools, Task tab on the ribbon. These features behave the same in PWA as in Project Professional.

  6. After setting up tasks and creating scheduling logic, select the Calculate button to make sure that all changes are reflected in the task data. Once the project plan is set up, select the Save button and then the Publish button.

    Note:

    Changes in the project schedule are not visible in the Project Center or on team members' Task view until they have been Published to Project Server.

  7. To close the project plan, select the Project tab in the ribbon, and then click the Close button. The Close window appears. Select Yes to check in the project plan.

Other chapters

For more information, see the other chapters in this guide:

  • Navigating Project Web App

  • Managing resources in Project Web App

  • Managing task updates in Project Web App

  • Managing issues, risks, and documents in Project Web App

  • Managing status reports in Project Web App

  • Configuring e-mail notifications and reminders in Project Web App

See Also

Concepts

Microsoft Project Server 2010 Project Manager's Guide for Project Web App


Managing resources in Project Web App
See Also

Published: January 10, 2012

Summary: The fourth article in a series of eight articles about how to use Microsoft Project Web App to work with Microsoft Project Server 2010 data and to perform project management-related tasks.

Applies to: Project Server 2010 | Project Web App

In this article:

  • Overview of the Resource Center

  • Viewing resource assignments

  • Exporting Resource Center data to Excel 2010

Overview of the Resource Center

Understanding resources and their availability to work on projects is important to a project manager. This article describes how to use the Resource Center page in Project Web App to assist you in such tasks as viewing resource availability, viewing resource assignments, adding a resource in PWA, filtering for resources, and exporting Resource Center data to a spreadsheet in Microsoft Excel 2010.

You can use the Resource Center in Project Web App to view, modify, and analyze information for one or more resources who are assigned to tasks in projects that are published to the Project Server database. Assignment information in the Resource Center tells you who is doing what in which project. The Resource Center displays a list of the resources in the Enterprise Resource Pool; permission to view items in the Resource Center is granted by the Project Server administrator.

The following table lists the Project Server 2010 permissions that are required for Project Professional 2010 and Project Web App users to work with the Resource Center.

Required permissions

Permission Type | Permission | Description
Category | View Enterprise Resource Data | Enables the user to view resources and resource data that is stored in the Enterprise Resource Pool, including the Build Team, Resource Center.
Category | Edit Enterprise Resource Data | Enables editing and saving of resources in the Enterprise Resource Pool using Project Professional 2010 (optional)
Category | View Resource Assignments in Assignment Views | Enables the user to view assignment details by using Assignment view in the Resource Center
Category | Approve Timesheets | Enables the user to accept, but not approve, a timesheet (only needed if she or he is using Timesheets)
Global | View Resource Center | Enables users to access the Resource Center from Project Web App or Project Professional 2010 and view resource allocation data
Global | View Assignments View | Enables a user to view resource assignments in the Resource Center
Global | View Resource Availability | Enables a user to access the View Resource Availability page to view resource allocation data in Project Web App

The Resource Center ribbon

The Resource Center provides insight into enterprise resource information. The Resource Center ribbon provides visibility into resource information, assignments and availability.

You can do the following in the Resource Center:

  • Modify information about resources. Some resource attributes, such as calendar settings, can only be changed by using Project Professional 2010.

  • View and analyze resource information, such as the availability of resources and their allocation across projects.

  • Analyze project performance by exporting data to Excel 2010.

  • View resource assignments at the task and project level, and by availability. Project managers and resource managers can access this view; each group sees information that is specific to their needs. By default, a project manager can only use the View resource assignments option; what a project manager can view is determined by Project Server security categories and security groups, and the projects that they are associated with. (A user in the default Project Manager role in Project Server 2010 is not granted the Edit Enterprise Resource Data permission and therefore cannot edit or save information related to resources in the Enterprise Resource Pool.)

  • View and approve resource timesheets. Approving timesheets is useful for organizations that have multiple departments, such as payroll departments and project management departments, which require that timesheet approval be a separate process from updating task and project status by using timesheets.

  • Adjust actual work values on resource assignments that were submitted by team members. If your organization uses the managed timesheets feature of Project Server 2010, users who are assigned the appropriate permission can update or change actual work entered by team members in their timesheets and locked-down timesheet reporting periods.

Using the Filter drop-down and Group By features in the Resource Center

You can use the Filter and Group By drop-down lists to customize how you want to sort and group resources. The Filter and Group By features are useful when the Resource Center includes lots of resources. This feature includes the following options:

  • Filter. Enables you to filter resources by using a custom filter. You can use a custom filter by selecting Custom filter from the Filter drop-down list and then completing the More Filters dialog box.

  • Group. Enables you to group resources by specified values. In the Group By drop-down list, either select a single grouping from the available list, which is all of the columns active in the view, or create a custom grouping parameter in the Group by drop-down list. When you create a custom grouping, you can set additional grouping parameter from the Then by drop-down list. The second parameter filters data within the data filtered by first parameter. To remove grouping, select the No Group option in the Group By drop-down list.

Resource types

When you use the Resource Center page in PWA, you must understand that there are three types of resources for projects:

  • Work. A Work resource is anyone or anything that works on a task in your project.

  • Material. Material resources are things that are kept available and used up by the tasks in a project.

  • Cost. A Cost resource is a cost that has no time or quantity associated with it.

Viewing resource assignments

You can view current resource assignments by using the Resource Assignments page in the Resource Center in Project Web App. Resource assignments are displayed in a timesheet that shows the data for the current assignments that fall within the range that is specified for the view or are displayed in a Gantt Chart view.

This view resembles the Task Usage view in Project Professional 2010. Assignments are displayed in a grouped structure of tasks within projects within resources, including generic and specific resources. (Only resources that are members of the Enterprise Resource Pool are available.) Tasks are sorted by Task ID within each project. Only resource assignments in projects that the user has permission to view are available.

To view assignments for a resource

  1. In the Resource Center in Project Web App, select the resources whose assignments you want to view on the Resource Assignments page. You can choose to view the resource information in a Gantt chart view or a Time-phased Data view.

    In a Gantt chart, a table appears that shows resource assignments and other information about the assignments. By selecting the check box, you can view Work hours, Overtime Work, Summary Tasks, and time with date. Additionally, you can modify the displayed date range by using the Set Date Range button.

  2. On the Resource Assignments page, in the View drop-down list, select the view that shows the resource information that you want to review.

View resource availability

You can easily view the availability information for specific resources on the Resource Availability page.

To view the availability of a resource

  1. In the Resource Center in Project Web App, select the resources whose availability you want to view, and then click the Resource Availability button.

  2. You can check and clear the resources that you select in the list on the left side, which adjusts the numbers used to create the graph. This view provides a graphical representation of resource information that will help you assess whether a resource is available for work during the period that you choose in the Date Range. Various views exist that help you determine the resource's availability, including Assignment Work by project, Remaining Availability, and Work. The resource availability Details are represented in tabular form on the lower portion of the page.

    You can edit the details of enterprise resources by selecting the resource and then clicking the Open button. Note that this opens Project Professional 2010, which is required to edit the resource.

    Note:

    Only users who are assigned the Edit Enterprise Resource Data permission and who have Project Professional 2010 installed on their local computer can edit resources in Project Professional 2010.

Create a new resource in PWA

You can add a new resource by using the New Resources feature on the Resource Center page.

To create a new resource through the Resource Center

  1. In the Resource Center in Project Web App, select the New Resource button.

  2. Specify the necessary properties for your resource.

  3. In the Type section, complete the following:

    • Type. Choose whether you are creating a Work, Material, or Cost resource.

    • Budget. If the resource is a budget resource, select the Budget check box.

    • Generic. A Generic resource is one that you use to plan, and then replace it with at least one named resource later in the planning process. If this is a Generic resource, select the Generic check box.

  4. In the Identification Information section, complete the following:

    • Resource can logon to Project Server. Select this check box if you want the resource to also be a Project Web App user.

    • Display Name. Type the name of the resource in this box. This field is required.

    • E-mail address. If this resource has an e-mail address that he or she wants associated with project work, type the address in this box.

    • RBS. If your organization uses a resource breakdown structure (RBS), click the button next to this field and select the appropriate RBS code for this resource from the list.

    • Initials. This field is automatically populated with the initials of the resource, based on the name that is specified in the Display Name box. If you want to use different initials to refer to this resource, specify them in the Initials box.

    • Hyperlink Name. If this resource has an associated Web site, specify the name of that site in this box.

    • Hyperlink URL. If this resource has an associated Web site, specify the URL to that site in this box.

  5. In the User Authentication section, complete the following:

    Note:

    The User Authentication section only appears if the Resource Can Log on to Project Server option is enabled in the Identification Information section.

    • User logon account. If you use Integrated Windows authentication, specify the user's account name in the following form: DomainName\UserAccountName. If you use forms-based authentication, specify the user account name in the following form: MembershipProviderName:UserAccount.

    • Prevent Active Directory Synchronization for this user. Select this check box to prevent a user account from being synchronized during Active Directory Resource Pool Synchronization.

  6. In the Assignment Attributes section, complete the following:

    • Resource can be leveled. If you want to give project managers the ability to balance this resource's workload based on his or her availability and assignments (leveling), select this check box.

    • Base Calendar. Choose the calendar that most closely represents this resource's overall availability. For example, if your organization has a base calendar that accounts for specific holidays or events, you can set that as this resource's calendar, and work assigned to this resource will be scheduled around the calendar's nonworking days.

    • Default Booking Type. Choose whether you want this resource to be Committed or Proposed when assigning work.

    • Timesheet manager. Type the name of the person who approves or rejects this resource's timesheets, or click Browse to select the timesheet manager from a list. Resources might not have separate timesheet managers.

    • Default Assignment Owner. Type the name of the person who approves or rejects this resource's task progress, or click Browse to select the assignment owner from a list. Resources might not have separate assignment owners. For example, if the resource is a conference room, and the project manager tracks how long that the conference room is used, the assignment owner might be the project manager.

      Tip:

      You can set the assignment owner in the project on an assignment-by-assignment basis.

    • Earliest Available. Choose the date when the resource becomes available to assign to tasks, if it is appropriate. If the resource does not have a set period of availability (that is, if he or she is always available), leave this setting blank.

      Note:

      The earliest and latest available dates correspond to the resource availability dates for a resource, as seen in Project Professional 2010.

    • Latest Available. Choose the last date that the resource is available to work on tasks, if it is appropriate. If the resource does not have a set period of availability (that is, if he or she is always available), leave this blank.

    • Standard Rate. Type the standard pay rate for this resource in this box.

    • Overtime Rate. Type the overtime pay rate for this resource in this box.

    • Current Max. Units (%). Specify the maximum time period that a resource is available for work, as a percentage. For example, if the resource is available full-time, type 100%. If the resource is available half-time, type 50%.

    • Cost/Use. If the resource has a flat fee associated with each use, type that cost in this box. For example, a van rental might require a flat fee up front, with an added standard cost per mile. The flat fee is its cost per use.

  7. In the Exchange Server Details section, you can specify whether the user's tasks should be synchronized with Microsoft Exchange Server. Select the Synchronize Tasks check box if you want to enable task synchronization by using Microsoft Exchange Server for this user. Exchange integration must be configured for task synchronization to function.

    For more information about how to configure task integration with Microsoft Exchange Server, see Deploy Project Server 2010 with Exchange Server in the TechNet library.

    Note:

    The Exchange Server Details section only appears if the Resource Can Log on to Project Server option is enabled in the Identification Information section.

  8. In the Departments section, click the button next to the Resource Departments box, and select a department or departments to associate with the resource. If the resource is not associated with a particular department, leave this blank

    Tip:

    Associating a resource with a department narrows what the resource sees when they use Project Web App. It can help the resource find what he or she is looking for more quickly, by removing things from other departments that do not apply to his or her work.

  9. If your organization created codes for grouping and costing purposes, in the Group Fields section, complete the following:

    • Group. Specify the name of the group in this box.

    • Code. Specify the code for the group in this box.

    • Cost Center. Specify the cost center code for the group in this box.

    • Cost Type. Click the button next to the Cost Type field, and then select the type of cost associated with this group.

  10. In the Team Details section, click the button next to the Team Name box, and select which team the resource belongs to, if it is appropriate. If the resource will be managing and delegating tasks that are assigned to the team, select the Team Assignment Pool check box.

    Tip:

    Some organizations create a generic resource for each team so that tasks assigned to the team first go to the generic resource. This way, no single resource takes on the task assignment before it is appropriately delegated. If you choose to use a generic resource in this manner, set the assignment owner for the resource as the team manager, select the Team Assignment Pool check box, and select the team from the Team Name list.

  11. In the System Identification Data section, type additional identifying information for the user in the External ID box, if it is appropriate.

    For example, your organization's HR department might use employee ID numbers to track data in its HR systems. By providing that ID number in the External ID box, you identify an association between the resource that you are creating and the HR department's employee data. The External ID box can also be used to facilitate the consolidation of reporting of resource use beyond what Project Server provides.

    Tip:

    If you are not sure whether to specify information in the External ID box, check with other departments in your organization to determine whether it is useful to connect resource data with other systems, or to just leave this box blank.

  12. After you specify all the information, select the Save button to create the new resource.

Note:

For information about adding a resource to a project, see Managing projects in Project Web App in the "Adding Resources to a Project Plan" section.

Exporting Resource Center data to Excel 2010

You can export Resource Center data to Excel 2010 from Project Web App by using the Export to Microsoft Excel feature. Project Web App also enables you to copy data that is displayed in the Project Web App Grid Control and paste it into applications such as Excel, Word, and Outlook.

To export Resource Center data to Excel 2010

  1. In the Resource Center in Project Web App, click the Export to Excel button.

  2. A file download window appears that enables you to open or save the document. Select Open.

  3. A message box might is displayed to say that the file that you are trying to open is in a different format than what is specified by the file name extension. Select Yes.

  4. The Resource Center view opens in Excel.

  5. Click Save As on the File menu in Excel if you want to save the data as it is currently presented. You can save the data in any supported Excel format.

Other chapters

For more information, see the other chapters in this guide:

  • Navigating Project Web App

  • Managing projects in Project Web App

  • Managing task updates in Project Web App

  • Managing issues, risks, and documents in Project Web App

  • Managing status reports in Project Web App

  • Configuring e-mail notifications and reminders in Project Web App

See Also

Concepts

Microsoft Project Server 2010 Project Manager's Guide for Project Web App


Managing task updates in Project Web App
See Also

Published: January 10, 2012

Summary: The fifth article in a series of eight articles about how to use Microsoft Project Web App to work with Microsoft Project Server 2010 data and to perform project management-related tasks. Learn how team members can update their tasks and then submit them for approval through Project Web App. It also describes how project managers review task updates that are submitted for approval.

Applies to: Project Server 2010 | Project Web App

In this article:

  • Submitting task updates

  • Task viewing options

  • Task update approval

  • Processing task changes and requests

Submitting task updates

Team members can report time against published assignments (Project Tasks) through the Project Web App Tasks page. As the project manager, you can also update actual work directly in Project Professional 2010, but this should be done as the exception, not the rule, if you are accepting updates from Project Web App.

The following scenario outlines the interchange between a team member and a project manager during the task update and approval process.

  1. A team member logs on to Project Web App. On the Project Web App home page, the team member can click Tasks in the Quick Launch to view tasks that are assigned to him or her.

  2. Tasks that are assigned to the user appear on the Tasks page. On the Tasks page, the team member can enter the actual hours worked in the grid based on the days he or she worked.

    Note:

    Hours can only be entered on detailed tasks. It is not possible to enter time against the project summary task.

  3. The team member can use the buttons in the Period column of the ribbon to navigate to a previous week or later week by selecting the buttons. The team member can also select a specific time period by clicking the Select Period button.

  4. Subsequent to associating actual hours with a task assignment, the following steps have to be addressed, depending on whether the task is now complete. The team member can save updates, but not send them to the project manager, by clicking Save. Updates can be sent at a later time by selecting one of the Send Status options.

    • If the task is complete, the user should make sure Remaining Work is 0, and the system will indicate 100% complete. If the task indicates that there is work remaining but in fact the task is completed, the value should be changed to zero.

    • If the status is not finished with the task, the team member should update the Remaining Work with the hours expected to complete the task. This might be more or less than the hours shown, which was calculated based on the original task work estimate and the hours that have been entered so far. The act of entering Remaining Work hours will recalculate the % Complete and Work values.

    In the scenario, the team member requests additional work hours to complete a task, specifically 60 hours instead of the 40 hours that was an automatically calculated value. Ten of these hours have already been worked. Additionally, the team member attaches a comment to the update submittal. This process enables the team member to communicate to the project manager the reason why additional time is needed to complete the task.

    Note that the team member has selected only the one task to update. (Alternately, additional assignments can be updated by selecting them with a checked box or by clicking the Send Status, All Tasks button.) Also note that the Send Comment box is checked before the user clicks Send Status, Selected Tasks. The following image depicts task updates ready to be submitted.

    When a team member is ready to submit a task update to the project manager, she or he selects the check box of the row for the status update. He or she then clicks Send Status to view the following options:

    • All Tasks. Quickly send an update for all tasks updated to the Project Manager.

    • Selected Tasks. Enables submitting updates for specific tasks at a time to the Project Manager.

    Clicking Selected Tasks submits a status update for the selected task.

  5. After the Send Status, Selected Tasks button is clicked, a comment box displays the comment that is associated with the assignment update.

    After the assignment update is submitted, the Process Status column reflects the current status of the task.

Task viewing options

Team members can select different task viewing options to change the way task information is displayed to them on the task page. These options can be selected on the Project Web App ribbon.

The following task-viewing options are available on the PWA ribbon:

  • Import. Imports status data from the timesheet.

  • Layout. Enables the following viewing options:

    • Gantt Chart. Displays the data in Gantt chart view.

    • Timephased Data. Displays the data by the day, week, or other incremental time level. If this option is not selected, the date column grid does not appear for time entry.

    • Sheet. Displays the data in a table format.

  • Units. Enables the following viewing options:

    • Duration

      • Minutes

      • Hours

      • Days

      • Weeks

    • Work

      • Minutes

      • Hours

      • Days

      • Weeks

    • Date

      • 1/28/2010

      • 12:33 PM

      • 1/28/2010 12:33 PM

      • Thursday, January 28, 2010

      • Thursday, January 28, 2010 12:33 PM

      • Thu 1/28

      • January 28

      • January, 2010

  • Filter. Changes the task information displayed to utilize a standard filter or create a custom filter.

Task update approval

After a team member has submitted an update, you as the project manager can then review the submittal and make a determination to accept it into the project schedule or reject it.

Clicking a pending approval opens the Approval Center.

On the Approval Center page, you can view all submitted tasks updates that are pending your approval. Details about the task update — such as the resource who submitted the update or comments — are displayed on this page. Clicking a task on this page displays additional task details about the update.

You can then accept or reject the task update by selecting the check box next to the task, and then clicking the Accept or Reject button on the ribbon. With either choice, you can optionally submit a comment back to the resource about the task update.

Processing task changes and requests

The Approval Center page in Project Web App enables you to review changes to project tasks and working times that team members submit by using the Tasks and Timesheet pages. You can use the Approval Center in Project Web App to review changes to project tasks and resource working times, and to update projects with the latest information.

The following types of changes appear in the Approval Center in Project Web App:

  • Task changes

  • New task requests

  • Task delegation requests

  • Resource declined assignments

  • Resource declined task delegation requests

You can update project information based on the task changes that appear in the Approval Center in the following ways:

  • Manually. You can update projects for each task change that a team member submits by clicking Accept on the Approvals tab in the Approval Center. If you don't want to approve a task change request, you can click Reject, and provide a comment to the resource submitting the request to give an explanation of the rejection. When you reject a change request, it is removed from the list in the Approval Center until the team member resubmits the request.

  • Automatically (by using rules). You can create and run rules to automatically update projects with changes that do not need to be reviewed before approval. You can create rules that run for specific projects, for all projects, for specific resources, or for groups of resources at a specific location in the Resource Breakdown Structure of your organization. Even if you enable rules for automatic approval, you will need to publish the project before tasks will be fully rescheduled.

The following table lists the Project Server 2010 permissions that are required in order for Project Professional 2010 and Project Web App users to work with task updates.

Required permissions

Global permission | Description
Manage Rules | Enables a user to access the Updates page in Project Web App and create rules that determine how update transactions are automatically processed.
Manage Task Changes | Allows users to access the Updates page in Project Web App to get task updates, and view, accept, or reject a resource's transactions.

Processing Task Changes from the Approval Center

Project team members use the timesheet that is available in Project Web App to report changes to their assignments. Project managers automatically receive a notification when changes are submitted by team members assigned to tasks in projects that they manage. Project managers can choose to accept or reject each task change.

Changes submitted by team members do not affect projects until they are published; only approved task changes are applied to projects that are published to the Project Server database and only approved task updates appear in projects as reported actual work. If you know that team members have changed tasks, added new tasks, delegated tasks, or declined tasks, but the submitted changes are not available in the Approval Center, your team members might not have actually submitted their changes.

Before you accept or reject task changes from project team members, it is important to be aware of your organization's timesheet processing cycle. For example, if your organization has a weekly timesheet cycle, you should plan to process all timesheet and task changes at least once per week, after all team members submit their status, but before the end of the weekly timesheet cycle. This helps to ensure that the correct data is submitted and accepted/rejected and also helps to prevent the publication of incorrect data as a result of updates.

The Updates page has the following characteristics:

  • If a team member sends multiple changes for a single task element, only the change that was submitted most recently is displayed.

  • If a team member delegates a task, one row is displayed in the update list. If the team member to whom the task was delegated rejects the delegation, the rejection appears as a separate row and the Accept field cannot be edited.

  • The tracking mode of the pending update determines whether to display a timesheet or a Gantt Chart view. If specific hours are used for any update, the timesheet is displayed. A Gantt Chart view is displayed for all other updates.

  • If an update is rejected, the team member who sent the update is notified by e-mail and an icon is displayed in their timesheet.

  • After a task change is approved, a record of the change is added to the History page. Any changes that were not approved or rejected are pending and remain in the Approval Center until they are accepted or rejected and processed.

Preview the effects of approving a task change

The Preview Updates button in the Approvals ribbon allows you to see what a project plan will look like if you accept a specific task update request. It displays a Preview page for the project plan that contains a Gantt Chart of the project with the task update.

To preview the effects of a task change to a project plan

  1. On the Quick Launch, in the Projects section, click Approval Center.

  2. On the Approvals tab, select the check box in the left column for the task update that you want to preview.

  3. On the Approvals tab of the ribbon, click Preview Updates.

  4. On the Approval Preview page, view how the project plan would look if the task update were approved.

Approve or reject task changes submitted by project team members

After looking at the effects of the task changes submitted for approval, you can chose to either approve or reject the request.

To approve or reject task changes submitted by project team members

  1. On the Quick Launch, in the Projects section, click Approval Center.

  2. Select the check box in the left column for the task update row that you want to accept or reject.

  3. On the Approvals tab of the ribbon, click Accept or Reject.

Note:

If you accept a task delegation request and update a project, you cannot reject the task delegation later.

Viewing task change history

You can view a history of all task changes that were processed within the previous 60 days. This history is for review purposes only; it cannot be modified. This enables you to review the history of updates made for all projects and resources. The update archive displays the updated tasks in a similar format to the Update Task Changes page. The Customization tabs display the same options that the Updates page displays. The Show Task Changes button in the action menu re-directs you to the Update Task Changes page. The number of days that are available in the task update history section is set by the Project Server administrator.

Note:

Task changes appear in the grid, after you have processed (either accepted or rejected) them. To navigate quickly to the page where you can process task updates from team members, click Show Task Changes. If you want to adjust actuals for resources, go to the Resources page, and click Adjust Actuals.

To view task change history

  1. In the Approval Center in Project Web App, on the Approvals tab, click History. From the menu, click Status Updates or Timesheets to view history on task updates for either.

  2. Task updates made within the previous 60 days appear, presented in a grid format. In the task updates history, scroll to the right to view details about each update. Details include whether or not the task was accepted, current status, the Project Web App user to whom the task is assigned, the user who approved or rejected the task, and the actual work associated with the task, and other information about the task.

Other chapters

For more information, see the other chapters in this guide:

  • Navigating Project Web App

  • Managing projects in Project Web App

  • Managing resources in Project Web App

  • Managing issues, risks, and documents in Project Web App

  • Managing status reports in Project Web App

  • Configuring e-mail notifications and reminders in Project Web App

See Also

Concepts

Microsoft Project Server 2010 Project Manager's Guide for Project Web App


Managing issues, risks, and documents in Project Web App
See Also

Published: January 10, 2012

Summary: The sixth article in a series of eight articles about how to use Microsoft Project Web App to work with Microsoft Project Server 2010 data and to perform project management-related tasks.

Applies to: Project Server 2010 | Project Web App

In this article:

  • Introduction to managing issues, risks, and documents

  • Project risks

  • Project issues

  • Project documents

Introduction to managing issues, risks, and documents

The beauty of the EPM Solution is the collaboration capabilities that are native to the product because of the components that have been incorporated into the solution mix. This function is greatly enhanced by using Microsoft SharePoint Foundation as the framework from which team collaboration can be better managed.

Project artifacts such as Risks, Issues, and documentation can be stored, linked and attached to projects or tasks. A project site (subsite) is automatically created for a project when a project plan is published in the Microsoft Project Professional 2010 environment. Each subsite is created with its own library so that risks, issues and documents can be linked.

When you use Microsoft Project Server 2010, the following collaboration features are enabled:

  • Risks Risk management involves proactively identifying and tracking events and conditions that can potentially affect future planning for a project. Risks can be rated by severity and assigned an estimate for how likely they are to occur.

  • Issues Issues can be used to track work items that are not easily identified as assignments or tasks in projects. Project managers, resource managers, and team leads can then determine whether the issues will affect the project and identify strategies to manage the issues before they become larger problems.

  • Documents A document library provides a location for team members to collaborate and share documents and other project artifacts with project team members.

  • Project Site A project site can exist for each project saved to the Project Server database. The project site enables additional collaboration features (for example, announcements, alerts, deliverables and the ability to link these to your project tasks) by providing a Web site for each project that makes the capabilities of SharePoint Foundation available to a project team.

As a project manager, it is important to know how to understand and manage the collaboration capabilities of project sites that you manage.

Project risks

Risks are events or conditions that can have a positive or adverse effect on the outcome of a project; in many ways, managing risks is critical to the success of managing projects. Risk management involves proactively identifying and tracking events and conditions that can potentially affect future planning for a project. Identifying risks differs from tracking issues because it involves identifying an event or condition that can affect the outcome of a project instead of tracking an actual effect on the outcome of a project. Risks can exist in the present time and can have up to a 100 percent probability of occurring. Risks can also exist in the far future and have up to a 100 percent probability that they will eventually be a factor in the life cycle of a project.

Project risks can be submitted and tracked on the project site. This allows for greater communication between team members and provides a central repository for concerns. Risks can be accessed through Microsoft Project Web App (PWA).

Adding project risks

Use the following procedure to add a project risk through Project Web App.

To add a project risk

  1. From the Project Center, select the project and the Project Site button, and then click the project that will store the risk information.

  2. After the project site opens, click the Risks option on the Quick Launch.

  3. After the Risks page opens, click Add New Item.

  4. Specify the Risk information on the Risk Template (this template can be modified by the system administrator).

  5. You can Attach a file to this risk, or Link Items to this risk by selecting the associated button in the Risk ribbon.

Viewing and managing risks

Use the following procedure to view project risks that are assigned to you. When viewing the risk, you have options to change the risk, such as adding an item, deleting, or managing permissions.

To view the risks assigned to you

  1. From the Project Web App Quick Launch, click Issues and Risks.

  2. Click the Project name with the risk that you want to open.

  3. From the project site Risks page, choose the risk that you want to view or change.

  4. You can Add a new item, Edit the risk, Delete the risk, Manage Permissions on this form, or set an alert by using the SharePoint Foundation notification mechanisms, if it is enabled.

Project issues

Issues tracking can be an important part of project management. Issues are best used to capture work items that are not easily identified in assignments or tasks within projects. Team members and project managers can use the Issues page in the project site. Project managers, resource managers, and team leads can then determine whether the issues will affect the project, and they can identify strategies to manage the issues before the problems become larger.

Adding project issues

Use the following procedure to add a project issue through Project Web App.

To add a project issue

  1. From the Project Center, select the project and the Project Site button, and then click the project that you want to store the issues information.

  2. After the project workspace opens, click the Issues option on the Quick Launch.

  3. After the Issues page opens, click Add new item.

  4. Specify the Issue information on the Issue Template (this template can be modified by the system administrator).

  5. Similar to Risks, you can Attach a file to this risk, or Link Items to this issue by selecting one of the buttons on the Issues ribbon.

Viewing and managing issues

Use the following procedure to view issues that are assigned to you. On the issue details page, you have options to add items to the issue, delete the issue, and manage permissions for the issue.

To view the issues assigned to you

  1. From the Project Web App Home Page, click Issues and Risks.

  2. Click the Project Issue that you want to open.

  3. From the Issues page, choose the issue that you want to view or change.

  4. You can Add a new item, Edit the issue, Delete the issue, Manage Permissions on this form, or set an alert by using the SharePoint Foundation notification mechanisms, if it is enabled.

Project documents

Project Server 2010 integrates document management into the overall project management process by incorporating the SharePoint document library feature. A document library can be associated with any project that is published to the Project Server database, and it can provide a location for team members to collaborate and share documents (including Microsoft Word, Microsoft Excel, and many other document types and formats) outside a project. In addition to document libraries, a public library can be used to store documents that are related to all projects in your organization.

You can access the document management feature of Project Server 2010 by clicking the Libraries link in Project Web App, by selecting Shared Documents, or by directly going to the project site from Project Web App. You can create document libraries for each project that is published to the project site. Documents are used to capture non-structured, project-related information that is not otherwise available in a typical project.

Adding project documents

Use the following procedure to add a document to a document library on a project site.

To add a project document

  1. From the Project Center, select the project for which you want to open the Project Site, and then click the Project Site button on the ribbon.

  2. After the project site opens, click the Project Documents option on the Quick Launch.

    The Project Document page opens.

  3. After the Project Documents page opens, click Add document to upload or import one or more files into the document list. You can also modify list settings and process with the correct permissions by clicking the Library tab, Library Settings.

  4. From here you can View or Edit Properties, Manage Permissions, Edit, or Delete the document, Send to using e-mail if it enabled, Check Out (a function of SharePoint Services that manages version control), or set an alert (for any revisions to a document).

Other chapters

For more information, see the other chapters in this guide:

  • Navigating Project Web App

  • Managing projects in Project Web App

  • Managing resources in Project Web App

  • Managing task updates in Project Web App

  • Managing status reports in Project Web App

  • Configuring e-mail notifications and reminders in Project Web App

See Also

Concepts

Microsoft Project Server 2010 Project Manager's Guide for Project Web App


Managing status reports in Project Web App
See Also

Published: January 10, 2012

Summary: The seventh article in a series of eight articles about how to use Microsoft Project Web App to work with Microsoft Project Server 2010 data and to perform project management-related tasks.

Applies to: Project Server 2010 | Project Web App

In this article:

  • Introduction to managing status reports

  • Requesting and updating status reports

  • Viewing status reports

  • Viewing the status report archive

Introduction to managing status reports

Status reports provide a simple method for communicating descriptive information about the status of specific tasks or a whole project. Status reports are narrative descriptions of the status of or progress on assigned tasks, and they enable you to automate requesting and receiving status information. Project managers can send team members status report requests and team members can then respond to them by providing the information requested. Team members can also begin the submission of status reports. Project managers can configure status reports so that they receive individual submissions and a merged or compiled status report that consolidates responses into a single status request. You can manage status reports, including status report requests, from the Project Web App Status Reports page.

The Status Reports feature in Project Web App enables project stakeholders to send status reports to any persons involved with a project (as long as they are also Project Web App users) to provide information about the status of their tasks. When you are configuring status reports, you can do the following:

  • Specify the title of a status report and the frequency at which it must be submitted.

  • Identify the team members who will receive and respond to the status report request.

  • Specify the information that team members will report.

  • Send the request.

Note:

Status reports differ from resource updates to task assignments. Use the Approval Center page in Project Web App to review updates to project tasks, to work with resource working times, and to update projects with the latest information.

The following table lists the Microsoft Project Server 2010 permissions that are required for Microsoft Project Professional 2010 and Microsoft Project Web App (PWA) users to work with status reports.

Table 6: Required permissions

Global permission | Description
Edit Status Report Requests | Enables a user to access the Request link in Project Web App.
Edit Status Report Responses | Enables a user to access the Responses link in Project Web App.

Status reports are typically submitted on a scheduled, recurring basis. For example, a project manager might want to receive a weekly status report from each team member assigned to tasks in a project. The default status report form includes headings such as Major Accomplishments, Objectives for the Next Period, and Hot Issues. However, these can be customized to meet the status reporting needs of different organizations.

You can complete the following activities from the Status Reports page:

  • Requests Enables project managers and project stakeholders to create a reporting template and sent out a status request to team members for reporting progress. You can create a new status report for your team, edit an existing status report request, delete a request, view individual responses, or consolidated responses to requests.

  • Responses Enables team members to reply to a status report sent by their project manager or by any other Project Web App user.

  • Submit unrequested report Enables any project stakeholder to return a status request or define and submit a status report to any other selected project stakeholders in Project Web App. Users can respond to upcoming status report requests or create and submit an unrequested status report.

  • Viewing an archive of submitted status reports Enables you to view and edit sent and unsent status reports.

For example, as a project manager you might have to create a weekly report that covers the overall progress of a project. By using the Requests feature, you can set up a status reporting template for team members that, when it is complete, provides information about important activities during a specified time period. You can configure status report requests to be sent out automatically at set intervals to team members. Team members are then notified on their Project Web App home page of the pending status report that requires a response. Project managers and team members can also use the Task Alerts and Task Reminders features to customize e-mail notifications and reminders. By using the Responses feature, team members can complete the status report and send the response back to the project manager. You can group responses, which allows you to verify the response rate for a status report request, and then you can merge completed status reports and view the consolidated responses from team members.

Users must be granted the Edit Status Report Responses or Edit Status Report RequestsProject Server permissions by the Project Server administrator to submit status reports, view status reports, submit unrequested status reports, and manage status report requests. By default, only members of the following Project Server security groups have the permissions that are required to request status reports and view group responses: Executives, Project Managers, and Resource Managers. Users Project Web App can submit a status report in response to a status request or because they want to independently.

Consider the following tips when create status reports:

  • Include a department name or project name in the title for the status report.

  • Project Server 2010 automatically generates the first status report at the start date specified in the setup pages for the status report, and generates status reports on the first day of each reporting period after that.

Requesting and updating status reports

You can request and update status reports by using the Status Reports page in Project Web App. Status reports are forms that team members use to provide specified information about the current status of their work. Unlike task updates, status reports are not associated with a project, do not contain information about a project (unless it is added to the text of the status report itself), and cannot be used to update a project schedule. Status reports can be used to provide detailed information about accomplishments, goals, issues, and other factors that affect a team member's work. When you create a status report request, you must define the sections that it contains, who must respond to it, and how frequently it is sent out and replied to.

When you request a status report, a notification appears on the user's Home and Status Reports pages in Project Web App. The user can reply to the status report request by selecting that report on either page. Team members can submit unrequested status reports on any topic in the Responses section by using the Submit Unrequested Report option. This displays a page from which a team member can create a status report and send it to the appropriate Project Web App user.

Note:

Unrequested status reports are not recurring. They must be submitted individually and in addition to any required recurring status reports.

To request a status report

  1. On the Project Web App home page, in the Quick Launch, in the Resources section, click Status Reports.

  2. On the Status Reports page, in the Requests section, click New, and then click New Request.

  3. In the Report Title section, in the Title box, specify the name of the new status report.

  4. In the Frequency section, specify the frequency with which the status report must be submitted and the day of the week, month, or year on which the status report is due.

  5. In the Start Date section, in the Start box, specify the date to begin the period that the status report will cover.

  6. In the Resources section, in the Available Resources list, select the resources who should respond to the status report request.

    Click the Add button to add the resources to the Resources Who Should Respond list.

    The selected resources appear in the Resources Who Should Respond list.

  7. To remove a resource from the Resources Who Should Respond list and return them to the Available Resources list, highlight the resources name, and then click the Remove button.

  8. To create the Status report sections, click the Insert Section button and indicate the topics that you want your resources to report by specifying a title and brief description for each section of the status report. By default, three titles are listed: Major Accomplishments, Objectives for the Next Period, and Hot Issues. You can delete those rows, change the name and include a description.

    Complete the following:

    • In the Name column, specify the names of the status report sections, for example, New Section for Information.

    • In the Description column, provide any additional descriptive text that you want to provide, for example, Please enter Additional information about the project.

    • Click Insert Section to insert a row at the bottom of the list.

    • Click Delete Section to delete the selected row.

  9. To send the status report request to the selected team members, click the Send button. Use the Cancel button to exit the status report creation, recognizing that all previous work on this status report request will not be saved.

    The new status report is available on the Status Reports page in the Requests section.

To edit a status report request

  1. On the Status Reports page in Project Web App, in the Requests section, select the row with the name of the status report that you want to edit. Click the Edit Request button.

  2. After you are finished, click Send to send the status report to the people identified in the Resources Who Should Respond list.

Viewing status reports

You can view individual team member status report responses as a group status report and status reports that you did not request. You can use the Group merged reports by feature to view consolidated responses to a status report request by either resource name or response date. A notification also appears on the home page in Project Web App if you requested a status report.

The View Responses button shows the people who have responded to the status report request, grouped by reporting period. Icons indicate whether a report was submitted, and whether it was merged into a consolidated report.

Miscellaneous reports are created when unrequested status reports are submitted or when a non-project team member was copied on a requested status report. You can access these through the Status Reports page in the Responses section, selecting Status Report: Miscellaneous from the Go To drop-down list.

Responses can be exported to Word on the Status Report Responses page or Excel in the Requests section Action drop-down list on the Status Report page.

To view status report responses

  1. On the Status Reports page in Project Web App, click on the report name in the Requests section.

  2. In the View Responses page, highlight all the resource's responses that you want to view in a merged file, and then click the Open button.

  3. The Status Report Responses page shows the responses either merged or individually, depending on how you elected to view the information. Select the Export to Microsoft Word command to pull the responses out of Project Web App and into Word.

    • To view the details for a single Project Web App user, select the user, and then click Open.

    • To merge the details from a single Project Web App user into a consolidated status report, select the user, and then click Merge.

    Note:

    Pending status report responses are also listed on your Project Web App home page immediately after you log on.

Viewing the status report archive

The Status Reports Archive contains all the status reports sent or received by the current user. This archive allows you to access these reports, view and update. This will allow text to be added to each topic section specifying any update to the original comments. Choosing the Send button resends the selected status report in the Status Reports Archive.

To view the status report archive

  1. In the Status Report page in the Responses section, select Status Reports: Archive from the Go To drop-down list.

  2. To view a specific status report within the Status Reports Archive, click the report name in the Report column. After you select a report, you can do one or more of the following:

    • Add more information to the status report.

    • Add a new section to the report.

      The update view opens with a new section in which you can type updated status report information. To add another section to the updated status report, click the Click to add section button. Click Save to save the updated status report to the Status Reports Archive. Click Send to send the status report to the Project Web App user identified in the To field.

    • To return to the Status Report page, select Status Report link in the Resources section of the Project Web App left navigation column.

Other chapters

For more information, see the other chapters in this guide:

  • Navigating Project Web App

  • Managing projects in Project Web App

  • Managing resources in Project Web App

  • Managing task updates in Project Web App

  • Managing issues, risks, and documents in Project Web App

  • Configuring e-mail notifications and reminders in Project Web App

See Also

Concepts

Microsoft Project Server 2010 Project Manager's Guide for Project Web App


Configuring e-mail notifications and reminders in Project Web App
See Also

Published: January 10, 2012

Summary: The eighth article in a series of eight articles about how to use Microsoft Project Web App to work with Microsoft Project Server 2010 data and to perform project management-related tasks.

Applies to: Project Server 2010 | Project Web App

In this article:

  • Introduction to configuring e-mail notifications and reminders in Project Web App

  • Overview of e-mail notifications and reminders

  • Configuring personal notifications and reminders

  • Configuring notifications and reminders for your resources

Introduction to configuring e-mail notifications and reminders in Project Web App

You can use e-mail notifications to be alerted to changes to, or actions required for, projects that you or resources that you manage belong to. You can use reminders to be alerted to upcoming or overdue actions that you or resources that you manage are responsible for. Alerts and reminders are triggered by specific events in Microsoft Project Server 2010, and they generate e-mail messages that are sent to the appropriate users' e-mail accounts. The Manage My Alerts and Reminders and Manage My Resources' Alerts and Reminders pages allow you to configure how you or resources that you manage are alerted to changes related to your tasks, status reports, or queue job failures. The notifications that you receive can provide hyperlinks to the appropriate pages in Project Web App (PWA) from which the recipients of the notification or reminder can take additional action.

Note:

Manage My Alerts and Reminders is configured at the user level; each Project Web App user must subscribe and unsubscribe to their own notifications. In some cases, depending on security settings, a resource manager in Manage My Resources' Alerts and Reminders can configure e-mail notifications and reminders for the resources that they manage.

The following table lists the Project Server 2010 permissions that are required for Microsoft Project Professional 2010 and Project Web App users to configure e-mail notifications.

Table 7: Required permissions

Global permission | Description
Manage Notification and Reminders | Enables a user to manage the Alerts and Reminders settings in Project Web App Server Settings.
Manage Personal Notifications | Enables a user to access the Manage My Alerts and Reminders link in the Personal Settings section of the Project Web App navigation column.
Manage Resource Notifications | Enables a user to access the Manage My Resources' Alerts and Reminders link in the Personal Settings section of the Project Web App navigation column.

Overview of e-mail notifications and reminders

Notifications are generated by many user-initiated events. These events can be the actions of other team members and project managers. For example,, a project manager sending a new task to a resource can trigger a notification to the team member who is assigned to the task so that that person is aware of and can act upon the new assignment.

The following user actions can generate e-mail notifications:

  • Publish

  • Reassign Tasks

  • Task Updates

  • New Tasks

  • Overdue Tasks

  • Status Report Requests

  • Status Report Responses

  • Overdue Status Reports

  • New Issue is Opened

  • New Risk is Opened

  • Issue Assignment

  • Issue is Modified

  • Document Changes (New, Delete, Modify

  • Task List Delegation

  • Queue Job Failure

By default, the following actions generate e-mail notifications. (Users cannot unsubscribe to these notifications):

  • Rejected Assignments (by Resource)

  • Rejected Task Updates (by Manager)

  • Rejected New Tasks (by Manager)

  • Rejected Calendar Updates (by Manager)

  • Rejected Reassign Task Requests (by Manager)

  • Rejected Remove Task (by Manager)

  • Removed from a Status Report (by Manager)

Reminders are triggered by timed events. For example, if a task is due to be completed by a resource on a certain date, a reminder is sent to the resource indicating the current status of the task. Project Server 2010 checks for and submits reminders at an interval specified by the user or resource manager/project manager with rights to Manage My Resources' Alerts and Reminders.

Project Web App users can define when Project Server sends e-mail notifications or reminders to themselves. Project managers and resource managers can define e-mail notifications and reminders for themselves and for their team members. Team members cannot unsubscribe to e-mail notifications or reminders that are configured for them by their project manager or resource manager.

The Project Web App Personal Settings section of the Project Web App navigation column includes the following links that you can use to configure e-mail notifications and reminders:

  • Manage My Alerts and Reminders. Use this link to configure e-mail notifications for changes to your tasks and status reports. Notifications for tasks and status reports are configured separately.

  • Manage My Resources' Alerts and Reminders. Use this link to configure e-mail notifications for changes to your resources' tasks and status reports.

As a project progresses, you might want to adjust the type and frequency of e-mail notifications and reminders. For example, you might initially set a longer reminder for overdue tasks, such as several days or several weeks, and then shorten it when you are closer to project completion so that the reminders are sent out as soon as a task becomes overdue. You might also want to unsubscribe to notifications.

E-mail notifications and reminders for tasks, projects, resources, status reports, and updates are configured by the Project Server administrator. In addition, e-mail notifications and reminders can be customized.

Configuring personal notifications and reminders

All users of Project Web App can configure the types of e-mail notifications and reminders that they want to receive.

Subscribe to personal e-mail notifications and alerts

You can configure your own personal e-mail notifications and alerts by using the following procedure.

To subscribe to personal e-mail notifications and alerts

  1. On the Project Web App home page, in the Quick Launch, click Personal Settings, and then select Manage My Alerts and Reminders

    Note:

    The e-mail address to which alerts are sent is listed at the top of the Manage My Alerts and Reminders page next to E-mail address.

  2. To configure alerts for tasks, expand the Tasks section, and configure the following:

    • If you want to receive e-mail immediately upon the occurrence of specified events, in the Alert me immediately when section, select the appropriate check boxes to set e-mail alerts to be sent when you receive new task assignments or when your tasks are modified or updated.

    • If you want to receive e-mail at set intervals, in the Task Reminders section, select the appropriate check boxes to set e-mail alerts to be sent before tasks start, before tasks are due (and overdue), for incomplete tasks, and for overdue tasks. For each interval, specify the frequency.

  3. To configure alerts for status reports, expand Status Reports section, and configure the following:

    • If you want to receive e-mail immediately upon the occurrence of specified events, under the Alert me immediately when heading, select the I receive a new status report request check box to set e-mail alerts to be sent when you receive a new status report request.

    • If you want to receive e-mail at set intervals, under Status Report Reminders, select the appropriate check boxes to set e-mail alerts to be sent when status reports are due, when your status reports are overdue, and when status reports are submitted or have become overdue. For each interval, specify the frequency.

  4. To receive alerts about queue job failures, expand the Queue Job Failure section, and then select or clear the Queue Job Failure Alerts options.

  5. If Multilingual User Interface Packs (MUI Packs) are installed for Project Server 2010, select the language in which you want to receive your e-mails from the Language Settings drop-down list.

  6. Click Save.

Unsubscribe to personal e-mail notifications and alerts

If you no longer want to receive personal e-mail notifications and alerts, follow these steps.

To unsubscribe to personal e-mail notifications and alerts

  1. On the Project Web App home page, in the Quick Launch, click Personal Settings, then select Manage My Alerts and Reminders.

    Note:

    The e-mail address to which alerts are sent is listed on the Alert Me about My Tasks and Status Reports page next to E-mail Address.

  2. To unsubscribe to alerts for tasks, expand the Tasks section and then clear the check box for the specific type of alert and reminder from which you want to unsubscribe.

  3. To unsubscribe to alerts for status reports, expand the Status Report section and clear the I receive a new status report request check box and all check boxes under the Status Report Reminders section.

  4. To unsubscribe to alerts for queue job failures, expand the Queue Job Failures section and clear the Any of my Queue Jobs fails check box.

  5. Click Save.

Configuring notifications and reminders for your resources

Users of Project Web App who manage resources can configure e-mail notifications and reminders to be sent to their resources when specific actions occur.

Subscribe your resources to alerts and e-mail notifications

If you want to configure alerts and notification for resources that you manage, follow these steps.

To subscribe your resources to alerts and e-mail notifications

  1. On the Project Web App home page, in the navigation column, click Personal Settings, then select Manage My Resources' Alerts and Reminders.

    Note:

    The e-mail address to which alerts are sent is listed on the Manage My Resources' Alerts and Reminders page next to E-mail address.

  2. To configure alerts for your tasks assigned to your resources, expand My Team Members' Tasks, and configure the following:

    • If you want to receive e-mail immediately upon the occurrence of specified events, in the Task Alerts section, select the appropriate check boxes to set e-mail alerts to be sent when your team members submit new tasks and assignments, reassign tasks, and when team members update tasks.

    • If you want to receive e-mails at set intervals for upcoming tasks, under Task Reminders, select the appropriate option to set e-mail reminders to be sent before tasks are due and have the alerts sent only to you, only to your team members, or both to you and your team members. You can also specify the number of days, weeks, or months in advance of the due date for the upcoming task that the e-mail is sent.

    • If you want to receive e-mail alerts at set intervals for overdue tasks, in the Task Reminders section, select the appropriate check boxes to set e-mail alerts to be sent when tasks are overdue (and again until the overdue task is completed) and select the appropriate option to set the alerts to be sent only to you, only to your team members, or both to you and your team members. You can also specify the number of days, weeks, or months past the due date for the overdue task at which the alert is sent and the frequency at which reminder e-mails are sent until the task is complete.

    • If you want to receive e-mail at set intervals for tasks that have been in progress but have no actual work, in the Task Reminders section, select the appropriate options to set e-mail alerts to be sent when a task is started, but has no reported actual work, and have the alerts sent only to you, only to your team members, or both to you and your team members. You can also specify the number of days, weeks, or months after the task has started at which the alert is sent.

  3. To configure reminders for your resource's status reports, expand My Resources' Status Reports, Status Report Alerts, and configure the following:

    • If you want to receive e-mail immediately when your resources send a status report, in the Status Report Alerts section, select the check box to set e-mail alerts to be sent when your resources submit a status report.

    • If you want to receive e-mail at set intervals for upcoming status reports, in the Status Report Reminders section, select the appropriate option setting e-mail alerts to be sent when a resource's status report is due and have the alerts sent only to you, only to your resources, or both to you and your resources. You can also specify the number of days, weeks, or months in advance of the due date for the status report at which the alert is sent.

    • If you want to receive e-mail at set intervals for overdue status reports, in the Status Report Reminders section, select the appropriate options to set e-mail alerts to be sent when a resource's status report is overdue (and until the status report has been sent) and have the alerts sent only to you, only to your team members, or both to you and your team members. You can also specify the number of days past the due date for the status report at which the alert is sent and the frequency at which reminder e-mails are sent until the status report is submitted.

  4. If Multilingual User Interface Packs (MUI Packs) are installed for Project Server 2010, select the language in which you want to receive your notifications from the Language Settings drop-down list.

  5. Click Save.

Unsubscribe your resources from e-mail notifications

If your resources are currently configured to receive personal e-mail notification and alerts, follow these steps to unsubscribe them.

To unsubscribe your resources from e-mail notifications

  1. On the Project Web App home page, in the navigation column, click Personal Settings, then select Manage My Resources' Alerts and Reminders.

  2. To unsubscribe from alerts for your resource's tasks, expand My Team Members' Tasks and in the Task Alerts section, clear the check box for the specific type of alert from which you want to unsubscribe.

  3. To unsubscribe from e-mail notifications sent when your resources send status reports, expand My Resources' Status Reports and in the Status Report Alerts section clear the Submit a status report check box.

  4. Click Save.

Other chapters

For more information, see the other chapters in this guide:

  • Navigating Project Web App

  • Managing projects in Project Web App

  • Managing resources in Project Web App

  • Managing task updates in Project Web App

  • Managing issues, risks, and documents in Project Web App

  • Managing status reports in Project Web App

See Also

Concepts

Microsoft Project Server 2010 Project Manager's Guide for Project Web App


Server Settings (Project Server 2010)

Published: March 31, 2011

This section helps your organization understand the tasks involved with administering Microsoft Project Server 2010.

Articles in this section include the following:

  • Security (Project Server 2010 settings)

  • Enterprise Data (Project Server 2010 settings)

  • Database Administration (Project Server 2010 settings)

  • Look and Feel (Project Server 2010 settings)

  • Time and Task Management (Project Server 2010 settings)

  • Queue (Project Server 2010 settings)

  • Operational Policies (Project Server 2010 settings)

  • Workflow and Project Detail Pages (Project Server 2010 settings)

What you will learn in this section

There are several important tasks that an administrator must manage in Project Server 2010 for Microsoft Project Web App users to access and interact effectively with project data. These tasks include the following:

  • Managing users, groups, and categories

  • Customizing Project Web App to fit the specific needs of your organization

  • Managing workflows

  • Managing enterprise data (custom fields, calendars, views, etc.)

  • Managing queue settings for your specific environment

  • Managing time and task tracking

  • Configuring Active Directory synchronization to security groups and resources

Whom these articles are written for

This section produces maximum benefits for the following professionals:

  • Project Server administrators Those persons who have administrative privileges for Project Server 2010 and perform the duties required to configure and maintain Project Server 2010.

  • SharePoint Server farm administrators Those persons responsible for administering the SharePoint Central Administration Web site and making sure that Project Server 2010 and Microsoft SharePoint Server are always correctly synchronized and that SharePoint Server features and functionality are available.

  • Project Management Office (PMO) Those persons who help define and maintain project management standards and practices throughout the organization.

  • Project site administrators Those persons who have administrative privileges for Project Server 2010 and perform the duties required to configure Project Server 2010 to meet organizational portfolio and project management needs.

  • Active Directory administrators Those persons responsible for setting up individual e-mail accounts and security groups in the Active Directory directory service that are mapped to the Project Server 2010 Enterprise Resource Pool and Project Server 2010 security groups.

  • Any member of your organization's Project Server deployment planning team Those persons within your organization who plan the deployment of Project Server 2010 and who may need a better understanding of the day-to-day Project Server administrative tasks that are available in Project Web App.


Security (Project Server 2010 settings)
See Also

Published: May 12, 2010

Microsoft Project Server 2010 security is based on users, groups, and categories. Groups contain sets of users who need to access the same set of data in the same way. Categories provide access to projects and resources based on parameters that you define.

Define your groups by identifying common needs based on the areas of Project Server to which users in your organization need access. After you define your groups, you can add users to the groups and grant permissions to the groups. Permissions assigned to groups apply to all of the users that the group contains. Using groups to control access to Project Server simplifies security administration.

Project Server users can be automatically added or removed from groups based on Active Directory group membership. This can be configured in Project Server 2010 through the Active Directory synchronization feature. For more information, see Manage security group synchronization with Active Directory in Project Server 2010.

Users can belong to multiple groups according to their role in the organization and their access requirements. Several groups are created by default when Project Server 2010 is installed, each of which is assigned a set of predefined categories and permissions. For more information, see Manage security groups in Project Server 2010.

Administrators usually assign permissions by adding a user account to one of the built-in groups or by creating a new group and assigning specific permissions to that group.

For complete lists of Project Server permissions, see Project Server 2010 category permissions and Project Server 2010 global permissions.

The following tasks for managing security in Project Server are performed on these components:

  • Manage users in Project Server 2010

  • Manage security groups in Project Server 2010

  • Manage categories in Project Server 2010

  • Manage security templates in Project Server 2010

  • Manage Project Web App permissions in Project Server 2010

  • Manage security group synchronization with Active Directory in Project Server 2010

  • Active Directory Resource Pool Synchronization (Project Server 2010 settings)

  • Manage delegates (Project Server 2010 settings)

See Also

Concepts

Project Server and SharePoint Server security
Plan groups, categories, and RBS in Project Server 2010


Manage users in Project Server 2010
See Also

Published: May 12, 2010

Summary: Project Server Administrators can manage security permissions for users by using the Manage Users page in PWA Server Settings.

When you make the initial connection to Microsoft Project Server 2010 through the Microsoft Project Web App (PWA) site, you must be logged on using the administrator account used to provision the PWA site. You can use this initial account to create other user accounts that can access Project Server. For example, this initial account could be used to create the user accounts that will serve as Project Server administrators, who will in turn create other user accounts and will do additional post-installation configuration.

You can use the Manage Users page that is available from the Server Settings page to add new individual users, modify existing users, deactivate user accounts, and reactivate inactive user accounts. You can also assign permissions to users by adding them to one of the built-in groups or by creating a custom group and assigning specific permissions to the custom group.

Requirements for managing users

The following are required to perform the procedures for this task:

  • Access to Project Server through the Project Web App site.

  • The Manage users and groups global permission in order to add, modify, deactivate, or reactivate a user account

To manage users in Project Server, you can perform the following procedures:

  • Add a user account in Project Server 2010

  • Modify a user account in Project Server 2010

  • Deactivate a user account in Project Server 2010

  • Reactivate a user account in Project Server 2010

See Also

Concepts

Determine the number and types of users (Project Server 2010)
Security (Project Server 2010 settings)
Project Server 2010 global permissions
Project Server 2010 category permissions
Manage security groups in Project Server 2010
Manage categories in Project Server 2010
Manage security templates in Project Server 2010
Manage Project Web App permissions in Project Server 2010


Add a user account in Project Server 2010
See Also

Published: May 12, 2010

Summary: Add user accounts by using the Manage Users page in PWA Server Settings.

Every Microsoft Project Server 2010 user must have a user account before he or she can log on to Project Server 2010 and interact with Project Server data. User accounts can be added through the Manage Users page in Microsoft Project Web App (PWA) Server Settings.

Note:

Windows users can also be added to Microsoft Project Web App from the Active Directory directory service through Active Directory Synchronization.

Before you perform this procedure, confirm the following:

  • You have read Manage users in Project Server 2010.

  • You have access to Project Server 2010 through the Project Web App site.

  • The user accounts that you are adding are configured properly in either Active Directory or the forms-based membership provider so that their information is available to Project Server 2010. Project Server 2010 supports two authentication methods for its users (Windows authentication and forms-based authentication). For more information about supported authentication methods for Project Server 2010, see Plan for authentication in Project Server 2010.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

To add a new user account, perform the following procedure.

To add a user

  1. On the Server Settings page, in the Security section, click Manage Users.

  2. On the Manage Users page, click New User.

  3. On the New User page, fill out the required information for the user. See the following sections for more information about each option.

  4. Click Save.

Identification Information

Use the Identification Information section to specify user information such as name, e-mail address, and account status.

The following table describes the user identification options.

Attribute | Description
User can be assigned as a resource | The status of the user as an Enterprise Resource. Select User can be assigned as a resource to enable this user account to be assigned tasks as a resource. Selecting this entry makes the user an Enterprise Resource. This setting is the default selection. Once a user account becomes an Enterprise Resource it cannot be changed back to a non-Enterprise Resource even if the check box is cleared.
Display Name | The name for the user account. This is a required field.
E-mail address | The e-mail address for the user. This field is required to synchronize tasks with Microsoft Exchange Server.
RBS | The user's position in the Resource Breakdown Structure hierarchy.
Initials | The user's initials.
Hyperlink Name | The name of the user's web site (for example, a team web site) if applicable.
Hyperlink URL | The URL of the user's web site, if applicable.
Account Status | Can be set to Active or Inactive. If the value is set to Active, the user account functions normally. If the value is set to Inactive, the user is unable to access the account.

User Authentication

Use the User Authentication section to specify the user's logon account and whether the user account should be synchronized with Active Directory.

The following table describes the user account options.

Attribute Description

User logon account

If you are using Integrated Windows authentication, type the user's account name in the form of DomainName\UserAccountName.

If you are using forms-based authentication, type the user account name in the form of MembershipProviderName:UserAccount.

Prevent Active Directory synchronization for this user

Selecting the Prevent Active Directory synchronization for this user check box prevents a user account from being synchronized during Active Directory Resource Pool Synchronization.

Assignment Attributes

Use the Assignment Attributes section to define information associated with the user's assignment to tasks. This includes calendar, booking type, timesheet manager, assignment owner, and cost and availability information.

Note:

If you have not selected the User can be assigned as a resource check box, these options are not available.

The following table describes the Project Server user assignment attribute options.

Attribute | Description
Resource can be leveled | Indicates whether the resource can be leveled. Leveling is the process that is used to resolve resource conflicts or over-allocations by delaying or splitting certain tasks. When Project levels a resource, its selected assignments are distributed and rescheduled.
Base Calendar | The base calendar for this resource. A base calendar is a calendar that can be used as a project and task calendar that specifies default working and non-working time for a set of resources.
Default Booking Type | The configuration of a user's booking type as either Committed or Proposed. A committed resource is formally allocated to any task assignment in a project. A proposed resource has a pending resource allocation to a task assignment that has not yet been authorized. This resource assignment does not detract from the availability of the resource to work on other projects.
Timesheet manager | The timesheet manager, if there is one, for the user.
Default Assignment Owner | The enterprise resource who is responsible for entering progress information in PWA. This person can differ from the person first assigned to the task. For example, a material resource cannot log on to PWA but the assignment owner field allows an enterprise resource to enter progress for the resource within PWA.
Earliest Available | The earliest date that the user is available as a resource. This date corresponds to the resource availability dates for a resource that can be seen in Microsoft Project Professional 2010.
Latest Available | The latest date that the user is available as a resource. This date corresponds to the resource availability dates for a resource that can be seen in Project Professional 2010.
Standard Rate | The rate for the work on an assignment that is scheduled during the regular working hours of an assigned resource. To establish variable rates, open the enterprise resource in Project Professional 2010 and set this information in the Cost Rate tables.
Overtime Rate | The rate for the work on an assignment that is scheduled beyond the regular working hours of an assigned resource. To establish variable rates, open the enterprise resource in Project Professional 2010 and set this information in the Cost Rate tables.
Current Max. Units (%) | The percentage of time that the resource is available for assignments. The current max units is tied to the early and late availability dates, if set. For example, if today is 1/1/2011 and the earliest available date is 1/2/2011 then the max units value is 0% and text next to the field says "Custom availability detected, edit in Project Professional 2010."
Cost/Use | The per-use cost of the resource if applicable. For work resources, a per-use cost accrues every time that the resource is used. For material resources, a per-use cost is accrued only one time.

Exchange Server Details

Use the Exchange Server Details section to specify whether the user's tasks should be synchronized with Exchange Server.

Select the Synchronize Tasks check box if you want to enable task synchronization by using Microsoft Exchange Server for this user. Exchange integration must be configured for task synchronization to function.

For more information about how to configure task synchronization with Exchange Server, see Deploy Project Server 2010 with Exchange Server.

Departments

Use the Departments section to define whether the user is a member of a particular department. (You define departments for your organization by populating the Departments custom lookup table.)

If the user is a member of a department, click the expand button (…) and select the department from the displayed hierarchy.

Security Groups

Use the Security Groups section to specify the user's membership in security groups.

To add the user to a security group, select the group in the Available Groups list, and then click Add.

The following table describes the security group configuration options for a user.

Attribute | Description
Available Groups | The Available Groups list contains the groups that the user is currently not a member of.
Groups that contain this user | The Groups that contain this user list contains the groups that the user is currently a member of.

Security Categories

Use the Security Categories section to specify the user's membership in security categories.

To add the user to a category, select the category in the Available Categories list, and then click Add. To modify the category permissions for this user in a category, select the category in the Selected Categories list, and then select Allow for the permissions that you want to enable.

Important:

We recommend that you do not set category permissions for a single user. Instead, assign the user to a group and set category permission for the group. This allows for easier maintenance.

The following table describes the security category configuration options for a user.

Attribute | Description
Available Categories | The Available Categories list contains the categories that the user is not a member of.
Selected Categories | The Selected Categories list contains the categories that the user is a member of.
Permissions for <category> | The Permissions for <category> area lets you configure category permissions for this user for the selected category.
Set permissions with Template | The Set permissions with Template option can be used to prepopulate a set of category permissions based on a predefined template for the user's role (such as Executive or Project Manager).

Global Permissions

Use the Global Permissions section to configure global permissions for the user.

To allow or deny a global permission for the user, select the Allow or Deny check box for the permission.

We recommend that you do not configure global permission for a single user. Instead, configure permissions at the group level and add users to the appropriate group. Doing this allows for much easier administration and helps in troubleshooting permissions issues.

For a complete list of global permissions, see Project Server 2010 global permissions.

Group Fields

Use the Group Fields section to define group and cost information for the user. Group fields are not tied to Project Server security, but are a way to specify that a user belongs to a particular group in your organization. These fields appear in the Project Server reporting database and can be used for reporting. Cost Type can be added to the resource and assignment OLAP cubes.

If your organization uses group names, codes, or cost center information for people, type the information in the Group Fields area. The values available for Cost Type are those that are defined in the Cost Type custom lookup table. By default, the Group field is synchronized with Active Directory if you use Active Directory synchronization.

Team Details

Use the Team Details section to define a team association for the user. To use teams, you must first do the following:

  1. Create a custom lookup table and populate it with the team names that you want to use.

  2. Edit the Team Name custom field to use the new lookup table.

You can use teams to pool assignments under a single resource where they can be later reassigned to other resources. For example, you could create a team resource named "Development" to which you assign software development tasks. By assigning this resource to the Development team and selecting the Team Assignment Pool check box, you enable other users on the Development team to see any tasks assigned to the Development resource and to accept the assignments in PWA. You could also select Team Assignment Pool for a team lead and have all assignments go through that person for distribution to team members.

System Identification Data

The System Identification Data section displays user metadata, such as when the account was created, updated, or checked out.

In the System Identification Data section, type additional identifying information for the user in the External ID box. This information can be used to link the person to corresponding information elsewhere in the organization, or to facilitate the consolidation of reporting of resource use beyond what Project Server provides.

The following table describes the system identification data fields.

Attribute | Description
GUID | The unique ID associated with this user.
External ID | An identifier that can be used to link this user to external data.
Active Directory GUID | The unique ID for this user's Active Directory account.
Date Created | The date this user account was created.
Date last updated | The date this user account was last updated.
Checked out by | The user who currently has this user account checked out.
Checkout date | The date this user account was checked out.

See Also

Concepts

Manage users in Project Server 2010
Modify a user account in Project Server 2010
Active Directory Resource Pool Synchronization (Project Server 2010 settings)
Test background operations (Project Server 2010)


Modify a user account in Project Server 2010
See Also

Published: May 12, 2010

Summary: Edit user accounts by using the Manage Users page in PWA Server Settings.

In Microsoft Project Server 2010, you can modify existing account information for any user. You might want to do this, for example, if a resource name is changed or if a resource changes roles in your organization.

Before you perform this procedure, confirm the following:

  • You have read Manage users in Project Server 2010.

  • You have access to Project Server 2010 through the Microsoft Project Web App site.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

Modify a user account

Use this procedure to modify an existing Project Server 2010 user account.

To modify a user account

  1. On the Project Web App home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Manage Users.

  3. On the Manage Users page, in the Users list, click the name of the user that you want to edit.

  4. On the Edit User page for the selected user, make your changes to the user account information. For information about each option on the page, see Add a user account in Project Server 2010.

  5. Click Save.

See Also

Concepts

Manage users in Project Server 2010
Add a user account in Project Server 2010
Active Directory Resource Pool Synchronization (Project Server 2010 settings)
Test background operations (Project Server 2010)


Deactivate a user account in Project Server 2010
See Also

Published: May 12, 2010

Summary: Deactivate user accounts by using the Manage Users page in PWA Server Settings.

At times, you may have to make Microsoft Project Server user accounts unavailable. When you deactivate a user account, that user's information and data remains in the database, but the user is unavailable for new assignments. The user account is inactive until it is reactivated.

Deactivating a user account means that it can no longer be used to log on to Project Server 2010. Users cannot use this account to send assignment updates, request status reports, or delegate tasks.

Before you deactivate a user account, make sure that the user does not own any projects in Project Server. If the user does own projects, you must transfer ownership of the projects to another user before you deactivate the account. Also, remove all active user delegations for the account that is to be deactivated.

Once a user is deactivated, the Project Manager is prompted to reassign the user's work. This prompt occurs when the Project Manager opens the project in Microsoft Project Professional 2010.

User accounts, when deactivated, are not actually deleted from the Project Server database. This is to ensure that any relationships that resource might have with project data can be preserved in case the account is reactivated later. The option to delete a user is available in the Database Administration section in Server Settings. However, deactivating a user to preserve data is recommended.

After an account is deactivated, the account cannot access Project Server 2010 until it has been reactivated. The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

When you are using Active Directory synchronization, Project Server users not found in the Active Directory group being synchronized will be deactivated. If a user is to be removed from the Active Directory directory service but you do not want the account deactivated, select the Prevent Active Directory synchronization for this user check box in the User Authentication section on the Edit User page.

Before you perform this procedure, confirm the following:

  • You have read Manage users in Project Server 2010.

  • You have access to Project Server 2010 through the Microsoft Project Web App site.

  • The user account that you are deactivating truly must be deactivated.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

Deactivate a user account

Use this procedure to deactivate an active Project Server 2010 user account. After this procedure has been performed, the account will be unable to access Project Server 2010 until it has been reactivated.

To deactivate a user account

  1. On the Project Web App home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Manage Users.

  3. On the Manage Users page, in the Users list, find the user account that you want to deactivate. (You can use the Search box to search for a specific user.) Click the check box next to the user name of the account that you want to deactivate. Note that you can select multiple user accounts.

  4. Click Deactivate Users.

  5. A message box appears and asks for confirmation. Click OK to deactivate the user account or user accounts.

See Also

Concepts

Reactivate a user account in Project Server 2010
Active Directory Resource Pool Synchronization (Project Server 2010 settings)
Test background operations (Project Server 2010)


Reactivate a user account in Project Server 2010
See Also

Published: May 12, 2010

Summary: Turn on deactivated user accounts by using the Manage Users page in PWA Server Settings.

After deactivating a user account, you may need to reactivate it at some later time. Because the user information still exists in the Project Server database, you simply need to change the account status from Inactive to Active.

Before you perform this procedure, confirm that:

  • You have read Manage users in Project Server 2010.

  • You have access to Project Server 2010 through the Microsoft Project Web App site.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

To reactivate a user account

Use this procedure to reactivate a deactivated Project Server 2010 user account. After you have performed this procedure, the reactivated account is able to access Project Server 2010.

Reactivate a user account

  1. On the Project Web App home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Manage Users.

  3. On the Manage Users page, in the Users list, find the user account you want to reactivate. (You can use the Search box to search for a specific user.) Click the user name of the account.

  4. On the Edit User page for the selected user, in the Identification Information section, select Active from the Account Status drop-down list.

  5. Click Save.

See Also

Concepts

Deactivate a user account in Project Server 2010
Active Directory Resource Pool Synchronization (Project Server 2010 settings)
Test background operations (Project Server 2010)


Manage security groups in Project Server 2010
See Also

Published: May 12, 2010

Summary: Administrators can manage security permissions for groups by using the Manage Groups page in PWA Server Settings.

A group is a container for users that can be assigned permissions in Microsoft Project Server 2010. Users automatically inherit the permissions of any group to which they belong. By adding users to groups, you can significantly reduce the amount of time spent managing user permissions. You can manage groups from the Microsoft Project Web App (PWA) Server Settings page.

Avoid creating unnecessary groups. Having lots of groups and categories in an organization can lead to additional management complexity. Additionally, having many groups and categories can stress the authorization system, which can affect performance.

You can modify the information associated with any security group in Project Server 2010. For example, you may have to modify the group for changes to users or categories, or for changes to the Active Directory group to which it is currently being synchronized.

We recommend not modifying the default Project Server groups, but instead creating a new group that has the same permissions and modifying the new group.

By default, the following groups are created when Project Server 2010 is installed:

  • Team Members Users have general permissions for using PWA, but limited project-level permissions. This group is intended to give everyone basic access to PWA. All new users are added to the Team Members group automatically. This group is associated with the My Tasks category.

  • Project Managers Users have most global and category-level project permissions and limited resource permissions. This group is intended for users who maintain project schedules daily. This group is associated with the My Organization and My Projects categories.

  • Resource Managers Users have most global and category-level resource permissions. This group is intended for users who manage and assign resources and edit resource data. This group is associated with the My Direct Reports, My Organization, My Projects, and My Resources categories.

  • Executives Users have permissions to view project and Project Server data. This group is intended for high-level users who need visibility into projects but are not themselves assigned project tasks. This group is associated with the My Organization category.

  • Team Leads Users have limited permissions around task creation and status reports. This group is intended for people in a lead capacity who do not have regular assignments on a project. This group is associated with the My Projects category.

  • Portfolio Managers Users can create and edit data, but cannot perform Project Server administrative tasks such as adding users or creating groups. Portfolio Managers are able to view and edit all projects and resources in the organization. This group is associated with the My Organization category.

  • Administrators This group is granted all available Project Server permissions. It is associated with the My Organization category.

These default groups should be used together with the five default categories.

Task requirements

The following are required to perform the procedures for this task:

  • Access to Project Server 2010 through the Project Web App site.

  • The Manage users and groups global permission in Project Server 2010 in order to add, modify, or delete a group.

To manage groups in Project Server 2010, you can perform the following procedures:

  • Create a security group in Project Server 2010

  • Modify a security group in Project Server 2010

  • Delete a security group in Project Server 2010

See Also

Concepts

Security (Project Server 2010 settings)
Project Server 2010 category permissions
Project Server 2010 global permissions
Plan groups, categories, and RBS in Project Server 2010


Create a security group in Project Server 2010
See Also

Published: May 12, 2010

Summary: Create custom security groups by using the Manage Groups page in PWA Server Settings.

Seven default security groups are installed with Microsoft Project Server 2010. To better meet the security requirements of your own organization, you can also create custom groups by using the Manage Groups page on the Microsoft Project Web App (PWA) site Server Settings page.

Before you perform this procedure, confirm the following:

  • You have read Manage security groups in Project Server 2010.

  • You have access to Project Server 2010 through Microsoft Project Web App.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

Perform the following procedure to create a custom group in Project Server 2010.

To create a security group

  1. On the Server Settings page, in the Security section, click Manage Groups.

  2. On the Manage Groups page, click New Group.

  3. Complete the required fields on the Add or Edit Group page. See the following sections for information about each area.

  4. Click Save.

Group information

Use the Group Information section to specify a name and description for the group.

If you want to synchronize the membership of this group with an Active Directory group, click Find Group and search for the group that you want to synchronize. To stop synchronizing an existing group, click Clear Group.

The following table describes the group information options.

Attribute | Description
Group Name | The name of the group.
Description | A description of the group.
Active Directory Group to Synchronize | The name of the Active Directory group from which this group obtains its membership. If you configure this group to synchronize with an Active Directory group, the membership of this group will be synchronized with the Active Directory group specified on the schedule that you configure.

Users

Use the Users section to specify which Project Server users are members of this group.

To add users to the group, select the users in the Available Users list, and then click Add. To remove users from the group, select the users in the Selected Users list, and then click Remove.

If you have configured Active Directory synchronization for this group, the group membership is maintained by that mechanism. Any changes that you make manually may be overwritten the next time that the group is synchronized with the Active Directory directory service.

The following table describes the options for users in the group.

Attribute | Description
Available Users | The users in Project Server that are not members of this group.
Selected Users | The users in Project Server that are members of this group.

Categories

Use the Categories section to define which security categories area associated with this group.

To associate a category with this group, select the category in the Available Categories list, and then click Add.

To set the category-level permissions for a particular category, select the category in the Selected Categories list, and then click Allow for the permissions that you want to enable for this category/group combination.

The following table describes the categories options for a group.

Attribute | Description
Available Categories | The categories that are not associated with this group.
Selected Categories | The categories that are associated with this group.
Permissions for <category> | The permissions that members of this group have within the selected category. This option appears when you select a category in the Available Categories list.
Set permissions with Template | To set the category permissions for the selected category from a template — such as Project Manager or Team Member — select the desired template from the drop-down list, and then click Apply.

Global permissions

Use the Global Permissions section to configure global permissions for this group.

To allow a permission for the group, select the Allow check box for that permission.

To deny a permission for the group, select the Deny check box for that permission.

For a complete list of global permissions, see Project Server 2010 global permissions.

Note:

If neither check box is selected for a permission, the user is not allowed the permission unless it is allowed in another group that the user is a member of, or it is allowed at the user level. If the Deny check box is selected for a permission, that permission is denied for all users in the group and cannot be enabled through other group or user settings.

See Also

Concepts

Plan groups, categories, and RBS in Project Server 2010
Project Server 2010 global permissions
Manage security groups in Project Server 2010


Modify a security group in Project Server 2010
See Also

Published: May 12, 2010

Summary: Change settings for security groups by using the Manage Groups page in PWA Server Settings.

You can modify the information associated with any security group in Microsoft Project Server 2010. For example, you may have to modify the group for changes to users or categories, or for changes to the Active Directory group to which it is currently being synchronized.

Before you perform this procedure, confirm the following:

  • You have read Manage security groups in Project Server 2010.

  • You have access to Project Server 2010 through the Microsoft Project Web App site.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

Modify a security group

Perform the following procedure to modify an existing group in Project Server 2010.

To modify a group

  1. On the Project Web App home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Manage Groups.

  3. On the Manage Groups page, in the Group Name list, click the name of the group that you want to modify.

  4. On the Add or Edit Group page for the selected group, make your changes to the group information. For information about each option on the page, see Create a security group in Project Server 2010.

  5. Click Save.

See Also

Concepts

Manage security groups in Project Server 2010


Delete a security group in Project Server 2010
See Also

Published: May 12, 2010

Summary: Delete custom security groups by using the Manage Groups page in PWA Server Settings.

If you no longer need a security group in Microsoft Project Server 2010, you can delete it. Before you delete a group, ensure that no other users or groups are dependent on it for required permissions.

Before you perform this procedure, confirm that:

  • You have read Manage users in Project Server 2010.

  • You have access to Project Server 2010 through the Microsoft Project Web App site.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

To delete a security group

Perform the following procedure to delete a group in Project Server 2010.

Important:

We highly recommend not deleting the default Project Server groups. The Team Members group cannot be deleted.

Delete a custom group

  1. On the Project Web App home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Manage Groups.

  3. On the Manage Groups page, in the Group Name list, find the group you want to delete. Select the check box next to the group that you want to delete. Note that you can select multiple groups.

  4. Click Delete Group.

  5. A message box appears, asking for confirmation and noting that the group will be permanently removed. Click OK to delete the group.

    Note:

    Security groups are permanently deleted, unlike deactivated user accounts (which can be reactivated). If you delete a security group and then find that you want to have it again, you must recreate it.

See Also

Concepts

Manage users in Project Server 2010


Manage categories in Project Server 2010
See Also

Published: May 12, 2010

Summary: Administrators can organize a system of categories to manage user and group access to projects, resources, and views in PWA.

Categories are the collections of projects, resources, and views to which users and groups in Project Server are granted access. Categories define which collections of specific data (projects, resources, and views) that these users and groups have access to. Categories also allow the administrator to filter data using security rules, like Resource Breakdown Structure (RBS), that can help organize and display data in specific ways.

You can add projects and resources to categories manually by choosing them from lists, or you can use dynamic filters to automatically add them to categories. Any user associated with a category can be granted permission to the projects and resources in that category.

  • You must have the Manage users and groups global permission to add, modify, or delete a category.

  • Avoid creating unnecessary categories. Having a large number of groups and categories within an organization can stress the authorization system, which can affect performance.

Microsoft Project Server 2010 creates five default categories during installation. These default categories are designed to enable Project Server to provide the most common layer of security for a hierarchical organization or matrix organization.

Default category | Default groups in the category | Description
My Tasks | Team Members | Primarily used by project resources who have assigned tasks.
My Projects | Project Managers Resource Managers Team Leads | Provides access to all projects that a user owns.
My Resources | Resource Managers | Intended for resource managers and is useful only after the Resource Breakdown Structure (RBS) is defined.
My Direct Reports | Resource Managers | Intended for users who need to be able to approve timesheets.
My Organization | Executives Portfolio Managers Project Managers Resource Managers Administrators | Used to grant access to all information in the organization. This category is intended for members of a Project Management Office (PMO), executives in an organization, and other key users who require the ability to view projects and resources across the entire organization.

Task requirements

The following are required to perform the procedures for this task:

  • Access to Project Server 2010 through the Microsoft Project Web App site.

  • The Manage users and groups global permission in Project Server 2010 in order to create, modify, or delete a category.

To manage categories in Project Server 2010, you can perform the following procedures:

  • Create a category in Project Server 2010

  • Modify a category in Project Server 2010

  • Delete a category in Project Server 2010

See Also

Concepts

Security (Project Server 2010 settings)
Plan groups, categories, and RBS in Project Server 2010
Project Server 2010 category permissions
Project Server 2010 global permissions
Microsoft Project Server 2010 default categories


Create a category in Project Server 2010
See Also

Published: May 12, 2010

Summary: Add custom security categories by using the Manage Categories page in PWA Server Settings.

In Microsoft Project Server 2010, you can add custom security categories as necessary to create a Project Server security model that meets the specific needs of users and groups in your organization.

Avoid creating unnecessary categories. Having lots of groups and categories in an organization can lead to greater administrative complexity. Additionally, having many groups and categories can stress the authorization system, which can affect performance.

If there are many users at the highest level of the Resource Breakdown Structure (RBS), consider adding them to a custom category that enables them to view all projects (avoiding dynamic rules). Top-level RBS users probably have access to all projects, so assigning them to this category avoids unnecessary work by the authorization system.

Before you perform this procedure, confirm the following:

  • You have read Manage categories in Project Server 2010.

  • You have access to Project Server 2010 through a Microsoft Project Web App (PWA) site.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

To create a new category, perform the following procedure.

To create a category

  1. On the Microsoft Project Web App (PWA) home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Manage Categories.

  3. On the Manage Categories page, click New Category.

  4. Complete the Add or Edit Category page. See the following sections for information about each setting.

  5. Click Save.

Name and Description

Use the Name and Description section to specify a name and description for the category.

The following table describes the name and description options for a category.

Attribute | Description
Category Name | The name of the category. This name must different be than that of other categories.
Description | Description of the category.

Users and Groups

Use the Users and Groups section to specify which users and groups are associated with this category.

To associate a user or group with this category, select the user or group in the Available Users and Groups list, and then click Add.

To remove the association between a user or group and this category, select the user or group in the Users and Groups with Permissions list and then click Remove.

For easiest administration, only associate groups with categories.

Attribute | Description
Available Users and Groups | Users and groups that are not associated with this category.
Users and Groups with Permissions | Users and groups that are associated with this category.

To select the category permissions for each user or group, select the user or group in the Users and Groups with Permissions list. This action displays the category permissions for the selected group in this category.

Each user or group can be assigned distinct permission in a category.

For a complete list of category permissions, see Project Server 2010 category permissions.

Projects

Use the Projects section to specify the projects that users associated with this category can view.

You can explicitly select projects that users who have permissions in this category can view, or you can use one of the dynamic security options to have projects made available to users based on their relationship to the project or their RBS value.

Attribute Description

All current and future projects in Project Server database

When this option is selected, users in this category can see all projects in this instance of PWA.

Only the projects indicated

When this option is selected, users in this category can view the projects in the Selected Projects list and any projects from the Available Projects list that the user has permissions to see with the dynamic permissions options. The dynamic permissions features only work when this option is selected.

Available projects

Projects that are not explicitly part of this category. Users may still be able to view these projects if any of the dynamic permissions options are configured to enable it.

Selected projects

Projects that users in this category can view.

The User is the Project Owner or the User is the Status Manager on assignments within that Project

Gives users permissions on any project they own. Also gives Status Managers permissions on projects that contain assignments that they manage.

The User is on that project's Project Team

Gives users permissions on any project where they are on the project team. Users do not need to have assignments on the project.

The Project Owner is a descendant of the User via RBS

Gives users permissions on any project that is managed by resources subordinate to them in the RBS hierarchy.

A resource on the project's Project Team is a descendant of the User via RBS

Allows a user to view any project where a resource subordinate to the user in the RBS is a member of the project team.

Avoid using this rule for users who have many resources under them in the RBS. If the resources under them are on many projects involving many categories, this stress on the authorization system can affect performance (for example, delay the loading of the Project Center page).

The Project Owner has the same RBS value as the User

Allows a user to view projects managed by persons that have the same RBS value that the user has.

Resources

Use the Resources section to specify which resources the users associated with this category can view.

You can explicitly select resources that users who have permissions in this category can view, or you can use one of the dynamic security options to have resources made available to users based on their relationship to the resource or their RBS value.

Attribute | Description
All current and future resources in Project Server database | When this option is selected, users in this category can see all resources in this instance of PWA.
Only the resources indicated | When this option is selected, users in this category can view the resources in the Selected Resources list and any resources from the Available Resources list that the user has permissions to see with the dynamic permissions options.
Available Resources | Resources that are not explicitly part of this category. Users may still be able to view these resources if any of the dynamic permissions options are configured to enable it.
Selected Resources | Resources that users in this category can view.
The User is the resource | Gives users permissions to view information about themselves (such as assignments).
They are members of a Project Team on a project owned by the User | Gives users permissions to view information for all resources in projects they own.
They are descendants of the User via RBS | Gives users permissions to view information for all resources under them in the RBS.
They are direct descendants of the User via RBS | Gives users permissions to view information about resources that are directly under them in the RBS.
They have the same RBS value as the User | Gives user permissions to view information about resources that have the same RBS value.

Views - Add to Category

Use the Views - Add to Category section to specify views that users associated with this category can see.

To add a view to the category, select the Add check box for that view. To remove a view, clear the Add check box for that view.

See Also

Concepts

Manage categories in Project Server 2010
Plan groups, categories, and RBS in Project Server 2010
Project Server 2010 global permissions
Plan groups, categories, and RBS in Project Server 2010
Modify a category in Project Server 2010
Delete a category in Project Server 2010


Modify a category in Project Server 2010
See Also

Published: May 12, 2010

Summary: Edit security categories by using the Manage Categories page in PWA Server Settings.

In Microsoft Project Server 2010, you can modify an existing category from the Manage Categories page in on the Microsoft Project Web App (PWA) Server Settings page. You might want to do this, for example, if an existing category has to be updated for new projects and resources.

Before you perform this procedure, confirm the following:

  • You have read Manage categories in Project Server 2010.

  • You have access to Project Server 2010 through the Project Web App site.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

Modify a category

Perform the following procedure to modify an existing category in Project Server 2010.

To modify a category

  1. On the PWA home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Manage Categories.

  3. On the Manage Categories page, in the Category Name list, click the name of the category that you want to edit.

  4. On the Add or Edit Category page, make your changes to the category information. For information about the options on the page, see Create a category in Project Server 2010.

  5. Click Save.

See Also

Concepts

Plan groups, categories, and RBS in Project Server 2010
Project Server 2010 global permissions
Create a category in Project Server 2010
Delete a category in Project Server 2010
Manage categories in Project Server 2010


Delete a category in Project Server 2010
See Also

Published: May 12, 2010

Summary: Delete custom security categories by using the Manage Categories page in PWA Server Settings.

In Microsoft Project Server 2010, you can delete any existing custom category from the Manage Categories page in Microsoft Project Web App.

Note:

Default Project Server categories cannot be deleted.

Before you perform this procedure, confirm that:

  • You have read Manage categories in Project Server 2010.

  • You have access to Project Server 2010 through the Microsoft Project Web App site.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

To delete a category

Perform the following procedure to delete an existing category in Project Server 2010.

Delete a category

  1. On the Project Web App home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Manage Categories.

  3. On the Manage Categories page, in the Category Name list, find the category that you want to delete. Select the check box next to the category that you want to delete. Note that you can select multiple categories.

  4. Click Delete Categories.

    A warning message appears, noting that the category will be permanently removed.

    Caution:

    Verify that the category you are deleting is the one you intend to delete. If you accidentally delete the wrong category, it is permanently deleted and will need to be recreated.

  5. Click OK.

See Also

Concepts

Manage categories in Project Server 2010
Plan groups, categories, and RBS in Project Server 2010
Project Server 2010 global permissions
Create a category in Project Server 2010
Modify a category in Project Server 2010


Manage security templates in Project Server 2010
See Also

Published: May 12, 2010

Summary: Administrators can use security templates in PWA to standardize the granting of user permissions by role.

Security templates provide a means for you to quickly apply or reset predefined permission profiles to new or existing users, groups, and categories. By applying security templates, you can easily standardize the permissions that you assign according to user's role in the organization. A number of predefined security templates are created by default when Microsoft Project Server 2010 is installed. These align with the predefined groups. You can customize these security templates or create new security templates according to your needs.

Creating custom templates requires planning. You must first identify the common Project Server usage patterns in your organization that are not reflected in the default Project Server security templates. This helps you to identify your requirements for custom security templates. Then, determine the permissions that the users who share the common Project Server usage patterns require. This defines the security template. Next, determine the set of projects, resources, views, and so on, that the users and groups require access to; this defines the security category. Create the custom security template and apply it to the group of users that share the common usage pattern. The permissions that you define in the custom security template will enable users to access the Project Server security objects that they require.

Project Server 2010 creates eight default security templates during installation.

  • Administrators

  • Executives

  • Portfolio Managers

  • Project Managers

  • Proposal Reviewers

  • Resource Managers

  • Team Leads

  • Team Members

Each security template is given a set of default category and global permissions, based on the functions that each group typically does in an organization. As mentioned previously, when creating new security templates, you are allowed to copy the permissions for a default security template and then customize it to suit your needs.

Note:

For information about the permissions assigned to default security templates, see Project Server 2010 default group permissions.

Task requirements

The following are required to perform the procedures for this task:

  • Access to Project Server 2010 through the Microsoft Project Web App site.

  • The Manage users and groups global permission in Project Server 2010 to create, modify, or delete a security template.

To manage security templates in Project Server 2010, you can perform the following procedures:

  • Create a security template in Project Server 2010

  • Modify a security template in Project Server 2010

  • Delete a security template in Project Server 2010

See Also

Concepts

Security (Project Server 2010 settings)
Plan groups, categories, and RBS in Project Server 2010
Manage security group synchronization with Active Directory in Project Server 2010
Project Server 2010 category permissions
Project Server 2010 global permissions
Project Server 2010 default group permissions


Create a security template in Project Server 2010
See Also

Published: May 12, 2010

Summary: Add custom security templates by using the Manage Templates page in PWA Server Settings.

In Microsoft Project Server 2010, you can group commonly used permissions into a security template and then use it to assign permissions to users, groups, and categories.

Before you perform this procedure, confirm that:

  • You have read Manage security templates in Project Server 2010.

  • You have access to Project Server 2010 through the Microsoft Project Web App site.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

To create a template

Perform the following procedure to create a template in Project Server 2010.

Create a template

  1. On the PWA home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Manage Templates.

  3. On the Manage Templates page, click New Template.

  4. On the Add or Edit Template page, in the Name section, do the following:

    1. In the Template Name box, type a name for the template.

    2. In the Description box, type a short description of the template.

    3. Optionally, you can base the new template on an existing template, and then make any required changes. To do this, select an existing template from the Copy Template list. The new template will be populated with the security permissions from the template you selected.

  5. In the Category Permissions section, select the permissions in the Allow or Deny column that you want to apply towards projects and resources whenever this template is used to set permissions.

    For more information about specific category permissions, see Project Server 2010 category permissions.

  6. In the Global Permissions section, select the permissions in the Allow or Deny columns that you want to apply across Project Server 2010 whenever this template is used to set permissions.

    For more information about specific global permissions, see Project Server 2010 global permissions.

  7. Click Save.

See Also

Concepts

Manage security templates in Project Server 2010
Modify a security template in Project Server 2010
Delete a security template in Project Server 2010
Manage security group synchronization with Active Directory in Project Server 2010
Plan groups, categories, and RBS in Project Server 2010


Modify a security template in Project Server 2010
See Also

Published: May 12, 2010

Summary: Edit security templates by using the Manage Templates page in PWA Server Settings.

In Microsoft Project Server 2010, you can modify the permissions for any existing template in the Manage Templates page in Microsoft Project Web App Server Settings.

Important:

As a best practice, do not make any changes to the default Project Server templates.

Before you perform this procedure, confirm that:

  • You have read Manage security templates in Project Server 2010.

  • You have access to Project Server 2010 through the Project Web App site.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

To modify a template

Perform the following procedure to modify an existing template in Project Server 2010.

Modify a template

  1. On the Project Web App home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Manage Templates.

  3. On the Manage Templates page, in the Template Name list, click the template that you want to edit.

  4. On the Add or Edit Template page, make your changes to the template.

  5. Click Save.

See Also

Concepts

Manage security templates in Project Server 2010
Create a security template in Project Server 2010
Modify a security template in Project Server 2010
Manage security group synchronization with Active Directory in Project Server 2010
Plan groups, categories, and RBS in Project Server 2010


Delete a security template in Project Server 2010
See Also

Published: May 12, 2010

Summary: Delete security templates by using the Manage Templates page in PWA Server Settings.

In Microsoft Project Server 2010, you can delete any existing security templates from the Manage Templates page on the Microsoft Project Web App site.

Important:

As a best practice, do not delete any of the default Project Server templates.

Before you perform this procedure, confirm that:

  • You have read Manage security templates in Project Server 2010.

  • You have access to Project Server 2010 through the Project Web App site.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

To delete a template

Perform the following procedure to delete an existing template in Project Server 2010.

Delete a template

  1. On the Project Web App home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Manage Templates.

  3. On the Manage Templates page, in the Template Name list, select the check box next to the templates that you want to delete.

  4. Click Delete Template.

    A warning message appears, noting that the template will be permanently removed.

  5. Click OK.

See Also

Concepts

Manage security templates in Project Server 2010
Create a security template in Project Server 2010
Modify a security template in Project Server 2010
Manage security group synchronization with Active Directory in Project Server 2010
Plan groups, categories, and RBS in Project Server 2010


Manage Project Web App permissions in Project Server 2010
See Also

Published: May 12, 2010

Summary: Project Server global and category permissions can be disabled, but this action should be examined carefully before it is done.

You can use the Manage Project Web App Permissions page to control which global and category permissions are enabled on a given Microsoft Project Server 2010 instance. An administrator can use the Project Web App Permissions page to deny access to all Project Server 2010 users for a particular feature in Microsoft Project Professional or a Microsoft Project Web App (PWA) instance. If a Project Web App permission is disabled on this page, the equivalent global or category permission is disabled for users throughout PWA. All permissions on this page are enabled by default.

For example, if you deny the Delete project permission, users throughout PWA cannot delete projects, regardless of whether they have the Delete project category permission.

Important:

Before disabling a Project Web App permission, thoroughly consider the effects on your organization of doing so. If you want to turn off a permission for only some Project Web App users, verify whether you can do it by creating a custom group and denying the permissions you want to restrict.

Task requirements

The following are required to perform the procedures for this task:

  • Access to Project Server 2010 through the Project Web App site.

  • The Manage users and groups global permission in Project Server 2010 to manage Project Web App organizational permissions.

To manage Project Web App organizational permissions in Project Server 2010, you can perform the following procedure:

  • Disable a Project Web App permission in Project Server 2010

See Also

Reference

Permissions

Concepts

Plan groups, categories, and RBS in Project Server 2010
Security (Project Server 2010 settings)
Project Server 2010 category permissions
Project Server 2010 global permissions


Disable a Project Web App permission in Project Server 2010
See Also

Published: May 12, 2010

Summary: Project Server global and category permissions can be disabled, but this action should be examined carefully before it is done.

Important:

In Microsoft Project Server 2010, thoroughly consider the effects on your organization of disabling permissions before making such a change. If the removal of the permission does not need to be applied to all users, then verify whether another approach could be used. For example, could you create a custom group and deny the permission you want to restrict instead of disabling the permission throughout the organization?

For information about how permissions work, see Permissions.

Before you perform this procedure, confirm that:

  • You have read Manage Project Web App permissions in Project Server 2010.

  • You have access to Project Server 2010 through the Microsoft Project Web App site.

    Important:

    The Manage users and groups global permission in Project Server 2010 is required to complete this procedure.

To disable a Project Web App organizational permission

Perform the following procedure to disable a Project Web App organizational permission in Project Server 2010.

Disable a Project Web App permission

  1. On the Project Web App home page, in the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Security section, click Project Web App Permissions.

  3. On the Project Web App Permissions page, in the Available Project Web App Permissions list, clear the Enable check box next to the permission that you no longer want to make available to Project Web App users. (All Project Web App permissions are enabled by default.)

  4. Click Save.

    Note:

    Enabling a previously disabled permission is simply done by selecting the Enable check box next to the permission that has been disabled.

See Also

Concepts

Manage Project Web App permissions in Project Server 2010
Plan groups, categories, and RBS in Project Server 2010


Manage delegates (Project Server 2010 settings)
See Also

Published: April 14, 2011

Summary: Using delegation, one user can act as another user in every part of Project Web App, regardless of the permission level difference of one user compared to the other.

Microsoft Project Server 2010 enables user delegation throughout all of Microsoft Project Web App. This means that one user can act as another user in every part of Project Web App, regardless of the permission level difference of one user compared to the other.

Articles in this section include the following:

  • Turn user delegation on or off (Project Server 2010 settings)

  • Set up who can act as a delegate (Project Server 2010 settings)

  • Set up who can have delegates assigned to them (Project Server 2010 settings)

  • Create a new delegation (Project Server 2010 settings)

See Also

Concepts

Delete user delegates (Project Server 2010)

Other Resources

Act as a delegate (Project Server 2010)


Turn user delegation on or off (Project Server 2010 settings)
See Also

Published: January 27, 2011

Summary: Toggle delegation by using the Project Web App Permissions page in PWA Server Settings.

The user delegation feature in Microsoft Project Web App can be enabled or disabled globally, for all users and groups. When user delegation is turned on, you can set permissions to control the specific behavior of the feature in Project Web App.

To turn delegation on or off

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Security section, click Project Web App Permissions.

  3. In the Resource section, select the check box for the Manage Resource Delegates permission to turn on the user delegation feature within Project Web App.

  4. Choose any additional delegation permissions that meet your organization's needs:

    • Manage My Resource Delegations Select this check box to enable users to set up delegations for other users.

    • Manage My Delegations Select this check box to enable users to create delegations for themselves.

    • Can be Delegate Select this check box to enable a user to become a delegate for another user, after a delegation has been created.

  5. Click Save to save the permissions on the server.

See Also

Other Resources

Create a new delegation (Project Server 2010 settings)


Set up who can act as a delegate (Project Server 2010 settings)
See Also

Published: April 14, 2011

Summary: Enable delegation by setting properties on the Manage Users page (for single users) or Manage Groups page (for groups) in PWA Server Settings.

In Microsoft Project Web App, there are user- or group-level permissions that enable you to determine which users or groups can act as delegates for other people. By default, the only group that has these permissions turned on is the administrators group. Therefore, if you want users in your organization to be able to act as delegates, you have to set the appropriate permissions.

To set permissions for a specific user

  1. On the PWA home page, click Server Settings.

  2. In the Security section, click Manage Users.

  3. Click the name of the user for which you are setting permissions.

  4. On the Edit User page, expand the Global Permissions section.

  5. In the Global Permissions section, under Resource, choose the appropriate permissions for this user.

    • Can be Delegate Select the Allow check box for this permission to enable this user to become a delegate for another user.

    • Manage My Delegations Select the Allow check box for this permission to enable this user to create his or her own delegations.

    • Manage My Resource Delegations Select the Allow check box for this permission to enable this user to set up delegations for other users.

  6. Click Save to save the permissions on the server.

To set permissions for a group

  1. On the PWA home page, click Server Settings.

  2. In the Security section, click Manage Groups.

  3. Click the name of the group for which you are setting permissions.

  4. On the Add or Edit Group page, expand the Global Permissions section.

  5. In the Global Permissions section, under Resource, choose the appropriate permissions for this group.

    • Can be Delegate Select the Allow check box for this permission to enable members of this group to become delegates for other users.

    • Manage My Delegations Select the Allow check box for this permission to enable members of this group to create their own delegations.

    • Manage My Resource Delegations Select the Allow check box for this permission to enable members of this group to set up delegations for other users.

  6. Click Save to save the permissions on the server.

See Also

Concepts

Set up who can have delegates assigned to them (Project Server 2010 settings)


Set up who can have delegates assigned to them (Project Server 2010 settings)
See Also

Published: April 14, 2011

Summary: Specify who can have delegates do work on their behalf by using the Manage Categories page in PWA Server Settings.

Categories are used in Microsoft Project Web App to determine which users or groups can have delegates do work on their behalf. In order for a delegation to work correctly, the user requesting the delegation must have the correct category permissions, and the user who will act as the delegate must have the correct individual user or group permissions.

To set up who can have delegates assigned to them

  1. On the PWA home page, click Server Settings.

  2. In the Security section, click Manage Categories.

  3. Click the name of the category that contains the user or group for which you want to enable user delegation.

  4. In the Users and Groups section, click the name of group or a specific user in the Users and Groups with Permissions box.

  5. In the permissions box that appears, scroll down to the Resource section, and select the check box for the Manage Resource Delegates permission to turn on the user delegation feature for that user or group.

  6. Click Save to save the permissions on the server.

See Also

Concepts

Set up who can act as a delegate (Project Server 2010 settings)


Create a new delegation (Project Server 2010 settings)
See Also

Published: January 27, 2011

Summary: Add a new delegation by using the Manage Delegates page in PWA Server Settings.

Creating a new delegation in Microsoft Project Web App enables one user to work on behalf of another user, such as submitting a second user's timesheet.

To create a delegation

  1. On the PWA home page, click Server Settings.

  2. In the Security section, click Manage Delegates.

  3. On the interface ribbon, click New.

  4. In the Set Delegation Period section, select the date range for the period during which the delegate will be able to manage work.

  5. In the Set Delegation section, select the delegate that you want to manage work during the specified period.

  6. In the Working on Behalf of section, select the user who requires a substitute.

  7. Click Save to save the permissions on the server.

See Also

Other Resources

Turn user delegation on or off (Project Server 2010 settings)


Manage security group synchronization with Active Directory in Project Server 2010
See Also

Published: March 24, 2011

Summary: User security access in PWA can be managed automatically by associating a PWA security group with an Active Directory group.

This article describes security group synchronization scenarios, how to configure security group synchronization with Active Directory, and security group synchronization with users in a different domain.

Microsoft Project Server 2010 security group synchronization controls Project Server security group membership by automatically adding and removing users from specified Project Server security groups based on group membership in the Active Directory directory service. Each Project Server security group can be mapped to a single Active Directory group. However, this Active Directory group can contain nested groups whose members will also be synchronized.

The following actions can occur during a Project Server security group synchronization process:

  • A new Project Server user account can be created based on an Active Directory account.

  • An existing Project Server user can be removed from a Project Server security group.

  • An existing Project Server user can be added to a Project Server security group.

  • An existing Project Server user account's metadata (name, e-mail address, and so on) can be updated if it has changed in Active Directory.

  • A previously inactive Project Server user account can be reactivated.

Before you perform this procedure, confirm the following:

  • The account with which you are accessing Project Server through Project Web Access (PWA) has both the Manage Active Directory Settings and the Manage users and groups global permissions enabled.

  • The Service Application service account for the Project Server instance has Read access to all Active Directory groups and user accounts involved in the synchronization. You can verify this account on the Service Application page on the SharePoint Central Administration Web site.

Scenarios for security group synchronization in Project Server

The following are possible scenarios and corresponding actions that occur when security group synchronization takes place:

Scenario | Action
The user exists in Active Directory and is a member of the Active Directory group mapped to the current Project Server security group. The user does not exist in Project Server. | A new corresponding user account is created in Project Server and is granted membership to the current Project Server security group.
The user is not a member of the Active Directory group mapped to the current Project Server security group. The user also exists in Project Server and is a member of the current Project Server security group. | The existing Project Server user is removed as a member of the current Project Server security group.
The user exists in Active Directory and is a member of the Active Directory group mapped to the current Project Server security group. The user also exists in Project Server, but is not a member of the current Project Server security group. | The existing Project Server user is given membership to the current Project Server security group.
The user exists in Active Directory and is a member of the Active Directory group mapped to the current Project Server security group. The user also exists in Project Server and is a member of the current Project Server security group. User information has been updated in Active Directory. | The corresponding Project Server user information is updated (if applicable).
The user exists in Active Directory and is a member of the Active Directory group mapped to the current Project Server security group. The user also exists in Project Server, but as an inactive account. | If the Automatically reactivate currently inactive users if found in Active Directory during synchronization option is selected in Project Server, the account is reactivated and is added to the current Project Server security group. If the option is not selected, the account remains inactive in Project Server.

Configure security group synchronization

You can use this procedure to configure security group synchronization with Active Directory in Project Server 2010.

To configure security group synchronization

  1. On the Project Web App Server Settings page, in the Security section, click Manage Groups.

  2. On the Manage Groups page, in the Group Name column, click the name of the security group that you want to synchronize.

  3. On the Add or Edit page for the group that you selected, in the Group Information section, for Active Directory Group to Synchronize, click Find Group.

  4. On the Find Group in Active Directory page, in the Group Name field, enter all or part of the name of the Active Directory group that you want to synchronize with your security group. Click the button next to the Group Name field to search the Active Directory forest based on your search criteria.

    To select a group from a remote forest, type the fully qualified domain name of the group (for example, group@corp.contoso.com). You can synchronize to a security or distribution group of any scope (Local, Global, or Universal).

    Note:

    The Active Directory forest that is search is displayed at the top of the Find Group in the Active Directory page. The forest is defined by the fully qualified domain name of the account for the Service Application on which the Project Server instance is running.

  5. From the Group Name list, select the group with which you want to synchronize your Project Server security group. Click OK.

  6. On the Add or Edit Group page, you should see the Active Directory group that you selected in the Group Information section next to Active Directory Group to Synchronize. Click Save.

  7. On the Manage Groups page, in the Group Name column, select the check box next to the security group that you just configured for synchronization. Then click Active Directory Sync Options.

  8. If you want synchronization to occur on a scheduled basis, on the Synchronize Project Server Groups with Active Directory page, in the Scheduling section, select Schedule Synchronization. Or, you can choose to manually run the security group synchronization. If you prefer the manual option, go to step 10.

  9. In the Frequency fields, define the frequency at which you want synchronization to occur between the Project Server security group and the Active Directory group. This can be scheduled over a defined period of days, weeks, or months. Select a start date and time.

  10. You can enable inactive user accounts to be reactivated if they are found in the Active Directory group during synchronization. To do so, in the Options section, select Automatically reactivate currently inactive users if found in Active Directory during synchronization. (For example, if you enabled this option, it would ensure that if an employee were rehired, the employee's user account would be reactivated.)

  11. Click Save to save the settings. Click Save and Synchronize Now if you want to synchronize your Project Server security group immediately. If you decide not to schedule the synchronization, you can rerun it manually when you have to by returning to this page and clicking Save and Synchronize Now.

  12. You can check the status of the security group synchronization by returning to the Synchronize Project Server Groups with Active Directory page for the specific security group and reviewing the information in the Status section. It contains information such as when the last successful synchronization occurred.

Synchronizing security groups across domains requires a two-way trust relationship

Imagine that you need to synchronize Project Server 2010 security groups with Active Directory users that exist in a domain other than the one that Project Server 2010 is installed on. For example, your organization may acquire a new company, or your branch may need to add users from a different branch within your organization. In this scenario, a two-way trust relationship must exist between the domains in order for Active Directory users in one domain to synchronize with security groups in a Project Server 2010 installation that exists on a different domain.

Note:

Project Server 2010 does not support synchronizing security groups or the Enterprise Resource Pool with Active Directory users across different domains in which only a one-way trust relationship exists between domains. It is possible for an Active Directory user to synchronize with SharePoint Server 2010 in a cross-forest deployment in which a one-way trust relationship exists between domains (see Resolve accounts across multiple forests (SharePoint Server 2010). However, Project Server 2010 does not support this scenario.

For more information about trust relationships in Windows Server 2008 and Windows Server 2008 R2, see Managing Trusts. For information about creating a two-way trust relationship between domains in Windows Server 2008 or Windows Server 2008 R2, see Create an External Trust.

See Also

Concepts

Test background operations (Project Server 2010)
Active Directory Resource Pool Synchronization (Project Server 2010 settings)
Manage security templates in Project Server 2010
Project Server 2010 Administrator's Guide


Enterprise Data (Project Server 2010 settings)

Published: January 27, 2011

The Microsoft Project Server 2010 Enterprise Data administration section contains the following articles:

  • Enterprise Custom Fields and Lookup Tables (Project Server 2010)

  • Enterprise Global (Project Server 2010 settings)

  • Enterprise Calendars (Project Server 2010 settings)

  • Resource Center (Project Server 2010 settings)


Enterprise Custom Fields and Lookup Tables (Project Server 2010)
See Also

Published: March 17, 2011

In Microsoft Project Server 2010, you can use Enterprise Custom Fields to help establish consistency across all the organization's projects. That way that you can ensure that fields and associated lookup tables are used in the same manner for all projects, tasks, resources, and assignments.

Enterprise Custom Fields can include custom formulas and can use lookup tables and graphical indicators. By using Enterprise Custom Fields effectively, you can help customize Microsoft Project Server 2010 to fit the unique needs of your organization. When you use Enterprise Custom Fields, all users in your organization have access to a standard set of fields, which enables operations to be applied in the same manner across whole sets of projects. For example:

  • You can customize project management to reflect your organization's structure and processes. All users in your organization can have access to a standard set of fields, which enables the same operations to be completed across whole sets of projects.

  • You can set Enterprise Custom Fields as required fields so that users are prompted to enter information in that field before they save.

  • You can use Enterprise Custom Fields on a per-department basis.

Because creating Enterprise Custom Fields can range from being easy to being very complex and labor-intensive, it is important to correctly design your Enterprise Custom Fields. To determine the scope of Enterprise Custom Fields that your organization requires, consider the following questions:

  • What words or phrases are used by stakeholders in your organization, such as return on investment (ROI), Key Performance Indicator (KPI), and so on? You might want to quantify and codify these concepts by using Enterprise Custom Fields. Also consider the concepts behind the common words and phrases used by stakeholders in your organization.

  • What are the user requirements in your organization? User requirements are frequently based on reporting requirements.

  • How will you sort and select data? How will you use graphical indicators?

Enterprise Custom Fields

You can create Enterprise Custom Fields at the task, project, and resource level. It is important to determine which specific Enterprise Custom Fields your organization needs when you review your business requirements while planning your Project Server 2010 deployment. It is best to do this after you have performed a gap analysis by comparing the capabilities of Project Server 2010 against the business needs of your organization.

For example, a group of executives in an organization wants to be able to view project data by department. In order to achieve this business requirement, they have to define a consistent method for identifying departments within the organization. In addition, if each department has a different accounting method or funding process, the executives might have to determine a method for defining this, also. You can use the Project Departments or Resource Departments custom fields together with the Department custom lookup table, or any enterprise custom field that has the Department property set to do this.

The most important use for Enterprise Custom Fields is to enable organizations to enforce consistency across all projects. For example, if two project managers use different fields to specify a resource's location, then users will be unable to determine when the same resource is assigned to projects managed by each project manager.

Enterprise Custom Lookup Tables

Consider using custom lookup tables for any Enterprise Custom Field for which standardization of data is the most important factor. For example, it might not be a good practice to let users enter any integer value in a custom Status field. One project manager might enter Started, and another might enter In-Progress, both indicating that the project has begun and is underway. Without using lookup tables, it is difficult to standardize terminology in your organization.

For example, you might create a custom text field that is associated with Resources. To do this, you click the Resource option, select Text from the list, and rename it Manager. If you do not specify a lookup table for this custom text field, a user could enter any text value in the Manager field.

See Also

Concepts

Add or edit an Enterprise Custom Field (Project Server 2010)
Add or edit an Enterprise Custom Lookup Table (Project Server 2010)


Add or edit an Enterprise Custom Field (Project Server 2010)

Published: March 17, 2011

The New Custom Field page in Microsoft Project Server 2010 lets you specify the options for a custom field. Use the following procedure to create a new enterprise custom field or edit an existing one.

To create or edit Enterprise Custom Fields

  1. On the PWA Server Settings page, click Enterprise Custom fields and Lookup Tables.

  2. In the Enterprise Custom Fields section, click the field that you want to edit, or click New Field to create a new field.

  3. Fill out the Custom Field page by specifying the custom field options that you want to use. See the descriptions for each field in the following sections.

  4. Click Save.

Name and Description

Use the Name and Description areas to specify a name and description for the custom field. The following table describes the name and description fields.

Attribute | Description
Name | The name of the custom field.
Description | A description of the custom field.

Entity and Type

Use the Entity and Type areas to specify whether you want a Project, Resource, or Task custom field, and what data type the field should be.

The following table describes each available entity.

Attribute | Description
Project | Select to create Enterprise Custom Fields that are applied at the project level.
Resource | Select to create Enterprise Custom Fields that are applied at the resource level.
Task | Select to create Enterprise Custom Fields that are applied at the task level.

The Type selection defines the data type of the custom field. The value that you choose here affects which options are available in the Custom Attributes, Calculation for Summary Rows, and Behavior sections. The following table describes the available custom field types.

Attribute | Description
Cost | Use custom cost fields to define currency data. For example, you can use a custom cost field to define a project's Approved Budget.
Date | Use custom date fields to specify date-driven data. For example, you can create an Enterprise Custom Field called Project Approval Date and use it to record the date on which a project is approved.
Duration | Use custom duration fields to define a duration. These are frequently defined as calculations that use custom formulas. For example, a custom duration field can enable your organization to define a way for a project manager to show and store the difference between a project's original schedule and the actual schedule.
Flag | Use custom flag fields to define anything that can have only two choices for defining the data. For example, you might use a flag field to determine whether to display a field or to enable a macro that controls whether a particular set of data is available in the project.
Number | Use custom number fields to define any numeric set of data or to perform a custom calculation by using a custom formula. For example, you might use a task-level field to record the estimated lines of code in a software development project or to compare a project's actual cost to its proposed cost.
Text | Use custom text fields to define simple, non-hierarchical, alphanumeric data. For example, you can create a custom text field that is named Project Status that includes options such as Initiated, Approved, In-Progress, Suspended, Cancelled, and Closed.

Custom attributes

When you select a Project Text custom field, you have the option of specifying one or multiple lines of text for the custom field.

The following table describes the custom text options.

Attribute | Description
Single line of text | Select if you want the custom field to be a single line of text. This option is available only for Project Text fields.
Multiple lines of text | Select if you want the custom field to be multiple lines of text. This option is available only for Project Text fields. The project field created by using this option is not visible in the project information tab in Microsoft Project Professional. However, this field can be exposed by using a Web-based Project Detail Page.

You can choose to have a custom lookup table supply the values for a custom field. This lets you control the values selected for the custom field. You can do the following:

  • Choose whether to have a default value if no other value is selected

  • Choose whether to allow multiple values to be selected from the lookup table

  • Choose to restrict available values to those values in the table that have no subordinates

The lookup table option is available when you have selected Text as the field type.

The following table describes the lookup table options for custom fields.

Attribute | Description
Lookup Table | The name of the Enterprise Custom Lookup Table that you want to associate with this custom field. Once you have associated a lookup table with a field and have saved it, you cannot remove the lookup table relationship. Therefore, make sure that you need the lookup table before you make this association.
Choose a value to use as a default when adding new items | If you want to have a default value included in this custom field in cases where the user does not specify one, select this check box, and then select the default value.
Default value | The default value to be used in this field when users do not specify a value. To set the value, click the browse button and select the desired value.
Only allow codes with no subordinate values | Select this option if you want to allow only values in the lookup table that have no subordinate values (that is, values at the lowest level of each branch).
Allow multiple values to be selected from lookup table | Select this option if you want to allow users to select more than one value from the lookup table. Once this selection has been made and saved, it cannot be removed.
Note:

If you plan to create a custom field that refers to a lookup table, create the lookup table before creating the custom field.

You can use formulas to define your own parameters for how your Enterprise Custom Fields measure data or present information when they are used in a project. Formulas cannot be used with all types of Enterprise Custom Fields.

The formula option is available with all field types.

Note:

Once a formula is associated with a custom field, it can be edited but it cannot be removed.

  • To use a known formula, type the formula in the Edit formula box.

  • To add a field to the formula, click Pick field, point to a field type, and then click the name of the field that you want to reference. To reference an existing Enterprise Custom Field, point to a field type, point again to a custom field type (such as Custom Date or Custom Finish), and then click the Enterprise Custom Field that you want.

  • To use a function in the formula, click Pick function, click a function type, and then click the function that you want. Each function includes placeholder arguments that you can replace with the fields and values that you want to use.

  • To build a formula by using a standard set of operators, click Pick operator and choose the operator that you need. The formula can operate by using referenced fields, functions, or literal data.

The following table describes the formula options.

Attribute | Description
Enter formula | The formula you want to use.
Insert field | Inserts a field (cost, date, duration, flag, number, or text) into the formula.
Insert function | Inserts a function (conversion, date/time, general, math, Microsoft Project, or text) into the formula.
Insert operator | Inserts an operator (mathematical or Boolean) into the formula.

Department

You can select a department to be associated with a custom field. Selecting a department allows you to limit a user's ability to see the custom field if that person is not a member of that department. If you do not specify a department, then all users are able to see the custom field.

The values available for Department are specified in the Department custom lookup table.

Calculation for summary rows

For entity types of Resource and Task, you can select options for the calculation of summary rows.

Note that summary row calculation is not available with a field type of Text.

The following table describes the options for summary task calculation.

Attribute | Description
None | Choose None if you do not want the custom field to be applied to summary and group summary rows.
Rollup | Choose Rollup to roll up the individual rows for the summary row.
Use formula | Choose Use formula to use a specific formula to calculate the summary row. You must specify the formula to use under Custom Attributes.

Calculation for assignment rows

For resource types of Resource and Task, you choose to use a roll down calculation for assignment rows.

The following table describes the options for calculating assignment rows.

Attribute | Description
None | Choose None if you do not want to roll down assignment rows.
Roll down, unless manually specified | Choose Roll down if you want data that is entered at the task or resource level to be rolled down and copied to each assignment with the same value.

Values to display

You can choose to display raw data or to have the data represented graphically.

If you select Graphical indicators, you can select different criteria for Non-summary rows, Summary rows, and, if you are using an entity type of Project, Project summary.

When you select an option, further configurable parameters specific to that option are displayed.

The following table describes the options for graphical indicators.

Attribute | Description
Non-summary rows | Choose Non-summary rows to specify criteria for graphical representation of data rows that are not summary rows.
Summary rows | Choose Summary rows to specify criteria for graphical representation of summary rows.
Project summary | Choose Project summary to specify criteria for graphical representation of the project summary.

When you configure graphical indicators, you can specify the exact value and comparison parameters that determine when a particular graphic is used. The available comparison (test) parameters are as follows:

  • Equals

  • Does not equal

  • Is greater than

  • Is greater than or equal to

  • Is less than

  • Is less than or equal to

  • Is within

  • Is not within

  • Contains

  • Does not contain

  • Contains exactly

  • Is any value

These are used to compare the data value with a threshold value that you specify to determine which graphic to display. For example, you can configure values greater than or equal to 50 to display a green indicator and values less than 50 to display a red indicator.

You can specify as many images for different values as required. Add a new row to the table for each test/value comparison. Rows in the table are evaluated from top to bottom and the image associated with the first row where the test/value combination is true is displayed.

The following table describes the graphical indicator options for non-summary rows.

Attribute | Description
Test | Choose the operator (equals, less than, and so on) to apply to the field value to determine the image to use.
Values | Type the field value or a field reference (for example, [cost]) that, combined with the operator in the test column, determines when to use the image in the Image column.
Images | Choose the image to display when the test/value combination is true.
Move | Use the move buttons to move a row up or down in the table.
Show data values in ToolTips | Select this attribute to show the field value in the tool tip associated with the image.

When you use graphical indicators for summary rows, you can choose to inherit the graphical indicator settings that you have defined for non-summary rows.

If you select the Inherit criteria from non-summary rows check box when you configure graphical indicators for summary rows, the graphical indicator parameters that you configured for the non-summary rows are used.

If you select the Inherit criteria from summary rows check box when you configure graphical indicators for project summary, the graphical indicator parameters that you configured for the summary rows will be used.

Behavior

You can configure a custom field to be controlled by workflow or to require a value.

If you choose to have the custom field controlled by a workflow, the required field option is not available because that behavior is controlled by workflow.

The following table describes the options for configuring custom field behavior.

Attribute | Description
Behavior controlled by workflow | Select this check box if you want the custom field behavior to be controlled by workflow.
Require that this field has information | Choose whether you want this to be a required field (that is, the field cannot be left blank). This option is not available if the Behavior controlled by workflow option is selected.


Add or edit an Enterprise Custom Lookup Table (Project Server 2010)

Published: March 17, 2011

The New Lookup table page in Microsoft Project Server 2010 lets you specify the options for a custom lookup table. Use the following procedure to create or edit an enterprise custom lookup table.

To create or edit Enterprise Custom Lookup Tables

  1. On the PWA Server Settings page, click Enterprise Custom fields and Lookup Tables.

  2. Under Lookup Tables for Custom Fields, click New Lookup Table to create a new lookup table, or click the lookup table that you want to edit.

  3. For a new table, type a name for the lookup table in the Name box.

  4. Fill out the Custom Lookup Table page by specifying the options that you want to use. See the descriptions for each field in the following sections.

  5. Click Save.

Type

For a new lookup table, you must specify a data type for the table. It is not possible to mix field types in a table.

The following table describes the options for data types in a custom lookup table.

Attribute | Description
Cost | Each field in the table is a cost value.
Date | Each field in the table is a date value.
Duration | Each value in the table is treated as a duration.
Number | Each value in the table is a number.
Text | Each value in the table is text. Choosing Text also allows a hierarchy of values to be specified if you want.

Code mask

The code mask option only appears when a field type of Text has been selected.

The code mask lets you specify what types of text characters appear in the lookup table, the length of the string, and what characters to use to separate levels in a hierarchy. If you are creating a hierarchical lookup table, you must specify a code mask for each level of the hierarchy.

The following table describes the options available for configuring code masks.

Attribute | Description
Code preview | Displays a preview of the code mask for the table.
Sequence | Specify the type of text characters to allow. Choose Numbers, Uppercase characters, Lowercase characters, or Characters.
Length | Specify the maximum length of the string. Choose a number from 1 to 255 or Any.
Separator | Specify from one to three characters to use as a separator between levels of the table hierarchy.

Lookup Table

Use the Lookup Table section of the New Lookup table page to specify the values in the lookup table.

Note:

If you are having difficulty editing the grid, make sure that you have applied the latest updates for Internet Explorer 9 on your workstation.

Type each value that you want in the lookup table in the Value column. Create as many rows as needed to accommodate the values that you want to include. Optionally, include a description for the value in the Description column.

The following table describes the options for creating lookup table values.

Attribute | Description
Level | Denotes the level in the hierarchy. This is a read-only field. Select the row and use the Indent and Outdent buttons to change levels.
Value | Specify the value of the field.
Description | Describes what the field represents. (Optional)
Move | Use the Move buttons to change the position of rows in the table. Select a row and then click the Up or Down Move button to move a row.
Display order for lookup table | Specifies how to sort the lookup table. If you select By row number, the table remains sorted as you specify it. If you choose to sort ascending or descending, the table is sorted based on the values in the Value column.


Enterprise Global (Project Server 2010 settings)

Published: April 14, 2011

The Enterprise Global setting enables you to change the Enterprise Global file in Microsoft Project Professional 2010.

The Enterprise Global file contains all custom enterprise objects that are available to users (for example, views, tables, groups, filters, and reports). When a Project Professional 2010 user connects to Microsoft Project Server 2010, the latest version of the Enterprise Global file is loaded and cached on the client computer. This lets the user access all enterprise custom objects available on the server.

Through the Enterprise Global file, you are able to enforce standards in your organization that can be applied to all project and resources that work with Project Server data. By using views, tables, filters, and other related elements contains in the Enterprise Global file, you can help ensure effective standardization in your organization.

Decisions about what to include in the Enterprise Global file should be made at an organizational level. You should contact your Project Management Office (PMO) before you make any significant changes to the Enterprise Global file.

Note:

To be able to modify the Enterprise Global file, you must have the Save Enterprise Global permission in Project Server 2010.

To open the Enterprise Global file through the Enterprise Global setting

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Enterprise Data section, click Configure Project Professional.

    Project Professional 2010 opens the Enterprise Global file. The name of the project in the title bar is "Checked-out Enterprise Global."

  3. Make changes to your custom objects through your Enterprise Global file.

  4. After you have completed your changes, click File, and then click Save.

  5. After save has completed successfully, click File, and then click Close.

    A dialog box is displayed to ask whether you want to check-in the Enterprise Global file.

  6. Click Yes.

    Note:

    If users have Project Professional 2010 open when an updated Enterprise Global file is checked in to the server, the changes in the updated Enterprise Global file will not be available until Project Professional 2010 is closed and reopened.

Important:

Make sure not to add into the Enterprise Global file any view, table, filter, grouping, reports, and so on that has the same name as an element that exists natively in Project Professional 2010. Verify that you give any new enterprise-wide elements a unique name that does not conflict.


Enterprise Calendars (Project Server 2010 settings)

Published: March 31, 2011

Enterprise calendars capture the predefined working hours, holidays, and other schedule details in an organization. They are used to standardize the working time for all of an organization's projects. In Microsoft Project Web App, you can view a list of existing calendars, select a calendar to edit, or start the process of creating a new calendar. However, to create or modify a calendar, you must have Microsoft Project Professional 2010 installed on the computer that you are using to access Project Web App.

Articles in this section include the following:

  • Create a new calendar (Project Server 2010 settings)

  • Copy an existing calendar (Project Server 2010 settings)

  • Edit an existing calendar (Project Server 2010 settings)

  • Delete a calendar (Project Server 2010 settings)

  • Modify working and nonworking times (Project Server 2010 settings)


Create a new calendar (Project Server 2010 settings)

Published: January 27, 2011

By default, Microsoft Project Server 2010 uses a standard enterprise calendar for scheduling. Some organizations may use multiple calendars. For example, if some of your organization's employees work in another country, those workers will likely observe different holidays, and so will need a different enterprise calendar for scheduling project work. You can create a new, blank enterprise calendar by using Microsoft Project Web App and Microsoft Project Professional 2010.

To create a new, blank enterprise calendar

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Enterprise Data section, click Enterprise Calendars.

  3. On the Enterprise Calendars page, click New Calendar.

  4. On the Windows Security dialog box, type your user name and password to connect to Project Server 2010 through Project Professional 2010, and then click OK.

    Note:

    If you are using Integrated Windows authentication and your Internet Explorer settings are set to automatically log you on, or if Project Professional 2010 is already connected to the server that is using the correct profile, then you will not be prompted for credentials.

    Project Professional 2010 opens and displays the Change Working Time dialog box.

  5. Type a name for the new calendar in the For calendar box.

  6. Use the calendar along with the Exceptions and Work Weeks tabs to modify the working and nonworking times for your organization. For more information, see Modify working and nonworking times (Project Server 2010 settings).

  7. Click OK on the Change Working Time dialog box to save the new calendar to Project Server 2010.

  8. Close Project Professional 2010.


Copy an existing calendar (Project Server 2010 settings)

Published: March 31, 2011

If an existing calendar has many of the same holidays and other calendar items that you want to use in a new calendar, you can base a new calendar on an existing calendar. Copy the existing calendar in Microsoft Project Web App, and then modify the copy in Microsoft Project Professional 2010. For example, if the standard calendar in your organization captures all of the organization's unique holidays and events, but you need a separate calendar to reflect an all day, every day working schedule, you can copy the standard calendar and then modify it for the all day, every day schedule.

To create a new calendar as a copy of an existing calendar

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Enterprise Data section, click Enterprise Calendars.

  3. Click the row that contains the calendar that you want to copy, and then click Copy Calendar.

  4. On the Copy Calendar dialog box, type the name that you want to use for the new calendar in the Name box, and then click OK.

    The calendar is added to the list on the Enterprise Calendars page.

  5. Click the row that contains the new, copied calendar, and then click Edit Calendar.

    If the Windows Security dialog box appears, log on to Microsoft Project Server.

    Project Professional 2010 opens and displays the Change Working Time dialog box.

  6. Use the calendar with the Exceptions and Work Weeks tabs to modify the working and nonworking times for your organization. For more information, see Modify working and nonworking times (Project Server 2010 settings).

  7. Click OK on the Change Working Time dialog box to save the new calendar to Project Server.

  8. Close Project Professional 2010.


Edit an existing calendar (Project Server 2010 settings)

Published: April 14, 2011

As you are configuring Microsoft Project Server 2010 for the first time, you can modify the default standard enterprise calendar to account for the working and nonworking times observed by your organization. You can modify any enterprise calendar at any time by selecting the calendar in Microsoft Project Web App, and making changes in Microsoft Project Professional 2010.

To modify an existing enterprise calendar

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Enterprise Data section, click Enterprise Calendars.

  3. Click the row that contains the calendar that you want to change, and then click Edit Calendar.

    If the Windows Security dialog box appears, log on to Project Server 2010.

    Project Professional 2010 opens and displays the Change Working Time dialog box.

  4. Use the calendar with the Exceptions and Work Weeks tabs to modify the working and nonworking times for your organization.

    For more information, see Modify working and nonworking times (Project Server 2010 settings).

  5. Click OK on the Change Working Time dialog box to save the new calendar to Project Server 2010.

  6. Close Project Professional 2010.


Delete a calendar (Project Server 2010 settings)

Published: March 31, 2011

If you find that your organization is not using a specific enterprise calendar, you can easily delete it in Microsoft Project Web App.

To delete an enterprise calendar

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Enterprise Data section, click Enterprise Calendars.

  3. Click the row that contains the calendar that you want to delete, and then click Delete Calendar.

  4. When prompted, click OK to delete the selected calendar.

    Note:

    If the calendar is currently being used, a notification appears.


Modify working and nonworking times (Project Server 2010 settings)

Published: March 31, 2011

When you are working with calendars in Microsoft Project Professional 2010, there are some different things that you can do to accurately account for working and nonworking time in your organization. The following sections provide examples for each kind of change and show you the steps that you must follow to make each change.

Note:

Steps in this article assume that you are already creating or editing a calendar. For more information about how to create a calendar, see Create a new calendar (Project Server 2010 settings) or Copy an existing calendar (Project Server 2010 settings). For more information about how to edit a calendar, see Edit an existing calendar (Project Server 2010 settings).

Change a working day into a nonworking day

Occasionally, you may have to turn a working day into a nonworking day. For example, if your organization observes specific days as holidays, you can turn those holidays into nonworking days. Microsoft Project Server will not schedule work on nonworking days.

To change a working day into a nonworking day

  1. Click the date on the calendar that you want to convert into a nonworking day.

  2. On the Exceptions tab, type a name for the nonworking day in the Name column. The Start and Finish columns are automatically populated with the date that you clicked in Step 1.

    Note:

    Although you can create multiple exceptions that contain a specific day, only the lowest-level exception will apply on that day. For example, you might have one exception that changes the standard working times for a month, and another exception that calls out a specific day within that month as a nonworking day. Because the single-day exception is at a lower level than the month-long exception, the single nonworking day exception is applied on that day. You cannot create multiple single-day exceptions on the same day.

Change a nonworking day into a working day

There may be times when your organization has to work on what would otherwise be a nonworking day. For example, say your organization participates in a convention each year that occurs over a weekend. You can convert weekend days of the convention into working days, so that Project Server knows to schedule work on those days.

To change a nonworking day into a working day

  1. Click the date on the calendar that you want to turn into a working day.

  2. On the Exceptions tab, type a name for the working day in the Name column, and then press Enter.

    Note:

    While you can create multiple exceptions that contain a specific day, only the lowest-level exception applies on that day. For example, you might have one exception that changes the standard working times for a month, and another exception that calls out a specific day within that month as a nonworking day. Because the single-day exception is at a lower level than the month-long exception, the single nonworking day exception is applied on that day. You cannot create multiple single-day exceptions on the same day.

  3. Click the row that you added for the working day, and then click Details.

  4. In the Set working times for these exceptions section, click Working times, and then set the working times for that day by adjusting the times in the From and To columns.

  5. If your organization observes these working times on a regular basis (for example, once a month or once a year), under Recurrence pattern, choose whether these times should recur Daily, Weekly, Monthly, or Yearly, and then set the following options:

    • Daily Set the frequency for these working times. For example, every 10 days.

      Tip:

      If you find that the working day exception is happening very frequently, you may find it easier to change the default calendar options under Schedule on the Project Options dialog box in Project Professional 2010. All calendars begin with these default days and times. It may be easier to change the default calendar options than to set up exceptions that recur frequently.

    • Weekly Specify how often you want the working times to recur, and on what day of the week you want them to recur. For example, every two weeks on Saturday.

    • Monthly Choose what day of the month and at what monthly frequency you want the working times to recur. For example, day 15 of every third month, or the third Saturday of every sixth month.

    • Yearly Choose on which day of the year you want the working times to recur. For example, August 21, or the third Saturday of July.

  6. In the Range of recurrence section, specify the period when you want the recurrence to take place, if appropriate.

    • Start Choose the date when you want the recurrence pattern to begin.

    • End after If you want the recurrence to happen only a set number of times, choose End after, and then type the number of instances when the working times should occur.

    • End by If you want the recurrence to happen only during a certain time period, choose End by, and then choose when the recurrence should stop.

  7. Click OK.

Change the working times for a working day

While the specific days on the calendar may be accurately accounted for as working and nonworking, there may be working days that use a different time schedule than the typical 8-hour work day. You can adjust the working times for a specific working day so that work is accurately scheduled on that day.

To change the working times for a working day

  1. Click the date on the calendar for the working day that you want to adjust.

  2. On the Exceptions tab, type a name for the changed working day in the Name column, and then press Enter.

    Note:

    While you can create multiple exceptions that contain a specific day, only the lowest-level exception applies on that day. For example, you might have one exception that changes the standard working times for a month, and another exception that calls out a specific day within that month as a nonworking day. Because the single-day exception is at a lower level than the month-long exception, the single nonworking day exception is applied on that day. You cannot create multiple single-day exceptions on the same day.

  3. Click the row that you added for the changed working day, and then click Details.

  4. Under Set working times for these exceptions, click Working times, and then set the working times for that day by adjusting the times in the From and To columns.

  5. If your organization observes these working times on a regular basis (for example, once a month or once a year), under Recurrence pattern, choose whether these times should recur Daily, Weekly, Monthly, or Yearly, and then set the following options:

    • Daily Set the frequency for these working times. For example, every 10 days.

    • Weekly Specify how often you want the working times to recur, and on what day of the week you want them to recur. For example, every two weeks on Saturday.

    • Monthly Choose what day of the month and at what monthly frequency you want the working times to recur. For example, day 15 of every third month, or the third Saturday of every sixth month.

    • Yearly Choose what day of the year you want the working times to recur. For example, August 21, or the third Saturday of July.

  6. In the Range of recurrence section, specify the period when you want the recurrence to take place, if appropriate.

    • Start Choose the date when you want the recurrence pattern to begin.

    • End after If you want the recurrence to happen only a set number of times, choose End after, and then type the number of instances when the working times should occur.

    • End by If you want the recurrence to happen only during a certain time period, choose End by, and then choose when the recurrence should stop.

  7. Click OK.

Change the working times for each day of a work week

If your organization has a specific work week (or set of work weeks) when the working times are different from the default, you can make those changes to the working times for each day in a work week, during a set period of time. For example, if your organization does not use the default Monday through Friday, 08:00 to 17:00 schedule, you can change the working times for each day in the work week to reflect your organization's accurate schedule.

To change the working times for each day of a work week

  1. Click the date on the calendar where you want the changed working times to begin.

  2. On the Work Weeks tab, type a name for the changed work week or weeks in the Name column, and then press Enter.

  3. Change the date in the Finish column for the row that you just added, to reflect the last day that you want to include in the changed work week or weeks.

  4. Click Details.

  5. In the Select day(s) section, click the day of the week that you want to use adjusted working times. Press Ctrl and click, or press Shift and click to select multiple days.

  6. If you want to turn the selected day or days into nonworking time, click Set days to nonworking time.

  7. If you want to change the working times for the selected day or days, click Set day(s) to these specific working times, and then set the working times by typing in the From and To columns.

  8. Click OK.


Resource Center (Project Server 2010 settings)

Published: April 14, 2011

The Resource Center is a view in Microsoft Project Web App that can be used to create new resources and modify existing resources. It can be accessed from the Server Settings page.

Tip:

Depending on how your organization has Project Web App configured, you may also be able to access the Resource Center from the Quick Launch.

Articles in this section include the following:

  • Create a new resource (Project Server 2010 settings)

  • Edit an existing resource (Project Server 2010 settings)


Create a new resource (Project Server 2010 settings)

Published: April 7, 2011

When you create a new user in Microsoft Project Server 2010, you can choose to also make that user a resource. However, sometimes you may want to create a resource that cannot log on to Project Server. For example, you may want to add a material resource, such as a conference room, that has no need to be able to log on to Project Server. Project managers can still assign the resource to work. But if there is no work to track, and the project manager can account for when the resource is actually used, there is no need for that resource to also be a user.

To create a new resource:

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Enterprise Data section, click Resource Center.

  3. On the Resources tab, in the Editing group, click New Resource.

  4. In the Type section, complete the following:

    • Type Choose whether you are creating a Work, Material, or Cost resource.

    • Budget If the resource is a budget resource, select the Budget check box.

    • Generic If the resource is generic, meaning that you will use it for planning and replace it with at least one named resource further in the planning process, select the Generic check box.

  5. In the Identification Information section, complete the following:

    • Resource can logon to Project Server Select this check box if you want the resource to also be a Microsoft Project Web App user.

    • Display Name Type the resource's name in this box. This field is required.

    • E-mail address If this resource has an e-mail address that he or she wants associated with project work, type the address in this box.

    • RBS If your organization uses a resource breakdown structure (RBS), click the button next to this field and select the appropriate RBS code for this resource from the list.

    • Initials This field is automatically populated with the resource's initials, based on the name typed in the Display Name box. If you want to use different initials to refer to this resource, type them in the Initials box.

    • Hyperlink Name If this resource has an associated Web site, type the name of that site in this box.

    • Hyperlink URL If this resource has an associated Web site, type the URL to that site in this box.

  6. In the Assignment Attributes section, complete the following:

    • Resource can be leveled If you want to enable project managers to balance this resource's workload based on his or her availability and assignments (leveling), select this check box.

    • Base Calendar Choose the calendar that most closely represents this resource's overall availability. For example, if your organization has a base calendar that accounts for specific holidays or events, you can set that as this resource's calendar, and work assigned to this resource will be scheduled around the calendar's nonworking days.

    • Default Booking Type Choose whether you want this resource to be Committed or Proposed when assigning work.

    • Timesheet manager Type the name of the person who approves or rejects this resource's timesheets, or click Browse to select the timesheet manager from a list. Resources may not have separate timesheet managers.

    • Default Assignment Owner Type the name of the person who approves or rejects this resource's task progress, or click Browse to select the assignment owner from a list. Resources may not have separate assignment owners. For example, if the resource is a conference room, and the project manager tracks how long that the conference room is used, the assignment owner may be the project manager.

      Tip:

      You can set the assignment owner within the project on an assignment-by-assignment basis.

    • Earliest Available Choose the date when the resource becomes available to assign to tasks, if it is appropriate. If the resource does not have a set period of availability (that is, if he or she is always available), leave this setting blank.

      Note:

      The earliest and latest available dates correspond to the resource availability dates for a resource, as seen in Microsoft Project Professional.

    • Latest Available Choose the last date that the resource is available to work on tasks, if it is appropriate. If the resource does not have a set period of availability (that is, if he or she is always available), leave this blank.

    • Standard Rate Type the resource's standard pay rate in this box.

    • Overtime Rate Type the resource's overtime pay rate in this box.

    • Current Max. Units (%) Specify the maximum time period that a resource is available for work, as a percentage. For example, if the resource is available full-time, type 100%. If the resource is available half-time, type 50%.

    • Cost/Use If the resource has a flat fee associated with each use, type that cost in this box. For example, a van rental may require a flat fee up front, with an added standard cost per mile. The flat fee is its cost per use.

  7. In the Departments section, click the button next to the Resource Departments box, and select which department or departments the resource is associated with. If the resource is not associated with a particular department, leave this setting blank.

    Tip:

    Associating a resource with a department narrows what the resource sees when they use Project Web App. It can help the resource find what he or she is looking for more quickly, by removing things from other departments that do not apply to his or her work.

  8. If your organization created codes for grouping and costing purposes, in the Group Fields section, complete the following:

    • Group Type the name of the group in this box.

    • Code Type the code for the group in this box.

    • Cost Center Type the cost center code for the group in this box.

    • Cost Type Click the button next to the Cost Type field, and then select the type of cost associated with this group.

  9. In the Team Details section, click the button next to the Team Name box, and select which team the resource belongs to, if it is appropriate. If the resource will be managing and delegating tasks that are assigned to the team, select the Team Assignment Pool check box.

    Tip:

    Some organizations create a generic resource for each team so that tasks assigned to the team first go to the generic resource. This way, no single resource takes on the task assignment before it is appropriately delegated. If you choose to use a generic resource in this manner, set the assignment owner for the resource as the team manager, select the Team Assignment Pool check box, and select the team from the Team Name list.

  10. In the System Identification Data section, type additional identifying information for the user in the External ID box, if it is appropriate.

    For example, your organization's HR department may use employee ID numbers to track data in its HR systems. By providing that ID number in the External ID box, you identify an association between the resource that you are creating and the HR department's employee data. The External ID box can also be used to facilitate the consolidation of reporting of resource use beyond what Project Server provides.

    Tip:

    If you are not sure whether you should be capturing any data in the External ID box, check with other departments in your organization to find out whether it would be useful to connect resource data with other systems, or merely leave this box blank.

  11. Click Save to create the new resource.


Edit an existing resource (Project Server 2010 settings)

Published: April 7, 2011

Once a resource is added in Microsoft Project Web App, you may find that you have to change the resource's information. Perhaps the resource had a rate change, or has to use a different base calendar.

Edit a resource

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Enterprise Data section, click Resource Center.

  3. Select the check box in the left column for the row that contains the resource that you are editing.

    Tip:

    If your organization has lots of resources and you cannot easily find the one that you want to edit, you can filter the Resource Center. On the Resources tab, in the Data group, click Custom Filter in the Filter list. Identify the parameters for the resource that you are editing, and then click OK.

  4. On the Resources tab, in the Editing group, click Edit Resource.

  5. Make changes to the resource data, as needed, and then click Save.

Change multiple resources

In some cases, several resources may require the same change. For example, if several resources use the same timesheet manager, and that person takes a job elsewhere, you must replace the timesheet manager for those resources with whoever steps in as a replacement. Project Web App supports bulk editing of several resources at the same time. You can bulk edit the Timesheet manager, Default Assignment Owner, RBS, Team Name, Cost Type, and Resource Departments fields.

Tip:

Another good way to edit many resources at the same time is by using Microsoft Project Professional 2010. By making changes through Project Professional 2010, you can add fields that you will not see if you make bulk changes through Microsoft Project Server 2010, and you can also copy and paste from Microsoft Excel or another list.

To make the same change to several resources at the same time:

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Enterprise Data section, click Resource Center.

  3. Select the check box in the left column for each row that contains a resource that you are editing.

  4. On the Resources tab, in the Editing group, click Bulk Edit.

  5. For each field that you want to edit, select the Apply Changes check box, to the left of the field, and then make your changes.

    Tip:

    If you have trouble remembering which resources you are editing, expand the Resources Selected section. This section displays a list of all resources that will be changed when you click Save.

  6. Click Save to save your changes to all selected resources.


Database Administration (Project Server 2010 settings)

Published: April 14, 2011

The Microsoft Project Server 2010 Database Administration section contains the following articles:

  • Delete enterprise objects (Project Server 2010)

  • Force check-in enterprise objects (Project Server 2010)

  • Back up item-level objects by using Project Web App (Project Server 2010)

  • Restore item-level objects by using Project Web App (Project Server 2010)

  • OLAP database management (Project Server 2010)


Delete enterprise objects (Project Server 2010)

Published: March 17, 2011

You can delete enterprise objects from Microsoft Project Server 2010 when they are no longer needed. You can delete the following types of objects from Microsoft Project Web App (PWA):

  • Projects

  • Resources and users

  • Status report responses

  • Timesheets

  • User delegates

See the articles in this section for procedures to delete each type of object:

  • Delete projects (Project Server 2010)

  • Delete resources and users (Project Server 2010)

  • Delete status report responses (Project Server 2010)

  • Delete timesheets (Project Server 2010)

  • Delete user delegates (Project Server 2010)


Delete projects (Project Server 2010)

Published: March 17, 2011

When a project is no longer needed, you can delete it from Microsoft Project Server 2010. Note that this process deletes the project completely from Project Server and it cannot be retrieved.

Use the following procedure to delete a project from Project Server.

Important:

The project is permanently deleted from Project Server.

To delete a project

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Database Administration section, click Delete Enterprise Objects.

  3. On the Delete Enterprise Objects page, select the Projects option.

  4. Select one of the following options:

    • Delete projects from Draft and Published databases to display a list of projects found in both the Draft and Published databases.

    • Delete projects only from the Published database to display a list of projects in the Published database.

    • Delete projects only from the Archived database to display a list of projects in the Archive database.

  5. To delete the associated SharePoint site, select the Delete the associated Microsoft SharePoint Foundation sites check box.

    Note:

    If you do not delete the associated SharePoint site and you save and publish a new project with the same name as the deleted project, the SharePoint site publishing process will fail.

  6. Select the project that you want to delete.

  7. Click Delete.


Delete resources and users (Project Server 2010)

Published: March 17, 2011

When a resource or user is no longer needed, you can delete it from Microsoft Project Server 2010.

Important:

We recommend not deleting resources from Project Server as this can affect the reporting of actuals. Instead, deactivate resources that are no longer needed.

Use the following procedure to delete resources and users from Project Server.

Important:

The resources and users will be permanently deleted from Project Server.

To delete resources and users

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Database Administration section, click Delete Enterprise Objects.

  3. On the Delete Enterprise Objects page, select the Resources and Users option.

  4. Select the user or resource that you want to delete.

  5. Click Delete.


Delete status report responses (Project Server 2010)

Published: March 17, 2011

When a status report response is no longer needed, you can delete it from Microsoft Project Server 2010. Note that this process deletes the status report response completely from Project Server and it cannot be retrieved.

Use the following procedure to delete status report responses from Project Server.

To delete status report responses

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Database Administration section, click Delete Enterprise Objects.

  3. On the Delete Enterprise Objects page, select the Status Report Responses option.

  4. Specify a period end date parameter (number of days, weeks, months, or years ago before which you want to delete all status report responses).

  5. Click Delete.


Delete timesheets (Project Server 2010)
See Also

Published: March 17, 2011

When a timesheet is no longer needed, you can delete it from Microsoft Project Server 2010. Note that this process deletes the timesheet completely from Project Server and it cannot be retrieved.

Use the following procedure to delete timesheets from Project Server.

To delete timesheets

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Database Administration section, click Delete Enterprise Objects.

  3. On the Delete Enterprise Objects page, select the Timesheets option.

  4. Select the range of timesheet end dates that you want to delete.

  5. Click Delete.

See Also

Other Resources

TimeSheet.QueueDeleteTimesheet Method


Delete user delegates (Project Server 2010)

Published: March 17, 2011

When a user delegate is no longer needed, you can delete it from Microsoft Project Server 2010. Note that this process deletes the user delegate completely from Project Server and it cannot be retrieved.

Use the following procedure to delete user delegates from Project Server.

To delete a user delegate

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Database Administration section, click Delete Enterprise Objects.

  3. On the Delete Enterprise Objects page, select the User Delegates option.

  4. Specify a period end date parameter (number of days, weeks, months, or years before which you want to delete all user delegates).

  5. Click Delete.


Force check-in enterprise objects (Project Server 2010)

Published: July 16, 2012

If an enterprise object is checked out and the user who checked it out is unavailable or unable to check it back in, you can force a check-in.

Important:

If you force check-in an enterprise object that a user is modifying, the modifications may be lost.

You can force check-in the following types of enterprise objects:

  • Enterprise projects

  • Enterprise resources

  • Enterprise custom fields

  • Enterprise calendars

  • Lookup tables for enterprise custom fields

  • Resource plans

See the articles in this section for procedures to check-in each type of object:

  • Check-in enterprise projects (Project Server 2010)

  • Check-in enterprise resources (Project Server 2010)

  • Check-in enterprise custom fields (Project Server 2010)

  • Check-in enterprise calendars (Project Server 2010)

  • Check-in lookup tables for enterprise custom fields (Project Server 2010)

  • Check-in Resource Plans (Project Server 2010)


Check-in enterprise projects (Project Server 2010)

You can force the check-in of an enterprise project that is checked out. Note that forcing a check-in of a project that is being modified by a user may result in the loss of those changes. We highly recommend that users check in projects in the typical manner and that you use force check-in only when it is absolutely necessary.

Use the following procedure to check in enterprise projects.

To check in enterprise projects

  1. On the Server Settings page, click Force Check-in Enterprise Objects.

  2. From the Select the type of object you want to force check-in drop-down list, select Enterprise Projects.

  3. Select the projects that you want to check in.

  4. Click Check In.


Check-in enterprise resources (Project Server 2010)

You can force the check-in of an enterprise resource that is checked out. Note that forcing a check-in of a resource that is being modified by a user may result in the loss of those changes.

Use the following procedure to check in enterprise resources.

To check in enterprise resources

  1. On the Server Settings page, click Force Check-in Enterprise Objects.

  2. From the Select the type of object you want to force check-in drop-down list, select Enterprise Resources.

  3. Select the resources that you want to check in.

  4. Click Check In.


Check-in enterprise custom fields (Project Server 2010)

You can force the check-in of an enterprise custom field that is checked out. Note that forcing a check-in of a custom field that is being modified by a user may result in the loss of those changes.

Use the following procedure to check in enterprise custom fields.

To check in enterprise custom fields

  1. On the Server Settings page, click Force Check-in Enterprise Objects.

  2. From the Select the type of object you want to force check-in drop-down list, select Enterprise Custom Fields.

  3. Select the custom fields that you want to check in.

  4. Click Check In.


Check-in enterprise calendars (Project Server 2010)

You can force the check-in of an enterprise calendar that is checked out. Note that forcing a check-in of an enterprise calendar that is being modified by a user may result in the loss of those changes.

Use the following procedure to check in enterprise calendars.

To check in enterprise calendars

  1. On the Server Settings page, click Force Check-in Enterprise Objects.

  2. From the Select the type of object you want to force check-in drop-down list, select Enterprise Calendars.

  3. Select the calendars that you want to check in.

  4. Click Check In.


Check-in lookup tables for enterprise custom fields (Project Server 2010)

You can force the check-in of an enterprise lookup table that is checked out. Note that forcing a check-in of a lookup table that is being modified by a user may result in the loss of those changes.

Use the following procedure to check in lookup tables.

To check in lookup tables for enterprise custom fields

  1. On the Server Settings page, click Force Check-in Enterprise Objects.

  2. From the Select the type of object you want to force check-in drop-down list, select Lookup Tables for Enterprise Custom Fields.

  3. Select the lookup tables that you want to check in.

  4. Click Check In.


Check-in Resource Plans (Project Server 2010)

You can force the check-in of an enterprise resource plan that is checked out. Note that forcing a check-in of a resource plan that is being modified by a user may result in the loss of those changes.

Use the following procedure to check in resource plans.

To check in resource plans

  1. On the Server Settings page, click Force Check-in Enterprise Objects.

  2. From the Select the type of object you want to force check-in drop-down list, select Resource Plans.

  3. Select the resource plans that you want to check in.

  4. Click Check In.


Back up item-level objects by using Project Web App (Project Server 2010)
See Also

Published: May 12, 2010

This article describes how to back up specific project items in Microsoft Project Web App. This procedure does not back up the physical files of a database (.mdb), but creates backups of specific items in the database. These items are backed up from the Microsoft Project Server 2010 Published database to the Project Server 2010 Archive database.

In order to perform these procedures, you must log on to Project Web App as a member of the Project Server administrator group.

Backing up item-level objects

You can use the procedures in this article to back up the following project items:

Item | Description
Project | Includes project resources, assignments, tasks, custom field values, baseline data
Enterprise resource pool and calendars | Includes enterprise resources and enterprise calendars
Enterprise custom field | Includes enterprise custom field metadata, enterprise lookup table metadata, enterprise lookup table values
Enterprise global template | Includes all Project Professional table, macro, and view definitions
View definition | Includes statusing, Project Center, Portfolio Analyzer, and Resource Center view definitions
System setting | Includes the Web settings table. These are all of your system settings choices but do not include OLAP cube options.
Category and group setting | Includes settings for all Project Server categories and groups.

To back up data automatically by using a daily schedule

  1. Browse to Project Web App.

  2. On the Quick Launch, click Server Settings.

  3. On the Server Settings page, click Schedule Backup.

  4. On the Daily Backup Schedule page, in the Project Retention Policy box, type the number of backups that you want to retain.

    Note:

    Increasing the number of backups requires more database space.

  5. For each project item in the Item section, select either Schedule or Never from the Option list to indicate whether you want to schedule a backup for that item.

  6. If you selected Schedule from the Option list, select the time that you want the backup to occur each day.

  7. Click Save.

To back up data manually

  1. Browse to Project Web App.

  2. On the Quick Launch, click Server Settings.

  3. On the Server Settings page, click Administrative Backup.

  4. In the Select Items section, select the check box next to each project item that you want to back up.

  5. Click Backup. The items that you have selected are backed up immediately.

See Also

Concepts

Restore item-level objects by using Project Web App (Project Server 2010)
Back up and restore the Project Server 2010 farm
Back up a Project Server 2010 farm by using built-in tools


Restore item-level objects by using Project Web App (Project Server 2010)
See Also

Published: May 12, 2010

This article describes how to restore specific project items in Microsoft Project Web App. This procedure does not restore the physical files of a database (.mdb), but restores backups of specific items in the database. These items are backed up from the Microsoft Project Server 2010 Published database to the Project Server 2010 Archive database.

Before you perform this procedure, confirm that project items have been backed up.

Important:

You must log on to Project Web App as a member of the Project Server administrator group to complete this procedure.

Restoring item-level objects

Use the procedure to restore the following project items:

Item | Description
Project | Includes project resources, assignments, tasks, custom field values, baseline data
Enterprise resource pool and calendar | Includes enterprise resources and enterprise calendars
Enterprise custom field | Includes enterprise custom field metadata, enterprise lookup table metadata, enterprise lookup table values
Enterprise global template | Includes all Project Professional table, macro, and view definitions
View definition | Includes statusing, Project Center, Portfolio Analyzer and Resource Center view definitions
System setting | Includes the Web settings table. These are all of your system settings choices but do not include OLAP cube options.
Category and group setting | Includes settings for all Project Server categories and groups.

To restore project items by using Project Web App

  1. Browse to Project Web App.

  2. On the Quick Launch, click Server Settings.

  3. On the Server Settings page, click Administrative Restore.

  4. In the Item list, select the item that you want to restore.

  5. If you selected Projects from the Item list, select the version of the project that you want to restore as the current working version of the project.

    Note:

    The versions that are available for you to restore depend upon the number of backups that have been completed and the total number of backups that you have chosen to retain.

  6. Click Restore.

  7. Any changes that were made between when the item was deleted and when the item was most recently backed up cannot be restored.

See Also

Concepts

Back up item-level objects by using Project Web App (Project Server 2010)
Back up and restore the Project Server 2010 farm
Restore a Project Server 2010 farm by using built-in tools


OLAP database management (Project Server 2010)
See Also

Published: May 12, 2010

Through Microsoft Project Web App (PWA), multiple OLAP databases can be delivered that contain the specific resources, projects, and custom fields that each group within your organization requires for its particular group reporting needs.

In Microsoft Project Server 2010, you can create multiple OLAP databases that have the following characteristics:

  • They only contain data for projects and resources that they administer

  • They only contain facts and dimensions that they select from the new integrated OLAP database management user interface

  • They support departmental filtering to restrict which projects, custom fields, and resources are loaded into the OLAP database

  • They support selection of intrinsic measures for inclusion/exclusion. For example, you can remove fields that you may not use, such as baseline cost 7, to reduce data clutter.

  • They include data for Inactive Tasks and User Scheduled Tasks

  • They let you choose whether to add Timephased/NonTimephased data

  • They have support for Multiple Measure groups in a single OLAP database

  • They contain field names in multiple languages to enable multi-language report creation

Also, when a new OLAP database is created, the necessary Office Data Connections and Excel Reporting templates are created in the Business Intelligence Center in the Reports folder. This data-connected blank template will help you quickly create new reports that are based on the new OLAP database.

For more information about the cubes created within each OLAP database, see Cube Build Service (http://go.microsoft.com/fwlink/p/?LinkId=186369) in the MSDN Library Online.

Departments

The Department field is a new feature for Project Server 2010. Both projects and resources can have departments. The main purpose of departments is to act as a filter for what custom fields are displayed to users within given areas of Microsoft Project Professional 2010 and PWA. Departments allow for different business units to define and make visible their own set of custom fields. Departments are also used to filter OLAP databases so that only the data for that department is loaded.

When configuring a cube, you can specify both the project and resource departments so that the database data is filtered based on these criteria. These values are specified in the OLAP Database Build Settings page.

Also, within the OLAP database configuration, you can add the Project department field as a dimension to the Project and Tasks cubes. And you can add the Resource department field as a dimension to the Resource cube as long as the department field has not been converted to a multi-value field.

With Project Server 2010, departmental custom fields help relieve the problem of too much information and too many choices. Departments help you manage the custom field list, and help you define, at a resource, task, or project level, which fields are required or not required.

Whereas in Microsoft Office Project Server 2007 all custom fields are globally scoped, which means the fields are available to all users, in Project Server 2010, fields can be globally scoped or they can be scoped to a specific department.

Departmental fields enable two primary functions:

  • Filtering custom fields so that a user sees, by default, only those fields that are either global to the system or in the department that the user belongs to.

  • Controlling which fields require input.

Example of departments in use

Field | Scope | Department | Required?
ProjectCustomText1 | Global | - | No
ProjectCustomText2 | Global | - | Yes
ProjectCustomText3 | Department | Marketing | No
ProjectCustomText4 | Department | Marketing | Yes
ProjectCustomText5 | Department | Development | Yes
ProjectCustomText6 | Department | Development | No

If John Woods belongs to the Development department, then when he views areas of the product that have departmental custom fields enabled, he will see:

  • ProjectCustomText1

  • ProjectCustomText2

  • ProjectCustomText5

  • ProjectCustomText6

John will be required to enter data into ProjectCustomText2 and ProjectCustomText5.

Cindy White belongs to the Marketing department; when she views areas of the product that have departmental custom fields enabled, she will see:

  • ProjectCustomText1

  • ProjectCustomText2

  • ProjectCustomText3

  • ProjectCustomText4

Cindy will be required to enter data into ProjectCustomText2 and ProjectCustomText4.

By default, departments filter the list of custom fields that John Woods and Cindy White see. But the filter does not prevent them from viewing custom fields assigned to the other departments.

Departmental fields are not tied into security. You cannot use them with security categories and groups to enable or disable fields and their functions. Instead, their main purpose is to filter out fields which are not useful for the target user.

Department considerations for cubes

Which cubes are filtered by which value No project department specified Project department specified

No resource department specified

All data is loaded for all cubes

Project non-timephased cube

Task non-timephased cube

Issues cube

Risks cube

Deliverables cube

MSP_Project_WSS virtual cube

MSP_Project_Timesheet virtual cube

MSP_Portfolio_Analyzer virtual cube

Assignment non-timephased cube

Assignment timephased cube

EPM timesheet cube

Resource department specified

Assignment non-timephased cube

Assignment timephased cube

Resource non-timephased cube

Resource timephased cube

Timesheet cube

MSP_Project_Timesheet virtual cube

MSP_Portfolio_Analyzer virtual cube

Filtered by Project Department:

  • Project non-timephased cube

  • Task non-timephased cube

  • Issues cube

  • Risks cube

  • Deliverables cube

  • MSP_Project_WSS virtual cube

Filtered by Resource & Project Department:

  • Assignment non-timephased cube

  • Assignment timephased cube

  • EPM timesheet cube

  • MSP_Project_Timesheet virtual cube

  • MSP_Portfolio_Analyzer virtual cube

Filtered by Resource Department:

  • Resource no- timephased cube

  • Resource timephased cube

  • Timesheet cube

Cubes include assignments for resources in projects that belong to other departments or to no department. This ensures that all data is present when examining data such as a department's resources full calendar capacity.

The subset of projects and resources will be used to filter at the project and timesheet level as follows:

Project non-timephased:

  • The data in this cube will be filtered by the departmental project list.

  • Projects with assignments to the department's resources will be included.

Task non-timephased:

  • Non-departmental tasks with assignments to the department's resources will be included. The full non-departmental project will not be included.

  • All tasks for departmental projects will be included.

Assignment non-timephased:

  • Non-departmental project assignments for the department's resources will be included.

  • All assignments for departmental projects will be included.

Assignment timephased:

  • Non-departmental project assignments for the department's resources will be included.

  • All assignments for departmental projects will be included.

Deliverables:

  • All deliverables owned by the filtered list of projects will be included.

  • All deliverables to which the filtered list subscribes and the projects/tasks that subscribe to the filtered list's deliverables will be included.

  • All deliverables offered by non-departmental projects that are subscribed to by departmental projects will be included.

Issues:

  • Issues connected to the filtered list of projects and tasks will be included.

Risks:

  • Risks connected to the filtered list of projects and tasks will be included.

Resource non-timephased:

  • Resources in the departmental list will be included.

Resource timephased:

  • Resources in the departmental list will be included.

Timesheet:

  • Timesheets for departmental list resources will be included.

EPM Timesheet:

  • Timesheets for departmental list resources will be included.

  • Task assignments from projects outside the department will be included.

Resources are described in three ways in the OLAP databases:

  • Fact focus (timesheets, capacity)

  • Associated with Facts (project task assignments)

  • Owning Facts (project owner, issue owner, assignment owner)

The departmental resource list is used to filter facts with focus (Timesheets). Consequently, a non-departmental resource will never have any timesheets or capacity in the OLAP database if the database has a resource filter. However the non-departmental resource will be in the Resource List dimension if it has association with a departmental project, and will only have the relevant assignment facts.

Resources who own things that have separate dimensions (that is, Assignment Owner) do not have to be in the resource list. The Resource List dimension for a specific OLAP database contains:

  • The departmental resources

  • All resources with assignments to departmental projects

See Also

Concepts

Create an OLAP cube (Project Server 2010)
Configure an OLAP cube (Project Server 2010)
Copy an OLAP cube (Project Server 2010)
Delete an OLAP cube (Project Server 2010)
Build an OLAP cube (Project Server 2010)


Create an OLAP cube (Project Server 2010)

Published: May 12, 2010

OLAP cubes are managed on the OLAP Database Management page in Server Settings on a Microsoft Project Web App (PWA) site.

To create an OLAP cube, you must have the Manage Cube Building Service and Manage Site Services Global Permissions. Perform the following procedure to create a new OLAP cube.

To create an OLAP cube

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Database Administration section, click OLAP Database Management.

  3. On the OLAP Database Management page, click New.

  4. Configure the settings on the OLAP Database Build Settings page:

    Setting Description

    Analysis Services Server

    The name of the instance of Microsoft SQL Server Analysis Services (SSAS) where you want to build the cube.

    Analysis Services Database to be created

    The name of the database that you want to create.

    Extranet URL

    The URL for the extranet site.

    Description

    A description of this OLAP cube.

    Project Departments

    If you have projects assigned to departments, you have the option of selecting the departments that you want to have included in the cube. If no department is selected, then no departmental filtering occurs.

    The selection of departments available is controlled by the Department custom lookup table. To allow for multiple selections, modify the Project Departments custom field and select the Allow multiple values to be selected from lookup table check box.

    Note:

    To cancel the selection of a department after it is selected, click the department again.

    Resource Departments

    If you have resources assigned to departments, you have the option of selecting the departments that you want to have included in the cube. If no department is selected, then no departmental filtering occurs.

    The selection of departments available is controlled by the Department custom lookup table. To allow for multiple selections, modify the Resource Departments custom field and select the Allow multiple values to be selected from lookup table check box.

    Note:

    To cancel the selection of a department after it is selected, click the department again.

    Use the earliest project start date and the latest project finish date

    Select this option if you want to base the date range of the cube on the earliest start date of any project and the latest finish date of any project.

    Use the following last and next time units to calculate the date range at the time that the OLAP database is built

    Select this option if you want the date range to be configured automatically based on a delta from the date on which the cube is built. In the Last and Next boxes, type the number of days, weeks, or months that you want to use for the delta.

    Use the fixed date range specified below

    Select this option if you want to use a fixed date range. In the From and To boxes, type the dates that you want to use.

    Update periodically

    Select this option if you want to schedule an update frequency. If this option is not selected, the cube is not updated automatically.

    Immediately retry the OLAP database update if scheduled time fails because of queue down time

    If the scheduled cube build fails because the queue is not available, selecting this option causes the build job to start automatically when the queue becomes available instead of waiting for the next scheduled time.

    Update every

    Select the number of hours, days, weeks, or months for the cube to be rebuilt.

    Start date

    Select the start date for the first automated cube build.

    Start time

    Select the start time for each automated cube build.

  5. Click Save.


Configure an OLAP cube (Project Server 2010)

Published: May 12, 2010

OLAP cubes are managed on the OLAP Database Management page in Server Settings on a Microsoft Project Web App (PWA) site. You can configure OLAP cube dimensions and measures, or you can configure the build settings of a cube.

To configure an OLAP cube, you must have the Manage Cube Building Service Global Permission.

There are two sets of parameters that can be configured on an existing OLAP cube:

  • Dimensions and measures

  • Cube build settings

Perform the following procedure to configure the dimensions and measures of an existing OLAP cube.

To configure OLAP cube dimensions and measures

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Database Administration section, click OLAP Database Management.

  3. On the OLAP Database Management page, select an OLAP database from the list, and then click Configuration.

  4. Configure the settings on the Database Configuration page:

    Setting Description

    Cube Dimensions

    Use the Cube dimensions area to specify the custom fields that you want to add to the OLAP cube as dimensions.

    Select a cube from the drop-down list to display the available and selected dimensions.

    Select the dimensions that you want to include in that cube in the Available fields list and click Add to include them in the cube. Do this for each cube in the Cube drop-down list.

    Cube Measures

    Use the Cube measures area to specify the custom fields that you want to add to the OLAP cube as measures.

    Select a cube from the drop-down list to display the available and selected measures.

    Choose the measures that you want to include in that cube in the Available fields list and click Add to include them in the cube. Do this for each cube in the Cube drop-down list.

    Built-in Measures

    Select the built-in measures that you want to include in the cube.

    The fields that you select are added to the Project, Task, and Assignment cubes as measures.

    Inactive Tasks

    If you want the cube to include inactive tasks, select the Include Inactive Tasks check box.

    Calculated Measures

    Select the cube that you want to define an expression for from the Cube drop-down list, and then click Insert to add a custom MDX expression.

    For more information about MDX expressions, see Multidimensional Expressions (MDX) Reference (http://go.microsoft.com/fwlink/p/?LinkID=186166).

    Note:

    If you are having difficulty editing the grid, make sure that you have applied the latest updates for Internet Explorer 9 on your workstation.

  5. Click Save.

Perform the following procedure to configure the build settings of an existing OLAP cube.

To configure OLAP cube build settings

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Database Administration section, click OLAP Database Management.

  3. On the OLAP Database Management page, in the OLAP Database Name column, click the database that you want to configure.

  4. Configure the settings on the OLAP Database Build Settings page:

    Setting Description

    Analysis Services Server

    The name of the instance of Microsoft SQL Server Analysis Services (SSAS) where you want to build the cube.

    Analysis Services Database to be created

    The name of the database that you want to create.

    Extranet URL

    The URL for the extranet site.

    Description

    A description of this OLAP cube.

    Project Departments

    If you have projects assigned to departments, you have the option of selecting the departments that you want to have included in the cube. If no department is selected, then no departmental filtering occurs.

    The selection of departments available is controlled by the Department custom lookup table. To allow multiple selections, modify the Project Departments custom field and select the Allow multiple values to be selected from lookup table check box.

    Note:

    To cancel the selection of a department after it is selected, click the department again.

    Resource Departments

    If you have resources assigned to departments, you have the option of selecting the departments that you want to have included in the cube. If no department is selected, then no departmental filtering occurs.

    The selection of departments available is controlled by the Department custom lookup table. To allow multiple selections, modify the Resource Departments custom field and select the Allow multiple values to be selected from lookup table check box.

    Note:

    To cancel the selection of a department after it is selected, click the department again.

    Use the earliest project start date and the latest project finish date

    Select this option if you want to base the date range of the cube on the earliest start date of any project and the latest finish date of any project.

    Use the following last and next time units to calculate the date range at the time that the OLAP database is built

    Select this option if you want the date range to be configured automatically based on a delta from the date on which the cube is built. In the Last and Next boxes, type the number of days, weeks, or months that you want to use for the delta.

    Use the fixed date range specified below

    Select this option if you want to use a fixed date range. In the From and To boxes, type the dates that you want to use.

    Update periodically

    Select this option if you want to schedule an update frequency. If this option is not selected, the cube will not be updated automatically.

    Immediately retry the OLAP database update if scheduled time fails because of queue down time

    If the scheduled cube build fails because the queue is not available, selecting this option will cause the build job to start automatically when the queue becomes available instead of waiting for the next scheduled time.

    Update every

    Select the number of hours, days, weeks, or months for the cube to be rebuilt.

    Start date

    Select the start date for the first automated cube build.

    Start time

    Select the start time for each automated cube build.

  5. Click Save.


Copy an OLAP cube (Project Server 2010)

Published: May 12, 2010

OLAP cubes are managed on the OLAP Database Management page in Server Settings on a Microsoft Project Web App (PWA) site.

To copy an OLAP cube, you must have the Manage Cube Building Service Global Permission. Perform the following procedure to copy an existing OLAP Cube. Copying a cube creates a new cube with the same settings and configuration as the cube that you copied. Copying a cube does not copy the Analysis Services database, but instead copies all the cube settings from which you can build a new Analysis Services database.

Note:

You must specify a new name for the Analysis Services database after you copy the cube.

Use the following procedure to copy an OLAP cube.

To copy an OLAP cube

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Database Administration section, click OLAP Database Management.

  3. On the OLAP Database Management page, select the cube that you want to copy, and then click Copy.

  4. On the OLAP Database Build Settings page, type the name of the server and the database that you want created and adjust any other desired settings.

  5. Click Save.

    Note:

    This procedure copies the cube configuration but does not build the cube. You can build the cube manually or wait for it to build on the schedule that you set.


Delete an OLAP cube (Project Server 2010)

Published: May 12, 2010

OLAP cubes are managed on the OLAP Database Management page in Server Settings on a Microsoft Project Web App (PWA) site.

To delete an OLAP cube, you must have the Manage Cube Building Service Global Permission. Perform the following procedure to delete an OLAP Cube.

To delete an OLAP cube

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Database Administration section, click OLAP Database Management.

  3. On the OLAP Database Management page, select the cube that you want to delete, and then click Delete.

    Note:

    This procedure deletes the cube and its associated configuration from Microsoft Project Server. The actual OLAP database is not deleted from Microsoft SQL Server Analysis Services (SSAS). For information about deleting the OLAP database from Analysis Services, see How to: Delete an Analysis Services Database or Cube.


Build an OLAP cube (Project Server 2010)

Published: May 12, 2010

OLAP cubes are managed on the OLAP Database Management page in Server Settings on a Microsoft Project Web App (PWA) site.

OLAP cubes can be scheduled to be built on a regular basis. For more information, see Configure an OLAP cube (Project Server 2010). You can also start the build process manually.

To build an OLAP cube, you must have the Manage Cube Building Service Global Permission. Perform the following procedure to build an existing OLAP cube.

To build an OLAP cube

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Database Administration section, click OLAP Database Management.

  3. On the OLAP Database Management page, select the cube that you want to build, and then click Build Now.


Look and Feel (Project Server 2010 settings)

Published: January 27, 2011

Microsoft Project Server 2010 supports customization of various user interface elements, including the following:

  • Views

  • Color and text formats of grouping levels within views

  • Color and shape options for Gantt bars

  • Links, or groups of links, included on the Quick Launch in Microsoft Project Web App

The options that are described in this section are available in the Look and Feel section on the "Server Settings" page in Project Web App.

Topics covered in this section include the following:

  • Manage Views (Project Server 2010 settings)

  • Grouping Formats (Project Server 2010 settings)

  • Gantt Chart Formats (Project Server 2010 settings)

  • Quick Launch (Project Server 2010 settings)


Manage Views (Project Server 2010 settings)

Published: April 7, 2011

Team members can view project information by selecting different views from the View list at the top of most pages within Microsoft Project Web App. As an administrator, you can better meet the information needs of your organization by adding new views and changing the existing views.

There are several different kinds of views in Project Web App, as listed in the following table.

View type | Description
Project | Use this type of view to review the task, assignment, and resource details of a specific project when a team member clicks a project in the Project Center.
Project Center | Use this type of view to review information about all projects in the Project Center.
Resource Assignments | Use this type of view to review details about specific resource assignments.
Resource Center | Use this type of view to review and compare all resources in the Resource Center.
My Work | Team members use this type of view to review their task assignments.
Resource Plan | Managers use this type of view to create resource plans for their projects.
Team Tasks | Team members use this type of view to review the tasks to which their team is assigned as a resource.
Team Builder | Managers use this type of view to create a team for their project (not a resource plan).
Timesheet | Team members use this type of view to report time against the projects to which they are assigned.
Portfolio Analyses | Portfolio managers use this type of view to compare project proposals and determine which meet organizational goals.
Portfolio Analysis Project Selection | Portfolio managers use this type of view to choose which proposals to approve as projects.

Articles in this section include the following:

  • Create a new Project Web App view (Project Server 2010 settings)

  • Modify a Project Web App view (Project Server 2010 settings)

  • Copy a Project Web App view (Project Server 2010 settings)

  • Delete a Project Web App view (Project Server 2010 settings)


Create a new Project Web App view (Project Server 2010 settings)

Published: January 27, 2011

Options for creating a new view in Microsoft Project Web App vary depending on the kind of view that you are creating.

To create a new view

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, click Manage Views. A list of views is displayed.

  3. Click New View.

  4. In the Name and Type section, in the View Type list, select the kind of view that you are creating.

  5. In the Name box, type the name of the new view.

  6. In the Description box, type a description of the new view.

  7. Complete the remaining fields on the New View page. Not all options listed here are available for every view type.

    • Task, Resource, or Assignment Choose the type of information to display in the view.

      Note:

      These choices are available only when Project is selected as the View Type.

    • Available fields and Displayed fields In the Available fields list, select the fields that you want to include in the view and then click Add. To reorder the fields, click a field name in the Displayed fields box, and then click Up or Down to move it within the list.

    • Field width Click the name of a field in the Displayed fields box, and then type a number of pixels in the Field width box. You can repeat this for each field listed in the Displayed fields box. Setting this value is optional.

    • Custom Label Click the name of a field in the Displayed fields box, and then type a display name in the Custom Label box. You can repeat this for each field listed in the Displayed fields box. Setting this value is optional.

      Note:

      Custom labels are not available for the Resource Plan, Team Tasks, Team Builder, or Portfolio view.

    • Make column read only Click the name of a field in the Displayed fields box, then select this check box to make that field read-only. Not all fields can be made read-only.

      Note:

      Only the Timesheet and My Work views have this option.

    • Gantt Chart format Select the type of Gantt chart that you want to use to display information.

      Note:

      This option is available only for views that can show a Gantt chart.

    • Left offset for the splitter bar Type an offset measurement in pixels to define the placement of the splitter bar in the view.

      Note:

      This option is available only for views that can show a Gantt chart.

    • Show Select the number of outline levels that you want to display, by default, in this view. People using the view will be able to expand additional outline levels.

    • Grouping format Select the grouping style that you want to use, and then define the order of grouping by using the Group by and Then by lists. For more information about how to set up grouping formats, see Grouping Formats (Project Server 2010 settings).

    • Sort by Select the fields by which you want to sort the view. In the Order list, select Ascending or Descending to define the order in which you want to sort the view.

    • Filter Click this button to create or edit filters that you can apply to this view. For more information, see To set up a filter for a view.

    • Filter Resources to user's RBS branch Select this check box to display only those resources that fall under the resource breakdown structure branch of the resource looking at the view.

      Note:

      This option is available only in Resource Center views.

    • Available categories and Categories which access this view Click a category in the Available categories list, and then click Add to make the new view available to users in that security category.

      Tip:

      If users cannot see views that they think they should be able to see, a best practice is to first check that the correct categories are added to the view.

  8. After you have set all appropriate options for the new view, click Save.

You can apply a filter to a view so that data in the view is automatically narrowed based on a set of criteria.

To set up a filter for a view

  1. On the New View page, in the Filter section, click Filter. The Custom Filter dialog box appears.

  2. On the Custom Filter dialog box, select a field in the Field Name list and a test in the Test list, and then type a value to test for in the Value box. You can set a range of values by typing two values separated by a comma (,) in the Value box.

    Tip:

    As you create the filter rules, a green check mark or a red X is displayed to the left of the rule, under the Valid? heading. If you see a red X next to a rule, rest the mouse pointer over the X for more information about why the rule is not considered.

  3. If the filter contains more than one row, select an operator in the And/Or column to start a new row.

  4. Click OK when you have finished setting up filters.


Modify a Project Web App view (Project Server 2010 settings)

Published: April 7, 2011

After you have been using a view in Microsoft Project Web App, you may find that it needs some fine-tuning. It may need a field added, or some adjustments to the security settings. You can easily modify existing views.

To modify an existing view

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Look and Feel section, click Manage Views.

  3. Click the name of the view that you want to modify, in the Name column.

    Tip:

    If you know the view type for the view that you want to modify, you can collapse the other view types to reduce the number of views to scroll through.

  4. Modify the fields and options for the view and then click Save.


Copy a Project Web App view (Project Server 2010 settings)

Published: April 7, 2011

In Microsoft Project Web App, sometimes it may be easier to create a new view by basing it on an existing view. You can select a view and copy it to create a new view.

To create a new view as a copy of an existing view

  1. On the Quick Launch, under Settings, click Server Settings.

  2. On the Server Settings page, under Look and Feel, click Manage Views.

  3. Click a cell in the row for the view that you are copying, and then click Copy View.

    Note:

    Be careful not to click the name of the view, in the Name column. This opens that view for editing, instead of selecting it.

  4. On the Copy View dialog box, type the name that you want to use for the new view, and then click OK. The copied view is added to the table on the Manage Views page.

  5. Scroll through the list of views to find the view that you just created, and then click the name of the new view in the Name column.

  6. Modify the fields and options for the new view, and then click Save.


Delete a Project Web App view (Project Server 2010 settings)

Published: April 7, 2011

If a view is not meeting your organization's needs, or is merely not being used, you can delete it from Microsoft Project Web App.

To delete a view

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Look and Feel section, click Manage Views.

  3. Click a cell in the row for the view that you are deleting, and then click Delete View.

    Note:

    Be careful not to click the name of the view, in the Name column. This opens that view for editing, instead of selecting it.

  4. When prompted, click OK to delete the view.


Grouping Formats (Project Server 2010 settings)

Published: January 27, 2011

You can change how rows (or levels) of information appear when task and resource information is grouped in the Project Center, Resource Center, Project, Task, Timesheet, and Assignment views in Microsoft Project Web App. By changing the appearance of these grouping levels, you can highlight specific information for your team members.

To change the appearance of grouping levels

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Look and Feel section, click Grouping Formats. A list of grouping formats appears.

  3. In the Grouping format list, above the table, select the grouping level that you want to format. This updates the table and narrows which levels are displayed.

  4. To rename the selected grouping level, click Rename.

    Type the new name in the New name for the grouping format box, and then click OK.

    If you do not want to rename the selected grouping level, skip this step.

  5. Use the lists in the Cell Color, Font Color, and Font Style columns to define the appearance of each grouping level.

  6. Click Save, at the bottom of the page.

After you have created a format for grouped task or resource information, you apply the formatting when a new view is created or modified. See Manage Views (Project Server 2010 settings) for more information.


Gantt Chart Formats (Project Server 2010 settings)

Published: January 27, 2011

You can format the color, shape, and pattern of the Gantt bars in Gantt Charts views, Project Center views, and other views in Microsoft Project Web App.

To format a Gantt chart

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Look and Feel section, click Gantt Chart Formats.

  3. In the Gantt Chart list, above the table, select the name of the Gantt chart view that you want to format.

  4. To rename the selected Gantt chart view, click Rename. Type the new name in the New name for Gantt Chart box, and then click OK. If you do not want to rename the selected Gantt chart view, skip this step.

    Note:

    You cannot change the names of the individual Gantt bars.

  5. For each bar type within the selected Gantt chart view (represented as a row in the table), choose the following:

    • Display Select this check box to display this bar type on the selected Gantt chart view.

    • Middle bar shape Select the shape that you want to use for the bar type.

    • Bar Color Choose a color to fill in the selected bar shape.

    • Bar Pattern Choose a pattern to fill in the selected bar shape.

    • Start shape Choose a graphic to display at the start of a Gantt bar of this type.

    • Start color Choose a color to fill in the start shape.

    • End shape Choose a graphic to display at the end of a Gantt bar of this type.

    • End color Choose a color to fill in the end shape.

    A preview of the resulting Gantt bar is displayed on the right side of the table.

  6. Click Save, at the bottom of the page, below the table.


Quick Launch (Project Server 2010 settings)

Published: March 31, 2011

The Quick Launch is the left navigation list in Microsoft Project Web App. You can change how links behave on the Quick Launch, add new links or groups of links, reorder the links, or delete links or groups of links.

Articles in this section include the following:

  • Change Quick Launch behavior (Project Server 2010 settings)

  • Add a new Quick Launch link (Project Server 2010 settings)

  • Modify an existing Quick Launch link (Project Server 2010 settings)

  • Reorder Quick Launch items (Project Server 2010 settings)

  • Delete a Quick Launch link (Project Server 2010 settings)


Change Quick Launch behavior (Project Server 2010 settings)

Published: March 31, 2011

In Microsoft Project Web App, links on the Quick Launch can always be displayed, or you can choose to collapse links based on the context of what a user is currently viewing. You can also choose whether to include links from Microsoft SharePoint Foundation 2010.

To change how the Quick Launch displays links

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Look and Feel section, click Quick Launch.

  3. In the Edit Quick Launch section, in the Expand menu items for area, select from the following options:

    • All sections If you want to display all Quick Launch items always, regardless of what view is currently displayed, click All sections.

    • Current section only If you want to collapse the Quick Launch items to just the top-level headings for sections that do not apply to the current view, click Current section only. For example, if you have selected Current section only, when you are looking at the Project Center, you only see the Quick Launch items under the Projects heading.

  4. Select the Show menu items from Microsoft SharePoint Foundation check box to also show any applicable Quick Launch items that are part of SharePoint Foundation. If you clear this check box, only Project Web App items are displayed on the Quick Launch.

  5. Click Save.


Add a new Quick Launch link (Project Server 2010 settings)

Published: March 31, 2011

You can add new links to the Quick Launch in Microsoft Project Web App, to meet your organization's needs. Links can be to views within Project Web App, intranet sites, or even external Web sites.

To add a link to the Quick Launch

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, under Look and Feel, click Quick Launch.

  3. Under Set Menu Item Details, click New Link.

  4. Type a name for the link in the Custom link name box. This is the text that appears linked on the Quick Launch.

  5. Type the URL for the link in the Custom Web address box.

  6. In the Heading section, select the placement for the new link:

    • If you are creating a new heading link for the Quick Launch, similar to the Projects and My Work headings, select New Heading.

    • If you are creating a link to be included under an existing heading, select the existing heading from the list. The link will be indented under the selected heading.

  7. If you want to hide the new link from the Quick Launch, click No in the Display link in Quick Launch list.

    For example, if you are creating a new group of links under a new heading, you can choose to hide the new heading, and then create all of the new links under the heading and set those to display. When you have the group of links ready to go, you can change the Display link in Quick Launch setting for the new heading to Yes, and the group of links is added to the Quick Launch.

  8. Click OK to add the link to the Quick Launch.


Modify an existing Quick Launch link (Project Server 2010 settings)

Published: March 31, 2011

In Microsoft Project Web App, if a link on the Quick Launch is not pointing to the correct place, is not categorized under the correct heading, or must be temporarily hidden, you can easily make those changes.

To modify an existing Quick Launch item

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Look and Feel section, click Quick Launch.

  3. Under Set Menu Item Details, click the name of the link that you want to modify, in the Name column.

    Tip:

    If you have a long list of Quick Launch items to scroll through, you can collapse the headers to hide the links that you do not want to modify.

  4. Modify the link name, URL, and display option for the link, and then click OK.


Reorder Quick Launch items (Project Server 2010 settings)

Published: March 31, 2011

As you use Microsoft Project Web App, you may find that the links on the Quick Launch would be more helpful if they appeared in a different order. You can reorder the links to meet your organization's needs.

To reorder the links on the Quick Launch

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Look and Feel section, click Quick Launch.

  3. Under Set Menu Item Details, click a cell in the row for the Quick Launch item that you are moving, and then click Move Up or Move Down. If you select a heading, all items indented under the heading move with it.

    Note:

    Be careful not to click the name of the link, in the Name column. This opens that link for editing, instead of selecting it.


Delete a Quick Launch link (Project Server 2010 settings)

Published: March 31, 2011

If your organization is not using a link that is currently included on the Quick Launch in Microsoft Project Web App, you can easily remove it.

To delete a link from the Quick Launch

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Look and Feel section, click Quick Launch.

  3. Under Set Menu Item Details, click a cell in the row for the Quick Launch item that you are deleting, and then click Delete Link. If you select a heading, all items indented under the heading are also be deleted.

    Note:

    Be careful not to click the name of the link, in the Name column. This opens that link for editing, instead of selecting it.

  4. When you are prompted, click OK to delete the link, or group of links, from the Quick Launch.


Time and Task Management (Project Server 2010 settings)

Published: January 27, 2011

Site administrators and other users with appropriate permissions can configure how timesheets and task status are captured and handled in Microsoft Project Server 2010. This includes the following:

  • Setting up fiscal periods and time reporting periods

  • Adjusting timesheets

  • Setting up timesheet line classifications

  • Choosing the right timesheet settings

  • Configuring administrative time categories

  • Choosing task status settings

  • Preventing certain tasks from being updated

The options that are described in this section are available in the Time and Task Management section on the "Server Settings" page in Microsoft Project Web App.

Topics covered in this section include the following:

  • Fiscal periods (Project Server 2010 settings)

  • Time Reporting Periods (Project Server 2010 settings)

  • Timesheet Adjustment (Project Server 2010 settings)

  • Line classifications (Project Server 2010 settings)

  • Timesheet Settings and Defaults (Project Server 2010 settings)

  • Administrative Time (Project Server 2010 settings)

  • Task Settings and Display (Project Server 2010 settings)

  • Close tasks to update (Project Server 2010 settings)


Fiscal periods (Project Server 2010 settings)

Published: January 27, 2011

Fiscal periods define the start dates and beginning dates of the business calendar. They are used to calculate financial statements on an annual basis. By setting up fiscal periods in Microsoft Project Server 2010, you make it possible to map project work against your organization's fiscal planning structure. Once they are set up, you can use fiscal periods as a dimension in your OLAP cubes.

Articles in this section include the following:

  • Define fiscal periods (Project Server 2010 settings)

  • Delete fiscal periods (Project Server 2010 settings)


Define fiscal periods (Project Server 2010 settings)

Published: April 7, 2011

Using Microsoft Project Web App, you can easily define the fiscal periods for a specific year. By creating the fiscal periods in bulk, you can base them off several different models, and Project Server will calculate the dates accordingly.

For example, if your organization divides each quarter into three periods—one that is four weeks long, followed by one that is five weeks long, and then another that is four weeks long—you can specify this model in Project Web App, and Project Server will create fiscal periods for the year according to that schedule. So, if the fiscal year begins on January 1, 2011, the first quarter will have three periods:

  • Period 1: 1/1/2011 - 1/28/2011

  • Period 2: 1/29/2011 - 3/4/2011

  • Period 3: 3/5/2011 - 4/1/2011

To set fiscal periods in Project Web App

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Fiscal Periods.

  3. In the Manage Fiscal Period section, click the year that you want to define as the fiscal period, and then click Define.

  4. In the Define Fiscal Period Start Date section, type the date on which the fiscal year should begin, or select it by using the date picker.

  5. In the Set Fiscal Year Creation Model section, select a formatting method for the fiscal period:

    • 4,5,4 Method Sets a four-week fiscal period, followed by a five-week fiscal period, and then another four-week fiscal period.

    • 4,4,5 Method Sets a four-week fiscal period, followed by another four-week fiscal period, and then a five-week fiscal period.

    • 5,4,4 Method Sets a five-week fiscal period, followed by a four-week fiscal period, and then another four-week fiscal period.

    • 13 months Sets each fiscal period as four weeks.

    • Standard calendar year Sets each fiscal period according to the standard 12-month year, beginning on January 1.

    Note:

    If you want to use a different model for your organization's fiscal year, follow the steps in this procedure to choose a model that is closest to what you want your fiscal year to be like. Once you have saved, you can go back and modify the calendar dates to refine the schedule to meet your organization's needs.

  6. In the Define Period Naming Convention section, create a unique name for the periods by entering:

    • Prefix A prefix of up to 15 characters.

    • Next Sequence Number A sequence number of up to six digits.

    • Suffix A suffix of up to 15 characters.

    Tip:

    As you enter a naming convention in the Prefix, Next Sequence Number, and Suffix fields, an example of the final naming convention is displayed under the fields, next to Sample.

  7. Click Create and Save.

On the Fiscal Periods page, the fiscal period is displayed with the individual periods showing in the Adjust Fiscal Months grid.

After defining a fiscal period, you can edit it by using the Adjust Fiscal Months grid.

To refine the fiscal period dates

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, under Time and Task Management, click Fiscal Periods.

  3. In the Manage Fiscal Period section, select the year that you want to adjust.

  4. In the Adjust Fiscal Months section, in the End Date column, click the end date that you want to modify, and then use the date picker to select a new end date. Start and end dates for periods following the modified end date are automatically adjusted so that all periods are contiguous.

  5. Click Save.


Delete fiscal periods (Project Server 2010 settings)

Published: April 7, 2011

After you have defined the fiscal periods for the first time for your organization in Microsoft Project Web App, you may decide that a 13 month schedule would work better, or that you would prefer a 5,4,4 schedule over the 4,5,4 schedule that you first selected. Instead of redefining each date, it may be easier to delete the fiscal periods completely and start over from scratch.

To delete the fiscal period for a specific year in Project Web App

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Fiscal Periods.

  3. In the Manage Fiscal Period section, select the year that contains the fiscal periods that you want to delete.

  4. In the Adjust Fiscal Months section, click Delete.

    All periods are deleted, and the year returns to an Undefined status.

Once you have deleted the fiscal periods for a year, you can redefine them using the process outlined in Define fiscal periods (Project Server 2010 settings).


Time Reporting Periods (Project Server 2010 settings)

Published: April 7, 2011

In Microsoft Project Web App, time reporting periods define the start dates and the end dates used for each timesheet and task status report. You can create several time reporting periods in bulk to set them up, and then insert or delete individual periods, as necessary. For example, you can create several time reporting periods for a whole fiscal year, and then modify those periods, as needed, to meet the individual needs of your organization.

Articles in this section include the following:

  • Create bulk time reporting periods (Project Server 2010 settings)

  • Insert or delete time reporting periods (Project Server 2010 settings)


Create bulk time reporting periods (Project Server 2010 settings)

Published: April 7, 2011

Rather than creating each Microsoft Project Web App time reporting period individually, you can save yourself much time if you create them in bulk. Use parameters: one for how many periods to create, another for when the first period should begin, and one for how long each period should last.

To create several time reporting periods at the same time

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Time Reporting Periods.

  3. In the Define Bulk Period Parameters section, enter the following:

    • Number of periods to be created Type the number of time reporting periods that you want to create at one time. If you want to create time reporting periods for each week in a year, leave this set to 52.

    • Date the first period starts Type the date on which you want the first time reporting period to start, or use the date picker to select a date. Project Server calculates the dates for all successive periods based on the date selected in this field.

      Note:

      Be sure to select the correct day of the week, as all time reporting periods are based on this date.

    • Length of the standard period (days) Type the number of days in each time reporting period. If you want to use one-week time reporting periods, leave this value set to 7.

  4. In the Define Batch Naming Convention section, create a unique name for each period by entering:

    • Prefix A prefix of up to 20 characters.

    • Next Sequence Number A sequence number of up to six digits.

    • Suffix A suffix of up to 20 characters.

    Tip:

    As you enter a naming convention in the Prefix, Next Sequence Number, and Suffix fields, an example of the final naming convention is displayed after the fields, next to Sample.

  5. Click Create Bulk to create the time reporting periods that you specified.

    Note:

    The Status column for all new time reporting periods is set to Open. Only a Project Server administrator can close a period. It is possible to restrict future timesheets from being submitted. For more information, see Timesheet Settings and Defaults (Project Server 2010 settings).

  6. To change a period label, date, or status, click in the grid in the Create Periods section, and then enter the modifications. For more information, see Insert or delete time reporting periods (Project Server 2010 settings).

    Note:

    If you are having difficulty editing the grid, make sure that you have applied the latest updates for Internet Explorer 9 on your workstation.

  7. Click Save.


Insert or delete time reporting periods (Project Server 2010 settings)

Published: April 7, 2011

In Microsoft Project Web App, time reporting periods define the start dates and the end dates used for each timesheet and task status report. When you first create time reporting periods, the best practice is to create them in bulk. However, you can insert individual time reporting periods, or delete them, as needed.

For more information about how to create time reporting periods in bulk, see Create bulk time reporting periods (Project Server 2010 settings).

Insert a time reporting period

Occasionally, you may have to insert an additional time reporting period. For example, if the current fiscal year uses Monday-Sunday time reporting periods, and you have decided that the next fiscal year will use Sunday-Saturday time reporting periods, you may have to insert a shortened period to transition between the two models.

To insert a time reporting period

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Time Reporting Periods.

  3. In the Create Periods section, scroll through the list to find where you want to insert a new time reporting period, and then click the nearest existing period.

    Note:

    If you are having difficulty editing the grid, make sure that you have applied the latest updates for Internet Explorer 9 on your workstation.

  4. Click Insert Before or Insert After to create a new row for the period you are inserting.

  5. In the Period Label column, replace the New Period text with the name of the inserted period.

  6. Replace the dates in the Start Date and End Date columns, if you need to.

  7. If the inserted period is currently not open for resources to report data, select Closed in the Status column.

  8. Click Save.

Delete a time reporting period

You may also find that you occasionally have to delete existing time periods. For example, if your organization has already set up one-week time reporting periods for the whole year, and partway through the year you decide to switch to two-week time reporting periods, you must delete the remaining one-week periods and re-create the rest of the year as two-week periods.

To delete a time reporting period

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Time Reporting Periods.

  3. In the Create Periods section, click the row for the time period you want to delete, and then click Delete.

    Important:

    To protect project data that is provided by team members, time reporting periods that have associated timesheets cannot be deleted. Because it is common for time reporting periods to have associated timesheets, it is unlikely that you will be able to delete past time reporting periods.

  4. Click Save.


Timesheet Adjustment (Project Server 2010 settings)

Published: March 31, 2011

Occasionally, a resource identifies changes that must be made to a timesheet after the timesheet has been submitted and approved. In Microsoft Project Web App, people with the appropriate permissions can adjust timesheet data.

To adjust timesheets

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Timesheet Adjustment.

  3. Choose filter options to help you display the timesheet that you want to adjust:

    • Approved by me Choose this option to display only timesheets that you have approved.

    • Available timesheets to adjust Choose this option to display all timesheets available for adjustment.

    • My Resources' Unsubmitted Timesheets Choose this option to show all timesheets for resources assigned to your projects. This option may display a very long list of timesheets. You can use the options to the right of the line in the shaded filter section to narrow the list.

    • Date Use this option in combination with Approved by me, Available timesheets to adjust, or My Resources' Unsubmitted Timesheets. Select the Date check box, and then select whether you want to filter for a specific Fiscal Period, or a Custom Date Range.

    • Resources Use this option in combination with Approved by me, Available timesheets to adjust, or My Resources' Unsubmitted Timesheets. Select the Resources check box, and then select whether you want to filter for a specific Cost Center, a specific Resource Name, or both.

  4. Click Apply, on the far right side of the shaded filter section, to filter the list of timesheets by using the options that you selected.

  5. Click the name of the timesheet you want to adjust, in the Timesheet Name column. This opens the timesheet.

  6. Make adjustments to the timesheet, as necessary. Rows that you have adjusted appear as Not Submitted in the Process Status column, which indicates that the data for those rows was not submitted by the resource.

  7. On the Timesheet tab of the ribbon, in the Actions group, click Save.


Line classifications (Project Server 2010 settings)

Published: January 27, 2011

Timesheet line classifications are used to report different types of time against the same task assignment in Microsoft Project Web App. For example, your organization may have different classifications for Travel, Training, and Standard (default) work. Using classifications enables the timesheet user to add the same task assignment once per classification type.

Note:

The Standard line classification is required, even if all work on the task assignment is being reported against timesheet lines with other classifications.

By default, all timesheet lines use the Standard (or default) line classification. Resources can manually change a timesheet line to use one of the additional line classifications that you have configured.

To create a new timesheet line classification

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Line Classifications.

  3. In the Edit, Enter Line Classification section, click New Classification.

  4. In the grid, type a new name and description that identifies the timesheet line classification for team members.

    Note:

    If you are having difficulty editing the grid, make sure that you have applied the latest updates for Internet Explorer 9 on your workstation.

  5. Click Save.

If a classification has been used in previous timesheets, but you no longer want resources to be able to use a classification in timesheets, you can make the classification inactive. This maintains the classification in previous timesheets, for historical reporting, but prevents it from being available in future timesheets.

To inactivate an existing timesheet line classification

  1. On the Quick Launch, under Settings, click Server Settings.

  2. On the Server Settings page, under Time and Task Management, click Line Classifications.

  3. In the Edit, Enter Line Classification section, select Inactive in the Status column for the line classification you no longer want available to resources.

  4. Click Save.

If a line classification has never been used on a timesheet, you can delete it from Microsoft Project Server 2010 altogether.

To delete an existing timesheet line classification

  1. On the Quick Launch, under Settings, click Server Settings.

  2. On the Server Settings page, under Time and Task Management, click Line Classifications.

  3. In the Edit, Enter Line Classification section, click the row for the line classification you are deleting, and then click Delete Classification.

  4. Click Save.


Timesheet Settings and Defaults (Project Server 2010 settings)

Published: March 31, 2011

In Microsoft Project Web App, site administrators can select several different options to control how resources enter time on their timesheets, and whose approval is required. The Timesheet Settings and Defaults page is also where you choose whether your organization uses Single Entry Mode, a feature new to Microsoft Project Server 2010 that combines task status updates with timesheets in one view.

To configure timesheet settings and defaults

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Timesheet Settings and Defaults.

  3. In the Project Web App Display section, select the The timesheet will use standard Overtime and Non-Billable time tracking check box to enable team members to submit overtime and non-billable time. If you do not want team members to be able to submit overtime or non-billable time, clear this check box.

  4. In the Default Timesheet Creation Mode section, specify which data should be included in the default timesheet:

    • Select Current task assignments to pre-populate timesheets with information about the team members' tasks assignments.

    • Select Current projects to pre-populate timesheets with information about the team members' current projects.

    • Select No prepopulation to create blank timesheets for team members.

  5. In the Timesheet Grid Column Units section, specify whether you want timesheet columns to represent Days or Weeks. If you select Weeks, each column in a timesheet represents 7 days, and the date in the column represents the first day of the week.

  6. In the Default Reporting Units section, specify whether team members report time within each timesheet column in Hours or Days.

  7. To specify how many hours make up a whole day's worth of work, type the hours in the The number of hours in a standard timesheet day is box.

  8. To specify how many hours make up a standard work week, type the hours in the The number of hours in a standard timesheet work week is box.

  9. In the Hourly Reporting Limits section, specify the maximum and minimum hours allowed in a timesheet and the maximum number of hours allowed to be reported in a day. If team members report time beyond these limits, errors appear on their timesheets when they submit them.

    Note:

    You may have to put some restrictions on how time is entered based on accounting systems, customers, or internal business policies. Also, if your organization uses team resources, remember this when you set the maximum and minimum values in the Hourly Reporting Limits section.

    If you do not want to set a maximum or a minimum hourly reporting limit, type 999 in the Maximum Hours per Timesheet box to represent unlimited hours, or type 0 in the Minimum Hours per Timesheet box to represent no minimum time. Typing either of these options effectively turns off reporting limits.

  10. In the Timesheet Policies section, specify the following:

    • Select the Allow future time reporting check box to enable team members to record time for periods in the future.

    • Select the Allow new personal tasks check box to enable team members to create as many personal tasks as needed. This time is not mapped to any Project Server project or task. Personal tasks do not appear outside a team member's timesheet or task status.

    • Select the Allow top-level time reporting check box to enable team members to report time against summary tasks. If this check box is cleared, team members must report time against lower-level tasks, and those values roll up to the summary level.

    • In the Task Status Manager Approval section, click Enabled to enable project managers to coordinate or approve/reject timesheet lines on a per-line basis. If you select Enabled, you can select the Require line approval before timesheet approval check box, which specifies that each line must be approved before the whole timesheet can be approved. If you only want to approve whole timesheets (no line-by-line approval), select Disabled.

      Note:

      If you are using Single Entry Mode, you must enable task status manager approval.

  11. In the Auditing section, select the Enable Timesheet Auditing check box to create a detailed record of all changes that are made to a timesheet.

    Tip:

    Click Purge Log to clear the auditing log.

  12. In the Approval Routing section, select the Fixed Approval Routing check box to prevent team members from manually specifying the next approver when they submit their timesheet.

  13. In the Single Entry Mode section, select the Single Entry Mode check box if you want to enable team members to report task progress, and also actual work, on their timesheets.

  14. Click Save.


Administrative Time (Project Server 2010 settings)

Published: March 31, 2011

In Microsoft Project Web App, time that you spend on things other than project work can be classified as administrative time. Administrative time may include vacation, sick leave, organizational meetings, training, or travel. Site administrators can set up different categories for administrative time so that resources can capture those hours on their timesheets to accurately represent what they have done during a given reporting period.

To add an administrative time category

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Administrative Time.

  3. Click New Category. A row is added to the table.

    Note:

    If you are having difficulty editing the grid, make sure that you have applied the latest updates for Internet Explorer 9 on your workstation.

  4. Type a name for the new administrative time category in the Categories column.

  5. In the Status column, choose whether the category is currently Open for use on timesheets, or Closed.

  6. In the Work Type column, choose whether the category captures Working time, such as training or travel, or Non Work time, such as vacation or sick leave.

  7. In the Approve column, choose whether you want time reported in this category to require approval from a manager.

  8. Select the check box in the Always Display column if you want to display a row for this category, by default, on every timesheet for every user. For example, you might choose to always display a timesheet row for the Sick time category so that team members are reminded to report those hours.

  9. Click Save.

    Tip:

    Before clicking Save, make sure that you have the correct set of categories listed. Once you click Save, any new categories that you have added cannot be deleted.

As you create administrative time categories, you may decide that you do not actually need a category and would rather delete it. If you have not yet saved the new categories, you can easily delete the category that you do not need.

Tip:

If you want to make it so that a category that has been saved is no longer available for selection in a timesheet, change the Status column for that category to Closed, and make sure that the check box in the Always Display column is cleared.

To delete an administrative time category

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Administrative Time.

  3. Click the row header for the category that you are deleting, and then click Delete Category. The category is removed.

    Note:

    You can only delete categories that are not yet saved. For example, let's say that you have created several new categories on the Administrative Time page, but have not yet clicked Save on that page. You can delete any of the new categories that you created while on that page. Once you click Save on the Administrative Time page, the categories that you added can no longer be deleted.

  4. Click Save.


Task Settings and Display (Project Server 2010 settings)

Published: March 31, 2011

Site administrators can use the Task Settings and Display page in Microsoft Project Web App to change how resources report task progress, how actual work can be updated, and other task settings.

To configure task settings and display options

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Task Settings and Display.

  3. In the Tracking Method section, select the tracking method that best represents how you want team members to report their progress on project tasks. Options in this section can only be modified if you are not using Single Entry Mode. If you are using Single Entry Mode, the Hours of work done per period and Force project managers to use progress reporting method specified above for all projects options are automatically selected and cannot be modified.

    Tip:

    If you want project managers to have the option of displaying different reporting methods for their projects, clear the Force project managers to use the progress reporting method specified above for all projects check box. However, requiring the same reporting method provides a consistent user experience throughout all projects in your organization, and may make it easier for team members to report progress.

  4. In the Reporting Display section, choose whether you want resources to report their hours daily or weekly. If you select the Resources should report their total hours worked for a week option, select the appropriate day from the Week starts on list.

  5. In the Protect User Updates section, specify how you want updates on actuals to occur:

    • To prevent the project manager from updating a team member's actual time worked, select the Only allow task updates via Tasks and Timesheets check box.

    • To import actual work from all timesheet lines, regardless of line classification, select the Import all timesheet line classifications check box. If this check box is cleared, only actual work from timesheet lines that have a standard classification are imported into task status.

    • To enable users to provide task updates by using periods that they define, select the Allow users to define custom periods for task updates check box.

  6. In the Define Near Future Planning Window section, type the number of reporting periods you want to include in the Near Future Planning Window on the Tasks page.


Close tasks to update (Project Server 2010 settings)

Published: January 27, 2011

If you have the appropriate permissions in Microsoft Project Web App, you can lock project tasks in order to prevent people from submitting task updates.

Note:

Changes to task updating will not take effect until the next time that the project is published.

To prevent updates to a task

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Close Tasks to Update.

  3. On the Close Tasks to Update page, in the Select a project list, click the project that contains the task that you want to close for updating.

  4. In the Select Tasks section, in the Lock column, select the check box for each task that you want to close to updating.

    Tip:

    If you want to prevent updates to all tasks in a project, click Select All, below the table in the Select Tasks section. You can also click Clear All to remove all current selections in the Lock column.

  5. Do one of the following:

    • To publish your project and close the selected tasks to updating, click Publish.

      Note:

      Publishing your project to close tasks to updating will also publish all applied task updates and any other changes that were made to the plan. If you are not ready to publish that information, click Submit instead, to save your task closure settings. When you are ready to publish other changes to your project, the task closure settings are also published.

    • To save your changes without publishing the project, click Submit. Tasks that you selected to be closed for updating will remain open until you publish the project.


Queue (Project Server 2010 settings)
See Also

Published: April 21, 2011

The Queue administrative settings are part of the Microsoft Project Server 2010 Server Settings.

The following are articles about settings that can be configured through the Queue page:

  • Manage Queue Jobs (Project Server 2010 settings)

  • Queue Settings (Project Server 2010 settings)

See Also

Concepts

Project Server 2010 Administrator's Guide


Manage Queue Jobs (Project Server 2010 settings)
See Also

Published: April 21, 2011

The Manage Queue Jobs settings are available through the Microsoft Project Server 2010 Server Settings page in the Queue section. For more information about related administrative settings, see Queue (Project Server 2010 settings).

The Manage Queue Jobs page lets you view Project Server 2010 operations ("jobs") that have been processed by the Microsoft Project Server 2010 queue system. You can use the configuration options to filter jobs and only see the jobs that you are interested in viewing. You can also retry or cancel jobs through this page. The page contains two sections:

  • Queue Jobs settings Contains settings that let you configure which jobs appear in the Jobs Grid and configure which columns are displayed.

  • Jobs Grid Displays jobs that have been processed by the queue, based on the Queue Jobs settings.

Queue Jobs settings

The Manage Queue Jobs page lets you view jobs in the queue through the jobs grid. Viewable jobs are displayed according to the following filter options:

  • Filter Type

  • Job History

  • Job Types

  • Job Completion States

  • Columns

  • Advanced Options

Filter Type

The Filter Type configuration option lets you select filters to query for specific types of jobs that will appear in the Jobs Grid. The filters available in the Filter Type drop-down list are as follows:

  • By Status Displays jobs in the queue in order by status. This is the default setting.

  • My Jobs Displays only the jobs initiated by you.

  • By Project Displays jobs in the queue in order by project.

  • By ID Displays jobs in the queue in order by Job ID.

  • Active Displays all jobs that have a status of Active.

  • Blocked Displays all jobs that have a status of Blocked.

To select a filter

  1. On the Server Settings page, in the Queue section, click Manage Queue Jobs.

  2. On the Manage Queue Jobs page, in the Filter Type section, click the Filter Type drop-down list and select the type of filter that you want to use to determine which jobs appear in the Jobs Grid.

  3. In the Jobs Grid, click Refresh Status.

    Jobs in the Jobs Grid appear according to the filter type that you select. For example, if you select the By Status filter, jobs are listed alphabetically by status.

Job History

This configuration option enables you to select the date range of jobs that appear in the Jobs Grid. Use the From and To fields to select a beginning and end data. The default selection is to select the one-day date range for the present date.

You can use the Maximum Number of Jobs field to limit the number of jobs that appear for a given date range. If the selected date range contains a very large number of jobs that have to appear in the Jobs Grid, the load time for the Manage Queue Jobs page can be very long. The Maximum Number of Jobs field lets you limit the jobs that appear. The default setting is 500.

To configure the Job History setting

  1. On the Server Settings page, in the Queue section, click Manage Queue Jobs.

  2. On the Manage Queue Jobs page, in the Job History section, specify the following values:

    • In the From field, specify the start date for which you want jobs to appear in the Jobs Grid. You can also click the calendar icon to select a start date.

    • In the To field, specify the end date for which you want jobs to appear in the Jobs Grid. You can also click the calendar icon to select an end date.

  3. In the Maximum number of jobs per queue box, you can specify the maximum number of jobs that you want to display. The default value is 500.

  4. In the Jobs Grid, click Refresh Status.

Job Types

The Job Types configuration option lets you select the type of job (for example, Project Create, Timesheet Submit, Notifications, and so on) that you want to appear in the Jobs Grid. By default, all job types are listed in the Selected Jobs list.

To configure the Job Types setting

  1. On the Server Settings page, in the Queue section, click Manage Queue Jobs.

  2. On the Manage Queue Jobs page, in the Job Types section:

    • If you want to keep certain job types from appearing in the Jobs Grid, from the Selected Jobs list, select the job types that you do not want to appear in the Jobs Grid, and then click Remove. (This action moves the selected job types to the Available Jobs list.) Click Remove All if you want to remove all job types from the Selected Jobs list.

    • If you want to add jobs types to the Jobs Grid, from the Available Jobs list, select the job types that you want to appear in the Jobs Grid, and then click Add. This action moves the selected job types to the Selected Jobs list. Click Add All if you want to add all job types to the Selected Jobs list.

  3. In the Jobs Grid, click Refresh Status.

Job Completion States

The Job Completion States configuration option lets you select the job states (for example, Success, Blocked Due to a Failed Job, Processing, and so on) of the jobs that you want to appear in the Jobs Grid. By default, all job state types except Success are listed in the Selected Jobs list. By default, Success is not available because we assume Project Server Administrators are more interested in problems that can be caused by non-successful jobs instead of successful jobs.

This setting can be helpful for troubleshooting jobs that are not completing successfully in the queue. For example, some users might have experienced problems over the past several days. You can see specifically which jobs are not completing successfully by going to the Job Completion States setting and adding all job states except Success. You can also select a Job History date range that begins shortly before the problems occurred (for example, seven days). In this scenario, the Jobs Grid should display information about all jobs that are in a non-successful job status that have occurred over the past week.

The Job Completion states that you can select for this setting are as follows:

  • Blocked Due to a Failed Job

  • Cancelled

  • Failed and Blocking Correlation

  • Failed but not Blocking Correlation

  • Getting Queued

  • Processing

  • Skipped for Optimization

  • Success

  • Waiting to be Processed

  • Waiting to be Processed (On Hold)

  • Waiting to be Processed (Ready for Launch)

  • Waiting to be Processed (Sleeping)

To configure the Job Completion States setting

  1. On the Server Settings page, in the Queue section, click Manage Queue Jobs.

  2. On the Manage Queue Jobs page, in the Job Completion States section, add all job states that you want to display in the Jobs Grid to the Selected Job States list. Job states that are shown in the Available Job States list will not appear in the Job Grid.

    • To move an available job state in the Available Job States list to the Selected Job States list, select the job and then click Add.

    • To remove a job state from the Selected Job States list, select the job and then click Remove. To select multiple job states press the Ctrl key while making your selections.

  3. In the Jobs Grid, click Refresh Status.

Columns

The Columns configuration option lets you select the columns that appear in the Jobs Grid. It also lets you configure the order of the columns in the Jobs Grid.

The column options available to you are as follows:

  • Completed Time

  • Correlation ID

  • Correlation Priority

  • Entry Time

  • Job ID

  • JobGroup ID

  • JobInfo ID

  • Job State

  • Job Type

  • Last Admin Action

  • Position

  • Priority

  • Project Name

  • Queue Type

To configure the Columns setting

  1. On the Server Settings page, in the Queue section, click Manage Queue Jobs.

  2. On the Manage Queue Jobs page, in the Columns section, add all job states that you want to display in the Jobs Grid to the Selected Job States list. Job states that are shown in the Available Job States list will not appear in the Job Grid.

    • To move an available job state in the Available Job States list to the Selected Job States list, select the job and then click Add.

    • To remove a job state from the Selected Job States list, select the job and then click Remove. To select multiple job states press the Ctrl key while making your selections.

  3. In the Jobs Grid, click Refresh Status.

Advanced Options

Both of the Advanced Options queue settings apply to the way that jobs in the queue are canceled:

  • Cancel jobs getting enqueued Select this option to cancel all jobs that remain in a "getting enqueued" state for a prolonged time. When a job is in this state, it means that the queue has been told to start to receive a job that will be processed later. But it has not received a tag telling it that all the data for the job has been received. Until the full job has been received, the job will remain in the getting enqueued state. If a job remains in the getting enqueued state for a prolonged time, it is likely that something is preventing the job from finishing. If the job continues to remain in this state after you re-run it, review your ULS logs to troubleshoot why they problem is occurring.

    Saving a project from Project Professional to Project Server is a job that typically enqueues. When you save a project from Project Professional to the Project Server, the job synchronizes with the server. If the synchronization is not completed, then the job remains in the enqueued state.

    By default, this setting is enabled.

  • Cancel subsequent jobs in the correlation When you cancel a job that spawns additional jobs, this option automatically cancels those jobs also. For example, a Project 1 Publish job that is canceled will also cancel the Project 1 Reporting job that was automatically created.

    By default, this setting is also enabled.

Make sure to click Refresh Status in the Jobs Grid after you make any changes.

Jobs Grid

The Jobs Grid provides a view of the jobs that meet the criteria listed in the Manage Queue Jobs page. Options within this section let you select a job or group of jobs and to apply the following options to them, if applicable:

  • Retry Job Allows you to rerun selected jobs in the queue that were not completed successfully.

  • Cancel Job Allows you to cancel selected jobs in the queue that were not completed successfully.

  • View Related Jobs Allows you to view jobs that have a dependency relationship (for example, jobs in the same correlation) with a selected job in the queue.

  • Refresh Status Allows you to update the jobs in your job grid with the latest status.

To retry a job

  1. In the Jobs Grid, find the job that you want to retry, and then select the check box in the far left column of this job.

  2. Click Retry Job. Recheck the status of the job in the Jobs Grid to verify the results of retrying the job.

To cancel a job

  1. In the Jobs Grid, find the job that you want to cancel, and then select the check box in the far left column of this job. Note that a job that has already completed successfully cannot be canceled.

  2. Click Cancel Job.

To view related jobs

  1. In the Jobs Grid, find the job for which you want to find related jobs, and then select the check box in the far left column of this job.

  2. Click View All Jobs. All jobs that have a dependency relationship with this job appear in the Jobs Grid.

See Also

Concepts

Project Server 2010 Administrator's Guide
Queue Settings (Project Server 2010 settings)


Queue Settings (Project Server 2010 settings)
See Also

Published: April 21, 2011

The Queue Settings are available through the Microsoft Project Server 2010 Server Settings page in the Queue section. For more information about related administrative settings, see Queue (Project Server 2010 settings).

The Queue Settings page lets you configure the way that the Project Server 2010 queue system operates in your environment. The Queue Settings page includes the following options:

  • Queue Type

  • Maximum Number of Job Processor Threads

  • Polling Interval (in milliseconds)

  • Retry Interval (in milliseconds)

  • Retry limit

  • SQL retry interval (in milliseconds)

  • SQL retry limit

  • SQL Timeout (in seconds)

  • Cleanup Interval (in hours)

  • Cleanup Interval Offset (in minutes)

  • Cleanup Age Limit for Successful Jobs (in hours)

  • Cleanup Age Limit for Non-Successful Jobs (in hours)

  • Bookkeeping Interval (in milliseconds)

  • Queue Timeout (in minutes)

  • Fast Polling

Queue settings can be configured on this page by entering a value in the corresponding settings field.

Important:

Queue settings are specific per Microsoft Project Web App site.

Queue Type

The Queue Type setting lets you select the queue to which the settings on the page apply. The options are the Project Queue (which processes job types such as Project Save and Publish) and the Timesheet Queue (which processes job types such as Timesheet Save and Notifications).

Maximum Number of Job Processor Threads

The Maximum Number of Job Processor Threads setting determines how many job processor threads are available for use for the selected queue type (Project or Timesheet).

As a starting point, we recommend that you set the maximum number of processor threads settings based on the number of available processors (or cores). For example, if the Project Server application server uses a single dual-core processor, configuring the settings for two threads per queue is a good starting point. If your application server uses a quad dual-core processor, you might be able to use eight threads per queue. You can adjust these settings accordingly based not only on the volume of transactions, but also the average size of the transactions (for example, publishing 10-line projects versus 1000-line projects).

You should also think about the farm topology and other applications that are running on the farm. If you have four application servers on the farm and if you set the Maximum Number of Job Processor Threads setting to 4, it gives you the potential for 16 threads to be operating. You should adjust the setting accordingly if your application server is also serving as a front-end Web server or running search or other processor-intensive activities.

Along with the consideration of the processing power of application servers, it is important to consider the throughput of the computer that is running SQL Server that is hosting the Project Server databases. For instance, suppose that you have eight application servers that can process threads and the Maximum Number of Job Processor Threads setting is at 4 (potential for 32 threads all processing jobs). SQL Server may start having contention issues because all the threads are operating on the same table.

Additionally, you can monitor performance counters, application logs, and ULS logs to guide you in fine-tuning the queue to work with your typical server loads.

Polling Interval (in milliseconds)

The Polling Interval setting lets you specify the time interval (in milliseconds) in which the Queue NT Service polls the project or timesheet database (depending what you selected for Job Type) for new jobs. The valid range is 500 through 300000, with a default value of 1000.

Retry Interval (in milliseconds)

The Retry Interval setting lets you set the length of time (in milliseconds) between retries for jobs that have failed through SQL-related issues, such as SQL deadlocks. The valid range is 0 (immediate retry) to 300000, with a default value of 1000.

Retry limit

The Retry limit setting lets you set the limit on retries on a failed polling query. The Project Server Queuing System polls the databases on a regular basis to retrieve jobs that need processing. If this query should fail for an SQL-related reason, the system will attempt to poll the database again after a time.

SQL retry interval (in milliseconds)

The queue polls the database at set intervals for jobs that need processing. If the query fails, the SQL Retry Interval setting lets you set the length of time (in milliseconds) before the query is retried. The valid range is 0 (immediate retry) to 60000, with a default value of 1000.

SQL retry limit

The queue polls the database at set intervals for jobs that need processing. If the query fails, the SQL retry limit setting lets you set the number of times the query will be retried. The valid range is 0 (no retries) to 100, with a default value of 5.

SQL Timeout (in seconds)

The queue makes SQL calls for retrieving and executing jobs. This SQL Timeout setting lets you set the time-out value (in seconds) for these calls. If any job fails because of an SQL Timeout error, you can increase the value for this setting and retry the job. The valid range is 30 to 86400 (one day), with a default value of 1800 (30 minutes).

Cleanup Interval (in hours)

The Cleanup Interval setting lets you configure the frequency (in hours) with which the Queue Cleanup job runs. The valid range is 1 to 100000, with a default value of 24 (one day). For example, if the cleanup interval is set to the default value of 24, the Queue Cleanup job will run every 24 hours. You can set the time which the Queue Cleanup job will run with the Cleanup Interval Offset setting.

Cleanup Interval Offset (in minutes)

The Cleanup Interval Offset setting determines the time at which the queue cleanup job will run. The default value is 0, which sets the cleanup to occur at 12:00 A.M. The valid range is 0 (12:00 A.M.) to 1439 (11:59 P.M.). Use this together with the Cleanup Interval setting. For example, if the Cleanup Interval Offset value is set to 180, and the Cleanup Interval value is set to 24, the Queue Cleanup job will run daily at 3:00 A.M.

You may want to use the Cleanup Interval Offset to run after the cube service is scheduled to run. In this situation, if the cube service starts at midnight, you may want to postpone the cleanup to occur some hours after midnight.

Cleanup Age Limit for Successful Jobs (in hours)

The Cleanup Age Limit for Successful Jobs setting lets you configure when a job that has been completed successfully is removed from the system. You can configure this setting by entering the value (in hours) in the Cleanup Age Limit for Successful Job field. The value that you enter configures the queue to delete the job during the cleanup interval, only if the age of the successfully created job is equal to or greater than that value.

For example, you configure the Cleanup Age Limit for Successful Jobs value to be 24 (default value). Cleanup Interval Offset is configured to clean up jobs at 12:00 A.M. daily. If you have a publish job that completed successfully on 11:55 P.M. on September 1, it is not removed from the system until September 3 at 12:00 A.M. when it is over 24 hours old. The September 2 12:00 A.M. cleanup does not remove the job because it is only five minutes old.

Note:

Typically the number of successful jobs compared to non-successful jobs is very high. Therefore, Cleanup Age for Successful Jobs is usually set to a lower value compared to the Cleanup Age Limit for Non-Successful Jobs value.

Note:

Default Project Server categories cannot be deleted.

Cleanup Age Limit for Non-Successful Jobs (in hours)

The Cleanup Age Limit for Non-Successful Jobs setting lets you configure when a job that has completed in an unsuccessful state is removed from the system. You can configure this setting by entering the value (in hours) in the Cleanup Age Limit for Non-Successful Job field. The value that you enter configures the queue to delete the job during the cleanup interval, only if the age of the unsuccessful job is equal to or greater than that value. The method in which unsuccessful jobs are removed from the system is identical to the way successfully completed jobs are removed from the system.

Note:

Jobs that are in an Unsuccessful and blocking correlation state stay in the history until they are successfully retried or canceled. The cleanup for non-successful jobs does not affect jobs in this state.

The default value of this setting is 168 hours (7 days). Since job status information is important in helping to troubleshoot problems when a job has not completed successfully, we recommend not to set this value to less than the default setting.

Bookkeeping Interval (in milliseconds)

There are several "bookkeeping" tasks that are run by the Queuing System. For example, these include awakening jobs in a "sleeping" state, updating the heartbeat time stamp, or checking whether the Queue Cleanup job needs to be run. The Bookkeeping Interval setting controls the time interval (in milliseconds) at which these tasks are run.

The valid range is 500 to 300000, with a default value of 10000 (ten seconds).

Queue Timeout (in minutes)

In a farm that contains multiple Application servers, if the Queue Service fails on one of the servers, jobs are automatically distributed among the remaining Application servers on which the Queue Service is active. A Queue Service is considered to have timed out if it has not updated its heartbeat for longer than the Queue Timeout value (in minutes). The heartbeat is updated by the Queue in all the Project Web App databases that it touches (for example, every time that the Published and Draft databases are polled for jobs).

The valid range is 2 to 20, with a default value of 3.

Note:

The Queue Timeout value cannot be less than four times the Bookkeeping Interval at any time. If this rule is violated, the Queue Timeout value will automatically be changed to four times the Bookkeeping value.

Note:

Default Project Server categories cannot be deleted.

Fast Polling

By default, the Fast Polling setting is enabled, and it allows the queue to process all jobs in a Waiting to be Processed state to be processed as soon as possible. However, if this fast processing overwhelms the server and the Queue has to slow down, this setting can be disabled.

If Fast Polling is disabled, the Queue checks whether there are any free threads to process jobs. If there are, the free threads are loaded with jobs in a Waiting to be Processed state. It then waits for the polling interval and repeats the process.

If Fast Polling is enabled, the Queue does not wait for the polling interval if there are pending jobs. As jobs get processed, all pending jobs get processed immediately.

See Also

Concepts

Project Server 2010 Administrator's Guide
Manage Queue Jobs (Project Server 2010 settings)


Operational Policies (Project Server 2010 settings)
See Also

Published: March 31, 2011

The Operational Policies administrative settings are part of the Microsoft Project Server 2010 Server Settings.

The following are articles about settings that can be configured through the Operational Policies page:

  • Alerts and Reminders (Project Server 2010 settings)

  • Additional Server Settings (Project Server 2010 settings)

    • Project 2007 Compatibility Mode (Project Server 2010 settings)

    • Project Professional Versions (Project Server 2010 settings)

    • Enterprise Settings (Project Server 2010 settings)

    • Currency Settings (Project Server 2010 settings)

    • Resource Capacity Settings (Project Server 2010 settings)

    • Resource Plan Work Day (Project Server 2010 settings)

    • Exchange Server Details (Project Server 2010 settings)

    • Task Mode Settings (Project Server 2010 settings)

  • Server Side Event Handlers (Project Server 2010 settings)

  • Active Directory Resource Pool Synchronization (Project Server 2010 settings)

  • Project Sites (Project Server 2010 settings)

  • Project Site Provisioning Settings (Project Server 2010 settings)

  • Bulk Update Project Sites (Project Server 2010 settings)

See Also

Concepts

Project Server 2010 Administrator's Guide


Alerts and Reminders (Project Server 2010 settings)
See Also

Published: March 31, 2011

The Alerts and Reminders settings are available through the Microsoft Project Server 2010 Server Settings page in the Operational Policies section. For more information about related administrative settings, see Operational Policies (Project Server 2010 settings).

Configure Alerts and Reminders settings

Project Server 2010 generates e-mail notifications and reminders for each user whenever new, overdue, rejected, or forthcoming events occur. Administrators can configure alerts for their reminders from the Alerts and Reminders page in your Project Web App Server Settings.

Before e-mail notifications and reminders can be used by members of your organization, the appropriate server and account information must be identified. As a Project Web App administrator, you can configure the following settings in the Alerts and Reminders page:

  • Notification E-mail Settings

  • Schedule e-mail reminder service

Notification E-mail Settings

The Notification E-mail Settings allows the Project Server Administrator to maintain the default sender e-mail address and message information that is automatically included with each e-mail notification or reminder sent by Project Server. It also lets you specify the SMTP server and associated port number.

To configure the Notification E-mail settings

  1. On the Server Settings page, in the Operational Policies section, click Alerts and Reminders.

  2. On the Alerts and Reminders page, in the Notification E-mail Settings section, enter the following information:

    1. Select the Turn on notifications with the following settings check box to maintain all the notification e-mail settings but turn off notifications globally.

      Note:

      This setting was not available in Microsoft Office Project Server 2007. In Office Project Server 2007, you had to remove the SMTP server details to stop notifications and reminders from being sent.

    2. In the SMTP mail server box, type the name of your SMTP server. Verify the port number in the Port box.

    3. In the From address box, enter the default e-mail address. This address is the reply-to address for all notification and reminder e-mail messages.

    4. In the Company domain box, enter the domain name of your company (for example, Contoso.com).

    5. In the E-mail footer box, type the default message that you want appended to all notification e-mail messages. For example: This e-mail message may contain confidential information and is intended only for the recipients named above.

  3. Click Save.

Schedule e-mail reminder service

The Schedule e-mail reminder service allows a Project Server administrator to set the time of day at which the e-mail reminder service scans the Project Server databases to determine who should receive e-mail reminders (such as users who have upcoming or overdue tasks and status reports).

Depending on the volume of notification and reminder e-mail messages, you should consider setting the service to run at a time when the overall load on the server is low.

To configure the Schedule E-mail Reminder service

  1. On the Server Settings page, in the Operational Policies section, click Alerts and Reminders.

  2. On the Alerts and Reminders page, in the Schedule e-mail reminder service section, click the Schedule e-mail reminder service to run every day at drop-down menu and select the time at which you want the service to run.

  3. Click Save.

See Also

Concepts

Project Server 2010 Administrator's Guide


Additional Server Settings (Project Server 2010 settings)
See Also

Published: March 31, 2011

The Additional Server Settings page is available from the Operational Policies section of the Microsoft Project Server 2010 Server Settings page. For more information about related administrative settings, see Operational Policies (Project Server 2010 settings).

The Additional Server Settings page in Project Server 2010 Server Settings lets you configure:

  • Project 2007 Compatibility Mode (Project Server 2010 settings)

  • Project Professional Versions (Project Server 2010 settings)

  • Enterprise Settings (Project Server 2010 settings)

  • Currency Settings (Project Server 2010 settings)

  • Resource Capacity Settings (Project Server 2010 settings)

  • Resource Plan Work Day (Project Server 2010 settings)

  • Exchange Server Details (Project Server 2010 settings)

  • Task Mode Settings (Project Server 2010 settings)

See Also

Concepts

Project Server 2010 Administrator's Guide


Project 2007 Compatibility Mode (Project Server 2010 settings)
See Also

Published: March 31, 2011

Project 2007 compatibility mode is a part of the Additional Server Settings in the Operational Policies section of Microsoft Project Server 2010 Server Settings. For more information about related settings that you can configure, see Additional Server Settings (Project Server 2010 settings). For more information about Operational Policies settings, see Operational Policies (Project Server 2010 settings).

Project 2007 Compatibility Mode

Project 2007 compatibility mode allows an upgraded Project Server 2010 instance to accept client connections from Microsoft Office Project Professional 2007 with Service Pack 2 (SP2) and also Project Professional 2010. This setting is only configurable if your deployment has been upgraded from Microsoft Office Project Server 2007. (By default, it is enabled after the upgrade.) This feature in Project Server 2010 is also known as backward compatibility mode (BCM).

Note:

Project Server 2010 does not accept connections from Project Professional 2003, even if BCM is enabled.

Backward compatibility mode (BCM) is a feature in Project Server 2010 that assists in the upgrade of an Enterprise Project Management environment. Project Server 2010 accepts connections from the Microsoft Project Professional 2010 client. But it can also accept connections from Microsoft Office Project Professional 2007 with Service Pack 2 (SP2) if BCM is enabled in Project Server 2010. BCM is enabled automatically after you upgrade to Project Server 2010. After you upgrade to Project Server 2010 (by either the in-place or database-attach upgrade method), BCM enables you to avoid having to upgrade your Office Project Professional 2007 client computers at the same time. Because Project Server 2010 accepts connections from both Office Project Professional 2007 SP2 and Project Professional 2010 clients when BCM is enabled, you can decide to upgrade the clients later, and in batches (running in a mixed environment), if you want. When you have finished upgrading the clients to Project Professional 2010, you can turn off BCM in Project Server 2010 server settings, which then allows for only Project Professional 2010 connections.

Important:

Once Project 2007 compatibility mode is disabled, it cannot be re-enabled. Ensure that you want to disable BCM if you are going to make the change.

We recommend that BCM be enabled only as a temporary measure to help in the upgrade process. When Project Server 2010 is configured in backward compatibility mode, Project Professional 2010 clients that connect with Project Server 2010 have certain features disabled. The disabled features cause the following limitations:

  • Manually scheduled tasks are not available on the server or client.

  • Tasks cannot be set to inactive.

  • Font strikethrough is not available.

  • All departmental custom fields are enforced in Office Project Professional 2007.

All new features that are available in Project Professional 2010 (for example, Timeline, Team Planner, 32-bit colors) are available to Project Professional 2010 users, but not to Office Project Professional 2007 SP2 users.

An instance of Office Project Professional 2007 SP2 connecting to Project Server 2010 in backward compatibility mode is blocked from providing functionality that requires loading a Microsoft Project Web App page in the client. This includes doing approvals and opening enterprise resources. As a workaround, you can use Project Web App on a Web browser to do these functions until you are ready to upgrade to Project Professional 2010. Additionally, workflow-controlled custom fields are not available in Office Project Professional 2007 SP2.

Project Server 2010 prevents you from creating cross-project type links (resource sharing, cross-project dependencies, and master/subproject) on mixed Project file versions. For example, you cannot create a cross-project link from a project that is in compatibility mode (Office Project 2007 format) with one that is in the native mode (Project 2010 format). What this means is that after you disable backward compatibility mode, as you open and save projects, they are converted to native mode. However, projects that have not been opened and saved remain in compatibility mode. Project Server 2010 does not let you create or even connect projects that are in different modes. Therefore, your cross-project links do not fully function until all of the related projects are opened and saved so that they are all in Project 2010 format.

When BCM is disabled in Project Server 2010, Project Server is running in native mode. In native mode, only Project Professional 2010 clients are able to connect to Project Server 2010. However, Project Professional 2010 features that were not available in BCM (such as manually scheduled tasks) become available in native mode.

To disable Project 2007 compatibility mode (backward compatibility mode)

  1. On the Server Settings page, in the Operational Policies section, click Additional Server Settings.

  2. On the Additional Server Settings page, in the Project 2007 Compatibility Mode section, clear the Enable Project 2007 Compatibility Mode check box.

  3. Click OK.

  4. After making the change, you must check out and open the Enterprise Global file in Microsoft Project Professional 2010. In the Enterprise Global file, make a very minor change (for example, dragging the splitter bar on the screen), save the file, and then check it back in. This is required to upgrade the Enterprise Global file to the newer version of the Microsoft Project Professional client.

Important:

The Enterprise Global file must be upgraded to the Project Professional 2010 client after BCM is disabled (step 4 in the procedure above). This step ensures that all new projects are in native mode with all Project Professional 2010 features enabled. (All new projects are based on the Enterprise Global file). Neglecting to upgrade the Enterprise Global file with the Microsoft Project Professional client can lead to serious problems. Objects in the file (for example, views, tables, filters) will remain in Office Project 2007 format and they will be expected to be in Project 2010 format when new projects are created.

See Also

Concepts

Backward compatibility mode (Project Server 2010 TechNet Webcast)


Project Professional Versions (Project Server 2010 settings)

Published: March 31, 2011

Project Professional Versions is a part of the Additional Server Settings in the Operational Policies section of Microsoft Project Server 2010 Server Settings. For more information about related settings that you can configure, see Additional Server Settings (Project Server 2010 settings). For more information about Operational Policies settings, see Operational Policies (Project Server 2010 settings).

Project Professional Versions

Project Professional Versions lets you specify which versions (build numbers) of Project Professional client will be able to connect to your Project Server 2010 environment. This setting lets you ensure that Project Professional client connections to the server are all at a required base level. For example, if you recently updated both Project Server 2010 and Project Professional 2010 to the October 2010 Cumulative Update, you can verify that all clients that connect to the server are at least at this level by entering the build number (14.0.5128.5000). All Project Professional 2010 clients that have not been updated to the October 2010 Cumulative Update or a later version will be unable to connect.

Note:

If backward compatibility mode (BCM) is enabled, you do not have to make any additional changes to this setting to enable Project Professional 2007 SP 2 clients to connect to the server. However, you can enter a build number for the Microsoft Office Project Server 2007 client if you require a minimum build.

For example, let's say that BCM is enabled and you only want the following two builds (and later versions) to connect to Project Server 2010:

  • Project Professional 2007 with Service Pack 3 (SP3)

  • Project Professional 2010 with the December 2010 Cumulative update

In the previous example, for the Project Professional Versions setting that you would enter the build number for each version, separated by a comma.

To configure the Project Professional Versioning setting

  1. On the Server Settings page, in the Operational Policies section, click Additional Server Settings.

  2. On the Additional Server Settings page, in the Project Professional Versions section, type the build number of each Project Professional version that you want to connect to Project Server 2010. Use a comma as a separator between multiple version numbers.

    Versions older than the build number that you enter will be unable to connect to your Project Server 2010 environment.

  3. Click Save.


Enterprise Settings (Project Server 2010 settings)

Published: March 31, 2011

Enterprise Settings is a part of the Additional Server Settings in the Operational Policies section of Microsoft Project Server 2010 Server Settings. For more information about related settings that you can configure, see Additional Server Settings (Project Server 2010 settings). For more information about Operational Policies settings, see Operational Policies (Project Server 2010 settings).

Enterprise Settings

Enterprise Settings lets you determine whether Project Server 2010 allows for projects to have the following capabilities:

  • Allow master projects to be saved and published to Microsoft Project Server 2010 (By default, this option is enabled.) Enabling this setting enables master projects to be used in Project Server 2010. Master projects are projects that contain sub-projects, and they usually contain tasks that are dependent on one another. Check with your Project Management Office to determine whether your organization prohibits the use of master projects.

  • Allow projects to use local base calendars Enabling this settings lets users not only use enterprise base calendars that are on the system for their enterprise projects, but to also use local base calendars that users create. Having this setting disabled (which is the default) restricts users to using only enterprise base calendars that are on the system for their projects. Restricting the users to enterprise calendars gives you more control by preventing problems that can occur when projects use local base calendars that contain conflicting data. For example, a project that uses a local base calendar that differs from an enterprise calendar (for example, July 4 as a work day versus a holiday) can lead to faulty calculations and other issues.

To configure the Enterprise Settings

  1. On the Server Settings page, in the Operational Policies section, click Additional Server Settings.

  2. On the Additional Server Settings page, in the Enterprise Settings section:

    1. Select Allow master projects to be saved and published to Microsoft Project Server 2010 if you want to enable this setting. (By default, it is enabled.)

    2. Select Allow projects to use local base calendars if you want to enable this setting (By default, this option is cleared.)

  3. Click Save.


Currency Settings (Project Server 2010 settings)

Published: March 31, 2011

Currency Settings is a part of the Additional Server Settings in the Operational Policies section of Microsoft Project Server 2010 Server Settings. For more information about related settings that you can configure, see Additional Server Settings (Project Server 2010 settings). For more information about Operational Policies settings, see Operational Policies (Project Server 2010 settings).

Currency Settings

Through the currency setting, you can select the default currency setting for projects that are published to the server. (This is used for reports and the default view for new projects.) The default value is based on the default currency of the language that is used for the Project Web App instance.

You can also select the currency settings for publishing:

  • Allow projects to be published in various currencies Select this option if your organization uses multiple currencies for costs within projects. (This is the default setting).

  • Enforce that projects are published in the server currency Select this option if your organization only uses a single currency for costs within projects. The currency that is used is the one selected as the default server currency.

To configure the Currency Settings

  1. On the Server Settings page, in the Operational Policies section, click Additional Server Settings.

  2. On the Additional Server Settings page, in the Currency Settings section, select one of the following currency options:

    • Allow projects to be published in various currencies (default).

    • Enforce that projects are published in the server currency

      If you select Enforce that projects are published in the server currency, you see a message. This message box warns you that the change is only be enforced on all successive projects that are published to the server. All projects that are not using the default server currency must be changed to the default currency and republished.

  3. Click OK.

    All projects published to the server that are using a currency that conflicts with the server currency will be displayed in the Currency Settings section of the page in the Project in conflict with the server currency list. You can use this as a reference to note which projects have to have their currency changed to the server currency.

  4. Click Save.

Change currency option for a project

Use the following procedure in Project Professional 2010 to change the currency settings for a project. You can use this procedure to do the following:

  • Select the currency for a specific project if the currency setting lets you use multiple currencies.

  • Change the currency setting on a project to the server currency if the currency setting only lets you use the server currency.

To change the currency for a project in Project Professional 2010

  1. Open Project Professional 2010 and log on to Project Server 2010.

  2. Check out and open a project from Project Server 2010.

  3. Click File, and then click Options.

  4. On the Project Options page, click Display.

  5. On the Display page, in the Currency options for this project section, select the currency that you want to use for this project.

  6. Click OK.

  7. Click File, and then click Save to save the project.

  8. Click File, and then click Publish to publish the project.


Resource Capacity Settings (Project Server 2010 settings)

Published: March 31, 2011

Resource Capacity Settings is a part of the Additional Server Settings in the Operational Policies section of Microsoft Project Server 2010 Server Settings. For more information about related settings that you can configure, see Additional Server Settings (Project Server 2010 settings). For more information about Operational Policies settings, see Operational Policies (Project Server 2010 settings).

Resource Capacity Settings

Resource Capacity Settings are used to calculate your resources' availability for work over a specified time range. Your resources' capacity data for the specified time range is stored on the Reporting database, and it is updated daily through a processing job that is run at a time that you specify in the settings. You are able to set the Active capacity view by entering a time range in relative terms — months in the past, and months in the future — where the current date is a relative starting point. You can view your resources' availability for work through the Resource Center in Microsoft Project Web App.

The default Active capacity view settings are "1" month behind and "12" months ahead. This means that in the Resource Center you can view a resource's future availability for up to 12 months from the current date, and you can view utilization over the last month. By increasing the Month ahead setting, you get more capacity computed for future periods. For example, imagine that a company plans for new projects later in the year and wants to forecast the capacity for resources from 12 months to 24 months. Some customers might want to increase the Months behind value to get an accurate report of work completed in the past (for example, to account for any users who might report time long after the work is completed).

Note that increasing either value also increases the time it takes for the daily processing job to run.

To configure Resource Capacity Settings

  1. On the Server Settings page, in the Operational Policies section, click Additional Server Settings.

  2. On the Additional Server Settings page, in the Resource Capacity Settings section, for Active capacity view, enter the following:

    1. In the Months behind field, enter the number of months in the past that you want resource data to be calculated from.

    2. In the Months ahead field, enter the number of months in the future that you want resource data to be calculated from.

    3. For Scheduled time, enter the time at which you want latest resource capacity information to be processed. (The default value is 1:00 AM.)

  3. Click Save.


Resource Plan Work Day (Project Server 2010 settings)

Published: March 31, 2011

Resource Plan Work Day is a part of the Additional Server Settings in the Operational Policies section of Microsoft Project Server 2010 Server Settings. For more information about related settings that you can configure, see Additional Server Settings (Project Server 2010 settings). For more information about Operational Policies settings, see Operational Policies (Project Server 2010 settings).

Resource Plan Work Day

Resource Plan Work Day lets you specify the length of a work day ("full-time equivalents" or FTE) for all resources in your resource plan. This value can be calculated from the resource's base calendar or can be manually entered as a value.

To configure the Resource Plan Work Day setting

  1. On the Server Settings page, in the Operational Policies section, click Additional Server Settings.

  2. On the Additional Server Settings page, in the Resource Plan Work Day section, for Calculate resource full-time equivalent from, select one of the two options:

    • Resource base calendars Use this option if you want the full-time equivalents to be calculated from each resources base calendar. This is the default option.

    • Hours per day Use this option if you want to specify the full-time equivalents for your resources in the resource plan. After selecting this option, enter the value (in hours) of the standard work day for your organization. Note that this value is used for all resources in the resource plan.

  3. Click Save.


Exchange Server Details (Project Server 2010 settings)
See Also

Published: March 31, 2011

Exchange Server Details is a part of the Additional Server Settings in the Operational Policies section of Microsoft Project Server 2010 Server Settings. For more information about related settings that you can configure, see Additional Server Settings (Project Server 2010 settings). For more information about Operational Policies settings, see Operational Policies (Project Server 2010 settings).

Exchange Server Details

In Microsoft Office Project Server 2007, users can view their tasks in Microsoft Outlook by using an Outlook Add-in that had to be downloaded and installed to each user's computer. In Project Server 2010, Exchange Server can be integrated with Project Server 2010 to provide task synchronization with Outlook 2007 or Outlook 2010. For more information about how to configure task integration with Exchange Server, see the TechNet article set, Deploy Project Server 2010 with Exchange Server.

To configure the Exchange Server Details setting

  1. On the Server Settings page, in the Operational Policies section, click Additional Server Settings.

  2. On the Additional Server Settings page, in the Exchange Server Details section, click Synchronize Tasks if you want to automatically synchronize tasks from Project Server 2010 with Outlook 2007 or Outlook 2010.

  3. Click Save.

See Also

Concepts

Deploy Project Server 2010 with Exchange Server


Task Mode Settings (Project Server 2010 settings)

Published: March 31, 2011

Task Mode Settings is a part of the Additional Server Settings in the Operational Policies section of Microsoft Project Server 2010 Server Settings. For more information about related settings that you can configure, see Additional Server Settings (Project Server 2010 settings). For more information about Operational Policies settings, see Operational Policies (Project Server 2010 settings).

Task Mode Settings

Task Mode Settings let you select the default mode in which tasks are scheduled: manually or automatically. Additionally, if you select the default setting (Manually Scheduled), you can also configure if you want task to be published to team members.

Manually scheduled tasks (also known as "User-Controlled Scheduling") are new in Project Server 2010. In this mode, when a new task is created, the scheduling engine is ignored and Project Server 2010 creates the task without a duration, start date, or finish date. (These values can be entered manually.) It can be useful for scheduling tasks with hard dates that are difficult to move (for example, training).

For more information about the manually scheduled task feature, see the MSDN article, Project 2010: Introducing User-Controlled Scheduling (http://blogs.msdn.com/b/project/archive/2009/10/23/project-2010-introducing-user-controlled-scheduling.aspx).

To configure the Task Mode setting

  1. On the Server Settings page, in the Operational Policies section, click Additional Server Settings.

  2. In the Task Mode Settings section:

    1. Select Manually Scheduled tasks can be published to team members (which is enabled by default) if you want to allows project managers to publish their manually scheduled task to team members.

    2. For Default task mode in new projects, select one of the two following settings:

      • Manually Scheduled You have to enter duration, start, and finish dates for your tasks. By default, this option is selected.

      • Automatically Scheduled The scheduling engine automatically calculates durations and start dates and finish dates for your tasks.

    3. Select Users can override default in Project Professional (which is enabled by default) if you want to enable your Project Professional users to override the default task mode settings that you selected.

  3. Click Save.


Server Side Event Handlers (Project Server 2010 settings)
See Also

Published: March 31, 2011

The Server Side Event Handler settings are available through the Microsoft Project Server 2010 Server Settings page in the Operational Policies section. For more information about related administrative settings, see Operational Policies (Project Server 2010 settings).

Configure Server Side Event Handlers

Similar to Microsoft Office Project Server 2007, Project Server 2010 provides public events that enable development of custom processes such as adding and enforcing business rules, validation, data processing, notification services, and workflow. These custom processes are written as server-side event handlers by developers in an organization and can be associated to Project Server 2010 events through the Server Side Event Handlers page in Project Web App Server Settings. For example, developers in your organization can create an event handler that starts a custom workflow. Through the Server Side Event Handlers page, you can associate that event handler with the Project Published event so that a workflow starts when the event occurs.

For more information about Project Server events, see the MSDN article, Project Server Events (http://go.microsoft.com/fwlink/p/?LinkId=214597).

For more information about Project Server event handlers, see the MSDN article, How to Write and Debug a Project Server Event Handler (http://go.microsoft.com/fwlink/p/?LinkId=214598).

To associate an event handler with a server-side event

  1. On the Server Settings page, in the Operational Policies section, click Server Side Event Handlers.

  2. On the Server Side Event Handlers page, in the Events list, find the event that you want to associate your new event with, and then click the Event Source listed next to the Event Name (for example, click the Project event source for the Published event name).

    In the Event Handlers section, the Event Source and Event Name should be populated with the event that you selected. Any event handlers that are currently associated with the event appear in the Event Handlers list.

  3. Click New Event Handler.

  4. In the New Event Handler page, enter the following information for the event handler that you want to associate with the selected event:

    1. In the Display Information section, enter the event handler name. You can also optionally enter a description of the event handler.

    2. In the System Information section, in the Assembly Name field, enter the full name of the strongly named event handler assembly.

    3. In the Class Name field, enter the fully qualified name of the class that implements the event handler functionality.

    4. In the Order field, provide the order number of the event handler. If it is the only event handler associated with the event, enter 1. If there are multiple event handlers associated with the event, enter the order number in which this event handler will be executed.

  5. Click Save.

See Also

Concepts

Project Server 2010 Administrator's Guide


Active Directory Resource Pool Synchronization (Project Server 2010 settings)
See Also

Published: March 31, 2011

The Active Directory Resource Pool Synchronization settings are available through the Microsoft Project Server 2010 Server Settings page in the Operational Policies section. For more information about related administrative settings, see Operational Policies (Project Server 2010 settings).

In this article:

  • Configure Active Directory Resource Pool Synchronization

  • Enterprise Resource Pool Synchronization scenarios

  • Requirements for synchronizing the Enterprise Resource Pool with Active Directory users in a different domain

Configure Active Directory Resource Pool Synchronization

Project Server 2010 Active Directory Enterprise Resource Pool synchronization is used to create or update multiple Project Server enterprise resources at the same time. Project Server enterprise resources can also be automatically activated and deactivated based on group membership in the Active Directory directory service. For example, new employees in your department can automatically be added as Project Server enterprise resources as long as they are in the Active Directory group selected for synchronization. Conversely, employees who are removed from the Active Directory group have their Project Server accounts deactivated upon synchronization.

Enterprise Resource Pool synchronization also updates enterprise resource properties with the most current data from Active Directory. For example, an employee's name and e-mail address may change because of marriage. As long as the change is made in Active Directory and the user is in the linked group, the change occurs in the user's Enterprise Resource properties when synchronization occurs.

The Enterprise Resource Pool can be mapped to a single Active Directory group for synchronization. However, this Active Directory group can contain nested groups whose members are also synchronized.

The following actions can occur during the Enterprise Resource Pool synchronization process:

  • A new Project Server enterprise resource and corresponding user account can be created based on an Active Directory account.

  • An active Project Server resource/user account can be deactivated.

  • An existing Project Server user account's metadata (for example, name, e-mail address, and so on) can be updated if it has changed in Active Directory.

  • A previously inactive Project Server resource/user account can be reactivated.

Before you perform this procedure, confirm the following:

  • You have access to Project Server through Project Web App with an account that has the Manage Active Directory Settings, the Manage Site Services, and the Manage users and groups global settings turned on.

  • The Service Application (SA) service account for the Project Server instance has Read access to all Active Directory groups and user accounts involved in the synchronization.

    You can verify this account in the SA's properties on the Service Application Administration page on the SharePoint Central Administration Web site.

Enterprise Resource Pool Synchronization scenarios

The following table describes possible scenarios and corresponding actions that occur when Enterprise Resource Pool synchronization occurs.

Scenarios | Action
The user exists in Active Directory and is a member of the Active Directory group that is mapped to the Enterprise Resource Pool. The user does not exist in Project Server. | A new corresponding Project Server user and enterprise resource is created in Project Server and added to the Team Members Project Server security group.
The user exists in Project Server, but does not exist in Active Directory or is not a member of the Active Directory group that is mapped to the Enterprise Resource Pool. | If Prevent Active Directory synchronization for this user is not enabled for the user account in Project Server, the corresponding Project Server user account status is set to inactive. Otherwise the account will stay active.
The user exists in Active Directory and is a member of the Active Directory group that is mapped to the Enterprise Resource Pool. The user exists in Project Server as an enterprise resource and a user. The user's information has been updated in Active Directory. | The corresponding Project Server enterprise resource and user information is updated (if applicable).
The user exists in Active Directory and is a member of the Active Directory group that is mapped to the Enterprise Resource Pool. The user exists in Project Server, but as an inactive account. | If the Automatically reactivate currently inactive users if found in Active Directory during synchronization resource option is selected in Project Server, the account is reactivated. If the option is not selected, the account remains inactive in Project Server.

To configure Enterprise Resource Pool synchronization

  1. On the Server Settings page, in the Operational Policies section, click Active Directory Resource Pool Synchronization.

  2. On the Active Directory Enterprise Resource Pool Synchronization page, in the Active Directory Group section, under Active Directory Group to Synchronize, click Find Group.

  3. On the Find Group in Active Directory — Webpage Dialog page, in the Group Name field, enter all or part of the name of the Active Directory group that you want to synchronize with the Enterprise Resource Pool. Click the button next to the field to search the Active Directory forest based on your search criteria.

  4. To select a group from a remote forest, type the fully qualified domain name of the group (for example, group@corp.contoso.com). You can synchronize to a security or distribution group of any scope (Local, Global, or Universal).

    Note:

    The Active Directory forest that is searched is shown at the top of the Find Group in Active Directory — Webpage Dialog page. The forest is defined by the fully qualified domain name of the account for the service application on which the Project Server instance is running.

  5. From the Group Name list, select the group with which you want to synchronize your Enterprise Resource Pool.

  6. Click OK. When you do this, the Active Directory group membership of the selected group is put into memory. This includes all users who are members of nested Active Directory groups across domains and forests.

  7. On the Active Directory Enterprise Resource Pool Synchronization page, you should see the Active Directory group that you selected next to Active Directory Group to Synchronize: in the Active Directory Group section.

  8. If you want to configure synchronization to occur on a scheduled basis, in the Scheduling Options section, select Schedule Synchronization. Or, you can choose to manually run Active Directory Enterprise Resource Pool synchronization. If you prefer the manual option, skip the following step. Step 11 describes how to use the Save and Synchronize Now button, which allows you to manually synchronize your Enterprise Resource Pool immediately.

  9. In the Frequency fields, define the frequency at which you want synchronization to occur between the Enterprise Resource Pool and the Active Directory group. This can be scheduled over a defined period of days, weeks, or months. Select a start date and time.

  10. You can enable inactive accounts to be reactivated if they are found in the Active Directory group during synchronization. To do so, in the Resource Option section, select Automatically reactivate currently inactive users if found in Active Directory during synchronization. (For example, were you to enable this option, it would ensure that if an employee were rehired, the employee's user account would be reactivated.)

  11. Click Save to save the settings. Click Save and Synchronize Now if you want to synchronize your Enterprise Resource Pool immediately. If you decide not to schedule Enterprise Resource Pool synchronization, you can rerun it manually when you need to by returning to this page and clicking Save and Synchronize Now.

  12. You can check the status of the Enterprise Resource Pool synchronization by returning to the Active Directory Enterprise Resource Pool Synchronization page and reviewing the information in the Synchronization Status section. It contains information such as when the last successful synchronization occurred.

Requirements for synchronizing the Enterprise Resource Pool with Active Directory users in a different domain

Imagine that you need to synchronize your Enterprise Resource Pool with Active Directory users that exist in a domain other than the one that Project Server 2010 is installed on. For example, your organization may acquire a new company, or your branch may need to add users from a different branch within your organization. In this scenario, a two-way trust relationship must exist between the domains in order for Active Directory users in one domain to synchronize with the Enterprise Resource Pool in a Project Server 2010 installation that exists on a different domain.

Note:

Project Server 2010 does not support synchronizing your Enterprise Resource Pool or security groups with Active Directory users across different domains in which only a one-way trust relationship exists between domains. It is possible for Active Directory user to synchronize with SharePoint Server 2010 in a cross-forest deployment in which a one-way trust relationship exists between domains (see Resolve accounts across multiple forests (SharePoint Server 2010). However, Project Server 2010 does not support this scenario.

For more information about trust relationships in Windows Server 2008 and Windows Server 2008 R2, see Managing Trusts. For information about creating a two-way trust relationship between domains in Windows Server 2008 or Windows Server 2008 R2, see Create an External Trust.

See Also

Concepts

Manage security group synchronization with Active Directory in Project Server 2010
Test background operations (Project Server 2010)
Project Server 2010 Administrator's Guide


Project Sites (Project Server 2010 settings)
See Also

Published: March 31, 2011

The Project Sites setting is available through the Microsoft Project Server 2010 Server Settings page in the Operational Policies section. For more information about related administrative settings, see Operational Policies (Project Server 2010 settings).

Configure the Project Sites setting

Project sites were known as Project Workspaces in previous versions of Project Server. The Project Sites page in Server Settings lets you manage project sites in Project Server 2010. You can do the following through the Project Sites page:

  • Create a new project site

  • Edit a project site address

  • Synchronize

  • Delete a project site

  • Go to Project Site Settings

Create site

Create Site lets you create a new project site for your project if you did not create one when the project was originally published to Project Server 2010. You can view the Project Sites list to determine whether a project has an existing site. A project without a project site does not have a corresponding URL next to it in the Site Address column.

To create a project site

  1. On the Server Settings page, in the Operational Policies section, click Project Sites.

  2. From the Project Name list, select a project for which you want to create the project site.

  3. Click Create Site.

    The Create Project Site dialog box appears.

  4. In the Web Application list, select the Web Application that you want for the project site.

  5. In the Site URL field, verify the site URL for the project site. You can edit the site URL information, if necessary. The site URL is appended to the Web Application name to provide the destination URL (as seen in the Destination URL field).

  6. Click OK.

    The project site you created now appears next to the project name that you selected in step 2.

Edit Site Address

Edit Site Address lets you edit the destination URL for a project site to point to a new site address. Changing the site address information breaks the existing link between the project and the existing project site. You can then enter the information for the new project site.

Note:

Before changing the project site URL for a project, be sure to provision a new project site with a new site template.

To edit a site address for a project site

  1. On the Server Settings page, in the Operational Policies section, click Project Sites.

  2. From the Project Name list, select a project for which you want to edit the project site information.

  3. Click Edit Site Address.

    The Edit Site Address dialog box appears.

  4. Change the project site URL to the new URL.

  5. Click Test URL to verify whether the new project site URL can be opened.

  6. Click OK.

    The project site URL for the project you selected in step 2 is changed to the new URL.

Synchronize

Synchronize lets you manually synchronize the project site's users, permissions, and other Project Server-related information between Project Server 2010 and the Web server that is running Microsoft SharePoint Foundation 2010.

If you want to automatically run synchronization for your project sites, see the Automatic Provisioning option that is available in Project Site Provisioning Settings (Project Server 2010 settings).

To synchronize your project site information between Project Server and SharePoint Foundation

  1. On the Server Settings page, in the Operational Policies section, click Project Sites.

  2. From the Project Name list, select a project for which you want to synchronize your Project site information between Project Server 2010 and SharePoint Foundation.

  3. Click Synchronize.

    Note:

    To view a confirmation that synchronization occurred, you can view the Manage Queue Job settings in Project Web App Server Settings and verify that the synchronization job completed successfully.

Delete Site

Delete Site lets you permanently remove a project site and its content.

Important:

Before you proceed, verify that you want to permanently remove a site and its content. Deleted project sites are not recoverable.

To delete a project site

  1. On the Server Settings page, in the Operational Policies section, click Project Sites.

  2. From the Project Name list, select a project for which you want to delete a project site.

  3. Click Delete Site.

    A message box appears that asks you to confirm whether you want to delete the project site. It also warns you that you will also be deleting all documents, issues, risks, and deliverables that are associated with the site.

  4. Click OK to proceed with deleting the site. Click Cancel if you no longer want to delete the site.

  5. If you clicked OK, the project site is deleted and no longer appears next to the project it was associated with on the Project Sites page.

Go to Project Site Settings

Go to Project Site Settings lets you go directly to a Project Site's site settings page. From the Site Settings page, you can make changes to the site, such as adding or removing users, adding Web Parts to the site, customizing the site's look and feel, and many others.

To go to the Site Settings page for a project site

  1. On the Server Settings page, in the Operational Policies section, click Project Sites.

  2. From the Project Name list, select a project for which you want to view the Project Site settings page.

  3. Click Go to Project Site Settings.

  4. The Site Settings page for the selected project site opens. You can make changes to the site settings from this page.

See Also

Concepts

Project Server 2010 Administrator's Guide


Project Site Provisioning Settings (Project Server 2010 settings)
See Also

Published: March 31, 2011

Project Site Provisioning Settings are available through the Microsoft Project Server 2010 Server Settings page in the Operational Policies section. For more information about related administrative settings, see Operational Policies (Project Server 2010 settings).

Configure Project Site Provisioning Settings

The Project Site Provisioning Settings page let you configure settings for the project sites that are created for projects. You can configure the following settings:

  • Site URL

  • Default Site Properties

  • Automatic Provisioning

  • Project Site Permissions

Site URL

The Site URL settings let you change the default Web application in which your project sites are created. The default site URL information on this page is based on the information that is provided during the provisioning of the Project Web App instance.

To specify site URL information

  1. On the Server Settings page, in the Operational Policies section, click Project Site Provisioning Settings.

  2. On the Project Site Provisioning Settings page, in the Site URL section, specify a default Web application that your project sites will be created from. Select the Web application from the Default Web application menu.

  3. In the Site URL field, type the URL path (for example, PWA).

  4. Click Save.

Default Site Properties

The Default Site Properties settings let you select the default site template language and the default project site template that will be used to create your project sites.

When you select a project site template, you can only use the Microsoft Project Site template that installs with Project Server 2010 or a template that is derived from it. The Microsoft Project Site template is built to support features and functionality in SharePoint Server 2010.

Important:

Project Server 2010 and Office Project Server 2007 do not support the use of the Project Tracking Workspace template from the SharePoint Server 2010 "Fab 40" templates to create project sites. For more information, see Project Server 2010 -The Fab 40 Strikes Again! (http://go.microsoft.com/fwlink/p/?LinkId=214559) on the Microsoft Project Support Weblog.

To configure default site properties for your Project Sites

  1. On the Server Settings page, in the Operational Policies section, click Project Site Provisioning Settings.

  2. On the Project Site Provisioning Settings page, in the Default Site Properties section, select the default language for your project sites from the Default site template language drop-down list.

  3. In the Default Project Site template drop-down list, select the project site template that will be used to create your project sites.

  4. Click Save.

Automatic Provisioning

The Automatic Provisioning setting lets you indicate whether you want to have Project Server 2010 create project sites for projects when the projects are newly published to the server. Or, the settings can be configured to allow the Project Server Administrator to create project sites manually after projects have been published, if you prefer.

Note:

If you have a group of project managers who will not need to create project sites, you can set the provision mode to Allow users to manually crate project sites in Project Server as noted earlier in this section. Additionally, denying this group of users the Manage SharePoint Foundation global permission eliminates the display of a Publish Project Site dialog box that typically appears when a project is created.

To configure the Automatic Provisioning setting

  1. On the Server Settings page, in the Operational Policies section, click Project Site Provisioning Settings.

  2. On the Project Site Provisioning Settings page, in the Automatic Provisioning section, select one of the two Provisioning mode options:

    • Automatically create a project site for each project when first published to Project Server

    • Allow users to manually create project sites in Project Server

  3. Click Save.

Project Site Permissions

The Project Site Permissions setting lets you grant access to project sites in Project Server 2010. This setting lets you automatically synchronize Project Web App users with project sites in the following circumstances:

  • When project sites are created

  • When project managers publish projects

  • When user permissions change in Project Server 2010

When the Project Site Permissions setting is enabled, the following things occur automatically when any of the circumstances named in the previous list occur:

  • Project managers who have published a project or who have Save Project permissions on a project are added to the Project Managers (Microsoft Project Server) site group.

  • Team members with assignments in a project are added to the Team Members (Microsoft Project Server) site group.

  • Other Project Server users who have View Project Site permission on a project are added to the Readers (Microsoft Project Server) site group.

To enable the Project Site Permissions setting

  1. On the Server Settings page, in the Operational Policies section, click Project Site Provisioning Settings.

  2. On the Project Site Provisioning Settings page, in Project Site Permissions section, click Check to automatically synchronize Project Web App users with Project Sites when they are created, when project managers publish projects, and when user permissions change in Project Server. When the check box is cleared, Project Server users are never synchronized with project sites.

  3. Click Save.

When the check box is cleared, users are not automatically added to their respective Web sites. To add or update users to their sites, click the Synchronize button on the Project Sites page of the Operational Policies section of Project Web App Server Settings.

See Also

Concepts

Project Server 2010 Administrator's Guide


Bulk Update Project Sites (Project Server 2010 settings)
See Also

Published: March 31, 2011

Bulk Update Project Sites is available through the Microsoft Project Server 2010 Server Settings page in the Operational Policies section. For more information about related administrative settings, see Operational Policies (Project Server 2010 settings).

Configure the Bulk Update Project Sites Setting

The Bulk Update Project Sites page allows you to change site path information for project sites in one Web application to a different one (for example, when migrating). It allows you to break the original links between projects and their corresponding project sites in one site collection and then relink to the new project sites in the new site collection.

  • Update Site Paths

  • Update Content Types

  • Project Site Permissions

Update Site Paths

The Update Site Paths setting lets you break links between projects and project sites that are contained in one site collection and relink with the new project sites in a different site collection.

To update project site paths to a new site collection

  1. On the Server Settings page, in the Operational Policies section, click Bulk Update Project Sites.

  2. On the Bulk Update Project Sites page, in the Update Site Paths section, for Previous Site Path:

    1. Select the Web application for your project sites that you want to break the link to. If you are migrating project sites on the same server, the Web application that you need to select may appear as a URL. If you are migrating projects sites from a different server, the Web application you need to select may appear as a globally unique identifier (GUID).

    2. In the Site URL field, type the site URL information (for example, PWA).

  3. For New Site Path:

    1. Select the Web application that contains the project sites that you want to link to (for example, http://hr1.contoso.com).

    2. In the Site URL field, type the site URL information (for example, PWA).

  4. Click Save.

Update Content Types

The Update Content Types setting allows you to ensure that when you migrate content from one farm to another, the content types of Project Issues, Risks, and Documents are updated in the new location so that item links remain functional.

To enable the Update Content Types setting

  1. On the Server Settings page, in the Operational Policies section, click Bulk Update Project Sites.

  2. On the Bulk Update Project Sites page, in the Update Content Types section, select Update Content Types.

  3. Click Save.

Project Site Permissions

The Project Site Permissions setting allows you to synchronize permissions to the Project Sites while updating the site paths. This allows users to immediately access their project sites.

Note:

For the Project Site Permissions setting to be enabled, the Project Site Permissions setting must also be enabled on the Project Site Provisioning page.

To enable the Synchronize site permissions setting

  1. On the Server Settings page, in the Operational Policies section, click Bulk Update Project Sites.

  2. On the Bulk Update Project Sites page, in the Project Site Permissions section, click Synchronize site permissions.

  3. Click Save.

See Also

Concepts

Project Server 2010 Administrator's Guide


Workflow and Project Detail Pages (Project Server 2010 settings)

Published: January 27, 2011

When you are using the Demand Management and portfolio analysis features in Microsoft Project Web App, workflow and project detail pages have to be set up beforehand by the site administrator. Articles in this section cover the following:

  • Enterprise Project Types (Project Server 2010 settings)

  • Workflow Phases (Project Server 2010 settings)

  • Workflow Stages (Project Server 2010 settings)

  • Change or Restart Workflows (Project Server 2010 settings)

  • Project Detail Pages (Project Server 2010 settings)

  • Project Workflow Settings (Project Server 2010 settings)


Enterprise Project Types (Project Server 2010 settings)

Published: January 27, 2011

In Microsoft Project Web App, an enterprise project type (EPT) represents a wrapper that encapsulates phases, stages, a single workflow, and Project Detail Pages (PDPs). Each EPT represents a single project type. Normally, project types are aligned with individual departments: for example, marketing projects, IT projects, or HR projects. Using project types helps categorize projects within the same organization that have a similar project life cycle. For a user, the EPTs appear in a drop-down list of project types when the user clicks New Project on the ribbon in Project Web App.

Watch a video of this procedure

To create a new enterprise project type

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Workflow and Project Detail Pages section, click Enterprise Project Types.

  3. Click New Enterprise Project Type. In the Name box, enter a name for the type, and then provide a brief description in the Description box.

  4. Select a workflow from the Site Workflow Association list. Once you associate a site workflow with a project type and save the type, you cannot go back and update the type to use a different workflow.

    Note:

    If you are not seeing any workflows in this list, be sure that your server administrator has installed and configured workflows on the Microsoft Project Server 2010 computer. The Project Server 2010 workflow platform is built on the SharePoint workflow platform, which, in turn, is built on the Windows workflow platform.

  5. Select a project detail page from the New Project Page list.

  6. If you selected No Workflow from the Site Workflow Association list, select the project detail pages that you want to include in this project type from the Available Project Detail Pages box, and then click Add to move them to the box on the right.

  7. If the enterprise project type that you are creating is the one that all new projects should use by default, select the Use this as the default Enterprise Project Type during Project Creation check box.

  8. Click the button next to the Departments field to select the departments that you want to associate with this project type, if it is appropriate.

  9. If you want to associate an image with this project type, provide the URL for the image in the Type the URL box.

  10. In the Order section, choose whether you want this project type to appear at the end of the list of project types, or if you want to control its placement in the list.

  11. To include this type at the end of the list, select the Position this type at the end check box.

  12. To control the placement of this type in the list, clear the Position this type at the end check box, and then choose the type that you want to appear just before the type that you are creating from the Choose the type before which the current type should be positioned list.

  13. Select a template from the Project Plan Template list, if it is appropriate.

  14. Select a template from the Project Site Template list, if it is appropriate.

  15. Click Save to save this enterprise project type to the server, thus making it available for new project or proposal creation.


Workflow Phases (Project Server 2010 settings)

Published: January 27, 2011

In Microsoft Project Web App, a phase represents a collection of stages grouped to identify a common set of activities in the project life cycle. Examples of phases are project creation, project selection, and project management. Phases have no direct technical effect on the behavior of an Enterprise Project Type. That is, changing the order of phases does not affect how the system reacts. The main purpose of Demand Management phases is to provide a smoother user experience where users have the option of organizing stages into logical groups.

Watch a video that shows an overview of the complete process of defining the phases and stages of a project life cycle

To create a new workflow phase

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, under Workflow and Project Detail Pages, click Workflow Phases.

  3. Click the New Workflow Phase button on the toolbar.

  4. Under Name, enter the name of the desired phase, and optionally enter a description of the phase in the Description text box.

  5. Click Save.

To edit an existing workflow phase

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, under Workflow and Project Detail Pages, click Workflow Phases.

  3. Click the existing workflow phase in the Workflow Phases column that you want to modify.

  4. Under Name, change the name to the phase name that you want, and optionally enter a description of the phase in the Description text box.

  5. Click Save.


Workflow Stages (Project Server 2010 settings)

Published: April 7, 2011

A stage represents one step in a project life cycle in Microsoft Project Web App. A stage is composed of one or more Project Detail Pages linked by common logic or theme. Stages at a user level appear as steps in a project. At each step, data must be entered, modified, reviewed, or processed.

Watch a video that shows an overview of the complete process of defining the phases and stages of a project life cycle

To create a new workflow stage

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Workflow and Project Detail Pages section, click Workflow Stages.

  3. Click the New Workflow Stage button on the toolbar.

  4. Under Name, enter the name of the desired stage and optionally enter a description of the stage in the Description text box.

  5. Under Description for Submit, type the description that will be displayed to end-users when they submit the stage to the workflow. By default, this description will be displayed in the following places:

    • As a Tool Tip when users rest the pointer on the Submit button in a Project Detail Page

    • As part of the confirmation dialog box that is shown to users when they click the Submit button in a Project Detail Page

  6. Under Workflow Phase, select the Workflow Phase to correspond to this Workflow Stage.

  7. Under Workflow Stage Status Project Detail Page, select the Workflow Stage Status Project Detail Page from the drop-down list. This page is displayed as the introduction page when the project enters this workflow stage.

  8. In Visible Project Detail Pages, select the Project Detail Pages you want to be visible for this workflow stage by selecting them from the Available column and clicking the Add button to put them in the Selected Project Detail Pages column.

    Note:

    By default, no PDPs are visible for workflow stages but at least one page should be selected for a workflow stage.

  9. Under Additional Settings for the Visible Project Detail Page, you may edit the specific description of the Visible PDPs by selecting them in the right column from the previous step and then editing the description in the text box. You may also check the Project Detail Page requires attention check box to highlight the PDP on the Workflow Status page.

  10. Under Required Custom Fields, select the custom fields that are required for the Workflow to enter this Workflow Stage and then click the Add button. Take note that these Custom Fields are 'Required' only for this Workflow Stage, not for all the successive Workflow Stages in the Workflow.

  11. Under Read Only Custom, select the Custom Fields that are read-only for this Workflow Stage and then click the Add button.

  12. Under Strategic Impact Behavior, select the radio button to specify whether the strategic impact values for the project are Read Only, Read Write, or Required in this workflow stage. If Strategic Impact Behavior is set to Required then a strategic impact value has to be specified for every business driver. This is typically achieved by using the Strategic Impact Web Part on a project detail page.

  13. Under Project Check In Required select whether this Workflow Stage requires the project to be checked in. If project checkin is required for the current workflow stage, the user cannot submit the project to workflow without checking in the project. This option is typically selected if any project updates occur in this Workflow Stage (which will be blocked if the project is not checked in).

  14. Click Save.

    The Project Workflow Stage is now saved.


Change or Restart Workflows (Project Server 2010 settings)

Published: April 14, 2011

The Change or Restart Workflow section in Microsoft Project Web App enables you to change a project's in-progress workflow or change a project's current stage in a workflow.

To change or restart a workflow

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Workflow and Project Detail Pages section, click Change or Restart a Workflow.

  3. Under Choose Enterprise Project Type, select the Enterprise Project Type that needs to be changed or restarted.

  4. Under Choose Projects, select the project with the workflow instances that need to be changed or restarted, and add it to the Target List.

    Note:

    Only projects that are not checked out or are checked out to you are shown in the Choose Projects section. If a project is checked out to another user, the workflow cannot be changed or restarted on that project.

  5. Under Choose new Enterprise Project Type or restart workflow for current Enterprise Project Type, select whether to restart the current workflow for the selected projects or to associate the projects with a new Enterprise Project Type. If a new Enterprise Project Type is selected, you must then select from the drop-down menu the new Enterprise Project Type that you want to use.

  6. Under Choose Workflow Stage to Skip to, you can select the target workflow stage that this workflow will skip to.

  7. Click OK.


Project Detail Pages (Project Server 2010 settings)

Published: April 14, 2011

Project Detail Pages (PDPs) represent a single Web Part Page in Microsoft Project Web App. PDPs can be used to display or collect information from the user. You can create PDPs much as you create any Web Part Page in a SharePoint site, where you can add Web Parts that provide the experience that you want. You can add individual Web Parts from the standard Web Part galleries or create custom Web Parts.

Microsoft Project Server 2010 Web Parts and custom Web Parts used in Demand Management all contain custom fields. Web Parts can make calls to the Project Server Interface (PSI), query the Reporting database, or integrate with external systems.

There are three types of Project Detail Pages that can be created:

  • New Project Used for creating a project. This type of PDP is required with an enterprise project template that has a workflow for portfolio analysis.

  • Workflow Status Shows the current stage and status for a project proposal.

  • Project Used for editing.

To create a project detail page

  1. On the PWA home page, click Server Settings.

  2. On the Server Settings page, in the Workflow and Project Detail Pages section, click Project Detail Pages.

  3. Click the Documents tab.

  4. Select New Document on the ribbon.

  5. On the newly created blank page, select Add a Web Part.

  6. In Categories, select Project Web App, and then select the Web Part you want to add.

    The newly selected Web Part is displayed.

  7. Now you must select the project fields used to populate the web part. From the upper-right menu, select Edit Web Part.

  8. In the Edit Web Part pane, click the Modify button.

  9. Select the project data that you want the Web Part that you selected to display, and then click OK.

  10. In the Edit Web Part pane, under Appearance, enter a title and then click OK.

  11. Select the Page Tools tab on the ribbon and then click Stop Editing.

  12. Now select Edit Properties on the ribbon and update the Display Name and Page Type for your newly created Project Detail Page.


Project Workflow Settings (Project Server 2010 settings)

Published: April 14, 2011

Microsoft Project Server 2010 workflows are built from Microsoft SharePoint Server 2010 Site Workflows which are built from Windows Workflow Foundation, which in turn is built from Microsoft .NET Framework 3.5. The workflows are made up of workflow activities that are objects that have code within them.

The Project Workflow Settings page designates the Workflow Proxy User account so that the Project Server Interface (PSI) calls in a workflow can be performed. By default, all PSI calls in a workflow are made under the context of the Workflow Proxy User Account. For these PSI calls to be successful, the Workflow Proxy User Account should have appropriate permissions in Project Server. Therefore the only item to be set on this page is to make sure that the Workflow Proxy User account text box contains a logon account that has sufficient permissions.


Back up and restore databases (Project Server 2010)
See Also

Published: May 12, 2010

If your IT environment requires that your database administrator (DBA) or administrator of your SharePoint Products and Technologies deployment must back up or restore the databases associated with the Shared Services Provider (SSP), you must coordinate your backup and recovery operations with either your DBA or the administrator of the host SharePoint Products and Technologies deployment.

Task requirements

Important:

When using SQL Server 2005, the account used to back up the databases must be a member of the Microsoft SQL Server db_backupoperator fixed database role. The account used to restore the databases must be a member of the SQL Server dbcreator fixed server role.

To back up Project Server 2010 databases, see Back up databases (Project Server 2010).

To restore Project Server 2010 databases, see Restore databases (Project Server 2010).

See Also

Concepts

Back up and restore the Project Server 2010 farm


Back up databases (Project Server 2010)
See Also

Published: May 12, 2010

This article guides you through the process of backing up a Microsoft SQL Server database.

Backing up databases by using Project Server 2010 built-in tools

Important:

This method should only be used to create a full farm back up. The SharePoint Central Administration Web site is the only recommended way to perform a full farm back up or recovery.

Use this procedure to back up a database by using the SharePoint Central Administration Web site.

To back up your farm using Office Project Server built-in tools, you must use the following accounts and permissions:

  • You must be logged on to the server that runs Central Administration.

  • You must have a shared folder that you will use to store the backup files.

Important:

You must be a member of the Farm Administrators SharePoint group to complete the following procedure.

Important:

If any failures occur during the backup process, the entire process must be restarted to prevent data corruption.

Back up a database by using Central Administration

  1. In the SharePoint Central Administration Web site, on the Operations page, in the Backup and Restore section, click Perform a backup.

  2. On the Select Component to Backup page, select the check boxes for the databases you want to back up. Click Continue to Backup Options.

  3. On the Select Backup Options page, a differential backup backs up data created or changed since the last backup. If you are performing a combination of full and differential backups, restoring requires you to have the last full backup, the last differential backup, and intervening differential backups.

    • In the Backup Content section, verify that the database you selected is displayed.

    • In the Type of Backup section, select Full.

    • In the Backup File Location section, type the UNC path of the backup folder.

  4. Click OK.

    You can view the backup job status on the backup status page by clicking Refresh. The page also refreshes every 30 seconds automatically. Backup and recovery is a Timer service job, so it may take few seconds for the backup to start.

    If you receive any errors, you can find more information by looking in the spbackup.log at the UNC path you specified above.

See Also

Concepts

Migrate a Project Web App instance in Project Server 2010
Restore databases (Project Server 2010)


Restore databases (Project Server 2010)
See Also

Published: May 12, 2010

You can restore the following Project Server and Microsoft SharePoint 2010 databases:

Important:

You can only perform a full farm recovery using the SharePoint Central Administration Web site.

  • Content database

  • Draft database

  • Published database

  • Archive database

  • Reporting database

  • Databases for Service Applications)

  • Central Administration content database

  • Configuration database

    Note:

    The configuration database and the Central Administration content database contain computer-specific information. Therefore, you can restore them only to an environment that you configure to be precisely the same, including all software updates, server names, and numbers of servers. That is, you cannot back up the configuration database, change your topology or server roles, and then restore the configuration database.

For more information about using Microsoft SQL Server to restore databases, see Backing Up and Restoring Databases in SQL Server (http://go.microsoft.com/fwlink/p/?LinkID=102629&clcid=0x409).

Restoring Project Server 2010 databases

Note:

When protecting Microsoft Project 2010, we recommend that you configure a recovery farm—a second farm that is only used to restore data—for site and item recovery. The recovery farm is not intended to be a live farm. The recovery farm does not need to have the same hardware as your primary farm; we recommend that you use a single server installation or a virtual farm.

If your IT environment requires that your database administrator (DBA) must restore the databases associated with the Service Applications you must coordinate your backup and recovery operations with your DBA. The account used to restore the databases must be a member of the SQL Server dbcreator fixed server role.

Restoring a database by using built-in tools

Use this procedure to restore a database by using the Microsoft SharePoint 2010 built-in tools.

Important:

Membership in the Farm Administrators SharePoint group is the minimum required to complete the following procedure.

Restore a database by using Central Adminstration

  1. On the SharePoint Central Administration Web site, on the Operations page, in the Backup and Restore section, click Restore from Backup.

  2. On the Select Backup Location page, in the Backup File Location section, enter the universal naming convention (UNC) path to the backup folder.

  3. On the Select Backup Package to Restore page, select the backup file you want to restore, and then click Continue Restore Process.

  4. On the Select Component to Restore page, select the database you want to restore, and then click Continue Restore Process.

  5. On the Select Restore Options page:

    1. In the Restore Component section, verify that the database you selected is displayed.

    2. In the Restore Options section, select Same configuration.

      A message appears, notifying you that the current farm will be overwritten. Click OK.

    3. In the New Names section, type new names and URLs for each component, or accept the default values.

  6. Click OK.

See Also

Concepts

Back up and restore databases (Project Server 2010)
Back up databases (Project Server 2010)


Project backup and recovery (Project Server 2010)

Published: May 12, 2010

This chapter covers backup and recovery operations for Microsoft Project Server 2010.

In this section:

  • Migrate a Project Web App instance in Project Server 2010

  • Back up and restore the Project Server 2010 farm

  • Backup/RestoreTool for Server Settings (Project Server 2010)


Migrate a Project Web App instance in Project Server 2010
See Also

Published: May 12, 2010

Microsoft Project Server 2010 provides various methods for backing up, restoring, or migrating a Project Server farm, Web applications, and content databases. This article discusses the variations in those methods based on specific needs and outcomes.

Project Server migration and Project Web App provisioning methods

Provisioning Project Web App to another site

Restoring by provisioning Microsoft Project Web App to another site is the preferred method for restoring a corrupted Project Web App instance. This method involves attaching the content database at http://servername and then provisioning the Project Web App site and the four project databases to a new Project Web App site at http://servername/newpwa. Workspaces can then be re-linked to the new Project Web App site.

Storing site content in a separate database

Storing the content in a separate database involves attaching a content database to a new Project Web App site such as http://servername/workspaces, while maintaining a provisioned Project Web App site at the original location of http://servername/pwa and then relinking the workspaces.

Restoring a Project Web App site completely

This method completely restores Project Web App and the content databases to their original state by temporarily attaching the content database somewhere else, such as http://servername/else. Then you would provision the new Project Web App site at the original location, say http://servername/pwa, and then use the Windows PowerShell export command to take each site from the content database at http://servername/else. Then, using the procedure found in Back up and restore the Project Server 2010 farm, you can import all of your sites back under the newly provisioned site at http://servername/pwa. This method is the most complicated, and you should take into consideration how many Project Web App sites exist in the database that need to be exported and imported to the new Project Web App site.

Important:

Links to tasks may break when performing this procedure.

Migrating Project Server to an existing server farm

When you are migrating to an existing farm, the steps are the same as migrating to a new farm, but first you must decide if you will add your content database to one of the existing Web applications (as described above) or if you plan to add your content database to a newly created Web application.

There are a number of reasons why you might choose to create a new Web application, but perhaps the most common is that the content that you are migrating requires a different kind of authentication than is offered on the existing server. For example, imagine that the existing server is configured to authenticate Windows users but the new content requires forms-based authentication. In this case, you would need to create a new Web application. You might also need to extend your Web application, and in that case, you would also need to create a new Web application.

If you are in an extranet environment where you want different users to access content by using different domains, you might also need to extend a Web application to another Internet Information Services (IIS) Web site. This action exposes the same content to different sets of users by using an additional IIS Web site to host the same content.

Preparing to migrate a Project Server instance

If this will be the only instance or it is the first instance of Project Server 2010 to be installed on the server farm, do the following on the target server farm:

[ ] Run Setup and select the Complete Server Installation Type.

Run the SharePoint Products and Technologies Configuration Wizard:

  • [ ] Create a new farm

  • [ ] Create a new Configuration database

[ ] Configure the farm services and start the Project Application service.

Create Web applications:

  • [ ] Create a Web application for the Project Web App site content

[ ] Create the Services Application.

Note:

You can migrate the Shared Services Application database or you can create a new one.

This is a general checklist of the steps needed to prepare the server farm for migration. For more detailed information about installing Project Server 2010, see Deploy Project Server 2010 to a server farm environment.

See Also

Concepts

Move all databases (Project Server 2010)
Back up and restore databases (Project Server 2010)
Restore item-level objects by using Project Web App (Project Server 2010)


Move all databases (Project Server 2010)
See Also

Published: May 12, 2010

This article contains information and steps to move all of the databases associated with Microsoft Project Server 2010 from one database server to another database server within the same farm.

Important:

This task requires you to stop the entire farm. This will make all farm sites and assets unavailable to users until the process is complete.

This article does not provide information about how to migrate or move the Project Server 2010 farm from one group of servers to another group of servers. For more information about how to move the complete farm from one set of farm servers to another, see Migrate a Project Web App instance in Project Server 2010.

This article does not provide information about how to upgrade SQL Server 2008 on the database server. For more information about how to upgrade SQL Server 2008, see Upgrading to SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=188747) in SQL Server 2008 Books Online.

You must move the following databases associated with Project Server 2010:

  • Draft database

  • Published database

  • Archive database

  • Reporting database

  • Content database

The following are required to perform the procedures for this task:

  • You must be logged on to the server that is running the SharePoint Central Administration Web site.

  • You must have membership in the following roles in SQL Server:

    • db_backupoperator fixed database role to back up the databases.

    • dbcreator fixed server role on the destination server that is running SQL Server or an instance of SQL Server to restore the databases.

  • You must coordinate the move procedures with the database administrator (DBA). Steps that require the involvement of the DBA are signified by the prefix "[DBA]".

Procedure overview

This section summarizes the procedures that you must follow to complete the move process for all the databases associated with Project Server 2010. To see the actual procedure steps, see each procedure following the overview.

In the move process, you will use Project Server 2010 tools and SQL Server 2005 or SQL Server 2008 tools. Moving all of the databases from one database server to another database server consists of the following steps:

(In some environments, the database administrator must perform certain steps. Those steps begin with "[DBA]".)

  1. Perform a full backup of the default Shared Services Application (SSP).

  2. Completely stop the farm by stopping the services associated with Project Server 2010 and by stopping Internet Information Services (IIS).

  3. [DBA] Backing up databases on the source database server by using SQL Server tools:

    • Draft database

    • Published database

    • Archive database

    • Reporting database

    • Content database

  4. [DBA] Copying or moving the backup files to the destination database server.

  5. [DBA] Restoring databases on the destination database server by using SQL Server tools.

  6. [DBA] Copying to the destination server all of the SQL Server logins, fixed server roles, fixed database roles, and permissions for these databases.

Backing up databases on the source database server

Important:

Membership in the db_backupoperator fixed database role is the minimum required to complete this procedure.

Important:

It is important that the queue service is emptied and stopped to prevent data inconsistencies.

In some environments, the DBA must perform these steps.

Back up databases on the source database server

  1. Open Microsoft SQL Server Management Studio and connect to the database server.

  2. In Object Explorer, expand Databases.

  3. Right-click the database that you want to back up, point to Tasks, and then click Back Up.

  4. In the Back Up Database dialog box, select the type of backup that you want to perform from the Backup type list. For more information about which backup type to use, see Overview of the Recovery Models (http://go.microsoft.com/fwlink/p/?LinkId=114396) in SQL Server 2008 Books Online.

  5. Under Backup component, select the Database option.

  6. In the Backup Set section, either use the default name provided or specify a name for the backup set in the Name text box.

  7. Specify the expiration date for the backup set. This determines how long, or when, the backup set can be overwritten by any later backups with the same name. By default, the backup set is set to never expire (0 days).

  8. In the Destination section, if the correct path of the backup folder is not listed, you can add the path by clicking Add.

  9. Click OK to back up the database.

  10. Repeat steps 3-9 for each database that you want to move.

Important:

You should only back up the Draft and Published databases from the source database server.

Copying or moving the backup files to the destination database server

Important:

Read access to the shared folder on the source computer and Write access to the shared folder on the destination computer is the minimum required to complete this procedure.

In some environments, the DBA must perform these steps.

Copy or move the backup files to the destination database server

  1. In Windows Explorer, browse to the location of the .bak files for the databases.

  2. Select the .bak files for the databases that you want to move, and then either copy or move them to the destination directory.

Restoring databases on the destination database server

Important:

Membership in the dbcreator fixed server role is the minimum required to complete this procedure.

You must add the Farm Administrator account to the dbcreator fixed server role to perform this procedure. The account can be removed from the role after recovery operation is complete.

In some environments, the DBA must perform these steps.

Restore databases on the destination database server

  1. Open Microsoft SQL Server Management Studio and connect to the database server.

  2. In Object Explorer, expand the database instance.

  3. Right-click the Databases node, and then click Restore Database.

  4. In the Restore Database dialog box, under Destination for restore, type the name of the database. You must use the identical name for the database that it had on the source database server.

  5. Under Source for restore, select the From device option.

  6. In the Specify Backup dialog box, select File from the Backup media list.

  7. Click Add, and then browse to the .bak file for the database.

  8. Select the .bak file, and then click OK. Click OK again to add the path of the Restore Backup dialog box.

  9. Ensure that the backup set is selected in the Select backup sets to restore list.

  10. In the Select a page pane, click Options.

  11. In the Restore options section, select only Overwrite the existing database. Unless the environment or policies require otherwise, do not select the other options in this section.

  12. In the Recovery state section, select the RESTORE WITH RECOVERY option.

    For more information about these recovery options, see Restore Database (Options Page) (http://go.microsoft.com/fwlink/p/?LinkId=114420).

  13. Click OK to complete the recovery operation.

  14. Repeat steps 3-13 for each database that you are moving.

Copying to the destination server all of the SQL Server logins, fixed server roles, fixed database roles, and permissions for these databases

For information about how to copy SQL Server roles and permissions to the destination database server, see Microsoft Help and Support article 246133, How to transfer logins and passwords between instances of SQL Server (http://go.microsoft.com/fwlink/p/?LinkId=132636). For troubleshooting information, see Microsoft Help and Support article 240872, How to resolve permission issues when you move a database between servers that are running SQL Server (http://go.microsoft.com/fwlink/p/?LinkId=123469).

Restarting the server

Important:

Membership in the Administrators group on the local computer is the minimum required to complete these procedures.

Restart the server

  1. Restart the server that is running Project Server.

  2. In the Services snap-in, ensure that the following services are started:

    • SharePoint Server Project Server Eventing service

    • SharePoint Foundation Project Server Queue service

  3. In Internet Information Services (IIS) Manager, ensure that the following Web sites are started:

    • Office Server Web Services

    • All SSP Web sites

    • SharePoint Central Administration

See Also

Concepts

Migrate a Project Web App instance in Project Server 2010
Back up and restore the Project Server 2010 farm
Back up databases (Project Server 2010)
Restore databases (Project Server 2010)


Back up and restore the Project Server 2010 farm
See Also

Published: May 12, 2010

This document set is written to meet the requirements of information technology (IT) professionals who are responsible for the planning, design, deployment, and operations of backup and recovery solutions in enterprise, corporate, or branch office environments. The readers of this document set are expected to have an understanding of its technical details. However, service-level expertise is not needed to follow the enterprise-level discussions and to understand the decisions that are made.

A backup is a copy of data that is used to restore and recover that data after a system failure or corruption. Backups allow you to restore data after a failure. With proper backups, you can recover from many failures, including:

  • Media failure

  • User errors (such as deleting a Project file or Microsoft Project Web App (PWA) site by mistake)

  • Hardware failures (such as a damaged disk drive or permanent loss of a server)

  • Natural disasters

Additionally, keeping backups of Project Server databases is useful for routine purposes, such as copying a database from one production server to another, moving databases from a production environment to a test environment, restoring Project Web App sites, archiving for legal purposes, and disaster recovery. For specific guidance on which backup or recovery method you should use for your specific requirements, see Plan for disaster recovery in Project Server 2010 and Prepare to back up and restore a Project Server 2010 farm.

Back up and restore all or part of the farm and content

The following tasks for backup and recovery are performed to back up a Project Server farm by using built-in tools:

  • Back up a Project Server 2010 farm by using built-in tools

  • Restore a Project Server 2010 farm by using built-in tools

See Also

Concepts

Prepare to back up and restore a Project Server 2010 farm


Prepare to back up and restore a Project Server 2010 farm

Published: May 12, 2010

Before you back up project data, you must first create a shared folder on the network in which to store the data. You should also ensure that the accounts needed to perform a backup have access to the shared folder. This article and the procedures that follow cover preliminary considerations and the steps that you must take before you back up your data.

Preparation is the key to ensuring that you are backing up and can recover the data that will be needed should a failure occur. Before backing up your Project Server deployment, review your backup and recovery plan and consider the following key activities:

  • When you deploy Microsoft Project Server 2010, keep a record of the accounts that you create, and the computer names, passwords, and setup options that you choose. Keep this information in a safe place.

  • Always keep a copy of all recovery materials, documents, and database and transaction log backups at an offsite location. For more information about planning for backup and recovery, see Plan for disaster recovery in Project Server 2010.

  • Be certain that your system has adequate space to accommodate your backup. For more information about planning storage capacity, see Planning for Storage (http://go.microsoft.com/fwlink/p/?LinkId=121920&clcid=0x409) in the "Windows Server 2003 Deployment Guide."

  • Periodically perform a trial data recovery operation to verify that your files are properly backed up. A trial data recovery can uncover hardware problems that do not show up with software verifications.

  • To safeguard against loss from a catastrophic event, such as a fire or earthquake, maintain duplicate copies of your server backups in a separate location from the servers. Doing so can help protect you against the loss of critical data. As a best practice, keep three copies of the backup media, and keep at least one copy offsite in a properly controlled environment.

The following restrictions and exceptions may apply when backing up or restoring the SharePoint 2010 Products server farm:

  • Built-in tools in SharePoint 2010 Products might not back up or restore the following:

    • Any custom solutions that have been deployed

    • Alternate access mappings

    • The Web application that hosts the SharePoint Central Administration Web site

    • The Internet Information Services (IIS) metabase

    • The Central Administration content database

    • The configuration database

      Important:

      Although the configuration database and Central Administration content database can be backed up, we recommend against doing it with built-in tools on a running farm. Restoring backups of the configuration database and Central Administration content database taken from a running farm by using the tools built in to SharePoint 2010 Products or SQL Server is not supported.

      This is because data in these databases may not be synchronized with data in other SharePoint 2010 Products databases. Therefore, the tools built in to SharePoint 2010 Products do not recover these databases during a farm-level recovery operation.

      You can recover a farm, including the configuration database and Central Administration content database, in the following ways:

      • Use farm-level backups of a running farm taken with Microsoft System Center Data Protection Manager 2007 to recover an entire farm, including the configuration database and Central Administration content database. For more information, see Recover a farm (SharePoint Server 2010).

      • Restore a backup of the configuration database and Central Administration content database taken from a fully stopped farm. For more information, see Move all databases (Project Server 2010).

      If the configuration database and the Central Administration content database of a farm become unsynchronized, you must re-create both databases by using the SharePoint Products Configuration Wizard or Psconfig command-line tool.

      To protect the configuration database and the Central Administration content database:

      • Document all configuration settings and all your customizations so that you can correctly re-create the databases. For more information about recovering a farm, see Recovering your deployment in Project Server 2010.

  • Site collection backup and recovery does not support migrating a Central Administration site to a non-Central Administration site.

  • The SQL Server VSS Writer service, which is available with Microsoft SQL Server database software, must be started for the Windows SharePoint Services VSS Writer service to work properly. By default, the Windows SharePoint Services VSS Writer service is not automatically started.

  • If you want to move the backups that you created by using SharePoint 2010 Products to another location, be sure to copy and move the entire backup folder and not the individual backup folders under this folder.

  • If you want to schedule backups, you can use the Windows Task Scheduler to run them by using Windows PowerShell.

    Important:

    Do not modify the spbackup.xml file. Doing so can corrupt your backup or restored farm and make it unrecoverable.

  • If you use Central Administration to back up, you cannot use other methods to restore, such as Microsoft SQL Server 2005 or Microsoft SQL Server 2008 tools.

  • If you perform a backup while any task that creates or deletes databases is running, these changes might not be included in the backup.

  • You should maintain a separate backup of all your custom solutions.

  • SQL Server does not support performing a backup to mapped drives, shares that end in "$" on remote computers, or IP addresses.

  • Backing up the Service Application does not back up the global search settings.

Task requirements

The following components are required to perform the procedures for this task:

  • Microsoft Project Server 2010 must be installed. For more information about installing Project Server 2010, see Deploy Project Server 2010 to a server farm environment.

  • The accounts listed in the following table must be enabled to do backup and recovery.

    Account Description

    SQL Server service account (MSSQLSERVER)

    If the Local System account is used for this service account, and if the shared folder is on another computer, you must give the computer that is running SQL Server Change and Read permissions to the shared folder. Alternatively, you can specify a domain user account and give that account permissions to the shared folder.

    A local administrator's account

    To perform backup and recovery by using Windows PowerShell, you must be logged on as a member of the Administrators group on the computer that holds Windows PowerShell.

    The SharePoint Central Administration application pool identity account in Internet Information Services (IIS)

    This application pool identity account is required to do backup and recovery when you use Central Administration. Therefore, the security account for this application pool must have Change and Read permissions to the shared folder that contains the backup data.

  • If you have changed the farm account, before you back up, you must grant the new account the correct permissions to the shared folder that will contain your backup data.

  • If you are backing up by using Central Administration, the database server's SQL Server account, the Timer service account, and the Central Administration application pool identity account must have Write permissions to the backup locations. If you are using Windows PowerShell, the account that you use to log on must have Write permissions to the backup locations.

  • The database server and farm server being backed up must be able to connect to one another.

Creating a shared folder on the network

Use this procedure to create a shared folder on the network that can receive and hold backed-up data. You can also use this shared folder when you restore data. If you already have a shared folder that serves this purpose, you do not need to perform this procedure. By performing the following procedure, you ensure that you can access the shared folder from the computer that runs Microsoft SQL Server database software and from the computer that hosts the SharePoint Central Administration Web site.

Important:

Membership in the Administrators group on the computer on which the shared folder is located is the minimum requirement to complete this procedure.

Create a shared folder on the network

  1. If you create the shared folder on a computer other than the one running SQL Server, ensure that the service account for SQL Server (MSSQLSERVER) is using a domain user account. For information about accounts in SQL Server, see the following resource:

    • SQL Server Books Online (http://go.microsoft.com/fwlink/p/?LinkId=83543)

  2. On the server on which you want to store your backup data, create a shared folder.

  3. On the Sharing tab of the Properties dialog box, click Permissions, and then add the following accounts:

    • SQL Server service account (MSSQLSERVER)

    • The SharePoint Central Administration application pool identity account.

  4. Select Allow for the Change and Read permissions, and then click OK.

  5. On the Security tab of the Properties dialog box, grant all the permissions except Full Control to the accounts listed in step 3, and then click OK.

Preparing to restore

You should be aware of the following before beginning to restore:

Important:

Although the configuration database and the Central Administration content database can be backed up, we recommend against doing it with built-in tools on a running farm. Restoring backups of the configuration database and the Central Administration content database taken from a running farm by using the tools built in to SharePoint 2010 Products or SQL Server is not supported.

This is because data in these databases may not be synchronized with data in other SharePoint Server 2010 or SharePoint Foundation 2010 databases. Therefore, the tools built in to SharePoint 2010 Products do not recover these databases during a farm-level recovery operation.

If this data is not synchronized, users might experience various random errors.

You can recover a farm, including the configuration database and the Central Administration content database, in the following ways:

  • You can use farm-level backups of a running farm taken with System Center Data Protection Manager to recover an entire farm, including the configuration database and the Central Administration content database. For more information, see Recover a farm (SharePoint Server 2010).

  • You can restore a backup of the configuration database and the Central Administration content database taken from a fully stopped farm. For more information, see Move all databases (Project Server 2010).

If the configuration database and the Central Administration content databases of a farm become unsynchronized, you must re-create both databases by using the SharePoint Products Configuration Wizard or Psconfig command-line tool.

To protect the configuration database and the Central Administration content database:

  • Document all configuration settings and all your customizations so that you can correctly re-create the databases. For more information about recovering a farm, see Restore a Project Server 2010 farm by using built-in tools.

  • Consider a redundancy solution, such as clustering or mirroring, for the computer running SQL Server that is hosting the configuration database.

  • Project Server 2010 does not support a backup made from one version to be restored to another version of Project Server 2010. To do this, use the upgrade process.

  • If you are restoring by using the SharePoint Central Administration Web site, then the database server's SQL Server account, the Timer service account, and the Central Administration application pool account must have Read permissions to the backup locations.

  • If you are using Windows PowerShell, the account you logged on with must have Read permissions to the backup locations.

  • If the crawl-related account's credentials have changed between the time you backed up and the time you restore, you must reenter all crawl-related passwords after a restore is performed. This includes the password of the default content access account and each of the include crawl rules that has credentials.

  • Before restoring a service application on a stand-alone installation, the administrator must manually start the Microsoft SharePoint Service Application Administration service so that search can be provisioned. This service is required to create the search directories on the local server. These directories hold the search index files.

  • On stand-alone installations, you must restart the Timer service before restoring the service application.

  • If you are restoring or migrating search services and indexes to a new installation, make sure the search service is running before performing the recovery.

    After restoration, search might take up to 15 minutes to be available again.

  • Make sure that the synchronization service is paused before restoring any Web applications.

  • Be aware that you cannot perform more than one recovery from the same backup at the same time.


Back up a Project Server 2010 farm by using built-in tools
See Also

Published: May 12, 2010

There are two methods you can use to back up data for Microsoft Project Server 2010 by using SharePoint 2010 Products:

  • You can use the SharePoint Central Administration Web site to back up Project Server 2010. This tool allows you to perform backups from the user interface. When you use this method, you can back up the server farm, Web applications, and any or all of the content databases in your server farm. You can use Windows PowerShell 2.0 to view backup and recovery history and to view backup and recovery job status.

  • You can use Windows PowerShell to back up the server farm, Web applications, and any or all of the content databases in your server farm. You can use Windows PowerShell to view backup and recovery history and to view backup and recovery job status. This method of backing up and restoring data does not require SQL Server tools. However, you must still be an administrator on a server computer that has Project Server 2010 installed in order to perform this method of backing up and restoring.

We recommend that you regularly back up the complete farm by backing up both the configuration and content. Regularly backing up the farm reduces the possibility of data losses that might occur from hardware failures, power outages, or other problems. It is a simple process and helps to ensure that all the farm data and configurations are available for recovery, if that is required.

Performing a backup does not affect the state of the farm. However, it does require resources and might slightly affect farm performance when the backup is running. You can avoid performance issues by backing up the farm during hours when farm use is lowest, such as outside office hours.

Use Central Administration to back up a Project Server farm

Important:

To perform this procedure, you must be a member of the Farm Administrators group on the computer that is running Central Administration.

To back up a Project Server farm by using Central Administration

  1. In Central Administration, on the Home page, in the Backup and Restore section, click Perform a backup.

  2. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the farm from the list of components, and then click Next.

  3. On the Start Backup — Step 2 of 2: Select Backup Options page, in the Backup Type section, select either Full or Differential.

    Note:

    If you are backing up the farm for the first time, you must use the Full option. You must perform a full backup before you can perform a differential backup.

  4. In the Back Up Only Configuration Settings section, click Back up content and configuration settings.

  5. In the Backup File Location section, type the UNC path of the backup folder, and then click Start Backup.

  6. You can view the general status of all backup jobs at the top of the Backup and Restore Status page in the Readiness section. You can view the status for the current backup job in the lower part of the page in the Backup section. The status page updates itself every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the backup to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Spbackup.log file at the UNC path that you specified in step 5.

Use Windows PowerShell to back up a Project Server farm

You can use Windows PowerShell to back up your Project Server 2010 farm manually or as part of a script that can be run at scheduled intervals.

To back up a Project Server farm by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Backup-SPFarm -Directory<BackupShare>-BackupMethod [full/incremental]

    -Directory specifies the Universal Naming Convention (UNC) path of the backup folder.

    Note:

    If you are backing up the farm for the first time, you must use the full option. You must perform a full backup before you can perform a differential backup. To view the progress of the backup operation, use the -Verbose parameter.

    If you do not use the -Verbose parameter, the Command Prompt window displays no message if the operation succeeds. If the operation does not finish successfully, the Command Prompt window displays an error message, such as the following.

    Copy Code
    Backup-SPFarm:  The backup job failed. For more information,
see the error log that is located in the backup directory.
At line: <line> char:<column>.
+ <cmdlet> <<<< <location of error>
    Note:

    The error message is displayed even if the backup task finished, but resulted in at least one warning or error message. The summary of the backup job is listed at the end of the Spbackup.log file. The summary contains specific details about the errors in the Spbackup.log file.

  6. If there are errors or warnings, or if the backup does not finish successfully, review the Spbackup.log file in the backup folder.

For more information, see Backup-SPFarm.

Note:

We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

See Also

Concepts

Prepare to back up and restore a Project Server 2010 farm


Restore a Project Server 2010 farm by using built-in tools
See Also

Published: May 12, 2010

Microsoft Project Server 2010 provides two methods for restoring a server farm, Web applications, and content databases. Restoring by using the SharePoint Central Administration Web site offers the convenience of working from the user interface, while restoring by using Windows PowerShell 2.0 offers a wide range of parameters and allows automation of your recovery process.

Before restoring your farm, ensure that the following requirements are met.

  • To restore your farm by using the SharePoint Central Administration Web site, the database server's Microsoft SQL Server account, the Timer service account, and the Central Administration pool account must have Read permissions to the backup locations. (The Timer service account and the Central Administration pool account are generally the same.)

Consider the following before restoring your farm:

  • Restoring from one version of SharePoint Products and Technologies to a different version is not supported. For information about migrating, see Migrate a Project Web App instance in Project Server 2010.

  • After recovery, Search might take up to 15 minutes to be available again and could take longer if Search has to re-index all of the content. To avoid having Search do a full search and re-index, you can back up and restore the entire Service Application node.

  • You cannot perform more than one recovery from the same backup at the same time. Moreover, you can only perform one recovery or one backup operation at a time.

Use Central Administration to restore a Project Server farm

To perform this procedure, you must be a member of the Farm Administrators group on the computer that is running Central Administration.

To restore a farm by using SharePoint Central Administration

  1. In Central Administration, on the Home page, in the Backup and Restore section, click Restore from a backup.

  2. On the Restore from Backup — Step 1 of 3: Select Backup to Restore page, from the list of backups, select the backup job that contains the farm backup, and then click Next.

    Note:

    If the correct backup job does not appear, in the Current Directory box, enter the UNC path of the correct backup folder, and then click Update.

  3. On the Restore from Backup — Step 2 of 3: Select Component to Restore page, select the check box that is next to the farm, and then click Next.

  4. On the Restore from Backup — Step 3 of 3: Select Restore Options page, in the Restore Component section, ensure that "Farm" appears in the Restore the following content list.

    In the Restore Only Configuration Settings section, ensure that the Restore content and configuration settings option is selected.

    In the Restore Options section, select the Type of Restore option. Use the Same configuration setting unless you are migrating the farm or using a recovery farm. If you select this option, a dialog box appears that asks you to confirm the operation. Click OK.

    Note:

    If the Restore Only Configuration Settings section does not appear, then the backup that you selected is a configuration-only backup. You must select another backup.

    Click Start Restore.

  5. You can view the general status of all recovery jobs at the top of the Backup and Restore Status page in the Readiness section. You can view the status for the current recovery job in the lower part of the page in the Restore section. The status page updates itself every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the recovery to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Sprestore.log file at the UNC path that you specified in step 2.

Use Windows PowerShell to restore a Project Server farm

You can use Windows PowerShell to restore a Project Server 2010 farm.

To restore a Project Server farm by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Restore-SPFarm -Directory<BackupShare>-RestoreMethod [new/overwrite]

    Note:

    If you are not logged on as the Farm account, you will be prompted for the Farm account's credentials.

    To restore to the same farm, use the -RestoreMethod Overwrite parameter. To restore to a different farm, such as a recovery farm, use the -RestoreMethod New parameter. To view the progress of the operation, use the -Verbose parameter.

  6. If you do not use the -Verbose parameter, the Command Prompt window displays no message if the operation succeeds. If the job does not finish successfully, the Command Prompt window displays an error message, such as the following.

    Restore-SPFarm:  The job failed. At line: <line> char:<column>.+ Restore-SPFarm <<<< <Error Message>

  7. If there are errors or warnings, or if the job does not finish successfully, review the Sprestore.log file in the backup folder.

For more information, see Restore-SPFarm.

Note:

We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

See Also

Concepts

Prepare to back up and restore a Project Server 2010 farm


Backup/RestoreTool for Server Settings (Project Server 2010)

Published: September 16, 2010

The Microsoft Project Server 2010 Server Settings Backup/Restore tool is part of the Microsoft Project Server 2010 Resource Kit (PRK). It enables Project Server 2010 administrators to back up server settings from a selected Project Server 2010 instance to an XML or binary .playbook file. The tool can then restore the server settings to another Project Server 2010 instance. The data from the exported XML (or binary) file is what is imported to the target Project Server 2010 instance. This tool can be especially useful when you move server settings from a test to a production environment, but could also be used to generate a simple "playbook" of custom fields and views (for example, for different industries).

You can access the Project Server 2010 Server Settings Backup/Restore tool by downloading the Project 2010 PRK from the Microsoft Download Center.

Note:

You should import server settings only from sources that you trust.

Requirements

The Server Settings Backup/Restore tool has the following usage requirements:

  • Windows 7, Windows XP, Windows Vista, Windows Server 2003, or Windows Server 2008

  • Microsoft .NET Framework 2.x or 3.x

  • Administrator permissions on the instance of Project Server 2010 that you are accessing

  • You are migrating settings either from a Project Server 2010 site to another Project Server 2010 site, or from a Project Server 2010 upgraded site (running in Backward Compatibility Mode) to a full Project Server 2010 site.

    Note:

    When moving from an upgraded site to a full site, notice that Enterprise Global will be unable to be restored.

  • For most settings, you can back up and restore settings to Project Server instances without running the Project Server 2010 Server Settings Backup/Restore tool on the computer that is hosting that instance. However, for certain Workflow settings (see the Server Settings section), you must be on the server computer that is hosting the Project Server 2010 instance to run either a backup or a restore process by using the tool. If the Project Server 2010 Server Settings Backup/Restore tool is not run from a server computer for the Workflow Settings, then you may see an error message that resembles the following:

    ERROR: Could not load file or assembly 'Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified.
    Note:

    Do not alter a server manually during a backup or restore process, and do not run multiple instances of the Project Server 2010 Server Settings Backup/Restore tool at the same time. Either of these actions could lead to unwanted server alteration or data corruption.

Backing up server settings

The first step in using the Project Server 2010 Server Settings Backup/Restore tool is to save the server settings of the Project Server 2010 instance that you want to back up. These server settings are restored to a different Project Server 2010 instance later.

To back up server settings

  1. Run Playbooks.exe to start the Project Server 2010 Server Settings Backup/Restore tool.

  2. On the Select Server URL page, enter information about the Project Server 2010 instance from which you want to back up server settings.

    Playbook Select Server URL page

    1. In the Server URL box, type the URL of the instance of Project Server 2010 from which you want to back up the server settings. By default, the URL is the name of the server on which you run the tool and targets the default PWA instance. Replace the default information if it is incorrect.

    2. Click either Use Windows Authentication or Use Forms Authentication to specify the authentication mode with which you are connecting to Project Server 2010. If you select Use Forms Authentication, type the user name and password in the corresponding text boxes. Click OK.

      Note:

      If Project Server 2010 is configured for "multi-authentication" (Windows and forms-based authentication on the same URL), then you can only log on by using the Forms Authentication option.

  3. On the Playbooks - Project Server Settings Backup/Restore page, click the Backup tab.

    Playbook Backup tab

    1. In the File Name box, type a path and name of the backup file that you are creating to which you are exporting the server settings information. (By default, it is saved as an .xml file, but it can also be set to a binary .playbook file.) You can also use the Browse button to select a path.

    2. The read-only Source Server box shows you the URL of the server that you are currently connected to.

    3. In the optional Description box, type information about your backup.

    4. In the Settings list, you see a list of available server settings. Select the settings that you want to save from your server to the backup file.

    5. After you have finished selecting the settings that you want to save to the backup file, click Backup. A dialog box displays the status of the backup process.

  4. The Backup Server Settings message box appears, stating whether the backup was successful. If your backup was successful, the backup file is created in the file location that you specified. If the backup was unsuccessful, click View Log to view the log file of the backup to determine where a problem occurred. Click OK to close the message box. By default, the log file is located in the same folder where the Playbooks.exe file is found.

    Note:

    It is the responsibility of the user to manually delete XML or .playbook files that you no longer need. The tool does not manage the cleanup of these files.

Restore server settings

After you save your Project Server 2010 server settings, you can now use the Project Server 2010 Server Settings Backup/Restore tool to restore them to a different server farm.

Note:

To ensure successful restoration of your server settings, make sure that all enterprise objects (such as Custom Fields, Lookup Tables, and Calendars) are checked in to the restored PWA instance prior to the restoration process. You can use the Force Check-In Enterprise Objects setting in the Server Settings section of the Microsoft Project Web App site to force a check-in of all checked-out enterprise objects.

To restore your server settings

  1. Run Playbooks.exe to start the Server Settings Backup/Restore tool.

  2. On the Select Server URL page, in the Server URL box, type URL of your instance of Project Server 2010. By default, the URL uses the name of the server on which you run the tool, and it targets the default PWA instance.

  3. Also on the Select Server URL page, click either Use Windows Authentication or Use Forms Authentication to specify the authentication mode with which you are connecting to Project Server 2010. If you select Use Forms Authentication, type the user name and password in the corresponding boxes. Click OK.

    Note:

    If Project Server 2010 is configured for "multi-authentication" (Windows and forms-based authentication on the same URL), then you can only log on by using the Forms Authentication option.

  4. On the Playbooks - Project Server Settings Backup/Restore page, click the Restore tab.

    Playback tool Restore page

    1. In the File Name box, click the Open File button to browse to and select your server settings backup file. The Description and Settings boxes will be populated after the backup file is selected.

    2. In the read-only Destination Server box, view the URL of the server which you are currently connected to. To connect to a different server, you may click Change Server URL on the File menu of the dialog box. The read-only Description box contains information about the server-settings backup file, including source server name, version, build, revision, playbook version, date created, and description information.

    3. The Settings list shows all server settings options that were saved to the backup file. (These settings are selected). You can choose to restore all server settings that were backed up, or to restore specific server settings by clearing any checked items.

      Note:

      Refer to the Server Settings section for a complete list of Project Server 2010 server settings.

    4. In the Strategy section, you can choose whether to merge or replace the server settings on the new Project Server instance with the backed-up server settings.

      • Merge: This option is typically used when you are moving from one test environment to another to collect the list of settings that you want. An example of a merge going from the backup file to the target server and its result is shown here:

        Backup file Target Server Result

        View A

        View C

        View A

        View B

        View B

        View C

        In this table, the Backup file contains Views A and B from the initial Project Server 2010 instance. Selecting the Merge option results in the new Project Server 2010 instance that contains the views from the Backup file (Views A and B). It also contains the existing views that were on the Project Server 2010 instance to which the backup file was restored (View C).

      • Replace (where it is possible): Use this option when the data in the backup file takes precedence over the data in the target server. This could be used when you are rolling out data from a test environment to a deployment where the items in the backup file represent the final status of the server. The example here shows what happens when you do a replace operation:

        Backup file Target Server Result

        View A

        View C

        View A

        View B

        View B

        In this table, all existing views on the target server on which the Backup file is restored (View C) are replaced by the views contained in the backup file (Views A and B).

        Note:

        Custom Fields, Lookup Tables, and Security Categories use the merge strategy.

  5. After making your selection, click Restore. A dialog box displays the status of the recovery process.

  6. The Restore Settings message box appears, stating whether the restoration was successful. If your restoration was successful, click OK to exit the message box. If your restoration was unsuccessful, click View Log to view the log file to determine where a problem occurred.

    Note:

    In the restore process, settings with multiple fields (such as custom fields, lookup tables, and so on) validate with the server one-by-one. However, they are updated to the server as a batch at the end of the restoration of that setting. Therefore, if a restore process fails in the middle of the custom fields setting, no custom fields are updated on the destination server.

Server Settings

The following is a list of Project Server 2010 server settings that can be backed up or restored.

Operational policies

Additional Server Settings

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/ServerConfig.aspx

Alerts and Reminders

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/Notification.aspx

Server-Side Event Handler Configuration

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/Events.aspx

Project Workspace Provisioning Settings

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/WorkspaceProvisioningSettings.aspx

Note:

The Project Server 2010 Server Settings Backup/Restore tool does not back up any "Site URL" information from the Project Workspace Provisioning Settings.

Time and task management

Time Reporting Periods

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/TimePeriod.aspx

Time Reporting Periods always take a replace approach, regardless of which recovery method is selected, to avoid period conflicts.

If a Time Reporting Period has a Timesheet associated to it, it cannot be deleted. Therefore,, if the destination server has a Time Reporting Period with a Timesheet associated to it, the restoration of Time Reporting Periods fails.

Timesheet Classifications

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/LineClass.aspx

Timesheet Settings and Defaults

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/TSSettings.aspx

Administrative Time

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/AdmTime.aspx

Task Settings and Display

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/Statusing.aspx

Database administration

OLAP Database Management

http://<ServerName>/<PWASite>/_layouts/pwa/CubeAdmin/CubeGenAdmin.aspx

Look and Feel

Quick Launch

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/SiteMap.aspx

Views

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/ViewsMain.aspx

Enterprise data

Custom Fields and Lookup Tables

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/CustomizeFields.aspx

Custom Field restoration for Playbooks is not case-sensitive, but on Project Server, Custom Fields are case-sensitive. If you have two Custom Fields with the same name but in a different case setup, change the name of one of these Custom Fields if you want both on the destination server.

Enterprise Global

Backs up the Enterprise Global. The E-Global binary is persisted within the XML file.

Enterprise Calendars

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/Admin/CalendarsMain.aspx

Enterprise base calendars; resource calendars are separate.

Security

Groups

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/ManageGroups.aspx

Because only group setting information is restored, this setting does not persist any user information in the groups.

Categories

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/ManageCategories.aspx

Because only category setting information is restored, this setting does not persist any user information in the groups.

Security Templates

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/ManageTemplates.aspx

Project Web Access Permissions

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/OrgPermissions.aspx

Workflow

Enterprise Project Types

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/Admin/EnterpriseProjectTypes.aspx

As Enterprise Project Types (EPTs) depend on Project Detail Pages (PDP), they must follow the same rules as PDPs noted later in this article.

If you are migrating EPTs that belong to departments, you must also migrate Custom Fields for that EPT to be restored on the destination server.

Workflow Phases

http://<ServerName>/<PWASite>/_layouts/pwa/WorkflowPhases.aspx

Workflow Stages

http://<ServerName>/<PWASite>/_layouts/pwa/WorkflowStages.aspx

Workflow Stages depend on PDPs, and they must follow the same rules as PDPs described here.

Project Detail Pages

http://<ServerName>/<PWASite>/Project Detail Pages/Forms/AllItems.aspx

Project Detail Pages can only be accessed by the Project Server 2010 Server Settings Backup/Restore tool if the PWA instance being connected to is located on the computer on which the tool is running. This means three things:

  1. In order to back up and restore PDPs, the tool must be run locally first on the computer that is hosting the server to be backed up.

  2. The created .xml or .playbook backup must be sent to the computer that is hosting the server to receive the restore.

  3. the tool must be run locally on the computer that is hosting the restored-to server in order to run the restore process.

Claims-forms servers cannot access PDPs because of limitations intrinsic to Microsoft SharePoint Server 2010. If you are migrating settings to or from a claims-forms server, please notice that most of the workflow settings will be unable to be migrated.

The account that is used to log on to Project Server 2010 must also have read/write permission to the SharePoint content database, and it must also be a site administrator. The recommended approach is to use the default PWA site administrator account.

If you restore PDPs to a site that shares the same content database as the site that was backed up, the process may fail. In the ULS log, you will see an error message that resembles: Violation of UNIQUE KEY constraint 'Docs_IdLevelUnique'. This occurs because each PDP in the content database must be unique. If you back up from one site and restore to another site in the same database, the same restored PDP will have the same GUID as one that already exists in the database.

Workflow Proxy User

http://<ServerName>/<PWASite>/_layouts/pwa/Admin/WorkflowSettings.aspx

This is the name of the account that acts as the proxy user for workflow execution.

During the recovery process, the physical account associated with the Workflow Proxy User must exist on the destination server. The restore process will not create the account but only creates the link from the server setting to the physical account.


Database maintenance plans for Project Server 2010

Published: June 28, 2011

This article contains information and guidelines for maintaining the databases that host Microsoft Project Server 2010. It describes and provides examples of the database maintenance tasks that we recommend when you are using Project Server 2010.

This document provides detailed examples for Microsoft SQL Server 2008 R2. External references for how to perform the same database maintenance tasks with Microsoft SQL Server 2008 are also included.

Before you implement any database maintenance tasks or modify your Project Server 2010 or Microsoft SharePoint Server 2010 databases, read Database maintenance for SharePoint Server 2010.

A well-defined database maintenance plan and process are necessary for the smooth operation of Project Server 2010 and SharePoint Server 2010 databases. This document describes the key concepts, database maintenance tasks supported for Project Server 2010 databases, and best practices.

Broadly, the recommended database maintenance tasks for Project Server 2010 databases include the following:

  • Checking database integrity

  • Defragmenting indexes by either reorganizing them or rebuilding them

  • Setting the fill factor for a server

  • Monitoring database size to determine whether to grow or shrink databases

If your organization wants the simplest possible database maintenance plan, we recommend that you use a default Microsoft SQL Server maintenance plan. For more information, see Maintenance Plan Wizard (http://go.microsoft.com/fwlink/p/?LinkId=221722) in SQL Server Books Online.

To help you create a database maintenance plan for your Project Server 2010 deployment, consult the following articles in this section:

  • Overview of Project Server 2010 databases

  • Creating maintenance plans for Project Server 2010 databases

  • Defragmenting indexes for Project Server 2010 databases

  • Shrinking databases in Project Server 2010

  • Monitoring maintenance plans for Project Server 2010


Overview of Project Server 2010 databases

Published: June 28, 2011

When defining a database maintenance plan, you must understand where Microsoft Project Server 2010 stores data. Project Server 2010 data is partitioned into five databases in Microsoft SQL Server:

Database Purpose Usage pattern

Archive

Used to store online backups of data from the rest of the site.

Light usage.

Draft

Contains tables for editing unpublished projects from Microsoft Project Professional 2010 and the Project Server Interface Web services. Project data in the Draft database cannot be accessed by using Microsoft Project Web App. This database also hosts the tables that are used by the Project Queue.

Light usage.

Published

Contains all of the published projects. Published projects are visible in Project Web App. The Published database also contains tables that are specific to Project Web App (timesheets, models, views, and so on), and global data tables (which contain resources, custom fields, security definitions, and other metadata). This database also hosts the tables that are used by the Timesheet Queue.

Most frequently accessed by direct user interaction: expect usage to follow user behavior patterns such as time spikes based on user work hours and procedural deadlines.

Reporting

Contains the same data as the Published database, but optimized for generating reports and online analytical processing (OLAP) cubes. Data in the Reporting database is updated almost in real-time, is comprehensive, and is optimized for read-only report generation.

Two main sources of load:

  • Populated more constantly (proportional to published usage) and may have a large, unpredictable ad-hoc load.

  • Off-hours burst load because of subscription push reporting.

Experiences rapid log-file growth.

SharePoint Content database

Contains project site content such as custom pages, workflows, management settings, documents, and lists of issues, risks, and commitments.

Light usage.

Note:

If the content database is shared with Microsoft SharePoint Server 2010, then usage may vary depending on SharePoint Server 2010 usage.

For additional information about Project Server 2010 architecture, see Project Server 2010 Architecture (http://go.microsoft.com/fwlink/p/?LinkId=221724) in the Project 2010 SDK on the MSDN Library Online.


Creating maintenance plans for Project Server 2010 databases

Published: June 28, 2011

If you are unfamiliar with Microsoft SQL Server operational best practices and want to begin to use SQL Server quickly and safely, then we recommend adoption of SQL Server maintenance plans. These are designed specifically for smaller application implementations where the benefits of having something quick and easy outweighs the control given by designing custom maintenance schemes.

If your organization has staff trained in supporting SQL Server applications, these staff are most ideally suited to design the operational schedule based on the service levels demanded by the organization.

Many of the database maintenance operations covered in this document can be programmatically applied through the implementation of SQL Server maintenance plans. Maintenance plans can both automate and schedule necessary tasks to protect your data. By using maintenance plans in Microsoft SQL Server 2008 or Microsoft SQL Server 2008 R2, an administrator can schedule such operations as running database consistency checks, reorganizing or rebuilding indexes, and shrinking databases to reclaim unused space. For more information, see the following resources:

  • Maintenance Plan Wizard (http://go.microsoft.com/fwlink/p/?LinkId=221726) for SQL Server 2008

  • Maintenance Plan Wizard (http://go.microsoft.com/fwlink/p/?LinkID=221722) for SQL Server 2008 R2

When creating a database maintenance plan for your Microsoft Project Server 2010 deployment, consider the following best practices:

  • Ensure that you have reliable backups for all databases before you implement maintenance operations and maintenance plans.

  • Before you implement consistently running maintenance operations or a maintenance plan, test the effect of the operations on the system and the time that is required to run them.

  • As much as possible, set any maintenance operations or maintenance plans to run during off-hours to minimize the performance effect on users.

If you have an environment that has ten or more content databases or more than 250 GB of content, we recommend that you configure separate maintenance plans to provide appropriate specificity and to maximize the maintenance window.

When you are creating a maintenance plan using the Maintenance Plan Wizard, we recommend the following best practices:

  • A maintenance plan should include either index reorganization or index rebuilding, not both.

  • To determine the duration of each task, test each task individually before combining tasks into a single plan. You may have to define several maintenance plans on separate schedules to enable tasks to finish during hours when end-user operations will not be adversely affected.

  • Always begin with the database integrity check. If the integrity check fails, do not perform the remaining tasks. Instead, repair the suspect database.

  • To maintain a sustainable and stable SharePoint 2010 Products deployment, content databases are the only databases that you should shrink. (Deletion is most common in content databases.) Shrinking the configuration database, Central Administration content database, SSP databases, and Search databases is unnecessary and can lead to fragmentation.

  • When configuring database shrinking, set the database to shrink when it reaches 20 percent more than the maximum size that you want your content databases to grow. For example, if you have established a database architecture that allows up to 100 GB for each content database, set this value to 120 GB.

  • Retain 10 percent of free space after a database shrink operation. Setting this value can help reduce fragmentation when you have scheduled frequent shrinking.

  • When rebuilding an index, set the free percentage per page to 70 percent. This sets the fill factor for the database.

More complex maintenance plans are best implemented in SQL Server Integration Services. It provides the same maintenance task options as SQL Server maintenance plans with the option to add event handlers, integrate with outside systems such as workflow or Operations Management systems, specify complex conditional execution, and use variables to store state.


Defragmenting indexes for Project Server 2010 databases

Published: June 28, 2011

Database maintenance tasks can be performed by either executing Transact-SQL commands or running the Database Maintenance Wizard. This article contains details on both the approaches.

The recommended database maintenance tasks for Microsoft Project Server 2010 databases include the following:

  • Checking database integrity

  • Defragmenting indexes by either reorganizing them or rebuilding them

  • Setting the fill factor for a server

  • Monitoring the database size to pre-grow the database or to shrink databases

  • Cleaning up the history

  • Updating Statistics

Defragmenting indexes by reorganizing or rebuilding

Fragmentation occurs when the logical and physical storage allocation of a database contains many scattered areas of storage that are insufficient, not physically contiguous, or have become too fragmented to be used efficiently. Fragmentation can be the result of many inserts, updates, or deletes to a table. When a table becomes fragmented, the indexes defined on the table also become fragmented.

Project Server 2010 uses GUID types as clustering keys, which avoids concurrent inserts competing for the same data pages (insert hot spots), but which can be a cause of table and index fragmentation. Fragmentation can occur because new records can be inserted anywhere in the b-tree, instead of at the end, leading to a greater propensity to page split (index and data) and therefore fragment. This is lessened by clustering on composite keys that use the Project UID to ensure data pages contain related data, but regular defragmentation of the larger tables will improve performance, especially in large deployments of Project Server 2010.

Over time, database fragmentation can result in performance degradation (unnecessary disk activity) and inefficient space usage. To reduce fragmentation and minimize the rate at which fragmentation occurs, manually set the size of content databases to be as large as possible given your business requirements and database architecture. For example, if you have to limit content databases to 100 gigabytes (GB), after you have created your content databases, set their size to 100 GB in SQL Server Management Studio.

Although you can defragment tables, defragmenting indexes is more useful to database performance, and it is much faster. This article only describes how to defragment indexes.

Before implementing a database fragmentation maintenance plan, determine which tables and indexes are most fragmented and then create a maintenance plan to rebuild or reorganize those indexes.

Measuring fragmentation with sys.dm_db_index_physical_stats

Use the sys.dm_db_index_physical_stats dynamic management view to determine fragmentation for the indexes on a specified table or view.

For measuring fragmentation, we recommend that you monitor the column avg_fragmentation_in_percent. The value for avg_fragmentation_in_percent should be as close to zero as possible for maximum performance. However, values from 0 percent through 10 percent may be acceptable.

For information about how to use sys.dm_db_index_physical_stats, see sys.dm_db_index_physical_stats (Transact-SQL) (http://go.microsoft.com/fwlink/p/?LinkID=110839)

Reducing fragmentation for a database

For information about reducing fragmentation for a database, see the Measure and reduce fragmentation section of the Database Maintenance for Microsoft SharePoint 2010 Products white paper. You can download the white paper from Database maintenance for SharePoint Server 2010.

Reducing fragmentation for a specific table and its indexes

If you want to defragment the index associated with a particular table, instead of a whole database, you can either reorganize or rebuild the index. For more information, see Clustered Index Structures (http://go.microsoft.com/fwlink/p/?LinkID=110847).

Reorganizing an index means that the index leaf level will be reorganized. Index reorganization defragments and compacts clustered and non-clustered indexes on tables and views and can significantly improve index scanning performance. Reorganization is always performed online so that the underlying table is available to users.

Rebuilding an index means that the index will be rebuilt using the same columns, index type, uniqueness attribute, and sort order. Rebuilding improves the performance of index scans and seeks. You can rebuild the index with a table either on- or offline.

The fragmentation level of an index determines the method that you should use to defragment it, and whether it can remain online, or should be taken offline.

Fragmentation level | Defragmentation method
Up to 10% | Reorganize (online)
10 - 75% | Rebuild (online)
75% or more | Rebuild (offline)

Note that using the DROP INDEX and CREATE INDEX commands is not supported on Microsoft SharePoint Server 2010 databases.

Using ALTER INDEX

ALTER INDEX permits a database administrator to perform maintenance operations against an existing table or view index. It can be used to disable, rebuild, and reorganize indexes or optionally setting options on the index.

In most cases, you can rebuild indexes while the database is online, because there are no significant gains in an offline rebuild of the indexes. However, be aware that when an index is being rebuilt, a shared table lock is put on the table, preventing all operations except for SELECT operations from being performed. SharePoint Server 2010 databases use clustered indexes specifically. When a clustered index is being rebuilt, an exclusive table lock is put on the table, preventing any table access by end-users.

You can customize the following sample script to rebuild all indexes on a table.

Copy Code
USE Contoso_Content_1
GO
ALTER INDEX ALL ON [database_name. [ schema_name ] . | schema_name. ]table_or_view_name
REBUILD WITH (FILLFACTOR = 70, SORT_IN_TEMPDB = ON, ONLINE = ON,
STATISTICS_NORECOMPUTE = ON)
GO

Special consideration for the Reporting Database

As we expect customers to implement custom reports that are based on custom fields and data available in the Reporting database, we recommend following the best practices for T-SQL writing and index creation to ensure scalable and performance reporting solution. Project Server 2010 does not index these (dynamically generated) tables outside the primary key.

When you are working with Microsoft Customer Service and Support, a support engineer might ask you to remove any additional indexes created or remove any additional columns added to existing indexes. This is because additional indexes can change data access paths and in some cases lead to unexpected performance and locking/deadlocking issues.

Setting the fill factor for a server

The fill factor can be used to further improve index data storage and performance. When indexes are created or rebuilt, the fill factor value (1-100) determines the percentage of space on each leaf-level page that can be filled with data. The remaining space is reserved for future growth. For many situations the default server-wide fill factor level of 0 is optimal; however, for SharePoint Server 2010, a server-wide setting of 70 is optimal to support growth and minimize fragmentation.

Although it is possible, we do not recommend that you set the fill factor for individual tables or indexes.

To view the fill factor value of one or more indexes, query the sys.indexes catalog view. For more information about the view, see sys.indexes (Transact-SQL) (http://go.microsoft.com/fwlink/p/?LinkId=221728).

To configure the server-wide fill factor value, use the sp_configure system stored procedure. For more information, see sp_configure (Transact-SQL) (http://go.microsoft.com/fwlink/p/?LinkId=221729).


Shrinking databases in Project Server 2010

Published: June 28, 2011

Sizing the deployment of any farm is an inexact science. It is best to err on the side of caution and over-allocate space in your instance of Microsoft SQL Server. Once the system achieves steady state (the number of projects being created each year is about the same as the number that you are archiving/deleting) you may be able to reduce your initial allocation to recover space on your instance of SQL Server.

Shrinking data files

You can shrink each file in a database (extensions .mdf, .ldf, and .ndf) to remove unused pages and recover disk space. Microsoft SharePoint Server 2010 databases do not automatically shrink data files, although many activities create white space in the database. Activities that can create white space include merging content databases, and deleting projects, resources, large custom fields, documents, document libraries, lists, list items, and sites within Project Workspaces.

Free space is released from the end of the file — for example, a content database file of 60 gigabytes (GB) with a specified target size of 40 GB will free as much space as possible from the bottom 20 GB of the database file. If used pages are included in the bottom 20 GB, those pages will later be relocated to the upper 40 GB of the file that is retained. You can determine the free space in a database by using the sp_spaceused stored procedure. For more information, see sp_spaceused (Transact-SQL) (http://go.microsoft.com/fwlink/p/?LinkId=221731).

You can shrink database files individually or as a group. Shrink operations are most effective following a large file or site that can potentially generate much unused space. Database files can only be reduced to the point where there is no free space remaining; therefore a content database in which content is infrequently deleted may see minimal benefit from shrinking. Repeated shrinking may result in increased fragmentation because the operation does not preserve the fragmentation state of indexes. You do not have to shrink database files as frequently as you defragment indexes. However, in environments where data is often deleted from the databases, you may want to schedule database file shrinking more frequently.

When shrinking databases, consider the following:

  • We do not recommend that you auto-shrink databases or configure a maintenance plan that programmatically shrinks your databases.

  • Shrink a database only when 50% or more of the content in it has been removed by user or administrator deletions.

  • We recommend that you shrink only content databases. The configuration database, Central Administration content database, SSP databases, and search databases do not usually undergo enough deletions to contain significant free space.

  • Avoid the need to shrink databases by including growth allocations in your capacity planning, including an overhead allocation of 10-20 percent.

  • Shrinking databases is a resource-intensive operation. Therefore, if you must shrink a database, carefully consider when to schedule it.

Database and database files can be shrunk manually to recover space by using Management Studio or the Maintenance Plan Wizard. For more information, see Shrinking a Database (http://go.microsoft.com/fwlink/p/?LinkId=221732).


Monitoring maintenance plans for Project Server 2010
See Also

Published: June 28, 2011

A database maintenance plan is only as good as its integrity is preserved, which requires monitoring. Operationally, maintenance tasks must be monitored for success and duration, and system performance must be monitored to find system degradation before users report it. We recommend that you use solution monitoring software, such as System Center Operations Manager. Microsoft has released management packs for it that provide monitoring according to best practices for specific products involved in the Microsoft Project Server 2010 architecture, such as Microsoft SQL Server, Microsoft SharePoint Server 2010, and Project Server 2010.

Some maintenance tasks, such as nightly backups or hourly transactional log backups, may have a significant effect on system performance or data integrity if they do not operate. Therefore, it is important to monitor their execution. Most operational environments have an extant alarming system —Project Server database maintenance plan execution should be integrated with these if it is possible. If you cannot do this, basic alarming can be quickly implemented through SQL Server Agent's Operator mechanism combined with SQLMail via SMTP. The SQL Server Agent jobs created when a maintenance plan is scheduled can be edited to add operator notification upon maintenance task completion, success, or failure. Depending on the solution scale and operational maturity of the environment, a mixture of positive ("the task ran successfully") and negative ("an error occurred") notifications are suggested. This mixture may change over time — during initial implementation and test periods, it is reassuring to receive regular notifications, which may not be necessary as the system matures.

For more information, see Using SQL Server Profiler (http://go.microsoft.com/fwlink/p/?LinkId=221734)

Monitoring SQL Server Counters

As part of your monitoring plan, we recommend that you monitor the following SQL Server counters.

Objects and Counters | Description
General Statistics | This object provides counters to monitor general server-wide activity, such as the number of current connections and the number of users connecting and disconnecting per second from computers that are running an instance of SQL Server.
User Connections | This counter shows the number of user connections on your instance of SQL Server. If you see this number increase by 500 percent from your baseline, you may see a performance reduction.
Databases | This object provides counters to monitor bulk copy operations, backup and restore throughput, and transaction log activities. Monitor transactions and the transaction log to determine how much user activity is occurring in the database and how full the transaction log is becoming. The amount of user activity can determine the performance of the database and affect log size, locking, and replication. Monitoring low-level log activity to gauge user activity and resource usage can help you determine performance bottlenecks.
Transactions/sec | This counter shows the number of transactions on a given database or on the whole SQL Server instance per second. This number is to help you create a baseline and to help you troubleshoot issues.
Locks | This object provides information about SQL Server locks on individual resource types.
Number of Deadlocks/sec | This counter shows the number of deadlocks on the SQL Server per second. This should typically be 0.
Average Wait Time (ms) | This counter shows the average amount of wait time for each lock request that resulted in a wait.
Lock Wait Time (ms) | This counter shows the total wait time for locks in the last second.
Lock Waits/sec | This counter shows the number of locks per second that could not be satisfied immediately and had to wait for resources.
Latches | This object provides counters to monitor internal SQL Server resource locks called latches. Monitoring the latches to determine user activity and resource usage can help you determine performance bottlenecks.
Average Latch Wait Time (ms) | This counter shows the average latch wait time for latch requests that had to wait.
Latch Waits/sec | This counter shows the number of latch requests per second that could not be granted immediately.
SQL Statistics | This object provides counters to monitor compilation and the kind of requests sent to an instance of SQL Server. Monitoring the number of query compilations and recompilations and the number of batches received by an instance of SQL Server gives you an indication of how quickly SQL Server is processing user queries and how effectively the query optimizer is processing the queries.
SQL Compilations/sec | This counter indicates the number of times the compile code path is entered per second.
SQL Re-Compilations/sec | This counter indicates the number of times statement recompiles are triggered per second.
Plan Cache | This object provides counters to monitor how SQL Server uses memory to store objects such as stored procedures, ad hoc and prepared Transact-SQL statements, and triggers.
Cache Hit Ratio | This counter indicates the ratio between cache hits and lookups for plans.
Buffer Cache | This object provides counters to monitor how SQL Server uses memory to store data pages, internal data structures, and the procedure cache, and it also provides counters to monitor the physical I/O as SQL Server reads and writes database pages.
Buffer Cache Hit Ratio | This counter shows the percentage of pages found in the buffer cache without having to read from disk. The ratio is the total number of cache hits divided by the total number of cache lookups since an instance of SQL Server was started.

See Also

Other Resources

Monitoring and maintaining SharePoint Server 2010


Database management (Project Server 2010)

Published: July 29, 2010

This section covers database maintenance procedures.

In this section:

  • Move the Reporting database to a new server (Project Server 2010)

  • Move all databases to a different server (Project Server 2010)

  • Configure availability by using SQL Server database mirroring (Project Server 2010)


Move the Reporting database to a new server (Project Server 2010)

Published: July 29, 2010

Microsoft Project Server 2010 performance can be improved by deploying the Reporting database to a separate instance of Microsoft SQL Server from the other three Project Server databases. If you want to move the Reporting database to a different instance of SQL Server after you have deployed your Microsoft Project Web App (PWA) site, you can do so by using the procedures in this article.

Moving the Reporting database is a major maintenance procedure and should be done at a time of minimal system activity. Users cannot access the PWA site while you are performing these procedures.

The basic steps involved in moving the Reporting database are as follows:

  1. Unprovision the PWA site

  2. Detach the Reporting database

  3. Copy the Reporting database to the new instance of SQL Server

  4. Attach the Reporting database to the new instance of SQL Server

  5. Reprovision the PWA site

Video demonstration

This video shows the steps involved in moving the Reporting database to a new instance of Microsoft SQL Server.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=202555). To download the video file, right-click the link, and then click Save Target As.

Unprovision the PWA site

When moving the Reporting database, you must unprovision the PWA site as a first step. This removes references to the site from Microsoft SharePoint Server 2010 without making any changes to the site itself. Once you have done this, you can reconfigure PWA by moving the Reporting database and then reprovision the PWA site.

To unprovision the PWA site

  1. In the SharePoint Central Administration Web site, in the Application Management section, click Manage service applications.

  2. On the Manage Service Applications page, click the Project Server service application.

  3. On the Manage Project Web App Sites page, click the drop-down menu for the PWA site where you want to move the reporting database, and then click Delete.

  4. On the Delete Project Web App Site page:

    1. Clear the Delete site collection from SharePoint check box.

      Caution:

      The Delete site collection from SharePoint check box must be cleared or else the PWA site will be deleted from the Content database.

    2. Click Delete.

Unprovisioning the site may take several minutes. Once the PWA site is no longer listed on the Manage Project Web App Sites page, it is unprovisioned and you can move the reporting database.

Move the reporting database

The Reporting database can be moved by detaching it from the current instance of SQL Server and attaching it to the new instance of SQL Server. We recommend that you have your database administrator perform these steps if you are unfamiliar with moving databases in SQL Server.

To move the Reporting database

  1. Start SQL Server Management Studio.

  2. Connect to the instance of SQL Server where the Reporting database is located.

  3. In Object Explorer, expand Databases.

  4. Right-click the Reporting database, click Tasks, and then click Detach.

  5. Copy the database files (.mdf and .ldf files) to the new instance of SQL Server.

  6. In SQL Server Management Studio, in Object Explorer, click Connect, and then click Database Engine.

  7. Connect to the instance of SQL Server where you copied the Reporting database.

  8. Right-click Databases and then click Attach.

  9. Click Add.

  10. Select the Reporting database (.mdf) file and then click OK.

  11. Click OK.

Once the Reporting database is attached to the new instance of SQL Server, you can reprovision the PWA site.

Reprovision the PWA site

Reprovisioning the PWA site is achieved by adding a new PWA site and connecting it to your existing databases and site collection. This is performed from SharePoint Central Administration.

To update PWA properties

  1. In SharePoint Central Administration, in the Application Management section, click Manage service applications.

  2. Click the Project Server service application.

  3. On the Manage Project Web App Sites page, click Create Project Web App site.

  4. On the Create Project Web App Site page:

    1. Check all settings to make sure that they match the PWA site that you unprovisioned. Database names must exactly match the databases in SQL Server for this PWA site.

    2. In the Reporting Database section, make sure that the values for Reporting database server and Reporting database name correspond to the Reporting database that you just moved.

  5. Click OK.

Once the PWA site has been reprovisioned (when the status is Provisioned), the users can return to using PWA as usual.


Move all databases to a different server (Project Server 2010)

Published: September 2, 2010

If you want to move the databases associated with a Microsoft Project Web App (PWA) site to a different instance of Microsoft SQL Server, you can do so by using the procedures in this article.

Moving the PWA databases is a major maintenance procedure and should be done at a time of minimal system activity. Users cannot access the PWA site while you are performing these procedures.

Note:

This article describes how to move the Microsoft Project Server 2010 databases to a new instance of SQL Server while keeping the same PWA site. For information about how to move your Project Server databases to a different PWA site, see Move all databases (Project Server 2010).

The basic steps involved in moving a database are as follows:

  1. Unprovision the PWA site

  2. Detach the databases

  3. Copy the databases to the new instance of SQL Server

  4. Attach the databases to the new instance of SQL Server

  5. Reprovision the PWA site

Unprovision the PWA site

When moving the PWA databases, you must unprovision the PWA site as a first step. This removes references to the site from Microsoft SharePoint Server 2010 without making any changes to the site itself. Once you do this, you can reconfigure PWA by moving the reporting database and then reprovision the PWA site.

To unprovision the PWA site

  1. In the SharePoint Central Administration Web site, under Application Management, click Manage service applications.

  2. On the Manage Service Applications page, click the Project Server service application.

  3. On the Manage Project Web App Sites page, point to the PWA site where the databases that you want to move reside, click the arrow that appears, and then click Delete.

  4. On the Delete Project Web App Site page:

    1. Clear the Delete site collection from SharePoint check box.

      Important:

      The Delete site collection from SharePoint check box must be cleared or the PWA site will be deleted from the content database.

    2. Click Delete.

Deprovisioning the site may take several minutes. Once the PWA site is no longer listed on the Manage Project Web App Sites page, it is deprovisioned and you can continue with moving the databases.

Move the databases

Any combination of the following databases can be moved:

  • The Draft, Published, and Archive databases

  • The Reporting database

  • The SharePoint Server content database where the PWA site and project workspaces reside

You can move any or all of these databases to different instances of SQL Server. The Draft, Published, and Archive databases must reside on the same instance of SQL Server. The Reporting database and SharePoint Server content database can reside on different instances of SQL Server if you want.

If you plan to move the SharePoint Server content database, you must follow the recommended procedures published for SharePoint Server 2010. For more information, see Move content databases (SharePoint Server 2010).

Important:

If you are going to move the content database, you must do so while the PWA site is deprovisioned. Follow the published SharePoint Server 2010 procedures for moving a content database and then complete the rest of the procedures shown here.

Each Project Server database can be moved by detaching it from the current instance of SQL Server and attaching it to the new instance of SQL Server. We recommend that you have your database administrator follow these steps if you are unfamiliar with moving databases in SQL Server. Perform the following procedure for each database that you want to move.

To move a database

  1. Start SQL Server Management Studio.

  2. Connect to the instance of SQL Server where the database is located.

  3. In Object Explorer, expand Databases.

  4. Right-click the database that you want to move, click Tasks, and then click Detach.

  5. Copy the database files (.mdf and .ldf files) to the new instance of SQL Server.

  6. In SQL Server Management Studio, in Object Explorer, click Connect, and then click Database Engine.

  7. Connect to the instance of SQL Server where you copied the database.

  8. Right-click Databases and then click Attach.

  9. Click Add.

  10. Select the database file (.mdf file) and then click OK.

  11. Click OK.

Once you have finished moving the databases, you can reprovision the PWA site.

Reprovision the PWA site

Reprovisioning the PWA site is achieved by adding a new PWA site and connecting it to your existing databases and site collection. This is performed from SharePoint Central Administration.

To update PWA properties

  1. In SharePoint Central Administration, under Application Management, click Manage service applications.

  2. Click the Project Server service application.

  3. On the Manage Project Web App Sites page, click Create Project Web App site.

  4. On the Create Project Web App Site page, check all settings to make sure that they match the PWA site that you deprovisioned.

    Important:

    Database names must exactly match the databases in SQL Server for this PWA site, and database server names must correspond to the instances of SQL Server where you reattached the databases.

  5. Click OK.

Once the PWA site is reprovisioned (when the status is Provisioned), the users can return to using PWA as usual.


Configure availability by using SQL Server database mirroring (Project Server 2010)

Published: July 29, 2010

Microsoft SQL Server database mirroring provides availability support by sending transactions directly from a principal database and server to a mirror database and server. This can provide redundancy for the four Microsoft Project Server 2010 databases and for the associated content database. This is useful in the event of a system failure, and also for regular system maintenance.

This article describes requirements for using database mirroring with a Microsoft Project Web App (PWA) site. This article applies specifically to the four Project Server 2010 databases (Draft, Published, Archive, and Reporting), and also to the Microsoft SharePoint Server 2010 content database associated with PWA. For information about database mirroring for the rest of your SharePoint Server 2010 farm, see Configure availability by using SQL Server clustering (SharePoint Server 2010)

Database mirroring for Project Server 2010 can only be configured by using Windows PowerShell. When you create a new PWA site, use the New-SPProjectWebInstance cmdlet; when you update an existing PWA site for use with database mirroring, use the Set-SPProjectWebInstance cmdlet. By using these cmdlets, you can specify the primary and secondary mirroring servers for the four Project Server 2010 databases.

For detailed information about how to configure database mirroring in SQL Server, see Database Mirroring.

Important:

Project Server 2010 requires synchronous mirroring.

Failover considerations

Project Server 2010 requires manual failover for the Draft, Published, and Archive databases. These databases all interact with one another. These databases must all reside on the same instance of SQL Server. Using automatic failover with a witness server could cause one of these databases to fail over to the mirror server while the other databases remain on the primary server. This could result in failures in Project Server Interface (PSI) calls and other Project Server functionality. When you have to fail over the Draft, Published, or Archive database, manually fail over all three of them to the secondary server at the same time.

The Reporting database operates independently of the other three Project Server databases. Use of a witness server and automatic failover for the Reporting database is supported.

When failing over the Project Server databases for the purposes of system maintenance or other non-urgent tasks, we recommend failing over during a time of low usage for the system. This minimizes the time that is required for log-redo tasks on the secondary server and lets you bring Project Server online on the secondary server faster.

Video demonstration

This video shows the steps involved in configuring database mirroring.

Screenshot of video

Watch the video (http://go.microsoft.com/fwlink/p/?LinkId=202557). To download a copy of the video file, right-click the link, and then click Save Target As.

Configuration

We recommend that you configure mirroring at a time of minimal system use. This speeds initial database synchronization.

Before you configure SQL Server mirroring, ensure that any database access accounts that are used by SharePoint Server or Project Server are duplicated on the instance of SQL Server where you plan to deploy your mirrored databases. This includes the Farm Administrator account and any other accounts that you might use for database access related to Project Server.

We recommend that you transfer your logins and permissions from the principal server to the mirror server by running a script. An example script is available in Knowledge Base article 918992 How to transfer the logins and the passwords between instances of SQL Server 2005 (http://go.microsoft.com/fwlink/p/?LinkId=122053&clcid=0x409). For more information about how to transfer SQL Server metadata between instances, see the SQL Server Books Online article Managing Metadata When Making a Database Available on Another Server Instance (http://go.microsoft.com/fwlink/p/?LinkId=122055&clcid=0x409).

SQL Server mirroring requires that the recovery model be set to Full on each database that you plan to mirror. Full recovery is the default for Project Server databases, but we recommend that you confirm this setting before configuring mirroring.

Perform the following procedure for each Project Server database that you plan to mirror.

To set the recovery model

  1. In SQL Server Management Studio, expand Databases.

  2. Right-click the database, and then click Properties.

  3. In the left pane, select Options.

  4. From the Recovery model list, choose Full.

  5. Click OK.

Once you have verified the recovery model, you must do the following:

  1. Configure SQL Server mirroring in SQL Server for each database that you want to mirror.

  2. Configure the PWA settings to point to the mirror server.

  3. If you are mirroring the content database, configure SharePoint Server to mirror that content database.

Configure mirroring on SQL Server

You must back up each database that you plan to mirror and restore it to the instance of SQL Server where you want the mirror to reside. A transaction log backup is also required.

Important:

The Draft, Archive, and Published databases must all be running on the same instance of SQL Server. If you mirror one of them, you must mirror all three of them.

Perform the following procedures on each Project Server database that you plan to mirror.

To back up a database

  1. In SQL Server Management Studio, expand Databases.

  2. Right-click the database, click Tasks, and then click Back up.

  3. Confirm that the backup type is Full.

  4. Set the backup destination to Disk and choose a location on the local disk.

  5. Click OK.

Once the database backup has finished, you must back up the transaction log.

To back up the transaction log

  1. In SQL Server Management Studio, expand Databases.

  2. Right-click the database, click Tasks, and then click Back up.

  3. In the Backup type list, select Transaction Log.

  4. Set the backup destination to the same file and location as the Full backup.

  5. Click OK.

Once you have backed up each database, copy the database backup files to the instance of SQL Server where you want to create the mirror.

On the instance of SQL Server where you want to create the mirror, restore each database by using the following procedure.

To restore a database for mirroring

  1. In SQL Server Management Studio, right-click Databases, and then click Restore Database.

  2. In the To database box, type the name of the database that you are restoring.

  3. Select the From device option, and then click Browse.

  4. In the Specify Backup dialog box, confirm that the Backup media type is File and then click Add.

  5. Navigate to the location of your backup files and select the database that you want to restore.

  6. Click OK.

  7. Click OK.

  8. In the Select backup sets to restore table, select the check boxes for both the Full and Transaction Log backups.

  9. In the left pane, click Options.

  10. In the Recovery state section, select the RESTORE WITH NORECOVERY option.

    Important:

    You must restore the database by using NORECOVERY for mirroring to function.

  11. Click OK.

Once the backups have been restored, you can configure mirroring. For each database that you want to mirror, perform the following procedure on the instance of SQL Server where your active databases reside.

To configure mirroring

  1. In SQL Server Management Studio, expand Databases.

  2. Right-click the database that you want to mirror, click Tasks, and then click Mirror.

  3. On the Database Properties dialog box, click Configure Security.

  4. On the wizard, click Next.

  5. On the Include Witness Server page, select the No option, and then click Next.

  6. On the Principal Server Instance page, click Next.

  7. On the Mirror Server Instance page, click Connect.

  8. On the Connect to Server dialog box, type the name of the mirror server, and then click Connect.

  9. Click Next.

  10. On the Service Accounts page, type the names of the service accounts for the Principal and Mirror servers, and then click Next.

  11. Click Finish.

  12. When the Configuring Endpoints dialog box shows Success, click Close.

  13. On the Database Properties dialog box, click Start Mirroring.

  14. Click OK.

Once SQL Server is configured for mirroring, you must configure Project Server. You must also configure SharePoint Server if you are mirroring the content database.

Configure Project Server for mirroring

Configuring Project Server for mirroring involves using the Windows PowerShellSet-SPProjectWebInstance cmdlet to set the mirror server for the Project Server database that you are mirroring. The -PrimaryDBMirrorServer parameter configures the mirror server for the Draft, Archive, and Published databases. The -ReportingDBMirrorServer parameter configures the mirror server for the Reporting database.

Perform the following procedure on the application server where Project Server is running.

To configure mirroring in Project Server

  1. Click Start, All Programs, Microsoft SharePoint 2010 Products.

  2. Right-click SharePoint 2010 Management Shell, and then click Run as administrator.

  3. Run the Windows PowerShellSet-SPProjectWebInstance cmdlet with the appropriate values for your mirror servers. For example:

    Set-SPProjectWebInstance -AdminAccount Litware\FarmAdmin -ArchiveDbname Proj_Archive -DraftDbname Proj_Draft -PrimaryDbserver SQL1 -PublishedDbname Proj_Pub -ReportingDbname Proj_Rep -ReportingDbserver SQL1 -PrimaryDBMirrorServer SQL2 -ReportingDBMirrorServer SQL2 -Url http://SharePointFarm/pwa

Database mirroring configuration is now complete for the Project Server databases.

Configure SharePoint Server for mirroring

If you are mirroring the content database, you must configure the Failover Database Server settings in the SharePoint Central Administration Web site after database mirroring has been configured in SQL Server. Perform the following procedure for the content database if you are mirroring the content database.

To configure SharePoint Server to mirror the content database

  1. In Central Administration, under Application Management, click Manage content databases.

  2. In the Database Name section, click the Project Server content database that you want to mirror.

  3. On the Database settings page, in the Failover Database Server box, type the name of your mirror server.

  4. Click OK.

The content database is now configured to enable failover to the mirror server.

Failing over databases

You can decide to fail databases over to the mirror server for several reasons, including the need to perform maintenance on the primary server, or in response to a hardware failure on the primary server.

When failing over Project Server databases, be aware of the following:

  • The Draft, Archive, and Published databases must all be running on the same instance of SQL Server. If you fail one of them over, you must fail over the other two also. The Reporting database and the content database can each be failed over independently.

  • Failing over databases is not a method of moving databases to a new server permanently. Project Server is still configured to use the original database server; it merely redirects database calls to the mirror server until you fail the databases back to the original server.

Failing over a mirrored database is done through SQL Server. Use the following procedure to fail over a database to the mirror server. Perform this procedure on the instance of SQL Server where the mirroring Principal is located (not the mirror).

To fail a database over to the mirror server

  1. In SQL Server Management Studio, expand Databases.

  2. Right-click the database, click Tasks, and then click Mirror.

  3. Click Failover.

  4. On the confirmation dialog box, click Yes.

When you fail over a database, SQL Server will swap roles between the principal and mirror servers — the mirror will become the principal and the principal will become the mirror. To fail back, perform the same procedure on the instance of SQL Server where the now-principal database is located.

Note that if you fail over databases in response to a hardware failure or other problem on the primary server, the farm can run on the mirror server as long as necessary. However, you will not have database redundancy until you fix the failure and reconfigure mirroring.

When you have completed the necessary maintenance or repairs on the primary server, make sure that you fail your databases back to the original server.


Use Project Web App (Project Server 2010)

Published: January 27, 2011

Articles in this section describe how to configure and use Microsoft Project Web App. Content is designed for team members, project managers, portfolio managers, and site administrators.

The following articles and sections focus on typical scenarios for using Project Web App:

  • What's new in Project Web App (Project Server 2010)

  • Getting started with Project Web App (Project Server 2010)

  • Setting up Project Web App (Project Server 2010)

  • Managing portfolios (Project Server 2010)

  • Creating and working with projects (Project Server 2010)

  • Submitting and approving time and status (Project Server 2010)

  • Reporting on projects (Project Server 2010)

  • Getting Help with Project Web App (Project Server 2010)


What's new in Project Web App (Project Server 2010)

Published: January 27, 2011

The version of Microsoft Project Web App that ships with Microsoft Project Server 2010 includes an improved user interface and several robust new features. Together, these updates provide an intelligent business application that supports integrated project and portfolio management capabilities, scalable collaboration for both small teams and enterprises, and an extended platform that integrates with related Microsoft technologies.

In this article:

  • Improved user interface

  • Integrated project and portfolio management

  • Scalable collaboration

  • Extended platform

Improved user interface

Project Web App offers a significantly updated user interface, including the Ribbon and a streamlined project editing grid.

Introducing the Ribbon

Project Web App now uses the Ribbon, which helps you to quickly find the commands that you need to complete a task. Commands are organized in logical groups that are collected together under tabs. The new versions of Microsoft SharePoint Server 2010, Microsoft SharePoint Foundation 2010, and the Microsoft Project 2010 client program are also using the Ribbon, providing a seamless interface across all programs.

Enhanced project editing interface

With a new grid-based project editing interface, you can now update project data in the same grid and Gantt Chart view that you use to review your project data. Data entered into the grid is validated upon entry, and the overall experience is much more streamlined. This updated grid is used throughout Project Web App, including the Project Center, task updates, preview pages, the Resource Center, and resource assignment views.

Integrated project and portfolio management

Changes in integrated project and portfolio management include end-to-end demand management and portfolio analysis solutions, and the ability to manually schedule tasks and effectively schedule using a top-down approach.

Manage project proposals

The new demand management functionality in Project Web App enables you to implement an end-to-end proposal submission and approval process that uses templates, a Web-based proposal submission form, project lifecycles, and business strategies. Once a proposal is approved, you can easily create a project schedule based on the proposal and assign resources.

Analyze proposals for your project portfolio

Project Web App offers new portfolio analysis features. You can now analyze project proposals using business drivers, high-level cost constraints, and high-level resource constraints before you make approval decisions.

User-controlled scheduling

In Project Web App, project managers can maintain control over their project plans and minimize unexpected changes using manually scheduled tasks. Factors such as task dependencies and calendar changes will no longer automatically adjust task dates when user-controlled scheduling is enabled.

Top-down summary tasks

At the beginning of the planning phase, project managers may only have some high-level information on key deliverables and major milestones of their projects. Using Project Web App, projects can be divided into high-level phases based on the overall timeline and budget. This means that dates for individual work items do not necessarily need to line up exactly with dates for the high-level phases.

Scalable collaboration

A major goal in developing this version of Project Web App was to provide teams with tools customized for their size and maturity. To achieve this goal, improvements were made to help simplify submitting and approving timesheets and task status. In addition, user delegation was added to support an uninterrupted collaborative experience.

Single entry mode for timesheets and task status

Project Web App offers a new unified mode for entering time and task progress. If your organization chooses to use this single entry mode, you can complete your timesheet and inform your manager of your task status with a single view.

Approval Center for timesheets and task status

In addition to being able to enter time and task progress in a single location, those with the appropriate permissions can now approve timesheets and task updates in a single view.

User delegation

The new user delegation feature in Project Web App enables one user to act as another user, regardless of permission-level differences. For example, if an administrator has a planned vacation and needs someone to fill in for her while she's away, she can identify a team member as her delegate, and that team member will have all of the administrator's privileges.

Extended platform

Project Web App offers an extended platform, including departmental custom fields, the ability to create multiple OLAP cubes that have department support, and end-user reporting that uses Excel Services.

Departmental custom fields

Departmental custom fields, or departments, enable you to define, at a resource, task, or project level, which fields are required or not required. This helps to filter information displayed throughout Project Web App, so that information is focused on what is applicable to each department. While this is not a security feature, it can help to simplify the interface for Project Web App users.

Multiple OLAP cubes with department support

Project Web App enables you to build more than one OLAP cube. In addition, you can now filter cube data by department.

Business intelligence with Excel Services

In this release, Excel Services in Microsoft SharePoint Server 2010 is integrated with Project Web App to make it easier to create business intelligence views. As part of this integration, blank data-connected spreadsheets and predefined views are provided. The data available for reporting has also been expanded to include timesheet custom fields, project properties, and portfolio planner and optimizer data.


Getting started with Project Web App (Project Server 2010)

Published: January 27, 2011

If you used an earlier version of Microsoft Project Web App, have never used Project Web App before, or want to understand how Project Web App can help you in your role, explore these resources to begin learning how to use the latest version.

What is your situation? | Where to go
Just need to know what's changed? Find out what's new, changed, or discontinued for Project Web App in Microsoft Project Server 2010. | What's new in Project Web App (Project Server 2010) Discontinued features and modified functionality in Project Server 2010
Never used Project Web App before? Learn what Project Web App does, what it is most useful for, and how to work with it. | Up to speed with Project Web App in Project Server 2010
Want to learn about using Project Web App in your role? These guides are designed to get you started using features in Project Web App that are most applicable to your project role. | Getting started: Team members (Project Server 2010) Getting started: Project managers (Project Server 2010) Getting started: Portfolio managers (Project Server 2010) Getting started: Site administrators (Project Server 2010) About the Quick Launch in Project Web App

For more information about how to get started with other, related Microsoft programs, see Getting Started with Microsoft Office 2010.


Up to speed with Project Web App in Project Server 2010

Published: January 27, 2011

Welcome to Microsoft Project Web App! The following video series is designed to help you get oriented within Project Web App and learn about its many features. After watching all five videos, you should have a good understanding of what this tool is used for, and how it can meet your needs.

  • Part 1: The Basics

  • Part 2: Proposing and creating a new project

  • Part 3: Selecting projects for your portfolio

  • Part 4: Plan your project

  • Part 5: Manage your project


Getting started: Team members (Project Server 2010)

Published: January 27, 2011

In Microsoft Project Web App, team members are the people who actually do the work on projects and tasks.

Are you a team member? If so, welcome to Project Web App! You use this tool to update progress, enter time spent on tasks, and view project schedules, issues, and risks.

In this article:

  • What is Project Web App?

  • Where do you start?

  • How to get help

What is Project Web App?

Project Web App is one part of an end-to-end enterprise project management solution. This solution includes a client program, Microsoft Project Professional, and a server, Microsoft Project Server. Project Web App is part of Project Server. It is a robust Web application that is used to do everything from analyzing portfolios and managing demands, to entering time in a timesheet and updating task status.

Get oriented

The Project Web App interface is made up of three main areas: the Quick Launch, the Ribbon, and the content display area.

The Quick Launch lists the main views and pages that you are able to access. You can click these links to navigate to different areas of the program. Some pages in Project Web App do not include the Quick Launch. For example, when you fill out a form, you must complete and save the form, or cancel out of it, in order to see the Quick Launch.

The Ribbon is the toolbar that you use to perform actions on what is currently in the content display area. There may be multiple tabs on the Ribbon, to change between different sets of actions. Each tab contains groups of related buttons that you can use to interact with the page content.

The content display area contains information about your portfolios, projects, and tasks. This is the main focus of each page, and it is where you enter and review data.

Where do you start?

Project Web App is highly customizable, so your organization can have a unique starting page for you to use. By default, the main page that appears when you open Project Web App is a great starting point. It shows any new tasks that have been assigned to you, information about your timesheets, notifications about status reports, and issue and risk assignments.

There are other useful places to start in Project Web App, depending on what you intend to do while you are logged on. The following sections provide details about some common scenarios.

Fill out a timesheet

There are two starting points for entering actual work on a timesheet.

  • To fill out your current timesheet, on the Quick Launch, under My Work, click Timesheet. This takes you to your current timesheet, where you can enter time against tasks, or log vacation, sick time, or other administrative work items.

  • If you need to create a new timesheet for a period other than the current one, on the Quick Launch, under Settings, click Manage Timesheets. This takes you to a list of timesheets that you can create.

These pointers should get you started with the process of filling out your timesheet, but it is likely that you have more questions. For example, you may need to add tasks to your timesheet, set up vacation time, or submit your timesheet to your manager.

Enter task progress

In Project Web App, you can enter your progress on a task separately from the time that you have spent on the task. For example, let's say you have a task that was estimated to take 10 days to complete. You have spent five days working on the task, so you enter that time on your timesheet, but you feel ahead of the game, as though you have completed about 75 percent of the work. You can communicate that progress to your manager by using the Tasks page.

Review project information

While a team member's primary interest is typically at the task level, there may be times when you would like to review project-level information, such as the overall project schedule, issues, or risks.

To view the project schedule, on the Quick Launch, under Projects, click Project Center. You can use this page to view the overall project schedule.

To view issues and risks assigned to you, on the Quick Launch, under My Work, click Issues and Risks. On this page, you can review your assigned issues and risks, including whether they are active, postponed, or closed.

How to get help

If you run into trouble while using Project Web App, use the following workflow to try to find a solution.

  1. Web resources Try to find an answer to your question on Office.com or the Project Server 2010 TechCenteron TechNet. If you are not able to find what you need there, you might also try the Project 2010 Solution Center.

  2. Project manager Talk with the project manager for the project where you are encountering issues.

  3. Site administrator If the issues are not project-specific, you should contact your organization's Project Server site administrator. If you are not sure who this is, one of your organization's project managers can help point you in the right direction.


Getting started: Project managers (Project Server 2010)

Published: January 27, 2011

In Microsoft Project Web App, project managers are the people who create and maintain projects and tasks, assign resources to tasks, and track task work and status.

Are you a project manager? If so, welcome to Project Web App! You can use this tool to create projects, schedule tasks, assign tasks to resources, approve timesheets, and review task progress.

In this article:

  • What is Project Web App?

  • Where do you start?

  • How to get help

What is Project Web App?

Project Web App is one part of an end-to-end enterprise project management solution. This solution includes a client program, Microsoft Project Professional, and a server, Microsoft Project Server. Project Web App is part of Project Server. It is a robust Web application that is used to do everything from analyzing portfolios and managing demands, to entering time in a timesheet and updating task status.

Get oriented

The Project Web App interface is made up of three main areas: the Quick Launch, the Ribbon, and the content display area.

The Quick Launch, on the left side of the window, lists the main views and pages that you are able to access. You can click these links to browse to different areas of the program. Some pages in Project Web App do not include the Quick Launch. For example, when you fill out a form, you must complete and save the form or cancel out of it in order to return to the Quick Launch.

The Ribbon is the toolbar that you use to perform actions on the project information in the content display area. There may be multiple tabs on the Ribbon, to change between different sets of actions. Each tab contains groups of related buttons that you can use to interact with the page content.

The content display area contains information about your portfolios, projects, and tasks. This is the main focus of each page, and is where you will enter and review data.

Where do you start?

Project Web App is highly customizable, so your organization can have a unique starting page. By default, the main page that appears when you open Project Web App is a great starting point. It shows information about tasks, timesheets, approvals, status reports, issues, and risks.

There are other useful places to start in Project Web App, depending on what you intend to do while you are logged on.

Create projects and schedule tasks

In Project Web App, you can create projects and schedule tasks in the Project Center. On the Quick Launch, under Projects, click Project Center. On the Ribbon, click the Projects tab to access the tools that you can use in the Project Center. Here, you can create new projects using templates or by importing SharePoint lists. On the Projects tab of the Ribbon, click the arrow on the New button. Use the list that is displayed to decide what method you want to use to create a new project.

Once you have created a project, you can use the tools on the Project, Task, and Options tabs of the Ribbon to work with the project's tasks.

Work with resources

With a project and its tasks in place, your next step is to assign the resources that will complete the tasks. In some organizations, a resource manager may be responsible for assigning resources to tasks, but typically this falls on the project manager's plate. In Project Web App, you can add resources and manage your enterprise resource pool in the Resource Center. On the Quick Launch, under Resources, click Resource Center.

Once the resources that you need for the tasks in your project are added to the Resource Center, you can assign them to tasks by using the Project Center. On the Quick Launch, under Projects, click Project Center. Click the name of your project in the list to open it for viewing, check out the project for editing, and then build your team. Pick resources from your team to assign to tasks in your project.

Track time and task progress

Some project managers may find time and task progress tracking very important for monitoring project status. As a project progresses, team members assigned to project tasks report how much time they spend on tasks and how much work is left. As the manager of the project where this data is being reported, it is your responsibility to review and approve or reject this time and task progress as it is reported.

The Approval Center provides a central location for approving both time and task progress. On the Quick Launch, under Projects, click Approval Center. Here, you can review the data that has been reported by team members, and then either approve the data, submitting it to the project, or reject it, with notes to help communicate the reason for the rejection.

How to get help

If you are using Project Server 2010 with Microsoft SharePoint Server 2010, there are two video references that you might find helpful:

  • Webcast: Project Server 2010 and SharePoint Server 2010: Focus on Project Management (Level 200)

  • Webcast: Project Server 2010 and SharePoint Server 2010: Focus on Collaboration (Level 200)

If you experience trouble while you are using Project Web App, use the following workflow to try to find a solution.

  1. Web resources Try to find an answer to your question on Office.com or the Project Server 2010 TechCenter on TechNet. If you cannot find what you want there, you might also try the Project 2010 Solution Center.

  2. Other project managers Talk with other project managers in your organization to see whether anyone else has encountered the same issue.

  3. Site administrator If you cannot find a solution, perhaps the issue that you are encountering is not specific to your project. Contact your organization's Project Server site administrator for help. The site administrator is the person who configures Project Web App.


Getting started: Portfolio managers (Project Server 2010)

Published: January 27, 2011

In Microsoft Project Web App, portfolio managers are the people who guide project proposals through the process of comparing proposals against business needs, financial constraints, and other deciding factors.

Are you a portfolio manager? If so, welcome to Project Web App! You can use this tool to set up project proposal templates, configure workflow phases and stages, and set up and perform portfolio analyses using business drivers, cost constraints, and resource constraints.

In this article:

  • What is Project Web App?

  • Where do you start?

  • How to get help

What is Project Web App?

Project Web App is one part of an end-to-end enterprise project management solution. This solution includes a client program, Microsoft Project Professional, and a server, Microsoft Project Server. Project Web App is part of Project Server. It is a robust Web application that is used to do everything from analyzing portfolios and managing demands, to entering time in a timesheet and updating task status.

Get oriented

The Project Web App interface is made up of three main areas: the Quick Launch, the Ribbon, and the content display area.

The Quick Launch lists the main views and pages that you are able to access. You can click these links to navigate to different areas of the program. Some pages in Project Web App do not include the Quick Launch. For example, when you fill out a form, you must complete and save the form, or cancel out of it, in order to see the Quick Launch.

The Ribbon is the toolbar that you use to perform actions on what is currently in the content display area. There may be multiple tabs on the Ribbon, to change between different sets of actions. Each tab contains groups of related buttons that you can use to interact with the page content.

The content display area contains information about your portfolios, projects, and tasks. This is the main focus of each page, and it is where you enter and review data.

Where do you start?

The starting point for portfolio managers really depends on how much is already set up in your organization's implementation of Project Web App.

Step 1: Work with your site administrator

If your organization has just installed Project Web App and is still in the process of configuring it, your role as a portfolio manager is to work with the site administrator to set up the project lifecycle workflow and the layout of the pages used to gather information about project proposals.

  • Project lifecycle The project lifecycle is represented in Project Web App with a workflow that is set up by your organization's site administrator. This workflow calls out who needs to approve what at certain points during the lifecycle. Workflows are built using phases and stages.

    For example, your project lifecycle may include Create, Select, Plan, and Manage phases. Within the Create phase, you may have stages for Capture Proposal Details, Proposal Review, and Proposal Rejection. A proposal begins in the Capture Proposal Details stage. When the person proposing the project submits the details, the proposal moves to the Proposal Review stage. During this stage, if the stakeholders review the proposal and determine that it is worth evaluating further, the proposal is moved to the Select phase. If the stakeholders decide to reject the proposal, it moves to the Proposal Rejection stage, during which the reason for the rejection is communicated to the person who proposed the project.

    If your organization is in the initial stages of setting up Project Web App, defining the logic to your project lifecycle is a great starting point. You will need to think through what the phases and stages of the project lifecycle are for your organization, and communicate those to your site administrator.

  • Project detail pages While the site administrator is the person who actually sets up the pages that are used for capturing details about project proposals, the portfolio manager is responsible for determining what information needs to be captured during each phase and stage of the project lifecycle. You need to think through what information is critical for making the decisions associated with the phases and stages in the lifecycle, and then communicate that information to your organization's site administrator.

Once the site administrator has set up Project Web App to reflect this information, you can move on to the next section, where you, as the portfolio manager, will set up and prioritize your organization's business drivers.

Step 2: Set up and prioritize business drivers

Project investments should be made based on how well they contribute to achieving the business goals of an organization. Portfolio managers are responsible for capturing these business drivers in Project Web App, and then guiding them through a prioritization process with the appropriate stakeholders.

To enter your organization's business drivers in Project Web App, on the Quick Launch, under Portfolio Strategy, click Business Driver Library. You can use the tools on the Driver tab of the Ribbon to create new business drivers.

Once you have entered all of your organization's business drivers in the Business Driver Library, the next step is to prioritize those drivers. By prioritizing drivers, you are providing a more realistic representation of your organization's strategic objectives, which will ultimately yield more accurate project proposal valuations during portfolio analysis. To prioritize business drivers, on the Quick Launch, under Portfolio Strategy, click Driver Prioritizations.

Step 3: Analyze project proposals

As people begin proposing projects, your role as the portfolio manager is to analyze each proposal for inclusion in your organization's project portfolio. The results of this analysis determine whether the proposal is approved to be a project, or rejected.

To analyze the proposals that are currently submitted in Project Web App, on the Quick Launch, under Portfolio Strategy, click Portfolio Analyses. Use the tools on the Analyses tab of the Ribbon to create a new analysis.

How to get help

Microsoft has several excellent video resources to walk you through this new functionality:

  • Webcast: Overview of Project Portfolio Management Using Project Server 2010 (Level 200)

  • Webcast: Deep Dive into Project Portfolio Management Using Project Server 2010 (Level 200)

  • Webcast: Project Server 2010 Demand Management (Part 1 of 4): Overview (Level 200)

  • Webcast: Project Server 2010 Demand Management (Part 2 of 4): Create and Select Phases (Level 200)

  • Webcast: Project Server 2010 Demand Management (Part 3 of 4): Plan, Manage, and Close Phases (Level 200)

  • Webcast: Project Server 2010 Demand Management (Part 4 of 4): Test the Theory and Review (Level 200)

If you run into trouble while using Project Web App, use the following workflow to try to find a solution.

  1. Web resources Try to find an answer to your question on Office.com or the Project Server 2010 TechCenter on TechNet. If you are not able to find what you need there, you might also try the Project 2010 Solution Center.

  2. Site administrator If you are unable to find a solution, contact your organization's Project Server site administrator for assistance.


Getting started: Site administrators (Project Server 2010)

Published: January 27, 2011

Site administrators are the people who configure the Microsoft Project Web App server settings. They are responsible for setting up a wide variety of options in Project Web App, including things like security, time reporting periods, operational policies, and workflows.

Are you a site administrator? If so, content to help you get your job done can be found throughout the Project Server 2010 TechCenter and Library on TechNet.

In this article:

  • What is Project Web App?

  • Where do you start?

  • How to get help

What is Project Web App?

Project Web App is one part of an end-to-end enterprise project management solution. This solution includes a client program, Microsoft Project Professional, and a server, Microsoft Project Server. Project Web App is part of Project Server. It is a robust Web application that is used to do everything from analyzing portfolios and managing demands, to entering time in a timesheet and updating task status.

Get oriented

The Project Web App interface is made up of three main areas: the Quick Launch, the Ribbon, and the content display area.

The Quick Launch lists the main views and pages that you are able to access. You can click these links to navigate to different areas of the program. Some pages in Project Web App do not include the Quick Launch. For example, when you fill out a form, you must complete and save the form, or cancel out of it, in order to see the Quick Launch.

The Ribbon is the toolbar that you use to perform actions on what is currently in the content display area. There may be multiple tabs on the Ribbon, to change between different sets of actions. Each tab contains groups of related buttons that you can use to interact with the page content.

The content display area contains information about your portfolios, projects, and tasks. This is the main focus of each page, and it is where you enter and review data.

Where do you start?

Site administrators should start by clicking Server Settings on the Quick Launch in Project Web App. To be frank, if you are a new Project Web App site administrator, you may find yourself somewhat overwhelmed when you see how many options you can set up on the Server Settings page. You may have an easier time thinking about the server settings in bigger terms. There are server settings for people, data, projects, user interface, and Project Server. The following sections provide more information about which settings pages fall into these categories.

People

First, let's get our heads around what you need to set up in terms of people in Project Web App. In Project Web App, "people" translates to "users," so you need to first think about what kind of security you want to put in place for your user base. Project Web App has multiple security levels, which you can use to clearly define who can see and do certain things. Once you have your security model defined, you can begin adding user accounts, and applying security levels to those accounts.

Site administrators are also responsible for setting up delegations. When a user knows that he or she will be unavailable during a certain time period, and that during that period there are specific things that need to happen in a project that only that user can do, the user can request that another user be made his or her delegate for that time period. As a site administrator, you can set up that delegation, granting one user full access to everything the other user can do, for a set duration.

Data

There are several different angles to talking about data in Project Web App. The site administrator can set up different enterprise data options, such as custom fields and calendars, that are used throughout several projects. The flip side of setting up the data within the system is handling the actual database where the data is stored. The site administrator is also responsible for setting up backups, restoring the database (when necessary), and managing OLAP databases.

Projects

The site administrator sets up three different aspects of projects in Project Web App: workflows, project details, and time and task management.

In this version of Project Web App, projects are tied to a workflow, which the site administrator sets up using a combination of Microsoft Visual Studio and Project Web App. The workflow logic is defined by the portfolio manager, who provides it to the site administrator to set up. You will set up phases and stages in Project Web App, and then use Visual Studio to organize those phases and stages into a workflow.

The site administrator is also responsible for setting up the pages that are used to capture project details at each phase and stage of the workflow. The portfolio manager provides the site administrator with the information that needs to be captured, the site administrator sets up the appropriate custom fields in Project Web App, and then the site administrator adds those fields to project detail pages.

In the time and task management area of Project Web App, the site administrator is responsible for configuring reporting periods and other settings specific to tracking how much work is done on a project, and how much work remains.

User interface

The site administrator has a degree of control over the Project Web App user interface. Changes can be made to views, grouping formats, Gantt chart formats, the Quick Launch, and the layout of project detail pages.

Project Server

Finally, the site administrator is responsible for the management of certain things that are not specific to only Project Web App. These Project Server aspects that are controlled by the site administrator include the queue and several operational policies.

How to get help

If you run into trouble while administering Project Web App, be sure to look for answers in the Project Server 2010 TechCenter and Library on TechNet.


About the Quick Launch in Project Web App

Published: February 24, 2011

The Quick Launch is the pane that appears on the left side of Microsoft Project Web App. You can use the Quick Launch to access Project Web App features such as tasks and timesheets.

In the version of Project Web App that is included with Microsoft Project Server 2010, the Quick Launch may contain any combination of the following headings and links:

  • Projects

    • Project Center

    • Approval Center

    • Workflow Approvals

  • My Work

    • Tasks

    • Timesheet

    • Issues and Risks

  • Resources

    • Resource Center

    • Status Reports

  • Strategy

    • Driver Library

    • Driver Prioritization

    • Portfolio Analyses

  • Business Intelligence

  • Settings

    • Personal Settings

    • Server Settings

    • Manage Timesheets

  • Libraries

    • Shared Documents

The Quick Launch displays different links based on your permissions within Project Web App, and it can also be customized for your specific organization. The list in this article represents what a Project Server administrator sees, by default, on the Quick Launch.

Note:

The Quick Launch does not appear on every page. It is not displayed on some site administration pages, such as the Site Settings page, and the pages on which a site administrator creates and edits lists, libraries, and project workspaces.


Overview: Customize your enterprise project management solution (Project Server 2010)

Published: January 27, 2011

Microsoft Project Server 2010 includes new features that help you customize what project, resource, and task data is displayed for users. It also includes new features that integrate with Excel Services in SharePoint, making it easier to create rich custom reports. With these new features, Project Server 2010 offers a flexible, unique enterprise project management solution for your organization.

What do you want to do?

  • Customize what data is displayed for users

  • Create rich custom reports

Customize what data is displayed for users

Project Server 2010 lets you associate project types, resources, and custom fields with departments. This helps provide a focused view of project and task information based on which departments a user belongs to. For example, if Bob is assigned to the HR department, he will have a filtered view of the project types and custom fields available to those users who are part of the HR department. Although departments are not a security feature, they can be helpful in de-cluttering what a user sees, making it easier to find or provide the most suitable information about projects and tasks.

Task | Description
Associate a resource with a department (Project Server 2010) | By associating a resource with a department, you make it so that resource has a filtered view of custom fields and project types available for that department.
Associate a custom field with a department (Project Server 2010) | By associating a custom field with a department, you make it so that the field is available only to resources that are also associated with that department.
Associate a project type with a department (Project Server 2010) | By associating a project type with a department, you make it so that only resources in that department can use that project type to propose or create a new project.
Add or edit an Enterprise Custom Field (Project Server 2010) Add or edit an Enterprise Custom Lookup Table (Project Server 2010) | Use custom fields and lookup tables to capture data that may be unique to your project or organization. New to Project Server 2010 is the ability to add workflow-controlled custom fields and multi-lined custom fields.

Create rich custom reports

In Project Server 2010, reporting is integrated with Excel Services, and additional data is available to include in your organization's reports. You can now include timesheet custom fields, portfolio data, project properties, and the Combined Work field. Reports are typically customized by the site administrator.

Task | Description
Learn about the BI Center | The BI Center includes several default reports, and may include custom reports for your organization.
Create a reporting view (Project Server 2010) | Site administrators can create or modify the connections to data that is used in reporting, and also the templates used by the reports.


Overview: Set up and submit project proposals (Project Server 2010)

Published: January 27, 2011

Microsoft Project Server 2010 includes new features to help guide you through the process of proposing new projects and sending them through a workflow. Before you can propose new projects, the portfolio manager and site administrator must work together to set up the workflow, project detail pages, and templates used during the process. Your first run through the process may be a little intimidating, but it is more straightforward than it looks.

In this article:

  • Set up the proposal process

    • Workflows

    • Project detail pages

    • Enterprise project types

    • Approvals

  • Propose a new project

Set up the proposal process

Before users can begin proposing projects, the portfolio manager and the site administrator must work together to set up the proposal process. This process has several parts: workflows, project detail pages, enterprise project types, and approvals.

Workflows

Let's back up a bit. In Microsoft Project Web App, when a project is proposed, it goes through a workflow to determine whether it fits in with the strategic and financial goals of the organization, and, ultimately, to determine whether it is approved as a viable project. Before projects can be proposed, the portfolio manager must work with the site administrator to set up Project Web App with an infrastructure that corresponds to the way your organization works. Sound complicated? Really what you are doing is taking the way that you evaluate project proposals now, and turning that process into the more formal phases and stages supported by Project Web App. The result is a seamless process that takes you from a simple proposal all the way to a working project that you can capture time and report against.

Task | Description
Workflow Phases (Project Server 2010 settings) | The portfolio manager works with the site administrator to set up a workflow for proposals in your organization.
Note:

Want more information on workflows? Try watching this series of webcasts:

  • Webcast: Project Server 2010 Demand Management (Part 1 of 4): Overview (Level 200)

  • Webcast: Project Server 2010 Demand Management (Part 2 of 4): Create and Select Phases (Level 200)

  • Webcast: Project Server 2010 Demand Management (Part 3 of 4): Plan, Manage, and Close Phases (Level 200)

  • Webcast: Project Server 2010 Demand Management (Part 4 of 4): Test the Theory and Review (Level 200)

Project detail pages

Next, the portfolio manager creates project detail pages. That is a fancy way of referring to the forms people fill out when they are proposing a project. The portfolio manager chooses which fields are included where, and may create more than one page to use during different parts of the workflow. For example, you might have one very simple page that people can fill out to submit a proposal, or you might have another, more complicated page for approvers to fill out to add information to the proposal during the review process. It is just a way of slicing and dicing when and where information is added and who is adding it during the workflow.

Task | Description
Create a Web page to submit proposals | The portfolio manager creates the forms that will be used to gather information about the proposal throughout the workflow.

Enterprise project types

Next, portfolio managers need to set up enterprise project types. These are the templates that users choose from when creating a new project or proposal. Enterprise project types are the way Project Web App brings together workflows with project detail pages. You may have several enterprise project types in your organization. For example, the HR department might have one enterprise project type, with its own set of project detail pages and its own workflow, while the Sales department may have a separate enterprise project type, with a separate workflow and set of project detail pages. This ensures a proposal experience that really hones in on what the user is trying to accomplish.

Task | Description
Enterprise Project Types (Project Server 2010 settings) | The portfolio manager sets up an enterprise project type, which is the template that people use to propose projects.

Approvals

Finally, the portfolio manager needs to set up the approval process. When a project is proposed, certain individuals in your organization have to review the proposal and accept it or reject it. The portfolio manager has to identify who those reviewers are, and in what order they should receive the proposal for review. Once this approval chain is set up, users can begin submitting proposals.

Task | Description
Create the approval process for a proposal (Project Server 2010) | The portfolio manager sets up the approval process, identifying which users have to review submitted proposals, in what order.

Propose a new project

Once the portfolio manager and site administrator have set up the proposal process, submitting a new project proposal is quite simple. Once a project is proposed, the workflow begins, and the approvers are notified that a proposal is ready for review. The review process may include several steps, including the more complex steps involved with portfolio analysis. To learn more about this process, see Overview: Analyze and approve project proposals (Project Server 2010).

Task | Description
Create or edit a project or proposal (Project Server 2010) | You can use the project detail pages, set up by the portfolio manager, to create a new project or proposal.


Overview: Analyze and approve project proposals (Project Server 2010)

Published: January 27, 2011

Microsoft Project Server 2010 includes new features to help you evaluate whether project proposals fit in with your organization's business strategy and with its financial and resource constraints. Once the appropriate people have determined which proposals make the most sense to implement, then the proposals can be approved as projects.

Note:

This article assumes that proposals have already been submitted. For more information about proposals, see Overview: Set up and submit project proposals (Project Server 2010).

What do you want to do?

  • Analyze proposals

  • Approve proposals

Analyze proposals

When users submit project proposals for review, the portfolio manager is responsible for guiding them through the analysis process. Reviewers analyze the proposals to determine whether they are viable projects for your organization. If a project is considered viable, it is approved and becomes part of your organization's project portfolio. This process is also known as portfolio analysis.

What kinds of things are reviewers analyzing when they review project proposals?

  1. First, reviewers look at the relative priority of each proposal. How well does this proposal fit in with what your business is trying to achieve? The portfolio manager helps the reviewers evaluate the proposal's effect on the organization's business drivers, resulting in a rated list of all of the proposals included in the analysis.

  2. Then, the reviewers examine each proposal's value, relative to the organization's high-level cost constraints. If a proposal will cost more than your budget allows, it may not be a viable project for your organization.

  3. Finally, the reviewers examine each proposal's resource requirements. Does the proposal require an unreasonable number of resources given its schedule needs? Reviewers examine how adjusting the number of resources or the schedule will affect whether the proposal is a viable project.

After reviewing these factors, a subset of the proposals will stand out as having the greatest strategic value with the most reasonable cost and resource needs. These proposals are selected for approval as projects.

Task | Description
Create analyses and prioritize projects (Project Server 2010) | Create an analysis, where you try different ways of fitting proposals into your portfolio and prioritize the proposals you are analyzing.
Analyze portfolio based on high-level cost constraints (Project Server 2010) | Reviewers evaluate each proposal's effect on your organization's budget.
Analyze portfolio based on time-phased resource requirements (Project Server 2010) | Reviewers evaluate each proposal's resource and schedule needs, and they try to find a balance that works with the portfolio.
Commit selection decisions and communicate to portfolio stakeholders (Project Server 2010) | The selection decisions are made, and stakeholders are notified.

Approve proposals

Once selection decisions are made, the next step is to approve the proposals as projects.

Task | Description
Approve or reject a proposal (Project Server 2010) | Use the Workflow Tasks page in Microsoft Project Web App to review and approve or reject a project proposal.


Overview: Manage projects (Project Server 2010)

Published: January 27, 2011

Microsoft Project Server 2010 provides professional, part-time, and informal project managers with the tools that they need to plan and execute projects on the Web. New features in this area include synchronization with SharePoint lists, top-down project planning, and user-controlled scheduling.

In this article:

  • Create new projects

  • Plan project work

  • Control project schedules

Create new projects

Microsoft Project Web App offers several ways to create new projects. If your organization uses a formal project proposal and selection process, you will want to read Overview: Set up and submit project proposals (Project Server 2010) and Overview: Analyze and approve project proposals (Project Server 2010) to fully understand the project proposal process.

If your organization does not use a formal selection process, you can create a new project by using a template, or by synchronizing with a SharePoint project tasks list. Projects often start as informal lists of work items that are shared among a team. Sometimes these lists are captured by using SharePoint Server. When that is the case, you can easily synchronize your SharePoint project tasks list with Project Web App, which provides a smooth transition from casual project planning to more formal project planning.

Task | Description
Create or edit a project or proposal (Project Server 2010) | Depending on your organization's project proposal practices, you can create a project or you can submit a project proposal for review.
Create a project from a SharePoint tasks list (Project Server 2010) | You can synchronize a project tasks list in SharePoint Server with Project Server 2010.

Plan project work

In this version of Project Web App, you can plan projects by using a top-down method. That is, the tasks that fall inside a summary task do not have to use dates that line up exactly with the summary dates.

In a typical organization, when decision makers and stakeholders have selected and approved a set of projects, project managers are responsible for scheduling the specific work items in the project. During initial planning, project managers may start by sketching a set of high-level phases and key milestones based on business needs and delivery timeframe. At this point, the project manager may not have complete information about all of the work items and the time required for each one. For example, a project manager may know that he has up to five weeks to complete a certain phase in a project, but he may not have all of the information yet to schedule each task within that phase.

The top-down planning features that are included in this version of Project Web App enable that project manager to create a plan with a summary phase, "Develop Widget," that lasts for five weeks. Then, the project manager can enter known work items that span only three weeks, with additional work scheduled in the future, based on the available buffer time. Top-down planning also enables the project manager to enter subtasks that start before the official start date of the phase and that end after the official phase end date.

Task | Description
Create top-down summary tasks (Project Server 2010) | Use top-down summary tasks for initial project planning, when you do not have all of the details about the work items in a project.
Create a new task (Project Server 2010) | Once a project is created, you are ready to start scheduling tasks.

Control project schedules

In previous versions of Project Server, schedules were controlled by using a highly structured, systematic approach that took things such as task duration, various calendars, number of resources, and other factors into consideration. Based on these factors, Project Server calculated the optimal schedule for the project automatically. Project Server 2010 supports this traditional, "automatic" scheduling method that you have seen in previous versions, but it also introduces a new "manual" scheduling method.

Manual scheduling is much less formal. With manual scheduling, projects may begin as simple lists of dates from e-mail messages, meetings with stakeholders, or even hallway conversations. Project managers rarely have complete information about work items when scheduling a project. For example, a project manager may only be aware of when a task has to be started, but not its duration until he has an estimate from his team members. Or, the project manager may know how long a task will take, but will not know when it can be started until he has approval from the resource manager.

When a task is manually scheduled, the Start, Finish, and Duration fields can be blank, or can hold text in addition to recognizable dates. For example, if you cannot set a date until you receive information from someone else, you might enter "Pending JohnT's estimate" in the start date field until you can provide a date for the schedule. Dates for manually scheduled tasks will not be automatically filled in by Project Server 2010 as it performs its calculations.


Overview: Track your time and task progress (Project Server 2010)

Published: January 27, 2011

Microsoft Project Web App enables you to easily track the time you spend on a project's tasks, and the progress of those tasks toward completion. You can also enter time spent on administrative tasks, like vacation, travel, training, and sick leave. In this version of Project Web App, you can enter time and task progress by using the same view, or by using separate views.

What do you want to do?

  • Set up time and task reporting

  • Enter and submit time and task progress

  • Approve or reject time and task progress

Set up time and task reporting

There are several things that the site administrator needs to set up in Project Web App before team members can begin reporting their time and task progress.

Task | Description
Set up time reporting periods | Time reporting periods are used on both the My Tasks and the My Timesheets pages, and they must be set up before either page can be used.
Line classifications (Project Server 2010 settings) | Timesheet line classifications are used to provide detail about project tasks. For example, you might have overtime classifications that include Holiday Time, Double Time, and so on.
Configure timesheet settings and defaults | Timesheets can be configured in several ways that apply business rules to how users are allowed to track time. This is where you can turn on single entry mode, which is new in this version of Project Web App.
Configure administrative time categories | By default, Project Web App provides three administrative time categories: Sick, Vacation, and Administrative. Your organization may have specific categories that meet your needs.
Configure task settings and display | Task progress updates can be configured in several ways to meet your organization's needs.

Enter and submit time and task progress

As team members work on tasks, they can enter the time they have spent on those tasks by using a timesheet, and enter progress toward task completion either in the same view as the timesheet (called single entry mode), or in a separate view, depending on how the site administrator has set up Project Web App.

Task | Description
Report work on my timesheet | To start entering time spent on tasks, create your timesheet.
Report the status of my tasks | You can report your task progress on the same view as your timesheet, or in a view that is separate from your timesheet.
Add or remove a timesheet task (line) | If a task that you worked on during a time period is not showing up on your timesheet, you can add it as a separate line.
Add a task to my task status | If a task that you worked on during a time period is not showing up to report task progress, you can add that task to your status.

Approve or reject time and task progress

Once a team member submits a timesheet or task progress, the next step is for the approver(s) to review what has been submitted, and then approve or reject it.

Task | Description
Approve or reject entire timesheets | If an approver has many timesheets pending approval, he or she may find it most efficient to approve or reject entire timesheets, rather than reviewing each timesheet line.
Approve tasks or timesheet lines | In this version of Project Web App, approvers can approve or reject individual task progress updates or timesheet lines.


Discontinued features and modified functionality in Project Server 2010

Published: January 27, 2011

For users who are familiar with previous versions of Microsoft Project Server, the following sections describe features and functionality that have been discontinued or changed in Microsoft Project Server 2010.

Project Portfolio Server changes

Project Server and Microsoft Office Project Portfolio Server are no longer two separate products. Relevant portfolio functionality from Office Project Portfolio Server 2007 has been merged into Project Server 2010. The following Office Project Portfolio Server 2007 features and functionality were discontinued or changed for Project Server 2010:

  • Application portfolio management This includes tracking and managing applications.

  • Audit Trail Workflow activity was previously made available from the Audit Trail link in the Workflow module. In Project Server 2010, this information is available in the Workflow History list, which can be accessed from the Additional Workflow Data link in the All Workflow Stages section.

  • Benefits estimating This includes estimating and tracking financial and non-financial benefits.

  • Organizational hierarchy and aggregates This includes a security-based hierarchical data grouping and aggregation. In Project Server 2010, departments have been added to enable hierarchical data grouping based on organizational structure.

  • Dynamic charting This includes the Chart Wizard, which allows for ad-hoc interactive chart creation, including bubble chart modeling. In Project Server 2010, Excel Services support has been added, which provides a new method of dynamic reporting.

  • Financial management This includes time-phased budget, actual, and forecast cost tracking. In Project Server 2010, use custom fields and Excel Services to enable cost functionality for simple estimation, tracking, and forecasting costs. Solutions for more complex estimating, tracking, and forecasting costs are offered by Microsoft partners.

  • Insight analysis This enabled users to get specific details into the factors that affect a specific portfolio selection.

  • Decision dashboard This enabled users to make selection decisions supported by a rich dashboard with live grouping and charting.

  • Sensitivity analysis This enabled users to take a portfolio selection through various what-if scenarios and figure out how close a project was to being selected.

  • Snapshotting and versioning This enabled users to create cost, resource, and benefit snapshots at any given point in time. In Project Server 2010, reporting and baselining can be used to capture data snapshots.

  • Surveys This includes flexible, user-definable survey forms, on subjects related to risk, architectural fit, and operational performance.

Other changes

In addition to the portfolio functionality changes, following are other changes implemented in Project Server 2010.

  • Outlook add-in The Microsoft Outlook add-in for Project Server has been discontinued in Project Server 2010. The existing add-in can still connect to Project Server 2010; however it has not been updated for this release. Instead, Project Server 2010 is integrated with Microsoft Exchange Server so that users no longer have to download a separate COM add-in. The timesheet functionality that was present in the Outlook add-in has been discontinued.

  • Activity plans and personal projects Microsoft Office Project Server 2007 included the ability to create and manage activity plans, also known as lightweight projects, and personal projects from inside Office Project Web Access. Instead, Project Server 2010 supports editing any project on the server by using a rich, new grid control in Project Web App.

  • Color indicators on the My Tasks page Color indicators on the My Tasks page have been replaced with the text from the tool tip for the indicator on the Tasks page, paired with a background color for the text.

  • Data analysis The underlying technology that is used for data analysis in previous versions, Office Web Components, has been discontinued. In Project Server 2010, this technology has been replaced with Excel Services.


Setting up Project Web App (Project Server 2010)

Published: January 27, 2011

There are several ways that you can customize Microsoft Project Web App to meet your organization's needs. Articles in this section cover the following:

  • Security (Project Server 2010 settings)

  • Look and Feel (Project Server 2010 settings)

  • Enterprise Data (Project Server 2010 settings)

  • Time and Task Management (Project Server 2010 settings)

  • Workflow and Project Detail Pages (Project Server 2010 settings)


Overview: Setting up resource constraint analysis (Project Server 2010)

Published: January 27, 2011

Resource constraint analysis is one part of the portfolio analysis process in Microsoft Project Server 2010. When stakeholders are evaluating project proposals to determine which should be approved and added to the organization's portfolio of projects, they use resource constraint analysis to weigh the resource needs of a project proposal with the resource capacity of the organization.

Before resource constraint analysis can occur, some different elements must be configured correctly: primary roles, capacity planning, and demand planning.

In this article:

  • Configuring primary resource roles

  • Configuring resource capacity planning

  • Configuring resource demand planning

Configuring primary resource roles

Project Server 2010 relies on defined roles for resource constraint analysis. Examples of roles include Developer, Tester, and Business Analyst. Each resource, whether a named resource (a "real person") or a generic resource (a placeholder), must be associated with a single primary role to be considered during resource constraint analysis.

Who sets up resource roles? Resource roles are configured in Project Server 2010 by the site administrator.

Where can I learn more? For more information about how to set up resource roles, see Define your organization's resource roles (Project Server 2010).

Configuring resource capacity planning

Before stakeholders can determine whether a proposal can be approved, all available resources in the organization must be accounted for to determine resource capacity. Once there is a good understanding of what resources are available to assign to projects at a given time, stakeholders can compare the available resource capacity with the resource needs of each project proposal during resource constraint analysis. Resource capacity can account for individual named resources (for example, employees in your organization), or non-named resources that represent people, equipment, or other named resources that will be hired (or otherwise obtained) later. Each resource that is used to represent capacity must be associated with a single primary role.

Who sets up capacity planning? Capacity planning is typically configured by resource managers, project managers, or portfolio managers in your organization, depending on how the site administrator has configured permissions.

Where can I learn more? For more information about how to configure capacity planning, see Create resources to represent capacity (Project Server 2010).

Configuring resource demand planning

When submitting a project proposal, the submitter can assign named ("real") or generic (placeholder) resources to tasks to represent the resource needs of the project. Stakeholders can take these resource demands into account when they review the proposal and compare the demands with the resource capacity of the organization. If the demand can be met by capacity, the proposal may have a better chance of being approved than one that requires additional resources to be hired or acquired. Before resource demand can be included in a proposal, resources must be created to represent demand by role type. Generic resources should be used when the role type and quantity needed for a project (for example, two Developers) is known. But the actual people doing the work are not known or not important at this point of planning.

Who sets up resources for demand planning? Resources are typically configured by resource managers, project managers, or portfolio managers in your organization, depending on how the site administrator has configured permissions.

Who assigns resources to proposals? The person submitting the project proposal may choose to assign resources to tasks in the project, or to the overall project itself. This person may be a project manager, but may also be a team member or other stakeholder.

Where can I learn more? For more information about how to set up resources for demand planning, see Create generic resources to represent resource needs (Project Server 2010). For more information about how to assign resources to proposals for demand planning, see Specify resource needs in a project proposal (Project Server 2010).


Define your organization's resource roles (Project Server 2010)

Published: January 27, 2011

Resources in your organization may have different roles that represent the work that they do. Configuring these roles in Microsoft Project Web App is a two-step process. First, you have to create a list of all of the roles in your organization, and then you have to assign that list to a custom field.

Create a list of resource roles

  1. On the Quick Launch, under Settings, click Server Settings.

  2. In the Enterprise Data section, click Enterprise Custom Fields and Lookup Tables.

  3. On the Enterprise Custom Fields and Lookup Tables page, scroll down to the Lookup Tables for Custom Fields section, and then click New Lookup Table.

  4. Type Role in the Name field.

  5. In the Lookup Table section, type the name of each role in your organization in the Value column.

  6. Click Save.

Assign the list of roles to a custom field

  1. On the Quick Launch, under Settings, click Server Settings.

  2. In the Enterprise Data section, click Enterprise Custom Fields and Lookup Tables.

  3. On the Enterprise Custom Fields and Lookup Tables page, in the Enterprise Custom Fields section, click New Field.

  4. Type Role in the Name field.

  5. In the Entity and Type section, click the Entity list, and then click Resource.

  6. In the Custom Attributes section, click Lookup Table, and then select Role from the list that appears.

  7. Click Save.


Create resources to represent capacity (Project Server 2010)

Published: January 27, 2011

When you are analyzing which projects your organization can take on, an important factor to consider is the expected resource capacity. That is, a summary of what resources are available to work on a proposed project. In Microsoft Project Web App, you can define resources to represent resource capacity by your organization's resource roles. You can use individual named resources ("real" people), non-named resources ("to be hired" people), or a combination of both.

Note:

Each resource that is used to represent capacity must be associated with a single primary role.

What do you want to do?

  • Configure non-named resources to represent capacity

  • Configure named resources to represent capacity

  • Use named and non-named resources to model capacity

Configure non-named resources to represent capacity

When you are modeling resource capacity without creating individual named resources, the idea is to create one resource for each role that you defined in the Role lookup table. For example, you want one resource to represent all developers, another resource to represent all testers, and so on. If you have not defined roles in a lookup table, see Define your organization's resource roles (Project Server 2010).

  1. On the Quick Launch, under Resources, click Resource Center.

  2. On the Resources tab of the ribbon, click New Resource.

  3. In addition to the required fields, complete the following fields:

    • Resource can logon to Project Server: Cleared

    • Display Name: <Role name> - Capacity (For example, "Developer - Capacity.")

    • Max Units: Type a percentage that represents the number of resources that you have available for this role. For example, if you have 10 developers available at 100% of their time, enter 1000%.

    • Role: Choose the role that corresponds to the display name that you have specified. For example, if you typed "Developer - Capacity" in the Display Name box, click Developer in the Role list.

  4. Click Save, and then repeat Steps 2 and 3 for each role in your organization's Role lookup table.

Configure named resources to represent capacity

To use named, or "real," resources to represent capacity, there are two considerations:

  • Must be an enterprise resource Each named resource must have been created as an enterprise resource in Microsoft Project Server 2010. Not all Project Server 2010 users are also available as resources. For more information, see Add a user account in Project Server 2010.

  • Must have a defined role Each named resource should have an associated role set in his or her resource properties.

When you are evaluating whether your organization has the resource capacity to take on specific project proposals, you can use any named resource that meets both conditions.

Use named and non-named resources to model capacity

The key to modeling capacity using both named and non-named resources is to flag them separately for reporting. First, you have to create a custom field that you will use for flagging.

  1. On the Quick Launch, under Settings, click Server Settings.

  2. In the Enterprise Data section, click Enterprise Custom Fields and Lookup Tables.

  3. On the Enterprise Custom Fields and Lookup Tables page, in the Enterprise Custom Fields section, click New Field.

  4. Type Used for placeholder capacity in the Name box.

  5. In the Entity and Type section, click Resource in the Entity list, and then click Flag in the Type list.

  6. Click Save.

With this custom flag set up, you can now identify named resources as placeholders by clicking Yes in the Used for placeholder capacity list, in the Resource Custom Fields section of the New Resource, Edit Resource, New User, or Edit User page.

For non-named resources, leave the Used for placeholder capacity list set to No. This way, in a list of resources with a specific role, you can filter named versus non-named resources using the Used for placeholder capacity flag.


Create generic resources to represent resource needs (Project Server 2010)

Published: January 27, 2011

When you are proposing a project, generic resources can help indicate demand for resources in a specific role. This helps with capacity planning and can be a deciding factor during portfolio analysis. To facilitate the use of generic resources in the proposal process, the first step is to create one generic resource for each role defined in the Role lookup table. For example, you want one generic resource to represent all developers, another generic resource to represent all testers, and so on. If you have not defined roles in a lookup table, see Define your organization's resource roles (Project Server 2010).

  1. On the Quick Launch, in the Resources section, click Resource Center.

  2. On the Resources tab of the ribbon, click New Resource.

  3. In addition to the required fields, complete the following fields:

    • Generic: Selected

    • Resource can logon to Project Server: Cleared

    • Display Name: <Role Name> - Demand (For example, "Developer - Demand")

    • Role: Choose the role that corresponds to the display name you have specified. For example, if you typed "Developer - Demand" in the Display Name box, click Developer in the Role list.

  4. Click Save, and then repeat Steps 2 and 3 for each role in your organization's Role lookup table.


Specify resource needs in a project proposal (Project Server 2010)

Published: January 27, 2011

You can identify the resource needs for a proposed project at a high project level, a detailed task level, or a combination of both.

What do you want to do?

  • Provide a high-level estimate of resource needs

  • Provide a detailed estimate of resource needs

  • Provide high-level and detailed estimates of resource needs

Provide a high-level estimate of resource needs

You can use a resource plan to communicate high-level estimates of what kinds of resources your project requires.

  1. On the Quick Launch, in the Projects section, click Project Center.

  2. Click the name of your project in the Project Name column.

  3. On the Project tab, in the Navigate group, click Resource Plan.

  4. On the Plan tab, in the Resources group, click Build Team.

  5. Select the check box in the left column of the left box for each named or generic resource that you think that your project will require.

    Note:

    When choosing generic resources, make sure that you select the resources that use the "<Role Name> - Demand" naming convention. For more information, see Create generic resources to represent resource needs (Project Server 2010).

  6. Click Add to move the selected resources to the box on the right.

  7. On the Team tab, in the Team group, click Save & Close.

  8. On the Plan tab, in the Date Range group, click Date Range.

  9. Enter the From and To dates for the period during which the resources are needed, and then click OK.

  10. On the Plan tab, in the Display group, change the Work Units and Timescale settings to specify how you want to enter work estimates.

    For example, select Full-time Equivalent from the Work Units list, and Months from the Timescale list, to provide the estimated number of months your full-time resources would be needed for this project.

  11. On the Plan tab, in the Resource Utilization group, click Resource Plan in the Calculate from list.

  12. For each resource in the table, specify the amount (work units) required of each resource per timescale unit. For example, if the timescale is set to months, you can fill out the table to indicate how many of each resource this project will need during each month in the specified date range.

  13. Click Save, then click Publish, and then click Close to close the resource plan.

Provide a detailed estimate of resource needs

If you have a more detailed project schedule in place, with the expected tasks, dates, and durations, you can provide a detailed estimate of your proposal's resource needs by assigning named or generic resources to tasks in the project proposal.

Provide high-level and detailed estimates of resource needs

If you only know project details such as tasks, dates, and durations up to a certain point in your project proposal, you can use a combination of detailed, task-level estimates and high, project-level estimates. Begin by assigning named or generic resources to the tasks that you have defined in your project, and then add the high, project-level estimates using a resource plan.

  1. Assign named or generic resources to the tasks that you have defined in your project proposal.

  2. Create a resource plan for the rest of your project proposal, when you are unsure of the task details. For more information, see the Provide a high-level estimate of resource needs section, earlier in this article.

  3. In the resource plan, on the Plan tab, in the Resource Utilization group, click Project Plan until in the Calculate from list. Enter the date when you want to switch from using the detailed, task-level estimates, to the estimates you provided in the project plan.

Now, the resource constraints for this proposal are analyzed by using the task assignments you provided and the resource plan estimates after the Calculate from date that you identified in step 3.


Associate a custom field with a department (Project Server 2010)

Published: January 27, 2011

Microsoft Project Server 2010 includes a new way to help narrow the data that users can see, based on their departments. You can assign departments to custom fields, and those fields will only be available to users who are part of the corresponding departments.

  1. On the Quick Launch, click Server Settings.

  2. Under Enterprise Data, click Enterprise Custom Fields and Lookup Tables.

  3. In the Enterprise Custom Fields table, click the name of an existing custom field, or click New Field to create a new custom field.

  4. On the Edit Custom Field or New Custom Field page, in the Department section, click the button next to the Department field, and then click the name of a department to select it.

  5. If you are creating a new custom field, complete each appropriate section on the page.

  6. Click Save to save the custom field, with the departmental association.


Find custom fields associated with a department (Project Server 2010)

Published: January 27, 2011

You can sort the list of all custom fields in Microsoft Project Web App to show which custom fields are associated with a specific department.

  1. On the Quick Launch, click Server Settings.

  2. In the Enterprise Data section, click Enterprise Custom Fields and Lookup Tables.

  3. Click the Department column header in the Enterprise Custom Fields table to sort the custom fields by department.


Overview: Enter time and task progress in one view (Project Server 2010)

Published: January 27, 2011

Microsoft Project Server 2010 introduces the ability to enter the time you spend on project tasks and the progress you are making against that task in one view. This feature is called "single entry mode" and can be turned on or off by your site administrator.

In this article

  • Understanding time versus task progress

  • Advantages to using single entry mode

  • Turn on single entry mode

  • Related information

Understanding time versus task progress

First, let's make sure we are clear on the differences between time and task progress. Time is the actual number of hours you spend working on a specific task. This is what you fill out on a timesheet to capture the number of hours you spent on different things during your work week. Task progress is an umbrella term for things like percent complete and remaining work. Submitting task progress is a way to capture a broader description of what you currently have done on a specific task, and what you think there is left to do to complete the task.

Let's look at an example to get clear on the differences between these two task update methods. You are assigned to a task that has a duration of 5 days (or 40 hours). You spent 8 hours on the task on Monday, 4 hours on Tuesday, and 8 hours on Wednesday, for a total of 20 hours. This is the information you would enter on a timesheet. However, when looking at the work you did from a task progress perspective, even though 20 of 40 hours have been spent on the task, you may not feel that you are 50% complete. You may think you are farther along, say 60% complete, or a bit behind, maybe 35% complete. When you communicate your estimated percent complete, this is your task progress. Communicating your estimated number of hours left on the task is also considered your task progress.

Advantages to using single entry mode

Project Server 2010 enables site administrators to set up Microsoft Project Web App so that team members can enter and submit time and task progress using two separate views, or by using single entry mode, where actual work is captured in one view, and submitted to both the task project plan (as task progress) and the timesheet.

Single entry mode eliminates the duplicate effort involved with submitting time and task progress separately. When you are using separate views to enter time and task progress, you have to do one of the following:

  • Enter the hours spent on a task in both the Timesheet view and the Tasks view.

  • Import the hours spent on a task from the Timesheet view to the Tasks view.

  • Import the hours spent on a task from the Tasks view to the Timesheet view.

While some organizations require this separation, the more streamlined method of entering hours is by using single entry mode. With single entry mode turned on, you only have to enter your actual work in one view, where it gets submitted both to the task project plan and to the timesheet.

Note:

When you are using single entry mode, task progress is entered as actual work, not as a percent complete. If you prefer to enter task progress as a percent complete, discuss the option of not using single entry mode with your site administrator.

Turn on single entry mode

Site administrators can turn on single entry mode on the Server Settings page to enable users to enter time and task progress in the same view.

  1. On the Quick Launch, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Timesheet Settings and Defaults.

  3. Select the Single Entry Mode check box, and then click Save.

Related information

For more information about timesheets and task status, check out these resources:

  • Training: Microsoft Project Server 2010 - Timesheet and Statusing

  • Overview: Track your time and task progress (Project Server 2010)


Associate a project type with a department (Project Server 2010)

Published: January 27, 2011

When users create new projects in Microsoft Project Web App, they choose from a list of different types of projects. You can associate these project types with departments. For example, there may be separate types for marketing projects, IT projects, HR projects, and so on.

  1. On the Quick Launch, click Server Settings.

  2. In the Workflow and Detail Pages section, click Enterprise Project Types.

  3. Click the name of an existing project type, or click New Enterprise Project Type to create a new one.

  4. In the Departments section, click the button to the right of the Departments field, and then choose the department that you want to associate with this enterprise project type.


Managing portfolios (Project Server 2010)

Published: January 27, 2011

Microsoft Project Web App introduces portfolio management features in the version that ships with Microsoft Project Server 2010. Articles in this section cover the following:

  • Portfolio Analysis with Microsoft Project Server 2010 (white paper)

  • Managing the proposal process (Project Server 2010)

  • Analyzing portfolios (Project Server 2010)


Portfolio Analysis with Microsoft Project Server 2010 (white paper)

Published: March 17, 2011

This white paper is a comprehensive user guide for the Portfolio Analysis module of Microsoft Project Server 2010. The intended audience for this document is an experienced non-technical user or PMO administrator charged with analyzing portfolios of projects within Project Server 2010.

This white paper assumes that the reader has a basic understanding of the mechanics of working with resource loaded projects within Microsoft Project Professional 2010.

This white paper does not address the technical aspects of configuring Project Server 2010 to support Portfolio Analysis, that is, any of the functionality typically found on the Server Settings page of Microsoft Project Web App (with several minor exceptions as noted). This white paper does not address the implementation of workflow to support organizational Demand Management practices, including discussion of Project Detail Pages or Enterprise Project Types.

In other words, this white paper focuses primarily on the new functionality that is behind these three simple links on the Project Web App Quick Launch:

  • Driver Library

  • Driver Prioritization

  • Portfolio Analyses

Download as a Microsoft Word (.doc) file (http://go.microsoft.com/fwlink/p/?LinkId=213746) (11.7 MB)

Download as a PDF file (http://go.microsoft.com/fwlink/p/?LinkId=213747) (8.77 MB)

Download as an XPS file (http://go.microsoft.com/fwlink/p/?LinkId=213748) (11.3 MB)


Managing the proposal process (Project Server 2010)

Published: January 27, 2011

The proposal process in Microsoft Project Web App involves defining the approval process and approving or rejecting proposals. Articles in this section include the following:

  • Create the approval process for a proposal (Project Server 2010)

  • Approve or reject a proposal (Project Server 2010)

  • Overview: Setting up resource constraint analysis (Project Server 2010)

  • Define your organization's resource roles (Project Server 2010)

  • Create resources to represent capacity (Project Server 2010)

  • Create generic resources to represent resource needs (Project Server 2010)

  • Specify resource needs in a project proposal (Project Server 2010)


Create the approval process for a proposal (Project Server 2010)

Published: January 27, 2011

The approval process in Microsoft Project Web App enables decision-makers to tightly control which projects and proposals continue along in their life cycles. The site administrator and the server administrator work together to set up the approval process.

What do you want to do?

  • Learn about how to create an approval process

  • Create or edit a user account

  • Create or edit a user group

Learn about how to create an approval process

Although Microsoft Project Server 2010 has a standard approval process, your organization may have specific needs that require a unique approval structure.

Watch a video overviewing the approval process

Create or edit a user account

Watch a video of the following procedure

  1. On the Quick Launch, click Server Settings.

  2. In the Security section, click Manage Users.

  3. Choose to create a new user or edit an existing user.

    • To create a new user, click New User.

    • To edit an existing user, click the name of the user in the list.

  4. If you want the user to be available as a resource to assign to projects and tasks, select the User can be assigned as a resource check box.

  5. Under Display Name, type a display name for the user, and then complete any of the other optional fields in the Identification Information section.

  6. Under User Authentication, choose the authentication method for this user, and provide a User logon account.

  7. If you chose to make this user available as a project resource, complete the appropriate fields in the Assignment Attributes section.

  8. In the Exchange Server Details section, choose whether to synchronize the user's project tasks with his or her Outlook tasks by selecting or clearing the Synchronize Tasks check box.

    Tip:

    Unless your organization has a policy requiring that project tasks be synchronized with Outlook, a best practice is to check with the user before you select this check box.

  9. Under Departments, choose which departments this user belongs to.

  10. Complete the required fields in the Resource Custom Fields section.

  11. In the Security Groups section, choose this user's appropriate user groups in the Available Groups box, and then click Add to move them to the Groups that contain this user box.

  12. If this user must have additional permissions that are not granted through the selected security groups, use the Security Categories and Global Permissions sections to grant the unique permissions.

  13. If your organization uses group fields for reporting or filtering, complete the fields in the Group Fields section.

  14. If this user represents a team for team resource assignments, select the Team Assignment Pool check box, and then choose which team this user is representing.

  15. Click Save to add the user to the server.

Create or edit a user group

Watch a video of the following procedure

  1. On the Quick Launch, click Server Settings.

  2. In the Security section, click Manage Groups.

  3. To create a new user group, click New Group. To edit an existing group, click the name of the group in the list.

  4. In the Group Name box, type the group name, and provide a brief description in the Description box.

  5. If you want to synchronize this group with an existing Active Directory group, click Find Group.

  6. Select the users whom you want to be a part of this group in the Available Users box, and then click Add to move them to the Selected Users box.

  7. Select the categories that you want to make available to members of this group from the Available Categories box, and then click Add to move them to the Selected Categories box.

  8. Select a category from the Selected Categories box, and then use the Allow and Deny check boxes to indicate the permissions for members of this group. Repeat this for each category in the Selected Categories box.

  9. If members of this group must have any specific global permissions, expand the corresponding section and use the Allow and Deny check boxes to indicate the appropriate permissions.

  10. Click Save to update the server.


Approve or reject a proposal (Project Server 2010)

Published: January 27, 2011

In some cases, approvers may receive an e-mail message in Microsoft Outlook, notifying them of items that require their review and possible approval. In other cases, the approver must check for items requiring approval in Microsoft Project Web App.

  1. Choose where to begin to review an approval request.

    • If you have received an e-mail message notifying you of an item requiring your review for approval, click Edit this Task on the message in Outlook.

    • If you have not received an e-mail message, on the Quick Launch in Project Web App, in the Approvals section, click Workflow Tasks.

  2. Click the item in the list that you want to review for approval.

  3. Review the requested change, and then click Edit Item.

  4. If appropriate, add a comment about your approval or rejection of the request, and then click Approve or Reject.


Analyzing portfolios (Project Server 2010)

Published: January 27, 2011

Microsoft Project Web App enables you to clearly analyze proposals for inclusion in your organization's portfolio of projects. Articles in this section include the following:

  • Overview: Analyze and approve project proposals (Project Server 2010)

  • Create analyses and prioritize projects (Project Server 2010)

  • Analyze portfolio based on high-level cost constraints (Project Server 2010)

  • Analyze portfolio based on time-phased resource requirements (Project Server 2010)

  • Commit selection decisions and communicate to portfolio stakeholders (Project Server 2010)


Create analyses and prioritize projects (Project Server 2010)

Published: January 27, 2011

With several project proposals submitted, the next step is to determine which proposals will be approved as projects. The portfolio analysis features in Microsoft Project Web App can help you evaluate cost relative to strategic value for each proposal.

Note:

This article and the videos it contains describe a typical portfolio analysis scenario. Your organization may have customized this process to meet unique business needs.

Create the analysis

Watch a video of the following procedure

  1. On the Quick Launch, under Portfolio Strategy, click Portfolio Analyses.

  2. Click New.

  3. Type a Name and Description, and then choose a Department, if appropriate.

  4. Choose whether to Prioritize projects using business drivers or to Prioritize projects using custom fields.

  5. Click Selected Projects and identify which proposals to include in the analysis.

  6. In the Analysis Primary Cost Constraint section, choose the primary budget constraint for the analysis.

  7. If resource requirements have been specified for the proposals you are analyzing, choose the Analyze time-phased project resource requirements against organizational resource capacity check box.

  8. Under Alias project Force-in and Force-out options, identify the lookup tables to use if you want to tie force-in and force-out decisions to options selected from a list.

  9. Click Next.

Prioritize the proposals

Watch a video of the following procedure

If you chose to prioritize projects by using business drivers:

  1. For each proposal listed down the left side, rate its impact on each of the business drivers listed across the top. Do this by using the lists in the grid.

  2. Click Next to see the calculated priorities.

If you chose to prioritize projects by using custom fields:

  1. Click Modify, and then choose the fields you want to use in the analysis.

  2. Set the weights and minimum/maximum values for each of the custom fields.

  3. Click Next to see the calculated priorities.

Once you have completed these procedures, the next step is to analyze your portfolio based on high-level cost constraints.


Analyze portfolio based on high-level cost constraints (Project Server 2010)

Published: January 27, 2011

After you have created an analysis and reviewed the relative priority values of the proposals, the next step is to analyze the proposals based on high-level cost constraints. You can set cost limits that help narrow the list of proposals that can reasonably be approved as projects.

Note:

This article and the videos it contains describe a typical portfolio analysis scenario. Your organization may have customized this process to meet unique business needs.

  1. On the Quick Launch, in the Cost Constraint Limits section, adjust the value of the primary cost constraint, and then click Recalculate.

  2. To include additional constraints by using custom fields, under Cost Constraint Limits, click Add/Remove. Add the field, click OK, and then set the value for the field. Click Recalculate to see its effect on the scenario.

  3. Click the Force in/out column for each row in the Projects table to choose to manually include or exclude a project in the scenario.

  4. Type adjusted costs in the Projects table to evaluate what-if cost scenarios. Notify the proposal owner of the adjusted budget for the proposal, if this scenario is committed.

  5. To override project dependencies for the scenario, on the Options tab, clear the Enforce Project Dependencies check box.

  6. On the Analysis tab, click Save As and name the scenario.

  7. Click Compare to review the saved scenarios.

Once you have completed these procedures, the next step is to analyze the portfolio based on time-phased resource requirements, if the proposals in your portfolio have resource information defined. If the proposals in your portfolio do not have resource information defined, the next step is to commit your selection decisions and communicate them to portfolio stakeholders.


Analyze portfolio based on time-phased resource requirements (Project Server 2010)

Published: January 27, 2011

Once you have created analyses and prioritized projects, and analyzed your portfolio based on high-level cost constraints, the next step is to review your portfolio's resource requirements. After examining the project schedule and timephased resource requirements of a portfolio, a common conclusion is that many of the proposals cannot go forward without significant schedule and resource adjustments. The resource constraint analysis feature in Microsoft Project Web App identifies resources for projects by using role-based availability and project requirements.

Note:

This article and the videos it contains describe a typical portfolio analysis scenario. Your organization may have customized this process to meet unique business needs.

  1. On the Analysis Properties page for an analysis, in the Time-phased Resource Planning section, select the Analyze time-phased project resource requirements against organizational resource capacity check box.

  2. In the Planning Horizon and Granularity section, choose the timeframe for the proposals in the analysis by setting the Planning Horizon Start and Planning Horizon End dates.

  3. Choose whether you want to view monthly or quarterly data in the Planning Granularity list.

  4. In the Resource Options section, select the Role Custom Field that your organization uses, and then select any additional filters to apply.

  5. In the Project start and finish dates section, choose from the following two options.

    • Use Resource Plan Utilization Settings The project start dates and finish dates come from the resource requirement data in the proposals.

    • Custom fields The dates are taken from the fields that you specify as the Start date and End date.

  6. Click Next to continue with the analysis. When you have completed cost constraint analysis, the next step is the resource constraint analysis.

  7. Review the red resource gaps, and reconcile them by doing the following:

    • Forcing proposals in or out

    • Adjusting the schedule

    • Hiring resources and incurring costs

    • Reducing resource cost rates and hiring resources without incurring costs

    • Changing your organization's resource capacity and the resource requirements of the proposals

Once you have completed these procedures, the next step is to commit your selection decisions and communicate them to portfolio stakeholders.


Commit selection decisions and communicate to portfolio stakeholders (Project Server 2010)

Published: January 27, 2011

Once you have completed your portfolio analysis by creating analyses and prioritizing projects, analyzing your portfolio based on high-level cost constraints, and analyzing your portfolio based on time-phased resource requirements, the last step is to commit your decision and communicate it to the stakeholders.

Note:

This article describes a typical portfolio analysis scenario. Your organization may have customized this process to meet unique business needs.

  1. Make sure that your portfolio reflects exactly what you want to commit to.

    Verify that you have selected all the proposals you want to include, and that you have not selected the proposals that you want to exclude.

  2. Click Commit.

  3. Review the message that appears, and then click OK to commit the portfolio.

  4. Communicate selection decisions with project owners and other portfolio stakeholders.

    Use the data in the MSP_PROJECT_ANALYSES_RESULTS table in the reporting database to provide detailed decision support information. You can access this data through views in the Project Center, or by editing or viewing individual projects.


Creating and working with projects (Project Server 2010)

Published: January 27, 2011

You can manage projects in Microsoft Project Web App, similar to how projects are managed in Microsoft Project Professional 2010. Articles in this section include the following:

  • Overview: Manage projects (Project Server 2010)

  • Creating or proposing a project (Project Server 2010)

  • Working with tasks (Project Server 2010)

  • Working with resources (Project Server 2010)

  • Archive a completed project (Project Server 2010)


Creating or proposing a project (Project Server 2010)

Published: January 27, 2011

Creating or proposing a project in Microsoft Project Web App is different based on how your organization operates. Articles in this section cover the following:

  • Overview: Set up and submit project proposals (Project Server 2010)

  • Create or edit a project or proposal (Project Server 2010)

  • Create a project from a SharePoint tasks list (Project Server 2010)


Create or edit a project or proposal (Project Server 2010)

Published: January 27, 2011

In Microsoft Project Web App, you can create a new project or proposal, or edit an existing one, in the Project Center. The process for creating a new project or proposal is slightly different from the process for editing an existing one.

Create a new project or proposal

Watch a video of the following procedure

  1. On the Quick Launch, under Projects, click Project Center.

  2. On the ribbon, click the down arrow below New, and then choose how you want to create the new project or proposal. You can choose to use an existing SharePoint list, or you can use one of the enterprise project types.

  3. On the project detail page that appears, type the appropriate information in the Name, Description, Start Date, and Owner boxes, and then click Save.

  4. Complete as much information as you can on the project detail pages that follow. After completing a page, click Save, and then click Previous or Next on the ribbon to navigate between project detail pages.

  5. To change the enterprise project type, click Change EPT, and then choose a different type on the box that appears.

  6. If the project or proposal is associated with a workflow with multiple stages, you can click Submit to kick off the workflow after you have added as much information as you can on the project detail pages.

Edit a project or proposal

Watch a video of the following procedure

  1. On the Quick Launch, under Projects, click Project Center.

  2. Click the name of the project or proposal you want to edit in the list.

  3. On the ribbon, click Edit to check out the project and make changes.

  4. Update the information on each of the project detail pages. After updating a page, click Save, and then click Previous or Next on the ribbon to navigate between project detail pages.

  5. To change the enterprise project type, click Change EPT, and then choose a different type on the box that appears.

  6. Once you have made and saved your updates, click Close to check the project back in, or click Submit to move the project or proposal to the next stage or phase in the workflow.


Create a project from a SharePoint tasks list (Project Server 2010)

Published: January 27, 2011

Microsoft Project Web App is closely integrated with SharePoint Server. In this version of Project Web App, you can create a new project by importing an existing SharePoint Server tasks list or project tasks list.

Tip:

For more information about how to use Microsoft Project Server 2010 with Microsoft SharePoint Server 2010, see these webcasts:

  • Webcast: Project Server 2010 and SharePoint Server 2010: Focus on Project Management (Level 200)

  • Webcast: Project Server 2010 and SharePoint Server 2010: Focus on Collaboration (Level 200)

Import an existing SharePoint tasks list

  1. On the Quick Launch, in the Projects section, click Project Center.

  2. On the Projects tab of the ribbon, in the Project group, click the arrow under New, and then choose From SharePoint List.

  3. Enter the URL of an existing SharePoint list in the box, and then click Open List.

  4. Map the fields used in the list to the fields used by Project Server 2010, and then click Import.

Update SharePoint list data in your project

To update the project data with information from the SharePoint list, select the row that you are updating, and then, on the Projects tab of the ribbon, in the Project group, click Update List.


Working with tasks (Project Server 2010)

Published: January 27, 2011

Microsoft Project Web App enables you to create tasks at different levels within a project. Articles in this section cover the following:

  • Create a new task (Project Server 2010)

  • Create top-down summary tasks (Project Server 2010)


Create a new task (Project Server 2010)

Published: January 27, 2011

If you have the appropriate permissions, you can easily create a new task in Microsoft Project Web App by using the Project Center.

  1. On the Quick Launch, in the Projects section, click Project Center.

  2. Click the name of an existing project in the list.

  3. On the Project tab of the ribbon, click Edit.

  4. Enter a new task by using one of the following methods:

    • Enter the task information in the blank row at the bottom of the list.

    • Copy and paste tasks from another program, such as Microsoft Excel.

    • Insert a new task between two existing tasks by clicking the row that you want to appear under the new task, and then pressing Insert on your keyboard.

  5. When you have finished adding tasks, click Close to check the project back in.


Create top-down summary tasks (Project Server 2010)

Published: January 27, 2011

While you plan a project, you may only have some high-level information about major milestones. In this version of Microsoft Project Web App, you can still plan your project, even without work estimates or details about what tasks might be involved. Instead of entering the task-level details about your project, you can take a top-down approach by creating high-level summary phases based on the overall timeline of your project.

  1. Create tasks that represent what you know about the project.

  2. Indent subtasks under summary tasks to represent different stages or phases within the project.

  3. Enter the desired dates or durations at the summary task level to manually schedule the summary task so that the dates and durations of the subtasks do not roll up to the summary task.


Working with resources (Project Server 2010)

Published: January 27, 2011

In Microsoft Project Web App, resources (which are different from users) are available to assign to projects and tasks. This section covers the following:

  • Associate a resource with a department (Project Server 2010)


Associate a resource with a department (Project Server 2010)

Published: January 27, 2011

Microsoft Project Server 2010 includes a new way to help narrow the amount of data that resources can see, based on their departments. Setting a resource's department helps control which custom fields are available to the resource, and which fields are required.

  1. On the Quick Launch, in the Resources section, click Resource Center.

  2. Select the check box to the left of the name of the resource that you are associating with a department.

  3. On the Resources tab of the ribbon, click Edit Resource.

  4. In the Departments section, click the button to the right of the field.

  5. Click the department that you are associating with the resource.


Set project-level permissions in Project Web App
See Also

Published: February 28, 2012

Summary: In Microsoft Project Web App, project managers can set up permissions at the project level.

There may be times when a project manager would like to grant additional permissions to a specific project for a certain user or group of users. The Project Permissions feature allows a project manager to give another project manager limited access to a project without adding that project manager to the project's team. Project managers can also use this feature to give an executive rapid access to a project that she or he needs to view.

How project permissions differ from groups and categories

The Project Permissions feature helps project managers get the right information to the right people quickly. It is not designed to be used as the primary source of security for all projects in your organization. Instead, we highly recommend that the Project Server administrator use groups and categories to grant permissions to most users. Using project permissions on a large scale can adversely affect the performance of Project Server. Additionally, using project permissions can make administration more difficult. Project Server administrators cannot tell which users have project permissions by checking groups or categories. They must examine each individual project.

Tip:

For more information about groups and categories, see Plan groups, categories, and RBS in Project Server 2010.

Set specific permissions for a project

To be able to set project-level permissions, the project manager must have the Manage Basic Project Security category-level permission. If you are a project manager and you cannot set project-level permissions, contact your Project Server administrator.

To set project-level permissions

  1. On the Quick Launch, in the Projects section, click Project Center.

  2. In the Project Center, click the row header for the project for which you are setting permissions. This selects the row.

  3. On the Projects tab, in the Navigate group, click Project Permissions.

    Tip:

    You can also access the Project Permissions page while you are viewing or editing a specific project. With the project open, on the Project tab, in the Navigate group, click Project Permissions.

    On the Project Permissions page, each row represents a set of permissions that have been granted to a set of users and groups, specific to this project. Permissions granted for a specific project supersede the security permissions set up by the Project Server administrator.

  4. Choose whether you are creating a new permission or editing an existing one:

    • If you are creating a new permission, on the Permissions tab, click New to give a new set of users specific permissions for this project.

    • If you are editing an existing permission, select the check box to the left of the permission that you are changing, and then, on the Permissions tab, click Edit.

    Tip:

    If you no longer need a permission listed on the Project Permissions page, select the check box to the left of the permission that you want to remove, and then, on the Permissions tab, click Remove.

  5. In the Available Users and Groups box, select the specific people and groups that you want to have unique permissions for this project, and then click Add to move them to the Users and Groups with Permissions box.

    If you want all users and groups to have these permissions, click Add All.

    Note:

    When you grant permissions to a user by using the Project Permissions feature, the user is automatically granted permissions to all project views. For this reason, we recommend that you not use this feature to grant project permissions to team members.

    You can also remove permissions for specific users and groups by selecting them in the Users and Groups with Permissions box, and then clicking Remove.

  6. In the Permissions section, select the check box for each permission that you want to grant to the users and groups that you identified in the previous step.

  7. Click Save to save these project-level permissions.

  8. Repeat steps 4 through 7 for each set of users and groups for which you want to have unique permissions for this project.

  9. When you are finished adding or changing the project-level permissions, on the Permissions tab, click Close.

See Also

Concepts

Plan groups, categories, and RBS in Project Server 2010
Manage security groups in Project Server 2010
Manage categories in Project Server 2010


Archive a completed project (Project Server 2010)

Published: January 27, 2011

Once you have completed a project, it is likely that you will no longer need immediate access to it, and you may want to hide it from being displayed in the Project Center and in team members' My Task views. Archiving and hiding completed projects reduces the "clutter" in these views, and it helps keep users from making changes to projects that are no longer active.

There is one "standard" method for archiving projects effectively by using Microsoft Project Server 2010. If that method does not meet your needs, there are some alternative methods that may be better suited for your organization. This article describes these methods and best practices for long-term archival.

In this article:

  • Archive a project by using the standard method

    • Step 1: Unpublish all project tasks

    • Step 2: Turn off updates in the project summary task

    • Step 3: Set up a security group for users who are not administrators

    • Step 4: Set up an Archive security category

    • Step 5: Archive the project team site

  • Archive a project by using an alternative method

  • Best practices for long-term archival

Archive a project by using the standard method

The standard method for archiving a project is a multi-step process:

  • Step 1: Unpublish all project tasks

  • Step 2: Turn off updates in the project summary task

  • Step 3: Set up a security group for users who are not administrators

  • Step 4: Set up an Archive security category

  • Step 5: Archive the project team site

These steps are performed by the project manager and the administrator, as noted in the following sections.

Step 1: Unpublish all project tasks

If the project has previously been published to team members and you now want to remove the project and its tasks from their views, the project manager must unpublish all tasks in the project that you are archiving. The project manager can start this process in Microsoft Project Web App, but the actual unpublishing process is performed in Microsoft Project Professional 2010.

Note:

Unpublishing a task does not remove any accepted and applied work from the project. However, any update approval history associated with a task is deleted.

To unpublish all project tasks

  1. On the Quick Launch, under Projects, click Project Center.

  2. Click the name of the project that you are archiving in the Project Name column.

  3. On the Task tab, in the Project group, click the arrow on the Edit button, and then click In Project Professional.

  4. In Project Professional 2010, scroll to the far right column in the table part of the Gantt Chart view, click the Add New Column header, and then click Publish.

    If the Gantt Chart view already has the Publish column displayed, skip this step.

  5. In the Publish column for each task in the project, click No.

    Tip:

    To speed this process for larger projects, set the first task to No. Then, click the handle on the lower right corner of the cell and drag it to copy cell contents in the Publish column.

  6. On the File tab, click Publish.

  7. Once the project is published, close and check in the project.

Step 2: Turn off updates in the project summary task

Next, the project manager may have to turn off updates in the project summary task so that no timesheet reporting is possible.

To turn off updates in the project summary task

  1. On the Quick Launch, under Projects, click Project Center.

  2. Click the name of the project that you are archiving in the Project Name column.

  3. On the Options tab, in the Show/Hide group, select the Project Summary Task check box.

  4. On the Options tab, in the Tasks group, click Close to Updates.

  5. In the Select Tasks section, select the check box for the project summary task (ID is 0), and then click Publish.

Step 3: Set up a security group for users who are not administrators

Once the project manager has prepared the project for archiving, the administrator creates a security group that contains all users except for administrators.

To create a security group for users who are not administrators

  1. On the Quick Launch, under Settings, click Server Settings.

  2. On the Server Settings page, under Security, click Manage Groups.

  3. Click New Group.

  4. In the Group Information section, type All Non-Admin Users in the Group Name box.

  5. In the Users section, in the Available Users box, select the names of all users who are not administrators, and then click Add to move them to the Selected Users box.

  6. Click Save.

Step 4: Set up an Archive security category

Once the administrator has created the All Non-Admin Users group, the next step is to create an Archive security category. During this process, the administrator chooses which projects to archive by including them in this category.

To create an Archive security category

  1. On the Quick Launch, under Settings, click Server Settings.

  2. On the Server Settings page, under Security, click Manage Categories.

  3. On the Manage Categories page, click New Category.

  4. In the Name and Description section, type Archive in the Category Name box.

  5. In the Users and Groups section, under Available Users and Groups, click All Non-Admin Users, and then click Add to move the group to the Users and Groups with Permissions box.

  6. Under Permissions for All Non-Admin Users (Group), select the Deny check box for all permissions.

    Tip:

    Select the Deny check box for each top-level permission node (Project and Resource) to deny all permissions indented under each node.

  7. In the Projects section, select Only the projects indicated, and then click the name of the project that you are archiving in the Available Projects box.

    Note:

    Be sure not to select any of the check boxes listed under Apply the above Project security permissions to all projects where. Doing so may create permissions issues on other projects and resources.

  8. Click Add to move the project to the Selected Projects box.

  9. Click Save.

Step 5: Archive the project team site

Many projects use the associated project team site to gather information that complements the project schedule. You may want to ensure that this information is also archived. Microsoft SharePoint Server 2010 enables site-level backup. For more information about how the administrator completes this step, see Export a site, list, or document library (SharePoint Server 2010).

Once the site is backed up, the administrator can then delete the site.

To delete a project team site

  1. On the Quick Launch, under Settings, click Server Settings.

  2. On the Server Settings page, under Operational Policies, click Project Sites.

  3. Click the row that contains the project team site that you backed up, and then click Delete Site.

  4. Click OK to confirm the deletion.

Archive a project by using an alternative method

The standard method of archiving is thorough and enables recovery, if you need it. However, extensive archiving is not always what an organization needs. Sometimes merely hiding completed projects from view, or saving a project locally, is enough to meet your archiving requirements.

If the standard method of archiving does not seem to meet your needs, here are some alternatives:

  • Hide the project in the Project Center If you merely want to hide completed projects in the Project Center, you can add an Archive flag to the Project Details page, and then filter a Project Center view to display only those projects where the Archive flag is set to No.

  • Remove the project from the Draft database Another option is to ensure that the project is backed up to the Archive database, and then delete the project from the Draft, Published, and Reporting databases. If you need data from the archived project later, use the Administrative Restore option on the Server Settings page to bring it back into the Draft database, and then republish the project.

  • Save the Project as an .MPP file If you want to remove the project completely from Project Server, another option is to open the project from Project Server by using Project Professional 2010, and then save the project as an MPP file. For more information, see the section titled, "Save your project locally," in Save a project. We recommend that you save the project with all custom field data so that the MPP file is isolated from any additional changes that are made to custom fields in Project Server. Once you have saved and backed up the project as an MPP file, it may be deleted from Project Server. If you need to recover the project at a later date, you can open the MPP file in Project Professional 2010 while connected to Project Server, and then save the project to the server. For more information, see the section titled, "Save a local project to Project Server," in Save a project.

    Note:

    Using this method will break any deliverable, issue, and risk links between the project and its project team site in Project Server.

Best practices for long-term archival

From time to time, the project MPP file format, the Project Server content database schemas, and the SharePoint site schemas can change to reflect new features. This can affect backward compatibility to the extent that a project saved as an MPP file, an old backup of a Project Server content database, or a project team site backup may not be immediately usable.

A best practice is to always plan on including your archived content in your upgrade planning. This reduces the time to recover an old project that might require several upgrade steps otherwise.


Submitting and approving time and status (Project Server 2010)

Published: January 27, 2011

As team members work on a project, they can provide their time and task status using Microsoft Project Web App. Project managers and resource managers can then review team members' time and task status and choose to approve or reject it. Articles in this section cover the following:

  • Overview: Track your time and task progress (Project Server 2010)

  • Overview: Enter time and task progress in one view (Project Server 2010)

  • Videos: Time and task progress workflow overview (Project Server 2010)

  • Submitting time and task status (Project Server 2010)

  • Approving time and task status (Project Server 2010)


Videos: Time and task progress workflow overview (Project Server 2010)

Published: February 24, 2011

Microsoft Project Web App enables you to easily track the time you spend on a project's tasks, and the progress of those tasks toward completion. In the version of Project Web App that is included with Microsoft Project Server 2010, you can enter time and task progress by using the same view, or by using separate views. You can also assign someone else to enter and submit your time and task progress information on your behalf. This person is called a "delegate."

The following videos illustrate the workflow for entering, submitting, and approving time and task progress by using a single view (single entry mode), separate views, through a delegate, after a time reporting period has closed, or after a task has been locked from updating.

Click a link to open a .wmv file in the default video viewer for full-resolution viewing. For an optimal viewing experience, you can download a video. To download a video, right-click the link, and then click Save Target As.

Play video Watch the "Tracking time and reporting task progress: Standard method (single entry mode)" video.

Running time: 3:52

Play video Watch the "Tracking time and reporting task progress: Standard method (separate views)" video.

Running time: 4:33

Play video Watch the "Tracking time and reporting task progress: Timesheet delegation" video.

Running time: 5:07

Play video Watch the "Tracking time and reporting task progress: Closed-period updating" video.

Running time: 2:40

Play video Watch the "Tracking time and reporting task progress: Closed-task updating" video.

Running time: 2:53

If you find these videos helpful, you may also find the Time and task progress workflow diagrams (Project Server 2010) useful. These diagrams are available as .vsd, .pdf, and .xps files, and they illustrate the workflows that are discussed in the videos.


Submitting time and task status (Project Server 2010)

Published: January 27, 2011

As you work on tasks in a project, you may be asked to report the time that you have spent on each task, plus the status of work on each task. Microsoft Project Web App enables simple time and task status reporting. Articles in this section cover the following:

  • Report work on my timesheet (Project Server 2010)

  • Report the status of your tasks (Project Server 2010)

  • Add or remove a timesheet task (line) (Project Server 2010)

  • Add a task to your task status (Project Server 2010)

  • Create a new delegation (Project Server 2010 settings)

  • Act as a delegate (Project Server 2010)


Report work on my timesheet (Project Server 2010)

Published: January 27, 2011

You can track the time that you have spent working on tasks, projects, and non-project activities by using timesheets in Microsoft Project Web App.

Note:

Before you can create a timesheet, the site administrator needs to set up time reporting periods for your organization. If you follow the steps in this article and do not see any links to create a new timesheet, perhaps your site administrator has not set up reporting periods yet.

To create a new timesheet

  1. On the Quick Launch, under My Work, click Timesheet.

  2. To create a timesheet for a reporting period other than the current one, on the Timesheet tab of the ribbon, click Select Period.

  3. Choose a date within the reporting period for that timesheet, and then click OK.

The timesheet automatically contains all the project tasks, with work planned for the period, plus any standard non-project activities.

To have more control over what data is pre-populated in a new timesheet

  1. On the Quick Launch, in the Settings section, click Manage Timesheets.

  2. Place the mouse pointer over the Click to Create link in the Timesheet Name column for the timesheet in the period that you want to create, and then click the arrow that appears.

  3. Choose a method for pre-populating your timesheet: Create with Default Setting, Create with Tasks, Create with Projects, or Do not Autopopulate.

From here, you can decide to add lines to your timesheet, enter actual work, or, if you have completed your timesheet, save it or submit it for approval.

Note:

If your organization uses single entry mode to capture timesheet data and task status information by using a single view, your timesheet also shows overdue tasks.


Report the status of your tasks (Project Server 2010)

Published: January 27, 2011

As you work on your tasks, you may find it helpful to report status together with the time you have spent on the task. For example, you might want to let the project manager know what percentage of the task is complete or give your best guess about how much work is left.

In this version of Microsoft Project Web App, you can report task status separately from your timesheet hours (actual work), or, if your site administrator has enabled the appropriate setting, you can use a single view to report your task status together with your actual work.

  1. Do one of the following:

    • To enter your task status separately from your timesheet, on the Quick Launch, in the My Work section, click Tasks.

    • If your organization captures time and task status by using the same view, on the Quick Launch, under My Work, click Timesheet.

    Note:

    The site administrator sets up whether your organization captures time and task status using a single view or separate views.

  2. Enter the progress that you have made on your tasks.

  3. To include a comment when you submit your task status, on the Tasks tab of the ribbon, in the Show/Hide group, select the Comment on Submit check box.

  4. Choose how to submit your task status updates:

    • Submit all tasks On the Tasks tab, in the Submit group, click the arrow under Send Status, and then click All Tasks to submit all task status updates for approval.

    • Submit selected tasks If your organization enables you to submit only selected task status updates for approval, click the check box to the left of each task status update that you want to submit, and then, on the Tasks tab, in the Submit group, click the arrow under Send Status, and then click Selected Tasks.

  5. If you chose to include a comment, type the comment in the box that appears, and then click OK to submit your updates.


Add or remove a timesheet task (line) (Project Server 2010)

Published: January 27, 2011

Each line on your timesheet captures your actual work for the selected reporting period. You can add lines for different categories of time that you want to capture, or you can remove a line if you no longer have any time to report on the task.

Add a task to your timesheet

  1. On the Quick Launch, under My Work, click Timesheet.

  2. On the Tasks tab of the ribbon, in the Tasks group, click the arrow under Insert Row.

  3. Choose how you want to add a task:

    • Insert Task Assign yourself to an existing task, and then add that task to your timesheet.

    • Create a New Task Create a new task within an existing project, and then add that task to your timesheet.

    • Add Yourself to a Task Add one of your assigned tasks to your current timesheet.

    • Insert Team Tasks Assign yourself to one of your team tasks, and add that task to your timesheet.

    • Insert Administrative Task Add sick leave, vacation, training, travel, or any other non-project time to your timesheet.

    • Insert Personal Task Add a task that lets you capture any other time on your timesheet.

Remove a task from your timesheet

  1. On the Quick Launch, under My Work, click Timesheet.

  2. Click the check box to the left of the task that you want to remove, and then, on the Tasks tab, in the Tasks group, click Remove Task.


Add a task to your task status (Project Server 2010)

Published: January 27, 2011

While reporting task status in Microsoft Project Web App, you may find that you want to report on a task that is not showing up in the list.

  1. On the Quick Launch, in the My Work section, click Tasks.

  2. On the Tasks tab of the ribbon, in the Tasks group, click the arrow under Insert Row.

  3. Choose how you want to add a task:

    • Create a New Task Create a new task within an existing project, and then add that task to your task status.

    • Add Yourself to a Task Assign yourself to an existing task, and then add that task to your task status.

    • Insert Team Tasks Assign yourself to one of your team tasks, and add that task to your task status.

Once you have added a task to your task status, you can enter your progress on that task.


Act as a delegate (Project Server 2010)

Published: January 27, 2011

When the start date for a delegation arrives, the user who will be substituting for the absent user must choose to become a delegate in order to start to work in Microsoft Project Web App as the absent user.

  1. On the Quick Launch, click Personal Settings.

  2. Click Act as a Delegate.

  3. In the table, click the delegation that you want to act on, and then click Start Delegate Session on the Delegations tab of the ribbon.

  4. When you have completed the work that you needed to do as a delegate for the absent user, click the link in the yellow status bar to return to the Act as a Delegate page.

  5. Click Stop Delegate Session on the Delegations tab of the ribbon to return to your own account.


Approving time and task status (Project Server 2010)

Published: January 27, 2011

After team members have submitted their time and task progress in Microsoft Project Web App, the next step is for the appropriate manager(s) to review and then approve or reject the submitted information. Articles in this section cover the following:

  • Act as a delegate (Project Server 2010)


Reporting on projects (Project Server 2010)

Published: January 27, 2011

The version of Microsoft Project Web App that is included with Microsoft Project Server 2010 introduces the Business Intelligence Center, where you can dynamically view reports about your organization's projects. Articles in this section include the following:

  • About the BI Center (Project Server 2010)

  • Create a reporting view (Project Server 2010)


About the BI Center (Project Server 2010)

Published: January 27, 2011

The following video helps Microsoft Project Web App site administrators become familiar with the business intelligence and reporting environment used in Microsoft Project Server 2010. Once you are more familiar with how reporting works, you will be better prepared to roll out the Business Intelligence (BI) Center in an effective way for your organization.

Watch this video


Create a reporting view (Project Server 2010)

Published: January 27, 2011

Microsoft Project Server 2010 provides a rich custom reporting environment to support your business intelligence needs. Several default reporting views and templates are included when Project Server 2010 is installed, and site administrators can use those templates as a basis for creating reporting views that meet the unique needs of your organization.

In this article:

  • What default reporting views are available?

  • Display a default reporting view

  • Create a custom reporting view by using a template

What default reporting views are available?

Project Server 2010 includes a set of default reporting views that you can use to analyze your project data. The following table describes the default views.

Report name | Description
Capacity Report | Provides the resource manager with a graphical view of assigned work and remaining capacity by month for a set of resources.
Issues and Risks | Provides a summary of issues and risks.
Exit Status of Resources by Program | Enables the project manager to easily determine which resources are due to exit a set of projects and to determine how much remaining work is assigned to those resources.
Milestones Due This Month | Provides a list of milestones that are due this month for a set of projects.
Timesheet Actuals | Enables the timesheet manager to see what was submitted through timesheets.
Timesheet Audit | Enables the timesheet manager to audit where entries are in the timesheet process.
Workflow Chart Data | Provides a snapshot of how many projects are in the pipeline by stage and phase.
Top Projects Data | Provides a list of the top projects in the portfolio that consume company resources, such as cost or employees.
Workflow Drilldown Data | Offers an in-depth analysis of projects by providing dates when projects enter each stage, project owners, and project health status.
Rejected Projects List | Contains a list of projects that were rejected or canceled during the workflow.
Simple Projects List | Lists all projects that are currently in the pipeline (proposed, continued, rejected, and canceled).
Incomplete Projects Data | Provides a list of all projects that are stuck in the proposal stage because of incomplete information.

Display a default reporting view

You can use the Business Intelligence (BI) Center in Microsoft Project Web App to view the default reporting views.

  1. On the Quick Launch, click Business Intelligence.

  2. On the BI Center Quick Launch, click Sample Reports.

  3. Click the appropriate language folder to view the list of default reporting views.

  4. Click a view name to display that view in Microsoft Excel or Microsoft Visio.

Create a custom reporting view by using a template

Project Server 2010 comes with several view templates that site administrators can use to build reporting views to meet your organization's needs. The templates provide the connection between Excel and the Project Server reporting database by using Office Data Connections and Excel Services in SharePoint.

  1. On the Quick Launch, click Business Intelligence.

  2. On the BI Center Quick Launch, click Templates.

  3. Click the appropriate language folder to view the list of default templates.

  4. Click a template name to create a custom reporting view by using that template.

  5. Create PivotCharts and PivotTables to display the data in a way that meets your organization's needs.


Best practices for submitting and reporting on actual work (Project Server 2010)

Published: December 6, 2011

Organizations choose to track work that is performed by resources in many ways. Microsoft Project Server 2010 supports flexibility for the varying tracking needs of organizations. Some organizations require the work submitted by resources to be recorded on a day-to-day basis, especially if the actual work is used for billing, payroll, or other financial purposes. Project Server 2010 can be used to capture actual work submitted by users. Some organizations choose to transfer actual work to other enterprise resource planning (ERP) and reporting systems. For example, an organization might choose to use Project Server 2010 to capture actual work, but then transfer the actual work to an accounting tool to drive invoicing to internal and external customers.

Because Project Server helps you manage projects, actual work can be captured in multiple ways, and it is displayed in the way that makes it most useful for the user who is accessing it. For example, in the timesheet the focus is on user-entered data on a per-day (or per-period) basis, whereas in the Microsoft Project client the focus is on the aggregate, or scalar, value for work completed and remaining on a task to help with planning.

This article outlines the set of best practices for submitting and reporting on actual work in Project Server 2010.

1. Use single entry mode

The best practice to help make sure that actual work is populated correctly throughout Project Server 2010 is to use single entry mode and have resources only enter actual work through the Timesheet view.

To turn on single entry mode:

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Timesheet Settings and Defaults.

  3. In the Single Entry Mode section, select the Single Entry Mode check box.

If your organization is using single entry mode, it may be in your best interests to hide the Tasks view completely so that resources can only enter actual work by using the Timesheet view. When both views are available, users can enter actual work in either view, and the data is persisted in both views. If your organization pulls data from timesheets to drive billing or payroll, for example, the best practice is to only allow users to enter actual work in the Timesheet view. This reduces the possibility for actual work to be incorrectly overwritten if a user can also enter actual work in the Tasks view.

An exception to this best practice is if there are material resources. Assignment owners for material resources must enter time for those material resources by using the Tasks view. If your organization has assignment owners that record time for material resources, the Tasks view should remain visible, and users should be instructed to only enter actual work for their assignments in the Timesheet view.

To hide the Tasks view:

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Look and Feel section, click Quick Launch.

  3. Under Set Menu Item Details, click the Tasks view, in the Name column.

  4. Click No in the Display link in Quick Launch list, and then click OK.

There are a few important notes to consider when single entry mode is enabled in your organization. Let's say a user's timesheet contains a line for a particular assignment, and that assignment is deleted. The next time that the user opens that timesheet, the line associated with the deleted assignment may be removed, depending on the following conditions:

  • If the line contains no user entries, it is removed.

  • If user updates are not protected, and the line contains approved actual work, it is removed.

  • If user updates are protected, and the line contains approved actual work, the line remains in the timesheet. However, if the approved timesheet is recalled, then the line is removed.

  • If the line contains actual work that has been entered into the timesheet but that is still pending approval, the line is removed, even when user updates are protected.

Project managers should use caution when deleting or changing assignments, to be sure that all submitted actual work is reviewed before the change or deletion. This helps to ensure that valid user-entered data is not lost. Assignments can be explicitly or implicitly changed in any of the scenarios listed below:

  • The project manager explicitly deletes an assignment for which there are pending actual work updates.

  • The project plan containing the assignment is restored from its archive.

  • The project plan containing the assignment is deleted.

  • The project plan containing the assignment is overwritten, using the Save As functionality in Microsoft Project 2010.

2. Protect user updates

Some organizations might choose to prevent a project manager from updating a team member's actual work inside the project.

Note:

Project managers are unable to update a resource's actual work recorded on a timesheet.

If your organization wants to maintain resource-entered values for actual work in the timesheets and make sure that value is reflected in the project plan, then the best practice is to turn on the feature in Project Server 2010 that protects user updates.

To protect user updates:

  1. On the Quick Launch, in the Settings section, click Server Settings.

  2. On the Server Settings page, in the Time and Task Management section, click Task Settings and Display.

  3. In the Protect User Updates section, select the Only allow task updates via Tasks and Timesheets check box.

When you protect user updates, timesheets always maintain exactly what the user entered for timephased work, and the scalar values between timesheets and the project plan are always consistent. However, the timephased distribution of the scalar value may be slightly different in the project plan, as it is geared toward future work planning and not maintenance of actual work historical values. The scheduling engine may adjust some timephased actual work to keep the plan consistent.

3. Use submitted actual work from timesheets, instead of project plans, for timephased reporting

Actual work can be captured by using either the project client (project plan) or timesheets. However, many users only capture actual work directly from their resources by using timesheets, especially if they are also protecting actual updates as previously described. When you are using timesheets to track the submission of actuals on a daily or weekly basis, the best practice is to report directly against the actual work captured in timesheets when syncing with external ERP and reporting systems. The timesheet data is specifically rendered to ensure accuracy on a historical and per-period basis exactly as the user entered it, even when conditions in the project plan have changed.

While many calculations are made in a project plan, such as cost based on cost rates, these can be easily replicated with timesheet data. The project plan, on the other hand, renders the actual work data (and other schedule data) with an emphasis on future work planning (analytics and earned value calculations). Therefore, there may be circumstances where the user-entered value in the timesheet does not exactly match the same value in the project plan for a specific day. However the overall aggregate, or scalar, value for the assignment will be consistent between the project plan and the timesheet when protected actuals is enabled.

If you are reporting on submitted actual work from timesheets, it is important that resources be asked not to reassign or self-assign tasks. All assignments should go through the project manager or resource manager. This helps ensure proper handling of actual work data.

The BI Center in Microsoft Project Web App provides report templates that take advantage of the reporting database (T-SQL) and Analysis Services (OLAP). These templates may help you author reports against the timesheet's data store.

4. Use administrative time categories to track non-project work

Some organizations require the tracking of administrative activities, or non-project work. Examples of administrative activities include sick time, vacation, and work-related repetitive activities such as customer support, system maintenance, or meetings. We recommend that these activities be tracked by using administrative time categories. These categories require minimal maintenance, and time that is captured in these categories can be used to generate data analysis reports from the corresponding OLAP cube.

For more information about how to set up administrative time categories, see Administrative Time (Project Server 2010 settings).

If administrative time categories do not meet your organization's needs, and you decide to use projects to track administrative activities, the project owner should follow these guidelines for more efficient projects:

  • Limit the number of resources assigned to the project plan to less than 100 resources.

  • Limit the duration of the project plans to track administrative activities on a quarterly or half-yearly basis.

  • Keep tasks in the project plan automatically scheduled, with a fixed units task type.

  • Keep the project plan's schedule in line with time reporting periods.

5. Close tasks to updates, instead of using the Publish and Booking Type fields

Project managers may find the Publish and Booking Type fields helpful for controlling task and resource visibility. The Publish field can be used to control which tasks are visible in Project Web App, and the Booking Type field can be used to control which resources are visible during the resource planning process. However, be aware that these fields are part of the early planning process. They are not designed for limiting users' ability to continue to track time on a particular task. If the Publish and Booking Type fields are used incorrectly, they can result in the removal of task entries from a user's timesheet or task status. This is especially critical because the removal of task entries may mean the loss of submitted time.

For more information about the Publish and Booking Type fields, see the following Help articles:

  • Publish (task field)

  • Add a user account in Project Server 2010

  • Create a new resource (Project Server 2010 settings)

If you want to close a particular task so that no additional time can be submitted, you can use the Close Task to Update option in Project Server 2010.

For more information about how to close a task to updates, see Close tasks to update (Project Server 2010 settings).

Tip:

If you want to close a task to updates, perform this action at the beginning of the new timesheet period, after the previous period has been closed. This can help prevent the accidental removal of tasks that have recorded actual work. Tasks that require closure to updates are typically administrative, and the best practice is to use administrative time categories, instead of projects.

Summary

If your organization uses actual work captured in Project Server 2010 together with other ERP or reporting systems, it is in your best interests to follow the guidelines described in this article:

  • Use single entry mode

  • Protect user updates

  • Use submitted actual work from timesheets, instead of project plans, for timephased reporting

  • Use administrative time categories to track non-project work

  • Close tasks to updates, instead of using the Publish and Booking Type fields

By following these best practices, you are working to preserve the accuracy of the actual work data that is entered in timesheets by your organization's resources.

To maintain the actual work data for a project that has been completed or is no longer active, follow the guidance offered in Archive a completed project (Project Server 2010).

Acknowledgements

The Project Server Content Publishing team thanks the following contributors to this article:

  • Bobby Burns, Program Manager II, Project/Project Server

  • Aik Chen, Senior Support Escalation Engineer, Project/Project Server

  • Christophe Fiessinger, Senior Technical Product Manager, Project/Project Server

  • Heather O'Cull, Senior Program Manager Lead, Project/Project Server

  • Keshav Puttaswamy, Principal Group Program Manager, Project/Project Server

  • Matt Roe, Program Manager, Project/Project Server

  • Saurabh Sanghvi, Program Manager, Project/Project Server

  • Eli Sheldon, Program Manager, Project/Project Server

  • Brian Smith, Senior Support Escalation Engineer, Project/Project Server

  • Eric Zenz, Senior Program Manager Lead, Project/Project Server


Reporting with Microsoft Project Server 2010 (white paper)

Published: April 7, 2011

This white paper is an introduction to the reporting options available in Microsoft Project Server 2010 and Microsoft SharePoint Server 2010. The target audience for this document is the experienced user, business owner, or administrator who is new to Project Server 2010 and looking for a quick way to assess the reporting options available to the organization.

This white paper does not cover how to configure the Project Server 2010 reporting infrastructure. For information about how to configure reporting for Project Server 2010, see Configure reporting for Project Server 2010.

This white paper includes information about the following:

  • Project Center views

  • OLAP cubes

  • ODC files

  • Microsoft Excel and Excel Services in Microsoft SharePoint Server 2010

  • Microsoft Visio and Visio Services in Microsoft SharePoint Server 2010

  • Microsoft SQL Server Reporting Services (SSRS)

  • PerformancePoint Services in Microsoft SharePoint Server 2010

  • The REST API

  • External Content Types

Download as a Microsoft Word (.docx) file (http://go.microsoft.com/fwlink/p/?LinkId=215299)

Download as a PDF file (http://go.microsoft.com/fwlink/p/?LinkId=215300)

Download as an XPS file (http://go.microsoft.com/fwlink/p/?LinkId=215301)


Getting Help with Project Web App (Project Server 2010)

Published: January 27, 2011

As you work in Microsoft Project Web App, you may encounter issues that you are not sure how to handle. The following articles suggest resources that you may find helpful:

  • Troubleshooting for team members, project managers, and portfolio managers (Project Server 2010)

  • Troubleshooting for site administrators (Project Server 2010)


Troubleshooting for team members, project managers, and portfolio managers (Project Server 2010)

Published: January 27, 2011

Maybe you are not seeing what you expect to see, or Microsoft Project Web App is not doing what you think it should do. If so, you have several options for troubleshooting your issues.

What do you want to do?

  • Find information about TechNet and Office.com

  • Find information about the Project 2010 Solution Center

  • Talk with other team members, project managers, and portfolio managers

  • Talk with your site administrator

  • Post your issue on the Project Server discussion forums

Find information about TechNet and Office.com

The Office.com and TechNet Web sites are great resources for information about how to use Project Web App. You will find Help topics to you get started, plus details on how to really dig in and use some of the more complex areas of the product. These sites are your best bet to start your troubleshooting search.

Find information about the Project 2010 Solution Center

The Project 2010 Solution Center is the Support Web site where you will find knowledge base articles, links to downloadable content, and other troubleshooting information. If the issue goes beyond understanding how to use Project Web App (for example, if you are encountering an error message), search the Project 2010 Solution Center to see whether information for addressing your issue is published.

Talk with other team members, project managers, and portfolio managers

Sometimes, the best resource to help you resolve issues is your peers. They are working in the same tool and the same environment that you are, and they may have encountered the same issues. You may be able to benefit if they have figured out a way to resolve some of these issues before you encountered them. Ask around, make your issue known, and your peers may prove to be your top troubleshooting resource.

Talk with your site administrator

If you still do not have an answer, talk with your organization's site administrator. This person knows the finer points of Project Web App permissions, which is where some of your issues may be originating. Project Web App is highly customizable, and your user account may not have the permissions that are required to do what you are trying to do, or your organization may have policies that prevent you from doing or seeing what you expect. Your site administrator can help explain why your permissions are set a certain way, and if your permissions are incorrect, he or she can adjust them appropriately.

Post your issue on the Project Server discussion forums

Project Server has some very active discussion forums, where you can post the issue that you are encountering, and see whether any other users have encountered the same situation. If you cannot figure out the issue by reviewing the information on Office.com, TechNet, or the Project 2010 Solution Center, or by talking with your peers or site administrator, try posting your question to one of these forums:

  • Forum: Project Server General Questions and Answers

  • Forum: Project Server Setup, Upgrade, Administration and Operation


Troubleshooting for site administrators (Project Server 2010)

Published: January 27, 2011

If you are a site administrator, you may have users coming to you with troubleshooting questions, or you may encounter issues of your own that need to be resolved. You have several troubleshooting options.

What do you want to do?

  • Find information on TechNet and Office.com

  • Find information on the Project 2010 Solution Center

  • Post your issue on the Project Server discussion forums

Find information on TechNet and Office.com

The Office.com and TechNet Web sites are great resources for information about using Microsoft Project Web App. If users come to you asking about how to use a specific feature, redirecting them to either of these sites is a good first step. If they are unable to find the information that they need, you may have a better understanding of the features that they are trying to use, and therefore may be more successful in finding information appropriate to their issue on this site. Regardless, if the question at hand deals with how to use Project Web App, check the Help topics on TechNet or Office.com first.

The Project Server 2010 TechCenter on TechNet is a great place to look for information about issues that your server administrator might be able to address. If you are dealing with an issue that you think may go beyond the scope of what you control as site administrator, you can search through the content on the Project Server 2010 TechCenter to see whether the issue is something that your server administrator can address.

Find information on the Project 2010 Solution Center

The Project 2010 Solution Center is the Support Web site where you will find knowledge base articles, links to downloadable content, and other troubleshooting information. If the issue goes beyond understanding how to use Project Web App (for example, if you are encountering an error message), search the Project 2010 Solution Center to see whether information for addressing your issue is published.

Post your issue on the Project Server discussion forums

Project Server has some very active discussion forums, where you can post the issue you are experiencing, and see whether any other users have encountered the same situation. If you are unable to figure out the issue by reviewing the information on Office.com, the Project 2010 Solution Center, or the Project Server 2010 TechCenter on TechNet, try posting your question to one of these forums:

  • Forum: Project Server General Questions and Answers

  • Forum: Project Server Setup, Upgrade, Administration and Operation


Add or remove Project Web App Web Parts for a site in the Project Web App site collection (Project Server 2010)
See Also

Published: October 21, 2010

You can add or remove a Microsoft Project Web App Web Part from a Web site that resides in the same site collection as the Project Web App (PWA) instance. For sites that are in the same site collection as the Project Web App instance, the Project Web App Web Parts are readily available for you to add from the Web Part Gallery.

If you want to add a Project Web App Web Part to a site that is not in the Project Web App site collection, you must import the PWA Web Parts into the Web Part Gallery for the site. For more information about how to add a PWA Web Part to a site not in the PWA site collection, see Add Project Web App Web Parts to a site not within the Project Web App site collection (Project Server 2010).

This article contains the following sections:

  • Requirements to add or remove a Project Web App Web Part from a Web Parts page

  • Add a Project Web App Web Part to a page

  • Remove a Project Web App Web Part from a page

For more information about Project Web App Web Parts in Microsoft Project Server 2010, see the following articles:

  • Plan for Project Server 2010 Web Parts

  • Add Project Web App Web Parts to a site not within the Project Web App site collection (Project Server 2010)

  • Upgrade considerations for Project Web App Web Parts

Requirements to add or remove a Project Web App Web Part from a Web Parts page

There are two requirements for a user to add a Web Part to a Web Parts page:

  • You must have at least SharePoint "Design" permissions to the page.

    Note:

    The SharePoint "Design" permission is not required to add a Web Part when you are personalizing pages that are viewable only by you.

  • You must have a supported browser. Project Web App requires Windows Internet Explorer 7 or 8.

    Note:

    Ensure that all Project Web App users are using supported browsers. Microsoft SharePoint Server 2010 supports additional browsers that are not supported by Project Web App. For more information, see Plan browser support (Project Server 2010).

Add a Project Web App Web Part to a page

When you are adding a Project Web App Web Part to a page in a Web site that resides in the same site collection as Project Web App, it can be added through the user interface in the following ways:

To add a Project Web App Web Part to a page

  1. On the Web page, click the Site Actions menu, and then click Edit Page.

    The page appears in Edit Mode. In Edit mode, the Web Parts page for the site lets you add Web Parts to different areas on the page (Header, Left, Middle, Right, and Footer).

  2. Click Add a Web Part in the location in which you want to add the Web Part.

  3. On the Browse server ribbon, in the Category list, select Project Web Access. Web Parts that are contained in the Project Web Access category appear in the Web Parts list.

  4. Select the Web Part that you want to add to the site and then click Add.

    When you select a Web Part, a brief description of it appears in the About Web Part section.

  5. The page appears with the added Web Part, but is still in Edit Mode. When you are finished adding Web Parts to the page, click the Page tab to display the Page server ribbon, and then click Stop Editing.

Or, you can add a Web Part to a Web Parts page by using the Insert server ribbon.

To add a Web Part to a page by using the Insert server ribbon

  1. On the Web page, click the Site Actions menu, and then click Edit Page.

    The page appears in Edit Mode.

  2. Click the Page tab, and then click Insert to display the Insert server ribbon. Click Web Part.

  3. In the Category list, select Project Web Access. Web Parts that are contained in the Project Web Access category appear in the Web Parts list.

  4. Select the Web Part that you want to add to the site.

    A brief description of that Web Part appears in the About Web Part section.

  5. In the About Web Part section, specify a location by using the Add Web Part to control. Choose a location from that drop-down list, and then click Add.

    The page then appears with the added Web Part, but it is still in Edit Mode.

  6. When you are finished adding Web Parts to the page, click the Page tab to display the Page server ribbon, and then click Stop Editing.

Remove a Project Web App Web Part from a page

The procedure for removing a PWA Web Part from a page is the same for a site in the PWA site collection or a site not in the PWA site collection.

To remove a Web Part from a page

  1. On the Web page, click the Site Actions menu, and then click Edit Page.

    The page appears in Edit Mode.

  2. Select the Web Part that you want to remove, click the Web Part menu (which is the downward pointing arrow next to the check box in the upper-right corner of the Web Part), and then click Delete.

  3. In the Message from Web Part dialog box, click OK to confirm that you want to delete the Web Part.

    The page appears with the Web Part removed, but it is still in Edit Mode.

  4. Click the Page tab to display the Page server ribbon, and then click Stop Editing.

See Also

Concepts

Upgrade considerations for Project Web App Web Parts
Plan for Project Server 2010 Web Parts
Add Project Web App Web Parts to a site not within the Project Web App site collection (Project Server 2010)

Other Resources

Manage Web Part pages (SharePoint Server 2010)
Developing Project Server 2010 Web Parts


Add Project Web App Web Parts to a site not within the Project Web App site collection (Project Server 2010)
See Also

Published: October 21, 2010

You can add Microsoft Project Web App Web Parts to a site that is not in a Project Web App (PWA) site collection. Sites that are not in the same site collection as the Project Server 2010 instance do not have the PWA Web Parts in the Web Part Gallery for the site collection. Sites that are in the farm but not in the same site collection as the PWA instance have two requirements for you to add PWA Web Parts to them:

  • The PWA Web Part must be imported into the Web Part Gallery for the site collection.

  • If the PWA Web Part has a ribbon dependency, the Project Web App server ribbon must be enabled on the site.

Note:

There are additional actions that you must take if the site on which your Project Web Access Web Parts reside was upgraded from Microsoft Office SharePoint Server 2007. For more information, see the Fix the upgraded Project Web App Web Parts on sites not in the same site collection as Project Web App section of Upgrade considerations for Project Web App Web Parts.

For more information about PWA Web Parts in Project Server 2010, see the following articles:

  • Plan for Project Server 2010 Web Parts

  • Add or remove Project Web App Web Parts for a site in the Project Web App site collection (Project Server 2010)

  • Upgrade considerations for Project Web App Web Parts

Import a Project Web App Web Part into a Web Part Gallery for a site collection

A site that is not in the Project Web App site collection does not have the Project Web App Web Parts available for use. They must be imported to the Web Part Gallery of the site collection to make them available to load to sites in the site collection. The PWA Web Parts must be imported from an existing site that is already in a Project Web App site collection on the farm. Use the following steps to import PWA Web Parts from a site in the PWA site collection to the Web Part Gallery of the site that is not in the PWA site collection.

To upload the Project Web App Web Part to the Web Part Gallery

  1. Open a site in the Project Web App site collection.

  2. Click Site Actions, and then click Site Settings. On the Site Setting page, in the Galleries section, click Web Parts.

  3. On the All Web Parts page, in the Web Parts section, select the check box next to all of the PWA Web Parts that you want to import to the other site.

  4. Click the Documents tab to display the Documents server ribbon. Click Download a Copy. In the File Download dialog box, click Save. In the Save As dialog box, select a convenient location to save the Web Part to and then click Save.

  5. Open the site to which you want to import the PWA Web Parts. On this site, click Site Actions, and then click Site Settings. On the Site Settings page, in the Galleries section, click Web Parts.

  6. Click the Documents tab to display the Documents server ribbon. Click Upload Document.

  7. Select the Web Parts you want to import from the location that you saved them to, and then upload them to the Web Part Gallery.

Enable the Project Web App Server ribbon on the site

Some PWA Web Parts require the Project Web App Server ribbon to be on the page in order to use them. If the Web Part has a ribbon dependency and the Web Part is added to a non-Project Web App site collection, the ribbon feature must be enabled on the target site collections.

The PWA Web Parts that have a ribbon dependency are as follows:

  • Project Details

  • Project Center

  • Resource Assignments

  • Resource Center

  • My Tasks

  • Approval Center

  • Team Tasks

  • My Schedule

  • My Timesheet

Use the following procedure to enable the Project Web App Server ribbon feature on a site if the PWA Web Part that you are adding has a dependency on it:

To enable the ribbon feature on a site

  1. On the site on which you want to enable the ribbon, click the Site Actions menu, and then click Site Settings.

  2. On the Site Settings page, in the Site Collection Administration section, click Site Collection Features.

  3. On the Site Collection Administration-Features page, find Project Web App Ribbon and then click the Activate button to the right of it.

See Also

Concepts

Plan for Project Server 2010 Web Parts
Add or remove Project Web App Web Parts for a site in the Project Web App site collection (Project Server 2010)
Upgrade considerations for Project Web App Web Parts

Other Resources

Manage Web Part pages (SharePoint Server 2010)
Developing Project Server 2010 Web Parts


Best practices for managing a large number of resources in Project Server 2010

Published: November 29, 2011

This article describes best practices for managing users in a Microsoft Project Server 2010 environment when you have projects that have lots of users.

In this article:

  • Overview of Project Server 2010 site permissions

  • Microsoft SharePoint Server 2010 permissions for Project Server 2010 users

  • Performance issues when the recommended user limit to project sites is exceeded

  • Inheriting permissions from the PWA parent site

  • Disabling Project Site Permission settings

  • Errors associated with exceeded recommended user limits to project sites

Overview of Project Server 2010 site permissions

Project Server 2010 uses the normal SharePoint permissions infrastructure to set access control for the Microsoft Project Web App (PWA) site. It also uses that same infrastructure to set access control for any project sites (previously known as project workspace sites) that are created for the individual project plans held in Project Server.

At the PWA site level, users are added to specific SharePoint groups depending on their permission level within Project Server. The site settings page for a PWA site contains "Microsoft Project Server" SharePoint groups for Project Managers, Readers, Team members, Web Administrators, and Workflow and Project Detail Pages Administrators. When users are added in Project Server 2010, they are also added to the appropriate group for the PWA site that they are allowed to access. For example, let's say a user is added to Project Server 2010 and is a member of the Project Managers security group. The user is added to the Project Managers Group (Microsoft Project Server) in Site Permissions for the PWA home page, the Project Center page, the Approval Center page, and all PWA site pages that the user is allowed to access.

The PWA site's Site Permissions settings not only contain the "Microsoft Project Server" SharePoint groups, but also show some individual SharePoint user accounts for site collection administrators and other farm administrator accounts. The following table shows the SharePoint permission levels for the Microsoft Project Server SharePoint Group at the PWA site level.

Name | Permission level
Project Managers Group (Microsoft Project Server) | Limited Access, Project Managers (Microsoft Project Server)
Readers Group (Microsoft Project Server) | Limited Access, Readers (Microsoft Project Server)
Team members group (Microsoft Project Server) | Limited Access, Team members (Microsoft Project Server)
Web Administrators Group (Microsoft Project Server) | Limited Access, Web Administrators (Microsoft Project Server)
Workflow and Project Detail Pages Administrators Group (Microsoft Project Server) | Limited Access

For project sites, users are added directly as individuals, and they are not added to specific "Microsoft Project Server" SharePoint groups. The permission level granted to the user is determined by his or her role.

SharePoint Server 2010 permissions for Project Server 2010 users

Project Server 2010 users are given access to Project Server sites through SharePoint Server 2010 permissions. Project Server 2010 is built on Microsoft SharePoint Server 2010, and sites that are available through Project Server 2010 are SharePoint sites.

The two types of Project Server 2010 sites for which SharePoint permissions have to be assigned are as follows:

  • PWA sites (PWA home page, Project Center, Resource Center, and so on)

  • Project sites (Collaboration sites for individual project. These are called project workspace sites in Office Project Server 2007).

For PWA sites, Project Server 2010 users are assigned to Microsoft Project Server SharePoint groups, depending on their permission level in Project Server 2010:

User's security role SharePoint permissions on the PWA site

  • Project Manager

  • Portfolio Manager

  • Resource Manager

  • Executive

Project Managers Group (Microsoft Project Server)

Administrator

Web Administrators Group (Microsoft Project Server)

Team Member

Team Lead

Team members group (Microsoft Project Server)

For project sites, Project Server 2010 users are provided the following SharePoint permissions. For project sites, Project Server 2010 users are added as individual SharePoint users who have specific SharePoint permissions to the site:

User | SharePoint permissions on the project site
Project Managers who have published a project | Project Managers (Microsoft Project Server)
Project Managers who have Save Project permissions on a project | Project Managers (Microsoft Project Server)
Team Members with assignments in a project | Team Members (Microsoft Project Server)
Project Server users with View Project Site permission on a project | Readers (Microsoft Project Server)

Performance issues when the recommended user limit to project sites is exceeded

In Office Project Server 2007, a performance issue can occur in user synchronization to the PWA sites because individual users are added to PWA and project workspace sites with specific permission levels. When changes are made to the user permission for the site, all users who have permissions to the site are removed, and then they are added back to the site. When there are many users on a site, this process can take a very long time. Users who are in process of being added back to the site get an Access Denied error until they are added back to the site.

In Project Server 2010, two changes were made to user access to PWA sites to correct the issue that exists in Office Project Server 2007:

  • Users who access PWA sites were added to SharePoint user groups instead of added individually.

  • When user synchronization occurs, users are removed individually and added back to the site one at a time (instead of removing all users and then adding them back one at a time).

These changes were enacted only for PWA sites, which typically have lots of users who access them. This change was not made for project sites. The reason is that project sites typically have a lot fewer users who access them (usually the resources assigned to the project) and are less likely to be affected by the synchronization issue. Where this can be an issue is when you want to have many or all of the users accessing many or all the project sites. This could be achieved either by adding many users to a project, or by assigning the View Project Sites permission at the team-member level in a category that includes many or all projects. However, when this scenario occurs, it is possible for the recommended software boundaries and limits of SharePoint Server 2010 to be exceeded if the number of users is large. Exceeding these recommended boundaries can lead to performance issues. Each user who is added individually to a site is considered a security scope. The recommended maximum number of unique security scopes per list is 1,000. Each list and library in the site would be inheriting from the parent site permissions — and would exceed this limit if more than 1,000 individual users have access to the site. For more information about security scope limitations for lists, see SharePoint Server 2010 Capacity Management: Software Boundaries and Limits.

When the recommended unique security scope boundaries are exceeded, performance issues can occur. The problems occur when a change is made in site membership caused by changes in the categories or group, or because of actions such as adding a user or deactivating a user. One reason the recommended limitation for individual users was imposed was that if it was exceeded, the process for removing users from the site can become very slow. It is especially slow if the same user is removed from multiple sites, all of which have exceeded the recommended limit. In cases in which multiple users are deactivated, it is possible that the server will become unresponsive and unable to authenticate users. This creates a unique problem when you start to exceed the recommended individual user limits for a site. Your server could become unresponsive when you have to manage users because you have too many users who have permission on a site. When you attempt to correct the problem by removing users from the site, you can also make the server unresponsive.

Best practices for avoiding this issue depend on what your intended purpose is:

  • If you really do require that most of the users can access most of the project sites: Instead of adding users individually to sites, use SharePoint Server 2010 groups and use inheritance from PWA to add the users to these groups. For example, generally the parent site for project sites is the PWA home site. In this scenario, project sites will inherit the permissions of the PWA home site, which has all PWA users in Microsoft Project Server SharePoint groups.

  • If having many users who are accessing many sites is unintended and you have to resolve the problem: Remove the View Project Sites category permission from the category that gives users access to the sites. You can also reduce the number of resources assigned to the project. Prior to doing either action, you must stop the synchronization of users to the site. Otherwise, either action may make your server unresponsive.

To disable project site synchronization, you can write a utility that uses the Project Server Interface (PSI), the Admin Web Service, and sets the UserSyncSetting Enumerationto DisablePWS. Call the enumeration with the Admin.UpdateUserSyncSetting Method.

Member name | Description
Enable | Value=0 Enable all synchronizations
DisablePWA | Value=1. Disable synchronization with Project Web App.
DisablePWS | Value=2. Disable synchronization with project sites for the user.
DisableEmailSync | Value=3. Disable e-mail synchronization.
DisableAll | Value=4. Disable all synchronizations.

You can also disable the setting by making changes directly to the MSP_WEB_ADMIN table in the Published database in the WADMIN_USER_SYNC_SETTING column. You can run the following SQL query to disable project site synchronization:

Copy Code
Update [ProjectServer_Published].[dbo].[msp_web_admin] set [WADMIN_USER_SYNC_SETTING]=2

You may find the option of making changes directly to the MSP_WEB_ADMIN table in the Published database to be much easier than creating and testing a tool to do the same thing through the PSI.

Note:

In most instances, we recommend against changing the Published database directly. Furthermore, if you do this, it can invalidate your support. However, using the previous query to disable project site synchronization is an allowed exception.

Inheriting permissions from the PWA parent site

Once project site synchronization is disabled, it is still possible to trigger the same issues if you try to remove users directly from the project site through the functionality that is provided in the SharePoint site permission page. One way to remove users quickly without triggering the individual deletion that causes the problem is to inherit permissions from the parent site. This can be done through the user interface ribbon on the Site Permissions page of the individual project site (under the Site Actions menu).

To inherit permissions from the parent site to the project site

  1. On the project site, click Site Actions, and then click Site Permissions.

  2. On the Permissions page, click the Edit ribbon.

  3. Click Inherit Permissions.

  4. On the message box that warns you that changing to inherited permissions may prevent users from accessing the site, click OK.

The ribbon will indicate that the site now inherits permissions from its parent site, which should be a PWA site. The site permission structure from the parent site will now be the site permission structure for the project site, which means that individual PWA users are now contained within Microsoft Project Server site groups.

If your end goal is to give most users access to most sites, you may want to have your project sites inherit parent permissions from PWA as described above. Before taking this action, you should make sure that the PWA site has the right permissions for all users who need access. This is because the permission that the users have in PWA will be the permission the users will have in the project site when you execute the procedure to inherit permissions.

If you have many project sites, you can use Windows PowerShell to automate the change for you. The following Windows PowerShell command causes all project sites that are children of the specified parent PWA site to inherit its permissions. You can run the Windows PowerShell command in the SharePoint 2010 Management Shell:

Copy Code
$site = Get-SPSite "<url of PWA>"
     Foreach ($web in $site.AllWebs) {
        $web.Update()
        $web.ResetRoleInheritance()
        $web.Update()
        }
     $site.Dispose()

You would have to run this command (or the previous procedure for inheriting site permissions) for any new project sites to avoid a reoccurrence of the issue.

Note:

Clicking the Synchronize option on the project site page in PWA Server Settings will re-break inheritance. Make sure not to click this option if you want the project site to continue to inherit permissions from its parent PWA site.

In an environment in which all project sites are inheriting PWA permissions, it is possible that you may want to have certain projects that have sensitive information and you would want to manage permissions and users at an individual level. It would be possible to use Windows PowerShell to set a property for these sites, and then use the property to filter it out in a modified version of the Windows PowerShell command used to set inheritance (above).

Disabling the Project Site Permissions setting

You can also avoid the automatic addition of users to your project sites by disabling the Project Site Permissions setting located in the Operational Policies section of your Project Web App Server Settings. When this setting is enabled, Project Web App users are automatically synchronized with project sites whenever user permissions change in Project Server 2010, the project manager publishes the project, or when the project site is created. If the setting is enabled and any of the above things occurs, the following actions will occur automatically:

  • Project managers who have published a project or who have Save Project permission on a project are added to the site with Project Manager (Microsoft Project Server) permissions.

  • Team members with assignments in a project are added to the site with Team Members (Microsoft Project Server) permissions.

  • Other Project Server users who have View Project Site permissions on a project are added to the site with Readers (Microsoft Project Server) permissions.

Disabling this option stops the automatic addition of Project Server users to the site, but it will not remove users that have already been added.

To disable the Project Site Permissions setting

  1. On the Server Settings page, in the Operational Policies section, click Project Site Provisioning Settings.

  2. On the Project Site Provisioning Settings page, in Project Site Permissions section, clear the check box labeled Check to automatically synchronize Project Web App users with Project Sites when they are created, when project managers publish projects, and when user permissions change in Project Server.

    When the check box is cleared, Project Server users are never synchronized with project sites.

  3. Click Save.

For more information about the Project Site Permissions setting, see Project Site Provisioning Settings (Project Server 2010 settings).

Errors associated with exceeded recommended user limits to project sites

The following are errors that might appear in the ULS logs when your Project Server deployment has performance problems because more than the recommended maximum users are accessing project sites. Typically the user who initiates the problem (perhaps by deactivating a resource), sees the Save button on the Edit User page hang on the "clicked" position, eventually displaying a message that "An unexpected error has occurred." The correlation ID can be found in the ULS logs, and it will provide data that relates to an SQL deadlock. The "Critical" level entry will resemble the following:

  • 08/10/2011 12:17:02.85 w3wp.exe (0x2178) 0x314C SharePoint Foundation Database 5586 Critical Unknown SQL Exception 1205 occurred. Additional error information from SQL Server is included below. Transaction (Process ID 80) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. 886d9cdd-5c0c-4f3a-8f89-f4e8c92acde3

A "High" level error that provides more information about the query causing the issue will resemble the following text. The entry provided has been shortened significantly, but do note the key "proc_SecRemoveUserFromSite" text:

  • 08/10/2011 12:17:06.97 w3wp.exe (0x2178) 0x314C SharePoint Foundation Database tzkv High SqlCommand: 'SET NOCOUNT ON; DECLARE @DN nvarchar(256),@LN nvarchar(128),@@DocUIVersion int,@@S uniqueidentifier,@@Level tinyint; DECLARE @ItemId int; DECLARE @@iRet int; DECLARE @ExtraItemSize int; SET @@Level = 1; SET @@S=@wssp0; EXEC @@iRet = proc_SecRemoveUserFromSite @@S, @wssp1, @wssp2 SELECT @ItemId = @wssp3 IF @@iRet <> 0 BEGIN GOTO DONE; END ;BEGIN TRAN IF NOT EXISTS( SELECT tp_ID FROM UserData WHERE tp_ListId = '06C8C9BB-B10B-4042-8859-9F9985E73E76' AND tp_ID = @ItemId AND tp_Level = 1 AND tp_RowOrdinal =0) BEGIN SELECT @ExtraItemSize = 0 EXEC @@iRet = proc_AddListItem @SiteId….

An "Unexpected" level entry that also may be generated, similar to the following:

  • 08/10/2011 12:17:06.97 w3wp.exe (0x2178) 0x314C SharePoint Foundation Runtime tkau Unexpected System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x80131904 at Microsoft.SharePoint.Library.SPRequestInternalClass.UpdateMembers(String bstrUrl, UInt32 dwObjectType, String bstrObjId, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bRemoveFromCurrentScopeOnly, Boolean bSendEmail) at Microsoft.SharePoint.Library.SPRequest.UpdateMembers(String bstrUrl, UInt32 dwObjectType, String bstrObjId, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bRemoveFromCurrentScopeOnly, Boolean bSendEmail) 886d9cdd-5c0c-4f3a-8f89-f4e8c92acde3

The server could be unresponsive for 15-30 minutes. During this time, other users will get timeout errors on their pages and the ULS logs may show the following entries:

  • 08/10/2011 12:20:22.30 w3wp.exe (0x1228) 0x1454 SharePoint Foundation Monitoring b4ly High Leaving Monitored Scope (ExecuteStoredProcedureDataReader -- MSP_AUTH_GETUSERBYNAME). Execution Time=120002.728838442 2be0491a-a64b-4237-8cfc-40342a374d49
  • 08/10/2011 12:20:22.30 w3wp.exe (0x1228) 0x1454 Project Server General 8ym5 Monitorable PWA:http://<server>/PWA, ServiceApp:Project Web App Service Application, User:, PSI: SqlException occurred in DAL: <Error><Class>0</Class><LineNumber>0</LineNumber><Number>-2</Number><Procedure></Procedure> <Message> System.Data.SqlClient.SqlError: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. </Message> <CallStack> at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at …


Security and protection for Project Server 2010

Published: May 12, 2010

This section provides information and best practices about how to make the Microsoft Project Server 2010 system more secure and how to help protect data.

  • Security and protection for SharePoint Server 2010

  • Plan for authentication in Project Server 2010

  • Plan groups, categories, and RBS in Project Server 2010

  • Project Server 2010 global permissions

  • Project Server 2010 category permissions


Technical reference for Project Server 2010

Published: May 12, 2010

Technical references include information about the Microsoft Project 2010 provider for Windows PowerShell, the Stsadm command-line tool, and other useful reference information about general settings, security, and tools.

In this section:

  • Windows PowerShell for Project Server 2010

    Windows PowerShell can be used with Microsoft Project Server 2010 to perform both simple and complex administrative tasks.

  • Project Server 2010 global permissions

    This article describes the global permissions for Microsoft Project Server 2010.

  • Project Server 2010 category permissions

    This article describes the category permissions for Microsoft Project Server 2010.

  • Microsoft Project Server 2010 default categories

    This article describes the default settings for each of seven default categories for Project Server 2010.

  • Project Server 2010 default group permissions

    This article describes the default permissions that are given to the default templates and user groups in Project Server 2010.

  • General reference for Project Web App (Project Server 2010)

    This section shows the Keyboard shortcuts for Microsoft Project Web App.

  • System Center Operations Manager knowledge articles (Project Server)

    The articles in this section are knowledge articles for the Microsoft Project Server 2010 management pack for Microsoft System Center Operations Manager 2007. Typically, you would encounter one of these articles after clicking a link in an alert in the Operations Manager console. You can use these articles to help you troubleshoot and resolve problems in Project Server 2010.

  • Accessing Project Web App and Project Professional from a Macintosh-based computer

    Describes two options for those who want to access a Project Web App site or use the Project Professional client from a Macintosh-based computer.

  • Conformance statement A-level (Project Server 2010)

    This article is a conformance statement for Project Server 2010 in regards to Web Content Accessibility Guidelines 2.0 (http://www.w3.org/TR/WCAG20/).

  • Conformance statement AA-level (Project Server 2010)

    This article is a conformance statement for Project Server 2010 in regards to Web Content Accessibility Guidelines 2.0 (http://www.w3.org/TR/WCAG20/).


Windows PowerShell for Project Server 2010
See Also

Published: May 12, 2010

Windows PowerShell can be used with Microsoft Project Server 2010 to perform both simple and complex administrative tasks. Information about cmdlets in Project Server 2010 is currently accessible using command-line Help. For information about Windows PowerShell in general, visit the Windows PowerShell Technology Center (http://go.microsoft.com/fwlink/p/?LinkId=167152).

In this section:

  • SharePoint 2010 Products administration by using Windows PowerShell

  • Windows PowerShell for Project Server 2010 reference

See Also

Other Resources

TechNet Script Center Repository (http://go.microsoft.com/fwlink/p/?LinkId=190444)
MSDN Code Gallery: Windows PowerShell Cmdlets for Project Server PSI (http://go.microsoft.com/fwlink/p/?LinkId=190445)


SharePoint 2010 Products administration by using Windows PowerShell

Published: May 12, 2010

This article describes how to use Windows PowerShell with Microsoft SharePoint 2010 Products and provides an overview of basic Windows PowerShell cmdlets and concepts necessary to get the most benefit from this powerful functionality.

In this article:

  • Overview

  • Accessing Windows PowerShell for SharePoint 2010 Products

  • Permissions

  • Scripts and execution policies

  • Learning Windows PowerShell

Overview

Windows PowerShell is a command-line scripting tool that provides an administrator full access to applicable application programming interfaces (APIs), along with the ability to unlock the capability to interact directly with SharePoint 2010 Products to manipulate Web applications, site collections, sites, lists and much more. In addition, the administrator has the ability to script cmdlets (pronounced "command-lets"), which makes for an improved experience from past product versions.

Windows PowerShell 2.0 is a pre-requisite for installing SharePoint 2010 Products. It will be installed, if necessary, when you run the Microsoft SharePoint Products Preparation Tool. By default, Windows PowerShell is located at the following path: <%SystemRoot%>\System32\WindowsPowerShell\v1.0\PowerShell.exe.

Note:

Windows PowerShell 2.0 is backward compatible with Windows PowerShell 1.0 and subsequently installs to the v1.0 folder.

For a list of new features for Windows PowerShell version 2.0, see About Windows PowerShell 2.0 (http://go.microsoft.com/fwlink/p/?LinkId=113247).

For an interactive tool and guide that helps you learn Windows PowerShell syntax, see Windows PowerShell Command Builder Tool and Getting Started Guide.

We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

Accessing Windows PowerShell for SharePoint 2010 Products

After installing SharePoint 2010 Products, the applicable Windows PowerShell cmdlets are available by using the SharePoint 2010 Management Shell, or by using the Windows PowerShell console. With the management shell, you can manage every aspect of SharePoint 2010 Products. You can create new site collections, Web applications, user accounts, service applications, proxies, and more. The commands from the management shell output SharePoint objects based on the Microsoft .NET Platform. These objects can be applied as input to subsequent commands or stored in local variables for later use.

With the management shell, you do not have to register the snap-in that contains the cmdlets. Registration of the Microsoft.SharePoint.PowerShell.dll module for SharePoint 2010 cmdlets is automatic, as a result of the line Add-PSSnapin Microsoft.SharePoint.PowerShell in the SharePoint.ps1 file located in %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\Config\PowerShell\Registration. If you choose to use the Windows PowerShell console, you must register this snap-in manually.

Whether you are using the management shell or the Windows PowerShell console, you can also load additional snap-ins. For more information, see Customizing Profiles (http://go.microsoft.com/fwlink/p/?LinkId=183166).

To access the SharePoint 2010 Management Shell

  1. On the Start menu, click All Programs.

  2. Click Microsoft SharePoint 2010 Products.

  3. Click SharePoint 2010 Management Shell.

Note:

The SharePoint 2010 Management Shell and the Windows PowerShell console also differ in the use of the ReuseThread option, which defines how the threading model is used. The management shell's use is defined by this line, {Host.Runspace.ThreadOptions = "ReuseThread"}, which is in the SharePoint.ps1 file. For more information, see PS Thread Options (http://go.microsoft.com/fwlink/p/?LinkId=183145).

Permissions

Before you can use the management shell and the Windows PowerShell cmdlets, verify that you meet the following minimum requirements: See Add-SPShellAdmin.

If you do not have membership in the SharePoint_Shell_Access role or WSS_Admin_WPG local group, use the Add-SPShellAdmin cmdlet. When the Add-SPShellAdmin cmdlet is used, the user is added to the WSS_Admin_WPG group in all front-end Web servers and is added to the SharePoint_Shell_Access role. If the target database does not have a SharePoint_Shell_Access role, the role is automatically created. Once the Add-SPShellAdmin cmdlet has been run, the user can run SharePoint 2010 Windows PowerShell cmdlets in a multiple-server farm environment.

When you run the Add-SPShellAdmin cmdlet to add a user to the SharePoint_Shell_Access role, you must have the following security permissions:

  • Securityadmin server role access on the SQL instance and the db_owner role in a database.

  • Administrative permission on the local computer.

Note:

Typically, the person that will use the Add-SPShellAdmin cmdlet must be associated with the user account that was used for Setup.

You must run the Add-SPShellAdmin cmdlet for all databases to which you want to grant access. If no database is specified, the farm configuration database is used. If you do specify a database, the farm content database will be included in addition to the farm configuration database you specify.

To see a list of all of the *SPShellAdmin cmdlets, from a Windows PowerShell command prompt, type Get-Command -Noun SPShellAdmin.

Scripts and execution policies

Although you can use Windows PowerShell to perform a single administrative task, the real benefit of using Windows PowerShell cmdlets is the ability to use a script to automate a series of tasks. A script is a plain text file that contains one or more Windows PowerShell commands. Windows PowerShell scripts have a .ps1 file name extension.

When using a script, be aware that the minimum required execution policy for SharePoint 2010 Products is RemoteSigned, while the default policy for Windows PowerShell is Restricted. If the policy is left as Restricted, the SharePoint 2010 Management Shell will change the policy for Windows PowerShell to RemoteSigned. This means the SharePoint 2010 Management Shell must be launched with elevated administrative permission by selecting Run as administrator. This change will apply to all Windows PowerShell sessions.

For additional information about scripts and execution polices, see about_scripts and about_Execution_Policies respectively.

Learning Windows PowerShell

There are several Windows PowerShell learning resources for SharePoint IT professionals who are not familiar with Windows PowerShell.

TechNet Scripting Center

The TechNet Scripting Center includes many resources for learning the basics of using Windows PowerShell. It also contains script repositories with samples of scripts commonly used with various Microsoft products. The following table shows the main learning resources.

Page | Description
Windows PowerShell Documentation on TechNet (http://go.microsoft.com/fwlink/p/?LinkId=187813) | This section of the TechNet Library contains Web copies of the core Windows PowerShell Get-Help topics. The section also has Web copies of the Windows PowerShell Getting Started document, the PowerShell.exe help, and a Windows PowerShell primer.
Scripting With Windows PowerShell (http://go.microsoft.com/fwlink/p/?LinkId=187815) | The home page for Windows PowerShell scripting learning resources.
Windows PowerShell Owner's Manual (http://go.microsoft.com/fwlink/p/?LinkId=187817) | Web-based guide for getting started with Windows PowerShell.
Windows PowerShell Quick Reference (http://go.microsoft.com/fwlink/p/?LinkId=187819) | Downloadable copy of the Quick Reference document installed with Windows PowerShell.

Windows PowerShell documents

Windows PowerShell installs the following documents in the Windows PowerShell 1.0 program group. They can also be installed after downloading the Windows PowerShell 1.0 Documentation Pack (http://go.microsoft.com/fwlink/p/?LinkId=187822).

File | Description
GettingStarted.rtf | Describes how to start using Windows PowerShell.
UsersGuide.rtf | A primer for the Windows PowerShell environment and language.
QuadFold.rtf | A printable quick reference document for the commonly used Windows PowerShell syntax and commands. Also available as a download from the TechNet Scripting Center.

As you read these resources, consider that the following concepts and cmdlets are useful ones to learn before using Windows PowerShell for SharePoint 2010 Products:

  • Get-Command (http://go.microsoft.com/fwlink/p/?LinkId=171069)

  • Get-Member (http://go.microsoft.com/fwlink/p/?LinkId=171070)

  • Get-Help (http://go.microsoft.com/fwlink/p/?LinkId=171068).

  • Aliasing (http://go.microsoft.com/fwlink/p/?LinkId=113207)

  • Piping and the Pipeline in Windows PowerShell (http://go.microsoft.com/fwlink/?LinkId=187808)

  • Cmdlet Parameter Sets (http://go.microsoft.com/fwlink/p/?LinkId=187810)

  • Foreach-Object (http://go.microsoft.com/fwlink/p/?LinkId=187812)

  • Where-Object (http://go.microsoft.com/fwlink/p/?LinkId=187811)


Windows PowerShell for Project Server 2010 reference

Published: May 12, 2010

The following article lists Windows PowerShell cmdlets for Microsoft Project Server 2010 by functionality.

Category article

Project Server 2010 cmdlets


Project Server 2010 cmdlets

Published: May 12, 2010

You can use Windows PowerShell cmdlets to create and configure a Microsoft Project Server Service application, create and configure a Microsoft Project Web App (PWA) instance, and create and configure Project Server permissions.

Microsoft Project Server is a project management tool that you can use to manage projects more efficiently and effectively. You can stay informed; control project work, schedules, and finances; keep project teams aligned; and be more productive through integration with familiar Microsoft Office system programs.

New features in Microsoft Project Server 2010 include more closely integrated project and portfolio management capabilities, better and more scalable collaboration for both small teams and enterprises, and the ability to extended platform and integration with related Microsoft technologies.

Cmdlet name | Description
Get-SPProjectWebInstance | Returns an instance of a Project Server Service application.
New-SPProjectServiceApplication | Creates a new Project Server Service application.
New-SPProjectServiceApplicationProxy | Creates a proxy for a Project Server Service application.
New-SPProjectSiteAdministrator | Creates a Microsoft Project Server 2010 administrator account for the requested user.
New-SPProjectWebInstance | Creates a new instance of a Project Server Service application.
Remove-SPProjectSiteAdministrator | Removes an account from a Microsoft Project Web App (PWA) instance.
Remove-SPProjectWebInstance | Deletes an instance of a Project Server Service application.
Set-SPProjectServiceApplication | Sets properties of a Project Server Service application.
Set-SPProjectWebInstance | Sets the properties of an instance of a Project Server Service application.
Upgrade-SPProjectWebInstance | Upgrades a single Project Web App site.


Get-SPProjectWebInstance
See Also Example
[image]

Published: May 12, 2010

Returns an instance of a Microsoft Project Web App.

Get-SPProjectWebInstance [-AssignmentCollection <SPAssignmentCollection>] [-ServiceApplication <PsiServiceApplicationPipeBind>] [-Url <String>]

Parameters

Parameter Required Type Description

ServiceApplication

Optional

Microsoft.Office.Project.Server.Cmdlet.PsiServiceApplicationPipeBind

Specifies the name of the Microsoft Project Server 2010 service application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a Project Web Access instance (for example, ProjectWebApp1); or an instance of a valid PsiServiceApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Url

Optional

System.String

Specifies the URL of the Project Web App (PWA) instance to get.

The type must be a valid URL, in the form http://server_name/PWA_name.

Detailed Description

The Get-SPProjectWebInstance cmdlet returns an instance of a Project Web App site, including the following information:

  • ID (GUID)

  • Service application name

  • Parent Web App

  • Project Web App URL

  • Location ID (LCID)

  • Admin account

  • Primary and reporting database servers

  • Database names for Published, Draft, Archive, and Reporting databases

  • Provisioning status

  • Report center status

  • Site ID (GUID)

Input Types

Return Types

Example

----------------------EXAMPLE-----------------------

Copy Code
Get-SPProjectWebInstance -Url http://server/pwa

This example returns the properties for a PWA instance at http://server/pwa.

See Also

Reference

New-SPProjectWebInstance
Remove-SPProjectWebInstance
Set-SPProjectWebInstance


New-SPProjectServiceApplication
See Also Example
[image]

Published: May 12, 2010

Creates a new Project Server Service application.

New-SPProjectServiceApplication [-Name] <String> -ApplicationPool <SPIisWebServiceApplicationPoolPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Proxy <SwitchParameter>]

Parameters

Parameter Required Type Description

ApplicationPool

Required

Microsoft.SharePoint.PowerShell.SPIisWebServiceApplicationPoolPipeBind

Specifies the existing IIS application pool to run the Web service in for the new service application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of an application pool (for example, AppPoolName1); or an instance of a valid IISWebServiceApplicationPool object.

Name

Required

System.String

Specifies the name of the new Project Server Service application.

The type must be a valid name of a Project Server Service application; for example, ProjectWebApp1.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Proxy

Optional

System.Management.Automation.SwitchParameter

Specifies that a proxy for new service application is automatically created.

Detailed Description

The New-SPProjectServiceApplication cmdlet creates a new Project Server Service application.

Input Types

Return Types

Example

--------------EXAMPLE 1-------------------

Copy Code
New-SPProjectServiceApplication -Name "PsiApplication" -ApplicationPool "PsiApplicationPool" -Proxy

This example creates a Project Server Service application with the name PsiApplication and application pool PsiApplicationPool and creates a Project Server Service application proxy for the application.

--------------EXAMPLE 2-------------------

Copy Code
Get-SPIisWebServiceApplicationPool "PsiApplicationPool" | New-SPProjectServiceApplication -Name "PsiApplication"

This example creates a Project Server Service application with the name PsiApplication. The result is piped using an application pool object.

See Also

Reference

Set-SPProjectServiceApplication


New-SPProjectServiceApplicationProxy
Example
[image]

Published: May 12, 2010

Creates a proxy for a Project Server Service application.

New-SPProjectServiceApplicationProxy [-Name] <String> -ServiceApplication <PsiServiceApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Name

Required

System.String

Specifies the name of the new proxy.

The type must be a valid name of a Project Server Service application proxy; for example, ProjectSvcProxy1.

ServiceApplication

Required

Microsoft.Office.Project.Server.Cmdlet.PsiServiceApplicationPipeBind

Specifies the Project Server Service application to associate with the new proxy.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a Project Server service application (for example, ProjectWebApp1); or an instance of a valid PsiServiceApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Default

Optional

System.Management.Automation.SwitchParameter

Specifies that this is the default proxy for the specified Project Server Service application.

Detailed Description

The New-SPProjectServiceApplicationProxy cmdlet creates a proxy for a Project Server Service application.

Input Types

Return Types

Example

-------------------EXAMPLE 1------------------

Copy Code
New-SPProjectServiceApplicationProxy -Name PsiApplicationProxy -ServiceApplication PsiApplication

This example creates a Project Server Service application proxy with name PsiApplicationProxy for the application PsiApplication.

-------------------EXAMPLE 2------------------

Copy Code
Get-SPServiceApplication | ?{ $_.Name -eq "PsiApplication" } | New-SPProjectServiceApplicationProxy -Name "PsiApplicationProxy" -Default

This example creates a Project Server Service application proxy with name PsiApplicationProxy for the application PsiApplication and adds the proxy to Default proxy group.


New-SPProjectSiteAdministrator
See Also Example
[image]

Published: May 12, 2010

Creates a Microsoft Project Web App administrator account for the requested user.

New-SPProjectSiteAdministrator -AdminAccount <String> -Url <String> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AdminAccount

Required

System.String

Specifies the user to add in the form of domain\user or user@domain.

Url

Required

System.String

Specifies the Project Web App on which to add the administrator account. The account designated by the AdminAccount parameter will be added to the Administrators group on Project Web App.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The New-SPProjectSiteAdministrator cmdlet creates a Project Web App administrator account for the requested user.

Input Types

Return Types

Example

---------------------EXAMPLE----------------------------

Copy Code
New-SPProjectSiteAdministrator -AdminAccount domain\user -Url http://servername/pwa

This example adds domain\user as an administrator to the PWA instance that is hosted at http://servername/pwa.

See Also

Reference

Remove-SPProjectSiteAdministrator


New-SPProjectWebInstance
See Also Example
[image]

Published: May 12, 2010

Creates a new instance of a Microsoft Project Web App (PWA) site.

New-SPProjectWebInstance -AdminAccount <String> -ArchiveDbname <String> -DraftDbname <String> -PrimaryDbserver <String> -PublishedDbname <String> -ReportingDbname <String> -ReportingDbserver <String> -Url <String> [-AssignmentCollection <SPAssignmentCollection>] [-HostHeaderWebapplicationUrl <String>] [-Lcid <Int32>] [-PrimaryDBMirrorServer <String>] [-ReportingDBMirrorServer <String>] [-Wait <SwitchParameter>]

Parameters

Parameter Required Type Description

AdminAccount

Required

System.String

Specifies the administrator account to use for creating and running the Project Web App site.

The type must be a valid name of an administrator account; for example, MyAdminAcct1.

ArchiveDbname

Required

System.String

Specifies the name of the archive database that this instance of Project Web App will use.

The type must be a valid name of a SQL Server database; for example, PWA_Archive.

DraftDbname

Required

System.String

Specifies the name of the draft database that this instance of Project Web App will use.

The type must be a valid name of a SQL Server database; for example, PWA_Draft.

PrimaryDbserver

Required

System.String

Specifies the host server for the Draft, Archive, and Published databases.

The type must be a valid instance of SQL Server.

PublishedDbname

Required

System.String

Specifies the name of the published database that this instance of Project Web App will use.

The type must be a valid name of a SQL Server database; for example, PWA_Published.

ReportingDbname

Required

System.String

Specifies the name of the reporting database that this instance of Project Web App will use.

The type must be a valid name of a SQL Server database; for example, PWA_Reporting.

ReportingDbserver

Required

System.String

Specifies the host server for the reporting database.

The type must be a valid instance of SQL Server.

Url

Required

System.String

Specifies the URL of the new PWA instance.

The type must be a valid URL, in the form http://server_name/instance_name.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

HostHeaderWebapplicationUrl

Optional

System.String

Specifies the URL of the Web application to use for the host header site.

The type must be a valid URL, in the form http://server_name.

Lcid

Optional

System.Int32

Specifies the locale ID of the new PWA instance. The ID is set to the server locale ID if this parameter is set to 0 or not specified.

The type must be a valid Locale ID (LCID).

Wait

Optional

System.Management.Automation.SwitchParameter

Specifies the creation of the PWA instance synchronously; that is, waits for the creation of the job to complete before returning.

Detailed Description

The New-SPProjectWebInstance cmdlet creates a new instance of a Project Web App site.

Input Types

Return Types

Example

--------------EXAMPLE--------------

Copy Code
New-SPProjectWebInstance -Url "http://SERVER/pwa" -AdminAccount "CONTOSO\FarmAdmin" -PrimaryDbserver "SQLSERVER1" -PublishedDbname "ProjectServer_Published" -ArchiveDbname "ProjectServer_Archive" -DraftDbname "ProjectServer_Draft" -ReportingDbserver "SQLSERVER2" -ReportingDbname "ProjectServer_Reporting"

This example creates a PWA instance with specified parameters.

See Also

Reference

Get-SPProjectWebInstance
Remove-SPProjectWebInstance
Set-SPProjectWebInstance


Remove-SPProjectSiteAdministrator
See Also Example
[image]

Published: May 12, 2010

Removes an account from a Microsoft Project Web App (PWA) instance.

Remove-SPProjectSiteAdministrator -AdminAccount <String> -Url <String> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AdminAccount

Required

System.String

Specifies the name of the user to remove, in the form domain\user or user@domain.

Url

Required

System.String

Specifies the PWA site where the user account is located.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

You can remove an account from a PWA instance by running the Remove-SPProjectSiteAdministrator cmdlet.

When the cmdlet is successfully run, the requested user account is deleted. All assignments made to that user are lost. This cmdlet can be used to remove any Project Web App user account, not just members of the Project Web App Administrators group.

Input Types

Return Types

Example

-----------------------EXAMPLE-----------------------

Copy Code
Remove-SPProjectSiteAdministrator -AdminAccount domain\user -Url http://servername/pwa

This example removes the domain\user user account from the PWA instance that is hosted at http://servername/pwa.

See Also

Reference

New-SPProjectSiteAdministrator


Remove-SPProjectWebInstance
See Also Example
[image]

Published: May 12, 2010

Deletes an instance of Microsoft Project Web App (PWA).

Remove-SPProjectWebInstance -Url <String> [-AssignmentCollection <SPAssignmentCollection>] [-KeepSiteCollection <SwitchParameter>] [-Wait <SwitchParameter>]

Parameters

Parameter Required Type Description

Url

Required

System.String

Specifies the URL of the Project Web App (PWA) instance to delete.

The type must be a valid URL, in the form http://server_name/PWA_instance.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

KeepSiteCollection

Optional

System.Management.Automation.SwitchParameter

Specifies that the site collection is retained when the PWA instance is removed.

Wait

Optional

System.Management.Automation.SwitchParameter

Specifies when the delete job is performed.

Any one of the following values:

True- the delete job is performed

False - the delete job is queued.

The default value is False.

Detailed Description

The Remove-SPProjectWebInstance cmdlet deletes an instance of Project Web App.

Input Types

Return Types

Example

--------------------EXAMPLE-----------------

Copy Code
Remove-SPProjectWebInstance -Url http://WFESERVER/pwa

This example removes the specified PWA instance.

See Also

Reference

Get-SPProjectWebInstance
New-SPProjectWebInstance
Set-SPProjectWebInstance


Set-SPProjectServiceApplication
See Also Example
[image]

Published: May 12, 2010

Sets properties of a Project Server Service application.

Set-SPProjectServiceApplication [-Identity] <PsiServiceApplicationPipeBind> [-ApplicationPool <SPIisWebServiceApplicationPoolPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-RegisterTimerJob <SwitchParameter>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.Office.Project.Server.Cmdlet.PsiServiceApplicationPipeBind

Specifies the Project Server Service application to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a Project Web application (for example, ProjectWebApp1); or an instance of a valid PsiServiceApplication object.

ApplicationPool

Optional

Microsoft.SharePoint.PowerShell.SPIisWebServiceApplicationPoolPipeBind

Specifies the existing IIS application pool to run the Web service in for the service application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of an application pool (for example, AppPoolName1); or an instance of a valid IISWebServiceApplicationPool object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

RegisterTimerJob

Optional

System.Management.Automation.SwitchParameter

Specifies if timer jobs should be re-registered in Microsoft SharePoint Server 2010.

Detailed Description

The Set-SPProjectServiceApplication cmdlet sets properties of a Project Server Service application.

Input Types

Return Types

Example

--------------------EXAMPLE---------------------

Copy Code
Set- SPProjectServiceApplication -Identity PSIServiceApp -ApplicationPool newapppool RegisterTimerJob

This example updates the application pool and re-registers the timer job for a Project Server Service application.

See Also

Reference

New-SPProjectServiceApplication


Set-SPProjectWebInstance
See Also Example
[image]

Published: May 12, 2010

Sets the properties of an instance of Microsoft Project Web App.

Set-SPProjectWebInstance -AdminAccount <String> -ArchiveDbname <String> -DraftDbname <String> -PrimaryDbserver <String> -PublishedDbname <String> -ReportingDbname <String> -ReportingDbserver <String> -Url <String> [-AssignmentCollection <SPAssignmentCollection>] [-PrimaryDBMirrorServer <String>] [-ReportingDBMirrorServer <String>] [-Wait <SwitchParameter>]

Parameters

Parameter Required Type Description

AdminAccount

Required

System.String

Specifies the administrator account to use for the PWA instance.

The type must be a valid name of an administrator account; for example, MyAdminAcct1.

ArchiveDbname

Required

System.String

Specifies the name of the archive database that the instance of Project Web App will use.

The type must be a valid name of an existing Project Server Archive database.

DraftDbname

Required

System.String

Specifies the name of the draft database that the instance of Project Web App will use.

The type must be a valid name of an existing Project Server Draft database.

PrimaryDbserver

Required

System.String

Specifies the instance of SQL Server where the specified Draft, Archive, and Published databases reside.

PublishedDbname

Required

System.String

Specifies the name of the published database that the instance of Project Web App will use.

The type must be a valid name of an existing Project Server Published database.

ReportingDbname

Required

System.String

Specifies the name of the reporting database that the instance of Project Web App will use.

The type must be a valid name of an existing Project Server Reporting database.

ReportingDbserver

Required

System.String

Specifies the instance of SQL Server where the specified Reporting database resides.

ServiceApplication

Optional

Microsoft.Office.Project.Server.Cmdlet.PsiServiceApplicationPipeBind

Specifies the Project Server Service application associated with the PWA instance.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a Project Server Service application (for example, ProjectWebApp1); or an instance of a valid PsiServiceApplication object.

Url

Required

System.String

Specifies the URL of the PWA instance.

The type must be a valid URL, in the form http://server_name/PWA_name.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Wait

Optional

System.Management.Automation.SwitchParameter

Specifies whether to run the job immediately or queue it.

Detailed Description

The Set-SPProjectWebInstance cmdlet sets the properties of an instance of Project Web App.

Input Types

Return Types

Example

---------------------EXAMPLE----------------------

Copy Code
Set-SPProjectWebInstance -Url "http://SERVER/pwa" -AdminAccount "CONTOSO\FarmAdmin" -PrimaryDbserver "SQLSERVER1" -PublishedDbname "ProjectServer_Published" -ArchiveDbname "ProjectServer_Archive" -DraftDbname "ProjectServer_Draft" -ReportingDbserver "SQLSERVER2" -ReportingDbname "ProjectServer_Reporting"

This example updates a PWA instance with specified parameters.

See Also

Reference

Get-SPProjectWebInstance
Remove-SPProjectWebInstance


Upgrade-SPProjectWebInstance
See Also Example
[image]

Published: May 12, 2010

Upgrades a single Microsoft Project Web App site.

Upgrade-SPProjectWebInstance -Url <String> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Url

Required

System.String

Specifies the location of the Project Web App instance where the upgrade changes are to be applied.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

Use the Upgrade-SPProjectWebInstance cmdlet to apply upgrade changes to a single Project Web App site within a Microsoft SharePoint Server 2010 farm.

If you apply an update to Microsoft Project Server 2010, applying the update only updates the binaries on the server, until you run PSConfig. If you do not run PSConfig, and run the Upgrade-SPProjectWebInstance cmdlet instead, it will upgrade the Project Server 2010 databases that are associated with the specified PWA instance to match the version of the updated binaries.

Note:

Upgrade-SPProjectWebInstance only upgrades the Project Server 2010 databases. It does not upgrade any SharePoint Server 2010 databases.

Input Types

Return Types

Example

--------------------EXAMPLE------------------------

Copy Code
Upgrade-SPProjectWebInstance - Url "http://servername/pwa"

This example upgrades the Project Server 2010 databases associated with the Project Web App instance at the specified URL.

See Also

Reference

Get-SPProjectWebInstance
New-SPProjectWebInstance
Remove-SPProjectWebInstance
Set-SPProjectWebInstance


Project Server 2010 global permissions
See Also

Published: May 29, 2010

The following is a list of global permissions for Microsoft Project Server 2010. The columns in the table include the following:

  • Description Describes what the permission enables you to do.

  • Dependencies Lists any other permissions (global or category) or requirements necessary for the permission to function.

  • Previous name, if renamed from Project Server 2003 Specifies the Office Project Server 2007 permission name if the permission was renamed from Office Project Server 2007 but provides the same functionality.

  • New for Project Server 2010 Displays an × symbol if the permission is new for Project Server 2010.

Permission Description Dependencies Previous name, if renamed from Office Project Server 2007 New for Project Server 2010

About Microsoft Project Server

Allows a user to access the About Project Server page through Project Web App Server Settings.

Accept Timesheets

Allows a user to accept but not approve a timesheet. An example would be where an administrative assistant would view the timesheets to make sure that there were no inaccuracies in them. When it is accepted then a manager with Approve Timesheets permission will approve the timesheets.

Users have access to the Approval Center if they have either the Accept Timesheets or the View Approvals permission.

Build Team On New Project

Allows a user to add resources to a project that has not been saved to Project Server. Grant this permission to project managers who want to use the Build Team feature in Microsoft Project Professional to staff their projects before they save (and publish) them to Project Server.

User has to be granted the Assign Resources and View Enterprise Resource Data category permissions in order to see resources that are part of the Enterprise Resource Pool in the Build Team feature in Microsoft Project Professional.

Can be Delegate

Specifies whether a user can be a delegate.

X

Change Password

Allows a user to change their Forms user account password user account password from Project Web App. Forms authentication is provided through a membership provider and individual membership providers may prevent the changing of passwords. Please verify this with your membership provider if you intend to use this permission.

Change Workflow

Allows a user to change a project's Enterprise Project type. (Change Project Type).

X

Clean up Project Server database

Allows a user to access the Delete Enterprise Objects page available through the Server Settings page in Project Web App. Grant this permission to users who have to delete timesheets, status reports responses, projects, resources, users, and user delegates from Project Server.

Close Task to Updates

Allows a user to close tasks to Time Reporting. It gives access to the Close Tasks to Update Project Web App page.

Contribute to Project Web App

Allows users to edit items within lists in Project Web App project sites.

Contribute to Project Web App

Edit Status Report Requests

Allows a user to access the Request a status report link on the Project Web App Status Reports center and to view team reports. Grant this permission to any member of your organization who has to create status report requests and view team reports, usually project managers, resource managers, team leads, and members of your organization's PMO.

Edit Status Report Responses

Allows a user to access the Submit a status report link on the Status Reports center in Project Web App. Grant this permission to any user of Project Web App who must be able to submit status reports.

Log on

Allows a user to connect to Project Server from Microsoft Project Professional or to log on to Project Web App. Grant this permission to any user who is authorized to connect to Project Server from Microsoft Project Professional or log on to Project Web App.

Log on to Project Server from Project Professional

Allows a user to load the Enterprise Global Template when he or she connects Microsoft Project Professional to Project Server. Grant this permission to all users in your organization who will be using Microsoft Project Professional to connect to Project Server.

Manage Active Directory Settings

Allows users to modify any Active Directory Synchronization settings within the Project Web App Administration. If the user is denied this permission then they cannot modify settings for any of the following:

  • Enterprise Resource Pool synchronization settings.

  • Project Web App Security Groups synchronization settings.

  • Choose an Active Directory Group to synchronize against a specific Security Group within the Add/Modify Group page.

Manage Check-Ins

Allows a user to access the Forced Check-in Enterprise Objects page in Project Web App. This page lets users force check-in projects, resources, custom fields, calendars, lookup tables and resource plans.

Manage Cube Building Service

Allows a user to the set and modify the settings for OLAP cube creation.

Manage Drivers

Allows a user to access the drivers.aspx page and manage business drivers for project portfolio analysis.

X

Manage Enterprise Calendars

Allows a user to create, modify and delete Enterprise Calendars within Project Web App.

Manage Enterprise Custom Fields

Allows a user to modify the definitions of Enterprise Custom Fields and lookup table from Project Web App.

Manage Exchange Integration

Allows administrators to enable the synchronization of project tasks with Exchange Server.

X

Manage Gantt Chart and Grouping Formats

Allows a user to access the Gantt chart and grouping formats customization options in the Project Server Administration page for Project Web App views.

Manage Lists in Project Web App

Allows a user to create, modify, and delete lists within the Project Web App project site. This permission is used when synchronizing a user against the Project Web App project site.

Manage Notification and Reminders

Allows a user to manage the Notification and Reminders settings.

X

Manage My Delegates

Allows users to see the "Manage Delegates" link and to set a delegate on the "Add/Modify Delegation" page.

X

Manage My Resource Delegates

Allows users to set a user who requires a substitute on the Add/Modify Delegation page.

X

Manage Personal Notifications

Allows a user to access the Manage My Alerts and Reminders page in Project Web App. Grant this permission to any user that you want to be able to sign up for e-mail notifications and reminders related to tasks and status reports.

Manage Portfolio Analyses

Allows a user to create, read, update, and delete Portfolio analyses.

X

Manage Prioritizations

Allows a user to create, read, update, and delete driver prioritizations.

X

Manage Project Server Backup

Allows a user to schedule the backup or immediately back up several entities on Project Server, including the following:

  • Projects

  • The Enterprise Resource Pool

  • Calendars

  • Custom fields

  • The Enterprise Global template

  • Views

  • System settings

  • Categories

  • Group settings.

Manage Project Server Restore

Allows a user to immediately restore several entities on Project Server, including the following:

  • Projects

  • The Enterprise Resource Pool

  • Calendars

  • Custom fields

  • The Enterprise Global template

  • Views

  • System settings

  • Categories

  • Group settings.

    Note:

    Similar to Server Backup, except that the permission does not let you to schedule a recovery.

Manage Project Web App Views

Allows a user to access the Manage Views page in the Server Settings page in Project Web App. Users with permission to access this page are able to add, modify, or delete Project, Project Center, Resource Center, Assignment, or Portfolio Analyzer views, and they are able to modify Timesheet views. Grant this permission to project managers, resource managers, and members of your organization's PMO so they can create project data views for users to access in Project Web App and Microsoft Project Professional. It is important to remember that if your organization is allowing project managers to create custom fields at the project level, then each project may require its own unique view. The number of projects in this kind of environment may be too many for the IT administrator team; offloading this work to the people in your organization that work at the project level on a day-to-day basis is one way to distribute the workload of managing views.

Manage Queue

Allows the user to read or set queue configuration settings and retry, cancel, and unblock jobs in the queue.

Manage Resource Notifications

Allows a user to access the Alert me about my resources on tasks and status reports link on the Project Web App home page. Grant this permission to any resource manager or project manager you want to be able to sign up for e-mail notifications and reminders related to their resource's tasks and status reports.

Manage Rules

Allows a user to access the Rules page from the Approval Center in Project Web App and set rules on how update transactions will be automatically processed. Grant this permission to project managers, resource managers, or members of your organization's PMO so they can define how they will automatically receive and accept changes to transactions by their resources.

Manage security

Allows a user to access the Manage security page in Project Web App to define security categories, security templates, and user authentication settings. Grant this permission to Project Server administrators or a very small and closely managed group of people. This page lets users change Project Server security settings, create security categories and security templates. Changes to settings on this page, once you have begun using Project Server in your organization, should be carefully managed and (ideally) infrequent.

Manage Server Events

Allows a user to register event handlers for specific Project Server server-side events. The Manager Server Events page requires the event handler to be registered by the server as defined in the Project Server SDK.

X

Manage Server Configuration

Allows a user to access the Project Web App Permissions page in Project Web App. Users with permission to access the Project Web App Permissions page can enable or disable enterprise features, manage organizational permissions, and create custom menus (both top-level and side-pane) in Project Web App. Grant this permission to Project Server administrators or a very small and closely managed group of people.

Manage SharePoint Foundation

Allows a user to create and delete project sites, whether or not sites are created on project publish, permission synchronization settings, and site path updates. Grant this permission to members of your organization who are administrators for Project Web App or administrators for the servers that are running SharePoint Server 2010.

Users with this permission should be granted administrative privileges to all of the servers that are running Project Server 2010 and SharePoint Server 2010

Manage Windows SharePoint Services

X

Manage Site Services

Allows users or groups the ability to manage Queue Settings, Active Directory Synchronization, and Event handlers.

X

Manage Time Reporting and Financial Periods

Allows a user to create and modify Timesheet and Fiscal period definitions.

Manage Timesheet and Financial Periods

X

Manage Time Tracking

Allows a user to be forwarded timesheets for review. After reviewing the timesheet, the user will be required the following permissions:

  • Accept Timesheet

  • Approve Timesheet

Manage Users and Groups

Allows a user to access the Manage Users and Groups page in the Server Settings page in Project Web App. Users with this permission will be able to add, modify, or delete Project Server users and manage Project Server security groups. Grant this permission to members of your organization who are Project Server administrators. Only a small group of people should have permission to access this set of pages.

Manage Workflow and Project Detail Pages

Allows a user to manage and view workflow and Project Detail Pages (PDPs).

X

New Project

Allows a user to add a new project to Project Server using Microsoft Project Professional, Project Web App, or the Project Server Interface (PSI). New functionality in Project Server 2010 for this permission: If you do not also have the Open Project permission, after you create a project, you are taken back to the Project Center.

New Resource

Allows a project manager to add new resources to the Enterprise Resource Pool using Microsoft Project Professional, the Project Web App Resource Center, or the Project Server Interface (PSI). Grant this permission to any member of your organization who has to create new enterprise resources in Project Server.

Note:

If your organization is using the Active Directory synchronization feature, you may want to consider denying this permission to all non-IT administrators in your organization.

New Task Assignment

Allows users to access the Create a New Task and Add Yourself to a Task links from the Insert Row button found on the Tasks page of Project Web App. Grant this permission to any member of your organization who has to create new assignments on existing tasks in projects that have been published to Project Server. Users with this permission will also be able to use the Create a New Task link to create new tasks in Project Web App for any project to which the user has access. The list of available projects for a user to create new tasks is determined by the Create New Tasks or Assignment category permission. A user who has the New Task Assignment permission must also have access to the projects to which they want to assign themselves to a task.

Open Project Template

Allows a user to open an Enterprise Project Template from Project Server using Microsoft Project Professional. Grant this permission to all users in your organization who will be using Microsoft Project Professional to create and manage projects that are based on Enterprise Project Templates.

User must be granted the New Project global permission in order to save the project to the Project Server database as an actual project.

Reassign Task

Allows a user to delegate an assigned task to another (existing) user. Grant this permission to members of your organization who need the ability to delegate task assignments to other resources. For example, a large project may be run by a single project manager, but actually implemented by several teams, each with their own team lead. A project manager could assign the team leads in the project plan, and then the team leads could in turn delegate each task to individual members of their teams. This example creates an additional layer of task management within the larger organization, but it can also simplify resource allocation within projects themselves and make it easier for a project manager to manage large projects. Or, if you have a resource that is about to leave on a three-week vacation, and this resource had this permission, they would be able to assign their tasks directly to other resources instead of having the project manager check out the project and reassign resources.

Save Enterprise Global

Allows a user to check out, modify, and save the Enterprise Global Template to the Project Server database from Microsoft Project Professional. This permission should only be granted to a small group of people in your organization; either project managers, members of your organization's PMO, or Project Server administrators.

Save Project Template

Allows a user to create and save a project as an Enterprise Project Template from Microsoft Project Professional to the Project Server database. Grant this permission to members of your organization who are tasked with creating Enterprise Project Templates. When a user saves a project to Project Server for the first time, the option to select Template (as opposed to Project) from the Type drop-down list in the Save to Project Server dialog box is enabled.

User needs to be granted the Assign Resources and View Enterprise Resource Data category permissions in addition to this permission if they are also responsible for adding Generic resources to the Enterprise Project Template.

Save Unprotected Baseline

Allows a user to save a non-protected baseline or clear a non-protected baseline associated with an enterprise project published to the Project Server database. Baselines are saved by using the Set Baseline functionality accessed from the Microsoft Project Professional ribbon on the Project tab in the Schedule group. Click the Set Baseline button and then select Save Baseline or Clear Baseline. Unprotected Baselines are in the range of Baseline 6-10 inclusive.

User needs to be granted the Save Project category permission.

Self-Assign Team Tasks

Resources can be members of a Team Assignment Pool. With this permission, it is possible for users to assign tasks, which have been assigned to their Team Assignment Pool, to themselves through the Team Tasks page in Project Web App.

Status Broker Permission

Allows API updates to occur for a user from places like Microsoft Exchange Server.

X

View Approvals

Allows a user to view the Approval Center.

Users have access to the Approval Center if they have either the Accept Timesheets or the View Approvals permission.

View Business Intelligence Link

Allows a user to see the Business Intelligence link in Quick Launch. However, it has no impact on Report Center Security.

X

View OLAP Data

Allows a user to read from the output for the OLAP cube. This permission is only checked when the OLAP cube is built.

View Project Center

Allows users to access the Project Center from Project Web App or Microsoft Project Professional.

User needs to be granted the View Project Summary in Project Center category permission.

View Project View

Allows a user to access project views in Project Web App. Grant this permission to users who need to drill down into project details using the Project Center in Project Web App or Microsoft Project Professional.

View Project Schedule Views

Allows a user to see the link in the Quick Launch. However, it has no impact on Report Center Security.

X

View Project Timesheet Line Approvals

Allows a user to approve timesheets on a line-by-line basis.

X

View Resource Availability

Allows a user to access the View Resource Availability page to view resource allocation data in Project Web App. Grant this permission to users in your organization who need to view resource availability in Project Web App.

View Resource Center

Allows users to access the Resource Center from Project Web App or Microsoft Project Professional and view resource allocation data. Grant this permission to users who need to view the Resource Center in Project Web App by clicking the Resources link in the top-level navigation, or in Microsoft Project Professional by selecting Resource Center on the Collaborate menu.

User needs to be granted the View Enterprise Resource Data category permission.

View Resource Plan

Allows a user to access the Resource Plan page within Project Web App.

X

View Resource Timesheet

Allows users to view the timesheets, regardless of their state or ownership, for resources identified in the category selection criteria.

Users must be granted the Accept Timesheet global permission to use this permission.

View Task Center

This permission when denied prevents users from seeing the Task Center link on the Project Web App Quick Launch menu

Note:

This permission does not lock down access to the Task Center page. It is still possible for users to navigate to this page

View Team Builder

Allows a user to use Build Team in Project Web App and Microsoft Project Professional, as well as determine the list of available resources. Grant this permission to resource managers to allow them to use Build Team in Project Web App to add resources to projects that have been saved to the Project Server database. Project Managers can also use this permission to allow them to use Build Team in Microsoft Project Professional to add resources to projects.

  • User needs to be granted the Assign Resources category permission in addition to the View Team Builder global permission. The Assign Resources category permission determines the list of resources available in Build Team in both Microsoft Project Professional and Project Web App.

  • User needs to be granted the Build Team on Project category permission. The Build Team on Project permission determines with which projects Build Team can be used. This applies to using Build Team in both Microsoft Project Professional and Project Web App.

View Timesheets

When this permission is denied it prevents users from seeing the Timesheet Center link on the Project Web App Quick Launch menu

Note:

This permission does not lock down access to the Timesheet page. It is still possible for users to navigate to this page.

View Timesheet Center

X

See Also

Concepts

Project Server 2010 category permissions
Manage categories in Project Server 2010


Project Server 2010 category permissions
See Also

Published: May 29, 2010

The following is a list of category permissions for Microsoft Project Server 2010. The table includes columns with the following information:

  • Description Describes what the permission lets you do.

  • Dependencies Lists any other permissions (global or category) or requirements to allow the permission to function.

  • Previous name, if renamed from Office Project Server 2007 Specifies the Microsoft Office Project Server 2007 permission name if the permission was renamed from Office Project Server 2007 but provides the same functionality.

  • New for Project Server 2010 Displays an X symbol if the permission is new for Project Server 2010.

Permission Description Dependencies Previous name, if renamed from Office Project Server 2007 New for Project Server 2010

Accept Task Update Requests

Allows a user to accept updates on projects without requiring that the user have the Save Project to Project Server permission

Adjust Timesheet

Allows a Project Web App user to adjust a team member's submitted timesheet entries. Grant this permission to any member of your organization who requires the ability to adjust a resource's timesheet entry after that resource has submitted the entry.

User must have the View Resource Timesheet permission to use this permission.

Approve Timesheets

Allows a user to approve a team member's submitted timesheet entries. Grant this permission to any member of your organization who requires the ability to approve a resource's timesheet.

  • User must have the Approve Timesheets permission through a category which contains the resources which they want to approve timesheets on.

Assign Resources

Allows a user to assign or allocate a given resource to projects. This permission controls the list of available resources in Team Builder in both Project Web App and Project Professional. Grant this permission to all project managers and resource managers who have to assign, manage, or allocate resources. For example, if you want to add resource R to project P, then you must have permission to assign resource R (Assign Resources) plus permission to build the team on Project P (Build Team on Project). In addition, you must have access to the Team Builder page through either Project Web App or Project Professional (Assign Resources to Project Team).

  • User must have the View Team Builder global permission in order to use the Build Team page in Project Web App or Project Professional.

  • User must have the Build Team on Project category permission in order to assign a resource in an existing enterprise project.

  • User must have the Build Team on New Project global permission in order to assign a resource in a new enterprise project.

Build Team On Project

Allows a user to add resources to a project that has already been saved to the Project Server database. Grant this permission to project managers who want to use the Build Team feature in Project Professional to staff their projects before they save (and publish) them to the Project Server database. Or, grant this permission to resource managers who want to use the Build Team feature in the Project Center of Project Web App to add resources to a project that has already been saved to the Project Server database.

  • User must have the View Enterprise Resource Data and Assign Resources category permissions in order to see resources that are part of the Enterprise Resource Pool in the Build Team feature in Project Professional and Project Web App.

  • User must have permission (at the category level) to access the specific projects and resources that have to be accessed to build the project team or assign resources.

Create New Task or Assignment

Determines which projects are available when you are creating new tasks. Grant this permission to any group of projects that individual users will be able to create new tasks in by using the Create a new task page in Project Web App.

User must be granted the New Task Assignment global permission in order to access the New task page in Project Web App.

Create Object Links

When allowed, this permission enables a user to create, modify, or delete links between Project Tasks and items in the Project Workspace (documents, issues, deliverables or risks).

Delete Project

Allows users of Project Professional to delete a project saved to the Project Server database from the Open from Microsoft Project Server dialog box in Project Professional. Grant this permission to members of your organization to enable them to more closely manage the projects he or she has saved to the Project Server database from Project Professional or by using the "Delete Enterprise Objects" link in Project Web App. Before letting users delete projects, you should consider how your organization will recover those projects, if you have to do so.

Edit Enterprise Resource Data

Allows a project manager to edit enterprise resource data by using Project Professional (checked-out Enterprise Resource Pool) or a resource manager to edit enterprise resources using Project Web App (Resource Center). Grant this permission to project managers and resource managers who have to make updates to resources that belong to the Enterprise Resource Pool. Resource managers with this permission are able to edit enterprise resource data in the Resource Center in Project Web App, and they can make updates to cost data, custom outline code data, custom field data, and other static information related to resources. Resource managers cannot add or delete resources from the Enterprise Resource Pool in Project Web App. Project managers can add or delete resources from the Enterprise Resource Pool in Project Professional if they have the New Resource global permission (to add resources) or the Clean Up Project Server Database global permission (to delete resources). These permissions are required in addition to the Edit Enterprise Resource Data category permission.

Note:

The Project Server Interface (PSI) can also be used to create or delete resources in the Enterprise Resource Pool and to edit enterprise resource data.

User must be granted the View Enterprise Resource Data category permission.

Edit Project Summary Fields

Allows a user to edit only the enterprise project fields shown in the new project fields Web Part. If you do not have this permission, but have "Save Project to Project Server" you can still edit project-level fields/custom fields in the project field Web Part.

Edit Project Properties in Project Center

X

Manage Basic Project Security

Controls whether a specific Project Permission can be set on a single project through the new Project Permissions feature.

X

Manage Resource Delegates

Allows a user to see other users whom he or she manages and to set delegates for them.

X

Manage Resource Plan

Allows a user to edit a resource plan.

Open Project

Allows a user to open a project from the Project Server database in read-only mode using Project Professional. Grant this permission to any member of your organization who has to use the Open from Microsoft Project Server dialog box in Project Professional or in the Project Center in Project Web App to open projects that have been saved to the Project Server database. If users are not assigned the Save Project to Project Server permission, then the project will only be open in read-only mode.

Publish Project

Allows a user to Publish projects to the Project Server Published database using Project Professional and Project Web App. Grant this permission to all members of your organization who will be publishing projects.

User must be granted the Open Project category permission on any project that has to be checked out from the Project Server database. If the project has changed since opening, the user will be required to have the Save Project to Project Server permission on that project. If not, when a publish occurs, it will only publish the outdated version.

Save Project to Project Server

Allows a user to save projects to the Project Server database using Project Professional. Also gives Project Web App users the permission to save schedules and strategic impact data. Grant this permission to all members of your organization who will be saving projects from Project Professional to the Project Server database using the Save to Project Server dialog box or through Server-side projects.

  • User must be granted the New Project permission in order to create the project.

  • User must be granted the Open Project category permission on any project that has to be checked out from the Project Server database.

Save Protected Baseline

Allows a user to save a protected baseline or clear a protected baseline associated with an enterprise project published to the Project Server database. Grant this permission to project managers who have to save baselines in their projects. Baselines are saved by using the Set Baseline functionality accessed from the Project Professional ribbon on the Project tab in the Schedule group. Click the Set Baseline button and then select Save Baseline or Clear Baseline. Protected Baselines are in the range of Baseline 0-5 inclusive. Only users who have Save Unprotected Baseline, Open Project and Save Project Category permissions are able to save Baselines in Baseline 6-10.

User must be granted the Save Project to Project Server category permission.

View Project Summary in Project Center

Allows a user to access a specific project in the Project Center from Project Web App. Grant this permission to any member of your organization who has to view projects summaries in the Project Center.

Users also must be granted the View Project Center View permission in order to see the Project Center.

View Project Schedule in Project Web App

Allows a user to view project information for a specific project from the Project Center in Project Web App. Grant this permission to users who have to view project details in the Project Center.

View Project Details in Project Center

X

View Resource Assignments in Assignment Views

Allows a user to view assignment details using assignment views in the Resource Center. Grant this permission to project managers and resource managers who have to view resource assignment details in the Resource Center from Project Professional or Project Web App.

View Enterprise Resource Data

Allows a user to view resources and resource data that is stored in the Enterprise Resource Pool. Grant this permission to any user who has to view resources and resource data that is stored in the Enterprise Resource Pool.

View Project Site

Allows users to view Risks, Issues, and Documents areas in Project Web App and Project Professional. Grant this permission to any user of Project Professional who has to select Project site, Documents, Issues, or Risks from the Info page in the Backstage or any user of Project Web App who has to access the Project site, Documents, Issues, or Risks top-level navigation links.

View Project Workspace

X

See Also

Concepts

Project Server 2010 global permissions


Microsoft Project Server 2010 default categories
See Also

Published: June 24, 2010

Microsoft Project Server 2010 creates seven default categories during installation. Each of the categories is configured to be accessed by specified default user groups. Each category has a predefined set of category permissions for default user groups that have access to that category. The following sections list the default settings for each category for Project Server 2010.

In this article:

  • Categories

  • Category permissions

Categories

Specific default groups are already associated with each of the default categories, The following table shows the default categories and the default groups that can access each of them.

Note:

For more information about the relationship between groups and categories, see Plan groups, categories, and RBS in Project Server 2010.

Category Name | Administrators | Executives | Portfolio Managers | Project Managers | Resource Managers | Team Leads | Team Members
My Direct Reports |  |  |  |  | X |  |
My Organization | X | X | X | X | X |  |
My Projects |  |  |  | X | X | X |
My Resources |  |  |  |  | X |  |
My Tasks |  |  |  |  |  |  | X

Category permissions

The following table describes the default category permissions for each default group. For example, a user in the default Administrators group (who is associated to the My Organization category by default) has the permissions allowed in the Administrators column in the table. These category permissions only apply to all projects, resources, and views selected for the My Organization category. However, a user in the default Project Managers group (who is associated to the My Organization and My Projects categories) has a different set of category permissions for the objects in the My Organization category. This allows you to conveniently set a more or less restrictive set of permissions for different types of users to a group of projects, resources, and views.

Note:

For more information about category permissions, see Project Server 2010 category permissions. For more information about how categories relate to groups, see Plan groups, categories, and RBS in Project Server 2010.

Use the following legend for the table below.

  • My Org = My Organization

  • My Dir = My Direct Reports

  • My Proj = My Projects

  • My Res = My Resources

  • My Tsks = My Tasks

Permission Name | Administrators | Executives | Portfolio Managers | Project Managers | Resource Managers | Team Leads | Team Members
Accept Task Update Requests | My Org |  |  | My Proj |  |  |
Adjust Timesheet | My Org |  |  |  |  |  |
Approve Timesheets | My Org |  | My Org |  | My Dir, My Res |  |
Assign Resource | My Org |  | My Org | My Org | My Res |  |
Build Team On Project | My Org |  | My Org | My Proj | My Org |  |
Create New Task or Assignment | My Org |  |  | My Proj | My Proj | My Proj | My Tsks
Create Object Links | My Org | My Org | My Org | My Proj | My Org, My Proj, My Res | My Proj | My Tsks
Delete Project | My Org |  | My Org | My Proj |  |  |
Edit Enterprise Resource Data | My Org |  | My Org |  | My Res |  |
Edit Project Summary Fields | My Org |  |  | My Proj |  |  |
Manage Basic Project Security | My Org |  | My Org | My Proj |  |  |
Manage Resource Delegates | My Org |  |  |  | My Res |  |
Manage Resource Plan | My Org |  | My Org | My Org | My Res |  |
Open Project | My Org |  | My Org | My Proj |  |  | My Tsks
Publish Project | My Org |  | My Org | My Proj |  |  |
Save Project to Project Server | My Org |  | My Org | My Proj |  |  |
Save Protected Baseline | My Org |  |  | My Proj |  |  |
View Enterprise Resource Data | My Org | My Org | My Org | My Org, My Proj | My Res |  |
View Project Schedule in Project Web App | My Or | My Org | My Org | My Proj |  | My Proj | My Tsks
View Project Site | My Org | My Org | My Org | My Proj | My Proj | My Proj | My Tsks
View Project Summary in Project Center | My Org | My Org | My Org | My Proj | My Proj | My Proj | My Tsks
View Resource Assignments in Assignment Views | My Org | My Org | My Org | My Proj | My Res | My Proj | My Tsks

See Also

Concepts

Project Server 2010 global permissions
Project Server 2010 category permissions
Project Server 2010 default group permissions
Plan groups, categories, and RBS in Project Server 2010


Project Server 2010 default group permissions
See Also

Published: June 24, 2010

In this article:

  • Default global permissions

  • Default category permissions

This article describes the default permissions that are given to the default templates and user groups in Microsoft Project Server 2010.

Project Server 2010 creates seven default groups during installation:

  • Administrators

  • Executives

  • Portfolio Managers

  • Project Managers

  • Resource Managers

  • Team Leads

  • Team Members

Each group is given a default set of permissions (global and category). Templates are also included to allow these default permissions to be assigned to new groups created by the administrator. After using the template to create a new group, you can then choose to customize the new group to better suit your users by editing the permission for the group.

Global permissions differ from category permissions in that they apply to functionality that the user is allowed to use in Project Server 2010. Category permissions apply to what users are allowed to do with specific projects, resources, and views as defined by the category that the group is associated with. For more information about groups and categories, see Plan groups, categories, and RBS in Project Server 2010.

Default global permissions

The following table contains a list of the default global permissions for each of the default user groups.

Permission Name | Administrators | Executives | Portfolio Managers | Project Managers | Resource Managers | Team Leads | Team Members
About Microsoft Project Server | X |  |  |  |  |  |
Accept Timesheets | X |  | X |  | X |  |
Build Team On New Project | X |  | X | X | X |  |
Can Be Delegate | X |  |  |  |  |  |
Change Password | X | X | X | X | X | X | X
Change Workflow | X |  |  |  |  |  |
Clean Up Project Server Database | X |  |  |  |  |  |
Close Tasks To Updates | X | X |  | X |  |  |
Contribute to Project Web App | X |  |  |  | X | X | X
Edit Status Report Requests | X | X | X | X | X | X |
Edit Status Report Responses | X | X | X | X | X | X | X
Log On | X | X | X | X | X | X | X
Log on to Project Server from Project Professional | X |  | X | X | X |  |
Manage Active Directory Settings | X |  |  |  |  |  |
Manage Check-Ins | X |  | X |  |  |  |
Manage Cube Building Service | X |  | X |  |  |  |
Manage Drivers | X | X | X |  |  |  |
Manage Enterprise Calendars | X |  | X |  |  |  |
Manage Enterprise Custom Fields | X |  | X |  |  |  |
Manage Exchange Integration | X |  |  |  |  |  |
Manage Gantt Chart and Grouping Formats | X |  |  |  |  |  |
Manage Lists in Project Web App | X | X | X | X |  |  |
Manage My Delegates | X |  |  |  | X |  |
Manage My Resource Delegates | X |  |  |  | X |  |
Manage Notification and Reminders | X |  |  |  | X |  |
Manage Personal Notifications | X | X | X | X | X | X | X
Manage Portfolio Analyses | X | X | X |  |  |  |
Manage Prioritizations | X | X | X |  |  |  |
Manage Project Server Backup | X |  |  |  |  |  |
Manage Project Server Restore | X |  |  |  |  |  |
Manage Project Web App Views | X |  | X |  |  |  |
Manage Queue | X |  | X |  |  |  |
Manage Resource Notifications | X |  | X | X |  | X |
Manage Rules | X |  |  | X |  |  |
Manage Security | X |  |  |  |  |  |
Manage Server Configuration | X |  |  |  |  |  |
Manage Server Events | X |  |  |  |  |  |
Manage SharePoint Foundation | X |  |  |  |  |  |
Manage Site Services | X |  |  |  |  |  |
Manage Time Reporting and Financial Periods | X |  |  |  |  |  |
Manage Time Tracking | X |  |  |  |  |  |
Manage Users and Groups | X |  |  |  |  |  |
Manage Workflow Project Detail Pages | X |  |  |  |  |  |
New Project | X | X | X | X | X | X | X
New Resource | X |  | X |  | X |  |
New Task Assignment | X |  |  | X |  | X | X
Open Project Template | X |  | X | X |  |  |
Reassign Task | X |  |  | X |  |  | X
Save Enterprise Global | X |  | X |  |  |  |
Save Project Template | X |  | X | X |  |  |
Save Unprotected Baseline | X |  | X | X |  |  |
Self-assign Team Tasks | X |  |  | X | X | X | X
Status Broker Permission | X |  |  |  |  |  |
View Approvals | X |  |  | X | X | X |
View Business Intelligence Link | X | X | X | X |  |  |
View OLAP Data | X | X | X | X |  |  |
View Project Center | X | X | X | X | X | X | X
View Project Schedule Views | X | X | X | X | X | X | X
View Project Timesheet Line Approvals | X | X | X | X |  |  |
View Resource Availability | X | X | X | X | X |  |
View Resource Center | X | X | X | X | X |  |
View Resource Plan | X | X | X | X | X |  |
View Resource Timesheet | X |  |  |  |  |  |
View Task Center | X | X | X | X | X | X | X
View Team Builder | X |  | X | X | X |  |
View Timesheets | X | X | X | X | X | X | X

Default category permissions

The following table contains a list of the default category permissions for each of the default user groups.

Use the following legend for the table below.

  • My Org = My Organization

  • My Dir = My Direct Reports

  • My Proj = My Projects

  • My Res = My Resources

  • My Tsks = My Tasks

For example, a user in the default Administrators group (who is associated to the My Organization category by default) has permissions allowed in the Administrators column in the table. These category permissions only apply to all projects, resources, and views selected for the My Organization category. However, a user in the default Project Managers group (who is associated to the My Organization and My Projects categories) has a different set of category permissions for the objects in the My Organization category. This allows you to conveniently set a more or less restrictive set of permissions for different types of users to a group of projects, resources, and views.

For more information about groups and categories, see Plan groups, categories, and RBS in Project Server 2010.

Permission Name | Administrators | Executives | Portfolio Managers | Project Managers | Resource Managers | Team Leads | Team Members
Accept Task Update Requests | My Org |  |  | My Proj |  |  |
Adjust Timesheet | My Org |  |  |  |  |  |
Approve Timesheets | My Org |  | My Org |  | My Dir, My Res |  |
Assign Resource | My Org |  | My Org | My Org | My Res |  |
Build Team On Project | My Org |  | My Org | My Proj | My Org |  |
Create New Task or Assignment | My Org |  |  | My Proj | My Proj | My Proj | My Tsks
Create Object Links | My Org | My Org | My Org | My Proj | My Org, My Proj, My Res | My Proj | My Tsks
Delete Project | My Org |  | My Org | My Proj |  |  |
Edit Enterprise Resource Data | My Org |  | My Org |  | My Res |  |
Edit Project Summary Fields | My Org |  |  | My Proj |  |  |
Manage Basic Project Security | My Org |  | My Org | My Proj |  |  |
Manage Resource Delegates | My Org |  |  |  | My Res |  |
Manage Resource Plan | My Org |  | My Org | My Org | My Res |  |
Open Project | My Org |  | My Org | My Proj |  |  | My Tsks
Publish Project | My Org |  | My Org | My Proj |  |  |
Save Project to Project Server | My Org |  | My Org | My Proj |  |  |
Save Protected Baseline | My Org |  |  | My Proj |  |  |
View Enterprise Resource Data | My Org | My Org | My Org | My Org, My Proj | My Res |  |
View Project Schedule in Project Web App | My Or | My Org | My Org | My Proj |  | My Proj | My Tsks
View Project Site | My Org | My Org | My Org | My Proj | My Proj | My Proj | My Tsks
View Project Summary in Project Center | My Org | My Org | My Org | My Proj | My Proj | My Proj | My Tsks
View Resource Assignments in Assignment Views | My Org | My Org | My Org | My Proj | My Res | My Proj | My Tsks

See Also

Concepts

Project Server 2010 global permissions
Project Server 2010 category permissions
Project Server 2010 default group permissions
Plan groups, categories, and RBS in Project Server 2010
Microsoft Project Server 2010 default categories


General reference for Project Web App (Project Server 2010)

Published: January 27, 2011

The following reference materials may provide helpful information as you work in Microsoft Project Web App:

  • Keyboard shortcuts for Microsoft Project Web App (Project Server 2010)


Keyboard shortcuts for Microsoft Project Web App (Project Server 2010)

Published: January 27, 2011

For keyboard shortcuts in which you press two or more keys at the same time, the keys to press are separated by a plus sign (+) in this Microsoft Project Web App article. For keyboard shortcuts in which you press one key immediately followed by another key, the keys to press are separated by a comma (,).

Note:

To print this article, press Ctrl+P.

In this article:

  • Shortcuts in Online Help

  • Moving through Project Web App

  • Using grid controls

Shortcuts in Online Help

The Help window provides access to all Office Help content. The Help window displays topics and other Help content.

To do this Press

Open the Help window.

F1

Close the Help window.

Alt+F4

Switch between the Help window and the active program.

Alt+Tab

Go back to [Program Name] Home.

Alt+Home

Select the next item in the Help window.

Tab

Select the previous item in the Help window.

Shift+Tab

Perform the action for the selected item.

Enter

In the Browse [Program Name] Help section of the Help window, select the next or previous item.

Tab or Shift+Tab

In the Browse [Program Name] Help section of the Help window, expand or collapse the selected item.

Enter

Select the next hidden text or hyperlink, including Show All or Hide All at the top of a topic.

Tab

Select the previous hidden text or hyperlink.

Shift+Tab

Perform the action for the selected Show All, Hide All, hidden text, or hyperlink.

Enter

Move back to the previous Help topic (Back button).

Alt+Left Arrow or Backspace

Move forward to the next Help topic (Forward button).

Alt+Right Arrow

Scroll small amounts up or down within the currently displayed Help topic.

Up Arrow or Down Arrow

Scroll larger amounts up or down within the currently displayed Help topic.

Page Up or Page Down

Change whether the Help window appears connected to (tiled) or separate from (untiled) the active program.

Alt+U

Display a menu of commands for the Help window. This requires that the Help window have the active focus (click in the Help window).

Shift+F10

Stop the last action (Stop button).

Esc

Refresh the window (Refresh button).

F5

Print the current Help topic.

Note:

If the cursor is not in the current Help topic, press F6 and then press Ctrl+P.

Ctrl+P

Change the connection state.

F6, and then click Down Arrow

Type text in the Type words to search for box.

F6, and then click Down Arrow

Switch among areas in the Help window; for example, switch between the toolbar, Type words to search for box, and Search list.

F6

In a Table of Contents in tree view, select the next or previous item.

Down Arrow or Up Arrow

In a Table of Contents in tree view, expand or collapse the selected item.

Left Arrow or Right Arrow

Moving through Project Web App

The following table lists keyboard shortcuts for moving in Project Web App.

To do this | Press
Move the selection between the links on the top link bar. | Alt+J
Move the selection from Web Part to Web Part on pages that use multiple Web Parts. | Alt+W
Expand drop-down lists. | Alt+Down Arrow

Using grid controls

Project Web App, the Web client of Microsoft Project Server 2010, uses AJAX and HTML grid controls to display various pieces of information.

Some of the pages in Project Web App use an HTML table-based grid for viewing and editing information. For example, the Tasks page uses an HTML table-based grid. In HTML grids, you can use the following keyboard shortcuts:

To do this | Press
Move to the next cell or row. | Right Arrow or Tab
Move to the previous cell or row. | Left Arrow or Shift Tab
Move up. | Up Arrow
Move down. | Down Arrow or Enter
Go to the URL in the selected cell. | Enter
Remove focus from selected cell. | Esc
Move to last cell or row. | Ctrl+End
Move to first cell or row. | Ctrl+Home
Toggle row highlight. | Ctrl+Spacebar
Expand or collapse a grouping. | Ctrl+ Spacebar
Expand a group. | Ctrl+Plus Sign
Collapse a group. | Ctrl+Minus Sign
Toggle a check box. | Spacebar
Open a drop-down cell. | Alt+Down Arrow

Project Web App also uses AJAX grid controls for viewing and editing information. For example, the Project Details page uses an AJAX grid. In AJAX grids, you can use the following keyboard shortcuts:

To do this | Press
Activate Edit Mode for a cell. | F2
Up one page. | Page Up
Down one page. | Page Down
Indent selected task. | Alt+Shift+Right Arrow
Outdent selected task. | Alt+Shift+Left Arrow
Cancel entry or edit. | Esc
Copy selection. | Ctrl+C
Cut selection. | Ctrl+X
Delete the selected data. | Delete or Ctrl+V or Ctrl+Z
Delete a row | Ctrl+Delete
Move to the first field in a row. | HOME
Move to the first row. | Ctrl+Up Arrow
Move to the last field in a row. | End
Move to the last field of the last row. | Ctrl+End
Move to the last row. | Ctrl+Down Arrow
Extend the selection down one page. | Shift+Page Down
Extend the selection up one page. | Shift+Page Up
Extend the selection down one row. | Shift+Down Arrow
Extend the selection up one row. | Shift+Up Arrow
Extend the selection to the first field in a row. | Shift+Home
Extend the selection to the last field in a row. | Shift+End
Extend the selection to the first field of the first row. | Ctrl+Shift+Home
Extend the selection to the last field of the last row. | Ctrl+Shift+End
Move down a row. | Enter
Move right one cell. | Right Arrow
Move left one cell. | Left Arrow
Move up one cell. | Up Arrow
Move down one cell. | Down Arrow
Toggle a check box. | Spacebar


System Center Operations Manager knowledge articles (Project Server)

Published: May 12, 2010

Applies to: Project Server 2010 | Project Server 2013

The articles in this section are knowledge articles for the Microsoft Project Server 2010 management pack (MP) for Microsoft System Center Operations Manager (SCOM) 2007. Typically, you would see these articles after clicking a link in an alert in the Operations Manager console. You can use these articles to help you troubleshoot and resolve problems in Project Server 2010.

In this section:

  • Project Active Directory connection failed

  • Project Active Directory exception occurred during synchronization

  • Project Active Directory nested foreign security principal could not be resolved

  • Project Active Directory nested object could not be resolved

  • Project Active Directory PWA group could not be resolved

  • Project Active Directory top-level group has no members

  • Project Creating Report Center Web failed

  • Project Cube Build Service Analysis Services server connection failure

  • Project Cube Build Service Analysis Services server lock time out

  • Project Cube Build Service attempt to overwrite failed

  • Project Cube Build Service Decision Support Object is not installed

  • Project notification XSLT transformation error

  • Project Failure creating a Project workspace

  • Project General Data Access Layer error connecting to database

  • Project General Data Access Layer error while getting connection strings

  • Project notification e-mail delivery failed

  • Project notification XSLT transformation error

  • Project Queue general percentage SQL retries per day

  • Project Queue general percentage SQL retries per hour

  • Project Queue jobs average wait time per day

  • Project queue jobs percentage jobs failed per day

  • Project queue jobs percentage failed per hour

  • Project Queue System restarting due to unexpected error

  • Project Reporting server side event has failed

  • Project Server event handler could not be found

  • Project Server event service could not be found

  • Project SQL user view refresh message was not queued

  • Project user view was truncated

  • Project Windows SharePoint Services format error

  • Project Winproj average time taken for project open

  • Project Winproj average percentage of incremental save to full save

  • Project workspace user synchronization failed


Project Active Directory connection failed
See Also

Published: May 12, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule name: Project_Active_Directory_Connection_Failed

Summary: This monitor indicates that Microsoft Project Web App could not access the Active Directory directory service.When an administrator browses to the "Active Directory Enterprise Resource Pool Synchronization" or "Add or Edit Group" page by using Project Web App, Project Web App checks the current availability of the Active Directory forests. This check determines whether the Find Group button on those pages is enabled. If the Find Group button is available, administrators can use it to choose which Active Directory group to use for synchronization.

Cause: One or more of the following situations might be the cause:

  • The Microsoft Project Server application server is using a SharePoint Service Account (SA) account that does not have read access to Active Directory.

  • The Project Server application server may no longer be joined to an Active Directory domain.

  • The Project Server application server does not currently have network access to the domain.

  • Ports required for Project Server and Active Directory to communicate are not open between the Project Server application server and the Active Directory store. This can occur if a firewall is configured to block a port described in the following list:

    • 389/UDP - LDAP: LDAP is the Lightweight Directory Access Protocol that is designed to provide a standard way to access directory services. LDAP is the primary protocol used to access an Active Directory store.

    • 636/TCP - LDAP over SSL: When Secure Sockets Layer (SSL) is enabled, the LDAP data that is transmitted and received is encrypted.

    • 3268/TCP - Microsoft Global Catalog: Active Directory global catalogs listen on this port.

    • 3269/TCP - Microsoft Global Catalog with LDAP/SSL: Microsoft global catalog SSL connections listen on this port.

Possible resolutions include:

  • Verify that the service account used by the SA used by the Project Server application server is a domain account that has read access to Active Directory.

  • Verify that the Project Server application server is joined to an Active Directory domain.

  • Verify that the Project Server application server has network access.

  • Verify that the ports listed in the previous section are open between the Active Directory store and the Project Server application server.

See Also

Other Resources

Project Active Directory connection failed
Project Active Directory exception occurred during synchronization
Project Active Directory nested foreign security principal could not be resolved
Project Active Directory nested object could not be resolved
Project Active Directory PWA group could not be resolved
Project Active Directory top-level group has no members
Project Creating Report Center Web failed
Project Cube Build Service Analysis Services server connection failure
Project Cube Build Service Analysis Services server lock time out
Project Cube Build Service attempt to overwrite failed
Project Cube Build Service Decision Support Object is not installed
Project notification XSLT transformation error
Project Failure creating a Project workspace
Project General Data Access Layer error connecting to database
Project General Data Access Layer error while getting connection strings
Project notification e-mail delivery failed
Project notification XSLT transformation error
Project Queue general percentage SQL retries per day
Project Queue general percentage SQL retries per hour
Project Queue jobs average wait time per day
Project queue jobs percentage jobs failed per day
Project queue jobs percentage failed per hour
Project Queue System restarting due to unexpected error
Project Reporting server side event has failed
Project Server event handler could not be found
Project Server event service could not be found
Project SQL user view refresh message was not queued
Project user view was truncated
Project Windows SharePoint Services format error
Project Winproj average time taken for project open
Project Winproj average percentage of incremental save to full save
Project workspace user synchronization failed


Project Active Directory exception occurred during synchronization
See Also

Published: May 12, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Active_Directory_Exception_Occurred_During_Synchronization

Summary: During a synchronization process, Microsoft Project Server attempts to obtain a reference to an Active Directory group that is mapped to either the Enterprise Resource Pool or a Project Server security group by using the GUID of the Active Directory group in an LDAP query. If the LDAP query fails, an Active Directory synchronization exception is recorded in the Windows Server event log. When this exception occurs, it typically means that the Active Directory synchronization process failed either partly or completely.

Cause: The Project Server application server cannot access the Active Directory directory service for any of the following reasons:

  • The Project Server application server is using a SharePoint Service Account (SA) account that does not have read access to Active Directory.

  • The Project Server application server may no longer be joined to an Active Directory domain.

  • The Project Server application server does not currently have network access to the domain.

  • Ports required for Project Server and Active Directory to communicate are not open between the Project Server application server and the Active Directory store. This can occur if a firewall is configured to block the ports described in the following list:

    • 389/UDP - LDAP: LDAP is the Lightweight Directory Access Protocol that provides a standard way to access directory services. LDAP is the primary protocol that is used to access an Active Directory store.

    • 636/TCP - LDAP over SSL: When Secure Sockets Layer (SSL) is enabled, the LDAP data that is transmitted and received is encrypted.

    • 3268/TCP - Microsoft global catalog: Active Directory global catalogs listen on this port.

    • 3269/TCP - Microsoft global catalog with LDAP/SSL: Microsoft global catalog SSL connections listen on this port.

  • The Active Directory group no longer exists in the Active Directory store. For example, the group may have been deleted by an administrator.

  • The Project Server application server's SA account does not have read access to an Active Directory group or user object.

Possible resolutions include the following:

  • Verify that the service account that is used by the SA used by the Project Server application server is a domain account that has read access to Active Directory.

  • Verify that the Project Server application server is joined to an Active Directory domain.

  • Verify that the Project Server application server has network access.

  • Verify that the ports listed in the previous section are open between the Active Directory store and the Project Server application server.

  • Verify that at least one Active Directory group exists in the Active Directory store with the same Active Directory GUID that is stored in the Project Server application server.

  • Use the ADSI Edit tool to check security permissions on individual Active Directory group and user objects. The SA account must be able to read all Active Directory group and user objects that are involved in the synchronization process.

    Note:

    The ADSI Edit tool is available for Windows Server 2008 when you install the Active Directory Domain Services (AD DS) role to make a server a domain controller. It is also available as a part of the Remote Server Administration Tools (RSAT) kit available. See Installing or Removing the Remote Server Administration Tools Pack (http://go.microsoft.com/fwlink/p/?LinkId=143345) in the TechNet Library.

See Also

Other Resources

Project Active Directory connection failed
Project Active Directory exception occurred during synchronization
Project Active Directory nested foreign security principal could not be resolved
Project Active Directory nested object could not be resolved
Project Active Directory PWA group could not be resolved
Project Active Directory top-level group has no members
Project Creating Report Center Web failed
Project Cube Build Service Analysis Services server connection failure
Project Cube Build Service Analysis Services server lock time out
Project Cube Build Service attempt to overwrite failed
Project Cube Build Service Decision Support Object is not installed
Project notification XSLT transformation error
Project Failure creating a Project workspace
Project General Data Access Layer error connecting to database
Project General Data Access Layer error while getting connection strings
Project notification e-mail delivery failed
Project notification XSLT transformation error
Project Queue general percentage SQL retries per day
Project Queue general percentage SQL retries per hour
Project Queue jobs average wait time per day
Project queue jobs percentage jobs failed per day
Project queue jobs percentage failed per hour
Project Queue System restarting due to unexpected error
Project Reporting server side event has failed
Project Server event handler could not be found
Project Server event service could not be found
Project SQL user view refresh message was not queued
Project user view was truncated
Project Windows SharePoint Services format error
Project Winproj average time taken for project open
Project Winproj average percentage of incremental save to full save
Project workspace user synchronization failed


Project Active Directory nested foreign security principal could not be resolved
See Also

Published: May 12, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Active_Directory_Nested_Foreign_Security_Principal_Could_Not_Be_Resolved

Summary: During synchronization with the Active Directory directory service, Microsoft Project Server could not resolve a nested Active Directory foreign security principal. The foreign security principal could be either a user or a group residing in a remote Active Directory forest or external domain.However, this warning message does verify that the top-level Active Directory group was resolved. This means that communication between the Project Server application server that initiated the Active Directory synchronization and the Active Directory domain or forest to which the top-level Active Directory group belongs was successfully established. However, the foreign security principal listed in the Windows Server event log cannot be resolved. Active Directory synchronization was tagged for partial failure.

Cause: Possible causes include the following:

  • The Active Directory group no longer exists in the Active Directory store. For example, the group may have been deleted by an administrator.

  • The Project Server application server's SharePoint Service Account (SA) account does not have read access to the Active Directory group or user object listed in the Windows Server event log.

  • A communication problem exists between Project Server and the Active Directory domain in which the Active Directory group or user object resides.

Possible resolutions include the following:

  • Verify that at least one Active Directory group exists in the Active Directory store with the same Active Directory GUID that is stored in the Project Server application server.

  • Use the Active Directory Service Interfaces (ADSI) Edit tool to check security permissions on individual Active Directory group and user objects. The SA account must be able to read all Active Directory group and user objects that are involved in the synchronization process.

    Note:

    The ADSI Edit tool is available for Windows Server 2008 when you install the Active Directory Domain Services (AD DS) role to make a server a domain controller. It is also available as a part of the Remote Server Administration Tools (RSAT) kit available. See Installing or Removing the Remote Server Administration Tools Pack (http://go.microsoft.com/fwlink/p/?LinkId=143345) in the TechNet Library.

  • Ensure that the local Active Directory forest or domain has access to the remote Active Directory forest or domain on which the foreign security principal resides.

See Also

Other Resources

Project Active Directory connection failed
Project Active Directory exception occurred during synchronization
Project Active Directory nested foreign security principal could not be resolved
Project Active Directory nested object could not be resolved
Project Active Directory PWA group could not be resolved
Project Active Directory top-level group has no members
Project Creating Report Center Web failed
Project Cube Build Service Analysis Services server connection failure
Project Cube Build Service Analysis Services server lock time out
Project Cube Build Service attempt to overwrite failed
Project Cube Build Service Decision Support Object is not installed
Project notification XSLT transformation error
Project Failure creating a Project workspace
Project General Data Access Layer error connecting to database
Project General Data Access Layer error while getting connection strings
Project notification e-mail delivery failed
Project notification XSLT transformation error
Project Queue general percentage SQL retries per day
Project Queue general percentage SQL retries per hour
Project Queue jobs average wait time per day
Project queue jobs percentage jobs failed per day
Project queue jobs percentage failed per hour
Project Queue System restarting due to unexpected error
Project Reporting server side event has failed
Project Server event handler could not be found
Project Server event service could not be found
Project SQL user view refresh message was not queued
Project user view was truncated
Project Windows SharePoint Services format error
Project Winproj average time taken for project open
Project Winproj average percentage of incremental save to full save
Project workspace user synchronization failed


Project Active Directory nested object could not be resolved
See Also

Published: May 12, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Active_Directory_Nested_Object_Could_Not_Be_Resolved

Summary: Microsoft Project Server could not resolve a nested Active Directory object during Active Directory synchronization. The Active Directory object could be either a user or a group.However, this warning message does verify that the top-level Active Directory group was resolved. This means that communication between the Project Server application server that initiated the Active Directory synchronization and the Active Directory domain or forest to which the top-level Active Directory group belongs was successfully established. However, the nested Active Directory object listed in the Windows Server event log cannot be resolved. Active Directory synchronization was tagged for partial failure.

Cause: Possible causes include the following:

  • The Active Directory group no longer exists in the Active Directory store. For example, the group may have been deleted by an administrator.

  • The Project Server application server's SharePoint Service Account (SA) account does not have read access to the Active Directory group or user object listed in the Windows Server event log.

  • A communication problem exists between Project Server and the Active Directory domain in which the Active Directory group or user object resides.

Possible resolutions include the following:

  • Verify that at least one Active Directory group exists in the Active Directory store with the same Active Directory GUID that is stored in the Project Server application server.

  • Use the Active Directory Service Interfaces (ADSI) Edit tool to check security permissions on individual Active Directory group and user objects. The SA account must be able to read all Active Directory group and user objects that are involved in the synchronization process.

    Note:

    The ADSI Edit tool is available for Windows Server 2008 when you install the Active Directory Domain Services (AD DS) role to make a server a domain controller. It is also available as a part of the Remote Server Administration Tools (RSAT) kit available. See Installing or Removing the Remote Server Administration Tools Pack (http://go.microsoft.com/fwlink/p/?LinkId=143345) in the TechNet Library.

  • Ensure the local Active Directory forest or domain has access to the remote Active Directory forest or domain on which the foreign security principal resides.

See Also

Other Resources

Project Active Directory connection failed
Project Active Directory exception occurred during synchronization
Project Active Directory nested foreign security principal could not be resolved
Project Active Directory nested object could not be resolved
Project Active Directory PWA group could not be resolved
Project Active Directory top-level group has no members
Project Creating Report Center Web failed
Project Cube Build Service Analysis Services server connection failure
Project Cube Build Service Analysis Services server lock time out
Project Cube Build Service attempt to overwrite failed
Project Cube Build Service Decision Support Object is not installed
Project notification XSLT transformation error
Project Failure creating a Project workspace
Project General Data Access Layer error connecting to database
Project General Data Access Layer error while getting connection strings
Project notification e-mail delivery failed
Project notification XSLT transformation error
Project Queue general percentage SQL retries per day
Project Queue general percentage SQL retries per hour
Project Queue jobs average wait time per day
Project queue jobs percentage jobs failed per day
Project queue jobs percentage failed per hour
Project Queue System restarting due to unexpected error
Project Reporting server side event has failed
Project Server event handler could not be found
Project Server event service could not be found
Project SQL user view refresh message was not queued
Project user view was truncated
Project Windows SharePoint Services format error
Project Winproj average time taken for project open
Project Winproj average percentage of incremental save to full save
Project workspace user synchronization failed


Project Active Directory PWA group could not be resolved
See Also

Published: May 12, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Active_Directory_PWA_Group_Could_Not_Be_Resolved

Summary: During Microsoft Project Web App security group synchronization, Microsoft Project Server could not resolve the top-level Active Directory object for the Project Web App security group. Active Directory synchronization has been tagged for failure for this group.

Cause: The Project Server application server cannot access Active Directory for any of the following reasons:

  • The Project Server application server is using a SharePoint Service Account (SA) account that does not have read access to the Active Directory directory service. This can occur if the SSP is configured to use a local computer account.

  • The Project Server application server does not currently have network access to the domain.

  • TCP or UDP ports that are required for Project Server and Active Directory to communicate are not open between the Project Server application server and the Active Directory store. This can occur if a firewall is configured to block the ports described in the following list:

    • 389/UDP - LDAP: LDAP is the Lightweight Directory Access Protocol that provides a standard way to access directory services. LDAP is the primary protocol that is used to access an Active Directory store.

    • 636/TCP - LDAP over SSL: When Secure Sockets Layer (SSL) is enabled, the LDAP data that is transmitted and received is encrypted.

    • 3268/TCP - Microsoft global catalog: Active Directory global catalogs listen on this port.

    • 3269/TCP - Microsoft global catalog with LDAP/SSL: Microsoft global catalog SSL connections listen on this port.

  • The Active Directory group no longer exists in the Active Directory store. For example, the group may have been deleted by an administrator.

  • The Project Server application server's SA account does not have read access to an Active Directory group or user object.

Possible resolutions include the following:

  • Verify that the service account that is used by the SA that is used by the Project Server application server is a domain account that has read access to Active Directory.

  • Verify that the Project Server application server is joined to an Active Directory domain.

  • Verify that the Project Server application server has network access.

  • Verify that the TCP and UDP ports listed in the previous section are open between the Active Directory store and the Project Server application server.

  • Verify that at least one Active Directory group exists in the Active Directory store with the same Active Directory GUID that is stored in the Office Project Server application server.

  • Use the Active Directory Service Interfaces (ADSI) Edit tool to check security permissions on individual Active Directory group and user objects. The SA account must be able to read all Active Directory group and user objects that are involved in the synchronization process.

    Note:

    The ADSI Edit tool is available for Windows Server 2008 when you install the Active Directory Domain Services (AD DS) role to make a server a domain controller. It is also available as a part of the Remote Server Administration Tools (RSAT) kit available. See Installing or Removing the Remote Server Administration Tools Pack (http://go.microsoft.com/fwlink/p/?LinkId=143345) in the TechNet Library.

See Also

Other Resources

Project Active Directory connection failed
Project Active Directory exception occurred during synchronization
Project Active Directory nested foreign security principal could not be resolved
Project Active Directory nested object could not be resolved
Project Active Directory PWA group could not be resolved
Project Active Directory top-level group has no members
Project Creating Report Center Web failed
Project Cube Build Service Analysis Services server connection failure
Project Cube Build Service Analysis Services server lock time out
Project Cube Build Service attempt to overwrite failed
Project Cube Build Service Decision Support Object is not installed
Project notification XSLT transformation error
Project Failure creating a Project workspace
Project General Data Access Layer error connecting to database
Project General Data Access Layer error while getting connection strings
Project notification e-mail delivery failed
Project notification XSLT transformation error
Project Queue general percentage SQL retries per day
Project Queue general percentage SQL retries per hour
Project Queue jobs average wait time per day
Project queue jobs percentage jobs failed per day
Project queue jobs percentage failed per hour
Project Queue System restarting due to unexpected error
Project Reporting server side event has failed
Project Server event handler could not be found
Project Server event service could not be found
Project SQL user view refresh message was not queued
Project user view was truncated
Project Windows SharePoint Services format error
Project Winproj average time taken for project open
Project Winproj average percentage of incremental save to full save
Project workspace user synchronization failed


Project Creating Report Center Web failed

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Creating_Report_Center_Web_Failed

Summary: The ProjectBICenter web could not be created during provisioning.

Cause: The ProjectBICenter web could not be created during provisioning for any of the following reasons:

  • The required web template is not available on the site collection.

  • At least one of the following required features could not be activated:

    • Office Server Publishing Site

    • BasicWebParts

    • PerformancePoint SiteCollection

    • PremiumSite

  • There already is a web with the same name as ProjectBICenter that is not of type Business Intelligence.

Possible resolutions include the following:

  • Make sure that the PerformancePoint service application is created. Re-try Microsoft Project Web App (PWA) creation.

  • Activate the following features:

    • Office Server Publishing Site

    • BasicWebParts

    • PerformancePoint SiteCollection

    • PremiumSite

  • Move the content and delete the old ProjectBICenter site. Then re-create PWA site.


Project Cube Build Service Analysis Services server connection failure

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Cube_Build_Service_Analysis_Services_Server_Connection_Failure

Summary: Microsoft Project Server failed to connect to the Microsoft SQL Server Analysis Services (SSAS) server for building cubes.

Cause: This error can occur for a number of reasons. Most commonly, this can occur when the SQL Server Analysis Services server is unavailable or the account used to access the Analysis Services server does not have adequate permissions to connect.

Possible resolutions include the following:

  • Ensure that the MSSQLServerOLAPService service (if SQL Server 2000 is used as the back-end database) or SQL Server Analysis Services (if Microsoft SQL Server 2005 is used as the back-end database) is running.

  • Ensure that the account running the Microsoft Project Server Queuing Service is a member of the OLAP Administrators group on the Analysis Services server.


Project Cube Build Service Decision Support Object is not installed

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Cube_Build_Service_Decision_Support_Object_Is_Not_Installed

Summary: The Cube Build Service requires the Decision Support Object (DSO) component of SQL Server Analysis Services be installed on the Microsoft Project Server application server from which the Project Server farm connects to the Analysis Services server to generate the cubes structure.

Cause: The DSO component of Analysis Services is not installed on the Project Server application server.

Possible resolutions include the following:

  • Use the Analysis Services 2000 setup wizard to install the DSO component on the Project Server application server. Note that you do not have to install the Analysis Services, only the DSO component. In the setup wizard, the DSO component is known as the "Client Component."

  • If the cubes will be built on SQL Server 2005 Analysis Services, you have to install the following components on the application server:

    • Microsoft SQL Server Native Client (installed by using sqlncli.msi).

    • Microsoft SQL Server 2005 Management Objects Collection (installed by using sqlserver2005_xmo.msi).

    • Microsoft SQL Server 2005 Backward Compatibility Components (installed by using SQLServer2005_BC.msi).

    Note:

    These components can be downloaded from the Feature Pack for Microsoft SQL Server 2005 - April 2006 release (or newer). For additional configuration information, see Deployment for Project Server 2010.

  • Move the Content and Delete the old ProjectBICenter site. And then re-create PWA site.


Project Cube Build Service Analysis Services server lock time out

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Cube_Build_Service_OLAP_Processing_Failure

Summary: After the Microsoft Project Server cube structures are built, the Microsoft SQL Server Analysis Services (SSAS) server processes the cubes in order to obtain the data from its data source, which is the associated Project Server Reporting database. This processing also obtains any customized data that was added to the cubes.

Cause: Several things could cause the SQL Server Analysis Services database processing to fail. The most common case is that the Analysis Services server does not have access to the data in the Project Server Reporting database. This could be the case if the computer that is running SQL Server and that is hosting the Reporting database and the Analysis Services server are on separate computers and the SQL Server Analysis Services is not running under an account that has at least read access to the Reporting database. This might also occur if there is a custom extension to the cubes that attempts to read data from a source without having sufficient permission.

Possible resolutions include the following:

  • Use the ULS logs to verify that the processing failure is caused by permission problems.

  • Resolve permission problems:

    • In the computer where the Analysis Services server is running, ensure that the account that is used by the computer that is running SQL Server Analysis Services is a Windows domain account instead of in a service account, such as Local System.

    • Ensure that this account has read access to the Project Server Reporting database from the site on which you want to build cubes. Note that, if there are multiple sites building cubes on the same Analysis Services server, the Windows domain account that is used by the SQL Server Analysis Services should have read access to all corresponding Project Server Reporting databases.

  • If processing fails but the credentials are configured properly, go directly to the Analysis Services server and manually attempt to process the database. This action will provide you with detailed information about where the failure is occurring.


Project Cube Build Service OLAP Processing Failure

Published: August 27, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Cube_Build_Service_OLAP_Processing_Failure

Summary: After the Microsoft Project Server cube structures are built, the computer that is running Microsoft SQL Server Analysis Services (SSAS) processes the cubes in order to obtain the data from its data source. The data source is the associated Project Server Reporting database. This processing also obtains any customized data that was added to the cubes.

Cause: Several things could cause the SQL Server Analysis Services database processing to fail. The most common case is that the Analysis Services server does not have access to the data in the Project Server Reporting database. This could be the case if the following are true:

  • The Reporting database and the Analysis Services server are on separate computers

  • The instance of SQL Server Analysis Services is not running under an account that has at least read access to the Reporting database

This might also occur if there is a custom extension to the cubes that attempts to read data from a source without having sufficient permission.

Possible resolutions include the following:

  • You can use the ULS logs to verify that the processing failure is caused by permission problems.

  • To resolve permission problems:

    1. In the computer where Analysis Services server is running, ensure that the account that is used by the computer that is running SQL Server Analysis Services is a Windows domain account instead of a service account, such as Local System.

    2. Ensure that this account has read access to the Project Server Reporting database from the site on which you want to build cubes. If there are multiple sites building cubes on the same Analysis Services server, the Windows domain account that is used by SQL Server Analysis Services should have read access to all corresponding Project Server Reporting databases.

  • If processing fails but the credentials are configured correctly, go directly to the Analysis Services server and manually attempt to process the database. This action will give you detailed information about where the failure is occurring.


Project Failure creating a Project workspace

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Failure_Creating_A_Project_Workspace

Summary: Microsoft Project sites are created asynchronously on project publish through the Project Server Queue Service. This applies to projects published from Project Professional and those published using Microsoft Project Web App alike. This alert occurs when asynchronous Project site creation fails.

Cause: Failure creating a project workspace may be caused by any of the following reasons:

  • An invalid template. If the administrator has incorrectly extended the Project Site template, or has incorrectly deployed the template, site creation using that template may fail.

Possible resolutions include the following:

  • Attempt to create a Project site manually to determine whether the site template is valid. If site creation succeeds, the problem may be related to other operations that occur during Project site creation, such as site linking or user synchronization. If Project site creation fails, review the Windows Event log and trace logs and troubleshoot accordingly.

  • If the problem persists, determine whether the underlying Project Server Interface methods that support site creation are functioning correctly. If the site is provisioned correctly through the user interface (which is a synchronous operation), the problem may be related to the queue.

  • Create a Project site manually

    1. Log on to Project Web App as an administrator.

    2. On the Site Actions menu, click Site Settings.

    3. In the Site Administration section, click Sites and Workspaces.

    4. On the Sites and Workspaces page, click Create.

    5. On the New SharePoint Site page, select the options that you want and then click Create.

      Note:

      You must specifically choose the Microsoft Project site template.

  • Verify that the underlying Project Server Interface methods that support site creation work.

    1. Log on to Project Web App as an administrator.

    2. In the Quick Launch, click Server Settings.

    3. In the Operational Policies section, click Project Sites.

    4. On the Project Sites page, select a project that does not have a site, and then click Create Site.

    5. In the Create Project Site dialog box, enter this project site in the Site URL box and then click OK.

      Tip:

      Notice that, as you type the path in the Site URL box, the URL displayed to the right of the Destination URL label is automatically updated.


Project General Data Access Layer error connecting to database

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_General_Data_Access_Layer_Error_Connecting_To_Database

Summary: This message indicates that the Data Access Layer on a Microsoft Project Server application server tried but could not connect to one of the four Project Server databases that hold the data for a Microsoft Project Server site. The effect that this problem has on the Project Server deployment varies, depending on whether the problem is caused at the server or the database level, and whether a database is affected. The following list describes how the effect on the Project Server deployment varies, depending on which database the error originated from:

  1. Draft Database Project managers will be unable to save edits to data. However, some Microsoft Project Web App functionality will be available, although typically read-only. All Reporting database read-only functionality should be available. Limited Archive database functionality will be available, but no project archive or restore functions will be available.

  2. Published Database Most system functionality will be impaired because the security data that is used for authorization is stored in this database. All Reporting database functionality should be available. However, no Archive database functionality will be available.

  3. Archive Database Most system functionality will be available except for archive and restore functions that are either scheduled or performed manually.

  4. Reporting Database Most system functionality will be available except for relational reporting.

Note:

If either the Published database or the Draft database is unavailable, the Project Server queue service will degrade over time as queued actions either fail or are blocked.

Cause: Possible causes include the following:

  • Network connectivity issues that prevent the Project Server application servers from connecting to the one or more computers that are running Microsoft SQL Server.

  • Invalid service account credentials caused by account lockouts or failure to propagate changes.

  • Database availability issues caused by hardware problems, such as failed hard disk drives or controllers.

  • Data access issues caused by an administrator who changes database permissions, which results in the account that is used to access data being denied authorization.

Possible resolutions include the following:

  • Troubleshoot and resolve network connectivity between the Project Server application server and its SQL Server computers. For more information, see How to troubleshoot network connectivity problems (http://go.microsoft.com/fwlink/p/?LinkID=72704).

  • Troubleshoot and resolve SQL Server connectivity problems. For more information, see How to troubleshoot connectivity issues in SQL Server 2000 (http://go.microsoft.com/fwlink/p/?LinkID=72705).

  • Troubleshoot and recover from database issues. For more information, see INF: Disaster Recovery Articles for Microsoft SQL Server (http://go.microsoft.com/fwlink/p/?LinkID=72706).

    Note:

    Once connectivity to the databases is restored, the application administrator should use the Manage Queue Jobs page in Project Web App to review the queue and take any corrective actions as indicated by the queue management documentation.

  • Access the Manage Queue Jobs page

    1. Log on to Project Web App as an administrator.

    2. In the Quick Launch, click Server Settings.

    3. On the Server Settings page, in the Queue section, click Manage Queue.


Project General Data Access Layer error while getting connection strings

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_General_Data_Access_Layer_Error_While_Getting_Connection_Strings

Summary: The Data Access Layer reads information from the configuration database of the SharePoint Server farm when a Project Server application server is starting. The configuration database contains system infrastructure information, including the location of the Microsoft Project Server databases. If a Project Server application server cannot obtain this information from the configuration database, it cannot start.

Cause: A General Data Access Layer Error may occur for any of the following reasons:

  • Infrastructure availability problems that affect the configuration database or the Microsoft SQL Server computer where the configuration database is hosted.

  • Credential issues with the service account. This can be caused by a failure to propagate an account or a changed password, or the account has been locked out.

  • Incomplete or incorrect information in the configuration database due to a partial farm restore of an older copy of the configuration database that does not contain the Project Server information.

Possible resolutions include the following:

  • Depending on the root cause of the issue, you might use the troubleshooting guides in the following list to resolve the problem or restore the configuration database from backup.Possible resolutions include the following:

    • If the problem is due to network connectivity problems between the Project Server application servers and SQL Server computers, see How to troubleshoot network connectivity problems (http://go.microsoft.com/fwlink/p/?LinkID=72704).

    • If the problem is due to SQL Server connectivity issues, see How to troubleshoot connectivity issues (http://go.microsoft.com/fwlink/p/?LinkID=72704).

    • If the problem is due to incorrect data in SQL Server, see Disaster Recovery Articles for SQL Server (http://go.microsoft.com/fwlink/p/?LinkID=72704).

    • In the case of an out-of-step restore of the configuration database that has no possibility of rolling forward based on database logs, it is recommended that you reinstall Project Server and restore its data from backup into the new databases.


Project notification e-mail delivery failed

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Notification_E_mail_Delivery_Failed

Summary: The connection to the SMTP server failed..

Cause: A functioning connection to the SMTP server is unavailable.

Possible resolutions include the following:

  • Verify that the correct name of the SMTP Server is configured in Microsoft Project Server.

  • Verify that the SMTP Server is functioning normally. For example, the SMTP server may be incorrectly configured to use the wrong SMTP server name or port number.

    Note:

    After verifying the information listed earlier in this section, retry the queue job.


Project notification XSLT transformation error

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Notification_XSLT_Transformation_Error

Summary: This alert indicates that the XSL used to transform XML data in the body of an e-mail message has failed.

Cause: Possible causes may include:

  • The XSL data might be corrupted.

  • If the XSL data was customized, there could be an error in the custom code.

  • Other custom updates to the server farm might create a situation that is not compatible with the XSL data.

Possible resolutions include the following:

  • Make sure the performance point service application is created. Re-try Microsoft Project Web App (PWA) creation.

  • Performing the following steps:

    1. Check the Windows NT Event log to determine the notification e-mail type UID.

    2. Using the notification e-mail type UID from the Windows NT Event log, query the MSP_Notification_XSLS table in the Published database to return the notification e-mail XSL.

    3. Verify that the XSL does not contain any errors.

    4. If necessary, restore the XSL for the specified notification e-mail type UID from backup.


Project Queue jobs average wait time per day

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Queue_Jobs_Average_Wait_Time_Per_Day

Summary: This alert indicates that the amount of time jobs are waiting in the queue (on average) before they are processed has exceeded the threshold set for this rule. This gives you a direct way to determine whether your Service Levels are not being met. Note that if this alert occurs repeatedly, this indicates that service is poor.

Note:

Average wait time is calculated as follows:

Average wait time = Time when the job was picked up for processing - Time when the job was put into the queue.

Cause: Possible causes include the following:

  • Jobs are blocked in the queue of the Project Server application server.

  • The Project Server application server may be overloaded.

  • The Project Server application server may have fewer job processor threads than required to meet the inflow of jobs.

Possible resolutions include the following:

Perform the following steps:

  1. Verify whether jobs are blocked in the queue by reviewing the Windows NT Event log and trace logs, and troubleshoot accordingly.

  2. If the problem persists, determine whether the problem is due to an overloaded Project Server application server by monitoring the following performance counters on the affected server: Processor, Memory, and PhysicalDisk.

    Important:

    If these performance counters indicate a bottleneck, upgrade the components that are causing the bottlenecks, or add one more additional Project Server application server as a service application so that the load is balanced among multiple servers.

    Warning:

    When you add another service application to the farm, the farm and the queue infrastructure provide load balancing automatically. If these performance counters indicate that the Project Server application server is not bottlenecked. However, the average wait time remains high, this may indicate that your Project Server application server might have fewer job processor threads than are required to meet the inflow of jobs. You can also increase the number of job processor threads.

  3. Try increasing the number of job processor threads by using the following procedure:

    1. Log on to Microsoft Project Web App as an administrator.

    2. In the Quick Launch, click Server Settings.

    3. On the Server Settings page, in the Queue section, click Queue Settings.

    4. On the Queue Settings page, in the Maximum Number of Job Processor Threads section, enter the maximum number of threads you want to use.

      Note:

      This setting is for a particular Project Web App site. This means that, if your Project Server application server has three Project Web App sites and you set the number of threads to 4 for each site, this will result in a total of 12 job processor threads for the Service Application (3 * 4 = 12). This is important to understand, because setting the total number of job processor threads too high can affect the performance of your server.


Project Queue general percentage SQL retries per day

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Queue_General_Percentage_SQL_Retries_Per_Day

Summary: This alert occurs if the queue is hit with a number of SQL retries when it is trying to read jobs from the Microsoft Project database or write status back.

Caution:

Note that this does not include SQL retries that may result from individual jobs being processed — but still gives a fair idea that there is something potentially wrong with the Project Server-to-SQL interaction.

Cause: Possible causes include the following:

  • The network connection between the Project Server application server and the SQL Server computer may be a bottleneck (if they are on different computers).

  • The SQL Instance that Project Server connects to may be overloaded.

Possible resolutions include the following:

  • Use a network Ping to verify whether there is excessive network latency between the Project Server application server and the SQL Server computer. If it is determined that the network is the bottleneck, resolve accordingly.

  • Monitor the performance objects on the computer that is running SQL Server, such as Processor, Memory, PhysicalDisk, and SQL-specific counters. If the problem is caused by too many applications that run on the SQL Server computer used by the Project Server application server, do one of the following:

    • Move the Project application to another computer that is running SQL Server.

    • Move other applications from the instance of SQL Server that Project Server is using to another instance of SQL Server.

    • Set up a SQL Cluster to improve the efficiency of the back-end database.


Project Queue general percentage SQL retries per hour

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Queue_General_Percentage_SQL_Retries_Per_Hour

Summary: This alert indicates that the number of SQL retries has exceeded the threshold for the past hour.This alert is based on the same performance counter as the "QueueGeneral: % SQL Retries / Day rule." It also helps to show spikes in SQL retries over a shorter period of time so you can choose to investigate possible causes before customers become aware of a potential problem.

Cause: Possible causes include the following:

  • The network connection between the Project Server application server and the SQL Server computer may be a bottleneck (if they are on different computers).

  • The SQL instance that Project Server connects to may be overloaded.

Possible resolutions include the following:

  • Use a network Ping to determine whether there is excessive network latency between the Project Server application server and the SQL Server computer. If you decide that the network is the bottleneck, resolve accordingly.

  • Monitor the performance objects on the SQL Server computer, such as Processor, Memory, PhysicalDisk, and SQL-specific counters. If the problem is caused by too many applications running on the SQL Server computer used by the Project Server application server, do one of the following:

    • Move the Project application to another SQL Server computer.

    • Move other applications from the SQL Server computer that Project Server is using to another SQL Server computer.

    • Set up a SQL cluster to improve the efficiency of the back-end database.


Project Cube Build Service attempt to overwrite failed

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Cube_Build_Service_Attempt_To_Overwrite_Failed

Summary: The Microsoft Project Server Cube Build Service failed to build a Microsoft SQL Server Analysis Services (SSAS) database because another SQL Server Analysis Services database already exists with the same name from a different Microsoft Project Web App site.

Cause: This error can occur when more than one Project Web App site attempts to build an Analysis Services database in the same Analysis Services server that uses the same database name.

Possible resolutions include the following:

  • Ensure that all Analysis Services database names for a particular Analysis Services server are unique across all Project Web App sites.


Project Active Directory top-level group has no members

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Active_Directory_Top_Level_Group_Has_No_Members

Summary: The top-level Active Directory group that is mapped to the Enterprise Resource Pool or a Microsoft Project Web App Security Group does not contain any members. Because of this, no user objects in the Active Directory directory service will be synchronized with Microsoft Project Server.

Cause: The top-level Active Directory group that is mapped to the Enterprise Resource Pool or a Project Web App Security Group does not contain any members.

Possible resolutions include the following:

  • To keep this warning from occurring, add members to the Active Directory group. If you have created the Active Directory group and plan to add members to the group at a later time, you can ignore this message.


Project workspace user synchronization failed

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Workspace_User_Synchronization_Failed

Summary: Microsoft Project Server users are added as users to Project sites based on the permissions that are assigned to them by an administrator in Project Server. This allows for Project team members to access the Project site. This alert occurs when the synchronization of users from Project Server to the Project site fails. This indicates that some or all of the project users were not added to the SharePoint groups for the Project site. Until this problem is resolved, those project users will not have access to the Project site.

Cause: User synchronization may have failed for one of the following reasons:

  • There was an error communicating with the site. For example, the Web application that hosts the Project site may be down.

  • User synchronization may have encountered an error when you are adding one or more users to the Project site.

  • User synchronization may have timed out on the Project Server application server.

Possible resolutions include the following:

  • Make sure the PerformancePoint service application is created. Re-try Microsoft Project Web App(PWA) creation.

  • You can troubleshoot user synchronization errors by doing the following:

    • Attempt to synchronize users to a Project site manually, as described in the following steps. If this action works, the error might have occurred because a user has inadequate permissions.

    • Review the trace logs to determine whether synchronization failed for a specific user. Take action on that error and retry user synchronization.

  • Synchronize users to a Project site manually

    1. Log on to Project Web App as an administrator.

    2. In the Quick Launch, click Server Settings.

    3. In the Operational Policies section, click Project Sites.

    4. On the Project Sites page, select a project and then click Synchronize.


Project Winproj average percentage of incremental save to full save

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Winproj_Percentage_Of_Incremental_Save_To_Full_Save

Summary: The first time that a project is created on the Microsoft Project Server application server from Microsoft Project Professional, it is saved using a full save, which means that all of the project data is transmitted and saved in the database used by the Project Server application server. Subsequent saves of the project are saved incrementally, by default. This means that only the project data that has CHANGED is transmitted to the server and saved in the database. This is mainly to optimize performance.

Full saves also occur in the following situations:

  1. If the incremental save fails, a FULL SAVE is attempted.

  2. The "correlated job group" for a particular project is blocked. For example, a project check-in failure can block the correlated job group for that project. After this, when a user attempts to save that same project from Microsoft Project Professional, the "correlated job group" for that project is canceled and a FULL SAVE of a project is performed. For more information about correlated job groups, see the queue documentation.

    Note:

    Note that users are never aware of whether their project is saved using a FULL SAVE or an incremental save. However, the administrator should care about this issue because it directly affects performance.

    Note:

    This alert occurs if the percentage of incremental saves is less than the threshold.

Cause: The number of full saves that are occurring has exceeded the threshold set for this alert.

Possible resolutions include the following:

  • Use the Queue Management page in Microsoft Project Web App and check for failed jobs to determine which jobs are blocking the correlated job group. Review the Windows NT Event and trace logs to determine whether there are events or traces from the "Project Server Active Cache Save" category that relate to the failed queue jobs that you discovered on the Queue Management page, and troubleshoot accordingly.


Project Winproj average time taken for project open

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Winproj_Average_Time_Taken_For_Project_Open

Summary: This counter tracks the average time taken (in seconds) for a project to open on a Microsoft Project Server application server that uses Microsoft Project Professional. Note that this counter tracks the time taken for a project to open on the server only — it does not include the communication overhead between the client application (in this case Microsoft Project Professional) and the Project Server application server. The average time taken for a project to open is calculated as follows:

Average time taken for project to open = Total time taken for all projects to open / total number of times projects were opened.

Note:

By default, this alert occurs if the average time taken is greater than 2 minutes.

Cause: Possible causes include the following:

  • This alert typically occurs when the Project Server application server is overloaded.

  • The SQL Server computer that hosts the databases for the Project Server application server is overloaded.

Possible resolutions include the following:

  • Review other performance objects, such as Processor, Memory, and PhysicalDisk to determine the performance bottleneck, and upgrade the components that are causing the bottlenecks or consider adding more Project Server application servers to your farm to balance the load.

  • If the Project Server application server is not overloaded, the SQL Server computer may be the bottleneck. Monitor the performance objects on the SQL Server computer, such as Processor, Memory, PhysicalDisk, and SQL-specific counters. If the problem is caused by too many applications that run on the same SQL Server computer, do one of the following:

    • Move the Project application to another SQL Server computer.

    • Move other applications from the SQL Server computer that Project Server is using to another SQL Server computer.

    • Set up a SQL cluster to improve the efficiency of SQL Server.


Project user view was truncated

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_User_View_Was_Truncated

Summary: The Reporting Data Service creates views that make it easy for users to perform reporting and cube building against the Reporting database. These views, which are Microsoft SQL Server views, are limited to1024 columns, also referred to as fields.

This alert occurs every time that the Reporting Data Service recreates the Reporting Database views (for example, when cubes are defined or when custom fields are created or deleted) if the reporting database is configured to use more than 1024 columns.

Organizations that bring multiple business divisions together into the same Microsoft Project Server site may have little or no overlap between custom fields. This can result in a Reporting database that exceeds 1024 columns.

Cause: A large number of custom fields, in combination with a large number of Project Server fields, can cause the Reporting database views to exceed the architectural limit of 1024 columns. To prevent this condition from causing the view creation process to fail, the Reporting Data Service stops adding custom fields when the limit is reached and provides a warning Windows NT Event to help system administrators who are unaware of this limit to diagnose "missing" data.

Possible resolutions include the following:

  • Reduce the number of custom fields used by any particular Project Server site. One way to do this is by creating additional Project Server sites and moving some of the users to the new sites.

  • Organizations that need more than 1024 fields for a particular site should consume the Reporting UserViewChanged event and create additional views that contain the additional data.


Project Windows SharePoint Services format error

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Windows_SharePoint_Services_Format_Error

Summary: The Reporting Data Service extracts Microsoft Project Issue, Risk, and Deliverable data from lists that are defined within each workspace (sites) on the Microsoft Project Server application servers in the farm. This alert occurs if an item in one of the lists contains data that cannot be stored in its associated Reporting database table. This typically is caused by the list data being in the wrong format or too large to store in the database table.

The resolution is to fix the underlying problem. The RDS pulls SharePoint Server data (Issues, Lists, Deliverables) into RDS. Use ULS to pinpoint the SharePoint Server list item causing the issue. Delete/re-create the item, or look for type mismatches/anomalies in the list item instance data.

Cause: An administrator or designer incorrectly modified the standard Project list templates. For example, the entry types or sizes were changed in a way that data that was stored in lists cannot be replicated to the Reporting database.

Note:

The Project Server SDK documentation indicates valid customizations that can be made to these standard list items.

Possible resolutions include the following:

  • If the site template was incorrectly edited, you can do the following to resolve the problem:

    • Correct the site template.

    • Recreate the workspace using the corrected template.

    • Manually reload the data into the lists.

  • If this procedure is not feasible, the affected lists should be deleted and a custom list that supports the data format that you require should be used instead. Note that if you choose this alternate resolution, you will not be able to replicate data from the custom list to the Reporting database.


Project SQL user view refresh message was not queued

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_SQL_User_View_Refresh_Message_Was_Not_Queued

Summary: The Reporting Data Service maintains a series of Microsoft SQL Server views that shield the reporting user or application and the Cube Building Service from the complexities of custom field and time-phased data storage. These views are updated when custom fields are added, changed, or deleted.

This event indicates that a queue service or application logic problem has stopped a request to regenerate a SQL view and, therefore, the view may now be out of date. For example, the view may contain a field that has been deleted or the view may be missing a new field that was created after the view was last created. SQL queries that are made against the Reporting database using this view may return stale or incorrect data.

Cause: The request to regenerate a SQL view, also referred to as a user view refresh message, could not be added to the Microsoft Project Server queue due to queue service availability issues, database issues with the Draft database, or an application logic problem with the Reporting Data Service.

Possible resolutions include the following:

  • Force the Project Server application server to attempt to queue the user view refresh message, change the property of an enterprise custom field definition, and then change it back. For example, change the name of an enterprise custom field from "My Enterprise Custom Field" to "My Enterprise Custom Fields," save the changes, and then change the field name back to "My Enterprise Custom Field." This forces the Project Server application server to attempt to queue the user view refresh message again.

    Note:

    The custom field definition must be of the same entity type as the custom field that is causing the issue. For example, if a Task custom field has prevented the User View Refresh message from being queued, you must modify a property of a Task custom field.


Project Server event service could not be found

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Server_Event_Service_Could_Not_Be_Found

Summary: Project Server events are handled by the application servers in the farm. A Windows NT service called Microsoft Project Server Eventing fires the event handlers. This service is responsible for locating, loading, and running the appropriate third-party event handlers. If the Microsoft Project Server Eventing Service is unavailable, then no registered event handlers can be executed.

Cause: Possible causes include the following:

  • The Microsoft Project Server Eventing Service is not started and running.

    Note:

    The Windows SharePoint Services Timer service periodically checks whether the Microsoft Project Server Eventing Service is running, and attempts to start it if they are necessary.

  • The Microsoft Project Server Eventing Service uses the same credentials as the Service Application for the Project Server Interface application. This means that if those credentials are invalid (for example the password has expired), this event may occur.

Possible resolutions include the following:

  • If it is stopped, restart the Microsoft Project Server Eventing Service.

  • If the Microsoft Project Server Eventing Service is not stopped, verify that the credentials for the account that is used by this service are valid and then restart the service.


Project Server event handler could not be found

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Server_Event_Handler_Could_Not_Be_Found

Summary: Administrators can register event handlers for Microsoft Project Server by using the Events page in Microsoft Project Web App. To register an event handler, the event handler assembly must be physically present on all application servers in the farm. If the event handler cannot be located, it cannot be loaded and executed.

Cause: An administrator might have deleted the event handler or moved it to a different location. To avoid errors, the registration information in Project Web App must be updated when an administrator deletes or moves an event handler. The system looks for the registered event handler when a server side event occurs.

Possible resolutions include the following:

  • Perform the following steps:

    • Verify the existence of the event handler assembly on all application servers in the farm.

    • Use the Events page in Project Web App to update the event handler registration with the correct location of the event handler assembly.


Project Reporting server side event has failed

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Reporting_Server_Side_Event_Has_Failed

Summary: The Microsoft Project Server application server has a custom event handler infrastructure that enables developers to write code, such as a custom server-side event handler, to extend the capabilities of the application server and to enforce data-based business rules that are connected to the project management process.

This alert indicates that a custom server-side event handler running within the Reporting Data Service component has failed.

Cause: A problem, such as faulty logic or an unhandled exception, may have occurred in the custom event handler code or in the application server eventing infrastructure.

Possible resolutions include the following:

  • Verify the health of the Project Server Eventing Service that is running on the Project Server application server and troubleshoot accordingly. If no problem is found with this service, do one of the following:

    • Remove the custom event handler to prevent this error from occurring.

    • Review the Windows NT Event log for errors from the event handler and troubleshoot accordingly. In some cases, you may need to debug the code for the server-side event handler to uncover the root cause of the failure.


Project Queue System restarting due to unexpected error

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Queue_System_Restarting_Due_To_Unexpected_Error

Summary: The Queue System has been forced to restart due to an unexpected error.

Cause: The Project Queue System can restart due to any of the following reasons:

  • A queue job failure

  • Misconfiguration of the queue

Possible resolutions include the following:

  • View the ULS logs to see the specific error.

  • If a queue job is continually failing, cancel the job and restart the queue.


Project queue jobs percentage failed per hour

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Queue_Jobs_Percentage_Jobs_Failed_Per_Day

Summary: This rule indicates the percentage of jobs that failed in the queue of a specific Project Server application server over the past hour.

This alert is based on the same performance counter as the "ProjectServer:QueueJobs: % Jobs Failed / Day" rule, but it helps to show spikes in the number of jobs that have failed over a shorter period of time so you can choose to investigate possible causes before customers become aware of a potential problem. This percentage is calculated as follows:

% jobs failed = Total number of jobs that failed during the past hour / Total number of jobs processed during the past hour.

Cause: Causes may vary.

Possible resolutions include the following:

  • Perform the following steps to determine the problem and troubleshoot accordingly.

    1. View errors in Microsoft Project Web App:

      1. Log on to Project Web App as an administrator.

      2. In the Quick Launch, click Server Settings.

      3. On the Server Settings page, in the Queue section, click Manage Queue.

      4. On the Manage Queue Jobs page, find the jobs that have the job state of Failed and blocking or Failed and not blocking correlation.

      5. View more information about the failed jobs by clicking the error IDs that appear in the Error column of the failed jobs.

    2. View errors in the Windows NT Event log

      • View the Windows NT Event log on the Project Server application server on which this alert occurred to determine whether any errors occurred at approximately the same time as this alert that may have caused the problem.

    3. View trace logs

      • View the trace logs on the Project Server application server on which this alert occurred to determine whether any errors occurred at approximately the same time as this alert that may have caused the problem.

        Note:

        All the queue traces related to the Project Server queue are appended with "[QUEUE]".


Project queue jobs percentage jobs failed per day

Published: June 10, 2010

Applies to: Project Server 2010 | Project Server 2013

Element ID / Rule Name: Project_Queue_Jobs_Percentage_Jobs_Failed_Per_Day

Summary: This rule indicates the percentage of jobs that failed in the queue of a specific Project Server application server. This percentage helps you quantify the overall health of your system.This percentage is calculated as follows:

% jobs failed = Total number of jobs that failed / Total number of jobs processed.

Note:

The total number of jobs processed is calculated from the time the Microsoft Project Server Queuing Service was started. This means that, if an administrator stops and restarts the Project Server Queuing Service, this value is reset to zero.

Note:

The total number of jobs that failed is equal to the number of jobs that are in the "Failed and blocking" or "Failed and not blocking correlation" states.

Cause: Causes may vary.

Possible resolutions include the following:

Perform the following steps to determine the problem and troubleshoot accordingly.

  1. View errors in the Microsoft Project Web App:

    1. Log on to Project Web App as an administrator.

    2. In the Quick Launch, click Server Settings.

    3. On the Server Settings page, in the Queue section, click Manage Queue.

    4. On the Manage Queue Jobs page, find the jobs that have the job state of Failed and blocking or Failed and not blocking correlation.

    5. View more information about the failed jobs by clicking the error IDs that appear in the Error column of the failed jobs.

  2. View errors in the Windows NT Event log

    • View the Windows NT Event log on the Project Server application server on which this alert occurred to determine if any errors occurred at approximately the same time as this alert that may have caused the problem.

  3. View trace logs

    • View the trace logs on the Project Server application server on which this alert occurred to determine whether any errors occurred at approximately the same time as this alert that may have caused the problem.

      Note:

      All the queue traces related to the Project Server queue are appended with "[QUEUE]".


Accessing Project Web App and Project Professional from a Macintosh-based computer

Published: April 28, 2011

Although Project Professional and full access to Microsoft Project Web App are not supported in a Macintosh operating environment, Microsoft suggests two options for those who want to fully access Project Web App or use the Microsoft Project Professional client.

  • The first option is to install a Microsoft Project-compatible Windows operating system on your Apple computer that is using a genuine copy of Windows and Apple's Boot Camp software. Boot Camp is software included with Mac OS X 10.6 Snow Leopard that lets you run compatible versions of Microsoft Windows on an Intel-based Mac. More information about Boot Camp can be found at http://www.apple.com/support/bootcamp/ site.

  • The second supported option, which works on both Intel- and PowerPC-based Apple computers, is to download the free Microsoft Remote Desktop Connection Client for Mac. It enables you to connect your Macintosh computer to a Windows-based computer or to multiple Windows-based computers. Once the computers are connected, you can use Windows Internet Explorer on the remote computer to connect to a Project Web App site, or you can use a local client copy of Project Professional 2010 (if it is installed). The download for Microsoft Remote Desktop Connection Client for Mac can be found at http://www.microsoft.com/mac/downloads.

Access to Project Web App team member pages through Apple Safari 5 by using the Project Server 2010 Service Pack 1 update

The Project Server 2010 Service Pack 1 update provides support for the Apple Safari 5 browser for Mac OS x v10.6 users to access Project Web App pages that are most frequently used by team members. These pages include:

  • Project Web App main default page (default.aspx)

  • All pages in the "My Work" section in the Quick Launch. This includes the following:

    • Tasks

    • Timesheets

    • Issues and Risks

Important:

Although the Project Server 2010 Service Pack 1 update will allow access to these pages through the Apple Safari 5 browser, it is important to note that it will not allow you access to all pages in Project Web App. If you need access to all PWA pages in a Macintosh operating environment, use one of the two options listed in the previous section.

The Project Server 2010 Service Pack 1 update is applied to your Project Server 2010 Server environment, and must be applied to all Web Front End and Application server in your Project Server 2010 farm. For more information about the Project Server 2010 Service Pack 1 update, see Deploy Service Pack 1 for Project Server 2010. This article includes information about:

  • How to apply the update to your Project Server 2010 environment.

  • Key enhancement included with the update.

  • Additional browsers that are supported with the update.


Microsoft Project Server 2010 integration with SAP (white paper)

Published: January 17, 2012

Summary: Use Project Server to provide timely and cost-effective resource forecast business intelligence through integration with SAP and other ERP systems.

This white paper outlines the benefits and scenarios for integrating Microsoft Project Server 2010 with SAP's ERP; in particular integrating the actual time reporting from SAP with the time-phased planning and resource forecasting power of Project Server 2010.

This integration is cost-effective and enables the source of record Actuals (both Cost and Time reporting) to bring actuals to the planning activities that Project/Program Offices or Scheduling groups use Project Server 2010 for.

This connection and process enables a large national company to greatly reduce the time that is spent in planning and trying to map the actuals directly with the way that the organization schedules work. The feature-rich reporting capabilities of Microsoft Project Professional 2010, Project Server 2010, and Microsoft SharePoint Server 2010 are enabled, and that planning and reporting is put directly in the hands of the end-users.

This white paper is not a Detailed Technical Systems or programming write-up. Instead, it is a customer solutions case study focused on the value of systems integration of a Project and Resource Planning Organization.

Download as a Microsoft Word (.docx) file (http://go.microsoft.com/fwlink/p/?LinkId=238714)

Download as a PDF file (http://go.microsoft.com/fwlink/p/?LinkId=238716)


Conformance statement A-level (Project Server 2010)

Published: July 22, 2010

Conformance statement for Microsoft Project Server 2010 in regards to Web Content Accessibility Guidelines 2.0 (http://www.w3.org/TR/WCAG20/).

Conformance statement for configuration and administration experience at A-level

Claim | Details
Date of the claim | May 12th, 2010
Guidelines title, version, and URI | Web Content Accessibility Guidelines 2.0 (http://www.w3.org/TR/2008/REC-WCAG20-20081211/)
Conformance level satisfied: (Level A, AA or AAA) | A
A concise description of the Web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim. | Default content included with Project Server 2010 and Administration and Configuration features of Project Server 2010. For other product features, see Conformance statement AA-level (Project Server 2010).
A list of the Web content technologies relied upon. | HTML JavaScript CSS
Additional Web content technologies used, but not relied upon. | ARIA Silverlight RSS PNG GIF JPEG
A list of success criteria beyond the level of conformance claimed that have been met. This information should be provided in a form that users can use, preferably machine-readable metadata. | Conforms to 1.4.9 Images of Text (No Exception) - AAA. Conforms to 2.1.3 Keyboard (No Exception) - AAA. Conforms to 2.2.3 No Timing (No Exception) - AAA. Conforms to 2.3.2 Three Flashes - AAA. Conforms to 2.4.8 Location - AAA. Conforms to 3.3.6 Error Prevention (All) - AAA.

This conformance statement pertains to Project Server 2010.

Customization of the product voids this conformance statement from Microsoft. Customers may make independent conformance statements if they have conducted due diligence to meet all relevant requirements for their customization.

Please consult with Assistive Technology (AT) vendors for compatibility specifications of specific AT products. AT products that are compatible with all the rely-upon-technologies are expected to be functional with the product.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Revised 07/22/2010.

Microsoft regularly updates its websites and provides new information about the accessibility of products as that information becomes available.


Conformance statement AA-level (Project Server 2010)

Published: July 22, 2010

Conformance statement for Microsoft Project Server 2010 in regards to Web Content Accessibility Guidelines 2.0 (http://www.w3.org/TR/WCAG20/).

Conformance statement for core reader, author, and contributor experience at AA-level

Claim | Details
Date of the claim | May 12th, 2010
Guidelines title, version, and URI | Web Content Accessibility Guidelines 2.0 (http://www.w3.org/TR/2008/REC-WCAG20-20081211/)
Conformance level satisfied: (Level A, AA or AAA) | AA
A concise description of the Web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim. | All default content included with Project Server 2010 and Web application features of Project Server 2010 except where limited by Conformance statement A-level (Project Server 2010).
A list of the Web content technologies relied upon. | HTML JavaScript CSS
Additional Web content technologies used, but not relied upon. | ARIA Silverlight RSS PNG GIF JPEG
A list of success criteria beyond the level of conformance claimed that have been met. This information should be provided in a form that users can use, preferably machine-readable metadata. | Conforms to 1.4.9 Images of Text (No Exception) - AAA. Conforms to 2.1.3 Keyboard (No Exception) - AAA. Conforms to 2.2.3 No Timing (No Exception) - AAA. Conforms to 2.3.2 Three Flashes - AAA. Conforms to 2.4.8 Location - AAA. Conforms to 3.3.6 Error Prevention (All) - AAA.

This conformance statement pertains to Project Server 2010.

Customization of the product voids this conformance statement from Microsoft. Customers may make independent conformance statements if they have conducted due diligence to meet all relevant requirements for their customization.

Please consult with Assistive Technology (AT) vendors for compatibility specifications of specific AT products. AT products that are compatible with all the rely-upon-technologies are expected to be functional with the product.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Revised 07/22/2010.

Microsoft regularly updates its websites and provides new information about the accessibility of products as that information becomes available.


Video demos and training for Project Server 2010
See Also

Published: May 12, 2010

The following list contains links to all video demos and training that are available for Microsoft Project Server 2010.

Overview

Title | Description | Related topics
Ignite Training - Introduction to Project Server and Project Professional | This module of Project Server 2010 Ignite Training provides an overview of what Project Server 2010 is and what key investments have been made in this release. |
Microsoft Project Server 2010 Demo (http://go.microsoft.com/fwlink/p/?LinkId=197311) | Seth Patton, Senior Director of Microsoft Project, walks through a demonstration of Project Server 2010. |
Project 2010 Overview (http://go.microsoft.com/fwlink/p/?LinkId=197312) | This Project Conference keynote address by Keshav Puttaswamy covers the key investment areas of unified project and portfolio management, simple and intuitive user experience, enhanced collaboration and reporting, and scalable and connected platform. |
TechNet Webcast: Overview of Microsoft Project Server 2010 for IT Professionals (http://go.microsoft.com/fwlink/p/?LinkId=197313) | This Webcast is an overview of Project Server 2010 features, requirements, and deployment considerations that IT professionals need to know about the product. |

Planning

Title Description Related topics

Ignite Training - Planning, Design, and Deployment

This module of Project Server 2010 Ignite Training discusses the new service architecture for this release, what topologies are supported, Project Server 2010 and Microsoft SharePoint Server 2010 scenarios, and an overview of deployment considerations.

Ensuring Implementation Success by Focusing on Culture and Readying the Organization for Change (http://go.microsoft.com/fwlink/p/?LinkId=197314)

This executive session features Betsy Guthrie, Project Manager and Change Agent at Autodesk, the leading developer of state-of-the-art 2-D and 3-D applications. She shares her adoption strategies used to successfully deploy an enterprise Project Server 2010 and SharePoint Server 2010 implementation at one of the largest software development organizations in the world.

Project Server Security Part 1 - Permissions

This video presents an overview of Project Server 2010 security.

Note:

This video uses Microsoft Office Project Server 2007. The functionality is the same in Project Server 2010.

Plan groups, categories, and RBS in Project Server 2010

Project Server Security Part 2 - Groups

This video explains groups in Project Server 2010.

Note:

This video uses Office Project Server 2007. The functionality is the same in Project Server 2010.

Plan groups, categories, and RBS in Project Server 2010

Project Server Security Part 3 - Categories

This video explains categories in Project Server 2010.

Note:

This video uses Office Project Server 2007. The functionality is the same in Project Server 2010.

Plan groups, categories, and RBS in Project Server 2010

Project Server Security Part 4 - RBS

This video explains the Resource Breakdown Structure (RBS) in Project Server 2010.

Note:

This video uses Office Project Server 2007. The functionality is the same in Project Server 2010.

Plan groups, categories, and RBS in Project Server 2010

Deployment

Title | Description | Related topics
Planning, Design, and Deployment | This module of Project Server 2010 Ignite Training discusses the new service architecture for this release, what topologies are supported, Project Server 2010 and Microsoft SharePoint Server 2010 scenarios, and an overview of deployment considerations. |
Deploy Project Server - Single Application Server Farm | This video demonstrates how to install Project Server 2010 on a farm with a single application server. | Install and configure Project Server 2010
Deploy Project Server - Multi Application Server Farm | This video demonstrates how to install Project Server 2010 on a farm with multiple application servers and/or Web servers. | Install and configure Project Server 2010
Create Project Web App Site | This video demonstrates how to create and configure a Microsoft Project Web App site. | Create a PWA site (Project Server 2010)
Add an Application Server to a Project Server Farm | This video demonstrates how to add an application server to a Project Server 2010 farm. | Add an application server to a farm (Project Server 2010)
Deploying and Administering Project Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=197315) | This session from the Project Conference covers how to deploy Project Server 2010 and how to administer Project Server effectively using some of the new capabilities such as departmental custom fields. |
Deploy Project Server 2010 to a test environment - Hyper-V quick start | This video demonstrates how to configure Hyper-V for use with a Project Server 2010 test environment. | Hyper-V quick start for creating a Project Server 2010 test environment
Deploy Project Server 2010 to a test environment - Setting up a domain controller | This video demonstrates how to set up a domain controller for a Hyper-V based Project Server 2010 test environment. | Set up a domain controller for a Project Server 2010 test environment
Deploy Project Server 2010 to a test environment - Adding a virtual machine to the virtual domain | This video demonstrates how to add a virtual machine to the virtual domain in a Hyper-V based Project Server 2010 test environment. | Add a virtual machine to the virtual domain in a Project Server 2010 test environment
Deploy Project Server 2010 to a test environment - Setting up SQL Server | This video demonstrates how to configure SQL Server for a Hyper-v based Project Server 2010 test environment. | Set up SQL Server for a Project Server 2010 test environment
Deploy Project Server 2010 to a test environment - Install SharePoint Server 2010 | This video demonstrates how to install SharePoint Server 2010 on a Hyper-V based Project Server 2010 test environment. | Install SharePoint Server 2010 on a Project Server 2010 test environment
Deploy Project Server 2010 to a test environment - Installing and configuring Project Server | This video demonstrates how to install and configure Project Server 2010 in a Hyper-V based test environment. | Install and configure Project Server 2010 in a test environment
Deploy Project Server 2010 to a test environment - Creating a PWA site | This video demonstrates how to create and configure a Project Web App site in a Hyper-V based Project Server 2010 test environment. | Create a PWA site in a Project Server 2010 test environment
Deploy Project Server 2010 to a test environment - Configuring reporting | This video demonstrates how to configure reporting in a Hyper-V based Project Server 2010 test environment. | Configure reporting for a Project Server 2010 test environment

Upgrade and migration

Title | Description | Related topics
Ignite Training - Upgrade and Migration | This module of Project Server 2010 Ignite Training includes an overview of upgrade and migration and a look at specific upgrade scenarios, including Microsoft Office Project Server 2007 to Project Server 2010, Microsoft Office Project Server 2003 to Project Server 2010, and Microsoft Office Project Portfolio Server 2007 to Project Server 2010. |
TechNet Webcast: Project Server 2010 - Upgrade and Migration (http://go.microsoft.com/fwlink/p/?LinkId=197319) | This Webcast discusses upgrade options from both Project Server 2003 and Office Project Server 2007 to Project Server 2010, including tools, processes, scenarios, best practices for upgrade and migration, SharePoint Server 2010 coexistence impacts, and full-farm versus split-farm upgrades. |
TechNet Webcast: Project Server 2010 - Backwards Compatibility Mode (http://go.microsoft.com/fwlink/p/?LinkId=197320) | This Webcast discusses Project Server 2010 Backward Compatibility Mode (BCM), a feature that makes it possible for Microsoft Office Project Professional 2007 to access Project Server 2010. |
Project Server 2003 to Project Server 2007 Migration Best Practices (http://go.microsoft.com/fwlink/p/?LinkId=197321) | This session provides a wealth of best practices gathered and developed by Microsoft Consulting Services during many migration projects since 2007. |

Business Intelligence

Title | Description | Related topics
How reporting in Project Server 2010 works | In this video, Microsoft Program Manager Treb Gatte provides an overview chalk talk about how Project Server 2010 reporting works, and how it makes use of SharePoint Server 2010 services. |
Project Server 2010 Reporting Tour | This video provides a tour of a functional Project Server 2010 Business Intelligence Center, including a look which SharePoint Server 2010 services are used and how the various services interact with each other. |
Configure Reporting | This video demonstrates how to configure reporting for Project Server 2010 |
Better Reporting Using Microsoft Business Intelligence Capabilities (http://go.microsoft.com/fwlink/p/?LinkId=197322) | In this video from the Project Conference in 2009, Microsoft Program Manager Treb Gatte describes the business intelligence capabilities available in Project Server 2010. |
Project Server 2010 Reporting Deep Dive (http://go.microsoft.com/fwlink/p/?LinkId=197324) | This session demonstrates how to build reports, KPIs, and dashboards using the various Microsoft BI technologies that are part of Project Server 2010. |
Ignite Training - Reporting Part 1 | This module from Project Server 2010 Ignite Training includes an introduction to the reporting infrastructure, including using Excel Services in Microsoft Office SharePoint Server 2007 to generate reports. |
Ignite Training - Reporting Part 2 | This module from Project Server 2010 Ignite Training includes a look at advanced reporting options, including PerformancePoint Services in Microsoft SharePoint Server 2010, Visio Services in Microsoft SharePoint Server 2010, and PowerPivot. |

Demand management

Title | Description | Related topics
Demand Management | This module from Project Server 2010 Ignite Training includes an overview of demand management, a look at its components, and a review of the steps required to implement demand management. |
Demand Management Workflow Deep Dive (http://go.microsoft.com/fwlink/p/?LinkID=197325) | This session covers developer experience in creating a workflow, deployment of Project workflows, and administrator experience in creating Workflow Controlled Enterprise Project Types. |

Timesheet and statusing

Title | Description | Related topics
Ignite Training - Timesheet and Statusing | This module from Project Server 2010 Ignite Training includes an overview of timesheet and statusing configuration, reporting, and Exchange Server integration. |

Portfolio management

Title | Description | Related topics
Portfolio Strategy | This module from Project Server 2010 Ignite Training includes an overview of business drivers and portfolio analyses. |
Portfolio Management (http://go.microsoft.com/fwlink/p/?LinkId=197326) | This Project Conference session covers the capabilities around business driver prioritization, portfolio optimization, and the new portfolio planning capabilities. |
Strategic Portfolio and Resource Capacity Planning Using Simulation (http://go.microsoft.com/fwlink/p/?LinkId=197327) | This presentation explores how simulation works with Project Server 2010, allowing EPM customers to understand their EPM data in a new, more dynamic way. |

Operations and administration

Title | Description | Related topics
Ignite Training - Administration | This module from Project Server 2010 Ignite Training includes a look at departments, delegation, Active Directory synchronization, and bulk updating project sites. |
Ignite Training - Operations | This module from Project Server 2010 Ignite Training includes discussions around error logging, usage logging, health reports, password management, and Windows PowerShell. |

Development and Extensibility

Title | Description | Related topics
Developing Custom Solutions in PWA (http://go.microsoft.com/fwlink/p/?LinkId=197328) | This session focuses on extending current PWA features as well as using the new JavaScript based grid control to create features of your own. |
Development and Extensibility | This module from Project Server 2010 Ignite Training includes an overview of Project Server 2010 and Microsoft Project Professional 2010 extensibility. |

Using Project Server

Title | Description | Related topics
Up to speed with Project Web App - Part 1: The basics (http://go.microsoft.com/fwlink/p/?LinkId=197329) | This video covers the basics of how to use Project Web App. |
Up to speed with Project Web App - Part 2: Proposing and creating a new project (http://go.microsoft.com/fwlink/p/?LinkId=197330) | This video covers the process of creating a new project in Project Web App. |
Up to speed with Project Web App - Part 3: Selecting projects for your portfolio (http://go.microsoft.com/fwlink/p/?LinkId=197331) | This video covers the process of selecting projects for your portfolio. |
Up to speed with Project Web App - Part 4: Plan your project (http://go.microsoft.com/fwlink/p/?LinkId=197332) | This video covers techniques for planning your projects, including adding tasks and resources. |
Up to speed with Project Web App - Part 5: Manage your project (http://go.microsoft.com/fwlink/p/?LinkId=197333) | This video covers techniques for managing a project that is currently underway, including working with timesheets. |
Create a custom enterprise project type (http://go.microsoft.com/fwlink/p/?LinkId=197334) | Watch this video to learn how a site administrator creates an enterprise project type. | Create a custom enterprise project type (http://go.microsoft.com/fwlink/p/?LinkId=197343)
Create an analysis (http://go.microsoft.com/fwlink/p/?LinkId=197405) | This video covers how to create an analysis of your proposal, including using business drivers and custom fields. | Create analyses and prioritize projects (http://go.microsoft.com/fwlink/p/?LinkId=197344)
Prioritize a project (http://go.microsoft.com/fwlink/p/?LinkId=197336) | This video covers how to prioritize the projects included in an analysis. | Create analyses and prioritize projects (http://go.microsoft.com/fwlink/p/?LinkID=197344)
Create the approval process for a proposal, part 1 (http://go.microsoft.com/fwlink/p/?LinkId=197337) | This video covers configuring an approval workflow for your projects. | Create the approval process for a proposal (http://go.microsoft.com/fwlink/p/?LinkId=197345)
Create the approval process for a proposal, part 2 (http://go.microsoft.com/fwlink/p/?LinkId=197338) | This video covers creating and editing a user in Project Web App. | Create the approval process for a proposal (http://go.microsoft.com/fwlink/p/?LinkID=197345)
Create the approval process for a proposal, part 3 (http://go.microsoft.com/fwlink/p/?LinkId=197339) | This video covers creating and editing a group in Project Web App. | Create the approval process for a proposal (http://go.microsoft.com/fwlink/p/?LinkID=197345)
Define the phases and stages of a project life cycle (http://go.microsoft.com/fwlink/p/?LinkId=197340) | This video covers creating phases and stages and connecting them into a workflow. | Define the phases and stages of a project life cycle (http://go.microsoft.com/fwlink/p/?LinkId=197346)
Create or edit a project or proposal, part 1 (http://go.microsoft.com/fwlink/p/?LinkId=197341) | This video covers creating a new project or proposal in Project Web App. | Create or edit a project or proposal (http://go.microsoft.com/fwlink/p/?LinkId=197347)
Create or edit a project or proposal, part 2 (http://go.microsoft.com/fwlink/p/?LinkId=197342) | This video covers editing a project or proposal in Project Web App. | Create or edit a project or proposal (http://go.microsoft.com/fwlink/p/?LinkID=197347)

Cumulative Updates

Title | Description | Related topics
TechNet Webcast: Information About Microsoft Project and Project Server Cumulative June 2010 Updatehttp://go.microsoft.com/fwlink/p/?LinkID=201581 | This webcast provides a brief overview of recently released Microsoft Project and Project Server Cumulative Updates (CU) as well as answering related questions about the Cumulative Updates. | The slide deck for this topic can be downloaded at: http://go.microsoft.com/fwlink/p/?LinkId=201593
TechNet Webcast: Information About Microsoft Project and Project Server Cumulative August 2010 Update (http://go.microsoft.com/fwlink/p/?LinkId=201583) | This webcast provides a brief overview of recently released Microsoft Project and Project Server Cumulative Updates (CU) as well as answering related questions about the Cumulative Updates. | The slide deck for this topic can be downloaded at: http://go.microsoft.com/fwlink/p/?LinkId=203367

See Also

Concepts

Project 2010 Ignite training slide presentation


D ps
See Also

2/24/2012

Scope | Token
project | Microsoft Project Server 2010
database | Microsoft Project Server 2010

See Also

Other Resources

D misc
D ss
D sf
D srch
D or
D gr


Add-SPProjectTenantAdministratorGroupAndTemplate
See Also
[image]

Published: May 12, 2010

Important:

Microsoft Project Server 2010 does not support multi-tenant environments. Use of the Add-SPProjectTenantAdministratorGroupAndTemplate cmdlet is not supported.

For information about supported Windows PowerShell cmdlets for Project Server 2010, see Project Server 2010 cmdlets.

Add-SPProjectTenantAdministratorGroupAndTemplate

Input Types

Return Types

See Also

Other Resources

White paper: SharePoint 2010 for hosters (SharePoint Server 2010)


OBSOLETE obsolete article

Published: May 12, 2010

This article is temporarily unavailable.