The Azure Automation platform connects Polysync to an Azure Automation account so it can run the account's runbooks as scheduled Jobs — PowerShell scripts that patch, restart or report on servers, and Python scripts that move files or call APIs. A runbook runs either in the Azure sandbox or on a Hybrid Runbook Worker group: your own Windows or Linux machines, on premises or in any cloud. Polysync starts each run as an Automation job, polls it to completion, and reads the runbook's result back as output parameters.
Polysync talks to the Automation account through the Azure Resource Manager REST
API (Microsoft.Automation, api-version 2024-10-23).
.pfx,
with an optional Certificate Password). More secure than a client secret. A
Certificate Thumbprint is looked up in the Polysync host's own certificate
store, so it only works for self-hosted Polysync.Webhooks are not offered: a webhook can start a runbook but cannot report its status, return its output or stop it, and it does not work for Python runbooks. Managed identity is not offered either: Polysync runs in its own Azure tenant, so its managed identity cannot be given roles in yours. The Polysync Service Principal is the secret-less option.
Grant the chosen identity both built-in roles, scoped to the Automation account (not the resource group or subscription):
| Role | What Polysync uses it for |
|---|---|
| Automation Runbook Operator | List runbooks and read their parameters (discovery, and the runbook type and signature at run time). |
| Automation Job Operator | Create jobs, read their status and output, and stop them (execute, monitor, cancel). |
The single built-in Automation Operator role covers both, but it also lets the identity create and change schedules, which Polysync does not need. Neither least-privilege role can read the Automation account resource itself; Polysync never needs to.
Test connectivity checks both roles: it lists runbooks, then lists jobs, and names the missing role when either call is refused. Starting a job can only be proven by running one.
Get Pipelines lists the account's published runbooks. A runbook that has never been published (state New) cannot be started, so it is not offered. Each runbook becomes a Job whose External Id is the runbook name, typed by its runbook type:
Each Automation account has a quota of concurrent jobs. When it is used up Azure Automation refuses new jobs (HTTP 429) and Polysync fails the run with that reason, so a Contention Profile on the Platform is a good way to keep within it.
| Symptom | Likely cause | Fix |
|---|---|---|
| Permission denied … cannot read runbooks | Missing role, or a wrong account, resource group or subscription — ARM reports a scope the identity has no rights on as forbidden, not missing | Grant Automation Runbook Operator and Automation Job Operator on the account; re-check the three names |
| … can read runbooks but cannot read jobs | Only Automation Runbook Operator is granted | Also grant Automation Job Operator |
| MissingSubscriptionRegistration when creating the account | The subscription has never used Azure Automation | Register the Microsoft.Automation resource provider on the subscription |
| A runbook is missing from Get Pipelines | It has never been published | Publish it in the Azure portal, then fetch again |
| Run fails with concurrent-job quota is used up | Too many jobs running in the account at once | Retry later, cap concurrency with a Contention Profile, or request a quota increase |
| Cloud run fails after about three hours | Fair-share limit of the Azure sandbox | Run the runbook on a Hybrid Worker Group |