 Hey everybody, stay tuned for this Azure Unblogged episode where I'm talking to Vijay from the Azure Update Management team. He talks about the product and how you can use it within your environment to patch your Windows and Linux machines, and also share some insights into how you can do that third-party patching as well. Lastly, he actually mentions the private preview that is running within the product, so stay tuned for all of that. Welcome to today's episode of Azure Unblogged. My name is Sarah and I'm joined by Vijay from the Azure Update team. Welcome to the show, Vijay. Thank you, Sarah. Thank you, everyone. Hi, I'm the PM for the OS Update Management Service in Azure, also popularly known as the Azure Update Management Service. It's a pleasure to be here. Awesome. Now, I've been using Azure Update Management for a while now, both at my home lab and for customers, but for those that aren't familiar with the product, could you give them a quick overview as to what it is please? Okay. First things first, Update Management is a wrapper for the operating systems update service or package manager, and it's a wrapper that allows you to control it from the Cloud, and tell it when to execute updates and how you want to do it. There's a nice documentation that we have there which illustrates the same. The nuts and bolts of it is that it's built on the Azure Update Management and Log Analytics solution. As you can see from the diagram in the documentation. What happens is from the Cloud, when you write a job or ask for Update Management to start patching the machines that you would want, we essentially look at the automations, Hydra Runbook worker on that machine to start executing a script, to start getting the package manager, let's say, YAM, or Reciper, or the Windows Update Service, if you're using Windows Server, to start executing those updates that you had wanted, and we do additional checks like ensuring reports don't happen and things happen in the time we do that you wanted, and does not perpetuate for infinity and beyond. Additionally, you can also ask us to do some pre and post jobs. For example, if you have a set process by which you want to gracefully bring down your application, and then patch the machine and then bring it up again, we can do all of those things. Finally, the store in this case is the Log Analytics. All the information that we generate on the logs is stored there, and you can use the power of Custo and Log Analytics to slice and dice, and build your own custom dashboards, queries, reports, and alerting, and all of that goodness that comes from Azure Monitor. Awesome. Now, thinking about a customer's journey into Azure, where does the Update Management solution fit? Is it a replacement for their existing patch management solution, or is it something they use in conjunction with what they've already got? Okay. That's a good question, Sarah. So Update Management solution, much like everything else that is built in Azure is built for the hybrid Cloud. We don't think of on-prem and Cloud as variance, it's everything mostly in Azure is built for the hybrid world. If a customer is looking for a Cloud-based mechanism to do patch control, they can start off with that on-prem assets, and as they move to the Cloud, the Update Management solution can continue that journey with them. As such as when you're asking as a replacement for the current solution, one thing to understand is that Update Management is a free solution, like free as it be, right? Except for the part for the log storage which goes to log analytics, but more or less it's free. Hence, it's a no-frills product. So it meets the most common scenarios and needs. So based upon if you have certain complex needs, they may be out of the ballpark of the solution itself. But Azure and Microsoft has a buffet kind of a part mentality when we build our services and products. So why Update Management on its own may not do everything. We have supplementary services like configuration management and automation and policy, which supplement and help string together the same functionality that you may find in other commercial offerings in the same space. A good example could be WSAS or the Windows Server Update Service, which can be leveraged alongside Update Management to do things like baselining, update caching, and even pushing third-party updates to your machines. So while Update Management on its own cannot do it, we rely on the, you know, we work on the capabilities of other services in Azure and Microsoft so that you have the choice to pick and choose what you want and how you want to do it. So you actually mentioned third-party updates there, VJ. Now, obviously Windows and Linux patching is a big part of any customer's kind of environment, and so is that third-party Update Management. Where does Azure Update Management actually sit? Can it help deploy these third-party updates for you? So like I alluded to earlier, Update Management does not try to reinvent the wheel. It instead is a wrapper for the operating system and its capabilities as in the package manager or update service. On the lining side, things are a bit more upfront because the package managers can pick up third-party applications to install and update if you hook them up to the right repository. So if you configure, let's say, to a repository hosting, just for example, the open-office repository, hook them up to considering it as a third-party application or Oracle Repository, you can pick up updates for the Oracle GV and Update Management will show the same and allow you to install the same as well. When it comes to Windows, it's a little more catchy because Windows servers use the Microsoft or Windows Update service and the Windows Update service can fetch and install, apart from those updates, updates for the Microsoft applications. So out of the box, this is this restriction, but there are open-source ways by which you can push third-party applications, let's say, like an Adobe Reader or a Java Update through the pipeline such that it is consumed by Windows Update service. So I thought of the link of an open-source tool called WSS Package Manager, which essentially takes any third-party application update packages as a WSS update and through the WSS pipeline pushes it to your Windows Update. And therefore, if that is connected to Azure Update Management, then you will see those updates and you can apply those third-party application updates through Update Management. That's pretty cool. I didn't realize that open-source project was there, so I'll need to have a look at that VGA, so thank you for pointing that out. I think you alluded to it earlier on when you were explaining what Update Management is within Azure, but something people always ask me about and can't quite believe when I tell them the answer is the cost of implementing Azure Update Management. Could you take us through what it actually means when you're implementing that in your environment? Yeah, that's a secret sauce because, like I said, Update Management is free, free as in beer. No matter how many times you ask the solution to set up schedules to update your machines or how many machines you choose to update using Update Management, we don't charge you a cent or the penny, more details on the link that I've provided. But Update Management as a solution has to store its data somewhere, right? For it to be in person, for us to be able to give you reports of what went right, what went wrong, what we installed and what we didn't install, et cetera. And that store is currently Azure Monitor Logs, also known as Log Analytics. The Log Analytics service has a free tier of up to five GB or with a retention of 30 days or one month. Exceeding that limit is where you have to pay the Log Analytics, more details on the Azure Monitor pricing page. So on average, if you see, we see that a machine connected Update Management generates from 25 megabytes of logs. So given the five GB free tier, most small and medium users should not see any charge coming out of Update Management because the jobs are not charged and the data possibly falls under the free tier. It's only for the larger customers or with customers who have a necessity to store the data for a long period of time, let's say for audit purposes or other legal purposes. That's where some incremental charge might come into play. But else it's all free. Yep, I've got a home lab, a home server here and I love running Azure Update Management within that free tier because it saves me from having to apply all those patches, VGA myself. Talking about where the future is for Azure Update Management, is there anything you can tell us about roadmap features or any insider information that you're able to share at all? Yeah, this is where it becomes tricky as the legal team has their eyes and vigilance on us. But if you've been following Update Management, we have been tirelessly working to expand the service to all popular regions of Azure Cloud recently. So in the first few months, we have brought out to most of the more popular regions that have been asked by customers and other folks like North Europe, Central Europe, Central East Asia, Transcentral and more, Azure China and more. And we continue to expand and bring it to more popular regions and hubs as we go forward in this year. Secondly, the other big ask that we saw was on the operating system for it, right? New operating system scheme coming out. Hey, does Update Management work? Is it validated and verified for those? So we just have done the verification and now officially support things like Red Hat 8, CENT 8, SUSE Linux Enterprise Server 15 and so forth. And in the pipeline, we'll add support for things like Ubuntu 20.4, LTS and Oracle Linux as well. And the last and more interesting part is we have in, this is the insider part where I have to tread carefully, is we have in private preview something called Azure Update Center. That's the current naming that we use. It is essentially the same, almost same as Update Management, but decoupled from log analytics and automation. So whatever grievances or whatever issues that people might have had with the solution because of its coupling with log analytics and automation kind of go away. So onboarding is basically non-existent now. So it's like a native operation for your Azure, Azure compute machine or an ARC machine. If you have installed an ARC agent on your on-prem machine, you have just not need to do anything more. You can just go and start doing a patching for the same. Similarly, if you have an Azure machine, basically you don't need to do anything more, just go and patch it directly. And of course, because it's like a native operation you in, it gives you the power of Azure RBAC to create those custom roles and control if you're in a mixed environment, right? You have multiple people touching the systems and you want to deviate who gets to do these kinds of operations which may be destructive in nature like causing updates and reboots. So all of those things are possible now. You can sign up for the preview at the link we have provided. Once you fill in the details, we'll mail you the doc which tells you how to onboard your subscription, the features that are entailed and how to use the preview. That's all I think I can tell in the preview of legal linearity. But yeah, we're happy to have people try it out and give us feedback and take it forward. Awesome, that sounds very interesting. I might try and sign up for that private preview myself, Vijay, to see what it looks like. Thank you so much for joining me today. It's been a pleasure talking to you and kind of working my way through the Azure Update Management questions that a lot of people come across. Thank you. Thank you, Sarah. Thank you everyone for joining in. So again, thank you. And we will be sharing the links that Vijay mentioned in the description box below. So make sure you check them out as well.