Azure Hybrid Benefit for SQL Server on Azure Virtual Machines

Benefits for CSP Partners

SQL Managed Instance

Next Steps

1. Deploy SQL on a VM from the Azure Marketplace, such as SQL Server 2016 SP1 Enterprise on Windows Server 2016
2. Once deployed, use PowerShell to switch the VM from PAYG to AHB licensing

Preparation

1. Perform an assessment using Data Migration Assistant (DMA). DMA is a light-weight tool that you can run inside your environment to analyze if your current SQL Server databases are compatible with SQL MI.
2. Decide how your app will connect to SQL MI after the migration. Keeping front end much closer to back end as possible is a best practice, so if you migrate the database from on-prem SQL Server to SQL MI, consider also migrating front end server to Azure VM or Azure App Service. For example, you can migrate front end server and on-prem SQL Server to Azure together using Azure Migrate or another lift&shift tool, and then migrate databases from SQL Server inside Azure VM to SQL MI.
3. Create new SQL MI through Azure Portal. Deployment of the first SQL MI instance takes up to 6 hours, so consider doing this first. Don’t worry, deployments of additional instances take less than an hour.
4. Create new Azure Database Migration (DMS) instance. DMS is a free service that supports migrations of different databases to Azure database offerings. It can migrate MySQL, PostgreSQL, MariaDB databases to Azure Database for MySQL/PostgreSQL/MariaDB, and it also supports SQL Server migrations, including SQL MI.
5. Connect DMS to the source SQL Server and to target SQL MI.
6. Perform the migration (online or offline).
7. Change the connection string in the app to direct it to SQL MI host name.

1. SQL MI is based on SQL Server 2017 Enterprise Edition, which has backwards compatibility with SQL Server 2008 and newer. But what's very important - you need to know what is the latest supported compatibility level of the app that is using SQL Server - a number from 80 to 150. Each version of SQL Server introduces a new set of features and changes, and to ensure that app is using T-SQL queries with the right syntax and invoked stored procedures in the right way, there is a concept of compatibility levels. SQL Server 2000 has default compatibility level 80, and each next version of SQL Server has +10 compatibility by default (up to 150 for SQL Server 2019). For backwards compatibility each new SQL Server supports compatibility levels of older SQL Server versions. SQL Server 2017 supports compatibility levels from 100 (default for SQL Server 2008) to 140 (default for SQL Server 2017). So if you app requires compatibility level 100 (default for SQL Server 2008), and you use SQL Server 2014 - you can safely move to SQL MI. But if you use an app with compatibility level 80, running on SQL Server 2008 (which supported that compatibility level, which is default for SQL Server 2000), you won't be able to move it to SQL MI since it supports compatibility levels 100 and newer. You may face such situation if you have very old workloads, which were created a decade ago and hasn't been updated since then. You can an upgrade from compatibility level 90 to 100 though using in-place upgrade, but ensure to check the differences between compatibility level 90 and 100 to ensure that it won't break the app.
2. SQL MI is a SQL Server database engine. While it includes SQL Server Agent, it doesn't include other components of SQL Server product like:
   1. SQL Server Reporting Services (SSRS) - there is no alternative to traditional SSRS paginated reports in Azure except running SQL Server inside a VM. But if you've already switched from paginated reports to PowerBI-format reports, it won’t be a problem for you to move those reports to PowerBI.
   2. SQL Server Analysis Services (SSAS) - Azure provides PaaS solution based on SSAS - Azure Analysis Services. You can use it as an alternative to existing SSAS. SSAS has its own compatibility levels, and Azure Analysis Services supports 1200 and newer (SQL Server 2016+)
   3. SQL Server Integration Services (SSIS) - if your app relies on SSIS, you can deploy it in Azure Data Factory.
3. Check this article for connectivity options between your app and SQL MI. Important to remember:
   1. SQL MI requires a new subnet inside new or existing vNet that conforms to specific requirements. If you'll decide to create a new vNet during SQL MI deployment on Azure Portal, it will create a new vNet with 10.0.0.0/16 address space and 10.0.0.0/24 subnet. SQL MI default cluster IP is 10.0.0.254. If your existing SQL Server environments is in 192.168.x.x address space or any other outside 10.x.x.x range, then you can leave it as is. But you already use 10.x.x.x address space, you won't be able to tie existing network with SQL MI vNet due to conflicting address spaces. In this case you should consider creating a new vNet with all required rules applied using the following script.
   2. SQL MI can't be published to the Internet and it can't be accessed by IP directly. It has a private IP assigned (10.0.0.254 by default) inside Azure vNet and has a publicly resolvable host name in a form <mi-name>.<unique-id>.database.windows.net. But private IP doesn’t belong to SQL MI - it belongs to internal load balancer that directs traffic to the Managed Instance Gateway (GW). As multiple Managed Instances can run inside the same cluster on the same IP, GW uses Managed Instance host name (<mi-name>.<unique-id>.database.windows.net) to redirect traffic to the correct SQL Engine service. Check here for more details. For you it means that app should connect to SQL MI using a specific host name. If you'll try to connect directly using private IP, GW won't accept the connection since it won't know to which instance do you want to connect.
   3. Comment above means that you will need to change the connection string on the app level and switch your app from existing SQL Server IP/FQDN to SQL MI hostname. Trick with modifying hosts file won't work, since you can't access SQL MI directly by IP. Adding an ability to connect to SQL MI through DNS CNAME (and leaving the connection string as-is) is in the roadmap for future SQL MI versions.
   4. SQL MI doesn't support connectivity through Named Pipes. So if you app connects to SQL Server using Named Pipes, you need to switch it to TCP/IP sockets.
   5. SQL MI currently supports only SQL Server logins. Azure AD logins will be added in next versions. Windows logins are not supported. So if your app connects to SQL Server using Windows Authentication, then you need to switch to SQL Authentication. Or you can wait for the release of Azure AD logins support in SQL MI and then convert existing Windows logins to Azure AD logins.
4. I recommend to use SQL Server Management Studio (SSMS) 18 since I've faced some issues with SSMS 17.9 related to SQL MI management. E.g. SSMS 17.9 throwed an error when I tried to create a new DB through UI, most probably because SQL MI uses different syntax for CREATE DATABASE command. Running a command using a query went fine. That bug was fixed in SSMS 18.

1. Azure Database Migration Service has two pricing tiers - General Purpose and Business Critical. For General Purpose you can select the instance size - 1 vCore, 2 vCore or 4 vCore. Business Critical is available only in 4 vCore size. Larger instance means more computation power to perform data replication and transformation from source to the target. It allows to perform the migration quicker. Since DMS is free of charge until December 31st, 2018 anyway, I recommend to use Business Critical tier for DMS to reduce the downtime period.
2. DMS can perform offline and online migrations to SQL MI. Online mode is available only for Business Critical tier DMS instances.
   1. In offline migration mode DMS performs full backup of the source database, copies the backup from local network share to Azure Storage blob and then restores it on SQL MI. You should stop all write transactions on the source database before initiating last full backup through DMS. So your database won't be available for writes for the time of making full backup, uploading it to Azure blob and then restoring on MI, which takes time depending on the database size - from minutes for small databases to hours for large ones. It also copies SQL Server logins with current passwords from source SQL Server to SQL MI. Offline migration mode should be used in all migration scenarios where putting the database to read-only mode is a possible option.
   2. In online migration mode you need to perform full backup and incremental transaction log backups, then DMS will take these files from local share, upload it to Azure Storage account, and then restore the database on SQL MI - starting from the last full backup, and then applying all incremental transaction log backups. So just before the migration you put the database to read-only mode and perform the last transaction log backup, and then DMS automatically uploads it and applies to the current database copy on SQL MI. As soon as it is done, you perform the failover in DMS and SQL MI database becomes available for read-write. Downtime time in this case is significantly shorter since you don't need to wait until the full backup is completed and uploaded to Azure blob - minutes even for large databases. But there are some disadvantages of DMS online migration mode for SQL Server:
      1. It can migrate up to 4 databases per activity, up to 2 activities per DMS instance. So you can perform up to 8 database migrations and cutovers at the same time.
      2. It requires to use Business Critical tier for DMS instance, which potentially means more migration costs after DMS promotion period.
      3. You need to migrate SQL Server logins manually
      4. It won't work for databases in Simple recovery model.
3. Current experience for offline and online mode differs, but DMS team is working on building a unified UI.
4. DMS requires to perform checksums for database backups. If you didn't enable that setting for existing backups - you will need to do backups again.
5. SQL Server logins are migrated only in offline mode. Windows logins can't be migrated since SQL MI doesn't support them. An ability to convert Windows logins to Azure AD logins will be added in next versions of DMS.
6. SQL Server Agent jobs are not migrated through DMS UI, but you can migrate them through PowerShell. Migration of jobs through DMS UI will be added in next versions.
7. If migration takes too long or fails - try using a larger DMS instance (4 vCore) or switching to Business Critical tier.

Source environment

1. Front-end - all Windows Azure Pack components (tenant portal, admin portal, resource providers). Windows Server 2012. Private IP 10.0.1.4 + public IP for Internet access.
2. Back-end - SQL Server 2012 on Windows Server 2012. Hosting 7 management databases of Windows Azure Pack and one tenant DB (db01). Private IP 10.0.1.5, no public IP.

Step 1: Assessment using DMA

Step 2: Create SQL MI Instance

Step 3: Create DMS Instance

Step 4: Connect source SQL Server, SQL MI and DMS

Step 5: Configure DMS

Step 6a: Migrate databases using online mode

Step 6b: Migrate databases using offline mode

Step 7: Redirect the app to SQL MI

• 5 new VM series were announced:
  • NVv2. Architected to support remote visualization workloads and other graphics intensive applications. The new NVv2 VMs feature up to 448GiB of RAM - twice the amount of memory present in the prior NVv1 generation - an upgraded CPU class and are backed by the NVIDIA Tesla M60 GPU. The NVv2 VMs will also support Premium SSDs and they have been optimized for applications like CAD, gaming and interactive 3D design. They are in private preview right now, and if you are interested - request access here.
  • NDv2. A new addition to the ND-series, NDv2 VMs focus on deep learning training and inferencing as well as machine learning. The new NDv2 will feature up to 8 NVIDIA Tesla V100 Tensor core GPUs interconnected via NVIDIA NVLink GPUs and up to 40 Intel Skylake cores aimed to deliver high quality results even faster. NDv2 VMs are expected to be in preview by the end of 2018.
  • HB. These new VMs will feature 60 AMD EPYC cores and 240 GiB RAM. They have the highest amount of memory bandwidth (260GBps) in the public cloud. This is really valuable for calculations required in fluid dynamics and weather forecasting. Preview will start later this year, and if you are interested - request access here.
  • HC. These VMs are optimized for computationally intensive workloads. The HC will feature up to 352 GiB RAM, 44 Intel Skylake cores with clock speeds up to 3.7 GHz, and will support Intel’s rich ecosystem of HPC software tools. Preview will start later this year, and if you are interested - request access here.
  • DC. A new family of virtual machines in Azure that can help protect the confidentiality and integrity of your data and code while it’s processed in the public cloud. These machines are backed by the latest generation of 3.7GHz Intel Xeon E-2176G Processor with SGX technology. With the Intel Turbo Boost technology these machines can go up to 4.7GHz. DC series instances enable customers to build secure enclave-based applications to protect their code and data while it’s in use.

• Managed Disks enhancements:
  • Standard SSD Managed Disks are now generally available. Standard SSD Disks are a cost-effective storage option optimized for workloads that need consistent performance at lower IOPS levels. Standard SSD Disks store data on Solid State Drives (SSDs) whereas our Standard HDD disks store data on Hard Disk Drive (HDD). Standard SSDs deliver better availability, consistency, reliability and latency compared to HDD Disks, and are suitable for Web servers, low IOPS application servers, lightly used enterprise applications, and Dev/Test workloads.
  • Ultra SSD Managed Disks are now available in public preview. Ultra SSD provides top of the line performance at the same availability levels as our other disks offerings. Additional benefits of Ultra SSD include the ability to dynamically tune disk performance, without the need to restart your virtual machines. Ultra SSD is designed for I/O-intensive workloads such as SAP HANA, top tier databases (e.g. SQL, Oracle), and other transaction-heavy workloads.
  • Larger Managed Disks - up to 32 Tib for regular tiers and up to 64 TiB for new Ultra SSDs. Significant increase comparing to old 4 TiB limit.With new disk sizes, Premium SSD performance will now reach up to 20,000 IOPS and 750MBps, and Standard SSD will now reach up to 2,000 IOPS and 500MBps. New disk sizes are in public preview now and available only in West Central US region, but they will be rolled out in other regions after GA.

• ExpressRoute Direct. New mode of ExpressRoute that provides an ability to connect your network directly into Microsoft’s global network at peering locations strategically distributed across the world. ExpressRoute Direct provides dual 100Gbps connectivity, which supports Active/Active connectivity at scale. Now you can connect your datacenter directly to the closest Azure region with fast and reliable 100Gbps pipe. Also there is a new gateway bypass feature, which gives 100Gps throughput directly into vNet.
• ExpressRoute Global Reach. New feature of ExpressRoute, that allows you to link together several ExpressRoute circuits in different parts of the world.
• Azure Firewall is now GA. Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is 1st-party fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability.
• Azure Virtual WAN is now GA and has new features in private preview. Azure Virtual WAN is a networking service that provides optimized and automated branch-to-branch connectivity through Azure. Virtual WAN lets you connect and configure branch devices to communicate with Azure. In addition to site-to-site connections (which are GA now), you can add point-to-site and ExpressRoute connectivity to Virtual WAN environment.
• VMware NSX SD-WAN for Azure Virtual WAN. VMware and Microsoft will enable customers to redesign their networks for optimized cloud access using SD-WAN and a Virtual Cloud Network architecture. The solution will combine Microsoft Virtual WAN, which spans 130 edge sites or Points of Presence (PoPs), with the optimization, security, and ease of deployment and use provided by cloud-delivered NSX SD-WAN by VeloCloud cloud.
• New Azure DDoS protection features - DDoS Attack Analytics and DDoS Rapid Response. They provide enterprise grade visibility and support to customers when their resources are under attack. DDoS Attack Analytics provides attack insights that can be used for compliance, security audits and post attack analysis to optimize defense strategies and security operations. DDoS Rapid Response will enable customers to engage DDoS experts during an active attack for specialized support.
• Azure Front Door. New service that allows to deliver and protect global applications close to your end users with a "battle-tested" service built on world-class Microsoft Global Network infrastructure. This service is a commercialized representation of a solution, that was used by Bing, OneDrive and Xbox Live teams to deliver applications globally.

• Data Box offline devices easily move data to Azure when busy networks aren’t an option:
  • Data Box - ruggedized device, with 100 TB of capacity, uses standard NAS protocols and common copy tools. It features AES 256-bit encryption for safer transit. This solution is now GA and you can order it through Azure Portal in US and Europe (other regions will follow).
  • Data Box Disk - Microsoft-provided 8 TB SSD, with a USB/SATA interface and 128-bit encryption. It comes in packs of up to five for a total of 40 TB.
  • Data Box Heavy - as its name implies, this ruggedized, self-contained device is designed to lift 1 PB of data to the cloud.
• Data Box online appliances transfer data to and from Azure over the network:
  • Data Box Gateway - storage solution that enables you to seamlessly send data to Azure and back. It is a virtual device based on a virtual machine provisioned in your virtualized environment. The virtual device resides in your premises and you write data to it using the NFS and SMB protocols. The device then transfers your data to Azure block blob, page blob, or Azure Files.
  • Data Box Edge - on-premises physical network appliance that transfers data to and from Azure. Analyze, process, and transform your on-premises data before uploading it to the cloud using AI-enabled edge compute capabilities powered by Intel FPGA. It includes Azure Data Box Gateway, mentioned previously, and Azure IoT Edge.

• Avere vFXT for Azure. Caching solution from a company, that was recently acquired by Microsoft. It tiers data stored in Azure Blob to an SSD-based cache in Azure Compute while the job is running. Once processing is complete, the data is written back into Blob. With this flexibility to support hybrid deployments and edge computing, the Avere vFXT becomes an important part of a cloud migration strategy for file-based applications in HPC environments.
• Azure NetApp Files. Jointly developed by Microsoft and NetApp, Azure NetApp Files is a native Azure service powered by NetApp’s ONTAP technology and storage expertise. It is designed to meet and exceed most organizational requirements for performance, scalability, data management, security and more.
• Azure File Sync. This service replicates files from on-premises Windows Server to an Azure file share. Azure File Sync enables you to centralize your file services in Azure while maintaining local access to your data.
• Azure Premium Files. New service that provides fully managed file services, optimized to deliver consistent performance at 100 times improvement from the existing Azure Files. It's designed for IO intensive enterprise workloads that require high throughput and a single digit millisecond latency.

• Now you can pre-pay for Azure SQL Database Managed Instance capacity for 1 year or 3 years and get a significant discount.
• Database Migration Assistant (DMA) - essential tool for SQL Server migration, now has full support for Azure SQL Database Managed Instance. Also there were important updates for Azure Database Migration Service.

• Windows Server 2019 is now GA. Check this article to learn what's new in the latest version of Windows Server.
• New services for Azure Stack - Kubernetes, Event Hubs and Service Fabric.
• Now you can move VMs with managed disks from one subscription to another. E.g. from Azure subscription in EA to CSP, vice versa.
• Azure Cloud Shell is now GA. Azure Cloud Shell is an interactive shell for managing Azure resources, accessible directly from Azure Portal with one click. It provides the flexibility of choosing the shell experience that best suits the way you work. Linux users can opt for a Bash experience, while Windows users can opt for PowerShell.
• Azure Database portfolio now includes MariaDB (in preview) in addition to MySQL, PostgreSQL and SQL Server.
• Windows Virtual Desktop was announced and will be available in private preview later this year. It is a new VDI solution, that will allow you to deploy and scale Windows and Office clients on Azure in minutes, with built-in security and compliance.
• Azure Blueprints is not available in public preview. Azure Blueprints enables you to rapidly provision and stand up new environments knowing that they're built within organizational compliance and contain a set of built-in components. Blueprints are a declarative way to orchestrate the deployment of multiple resource templates and other artifacts such as role assignments, policy assignments, Azure Resource Manager templates and Resource Groups.

1. BRK2041 - A deeper look at Azure Storage with a special focus on new capabilities. Great insights into an evolution of hardware, backing up Azure storage services and the future of cost-efficient data storage in the glass and using DNA.
2. BRK2483 - Azure networking internals. How global Azure network looks on the other side and what are the challenges that Microsoft solves while operating one of the largest software-defined networks in the world.
3. BRK3296 - Tips and tricks to get the most out of your Azure virtual machines. Number of insider tips on how to get the most out of your Azure virtual machines.
4. BRK3055 - Azure migration deep dive: Accelerate your migration with the right tools. This session, rich in demos, shows you how to leverage Azure migration services, such as Azure Migrate, Azure Site Recovery, and Database Migration Service, to automate and accelerate your migration.
5. BRK2414 - Migrating your Linux solutions to Microsoft Azure. Overview of existing services and IP that will help you with the migration of Linux solutions to Azure.
6. BRK3337 - Azure migration customer experiences and best practices. Learn the steps Azure customers have used to migrate applications from on-premises data centers to Azure.
7. BRK3165 - Azure SQL Database Managed Instance: Migrate SQL Servers easily to a fully managed cloud service and BRK3163 - Securing Azure SQL Database Managed Instance: Overview and best practices - if you want to learn more about new Azure SQL Database Managed Instance.

1. Run the same VM in another Azure region - to determine if it is a global problem, or something is wrong with a -specific region
2. Resize it to a different VM family - to use a different underlying hardware
3. Recreate the VM - maybe something is wrong with guest OS configuration

What about Partner Center?

1. If you have a problem with Partner Center portal, Partner Center API, CSP billing or any other problem with Partner Center - create a support request on Partner Center portal and provide the details.
2. If you have a problem with Azure resource (VM, storage account, Web app or anything not related to Partner Center) - go to Azure Portal on behalf of an affected customer and create a support request there.

• Support for SQL Server 2008/2008 R2 ends July 9, 2019
• Support for Windows Server 2008/2008 R2 ends January 14, 2020

Free extended security updates in Azure

Save money

Migrate VMs using Azure Site Recovery

Migrate SQL Server 2008 & 2008 R2

• Migrate to SQL Server on Azure VM Migrate to PaaS, Azure SQL DB Migrate to Azure SQL Managed Instance

Modernize the data platform

1. Windows Server Standard 8 Core License Pack + CALs
2. SQL Server Standard 2 Core License Pack
3. SQL Server Enterprise 2 Core License Pack
4. Windows Server RMS CAL.

1. Use Azure Marketplace images with pay-as-you-go (PAYG) licenses for Windows Server and SQL Server included and pay for Windows Server and SQL Server based on the number of cores per hour.
2. Use this new capability of Partner Center to buy Windows Server and SQL Server licenses for 1 year or 3 years on behalf of your customers.

Azure Hybrid Benefit for Windows Server

1. Number of required core licenses is based on the number of VM cores (no matter if they are hyper-threaded or not).
2. Minimal amount of Windows Server licenses in order to use Azure Hybrid Benefit per customer - 16 cores (at least two 8-core packs).
3. 16 core licenses allow to run two VMs with up to 8 core each, or single 16-core VM.
4. VMs with less than 8 cores still require 8 core licenses assigned.
5. VM price with Azure Hybrid Benefit for Windows Server is equal to the Linux VM price of the same size.
6. You can create VMs with Azure Hybrid Benefit activated using Azure portal, PowerShell or even ARM template. You can enable Azure Hybrid Benefit in the existing Azure VM, so it will be converted from PAYG Windows Server license to AHB. You can filter all VMs that are using AHB in the VM list. Those topics are covered on this page.
7. If you are migrating an existing VM to Azure, don't forget about Windows Server activation - switch to Azure KMS servers after the migration as described in this article.

Azure Hybrid Benefit for SQL Server

1. 1 core license for SQL Server Standard grants rights to 1 vCore for Azure SQL Database, General Purpose tier only.
2. 1 core license for SQL Server Enterprise grants rights to 4 vCores for Azure SQL Database in General Purpose tier, or 1 vCore for Azure SQL Database in Business Critical tier.

Process walkthrough

1. Go to Partner Center portal, select customer account from the list, and then select Software -> Add products.
2. Select Segment: Commercial, Type: Software subscriptions, Terms: 1 Year or 3 Years.
3. Select the quantity of required licenses and click Add to cart.
4. Then click Review and Buy.

1. Go to Azure portal and create a new VM using any Windows Server image.
2. Choose Yes for Already have a Windows license? question and confirm that you have enough licenses for Windows Server with active Software Assurance. All licenses that you buy in Partner Center include Software Assurance for the duration of software subscription.
3. Proceed through the VM creation UI as usual.
4. Go to Configuration menu in VM settings and ensure that Use existing Windows license is set to Yes.

1. If you want to activate Azure Hybrid Benefit for VM, that was created without Azure Hybrid Benefit, than just select Yes on VM Configuration page.
2. If you want to activate Azure Hybrid Benefit for VMs that you want to migrate to Azure using Azure Site Recovery, check this guide.
3. If you've migrated this VM to Azure from your environment and it was previously activated using your internal KMS servers, than run the following command inside the guest OS to set Azure KMS servers for Windows activation instead:

1. Go to Azure portal and start creating new Azure SQL Database.
2. In the Pricing tier menu select vCore-based purchasing options, then select General Purpose or Business Critical tier.
3. Click Yes for Save money option to activate Azure Hybrid Benefit for SQL Server and confirm that you enough SQL Server licenses with Software Assurance. All licenses that you buy in Partner Center include Software Assurance for the duration of software subscription.
4. Proceed through SQL Database creation UI as usual.
5. If you want to activate Azure Hybrid Benefit for SQL database, that was created without Azure Hybrid Benefit, than just select Yes in Configure page in database settings.

1. Go to Software menu in customer account page on Partner Center portal.
2. Select SQL Server version and language.
3. Click Get keys and downloads.
4. Download SQL Server ISO. Product key is not required for SQL Server installation, it is embedded to the installer.
5. Create a new VM using regular Windows Server image. Don't use SQL Server Azure Marketplace images since you will be charged for SQL Server license using pay-as-you-go meter.
6. Activate Azure Hybrid Use Benefit for Windows Server during the VM creation if you want to utilize existing Windows Server licenses.
7. Proceed through new VM creation UI as usual.
8. Install SQL Server on that VM manually using the SQL Server installation media, downloaded from Partner Center.

1. Create new VM in Azure using regular Linux template for one of the supported Linux platforms. Don't use SQL Server Azure Marketplace images since you will be charged for SQL Server license using pay-as-you-go meter.
2. Proceed through new VM creation UI as usual. BYOL images for SQL Server are not available in CSP yet.
3. Install SQL Server on that Linux VM manually. Installation media or product key is not required to install SQL Server on Linux.
4. Select edition on the last step - Standard or Enterprise, regarding SQL Server license edition that you've purchased through Partner Center.

1. Migrate the source VM to Azure using Azure Site Recovery or similar VM lift&shift tool, activate Azure Hybrid Benefit for Windows Server if needed.
2. Deploy new VM and install SQL Server as described above. Migrate existing SQL Server database using Azure Database Migration service or similar tool.
3. Create Azure SQL Database or Azure SQL Database Managed Instance and activate Azure Hybrid Benefit for SQL Server. Migrate an existing SQL Server database using Azure Database Migration service or similar tool.

Azure CSP documentation provides answers to the most popular partner questions about Azure specifics in Cloud Solution Partner model, including:

1. Which Azure services are available (and not available) in CSP
2. How to move existing Azure EA customers to CSP
3. How Azure partner experience looks like inside Partner Center (with videos)
4. How customer support of Azure customers in CSP should look like
5. How Azure billing works in CSP etc.

 Also Azure CSP documentation provides details about 50 integration scenarios with UI screenshots and code examples on PowerShell, C# and REST API. It should helpful for CSP partners, that are looking for guidance how to integrate existing apps and services with Azure in CSP.

There is a comment section in the bottom of every page in the documentation. So you are able to provide feedback and ask additional questions directly on documentation pages.

• The Landscape and Feasibility. This chapter summarises the key areas to address when evaluating the business feasibility of moving the managed services provider platform into Microsoft Azure.
• Planning for Coexistence. Transformations or migrations are not accomplished Customer functional and non-functional requirements, platform requirements, and other dependencies force typically demand a phased approach to migration. This means that both the source and target environments will be active concurrently for at least the duration of the migration.
• Building the Inventory. A thorough understanding of the source environment is required when moving a workload, application or service from the source environment into the target environment. Dependencies within and between workloads must be identified to assess the impact of migration and plan an appropriate approach.
• Designing the Target Environment. This section will address considerations for planning the Microsoft Azure environment and provide examples of logical and physical architectures and approaches to leverage the agility introduced when embracing public cloud services.
• Migration. This section focusses on different approaches to moving services into Azure subscriptions, the approach to project execution as well as roles and responsibilities within the migration project team.

The Landscape and Feasibility

Overview

• Cloud Solution Provider and Shared Services

• Role-based access control may be configured at the subscription level to secure Azure resources.
• All Azure resource consumption within a CSP-based subscription is linked to the subscription, enabling the service provider to readily identify the tenant with which the consumption is associated.
• When requesting support from Microsoft, service providers can create service requests on behalf of their tenants that are linked to a specific tenant and subscription.

Individual CSP Subscriptions Per Tenant

Cost Optimization and Planning

• The public cloud does not provide hardware resilience in the same way as on-premises virtualisation platforms may. Workloads should incorporate availability measures at the application layer rather than relying on highly available infrastructure.
• Service providers have limited control over maintenance cycles for public cloud infrastructure but are still required to meet service levels with their customers as described by their managed services agreement.

• Resource Capacity Requirements: It is of utmost importance to understand the actual resource requirements of a certain workload, application or services within managed services. By understanding specific workload requirements it is possible to allocate sufficient public cloud resources without over-provisioning and incurring unnecessary additional cost. Using resource definitions equivalent to an existing on-premises environment and adopting them unchanged in the public cloud infrastructure often leads to higher cost, thereby affecting the bottom line.
• Infrastructure Availability: Not having an underlying highly available compute infrastructure for workloads means that service availability must be accomplished at a workload level. Single server configurations must transition to multiple server configurations to provide continued availability of managed services in case underlying infrastructure is affected by issues or maintenance. Microsoft Azure Availability Set resources can be used to ensure virtual machines are distributed across multiple Fault Domains.
• Workload Availability: Increasing workload availability through the addition of virtual machine instances may increase operational costs and thereby impact the business case for virtual machine migration to Microsoft Azure. One approach to managing this impact is to appropriately scale virtual machines to meet workload requirements whilst adding additional instances to enable a workload to survive the loss of one or more virtual machines. Load balancing across virtual machines can be accomplished either at the application level by workload-specific mechanisms, or through the addition of infrastructure-level load balancing resources such as Azure Traffic Manager, Azure Web Application Gateway or Azure Load Balancers. Other approaches to providing workload resilience include utilising replication capabilities or cluster capabilities within a workload. For example, Active Directory Domain Controllers replication can provide resilience for Active Directory Domain Services, whilst Microsoft SQL Server Log Shipping or Always-On Availability Groups may provide resilience for database services. Replication is unlikely to result in cost optimisation, but may address requirements for ongoing service availability.
• Planning for Growth: Even if a decision is made to implement a single virtual machine instance, Microsoft recommends that single virtual machine instances are deployed in their own Availability Sets. This approach facilitates the addition of additional virtual machine instances in future if required, through their addition to the same Availability Set. By including the initial virtual machine in an Availability Set from the outset, a service interruption to join the virtual machine to an Availability Set when subsequent virtual machine instances are deployed is avoided.
• Virtual Machines with Licenced Software: Some VM images include pre-installed software, such as Microsoft SQL Server. The usage costs for VMs using these images will be higher than the cost of a VM deployed with an image including only the operating system, as a component of the usage cost is attributed to the licence for the included software. When deploying virtual machines it is important to consider whether to utilise images with pre-installed software, or whether to install application software after VM deployment and leverage other licencing models for the application.

Planning For Coexistence

• On-Premises Bandwidth Requirements. During a period of coexistence the bandwidth needs of the on-premises environment will fluctuate. Initially, additional bandwidth may be required to accommodate communication between services hosted on-premises and those running in Microsoft Azure. Over time, the bandwidth requirements for on-premises systems will decrease as they are progressively migrated to Microsoft Azure and client applications access these through endpoints published in Microsoft Azure. Estimating bandwidth requirements and how these will change over the period of coexistence is important but can be a challenging task, particularly when the on-premises network is not well segregated or network components do no provide sufficient information for analysis.
• Deployment Sequence. When planning for coexistence, Microsoft recommends deploying core services in Microsoft Azure prior to migrating services that are dependent on these. For example, consider deploying (or migrating, when appropriate) the following services in Microsoft Azure early in the period of coexistence:
  • Active Directory Domain Controllers to provide authentication and authorisation services for subsequent application workloads.
  • Distributed File Services (DFS) nodes to provide file services with a local replica of content.
  • Remote Desktop Services (RDS) services to minimise the impact to end users.
  • SQL Server Always-On Availability Group nodes to provide a local replica of databases that may be used by applications.

• DNS Switch or Platform Activation. Once a hybrid scenario is established and core services are deployed and extended into Microsoft Azure, platform activation is the next step. Although there are several approaches that may be used, two of these approaches are described below. Reconfiguration of endpoints or clients should be avoided due to the effort, timeframes and costs involved in making these changes. Two possible approaches include:
  • Traffic Manager. Introducing Azure Traffic Manager to provide global load balancing services will enable load balancing of traffic across services running on-premises and in Microsoft Azure. Azure Traffic Manager operates as a mediation layer between the end points consuming services and the platform publishing the services. If running two environments concurrently is not an option, Traffic Manager may also be used to switch between environments without requiring a change to public DNS records. Using Azure Traffic Manager in this manner to support migration is typically temporary and provides a controlled approach to direct traffic to migrated workloads.
  • DNS Switch. When performing a DNS Switch, the public DNS records for the workload are updated. Initially, these DNS records resolved to the IP address of the workload on-premises, however after migration the DNS records are updated to reflect the addresses of the Microsoft Azure endpoints for the migrated workload. When updating DNS records the time-to-live (TTL) of the records must be considered as it may take some time for systems to cease using cached IP addresses and query DNS servers for updated addresses. As this approach may result in a delay until all clients utilise the new IP address, performing a DNS switch is seen as the least controlled approach to connecting to migrated workloads. From the time the DNS record is updated, traffic may be directed to both the prior on-premises address and the address of the workload in Microsoft Azure for some time.

Building the Inventory

Designing the Target Environment

Naming Conventions

Logical Design

Physical Design

Subscriptions and Delegated Administration

• The size of the customer environment.
• The type of access a customer would require within that environment.
• The ability to isolate customers from other customers.
• The cost and operational considerations in operating one environment or several.
• Licensing constraints that may limit the ability to deploy services or workloads shared by multiple customers within a given subscription type.

Storage Accounts

Virtual Networks and Network Security Groups

Migration

• Lift and Shift. This approach involves shutting down the VM in the source location, copying the VM data to an Azure storage account then recreating the VM in Azure. The data transfer will originate from the system where the copy action is started but the actual data to transfer comes from the location where the virtual Hyper-V disks are located. Where Microsoft Hyper-V virtual hard disks (VHD) are migrated no further conversion is Where other virtualisation platforms are used and virtual hard disks are not in the VHD format, conversion of virtual disks to a format supported by Microsoft Azure is required. Disk format conversion may take some time and the down time for the workload starts when the conversion starts. Once the virtual disk is in the VHD format, the virtual disk must be copied to the storage account in the Microsoft Azure subscription. This data transfer will occur over the Internet, and the throughput available will determine the duration of the transfer. Once the virtual disks for a VM are transferred, the virtual machine can be created in Microsoft Azure. The newly created virtual machine will come online in the new environment with new IP addresses however as the operating system disk has been retained the same hostname will be used. Although this process can be automated, the amount of data to transfer, the level of concurrency, downtime required for testing and the required overall downtime of the workload must be taken in consideration when selecting this approach.

• Azure Site Recovery. Azure Site Recovery (ASR) provides the capability to replicate a workload from a source environment to the target Microsoft Azure subscription. This replication is either performed by an agent installed on the Hyper-V host server (when no conversion is required) or it is performance by installing an agent in the guest operating system in case the Hyper-V hypervisor is an older version not supporting replication, or the workload either is located on physical servers or VMWare hosts. When using ASR there is no downtime during replication of disk content to Azure. Although the new virtual machine within the target environment can retain existing IP addresses or obtain new IP addresses, the virtual machine network name will stay the same which could introduce challenges when bringing up this virtual machine in the target environment while the source system is still active in the current environment. This approach minimises workload disruption as there is a short switch over time whilst the VM is brought online in Microsoft Azure. Where hard dependencies on the IP address of the migrated server exist, these must be identified and modified where necessary when using this migration approach.

• Rebuild or Build out. This approach is based on either the redeployment of the workload in Microsoft Azure, or the application-dependent capability to extend the workload through the addition of additional nodes. In the latter case, the ability to add additional nodes may also require application-level support for data replication. This approach also provides an opportunity to eliminate legacy applications, either known or unknown. Although this approach might be labour intensive, it provides an opportunity to run two environments concurrently, create a "clean sheet" situation and do a better and easier non-disruptive testing as well. Workload will get new names and new IP addressing within the target environment.

Migration Planning Template

Migration Plan - <Customer Name>

Essential Customer Details

Technical Details

Dependent Resources

Server Dependencies

Server Mapping

Migration Description

Migration Timelines and Milestones

Migration Script

Risks

Rollback Plan

Project Management

Project Approach

Planning Phase

• Build initial Architectural blueprint for shared services as well as dedicated customer environments within Microsoft Azure.
• Build initial migration blueprints and planning for shared services as well as dedicated customer environments for migration from the current datacenters to Microsoft Azure
• Setup initial project planning, team structure, tracking, and risk management
• Validate and finalise Architectural blueprint
• Validate and finalise migration blueprints
• Finalise collection of customers to be migrated in this project
• Establish project organisation and allocate resources
• Identify 3rd party dependencies and engage these 3rd parties.
• Define migration procedure verification criteria
• Define platform acceptance tests on core components to support coexistence

Build Phase

• Preparation of procedures to build core platform building blocks
• Preparation of procedures for platform migration
• Execution of functional tests as defined in migration procedure verification criteria
• Execution of functional tests as determined in the definition of platform acceptance test on core components to support coexistence
• Validation and finalisation of procedures to build core platform building blocks
• Validation and finalisation of procedures for platform migration
• Build platform core components within Azure

Deploy Phase

• Migrate shared services and dedicated customer environments from the source platform into Microsoft Azure.

Stabilize Phase

• Stabilise the environment and identify any issues. These issues will be triaged, prioritised and resolved.

Roles and Responsibilities

Core Objectives

• Transform into a cloud based managed services provider with deep expertise in Microsoft Dynamics ERP, CRM and Azure platforms.
• Leverage Microsoft Azure as their primary DC for customer expansion and growth.
• Migrate the existing customer managed services from their co-location datacenter facility to Azure.
• Minimize down-time with any service outages to be managed out-of-hours of the Production service.
• Run the current services in Azure for the same cost or less than in the co-lo facility.

Business Focus

Understand the current business environment and economics

Symbiosis between business and technical solutions

Inflection points

• What are strategic objectives for the partner - e.g.: business model transformation, customer and revenue growth, moving away from additional capital investment?
• What are the business drivers for migration to Azure?
• What is the budgeting cycle in the company and who approves projects?
• When are the inflection points? This could include expiring colo/maintenance contracts, hardware depreciation/refresh cycle, end of support, existing hardware reaching capacity, customer expansion/growth in newer geographies
• Existing contractual arrangements? Who owns the existing infrastructure and maintenance, timelines, break-points, dependencies.
• What is the detailed financial breakdown for the as-is on-premise hosting versus the Azure migration?

Understand the as-is architecture and constraints

Gather detailed as-is usage data

• Constant capacity, specified for peak load.Infrastructure has been designed to handle peak demand at all times rather than flexing capacity over time to meet demand. Most demand follows cycles (daily, monthly, quarterly or based upon predictable triggers) where median load is a small percentage of the peak.
• On-premise capacity is not quick to change. Adding additional capacity to an on-premise server farm at worst case can involve procuring additional hardware, racking/stacking, etc., which could take several weeks. Therefore, architects and System Administrators will add an on-premise capacity buffer to mitigate against this.
• On-premise solution capacity is typically specified for estimated demand years into the future. Traditional on-premise projects often have 3 to 5 year business cases and it is common for infrastructure capacity to provisioned on day 1 for the forecast capacity in 3+ years' time.
• Required capacity was forecast but not measured. On-premise capacity was set based on a forecast and not retuned for actual demand.
• On-premise solution capacity will always be over specified by design. When architects perform capacity planning they will naturally add a capacity safety net to their forecasts, it's human nature. This is because under-provisioning capacity can have visible implications (solution could fail) but over-provisioning has far less visible implications (infrastructure costs are higher than they should be) and companies rarely hold architects accountable for their capacity estimates.

Provisioning guidance

1. Considering customer growth, but provisioning infrastructure capacity in Azure appropriate for the actual solution demand now.
2. Use smaller percentage capacity headroom values. Scaling for 90% utilization is recommended for most solutions.
3. Ensure that the Azure capacity will scale up and down in response to changes in demand.

Measuring demand

Develop a detailed financial model for a selection of solution options

Option variations

• Stay on-premise option (baseline 1)
• Direct one-to-one port into Azure (baseline 2)

• Pre-Production environments started on demand (different types of pre-Production environments will have different capacity requirements, e.g. Functional Test versus Performance Test)
• Pre-Production environments started on schedule (e.g. Monday to Friday 8am to 6pm - i.e. switched-off out of hours)
• Single geography Production environments scaled back during non-peak hours
• Tracking available capacity to actual demand in pseudo real-time, with a small buffer.
• Pre-loading capacity for known peak cycles (e.g. start of business day logins, end of month batch run, etc.)
• Consolidation of SQL hosts

• Moving VM hosted SQL to Azure SQL
• Utilizing PaaS services to replace some IaaS components

Modeling utilization

Target utilization when capacity planning

Cost drivers

Things that are included in Azure but are usually missed in financial modeling comparisons

Include all existing contractual liabilities in the model

Sunk costs and depreciated assets

Time horizon for financial modeling

Azure licensing

Scalability of the solution

• Runs as one or more stateless processes,
• Supports concurrency and the ability to scale processes horizontally (elastic scaling),
• Disposability, designed to fail gracefully so that nodes can be replaced easily.

When to consolidate resources

Options with SQL and using PaaS to reduce costs

1. Azure now supports high-availability with SQL Standard edition, which can mitigate lack of scheduling ability for Azure maintenance windows.
2. Use Azure SQL PaaS service to provide HA service, either provisioned by database or by required performance.

Existing SLAs and Contracts

1. Reduce Test environment capacity out of office hours (based on usage data) while still keeping the environments available 24x7.
2. Plan for a future product update that gives the customer the choice of Test environments being available 24x7 or just during office hours, with different price points.

Migration approach - a business view

Refine the model after initial Azure deployment

Ensure contractual cover for all agreements

• The agreed migration approach and high-level solution
• Agreed goals and KPIs for the partnership
• The financial model headlines, e.g. MSP consumption/revenue expectations over time
• Financial gives and gets across Microsoft and the MSP (including resource commitments)
• Technical gives and gets across Microsoft and the MSP
• High-level timeline for the change program, showing work-streams
• Protection of Microsoft and/or Partner IP used during the program
• Ownership of any new IP resulting from the program
• Specific roles and responsibilities between Microsoft and the MSP
• Governance approach including Steering Committee membership and communication cadence
• Escalation path and agreed criteria for escalation
• Agreement from the MSP to create a Case Study.