Lessons Learned from Using Azure Automation with PowerShell Scripts

Debugging, Cost, and Tracking for Azure Automation PowerShell

As you might have noticed, I’ve spent some time recently investigating how to exploit Azure Automation with Microsoft 365 PowerShell modules, exploring topics such as using Microsoft Graph PowerShell SDK with Run As accounts to Managed Identities with Exchange Online.

I cheerfully admit that I am still an Azure Automation PowerShell novice, but I’ve enjoyed probing the ins and outs of topics like Managed identities and understanding how things fit together to run jobs on the Azure infrastructure. Working with Azure Automation is certainly different to putting together PowerShell scripts for interactive use, but it’s a technique that I believe Microsoft 365 tenant administrators should master because it’s a great (and secure) way to run resource-intensive scripts on a scheduled basis. Or indeed, scripts that need to run periodically to adjust settings, like the one to update new teams to block team members from creating regular channels. In any case, here are three lessons I’ve learned over the last year or so.

Debugging Azure Automation PowerShell is Different

Debugging code in Azure runbooks is one of the more interesting challenges. When a runbook (PowerShell script) executes, it essentially runs on a headless server. Your code either runs or it doesn’t, and there’s no way to step through commands in a script as you can interactively. If code doesn’t run as expected, it becomes a matter of breaking code up into segments to identify where the problem occurs and inserting old-time output statements to gain clues about what might be going wrong.

Microsoft documentation recommends using the output stream to log progress and information about processing. That’s just a sophisticated way of saying that you insert Write-Output commands in the code to output details of variables. I did this with PRINT statements when I was a COBOL programmer in the 1980s and I’m still doing it today. Technology changes, but some debugging techniques remain in situ. It works both for the output of scheduled jobs and when you execute a runbook in the test pane.

Figure 1 shows the output of a run of the Azure Automation version of the script used to generate the Microsoft 365 Groups Expiration Report. The original article explaining the principle behind the script is available here.

Cost of Azure Automation PowerShell is Minimal

You need a paid Azure subscription to use Azure Automation. The subscription pays for costs such as the small amount of storage used to store runbooks and the compute costs for running the code. Originally, I was concerned that I would rack up considerable costs, especially when running scheduled jobs. However, the actual costs are very modest and most months I end up with a total of a couple of dollars.

The bottom line is that running PowerShell scripts with Azure Automation is unlikely to break the bank unless you execute some highly resource-intensive scripts on a very frequent basis. But in saying that, it’s always a good idea to keep an eye on costs until you’re happy that you understand the cost profile. Suffice to say that I am no longer concerned about expenditure on Azure Automation, at least not for the work that I do (famous last words…).

Tracking Access for Azure Automation PowerShell

Tenant administrators tend to like to know what’s happening. To gain an insight into the usage of Azure Automation accounts, we can analyze the Azure AD sign-in logs for the service principals of these accounts. For example, this code uses the Microsoft Graph PowerShell SDK to connect and fetch audit records for service principal events. It then groups the records to show the count of events for each service principal:

Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"
Select-MgProfile Beta
[array]$AuditRecords = Get-MgAuditLogSignIn -Filter "(signInEventTypes/any(t:t eq 'servicePrincipal'))" -Top 2000 -Sort "createdDateTime DESC"
$AuditRecords | Group-Object ServicePrincipalName | Sort-Object count -Descending | Format-Table Name, Count

Name                                                              Count
----                                                              -----
ExoAutomationAccount_Y6LgjDYIfPnxmFzrqdbaClsnTD/gN4BNnVMywiju5hk=   119
Graph Microsoft 365 Groups Membership Report                         84
Clean up Exo Mailboxes                                                6
PS-Graph                                                              6
ServiceCommunications                                                 5
PopulateOrgContacts                                                   2

Each access to a resource (like signing into the Graph) generates an audit record.

$AuditRecords | ? {$_.ServicePrincipalName -eq "Clean up Exo Mailboxes"} | Format-Table ServicePrincipalName, CreatedDateTime, ResourceDisplayName, ipaddress

ServicePrincipalName   CreatedDateTime     ResourceDisplayName IPAddress
--------------------   ---------------     ------------------- ---------
Clean up Exo Mailboxes 12/08/2022 05:33:12 Microsoft Graph     51.171.212.123
Clean up Exo Mailboxes 07/08/2022 15:32:34 Microsoft Graph     51.171.212.123
Clean up Exo Mailboxes 03/08/2022 16:24:01 Microsoft Graph     78.17.104.68
Clean up Exo Mailboxes 02/08/2022 23:23:50 Microsoft Graph     78.17.104.68
Clean up Exo Mailboxes 02/08/2022 17:08:26 Microsoft Graph     51.171.212.123
Clean up Exo Mailboxes 01/08/2022 20:41:35 Microsoft Graph     51.171.212.123

In passing, the large number of sign-ins for the service principal for the app used by the Graph-based Microsoft 365 Groups Membership Report arise from a mistake I made when publishing the report script in GitHub. Unhappily, I included the tenant identifier and app identifier for my tenant (now fixed), and people continue to try to run the script using those values. In the last week, I’ve seen sign in failures from many locations, as I discovered by looking at sign in logs with a failure status.

ForEach ($R in $AuditRecords) {
 $Status = $R.Status.ErrorCode
 $City = $R.Location.City
 If ($Status -ne 0) {
 Write-Host ("{0} Status {1} City {2}" -f $R.CreatedDateTime, $Status, $City, $R.IPAddress) }
}
26/08/2022 20:20:49 Status 7000215 City Sanger
26/08/2022 18:16:44 Status 7000215 City Edmonton
25/08/2022 19:34:10 Status 7000215 City Montreal
25/08/2022 19:33:47 Status 7000215 City New Berlin
25/08/2022 19:24:09 Status 7000215 City Montreal
25/08/2022 11:16:23 Status 7000215 City Leigh
25/08/2022 11:11:15 Status 7000215 City Amsterdam
25/08/2022 10:42:51 Status 7000215 City London
25/08/2022 07:54:12 Status 7000215 City Frederiksvaerk
24/08/2022 19:44:03 Status 7000215 City Montreal
23/08/2022 20:57:05 Status 7000215 City Wellington
23/08/2022 13:43:48 Status 7000215 City Kobenhavn

The script contains a note to tell people to change the values to match a registered app in their tenant, but it seems to be ignored. The moral of the story is to always be sure to obscure authorization details in scripts available publicly.

Azure AD sign-in records for managed identities are fetched with:

[array]$AuditRecords = Get-MgAuditLogSignIn -Filter "(signInEventTypes/any(t:t eq 'servicePrincipal'))" -Top 2000 -Sort "createdDateTime DESC"

These records tell us what resources (services) the scripts run by the managed identity use. For instance, these records are generated by calls made to connect to Teams (as an administrative app), run a Graph request, fetch secrets from Azure Key Vault, and fetch an access token using the Azure management API.

$AuditRecords | Format-Table CreatedDateTime, ResourceDisplayName

CreatedDateTime     ResourceDisplayName
---------------     -------------------
30/08/2022 15:35:02 Skype and Teams Tenant Admin API
30/08/2022 15:35:01 Microsoft Graph
30/08/2022 15:35:00 Azure Key Vault
30/08/2022 15:35:00 Azure Key Vault
30/08/2022 15:35:00 Azure Key Vault
30/08/2022 15:34:49 Windows Azure Service Management API

More to Discover About Azure Automation PowerShell

A great deal of information is available for administrators to fetch and analyze to help understand the usage of Azure Automation in their tenant. I’m not done with my investigations yet. I expect to find other interesting aspects of Azure Automation to investigate. And when I do, I shall share my findings.

---

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.