View
247
Download
0
Category
Preview:
Citation preview
Technical Deployment Considerations SharePoint 2013 on Windows Azure Virtual Machines
Prepared by
Mike TaghizadehSharePoint Architect
Microsoft Consulting Services (MCS)
November 2012
Page iTechnical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
List of Reviewers
Name Company
Steve Peschka Microsoft
Bill Baer Microsoft
Rahim Dossa Microsoft
Corey Sanders Microsoft
Mark Sorenson Microsoft
Chuck Heinzelman Microsoft
Durgaprasad Gorti Microsoft
Blair Shaw Microsoft
Paul Stubbs Microsoft
Steve Fox Microsoft
Dave Mackey Microsoft
Wayne Ewington Microsoft
Page iiTechnical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
Table of Contents
1 Introduction............................................................................................................1
1.1 Who should read this paper................................................................................................1
1.2 Today’s Delivery Models for Cloud Services........................................................................1
1.3 IaaS with SharePoint 2013 and Windows Azure Virtual Machines......................................2
1.4 Today’s State of Windows Azure Virtual Machines.............................................................3
2 Comparing SharePoint 2013 Cloud Deployment Options.........................................5
2.1 Microsoft Office 365............................................................................................................5
2.2 Windows Azure Virtual Machines.......................................................................................6
2.2.1 Shift in IT Focus.........................................................................................................................7
2.2.2 Faster Deployment...................................................................................................................7
2.2.3 Scalability..................................................................................................................................7
2.2.4 Metered Usage.........................................................................................................................7
2.2.5 Flexibility...................................................................................................................................8
2.3 Targeted Workloads for SharePoint 2013 on Windows Azure Virtual Machines................8
2.3.1 SharePoint Development, Staging and Test Environments.......................................................8
2.3.2 Public Internet Facing sites.......................................................................................................9
2.3.3 Building Proof of Concepts (POCs) and/or Pilots.......................................................................9
2.3.4 Full Trust Code Solutions........................................................................................................10
3 Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines....................................................................................................................11
3.1 SharePoint Virtual Machine Components.........................................................................11
3.1.1 Virtual Hard Disks (VHD).........................................................................................................11
3.1.2 Images....................................................................................................................................12
3.1.3 Disks........................................................................................................................................12
3.2 Server Role Considerations................................................................................................13
3.2.1 SharePoint 2013 Roles............................................................................................................13
3.2.2 Microsoft SQL Server for SharePoint 2013..............................................................................13
3.2.3 Active Directory Domain Controllers......................................................................................15
3.3 Hardware Considerations..................................................................................................15
3.3.1 Virtual Machine CPUs.............................................................................................................16
3.3.2 Virtual Machine RAM..............................................................................................................17
3.3.3 Virtual Machine Allocated Bandwidth....................................................................................18
3.3.4 Other Hardware Considerations.............................................................................................19
3.4 Software Considerations...................................................................................................19
Page iiiTechnical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
3.4.1 Using SysPrep..........................................................................................................................19
3.4.2 Windows Azure Caching.........................................................................................................20
3.4.3 FBA/SAML Authentication Considerations..............................................................................21
3.5 Storage Considerations.....................................................................................................21
3.5.1 Virtual Machine Available Storage Drives...............................................................................22
3.5.2 Virtual Machine Operating system Disk..................................................................................22
3.5.3 Virtual Machine Data disk.......................................................................................................23
3.5.4 Virtual Machine Temporary local disk.....................................................................................24
3.5.5 Storage Summary....................................................................................................................24
3.6 Load Balancing Considerations..........................................................................................25
3.7 Disaster Recovery..............................................................................................................26
3.8 Windows Azure Virtual Machines Virtual Network...........................................................27
3.9 Active Directory Considerations........................................................................................27
3.9.1 Hosting Active Directory Domain Controllers on Windows Azure Virtual Machines...............28
3.9.2 Connecting to On Premise Active Directory Domain Controllers............................................29
4 Looking Ahead......................................................................................................31
Page ivTechnical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
1 Introduction
Today, cloud computing can be defined as IT services that are deployed and delivered over the
Internet and are scalable on demand. Cloud computing is fundamentally changing the world of IT
today, impacting every role such as service providers and system architects to developers and end
users. IT services can range from basic infrastructure to complete applications. End users can
request and consume abstracted services without the need to manage or know about, what
constitutes those services. Today, cloud computing represents a major shift happening in IT today.
Windows Azure Virtual Machines are leading the way in cloud computing by delivering easy, open,
flexible, and powerful virtual infrastructure to customers. Windows Azure Virtual Machines
minimize the need for hardware, so organizations can reduce cost and complexity by building
infrastructure at scale, while having full control and streamlined management.
1.1 Who should read this paper
This paper is intended for IT professionals, architects and system administrators, to use this
information to decide if deploying Microsoft SharePoint 2013 on Windows Azure Virtual Machines is
the right choice for their organization today. It will cover the reasons why companies would want to
deploy on Windows Azure Virtual Machines and the technical limitations and boundaries that exist
in this approach.
1.2 Today’s Delivery Models for Cloud Services
Today, the industry recognizes three delivery models for cloud services, each providing a distinct
trade-off between control, flexibility and total cost:
Infrastructure as a Service (IaaS) such as Microsoft SharePoint 2013 on Windows Azure Virtual
Machines:
IaaS offers a virtual infrastructure that hosts Virtual Machines and existing applications. With IaaS,
the lower levels of the stack, such as networking and host servers, are managed by a vendor such as
Microsoft, while the customer is responsible for managing the Virtual Machine operating system
Page 1Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
through applications. IaaS provides a unique balance between manageability and infrastructure
abstraction.
Platform as a Service (PaaS):
PaaS is a Cloud application infrastructure that provides an on-demand application-hosting
environment. With PaaS, a platform vendor provides and manages everything from network
connectivity through runtime. The customer only needs to manage applications and data.
Software as a Service (SaaS) such as Microsoft Office 365:
SaaS is a Cloud services model where an application is delivered over the Internet and customers
pay on a per-use basis. SaaS provides the applications and abstracts all services from all underlying
components.
The diagram below displays the cloud services taxonomy and how it maps to the components in an
IT infrastructure. Microsoft Office 365 is an example of Software as a Service, shown in the last
column. SharePoint 2013 on Windows Azure Virtual Machines is an example of Infrastructure as a
Service as shown in the second column.
1.3 IaaS with SharePoint 2013 and Windows Azure Virtual Machines
Page 2Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
Infrastructure as a Service (IaaS) allows virtual infrastructure to host Virtual Machines and existing
applications. Hosted and managed in the cloud, the Windows Azure Virtual Machines offering
provides complete, reliable, and available infrastructure to support various on-demand application
and database workloads, such as Microsoft SQL Server and SharePoint deployments.
Windows Azure Virtual Machines enable organizations to create and manage their SharePoint
applications and infrastructure quickly. This allows full control and management over processors,
RAM, CPU ranges, and other resources of SharePoint Virtual Machines. SharePoint 2013 supports
various workloads in a Windows Azure Virtual Machine deployment.
Windows Azure Virtual Machines provide a full continuum of SharePoint deployments. As such,
organizations can easily set up and deploy SharePoint Server within Windows Azure, either to
provision infrastructure for a new SharePoint deployment or to expand an existing one. As business
workloads grow, organizations can rapidly expand their SharePoint infrastructure. Likewise, if
workload needs decline, organizations can contract resources on demand, paying only for what they
use.
Successful deployment of SharePoint 2013 on Windows Azure Virtual Machines requires solid
planning, especially considering the range of critical farm architecture and deployment options. The
insights and best practices outlined in this paper can help to guide decisions for implementing an
informed SharePoint 2013 deployment.
1.4 Today’s State of Windows Azure Virtual Machines
At the time of writing this paper, Windows Azure Virtual Machines is still in Preview and has not
moved to a General Availability. As of today, there is no Premier support for Windows Azure Virtual
Machines. This will change when Windows Azure Virtual Machines reaches General Availability. The
only support model currently for Windows Azure Virtual Machines is the online Forums where
customers, partners, MVPs and Microsoft experts are active and can post and respond to questions.
One such area is the Microsoft forums for Windows Azure Virtual Machines located at:
http://social.msdn.microsoft.com/Forums/en-US/category/windowsazureplatform,azuremarketplac
e,windowsazureplatformctp
Page 3Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
Also there are currently no Service Level Agreements (SLA) for Windows Azure Virtual Machines.
Areas such as uptime, high availability and other areas with the Virtual Machines that are hosting
SharePoint 2013 deployments, are not currently available in Windows Azure. However, they will be
available when Windows Azure Virtual Machines reaches General Availability.
Due to these reasons, customers are not encouraged to host Production deployments of SharePoint
on Windows Azure Virtual Machines today, and should wait until Windows Azure Virtual Machines
have gone to General Availability. However, customers are encouraged to build out their Production
like infrastructure on Windows Azure Virtual Machines today for Piloting, Development Scenarios,
Proof of Concept building and testing.
Page 4Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
2 Comparing SharePoint 2013 Cloud Deployment Options
In this section, we will look at Microsoft’s leading cloud hosting technology for SharePoint 2013
which is Office 365, and then we will discuss Windows Azure Virtual Machines benefits for
customers.
2.1 Microsoft Office 365
Organizations can reduce IT costs with Office 365, a cloud productivity solution that simplifies IT
management and provides virtually anywhere access to familiar Office tools, email, file sharing,
conferencing, and many more services. With deploying SharePoint 2013 on Office 365, customers
can create sites to share documents and information, making it easy to work together with
colleagues and customers.
By moving to Microsoft Office 365, the IT team does not have to worry about hardware
management, SharePoint management, upgrading, patching, high availability, Disaster Recovery and
Health Monitoring. This is done for them on Microsoft Office 365. With Windows Azure Virtual
Machines, the customer’s IT team is in charge of keeping the Virtual Machines updated and they are
also in charge of upgrading the applications running on Virtual Machines and setting up high
availability and disaster recovery for them. With Microsoft Office 365, these areas are automatically
taken care for customers where all the infrastructure and SharePoint roles are deployed on
Microsoft office 365.
Microsoft Office 365 is continuously being updated. This means that Office 365 gets continuously
updated and upgraded with newest patches, features and capabilities for underlying technologies
such as SQL Servers but also for the SharePoint roles and servers. Microsoft Office 365 offers
SharePoint 2013 customers reliability, supportability, availability and improved manageability and
reduction in time to go to Production.
The figure below shows control and cost efficiency between Microsoft Office 365 and deploying
SharePoint 2013 on Windows Azure Virtual Machines. As customers move to the left on X axis, they
have more control. As they move up the Y axis, it will be more cost effective for them.
Page 5Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
However there are various scenarios and workloads (described below), where deploying SharePoint
2013 environments on Windows Azure Virtual Machines might be a better choice than Microsoft
Office 365.
Also if Microsoft Office 365 or deploying on Windows Azure Virtual Machines does not meet the
customer’s requirements, then deploying a Private Cloud would be an alternative. For more
information on deploying Private Clouds, please see: http://www.microsoft.com/en-us/server-
cloud/private-cloud/default.aspx
2.2 Windows Azure Virtual Machines
Windows Azure offers additional flexibility and control over deploying Microsoft SharePoint 2013 on
customer’s own hardware and on their premise. If an organization wants to manage and control its
own SharePoint 2013 implementation while capitalizing on options for virtualization in the cloud,
Windows Azure Virtual Machines are ideal for this deployment. As SharePoint workloads grow, an
organization can rapidly expand infrastructure or as utilization decreases, customers can reduce the
scope of their deployment.
For more information on Windows Azure pricing, please see: http://www.windowsazure.com/en-
us/pricing/calculator/
Page 6Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
The following list mentions benefits of moving the on premise SharePoint 2013 deployment to
Windows Azure Virtual Machines:
2.2.1 Shift in IT Focus
Many organizations contract out the common components of their IT infrastructure and
management, such as hardware, operating systems, security, data storage, and backup—while
maintaining control of mission-critical applications, such as SharePoint Server. By delegating all non-
mission-critical service layers of their IT platforms to a virtual provider, organizations can shift their
IT focus to core, mission-critical SharePoint services and deliver business value with SharePoint
projects, instead of spending more time on setting up infrastructure.
2.2.2 Faster Deployment
Supporting and deploying a large SharePoint infrastructure can hamper IT’s ability to move rapidly
to support business requirements. The time that is required to build, test, and prepare SharePoint
servers and farms and deploy them into a production environment can take weeks or even months,
depending on the processes and constraints of the organization. Windows Azure Virtual Machines
allow organizations to quickly deploy their SharePoint workloads without capital expenditures for
hardware. In this way, organizations can capitalize on infrastructure agility to deploy in hours
instead of days or weeks.
2.2.3 Scalability
Without the need to deploy, test, and prepare physical SharePoint servers and farms, organizations
can expand and contract compute capacity on demand, at a moment’s notice. Windows Azure
Virtual Machines reduces upfront expenses and long-term commitments, enabling organizations to
build and manage SharePoint infrastructures at scale. Again, this means that these organizations can
innovate, experiment, and iterate in hours—as opposed to days and weeks with traditional
deployments.
2.2.4 Metered Usage
Page 7Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
Windows Azure Virtual Machines provide computing power, memory, and storage for SharePoint
scenarios, whose prices are typically based on resource consumption. Organizations pay only for
what they use, and the service provides all capacity needed for running the SharePoint
infrastructure.
2.2.5 Flexibility
Windows Azure Virtual Machines provide developers with the flexibility to pick their desired
language or runtime environment. Microsoft delivers a low-cost, low-risk path to the cloud and
offers cost-effective, easy provisioning and deployment for cloud reporting needs. Finally, with the
Windows Azure offering, users not only can move VHDs to the cloud, but also can copy a VHD back
down and run it locally or through another cloud provider, as long as they have the appropriate
license.
2.3 Targeted Workloads for SharePoint 2013 on Windows Azure Virtual
Machines
There are scenarios today for which deploying SharePoint 2013 on Windows Azure Virtual Machines
may be a better approach and option. The following workloads are scenarios in which deploying on
Windows Azure Virtual Machines might give customers more flexibility and options:
SharePoint Development, Staging and Test Environments
Public Internet Facing sites
Building Proof of Concepts (POCs) and/or Pilots
Full Trust Code Solutions with SharePoint
Below, we will discuss each of these workloads in more detail.
2.3.1 SharePoint Development, Staging and Test Environments
Today, more companies are looking for agile ways to create SharePoint applications and set up
SharePoint environments for development and testing. Fundamentally, they want to shorten the
time required to set up SharePoint application development projects, and decrease cost by
increasing the use of their test environments. Organizations can eliminate the capital cost for server Page 8
Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
hardware and achieve flexibility by greatly reducing the provisioning time required to create, set up,
or extend a SharePoint farm for a testing and development environment. IT can dynamically add and
remove capacity to support the changing needs of testing and development.
To fully utilize load-testing machines, organizations can configure SharePoint virtualized
development and test machines on Windows Azure Virtual Machines. This enables development
teams to create and test applications and easily migrate to on-premises or cloud production
environments without code changes. The same frameworks and toolsets can be used on premises
and in the cloud, allowing distributed team access to the same environment. Organizations can use
Windows Azure Virtual Machines for testing their code, their applications and other SharePoint
objects before moving them to their on premise Production deployments.
2.3.2 Public Internet Facing sites
Today companies want to create an Internet presence that is hosted in the cloud and is easily
scalable based on need and demand. They also want to create partner extranet websites for
collaboration and implement an easy process for distributed authoring and approval of website
content. Microsoft Office 365 supports .com namespace, but for dedicated hardware model,
anonymous or public sites are currently not supported. This is due to various reasons such as
Microsoft Office 365 has not adopted an anonymous model for hosting yet. This is an option that
customers get when deploying in Windows Azure Virtual Machines that they do not get with Office
365.
With SharePoint public-facing websites on Windows Azure Virtual Machines, organizations can scale
as traffic grows and pay only for what they use. Common tools, similar to those used on premises,
can be used for content authoring, workflow, and approval with SharePoint on Windows Azure
Virtual Machines. This enables customers to rapidly deploy and host their business websites on a
secure, scalable cloud infrastructure. They can also rapidly deploy the infrastructure for a partner
extranet site or customer Internet site using Windows Azure Virtual Machines.
2.3.3 Building Proof of Concepts (POCs) and/or Pilots
Page 9Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
As mentioned earlier in this document, Windows Azure Virtual Machines is currently in Preview and
has not been released to Production. Also currently there is no Premier Support for Windows Azure
Virtual Machines and there are no Service Line Agreements on areas such as uptime.
Due to these reasons, it is highly recommended that customers do not deploy their Production
environment on Windows Azure Virtual Machines. If customer needs to go to Production right now,
then it is recommended that they host their sites on Microsoft Office 365. However, as Windows
Azure Virtual Machines reaches General Availability, it will continue to be a great platform for doing
POCs and/or Pilots.
Due to the reasons above, Windows Azure Virtual Machines is a great candidate for building Proof of
Concepts and/or Pilots. This would allow the customer to build out an environment very close to
their future Production right now on Windows Azure Virtual Machines. Customers can then build
their Virtual Machines, setup their SharePoint sites and content and build out their farms as they
would do in Production. However, this is a Proof of Concept where the customer has an opportunity
to evaluate the features of Windows Azure Virtual Machines. Customer can then choose to keep this
Proof of Concept up and running, or take it down and build the SharePoint farm again when Virtual
Machines are is in General Availability.
2.3.4 Full Trust Code Solutions
Some customers build SharePoint sites that include custom code that integrates or is built on top of
SharePoint 2013. These custom code require permissions to be able to run and execute. These
customers may write code that heavily use the SharePoint Object Model. Some of these object
model calls can be in areas such as custom timer jobs, custom claims providers and other code that
performs administration tasks. These type of code are not currently supported for Office 365.
Therefore, deploying these custom solutions with SharePoint, would be appropriate using Windows
Azure Virtual Machines.
Also some customers may need to write code that will need Full Trust. Full trust allows developers
to execute native code, to read from the Registry and Windows Event Log, and to read and write to
files outside of the SharePoint’s virtual directory. In short, with full trust one web application could
delete the entire contents of another web application. This can be dangerous and is something that
requires very detailed attention by developers. These type of code are also not currently supported
Page 10Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
for Office 365. Therefore, deploying these custom solutions with SharePoint, would also be
appropriate using Windows Azure Virtual Machines.
SharePoint 2013 also introduces a Cloud App Model that enables customers to create apps. Apps for
SharePoint are self-contained pieces of functionality that extend the capabilities of a SharePoint
website. An app may include SharePoint components such as lists, workflows, and site pages, but it
can also surface a remote web application and remote data in SharePoint. Apps have no custom
code that runs on the SharePoint servers. Instead, all custom logic moves "up" to the cloud or
"down" to client computers. Customers should look into the new Could App Model for SharePoint.
However if they have requirements that the Cloud App Model cannot satisfy, (such as the need for
Full Trust code), they can then run their own applications allowing Full Trust Code to be deployed on
Windows Azure Virtual Machines.
3 Deployment Considerations for SharePoint 2013 on Windows Azure
Virtual Machines
In this section, we will dive into the various boundaries, limitations and considerations when
deploying SharePoint 2013 on Windows Azure Virtual Machines.
3.1 SharePoint Virtual Machine Components
A SharePoint 2013 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 blobs in a storage account in Windows Azure Virtual Machines. Customers can use
platform images that are available in Windows Azure to create virtual machines or they can upload
their own SharePoint 2013, Microsoft SQL Server or Active Directory Domain controller images
(more on this later in the paper) to create customized Virtual Machines. Customer can easily create
new Virtual Machines from existing disks.
3.1.1 Virtual Hard Disks (VHD)
Page 11Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
A VHD file is stored as a page blob in Windows Azure storage and can be used for creating
SharePoint images (or SQL Server or Active Directory Domain Controllers), operating system disks, or
data disks in Windows Azure Virtual Machines. Customers can upload a VHD file to Windows Azure
and manage it just as they would any other page blob.
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 Virtual Machines. Therefore, it is also required for SharePoint that
VHD drives be in fixed format.
3.1.2 Images
A SharePoint image is a VHD file that customers can use as a template to create a new Virtual
Machine. Customers can use images from the Image Gallery to create virtual machines or they can
create their own images.
3.1.3 Disks
Customer can use disks in different ways with a Virtual Machine in Windows Azure. An operating
system disk is a VHD that customers can use to provide an operating system for a SharePoint Virtual
machine. A data disk is a VHD that customers can attach to a SharePoint Virtual Machine to store
application data. Customers can create and delete disks whenever they need to.
SharePoint customers can choose from multiple ways to create disks depending on the needs of
their application. A typical way for customers to create a data disk is to attach an empty disk to a
Virtual Machine and a new data disk is created for them. They can create a disk by using a VHD file
that has been uploaded or copied to a storage account that is related to their subscription.
There are 3 types of disks that can be used by a SharePoint Virtual Machine:
1. Operating System Disk
2. Temporary Storage Disk
3. Data Disks
We will discuss these later in this chapter and their storage recommendations.
Page 12Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
3.2 Server Role Considerations
As with deploying SharePoint 2013 on premise at a customer site, there are considerations that have
to be made when deploying on Windows Azure Virtual Machines. It is important to understand
which SharePoint roles, as well as other associated technologies that SharePoint needs, have to be
located on which environment.
3.2.1 SharePoint 2013 Roles
For deploying SharePoint 2013 products, customers will need to have one to many Web Front Ends
(WFE) and one to many Application Servers in their farm deployment (or one machine can host both
WFE and Application Servers for demo and testing purposes). These roles have to be located in the
same farm, datacenter and Local Area Network as required by SharePoint. When deploying to
Windows Azure Virtual Machines, this does not change. Customers are still required to have one to
many Web Front Ends and one to many Application Servers. Both of these roles can be on the same
Virtual Machine or spread into multiple Virtual Machines. The deployment options depend on the
size of the deployment, the technical requirements, numbers of users needing to access the farm
and other factors. Typical SharePoint farm deployments are documented here on TechNet for
SharePoint 2013: http://technet.microsoft.com/en-us/library/cc263199(v=office.15).aspx
Customers can deploy SharePoint 2013 in the following configurations on Windows Azure Virtual
Machines:
Single Virtual Machine with built-in database
Server farm with a single Virtual Machine in the farm
Server farm with multiple Virtual Machines in the farm
Each of Virtual Machines must also be using 64-bit edition of Windows Server 2008 R2 Service Pack
1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 Standard
or Datacenter.
3.2.2 Microsoft SQL Server for SharePoint 2013
SharePoint 2013 relies on Microsoft SQL Server for its data storage. SharePoint 2013 supports the
following versions of SQL Server:
Page 13Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
The 64-bit edition of Microsoft SQL Server 2012
The 64-bit edition of SQL Server 2008 R2 Service Pack 1
Also at this time, Windows Azure SQL Databases are not supported to be used by customer’s
SharePoint 2013 Virtual Machines, therefore customers must setup their own SQL Virtual Machines
to connect to their SharePoint 2013 Virtual Machines.
For customer’s SharePoint 2013 deployment, they will need to have their SQL servers also located
on Windows Azure Virtual Machines. It is not supported to have the SQL Servers on premise or in
another datacenter, talking to the SharePoint Virtual Machines on Windows Azure.
Therefore, all SharePoint Virtual Machines in the Windows Azure Virtual Machines farm should be in
the same affinity group and be on the same VNET. Also Microsoft, does not support a wide area
network (WAN) topology in which a server that is running SQL Server is deployed remotely from
other components of the farm over a network that has latency greater than 1 millisecond (ms). This
topology has not been tested and is not supported. For more information, please see:
http://support.microsoft.com/kb/971160/EN-US
In SharePoint 2010, Stretched Farms were supported with caveats. However, in SharePoint 2013,
Microsoft does not support building out a stretched farm. Therefore, all servers must reside in the
same datacenter. All servers that belong to a server farm, including database servers, must
physically reside in the same datacenter.
Due to this requirement, customers will need to have a SQL Server Virtual Machine(s) created in
Windows Azure Virtual Machines. As mentioned above, SQL Server can be on the same Virtual
Machine as SharePoint Web Front Ends or Application Servers, but this is only recommended for
development or testing purposes. The SQL Server Virtual Machine(s) should be using 64-bit edition
of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or datacenter or the 64-bit
edition of Windows Server 2012 Standard or datacenter.
Installing and running SQL Server into Windows Azure Virtual Machines for SharePoint is a key
scenario that Microsoft is delivering and supporting. From a compatibility point of view for
SharePoint customers, running SQL Server in a Windows Azure Virtual Machines is the same as
Page 14Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
running SQL Server hosted in a Virtual Machine on premises. SharePoint customers will typically
create a SQL server using pre-built Virtual Machine images from the Windows Azure Image Gallery,
or they can build their own SQL Server Virtual Machine.
The figure below shows key benefits for deploying SQL Server in Windows Azure Virtual Machines to
support the SharePoint 2013 deployment.
At the time of writing this paper, there is a SQL Server image that is available from the Windows
Azure Gallery that customers can use with their SharePoint deployments. For more information,
please see: http://msdn.microsoft.com/en-us/library/windowsazure/jj156003.aspx
3.2.3 Active Directory Domain Controllers
For the customer’s SharePoint 2013 deployment on Windows Azure Virtual Machines, there are
considerations to be made on where the customer’s Active Directory Domain Controllers should
reside. For recommendations on this, please see later section in this paper called Authentication.
3.3 Hardware Considerations
When deploying SharePoint 2013 on Windows Azure Virtual Machines, there are various hardware
configurations that are possible and available to the customer. In this section, we discuss the
available hardware and other areas to assist customers to deploy Virtual Machines with SharePoint
2013.
Page 15Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
The table below highlights the deployment options customers have when creating their Virtual
Machines. When they create a Virtual Machine in their SharePoint farm, they can choose from five
sizes:
SharePoint Virtual Machine
Extra
Small
Medium
Large
Extra Large
Customers should keep in mind that these sizing capabilities are for the current Preview of Windows
Azure Virtual Machines and they might expand over time. For a complete list of configuring Virtual
Machine sizes on Windows Azure today, please see:
http://msdn.microsoft.com/en-us/library/windowsazure/ee814754.aspx
Each of these sizes has various properties such as:
1. Number of CPUs
2. Memory allocated to each Virtual Machine
3. Temporary Local Storage
4. Allocated Bandwidth for the Virtual Machine
5. Maximum Data Disks
We will now talk more about these with respect to the SharePoint deployment.
3.3.1 Virtual Machine CPUs
For each of the SharePoint Virtual Machine sizes that the customer decides to deploy, there are
number of CPUs available to them. The following mentions the number of CPUs and the CPU power
available to customers for their SharePoint Virtual Machine deployment size:
SharePoint Virtual Machine Number of CPUs CPU Power
Extra Small Shared 1.6 MHz
Small 1 1.6 MHz
Page 16Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
Medium 2 1.6 MHz
Large 4 1.6 MHz
Extra Large 8 1.6 MHz
3.3.2 Virtual Machine RAM
For each of the SharePoint Virtual Machine sizes that the customer decides to deploy, there is a
specific amount of RAM that is given to that Virtual Machine. The table below mentions the amount
of RAM available today in Windows Azure Virtual Machines, to a typical SharePoint Virtual Machine
deployment size:
SharePoint Virtual Machine Memory
Extra Small 768 MB
Small 1.75 GB
Medium 3.5 GB
Large 7 GB
Extra Large 14 GB
The following are recommendations for deploying SharePoint 2010 and 2013 SQL Servers, WFE or
Application Servers with respect to installation scenarios, deployment scale and needed RAM.
Customers should consider the table below when deciding to choose a Virtual Machine size for their
SharePoint Farm.
SharePoint 2013 Hardware Recommendations for WFE and Application Servers
The values in the following table are minimum values for installations on a single server with a built-
in database and for web and application servers that are running SharePoint 2013 in a multiple
server farm installation.
For information about the deployment types that are used in this table, see the SharePoint 2013:
Deployment model. Customers can download this model from the Install and deploy SharePoint
2013 (IT pros) resource center. For more information on farm sizes, see Capacity management and
sizing for SharePoint Server 2013.
Page 17Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
Installation Scenario Deployment type and scale RAM Processor Hard Disk Space
Single server with a built-in database or single server that uses SQL Server
Development or evaluation installation of SharePoint Foundation 2013
8 GB 64-bit, 4 cores
80 GB for system drive
Single server with a built-in database or single server that uses SQL Server
Development or evaluation installation of SharePoint Server 2013
24 GB 64-bit, 4 cores
80 GB for system drive
Web server or application server in a three-tier farm
Pilot, user acceptance test, or production deployment of SharePoint Server 2013
12 GB 64-bit, 4 cores
80 GB for system drive
SharePoint 2013 Hardware Recommendations for SQL Servers
The requirements in the following table apply to database servers in a SharePoint 2013
environments.
Component Minimum requirementProcessor 64-bit, 4 cores for small deployments
64-bit, 8 cores for medium deployments
RAM 8 GB for small deployments
16 GB for medium deployments
3.3.3 Virtual Machine Allocated Bandwidth
For each of the SharePoint Virtual Machine sizes that the customer decides to deploy, there will be
allocated bandwidth to that Virtual Machine. Allocated bandwidth refers to the amount of
bandwidth on the network card for service requests and it is measured in megabits per second (Mb).
Page 18Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
The table below mentions the available bandwidth for each SharePoint Virtual Machine deployment
size:
SharePoint Virtual Machine Allocated
Bandwidth (Mb)
Extra Small 5
Small 100
Medium 200
Large 400
Extra Large 800
3.3.4 Other Hardware Considerations
The following are not supported in a Virtual Machine on Windows Azure:
- Multiple IP addresses in a Virtual Machine
- 32 Bit Applications in a Virtual Machine
- Static IP addresses:
o Dynamic addresses must therefore be used instead, which requires that customers
create a Windows Azure Virtual Network. Dynamic addresses are effectively
become static once they are assigned.
3.4 Software Considerations
When deploying SharePoint Virtual Machines on Windows Azure, there are various considerations
that customer has to be aware of with respect to software.
3.4.1 Using SysPrep
Some customers want to save time and want to copy their SharePoint Virtual Machines from their
environments onto Windows Azure Virtual Machines. There are things to know when wanting to just
pick up an image and moving it to Windows Azure Virtual Machines using SysPrep.
Page 19Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
The System Preparation (SysPrep) tool is used to change Windows images from a generalized state
to a specialized state, and then back to a generalized state. SysPrep can be used to prepare an
operating system for disk cloning and restoration via a disk image.
However, using SysPrep with a SharePoint image is supported only if PSConfig has not been ran yet.
One of the reasons for this, is that the NETBIOS name of the machine is recorded in the SharePoint
Configuration Database when the PSConfig tool runs (or using PowerShell). If the customer does a
SysPrep following running PSConfig and moves the image to Windows Azure Virtual Machines with a
new name, the record in the configuration database is not updated therefore this will fail.
SysPrep is only supported in the following scenarios with SharePoint:
SharePoint Products and Technologies Configuration (PSConfig) Wizard has not yet been run
after the SharePoint installation.
SharePoint has not been installed in Standalone mode (Database and SharePoint on the
same box). Standalone installation is unsupported due to configuration changes made
during install that will not be properly adjusted by SysPrep.
For more information, please see: http://support.microsoft.com/kb/2728976
3.4.2 Windows Azure Caching
The Virtual Machine operating system disk and data disks have 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 write operations for operating system disks.
Therefore, when installing SharePoint on the operating system disk (C Drive), since this caching
mechanism is on, the installation might be a bit slower. So it is recommended that customers turns
off this caching on the C drive, before installing SharePoint 2010 on their Virtual Machines. For more
information on this, please see:
http://msdn.microsoft.com/en-us/library/windowsazure/jj156003.aspx
Page 20Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
3.4.3 FBA/SAML Authentication Considerations
Windows Azure Virtual Machines have built in load balancers that customers can use to load
balance their SharePoint Virtual Machines (more details are provided below in the paper on Load
Balancing options). SharePoint 2010 (such like SharePoint 2013) allows authentication through
various forms such Forms Based Authentication and using SAML tokens. These two authentication
methods require “sticky” sessions from the load balancer. As of today, Windows Azure Virtual
Machines load balancing mechanism does not support Sticky Sessions so this will be a problem for
SharePoint 2010 deployments. Sticky session refers to a load balancer feature to route the requests
for a particular session to the same physical machine that serviced the first request for that session.
In SharePoint 2013, this is not a problem, as SharePoint 2013 does not require sticky sessions with
Forms Based Authentication or SAML authentication.
These are some solutions available today to customers who have Forms Based Authentication
and/or SAML Authenticating with their SharePoint 2010 deployments on Windows Azure Virtual
Machines:
1 They can stop using Forms Based Authentication or SAML Authentication and use
Windows Authentication.
2 They can deploy their entire SharePoint 2010 farm on a single server so a load balancer
is not required. This option would not be ideal for a Production deployment
Again this limitation does not exist with SharePoint 2013 using Forms Based Authentication or SAML
Authentication.
3.5 Storage Considerations
When deploying SharePoint 2013 on Windows Azure Virtual Machines, there are various storage
configurations and sizing that is available to customers. Also, there are various components that
make up a SharePoint Virtual Machine storage requirements on Windows Azure Virtual Machines.
Customers should read the following sections to know the options available to them.
Page 21Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
3.5.1 Virtual Machine Available Storage Drives
As mentioned above, SharePoint customers can use disks in different ways with their SharePoint
Virtual Machines in Windows Azure. For example, an operating system disk is a VHD that customers
can use to provide an operating system for a SharePoint Virtual machine. A data disk is a VHD that
customers can attach to a SharePoint Virtual Machine to store application data. For more
information, please see the earlier chapters in this paper.
The following diagram shows the disks that are used by a SharePoint Virtual Machine.
We will discuss each of these now in these three sections.
3.5.2 Virtual Machine Operating system Disk
Every SharePoint Virtual Machine has one attached operating system disk. Customers can upload a
VHD that can be used as an operating system disk, or they can create a SharePoint Virtual Machine
from an image and a disk is created for them. This disk is a copy of a source VHD file and the new
copy is registered as an operating system disk.
An operating system disk is a VHD that they 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. This
Page 22Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
drive is Persistent. This drive will also have caching enabled by default which can be configured later.
See caching section below for more information.
3.5.3 Virtual Machine Data disk
A data disk is a VHD that can be attached to a running Virtual Machine to persistently store
application data. Customers can upload and attach a data disk that already contains data to the
Virtual Machine, or they can use the Windows Azure Management Portal to attach an empty disk to
the machine. Data disks are registered as SCSI drives and are labeled with a letter that customer can
choose. This drive is Persistent.
The maximum size of a data disk is 1 TB and customers are limited in the number of disks that they
can attach to a Virtual Machine based on the size of the machine. The following table lists the
number of attached disks that are allowed for each size of a SharePoint Virtual Machine.
SharePoint Virtual Machine Maximum data disks
Extra Small 1
Small 2
Medium 4
Large 8
Extra Large 16
These drives are good candidates to be used for SQL Server Virtual Machine(s) in a SharePoint farm
to store its data. So the biggest deployment of SharePoint SQL Servers can be up to 16 TB. However
customers have to configure SQL Server to be able to use multiple and separate storage and drives
for its storage, for their SharePoint deployments. If they want to take advantage of 16 TB, then they
have to store SQL databases across these 16 Windows Azure Virtual Machines drives. This drive will
have caching enabled by default which can be configured later. See caching section below for more
information.
So customers can have up to 16 VHDs attached to their largest Virtual Machine (Extra Large size)
that they are building with SharePoint on Windows Azure Virtual Machines. In this case, customers
are really creating 16 Azure drives, where each drive is a page blob in Windows Azure Virtual Page 23
Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
Machines. Each blob has a maximum of 500 Input/Output per seconds (IOPS). So customers get 16
blobs where each blob has 1 TB size limitation and maximum of 500 Input/Output per seconds.
3.5.4 Virtual Machine Temporary local disk
Each Virtual Machine that customers 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. The
applications and processes running in the VM can use this disk for transient and temporary storage.
The following table lists the size of this temporary local storage that are allowed for each size of a
SharePoint Virtual Machine.
SharePoint Virtual Machine Temporary Local Storage
Extra Small 20 GB
Small 50 GB
Medium 100 GB
Large 200 GB
Extra Large 400 GB
This drive is non-Persistent. Data on this disk is not permanently stored and customers should not
use this disk to store data for their application.
3.5.5 Storage Summary
So here we have summarized the storage that is available today for SharePoint Virtual Machines in a
SharePoint farm on Windows Azure Virtual Machines:
Available Disk Name Drive Letter: Maximum Storage:
Operating System Disk C 127 GB
Temporary Storage Disk D 400 GB
Data Disks Customer Defined Up to 16 TB
Page 24Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
3.6 Load Balancing Considerations
Customers deploying a SharePoint 2013 farm in Windows Azure Virtual Machines need to think
about load balancing their Virtual Machines. This is for SharePoint 2013 deployments that are more
than one server. Windows Azure Virtual Machines offers a very flexible Load Balancing mechanism.
SharePoint 2013 Virtual Machines that are created in Windows Azure Virtual Machines can
automatically communicate with other Virtual Machines in the same cloud service or in the same
virtual network. However, customers might want to harness the power of multiple virtual machines
to handle high-volume requests or for High Availability. To do this, customers can add an endpoint
to their SharePoint Virtual Machine, define it as a load-balanced endpoint, and then add other
Virtual Machines to share it.
Windows Azure Virtual Machines takes the inbound traffic to that endpoint and shares it among the
Virtual Machines. External communication with Virtual Machines occurs through endpoints. These
endpoints are used for different purposes, such as load-balanced traffic or for direct Virtual Machine
connectivity. Customers define endpoints that are associated to specific ports and are assigned a
specific communication protocol. Each endpoint defined for a Virtual Machine is assigned a public
and private port for communication. The private port is defined for setting up communication rules
on the Virtual Machine and the public port is used by Windows Azure to communicate with the
virtual machine from external resources.
For more information on Windows Azure Virtual Machines load balancing, please see:
http://www.windowsazure.com/en-us/manage/windows/common-tasks/how-to-load-balance-
virtual-machines/
Below are some considerations when using Windows Azure Virtual Machines load balancing:
1 Windows Azure Virtual Machines currently only supports Round Robin for its load
balancing configuration.
2 It does not support affinity (sticky) sessions. This is an issue for SharePoint 2010 but not
for SharePoint 2013. See above for more information.
For customers wanting to use their on premise load balancing, this configuration is not supported
today. So customers who have their own on premise hardware or software load balancing products
Page 25Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
are not supported to use them with their SharePoint Virtual Machines. This configuration is
currently not supported with Windows Azure Virtual Machines.
3.7 Disaster Recovery
Disaster Recovery is defined as the ability to recover from a situation in which a datacenter that
hosts SharePoint becomes unavailable. The disaster recovery strategy that customers choose for
SharePoint must be coordinated with the disaster recovery strategy for the related infrastructure,
including Active Directory domains and Microsoft SQL Server. SharePoint 2013 supports both
database mirroring and log shipping for disaster recovery. For more information, please see:
http://technet.microsoft.com/en-us/library/ff628971(v=office.15).aspx
Windows Azure Virtual Machines support for high availability and/or disaster recovery is currently
limited to Database Mirroring and Log Shipping. Currently, AlwaysOn Failover Cluster Instances are
not supported. However, Windows Server Failover Cluster to support Availability Groups (non-
shared Storage) is currently supported. It is not supported for other uses.
When Windows Azure Virtual Machines reaches General Availability, more High Availability options
for SharePoint Virtual Machines will be added. These limitations should be considered by
customers, when planning a highly available SharePoint environment in Windows Azure Virtual
Machines.
For SharePoint 2010, customers can see which databases support log shipping and/or data mirroring
here: http://technet.microsoft.com/en-us/library/ff628971.aspx#Section3
For SharePoint 2013, customers can see which databases support log shipping and/or data mirroring
here: http://technet.microsoft.com/en-us/library/ff628971(v=office.15).aspx
Windows Azure Virtual Machines supports database mirroring and log shipping the SQL Server
content. This allows customers to build farms that can be recovered in a very quick manner by using
these methods when disaster occurs. However, SQL fail over clustering is currently not supported.
Also, using SQL Server 2012’s new feature called AlwaysOn is also currently not supported. So the
recommendation today would be to provide disaster recovery through Log Shipping and Database
Mirroring.
Page 26Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
3.8 Windows Azure Virtual Machines Virtual Network
Windows Azure Virtual Network enables customers to create secure site-to-site connectivity, as well
as protected private virtual networks in the cloud for their SharePoint 2013 deployments. They can
specify the address space that will be used for both their virtual network and the virtual network
gateway. When building a SharePoint 2013 farm on Virtual Networks, it is highly recommended that
customers are familiar with Windows Azure Virtual Machines Virtual Network, as this is a required
process for setting up the SharePoint Farm.
One important note to know when setting up the SharePoint farm in Windows Azure Virtual
Machines using Virtual Networks, is that modifying or making changes to the Virtual Network is
complex. For this release, it can be difficult to makes changes after the SharePoint Virtual Network
has been created and customer has deployed role instances and Virtual Machines. After this stage of
deployment, customers cannot easily modify the baseline network configuration and many values
cannot be modified without pulling back roles and Virtual Machines and then reconfiguring. This can
be a very time consuming effort if customers have large SharePoint farms already deployed on
Windows Azure Virtual Machines.
For tutorials on how to setup and configure the Windows Azure Virtual Machines Virtual Network,
please see: http://www.windowsazure.com/en-us/manage/services/networking/
For more information on using Windows Azure Virtual Machines available networks (such as Virtual
Network, Name Resolution and Connect), please see:
http://msdn.microsoft.com/en-us/library/windowsazure/gg433091.aspx
3.9 Active Directory Considerations
For customer’s SharePoint 2013 deployments on Windows Azure Virtual Machines, there are
considerations that need to be made with respect to authentication with Active Directory (AD).
Customers need to decide where they would want their AD Domain Controllers located to be used
by their SharePoint 2013 Virtual Machines.
Page 27Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
There are two options available for customers who are running their SharePoint Virtual Machines on
Windows Azure Virtual Machines and need to decide where to host their AD Domain Controllers:
1. Hosting Active Directory Domain Controllers on Windows Azure Virtual Machines
2. Connecting to On Premise Active Directory Domain Controllers
(a) For this scenario, customers should keep in mind the latency that is involved
here when connecting to their on premise Active Directory. This option might
have performance and cost impact.
SharePoint Virtual Machines require Windows Server Active Directory but have no dependency on
the on-premises network or the corporate Windows Server Active Directory. In this case, deploying
an isolated forest on Windows Azure Virtual Machines to meet the SharePoint server’s requirements
is also an option. Again, deploying network applications that do require connectivity to the on-
premises network and the corporate Active Directory is also supported.
Please refer to this article on various details around pros and cons of deploying Windows Server
Active Directory on Windows Azure Virtual Machines
http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx
3.9.1 Hosting Active Directory Domain Controllers on Windows Azure Virtual Machines
Customers can host their Active Directory Domain Controllers on Windows Azure Virtual Machines.
For this, they can have a Virtual Machine that can act as the AD Domain Controller for the
SharePoint farm.
The fundamental requirements for deploying Windows Server Active Directory on Windows Azure
Virtual Machines differ very little from deploying it in Virtual Machines (and, to some extent,
physical machines) on premises. For example, in the case of Windows Server AD DS, if the domain
controllers (DCs) that customers deploy on Windows Azure Virtual Machines are replicas in an
existing on-premises corporate domain/forest, then the Windows Azure Virtual Machines
deployment can largely be treated in the same way as customers might treat any other additional
Windows Server Active Directory site. That is, subnets must be defined in Windows Server AD DS, a
site created, the subnets linked to that site, and connected to other sites using appropriate site-
links.
Page 28Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
Deploying Windows Server Active Directory DCs on Windows Azure Virtual Machines is subject to
the same guidelines as running DCs on premises in a Virtual Machine. Running virtualized DCs is a
safe practice as long as guidelines for backing up and restoring DCs are followed.
There are some advantages to deploying AD Domain Controllers on Windows Azure are:
- Customers can provide high availability for AD servers by using the load balancing
capabilities of Windows Azure Virtual Machines.
- Customers can more simply deploy a set of federated applications to employees and
partners without the complexities and requirements inherent in deploying AD in a perimeter
network.
- Customers can deploy corporate domain controllers alongside AD on Windows Azure Virtual
Machines, which provides additional guarantees of service availability in the event of
unforeseen failures such as natural disasters.
For guidelines for deploying Windows Server Active Directory on Windows Azure Virtual Machines
for authentication with the SharePoint 2013 Virtual Machines, please see:
http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx
For more information on installing a new Active Directory forest on Windows Azure Virtual
Machines for authentication with the SharePoint 2013 Virtual Machines, please see:
http://www.windowsazure.com/en-us/manage/services/networking/active-directory-forest/
For instructions on how to install a Replica Active Directory Domain Controller in Windows Azure
Virtual Machines, please see: http://www.windowsazure.com/en-us/manage/services/networking/replica-domain-controller/
3.9.2 Connecting to On Premise Active Directory Domain Controllers
Many enterprises prefer to integrate their Windows Azure Virtual Machines SharePoint deployment
with their on premise Active directory. This will help them ensure that there is no identity replication
in other locations.
Page 29Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
Customers can extend their on premise AD with Active Directory Federation Services (ADFS). Since
SharePoint 2013 supports claims based authentication, they can then leverage ADFS as an identity
provider for their SharePoint 20103 Virtual Machines.
For more information on how to configure the SharePoint Virtual Machines in Windows Azure
Virtual Machines to authenticate using ADFS, please see the following articles:
http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx
http://www.windowsazure.com/en-us/manage/services/networking/cross-premises-connectivity/
http://www.windowsazure.com/en-us/manage/services/networking/add-a-vm-to-a-virtual-
network/
Page 30Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
4 Looking Ahead
As mentioned in this paper, at the current time, Windows Azure Virtual Machines are in a Preview
and has not moved to reached General Availabit (GA)y.. Once Windows Azure Virtual Machines
reache, customers can expect full support by Microsoft Premier. Customers can call Premier and
open tickets and get help through the regular Microsoft channels. At GA, Windows Azure Virtual
Machines also will have an SLA and customers can deploy their full SharePoint 2013 production
environments on Virtual Machines with confidence.
Page 31Technical Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines
Recommended