Patch ‘em All?! Post Session
If you attended the Midwest Management Summit session that I did with Adam Gross, then you likely have already seen everything I'm about to cover, but just in case this is your first exposure to Azure Arc, I can't wait for you to read on and hopefully take away some ideas on implementation in your own environment.
What is Azure Arc?
According to the official Microsoft docs, "Azure Arc simplifies governance and management by delivering a consistent multi-cloud and on-premises management platform." How that translates for me is that Azure Arc is the first step to reviving the first-class citizen status that your servers once had back in their glory days. Azure Arc creates an arc (see what I did there 😜) between where your resources currently live and Azure, allowing management of your resources in one unified location.
Why Azure Arc?
A consistent pain point that I've had since starting my Engineering journey and striving towards cloud-native has been, well what do I do with my servers? It always seemed as though managing my on-prem servers, or servers hosted in another cloud, was going to be tech debt that I wouldn't be able to address unless I rebuilt these servers in Azure.
In came Azure Arc to the rescue! Finally, a management method that gave the flexibility to address current management pain points while also extending Azure features (Log Analytics, Managed Identities, Defender for Cloud, etc) giving additional management capabilities, and a single pane of glass.
Enrollment
Enrollment. Truly, not anywhere near as scary as it seems. It really is as easy as the Microsoft Docs say that it is.
Enrollment Steps
1. Navigate to Azure Arc in the Azure Portal and from the drop-down select Add/Create and then Add a machine:
2. On the Add servers with Azure Arc page choose Add multiple servers (you’ll see why in just a moment) and select Generate script.
3. For the Project and server details, use what makes the most sense for your environment. For this blog post, I’ll be choosing all of the following:
4. Tags - adding custom tags is one of my favorite methods of managing servers with Azure Arc. I recommend adding tags that make sense to you and your environment. You can add tags later, but for this enrollment, you'll want to choose a grouping of servers that you plan to enroll and manage all together, for instance a dev patching group.
If you leave any of the tag values empty, those tags won’t populate.
5. Downloading the script. Choose a deployment method that works best for your environment. I personally would recommend Configuration Manager, or if you’re feeling fancy, Ansible.
6. Tada! The server that I enrolled is now in Azure Arc ready for me to manage, with the tags that I had configured during enrollment.
Azure Update Manager
Now that we have our server enrolled in Azure Arc, here’s where the fun begins.
One item of note that I do want to call out, when first opening Azure Update Manager, you’ll see your newly Arc-enabled server under the machines blade. That does not mean that the server is being patched with Azure Update Manager yet.
From the Machines blade, select your server, select Settings, and then Update Settings:
On the next page you’ll want to enable Periodic assessment so that the server can be assessed for patches.
Note: Patch orchestration is not application to Arc-enabled servers
I’m a bit impatient, so my next step is to select my newly enrolled server and click Check for updates from the machines blade of Azure Update Manager. Checking for updates will kick off an assessment on the server allowing me to do something with those updates, as well as installs the WindowsOsUpdateExtension. Fantastic, right? But who wants to sit around and wait for updates and manage them manually… I definitely don’t! Off to automating the installation of those updates.
Maintenance Configurations
An easy way to think about maintenance configurations, if you have a Configuration Manager background, is to think of them like maintenance windows in ConfigMgr.
Creating a Maintenance Config
From the same Azure Update Manager machines blade, select your newly enrolled server and click Schedule updates.
On the Basics tab input all of the details that align with what makes sense for your environment, and then for schedule, this is where you’ll configure all how often you’d like this schedule to run:
Dynamic Scopes is where the real magic starts to happen, in my opinion. After choosing the Filter by field you’ll have a list of filters to choose from…including… TAGS! Would you look at that? The custom tags (location tags would have also been available to use had I set them) from earlier now serve as a dynamic assignment option for this maintenance config.
For the Updates selection there’s the following options:
Include update classification
Include KB ID/package
Exclude KB ID/package
I’m going to make my update classification selection and continue on to Review + Create.
What about Server 2012 R2?
I thought you’d never ask… Enrolling Server 2012 R2 into Azure Arc is just as easy as enrolling newer server OS’. The one dependency is that Server 2012 R2 needs to be enrolled into Extended Security Updates (ESUs) per Microsoft’s Deliver Extended Security Updates for Windows Server 2012.
Installing Critical Updates
Automating update installation so that it can essentially be set and forget is definitely the ideal scenario, but as most of us can attest to, the ideal scenario is a lot less common than we’d like. What happens when you need to install 5 minutes ago? Not to fear! That’s where the one-time update comes into play.
Installing is very similar to steps from earlier, we’re going to choose One-time update from Azure Update Manager.
I do wish that the following pop-up didn’t make it seem as though clicking Install now was going to IMMEDIATELY install pending updates.
After clicking the Install now a much less intimidating page emerges, just like before, allowing you to choose the machines, update classifications, include by KB ID/package, exclude by KB ID/package, and include by maximum patch publish date.
Reporting
Where can you find the results of patching? From the Manage tab in Azure Update Manager select History. From there you’ll have the option to choose either By Machines or By maintenance run ID:
Clicking on the Open query in either the Total machines or Update deployment status boxes, Azure Resource Graph Explorer will open on the next page. I find this quite helpful as someone that has quite a bit to learn when it comes to KQL.
But why Azure Arc?
If you’ve made it this far, the real question is, why should I use Azure Arc? Sure it’s cool to be able to manage resources in Azure, but how will this impact my day to day?
For me, I kept finding that server management was what was stopping me from fully cloud-native. I continually kept coming back to on-prem management tools to manage my servers, especially when it came to updates. I needed a solution that was simple, created a single pane of glass for reporting, and got me one step closer to fully in the cloud. Azure Arc allowed me to manage servers hosted on various platforms and treat them all as though they were Azure native VMs. I finally was able to cut my time spent patching by a good 75%, managing double the amount of servers. That time savings alone allows me to now focus on modernizing the rest of my environment because I no longer have a complicated method of management, I now have a cohesive management methodology that will scale (thank you dynamic scoping!).
This is just the beginning of what can be done with Azure Arc! Keep your eyes peeled, I’ve been saving some of the automation that can be done for another blog post.
Resources:
The secrets to patching ‘em all?
I can give you a hint where to start looking -- follow my GitHub, AllwaysHype.
Follow me --> AllwaysHyPe GitHub