Installing AI Insights 365 On-Prem — Requirements & Setup

This guide walks IT administrators and data engineers through a clean installation of AI Insights 365 On-Prem on Windows infrastructure. Because the platform runs entirely inside your own network, you control every layer — the operating system, the application host, the database, and the AI engine. The first run is driven by a self-hosted setup wizard that takes you from a fresh license to a fully provisioned, hardened deployment in a single session.

Read this document end to end before you begin. A few decisions — most notably your AI engine and your database topology — are easiest to make up front and harder to change later.

Before You Begin: What You'll Decide

The installer is deliberately opinionated about security but flexible about architecture. During setup you will make three decisions:

• AI engine — Azure AI Foundry (cloud inference) or local Ollama (fully air-gapped, no external calls).
• Application database — which SQL Server instance hosts the platform's own metadata, configuration, and audit store.
• Network exposure — whether the platform is reachable only on the LAN or behind a reverse proxy, and how it reaches databases on remote subnets (direct in-network connection, or private networking / VPN where the source sits in a different segment).

Have these answers ready and the wizard takes only a few minutes.

Why these decisions matter early

The AI engine choice determines your egress posture and your hardware sizing — an air-gapped Ollama deployment looks very different from a cloud-inference one, and you don't want to discover a GPU shortfall after go-live. The database topology determines where your metadata and audit trail live, and which network paths the application host needs to reach each data source. The network exposure decision shapes your firewall change requests, which in many organizations take longer to approve than the install itself. Settling these three before you touch the installer turns a multi-day change window into an afternoon.

Hardware and Operating System Prerequisites

AI Insights 365 On-Prem is a Windows-hosted application. Size the host to your concurrent user count and the volume of data you intend to transform and query.

Minimum and recommended specs

If you choose local Ollama as your AI engine, plan for additional resources. Language models are memory- and (ideally) GPU-intensive; budget extra RAM and, where possible, a supported GPU on the host that will serve inference. Cloud inference via Azure AI Foundry offloads that demand, so the application host itself can stay lean.

Database server

The platform stores its own configuration, workspace metadata, and audit logs in SQL Server. This is separate from the data sources you will later connect for analytics. You may co-locate the database on the application host for small deployments, but a dedicated SQL Server instance is recommended for production. Ensure the SQL login the platform uses can run schema migrations — it needs permission to create and alter tables in its own database during first run and future upgrades.

Treat this metadata database as a production asset in its own right. It holds your workspace structure, user-to-role assignments, connection definitions, and the audit trail — losing it means losing your governance record. Put it under your normal SQL Server backup regime, and if you run an Always On availability group or failover cluster, point the platform at the listener rather than a single node. A small deployment can run comfortably on Express-class resources, but plan capacity for audit-log growth: high-activity orgs accumulate audit records steadily, and you'll want a retention and archival plan rather than an unbounded table.

Network and Firewall Considerations

Keep the platform's footprint deliberate. At minimum, plan for:

• Inbound HTTPS to the application host from your user network. Terminate TLS at the host or at a reverse proxy in front of it.
• Application host to SQL Server on the SQL listener port (1433 by default) for the metadata database.
• Application host to data sources for any connections you configure directly (PostgreSQL, MySQL, Oracle, cloud warehouses, REST APIs, and so on).

When databases live on a remote subnet

AI Insights 365 connects directly to your databases — the application host opens a normal client connection to each source over its native port, all of it inside your own network. There is no intermediary, broker, or polling agent in the data path; a query issued by the platform runs against the source the same way any in-network client would run it.

If a SQL Server or PostgreSQL source sits in a segment the application host cannot reach directly, the answer is to make that segment reachable on your own network rather than to introduce a relay. The two standard options are:

• Private networking / routing — peer or route the application-host subnet to the database subnet (for example with a route table entry, VPC/VNet peering, or an internal firewall rule that permits only the application host to the listener port). The connection remains a direct database connection; you have simply made the path exist.
• Site-to-site or host VPN — where the database lives in another office, datacenter, or cloud region, establish a VPN so the application host reaches the source across an encrypted tunnel on private addressing.

In every case the credentials and traffic stay inside your network or inside an encrypted tunnel you control, and access is constrained by a least-privilege, read-only database account so the platform can query but never mutate source data. Pair that with the platform's AES-256 encryption at rest for the stored credential, and a remote-subnet source is no less protected than a co-located one.

AI engine egress

• Azure AI Foundry requires outbound HTTPS from the host (or the Ollama-free inference path) to the Azure endpoint you configure.
• Local Ollama requires no external egress. For a truly air-gapped install, choose Ollama and the platform makes no outbound AI calls whatsoever.

A reference firewall summary

The table below summarizes the typical flows. Adapt ports to your environment — these are defaults, not requirements.

Note that every database flow originates outbound from the application host to the source — you only permit the application host to reach the listener port, never the reverse. Scoping that allowance to the single application host (and, on remote subnets, carrying it over a route you control or an encrypted VPN tunnel) lets the platform reach any in-network database without widening your overall network posture.

Running the Installer

1. Copy the installer package to the target Windows Server.
2. Confirm the .NET hosting bundle is present; install it first if needed.
3. Run the installer with administrative privileges.
4. Let it provision the application files, register the Windows service/site, and bind the HTTPS endpoint.

When the installer finishes, the application is running but not yet configured. Open the site in a browser and you will land on the first-run setup wizard.

Running as a service account

Run the application under a dedicated service identity rather than a personal account or the default system account. A managed service account (or a domain service account with a non-expiring, vaulted password) gives you a clean identity to grant the SQL Server permissions to and to audit. If you intend to use Active Directory SSO later, a domain identity also simplifies integrated authentication. Grant that account only the file-system and registry rights the application needs, and nothing more.

The First-Run Setup Wizard

The wizard runs once, in order. Each step gates the next, so the platform can never come online half-configured.

Step 1 — License

Paste or upload your license. Licenses are offline, HMAC-signed files that encode your seat count and expiry. You can activate two ways:

• Online activation — the host contacts the licensing service to validate.
• Air-gapped activation — for isolated networks, complete the offline challenge/response so no internet connection is required.

The wizard validates the signature and shows your seat count and expiry before you continue.

Step 2 — AI Provider

Choose your inference engine:

• Azure AI Foundry — supply the endpoint and credentials. Inference runs in your Azure tenant.
• Local Ollama — point the platform at your Ollama host. No data leaves your network; this is the air-gapped choice.

This selection drives every AI feature later — natural-language-to-SQL chat, AI auto-report generation, chart and anomaly explanation, and AI-assisted transforms. You can set a per-org monthly token budget after setup to govern consumption.

Step 3 — Database Migrations

Provide the connection details for the SQL Server instance that will host the platform's metadata. The wizard tests the connection, then runs the schema migrations to create the application's tables. Confirm the login has rights to create and alter objects in this database. If the connection test fails, the wizard surfaces the error and lets you correct credentials before proceeding — migrations will not run against an unreachable or under-privileged database.

Step 4 — Administrator Account

Create the first Admin user. This account holds the highest role in the platform's RBAC model (Admin / Editor / Viewer) and is your break-glass identity. Use a strong, unique password and store it in your secrets vault. You can wire up Active Directory or Entra ID (Azure AD) SSO after setup, but this local admin remains your fallback.

Step 5 — Encryption and JWT Key Generation

The final step generates the cryptographic material the platform uses at runtime:

• The encryption key that protects data-source credentials at rest (AES-256-CBC).
• The JWT signing key that secures authenticated sessions.

These keys are generated locally and stored on the host. Back them up immediately to your secrets management system. Losing the encryption key means stored connection credentials cannot be decrypted; losing or rotating the JWT key invalidates active sessions.

Treat these keys with the same rigor you apply to any root secret. Store them in your enterprise secrets vault, restrict access to a named set of administrators, and document the recovery procedure. Because the encryption key is what protects every connection credential at rest, key loss is effectively credential loss — you would have to re-enter and re-test every data source. Capturing the keys at this moment, before any connections exist, costs nothing; recovering from their loss later is painful.

Why the wizard runs in order

Each step depends on the one before it. The license unlocks the configuration surface; the AI provider must be known before features that depend on it can initialize; migrations must succeed before any user or audit record can be written; the admin account needs a database to live in; and the keys are generated last so they can immediately protect everything that follows. This ordering is deliberate — it guarantees the platform either comes online fully configured or not at all, with no partially provisioned state for an attacker or a misconfiguration to exploit.

Verifying the Installation

Once the wizard completes, confirm the service is healthy. The platform exposes a /health endpoint for exactly this purpose.

curl -k https://your-host/health

A healthy instance returns a success status. Wire this endpoint into your monitoring and load-balancer health checks so degraded states are caught early. Then log in with the admin account you created and confirm the dashboard loads.

A quick smoke test:

• Log in as the admin user.
• Create a workspace.
• Add a simple data source (a CSV/Excel upload works well) and confirm the connection test passes and the schema is introspected.
• Open the natural-language chat and ask a question to confirm the AI engine responds.

Troubleshooting first-run issues

A few situations come up often enough to call out:

• Migrations fail at Step 3. Almost always a permissions or connectivity problem. Confirm the login can create and alter objects in the target database and that the SQL listener is reachable from the application host. The wizard reports the underlying error — read it before retrying.
• The AI engine doesn't respond in the smoke test. For Azure AI Foundry, verify outbound HTTPS to the endpoint and that the credentials are valid. For Ollama, confirm the Ollama host is running, reachable from the application host, and has a model pulled.
• /health returns a degraded status. Check the application logs on the host. A common cause is the metadata database becoming unreachable after first run — for example, a firewall change or a SQL service restart.

Post-Install Hardening Checklist

Before you hand the platform to users, work through this checklist:

• Enforce HTTPS only. Terminate TLS at the host or reverse proxy and disable any plain-HTTP binding.
• Back up the encryption and JWT keys to your secrets vault, separately from the host.
• Restrict the metadata SQL login to least privilege after migrations complete.
• Configure SSO with Active Directory or Entra ID, and reserve the local admin account for break-glass use.
• Define RBAC roles — assign Admin sparingly; default users to Editor or Viewer.
• Set the per-org monthly token budget to cap AI consumption.
• Lock down network exposure — limit inbound access to the user network, and reach remote-subnet databases over a scoped route or VPN rather than opening broad firewall paths.
• Use least-privilege, read-only database accounts for every connected source so the platform can query but never modify data.
• Enable audit logging review and forward logs to your SIEM if you have one.
• Schedule org/workspace backups (.orgbak / .wbak) and verify a restore works.
• Monitor /health from your existing observability stack.
• Document the license expiry so renewals don't lapse and lock out users.

Next Steps

With the platform installed, verified, and hardened, you're ready to connect data sources, build no-code transform pipelines, and publish reports and dashboards. If a database sits on a remote subnet, establish the route or VPN that lets the application host reach it directly, and connect using a least-privilege, read-only account so credentials stay in-network and the source stays read-only. From there, configure scheduled email subscriptions and tokenized share links to put insights in front of stakeholders — all without a byte of sensitive data leaving your infrastructure.