In this series of posts we will be discussing a solution we developed for replicating SharePoint over satellite communications. This post will cover our client’s requirements and how we leveraged existing technology to provide a stable platform for replication.
A brief history
Following the Deepwater Horizon oil spill in the Gulf of Mexico, oil companies operating in the Gulf of Mexico are now required to keep up to date procedural documentation on the vessel at all times. The documents change frequently due to new regulations or safety concerns and ensuring the quality and usability has become a resource intensive operation for most oil companies.
Vessels used in oil production are typically linked to the mainland using satellite communications. Satellite links are unstable and provide very little bandwidth. Imagine a floating oil platform rocking back and forth while trying to send a signal to a satellite, not an easy task. Most vessels have gyroscopic stabilizers to keep the satellite dish at the proper azimuth but a stable connection is still a rare condition. A large number of the transmissions miss their targets causing the satellite or vessel to resend the data.
Our client’s procedural documentation was stored in a collection of PDF documents to prevent anyone from tampering with the current approved version. Each document had hyperlinks to other documents creating a pseudo web site of PDF documents on the vessel’s file server. The result was usable but not entirely user friendly. Finding a specific document involved hunting through the hyperlinks, which could result in injury if the wrong procedure is used. We needed to create a solution that improved usability and ensured delivery of the documentation in an unstable communications environment. That should be easy, right?
How I learned to stop worrying and love the SharePoint
Our client was using a manual process of approving the procedural documentation for distribution to the vessels. This involved printing the revised document and physically walking the document to each manager and vice president for a signature. We looked at the process and saw that it was a perfect candidate for a SharePoint workflow. In SharePoint, the document’s life cycle could be monitored through each step. It also gave us the ability to do full text searching on PDF documents and an opportunity to add metadata to each document, like any related forms or procedures the end user might need.
Our solution needed to be cost effective and having 40-50 vessels with a full version of SharePoint would have been an expensive solution. Luckily Microsoft offers a lighter version of SharePoint at no cost when used with a licensed version of Windows Server. SharePoint Foundation 2013 gives us the full text search capabilities we need for the end users but not the workflow we need for the approval process. We learned that most of the approvals occur at the corporate offices so we decided on SharePoint 2013 Foundation for the vessels and SharePoint 2013 Standard for the corporate offices to handle the workflows.
SharePoint does not have an out of the box replication engine and replication of the database between sites is not supported by Microsoft. There are third party solutions but each of those solutions presented their own issues. We would need to create our own replication process, one that replicated the metadata with the document. Again, easy right?
Why Distributed File System – Replication (DFS-R)?
Initially, we planned to use Microsoft Exchange to replicate the content to the vessels. Our client has an existing distributed Microsoft Exchange environment which could support the replication. The read receipt feature in Microsoft Exchange could be used to ensure the document arrived safely and Microsoft Exchange will automatically retry when connectivity is spotty. The downside to using Microsoft Exchange for the solution was the need to send a complete document every time it was changed.
In Windows Server 2003 R2, Microsoft added Remote Differential Compression (RDC) to DFS. RDC is a synchronization algorithm which compares fingerprinted blocks of data in existing files between replicating partners. The results of comparison identify which blocks of data are missing or have changed, allowing only the differential blocks of data to transfer. Using DFS-R reduced the need to send a complete document when all we needed was a word changed in the third paragraph of a 20 page document.
We talked to the client’s server support team and they had been using DFS-R to replicate the PDF documents for a few years. They had voiced concern about DFS-R’s lack of status reporting so our solution had to include real-time information about the replication process.
Choosing DFS-R for the replication was easier, knowing the client had experience with it. This meant they didn’t need to support a completely new process; it was a proven technology. Stick with what they know and keep it simple.
Simple Solutions for complex problems
Remember to keep your solutions cost-effective. Sometimes you can find gems in products you don’t typically consider. Try to stay with tools and technologies your client has had experience with. If they have to support it, you probably want to make sure they have the knowledge to do so before going too far down the road to a solution.
What we arrived at was fairly simple, and I hope to cover all of it in the coming weeks.
If you enjoyed this blog, would like to know more, or wants to learn more about Sharepoint, please don’t hesitate to contact us with your questions or comments. We would love to have a conversation with you today about making your business the best it can be through leadership and technology.
Information and material in our blog posts are provided "as is" with no warranties either expressed or implied. Each post is an individual expression of our Sparkies. Should you identify any such content that is harmful, malicious, sensitive or unnecessary, please contact marketing@sparkhound.com
