Understanding Preconfiguration and Template Groups for Day 0 Deployment

Learn when to use an EdgeConnect preconfiguration file, when a template is required, and how templates and template groups work together during Day 0 deployment.

Scope: HPE Networking EdgeConnect SD-WAN and Orchestrator 9.6.3. Features introduced in Orchestrator 9.7 are identified as forward-looking.

Overview

Preconfiguration files, templates, and template groups are complementary mechanisms. They are not interchangeable, and a complete Day 0 deployment can require both preconfiguration and templates.

A preconfiguration file is applied to one appliance at a time. It can be created specifically for that appliance or reused as a standard deployment profile for appliances that share the same design. For example, an organization might use a Gold profile for large branches with three WAN and two LAN interfaces and a Silver profile for branches with two WAN and one LAN interface. When a reusable profile is used, appliance-specific values—such as hostname, site, IP addresses, bandwidth, licensing, and HA peer information—can be adjusted for each deployment.

The preconfiguration file can associate an appliance with template groups by listing their names under templateGroups.groups.

Important: The preconfiguration file does not support every appliance setting. Features such as QoS policies, security policies, access lists, user management, and optimization policies require templates. Create the required templates in a template group, then associate that group with the appliance.

Templates and template groups

A template configures one product feature. A template group packages selected templates under a name so that the configurations can be assigned to appliances together.

A group does not need to include every available template. For example:

• The Default Template Group can include User Management, DNS, SNMP, Date/Time, Banner Messages, Routes, Admin Distance, Access Lists, Shaper, CLI, and Session Management templates.
• A Security Template Group can contain only the Security Policies template.
• A Branch QoS Group can contain the QoS Policies and Shaper templates.

An appliance can be associated with multiple template groups. If multiple groups configure the same setting, Orchestrator uses template group priority to determine which value takes precedence.

yaml
templateGroups:
groups:
- Default Template Group
- Security Template Group

How they work together

The preconfiguration file carries appliance-specific settings and references the named template groups that Orchestrator should apply. Each template group contains the selected feature templates.

flowchart TD
    A[Define appliance-specific settings] --> B[Create preconfiguration YAML]

    C[Configure feature templates] --> D[Organize templates into named template groups]
    D -. Referenced by group name .-> B

    B --> E[Appliance connects to Orchestrator]
    E --> F[Discover and approve appliance]
    F --> G[Apply preconfiguration]
    G --> H[Apply referenced template groups]
    H --> I[Orchestrator continues enforcing template settings]

Core difference

Preconfiguration carries appliance-specific instances. Templates carry shared defaults, policies, and settings that Orchestrator centrally enforces.

Features available through both mechanisms

Ten features are configurable through both preconfiguration and templates in Orchestrator 9.6.3. This does not mean that the two mechanisms expose identical settings. In several cases, the template supplies common defaults while preconfiguration supplies appliance-specific instances.

Template-only fields within overlapping features

Even when a feature exists in preconfiguration, some settings can still require its template.

Preconfiguration-only fields within overlapping features

The following examples require preconfiguration even though a template exists for the broader feature:

• segmentBfdConfigs.enable
• VRRP group ID, virtual IP address, interface name, tracker, description, and packet-trace settings
• Static route entries under localRoutes.routes. and segmentLocalRoutes.routes.
• Most BGP neighbor fields
• OSPF areas and interface instances

Equivalent behavior with different field names

Some equivalent settings are represented differently:

Preconfiguration-only capabilities

Use preconfiguration for per-appliance identity, deployment, and feature instances that do not have equivalent templates.

Identity and association

Deployment and interfaces

Licensing, routing, and network services

Security, services, and other appliance settings

Template-only capabilities

The following features cannot be completed through preconfiguration. Create the appropriate templates and include them in one or more template groups.

General Settings

Networking

Policies

Certificates and overlays

Tools

Version and availability notes

When to use each mechanism

Caveats and interactions

Precedence

When preconfiguration and a template group configure the same feature, preconfiguration establishes the initial state. Orchestrator subsequently enforces template values according to template group priority.

Post-approval behavior

Most preconfiguration sections replace the existing configuration when reapplied. The following sections merge instead, preserving values not supplied in the file:

• businessIntentOverlays
• managementRoutes
• tunnelConfiguration
• pppoe

Don't apply

Some template controls support three states:

• true applies or enables the value.
• false clears or disables the value.
• none (Don't apply) preserves the existing appliance value.

Preconfiguration does not have an equivalent to Don't apply; supplied values are applied.

Routes are not a superset in either direction

The routes template controls automatic subnet advertisement and routes.ecmp_en, but it has no static route table. A deployment that needs ECMP and static routes must use both mechanisms:

• Use the routes template for ECMP and automatic-subnet settings.
• Use localRoutes.routes. or segmentLocalRoutes.routes. in preconfiguration for static routes.

Nested deployment sections

The following are children of deploymentInfo, not top-level preconfiguration sections:

• haConfig
• dhcpInfo
• dhcpInfo.dhcpHA
• DHCP relay settings within dhcpInfo
• raInfo

AppExpress groups

appExpressGroups associates existing AppExpress groups with an appliance. The groups must already exist in Orchestrator.

yaml
appExpressGroups:

- Alexa

Recommended Day 0 workflow

1. Identify which values are unique to each appliance and place them in its preconfiguration file.
2. Create feature templates for shared settings and policies.
3. Organize related templates into clearly named template groups, such as Default Template Group, Security Template Group, or Branch QoS Group.
4. Reference the required template groups under templateGroups.groups in the preconfiguration file.
5. Onboard and approve the appliance.
6. Confirm that template group priority produces the intended result for any overlapping configuration.

A successful deployment commonly uses both mechanisms: preconfiguration for appliance-specific Day 0 instances and template groups for shared settings and policies that Orchestrator must continue to enforce.