OK, I think it's just about 2 o'clock, so we can probably get started. First of all, I want to thank everyone for coming to the session. My name is Eamon O'Reilly. I'm a lead program manager on the Azure Automation service

that we have. And today, we're going to talk about how you can bring a lot of your knowledge you've built up in PowerShell or in Python and be able to bring that knowledge, all the investments you've done, but be able to deliver that from the cloud and orchestrate across both your cloud resources as well as your on-premises resources

or even other cloud providers from a single location. And so that's really the talk we're going to go through today. I have a lot of demos, so if you have some questions, just raise your hand. We'll try to answer them. If they go too long, then we'll move on just so we can get through all the content. So some of you may have seen this slide.

When you think about all of the management capabilities we have delivered from Azure, we really try to have some built-in management that allows you to, obviously, manage all of your Azure resources. But all that learning and all that knowledge we build up in managing Azure, we try to make available so you can manage all of your on-premises resources at the same time. And so that's the real focus as we go forward.

And so the area we are going to talk about today mostly is this automation area inside of Configure. So we have a whole set of built-in SaaS-based services in Azure that can manage everything, but the one we're going to talk about is our automation service and specifically talk about what we're doing for PowerShell as well as what we're doing for Python and potentially other scripts as we go forward.

So first of all, I'll ask, how many of you are familiar with Azure automation? That's a good crowd, perfect. Thank you. So hopefully that's working well for you. So if you're familiar with it, we're going to go deeper dive into some of the advanced capabilities, but also give an overview for people

who aren't familiar just so you can get started and start to see the benefits it provides. But we started working on this service it was probably over four years ago now. And a lot of it came out of the knowledge we learned when we were building PowerShell natively into Windows. And then some of you might be familiar with, as part of the system center, we delivered a product called

Orchestrator that had a component called Service Management Automation. And that Service Management Automation is basically from the same team I had worked on past then. But what we really wanted to do was take all that learning that we had from the PowerShell investments, Service Management Automation investments, and start to bring those into the cloud so we could really build one automation platform for all

of the tasks that you want to do across your on-premises environment, but as you start to move in the cloud, have that exact same platform available as you move and start to manage those Azure resources. And so a lot of learnings we went along the way was, there's challenging things today when you're trying to automate on-premises. A lot of the things was, where do I store all my automation?

If I have credentials or I have variables I need to use, where do those get stored securely? How do I get access to them? How can I share my automation between different teams? All these kind of complex, basically, scenarios that customers had to do in order to leverage all of the PowerShell and even Python capabilities, we wanted to give you a place in Azure that could solve all of those challenges

and really have you focus on what was the value you were trying to offer when you wrote your PowerShell or you wrote your Python. And so the first thing we focused on was, let's make sure we really build a highly scalable platform that you can move all of your automation into and then be able to use a language you prefer. So if you prefer PowerShell, use PowerShell. If you like graphical authoring, use graphical authoring. If you like Python, use Python.

But the exact same way you authored it and used it when you were working on your on-premises environments, you can just bring up that knowledge and bring it into the cloud without having to redo everything. And so that was a major focus as we went forward. The other thing we really wanted to make sure was, because we've learned that most customers are in a hybrid environment, that it's rarely all of your automation

needs to take place just against Azure resources or just against your on-premises resources. We're seeing a lot of customers get into a mixed mode where they have a lot of investments on-premises, but they still have a lot of investments that are moving to Azure. And so we really made sure that the hybrid support we built was native into the service and so that you could actually bring all your automation in and literally automate

all of your on-premises environments without doing anything into Azure. But as you started to move things in, it natively supported those as well as you went forward. The other big learning we had around service management automation and just PowerShell in general was what most of our customers were doing was they were writing an automation so that they could react to some task

and deliver some service automatically. I mean, that's the whole idea of automation is transfer the knowledge you have on how something's supposed to be done into the system so that it can automatically react without you having to press buttons and manually go through all of the UI. And so our major focus was how do we make it very easy to connect up into systems? How do we make it easy for you

to trigger this automation, integrate into external systems that might trigger us? So we spent a lot of time on giving all these interfaces that allow you to pull external systems, have those external systems trigger us. So that really becomes almost like the automation service that allows you to integrate seamlessly and deliver on-demand services. I mean, our whole overall goal is,

you know, automation is designed to be headless. And so we wanna make sure that when you bring your automation in, it can be triggered from any location and it will actually go and deliver the value that you put into the scripts. And so that was our major focus as we went and built this service. So if you're not familiar with it, how Azure Automation Service is,

it's basically is a serverless automation engine that runs in the cloud. And so what that really means is, you don't have to focus on how the infrastructure is gonna work. Do I need to spin up enough VMs? Is it gonna scale? Is it gonna be reliable? What happens if my machine is down? All the challenges you have to try to overcome with an on-premises infrastructure.

We try to take all of that pain away from you and just say, all you need to do is focus on what automation you're trying to deliver. And then from the backend, we will actually run that behind the scenes and manage all of those backend infrastructure to have it scale. So if you wanna run just 1,000 jobs or 100,000 jobs or a million jobs, we will take care of all of the backend so that you can actually just deliver the value

and you don't have to worry about the infrastructure. That's kind of a key differentiator between all of the work you might be doing today and trying to host your infrastructure compared to bring it into the cloud. The other big thing is, when we built this, I talked a little bit about the hybrid work we did. So we wanted to make sure that you could manage your Azure resources but also manage your on-premises resources.

But we also wanted to make sure, as we built it out, that we had the exact same capabilities against Windows and against Linux. That's another kind of trend we've seen is that customers aren't just in a Windows world anymore. They're also starting to get into a hybrid world where they have Linux in their environments plus Windows in their environments. And how do we give a single automation platform that can integrate and automate

all those different tasks together? And so a lot of the work we did was to make Linux kind of first class into the service as well, as well as the languages like Python that people might be familiar with it. Obviously it's great that PowerShell Core now works on Linux as well. So you can also take advantage of PowerShell Core as you go forward if you need to run it on a Linux environment. And so those were some of the core capabilities.

But the other ones we did was like all kind of management on top of that. So I'll talk a bit about the shared resources we have like credentials and variables, all those challenges you have today, how they're available in the service, but also things like role-based access control. Who has access to what automation? Who can actually perform tasks? Is there different roles for different types of people who use the service? All of those are natively available as well.

So you don't have to kind of figure out how do I share out all my automation to all my external teams or have other people contribute. So a lot of native capabilities, we try to abstract away the complexity and really just make it very easy for you to deliver that value. Okay, so with that, I'm gonna jump into a demo. And for those who haven't seen the automation service, I'm just gonna show you how easy it is to get set up.

And then I'm gonna go deeper and deeper as we go along. And if you do have questions, let me know. Okay, so let me jump into a quick demo here. Okay, so if you're not, let me see, oh, sorry.

There it is. Okay, so if you're not familiar with the Azure portal, so when you get inside the Azure portal,

the real goal is try to make it easy for you to get value out of the services without having to worry about the infrastructure behind them. So if you go into all services up here, what this allows you to do is basically look at all the available Azure services, but I'm just gonna focus on our automation one. So I'm just gonna talk into automation. And you can see I've started here, but I can just click on automation.

And what this is gonna do is allow me to bring in and use all the different automation accounts available to me. So I can just go click add if I wanted to. And within one click, I'll have one of these automation accounts set up, and I can start using it. So I could just do DevOps,

and I'll create a new place to store it in the container, and I can pick a location. So we're available all over the world, so you could basically decide where you wanna put this. And so the other thing that we do is we create a run as account during creation. I'll just create it here. And what this run as account does,

it allows you to manage all of your Azure services natively. Because one of the things with automation is you're not going to be there clicking on the automation. And so as this automation gets triggered by some external system, through a webhook, through a schedule, through an ITSM server calling it, through a monitoring server calling it from an alert, it will actually go and be able to manage all of your Azure resources

using this Azure AD service principle that we create. Yep, question. Yes, yep, perfect. Okay, so once you have an automation account, I'm just gonna go into one

just so you can see how it all works. So you can see this other automation account already got created, and it's available to you. So once you have an automation account, the area I'm gonna focus on today is all of our automation capabilities under process automation. As you're probably familiar with our automation service, we support DSC natively in it. Michael had a session earlier

that talked about all the features we have related to DSC. But we have a bunch of other capabilities around how we do inventory, change tracking, as well as update management. And so if you're interested in going deeper on those, there's a session at four on our inventory and change tracking, and there's a session tomorrow morning at nine on update management. But I'm gonna focus mostly around PowerShell

and how you could use that inside the service. Okay, so let me just kind of, if you're not familiar with it, this is where we store all of our scripts. So we have a Rumble container, and this allows us to create different types of automation. So you could create PowerShell, PowerShell workflow, Python, graphical, those are just types of automation that you wanna store in the service.

As you run jobs, you'll get all the history of the jobs, all the auditing. We have integration with the gallery. So we basically pull all of our, you can browse basically and pull in scripts from powershellgallery.com, or you can pull them from Script Center. And this is really allowing you to kind of leverage all the community content that's been built out there for PowerShell. But also we're hoping to bring in Python

and others as we go forward. I mentioned the hybrid workers, and so I'll talk a little bit about those. A hybrid workers, these really give you the ability to spin up a node, basically a Windows agent inside your on-premises environment, or even in Azure. And what it does is it will actually reach out into our service and look for automation to run.

And so the nice thing is there's no inbound ports. It reaches out through 443 against a known endpoint. And so that allows you basically to say, I wanna deliver all my automation from the cloud. Oh, sorry, I'm just gonna get out of here. And then we will actually deliver that automation

automatically against those hybrid workers. And I'll jump with that in a second. And then there's a few other areas I just wanna talk on. So watch your tasks. This is another capability. If you're familiar with services we've built inside of service management automation or orchestrator, we have the ability to kind of poll a system looking for work to do. And so instead of doing an event-based

where you get a trigger through a webhook or you get some other external API call to you, we have the ability to use watch your task that you can basically go and poll a system. So you might be polling an exchange looking for an email. And if you see an email come in, go and process it and do some automation task. Or maybe you're gonna poll a SharePoint site, or you're gonna poll a file server looking for things.

And so we basically have this service available so that you can author how you want to listen for those events. And when those events happen, you can go and process those and deliver automation on them. And then shared resources I talked a little bit about was schedules, modules, our gallery, credentials, connections. All of these things make it easier for you to do automation inside of the platform

and not really have to kind of worry about how do I do these things if I was to deliver them natively in your on-premises environment. So let me just jump in and show you a little bit here of how these work. So I'm gonna jump into runbooks. And I'm gonna show you a common task that we see a lot of our customers doing that if you start to deliver a lot of resources

in Azure like SQL and virtual machines, what we notice is a lot of these aren't for development environments. And so they don't really need to be on 24-7. And so what our customers do is that when those virtual machines aren't running at night, they'd like to shut them off so they can save all those costs and then turn them back on in the morning. And in some ways it's a very simple scenario, but it actually, when you implement it,

it can reduce your costs sometimes almost in half just by managing the expensive resources that get created in the cloud if they're not being used. And so I'll show you how this can actually work. I'll show you the stop one. There's a corresponding. So I'm gonna open up a Python runbook

and show you how inside the service we allow you to author Python. So here's some, if you're not familiar with Python, most of you guys are probably, I don't know, is anyone familiar with Python here? Oh, awesome. It's almost half, which is great. So this is basically very standard Python here,

but when I authored this and run it, it's gonna run from our automation service in the cloud and it's going to go and manage automatically all the Azure resources that you may have created in your environment. And so what this one does is basically asks you which subscription or resource group that you want to manage and stop those virtual machines that are running.

And so this one uses our built-in service principle in Azure AD to do authentication and manage those resources so it can run headless anytime you want to. And so it's very simple Python. I won't go through all of it, but you can see it's spinning up threads and then it's basically processing all these things in parallel so you could shut down 100, 1,000, 5,000 machines automatically just by targeting which subscriptions,

which resource groups you want to focus on. And so I have some limits in here around I only process 20 at a time and things like that. So all of this is just native Python that you can write and there's a bunch of samples out there and bring into the service and run it. So that's kind of how the normal Python works inside of our service.

But let me close out and show you something that looks maybe more familiar for some people, which is some PowerShell. So I'm going to go to session. And what another common scenario we see customers doing is basically deployment of resources, either on-premises, so you want to deploy against, you know, Active Directory or VMware or whatever else

you're deploying resources against. People write a lot of automation to try to seamlessly deploy those resources on demand. And so you can actually do that from inside of our service as well. And so this one is basically using that same run as that I talked about earlier, that's a service principle in Azure AD to do authentication. And it will go and deploy resources.

And so in Azure, we have this thing called Azure Resource Manager templates. And so templates allow you to basically declare to describe how you want your resources in Azure to be deployed. Very similar to how DSC works inside of an in-guest, you can declare how your resources you want. And so ARM is the same way. And so all I'm doing here is calling

an Azure Resource Manager template that I've hosted up on GitHub. And then it's going to go and automatically deploy this. And so the benefits of doing this through automation and writing PowerShell inside of here is allows you to bring all of your automation you want to do in the cloud or even on premises and basically put it into one place that then you can call what you need to call.

So if you need to call some CLI that might be for VMware, you can call it from here. If you want to call Azure Resource Manager templates because you're deploying some Azure resources, you can deploy it from here. But it gives you these hooks where you can do pre and post actions that you might want to do as part of that delivery. So that's a pretty simple one inside of there.

Let me just go back for one second here. One thing I didn't mention is there's a corresponding Python one as well for starting them. And so the nice thing about this is we also have scheduling functionality. So say I wanted to start all these virtual machines in the morning for my test environments, I can just go author that runbook in Python

and then inside the service, I can just create a new schedule or use an existing one. So I could say, you know, hopefully our dev team gets in at 6 a.m., which we know is not true, and pick a time. So I'll pick six.

And then I could say I want to do it recurring and I'll run it every day. I'll start tomorrow. So just like that, you can basically create a schedule in our service. And what this is going to do is

every single morning now at 6 a.m., it's going to run that Python runbook to go start all those different resources I have in Azure like virtual machines or SQL or whatever I define. And it will just continue running. I don't have to worry about it. I can manage it centrally from the cloud. Everything is available through the experience. And so this kind of gives you a feel for all the different capabilities we have inside of the service natively.

But I'll just touch on the last language we have support for just so you can see how the platform is built. And so we also support GraphiQL runbooks in our service. And with GraphiQL, this basically allows you to author

everything graphically as well. And so those familiar with Orchestrator, we had as part of System Center, we have a lot of our customers who do all of the heavy lifting in PowerShell and Python, but then when they're trying to share knowledge about how their end-to-end service works, it becomes often useful that it's almost like a documentation tool, but it's actually implementation as well

to describe here's how all these different services connect up together and how I'm going to actually deliver them. And so inside of our core capability, we kind of encourage modular design. So you write smaller PowerShell scripts and then reuse those in all kinds of parent PowerShell scripts. The same is true for graphical authoring. So graphical authoring allows you to author

and then you can call sub runbooks that go and do the heavy lifting work for each part of the system, but you get an overall view on top of this and it's an actual job that will run that you can debug and it has all the core capabilities you would expect in a graphical authoring capability. And so all this is native inside the service and so it's really about

which language are you familiar with, what problem are you trying to solve and how do you bring your existing knowledge forward into the service and allow that to run without changes. Okay, so that's kind of the core of the service at a very high level. And so what I'm going to do now is kind of jump in a little bit about how do you do this kind of using the native tools

that you would want to use in your day-to-day work. So I'll jump back to the slide for a second and just talk a little bit about how this gets used going forward.

Okay, so I talked a little bit about all the scenarios that probably every one of you are doing some kind of automation across the entire life cycle of your applications and your infrastructure.

And so what we really want to build is how do we make sure that automation becomes core of everything that gets done inside the organization. And so what we built was as we started thinking about the life cycle, what do we need to do so as you're building out your infrastructure, you're building out your applications, how do we make sure that automation can plug seamlessly in there. If you need to configure those resources,

so maybe you're using DSC to configure the guest resources, or maybe you're not, you're just going to do it using imperative PowerShell. All of those capabilities can actually be applied from the service and touch each part of the life cycle of your application and infrastructure. So the thing we're trying to get to is no matter what you do, you should try to do automation either to deploy resources and configure them

but also to react to services. So if you get an alert, can you hook up automation easily to go and try to remediate that alert? And if you can't remediate it, can you easily escalate it into your ITSM or ticketing system so that manual intervention is possible? So it's really about trying to kind of build up an automation service that you can embed into your entire kind of IT life cycle

and allow a single place to transfer all that knowledge in and give you all the hooks and all the tools available. And so here's a lot of common scenarios we see customers doing with our automation service. And it's really, you can see most of these are standalone other services like monitoring as a service and security is often a service and deployment sometimes is a separate service. But how can we build a single automation platform

that plugs into the entire life cycle? So you're not really moving all of your code and all of your scripts into all these different services. You can put all your investments in one place, you can share them, you can actually apply role-based access control to them and then have all those other systems integrate into a single API to go and deliver that automation.

Okay, so that's kind of all the core scenarios that you can go through. What I'm going to do now is kind of jump into the demo and go a little deeper into all of the different tooling available to make it easier for you to bring a lot of this, what you do today, and bring it into the service as seamlessly as possible.

Okay, so you saw the portal and kind of its core capabilities inside of here. What I'm gonna show you is a couple of different ways that you can interact with a service. Obviously, you're not going to do everything in the portal. You're going to probably use some other tooling like VS Code, or you might be using the PowerShell ISE, you might be using source control. How do all these different capabilities

integrate into the service so that you can do all of your normal automation work, but instead of trying to run it in your on-premises environment, you can seamlessly hook it up into that single automation API and have it deliver the work for you. So I'm going to show you a couple of different pieces we have for that.

Okay, so if you're using the PowerShell ISE, then I will show you what you can do here. So there's a PowerShell ISE add-on that basically allows you to integrate into the Azure Automation Service. Oh, thanks, Lee.

Perfect. So I'm in the PowerShell ISE, and there's an add-on available up on the PowerShell gallery that you can search and basically install from the PowerShell gallery, and it will install a little add-on to the right of your ISE. And what this add-on allows you to do

is do all of your authoring natively the way you would want to see it. No worries. Let's see if I can zoom up here. It'll show my text, but it won't zoom this part,

but hopefully, I'll just describe what it does. I won't go into all of the details of each one. But what it allows you to do is basically do all of your authoring inside of your PowerShell ISE, but you can do it in offline mode. So you can author all of your PowerShell just the way you would do it today. You can test it using all of our built-in assets,

like our variables and our credentials. Everything that you could do in the cloud, you can basically do in your normal working environment, but then you can seamlessly upload these capabilities directly into the cloud. So if you remember, here are all the different ones that are available to me. So if I just sign in.

So it'll sign in with your normal credentials. You could switch the credentials and basically use a different authentication if you wanted to. Okay, so it's going to do and download, and then what I'm going to do is try to switch to one of those accounts that were created.

So here's that DevOps one I just created. So if you remember, inside of the automation portal, I created an automation account, and we ship a few built-in runbooks automatically for you. So here is, well, they're all in the cloud, so I'm going to download them.

So now I've brought in all my automation that's up in the cloud, and I've made it available locally for me. And then I can open up one of these. And so here's the PowerShell that we ship a couple of tutorials automatically, and these tutorials are available for me to actually go and use automatically inside of the ISE environment. And the nice thing about this is,

obviously we can do it for DSC as well, but those assets I talked about earlier, you can also start to see which assets in the cloud are available to me, and I can sync locally. And the nice thing is you can also create them locally and add more. So I'll just create one like test. I'm gonna pick it as a variable

and give it a value of DevOps. And so now I have a variable inside of my system that I can use inside of my local environment when I'm writing the PowerShell, but then when I bring that up into the cloud and say run from the service, it's also available inside the service at the same time.

So I could just upload this guy, and it's gonna upload that asset into the automation service, and so that account I created in Azure, it has a variable now called test. I could do it for the credentials, anything else you would wanna do as your author. And then inside of your environment, you could create your own book,

check test, you could create a partial workflow one or a script, and then the nice thing about it is you can basically go inside of these assets and just look at what it is, and I can also insert it. So now it's gonna pull in this variable. And then when you think these are actual special activities

that work inside of our service, but they're available emulated on your local environment as well. So now I have a DevOps environment. And so the whole idea is this, is you can basically leverage all of this service to build up anything you don't wanna hard code in your scripts, put them into these assets, like credentials, like variables, connection objects, everything can be stored and then used

inside your automation just like you normally would. So you can see I pulled out DevOps automatically. And then if I ran this, if I went and uploaded this, so I'm gonna upload real quick. I may change this, so I will save it.

So now it's just gonna upload it into the cloud, and then I can test it up in Azure from the ISE add-on as well. So now I was just gonna run the exact same thing I ran on-premises, I can run it in the cloud, and you'll see that I didn't have to change anything that I've authored and tested locally. It will work the same way up in the cloud. You can see it's gone into running mode.

And hopefully it'll print out DevOps. So just like that, we basically allow you to all of your authoring inside of the ISE, but seamlessly integrate into the cloud as well. And so this will work very, for all of your automation you do with PowerShell today, you can kinda keep doing how you do it today and integrate into the service automatically.

And so this gives you all that kinda core capability. So once you kind of have, you know, a knowledge of how the service works and how you can take advantage of all of, you know, runbooks, calling runbooks, and all of the assets, you know, you might start to move into more of a DevOps mentality as well and say, you know, I don't wanna just use the PowerShell ISE, although it is pretty awesome.

I use it mostly myself. You might start to use VS Code. And so how would you use VS Code to do this work as well? So for that, I'm going to jump into VS Code. And this add-on also can run outside of the ISE.

But now it'll integrate directly to VS Code or Visual Studio, depending on what you're using. And so this kinda gives you that flexibility to use the editors you want to use, but also get that native integration into the service as well. And so obviously inside of here, here's that Ignite one I was showing you, and here's all the different runbooks that are available.

And you can see what status they're in. Are they in sync with my local environment? Are they updated locally? Are they updating the cloud? Are they not on the local machine at all? You have full control over everything you have in your service. Here's all my DSC, all the assets I have. So everything is available locally, but in the cloud as well. And of course, you can upload modules as well from here.

And so one thing about this is, you can see here I have a Python runbook, and this runbook is basically just, you know, it takes an argument, which path you're looking for, and it takes an argument of, you know, what kind of extensions are you looking for? So I could just run this guy locally. So I'll just go Python, and then I'll do what?

Find file, can you guys see or zoom? I'll just do this, C colon temp, and I'll look for text files. So you can see there, it just ran locally Python, and I was able to point to a directory, and be able to kind of pull all that information in automatically.

The nice thing about this though, if I went back into the service, I could basically go and run this from the service as well, and do exactly the same thing. But I'm gonna change it a little bit, and not just run it in the cloud, I'm gonna target one of our hybrid workers, and show you how you can do it from there. Question?

For which part? Yeah, so there's a native, and so that's what you'll see if you're using PowerShell, there's a PowerShell extensions for VS code, and that gives you all of the IntelliSense, and highlighting everything else. All this, and the only one available that I know of is this one,

that allows you to connect directly into your Azure Automation account, and seamlessly bring things back and forth as you go forward. There isn't another native. Oh, if there is, that'd be awesome, I wasn't aware of it, it'd be good to know what. Oh, did you? Then it's even better.

Yeah, so if there's another native one, you can always just go to the extensions and install it. We should talk afterwards, and see if we can, how it works. Yep, so that kinda gives you this native functionality. But if I went back into my runbooks here, I'm just gonna show you a little bit how that same one I just ran,

can work inside of the cloud, but actually target resources that are not in the cloud. So I'll go into edit, and you'll just, so we can see it's the same. But I can go and test this now, and so I could actually go and run this in the cloud, but it wouldn't make much sense, because I'm actually looking locally

for some directory and some extensions. And so this is where our hybrid worker can actually come in, and be useful. So I'll just do the same, this time I'm going to look though on Linux, and not Windows. So it's the same runbook, but obviously Python works on Windows and Linux, just like PowerShell does now. And I'll go for,

let's do a, asterisk dot txt, I think I said. And I'm gonna pick a hybrid worker this time. So I have an Ubuntu server, that I'm going to run this automation in. And so what's happening now is that, I've registered a couple of hybrid worker nodes, in my environment.

And what those nodes are doing, is they're reaching out to our service to look for work. They're gonna pull down those scripts, either Python, or PowerShell, or GraphiQL, and run them inside of the environment. So there you can see it already finished. And so everything I've done in the cloud, I can either say I wanna run it in the cloud, because I'm managing cloud resources, and I wanna take advantage of what the service offers.

Or if I need to get into my local environment, this, you know, I have an on-premises environment, or I'm trying to get to another location that I can't easily connect with the internet, then you can just stick a hybrid worker in there, and it will reach back, and the exact same code you write, all the assets you write, all the resources you write, it works exactly the same as if you're on the machine, and you were running it yourself.

But it's all controlled from the service up here. So obviously that's pretty nice. And if I said no, I'm just gonna target Windows instead, you know, I could do the same thing, I'll change it. Look at temp maybe instead, and see what's in there.

And this should go, and now it's gonna pick up a different hybrid worker on this machine, and it's hopefully gonna run it as well. The nice thing about these hybrid workers is that you can target a single machine like I'm doing here, but they can also be registered as a group of machines. And what this allows you to do

is basically create high availability of your hybrid workers. And so you can target a specific group, and so if one of the nodes went down, oh, I don't actually have Python installed on that machine, so I can just switch to PowerShell, and it would work the same way. And so the idea behind those hybrid workers is that if a machine goes down, it won't matter.

We will actually automatically pick up any available node in that hybrid worker group, and be able to deliver automation. So not only do we kind of have high availability, obviously built in the cloud, we wanted to make sure we had high availability built inside of your on-premises environments as well. So you can kind of make sure no matter where it runs, it works and executes exactly the same.

Okay, so with that, I'm going to switch over to a little bit of one last demo, and kind of show you a little bit about how we do our integration across a bunch of other services. So I'm going to do a quick watchers. So I'm gonna show you how watchers basically work.

Yep, so I have basically this watcher. I've tagged a couple of these so it's easier to find scenarios. And so I have a watcher that basically is going to watch for new files in my local environment. If I see a new file, I'm going to actually

process that file. And so I just wrote a couple of runbooks that do that work. They're just PowerShell scripts. But the nice thing is I can hook them up into our watcher service. So you can see here I have a watcher service running. And what this does is leverages that hybrid worker groups we talked about. But now that PowerShell that you write, it will actually go, and it will go listen

to new work that might be showing up. So in this scenario, I'm looking for new files to get dropped in a directory. And if I see new files, I wanna go process them. I could process them back in my local environment, or I could go process them in the cloud. So you have the flexibility of not only where do you want to process those on premises or in the cloud. All of that can be hooked into a single watcher's capability.

And if I look at some of these I've done, just make sure we keep the time. You can see here I ran one this morning. And the input, so this was sent to me from the watcher when it finds new work. So I create a new text file. And then I was able to process that input and be able to see that a new myfile.txt was created.

And so the real power about this is now you can basically create these watchers to go and manage and watch for everything happening inside of your environment as a trigger to go do automation. So that's one way that we have triggers that you can do automation. Obviously you saw scheduling as another one. The last one I'm gonna show you is how we can do it using Event Grid.

So I don't know if you guys are familiar with Event Grid, but it's a service in Azure that basically is kind of a publisher subscriber model. But they have a lot of events that they already track natively inside their service. And so one of the things they track is Azure subscriptions. And so we can build native integration into Azure Event Grid as well.

And so what this one is doing is it basically is saying any time that a new compute resource gets modified inside of a resource group in Azure, I actually wanna get called because I'm gonna process that resource and do some work on it. And so here you can see they support a type called Webhooks.

And Azure Automation has the ability to create a Webhook on any Roam book inside your environment. And so what Webhooks to do is they basically allow you to include the authentication as part of the Webhook call. And so that it's very easy for external systems like VSTS, Event Grid, it doesn't really matter, GitHub, anything that supports service hooks or Webhooks,

they can automatically call automation when events happen. So this one is just calling this event. And I'll show you a little bit about how this works. But when this actually gets created, what it does is it processes the event from compute and it does a couple of things. One, it adds a tag to compute to saying this is part of a start, stop, shut down.

So then I can target with my automation. It also sends an event into Teams using PowerShell so that it's available inside of my Teams experience. And so here you can see where I got a new VM created. And not only did I can click on it from Teams and be able to manage that new VM that got created.

And so as you guys know, the real power of PowerShell and Python and all these others is they make it very easy for you to integrate into other systems as well. And so not only do you do it from the scripts, but there's so many modules that are written out there. You can literally just bring any module that you've written yourself or any module from PowerShell gallery or any other place and just import them into our service.

And then now you can start integrating and managing those different systems just by bringing in a module and writing PowerShell. So for this one, I integrated directly into Microsoft Teams. Every time a VM gets created, I add some, let me see if I did it. Yep, so you can see I added a new tag to this VM that says auto-shutdown startup is true.

And so because I've kind of added this metadata onto a resource that got created, my other automation now can feed off of that and say, okay, every VM that has this tag is part of the shutdown experience and I'm gonna shut this down at night and then start it up in the morning. And obviously the owner then could go in and set this to false if they're like, no, I don't want my VM to be part of that overall schedule.

So it offers this kind of automation, but it also delivers self-service as part of it. And so these are just some of the scenarios where it's very easy to integrate into all these different capabilities. But the core of it is everything is kind of based in this one automation platform that allows you to integrate into all your on-premises as well as your Azure environments.

The one thing I'll just mention as well, there's so much to kind of, to go through inside this automation platform. As you can see, it's a pretty large platform, but we really did try to build it based on learnings we got from you guys literally over the last four years as we built up this service. There's also native source control integration. So you can integrate directly into GitHub

and then VSTS is coming hopefully in the next month or two. But there is a way to integrate with that natively. And the advantage of doing that is if you bring up like VS Code, you can check in directly inside of VS Code into VSTS or GitHub, and you can automatically basically mirror

all of that automation that you're creating through source control back into the automation service as well. And so instead of going from your local box directly into the automation service and then offering it there, you can also integrate directly into all of the source control tooling you might be using and have it come back into the automation service. And so then you get all the benefits of source control that you might be using as well.

So again, it's kind of another scenario where it's very easy to integrate whatever tooling you're using back into this single automation service no matter how we need to get that content synced up. And so this one is a very similar type of thing where you can just change it. This one I'm using VSTS with Git. But if I made some changes here and checked them in,

they will actually go into my automation account and automatically sync them over. So it's just gonna mirror those changes. And obviously it depends on if it's the master branch and you can specify which ones you wanna sync. Question. Yeah, so the question was really around, we have this kind of two concepts inside the service which is draft and publish. And the idea behind that was it was really designed where

you may not have source control set up and we wanted to give the capability for customers to say, I'm working on a set of automation but don't make it available in production yet. And so that you can't start it, you couldn't create webhooks on it, you can't schedule it, you can't do anything with it. So you can have an official version that's actually running but you can work on this edited mode, draft mode.

And then once it's ready you can promote it into publish mode. So it's not usable in draft mode. So it's not usable in draft mode so you can't call it externally, you can't do all of those endpoints. You can just author it and test it but you can't basically publish it and then hook it up to an external endpoint.

Yeah, so what we see, what we see a lot of our customers doing with source control is they'll actually end up creating two different automation accounts. So they'll create an automation account for like tests or pre-prod or whatever you need to have and then they'll have an automation account for production. And so what they allow them to do then is they can point their test automation account

to the test branch that they're working off of. And so they can check in there, it'll automatically sync it over, do all your testing there. Once they know it works correctly in the service then they can promote it into their master branch through source control. And then it'll automatically sync into the kind of a published or production version automation account. And then so you never have to work

off the production account. You can do all of your testing inside of the test automation account that matches your test source control. Great, okay, I only have a couple minutes left so I'm going to jump back and just show the last slide and then leave a little bit of time for questions as well hopefully.

Okay, great, so this was the last slide and so I kind of wanted to just wrap up. Hopefully you got a good view of the kind of capabilities. What we're really trying to accomplish is everything you've built and learned and all of the scripts you've written over the last 10 years on PowerShell

and maybe longer if you're using Python and other languages. How can you start to take advantage of all of that investments you've done? Bring it into a cloud in the exact same way you have it today but then take advantage of all these unique value adds that we have inside the service that you don't have to worry about. You know, is infrastructure going to be up when I run these? Where do I store my credentials? Can I put some role-based access control on them?

Can I integrate them easily into all these different systems? Do they support webhooks? Or is there an SDK? All of these capabilities are native in the service. And so kind of you think about it from your authoring, through your resources, the community integration, triggering how you want to do your automation, integrating with your DevOps pipelines. The platform's really been built to try to support all of those capabilities

and so if you haven't had a chance, you know, I think the ask would be, you know, try it out, see if it works the way you would like it to work and if not, please give us feedback. The one thing about the service is we're constantly adding new capabilities. Literally every week to every month, there's new capabilities and new features because it gives us the opportunity to get feedback quickly, iterate, deliver it into the service and then make it available to you almost straight away.

And so if you haven't used it, please try it out and just give us as much feedback as possible so that we can keep iterating and kind of make sure it is the automation platform that you guys need as you go forward. Okay, with that, I think I'm out of time so I just want to say thank you and I appreciate everyone coming.