Common errors when a PWA site is deleted ‘incorrectly’

Disclaimer: This post isn’t going to be up to the level of one of Brian Smith’s technical posts and is based on my own experiences and testing. You’re mileage my vary and I encourage you to vigorously test anything detailed in this post before attempting yourself, I accept no liability should you run into issues etc etc.

Recently there have been a number of posts in the project forums from users that have been running into issues when they have deleted a PWA instance incorrectly. Now what do I mean by incorrectly? Well, by deleting the PWA instance any way other than via the Project Server Service Application > Delete Instance.

So to start, what are the errors you can run into?

The Project Web App Path Site is invalid. Correct path and try again.

The most obvious error is not being able to create a new PWA instance with the name of an instance you had previously deleted incorrectly, even though the Project Server Service Application is showing that particular instance does not exist. From my experimenting this can occur if the PWA site collection is deleted from the ContentDB manually (in the example below, the PWA2 site collection).

The Project Web App Site Path is invalid. Correct path and try again

Note this error will also be seen if you are legitimately trying to create a PWA instance with a duplicate path.

Event 7626  – Cannot start queue

The second common error is a number of Event 7626 in the Event viewer indicating the queue’s (both Project and Timesheet) cannot be started. Again, this was seen when the /PWA2 site collection was manually deleted.

Event 7626 : Cannot start queue

The exact errors you may see (for the search engines) are:

Cannot start queue. SSP: <Guid> SiteUID: <Guid> Url: Queue: ProjectQ

Cannot start queue. SSP: <Guid> SiteUID: <Guid> Url: Queue: TimesheetQ

The database specified is already used by another project server. Enter a different server or database name and try again.

This error can occur if the user deletes the ContentDB hosting the PWA site collection and no other PWA instances exist using those Project databases. As you would imagine, you can also see this error if a legitimate PWA site is using those databases, so make sure you are certain.

The database specified is already used by another project server

So how to fix it?

The easiest fix is to restore the deleted site collection or contentdb from a backup, and then delete the site correctly via the Project Server Service Application.

If you don’t have backups then you are going to need to remove the left over configuration manually, using some PowerShell as outlined below.

1. Find the Project Server Service Application

The first command below will bring back all service applications where the TypeName contains the word Project and assigns them into an object called $serviceapp:

$serviceapp = get-spserviceapplication | ? {$_.TypeName –like “*Project*”}

Powershell - get-spserviceapplication

The second command takes the object and then formats the output as seen above. If you don’t see anything returned, then there are either no Project Server Service Application configured, or you may have typed the command wrong.

2. View the Site Collection Properties

Now that the $serviceapp object contains the service application instance, the next thing we want to do is see the site collections associated with it.  To do this, type the following:

$pwainstances = $serviceapp.Sitecollection


This will find the various site collections associated with the instance:

Powershell - Instances in site collection

In this case, there are two instances associated with the Project Server Service Application, the good /PWA one and the incorrectly deleted /PWA2 one.  Notice even though the underlying site collection has been deleted, SharePoint still thinks its there in the configuration.

3. Remove the configuration for the incorrectly deleted instance

To remove the configuration of the /PWA2 site, enter the following:

$toberemoved = $pwainstances | ? {$_.Id –eq “<Id of the instance to delete>”}


Powershell - Select individual instance

The second $toberemoved shows that the object contains the PWA2 instance that is to be removed. To perform the actual removal, enter:


Finally, perform a check to make sure the instance was deleted as follows:

Powershell - Delete site collection

If all went well, the object $toberemoved should be empty meaning the configuration within SharePoint has been removed and you should be free to go and create your PWA site again without error.


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