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 – https://channel9.msdn.com/Events/Project/2014/PC325 – 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 http://blogs.technet.com/b/projectsupport/archive/2013/09/16/project-server-2013-controlling-the-version-of-connecting-clients-and-pwa-edits.aspx 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.