Project Server technical bits

I was intending to write a set of posts on the topic of migrating SharePoint and Project Server from 2010 on premise through 2013, 2016 to 2019 Azure, using SQL Managed Instance as the backend SQL Service.  This set of posts are still getting drafted and updated as we move through this cycle, but I came across a huge blocker this week that I wanted to post on, whilst it was fresh. Our Azure migration machines (2013 and 2016) are: - dual core 2.3ghz - 28GB Ram 2013 server is Windows Server 2012 R2 running SQL 2012 SP1 2016 server is Windows Server 2016 running SQL 2014 SP1 The Project Server dataset we are dealing with here is c.100GB (50% archive data). The uplift from SP/PS 2010 to 2013 went without a hitch over a 2.5hr period which was a huge win.  However when attempting to upgrade to 2016 we hit a hitch. Firstly some background:  When you perform the Migrate-SPProjectDatabase command, the following will happen (well it certainly did to us) - the ProjectWebApp DB fro

The scenario is this: SharePoint 2016 Farm with Project Server Two Web Apps Development UAT One PWA on Development Web App. I want to copy the PWA Site on Development web app to UAT to support a testing cycle. As far as I knew there were two options: 1) Content Database Restore and Attach Process would be backup your Dev Content Database, Restore to a new Content Database for QA, then mount the database on the appropriate web app and your off.... Problem:  Although you can do this with the -AssignNewDatabaseID switch in Powershell (to avoid two content db's having the same database id) the Site Collection (PWA) in the db still retains its SiteID which means there is a duplicate SiteID in the Configuration Database.  This stops the PWA site being created and alllocated correctly and becomes essentially orphaned. This method is only any good for MOVING not COPYING Back to the drawing board... 2) Backup-SPSite / Restore-SPSite I didn't believe this w

Dashboard navigation is the phrase i am using to describe the process of being able to interrogate and drill down into reports without the necessity for using parameters.  Let's face it, parameters are really ugly in SSRS - even with the ability to now lay them out - and the world would be a happier place if there was such a concept as slicers and other report UI elements natively in the SSRS universe. Firstly a note:  yes, I know Power BI does a lot of this stuff.  However, for on-premise customers, this isn't necessarily a cost-effective solution.  Most of my customers are SharePoint and Project Server users and - lets face it - most Project Server environments don't end up sitting on SQL Enterprise Edition so Power BI requires $/£ on top of the existing customer investment, which just isn't gonna fly in most cases. So here are a few concepts I have played with in the last few weeks to spoof such navigation tricks. Part 1) Single-select slicers using

Just a quickie... I've been interested in how MS have handled the "multiple PWA sites in a Content DB" thing since I read that this was their new approach.  Most of my reporting is via SSRS so i am reliant (still... in 2016) on DB queries rather than OData feeds (tsk) and this "querying a PWA DB with more than one PWA site in it is unsupported" quote was worrying me. So it looks like what is happening is this. When you create the first PWA site in a Content DB it hard-codes the SiteID into the _Userview view design elements.  This means that your first PWA Site is the default.  All the data for subsequent sites are still held in the tables against separate SiteID's but you cannot utilise the OOTB _Userview components (see below) SELECT        ProjectFields.... FROM            pjrep.MSP_TVF_EpmProject('FF19B767-CA6D-4C4C-B123-C0B5AE5354D6') AS MSP_EpmProject  LEFT OUTER JOIN                       pjrep.MSP_TVF_EpmInternalProjectHierarchies

Following on from my previous 2016 PWA Setup post, I am encountering an issue with PWA on the root of a HNSC with PWA in ProjectServer Permission Mode. Scenario  I want to create a pwa site on a HNSC at http://pwa.domain.com ,  I don’t PWA as a pathed web under the HNSC (‘/pwa’) and I would like to avoid using a Host Header on a separate webapp with PWA provisioned at ‘/’ if poss as its horrible and ikkie Method Create a web app on server name http://fe1 Create a root Site Collection on the web app Lock Content DB down Create new Content DB for the PWA site Create a HNSC called http://pwa.domain.com pointing to the above web app using the PWA#0 template etc New-spsite " http://pwa .domain.com " -hostheaderwebapplication " http://fe1 " -name "PWA" -Description "Project Web App" -owneralias "Domain\user" -language 1033 -template "PWA#0" Lock the content db down Enable PWASite features and all that jazz Swi

** update 3 ** seems so far that creation of Root PWA sites doesn't work (sync issues in Project Permission mode).  I've written a post recently about this Also _userviews are back... but only apply to the first Site in any Content DB.  See post 8 June 2016 ** update 2 ** user sync issue is still happening on PWA.  not sure why as of yet.... ** update ** I encountered a failure in the user synchronisation job in PWA which i think was atributed to creating the PWA HNSC site prior to creating the web app root site. whoops  ** end ** Project Server 2016 RTM first looks........... Once you've installed SQL and SharePoint there are a few surprises for you under the hood of Project Server Getting going It is probably worth noting that the Project service is deemed "front end" in the miniroles for SP2016.  This is inline with my latter thinking on SP2013 and a welcome addition.  However i have gone Custom for my limited installation just for flexibili