Requirements
What TRACER365 needs before you install it
The host it runs on, the network paths it uses, the read-only tenant access it asks for, and what a licence covers. This page is written to be forwarded — it is the one to hand to whoever has to approve the app registration.
The host
A Windows machine you control
TRACER365 is a self-hosted Windows application. It runs entirely on a machine you control — your server or workstation, your network, your local database. Nothing about the application runs in a vendor cloud, and Storrex never receives your audit data, your tenant data, or your credentials. It does connect outbound to read your tenant, and can optionally connect to a mail relay or an update endpoint — those paths are set out in the next section.
It runs as a background Windows service and serves its management interface over HTTPS as a web console listening on a TCP port on the host. How that port is reached is determined by your own network configuration.
| Requirement | What it means |
|---|---|
| Operating system | Windows Server 2019 or later, or Windows 11. Not an earlier release. |
| Architecture | A 64-bit (x64) edition of Windows. TRACER365 is a 64-bit application; it does not run on 32-bit Windows. |
| Runtime | None to install separately. The installer brings its own Python runtime, so there is no Python to install or maintain on the target machine. |
| Database | None to install separately. Everything is stored in a local SQLite database file that the installer creates and manages — no database server to provision, license or patch, and no connection to any SQL Server instance already on the machine. |
| Rights to install | Local administrator rights on the host, as for any application that installs a Windows service and writes to the machine's shared program-data area. That is an install-time requirement; day-to-day use of the application does not run as an administrator. |
| Disk | The application, its runtime and its local database live on the host's own disk. The database grows over time with the volume of findings, scan history and the audit trail — which is retained in full for the life of the installation — so size the disk with headroom for that growth. |
A scan is Microsoft-Graph-bound work: the application reads sharing and permissions metadata from your tenant over the network and writes results to the local database. It is I/O- and API-latency-bound rather than compute-heavy, and it runs in the background on the host. Plan for the machine to be able to reach your tenant and left running for the duration of a scan, which grows with the size of the tenant being audited.
Network
Outbound only — nothing needs to reach it
What the host must be able to reach
There are three kinds of outbound connection, and each goes to a destination you choose or control:
- Your Microsoft 365 tenant. The core function. The application connects to Microsoft Graph and the SharePoint REST API over HTTPS, using the credentials you provision, to read the metadata it audits. Your egress rules must allow the host to reach Microsoft's sign-in endpoints, Microsoft Graph, and your tenant's SharePoint Online.
- Your mail relay (optional). If you configure email delivery, the application connects to the SMTP server you specify. What it sends there is operational notice about your own installation — the post-scan findings digest, alerts when a scheduled scan fails or is repeatedly skipped, and certificate-expiry notices among them. This path does nothing until you configure it, and its destination is your own mail infrastructure.
- An update check (optional, off by default). The only outbound path that reaches a Storrex-published endpoint rather than one you run. It ships turned off — with it disabled, the application makes no request and performs no DNS lookup for it. If you enable it, it fetches a static version file and compares versions locally; it sends no tenant, installation or version-identifying data, and reports nothing about what the installation scans.
Nothing needs to reach it from the internet
Where the console is reached from is your decision
If the host reaches the internet through a proxy
Two of those three are HTTP requests — the tenant connection, and the update check once you enable it — and both go through the proxy you configure for the host. You configure it the standard way: the environment variable HTTPS_PROXY for the traffic, and NO_PROXY for any host that must be reached directly instead. HTTP_PROXY does nothing here, because every request the application makes is HTTPS. The mail relay is unaffected either way — that is an SMTP connection to the server you name, not an HTTP request. And a transparent proxy needs none of this: traffic passes through it with no client configuration at all.
Set those variables machine-scoped, as system variables. The application runs as a background Windows service under a service account, and a variable set in a signed-in administrator's profile is not present in that account's environment — so setting it while signed in as yourself does not set it for the service. The proxy configured in Windows Internet Options is read too, with the same catch and one more: it comes from the registry of the account the process runs as rather than from a machine-wide setting, and it is read only as a fallback, when none of the environment variables is set — and NO_PROXY counts as one of them, so a bypass list on its own suppresses the Windows setting and leaves the host with no proxy at all. The application reads its environment once, when the service starts, so restart the service after changing any of these variables.
Two limits to plan around. Only a statically configured proxy address and its bypass list are read from Windows — a proxy published through an automatic configuration script (a PAC file) or discovered through WPAD auto-detection is not found, and on such a network the environment variables have to be set explicitly. And where the proxy inspects TLS, trusting its certificate authority in the Windows certificate store does nothing here: the application validates certificates against a list bundled with it, so it has to be pointed at a PEM file containing that authority instead — machine-scoped again, in REQUESTS_CA_BUNDLE. That file replaces the bundled list rather than adding to it, so it must carry every authority the host still needs.
Microsoft 365 tenant access
One app registration, read-only, in your tenant
To audit your tenant, TRACER365 needs an Azure AD (Microsoft Entra) application registration, created in your tenant and granted admin consent by someone able to register an application and consent to tenant-wide application permissions.
The application authenticates as itself — app-only, with no signed-in user — and it does so with an X.509 certificate rather than a client secret. That is not merely the recommended pattern here; it is required. The SharePoint REST API rejects app-only tokens obtained with a client secret, so part of the product's detection capability depends on certificate authentication.
You — or your PKI — generate the certificate. You upload the private-key file to the application once, over your own local connection; the matching public certificate goes onto your own app registration. Storrex never generates a certificate for you and never holds a copy of your private key.
Application permissions requested (all read-only)
| Permission | Used for |
|---|---|
Files.Read.All (Graph) | Read drive items and their permissions for sharing analysis |
Sites.Read.All (Graph) | Enumerate SharePoint sites and read site-level metadata |
User.Read.All (Graph) | Resolve display names and sign-in names (UPNs) for the principals on sharing grants |
Group.Read.All (Graph) | Enumerate Microsoft 365 groups and map sites to their backing group |
Sites.Read.All (SharePoint REST) | Identify a site's default groups, so default-group membership is not mis-read as external exposure — a separate grant from the Graph permission of the same name |
Deliberately not requested
- no write-capable permission on either API;
- no
Sites.FullControl.All; - no directory-write or user-write scope;
- no mail, calendar or contacts access;
- no delegated permissions of any kind — there is no end-user sign-in path into your tenant.
One trade-off is worth naming: Microsoft Graph offers a delta-query mode that would make change-detection scans more efficient, but it requires tenant-wide Sites.FullControl.All. TRACER365 declines it by design — a read-only auditing tool will not ask for full control of your SharePoint estate to do its job.
Plan for certificate rotation
The application validates a certificate's format, expiry and key strength when you upload it, and rejects one that is malformed, expired or too weak before storing it.
Once in service, the dashboard raises a warning banner ahead of expiry — an early informational notice around a month out, a more prominent warning in the final week, and an urgent warning in the last day or once the certificate has expired. The banner is what an administrator sees by being signed in to the console. The product also sends an expiry notice by email, but only where you have configured a mail relay and the failure-notification recipients on an active schedule for that connector. If a certificate does lapse, a scan fails loudly with a clear cause rather than a cryptic error.
Plan to rotate the certificate on your normal PKI schedule. The application does not perform CRL/OCSP revocation checking, so a certificate revoked at your CA is removed by taking it off the app registration.
Licence scope
One installation, up to two tenants
A TRACER365 licence covers one installation auditing up to two Microsoft 365 tenants. This is a contractual scope, not a technical control — the application does not count or meter the tenants you connect, and it performs no licence-usage reporting. Connecting a third tenant raises an advisory warning and still saves.
Scaling beyond two tenants is by additional licences rather than by adding tenants to a single installation: a consultant or managed-service provider serving more clients runs one installation per client. Treat the licence key with the same care as any other credential.
Operational expectations
What to plan for once it is running
Scheduled scans run weekly at most
A scan you start by hand can run whenever you choose. The shortest recurring interval a schedule will accept is weekly — deliberate, because sharing posture changes on a scale of days, and Microsoft's APIs bound how quickly a tenant can be read.Two scans at a time
The application runs at most two scans at the same time across all connected tenants. A customer auditing two tenants can have both scanning at once; a further scan requested while two are already running does not run.Back up the database and its key file together
Stored credentials are encrypted with a key generated locally, per installation, and held in a separate key file. That file and the database are one backup unit — restoring the database without its matching key file leaves every stored credential undecryptable.
What it does not need
The list your reviewer will want
During an evaluation, an explicit list of what the product does not need is often more useful than a feature list — it tells you where your own controls stay in charge.
| Not required / not done | What this means for you |
|---|---|
| No write access to your tenant | Every permission requested is read-only; the application cannot change anything in Microsoft 365. |
| No client secret | Authentication is certificate-based app-only; a shared secret is neither used nor accepted for the SharePoint path. |
| No end-user sign-in to your tenant | The application is app-only — there are no delegated permissions and no user consent flow. |
| No separate database server or Python installation | Both the runtime and the local SQLite database are provided by the installer. |
| No inbound internet exposure | Nothing needs to reach the application from the internet for it to do its job. It does listen for management-console connections, but that requires no inbound internet path. |
| No licence server or usage reporting | Licence verification is fully offline; Storrex receives no telemetry about your usage. |
| No transfer of your audit data to Storrex | Findings, scan history and credentials stay in your local database; Storrex never receives them. |
| No full-disk or full-database encryption | Credentials at rest are encrypted; the database as a whole is not — apply host-level disk encryption (e.g. BitLocker) if you require it. |
| No application-level MFA for the product's own login | The product's own sign-in is single-factor. Host-level identity controls in front of the machine gate access to the host, and restricting who can reach the console's port reduces exposure, but neither replaces MFA on the product's own login. |
| No policy or intent judgement | The product surfaces exposures; deciding whether a given share is a violation of your policy remains yours. |
The credentials-at-rest detail, the operator-role model, the audit trail and the full non-goals list are on the security & trust page. How the auth model and a scan work is in the documentation.
Ready to check this against your own environment?
Start the free trial at launch — or take your reviewer the security detail first: credentials at rest, operator roles, the audit trail, and the explicit non-goals.