Deployment Planning
File Reporter can be installed to work in a variety of configurations. Before proceeding with the installation, you should understand how to deploy File Reporter to best meet the needs of your organization.
Requirements Overview
Before you install File Reporter, review the following table to understand how different technologies might affect how you proceed.
| Technology | Notes |
|---|---|
| Windows and Networking |
The Engine runs on a Windows operating system and uses basic TCP/IP networking inherent to the operating system. |
| Microsoft Internet Information Server (IIS) |
File Reporter is accessed and managed via a web browser. The Web Application is an ASP.NET application that runs in conjunction with IIS. The installer and configuration utilities automatically configure IIS and manage most aspects of the installation for you. The Engine and Web Application must run on the same system in this release of the software. |
| DNS |
To access the File Reporter Web Application with a browser, the site hostname registered with IIS must be used. In other words, the raw IP address does not work. You need to create a DNS entry for the name in the environment, or the
entry needs to be added to the |
| Database |
File Reporter utilizes a Microsoft SQL Server or PostgreSQL database as the backend data store. The database must be accessible from the server running the Engine. |
| Active Directory and Windows Server |
For reporting on Active Directory and Windows file systems, File Reporter makes use of a proxy object and group in Active Directory that is used by the system as part of day-to-day operations. You should be familiar with the Windows network that you will be reporting against with File Reporter as well as with basic Windows file system and Active Directory terminology and operations. |
| Message Broker |
To enable messaging between File Reporter components that are needed for file content scanning (ManagerFC and AgentFC) or Microsoft 365 scanning (Agent365), File Reporter utilizes the RabbitMQ message broker. |
Engine Host
-
The server hosting the Engine service should have significant CPU, disk, and memory for all but the smallest installations.
-
The Engine runs on any of the following Windows Servers:
-
Windows Server 2022
-
Windows Server 2019
-
Windows Server 2016
-
-
The Engine host must be joined to the domain
NOTE: OpenText strongly recommends that you install the Engine on a member server and not on a domain controller. This recommendation might be a requirement in a future release.
File Content
Among the capabilities of File Reporter is the ability to scan and classify file content. For example, you can scan for files containing United States Social Security numbers and then classify these documents as restricted documents whose access permissions and storage locations might need to be corrected.
If you plan to scan Windows network storage devices for file content, you will need to install the following additional components:
-
ManagerFC
-
AgentFC
-
RabbitMQ message broker
For more details on file content scanning, see File Content Scanning in the File Reporter 24.1 Administration Guide.
Microsoft 365
With the release of File Reporter 24.1, File Reporter can scan and report on the metadata and permissions of files stored in OneDrive for Business, SharePoint Online, and Teams. If you plan to scan and report on these Microsoft 365 cloud-stored files, you will need to install the following components:
-
Agent365
-
RabbitMQ message broker
File System Agents
| Target System | Local Scan | Proxy Scan |
|---|---|---|
| Windows Server | Yes | Yes |
|
Network Attached Storage |
No | Yes |
When you decide whether to install AgentFS locally on a Windows server or to have the AgentFS service run as a proxy, be aware of the following:
-
Locally installed agents perform scans faster than proxy-based agents.
-
Locally installed agents share CPU and memory resources with other software running on the system. If a server is already constrained for resources, consider using a proxy instead of installing the agent locally.
Database Planning
You should consider the following guidelines before installing and configuring any database system for File Reporter.
Determine a Database Type
You can utilize either a PostgreSQL database or a Microsoft SQL Server database. Here are some considerations for choosing one over the other:
-
You might prefer to utilize Microsoft SQL Server if you have a Microsoft Licensing Agreement that entitles you to Microsoft SQL Server.
File Reporter supports the Standard and Enterprise versions of SQL Server. It does not support the Web or Express editions.
-
You might prefer to utilize the PostgreSQL database if you are proficient with Linux.
Use a Dedicated Server
Due to the potential size of the collected scan data and the I/O processing needed for large database installations, we strongly recommend that you install the database on a dedicated server.
-
For minimum requirements for PostgreSQL, see .
-
For minimum requirements for a SQL Server host, see .
Use a Dedicated Database Instance
In addition to sizing requirements, we recommend that you use a dedicated SQL Server instance or PostgreSQL cluster to prevent conflicts with other vendor software. File Reporter needs access to manage the database security principals and roles, which requires access at the instance level. In addition, File Reporter ships with optional CLR extensions for SQL Server, which requires enablement at the instance level.
In short, do not install the File Reporter database in an instance or cluster that shares databases with other software.
Provide Sufficient I/O Bandwidth
Relational Database Management Systems are by nature very I/O intensive, especially when it
comes to persisted storage on disk. For best performance, consider the following:
-
Provide SSD storage if possible for the database tablespaces or filegroups*.
-
Alternatively, provide RAID-10 spindle storage for database tablespaces or filegroups*.
-
Do not use RAID-5 storage for database storage.
-
Do not use Network Attached Storage for database storage.
-
If using a SAN, be sure to provide at least 10 GB or more throughput (ideally, the SAN link should be faster than the I/O capacity of the backend storage system, so that it is not the bottleneck).
-
Be sure to enable battery-backed cache for RAID and SAN controllers.
-
For SQL Server, optionally place tempdb on a separate RAID-1 or SSD.
-
Optionally, place the transaction logs on a separate RAID-1 or SSD.
This can be done either during the installation of the SQL Server instance or afterwards.
For procedures on moving database files after the installation of an SQL Server instance, see https://learn.microsoft.com/en-us/sql/relational-databases/databases/move-database-files.
For PostgreSQL, moving database files is a simple process of stopping the database server, relocating the pg_xlog folder, and then creating a symbolic link to the new path.
The need for separate disks for transaction logs is minimized if the main storage is already on RAID-10 or SSD, and the I/O channel is not already saturated.
* For basic information on SQL Server filegroups, see https://learn.microsoft.com/en-us/sql/relational-databases/databases/database-files-and-filegroups.
* For basic information on PostgreSQL tablespaces, see https://www.postgresql.org/docs/current/static/manage-ag-tablespaces.html.