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

Posted on 2014-08-08
Last Modified: 2014-08-11
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.
Question by:Adam409
    LVL 18

    Assisted Solution

    by:Matthew Kelly
    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".
    LVL 15

    Assisted Solution

    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:

    Author Comment

    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!
    LVL 15

    Accepted Solution

    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.

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Looking for New Ways to Advertise?

    Engage with tech pros in our community with native advertising, as a Vendor Expert, and more.

    This very simple solution applies to a narrow cross-section of the "needs to close" variety. In this case, the full message in Event Viewer was in applog, Event ID 1000: Faulting application iexplore.exe, version 8.0.6001.18702, faulting module …
    Find out how to use Active Directory data for email signature management in Microsoft Exchange and Office 365.
    This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …
    The viewer will learn how to simulate a series of sales calls dependent on a single skill level and learn how to simulate a series of sales calls dependent on two skill levels. Simulating Independent Sales Calls: Enter .75 into cell C2 – “skill leve…

    761 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    15 Experts available now in Live!

    Get 1:1 Help Now