We have seen a few customer caught out by the experience when provisioning a new Project Web App in Project Online and I wanted to share with you some of the behind the scenes activity that goes on – and what to expect if you choose to provision in a language different language.  In my example I am starting with a US English Project Online – it happens to be an E3 tenant and has Exchange, Lync etc. too – but I will be concentrating on the Project Web App experience.  I am choosing Czech as the language for my new PWA site.  I should also point out that currently (as of 9/26/2013) we are looking in to some anomalies we are seeing in different language choices – so I will be explaining what you should be seeing – as well as some of these anomalies we are currently investigating.

If you are one of the customers currently suffering with some English terms appearing then you have my sincerest apologies.  It has been escalated to the product group and a resolution is being worked on as I type.

One thing you may see initially is the left navigation may still contain some English words when PWA is first provisioned.  A timer job in the background applies some of the language information and this can take several hours to complete.  Mine was finished overnight – but probably took 5+ hours at least.  So patience may be needed until the full language provision has completed.

You can see here that it was provisioned in Czech as the default language – and you can make other languages available.  The expectation is that Czech is the native language so certain text such as the names of views and custom fields will also be Czech – but if you enable another language they will still see certain things in Czech.  This is one of the current anomalies we are investigating – View names, custom field names and some grid column headers are still showing English.  This does not appear to be an issue affecting all languages – more later. *** Update 10/1/2013 - it does now appear that ALL new PWA sites provisioned in a non English language will suffer from these same issues - existing sites are not affected. ***

If you have multiple languages available to users then the one they see will be governed by the setting in their SharePoint Profile.  Going to the About Me link under their login name top right, then clicking Edit profile – and then going to the ellipses and selecting Language and region will allow the selection of multiple display languages which can be ordered to the users preference.  See the blog referenced at the foot of this posting for a walk-through.

The BI Center should get provisioned in the same language as the main PWA – but here we are also seeing English.

And initially we just see an English directly for reports.  This part – just seeing one directly is again a timing consideration – and all the other language versions should appear within a few hours.

Overnight my main PWA site is looking better, with all Czech showing correctly (at least in this view) – although I’m half expecting at least one Czech reader will comment on some of the translations – and I’d be pleased to hear feedback.

The BI Center is still shown as English though (another anomaly we are investigating)  – but through Server Settings, Language Settings (as this is a different site than the base PWA) we can choose Czech as an offered language for this site.  It should show Czech as the default language – and certainly provisioning a Spanish site this works as expected and Spanish is the default.

Apart from the word ‘Reports’ all looks good.

And all the other language folders have appeared.

We are working to understand what is broken that is causing the non-English sites to not switch 100% – and hopefully we will resolve this soon.

One other issue worth mentioning here is that the UI when provisioning does allow for the selection of languages that are not supported for Project Web App – and currently the provision will fail – you will just see the spinning circle and provisioning will never appear to finish (but nothing is actually happening – it has already failed).  We are changing this behavior – but not removing the unsupported languages – but will have a fallback language – and the site will get provisioned.  I aim to do another blog post once I have more details of the fallback languages for the unsupported languages of Basque, Bulgarian, Catalan, Croatian, Estonian, Galician, Hindi, Kazakh, Latvian, Lithuanian, Serbian (Latin), Thai.  I could take some guesses at what the fallback languages might be – but I certainly don’t want to cause offence or any international diplomatic incidents – so I’ll keep quiet.

On a related topic – some other good resources for language packs for On Premises installations can be found at http://technet.microsoft.com/en-us/library/ff700192.aspx.  I also did a blog [post a little while back which talks about language packs for Project 2013, Project Server 2013 and Project Online – which can be found at http://blogs.technet.com/b/projectsupport/archive/2012/12/31/project-2013-and-project-server-2013-language-packs.aspx 

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
Line: 2
Char: 16751
Code: 0
URI: http://<servername>/_layouts/15/inc/pwa/library/shell.js?rev=VV59QN4O%2FYo%2BkyvfjP7EPg%3D%3D

***

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|redmond\brismith, 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.

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

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

*** Update 10/22 - latest info - see http://blogs.technet.com/b/projectsupport/archive/2013/09/13/project-server-2010-august-2013-cumulative-update-installation-latest.aspx - and October CU overcomes this issue too. ***

We are investigating issues relating to the installation of the August 2013 Cumulative Update (CU) for Project Server 2010, after installing Service Pack 2 (SP2).  The failure appears due to some incorrect schema versions either in SP2 or the August CU, and the error is: 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 = 14.2.151.0). 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.  This is because the normal process of database upgrade will remove some objects such as views and then re-create them – so in this case the re-creation did not complete.  Please do not just recreate the views – as has been suggested in another blog post – as although this may get things working, firstly you may not have the right definitions of the views if things have changed – and you are also likely to be missing other database objects – and you will likely see the same failure next time you load a Cumulative Update.

I should also point out that the August CU was re-released – and the version of the re-release is 14.0.7106.5002 http://support.microsoft.com/kb/2825959/en-us – part of our investigation is to determin if this re-release or the original (or both) suffer from this problem.

*** Update - 10/22 - (thanks for the prompt Stacy!) - both the original and re-release suffered from this issue - but the October 2013 CU handles things correctly ***

We are working on some recovery steps right now – and it appears that reducing the schema version and re-running the configuration wizard from the command line (psconfig) may be a suitable recovery method – and I’ll update this post with exact details once we have them.

I should also point out that the installation of the binaries for the August CU can be very slow – taking 5 hours or more – so please allow enough time when you do get around to patching.

Thanks to Adrian, Alex, Marc, Ray, Rogério and Solomon for their work on this issue – and information from some of our partners, Agora and TPG that has helped isolate the issue.