The Infrastructure Update is a set of product improvements and prescriptive guidance for Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. Our favorite features (and the ones we’ve written the most about) include federated search, Kerberos authentication for the SSP infrastructure, and content database ID and change log retention.
An important feature of the Infrastructure Update is support for federated search, which is also included in Microsoft Search Server 2008. Federated search enables end users to issue queries that search multiple sources and display results in separate Web Parts on a single search results page. Displaying the results in separate Web Parts can help users distinguish where content is located, making it easy to identify which content is local. Understanding where content is located can also help users determine which results are most likely to be relevant. Using federated search enables you to provide more extensive query results for users without having to devote server resources to crawling and indexing content.
For more information about federated search, see Plan for global enterprise search. The operations content for federated search in Microsoft Office SharePoint Server is coming soon, but for now, feel free to refer to Working with federation, written for Microsoft Search Server.
Kerberos authentication for the SSP infrastructure
Another important feature of the Infrastructure Update is support for configuring the Office SharePoint Server 2007 Shared Services Provider (SSP) infrastructure for Kerberos authentication. The Infrastructure Update includes a new, custom-format Service Principal Name (SPN) for Kerberos authentication for the SSP infrastructure. For Kerberos authentication to work correctly, you must create SPNs in Active Directory. If the services to which these SPNs correspond are listening on non-default ports, the SPNs should include port numbers. This is to ensure that the SPNs are meaningful. It is also required to prevent the creation of duplicate SPNs. When you use Kerberos authentication, accurate authentication functionality is dependant in part on the behavior of the client that is attempting to authenticate using Kerberos. The browser is the client used when browsing to a Web page in an Office SharePoint Server 2007 Web application. When Office SharePoint Server 2007 performs tasks such as crawling the local Office SharePoint Server 2007 content sources or making calls to the SSP infrastructure, the .NET Framework is functioning as the client. When a client attempts to access a resource using Kerberos authentication, the client must construct an SPN to be used as part of the Kerberos authentication process. If the client does not construct an SPN that matches the SPN that is configured in Active Directory, Kerberos authentication will fail, usually with an “access denied” error. In a farm running Office SharePoint Server 2007, by default the .NET Framework does not construct SPNs that contain port numbers. This is why Search cannot crawl Web applications using Kerberos authentication if those Web applications are hosted on IIS virtual servers that are bound to non-default ports. This is also why Kerberos authentication cannot be correctly configured and made to work for the SSP infrastructure unless the Infrastructure Update is installed.
To configure the Office SharePoint Server 2007 SSP infrastructure for Kerberos authentication you have to:
For more information about Kerberos authentication for Office SharePoint Server 2007, see Configure Kerberos authentication (Office SharePoint Server).
For more information about authentication for SharePoint Services 3.0 and Office SharePoint Server 2007, see the Authentication Resource Center for SharePoint Products and Technologies.
Content database IDs and change logs
If you are running the Infrastructure Update, the identifier (ID) of each content database is retained when you restore or reattach the database by using built-in tools. Change logs are also retained by default in some cases. Default change log retention behavior when using built-in tools is as follows:
What does this mean to you? Fewer full crawls after restoring or reattaching. When a database ID and change log are retained, Search continues crawling based on the regular schedule defined by crawl rules—if an incremental crawl is scheduled, an incremental crawl is what you get.
If you’d like to manually manage how change logs and content IDs are retained for a specific content database, see the following articles:
Restore: Stsadm operation (Office SharePoint Server)
Addcontentdb: Stsadm operation (Office SharePoint Server)
There are many other improvements that are part of the Infrastructure Update, including:
For a full list of the topics updated to include information about the Infrastructure Update, see:
As you can see, we think the Infrastructure Update has great features in it, and strongly encourage you to install it. For information about downloading and installing, see the Updates Resource Center for SharePoint Products and Technologies.
Douglas Goodwin, WriterSharePoint Server UA team