sharepoint 2013 on windows azure infrastructure …€¦ · 1 sharepoint 2013 on windows azure...
TRANSCRIPT
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.