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.

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.

If your index server is not running other shared services, it is recommended to enable the web front end role on this computer and use it as the dedicated web front end for crawling."

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)

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.

From Mart, a quick-and-easy picture to help understand which CALs you may need with your WSS/MOSS 2007 architecture.

 

The long-awaited Performance and Capacity Planning guides for the WSSv3 and MOSS 2007 products have emerged (although somewhat annoyingly they are still carrying the "This content is preliminary content. It might be incomplete and is subject to change" note - come on guys, where are the definitive guides ???)

MOSS 2007

WSS v3

The WSS-only deployment (as promoted extensively by Mike Walsh and others) has always been somewhat underused, partially at least because people didn't really understand the features and facilities which were available in WSS as opposed to the full-blown Sharepoint Portal Server product.

Now in the 2007 world with WSS v3 and MOSS 2007 with both products having an enriched function set, Microsoft have released an easy-to-scan guide for checking off your favourite bits of functionality and seing which of the various SKUs it appears in.

http://office.microsoft.com/en-us/sharepointtechnology/FX101758691033.aspx

Two of the great new things about MOSS2007 are Content Types and the extensibility of the Search function. Put the two together and very quickly you’ll come up with the scenario where you’ve created a nice comprehensive set of metadata which you’ve now applied to all the sites and libraries in your site collection, and now you want search on those metadata items.

 

The Advanced Search web part (typically surfaced through the Search Centre) looks like it’s going to do the job for you, with a drop down box which lets you restrict your search based on properties, but out-of-the-box it quickly becomes apparent that only a subset of the standard properties are there, not your own site columns. The ones you get as standard are:

 

Author

Description

Name

Size (MB)

URL

Created Date

Last Modified Date

Created By

Last Modified By

 

 

There are a couple of additional steps which you have to carry out to make your own appear there, most of which have been documented in various places but I couldn’t find a complete end-to-end walk through for the process, so this is it.

 

Firstly, I’ve assumed that you’ve already set up the site columns, assembled them as content types, and made those content types available within the document libraries of your sites. In my case, I have a set of them which form the core metadata schema for my customer – a mixture of default and bespoke ones.

 

Contributor                 (multiline)                    default

Date Created               (date/time)                   default

Disposal Action          (choice)                       bespoke

Disposal Date              (date/time)                   bespoke

Disposal Review         (date/time)                   bespoke

Document Type          (choice)                       bespoke

Relation                       (multiline)                    default

Title                             (single line)                  default

Topic                           (choice)                       bespoke

Created By                  (person/group)             default

Modified By               (person/group)             default

Checked Out To         (person/group)             default

 

The problem comes about because within Sharepoint 2007 there are two types of properties – crawled and managed. Crawled properties are automatically extracted from crawled content, but users can however only perform queries over managed properties. Thankfully Sharepoint lets us map one or more crawled properties onto a managed property and then, after the next crawl, those properties become available.

 

That description – one or more – is quite important as it permits an element of ‘fuzzy searching’ whereby the metadata category which the user wants to search on may be implemented in a number of different ways across different content types. This lets us hide that from the user.

 

The place to start is Central Admin – Shared Services Administration – Metadata Poperty Mappings. This is where you can check whether the properties you want are already being managed, or whether you will need to add them. For my list above, the “Created By”, “Created Date” [aka “created”], “Title” [aka “DisplayTitle] and “Modified By” properties are present but the “Contributor”, “Disposal Action”, “Disposal Date”, “Disposal Review”, “Document Type”, “Relation”, Topic and “Checked Out To” ones will need to be added. NB It may also be necessary to check the existing ones and add any additional new crawled properties to the list.

 

Adding them is really only a case of clicking the “new managed property” button, giving the property name (no embedded spaces allowed), a description, a type (text, integer, date, etc) and then deciding which crawled property (or properties) to map to.

 

In my case I’m mapping as follows

 

Managed Property	Type	Crawled Properties
CreatedBy	Text	Creator
Created	Date/Time	Office:12 Basic:15
DisplayTitle	Text	Basic:displaytitle
ModifiedBy	Text	ows_ModifiedBy ows_Modified_0x0020_By
Contributor	Text	_Contributor
DisposalAction	Text	Disposal Action ows_Disposal_x0020_Action
DisposalDate	Date/Time	ows_Disposal_x0020_Date
DisposalReview	Date/Time	Disposal Review
DocumentType	Text	Document Type ows_Document_x0020_Type
Relation	Text	_Relation
Topic	Text	ows_Topic Topic
CheckedOutTo	Text	ows_CheckoutUser

 

 

At this point it would be nice if they all just magically appeared in the advanced search dropdown list, but unfortunatley there’s one more step involving evil editing of config files.

 

Go into your Advanced Search page and select Site Actions – Edit Page. For the Advanced Search Box webpart chose Edit- Modify Shared Webpart. In the “Properties” section there is a ‘properties’ dialogue box which, if you click into it, will give you the […] ‘builder’ link allowing you to edit the XML string.

 

This string has four sections, two of which concern us. Between <LangDefs> and </LangDefs> it lists all the languages which can be used and between <Languages> and </Languages> it causes those languages to be displayed in the web part.

 

We’re interested in the bottom two sections however. Somewhere between <PropertyDefs> and </PropertyDefs> we need to insert all of the Managed Properties we added above, following the format of the entries already there. So, for example, for our “DisplayTitle” property, we add the line

 

<PropertyDef Name=”DisplayTitle” DataType=”text” DisplayName=”Title”/>

 

Finally, in the section between <ResultTypes> and </ResultTypes> we need to show which result types we want our results to show up in. So assuming we want our new results to show up everywhere, we find the subsection between <ResultType DisplayName=”All Results” Name=”default”> and </ResultType> and add in the line

 

<PropertyRef  Name=”DisplayTitle” />

 

Exit the “modify web part” process and publish the page if necessary.

According to Bink and a number of other sources both Office System and Vista are within a whisker of RTMing.

Hopefully this meanst that we'll be able to get our hands on the RTM code for download over the next few days - I have a B2TR MOSS box which is trembling in antici....pation.

[Edit]
Depending on who you read, this might be a thin whisker or a somewhat thicker one. Cruisng the blogs this morning it seems that people are "predicting" code availability for a range of slots between "end of the week" and "end of the month" - I guess we'll have to wait and see.

What does seem likely is that the pessimists (including, it must be said, me) who were expecting "before the end of the year" to mean late December may just have to eat our words.

I've been playing with the MOSS 2007 blog template for an internal project, and although I like the quick and out of the bos setup there are a couple of things which escape me (unless I'm being daft).

Firstly, I can't seem to find a way to set up an alert on the blog (or indeed on a posting or comment). I know that one could, and possibly should, use RSS for the purpose, but for me one of the joys of the other lists types is that it gives the user choice of how they get the information - through browse/search on the website, through email notification (alerts) or through subscription to the RSS feed. We have many users who love their email but wouldn't know an RSS feed if it came up and bit them.

Secondly, what has happened to attachments/enclosures? Why is there no mechanism for associating an external file object with a posting

I'm going to make a commitment to doing this myself, but could I put out a plea for people to try to remember to identify the version of the product they're talking about somewhere early in their posts?

Now that a substantial number of us are looking at Office Sharepoint Server 2007/WSS v3 as well as still working on the previous versions, I see a lot of blog entries where it's not clear to me which version you're talking about.

Just my 0.02

Am I the only person who doesn't 'get' Microsoft Live?

I suppose it's possible that it offers nothing to me, or that its marketing is something which doesn't match my receptors, but so far I'm aware of it as a title which pops up in blogs and press releases from time to time.

Convince me someone. 

If you're still trying to get your head around how all the search technologies co-exist and (dare we hope) integrate together, see Arpan's "Enterprise Search 101" posting.

Hidden away down at thebottom of it as well, are a useful couple of paragraphs on licensing which describe how the different SKUs are going to operate. We're expecting a formal announcement of the licensing model mid-August, but this may help in the interim.

"It's important to note that there are different SKUs available that contain SharePoint search. Depending on your business needs, you want to explore the following.

1. SharePoint Server for Search. This is a "Search SKU" and the licensing model is dollars/server. It comes in two versions (Standard and Enterprise) and depending on the number of documents, you want to choose the appropriate one. This SKU builds on top of Windows SharePoint Services (WSS) v3 and has all the extensibility that SPS 2003 has today. There's also an upgrade path from the search SKU to the Standard and Enterprise versions of SharePoint Server.

2. SharePoint Server w/ Standard CAL. This is a Server/CAL licensing model and provides a lot more functionality across the board than the "search SKU". This is also built on WSS v3 and gives you portal and enterprise content management features (for specifics on what SharePoint Server provides, read this post). From a search perspective, this adds the ability to search people and introduces a new extensibility and UI experience known as the Search Center. People search can be enhanced with Knowledge Network for SharePoint which is an add-on if you own this SKU.

3. SharePoint Server w/ Enterprise CAL. This is a Server/CAL liecnsing model and in addition to the capabilities provided w/ Standard, this provides rich Business Intelligence and Forms capabilities. From a search perspective, above and beyond what Standard provides, this introduces a new feature known as the Business Data Catalog (BDC) that allows you to easily search structured LOB systems without writing code. Out of the box, we plan to provide integration with SAP and Seibel as well as any database via ADO.NET. Any LOB system that exposes information via XML Web Services can be connected to.

Please note: While #2 and #3 provide search functionality, they provide rich Information management features that helps information workers share, collaborate, find and retain information end-to-end. It's more than search!

In recap (all will be available in the Office 2007 timeframe):

1. Office SharePoint Server for Search follows a per server licensing model, is extensibile, crawls file shares, sharepoint sites, web sites, exchange pfs, lotus notes databases out of the box. it comes in to versions: standard and enterprise - you choose depending on how many docs. it upgrades to the other office sharepoint server skus.

2. Office SharePoint Server Standard follows a CAL/server licensing model. It provides much richer features than the search SKU. From a search perspective, it provides people search and the Search Center.

3. Office SharePoint Server Enterprise follows a CAL/server licensing mode. It provides more features than Standard such as BI and Forms. From a search perspective, it introduces the Business Data Catalog (BDC) that allows you to connect to LOB systems without writing code."

There has been a real deficit of information relating to the Web Content Management capabilities of Office Sharepoint 2007 but Andrew Connel has been scouring the web and has collected together a master page of links.

http://andrewconnell.com/blog/archive/2006/07/31/3275.aspx