Azure Update Manager 2023 Edition

hey everyone in this video I wanted to talk about the new version of the Azure update manager completely recreated using different backend Services interacting with the clients in completely different ways now patching is not the most exciting technology very rarely of our hearts are flutter thinking about patching but it is critical it's really that first step when we think about any kind of even security as we patch bugs we patch security vulnerabilities so step one in anything is to make sure we're patching but you can't just generally in a real environment just automatically roll out patches to every OS at the same time because if we think about well some new patch comes out our application may have a problem with this patch Maybe there's a bug in the patch maybe the application has been doing some behavior that was not documented and has been modified in the patch so we want to always make sure when we apply patches we do it in a staged rolled out process that validates hey our application our workflow still functions correctly so we always think about well firstly we want to apply that to some set of test systems maybe test system one and in here we want to do very fur testing now that testing would be both functional are we testing all the various code paths the directions and the components that could get called based on different scenarios but also I want to make sure I'm still doing a good load test that is proportional to production and by proportional I mean well if production gets a th messages a second but my test environment is a 10th of the size well I want to see 100 messages a second I want to make sure there's not been some performance um implication with this patch and I'd look at baselines i' make sure it's behaving in a consistent Manner and then we' think about well once I've completed that testing then sure now that patch could go to a second set of test systems where again there will be some testing I'll monitor it and only after that would I then think about well it can go to my first group of production systems and typically especially in an Azure world but it could be different data centers we're going to base that on some location or region or even ring of services and then again then we'll go to the next one and typically we'll always think about some time window maybe 24 hours to make sure look there was some scenario we missed it didn't get caught in a Dev environment but hey it gets found when it hits production but at least we've not hit all of our locations at the same time hey it's broke here we'll F over to Dr fix it and I want enough time that I would see the problem happening so we have this idea of going through these rings when we deploy we do the same with desktop operating systems we don't just hit everything at once we do this very staged roll out we're monitoring all the time we're looking for signals that may say hey there there's something not quite right about this process therefore if I'm thinking about well I want this orchestrated process I need a patch orchestrator now there are many ways we can do this we can do things like hey the system center configuration manager for clients there's in tune there's other MDM Solutions there's WS so we have many different ways of doing this and what I did in the past is I did a video all about the update options we could do in Asia and as part of that I talked about the initial Azure update management solution well that solution has now been updated so I want to quickly touch on well what was there in the past for the Azure update manager and then really what's changing so Azure update manager and it goes without saying this is both windows and Linux both the Old and the new obviously many many organizations have huge amounts of Linux huge amounts of Windows we need to be able to cater for both of those so we're focusing on this the V1 solution was very widely used it was built on log analytics workspace and then it used Azure alteration so there was a certain amount of on boarding I had to do a certain amount of work it had to have running and as part of this Azure automation what that was actually using to go and Trigger activities was this hybrid runbook worker now what that did mean with that hybrid runbook worker is we often hear about Azure Arc the ability to take the Azure control plane and bring it to systems outside of azure spefic speically Arc enabled server operating systems brings that Azure control plane and its capabilities to Windows and Linux this did not require Arc you could have Arc but it there was no requirement for that to function now with this there's a certain amount of onboarding I had to do but also its capabilities were fairly Limited in terms of customization for example I only had very very basic scheduling I couldn't for example schedule based around hey Patch Tuesday let's have some offset after that I had to manage two different groups if it was my Azure machines or maybe it was my Azure Arc machines um there was no on demand capability to just trigger it there was no granular ro-based access control I could do my RO based access control of the level of the lock analytics or the Azure automation account that was it I couldn't do anything else um to try and say hey just these groups of virtual machines you can manage the patching on so now we're at the V2 solution and as you would expect they've really worked to address these limitations but also this on boarding was a fairly painful thing to leverage this to leverage the hybrid runbook worker and so it's been restructured and Rewritten so instead of relying on for the storage of the patches and its state instead of log analytics what it's now based on is the Azure resource graph and if you've played around with Azure you know the Azure resource graph is that super high performance database we can use to interact and find information about all our Azure resources in the environment so there's no log Antics workspace there's no Azure automation account it's now just a native feature of the Azure Fabric and it's using the Azure resource graph for the storing of any status it needs about the patches that it has that it's missing reboots required everything is now just in that Azure resource graph additionally now because we're not using Azure automation there's no hybrid runbook worker so what it's using is its extension based now that extension basis obviously opens up some requirements there about well then how does it interact with things that aren't in Azure because if it's extension based well then that's super obvious for the Azure VMS that's easy we can add extensions no problem it's in the your resource manager the control plane already hey add this extension and note this extension is just going to get added automatically the first time it needs to patch I don't have to do anything ahead of time to enable this it's just going to set this up if it's not AER based then I do require it to be an arc enabled server o so that's the key point now it requires AR now remember Arc enabled server OS is free I don't have to use the separate additional capabilities that are paid but I can just use the free out the box and then I get basic inventory information control level fabric information hey I can assign certain windows for example capabilities Linux and windows I can SSH into them there's a whole set of nice features I get just from that Arc enablement and of course extensions I can run things on them manage identity Integrations but I am going to require that Arc enablement now so that's how this is going to function but then when I have this in place now I'm going to get very very rich scheduling and I'll walk through this so we can especially like Patch Tuesday is a big one hey yeah I want it to happen after patch Tuesday with a couple of days after it I very rich grouping of machines based on many different attributes again we saw that picture of well hey different environments different locations I'm going to be able to leverage all of that and I have VM level ARB back so very very granular arback capabilities so that's really what we're going to do here now I want to point sank out right at the start CU it's really important so when I think about those Azure virtual machines there's this step one that I have to do and it's to do with how the Azure resource is configured for its patch orchestration and you're going to see this in documentation all over the place so the most important thing is just for this just for the Azure VMS it doesn't apply to the arc but for the Azure virtual machines I have to set this customer managed schedule very very important if I don't do this various things are not going to work correctly now if we jump over and had a look super super quickly I'll just show you what this looks like today there's a little bit of a difference in the flow and enabling this if I was creating a new VM versus hey now I'm using Azure update manager but if I was to quickly go and look at a couple of machines um let's pick an arc and you'll actually notice it shows me here is it an Azure VM or an arc enabled machine but if I was just just to pick a couple and the settings I have this ability to update my settings and all I have to do is here's the important part for the patch orchestration I need it set to this customer managed schedules that's what mine is set to so that's correct but I need to go through and make sure this is done so this is just an important part when you on board it I can configure this but I have to make sure that notice for the arc enabled it's not available Arc does not leverage those settings doesn't support Hot Patch but that's a super important step that I I need to have done to make sure this all functions okay important step so now how's it actually going to work like what is this doing behind the scenes to enable me to patch at a large scale but in a very controlled manner so if we think about what what do we have to have in place to be able to do patching so the first thing I have to have done is I have to actually run an assessment so I need this assessment I need to understand what patches they have what patches they are missing now on Windows it's just wind using the Windows update agent so it's using the builing capability if it's Windows to do the assessment piece if it's Linux it's using these oval um compatible tools to do the assessment of what patches is missing there's going to be oval definitions based on the specific platform that can be retrieved from a local or remote repository so we have choices on that but what we want to do is enable this periodic assessment and what we have here is this idea once again it's time based but we want to run it every 24 hours and we can see that in the screen we were actually just looking at we can configure that option so if I jump back over to here we can see we have this option of periodic assessment and this applies both to the aure and the arc enabled server operating system so we've set that to enabled so what that means is every 24 hours it is going to go and check for that now instead of applying it at a machine level if we actually jump over to the getting started it will also show us the other options so hey I can sign a policy so if we use the a policy now it's just going to use Azure policy and there's some built in so we can see we have these built-in policies down the bottom schedule recurring updates using Azure update manager so we got the scheduling and also we can see configure periodic checking for our Arc based and also the regular Azure based so it's really these bottom two we'll focus on just for that checking every 24 hours so we can leverage this and then through this policy it would configure us to have that 24-hour check for all the different operating systems in there so I can either do it on a per Machine level or I can actually go and do it via Azure policy the other thing we can do as well is if we went and looked to the machines and again I could pick a few Ma machines here one of the options I have is I can do an on demand so I can say hey check for updates so I can check for updates on a selection of machines I think it's up to 100 I can do at any one time and I can do an assessment now so it would go and do a check to say hey are we missing any um patches let's go and do that assessment using those local tools so if we jump back over so yes we have this periodic option but also we can trigger an on demand and now we know what the status is so one of the options we have all over here is there's reporting so there's reporting to we can see hey what have we found but we'll also see hey there's reporting when we actually go and do the patching and I guess I'll just quickly show that so if we jump back over again we can see it right here so it's showing me when I look at the machines well I can group them and I can see various bits of information uh about this but also just in the overview page this overview page is really nice once again I have these filters I could activate again tags over here is super super useful but also the update status of all the machines but I could change it to only certain classific ations if I wanted to I can see the patch orchestration configuration of the Azure VMS so this is where I can see hey look I really need that customer managed schedules if it's not I could go and find the ones that aren't and update them and notice it's showing me the query it's using I can see hey my update runs um where am I with Windows where am I with Linux then I can dive into the particular machines and once again I can see ones with no update data ones with pending updates sorry no pending updates ones with pending updates ones that are pending a reboot ones that are unsupported and for any of these I could just dive into it select it and I can see the detail of what exact patches it's actually missing so just huge amounts of detail available to me and I can even create my own um reports so there's an update reports and I can edit this I could duplicate it and create my own to get even more different views of all the different patches the status the main ones that are missing all different schedules all of that information is available to me so just huge amounts of functionality there to really get good insight and again customize however we need it so once we've got that assessment up and running so next thing we'd have to do is the actual patching and so what we want to do here is we're going to go ahead and create a schedule so I'm going to think about well I'm going to create these schedules and what you'll see written a lot here is it's a maintenance configuration and there's a number of aspects to this configuration now the first part of that schedule is obviously hey is it a one time is it a recurring uh I can specify a window so I can have things like the window of time that I can run this maintenance event for I can have repeat capabilities one of the nice things about the repeat is I can include an offset so you think about those Patch Tuesday scenarios hey I need the second Tuesday of every month but I want you to offset one day two day three day four day five days for different groups of machines and of course that's super important when we go back to this idea that hey let's say Patch Tuesday happens hey those initial test group offset one day offset 2 days offset 5 days offset six St so I could create different schedules based on the different groups and machines and those different groups and machines could be based on environment tags and then when we get to production it could be based on location so hey I'll do East Us 2 and then day later I'll do West Us 2 when the tag is environment so these are really important but let's dive over and start setting one of these up so I have this idea of schedule updates so I'll say yes we want to schedule an update I would give it a name I don't really care about any of this and what is the scope so I can do Azure VMS and Arc enabled VMS so I want to use those I can configure the reboot always reboot reboot if required never reboot and I can add a schedule so here we can see what I can set a start when I'm going to start the schedule existing I set the window of the maintenance time and then I can set a repeat so what I'm going to do here is I'm going to change this repeat to be monthly and then I could say something like hey this is going to be for maybe windows it's the second Tuesday and then for my first Dev so for this particular configuration this will apply to my first group of test servers I'll say it's a one day offset the next group of test servers maybe is a three-day maybe I do two days of testing if it was my first group of production I'd say it's 5 days not 50 and for the second set of production maybe it's 6 days etc etc so you can see I could create different schedules for the different groups of machines I could add an end date but I can configure this however I want to so that's the time in which it's going to actually go and apply these the next part is then well who am I applying it to so this Dynamic scope is super useful if we think about what I want to do here these are the machines that are going to apply this schedule and the patches we're going to configure so with a dynamic scope it's not a fixed set of resources now there might be times I want that if it was the very specific machines that will always get them for the initial set of testing that might just be a set of resources and we can do that but I can have any number of dynamic Scopes and this could be based on hey the resource Group it's in it could be based on location IE region so that would be really useful for that production based roll out but I can also base it on tag so that would be useful if I have for example an environment tag and maybe it's test Maybe it's production and I could use that as part of this Dynamic scope now each Dynamic scope can have up to a thousand at time of recording um resources maximum as part of that so again we would jump in and I would just create a dynamic scope select the subscriptions again lots of different subscriptions it might use it's showing me a preview what would get included but this is just a preview at this moment in time this actual scope would be evaluated a couple of minutes before the patching actually applies it's not actually these resource this is an idea based on if it was running right now but it will get calculated a couple of minutes before the actual patch run each time it runs I can select the types of resources the locations particular os's maybe if this is Windows I would just say windows but then tags hey I could add a tag to say hey it's a certain environment and it has to equal test or it has to equal prod and then it has to be this location in prod so these filters are really powerful to really meet any scenario you can think of of those various combinations and I can then just add manual resources as well so in the scenario where hey uh I am maybe doing that initial test ring I don't have to use a dynamic scope so yes these are super super powerful but I can also just add in N number of resources now for any one particular schedule so the combined number is 3,000 Max now this may change over time but this is documented so if we look at the documentation it tells us the total resources for any one schedule is currently 3,000 and each individual Dynamic scope is up to a th000 so technically I could have three Dynamic scopes with a th000 each or I could have 20 Dynamic Scopes if they only returned for example like 100 resources each and then I could have a bunch of statically assigned resources so I have a number of options around that and then the next thing we're going to add is really just the types of updates so my my last option here is what are the updates so I can include and remove the type of updates I want so for Linux hey is it just secure in critical or others all the different types we have for Windows and I can include and exclude specific packages so specific ID specific packages I want to include as part of that then I would just go ahead and create it so that's all of the capability we think about when it comes to the actual schedule and so the final piece of this is just what are the updates so I have the type of updates oh that's not right the type of updates but then I can also remove add or remove particular KBS or packages so I have huge amounts of control um over what I want to do with this and that's obviously um the key Point around all of this now that was the schedule based option you will see there's also an on demand so if I let's say hey I've set up my schedules everything's great a critical update has come out I can do a onetime update maybe actually this is where it's the 100 machines at a time um there may be newer updates so I can install updates now I would add the machines that I wanted to actually go and patch or I could have selected them already and then what are the particular updates that I want to add so I can go and select those hey yeah I need to install these now and it will go and push those to the machine so we do have that on demand hey I I have to get these out basically right this second that also could be useful for for example maybe I've got a new VM that I've just created and I want to go and get the latest patches pushed into that straight away so I might also um consider that there now one of the things that that I will stress today there is no human approval element in this flow so I can't have it say hey here are these patches ready do you want to approve them no so I need to be very careful about that I really don't just have everything going at the same time time I really want to make sure I have this process in place that I have very controlled schedules to make sure I give myself enough time and I have the awareness and communication that people know hey in your Dev environment we've pushed these patches there some alerting goes out we can trigger off various types of activity log that will fire apis hey go and do your testing hopefully it's automated I could be using things like uh obviously there's Azure has testing capabilities there's devops pipelines there's things like chaos Studio to inject there's Azure load testing make sure I'm got these good capabilities as part of this to do this forward testing at each of those patch cycles and as I talked about you have the full reporting afterwards it has all those dashboards I can customize it to see what is going on now obviously say people always care about is um what's the pricing of this how am I paying for this so for the V2 if we think pricing if it's an Azure VM it's free so it's an Azure resource there it also applies I me if it's Azure stack HCI um Arc enabled it's free as well if it's Arc based not the HCI scenario and it's in US currency it's $5 per month but again I'm not paying for log analytics space or the interactions with that and we can double check the pricing so you'd want to go and look at the pricing to see your local um currency Etc oh that's not right page let's open up the pricing right there we go so $5 uh per month and it does say mention it PR rates it so if it's for a portion of the day it's saying here say 16 cents per server per day and that is how all of that patching is done the other thing I was going to show is just some of the things they're talking about that's um coming up so alerting but I'm excited about this pre and postcript so the ability to run scripts both before and after the patching that I think is really interesting you can imagine a scenario that maybe I have a gold image so pre hey go and start up a VM based on the gold image patch it post generalize it and then store a new version of that image back up to my gallery I can start to leverage that so I don't have to hey as soon as I create a new VM apply the patches it could help me maintain those uh gold images as well so I think that's a a really nice useful capability but that's the solution it it's completely re architected from the V1 it applies to both Azure and non- aure resources I do need to Arc enable that server operating system but that's a free capability windows and Linux and then I can configure these schedules to automatically roll out but again don't just think hey I'm going to patch everything day one it's really really important you get that good cycle and give yourself time to functionally test load test and then once you're satisfied with that then I can roll it out to the next environment even once you've done all your testing production it's a good idea to roll it out based on for example regions give myself at least 24 hours think safe deployment practices of your updates the same way you would stagger your own application changes you don't push an app change all at the same time I want to be doing the same thing here and I like the dynamic Scopes I think that's really useful way to help enforce this good process of environment by environment so as always I hope this was useful till next video take care

Channel: John Savill's Technical Training

Views: 28,023

Keywords: azure, azure cloud, microsoft azure, microsoft, cloud, patching, updates, azure update manager

Id: LVmNh5YgBOQ

Length: 32min 32sec (1952 seconds)

Published: Mon Oct 16 2023