The Forescout Bible

This manual is written for the engineer who runs Forescout in production: the one who gets the page when a plugin stops, who has to explain a license count to finance, and who has to defend a policy change in front of a change board. It is not a product overview. It assumes you can log into the Console and the CLI, and it focuses on what the documentation does not say out loud.

Captured, Discovered, Guessed

Every statement an engineer makes about a Forescout system belongs in one of three buckets. Know which bucket you are in before you say it.

Conventions

• Where it runs. Every command states where it runs: the Enterprise Manager (EM) or a named appliance. Default is the EM. Some commands are dangerous on the wrong box.
• Paths. The product root is /usr/local/forescout. Logs live under /usr/local/forescout/log, plugin code under /usr/local/forescout/plugin.
• Plugin names. Console names and on-disk names differ. Switch is sw, HPS Inspection Engine is va, NBT Scanner is nbtscan_plugin, Advanced Directory is ad, Hardware Inventory is hwi.
• Box colors. Green is a field rule. Amber is a warning. Red is a hard stop. Blue is a field story with the customer stripped out.
• Counting. Count with | wc -l. Compute rates from the epoch inside each record, never from the number of rotated files.

1.1 The pieces

1.2 Mental model one: the host object

Everything in Forescout hangs off a host object, keyed primarily by IP address, with MAC as a strongly linked attribute. Plugins write properties onto the host object. Policy reads those properties and decides. Actions change the world, and the world feeds new properties back. If you remember one thing, remember this loop.

1.3 Mental model two: properties arrive late

Classification is asynchronous. The DHCP classifier might answer in a second, the NIC vendor lookup instantly, HPS in a minute, and an integration whenever its API replies. Policy evaluates on whatever is present at the moment. A rule that depends on three properties can match differently at second 5 than at minute 5. Most "Forescout put my device in the wrong place" tickets are timing tickets.

1.4 Mental model three: the appliance that manages it

Two different appliances can be involved in one endpoint: the appliance that manages the host (by IP range) and the appliance that manages the switch the host is plugged into. Switch-driven evidence, switch debug, and switch tech support always come from the appliance listed as Managed By for the switch. Host evidence comes from the appliance that owns the host's IP. Mixing them up is the single most common reason an evidence bundle is useless to engineering.

1.5 Mental model four: licensing counts IP host entities

A device consumes a license once the platform sees it with an IP. When a device changes segment and gets a new address, it briefly holds two: the old one stays until the purge timer clears it. The license engine counts surviving IP host entities per license and the EM sums what the appliances report. There is no stored "IP to license" map you can query. Every row in a host export is a used license.

1.6 Mental model five: configuration applies are fleet events

Saving certain configuration in the Console restarts plugins on every affected appliance at the same second. When you see the same event on every appliance in a region within one second, you are looking at a configuration apply or a service restart from the EM, not a coincidence and not a crash.

1.7 The on-disk map

# Product root on an EM or appliance
/usr/local/forescout/
├── log/        all runtime logging (world-writable, often the largest consumer on the box)
│   ├── plugin/     per-plugin logs (list before you name a file)
│   ├── daemon/     core service supervision
│   ├── heart-beat/ appliance-to-EM connectivity
│   ├── install/    upgrade and plugin installs
│   ├── jstats/     JVM health
│   ├── pg_log/     Postgres
│   ├── tomcat/     web console
│   ├── rabbitmq/   message bus
│   └── stall-snapshot/  thread dumps at hang time
├── plugin/     installed plugin code and config (sw, dot1x, va, ad, hwi, ...)
├── db/         Postgres data, postgres:postgres 0700, never read directly
├── etc/        product configuration, local.properties override file
├── backup/ restore/ rollback/ upgrade/   lifecycle
└── policy/ reports/ stats/ telemetry/    product output

Ownership is a diagnostic

• _fsservice owns what the running product writes. Root-owned files appearing there usually mean someone ran something as root that should not have.
• root owns installer and platform content. It should not change in normal operation.
• postgres owns the database and its log. tomcat5 owns the web console. rabbitmq owns the message bus logs.

1.8 Chapter checklist

• You can name, for any host, the appliance managing the host and the appliance managing its switch.
• You know which plugins are installed, which are running, and which are licensed, and you know those are three different lists.
• You treat any fleet-wide same-second event as a configuration apply until proven otherwise.

2.1 Placement principles

• Close to the traffic. Appliances need to see the traffic for the ranges they own: a SPAN or tap feed, or a packet broker. Without monitor traffic you lose the packet engine's discovery and much of the passive classification.
• Close to the switches they manage. SNMP and CLI polling across a WAN with high latency inflates every read cycle and invites timeouts.
• One owner per IP. Every IP range belongs to exactly one appliance. Overlaps create duplicate host objects and arguments between appliances.
• The EM is not a worker. Do not plan on the EM to manage switches or run the packet engine.

2.2 Sizing dimensions

2.3 License headroom

The EM recalculates license usage on a fixed cadence (the counter interval defaults to ten minutes). If usage crosses capacity on any cycle, a capacity email goes out, one per license type over the limit. Usage naturally bounces: devices change segment and briefly hold two IPs, guests arrive in a burst, a lab spins up. Running within one percent of capacity guarantees noisy emails.

• Plan for at least five percent headroom on every license type.
• Exclude infrastructure that should never count (gateway addresses, virtual router addresses, management networks you do not control) through the supported exclusion mechanisms, not by editing tables.
• Tune the purge timers for stale hosts so departed devices stop counting in a reasonable time.

2.4 Segment Manager design

Build the Segment Manager tree to mirror how people reason about the network: region, site, function. Policy scope, reporting, and troubleshooting all lean on it. Segment names that encode function (vendor, voice, facilities, isolation) become classification signals of their own when other evidence is thin.

2.5 Deployment checklist

• Every IP range has exactly one owning appliance, and the map is documented.
• Every appliance receives monitor traffic for the ranges it owns, verified by packet engine counters.
• Switch assignments are balanced by workload, not only by count.
• License headroom is at least five percent per license type, with exclusions documented.
• Recovery EM and HA decisions are made and written down before go-live.

3.1 The morning check

1. Appliance status. Every appliance connected to the EM, no red. A disconnected appliance means its hosts are on autopilot.
2. Plugin health. Any plugin stopped or restarted overnight. Note it, then classify it (Chapter 7 for Switch).
3. Disk. Log filesystem below threshold on every node. A full log filesystem takes the product down.
4. License usage. Current usage against capacity per license type, and the trend.
5. Isolation population. Count of hosts in the isolation or pre-admission segment compared with yesterday. A jump is the earliest symptom of a classification or certificate problem.
6. Overnight email. Capacity, plugin health, and policy notification mail, read rather than filed.

# On each node: disk on the log mount
df -h /usr/local/forescout/log

# Where the log weight is
du -sh /usr/local/forescout/log/* | sort -h | tail -20

# What was written in the last two hours (scoped, never grep -r the whole tree)
find /usr/local/forescout/log -maxdepth 3 -type f -mmin -120 \
     -printf '%TY-%Tm-%Td %TH:%TM %10s %p\n' | sort

3.2 Running a command across the fleet

fstool oneach runs a command from the EM on every appliance. It has no appliance filter, so filter the output with grep afterwards. Pipes pass through when the whole command is quoted. Some environments break the -c form; the quoted form is the safe default.

# EM: same check on every appliance
fstool oneach 'df -h /usr/local/forescout/log | tail -1'

3.3 Weekly sweep

• Plugin restart counts per appliance for the week, classified by cause.
• Top unknown and unclassified device types, with OUI breakdown.
• Policy match counts for enforcement rules: anything that jumped or dropped to zero.
• Pending module and content updates (DPL, NIC vendor database, plugin versions).
• Certificate expirations inside 90 days (Chapter 9).
• Backup job success and the age of the newest good backup (Chapter 14).

3.4 Properties and overrides

Many behaviors are controlled by properties. The supported way to read and change them on a node is the property tooling, which reads and writes the local override file in /usr/local/forescout/etc/local.properties.

fstool get_property <key>
fstool set_property <key> <value>
fstool remove_property <key>

3.5 Leading indicators

4.1 Discovery sources

4.2 Which signals to trust

1. Cryptographic identity. A valid certificate from a trusted issuer (EAP-TLS) is the strongest signal you will get.
2. Authoritative integration. EDR or MDM presence, CMDB ownership, directory membership.
3. OUI. Strong only when a given OUI maps exclusively to one device type in your fleet. Many vendors build both phones and laptops, and ODM manufacturers build for everyone.
4. DHCP fingerprint and hostname conventions. Useful, spoofable, and great as a second signal.
5. Function and OS from passive classification. Helpful context. Not reliable enough to enforce on alone.

4.3 Unknowns are a population, not a pile

Treat unclassified devices as a dataset. Export them, group by OUI, and you will usually find that a handful of OUI blocks explain most of the unknowns. Those are often corporate hardware built by an ODM whose vendor string the NIC database does not map well. Fix the biggest block first with a classification rule tied to a second signal, then move to the next.

# Normalize MACs before comparing exports: strip delimiters, lowercase, 12 hex chars
python3 -c "import re,sys; [print(re.sub(r'[^0-9a-f]','',l.lower())[:12]) for l in sys.stdin]" < macs.txt

4.4 DPL and NIC vendor database risk

Content updates to the Device Profile Library and the NIC vendor database can change the vendor string returned for an OUI. Any policy condition that matches on the old string silently stops matching. Devices that relied on that condition fall through to the next sub-rule, and sometimes into isolation.

# Find policy content that references a vendor string before you accept an update
grep -rl -i "<vendor string>" /usr/local/forescout/policy/

4.5 Classification checklist

• Top ten unknown OUI blocks identified and owned.
• No enforcement rule depends on a single spoofable property.
• Vendor-string conditions inventoried and rechecked after every DPL or NIC database update.
• Isolation population trended daily as the canary for classification health.

5.1 Anatomy

A policy has a scope (which hosts it considers), a main rule, and ordered sub-rules. Each sub-rule has conditions and actions. Within a policy, sub-rules evaluate top down and the first match wins. Across policies, every policy in scope evaluates independently, so one host can match many policies at once.

5.2 A numbering scheme that scales

The scheme matters because it makes dependency direction obvious: lower tiers produce groups, higher tiers consume them. A higher tier never writes a group a lower tier depends on.

5.3 Ordering is architecture

5.4 Rescue rules

Rescue rules move legitimate devices out of isolation when normal classification fails. They are powerful and fragile. A rescue rule that requires an operating system match plus directory membership will silently stop rescuing devices if a content update changes how the OS is detected. Monitor rescue rule match counts. A drop to zero is an incident.

5.5 Walking a policy

A policy walk traces one real device through the policy tree, sub-rule by sub-rule, with evidence at each step. It is the most valuable document a resident engineer produces because it turns "the policy is wrong" into "sub-rule 3.2.x matched because property Y was Z."

Fact panel for every walk

1. Fill the fact panel from live evidence, not from memory.
2. For each policy in scope, list sub-rules in order and mark which matched and why.
3. Note the groups each match produced and which later policies consumed them.
4. End with the final state: groups, labels, segment, and any CoA sent.
5. Recommend the smallest change that produces the correct outcome, and the walk that proves it.

5.6 Testing policy changes

• Clone to a test policy scoped to a lab range or a handful of hosts.
• Start with actions disabled or notify-only and watch match counts.
• Use fstool trace_ip to capture decision detail for named hosts while you test (Chapter 10).
• Promote with a rollback plan: the exported previous policy and the exact steps to restore it.

6.1 The connection timeline

6.2 Pre-admission lives in the RADIUS plugin

Pre-admission rules are configured in the 802.1X (RADIUS) plugin configuration, not in Policy Manager. They run before a host object exists, using only what RADIUS knows: MAC, certificate attributes, NAS details, and the MAC Authentication Repository (MAR). They are evaluated top down, first match wins, same as policy.

6.3 MAB and the MAR

MAC Authentication Bypass sends the MAC as the identity. The plugin checks the MAR for that MAC and returns the target VLAN if a valid entry exists. If none exists, the device lands in the pre-admission or isolation VLAN, policy evaluates, and on success the MAR entry is written so the next connection goes straight to the right place.

6.4 EAP-TLS

The switch relays EAP. The plugin validates the client certificate chain against its trust store and checks revocation if configured. A valid certificate drives the VLAN through pre-admission. Common failures:

• Issuer not trusted. Firmware updates on cameras and IoT devices can switch them from MAB back to 802.1X with a factory device certificate whose issuer you never trusted. MAB-only on that port is the clean fix.
• Fragmentation through a load balancer. EAP-TLS packets fragment. Non-initial UDP fragments carry no port information, so a source-IP load balancer can route the fragments of one handshake to different servers. MAB keeps working, EAP-TLS fails. Fix the balancer persistence or path, not Forescout.
• MTU on the path. Small path MTU extends the handshake. Some supplicants tolerate it, others time out.
• Cipher list. The plugin regenerates FreeRADIUS configuration from templates on restart. Edits to generated files revert. Changes belong in the source templates under /usr/local/forescout/plugin/dot1x/fr_config/modules/ (the eap_fs_template files), under change control.

6.5 The MAB then EAP race

Ports configured for both methods often run MAB first because it is fast. MAB lands the device in isolation, then EAP-TLS completes seconds later and reauthorizes to the correct segment. To the user it looks like a slow login. To the license count it looks like two IPs. To a monitoring tool it looks like a device flapping. It is normal behavior, and the size of the gap is the thing to watch.

6.6 CoA

• CoA fires when an enforcement action changes the segment, when the MAR target changes, or on a manual trigger.
• CoA does not fire for label changes or for group changes that hit no enforcement rule.
• Every CoA can cause a new DHCP lease and a second license entry until purge.

6.7 Where to look

# On the authenticating appliance. List the folder first; file names vary by version.
ls -lh /usr/local/forescout/log/plugin/dot1x/

# Auth events for one device (MAC in this log is dash separated, uppercase)
grep "00-11-22-33-44-55" /usr/local/forescout/log/plugin/dot1x/dot1x.log | tail -50

# Deeper debug for a reproduction, then put it back
fstool 802.1x debug 10

7.1 How it works

The Switch Plugin (sw) manages switches over SNMP and CLI. It reads MAC tables, ARP tables, interface descriptions, and neighbor data on a schedule (the read cycle), and it also reacts to SNMP traps such as MAC learn and link events. It can write: assign VLANs, apply ACLs, block ports.

• Multi process mode. A parent forks N children that share the switch workload. Children are forked, so they do not show up as separately named processes in ps, which makes the subprocess setting look like it does nothing. The watchdog log line reporting the child count is the proof it took effect.
• Log prefixes. Parent lines carry sw:, children sw-1: through sw-N:. Count both and you inflate every figure by the number of processes.
• Child memory ceiling. Each child runs under a memory limit. A child that needs one allocation past the ceiling dies with out of memory even though it is not leaking.

7.2 Where the evidence lives

# Plugin install home: code, vendor tables, properties
/usr/local/forescout/plugin/sw/
   device_table.xml, device_profile_table.xml, ...   # vendor recognition, do not hand edit
   advanced_flags.properties, local.properties      # supported tuning points, restart required
   install.properties<epoch>                        # install history, convert with date -d @epoch

# Logs: list first, never assume a file name
ls -lh /usr/local/forescout/log/plugin/sw/
ls -lh /usr/local/forescout/log/daemon/           # daemon supervision, plugin start and stop
ls -lh /usr/local/forescout/log/ | grep -i watchdog

find /usr/local/forescout/log/plugin/sw -type f -mmin -60 -print0 | \
  xargs -0 grep -h "pattern" | wc -l

7.3 Crash or shutdown

The Plugin Health alert says "crashed" for every stop. The logs separate them:

7.4 Fabric switches: VXLAN, MLAG, anycast

The Switch Plugin was designed around classic access switching. Modern fabrics break several of its assumptions.

• Flood and learn VXLAN. Every VTEP learns every MAC over the VXLAN interface and every one sends a learn trap. One device yields one trap per chassis in the VNI.
• Bridge port versus ifIndex. A MAC learn trap carries a bridge port number. If that number is used directly as an interface index without conversion, the port name is wrong. On chassis numbering, a VXLAN bridge port can collide with the index of a real Ethernet port, so a "don't learn" rule on the VXLAN interface name never matches the trap.
• MLAG without port channels. Dual homed servers without a port channel cause MAC move storms that can reach hundreds of thousands of events an hour.
• Anycast gateways and shared addresses. Many switches advertise the same addresses through neighbor protocols. The plugin cannot hold a stable view of the switch and keeps reassigning interface addresses, which drives restarts.
• Per-port neighbor sweeps. Some vendor integrations run a neighbor query per occupied port or per powered port on every read cycle and every trap. On a big chassis that is a lot of CLI work and memory.

7.5 Tuning levers

• Ignored MACs. Exclude virtual router MAC patterns (HSRP, VRRP) so gateway churn never reaches policy.
• Don't learn on port names. Exclude VXLAN interfaces, MLAG peer links, and uplinks from learning in the read cycle.
• Trap handling. On fabric switches, consider running with trap handling off and relying on the read cycle.
• Read intervals. Faster MAC reads improve freshness and cost load. Pick per template, per vendor.
• Switch assignment. Spread heavy switches across appliances. Remove unreachable switches that time out every cycle.
• Write permissions. If a switch template does not enforce, leave write actions and ACL off so those code paths never run.

7.6 Engineering evidence for a Switch Plugin case

# On the APPLIANCE that manages the switch (Managed By column). Never on the EM.
fstool sw debug 5
# reproduce the problem
fstool sw debug 0
fstool tech-support -t <window> -p sw --define snmpwalk==<switch IP>

8.1 Two directions

8.2 Priority order

1. SIEM out. Cheap, low risk, and it puts device context in front of the SOC immediately.
2. EDR in. "Managed corporate endpoint without a healthy agent" is the highest value compliance rule most organizations can write.
3. CMDB or asset inventory in. Ownership turns an unknown device into a ticket with a name on it.
4. ITSM out. Compliance failures become tracked work instead of console noise.
5. Firewall tags out. Device-type aware rules at the perimeter and between segments.
6. Automated response. Last, after the data has proven trustworthy.

8.3 Plugin map

On disk, integration and export code lives in plugins such as syslog, cef, splunk, datapublisher, datareceiver, webapi, adminapi, pxgrid, and connect_module (the framework that runs eyeExtend Connect apps). Each has its own log folder under /usr/local/forescout/log/plugin/. List it before you go hunting.

8.4 eyeExtend Connect apps

Connect apps are packaged integrations: configuration, property definitions, and scripts that the framework runs on a schedule or on demand. They extend the platform to products without a native module.

• Review the scripts before importing any app. It runs inside your platform with your credentials.
• Use a dedicated, least-privilege service account per integration.
• Respect the remote API's rate limits. Polling every host every minute is how integrations get throttled or banned.
• Version the app package and keep the previous one for rollback.

8.5 Failure design

• Monitor integration freshness: the age of the newest successful poll.
• Alert on credential expiry and certificate expiry for every connected service.
• Keep integration logs at normal levels in production. Raise them only for a reproduction window.

8.6 Integration checklist

• Each integration has an owner, a service account, a credential expiry date, and a rollback package.
• Each consuming policy has a defined behavior for "data unavailable."
• Outbound data is filtered to what the receiver needs. No dumping every property to every tool.
• Automated response actions are reversible and logged.

9.1 Certificate inventory

9.2 Inspecting the Java trust store (read only)

# EM: list trusted roots in the bundled JRE store. changeit is the Java default store password.
keytool -list -v -keystore /usr/local/forescout/java/jre/lib/security/cacerts \
        -storepass changeit | grep -i "^Owner" | grep -i "<ca name>"

# OS bundle, for comparison
grep -i "<ca name>" /etc/pki/tls/certs/ca-bundle.crt | wc -l

9.3 TLS inspection and outbound services

When outbound traffic passes a TLS inspecting proxy, the proxy presents its own certificate. The product's Java trust store will not trust it, and some services will not negotiate through inspection at all. Ask for an inspection bypass for the specific destination and port rather than importing the enterprise inspection CA into the product.

9.4 Renewal runbook

1. Inventory every certificate with expiry, issuer, and where it is installed.
2. Ninety days out: request the replacement with the same names and the right key usage.
3. For the 802.1X server certificate, confirm supplicants trust the new issuer chain before the swap. If supplicants pin the old chain, a swap fails every EAP login.
4. Install through the Console during a window, verify a test EAP-TLS login on every authenticating appliance, then close.
5. Update the inventory with the new expiry date.

9.5 Identity sources

• Directory (ad plugin). Group membership drives many classification and compliance rules. Directory outages make those properties irresolvable. Plan the fallback.
• Certificates. Subject and SAN attributes from client certificates can drive segment selection directly at pre-admission.
• Console users. Prefer directory-backed Console accounts with role-based scopes over shared local accounts (Chapter 15).

10.1 Access

On 8.2.2 and later, root SSH password login is disabled by default on new installs. It is enabled per node from the CLI admin account, which prompts for the CLI admin password and then the shell password.

# As cliadmin, per node
fstool cli ssh_root_password_login enable
shell
passwd
# When the work is done
fstool cli ssh_root_password_login disable

10.2 Core commands

10.3 Debug levels by plugin

10.4 Evidence packages by problem type

Switch Plugin

• Debug 5 on the appliance that manages the switch, reproduce, debug 0.
• fstool tech-support -t <window> -p sw --define snmpwalk==<switch IP> to embed the switch walk.
• For VLAN or ACL failures: switch configuration tab screenshots, the error, host log, hostinfo from both appliances, switch IP and port, running configuration.

Performance, instability, crashes

• fstool tech-support --pack then fstool tech-support diag <bundle>. Send both the bundle and the .diag directory.

802.1X

• Guided debug session on the authenticating appliance, reproduce in a second session, stop and collect. For captive web portal problems, collect from both the authenticating appliance and the appliance managing the endpoint.

Policy mismatch

• Tech support over the window, the host log, the policy export, hostinfo, and a trace_ip capture covering the reproduction.

License

• fstool check_license, fstool rms_license_info, fstool get_machine_locking_id, licensing trace categories raised in /usr/local/forescout/etc/fstrace.properties during collection and returned afterwards.

HA

• fstool ha status, sync interface counters read twice, fstool ethset, fstool ha_snapshot on each node, plus system messages and kernel log, which tech support does not include. fstool ifcount breaks the SSH session on exit.

10.5 Moving evidence off the box

• Bundles land in /tmp or /tmp/snapshot. List before you copy so a wildcard does not concatenate two bundles.
• In restricted environments, pull appliance bundles to the EM over SSH, then move them off through the EM's approved path.
• The CLI --send option uploads directly to the vendor snapshot service over TLS 443. Confirm the firewall and inspection policy allow it before relying on it.

10.6 Reading logs well

• Convert epochs: date -d @<epoch>.
• Read the minutes before the failure, not the failure line. The last error is the last domino.
• Never attribute a slow node's cause from a keyword slice. Read the full block and find the dominant phase by timestamp deltas.
• Compute rates from record timestamps. Rotation is volume driven, so files per hour means nothing.
• Match the measurement window to the change. A sixty minute window after a ten minute fix still contains the broken minutes.

11.1 Ground rules

• The database directory is owned by postgres with mode 0700. Do not browse it.
• Read with psql on the EM as root, with the pager off.
• Read only. Direct inserts and updates are unsupported. The EM caches much of this state in memory and will not see, or will overwrite, what you change.

# EM: read only query with pager off
psql -P pager=off -c "select field_name, count(*) from devinfo group by field_name order by 2 desc limit 25;"

11.2 Useful structures

11.3 Growth and maintenance

Host history, property history, and plugin data grow without bound unless retention is managed. A bloated database slows policy evaluation, slows the Console, and lengthens upgrades and restores.

• Trend database size monthly from log/pg_log and filesystem usage.
• Set host purge and history retention to what audits actually require, not "forever."
• Schedule database maintenance in windows like patching. Large restores and rebuilds can take hours on big tables, and the slow phase is often not the one you expect.

11.4 Reporting that holds up

• State the snapshot time. The Console, the license cache, and an email were each taken at a different moment and will differ by a few devices. Say which one you used.
• Dedupe by normalized MAC when comparing exports from different sources.
• Beware spreadsheet formula injection. Switch alias and description fields can start with = or +. Strip or escape before saving to Excel.
• Trend, do not snapshot. A single license number means little; the seven day high and the margin to capacity mean a lot.

Reports leadership actually reads

1. Endpoint count by segment and type, with week over week change.
2. Unknown and isolated device population with top OUI blocks.
3. Compliance pass rate for managed endpoints (agent present and healthy).
4. License usage against capacity with headroom.
5. Platform health: plugin stops by cause, appliance availability.

13.1 Three kinds of change

13.2 Sequencing

1. Lab first. Same version path, same plugins, representative switches and policies.
2. Backup and baseline. Fresh backup, policy export, plugin configuration screenshots, and a baseline of counts: hosts per segment, isolation population, plugin restarts, license usage.
3. EM first, then appliances. Upgrade the Enterprise Manager, confirm health, then appliances in waves, smallest and least critical first.
4. Hold between waves. Long enough to see a full read cycle, a morning login surge, and a recheck cycle.
5. Compare against baseline. Same counts, same health. Investigate every difference before the next wave.

13.3 Reading install history from the box

Nodes stamp install and patch events into names using Unix epoch seconds: additional<epoch> directories under the product root and install.properties<epoch> snapshots in plugin folders. On a box with no change record, these reconstruct the timeline.

# Switch Plugin install history
for f in /usr/local/forescout/plugin/sw/install.properties[0-9]*; do
  printf '%s  ->  ' "$f"; date -d "@${f##*install.properties}"
done

# What did the last upgrade change in the plugin's install state?
diff /usr/local/forescout/plugin/sw/install.properties<newest_epoch> \
     /usr/local/forescout/plugin/sw/install.properties

# Install and upgrade logs
ls -lh /usr/local/forescout/log/install/

13.4 What upgrades overwrite

• Shipped vendor tables in plugin folders (for example the Switch Plugin device_*_table.xml set) are replaced. Local edits there are lost silently and can break model detection. Do not hand edit them.
• Supported tuning lives in the plugin's advanced_flags.properties and local.properties and in the node's etc/local.properties. Record every override before an upgrade and verify each one after.
• Generated service configuration (FreeRADIUS, for example) is rebuilt from templates.

13.5 Content updates

13.6 Upgrade readiness checklist

• Release notes read for the platform and every plugin that changes, with behavior changes listed.
• Lab upgrade completed with the same path and plugin set.
• Fresh backup verified restorable, policy exported, overrides recorded.
• Baseline counts captured.
• Rollback plan written, including what the rollback directory covers and what it does not.
• Change window long enough for the slowest node, including database migration time.

13.7 Hardware lifecycle

• Track appliance model support dates and plan replacements a budget cycle ahead.
• Out of band management (iDRAC or equivalent) on every appliance, documented and reachable. You will need it the day a node does not come back from a reboot.
• Replacement nodes are built to the same version first, then joined.

14.1 Failure behavior by component

14.2 Backups

• Scheduled system backups on the EM and appliances, stored off box. The local backup directory is a staging area, not a backup strategy.
• Component backup jobs log under log/component_backup. Alert on failure, not only success.
• Keep backups from before every upgrade until the next one is proven.
• Export policy and plugin configuration separately as human-readable references.

14.3 Recovery EM and HA

• Recovery EM protects central management. Document the failover and failback steps, who may trigger them, and how licensing behaves on the standby (the machine locking ID differs).
• HA pairs protect a single node. Sync links use straight-through cabling, and both nodes must stay on the same version. HA does not protect against a bad configuration push.
• Test both. An untested failover tends to fail the first time it is needed.

14.4 Recovery runbook skeleton

1. Stabilize. Confirm what is actually down, from the CLI, not the Console.
2. Protect evidence. Collect a tech support bundle before restarting anything, if the node can still produce one.
3. Check the basics. Disk, memory, services, network path, certificates.
4. Restore service. Restart the smallest component that fixes it. Escalate to node reboot, then failover, then restore, in that order.
5. Verify. Hosts per segment, isolation population, authentications succeeding, plugin running.
6. Write it down. Timeline from log epochs, cause, fix, and the change that prevents it.

14.5 Continuity drills

• Annual RADIUS dead-server test on a representative switch.
• Semiannual backup restore into the lab, timed.
• Recovery EM failover and failback exercised in a window.
• Out of band access to every node verified quarterly.

15.1 The platform is a crown jewel

Forescout can move any port to any VLAN, read directory groups, hold integration credentials for your EDR and ITSM, and see every device. Protect it like a domain controller.

• Management interfaces on a management network only, reachable from jump hosts.
• Root SSH disabled when not in use. Enable it per node for a task and disable it after.
• CLI user management through the supported tooling (fstool cli adduser with its add, del, list, faillock, and session subcommands), not by editing system files.
• Console accounts directory backed, role based, and scoped to the segments each team owns.
• Integration service accounts least privilege, unique per integration, and rotated.
• Vulnerability checks run against the platform itself when a new advisory lands: confirm whether the affected component is even installed before raising alarms.

# Example exposure check: is a component installed or running at all?
rpm -qa | grep -i <component>
ps -ef | grep -i <component> | grep -v grep

15.2 Audit

• Use the Console audit trail for who changed what and when, and export it on a schedule to the SIEM.
• Correlate configuration applies with plugin restarts. Fleet-wide same-second restarts should always map to an audit entry.
• Keep change records that reference the audit entry, the before value, and the after value.

15.3 Change control that works

1. Read before write. Record the current value of anything you will change.
2. Lab proof. Same change on a lab node first, with result and side effects noted.
3. Blast radius. Name every appliance and service that restarts as a result. Saving a switch's settings restarts the Switch Plugin on the appliance managing that switch.
4. Rollback. Exact steps and exact values, written before execution.
5. Verification. Measurable success criteria and the window you will measure over.
6. Record. Execution record with timestamps from the logs, not from memory.

15.4 Writing standards

• Evidence first. Every claim cites its source: command, node, file, time. Captured, Discovered, or Guessed.
• One page answers. Lead with the conclusion and the ask, then the evidence.
• Names are facts. Never fabricate a person, a case number, a hostname, or a version. If it is unknown, say unknown.
• Commands state where they run. EM or a named appliance, every time.
• Electronic signatures. Formal records close with an /s/ signature block and date.
• Strip before sharing. Anything leaving the engagement loses customer names, hostnames, addresses, credentials, and case numbers.

15.5 The document set every deployment needs

# ---------- ORIENTATION (any node) ----------
df -h /usr/local/forescout/log
du -sh /usr/local/forescout/log/* | sort -h | tail -20
find /usr/local/forescout/log -maxdepth 3 -type f -mmin -120 -printf '%TY-%Tm-%Td %TH:%TM %10s %p\n' | sort
ls -lh /usr/local/forescout/plugin/
ls -lh /usr/local/forescout/log/plugin/<plugin>/
date -d @<epoch>

# ---------- FLEET (EM) ----------
fstool oneach '<command | with pipes>'          # filter output with grep afterwards

# ---------- HOSTS (appliance managing the host) ----------
fstool hostinfo <ip>
fstool trace_ip start ip_list "a;b;" mac_list "x;y;"
fstool trace_ip stop

# ---------- SWITCH PLUGIN (appliance managing the switch, NEVER the EM) ----------
fstool sw debug 5   # reproduce
fstool sw debug 0
fstool tech-support -t <window> -p sw --define snmpwalk==<switch IP>

# ---------- 802.1X (authenticating appliance) ----------
fstool tech-support --debug-session i -p dot1x
fstool 802.1x debug 10
grep "AA-BB-CC-DD-EE-FF" /usr/local/forescout/log/plugin/dot1x/dot1x.log | tail -50

# ---------- HPS (appliance) ----------
fstool va debug 5
fstool va_test -h <IP> -c vulns -d 100

# ---------- SUPPORT BUNDLES (node with the problem) ----------
fstool tech-support --pack
fstool tech-support diag <bundle.tgz>

# ---------- PROPERTIES (node) ----------
fstool get_property <key>
fstool set_property <key> <value>
fstool remove_property <key>

# ---------- LICENSE (EM) ----------
fstool check_license
fstool rms_license_info
fstool get_machine_locking_id
# fstool calc_license_status restarts the license server: never in business hours

# ---------- HA (each node) ----------
fstool ha status
fstool ha_snapshot

# ---------- DATABASE (EM, read only) ----------
psql -P pager=off -c "<select ...>"

# ---------- ACCESS (cliadmin, per node) ----------
fstool cli ssh_root_password_login enable
fstool cli ssh_root_password_login disable