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

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.