Back in April, I posted an article where I recommended that you install the latest CU for SQL 2005 (CU7).

Since then, I’ve recieved feedback regarding some issues introduced by this CU. It would appear that they are more of an issue than I originally thought. Based on this feedback, I’m going to recommend that you all stick with CU6 for the time being.

Popularity: 26%

Quick post today… just for reference, the version numbers for the various major hotfixes and service pack.

RTM: 12.0.4518.1016
SP1 (KB 936984): 12.0.6218.1000
Post-SP1 Hotfix Rollup (KB 941426): 12.0.6300.5000
April 3rd, 2008 Hotfix (KB 950816): 12.0.6309.5000

Update: Chris Fiessinger posted an article back in December detailing the four ways to retrieve the version information from Project Server. The version numbers above should align to those returned by the PSI and within the Published DB.

Popularity: 25%

At a previous client, I encountered an issue where, when creating or viewing certain views in Data Analysis, the Analysis Services service would spike in processor/memory utilization and become unresponsive.

I have recently discovered that this is a known issue in environments that have an interaction between Office Web Components and SQL Server 2005 Analysis Services with Service Pack 2 (which means Project Server).

Although I’m not 100% sure, I believe the KB that covers this issue is KB936251. The symptoms seem to fit.

At any rate, I have been told that the resolution was included way back in SQL Server 2005 Cumulative Update 2. I recommend that you install the current CU, which is CU7, due to the number of fixes it contains. UPDATE: I’ve recieved information that CU6 is a better choice due to some issues introduced by CU7. I’ve posted a followup article here.

At one time or another, almost everybody recieves an error while working in Project Server 2007’s Project Web Access. By default, SharePoint (and therefore Project Server 2007) are configured to present what are known as “custom” errors. These are an inherent part of ASP.NET that allow developers to create friendly error pages to report errors rather than the stock ones provided by the .NET Framework. These pages are generally simplistic and often leave out a great deal of information, such as stack traces. The reason for these pages is chiefly to spare the user the gory details of whatever unhandled exception just occurred. Unfortunately, not every error is or can be logged. This causes an obvious problem in Project Server deployments — especially when trying to resolve a transient error.

Are you seeing one or more of the following Event IDs (6398, 6482, and 7076) in your event log approximately every minute? Many of our clients have seen these errors indicating insufficient storage on their MOSS/WSS/Project Server farms, but are unable to find exactly what the errors refer to. Upon investigation, they generally find that there is sufficient memory and hard disk space on all servers in the farm (including SQL Server). However, even in cases where the amount of available storage is lacking, expanding the amount of available storage does not make the errors stop.

The full errors are:

In Brian Smith’s recent post about the PWA Administrator that you select during provisioning, he points out that there is nothing special about this account — as you know, this account is the first admin in the system. According to Brian, it is also set as the administrator for the PWA site collection:

The first administrator is also set as the primary administrator of the site collection created for the PWA site. You can update the user in this case using stsadm -o siteowner. The parameters for this command are -url -ownerlogin -secondarylogin

My personal practice is to set the PS07 Service Account as this “primary admin” to ensure that it always has access. After provisioning, I log in as the service account and create the other administrators as needed. During post-deployment knowledge transfer, I strongly discourage clients from ever making any changes to the service accounts used during configuration (e.g. passwords, changing to another account entirely). While it’s possible to go through and change all the passwords, it’s labor intensive and error-prone, and any missteps during that process will cause issues in the environment.

Super-quick tip… When reviewing the traffic logs for the week, I noticed that someone had arrived here searching for the Administrator password for Microsoft’s EPM2007DEMO VPC.

So, if you happen to return:

Username: FarmAdmin
Password: pass@word1

All of the passwords you need are on Pg. 26 in 2007 Microsoft EPM Solution Demo Image Installation Instructions.doc, which is included in the package for the VPC.

HTH!

Popularity: 52%

A few of our clients have reported that after customizing a Project Workspace or deploying a customized Project Workspace, they begin to see Reporting (WSS Sync) errors in their queue:

When they view the details of this error, they see the following details (duplicate lines removed for your convenience):

Error summary/areas:
Reporting Wss list sync failed
ReportingWssSyncListFailed
Reporting message processor failed
ReportingWSSSyncMessageFailed
Queue
GeneralQueueJobFailed

Error details:

<errinfo>
<general>
<class name="Reporting Wss list sync failed">
<error id="24018" name="ReportingWssSyncListFailed" uid="7e7fa8da-24d4-4c4d-a9ab-c32ed46e205c" SPListType="1100" Error="Failed to prepare the transfer of SP list 1100 for project ‘89ec6841-1f56-46b1-b97b-d775f0ca7e06′. The field Category was missing from the SP list and was ignored." />
</class>
<class name="Reporting message processor failed">
<error id="24016" name="ReportingWSSSyncMessageFailed" uid="79d63cef-5a83-46b1-bc6c-c0124311b60f" QueueMessageBody="ProjectUID=’89ec6841-1f56-46b1-b97b-d775f0ca7e06′. ForceFullSync=’False’" Error="RDS failed while trying to sync one or more SP lists. The RDS queue message will be retried." />
</class>
<class name="Queue">
<error id="26000" name="GeneralQueueJobFailed" uid="b04b7077-731c-4149-87ac-89af07377229" JobUID="ba088e4e-781a-4bc4-b787-3e24ac2849ec" ComputerName="EPM2007DEMO" GroupType="ReportingWSSSync" MessageType="WSSSyncMessageEx" MessageId="1" Stage="" />
</class>
</general>
</errinfo>

When building a cube for the first time,  a deployer will sometimes see an error similar to the following error message in the Cube Status screen:

Failed to build the OLAP cubes. Error: Analysis Services session failed with the following error: Failed to delete the Olap database: PWA_AnalysisServices. Error: Your permissions on the server computer do not allow you to administer this Analysis server. Error:

Typically, this error is caused by failing to correctly or completely follow the directions outlined in this article on configuring Analysis Services 2005 to work with Project Server 2007. It can also caused by not restarting Analysis Services after you give the SSP account administrative permissions to Analysis Services — this does not appear in the aforementioned article, but it is sometimes required.