I have a medium Moss farm 3 frontend servers Index server and DB server. I am at the part of adding the index server to the farm all is good but I am confused on the 2 check boxes "Use this server to index content" and "User the server for serving search queries" What is the difference? Do I check both if this is a dedicated Index Server?

If you want to store you indexed file information on the new server then you need to choose only "Use this server to index content" on the new server when configuring "office sharepoint server search" Refer this article: Plan to crawl content (Office SharePoint Server) http://technet.microsoft.com/en-us/library/cc262926.aspxVisit: http://yagyashree.wordpress.com MCP & MCTS [WSS 3.0/MOSS]

I have a medium Moss farm 3 frontend servers Index server and DB server. I am at the part of adding the index server to the farm all is good but I am confused on the 2 check boxes "Use this server to index content" and "User the server for serving search queries" What is the difference? Do I check both if this is a dedicated Index Server? This is a very important distinction, and the decisions depend on your preferred architecture and performance. The index portion is definitely a requirement for making that your dedicated index server. This gives it the role of building and storing the index. The query role does not have to be on your index server. You can instead use your web front ends (1 or more) as query servers. What this does is it tells the index server to propagate its index to the WFEs that are set as query servers so that they have a local copy of the index. Then, when someone does a search (this is done on the WFE), then that WFE will search itself locally instead of going across the network to query the index server. This increases speed at the time of query, but it of course introduces additional overhead in terms of having multiple full copies of the index on the network and the network demand of propagating those index copies all the time. If you select the query role on your index server, then the index will not get propagated and all searches will query the index server across the network. Oh, btw, to set WFEs as query servers, you have to activate the Office Search Service and only select the query checkbox, then tell it where to store the index.One last piece of info to be aware is that there is also a crawling role that is defined in the SSP settings. The crawl server (or servers) is the WFE that the indexer uses for crawling content. A new concept being used (or at least new to me) is that you can actually make your index server a WFE that isn't part of your normal web browsing rotation (not load balanced) then set itself as the dedicated crawler. What this does is allows the indexer to crawl itself, which does two things: avoid the network traffic of building the index across the network and eliminates the crawling load on the WFEs. Since your index server becomes an out-of-rotation WFE for regular browsing, you can actually use it to host your Central Admin and SSP web apps, which again reduces load/overhead on the content WFEs. Consider that option as it is what I am using on a current project thanks to some input from a colleague.SharePoint Architect - Planet Technologies - 4-Year Microsoft Federal Partner of the Year (2005-2008)

I was thrown off by the idea of having the Query service server need a local copy of the Index files. My goal was to move Indexing to a dedicated server since I was concerned the index would become too large. If leaving the Query service on my front end box still requires the index to be copied back to it, then I haven't achived my goal. So it looks like I have to move the Index AND Query service to a dedicated machine in order to deal with a very large index. It is NOT clear in the documentation that the index file still needs to be copied to a query server.

That's how it works. A query server can't be a query server unless it has the index. Whenever you add the query role to a server, it asks for a file location, and the index gets propagated to that location on that server. It's good to have the WFE as a query server so that the searches are fast (queries itself locally) and for some redundancy, since index servers cannot be made redundant. If the index server goes down, WFEs still have a copy of the index for allowing searches with current info - they just don't get refreshed until the index server comes back online.If you put query on the index server, then queries have to go from the WFE to the index server and back, which can cause a performance hit, but it's still doable. You have to decide what is best for your situation. Just remember that acting as a query server will compete with the very intense indexing process if they're on the same box.SharePoint Architect || My Blog

Thanks...I opted to move both Query and Indexing to the secondary server. The Index file size is not very predictable and I don't know how large it will ultimatley be in the end. I will see if there is any noticable perfromance hits for searching, I am hoping not too much. There are too many moving parts and all of this has me holding my breath since I really don't have a way to test this outside of my production system.

As a follow-up, doing this is a major pain in the you know what. I ran itno so many issues that I can't even begin to list here....however I did it. And am done after hours of head scratching and google searches. Good luck to everyone else! Don't you wish SharePoint had an Easy button?

Clayton, We have a MOSS 2007 environment with 1 App server and 2 WFEs. The App server currently has both the indexer and the query role, but we will be adding a dedicated index server. We could keep the query role on the App server, which would ensure that the search capability is not impacted if anything happens to the crawl (hangs, etc.), but I'm thinking that perhaps it would be better to make the WFEs query machines instead. That way, we could still keep the search and the crawl separate, and the index would get propagated to the WFEs so there would be 0 hops for search queries to get to the closest copy of the index (as you describe). Would you say that it's definitely better to put the query role on the WFEs as opposed to the indexer or app servers? I've read postings that say that it's better to leave the query role on the app server, but I don't agree so I'm looking for others' opinions on the matter. BTW, our new dedicated indexer is also going to be an out-of-rotation WFE to serve as a dedicated crawl target - trying to get the best of both worlds (i.e., 0 hops for indexing, 0 hops for queries). Since the new server is going to be both the indexer and a WFE, I was also wondering if you might have any recommendations with regard to storage allocation. I'm thinking of putting the OS and product on the C: drive and the index itself on another drive, but we're also looking at perhaps putting the ULS and IIS logs on yet another drive to keep from running out of space. What are your thoughts on this? Thanks, Patty

That really helped to avoid confusion ...thanks :-)