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.
- # change this configuration values according the values in your farm
- $webAppUrl = 'http://YourSharePointServer'
- $contentDBName = 'ContentDB_PWA'
- $contentDBServer = 'YourSQLServer'
- $pwaMgdPathPostFix = "PWA"
- $pwaUrl = [string]::Format("{0}/{1}", $webAppUrl, $pwaMgdPathPostFix)
- $pwaTitle = "PWA Site"
- $pwaSiteTemplate = "PWA#0"
- $pwaLcid = 1033 # English
- $ownerAlias = "domain\user1"
- $secondaryOwnerAlias = "domain\user2"
- Write-Host Getting web application at $webAppUrl
- $webApp = Get-SPWebApplication -Identity $webAppUrl
- # create the content database if needed
- $contentDatabase = Get-SPContentDatabase -Identity $contentDBName
- if ($contentDatabase -eq $null) {
- Write-Host Creating content database: $contentDBName
- $contentDatabase = New-SPContentDatabase -Name $contentDBName -WebApplication $webApp -MaxSiteCount 1 -WarningSiteCount 0 -DatabaseServer $contentDBServer
- }
- else {
- Write-Host Using existing content database: $contentDBName
- }
- # create the managed path if needed
- $pwaMgdPath = Get-SPManagedPath -Identity $pwaMgdPathPostFix -WebApplication $webApp -ErrorAction SilentlyContinue
- if ($pwaMgdPath -eq $null) {
- Write-Host Creating managed path: $pwaMgdPathPostFix
- $pwaMgdPath = New-SPManagedPath -RelativeURL $pwaMgdPathPostFix -WebApplication $webApp -Explicit
- }
- else {
- Write-Host Using existing managed path: $pwaMgdPathPostFix
- }
- # (re)creating site collection for the PWA instance
- # we delete the site collection if it already exists
- $pwaSite = Get-SPSite -Identity $pwaUrl -ErrorAction SilentlyContinue
- if ($pwaSite -ne $null) {
- Write-Host Deleting existing PWA site at $pwaUrl
- $pwaSite.Delete()
- }
- Write-Host Creating PWA site at $pwaUrl
- $pwaSite = New-SPSite -Url $pwaUrl OwnerAlias $ownerAlias SecondaryOwnerAlias$secondaryOwnerAlias -ContentDatabase $contentDatabase Template $pwaSiteTemplate -Language $pwaLcid -Name $pwaTitle
- # Enable PWASITE feature
- Enable-SPFeature pwasite -URL $pwaUrl
- # Enable Project Server Permissions mode
- Set-SPProjectPermissionMode -Url $pwaUrl -Mode ProjectServer
- # disabling qutoa
- $quota = Get-SPProjectDatabaseQuota -Url $pwaUrl
- $quota.IsEnabled = $false
- $quota.MaxDbMegaByteSize++
- 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.