SharePoint Over the WAN-Bow: How to Implement a Global SharePoint Service

Greetings from New York City! I'm stopping here for a few very busy days to visit my colleagues at AvePoint on my way from London and Berlin to Las Vegas for SharePoint Connections next week.

Unfortunately, my luggage isn't on the same trip. I actually saw my bag arrive at my gate yesterday in London, just as my plane was being pushed back out of the gate. Ahhh, the glamor of international travel!

The enterprises that I've been visiting recently are equally spread all over the world. One of the many common topics we discuss is how to implement a global SharePoint service when users are in remote locations.

The pain point is poor performance for users on the far side of WAN connections--far away from the data center hosting a SharePoint farm.The greatest pain is typically felt in document collaboration scenarios--typical team sites--in which users are opening and saving Microsoft Office and other document types over the WAN. But the pain is also felt in many intranet-published-content scenarios in which users experience slow page loads because SharePoint pages can easily top 1MB in size.

Actually, several solutions exist for "over the WAN-bow" SharePoint usage. Each solution fits certain scenarios for certain types of organizations.  I'll outline each of the solutions I've seen work for customers, and I'll highlight a consideration that many enterprises forget until too late: It's not just about performance!

As with any SharePoint guidance, one assumes a fundamental caveat: It depends. Your requirements drive your architecture and configuration. Any broad-stroke, best-practice guidance is only that--guidance--not prescriptive or "silver bullet" answers. That said, the following are--at a high level, anyway--the options you have for implementing a SharePoint service to a distributed user population:

  • Grin and bear it. When you configure a SharePoint farm, you require exceptionally good performance within the farm--performance from the server to the network layer. It's particularly important that the SharePoint servers can communicate efficiently with the SQL Server(s).
    Microsoft supportability limits and generally accepted guidance prescribe 20ms TTFB (time to first byte) and 10ms latency, but you'll probably want much better than that for most SharePoint scenarios. The bottom line is that you generally cannot "stretch" the farm itself over slow connections.
    While there are workarounds I've seen in which Web front-end servers (WFEs) are placed on the far side of a WAN connection from other parts of the farm, such configurations are fraught with potential problems and are often stretched beyond supportability.
  • Optimize SharePoint. By optimizing branding (CSS, master pages), JavaScript, and other SharePoint page elements, you can reduce the size of pages SharePoint returns. A session at the Microsoft SharePoint Conference (SPC374) discussed optimizing SharePoint websites. Talented SharePoint branding experts can also do a lot to optimize SharePoint page payloads. See Todd Baginski's "Building Custom WCM Sites with SharePoint 2010, Lesson 1."
  • Optimize the network delivery of content. Several solutions address network content delivery. WAN accelerators, compression, and caching all play a role here. I have had more than one global customer with users in the most distant places, who has managed to eke out enough performance from the network to make SharePoint tolerable for certain scenarios. Riverbed Technology is one of the main players in this space--probably the most common vendor name I hear mentioned in that respect.
  • Take the content to the users (remote farm). The best solution--from a purely performance perspective--is to place a SharePoint farm on the far side of a slow WAN link, and use that farm to support local collaboration.
    Creating additional farms for geoperformance makes sense for other reasons that I'll address in a moment, but each new farm adds complexity to the environment, and makes the service slightly more difficult to manage-in terms of security, reporting, recovery, and availability-particularly if you don't use one of the many third-party tools that make it so much easier to manage multi-farm, distributed SharePoint environments.
  • Take the users to the content (remote processing). The flip side of the previous solution is to take users to the content. That is, perform the "heavy lifting" on the side of the WAN that is closest to the SharePoint content. Office Web Apps, for example, can be running on the farm, accessing large Office documents stored in the farm, and rendering a browser-based interaction with that content that's then delivered over the WAN. This can be--depending on the scenario--more efficient than users opening and saving documents over the WAN to their locally-installed Office client applications. Another variation of this approach is using Remote Desktop Services on Windows (or equivalent solutions from CITRIX or others) running on servers in the same network as the SharePoint farm.
    Users interact with large documents in a remote session-either a full remote desktop or a published remote application-so that processing is happening on servers local to the content, and only the remote session is being transmitted over the network. Remote desktop protocol (RDP) is already highly optimized for WAN access, so this can be the cleanest solution.
    I see this approach being used with increasing frequency to enable users to open large PDFs, images, and AutoCAD documents stored on a central farm from a remote office. Keep in mind that with remote application publishing and modern Windows clients (e.g., Vista or Windows 7), the user can be launching an application that appears to be local to them but is actually running remotely. It can be a beautiful, transparent experience to the user. RDP-based solutions can be quite effective, so be sure to consider it against each remote scenario you're trying to support.

Each of the approaches outlined above works in different scenarios. Each is a valid approach. However, one problem I have seen with some regularity is that enterprises approach "over the WAN-bow" scenarios with an eye only on performance. And that's the rub: It's not all about performance! You must consider all of your requirements, including information management requirements.

Here's a scenario that illustrates what I mean. I had a customer who was in the mining business, with mines in remote places. They had a network infrastructure team that was pretty close to voodoo masters--they could eke insane performance out of really bad network connections. It seemed their only limit was the speed of light itself. So this company assumed it could tackle all problems by optimizing the network, and they started down a path towards a single, global SharePoint farm stored in their corporate data center.

Against my recommendations, they proceeded down this path only to realize, too late, that they hadn't considered the business requirements they wanted to support with SharePoint. One of those requirements was to provide regulatory-environment-required safety information and emergency response procedures to each remote mine.

Because of this very typical business use of SharePoint-to provide information that might be required to be available locally--a single global farm doesn't cut it for many customers I visit. Nor does a cloud-based solution, which also might be inaccessible in the event of disasters.

I hope this overview of the major approaches to bridging the WAN gap, along with a practical illustration of why you must consider more than performance, will help you conduct a rich, fully-informed discussion with your business and your technical teams. This is an area where I and my company spend a lot of time, so I'm happy to help wherever I can.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish