Tutorial: Migrating Microsoft Sharepoint Project Server to a different URL

29 Nov

So at the moment we’re completing a project that included migrating an existing Microsoft Sharepoint Project Server environment implementation to a different server environment with a different URL. Our goal was to get rid of the /pwa part and create an http://projects.domain.local/businessunit URL. We have read a lot about this on the internet. A lot of peope saying it’s not advised to do so, it cannot be done etc. etc. No straightforward manual how to accomplish this. Even our consulting partner said it couldn’t be done.

So in this article I’m writing how it can be done and which errors we faced. You do need Sharepoint and Project Server knowledge cause I will not include screenshots etc. If you start using this article I’m assuming you have the knowledge to create a content database and add a managed path.

SETUP

A little insight in our environment. We have an existing projectserver installation running under the http://server1/pwa URL. The sql server on the same machine contains the reporting, draft, published, archive and also the PWA_Content database. On the target environment we have server2 running the same or a newer (NOT older) version of Sharepoint and Project Server. In our case our Sharepoint Config database is running in the default SQL instance on a different machine. A seperate SQL instance is created on the same machine for our Project Server environment: sql1.domain.local\projects,4567 (the latter is the portnumber). We already have a webapp running another Project Server implementation (name of the webapp: projects.domain.local). We also have an existing content database for another Project Server implementation and want to be sure that every PWA implementation has his own content datbase. Let’s start.

ORPHANED SITECOLLECTIONS

We did a lot of trial and error on our testenvironment. This created some orphaned sitecollections which we needed removed first. Below you’ll find the powershell script we used to delete them. In a clean environment you do not need to complete this step.

Check for orphaned sitecollections
$serviceapp = get-spserviceapplication | ? {$_.TypeName –like “*Project*”}
$pwainstances = $serviceapp.Sitecollection
$pwainstances

Delete them
$toberemoved = $pwainstances | ? {$_.Id –eq “1eb13e72xxxxxxxxxx”}
$toberemoved = $pwainstances | ? {$_.Id –eq “d4ee2a32-xxxxxxxxx”}
$toberemoved.Delete()

MIGRATING THE ENVIRONMENT

So now the fun part. Let’s start migrating. You need to create a full backup of the projectserver databases of the source environment. So the reporting, draft, published, archive and also the PWA_Content database. Restore the databases on the target SQL server. Make sure the Sharepoint FARM account is DBO of all the databases. Also make sure the FARM account is DBO of the Sharepoint Config database.

Next step is to make sure any existing content databases have the maximum allowed number of sitecollections maxed out. We want to make sure that the sitecollection we’re about to restore lands in the correct content database. When done use Sharepoint Central Admin to mount the content database to the existing projects.domain.local webapp. So in our setup we needed to add a new content database. Use sql1.domain.local\projects,4567 as the database server and type in PWA_CONTENT as the content database. You will now have a /pwa sitecollection.

Next Use Powershell to create a sitecollection backup of the /pwa sitecollection:

backup-spsite -identity http://projects.domain.local/pwa -path c:\temp\backup.bak

When the backup is completed remove the PWA Content database from the Central Admin and remove the PWA_Content database from SQL. Also remove the /pwa managed path. Now create an empty content database from Central Admin. Again make sure that restored sitecollections land in this content database by setting the maximum on the other content database. Remember that our goal was to migrate the environment to the http://projects.domain.local/businessunit URL. In this case we need to explicitly create (no wildcard) the managed path for businessunit. If you do not create the managed path, or create it with wildcard and not explicit you will receive errors.

Now we’re ready to restore the sitecollection to the new URL:

restore-spsite -identity http://projects.domain.local/businessunit -path c:\temp\backup.bak

Wait until the restore completes. Then remove the businessunit managed path, cause it will be recreated when you create your Project WebApp Site. When done you’re ready to create your PWA site. The first admin need to be the account that has permissions on your PWA_Content database AND on the Sharepoint Config database. If you make a mistake here you will receive stange misleading errors (see below in the error section). During the creation of our PWA site on our environment two PWA sites with the same URL were created. One that had a failed state. The other one was setting up. If you notice the same just wait until the working one is done setting up, and you will see the the failed one has dissapeared.

So now you’re almost done. In our case some webpart (eg. the project webapp) functionality wasn’t working. This we tracked back to a wrong PWA url. You can check your PWA url with the following powershell script:

$Web = get-SPWeb http://projects.domain.local/businessunit
$Web.AllProperties | Format-Table

If you notice that the PWAURL is wrong you can change it with the following Powershell script:

$Web = get-SPWeb http://projects.domain.local/businessunit
$Web.AllProperties[“PWAURL”]="http://projects.domain.local/businessunit"
$Web.Update()

We completed this migration three times (two times to our test env. , one time from test to production). In our case we had a 100% score migrating to a different URL. Ofcourse it might not apply to all Project Server environments so please have a good look at your own environment and use this document as a guideline how you might be able to accomplish the migration.

Good luck! And please let me know if you did a succesful migration following this document.

ERRORS

Error 1

During our trial and error stage some misleading errors took us a long time to troubleshoot. Below a little list and possible resolutions.

Site names cannot contain certain reserved words and cannot begin with an underscore.
Please enter a different name.
At line:1 char:15
+ Restore-SPSite <<<< -Identity http://projects.domain.local/businessunit -Path E:\temp\content.bak + CategoryInfo : InvalidData: (Microsoft.Share...dletRestoreSite: SPCmdletRestoreSite) [Restore-SPSite], SPException + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRestoreSite Resolution:You probably selected wildcards instead of explicit when you created your managed path

Error 2

Kan de site BusinessUnit niet inrichten met fout: System.ArgumentException: Er bestaat al een andere site op http://projects.domain.local/businessunit. Verwijder deze site voordat u probeert een nieuwe site te maken met dezelfde URL, kies een nieuwe URL of maak een nieuwe include in het pad dat u oorspronkelijk hebt opgegeven. —> Microsoft.SharePoint.SPException: Er bestaat al een andere site op http://projects.domain.local/businessunit. Verwijder deze site voordat u probeert een nieuwe site te maken met dezelfde URL, kies een nieuwe URL of maak een nieuwe include in het pad dat u oorspronkelijk hebt opgegeven.
— End of inner exception stack trace —
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.CreateSite(SPWebApplication application, SPContentDatabase database, String originalPath, Guid id, Guid siteSubscriptionId, Boolean useHostHeaderAsSiteName, Boolean bDeleted, DateTime deletionTime)
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.CreateSite(SPWebApplication application, SPContentDatabase database, String path, Boolean useHostHeaderAsSiteName)
at Microsoft.SharePoint.Administration.SPSiteCollection.Add(SPContentDatabase database, SPSiteSubscription siteSubscription, String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail, String secondaryContactLogin, String secondaryContactName, String secondaryContactEmail, String quotaTemplate, String sscRootWebUrl, Boolean useHostHeaderAsSiteName)
at Microsoft.SharePoint.Administration.SPSiteCollection.Add(SPSiteSubscription siteSubscription, String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail, String secondaryContactLogin, String secondaryContactName, String secondaryContactEmail, Boolean useHostHeaderAsSiteName)
at Microsoft.SharePoint.Administration.SPSiteCollection.Add(String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail, String secondaryContactLogin, String secondaryContactName, String secondaryContactEmail, Boolean useHostHeaderAsSiteName)
at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.CreateWSSSite(ProjectProvisionSettings provset, SPWebApplication parentWebApp, String adminName, String adminEmail, String secondaryAdminLogin, String secondaryAdminName, String secondaryAdminEmail, SPSiteStatus& siteStatus)

Resolution: So this error I only have in dutch. Translated it says something about the site cannot be created cause it already exists. We had this error a number of times in different situations. So here our three resolutions:

1) You have orphans. Refer to the script how to remove orphans at the start of this article.
2) You forgot to remove a managed path when you were supposed to do so.
3) The account you use to create the PWA site isn’t DBO on both the PWA_Content AND the Sharepoint Config database.

There might be other explanations why this error is created. But those were the three we encounterd.

Comments

Leave a Reply