*** Update 2/6/2015 – Worth adding to this posting that from the November 2014 CU for Project Server 2013 onwards the schedule web part is no longer stopped from working by this setting. So for example you could have November 2014 Server CU, but still control the clients connecting to a more recent CU – such as December 2014 – or the February 2015 CU – due out next Tuesday. Thanks for the reminder to update this post Heather! ***
Since Project Server 2010 it has been possible to control which patch level of Project Professional is allowed to connect to Project Server by referencing the Version in Server Settings. This is configured in Server Settings, Additional Server Settings, and in Project Server 2013 this is one of the settings that is accessed via SharePoint C2013 Central Administration, General Application Settings, PWA Settings, Manage – and then under Additional Server Settings (and don’t forget to set the right Project Web App Instance if you have more than one). So for example I might set the value to 15.0.4535.1000 – the version of the August 2013 Cumulative for Project Professional 2013. But I might not…
If I then try to connect with a lower version of Project I get an error – The following job failed to complete. Job Type: Load, Error ID: 12015(0x2EEF), Error: An internal error occurred – and I opened the More Info section and scrolled down to see the interesting stuff – name="ActiveCacheUnsupportedProjectProfessionalVersion" uid="53cf724e-f01e-e311-9415-00155d745a02" version="15.0.4517.1001"/.
So what’s the problem? Seems to work? What if I try and edit a plan in PWA?
Strange. The plan doesn’t load, and you might also see other PDPs than the schedule also fail to load – *** additional info – 12/12/2013 – if you have script errors I.E. not disabled then you will also see an error something like
Webpage error details
Message: Unable to get property 'replace' of undefined or null reference
If you look in the ULS logs you willI see something like the following:
09/16/2013 10:19:09.93 Microsoft.Office.Project.Server (0x3548) 0x0590 Project Server Active Cache Load 3oh1 Medium Error is: ActiveCacheUnsupportedProjectProfessionalVersion. Details: ActiveCacheUnsupportedProjectProfessionalVersion Attributes: 15.0.4525.1000 . Standard Information: Project:73f0a279-f31e-e311-be99-f4b7e2e8268f Project:75cdd7db-1b68-4b70-a8d6-2fe52da83acd 549f439c-1222-a04c-45e7-ac3fd79c7a5a
09/16/2013 10:19:09.93 Microsoft.Office.Project.Server (0x3548) 0x0590 Project Server Project Calculation Service (M) ai2no Unexpected PWA:, ServiceApp:Project Server Service Application, User:i:0#.w|redmondbrismith, PSI: CalcServiceManager can't read PreReadProject2 for projectGuid 75cdd7db-1b68-4b70-a8d6-2fe52da83acd. Project:73f0a279-f31e-e311-be99-f4b7e2e8268f Project:75cdd7db-1b68-4b70-a8d6-2fe52da83acd 549f439c-1222-a04c-45e7-ac3fd79c7a5a
09/16/2013 10:19:09.95 Microsoft.Office.Project.Server (0x3548) 0x0590 Project Server Project Calculation Service (M) ai2mv Exception CalcServiceManager : Processing Error while opening project guid: 73f0a279-f31e-e311-be99-f4b7e2e8268f Microsoft.Office.Project.Server.BusinessLayer.PcsEngine.PcsManagerException: CalcServiceManager : ReadProjectData : CalcServiceManager can't read PreReadProject2 at Microsoft.Office.Project.Server.BusinessLayer.CalcServiceManager.ReadProjectData(IPlatformContext siteContext, WinProj winprojActiveCache, Guid ProjectGuid, Guid sessionGuid, UInt32 flags, Int32 lcid, String versionStamp, Boolean fNonCoreData, Boolean fEglobal, Boolean keepWriteLock, Byte& coreData, Byte& noncoreData, PSError psError) at Microsoft.Office.Project.Server.BusinessLayer.CalcServiceManager.LoadProjectData(IPlatformContext siteContext, Guid projectGuid, WinProj winprojActiveCache, Guid globalGuid, Int32 lcid, IPCSPipe pipe, Guid sessionGuid, String oldVersion, String globalOldVersion, Boolean keepWriteLock, PSError psError) at Microsoft.Office.Project.Server.BusinessLayer.CalcServiceManager.OpenProjectRemappedProject(CalcServiceCallState callState, Guid realProjectGuid, Guid remappedProjectGuid, EngineSessionState& sessionState, EngineSessionType sessionType, PSError& psError) StackTrace: at Microsoft.Office.Project.Server.Native.dll: (sig=9f2c3f6c-406e-4293-ab26-21dadb9504de|2|microsoft.office.project.server.native.pdb, offset=3C1E) at Microsoft.Office.Project.Server.Native.dll: (offset=1255D) 549f439c-1222-a04c-45e7-ac3fd79c7a5a
You may see a different version reported there – depending on the server patch level. This is with the August CU for Project Server 2013.
*** Update 10/15/2013 – The October 2013 CU does not give this issue if the Server and Client are both patched to Oct 2013 then the version reported by client and server is the same – 15.0.4551.1001 – obviously if the server isn't patched then trying to control the client to Oct CU will also limit the ability to edit plans in the Schedule Web Part in PWA. ***
That’s the reason I might not want to set the Project Professional version. This issue in 2013 is due to the change in the server-side scheduling engine infrastructure. In Project Server 2013 we now use the same scheduling engine as Project Professional in the server – which has many great benefits – but one side effect that I hadn’t considered. When you open a plan for editing in PWA the server-side scheduling engine reports its version number – and if you are controlling the connected patch level as detailed above then you will get this failure to read the project. The reason the server-side calculation engine may report a different version is that although this is the same scheduling engine – Project Professional may be patched for features that are not related to scheduling – such as printing issue for example – so its version can be different to the server scheduling engine.
In this case you could safely set the version to 15.0.4525.1000 and this would then only allow the August CU patched clients (as June CU was below this value) and PWA editing would work just fine. We are reviewing this issue as a bug as there could be conditions where you want to control a client patch level yet your server may still be at an earlier level – if you are in this situation I would suggest opening a support incident.
Thanks to Hans Bellen of UMT for bringing this to our attention.