We have a SharePoint farm as follows:1 WFE1 Index + Excel Services + CA2 Clustered DB ServersWe are planning to NLB our WFE by bringing in a second WFE into our farm. We are also bringing in another application server to host Excel Services, CA, etc while keeping the index server on its own server.Can someone shed some light on the impact of moving these roles around from one server to another in terms of configurations, duration, and complexity.Thanks,

Generally speaking, it is very easy to add a web front end to an existing farm. You potentially have some other changes required though if you are adding in the NLB. Are you currently using a server name reference or a FQDN in DNS to access the system? I.e. http://servername versus http://portal.company.com if it is the former then you probably have some alternate access mapping and application changes that need to be made to support the new path. Purely from a role perspective it would be easier to reconfigure the Index server than it would be to relocate CA. If the hardware running the current index server is more robust than the web front end you were going to add then it probably wouldn't make sense to move the Index role. I would also enable the web role on the CA/Excel calculations box and then use that as the dedicated front end for the index crawls. That will greatly reduce the impact of crawls on the user experience.SharePoint MVP | Developer | Administrator | Speaker-- Twitter -- Blog - http://nextconnect.blogspot.com

Mike,Thanks for your reply.The reason I would like to separate the index server from the other services (Excel, CA, etc), is because I would like to have the index server act as a dedicated WFE for crawling as you suggested. However, MS indicates that no other roles should be on the index server if one wishes to dedicate the index server as a WFE.Are you suggesting to relocate the index server to the new application server instead of relocating Excel, CA, etc...?Thanks,

Mike,I am still greatly confused about using the index server as a dedicated WFE for crawling.You said:I would also enable the web role on the CA/Excel calculations box and then use that as the dedicated front end for the index crawls. That will greatly reduce the impact of crawls on the user experience.However MS says not to make the index a dedicated WFE for crawling if you have other roles on the index server. MS excerpt:Do not configure a dedicated front-end Web server for crawling under any of the following conditions: Another application (such as the Excel Calculation service) is running on the index server. Configuring a dedicated front-end Web server for crawling might prevent that application from communicating with other servers in the farm. If other applications are running on the index server, move those applications to another application server before configuring a dedicated front-end Web server for crawling. You want to use the index server as the dedicated front-end Web server for crawling and the index server is also configured as a query server. The NetBios name of your query server is also the host name of your SharePoint site.

Sorry for the confusion. I think it is a good idea to split out the roles, the question is what do you keep on the existing server and what do you move to the new server. It is easier to reconfiguring indexing on a new server than it is to move the Central Administration application. So if the two servers were equipped with similar hardware I would be more likely to move the Index role than I would to move the CA/Excel Calc Services. Generally speaking CA is not widely used in most organizations so there is very little load there. The Excel Calculation Services role may or may not be busy depending on how much it is used. In my current organization it isn't used at all, but it was activated to support the basic Excel Services feature set. Here is a good overview on Roles. I think Joel did a good job of explaining them: http://www.sharepointjoel.com/Lists/Posts/Post.aspx?ID=174 SharePoint MVP | Developer | Administrator | Speaker-- Twitter -- Blog - http://nextconnect.blogspot.com