Cascade Skyline - with Microsoft Logo and Project Support header - author Brian Smith

February, 2011

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Language Pack Update

    • 8 Comments

    A quick revisit to the Language Pack topic – and a clarification on which languages work with Project Server 2010 – and what do I mean by ‘work’…  In 2007 there were some SharePoint language packs that were ‘not supported’ with Project Server and these could cause issues.  In 2010 there is still a distinction, but now we do support all the languages that SharePoint support, but the level of functionality varies.  We now have the languages that will allow you to see Project menus in the localised language, as well as allowing provisioning of your PWA site in that language and creating project sites – and a small subset of languages which can still be installed if Project Server is present – but will not change how Project Server is displayed (in the TechNet documentation these are termed Compatible languages).  These will give localisation of any SharePoint features used by Project – one example being the Site Actions area.  So an example, and for this I will use the new Galician language pack for SharePoint Server 2010.  Once the Language pack is installed (see our Deployment documentation) and you have run the configuration wizard you will need to go to any sites where you wish to use this new language pack and make it available.  Site Actions, Language settings (under the Site Administration heading).  So here I am turning on Galician for my Central Administration (also note that your default language is shown here – in my case English).

    image

    If I then choose Galego as my Display Language I can see my central admin page in that language

    image

    If I do the same for a Project Web App site I only see a couple of the SharePoint elements showing in Gelago, the remainder shows in the default language – which in my case is English.

    image

    but in Accións do sitio I see the SharePoint support for this language

    image

    As a reminder – if I choose a fully supported Project Server language then I get the full language experience on Project Web App – such as this display in Hebrew

    image

    One final catch with the ‘compatible’ languages is that when we first shipped the RTM release of Project Server 2010 there was a bug that would cause the upgrade of any Project Server 2007 system, including a database attach upgrade, to fail if one of the compatible languages was loaded.  The error would look something like this – which was the result of trying to upgrade Project on a Spanish system that also had the Basque language pack loaded.  The highlighted number indicates the LCID for Basque – 1069.

    No se pudo realizar el aprovisionamiento del sitio PWA con error: Microsoft.SharePoint.Upgrade.SPUpgradeException: Action 14.0.248.0 of Microsoft.Office.Project.Server.Upgrade.PublishedDatabaseSequence failed. ---> Microsoft.SharePoint.Upgrade.SPUpgradeException: Failed to retrieve localized script for LCID: 1069 section: published version: 14.0.248.0 ---> System.IO.DirectoryNotFoundException: No se puede encontrar una parte de la ruta de acceso 'C:\Program Files\Microsoft Office Servers\14.0\Sql\Project Server\CORE\1069\LocalizedUpgrade.xml'.

    This was quickly resolved, and released in the June 2001 2010 (thanks Ben!) CU for Project Server 2010 – and included in all CUs since – so if you are upgrading from 2007 and have one of these compatible languages installed as a SharePoint Language pack then you should ensure your 2010 farm is upgraded with a CU – and not just at the RTM level.  The compatible languages are:

     

    • Basque (1069) – new addition
    • Bulgarian (1026)
    • Catalan (1027) – new addition
    • Croatian (1050) – at the time of writing the link to this one appeared broken
    • Estonian (1061)
    • Galician (1110) – new addition
    • Hindi (1081)
    • Kazakh (1087)
    • Latvian (1062)
    • Lithuanian (1063)
    • Portuguese (Portugal – 2070)
    • Romanian (1048)
    • Serbian (Latin - 2074)
    • Thai (1054)

    The ones that are fully functional are – Arabic, Brazilian, Chinese (SC), Chinese (TC), Czech, Danish, Dutch, English, Finnish, French, German, Greek, Hebrew, Hungarian, Italian, Japanese, Korean, Norwegian (Bokmal), Polish, Portuguese (Brazil), Russian, Slovak, Slovenian, Spanish, Swedish, Turkish, Ukrainian

    On the download page for the Language Packs it isn’t obvious which ones are in this list (I’m hoping to get that rectified) but when you download you will see it either say installing for SharePoint Server 2010, Project Server 2010 and Office Web Apps 2010 – or just SharePoint Server 2010 and Office Web Apps 2010.  It is also obvious from the Control Panel, Programs view which are which – and as you can see I have a selection loaded of both types:

    image

    And the final question I am sure you want the answer to – if you haven’t Bing’d it already – Galician (Galego) is a language spoken in Galicia – an area of northwestern Spain, and just across the border into Portugal.  Who knows – we might even get a UK English localisation one day?

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Common Project Web App (PWA) Provisioning Problems

    • 6 Comments

    This post rounds up a few of the more common issues that customers run into – either when provisioning a new Project Server 2010 Project Web App (PWA) site – or more commonly when provisioning a site against a set of existing databases (either 2007 or 2010 databases).  As you should know by now Project Server 2010 supports provisioning against a full set of 5 existing databases – the usual 4 project ones (Archive, Draft, Published and Reporting) and also the Content DB that contains a the PWA site you want to provision against.  The first thing to remember is that you cannot restore a Content DB to the same farm to make a copy of a PWA site – even on a different port.  You will get an error like this, and following the workaround in the message will not help you create a duplicate:

    The attach operation cannot continue because another object in this farm already contains the same ID. Each object in a farm must have a unique ID. In order to proceed with the attach operation you must assign a new ID to this database. To attach this database with a new ID, use the Mount-SPContentDatabase command with the -AssignNewDatabaseId parameter. Note that if this new database and an existing database contain the same site collections, attaching this database will likely result in orphaned site collections due to conflicts between the two databases.

    So not directly a provisioning problem – but one error you may run in to if you try to duplicate a PWA instance within the same farm.

    The next group of scenarios will generate the same error – and I’ll list the various reasons this error may appear.  In this scenario I am restoring and provisioning against a set of databases from another server.  The first thing you will see is “Failed – see the Application event Log” and when you open this you will see a series of errors, the first being the generic Event ID 7070 (Source: Project Server, Task Category: Provisioning)

    Provisioning 'PWA': One or more of the databases already contains schema. When editing or creating a Project Server instance, you may specify:
    * Four databases that do not exist
    * Four existing, blank databases
    * Four existing Project Server databases of the same version from the same installation.
    Combinations of blank, new, and existing databases are not allowed.

    Followed by Event ID 6993

    Provisioning 'PWA': Failed to provision databases. An exception occurred: Provisioning failed because the databases specified did not match.

    then Event ID 6958

    Provisioning 'PWA': Database provisioning failed.

    and finally Event ID 6971

    Failed to provision site PWA with error: Microsoft.Office.Project.Server.Administration.ProvisionException: Failed to provision databases. ---> Microsoft.Office.Project.Server.Administration.ProvisionException: Provisioning failed because the databases specified did not match.
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)
       --- End of inner exception stack trace ---
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.CreateSite(ProjectProvisionSettings provset)

    You will see exactly the same errors in the ULS logs – and the more useful information level log EventID 6975, which will read something like this – although yours will likely vary depending on the reason for your failure (I know why mine failed already, because I broke it on purpose).  I have also put in some line breaks to make it more readable for each of the databases.

    Provisioning 'PWA': Databases specified for site 'ProjectServer' are as follows:

    • Published: Name = 'Proj_Published', State = NotCreated
    • Draft: Name = 'Proj_Draft', State = ProjectSchema
    • Archive: Name = 'Proj_Archive', State = ProjectSchema
    • Reporting: Name = 'Proj_Reporting', State = ProjectSchema

    It then becomes obvious that my Published is the one that is different – and if I go back and check what happened I will discover that when I restored my Published database I accidentally named it Prj_Published and not the Proj_Published that I entered on the PWA provisioning page.  Just re-name the DB and try again and all will be well. The type could happen either when restoring or when provisioning – but will give a similar error.  A slight variation on this theme is if the database you type exists but is just empty (you haven’t restored anything yet) – and you will see a state of Empty.

    Provisioning 'PWA': Databases specified for site 'ProjectServer' are as follows:

    • Published: Name = 'Proj_Published', State = Empty
    • Draft: Name = 'Proj_Draft', State = ProjectSchema
    • Archive: Name = 'Proj_Archive', State = ProjectSchema
    • Reporting: Name = 'Proj_Reporting', State = ProjectSchema

    The other thing that is checked when restoring is that the databases actually are a “matching set” and this is done in a couple of ways.  There are a couple of extended properties defined on the Project Server databases (you may also have your own defined for various purposes) and the first of these is the ProjectCollectionGuid – and this should match for all of the 4 project databases.  If for some reason this does not match then the failure will be similar to the ones above – the same event log entries in terms of EventID, and this time the ULS log EventID 6975 looks OK:

    Provisioning 'PWA': Databases specified for site 'ProjectServer' are as follows:

    • Published: Name = 'Proj_Published', State = ProjectSchema
    • Draft: Name = 'Proj_Draft', State = ProjectSchema
    • Archive: Name = 'Proj_Archive', State = ProjectSchema
    • Reporting: Name = 'Proj_Reporting', State = ProjectSchema

    but looking closer at the Application event Log Event ID 6971 (or the ULS log version) will show a slightly different error:

    Failed to provision site PWA with error: Microsoft.Office.Project.Server.Administration.ProvisionException: Failed to provision databases. ---> Microsoft.Office.Project.Server.Administration.ProvisionException: Mismatched databases.   
    at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)     -
    -- End of inner exception stack trace ---   
    at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)   
    at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.CreateSite(ProjectProvisionSettings provset)

    So Mismatched databases, rather than Provisioning failed because the databases specified did not match – very similar meaning, but different root cause and different type of mismatch.  The solution here is to ensure that your set of databases came from the same set – you cannot expect things to work if you mix things up with databases from different PWA instances. 

    The only exception I would make here is a trick we sometimes use in support to avoid having to get customers to send us all 4 databases if our repro of their issue does not require the Archive or Reporting databases. You can fool Project Server into provisioning with an ‘empty’ archive and reporting database, as long as it isn’t really empty – but just has schema (all the tables, views etc.) created in the same version of Project Server (usually by just provisioning a new site and backing up and then restoring the archive and reporting db).  In this scenario you would copy the ProjectCollectionGuid from the draft or published to the archive and reporting – to ensure they all matched.  Not something you would do in production – as you would lose reporting data (and yiur archive) – but might make sense for some transfers to a development system for example.

    The final mismatch that can occur and can be more difficult to spot the problem – is if you accidentally restore your databases to the wrong type – and to simulate this error I restored my Draft database but accidentally chose the backup of my Published database to restore it from.  The Event log errors are the same as the original ones – and the information message from the ULS EventID 6975 looks like the ‘typo’ problem – but the secret to the failure is in the other Extended Property – the ProjectDatabaseType.  In this case my extended properties look like this:

    image

    And the name of the database is typed correctly – but the ProjectDatabaseType should be ‘Working’, but instead says ‘Published’.  So Draft has a Type of ‘Working’ - Archive has a type of ‘Versions’ – Published and Reporting use the same terms.  Obviously the only way to resolve this is to restore the correct databases.  Just changing this value will likely lead to very bad things…

    Moving on from mismatch issues, here are a couple of issues that you might see once Language Packs come in to play (and I’m not specifically going in to different SQL Collation issues – but they can give problems too – perhaps another post for this next time I have a good repro to document).

    I’ll document the errors first, and then give details of the cause:

    The first error from the Application event log – Event ID 7110

    Failed to connect Proj_Published to PWA because the language of the database (English) does not match the language of the site (Portuguese - Brazilian).

    followed by the 6993 and 6958 errors we have already seen, and then the 6971, but again with a slight variation on the text.

    Failed to provision site PWA with error: Microsoft.Office.Project.Server.Administration.ProvisionException: Failed to provision databases. ---> Microsoft.Office.Project.Server.Administration.ProvisionException: Language of database does not match language of site
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.CheckMatchingLcid(Int32 lcid, String connectionString, String siteName)
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)
       --- End of inner exception stack trace ---
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.CreateSite(ProjectProvisionSettings provset)

    In this case I took a backup from an en-US site, and tried to provision on my en-US server with the language setting changed to pt-Br.  So even if you have the language pack installed (en-US in this case) you cannot change the base language of a provisioned set of databases – you must provision in the same language.

    One slight variation on this theme and switching to a Project Server 2007 scenario  – which had me confused for a while, was the following scenario.  I was sure the site was US English – so tried to provision and got this error (Event ID 7110)

    Failed to connect Proj_Published to PWA because the language of the database (Portuguese - Brazilian) does not match the language of the site (English).

    OK, lets try that with pt-Br selected – hmm – Catch-22…

    Failed to connect Proj_Draft to PWA because the language of the database (English) does not match the language of the site (Portuguese - Brazilian).

    I have changed the nationality of this customer – to protect their identity – but they had been using an undocumented, unsupported workaround to get notification e-mails in a different language than the base – by updating the WADMIN_DEFAULT_LANGUAGE setting.  In 2007 this existed in both the Draft and Published databases – and if the two didn’t agree you would get this bizarre situation when it wouldn’t provision in either language.  In 2010 we only have that table in the Published database – so only see the first occurrence of this error.  If you tried to provision in the ‘other’ language then it would work – and your site would be provisioned be in that other language – but I think I’d have to say this isn’t supported as I am certain this wasn’t a tested scenario…

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Take care changing custom fields to allow multiple values

    • 3 Comments

    One of the options when setting up a custom field is to allow it to have multiple values selected from the lookup table.  There are however some downsides to this, and a recently discovered bug makes one of these downsides a higher risk than it should be.  This relates to OLAP cubes – and the fact that custom fields with the ability to select multi values cannot be added to cubes.  First a reminder of where this value is set:

     

    image

    Problems begin when you wish to change this later to a multiple value option custom field – and it is already in a cube configuration.  The exact nature of the problem will depend on whether your data was migrated to Project Server 2010 from an earlier version or not – and if so, if the custom field was already added to the cube. 

    I’ll deal with the case of migrated/upgraded data first.

    If you select the check-box for a field that was included in a cube before you upgraded to 2010 then try and save you will get the following message – regardless of whether the field is in a cube currently or not.

    The custom field could not be saved due to the following reason(s):

    • "The selected custom field is currently part of one or more Project Server OLAP cubes and the change requested is not supported by the cubes. Select a valid setting or remove the custom field from the OLAP database(s)."

    There is no way to make the change, as the validation checking that it isn’t in a cube is not working correctly in 2010.  If you are in this situation and really, really want to make this change then best open a support incident.  Remember – the change from single to multiple value selection is NOT REVERSIBLE!  So please be very sure you want to make the change.  In this case even deleting the cube will not help.

    For brand new 2010 installations the root of the problem is the same, but with different results.  If your custom field has been added to a cube configuration and you then choose to allow multiple values then the validation will think everything is OK, and that your field is not in a cube when it actually is.  This will mean that the save of the change will succeed.  If you view the cube configuration it will look like the field has been removed – whereas in fact it has just been filtered out as it is now multi-value.  The end result is that you never got the warning – you didn’t get the chance to reconsider if you could live without this field in the cube – or if you really needed multi-value – and to top it all your cubes will no longer build.  The error will be something like

    Failed to build the OLAP cubes. Error: InitCustomFieldDimensions cannot process the Project custom field 'ProjectColours'

    There are a couple of workarounds though, depending if you are reading this having hit the problem – or lucky enough to see it while still thinking about making such a change.  If the field is removed from any and all cubes that it is included in BEFORE making the change to multiple value then all will be OK (but as mentioned – only for new 2010 systems – upgraded ones will get the error above).  If you already hit the issue then the easiest option would be to delete the cube and build a new one – but this doesn’t help if you really decided you couldn’t live without this data in the cube...  Also you can’t delete the default cube – so you may need to create another cube – delete the first one and then rename the second one back to the same name as the first.

    Another option in either case would be to create another custom field and let that one have multiple values – leaving the original one exactly as it was.

    No current dates I can give you for a potential fix, but as mentioned earlier – log a call with support if you have run in to this – no charge as it is a bug.

Page 1 of 1 (3 items)