avepoint and amazon web services: sharepoint in …...if you choose the public cloud, do you go with...

1

AvePoint confidential. This document cannot be distributed in any form without prior expressed written consent from AvePoint Inc.

AvePoint & Amazon Web Services: SharePoint in AWS

Randy Williams Enterprise Trainer and Evangelist

Published: October 15, 2012

2

AvePoint confidential. This document cannot be distributed in any form without prior

expressed written consent from AvePoint Inc.

Table of Contents

Introduction .................................................................................................................................................. 4

About AvePoint ............................................................................................................................................. 5

Hosting Options ............................................................................................................................................ 5

IaaS ............................................................................................................................................................ 7

PaaS ........................................................................................................................................................... 8

SaaS ........................................................................................................................................................... 9

Cloud Computing Benefits ............................................................................................................................ 9

Introducing AWS ........................................................................................................................................... 9

Amazon Elastic Compute Cloud (EC2) ..................................................................................................... 11

Amazon Elastic Block Storage (EBS) ........................................................................................................ 12

Amazon Simple Storage Service (S3) ...................................................................................................... 13

Amazon Virtual Private Cloud (VPC) ....................................................................................................... 13

Why consider running a SharePoint Farm in AWS? ................................................................................ 14

AWS & DocAve: Better Together ................................................................................................................ 16

Preserve and Protect SharePoint Content .............................................................................................. 17

High Availability ...................................................................................................................................... 17

DocAve Backup and Restore .......................................................................................................... 17

DocAve Replicator .......................................................................................................................... 18

Flexible Storage ....................................................................................................................................... 18

Real-Time Storage Manager .......................................................................................................... 20

Scheduled Storage Manager .......................................................................................................... 20

DocAve Archiver ............................................................................................................................. 21

Optimize Global Deployments ................................................................................................................ 21

Simplify and Automate Administrative Tasks ......................................................................................... 22

DocAve Administrator .................................................................................................................... 23

DocAve Content Manager .............................................................................................................. 23

DocAve Deployment Manager ....................................................................................................... 24

Improve Hybrid Experience .................................................................................................................... 24

DocAve Connector ......................................................................................................................... 25

Enforce Governance Policies................................................................................................................... 25

3


Governance Automation ................................................................................................................ 26

AWS & DocAve: Reference Architecture .................................................................................................... 27

Farm configuration overview .................................................................................................................. 27

New Jersey on-premises farm........................................................................................................ 27

AWS Hosted Farm (US East region) ............................................................................................... 28

AWS Hosted Farm (EU region) ....................................................................................................... 29

Test Cases ................................................................................................................................................ 29

Use Case 1: Externalize BLOBs to S3 .............................................................................................. 30

Use Case 2: Backup and Restore/Disaster Recovery ..................................................................... 31

Use Case 3: Move and restructure content across farms .............................................................. 32

Use Case 4: Cross-farm replication ................................................................................................ 32

Use Case 5: Enterprise search ........................................................................................................ 33

Use Case 6: Connect on-premises file servers to AWS-hosted farm ............................................. 33

Use Case 7: Centrally administer farms from a single interface .................................................... 34

Architecture Diagram .............................................................................................................................. 34

Conclusion ............................................................................................................................................... 35

4



Introduction Choosing a hosting strategy for your organization’s SharePoint farm is not a trivial decision. Of course, you always have the option of the traditional on-premises model where hardware runs in your data center. But maybe it’s time to think about an “all-in” move into one of the well-known private or public clouds? If you choose the public cloud, do you go with a multi-tenant option using shared servers such as Microsoft Office 365 SharePoint Online, or do you need the flexibility of a more dedicated, private-cloud-like model with Amazon AWS (Amazon Web Services)? Do you hedge your bets and opt for one of the hybrid configurations that allow you to move to the cloud at your own pace?

It seems that the maturity and ubiquity of SharePoint has presented myriad options, not unlike when you need to choose a color of paint from your local hardware store. Wouldn’t it be easier if there were just a few colors from which to choose? And when choosing a hosting strategy, do you wonder if that choice paints you into a corner where you lose the flexibility of running custom applications or buying essential third-party components? Indeed, this choice is far from trivial.

In this whitepaper, we review the basic hosting concepts such as Infrastructure as a Service (Iaas), Platform as a Service (PaaS), and Software as a Service (SaaS) as well as discuss who manages which component within these three offerings. To further establish context, we review the significant advantages when working with the cloud in comparison to an on-premises environment. We cover many of the unique advantages that an AWS-hosted service offers you and make sure you are clear with some of its main components such as EC2, S3 and EBS. This paper then introduces AWS Virtual Private Cloud (VPC) as a way of extending your on-premises infrastructure such as Active Directory into your personal Amazon private cloud.

Once the AWS foundation is set, the paper transitions into its primary goal, which is to educate and illustrate how the AvePoint DocAve Software Platform can integrate, manage, optimize, protect your SharePoint investments – whether these are hosted on-premises, in your AWS private cloud, or a hybrid state. In this process, this paper provides a reference architecture that represents a common hybrid scenario where an organization has both on-premises and cloud-hosted SharePoint farms. We then discuss how DocAve helps you address and close the gaps found in many of today’s modern and complex SharePoint architectures. These discussions center around a number of use cases that represent real-world challenges that organizations face today, including:

• Needing to backup and restore content in between on-premise to a cloud-hosted farms • Using Remote Blob Storage (RBS) to reduce storage costs and increase SharePoint’s overall

performance • Moving, coping and restructuring of SharePoint content within and between on-premise and

cloud-hosted farms • Solving the global collaboration riddle by providing real-time and scheduled replication of

content in between and across global farms • Integrating on-premise infrastructure such as legacy file servers within cloud-hosted SharePoint

farms.

5


About AvePoint AvePoint is a global technology company and proven software leader. Since its founding in 2001, AvePoint has become the world’s largest provider of enterprise-class governance and infrastructure management solutions for Microsoft SharePoint. Propelled by the world’s largest SharePoint-exclusive research & development team, AvePoint helps more than 10,000 customers – including many Fortune 500 companies and government agencies – meet their specific business objectives utilizing the SharePoint platform. AvePoint, Inc. is headquartered and maintains its principal operational center in Jersey City, NJ, with wholly owned operational centers in the USA, Canada, Australia, South Africa, United Kingdom, France, Germany, Netherlands, Switzerland, Japan, Singapore, and China. AvePoint is a Depth Managed Microsoft Gold Certified Portals and Collaboration Partner and Gold Certified ISV Partner as well as a US Government GSA provider via strategic partnerships.

6



Hosting Options

When moving to the cloud, you locate servers, storage, and other hardware assets outside of your data center and physical office premises. For the better part of the last decade, it was common to buy the hardware as a capital expense and simply lease space within a shared data center. With rampant growth in virtualization technologies and the economy of scale that comes with buying equipment in bulk, it is much more typical now to lease virtual machines rather invest in physical hardware. Consequently, this paper will focus on the latter approach since it is the dominant approach today and expected to remain so into the future. Whether you are ready for a move of this type or not, make no mistake, this is the future of server computing. Competition among providers is fierce, and providers have been investing billions of US dollars building the infrastructure around the globe in anticipation of this eventual transition.

To understand the various offerings and their intrinsic advantages and disadvantages, it helps to have a basic understanding of the hosting options that are made available. In general, these fall into three main categories, Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). These three are shown in Figure 1. While the SaaS model is the most recognized, don’t assume that means it is the one you should probably be using. Understanding the actual service provided for each is essential to accurately comprehending what the provider’s responsibility is versus the client’s with regard to day-to-day management and support.

Figure 1: Service options

Let’s take a little time to examine these services to understand the individual service layers. This helps us see the similarities and differences among them. Figure 2 illustrates the layers broken out starting with the hardware at the bottom and going up to the application at the top. (Note: those with a networking background should recognize the concept here as it is very similar to the Open Systems Interconnection [OSI] model used when studying network communications.) On the left is the service layer and on the right is the extension of this to a SharePoint environment. Note these layers do not necessarily match up one-for-one as the services on the left are intended to be generic across multiple platforms.

7


Figure 2: Service layers

IaaS With IaaS, the infrastructure layer is outsourced to the cloud provider. This generally corresponds to the bottom four layers as shown in Figure 3. In basic terms, the provider is providing you with your own virtual machines (VM). The provider manages the underlying physical hardware and the hardware configuration settings for the VM; the client manages the software, including the operating system (OS) and all applications. This option gives you the most flexibility in hosting whatever application solution regardless of the software platform. Effectively, it’s your OS in the cloud. The primary drawback is that it requires skilled labor to install, configure and handle all the day-to-day management of the OS and software. Amazon Web Services and Windows Azure are based on this model, and thus, is the model on which this whitepaper is based.

Figure 3: Infrastructure as a service

8



PaaS

With PaaS, the cloud provider manages not just the hardware and the VM, they also handle the OS and typically middleware/runtime components—for example, .NET or Java EE. This is shown in Figure 4. The client is responsible for deploying and maintaining the application code and the data it consumes. With PaaS, the client doesn’t need to worry about specific VMs and only needs to focus on the application. Issues such as OS updates, scalability, elasticity (growing and shrinking the service on demand), and hardware failure are handled behind the scenes by the provider.

Figure 4: Platform as a service

SaaS

With SaaS, the provider effectively owns and manages the service stack from the application layer down to the hardware. This is shown in Figure 5. Typically the software layer is a commonly used application. The client’s only task is to use the application and possibly perform light administrative duties such as assigning permissions. The SaaS model has grown quite common as of late, and we all consume software of one form or another this way. Facebook, Salesforce, Google Docs, Hotmail, and Office 365 (including SharePoint Online), are all examples of SaaS offerings. With these applications, all upgrades and most of the common technical support issues are handled by the provider. The key advantage to this model is it allows a business to focus on its core competencies by outsourcing much of its IT infrastructure.

Figure 5: Software as a service

9


Cloud Computing Benifits

At a high level, perhaps the greatest benefit of cloud computing is the notion of managed services. With this model, you shift resources away from inefficient tasks to higher-value activities in your organization. This in turn allows the IT organization to focus its efforts on delivering new, more innovative solutions for the business and less on counterproductive, reactive tasks to help support the infrastructure. Figure 6 summarizes many of the tangible benefits.

Figure 6: Cloud Computing Benefits

Centralizing computing and storage resources in the cloud allows organizations to utilize its assets to their fullest potential. On average, most on-premise systems are well underutilized, and this becomes especially true when factoring in redundant hardware needed for disaster recovery. With cloud computing, hardware resources are pooled and shared across a wide number of systems, applications and customers, and you only pay for what you use.

Scalability and elasticity (growing and shrinking demand) are other key benefits. Whether your solution targets just a few users or thousands, the cloud can accommodate your needs. If your business experiences seasonal peak periods, additional resources can quickly be added or removed to meet current demand. This degree of flexibility and turnaround is just not possible with on-premises models. For organizations, it often takes weeks or months for additional hardware to be approved, ordered, delivered, installed, configured, and tested.

While billing does vary by provider and whether the service is IaaS, PaaS, or SaaS, most go with a user-count or usage-based model. Virtually all use a monthly billing cycle which reduces the up-front capital expense of deployment or scaling out. AWS uses a pay-as-you-go model and the majority of costs are determined by features and usage such as storage, network traffic, request counts, and server hours.1 As a related benefit, the cloud uses a more eco-friendly operating model. Whether your organization’s

1 To estimate monthly costs with AWS, use the online calculator: http://aws.amazon.com/calculator

http://aws.amazon.com/calculator

10



motive is to reduce its carbon footprint or reduce hard costs such as electricity or real estate, cloud computing pools these costs and distributes them across many systems and users. This economy of scale reduces the individual price.

In general, the security procedures and protocols in place at cloud providers are stricter and more disciplined than compared to on-premises data centers. Building access is carefully controlled and monitored. Encryption technologies for data in transit and at rest are almost usually superior. Cloud engineers are highly trained and must undergo rigorous background checks. Routine audits are done to ensure standards are enforced. While occasional security breaches have and will continue to occur, the overall security risk with a mature cloud provider is much lower compared to an on-premises data center. For most, the concern here is more of a perceived risk than an actual one.

The National Institute of Standards and Technology (NIST) have published a document titled “Guidelines on Security and Privacy in Public Cloud Computing”2 . The key recommendations from this paper make good sense and include the following:

• Understand the environment offered by the cloud provider and carefully plan the security and privacy aspects of cloud computing solutions before implementing them

• Ensure that a cloud computing solution—both cloud resources and cloud-based applications—satisfy organizational security and privacy requirements

• Maintain accountability over the privacy and security of data and applications implemented and deployed in public cloud computing environments

2 NIST Special Publication 800-144, available from http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909494

http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909494

11


Introducing AWS

Through its many products and services, AWS provides customers with an IaaS computing solution. This design provides the most flexibility in terms of control over the OS and its applications, but does require the organization to handle the architecture, deployment and day-to-day management tasks related to SharePoint. Nonetheless, it’s much easier than the on-premises model when it comes to installation and scaling. Furthermore, there are numerous advantages AWS hosting offers that are not possible with traditional, on-premises deployments. In Figure 7 below, we introduce the AWS computing platform:

Figure 7: Amazon Web Services computing platform

Circled above are the four areas that are most relevant to us in this paper. We’ll quickly introduce them so you have a basic understand of what these services are:

Amazon Elastic Compute Cloud (EC2)

At the heart of AWS is the Amazon Elastic Compute Cloud (Amazon EC2) web service, a cloud computing infrastructure that supports a variety of operating systems and machine configurations (e.g. CPU, RAM). Think of EC2 as being the virtual machine in the cloud. Fortunately, you don’t have to start with an empty image as AWS provides preconfigured VM images (Amazon Machine Images, or AMIs) with guest operating systems (Linux®, Windows, etc.) and may have additional software (like SQL Server) that are preinstalled in the base image. These AMIs are starting points to instantiate and install or configure additional software, data, and more, allowing you to create your own application- or workload-specific AMIs. SharePoint Server 2010 is not pre-installed due to licensing reasons, and this is covered in more detail in the “Why consider running a SharePoint Farm in AWS” section; however, SharePoint Foundation 2010 is available.

12



To implement the various roles in a SharePoint farm (i.e. web front end [WFE], application server or database server), start with an AMI that is based on Windows Server 2008 R2. Some AMIs include components like Microsoft Internet Information Services (IIS) for the web tier roles; others include SQL Server Standard (for the database tier). When choosing the specific ones, look at the pre-installed software running to determine which is applicable for a SharePoint WFE/application server or a SQL database server. At this time, several AMIs support a number of versions of Windows Server and a Windows Server 2012 AMI is expected in the Q4 2012 timeframe. For more on the options and pricing, see http://aws.amazon.com/windows/.

EC2 web servers can also be load balanced, something that is necessary if you use multiple WFE servers. Amazon refers to this as Elastic Load Balancing and you can read more from http://aws.amazon.com/elasticloadbalancing/. For SQL Server high availability, AWS supports both synchronous and asynchronous mirroring with or without a witness server, provided the servers are within different availability zones in the same region (availability zones and regions are introduced in the next section).3

Amazon Elastic Block Storage (EBS)

Amazon Elastic Block Store (EBS) provides block level storage volumes for use with Amazon EC2 VM instances. Think of an EBS volume as like a Logical Unit Number (LUN) that is available from a storage area network (SAN). EBS is the recommended approach when creating your data and log partitions to be used for your SQL Server VMs. EBS volumes can be created from 1GB to 1TB in size. Once attached, it will appear as a mounted device similar to any local hard drive or LUN. At that point, the VM can interact with the volume just as it would with a local drive, formatting it with an NTFS file system, for example.

EBS solutions are network-attached and can persist independently from a VM. When choosing EBS, you can specify which type of volume based on the performance needs you have. AWS provides standard volumes that deliver on average 100 IOPS (Input Operations per Second)4 and high-performance volumes called Provisioned IOPS volumes that yield 1000 IOPS. These volumes can also be striped together (e.g. RAID 0) to yield even faster performance if needed. In terms of reliability, volumes are also replicated to other data centers in the same availability zone5. This protects from the loss because of any single component failure. For pricing or other information on EBS, see http://aws.amazon.com/ebs/.

3 To learn more about AWS-based high availability options for SQL Server, see http://bit.ly/oTm1HH. 4 Microsoft’s supported limit for storage performance in SharePoint depends on the size of the content database stored. The minimum recommended speed is 0.25 IOPS/GB. Thus, a dedicated standard volume that yields 100 IOPS can effectively store a content database up to 400GB in size. For more details, see http://slidesha.re/t1xnxD. 5 Availability Zones are distinct locations within a region that are engineered to be isolated from failures in other Availability Zones and provide inexpensive, low latency network connectivity to other Availability Zones in the same Region. To learn more about regions and availability zones, see http://bit.ly/TiXgdC.

http://aws.amazon.com/windows/

http://aws.amazon.com/elasticloadbalancing/

http://aws.amazon.com/ebs/

http://bit.ly/oTm1HH

http://slidesha.re/t1xnxD

http://bit.ly/TiXgdC

13


Amazon Simple Storage Service (S3)

S3 is your file system in the cloud. Through its published API (application programming interface), you can create, read, modify, and delete any file object containing any content and in virtually any size needed. You probably know that SharePoint stores all of its content (e.g. list items, metadata, document in libraries) within content databases stored inside SQL Server. If SharePoint’s files are placed inside a database already, what advantage does a file system in the cloud offer? The answer to that is Remote Blob Storage, or RBS. With RBS, you are able to externalize a subset of SharePoint’s files into an external store.

There are two primary advantages in wanting to externalize these files. One is to save on storage costs. EBS provides fast and very reliable storage, but these benefits come at a cost. Considering both storage and request pricing, S3 usually works out to be much cheaper. The other advantage is performance. By externalizing content outside the content database, you are able to reduce the load on SQL Server for all open and save file requests; this in turn, then makes your SQL Server more responsive to all other requests that come in.

Not every RBS provider is able to externalize files to S3. For this to work, the provider must be written in a way that S3 read and write activities are able to be redirected to the S3 API. AvePoint’s DocAve Storage Manager is S3 compatible and we will cover this in the Externalize BLOBs to S3 section of this whitepaper. You can also use RBS with Amazon Elastic Block Storage as well. To learn more about S3 and pricing, see http://aws.amazon.com/s3. To learn more about using RBS with SharePoint see the whitepaper titled “Optimize SharePoint Storage with BLOB Externalization” available at http://www.avepoint.com/assets/pdf/sharepoint_whitepapers/ Optimize_SharePoint_Storage_with_BLOB_Externalization.pdf.

Amazon Virtual Private Cloud (VPC)

Amazon’s VPC becomes your bridge to enable your on-premises infrastructure to integrate with your VMs running in the cloud. Effectively, it is what facilitates hybrid scenarios where you have some SharePoint workloads running on-premises and others separated out into the cloud. For example, you may wish to move My Sites and Extranet collaboration into an AWS-hosted farm, whereas internally you have business intelligence, enterprise search, and other workloads running in your on-premises farm.

Amazon Virtual Private Cloud (Amazon VPC) lets you create a private, isolated network in AWS where you can define VM servers in a virtual network that you define. This network topology closely resembles a traditional network that you might operate in your own data center. For example, you have control over settings such as IP address ranges, subnets, and configuration of route tables and network gateways. In terms of bridging this network to your on-premises environment, you can create a secure and encrypted hardware- or software-based virtual private network (VPN) connection between these two networks. The net result is your AWS resources become an extension of your on-premises data center. This is depicted in the Figure 8, and we will discuss how this VPC works in the AWS & DocAve Reference Architecture section.

http://aws.amazon.com/s3

http://www.avepoint.com/assets/pdf/sharepoint_whitepapers/Optimize_SharePoint_Storage_with_BLOB_Externalization.pdf


14



Figure 8: Extending your data center into AWS

Technical Note: SharePoint farms are not designed to span across data centers. In other words, servers within a farm should be co-located within the data center or within geographically close data centers that have at least 1 gbps connectivity and less than 1 millisecond ping latency6. Due to this, it is neither supported nor advised to have a single farm stretch across on-premise and AWS-hosted data centers. In Figure 8, the design assumes that the on-premises data center has a separate farm from the ones hosted in AWS.

Why consider running a SharePoint Farm in AWS?

Aside from the obvious cloud computing benefits shared earlier, there are some distinct advantages to running SharePoint in AWS. One is that it allows you to locate the farm in a region that is geographically close to your users, ensuring that you can provide the best performance. AWS currently has seven global regions available: US East (N. Virginia), US West (California and Oregon), EU (Ireland), Asia Pacific (Singapore and Tokyo), and South America (Sao Paulo).

Another very practical use for a SharePoint farm hosted in AWS is for development and testing activities. For a production environment, it is absolutely essential to have a test environment where changes can be made prior to being made in production. This is commonly used for cumulative update or service pack testing, testing SharePoint Designer customizations, or any other change that may impact users. On

6 See http://technet.microsoft.com/en-us/library/cc748824.aspx for more details.

http://technet.microsoft.com/en-us/library/cc748824.aspx

15


a related note, when applying patches of this sort, it’s common do to so by applying them to a group of servers that you pull out of a load balancer. In other words, you do not need to schedule downtime for all patch operations. By easily adding and removing new EC2 servers, you can help ensure that you maximize your service uptime.

Speaking of development activities, the fact that you have full control over the VMs gives you freedom to run full-trust custom applications, whether these were internally developed or by a third party. There are no restrictions and no outside validation process that you need to go through. If you expect to be developing sandboxed or full-trust solutions on top of your SharePoint farm, it is strongly recommended to also have a development environment where integration and basic validation testing can be done. Since you only pay when your servers are running and actively receiving request, you can power down these servers when not in use.

With both SharePoint and SQL Server, you can apply your on-premises licensing model to EC2 hosted servers. This is called license mobility and is available to Microsoft volume licensed customers with eligible server applications covered by active software assurance contracts. To learn more, see http://aws.amazon.com/windows/mslicensemobility/.

Running SharePoint in AWS looks and feels the same as running it on-premises, just without the numerous on-premises challenges. It’s the same SharePoint experience for administrators and end users, including full SharePoint enterprise license features, plus Active Directory, SQL Server and the familiar IT environment in terms of networking, security, etc. Figure 9 provides a visual depiction of how all these pieces come together when provisioning an AWS-hosted farm:

Figure 9: SharePoint Reference Architecture on AWS

http://aws.amazon.com/windows/mslicensemobility/

16



For more details on running SharePoint on AWS, see the whitepaper titled “Microsoft SharePoint Server on AWS: Reference Architecture” available from http://aws.amazon.com/windows/sharepoint/whitepaper/

AWS & DocAve: Better Together

AvePoint’s DocAve software platform is the industry’s only enterprise-class management platform for SharePoint governance. Covering a wide range of features, DocAve delivers across six primary areas of need: migrate, integrate, manage, optimize, protect, and report. DocAve simplifies the deployment, monitoring, and enforcement of Microsoft SharePoint 2010 governance policies. As a fully integrated platform, DocAve enables centralized or delegated management of SharePoint farms hosted on-premise, or in hosted clouds such as AWS. With DocAve, you can manage development, test, and production farms with ease as well as govern solution and component deployment with DocAve's application lifecycle management tools. The various products are introduced in Figure 10:

Figure 10:Introducing DocAve

The latest release of DocAve, version 6, has an intuitive, ribbon-based user interface that is built entirely on supported Microsoft technologies and APIs. DocAve comes with its own API and PowerShell cmdlets, allowing administrators and developers to customize, automate, and extend DocAve’s platform of technology. DocAve 6 is the culmination of AvePoint's decade of experience helping more than 10,000 customers in 63 countries realize SharePoint success. To learn more about the benefits and features that DocAve offers, please see http://www.avepoint.com/docave6.

Within the context of AWS, DocAve is fully compatible and supported running on top of any on-premises and/or AWS-hosted farm. In the following sections, we introduce many of the benefits of running DocAve to give you better control over all your SharePoint farms, whether they are on-premises, hosted in AWS, or both.

http://aws.amazon.com/windows/sharepoint/whitepaper/

http://www.avepoint.com/docave6

17


Preserve and Protect SharePoint Content

Amazon’s EC2 VMs and EBS storage provide a robust hardware infrastructure but these will not help you in the event of SharePoint content failure. While SharePoint’s built-in backup and recovery system provides one level of protection for sites and their content, there are still a number of limitations. Here are a few common use cases where DocAve Backup and Restore can provide full-fidelity7 restore capabilities:

• Item-level restore beyond recycle bin aging period (30 days, by default), due to document loss, or document corruption

• Using InstaMount8 to quickly restore content with very tight recovery time objectives9 • Granular backup that is 100% RBS aware, allowing externalized BLOBs to be restored properly • Out-of-place restore, allowing you to easily restore an item or container of content (library, site,

etc.) into a different area of SharePoint, while maintaining content fidelity

In addition, you can centralize backups on-premises or in the cloud. By storing all backups in AWS S3, for example, you no longer need to store tapes offsite. Cloud-based backups can be applied to either AWS-hosted or on-premises farms, and this benefit is expanded upon more in the next section on high availability. To learn more about disaster recovery concepts, see the magazine article titled, “Mature SharePoint Disaster Recovery” available at http://bit.ly/yuw1qw. To learn more about DocAve Backup and Restore, see http://www.avepoint.com/sharepoint-backup-and-restore-docave/.

High Availability

AWS provides a great number of high availability features, ensuring that you can maximize your uptime and reach your business continuity goals, but what if your primary farm is currently in an on-premises data center?

Achieving high availability at the 99.9%10 or higher level for an on-premises SharePoint farm is quite complex, expensive and labor extensive. In all likelihood, you’ll need a redundant, secondary farm in an off-site data center, and for most small-to-medium-sized businesses, this is cost prohibitive. However, AWS and DocAve have a cost-effective solution: AWS hosts this secondary farm and DocAve keeps it in a warm standby state so that you can quickly failover to it if needed. There are two products that DocAve uses together to offer this capability. Let’s look at each one to understand its purpose.

DocAve Backup and Restore

As mentioned in the previous section on protecting SharePoint, this builds on the idea that on-premises backups are stored in AWS, possibly in S3. The purpose of DocAve Backup and Restore is to provide a full

7 By full fidelity, we mean recovering content and all associated metadata, timestamps, permissions and workflow state. Unless you recover from the recycle bin, or perform a full content database or site collection restore, SharePoint does not provide full-fidelity when restoring content. 8 http://www.docave.com/TeamBlog/Lists/Posts/Post.aspx?ID=26 9 http://en.wikipedia.org/wiki/Recovery_time_objective 10 99.9% of downtime translates to about 9 hours of downtime per year

http://bit.ly/yuw1qw

http://www.avepoint.com/sharepoint-backup-and-restore-docave/

18



platform-level sync of the primary and secondary farms. Once a full backup completes, the backup set is applied to the AWS-hosted secondary farm. Since DocAve provides a platform backup and recovery option, configuration settings such as web.config changes, IIS changes, global assembly cache files, SharePoint root contents (i.e. 14 folder) and farm settings can be applied to the secondary farm, meaning that no manual steps are needed to keep the farm’s configuration consistent. In addition to farm configuration, all content and service application databases are also synched during this restore. The frequency of a full restore will depend on how often farm configuration or service application configuration changes. For example, if you regularly add new terms into a Managed Metadata Service term store, you’ll want to run this more often.

DocAve Replicator

Once platform recovery has the base platforms in sync, Replicator is used to keep the content and configuration within site collections up to date. This sync operation is done one way from the primary on-premises farm to the secondary farm and will likely be scheduled to run on an hourly or daily frequency. When replicating, Replicator is able to detect and just replicate byte-level differences within files, reducing the bandwidth needed. Optional compression and throttling-control enables control over bandwidth usage throughout the day. If needed, you can also configure real-time replication based on triggers to reduce the latency between the two environments. Figure 11 below depicts how Backup and Restore and Replicator together keep the secondary farm in a warm standby state. To learn more about DocAve Replicator, see http://www.avepoint.com/sharepoint-replication-docave-v6/.

Figure 21:Keeping DR environment in warm standby state

Flexible Storage

It’s well-known that SharePoint stores all content, including documents, in content databases. As content databases grow, so does the underlying storage. With content databases being stored on the highest quality storage, managing spiraling storage costs becomes a new challenge. With AWS, you have the option of storing content databases on either native EC2 storage or EBS volumes as described earlier in this paper. For simple workloads where content is of uniform type, size, and age, this design is

http://www.avepoint.com/sharepoint-replication-docave-v6/

19


sufficient. However, as existing workloads evolve and new workloads are added, these storage options become expensive and too limiting. For example, a paperless initiative requires you to back-scan content that may total terabytes. This content should be placed in a low-cost document archive but still be completely accessible to SharePoint for search or to enforce records management policies (e.g. legal holds, disposition).

RBS was developed by Microsoft to facilitate these kinds of uses. The idea behind RBS is that you store certain documents (these are the BLOBs or Binary Large Objects) outside the content database, almost always into more affordable storage. While the document may be stored outside the database, its metadata, permissions, and other details are kept inside. From a SharePoint point of view, since RBS is handled at a low level (RBS is technically a database API) this change is completely transparent to users and to SharePoint itself. Figure 12 shown here illustrates how RBS works when uploading a document into SharePoint:

Figure 32:How RBS externalizes a document on upload

When using RBS, the primary goal (and gain) is cost savings. However, there can also be an unexpected performance boost to externalizing these BLOBs as well. The primary reason is that you are reducing the load on the SQL Servers which is the most-common bottleneck found within SharePoint environments. By having web-front end servers directly access the BLOB store for reading and writing these documents, SQL server is able to better focus on other functions such as reading and writing structured content (metadata, permissions, site structure, etc.).

There is a notable drawback to RBS that needs to be mentioned to keep this discussion balanced. By externalizing BLOBs, you introduce a new challenge in terms of backup and restore since you now have two content areas to worry about: the content database and the BLOB store. With RBS, the content database uses pointers to reference the external BLOBs and these pointers must be kept in sync. While this sounds difficult, it doesn't need to be. To learn more about how to manage recovery with RBS, see the magazine article “Mature SharePoint Disaster Recovery” available from http://bit.ly/yuw1qw. To learn more about RBS, see the whitepaper titled “Optimize SharePoint Storage with BLOB Externalization” at http://www.avepoint.com/assets/pdf/sharepoint_whitepapers/ Optimize_SharePoint_Storage_with_BLOB_Externalization.pdf.

http://bit.ly/yuw1qw



20



Now that you have an understanding of how RBS works, let’s apply this to AWS. By using S3 storage instead of the more costly EBS, you are able to reduce overall storage costs. Furthermore, for scenarios like document archive where these documents do not change, we don’t need to back up the BLOB store with the same frequency as the database. This reduces the time and storage needed for backup operations.

In order to use S3 storage as a BLOB store, you need a specially written RBS provider like what AvePoint offers within DocAve Storage Manager. In fact, Storage Manager can help you achieve a design that provides a full hierarchical storage management solution where you have multiple levels (or tiers) or storage and as content ages, it is moved from higher to lower tiers of storage. Storage Manager is able to do this as it provides externalization in two different ways. Let’s quickly look at each.

Real-Time Storage Manager

Real-time resembles what you see in Figure 12. That is, upon upload the file is externalized to a designated BLOB store. This is the simplest form, and there is just a single rule that you have when deciding what documents get externalized: the document’s size. This should make sense, as it is the larger files you want to remove from the database. While the magic size threshold varies, most agree that around 1MB is a good starting size. Anything larger than 1MB is externalized and anything smaller is kept inside the content database.

Scheduled Storage Manager

Scheduled Storage Manager is much more intelligent. The idea is that you can develop many more rules on determining which content gets externalized. For example, you may want to archive documents that haven’t been modified within the last 12 months. Or, you may want to archive just older versions of a document (say, any major and minor version 3 and higher). Other rules include content type, file type, metadata, size, and where it’s stored (e.g. folder, library, site).

Putting this all together, we are able to achieve a very intelligent storage design where you can be very precise about which documents are located where. As shown in Figure 13 below, you may choose to put business critical content in high-performance EBS volumes, whereas low transaction document archives are stored in S3.

Figure 43:Flexible storage architecture

21


To learn more about Storage Manager, see http://www.avepoint.com/sharepoint-storage-manager-docave/.

DocAve Archiver

When it comes to creating new or uploading existing content into SharePoint, it’s easy for users. Archiving or deleting stale content is much harder. Both, however, are necessary to enforce retention policies, maintain manageable content databases sizes, and overall promote a healthy content-lifecycle process. Out of the box, SharePoint 2010 lets you delete or archive items by using retention-based information management policies11. You can also delete unused site collections by using SharePoint’s Site Use Confirmation and Automatic Deletion12, but these capabilities are quite limited.

We just described how Storage Manager enables you to use RBS to archive files but still keep them connected to SharePoint. DocAve Archiver takes it one step further by removing content from SharePoint. Effectively, it takes a backup of this content and removes it from the content database. The unit that is archived can be anything from a site collection down to a document version, and any container in between. Rules are used to determine what gets archived, so you can selectively include or exclude as needed. The archived content is encrypted and compressed and can be stored in affordable S3 storage or on-premises if you prefer. While archived content is no longer accessible directly from SharePoint, it can still be indexed and exposed through a federated search. If content is needed, it can also be restored either in place (to the same location it was archived) or the documents can be restored to a file share (e.g. in the event SharePoint is no longer in use). To learn more about DocAve Archiver, see http://www.avepoint.com/sharepoint-archiving-docave/.

Figure 54:Flexible storage architecture

Optimize Global Deployments

More and more, the industry is seeing SharePoint customers that have a global presence and need to keep their SharePoint content locally accessible where possible. For example, let’s introduce a representative company, Acme. Acme has regional offices in the US, Europe and Asia. Since SharePoint farms are not designed to be stretched across the globe, each office has their own SharePoint farm. If each office were completely autonomous, it would be easy as collaboration and other workloads could be kept to the local office. However, most are not autonomous. Acme, in particular, has a strategic initiative called “One Acme” that is intended to bring the company under one umbrella with one set of standards and governance policies, and they rely heavily on SharePoint for enterprise search and document collaboration to be a unified company. 11 http://technet.microsoft.com/en-us/library/cc262490.aspx 12 http://technet.microsoft.com/en-us/library/cc262420.aspx

http://www.avepoint.com/sharepoint-storage-manager-docave/

http://www.avepoint.com/sharepoint-storage-manager-docave/

http://www.avepoint.com/sharepoint-archiving-docave/



22



Acme’s goal is to maintain region-specific copies of content so that documents can be quickly opened. So, when the Hong Kong team opens up a large document that was created in New York, they are opening a local copy rather than waiting for it to download it over the WAN. In order to achieve this requirement, replication must be used to store copies of content in each regional farm. Unfortunately, the closest built-in feature that SharePoint has is called content deployment13, but it is designed for publishing web pages and is inadequate for a complex scenario like Acme’s.

We introduced DocAve Replicator in the Preserve and Protect SharePoint Content section, and here is another common use case for it. With Replicator, we can create granular rules when designating which content is replicated to other farms. For example, we can be very broad and replicate everything within a site collection or be much more specific and choose just a few libraries or folders. Replicator is also smart enough to detect conflicts when two people try to modify the same file at approximately the same time.14

Since Amazon supports SharePoint farms that can be hosted in 7 different regions (3 in US, 1 in Europe, 2 in Asia, 1 in South America), most of the globe is covered. Furthermore, when replicating between each of the farms, compression and intelligent byte-level difference is used to minimize bandwidth. A diagram of how this looks is shown in Figure 15.

Figure 65:Optimizing global deployments

Simplify and Automate Administrative Tasks

With SharePoint’s power and flexibility it brings businesses, it is far from a maintenance-free solution. There are administration tasks that occur at the farm level, server level, content database level, site

13 http://technet.microsoft.com/en-us/library/ee721058.aspx 14 To avoid the frequency of this, it is advised to design information architecture patterns in a way so that regions are authoritative owners of content and when changes are made, only the master is changed. This said, we acknowledge this is easier said than done.

http://technet.microsoft.com/en-us/library/ee721058.aspx

23


collection level, and web site level as well as even the list, library, item and item-version levels. In other words, there are settings in a number of locations—maybe too many locations. Furthermore, since SharePoint consists of a number of dependent technologies such as Windows, IIS, SQL Server, Active Directory, DNS, load-balancers, firewalls, and ASP.NET, many administrative and troubleshooting tasks are very complex and require a number of multi-disciplinary support experts.

With all this complexity, there is a significant total cost of ownership to keep it configured properly and running smoothly. To reduce this support burden, AvePoint has released a number of products that help increase operational efficiency and ensure governance policies you have can be properly enforced. Let’s quickly introduce a few of them and cover some common ways they can be used:

DocAve Administrator

With Administrator, there is a single graphical interface that can be used to administer all aspects of SharePoint in all locations. So, you can connect to any farm and perform administrative functions that have been granted to you. A farm administrator on multiple farms, for example, can perform both Central Administration-like and Site setting-like tasks across multiple farms from a single interface. Having just one interface means you can apply settings across multiple locations in one step, and this applies all the way from the farm down to items in lists and libraries.

Common use cases are to manage features, security settings (including permissions), even clone or transfer permissions from one use to another, which is very difficult to do manually. You can also search and report on settings. For example, you may want to find all sites to which particular user or group has access. With Administrator, your management control includes both on-premises and AWS-hosted farms, simplifying hybrid scenarios as shown in Figure 16. To learn more about DocAve Administrator, see http://www.avepoint.com/sharepoint-administration-docave-v6/.

Figure 76:Using DocAve Administrator to manage on-premises and AWS-hosted farms

DocAve Content Manager

Content Manager is used for real-time, point-and-click restructuring of SharePoint content. This content can be moved or copied across any boundary—including separate farms whether on-premises or hosted in AWS—provided both are the same SharePoint version. This content and topology restructuring is done easily and accurately from a single, Silverlight-based browser app while maintaining all content, configuration, security, and metadata—in other words, full fidelity. Content Manager comes in very handy if you need to move a site or library to another location (either within or across site collections).

http://www.avepoint.com/sharepoint-administration-docave-v6/

24



Sometimes a large site collection needs to be carved up into multiple ones, and this is another common use case for Content Manager. You can also promote and demote sites within a site collection (i.e. move sites up and down the site hierarchy). When copying or moving sites across a site collection boundary, content dependencies such as permissions including SharePoint groups, content types, and site columns can be recreated in the destination site collection to ensure the data context is fully preserved. To learn more about DocAve Content Manager, see http://www.avepoint.com/sharepoint-content-management-docave/.

DocAve Deployment Manager

Deployment Manager can be used to deploy farm and site collection-specific assets. This is commonly used in branding scenarios where master pages, CSS, JavaScript and image files need to be propagated consistently to multiple site collections. In addition, it can be used to also deploy site columns, content types, site and list templates enforcing a consistent taxonomy and information architecture across a number of site collections. For situations where custom code needs to be propagated across development, test/QA and production environments, Deployment Manager can also help with solution package management and deployment as shown in Figure 17. To learn more about DocAve Deployment Manager, see http://www.avepoint.com/sharepoint-deployment-management-docave/.

Figure 87: Application lifecycle management for custom SharePoint code

Improve Hybrid Experience

Making a move to the cloud is never a one-time leap. It is done incrementally, usually starting with low-risk workloads. Even if your primary SharePoint environments are fully running in the cloud, they will be detached from on-premises infrastructure such as Active Directory domain controllers, file servers, and line-of-business applications that may have hooks into SharePoint. With the Amazon’s Virtual Private Cloud (VPC), these systems can still integrate with each other.

In many of the previous sections, we have covered situations where DocAve solutions can help improve this hybrid state where part of your infrastructure is in the cloud and part is still on-premises. As a review, DocAve Backup and Restore can centrally backup your entire SharePoint infrastructure whether it’s hosted within AWS or on-premises. DocAve Administrator lets you administer all of your farms from one centralized location, and DocAve Content Manager lets you move and copy content in between each of your environments, regardless of location. There is one additional and quite powerful solution to keeping AWS-hosted farms in close contact with on-premises systems. For that, we’ll introduce DocAve Connector.

http://www.avepoint.com/sharepoint-content-management-docave/

http://www.avepoint.com/sharepoint-content-management-docave/

http://www.avepoint.com/sharepoint-deployment-management-docave/

25


DocAve Connector

Connector is a unique product that lets you expose regular Windows-based file shares within SharePoint, without migrating those files into libraries. Using Connector, you “connect” a document library to a file share using the UNC syntax (i.e. \\fileserver\share). Connector creates all of the folders in the same hierarchy and creates file entries, capturing relevant metadata from the files and storing in SharePoint. Instead of storing the BLOB data in SharePoint, the file is kept in the file system by using a form of RBS. This design opens up a number of very useful possibilities, including:

• Making documents HTTP accessible, rather than requiring network file share access—a great convenience for remote or mobile-device users who may not have VPN connectivity

• Increasing user adoption by requiring users to go through SharePoint to access content • Providing all the SharePoint document management capabilities such as check-in/check-out,

versioning, metadata, and workflow while avoiding the migration challenge • Reducing storage costs by keeping documents on file servers and NAS devices, extending the life

of these devices while keeping content databases trim

Let’s take this Connector solution and apply it to a real-world hybrid scenario. Imagine your SharePoint farm is hosted in AWS, but you have a number of legacy file servers that are kept on-premises. Using Connector, you can expose any or all of this file share data through connected libraries in SharePoint. You’ve now centralized access through SharePoint, and when a file is opened, it is opened by a WFE server going through the VPC network tunnel. In other words, the user does not connect to the file share—the server does on the user’s behalf. When the file is saved, it is written back to the file share, either overwriting the existing file or creating a new one if versioning is turned on in the library. Most importantly, users do not need to know or be concerned about where the file is actually stored. To them, it appears as though it is a normal SharePoint document. To learn more about DocAve Connector, see http://www.avepoint.com/sharepoint-sharepoint-connector-docave/.

Enforce Governance Policies

As you move to the AWS cloud, in whole or in part, there is still an important need to have a governance strategy and be able to enforce key elements within it. The purpose of governance is to provide guidance and standards that define how a system should be used. It is usually comprised of four key elements: people, process, policy, and technology. When developing governance plans for SharePoint, there are a number of areas that must be considered. Some of these include:

• Identifying content owners and determining content for which they are accountable • Providing rules and restrictions around content sharing • Defining what type of content is appropriate • Providing answers to important questions such as

o How and when do I create a new website? o How do I find/publish/protect/preserve/expire/recover content o Where do I store this type of content? o How do I apply metadata to classify this document?

http://www.avepoint.com/sharepoint-sharepoint-connector-docave/

26



Governance is a big subject and well beyond the scope of this paper. For further guidance on developing and implementing a governance plan, see http://www.avepoint.com/assets/pdf/sharepoint_whitepapers/KMWorld_Governance_White_Paper.pdf .

For some organizations, compliance is an important factor and AvePoint has a suite of products that enables organizations to automate access and controls for their SharePoint deployments in order to not only mitigate the likelihood of a catastrophic incident, but also help establish a comprehensive risk management program. Some of these we have introduced at various points in this paper, but here is a recap and some new benefits that AvePoint Compliance Solutions provide:

• Prevent content leaks and misuse by applying SharePoint permissions, tagging, and security settings

• Assign policy access rights and permissions to content stored in file shares • Detect offensive content with real-time scans and scheduled risk reports • Search for user permissions with security search or profile security permissions for individual

users or groups • Track user activity with user lifecycle reports • Monitor content lifecycle with item lifecycle reports • Respond to and resolve breaches by archiving and encrypting all SharePoint content • Implement and manage legal holds on discrete SharePoint content on-demand • Quickly restructure permissions, access metadata, and security of content itself

Governance Automation Further extending the governance control, AvePoint has developed a product named Governance Automation. Governance Automation enables automated, end-to-end SharePoint service and information management. Through the creation of service requests that support rich, customizable approval processes and comprehensive reporting, organizations can define, implement, and enforce SharePoint governance policies while closing the custom code gap created by home-grown solutions. For example, business users can request a new site collection and after it is approved, it is automatically created based on the settings that are defined in a set of governance policies.

Governance Automation sits on top of DocAve and communicates with DocAve APIs as shown in Figure 18:

http://www.avepoint.com/assets/pdf/sharepoint_whitepapers/KMWorld_Governance_White_Paper.pdf

http://www.avepoint.com/assets/pdf/sharepoint_whitepapers/KMWorld_Governance_White_Paper.pdf

27


Figure 98: Architecture of Governance Automation

Just as with DocAve, Governance Automation is fully compatible and supported with farms running in AWS, on-premises or both. To learn more about Governance Automation, see http://www.avepoint.com/sharepoint-governance-automation/.

AWS & DocAve: Reference Architecture In this section, we would like to provide you with a reference architecture based on a real-world proof of concept that was recently conducted between Amazon and AvePoint. In this implementation, we created multiple SharePoint farms to mimic a typical hybrid design for a global organization. In this case, the company already had an on-premises farm hosted within its data center in Jersey City, New Jersey. Two new AWS-hosted farms were added. One was stored in the US-East region (physically located in Virginia), and the other is stored in the Europe region (physically located in Ireland). At a high-level resembled Figure 19:

Figure 109: SharePoint Farms

Note: To see a detailed configuration diagram of these farms and the WAN configuration, please see Figure 31 in the Architecture Diagram section.

While developing this proof of concept, we outlined five specific goals we hoped to accomplish:

(1) Reduce storage costs (2) Support both content and disaster recovery scenarios within and in between farms (3) Restructure and replicate content in between farms (4) Support common hybrid scenarios (5) Centralize the administration of all farms

Farm configuration overview

New Jersey on-premises farm

Let's first introduce the on-premises infrastructure. In the data center, a single Active Directory domain controller, AveNADC exists within a domain called AveHQNA.com. This server also provides DNS functions for this domain. This farm consists of three-servers:

http://www.avepoint.com/sharepoint-governance-automation/

28



• The WFE server is AveNASPWFE and is running SharePoint 2010 Server with SP1 • The application server is named AveNAAPP • The SQL Server is running the 2008 R2 version and is named AveNASQL

Figure 20: New Jersey on-premises farm

The DocAve agent runs on both the WFE and application servers. Also on the application server, a Windows file share has been created and a number of MS Office files have been added to it. (Note: this is not a production environment best practice but reduces the hardware needed for this proof of concept.) In addition, a Juniper SSG5 Secure Services Gateway15 is used to provide a VPC connection between this on-premises data center and the AWS hosted farms.16 This ensures all in-transit traffic is encrypted.

AWS Hosted Farm (US East region)

In the US-hosted AWS farm, four servers are used. One is a separate domain controller, AWSNADC, which exists in a domain called AWSNA.com. A two-way Windows trust relationship has been established between the AWSNA.com and AveHQNA.com domains. This is to facilitate two-way sharing of content. This server also provides DNS functions for this domain. This farm contains three servers:

• The WFE server is AWSNAMGRWFE and is running SharePoint 2010 Server with SP1 • The application server is named AWSNAAPP • The SQL Server is running the 2008 R2 version and is named AWSNASQL

15 http://www.juniper.net/us/en/products-services/security/ssg-series/ssg5/ 16 To learn more about how to create a software or hardware based VPN connection with Amazon VPC, see http://aws.amazon.com/vpc/faqs/#C6

http://www.juniper.net/us/en/products-services/security/ssg-series/ssg5/

http://aws.amazon.com/vpc/faqs/#C6

29


Figure 21: AWS farm (United States)

Also running on the WFE is the DocAve Manager, which means this is the centralized DocAve Management server for all three farms. (Note: multiple manager servers can be used to increase performance and fault tolerance, but was not incorporated into this design.) The DocAve agent is running on both the WFE and application server.

AWS Hosted Farm (EU region)

In the EU-hosted AWS farm, just two servers are used as this is a small satellite office. One is a separate domain controller, AWSEMEADC, and exists in a domain called AWSEMEA.com. This server also provides DNS functions for this domain. This farm contains just a single server running all SharePoint roles. The server is named AWSEMEAAIO and this server is also running the DocAve agent.

Figure 22: AWS farm (Europe)

Test Cases

Within this proof of concept, we configured and ran through seven different test cases, many of which are typical use cases that are introduced within this whitepaper. The two-fold purpose of these tests is to successfully achieve the goals outlined and, at the same time, validate our assumptions on how this hybrid design works.

30



Use Case 1: Externalize BLOBs to S3

Goal: (1) Reduce storage costs

This use case demonstrates how DocAve Storage Manager can be used to store large files outside the content database. We used the Simple Storage Service (S3) as our BLOB store. In our tests, we were able to successfully configure Storage Manager in real-time to externalize newly uploaded files larger than 1MB. A DocAve physical device was created to store these BLOBs in S3 as shown in Figure 23 here:

Figure 23: Real-time Storage Manager rule

Additionally, we tested Scheduled Storage Manager to externalize all .docx files that were less than 1MB, and this correctly externalized 253 files – which is the correct number. The results of this job are shown here in Figure 24:

Figure 24: Scheduled Storage Manager job results

While no formal performance comparisons were done, similar tests done with on-premises farms has demonstrated a small but noticeable performance benefit for SQL Server and, hence, SharePoint when externalizing BLOBs.

31


Use Case 2: Backup and Restore/Disaster Recovery Goal: (2) Support both content and disaster recovery scenarios within and in between farms

The purpose is to demonstrate that we can backup from one farm and restore in another, a relevant story for organizations that cannot afford the redundant hardware that is often required for a separate disaster recovery (DR) center. In this case, the DR center is hosted in AWS. During our tests, we were able to successfully backup and restore a site collection from the on-premises farm and restore to the AWS-hosted US farm. We also restored individual libraries and items in separate restore tests. Since the configuration and use of DocAve with AWS-hosted farms is identical to the experience with on-premises farms, we are confident that platform recovery capabilities will support disaster recovery needs. The out-of-place restore of an individual library is shown in Figures 25 and 26:

Figure 25: Selecting the library from the source, on-premises farm

Figure 26: Out-of-place restore to a site in the AWS US farm.

32



Use Case 3: Move and restructure content across farms

Goal: (3) Restructure and replicate content in between farms

This use case proves how DocAve Content Manager can be used to restructure and reorganize content across farms. This is very relevant as organizations slowly transition from on-premises farms to the cloud. For example, we separately copied a document library and a whole site collection from the on-premises farm to the AWS US-hosted farm while retaining full context of the data (e.g. permissions, metadata). We also “promoted” a sub-site from the on-premises HQ farm to a new site collection in the AWS US farm. The interface for copying the document library is shown in Figure 27:

Figure 27: Using Content Manager to copy a document library across farms

Use Case 4: Cross-farm replication

Goal: (3) Restructure and replicate content in between farms

This use case demonstrates the need to keep site collections in sync across two globally distributed farms. This is an important use case for organizations that want to provide locally accessible content, which can significantly increase SharePoint performance while reducing bandwidth. For our tests, we configured a site collection in the AWS-hosted US farm and successfully replicated changes to the Europe farm. To start, a full replication job was submitted to establish a one-time full sync. From there, we only ran incremental replication where just the changes sent. Some specific test cases involved creating, updating, and deleting files; creating metadata columns; breaking inheritance and changing item permissions; and creating sub sites. The one-time configuration of Replicator with the source and destination site collections is shown in Figure 28:

33


Figure 28: Configuring Replicator

Use Case 5: Enterprise search

Goal: (4) Support common hybrid scenarios

In this use case, we configured a content source in the AWS-hosted US farm that pointed to a file share in the on-premises farm. This was done within an enterprise search service application. We then issued a full crawl. Upon completion, we tested a number of different search combinations to confirm that the content from the on-premises file server was returned correctly in the search results page. All tests were done using the search service application and the enterprise search center site template that is built into SharePoint Server 2010. The results of the search test are shown in Figure 29:

Figure 29: Enterprise search results

Use Case 6: Connect on-premises file servers to AWS-hosted farm

Goal: (4) Support common hybrid scenarios

34



For this use case, we used DocAve Connector to expose on-premises files within a file server from inside the AWS-hosted US farm. This connection and population of the library with files and folders from the file share worked flawlessly. With this design in place, users are now able to consume content within on-premises file shares directly from an AWS-hosted SharePoint farm. This is a very powerful feature, especially since all SharePoint document library capabilities such as versioning, check-in/check-out, permissions, and auditing are fully functional despite having the files physically stored on the file server. The end-user experience after this library is connected is shown in Figure 30. (Note that it looks and functions like a typical document library.)

Figure 30: Connecting content from an on-premises file share

Use Case 7: Centrally administer farms from a single interface

Goal: (5) Centralize administration of all farms

For this use case, our goal is to confirm that we are able to successfully administer all three SharePoint farms from a single DocAve interface. This was confirmed after successfully running through all of the above use cases. When working within DocAve Administrator, you first select the object or objects that you want to administer and the ribbon will automatically adapt to reflect the actions that you have. For example, if you select multiple web applications, you can make recycle bin changes to all selected web applications in one step. Or, if you select multiple site collections, you can adjust the quota template that you want all these site collections to use. Having a single centralized interface to search and apply configuration changes across the board is a powerful way to enforce governance policies in a consistent way across all farms, whether these are on-premises or hosted in an AWS cloud.

Architecture Diagram

The three-farm environment that was used for all of these test cases is diagramed here in Figure 31.

35


Figure 31: AWS and DocAve Reference Architecture

Conclusion

Over the course of this in-depth whitepaper, we have hopefully made a strong argument for the value and flexibility that an AWS-hosted SharePoint farm running DocAve combination delivers. We have covered a number of common challenges in managing a cloud-based farm, but as we’ve seen each of these can be overcome. We’ve also seen how the DocAve platform of solutions helps you integrate, manage, optimize, and protect your SharePoint investments whether these are hosted on-premises, in your AWS private , or a hybrid combination. We have also introduced a series of real test cases and a reference architecture proving our assertions when you work with farms, regardless of where they are hosted.

If you would like more information about AvePoint’s products or services, please visit our website at http://www.avepoint.com. To learn more about Microsoft technologies running in AWS, see http://www.awsmicrosite.com/.

http://www.avepoint.com/

http://www.awsmicrosite.com/

avepoint and amazon web services: sharepoint in …...if you choose the public cloud, do you go with...

Documents