Visit My Sponsors - SharePointAds







Easily Secure SharePoint Documents
Based on Metadata. By Titus Labs.



SharePoint Joel's SharePoint Land > Posts > Simplifying SharePoint Server Roles
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.

Comments

ESP for SharePoint is going to change things alot

Having worked with Fast in the past, where it is common to have two query servers and an index server just for search, is going to cause a bit of a stir for SharePoint deployments everywhere. It will be interesting to see what common/best practice becomes for Fast + SharePoint installations. AP - http://www.alexpizarro.com
at 2/14/2009 8:31 PM

Add Comment

 Social Comments

Post Comments to your Facebook Profile Post comments to twitter or on SharePointJoel.com
blog comments powered by Disqus
Share

Blog (RSS)

Follow on Networked Blogs Facebook

Recent Comments

Powered by Disqus
Subscribe by Email or RSS

Contact me

 20 Recent Posts

Effective SharePoint 2010 Upgrade Q&AUse SHIFT+ENTER to open the menu (new window).New
How Microsoft Is Doing Records ManagementUse SHIFT+ENTER to open the menu (new window).New
Free Webcast: Get to SharePoint 2010 – Strategies for Effective Upgrades and MigrationsUse SHIFT+ENTER to open the menu (new window).
SharePoint 2010 and SQL Hotfix DependenciesUse SHIFT+ENTER to open the menu (new window).
Aptillon SharePoint Consulting GeniusUse SHIFT+ENTER to open the menu (new window).
Really, A SharePoint Training Cruise?Use SHIFT+ENTER to open the menu (new window).
Updated Guidance on SharePoint 2010 Upgrade and the FAB 40 application templatesUse SHIFT+ENTER to open the menu (new window).
SharePoint 2010 Upgrade Decision TreeUse SHIFT+ENTER to open the menu (new window).
We’re Serious - Don’t Modify Your Database or Face ConsequencesUse SHIFT+ENTER to open the menu (new window).
Remove/Deactivate a missing feature for a cleaner upgradeUse SHIFT+ENTER to open the menu (new window).
Free Webcast: Best Practices for Upgrading and Migrating to SharePoint 2010Use SHIFT+ENTER to open the menu (new window).
I’m in Utah today at the MOSSPit (SLC UG)Use SHIFT+ENTER to open the menu (new window).
Wish you had free end user training incorporated into your SharePoint environment?Use SHIFT+ENTER to open the menu (new window).
SharePoint Virtual Expo Networking EventUse SHIFT+ENTER to open the menu (new window).
Planning SharePoint Deployments with RACIUse SHIFT+ENTER to open the menu (new window).
Reaching out to the SharePoint Portuguese CommunityUse SHIFT+ENTER to open the menu (new window).
Kudos to Owen Allen @owenallenUse SHIFT+ENTER to open the menu (new window).
Practical Windows PowerShell for SharePoint 2010Use SHIFT+ENTER to open the menu (new window).
Project Server 2010 and SharePoint 2010 CoexistenceUse SHIFT+ENTER to open the menu (new window).
What’s Next in SharePoint LandUse SHIFT+ENTER to open the menu (new window).