Spark the future.

May 4 – 8, 2015Chicago, IL

Exchange on IaaSConcerns, Tradeoffs, and Best PracticesJeff MealiffePrincipal Program ManagerOffice 365 Customer Experience

BRK3178

AgendaStarting with the basicsSupportabilityThis isn’t for everyone (a moment of clarity)Planning for an IaaS deploymentWrap up

Starting with the basics

IaaS 101What is Infrastructure as a Service (IaaS)?ServersStorageNetworkPlatform services

Many competitive offeringsMicrosoft AzureAmazon Web ServicesGoogle Compute EngineOther “traditional” hostersSome virtualized, some physical

Why do Exchange customers want IaaSTypical IaaS requirementsCapacity on demand / ElasticityPartial outsourcingAdditional sites with minimal investmentCloud is coolCost savings

Specific scenariosDev/test/pilotHybrid infrastructureDAG witness placementStretched DAGUnplanned disaster recoveryAll-in

Supportability

Supportability concernsExchange historically not tested on IaaS platformsHypervisor may not be supportedStorage may not meet performance requirementsPotential issues with outbound mail

All other supportability requirements must be met

Announcing…

Azure supportabilityAs of today, we support three Exchange 2013 deployment scenarios on Azure IaaS VMs:1. Non-production (dev/test)2. Cluster witness for stretched DAGs

http://aka.ms/dagazurewitness

3. Production, using Azure Premium Storage

Updated support statement: http://aka.ms/e2013virt

Azure supportability detailsProduction support is specific to Exchange 2013 (and later)Azure Premium Storage required for production deployments: all Exchange databases/logs must be stored on premium storage drivesAs with other Microsoft workloads, licensing is handled via Licensing Mobility through Software Assurancehttp://aka.ms/LicenseServerVirthttp://aka.ms/LicenseMobilityThroughSA

AWS supportabilityAWS runs an unsupported hypervisorSVVP doesn’t apply to IaaS providers like AmazonWe still use the SVVP list to define hypervisors that are supported for Exchange deployment

Standard guidance on unsupported virtualization platforms applies herehttp://support.microsoft.com/kb/897615Customers may be asked to reproduce issues on a supported platform

Lack of full support means additional risk – you must plan for this & mitigate

This isn’t for everyone

This isn’t for everyoneFirst and best option: Exchange Online (Office 365)On-premises deployment on physical hardware may be dramatically cheaper than IaaShttp://aka.ms/preferred

We want customers to have choice and appropriate levels of deployment flexibility

The future of Exchange in the cloud is clearOFFICE 365 IS OUR FOCUSInvestments target Office 365New features & capabilities delivered to Exchange Server where it makes sense

Exchange on Azure is not “Exchange in the cloud”

Using IaaS VMs for dev/testIaaS is great for quickly spinning up resources to try something outInternet connectivity is easy, large amount of flexibility for internal componentsCan even test DR scenarios by bringing site connections down

DAG

IaaS Virtual Machines

Placing hybrid infrastructure on IaaS VMsExtend AD to Azure, deploy AAD Sync, ADFS machines on Azure VMCan now move Exchange 2013+ “hybrid role” to AzureOn-premises Exchange organization Office 365 Active

Directory synchronization

Exchange 2013

Office 365

User, contacts, & groups via Azure AD Sync

Secure mail flow

Mailbox data via Mailbox Replication Service (MRS)

Sharing (free/busy, Mail Tips, archive, etc.)

DAG witness on IaaS VMsSupport announced earlier this yearhttp://aka.ms/dagazurewitness

Quick & easy deployment of 3rd site for automatic datacenter failoverNot “Azure Cloud Witness”Requires separate file server & DC, or combine both (not recommended)Multi-site VPN configuration required

Stretching a DAG into IaaSCustomers with a single datacenter might consider stretching a DAG into an Azure regionProvides similar benefits as deploying to a second on-premises datacenterSizing is critical, consider network impactsStrongly consider ExpressRoute as a better network solutionDesign & ops may be challenging due to limits on VM sizes

Going all-inPlacing all production Exchange infrastructure in IaaS is possibleUnderstand the benefits, and what is not “outsourced”All OS & app level ops must still be performed, some work must happen through new interfacesNetwork infrastructure may need significant changesExchange Online is likely a much better alternative

Planning an IaaS deployment

Planning is criticalOrder of deployment requires that a good plan is created firstSimple deployments can be very flexible, less planning requiredExchange infrastructure requirements will often result in a more complex Azure deploymentGo through normal sizing process, use the calculatorRemember that you are virtualizing on Hyper-VPlan to automate deployment & config to enable “elasticity” in the future

Namespace design for IaaSPreferred architecture suggests unbound namespaceWith IaaS, proxy traffic runs on provider’s networkBe aware of per-VM bandwidth limitationsBound is also an option…

Round robin between # of VIPs

DNS resolution

DAG

Sue (somewhere in NA)

VIP #1 VIP #2

DAG

mail.contoso.com

Datacenter design for IaaSIaaS provider regions allow for location flexibilitySite resilient deployment can be dramatically easierPA recommends two or more well-connected datacentersAzure can do that!

Server design for IaaSServer design limited by available VM sizesNo perfect “size” for Exchange – depends on requirementsPA recommends JBOD storage, but must still meet IOPS/latency requirementsStick to recommendations on max size (~20 cores, ~96GB RAM) to get best experienceDisk sizes & max disk count may constrain capacity

Exchange Server VM deploymentUse static IP addresses, assign to appropriate virtual network subnetAssociate with an availability setExchange doesn’t support sysprep, can’t start with a pre-built imagePre-reqs can be deployed on a starter image

Download latest Exchange CU & install locally

DAG designPA’s recommended DAG design can be entirely implemented in IaaSSingle network design maps nicely to available infraMinimize number of DAGs (design for fewer larger DAGs)Add new region for witness placement in “3rd datacenter”Backup can be hard in IaaS, focus on PA recommendations to utilize Native Data ProtectionUse “IP-less” DAGs

Sizing for IaaS deploymentUse on-prem virtualized methodologyStart with the calc – http://aka.ms/e2013calc Take business requirements to infrastructure requirements

Determine VM type and countSizing process will produce mcycle, RAM, storage requirementsMap these requirements onto Azure offeringsDS* SKUs currently use Intel E5-2660 CPUs (SPECint_rate = 42 per-core)Remember Premium Storage requirement for productionNote storage size limitations

Standard tier – DS seriesSize CPU

coresMemory

Max. data disks (1023

GB each)

Max. disk IOPS & bandwidth

Standard_DS1 1 3.5 2 3,20032 MB per sec

Standard_DS2 2 7 4 6,40064 MB per sec

Standard_DS3 4 14 8 12,800128 MB per

secStandard_DS4 8 28 16 25,600

256 MB per sec

Standard_DS11

2 14 4 6,40064 MB per sec

Standard_DS12

4 28 8 12,800128 MB per

secStandard_DS13

8 56 16 25,600256 MB per

secStandard_DS14

16 112 32 50,000512 MB per

sec

Demo: Sizing an Exchange Azure deployment

Active Directory architecture recommendationsUse Windows Server 2012 or later for rollback prevention via VM-GenerationIDEach deployment region should be an AD sitePlan for VPN connectivity to enable replication with on-premises AD (or use ExpressRoute) ADFS deployment works great, follow on-prem deployment guidanceUse static IPs (important for DNS config)Use availability sets to improve overall availability

Plan network architectureEach region will need a virtual network definedVirtual network definitions include IP subnets, DNS serversAzure regional virtual networks are connected with site-to-site VPNOn-premises networks connected via VPN or ExpressRouteAzure network configuration defined in XML, applied with PowerShellSet-AzureVNetConfig

Plan load balancer configuration for client access

Load balancing Exchange in AzureAzure Load Balancer sufficient for many scenariosIncrease idle connection timeout to handle long duration connections from Exchange clientsSet-AzureLoadBalancedEndpoint –IdleTimeoutInMinutes 15

Connection distribution is not round-robin or least connections – using hash distribution insteadHealth probe can either be http or ping probeTypical caveats of LB health monitoring with layer 4 LB applyNote http only

Various 3rd party options available for additional functionalityExample: http://kemptechnologies.com/load-balancer-for-azure/

Planning for transportIaaS providers typically not worried about IP reputation, commonly used by spammers to send UCEDelivery failures common (connection filtering with 3rd party blocklists)Consider outbound relay service for SMTP to InternetEOP now properly handling cert auth from Azure VMs, EOP standalone offers are a good solution

Does this stuff actually work?

Let me show you!

Wrap upExchange on IaaS is possibleConsider all your optionsEvaluate cost & complexityStay within supportability boundaries

Have an interesting IaaS deployment scenario? Let’s continue the conversation!

jeff@Microsoft.com

Pre-Release Programs Be first in line!

Exchange & SharePoint On-Premises Programs

Customers get:Early access to new featuresOpportunity to shape featuresClose relationship with the product teamsOpportunity to provide feedbackTechnical conference calls with members of the product teamsOpportunity to review and comment on documentation

Get selected to be in a program:Sign-up at Ignite at the Preview Program desk

ORFill out a nomination: http://aka.ms/joinoffice

Questions:Visit the Preview Program desk in the Expo HallContact us at: ignite2015taps@microsoft.com

Visit Myignite at http://myignite.microsoft.com or download and use the Ignite Mobile App with the QR code above.

Please evaluate this sessionYour feedback is important to us!

© 2015 Microsoft Corporation. All rights reserved.