Introduction
When working in Azure or the Microsoft Cloud environments in general, you will experience that most information are accessible using Powershell. However, there is a catch in regards to what the different modules provides.
When you are done reading this post, you should have a better understanding about which modules connects to which areas in Azure and Exchange online and how they will be able to help you in your quest for daily maintenance or scripting of tasks.
For those of you who don’t know what a module is here is the short version of an explanation. A module is basically a package containing cmdlets and aliases that can be used to create, read, change or delete dependent on the purpose of the specific module.
All of the described modules are publicly available by use of the install-module command.
But let’s get to it, shall we?
AZ Modules
The AZ modules is the current Azure powershell modules. The AZ modules supersedes the older AzureRM modules as the current module to manage and build resources in Azure, using powershell.
If you find a script or have legacy scripts where the command “azurerm” is used, you will in most cases be able to find the exact same command by replacing azurerm with az.
You can install the modules directly from powershell using one of the below commands.
|
1 2 3 4 5 |
#If you wish the module to be installed for all users install-module -Name az #If you wish the module to be installed for the current user install-module -Name az -Scope CurrentUser |
After the module is installed, you will need to connect. If you have a user that only have access to one specific tenant, all you have to do is to connect using the following command.
|
1 2 |
#This command will connect to the azure environment Connect-AzAccount |
However, if you have access to multiple tenants you will soon learn that you can see subscriptions across all tenants. So for instance if I run connect-azaccount and connects, and following that runs the “Get-AzSubscription” you will notice that this shows subscriptions across 3 different tenants.
This is one of the details that makes the az modules special, since they do not connect to a specific tenant but can connect to all tenants where the specific user has access with the privileged that the user has in the given tenant.
To connect to a specific tenant, and perhaps even a specific subscription, we need to specify the tenant and subscription that we wishes to work on. This can be done by either connecting and then selecting the right subscription or by connecting to the correct subscription and tenant on the connection cmdlet like this
|
1 |
Connect-AzAccount -TenantId "105f4443-3333-2222-1111-5368711706fb" -SubscriptionId "74eb4444-3333-2222-1111-999999998eca" |
The Az module is split up into 75 submodules, that will be installed when running the above command. Each submodule is designed to handle a specific subsection of commands.
So for instance the az.compute module is designed to handle everything related to virtual machine creation and maintenance in Azure. But we do not have to specify which module to use when utilizing the az module, so if we wish to create a VM right now, and we don’t care about anything but the name, we could simply run the following command.
|
1 |
New-AzVM -Name MyVm -Credential (Get-Credential) |
Which will create a VM named “MyVm” in the subscription where we are currently located, in a resource group named “MyVm”.
To create an example. A VM in Azure like most resources are attached to a subscription. If we run the get-azvm we will only be shown the specific VM’s in a given subscription, but if we wish to see all VM’s in a tenant or a selection of subscriptions, we need to run through all subscriptions, one by one to get the data we needs.
|
1 2 3 4 5 6 7 8 9 10 11 |
$tenantid = "105f4443-3333-2222-1111-5368711706fb" #Insert tenant ID here Connect-AzAccount -tenantid $tenantid $subscriptions = get-azsubscription -TenantId $tenantid $allvms = @() foreach($subscription in $subscriptions) { Select-AzSubscription -Subscription $subscription -Tenant $tenantid $allvms += Get-AzVM } |
The result of the above script would be an array containing all the servers in this specific test tenant that I ran this on.
|
1 2 3 4 |
ResourceGroupName Name Location VmSize OsType NIC ProvisioningState Zone ----------------- ---- -------- ------ ------ --- ----------------- ---- LBTESTSETUP_DEST Testserver01 westeurope Standard_D4s_v3 Windows testserver01429 Succeeded CHOCOTEST chocotestVM westeurope Standard_D4s_v3 Windows chocotestvm281 Succeeded |
However, not all modules are installed with the base package. In total, there are 163 different az.* modules, but of these only 75 are included when installing the az module. So for some resources or information it requires us to install a module manully. An example of one of the missing modules is the az.costmanagement. If you for some reason requires the features in one of these packages you can install them using the install-module command.
Exchange Online
For everyone working in Exchange online the powershell tools are a must. Not only are there a lot of settings that can only be changed using powershell, but reading data from the users or bulk changes are done a lot faster using powershell than ECP, not to mention the advantage of sourcing data from different sources into the same output.
First things first, to install the module, you have to download it from the powershell gallery
|
1 2 3 4 5 |
#If you wish the module to be installed for all users install-module -Name ExchangeOnlineManagement #If you wish the module to be installed for the current user install-module -Name ExchangeOnlineManagement -Scope CurrentUser |
Once it’s installed, you connect to your environment using the connect-ExchangeOnline cmdlet. You can either connect to your own tenant, or to a tenant where your user have the appropriate rights for exchange management.
|
1 2 3 4 5 |
Connect to own tenant Connect-ExchangeOnline -UserPrincipalName <UPN> Connect to guest tenant Connect-ExchangeOnline -UserPrincipalName <UPN> -DelegatedOrganization orgname.onmicrosoft.com |
And from there, we can start handling everything such as creation, changing or simple get operations or pulling data for reports.
So what can we use this module for? Well, a lot of things. It’s used to bulk migrate user, see status for migrations, enable access to shared mailboxes, or even as a central way as configuring access to all users calendars.
So let’s take an example, the following script exports all calendar permissions set on the users calendars. It does this by first finding all mailboxes in the organization, and then run through them one by one for calendar permissions.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
$data = get-mailbox -ResultSize unlimited $trigger = 0 foreach($i in $data) { $trigger++ $i.UserPrincipalName $text = "Working through: " + $trigger + " of " + $data.count + " in total - Name: " + $i.displayname $calendarFolder = Get-MailboxFolderStatistics -Identity $i.UserPrincipalName -FolderScope Calendar | Where-Object { $_.FolderType -eq 'Calendar'} | Select-Object Name, FolderId Write-Host $text $value = $null $calender = $null $value = $i.UserPrincipalName +":\" $calender = $calendarFolder.Name Get-MailboxFolderPermission -Identity $value$calender | Select-Object Identity,FolderName,User,@{name="AccessRights";expression={ [string]::join(",",@($_.accessrights)) }},@{name="Mail";expression={ [string]::join(",",@($i.UserPrincipalName)) }},@{name="DisplayName";expression={ [string]::join(",",@($i.DisplayName)) }},@{name="RecipientTypeDetails";expression={ [string]::join(",",@($i.RecipientTypeDetails)) }} | export-csv c:\temp\permissions.csv -Encoding Unicode -Delimiter ';'-NoTypeInformation -Append } |
The output of that code is an exported csv file, that would look something like this and which would provide an overview of all calendar permissions in that specific organization
MSOL
MSOL is a bit hard to explain – it’s still nessesary in many cases, but at the same time it’s being deprecated some time in the future. It holds a lot of the same data azure the AzureAD and ExchangeOnline module, but still contains some variables that are not present in those modules.
So you might not need it, but there is no guarantee.
The module can be downloaded from the powershell gallery
|
1 2 3 4 5 |
#If you wish the module to be installed for all users Install-Module -Name MSOnline #If you wish the module to be installed for the current user Install-Module -Name MSOnline -Scope CurrentUser |
When it’s installed, you have to connect to the module. To connect you can run the following command
|
1 2 |
Connect to own tenant Connect-MsolService |
Basically, if there is user information you can’t find on the two previously named modules, msol can be your saviour.
Final thoughts
This is only a select few of the modules in existence for your cloud services, but given the area that I work in, these are the ones I use the most.
Each of them have an area in Microsoft Cloud Environments where they are the powershell tool at hand for handling and solving both incidents and day to day maintenance.
