OST Batch Folder-Level Export for Multi-Custodian eDiscovery: The Sherlock Forensic Workflow

Multi-custodian eDiscovery engagements routinely surface 10 or more OST archives that need consistent folder-level export for downstream review platform ingest. The Sherlock Forensics batch workflow with Sherlock OST Viewer handles the acquisition-through-export pipeline in a single tool. This Tool Guide walks through the 6-step methodology, the per-custodian output structure that Relativity and similar review platforms expect and the FRE 902(14) admissibility considerations that support the exported records in downstream litigation.

TL;DR and Workflow Summary

The short answer: Six-step workflow. Acquire OSTs per custodian with chain of custody documentation. Hash and manifest each file. Batch-open through Sherlock OST Viewer. Apply cross-custodian filter (date range and keyword and sender-recipient). Configure per-custodian output directory structure and export format. Execute batch export and verify hash manifest parity. Total workflow time approximately 3 hours for 10-custodian engagement with mid-size archives (2 to 10 GB per custodian).

Why Multi-Custodian OST Engagements Need a Batch Workflow

Single-custodian OST forensic work is a linear task: acquire the file, load it in the viewer, extract the responsive messages, export to the target format. Multi-custodian engagements do not scale linearly because consistency and reproducibility across custodians dominates the effort. The three challenges that a batch workflow addresses are consistent filtering (the same filter criteria applied to every custodian archive without per-custodian variance), consistent output structure (per-custodian directory hierarchy that Relativity and similar review platforms ingest predictably) and consistent chain of custody documentation (per-file hash records and per-custodian manifest that support authentication in downstream review and court submission).

For engagements involving 5 to 20 custodians the batch workflow reduces engagement time by 40 to 60 percent versus per-custodian sequential processing. For engagements with 20 or more custodians the batch workflow is not just a time saving but a consistency requirement: manual per-custodian filter application at scale introduces variance that opposing counsel routinely challenges during expert deposition. The Sherlock OST Viewer handles the batch scale directly through the multi-file open and unified filter interface.

Step 1: Acquire OST Files Per Custodian

Per-custodian acquisition follows the standard forensic acquisition posture. For custodians whose devices are corporate-owned and subject to acceptable-use-policy inspection provisions the acquisition happens directly from the device profile at %LOCALAPPDATA%/Microsoft/Outlook/ on Windows or ~/Library/Group Containers/UBF8T346G9.Office/Outlook/ on macOS. For custodians whose devices are personal and subject to litigation hold obligations the acquisition uses forensic imaging tools and a documented consent workflow. For custodians whose device is unavailable the acquisition path pivots to Microsoft Exchange server-side extraction or Microsoft 365 eDiscovery export depending on the licensing and retention configuration.

Each acquisition record documents the source device identifier, the acquisition timestamp (UTC and local), the examiner identity, the OST filename and size and the chain of custody handoff from field acquisition to the batch processing environment. For engagements involving international custodians the acquisition documentation needs to identify the jurisdiction of collection and the applicable cross-border data handling rules; Canadian PIPEDA and provincial-equivalent privacy law imposes documentation requirements that support subsequent regulator inquiry if the collection involved personal information categories.

Step 2: Hash Plus Manifest Per Custodian

Compute SHA256 of every source OST file before any analysis or extraction. Write a per-custodian manifest in a structured format (JSON or CSV) that lists the acquired OST filename, the file size in bytes, the SHA256 hash, the source device identifier, the acquisition timestamp and the examiner identity. The per-custodian manifest becomes the source-truth reference against which downstream batch outputs are verified for parity.

For multi-file custodians (rare but occurs when a custodian used multiple Outlook profiles or when acquisition captured archive-plus-live OST pairs) the manifest includes each file separately. The Sherlock hash verifier produces a signed acquisition record suitable for later court submission. The per-custodian manifest also drives the downstream directory-naming convention: custodian-NN-lastname-firstname subdirectories match the manifest ordering for auditable traceability.

Step 3: Batch-Open Through Sherlock OST Viewer

Point Sherlock OST Viewer at the acquisition directory and load all OST files in a single session. The tool indexes each file independently in a per-file working index and retains per-file provenance metadata (source filename, source hash, index build timestamp) across the batch session. Loading 10 to 20 mid-sized OST files typically completes in 3 to 8 minutes on modern forensic workstation hardware. For engagements with very large custodian archives (individual OSTs above 30 GB) the loading step is IO-bound; consider staging the working copies on NVMe storage to reduce load time.

The batch session interface presents a unified custodian list with per-custodian message count and folder structure. From this interface investigators apply cross-custodian filter criteria and produce the unified in-scope message set that drives downstream export configuration. Distinct from single-custodian workflows the batch session preserves per-custodian identity through every subsequent step; the tool never produces cross-custodian message pools where custodian identity would be lost.

Step 4: Apply Cross-Custodian Filter

Apply date range and keyword and sender-recipient filters across all loaded OSTs simultaneously through the unified filter panel. The unified filter set produces the responsive message subset consistent across every custodian archive. Common eDiscovery filter patterns include date range bounded to the discovery period, keyword filters bounded to the responsive terms list, sender or recipient filters bounded to identified and in-scope parties and subject-line filters bounded to identified matter references.

Compound filters using boolean logic (AND and OR and NOT) combine multiple criteria into a single evaluation. For example: date between 2024-06-01 and 2024-09-30 AND (sender contains contract-negotiation OR recipient contains contract-negotiation) AND NOT subject contains automated-notification. The filter set is saved as a reusable filter profile that the batch session persists and reproduces in follow-up runs; this reproducibility is what opposing counsel and the court expect for large-scale eDiscovery exports.

The Sherlock OST Viewer filter pane shows the responsive message count per custodian in real time as filter criteria change. This visibility lets investigators iterate the filter set toward the target scope before committing to the export step. For engagements where the responsive set is intentionally narrow (targeted single-issue review) the filter iteration converges quickly; for broad discovery the iteration takes more rounds but the real-time count feedback keeps the loop tight.

Step 5: Configure Per-Custodian Output Structure

Configure output directory structure with per-custodian subdirectory naming that matches the manifest ordering. The recommended convention is custodian-NN-lastname-firstname where NN is a zero-padded custodian number and lastname and firstname support human-readable ordering. Within each per-custodian directory the recommended structure separates by output format: pst for Relativity ingest, msg for native message review, eml for cross-platform review and attachments for extracted attachment binaries when the review platform requires them separately.

The output format selection depends on the downstream review platform. Relativity ingests PST natively and preserves folder structure and per-message metadata. Logikcull and Everlaw ingest both PST and EML with folder preservation. Native-format review workflows (rare but real for specific matter types) prefer MSG for Windows and EML for cross-platform. For Canadian civil litigation the most common target is PST for Relativity ingest; for US eDiscovery matters the most common target is EML for review-platform-agnostic ingest.

Step 6: Execute Batch Export Plus Verify

Execute the batch export. Sherlock OST Viewer writes per-custodian output directories following the configured naming convention and produces a batch manifest documenting source file, export format, output path, per-file hash and per-message hash where the review platform expects message-level authentication. Batch export for a 10-custodian engagement with mid-size archives typically completes in 30 to 90 minutes on modern forensic hardware; IO bandwidth is the dominant constraint.

Verify the batch manifest against the source acquisition manifest for parity. Every custodian in the source manifest must appear in the batch manifest with matching custodian identity and non-empty output. Every message included in the exported PST or MSG or EML output must appear in the batch manifest with a valid per-message hash. Discrepancies between the source manifest and the batch manifest are cause to halt the export and investigate before proceeding; halting on inconsistency preserves the export credibility that later depositions may test.

FRE 902(14) Admissibility Considerations

Federal Rules of Evidence Rule 902(14) covers self-authentication for certified electronic records produced through processes shown to produce accurate results. For batch-exported OST records the certification typically pairs the batch manifest with an examiner affidavit describing the export process and attesting to the accuracy of the exported records. The batch manifest documents the technical facts (source file, hash, output path, per-message hash) and the examiner affidavit documents the process facts (chain of custody, tool version, filter configuration, verification result).

For Canadian civil and criminal contexts the equivalent authentication provisions live in the Canada Evidence Act and provincial evidence acts. The specific admissibility standards vary by jurisdiction and by matter type; the Sherlock OST Viewer output supports either framework through the same batch manifest structure. For matters where the export may cross the border (Canadian custodians in US litigation or vice versa) the certification package needs to satisfy both frameworks.

The operational implication is that the batch export workflow documented above is not optional detail. It is the process that produces the certification-ready output. Shortcuts in the workflow (skipping the per-custodian manifest, applying inconsistent filter criteria, discarding the batch manifest) all produce output that may be challenged for authenticity at deposition. The 3-hour batch workflow investment produces evidence that supports both litigation outcomes and regulator inquiry with no follow-on rework required.

What Sherlock Customers Get From the Batch Workflow

For organizations conducting multi-custodian eDiscovery at scale the operational discipline documented above is the reference methodology. The Sherlock OST Viewer product handles the batch scale directly and the storefront documents pricing and licensing for the Forensic Edition that unlocks the batch export capability. For organizations that prefer engagement work rather than internal capacity Sherlock incident response and eDiscovery engagements apply this methodology as the standard workflow for OST-bearing matters.

The batch workflow scales predictably from small (3 to 5 custodian) engagements through large (50-plus custodian) engagements. The bottleneck at scale is typically IO bandwidth rather than tool capacity; provisioning NVMe staging and fast network storage removes the practical constraints. For engagements involving cross-border data movement the workflow accommodates the additional documentation requirements without changing the core steps.