Beyond the Bits

I ran into this issue several times in the past in setting up SharePoint environments (for both internal development use and customers) so I figured it was time to write a blog post about it.  If you are running SharePoint Server 2007 or WSS 3.0 on  Windows Server 2003 SP1 or later you will run into authentication issues if you are trying to access a SharePoint site using host headers from the server itself (i.e. host file has portal.mydomain.com pointed to 127.0.0.1).  This issue manifests itself as the result of a loop back security check that Microsoft built in to Windows Server 2003 SP1 and later.  The purpose of the loopback check is to eliminate denial of service attacks however it causes issues with access SharePoint sites locally from the server.  In a typical production environment this is typically not a problem since you rarely access SharePoint sites (besides central admin) from  a front end web server itself.  However I do have physical and virtual development environments where all activities take place from the server, so this can cause some heartburn unless you have worked through the issue before.  You can read the detailed KB article at http://support.microsoft.com/kb/926642 & http://support.microsoft.com/kb/896861.  Here is a rundown of how to fix the problem.   I typically disable the loopback check however this is not recommended for production server environments.

Method 1: Disable the authentication loopback check
Re-enable the behavior that exists in Windows Server 2003 by setting the DisableLoopbackCheck registry entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry subkey to 1. To set the DisableLoopbackCheck registry entry to 1, follow these steps on the client computer:

1. Click Start, click Run, type regedit, and then click OK. 
2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Right-click Lsa, point to New, and then click DWORD Value. 
4. Type DisableLoopbackCheck, and then press ENTER. 
5. Right-click DisableLoopbackCheck, and then click Modify.
6. In the Value data box, type 1, and then click OK. 
7. Exit Registry Editor.
8. Restart the computer.
Note You must restart the server for this change to take effect. By default, loopback check functionality is turned on in Windows Server 2003 SP1, and the DisableLoopbackCheck registry entry is set to 0 (zero). The security is reduced when you disable the authentication loopback check, and you open the Windows Server 2003 server for man-in-the-middle (MITM) attacks on NTLM.

Method 2: Create the Local Security Authority host names that can be referenced in an NTLM authentication request
To do this, follow these steps for all the nodes on the client computer:

1. Click Start, click Run, type regedit, and then click OK. 
2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
3. Right-click MSV1_0, point to New, and then click Multi-String Value. 
4. In the Name column, type BackConnectionHostNames, and then press ENTER. 
5. Right-click BackConnectionHostNames, and then click Modify. 
6. In the Value data box, type the CNAME or the DNS alias, that is used for the local shares on the computer, and then click OK.

Note Type each host name on a separate line.

Note If the BackConnectionHostNames registry entry exists as a REG_DWORD type, you have to delete the BackConnectionHostNames registry entry.
7. Exit Registry Editor, and then restart the computer. 

If you are using the SharePoint object model to query a SharePoint list you will find out that SPQuery doesn't retrun items in the subfolders. In  order to execute a search query against a list and return results regardless of subfolder location you need to add "Scope='RecursiveAll'" attribute to the SPQuery object's ViewAttributes property.  Since the ViewAttributes property is a string you need to make sure that this attribute doesn't already exist.  If it exists you must remove it and then add it back to the ViewAttributes property.   

itemCollection = list.GetItems(query);

It is generally accepted that searching for content in MOSS or WSS 3.0 requires the content to first be crawled by the SharePoint Search Service.  However in traditional Enterprise Content Management (ECM) scenarios this typically doesn't make a lot of sense.  If evaluate how most organizations manage content for the purposes of managing that content, you will quickly see why crawling content doesn't make a whole lot of sense.  A typical ECM related business process involves the capture (data stream or scanning of content), categorization, processing, and archival of content.  In many cases significant time, money, and effort is expended in these business processes.  So if you spent significant resources to capture and categorize content then why would you rely on a search technology that is better suited for unstructured, full text queries to retrieve your content?  In most (and I say "most" because there are exceptions to this rule) ECM scenarios users are not conducting broadly scoped searches for content.  User's search critieria is very targeted and specific.  For example an accounting user might want to search for an invoice for a specific vendor based on vendor id and/or invoice number.  A slightly broader search might be executed where the same accounting user is looking for all invoices from a specific vendor for the 2008 calendar year.  In either case the search is targeting.  Attenmpting to crawl this content doesn't result in a favorable outcomes.  For starters crawling content in SharePoint doesn't occur immediately after content is added and incremental crawls can take long periods of time to execute depending on how much content was added since the last incremental crawl was executed.  In many EMC scenarios users are required to immediately validate the content once it's archived to SharePoint but requiring the content to first be crawled doesn't support this process due to the latency by which items are made available for searching. 

 The performance challenges with crawling large volumes of content in SharePoint are well documented.  If you are not familiar with SharePoint limitations I would recommend reviewing Microsoft's TechNet article title Plan for Software Boundaries (Office SharePoint Server) located here http://technet.microsoft.com/en-us/library/cc262787.aspx.  If you have ECM scenarios where users are conducting targeted searches in SharePoint, I would suggest evaluating existing search utilities that leverage CAML (Collaborative Application Markup Language) or developing your own.  In large volumen scenarios it makes sense to exclude the content from the SharePoint crawl all together.  I have personally experienced extremely unfavorable crawl performance as a result of larger content volumes in SharePoint even when the underlying SharePoint server infrastructure was optimal.

Microsoft Live Writer can be configured to use with SubText.  Here are the steps. 

1). Navigate to the Weblog > Add Weblog Account menu

2). Select Another weblog service 

3). Enter the URL of your weblog (http://myblog.com/blogname)

4). Enter a username and password.

5). Under the type of weblog select Metaweblog API and enter the Remote Posting Url in the following format: 
http://<someblogsite.com>/<username>/services/MetaBlogAPI.aspx

6). Click Next.  Enter a name for this blog setting and click Finish.