Creating Collections
Choosing a front-end and planning what to collect.
Responsible use: Perform evidence collection only on systems you are authorized to examine, and handle collected evidence according to your organization's forensic and evidence-handling procedures.
A "collection" is one run of Collector: a selection of evidence modules, a set of collection options, and the resulting hash-manifested package. Both front-ends produce the same shape of output from the same selection — the choice between them is about workflow, not capability.
Which front-end?
- Use the GUI when you're at the machine's console, want a visual module picker, or want to watch live progress and copy an equivalent CLI command afterward for later automation. See GUI.
- Use the CLI wizard (no arguments) for the same guided experience in a terminal — useful over a remote shell, or when you'd rather not wait for the GUI to load. See CLI.
- Use headless flags for scripted, unattended, or repeated collections (deployment tooling, PsExec, scheduled tasks). See the CLI reference.
The three decisions every collection makes
- Which modules? Recommended (the default set) covers most incident-response needs. Custom lets you add or remove individual modules — see Evidence Handling for what each one collects.
- How deep is Hash Inventory? Smart is fast and targeted; Extended and Full trade time/size for broader coverage.
- Where does the package go, and as what extension? Local disk, a mapped
share, or a USB drive;
.zipor.tvak— see Configuration.
Whatever you select gets collected in full and honestly recorded — including failures.
Collector never silently skips or filters based on what it "thinks" is interesting. See
Troubleshooting for how failures are reported.