Beyond the Bits

I have recently switched my laptop over to Windows Server 2008 from Windows 7 to take advantage of hyper-v.  I wasn't happy with Virtual PC 2007 for Windows 7 and VMWare is too expensive when I have access to Windows Server 2008.  Overall the experience is very good as Windows Server 2008 runs very quickly on my Lenovo t61 (I am not running the Desktop Experience feature as this sucks too many system resources).  Since I am running this machine as my core workstation I am running Office 2007. I ran into a scenario where I wanted to enable Outlook Instant Search.  Here is a link to a good blog post that walks you through the process of enabling Outlook Instant Search on Windows Server 2008.

http://exchangepedia.com/blog/2009/04/using-outlooks-instant-search-feature.html

I have ran into this issue several times in the past where a SharePoint server’s event log is filling up with event id’s 6398, 6482, and 7076.  These errors typically popup in your event viewer for administrative timer jobs.  According to Microsoft there is an issue with multithreaded applications accessing IIS at the same time.  Microsoft does have a hot fix to address the issue.  The knowledgebase article is located here http://support.microsoft.com/default.aspx?scid=kb;EN-US;946517

This pertains to Windows Vista and Windows 7 only.  If you are running Windows XP then stop reading.

If you are running Vista or Windows 7 and you are attempting use the “Upload Multiple Documents” feature of MOSS 2007 or WSS 3.0 to upload zip files you have probably noticed that zip files do not show in the upload explorer window.  The “Upload Multiple Documents” feature is an ActiveX control that installs with Office 2003/2007 so if you aren’t running either Office versions then the option won’t show up in SharePoint.  The problem with zip files and the ActiveX control has to do with how Vista deals with zip and CAB files. By default Vista is configured to show zip and CAB files as folders allowing the user to drill into their contents within Windows Explorer.  For this reason they do not show up in the ActiveX control that handles multiple file uploads for SharePoint.  To fix this problem you need to delete the following registry keys.  WARNING! Backup your registry before making any changes!

HKEY_CLASSES_ROOT\CLSID\{E88DCCE0-B7B3-11D1-A9F0-00AA0060FA31}
HKEY_CLASSES_ROOT\CLSID\{0CD7A5C0-9F37-11CE-AE65-08002B2E1262}

Now deleting the above registry keys is a bit more involved than running RegEdit, finding the keys, and deleting them.  Both keys above are protected keys and are own by the SYSTEM account.  In order to delete the keys you need to change ownership of the keys, delete sub keys first, and then delete the root key.  To do this you need to download the PSExec utility from Microsoft that is part of the Sysinternals tools.  The download is located here http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx .  Once you have downloaded the tools and extracted the PSExec utility from the zip file, you need to then start a windows command prompt as the local machine administrator (if you are not logged in as the administrator then run the following from the RUN dialog:  runas :user/localhost\administrator CMD ).  Once the command window launches navigate to the directory where you unpacked the contents of the zip file that you downloaded earlier and execute the following command: psexec -i -d -s c:\windows\regedit.exe.  At this point you are now running RegEdit as the SYSTEM account and will be able to change ownership of registry keys.  It is important to note that you have to delete child keys before deleting the root key. 

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);