Install SharePoint 2010 RTM with a named sql Instance

I am installing a sharepiont 2010 farm with its configuration database in a remote sql server, and am using a named sql instance for its configuration database. During  running SharePoint Product Configuration Wizard, I keep getting the following clueless error message:

Cannot connect to database master at SQL server at ..... The database might not exist, or the current user does not have permission to connect to it.

This happened even after I opened firewall exceptions for sqlservr.exe or whatever port the named instance is running at! As that was what I did to the default instance and I never had problem connecting to the default instance. So what is the issue with the named instance?

In SQL server, I run sql profile and found no connection even being attempted from the sharepoint wizard, so it seems most likely a firewall issue.  As a testing, I turned off window firewall, and it works immediately!

But I can't leave the firewall off, so I have to find out what else I need to open in the firewall. After some googling, I understand how sql named instance works differently from default instance: the named instances need handshaking when a connection is requested (as client requests normally don;t include port number, but just instance name), and it is SQL Browse Service which helps client find port number at which the named instance is running at. The service name is sqlbrowser.exe and it is running at UDP port 1434.

With that, opening firewall for either .exe or UDP port 1434, the problem goes away, and I got a first look at SharePoint 2010 RTM after so many months with Beta. It is so exciting!

What happen behind screen for HTTP authentication, Kerberos or NTLM?

It is well known that during client-server authentication negotiation if clients send Kerberos token, kerberos will be adopted, otherwise authentication will fall back to NTLM. But from where clients get kerberos token, and how NTLM is chosen as a secondary choice? With helps from WireShark, I have found answers for those questions:

If server IIS is set up as "Negotiate, NTLM", on the first session, client first attempt to make anonymous HTTP request (without credential), server responds with 401 deny. After ACK,client makes a request to its KDC or Domain Controller for service token. One of the followings can happen then:

• if KDC respond back with a service token, 
• client will cache this token for subsequent sessions before its expiry time (10 hours by default)
• 
  client will make another HTTP request with service token.
• if the token is accepted by server, server send back 200, connection is established
• if the token is invalid, server deny again with 401 (if client is IE, IE will pop up a window for password, authentication reach an impasse)
• if KDC respond back with an KRB error( for example, SPN is not found), client will send NTLM negotiation to server,
•  server respond with NTLM challenge back to client
• client make HTTP request with NTLM token
• if KDC respond back with a kerberos account token (like krbTGT, not requested service token), that means this KDC can't find the requested service token, instead it designates a subdomain KDC
• with this subdomin TGT token, client can makes requests to sub domain KDC for the same  service token
• negotiation continue then

On subsequent session, since client already has token cache, it won't ask for KDC again until the token expires. This is why kerberos is considered not only secure, but also efficient.
 
At first, clients use a special TGT token to make requests to its KDC for service token. Clients get this special TGT token at login time. This TGT token also has a expiry time, and on Window 2008 Domain, it is automatically renews 30 minutes before expiry time. In a rare case (UPDATE: this case only happens to some xp sp2, sp3 has fixed this problem), with client kerberos cache corrupted, clients just send NTLM directly without even querying KDC for kerberos token. As a workaround, loging off/on or reboot client computer can solve this problem.

sharepoint 2010 WCF service error

if your sharepoint 2010 have multiple IIS headers, you will get the following error when programming client OM (client.svc) or invoking any other WCF service such as listdata.svc:

This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.

By design, WCF can't have multiple bindings for the same schema (HTTP).

Extending web application certainly is a workaround, but modifying web.config should be considered a better solution:

< system.servicemodel >
<servicehostingenvironment aspnetcompatibilityenabled="true">
<baseaddressprefixfilters>
<add prefix="http://sharepoint2010.yourDomain.com/_vti_bin">
</baseaddressprefixfilters>
</servicehostingenvironment>
</system.servicemodel>

much improved RSS Viewer web part in SharePoint 2010

RSS Viewer web part in MOSS 2007 is very buggy when it is used to host private/authenticated feeds. In addition to the one related with AAM setting, another big problem is, it can't auto refresh private feeds (only refresh after IISRESET!). Also if you try to set up constrained delegation in order to host private feeds from a remote server, it will break for those feeds from its own server! ( the workaround is to add delegation to itself, isn't it ridiculous?)

The only problem I have seen with RSS Viewer web part in SharePoint 2010 beta2 is, when setting up delegation (in order to view feeds from a remote server), choose the option "Trust this user for delegation to any service (kerberos only)" won't work (same behavior in MOSS's RSS Viewer). You have to choose the option "Trust this user for delegation to specific services only", and then add remote services for delegation target:

References: great article by Spencer Harbar: Sharepoint 2010 and Kerberos