Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

What are the best practices when it comes to building a SharePoint Extranet? Any good resources out there?

One question that I am particularly looking for some thoughts on is how to best create a water-proof separation between different customers on an Extranet. My experience tells me that it would be best to create a new site collection for each customer. But others in our project argue for a single site collection with a sub-site for each customer. Each sub-site will of course have separate permissions and navigation. They argue for one site collection in order to be able to roll-up shared content with the CQWP.

But in my world a shared site collection is, security wise, just too dangerous a design. The risk that one customer by accident gets access to the sub-site of another customer is just too big.

What is the best practice on this one?

share|improve this question

5 Answers 5

up vote 7 down vote accepted

Have you considered using Tenants?

http://www.harbar.net/articles/sp2010mt1.aspx

http://blogs.msdn.com/b/russmax/archive/2010/04/02/sharepoint-2010-multi-tenant-hosting-part-1.aspx

http://blogs.msdn.com/b/russmax/archive/2010/04/03/sharepoint-2010-multi-tenant-hosting-part-2-configuring.aspx

EDIT: As usual when we are talking SharePoint best practices, the answer is "it depends".

If security is a big issue, this speaks for seperate Site collections. You could still roll up data between SC's using search web parts.

share|improve this answer
    
Thanks for the great links :-) However, we are not looking to build a full-blown hosting environment. Just a "simple" Extranet that a few customers can log on to to view project information from their vendor. –  Lars Fastrup Aug 3 '10 at 9:03

We have had an extranet built on SharePoint since 2006 and we made the initial decision to put each client into their own site collection. I know that's a lot of site collections and for us, since we put each site collection in it's on databases, it's a lot of databases. But we feel like that decision was the correct one. It also leaves the most oportunity for growth and meeting the needs of the client.

FYI, here's a link to a case study done by Microsoft on one of our clients that uses our extranet: http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000003041

share|improve this answer
    
Link to case study is dead. Not surprising due to the age of the question/answer. I thought it was worth mentioning, however. –  nsturdivant Jan 3 '13 at 18:07
    
The word doc seems to still be live on Microsoft's servers. Here's the link if anyone is interested: download.microsoft.com/download/E/7/F/… –  Steve Lineberry Jan 7 '13 at 15:28

Definitely don't put everything in a single site collection, and if you really want people not to even know the other users and sites exist, you'll probably want to look in to the peoplepicker-onlysearchwithinsitecollection property. A lot of the other options depend on where you want to store your users (i.e. using Windows auth, FBA, etc). It's hard to get too specific without a little bit more detail.

Also, aren't you kind of a search guru? :) I would think you'd be able to find search-based solutions for most of the cross-site "rollup" scenarios.

share|improve this answer
1  
Appreciate the kind words :-) Yes, rollup is for sure not the problem in my argumentation. We can use search or build our own simplified CQWP if the search indexing lag is unacceptable to the client. –  Lars Fastrup Aug 5 '10 at 6:32

We made the mistake of putting everything into a single site collection for one type of external program we run. The biggest problem we found was that when doing a security review, it was more difficult to assess where security inheritance was in place and where it was broken. As these types of extranet are ongoing, it's easier to just deal with the problem than try to fix it.

For a new type of program, we're looking for a greater level of customisation and are taking advantage of what site collections provide. Features such as custom navigation and security (clearly distinctive from other site collections), own branding, its own search scope and the ability to more easily deploy the whole site collection to the live site from dev and QA.

share|improve this answer

We usually go with separate site collections in cases like this also. If the site is on SharePoint Foundation, you would not be able to search across site collections, right? I would think that is a nice added security feature in this case as well. You could always have one site collection that is accessible by all customers for common content, then link to the individual site collections for customer-specific things.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.