What's new for IT pros in Project Server 2010

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.

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 (https://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 (https://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 (https://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 (https://go.microsoft.com/fwlink/p/?LinkID=189587). For a series of how-to articles, see Developing Project Server workflows (https://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 (https://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 (https://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) (https://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).

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).

See Also

Other Resources

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