Azure Automation - Simply Explained

Today's topic is one that almost everyone in IT has heard of, but most people can't explain what it actually is. As your automation, is it just a fancy name for running scripts in the cloud, or is it something much bigger? Imagine you're an IT admin. Every single day you repeat the same tasks. Start a VM, stop another one, patch servers, clean up old files, maybe you run a script manually, maybe you set up a schedule task on one machine, it works, but it's fragile, it doesn't scale, and when you have 50 servers instead of five, it breaks completely. Most people just keep doing this manually, they log in, click around, run their scripts, it feels productive because you're getting things done, but here's the problem. You're wasting hours on work that a machine could do for you, and worse, every manual step introduces the chance of human error. You forget to patch one server, you stop the wrong VM, it happens. As your automation is like hiring a 24/7 assistant who never sleeps, you tell it what to do once and it handles the rest. On schedule, every time, no mistakes, no forgetting. In this episode, I'll show you what as your automation really is and break down the key building blocks, runbooks, schedules, hybrid workers, state configuration. By the end, you'll understand how all these pieces fit together to make your job easier. Let's start with why you even need this. Why automation? The problem of repetitive manual work. 20 years ago, if you wanted to automate something, you logged into each server individually, you wrote a script, ran it on that one machine, and set up a schedule task locally. If you had five servers, you repeated the process five times. If you had 20, you did it 20 times, it was slow, it was boring, and it was incredibly easy to mess up. Here's the real cost. First, the wasted hours. Every time you manually run a task that could be automated, your burning time you could spend on something more valuable. Second, human errors. You forget a step. You run the wrong script on the wrong server. You miss a server entirely. Third, inconsistency. One server gets patched on Tuesday, another on Thursday. One has the right config, another doesn't. Over time, your environment drifts apart and that's when weird problems start showing up. The breaking point comes when you have tens or hundreds of VMs. At that scale, manual work just doesn't work anymore. You can't log into 100 servers one by one. You can't trust that every schedule task on every machine is running correctly. Something will break and you won't notice until it's too late. As your automation solves this by centralizing everything in one place, instead of having scripts scattered across individual machines, you store them in a single automation account. Instead of setting up schedule tasks on each server, you define one schedule in Azure. Instead of hoping everything runs correctly, you get logs, alerts, and reports. It runs your scripts on a schedule. It responds to alerts when something goes wrong. It can even fix problems before you notice them and it does all of this without you having to log into anything. So what's inside this automation tool? Let's look at the main building block, runbooks. Runbooks, the heart of automation. A runbook is just a script. Usually PowerShell, sometimes Python, that's it. There's no magic here. You write the steps you want to follow and Azure Automation follows them exactly every time. Think of it as a recipe. You write the instructions once. Start the VM. Wait for it to be ready. Run this command. Send an email when it's done. Then you hand that recipe to Azure Automation and it cooks the same meal every single time. No shortcuts. No forgetting ingredients. There are different types of runbooks. The most common are PowerShell and Python. These are text-based scripts that look exactly like what you'd write in your local editor. Then there's graphical runbooks. These let you build workflows by dragging and dropping activities on a canvas. They're designed for people who prefer visual tools over writing code. Personally, I'd stick with PowerShell or Python. They're easier to version control, easier to test and more flexible in the long run. Runbooks live inside your Automation account. That's the container that holds everything. Your runbooks, your schedules, your credentials, your variables, it's all stored centrally in Azure. Not scattered across individual servers. And here's the powerful part. Runbooks can do almost anything. Start and stop VMs. Copy files between storage accounts. Query databases. Call external APIs. Send notifications. If you can do it with PowerShell or Python, you can put it in a runbook. Here's a simple example. You have a set of development VMs that only need to run during business hours. At 7pm every day, you want them all shut down to save money. You write a runbook that loops through your dev VMs and stops each one. You test it once. It works. And from that point on, your 7pm shutdown happens automatically. But a runbook sitting idle is useless. You need to tell it when to run. Scheduling and triggers when the magic happens. The simplest way to start a runbook is to hit the run button in the portal. That's great for testing. You write your script, click start, and watch it execute. But that's not automation. That's just running a script manually from a web page. Real automation needs a trigger, something that tells your runbook when to run without you touching anything. The most common trigger is a schedule. You set a time, and as your automation runs the runbook at that time. Daily, weekly, one time. It works like an alarm clock for your runbook. You pick the time zone, the frequency, and you're done. From that point on, your runbook runs automatically. But schedules aren't the only way. You can also trigger runbooks from alerts. Imagine you have a VM that spikes to 95% CPU and alert fires, and that alert can automatically start a runbook that investigates the issue, maybe even fixes it, same with low disk space. Instead of waiting for someone to notice, the alert triggers a cleanup runbook before the disk fills up. Then there are web hooks. A web hook is basically a URL that when called starts your runbook. This is how you connect as your automation to other services. Logic apps can call it, third party tools can call it, and you can even trigger a runbook from a custom application. You just make an HTTP request to the web book URL and your runbook fires. One thing that's easy to miss, schedules are shared resources. You create one schedule, and you can link it to multiple runbooks. So you can have a 7 p.m. shutdown schedule that triggers your stop VM runbook and your cleanup runbook and your logging runbook. One schedule, multiple actions. Here's a real example. You have 10 development VMs. They cost money every hour they run. So you create a schedule that runs a stop VM runbook at 7 p.m. every weekday. Then you create another schedule that runs a start VM runbook at 6 a.m. That's it, your VMs run during business hours and shutdown at night, no manual intervention, no forgotten servers, just automatic savings. Now what of the machines you need to manage aren't in Azure? Hybrid workers automating outside the cloud. By default, your runbooks execute inside Azure Sandbox. That's Microsoft's compute environment. It's fast, it's managed, and it works great for anything that lives in Azure. But what about your on-premises servers, the ones sitting in your own data center? The file server in the corner, the domain controller, the school server that can't be moved to the cloud, the sandbox can't reach those machines. It's inside Azure's network, not yours. That's where hybrid runbook workers come in. A hybrid runbook worker is exactly what it sounds like. You install the runbook worker software on any machine, Windows or Linux. That machine then becomes the robot that runs your runbooks locally. Instead of executing an Azure Sandbox, the runbook runs directly on that machine. Using its network, its permissions, its access to local resources. This is perfect for a few scenarios. On-premises, servers that can't leave your data center, machines behind private networks that don't have direct internet access, servers that need to reach local file shares, active directory or legacy applications. The modern way to set this up is through Azure Arc. You connect your on-premises machine to Azure using Arc and then you add it as a hybrid runbook worker. Arc handles the identity, the connectivity, the management. From Azure's perspective, that on-prem server looks just like an Azure resource. You can apply policies, assign roles and of course run runbooks on it. There are some real benefits to using hybrid workers. First, the three hour runtime limit that exists in the sandbox, that doesn't apply here. Your runbook can run for as long as it needs, hours, days, doesn't matter. Second, you have full access to local resources. You can read local files, run local commands, connect to local databases. Third, you control the execution environment completely. You install whatever modules you need, you configure the machine however you want. But there's a trade-off. You manage that worker machine. You're responsible for updates, security patches, keeping it running. It's not a managed service anymore. It's your machine doing the work. Still, for organizations with hybrid environments, hybrid workers are essential. They extend your automation reach from the cloud into your own data center, but automation isn't just about running scripts. It's also about keeping servers consistent. State configuration, keeping servers in line. Ever had a server drift from its intended setup? Someone changes a setting, installs something they shouldn't, or disables a service they needed to leave running, suddenly things break. And you spend hours trying to figure out what changed. That's the problem as your automation state configuration solves. It's built on something called PowerShell.dsc, desired state configuration. The name tells you exactly what it does. You define the state you want and a zero automation, make sure every machine stays in that state. Here's how it works. You define the golden state for your servers, which Windows features should be enabled, which registry keys need to be set, what services should be running, which security settings are required. You write all of this in a configuration file, and you upload it to your automation account. Then the DSC agent on each machine checks in. It looks at the configuration you defined, compares it to what's actually running on that server, and reports back. Is it compliant? Yes or no? You can see this in a dashboard, a list of all your machines green for compliant, red for not. But here's where it gets really useful. If a machine drifts from its desired state, it can auto correct itself. The agent doesn't just report the problem. It fixes it. A server gets stopped. It starts it again. A registry key gets changed. It sets it back. The machine pulls itself back into compliance without anyone touching it. This is also incredibly useful for initial server setup. Instead of configuring each new server by hand, you just assign it a configuration. The DSC agent pulls the configuration, applies it. And within minutes, the server is an exactly the state you want. Deployed to 100 servers at once. Same result every time, one thing to note. This feature is evolving. Microsoft is moving towards something called Azure machine configuration. It's the next generation of the same idea, more reporting, more flexibility, tighter integration with Azure policy, but the core concept stays the same. Define your desired state. Let automation keep it there. All these runbooks and configurations need certain things, though, credentials, variables, connections. Let's look at shared resources. Shared resources, the utility closet. Your runbooks often need secrets, passwords to connect to databases, API keys to call external services, connection strings to reach other systems. The worst thing you can do is hard code those secrets directly into your runbook. Why? Because now that secret lives in your script, it's in your source control. Anyone who can see the runbook can see the password. And when you need to rotate it, you have to edit the runbook, republish it, test it again, it's a mess. Azure automation solves this with shared resources. Think of it as a utility closet for your runbooks. All the things your scripts need, stored centrally and securely. First, variables. These store simple values, a VM name, a subscription ID, a region name. Instead of writing "Eastus" directly into your script, you create a variable called Azure Region and set it to "Eastus". When you need to change regions later, you update the variable once. Every runbook that uses it picks up the change automatically. Second, credentials. These store usernames and passwords securely. You create a credential asset, give it a name, and store the username and password inside. Your runbook references that credential by name. It never sees the actual password. Azure automation handles the decryption when the runbook runs. Third, certificates. For authentication to other services. Same idea. Upload the certificate once, reference it in your runbook. Fourth, connections. These are predefined links to Azure or other services. You set up the connection once with all the required parameters and your runbook just calls it. All of these resources are encrypted. Only your runbooks can access them. No hard-coded secrets, no password sitting in plain text files. Here's a simple example. You create a variable called OfficeHoursEnd and set it to 19Honetacorque. Your shutdown runbook reads that variable instead of having 19Honetacorque coded. When business hours change to 18Honetac, you update the variable. The runbook doesn't change one update, and every schedule that uses that variable adjusts automatically. But who runs the runbook? That's where identities come in. Managed identities. Secure authentication without passwords. Every runbook needs permission to do things, stopping a VM, reading a secret from Key Vault, querying a database. The runbook itself doesn't have inherent access to anything. You have to give it permission. The old way of doing this was painful. You'd create a service principle in Azure Active Directory. That's basically a digital identity for your application. Then you generate a password for that service principle, store it somewhere secure, and configure your runbook to use it. And then every year or so, you'd have to rotate that password. Generate a new one, update your runbook, test it, hope nothing broke. It worked, but it was a constant maintenance burden. Managed identities solve this completely. A managed identity is exactly what it sounds like. Azure handles the identity for you. It creates it, manages it, and rotates the credentials automatically. You never see a password. You never have to update one. It's like a digital badge that your automation account wears. When the runbook runs, it presents that badge and Azure recognizes it. There are two types. System assigned managed identity is tied directly to your automation account. It lives and dies with that account. If you delete the account, the identity goes away. Simple, clean, one identity per account, user assigned managed identity is separate. You create it as its own resource in Azure, and then you can assign it to multiple automation accounts or even to other Azure services. This is useful when you want the same identity and permissions to be shared across different systems. More flexible, but slightly more set up. Here's how it works in practice. You go to your automation account, enable the managed identity. Then you go to the resource, you want your runbook to manage maybe a resource group full of VMs and you assign a role to that identity, contributor reader, whatever it needs. You do this once, that's it. Then inside your runbook, instead of storing a password or using a credential asset, you just call one line. Connect as account identity. That's the whole authentication. No passwords, no secrets, no rotation. The runbook runs as your recognizes the managed identity, checks the permissions you assigned, and lets it do its work. This is the best practice. Always use managed identities when you can. They're most secure because there's no password to leak, they're easier to maintain because there's nothing to rotate. And they're simpler to set up because you don't need to create and configure service principles. With all these pieces, let's see a real world example. Putting it all together, a simple start stop scenario. Let's make this concrete. You have 10 development VMs. They only need to run during business hours. From 6 a.m. to 7 p.m. Monday through Friday, the rest of the time, they're sitting there, burning money, not doing any work, but still costing you compute hours. Here's how you automate this with Azure Automation in five steps. Step one, create an automation account. This is your central hub. It takes about 30 seconds in the portal and the first 500 minutes of runbook execution each month are free. So for a simple start stop scenario, you might never pay a cent. Step two, import a runbook. You can write one from scratch if you want. A PowerShell script that gets all VMs in a resource group and starts or stops them. But you don't even have to write it yourself. Azure Automation has a gallery full of pre-built runbooks. There's one called start as your V2 VMs and another called stop as your V2 VMs. You import them and they're ready to go. Step three, create two schedules. One for started 6 a.m., one for stop at 7 p.m. Daily, Monday through Friday. Each schedule is just a time in a recurrence. Simple, step four. Give your automation accounts managed identity permission on those VMs. You go to the resource group, add a role assignment, select contributor, and pick your automation accounts managed identity. That's the permission your runbook needs to start and stop VMs. Step five, link the runbook to each schedule. You open the runbook, go to schedules, link the start schedule, then link the stop schedule. Done, that's it. From this point forward, every weekday at 6 a.m. your runbook starts all 10 VMs. At 7 p.m. it shuts them all down automatically. No one logs in. No one remembers to do it, it just happens. And the savings add up. 10 VMs running 24 hours a day, 7 days a week costs a lot. 10 VMs running only during business hours, 5 days a week, costs less than half. The few cents you pay for runbook execution minutes are nothing compared to the compute savings. That's the big picture. Let me wrap it up for you. So there you have it. Azure Automation in plain English. It's your 24/7 cloud assistant that runs, scripts, keeps servers consistent, and reaches anywhere. Even on-premises, the key building blocks, runbooks for the logic, schedules for timing, hybrid workers for reach, state configuration for consistency, and managed identities for secure access without passwords. If you're starting, pick one repetitive task. Just one. Maybe shutting down a VM at night, automate that. That's your first knowledge nugget. If this helped, subscribe for more plain English explanations, and share this with a colleague who's just starting their cloud journey. They'll thank you later.