Automating the Provisioning of a PWA-Instance in Project Server 2016

Yet in 2015 I wrote a post about the automatic provisioning of a PWA instance. That time, it discussed the process in the context of Project Server 2013, now I updated the description to the version 2016.

Preparations

First of all, be sure you have enabled the usage of Project Server in the farm by entering a valid license key, otherwise you receive the error message below, when enabling the PWASITE feature at the end of the provisioning:

Enable-SPFeature : The farm does not have a product key for Project Server.
You can add your key by using Enable-ProjectServerLicense

As suggested by the error message, you should add your key by using Enable-ProjectServerLicense like:

Enable-ProjectServerLicense -Key [Guid of you Project Server product key]

At this step you might receive a further error message, stating:

Enable-ProjectServerLicense : We encountered an error while enabling Project
Server 2016 . Project Server 2016  requires the farm to have a valid
SharePoint Server Enterprise product key.

It means Project Server requires a licensed Enterprise version of SharePoint. In our case it was a bit confusing, as the page Upgrade and Migration / Enable Enterprise Features in Cental Administration displayed that the farm has already the Enterprise features activated.

The Upgrade and Migration / Convert License Type answered the question, as it turned out the farm was not licensed at all, being in state:

SharePoint Server Trial with Enterprise Client Access License

After entering the correct license key for the enterprise version to the  Enter the Product Key text field an submitting the form:

On the Convert License Type page the Current License changed to:

SharePoint Server Trial with Enterprise Client Access

and the Enter the Product Key text field was no more editable.

Unfortunately, I have not found any solution to convert the farm license type by PowerShell, so if you need it, you should perform it in Cental Administration user interface manually. The process of converting a license type is discussed in this post in details.

After we have a licensed Enterprise version, we can enable the Project Server license as well. Note, that you should restart your PowerShell console after converting the license type from Cental Administration as discussed above, otherwise it seems to be unable to recognize the change, and you receive the same error message about the lack of a valid SharePoint Server Enterprise product key as earlier.

Enable-ProjectServerLicense -Key [Guid of you Project Server product key]

The result should be now:

Project Server 2016  is now enabled.

Second part of the preparation is to ensure you have the adequate permissions to perform the provisioning job. Personally I prefer to have db_owner membership in all databases in the farm, including the configuration database as well. It is particularly important to check the permissions, if you plan to use an already existing content database to provision your PWA site, that you created via Central Administration site and not by PowerShell. Based on my experience the databases created in CA have different permissions configured as the ones created by PowerShell, and the lack of the permission may cause your provisioning process to stuck with no trivial solution.

Provisioning

After being prepared, let’s see our PowerShell script that provisions a new PWA instance, including:
– A separate SharePoint content database that should contain only a single site collection: the one for the PWA. If the content DB already exists, we will use the existing one, otherwise we create a new one.
– Creating the managed path for the PWA.
– A new site collection is created for the PWA using the project web application site template, and the right locale ID (1033 in our case). If the site collection already exists (in case we re-use a former content DB), it will be dropped before creating the new one.
– The PWASITE feature will be activated on the new site collection.
– Changing to the Project Server security model.
– Disabling quotas.

1. # change this configuration values according the values in your farm
2. $webAppUrl = 'http://YourSharePointServer'
3. $contentDBName = 'ContentDB_PWA'
4. $contentDBServer = 'YourSQLServer'
5.  
6. $pwaMgdPathPostFix = "PWA"
7. $pwaUrl = [string]::Format("{0}/{1}", $webAppUrl, $pwaMgdPathPostFix)
8. $pwaTitle = "PWA Site"
9. $pwaSiteTemplate = "PWA#0"
10. $pwaLcid = 1033 # English
11. $ownerAlias = "domain\user1"
12. $secondaryOwnerAlias = "domain\user2"
13.  
14. Write-Host Getting web application at $webAppUrl
15. $webApp = Get-SPWebApplication -Identity $webAppUrl
16.  
17. # create the content database if needed
18. $contentDatabase = Get-SPContentDatabase -Identity $contentDBName
19. if ($contentDatabase -eq $null) {
20.   Write-Host Creating content database: $contentDBName
21.   $contentDatabase = New-SPContentDatabase -Name $contentDBName -WebApplication $webApp -MaxSiteCount 1 -WarningSiteCount 0 -DatabaseServer $contentDBServer
22. }
23. else {
24.   Write-Host Using existing content database: $contentDBName
25. }
26.  
27. # create the managed path if needed
28. $pwaMgdPath = Get-SPManagedPath -Identity $pwaMgdPathPostFix -WebApplication $webApp -ErrorAction SilentlyContinue
29. if ($pwaMgdPath -eq $null) {
30.   Write-Host Creating managed path: $pwaMgdPathPostFix
31.   $pwaMgdPath = New-SPManagedPath -RelativeURL $pwaMgdPathPostFix -WebApplication $webApp -Explicit
32. }
33. else {
34.   Write-Host Using existing managed path: $pwaMgdPathPostFix
35. }
36. # (re)creating site collection for the PWA instance
37. # we delete the site collection if it already exists
38. $pwaSite = Get-SPSite -Identity $pwaUrl -ErrorAction SilentlyContinue
39. if ($pwaSite -ne $null) {
40.   Write-Host Deleting existing PWA site at $pwaUrl
41.   $pwaSite.Delete()
42. }
43.  
44. Write-Host Creating PWA site at $pwaUrl
45.   $pwaSite = New-SPSite -Url $pwaUrl OwnerAlias $ownerAlias SecondaryOwnerAlias$secondaryOwnerAlias -ContentDatabase $contentDatabase Template $pwaSiteTemplate -Language $pwaLcid -Name $pwaTitle
46.  
47. # Enable PWASITE feature
48. Enable-SPFeature pwasite -URL $pwaUrl
49.  
50. # Enable Project Server Permissions mode
51. Set-SPProjectPermissionMode -Url $pwaUrl -Mode ProjectServer
52.  
53. # disabling qutoa
54. $quota = Get-SPProjectDatabaseQuota -Url $pwaUrl
55. $quota.IsEnabled = $false
56. $quota.MaxDbMegaByteSize++
57. Set-SPProjectDatabaseQuota -Url $pwaUrl $quota

A comment regarding the last step, disabling quota. If you simply read the values of the current quota using the Get-SPProjectDatabaseQuota cmdlet, disable the quota, and try to set the value by Set-SPProjectDatabaseQuota cmdlet, you get an error message:

Set-SPProjectDatabaseQuota : Cannot apply settings, the maximum database size must be greater than the read only limit.

That is because the properties MaxDbMegaByteSize and ReadOnlyMegaByteLimit have by default the same value (10240). Funny, that it later not allowed to set the same values yourself. That is why we have $quota.MaxDbMegaByteSize++ in code.