My name is Treb Gatte and I’m the Program Manager responsible for Setup and Upgrade for Microsoft Project Server 2010. 

In this post, we will review the major requirement changes for Project Server 2010 and give you the locations of the documentation.  In subsequent posts, we will review the “shopping list” of required patches and software levels and then delve into the setup process itself.

What’s different from Project Server 2007?

While much of Project Server 2010 will look familiar to Project Server 2007 users, there are some key items that have changed in the infrastructure. 

Microsoft SharePoint Server 2010. 

Project Server 2010 now requires Microsoft SharePoint Server 2010 as a setup prerequisite.  SharePoint Server 2010 is the latest version of what was Microsoft Office SharePoint Server (MOSS) 2007.  This is a higher SKU than in the previous release where only Windows SharePoint Services 3.0 was required.  The key takeaway is that this change may impact your infrastructure and licensing needs.

Project Server 2010 leverages SharePoint Server 2010 to provide workflow capabilities to our new Portfolio features, charting support for Resource and Portfolio charting and Excel Services and the Business Intelligence Center to greatly enhance our Business Intelligence capabilities. 

64 Bit Only Hardware

Project Server 2010 will only be offered in 64 bit versions this release.  The 64 bit requirement is the same for all tiers (web front end, application server and SQL Server).  This change was done to take advantage of better performing hardware.  The key takeaway is that this change may impact your infrastructure needs.

Most customers we’ve talked to seem to already use 64 bit SQL Servers.  The impact appears to be to the Web Front End /Application Server tiers. 

Internet Explorer 7 or Higher

Project Server 2010 requires Internet Explorer 7 or higher only.  This means if you attempt to use Firefox and Safari to browse to PWA, it will not load as these browsers are explicitly blocked.  The key takeaway is that this may have an impact on how you implement the solution. 

If your company is planning to implement Windows 7 on the desktop and you have internal applications that require Internet Explorer 6, you may consider the XP mode feature of Windows 7 for IE 6 support while keeping IE 7/8 on the native desktop for other applications, such as Project Server.

Windows 2008

The final release of Project Server 2010 can be hosted on Windows Server 2008 SP2 or later or Windows Server 2008 R2.  Please note, the Public Beta can be hosted on Windows Server 2008 SP2 initially.  Windows Server 2008 R2 support will be added to the Public Beta in the near future.  We’ll post a note when that support is available.

SQL Server

Project Server 2010 will require SQL Server 2005 SP3 CU3 or SQL Server 2008 SP1 CU2 to be installed.  As a result, we will no longer support SQL Server 2000.  We are currently testing SQL Server 2008 R2 November CTP.  Therefore, it isn’t officially supported for Public Beta yet.  A note will be posted when this support is available.

What’s Improved from Project Server 2007?

Bye, Bye ActiveX.

Absolutely, positively no ActiveX controls anywhere.  This will reduce the long term impact of cumulative updates and service paces and well as make initial installation much easier.

Windows PowerShell

Windows PowerShell support has been added to Project Server 2010.  This capability makes managing and setting up SharePoint Server and Project Server much easier.  If you’ve never used Windows PowerShell, this primer would be a great place to start.  http://technet.microsoft.com/en-us/library/ee176949.aspx

Exchange Integration

Project Server 2010 now integrates directly with Exchange Server 2007 SP2 or later rather than use the Outlook Add-In.   If your users want to update task status via Outlook, you no longer have to contend with the Outlook Add-In ActiveX control.  All configuration is done on the Project Server and the Exchange Server.

No More DSO.

If you are using OLAP, Project Server now requires SQL Server 2008 Analysis Management Objects instead of DSO.  The setup details and link to the download can be found here:  http://technet.microsoft.com/en-us/library/ee662106(office.14).aspx#section2

Configuring the System Changes

Post Installation Configuration

The number of post installation configuration steps are greater than in past releases and are needed in both SharePoint and Project Server.  Project Server 2010 is now dependent on the following services for Business Intelligence features.  As such, there are post configuration steps to enable the functionality for each Project Web Application instance.

• Excel Services
• Secure Store
• PerformancePoint Services

For charting in the Portfolio and Resource features, there is a dependency on the State Service.  However, this service is automatically configured by our provisioning process since it is a farm wide service.

In Project Server, you will now have to configure Time Reporting Periods as the newly redesigned My Tasks and My Timesheet interfaces depend on having those periods configured.  If you previously configured Timesheet Periods in Project Server 2007, these values will populate this table automatically on upgrade.

There are also some recommended SQL Server settings that will improve your performance, which we will cover in a separate post.

Setup and Migration Documentation

To make it easier for you to correctly setup the product, the setup and upgrade documentation is located here.  

http://technet.microsoft.com/en-us/library/cc197280(office.14).aspx

Videos

Sometimes, seeing the process performed can be a great way to see beyond the documentation.  Therefore, we’ve created videos of the entire setup process for you to review.

Deploy Project Server – Single Application Server Farm

• Stream: http://go.microsoft.com/fwlink/?LinkId=169126
• Download: http://go.microsoft.com/fwlink/?LinkId=169127

Deploy Project Server – Multi Application Server Farm

• Stream: http://go.microsoft.com/fwlink/?LinkId=169128
• Download: http://go.microsoft.com/fwlink/?LinkId=169129

Create Project Web Access Site:

• Stream: http://go.microsoft.com/fwlink/?LinkId=169130
• Download:  http://go.microsoft.com/fwlink/?LinkId=169131

Configure Reporting:

• Streaming: http://go.microsoft.com/fwlink/?LinkId=169132
• Download: http://go.microsoft.com/fwlink/?LinkId=169133

Add an Application Server to a Project Server Farm:

• Streaming: http://go.microsoft.com/fwlink/?LinkId=169134
• Download: http://go.microsoft.com/fwlink/?LinkId=169135

Introduction

Project Server 2007 allows you to creating literally hundreds of custom fields.  This is great, but a huge downside is that all of these fields are not typically needed by every user and therefore, they may add clutter and confusion.  In 2007, it is also not possible to create different custom field rules for one project vs. another user.  For instance, you cannot make a field required for one project yet optional for another.

With Project Server 2010, departmental custom fields help to relieve the problems of too much information and too many choices. As an example, departments help you to manage the UI clutter, and help you to define, at a resource, at a task, or at a project level, which fields are required or not required.  Let’s walk through this new feature and show you how you can use departments to manage your enterprise custom fields.

Scope

To begin with, we need a brief conversation about scope.  In 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, but they can also be departmentally scoped as well.  Consider this list of custom fields:

If a project belongs to the Development department, then when viewing areas of the product that enabled departmental fields, you will see:

• ProjectCustomText1
• ProjectCustomText2
• ProjectCustomText5
• ProjectCustomText6

Let’s say we have a user named Bob. Departments filter the list of custom fields Bob sees by-default.  This does not mean, however, that he won’t be able to view custom fields assigned to the marketing department.  When Bob saves a project, which fields will he be required to enter values for?  Remember, in Project 2007, Bob would need to input data for all required fields. In Project 2010 since a project, for example, can be associated with a department, Bob may be required to enter a value for the ProjectCustomText5 field AND will always be required to enter a value in the ProjectCustomText2 field since has global scope.

A quick summary of scope shows that departmental fields enable two primary functions:

1. Filtering custom fields so that a user sees by default, only those fields that are either global to the system or those that are in a given department.
2. Controlling which fields require input.

It needs to be stressed the departmental fields are not tied into security.  That is, you cannot use them with security categories and groups to enable or disable fields and their functions.  Instead, their primary purpose is to filter out fields you don’t need to deal with.  There are places in Project Web App (PWA) where you may not be able to see filtered fields and so it may seem like security has been applied, but you’ll find that in places like Project Professional, you can re-filter to show all fields.

Remember this:  it’s about Structure and NOT Security.

Now, let’s look at what it takes to setup and use departmental fields.

Setup

By default, Project Server 2010 has a new lookup table named Department.  Similar to the 2007 State and RBS lookup tables, this is a permanent lookup table (you can’t delete it) that is blank by-default.

Like any other lookup table, you can define the code mask and create a lookup table that’s flat or hierarchical. In addition to the Departments lookup table, by default there’s also the “Project Departments” and “Resource Departments” fields, predefined with the Department lookup table selected (you can’t change this).

These two new fields control a number of aspects within Project Professional and PWA. As with other custom fields associated with lookup tables, you can choose whether or not multiple values can be selected. But, just as with other such fields, once you’ve chosen to allow multiple values, you cannot revert back to single selection.  So be careful in your selection!

You can create other custom enterprise fields and also choose to associate them with departments as shown below.

To help administrators easily determine which fields have been associated with a department, as you can see in the next picture the new Department field has been added to the Enterprise Custom Fields and Lookup Tables page.

In addition to setting up custom fields and associating them with departments, you can also associate users with departments.  Let’s suppose user Bob needs to be a part of the Development and Testing departments.  While editing his user account, you set the departments as seen the next picture.

Remember, setting the user’s department(s) helps to control how custom fields are filtered to them and helps to control which whether some items are seen or not seen in PWA. 

Using Departmental fields

Now that you’ve had a brief overview of creating departments, and associating departments with fields and with users, how do you use them in normal every day usage and what should you expect?   There are a number of Places in Project Professional and PWA where departmental custom fields can be used to your advantage so let’s take a brief look at these.

Project Professional

To understand how departmental custom fields are used in Project Professional, let’s look back to the first example given earlier where there are the two globally scoped project level fields plus two each for the marketing and development departments.  Our user Bob is working in Project Professional and is saving a project.  By default, Bob will see only the globally scoped enterprise project fields similar to the below picture:

Bob sees the two global fields because this project has not been associated with a department. Therefore, when Bob attempts to save the project (and without entering text into the ProjectCustomText2 field), he sees the following message:

Bob then enters a value into the ProjectCustomText2 field and is able to save the project. Bob then goes to the Project Information dialog box and associates the project with the Development department. Now he sees not only the global custom fields, but also two additional fields associated with the Development department.

Take notice that the required fields always appear at the top of the list.

Here you see the addition of both the ProjectCustomText5 and the ProjectCustomText6 fields.  Bob forgets to fill in the required ProjectCustomText5 field and is reminded of this when saving similarly to when he neglected to enter required text into the ProjectCustomText2 field.

Finally, Bob fills in the required field and is able to successfully save his project.  The same concepts can be applied to task level custom fields as well.  For instance, you can assign a department to a task-level custom field and if the project belongs to the department and a field is required, you’ll need to fill in a value for all tasks in the project before you can save it.

Project Web App

There are a few places in PWA where departments affect your experience and an example is when creating new projects based on an enterprise project types (EPT). The administrator who creates the EPTs can specify that they belong to a department.  Therefore, when creating new projects from within the Project Center view, the list of EPTs you see is filtered based on your department.  Likewise, when editing the properties of a project, you will see similar behaviors.  In the following picture, suppose you you are a project manager and you are a member of the marketing department.

Here, you see the “EPT for Marketing Projects” EPT because you are a member of the marketing department. If there are EPTs that have no department association, then they appear in the list as well. However, EPTs associated with other departments do not appear and unlike in Project Professional where you can set the department filter within the Save dialog box, there’s no provision to do so in the Project Center.

Reporting

Project Server 2010 allows you to create multiple OLAP databases for reporting purposes.  When configuring a cube, you can specify both the project and source departments so that the cube is “filtered” on these criteria.  Here is a look at the OLAP Database Build Settings page:

Within the cube 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. Like any other custom field, if the Project or Resource departments fields are defined for multiple values, then they can be used for filtering, but the field itself does not make it into the cube.

Portfolio Analysis

Departmental custom fields are used heavily in Project Server 2010’s portfolio analysis features.  When creating your driver library, you can associate a business driver with a single or multiple departments as shown in the following picture:

In this example, Driver2 has been associated with both the Development and Testing departments.

Similarly, after your business driver library has been established and you want to create the driver prioritizations, when establishing the properties for the prioritization set, you can associate it with a department.

A department on the driver prioritization filters which business drivers are available. In the previous picture, you can see that Driver2 is available because this driver belongs to both the Development and Testing departments.  Obviously, having just one business driver will not produce a good portfolio analysis, but the example suffices.

Summary

This brief overview of departmental custom fields has been given to help you understand the following:

1. Departmental custom fields’ primary function is to trim or filter the list of what a user may see within given areas of Project Professional and PWA.
2. Departments are not meant to act as a security measure. Remember, it’s about Structure and NOT Security.
3. Examples in both Project Professional and PWA where departments are used.

Database, database, database, yes there are plenty of them and guess what you need to maintain them for optimal performance! A MUST read for all farm admin, and I hope you all carefully implement maintenance plans: Database Maintenance for Microsoft SharePoint 2010 Products

This white paper provides information and guidelines for maintaining the databases that host Microsoft® SharePoint® 2010 data and configurations. It describes and provides examples of the database maintenance tasks that we recommend when using SharePoint 2010.

Yes we are currently on updating our Project Server 2010 database guidance as well, in the meantime this is a great starting point: Database maintenance plans for Project Server 2007

A great reminder of best practices I am sure you are all following already! http://technet.microsoft.com/en-us/library/cc973097.aspx

• 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

Service Pack 3 (SP3) for Project and Project Server 2007 are now released and can be found at:

• 2007 Microsoft Office servers Service Pack 3 (SP3) and 2007 Microsoft Office servers Language Pack (SP3) 2526086 ***Update   2526299 (Thanks Andre and Alex for the correction)
• Office Project 2007 Service Pack 3 (SP3) and of Office Project Language Pack 2007 SP3 2526091
• Windows SharePoint Services 3.0 Service Pack 3 (SP3) and of Windows SharePoint Services 3.0 Language Pack SP3 2526305

For full details and more specific link see the Office Sustained Engineering blog at http://blogs.technet.com/b/office_sustained_engineering/archive/2011/10/25/office-2007-and-sharepoint-2007-service-pack-3-availability.aspx

*** Update – just heard there are a couple of issues being investigated with the 2007 Office packages – this affects the MOSS Server package 2596540 (which is the roll up that also includes the Project Server 2007 fix below), and a Project 2007 fix that was specifically  aimed at implementations of Project 2007 and Office 2010 where Visual Reports would not work.  Also corrected the description below from 2010 to 2007 – sorry…  Both of the updates below are unaffected. ***   All affected updates have been re-released 11/1/2011

The October 2011 Cumulative Update for Project and Project Server 2007 can be found at:

• Project Professional 2007
  • http://support.microsoft.com/kb/2596533
• Project Server 2010  2007 
  • http://support.microsoft.com/kb/2596542

A few answers to questions I’m am sure are on the tips of your tongues (as we have all been asking them internally)

• SP3 does not contain the October CU, but contains all fixes up to the August 2011 CU – so to get fully up to date you need to load both SP3 and the October CU. 
• SP3 contains all of the fixes previously released via cumulative updates up to and including the August 2011 CU plus any applicable security fixes released.  If you are up to date with updates and CU’s then SP3 will not be adding anything you don’t already have.
• October CU and SP3 can be loaded in either order – and for the server you could add both before running the configuration wizard.
• You do need to be at least at SP2 to load the October CU – or preferably SP3

Thanks to Rob and Adrian for the information – and Adrian and I (mostly Adrian) will include SP3 in our regular Cumulative Update webcast – 11/8/2011.

Here’s the URL for the 11/8/2011 8:00:00 AM - Information about Microsoft Project and Project Server October 2011 Software Update

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032493962&Culture=en-US

There is a slight delay in the release of the 2010 Cumulative Updates for October 2011 – more information as soon as I have it.