So we've talked about creating different SharePoint sites, but we haven't really covered how they're organized. We're now going to explore one of the most important concepts in creating a good SharePoint infrastructure. It's something called a site collection. Site collections can make your life easier. They can make the difference between a scalable SharePoint solution and a disaster. They can stop your life becoming a constant stream of requests. They can allow SharePoint to grow and you to minimize your worry about how it's growing. Many people don't even really know what they are.
Even if you have a single SharePoint site, whatever it is, a team site, a Document Workspace, or anything else, you have a site collection. Every SharePoint site is in a site collection. The first site is referred to as the top level site in that site collection. It doesn't mean it's magic, just means it was first. This could have been a team site, this could have been a blank site, could have been a Document Workspace, could have been anything. And from that first site you then create another site, say a Document Workspace, this is called a sub-site.
Again, it doesn't mean it's inferior. It just means it was created in a site collection after the top level site. Create another site, same thing. It's a sub-site. Now, one of the most noticeable effects on this whole site creation issue is the URL. All SharePoint sites need a unique URL. We can't give them all their own .com domain name. We'd run out of money. Instead, we give them longer URLs. Quite commonly, you will see a SharePoint site with this kind of name. Server name/sites/something.
This could be meaningful, Sales, Operations, Eastern, Western, doesn't really matter. But when you create a sub-site, the URL of the sub-site will always be the name of the parent site/something. Now, the thing is you should end up, not just with one, but with multiple site collections, because site collections are a great way to group your SharePoint sites together. Now, I'm a big fan of liberal use of site collections. You should have several, you may have dozens.
If there is one issue that I hear from people again and again, it's that they started off with one site collection and just dumped hundreds or even thousands of SharePoint sites into it, and now it's a real pain to maintain. Navigation is difficult. It's growing too large for the database. Security is too different between parent sites and sub-sites. So why would you split your site collections apart? Well, one of the classic first reasons to do this is that you're splitting by department or organizational unit. Maybe Operations needs their own group of sites, Sales needs a different group of sites, and there is not much crossover in personnel.
They don't really need to know about each other. But what are the benefits of doing this? Well, there is a lot of benefits of creating site collections. You get, for example, lot of dedicated resources, dedicated recycle bins. Site collections can have their own databases. You get dedicated usage reports, dedicated shared libraries. When you're working with security, the idea is that creating security on a top level site will filter down to sub-sites, so it's much easier to set them up that way. One of the best ideas is really this idea of distributed administration.
By creating multiple site collections, we can push out some of the administrative tasks throughout the organization. But here's the problem. Typically, most power users, even if they have a permission to make a site, they cannot create a site collection. It takes high administrative permissions to be able to do it. So while I am going to show you how it's done, you may sometimes have to ask your farm administrator for a new site collection, and they are often reluctant to do it, but do know that it's often because they don't really understand the benefits.
So you may need to educate them.
- Understanding a SharePoint team site
- Navigating lists and libraries
- Creating Document Workspaces
- Using versioning and check-in/check-out
- Integrating with Office 2010 applications
- Adding and deleting users
- Creating workflows
- Working with server site templates
- Creating a wiki and a blog
- Working with rich media
- Managing documents and other content
- Sharing information with charts and status indicators
Skill Level Beginner
Q: In the "Adding a user to a site" movie, the instructor shows how to add a user to SharePoint and demonstrates by adding a user named “gini.” But gini is already set up and recognized by SharePoint. What if I have no users set yet? How can I add someone?
A: SharePoint doesn't store a separate user database; it wants to be pointed to an existing source of users, like Active Directory. If you don't have that, you need to first add your new users as local accounts on the Windows box you installed SharePoint on. Only then will you be able to give them permission on a SharePoint site.
1. SharePoint 101
2. Core SharePoint Sites: Team Sites
3. Core SharePoint Sites: Document Workspaces
4. Core SharePoint Sites: Meeting Workspaces
5. SharePoint Lists and Libraries
6. SharePoint 2010 and Office 2010
7. SharePoint Sites and Site Collections
8. SharePoint 2010 Security
9. SharePoint Workflows
10. SharePoint 2010 Server Site Templates
11. SharePoint Documents and Content
12. SharePoint Communities
Creating a SharePoint blog2m 48s
13. SharePoint Search
14. SharePoint Business Intelligence
- Mark as unwatched
- Mark all as unwatched
Are you sure you want to mark all the videos in this course as unwatched?
This will not affect your course history, your reports, or your certificates of completion for this course.Cancel
Take notes with your new membership!
Type in the entry box, then click Enter to save your note.
1:30Press on any video thumbnail to jump immediately to the timecode shown.
Notes are saved with you account but can also be exported as plain text, MS Word, PDF, Google Doc, or Evernote.