Skip to main content

From The Field

Go Search
From The Field
  

From The Field > Posts > Troubleshooting Index Server Moves
Troubleshooting Index Server Moves
I recently helped a customer through some problems with an index server move.  They have 3 MOSS servers (in this example; server 1, 2 and 3).  Server 1 and 2 are front ends and and server 3 is an application server.  Server 1 had the index and query roles.  The wanted to move the index role to server 3 and have a second query role on server 2.
 
They had been able to move the index role and run a crawl, but that new index would not propagate to either of the query servers.  I wrote them an action plan that got them to where they wanted to be.  It might help if you are in a similar situation.
 
Deactivate Alerts
1. Go to SSP admin > Search settings
2. Search based alerts
3. Deactivate
4. Check the Search alerts status is inactive on the status page.
 
Stop the search services on server 1
1. From Central Administration > Services on Server
2. Change the context to server 1
3. Stop the Office SharePoint Server Search
4. Repeat this on server 2 and server 3 - just in case they are running
 
Delete old Indexes from all servers
1. Just to be tidy: on all servers - go to C:\Program Files\Microsoft Office Servers\12.0\Data\Office Server\Applications
2. Remove index folders (folders named with a GUID) – leave the Applications folder where it is.
 
Add the Index Role to server server 3
1. From Central Administration > Operations > Services on Server
2. Change the context to server 3
3. From Office SharePoint Server Search click Start
4. Check the box for indexing on this server
5. Use the default index location (will probably be greyed out anyway)
5. Fill in the service account details and start the service.
6. After a few minutes check the index location exists on the file system
 
Change the index location
1. Go to server 3 console
2. stsadm -o editssp -title YourSharedServicesName -indexserver server 3servername -indexlocation filePathtoIndex
3. After a moment check the new location exists
 
Change the SSP
1. Go to Central Admin > Application Management > Create or configure this farm's shared services
2. Edit properties of SSP (SharedServices1 for example)
3. Go to the index server section and choose server 3 as the new indexer.
 
Add query role to server 1
1. From Central Administration > Operations > Services on Server
2. Change the context to server 1
3. From Office SharePoint Server Search click Start
4. Start the search service – check the box for querying on this server
5. Fill in the service account details
 
List search info
1. stsadm -o osearch -action list
2. You should see:
a.  server 3 and server 1 and their roles - check that they are ok at this point
b. Some farm contact info and service account - check these are correct
 
Just to be sure – set the propagation location
1. On server 1
2. stsadm -o osearch -propagationlocation filePathtoPropagationShare (same as index but on the query server)
3. After a little while you should see the folder shared on the query server file system.
 
Run a full crawl
1. From SSP admin > Search settings
2. Select content source and run full crawl
3. Monitor until Idle
 
Check Propagation to server 1
1. Once the crawl has finished
2. From SSP admin > Search settings
3. Wait for a while and monitor propagation status -
a. Idle - Is good - carry on to Add query role to server 2
b. Propagation Not required - not so good - check the query service is running server 1.  Check the SSP is using server 3 as the index server.
c. Propagating to New Query server - might need attention if it stays like that for too long - give it 5 minutes.  Check the application event log for 6398 and 6482.
 
If propagation doesn't work we are into troubleshooting mode.  Things to check:
a. The index location exists on the server 1
b. Its shared as searchindexpropagation
c. The share permissions include the WSS_WPG_ADMIN group and it has full control
d. The WSS_WPG_ADMIN group has full control on the Security tab as well
e. Events on server 3 – like can’t propagate, no access to share, shared doesn’t exist etc. Also 6398, 6482
If Propagation seems to work OK – got to a web app and run a search query
 
Add query role to server 2
1. If we see propagation working ok from server 3 to server 1 we start search on server 2
2. From Central Administration > Services on Server
3. Change the context to server 2
4. Start the search service – check the box for querying on this server
5. Fill in the service account details
 
Just to be sure – set the propagation location
1. On server 2
2. stsadm -o osearch -propagationlocation filePathtoPropagationShare (same as index but on the query server)
3. After a little while you should see the folder shared on the query server file system.
 
Check Propagation to server 2
1. From SSP admin
2. Search settings
3. Monitor propagation status -
a. Idle - Is good
b. Propagation Not required - not so good
c. Propagating to New Query server - might need attention if it stays like that for too long - give it 5 minutes.
 
Activate Alerts
When everything is working as expected
1. Go to SSP admin > Search settings
2. Search based alerts
3. Activate
4. Check the Search alerts status is active on the status page.

Comments

How do you troubleshoot the 6398 and 6482 errors?

I've run into thousands of the 6482 errors in my SSP server event log and I have no idea how to fix it. Seems to be a permissions error?
at 5/12/2009 11:43 AM

How do you troubleshoot the 6398 and 6482 errors?

That sounds like the old IIS issue.  There is a fix for this: http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?ID=47
at 5/12/2009 12:11 PM

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title (required) *


Body (required) *

Name (required) *


Are you a bot? *


Anti-Spam Filter 1

What's 10+4? *


Anti-Spam Filter 2
Attachments