Examples
This section provides practical scenarios to help you understand how to use scm-clone effectively. Each example
demonstrates a real-world usage pattern, from initial setup to cloning various object types (addresses, tags, security
rules, services) with different filters and runtime overrides.
Table of Contents
- Overview
- Flags and Parameters
- Initial Setup (Creating the Settings File)
- Cloning Addresses
- Cloning Tags
- Cloning Services
- Cloning Security Rules
- Cloning Remote Networks
- Cloning Syslog Server Profiles
- Cloning IKE Crypto Profiles
- Cloning IKE Gateways
- Cloning IPsec Crypto Profiles
- Other Supported Commands
- Advanced Examples
Overview
Before running clone operations, ensure you have a settings.yaml file configured. This file stores default
credentials, logging preferences, and default flags like auto_approve or quiet. All commands read from
settings.yaml first, allowing you to run most operations without constantly re-entering credentials or options.
If needed, you can override any setting at runtime using the provided flags.
Flags and Parameters
All commands use the context pattern with the following format:
scm-clone [command] --context [folder|snippet|device] --source "SourceName" --destination "DestinationName" [options]
Command Parameters
| Argument/Flag | Description | Default |
|---|---|---|
--context |
The context type ('folder', 'snippet', or 'device') | "folder" |
--source |
The source folder/snippet/device from which to retrieve objects | None (prompted) |
--destination |
The destination folder/snippet/device where objects will be created | None (prompted) |
--names, -n |
Comma-separated list of object names to filter | None |
--exclude-folders |
Comma-separated list of folders to exclude from retrieval | None |
--exclude-snippets |
Comma-separated list of snippets to exclude from retrieval | None |
--exclude-devices |
Comma-separated list of devices to exclude from retrieval | None |
--commit-and-push |
If set, commit changes on the destination tenant after creating objects | False |
--auto-approve, -A |
If set (or in settings), skip confirmation prompt before cloning | Value from settings |
--create-report, -R |
If set (or in settings), append results to result.csv |
Value from settings |
--dry-run, -D |
If set (or in settings), simulate without applying changes | Value from settings |
--quiet-mode, -Q |
If set (or in settings), hide console output except logs | Value from settings |
--logging-level, -L |
Override logging level (DEBUG, INFO, WARNING, ERROR, CRITICAL) | Value from settings |
--settings-file, -s |
Path to the YAML settings file | settings.yaml |
Initial Setup (Creating the Settings File)
The first step is to generate the settings.yaml file that stores your SCM credentials, default logging preferences,
and behaviors like auto_approve or quiet_mode.
Follow the prompts to enter:
- Source and destination SCM credentials (client_id, client_secret, tsg_id).
- Logging level (e.g., INFO).
- Additional flags (auto_approve, create_report, dry_run, quiet) as defaults.
Once the file is created, all commands will use these defaults unless overridden at runtime.
Cloning Addresses
Addresses are one of the most common object types. After creating settings.yaml, you can clone addresses from a source
folder.
Example: Cloning addresses from folder "Texas" with no additional filters:
If auto_approve is false in your settings, you'll be prompted before actually creating the objects. If quiet_mode
is false, you'll see a table of retrieved addresses and, after creation, a table of successfully created objects.
Overriding to run a dry-run:
This simulates the process without applying changes.
Using filters and committing changes after creation:
This excludes addresses from the All and Default folders, snippet predefined, auto-approves the operation, and
commits changes after successful creation.
Cloning Tags
For tags, assume we have a similar workflow. Just specify the folder and any filters:
This auto-approves and excludes any tag objects associated with DeviceA, prompting no confirmations since -A was
used.
If you want a dry-run scenario for tags:
This will show you what would happen without making any changes.
Cloning Services
For services, you may want to exclude certain snippets or folders. Additionally, you might want to run quietly to avoid console clutter:
This command suppresses console output, relying on logs for progress. If you have auto_approve enabled in
settings.yaml, it will skip prompts as well.
To commit changes after cloning services:
Cloning Security Rules
Security rules often require careful filtering and a dry-run before applying. Suppose you want to clone rules from
folder cdot65 in the pre rulebase, and you'd like a prompt before proceeding:
If you want to exclude certain devices or snippets while cloning security rules:
To automatically approve and commit the changes:
Cloning Remote Networks
Remote Networks are a key component of SASE deployments. After setting up your settings.yaml file with proper SASE credentials, you can use the following commands to clone Remote Network objects between tenants.
Basic cloning of remote networks from a source folder:
This will list all remote networks in the source folder, prompting for confirmation before cloning.
Specifying different source and destination folders:
This retrieves remote networks from "Remote Networks" folder in the source tenant and creates them in the "Branch Offices" folder in the destination tenant.
Excluding specific folders and auto-approving:
This excludes any remote networks in the "Deprecated" and "Testing" folders, and skips confirmation prompts.
Running a dry run with automatic commit after creation:
This will simulate the creation without applying changes. Note that --commit-and-push has no effect during a dry run.
Complete example with reporting and commit:
This command: - Retrieves remote networks from "Remote Networks" folder, excluding any in the "Testing" folder - Creates them in the "Production" folder in the destination tenant - Auto-approves without prompting for confirmation - Creates/appends results to result.csv - Commits changes to the destination tenant after successful creation
Cloning Syslog Server Profiles
Syslog server profiles define configurations for forwarding logs to external syslog servers. The following examples demonstrate how to clone these configurations between SCM tenants.
Basic cloning of syslog server profiles from a source folder:
This lists all syslog server profiles in the source folder and prompts for confirmation before cloning.
Using a specific context type and folder:
This explicitly specifies that we're working with folders, retrieves profiles from the "Logging" folder, and creates them in the "Security" folder.
Working with snippets instead of folders:
This retrieves profiles from a source snippet and creates them in a destination snippet, instead of working with folders.
Excluding specific profiles and auto-approving:
This excludes profiles from the "Test" and "Development" folders, automatically proceeding without confirmation.
Performing a dry run:
This simulates the cloning operation without making any changes, showing what would be created.
Creating a report, committing changes, and enabling quiet mode:
This command: - Retrieves syslog server profiles from the "Logging" folder - Creates them in the "Production" folder - Auto-approves without prompting for confirmation - Creates/appends results to result.csv - Runs in quiet mode with minimal console output - Commits changes after successful creation
Debugging issues with verbose logging:
This increases the logging level to DEBUG to help diagnose any issues that might occur during the cloning process.
Cloning IKE Crypto Profiles
IKE Crypto Profiles define the encryption, authentication, and key exchange parameters used for IPsec VPN tunnels. The following examples demonstrate how to clone these profiles between SCM tenants.
Basic cloning of IKE crypto profiles from a source folder:
This lists all IKE crypto profiles in the source folder and prompts for confirmation before cloning.
Specifying different source and destination folders:
This retrieves IKE crypto profiles from the "VPN" folder and creates them in the "VPN-Profiles" folder in the destination tenant.
Using snippets instead of folders:
This retrieves profiles from a source snippet and creates them in a destination snippet.
Filtering by profile names:
This clones only the specified profiles by name from the source folder.
Performing a dry run with auto-approve:
This simulates the cloning operation without making any changes and skips confirmation prompts.
Complete example with reporting and commit:
This command: - Retrieves only the specified IKE crypto profiles from the "VPN" folder - Creates them in the "Production-VPN" folder in the destination tenant - Auto-approves without prompting for confirmation - Creates/appends results to result.csv - Commits changes to the destination tenant after successful creation
Cloning IKE Gateways
IKE Gateways define the connection points for IPsec VPN tunnels. The following examples demonstrate how to clone these gateway configurations between SCM tenants.
Basic cloning of IKE gateways from a source folder:
This lists all IKE gateways in the source folder and prompts for confirmation before cloning.
Specifying different source and destination folders:
This retrieves IKE gateways from the "VPN" folder and creates them in the "VPN-Gateways" folder in the destination tenant.
Using snippets instead of folders:
This retrieves gateways from a source snippet and creates them in a destination snippet.
Filtering by gateway names:
This clones only the specified gateways by name from the source folder.
Performing a dry run with auto-approve:
This simulates the cloning operation without making any changes and skips confirmation prompts.
Complete example with reporting and commit:
This command: - Retrieves only the specified IKE gateways from the "VPN" folder - Creates them in the "Production-VPN" folder in the destination tenant - Auto-approves without prompting for confirmation - Creates/appends results to result.csv - Commits changes to the destination tenant after successful creation
Cloning IPsec Crypto Profiles
IPsec Crypto Profiles define the encryption, authentication, and other security parameters used for IPsec VPN tunnels. The following examples demonstrate how to clone these profiles between SCM tenants.
Basic cloning of IPsec crypto profiles from a source folder:
This lists all IPsec crypto profiles in the source folder and prompts for confirmation before cloning.
Specifying different source and destination folders:
This retrieves IPsec crypto profiles from the "VPN" folder and creates them in the "VPN-Profiles" folder in the destination tenant.
Using snippets instead of folders:
This retrieves profiles from a source snippet and creates them in a destination snippet.
Filtering by profile names:
This clones only the specified profiles by name from the source folder.
Performing a dry run with auto-approve:
This simulates the cloning operation without making any changes and skips confirmation prompts.
Complete example with reporting and commit:
This command: - Retrieves only the specified IPsec crypto profiles from the "VPN" folder - Creates them in the "Production-VPN" folder in the destination tenant - Auto-approves without prompting for confirmation - Creates/appends results to result.csv - Commits changes to the destination tenant after successful creation
Other Supported Commands
The following commands are also available but not covered in detail in this examples document. They all follow the same pattern and support the same flags and arguments as the commands shown above.
Object Commands
- address-groups: Clone address group objects (use
--context folder/snippet/device) - application-filters: Clone application filter objects (use
--context folder/snippet/device) - application-groups: Clone application group objects (use
--context folder/snippet/device) - dynamic-user-groups: Clone dynamic user group objects (use
--context folder/snippet/device) - hip-profiles: Clone HIP profile objects (use
--context folder/snippet/device) - http-server-profiles: Clone HTTP server profile objects (use
--context folder/snippet/device) - log-forwarding-profiles: Clone log forwarding profile objects (use
--context folder/snippet/device) - quarantined-devices: Clone quarantined device objects (use
--context folder/snippet/device) - regions: Clone region objects (use
--context folder/snippet/device) - schedules: Clone schedule objects (use
--context folder/snippet/device) - service-groups: Clone service group objects (use
--context folder/snippet/device)
Security Service Commands
- anti-spyware-profiles: Clone anti-spyware profile objects (use
--context folder/snippet/device) - decryption-profiles: Clone decryption profile objects (use
--context folder/snippet/device) - dns-security-profiles: Clone DNS security profile objects (use
--context folder/snippet/device) - security-rules: Clone security rule objects (use
--context folder/snippet/device) - url-categories: Clone URL category objects (use
--context folder/snippet/device) - vulnerability-profiles: Clone vulnerability protection profile objects (use
--context folder/snippet/device) - wildfire-profiles: Clone Wildfire antivirus profile objects (use
--context folder/snippet/device)
Network Service Commands
- ike-crypto-profiles: Clone IKE crypto profile objects (use
--context folder/snippet/device) - ike-gateways: Clone IKE gateway objects (use
--context folder/snippet/device) - ipsec-crypto-profiles: Clone IPsec crypto profile objects (use
--context folder/snippet/device) - nat-rules: Clone NAT rule objects (use
--context folder/snippet/device)
To use any of these commands, follow the same context pattern for all commands:
For detailed information about each command, including its specific parameters and behavior, refer to the Commands section.
Advanced Examples
Using a Custom Settings File: If you have multiple environments, you might have different settings files:
This command uses production_settings.yaml instead of the default settings.yaml.
Generating a Report: If you want to record all cloned addresses into result.csv for auditing:
After cloning, the CLI will append the results to result.csv with details about each cloned object.
Combining Flags: For a scenario where you want to exclude folders, run quietly, auto-approve, and create a report all at once:
This command retrieves and clones tags from the "Texas", excluding "All" and "Default" folders, auto-approves
without prompts, creates a CSV report, and runs quietly without console output.
Complete Tenant Migration Workflow
This section demonstrates a comprehensive workflow for migrating configuration from one tenant to another.
Step 1: Initial Setup
First, create your settings file with credentials for both source and destination tenants:
Follow the prompts to enter your source and destination tenant credentials.
Step 2: Clone Static Objects First
Start by cloning the foundational objects that other configurations may depend on:
# Clone servicesscm-clone services --context folder --source "Service Objects" --destination "Service Objects" --commit-and-push
# Clone tagsscm-clone tags --context folder --source "Tags" --destination "Tags" --commit-and-push
Step 3: Clone Group Objects
Next, clone group objects that reference the static objects:
# Clone service groupsscm-clone service-groups --context folder --source "Service Objects" --destination "Service Objects" --commit-and-push
# Clone application groupsscm-clone application-groups --context folder --source "Applications" --destination "Applications" --commit-and-push
Step 4: Clone Security Profiles
Before cloning security rules, set up the security profiles:
# Clone URL categoriesscm-clone url-categories --context folder --source "Security Profiles" --destination "Security Profiles" --commit-and-push
# Clone other security profilesscm-clone vulnerability-profiles --context folder --source "Security Profiles" --destination "Security Profiles" --commit-and-push
scm-clone wildfire-profiles --context folder --source "Security Profiles" --destination "Security Profiles" --commit-and-push
Step 5: Clone Security Rules
Now you can clone the security rules that reference all the objects and profiles:
Step 6: Clone NAT Rules
Clone NAT rules after security rules:
Step 7: Clone VPN Configurations
For VPN configurations:
# Clone IKE gatewaysscm-clone ike-gateways --context folder --source "VPN" --destination "VPN" --commit-and-push
# Clone IPsec crypto profilesscm-clone ipsec-crypto-profiles --context folder --source "VPN" --destination "VPN" --commit-and-push
Step 8: Clone SASE Configurations (if applicable)
If you're also migrating SASE configurations:
Step 8: Verify Migration
After completing all the cloning operations, verify that all objects were successfully created and committed in the destination tenant. Look for any errors in the console output or log files.
This comprehensive workflow ensures that objects are migrated in the correct dependency order, minimizing the risk of reference errors during the migration process.