In this article I am going to describe specific scenarios when moving databases to a different Project 2010 server which was not successful and hence you need to clean up the existing connections and re-provision the project web applications.

You can refer to the 'Move all databases to a different server (Project Server 2010)' if you are attempting FOR THE FIRST TIME to move the databases associated with a Project Web App (PWA). Here is the link

Setting the scene

You are in a migration where in phase one you built a new SharePoint / Project 2010 farm from scratch and moved the ProjectServer_Archive, ProjectServer_Draft, ProjectServer_Published, ProjectServer_Reporting and your PWA's Content database (DB). These content database have all the subsites that are connected to each project.
Now you have decided on a go live date and now need to update your databases with the latest data. Either you or the DB department has updated your databases. You are able to access the root site of your web application, however, you are not able to access the PWA. This article will describe how you can first attempt to re-establish the connections and if that doesn't work how to rebuild it.
Also, in these scenarios, the root site's URL DOES NOT include the web application server. The default URL was changed.

Scenario #1

You got confirmation that the updated databases have been imported on your SQL server. You are able to access the Root site of your web application successfully, however, when you access the PWA you get a 'The webpage cannot be found' which is an HTTP 404 Not Found error.

In this scenario you can attempt to access the Admin page of this PWA by adding the following URL to your PWA
Are you able to access these sites? If not then do you get an error with a correlation ID?

When you find the correlation ID, look it up in the ULS log. It is possible that you might see the following. If you do GREAT!! Because we can FIX THAT!!

Warning Alternate access mappings have not been configured. Users or services are accessing the site http://CustomProjectSiteURL:2010 with the URL http://ProjectServer:2010. This may cause incorrect links to be stored or returned to users.

What the above error is telling you is that the Alternate Access Mapping (AAM) links aren't working hence you need to change it back for the original URL that you first used while setting up the web app.

Here are the steps to resolve that issue.
• Log into Central Administration (CA)

• Go to Application Management and under Service Applications click on Manage Service Applications.

• Click on your Project Server PSI Service Application. You might have it named differently, for example, I have mine named as Project Web App as shown below: 

• Click on the drop down arrow next to the PWA and select Delete as shown below:

• This is the KEY STEP. UNCHECK THE 'DELETE SITE COLLECTION FROM SHAREPPOINT' option. If you don't then you will lose the content database that holds all the subsites for each project on your PWA.

Once the PWA is un-provisioned (aka deleted). You want to confirm that the service timers have run for all your application and web front end servers.

• The Timer is available at CA>Monitoring>Timer Jobs>Review job definitions. You should now be in the Job Definitions page. Click on the Job History option under Timer Links and confirm that the following highlighted timers have run on all your servers.

• Now go to your CA, under System Settings click on Configure Alternate Access Mappings. On the top right next to 'Alternate Access Mapping Collection click on Show All and then click on Change Alternate Access Mapping Collection. Now choose your Web application.

• Click on Edit Public URLs and change the URL. Again, confirm that all the timer jobs have run successfully.

• Go back to the Project Web App and click on 'Create Project Web App site'. Confirm that you have the exact same SharePoint Web App, Project Web App, Primary Database names and the Reporting Database names. Click Ok and wait for the PWA to be provisioned.

• Once it is provisioned go back to the Time Jobs page and confirm that all the jobs have run.

• Now access the root site and then PWA site and confirm that you can access them.

Scenario #2

In this scenario the root site, PWA and the respective sub-sites have migrated over "successfully". You are able to click and on each and every project and sites and able to access them. However, you hear back from the end users that they are getting an Access-Denied when they attempt to access their own projects which was built in the previous environment. The reason this occurs is because the Microsoft Project Server security groups that migrated over are blank.

As an example, the Project Managers Group (Microsoft Project Server) is a security group for Project server. This group was populated with end users in the previous environment, however after the migration this group was empty. To confirm the current status of your group got to Site Actions>Site Permissions and location your Microsoft Project Server group.
Below is a screenshot of the example group:

There is a very simple way to resolve this issue. On your PWA under Resources click on Resource Center. Below is a screenshot:

You will see a list of all the users, select the users who are experiencing this issue and click on Edit Resource. Below is a screenshot:

Confirm the current status of the user. For example, if you know certain users have left the company then uncheck the 'Resource can logon to the Project Server'. Below is a screenshot:

Click the Save and Continue button as shown below:

Go through this process for all the users you selected.

Once this is completed go back to your PWA home page and click on the Server Settings as shown below:

Under Queue select Manage Queue Jobs. This is where you will see the user accounts are waiting to be processed. Once the queue is empty go back to the Project Managers Group mentioned above. Now you should see the users populated there. Now all the end users can access their respective projects.

Scenario #3

This scenario occurs when you are re-creating your PWA (as described in scenario #1), however, you get the errors as shown below. This means that previously deleted PWA still exists but is orphaned and hence your have to use a series of power shell commands.

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

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

The second command takes the variable 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.

Now that the $serviceapp variable 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:

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.

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

$toberemoved = $pwainstances | ? {$_.Id –eq “78c7158a-5a22-44c3-8fb8-fd41d84db4aa”}

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:" [Alexander Burton, 2011]

Now that the orphaned PWA has been deleted you can continue the steps described in scenario #1 and rebuild the new PWA using the existing databases.

Scenario #4

In this scenario you have completed migrating , however, you DO NOT see the sub-sites as you did in the previous environment. The primary reason for this issue is the breakdown of the sites in the content databases. It is best practice TO NOT make any changes to the sub-sites' location in their respective content databases while the migration is going on. In other words, keep the environment breakdown of the sites in the content databases the same while they migrating over. Once the migration is completed make the changes.

In this scenario, as shown below, we had a the root site on the WSS_Root_ContentDB and we had all the PWA which contains all the subsites in the WSS_Content_ProjectServer content database.

We want to maintain the same breakdown of sites in our new farm. Assuming that your new farm is either using a new SQL server or a new SQL instance I recommend using the same database name for your SharePoint web app. For example, WSS_Root_Content was the database name for the SharePoint web app in the old farm and I have used the same name in the new farm. THIS IS BY NO MEANS IS A REQUIREMENT BUT HELPS TO MAINTAIN CONSISTENCY.
Now BEFORE BUILDING THE PWA add the content database that was migrated, in this example, the content database name is WSS_Content_ProjectServer. Now go ahead and build the PWA. Another way to confirm that you sites' breakdown in your new farm is the same as the previous farm is to go to your Central Administration>Application Management>Site Collections>View all site collections: 

Click on the 'Change Web Application' to the correct one. Below is a screenshot: 

As show below you should see all your sites. Click on each of the sites and to view the respective database name and confirm that it matches the previous farm.

Now you should see all your sub-sites in your PWA.


If neither one of the above 4 scenarios resolve your issue then I recommend that you rebuild the PWA. When doing so it is important that you delete the sections in their proper order. You need to delete the PWA first and then the web application. Deleting the PWA will delete the content database that contains the sub-sites hence make sure you have a backup copy of the database.