Install and configure Zeta Test Management Web

Zeta Test Management Web provides browser access to centrally managed test projects. The current application is based on ASP.NET Core and .NET 10. The web application and Windows client use the same projects but do not provide identical functionality.

For a central production deployment, use the IIS package zetatest-web.zip. The separate web EXE setup starts a local demo or single-user instance with Kestrel; it is not a replacement for a secured IIS installation.

This guide covers deployment choice, IIS and HTTPS, least-privilege permissions, configuration, updates, verification and rollback.

Choose the deployment model and prepare

Deployment options

  • Local demo or single-user instance: the web EXE setup starts the bundled application locally through Kestrel. Use it for evaluation or an individual Windows user, not as the central production server.
  • Central IIS deployment: extract zetatest-web.zip on a Windows Server and run its Website folder as an IIS application. This is the documented production path.
  • Reverse proxy: a managed proxy can terminate TLS and publish the application. Validate forwarding, trusted headers, redirects and the complete HTTPS path.

Prerequisites

  • a Windows Server and IIS combination approved for the intended Zeta Test Management release;
  • administrative access for the IIS site, application pool, binding and certificate;
  • the matching .NET 10 Hosting Bundle, including ASP.NET Core Module V2;
  • a stable DNS name and trusted TLS certificate;
  • backed-up project and database storage outside the replaceable website release folder;
  • a dedicated technical identity with only the required file and database rights.

Define backup, restore, update window, rollback owner and a representative acceptance project before the first deployment.

Install and configure the IIS application

  1. Install IIS and the .NET 10 Hosting Bundle that matches the release. Restart IIS or the server when the installer requires it.
  2. Extract zetatest-web.zip into a staging folder. The IIS physical path will point to the contained Website folder.
  3. Create a dedicated IIS application pool with “No Managed Code”, disable 32-bit applications, and assign the approved technical identity.
  4. Create the IIS site or application. Keep the supplied web.config and its AspNetCoreModuleV2 configuration.
  5. Grant read and execute access to the program folder and only the necessary modify access to approved project, user-storage, attachment and log folders. Grant minimal database rights.
  6. Create the HTTPS binding for the production DNS name and certificate. HTTP should remain only when an intentional redirect endpoint is required.
  7. Configure Config.json, appsettings.json and, only when client and server paths differ, foldermappings.json.
  8. Start the application pool and site. Sign in over HTTPS and verify the project list, permissions and one representative test workflow.

Important configuration boundaries

Config.json contains classic Zeta Test Management settings such as semicolon-separated projectSearchFolderPaths. appsettings.json controls ASP.NET Core behaviour including HTTPS, cookies, logging, language and optional preview areas:

{
  "AppSettings": {
    "UseHttpsRedirection": true,
    "AllowInsecureCookies": false,
    "ExperimentalWebAreas": {
      "Enabled": false,
      "ShowLabels": true
    }
  }
}

These values are examples and must match the deployment topology. Treat serviceApiKey and every other key as a secret. Project files, configuration, backups and logs must never be exposed as static website files. IIS URL Rewrite is not a Zeta Test Management prerequisite unless your own redirect or proxy configuration requires it.

Update, verify and roll back

Treat every web update as a controlled server change:

  1. Back up projects, databases, website configuration and required logs. Record the current product version and active website path.
  2. Extract the new zetatest-web.zip into a parallel release folder.
  3. Compare the new default configuration with the current environment. Merge required values deliberately; do not copy old Config.json, appsettings.json, foldermappings*.json or web.config blindly.
  4. Stop the application pool, switch the IIS physical path to the new Website folder, and restart the pool.
  5. Verify HTTPS, sign-in, project list, roles, file and database access, one typical test run and every enabled preview area. Review the Windows event log and enabled application logs.

For rollback, stop the pool, restore the previous website path and, when a data migration requires it, the corresponding project and database backup. Keep the previous release folder until the agreed acceptance period has ended.

For browser functionality and preview-area boundaries, continue with Use Zeta Test Management in the web application. For connector and MCP setup, see Integrations and automation.