andymay's blog

Without me realising it Amanda Murphy's blog somehow dropped off my blogroll (possibly when she moved to feedburner) which is a shame because it means that I missed her article on the differences in the way site collections are handled between 2003 and 2007 the first time around.

Now that I needed that information however, it's good to see that my Google-Fu didn't let me down AND I got to update my blogroll so Amanda's back on my reading list again. (Note to self – check feed reader to see if any other reliable posters have "gone away" for no apparent reason).

The points she raises are interesting and there's a big architectural choice implicit in them – namely when you create your MOSS 2007 architecture, what do you actually want to place as the top-level site in the default site collection running in the web application using port 80 i.e. what will your users get when they go to http://yourmoss2007server/ ?

Amanda's right in that for a number of organisations it will need to be some kind of portal (and I see that in the RTM code we ended up with templates for both "Collaboration Portal" for a traditional sharepoint-ish portal and "Publishing Portal" for something which sits more comfortably in the old CMS space).

However this won't necessarily always be the case – the local government customer I'm currently running a pilot for has a relatively mature Oracle portal as their standard intranet organisational portal, which acts as the gateway into a number of their line of business applications. There are a number of technical (and even more political) reasons why that's not going away any time soon, so from their perspective the primary role for MOSS is for collaborative working and document management.

We've done a fair bit of work with them on understanding what their WSS teamsite hierarchy needs to be based on their own functional structures and the extremely hierarchical nature of their information corpus, driven (to a great extent) by the mandates of the government classification list.

For them, the best fit seemed to be a site collection which gives them two tiers of site classification based on a modified version of the site directory (in which no content-holding sites actually exist  – as you would find in a records-management based fileplan) with the actual collaborative sites appearing at level 3 and below.

As with all information architectures it's somewhat of a compromise – it means we've ended up with a reasonably large number of "empty" sites to build the classification skeleton, but it did create for them in a relatively simple and vanilla fashion a structure whereby the collaborative sites themselves sat within an explicit context within a defined hierarchy, which was one of their key business drivers.

Without me realising it Amanda Murphy's blog somehow dropped off my blogroll (possibly when she moved to feedburner) which is a shame because it means that I missed her article on the differences in the way site collections are handled between 2003 and 2007 the first time around.

Now that I needed that information however, it's good to see that my Google-Fu didn't let me down AND I got to update my blogroll so Amanda's back on my reading list again. (Note to self – check feed reader to see if any other reliable posters have "gone away" for no apparent reason).

The points she raises are interesting and there's a big architectural choice implicit in them – namely when you create your MOSS 2007 architecture, what do you actually want to place as the top-level site in the default site collection running in the web application using port 80 i.e. what will your users get when they go to http://yourmoss2007server/ ?

Amanda's right in that for a number of organisations it will need to be some kind of portal (and I see that in the RTM code we ended up with templates for both "Collaboration Portal" for a traditional sharepoint-ish portal and "Publishing Portal" for something which sits more comfortably in the old CMS space).

However this won't necessarily always be the case – the local government customer I'm currently running a pilot for has a relatively mature Oracle portal as their standard intranet organisational portal, which acts as the gateway into a number of their line of business applications. There are a number of technical (and even more political) reasons why that's not going away any time soon, so from their perspective the primary role for MOSS is for collaborative working and document management.

We've done a fair bit of work with them on understanding what their WSS teamsite hierarchy needs to be based on their own functional structures and the extremely hierarchical nature of their information corpus, driven (to a great extent) by the mandates of the government classification list.

For them, the best fit seemed to be a site collection which gives them two tiers of site classification based on a modified version of the site directory (in which no content-holding sites actually exist  – as you would find in a records-management based fileplan) with the actual collaborative sites appearing at level 3 and below.

As with all information architectures it's somewhat of a compromise – it means we've ended up with a reasonably large number of "empty" sites to build the classification skeleton, but it did create for them in a relatively simple and vanilla fashion a structure whereby the collaborative sites themselves sat within an explicit context within a defined hierarchy, which was one of their key business drivers.

I've also just noticed that the Sharepointblogs site seems to think that we're still in British Summer Time here for some reason.

No, I'm not in a time warp – it is only a bit after 3pm here, not just after 4pm as the timestamp seems to suggest.

I've also just noticed that the Sharepointblogs site seems to think that we're still in British Summer Time here for some reason.

No, I'm not in a time warp – it is only a bit after 3pm here, not just after 4pm as the timestamp seems to suggest.

OK, seeing as I now have my MSDN version of MOSS 2007 I've scrubbed a load of rubbish of the disks in my lab and gone for a multi-server build to see how the components will stack up in something approaching a production environment.

In this instance I have a "real" SQL 2005 server and two virtual MOSS servers, one to be an Application Server and one to be a front-end web server purely to render content to the end user. The build, thus far, has gone remarkably simply but I've just hit a bit of an intellectual brick-wall while trying to configure the services on the farm.

Having to start the WSS Search service on the application server purely to enable searching of help content seems a little wierd but I can live with it.

The really confusing thing (or perhaps its just that I'm a bear of very little brain) seems to be the on-screen text accompanying the page to configure the Office SharePoint Server Search Service Settings.

The way I had envisaged it was that in my two-server configuration I would be able to run most of the services on my Application Server (in an SSP environment) leaving the front-end web server to just render content and consume such services as were appropriate.

However it doesn't look as though it works like that. At the top of the page you define whether your App server is going to index content and/or handle search queries. OK – I want mine to do both. This then brings up a number of other options further down the page. All th estuff about accounts is generic and understandable until you get to the last section about "Web Front End and Crawling"

From this it would appear that for your Application Server to act as a crawler (i.e. carry out the indexing function) it also has to be defined as a front-end web server. Err – why ? Surely the indexer creates indexes and then, if necessary, propagates its index to one of the search servers. I can't see any logic to why the indexer needs to be a front-end web server.

Nonetheless this seems to be mandatory, and so moving on we are then presented with a series of conditions for making the server dedicated or not. The help text says:

"Use this option to specify a dedicated web front end for crawling. Crawling through a dedicated web front end will reduce the impact of crawling on the other web front ends in the farm.

OK – so taking those two together it seems to be saying that a dedicated web front end for crawling is a Good Thing and that in an ideal world you have one server which is working purely as an indexer and not running any other services. OK – not too far from the 2003 model (except that there the indexing server typically acted as the job server too)

But…

If your index server is also running the Excel Calculation service or other shared services, select no dedicated web front end for crawling. Otherwise, these services may not work as expected.

So unless you have the luxury of a dedicated application server to act as an indexer then this suggests that you *must not* dedicate it, but instead (by inferrence) allow the crawling service to be shared across all your front-end web servers.

But surely this completely breaks the notion of having a three-tier web / application / database architecture for MOSS 2007. If I set this up the way it seems to be suggesting, I will have the crawling/indexing service running on both my front-end web server and my application server, the search service running only on my application server, and any other applications (profiles, excel services etc) also running on the application server.

It seems, somehow, counter-intuitive to force me to run the indexing service on a front-end web server which I *wanted* to just use for serving content to end users. If one was to be forced to run any applications there, wouldn't it be more logical to force the "search" rather than the "indexing" application?

As always, helpful hints and suggestions (including "Andy – you plonker, you've completely got hold of the wrong end of the stick") gratefully received.

OK, seeing as I now have my MSDN version of MOSS 2007 I've scrubbed a load of rubbish of the disks in my lab and gone for a multi-server build to see how the components will stack up in something approaching a production environment.

In this instance I have a "real" SQL 2005 server and two virtual MOSS servers, one to be an Application Server and one to be a front-end web server purely to render content to the end user. The build, thus far, has gone remarkably simply but I've just hit a bit of an intellectual brick-wall while trying to configure the services on the farm.

Having to start the WSS Search service on the application server purely to enable searching of help content seems a little wierd but I can live with it.

The really confusing thing (or perhaps its just that I'm a bear of very little brain) seems to be the on-screen text accompanying the page to configure the Office SharePoint Server Search Service Settings.

The way I had envisaged it was that in my two-server configuration I would be able to run most of the services on my Application Server (in an SSP environment) leaving the front-end web server to just render content and consume such services as were appropriate.

However it doesn't look as though it works like that. At the top of the page you define whether your App server is going to index content and/or handle search queries. OK – I want mine to do both. This then brings up a number of other options further down the page. All th estuff about accounts is generic and understandable until you get to the last section about "Web Front End and Crawling"

From this it would appear that for your Application Server to act as a crawler (i.e. carry out the indexing function) it also has to be defined as a front-end web server. Err – why ? Surely the indexer creates indexes and then, if necessary, propagates its index to one of the search servers. I can't see any logic to why the indexer needs to be a front-end web server.

Nonetheless this seems to be mandatory, and so moving on we are then presented with a series of conditions for making the server dedicated or not. The help text says:

"Use this option to specify a dedicated web front end for crawling. Crawling through a dedicated web front end will reduce the impact of crawling on the other web front ends in the farm.

OK – so taking those two together it seems to be saying that a dedicated web front end for crawling is a Good Thing and that in an ideal world you have one server which is working purely as an indexer and not running any other services. OK – not too far from the 2003 model (except that there the indexing server typically acted as the job server too)

But…

If your index server is also running the Excel Calculation service or other shared services, select no dedicated web front end for crawling. Otherwise, these services may not work as expected.

So unless you have the luxury of a dedicated application server to act as an indexer then this suggests that you *must not* dedicate it, but instead (by inferrence) allow the crawling service to be shared across all your front-end web servers.

But surely this completely breaks the notion of having a three-tier web / application / database architecture for MOSS 2007. If I set this up the way it seems to be suggesting, I will have the crawling/indexing service running on both my front-end web server and my application server, the search service running only on my application server, and any other applications (profiles, excel services etc) also running on the application server.

It seems, somehow, counter-intuitive to force me to run the indexing service on a front-end web server which I *wanted* to just use for serving content to end users. If one was to be forced to run any applications there, wouldn't it be more logical to force the "search" rather than the "indexing" application?

As always, helpful hints and suggestions (including "Andy – you plonker, you've completely got hold of the wrong end of the stick") gratefully received.

From Bob Mixon who's sat down and done the sums (and mostly for my benefit so that I don't forget)

From Bob Mixon who's sat down and done the sums (and mostly for my benefit so that I don't forget)

If you're deploying (or considering) Office Sharepoint Services 2007 in a regulatory environment, then there's a new white paper on Compliance Features in the 2007 Microsoft Office System just been made available for download.

It has somewhat of a US bias, but doesn't exclusively limit itself to US standards and at least gives a namecheck to the Data Protection Act (1998) and Basel II. The bulk of the document, however, isn't regulation-specific, but is a more general look at the typed of compliance and the MOSS functionality which may be pressed into service to aid compliance.

If you're deploying (or considering) Office Sharepoint Services 2007 in a regulatory environment, then there's a new white paper on Compliance Features in the 2007 Microsoft Office System just been made available for download.

It has somewhat of a US bias, but doesn't exclusively limit itself to US standards and at least gives a namecheck to the Data Protection Act (1998) and Basel II. The bulk of the document, however, isn't regulation-specific, but is a more general look at the typed of compliance and the MOSS functionality which may be pressed into service to aid compliance.