Jul 28 2017 09:26 AM - edited Jul 31 2017 04:01 AM
So, SharePoint sites vs. Site Collections has completely baffled me despite reading endless articles and watching many videos! As a very advanced end user, with very little admin. experience, I've recently been given the task of sorting out the existing O365 SharePoint sites / hierarchy in my new company *HURRAH*.
However, I'm utterly confused! Here's what I know:
So, my questions are:
I appreciate that this is a lot of questions, but I've done a lot of reading, watching videos and viewing webinars and I'm at a loss!
Thanks in advance for any help you can provide! Oz
Aug 01 2017 06:42 AM
I think the best answer is "it depends," but this might help.How to Choose between a Team Site and a Communications Site. Yes, when you see "create site" you are actually creating a new site collection - and this is actually what you want for your collaboration spaces. You will have lots of site collections backed by Office 365 Groups for membership when you create Team Sites. (Using Create Site from SharePoint home is probably the easiest way to do this.) When you create a privae team site, you'll want to be sure to assign someone to be the Owner other than you so that they can add other members to the site, both internal and external people as needed. It looks like your questions are about a combination of "broadcast/publishing sites" and private team sites. For department sites that serve as your intranet, you now have two choices - create a "classic" site collection from the Admin center or create independent modern Communication Sites from SharePoint home. Communication Sites should not really have subsites - though they are not blocked in the UI. However, you will currently need to write some code to create a shared navigation for these independent site collections if you want to connect them to feel like a traditional intranet. If you choose to create department sites using a classic SharePoint site collection at the "root," you can create sub-sites with unique permissions for each department. Most of the time, this type of site collection has read permissions for the entire organization and unique edit/owner privileges for each department.
I'm not sure what to recommend for your Operations and Associates sites since I don't know if you are talking about collaboration spaces or communications spaces, but your Project sites should almost certainly each be modern independent site collections created from SharePoint home. That will allow you the most flexibility and security in terms of governing who can have access to each one.
Aug 01 2017 08:21 AM
Let me start by asking a question. You asked plenty of questions so I thought I could ask one too ;)
Why do you care about sites vs site collections?
The general answer here can be:
1. Security (different permissions set from the top of the site collection)
2. Limiting database size ( this is an on premises argument only, As I'm less worried about backups in office 365)
3. Url ( not having to type /sites or /teams)
4. Logical separation
5. Use of site collection limited web parts ( e.g. CQ web part)
If you are now architecting an intranet, I would try and include as many as possible new style sites. So limit yourself to Communication sites (when they become fully available) and team sites with modern SPFx web parts. There are more and more examples available and plenty of consultancies happy to help. I will not mention any here but feel free to contact me.
I agree that all is very confusing and it looks every now and then a bit that Microsoft is offering many differnt options to do almost the same. Making the right choice straight fro the beginning is not always easy.
Aug 04 2017 12:31 AM
Thanks @Susan Hanley - very useful. I think I'm decided that for all our project sites and internal collaboration sites I'll use the +Create Site button in SharePoint home and create a new site collection / Group.
For the Associates 'bucket' I'll probably create a Communications Site although I may want to encourage collaboration between the Associates so may end up creating another standard Group.
For the Operations bucket, I'd like a top-level site with 3 sites underneath, each encouraging collaboration between the relevant people - do you think I'd be better creating 4 standard sites using the +Create Site button and just adding links to the navigation between them, or creating a top-level site and 3 sub-sites? How would this work with regards collaboration - create an assoicated Team for each?
Thanks again and your response has really helped.
Aug 04 2017 12:38 AM
Thanks @Pieter Veenstra - good question! The key reasons I didn't think I wanted lots of site collections were what I've read around:
With the help of you and others, the fog is slowly clearing with regards what structure I should have, but I don't seem to be making any progress on how best to move what we've already got into the new structure when it's created.
Thanks again, Oz
Aug 04 2017 05:34 AM
Aug 04 2017 05:55 AM
An important point to keep in mind is that External Sharing is enabled/disabled at the Site Collection level. For this reason, I typically recommend that new site collections be created for projects that will require collaboration with external organizations. Give that you may want/need to ensure that external partners do not interact with one another, then having separate site collections makes this much easier.
But as the others have stated, it really depends on the specific business/industry/requirements. In your scenario I would expect to create many site collections (possibly one for each project or one for each external partner.
FYI, when you create a new Team (in the Teams app), you will get a new site collection in the tenant.sharepoint.com/teams/.... path. A new Folder will be created in the default Documents library for each channel added to the Team. This site collection will not have external sharing enabled.
Aug 07 2017 02:35 AM
Thanks @Dean Gross - more useful information to help me plan the restructure. I think I'm now sorted for projects (i.e. a new site collection (via a Group) for each) and just have to decide for the other bits and pieces. That said, I now understand how it all works much better so it should be an easier task. The only thing that's still unclear I how I physically restructure existing sites / content (i.e. move document / libraries from one site / site collection to another). Thanks again, Oz
Aug 07 2017 03:35 AM
There are several ways to reorg content:
1. use a 3rd party tool, this provides the ability to keep all metadata, schedule jobs, do batches and much more.
2. drag/drop files - easy, but tedious, and it changes the Created/Modified info and it doesn't work if you have existing custom metadata
3. Use workflows to send files from one location to another - typically not practical if you have a lot of existing data, but can work well to help during a tranistion period.
4. If you have Publishing Infrastructure feature enabled, use the Site Contents and Structure tool to rearrange the Site Collection , this won't help across collections.
5. some others that I'm not thinking of at this time:)
Aug 07 2017 04:10 AM
Thanks @Dean Gross. I don't think the people who setup the existing SharePoint infrastructure have used any of the SharePoint functionality other than filing documents in folders - hopefully drag and drop will therefore be an option despite the change to created / modified information and loss of versions. My other option is probably the third party tools you mention so I need to go and research those. A lot of my reading to date has ended up at ShareGate's website so I guess that may be a place to start. Thanks again, Oz.
Aug 07 2017 05:13 AM
ShareGate is well respected and used by many. Other options include tools from Metalogix and AvePoint
Aug 07 2017 07:53 AM
Another option is to use the Content Organizer, you can send files to a Drop Off library where the get assigned a Content Type, tagged with Metadata and then automatically routed to a final destination. see https://support.office.com/en-us/article/Configure-the-Content-Organizer-to-route-documents-B0875658...
Aug 08 2017 02:45 AM
Thanks again @Dean Gross. I've read up on the Content Organiser - it suggests that you can use this to route documents when you upload them, but does it work for docs which have already been uploaded? Thanks, Oz
Aug 08 2017 05:01 AM
No, it does not work for docs already uploaded, but since it works with the Drop Off library, you could move files from an existing location to the dropoff library and then the rules would get triggered.
Aug 11 2017 09:21 AM - edited Aug 11 2017 09:41 AM
When we create site collections by going to "SharePoint Admin Center -> site collections" (screen below), then it gives us option to create site collection either under .../sites/ or .../teams/.
So "/sites/" really means "/site-collection/".
My question is when creating a "collection" why does it ask for "site" template (like Team Site" or "Project Site") etc. Is that selection only to limit the type of "sites" we can create in that collection ?
Also when I visit the new created collection, I expected to see a "+ Create Site" but looks like the collection created is site itself (screen below). Does not give option to create parallel sites within a collection.
Aug 11 2017 09:47 AM
Your statement about sites meaning site collections is not correct. In that context, /sites/ is just part of the url address and is intended to provide a different path to a collection than the /teams/ path. MS came up with these 2 names when the stared O365 and since the words have very vague meanings they really don't provide much value. Many companies will put certain type of collections in one or the other of these paths, but that is a totally arbitrary decision on their part (the MS Teams app does create new collections in the /teams/ path. )
You are asking an age old question that has existed since the early days of SharePoint 15 years ago :). It has to do with the fact that a site collection is really just a container of sites, when it is created, there is just one site in the collection (the top level or root) and this is created from a "site" template. To make it even more confusing, when you do this in code it is called a "web".
It is theoretically possible to create each site/subsite in a collection from different templates, but this is typically a bad idea.
Some of the site templates are intended to be the only site in the collection, but there is nothing that prevents you from adding subsites to them
Community sites have been around for a long time and are totally different than Communication sites (which are new), see https://technet.microsoft.com/en-us/library/jj219805.aspx?f=255&MSPPError=-2147217396 for some info on Community sites.
Aug 11 2017 11:02 AM - edited Aug 11 2017 01:40 PM
Thanks Dean. So effectively, every collection is a site (called 'root' or 'home' site) and everything else within that collection could only be subsites to that 'root' site. Therefore "site collection" is just one site and the collection of sub-sites under that root site.
Another question which arises is, the main URL of the tenant (say https://abc.sharepoint.com) IS THE BASE SITE COLLECTION created by Microsoft, so which site template does Microsoft decides for that.
Newly added confusion could be, when we create new collections (say https://abc.sharepoint.com/sites/collection-1) and we select 'Team Site' as template, but when it comes to creating subsites to this then Microsoft now allows selection of another templates "communication Site" within this parent "Team Site".
Time to take son for a baseball class ;)
Aug 11 2017 02:12 PM
Aug 14 2017 07:44 AM - edited Aug 14 2017 07:45 AM
Thanks Dean. I completely agree with the advice of keeping it slow and simple.
A very basic question, I was trying to find out how to create additional "sites" within a collection, so I went to that collection (say https://abc.sharepoint.com/sites/Collection-1) by clicking on the URL. Which is basically the root site created automatically for new collection. On visithing this site, when we go to 'Site Contents' it gives option to create "Sub-sites" (screen below). I was trying to find out how do we actually create "sites" (instead of subsites) within a collection. If this option of "subsite" at the collection level is actually just a terminology and these are effectively the "sites" then that's fine. Just wanted to make sure I am not missing anything while setting up the base structure.
Truely appreciate so valuable insights.
Aug 14 2017 07:53 AM
It is just terminology. Site collections contain sites (which can also be called subsites for simplicity).
Site collections are frequently called sites, because people are lazy and MS does not have technical editors enforcing consistent usage of terminology in their documentation:)
When writing code, sites are called webs, which makes this whole topic all the more confusing.
While this article was written for 2013, it applies to SPOnline and may be helpful, https://technet.microsoft.com/en-us/library/cc263094.aspx