Microsoft Project Server 2010 and 2013 March 2015 PU Announcement

I am very pleased to announce the release of the March 2015 Public Update (PU) for Project, Project Server and SharePoint for 2013, and Project Server and SharePoint 2010.  For the second time we are now delivering as Public Updates, although Server fixes are shipped just via the Download Center and not via Windows Update.  These are still cumulative.

*** Update 4/16 - See for the recorded session where Adrian talked about the 2013 fixes ***

Feel free to open a support case if you have any questions around this or need assistance getting these patches deployed.

The 2013 PU releases also have a prerequisite of the appropriate Service Pack 1 (SP1), and links for SP1 are given below.

Another important point to add here is that there was an issue early last year running the SharePoint Configuration Wizard on a server with Project Server 2013 installed – this is fixed by applying the April 2013 or later– so a good practice would be to load SP1, then the March 2015 PU and then run the configuration wizard (if you didn’t already load the April 2013 through June 2014 CU).

This release for the 2010 products, like all 2010 patches since the November CU, has a hard requirement on Service Pack 2 – see notes below, (Support for Microsoft Office 2010 Service Pack 1 ended on 10/14/14).  Don’t forget language packs SP2 if you have any language packs loaded!  In most of the KB articles the term hotfix is used in place of Cumulative Update.  They tend to be interchangeable terms – a Cumulative Update is just a hotfix built to a schedule.  I should also point out that the individual Project Server packages are only ‘individual’ in the sense that they do not include the SharePoint patches – they are still cumulative and the February PU will contain all previous CU releases (at least back to the applicable baseline). 

Also a reminder – an SP1 patched 2010 system (with no SP2) is no longer supported – see the Lifecycle site for more information - 


Project and Project Server 2013

An overview of all the Office 2013 releases for February 2015 can be found here – - Description of the Office updates: March 10, 2015

This include a number of fixes, so Microsoft strongly recommends that you test this in a test environment based on your production environment before putting this fix live in production.

The article below provides information on how to deploy the Project Server Cumulative Update.

You can read about the fixes included in the Project and Project Server February PUs from the following articles:

Project Server 2013 Server Rollup Package

As mentioned above – this rollup package will only be available via the Download Center – not Windows Update.

March 10, 2015 cumulative update for Project Server 2013 (KB2956162)

Project Server 2013 Individual Project Package – (cumulative, but only the Project Server fixes):

March 10, 2015 update for Project Server 2013 (KB2956178)

The dbo.Versions table should show 15.0.4699.1000 after applying the March 2015 PU.  The version number 15.0.4701.1000 can be used to control the connecting client to the March 2015 level, but only if you are loading the November CU or more recent to the server.  This version control no longer blocks server side scheduling engine since the November CU, but as this fix is server side you cannot use a higher value until you have this server patch or a more recent one.

SP1 for Project Server 2013 can be hound here -

Project 2013 Client Package:

March 10, 2015 update for Project 2013 (KB2956187)

The client version number will be 15.0.4701.1000 (I see 15.0.4701.1000 on my click to run Project Pro for Office 365 too).  The server scheduling engine is no longer blocked by version control since the November CU on the server, so providing you have November 2014 CU ort above on the server you can use the 15.0.4701.1000 value to control connection of the March 2015 PU patched client..  If you are running a server CU earlier than November 2014 CU then follow the suggested version number for the server patch level you are running.  See Project Server 2013- Controlling the version of connecting clients–and PWA edits- for more details.  As mentioned above – the version number entered no longer controls the server side scheduling engine – so from the November 2014 CU release onward you can set a higher version to control clients without blocking the server side scheduling in the schedule web part.

We are working on the specific CU installation documentation for 2013, but the process hasn’t changed from 2010 – so if you are familiar with 2010 patching or read the 2010 instructions below you should be good to go.

SP1 for Project Professional 2013 can be found here -

Also note that Click to Run installations will be automatically patched (mine updated today to the same version as above).  Installations in Enterprise Environments that have been modified will be deployed based on the schedule determined by your Administrator.  See

Project and Project Server 2010

An overview of all the Office 2010 releases for February 2015 can be found here - Description of the Office updates: March 10, 2015

This include a number of fixes, so Microsoft strongly recommends that you test this in a test environment based on your production environment before putting this fix live in production.

The article below provides information on how to deploy the Project Server Cumulative Update.

You can read about the fixes included in the Project and Project Server February PUs from the following articles:

Project Server 2010

Project Server 2010 Individual package (cumulative – but just the Project Server 2010 fixes)

March 10, 2015 update for Project Server 2010 (KB2553480)

Project Server roll-up package

March 10, 2015 cumulative update for Project Server 2010 (KB2956198)

The Project Server database version is updated to 14.0.7145.5000 with the March 2015 PU, after applying this or the package hotfix above, and running the configuration wizard.

Project 2010 Client Package:

No client update for Project 2010 this month – see for the most recent update – the February 2015 one.

More information on deploying the Cumulative Update:

The article below provides information on how to deploy the Project Server Cumulative Update.

Updates for Project Server 2010

As Project Server 2010 is now based on SharePoint Server 2010 we strongly recommend that you install the Project Server 2010 Server Rollup Package (when available) as there are a large number of individual server packages for SharePoint Server. The Project Server 2010 Server Rollup Package contains all the patches released in this Cumulative Update for SharePoint Foundation Server 2010, SharePoint Server 2010 and Project Server 2010.

As mentioned above, the November 2014 Cumulative Update and above requires your client and server to already be at the Service Pack 1 (SP2) level – if you get a message saying the patch does not apply to your system then this may be the reason – the message may be “expected version of the product was not found”

SP2 for the Project Server 2010 can be found at Service Pack 2 for Microsoft SharePoint and Project Server 2010 (KB2687452) – and a description at SP2 at Description of Project Server 2010 SP2.  If you have language packs installed then these will also need to be patched to SP2 or the message above will be seen – SP2 for the server language packs can be found at Download the Microsoft Office Servers 2010 Language Pack Service Pack 2 package now and a description at

SP2 for the Project Professional 2010 client can be found at for the 32-bit and for the 64-bit and a description at

Client Installation:

The instructions for installing the client patch are below.

NOTE: Microsoft strongly recommends testing within a NON-Production environment prior to rollout.

1. Download the hotfix from the link in the KB Article.

2. Extract the patch package by running the .exe file that you downloaded.

3. Run the extracted .exe file to apply the patch to your Project Professional/Standard client.

Or, from February 2015 onwards use Windows Update to download and install the patches.

Comments (17)

  1. anonymouscommenter says:

    Hi Brian, I’m wondering if you can comment on using database attach patching for Project Server. Most guidance just covers doing it that way for SharePoint, but I’m at a point where my PWA content DB contains something like 600 sites, so when I run psconfig
    on each server in my farm (5 servers), that process takes well over 45 minutes on each server because it seems to be querying all the project sites multiple times, and each one of those queries takes 10 minutes or so. It’s been getting slower and slower each
    CU I apply, so I want to switch to detaching that content DB, running the exe and psconfig on all servers, then reattaching and upgrading the content DB. I just don’t know how the Project database plays into this method.
    Hope you can shed some light on this. Thanks in advance!

  2. anonymouscommenter says:

    Hi Brian,
    do you know of an issue with Project Prof. March 2015 PU that leads to Project custom fields values getting lost when the plan is saved to the Server and the Server has patch Level before March 2015 PU?

  3. anonymouscommenter says:

    Hey Chris – what have you seen? I’m dealing with the same issue here. Users with March 2015 CU for the client and my server is December 2014 CU.

  4. anonymouscommenter says:

    Hi Aaaron,
    should be solved by installing March CU on the server side also. Had the issue with October 2014 and February 2015 CU on the server side. Good luck.

  5. anonymouscommenter says:

    Can you expand on what you were seeing? Ours were custom fields, some date fields, and project health fields, randomly getting blanked out after a project manager made some updates and published. Is that what was happening with you? We can’t just put on
    the March CU so I’m thinking we might have to roll back the patch level of the clients.

  6. anonymouscommenter says:

    Hi Aaaron,
    Seems to be project and tasks level custom fields after the plan was modified and published with Project Professional. As far as I heard from my colleagues, the issue was gone after the server was also patched to March 2015 PU.

  7. Hi Christoph, Aaron – sorry for not responding – my comment notification alerts didn’t fire. I wasn’t aware of this issue – but I hear from the frontline we have a couple of cases. I’ll see what I can find.
    Best regards,

  8. And Aaron – we don’t support database attach upgrades for Project Server unfortunately. I think this non-support may be more about the project database – but we certainly don’t test that scenario.
    Best regards,

  9. anonymouscommenter says:

    Thanks for the responses Brian. I submitted a case a week ago regarding the custom fields issue.

  10. anonymouscommenter says:

    Hello everyone/Brian,

    we recently had hte odd case that in Project Server 2010 after installing Uber 2015-03, the SharePoint Service account was lacking permission: The EXECUTE permission was denied on the object ‘MSP_ReadLocalAndEnterpriseLookupTableInfoByUIDs’, database ‘PWA_Published’,
    schema ‘dbo’.

    The account still had the usual DB permissions ProjectServerRole, db_datareader, db_datawriter. After giving it the db_owner role in addition (and violating the least privilege requirement), everything worked fine. It seems that the execution of some procedures/functions
    has recently fallen off there.
    Does anyone else experience this? Brian, could you possibly look into this?

    Note: Since the SharePoint Farm Account always has owner permissions, this effect only appears when you have a separate Service account.

    Thank you and best regards,

  11. anonymouscommenter says:

    Can confirm this,after giving the db_owner role to the Service account there is no longer an error message saving or changing Projects from PWA where fields with lookup table values are used

  12. anonymouscommenter says:

    I just checked the ‘MSP_ReadLocalAndEnterpriseLookupTableInfoByUIDs’ stored procedure, and the person responsible for scripting that particular code has managed to include the "grant execute…" statement within the actual procedure – accidentally removed
    a "GO" from the end of the actual procedure, probably…
    This means that if you’re running ProjectServer under an account with sql permissions to grant execute permissions (such as db_owner), you’re good – otherwise the execution will fail.
    Remove the offending last line from the procedure and give the ProjectServerRole execute rights on the result and you shouldn’t have to give the service account more access than neccesary.

  13. anonymouscommenter says:

    We face a similar issue after applying SharePoint patch, "MS15-033: Description of the security update for SharePoint Server 2010: April 14, 2015 (KB2553164)"

    System.Data.SqlClient.SqlException: Cannot find the object ‘MSP_ReadLocalAndEnterpriseLookupTableInfoByUIDs’, because it does not exist or you do not have permission.

    We tried applying the latest April CU for Project Server as well as looking at the service user permissions and neither worked.

  14. anonymouscommenter says:


    We had the same problems with customfields values getting lost. We have a Project 2013 server environment migrated from Project server 2010 and when the problem occurred, we are running on the Server February 2015 CU with the March Cu 2015 on the clients.

    Now we running on the Project server March CU 2015 and have another problem. When we change a custom field value in MS Project (meanwhile we running with CU April 2015 on the client) and publishing the project, we see the changes in PWA. Only the new values
    doesn’t update in the timesheets. It has worked before because I see the old values.
    It is not related to one project or user. Custom fields in the timesheets doesn’t update anymore. I’m not sure that this problem is related to the other problem.
    Does someone else experience the same problem? Or better, does someone knows how to solve this issue?


  15. The custom field loss issue now also has a fix which will be delivered in the June 2015 updates. One note on this issue is that if the original person who saved opens again (assuming no one else has saved since) and the plan is still in their local cache
    then the fields are there. Another good reason not to delete the local cache.
    Best regards,

Skip to main content