Doing this as a new post – and I will also update the previous one Project Server 2010- Service Pack2 and August 2013 Cumulative Update installation issues. The issue appears to be related to the version stamp of the database version schema (not the usual row we are interested in which is the Project Server DB version) – which SP2 sets at 184.108.40.206 – but ONLY if SP2 actually makes some database updates. In my testing if you apply SP2 and had previously applied the June 2013 cumulative Update (CU) – then there are no more database updates required from SP2 – so the version isn’t touched and stays at 14.1.653.0. If however you were at an earlier CU – or even SP1 – then SP2 will update to 220.127.116.11. The problem is that August CU is set for 14.1.702.0 – and as it sees the ‘newer’ stamp it fails. I’ve repeated the errors down below – for the search engines.
At this stage I’m not sure which is in the wrong – SP2 for setting the ‘2’ – or Aug CU for expecting a ‘1’ – or just the upgrader for not handling it correctly and knowing what to do. But there is a way to resolve this, and it may still be needed for future cumulative Updates too unless we sort it out in the next few weeks. The fix really depends where you are and where you want to be.
1. If you need the August CU for specific fixes and are at SP1+ some other CU already – then just load the August CU – you will not have this issue.
2. If you need a fix that is in SP2, then load the June CU first, and you will not have this issue with the future loading of CUs.
3. If you need both Aug CU and SP2 then you have a couple of choices – either load June CU, SP2 and then Aug CU – or if you want to skip June CU (you will still get all the fixes – but it will not take quite so long) you can use the workaround below after installing SP2 and running the configuration wizard – but before installing and running the config wizard for August.
If you are already broken – or you chose the option 3 above then you will need to change the version in the Publish database dbo.Versions table to 14.1.653.0. The easiest way is to open the table in SQL Management Studio for edit and just change the 1 to a 2 (correction 9/19) 18.104.22.168 to 14.1.653.0 – but you can use a SQL statement too - and then run psconfig from the command line with the following syntax – in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN directory.
psconfig -cmd upgrade -inplace b2b -wait -force
Be careful if copying and pasting – the flags use the character next to the 0 on a US keyboard – Word and other editors tend to lengthen it to a –.
Once the command completes then you should see a version in the published DB of 14.1.702.0, and the Project Server DB version showing 14.0.7104.5000.
We have seen some customers hit an issue with duplicate primary keys error on the MSP_TIMESHEET_VIEW_REPORTS_FIELDS table when running the psconfig command – my feeling is this probably occurred as a lower value than 14.1.653.0 was used so it may well have been trying to repeat some SQL updates that had already been applied. Best open a support incident if you hit this problem.
And for the search engines a repeat of the errors…
Configuration Failed – One or more configuration settings failed… Failed to upgrade SharePoint Products. An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfiguration.TaskException was thrown.
This particular exception can be thrown for many reasons – and the key to the specific failure will be in the upgrade logs, and will read something like this:
- [OWSTIMER] [PublishedDatabaseSequence] [ERROR] Upgrade object too new (build version = 14.0.7010.1000, schema version = 22.214.171.124). Current server (build version = 14.0.7104.5000, schema version = 14.1.702.0)
One of the symptoms will be that Project Professional can no longer see a list of projects when trying to retrieve the list from PWA – and also if you examine the databases you will see that the version on the Published database has not been upgraded and the number of Views available in the draft database is just 3 – and not the 250 or so you would expect to see.