Last time I gave a brief overview of why we set out to re-develop the Publishing features in MOSS 2007 for WSS. 

Our customer had a particular scenario which meant MOSS would be cost probitive and they needed to publish content from a single source out to their internal "Extranet" (this is not a spelling mistake - their business is federated and therefore their extranet is running on an internal network).

This post will start to address the how, albeit at a fairly high-level to start with.
To re-cap quickly (skip this paragraph if you read the last post).  

1. Customer needed to publishing content from MOSS 2007 (Intranet)  to a WSS 3.0 (Extranet)
2. The publishing experience needed to be as close as possible to the current MOSS publishing feature.
3. Build a publishing feature to be compatible across MOSS 2007 and WSS 3.0 – this would allow pages to flow between the 2 environments.

Our approach - “lowest common denominator”
When we consider that the destination Extranet server will be running a sub-set of SharePoint functionality currently available in the Intranet MOSS environment, it’s imperative to reduce/remove the dependencies on MOSS components without losing the MOSS functionality. 
An example of this is the Content Publishing features of MOSS.   These features are key to how content is managed on the Intranet, however, we can simulate these on the Extranet without imposing a MOSS licensing cost.  This was important to the customer as it was cost prohibitive to buy MOSS for their subsidiary business users.
It is also possible to deliver similar Content Publishing components without imposing a licensing overhead (like Content Query web part).   We achieve this through development and customisation; specifically replacing Microsoft built-in components with “freeware” components built within the SharePoint community. 
Bringing the MOSS Intranet back to a “lowest common denominator” (and not using the Publishing feature) facilitates a simpler content migration path.  In effect, we simulate and replace as many MOSS features as possible without using MOSS features.
In fact, we have a situation now where MOSS would be in question as needed for their Intranet except for the fact that Forms Services and People Search are required.
The following components are required to be replaced or augmented in Intranet for a possible synchronisation of content with the WSS v3.0 Extranet site. 

• Turn off the Content Publishing features in MOSS. The list below represents Publishing features affected: 
  • Libraries (Site Collection Documents, Site Collection Images, Style Library – these are global libraries that can be re-created.)
  • Lists (Content and Structure Reports, Reusable Content, Workflow tasks, - these lists can be re-created.)
  • Administrative  links (These are links to the Site Settings page, including the ability to manage Master Pages, Navigation, Searchable columns, Content and Structure, Content and Structure Logs, Variations and Translatable columns.  These will need to be re-created or replicated.)
  • Additional Master Pages and default Page Layouts are stored in the Master Page Gallery (This needs customisation to support the current master page and layouts)
  • Content Types and Site Columns (These are global components that are either not used or are easily re-created)
  • Web Parts (Content Query Web Part (CQWP), Summary Links, Table of Content. These will be replaced (if needed) by functionally similar Web Parts.)
  • SharePoint Groups (The following SharePoint Groups are created and can be re-created if needed: Approvers, Designers, Hierarchy Managers, Quick Deploy Users, Restricted Readers and Style Resource Readers, and although I do not find some of these groups useful in non-publishing site, there are some that will need to be recreated, such as the Approvers SharePoint Group.)
  • Personalised Views (The personalise option is installed as part of Publishing feature, only Shared View is supported without the Publishing feature).  This will not affect the viewing of Extranet content by anonymous users.  For Intranet users, adding personal views and web parts will not be possible as this is a Publishing feature and we have not scoped including this. 
• Workflows for content approval; simulate/replace content publishing workflows and port these to Visual Studio workflows. 
• Base the custom site templates on a collaboration portal templates rather than publishing templates
• Replace the Breadcrumb navigation with custom control to cater for different location of page content.
• Build our own navigation provider for the top-level navigation.
• Setting of the Master Pages and Welcome pages in WSS.
• Custom layouts and the Pages library (although our solution supports publishing pages to any library, not just the Pages library.
• Editing toolbar – this was a major component in making the editing process seamless.
• Implement the “free” Telerik RADEditor control/web part to assist with the Content Editing process.

Compare “features” set – align as much as possible
We needed to align features across the MOSS Intranet and WSS Extranet as much as possible. Most content migration issues relate to there being a mismatch in “features” between the source site template and the destination site template.    When the base or underlying site templates are different or have different features installed, it is likely that the migration will fail. 
All features installed and activated are to be the same across the MOSS Intranet site and the Extranet site, these include:

• Web parts 
• Custom content types 
• Custom features
• Custom workflows – like the moderation approval and cross-site content publishing.

Custom layouts and master pages –getting these into WSSv3.0
The Content Publishing features of the MOSS Intranet supports the ability for pages to be created and moderated.   When pages are created, users have the option of selecting a custom layout (which defines content placeholder areas).
It is imperative to simulate the multiple layout support and custom master page support for the Extranet.  This will ensure pages are supported and can load without error.   
The synchronisation of the custom layouts and custom master pages is a customisation as WSSv3 doesn’t support Content Publishing out-of-the-box.

Replicating the Editing toolbar –its works for MOSS & WSSv3.0
Our aim with the Content Publishing feature was to minimise the usabilty impact of implementing a replacement publishing feature.   Our Editing toolbar is exactly the same as the editing toolbar in MOSS and apart from some styling attributes most seasoned MOSS users would find it difficult to pick the difference.
Don’t under estimate the necessity of the editing toolbar, given it drives the editing process, it, along with the selection of layouts and master pages, they are the “killer” features of content publishing. 

Content Synchronisation Options
As with most things, there is always more than one way to achieve the same result.  MOSS and WSS has a very rich content deployment and migration application programming interface (API).   There are many built-in options using this API to make content migration and deployment easy for MOSS administrators.  

Content Deployment – not a viable option
MOSS has various content migration features built-in as part of the Content Publishing and Management features.  However, when looking to synchronised content with a separate WSS v3.0 farm, most of the built-in options either do not work or impose a licensing overhead.
The built-in content migration services as part of MOSS attracts a license overhead.  However, this is not the reason it is discounted as an option – the reason for discounting this as an option is because it does not work across farms, only within the same farm – intra-farm not inter-farm.
The other issue with this is that the destination or Extranet WSS v3.0 needs to accept the “right to receive” content from a source MOSS server and this is not supported in WSS v3.0 .
Finally, using this method, the entire site collection is replicated – this does not allow for an opt-in, only replicate tagged content model.  

Other content synchronisation options
There are three other methods of getting content from one farm to another, these include: 

• Export/import of sites, libraries and lists.  The STSADM utility is used to complete this task and it can be batched or scheduled to update entire sub-sites; or individual lists.   It replaces the entire site/list and there’s no ability to opt content in or out.
• Backup and restore site collection.   The STSADM utility is used to complete this task it can be batched or scheduled.   It backs up and replaces the entire site collection and therefore, as with import/export option, there’s no way to opt content in or out of the synchronisation process.
• Custom Workflow – this is the preferred option and is discussed in detail below.

Custom workflow – the preferred content synchronisation option
The Custom Approval workflow is the preferred content synchronisation option.   These workflows are customisation to SharePoint that action any business rule built into the workflow (via source code). Content can be opted in or out using metadata and migrated optionally on approval or without approval if needed. It leverages the SharePoint Content Deployment and Migration API which is an extremely rich and functional API.

Search
General Search
General Search for the Extranet allows users to search across group-wide published content active/published on the Extranet.   Search crawls all sub-site content and indexes the site content. 
We implemented Microsoft’s Search Server Express 2008 as there was no licensing overhead.  This  integrated with the Extranet WSS v3.0 Central Admin site very nicely, once you sort out the correct install process.  

People Search
People Search or a personnel directory search in the Extranet needed to be created from the ground up – its not supported in Search Server Express 2008 or WSS v3.0.  
With regards to MOSS people search, we couldn't use it because:

1. It had a licensing cost associated with it
2. The subsidiary business users where only “contacts” in the corporate AD (and not accounts), the OU structure for these contact made the LDAP query unusable and therefore were not able to import into the user profile database.

Regardless, it wasn’t relevant to put these contact in the User Profile database as the subsidiary contact would never require secure access to the corporate Intranet - this woiuld have poluted the user profile database with +200K users – they were Anonymous users using the WSS v3.0 Extranet.  

With another hurdle to jump over, we had to “stand-up” a separate/stand-alone people search for the group (including subsidiary business contacts); these contacts were synchronised with various sources to obtain a complete list of the corporations business employees.
A separate SQL database was used to host the contact People search; three main components accompanied this:

• A timer job to run daily (configurable) that imported contacts using LDAP queries to the various OUs to build the SQL people search database tables.
• A SQL web service – this returned the results set based on a query passed in - directly from SQL server
• A search web part and a results web part.  The results part was able to use the same XLST as the MOSS people search.

Next post I’ll cover the things to watch out for, this goes into a little more depth as to the discrete problems you may encounter tackling a project like this.