NSE5 Part 6: Device-Level Configuration and Templates

28 April 2026 FortinetNSE5FortiManagerTemplatesSD-WANFCPCertification

NSE5 Part 6: Device-Level Configuration and Templates

Part 6 of the NSE5 series. Templates are how FortiManager scales — instead of clicking through fifty FortiGates to set the same NTP server, you assign one template to a group and install. The exam tests both the types of templates and the order in which they apply during install.

Why templates exist

Without templates, the FortiManager database stores every device’s config in full. Adding a new branch means cloning a sister site’s database and editing the IPs. With templates, the per-device database stores only what’s different from the templates — the device’s own IPs, hostname, and any local overrides. Everything that’s the same across the fleet (NTP, SNMP, syslog, DNS, admin profiles) lives in templates and applies in bulk.

This matters for the exam because template settings can be overridden per device, and the override behaviour depends on the template type. A common exam trick is “device has hostname A in its database and hostname B in a template — which gets installed?” — the answer depends on which template type set hostname.

Provisioning templates

The catch-all bucket. A provisioning template groups together a set of system-level settings — DNS, NTP, SNMP, log servers, admin settings, FortiGuard — and assigns them to one or more devices.

Path: Device Manager → Provisioning Templates → System Templates.

config pm devprof
    edit "branch-baseline"
        set scope-member <device-list>
        ...
    next
end

Each section (DNS, NTP, etc.) is independently enabled. A template that enables only the NTP block will not touch the device’s DNS — useful when you want different teams to own different baseline settings.

The exam asks: “if two provisioning templates assigned to the same device both set NTP, which wins?” Answer: the one assigned later in the device’s template list. There is no merge.

CLI templates

A CLI template is raw FortiOS CLI text rendered into the install with optional Jinja-style variable substitution. It’s the escape hatch — anything you can’t express through a GUI template you write here.

{# branch-edge.tmpl #}
config system snmp community
    edit 1
        set name "{{ snmp_community }}"
        config hosts
            edit 1
                set ip {{ snmp_host }}
            next
        end
    next
end

Variables come from the per-device Metadata Variables (Device Manager → right-click → Edit Metadata). The template engine substitutes at install time. If a variable is missing, the install fails with a metadata error — read the install preview every time.

CLI templates run after all GUI-driven config in the install. This is intentional: it lets you override anything earlier templates set. The exam will test this ordering.

CLI template groups

A CLI template group is just a list of CLI templates that get applied in sequence. Useful when you want a ‘baseline’ template plus a ‘site-type-A’ template plus a ‘temporary fix’ template, all without merging them into one giant file.

The order in the group is preserved during install. Earlier templates run first; later templates can override.

SD-WAN template

The single most-used template on a real FortiManager. An SD-WAN template defines:

  • The SD-WAN zones (named groupings of underlay interfaces).
  • The members (the underlay interfaces themselves).
  • The performance SLAs (probes — typically ping or HTTP — that measure each underlay).
  • The SD-WAN rules (which application/source/destination uses which member when an SLA is met).
config wanprof system sdwan
    edit "branch-sdwan"
        config zone
            edit "underlay"
                set service-sla-tie-break input-device
            next
        end
        config members
            edit 1
                set interface "wan1"
                set zone "underlay"
            next
            edit 2
                set interface "wan2"
                set zone "underlay"
            next
        end
        ...
    next
end

The SD-WAN template references interface names that must exist on every device it’s applied to. A common exam scenario: “template assigned to two devices, install fails on the second” — interface name mismatch (e.g., one device has wan1/wan2, the other has port1/port2).

The fix is meta-fields: define wan_a and wan_b as metadata variables per device, and reference {{ wan_a }} in the template. Same template, per-device interface names.

IPsec template

Used for hub-and-spoke or full-mesh IPsec deployments where every spoke has the same IPsec config differing only in remote IP and PSK.

config wanprof system vpn ipsec phase1-interface
    edit "to-hub"
        set interface "{{ underlay_iface }}"
        set remote-gw "{{ hub_ip }}"
        set psksecret "{{ ipsec_psk }}"
        ...
    next
end

IPsec template applies the Phase 1 + Phase 2 + tunnel interface in one shot. Per-device variables fill in the values the template can’t know.

Certificate template

A certificate template installs CA-signed certificates onto managed devices. It can:

  • Push a CA bundle to be trusted (e.g., your private root CA).
  • Push a server certificate for SSL VPN or admin GUI.
  • Trigger a SCEP enrolment so the FortiGate generates its own keypair and gets a cert from a SCEP server.

The SCEP path is the production-ready one — keys never leave the device. The exam tests the SCEP flow:

  1. FortiManager creates a SCEP enrolment request via the template.
  2. FortiGate generates a private key locally.
  3. FortiGate POSTs a CSR to the SCEP server.
  4. SCEP server signs and returns a cert.
  5. FortiGate installs the cert; FortiManager records that it’s done.

Template assignment scope

Templates are assigned to devices or device groups, not directly to ADOMs. A device is in exactly one ADOM but can be in multiple device groups. Same-named groups in different ADOMs are different objects.

config dvmdb group
    edit "branch-edges"
        set os-type fos
        set type normal
        set scope member <device-list>
    next
end

Assign a template to the group; every member inherits the template; new members of the group inherit on the next install.

The install order — exam-critical

When you click Install, the FortiManager renders the device’s effective config in this order:

  1. The device’s own device database (from registration / last retrieve).
  2. Provisioning templates in the order they appear on the device’s template list.
  3. SD-WAN template.
  4. IPsec template.
  5. Certificate template.
  6. CLI templates in their group order.
  7. Policy package (covered in Part 7).

Each step can override the prior. CLI templates run last so they can override anything; policy package install is a separate operation that runs after all of the above.

The exam will hand you a scenario like “device has hostname ‘old’ in its database; provisioning template sets hostname ‘new’; CLI template sets hostname ’{{ site_code }}-fw’” — the installed hostname is whatever the CLI template renders, because CLI runs last.

Diagnostics

diagnose dvm device list
diagnose dvm cdb check
get system status

For a template-specific check:

diagnose dvm proc list

dvm cdb check runs an integrity check across the configuration database — catches dangling references (a template assigned to a device that no longer exists) and a few other classes of corruption.

The most useful diagnostic for “install rendered the wrong config” is the install preview. Templates render at preview time, so you can see exactly what each template produced, in order, before committing.

Common exam scenarios

  • “SD-WAN template install fails on one of three devices.” Almost always interface name mismatch — solve with metadata variables.
  • “CLI template variable not substituted.” Variable not defined as metadata on the device.
  • “Provisioning template’s NTP server didn’t apply.” NTP block not enabled on the template, or a later template overrode it.
  • “Certificate keeps reverting after install.” Certificate template removed but cert still on device — install removes anything not in templates if auto-purge is enabled.

Part 7 covers the policy package — the ADOM-level firewall configuration that turns templates into actual security.