HttpCode

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.

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. 

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?

Well I've started to get serious about blogging again, I'm now doing some interesting work that will give me the opportunity to post some useful content. In preparation for this, I've redesigned this web site and blog to reflect the new changes ahead.

Also I've started using Twitter more and more, you can follow me at: http://twitter.com/DanielPollard

So its been a couple of weeks with my TyTN II so I thought it would be a good time to write about my experience.with it. Well as I type this I am sitting at McDonalds watching the kids play. In this time I've answered some work emails, checked the cricket score, taken some photos (and posted them to flickr) and chatted on messenger (not to mention writing this post).

Some of the drawbacks I've found are very trivial, I think that it takes to much effort to create a new sms, I get annoyed at silly dialog boxes that assume that you have a stylus. I find the keyboard reasonably easy to use and my thumbs are pretty big.

I really like the home screen that comes on this device, all the tiles are a nice size for my fingers. I must say that windows mobile 6 seems much improved, the multi-tasking is much smoother than previous versions.

I read that one of the cons of this device was the battery life, I haven't experienced any problems myself but I do tend to have it tethered to my laptop most of the day. The other con was the camera speed, this is most certainly an issue it is very slow, for no apparent reason.

I really can't believe its taken me this long to finally go mobile, being able to just browse google maps for the nearest shop of type X or reading google reader on my way home on the train ... I will never go back.