Project Server 2010: August 2013 Cumulative Update Installation–latest

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 – 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  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) 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.

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 = 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.

Comments (8)

  1. PJ Mistry says:

    Thanks Brian. This helps.


    PJ Mistry


  2. Anderson C. Oliveira says:

    Hi, Brian

    Here, we are runing just Project Professional 2010 with SP1 (no Project Server). We are updating directly to SP2 with August CU. Is there any concearn around that?


  3. Sorry for the delay Anderson – and no problems whatsoever with the client patching.

    Best regards,


  4. says:

    I apologize if this gets posted twice but I believe I had quoted the wrong article number in the first post.

    Does this issue still apply to the updated August 2013 CU (Article ID: 2825959)?  I was on an older CU when I installed SP2.  

  5. anonymouscommenter says:

    Thanks for the article. When my newly patched farm started telling me that the Published database was too new, I thought I was taking crazy pills…

  6. Hi Brian ,

    Thanks for this article , this saves my time and efforts . We are on April 2013 CU know, Can i go directly with SP2+October 2013 CU? Or Just to stay on SP2 and wait for next stable release ,as we need SP2?

  7. anonymouscommenter says:

    Jason, did you run the psconfig command listed above to fix the issue?  Did it work for you?  I have this issue and it's causing ticket headaches!

  8. anonymouscommenter says:

    Updating the version in the database and then running the psconfig command worked on my dev environment.  Quick question, … In my production environment, running multiple wfe's / SharePoint servers will I need to run the psconfig command on a single server or all SharePoint servers as I do in a regular CU update?

Skip to main content