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.

In our previous article, we discussed Permission Levels for Project Web Access sites. We talked about how they were too liberal for most organizations and how to change them.

Unfortunately for us, the fact of the matter is that any changes you make to the default permission levels (in PWA or in a PWS) are not permanent, since the two Membership Synchronization processes overwrite them.

The PSI Methods for these two processes (QueueSynchronizeMembershipForWssSite and SynchronizeMembershipForPwaAppRootSite) can be found in the WssInterop service, which resides at http://ServerName/ProjectServerInstanceName/_vti_bin/psi/WssInterop.asmx. As previously discussed, both of them will delete and recreate the permission levels (or roles, depending which part of what document/interface/article/SDK you read) whenever triggered either by you or by Project Server.

One of the best aspects of Project Server is that it does the grunt work of collaboration and data collection for you. As Project Managers, we spend a lot of our time having meetings, preparing for meetings, reviewing and gathering status, and ensuring our plans are in line with expectations. Project Server allows you to handle the legwork for many of these tasks automatically.

Consider a standard status report that a team member fills out. Typically, these reports contain a list of issues, risks, past and future tasks, and a matrix of how their time was spent. The unfortunate downside of this method of communication is that the list of issues, risks, and tasks often becomes complicated and unwieldy on long projects or ones with more than a few people. Some teams choose to work around this by decreasing the detail provided in the report, but doing this obviously decreases the value of this report.

At many of my clients, I encounter situations where the default Permission Levels created by Project Server for Project Web Access sites cause problems. Typically, everything is going along just fine when suddenly one day PWA has a different theme or the “My Tasks” or “My Timesheets” page is blank and/or throws an error. While on occasion the error is legitimate, usually it is due to an inexperienced user editing the Shared version of the page. If you haven’t encountered this issue yourself, at this point you may be wondering how this is possible… The simple answer is that for many organizations, the default Permission Levels grant too much power to non-Administrative users.

When you provision a new Project Web Access site, Project Server creates four Permission Levels (described in this technet article):

• Web Administrators (Microsoft Office Project Server)
• Project Managers (Microsoft Office Project Server)

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.

When developing their software, Microsoft has always made ease of use and installation a priority. Microsoft puts a significant amount of effort into making the User Interfaces in their products efficient, intuitive, and friendly. This holds true for not only their client products, but also for their server products as well. Ease of deployment is one of the primary reasons why I love working with Microsoft products. Less time spent fighting through a difficult product installation means more time for implementing a truly integrated and comprehensive solution.

In today’s modern business environment, most organizations are familiar with the concept of a technology consultant. However, while many organizations tend to use the title consultant and contractor interchangeably, the job of a consultant differs significantly from that of a contractor.

A contractor is typically a specialist in a particular discipline or product, often serving as staff augmentation or hired to perform a specific task. Typically, the job that needs to be done is relatively simple, but the organization lacks the capacity or skill to perform it. Contrast this with consultants, who are typically multidisciplinary generalists who specialize in the creation of one or more types of comprehensive solutions that leverage technology to solve business problems. They may or may not specialize in a particular platform or technology, and they may be very experienced technicians. As such, consultants may perform technical or implementation duties in addition to their other duties. When all is said and done, the true value of a consultant is their ability to “see the forest for the trees”, which is to say that they can view the work as a whole and strategize without getting overly caught up in the details until necessary.

One of my clients has recently deployed a Sandbox of Project Server 2007 with MOSS 2007 (both RTM versions). During the course of this deployment they installed a number of the SharePoint Language Packs, in addition to creating a custom theme for Project Web Access. After deployment, they started having problems with incorrect rendering of the ASPX pages, along with some people recieving numerous authentication prompts (sometimes up to 17). In addition, for some people the page renders correctly on the initial load but manifests these problems if refreshed.

I believe the problem is one of two things: the permissions on the custom theme files, or some unforseen interaction with the language packs. The client is presently conducting further testing to confirm this theory. I have also suggested they fully patch both PS and MOSS from RTM to the Post-SP1 Hotfix Rollup.

I recently encountered a situation where I would see literally hundreds of errors in the ULS logs like this:

01/18/2008 10:22:59.99 OWSTIMER.EXE (0×0600) 0×08F8 Windows SharePoint Services Timer 5uuf Monitorable The previous instance of the timer job ‘Config Refresh’, id ‘{3F51D43C-C7DD-403D-A63B-1163EA9B46A6}’ for service ‘{2F8D95DC-ECBF-4661-83AD-92CA4162CD4E}’ is still running, so the current instance will be skipped. Consider increasing the interval between jobs.

Every single Timer Job Definition was throwing these errors (sometimes hundreds of them) every time it was invoked. There were no other errors in the Application Log or ULS Logs, even with verbosity cranked all the way up. Alerts weren’t going out, the cube build was failing, and literally everything that relied on a timer job was nonfunctional. Restarting the Timer service alleviated the problem temporarily, but it would inevitably come back after the first invocation of the timer job.

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>