www.johntimney.com

Replication is rarely the solution to poor wan links in MOSS - and MOSS deployment support over WAN is not good.  Bear in mind that as soon as you replicate content DB's or sites and have them attached to another site collection in a remote farm you have a possible synchronisation issue unless your audience is read only.

A decision to replicate has to be based on planning with a consideration for WAN link data consumption when adding a MOSS farm.  What's the impact - you need to know the volume a link has to carry before you deploy a farm, as that should form part of your planning exercise to see if new working practice when using MOSS will swamp your network, and it will if you do not plan it up front.  Simple rules like how many read and write operations per day of a typical document size are going to travese our network should be at the front of your mind.  Can the doc converter service help me, can I use publishing to offset traffic - what can be anonymous to offset load etc etc.

Also, if you do chose to replicate - how much data needs to go from one site to another or vice versa and before you decide that have you looked at the options like ISA server caching requests etc. and of course the possibility of harnessing WSS instances at remote sites for collaborative working and consolidating search or shared services centrally.

One other thing to consider is to have two farms in this type of low bandwidth scenario and use content publishing to replicate fixed data (like rarely changing HR policy) between sites, but there are many factors to consider (cost and techncial complexity of course can make this prohibitive).  If this isn't an option and you must replicate then take a look at DocAve from Avepoint as it can do two way replication with synching.
http://www.avepoint.com/products/sharepoint-administration/sharepoint-replication

I've not tested it (yet) but I hear its a fine fish in a river full of slippery eels!

As usual Joel Olsen has a word to say with respect to replication, more for redundancy than in a low bandwidth sceneario, but also as usual the words do carry a lot of value.

Read more here:

http://blogs.msdn.com/joelo/archive/2007/04/02/replication-and-high-availability.aspx

and here:

http://blogs.msdn.com/joelo/archive/2008/01/17/global-sharepoint-deployment-partner-solutions.aspx

I've been asked this question a few times, and I can honestly say I don't have a defacto answer for it.  Can MOSS really do Fileplans?  Myself and a good friend Brian English (who know more than me about information flow in MOSS) had a chat about this.

MOSS doesn’t provide great tools for defining a Fileplan and then enforcing it from that. However many organisations, inc Government, document their File plan in MS Excel or even Word so this isn’t necessarily a huge shortcoming. If the implementation and Design of the FilePlan is in the same tool and that tool doesn’t separate the two activities you run the risk of quality audit non-compliance. If one tool does everything, how do you know that it is doing what it is meant to do, and not what someone has mistakenly set it up to do. This is a common check for ISO9001 Quality Auditors in all sorts of areas which can result in the Fileplan design therefore having to be documented off-the system that enforces it anyway.

So, File-plans are normally defined outside of MOSS, depending on how you want to organise your information storage and the policies around it.  This is then mapped into MOSS using a combination of document workspaces, libraries, lists, image libraries etc. either at a root site level (department) or at a team site level (team) or an individual level (mysite – typically no policy other than manual process enforcement). 

This would include definition of Metadata which could be applied to each document and list item and views hrough which to improve exploitation.

You would build site templates to represent how the taxonomy of these storage areas (for want of a better description) would sit, and the structure for new sites based on the breakdown of the fileplan and new sites would be created to represent this taxonomy and the fileplan breakdown as it was expected to be applied. These can be reused to provide a consistent site structure, they may include standard data, e.g. document templates or links to help or template references (other sites) that you want to deliver to each site. You need to be careful which approach is used as embedding data in site templates can cause problems over time if the data changes significantly and there are a lot of sites that then need updating.

All areas of information storage in MOSS can be team centric (but they don’t have to be) as they can be divisional centric – but those team centric views on information can have policies applied to feed the records centre from anywhere to ensure the fileplan requirement is met.  So the structure of any “drop zone” in the records centre so to speak can have information policies applied that ensure the requirements of the fileplan are met. Ie. If it’s this type of document (email) move to folder X in the record centre and retain for two years then delete. The concept of content types supports the fileplan definition stage, so fileplan elements should be mapped into content types and the content types mapped to MOSS Information Management policy whihc can for all sense and purpose drive your fileplan enforcement.

There is a specific site called the document centre which is designed to offer a more robust document centric view on an organisation than a document library in a team site, where a less formal more hierarchical top level file structure can be created that represents how a logical view of the information might be managed – but it’s a bit of a forced taxonomy.  This though can be applied at any level, as can a folder hierarchy that represents taxonomy based on lists and libraries.  So it all depends on “what” you trying to do with your fileplan and whether it can be done in MOSS.

There are no fileplan modelling tools in MOSS.  You are expected to do this outside of MOSS and enforce the policy of fileplan object types based on specific content types.   MOSS also has no support in its record centre for hierarchical fileplans - you need third party tools like Wisdom, which is MOREQ2 compliant and conforms to the UK National Archive standards.

At this stage, I would probably start repeating an excellent article writtien by MVP  Zlatan Dzinic which goes into more details than I intend to do, and so I'm going to divert you over to that.

http://dotnet.org.za/zlatan/archive/2007/09.aspx

Hopefully I've wet your appetite and Zlatan can serve you the main course!