If you haven’t noticed, AlwaysOn Availability Groups in Windows Azure now supports availability group (AG) listeners. Configuring the AG listener in Windows Azure is a multi-step process that includes:

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:

Windows Azure PowerShell June 2013 or later installed on the local client. Download at http://go.microsoft.com/?linkid=9811175&clcid=0x409.
On your local client, copy and paste the following script into a Windows Azure PowerShell session to configure LB endpoints and DSR each AG node (not necessarily each WSFC node)


 

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.

 

Fail over the AG and test the listener connection again. The query above should succeed and return a different server name.

bron: http://blogs.msdn.com/b/sqlalwayson/archive/2013/08/06/availability-group-listener-in-windows-azure-now-supported-and-scripts-for-cloud-only-configuration.aspx