NSE5 Part 8: Workflow, Workspace Mode and Revision Control

NSE5 Part 8: Workflow, Workspace Mode and Revision Control

Part 8 of the NSE5 series. The locking and approval model is what turns FortiManager from a fancy CLI scripter into something you’d trust ten admins to share. The exam tests workspace modes, the lock states, the workflow state machine, and the recovery commands when an ADOM gets stuck.

Why workspace mode exists

Without workspace mode, two admins logged into the same ADOM can both edit the same policy package at the same time. Last write wins, the loser gets no warning. In a small shop this is fine — call across the office. In any larger team it’s a recipe for disaster.

Workspace mode adds ADOM-scoped locking. Before you can change anything in an ADOM, you have to take a lock. While you hold it, no one else can edit that ADOM. When you save, the lock releases.

config system global
    set workspace-mode normal
end

Three values for workspace-mode:

Mode	Behaviour
disabled	No locking. Anyone can edit anything. Default on a fresh FMG.
normal	ADOM-level locking. One admin at a time per ADOM. The everyday choice.
workflow	Locking plus a state-machine approval flow. Heavyweight; used in regulated environments.

Switching workspace mode requires a logout of all admins (the GUI prompts; the CLI doesn’t). Plan for the disruption.

Normal workspace mode — the lock states

Once normal is set, every ADOM has three possible states for an admin session:

• Unlocked — no one is editing. Any admin can take a lock to edit.
• Locked by you — you hold the lock. You can edit, save, install.
• Locked by someone else — view-only for you. You see who holds the lock.

Take a lock from the GUI banner (Lock ADOM) or via CLI:

diagnose dvm lock <adom-name>

Save (commits the lock changes to the ADOM database):

diagnose dvm save <adom-name>

Release without saving (discards):

diagnose dvm unlock <adom-name>

The exam tests the difference between save (commit and release) and unlock (release without saving). One of those throws away your work.

Stale locks

A lock held by a session that has died — admin closed their browser, network dropped, server restart — is a stale lock. It blocks every other admin from that ADOM until cleared.

The Super_User can force-unlock:

diagnose dvm unlock <adom-name>

Or, if the lock is held by a logged-in user who is unreachable:

diagnose dvm lock force-unlock <adom-name> <admin-user>

The exam will hand you “admin A locked the ADOM and went to lunch; admin B needs to deploy a fix” — answer: a Super_User force-unlocks. There is no time-based auto-release in normal mode (workflow mode has different semantics).

Workflow mode — the state machine

Workflow mode adds an explicit approval gate between editing and installing. Every change goes through:

1. Pending — admin opens a session, makes changes, submits for review.
2. Approved — a designated approver accepts the session.
3. Rejected — the approver rejects; the change goes back to the editor.
4. Discarded — abandoned; the database is unchanged.

The GUI surfaces this as a “session” — a named change set with a description, a list of edits, and an approval queue.

Configuration:

config system global
    set workspace-mode workflow
end

config system admin profile
    edit "approver-profile"
        set workflow-approve permit
        ...
    next
end

Two roles emerge:

• Editors — can take locks and submit sessions. Cannot self-approve.
• Approvers — can accept or reject sessions. Often editors too, but cannot approve their own.

Workflow mode is heavy and most production deployments don’t use it. The exam includes one or two questions on the state machine; learn the four states and the actor for each transition.

Revision history

Independent of workspace mode, FortiManager keeps a per-ADOM revision history. Two settings under System Settings → Advanced → Configuration Settings (and CLI):

config system global
    set adom-revision-max 25
    set adom-revision-auto-create-on-install enable
end

• adom-revision-max — how many revisions to keep before purging the oldest.
• adom-revision-auto-create-on-install — automatic snapshot before every install. Almost always on.

Revisions can be manually created, named, and locked (so they’re never auto-purged). Locking is how you keep the post-audit, pre-Christmas, or “known-good” snapshot for years.

diagnose dvm adom revision-list

Lists every revision per ADOM with its ID, name, lock state, and creation time. Roll back from the GUI (ADOM Revisions → right-click → Revert) — the CLI form is destructive and undocumented.

Workspace mode interaction with HA

Workspace mode is per-cluster, not per-unit. Locks are stored in the synchronised database, so a lock taken on the primary appears on the secondary. After failover (Part 3), the surviving primary still sees existing locks; clearing them is no different from any other admin operation.

A subtlety the exam tests: in the seconds between primary failure and admin promotion of the secondary, locks held by sessions on the dead primary are still in the database. They become stale on rejoin. Force-unlock them after promote.

Diagnostics

diagnose dvm lock list
diagnose dvm proc list
diagnose dvm adom revision-list

diagnose dvm lock list is the first command for any lock-related question. It shows every active lock with its ADOM, holder, and lock time.

For workflow mode:

diagnose dvm session list

Shows every pending, approved, rejected, and discarded session.

Common exam scenarios

• “Admin can edit objects but not save them in normal mode.” Saving requires the Save button or the explicit diagnose dvm save — closing the browser without saving discards.
• “Two-admin deadlock — both have changes pending in different ADOMs.” Not actually a deadlock; locks are per-ADOM, so both succeed. The exam may try to make this look like a problem when it isn’t.
• “Workflow session stuck in ‘pending’.” No approver assigned, or the approver’s profile lacks workflow-approve permit.
• “Revision count keeps growing past adom-revision-max.” Manually-locked revisions don’t count toward the cap. Find them and unlock if cleanup is needed.

Part 9 takes us to the diagnostic toolbox — diagnose commands, FGFM tunnel troubleshooting, install-failure forensics, and the OFTP / oftpd log feed.