Should four different divisions (with overlapping associates and security permissions) have diff. web applications

I have multi part question in regards to setting up the topology for my company and am curious about best practices.
We are creating a Sharepoint farm that will be used by different divisions in the company and we require isolation between the divisions.

We have let's call them Division1, Division2 and Division3 all to setup each needing to be separated from each other. Here are some of the questions and concerns i have:

What i was wondering about is do i setup a different web application for each? or do i setup more generic web application and separate them with site collections? for example,, or do i setup, to reach the isolation we require?
If i do use the more generic web applications approach what is the best practice for separating search and metadata? Is setting up partitioning for each service the better way to go in this scenario?
Do i setup a different application pool for each web application? Do i setup a different service application per service? or used a shared app / service pool? What are the advantages of each?

** I should note my sharepoint farm is on the same domain as all the different divisions.

I have done some research and am getting conflicting information on these points which is why i thought i would ask these questions here.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Matthew KellyCommented:
I would say that SharePoint farm questions should be answered based on the number of anticipated users, not by divisions; and likely you are not talking about 10s of thousands of users:

My recommendation (and how my company does it) is to have one SharePoint farm, with multiple site collections, e.g.,, etc.

Each site can have entirely different permissions. The search and meta is already separated by permissions, but site collection settings allow searching of just the site collection instead of "All Sites".
Each web application has its own content database and service applications (and of course IIS site).  This has advantages if you are planning a large deployment (content DB above 200GB), or you want to implement different rules per app at SQL level, for example if you want to keep DB's on different sections of a SAN.  You can also easily configure a top level URL per webapp (and add alternative access mappings), so your URLs could be configured to be:  http://division1, http://division2 etc.  The IIS site means you can configure different security settings per app (NTLM, forms sercurity etc.) and you get a separate IIS log.

In my farm I planned for very large content in a document centre, and also implemented a very large records centre,  and in that situation I created a webapp for each.  I repeat this config for two divisions.   Each division is entirely separate, and has NO CROSS OVER (they are, for the purpose of this, entirely separate legally), so separate web apps means they can be indivdually maintained, be ready for huge content, and have separate service applications and search indexes etc and comply to the complex information governance rules of my organisation.

The disadvatage of this approach is that it's more overhead, more to maintain, and its more difficult to configure search if for some reason you wanted to federate it across the whole farm etc.  

If you are not planning on a very large deployment, then the scenario you describe couls also be served using a single webapp and multiple site collections (one for each division).  Your URLs would then be something like: http://farm/division1, http://farm/division2 etc.  As has already been noted by the expert above, you can set individual permissions on each site and control search scopes using this topology, but you will not get the extra layer of security/logging from the IIS layer of a web application.

I have used a separate app pool for each of my web apps, however I have read that this is not considered "best practice" (see:
Adam409Author Commented:
Thank you both for your comments they are very much appreciated.

I'm still a little torn as too which way to go for my SharePoint Farm.  The scenario is that each division has multiple departments and I would need Search and Metadata to be shared within each department but not between divisions.  Couple things I’m still unsure on are

1. Should I have separate Application pools for each Web App?
2. Should I have separate domain accounts for each Web App?
3. Should I have separate service pools for each Service?
4. Should I have separate service accounts for each Service?

Here are the 2 scenarios that I see possibly working and I hope I can get an opinion as too best case:

1. Setup each division as its own separate web app. -> http://division1, http://division2
-- Setup each department as its own site collections -> http://division1/hr, http://division1/finance
-- Have 1 common mysites Web app for the entire parent company?

2. or Setup each division as a separate site collection all within 1 Web Application -> http://intranet/
-- Setup each division as its own site collection -> http://intranet/division1, http://intranet/division2
--- In this scenario it might be beneficial to create seperate content db's per site collection possibly?
-- Setup each department at its own site -> http://intranet/division1/hr, http://intranet/division1/finance
-- Have 1 common mysites Web app for entire company?

Are there any real advantages / disadvantages in terms of Isolation of Search / Metadata, security or anything else I’m not thinking of for each scenario?

Hopefully I'm not over thinking this but i want to get it right in the beginning.
Thanks again Mathew and Colby for all help!
Personally, then if you are not sharing data across divisions I think its easier to go with option 1, since that topology matches the scenario you describe.    However they are both fine unless you are planning a huge deployment (in which case, see my post above).  You are going to have to do muliple configurations whatever way you go.  The best practice to achieve this is to create "features" to configure your sites/metadata/content types/lists etc, or you could try saving a site as a template and using that.  

As stated, web apps allow you to specify different security protocols on the site, however this doesn't mean that you can't have different security settings per site collection/site.  They also allow for alternative access mappings, so nice URLs, but there is no reason why you do not do that on the root and have sub  sites below as you described, its your chioce.

You can backup/restore at each level: ie. site/collection/web app/farm, so splitting at web app level gives you more granularity.

If you want to go with site collections and split content DB's, then that is possible but awkard. SO again that is your decision.  

In scenario 1 you have service applicatiosn per web app, so this is overhead.  However it also offers resilience.   For example with two web apps you get two search services, and you can configure these to run on seperate servers in your farm, one for each wed app, ading both resilience and power.  You can probably do this using the 2nd topology too, but I don't know how.

Your questions are answered in the link I gave you I hope, but specifically::
1: apparently not (but I do - see above)
2: no (unless you want to). I do, but that is because each division has its own AD domain.  Unless you want differnt sets of engineers adminstering the different divisions, I can't see the point.
3: I'm not sure I know what you mean by "service pools".  If you mean app pools, see 1:
4: No just have a single account for this (but best pactice not to use the farm admin account).

To sum up, both designs are correct unless you have a specific need to split at web app level (security protocol, size, etc).  However it may be simpler to go with web apps simply because that topology matches your desired outcome.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SharePoint

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.