• P10: x < = 128 GB
• P20: 128 GB < x < = 512 GB
• P30 : 512 GB < x < = 1023 GB

1. Attach a new Empty Data-Disk, create a volume and assign an available drive Letter
2. Stop/Close any application that might update data in the source drive. This is necessary for preserve data consistency.
3. Move data from the DataDisk you want to shrink to the new drive, using robocopy (Windows). Why robocopy? There is no better answer than the one provided here: https://blogs.technet.microsoft.com/josebda/2014/08/18/using-file-copy-to-measure-storage-performance-why-its-not-a-good-idea-and-what-you-should-do-instead NOTE: You might want to preserve Security information from the source drive (i.e. if the disk you are resizing contains SQL Server data, you need to keep the existing permissions for the SQL Service Account to that drive's folder). This is a sample command :

   robocopy E:\ F:\ *.* /j /e /sec /Xd "System Volume Information" "$RECYCLE.BIN" /Xo

   The command above will move all data from E: to F:. Copy will be optimized for large files (/J), and will affect al files and subfolders (/e). Security information will be preserved (/sec). The copy will ignore system folders like "Sys Vol Info" and the recycle bin (/Xd). Option /Xo will not overwrite existing data unless the source copy is newer than the one possibly existing at destination.
4. Remove the original DataDisk
5. Rename the new drive as the original.
6. Start/Run the Application you stopped on step 2.

• Keep the original FQDN for the cloud service.
• Reduce the downtime as much as possible.
• Use a single subnet.

Introduction

Abstract

For classic deployments, there is a high chance that the allocation request to create DS VMs on the existing cloud service might fail. The allocation request is actually submitted to the specific cluster in the Azure datacenter that was uniquely associated to the cloud service, when it was created the first time. If the type of resource requested (DS VMs requires specific hardware to run Premium Storage) is not supported by that cluster, the allocation request then fails. This behavior is known as “Cluster Pinning” and it is documented in this article: “Troubleshoot allocation failures when you create, restart, or resize Windows VMs in Azure”.

Stage 1: Adding the new nodes to the AlwaysOn AG Cluster

1. Create the new DS-Series VMs on the same VNet/Subnet of the existing replicas. Select a new cloud service name, i.e. “CloudService2”. Use an existing Image from the Azure Gallery with SQL Server already installed, or perform a manual installation of SQL Server (Enterprise Edition) on a Windows Server VM. It is important to run the same SQL Server version on all replicas. Provision a SQL Server virtual machine in the Azure Portal
2. It is recommended to have a separated storage account for each VM in the same Availability Set. This will reduce the impact of a potential service interruption event affecting the cluster on which your storage account is located. Having the VMs running on different storage clusters, will reduce the probability to have the storage layer acting as a single point of failure. I.E.: For the SQL Server Availability Set:

   Node SQLDB3 --> storage account name = a0xstorageccountsqldb3
   Node SQLDB4 --> storage account name = b9fstorageccountsqldb4

   Each storage account name should have a 3-digits prefix created by a custom hash function. This hash prefix has the purpose to influence the allocator to most likely put the desired storage account in a different storage cluster. It might be necessary to recreate the storage account wiht a different hash prefix, in case it will be cretaed on the same storage cluster. In order to check which storage cluster your storage account lays on, you can run the following command:

   nslookup storageaccountname.blob.core.windows.net

   The results will show the actual cluster name. I.e:

   blob.db5prdstr04a.store.core.windows.net

   "db5prdstr04a" is the actual storage cluster name. For a full comprehension of this behavior, refer to this article: Microsoft Azure Storage Performance and Scalability Checklist - AllServices
3. This guide will assume that all VMs lay on the same subnet. Make sure that your subnet has 2 available IP Addresses available in its address space. In case you have no more available addresses, if possible, try to move 2 resources on a different subnet. Take in to account that you can’t resize the address space of an existing Subnet unless it is empty (no IP are assigned).Use this article to understand how to move VM to a different subnet: How to move a VM or role instance to a different subnet
4. At a minimum, use 2 Premium Storage P20 disks where one disk contains the log file(s) and the other contains the data file(s) and TempDB.All details on performance optimization can be found on the following article: Performance Best Practices for SQL Server in azure Virtual Machines
5. It is recommended that, if possible, the file path (including the drive letter) of a given secondary database be identical to the path of the corresponding primary database. This is because if you move the database files when creating a secondary database, a later add-file operation might fail on the secondary database and cause the secondary database to be suspended. Manually Prepare a Secondary Database for an Availability Group (SQL Server)
6. Complete the configuration of the VM before joining it to the AG Cluster. The following steps are taken and adapted from the following article: Test Lab: Create an AlwaysOn Availability Group in Windows Azure End-to-End
   1. Create firewall inbound rules for:
      • TCP Port : 59999 (ILB probe port)
      • TCP Port : 1433 (AG listener port)
      • Program: sqlsrv.exe (SQL Server)
   2. Add server feature "Failover Clustering"
   3. Make sure that it is possible to run “nslookup” against the FQDN for the domain controller (i.e; dc1.contoso.com). If not, then you need either to set the DC as primary DNS for the VM, or add the DC as DNS server on the VNet: Manage DNS servers used by a virtual network (VNet)
   4. Join the VM to the Active Directory Domain and restart the VM
   5. Login as the built-in admin user and add a domain user to the VM local admins: In the Start menu, type “user“, then click Give administrative rights to a domain user.
   6. Connect to the SQL Server Instance and add the domain users as “sysadmins” role for the SQL Server Instance.
   7. From SQL Configuration Manager, set the SQL Server service account with the appropriate domain user.
   8. Assign a static IP to VM from one of the available addresses in the Subnet.
   9. Access to the Failover Cluster Manager and add node 3 to cluster: NOTE: disable “Add all eligible storage to the cluster”.
   10. Connect to node 3 through RDP (use the domain user). From SQL Configuration Manager, open SQL Server Instance properties and enable AlwaysOn feature:
7. It is now possible to add the node as a secondary replica of the existing Availability Group. The below article explains in details how this operation should be done: Add a Secondary Replica to an Availability Group (SQL Server) Follow section : “Manually Prepare a Secondary Database for an Availability Group (SQL Server)”. WARNING: this step could require very long time, depending on the amount of databases to restore and to their size. Node 3 should be configured as “Synchronous” replica in order to ensure no data loss. Manual failover will be required, since node 3 cannot be reached by the External Listener (and the LB). If the number of databases in the AG is too high, in order to prevent severe performance drain on the primary replica, the type of replication for node 3 can be set to “Asynchronous”, with risk of data loss.
8. Create an additional DS Series VM (node 4) and repeat all the above steps. Node 4 can be configured as “Asynchronous” replica with Manual Failover option. As soon as all the replicas will be fully synchronized, the situation on the AlwaysOn Dashboard should appear similar to the screenshot below: Note that SQLDB4 is being showed as "synchronizing" as it was configured as Asynchronous replica.

Stage 2: Reconfigure the AG Cluster

1. Make sure that all the client applications are not reaching the DB. There should not be data modification from this point on.
2. From the Failover Cluster Manager, locate the resource related to the Availability Group, switch to “Resources” tab, right click on the client access point associated to the AG Listener and remove it (the AG Role will be brought offline due to its dependency on the Listener, you can ignore this now)
3. On the Active Directory Domain Controller, open the AD Admin Center, locate “Computers” section and remove the computer object associated to the "AG listener".
4. Connect with SSMS to the current primary node and perform a manual failover against node 3.
5. Unjoin node 1 and 2 from AG (from SSMS connected to the primary role).
6. Change failover mode to Automatic for node 3.
7. Change availability mode to “synchronous commit” and failover mode to “Automatic” for node 4.
8. Suspend data movement. Availability group state will be set to Critical:
9. Evict nodes 1 and 2 from the cluster. From the Failover Cluster Manager locate the Nodes group, right click on Node 1, More Actions and Evict. Repeat for node 2.

Stage 3: Reconfigure the Cloud Service Deployments

1. Stop and deallocate all 4 VMs.
2. Run the PowerShell script below, to recreate the deployments. All nodes will be destroyed as well as the both cloud services. Node 3 and 4 will be recreated on CloudService1. Make sure that the variables are correctly set.

   #setup variables. Change these values accordinlgy to your environment
   $servicename1 = "CloudService1"
   $servicename2 = "CloudService2"
   $vmname1 = "sqldb1"
   $vmname2 = "sqldb2"
   $vmname3 = "sqldb3"
   $vmname4 = "sqldb4"
   $location = "North Europe"
   $actualvnetname = "the name of the VNET"
   
   #export VM configuration for node 3 and 4 on temporary folder.
   Export-AzureVM -ServiceName $servicename1 -Name $vmname1 -Path "C:\temp\$vmname1.config.xml"
   Export-AzureVM -ServiceName $servicename1 -Name $vmname2 -Path "C:\temp\$vmname2.config.xml"
   
   #backup VM configuration for node 1 and 2
   Export-AzureVM -ServiceName $servicename2 -Name $vmname3 -Path "C:\temp\$vmname3.config.xml"
   Export-AzureVM -ServiceName $servicename2 -Name $vmname4 -Path "C:\temp\$vmname4.config.xml"
   
   #destroy all VMs (keeping the disks)
   Remove-AzureVM -Name $vmname1 -ServiceName $servicename1
   Remove-AzureVM -Name $vmname2 -ServiceName $servicename1
   Remove-AzureVM -Name $vmname3 -ServiceName $servicename2
   Remove-AzureVM -Name $vmname4 -ServiceName $servicename2
   
   #destroy all cloud services 
   Remove-AzureService -ServiceName $servicename1 -Force
   Remove-AzureService -ServiceName $servicename2 -Force
   
   #import VM's config from xml file for node 3 and 4
   $vms = @()
   $vms += Import-AzureVM -Path "C:\temp\$vmname3.config.xml"
   $vms += Import-AzureVM -Path "C:\temp\$vmname4.config.xml"
   
   #recreate the cloud service1 as empty
   New-AzureService -ServiceName $servicename1 -Location $location
   
   #Recreate VM 3 and 4 under CloudService1, on the specified VNet
   New-AzureVM -ServiceName $servicename1 -VNetName $actualvnetname -VMs $vms

3. Final step: open SSMS, connect to node 3 and reactivate data movement (similarly to Stage 2 - step 8).

Stage 4: Finalize & Reconfigure External Listener

1. Add VM 3 and 4 to a new Availability Set (AS) to ensure 99,95% HA as requested by Azure Service Level Agreement (SLA). How to configure an availability set for virtual machines in the classic deployment model (Option 2)
2. It is recommended to reserve a Public IP Address to the cloud service and use it for the configuration of the Client Access Point. This will prevent the loss of the current VIP after an unexpected deallocation of all VMs under the same Cloud Service: How to reserve the IP address of an existing cloud service
3. Follow the step-by-step guide below and reconfigure the external listener. In case you do not remember the probe port and listener port, you can open the XML configuration file exported from VM1 (Stage 3 - Step 2) and look after endpoint configuration. Configure an external listener for Always On Availability Groups in Azure

Conclusion

You might face situations in which your users may need more space and for this reason you are then trying to resize the VHDx associated to the UPD disks, stored on your Azure RDSH Server.

Today the only method for easily resizing a VHDx file is by using the Resize-VHD cmdlet.
This cmdlet belong to the Hyper-V Poweshell modules and requires the Hyper-V role in order to work.

If you have tried to install the Hyper-V in Windows Server 2008 R2 or 2012 through Server Manager probably encountered the following message: The following message appears preventing you from continuing the process: Hyper-V can not be installed: The hypervisor is already running. 

This means that currently, there is no supported way for resizing VHDx disks inside an Azure VM.

Leveraging the blog post from Gilson Banin, How to Install Hyper-V on a Virtual Machine in Hyper-V, I will present you a workaround for this purpose.

DISCLAIMER

THIS WORKAROUND RELIES ON AN UNSOUPPORTED SCENARIO: WE ARE BASICALLY USING A TEMPORARY VM WITH THE PURPOSE TO HOST HYPER-V ROLE. THIS TEMPORARY ENVIRONMENT IS NOT SUPPORTED BY MICROSOFT. USE IT ONLY AT YOUR OWN RISK.

Prerequisites

Make backups of all the VHDX files that you are going to resize, before applying the below steps.

Setup the Management Environment

1. Create a new temporary VM (a small size will be fine, like A1) and join this VM to your existing VNET.
2. Force Installation of Hyper-V Role using this PowerShell command (from Gilson's blog post):
   

   Enable-WindowsOptionalFeature –Online -FeatureName Microsoft-Hyper-V –All –NoRestart
   

3. Restart the VM.
4. Add the "Hyper-V Management Toos" feature:
   
5. Map the shared folder containing your VHDXs on a local drive.

Resizing

Log in to the mgmt VM and run the following from an elevated PowerShell prompt:
 

Resize-VHD -Path <full_path_to_a_vhdx_file_to_reize> -SizeBytes <new_size>

i.e.:

Resize-VHD -Path F:\UserDisks\UVHD-S-1-5-21-318835583-3572637251-3921833130-3102.vhdx -SizeBytes 3GB

Expanding Volume Size

1. Mount the VHDX and open Disk Management:
   
2. Extend the Volume size to all the available space:
   
3. Do not forget to detach the VHDx
   

Validating

Now RDP into the environment and run "dir" from a command prompt default location and check for the free space:

3GB!

Finalize

You can destroy the management VM, once you finished with all the resizings.

References

The above procedure is based on information provided in this article:

• How to Install Hyper-V on a Virtual Machine in Hyper-V, https://blogs.technet.com/b/gbanin/archive/2013/06/26/how-to-install-hyper-v-on-a-virtual-machine-in-hyper-v.aspx
• Resize-VHD, https://technet.microsoft.com/en-us/library/hh848535(v=wps.630).aspx 

Have a good time Resizing!

Rossano

DISCLAIMER

How it works

1. Create a copy of the source database by using the TSQL command
   “CREATE DATABASE AS COPY OF”. Note: This step uses PowerShell.
2. Export the copied database using Import/Export REST Endpoints.
   Note: This step will use a .Net command line application based on the sample application shown in the following article:
   Windows Azure SQL Database Import/Export Service Community Sample Application
3. Drop the copy after the Export completed (still uses PowerShell). 

KNOWN ISSUES

• There is no retry-logic implementation in this first version. 
• If a .bacpac with the same name already exists in the destination storage account, step 2 will fail.
• There is no check-logic between each steps.
  I.e.: if the step 1 fails, the step 2 will be executed anyway.

Where is it?

PACKAGE CONTENTS:

• Copy_db.ps1:   PowerShell script for creating the transitionally consistent copy (step 1)
• WASDImportExport.exe and related dlls: the export application which uses public API (step 2)
• Drop_db.ps1: the PowerShell script for dropping the copied db (step 3)
• Run.bat: the batch file that will run the 3 steps. 
• The batch file is fully configurable with all the requested parameters:
•  ServerName
•  UserName
•  Password
•  StorageName
•  StorageContainer
•  StorageKey
•  EndopintURI
• There is a 5-minute time delay between step 1 and 2 and a 30-second time delay between step 2 and 3, in order to allow all asynchronous actions to be completed.
• WASD ImportExport Service Community Sample Application Edited.zip: this zip contains the Visual Studio Solution with the source code of the export app used in the batch  

WHAT TO DO?

1. You can replicate the batch file for each database you would need to export. 
2. Configure each batch file providing the source database name and the copied database name + credentials for Azure SQL Db + storage account details. 
3. You can schedule all the batches from any client machine which has Internet access  + SQL Native Client. You could use the Windows Task Scheduler (taskschd.msc). Alternatively, you could create a temporary Azure Virtual Machine with Basic size to schedule the above task. 

References

• How to: Use the Import and Export Service in Azure SQL Database, https://msdn.microsoft.com/en-us/library/azure/hh335292.aspx
• Windows Azure SQL Database Import Export Code Examples, https://sqldacexamples.codeplex.com/
• Automate tasks with Task Scheduler, https://windows.microsoft.com/en-us/windows-vista/Automate-tasks-with-Task-Scheduler-from-Windows-Vista-Inside-Out

Rossano

Prerequisites

1. A SQL Server 2014 instance configured for managed backup.
2. Managed backup enabled for at least one of your databases.

Step-by-Step Guide

1. Open the Restore Database window.
   
2. On Restore Database Window, choose Device source and click on "..." to select a backup device.
   
3. From the Backup media type drop down list, choose "URL" and click to Add.
   
4. Add and connect to the storage account containing the managed backups.
   
5. Select the fullbackup (.bak ) and all the TLOG backups within the latest fullbackup and the TLOG backup next to the time you want to restore.
   Example:
   Let's assume we want to restore our db at 2015-02-19 07:00:00.
   We need to choose the latest full backup immediately before that time, therefore the one of 2015-02-18 17:43:36.
   We also need to select all the TLOG backups taken between 2015-02-18 17:43:36 and 2015-02-19 07:13:42.
   
6. Press Ok to confirm the backup media:
   
7. Change the Destination Database name to a custom name, i.e. : "Restored-At-7".
8. You can click on Timeline and select a define the exacxt time for your Point-In-Time restore:
   
9. Specify an exact timeline to recover, i.e. 7:00:00 and click OK.
   
10. Verify if you need to take a tail-log backup. If not so, you can disable the option: "Take tail-log backup before restore".
    
11. Press OK. The restore operation will start. A confirmation message will be shown once the operation is completed.
    

Rossano