IT Administrator Setup & Deployment Guide

Exhibit In-Sight Software Suite | Version 1.0
🔒 Zero-Cloud Evidence Architecture: This software does not transmit, host, process, or back up any evidentiary data, case notes, search warrant images, or crime scene photographs to vendor cloud infrastructure. All evidentiary data remains 100% sovereign on your agency's local hardware.

This guide provides IT Administrators and Systems Engineers with the technical specifications required to securely deploy the Exhibit In-Sight Desktop/MDT application and the Android Mobile companion app across your agency's endpoints. Please review the network, system, and group policy requirements to ensure successful deployment alongside existing Endpoint Detection and Response (EDR), Mobile VPN, and firewall infrastructure.

1. Minimum & Recommended System Requirements

A. Desktop / MDT Application (Windows)

B. Mobile Companion Application (Android)

2. Network & Firewall Configuration

The software suite utilizes an air-gapped wireless architecture. The desktop application acts as a localized HTTPS server communicating with mobile devices via a WPA2-secured Wi-Fi hotspot or local cruiser subnet.

A. Local Area Network (Inbound/Outbound Rules)

B. Cruiser Mobile VPNs & Virtual Adapters (NetMotion / Absolute)

Many agencies deploy persistent Mobile VPN clients (e.g., NetMotion Mobility, Absolute Secure Access) on in-vehicle MDTs. To ensure uninterrupted mobile device pairing:

C. Windows Time Synchronization (W32Time Service)

At application startup, the MDT queries the local time provider (w32tm /query /source) and logs the active clock source into the audit trail. If the machine cannot resolve a network time source, it logs CMOS Local Hardware Clock.

D. Outbound License Validation

The desktop software requires periodic outbound HTTPS (TCP 443) access to communicate with our licensing verification server. This is a lightweight HTTP GET request containing your agency's unique billing key.

3. Endpoint Protection (EDR) & Antivirus Whitelisting

The MDT application utilizes high-performance, non-blocking Java NIO FileChannel streams with active OS-level file locking (.lock files) to prevent multi-process data corruption during rapid live evidence logging. To avoid false-positive quarantines, performance degradation, or deadlocks caused by aggressive Endpoint Detection and Response (EDR) platforms (e.g., CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne), please configure the following behavioral and directory exclusions:

4. Enterprise User Authentication & 30-Minute Auto-Lock

5. Mobile App Deployment (MDM Guidelines)

The Android companion application is distributed as a signed .apk download, suitable for deployment via your agency's Mobile Device Management (MDM) solution (e.g., Microsoft Intune, VMware Workspace ONE, SOTI MobiControl).

6. Data Storage, Cloud Syncs, & Encryption at Rest

All case files generated by the MDT application are compiled as proprietary .eis container files (structured, uncompressed ZIP archives containing data.json, raw JPEGs, and warrant scans). In field-offline environments, mobile devices can also export self-contained .eis_mobile archive packages for manual USB or email transfer to the MDT.

🔐 Application-Layer Encryption Notice: To optimize live, high-frequency read/write performance during active scene operations, .eis containers and mobile SQLite databases do not apply proprietary file-level encryption. Data protection at rest relies entirely on host operating-system encryption:
⚠ CRITICAL STORAGE CONSTRAINT (NO LIVE CLOUD SYNC): The software continuously executes low-latency read/write operations during live evidence collection. Active .eis container files must reside on local, non-synchronizing disk storage (e.g., C:\Cases\). Hosting active working directories inside real-time cloud-sync folders (Microsoft OneDrive, SharePoint, Google Drive, Dropbox) causes operating-system file-locking collisions with Java NIO FileChannel streams, resulting in save thread deadlocks and container corruption.