In the past two posts we were introduced to Azure PowerShell and some of the capabilities that are present in the AZ module. For this blog post we will start digging into some Azure concepts, some of what might be referred to as sub AZ modules and what we can do with these modules. With these two, we will see if we can connect the two concepts of PowerShell and the various components of Azure. For example, we find that subscriptions, context and other concepts come into play with many of these modules. As such, we will start exploring from some core concepts and the related PowerShell cmdlets.
Where to begin?
While trying to write this article I found myself in a bit of conundrum as this series of articles is supposed to be a natural progression of Azure PowerShell exploration (as well as an ancillary components in Microsoft Docs). What I find is that while working with certain cmdlets that I (and this is my own tendencies) tend to get drawn into other tangents that may prove interesting. In an effort to cover both connecting ideas as well as to cover a topic completely, expect to see some side tangents as topics that link to ones that are the main focus. The tangents will also be covered in future articles for this series.
To start off we can explore some basic information about our tenants. This information includes domains, Az Tenant properties, Subscriptions (what provides us rights to what in Azure), Azure Environment settings (there is a PS cmdlet for this) and more. Let’s dive in.
Azure Tenant Properties and More
Azure Tenant Details
Azure tenants have quite a few details that we can review and document. If we want tenant information, we can first look for cmdlets on this:
Get-Command *tenant | Ft -Auto
Which provides us with the
Get-AzTenant
This provides us this information:
Not a lot of information revealed, but we do have the unique IDs for our tenant. Let’s see what else we can find for cmdlets in the same module as the Get-AzTenant:
From the above screenshots, it looks like the ‘Az.Accounts’ PowerShell modules is the one we need to explore. Let’s start with only Get-Cmdlets:
Get-Command Get-* | Where {$_.Source -eq 'Az.Accounts'}
This provides these cmdlets:
Get-AzDomain Get-AzContext Get-AzContextAutosaveSetting Get-AzDefault Get-AzEnvironment Get-AzProfile Get-AzSubscription Get-AzTenant
First of these is the Domain for the tenant:
What if we use ‘| Fl’, does this provide more information?
Not really, and if we notice, the ID and Tenant ID seem to match what we retrieved. Why is this? Let’s check this cmdlet out real quick:
What we see is that Get-AzDomain is an Alias. It’s an alias for?
Get-AZTenant. So Running Get-AzTenant and Get-AzDomain should provide us with the same results, which is what we conformed above.
Now. On to the next cmdlet which is Get-AzContext.
Get-AzContext | Fl
That seemed to provide more information. We see that we have a Name, Account, Environment, Subscription, Tenant and Token Cache. We’ll see some more of this in our next cmdlets. Our next cmdlet is Get-AzContextAutosaveSettings:
Get-AzContextAutosaveSetting
We see local information that is stored for this session. Next we have Get-AzDefault. In a new/Greenfield environment, this cmdlet returns no information:
Why is that? Let’s review Examples for this cmdlet:
That is a pretty clear description of the issue. If we were to make customizations, these would then be displayed with this cmdlet. Next is Get-AzEnvironment:
Get-AzEnvironment | Fl
(This is a subsection to display the one my tenant is in)
Notice the large list of URLs and connection data points above. Also notice that the Name listed above matches Environment value from the Get-AzContext cmdlet. The same cmdlet also lists information for all regions. If we format the output to a table (FT), we can see this a little better:
If our tenant we in the German Cloud for example, we could then query just the information for that cloud like so:
Get-AzEnvironment -Name AzureGermanCloud | Fl
Which provides us the information for just this Azure Environment:
Next we have Get-AzProfile. This cmdlet, in a new or Greensfield tenant, will provide no results. This is to be expected. If we were to save a sessions credentials, the credentials used for Connect-AzProFile, we could then review these credentials later with the Get-AzProfile.
First, after connecting, we can save it like so:
Save-AzProfile -Path c:\Scripts\MyProfile.Json
Then we can select this profile for us to use:
Select-AzProfile -ProfileName 'c:\Scripts\MyProfile.Json'
And finally, we can then display thisprofiles information:
Get-AzProfile
The JSON file looks something like this:
Last but not least, the Get-AzSubscription cmdlet will provide this information:
Get-AzSubscription | Fl
Again, like the Get-AzContext, this provides us with some usable information for at least documentation purposes as well as some contextual information about the tenant we are using in Azure.
Conclusion
As you can see, there is a lot of base information in our Azure tenant and we are still just scratching the Azure surface. We’ll keep digging for more Azure information with PowerShell in next week’s article. Please comment below if you found this useful. Thanks!
