HttpCode

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.

Last week I attended a training session on windows mobile, the training focused on the corporate features of windows mobile and exchange 2007.

Well that inspired me to go and get a HTC TyTN II on the Three network. I rarely stray outside their coverage area, so I think they will be a good fit. The device is absolutely awesome, I've used a number of windows mobile devices over the years and I haven't been overly impressed with them. There are still a few things that really annoy me with windows mobile like silly message boxes (I hate anything that pops up, what's worse is when you need to use the stylus, I HATE the stylus). Windows mobile 6 is a big step up in my opinion, not just for the corporate features.

The device has an inbuilt GPS, which was another influencing factor, since I do a bit of GPS development work. It was the first time that I've had a chance to run google maps, which is simply unreal.

I really like the slide out keyboard, it really works for me, I can use the device without the stylus (maybe 95% of the time), the camera also seems usable.

The big thing is really the data plan, being able to download content in high speed, I really love being connected full time, nothing beats it.

I've been doing a bit of XML work lately, writing and testing XSLT's. I've found that visual studio 2008 is a fantastic environment for this.
Firstly you need to use the properties window of an XML document the two relevant properties are the Schemas and Stylesheet settings.

By assigning a schema to your XML document you will then get validation and intelli-sense when you edit your XML document.
The stylesheet property allows you to select an XSLT to apply to the XML document you are working on, this can be run from the XML menu option and will produce a new output file.

One of the subjects I did for my masters degree was enterprise design patterns based around Fowlers Enterprise Architecture book, one part of an assessment piece was to review a book on patterns. I choose the book Head First Design Patterns, at first I thought I would just glance over it and get a feel for what the book was saying, but I found that I couldn't put it down. The narrative for each pattern is really engaging, it takes you down one path to see the mistakes and finally brings you back to view the full solution. The book is based around java, but the language isn't really important.

I would highly recommend this book regardless of your experience with the classic GOF design patterns.