Monday, May 12, 2008
Part 3 - Site Collections
Continuing on from Part 1 and Part 2 where I discussed Zones, Authentication providers and Policy, this time I would like to discuss Site Collections.
A site collection is a container, it forms the basis of an information architecture where you can create sub sites to build out your information architecture.
Windows Sharepoint Services (WSS) allows the user to create one site collection, that is all of your content will be housed in a single site collection.
MOSS takes a different approach and allows you to create as many site collections as you need, if you turn on self service site creation for team sites, then every site will be a site collection. Even the My Sites are in fact a site collection.
Using managed paths, you can create site collections that form parts of your information architecture.
So what are the benefits of a site collection? The first is distributed administration, each site collection can have different administrators, the other big features are a separate recycle bin and the ability to enforce a quota (as well as the features not covered here).
Each site collection is an isolated collection of sites, you can't use the content query web part to roll up content across site collections (although you could use RSS feeds to do this). This might sound like a bad thing, but lets consider it with an example.
From Part 1 we put forward a scenario where we have staff members and external people accessing a portal, both of these groups need to view different information depending on who they are. Lets assume we had one single site collection, without item level security (which isn't an out of the box feature) all users could see information they shouldn't. Or assume we did have item level security, it would only take a simple mistake to assign the wrong permissions for information to leak.
It might sound like a good idea to have a single site collection, but after you think about it a little more it becomes obvious that it doesn't work when you get past a simple implementation (like what WSS is designed for).
Looking at the reference diagram from Part 1, we see that Microsoft has indeed separated the partner content and internal content into separate site collections.
Monday, May 12, 2008 9:56:25 AM UTC Sharepoint | Work
Friday, May 09, 2008
Tuesday, May 06, 2008
MOSS 2007 Logical Architecture - Part 2 - Web Applications and Zone Policy
In my last post I covered a little bit about Zones and Authentication providers, the next chunk of knowledge that I would like to instill is Web Applications and Web Application Policy (or Zone Policy).
A Web Application is an IIS website with a unique domain name, looking at our all encompassing diagram from Part 1 the web applications are the shaded grey areas (which are labeled as Application Pools).
A Web Application can and should be given different application pool accounts to help secure the system. In the sample application the Intranet site is hosted in a different Web Application than the Team and MySites.
To recap, a Web Application is used to isolate content, isolate users so that we can enforce permissions. There are other benefits as well, but they don't really concern us at this stage in the planning process.
That leads into the next chunk of information: Zone Policy or web application policy.
The concept is that Zone Policy enforces permissions at the web application level, I might have understated that, so here it is again in different words: Zone Policy will override all other security settings.
Now that we have these concepts covered, if we look back at out requirements from Part 1, it starts to become clear what we need to start thinking about:
- Members of golf clubs, should use a web application with a Zone Policy that prevents write operations.
Just to touch on this point again and to stress the concept, no matter what a site collection administrator does, whatever human error is made in assigning permissions, a golf club member will never be able to write to this site.
Lets play devils advocate for a second and assume we took the approach of just using the permissions of the site collection, how do you prevent a user accidentally assigning permissions to someone who should not have them? By now your saying to yourself: Zone Policy.
I'd also like to share a practice that our team uses when we manage a MOSS instance, we use Zone Policy to prevent our Farm administrators from making silly mistakes. We setup a zone like admin.domainname and assign permissions via Zone Policy to the admins, rather than making the farm admin group the site collection administrator. We do this so that the farm admins are forced to think about what they are doing, rather than just blindly browsing as an admin.
I'm working on getting some screencasts up to help drive home the points that I'm making, so keep an eye out for them. Next time we will look at Site Collections.
Tuesday, May 06, 2008 9:24:12 AM UTC Sharepoint
Monday, May 05, 2008
Tip - Stop IE from requesting your Login Details
I thought I might create a screen cast for a bit of fun, so this screen cast shows how you can stop IE from prompting you to enter your windows login credentials:
Basically you need to ensure that your site is in the Local Intranet zone, IE will automatically forward your current login credentials on to sites in this zone.
Monday, May 05, 2008 11:08:51 AM UTC Sharepoint
Sign In