Retrieving the ProjectUID of a workspace using _api REST interface

Project workspaces are awesome. There I have said it. But one thing that has always frustrated me and other users is how hard it is to determine what project the workspace is linked to. The only reliable way of determining the ProjectUID is to look in the Property Bag of the site where Project Server stores the association. There are a couple of tricks that will let you find out the ProjectUID, one of them being developing a custom web part like I did a while back, or using the CSOM in 2013 as Giles Hamson posted a while ago,

But there is an easier way, thanks to the new _api REST interface.

With this new interface you can expose all aspects of the SharePoint site including all the web, site and lists. However the coolest thing is that you can expose values from the Property Bag directly, meaning we can get the ProjectUID of the site with a simple URL call which you can either use in your JavaScript code, or call it directly from a workflow.

The URL looks like this…$select=mspwaprojuid

if you break down there are three components…

_api URL format

The first component is the URL of the site we want to get the ProjectUID from.

The second component is the _api call we wish to make, in this case we are retrieving the AllProperties of the web object.

The third component filters the AllProperties to only retrieve the MSPWAPROJUID property, which is where the ProjectUID is stored.

When you open that url in the browser, you receive the following XML back from SharePoint containing the ProjectUID.

ProjectUID returned

Of course you are not limited to just the ProjectUID, removing the filter component from the URL will retrieve all the properties of the Project site including the URL of the PWA site it is associated with (PWAURL).

All Properties


Removing closed web parts before saving a project workspace template

Recently I have seen this problem manifest itself at two customers, so I thought I would post about it to save anyone else running into it, or scratching their heads. When you customise project workspaces, or SharePoint workspaces in general, you have two options to remove the web parts from the page:

  • Close the web part – this stops the web part being rendered on the page, but still being created on each page load
  • Delete the web part – this removes the web part from the page completely.

By default, when you click on a web part without putting the page into edit mode, the first option presented to the user is to close the web part, but not to delete.

Close Web Part

It is only after you choose to edit the page that you will get an option to delete the web part, either in the context menu,

Delete Web Part - Context Menu

or via the Web Part Tools ribbon.

Delete a web part

So what is the problem you may be asking? Well, in both cases,  to customise the templates the users had simply closed instead of deleting the web parts and then thinking all was good, saved the workspace as a template. When that template was used to create a new site, each of the closed web parts were restored and visible once again, effectively removing the customisations.

Luckily fixing this is pretty simple.

First, we need to gain access to the Web Part Maintenance page which will display all web parts on the page and their associated status. To get there, simply add the following to the URL – ?Contents=1 so…


This will display the web part maintenance page, showing each of the web parts and their associated status.

Web Part Page Maintenance

To delete the closed web parts, simply select the correct items and click on Delete. This will delete the web parts from the page.

Finally, save the site as a template once again and all new sites created with it will reflect your customisations. Of course all of this can be avoided by a simple bit of training to delete instead of close,  but if the web parts have already been closed, this will help you fix it.

File not found error when viewing risks or issues

Every now and again whilst using the Project Server Demo and Evaluation pack, I run into an ‘File Not Found ‘ error when clicking on a risk or issue in a project workspace.

Risk / Issues - File Not Found

On investigation in the ULS logs, the actual error is:

ULS Error - FileNotFoundException

The important part of the error message that gives away what the problem is is the ‘’, which is not the site we are using, but it is the site the workspace is looking at to get the risk or issue form.

Fixing the problem is relatively easy thanks to Project Server’s Bulk Update Project Sites. This capability replaces the WSSSiteRelinker tool that was one of the key tools of a Project Server consultant with the 2007 release. When project workspaces are restored from a different machine it is necessary to repoint them at the new PWA instance under the covers.

To run the Bulk Update Project Sites tool, navigate to Server Settings > Bulk Update Project Sites.  Once in the screen select Previous Site Path (this should be populated with all the relevant options), in our case and Enter the site URL, in our case PWA (not there is no proceeding /, this is added automatically. Then in the new site path, choose the relevant web application, in our case and the site path, PWA.

Update Bulk Project Sites

The really important option is the Update Content Types section that says:

When migrating content to a farm that did not contain Project Server, the content types of Project Issues, Risks, and Documents may be altered such that item links are broken. If you notice that item links are broken after migration, you should update content types.

This is what is causing our error, so it’s important it is checked. Once this is all done, click on Update and let Project Server do its magic. Once it’s completed, I did an iisreset, I am not sure it’s strictly necessary, but I did it anyway.

Finally, all that is required is to test the risk or issue list again…

Risk / Issue - All Fixed

and voila, it’s working again. Of course, as this is your demo image, make sure you backup or snapshot the VM image so you don’t need to fix this again in the future. Now of course this error can also occur in non demo images if you have done a upgrade / migration, in which case all of the above steps still stand.

Showing the Risk or Issue Id’s in the workspace edit and display forms

It’s always puzzled me why Microsoft never did show the ID of a SharePoint based list entry in the edit or display form. What do I mean by that? Well, out of the box, when you create a list in SharePoint, each item has an ID associated. This ID is then used to identify the individual records in the list.  Once you have created an item in the list you can see the ID in the view

Issue ID on the view

But not in the edit or display views of the list item.

Default display formDefault Edit Form

Now this is not unique to Project Server 2010, nor SharePoint 2010 for that matter. The same behaviour can be seen in SharePoint 2007 as well. So why am I telling you all this, well today one of my clients requested that the risks and issues lists on their Project Server instance be modified to show the actual id of the item, making it easier for them to reference and relate to the information they were viewing.

Well, it turns out doing this is pretty easy. Basically all that is needed is to add a content editor web part to the the Display and Edit forms and add a small piece of JavaScript to render the relevant ID. A quick search on the web revealed this article from that provides the code as well as steps to insert the Content Editor web part on a WSS 3.0 / SharePoint 2007 installation.  So I am going to concentrate on what is required to do so for SharePoint 2010.

First navigate to the list you wish to make the change to,  in my case I am using an issues list. In the ribbon choose List and then click on ‘Form Web Parts’.

List Ribbon

Click on the little down arrow and three options will be displayed.

Form Web Parts on Ribbon

We are interested in modifying the Default Display Form and Default Edit Form. There is no point in editing the Default New Form as the ID won’t be available yet to display.

Click on the Default Display Form, the screen will refresh to show the form in edit mode and display the web part zone.

Web Part Zone

Click on the ‘Add a Web Part’. The Web Part gallery will be displayed, select ‘Media and Content’ in the Categories and then the ‘Content Editor’. Click on Add to add it into the web part zone.

Add Content Editor Web Part

Click on the ‘Click here to add new content link’ inside the Content Editor Web Part.

Content Editor : Click here to add new content

Select the Edit HTML Source from the HTML menu.

Edit HTML Source

In the dialog, paste in the code from the PathToSharePoint site into the HTML Source and click on OK.

HTML Source with code

Choose to Stop Editing the Page and then navigate back to an issue and choose to view it, causing the newly updated display form to be used.

New Issue with Issue Id

You’ll notice a new item has appeared on the top line showing the Issue Id.  Now all that’s needed is to repeat the above for the Default Edit Form and your finished. Of course, this will only customise the list of the site you are in. If you want this to be carried through all of your sites, make sure you make the same changes to your Project template site.

Restoring a deleted Project Workspace from SQL Backups

imageThere was a post in the Project forums a few weeks ago from a user asking how to undelete a project workspace that had been deleted accidently. Project Server provides functionality that allows enterprise objects including projects, calendars & resource pools to be backed up and subsequently restored, but this capability does not cover project workspaces. As workspaces are stored within a SharePoint site collection, it is necessary to use SharePoint backup and restore techniques to get the workspace back.

Before we get started, it is essential that you have implemented some form of backup strategy for your Project Server instance. There are a number of excellent documents on Technet to assist including articles on performing Project Server Farm backups via SharePoint or the underlying databases. For the purposes of this post, I am going to assume you have access to a SQL backup of the content database where the project workspace sites reside, which from my experience is the most common method of backing up a Project Server / SharePoint data (but also the least flexible when it comes to restoring configuration and solutions).

1. Mount the database in SQL Server
The first step is to restore the database from the backup onto SQL Server. SQL Server Database Restore

Once this has completed, you should see the backup database attached as per below.

Database restored in SQL Server

As the backup was from the same server, the security on the database should be intact and not need any modification Smile

2. Export the site
Once the database has been mounted within SQL, it is necessary to export the data out of the database into a format that can then be imported back into SharePoint. Thankfully, 2010 introduced a fantastic new feature which allows you to navigate a content database to find the exact site or list you wish to export. Via Central Administration, choose the option ‘Recover data from an unattached content database’.Recover data from an unattached content db

You will be prompted for the database server and name to view and given a list of options including browsing, backing up a site collection or exporting a site or list. In our case, we are interested in exporting a site.

Enter database information

Next up, navigate through the content database, to find the correct site collection and site we want to restore, in this case the site Acquisition Target Analysis. In addition, we need to supply a file name for the site export and advise SharePoint that we want to export the security and all versions in addition.

Central Admin : Site or List Export

Once you click on Start Export, the screen will change to show a job status screen where the status of the export can be viewed.

Export Status

Once the export has been completed, two files will be created the .cmp file that contains the site export and a .export.log file that provides a log of the export process.

3. Import the Site
The final stage in the process is to import the site back into SharePoint, using the Import-SPWeb PowerShell command. Unfortunately Import-SPWeb expects the site that the import is going to be performed on to exist,  which isn’t going to be the case for our previously deleted site, so we need to create a new empty site based on the template.  There are two ways to do this, either via the New-SPWeb PowerShell command or to create a new site via Site Actions > New Site > Microsoft Project Site option.

Create new Project Site

Once the blank site has been created, the site content can finally be imported by running the Import-SPWeb PowerShell command restoring the site back to it’s pre deleted glory with the following parameters:

Import-SPWeb SiteName –Path

You can of course find out more about Import-SPWeb PowerShell command by typing the following into the SharePoint 2010 Management Shell:

Get-help Import-SPWeb –full

Powershell - Import-SPWeb

The last step is to check the site import has worked successfully by reviewing the import.log file and navigating to the site itself and having a look around.

Now of course the most simplest way to restore an accidently deleted site is to stop them getting deleted in the first place, so if this is a problem at your organisation, make sure you spend some time educating your users, or perhaps looking in to implementing a third party site level recycle bin such as the one at