Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium


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

Posted on 2014-08-08
Medium Priority
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 internet.domain.com, intranet.domain.com, my.domain.com or do i setup division1.domain.com, division2.domain.com 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
  • 2
LVL 18

Assisted Solution

by:Matthew Kelly
Matthew Kelly earned 668 total points
ID: 40250127
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: http://office.microsoft.com/en-us/windows-sharepoint-services-it/capacity-planning-for-windows-sharepoint-services-HA001160774.aspx

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

intranetcompanyname.com/sites/division1, intranetcompanyname.com/sites/division2, 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

colly92002 earned 1332 total points
ID: 40251121
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: http://sharepointpromag.com/sharepoint/top-10-sharepoint-2010-configuration-mistakes-and-how-fix-them)

Author Comment

ID: 40253515
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

colly92002 earned 1332 total points
ID: 40253678
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.

Featured Post

 [eBook] Windows Nano Server

Download this FREE eBook and learn all you need to get started with Windows Nano Server, including deployment options, remote management
and troubleshooting tips and tricks

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Excel can be a tricky bit of software to get your head around. Whilst you’ll be able to eventually get to grips with the basic understanding of how to get by, there are a few Excel tips that not everybody will even know about let alone know how to d…
High user turnover can cause old/redundant user data to consume valuable space. UserResourceCleanup was developed to address this by automatically deleting user folders when the user account is deleted.
The viewer will learn how to create a normally distributed random variable in Excel, use a normal distribution to simulate the return on an investment over a period of years, Create a Monte Carlo simulation using a normal random variable, and calcul…
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.

580 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