Syntax Highlighter

sábado, 10 de mayo de 2014

A few days ago I was wondering if one of the SQL Servers I deployed some months before was provisioned using a SQL Server “pay-per-use” image or was done by using a clean Windows Server 2012 R2 image and then manually installed the SQL Server on it. At the beginning the question seemed trivial, and that I could easily found that by simply logging into the VM and check the version number on SQL Server (i.e. by running SELECT @@version, or similar), but I was not really happy with what I found. Another way could be to check the billing details, the VM should be there in some way, but apart of the number of records that I had on those details plus the fact that those details were grouped by cloud service name, and that in some cases I would not have access to the billing information, this didn’t seem the correct path.

How to be immediately 100% sure that I was using one image instead of another? What if I have the same question about other “pay-per-use” VM image, and trying to found symptoms is not easy?

Looking at the Azure Portal

If you go to the Azure Portal and deploy a SQL Server VM via the VM Gallery, PowerShell or another way, you will currently find that in the VM dashboard there is a lot of information about the VM but no detail of what image are you paying for. The disk area shows you the current attached disks that in some way were used to initially provision the VM, but again, there is no information about which image was used:

By running this, you get different results from a VM that was provisioned by using a SQL Server image rather than a Windows Server one. The Source Image name can give you an idea of what are you paying for (this case I was paying for a SQL Server 2014 Enterprise on Windows Server 2012 R2, the April’s release):

With the VM Source Image Name you can now use the cmdlet Get-AzureVMImage to obtain the full information of the source image:

Running the cmdlet Get-AzureVMImage without parameters gives you the full list of current VM images ready to deploy.

Conclusion

After thinking twice, now seems obvious how to obtain the information I was looking for, and would be more obvious for those ones using Powershell day by day. It’s not my case, and day by day I learn a new highly useful cmdlet that will never forget. In fact, my RescueTime reports tell me that I’m increasing the time I daily spend on running Powershell cmdlets. Hopefully this helps you and encourages you to learn more about Azure cmdlets.