Project Server 2010 to 2013 Migration Reference Sheet

Following on from the last few upgrade and migration posts, I thought I would pull together a simple reference sheet that takes you through the migration process from Project Server 2010 to Project Server 2013.

Project Server 2010 to 2013 Migration Reference Sheet

The sheet takes you through the key steps and commands required to migrate between Project Server 2010 and Project Server 2013.

The reference sheet can be downloaded from http://sdrv.ms/12qUa8M or by clicking on the picture above.

Advertisements

Some common errors when upgrading / migrating to Project Server 2013

The process of upgrading from Project Server 2010 to Project Server 2013, or migrating between environments can be quite complex, requiring a number of steps to be completed in the correct order. In this post, I am going to document some of the common and uncommon errors that you may run into. I also intend to update this post as I uncover more.

Unmounted Project Service Database

Unlike SharePoint Content databases, Project Service databases need to be mounted before you can run a Test against them. If you do not mount them, you will see the following error.

Test-SPProjectDatabase : Could not find the ProjectDatabase instance (looking for database name: ‘ProjectWebApp’, service name: ‘demo2013’)

Test-SPProjectDatabase: Could not find the ProjectDatabase instance

To rectify this issue, make sure you mount the Project Database prior using

Mount-SPProjectDatabase –Name <ProjectServiceDatabaseName> –WebApplication <WebApplicationURL>

ConvertTo-SPProjectDatabase returns a ‘There are no addresses available for this application’ error.

The ConvertTo-SPProjectDatabase is used during an upgrade to convert the four Project Server 2010 databases (Draft, Published, Archive and Reporting) into one consolidated Project Service database with the different schemas.

ConvertTo-SPProjectDatabase returns a 'There are no addresses avaialble for this application' error

You will see the ‘There are no addresses available for this application’ error if you try and run this command and the Project Service App is not started. To rectify this, navigate to Central Administration and ensure the Project Service App is started and recycle the box, then try again.

Compilation Error – Microsoft.Office.Project.PWA.IDS does not contain a definition for ‘Licence_Copyright_Text’

You may run across this error message when navigating to a PWA instance that originated in Project Server 2010.

Compilation Error – Microsoft.Office.Project.PWA.IDS does not contain a definition for ‘Licence_Copyright_Text’

Compilation Error – Microsoft.Office.Project.PWA.IDS does not contain a definition for ‘Licence_Copyright_Text’

This error occurs when a 2010 PWA site has been mounted but the PWA site wasn’t upgraded using the following command:

Upgrade-SPSite -Identity <PWA URL> -VersionUpgrade

The PWA Settings option is missing from the Site Settings Menu

In Project Server 2013, the Server Settings menu item has been replaced by a PWA Settings option on the Site Settings menu. When performing an upgrade from Project Server 2010, this menu option is not automatically added when using the DB Attach method via PowerShell.

In the screenshot below you can see that the upgrade has been completed successfully, but the PWA Settings option is missing.

PWA Setting menu option not available

To fix this error, ensure you enter the following PowerShell command:

Enable-SPFeature –Identity pwasite –URL <URL of PWA site>

This will enable the pwasite feature which provides the PWA Setting menu link.

Introducing the365project.net

Welcome to the365project.netWith the introduction of Office 2013 and the arrival of Project Online in Office 365 I thought it would be a good time to try and bring some members of the Project and SharePoint community together to launch a new community site. So it is my great pleasure to introduce the365project.net.

Welcome to the365project.net

What is the365project.net? Well it’s a new tips and tricks site for the  Project, Project Server and SharePoint, covering the existing versions and the new 2013 wave of products. As the name suggests the content will also cover some parts of Office 365, Microsoft cloud based solution that provides SharePoint and the 2013 offering has finally been joined with a dedicated Project Server offering called Project Online.

We have been lucky enough to attract authors from all over the world including SharePoint Masters, Community Contributors, MVPs Microsoft staff and other well respected experts with tips for all audiences including End User, IT Pro, Consultants & Developers. Of course we are always looking for new authors and tips, so if there is a tip you would like to share with the community, please submit it through the submit a tip link and we’ll be in touch.

We hope to be posting 2-3 original posts a week over on the site, so make sure you add it to your favourite RSS aggregator, Twitter account (@365prj) or just plain old favourites.

Collecting business requests in SharePoint and automatically pushing into Project Server

At SharePoint Saturday Toronto, I presented one of my favourite sessions on SharePoint Governance and Lifecycle Management using Project Server 2010, based on Christophe Fiessinger’s and Scott Jamison’s session from TechEd NA 2011. I’ve delivered this session three or four times now, showing how organisations can benefit from using Project Server to collect business requests and guiding them through a process to successfully collect information, objectively determine which project to implement and then assist in the implementation.

Each time I have delivered the session, I have been asked if there were ways to collect the initial business requests outside of Project Server, in a SharePoint list for instance, reducing the need to licence and more importantly train all users within an organisation that may wish to lodge a business request. So, for SharePoint Saturday Toronto I decided to implement an interface that allows the business requests to be created initially in a SharePoint list and then via a workflow pumped into Project Server for the Project Server governance process to be applied.

image

 

This post shows you how you can implement it too. For this example, I will be using Nintex for the workflow component (disclosure, I work for Nintex), but you could also use a SharePoint Designer built workflow with the Christian Glessner’s iLSP SharePoint Designer Add-ons and a little elbow grease.

At a high level the solution has three components:

  • A SharePoint list that will be used to capture the business request. The list should be configured to capture the relevant items for the business request. In this example, the list requests the project name and a description, but you could extend this to capture other information such as anticipated budget, business need etc;
  • A default Enterprise Project Type configured to use the SharePoint Governance and Lifecycle Management demand management workflow. This EPT should also have a default Project schedule template associated; and
  • A list workflow associated with the SharePoint list above that will be used to call the PSI to create the project.

 

The list

Configure a SharePoint list to capture the information you want to capture. In this example, I have only captured two fields, as the rest will be captured within Project Server.

Both fields are set to be mandatory and the title field has been set to enforce unique values.

SharePoint list columns

 

The EPT

The Governance and Lifecycle Management white paper and databases guide you through the process of configuring a demand management workflow and EPT. For the list workflow to create a project automatically, it is essential to make sure this EPT is set as the ‘default’ and that a Project schedule template has been uploaded and associated with the EPT.

Before building the workflow, we need to know some information about the project schedule template, this will be used by the workflow to create the project. Each project template is stored within the DRAFT Project Server database and can be extracted with the following query:

SELECT PROJ_NAME, PROJ_UID FROM MSP_PROJECTS WHERE PROJ_TYPE = 1

Write down the PROJ_UID of the relevant record for the Project Template you associated with the default EPT.

 

The Workflow

The key component of the process is the workflow that will take the list item and create a project in Project Server. As I mentioned above, in this example I will use Nintex Workflow & Nintex Workflow for Project Server as it has Project Server specific actions, but you can achieve a similar outcome in SPD with a little more effort.

The workflow itself consists of only three actions, the first action ‘Call Web Service’ is used to call Project Server’s PSI and specifically the Project web service and the CreateProjectFromTemplate web method. This method creates a project within Project Server based on a specific project schedule template.

The action should be configured as below, ensuring you change the URL of the web service, credentials and Template GUID to match your environment.

Configure Call Web Service Action

The projectName field above is using the Title variable. A great thing about Nintex is that you have access to the list context information by clicking on the lookup icon as below:

Select item title

The final part of the configuration is to capture the UID of the project that is created. When CreateProjectFromTemplate is called, if the method is successful it will return the UID of the created project in an XML envelope.

The Call Web Service action can listen for the response and parse it. To do so, click on Specify Elements and then Select Element.

Web Service Output

A XML browser dialog will be displayed allowing you to select which item in the response to read, in this case we are interested in the CreateProjectFromTemplateResult, so select it and click on Apply.

Web Service Response

Choose to save the returned value into a variable called ProjectUID, this will be used later.

The second action is also a Call Web Service action, this time used to Publish the Project in Project Server, up until now our project has resided in the Draft database, performing this publish will make sure it is published and therefore visible in PWA.

Like the previous action, configure the web service to call the Project PSI server with the relevant URL and credentials.

Publish Project

For this action, choose the QueuePublish method. This method has different parameter requirements:

  • jobUid – A GUID used to identify the job, in this case use the inline function fn-NewGuid()
  • projectUID – the UID captured in the ProjectUID variable prior
  • fullPublish – true
  • WssURL – leave blank

Once these two actions are run, a project will be created in Project Server using the default EPT and schedule template, all that is needed to do is to copy the other fields from the list into the project custom field using the last action ‘Update Project Properties’ from Nintex Workflow for Project Server that provides a simple wrapper for updating project custom fields. If you decide to use SPD, you would need to perform a raw PSI call to update the property making sure you have created a valid XML message (Fiddler will be your friend here, but a word of warning, it is not simple).

Configure the action as shown below, ensuring you select Title from the lookup field for the Project Name and then choosing to update the WPROJ_DESCRIPTION field with a list lookup against our SharePoint list, the item we are starting the workflow against (our project idea) and relevant field (in this case the Project Description field).

Update Project Properties

If there were other fields you wished to push into Project Server, they can be chosen in the Project Property drop down.

Finally, configure the action to ‘Publish after update’ and to ‘Wait for job completion’.

The completed workflow should look like this:

Completed workflow

All that is needed to complete the workflow is to modify the workflow settings to allow it to be manually started, and to add it to the list item context menu as follows:

Configure workflow settings

Then publish the workflow and you’re ready to start pushing your project ideas from a SharePoint list into Project Server Smile

Of course, what I have shown you above is the tip of the iceberg, with a little more work you could:

  • extend the workflow to add in some approvals before the business request is pushed into Project Server, allowing people like team leads or managers that may not necessarily need access to Project Server to review, add additional information and approve or reject the request;
  • configure the demand management workflow to push updates about where the business request is back out to the SharePoint list; and
  • add additional fields to the list that are pushed through into Project Server custom fields at project creation time.

Building advanced Project Server workflows with Nintex Workflow for Project Server

Last week I was lucky enough to be interviewed by Dux Raymond Sy about my upcoming session at the Microsoft Project Conference which I will be presenting with Mark McDermott of Nintex. Mark and I have been busy putting the final touches to the presentation and demonstrations and have a really great session planned.

Our session is on Thursday 22nd March at 10:30am in room North 222 C. If can’t make it, or even if you can, make sure you follow the twitter hash tags #pc332 and #mspc12 to keep up with the action.

Hiding & Disabling ribbon items in Project Server, Part II

In the last post, we covered a few things you will need to know when hiding or disabling ribbon buttons in PWA. In this post we will look at how to actually hide the buttons.

Where to start?

Irrespective of whether you wish to hide or disable a button in the ribbon, you will need to follow the same basic process by building a solution in Visual Studio that will deploy your ribbon customisation.

To start, open up Visual Studio and choose to create an Empty SharePoint Project.

Create Empty SharePoint Project

Enter a name and then click on OK. You will then see the SharePoint Customisation Wizard, enter the local site you wish to use for debugging and choose to ‘Deploy as a sandboxed solution’.
SharePoint Customisation Wizard

On clicking finish, Visual Studio will create a solution ready to be customised.

To start with we need to create a feature,  this is a logical container for our customisation and allows the user to turn on and off the customisation by activating and deactivating the feature. To do so, right click on Features in the solution explorer and choose Add Feature.

Add Feature

A feature will be created and Visual Studio will show a page where you can enter information about the feature such as the name, description and the scope. In this case we are going to choose Web (for an individual site) as we want this change to deploy only to the /PWA site and not all the children sites.

Hidebutton Feature

Next we want to add an element to the solution, this is where the real work is done and contains the XML that will be used to configure our ribbon.

To add an element, right click on the project name, choose Add, New Item

Add New Item

In the dialog that is displayed, scroll down and select Empty Element and give it a name.

Add Element

Once you click add, the element will be created.

Blank Element

Now the empty element is created, all that is needed is to add the relevant XML to either disable or remove the button.

Disabling a button

For this example, we shall be disabling the EPT Change button from the Project Centre ribbon. To do so we need to know the ID of the item as defined in the ribbon so we can build up some XML that defines what we want to do to that item. To find the ID, we need to look through the PWARibbon.xml file, which can be a bit daunting, but after a while you will understand the structure and finding the Id’s will become simple.

SharePoint ribbon customisations use a defined XML schema which describes the structure and behaviour of the ribbon and the items that make it up. In order to disable the EPT Change button, we need to override the current structure and behaviour to change the configuration of what the button will do, in this case, pointing to a command that doesn’t exist.  In doing so, the ribbon will disable the button for us, giving us the desired effect.

To get the various attributes of the button, the PWARibbon.XML is your friend, containing all the configuration information you will need. In this case I have taken the configuration of the button and changed the command to point at a non existent command, which will cause the button to be disabled. This XML then needs to be put in the Element.xml file ready to be built, but more on that later.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction
			Id="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change"
			Location="CommandUI.Ribbon"
			Title="Disables the EPT Change button in the Project Center Ribbon">
		<CommandUIExtension>
			<CommandUIDefinitions>
				<CommandUIDefinition Location="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change">
					<Button
						Id="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change"
						Command="ChangeReplacement"
						Sequence="10"
						Image16by16="/_layouts/$Resources:core,Language;/images/ps16x16.png"
						Image16by16Top="-112"
						Image16by16Left="-190"
						Image32by32="/_layouts/$Resources:core,Language;/images/ps32x32.png"
						Image32by32Top="-352"
						Image32by32Left="-96"
						LabelText="$Resources:pwafeatures,WEBPARTS_PROJECTCENTERPART_CM_CHANGE"
						TemplateAlias="o1"
						ToolTipTitle="$Resources:pwafeatures,PAGE_PDP_CM_CHANGE_WORKFLOW"
						ToolTipDescription="$Resources:pwafeatures,SUPER_TOOLTIP_CHANGE_PROJECT_TYPE"
						/>
				</CommandUIDefinition>
			</CommandUIDefinitions>
		</CommandUIExtension>
	</CustomAction>
</Elements>

Removing a button

The XML code required to remove a button is simpler. Instead of defining the XML for the whole button, all that is required is to redefine the CommandUIDefinition as per below.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction
			Id="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change"
			Location="CommandUI.Ribbon">
		<CommandUIExtension>
			<CommandUIDefinitions>
				<CommandUIDefinition Location="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change" />
			</CommandUIDefinitions>
		</CommandUIExtension>
	</CustomAction>
</Elements>

When PWA parses the XML it uses this to remove the button as key items are not defined. Once again, all that is required to remove the button is to move this XML into the Elements.XML file and save ready for building.

In both cases, if you wish to hide or disable more than one button, you will need to duplicate the Custom Action mark up and change as necessary for each button.

How to Build

Finally once the configuration is completed, all that is required is to build and deploy the solution. To do so, right click on the project name and choose build, if everything is ok, you should see something similar to this in the build output:

Build Succeeded

If the build fails, then there may be a problem in your code. I have packaged the code up I used to build this post into a zip file which is available from my Skydrive account so you can compare or copy.

Once the build is successful you can deploy the solution by right clicking on the solution name and choosing deploy. VS 2010 will then deploy the solution to the site you entered for debugging and activate the solution in the site collection.

Activate Feature

Once the solution has been activated, you should see the changes to the ribbon in Project Center.

As you can see from above, creating a custom feature to hide or disabling buttons in the ribbon is relatively simple once you have the basic structure in place. Hopefully this post has explained how to build these customisations for use in your next project or internal implementation.

Hiding & Disabling ribbon items in Project Server, Part I

Recently I have been working on a number of projects where the requirement to disable ribbon commands in Project Server has come up again and again. There are a couple of posts out there around modifying the ribbon, but they tend to focus on adding new items, not removing or disabling them, so I thought I would post something covering it. Of course, before you look at disabling the ribbon item through a customisation, you should look to see if the item can be disabled using the Project Server security model first.

What you need to know about the ribbon

If you are going to do any work on the ribbon, you need to be aware of a couple of things, firstly for performance reasons the ribbon is cached client side, which makes it really really painful to work with as your changes may not be visible straight away. To get around this, I found using the InPrivate mode of Internet Explorer stopped the client side caching and ensured my ribbon changes were visible.

Secondly, if you are going to hide or disable a ribbon item you need to know the ID of the item. Both SharePoint and Project Server have xml configuration files that define the structure of the ribbons, for SharePoint the ribbon structure is defined in a number of files, but the main one is CMDUI.XML located in {SharePointRoot}TEMPLATE\GLOBAL\XML\CMDUI.XML. For Project Server, the ribbon definitions are kept in the PWACONFIG.XML file located in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\PWARibbon\listtemplates. The file itself contains the configuration of each button within the PWA app, including the name, image, command to be fired when clicked and references to the tooltips etc.

Example of PWACONFIG.XML

Finally, in the case of Project Server, you need to make sure you find the correct Id, things like the Timesheet ribbon have different id’s depending on whether the timesheet is running in Single Entry Mode, or normal timesheet mode.

To disable or hide? That is the question…

There are two schools of thought when disabling commands in SharePoint and therefore Project Server, to disable or hide the buttons. Hiding the buttons will remove the button completely from the ribbon, whereas disabling the button will leave the button on the ribbon, but in a state that cannot be clicked, thus stopping the functionality the item provides.

Normal Normal Ribbon
Disabled Disabled button on ribbon
Hidden Hidden button on ribbon

 

As you can see from above, the disabling route will be less confusing and will lead to a more consistent user experience for end users, but there are still situations where hiding might be the best route to go (I have a couple of customers that preferred hiding to disabling).

In the next post, we will look at how hide and disable a button using Visual Studio and some SharePoint features.