With this posting I am trying out some of the features of Windows Live Writer that I haven't used yet - so we have pictures!
You can install language packs on Microsoft Office Project Server 2007 which will allow users to view the PWA pages, and also create Project Workspaces in selected languages. This is similar to the Multi-Lingual User Interface in Project Server 2003 but because we are now using Unicode there are not the limitations with different code pages that we faced in the previous version. As an example I have the following PWA site provisioned in English. An you can see in the list of workspaces I have a workspace with a name in Japanese (in fact the Japanese word for "Japanese").
A Japanese user could modify their IE settings (Internet Options, then the Languages button on the front page) to make Japanese the preferred language.
Refreshing the page above would then give the following page, with the majority of the text in Japanese. Certain elements stay in the language it was provisioned in - such as the tab title of Home, the web part names and the links to Shared Documents. Also in this example I have a modified link to Timesheets which reads Timecard - so does not have a translation.
Once a language pack has been installed then a new PWA instance can be provisioned in the language of that pack - and the choice of languages is made on the Create PWA page.
Likewise you can select the language for any Project Workspaces by updating the language on the Project Server Workspace Provisioning page. The following is set for Arabic, but viewed in French.
Once a Project Workspace is provisioned it is only available in the language it is provisioned in - so for example the following is the Japanese workspace seen in the list on the first image.
So as a final taster of the support for right to left languages here is a PWA site provisioned and viewed with the IE setting for Hebrew.
For part 2 of this series I will take a look at the client language packs for Microsoft Office Project Professional 2007.
Technorati Tags: Project Server 2007
The download page for language packs at http://www.microsoft.com/downloads/details.aspx?FamilyID=2447426b-8689-4768-bff0-cbb511599a45&DisplayLang=en allows you to load language packs for many languages on top of your native installed language. For SharePoint this allows you to create sites in different languages. In Project these language packs do what the Multi-Language User Interface (MUI) did for 2003 and before - so two users can see the same PWA site in different languages, based on their IE language preference.
The download page however does not distinguish which languages will and will not work for Project Server 2007 - as only a sub-set of the Office ones are supported. The download page also just has a link for the SharePoint deployment page and not the Project Server one which can be found at http://technet2.microsoft.com/Office/en-us/library/7ac79302-38b1-4187-bbd5-ef9f53c6f9031033.mspx?mfr=true. The main difference is that for Project you need to install the language pack on your application servers as well as the web front ends. Load and run the configuration wizard on each server in your farm.
The languages supported by Project Server 2007 are listed on the page linked to above - but more importantly the ones SharePoint supports but Project Server 2007 DOES NOT support are:-
Bulgarian, Catalan, Croatian, Estonian, Hindi, Latvian, Lithuanian, Portuguese – Portugal, (Portuguese – Brazil is supported), Romanian, Serbian, Slovak, Slovenian, Thai, Ukrainian.
If you install these then the propagation of other MUI languages may be affected and you may not be able to see languages you expect to, and you will get many errors in your application event log referring to a file - notifications.sql - which cannot be found for these languages.
I will do another post soon (vacation next week!) on the use of language packs both on the client and the server, but just as a taster 2007 handles this much better than 2003. This week I worked on a project on a Korean version of Project Professional 2007 (US English plus Korean language pack for the project client) and created tasks in English, Korean, Japanese and with various European accents, then saved to my US version of server which had many of the language packs installed. I then changed my client language to Greek, re-opened the project and could see everything I had saved. After publishing I could even view my PWA site in Danish and view my project along with the tasks in the different languages. What? Next you want us to translate the tasks? One day...
If you have the right database permissions it is perfectly possible to point Project Professional 2003 at a Project Server 2007 database using the save-as option and specifying an ODBC connection. Please do not do this! Reason 1 is that it will not work and will give an error message, but reason 2 is that it could come back and haunt you later. In failing it does try to make the database look like a 2003 version, and it adds some data, and even adds some columns to tables where it thinks they are missing (I said you need the right permissions so only someone with a high level of SQL Server access would get this far).
The time you find the failure is if you ever try to recover your system on another server (or even the same server after a re-build). These extra columns then cause a failure of the PWA provisioning process against the set of databases. During the creating databases stage it will fail with a "Failed - See the Event Log" error. In the event log will be Exception: Insert Error: Column name or number of supplied values does not match table definition. You will now have an MSP_TASKS table with 130 columns compared to the expected 128 - so when it tries to create a stored procedure that will later be used to copy data from MSP_TASKS to MSP_TASKS_SAVED the columns no longer match. The extra columns are:-
Other evidence of the issue is:-
Recovery is reasonably painless, the extra columns can be deleted, and then provisioning will work.
One problem I have seen a few times is the Project Web Access site provisioning running into issues. If it fails completely then the error messages are pretty good - and you can generally resolve the issue and re-try and everything will be good. However, what do you do when it just sits on "Waiting for Resources" and nothing happens? The quick answer is that this relies on the SharePoint Timer Service and a couple of Shared Service Provider services that can be viewed through Timer Job Definitions (Shared Services Timer Job and Project Server Synchronizing Job for 'SharedServices1' - or whatever yours is called). If these are not running then you will be "Waiting for resources" for a very long time! Also there could be multiple versions of the timer jobs if you have multiple SSPs so it can get confusing, particularly as the first one does not differentiate by name. (Clue - the JobId in the URL for the job is the Id of the timer job row in the Objects table in SharePoint_Config database, and the Properties column from this row will lead you to the Guid of the TargetSharedResourceProvider - which will be the Id of the Shared Services Provider also in the same table.)
So to dig a little deeper so you can understand where it might be stuck I'll explain what is going on in the background which hopefully will help you find what is stopping it from working.
So, step 1 - you have been on the Create a Project Web Access Site page (CreatePWA.aspx) and entered all the details, and it goes back to the Manage Project Web Access Sites (ManagePWA.aspx) page and just sits there. At that point a row has been added to the MIPScheduledJob table in the SharedService1_DB (your database name may vary - this is the default). This is a pre-synchronizing job for the site, and is added to the database by the account running the Shared Services Provider application pool.
Step 2. The Shared Service Timer Job picks up the row from this database table and adds a row to the SharePoint_Config database Objects table. In the properties field of this table is some XML describing the site to be built, database names etc. This timer job will run as the account of the farm administrator (i.e. the account running the OWSTIMER service)
Step 3. The Project Server Synchronizing Job for 'SharedServices1' sees this row and actions it by creating the site, creating the database and then configuring the instance of PWA. If everything is working you see the status change on the ManagePWA page as these different stages are processed, and finally it will say Provisioned! Again, this timer service runs as the farm administrator.
Waiting for resources will be seen until the early stages of step 3.
So check all your services are running and your timer jobs are present and enabled and all should be good. One other workaround that generally gets things moving again is to create a new Shared Services Provider - which will then create new timer jobs and overcome any underlying issues. The web applications can then be associated with the new SSP, the new SSP can be made the default if you are not using the old one for anything else, and the old one could be deleted.
I mention the databases here on the condition that you can look - but don't touch!
Just when I thought I'd seen nearly all of the error messages possible when building a cube along comes another one. And the longest yet! I won't bore you all with the full error message but the key piece is:-
and so it goes on for another 3 or 4 pages...
The reason this happened was that the customer has the Project Server databases on a named instance of SQL - lets call this "server1\PS2007". When provisioning the PWA site from their application server they used an alias for the instance - lets call this "SQLServername". Now when they ask for a cube build the servername that gets passed over to Analysis Services for use when connecting back to the Reporting database is SQLServername (and not the server1\PS2007). But the Analysis Serices server does not have the alias set - so does not recognize SQLServername - hence the error. Resolution is reasonably straightforward - just make the alias available to the Analysis Services machine and all is good!
*** Update *** For a slight variation on this regarding 32 and 64 bit aliases - see http://blogs.msdn.com/brismith/archive/2009/10/08/project-server-2007-another-olap-cube-building-gotcha-is-your-alias-32-or-64-bit.aspx