and the SharePoint Zone
Microsoft first introduced a cloud offering focused on
business customers with the Business Productivity Online Suite (BPOS) in 2009,
which consisted of Exchange 2007, SharePoint 2007, Office Communicator 2007 and
Live Meeting 2007. In June 2011, Microsoft released the next iteration of its
cloud offering for customers: Microsoft Office 365. Office 365 has upgraded
these products to Exchange 2010, SharePoint 2010, Office Web Apps, and Lync
2010. Microsoft also announced plans to add Windows Intune and CRM Online. This
is a compelling set of cloud-based applications, compared with industry
competitors such as Google.
Office 365 has two major offerings: ‘Standard’ (S) and
‘Dedicated’ (D). The Standard offering has two major plans: the ‘P Plan’,
targeted at ‘professionals and small businesses’, and ‘E Plan’ targeted at
‘midsize businesses and enterprise’. Shortly, a third plan will be added and
will be called the education plan.
The Dedicated offering is targeted at enterprises that wish
to not be hosted on a multi-tenant environment, and take advantage of more
flexibility with deployments such as farm based solution packages and support
third-party vendor add-ons. Please note that Microsoft only offers the
Dedicated offering to customers with more than 20,000 users.
Perhaps the greatest threat to adoption of Office 365 is not
competitors, but rather reluctance of organizations to move data and
applications from on-premise servers and clients to Microsoft’s cloud.
This white paper discusses technical strategies for
leveraging this new service within your organization. The goal of this white
paper is to clarify strategies for incorporating Office 365 in your enterprise
IT portfolio and address the technical considerations for migrating to Office
365. When considering an activation of SharePoint Online as part of your
SharePoint strategy, the main architectural decisions which need to be made
should focus on the following areas:
- Creation of a cohesive end user experience
- Information Architecture
- On-boarding and Off-boarding of data
- System Requirements
- Architectural Approaches
Over the next sections we
will dive into all of these subjects.
SharePoint Online is a true multi-tenant system, and although
it has been designed in this manner, not all capabilities perform well in
multi-tenancy environments. When creating a roadmap for a SharePoint Online
environment –or migrating an on-premise environment to online –the following
limitations must be kept in mind.
Microsoft decided to exclude certain functionality from
SharePoint Online at the time of launch in June 2011. In short, the most
important capabilities missing in SharePoint Online are:
- Business Data Connectivity Services
- FAST Search
- Advanced Search Configuration
- Record Center
- Word Automation Services
- Business Intelligence Center
- Performance Point Services
- Secure Store Service
- Web Analytics
- Locally installing custom software
- Advanced public facing web sites
An exact list of all capabilities missing from the SharePoint
online offering is listed in the current Service Description. Over the upcoming
service releases, scheduled every 90 days, Microsoft will begin introduce some
of the aforementioned features.
SharePoint Online is bound to specific limits in number of
users (20,000) as well as storage. These limits are also described in the
Service Descriptions. Some of the highlights include: 5
maximum size of a SharePoint tenant is 5 terabytes (TB)
- A SharePoint Tennant can maximally hold 300 site
collections (excl. My Sites)
- Each site collection has a storage quota of 100
In SharePoint 2010, a new customization option was released
called sandboxed solutions. Sandboxed solutions are the only form of custom
coding supported by SharePoint Online. Sandboxed solutions are very similar to
the existing farm solutions (sometimes called full trust solutions), but with a
few major limitations:
- Deployment at site collection level –
Sandboxed solutions can only be deployed at a site collection level scope. In
SharePoint Online, within Site Settings, there is a mechanism to upload
sandboxed solution packages to the Solution Gallery and activate them.
- Resources measured – Any managed code, within
an assembly, referenced by artifacts deployed in a sandboxed solution, are
executed in a separate worker process to standard full trust solution managed
code. These worker processes are actually monitored for the resources they
consume via different categories (e.g. number of exceptions thrown and CPU
cycles) and stored in resource counters which are reset daily. If one of the
resource counter categories for a sandboxed solution reaches its daily quota,
sandboxed solutions are disabled within that site collection. This is a very
important concept to understand as it does not just affect the offending
sandboxed solution. Unlike the on-premises version of SharePoint 2010, these
quotas cannot be changed.
- Limited Server Object Model – Security
precautions as well as multi-tenant restrictions dictate that the server object
model available to managed code in sandboxed solutions is limited and enforced
by the fact it is running in a separate worker process. There are some
signification classes and methods that are not available and will subsequently
limit the level of customizations available on the server side.
A general pattern in the industry has already been to
leverage client side code (ECMAScript) and the client object model or
Silverlight to bypass some of the limitations.
Due to the limitations in capabilities, some workloads are
suited better for SharePoint Online than other workloads. Creating a Business
Intelligence center or public facing website in SharePoint Online, for
instance, is limited to very specific functionality, this will be discussed
below. Therefore, these workloads would be better in an on-premise environment.
We’ll address the
workloads according to the “SharePoint Pie” at the beginning of Page 6.
Within the workload ‘sites’, intranet sites, team sites,
extranet sites, and public facing websites are covered.
When implementing SharePoint Online as an Intranet
environment, all basic functionality is provided. Users can communicate
information about the organization and leverage publishing workflows that are
available to manage approval of content before it is visible to all business
users. Most Intranet Sites, however, also show specific information to a user
that is derived from other systems like SQL Server Databases and SAP
environments. This functionality is in most cases provided via Business
Connectivity Services (BCS), which connects to line-of-business systems and the
Secure Store (for setting permissions and passing through authentication
tokens). These two functions are currently unavailable, which means the
Intranet will have to do without user specific information from these services.
If needed, a Silverlight app could be created that retrieves information
through web services. However, this is more costly and time consuming than the
build in BCS. 7
SharePoint Online is perfect for hosting Team Sites. Team
Site functionality is largely the same in comparison to a local SharePoint
environment. Team Sites are used to enable groups of people to share
information and work together regarding a specific subject.
Public Facing Websites
The public facing websites offered by SharePoint Online are a
very limited subset of the on-premise equivalent. For example, users are
restricted in what changes they can make to the site. According to
documentation, SharePoint Designer cannot be used to customize the site
although this works in reality. The public facing website functionality is
perfect for smaller organizations that need simple web presence, but in reality
is not an option for most medium-to-large organizations.
For organizations looking to utilize sites functionality
using SharePoint Online, be sure to determine if you can still meet the needs
of your business with the following impairments in functionality (as related to
on-premises versions of SharePoint 2010):
- Vanity URLs
- User Permissions for External Users
- External users require a Windows Live ID to
- Limited changes possible in public facing web sites
- No line-of-business (LOB) data access with intranets
The workload ‘communities’ is used to describe MySite
functionality, Blogs, Wikis, and content tagging. All these functionalities are
provided by SharePoint Online. In reality, most organizations will not use
SharePoint Online solely for this workload and will likely integrate it into
SharePoint Online is a perfect host for MySites. These
MySites, however, do lack functionality in comparison to MySites in a
SharePoint 2010 on-premise environment. A SharePoint Online MySite, for
instance, cannot exceed 500 megabytes (MB), custom solutions are not supported,
the site collection root site template cannot be changed, administrators cannot
manage the site collections though the management option, and User Profile
information cannot be enhanced with information from external Data Sources
apart from the information synchronized with Office 365 Directory Services.
In summary, the aforementioned limitations are outlined
- Connections to MySites to SharePoint 2010 on-premise
- Size Limit (500 MB)
- Customizability for MySites is limited
- User Profile Store cannot be connected to other data
Many SharePoint environments are used to store vast amounts
of documents. SharePoint’s search and metadata features enhance the document
experience, which can in turn tremendously enhance the end user experience.
Because almost all ECM-related functionality of a SharePoint
on-premise environment is available online, a document management solution can
easily be created in SharePoint Online. There are, however, some limitations
which should be considered such as storage limit per site collection and maximum
storage per tenant.
Next to technical limitations from a SharePoint Online
perspective, one should also take latency, legal requirements regarding
specific documents, and storage costs into consideration. Because SharePoint
Online is accessed through the web, opening and closing many documents might
result in a poor user experience. Specific information within an organization
could have legal considerations which should be examined before putting it in
an external system. SharePoint Online comes with 10 GB of storage per tenant
and 500 MB of shared storage per user. If more storage is needed, it can be
purchased currently for USD$2.50 per GB, per month (this differs in each
region). When dealing with large amounts of data, this could grow costly.
In summary, the aforementioned limitations are outlined
- Size limit of a site collection (100 GB), number of
site collections (300) and maximum storage in a tenant (5 TB).
- Record Center capabilities not offered
- Mail Enabled Document Libraries are not supported,
impacting Scanners & Scanner software
- PDF documents cannot be opened in the browser
Automation features not available
- Auditing does not capture which documents are opened
Creating a great search experience for end users is as
important as creating an easy-to-understand site structure. SharePoint Online
supports searches across all online site collections, including My Sites and
User profile information. Creating a search experience which integrates a
SharePoint Online and a SharePoint on-premise deployment, however, is not
supported. Indexing other content sources from SharePoint Online is also
unsupported because the Search Service Application in SharePoint Online has a
limited configurable feature set.
Organizations that want to provide a ‘federated’ search
experience from other sources such as on-premise SharePoint instances, file
shares will not be able to. The solution is to use the on-premise farm for
search, and crawl content sources in that on-premise environment. It is not
recommended to crawl the Office 365 SharePoint 2010 site collections from
on-premise environments without considering the bandwidth considerations, as it
could be costly and negatively impact end user traffic.
In summary, the aforementioned limitations are outlined
- FAST Search not supported
- Search configuration very limited
- Crawling content source every hour to refresh index
- Custom IFilters not supported (PDF is the only
external IFilter supported)
- Indexing of multiple sources not supported
- Federated Search
- Search Integration with Windows 7
‘Insights’ is the workload in which all Business Intelligence
features are described. SharePoint Online doesn’t support the Business
Intelligence Center, SharePoint PowerPivot, PerformancePoint Services and
integration with a reporting server.
There are still several options left for creating compelling
Business Intelligence Solutions in SharePoint Online. These options, however,
are limited to creating data visualization solutions based on list 10 information, and Excel
sheets, but also integrating and visualizing Visio drawings.
In summary, the aforementioned limitations are outlined
- Business Intelligence Center, SharePoint PowerPivot,
PerformancePoint Services and integration with a reporting server not supported
- Access to LOB data not supported
One of the most powerful aspects of SharePoint is the ability
for end users to create their own business process solutions. These solutions
can automate entire business processes or be implemented to support specific tasks.
SharePoint Online supports all end user customizability options that are
supported using the browser. For example, you can create custom lists, connect
and enforce list relationships with lookup columns, create pages and add web
parts to them.
In addition, power users and business analysts can use
SharePoint Designer to create mashup-like business solutions. For example,
SharePoint Online supports Data View Web Parts, customizing the XSLT of list
view web parts, customizing form pages (e.g. NewForm.aspx), and even creating
The most powerful of solutions can be created by SharePoint
developers. These solutions are built using Visual Studio and uploaded in the
SharePoint Online environment. SharePoint Online does not support all custom
solutions. Full-trust solutions are not supported. Only Sandboxed Solutions, or
browser-centric applications based on technologies such as Silverlight, jQuery
and Client Object Model can be used.
In summary, the aforementioned limitations are outlined
- More sophisticated workflow systems, including K2,
Nintex, and Global360, are not supported
- Integration with LOB data is not supported
- Only Sandboxed Solutions are supported, fully
trusted code is not
Microsoft offers three kinds of authentication mechanisms
with SharePoint Online:
- Microsoft Online IDs
- Single Sign On with AD credentials through ADFS
- Microsoft Windows Live IDs for External Users
Microsoft Online IDs
Microsoft Online IDs are the simplest Authentication
Mechanism for Office 365. Essentially, Microsoft Online IDs are comparable with
Windows Live IDs. Users are created online either by hand, through a script, or
via Directory Synchronization. A Microsoft Online specific user ID and password
is required to login. Because this User ID and Password is different from the
local Active Directory users might get confused.
Using Microsoft Online IDs in most cases speed up deployment
of Office 365 because on-premises, except for a Directory Synchronization
Server, no implementation is necessary.
Single Sign On through ADFS
The best end user experience and best IT administrator
control experience is created when Active Directory Federation Services (ADFS)
is used to grant users access to Office 365. Users can utilize their active
Windows Active Directory username and password to login to SharePoint Online.
The other main benefit is that Active Directory security groups can be used to
grant users permissions within SharePoint Online.
In order to use ADFS for authentication multiple ADFS servers
need to be implemented in the on-premises IT infrastructure. Also, the Active
Directory needs to be synchronized with the Microsoft Online Directory. These
are two main options for implementing ADFS:
- ADFS servers behind the firewall: this only allows
users to access SharePoint Online when on the corporate network
- Implementing ADFS Federation Servers in the DMZ:
this allows usage both internally and externally.
Although usage of ADFS is a huge functionality enhancement,
it needs to be implemented with care. If Active Directory Servers are not
available, users cannot sign into SharePoint Online / Office 365.
When collaborating with external users, Microsoft provides a
feature in SharePoint Online which allows SharePoint Online administrators to
invite these users from the SharePoint Online interface (from within a specific
Site Collection). External Users can then use a Windows Live ID (ending with hotmail.com
or live.com only) or Microsoft Online ID from another tenant to access the
environment. Each tenant is equipped with 50 licenses for providing users
access through this method. More licenses can be purchased. Effectively, this
allows organizations to collaborate with external users through an extranet
type of functionality. The price point for adding external users is currently
Although working with this authentication method seems
compelling because in basis there are no licenses costs for less than 50 users,
and the license costs for every user above 50 is relatively cheap compared to
the on-premise SharePoint Internet Connector license, using this method adds
external users directly to a site collection. In other words, there is no centralized
way to report and control which external users have access to an environment
and, for instance, automatically revoke their access after a certain period of
Alternatively, when granting external users to a SharePoint
Online environment, these users could be created within the Active Directory in
order to give them access. Another approach is to add these users manually in
the Microsoft Online Portal and grant them permissions to each Site Collection
and allow them to sign in by using a Microsoft Online ID. Although these
methods allow a better control over external users, these external users must
be given a license in the environment.
Creating a good structure for permissions is always hard to
do. Usage of user accounts, SharePoint groups and Active Directory groups to
set permissions can be very conflicting. SharePoint Online can use a
combination of all three, much like SharePoint 2010 on-premises.
The SharePoint security model allows, with some elevated
exceptions, the granting of a permission level at the site collection root site
level; sub site level; list level; folder level; and list item level. The most
common out-of-the-box permission levels include: full control; contribute; and
read; and these can be applied directly applied to users, SharePoint groups or
Active Directory groups.
Direct User Permissions Approach
Granting permissions at such a granular level is certainly
the quickest way to give access to end users, but it does come with
limitations. Organizations experience this pain when end users change roles within an organization,
subsequently requiring SharePoint administrators to navigate through and
replace where the source user has been granted permissions with the target user
who has replaced them in that role.
SharePoint Groups Approach
Granting permissions at a SharePoint group level allows you
to define membership of created groups at the root site of the site collection.
These groups can then be used throughout the site collection bearing in mind
that if users need to be replaced, it can be done within the SharePoint groups.
A key limitation of SharePoint groups, is that they are created at the root
site of the site collection. This means with multiple site collections,
SharePoint groups will be duplicated across and require duplicate management
out of the box.
Active Directory Security Groups Approach
Active Directory security groups are created in the Active
Directory and can have Active Directory users as members. Security groups
created in Active Directory can be added to SharePoint Online and used within
the security model. This alleviates the limitation of SharePoint groups, as the
Active Directory groups can be applied across site collection security models
and membership manage in one instance.
One potential limitation of the creation of such Active
Directory groups and the subsequent membership is that the SharePoint team
often won’t have permissions to Active Directory and will require change
processes with the Active Directory team within the organization. This scenario
often leads to SharePoint administrators falling back onto SharePoint groups
for faster turnaround of membership requests.
Usage of Active Directory security groups in SharePoint
Online is only possible if ADFS is used in conjunction with Directory
A complex factor is that a user who is part of a specific
Active Directory Security group might not have a license to use SharePoint
Online. This means the user can actually have permissions to access the group
from a SharePoint Online perspective, but is denied access because of licensing
in Office 365.
Creation of a Cohesive End User Experience
When creating a SharePoint Online solution, the user should
be the main priority and targeting adoption metrics from a return on investment
perspective is a common measure of success. On creating a cohesive end user
experience, along with the workload complexities mentioned in the previous
section, the following key areas
should be addressed:
Navigation between Site Collections
Only the primary site collection is shown to the end user.
End users thus do not have any way of knowing which site collections they have
access to next to the primary site collection. There is no automated way to
show all site collections to end users. Site collections, therefore, must be
added manually to the navigational options.
Graphical User Interface
Because SharePoint Online and SharePoint Server are basically
the same product, changes in the graphical user interface can be shared between
both environments. By doing this, you ensure the same user experience for end
users. It is recommended that whatever customizations are done in the UI should
be deployed via a sandboxed solution to ensure consistency between both
As discussed in the aforementioned Permissions section, it is
important that end users have a seamless experience to access content
regardless of where it resides. Ensuring that this is consistent across
workloads and clearly communicated to the organization is essential. Many of
Office 365’s current customers choose the ADFS option and Active Directory
groups for this exact reason, because the security model is the same in both
on-premise and online environments.
When looking at incorporating SharePoint Online into your
SharePoint strategy, you should consider your information architecture. Some
content, due to its very nature, does not sit well in the cloud.
Service Level Agreements
Microsoft offers a Service Level of 99.9% percent uptime.
Next to that they have specific times set for recovery time objective (RTO) and
recovery point objective (RPO). Most organizations will perceive these Service
Levels as more than applicable for their organization. In some situations,
however, these Service Levels are not enough. Some data needs to be in a high
available farm, some require a continuous backup throughout the day made
available, and consequently RTO/RPO must be much faster than what Microsoft
offers in their Service Level Agreements.
Office 365 is a Cloud Service. Users are connected to the
service via the Internet. The end user experience is highly dependent on the
network latency and bandwidth against the SharePoint Online environment. Users
in offices with slow Internet connections or a high latency will have a poor
experience. Before migrating to SharePoint Online or considering activation of
services in SharePoint Online, you should consider measuring the connection
speed to the SharePoint Online environment.
In cases where SharePoint Online is crucial for specific
business scenarios, using offline tooling like SharePoint Workspace might
provide a solution.
SharePoint Online does not provide all feature workloads
supported in an on-premises SharePoint environment. When planning a move into
SharePoint Online, the actual workloads to be migrated should be assessed
according to these workloads. In particular, customization dependencies should
be looked after because customization is only supported with sandboxed
When moving new sites into SharePoint Online, a strategy
could be chosen in which all current sites are migrated into the cloud. Another
strategy could be to not migrate any current sites and only commence new
Some countries and organizations have legal restrictions on
where specific data can be hosted. Normally, these requirements are only
applicable for a small part of all data within an organization. Microsoft’s
Data Centers are located throughout the world and logically grouped per
continent. The European data centers, for instance, are located in Dublin and
Amsterdam. Although it is to be expected Microsoft will expand into new regions
and markets, currently there are no statements on this expansion. If data for
your organization cannot leave your region or continent, then at this time that
specific data cannot be put in Office 365.
SharePoint Online only supports In-Place Records Management.
The Record Center at this time is not supported. Organizations which have a
strong need for building solutions utilizing the Record Center should either consider
waiting with their migration until Microsoft offers the Records Center in
SharePoint Online or should consider continuing with an on-premises deployment
of SharePoint for this solution.
On-Boarding and Off-Boarding of Data
When moving to any software-as-a-service (SaaS) solution,
on-boarding and off-boarding of data should be a matter of attention. When the
Office 365 SharePoint 2010 Online instance is first provisioned, there is no
content in the default site collection. IT Administrators will need to make
some key decisions on what types of content will reside in SharePoint. For
existing content that must be migrated into SharePoint, there are multiple
approaches, each of which are covered in this section.
Microsoft provides a few native options for content
migration, such as manual upload of files, electronic or manual delivery of
existing content databases, and writing scripts to help automate the migration.
| Depending on the size of the content being moved into the
SharePoint 2010 Online instance, it may be feasible to upload it manually.
Many organizations opt to delegate this task down to individual business
units. When doing so, it is best to provide an outline of the information
architecture to ensure any governance rules and guidelines are followed. Here
are some of the manual approaches that can be used to manually upload
Explorer view via WebDAV
- Speed of
- Loss of metadata
SharePoint UI to Upload Multiple Documents
- Number of files
that can be uploaded at once is limited to the sum total of bytes than
maximum file upload (50 MB)
- Loss of metadata
- Limits on number
of items supported by Workspace