Panorama commit succeeded, but the firewall still shows an old setting—or the managed-device view says out of sync. Do not start by selecting Force Template Values. First identify which boundary failed: commit to Panorama, push selection, the firewall job, or the effective configuration on the target.
This guide provides a reusable troubleshooting matrix and push approval worksheet for that investigation. It is a proposed operational workflow, not a report of a production incident or an executed firewall test. Product behavior is grounded in the PAN-OS 11.2 Commit Operations reference and the vendor's Templates and Template Stacks page; check the matching documentation for your deployed release.[1][3]
Why a successful Panorama commit is not proof of deployment
A commit to Panorama activates its local configuration, including device-group and template changes, without pushing those changes to managed firewalls.[1] For Panorama 8.0 and later, the push uses the committed running configuration rather than uncommitted candidate changes.[1] Consequently, record the Panorama commit result and the per-device push result separately.
Treat these as separate questions:
- Was the intended change included in the Panorama commit?
- Did the push scope include the intended device, virtual system, and configuration area?
- Did that specific target complete its configuration job?
- Does the intended value now appear in the effective configuration?
- Did the affected service pass its functional test?
An out-of-sync indication is a starting point for diagnosis, not permission to overwrite local configuration. Conversely, do not accept a green status alone as evidence that the application behaves correctly. Make the configuration comparison and service test part of change closure.
Panorama out-of-sync troubleshooting matrix
Use this table top to bottom. The product behaviors referenced in the cause column come from the vendor documentation; the evidence collection and next actions are this article's recommended workflow.[1][3]
| Symptom | Cause to investigate | Evidence to collect | Safe next action |
|---|---|---|---|
| Panorama commit is successful; firewall still has old policy | Commit completed locally but the relevant push has not completed.[1] | Commit time, push job, device-group selection and target list | Review the committed change, then validate the intended push scope. |
| Template setting stays unchanged after a successful push | A firewall-local override may still own the setting.[3] | Effective local value, template value and override indicator | Establish why the override exists before changing ownership. |
| One template was edited, but a different value appears | A higher-priority template may define the same setting.[3] | Assigned stack, template order and duplicate setting definitions | Correct the intended source of the value rather than repeatedly pushing the lower-priority template. |
| Some targets updated and others did not | The push selection or per-target result may differ.[1] | Expanded target list, virtual systems, per-device jobs and timestamps | Investigate the missed or failed target; do not assume the whole fleet needs another push. |
| Rule or object changes are unexpectedly missing | Administrator, location or access-domain filters can limit commit and push scope.[1] | Change Summary, ownership and selected filters | Confirm the required dependencies and authorizations before broadening the scope. |
| A push includes an unexpected local change | Merge with Candidate Config can include pending firewall-local changes.[1] | Local configuration audit and the merge selection used | Stop further pushes; reconcile candidate changes with their owners. |
| A policy-only change also updates network settings | Include Device and Network Templates can include associated template changes.[1] | Push options and template differences | Explicitly approve the combined change or split the operations with dependencies reviewed. |
| The job fails validation | Configuration may be syntactically or semantically incomplete.[1] | Exact validation error, referenced object and configuration location | Correct the specific dependency; validate again before attempting deployment. |
Do not label all of these conditions “connectivity.” If the firewall never receives a job, first confirm that it was selected and inspect its management connection. If it receives a job that fails validation, work from that error. If the job succeeds but the value differs, investigate configuration ownership and precedence.
Step 1: Freeze the evidence before retrying
Start an incident or change worksheet before another administrator launches a broad push. Suggested fields:
Change identifier:
Panorama release / firewall release:
Intended configuration item and desired value:
Owning device group or template stack:
Target device and virtual system (keep privately):
Panorama commit job / timestamp / result:
Push job / timestamp / per-device result:
Local candidate changes reviewed by:
Local override present and approved owner:
Expected service test and rollback trigger:
Keep serial numbers, management addresses, credentials and configuration exports in your authorized internal system, not a public troubleshooting thread. Redact diagnostic bundles before sharing them externally.
Panorama's Task Manager exposes commit details, and Change Summary identifies settings, locations, owners and whether an item will be committed.[1] Use those views to establish the sequence instead of relying on an operator's recollection of clicking Commit and Push.
Step 2: Separate missing commit content from missing push scope
Preview Changes compares the selected commit scope with the running configuration, while Validate Commit checks syntax and semantic completeness without changing the running configuration.[1] First use those tools to answer whether the desired configuration is actually in the committed Panorama state.
Next inspect push selection independently. Panorama supports filtering by administrator and location, with administrative roles and access domains affecting the permitted scope.[1] A narrow filter is useful, but do not assume that “my change” is independent of objects edited by someone else. The vendor documents dependencies between administrators' changes and special handling when several administrators add, delete or reposition rules in the same device-group rulebase.[1]
Recommended gate: write down the required rule, object and template dependencies before approving the push. If a dependency is outside your permissions, involve its owner rather than switching blindly to an unrestricted commit.
Expand the target list and verify each intended firewall and virtual system. The No Default Selections setting is administrator-specific and persists across subsequent pushes until disabled.[1] For a missed target, inspect the actual selection; do not assume the dialog has the same defaults as another administrator's session.
Step 3: Check template precedence and local overrides
Within a template stack, Panorama evaluates templates from top to bottom, with higher templates taking priority for duplicate settings.[3] A local firewall override is a separate mechanism: the firewall saves that value locally and Panorama no longer manages that setting.[3]
For the single field under investigation, compare:
- The value in the template you edited.
- Any competing value in higher-priority templates and the stack's own configuration.
- Any variable resolution applicable to that device.
- The value and override state on the firewall itself.
Hypothetical example: you change a shared DNS setting, but one firewall continues to use its locally approved resolver. If a local override owns that field, another ordinary push is not a sound way to decide whether the exception should remain. Ask whether the local resolver is still required, document the decision, and use the supported release-specific procedure for the intended ownership change.
Keep this investigation distinct from a full rollback. If the entire change needs recovery, use the companion Palo Alto configuration rollback checklist to distinguish the recovery scopes.
Step 4: Review the three push options with the largest surprise potential
Merge with Candidate Config
The 11.2 reference describes this option as selected by default: pushed changes merge with pending firewall-local candidate changes, and the push commits the merged result.[1] Clearing the selection excludes that local candidate configuration from the commit.[1]
Recommendation: review the local candidate diff before deciding either way. Leaving it enabled without review can activate someone else's unfinished work; clearing it without reviewing dependencies can omit a local change that your deployment expects. Neither setting is a universal fix.
Include Device and Network Templates
On the Device Groups tab, this option is documented as selected by default and includes associated template changes in the operation.[1] Clearing it lets you push the configuration areas separately.[1]
Recommendation: inspect both policy/object and device/network differences. If you separate the pushes, explicitly decide which dependency must exist first. Avoid treating a policy change as low-risk when its push scope also contains management, routing or interface changes.
Force Template Values
Force Template Values replaces locally overridden values with the template values and is disabled by default; it must be enabled for each push.[1] The documented behavior is not “delete every local object”: a locally configured object that does not exist in the template or stack remains unchanged.[1]
Recommendation: do not use this checkbox as a generic synchronization repair. Inventory the overrides, identify the intended owners, and review the resulting network and management impact before approving it. A seemingly harmless DNS exception should not become the reason unrelated local network settings are overwritten without review.
Push approval worksheet
Copy this into a change ticket. These are recommended gates, not vendor-imposed universal defaults.
| Gate | Required evidence | Stop condition |
|---|---|---|
| Intended delta | Reviewed before/after values and approved change owner | Diff contains unexplained changes. |
| Target scope | Explicit firewalls, virtual systems and configuration areas | Target list differs from the approved change. |
| Local candidate | Audit reviewed; merge decision recorded | Unowned or unfinished local changes are present. |
| Overrides | Exception inventory and ownership decision | Force would replace an exception whose purpose is unknown. |
| Dependencies | Referenced objects and required network settings reviewed | A dependency is missing or belongs to an unapproved change. |
| Recovery | Known-good configuration, access path and named rollback owner | No usable recovery access or restoration procedure. |
| Validation | Successful validation and reviewed warnings | Any unresolved error; warning impact not understood. |
| Service checks | Named tests with baseline and pass criteria | Nobody can demonstrate whether the service improved or regressed. |
Step 5: Verify the firewall, not only the Panorama job
Use a small, explicitly authorized target set where appropriate for your topology. For high-availability deployments, include the intended peer scope in the change design rather than improvising it during troubleshooting. Panorama can group HA peers in the push selection, and its documentation recommends considering both peers in the same device group and template or stack for active/passive deployments.[1]
After the push, capture the exact target result and compare the effective configuration. Then run your pre-agreed service tests. The following is a proposed acceptance matrix; no results here are claimed to have been measured.
| Test | Pass criterion | Evidence to retain |
|---|---|---|
| Panorama commit | Desired delta exists in the committed configuration | Commit result and reviewed diff. |
| Per-target deployment | Every intended target completed the intended operation | Individual job outcomes and timestamps. |
| Effective setting | Desired value is present, with approved ownership | Redacted configuration comparison. |
| Management reachability | Approved management access remains usable | Connection check from the authorized management path. |
| Affected application | The intended transaction succeeds from the intended source | Application test result correlated with relevant logs. |
| Negative control | Traffic that should remain denied is still denied | Approved negative test and matching log evidence. |
| HA scope, if applicable | Required peers show the expected configuration and health | Peer-specific checks, without an unapproved failover drill. |
| Follow-up stability | No unexplained recurrence during the agreed observation window | Rechecked state and monitoring record. |
If a job succeeded but the service fails, stop treating the problem as purely a synchronization issue. Compare the changed policy and network behavior against the baseline. Use the approved recovery trigger if management reachability or an essential service regresses; do not keep widening the push scope to make the dashboard look healthy.
Practical takeaways
Separate local commit, target selection, per-device job success, effective values and functional testing. Inspect ownership before forcing template values. Record merge and template-inclusion choices explicitly. Close the change only when configuration and service evidence agree.
For related guides, use Start Here and the networking resources page. Keep the troubleshooting matrix and approval worksheet with your next Panorama change rather than waiting for an out-of-sync incident.
Post a Comment