SharePoint 2013 on Windows Azure Infrastructure David Aiken & Dan Wesley Version 1.0

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 1

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: 2

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

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 4

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

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

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

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 8

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

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 4 th 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. 10

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

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

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

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: 14

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 onpremises 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. 15

As a rule of thumb, you should consider using the following sizes as the minimum for each of the SharePoint roles: Role SharePoint 2013 Web Servers SharePoint 2013 Application Services SQL Server Domain Controller Size Large Large Extra Large 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. 16

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

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

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

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/enus/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. 20

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-toguides/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. 21