Project Server 2010: Restoring or Migrating PWA Instances


Just a quick posting on this topic pointing out a few of the changes between 2007 and 2010.  We have some documents already up on TechNet – under the Operations section at http://technet.microsoft.com/en-us/library/cc197578.aspx, but thought this would be a useful posting to make clear what you can and cannot do.

In 2007 you could restore your 4 Project Server databases, then point your provision job at these 4 and you’d have a new PWA instance using those DBs.  If you wanted your workspaces too then you’d need to copy the sites or if you’d had the forethought to use a different web application for sites then it could be even easier.

In 2010 we introduce the 5 dB restore –so you can now restore your Content database containing your PWA site (and potentially all your Project sites (workspaces,in 2007 speak), and your 4 Project Server databases, attach the Content DB to a web application and then you can provision and it will use this PWA site and the databases – rather than complaining that the /PWA site already exists – which was the case in 2007.  So this is excellent – and makes it much easier to move a complete copy of the instance around. 

However, there are some gotchas:

You cannot change the name of the site – but you could restore to a different web application (port) to avoid a clash if you needed to pull /PWA from one server to another server where /PWA already existed

If you change domains you might have some unexpected results – This is due to differences in accounts in different domains, and will be even more unusual if you happen to use a different farm admin from the Project admin (which would be best practice, but in a dev/test/support scenario might not be the case.  The issue here is that attaching the content DB will add the farm admin as the site administrator, but will not add the Project admin when you provision the site.  So you have a great Catch 22. Once you provision the PWA instance the Project admin will get an access denied on /PWA as he has no rights to the site.  Farm Admin will get Access Denied (or might be unexpected error) as he is not a project server user.  Simple solution is to navigate to http://servername/pwa/-layouts/user.aspx as the Farm Admin and then give the Project admin rights.  Once you can connect as Project Admin then you can update users credentials as necessary.

4 DB restores will NOT work – it looks like it has worked, but if you try to drill in to a project you will see a message “Unable to open Project, no valid Project Detail Page could be found for the project.”  The Project Detail Pages (PDPs) are stored in the Content DB – if you don’t; restore the Content DB then you don’t have them and cannot get to existing Projects through Project Center.  You can however still access via Project Professional, so in some support or disaster recovery scenarios this might be good enough – just to get access to projects while the full recovery happens somewhere else.

You may need to use the WSS site re-linker tool – now built in to Server Settings in PWA as “Bulk Update Project Sites”.  If you have changed URL die to a different port then re-linking should get your sites in order. In upgrade scenarios the “Previous Site Path” Web application might show as a GUID in the drop down – however it still works and will re-link the sites.

Cannot attach Content DB via the Central Administration UI – This is handled with very good error messages and will tell you to use stsadm if it needs to upgrade the content database due to differences of versions.  You could also use the PowerShell command – mount-SPContentDatabase. The correct syntax of the stsadm command is:

stsadm –o addcontentdb –url “http;//servername:port/ –databasename Content_DB_Name

Partial Restores using Full Farm Backup are not supported.  From the UI it looks as though you should be able to select just a PWA instance and backup stuff and then restore from this backup to another farm.  This isn’t supported.  it will only work when restoring to the same farm and the same named /PWA site.  I guess it could be used as a means of restoring the required databases, but you would still need to provision a site on the target server against the databases to get anything to work.

I am sure we will find more gotchas as we go along, and perhaps even some workarounds to recover from certain issues – but that’s all for now.  Let me know of anything you feel should be added.  I will probably do a more “step by step” posting with a few more details – but the TechNet articles cover those kind of details pretty well.

Technorati Tags: ,
Comments (9)

  1. Christoph Muelder says:

    Hello Brian,

    workaround for the 4DB restore problem:

    – create new pwa site /newpwa with empty databases

    – delete pwa site /newpwa, remove option to also delete the site collection

    – create new pwa site /newpwa with the 4 databases

    Regards

    Christoph

  2. Hi Christoph,

    Yes, I can see this might work slightly better, but only if your PWA was unchanged from the original.  If you had added Enterprise Project Types (EPT) and new Project Details Pages (PDP) then you would still have the same issues as mentioned above.  Also as this probably wasn't a tested scenario this would stray into the realms of unsupported – but as a disaster recovery step this may not be an issue.  I think I'll give it a try…

    Best regards,

    Brian.

  3. Nico Oosthuysen says:

    Hi Brian,

    thank you very much for this information – it really is very valuable, and I am very glad to see that we can now recover SharePoint content as well!  Very great news, thanks again!

    Nico

  4. Relinking WSS sites says:

    I am getting error while doing a relink as it shows the site does not exist on new site, Why is it trying to find the new site to have the old workspaces, Could we get a better understanding of the background process, Here is the error :

    General

    Web does not exist:

    WSSWebDoesNotExist (16405). Details: id='16405' name='WSSWebDoesNotExist' uid='8fd17187-b880-40f3-a1ef-bf342649b272' projectUID='fb78cea5-d5de-46a3-ac4e-486cb1c9423e' wssFullUrl='http://rcm-upgrade2010:800/PWA/CBIZ'.

    Queue:

    GeneralQueueJobFailed (26000) – UpdateProjectSitePath.UpdateProjectSitePathMessage. Details: id='26000' name='GeneralQueueJobFailed' uid='a79dd2fe-4dc6-4ab8-a92f-d116cc80c354' JobUID='939bc9c2-e315-4390-9484-47cd7a23769d' ComputerName='RCM-UPGRADE2010' GroupType='UpdateProjectSitePath' MessageType='UpdateProjectSitePathMessage' MessageId='1' Stage=''. For more details, check the ULS logs on machine RCM-UPGRADE2010 for entries with JobUID 939bc9c2-e315-4390-9484-47cd7a23769d.

  5. Megha says:

    Hi Brian,

    Thanks for the information.

    How does restoring a PWA site hosted on root site work. ie., if we have site created selecting "Use Project Web App path as host header", will have the issue you have listed here – "You cannot change the name of the site"

    Regards

    Megha

  6. Hi Megha, I've never needed to do this with host headers in place.  What is the purpose of the restore?  Could you use a different port and the same name?  You certainly couldn't do this in the same farm anyway – you couldn't have the content DB restored twice.  You may be able to restore without host header use depending on how the site is referenced in the content DB – that is the key piece – that whatever you provision must re-use the site in the content DB that was used before.

    Best regards,

    Brian.

  7. Megha says:

    Hi Brian,

    We are intending to migrate from the existing servers to new infrastructure.

    I wanted to try migrating to the dev environment from QA to do the testing of migration.

    Content DB has the same name as the PWA path provided while creating PWA. So that means I have to use same name while I restore.

  8. Didier Maignan says:

    Hi SuperBrian,

    Considering the 1 DB PWA instead of 4 , Is this articla 100% applicable for Project Server 2013 ON Premise too ?

    Thx again for all your good work

Skip to main content