Getting started with Azure Automation Accounts: automating Microsoft 365 and Azure administration

If you have spent any amount of time administering Microsoft 365 or Azure, you’ve likely found yourself performing the same task repeatedly. Perhaps you’re generating reports on licensed users. Maybe you’re cleaning up inactive accounts. You might be reviewing SharePoint permissions, auditing mailboxes, or maintaining Azure resources.

At first, these tasks feel manageable. Then the environment grows. What started as a ten-minute task suddenly becomes a monthly project. Eventually, someone asks the obvious question:

“Can’t this be automated?”

In many cases, the answer is yes.

One of the most powerful and often overlooked tools available in Azure is the Azure Automation Account. It provides a cloud-based platform for running PowerShell scripts, known as runbooks, without requiring a dedicated server, scheduled task, or administrator workstation.

In this blog, we’ll walk through Azure Automation Accounts at a high level and discuss the major components required to build an automation solution from start to finish.

What is an Azure Automation Account?

An Azure Automation Account is a cloud service that allows organizations to execute automated tasks using runbooks.

Think of it as a PowerShell execution environment hosted by Microsoft.

Instead of creating scripts that must run from a server in your environment, the scripts execute within Azure.

Common use cases include:

• Microsoft 365 reporting
• User provisioning and deprovisioning
• SharePoint administration
• Exchange Online management
• Azure resource management
• Scheduled maintenance tasks
• Compliance reporting
• License auditing
• Virtual machine startup and shutdown operations

For many organizations, Azure Automation becomes the foundation for recurring administrative tasks.

Why use Azure Automation?

There are several advantages to using Azure Automation versus traditional scheduled tasks.

No dedicated server required

A traditional automation solution usually requires:

• A Windows server
• Scheduled tasks
• Service accounts
• Script storage
• Patching and maintenance

Azure Automation eliminates much of that infrastructure.

Centralized script management

Runbooks are stored in a central location rather than scattered across servers and administrator workstations.

Scheduling capabilities

Runbooks can execute automatically based on schedules.

Examples include:

• Every morning
• Weekly
• Monthly
• Specific days and times

Cloud-based authentication

Automation Accounts can leverage Managed Identities, reducing the need to store usernames and passwords within scripts and providing a more secure authentication method. Microsoft specifically supports both system-assigned and user-assigned managed identities for Azure Automation Accounts.

Step 1: Obtain an Azure subscription

The first requirement is an Azure subscription.

Everything in Azure ultimately resides within a subscription.

If your organization already uses Microsoft 365, there is a good chance an Azure tenant already exists behind the scenes.

However, Azure Automation requires an Azure subscription where resources can be deployed and managed. Microsoft identifies an Azure subscription as a prerequisite when deploying Azure Automation solutions.

Step 2: Create a Resource Group

Before creating an Automation Account, a Resource Group should be established.

A Resource Group acts as a logical container for Azure resources.

Think of it as a folder for related Azure services.

For example:

• RG-Automation
• RG-Operations
• RG-M365-Automation

Keeping automation-related resources together simplifies administration, permissions management, and troubleshooting.

Step 3: Create the Automation Account

Once the Resource Group exists, the next step is creating the Automation Account itself.

When creating the Automation Account, administrators will typically specify:

• Subscription
• Resource Group
• Account Name
• Azure Region

This Automation Account becomes the central location where runbooks, schedules, modules, variables, credentials, and managed identities reside.

At this point, the foundation of the automation platform is in place.

Step 4: Enable a Managed Identity

One of the most important best practices for modern automation is utilizing a Managed Identity.

Historically, many PowerShell scripts stored usernames and passwords directly in the script or in encrypted files.

That approach creates security concerns and ongoing maintenance requirements.

Managed Identities allow Azure Automation to authenticate to Azure resources without storing credentials. Microsoft supports both system-assigned and user-assigned managed identities for Automation Accounts.

However, simply enabling the identity is not enough.

The identity must be granted permissions to perform the tasks the runbook requires.

Examples include:

• Virtual Machine Contributor
• Reader
• Storage Blob Data Reader
• Key Vault permissions

The automation account can only perform actions that its assigned identity has been granted permission to perform.

Step 5: Configure required permissions

The permissions required depend entirely on what the runbook will manage.

For Azure-focused automation, Azure RBAC permissions are commonly assigned to the Managed Identity.

Examples include:

• Reader
• Contributor
• Virtual Machine Contributor
• Key Vault Secrets User

For Microsoft 365-focused automation, Microsoft Graph permissions may also be required.

Examples include:

• User.Read.All
• Group.Read.All
• Directory.Read.All
• Sites.Read.All

As with any security implementation, the principle of least privilege should always be followed. Only assign permissions necessary for the automation’s specific purpose.

Step 6: Import required PowerShell modules

One area that often surprises new administrators is module management.

The Automation Account does not automatically contain every PowerShell module available on your local workstation.

If your script uses specific PowerShell commands, the corresponding modules must be imported into the Automation Account.

Common examples include:

• Az.Accounts
• Az.Resources
• Az.Automation
• Az.Compute
• Microsoft Graph modules
• PnP.PowerShell

Microsoft documentation specifically calls out importing required Az modules before using them within runbooks.

Many Microsoft Graph modules and third-party modules must also be imported before they can be used successfully.

A best practice is to verify all required modules exist within the Automation Account before troubleshooting script issues.

Step 7: Create a runbook

Now comes the fun part.

A runbook is simply the script that Azure Automation will execute.

Azure Automation supports several types of runbooks, including PowerShell runbooks.

When creating a runbook, administrators should select the appropriate runtime environment. For new deployments, PowerShell 7.2 is typically the preferred choice unless a specific module requires compatibility with Windows PowerShell.

Examples of runbook functions include:

• Generate Microsoft 365 license reports
• Export SharePoint site information
• Review inactive users
• Start and stop Azure VMs
• Audit mailbox permissions
• Generate compliance reports

Within the Automation Account, select Runbooks and create a new runbook.

You’ll provide:

• Name
• Runbook Type
• Description

After creation, the PowerShell editor becomes available.

Step 8: Write or paste PowerShell code

The runbook editor allows administrators to develop or paste PowerShell scripts directly within Azure.

Many administrators choose to:

• Develop scripts locally
• Test them thoroughly
• Copy them into Azure Automation

This approach often simplifies development and troubleshooting.

As scripts become more important to business processes, version control and documentation become increasingly valuable.

Treat production automation code the same way you would treat production application code.

Step 9: Save the runbook

A common mistake for first-time administrators is assuming a saved runbook is ready for production.

Saving simply stores the draft version.

It does not make the runbook executable.

Think of Save as saving a Word document while you’re still editing it.

Step 10: Publish the runbook

After verifying the code is correct, the runbook must be published.

Publishing is what makes the runbook executable.

Until publication occurs, Azure treats the runbook as a draft.

Many troubleshooting conversations start with: “Why can’t I run it?”

The answer is frequently that the runbook was saved but never published.

Step 11: Test the runbook

Before scheduling anything, test it.

Azure Automation provides testing capabilities that allow administrators to validate runbook behavior and identify problems.

Common areas to verify include:

• Authentication
• Assigned permissions
• Module loading
• Variable handling
• Service connectivity

Testing frequently uncovers issues that would otherwise be discovered after the automation is already in production.

Running multiple successful test executions before deployment is strongly recommended.

A common first-time mistake

One of the most common issues new administrators encounter is getting a script to work perfectly on their local machine but not inside Azure Automation.

In many cases, the problem comes down to one of two things:

• A required PowerShell module was never imported into the Automation Account.
• The Managed Identity does not have sufficient permissions to perform the requested action.

When troubleshooting Azure Automation, those should be among the first items checked.

Step 12: Create a schedule

Once testing is complete, schedules can be assigned to the runbook.

Examples include:

• Daily at 7:00 AM
• Weekly on Sunday evening
• Monthly on the first day of the month
• Every four hours

This is where Azure Automation begins delivering its value.

Tasks that previously required administrators to remember and perform them manually become automated and repeatable.

Common Azure Automation use cases

Organizations commonly leverage Automation Accounts for:

• Monthly Microsoft 365 licensing reports
• Inactive user reporting
• SharePoint permission audits
• Exchange Online reporting
• Azure VM startup and shutdown schedules
• Resource inventory reporting
• Compliance documentation generation
• Certificate and secret management tasks
• Tenant-wide health checks

These scenarios range from simple administrative reporting to complex multi-system automation workflows.

Monitoring and maintenance

Deployment is not the finish line.

Automation requires ongoing maintenance.

Administrators should periodically review:

• Failed jobs
• Module updates
• Permission assignments
• Runbook output
• Azure and Microsoft 365 service changes

As Microsoft evolves Azure and Microsoft 365, runbooks occasionally require updates to remain functional.

Regular reviews help ensure automations continue operating reliably.

Conclusion

Azure Automation Accounts provide a powerful platform for eliminating repetitive administrative work across both Azure and Microsoft 365 environments.

While the initial setup requires multiple components (including an Azure subscription, Resource Group, Automation Account, Managed Identity, required permissions, imported modules, and runbooks) the long-term benefits can be substantial.

The typical lifecycle is straightforward:

• Create an Azure subscription and Resource Group.
• Deploy an Automation Account.
• Enable a Managed Identity.
• Assign Azure and/or Microsoft Graph permissions as needed.
• Import required PowerShell modules.
• Create a runbook.
• Save and publish the runbook.
• Test the runbook.
• Attach a schedule.
• Monitor and maintain the solution.

Once that framework is established, organizations can automate countless administrative tasks that previously required manual effort. For IT departments managing growing Microsoft 365 and Azure environments, Azure Automation often becomes one of the most valuable tools in the cloud administration toolbox—saving time, improving consistency, and allowing administrators to focus on higher-value work.