This is a troubleshooting guide for all those going through the joys and pains of configuring the availability group listener in the cloud. There are already guidance on how to configure the listener in Windows Azure or hybrid IT, but no known content that helps you when you run into issues with your listener – until now.

Please take a moment to look at it. And as always, feedback welcome!

]]>https://blogs.msdn.microsoft.com/sqlalwayson/2014/01/06/published-troubleshooting-guide-for-availability-group-listener-in-windows-azure/feed/1More Windows Azure E2E Scripts!https://blogs.msdn.microsoft.com/sqlalwayson/2013/12/05/more-windows-azure-e2e-scripts/
https://blogs.msdn.microsoft.com/sqlalwayson/2013/12/05/more-windows-azure-e2e-scripts/#respondThu, 05 Dec 2013 07:26:00 +0000https://blogs.cloudplatform.qa.msdn.wdslab.com/sqlalwayson/2013/12/05/more-windows-azure-e2e-scripts/In case you’re not already aware, I’ve written additional scripts for Windows Azure deployment of AlwaysOn Availability Groups for you to play with. Windows Azure provides an ever-expanding set of PowerShell cmdlets, which make automated deployments and administration of SQL Server on IaaS a reality. These scripts are there as proofs of concept to you as well as a starting point for you in building an end-to-end scenario that fits your needs (with the usual disclaimers “for testing purposes only” and such).

These script deploy end-to-end, including creating the VMs, configuring DC, SQL Server accounts, WSFC cluster, creating the availability group and even a fully functional listener for client connectivity. The cloud-only deployment script (first on the list) is truly end-to-end, which only requires an empty working subscription and minimal requirements for running the script. The hybrid deployment script have more complex requirements since it requires an existing on-premise domain, a site-to-site VPN, and some on-premise SQL Server machines in the deployment.

Hope you find it useful, and your feedback/comments are always helpful. J

Creating a load-balanced endpoint for the Windows Azure VMs that host AG replicas.

Ensuring that hotfix KB2854082 is installed on all cluster nodes (including any node that does not host an AG replica).

Opening the probe port in the cluster nodes that host AG replicas.

Manually creating a client access point in the cluster and configuring the IP address parameters to use the cloud service IP address, the probe port, etc.

Setting the listener port in SQL Server.

If you are looking for an easier way to configure the listener in Windows Azure, I’ve published a script at the Script Center. This script currently has limited applications, but hopefully I can expand the scenarios as time goes on – and if you shout in my ear. If your scenario fits all the requirements, then I hope this script can help simplify the process of listener creation. If you don’t fit all the requirements, you may still be able to “scriptify” most of the steps. So just read on.

Now back to the requirements for this script, the biggest limitations are as follows:

All AG nodes are running in Windows Azure and in the same subnet – Simply put, if the same listener requires multiple IPs, you can’t use this script. This means the script excludes to all multi-subnet scenarios such as hybrid IT.

All cluster VMs were created with PowerShell Remoting enabled – This part gets a little hairy, so get ready. If after GA (4/16) you created your cluster VMs using PowerShell, then they are all PowerShell Remoting enabled. If however, you created your VMs using the portal, you had a choice until very recently to enable PowerShell Remoting by means of a small check box. If you didn’t check that box, I won’t say you lose, but you definitely can’t use this script, at least not without manually enabling PowerShell Remoting on your VMs and tweaking the script. My personal opinion is: not worth the trouble.

Now, the Azure team make a small tweak on 7/16 that enables PowerShell Remoting for all portal-created VMs without giving you the option. So if you created your VM after 7/16, then you win!

So enough for the $winners, now for the -not($winners) – those who can’t use the script because of the above limitations. I’d like to provide some PowerShell snippets that you can run and that hopefully can make things simpler as well. Mainly, there are three scripts: one to run on your local client from which you normally administer your Windows Azure deployment, one to run on all your cluster VMs, and one to run on the primary replica VM. Understand that these scripts are much more “quick and dirty” than foolproof, so don’t expect the validation and error checking that you find in the downloadable script. Also, you should have created a working AG in Windows Azure before using these steps. So now, without further ado, here are steps:

Connect to RDP session for each WSFC node and download hotfix KB2854082 to a local directory.

In the RDP session for each WSFC node, copy and paste the following script into an elevated PowerShell session to install hotfix 2854082 and open the probe port in the firewall if the node is an availability group node. Be careful to run the script to completion on each node before moving onto the next node.

Test connection to listener from a domain-joined VM that is not in the same cloud service (DSR not supported from within the same cloud service). Use a longer login timeout since network messages are traversing the VM’s public endpoint. You can use sqlcmd or SSMS.

]]>https://blogs.msdn.microsoft.com/sqlalwayson/2013/08/06/availability-group-listener-in-windows-azure-now-supported-and-scripts-for-cloud-only-configuration/feed/5AlwaysOn in SQL Server 2014 CTP1https://blogs.msdn.microsoft.com/sqlalwayson/2013/07/04/alwayson-in-sql-server-2014-ctp1/
https://blogs.msdn.microsoft.com/sqlalwayson/2013/07/04/alwayson-in-sql-server-2014-ctp1/#commentsThu, 04 Jul 2013 16:34:54 +0000https://blogs.cloudplatform.qa.msdn.wdslab.com/sqlalwayson/2013/07/04/alwayson-in-sql-server-2014-ctp1/Failover Cluster Instances as well as Availability Groups have some great features coming up in SQL Server 2014.

]]>https://blogs.msdn.microsoft.com/sqlalwayson/2013/07/04/alwayson-in-sql-server-2014-ctp1/feed/3AlwaysOn Availability Groups Troubleshooting and Monitoring Guide published!https://blogs.msdn.microsoft.com/sqlalwayson/2013/06/06/alwayson-availability-groups-troubleshooting-and-monitoring-guide-published/
https://blogs.msdn.microsoft.com/sqlalwayson/2013/06/06/alwayson-availability-groups-troubleshooting-and-monitoring-guide-published/#commentsThu, 06 Jun 2013 20:55:11 +0000https://blogs.cloudplatform.qa.msdn.wdslab.com/sqlalwayson/2013/06/06/alwayson-availability-groups-troubleshooting-and-monitoring-guide-published/AlwaysOn Availability Groups Troubleshooting and Monitoring Guide provides information on troubleshooting the common AlwaysOn Availability Groups issues and monitoring the availability group health. We will try to keep updating this guide as new troubleshooting scenarios are documented so that you can conveniently find all the information in one place.

Please send us feedback on it!

]]>https://blogs.msdn.microsoft.com/sqlalwayson/2013/06/06/alwayson-availability-groups-troubleshooting-and-monitoring-guide-published/feed/2Upgrade and Update Guide for AlwaysOn Availability Groups published!https://blogs.msdn.microsoft.com/sqlalwayson/2013/05/30/upgrade-and-update-guide-for-alwayson-availability-groups-published/
https://blogs.msdn.microsoft.com/sqlalwayson/2013/05/30/upgrade-and-update-guide-for-alwayson-availability-groups-published/#commentsThu, 30 May 2013 09:06:29 +0000https://blogs.cloudplatform.qa.msdn.wdslab.com/sqlalwayson/2013/05/30/upgrade-and-update-guide-for-alwayson-availability-groups-published/The upgrade/update guide for availability group servers is now live on MSDN.