Does SharePoint 2010 help out in South Africa with our expensive and constrained WAN connections?

  • Article

The SharePoint conference 2009 has been an absolute blast. With so much new and exciting content around SharePoint 2010 it is hard to decide what to blog about. However I thought it pertinent to briefly mention some of the new stuff in both SharePoint 2010 and Office 2010 that will seriously help us out locally, specifically around constrained network connections.

Does SharePoint 2010 help out in South Africa with our expensive and constrained WAN connections? In short the answer is “YES” and in long the answer is “YES”!!! Let me summarise some of the key scenarios which will help.

 

1. Cache Office documents on client computer, with differential synchronisation between Office client and SharePoint server

Office 2010 now has a local file cache which resides on the user’s computer, this is called the Office Document Cache (ODC). When a user opens and document from SharePoint the document is downloaded into this cache and then opened from there. When a user saves the document back to SharePoint it is saved into the document cache and then uploaded in the background (asynchronously) to SharePoint (like email leaving your outbox and going into sent items without you knowing). On top of both this download and upload scenario, only file differentials are sent across the wire, so if only 1 paragraph has changed, it is essentially just that paragraph which is sent on the wire, not the whole document.  There are a few benefits to this ODC model:

  1. A user can open a document previously cached if the SharePoint server is not available e.g. offline
  2. reduced network utilisation which improves both performance and costs (many customers in South Africa pay for the amount of data sent / received)
  3. When a user saves a document back to SharePoint, it seems like it has happening immediately and they get control back of the application immediately, in the background the document is uploaded to the server. Thus having a GREAT user experience.

This uses a new protocol Microsoft has put together called FSSHTTP (File Sync via SOAP over HTTP). There are some important points to note about this though:

  1. It only works with Office 2010 on the client and SharePoint 2010 on the server. This is because it requires new components on the client and server to deal with FSSHTTP
  2. It only works with the XML based Office file formats i.e. docx, xlsx, pptx etc

You might be thinking “what happens if conflict occurs as 2 people could possible edit the same document at the same time?”

SharePoint uses the same multi-master conflict used in co-authoring for the Office Web Applications:

  1. If 2 users change different sections in the document, the changes will be merged
  2. If 2 users change the same sections, you will need to resolve the conflict

2. BranchCache support for SharePoint deployments

SharePoint 2010 supports Windows BranchCache. BranchCache would need some more detailed explanation beyond this post (which can be found in this TechNet article), but in summary it does the following:

If you have a remote/satellite office with users who need to access centralised SharePoint server resources, either a dedicated server in the branch office can be used to host cached SharePoint objects or users desktop machines (Windows 7) can cache objects and share the objects with other user’s machines.

The first time a user in the remote office requests a  SharePoint page / document the object is fetched from the central SharePoint server, but then it is cached on a dedicated local server or on that users machine. Therefore when another user requests the same object, the cached object(s) can either be returned from the dedicated cache server or from another Windows 7 pc which has the object(s).

This model still ensures that a user can only access content they have access to, by ensuring the requests will always still hit the central server to check permissions, even though the object will be returned from a local cache machine.

3. Office SharePoint Workspace

Office SharePoint Workspace (formerly called Groove), is a desktop client application which is installed on a users desktop machine. This product allows a user to copy a SharePoint site’s content onto their desktop PC (offline into SharePoint workspace). The user can then work on the content locally and synchronise it back to SharePoint server either as needed or SharePoint Workspace will do the sync as soon as their is a network connection (e.g. like Outlook’s RPC over HTTP works). The Outlook user experience is a very good one when no network connection exists, and in the same way SharePoint Workspace allows for a similar way of working with SharePoint content.

It also only sends file delta’s between SharePoint Workspace and SharePoint Server (for downloads and uploads). This will improve performance and reduce the amount of traffic on the wire, which once again could save costs.

 

4. Office Web Application pages are generally smaller than downloading entire documents

In most scenarios viewing a document through the Office Web Applications (as HTML) will result in less data coming down the wire than if a user had to download the whole document and then open it in the Office application (Word, PowerPoint, Excel etc). This is because the Office Web Applications only download and show the first page and only when a user selects to move to the next page would it download the next page’s content.

You can configure the default action when a user clicks a document link in SharePoint, and by default it is to open in the Office Web Application instead of the Office client desktop application.

One again, this is a better user experience and saves on bandwidth. Ever downloaded a massive document only to find out it is not the one you want? With Office Web Application, you could see the first few pages, decide that it is not the correct one and then close the document, not needing to download the whole thing.

If you are using FAST Search for SharePoint, then in your search results, you will get thumbnail images for documents in the result set and for PowerPoint documents thumbnail images for each of the the slides in the presentation. This is a similar model which could assist in improving the user’s experience across a constrained network connection as well as save on bandwidth.

5. Page weight of “normal” SharePoint pages

In general SharePoint page weights are less than in SharePoint 2007. The style sheets and JavaScript files are smaller and the product teams are working hard to make them smaller still for RTM. This means that without any of the previous scenarios, a users web page browsing experience should be better based on the page weight.

The product also now has several AJAX style functions in pages which don’t require full page postbacks, this results in less HTML being pulled across the wire in many standard user operations. The user experience feels a lot more snappy and results in less bandwidth consumption.

 6. Page weight of mobile SharePoint pages

SharePoint ships with mobile web browser views for pages in a SharePoint site. These pages are tiny (very very tiny) and so in extreme cases you could even use these pages from a desktop web browser. Not only can you view web pages but you can also view documents in this view. The Microsoft Office documents are rendered in a text only view when selected, the document is stripped of all images and so you can do basic reading of the document, and once again the document is tiny in this mode.

The user also has the choice to see pages in a document as thumbnails (well images, JPG, that are bigger than thumbnails) for a full view of a page without images stripped out. Once again, these page images are much smaller than downloading the document and reading the pages.

In those extreme cases, users can get their jobs done using the mobile views across the smallest of network connections. Yes, might not look that pretty, but will work well.

7. Use Log shipping / Mirroring to copy data to a server close to a user

SharePoint 2010 supports both SQL log shipping and mirroring to “replicate” content databases to SharePoint deployments which are located close to a user. IMPORTANT – this is not a 2-way replication, but rather designed for one-way replication where you copy a site form one location to another and the destination location is read-only for users. This would work well in brochure-ware intranet scenarios, were the users just consume information rather than update information from the remote locations.

As you can see, the team has really put in some hard work to address constrained network scenarios, and using these in combination with each other or even by themselves should make a big difference for our users as well on the cost of our network.

Michael