
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

Monday, May 05, 2008
MOSS 2007 Logical Architecture - Zones and Authentication
I've been working on a large MOSS project for the past few months, I've learned a lot about designing and building the logical architecture of a MOSS instance. I thought that I might try to put some of my findings into words. Firstly I'd like to set the scene to some hypothetical scenario:
You have just walked into the offices of Golf Corp, they are a national company that manages the golf handicap and scoring system of 150 golf courses. They have chosen to implement Microsoft Office Sharepoint Server to serve their 1000 staff and 20,000 users. Your mission should you choose to accept it, is to design the logical architecture and the server topology.
From your first meeting you discover the following facts:
- Approved Golf Corp staff can add and edit golf scores and content
- Approved golf course staff can add and edit golf scores only of it's members
- The portal will be the homepage for all Golf Corp staff
- Golf Corp currently uses Active Directory for it's corporate network
- Users should be able to view their previous scores
- Golf Corp already has a SQL Server database with all users and current scores and handicaps.
The first place a new MOSS consultant should look for logical architecture guidance is at the Microsoft reference. The key points are the use of web applications, zones and policy. It has been my experience that consultants who have only worked on smaller MOSS projects (single site collection, default zone, etc) haven't really looked at these concepts.
I will make this a multi-part series, for this Part 1, lets first look at the basics of Zones and Authentication.
A Zone is a URL that users enter your portal on - you can create a total of 5 zones with the names of: Custom, Intranet, Default, Extranet, Internet.
That leads us to our next important bit, each Zone can have a different authentication provider these might include, NTLM / Kerberos, Forms, Anonymous etc.
The next important concept that a MOSS consultant should have is an idea about this diagram:
This diagram is also from the Microsoft reference design, an original Visio version can be found here. This excellent post from the Sharepoint team further explains the concepts that I have touched on here. The post raises a very important point:
When a user request cannot be associated with a zone, the authentication and policies of the Default zone are applied. Consequently, the Default zone must be the most secure zone
This diagram says so much, I will be referring to it in future posts as I cover more topics, the main point of this post however is to cover the top of the diagram, which lists the Zones and the types of users that make use of the zone. It is very important that your MOSS consultant understands these concepts, the next topic of Zone policy will build on top of what I have covered here.
Does your MOSS instance have a Logical Architecture diagram like the one above?
Monday, May 05, 2008 4:38:57 AM UTC
Work

Friday, May 25, 2007
Tech-Ed
Well its all official I've got my Tech-Ed 2007 ticket, I can't wait!
I last attended in 2005 and had a ball. This time I know a few more people who are also attending so it going to be so much better.
I'm looking forward to hopefully attending some sessions on silverlight and WPF.
Friday, May 25, 2007 5:13:13 AM UTC
Work

Tuesday, May 22, 2007
Data Binding
After having a good read of the Family.Show reference application I've been blown away with the power of data binding. I think that with all the hype over how easy it is to now create fancy UI's, WPF may be overlooked for general business development, when in fact its perfect for your average business process application. Of course that's not to say that these applications couldn't use an interaction specialist to help improve the users productivity, until business catch on that WPF has a slightly different development model (one with more focus on usability) it might be hard to justify the extra cost initially.
I've also just read Paul Stovell's data binding example based on winforms technology, it's not be as widely written about, but it seems that some pretty powerful data binding features exist in winforms today, it's just a matter of getting into the mind set. Its pretty cool how WPF databinding is introducing some new concepts to old technology.
Tuesday, May 22, 2007 1:47:36 AM UTC
Work

Monday, May 14, 2007
WPF Family.Show
I've spent some time
looking at the Vertigo WPF reference application Family.Show. It's a really
cool application, while I was playing around with it Rebecca saw it and
immediately wanted it installed on her computer, she's been busy entering data
into it. I hope an open source community forms around it.
The most interesting
thing I found was a presentation by Scott Stanfield at Mix 07, he describes
some of the lessons learnt from building this application. From the sounds of
it the problem domain caused the bulk of the problems. It's certainly a testament
to the design of the WPF that guys who have never used it before can produce
something so stunning and the code is very nicely laid out.
Monday, May 14, 2007 1:35:58 PM UTC
Work
Sign In