Archive for November, 2013

When reviewing your SQL Server HADR strategy for Azure IaaS here are main points of the different options: Windows Server Failover Cluster (WSFC), SQL Server AlwaysOn Availability Groups, Clusters, Availability Listeners, and Database Mirroring. WSFC provides infrastructure support and is required for both “AlwaysOn Availability groups” and “AlwaysOn Failover cluster”.

WSFC Clusters (sometimes called AlwaysOn Failover Clusters)

  • WSFC Failover Cluster is used for HA
  • WSFC provides redundancy at server level.
  • Uses one shared (mirrored)  storage server as Single Point of Failure between to active (primary) and passive (secondary) nodes. Thus, no copy of Tx Log. Failover takes time to roll to next node.
  • Primary is running (active) no SQL Server running in secondary. When primary fails secondary becomes active.
  • Mirroring is an option on the cluster and does not do auto failover. You have to manually use the secondary at failover.   It will automatically start the secondary node if the active node fails (no heartbeat response in time and routes to secondary).
  • Use the cluster name in the database connection string.  If failover then cluster will map it to secondary failover server

SQL Server AlwaysOn Availability Groups (SSAOGs)

  • Can use more than two nodes
  • Is a logical association across more than one SQL Server cluster nodes.
  • Since TX log is always being updated the secondary servers are always up and running as active/active.
  • No use for shared (mirrored) storage
  • AAA Group constantly checks for failover –  if primary replica node is suddenly not responding AAL VIP points to a secondary and makes that the primary.
  • Multiple secondary servers alternatively used for read-only queries, reporting, and backup.
  • AlwaysOn Availability Group is used for HA and DR scenarios.
  • Faster recovery and zero data loss using synchronous mode

SQL Server AlwaysOn Availability Group Listener (SSAOAGL)

  • Use the AAAG Listener (VIP) in the database connection string.
  • AAAGL abstracts out the actual database of the primary and secondary servers.
  • Requires Windows Server 2012 to set up AAAGL in Azure

SQL Server Database Mirroring


This is the fourth post for the mini-series entitled “Hosting SQL Server in Window Azure IaaS Fundamentals”. In this post I will teach you about uploading a VHD to Windows Azure that already has SQL Server (and possibly other supporting apps) installed on it. The reason you would want to take this approach is if you want to use SQL Server as part of an existing VM configuration you are running in your on premises virtual environment that may contain other supporting or reliant apps for SQL Server, and you want to move it as-is into Azure.    To create an Azure VM and rebuild this environment manually to replicate the on premises SQL Server configuration may be very time consuming and error prone.  With this option you will forklift the existing VM environment found on the VM into the Cloud.    This minimizes your configuration time and keeps a consistent environment from on premises to  the Cloud.  However, this process of getting SQL Server into Azure is the most complex and time consuming so it correspondingly takes longer to get SQL Server up and running in the IaaS environment. If expediency of getting SQL Server running in an Azure IaaS VM is important, or if you are not trying to replicate an on premises SQL Server installation exactly in Azure, this option is probably not for you.

We will also look at how to create and install a management certificate into Azure.  Once that is in place we can use the CSUpload utility or Azure PowerShell cmdlets to upload our VHD that contains SQL Server into Azure Blob storage.  After that is complete we can then create an Azure image or disk from that VHD. This in turn allows us to create our own custom VM installation of SQL Server running in the Azure IaaS Cloud.

Loading a VHD into Azure

By choosing this option to get SQL Server into an Azure IaaS Cloud you will not use any of the stock pre-loaded SQL Server Gallery images to create a SQL Server VM. Instead you will use a custom Azure Disk Image or Disk to create the SQL Server VM. Recall we discussed the differences between Azure disks and images in a previous post.  Be careful that when you load your VHD into Azure that it is of fixed format – not dynamic, or it may expand beyond the 127GB size during the upload process.  Also, I just want to mention again that with any SQL Server IaaS installation it is your job to manage updates to SQL Server and the VM on your own.

Install Management Cert in Azure Portal

This is a three-step process where we will first create a self-signed certificate for testing. You would probably want to get it signed by a Certificate Authority in real-world deployments.  You can then export it from the local certificate store using the Certificate Manager console.  You can then upload the certificate into Azure using CSUpload or the Azure portal.  Once the certificate is loaded you can then invoke PowerShell cmdlets or CSUpload to upload the VHD to Azure.

1. Create self-signed management certificates, open a Visual Studio command prompt as an administrator, and then run the following command. The Makecert command stores the new certificate in the default Personal certificate store. You will then need to export it from the personal store.

makecert -sky exchange -r -n “CN=mysqldemocert” -pe -a sha1 -len 2048 -ss My “mysqldemocert.cer”

2. Export your X.509 v3 certificate

  1. Start / run / certmgr.msc
  2. Navigate the tree hierarchy until you find the certificate you just created.
  3. On
    the left pane right click on the certificate and select / all tasks / export
  4. Select “No, do not export the private key”
  5. Click on next until you are asked for the Export path. Enter the desired export path.
  6. Follow the prompts and finish the export.

3. Upload the certificate to azure using the portal. Note you can also do it with the CSUpload tool if you desire to do it programmatically.

Upload a VHD from on Premises to Azure Blob Storage using CSUpload

Once the certificate is loaded to Azure, you could use its thumbprint as a parameter to the CSUpload utility and PowerShell cmdlets to upload the VHD to Azure Blob storage.  CSUpload is older technology than the Powershell cmdlet to upload the VHD but I will for sure include it since some folks don’t want to mess with Powershell.  So we will look at both in this module and you can choose which one you want to use based upon preference.  Note that if using PowerShell ISO once you import your publishsettings file you don’t need to specify a management certificate as the tool manages that for you for that session.

First let’s upload a VHD using CSUpload. Before we do any uploading we want to, as a best practice, create a named storage account for our VHDs. We will call this storage account sqluploadvms, all lowercase as required by the portal. CSUpload requires you to include the thumbprint of the management certificate you uploaded as a parameter. Here’s where you get other parameters from Azure for CSUpload.

  • Storage URL
  • Subscription ID
  • Cert Thumbprint (Column in cert page)

You can find the CSUpload tool in the C:\Program Files\Microsoft SDKs\Windows Azure\.NET SDK\2012-10\bin\ folder.  Run it from a command prompt as Administrator.

csupload Set-Connection “SubscriptionID= 04786d34-85b6-49c5-a3e3-564d625e1aa1;CertificateThumbprint= EA2D7C84D99127E5294B5A5151B7C7D886462DC3;ServiceManagementEndpoint=”

csupload Add-PersistentVMImage -Destination “” -Label Win2008R2.vhd -LiteralPath C:\Temp\Win2008R2.vhd -OS Windows

Upload a VHD to Azure Blob Storage Using PowerShell

The other option, and as a best practice is typically the preferred option since you don’t have to mess with creating an uploading a mgmt certitficate using PowerShell ISO, it to use PowerShell to upload the VHD.  PowerShell API offers more options as well over CSUpload.  We don’t need to explicitly upload a  management certificate for certain tools like Visual Studio or PowerShell ISE. When you access the publishsettings file from either of them it will create a mgmt certificate for that connection and install in the Azure portal.  Note that if you are running a PS1 PowerShell scripts from the normal Powershell comand prompt you need to reference the thumbprint of the certificate within the scripts itself.

Next let’s upload a VHD using PowerShell. Open a Windows Azure PowerShell ISE window. As a best practice when you are interactively using PowerShell this is better than using the normal Azure PowerShell prompt due to the ability to help you develop the call interactively. When you download the publishsettings file it contains information and a certificate for your Windows Azure subscription.  This means you do not need to use the certificate thumbprint explicitly in these calls. Import the file set the current subscription and storage account, then being the upload of the VHD to blob storage.

//Causes you to log into azure portal. Download to c:\temp and rename //for simplicity file.publishsettings.


If we now look at the at the Azure portal we can see there is a new certificate that has been uploaded and created for the PowerShell ISO tool.   We will now import the publishing settings file which contains an encoded version of the management certificate we just created. It serves as your credentials to administer your subscriptions and related services. Store this file in a secure location or delete it after you use it.  When we import the publishsettings file that cert will be used for all powershell calls using this connection.

//Imports the file and chooses a default subscription. If not what you //need to change it in next command.

Import-AzurePublishSettingsFile c:\temp\file.publishsettings

//Choose current subscription and storage account to copy the VHD to.

Select-AzureSubscription “Windows Azure MSDN – Visual Studio Professional”

//Begin the upload

Add-AzureVhd -Destination “” -LocalFilePath “C:\temp\Win2008R2.vhd”.

Once we get the VHD uploaded to Azure we need to the create an Azure Disk or Image from that VHD. What we will create depends upon if the OS on that disk has run sysprep for an image or not for a disk.

Once you get the VHD that contains SQL Server uploaded to blob storage you can then create a SQL Server image from a VHD, or you can create a SQL Server disk from a VHD in one of these two ways:

Creating an Azure SQL Server Image

  1. Virtual Machines/Images/Create
  2. Find a VHD that has been syspred and create a SQL Server image

Creating an Azure SQL Server Disk

  1. Virtual Machines/Disks/Create
  2. Find a VHD that has been NOT BEEN syspred and create a SQL Server image
  3. Click The VHD contains an operating system of it does and this disk you will run the SQL Server from. If just a SQL Server data disk (no OS) don’t check this.

Once we create an Azure Image or Disk, we can them create a VM from this in the gallery.


This post is one of the most involved so far. We discussed how to create, export, and upload a self-signed certificate to Azure if you are uploading a VHD using CSUpload or a PS1 file in which you would need to specify the cert thumbprint in the PS1 file. Once that is complete you upload your VHD to blob storage using powershell cmdlets or the CSUpload utility.  From there you create an Azure image or disk from the VHD (again depending upon if it has been sysprep’d or not) then create an Azure VM or Disk from that VHD.   You can then start your VM and your custom installation of SQL Server is up and running in Azure IaaS.

This is the third post for the mini-series entitled “Hosting SQL Server in Window Azure IaaS Fundamentals”. In this post I will teach you about capturing an Azure VM Image with SQL Server. This is a very powerful option for creating an image from a SQL Server Azure IaaS VM via the process known as “capturing”.  The reason you want to capture an existing VM image from Azure running SQL Server is simplicity as well as the fact that you want to create multiple VMs running SQL Server.  Remember that we previously discussed the difference between an Azure image and disk and the use cases for both. This is one of those use cases where you want to use Azure to create an image, then capture it to use it to create other VMs running SQL Server. The capture process uses an existing Azure VM running SQL Server to create a VM image. This allows us to then create many SQL Server VMs from that image as we want.

Just want to introduce the PowerShell commands to stop the VM then to Capture the VM. Will not spend a lot of time on the parameters for this as you can find them all documented online. But you will stop the VM using Stop-AzureVM then save it as an image.

Create Azure VM and Capture as an Image

Here’s the steps we will go through to create a SQL Server VM then capture it as an image.

  1. BP Create Affinity group (for this and rest of demos). Affinity group provides a high degree of co-location within a data center to avoid randomized placement of resources. Tries to do same cluster and even same rack if possible.
  2. BP Create storage account
  3. Create existing Azure VM running SQL Server
  4. Log into VM and run sysprep. If you don’t do this the portal will not allow you to create image.
  5. Once it completes try to RDP in again – you cant
  6. Shutdown the image (enabled capture)
  7. “Capture“ the image (deletes the VM).  If I try to capture without checking sysprep box it will not allow me to do this.
  8. The VM from which this image is captured is no longer viable to run as a VM once it is captured. In fact, once the VM is captured it will be deleted from the Virtual Machines section and moved under Azure images.
    1. Show VHD is now gone as well as is VM
    2. Show the image VHD under Images VM tab

Capture VM Image from Azure VM

Once the image is captured the image appears in the VM Image Gallery. From there you can then create new SQL Server VMs from it as many as you want.

Continuing our introduction of PowerShell commands here we want to create the VM from the image. Just want to make you aware of the New-AzureQuickVM command and its many parameters which you would use here.

  1. Using VM Gallery to create a new Azure VM from captured image>
  • Realize that regardless of the VM size of the captured VM you can create any size VM you want from that image up to and including Extra Large. Note you can’t create a VM from an image or a disk with a size above that. So if the VM you captured was a size Large, you can create a VM of size small, a VM of size Medium, etc.  But you cannot create a A6 (4 cores , 28 GB) or A7 (8 cores, 56 GB).

We are not going to connect to SQL Server Mgmt Studio in this lesson as we have a more appropriate place in a later lesson.
A small but occasionally important difference between creating a VM from an image that is not a stock Azure Gallery image (uploaded sysprepd / captured VM) and one that is a stock image is that you CANNOT specify the storage account with which the new VM will be associated. By default you create the new VM in the storage account


In this module I discussed how to use an existing Azure VM instance to create an image, then taking that image and creating one or more VMs from that. We also mentioned about how you attach disks to the VM but did not show it as we will show it in a more applicable demo. But I wanted to introduce that concept at this point in time so you will be familiar with the process when we encounter it.

This is the second post for the mini-series entitled “Hosting SQL Server in Window Azure IaaS Fundamentals”. In this post I will teach you about Azure disks and images.  The concept of Azure images and disks is a key concept that I have found is at least initially often confusing to customers wanting to use SQL Server. As we progress into this mini-series we talk about some of the different ways to get SQL Server into Azure IaaS, such as capturing an existing Windows Azure image or loading a VHD into the Azure IaaS Cloud.  So you will need to understand what makes up an Azure disk, an Azure image, and when you would use either to host SQL Server in Azure IaaS.   I will review your licensing options for SQL Server on Windows Azure IaaS for disks and images, and offer recommendations for sizing of your VMs based upon your version of SQL Server.   I will offer some key points and summarize this post at the end.

When you use SQL Server in the Azure IaaS environment it is no different than any other hosting environment in that you need to properly license your software. Your choice of licensing options can be a big factor in the option you choose to get SQL Server into Azure IaaS. If you choose to use a pre-installed version of SQL Server that is already installed on the VM, you have two options for the VM size.
• Standard VM (in all sizes) that will cost you around ~$1700 per month for a Medium size VM., or $1830 for a Large (4CPU/7GB RAM)
• Memory intensive VMs comes in just two sizes:
o Large (4CPU/28GB RAM) at $2321 per month
o Extra Large (8CPU/56GB RAM) at $4643 per month

If you choose to install your own version of SQL Server on the VM, your Azure costs are based solely upon the base Windows Server VM. You can take advantage of Windows Software Assurance through Licensing Mobility to manage the licensing of SQL Server on your VM once you install it yourself. And if you move a VM with SQL Server already installed from your on premises VM you just use that license with no changes.

VM Sizing
When you deploy SQL Server to the Azure IaaS Cloud, you need to make the correct choice of Azure VM size to host the SQL Server. Regardless of the licensing mode you choose for running SQL Server on a VM you will want to use at least a size Medium. This contains two cores, and 3.5 GB of RAM in the current configuration. This is the minimum choice for SQL Server Standard Edition. If using the SQL Server Enterprise Edition to take advantage of advanced features such as Reporting or Analysis Services, you will want to use at least a size Large. This contains 4 cores and 7 GB of RAM in the current configuration.

An often overlooked feature of the chosen VM size is related to the size of your SQL Server database. You want to make sure that the VM size you choose will support the size of database in its current and future size. There is a limit on the size of an individual disks in Azure IaaS of 1 TB. If you have a SQL Server database that is say 10TB, would need 10 of these disks to accommodate it. And you would have to create multiple physical disks and span them into one large logical disk. That process is beyond the scope of this post. But realize there are limits on number of disks based upon the VM size you select. Refer to Virtual Machine and Cloud Service Sizes for Windows Azure for the available sizes and options for the virtual machine-based compute resources you can use to run your apps and workloads.

Azure Images
You will use Azure images as a base image with which to create one or more instances of VMs.

An Azure Image needs to be generalized so they can be used to generate specific VM instances. To generalize the VM Image, you must first run the Sysprep utility and check the Generalize checkbox. The Sysprep utility sterilizes a VHD by removing system-specific data. This permits you to use it generically as an image base for more than one VM instances. So if you run Sysprep on a VHD you can load it as an Azure VM Image. You will want to run Sysprep before you capture a VM image (to be discussed shortly).

Azure Disks
There are situations when you may not want to run Sysprep on a VHD since in some cases making that disk generic can render it useless for its desired application. But you still want to run your VHD in Azure. For instance, you may have a Domain Controller on your VHD and executing Sysprep would make it ineffective as a DC. You will also most likely not be creating duplicate VMs from an image of a DC and therefore not need to run Sysprep. If you don’t Sysprep the VHD then you can only load it into Azure as a VM Disk. This serves as a specific base for a unique VM. It is not a generic image from which you will be creating multiple generic images.

Key Points
• Azure Disks and Images look very much the same from a portal storage standpoint. Both VHDs in blob storage. The difference it in how they are prepared before they are loaded into Azure.
• VM Disks are generic images from Sysprep and create multiple generic Azure Image VMs
• VM Disks are not made generic with Sysprep and create a unique Azure Disk VM
• Azure VMs use Hyper-V fixed format VHDs. So if you upload a dynamically formatted VHD it will be converted to fixed format. This may cause an unexpected bloat during the upload and yield a size greater than the 127 GB disk size limit imposed for Azure IaaS VM images. Thus it is recommended that you create a fixed format VHD before you upload it to Azure and don’t rely upon the conversion from dynamic to fixed format during the upload process. VHDs can be uploaded using a PowerShell cmdlet Add-AzureVhd or using the CSUPLOAD SDK utility and must be 127Gb or less in size
• When you delete a VM Azure creates a Cloud service to preserve the DNS value as well as hold onto any resources that are linked to that VM such as VNETs and attached disks.

• Be conscious of the cost for the size of the M sizes – cost and capacity
• Licensing – BYOL or pay increased costs for VM
• Azure Images – Generic and allow you to create multiple VMs
• Azure Disks – Specific to configuration and create a single unique VM

This is the first post and introduction for the mini-series entitled “Hosting SQL Server in Window Azure IaaS Fundamentals”.

This blog series targets the IT Ops person who is either new to Windows Azure IaaS (Infrastructure as a Service), or has some experience with it, and is wanting to understand the key points to consider when installing and hosting SQL Server on a Windows Azure IaaS Virtual Machine (VM). My goal is to empower personnel from typically a smaller IT department trying merely to accomplish a basic install of SQL Server in the Azure IaaS environment. This person is not concerned about optimizing storage or access, or building in advanced enterprise features like data replication or high availability.

In this introduction I will discuss briefly the terms PaaS (Platform as a Service) and IaaS (Infrastructure as a Service) in terms of Windows Azure and the different levels of involvement, application, and responsibilities when using either in Azure. We’ll look at some of the compelling reasons as to why you would want to consider using SQL Server in an Azure IaaS environment. You will need to have an in-depth and thorough understanding of Azure disks and images which we will give you not only from an Azure standpoint but also how it applies to SQL Server in Azure IaaS. There are four common ways to provision and install SQL Server on Azure IaaS VMs depending upon your licensing scheme and need to preserve existing on premises SQL Server installations. And finally you will need to know the different responsibilities you have for administrating SQL Server on an Azure IaaS VM.

SaaS, PaaS, and IaaS
Let’s touch very briefly on the three common service terms just to make sure you understand them.
SaaS – Software as a Service. We will not spend any time on Software as a Service in this course. With this model you are just a consumer of the Cloud resources, such as using Office 365 and just paying to use that service.
PaaS – Platform as a Service. In Azure these are all the services you can leverage for simplifying the building and deploying your Azure Web applications. For instance, ACS, Service bus, HDInsight, WAAD, and Azure SQL Database. Note this the use of SQL Server in Azure IaaS VM in not the same as using Azure SQL Database, which is a PaaS-based relational database service offered by Azure to abstract away the low-level management details of SQL Server. Azure SQL Database is a subset of SQL Server and offered as a database service for you to quickly and easily get SLQ Server functionality for your Azure applications. We are talking here about using an Azure IaaS VM and installing a full version of Microsoft SQL Server – the same one you may use today in your application environment – onto that VM.
A common reason why you would use SQL Server over Azure SQL database is scope of functionality. For instance, Azure SQL Database supports only a subset of Transact-SQL for SQL Server. Azure SQL Database does not participate in distributed transactions, and does not use SQL Server agent jobs. And there are other differences as well. So customers will typically SQL Server instead of Azure SQL Database to take advantage of full SQL Server functionality to which they are used to.
IaaS – This model is where you basically rent one or more virtual servers and their virtual networks (if needed) to host your SQL Server, AD, SPS, etc enterprise services upon. This is what we will be focusing on in this course.

There are different levels of responsibility you assume in each of the models. With SaaS you don’t assume any of the responsibility for the apps, data, OS, network, and storage as it’s all done by the vendor.With PaaS you manage your apps and data, but the vendor manages the rest. In the case of Azure PaaS the vendor is Microsoft of course and they manage the updates as needed. You don’t have to mess with updates and maintenance.For IaaS, you manage more of the stack than PaaS but less than SaaS. You now manage the OS and patching/updating manually. More responsibility lies with the IT Ops team than for the other options.
Service Model Responsibilities

Why SQL Server in IaaS?
So you may be asking why would I want to move my SQL Server installation to an Azure IaaS virtual machine environment. Why not just run it in-house or better yet from a hosting provider? That’s a legitimate question to ask and there are valid reasons why in some cases you may want to remain out of the Azure Cloud. Both the Azure PaaS (Platform as a Service), which is all about your applications and storage in the Cloud, and the Azure IaaS (Infrastructure as a Service), more about Virtual Machines (VMs) and Virtual Networks, provide advantages over running in a public hosting provider or on premises.
• Operation expenditure vs. Capital Expenditures
• Rent vs buy – every three year PC replenish cycle
• Less support duties for IT Ops – at the hardware level such as resourcing hardware, managing uptime, and updates of machines
• Global locality- data and apps near your customers
• Quick provisioning – hours instead of weeks/months. This is especially useful in a testing or development environment where you can quickly spin up various testing configurations
• Auto-scalability and load-balancing for multiple VMs
• Availability SLAs – 99.95% availability for two or more VMs
• Flexible licensing and deployment options to match your budget or licensing strategy. This leads me nicely into this next slide…

These points describe the flexible options for SQL Server deployment into Azure IaaS.

Installing SQL Server on IaaS VM
To use SQL Server on an IaaS VM you will first have to decide how to install it. Remember, with an IaaS VM it’s like your own greenfield system. Outside of a core OS installation, you install, delete, and update, and manage the configuration on the VM all yourself.
So we will look at the different ways to get SQL Server running within Azure IaaS.
1. You can forklift an existing VHD image or disk with SQL Server already installed into the Azure Cloud.
2. You can install a clean Windows Server VM and install SQL Server on it manually.
3. You can select one of the standard SQL Server gallery images to give you a Windows VM with SQL Server already installed.
4. You can capture an image of an existing Azure VM with SQL Server currently installed as a base image from which you can create multiple VMs running SQL Server.

Administering SQL Server on IaaS VM
Once we have SQL Server installed we will look at different options to administer SQL Server using SQL Server Management Studio run locally, or via remote desktop into the VM hosting SQL Server. We will see how to configure the correct protocols, create inbound firewall rules, configure a login account for use the correct form of SQL Server login authentication, and expose a management endpoint on the SQL Server VM to allow this remote management.

An important issue when running SQL Server in the Cloud is how to backup SQL Server. There are different approaches you can take to be able to back-up a SQL Server database running in Azure. After the data is backed up you will want to understand where to store it as well.

And finally, monitoring SQL Server in Azure IaaS. You can do this simply using the Azure Portal to monitor basic VM counters only. Or you can use third party tools, such as Azure Watch, to get more detailed and in-depth monitoring capabilities, including different ways to aggregate the SQL Server performance counter metrics followed by subsequent automated actions that can be triggered by alerts.

The rest of the posts for this mini-series will expand upon most of these topics we discussed here and dig into detail for you.

I’m starting a new blog mini-series under the category “SQL Server Azure IaaS” to parallel my new moonlighting role developing courseware for Pluralsight. My first course, recently completed and entitled “Hosting SQL Server in Windows Azure IaaS Fundamentals“, is an introductory level course for those new to using SQL Server in an Azure IaaS environment. You can find it at this location. Here is a description of this introductory level curriculum.

This class provides essential knowledge to IT Operations persons working in the Windows Azure environment to set up a simplified version of SQL Server on Windows Azure IaaS.  Discusses the different options for installing and configuring SQL Server to ensure you have a basic working configuration.  Explains how to configure supplemental data disks and the options to manage a basic SQL Server installation in Windows Azure IaaS. Provides choices on how to backup SQL Server database in the Azure IaaS cloud.  Wrap up touching upon a few key topics that you might want to consider that will be covered in the more enterprise-focused advanced SQL Server on Azure IaaS optimization class.

Around the end of this December I will begin work on the follow-on course entitled “SQL Server in Windows Azure IaaS – Optimizations & High Availability” that I plan to complete around the first months or so of 2014. Here is a description of its proposed content.

This course discusses advanced topics for optimizing SQL Server 2012 performance and availability on Windows Azure IaaS Virtual Machines Topics include maximizing SQL Server disk performance within Azure storage, minimizing latency through Azure Virtual Network connectivity, properly securing administrative operations, and designing for high availability in case of failure. These design recommendations are key to correctly implementing configuration of SQL Server AlwaysOn Availability Groups, which are presented as the prime data replication option. As a part of AlwaysOn we discuss and show how to properly configure SQL Server VMs using Azure Availability Sets and Windows Server Failover Clustering (WSFC), SQL Server Availability Groups and Listeners to manage failover between VMs transparently.

This Saturday, Nov 9, I’m speaking at Code Camp in Raleigh, NC on Azure HA/DR.