Project Server: Patch matching from client to server–is it necessary?

Revisiting this topic that I covered very briefly back in October last year, about the need or otherwise to keep Project Professional and Project Server (2010 and 2013) patched to the same level with Cumulative Updates and Service Packs.  Also covering a few other scenarios you might want to consider – and including how the control of the connecting client versions can affect editing schedules on the server.  This was a topic that came up during the Project Conference – so I'll be addressing some of the points raised in the IT Professional chalk talk session (available online - – the question at 3:40 is about patching – and a question from the audience at 15:44).

First point – you need to be running supported versions of both client and the server – see the Support Lifecycle page for more information – and you also can only run Project Professional 2010 against Project Server 2010 and Project Professional 2013 (or Project Pro for Office 365) against Project Server 2013) – no mix and match!

Beyond this you can run any patch level of the client Project Professional, Cumulative Update or Service Pack, against any patch level of the server and be in a supported configuration. 

However, there may be times when a bug that is causing you problems gets fixed and you want to ensure that no client that doesn’t have this fix connects to your server.  This is where the option to control the connecting version of Project Professional comes in to play.  In Server Settings, Additional Server Settings (2010) or Central Administration, General Application Settings,  PWA Settings, Manage Additional Server Settings (2013) you can put a value of the version of the client that can connect (usually I post the version numbers in the Cumulative update posts on this blog) and then only clients at or above his level can connect to the server.  This doesn’t however, stop you running a mix of client versions above this level – and certainly I have heard of ‘badness’ happening when different patch levels are being used to work on the same schedules.  In theory this shouldn’t cause any issues – but I can certainly imagine that some other bugs may exist in the older clients – or even some regressions introduced in the newer ones – so that the behavior of the schedule may look different to the differently patched users.  I certainly wouldn’t argue against keeping all clients at the exact same patch level – certainly a good practice to adopt.  I have also heard anecdotal evidence that matching the client and server Cumulative Update or Service Pack levels will avoid the occurrence of the ‘check-in pending’ issue – where a Project Professional client will still think the plan is checked out even when it appears to be safely checked in on the server.  No evidence or even a theory as to why this might be the case – but always wary of discounting something when partners and consultants have seen this make a difference.

One consideration for Project Server 2013 when controlling the connecting client version is that this also controls the server scheduling engine – which is the same component as the client scheduling engine.  This can mean that updating your clients before the server and then setting the value to the new client can mean that editing in the server schedule web part will not work – and in some case even being at the same CU level the server engine may report a slightly different version and then be blocked for editing.  See for more details.

Finally, there may be some occasions when a fix affects both the client and server, and to get the full affect of the fix you need to patch both.  Generally nothing will break if you don’t have both client and server patched to the same point – you just won’t see the full effect of the fix.  We will normally note this in the Knowledgebase (KB) articles for the fix.  In some rare situations there is a much tighter dependency for a fix and we require both client and server to be at or above a certain level – but the last time I can remember such a fix was the early days of 2007 and the Infrastructure Update.  Again, we would note any such dependency in the KB article – as well as making a note of this in my release blog posts.

And really finally - the above all applies to Project Server – for Project Online you cannot control the version of the connecting client but best to use Project Pro for Office 365 and then you will always be up to date and all your clients matched.

Comments (4)

  1. anonymouscommenter says:

    Hi Brain,
    Moral of the story : As best practice it is preferred to have both Client and Server at same patch level and live with peace of mind.!!
    I have witnessed several issues due to mismatch versions affecting the schedule. I agree thou technically and theoretically we can have different versions of CU’s but it is best Avoided.

    Thanks and Regards,
    Mustaq Hussain.

  2. anonymouscommenter says:

    Hi Brian,

    We are using Project Server 2013. we installed each CU and Sp1 on Project Server and SharePoint as they are published (You fixed so much things that we faced with, thanx for it) But we’re desperate with last sp1 update.

    Our clients also use Ms Project Prof. 2013. And they updated their workstations to Office 2013 sp1 (just for this matching thing ;o)) ). After that we’re unable to level our projects which are connected to Project Server 2013. When we try to level our master project it just hangs for hours and it says nothing, just hangs, nothing on workstation and server logs, too.

    While we’re dealing with this problem, we magically think to uninstall office2013 sp1 from workstation. After that everything goes fine. But this time, I don’t know how system affected.

    What can we do, Is it the best possible solution for this specific problem?

  3. anonymouscommenter says:

    Hi Hmcal,
    if this issue appeared after updating it might help to downgrade the clients. You could test with just one Client downgraded – bettor not save the plan to the Server, but you will see if leveling works.
    But best recommendation would probably be to open a Support call with Microsoft to check if this really is a SP1 issue. If it is a bug, there will be no costs for the call.

  4. anonymouscommenter says:

    Hi Christoph, appriciated for you answer.

    We already tried to uninstall Office sp1 and everything goes fine. I’d consider to open support ticket to MS.

    Thank you.

Skip to main content