You definitely want to scale with site  Collections. You will certainly regret
only having one Site collection  in the future if you go that way. With moss  you
have options like the Site Directory to help you get around, as well as the "My
Links" part of the My Sites. If you have one site collection then you can only
have one content  database and that will make backups and especially recoveries
very difficult. You also won't be able to use quotas, as they are applied at
the site collection level.

We are talking a completely customized implementation  using mostly the
WCM functions. Do site  Directory, My Sites, and My Links apply in
this type of implementation? How would we be able to represent to a
user clicking in HR where he is on the site through bread crumbs?
Which site collection  would the navigation  on the home page live in
and how can it be made to relate to the others?

From all the information I'm familiar with, separate site collections
poses a challenge to the developer - and to the content  editor.
Granted, there are a large  number of benefits to multiple site
collections. But think about what is required from a developer to
handle navigation across 10 site collections. How would we handle
personalization across site collections?

We could very well be missing something, but that's why I'm posting
here.

Many design considerations can be handled with seperate site  collections by
specifying your customizations via a custom site defintion. This will allow you
to present a consistent look and feel to any top-level site that is created
within that application. We've had pretty good luck with this in V2 and we're
looking forward to taking advantage of it in 2007 as well.

Unfortunately I'm mainly WSS guy, so I can't speak to how MOSS will handle this.
In our main WSS environment we have around 2000 Site Collections and close to
800 GB of content. There is no way we could have grown to this size with one
Site Collection, and breaking up Site Collections is a huge pain.

Again, think of your backup and recovery times. One Site Collection means one
Content Database. That mean if you need to restore a web, or a list item or
document that has made its way through both Recycle Bins then you have to
restore your entire database. Not only will this take a lot of time, it will
also take a lot of drive space.

I thought you could have multiple Site Collections per Content
Database. Is that not true? I only have one Content DB setup in my
Dev Environment and I can see the ability  to create a new Site
Collection and peg it to an existing Web Application. If it's not
true, do you simply create a new Web Application (and Content DB) and
then plug in the Site Collection there?

You can have multiple Site Collections in a single  Content Database. You cannot
spread a single Site Collection across more than one Content Database. He's
looking at having one Site Collection, which means on Content Database.

Yes, one content  DB can contain multiple site  collections.

If you've got a large  implementation with multiple site  collections
and want to set MOSS up so that a user can login and have certain
preferences that stay with them throughout the site? Or have a
taxonomy that starts from the homepage all the way down through
department sites  and is reflected on all pages and in breadcrumbs
across all pages? I've read docs of the pros and cons of site
collections but personalization and navigation  are common scenarios in
other CMS systems but I haven't yet seen them discussed in an
enterprise implementation.

One way or another we are implementing MOSS - just trying to
understand if these types of issues  are supported out of the box or if
we have to go a more custom route. Either way, they'd seem to be
fairly common issues that many users  will be facing.

I understand. I have the same issues.
I am more on the business part of MOSS and most of my users  adore the
fact that within a site  collection they can easily  (read: no technical
knowledge is needed) use lookups, site columns, content  types,
navigation and yes even the CQW... This is all lost when you move to
multiple collections. Again, this is from an end-user point of view. I
often have a very hard time convincing the business that for some
strange "database backup/restore" reason they cannot have all in one
collection, specially the ones who used working with DMS products before.
Technically I think (and hope) that SQL and MOSS can handle a lot
(maybe not a good idea to have 800GB in one SC :-)) and with a good
backup/restore tool you could provide granular backup/restore
solutions and keep the active/live data in as few as possible collections.

This is exactly the problem  we are trying to wrap our minds around. I
think everyone here can agree that from an administrative standpoint
its best to go with multiple site  collections. That being said, in
the real world this thing has to be usable in a predictable fashion
from a non tech savvy end user perspective.

To that end, from a development perspective two immediate questions
that come to mind:

. I understand that in a portal environment users  can link  to any
content they want, however if the site is made up of separate site
collections the default moss  interface will not allow them to simply
select pages from other collections  to link to. As far as I know they
would have to manually create links to the url's that they see on the
other site collections. Is there anything we are missing out of the
box that could accomplish something like that or are we going to have
to go custom or rely on users manually linking urls?

. Going back to the topic of persisting user data (which may or may
not be a business requirement going forward). If we need to persist
some bit of information that user has selected throughout their
navigation of the portal and they are switching site collections, are
they not in fact changing IIS applications as well. I realize we
could persist something via cookie, but is there a more elegant
solution for persisting some user information across site collections
out of the box in moss or wss?

I think was referring to was that by means of a site
collection, means that the contents (subwebs etc) can not live outside in a
seperate database. In other words, a site  collection lives in 1 and only 1
content database.
This doesn't mean that you can't have multiple site collections  in a single
database as Todd B notes. It simply means that you can't have multiple webs in
a site collection  split across content  databases. Nor does it mean that you can
only have one site collection per database.

For example:

http://server/sites/site1 and http://server/sites/site2 and
http://server/sites/site3
Site1 could live in Content Database 1, and site2 and site 3 could live in
Content database 2.

In Moss, you can tell it wether new sites  created are new site collections, or
subwebs of the existing portals site collection
(I can't remember the MOSS admin link  off the top of my head though)

But, if you want new sites to go into a new content database, you'll need to
visit the Manage Content databases list for the web application and set the "Max
Sites" value equal to the current number. Then MOSS/WSSv3 will only choose any
content databases that have "Capacity" for new site collections to be chosen.

If you create a new web application for just housing a new content database for
a new site collection, then that site collection is not related to your MOSS
portal. You could however add a link to that site in a seperate web application
to the "Sites" directory, but it's still a seperate site outside of your portals
URL namespace.

Like I said, one content  DB can contain multiple site  collections.

What does it mean to use and track information, specifically?

What I meant by "use and track" information was that content  editors
will be only editing content for their department, which would be a
sub-site in a site  collection. If this user was from HR, using
existing content from other site collections  doesn't appear to work.
Web parts don't work cross site collection  and I can't browse to
locate content in other site collections.

As for tracking, if a user comes in to the homepage and then links to
a department - isn't his session information lost? This complicates a
number of issues including  personalization.

Also, using the out of the box sharepoint navigation  is a challenge
with mutliple site collections. How can I natively link  to content in
multiple site collections from the homepage using the sharepoint
navigation?

Basically, what all this boils down to is we can make it work one way
or another. I'm more worried about trying to explain work arounds and
how to deal with them to our large  user base. I'd just expect that
what I'm describing will be very common in larger implementations.

I could totally be missing the boat here - but this post was based on
the fact that 3 developers arrived at the exact same conclusions
separately. For the record, we've taken the dev class and have both
the dev and admin  books.

Perhaps I'm oversimplifying but isn't that the purpose of a traditional
"portal"; to provide the browse and search capabilities across multiple site
collections. In this way, you organize the various contexts that a user will
need to transition to and from. Multiple disparate locations use to be organized
and presented in a taxonomy in an SPS 2003 portal, doesn't MOSS provide similar
functionality?

I agree that the purpose of a traditional portal is to provide easier
access to information and I understand what is being said. In the
most simple terms, what I'm trying to understand is that if you have
an organization  who doesn't want their content  to be completely
separated by site  collections, and wants to share content cross
division how can we bridge these gaps. How would you do this?

Users would need to be able to use content from other site
collections, web parts would need to access content from other site
collections, and potentially maintain  session information about users
across site collections. There is simply too much content to have a
single collection.

Is there an answer? Keeping in mind that we are dealing with a LARGE
organization and content editors who'd need to leverage as much OOTB
MOSS functionality as possible.

The whole reason there's a portal aspect of MOSS is to
do what you're trying to do. You asked about linking to content  in multiple
site collections. You can add links to anything to the top link  bar and the
quick launch, there is no site  collection restriction there. MOSS also has the
Site Directory (which I admittedly know very little about) and it helps in
navigation as well. There are also third party (if MOSS doesn't have it built
in) web parts that give three views to installations with multiple site
collections. It's more work, certainly, but multiple site collections  is very
doable.

Please ask your developers for their specific concerns. Maybe we're missing
something.

Don't get me wrong, SQL and MOSS can both handle large site  collections just
fine, so long as you don't exceed specific numbers of items in a single  list,
stuff like that. Multiple site collections  makes management easier. The
underlying software doesn't require it.

Regardless of the number of site  collections, one problem  that we have run into
with SPPS 2003 is the length of a resulting link  URL with subsites under sites
and folders inside of folders in doc libraries combined with long filenames that
contain spaces. No matter how much you try to educate folks, even TPTB, they
will still do what they want.

Multiple site  collections != multiple application pools. All 2000 of our site
collections are running in a single  virtual server. Users don't need to
authenticate as they move around the site. As for the links, that can be baked
into site templates, or master pages, or any number of ways. Each user will not
have to create links on every page they visit.

Multiple site  collection != multiple ap pools -- that was something we
realized today. That certainly helped with part of the problem.

As for the second part about "baking" links into templates or master
pages. That isn't realistic for content  managed site. I'm not going
to modify a site template or master page every time someone needs to
change a nav.

We are kicking around some ideas about creating a cross site
collection site map via the DOM that we can use to build nav.

No matter how you slice it, there are still some very real boundaries
from a dev perspective with site collections. The real issue as
someone else pointed out is it presents a business problem  to the
content editor. Something they perceived to be simple might require
significant dev effort to actually make it simple.