CliDeck
PlatformLog in
Workspace

FortiGate 7000E HA Status: Capture Members and Sync Before Maintenance

Runbooks
#fortigate#operational-evidence#runbooks#remote-operations#Runbooks
← Back to Blog

Short answer

On an authorized FortiGate 7000E HA cluster, collect get system ha status before maintenance and retain member identities, reported roles and configuration synchronization together. Read the individual sections rather than approving the entire cluster from “HA Health Status: OK.”

This is a baseline collection task. It does not trigger failover, reset a member or force synchronization, and it cannot replace the approved maintenance procedure.

When this guide applies

This guide targets the FortiGate 7000E synchronization view in FortiOS 7.4.8. Other FortiGate models, FortiOS releases, virtual clusters and chassis architectures can have different fields or maintenance requirements.

Confirm the exact model, build and cluster arrangement first. Do not transfer the 7000E chassis guidance to a small two-unit firewall pair without checking that platform's documentation. In a 7000E system, chassis and internal module synchronization require attention; a generic summary is not a complete module health inventory.

1. Define the expected membership

Before connecting, obtain the owner's expected chassis list, private physical identifiers, cluster context, maintenance objective and responsible engineer. Label the record as a pre-maintenance snapshot.

Use an authorized administrative CLI session with visibility into the cluster status. Collect:

get system ha status

Record the collection time, the unit or cluster session used, exact installed build and the complete returned output. If permissions or session context hide information, document that limitation.

Do not paste real serial numbers, group names, hostnames or operational addresses into a public report. Keep the original private and use stable sanitized identifiers in a handoff. The same sanitized identity must refer to the same chassis throughout the record.

2. Match identities before interpreting roles

Compare the reported member identities with the expected chassis list. Associate the Primary and Secondary lines with those identities. A remembered hostname or the place a unit occupies in the rack is not a substitute for that mapping.

Preserve the primary-selection explanation if present. It describes the reported election context; it is not an instruction to change priority or override settings.

If a member is missing, unexpected or cannot be mapped confidently, stop the maintenance handoff at that uncertainty. Do not reset or remove a member to make the listing match expectations.

3. Check synchronization separately

Inspect Configuration Status for every expected chassis. Retain in-sync or out-of-sync text, update ages and the reported checksum information.

Matching configuration checksums are part of the 7000E synchronization evidence. Preserve both the member state and checksum context; do not compare snippets from different collection times as though they were one consistent snapshot.

A health heading does not erase an out-of-sync member. Review each section independently, keeping apparent agreement and discrepancies visible. Nor does configuration synchronization prove that all application sessions, heartbeat paths or hardware components meet the maintenance acceptance criteria.

If status is changing, collect a bounded second snapshot with its own timestamp. Do not repeatedly poll until one favorable result can be presented as the whole history.

4. Handle an incomplete baseline

For out-of-sync output, missing members or conflicting identities, preserve the evidence and refer the next diagnostic action to the cluster owner. This article does not prescribe daemon restarts, forced synchronization or a factory reset as a generic remedy.

A planned failover needs its own approved procedure, coverage and service verification. Configuration synchronization is not a substitute for a demonstrated failover outcome. Likewise, wiping an HA pair for resale is a separate decommissioning workflow, not a repair for a live cluster.

Keep the approved backup workflow separate from this status snapshot. Having a status transcript does not mean a usable recovery backup exists.

Verification note: maintenance handoff criteria

Accept the baseline when each expected chassis is accounted for, roles are mapped to identities, and synchronization states and update context are preserved. Unresolved missing members or synchronization discrepancies must remain explicit.

Store the private transcript and checklist in CliDeck Workspace. The collection verifies that the baseline is reviewable; it does not claim a completed maintenance action, a tested cluster or guaranteed failover.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on SSH, serial, browser terminal, and infrastructure operations workflows.

When to use this

Use this guide when:

  • Several commands or checks must be repeated safely.
  • Another engineer, customer, onsite technician, or vendor may need context.
  • The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Workflow

  • Define the purpose, target device, access path, and approved scope.
  • Run read-only checks first and record the expected healthy state.
  • Execute commands from the runbook or handoff plan while watching for stop conditions.
  • Verify the final state with independent checks.
  • Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides