Simplifying SharePoint Server Roles

There is so much unnecessary confusion over server roles in SharePoint. Let me take the opportunity to simplify these roles, so you can see it is much much simpler than it is made out to be or even that original design.

SharePoint roles are really a description of what services are running on the server, and because of the past we've overcomplicated the way we think about servers roles, app servers, tiers, topologies, and farms.

The SharePoint Roles you've heard

• Web Front End - Every farm has one of these. It's where IIS is
• Query
• Index
• Calc
• App server - another name for all the goo that isn't the WFE
• Central Admin/SSP Admin
• Infopath - NOT A ROLE (This can NEVER be taken off the web front end)
• SQL - Not a SharePoint role and should not contain SharePoint code unless it's an all in one.
  

There are 2 server roles for 97% of the SharePoint World.

• WFE - WFE/Query/Calc/Central Admin/SSP Admin
• Index (the most common offloaded server role) (Note: Don't get carried away with what I'm saying. There is a Query/Index Gotcha.)
  

(Another 3% should know the all in one where WFE and all that jazz are combined with the Index.)

Why would I say you really only need to know about 2 roles?

First the Query role is the lightest role and doesn't really need to be offloaded. If it does you really are better off with an SSP farm which is focused on Search which would turn that Query server back into a WFE/Query box.

The Calc role is oversold. Excel services is cool, but no one is really able to stress it to the part where it needs separate servers. If you find a case, it's a .01% case, completely uncommon. MS IT had to reallocate and they

Infopath - not a server role, there was a license for forms server, that was never really used. Forget you ever heard about it. It's a dead end.

Central Admin/SSP Admin - I've heard people putting this on it's own server, totally unnecessary you don't have to put it on every server in the farm, but you don't have to buy a server for this purpose either.

Target - you can use existing roles for doing that.

What about MASSIVE farms?

In massive farms you have two choices. You put WFE/Query together and have a bunch of em, or you specialize search into it's own farm, maybe even two search farms, but you don't ever really need to offload query. Don't let an architect push you into having 2 WFE, 2 Query, 1 Index, 2 SQL. You are better off with 4 WFE/Query and 1 Index and 2 SQL or a Content farm of 2 WFE/Query and 2 SQL and a separate Search farm 2 WFE/Query 1 Index box and Shared SQL backend. Make sense?

Does this turn your world upside down or is it game changing?

Need an Exception?

A special customer that has a requirement for no data of any type in their public DMZ. They HAVE to have their data in the 2nd tier. Hence they put the WFE ONLY (remember that option no one uses) box in the pub DMZ and the 2 Query and Index boxes and SQL in their APP DMZ. They likely could have configured ISA publishing rules or used IAGin the pub DMZ and put the 3 SharePoint boxes in the App DMZ, but that's a design decision.

SharePoint Server Topology - Server Roles and Services on Server

All Services on Server (WFE/Query/Calc/Index) - Choose "Single Server or Web Server for small server farms" start the things it tells you to, and click on the things that look like links to configure them. In "Office SharePoint Server Search" you'll be checking both boxes since you're query and index are on this box. (Hint: Don't forget about SSP for further configration) You might not be using the document conversions, most likely you're not. These are optional.

WFE/Query/Calc - Choose "Web Server for medium server farms" and run the recommended services, and be sure to click on everything that is a link as in Office SharePoint Server Search. Be sure to check "Use this server for serving search queries." Doc Conversions is optional. (This role is very common in medium or high availability farms)

WFE - Windows SharePoint Services Web Application. Both of the document conversion services are "nice to have" if you use them in your SharePoint Standard or Enterprise publishing scenarios where you are converting your word to HTML for publishing. It's not common that these are used. During install you can choose WFE only, understand what you're doing, but this will limit the services you'll see in services on server.

Forms Rendering - I'm listing this here, since a lot of people think of this as a server role. This is automatically always on the WFE. You can't offload this.

Excel Calculation - Choose Excel Calculation, this service should be running. Configuration for this is in the SSP. It's a MOSS Enterprise configuration.

Query - In Services on Server choose "Search Indexing" then actually click, yes click on the text (under Service) "Office SharePoint Server Search." You'll see two options. Make sure "Use this server for indexing content" is unchecked and "Use this server for serving search queries" is checked.

By the way, if you ever decide to build a query server, I would nearly always recommend considering an SSP farm. Why? Cause if you're offloading query because you have that many search requests, then you'll need at least 2 Query servers and you'll have already offloaded your index, so that's 3 servers that could easily be load balanced and create a decent SSP farm.

Index - In Services on Server choose "Search Indexing" then actually click, yes click on the text (under Service) "Office SharePoint Server Search." You'll see two options. Make sure "Use this server for indexing content" is checked and "Use this server for serving search queries" is unchecked. You do need to add the Windows SharePoint Services search you don't need to go with the "every 5 minutes" by default, daily is sufficient. You will later create your rules for your content sources anyway. The service accounts will be configured when you configure indexing.

This is the first server I offload for performance. I do recommend making the index role also a WFE, so I wouldn't usually recommend this just be an index server unless it's in the SSP farm (a farm by itself with no content).

Index/WFE and WFE out of load balancing (Target) - here's where you could pick custom then start the Windows SharePoint Services Web Application and the Office SharePoint Server Search and be sure to check only "Use this server for indexing content." I did a whole post on this in a post called "Use a dedicated web front end for Indexing." A target server might be a WFE that's out of load balancing that only the index servers in your environment know about (host file entries on the index servers). The other configurational you'll see is index servers that have WFE components that are configured to index themselves and hence have the WFE services (Windows SharePoint Services Web Application) and also not in load balancing. There is an option to configure the "use a dedicated WFE on the bottom of the Index server configuration page (Office SharePoint Server Search Configuration page), don't use this if you have multiple IPs or multiple NICs. It is very possible it will choose the wrong IP and better that you configure this in hosts where you manage what is in.

WFE/index/Query and WFE/Query - If you ever have index and query on the same server and plan on doing another server with Query.... or are thinking about doing something like this please refer to my post about the Index/Query Gotcha. The Index server will NOT propegate if the Query components are enabled on the farm. In a sense this means if both boxes are checked (Query (search requests) and Index (crawling)) in "Office SharePoint Server Search" it will NOT propegate the index to any other query server. It assumes there is not another query box no matter how many you have.

Want to force changes after a role change of a server where you need to push down the web apps to a new box?

stsadm.exe -o execadmsvcjobs

This stsadm command will force timer jobs to execute.