The news every IT manager should read twice

Arista, which now owns the VeloCloud business, has confirmed a vulnerability in on-premises VeloCloud Orchestrator (VCO) deployments that remote attackers can abuse to reach "privileged internal functionality" on the very platform you use to manage SD-WAN subscriptions and the edge devices they control. The issue was discovered externally and is actively exploited in the wild. Arista has already patched its Hosted and Dedicated VCO environments — but if you run VCO on-premises, fixes are currently available only for some affected versions.

Read that again: actively exploited, and the patch matrix is incomplete. Your exposure now depends entirely on whether you know — right now, with certainty — which VCO build runs on every orchestrator in every site, every client environment, and every lab VM someone stood up in 2022 and forgot about.

How long would it take your team to answer that question? If the honest answer is "I'd have to ask Dave, and Dave is on PTO," this post is for you.

The problem in depth: patch state you can't see is patch state you don't have

On-prem is where patch discipline goes to die

Hosted SaaS gets patched by the vendor on the vendor's schedule. Your on-prem appliances don't. They sit behind a login page on a VLAN nobody scans, running whatever version they shipped with. When the advisory lists six affected builds and fixes for three of them, someone has to manually map "what do we actually run" against "what has a fix" and plan an upgrade path — sometimes a multi-hop one — on infrastructure whose downtime means branch offices fall off the map.

Your RMM was never built for this

Here's the uncomfortable truth about most tool stacks. NinjaOne, ConnectWise RMM, Datto RMM — pick your favorite — are built around an agent installed on a Windows endpoint or server. Ask them for KB-level Windows Update compliance and they deliver. But the VeloCloud Orchestrator is a virtual appliance. So is your firewall controller, your hypervisor management layer, your VPN concentrator. There's no agent. Patch state lives in a vendor portal, an appliance web UI, or — most often — a spreadsheet that was accurate for exactly one week in March.

So the same team runs an RMM for Windows patching, a standalone monitor for uptime and SNMP, a separate helpdesk where incidents land, a wiki for appliance versions, and six browser tabs of vendor advisories. None of those systems talk to each other. That's not a workflow — that's five different chances to miss something.

Patching without monitoring context creates its own outages

Every sysadmin knows this scenario. Emergency patch window at 2am for the SD-WAN orchestrator. The upgrade reboots the VM, tunnels re-negotiate, a branch edge re-registers 90 seconds late. Your standalone monitoring tool — which has no idea a change window exists — fires fourteen alerts. The on-call tech wakes up, sees the storm, and can't tell "planned maintenance" from "production is down." Either they ignore it and gamble, or they start escalating at 2:15am and burn goodwill with leadership.

Worse is the inverse: a patch silently fails on half the fleet. The machines come back up, monitoring shows green, everyone assumes compliance. Six weeks later an auditor asks for a patch report and you discover that 40% of endpoints show failed installs nobody was ever alerted about — because the patching tool and the alerting tool are different products from different vendors who have never spoken to each other.

What this actually costs the team and the business

• Emergency windows compress to exploit timelines, not change management. You patch when the attacker decides, in whatever window you can grab.
• Mystery outages become ticket floods. Branch users open P1 tickets for an orchestrator reboot your own team triggered, and the helpdesk has no link between the change record and the tickets.
• SLA reporting becomes archaeology. Monitoring data lives in one system, ticket data in another, and nobody can produce a defensible MTTR number.
• Your best people do data entry under stress. A senior engineer spends a weekend SSH-ing into appliances to collect version numbers. That's not engineering; that's burnout with extra steps.

How AlertMonitor closes the gap

AlertMonitor was built on a simple bet: patch state, monitoring, alerting, and the helpdesk should be one dataset — not four disconnected products.

1. Real-time patch status on every managed device. The patch management module shows, in one view, which Windows machines are missing updates, which have failed patches, and which are sitting on a pending reboot. When an advisory like Arista's VCO notice drops, the first question — "what's our exposure?" — starts with a complete, current inventory instead of a scavenger hunt.

2. Staged, scheduled, reversible deployments. Patch waves are scheduled and staged by department, device group, or — for MSPs — by client. Domain controllers never patch in the same wave as the workstation fleet. And when a patch causes problems, rollback is a built-in step, not tribal knowledge.

3. Patch-aware alerting. This is what changes the 2am experience. Because patching is integrated with monitoring, a device that reboots after an update fires an alert with full context: this reboot correlates with the scheduled deployment on this device group. The on-call tech sees "planned change in progress" instead of a mystery outage — and users never become your detection mechanism at 8am.

4. Failed patches become alerts, not audit surprises. A failed install doesn't quietly age in a compliance dashboard. It surfaces through alerting with the failure detail attached, so the "silently failed on 40% of the fleet" scenario can't happen.

5. Monitoring for what your RMM can't agent. For infrastructure like a VCO orchestrator host — the VM itself, its services, resource footprint, and reachability — AlertMonitor watches it like any other critical node, so an upgrade window that goes sideways is detected in seconds with change context attached.

The workflow difference: the old way is advisory drops → someone emails the team → three days of manual version collection → emergency change → uncorrelated alerts → unlinked tickets → a report nobody can produce. The AlertMonitor way is advisory drops → inventory and patch status in one dashboard → stage the wave → deploy → reboots land inside known change windows with context-aware alerting → failed patches flagged automatically → compliance report in one click.

What you can do today

1. Sweep your Windows fleet for missing updates

# Patch-compliance sweep: missing updates across a list of servers
$servers = Get-Content C:\Temp\servers.txt

Invoke-Command -ComputerName $servers -ScriptBlock {
    $session  = New-Object -ComObject Microsoft.Update.Session
    $searcher = $session.CreateUpdateSearcher()
    $missing  = $searcher.Search("IsInstalled=0 and Type='Software'")

    [PSCustomObject]@{
        Server       = $env:COMPUTERNAME
        MissingCount = $missing.Updates.Count
        TopMissing   = ($missing.Updates | Select-Object -First 5 -ExpandProperty Title) -join '; '
    }
} | Sort-Object MissingCount -Descending |
  Export-Csv C:\Temp\patch-compliance.csv -NoTypeInformation

Every row in that CSV is a machine an attacker would prioritize. In AlertMonitor, this is a live dashboard, not a script you have to remember to run.

2. Find pending reboots before they surprise you

A server that installed everything in March but hasn't rebooted since is not fully patched.

# Detect pending reboots across the fleet
$rebootKeys = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired',
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
)

Invoke-Command -ComputerName (Get-Content C:\Temp\servers.txt) -ScriptBlock {
    param($keys)
    foreach ($key in $keys) {
        if (Test-Path $key) {
            [PSCustomObject]@{
                Server  = $env:COMPUTERNAME
                Source  = ($key -split '\\')[-1]
                Pending = $true
            }
        }
    }
} -ArgumentList $rebootKeys

3. Install updates on a schedule, with a controlled reboot

# One-time setup: the community module most Windows admins rely on
Install-Module PSWindowsUpdate -Force

# Scan first — never blind-install on infrastructure
Get-WindowsUpdate -MicrosoftUpdate

# Stage the install and land the reboot inside your Saturday 02:00 window
Install-WindowsUpdate -MicrosoftUpdate -AcceptAll `
    -ScheduleReboot (Get-Date '2025-06-14 02:00') `
    -Verbose *>> C:\Temp\patch-run.log

4. Health-check appliance hosts before and after an upgrade window

For virtual appliances like a VCO orchestrator host, wrap the change window in basic health checks:

# Before and after an orchestrator upgrade: confirm the host is sane
uptime               # a recent reboot should match your change window
systemctl --failed   # any failed units after the upgrade?
df -h / /var         # upgrades fail on full disks more than anything else

bash

Sweep multiple orchestrator/appliance hosts after a patch wave

for host in vco-dc01 vco-branch07 vco-branch12; do echo "=== $host ===" ssh -o ConnectTimeout=5 admin@"$host" "uptime; systemctl --failed | tail -n +2" done

If a host in that sweep doesn't come back clean, you want an alert with context — not a branch-office user as your detection mechanism.

5. Then stop relying on scripts to know your patch state

Scripts are how you bootstrap visibility. They're a terrible way to operate it. The workflow that survives audits, staff turnover, and 2am emergencies is one where patch compliance, alerting, change context, and the helpdesk all read from the same data — which is exactly what a unified platform gives you.

The takeaway

The VeloCloud Orchestrator situation isn't exotic. It's the new baseline: actively exploited vulnerabilities, incomplete patch matrices, and critical infrastructure where "what version are we on?" is the difference between a calm Tuesday change window and an incident response. You don't control when vendors disclose or when fixes ship for your specific build. You absolutely control whether you can see your own patch state in seconds instead of days.

Related Resources

AlertMonitor Patch Management & Software Updates AlertMonitor Platform Overview Book a Demo Patch Management & Software Updates Resources