Hello, Cloud Gurus, and welcome back.
In this lesson, we're going to take a look
at how you can leverage hybrid process automation
to make your life a little easier
and save your company both time and money.
Let's take a look at what we're going to cover.
First up, we'll go through the process
of creating Azure Automation Runbooks,
then we'll take a look at how you can execute your runbooks.
And we'll also take a look at how you can deploy
your own hybrid workers and all the awesome that brings.
And finally, we'll wrap up with a decent demo
on hybrid process automation, let's get started.
As we briefly covered in the previous lesson,
you automate processes in Azure Automation using runbooks.
And runbooks can be either graphical or text based.
Graphical runbooks hide away the underlying script
and are created and edited within the Azure portal.
And text-based runbooks
can even be integrated with source control like Git
to be stored and versioned
outside of the automation account.
Now, you can create Python runbooks which are text based,
based on Pythons groups, targeting the Python Interpreter.
You can also create PowerShell runbooks
which are based on traditional windows PowerShell
or the new cross-platform PowerShell.
And PowerShell runbooks are either text based or graphical.
And you also have the option
to create Windows PowerShell Workflow runbooks.
And these are either text based or graphical runbooks
based on Windows PowerShell Workflow.
And these aren't supported
on the newer cross-platform PowerShell,
only Windows PowerShell.
Now, to make your runbooks more reusable,
you can include parameters in your runbook.
A parameter is defined when you create the runbook
and then the value for that parameter is set
when you execute the runbook.
And we'll take a look at how you can do this
in the demo later in this lesson.
And you can also use shared Automation account components
like credentials and variables in your runbooks.
And this will make it easier
to manage your scripts moving forward.
Say you need to include a server name
in a script that you're using as a runbook.
You can make that server name a variable,
so that when you need to replace that server down the track
you just need to update the variable
and not all of the scripts that use that server name.
Once you've created your runbook
you can test it in the Azure portal.
What's important to know about testing a runbook
is that it's a real test.
If you don't use things like the PowerShell WhatIf parameter
the test will do everything you asked it to do.
And this could be dangerous in a production environment.
When you are happy with your runbook
you publish it to make it available to execute.
Changes made while editing a runbook
don't affect how the runbook runs
until you publish the runbook.
So you get a draft version that you can work on,
and a published version that you can use
to execute in production.
All right, with your runbook published
let's take a look at how you can execute a runbook.
You can start the execution of your published runbooks
either manually by clicking the start button in the portal
or using scripting with the Azure PowerShell module
or the Azure CLI.
You can also create shared schedules
and link your runbooks to a schedule
to have them execute periodically,
according to that schedule.
And you can also use integrations to trigger your runbooks.
Webhook is one example of this integration,
but other Azure services can also execute runbooks.
Logic Apps is one example of an Azure Service
that can execute runbooks.
And when you execute your runbook, schedule it,
or integrate it, you decide which parameters to use
and where your runbook should be executed.
You can execute your runbooks either in Azure,
in what's known as Sandbox Automation.
These runbooks execute on workers
that are managed by Microsoft.
Sandbox Automation is great
if you want to automate Azure resources
and publicly accessible resources.
But if you want to access your private
or on-premises resources,
you can also execute runbook on hybrid workers,
which we'll take a closer look at up next.
When you execute your runbook it creates a job
which records all of the information about that execution,
including things like logs, where it was executed,
and what parameters were used.
To delegate access to all of the runbooks
in an Automation account,
you can use the Automation Account Operator role.
And to delegate access to view and run specific runbooks,
you can use the Automation Runbook Operator Azure RBAC role.
And you'll also need to grant those users
the Automation Job Operator RBAC role
on the Automation account
if you want them to be able to manage the jobs
for the runbook they've executed.
Now, let's take a look at hybrid workers.
Hybrid workers are servers that you deploy
and are used to run Azure automation runbook.
You can configure a hybrid worker using a VM extension.
And this is done either directly on an Azure VM
or via Azure Arc.
And this is the recommended method
for deploying a hybrid worker.
Or you can use the older agent-based method,
which uses the Log Analytics agent
and requires a Log Analytics workspace.
When you deploy a hybrid runbook worker,
it's configured as a user hybrid worker.
It's worth knowing
that there are also system-based hybrid workers
that are used by Microsoft
when you configure update management.
As of right now, system-based runbook workers
are agent-based and use the Log Analytics agent.
When you deploy a hybrid worker,
you add it to a hybrid worker group.
And the worker group is a group of similarly,
ideally, identically, configured servers
that will check with the Automation account
and collect jobs.
The job distribution is not guaranteed to be even,
but it does provide some sort of resiliency
in the case that a hybrid worker fails.
A hybrid worker group can also be configured
to run as an account
that can be used to provide access to resources.
Now, I personally recommend against using a runner's account
because it can become a single point of failure
for your hybrid workers.
All right, let's put a list together
and take a look at hybrid process automation.
In this demo, we will disable inactive, Active Directory
users using an Azure Automation runbook.
We already have an Automation account deployed
with the name aa-australiaeast.
Now, I've gone ahead and deployed a new VM
on-premises that will act as our hybrid worker.
I've also onboarded this VM into Azure Arc.
In this demo, we will create a hybrid worker group
and then we will deploy the hybrid worker VM extension
on our new hybrid worker.
And then we will create some shared resources
in the form of credentials
that our hybrid worker can use in a script.
And we have an existing account
that our hybrid worker can use for this.
And then we will create and test a runbook.
And finally, we will execute the runbook
and take a look at the results.
Sounds pretty cool, right?
Let's take a look.
All right, so here I am in the Azure portal.
And I just want to show you
that I've added the hybrid worker
as an Azure Arc enabled server.
So I've navigated to Azure Arc.
Now, let's navigate to servers and you can see here,
I have our new hybrid worker
added as an Azure Arc connected machine.
Now, let's navigate to our Automation account
and we'll go ahead and onboard this hybrid worker.
So we'll navigate to Automation Accounts,
and then we'll navigate to our Automation Account.
I'll go ahead and collapse this left menu.
And then we'll navigate to hybrid worker groups
under Process Automation.
Now, let's go ahead and create a hybrid worker group
and we'll just name this hybrid worker group CORP-Default.
Now, you can call your hybrid worker group whatever you want
the reason I've chosen to use CORP and then default,
is because CORP is the name of the Active Directory domain
that this hybrid worker is joined to.
Now, you can actually add your hybrid workers
when you create the hybrid worker group.
But we're going to add them after just so I can show you
how to do that.
So I want to go ahead and click Review and Create,
and then we'll go ahead and hit Create.
All right, our hybrid worker group has been created.
Let's refresh so we can see it in the list.
And now let's navigate into our Hybrid worker group
and then we'll navigate into our Hybrid Workers.
And then we'll go ahead and click Add,
and then we'll go ahead and select our Azure Arc
connected machine.
And then we'll go ahead and select Add.
Then this will just take a moment
to deploy that hybrid worker extension
to our Azure Arc connected machine,
so we'll come back when that's done.
All right, we've successfully onboarded our hybrid worker.
Now, we're going to create a runbook
that will check Active Directory
for inactive users and disable those accounts.
And this is a pretty common administrative task
that Active Directory Administrators
are going to need to do.
To do that, our runbook is going to need some credentials
to access Active Directory.
Now, ideally we'd use a group Managed Service Account
for this purpose, but I want a demo using shared credentials
in the Automation account.
So I've pre-created a user account
in Active Directory for the purpose
of searching for and disabling these user accounts.
But the hybrid worker is going to need access
to those credentials.
So we don't need to store them in plain text in our runbook.
Let's add them as a shared resource
in our Automation account.
To do that, we'll navigate to our Automation account.
And then under shared resources,
we'll navigate to Credentials.
We'll go ahead and add a credential
and I'll provide a name for this credential.
I'm going to use the name CORP-UserManagement.
Then I'll go ahead and provide the username
and I'll go ahead and provide the password.
I'll Go ahead and hit Create.
Then let's create a runbook.
We'll navigate up to runbook under process automation
and we'll select Create a Runbook
and we need to provide a name for our runbook.
So I'm going to use the name Disabled-inactiveADUser.
I'm going to go ahead and select the runbook type;
we're going to use PowerShell.
Go ahead and select the runtime version for PowerShell,
I'm going to use PowerShell 5.1,
which is Windows PowerShell.
And then we can go ahead and click Create.
Now, I've pre-created the script
we're going to use for this, so you don't have to sit here
and watch me draft out a script.
So I'm going to go ahead and paste the script in.
Now, we want to test this script in Azure Automation
before we go ahead and run it.
To test it in Azure Automation,
I'm going to add a WhatIf parameter
to this Disabled-ADAccount PowerShell cmdlet,
so that it doesn't actually disable the AD accounts
when I test the script.
So we'll go ahead and add the WhatIf parameter here.
And I'll go ahead and click Save.
And then we'll go ahead and click Test Pane
to test our runbook.
Now, our script provided default values
for a number of the perimeter that were in our script.
So you can see by default
it's using our domain name of corp.barrierreefaudio.com.
And it's using an inactive days of 90,
and it's using a default search base
where our domain users are located in Active Directory.
But the credential has not been provided.
So we need to provide a credential for this runbook
to access Active Directory.
I'm going to go ahead and use the credential
that we just created, which is CORP-UserManagement.
Now, you'll notice that I'm not providing the username
for this credential,
but rather I am providing the name of the saved credential
in the Automation account.
And then Azure Automation will do its magic in the backend
and swap out that credential
for the actual credential in the automation account.
Now, we want to run this on our hybrid worker
so we can access our on-premises Active Directory.
And then we'll go ahead and use our default
hybrid worker group.
Now, that's ready,
let's go ahead and run our script and test it out.
This will just take a moment to run,
so we'll come back when this is done.
All right, now that runbook has finished executing
and you can see that it would've disabled
two of our inactive users in our Active Directory domain.
But because we added that WhatIf parameter,
it hasn't actually disabled those users.
Now, let's go back and remove that WhatIf parameter
and then we can save and publish our runbook.
So we'll navigate back to our runbook
and then we'll remove that WhatIf parameter.
Then we can go ahead and save,
and then we can go ahead and publish.
And it's just letting us know,
that it'll override the currently published version
so that's fine, we'll go ahead and click Yes.
Now, we can, as you can see here,
link our runbook to a schedule
and then it will automatically execute on that schedule.
And that will probably be a good thing
to do for this runbook.
But instead, just so we can take a look at the jobs,
we're going to go ahead and click Start to run this runbook.
And we'll use all the default values for the parameters
and we'll just go ahead and provide that credential again.
And we're going to execute it on our hybrid worker.
And we'll go ahead and click OK.
Now, it's gone ahead and created that job.
We'll just give this a moment to execute
and then we'll come back when that's done.
All right, and that runbook has finished executing
and we can see here, the status is completed.
Let's now navigate back to the runbook
and we can take a look at the logs.
So we'll navigate back to our runbook up here,
and then we'll navigate down to jobs,
and then we'll navigate into the job that's been completed,
and then we'll navigate into the logs.
Now, it has taken us back to the same screen
where we're already on,
but I just wanted to show you how to navigate into the logs
after the job was already executed.
Because you might end up triggering the runbook
using some other method
other than running it manually in the portal.
And we can see here we have the output from our runbook
and has gone ahead and disabled
two of our active directory users.
All right, that's it for this demo.
Let's go and take a look at what we've covered
in this lesson.
All right, so what have we covered in this lesson?
PowerShell runbooks can be text based or graphical
and use either Windows PowerShell or PowerShell,
or you can use text based Python runbooks.
You can test your runbook in the Azure portal,
but you'll need to publish your runbook
before you can add it to something like a schedule.
And you can execute your runbooks in Azure
using the sandbox or on hybrid workers.
And the sandbox is useful for automating Azure resources,
and hybrid workers are useful
for accessing on-premises resources
and resources in other clouds.
And when a runbook is executed
it creates a job that stores details about that job
like the logs and the parameters that were used.
And hybrid workers that are similar
are grouped into hybrid worker groups.
And hybrid worker groups you create
are referred to as user groups,
and share the workload of jobs
that are assigned to that hybrid worker group.
All right, thanks for being with me in this lesson.
I hope you found it useful,
and I look forward to seeing you in the next lesson.