in

SharePoint Blogs

The Best Place for SharePoint-related Blogs

Dave Wollerman's SharePoint Blog

I use this blog to share information with the community plus also as a repository for reference material on unique situations that I have come across.

View Dave Wollerman's profile on LinkedIn  

Site Collection Logical Architecture

This post is probably not relevant to most people, but I keep running into the same discussions with companies that are setting up SharePoint for the first time or have already set it up and are asking a lot of questions about why their environment is not as flexible as they thought it was going to be. I also seem to get into discussions about this with other SharePoint integrators who don't feel that this topic is important. Maybe they assume people already know the concept or maybe they don't understand it themselves.

I feel that understanding the architecture around the definition and maybe the purpose of sites and site collections is the building blocks of SharePoint. Most people coming into SharePoint for the first time see it as if it were a single web application with a ton of features and settings. They also look at it as if the taxonomy of the sites were a physical heirarchy on a file system. Its hard for some people to grasp the understanding that everything is stored in a database and there is no real physical site hierarchy.

SharePoint Architecture 

With the use of managed paths, site collections can impersonate a physical hierarchy for a means of organization, but the site collections are still on the same level as far as SharePoint is concerned. A Farm, Web Application, and a Site Collection are all "Containers" (or in active directory thinking "organizational units").

As far as when to use a site collection as opposed to using a sub-site, that is based on the organization itself. Usually it is the IT department’s goal to implement the SharePoint system. In most circumstances these people are infrastructure experienced and not experienced in deploying applications. This results in a hodge-podge installation of SharePoint with a single site collection to house everything known within the organization. This will result in a failed installation, since there is no room for scaling. Plus IT will either be burdened with the task of maintaining all the structure and security, or they will demand it (sometimes IT doesn't get the idea of distributed security).

Site collections will allow the IT department freedom to maintain just application itself without the worry of security or content hierarchy maintenance. The following is a list of what an individual site collection offers.

For the Users:
  • Dedicated Recycle bins
  • Dedicated usage Reports
  • Distributed administration (site collection administrators)
  • Dedicated search scopes, keywords, and best-bets
  • Custom feature deployments
  • Dedicated language translation maintenance
  • Dedicated galleries for web parts, master pages, content types, site columns, site templates, and list templates
  • Dedicated shared libraries, such as site collection images and site collection styles
  • Dedicated real estate (Self Containment)
For the IT Administrators:
  • Site quota templates
  • Distributed administration
  • Site locking
  • Database maintenance options
  • Backup / Restore abilities
  • Content Deployments
  • InfoPath forms services global template targeting

I have 2 big, at least what I think is big, points on why to use site collections. The first one is site quotas and recycle bins. The issue is the recycle bin is based on site collections and the quota for a site collection. If everyone shares a site collection, then they share the recycle bins storage size. The example I usually give is HR deletes 1MB per day and IT deletes 1GB per day. With a 5GB site quota, HR content will be flushed through the system a lot quicker if they share a recycle bin. This results in having to restore a database to get back a single document. (You know it will happen, Murphy’s Law). If they were in separate site collections, then the HR recycle bin would be valid for months maybe years with a 5GB quota because it is only affected by their deletions.

The second point is distributed administration. For most small companies this might be a moot point, but for high content driven organizations with a small IT force. It is a godsend for IT. IT doesn't know who should be able to see what content, besides how it should be organized. This is the job of the content owners and users. SharePoint site collections offers IT the ability to create a site collection for a project, team, department, document, or whatever the needs are, then assign an owner and hand it off to them. Now IT has time to work on IT related issues and the content owner now has their real estate to start developing. By this I mean, they now have the ability to quickly create libraries, calendars, meetings, wikis, whatever they feel they need to efficiently organize their content in a meaningful manner to the people who will be using it.... THEM. Plus the ability to allow users to either read or contribute to the site. This is huge since the content owners best know who needs to author, read, consume the content, plus how it needs to be organized. IT usually has no clue which then leads IT down a long time consuming road to interpret how the content owner needs it and will probably have to keep changing it constantly since they are the owner. IT has their own work to do as well.

Published Jun 25 2007, 08:50 AM by dwollerman
Filed under: , , , , , , ,

Comments

 

Andrew Woodward said:

Dave,  excellent posting on sites and site collections.

Even Microsoft fail at times to understand the use of site collections (as is the case with the Microsoft Learning Gateway).  

June 25, 2007 9:39 AM
 

Toby Getsch said:

Excellent descriptions w/ great bulleted lists for users and IT Administrators.  This further clarifies strategy choices I've already made, and gives more credibility to my vision of where and why we're moving towards empowering the people who are closest to the data, but still maintaining control.  Thanks.

June 25, 2007 5:40 PM
 

Greg said:

Very nice. One question though. I understand that each Personal site is it's own top level site collection. Your diagram above makes it look like all personal sites are stored in a single site collection. Can you clarify? Thanks.

June 25, 2007 10:06 PM
 

Sharepoint link love 6-26-2007 at Virtual Generations said:

Pingback from  Sharepoint link love 6-26-2007 at  Virtual Generations

June 26, 2007 5:24 AM
 

Dave W. said:

I agree, I didn't clarify that good enough in the diagram, but yes each personal site is in its own site collection. What I was representing in the diagram is that all the personal site collections are stored in their own web application outside of the SSP but still within the Farm. I have updated the diagram to try and represent it a little better. Thank you for the feedback.

June 26, 2007 7:08 AM
 

Links (6/26/2007) « Steve’s SharePoint Stuff said:

Pingback from  Links (6/26/2007) « Steve’s SharePoint Stuff

June 26, 2007 9:02 PM
 

Mike Walsh's WSS and more said:

July 1, 2007 1:37 AM
 

Matt B said:

Great Discription, Thanks.  It's actually quite logical once it's explained!

July 3, 2007 5:29 AM
 

Mirrored Blogs said:

Dave Wollerman has posted a great article on the use of site collections and the benefits they have for

July 27, 2007 5:02 PM
 

Angie R. said:

Can content be shared across site collections? That is, what if we need unique site collections for each of our business units (for all the benefits you described above) - but 80% of the content ends up being the same across all sites? We won't have to build each page from scratch for each unique site collection, will we?

September 21, 2007 3:00 PM
 

dwollerman said:

think of site collections as individual containers. Each one is separate on to itself. The content in each site collection is separate from other site collections. Templates and site definitions can be used to create a default workspace with defined lists and libraries along with workflows and features that are activated.

September 21, 2007 6:44 PM
 

Angie R. said:

So even if the content is exactly the same, I would have to upload it multiple times, to each unique site collection? Can Sharepoint be extended/customized to overcome this? Or is it a fundamental limitation in the product, no matter how it's configured? Really appreciate your insight.

September 21, 2007 9:24 PM
 

dwollerman said:

site collections are designed to store like and similar content. If each site collection is storing the same content then maybe site collections are not the way to go.

I am not sure what the 80% of content is, but if it is content that should be unique or requires audits and such, then having multiple locations ofr the same content would (or should) fail the audit.

Not knowing your content, you can possibly use content deployment functions as part of MOSS using central administration (or WSS you have to use the STSADM command line utility) to push the content to all the site collections.

September 22, 2007 8:08 AM
 

Angie R. said:

Thanks for your perspective. To give you an example of  "common" content, let's say we're running a number of food-related sites. We would have articles on wine-food pairings, that could apply across all of the sites. So, rather than upload the article on wine-food pairing separately to each site collection, I'd like for only one instance of the content to live in some common repository, and simply "assign" it to the various sites.

September 24, 2007 8:21 AM
 

dwollerman said:

Angie,

There are a few ways you can do this, but not sure if any of the ways are what you are thinking...

#1: Content Deployment

Deploy content to multiple sites. This requires paths and jobs setup though central administration or manually using the command line STSADM utility. Still duplicates will then exist on every site.

#2: Page Viewer Web Part

Create a site that contains the common content then have pages created with page viewer web parts that render the content from the common site. This way there is only a single source for editing / maintaining.

#3: Site Definition or Features

Create a site definition template or a feature that contains the content as ghosted. This way the content exisits on the file system with the site def or feature and sites can then use that content. This still gives the single source benefit, plus allows for each site to customize if needed.

hopefully this helps.

September 24, 2007 8:38 AM
 

Angie R. said:

Thanks for all the info/feedback! You've been a great resource as I try to reconcile the options.

September 26, 2007 5:24 PM
 

Robert Aston said:

Hi David

Great article, sheds so light on some of the questions I have been having about the architecture of site collections.

I have a question though similar to Angies. Say you were to create a site collection for HR and a site collection IT. If the HR site collection had a list of custom training codes and you wanted to use that list as a look up field in a list in the IT site collection how could you achieve this? The two lists are not visible to each other right?

October 19, 2007 2:05 AM
 

dwollerman said:

Nope, site collections are not able to see other lists in other site collections. You would have to develop a custom field type to accomplish this.

October 19, 2007 6:17 PM
 

Alessandro Galanti said:

One question about that.

Can a Site Collection use multiple content DB?

thank you

October 22, 2007 10:23 AM
 

dwollerman said:

No. Part of the hierarchy of site collections are that an entire site collection is contained in a single content database. You can have multiple site collections in a single content database but you cannot have multiple content databases for a single site collection.

October 22, 2007 10:32 AM
 

SteveSelf said:

I relaly enjoy your perpective on the structure...

here is my question

lets say that i whant to use site collections and i have a  site www.abc.com/a/b/c  

i whant to create a site collection for Site C and have no content in site a or site b.... however i whant the ability to create a site collection at a laterday for Site b.. and hopefully not effect any of the data in A B or C  

Is there a way to do this... I have kinda experimited with this and it has broken... so any fixes would be welcome also

thanks

October 24, 2007 3:22 PM
 

dwollerman said:

I do know that SharePoint will choke if you try to create a site or already have a site created where a managed path will be used. I have ran into that in the past and it was a pain to get it resolved (at least in 2003 it was).

I haven't tested this out, but what I was thinking you would have to use is explicit managed paths. You would need one for a/b/c and a/b. I am leaning towards this not working. I honestly don't think you can have site collections that conflict with managed paths.

October 24, 2007 7:42 PM
 

Jacob Egholm said:

I planning to build multiple web sites that needs to use the same masterskins, page layouts, content types and web parts. The content and navigation structure on these sites will not be the same. Should I use a separate Site Collection for each web site or put all web sites in one Site Collection?

October 31, 2007 8:43 AM
 

dwollerman said:

well, this depends on the deployment of the master pages, layouts, content types and web parts.

by default sharepoint shares these items within a site collection, so the quick answer would be to keep it all in a single site collection.

but if you are deploying these items as a feature / solution package then you can deploy them to multiple site collections keeping the solution project as the source file for these items. There is more work involved in the deployment method, but you might benefit in the future using a deployment scheme allowing you to use the mutlitple site collections.

you will have to wiegh the benefits of site collections vs sub site plus the pros and cons of creating a deployment package.

October 31, 2007 12:21 PM
 

rebecca said:

thanks for the great article...

I have been struggling with this age old sitecoll v site question myself...

I know the pros, recycle bin, quotas, turning on and off services in cent admin, but...

isn't it more of a pain to plan navigation between site collections than using sites and sub sites? and what about master pages, themes, page layouts & content types, CQWPs etc? how difficult is it to use these elements across site collections as compared to within the same site collection?

Backups can occur at the site level, no?

Here's my big question: can a top level site and its subsites be migrated later if it is determined a site collection is needed? How difficult is the process?

What about records centers, can there only be one per site collection?

Sorry for the novel size comment. Some implementations can be so hard to decide which to use...others are easy, slam dunks. In each case I want to be sure my client has the correct taxonomy to begin with-a solid foundation for the organization.

November 8, 2007 10:22 PM
 

dwollerman said:

I get this question alot, and usually it comes down to what i most important to what the customer is doing with their environment. You need to balance the flexability and features of a site collection with its limitations.

The limitations of a site collection are there for a reason and that reason is because site collections are not suppose to be related to anything other than itself. Site collections are a means to provide a stand alone secure container to allow like content to be shared within. This means that site collections and their duties can range from a corporate portal down to a simple project adhoc workspace.

Also where customers get confused in the concept is that they expect all naviagion and flow of the portal down to those projects sites to be seemless. Although Microsoft does give you the ability to attempt this with managed paths, and "connect to portal", the reality is that it doesn't encapsulate everything.

Using CQWP across site collection is not possible, you need to write a custom query part to do that.

Master pages, page layouts, content types, site columsn, etc.. would have to be packaged and shared through a solution and features.

Themes are at a farm level and are automatically avaliable for all sites in a farm.

Backups in 2007 can be done from a farm level down to a database level, plus with STSADM you can backup site collections. There is no full backup for a site level.

In 2003, you had "smigrate" which was the frontpage backup site method. That is gone in 2007 and replaced with content deployment mechanisums "export and import". These operations can be found under STSADM or under central administration content deployment section (only for MOSS).

Record center is just a site template, you can apply that just like any other template at any level in any site collection as many as you need.

November 9, 2007 7:12 AM
 

dwollerman said:

Also, to elaborate on the CQWP Across site collections, you can do alot with enterprise search mapped properties to site columns. Dan Attis wrote a greate article as an example:

devcow.com/.../SharePoint_2007_How_to_Rollup_Content_from_multiple_Site_Collections.aspx

November 9, 2007 7:27 AM
 

Sandar Van Laan said:

My thoughts, exactly, Dave. This conversation continues to come up, and separate site collections always seems like the way to go.

Sandar

Trackback: vanlaan.typepad.com/.../site-collection.html

November 15, 2007 6:16 PM
 

Ivan WFP said:

Hi Thanks for your great insights. I am having one problem when running the stsadm - o backup and restore commands. It restores everything quite nicely except the images and the templates that I downloaded off the web and included onto my sharepoint sites. I have looked everywhere for a solution but cant find any do you perhaps know if you can get stsadm back up option to include these sites when it does a single file back up?

December 6, 2007 8:28 AM
 

dwollerman said:

Everything in the site collection will be contained with a backup of a site collection. Make sure that the images and templates you downloaded exist on the farm and web application that you restored the site collection to. The content in the site template gallery should come over with the backup, any images that are located outside the site collection refereneced relativly might not have the same relative path in the new location. There is not enough information in your comment that I can offer a direct answer to. Hopefully this helps.

December 6, 2007 8:57 AM
 

Aditya said:

Hi Dave,

A great article on how SharePoint is architected. I had a question, when we type in a URL (managed path) and hit enter, what is the sequence of events that retrieve the data? I believe the URL is broken into chunks and the query to DB performed for each of the chunk? Can you please explain what events take place, by giving an example?

December 6, 2007 2:36 PM
 

Kat said:

Hi Dave,

Thanks for this terrific information! This is a subject that has been a constant source of concern and frustration for me. I'm an Intranet Manager trying to plan for an upgrade from SPS 2003 to MOSS. In our current intranet environment, we have little content at the portal level (just general news, events, and other non-department-specific info), and we have a site collection for nearly every department and several ad-hoc groups and general purpose sites. Most department and general purpose sites have a top-level site that is readable by all staff, and private collaboration sites are built underneath. We try to use the portal to link to key content in the "public" top-level sites. The problem is when folks expect to find a "forms" library or something like that which contains all forms for the organization. That type of thing has to be manually created w/ a links list that links to the forms stored in the individual "public" top-level sites.

Anyway, when looking at moving to MOSS, the content query web part seemed really appealing for being able to display content from multiple sites in one spot. We were thinking of consolidating into fewer site collections in order to take advantage of the CQWP. But I constantly am concerned about hitting storage allocation limits, having long lists of random list and site templates, breaking permission inheritance everywhere, etc. Your post states most of the reasons I like using the multiple site collections.

We really like having web sites that can be managed by individual departments. They can set it up the way they like, display the information and documents people need to get from them, and manage the security, which makes them happy. It allows them to take more ownership of their content, which helps keep info current. The problem really is always that nagging..."this belongs here...and here...and here" and no one wants to create a bunch of manual links that go dead the second something is moved or deleted.

Any additional advice for this nervous intranet manager? :)

Thanks!

December 14, 2007 9:23 AM
 

dwollerman said:

Use Search... :)

Think of the intranet as how a user uses the internet. On the internet there is no way to keep up with the information that is available by using manual links. Yes there are more important pieces of information that will require a link to make it more easily available. That content is usually not moving around alot and has a set place where it needs to be located, but for more targetted information for an individual, search is mostly used.

On your intranet, it would be virtual impossible to keep up with manual links that are important to all individuals. If an individual uses the search functionality of sharepoint they would be able to find more targetted information that pertains to them and the information they are looking for.

This of course all depends on the search being configured properly for the information people are searching on regularly.

Hope this helps.

December 16, 2007 12:06 PM
 

Kat said:

Thanks, Dave! That does help.

December 17, 2007 9:23 AM
 

Dave Wollerman's SharePoint Blog said:

This post is inspired by a comment I recently recieved from someone asking about when to use site collections

January 2, 2008 1:11 PM
 

Robin said:

Hi,

Thanks for this excellent article.

I am new to Sharepoint and have a question. For internet sites, we would like to have content organized according to countries and use the end-user's browser settings to detect the language/country and provide appropriate country specific content.

In this case, would you recommend creating seperate site collections per country or 1 site collection with multiple sites for each of the countries? Some additional details:

1. Each of the country pages on the site share a common navigation structure - i.e. it is just content that varies but the categories (or sub-sites) are similar.

2. On a few occasions, we also have a need to have the French site show selective German content (in addition to the French content)

3.  In a few cases, within a country site, we have to set up variations for 2-3 languages (say Canada - French and English), Belgium (Danish, Finnish). Can we have multiple such variations within a single site collection?

Thanks, again.

January 9, 2008 5:08 PM
 

dwollerman said:

For the most part depending on what needs to be shown and if there are no security issues, you could create audiences for each country.

As for the variations, yes they can be contained in the same site colleciton. and in conjunction with the audiences, you can use variations for the languages.

for the most part it might be easier to have each country be their own site collection to keep the management of the content using audiences down. It will depend on if you want to have duplicate content in multiple site collections or manage a single copy of the content allowing only specific content by using audiences.

January 9, 2008 7:11 PM
 

Nicole said:

Thanks so much.  I have been looking ALL DAY for this.

I wanted to know when to start a new site collection and you clearly answered my question.

January 16, 2008 4:03 PM
 

Sanjar said:

Excellent article Dave, struggled to understand from other sources but, you have made it simple.

January 22, 2008 1:53 AM
 

John said:

On your second big point (distributed administration): Isn't it possible to assign administration at the site level?

So for instance, when creating  a site you can choose to not inherit parent site permissions.  At that point it will ask you for the names of the groups that you want for Reader, Contributor, and Owner.  Then you can add whomever you want.  Can't anyone in the Owner group do anything with that site and its subsites?

February 22, 2008 6:21 PM
 

dwollerman said:

Yes, you are correct that you can apply unique security at the stie level, but keep in mind that sharepoint groups span the site collection level. this means that IT groups then are managed in the same area as HR groups or any other sharepoint groups. Also site collection administrators are not useful in this scenario since you cannot give IT user or HR user site collection admin status as they will automatically have admin permissions everywhere. There is also the "all user information" area. all users who visit the site are automatically entered into the all users information area, this can get quite full and confusing for managing users at any level throughout the collection.

The point i was making is that since site collections are unique onto themselves and do not interact with other site collections, you can assign owners to the sites. These owners can then manage their own security groups and members without affecting or being affected by other departments, teams, or projects.

February 22, 2008 8:24 PM
 

Joe said:

Good article.  I was confused by this section though:

The example I usually give is HR deletes 1MB per day and IT deletes 1GB per day. With a 5GB site quota, HR content will be flushed through the system a lot quicker if they share a recycle bin. This results in having to restore a database to get back a single document. (You know it will happen, Murphy’s Law).

What do you mean by "HR's content will be flushed through the system quicker"?  Do you mean that, because IT is filling up the quota at a fast rate, the Recycle Bin will be emptied more often than if HR was in its own site collection?

March 13, 2008 9:31 AM
 

dwollerman said:

The recycle bin has 2 stages. The first stage is based on a time limit (default 30 days). The second stage is based on the a percentage of your site quota (default is 50%). Plus the first stage is counted against your site quota limit, where the second stage is not. The second stage bin runs a first in / first out process.

So HR deletes a very important 100k fle on day 1.  IT deletes 1GB of content over the next week. Your site quota is 2GB, which means that your second stage recycle bin is 1GB by default. In 30 days this content gets moved out of the time based bin into the second stage bin which has a quota of 1GB. Since IT has deleted 1GB of content that week, the HR 100K file will be flushed out of the system on day 31 or so.

Now if HR had their own site collection and recycle bin storage. That 100K file could be around for a year compared to just over a month.

March 13, 2008 12:15 PM
 

Karuana said:

Great article... thanx for this input and everyone elses... One note about sharing data across site collections.. it seems to me a problem that MS should have addressed but since they didn't I use CorasWorks to roll up executive data across site collections and maintain master lists of information that are used across the Enterprise... For me we couldn't really implement the best of SharePoint without Corasworks...

Thanx!

March 28, 2008 6:08 PM
 

Gregory S. MacBeth - View Gregory MacBeth's profile on LinkedIn said:

I wanted to say a few things that may help when deciding upon when a Farm, Web Application, Content Database

April 23, 2008 10:15 AM
 

JayGolden said:

Thanks, I was just firming up a SharePoint structure methodology document I have in place. This helped to add a few points that I missed.

Cheers,

Jay

April 23, 2008 2:05 PM
 

Harhar said:

Thanks for the article, very informative for a nube to SP.

Going back to "Also where customers get confused in the concept is that they expect all naviagion and flow of the portal down to those projects sites to be seemless. Although Microsoft does give you the ability to attempt this with managed paths, and "connect to portal", the reality is that it doesn't encapsulate everything."

I work in an organisation moving to MOSS 2007 that wants a lot of site collections (IT, HR etc.) but also wants the Intranet to have a common Global Navigation.

Is the easiest option to do the following:

Connect the Windows SharePoint Services Site to the Portal Site

Although this step is optional, Microsoft recommends that you configure the Windows SharePoint Services site to connect to the portal site. To connect your Windows SharePoint Services site to your portal site:

1.    Connect to your Windows SharePoint Services site, and then click Site Settings.

2.    On the Site Settings page, click Go to Site Administration under Administration.

3.    On the Top-level Site Administration page, click Configure connection to your portal site in the Site Collection Administration area.

4.    Click Connect to portal site, type the URL of the portal site in the Portal Web Address box, specify a friendly name for the portal in the Portal Name box, and then click OK.

April 30, 2008 6:47 AM
 

dwollerman said:

What you are describing is the ability to link the site up to the "Portal", which is whatever you decide to enter in as a URL. This connection will show up in the global breadcrumbs in the upper left of the screen. It will provide a link back up to the corporate intranet.

If the top or left navigation expectations are that they are the same no matter what site collection you are on there is two ways to do this.

1.) manually maintain the navigation (which removes the posibiliy of security trimming)

2.) Custom develop a site map provider that builds the appropiate navigation heirarchy based on site collections.

April 30, 2008 5:54 PM
 

HarHar said:

Thanks, thought that manaually updating would be the easiest way. Foruately it is going to be a pretty locked down structure so controlling it shouldn't be a problem

May 2, 2008 3:44 AM
 

Dave said:

Dave, we have lots of site collections. How can we create a list/report to identify who in the Site Collection Administrator groups for each collection?

Thanks

Dean

May 2, 2008 12:41 PM
 

Brian Merrifield said:

So, I'm a little confused in regards to multiple site collections within a web application. If I have my default web application running on port 80, doesn't that mean that only one URL will be "active" for one site collection?

I have our Intranet site setup really basic right now, but its time to add a seperate department from another site onto our SharePoint server. They want a custom URL, so I don't think a managed path will work (under our current URL).

I've read the specs for multiple site collections in a web application, but just don't see how it relates to a web application.

Thanks,

Brian

May 2, 2008 5:04 PM
 

dwollerman said:

Dave, there is nothing out of the box that will give you a list/report of the site collection administrators for every site collection. You will have to write a custom piece to extract that information.

You could possibly use the content databases and write a SQL query to pull the information out, but I do not recommend it since it is not supported by Microsoft.

May 2, 2008 6:55 PM
 

dwollerman said:

Brian, Web Applications are designed to handle multiple site collections. You can think of a web application as the equivelant to a IIS Virtual Server. The web application is technically just a container when created. It does absolutly nothing until you create a site collection.

When you create a site collection, you need to specify which web application the site collection will be contained. By default there are 2 managed paths. One is a root level (/) and the other is called "sites".

The root level managed path represents an explicit path which means that only one site collection can be created at that location. The "sites" managed path is a wildcard path, which means that multiple site collections can be created using that path.

Multiple web applications can use port 80, but they have to either be on a different IP address, or use a host header. Site collections run under the context of a web application, so one web application running under port 80 means that many site collections can run under the same port..

If they want a custom URL, you might need to consider creating a new web application for them, or look into using site collections with host header mode. Host header mode allows you to specify a DNS name for a site collection. I am not sure of the exact details, but you can see the option under the stsadm -help createsite command.

May 2, 2008 7:12 PM
 

James said:

This is an excellent clarification of Site collections.     I have a client that wants to take the existing single Site Collection with Subsites and split the subsites into separate Site Collections.  

Current hierarchy within One Site Collection:

hostname/Site Collection Top level Site

hostname/Subsite1

hostname/Subsite2

,,,

hostname/SubsiteN

The target architecture will have all subsites in its own Site Collection

hostname/Site Collection Top level Site

hostname/Site Collection for Subsite1

hostname/Site Collection for Subsite2

,,,

hostname/Site Collection for SubsiteN

There is a dependency in the current architecture such that Columns and Content Types are inherited by the subsites.

Can this type of site collection migration be accomplished using STSADM (export/import/backup/restore)?    Would the export/import operations export the any inherited items like columns and Content Type?  

How would you approach this migration from subsites to top level site collections?

Thanks in advanced!

May 6, 2008 9:11 PM
 

dwollerman said:

I don't think you are going to get the content types and site columns to come over with the export/import commands. The recommended method is to create a feature that contains all the shared content types and their related site columns. That way you can deploy to any site or site collection in your organization. There is a tool on codeplex that allows you to export content types to build the feature for cross farm deploymnet (www.codeplex.com/MOSS2K7CTypesViewer).

May 7, 2008 5:45 AM
 

James said:

Dave,  Thank you for the speedy response and advice.  I will give the Content Type deployment by Feature a try!  

Thanks again!

May 7, 2008 7:51 AM
 

sharepoint site verses subsite said:

Pingback from  sharepoint site verses subsite

May 9, 2008 5:46 AM
 

tmmurphy said:

Just like James, Above - I'm taking over admin-ing a SP farm that has many subsites and now wants many site collections.  

The trouble is, they were all set up under the "/" explicit Managed Path, and now they all want to be listed under that "mainsitename.domain.edu/sitecollection" site names.  

James didn't mention this as a problem, but from what I see above (about the explicit path "/" taking only one site collection) and what I've experienced trying to do this (and I've tried using SP Designer as another "backup/Restore" agent ).  So - will it be possible to do this - move sub-sites up under the main site name, all as Site Collections?  I could even move them all to our development server, change something on the main site, then bring them back.

Thanks for any/all help!

-tmmurphy

May 16, 2008 1:54 PM
 

dwollerman said:

tmmurphy,

There are two types of managed paths, wildcard and explicit. By default a web application has a "/" explicit managed path and a "sites" wildcard managed path.

The explicit managed path allows only a single site collection to exist at that path. So anything underneath that path will be sub sites of that site collection. (Example: http://www.domain.com/)

The wildcard managed path allows multiple site collections to utilized that managed path. So for example the default "sites" wildcard managed path will allow multiple site collections to utilize it as shown below...

http://www.domain.com/sites/sitecollection1
http://www.domain.com/sites/sitecollection2
http://www.domain.com/sites/sitecollection3

If we break it down...

http://www.domain.com = Web application
/sites = wildcard managed path
/sitecollection# = top level site (site collection)

if we break down the explicit managed path...

http://www.domain.com = Web application
/ = explicit managed path & top level site (site collection)

So basically you can use either sharepoint designer or the stsadm export/i