There’s a frequent need to refresh MS-Project Server test environments from Production. The conventional wisdom holds that you need to delete and recreate the SharePoint Web Application (PWA). However this requires you to:
- Recreate Alternate Access Methods (AAM)
- Set quotas
- Refine Blocked File Types
- Set User Policy
- Set Service Application connections…
The faster and smoother better way is instead to drop the old PWA content DB, and and reconnect the new PWA Content database. Regardless, the very first step should actually be dropping the Project Server Web App. This is done through the Project Server Service Application in Central Administration, Service Applications. Now let’s switch over to the replacement PWA Content DB. This houses both the top level Site Collection, the PWA application Site Collection and all webs under it (mostly each are a project site):
Dismount-spcontentdatabase [the old content database we are replacing] Mount-SPContentDatabase -name [the new content database ] -DatabaseServer [your DB server] -WebApplication "http ://pwa" [change as needed]
However there is one big wrinkle. Doing this seems to leave an orphaned explicit managed path definition in the Web Application that prevents creation of the PWA Site Collection. This appears to be what leads people to simply delete and recreate the Web Application. However the solution is quite simple; remove the orphaned site collection:
Remove-SPSite -Identity "htt p://pwa/" [change as needed]
When recreating the Project Web Application note:
- When removing the Project Server Web App, you may wish to uncheck the “Remove Content DB” checkbox
- Halting the Timer jobs may be required for the steps above. One advantage of using PowerShell is that it does not depend on the Web App Application Pool to be active
- “PWA” must be the name of the project web app
- Get the database names right, to ensure you connect to the target databases migrated to this environment
If your replacement PWA DBs come from an environment with different security, you’ll need to adjust security manually at the database level. I prefer to take screenshots in SQL Studio for comparison before starting.
OLAP Configuration
The OLAP cube inevitably needs to be reconfigured. When refreshing the databases, the OLAP configuration will now mirror the source environment. Make sure you know the name of the OLAP server and database to reset the OLAP configuration.
Delete the Data Connections OLAP folder, as well as the 13 assorted cubes and the folder in which they reside. When rebuilding the cube, these get recreated with reference to the OLAP Server and database.
Lastly, check the cube rebuild frequency and rebuild the cube. You should see a successful OLAP cube build log, the new cubes recreated, and data in the cubes that is visible in the Excel PivotTables stored in the OLAP folder that is as current as the source PWA database.
Testing
Check the main navigation links. Any hard-coded navigation links in the source may not get repointed automatically in the newly refreshed environment and could require hand-tuning.
Check that the new Excel OLAP pivots are in a SharePoint Excel Services Trusted Location
Other areas to test
- Add-ons
- Links
- Data (projects, resource pool and associated metadata)
- Sites
- Views
- Configurable fields and Lookup tables
- Enterprise Calendar
- Security
- Ability to access via MSPS client
- Scheduled backups
- Quick Launch settings in Server Settings
- Time/task management settings
- Project Detail pages
- Project site templates
- Ability to add a Risk, Issue to project sites
- OLAP
- Reports
When you’ve done a refresh once, you are golden! I like to say “only in technology can you do something once, then be considered an ‘expert’”!
Want to talk?
Drop us a line. We are here to answer your questions 24*7.