So this post is a bit different than my previous ones, as this is the first to not really be related to System Center Service Manager in a long time. That’s because, well, my focus will likely be shifting off of SCSM in the next few months and more towards SCCM and Microsoft’s new Azure offerings like EMS and OMS. A career change will do that to ya 😉
Anyway, as part of my recent exploration into the Azure-sphere, I’ve found a love for OMS. I’ve been looking for a compelling replacement for Orchestrator for a long time. In order to be really useful, a new solution had to be:
- Lightweight (My SCORCH boxes are usually single-box, 2 Core/4GB Memory. So awesome)
- Simple to setup/use
- Support PowerShell in all its glory!
SMA/WAP doesn’t fulfill requirement 1 or 2, and personally, nor does it really work with number 4. PowerShell Workflows are not exactly native powershell, and as I’ve yet to build something complex enough to *need* PowerShell workflows, the added complexity is just cumbersome.
Azure Automation sounded great when it first came out, but the lack of on-premise support was an issue. Once Hybrid Workers and native PowerShell (non-workflow) support came out, it was clear AzureAutomation was my new friend 🙂
So, now we’ve got this awesome, fancy new automation platform, let’s try and do something that I’ve never been able to do with SCORCH – Kick off a runbook via a URL! The XML Structured requests in SCORCH always made web browser’s unhappy, and so I was loving the new REST interface we’ve got with everything Azure, specifically, Azure Automation webhooks.
As I’ve done a bunch of work with the Cireson Portal lately, my knowledge of jQuery/HTML/CSS is pretty solid. I wanted to make a basic HTML website, have it take in parameters, and then run a runbook from AzureAutomation once I hit a button. That runbook should run against a local lab environment, and, in this case, would actually create a new user in my local AD environment, and email some info out on user creation. Easy? Simple? Eh, kinda.
I’m going to take this in 3 parts, so it’ll be a few different posts. I’ll link to the rest at the end!
First thing is first, we need to setup OMS, which is the platform for Azure Automation. Let’s hit up that OMS website and click that nice ‘Try for free’ button. Isn’t Microsoft nice!!
Well, that was easy! Let’s click the big blue ‘Get Started’ tile.
While there’s tons of functionality here, we just want the Automation for now – you can see I’ve checked the ‘Automation’ box in the lower right corner.
Once that’s installed, you’ll want to go back to that same ‘Get Started’ tile and setup our data sources. Don’t stop on the ‘Solutions’ tab this time, find the ‘Connected Sources’ tab and let’s take a peek at the ‘Attach Computers Directly’ section. That’s what we want to use! This will let us setup a local Hybrid Worker for automation. Download that Agent (64 bit obviously, you’re not using 32Bit OS’s in 2016, are you?) and save it someplace safe. Also, leave this page open, we’ll need that workspace ID and Primary Key.
When you download the agent, it’ll look like any other Microsoft Monitoring Agent. But it’s not just any agent, this is the one unique to Azure Automation! You can see I’ve given it a bit more detail in the name so I can find it later if I need to 🙂
Note that this cannot be installed on a machine that already has the ‘Microsoft Monitoring Agent’ on it – something like a box monitored by SCOM or a machine with an SCSM Agent installed (Management Server). Since they all are variations on the same ‘agent’, they must be unique on each box. I haven’t dived into SCOM monitoring of my HybridWorker, but that’ll come in a later post 🙂
Oh, and one last thing. For connectivity purposes, Microsoft just says the runbook worker needs web access to Azure! Make sure ports 80 and 443 are open to *.azure.com, and you should be golden. No messy ports to deal with – I love it!
This is what I’m talking about! Let’s link this to OMS.
You might have my ID, but not my key! Muwhahaha. This comes from the page we left open above. The Key is the ‘Primary Key’ from the Connected Sources tab.
Alright! That’s it. Pretty simple, right? Our hybrid worker should be setup and connected to OMS. If you head back to the OMS portal, it should show a connected Data Source now on that pretty blue tile:
Yess!!!!!!!!!! Now, in a lot of ways, that’s the easy part. OMS is just a *part* of the equation. We now need to link that OMS workspace to our actual Azure subscription, so we can manage Azure Automation from our Azure Portal. Got it?
OMS + Azure = Azure Automation!
I’m assuming you already have an Azure subscription, and if not, well, it’s easy and there’s tons of posts on it 🙂 We’re going to want to login to our Azure Portal (The new Azure Portal aka ARM), and search for the Automation content pane.
I hope you clicked on that little ‘star’ icon above so it got pinned to your left hand navigation. We’re going to be using this a lot 🙂 Now, let’s open the pane and hit the ‘Add’ button, then click ‘Sign Up’ on the right hand side.
This is going to do some interesting things if you don’t have an existing Azure subscription linked to this account, but ultimately you’ll get dropped back to the automation screen if you need to do anything here. Don’t panic! You’re on track 🙂
Phew! Billing is sorted, back to Automation. Let’s create a unique name and resource group for this bad boy. Think of resource groups as ways to keep resources distinguished between multiple customers. Azure is multi-tenant, so you’ll see a *lot* of separation built in. For smaller customers, or since we’re just doing an example here, we need not worry too much, we just need one resource group to assign resources to.
Here’s me making a resource group! Pretty easy 🙂
Awesome! We’ve now got our Automation Account setup. This configuration thus far has been *all* on the Azure side. Don’t you remember that equation from above? OMS + Azure = Azure Automation! We’ve got Azure all setup, and OMS all setup, now let’s link them so we get access to that Hybrid Worker.
You can see we’ve clicked on my Automation Account, clicked on the ‘Hybrid Worker Groups’ tile, and have clicked on the little ‘Configure’ icon at the top. It gives us awesome instructions on how to do this, but again, since we’re dealing with both Azure and OMS, it’s still a bit confusing. Basically, we did all the hard stuff before, this is just going to establish the linkage between our Azure workspace and the OMS workspace we setup earlier. They don’t *have* to be linked, which is why they exist separately, but for Azure Automation, we need that linkage.
In the above screenshot, see that ‘Step 1’ section? Make sure you’ve clicked on the second bullet in there where it says ‘Login to OMS and deploy the Azure Automation solution’. It’ll bring us…
Deja vu! Let’s sign back in…
Oh! Cool! We’re linking our OMS subscription to our Azure one. We want this.
You can see that there’s a new tile here ‘Solution requires additional configuration’ for Automation. Let’s click that.
It wants to link our Automation Account to Azure! Yes, yes, we want this. Save it and don’t look back!
Bow chica wow wow! You can see our Automation tile now shows the little Azure Automation icon with our Azure Automation account name at the top. It also shows a runbook now, which is cool. I like runbooks.
Now, if you haven’t taken a break at this point, don’t do it now! We’re so close to success I can taste it. We’ve got Azure setup, we’ve got OMS set up, and we’ve got our Hybrid Worker setup. The last bit is to add this Hybrid Worker to a Hybrid Worker Group so we can use it. I know, I sound crazy, but think of it kinda like a resource within a resource group. It exists, it’s functional, but it needs to be assigned somewhere before we can use it.
Microsoft has a great post on adding a runbook worker to a Hybrid Worker Group. I’ve screenshotted the good stuff below :
Luckily it doesn’t show my entire key in this screenshot 🙂
Here’s me adding things!
Boom! The command completed successfully and if I go back to the Azure portal and refresh things…
Hybrid workers for days! You’ll see I’m using my Orchestrator box for my new Hybrid Runbook worker. It works perfect! It’s a Server 2012 R2 box with 1 Core and 2GB memory. Insane, right?!
Now, this looks good, this looks fine, but the proof is in the pudding. We need to do a quick test to make sure this is all working. I’ll write a quick runbook to write a file locally on the Hybrid Worker and make sure that comes through!
To make a new runbook, easy enough, we just click the ‘Add a runbook’ button at the top there. You’ll see it opens up the ‘Add Runbook’ pane, where we can select ‘Quick Create.’
Lets fill in a few things…
Note: Powershell is no the same as Powershell Workflow! If you don’t know the difference, select ‘Powershell.’ If you do, then select which one you need 🙂
We’ve got a blank space!!! Wasn’t that a song? Right, let’s fill it with some basic stuff to just write to a local file on the Hybrid Worker.
That wasn’t too hard now, was it 🙂
You’ll need to hit the ‘Save’ button first. Once you do that, you’ll see it greyed out, and then you’ll need to ‘Publish’ the runbook to actually use it. It’s functionality that is pretty similar to what Orchestrator used to do actually…
Done and published! Don’t mind me, I’ve made a few other runbooks here too… those come later 😉
Let’s select the runbook, and hit that ‘Start’ button. Once we hit it, we’ll get the option to input any input parameters (there aren’t any in our case) but more importantly, specify if we want to run this just in Azure, or on a Hybrid Worker. Let’s pick the Hybrid Worker!
If we hit ‘OK’, you’ll be returned to the Job Summary page, where we can wait for it to finish. Don’t blink! It happens quick.
Yes, I know it’s a different Job number. The runbook ran too fast and I had to start a new job to take another screenshot 🙂
Beautiful! We’re in business! You’ve got Azure Automation on a Hybrid Worker in your environment now.
These Hybrid Workers are awesome in that they work:
- Faster than Orchestrator from trigger to execution
- Better than Orchestrator in their fault tolerance (Hybrid Worker Groups) and logging
A few last minute notes:
- You these Hybrid Worker ‘groups’ are exactly that – they can be groups of machines and the request can be passed around to the first available one to load-balance. In our case, we only have one, but it works just fine with a single worker in a group.
- If you want to use any commandlets locally on the Hybrid Worker, make sure they are installed by you! Azure Automation won’t do any of that part for you, but other tools in the MSFT toolkit will! (Think DSC 🙂 )
That’s all for now, check back in just a bit for the next two posts on making the real magic happen!
Update: Part 2 is now live!