Planning for SharePoint 2013 on Azure Infrastructure Services
Updated: January 29, 2015
With the virtual machine and virtual network services of Azure, it is now possible to deploy and operate an Internet-facing or intranet-only Microsoft SharePoint Server 2013 farm with SQL Server AlwaysOn Availability Groups in Azure. The following figure shows an example configuration.
This topic discusses the key design considerations, architecture, and operations required to do this successfully. This topic assumes a basic working knowledge of SharePoint Server 2013 and familiarity with the services offered by Azure.
Microsoft offers and licenses two categories of SharePoint farm solutions. These solutions are in the cloud (SharePoint Online with Office 365) and on-premises (SharePoint 2013).
SharePoint 2013 uses traditional software licensing and installation. You can install and configure SharePoint to deploy a farm on physical computers or in a virtual environment. You also have the option of deploying and operating a farm in your own datacenter or on an infrastructure provided by a hosting service. The Deploying SharePoint 2013 with SQL Server AlwaysOn Availability Groups in Azure document set describes deploying a SharePoint 2013 farm for Internet users with SQL Server AlwaysOn Availability Groups in Azure infrastructure services.
SharePoint Server 2013 provides an extensive set of features to support a wide range of collaborative activities for an organization. However, these features and capabilities can make planning and design a challenge due to the following:
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 capacities.
The importance of SharePoint farm planning and design cannot be overstated. Inadequate planning resulting in 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. Planning and design issues also contribute to a significant number of product support calls related to capacity and performance.
Thorough and careful planning is critical to ensure that a SharePoint farm is deployed successfully and provides the expected functionality.
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 Determine how, how often, and when your users will use the farm functions that are provided.
Farm content Farm content types (for example, documents, pictures, videos, lists, and web articles) 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. There are other factors that must also be included in farm planning, such as security, high availability, and scalability. For more information, see Plan for SharePoint 2013.
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 Plan logical architectures for SharePoint 2013.
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 vary. 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 tiers, which are just a convenient way to organize or categorize farm servers. Tier membership is based on server roles, which describe the features or services that a server provides. It is important to note that 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 a corporate intranet or for Internet-facing sites. Note 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.
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 tier 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.
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 a feature, or host more than one service. Depending on farm requirements, multiple load-balanced application servers can be used to distribute workloads and provide high availability.
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.
SharePoint 2013 does not support using an Azure SQL Database as a substitute for a server computer running SQL Server.
|There are cases where organizations share the database server with more than one application that uses SQL server. Because this can cause significant performance and capacity issues, as a best practice we recommend using a dedicated database server for SharePoint.|
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.
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 its previous releases.
In a two-tier farm shown in Figure 1, 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 Azure. This topology is suited for in-depth product evaluation, development and testing, or for limited production environments that have a small number of users (such as a SharePoint pilot deployment) and high availability is not required.
Figure 1 – Two-tier SharePoint farm
You can use SharePoint Server Farm, a feature of the Microsoft Azure Preview Portal, to automatically create a pre-configured two-tier, two-server SharePoint Server 2013 farm. This farm, known as the basic farm configuration, is created in a cloud-only virtual network for evaluation or SharePoint application development and testing purposes. For more information, see SharePoint Server Farm.
The three-tier topology shown in Figure 2 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.
Figure 2 – Multi-server farm with two web servers, one application server, and one database server
It also provides the framework for using redundant servers to increase farm capacity and farm availability, which is shown in Figure 3. In order to provide a highly available service, you will need at least two servers in each tier or for each role within a tier.
Figure 3 – Multi-server farm with high availability
You can use SharePoint Server Farm, a feature of the Microsoft Azure Preview Portal, to automatically create a pre-configured, highly-available SharePoint Server 2013 farm. This farm, known as the high-availability farm configuration, is created in a cloud-only virtual network for evaluation or SharePoint application development and testing purposes. For more information, see SharePoint Server Farm.
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 shows a model of service and server grouping in a three-tier farm.
Figure 4 - Large multi-server farm with multiple server groups
Size is used in conjunction with topologies to describe the physical architecture of a farm. SharePoint farms are categorized as small, medium, and large.
A small server farm consists of the following:
Two web servers
One database server
One of the web servers hosts the Central Administration site and services and the other handles additional tasks, such as incoming client content requests. This farm can be scaled out to three tiers by using a dedicated application server. See Figure 2 for an example.
A medium server farm usually has the following:
Two or more web servers
Two application servers
At least two database servers
See Figure 3 for an example.
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 for an example.
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 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 are the primary determining factors in making scaling choices when physical servers, peripherals, and networks provide the infrastructure. It is faster and less expensive to upgrade hardware than it is to add hardware.
However, with Azure it is more effective to scale out by adding virtual machines to the farm. Provisioning new servers is faster, which enables quicker response for 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 make 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.
Azure supports the deployment of SharePoint 2013 farms with virtual machines and virtual networks.
Azure allows you to create a virtual machine running Windows Server or other operating systems. After you create a virtual machine in Azure, you can access it like any other server and delete or re-create it whenever needed. You can use a virtual machine in Azure to deploy a Windows Server 2012 R2-based server.
Azure virtual machines are built from virtual hard disks (VHDs). These VHDs are the same as the VHDs used by Hyper-V and can be transferred to and from your existing environment. Azure also allows you to create multiple virtual machines and then load balance traffic from the Internet between them.
Azure provides specific combinations of CPU cores and memory 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 the following:
A1 (Shared core, 768MB Memory)
A2 (1 core, 1.75GB Memory)
A3 (2 cores, 3.5GB Memory)
A4 (4 cores, 7GB Memory)
A5 (8 cores, 14GB Memory)
A6 (4 cores, 28GB Memory)
A7 (8 cores, 56GB Memory)
You create an Azure Virtual Machine 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 VHD files stored as page blobs in a storage account in Azure. You can use platform images that are available in Azure to create virtual machines or you can upload your own images. The disks that are created from images are also stored in Azure storage. You can easily create new virtual machines from existing disks.
A VHD file is stored as a page blob in Azure storage and can be used for creating images, operating system disks, or data disks in Azure. You can upload a VHD file to 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. A VHD file is stored as a page blob in Azure storage and can be used for creating images, operating system disks, or data disks. You can upload a VHD file to 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 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 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.
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 images prepared with the SysPrep tool. 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.
There are also a number of gallery images that you can use to build SharePoint 2013 farms including several SQL Server 2012 images. The SharePoint 2013 Trial image has SharePoint Server 2013 installed, but the SharePoint Products and Technologies Configuration wizard has not been run.
Figure 5 shows an example of the list of images provided by Azure.
Figure 5 – Example of the Azure image gallery
The SharePoint 2013 Trial license can be upgraded to a fully licensed version. To convert a license type and enter the product key, do the following:
Verify that you have logged on to the SharePoint server as a member of the Farm Administrators SharePoint group on the computer that is running Central Administration.
On the Central Administration Web site, in the Upgrade and Migration section, click Convert farm license type.
On the Convert License Type page, in the Enter the Product Key box, type your SharePoint 2013 product key and then click OK.
You use disks in different ways with a virtual machine in 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 as needed.
You can 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 Azure storage to upload or copy the file, including Azure PowerShell commands. For more information, see Azure PowerShell Cmdlets Now Supports Storage.
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 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 Windows using Server Manager or the Disk Management snap-in. The following table lists the number of attached disks that are allowed for each virtual machine size.
|Size||Maximum Attached Disks|
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 on the D: drive will not survive a machine failure or any other operation that requires moving the virtual machine to another piece of hardware.
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. Please note the default settings:
For data disks, host caching is OFF for both read and write operations.
For operating system disks, host caching is ON for both read and write operations.
You can access new virtual machines over the Internet through the Remote Desktop Protocol (RDP) and with remote Windows PowerShell sessions. By default, Azure adds inbound mappings, known as endpoints, for both types of traffic when you create the virtual machine. These endpoints allow incoming RDP and remote Windows PowerShell sessions with the appropriate user credentials.
An Azure Virtual Network is a logical container that can host virtual machines grouped on subnets. Virtual machines on subnets in a virtual network can communicate directly with each other, just like on intranet subnets, without that traffic traversing the Internet. This is in contrast with Azure Virtual Machines that are not in a virtual network, which cannot communicate with each other without that traffic traversing the Internet.
There are two types of virtual networks:
Cross-premises virtual network A virtual network that is connected to your organization network across the Internet through a site-to-site VPN connection. Virtual machines in a cross-premises virtual network act as an extension of your organization network, providing applications and services to intranet users, Internet users, or both.
Cloud-only virtual network A virtual network that is not connected to your organization network. Virtual machines in a cloud-only virtual network typically provide applications and services to Internet users
With cross-premises virtual networks, IT administrators can extend on-premises networks into the cloud with control over subnet topology and virtual machine configuration of private IP addresses and DNS servers.
You should always create a virtual network within Azure before deploying any new virtual machines. Creating a virtual network will allow you to group your virtual machines together and allow you to divide and determine the ranges of IP addresses assigned to your virtual machines.
When you create a cross-premises virtual network, you define a private IPv4 address range unique to your organization network to use for all the subnets that the virtual network will contain. You also define an IPv4 address range for each subnet. When you create a virtual machine and add it to a subnet, Azure will assign an address from the IPv4 address range for the subnet through DHCP. The time on the DHCP lease is set to at least 100 years, providing a very stable address configuration.
It is important to note that Azure itself uses several addresses from the IPv4 address range for each subnet. The first virtual machine you add to a subnet typically has the fourth IP address in the range. For example, for the subnet with the address range 10.0.0.0/24 (or 10.0.0.0 with the subnet mask 255.255.255.0), the IP address of your first virtual machine will be 10.0.0.4.
To connect the cross-premises virtual network in Azure to your on-premises network, you create a site-to-site VPN connection. A VPN gateway device at the boundary of your on-premises network creates a secure connection to an Azure VPN gateway at the edge of your virtual network. To ensure that you can reach the virtual machines from your on-premises network, you must configure your routing infrastructure with routes for the address space of the virtual network to point to your VPN gateway device.
Azure site-to-site connections use the industry-standard Internet Security protocol (IPsec) to provide a secure connection between your VPN gateway device and an Azure VPN gateway at the boundary of your Azure virtual network. You can control network access using your on-premises security device. You can also control traffic between your data center and virtual machines running in Azure with the standard host-based Windows Firewall included with Windows Server.
To minimize the latency of performing authentication of intranet user credentials for access to and administration of SharePoint farm sites and resources, you should deploy Active Directory Domain Services (AD DS) domain controllers in the virtual network. For redundancy, you should deploy at least two.
For additional information, see Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines.
|SharePoint 2013 requires AD DS domain membership for the server on which it runs. You cannot use Azure Active Directory (AD) as a substitute for AD DS domain membership for the SharePoint 2013 server. However, you can use Azure AD to provide authentication for users accessing SharePoint resources. For more information, see Azure Active Directory with SharePoint 2013.|
When you define a cross-premises virtual network, you configure Azure with the IP addresses of DNS servers that are assigned to virtual machines with DHCP. These DNS servers could be existing, on-premises DNS servers or DNS servers that you will create within the virtual network. You can also host the DNS servers on the AD DS domain controllers in the virtual network.
|You should not make changes to the network connections of virtual machines in an Azure Virtual Network, for example, to configure DNS settings or other behavior. You must rely on Azure to provide network connection configuration, otherwise your virtual machine could become unreachable.|
When you create a virtual network, you can create an affinity group or specify a previously-created affinity group. When you create resources in Azure, such as storage accounts, an affinity group will let Window Azure know you wish to keep these resources located together within the same Azure regional datacenter. Once you have an affinity group, you should always specify it when creating related resources.
When you create a virtual machine, it is fully accessible from your other virtual machines within your virtual network. All TCP/IP protocols—such as TCP, UDP, and ICMP—are supported within the virtual network, subject to the settings of host-based firewalls, such as Windows Firewall in Windows Server 2012.
If you want to access your virtual machines from the Internet or make the resources on your virtual machines accessible to users on the Internet, you must use the external name or public IP address of the cloud service in which the virtual network is contained and configure endpoints. Endpoints are similar to firewall and port forwarding or mapping rules and can be configured for individual virtual machines in the Azure Management Portal.
By default, Azure configures endpoints for both RDP and Remote PowerShell traffic. These endpoints use random port numbers for the public ports that are mapped to the correct private port numbers on the virtual machines.
|To prevent malicious users on the Internet from attempting to access your virtual machines using RDP or Remote PowerShell, you can remove these pre-configured endpoints for cross-premises virtual networks. The tradeoff is that you can only administer the virtual machines from the on-premises network. Administrators located on the Internet must first obtain a connection to the on-premises network, for example, with a remote access connection.|
For Internet traffic to your SharePoint farm, you must configure endpoints on the web server virtual machines. For example, you could configure an endpoint for the public TCP port 80 that maps to a private TCP port 80 (for standard web traffic), or to the TCP port on which the SharePoint server is listening.
If you have configured your routing infrastructure to include the address space of your cross-premises virtual network, you can access the virtual machines on your cross-premises virtual network as you would any other computer on your organization network.
Azure also allows you to load balance network traffic to a public address and a specific public port number across multiple virtual machines. Figure 6 shows an example with two web servers, both listening on private TCP port 3456 for incoming web traffic, in a configuration known as a load-balanced endpoint. Azure will randomly distribute the traffic between the nodes. You can have up 50 virtual machines behind a single load-balanced endpoint.
Figure 6 – Public and private addresses and ports with endpoints
In the example in Figure 6, the Azure Load Balancer balances incoming Internet traffic for the public IP address of the cloud service and TCP port 80 across the two virtual machines (10.2.0.4 and 10.2.0.5). In Figure 6, the first row is a load-balanced endpoint.
For a load-balanced endpoint, Azure randomly distributes the traffic between the configured virtual machines. You can have up 50 virtual machines for a load-balanced endpoint. When you add virtual machines to a load-balanced endpoint, you should also create an availability set.
Note that you can only load balance traffic from the Internet through an endpoint, which is mapped to the public IP address of the cloud service containing the virtual machine. Azure does not load balance between virtual machines for private IP addresses and port numbers.
For example, if your SharePoint farm is also for intranet access, users on your network will access the servers of the farm through their private IP addresses. If you need to balance the intranet load between the farm servers, you must deploy your own load balancer.
For workloads that require high availability, you should deploy more than one virtual machine for each particular role. By using multiple virtual machines, you can make sure that your application is available during local network reachability 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 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.
Figure 7 shows servers in availability sets that are in separate fault domains.
Figure 7 – Fault Domains and Availability Sets
Azure periodically updates the operating system of virtual machines 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, Azure ensures that the machines are assigned to different update domains.
Figure 7 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.
|The Azure subscriber is responsible for installing updates to the SharePoint farm servers. For more information, see "Patching and Updating" in this topic.|
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.
Scaling out is a fundamental, core principle of the 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 rather than fewer high-capacity servers.
Operating a SharePoint farm running in Azure is no different than operating a SharePoint farm anywhere else. Despite the power and agility Azure brings you, at the end of the day you still have a Windows Server, SharePoint, and their dependencies to manage. On-premises servers use a combination of Windows Server and SharePoint administration tools, or you can manage the whole farm using System Center. These same tools and procedures can be used when the farm is hosted in an Azure cross-premises virtual network.
For more information, see Plan for monitoring in SharePoint 2013.
You are still responsible for OS patching and you are still in full control of how and when that should happen. Patching and updating a SharePoint 2013 farm can be quite involved depending upon the topology. For more information, see Software updates overview for SharePoint 2013.
One area in which Azure can help is when testing major updates. Because you can create resources on-demand, you could create a duplicate environment within Azure and test your update or patching strategy and methodology prior to updating your production environment.
Backing up and recovery of SharePoint farms in Azure is very similar to an on-premises SharePoint farm. One thing to consider is that you should suffer no significant down-time due to hardware failure. Because Azure will automatically repair and redeploy your virtual machine, there is no action to take on your part. You will get hardware downtime that would be automatically repaired. Ensure that any customizations you perform or applications you deploy can handle this automatic recovery. Azure makes it very easy to deploy more virtual machines, making it possible to create a highly available farm.
Although you can use the Microsoft-supplied SharePoint 2013 Trial image in the Azure Virtual Machine Image Gallery for your SharePoint servers, you can also create your own image. You might want to do this if you have different requirements or wish to preload other software, such as SharePoint applications or anti-malware software.
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 and custom Windows settings. This disk image can then be used to create new Azure 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 Azure virtual machine that has been customized. To create a base image with SharePoint 2013 installed, it is recommended that you do not complete the entire SharePoint 2013 installation. This is due to incompatibilities with the SYSPREP tool, which is a required step to prepare the disk image.
The summarized steps to create the image are the following:
Create a new virtual machine based on the Windows Server 2012 R2 Datacenter image in the gallery.
Create a remote desktop connection to the new server.
On the new server, download the SharePoint 2013 installation files.
Install the SharePoint 2013 prerequisites.
Run the SharePoint 2013 software installation but do not complete the SharePoint Products and Technologies Configuration wizard. You must install SharePoint onto the operating system drive because data drives are not captured as part of the SysPrep process.
Install and configure the customizations, including SharePoint applications and anti-malware software.
Run SysPrep and shut down the virtual machine.
From the Azure Management portal, click Virtual Machines in the navigation pane, click Running in the Status column for the virtual machine, and then select Capture to run 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 How to Capture a Windows Virtual Machine to Use as a Template
Many of the operations you perform on virtual machines or virtual networks in Azure can be automated using PowerShell. For more information:
SharePoint Server Farm is a feature of the Microsoft Azure Preview Portal that automatically creates a pre-configured, Internet-facing SharePoint Server 2013 farm in the cloud for you.
This can save you a lot of time when you need a basic or high-availability SharePoint farm for a development and testing environment or if you are evaluating SharePoint Server 2013 as a collaboration solution for your organization. For more information, see SharePoint Server Farm.
You can also create a test environment that mimics an intranet SharePoint farm deployed in an Azure-based hybrid cloud.
For the instructions, see Set up a SharePoint intranet farm in a hybrid cloud for testing. You can use this test environment to see the performance of the SharePoint farm relative to your location on the Internet and for intranet-based SharePoint application development and testing.
For the detailed instructions to configure SharePoint with SQL Server AlwaysOn Availability Groups in Azure, see Deploying SharePoint 2013 with SQL Server AlwaysOn Availability Groups in Azure.
For more information about SharePoint 2013, see the following resources: