There is alot of information your searching for in your comment, but I will try to tackle them one by one...

1. Yes, search can span your entire sharepoint environment, file shares, exchange folders, etc, but the catch is that you need to have at least MOSS Standard edition to do so. Just having WSS doesn't allow this. WSS only searches its own site collection.

2. Portal is just a term to identify an area where everyone can go for a particular topic. The term portal was used to describe the product for sharepoint in the 2003 version of the product. Now for 2007, the term portal has been removed (although it still shows up in the template names for MOSS Publishing).

So the first question about the top level of a web application. The web application is only a container. It really doesn't contain anything unless a site collection is created. You can create a site collection at the root level url called a managed path. The root level url is defined as an explicit managed path called "/" and there can only be one site collection created at that url.

The other question about having one portal or many in a web application is that Yes, you can have many site collections hosted in a web application. A site collection can use pretty much any of the site templates as its top-level site, so you can have 100 "collaboration portals" in a web application. I am not sure if you want to do them all as collaboration portals, but they give you the option.

As far as where a "portal" would show up in my logical architecture diagram, it would be created as a site collection.

3. The line between decideing to go all site collections or single site collection is very small. There is no really right or wrong answer here. There are pros and cons for each. Microsoft put the scalability of sharepoint at the site collection level. Meaning that if you have only 1 site collection, you can't take advantage of the administration of the databases and web applications. They give you the ability to host multiple site collections in multiple databases across a single web application to assist with both scale, load and performance, and database maintenance.

The problem comes in when you have to report across the information in different site collections. You will need to either have MOSS and use search, or write something custom to roll up information across your farm. Corasworks has a great tool for this as well, but they can be pricey for some companies.

4. Yes, you can have 1 or more (up to 20) SSPs per farm. No, you cannot have a web application be associated with more than one SSP. The SSP allows services to be shared across multiple web applications, such as search, user profiles and my sites, audiences, Excel Services, and BDC applications.

It also is the content index. Meaning 1 SSP = 1 Content Index. You can have multiple sources in the index, but it can only contain 1 content index. If you have another SSP created, then it will have its own content index and searches from a web application in SSP A will not search on SSP B. For an intranet, I have not found a reason to have more than one SSP, so unless you have a very large enterprise company that is expected to have over 50 million items in their content index, I think a single SSP would be fine for your situation. If you create a public internet site or extranet on the same farm, then you might consider creating an SSP for those web applications only.

Hope this helps.

Zach,

I want to start by saying that CorasWorks (last I checked) was not $50K. I believe they are around 12-15K at the most. Using MOSS Search capabilities along with a well designed environment plus content types and site columns, you can come very close to achieving the same results. All it takes is a little thought and creativity to accomplish.

I personally would never recommend a single site collection for an entire companies collaboration needs. I am part of an organization with half that amount of people, and we have many site collections.

I wouldn't short change the benefit and value of utilizing SharePoint to its greatest ability because a company has a limited amount of users. Yes, it might be easier to contain the information all in a central location, but there is a bigger picture. And most of the time it is a different picture for every company. Plus, taxonomy isn't just about organization and hierarchy. It is also related to how a company does buisness. If the company has many projects, then I would never recommend a single site collection. I would recommend a site collection for each project, especially if the client is part of the collaboration.

If the company just wants to publish information to share as an organization, then maybe a single site collection is recommended for the formal enterprise wide sharing of the content, but the collaboration working environments are more adhoc and informal allowing the dynamic ability of a company to quickly adapt to the type of work required to be done. Having this done at the site collection level maximizes the ability to archive the content as a whole, maintain security in its own segragated area, and allow the team to benefit with the extra features they can use that will only target their particular area.

Yes, each sub site can have its own security, but with everyone in a single site colleciton with different admins at levels throughout the hierachy, you open the door for people to over take and create uncontrolled heirarchies and delegations of other users to admin level throughout the environment. This will potentially expose all your data, where being contained in a single site collection "Project A" will not conflict with the settings and security of "Project B".

One thing you can do is create a site and set it up with everything that you need to start a project. You can then save that site as template and use it to create project sites as they are required.

I would recommend at least creating sites for these projects. If it were up to me I would go as far as creating a site collection for each project. Site collections provide the logical separator between the topics of each project. Site collections can be easily setup to lock down for online archiving, and backed up as a whole entity for near line archiving. Please see my post on Site Collection Logical Architecture at www.sharepointblogs.com/.../site-collection-logical-architecture.aspx for more information about the benefits of using site collections.

Using either method (sub sites or site collections), you can use the site template you create to create the additonal project sites. Also with the use of content types and the power of Microsoft SharePoint Server Search, you can easily gather information related to al projects across the organization.

Keep in mind that SharePoint is more than just a single web site, it can be more. Microsoft has designed SharePoint to utilize site collections which a lot of people do not take advantage of. There are a couple posts to check out...

one is mine about SharePoint and Intranets and how they are not just a single web site anymore...

www.sharepointblogs.com/.../corporate-intranet-meaning-through-my-eyes.aspx

the other is a brand new post on the SharePoint Team Blog from the director of technical project management for SharePoint at Microsoft...

blogs.msdn.com/.../sharepoint-platform-and-application.aspx

There is no right or wrong answer here on whether to use sub sites as part of another site or create site collections to host each project. It is up to you, your company, and how they do business. The only thing that I can say is that building an entire working collaborating environment in a single site collection will limit your growth potential (since everything is stored in a single database) and increase administrative work (unique security, shared recycle bins, and limited archiving capabilities).

Make sure you take the time now to analyze how these project areas will be used. Be sure to include administrative responsibilities (disaster recovery, ongoing user management, auditing, sharepoint designer usage, archiving, etc). Look at each scenario from all angles. Once you have done this, which shouldn't take much more than a couple of days at the most, you will have not only the understanding of which way would benefit you and the company, you have the plans to get them accomplished.

Albert,

There is no one way to design and use site collections. It is up to the customer to determine which mix of site collection grainularity they want to use to best serve their funcitonal and design requirements. The purpose of this post was to make people think about what they mean when they say "intranet".

Some customers I have worked with take the more common formal / informal approach meaning that they have a formal area which contains formalized process to publish content and edit pages. These areas are also shared across the corporation. Then have more informal to adhoc content that consists of team sites, meeting sites, project sites, personal sites, etc. that are more private and locked down to a group of individuals.

I recommend a more heavy use of site collections on the informal side, because this is where people are going to be securing content to a lesser number of individuals or groups, plus the content is more adhoc and the site can become adapable to the team, project, etc needs.

The formal side which is governed at a higher level can either consist of a single site collection which is most likely what companies refer to their "intranet" or multiple formal site collections where departments can govern their own "public" areas within the company. This is where my post is trying to change perspective on what an intranet is or can be to an organization.

The reasons of keeping it all in one, or spliting it out has to do with the functional requirements and the benefits of using a site collections vs sub sites. You can read my other blog post about the benefits of using a site collection (www.sharepointblogs.com/.../site-collection-logical-architecture.aspx).

I am not saying every customer can fall into this methodology. There are smaller organizations that would become overwhelmed managing a larger environment because they either don't have the personnel or it is the same person who is managing everything anyway so site collections pose no advantage in those cases other then the technical benefits.

MOSS Victim,

I can see using a single site collection for your public intranet. This is where you have more tightly controlled governance and publically shared information. The information contained in this site collection is not collaborated on.

The more private areas or informal areas for each division, team, project, etc.. .I would suggest creating a site collection for each "topic". This means that if there is a division that needs collaboration space within the division or possibly their own public area to themselves. then they will have a site collection. If there is a project in that division, that project will be a site collection. Even though the project is related to the division, it is in itself it's own "topic" area.

Also, keeping this more ad-hoc information in site collections allow greater flexability when it comes to administration and life cycle management of the information. The tools provided by sharepoint out of the box allows management and administration to occur at the site collection level.