Get-AzureRmLocation is missing from ARM PowerShell 1.x

[pcgeek86]

Please add back Get-AzureRmLocation. We have had very lengthy e-mail discussion on this, and other MVPs are asking for it as well. @devigned @ravbhatnagar @jodoglevy

Cheers,
Trevor Sullivan
Microsoft MVP: PowerShell
http://trevorsullivan.net
http://twitter.com/pcgeek86

[MaxTrinidad]

I mention about this issue for some time since 10/20/2015 after working on my blog on converting from classic Azure service scripting to use AzureRM. I waited until the latest release of version 1.0.2 and still this command is not available.

I'm been trying to follow the documentation "Create a SQL Database using PowerShell" in the section "Create a resource group, server, and firewall rule" which uses the "Get-AzureRMLocation". This information is totally inaccurate and need to be update with a workaround.

[devigned]

@ravbhatnagar I'm leaving this one to you. Please respond how you would like to handle this.

[ravbhatnagar]

@pcgeek86 Yes we have had pretty lengthy discussion on this one. We have also received other feedback on this. We are evaluating the feedback and would have an update on this soon.

Would also love to get your feedback on Get-AzureRmResourceProvider cmdlet which now has location details in the output along with a Location param. Please let us know if this helps achieve some of your scenarios.

@MaxTrinidad We will get the documentation updated.

[pcgeek86]

@ravbhatnagar We have already hashed this out repeatedly. It is getting exhausting repeating myself. Some people are looking for location information, regardless of the Resource Provider.

• Get-AzureRmResourceProvider - Retrieves a list of Resource Providers, with the locations that they exist in.
• Get-AzureRmLocation - Retrieves a list of Azure Regions (Locations), and a list of Resource Providers supported in them.

It is literally the exact same data, presented in two different formats (perspectives). Some people are looking for one thing or the other, so there should be commands to satisfy each need.

Cheers,
Trevor Sullivan
Microsoft MVP: PowerShell

[ravbhatnagar]

@pcgeek86 - I truly appreciate your efforts in advocating for what you believe is the right thing to do. As I mentioned, we are evaluating the feedback we have been getting on this and will provide an update soon.

I would like to point out that we have heard from customers, both internal and external, about the confusion around a location being listed in the output of Get-AzureLocation but still a resource cant be created in that region. I am sure you understand the reason behind this. But a lot of our customers don't and we should be mindful of that.

So yes, we have no problem in adding this cmdlet which provides a location based output. But we want to make sure we provide the right guidance to our customers around which cmdlet to use for which scenario so that it doesn't get confusing.

Although there are few use cases for knowing all the publicly available Azure regions, the #1 use case is still knowing which resources can be provisioned in which region for "your" subscription. So, yes, we will keep pointing out the differences because as I said not everyone has the same kind of experience.
cc @chadiel @vivsriaus @rjmax

[pcgeek86]

@ravbhatnagar @chadiel @vivsriaus Here's yet another request for it.

http://stackoverflow.com/questions/34627191/cannot-use-get-commands-in-azure-rm-portal-using-powershell

Cheers,
Trevor Sullivan
Microsoft MVP: PowerShell

[ravbhatnagar]

@pcgeek86 @MaxTrinidad @rhencke @vhusker @abombss @jychunyjh @jeffpatton1971 @iamshital @jodoglevy @chadiel @vivsriaus
Adding a few folks to gather some feedback on this. Please add others as needed. We want to make sure we do the right thing for our customers. As things stand currently, the Get-AzureLocation cmdlet was removed in the 1.0 release.
The cmdlet Get-AzureLocation used to list all the publicly available azure locations and did not take into consideration things like ring fencing. While this was pretty confusing and misleading to some customers, it looks like some folks did use it for certain scenarios.

We just wanted to get a sense from folks if the below solution would work for them-
Get-AzureRmLocation – would return all the publicly available azure locations and does not do subscription level filtering. So it will output all the location metadata like display name, normalized name, co-ordinates and any other metadata we introduce over time. It will not contain any provider related information.
Would the above cmdlet be helpful to folks?

Thanks for your help here!!

[pcgeek86]

@ravbhatnagar What is "ring fencing?"

[ravbhatnagar]

@pcgeek86 - "ring fencing" is a term which applies to certain regions like India and Australia which denotes that only azure subscriptions/accounts from that region can create a resources in that region. So a subscription based in Australia only would be able to create resources in the AU region (Australia). A US based azure subscription wont be able to create resources in the AU region or the India region.

[ravbhatnagar]

Folks - would really appreciate your feedback on this?

[pcgeek86]

I think you know where I stand @ravbhatnagar . If you need clarity, let me know.

You'll probably want to use other tools to draw people's attention to this thread, if you want more feedback though. I doubt many people are proactively watching it. Put it on Twitter, e-mail other Azure customers directly, promote it internally at Microsoft, etc.

[ravbhatnagar]

Was able to get more feedback on this from the Advisors group. We plan to fix this for May release.

[ravbhatnagar]

@pcgeek86 @MaxTrinidad - Below is the proposed output from the Get-AzureRmLocation cmdlet -
Location - Name of the region (EastUS)
Display Name - Display Name of the region (Ex- East US)
Providers - Lists of resource providers supported in that region (ex- Microsoft.Web, Microsoft.Sql etc.)

Please let me know if this is reasonable.

[pcgeek86]

Yes

[ravbhatnagar]

Fixed in May 2016 release.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @rthorn17