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.

Earlier today in the EPMFAQ Forums, there was a discussion concerning an issue in Project 2007 whereby the Duration on a Fixed Duration task is set to 0d if the Work on that task either rolled up or was set to 0h.

This is divergent behavior from Project 2003, and one that appears to be causing issues for a rapidly increasing number of users. Many of us within the community have been aware of this issue for quite some time, but there appear to be many people that are unfamiliar with this little conundrum, be they users, administrators, or consultants.

Here’s my response to the question:

The issue you are referring to manifests when the Work for the task is set to 0h, whether by rollup or entry. This results in the task’s Duration being set to 0d. This is true for all Task Types, including Fixed Duration.

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)

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.

As I’ve previously discussed, at my present client we recently were working very closely with Premier Support to resolve some issues with the cube build. Throughout the course of these discussions, I was told that I really should be running DB Maintenance Plans on the PS07 DBs because with the switch to GUIDs in Project Server 2007, the indices in the various databases can become stale very quickly.

My response to Premier was that since Microsoft has provided no guidance on doing this, and since Microsoft has made such a big deal about not touching any of the databases except Reporting (or Published in very limited circumstances) implementers (including myself) are concerned about doing ANYTHING with regards to Maintenance Plans without guidance from Microsoft.

Premier responded that Chris Fiessinger wrote a blog post about this recently. The agent I was working with gave me advice on how to set up the jobs in the maintenance plan, and promised to press the Product Group to put out some official guidance in the near future.

At my present client, prior to the release of Project Server 2007 SP1, we obtained and deployed the hotfix rollup described in KB939594 to resolve some of the issues present in the product prior to the release of SP1.

Unfortunately, after deployment of this hotfix we discovered that when building the cube it would take significantly longer than RTM to build. Specifically:

• Cubes built with earliest start and latest finish would take an hour and a half or more to build
• Cubes built with a timeframe of 36 months forward and 13 months back 7+ hours to build and would cause the TempDB to get HUGE (in excess of 200GB)

When running the Cube Build without a date range, the cube would build in an hour or two — but as soon as you introduced a date range, the cube build would jump to 7+ hours, if it was even successful at all. More often than not, however, it would simply grow the TempDB to around 250GB, filling up the disks that the SQL databases were stored on and fail.