SharePoint: Errors 6482, 6398

The Event Log on our MOSS 2007 server was filled with alternating error codes 6482 and 6398.

6482:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (dc8cedfd-9340-42bb-adee-57e75040cdf6).

Reason: Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005.
...

6398:
The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID 66aead00-c73c-4e06-a1ce-ac86070bb9da) threw an exception. More information is included below.

Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005.
...

---

After a little bit of Google researching, I found that the service account used by the "Windows SharePoint Services Search" service did not have appropriate rights to launch, activate, and access the DCOM component oSearch.

Give the service account Local Launch and Local Activation permissions in the "Launch and Activation permissions" portion of the oSearch DCOM component properties dialog. Also, give the service account Local Access permissions in the "Access Permissions" portion of the properties. Save the changes and restart the "Windows SharePoint Services Search" service and you should be good to go.

Thanks to the folks at Tahoe Solutions for posting this on their blog: http://tahoesolutions.blogspot.com/2008/01/event-6482-and-6398-errors-in-event.html.

Accessing subsites' lists via the MOSS 2007 Lists.asmx web service

I spent a little bit of time trying to figure this one out. I'm playing with the exposed web services that MOSS 2007 provides, trying to figure out how to manipulate lists via this API. My web reference is set to http://company.com/Clients/_vti_bin/Lists.asmx, but I am getting the same response as if the web reference were set to the site root (i.e. http://company.com/_vti_bin/Lists.asmx).

Thanks to user in.the.dark on MSDN forums (http://forums.msdn.microsoft.com/en-US/sharepointdevelopment/thread/80be9abc-f9e0-49b6-8ebc-8f90ddbf27a2/), a workaround is to set the URL programmatically, like so:

using (com.company.Lists lists = new com.company.Lists())
{
    lists.Url = "http://company.com/Clients/_vti_bin/Lists.asmx";
    XmlNode listColl = lists.GetListCollection();
}

listColl now contains the subsite's lists, rather than the root site's lists.

Calculating Work Days

I ran across the following T-SQL function to calculate the number of workdays between a given start date and end date. (This does not exclude non-weekend non-workdays such as holidays.)

Thanks to Jeff Moden for this function, which I found at http://www.sqlservercentral.com/articles/Advanced+Querying/calculatingworkdays/1660/:

SELECT
  (DATEDIFF(dd, @StartDate, @EndDate) + 1)
 -(DATEDIFF(wk, @StartDate, @EndDate) * 2)
 -(CASE WHEN DATENAME(dw, @StartDate) = 'Sunday' THEN 1 ELSE 0 END)
 -(CASE WHEN DATENAME(dw, @EndDate) = 'Saturday' THEN 1 ELSE 0 END)

ASP.NET Menu control & "downlevel" browsers

I ran into this fix when trying to get an ASP.NET 2.0 Menu control to render correctly on Safari. It turns out that ASP.NET thinks Safari is a downlevel browser (meaning incapable of rendering XHTML), so it sends a funky (and generally non-functioning) rendering of the Menu control down to the browser.

This isn't guaranteed to work in all cases, but in my case, adding the following Page directive did the trick:

<%@ Page ClientTarget="uplevel"... %>

Result set was not generated by a SELECT statement

This obscure error occurred when using PHP ODBC to retrieve values from a stored procedure. It turns out this occurs when the stored procedure SELECTs data from one or more TEXT columns. Convert these columns to VARCHAR(8000) and you're good to go.

AGONY: Vista Business x64 and SQL Server Management Studio

I have been fighting this one for days: my computer is currently joined to our corporate domain, but I am logged in as a local user. I've used "Manage network passwords" to add all of the relevant credentials for domain access. However, I still get the following error when logging in via Windows Authentication in SSMS:

Login failed for user ''. The user is not associated with a trusted SQL Server connection.

The error logs show that the SSPI handshake is failing - meaning that Windows is not passing along my valid domain credentials to SQL Server.

Finally, I found a workaround that deals with what I'm experiencing by making use of the runas command. It's hacky, and this is definitely due to Vista's "wonderful feature", but it gets the job done. Thanks to Jason Follas for the following tip:

http://www.jasonfollas.com/wiki/Default.aspx?Page=SQL%20Management%20Studio%20on%20Vista&AspxAutoDetectCookieSupport=1

For the record, we should not have to do this.

How to install Windows SharePoint Services 3.0 Tools to XP or Vista

Another blog ripoff, this time from Janne Mattila, on how to trick XP or Vista machines into thinking that WSS 3.0 is installed so that you can install WSS 3.0 Tools for Visual Studio 2005:

http://blogs.msdn.com/jannemattila/archive/2007/08/16/how-to-install-windows-sharepoint-services-3-0-tools-to-xp-or-vista.aspx

Details: it's a registry hack...

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0]
"Sharepoint"="Installed"