1

SharePoint 2013 on Windows Azure Infrastructure David Aiken & Dan Wesley

Version 1.0

Overview With the Virtual Machine and Virtual Networking services of Windows Azure, it is now possible to

deploy and operate a Microsoft SharePoint 2013 Server farm on Windows Azure. This document

discusses the key considerations, architecture and operations required to do this successfully. This

document assumes a basic working knowledge of SharePoint Server 2013 and familiarity with the

services offered by Windows Azure.

Article scope and SharePoint farm solution Microsoft offers and licenses two categories of SharePoint farm solutions. These solutions are in the

cloud (SharePoint Online) and on-premises (SharePoint 2013).

SharePoint 2013 uses the traditional software licensing and installation. Known as an on-premises

solution, customers can install and configure SharePoint to deploy a farm on physical computers or in a

virtual environment. Customers also have the option of deploying and operating a farm in their own

data center or on an infrastructure provided by a hosting service.

This article covers the hosted option that Microsoft provides as a public cloud solution. Windows Azure

is a cloud service that provides the infrastructure and platform services needed to host a SharePoint

2013 farm.

SharePoint Server planning and design SharePoint Server provides an extensive set of features to support a wide range of activities for an

organization. However, these features and capabilities can make planning and design a challenge,

because:

There is no generic, one size fits all farm design. Farms deployed in different organizations may

be appear similar and may have the same number of farm servers, but close examination will

show that there are key differences between any two farms. (Later in this article we describe

generic topology patterns that will help you design a farm.)

Although there are several ways to evaluate farm and server capacity requirements to make

sizing estimates, there is not a single, all-encompassing formula to generate a detailed farm

design complete with server quantities and server sizes.

The importance of SharePoint farm planning and design cannot be overstated. Inadequate planning and

as a result, poor farm design, is the main reason that SharePoint farms fail to live up to user

expectations and meet an organization’s goals and objectives for deploying SharePoint. Planning and

2

design issues also contribute to a significant number of product support calls related to capacity and

performance.

Planning Thorough and careful planning is critical to ensure that a SharePoint farm is deployed successfully and

after it is deployed, provides the expected functionality. For more information, see Plan for SharePoint

2013.

The following elements are fundamental to farm planning and design:

Functions and features – Determine the functions that you want the farm to provide, and

identify the features required to provide the functions.

Services and service applications – Determine the services and service applications that are

needed for the features that you intend to use.

Farm users – Develop a user profile to understand how, how often, and when your users will use

the farm functions that are provided.

Farm content – Farm content types (for example, documents, pictures, and videos) and volume

(number of items and size) determine database capacity requirements.

Intended use – The goal for deploying the farm or its intended use determine the level of

planning and type of design that is needed. For example, a product evaluation farm, developer

farm, and pre-production test farm have a different user base, different functional

requirements, and different sizing requirements.

The preceding aspects of farm planning are the most obvious and there are other factors that must also

be included in farm planning, such as: security, high availability, and scalability, to name a few.

Logical and physical architectures After you identify farm requirements the next step is to design the farm architecture. This architecture

describes the logical arrangement of all the components that deliver the features and services for the

farm. This logical architecture enables you to create a physical architecture, or farm topology that

identifies the elements required to implement the logical architecture. A SharePoint farm topology

identifies the number and distribution of servers that are needed and typically includes sizing

information for each of the servers. For more information, see Logical architecture planning.

SharePoint farm topology You can install and configure SharePoint on one or more servers to support the features that you intend

to provide on your SharePoint farm. For any given farm, the number of servers that are used, and the

capacity of each server varies. There are many determining factors that affect a SharePoint farm

infrastructure. For example, the functions and features that the farm provides, the number of users, and

the volume and type of content that is stored. These factors and many others must be identified and

evaluated before sizing, acquiring and provisioning servers for the farm.

A farm topology diagram uses the idea of tiers, which are just a convenient way to organize or

categorize farm servers. Tier membership is based server roles, which basically describe the features or

services that a server provides. It is important to note that:

3

Servers in a tier may host the same services or subsets of the same service. This is fairly common

in very large SharePoint farms where high availability and load balancing are design goals.

With the exception of servers in the database tier, servers in the other tiers are loosely coupled.

This means that it is relatively easy to move servers between tiers to accommodate workload

spikes or to replace a server that is failing.

The following tiers and server roles are used to describe every type of farm, such as corporate intranet

or Internet sites. (It should be noted that farm size itself is not a determining factor in deciding how

many tiers to use in a farm topology. However, three tiers are typically found in medium-large and large

SharePoint farms.)

Web or content tier

Usually referred to as front-end Web servers, the role of these servers is to respond to incoming user

content requests. These servers will either route the request to another server, or provide the content.

In most cases the servers in the Web have identical or very similar configurations to be interchangeable

and easily swapped in or swapped out of the tier. Because the servers in the Web tier are usually load

balanced and are not running many SharePoint Services, they do not require large amounts of memory

or local storage.

Application tier

The servers in this tier run the services, service applications, and jobs that support SharePoint features.

An application server may be dedicated to hosting a single service, support a subset of feature, or host

more than one service. Depending on farm requirements, multiple load-balanced application servers can

be used to distribute workloads as well as provide high availability.

Database tier

Sometimes referred to as the backend database tier, the servers in this tier are dedicated to hosting the

database server instance that handles every aspect of SharePoint farm content, farm configuration data,

and the service application databases.

Note: There are cases where organizations share the database server with more than one application to

host databases. Because this can cause significant performance and capacity issues, as a best practice

we recommend dedicating the database server to SharePoint.

Farm topology examples The following examples show how SharePoint can be deployed on one or more servers using tiered

topologies and server roles to implement a farm design that meets specific goals and objectives.

One-tier farm There are scenarios where it makes sense to install SharePoint on single server. A single server farm is

typically used to demonstrate SharePoint, to conduct a cursory evaluation of SharePoint features, or to

compare SharePoint 2013 with previous releases of the product.

4

Two-tier farm In two-tier farm, the database server is installed on one server and all the other roles are installed on

the second server. This level of separation is the minimum we recommend for deploying SharePoint on

Windows Azure. This environment is well suited for in-depth product evaluation, development and

testing or for limited production environments that have a small number of users (such as SharePoint

pilot) and high availability is not required.

FIGURE 1 – TWO-TIER SHAREPOINT FARM

Three–tier farm The three-tier topology shown in the following illustration consists of two front-end Web servers, an

application server, and a database server. This model provides the foundation for deploying a farm that

can scale out in response to increased workload demands or an expanding user base. It also provides the

framework for using redundant servers to increase farm capacity and at the same time increase farm

availability, which is shown in Figure 3. It is worth noting that in order to provide a highly available

service you will need at least 2 servers in each role.

FIGURE 2 - MULTI-SERVER FARM WITH 2 WEB SERVERS, 1 APPLICATION AND DATABASE SERVER

5

FIGURE 3 - MULTI-SERVER FARM FOR HIGH AVAILABILITY

Large, high demand SharePoint server farms that support a high number of concurrent users and a large

number of content items use service grouping as part of their scalability strategy. This approach

involves running services on dedicated servers, grouping these services together, and then scaling out

the servers as a group. Figure 4 provides a model of service and server grouping in a three-tier farm.

FIGURE 4 – LARGE MULTI-SERVER FARM WITH MULTIPLE SERVER GROUPS

SharePoint farm sizes Size is used in conjunction with topologies to describe the physical architecture of a farm. SharePoint

farms are categorized as small, medium, and large. These sizes reflect the number of servers that are

required for a farm that has ‘n’ users and ‘n’ content items.

6

Small server farm

A small server farm consists of at least two Web servers and a database server. One of the Web servers

hosts the Central Administration site and services and the other handles additional tasks, such as

handling content requests. This farm can be scaled out to three tiers by using a dedicated application

server.

Medium server farm

A medium server farm usually has two or more Web servers, two application servers, and at least two

database servers.

Large server farm

A large server farm is the result of scaling out a medium farm to meet capacity and performance

requirements or in preparation for implementing a SharePoint 2013 solution. A three-tier topology

typically uses dedicated servers on each tier and servers are grouped according to their role. (See Figure

4.)

SharePoint farm scalability SharePoint Server is designed to support service and service application granularity, which means you

can configure a feature to run its supporting services or service applications on individual servers in a

tier or on different tiers. This design approach provides a high degree of flexibility for scaling out a farm

and can be applied to every tier.

Scaling alternatives Scaling up farm servers or scaling out the farm by adding servers are both acceptable alternatives for a

SharePoint Server farm. In addition, both approaches to scaling can be applied to physical servers or

virtual machines. The decision to scale up or scale out a farm, like farm topology design, depends on

several factors.

Cost, flexibility, and provisioning speed were the primary determining factors in making scaling choices

when physical servers, peripherals and networks provided the infrastructure. It was faster and less

expensive to upgrade hardware than it was to add hardware.

With Windows Azure it is more effective to scale out by adding virtual machines to the farm.

Provisioning new servers is faster, which enables quicker response to peak demands.

Scale out also provides two other significant benefits: increased availability and reduced downtime

(planned or unplanned.) From a high availability perspective, virtualization flexibility and cost makes it

feasible to build server and service redundancy into the SharePoint farm design. This redundancy can

reduce or eliminate failure domains. The ability to quickly add additional servers to any of the farm tiers

also reduces the amount of downtime when applying software updates to the operating system, SQL

Server, or SharePoint.

7

Windows Azure Windows Azure can support the deployment of Microsoft SharePoint 2013 servers utilizing 2 key

technologies, Virtual Machines and Virtual Networks.

Windows Azure Virtual Machines Windows Azure Virtual Machine enables you to create a virtual machine running Windows Server or

Linux. After you create a virtual machine in Windows Azure, you can access it like any other server and

you can delete and re-create it whenever you need to. You can use a virtual machine in Windows Azure

to deploy the Windows Server 2008 R2 or Windows Server 2012. Windows Azure virtual machines are

built from virtual hard disks (VHD). These VHDs are the same as the VHDs used by Hyper-V, and can be

transferred to and from your existing environment. Windows Azure also allows you to create multiple

virtual machines and then load balance traffic from the internet between them.

Virtual Machine Sizes Windows Azure provides specific combinations of CPU Cores & memory. These combinations are known

as Virtual Machine Sizes. When you create a Virtual Machine you have to select a specific size. This size

can be changed after deployment. The sizes available for Virtual Machines are:

Extra Small (Shared core, 768MB Memory)

Small (1 core, 1.75GB Memory)

Medium (2 cores, 3.5GB Memory)

Large (4 cores, 7GB Memory)

Extra Large (8 cores, 14GB Memory)

A6 (4 cores, 28GB Memory)

A7 (8 cores, 56GB Memory)

Virtual Machine Components A Windows Azure Virtual Machine is created from an image or a disk, and all Virtual Machines use one

operating system disk, a temporary local disk, and possibly multiple data disks. All images and disks,

except the temporary local disk, are created from Virtual Hard Disk (VHD) files stored as page blobs in a

storage account in Windows Azure. You can use platform images that are available in Windows Azure to

create virtual machines or you can upload your own images to create customized virtual machines. The

disks that are created from images are also stored in Windows Azure storage. You can easily create new

virtual machines from existing disks.

8

VHDs

A VHD file is stored as a page blob in Windows Azure storage and can be used for creating images,

operating system disks, or data disks in Windows Azure. You can upload a VHD file to Windows Azure

and manage it just as you would any other page blob. VHD files can be copied or moved and they can be

deleted as long as they are not being referenced by a disk. For more information about page blobs, see

Understanding Block Blobs and Page Blobs.

A VHD can be in either a fixed format or a dynamic format, but only the fixed format of VHD files is

supported in Windows Azure. The fixed format lays the logical disk out linearly within the file, such that

disk offset X is stored at blob offset X. At the end of the blob, there is a small footer that describes the

properties of the VHD. Often, the fixed format wastes space because most disks have large unused

ranges in them. However, in Windows Azure, fixed VHD files are stored in a sparse format, so you

receive the benefits of both the fixed and dynamic disks at the same time, which includes only being

billed for the bits you are actually using. For more information about VHDs, see Getting Started with

Virtual Hard Disks.

Images An image is a VHD file that you can use as a template to create a new virtual machine. An image is a

template because it doesn’t have specific settings like a configured virtual machine, such as the

computer name and user account settings. Think of these as sysprep’d images. You can use Platform

Images from the Image Gallery which are provided by Microsoft to create virtual machines or you can

create your own images.

All Windows images from the gallery now have an operating system disk size of 127GB. There are also a

number of gallery images that you can use to build SharePoint 2013 farms including several SQL Server

2012 images as well as a SharePoint 2013 Trial. This trial image contains the SharePoint 2013 binaries,

but the farm install wizard has not been executed.

FIGURE 5 - WINDOWS AZURE VIRTUAL MACHINE GALLERY

9

This SharePoint 2013 trial license can be upgraded to a fully licensed version. To convert a license type

and enter the product key

1. Verify that you have the following administrative credentials:

To convert a license type, you must be a member of the Farm Administrators SharePoint group

on the computer that is running Central Administration.

2. On the Central Administration Web site, in the Upgrade and Migration section, click Convert

farm license type.

3. On the Convert License Type page, in the Enter the Product Key box, type the new product key

and then click OK.

Disks You use disks in different ways with a virtual machine in Windows Azure. An operating system disk is a

VHD that you use to provide an operating system for a virtual machine. A data disk is a VHD that you

attach to a virtual machine to store application data. You can create and delete disks whenever you

need to.

You choose from multiple ways to create disks depending on the needs of your application. For example,

a typical way to create an operating system disk is to use an image from the Image Gallery when you

create a virtual machine and an operating system disk is created for you. You can create a data disk by

attaching an empty disk to a virtual machine and a new data disk is created for you. You can also create

a disk by using a VHD file that has been uploaded or copied to a storage account in your subscription.

You can’t use the portal to upload VHD files, but you can use other tools that work with Windows Azure

storage to upload or copy the file including the Windows Azure PowerShell CmdLets. See

http://michaelwasham.com/2013/03/27/windows-azure-powershell-cmdlets-now-supports-storage/ for

more information.

Operating system disk

Every virtual machine has one operating system disk. You can upload a VHD that can be used as an

operating system disk, or you can create a virtual machine from an image and a disk is created for you.

An operating system disk is a VHD that you can boot and mount as a running version of an operating

system. Any VHD that is attached to virtualized hardware and that is running as part of a service is an

operating system disk. An operating system disk can be a maximum of 127 GB. When an operating

system disk is created in Windows Azure, three copies of the disk are created for high durability.

Additionally, if you choose to use disaster recovery that is geo-replication based, your VHD is also

replicated at a distance of greater than 400 miles. Operating system disks are registered as SATA drives

and are labeled as the C drive.

Data disk

A data disk is a VHD that can be attached to a running virtual machine to persistently store application

data. You can upload and attach a data disk that already contains data to the virtual machine, or you can

use the Windows Azure Management Portal to attach an empty disk to the machine. The maximum size

of a data disk is 1 TB and you are limited in the number of disks that you can attach to a virtual machine

based on the size of the machine. Data disks are registered as SCSI drives and you can make them

available for use within the operating system using the disk manage in Windows. The following table

lists the number of attached disks that are allowed for each size of virtual machine.

10

Size Data Disk Limit

Extra Small 1

Small 2

Medium 4

Large 8

Extra Large 16

A6 8

A7 16

Temporary local disk

Each virtual machine that you create has a temporary local disk, which is labeled as the D drive. This disk

is used by applications and processes running in the virtual machine for transient and temporary storage

of data. It is also used to store page files for the operating system. Note that this drive letter cannot be

changed and any data will not survive a machine failure or any other operation that requires moving the

virtual machine to another piece of hardware.

Caching The operating system disk and data disk has a host caching setting (sometimes called host-cache mode)

that enables improved performance under some circumstances. However, these settings can negatively

affect performance in other circumstances, depending on the application. Host caching is OFF by default

for both read operations and write operations for data disks. Host caching is ON by default for read and

write operations for operating system disks.

RDP and Remote PowerShell

It is worth noting that new Virtual Machines will have both RDP and Remote PowerShell available.

Windows Azure Virtual Networking Windows Azure Virtual Network lets you provision and manage virtual private networks (VPNs) in

Windows Azure as well as securely link these with on-premises IT infrastructure. With Virtual Network,

IT administrators can extend on-premises networks into the cloud with control over network topology,

including configuration of DNS and IP address ranges for Virtual Machines.

You should always create a virtual network within Windows Azure before deploying any new virtual

machines. Creating a virtual network will allow you to group your virtual machines together within the

datacenter as well as allow you to divide and influence the IP address ranges given to your virtual

machines.

When you create a virtual network, you can divide the network into one or more subnets. Each subnet

can have its own address range. When you create a server and add it to a subnet, it will be given one of

the IP addresses from the range you defined via DHCP. The time on the DHCP lease is set to at least 100

years.

It is important to note that Windows Azure itself uses several IP addresses. This means the first virtual

machine you add typically has the 4th IP address in the range. For example, in a 10.0.0.0/11 subnet, the

IP address of your first virtual machine will be 10.0.0.4.

11

Site to site network connections If you wish to connect the virtual network in Windows Azure to an existing network outside the

Windows Azure datacenter you can create a traditional site-to-site VPN to securely scale your

datacenter capacity. Virtual Network uses industry-standard IPSEC protocol to provide a secure

connection between your corporate VPN gateway and Windows Azure. You can control network access

using your on-premises security device, to control traffic between your data center and virtual machines

running in Windows Azure as well as the standard firewall within Windows Server.

DNS When you define a virtual network, Windows Azure will provide a DNS service, however if you wish to

use your existing DNS infrastructure, or have a dependency on Active Directory you need to define your

own. Defining your own in the virtual network configuration doesn’t actually create a DNS server;

instead you are configuring the DHCP service to include the DNS server IP that you define. This DNS

server could be a reference to an existing on-premises DNS server, or a new DNS server that you will

provision in the cloud.

Note: It’s important not to make changes to the network interface, NIC, to configure DNS etc. You must

rely on the platform to provide this information otherwise your machine could become unreachable.

Affinity Groups When you create a Virtual Network, an affinity group will also be created. When you create resources,

such as storage accounts, in Windows Azure an affinity group will let Window Azure know you wish to

keep these resources located together. Once you have an affinity group, you should reference this

always when creating related resources.

Firewalls and Endpoints When you create a Virtual Machine, it is fully accessible from any of your other virtual machines within

your VNET. All protocols, such as TCP, UDP, and ICMP etc. are supported within the local Virtual

Network. Virtual Machines on your Virtual Network are given an internal IP address from a range you

defined when you created the network.

If you wish to access your virtual machines from outside of your virtual network you will have to use the

external IP address and configure public Endpoints. These endpoints are similar to firewall and port

forwarding rules and can be configured in the Windows Azure portal. As a default, ports for both RDP

and Remote PowerShell are opened. These ports use random public port addresses which are mapped

to the correct ports on the virtual machines. You can remove these pre-configured endpoints if you have

network connectivity via a VPN.

If you want to allow internet traffic to your SharePoint farm you will have to open up the appropriate

ports on the Web Server Virtual Machines. For example, you could open port 80 externally and map that

to port 3456 internally.

Traffic from your on-premises network can access the virtual machines on your virtual network if you

have configured a site-to-site VPN connection as discussed previously.

12

Load balanced endpoints Windows Azure also allows you to load balance network traffic between multiple virtual machines

behind the same endpoint. To do this you create a new virtual server, but rather than configuring it as a

standalone server you can add it to an existing server. Once you have done this you can create a load

balanced endpoint.

FIGURE 6 – PUBLIC & PRIVATE IPS, ENDPOINTS AND LOAD BALANCED ENDPOINTS

Windows Azure will simply round-robin the traffic between the nodes. You can have up 50 virtual

machines behind a single load balanced endpoint. When you add virtual machines to a load balanced

endpoint you should also create an availability set. You can only load balance traffic from the public

internet, there is no provision to load balance internal traffic.

High Availability & Availability Sets For deployments where you need high availability you should deploy more than one virtual machine for

each particular role. By using multiple virtual machines in your application, you can make sure that your

application is available during local network failures, local disk hardware failures, and any planned

downtime that the platform may require.

You manage the availability of your application that uses multiple virtual machines by adding the

machines to an availability set. Availability sets are directly related to fault domains and update

domains. A fault domain in Windows Azure is defined by avoiding single points of failure, like the

network switch or power unit of a rack of servers. In fact, a fault domain is closely equivalent to a rack of

physical servers. When multiple virtual machines are connected together in a cloud service, an

availability set can be used to ensure that all the machines in the set are not taken down at the same

time during servicing and minimizes the risk of the entire set failing.

13

FIGURE 7 - FAULT DOMAINS AND AVAILABILITY SETS

Update domains Windows Azure periodically updates the operating system that hosts the instances of an application. A

virtual machine is shut down when an update is applied. An update domain is used to ensure that not all

of the virtual machine instances are updated at the same time. When you assign multiple virtual

machines to an availability set, Windows Azure ensures that the machines are assigned to different

update domains. The previous diagram shows two virtual machines running Internet Information

Services (IIS) in separate update domains and two virtual machines running SQL Server also in separate

update domains.

Important: The Windows Azure subscriber is responsible for installing updates to the SharePoint farm

servers. For more information, refer to the “Patching and updating” section.

You should use a combination of availability sets and load-balancing endpoints to make sure that your

application is always available and running efficiently. For more information about using load-balanced

endpoints, see Load Balancing Virtual Machines.

The Windows Azure scalability model Scale out is a fundamental, core principle of the Windows Azure infrastructure. When you plan a

SharePoint farm that is hosted on Azure design the farm topology from the perspective of using many

smaller capacity servers instead focusing on fewer high capacity servers.

14

Deploying a SharePoint farm on Windows Azure After you finishing planning your SharePoint farm and design a farm topology you are ready to deploy a

SharePoint farm. For the purpose of this article we divide the deployment process into the following two

phases.

Phase 1. Prepare the Windows Azure environment to host the SharePoint farm.

In this phase you will:

Create the network infrastructure & storage account

Create the servers required for the farm domain

Create the servers required to host SharePoint databases

Create the SharePoint farm servers

Phase 2. Install and configure SharePoint 2013.

In this phase you will:

Install SharePoint on all the farm servers

Configure the SharePoint farm

The key thing to note is that once you have the network and virtual machines created, deploying and

managing SharePoint is almost exactly the same in Windows Azure as it is on-premises.

The following section describes the considerations for each phase. For a detailed walkthrough, please

see the walkthrough guide in the appendix.

Preparing the Azure environment

Network Infrastructure The first step in deploying any workload to Windows Azure is to create the Virtual Network. As part of

this virtual network creation and affinity group will be created.

It is recommended that you create a subnet for each group of servers you wish to deploy as part of your

farm. In the example in the figure below there are 4 virtual machine roles, and therefore 4 subnets have

been created:

15

FIGURE 8 - SUBNETS IN WINDOWS AZURE

External Network Connections If you wish to connect the virtual network in Windows Azure to an on-premises network you need to

create a Local Network. For more information on creating a local network see

http://www.windowsazure.com/en-us/manage/services/networking/cross-premises-connectivity/

DNS Since SharePoint requires active directory, you will need to define your own DNS servers since you

cannot use the one provided by Windows Azure. These DNS servers need to reference a domain

controller with DNS installed and configured. It is recommended that you create new servers configured

as domain controllers within Windows Azure to reduce latency rather than reference existing on-

premises DNS servers.

Once you have defined the virtual network and affinity group you should create a storage account and

set its location to the same affinity group. This will ensure all your resources are within close proximity

of each other.

Storage Account Before you create a Virtual Machine, you should create a Windows Azure Storage Account. This account

should be created in the same affinity group as the network you just created. This will ensure your

network, disks and virtual machines are located within close proximity within the datacenter, thus

reducing latency.

Virtual Machine Configurations Windows Azure provides specific combinations of CPU Cores & memory. These combinations are known

as Virtual Machine Sizes. When you create a Virtual Machine you have to select a specific size. Although

you cannot change the makeup of a specific machine size, i.e. add more memory etc. You can change

which of the fixed sizes your Virtual Machine users after deployment.

16

As a rule of thumb, you should consider using the following sizes as the minimum for each of the

SharePoint roles:

Role Size

SharePoint 2013 Web Servers Large

SharePoint 2013 Application Services Large

SQL Server Extra Large

Domain Controller Small

For both the domain controller and SQL Server virtual machines you should add data drives to store the

Domain and SQL databases respectively.

For SharePoint, domain controllers and SQL Server we recommend that the Host-caching is set to OFF.

It is also recommended that you setup a cycle of monitoring performance against your workload. When

confronted with more demand, you can choose to increase the virtual machine sizes or add more virtual

machines to each SharePoint role. See the monitoring section later in this guide for more information.

Configure the domain infrastructure The farm infrastructure will require at least one server as a domain controller that provides essential

domain services such as Active Directory, DNS, and DHCP.

Active Directory SharePoint has a dependency on a domain controller. This domain controller can either be a new forest

for Developer, test or proof-of-concept (POC) scenarios, or can be connected to the on-premises

domain. Connecting to on-premises requires the creation and configuration of a local network

connection or VPN. It is NOT recommended to use a remote domain controller. Best practice is to

deploy a domain controller within Windows Azure.

If you want to ensure high availability, you should create at least 2 domain controllers. These 2 virtual

machines should be configured within the same availability set. This will help ensure at least 1 is always

running.

Finally, you should ensure the domain controllers have the same internal ip address of the DNS you

configured earlier. If they are not, you should reconfigure the virtual network. You can do this by

exporting the network configuration, changing the configuration within the file, and then importing the

new configuration. You will have to restart your virtual machines deployed within Windows Azure so

they pick-up the new settings.

Farm infrastructure servers

SharePoint requires Microsoft SQL Server for its data storage. A SharePoint farm cannot be created, or

exist without one or more SQL Servers. You will create one or more Virtual Machines in Windows Azure

and install Microsoft SQL Server, or use the image provided in the Gallery.

The number of database servers is determined by whether or not you want to implement a SQL Server

high availability such as database clustering or AlwaysOn Availability Groups.

17

The supported versions of SQL Server are for SharePoint are:

The 64-bit edition of Microsoft SQL Server 2012

The 64-bit edition of SQL Server 2008 R2 Service Pack 1

It is recommended that you add one or more data disks to your Windows Azure Virtual Machines

running SQL Server. You should format these disks individually and store the database files on them. It is

recommended you create multiple database files on each disk, rather than using any software striping.

FIGURE 9 - VIRTUAL MACHINE WITH 4 ATTACHED DATA DRIVES

For SharePoint 2013, the SQL Server(s) virtual machine must be located on the same virtual network in

Windows Azure. We do not support running SQL Server in any other location, including other

datacenters.

Configure the farm servers Use your farm topology as a guide to create the number of virtual machines that you need. Configure

and size these virtual machines using the published SharePoint best practice sizing guidance for farm

server roles. In Windows Azure we recommend Large as the starting machine size for all SharePoint

2013 roles. You can increase the size of these to suite your needs, even after deployment via the portal.

Load balancing support for farm servers SharePoint 2013 supports hardware load balancers for requests directed to the front-end web servers.

Because SharePoint 2013 now supports load balancers that do not provide sticky sessions you can use

the Windows Azure load balancer to reduce farm infrastructure complexity.

18

Configuration security for the infrastructure and farm Once you have a workload running within Windows Azure, most of the security configuration is

performed within the virtual machines. Thus many of the security procedures that you perform on

premises will apply directly to virtual machines running in Windows Azure, such as ACL’s, user accounts

and group policy.

For the services provided by Windows Azure the following should be considered:

Ensure the service administrator account(s) are kept secure. Service administrator accounts

essentially give you the keys to the datacenter. For normal management of Windows Server,

SQL Server and SharePoint, access to the service administrator account is not required. The

service administrator account is only needed when creating or modifying virtual machines or

networks.

Ensure the endpoints of the virtual machines are configured correctly. When you create an

endpoint to a virtual machine it makes that port available to anyone on the internet. It’s

important to appreciate that ports on the internet are subject to attacks from third parties and

you should ensure that:

o You only open ports that you need. Note: it is possible to remove all ports from the

virtual machine if no internet access is required.

o You have applied security rules within the firewall of the OS to prevent un-authorized

access.

Ensure you use strong passwords for all accounts that can be used to connect to the virtual

machines. Since these servers are visible on the internet, it is good practice to use strong

passwords and good password practices when hosting virtual machines.

Ensure that you monitor the use and access of management certificates in Windows Azure.

These management certificates are created by service administrators and can be used to access

the Windows Azure API’s via PowerShell without the need for password authentication.

Ensure the storage access keys are kept secret and not distributed. Anyone with the storage

access keys could download any of the VHD’s.

19

Install and configure SharePoint 2013 You install SharePoint on the farm servers and configure a SharePoint 2013 farm by following the

procedures and guidance provided for on-premise environments. The recommended steps, tasks and

installation sequence for deploying a small production farm are as follows.

1. Prepare the farm servers. In this step you get your servers ready to host SharePoint. This

includes the supporting servers and the servers that will have SharePoint installed.

Database server. Install the required version of SQL Server, including service packs and

cumulative updates. The installation must include any additional features, such as SQL

Analysis Services, and the appropriate SharePoint 2013 logins have to be added and

configured. The database server must be hardened. For more information, see:

o Hardware and software requirements

o Configure SQL Server security

Application servers and front-end Web servers. These servers must be prepared as follows:

verify that they meet the hardware requirements, have the operating system hardened,

have the required networking and security protocols configured, have the SharePoint 2013

software prerequisites installed and hardened, and have the required authentication

configured. For more information, see:

o System requirements for SharePoint 2013 o "Installing software prerequisites" in Hardware and software requirements for

SharePoint 2013 o Plan security hardening for SharePoint 2013 o Plan authentication in SharePoint 2013

Domain controller. Configure the required farm accounts and directory synchronization. For

more information, see:

o Initial deployment administrative and service accounts in SharePoint 2013

o About Directory Synchronization

2. Create the farm. In this step you install the product and configure each server to support its role

in the farm. You also create the configuration database and the SharePoint Central

Administration Web site.

Application servers.

o After you prepare the application server, install any additional components that are

required to support functions such as Information Rights Management (IRM) and

decision support.

o Install SharePoint on the server that will host SharePoint Central Administration

Web site and then run the SharePoint Products Configuration Wizard to create and

configure the farm.

Database server. When you run the SharePoint Products Configuration Wizard the

configuration database, content database, and other required databases are created.

Front-end Web servers. Install SharePoint 2013 and the language packs on each Web

server. Run the SharePoint Products Configuration Wizard to add the Web servers to the

farm.

20

3. Configure settings, services, solutions, and sites. Complete the following tasks to host your site

content.

Configure services. For more information, see Configure services and service applications in

SharePoint 2013

Configure global settings. For more information, see Configure SharePoint 2013

Create and populate the sites. For more information, see Set up web applications and sites

in SharePoint 2013

Refer to the following articles for step-by-step procedures that you can use for deploying SharePoint

2013.Install SharePoint 2013 across multiple servers for a three-tier farm

Test Lab Guide: Configure SharePoint Server 2013 in a Three-Tier Farm

Operate and maintain SharePoint farm on Windows Azure

Monitoring Operating a SharePoint farm running in Windows Azure is no different than operating a SharePoint farm

anywhere else. Despite the power and agility Windows Azure brings you, at the end of the day you still

have a Windows Server, SharePoint and the dependencies to manage. On premises you may use a

combination of Windows Server tools and the SharePoint administration tools, or manage the whole

farm via System Center. Regardless, the same tools and procedures can be used when the farm is hosted

in Windows Azure.

For more information see the monitoring guide at http://technet.microsoft.com/en-

us/library/jj219701.aspx

Patching and updating Again, patching and updating the OS, SharePoint and the dependencies is not different in Windows

Azure than anywhere else. You are still responsible for OS patching etc. and you are still in full control of

how and when that should happen. Patching and updating a SharePoint 2013 farm can be quiet involved

depending upon the topology. Please refer to http://technet.microsoft.com/en-us/library/ff806329.aspx

for more information.

One area in which Windows Azure can help is when testing major updates. Since you can create

resources on-demand, you could spin up a duplicate environment within Windows Azure and test your

update or patching strategy and methodology.

Backup and Recovery Backing up and recovery of SharePoint farms in Windows Azure is again is very similar. One thing to

consider is that you should suffer no significant down-time due to hardware failure. Since Windows

Azure will auto repair and redeploy your virtual machine there is no action to take on your part. That

said, you do need to consider the fact that you will get “hardware” downtime that would be

automatically repaired. It is good to ensure that any customizations you perform or applications you

deploy can handle this automatic recovery. The second key point here is that Windows Azure makes it

very easy to deploy more virtual machines making it possible to create a highly available farm as

discussed previously.

21

Appendix

SharePoint 2013 Resource Centers The following are useful resources for SharePoint 2013:

Capabilities and features in SharePoint 2013 Resource Center

Architecture design for SharePoint 2013 IT pros

Installation and deployment for SharePoint 2013 IT Pros Resource Center

Gold Images and Lab Environments Whilst you can use the Microsoft supplied Image in the Windows Azure Virtual Machine Gallery, another

viable choice is to create your own image. You might want to do this if you have different requirements,

or wish to preload other software, such as antimalware.

Windows Azure allows you to create “gold images” by creating a disk image from an existing VHD. This

disk image contains both the operating system and any customizations you may require, such as the

installation of software, changing of Windows settings etc. This disk image can then be used to create

new virtual machines. Using a disk image means that you can quickly create multiple copies of the same

server.

To create a gold image, you need a virtual machine on which to base the image. This virtual machine is

just a standard Windows Azure virtual machine that has been customized. To create a base with

SharePoint installed it is recommended that you do not complete the entire SharePoint installation. This

is due to incompatibilities with SysPrep, which is a required step to prepare the disk image.

To summarize the steps:

1. Create a new Virtual Machine based on the Windows Server 2012 or SharePoint 2013 trail image

in the gallery.

2. RDP into the new server and:

a. Download the installation files.

b. Install the SharePoint prerequisites.

c. Run the SharePoint software installation but do not complete the configuration Wizard.

You must install SharePoint onto the operating system drive in order to SysPrep as data

drives are not captured as part of the SysPrep process.

d. Run SysPrep and shutdown the virtual machine.

3. Select Capture from the Windows Azure Portal Virtual Machine Dashboard and follow the

wizard. You can now use this image as a template for new virtual machines.

For more information on how to capture an Image, see the how to guide which is also applicable for

Windows Server 2012 - http://www.windowsazure.com/en-us/manage/windows/how-to-

guides/capture-an-image/

Managing Lab Environments and automation All of the operations you perform on virtual machines or virtual networks in Windows Azure can be

automated using PowerShell. With this in mind, automating the creation of SharePoint farms for lab or

testing purposes is very simple. Microsoft are working on some PowerShell scripts to help with this

automation, which will be available in the near future.