How to Connect to Azure Stack via Powershell

Sometimes, when a new product is introduced to the market, some of the basic things are either missing, or not concisely documented. In this case since Azure and Azure stack use the same API and share the same cmdlets, you connect the same way right? The answer is yes, in theory. What's missing from that answer is that for Azure stack you need to setup your Powershell connection using the Add-AzureRMEnvironment command to set the specific AAD endpoints, RM API endpoint, Gallery Endpoint, etc. Since this is a mix of Azure and Azure Stack specific information, we thought a nice, concise script was in order. Now we’re assuming that your stack instance is running TP1 (this should work on TP2 when it ships, but we obviously haven’t tested it yet).

Step 1: Ensure you have the right Powershell Cmdlets on the machine you’ll be running from. For simplicity this is likely the client VM, but you could be running from your VPN connected workstation or, if your a little creative, someplace else. We’re assuming your connected.

• https://github.com/Azure/azure-powershell/releases/download/v1.2.1-February2016/azure-powershell.1.2.1.msi

We’ve found at present this version works well with TP1.

Step 2: Ensure you have some stuff setup in Azure Stack to see:

• Start by opening a browser to portal.azurestack.local, login with the admin AAD account used during setup and create a plan and offer.
• Next, Connect to AAD and a create test AAD user. No special rights needed.
• Login with the test user and Create a subscription using the offer you created. Take note of the subscription name (Hint: by default its named after the offer).
• You should now be able to create some resources. We recommend creating a simple resource group with a single VM and/or a storage account (depending on if your VM Resource Provider is behaving itself). Idea here is to create some objects you can see in Powershell.
• Now hang out and wait for that to complete.

Step 3: Fire up Powershell on the client copy, paste and edit the below script and then run it.

In the script you need to set the following:

• $AADUserName value to the UPN of the test account you used in AAD
• $AADPassword value to the password of the test account you used in AAD
• $AADTenantID value to the domain name used by your AAD tenant.
• If your the creative type and aren’t running a stock instance of TP1 you might need to adjust some DNS names in the script from azurestack.local to match your environment.
• On the Get-AzureRMSubscription command, set the –subscriptionName value to the name of the subscription you created.

That should do it. Any questions/issues, leave a comment.

[powershell] $AADUserName='YourAADAccount@Yourdomain' $AADPassword='YourAADPassword'|ConvertTo-SecureString -Force -AsPlainText $AADCredential=New-Object PSCredential($AADUserName,$AADPassword)

$AADTenantID = "YourAADDomain" Add-AzureRmEnvironment -Name "Azure Stack" ` -ActiveDirectoryEndpoint ("https://login.windows.net/$AADTenantID/") ` -ActiveDirectoryServiceEndpointResourceId "https://azurestack.local-api/" ` -ResourceManagerEndpoint ("Https://api.azurestack.local/") ` -GalleryEndpoint ("Https://gallery.azurestack.local:30016/") ` -GraphEndpoint "https://graph.windows.net/"

$env = Get-AzureRmEnvironment 'Azure Stack' Add-AzureRmAccount -Environment $env -Credential $AADCredential -Verbose Get-AzureRmSubscription -SubscriptionName "youroffer" | Select-AzureRmSubscription Get-AzureRmResource [/powershell]

Welcome to Azure Field Notes

We’re back! Several years ago a group of us used to post to TheCloudBuilderBlog.com. There we focused primarily on System Center based private clouds, Orchestrator, SCVMM, SCSM and SCOM. Over the past several years the marketplace has changed dramatically. System Center is moving to cloud thru tools like OMS and App Insights. Microsoft’s public cloud has a level of maturity in the marketplace, and  everyone is talking about cloud. We’ve changed as well. We’ve worked on a number of different enterprise cloud projects, both public and private, both Microsoft and non Microsoft since then. As a result, we’ve decided to share our knowledge with the wider community and re-launch. With the re-launch and shift in topics comes a new name. Azure Field Notes. This refers to our experiences coming from the field, and the focus on Azure and Azure Stack. (That’s right, we’re going to cover Azure Stack as well). We’ll still touch on System Center topics occasionally, especially with regards to integrations, but the focus of this blog will be covering the Microsoft Cloud. We’ll cover deep technical topics, scripts, and how to guides, but we’ll also cover higher level strategic thoughts, where we see the market going, what we believe is important for an enterprise to think about as part of the journey to cloud. And of course, as always, any posts, opinions, or information on this site is our own and does not represent the positions of Microsoft or our employers.