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.

Within the Project Object Model, the Application object has a method, FieldNameToFieldConstant(), that returns a PjField constant for use by the various SetField() and GetField() methods throughout the object model. More information on the SetField Method (and other associated methods) can be found here.

Unfortunately, when using the PSI, there’s no quick way to lookup the Guid for a field. This can be a problem, since the various CustomFieldsRow objects (Task, Resource, Assignment, and Project) do not include the name of the custom field, only the UID (for an example, look at the ProjectCustomFieldsRow entity in the Project 2007 SDK).

Retrieving custom field information in the PSI is accomplished by using the CustomFields web service. The code below is a class that implements a method to retrieve the Guid of a custom field using the field’s name and entity type. I had to chop the code up a lot because of space constraints, so I apologize for the excessive line breaks. This code assumes that you’ve set up a Web Reference to the CustomFields web service named WebSvcCustomFields.

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.