Office 365 SharePoint Online – Architectural Considerations

Brought to you by and the SharePoint Zone

Introduction

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:

• Capabilities
• Workloads
• Authentication
• Permissions
• 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.

Capabilities

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.

Functional Limitations

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.

Storage Limitations

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

• The 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 gigabytes (GB)

Customization Limitations

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.

Workloads

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.

Sites

Within the workload ‘sites’, intranet sites, team sites, extranet sites, and public facing websites are covered.

Intranet Sites

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

Team Sites

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.

Considerations

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 authenticate
• Limited changes possible in public facing web sites
• No line-of-business (LOB) data access with intranets

Communities

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 another solution.

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.

Considerations

In summary, the aforementioned limitations are outlined below:

• Connections to MySites to SharePoint 2010 on-premise environment
• Size Limit (500 MB)
• Customizability for MySites is limited
• User Profile Store cannot be connected to other data sources

Content

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.

Considerations

In summary, the aforementioned limitations are outlined below:

• 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
• Word Automation features not available
• Auditing does not capture which documents are opened and closed

Search

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.

Considerations

In summary, the aforementioned limitations are outlined below:

• 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

‘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.

Considerations

In summary, the aforementioned limitations are outlined below:

• Business Intelligence Center, SharePoint PowerPivot, PerformancePoint Services and integration with a reporting server not supported
• Access to LOB data not supported

Composites

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 custom workflow.

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.

Considerations

In summary, the aforementioned limitations are outlined below:

• 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

Authentication

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.

External Users

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 USD1.79.

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 time.

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.

Permissions

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 Synchronization.

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 environments.

Security Model

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.

Information Architecture

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.

Latency and Bandwidth

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.

Workloads

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 solutions.

Chronological Move

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 projects online.

Legal

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.

Records Management

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.

Out-of-the-Box Approaches

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.

Manual Upload

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 content: Approach	Scope	Things to Watch
Windows Explorer view via WebDAV	SharePoint Library	Speed of transmission Loss of metadata
Use SharePoint UI to Upload Multiple Documents	SharePoint Library	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
SharePoint Workspace Connection	SharePoint Sub Site	Limits on number of items supported by Workspace