How to Configure Configuration Automation
Configuration Automation defines a registry/script-based configuration, groups configurations into a bundle, deploys them to specific endpoints, and confirms the change was actually applied.
How to Configure Configuration Automation
Overview:
Why a registry tweak needs a workflow, not a one-off script
Turning off an application's auto-updater, disabling a Windows upgrade prompt, or stopping error reporting are all small, well-understood changes - a single registry key or a short command. The problem isn't knowing the fix, it's applying the same fix consistently across every endpoint that needs it, tracking which endpoints already have it, and proving it actually took effect rather than just assuming a script ran.
Configuration Automation covers that path: a Config Catalog of individual configurations (each a registry edit or script, scoped to an OS and architecture), a Config Bundle for grouping related configurations together, and Config Deployment for pushing a configuration (or bundle) to a chosen scope of endpoints. Like other automation modules, defining a configuration changes nothing by itself - nothing happens until it's deployed, and every deployment breaks down into a per-endpoint task with its own status and execution log.
This guide walks the full workflow end to end: opening Configuration Automation, reviewing how a catalog entry is structured, grouping configurations into a bundle, publishing a Config Deployment to a specific endpoint, and confirming from the task output that the change actually applied.
- Command or script, your choice: Configuration Type supports
command(e.g. a Registry edit) orscript, so simple and complex changes both fit the same catalog. - Generate Command assists the Registry command type: rather than hand-typing a
reg addstring, the Command Type/Command fields support a Generate Command action. - Is Remediation flags corrective configurations: a toggle on each catalog entry marks whether it's meant to fix a detected issue rather than apply a baseline setting.
- Bundles group related configurations: an OS-scoped bundle (e.g. "Adobe Acrobat") can hold several individual configurations so they deploy together as one unit.
- Full per-command execution log: the task output reports the exact command executed and its exit code, not just a single pass/fail result.
Prerequisites
Confirm these before deploying a configuration. An unconfirmed registry path or command syntax is the most common reason a deployment reports success while the setting on the endpoint doesn't actually change.
- Administrator access: your account holds a role permitted to manage the Automation -> Configuration Automation module.
- Agent installed and reporting: the endpoint agent is installed, registered, and reporting healthy on every target device.
- Exact registry path or script confirmed: for a Registry command type, confirm the exact key path, value name, type, and data before saving the catalog entry.
- Endpoint scope identified: know which specific endpoints this configuration or bundle should be deployed to before publishing the deployment.
Architecture: how a configuration reaches an endpoint
A Config Catalog entry defines the change itself. An optional Config Bundle groups related entries together. A Config Deployment binds a configuration (or bundle) to a scope of endpoints. The endpoint agent runs the command or script and reports back a per-task status and log.
| Stage | Component | Role |
|---|---|---|
| Definition | Config Catalog entry | Name, type (command/script), OS, architecture, description, Is Remediation flag, command type and command |
| Grouping (optional) | Config Bundle | Groups multiple catalog configurations, scoped to an OS, for deployment together |
| Binding | Config Deployment | Scope, endpoints, Configuration or Configuration Bundle selection, deployment policy, retry count, notification list |
| Execution | Endpoint agent | Runs the command or script, reports per-endpoint task status |
| Proof | Task Status and Output | Per-endpoint Success status with a timestamped, exit-code-level execution log |
Pro tip: Existing catalog entries are a good reference before writing a new one from scratch - browsing entries like "Turns off Automated Adobe Acrobat X Updater" shows the exact Registry command syntax the platform expects.
Step 1: Open Configuration Automation
Get oriented before deploying anything, so you know where the catalog, bundles, and deployments each live.
Instructions
- From the main console, go to Automation in the left sidebar, then select Configuration Automation from the submenu (alongside Software Automation).
- Note the sections in the left sidebar: Config Catalog, Config Bundle, and Config Deployment.
Path: Console / Automation / Configuration Automation
Result: You're in the Configuration Automation module with visibility into the existing Config Catalog before deploying anything.
Step 2: Review or create a Config Catalog entry
Understand how a configuration is structured before deploying one, or define a new one of your own.
Instructions
- Go to Config Catalog to browse existing entries, each showing a Configuration Name, ID (CNF-###), Architecture, and Configuration Type.
- Select Create to define a new entry, or the edit icon on an existing one to review its structure.
- Enter a Configuration Name and set Configuration Type to
commandorscript. - Set OS and Architecture.
- Enter a Description.
- Optionally set Tags and toggle Is Remediation if this configuration corrects a detected issue rather than applying a baseline setting.
- Under Configuration action, set Command Type (e.g.
Registry) and enter the Command, or select Generate Command for assistance. - Select Create (or Update when editing).
Path: Console / Automation / Configuration Automation / Config Catalog / Create
Console: catalog entry (example)
| Field | Value |
|---|---|
| Configuration Name | Turns off Automated Adobe Acrobat X Updater |
| Configuration Type | command |
| OS | Windows |
| Architecture | x64 |
| Description | Disables the automatic updates of Adobe Acrobat X |
| Command Type | Registry |
| Command | reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies..." |
Result: The Config Catalog holds a mix of built-in entries (disabling auto-updates for Adobe Acrobat/Reader, Google Chrome, Internet Explorer upgrades, Java, and similar) alongside any custom entries you add. Like other catalog-based modules, an entry has no effect until targeted by a deployment.
Important: Configuration Type and Command Type work together - a command type paired with Registry expects a reg add/reg delete-style command, while script expects a full script body instead. Confirm both match what you're actually trying to run.
Step 3: Group related configurations into a Config Bundle (optional)
Combine several individual configurations into one reusable unit when they're commonly deployed together.
Instructions
- Go to Config Bundle -> Create.
- Enter a Bundle Name, e.g. Adobe Acrobat.
- Set OS.
- Enter a Description, e.g. Update or on-off Adobe Acrobat.
- Under Configurations, select individual catalog entries from the left pane and move them into the bundle on the right.
- Select Create.
Path: Console / Automation / Configuration Automation / Config Bundle / Create
Console: bundle definition (example)
| Field | Value |
|---|---|
| Bundle Name | Adobe Acrobat |
| OS | Windows |
| Description | Update or on-off Adobe Acrobat |
| Configurations | 8 selected |
Result: The bundle appears in the Config Bundle list with its OS and a count of included configurations, ready to be selected as a single unit in a Config Deployment.
Pro tip: A bundle is scoped to one OS - if you need the same logical group of settings applied on both Windows and macOS, that's two separate bundles, one per OS, even if the underlying intent is identical.
Step 4: Publish a Config Deployment to endpoints
Bind a configuration (or bundle) to a scope of endpoints so the change is actually applied, rather than just defined.
Instructions
- Go to Config Deployment -> Create.
- Enter a Deployment Name, e.g. Stop Auto update Notification.
- Add an optional Description.
- Under Targeting, set Scope to
Specific Endpoints(or another available scope) and select the target Endpoints. - Under What to deploy, choose the Configuration tab (or Configuration Bundle for a group).
- In Select Configurations, check the configuration(s) to include - they move into the selected pane on the right.
- Under Policy & delivery, set Deployment Policy (e.g.
OOB Instant deployment policy, typeInstant). - Set Retry Count (defaults to
1). - Optionally set Notify to for completion alerts.
- Select Publish (or Save As Draft to finish later).
Path: Console / Automation / Configuration Automation / Config Deployment / Create
Console: deployment definition
| Field | Value |
|---|---|
| Deployment Name | Stop Auto update Notification |
| Scope | Specific Endpoints: <ENDPOINT-HOSTNAME> |
| Selected Configuration | CNF-006: Turns off Windows 10 upgrade notifications |
| Deployment Policy | OOB Instant deployment policy (Instant) |
| Retry Count | 1 |
Result: A deployment task is created (e.g. ADR-126: Stop Auto update Notification) with stage Initiated, moving through to Completed with progress 1/1, visible in the Config Deployment list alongside prior deployments.
Warning: Retry Count only governs automatic retries of a failed attempt - it won't fix a Command with the wrong registry path or an unsupported switch. If a deployment keeps failing after retries, review the catalog entry's Command before increasing the count further.
Step 5: Confirm the deployment with per-endpoint task status and output
Verify the setting actually changed on the endpoint, rather than assuming from the deployment stage alone.
Instructions
- Go to Config Deployment to see every deployment with its Stage (
Initiated,Completed), Progress, and Policy. - Select the view icon on a deployment row to open its Tasks panel, showing Endpoint, Name, Status, and Last Updated.
- Confirm the Status shows
Successfor the target endpoint. - Select the task row to open its Output view and review the exact command executed and its exit code.
Path: Console / Automation / Configuration Automation / Config Deployment / Tasks / Output
Console: task status
| Endpoint | Name | Status | Last Updated |
|---|---|---|---|
| <ENDPOINT-HOSTNAME> | Turns off Windows 10 upgrade notifications | SUCCESS | 2026/07/29 03:07:04 PM |
Result: Evidence-backed confirmation of the exact command that ran and its exit code, not just a single Success flag for the whole deployment.
Best practices for configuration automation
| Practice | Why it matters | Recommended setting |
|---|---|---|
| Confirm the exact registry path before saving | A mistyped key, value name, or hive silently fails to apply the intended change | Verify the path on a reference endpoint before authoring the catalog entry |
| Use Is Remediation intentionally | It flags an entry as corrective, which affects how it should be interpreted in reporting | Reserve it for configurations that fix a detected drift, not baseline settings |
| Group related settings into bundles | A single application often needs several related registry changes deployed together | Bundle per application or per OS-scoped intent, not as one catch-all bundle |
| Use Specific Endpoints while validating a new configuration | A broad scope makes it harder to confirm a new catalog entry behaves as expected | Test on one or two endpoints first, then expand |
| Check the exit code in Output, not just Status | A Success status confirms the agent ran the command, not that the command itself succeeded logically | Review the Output log's exit code for any new or unusual configuration |
| Set a Notify To list for unattended deployments | Without it, a failed configuration change can go unnoticed until someone checks manually | Add relevant recipients for any deployment run outside business hours |
Troubleshooting: common issues and resolutions
| Issue | Cause | Resolution |
|---|---|---|
| Deployment shows Success but the setting didn't change | Registry path, value name, or data type in the Command doesn't match what the application actually reads | Re-confirm the exact registry key and value against the application's documented settings |
| Task Status shows Failed | Agent lost connectivity mid-deployment, or the command syntax is invalid | Confirm agent health, then check the Output log for the specific error before re-publishing |
| Command executed but exit code is non-zero | The command ran but hit a logical failure (e.g. missing parent key, insufficient permissions) | Adjust the command or confirm the endpoint's permission level, then redeploy |
| New catalog entry doesn't appear in the Config Deployment picker | The entry was saved but the deployment panel's list wasn't refreshed | Close and reopen Create Configuration Deployment, or refresh the Config Catalog list first |
| Bundle deployment applies fewer settings than expected | One or more configurations were removed from the bundle after it was last reviewed | Open the bundle in Config Bundle and confirm all intended configurations are still included |
| Deployment stays at Initiated indefinitely | The target endpoint's agent isn't reporting, or the Deployment Policy type doesn't match the intended trigger | Confirm agent connectivity and the selected Deployment Policy's type (e.g. Instant) |
Frequently asked questions
No. A catalog entry only defines the change. It's applied only once targeted by a Config Deployment published to a chosen scope of endpoints.
Command is suited to a single instruction, such as a Registry edit. Script is suited to a longer, multi-step change that a single command can't express.
It flags the configuration as corrective, meant to fix a detected issue, as distinct from a configuration that applies a standard baseline setting.
A bundle groups related configurations, scoped to one OS, so they can be selected and deployed together as a single unit rather than repeating the same multi-select every time.
Open the deployment's Tasks panel and check the Status column for that endpoint, then open the task's Output view to see the exact command and its exit code.
It sets how many times the agent automatically retries a failed attempt before the task is marked Failed, helping absorb transient issues like a brief network drop.