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

  • Brian Smith's Microsoft Project Support Blog

    A couple more cube build error messages you might come across.

    • 8 Comments

    A couple more cube build error messages I have seen recently.  The first is related to a time out with Analysis Services 2005 and the clue is that failure will be just over an hour into the build (assuming the timeout is still the default 3600 seconds).  The error is:-

    • Failed to build the OLAP cubes. Error: Analysis Services session failed with the following error: Failed to process the Analysis Services database <cube name> on the <Analysis Server name>  server. Error: Internal error: The operation terminated unsuccessfully
    • Internal error: The operation terminated unsuccessfully. Internal error: The operation terminated unsuccessfully. OLE DB error: OLE DB or ODBC error: Unspecified error. Errors in the OLAP storage engine: An error occurred while processing the 'Assignment Timephased' partition of the 'Assignment Timephased' measure group for the 'Assignment Timephased' cube from the <cube name>  database.

    The first part of the error message will be localized if you are using a MUI - the second will not.

    To resolve the issue set the advanced property ExternalCommandTimeout to a value that will allow the building of the cube.  The default is 3600 (seconds) which is one hour.  Increasing to 36000 will be ten hours.  The value could be increased further or reduced depending if the cube builds within this modified time.

    To change the value of the timeout property go to Management Studio for SQL Server 2005 and connect to Analysis Services.  Right click the server name in the left pane and select Properties.  Check the option to Show Advanced (All) Properties then scroll down to ExternalCommandTimeout.  Change the value in the Value column then click OK.  A restart is not required.

    Another workaround would be to reduce the complexity of the cube build by either limiting dates or removing some or all added dimensions.  This workaround is unlikely to be a workable answer for most customers.

    The fact that a restart of the service is not required leads me to the second error message, which can appear if you do restart and then immediately try another cube build:-

    • Failed to build the OLAP cubes. Error: Analysis Services session failed with the following error: Failed to connect to the Analysis Services server <Analysis Server name>. Error: File system error: Error opening file; \\?\C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Data\DBCUbe260.0.db\0.CryptKey.bin is not a disk file or file is not accessible. Errors in the metadata manager. Processing for the database will be disabled because an error occurred while loading the '<random cube name>' database cryptography key. One possible reason for this error is that the service account has changed. File system error: Error opening file; \\?\C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Data\FarmPWA.0.db\0.CryptKey.bin is not a disk file or file is not accessible. Errors in the metadata manager. Processing for the database will be disabled because an error occurred while loading the 'FarmPWA' database cryptography key. One possible reason for this error is that the service account has changed.

    There may well be other scenarios that give the same error, but for the scenario where you have just restarted the server then just try the build again and all will work. 

    Technorati Tags: Project Server 2007

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2007: Check-in still pending?

    • 36 Comments

    ***UPDATE***  Please see my posting on the December 2008 CU - http://blogs.msdn.com/brismith/archive/2008/12/17/project-server-2007-december-2008-cumulative-update-released.aspx.  The Project Professional 2007 CU - http://support.microsoft.com/kb/959643 has a fix for this issue!

    *** 2nd Update *** But also see http://blogs.msdn.com/brismith/archive/2009/02/11/project-server-2007-check-in-still-pending-even-after-december-cu.aspx 

    I replied to a comment on this topic – but think it warrants a new posting so I have polished my reply and added some stuff.  I am aware customers are still having some issues with check-in pending and I think it may be a timing issue around closing and opening Project.  I haven’t been able to repro this so would love to hear some consistent repro steps based on the August Cumulative Update – if anyone out there can make it happen to order.

    However, I have some ideas what might lead to the issue.  When you close Project we now give a message to ensure any saves that are in progress get a chance to complete.  However this only waits for the save from client to the queue to complete - then the "real" save from the queue to the database happens - then any publish and check-in jobs.  So the client may be closed when the check-in completes and so doesn't get the message – and will still think the check-in is pending.  On opening it takes a little while for the communication to the server and the responses for any updates on pending check-ins etc – and you may see a message Offline changes - and if the user does a File, Open immediately then they may see Check-in pending for a project that is really checked in.  This will not get updated while the dialog is open.  Either closing the dialog and re-opening - or opening a "pending" project (read only) and then closing should flush things through and get the project available. This is by far the best approach rather than clearing the cache as it does not risk any data loss.  The above symptoms may never appear on a very fast network, and may appear more often in a WAN situation where there is high latency between the client and server.

    But as I say, I haven’t been able to repro, even from home, where I have to traverse my home wireless network, then another wireless link a few miles across the valley before getting on to a T1 link and the internet.  Another few hops and I get to my server.  The ping time is a pretty respectable 50ms across 9 hops.  Just to add a little load to my server I set all my projects publishing from ProjTool too – but I never see check-in pending.  Perhaps I need to be saving a much larger project and have lots of custom fields at the task level?  So for any repro I’d also like to know project size, custom fields, network parameters such as a ping and tracert to the server.

    Technorati Tags:
  • Brian Smith's Microsoft Project Support Blog

    Project Server 2013 Requirements to build an OLAP Cube

    • 12 Comments

    There appears to be an error currently on our TechNet documentation at http://technet.microsoft.com/en-us/library/ee662106.aspx indicating that the version of the Analysis Management Objects required when building an OLAP cube from Project Server 2013 depends on the version of SQL Server you have running Analysis Services.  In fact it does not – and like previous versions of Project Server we actually require a specific version that our code talks to – regardless of which version it will actually be building the cube on.  For Project Server 2013 we require the ‘10.xx’ release so anything from RTM SQL Server 2008 Analysis Management Objects – version 10.0.1600.60 through to the SP2 of the SQL Server 2008 R2 10.50.4000.0 will work.  The only one that does not work in my testing is the SQL Server 2012 version.

    *** Update 11/13 - I should also point out that the requirement for the SQL native client is fulfilled by the SharePoint pre-requisite installer - so no need to add anything - but if you remove it then you will likely get an error like "Error: The 'SQLNCLI10' provider is not registered on the local machine" If this happens then just re-install SQL Native client 10.x such as the one from http://www.microsoft.com/en-us/download/details.aspx?id=30440 - look for sqlncli_amd64.msi. End Update ***

     

    If you have the 2012 version, or if you haven’t loaded any Analysis Management Objects then you will see the following error when trying to build a cube.

    image

     

    [11/12/2012 10:17 AM] Failed to build the OLAP cubes. Error: The attempt to build the OLAP database on server BriSmithSQL failed, the SQL Server Analysis Services Analysis Management Objects (AMO) client software may not be installed on this server, please install/update the client on this server and retry. The underlying exception was: Could not load file or assembly 'Microsoft.AnalysisServices, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.

    The SQL Server 2008 R2 SP2 version is the most recent and can be found in the feature pack at http://www.microsoft.com/en-us/download/details.aspx?id=30440 and you are looking for SQLSERVER2008_ASAMO10_amd64.msi (which is the x64 version) (***Update *** corrected the name - thanks Adrian!).  Direct download link is here. I haven’t tried building a cube against a SQL Server 2008 instance – that may need to use the earlier SQL Server 2008 feature pack – most recent is SP2 if you find the R2 version above doesn’t work.

    For those still having a hard time finding where we have hidden the cube building option (I admit it – it took me a while…) can find it either by going to Central Administration, Manage Service Applications, Project Server Service Application (or whatever you have called yours) and then use the drop down for the specific PWA site you are interested in and click Manage which will take you to the following page – and OLAP Database Management is the link you need:

    image

    Or Central Administration, General Application Settings, and click Manage under the PWA Settings header.

    image

    If you go this root you may need to change the PWA site in the upper right hand corner.

    image

    And if you are using the preview of Project Online (or you are reading this after the full release) and can’t find the link to OLAP cubes it is because that feature isn’t available in the online version.

  • 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

    Patience please - async processes at work

    • 23 Comments

    One thing that I have touched on before is the asynchronous behavior of the some of the processes in Project Server and Windows SharePoint Services 3.0.  This is still catching some people out.  For instance, if you provision a new PWA site and then decide you want to change something - so you delete it - it looks like it has gone right away.  However, the site collection that was created as part of the process (usually /PWA) takes a while to be removed.  This means you may see an error if you try to re-create the PWA site immediately.  Another point of confusion is the "Waiting to be processed" message in the queue service of PWA.  This can sit there and look like it is doing nothing, when it is actually waiting for some other background task to complete.  Canceling and retry may make no difference - it will go when it is ready.  Of course there are times when something has gone wrong and it will never process - such as the queue service not running.  Perhaps a password has changed - or a connectivity or permission issue is stopping the account running the queue service from being able to get to the jobs (the queue jobs are held in the Project Server database tables).  Normally a look in the ULS logs or event logs will give clues to both these types of failures and also sometimes the reasons why a job may just be sleeping.

     For some internal details of the queue service take a look at the TechNet article at http://technet2.microsoft.com/Office/en-us/library/0845d622-95ab-4c20-b419-0dbd5aab33a51033.mspx?mfr=true

    The most common time for patience if if you have saved and closed a large project to the server and you are working on a low bandwidth or high latency connection.  This scenario was virtually impossible with 2003 but with 2007 it can be done.  However the save and check-in of the project may still take a while from the point you click the button on the client - and you may well find that the project is still checked out if you try to open it up too soon.  And remember - force check-in will not speed anything up - this just puts another job on the queue!

    Technorati Tags:

     

Page 5 of 95 (475 items) «34567»