Microsoft Azure Update Management

Name: Update Management API
Brand: Update Management
Availability: InStock

★ Only Publicly Available OpenAPI DocumentCloud InfrastructureComputeoauth24 Endpoints

Install Jentic One Beta

Connect the Update Management to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Update Management, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Update Management API.

Create a softwareUpdateConfiguration that targets Windows or Linux machines and applies a chosen patch classification (Critical, Security, Definition)

Schedule patching with a one-time or recurring frequency including time zone, start time, expiry, and advanced schedule options

Limit a deployment by including specific KB IDs or Linux package names and excluding others to keep changes auditable

GET STARTED

Start building with Update Management API

Explore with Jentic

View OpenAPI Document

For Agents

Creates and manages Azure Automation software update configurations to schedule patching campaigns across Windows and Linux VMs.

Use for: Create a recurring monthly Windows patch deployment for production VMs, List all software update configurations on the prod-automation account, Delete the legacy 'weekly-critical' update configuration, Schedule a Linux security patch run for tomorrow at 02:00 UTC

Not supported: Does not install agents on machines, run ad hoc commands, or report on update compliance - use the Log Analytics and Microsoft.OperationsManagement APIs for those; this API only manages softwareUpdateConfiguration objects.

Use Cases

Patterns agents use Update Management API for, with concrete tasks.

★ Monthly Patch Tuesday rollout

Operations teams need a repeatable monthly patching campaign that targets production Windows VMs with Critical and Security classifications, runs at the maintenance window, and reboots if required. The agent creates a softwareUpdateConfiguration with windows.includedUpdateClassifications=Critical,Security, frequency=Month, and an explicit machine list or saved search. Once created, Azure Automation runs the deployment on the configured schedule and emits run history that can be fetched separately.

Create a softwareUpdateConfiguration named 'prod-windows-monthly' on automation account 'ops-aa' in resource group 'ops-rg' with operatingSystem=Windows, includedUpdateClassifications='Critical,Security', frequency=Month, scheduleStart=2026-07-15T02:00:00Z, and target=savedSearch 'prod-windows'.

Emergency one-time Linux patch

When a CVE drops, an agent needs to push a one-time Linux patch across a defined VM list within hours. The configuration is created with operatingSystem=Linux, frequency=OneTime, an explicit azureVirtualMachines list, and linux.includedPackageNameMasks for the affected package. Azure Automation runs the patch run once and the agent tears the configuration down with DELETE after the run completes.

Create softwareUpdateConfiguration 'cve-2026-7777' on automation account 'ops-aa' (resource group 'ops-rg') with operatingSystem=Linux, frequency=OneTime, scheduleStart=2026-06-11T22:00:00Z, includedPackageNameMasks=['openssl*'], and azureVirtualMachines containing the 5 affected VM resource IDs.

Inventory and decommission of stale patch jobs

Long-running Automation accounts accumulate dozens of update configurations that no longer match current VM groups. The agent calls the GET-list endpoint to enumerate every softwareUpdateConfiguration on the account, filters those whose creationTime predates a cutoff, and issues DELETE on each. Run history is preserved on the account because deletion only removes the configuration, not its execution records.

List every softwareUpdateConfiguration on automation account 'ops-aa' (resource group 'ops-rg'), filter to those with creationTime before 2025-01-01, and DELETE each by name.

Agent-managed patch orchestration through Jentic

An AIOps agent receiving a CVE alert can orchestrate the full patching response: search Jentic for the create-configuration operation, fill the schema with the affected packages and VM list, and execute against the automation account. Because Jentic returns the input schema directly, the agent does not need to read the Azure Automation REST docs to know what fields softwareUpdateConfigurationProperties expects.

Search Jentic for 'create azure software update configuration', execute with the JSON above, then poll the configuration GET until provisioningState=Succeeded.

Key Endpoints

4 endpoints — jentic publishes the only available openapi specification for update management, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

GET

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Automation/automationAccounts/{automationAccountName}/softwareUpdateConfigurations

List all software update configurations on an Automation account

GET

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Automation/automationAccounts/{automationAccountName}/softwareUpdateConfigurations/{softwareUpdateConfigurationName}

Get a single software update configuration by name

PUT

Create or replace a software update configuration

DELETE

Delete a software update configuration

GET

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Automation/automationAccounts/{automationAccountName}/softwareUpdateConfigurations

List all software update configurations on an Automation account

GET

Get a single software update configuration by name

PUT

Create or replace a software update configuration

DELETE

Delete a software update configuration

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Your Azure AD OAuth token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'schedule an Azure software update configuration' or 'list patching schedules on an Automation account', and Jentic returns the softwareUpdateConfigurations operation with its input schema, including the updateConfiguration and scheduleInfo blocks, so the agent fills them without reading the ARM reference.

Time to first call

FAQs

Specific to using Update Management API through Jentic.

Why is there no official OpenAPI spec for Update Management?

Microsoft Azure does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Update Management via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer .

What authentication does the Update Management API use?

Azure Active Directory OAuth 2.0 with the user_impersonation scope against https://login.microsoftonline.com/common/oauth2/authorize. Through Jentic the Azure AD client secret is stored encrypted in the vault and a scoped bearer token is issued to the agent at call time.

Can I schedule a recurring monthly patch run with the Update Management API?

Yes. PUT /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Automation/automationAccounts/{automationAccountName}/softwareUpdateConfigurations/{name} with scheduleInfo.frequency=Month and scheduleInfo.startTime set creates a recurring deployment. Time zones are honoured via scheduleInfo.timeZone.

What are the rate limits for the Update Management API?

Calls go through Azure Resource Manager and Azure Automation, subject to the standard ARM throttling envelope (roughly 12,000 reads per hour per subscription) plus per-Automation-account write quotas. The spec does not declare exact limits; back off on Retry-After when a 429 is returned.

How do I create a software update configuration through Jentic?

Run pip install jentic, then client.search('create azure software update configuration'), client.load on the returned PUT operation, and client.execute with the configuration payload (operatingSystem, scheduleInfo, updateConfiguration). Jentic injects the Azure AD bearer token from the vault and returns the created resource.

Does deleting a software update configuration delete its run history?

No. DELETE on .../softwareUpdateConfigurations/{name} removes the configuration object only. Past softwareUpdateConfigurationRuns and softwareUpdateConfigurationMachineRuns remain on the Automation account and can still be queried for audit purposes.

Can I limit what my agent is allowed to do with the Update Management API?

Yes. Because you run Jentic One yourself, your own rules decide which operations and credentials the agent may use, and the subscription, resource group, Automation account, and configuration name are all URL path parameters, so a rule can pin the agent to softwareUpdateConfigurations on a single Automation account. You choose which operations it may call, so destructive ones like deleting a configuration or overwriting one with a PUT are left out unless you add them. That means an agent can be scoped to only list and read patch configurations while create and delete stay off-limits. Your Azure AD OAuth token is stored encrypted by your own instance and injected at call time, never exposed to the agent.