Making configuration changes in Panorama (whether to Templates, Device Groups, Policies, or Objects) modifies the candidate configuration . These changes do not take effect on Panorama itself or on managed firewalls until a Commit operation is performed.
Panorama provides different types of commit operations to control whether changes are saved only on Panorama or pushed down to managed firewalls. Additionally, certain operations, particularly dynamic content updates, can be scheduled for automatic execution.
Understanding the different commit types, scope options, and scheduling mechanisms is fundamental to managing firewalls effectively with Panorama.
It's helpful to remember the configuration states on Panorama:
The Commit process makes the candidate config the new running config *on Panorama*.
When you click the "Commit" button in Panorama, you are presented with options that determine the scope and target of the operation.
| Commit Type | Action | Purpose | Impact on Firewalls? |
|---|---|---|---|
| Commit (or Commit to Panorama) | Saves the current candidate configuration as the new running configuration ONLY on the Panorama server itself . |
|
No immediate impact. Does not send any configuration changes to managed firewalls. |
| Commit and Push |
|
|
Yes. This is the operation that sends configuration changes to managed firewalls, potentially overwriting local settings and impacting traffic flow based on the changes. |
When performing a Commit or Commit and Push, Panorama offers scope options to control *what* configuration changes are included and *where* they are sent:
Before committing or pushing, Panorama offers critical validation tools:
Always use Validate Commit and carefully review Preview Changes before initiating a Commit and Push operation, especially in production environments.
While most configuration changes are pushed manually via "Commit and Push", Panorama allows scheduling certain operations:
Device > Dynamic Updates
within a
Template
and pushed to firewalls. Panorama itself can also be scheduled to download updates (
Panorama > Device Deployment > Dynamic Updates
).
Panorama > Scheduled Config Push
.
Scheduling is primarily used for routine Content Updates rather than frequent configuration changes, which usually warrant manual validation and push.
For the PCNSE exam, understand:
Panorama > Scheduled Config Push
).
1. What is the primary difference between a 'Commit' and a 'Commit and Push' operation in Panorama?
2. An administrator makes changes in Device Group 'DG-Branch' and Template 'TPL-Branch'. They want to save these changes on Panorama but NOT send them to firewalls yet. Which action should they perform?
3. What is the main purpose of using the 'Validate Commit' option before committing?
4. The "Push Scope Selection" screen appears during which Panorama operation?
5. What is the MOST common use case for scheduling commit-related tasks in Panorama?
6. Where are the schedules for Dynamic Content Updates (like Applications and Threats) typically configured so they apply to managed firewalls?
7. What happens to configurations made locally on a firewall when a 'Commit and Push' is performed from Panorama for that firewall's Device Group/Template Stack?
8. What information does the 'Preview Changes' feature typically show during a Commit and Push?
9. An administrator wants to apply changes made ONLY within the 'Templates' section of Panorama without affecting any Device Group policies yet. Which commit scope should they choose?
10. True or False: Scheduled Configuration Pushes (Panorama > Scheduled Config Push) are the primary method for deploying daily Antivirus updates to managed firewalls.