Today when I tried to install the .NET Framework 3.5 security updates, I got the following errors in the event log:
Event Type: Warning
Event Source: Office Server Search
Event Category: Gatherer
Event ID: 2436
Time: 1:59:12 AM
The start address http://MOSSSERVER cannot be crawled.
Context: Application ‘SharedServices1′, Catalog ‘Portal_Content’
Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (0×80041205)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
When you start to analyse these errors you will find a Knowledge base article on the Microsoft homepageKB887993. Within this article they describe authentication issues to access web pages.
Use the second method to apply following registry key
When you applied above registry value you get a second error within your event log:
Event Type: Error
Event Source: Windows Search Service
Event Category: Gatherer
Event ID: 3083
Time: 10:08:23 AM
Computer: MOSS SERVER
The protocol handler Search.Mapi2Handler.1 cannot be loaded. Error description: Class not registered.
Event Type: ErrorEvent Source: Windows Search ServiceEvent Category: Gatherer Event ID: 3083Date: 8/2/2010Time: 10:08:23 AMUser: N/A Computer: MOSSSERVER Description: The protocol handler Search.Mapi2Handler.1 cannot be loaded. Error description: Class not registered.
What for a strange error. It seems that the search class is not registered yet. If you take a closer look within the “Component services” you find a discrepancy. If you search for osearch and check the permission entries you will see that you don’t have permission entries for your Index / Service account from your MOSS farm. You may miss the “WSS_Admin_WPG” and “WSS_WPG group” too.
If you take a look within your central administration now you will see that the search is running. But if you open your service manager you see that the service is stopped.
The simple resolution is to start the service from your search. You can do that on command line.
stsadm -o osearch -action start
That’s all. It seems if you start the service that all security information on the object will be set correctly.
It disappointing me that if you upgrade the .NET Framework to a higher version, what is good for your workflow functionality that you run in problems like that. Hopefully this would help someone and save some time.
For more information about the osearch commands check the technet article Osearch: Stsadm operation (Office SharePoint Server).
About the Author: