I recently encountered a situation where users attempting to login to a SharePoint 3.0 site when using the “Sign In” link were recieving an “Internet Explorer cannot display the Web Page” error. The Web Application was configured to allow Anonymous Access and to also use Integrated Windows Authentication.

No errors showed in either the Application or System logs. The IIS Logs displayed a 401 error:
2008-06-20 14:55:01 W3SVC96982807 ServerIP GET /_layouts/Authenticate.aspx Source=%2Fdefault%2Easpx 80 - ClientIP Mozilla/4.0+(BrowserIdentificationString) 401 1 0. Examination of the HTTP traffic with Fiddler showed the same 401.1 error.

Investigation of the Web Site’s properties in IIS showed that HTTP Keep-Alives were disabled — enabling them resolved the problem.

Integrated Windows Authentication (NTLM) requires HTTP Keep-Alives; this is because Microsoft’s NTLM for HTTP authenticates connections, not requests. This means that the HTTP connection must be kept open while the NTLM handshake completes. More technical information can be found here. There is no method that I know of to get around this limitation other than to not use NTLM.

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.

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.

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.

Chris Fiessinger recently posted a list of links to the post-SP1 hotfixes here.

For your benefit, I’ve copied them here:

• Project Server 2007 – KB 941426
• Project 2007 – KB 941657
• SharePoint Server 2007 – KB 941274
• Windows SharePoint Services 3.0 – KB 941422

These hotfixes take advantage of Microsoft’s new Hotfix Request offering… Each KB article for a hotfix has a link whereby you can submit an email request for the hotfix. Microsoft will respond with links to the hotfix. This should save you from having to call PSS every time you need a hotfix. However, if you choose to use these hotfixes, please remember that they have not been fully tested and you may experience some unexpected behavior.

Popularity: 48%

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:

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.

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.

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>