Previous Topic: Where Do I Install the FSA?Next Topic: FSA Terminology


FSA Architecture

The FSA can scan, analyze and apply policy to files saved in file system, items in Exchange Public Folders and on SharePoint sites, and database records. It can run multiple scanning jobs simultaneously, with each job scanning separate folders or machines and, if required, using a separate ‘run as’ account to access remote machines. An example FSA deployment architecture for scanning remote file systems is shown below.

FSA architecture

Example FSA deployment: file scanning

  1. FSA: The FSA runs scanning jobs to monitor files saved in remote file systems. It can delete or copy specified files.
  2. Scanning job file: An XML file containing the job definition.
  3. Scanned folders: The job file defines which items you want to scan and the target host machine.
  4. Database: The scanned files database (4a) contains records for each file already scanned. The FSA queries this database to check whether a file needs to scanned in the current job.

    For files that do need scanning, the FSA can then optionally query a NIST database (4b) to identify system files which can be omitted from the scanning job.

  5. Policy engine hub: Files that need to be analyzed are passed to the hub by the FSA. The hub then allocates files to policy engines for processing (6).

    When processing is complete, the hub also passes back to the FSA details of any actions that must be taken (for example, to delete a file or copy it to a new location).

  6. Policy engines: When the policy engine hub receives a new file from the FSA, it allocates the file to the least heavily loaded policy engine (that is, the policy engine that can process the new file most quickly).

    The policy engine then analyzes the file and applies Data At Rest triggers as necessary. Any resulting control actions (for example, to delete or copy a file) are passed back to the hub (5). The hub then relays these actions to the FSA (1).

  7. CMS: Each policy engine replicates processed file events up to the CMS. File events can be viewed alongside existing e‑mail, Web and IM events using CA DataMinder consoles.