HttpCode

I’m sure everyone has seen the famous ‘hamburger diagram’ (if you look closely it kind of forms the share of a hamburger)

The diagram shows the end-to-end product offering from Microsoft. The diagram points out some MOSS specific technologies such as Excel Workbooks, but it doesn’t highlight and BDC type interactions which I’m not sure how they would be modelled on this diagram since the BDC can return data straight from the data sources at the bottom, if they did include the BDC the diagram may not look like a hamburger anymore :)

Up until now I haven’t found a good resource to point a new developer who knows .NET but is new to SharePoint.

Well as what usually happens, I stumbled across this article: Introduction to SharePoint Products and Technologies for the Professional .NET Developer

• It covers everything a newbie needs to know:
• Benefits of SharePoint -
• Introduction to all the SharePoint components
• Using Visual Studio 2008 to build SharePoint solutions
• A comprehensive glossary of common terms
• A getting started guide

So I would add this to the list of must read items for that new starter, they have to start drinking from the fire hose at some stage!

The next Sharepoint topic I would like to cover is Shared Service Providers.

A Shared Service Provider (SSP) is responsible for handling:

• Profiles
• My Sites
• Business Data Catalogue (BDC)
• Excel Services
• Office Sharepoint Search

The idea is that the SSP handles all the above information in one place and your web applications can share the SSP. A web application can be associated to one SSP.

Planning SSP's is fairly easy, if you follow the Planning SSP's article you will notice the following:

A single SSP should be used if: There is no explicit reason to use multiple SSPs.

Your default thinking should be to use one SSP, unless you fit into the scenario's outlined in the planning article.

I was reading this excellent Excel Services resource: Excel Services Technical Overview.

It covers:

• What Excel Services is
• Managing Excel Workbooks in MOSS
• Business Intelligence Reporting and Dashboards
• Extending Excel Services

The particular bit of information that I was seeking was this diagram that outlines the core components:

Just a heads up to point out that you can download the stsadm command line parameter posters from here. You can print them out and put them on the wall next to the sample reference diagram.

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.

I've recorded a screencast that is a complement to Part 1 - Zones and Authentication Providers, in this screencast I show how to setup a custom zone to use forms based authentication by extending the existing web application onto a new zone and configuring that zone to use forms based authentication.

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.