SharePoint Replication

Do you have the following scenario? “Head office (HQ) with remote locations – location A and location B. Due to bandwidth/geographical consideration, staff at location A Or B do not want to view documents stored at HQ or at the other location. Everyone wants a copy of other location locally”. An ISV product Syntergy Replicator is available to resolve this common situation.

A picture is worth a thousand words – here is a rough schematic of the solution. Syntergy Replication

We proceed as follows. Head Office has SharePoint Portal Server 2003, Location A & Location B have Windows SharePoint Services. In each case MS-SQL server is needed. “EDIT” – The replicator will work with SPS-MSDE but will not work with WSS-WMSDE – I have this clarified from the Syntergy folks who were kind enough to share this information.

A site is created under SPS (http://sps/sites/project). It is designated to replicate to and from each of the locations http://remoteA/sites/project and http://remoteB/sites/project . 3 document libraries are created at http://sps/sites/project, one for each location – Permissions are ‘Read’ all 3 document libraries for entire Active Directory. Head Office doclib has write perms for Head Office staff, Location A doclib has write perms for Location A staff and such for Location B.

The remote SharePoint sites were connected to the portal by using “configure connection to portal” within the WSS. SPS2003 is not asked to search remote sites but only the sites created under SPS, staff at individual locations can search by using WSS (MS-SQL) search. In this way, remote WSS sites are self contained but are also connected to the SPS (visually).

Replicator was setup as a hub and spoke. Each of remote locations replicated to Head Office, then Head Office replicated content back to all. So if someone at Location A added a document, it would be available at Location A, Head Office and then Location B (in that order). 2 way replication setup between Head Office and Location A, &, Head Office and Location B. Location A does not replicate directly to Location B (& other ways around).

Any new document libraries (list, etc) created at any location can be replicated on the fly – there is a configuration setting for this – “select all lists”. If you do not want new libraries to be replicated, uncheck the “select all” box and only select those libraries you want to replicate. This setting is per site.

Any doc lib changed permissions at any locations are replicated.

Conflict resolution can be overridden manually by sending owner, site admin, system generated emails, or system can be configured to accept overrides automatically – this setting is for a virtual server, not individual sites.

This is a good setup and resolution for the problem stated at the beginning.


2 thoughts on “SharePoint Replication

  1. Jplatt

    Did you look at any other products for solutioning? In particular DovAve Content Manager (AvePoint)


  2. nkelkar Post author

    Nope, we didnt. This entry was posted a long time ago – April 2006, I am not sure if DocAve was available during that timeframe.

    Most of the times what happens is, if we find a solution and the vendor is good about support and advising us on strategy, etc we choose to stick to that vendor. IMHO any software product depends on the kind of support we get from the vendor. So that was my take on that.

    Nilesh Kelkar


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s