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.

> 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.

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?

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.

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

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."

> 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.

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.

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!

> 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.

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.