SharePoint Workspace 2010 (SPW) is the new kid on the
block in the SharePoint product lineup —or rather, one of the existing
products with a new name and some new tricks to match.
When the Office 2010 and
SharePoint 2010 product lines were being fleshed out, Microsoft made
the decision to take Microsoft Office Groove 2007, overhaul and add a
number of Share-Point 2010–specific features to it, and rebrand the
resultant product as SharePoint Workspace 2010. Although the product
features that were part of Groove 2007 still exist in SPW, this section
focuses specifically on the features that support SharePoint 2010.
Groove and related functions, such as peer collaboration, are not
discussed.
What Can It Do?
If you’re familiar
with Microsoft Exchange and e-mail, the easiest way to explain SPW is
with an analogy. SPW’s role with regard to SharePoint is analogous to
the role that the Microsoft Outlook client serves for Exchange servers.
Although you can access an Exchange e-mail account using the
browser-based Outlook Web Access (OWA) client, using the Microsoft
Outlook rich client on your workstation adds significant functionality
and improves the usability over OWA alone.
The capability that is front
and center in SPW is the ability it affords you to work with Share-Point
content in an offline, rich client application setting. When SPW is
installed and configured on your workstation, you have the option of
creating offline SharePoint workspaces that are tied directly to
SharePoint sites and subsites. An example of the SharePoint Workspace
for the root Web of a team site is shown in Figure 1.
You can use the
SharePoint Workspace client to interact with SharePoint lists and
libraries, check documents in and out, add new content, and perform most
of the list and document-centric tasks you are used to using a browser
to perform.
Note
SPW’s SharePoint functions
operate only with SharePoint 2010 sites. You cannot create workspaces
that are tied to SharePoint 2007 sites.
Your ability to work with
SharePoint content isn’t limited to just the times you are online and
connected. Behind the scenes, SPW uses the Office Documents Cache (ODC)
to track changes you make while working offline. Once you eventually go
back online and have access to the SharePoint sites associated with your
changes, SPW performs bidirectional synchronization to ensure that both
the SPW client ODC and the SharePoint sites are up-to-date with the
latest changes, updates, and additions.
SPW isn’t a complete
replacement for browser-based access to SharePoint sites, though. SPW’s
ability to work with lists and libraries is tied to the content types
that those lists and libraries implement. Lists and libraries that are
based on some content types, such as the publishing content types,
surveys, and events (calendars), for example, are clearly identified by
SPW as content that the application cannot handle.
Administrative Concerns
SPW
is the evolution of the Groove client, but to many users the product is
new in the SharePoint 2010 landscape. Once end users learn about it and
figure out how easily it works, you can expect adoption to grow
quickly—something that didn’t really happen with Groove. SPW’s offline
capabilities are compelling, and its ability to effectively replicate an
entire SharePoint site from the server to a workstation is undoubtedly
going to go a long way toward reassuring users that they are in control
of their data.
These new capabilities afford
end users a great deal of much-needed functionality, but there are some
administrative aspects that you should understand.
Limiting the Use of SharePoint Workspace
Upon learning about SPW and how
it works, the first question uttered by many administrators is “how do I
turn it off?” This is a good question; by default, SPW can connect to
every new site that is created within SharePoint 2010 for purposes of
establishing a client-side workspace.
Disabling SPW support
(and offline client support in general) can be accomplished at two
different levels. The approach you take is driven by whether you need to
lock out an entire site or just portions of it.
Site.
Preventing SPW and other offline client access to an entire SharePoint
site involves changing the Offline Client Availability setting for the
site to No. This setting is available on the Search and Offline
Availability page that is available under the list of Site
Administration links for a selected SharePoint site.
List or Document Library.
You can block the offline availability of a specific list or document
library through the Offline Client Availability setting on the list’s or
library’s Advanced Settings page. By default, the option is set to Yes
to enable access to the list or library by SPW and other offline
clients. Changing the option to No blocks offline client access for the
list or library only; the rest of the site remains unaffected.
Caution
Changes that
are made through each of the aforementioned settings take effect
immediately. Changing the offline availability settings for a site or
list/library that an end user already has a workspace for doesn’t sever
connections between SPW and the site and its lists/libraries, though. In
fact, end users can continue to operate with a fair level of
functionality. Operations become somewhat unpredictable, though,
particularly when SPW launches another application (such as Microsoft
Word) for editing. As a matter of policy, you should strive to set the
offline policy for your sites and lists/libraries before end users begin
using them. Changing them after the fact is seldom accomplished
cleanly.
Configuration Items and Concerns
To
support the operation of SPW, Microsoft actually created and
implemented a new file synchronization specification called the “File
Synchronization via SOAP over HTTP Protocol Specification,” or
MS-FSSHTTP. MS-FSSHTTP is a Web service-based protocol that allows for
the efficient transfer and synchronization of files between two
endpoints. The protocol supports a number of attractive capabilities in
the offline editing of documents that are housed in Share-Point, such as
incremental file synchronization, coauthoring of documents, and
multiuser editing without synchronization/conflict concerns.
By and large, SPW’s ability
to take files offline and synchronize them with a SharePoint site is one
of those things that simply “just works” from an administrator’s
perspective. Strictly speaking, there isn’t really anything extra or
special that you need to do to ensure that SPW can be employed by your
end user base. That doesn’t mean that you won’t benefit from some
additional insight, though.
First,
Microsoft recommends that you enable the Remote Differential Compression
(RDC) feature on Windows servers where offline clients are connecting.
Although clients that employ the MS-FSSHTTP protocol for connections to
the SharePoint environment support incremental file transfers and other
benefits already mentioned, other offline clients such as older versions
of Microsoft Office do not. RDC complements MS-FSSHTP and enables the
efficient upload and download of incremental file changes on these other
offline client types. Without RDC enabled, the upload and download of
an entire file is needed when an older client type is performing an
incremental change only.
RDC is not enabled by default on
Windows Server 2008, and it isn’t enabled by the SharePoint 2010
prerequisites installer. You must manually enable the RDC server feature
from either the command line or using the Windows Server Add Features
Wizard.
Offline Operations and Security
Another area you should be
concerned about when allowing SPW usage is security. As an
administrator, you need to address two specific areas:
Transport layer security.
By default, communications between SPW and the SharePoint environment
take place through the URL endpoint that end users supply when setting
up an SPW workspace on their workstations. If the URL that is supplied
doesn’t map to an endpoint that supports some form of transport layer
security such as Secure Socket Layer (SSL) encryption, end users are
going to be transmitting the contents of lists and libraries across the wire
in unencrypted form. This really is no different from other forms of
access to the SharePoint site through the endpoint specified, but the
sheer volume of file traffic that occurs with SPW warrants this special
mention.
Client storage security.
SPW uses the ODC for offline SharePoint list and library storage.
Although SPW is capable of encrypting some Groove-related data,
SharePoint file and nonfile data is not encrypted on end user
workstations. This means that the contents of each SharePoint workspace
(that is, the lists and libraries that are within the associated
Share-Point site) reside on end user workstations in unencrypted form.
The contents of these offline files aren’t human readable, but the fact
that they aren’t encrypted won’t stop someone determined to read them.
If data protection is a concern, you must employ a secondary form of
encryption (such as Windows BitLocker drive encryption).
Synchronizing Large Numbers of Documents
Although SharePoint
synchronization with SPW simply works in the majority of cases, you need
to be aware of a couple of thresholds when working with large numbers
of client-side documents that are tied to SharePoint sites through
workspaces.
The first threshold is hit
when SPW attempts to synchronize approximately 500 or more documents
between SharePoint sites and all client-side workspaces. When this
threshold is hit, you are warned that you need to free up some space on
your workstation. You can safely ignore this warning, but increasing the
number of offline SharePoint documents yields increased synchronization
overhead that may result in a degraded experience and poorer
performance.
A more dramatic threshold
is hit when the total number of offline documents across all workspaces
exceeds 1800. At this point, SharePoint Workspace switches from regular
synchronization of all document content and metadata to regular
synchronization of document metadata only. Any time a document is
targeted for action or modification, the document content is
synchronized on demand to ensure that you have a valid copy. This
on-demand content synchronization behavior allows SPW to limit what
would otherwise be excessive overhead and performance degradation.
Bringing SPW back to a point
that is below the document thresholds mentioned is as simple as
discarding local SharePoint documents, deleting unused SharePoint
workspaces, and disconnecting from unused or unneeded document
libraries. As a general rule of thumb, the fewer the number of offline
documents you have on your workstation, the better your performance will
be with SPW synchronization.
