Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Multiple Site Collections vs. Multiple virtual machines/web apps?

  Asked By: Nicholas    Date: Dec 05    Category: Sharepoint    Views: 2514

I'm still struggling to best decide how to structure our team site
portal.

We have 11 regions with each region having anywhere from probably 5 - 30
divisions, with each division having multiple departments and each
department having multiple sites, etc.

I see two options for this:

OPTION 1
================================

One team collab portal/web app:
- teams.ourdomain.com

11 site collections underneath for each region.
- each region then admins their own collection and
Creates as many sites underneath as needed

OPTION 2
================================
11 team collab portal/web apps:
- region1.teams.ourdomain.com
- region2.teams.ourdomain.com
- region3.teams.ourdomain.com
- etc...

Each web app then has its own admin and
They can add as many site collections as they want.

Both make sense, but I'm not fully understanding the pros and cons of
each and why I might want to go one route over the other?

Are these assumptions of mine correct? Am I missing some obvious ones
when comparing the two?

- multiple web apps = more granular backup/restore
- multiple web apps = performance hit? (Or can they all run under the
same SSP?)
- multiple web apps = each would need their own domain/IP if accessing
via HTTPS, correct?
- multiple web apps = Easier to segregate DBs?
- one web app, multiple collections = easier to share templates and the
like across regions?
- one web app, multiple collections = easier to restrict admin powers
within the regions?
- Others?

Share: 

 

11 Answers Found

 
Answer #1    Answered By: Harshini Raju     Answered On: Dec 05

Keep in mind also SharePoint's limitations on the number of items that
can be stored within particular containers. I don't recall those
numbers offhand, but they've been enumerated before on this list.
That could well be a factor in determining how much granularity you
really need here - how many documents/list items do you expect each
region to create?

That said, multiple  web apps  can run  under the same SSP - we have only
one SSP with multiple web  apps (central admin, MySites, normal sites,
etc.) They all run SSL (https) under the same domain - just that each
app runs on different port numbers.

 
Answer #2    Answered By: Christop Mcfadden     Answered On: Dec 05

> Keep in mind also SharePoint's limitations on the number of items that
> can be stored within particular containers. I don't recall those
> numbers offhand, but they've been enumerated before on this list.
> That could well be a factor in determining how much granularity you
> really need here - how many documents/list items do you expect each
region  to create?

I think my biggest frustration with MOSS is that it expects you to
predict the future before you install it. ;o)

A lot of the planning worksheets that MS provide look like this:

================================================
Determining how many sites  to create worksheet.

Enter the number of sites you need: ______
================================================

;o)

> That said, multiple  web apps  can run  under the same SSP - we have only
> one SSP with multiple web  apps (central admin, MySites, normal sites,
> etc.) They all run SSL (https) under the same domain - just that each
app  runs on different port numbers.

Ah! Well, that sounds like a decent way to handle it then.

What is the main drawback to multiple web apps? I assume it's a bit
harder to share  things like templates? What about sharing content via
content querying and RSS and the like (not that I'm sure we'd really
need that between regions).

This is perhaps more of an SSL issue, but can one certificate handle
each web app if they use unique domains? Or is the certificate tied to
each domain? I personally don't mind port numbers, but have found them a
bit foreign to end users when they need to type in a URL.

 
Answer #3    Answered By: Gopal Jamakhandi     Answered On: Dec 05

I don't have much ot add  to this discussion - limited experience and
all. But, I can mention that I saw godaddy.com offering "six in one"
ssl certificates where they allow you to attach up to six domain names
to a single certificate. The domain names can be any domain - they
don't have to be related to each other. I haven't tried it yet but
figured I'd mention it in response to the SSL query. Otherwise, if all
domains used on the server are a subdomain of the same primary domain
then you can use a wildcard (relatively expensive) certificate.

I'm really curious how well the "six in one" certificate works. If it
does, then why can't someone offer a "25 in one" or "100 in one"
certificate?

 
Answer #4    Answered By: Chantal Rosa     Answered On: Dec 05

They have "Global" certificates that apply to *.domain.com

To implement these though, even if you have the same certificate you
need a different port for each host.

Http can use host headers on the same port, but the network layer that
does ssl NEEDS the host header to validate the certificate, so unlike
http which can pass the host header as an afterthought once a connection
has been established, https:// uses the requested host header as part of
the handshake before a connection is allowed.

 
Answer #5    Answered By: Kyla Eckert     Answered On: Dec 05

We've set up our web apps  using host headers (subdomain.domain.com), SSL, and a
wildcard cert, all on the same port.

See "Configuring SSL Host Headers (IIS 6.0)":

www.microsoft.com/.../596b9\
108-b1a7-494d-885d-f8941b07554c.mspx?mfr=true

 
Answer #6    Answered By: Alisha Holmes     Answered On: Dec 05

Same here.

SharePoint is big enough that I think we can house all our content
management under one application.

In addition to this one application,

We have Central Admin Application

MySites

One public and one protected shared service provider.

Under one application we have one site  collection for our public web,
and we'll roll out separate site collections  as departments have special
needs involving unique security so that the sharepoint groups from these
site collections don't clutter our primary site collection.

There are all sorts of factors to take in to consideration.
Unfortunately the answer is once again "it depends."

 
Answer #7    Answered By: Alexis Ellis     Answered On: Dec 05

> we'll roll out separate site  collections as departments have
> special needs involving unique security so that the sharepoint
> groups from these site collections  don't clutter our primary
> site collection.

Good point! I hadn't thought of that. Another reason to consider
multiple collections, I suppose.

> There are all sorts of factors to take in to consideration.
> Unfortunately the answer is once again "it depends."

Agreed. If only there was good documentation on 'it depends on ______'

It's that blank that I'm struggling with the most.

 
Answer #8    Answered By: Percy Beach     Answered On: Dec 05

Ok. Disadvantages in having multiple  site collections, that I can think of.

1. Do you require seamless navigation between these site  collections? If yes,
I am not sure how sharepoint can provide this. Global Nav, Quick Launch, and
Breadcrumbs all these work within the same site collection.

2. Content query web  part can only pull content from the current site
collection. So, if you go with multiple site collections, pulling content from
one site collection  and showing it in another might be difficult.

3. I also believe the functionalities like Site columns, Site Content Types
are limited to the site collection level and if you need these, you have to
replicate them in multiple site collection and so the maintenance is a
difficulty.

 
Answer #9    Answered By: Mary Adams     Answered On: Dec 05

Just echo and confirm the comments below:

1. Navigation is a pain when you move to multiple  site collections. I
recently built a system that had 80 site  collections that needed to be
linked together. This was a problem, even though there are little things you
can do you are still stuck with navigation being tied to the site
collection. Not to push my push my blog, nut I wrote about using code to
automatically create the navigation quick launch items etc. Links below:

www.helloitsliam.com/archive/2007/07/12/moss2007-
<www.helloitsliam.com/archive/2007/07/12/moss2007---manual-site-colle
ction-portal-connections-and-site-quick-launch-links.aspx>
--manual-site-collection-portal-connections-and-site-quick-launch-links.aspx

www.helloitsliam.com/archive/2007/07/24/moss2007-
<www.helloitsliam.com/archive/2007/07/24/moss2007---portal-connection
s-and-quick-launch-items-part-2.aspx>
--portal-connections-and-quick-launch-items-part-2.aspx

2. CQWP is also bound to the site collection. To go across site
collections you have to use the trusty DataView Web part which is just as
powerful as the CQWP.

3. Content Types etc are also the same. In this instance if you create
your content types as "Features" you can deploy them to each site
collection. If you then need to change a feature, you can then just
re-deploy it to all the site collections.

Just adding to the great comments so far!

 
Answer #10    Answered By: Kundan Jambhale     Answered On: Dec 05

> 1. Do you require seamless navigation between these site  collections?
> If yes, I am not sure how sharepoint can provide this. Global Nav,
> Quick Launch, and Breadcrumbs all these work within the same site
> collection.

This seems to be a perfect example of the 'best practice' contradictions
I've come across in all the planning for MOSS.

On the back end, it sounds like databases should be limited to maybe
15gb and after that, you want to start splitting things apart into
separate site collections.

But then you're breaking up the front end logic as now you lose the data
integration and universal navigation.

I'm finding it hard to reconcile front-end features/needs/organization
with back end maintenance/policies.

It seems that MOSS has omitted an important 'middle tier' of site
organization. It seems as if a concept like 'site collection  collection'
would be ideal...something to tie front-end features between collections
together.

 
Answer #11    Answered By: Alyssa Butler     Answered On: Dec 05

Remember that Security is self-contained within a site  collection.

Also that it is easiest to consume content between sites  when the
content is within the same site collection.

Separate site collections  can exist on separate content databases.

Each new Web app  can use different authentication. A separate web  app in
separate application pools will require more memory on the WFE. If you
have major configuration changes (i.e. web config) to one web app, you
can bring it down, and the others will be unaffected. If you are using
http:// you can use different host headers on separate web apps  without
any trouble. We use https:// to protect credentials from being sniffed.
Every new web app has to be on a separate port because of the nature of
SSL.

 




Tagged: