All right, I'm ready to get started. So, hello, welcome. Today I'll be talking about managing your server updates with minimal administrative overhead.

My name is Zach Alexander. I'm a PM at Microsoft. I work on Azure Update Management, which is the feature we'll be discussing. You can find me on Twitter at MSFT Zackle. Just in case you wanna see the latest American chopper memes, I have you covered on that account. What else is Twitter for?

So, here's what we'll be covering today. I'll just talk about update management in general, some customer challenges with update management that I've heard, things that we've been targeting. We're gonna review the existing update management tools from Microsoft, so we'll talk about SCCM for a second. We'll talk about WSUS, how that fits into the ecosystem.

Then I'll go through Azure Update Management. We'll talk about what's available today. I have a couple demos for you, and we'll talk about pricing, that ever-important conversation. We'll go through the roadmap, some things that we are working on, some things that we are on our radar, but aren't necessarily getting worked on today.

Then we'll probably have about 15 minutes at the end for Q&A, so please leave your easy, simple questions for me towards the end. It's fine, you can ask me complicated questions. And then, if there's one thing that I want you to take away from this, it's that Azure today provides orchestrated update management across operating systems,

so Windows Analytics, and across any cloud, so Azure, other clouds, on-premise. So, you may have heard, security is important these days. This is a really brief, abbreviated timeline of just a couple of security incidents that have made the news.

As more companies move online, move more of their assets online, obviously, vulnerabilities become more and more important. These vulnerabilities can be patched, but the question is, are they getting patched? If you work for a company, it's your job to make sure that you're not getting hit by WannaCry, you're not getting hit by Meltdown or Spectre. You definitely don't want to be in the news,

but as it turns out, security is not the easiest thing in the world. So, when we were designing Azure Update Management, we went out, we talked to a whole bunch of IT professionals, talked to a whole bunch of consultants. We wanted to figure out what are the biggest pain points when managing updates across your environment.

And this is what they told us, and if you see something that you're hitting that's not on the list, definitely come talk to me afterwards. We'll make sure that your scenarios are covered as well. But for Windows, the biggest thing we hear here is there's inconsistent reliability. It's hard to manage multiple maintenance windows, and it's hard to deal with reboots in a Windows environment.

Orchestration is not the easiest thing. A lot of critical systems end up patched by hand with manual pre-steps, manual post-steps. Grouping based on workload is very difficult, and there's a need to consume existing groups instead of building new groups every time. Error handling and troubleshooting is extremely difficult,

especially when you're looking at some of the error messages that WUA emits. We need better targeting, we need better reporting, and we need better tracing of those errors. And update deployments rarely have zero downtime. And on the Linux side of things, because people are deploying more and more Linux servers these days, there's a lack of tooling for Linux

and managing those updates, and especially there's a lack of unified tools. If you have multiple Linux distros in your environment, those distros might all have different package managers. It's very hard to find a tool that will go across all those different package managers. Scheduling and orchestration is also pretty limited for Linux. Updates can break applications,

and you need error handling and troubleshooting to deal with those as well. There's a lack of control over what packages get applied, when they get applied, what components consume those. And it's very difficult to enforce compliance, and there's not a lot of reporting on that compliance. So these are the things that we kept in mind

as we started to design for Azure Update Management. And then there's also a bunch of attempts that have been made already by Microsoft to address the patching space. So I just wanna talk about how this all fits together. So obviously at the base of it is Microsoft Update. Microsoft Update is for Windows clients, Windows servers.

It's the core service. It's meant for direct update. It's not easy to get aggregation across that. And obviously it's not available for Linux. So Windows Server Update Services, WSUS, was the first attempt at trying to get that aggregation. Targets Windows clients and servers, lets you curate, improve,

proxy patches from Windows updates. There's still a manual process associated with that. It's possible to automate through PowerShell and GPO. There's SCCM, that well-loved application, we all know. And there's also Intune, which targets Windows clients and devices. So a majority of those SCCM customers are also using patching on those servers.

And again, there's manual steps. You can try and automate them. And it doesn't address Linux. There's some workload-specific stuff. So cluster-aware, update, and patching. It's really targeted at clusters for Windows Server 2012 and above.

And that's what allows you to start being cluster-aware. It lets you be able to drain nodes from your cluster, patch them, reboot them, add them back to the cluster when they're done. But that's something that is really specific for Windows clusters. SCCMM is targeted towards your hypervisors.

And there have been a couple of Azure VM extensions for Linux that try and address the Linux side of things. Those have been deprecated. And for cloud platform system, CPS, there have been attempts to do a zero downtime patch and update orchestration. But that's limited really strictly to CPS and hasn't made its way outside of CPS yet.

So when we look at this, the gaps that we see are mostly around Linux and then ability to kind of start automating these deployments at scale. So I'm here to talk to you about Azure Update Management. And this is just a really high-level architectural diagram of Azure Update Management.

You can see my mouse pointer here. We're a feature of automation and control. We live inside of Azure. We're able to talk to Azure VMs natively. And then we're also able to talk to other service providers. So if you have VMs in AWS or if you have things that are on premise, we have a hybrid worker. It goes onto your machines

and it reports back through Azure so that you're able to get a unified view of all your VMs regardless of whether they're on premise in AWS, in other clouds, or in Azure itself. And because we're in the cloud, we're able to offer things. We're reliable. We're highly available. We scale very well.

So what this lets you do is it lets you see the state of those machines that you have. You're able to assess whether they have the updates that they need. And you're actually able to schedule update deployments as well. So you're actually able to go in and tell these machines, hey, it's time to update, it's time to patch. We give that detailed reporting and compliance

across Windows and Linux. We handle domain, non-domain joined servers. We don't really care about your domain status. And we're using native Windows and Linux tools. We'll talk about what that means in a minute. But on our back end, we are using log analytics. That gives us rich search capabilities. So all the logs that you have from those updates,

they get stored in log analytics. You're able to search through them, build strong queries on top of them. And we do use leverage existing WSUS, AD, and log analytics saved searches. So you're able to take in some of the groups that you already have and deploy against them. We have flexible scheduling options.

So we're going to let you do one-time updates, weekly updates, monthly updates. We are able to bring in those logs and allow you to do advanced troubleshooting on them. We support proxy environments. So if you're an on-prem environment and you only have one path to the internet, we allow you to put a gateway on there

so that you're able to collect logs from the machines that are affected and bring them up into Azure. And we do respect WSUS and private repo configurations. So let's just talk about that part for a little bit. This is, again, a very generic, non-OS-specific way that we work. Basically, as a user, you schedule an update deployment

against Azure Update Management. We have an agent on the machine that checks for any jobs. When we see that we have a job, we go against the native update agent. So on Windows, that is the Windows update agent. We just invoke that. And on Linux, whatever the default package manager is, we go against that and we ask it to go

to whatever updates store it's configured against. So if you're using WSUS and you have it pointed towards a WSUS store, we respect that. If you're using Linux and you have a private repo configured, we respect that. We install the updates, and then we report that information,

the action we just took, we report that to the Azure update agent, which pushes that information back into the cloud so you're able to see it, analyze it. Actually, how many of you are running, have Linux in your environment? How many of you need to manage Linux machines? Okay. So I'm just gonna take a minute. This might be a little obvious,

but I just wanna talk about the Linux update lifecycle. There's actually some special processing that we do for Linux to bring in some advanced information. So for those who don't know, this is generally how the Linux update lifecycle works. You have a bug fix. It's committed into an open-source project. A vendor picks up those fixes,

it builds the package, and it publishes it to a repository. That repository is maintained by the vendor. And then out of the box, Linux servers will just go and talk to that repo through the native built-in tool, so yum apt-get whatever.

Updates are retrieved and installed, or you can actually configure a private mirror, similar to Wsus, where you just take in the updates that you want and you can configure your machines to go in and talk to that private repo. So those package repositories, those have updates about them, but sometimes vendors,

so there's two paths here, right? There's the package repository, and your machine goes in and gets that, but vendors will publish information out of band. They will have security built-in data. They publish that online. We will actually go in and download and normalize that data. We will cross-reference that against the update data

and give you additional security context so you're able to see, for example, what CVEs are linked to specific package updates on Linux. And that's all kept in automation control update management. And in terms of Linux versions, this is what we support today. We're always happy to support more.

If you don't see your distro here, I'm happy to talk and figure out what it would take to get it supported. But out of the box, we support Red Hat, SUSE, Ubuntu, CentOS, and Amazon Linux. And again, we're always looking to add more distros that we support.

So I'm gonna start off with a demo of the portal just to kind of show you what the UX looks like, how to start onboarding stuff into here. Do I need to make this a little larger? I think so. So this is my Azure dashboard. And actually, I have a machine here

that is not enrolled in update management. This is just an Azure VM. And I can go into this VM. In the table of contents here, you'll see update management. And this is, it's checking the status of my machine. It sees it's not enrolled. If I wanted to enable this, all I have to do is press enable.

On the back end, what we're doing is we're looking for a log analytics workspace in an automation account. If you have that stuff already set up and configured in your environment, which I do, you can just go in and choose wherever you're configured. Otherwise, we use a reasonable set of defaults. All you have to do is click enable. And it'll take a little bit for the agent to get deployed.

Yes, sir. Right now, we support, so the question is, what if the VM is in another subscription or resource group? Resource group is fine. You're able to pull in from the same resource group, or from different resource groups. For subscriptions, we have a script

that I can link to at the end of this that will help you onboard VMs from different subscriptions into the same workspace. We support it, just not through the UX at this time. So, we can see that this is being enabled on my machine. It takes a little bit for us to get the agent on there. It takes a little bit past there to actually get the data

to come up into our automation account. So, I'll let that bake for a minute. In the meantime, I'll go into our automation account, and I have update management right here. And we can see update management is part of my automation account. And this is gonna give me information about my environment.

And we can see, I actually have a whole bunch of red here. Apparently, Patch Tuesday happened when I wasn't paying attention, and all my machines are out of compliance. So, we define compliance as missing critical or security updates, and all my machines are missing at least one. And we can just take a look here and see, oh, I have an Azure Linux machine.

This is actually an EC2 machine, so I have a VM running in AWS, and I have that reporting into Azure. And then I have a couple more Azure Windows machines and another Azure Linux machine. So, we can see, hey, my Windows machines are all missing one critical, one security update.

I can drill into that if I want. So, I can drill into this EC2 machine and see what updates are missing. This is gonna go into Log Analytics. This is gonna give me a Log Analytics query. And it's gonna tell me what those updates are. So, we can see, okay, I have a definition update. That's fine.

But I also have, there's a cumulative update that came out. There's a malicious software removal tool. And there's another update that seems to have a critical impact. But let me show you for Ubuntu, we're gonna actually go in and provide some additional data. This is my Ubuntu machine, and it's missing a whole bunch of stuff, actually.

And if I go in over here, we're able to see, let's see here. We can see I have a security update. And we can actually go over here. We'll see the package severity. So, we can see this is a moderately important update. And we have a URL that will actually tell us more information.

So, we can go after that URL. We also pull in the CVE numbers for this update. So, we can see this actually has a couple of CVEs. That looks bad. And if I go into missing updates, I can just see all the updates that are missing across my environment. I can filter it if needed. So, I can just say, hey, I wanna see

if the latest cumulative update is missing in my environment. But for those Linux machines, for Windows, we point out to the KB that explains what this patch address is. And for Linux, we actually point out to, in this case, the Red Hat security advisory. It gives us URL, super easy access to see what exactly this one is.

So, this is a Emacs security update that is important. And that's the data enhancement that we do in update management. All right, so I have a bunch of non-compliant machines. I want to rectify that, so I'm going to schedule an update deployment. And we'll just call this demo deployment.

Let's target that Ubuntu machine. It makes me a little nervous. So, from here, when I click machines to update, this is gonna show me all my saved searches from log analytics. You can see I've created a couple. If I had AD, WSUS, SCCM groups,

they got pulled in as well. I'm able to target those. But we know that there's just a handful of machines I actually want to target. I'm just gonna choose individual machines for the minute. So, we'll select my two Ubuntu machines. We do update classifications. So, there are a whole bunch of updates that are missing from those Ubuntu machines.

I may or may not want to install all of those. If I really just want to address the security impact updates, then I could just choose those. In this case, everything should be updated. But let's say I have a production workload that's dependent on Python. I do not want Python to get updated without me knowing about it,

without explicit testing on my part. So, for the minute, I'm actually gonna go in and exclude Python and make sure no Python updates come down. That way, I know that my production workloads are gonna continue working. So, I configured a package exclusion there. For Windows, we'll allow you to do KB exclusion.

So, if you know for a fact that, hey, this specific KB has been causing problems in my environment, I want to keep it out of the deployment for now. You can also put in a KB number on Windows. Right now, this is per deployment. And then, this is where the powerful stuff really comes in. I could just do this as a one-time update,

but as we saw, my machines are all out of compliance. I wanna not have to come in and do this every week. So, we can actually choose a recurring update. And if I know that, for example, the third Sunday of every month is when we schedule our downtime, we're okay not having our machines online during that time

I'm actually able to come in and say, okay, once a month I want to have every third Sunday, I wanna have my downtime. That's the time I'm going to reserve for updates to get installed.

So, I have that flexibility. I could also do the last day of every month. I could do the first of every month, anything like that. This is my schedule, every third Sunday. And then, we define a maintenance window. So, a maintenance window basically says, this is how long I want you to stay installing updates. We reserve a couple minutes, 20 minutes at the end

for reboots, if necessary. And we will install updates until it looks like we're hitting that threshold of 20 minutes left in the maintenance window. Then, we will not install any more updates and allow the machine time to reboot and finish installing those updates.

So, that way you have some reassurance that the machine is not going to be installing updates for, say, six hours. And so, I have two hours to find right now. That's fine, I'm gonna create this. So, I'm gonna go into scheduled update deployments. And we can see here, here's my demo deployment. It's provisioning right now.

It's targeted at two machines. And if I refresh this, it'll probably come back up as deployed, there we go. So, next runtime is gonna be 4.15. Wow, I think we've already hit the third Sunday of this month on 4.15. And that's when we know we're gonna hit it.

So, let's fast forward a bit. Let's assume that the deployment happened already and we wanna see what actually occurred. So, we can go into update deployments. And we see here, demo success. So, let's assume that installed updates and everything worked as it should have. We're able to go in and see what machines were impacted

as well as what updates were actually installed. As soon as that decides to load, there we go. So, we can see across the entire deployment what updates were installed. We can drill in per machine and see, okay, here are the updates that were installed on this machine. We can see it was a pretty successful deployment. And then what we'll do is we actually monitor

the output of that job and we pull that back up into Azure. So, if I wanted to, I could go into all logs here and we'll see a whole bunch of information about what's been going on. And I'm able to actually see, I don't know if this is gonna be the most relevant piece of output. All right. But we're able to see logs from the sheen get pulled in.

And you can see, okay, we're refreshing local repo. We can see the exact command that we are running to get that data from the machine. And we can see, okay, this is why these updates got selected. As well as be able to go in, click in, see, okay, here's the updates that were installed, any errors that occurred with those updates.

So, that's the UX. But I know that not everyone comes here for the UX. So, I'll show you some of our APIs. We have some rest APIs that are published today. We're working on the cmdlets. I gambled on the cmdlets being available and I did not win. So, my samples are actually written in C sharp

but it's .net. You can easily convert that into PowerShell. When the cmdlets come out, which we're targeting for next month, you'll be able to run this stuff as cmdlets. Let me just show you the power of our SDK and what you're able to do. So, up here what I have is just the packages

that we're using, build dependencies on this. And I've configured some information in my backend. I have a service principle that I've configured. It has some secrets. I'm storing that in the backend. And I'm gonna create a credentials object that has that information.

And then with that, I'm going to create an automation client. So, the automation client's going to get my subscription ID and then the resource group that my automation account's in as well as the name of my automation account. So, from there I'm going to create a software update configuration list result.

So, I'm going to be querying for software update configurations. That is the deployment that we have. Here I just have a list of my VM resources. We can see these VMs that we were just looking at. We have our front end server, Ubuntu test. This machine with no schedule, I don't know what that's doing there.

But I've manually created this list. You can easily imagine just querying Azure for all the VMs in your subscription. And what I'm gonna do is I'm actually gonna go in and query each of these machines and see if it has an update schedule attached to it at this time. I wanna make sure that all of my machines are receiving updates on a regular basis. If there's a machine in my environment

that's not receiving those updates, I wanna know about it. So, I'm just gonna iterate through all of the VMs in my list. And I'm gonna call list by Azure virtual machine name. So, I'm going to list all the configurations that are associated with each Azure VM. And if it doesn't exist or the list comes back empty,

I'll add it to my list. So, let's run this real quick and see what machines I have that do not have an update deployment configured with them. Let me just scroll up for a minute and see. So, actually we can see there's one item and mysteriously this VM called no schedule does not have a scheduled update deployment

due to how I set up my demo environment. So, okay, great. I can see that there's one machine in my environment and it is not going to receive updates anytime soon. So, I'm able to use another API of ours to actually go in and correct that. So, this is the same setup. I have my automation client.

It's gonna target the same automation account. We're gonna have scheduled properties. We're gonna say, okay, let's create a one-time deployment. We'll do it 10 minutes from now. And we're gonna create, this is a Windows machine. So, we're gonna create a Windows update configuration. And we're gonna just target it for critical and security updates.

If we had any KBs that we knew we didn't want in there, we could exclude those KBs specifically. And we're gonna target my no schedule VM. Although, again, you can imagine just taking in the output of the previous script, plugging it in here, and having all your machines that don't have an update currently scheduled go into this.

And then we're gonna actually go in and create a new software update configuration with that configuration information and that schedule information. And we're gonna call it test software update configuration and we're gonna give it a unique name through GUID. So, let's see if this one works. Oh, that didn't scroll.

All right, so, it's provisioning and it's definitely gonna work. Ah, it worked. And hopefully, if we go in and run this script again, our machine's not gonna show up on the list. Yep, and we can see, okay, now we have no machines

that are not going to get updated. All of our machines have an update configuration associated with them. We're reasonably sure that our machines are gonna be up to date. So, let's step back for a second again. Okay, I created that update deployment. It's gonna fire 10 minutes from now. That's not gonna happen anytime soon.

So, let's just query for another configuration that we know works. Let's look at our demo success update configuration again. So, we're gonna just run, we're gonna get by name, demo success, and that should give us some information about this update configuration that is created.

Okay, so we can see, yep, we have an update configuration called demo success. It was successfully created. It was a one-time schedule and it fired. It looks like its next run is not gonna happen,

but it started previously on 4-6 at 7 p.m. And we can see the machines that it was targeting there. And that's fine. I know this configuration worked, but I wanna see what the actual, I wanna see what happened last time it ran. So now, instead of getting the software update configuration,

I'm gonna get the software update configuration run. So, we're gonna query for list all the runs for that configuration. And again, we're gonna query for demo success. Boy. And I did not create the name demo success in there.

Hmm. Weird. Okay. Oh, I just had, I highlighted the wrong thing. Okay. Great. That's why I use VS Code. That's why I prefer VS Code. I would've used it if I had PowerShell commandments, but. So we're able to see, okay, yep, we had that configuration.

It started at 4-6, it started at 7 p.m., and we got a status of succeeded. So we're able to query the state of our last update run and actually see, yep, it worked. All the updates we expected actually got installed. So, just to review what update deployment covers,

we allow you to choose what updates to install. We let you do approvals via update classifications and exclusions of packages. We let you choose when to install, so we have flexible scheduling options that go from once, daily, monthly, weekly, hourly, whatever you need. You can target computers based on a single computer

or you could use existing groups. So you're able to use your saved search, you're able to use WSUS groups, you're able to use AD groups or SCCM groups. We do have integration with configuration manager to pull in some of those groups. And then for OS support, we support Windows Server 2012 and above, as well as Linux. We support Red Hat, Ubuntu, SUSE, CentOS, Amazon Linux.

And we use the native agents on those machines. So we use Windows Update Agent or Linux repositories for update configuration. And we use Log Analytics and the automation platform to get all that to work. So, with all that in mind,

I've shown you a bunch of awesome, excellent functionality. I know the question on everyone's mind. How much is this gonna cost me? And I regret to tell you, oh, actually no, nevermind. It's included as part of your Azure subscription. This is, all you pay for is the logs to get set up with Log Analytics. Our goal is to make Azure

the best and easiest platform to manage. This is part of that goal. So when you have an Azure subscription, update management is totally included for Azure VMs and for on-premise VMs as well. So you have no excuse not to use this, is what I'm telling you. And then from a backlog, I show you some stuff, but there's some gaps,

especially based on what we talked about in the beginning, addressing some of the complaints people have with update management in general. So we wanna have richer update inclusion rules. If you have just one update that you wanna deploy, if a critical patch comes out and that's the only patch you wanna send out to your environment, or if you wanna just stage patches first

and once they're known good, deploy them to the rest of your environment, we're working on update inclusion. We're working on reboot control so that you can say, hey, don't reboot these machines right now. I wanna schedule another run where rebooting is okay. And obviously commandlets we are working on, we want to deliver PowerShell commandlets for update management

so you can start automating all this stuff. After that, we wanna have some richer support for groups. Right now we're only evaluating group membership once and we want to be able to, when you have new members added to the group, we want that to be reflected in your update deployments without any work on your part. And then we wanna start working on update orchestration

via pre-post scripts. So being able to allow you to deploy a pre-script that says let me get ready for this update run, let me shut down my services, let me make sure everything's good. And then a post script that says let me make sure that I'm coming back online okay, let me run any checks that I have. And then our backlog is, this is not ordered,

but this is just a list of things that are kind of on our radar, things that people have asked for and asked that we are aware of. So right now, approvals and management, we can have a richer story there. We do integrate with WSUS, we have an existing WSUS server, we will respect all that approval workflows,

but what I hear is people wanna get away from maintaining WSUS servers all the time, I understand that. We wanna start giving some better information about the reliability of patch installation. We have access to some telemetry that we'd like to surface to you. Hey, these patches are more or less likely to succeed. We can support pre-checks to make sure

that those patches are definitely gonna work. So for example, querying for available disk space, make sure that the patch isn't gonna fail because you didn't have enough room on your hard drive. Orchestration is something that we wanna continue improving, making sure that we have really rich experience around that orchestration.

Patching third party products is something that we get asked for a lot, we're aware of it, we would love to in the future provide that, and we're aware of the ask, and then better integration with your IT service manager products. Right now, because we're based on top of Log Analytics, you are able to build a Log Analytics query and generate some alerts off of that, but we can always improve in that area.

So, before I open the floor for questions, I just wanna reiterate, the key takeaway here is Azure provides a free orchestrated update management service across any OS, Windows and Linux, and any cloud, Azure, AWS, other clouds, and on-premises.

So, with that said, does anyone have any questions? Yes, sir. No, so the question is, how does the integration with AWS work? It's the same as on-premise, you just deploy our agent, and our agent will just report normally,

so there's not an integrated tool within AWS that allows you to do it, but we have an agent, you just deploy it via command line, however you want, and we'll start reporting data in. You still need to configure firewall rules and all that stuff, but we will consume data from AWS agents. Way in back.

What was the minimum version of Windows? Did you have plans for any other versions? Right now, our minimum version that I put up there was Windows Server 2012. We require WMF5, so if you have 2008 R2, and you install WMF5, that will work.

I think, yes. How do you handle content charges, like DC customers maybe putting a WSUS instance or something up in Azure so that they don't have to pay for Windows Update at that point? Right now, customers are just using Windows Update. It's a good question about the bandwidth,

the ingress or egress. I have to look into that, actually. Hasn't come up yet. Yes, sir. I'm auditing remediation, so after I've run through this, my manager wants to know, or my security manager wants to know, okay, what patches did you put up? Which ones were there? Which ones are missing? If you didn't install this patch, why?

Yeah. We put most of that data into Log Analytics. You are able to say, hey, for this update run, here are the patches that I put on. Here are the patches that didn't install. There's one other point that you had in there that I think I didn't cover. Remediation, which ones were missed, and what do I do about it? Yeah, so the remediation story would be through errors.

It sounds like we could improve there, so I'd be happy to talk to you afterwards about what specific reports you need and how we can make it easier to generate those reports. Yeah, the other question is if I can get the report automatically generated in email to me so I don't have to deal with it. Yeah, I think that Log Analytics lets you do something with that. We'll follow up on that.

I think you had your hand up, yeah. So have you put Amazon Linux 2 on your roadmap yet? Amazon Linux 2? The update to Amazon Linux. Oh, man. I just heard about it, so no. But I'll talk to the agent team. It's still fairly in pre-release.

I think they just dropped it not too long ago, but there are some significant changes because that's their move to system D. Okay, great. I will follow up with our agent team. Yes, sir. So right now we don't handle anything except for core OS updates,

but we are looking at what it would take to handle, for example, Microsoft updates that are coming through. Yeah. So is there a way to exclude patches by other than like name? Like say I want everything that's older than 30 days. Oh, not yet, but that is one of the requests

that we hear. So are you looking to not report on compliance older than 30 days or you want to say during this update deployment don't install patches that are less than 30 days old? Okay, we don't have that yet, but we hear it. Yes, sir. If I wanna use this strictly for on-premises machines

and I have zero Azure today, what is the minimum amount of Azure I need to use it? You will need an Azure account. You'll need a credit card linked to that account because that's part of creating an Azure account. You'll need an automation account. Well, we'll create for you an automation account and a log analytics workspace.

The only potential charge is for the logs that get sent up. So you pay for logs that get sent up. You get 500 megabytes free and after that it's on the order of like two cents per gigabyte for log analytics. There's an agent on each box or there's some on-premises? There's an agent on each box, yeah.

And we have instructions about how to deploy it, how to deploy it silently, all that stuff. Yes, sir. We're talking about kind of the bandwidth and I guess the agent. Is there any plans or is there currently functionality? For instance, if I have an agent deployed in this site and there are 20 other agents in this site that are also managed by the same agent

that it would then distribute the patches locally or use those to kind of do peer-to-peer or does everything have to come back for all agents? So questions about I have multiple agents on the same site, is there like a proxy service for downloading updates or peer-to-peer?

So we just rely on native Windows Update agent functionality. If you have SCCM set up and configured already, we should respect those settings but we don't have plans to go in and do the agent peer-to-peer stuff. So you guys aren't, there's no plan to replace SCCM or update management with this? Not like the download peering stuff.

Any other questions? Yes, sir. If you need an agent on all of your on-premise stuff, what's the point of the hybrid worker as well? Great question. The hybrid worker is part of the agent, I believe. You have to get some, I have to follow up with you

because I've been ignoring the hybrid worker. I'm not quite sure. I think it's part of the agent, I'm not sure. But yeah, we have, I don't know. Yeah, way in back.

It's on the order of months. It's a top request from our customers. We're taking it super seriously. So, yeah. Yes, sir. Regarding the hybrid worker, I actually think that the agent is making the server question

to have a hybrid worker. Yeah, I think you're right. It's a system hybrid worker, not a runtime hybrid worker. So the hybrid worker against the machine,

as you may also see through Azure Automation, we have another, we call it the DIY hybrid worker to allow you to run partial scripts against the machine. So essentially, we utilize that functionality in our order to run our partial scripts that triggers patches. So, to summarize, and thank you so much, Jenny.

Thank you for saving my skin here. To summarize. The patches need to be installed, but it's the hybrid worker that actually runs the patches and actually triggers the scripts, runs the scripts and installs the patches. So the instructions come from the management

to the hybrid worker and then zap on the machine. Thank you, Jenny. All right, every update management machine is a hybrid worker.

Thank you so much. It's a little complicated. That's my excuse. All right, any other questions? Not about hybrid worker. Yes, sir. Does meeting OS include client OSes?

We run on client OS. It's not officially supported, but we're talking about it. So, I mean, we just depend on WUA being present, and WUA is present. So it works if you, we're just still discussing how supported it is.

Any other questions? Yes, sir. I'm assuming you're supporting where that is also time to satellite as well. Probably. We have kind of a, we don't whitelist machines, so you can definitely try it out and see what happens.

And if it doesn't work, let us know. Anything else? All right. I think I'm three minutes ahead, so. Thank you so much for attending. Please submit a session rating. I get evaluated on those.

Make sure that we're providing quality content. That's all I got. I'll be hanging around for a couple minutes next door in case anyone has any other questions. Thank you. Thank you.