Azure Update Manager - Simply Explained

It's patch night. Dozens of servers need updates, but the work is scattered across different tools, different teams, and different lists that nobody fully owns. One server misses a security update. Maybe it's still running an old version. Maybe the update failed. Maybe somebody thought another team handled it. Either way, that one missed machine can turn a routine maintenance task into a real security problem. Welcome to another episode of Microsoft Knowledge Nuggets here on M365. FM, I'm Mirko Peters, and today we're talking about Azure Update Manager. What exactly is it? Is it just a button that tells Windows to update? Or is it something much bigger? By the end of this episode, you'll understand how Azure Update Manager helps you see missing updates, plan patching at the right time, install them across your servers, and check what actually happened afterward. We'll also clear up what changed from the older Azure Automation Update Management setup. Patching sounds boring until it goes wrong. Updates often fix security gaps. They can fix bugs that cause crashes or strange behavior. Some updates need a restart, and that restart has to happen when the people using the servers won't get caught by surprise. Then there's the question every IT team eventually gets asked, did the patching finish? Not, did we start it? Did it finish? Which machines failed and which server still needs attention? Think of your servers like rooms in a large office building. Each room has its own equipment. Some rooms run email, some run a business app, some hold files or databases. Updates are the repair work inside those rooms, and patch night needs one clear maintenance board that shows what work is waiting, who is responsible when repairs happen, and whether the work past inspection. Without that board, people leave notes in different places. Before Azure Update Manager, Azure Patching could involve Azure Automation Update Management, an automation account, and a log analytics workspace. Those services could do useful work, but you needed to connect several moving parts before you could run and report on patching. Azure Update Manager brings that patching work into one Azure native service. So let's start with the first building block, the machines you need to manage. One place to see every machine. Azure Update Manager is a service that checks, schedules, installs, and tracks operating system updates for your servers. That's the simple definition. It isn't there to manage every piece of software on every computer. Its job focuses on the operating system updates that keep Windows and Linux servers current, and it gives you one place to manage that work. Why does that matter? Because patching gets messy when your servers live in more than one place, you might have Azure Virtual Machines running an app. You might have another group of servers in your own server room. You may even have machines running in another cloud provider. If each group uses its own patching screen and its own reporting method, you spend time chasing answers instead of fixing the machines that need work. Azure Update Manager can manage Azure Virtual Machines running Windows or Linux. It can also work with virtual machine scale sets. A scale set is a group of similar virtual machines that Azure can add or remove as demand changes. So you don't want each machine treated like a separate mystery. You need a consistent way to see and manage updates across that group. But what about servers outside Azure? That's where Azure Arc comes in. Azure Arc connects an on-premises server or a server in another cloud to Azure for management. Think of it like a remote office, getting added to the same building directory as the main office. The remote office still sits in another location. Its rooms don't move into the main building, but the front desk can now see the office, recognize it, and include it in the same maintenance plan. Once a server connects through Azure Arc, Azure Update Manager can include it in the same patching view as your Azure Virtual Machines. This changes the daily experience. Instead of opening one tool for Azure, another tool for your server room, and perhaps a separate report for another cloud, you can look at a central dashboard. You can see machines with missing updates, their patch status, the history of update runs, and a view of which machines meet your patch rules and which ones don't. That central view doesn't remove the need for people to own their servers. It makes ownership clearer. When a machine appears with a failed update, you can see it in the same places the rest of the fleet. The right team can follow up faster because they aren't first trying to work out which system holds the answer. Imagine a company with 20 Azure Virtual Machines and 10 physical servers in its own server room. The Azure Machines run a customer website and some internal services. The on-premises servers run an older finance application that the company still needs. In the past, the cloud team might check Azure patching in one place while the local infrastructure team checks the server room through another tool. Now, the on-premises servers connect through Azure Arc. Azure Update Manager can show both sets of machines in one patch view. The company can see where updates are missing, what ran recently, and which machines need somebody to investigate. The machines remain in different locations but the patching picture stops being scattered. That's a much better starting point than guessing. Still, seeing a list of machines isn't enough. Before you install anything, you need a current checklist of what every machine actually needs. Assessment finds what needs attention. Before a technician starts repairs, they check the problem first. Server patching works the same way, but you don't want to send updates to a machine blindly then hope the right fix is installed and the wrong changes didn't cause trouble. First, you need to know what that machine is missing, what kind of updates those are and whether the machine has already reported a problem. That check is called an assessment. So here's the simple definition. Azure Update Manager can assess your machines and build a current picture of pending operating system updates. For most managed machines, it runs an automatic assessment every 24 hours. Why does that daily check matter? Because the update picture changes, a server that looked current yesterday might have new updates available today. Another machine may have installed some updates through a planned process and no longer need attention. Assessment keeps the list moving with the machines, instead of leaving you with a spreadsheet that was only accurate when someone last edited it. For Windows servers, the assessment looks for operating system updates that apply to that machine. For Linux servers, it checks the available package updates from the machines configured update sources. The operating systems work differently behind the scenes, but the question you need answered stays simple. What updates does this server still need? Not every update carries the same urgency. Security updates fix known security issues. Critical updates address serious problems that can affect the system. Think of those as repair tickets marked urgent. You usually want to spot them quickly because leaving them open can create risk but other updates need more thought. They can bring broader changes like new features or changes to a component your application depends on. That doesn't mean you should ignore them. It means your team should separate urgent security work from updates that need a longer test cycle. Now, Azure Update Manager gives you a compliance view for this you can look across your machines and find the servers missing security or critical updates. You can also see the result of past update work, including successful runs and failures. Instead of asking every server owner for an answer, you have a shared place to begin the conversation. But don't treat a dashboard number like a final verdict. The information is close to real time, yet it can take time for the portal to refresh after an assessment or installation. If you're responding to a serious security issue, confirm the machine's actual state before you close the incident. Check the update result. Check whether a restart is still waiting, check that the servers came back as expected. Imagine you manage 100 servers. The compliance view shows that 92 have the security updates you expected. 8 still need attention. A percentage on the screen might look reassuring but those 8 machines are where the work begins. Maybe one failed because it couldn't reach its update source. Another might need a restart before it reports the final result. And a third could have an update that doesn't apply after all, or it may run an application that needs a closer check before anything changes. The dashboard helps you find the 8 machines. It doesn't remove the need to investigate why each one appears there. That's the difference between reporting and managing. Assessment tells you what needs work and where to look first. After that, you need to decide when those machines receive updates, which updates you allow, and what happens if a restart is required. Maintenance Windows put you in control. Knowing which updates are waiting is only half the job. The next question is when you can safely do the work. A maintenance window is booked repair time for a server. It tells Azure Update Manager when updates can install and when a restart can happen if that restart is part of the job. That matters because a server doesn't know your business calendar. If you let updates happen at random, a restart could interrupt people in the middle of work, stop an application during a busy period, or break a process that needs someone nearby to check it. A maintenance window puts a clear boundary around that risk. You can create a one time patching job when an urgent fix needs attention now. Maybe a security issue affects a small group of internet facing servers. You don't need to wait for the next monthly cycle. You choose the machines, choose the updates, set a window and run the patch job when the service owner is agree it's safe. For normal operations, you can create recurring schedules. That might mean a monthly window after Microsoft releases its regular Windows updates. The schedule repeats, so your team doesn't need to rebuild the same patch plan every month. You still review it of course, but the basic routine is already there. Inside that schedule, you choose which kinds of updates are allowed. Many teams start with security updates and critical updates because those usually deal with the most immediate risks. You can also allow other update types when your testing process supports them. The point isn't to select everything because it's available. The point is to decide what belongs in each patch cycle. Reboots need the same kind of decision. Some updates don't finish until the server restarts. For lower risk systems, you may allow a restart if it's required. As long as it happens inside the maintenance window. But other servers need tighter control. A database server, a business app or a system with a strict uptime promise may need its service owner to choose the restart time. In that case, you avoid an automatic reboot and plan it separately. The update can install, but the final restart waits for the right people and the right time. As your update manager also supports automatic VM guest patching for supported Azure Virtual Machines. In plain English, Azure can download and install updates inside the virtual machine under the rules you choose. You set the patching approach and Azure handles the routine work in the guest operating system. That can reduce manual effort, but it doesn't remove the need to test the application running on that machine. Then there's hot patching on supported Windows versions and supported Azure Virtual Machines. Some security updates can install without a reboot. That's useful when keeping a service online matters. But hot patching isn't a free pass to forget about maintenance Windows. It applies only to supported systems and selected updates. Some changes still need a normal restart. Treat hot patching as a way to reduce restarts in the right cases, not as a promise that every server can stay online forever. A safe patch plan usually moves in stages. Start with development and test servers. These are the machines where you learn whether an update affects your application, scripts or basic server behavior. After those checks pass, patch a small production pilot group. Choose machines that represent the wider environment, but don't put the whole business at risk if something goes wrong. Watch the application, confirm the servers restart cleanly when needed. Give the service owners time to spot problems. Only then do you patch the wider production group. This is why development, test and production should have separate maintenance Windows. You don't want one giant patch night where every machine changes at the same time. Separate Windows give you time to learn from the earlier group before the next group receives the same updates. A schedule prevents surprise outages. But a schedule only tells you what Azure intended to do. Next, you need proof that the work completed and you need a clear way to find the machines where it didn't. Compliance turns patching into evidence. So a patch schedule finishes on time, but that doesn't always mean every server is safe. One machine might fail halfway through, another waits for a reboot, and a third never even reaches the update source. If you only look at that green success message for the overall schedule that one failed server stays exposed long after patch night ends. Here's why update manager keeps update history. For each update run, you can review exactly what happened to the machines in scope. You'll see an installation that completed, one that failed, or a machine waiting for a restart, meaning the work isn't fully done yet. A failed result doesn't always mean the same thing. The server could have a disk space problem. Its update servers might not be working. A Linux server can't reach its package source or an update conflicts with something already installed. The history gives your team a starting point. Instead of telling an auditor or a service owner, we ran the patch job. You can answer the more useful question, which servers still miss security updates, and what are we doing about them? That turns patching into real evidence. Here's how you use the compliance view. Narrow the list to machines with missing security updates. Check the last assessment and the last installation result, then assign the follow-up work to the people who own that server or application. Behind the scenes, as your update manager uses as your resource graph for this compliance information. That name sounds technical, but the idea is simple. As your resource graph is a way for as you're to search across the resources you manage and return information about them. Update manager uses it to build a central view of update status and compliance. You don't need to create a log analytics workspace just to use the core update manager service. That's different from the older patching setup where log analytics was a required piece. You can still use Azure Monitor and log analytics if you want alerts, longer term records, or deeper investigation. There are useful tools when your team needs to connect patch failures with other events, but they are optional for the basic patching flow. Now let's talk about governance. Azure Policy lets an organization set rules for how Azure resources should be managed. For patching, that means checking whether machines have the expected update settings, it turns a team preference into a rule that can be checked across many resources. Our back, role-based access control, answers a different question, who is allowed to do what? One person may be allowed to view compliance, another may run an assessment. A smaller group may have permission to create or change production patch schedules. That separation matters because patching can restart servers and affect real services. Imagine a schedule deployment runs overnight and one production server reports a failure. An Azure Monitor alert sends the team a message. In Update Manager, they check the history and find the server couldn't complete the installation. They connect to the server, find the blocker, fix it, and run the update again during an approved window. The schedule ran, the evidence showed the work wasn't finished. This is where Azure Update Manager differs most from the older patch management setup. It moves patching, reporting, and control closer together inside, what replaced the old setup. So why does Azure Update Manager feel different from the older Azure patching setup? Azure Automation Update Management tied patching work to an automation account and a log analytics workspace. Before your team could manage updates and see results, those extra services needed to exist and connect correctly. They could work well, but they added setup, ownership questions, and more places where access or reporting could become confusing. The newer model puts Update Management inside Azure as a native service. It uses Azure Resource Manager, the standard way Azure handles resources, permissions, and changes. That also means access can sit closer to the machine itself. A team can receive permission for a specific virtual machine, a resource group, or a wider Azure area depending on what they own. You don't need to hand someone broad access to a shared automation account just because they need to manage a small set of servers. Think about the difference like this. The older setup asked you to visit extra rooms before the repair work could begin. You needed the control room, the records room, and the repair desk to work together. With Azure Update Manager, the repair desk sits where you manage the server. You still need people, process, and care. But there are fewer places to set up before the work can start. That doesn't change the parts that always need human judgment. Windows and Linux updates still need testing. Applications still need owners who can tell you whether they work after a change. Maintenance Windows still need to match the real needs of the business and reboot plans still need agreement before anyone touches a production service. The service improves the patching process. It doesn't remove responsibility from the people running it. What improves is the path into the service. Azure VMs can use Update Manager without setting up the old automation and log analytics foundation first. Azure Arc also lets you bring connected servers from your own server room or another cloud into the same management approach. You can run a plan schedule when the routine calls for it. Or start an update job when an urgent issue needs a faster response. Cost depends on where the server runs. Azure VMs don't carry a direct Azure Update Manager charge. Arc enabled servers can cost about $5 per server each month, although some cases like certain bundled services can change that cost. Always check the current as you are pricing for your own setup before you commit. And remember, a new tool isn't an automatic safety switch. Move in stages. Start with a small group, compare the results with your existing process and confirm that permissions, schedules, update sources and reporting all behave the way you expect. Only then should you move more servers into the new approach. With the system clear, you can begin with a patch plan your team can repeat. Here's how to put Azure Update Manager into practice. Start with assessment. Look at machines missing security updates before you schedule anything. Then build patch rings, use Dev and Test first, then a small production pilot, then the wider group. Each ring gets its own maintenance window. Agree on reboot rules with your service owners. Send alerts when a patch job fails if servers run outside Azure connect them through Azure Arc. That gives you the same patch view everywhere. One process beats scattered lists. Azure Update Manager brings assessment, scheduling, patching and proof into one connected Azure service. Start with one small server group, confirm it works. Then expand, subscribe on your favorite podcast platform and share this knowledge nugget with someone planning their next patch night.