Logo 
Search:

MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

Search/index sharing errors?

  Asked By: Benjamin    Date: Mar 05    Category: MOSS    Views: 1839

Apologize in advance for the length here. I need help
researching/resolving the following. For background, we're running a
medium MOSS farm with load-balanced WFE servers.

Events:

1. Last week we experienced repeated authentication prompts
(symptom) that we resolved by closing some open, stale TS sessions on
the WFE servers and rebooting them. This may or may not be related to
the following.


2. Almost immediately after #1 events, we noticed that search
crawls had hung up and the Propagation status gave us the following
message: Query server not responding (WFE server #2). A check of the
WFE server log revealed a Search Service warning "Retry of query machine
'[WFE server #2]' has failed with error: The semaphore timeout period
has expired. 0x80070079. It will be retried again in 900 seconds.
Component: 3f9df969-2179-4968-b0e9-32963f2591dd" Research showed this is
a somewhat generic error that in essence is a sharing violation. One
possible problem was a file access issue.


3. My SysEngineer did some digging and thinks the
3f9df969-2179-4968-b0e9-32963f2591dd refers to the path where the
indexes are stored. (??) He ran filemon and there were several files in
the path "D:\program files\Microsoft office servers\12.0\data\office
server\applications\3f9df969-2179-4968-b0e9-32963f2591dd\projects\anchor
project\indexer\cifiles\" that had sharing violations when the
mssearch.exe process attempted to access them:

Excerpt from file mon:

5:47:16 PM mssearch.exe:2284 OPEN D:\program files\microsoft office
servers\12.0\data\office
server\applications\3f9df969-2179-4968-b0e9-32963f2591dd\projects\anchor
project\indexer\cifiles\00010003.ci SHARING VIOLATION Options: Open
Access: 00010080
5:47:16 PM mssearch.exe:2284 OPEN D:\program files\microsoft office
servers\12.0\data\office
server\applications\3f9df969-2179-4968-b0e9-32963f2591dd\projects\portal
_content\indexer\cifiles\00010040.ci SHARING VIOLATION Options: Open
Access: 00010080
5:47:22 PM mssearch.exe:2284 OPEN D:\program files\microsoft office
servers\12.0\data\office
server\applications\3f9df969-2179-4968-b0e9-32963f2591dd\projects\anchor
project\indexer\cifiles\00010003.ci SHARING VIOLATION Options: Open
Access: 00010080
5:47:22 PM mssearch.exe:2284 OPEN D:\program files\microsoft office
servers\12.0\data\office
server\applications\3f9df969-2179-4968-b0e9-32963f2591dd\projects\portal
_content\indexer\cifiles\00010040.ci SHARING VIOLATION Options: Open
Access: 00010080


7:35:29 PM mssearch.exe:2284 IRP_MJ_CREATE D:\program files\microsoft
office servers\12.0\data\office
server\applications\3f9df969-2179-4968-b0e9-32963f2591dd\projects\anchor
project\indexer\cifiles\00010003.ci SHARING VIOLATION Options: Open
Access: 00010080
7:35:30 PM mssearch.exe:2284 IRP_MJ_CREATE D:\program files\microsoft
office servers\12.0\data\office
server\applications\3f9df969-2179-4968-b0e9-32963f2591dd\projects\portal
_content\indexer\cifiles\00010040.ci SHARING VIOLATION Options: Open
Access: 00010080
7:35:30 PM mssearch.exe:2284 IRP_MJ_CREATE D:\program files\microsoft
office servers\12.0\data\office
server\applications\3f9df969-2179-4968-b0e9-32963f2591dd\projects\anchor
project\indexer\cifiles\00010003.ci SHARING VIOLATION Options: Open
Access: 00010080
7:35:31 PM mssearch.exe:2284 IRP_MJ_CREATE D:\program files\microsoft
office servers\12.0\data\office
server\applications\3f9df969-2179-4968-b0e9-32963f2591dd\projects\portal
_content\indexer\cifiles\00010040.ci SHARING VIOLATION Options: Open
Access: 00010080



4. The SE tried a couple of things:
--changed the file exceptions for the Antivirus thinking it may
be trying to look at the file at the same time (no impact)
--attempted to restart the Office SharePoint Server Search
service on the affected server but that was sluggish and would not stop
correctly
--rebooted the affected server. That appeared to resolve the
issue.


5. SE's analysis: The process that updates the index files on WFE
Server #2 was hung. He is not sure if that process lives on that server
or on the application server, but if the process locks the files cannot
be accessed by the search service on WFE Server #2. This would explain
the application errors and the Filemon sharing violations.


6. After the SE's reboot of the server, incremental search crawls
ran fine yesterday (with exception of the frequent URL error I posted
about yesterday, and which predated these events). However, last night a
scheduled full user profile import from AD resulted in the following
error:
spsimport://3f9df969-2179-4968-b0e9-32963f2591dd
The parameter is incorrect.

There is some indication that updates to AD accounts did not
accurately get updated in user profiles.

So the lingering questions I need help with are:

What, generally, is happening?

Can anyone verify the location where SP stores the index files on the
WFE servers?

Would there be benefits to recreating the indexes on one or both WFE
servers? What would impacts be? Can we rebuild the index on only the
affected server (#2) or would it be better to rebuild both?

Any advice is greatly appreciated. Our SE team is great but SharePoint
is new to them.

Share: 

 

1 Answer Found

 
Answer #1    Answered By: Emily Clark     Answered On: Mar 05

2. may be a permissions issue with the searchpropagation share on query  server.
check share/permissions. if it isn't a large index, you may also consider
turning off the query role on that WFE, waiting a few minutes, and adding it
back. this often 'kick starts' the process again.

make sure the index locations are excluded from anti-virus, or you may very well
have problems.

 
Didn't find what you were looking for? Find more on Search/index sharing errors? Or get search suggestion and latest updates.




Tagged: